[Development] The Fallacy Of Android-First

번역원본 Link :  안드로이드-우선 출시의 오류

Emu 라는 앱 개발사 이야기 이다. Home

내장 SMS 앱 기능에 몇 가지 유용한 기능을 더 해서 만든 앱이다.

메세지 마다 부가 메뉴가 있어고, 입력 창에 도 다양한 메뉴가 준비되어 있다.

그래서, 일정등록, 위치 공유, 일정 등록이 쉽다는게 개발사 이야기 이다.

안드로이드 먼저 선보였고, 4월 2일 안드로이드 서비스를 종료하면서, 왜 iOS만 서비스 하는지 잘 이야기 해주고 있다.

Editor’s note: 펠드먼(Dave Feldman)은 Emu의 공동 창업자다. 이전에는 CrunchFund의 Entrepreneur in Residence를 맡았고 2011년 TechCrunch의 디자인 개수를 이끌었으며, Yahoo! Messenger의 디자인팀을 이끌었다. 아이폰용 Emu는 이곳에서 이용 가능하다.

2012년 하순, 우리는 안드로이드용으로 Emu를 먼저 선보이기로 했다. 당시로서는 조류에 반하는 결정이었지만 실제로 이득이 있었다. 그러나 16개월 후, 우리는 다시 iOS로 되돌아왔다. 아이폰용 Emu가 4월 2일에 나왔으며, 여기서 안드로이드가 어째서 우리에게 잘 되지 않았는지, 안드로이드-우선 전략을 결정할 때 어째서 신중하게 고민해야 하는지를 말하겠다.

아이폰용 메시징 앱을 제작하려면, 본질적으로 IM 서비스인 커뮤니케이션 채널을 별도로 만들어야 한다. 하지만 안드로이드에서는 기존의 SMS/MMS를 사용하면서 내장 Messages 앱을 교체하기만 하면 된다. 즉, 커뮤니케이션 서비스를 별도로 만들 수고를 덜 수 있다는 의미다. 게다가 여러분의 사용자들이 자기 친구들을 일부러 초대할 필요가 없다. 언제나처럼 같은 장소에서 메시지를 받기 때문이다. 즉, 여러분 앱을 채택 시키기가 그만큼 더 쉽다. (차이점은 기술적인 한계가 아니다. 애플과 구글의 선택에 따른 차이이기 때문이다. 언제라도 두 회사의 결정은 후에 뒤바뀔 수 있다.)

하지만 안드로이드 사용자들이 앱을 다운로드 받지 않는다는 인식은 어떨까? 그래서 데이터를 봤으며, 그런 현상은 없었다. 안드로이드 사용자들이 유로 앱과 게임, 인-앱 콘텐츠 구매를 덜 하는 것으로 보이기는 하지만, 다운로드 자체는 그들도 왕성하게 하고 있다. 안드로이드는 전세계적으로 사용자가 더 많으며, 미국에서도 설치 기반으로 볼 때 iOS를 추월할 예정이었다. (실제로 그렇게 됐다.) 안드로이드의 UX 또한 개선을 이뤘으며, 몇몇 유명인사들이 아이폰에서 안드로이드로 스마트폰을 바꿨다.

안드로이드 앱이 만들기 더 쉽다는 희망 섞인 루머는 우리도 들었다. 최근 안드로이드 버전의 채택률은 충분히 높아서 하위 호환성을 제한 시키고, 심각한 파편화를 피하면서도 여전히 거대한 사용자를 거느릴 수 있었다. 아이폰 앱에 비해 다수의 안드로이드 앱이 여전히 투박하기는 하지만, Flipboard나 Press와 같은 회사들은 안드로이드에서도 다듬어지고 괜찮은 경험을 보일 수 있다는 점을 보이기 시작했다.

