 |
안드로이드의 호환성에 대하여 [번역]
출처 : http://android-developers.blogspot.com/2010/05/on-android-compatibility.html
- 오픈 소스 & 호환성 프로그램 매니저인 Dan Morrill의 글
우리는 Google I/O 2010를 통해 ‘현재 60가지 이상의 안드로이드 모델이 나와 있으며,
하루에 십만 대 이상이 팔리고 있다’고 밝힌 바 있다. 오픈 소스에 관련된 사람으로서, 사뭇 신나는 일이다.
내 고향 도시 인구 전체와 맞먹는 사람들이 오픈 소스 소프트웨어를 (아마도 처음으로) 쓰기 시작하는 것이다.
그런데 안드로이드 호환성에 대해 생각해보면, 이러한 숫자는 약과다.
그 많은 폰들이 모두 동일한 애플리케이션들을 공유할 수 있다니…
우리는 Google I/O를 통해 업그레이드되고 확장된 source.android.com 사이트도 런칭했다.
새 버전은 정보를 안드로이드 오픈 소스 프로젝트에 갱신했고,
디바이스 제조업체들을 위한 새로운 팁과 도구들도 제공되었다.
OEM 업계에서 일하는 분들에겐 유용한 정보들이 될 것이다.
이 뿐 아니라 현재, 안드로이드 호환성 프로그램에 관한 상세한 정보도 공개되어 있다.
이 또한 대부분은 OEM 관계자들을 타겟으로 하지만, Tim Bray는 어떻게 매일 십만 대에 이르는 디바이스들이
보조를 맞추어 행진할 수 있는지 개발자들도 살짝 알고싶어할 것이라고 귀뜸해주었다.
그래서 여기, 블로그를 통해 그 이야기를 하고자 한다.
F-word 또는 11월 5일을 기억하라.
(F-word란 원래 F로 시작하는 그 비속어를 의미 - 역자 주)
2007년 11월 5일, 필자는 동료들과 함께 컨퍼런스룸 44번 빌딩에 앉아,
Andy Rubin과 Eric Schmidt가 안드로이드를 세상에 발표하는 것을 듣던 그날을 기억한다.
이와 관련하여 언론에서 많은 얘기들이 쏟아져 나온 것도 기억한다.
예를 들면, 안드로이드는 “그냥 탁상공론”이라는 말도 있었다.
일주일 후면 최초의 SDK 초기 버전이 런칭될 준비가 되어 있음을 알고 있던 필자로서, 그런 기사를 보니 좀 우스웠다.
필자가 기억하는 또 다른 화두는… 그렇지, ‘파편화(fragmentation)’였다.
문자 그대로 우리가 안드로이드를 발표한 그 날 업무 시간이 끝나기도 전에 (정확히 말하면 오후 4시 46분에),
안드로이드의 ‘파편화’ 문제를 다루는 첫 번째 기사를 보았다. 발표 하루도 안 지났는데
언론은 안드로이드가 ‘파편화’ 문제를 가질 거라고 이미 판단을 내렸던 모양이다.
문제는, 아무도 ‘파편화’라는 용어를 명확히 정의하지 않았다는 것이다.
아니, 그보다는, 저마다 다른 정의를 내리고 있다는 것이다. 어떤 사람들은 단편화라는 용어를 쓸 때
너무 많은 모바일 운영체제를 가리키기도 하고, 혹자는 선택적인 API들이 플랫폼 구현에 있어서
불일치를 초래하는 점을 의미하기도 한다. 또 어떤 사람은 “차단된” 디바이스들을 지칭하거나,
동시에 여러 버전의 소프트웨어가 공존하는 것을 가리키기도 한다.
심지어는 상이한 UI 스킨들이 있는 것을 파편화라고 부르는 사람도 봤다.
그러나 이러한 정의들 대부분은 애플리케이션이 실행되는 데 아무런 영향을 끼치지 않는다.
파편화라는 용어가 너무 많은 것을 의미하므로, 실제로는 아무 것도 정확히 의미하지 않고,
따라서 쓸모 없는 말이다. ‘파편화’에 대한 이야기는 드라마틱하게 들리고 전문가인 양 하는 사람들의 블로그에
트래픽만 증가시켜줄 뿐, 실제 문제 해결과는 별 상관이 없다.
‘파편화’는 주의만 산만하게 하고 신참 개발자들 겁줄 때나 쓸 만한 하품 나는 얘기인 것이다.
호환성
안드로이드 디바이스들이 서로 간에 호환성을 갖추는 데에 아무런 어려움이 없다는 말이 아니다.
또한 애플리케이션 개발자들이 뜬눈으로 밤을 새도록 만드는 실제적인 문제가 없다는 말도 아니다.
분명히 그러한 문제가 존재하며, 필자 역시 이 문제를 고민하고 해결하느라 많은 시간을 보낸다.
문제는 용어에 대한 명확한 정의를 내려야 한다는 것이다.
우리는 ‘안드로이드의 호환성’을 ‘안드로이드 SDK로 작성된 애플리케이션들이 특정 디바이스에서
올바로 실행될 수 있는 능력’이라고 정의한다.
사실 이 정의는 그 의미하는 바를 다 아우르기에는 너무나 간단한 표현이다.
예를 들어, 아래와 같이 잘못될 가능성이 있는 많은 문제들이 잠재하기 때문이다:
버그들 - 디바이스들에 버그가 있을 수 있다. 예를 들면, 블루투스 드라이버에 버그가 있거나 GPS
API가 부정확하게 구현되어 있을 수도 있다.
필요한 컴포넌트의 누락 - 디바이스에 애플리케이션들이 있으리라 기대하는 (예를 들면 카메라와 같은)
하드웨어들이 없고, 마치 존재하는 것처럼 ‘눈속임’ 하거나, 해당 API를 스텁stub 처리만 했을 수도 있다.
추가되거나 변경된 API - 디바이스에 표준 안드로이드가 아닌 API를 더했거나 변경했을 수도 있다.
제대로 했다면 혁신이 될 수도 있지만, 엉성하게 했을 경우 ‘포용embrace과 확장extend’이 될 것이다
(원래 J. Allard가 제안한 ‘embrace, extend then innovate’ 전략에 빗대면서도, MS사의
‘Embrace, extend and extinguish(포용, 확장, 멸절)’과 같이 나쁜 선례가 될 수 있음을 암시하는 말. - 역자 주).
위에 언급한 일이 벌어지면 애플리케이션이 디바이스에서 제대로 동작할 수 없다.
실행은 될지 모르지만 올바르게 동작하지는 못할 것이다.
필자도 바로 이런 문제를 예방하기 위해 씨름하며 시간을 보낸다.
어떻게 호환성을 얻는가?
플랫폼을 책임지고 관리하는 입장에서, 우리는 호환성 있는 디바이스들만 안드로이드 에코시스템에
참여하도록 하는 것이 매우 중요하다는 사실을 깨달았다. 그래서 안드로이드 마켓에 접근하고 안드로이드라는
이름을 사용할 권한을 갖기 위해서는 반드시 호환성을 갖추는 것을 전제 조건으로 하고 있다.
즉, 개발자들은 (안드로이드 에코 시스템의 주축을 이루는) 안드로이드 마켓에서 그들의 애플리케이션이
호환성 있는 기기들에서만 실행된다는 사실을 신뢰할 수 있다는 뜻이다.
단일한 애플리케이션 에코시스템이 여러 소규모 에코 시스템보다 낫다는 사실은 자명하기 때문에,
일반적으로 OEM들도 호환성 있는 기기를 만들고자 하는 동기부여가 되어 있다.
그러나 동기부여가 되어있는 것만으로는 별 소용이 없다. 실제로 호환성을 보장해줄 도구가 필요하다.
바로 이 점이 안드로이드 호환성 프로그램이 등장하게 된 이유이다.
이 프로그램은 삼발이 의자에 비유할 수 있다:
다리 하나는 안드로이드 소스 코드, 하나는 호환성 정의 문서 (CDD), 하나는 호환성 테스트 슈트(CTS)인 것이다.
모든 것은 안드로이드 소스 코드에서 시작된다. 안드로이드는 스펙이 아니며,
전통적인 리눅스 개념에서의 배포도 아니다. 그렇다고 교체 가능한 컴포넌트들의 집합도 아니다.
안드로이드는 여러분이 특정 디바이스에 포팅하는 소프트웨어 덩어리이다.
대체로, 안드로이드 디바이스들은 동일한 코드를 실행시키고 있다.
모든 안드로이드 디바이스들이 동일한 코어 안드로이드 코드를 사용한다는 사실 때문에,
디바이스들이 모두 동일한 방식으로 동작하도록 보장하는 데 큰 도움이 된다.
그러나, 이 점이 컴포넌트가 누락되거나 변경된 API의 문제까지 해결해주지는 못한다.
소스 코드는 언제나 이렇게 저렇게 변경될 수 있기 때문이다. 이 때문에 호환성 정의 문서(CDD)가 필요하다.
CDD는 안드로이드 디바이스들에게 기대되는 것이 무엇인지, 시시콜콜 아주 상세하게 정의한다.
예를 들면, 디바이스들이 대부분의 컴포넌트를 생략할 수 없다고 명시하고,
또한 공식 안드로이드 API를 변경해서는 안 된다고 못박고 있다.
한마디로, CDD는 안드로이드 디바이스들에 대한 요구들을 모호함을 없애고 명확히 하기 위해 존재한다.
물론, 아무리 이런 장치들을 동원해도 사람의 실수(즉, 버그들)를 막을 수는 없다.
그래서 호환성 테스트 슈트(CTS)가 필요하다. CTS는 알려진 이슈들에 대한 2만 개가 넘는 테스트
케이스의 집합이며, 이들로 안드로이드 디바이스를 체크한다. 디바이스 제조사는 개발 프로세스 내내
자신들의 디바이스에서 CTS를 실행하여, 가능한 한 초기 단계부터 버그를 확인하고 수정하는 데 활용한다.
이렇게 하여 최종 출시를 위한 빌드 때는 가능한 한 버그 없는 상태가 되게 한다.
시간이 지나도 호환성을 유지하는 방법
우리는 OEM 파트너들과 이러한 호환성 프로세스를 일년 넘게 진행해왔다. 그리고 대체로 이 프로세스를 통해,
60여 디바이스 모델들의 상호 호환성을 확보한다. 그러나 완벽한 프로세스도 없고,
100% 커버하는 테스트 슈트도 없다. 게다가 이따금씩 버그도 발견하게 된다. 그렇다면 어떻게 해야 할까?
우리는 OEM 파트너들과 아주 좋은 관계를 유지하고 있으며, 앞서도 언급했듯이 OEM 업체들 역시
호환성을 확보하기를 간절히 원한다. 애플리케이션에 영향을 끼치는 심각한 버그를 발견할 때마다
우리는 파트너 업체들에게 알린다. 그러면 업체들은 보통, 버그를 수정한 버전을 릴리스하여
최종 사용자들에게 제공한다. 우리 쪽에서도 향후의 디바이스들을 위해, 발견된 그 문제를 캐치하도록
CTS에 관련 테스트 케이스를 추가한다. 이것은 완성되기 위해서는 아직도 진행 중에 있는 프로세스이지만,
파트너 업체들도 우리만큼이나 자기들이 파는 디바이스에서 사용자들이 만족스런 경험을 하는지
많은 관심을 갖고 있다.
오늘날의 모바일 업계는 “엄청나게 흥미진진”하며, 이는 또한 “고통스러울 정도로 빨리 변한다”는 것을
의미한다. 우리는 안드로이드의 성공을 위해서는 그러한 변화에 발맞추어야 하고,
더 나아가 궁극적으로는 그 변화를 주도해야 한다고 믿는다. 이는 시간이 흐름에 따라 CDD도
변해야 함을 의미한다. 우리는 새로이 발견하는 문제 케이스들마다 그에 해당하는 테스트들을
새로 추가할 것이고, 현장에서 일어나는 혁신들을 수용하기 위해 실제적인 요구사항들도 변경될 것이다.
예를 들면, 2.1/Eclair CDD에서 우리는 텔레포니 기능이 선택사항(이전에는 필수사항이었음 - 역자 주)이 되도록
CDD를 살짝 변경하였다. 이로 인해 폰이 아닌 이동 기기들에도 안드로이드를 호환성 있게 탑재할 수 있게 되었다.
물론 이렇게 변경이 이루어질 때마다 안드로이드 API와 안드로이드 마켓에도 그에 따른 수정을 하여
여러분의 애플리케이션들이 나쁜 영향을 받지 않도록 조치할 것이다.
약간 관련성 있는 어떤 기록에 보니, 동시에 여러 버전의 안드로이드가 사용자들의 손에 나가 있다는
사실에 대해 언급한 것들이 아주 많았다. 최신 소프트웨어가 없는 디바이스는 최신 애플리케이션들을
다 실행시킬 수 없는 게 사실이지만, 안드로이드는 100% 포워드forward 호환성을 갖춘다.
즉, 이전 버전에서 올바로 작성된 애플리케이션이라면 최신 버전에서도 잘 실행된다.
화려한 첨단 기능을 자랑하기 위해 유혈 낭자한 최일선에 서느냐,
아니면 최대한 많은 사용자 층을 확보하기 위해 오래된 버전에 머무느냐의 선택은
애플리케이션 개발자들의 손에 달렸다. 그리고 모바일 업계가 업그레이드 가능한 폰 소프트웨어 개념에
점점 익숙해지고 있으므로, 장기적으로 본다면, 보다 많은 디바이스들이 업그레이드될 것이다.
당신에게는 어떤 의미가 있는가?
다 좋은 얘기들이다. 그러나 이러한 논의가 개발자들에게는 어떤 의미가 있는가?
이에 대한 설명을 위해 SDK 문서 한 페이지에 정리해 두었으니 참조하기 바라며,
간단하게 요약하자면 다음과 같다:
- 개발자로서, 여러분의 애플리케이션이 어떤 기능을 요구하는지 판단하고 그 필요 기능들을 해당 애플리케이션의 AndroidManifest.xml에 나열하라.
- 안드로이드 호환성 프로그램을 사용하면 호환성 있는 디바이스들만 안드로이드 마켓에 접근할 수 있도록 보장해준다.
- 안드로이드 마켓은 위에 리스트된 기능들이 없는 디바이스들은 필터링을 통해 배제함으로써, 여러분의 애플리케이션이 올바로 실행될 디바이스들에게만 보이게 해준다.
이제 다 얘기했다!
십중팔구 여러분이 애플리케이션을 작성할 때 염두에 두지 않았던 디바이스들이
안드로이드 마켓에 접근할 것이다. 그러나 이것은 매우 좋은 일이다.
여러분이 만든 애플리케이션의 잠재적인 사용자가 증가하기 때문이다.
여러분이 애플리케이션의 요구사항만 정확히 리스트업 한다면, 나머지는 우리가 처리하여,
부적절한 디바이스들은 여러분의 애플리케이션에 접근할 수 없도록 할 것이다.
결국 우리도 애플리케이션 개발자들이고, 애플리케이션들이 의도하지 않은 디바이스에 올라가
제대로 돌아가지 않는다고 사용자들의 원성을 살 때, 이에 응대하는 것이 얼마나 고통스러운 일인지
우리 자신이 잘 알고 있다.
우리의 현 솔루션이 완벽하다고 말하는 것은 아니다. 완벽한 솔루션은 어디에도 없다.
그러나 우리는 안드로이드 개발자로서의 여러분의 삶이 보다 편해질 수 있도록,
SDK 툴과 안드로이드 마켓 개선을 위해 끊임없이 노력하고 있다. 최신 정보를 얻도록 계속해서
이 블로그와 안드로이드 마켓을 주시하길 바란다.
끝까지 읽어주셔서 감사하며, 즐거운 코딩 되시길!
 |
※ 회원등급 레벨 0 이상 읽기가 가능한 게시판입니다.
11
|
안드로이드의 호환성에 대하여 - 송경희
들풀
타락한수녀
