Google for Developers Korea Blog

회사나 고객에게 효과적으로 Flutter 소개하는 방법을 알려드립니다

2019년 1월 21일 월요일

.post-body span { white-space: normal !important; } <블로그 원문은 이곳에서 확인하실 수 있으며 블로그 번역 리뷰는 김태호(Google)님이 참여해 주셨습니다>
What’s Revolutionary about Flutter(Flutter는 왜 혁명적인가?)를 게시한 지 1년 넘게 지났습니다. 물론, 이 글은 여전히 Flutter를 잘 소개해주는 글입니다. 필자가 이 글을 쓰던 당시에는 Flutter에 대해 들어본 적 있는 모바일 개발자가 드물었지만, 그 이후로 큰 진전이 있었습니다. 지금은 적극적이고 활발하며 폭발적으로 성장 중인 Flutter 커뮤니티에서 Flutter를 주제로 쏟아내는 수많은 글과 동영상을 도저히 다 볼 수 없을 정도가 되었습니다. 개발자들은 Flutter의 진가를 알아챘고 이제는 진심으로 각별한 애정을 쏟아붓고 있습니다. Reflectly에서 Flutter를 사용하여 만든 훌륭한 앱을 감상해 보세요.

Reflectly 지능형 일기 쓰기 Flutter 앱
개발자들은 요즘 직면한 최대의 난제 중 하나는 회사 경영진(에이전시나 프리랜서로 활동하는 개발자라면 고객)에게 Flutter를 사용해보자고 설득하는 일이라고 필자에게 토로하곤 합니다. 회사 경영진이나 고객과 같은 의사결정권자는 단지 뭔가 대단한 기술이라는 이유만으로 최신 기술을 채택하는 데 열정을 보이지는 않습니다. 그들 역시 대체로 기술을 잘 알고 있는 사람들이지만, 그게 그들의 유일한 관심사는 아닙니다. 그들은 새로운 기술을 사용하는 것이, 예컨대 신규 고객 확보나 위험 감소와 같이, 회사의 성공에 도움이 될지 알고 싶어 합니다. 이 글은 다음 두 부류의 개발자를 염두에 둔 글입니다.

회사 경영진에게 Flutter를 사용해야 할 이유를 설득하고 싶은 개발자. 개발자가 Flutter를 잘 알고 있더라도 경영진에게 제시할 확고한 논거가 필요합니다.

Flutter를 사용하여 제품을 개발할지 스스로 결정하고 싶은 개발자.

이 글에서는 특정 모바일 앱은 Flutter를 사용하기에 좋은 대상이 아닐 수도 있는 이유도 설명하므로, 충분한 정보를 바탕으로 올바른 의사결정을 할 수 있을 것입니다. Flutter란? (엘리베이터 피치에 어울리는 표어적 문구로 작성한) Flutter의 슬로건은 ‘빠른 시간 안에 아름다운 네이티브 앱 빌드’ 입니다. 이 슬로건 문구를 네 부분으로 나누어서 하나씩 자세히 뜯어 봅시다.

빌드

아름다운

네이티브 앱

빠른 시간 안에

1. 빌드 Flutter는 현재 iOS 및 Android용 모바일 앱을 빌드하는 데 초점이 맞춰져 있습니다. 하지만 Flutter가 현재의 모바일 프레임워크와 구분되는 더욱 크고 장기적인 비전이 있습니다. Flutter는 단순한 프레임워크가 아니라 화면을 사용하여 상호 작용하는 앱을 빌드하기 위한 완전한 SDK 입니다. 즉, Flutter에는 렌더러와 렌더링할 것들(Flutter에서 위젯이라고 함)을 비롯하여 사용자 인터페이스를 만드는 데 필요한 모든 것이 있다는 의미입니다. 많은 면에서, Flutter는 Unity 또는 Unreal과 같은 게임 엔진과 유사한데, 이런 엔진은 자체적인 렌더러와 렌더링할 것들, 그리고 기타 소프트웨어도 제공합니다. 하지만 Flutter는 게임을 빌드하는 대신 앱을 빌드합니다. Flutter가 완전한 SDK라는 사실은 디스플레이를 포함한 사실상 어떤 하드웨어에서든 실행하도록 포팅 가능하다는 의미입니다. Flutter 렌더러는 다양한 기기에서 쉽게 사용할 수 있는 인기 오픈소스 그래픽 엔진인 Skia를 사용합니다.

데스크톱과 Raspberry Pi의 Flutter
Google에서는 모바일 앱에 초점을 맞춰왔지만, 다양한 회사와 개발자가 데스크톱 컴퓨터(그림 왼쪽의 macOS, Windows, Linux 및 기타), TV(Nvidia Shield TV에서 실행 중인 Flutter의 동영상), Raspberry Pi(그림 왼쪽 아래)로 Flutter를 포팅하는 작업을 해왔습니다. Flutter는 내부적으로는 Fuchsia용 사용자 인터페이스를 빌드하는 데도 사용됩니다. 앱은 점점 더 휴대폰의 범위를 뛰어넘어 확장할 것입니다. 홈 어시스턴트(Google Home Hub, Lenovo Smart Display 등), 자동차의 대화식 디스플레이, 가전기기(냉장고), 웨어러블 기기(시계, 옷), 기타 IoT 기기를 포함한 여러 기기에 걸쳐 앱에 액세스하는 것이 일상화될 것입니다. 2017년에는 온라인에 그런 기기가 84억 개가 있었습니다. IDC의 추정에 따르면, (지금으로부터 2년도 채 남지 않은) 2020년이 되면 (휴대폰은 50억 개인데) 위와 같은 기기는 300억 개를 넘을 것이라고 합니다. 이러한 기기 중 다수에 대화식 화면이 사용될 것입니다. Flutter의 아키텍처는 이처럼 새로운 기기를 위한 강력하고 아름다운 사용자 인터페이스를 만들기 위한 모든 요소를 갖추고 있습니다.

어디에나 있는 화면들
물론, Flutter는 완전히 무료이며 오픈소스로 제공됩니다.
2. 아름다운 만들려는 모바일 앱이 Google Play Store에 있는 380만 개의 앱과 Apple App Store에 있는 200만 개의 앱과 경쟁하는 현실에서 어떻게 앱의 성공을 보장할 수 있을까요? 사용자가 앱을 다운로드하도록 하는 데까지는 그럭저럭 성공하더라도, 사용자가 30일 후에도 앱을 활발히 사용할 가능성은 3%에 불과합니다. Gartner Inc.에 따르면, 게시되는 모든 모바일 앱 중 재정적 측면에서 성공하는 앱은 0.01%에 불과하다고 합니다. 개발자는 얻을 수 있는 모든 도움을 받아야 합니다.

Alibaba(왼쪽)와 Topline(오른쪽)