그래서 우리는 선택을 했다. 수 주일 째 작업중이었던 아이폰용 프로토타입을 폐기하고, 예전같지는 않지만 우리의 자바 실력을 동원하여 2013년 2월, 안드로이드용 알파 버전을 만들었으며, 7월에 퍼블릭 베타로 올려 놓았다. 그리고 10월, 우리는 언론의 상당한 호평을 받으며 제품을 선보였다. 특히 우리가 안드로이드 버전을 먼저 선보였기 때문에 칭찬하는 이들도 있었다. 안드로이드 사용자들은 매번 앱이 아이폰용으로 먼저 나오고 안드로이드가 나중에 흥 없이 나오는 광경을 힘들어 하고 있었다.

그리고 4월 2일, 우리는 아이폰용 Emu를 선보였으며, Play Store에서 안드로이드용 Emu를 내렸다. 언젠가 안드로이드로 되돌아 오기를 희망하지만, 우리 팀은 여러 플랫폼을 동시에 지원하면서 혁신하기에 너무 소규모이다. 게다가 우리는 아이폰이 더 나은 곳이라 결론을 내렸다.

• SMS/MMS 상단에 앱을 구축한다는 결정은 예기치 못한 거대한 기술적인 장애요소를 포함했다.


• 제아무리 예전 안드로이드 버전을 지원하지 않는다 하더라도, 파편화는 우리 자원을 심각하게 소모 시키는 요소였다.


• 구글 툴과 문서는 애플보다 불안정하고 후진적(less advanced)이다.


• 안드로이드의 거대한 사용자 규모가 거대한 시장과 동일하지 않다.

SMS & MMS Hurdles

안드로이드용 앱을 먼저 만들기로 한 이유는 안드로이드가 SMS와 MMS에 대한 접근권을 제공하기 때문이었다. 즉, 모든 폰에 내장된 전통적인 문자 메시징 채널에 대한 접근을 할 수 있다는 의미다. SMS/MMS 상단에 앱을 개발함으로써 우리는 채택에 대한 장애물을 줄일 수 있다 여겼다. 물론 우리 생각이 틀리지는 않았지만, 그 비용을 과소평가했었다.

• 안드로이드의 SMS API는 문서화가 잘 안 되어 있으며, 구글이 수시로 내용을 변경한다.


• 안드로이드 4.4 이전의 개별 앱은 서로 SMS를 받는 것을 막을 수 있었다. 다른 앱이 휴대폰의 작동에 영향을 끼칠 수 있다는 의미다.


• MMS(그룹 및 사진 메시징)는 오래 된 프로토콜이며, 여러 통신사들이 나름의 방식으로 별다르게 구현한 프로토콜이기도 하다. 따라서 특정 통신사의 MMS 설정이 필요했다. 예전 안드로이드에서는 MMS를 자동적으로 읽을 수 있었지만, 4.1 이후 버전에서는 불가능해졌다. 그래서 이전까지 본 적이 없던 통신사를 만날 때면, 사용자가 일일이 설정에 들어가서 세부 사항을 우리엑 보내 줘야 했다. 제조업체와 통신사는 안드로이드의 설정 앱을 수정하기 마련이기 때문에, 우리는 사용자가 어디에서 설정을 찾아야 할지 알려줄 수가 없었다.


• 이 문제는 파편화 때문에 더 심각해졌다. 통신사가 안드로이드를 변경하여 자기네 특정 MMS를 지원하기 때문이다. 즉, 간간이 일어나는 버그를 잡기가 어려워졌다. 단순히 고쳐서 해결되는 문제가 아니었다. 버그가 도대체 무엇인지, 어째서 생겨나는지, 혹은 정말 버그인지(통신사나 휴대폰 자체의 문제일 수 있었다) 알 도리가 없었기 때문이다.

곧 우리 제품의 일부를 개발, 디버깅, 테스팅하는 데에 훨씬 더 많은 시간을 들여야 한다는 의미다. 그래 봤자 이미 가지고 있는 제품과 별 차이도 없는데 말이다. 안정적인 SMS/MMS 앱은 그 자체로 별로 흥미로운 존재가 아니다.

