안녕하세요, 위시켓입니다!
지금처럼 모바일 앱 시장이 빠르게 변화하는 때에, 소비자들이 그저 그런 앱에 만족할 리 없습니다. 구글 플레이에서 불안정하고 느려터진 앱에 대해 유저들이 가장 많이 피드백을 하는 포인트는 “자꾸 앱이 다운된다”와 “안 돌아간다”입니다. 그리고 수많은 사람들이 다운로드 직전까지 갔다가 이런 리플들을 보고 다른 앱을 찾아 나서지요. 냉혹하지만, 이것이 현실입니다.
앱의 성패는 운에 의해 좌우되는 것이 아닙니다. 효과적인 전략을 제때에 취해야만 앱을 성공으로 이끌 수 있습니다. 대박을 치는 앱 개발자들을 보면 소비자들이 사용하는 다양한 종류의 단말기 모두에서 성능과 품질, 안정성이 보장된 앱을 만들며, 그에 따른 효과가 얼마나 엄청난 지를 잘 알고 있습니다.
개발자들이 저지르는 실수의 예를 들자면 한도 끝도 없습니다. 똑같은 앱이라도 여러 단말기에서 다른 방식으로 작동될 수 있다는 점을 간과하는 것은 흔히 저지르는 실수 중 하나지요. 이런 경우는 심지어 운영체제의 버전과 하드웨어가 같은 경우에도 종종 발생합니다.

[그림 1] 앱 테스트 (이미지 출처: Testroid)

올해 1사분기(2014.01.01~2014.03.31)동안 테스트로이드 클라우드로부터 방대한 양의 데이터를 수집해 그 결과를 분석한 자료가 있습니다. 모두 모바일 앱 및 게임 개발자들이 시행한 테스트에 관한 것들인데요.
(테스트로이드 클라우드: 온라인 클라우드 기반 플랫폼. 앱 개발자 스스로가 개발한 앱이 여러 단말기에서 제대로 작동하는 지를 테스트할 수 있음)

위 기간 동안 시행된 테스트는 무려 1,700만건에 달합니다. 288개의 서로 다른 안드로이드 디바이스에 시행되었는데요. 더 정확히 말하자면 인기 있는 모델(예 – 4.2.2, API level 17 Samsung Galaxy S4 GT-i9505)의 경우 여러 버전에서 테스트하더라도 한 건으로 처리되었기 때문에 실제 테스트는 더 많이 시행되었다고 볼 수 있습니다. 가령, Google Nexux 7 ME370T와 같이 Android OS ver. 4.1.2 (API level 16), 4.2.2(API level 17), 4.3(API level 18)을 갖춘 모델은 단일한 운영체제 하에 여러 버전을 탑재하고 있습니다.

테스트는 모두 자동화되어 있습니다. 표준 안드로이드 인스트러멘테이션(Android instrumentation)과 다양한 테스트 자동화 프레임을 이용하기에 가능한 것입니다. 인스트러먼테이션에 익숙하지 않은 앱 개발자들을 위해 기본적인 테스트 자동화에 대한 튜토리얼이 제공됩니다. 또한, 로그와 스크린샷, 성능 분석 등을 통해 문제를 포착하고, 앱 구동 성공률을 계산할 수 있지요.
(비고: 데이터는 앱이 완성된 초기 단계 – APK가 준비된 상태 – 에서부터 수집된 것까지 모두 포함합니다. 개발자가 직면한 문제들을 그대로 담고 있다고 볼 수 있습니다.)

[그림 2] 테스트 관련 통계 자료 (이미지 출처: Testroid)

본 연구는 안드로이드 앱 개발자가 특정 단말기와 관련해서 가장 빈번하게 마주하는 문제들을 파헤치고자 시행되었습니다. 테스트로이드에서 제공하는 288개의 각기 다른 안드로이드 디바이스는 안드로이드 전체 단말기의 거의 대부분을 차지합니다. 조사 범위와 방법에 따른 약간의 오차가 있을 수는 있지만 전세계적으로 사용되고 있는 안드로이드 단말기의 약 92~97%가 이들 288개 중 하나인 것으로 추산되고 있습니다. 이 연구를 통해 개발자의 관점에서 안드로이드 하드웨어와 소프트웨어가 갖는 중요성은 물론 그들이 가장 흔히 일으키는 문제들에 대해서도 살펴볼 것입니다. 그 내용은 소프트웨어적 측면으로 운영체제의 버전과 OEM 커스터마이징, 하드웨어적 측면으로 컴포넌트 레벨(디스플레이, 메모리, 칩셋 등)입니다.
위시켓은 위 내용을 두 번에 걸친 포스팅으로 자세히 안내해드리겠습니다.

Android Software