2Dimensions
연구 결과, 호소력 있는 디자인이 매우 중요한 성공 요인일 수 있다는 점이 밝혀졌습니다. 최근 몇 년간 가장 큰 인기를 끌었던 모바일 앱을 살펴보면 각각 나름대로 고유하고 눈에 띄는 디자인을 지니고 있음을 알 수 있습니다. 뿐만 아니라, 아름다운 앱은 이런저런 상도 받으면서 가치 있는 대중성도 얻게 됩니다. 몇 가지 예만 들자면, 왼쪽에 보이는 Alibaba(세계 최대의 전자상거래 회사)의 앱, Abbey Road Studios의 Topline 레코딩 앱, 2Dimensions의 놀라운 실시간 애니메이션 데모 앱과 같은 Flutter 앱이 있습니다. 회사 웹사이트와 웹 앱에 대해서도 그러하듯이, 회사의 브랜딩을 보완해주는 모바일 앱을 원하는 회사가 점점 늘고 있습니다. 이에 따라 높은 수준의 맞춤화 작업이 필요합니다. 마지막으로, 디자이너에게 훌륭하고 멋진 아이디어가 있었는데 그 아이디어가 실제로 구현되는 시점에 돌이켜보면 툴킷의 제한 때문에 최초의 아이디어를 제대로 살리지 못하는 경우가 종종 있습니다. Flutter는 자신의 비전을 구현하는 앱을 빌드하려는 디자이너에게 자신 있게 '예'라고 대답 할 수 있게 해줍니다. Flutter 쇼케이스에서 더 많은 Flutter 앱을 볼 수 있고, It’s All Widgets 사이트에도 수백 가지의 Flutter 앱이 소개되어 있습니다. 이러한 앱에는 이 글 초반부에 애니메이션 GIF를 사용하여 표시한 아름다운 Reflectly 일기 쓰기 앱도 포함되지만, 앱 스토어에서 다운로드하여 Android 또는 Apple 휴대폰에 설치해야 합니다. 앱을 Flutter로 전환한 경험에 대해 읽어보세요.
3. 네이티브 앱 모바일 개발자는 이 점에 놀라실지 모르겠습니다. 모바일 앱의 세계에서 '네이티브 앱'이라는 용어는 특정 언어를 사용하여 직접 플랫폼 API를 대상으로 하는 앱을 가리키는 데 종종 사용되는 용어이기 때문입니다. 게다가 더욱 혼란스럽게 만드는 점은, React Native 및 Xamarin과 같은 프레임워크에서는 플랫폼 위젯을 사용할 수 있다는 의미로 '네이티브'라는 용어를 사용한다는 사실입니다. '네이티브'라는 용어는 모바일에 사용되는 용어이므로 컴퓨팅 기술의 다른 영역에서는 실제로는 사용되지 않습니다. 예를 들어 Windows 및 macOS 컴퓨터 그리고 다른 많은 종류의 컴퓨터에 Linux를 설치할 수 있지만, Windows 또는 macOS를 '네이티브'라고 부르거나 Linux를 '교차 플랫폼' 또는 '하이브리드' 솔루션이라고 부르지는 않습니다. 사람들은 Linux를 그냥 Windows나 macOS와 똑같이 네이티브로 생각합니다. 그냥 그게 당연하다 생각하기 때문이죠. 컴퓨팅에 대해 '네이티브'의 정의를 더욱 정밀하게 내려보자면 '특정 시스템을 위해 디자인되거나 특정 시스템에 내장된다는 뜻으로, 특히 특정 프로세서, 컴퓨터 또는 컴파일러와 그 안에 작성된 프로그램과 관련된 언어를 나타냅니다.' Flutter 앱은 iOS와 Android에서 모두 네이티브 기계(ARM) 코드로 컴파일됩니다. 네이티브 앱은 장점이 많습니다. 네이티브 앱은 시작 속도가 더 빠르다는 점도 있지만, 가장 중요한 점은 더욱 원활하게 작동하며 기존 앱보다 끊김이나 버벅거림이 덜하다는 사실입니다(버벅거림은 아름다운 일이 아님). 또한 네이티브 앱은 개발자에게 앱의 동작에 대해 더 강력한 제어 능력을 부여합니다. 네이티브 앱의 장점을 누리기 위해, 모바일 개발자는 보통 별개의 도구와 언어를 사용하여 두 개의 앱을 따로 빌드해왔습니다. 이 사실이 의미하는 바는, 각 플랫폼에 대한 개발자 팀을 따로 두고서 개발한 후 팀 간에 조정해야 하는 경우가 종종 있었다는 사실입니다. 이로 인해 비용이 상당히 상승하고 위험이 증가하고 출시 시간이 길어집니다. 개발자는 Flutter를 사용하여 단일 코드베이스로 통합하고 개발 팀을 하나로 뭉치고 위험을 줄이고 출시 시간을 앞당길 수 있습니다. 이 모든 것이 네이티브 앱의 이점을 누리는 동시에 가능한 일들입니다.

어떤 것이 '네이티브'일까요? 둘 다입니다!
그럼, 위젯은 어떨까요? Flutter는 자체 위젯을 제공하므로, 플랫폼 위젯과 도구를 사용하여 개발한 앱과는 달리 Flutter 앱이 뭔가 이상하게 보이거나 느껴지지 않을지 걱정하실 수도 있을 겁니다. 왼쪽에서 iOS 플랫폼 설정 화면과 Flutter를 사용하여 만든 똑같은 화면을 비교한 모습을 확인할 수 있습니다. 픽셀 레벨에서는 작은 차이점이 몇 가지 있지만, Flutter를 사용하면 플랫폼 화면과 같은 모양과 느낌의 화면을 쉽게 만들 수 있다는 점이 중요합니다. 플랫폼은 OS 버전마다 바뀌므로, 플랫폼 네이티브 앱도 OS 버전마다 대체로 다르게 보입니다. Flutter가 '픽셀 레벨까지 완벽'하도록 시도하는 것은 사실상 무의미합니다. Flutter의 위젯은 자신이 작동 중인 플랫폼에 맞춰 적응하면서 아이콘, 색상, 레이아웃, 글꼴, 스크롤 동작 등을 비롯하여 알맞은 모양과 느낌을 제공합니다. Flutter 앱에 있어 '픽셀 레벨까지 완벽'해지는 것이 아닌, 더 중요한 목표는 해당 플랫폼의 디자인 가이드라인을 따르고 사용자에게 친숙하고 편안한 느낌을 주는 것입니다. Flutter는 플랫폼 캔버스에 직접 렌더링하는 완전한 SDK이므로 Flutter 앱의 높은 플랫폼 충실도를 실현할 수 있습니다. 따라서 같은 플랫폼에서도 언제든 바뀔 수 있는 플랫폼의 위젯, 글꼴 등에 앱이 종속되지 않습니다. Flutter를 사용해 앱을 개발하면 호환성 라이브러리도 불필요합니다. 예를 들어 Android Jelly Bean(4.1.2)을 실행하는 휴대폰에 머티리얼 디자인 위젯을 사용하는 Flutter 앱이 있습니다. 이 휴대폰은 머티리얼 디자인이 처음 만들어진 시점보다 2년이나 앞서 나온 제품이므로, 이 휴대폰에는 머티리얼 디자인용으로 내장된 위젯이 전혀 없습니다. 하지만 Flutter 앱은 이 휴대폰에서도 더 최근 버전의 OS가 설치된 더 최신 기종의 휴대폰에서와 똑같이 작동하고 멋진 모습을 보여줍니다.

Flutter가 없었더라면 이런 문제를 스스로의 힘으로 끙끙대며 해결해야 했을 것입니다. 그러나 Flutter가 있으므로 이전 버전의 OS에서 더욱 다양한 테스트를 수행하며 개발자의 앱이 사용하는 기능을 제공하지 않는 플랫폼을 위한 해결책을 찾을 수 있습니다. 개발자들은 Flutter를 사용해보니 테스트 작업이 너무나 쉬워졌다고 말합니다. 요컨대, Flutter는 네이티브 앱의 장점뿐 아니라 다음과 같이 추가적으로 중요한 이점이 있습니다.