또한 2013년에 메시징 앱이 폭발적으로 성장했다 함은, 우리가 채택률에 장애가 없겠다는 예측마저 틀렸다는 사실을 드러낸다. 우리는 올바른 조건 하에서라면, 새로운 서비스를 기꺼이 사용할 사람들이 많으리라 예측했었다. 

SMS와 MMS 상에서 구축하기를 원하는 한, 우리는 안드로이드에 있어야 했다. 안드로이드 버전의 포기가 안드로이드 자체의 포기를 요구하지는 않았지만, 아이폰에 대한 생각은 분명 바뀌었다.

Fragmentation

안드로이드의 파편화는 논쟁적인 주제이다. 수 개월 전에 관련 주제로 블로그 글을 올렸을 때, 그렇지 않다거나 적대적인 반응을 둘 다 받았었기 때문에, 우리 경험에 근거한 사례를 두 가지 알려 드리겠다.

• 삼성 갤럭시 S4의 멀티-윈도 기능을 켤 경우, 키보드로 Emu의 팝업창이 깨진다. 구글이 판매한 갤럭시 S4에서는 이런 현상이 일어나지 않는다. 구글이 판매하는 갤럭시 S4에는 삼성이 개조한 소프트웨어가 없기 때문이다. 갤럭시 S3의 멀티-윈도 기능에서도 괜찮다. 그래서 조사를 해 봤자. 하지만 삼성만의 기능에 해당하기 때문에 삼성과의 직접적인 협력이 없는 한 고칠 수 없을 듯 하다.


• Pandora를 들으면서 Emu의 알림음이 뜰 때, 갤럭시 넥서스폰의 일부에서 Pandora의 볼륨이 줄어든다. 다른 앱의 알림음에서는 일어나지 않는 현상이고, Pandora 외의 다른 스트리밍 앱에서도 일어나지 않는 현상이었다. 다른 휴대폰에서도 마찬가지다.

안드로이드 기준으로 봐서도 우리의 하위 호환성은 그리 넓지 않다. 처음부터 우리는 안드로이드 4.0(2011년 가을 출시) 이후만 지원했으며, 더 이상의 파편화를 줄이기 위해 4.0 지원도 없앴다.

하지만 Google Analytics에 따르면, 우리 앱은 10월 이후로 300여 가지 휴대폰에 설치돼 있으며, 같은 휴대폰이라 하더라도 약간씩 다른 "기종"들의 경우(가령 버라이즌의 갤럭시 S4와 AT&T의 갤럭시 S4, 구글에서 직판하는 갤럭시 S4) 적어도 운영체제가 약간씩 다 다름을 염두에 둬야 한다.

반대로 우리의 아이폰 앱 지원은 오로지 iOS 7(2013년 가을 출시) 이후이다. 즉, 아이폰 4, 4S, 5, 5s, 5c에서만 돌아간다는 의미다. 이 경우, 각 아이폰이 모두 같은 OS를 돌리며, 아이폰 5와 아이폰 5s 차이에 영향을 끼치는 버그는 극도로 드물다. 앱이 한 아이폰에서 잘 작동하면, 보통은 다른 다섯 가지 아이폰에서도 잘 작동한다.

파편화 묹는 버그가 많다만의 문제가 아니다. 버그 찾기 및 해결을 위한 이해도의 문제이기도 하다. 우리가 지원하는 모든 안드로이드 기기를 우리도 다 테스트할 수가 없기 때문에, 다른 사례에서는 발생하지 않은 예기치 못한 곳에서의 버그 보고서를 받기 마련이다. 그리고 그때문에 보고가 안 된 버그가 대단히 많다.

체니(Steve Cheney)의 안드로이드-우선 출시가 어째서 미신인가라는 글에서 인용한다. (강조는 필자가 했다.)