여러분이 만드는 앱이 바로 소프트웨어지요. 하지만 모바일 디바이스에서는 이외에도 여러 다른 소프트웨어가 들어있습니다. 바로 “다른” 소프트웨어가(엉망으로 만들어진!) 여러분이 만든 앱을 전혀 다른 방식으로 작동하게 만듭니다. 여러분의 앱이 디바이스 내의 다른 소프트웨어에 의해 방해 받지 않고 제대로 작동할 수 있도록 하려면 어떻게 해야 할까요? 앱 개발자들이 가장 자주 겪는 소프트웨어 관련 문제들을 먼저 살펴봅시다.
안드로이드 운영체제는 플랫폼 단편화(Platform fragmentation)를 해서 개발자들과 유저들이 불필요한 어려움을 겪게 만들었다고 비판 받아왔습니다. 그런데 이런 비판이 꼭 정당한 것은 아닙니다. 운영체제 그 자체는 거의 다운되지 않습니다. 앱 개발자들이 이런 상황을 겪는 경우는 거의 없고요. 다운이 일어난다면 그것은 대개 운영체제 자체보다는 거기에 OEM 업데이트나 하드웨어 혹은 다른 요인들이 더해졌기 때문입니다.

[그림 3] 2014년 7월 1일-7일까지 수집한 데이터 (이미지 출처: Google)

모바일 기기 사용자들 사이에서 안드로이드가 엄청난 인기를 구가하고 애플의 iOS에 비해서도 높은 시장 점유율을 점하고 있는 이유는 수십 종류의 OEM과 다양한 가격대 및 디자인을 갖춘 여러 종류의 디바이스에서 구동될 수 있다는 확장성 때문입니다.

운영체제와 플랫폼의 버전

앱 개발자들이 겪는 문제 중에 가장 중요한 요소는 무엇일까요? 가장 큰 문제는 안드로이드 운영체제입니다. 운영체제는 그야말로 개발자들이 사용하는 API와 다양한 디바이스에서 API가 작동되는 방식에 지대한 영향을 미칩니다.
많은 개발자들이 안드로이드가 버전을 바꾸면서 새로운 기능들이 도입되고, 무언가 개선되거나 추가되는 것을 지켜봐 왔습니다. 최근에서야 앱 개발을 시작한 분들이라면 최신 버전에 대해서만 알고 있겠지만, 컵케잌(1.5)이나 도넛(1.6) 버전 시절부터 앱을 개발해오던 분들도 있습니다. 물론 이들은 이제 옛날 얘기가 되어버렸죠.
아래 표는 OS의 여러 버전들이 출시된 날짜 및 테스트 중인 디바이스에 몇몇 버전이 도입되지 않은 이유를 나타내고 있습니다.

[그림 4] 안드로이드 OS의 여러 버전들 데이터 (이미지 출처: Testroid)

거의 대부분의 앱 개발자들이 앱의 호환성을 최대화하기 위해 테스트를 할 때 4.0(아이스크림 샌드위치, API level 14)에서부터 시작합니다. 하지만 정말 호환성을 높이고 싶다면 2.3.3 버전(진저브레드, API 10)부터 시작해서 가장 최근에 나온 킷캣(4.4.4, 곧 Android L로 업그레이드 될 예정)까지 차근차근 테스트를 해보는 것이 좋습니다. 4.0 이전의 버전들도 여전히 많이 사용되고 있기 때문입니다. 당분간은 이 추세가 지속될 것 같고요.

[그림 5] OS 버전에 따른 앱 구동 실패율 (이미지 출처: Testroid)

[참고] 그래프 보는 법
짙은 검정색 선: 해당 집단에서 시행된 앱 테스트가 실패한 비율의 평균(50%)
네모 상자 윗변: 상위 25%
점선의 끝: 최댓값, 최솟값
동그라미: 이상점

아이스크림 샌드위치(4.0.3 ~ 4.0.4)나 젤리빈(4.1.1~4.3), 킷캣(4.4~4.4.2)과 같은 안드로이드 최신 버전 중에서는 단연 아이스크림 샌드위치가 가장 안정적으로 플랫폼을 제공한다고 볼 수 있습니다. OEM 업데이트도 가장 문제를 덜 일으켰고 대부분의 앱들이 API level 15(4.0.3 ~ 4.0.4)에서 잘 작동했기 때문입니다. 젤리빈과 API level 16으로 업데이트를 하더라도 심각한 호환성 문제가 일어나지 않았고, 실패율의 평균 역시 낮은 수준에 머물렀습니다. 그러나 API level 16에서는 많은 문제가 발견되었습니다. 여기에는 물론 이유가 있었지요. 예를 들자면, Vsync와 확장된 알림 기능, 특히 화면 잠금과 화면 회전과 관련한 문제들이 증가했습니다.
API level 17이 되면서 화면 잠금 기능이 개선되었고, 4.2.2 버전까지 지속적으로 안정성을 유지했습니다. 업데이트를 하면서 추가된 대부분의 OEM들은 앱 구동 실패율을 높이는 것을 나타났습니다. 유저들의 입장에서는 새로운 버전이 더 많은 문제를 일으키는 것으로 느껴지는 것입니다.