Flutter 앱은 각 플랫폼 OS의 이전 버전에서 실행됩니다. 예를 들어 개발자가 최신 버전의 Android에서 Flutter 앱을 테스트하는 경우 이전 버전에서와 똑같은 모습일 것입니다. 따라서 Flutter 앱은 구형 휴대폰에서 잘 작동할 수 있으며, 테스트 횟수도 훨씬 줄일 수 있습니다.

변경 사항으로 인해 Flutter가 종속된 부분이 중단(이는 극히 드문 경우로, 개발자의 앱이 아니라 Flutter의 버그 때문일 것임)되지 않는 한, 플랫폼 OS의 새 버전에서도 Flutter 앱이 중단되는 일은 없을 것입니다.

제조업체나 이동통신사의 OS에 대한 수정 사항(기본 글꼴의 변경을 일반적인 예로 들 수 있음)으로 인해 앱의 모양이 극적으로 달라지지는 않을 것입니다.

가장 중요한 점은, 개발자가 Flutter를 사용함으로써 모든 플랫폼과 모든 버전에서 앱의 모양을 픽셀 레벨까지 정밀하게완벽히 제어할 수 있다는 사실입니다.

원한다면 iOS와 Android에서 Flutter 앱의 모양이 다르게 나타나도록 명시적으로 구현할 수 있습니다. 그렇게 하지 않더라도 Flutter 위젯은 각 플랫폼의 디자인 가이드라인에 맞춰 적응합니다.

Flutter는 두 플랫폼에 대해 모두 단일 코드베이스를 사용하여 이를 실현할 수 있습니다. 또는 원한다면 Flutter 앱에 각 플랫폼에 대한 플랫폼 네이티브 코드를 추가할 수 있습니다.

4. 빠른 시간 안에 마지막으로 언급하지만 결코 다른 항목보다 그 중요성이 덜하지 않은 점은, Flutter를 사용하면 더 나은 앱을 더 빠르게개발할 수 있다는 점입니다. Flutter의 가장 인기 있고 정말 멋진 기능은 상태 저장 핫 리로드기능입니다. 이 기능은 놀랍도록 빠른 속도(보통 1초 미만)를 자랑할 뿐 아니라 상태가 저장되는데, 그 의미는 앱의 깊숙한 부분에서 코드를 변경할 경우 다시 컴파일한 후에 변경 효과를 확인하기 위해 다시 같은 곳으로 이동하거나 상태를 수동으로 재생성할 필요가 없다는 뜻입니다.

상태 저장 핫 리로드!
Flutter의 상태 저장 핫 리로드는 (자바스크립트용 V8 컴파일러와 Smalltalk용 Strongtalk를 빌드한 사람들 중 몇 명이 개발한) 고급 컴파일러 기술과 Flutter가 네이티브이고 반응형 뷰를 기반으로 한다는 사실 덕분에 가능합니다. 속도가 빨라졌다는 점 외에도, 많은 개발자가 Flutter 덕분에 코딩 방식이 극적으로 변했다고들 합니다. 개발자는 Flutter로 새로운 아이디어와 새로운 레이아웃을 빠르게 시도해 볼 수 있습니다. 개발자는 이해관계자가 요청하는 변경 사항을 그들이 보는 앞에서 바로 구현할 수 있습니다. 우리는 디자이너가 자신이 원하는 결과를 정확히 얻는 데 Flutter가 도움이 된다는 점도 잘 압니다. 디자이너는 원하는 모습이 실현될 때까지 다양한 매개변수로 시험해 볼 수 있습니다. 사실, 웹 앱에서 CSS를 사용하는 방법을 아는 디자이너는 Flutter에서 레이아웃을 변경하는 방법을 스스로 쉽게 터득할 수 있다는 얘기를 들려줍니다. 이 점을 제대로 알아보려면 실시간으로 Flutter 앱 라이브 코딩을 보거나 Flutter를 직접 사용해 실제 앱을 빌드해 보세요. Flutter 해커톤에 참가해 얼마나 빠르게 Flutter를 배우고 Flutter에서 실제로 작동하는 앱을 빌드할 수 있는지 알아보세요. 마지막 섹션에서 논한 바와 같이, Flutter 앱은 또한 테스트가 덜 필요하므로 앱의 새로운 기능을 훨씬 더 빠르게 테스트하고 제공할 수 있습니다. 예를 들어 JD.com에서는 다음과 같은 얘기를 들려주었습니다. 우리는 전에 비해 절반의 개발 리소스만으로 똑같은 기능을 개발할 수 있었습니다. 같은 수의 엔지니어를 투입해도 이제는 릴리스마다 더 많은 기능을 제공할 수 있습니다. 마찬가지로, Alibaba 역시 Flutter를 사용한 덕분에 새로운 기능을 추가하는 데 걸린 평균 시간이 한 달에서 2주로 단축되었다고 합니다.

Hamilton 앱

Hamilton 앱의 경우 실제로 개발자가 앱을 출시하기 전날 밤에 앱에 대한 주요 변경 작업을 수행했는데, 앱이 바위처럼 굳건한 안정성을 가지고 있다는 확신이 있었기에 가능한 일이었습니다. 3개월이라는 짧은 기간에 빌드된 이 앱은 양쪽 앱 스토어에서 모두 인기를 끌었습니다. 게다가 Flutter를 사용하면 계속해서 새로운 기능을 자주 추가하기도 더 쉬우므로, 사용자를 적극적인 사용자로 유지하고 더 많은 사용자가 앱을 다시 사용하도록 하는 데 도움이 됩니다. 그게 바로 성공적인 모바일 앱을 빌드하는 방법입니다.

