※ Daum 소규모 지인 위주의 카페에 안드로이드 초기 느낀 점을 지인들과 공유하기 위해서 적은 글인데 어딘가 따로 정리가 필요해서 블로그로 복사합니다.
오늘은 안드로이드에서 약간 벗어나서 플랫폼 일반론에 대해서 얘기할까 합니다.
물론 안드로이가 빠지면 재미가 없기 때문에 당연히 언급이 있겠습니다만…
1990년대 후반 Qualcomm source base로 UI를 구성하던 시절에는 swich문과 state 변수에 의존한 소위 state machine으로 사용자 동작 시나리오에 대응했습니다.
예를들면 메시지를 수신하고 그 번호로 바로 통화키를 눌러서 전화통화를 하는데 다른 메시지가 다시 수신되면 메시지 관련 기능이 2번 수행되어야 하므로 re-entrance 개념이 없던 state machine에서는 앞선 메시지 수신 상태를 삭제하고
다시 메시지를 처리하는 식으로 사용자 편의성과는 상관 없는 기술적 한계에 의한 시나리오 대응이 되던 시절입니다.
이런 제약 때문에 전화 수신/발신 기능이 동작하면 state machine을 초기화하는데 메시지 작성 중에 전화가 수신되면 작성중이던 메시지가 아무런 경고도 없이 취소되는 어이없는 시나리오가 당연시 되던 상황이었죠.
물론 상품기획이나 고객들로부터 무수한 클레임으로 일부 제한적인 부분은 보완이 되었지만 Case by Case로 대응하는데 한계를 느낀 제조사들이 욕심을 내기 시작하는 것이 노키아와 같은 플랫폼을 가지고 싶어하는 것이었습니다.
그 당시 노키아의 성공 비결은 재사용성이 높은 S/W이고 그 기반에는 플랫폼이 있다고 생각했던 것이죠.
일정 부분 맞기도 하지만 여러가지 복합적인 요인으로 인해 노키아이기 때문에 가능했던 부분인데 플랫폼에 대한 막연한 기대를 하는 국내 제조사들이 간과하던 부분이었죠…
자의반 타의반으로 여기 저기 제조사를 떠돌면서 여러 플랫폼을 경험했고 플랫폼의 최종 모습으로 보이는 안드로이드까지 경험하면서 나름대로 크게 분류하자면 다음과 같습니다.
1.Code Share
국내 제조사들이 플랫폼 개발 초기에 중점적으로 가치를 두었던 부분입니다.
state machine 기반으로는 SW 재사용성이 상당히 낮은 상황에서 가장 중요하게 보였던 부분이죠.
LCD가 변경되고 MSM이 변경되고 부가적인 HW가 변경되더라도 Code를 최대한 재활용하고자 하는 목적으로 초기 플랫폼이 설계되기 시작했습니다.
2.Application Share
Application Share와 Code Share를 명확하게 구분하기는 쉽지 않습니다.
application share의 경우에는 특정 기능을 하는 application이 유일하게 1개가 존재하고 특정 기능을 수행하기 위해서는 해당 application을 구동하고 결과 값을 받아서 처리하는 개념입니다.
개념은 단순하지만 application간의 데이터 교환 방식 표준을 규정하는 것이 쉽지 않고 일반적인 플랫폼은 Windows의 Message 개념 또는 Event 개념으로 동작하다 보니 Dedicate된 자료구조를 사용하게 되고 application share가 어려워지는 악순환이 시작됩니다.
제조사들은 플랫폼 초기 설계시에 아이폰의 App Store 개념을 도입하여 시장 문제를 단말 SW 전체가 아닌 일부 application upgrade로 해결하고자 많은 노력을 했지만 개발 과정에서 발생하는 application간의 dependency 문제를 해결하지 못하여 결과적으로 application share가 아닌 code share 개념으로 변질되는 경우가 대부분입니다.
3.Data Share
대표적인 Data Share 플랫폼이 WIPI 입니다.
WIPI는 application share 개념으로 이해하기 쉽습니다만 실제로는 그렇지 않습니다.
예를들어 WIPI내에 전화번호부가 존재한다고 했을 때에 이 전화번호부를 통해서 전화 번호 등을 비롯한 전화번호부 정보를 획득하여 동작하는 것이 application share 개념이라면, Data Share는 각각의 application이 공통된 공간에 data를 저장하고 application이 필요할 때마다 data를 직접 검색/가공하는 방식을 의미합니다.
WIPI 플랫폼이 Terminal Resource가 방대한 이유가 Data Share 개념 때문이라고 볼 수 있습니다.
WIPI application은 전화부, 메시지, 사진 등의 정보가 필요하면 목록을 직접 얻어가서 각 application별로 UI를 구성하게 되고 전체적으로 일관된 UI를 가지지 못하다 보니 일반적인 플랫폼으로 인정받지 못하고 천대받았던 것이 아닌가 싶습니다.
4.Screen Share
안드로이드가 나오기 전까지는 전혀 상상하지 못했던 개념이고 획기적인 기능입니다.
안드로이드는 Application 구성을 화면 단위로 구현하는데 이를 “Activity”라고 부릅니다.
아래 그림을 보면 APK Package라고 되어 있는 부분이 우리가 흔히 말하는 application인데, “Task”라는 주황색 Box로 2개의 application에 걸쳐서 Activity 집합이 구성되는데 이것이 실제 안드로이드에서 동작하는 시나리오입니다.
안드로이드는 OOP기반의 Java 언어로 구현되기 때문에 각각의 Activity가 완벽하게 독립되고 Framework에서 application dependency가 연결될 수 없도록 구조를 제한하기 때문에 하나의 application에서 다른 application의 화면(“기능”)을 가져다가 쓸 수 있습니다.
위에서 언급한 전화번호부를 동일하게 적용해보면 왼쪽에 있는 application이 전화부를 사용하는 기능이고 오른쪽이 전화번호부 application이라면 전화부 사용이 필요할 때 전화번호부 application의 “사용자 검색 화면” 또는 “전화번호 검색 화면”을 이용해서 검색을 진행하거나 “전화부 명단 목록 화면”을 이용해서 전화부라는 UI에 일관성을 유지한 상태에서 application이 전화부 기능을 구현하지 않고 동일한 기능을 사용할 수 있게 되는 것입니다.
본의 아니게 플랫폼 일반론을 얘기하려다가 다시 안드로이드로 귀결되었네요…