운영체제에 대한 연구의 주요 내용

• 평균적으로 전체 앱의 23%가 운영체제 버전이 바뀌었을 때 오작동. 오류 발생률의 평균은 아이스크림 샌드위치(1%)에서 가장 적었고, 젤리빈(8%)과 허니컴(8%), 킷캣(21%), 진저브레드(30%) 순. 4분기 데이터(구동 실패율 35%)에 비하면 낮은 편.
• 테스트된 앱의 약 40%는 2 이하의 구 버전에서도 작동. 그보다 더 오래된 버전에서 구동될 확률 약 40%
• 안드로이드 운영체제가 업데이트 되면 50% 이상의 확률로 앱 구동 실패율을 높이는 새로운 문제 발생.
• 100개의 앱 중 임의로 5개를 뽑아 테스트 했을 때 구동 실패율 88%
• 플랫폼 당 테스트 평균 57회 시행. 구 버전들은 최근 버전에 비해 테스트되는 횟수 현저히 떨어짐. 진저브레드 12회, 아이스크림 샌드위치 17회, 젤리빈 58회, 킷캣 95회 순.
• 테스트 1회 당 전체 코딩에서 평균 75%의 버그 감소.

(비고: 테스트 1회는 단일 버전 앱에서 특정한 테스트 스크립트를 1회 시행하는 것.)

팁과 제안

1. 타겟 지역과 상관없이 호환성을 최대화하기 위해서는 가능한 최대한 많은 디바이스에서 실제로 앱을 구동해보는 것을 권합니다. 주요 고객층이 어떤 운영체제 버전을 사용하고 있는지 파악하세요. 전세계적으로 안드로이드 운영체제 버전이 어떻게 사용되고 있는지는 구글 대시보드에서 확인할 수 있습니다.
2. 3.3 이후의 모든 버전은 아직도 널리 사용되고 있습니다. 진저브레드와 아이스크림 샌드위치는 사용자가 전체 안드로이드 유저의 거의 25%를 차지하고 있고, 그 중 상당수는 업데이트를 하지 않기 때문에 이러한 상황은 한동안 계속될 것입니다.
3. 전체 운영체제의 66% 정도에서 구동되는 것으로 만족한다면 킷캣(4.4.x)과 젤리빈(4.1~4.3)을 테스트하는 걸로도(API 16~19) 충분합니다.
4. 앱이 75%의 운영체제에서 구동될 수 있으려면 0.3버전(API level 15)부터 테스트해야 합니다.
5. 다음은 호환성을 높이기 위해 테스트에 활용하기 좋은 디바이스들입니다.

Amazon Kindle Fire D01400 — 2.3.4
HTC Desire HD A9191 — 2.3.5
Huawei Fusion 2 U8665 — 2.3.6
Sony Xperia U ST25i — 2.3.7
Asus Eee Pad Transformer TF101 — 4.0.3
LG Lucid 4G — 4.0.4
HTC One S X520e — 4.1.1
Motorola Droid XYBOARD 10.1 MX617 4.1.2
Acer Iconia B1-A71 — 4.2
BQ Aquaris 5 HD — 4.2.1
HTC One mini M4 — 4.2.2
Samsung Galaxy Note II GT-N7100 — 4.3
LG Google Nexus 5 D821 — 4.4
HTC One M8 — 4.4.2

(비고: 이 디바이스들은 다양한 OEM 커스터마이징이 도입되어 있으며, 특정한 플랫폼 버전을 테스트하기에 좋은 기반을 갖추고 있습니다. 다시 말해, 이 디바이스가 일반적으로 높은 수준의 호환성을 갖추고 있으며 비슷한 디바이스들의 특징을 포괄적으로 담고 있어 대표성이 높습니다.)

OEM 커스터마이징