Flutter를 사용하면 앱을 쉽고 빠르게 빌드하고 수정할 수 있을 뿐 아니라, Flutter 위젯도 빠르게 업데이트할 수 있습니다. 플랫폼 위젯을 사용하지 않는 Flutter에 대해 공통적으로 걱정하는 문제는 각 플랫폼의 새로운 위젯이 출시되거나 기존 위젯이 개선될 때마다 Flutter가 플랫폼의 변화를 따라잡기 힘들지 않겠느냐는 점입니다. 하지만 Apple이 노치를 포함한 새로운 iPhone X를 발표했을 때 Flutter는 그 휴대폰 자체가 출시되기도 전에 노치를 위한 지원을 추가할 수 있었습니다. 이는 iOS 기능에만 해당되는 얘기가 아닙니다. Google이 I/O 2018에서 머티리얼 디자인의 중대한 개편을 발표했을 때 Flutter는 이미 새로운 기능을 완전히 구현하도록 업데이트된 상태였습니다. 빠르게 맞춤설정할 수 있는 Flutter의 능력 덕분에 가능한 일이었습니다. 개발자들이 Flutter를 사용해봤더니 생산성이 2~3배 정도 높아지고 더욱 성공적인, 더 나은 앱을 빌드할 수 있게 되었다고 자주 알려오는 것만 보더라도 Flutter의 가치를 확인할 수 있습니다.
위험 및 제한 사항 어떤 일에든 항상 절충할 점이 있게 마련인데, Flutter 역시 예외는 아닙니다. 특정 앱에는 Flutter가 최선의 도구가 아닐 수도 있는 이유가 몇 가지 있으므로, 이를 토대로 충분한 정보를 바탕으로 결정할 수 있습니다. 최종 완성된 Flutter 앱은 Flutter 위젯과 렌더러를 포함하므로 플랫폼 위젯과 렌더러를 활용하는 앱보다 크기가 약간 더 큽니다. 최근까지만 해도 Flutter 앱의 최소 크기는 6.7MB였지만 지금은 4MB를 약간 넘는 수준으로 줄었습니다. 앞으로 더욱 최적화할 계획입니다. (Flutter는 단일 플랫폼 전용 앱을 빌드하는 데도 사용되지만) Flutter의 주요 이점 중 하나는 양쪽 모바일 플랫폼에서 모두 단일 코드베이스를 사용하여 앱을 출시할 수 있다는 점입니다. 하지만 하나의 특정한 플랫폼에 긴밀하게 연계되어 있는 앱이나 주로 알림 기능을 제공하는 백그라운드 서비스를 제공하는 앱과 같이 플랫폼에서 제공되는 뷰 주위의 래퍼가 주된 역할인 앱이 있습니다. 이러한 앱을 Flutter로 작성할 수 있지만 그 이점을 충분히 누리지는 못할 것입니다. 우리가 종종 받는 질문 중에 Flutter가 계속 여기에 머무를지 여부를 묻는 질문이 있습니다. 그에 대한 대답이 강한 긍정인 이유가 여러 가지 있습니다. 첫째, Google은 그 자신이 고객용 앱과 내부용 앱(더 많은 앱을 개발 중임) 모두를 위한 Flutter를 비롯하여, Flutter의 헤비 유저입니다. 예를 들어 최근에 출시한 Google Ads 모바일 앱(전에는 AdWords라 불림)은 Flutter로 작성한 앱입니다. Google이 Flutter 뒤를 굳건히 받쳐주고 있고 Flutter의 성공을 위해 최선을 다하고 있습니다. 둘째, 회사들이 주요 앱을 일반적으로 두 플랫폼에서 따로 빌드해왔다는 사실로 미루어 볼 때, 예컨대 회사에서는 먼저 iOS 앱을 빌드한 다음에 수요가 충분할 경우 Android 앱을 이후에 빌드하는 것이 덜 위험한 방법이라고 생각했을 수 있습니다. Flutter를 사용하면 사실상 똑같은 기능으로 두 플랫폼에서 모두 앱을 동시에 출시할 수 있으므로, 그러한 위험을 우회하고 앱의 잠재 시장을 늘릴 수 있습니다. 이는 Android에 크나큰 이점이 될 수 있습니다. 또 다른 잠재적 문제는 Flutter가 비교적 새로운 도구라는 점입니다. 따라서 당연히 기능과 커뮤니티 지원이라는 측면에서 모두 Flutter가 기존 도구를 따라잡으려면 시간이 어느 정도 걸릴 것입니다. 현재로서는 플랫폼에서 제공하는 기능 중에 Flutter가 구현하는 데 시간이 다소 걸릴 기능이 있습니다. Google은 이러한 기능을 추가하기 위해 Flutter에 리소스를 투입하고 있습니다. 왜 Flutter를 사용해볼 만한 가치가 있는지에 대해 더욱 심층적인 정보를 원하신다면 What’s Revolutionary about Flutter(Flutter의 어떤 점이 혁명적인가)와 Why Flutter uses Dart(Flutter가 Dart를 사용하는 이유)를 읽어보세요. 그리고 Flutter 사용자가 Flutter에 대해 어떻게 생각하는지 알아보려면 최신 사용자 연구 결과를 읽어보세요.
시작하는 방법 Flutter를 사용해볼 준비가 되었으면 아래에 몇 가지 유익한 참고 자료가 있으니 확인해 보세요.

https://flutter.io/get-started/ — Flutter 설치, 편집기 구성, 시험 사용, 첫 번째 Flutter 앱 작성에 도움이 되는 가이드입니다.

YouTube에서 Flutter 동영상을 시청해 보세요.

개발자로서 Android, iOS, React Native, Xamarin 중 하나 이상에 익숙한 분을 위한 가이드 세트가 있습니다.

모바일 개발에 처음 도전하는 개발자를 위해 Building Layouts in Flutter, Add Interactivity, A Tour of the Flutter Widget Framework와 같은 가이드도 있습니다(반응형 프로그래밍 원리에 익숙하지 않은 분을 위한 설명 포함).

Flutter 설명서는 매우 가치 있는 자료입니다. 위젯 카탈로그와 FAQ도 중요한 내용을 담고 있습니다.

마찬가지로, It’s All Widgets의 앱도 살펴보세요. 이들 중 다수가 오픈소스이므로 게시된 앱의 코드를 볼 수 있습니다. 자신의 Flutter 앱을 작성하신 후에는 잊지 말고 꼭 제출해 주세요.

Flutter에 대한 베스트 기사 목록을 매주 이메일로 받고 싶으시면 Flutter Weekly 구독 신청을 해주세요.

훌륭한 Flutter용 코드랩이 많이 있습니다. 그걸로 충분치 않다면 Udacity에서 무료 제공하는 Flutter에 관한 온라인 동영상 과정도 있으므로 챙겨 보시기 바랍니다.

여기에는 다수의 다른 문서가 있습니다.

Flutter 커뮤니티에 참가하려면 Twitter, Gitter, Stack Overflow에서 우리를 찾으실 수 있습니다. Flutter Dev 메일링 리스트에 구독 신청하셔야 합니다. 그리고 가까운 곳에서 열리는 Flutter Meetup이나 Study Jam을 찾아보시고, 근처에서 열리는 모바일 앱 해커톤이 있는지 알아보세요.
결론 Flutter는 개발자의 생산성을 높여주고 더 나은 앱을 빌드하는 데 도움이 되는 고속 개발 환경을 제공합니다. 개발자에게 정말 놀라운 수준의 제어 능력을 부여하는, 이해하기 쉽고 유연성이 뛰어나며 맞춤설정 가능한 툴킷입니다. Flutter는 단일 코드베이스에서 빠르고 원활하게 작동하는 네이티브 iOS 및 Android 앱을 만듭니다. Flutter를 사용하면 비용을 절감하고 위험을 줄일 수 있습니다. Flutter는 무료이고 오픈소스로 제공됩니다. 또한 Flutter는 더 많은 수익을 거두는 데도 도움이 됩니다. Android 시장과 iOS 시장을 둘 다 동시에 공략하고, 더 짧은 시간에 더 나은 앱을 만들 수 있습니다. 또한 개발자들은 (필자의 마음에 가장 드는 부분 중 하나이기도 함) Flutter 덕분에 모바일 개발이 다시 재미있게 느껴진다고 합니다. Flutter를 사용하는 개발자 중 92%라는 압도적 비율로 Flutter에 대해 만족 또는 매우 만족 으로 응답했습니다. 이 숫자는 꾸준히 증가해오고 있는데, 이러한 결과는 모두 1.0 버전이 출시되기 전인 Flutter 알파 버전과 베타 버전에 대한 응답 결과라는 점이 더욱 놀랍습니다. 마지막으로, Flutter는 미래를 지향합니다. Flutter는 반응형 뷰를 지원하는 유일한 네이티브 모바일 툴킷이고, 더 나은 앱을 빌드하는 데 도움이 되는 프로그래밍 패러다임이며, 초고속 상태 저장 핫 리로드와 같은 기능도 지원합니다. 그리고 Flutter는 완전한 SDK이므로 대중적 인기를 얻게 되면 새로운 플랫폼으로 포팅함으로써 계속 유용하게 활용될 수 있습니다.