그동안 우리의 모든 대화는 안드로이드용 개발과 출시 비용은 iOS의 2-3배라는 단순하지만 힘든 현실을 확인 시켜준다. 여러가지 이유 때문이다. 세련되지 못한 툴, 일반적으로 더 다루기 힘든 API, 더 적인 진보적인 기능, 파편화로 인한 거대한 QA 문제 등이다. iOS 엔지니어 1명이 필요한 자리에, 안드로이드 엔지니어는 실질적으로 2명이 필요하다, 그렇지 않으면 개발 시간도 두 배 더 들어간다.

플랫폼 선호도, 혹은 플랫폼 능력의 문제가 아니다. 제한된 시간과 노력, 자금을 가진 우리들, 특히나 중대한 반복이 어쩔 수 없는 세운 지 얼마 안 된 스타트업이라면 대다수가 부딪혀야 할 질문이기 때문이다.

Tools & Technologies

체니의 글 중, "세련되지 못한 툴"과 "일반적으로 더 다루기 힘든 API"는 우리의 경험과도 같다. Eclipse는 느리고 기능이 과도하며, CPU/RAM 요구량이 거대하다. 구글의 대체품인 Android Studio (IntelliJ에 기반)이 훨씬 더 낫지만 위의 문제점들은 여전하다. 반면 애플의 엑스코드는 완벽하다. 대체로 빠르고 깔끔하며 직관적이고, 엑스코드 5는 이전 버전이 갖고 있던 문제점 대다수를 해결했다.

구글의 API는 애플의 API에 비하면 더 버그가 많다. 예를 들어 보겠다.