안드로이드 개발자들이 마주하는 또 하나의 어려움은 바로 오픈소스 프로젝트와 같은 커스터마이징입니다. 따라서 플랫폼 전체가 골칫거리를 안게 되는 경우도 허다하죠. 하위 내용에서는 개발자들이 소위 “단편화”라고 부르는, OEM 차별화에 대해 다루겠습니다.
몇 년 전부터 모든 안드로이드 OEM이 자신만의 독특한 UI 레이어를 구축하기 시작했습니다. 밋밋한 안드로이드에 스킨과 다른 미들웨어들을 입힌 것이죠. 여기서 개발자들을 괴롭히는 단편화가 시작되었다고 해도 과언이 아닐 것입니다. 많은 OEM들이 UI 레이어에 이어서 레거시 소프트웨어(Legacy software)를 도입하기도 했습니다. 이 또한 개발자가 여러 브랜드의 핸드폰에 동일하게 구동되는 앱을 개발하기 힘들게 되어버린 이유지요.
드라이버 역시 심각한 문제를 일으킵니다. 그 중 상당수는 그래픽에 관한 것인데요. 어떤 칩셋의 경우, 그래픽 드라이버를 이상하게 업데이트시켜버리는 바람에 앱과 게임 등에서 볼 수 있는 색상이 디바이스에 따라 다르게 보이기도 합니다. 안드로이드 디바이스마다 다른 색상이 나타나는 것이죠. 때에 따라 의도한 색상과 전혀 다른 색상이 나타나는 경우도 있습니다.

[그림 6] OEM에 따른 앱 구동 실패율 (이미지 출처: Testroid)

[참고] 그래프 보는 법
짙은 검정색 선: 해당 집단에서 시행된 앱 테스트가 실패한 비율의 평균(50%)
네모 상자 윗변: 상위 25%
점선의 끝: 최댓값, 최솟값
동그라미: 이상점

OEM 커스터마이징에 대한 연구의 주요 내용

• 가장 안정적인 것과 가장 문제가 심각한 디바이스들은 모두 삼성 제조. Galaxy Nexus GT-I9250은 모든 측면에서 가장 안정적, Samsung Infuse 4G SGH-I997은 가장 불안정적.
• 샤오미(Xiaomi) 및 아수스(Asus)의 디바이스들이 가장 안정적. 샤오미는 안드로이드 구동 방식에서 차이가 있음.
  예) 특정 디바이스의 경우 팝업이 뜨자 기기 통제 불능
• 쿨패드가 가장 많은 문제들을 일으킨 요인. HTC가 그 중 가장 적은 오류.
• HTC나 삼성, SONY, LG와 같은 메이저 급 브랜드에서 생산된 디바이스는 특정 종류의 앱을 구동하는 데에 문제 소지를 발생하는 커스터마이징 기능 탑재.
  예) SONY의 커스터마이징은 PDF 파일 열람 같은 기본적인 기능 무력화, 삼성의 경우 사진 촬영 및 통화 장애 발생

팁과 제안

1. 개발자들이 가장 많이 오해하는 것은 넥서스(Nexus)의 디바이스가 테스트하기에 최고라는 인식입니다. 넥서스의 디바이스들은 대체로 최신 운영체제 버전을 갖추고 있고 OEM 커스터마이징을 거의 건드리지 않기 때문에 테스트 용으로는 부적합합니다.
2. 특정 이동통신사의 서비스를 통해서만 작동되는 디바이스는 제조사가 같더라도 안드로이드의 구동 방식이 완전히 다를 수 있기 때문에 각별히 신경 써야 합니다.

다른 소프트웨어에 대한 의존성

어떤 앱은 구동되기 위해 다른 앱에 접근하기도 합니다. 실제로 게임과 같은 상당수의 앱이 SNS와 연동되지요. 하지만 모든 디바이스가 다 그런 것은 아니기 때문에 천편일률적인 앱 개발은 심각한 문제를 일으킬 수도 있습니다. 어떤 디바이스는 SNS관련 앱이 기본 앱으로 설치된 채로 출고되지만 그렇지 않은 경우, SNS와 연동되도록 설계되었다면 문제를 일으킬 수 밖에 없습니다. 소프트웨어에 대한 의존성의 문제가 앱 개발자에게도 악영향을 미친다는 것이지요.

다른 소프트웨어에 대한 의존성에 대한 연구의 주요 내용

• 92%의 앱이 광고를 띄우기 위해 플랫폼과 연동
• 65%의 앱이 최소 1개의 SNS 플랫폼과 연동
• 48%의 앱이 최소 2개의 SNS 플랫폼과 연동
• 33%의 앱이 3개 이상의 SNS 플랫폼과 연동

팁과 제안

1. 개발된 앱이 의존하는 소프트웨어가 모든 디바이스에 설치되어 있는 것인지 확인하세요.

안드로이드 개발자들이 흔히 겪는 문제 상황들을 Testroid를 통해 살펴보았는데요. 방대한 양의 데이터와 테스트로부터 도출된 결과를 통해 안드로이드 개발의 소프트웨어적 측면의 문제점들을 알 수 있는 좋은 자료가 되었으면 합니다. 이와 관련된 후속 포스팅으로 안드로이드 개발의 하드웨어적 측면의 문제점들을 다뤄보도록 하겠습니다.

* 본문 내용은 http://www.smashingmagazine.com/2014/10/02/what-every-app-developer-should-know-about-android/ 를 각색한 자료입니다.