Google Play의 64비트 요구 사항에 맞춰 앱을 준비하세요

2019년 1월 21일 월요일

.post-body span { white-space: normal !important; } <블로그 원문은 이곳에서 확인하실 수 있으며 블로그 번역 리뷰는 양찬석(Google)님이 참여해 주셨습니다>게시자: Vlad Radu(Play 제품 관리자), Diana Wong(Android 제품 관리자)
64비트 CPU는 사용자에게 더 빠르고 풍부한 환경을 제공하며, 앱에 64비트 CPU 지원을 추가하면 동작 성능이 개선될 수 있습니다. 그 뿐만이 아니라 64비트 CPU를 지원하는 앱이 많아 질수록 64비트 전용 하드웨어가 시장에 좀 더 빨리 자리잡고, 이를 통해 전체 기술 생태계가 좀 더 빨리 발전할 수 있습니다.
개발자 여러분이 64비트 CPU 지원을 위해 충분한 시간이 필요하다는 점을 잘 알고 있습니다. 안드로이드는 5.0 Lollipop 버전에서 처음으로 64비트 CPU를 지원해왔고, 2017년에는 네이티브 코드를 사용하는 앱이 (32비트 버전 외에) 64비트 버전을 제공해야 한다는 점을 공식적으로 발표했습니다. 관련하여 2019년에 시작될 64비트 요구 사항에 관해 좀 더 세부적인 정보와 일정을 알려드리려고 합니다. 64비트 요구 사항: 개발자에게 의미하는 바 2019년 8월 1일부터:

네이티브 코드를 포함하는 모든 새 앱과 앱 업데이트는 Google Play에 게시할 때 32비트 버전 외에 64비트 버전도 함께 제공되어야 합니다.

기간 연장 대상: Google Play는 2021년 8월까지 Unity 5.6 또는 이전 버전을 사용하는 기존 게임에 대한 32비트 전용 업데이트를 계속 허용할 예정입니다.

2021년 8월 1일부터:

Google Play는 64비트 지원 기기에서 64비트 버전이 없는 앱에 대한 서비스를 중단할 예정이며, 이에 따라 해당 기기에서는 Play Store에서 이러한 앱을 사용할 수 없게 됩니다.

여기에는 Unity 5.6 또는 이전 버전으로 만든 게임이 포함됩니다.

다음에 대해서는 이 요구 사항이 적용되지 않습니다.

현재 64비트 코드를 지원하지 않는 폼 팩터인 Wear OS 또는 Android TV를 명시적 대상으로 하는 APK 또는 앱 번들

Android 9 Pie 이상을 실행하는 기기에 배포되지 않는 APK 또는 앱 번들

이러한 변화가 32비트 지원에 관한 정책 변경을 의미하는 것은 아닙니다. Play는 계속 32비트 CPU 기반 기기에 앱을 제공할 것입니다. 이 요구 사항이 의미하는 바는 32비트 네이티브 코드를 사용하는 앱은 반드시 64비트 버전도 추가로 포함해야 한다는 점 입니다.

64비트 요구 사항에 맞춰 앱 준비하기 대부분의 경우 64비트로 이전하는 과정은 간단할 것으로 예상됩니다. 많은 앱이 네이티브 코드가 아닌 코드(예: 자바 프로그래밍 언어 또는 Kotlin)로 작성되고, 이 경우 64비트 요구 사항을 만족시키기 위해 추가할 필요한 작업은 없습니다.
모든 개발자: 다음은 64비트 호환 버전이 되기 위해 수행해야 할 단계에 대한 개요 정보입니다. 이 과정을 좀 더 자세히 설명한 내용은 심층적인 정보를 다룬 문서를 참조하세요.
APK 또는 앱 번들에서 네이티브 코드를 살펴보세요. APK Analyzer를 사용하여 .so 파일을 확인해 볼 수 있습니다. 이런 파일이 직접 작성한 코드로 만들어졌는지 아니면 사용 중인 SDK 또는 라이브러리에 포함된 파일인지 확인하세요. APK에 .so 파일이 없으면 이미 64비트와 호환되는 것입니다.
64비트 아키텍처를 사용 설정하고 자체 코드를 재컴파일해 네이티브 코드(.so 파일)를 다시 빌드하세요. 자세한 내용은 문서를 참조하세요.

필요한 경우 64비트 호환 버전으로 SDK와 라이브러리를 업그레이드하세요. SDK 또는 라이브러리 소유자에게 연락해 사용할 수 없는 SDK 또는 라이브러리가 있는지 알아보세요. 구글은 주요 라이브러리 개발사들과 함께 64비트 호환성에 관한 작업을 진행 중입니다.

앱을 다시 빌드한 후 로컬에서 문제를 테스트하세요.

철저한 테스트를 위해 테스트 트랙을 사용하여 테스터에게 롤아웃하세요.

게임 개발자: 가장 많이 사용되는 세 가지 엔진이 모두 현재 64비트를 지원합니다(2015 이후의 Unreal 및 Cocos2d, 2018 이후의 Unity). 구글은 게임 엔진 마이그레이션이 긴 리드 시간을 요하는 강도 높은 과정임을 잘 알고 있습니다.
Unity는 최근 버전 2017.4와 2018.2에서 64비트 지원을 제공하기 시작했습니다. 따라서, 5.6 또는 이전 버전을 사용한앱의 경우 2021년 8월까지 64비트 요구 사항 적용을 연장할 것입니다. Unity는 64비트 호환 버전으로 업그레이드하는 과정을 통해 개발자에게 도움을 줄 수 있는 가이드를 제공하고 있습니다.
SDK 및 라이브러리 소유자: 앱 개발자가 적응할 시간을 주기 위해 가급적 빨리 64비트 호환성을 갖추도록 업데이트하고 개발자에게 그 사실을 알리세요. 다음 폼을 통해 뉴스 그룹에 등록해 고객 서비스 제공에 도움이 될 수 있는 최신 도구와 정보에 대한 업데이트를 받아보세요. 앞으로의 전망 이미 64비트를 지원하는 개발자께는 감사 말씀을 드립니다. 수고 많으셨습니다! 아직 지원하지 않는 개발자께서는 가급적 빨리 64비트 요구 사항에 맞춰 작업을 시작하시기 바랍니다. 마감시한이 다가옴에 따라 앱의 호환 여부 확인 방법에 관해 더욱 자세한 정보로 개발자 문서를 계속 업데이트하겠습니다. 64비트 CPU가 인공지능, 머신러닝 및 몰입형 모바일 환경과 같은 영역에 가져올 미래의 변화는 생각만 해도 마음 설렙니다. 64비트 지원을 통해 64비트 기기의 첨단 컴퓨팅 기능으로 실현되는 혁신과 64비트 코드만 지원하는 미래의 안드로이드 기기에 맞는 생태계를 준비합니다.

안전하고 보안이 철저한 사용 환경 제공

2019년 1월 18일 금요일