• 안드로이드의 내장 JSON 라이브러리에서 성능 문제가 있다. (특이한 일인데, 구글은 JSON 라이브러리를 두 개 갖고 있으며, 안드로이드에 실리지 않은 라이브러리가 훨씬 더 잘 돌아간다.


• 별 거 아니게 보이는 시각적인 변화가 심각한 UI 버그를 만들어내는, 몇몇 텍스트-레이아웃 및 뷰-레이아웃 버그가 있다.


• 뷰에 드롭-섀도를 추가하고 싶다면, 페런트 뷰(parent view)를 우선 재배열 해야 한다.


• 최근까지 구글맵을 스크롤링 뷰에 집어 넣으면 심각한 화면-재작성 문제가 발생했다.

Until recently, putting a Google Map in a scrolling view resulted in this.

구글 문서는 애플 문서보다 훨씬 더 검색이 쉽지만, 혼란스럽고 일관성이 없다. 뭔가를 구현할 때, 마지막에 가서야 불가능하다고 넌지시 알려주는 글을 볼 때가 한 두 번이 아니었다. 종종 같은 주제에 대해 상충하는 문서가 있기도 하며, 샘플 앱은 컴파일이 안 된다. 그리고 어느 플랫폼에서건 개발자용 커뮤니티 문서로서 기적이랄 수 있을 Stack Overflow는 안드로이드의 자세한 UI/UX 문제에서 소용이 없어진다.

안드로이드 앱은 또한 iOS보다 컴파일에 훨씬 더 긴 시간이 걸리기 때문에 좀 기다려야 한다. iOS 개발자들이 빠른 테스트를 위해 내장 시뮬레이터를 사용할 때가 종종 있지만, 안드로이드의 내장 시뮬레이터는 시작하는 데에만 수 분이 걸릴 정도로 느리다.

iOS도 물론 완벽함과는 거리가 멀다. 애플의 심사 및 인증 시스템은 악몽이며, 사람이 손수 하는 애플의 앱-검토 시스템은 고통스럽고 특히 문제 해결이나 실험 버전일 경우 제멋대로인 것처럼 보인다. Android Studio의 코드-컴플리션(completion)과 코드-네비게이션 기능이 엑스코드에도 들어오기를 바라고 있으며, (간단한 그래픽이나 스트링, 디멘션, 색상 등) 비-코드 리소스에 대한 안드로이드의 XML-기반 접근은 디자인 관련과 코드 관련을 구분하는 데에 특히 유용하다. 그렇지만 그것만으로 충분하지는 않다.

Target Audience

ComScore에 따르면, 안드로이드는 미국 스마트폰 시장의 52%를, iOS가 41%를 갖고 있으며, 어느 경우에서건 상당한 시장이다. 그러나 안드로이드는 더 크고 자라나고 있는 중이다. 단 새로운 버전의 안드로이드 채택률은 더 느리다. 안드로이드 사용자가 업그레이드를 망설여서가 아니라, 통신사와 제조업체들이 커스터마이징을 할 수 있게 하는 성격을 지녔기 때문이다. 

삼성이나 HTC가 새로운 휴대폰을 출시할 때마다, 그들은 최근 버전의 안드로이드를 입수한 다음, 크고 작은 수정을 해 놓는다. 그러나 구글이 새로운 안드로이드 버전을 출시할 때, 이들은 기존 휴대폰 지원을 위해 다시 그 버전을 수정하지 않는다. 그럴 동기가 없기 때문이다. 즉, 더 새롭고 상대적으로 고급인 안드로이드 휴대폰이 실제로는 예전 안드로이드 버전을 돌리고 있다는 결과가 나온다.

반면 애플은 최신 OS를 담은 휴대폰만을 판매하며, 수 년의 하위 호환성을 유지한다. 구체적으로 얘기하면 아래와 같다.

• 안드로이드 버전으로 2년치(우리의 경우 안드로이드 4.0+이었다)를 만들면, 미국 스마트폰 시장의 40% 가량을 지원할 수 있다. 4.0-4.1 지원을 없애면, 1년치이며, 그경우 지원할 수 있는 시장은 12.5%로 급락한다.


• iOS 7 전용 앱을 만들면 미국 스마트폰 시장의 32% 가량을 지원할 수 있다.

즉, 다른 조건이 같을 때, 전체 시장 기반 크기만으로는 플랫폼 선택의 요소가 될 수 없다는 얘기다.

그렇다고 Emu가 아이폰에서 더 많은 사용자를 끌어 모으리라는 의미도 아니다. 그저 그들이 원하는 경우 우리 앱을 설치할 수 있는 전체 사용자 규모를 나타낼 뿐이기 때문이다. Emu의 플랫폼 이주가 목표 사용자 확보에 어떤 영향을 끼치는지 가정해 볼 수는 있겠지만 가정일 뿐이다. 우리의 아이폰용 버전 출시가 결과를 낼 때 한 번 더 글을 쓸 요량이다. 

안드로이드로 이주했던 해에 안드로이드 버전 먼저 내놓기가 유행이었다. 물론 그렇게 하여 성공한 제품들도 있었지만, 실제 내역을 고려해 볼 때, 처음부터 아이폰만 고집했을 때 어땠을지는 알 수가 없지만, 추측해 보면, (7월이 아닌) 4월에 베타 버전을 선보이고 (10월이 아닌) 8월에 1.0을 선보였을 것이다. 더 적은 시간에 더 많은 기능을 구축했을지도 모른다. 우리의 UX도 더 다듬어지고, 버그고 더 적으면서, 시장도 실질적으로는 더 컸을 것이다. 

스타트업 운영하기는 곧 학습이다. 우리가 배운 큰 교훈이 있으며 더 빨리 배웠으면 좋았을 텐데 말이다... 아마 우리의 경험이 다른 이들이 보다 더 정보가 담긴 결정을 내리도록 도움이 될 것이다. 안드로이드의 융통성과 특정 시장에서의 거대한 강점은 특정 종류의 제품에 있어서 안드로이드가 훨씬 더 나은 플랫폼일 수 있다. 그러나 안드로이드의 길은 험하며 눈을 반짝 뜨고 다녀야 한다.