.post-body span { white-space: normal !important; } 게시자: Paul Bankhead, Google Play 제품 관리 담당 이사 우리는 Android 사용자가 좋아할 만한 앱과 게임을 간편하게 찾아서 안전하게 설치할 수 있도록 하기 위해 Google Play Store의 보안과 개인정보 보호에 끊임없이 주력하고 있습니다. 우리는 Google Play Developer 정책을 정기적으로 업데이트하는데, 오늘은 사용자 데이터를 안전하게 지키기 위해 더욱 강력한 통제 기능과 새로운 정책을 도입했습니다. 다음과 같은 몇 가지 업데이트 사항이 있습니다.
보안과 성능을 위한 업그레이드
이전에 발표한 바와 같이, Google Play는 2018년 11월 1일부로 API 레벨 26(Android 8.0) 이상을 대상으로 하도록 기존 앱에 대한 업데이트를 요구할 것입니다. 새로운 앱에는 전부 업데이트가 이미 필수 사항으로 적용되고 있습니다. Google Play에 제공되는 모든 앱이 보안과 성능을 위해 최적화된 최신 API를 사용하여 빌드되도록 보장하는 것이 우리의 목표입니다.
사용자 보호
Google Play 개발자 정책은 사용자를 위해 안전하고 보안이 철저한 환경을 제공하는 동시에 개발자에게도 성공에 필요한 도구를 제공할 목적으로 마련된 것입니다. 예를 들어 우리는 개발자들에게 앱의 기능에 필요한 수준으로만 권한 요청을 제한하고 사용자에게 자신이 액세스하는 데이터에 대해 명확히 알릴 것을 항상 요구해왔습니다. 오늘 발표한 Google Play 개발자 정책 업데이트의 일환으로, SMS 및 통화 기록 권한과 관련된 변경 사항을 발표합니다. 일부 Android 앱은 사용자의 전화(통화 기록 포함)와 SMS 데이터에 액세스하기 위한 권한을 요청합니다. Google Play에서는 앞으로 이러한 권한의 요청이 허용되는 앱을 제한할 방침입니다. 사용자가 전화를 걸거나 문자 메시지를 보내기 위한 기본 앱으로 선택한 앱만이 각각 통화 기록과 SMS에 액세스할 수 있게 될 것입니다.
SMS 및 통화 기록 권한을 대체하는 제품에 대한 자세한 내용은 Google Play 개발자 정책 센터를 방문해서 살펴보시고 이 고객센터 문서를 참조하시기 바랍니다. 예를 들어 SMS Retriever API를 사용하면 SMS 기반 사용자 확인을 수행할 수 있고 SMS Intent를 사용하면 SMS 또는 MMS 문자 메시지를 시작하여 콘텐츠나 초대를 공유할 수 있습니다. 우리는 개발자 파트너들과 긴밀히 협력하고 소통하면서 앱을 조정하고 업데이트하기에 적절한 시간적 여유를 드릴 것이며, 본 정책 업데이트 발표로부터 90일 후에 실제로 시행하기 시작할 것입니다. 우리는 앞으로 몇 달 동안 다양한 제품과 플랫폼에 추가적인 통제 수단과 정책을 배포하고 계속 개발자와 협력하면서 원활하게 전환할 수 있도록 도와드릴 것입니다. 사용자의 신뢰가 무엇보다도 중요하므로, 우리는 앞으로도 계속 안전하고 보안이 철저한 Android 생태계를 만들어가는 데 만전을 기할 것입니다.

Google I/O를 위한 Google 어시스턴트 액션 제작기 (1)

2019년 1월 18일 금요일

이 게시물은 Google I/O ’18 Google 어시스턴트 액션의 디자인과 제작에 관해 두 파트로 나누어 소개하는 글로, April Pufahl(@aprilpufahl)과 함께 작성했습니다. 코드는 여기서 확인하세요.

행사에 몸소 참석하는 분이든, 가까운 곳에서 열리는 뷰잉 파티에 참석하는 분이든, 집에서 동영상으로 보는 분이든, Google I/O와 같은 이벤트를 최대한 활용한다는 것은 일종의 도전입니다. Actions on Google 팀은 어시스턴트 액션을 통해 이벤트 현장에 가시는 분과 동영상 시청자 모두에게 똑같이 유익한 경험을 줄 수 있는 기회를 발견했습니다. 더 많은 분들이 행사를 만끽할 수 있도록 Google 어시스턴트 액션을 만들고 싶었습니다. 이 게시물에서는 어시스턴트 액션을 만들 때 마딱드린 주요 과제와 이를 해결하기 위한 결정 사항을 비롯하여, 액션을 설계하는 과정에 중점을 두고 설명하겠습니다. 이어질 다음 게시물에서는 기술적 구현에 관해 상세히 다룰 예정입니다.

왜 대화인가?

대화 디자인은 강력한 접근 방식이지만, 모든 사례에 적합한 것은 아닙니다. 예를 들어 대화는 어떤 레스토랑의 영업 시간을 찾는 작업에는 효과적이지만, 저녁 메뉴를 찾아보기에는 좀 거추장스럽게 느껴집니다. 우리는 어시스턴트 액션이 제공하는 대화가 속도, 단순성, 편재성을 통해 사용자에게 확실히 가치를 부가하도록 하고 싶었습니다. 대화가 적합할 것이라 생각한 이유는 다음과 같습니다.

이벤트에 대한 대화는 직관적입니다. 사용자는 어떤 이벤트가 어디서 있을 예정인지에 대해 이벤트 플래너 및 관련 스태프와 대화하는 멘탈 모델을 이미 가지고 있습니다.
사용자가 이벤트에 관해 물어볼 수 있습니다. 사용자는 질문을 통해 자신이 정확히 원하는 바(예: 일정 정보, 세션 주제, 가는 길 등등)를 빠르게 확인할 수 있습니다.
사용자가 멀티태스킹을 해야 합니다(특히 이벤트에 참석할 때). 사용자가 잠시 다른 일을 해야 하거나 뭔가에 시선을 빼앗길 수도 있습니다. 또는 이동할 일이 생길 수도 있습니다.
이벤트에 대한 세부 사항을 묻는 것처럼 개인적 궁금증이 아닌 사항을 물어봐야 할 때, 사용자는 대화나 타이핑으로 질문하는 걸 편하게 느낍니다.

사용 사례의 확정

위의 전제로부터 어떻게 다음 단계로 나아갈 수 있을까요? 어떤 소프트웨어 프로젝트에서나 마찬가지로, 우선 요구 사항 수집부터 시작했습니다. 특히 다음과 같은 사용 사례에 집중하고 싶었습니다.

이벤트 참석자와 참석하지 못한 사람을 포함한 대부분의 사용자 포괄
I/O에 관해 사용자가 가장 자주 묻는 질문과 궁금증 해결
특히 이벤트 참석자를 위해 빠른 속도 강조
이벤트 이전, 도중, 이후에 사용자가 갖는 다양한 목표 존중

이러한 모든 목표에 맞춘 디자인 시도는 엄청나게 도전적인 과제였습니다. 우리는 I/O 이전, 도중, 이후에 여러 사용자 프로필에 걸쳐 다양한 사용 사례에 적합한 단일 솔루션을 만들어야 했습니다. 하지만 개발자를 위해 액션의 구현 소스를 공개하는 것이 제2의 목표였기에, 더 많은 기능을 탑재하려고 높은 품질 기준을 낮추고 싶진 않았습니다. Android IOSched 앱의 전통을 유지하면서 우리의 솔루션이 Actions on Google 개발자를 위한 도구이자 모델이 될 수 있기를 바랐습니다.

사용자가 가장 자주 묻는 질문을 파악하기 위해, 1) I/O ’17 액션에 대해 Dialogflow 분석을 통해 얻은 데이터와 2) 전에 I/O에서 일한 적 있는 Google 직원과 대화를 나누었습니다.

I/O ’17 액션은 기조연설, 행사 장소 등에 대한 몇 가지 기본적인 질문에 답해주었고, 사용자가 관심 영역별로 알맞은 세션을 찾을 수 있게 해주었습니다. 수집한 사용 데이터를 보면, 세션 찾기 기능이 꽤 많이 사용되었고 사용자들이 일단 해당 대화 경로에 들어오면 큰 오류없이 작업을 잘 마무리 하는 것으로 확인되었습니다. 대부분의 사용자는 기조연설이나 사은품 증정에 대해 물었고 여러 가지 발표, I/O Extended 등에 대해 미리 준비된 다른 답변은 찾지 않았습니다. 이를 바탕으로, 우리는 세션을 찾아 더 구체적인 정보를 알아내고 이벤트에 대한 FAQ의 검색 기능을 향상하기 위한 사용자 환경 개선에 초점을 맞추고 싶었습니다.

I/O에서 일한 Google 직원들과 대화를 나눠본 결과, 참석자들이 묻는 질문에는 다음과 같은 4가지 주요 범주가 있는 것으로 나타났습니다.

일반적인 길 안내(예: 화장실은 어디죠?)
개인적 길 안내(예: 내가 다음으로 참석할 세션은 어디서 열리죠?)
이벤트 세부 정보(예: 점심시간은 몇 시예요?)
위치별 이벤트 세부 정보(예: 이 방에서 다음에 진행되는 세션은 무엇인가요?)

이러한 조사 결과를 바탕으로 이벤트 현장에서 쉽게 길을 찾고 원하는 세션에 참가할 수 있도록 네비게이션에 대한 지원을 추가하고 싶었습니다. 또한 사용자가 이동 중에도 빠르게 네비게이션에 액세스할 수 있도록 사용자의 일정에도 연결하고 싶었습니다. 이런 기능을 실제로 구현하려면 기능마다 일정 부분 절충해야 할 사항이 있습니다(파트 2에서 자세히 다룰 예정임).

이 모든 정보를 활용하여 디자인을 안내해 줄 가상 사용자와 가상 사용자의 사용 여정을 만들었습니다.

페르소나 만들기

다음으로, 사용자와 상호 작용하는 페르소나 디자인에 초점을 맞췄습니다. 페르소나를 만드는 목적은 사용자가 마치 사람과 대화하고 있다고 여기게끔 하려는 게 아니라, 먼저 학습한 커뮤니케이션 시스템을 활용하여 최선의 대화를 파악하기 위한 것입니다. 특히 다음과 같은 특성에 초점을 맞추었습니다.

실용적이고 직접적임
기술에 정통함
열정적임
I/O 전문가임

우리는 GDE(Google Developer Expert)가 이러한 특성을 구현한 캐릭터의 훌륭한 예라고 판단했습니다. GDE는 개발자 커뮤니티에서 개방성과 전문성을 갖춘 호기심 많고 창의성이 풍부하며 열정적인 존재입니다. 이 시점에서 우리는 사는 이야기, 동기 부여, 기술적 선호도를 비롯하여, 한 페이지 분량에 걸쳐 가상 사용자의 일대기를 작성하는 실수를 범했습니다. 너무 의욕이 앞섰던 거죠. 애초에 생각했던 페르소나는 대화 내용을 작성할 때 쉽게 마음속에 떠오를 정도로 단순해야 하는데 말이죠. 그래서 그 내용을 짧은 한 단락으로 줄였습니다. 우리가 만든 가상 사용자를 Keeper of I/O-Specific Knowledge라고 불러 게임의 대가와 같은 느낌을 자아내고 싶었습니다. 신규 사용자의 경우 환영 인사의 일부로 이 이름을 들려줍니다. 이름의 첫 글자를 따면 KIOSK가 됩니다. 꽤 그럴듯하지 않습니까?

다음으로 이 가상 사용자에게 생명력을 불어넣어 줄 목소리를 선택해야 했습니다. 음성 오디오 녹음이 사용자 환경 개선에는 이상적인 방법이었겠지만, 문자열의 변동을 고려하면 막상 그렇게 구현할 경우 무척 지루해졌을 것입니다. 대신 Actions on Google 카탈로그에서 사용 가능한 음성을 살펴보았습니다. 사용 가능한 미국 영어용 TTS 음성 중에서 '실용적'이고 '기술에 정통'하며 '직접적인' 속성에 대해 'Female 2'에 최고 점수를 주었습니다.

샘플 대화 만들기

화자(사용자와 가상 사용자)와 대화 주제(사용 사례)를 분명히 정하고 나니 대화 작성을 시작할 수 있었습니다. 이를 통해 코드 표기, 복잡한 흐름도, 인식-문법 문제 등의 복잡한 기술적 처리 과정을 생략하고 음성 및 액션이 주는 대략적인 느낌을 확인하기 위한 실험을 할 수 있습니다. 행사 참가자(Anna)가 현재 I/O에 참석 중인데 그날의 나머지 세션에 대한 정보를 원하는 대화로 시작해봤습니다.

먼저 1) 사용자에게 환영 인사를 건네고, 2) 기대 수준을 조절하고, 3) 사용자가 통제권을 갖도록 하는 방식으로 환영 인사를 작성했습니다. 'Google I/O 18'이라는 이름은 액션이 할 수 있는 일을 제대로 나타내지 못하기 때문에, 이 액션을 '론치패드'로 설명했습니다. 결정적으로, 참석자와 비참석자가 서로 다른 목표(예: 가는 길 파악과 라이브스트림 시청)를 생각하고 있으므로 각 사용자 환경에 맞춰 조정하고 싶었습니다. 그래서 범위를 좁혀가는 질문(이 경우에는 예/아니요 질문)을 던졌습니다. 이때 넓은 범위의 질문(예: 어떤 게 필요하세요?)을 하기 전에 가상 사용자의 명칭(Keeper of I/O-Specific Knowledge)을 활용하는 것 외에도 사용자에게 몇 가지 추천 항목(예: 일정 관리, 할 일 찾기, 길 안내 받기 등)을 제시했습니다. 사용자는 추천 항목 중 하나를 선택하거나 액션이 지원하는 다른 항목(예: 기조연설 또는 세션 찾아보기)으로 바로 갈 수 있었습니다.

이 샘플 대화의 나머지 부분에서 지원하고 싶은 다양한 사용 사례로 사용자를 안내하는 메뉴를 만들었습니다. 사용자가 액션과 대화를 시작할 때 어떤 내용을 물을 수 있을지 자동으로 알지는 못할 것이므로 이는 유용한 기능입니다. 그와 동시에, 사용자에게 너무 많은 옵션을 제시해 혼란스럽게 만들고 싶지 않았으므로, 옵션을 직관적인 범주로 분류하려 했습니다. 예컨대 9가지 옵션을 그냥 나열한 메뉴를 제시하기보다는 다음과 같은 3가지 범주로 분류했습니다.

전문가에게서 배우기

기조연설
세션
오피스 아워
앱 리뷰

데모

코드랩
샌드박스

휴식 및 기타

음식
사은품
폐장 후 시간

이를 기반으로 각각 다른 사용 사례에 초점을 맞춘 10가지 샘플 대화를 더 만들었습니다.

디자인 구체화

몇몇 샘플 대화를 만든 후, 대화의 상위 레벨 흐름과 로직을 요약하기 시작했습니다. 이런 작업을 수행하는 과정에서, 대화 구조가 다차원이라는 점이 분명해졌습니다. 즉, 대화의 변화는 단지 한두 가지의 사용자 특성이 아니라 다음 세 가지 요소에 종속되어 있다는 점을 깨달았습니다.

사용자가 액션의 신규 사용자인지, 아니면 기존 사용자인지 여부
현재 세션 날짜가 I/O 이전, 도중 또는 이후인지 여부
사용자가 I/O에 참석 중인지 여부

이를 통해 다음과 같은 도식을 도출했습니다.

근본적으로 다음과 같은 사용 사례를 다루었습니다.

이벤트에 대한 일반적인 정보 관련 질문(날짜, 위치, 기조연설 등)
이벤트에서 할 일 또는 길 찾기(참석자의 경우)
일정 찾아보기
자신의 일정 찾아보기

일반적인 이벤트 관련 질문은 상당히 간단하게 다룰 수 있습니다. 기조연설, 사은품, 음식 등에 관련된 각 질문에 대해 이벤트와 관련된 날짜를 기준으로 미리 준비된 답변을 내놓았습니다. 각각의 답변이 TTS(텍스트 음성 변환)에서 렌더링되는 것을 청취하고 필요에 따라 SSML(Speech Synthesis Markup Language)을 사용했습니다. 대체로 대화 구문이 더욱 자연스럽게 들리도록 하려고 묵음 구간을 추가함으로써 가상 사용자가 실제 사람이 말할 때처럼 '호흡하느라 잠시 쉬어가며' 말하도록 했습니다.

예를 들어 사용자가 I/O에서 입을 옷에 대해 물어볼 때 다음과 같이 답변하도록 디자인했습니다.

각 프롬프트에 대해 여러 가지 조건을 고려했다는 점에 유의하세요. 또한 사용자가 한 눈에 내용을 파악할 수 있도록 가급적 내용을 압축해서 표현했습니다. 덕분에 다중 모달 대화로 디자인을 확장할 시점이 되었을 때, 음성 프롬프트를 쉽게 재사용할 수 있었습니다.

일정 찾아보기 사용 사례의 경우, I/O ’17 액션용으로 빌드된 흐름을 확장하여 사용자가 세션 시간도 찾아보도록 할 수 있었습니다. 또한 더욱 스마트한 찾아보기 환경을 제공하여 I/O 이전, 도중, 이후에 변화하는 사용자의 요구를 충족시키겠다는 더 어려운 과제에도 도전했습니다. 예를 들어 이벤트가 열리기 전에 사용자에게 모든 옵션을 제시하고 싶을지 모릅니다. 하지만 이벤트 도중에는 당일 진행될 세션만 제시함으로써 사용자가 당일 세션 목록을 모두 확인해야만 다음날의 세션을 찾아볼 수 있도록 하고 싶을 수도 있을 것입니다.

사용자가 어시스턴트와 상호 작용하는 데 사용하는 기기에 화면이 있는지 여부에 따라서도 대화 환경을 적절히 조정했습니다. 사용자가 Google Home과 대화하고 있다면 사용자에게 지나치게 많은 옵션을 제시하지 않도록 대화 프롬프트에 (총 17개 중) 임의로 6개 항목만 표시합니다. 사용자가 휴대폰을 사용하고 있다면 화면을 활용해 17개 항목을 전부 사전순으로 표시합니다. 다양한 프롬프트를 활용하고 표준어 대신 준말과 같이 좀 더 자연스러운 음성을 사용한다는 점에도 주목해 보세요. 디자인 단계에서는 한껏 큰 야심을 품기도 했지만, 구현 단계에서는 일정 부분 절충하고 타협해야 했습니다. 하지만 어떤 상황에서도 사용자가 충분히 납득할 수 있는 수준으로 만들었습니다.

길 안내를 받고 자신의 일정을 찾아보는 사용 사례는 주로 구현에 종속되었으므로, 이 단계에서는 밑그림을 그리기 어려웠습니다. Android IOSched 앱(Android에서 사용자를 위해 공개하기로 결정한 경우)과 스케줄링 백엔드에 의존적인 부분도 있었습니다. 어시스턴트용 Google 로그인이 프리뷰 버전으로 제공되고 있었지만, 이 액션에는 사용할 수 없었습니다. 이런 요소가 더 명확해질 때까지는 대화에서 이 부분을 열린 상태로 두었습니다.

골격이 제법 그럴듯하게 갖춰졌다는 생각이 들자, 나머지 세부적인 부분을 디자인할 때라고 판단했습니다. 즉, 뭔가 잘못될 수 있는 사례를 최대한 많이 다루어야 하는 시점이었다는 뜻입니다. 아마 상상하실 수 있듯이, 문제가 무척 복잡해졌습니다. 여러 가지 논리적 결정 지점, 오류 및 거부 처리, 메뉴 내부의 메뉴 등등 복잡한 디자인 문제가 남아 있습니다. 알 수 없는 답변(또는 대체 답변), 거부, 허용, 시스템 장애 등을 포함한 모든 프롬프트에 대한 모든 사용자 반응을 고려했습니다. 뿐만 아니라, 스마트 스피커부터 휴대폰까지 각각의 어시스턴트 표면에 알맞게 각각의 대화 경로와 프롬프트를 맞춤 제작해야 했습니다. 우리는 사용자가 전에 경험한 적이 있는 것과 유사한 결정 지점에 와 있음을 알아차릴 경우, 주어진 대화 상태로 '재진입'하기 위한 특정 프롬프트를 만들었습니다. 한 올 한 올 빈틈없이 뜨개질하듯이, 이 모든 과정을 거치며 액션을 만들어야 한다는 점을 기억해 주세요.

액션 전체에 걸쳐 몇 가지 똑같은 패턴을 활용할 수 있었습니다. 예를 들어 오류 처리 전략은 대부분 대화 내내 똑같이 유지했습니다. 보통은 다음과 같이 마지막으로 물어본 질문의 맥락을 기준으로 조정된 변형이었습니다.

TTS에서 알맞게 렌더링되도록 하기 위해 '4 0 4'를 세 개의 숫자로 발음했다는 점에 주목해 주세요. 실용적이고도 직접적인 톤을 유지하면서도 기술과 관련해서는 가벼운 농담을 포함하여, 우리는 오류 프롬프트를 작성할 때도 계속 페르소나를 염두에 두고 작성했습니다.

이때 야심 차고 종합적인 디자인을 계획했습니다. 기술적 종속성을 고려하여 약간의 공간은 남겨두고 의도한 모든 사용 사례와 가능한 한 많은 극단적 사례를 포괄했습니다. 문제는 그걸 실제로 빌드해야 했다는 거죠…

이 게시물의 두 번째 부분도 읽어보시기 바랍니다. 위에서 설명한 모든 것을 어떻게 구현했는지 설명한 글입니다.

회사나 고객에게 효과적으로 Flutter 소개하는 방법을 알려드립니다

Google Play의 64비트 요구 사항에 맞춰 앱을 준비하세요

안전하고 보안이 철저한 사용 환경 제공

Google I/O를 위한 Google 어시스턴트 액션 제작기 (1)

Contents

검색

Tag

Archive

Feed