Android에 대한 小考(소고) – 플랫폼

※ 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이 전화부 기능을 구현하지 않고 동일한 기능을 사용할 수 있게 되는 것입니다.

Activity
Activity

본의 아니게 플랫폼 일반론을 얘기하려다가 다시 안드로이드로 귀결되었네요…

Android에 대한 小考(소고) – 구글의 사악성

※ Daum 소규모 지인 위주의 카페에 안드로이드 초기 느낀 점을 지인들과 공유하기 위해서 적은 글인데 어딘가 따로 정리가 필요해서 블로그로 복사합니다.

제가 유명한 컬럼니스트도 아니고 제목이 좀 자극적이어서 상당히 부담이 되는 부분이기는 합니다만 이건 낚시질을 위한 제목이 아니고 일부 인터넷에서 오고가는 얘기를 인용하다보니 제목이 극단적이 되었습니다.

결론은 구글이 사악하다는 것이 아니고 사악하지 않은 척 하지만 그 뒷면에 많은 어두운 면이 있다는 것입니다.

Google 검색 서비스 초기에 광고없는 검색 창 하나만 달랑 보이는 페이지를 보면서 어느 대학에서 학생들이 연구용으로 만들어 놓은 페이지인가 하면서 종종 사용하기 시작했습니다.

Google Toolbar가 없는 IE는 어쩐지 허전해서 꼭 설치하고 PC를 사용해야 직성이 풀리고 회사 PC에는 Google Desktop을 설치해서 메일/문서를 찾을 때도 Google을 사용하고 구글 Mail, Google Doc, Google Groups, Piccasa Web, … 제가 실제로 사용하는 서비스들 입니다. 검색 결과가 탁월하고 속도가 빨라서 이용하기 시작했는데 지금 돌아보니 어느덧 ‘구글러’가 되어 있네요…

‘구글러’, ‘구글링’이라는 유행어를 만들어내고 사람들이 스스로를 구글에 연관시키는 부분은 대단하다고 할 수 있겠습니다.
구글의 다양한 Web 기반 service들은 구글이 애써서 굳이 뒷문으로 정보를 빼돌리지 않아도 사용자 스스로가 개인 정보를 알아서 바치는 형태를 만들어내는 구글의 고도의 전략일 수도 있습니다.

FSF(Free Software Foundation, 자유 소프트웨어 재단)을 설립한 리처드 스톨만이 언급한 “덫”에 대한 이야기
“웹 기반 소프트웨어를 사용하지 말라. 그렇게 하는 건 자신의 통제권을 잃는 일이다. 당신의 컴퓨터에 자유 소프트웨어를 설치해 당신만의 컴퓨팅을 하라. 독점 소프트웨어를 사용하는 것만큼 나쁜 것 웹기반 소프트웨어다. 당신이 독점 소프트웨어나 다른 누군가의 웹 서버에 있는 소프트웨어를 이용한다는 당신은 자신을 방어할 아무런 힘도 없게된다. 누가 됐든 그 소프트웨어를 만든 사람의 손아귀에서 벗어날 수 없기 때문이다.”

1.구글의 Goal – Gateway
어느 세미나를 갔더니 Google이 검색에 집중한 이유가 Web의 Gateway라서 그렇다고 합니다. (모든 길은 로마로 통한다는 문구가 문득 떠오르네요)
NHN을 비롯한 우리나라 회사들이 컨텐츠를 집중하는 포털에 집중한데 반해서 전혀 새로운 시도로 아무도 예상하지 못했던 성공을 거둔 Google인데, Mobile에서의 Gateway를 플랫폼이라고 생각했고 ‘Android’가 탄생한 배경이라고 합니다.

현재 구글에서는 막대한 비용이 투입된 Android로 어떻게 돈을 벌겠다라는 계획을 내놓지 않고 있습니다. 막연하게 Mobile이 활성화가 되면 검색을 비롯한 Web Access 기회가 많아져서 기존 구글 사업에 이득이 될 것이라는 막연한 얘기만을 하고 있는 상황이죠.

제가 순진한 학생이라면 이런 말을 믿겠지만 수익성을 확보해야 하는 기업이 하는 말이라 진정성에 의문을 가지게 됩니다.
경영진이나 주주들에게는 어떤 식으로 설득했을까???

애플에서 공전의 히트를 기록한 App Store를 따라하는 후발주자 이면서 Open Market에서 수수료 정도의 수익만 떼고 개발자와 사업자에게 모두 떼어주는 전략은 구글 체크아웃이라는 사업이 성장할 수 있는 기반이기 때문에 그 나마 속이 보이는 상황입니다만, 도대체 그 정체를 알 수 없는 기업입니다.

2.안드로이드 Kill Switch
아이폰에는 백도어가 있어 애플이 자사가 인증하지 않은 애플리케이션을 원격으로 삭제할 수도 있습니다. 안드로이드는 초기 플랫폼에서는 없던 이 기능이 2008년 후반에 공식적(?)으로 지원되기 시작했습니다.

안드로이드 Open Market 컨텐츠에 대해서 다운로드 받은 컨텐츠에 대해서 인증을 하지 않기 때문에 악성 SW가 등록될 가능성이 많고 이를 위해서 기능이 필요악일 수도 있죠.

원래 목적이 Open Market에서 구매한 컨텐츠에 대해서 환불요청을 하는 경우에 사용자가 컨텐츠를 삭제할 것을 기대하지 않고 원격으로 해당 컨텐츠를 삭제하는 것이죠. (어찌 보면 당연하고 편리할 수 있는 기능입니다만…)
우려하는 것은 Kill Switch가 구글이 마음 먹기에 따라서 Big Brother 역할을 수행할 수 있다는 것입니다.

3.책임지지 않는 구글
안드로이드 관련 프로젝트를 진행하게 되면 상당히 많은 장애물을 만나게 되는데 그 때마다 도달하는 결론이 있습니다.
안드로이드의 이면에는 구글이 책임지지 않는 것이 포함되어 있다는 것이죠.

① Open Market
구글이 수익성을 직접적으로 확보하지 않는 대신에 컨텐츠 인증 등의 절차를 없애 모든 이슈를 사용자 간의 문제로 만들었다는 것입니다.
문제가 발생해도 구글은 어떠한 책임도 지지 않는 구조라는 것이죠.

② Logo 테스트
MS의 로고 테스트는 인증의 개념에서 접근하지만 구글의 로고 테스트는 제휴 및 서비스 개념으로 접근합니다.
안드로이드 단말 테스트를 요청하면 테스트는 해주지만 FAIL 항목이 있다고 출시가 안되는 것도 아니고 그렇다고 구글의 로고가 호환성이나 안정성을 담보하는 것이 아니라는 의미로 결론은 구글이 책임지지 않는 다는 것입니다.

③ License
안드로이드는 GPL2, Apache2, … 등의 아주 복잡한 License가 얽혀 있습니다.

그 중에서도 Java license는 아주 복잡하고 미묘한 구조로 되어 있습니다.
Java는 개발 중에는 license가 적용되지 않지만 상용화하는 순간에 license가 적용됩니다.
안드로이드 개발 과정에는 Sun의 Java license를 교묘히 피해가는 묘수가 동원되는데 개발 중에는 JDK를 비롯한 Java tool-chain 등 모든 도구를 사용합니다. 그러다가 바이너리가 만들어지는 그 순간에 Java VM용 byte code를 Dalvik VM용 byte code로 변환하여 license에서 자유롭다고 주장합니다.

물론 이 부분은 Sun사의 공식 입장과는 다른 것 같습니다.

문제는 안드로이드가 Sun사의 Java license를 침해했다는 결론에 도달해도 구글이 안드로이드로 인해서 얻은 수익을 증명할 수 없기 때문에 책임지지 않을 것이라는 것이죠. 안드로이드 기반으로 출시한 제조사는 부당 이익을 증명할 수 있으므로 당연히 문제가 될테구요.

License 부분도 결국은 구글이 책임지지 않는다는 것입니다.

3. 미확인 이슈 하나 더
이 부분은 제가 안드로이드 공부 초기에 어떤 블로그에서 읽은 내용인데, 어떤 블로그 인지 다시 찾지를 못해서 사실인지 아닌지 확인된 사항이 아닙니다만, 구글 안드로이드 License에는 구글이 판단하기에 Business적인 가치가 없다면
안드로이드를 더 이상 진행하지 않을 수도 있다는 문구가 있다고 합니다. 판을 흔들 수 있는 아주 무서운 말인데 Open Project라는 이유로 간과되는 것이 아닌가 싶었습니다.

물론, Open Project이니 구글 없이도 진화를 할 것이라고 생각할 수 있을 것 같습니다.
일부 사람들은 구글이 지배력을 확대하기 전에 안드로이드를 구글로부터 분리시키자는 주장도 하고 있습니다.

그런데, 지금 안드로이드가 완전한 Open Project는 아니라는 사실이 아주 중요합니다.
안드로이드 소스는 Private version과 Public version이 존재하며 OHA member에게만 Private version을 비롯한 고급 정보가 제공됩니다.

Non-public API가 존재하며 해당 API를 사용하면 SDK에서 소스 빌드가 되지 않기 때문에 Linux 상에서 개발을 해야 하는데 디버깅이 아주 복잡하고 어렵습니다.
안드로이드에서 기본 제공되는 대부분의 application이 Non-public API를 사용해서 Public version SDK로는 수정이 불가능하고 여러가지 복잡한 과정을 거쳐야 개발이 가능합니다.

OHA member로 안드로이드가 세상에 빛을 볼때까지 투자한 비용이 있기 때문에 당연한 결과이지만 이런 내용을 모르는 순진한 개발자들이 많다는 것이 문제인 것 같습니다.

좋게 생각하면 얼마든지 좋게 생각하고 이해할 수 있는 수준의 문제 제기입니다.

다만, 구글의 모토가 “Don’t be Evil”로 사악해지지 말자는 것이고 인터넷에서 매력적인 서비스를 공짜로 제공하고 있는 자선사업가 같은 모습을 보이기 때문에 사람들이 구글의 사악성이라는 잣대를 지속적으로 들이대는 것이 아닌가 싶습니다.

아직까지 구글은 사악하지 않습니다. 다만, 사악해질 수 있는 여러가지 방법들이 있어서 의심된다는 것이죠.

참고문헌
http://www.visionmobile.com/blog/2008/09/the-darker-side-of-android/

“클라우드 컴퓨팅, 그거 덫이야”…스톨만 일갈

Android에 대한 小考(소고) – Open Access

※ Daum 소규모 지인 위주의 카페에 안드로이드 초기 느낀 점을 지인들과 공유하기 위해서 적은 글인데 어딘가 따로 정리가 필요해서 블로그로 복사합니다.

Open Access가 획기적이라고 극찬하였지만 실제로는 “Open Application”에 대한 내용입니다.
구글 CEO가 FCC에 보낸 서한에 Open Access라는 내용이 있고 그 중의 한가지로 안드로이드에 적용된 기술입니다.

Open Application의 핵심은 어떠한 Application도 플랫폼에서 독점적으로 동작할 수 없다는 것입니다.
(심지어 Google이나 제조사에서 출시 때 기본적으로 탑재하여 제공하는 application 조차도…)
플랫폼에서 구조적으로 불가능하도록 설계가 되어 있고 모든 Application은 안드로이드 플랫폼에서 평등합니다.

Open Access
Open Access

위 그림 중에서 오른쪽 Emulator Capture화면을 보면 “Home”과 “Home Sample” application 중에서 선택하라는 의미의 POP-UP이 보입니다.

이 그림만으로 보면 큰 반향이 있을만한 사항이 아닙니다만
Home이 일반적으로 대기화면 application으로 시스템이 기본적으로 제공하는 기능이라고 볼 때 사용자가 대기화면 application을 선택적으로 변경할 수 있다는 의미입니다.
여기서 중요한 것은 일반적으로 FEATURE폰 또는 기존 OS에서는 대기화면을 변경한다는 의미는 Look & Feel이 변경 가능하다는 의미이지 Application 자체가 변경된다는 의미가 아니라는 것입니다.

Microsoft가 Windows의 독점적인 지위를 이용해서 Netscape 브라우저를 밀어내고 별도 좋지도 않은 Internet Explorer의 시장 점유율을 획기적으로 끌어 올렸던 이유는 다 아시다시피 Windows에 IE는 기본적으로 탑재되어 있고 기본으로 설정된 IE 브라우저외에 별도로 Netscape 브라우저를 사용하기에는 사용자들이 많이 불편했기 때문입니다.
최근에는 반독점 판결에 의해서 브라우저와 검색 공급자를 사용자 선택으로 변경하게 하였지만 이는 또 다른 의미에서 선택된 application에게 독점적 지위가 부여되는 악순환일 뿐입니다.

안드로이드에서는 application들이 어떻게 평등한 권리를 가지는지 기술적으로 접근해 보겠습니다.

① System application의 Category 분류
구조적으로 평등한 권리가 가능한 기본 기술은 Application을 제작하는 시점에 category를 설정할 수 있습니다.
위 화면의 경우 기본적으로 안드로이드에 ‘HOME’이라는 속성을 가지는 application이 탑재된 상태에서 사용자가 “Home Sample”이라는 ‘HOME’ 속성을 가지는 application을 추가로 설치하고 부팅을 하게 되면 ‘HOME’이라는 동작을 수행하는 application이 2가지 이상이므로 플랫폼에서 사용자에게 어떤 application을 사용할 것인지 기본으로 설정할 것인지 묻는 것입니다.
즉, 제조사 조차도 대기화면을 사용자가 원하지 않으면 점유할 수 없다는 의미입니다.

② Intent라는 message 전달 시스템을 이용한 ACTION 정의
Category외에 “ACTION”이라는 것이 있는데 예를 들면 전화를 걸기 위해서 Dialer를 호출하는 “ACTION_DIAL”과 전화번호를 전달해서 바로 전화를 거는 “ACTION_CALL”입니다.
바꿔 말하면 기존 FEATURE phone에서는 해당 기능을 수행하는 Application을 직접 호출하는 방식인데 반해 안드로이드는 application을 직접 호출하는 것이 아니고 플랫폼에게 어떠한 동작을 하고 싶다고 요청하게 되면 플랫폼에 등록된 application 중에서 해당 ACTION을 수행하는 application에게 message를 전달하는 방식으로 HOME과 마찬가지로 동일한 ACTION을 수행하는 application이 2개 이상인 경우에는 사용자게에 어떠한 application으로 동작을 수행할지 묻게 됩니다.

물론, 특정 application을 직접 호출할 수 있는 방법을 제공하지 않는 것은 아니지만 안드로이드 플랫폼 진화 방향을 거스르는 동작 구조이므로 사용자의 선택을 받아야 하는 application 입장에서 독자적으로 동작하게 만들 이유가 없는 것이죠.

이러한 구조하에서 구글이 원했던 또는 원하지 않았던 아주 재미있는 자발적인 Site가 생겨났습니다.
OpenIntents라는 것입니다.

안드로이드에서는 “ACTION_DIAL(android.intent.action.CALL)”과 같이 시스템에서 정의하는 ACTION이 있지만 사용자가 임의로 ACTION을 생성해서 사용할 수 있도록 허용하고 있습니다.

이렇다보니 기존 안드로이드에서 제공하지 않는 신규 기능을 수행하는 application을 개발하고 해당 기능을 수행할 수 있는 action을 정의하였는데 다른 application에서 사용하지 않으면 무용지물이 될 뿐 아니라 동일한 동작에 대해서 action 정의가 달라질 수 있는 문제점을 자발적으로 해결하기 위해 생겨난 Site입니다.

내가 필요한 기능이 이미 OPEN되어 있다면 해당 Site에서 소스레벨 또는 application을 다운받아서 설치한 이후에 해당 기능을 호출해서 사용할 수도 있고 반대의 경우도 가능합니다.

어느 누가 통제하지 않고 관리하지 않아도 필요에 의해서 자발적으로 문제점을 해결해 가는 모습은 OPEN platform이기 때문에 가능한 문화가 아닌가 생각합니다.

Android에 대한 小考(소고) – 호환성과 불행의 씨앗

※ Daum 소규모 지인 위주의 카페에 안드로이드 초기 느낀 점을 지인들과 공유하기 위해서 적은 글인데 어딘가 따로 정리가 필요해서 블로그로 복사합니다.

아래 그림은 안드로이드 소개에서 꼭 보여지는 그림입니다. 파란색 영역은 JAVA, 초록색 영역은 C, 붉은색 영역은 Linux Kernel을 의미합니다.

Android architecture diagram
Android architecture diagram

원래 안드로이드에서는 Application은 Application framework 위에서 Java로 프로그래밍을 해야 합니다.
문제는 현 시점에서 Only Java로 할 수 있는 일이 많지 않다는 것이죠…
그 부분은 안드로이드 플랫폼 구조에서도 명확하게 보여집니다.
Application Framework 부터는 Java기반이지만 Libraries layer와 HAL layer 등은 C언어라는 것이고 Java언어와 C언어가 공존할 수 밖에 없는 구조로 다행인지 불행인지 Java application에서도 C library 사용이 가능합니다.
JNI(Java Native Interface)라는 기술을 사용하는 것인데 최근 안드로이드 관련해서 끊임없이 언급되는 용어입니다.

여기서 안드로이드의 불행이 시작됩니다.

현재 대부분의 Solution들은 C언어로 구현되어 있는데 어느날 갑자기 안드로이드가 대세가 되면서 Solution 업체들이 기존 코드를 Java로 모두 바꾸는 것을 포기하고 JNI interface를 이용해서 Solution을 재활용합니다.

물론, Libraries Layer에 기존 Core library들을 포팅하고 Application Framework 단에 Solution을 적절히 활용할 수 있는 Manager/Service Component 들을 만들어주면 좋은데 안드로이드 개발자가 거의 없고 안드로이드 플랫폼을 이해하는 수준이 미천해서 대부분 업체들은 아래와 같은 두 가지의 간편한 방법을 이용합니다.

① Java Application이 JNI Interface를 이용해서 Library를 직접 호출하도록 하는 방법
② Application Framework을 통하지 않고 안드로이드 플랫폼 옆에 Solution을 Vertical로 배치하는 방법

안드로이드 최초 배포시에는 JNI에 대해서 Recommened하지 않았으나 기술적으로 사용을 제한하지 않아서 방관하는 입장이었고 향후에는 JNI를 정식으로 지원한다는 얘기도 종종 들리고 있습니다.

위와 같은 방법으로 Solution이 포팅이 되면서 Java VM 기반 플랫폼의 장점이 무색해지는 동시에 표준 Application Framework과 연동되지 않는 Solution으로 인해서 호환성에 문제가 발생하는 것입니다.

Windows Mobile이나 Symbian같이 한 업체가 Ownership을 가지고 강력하게 통제를 하는 경우에는 호환성 문제가 심각하지 않지만 완전한 Open platform인 안드로이드는 이런 위험에 노출되어 있었는데 세상에 빛을 본지 얼마되지 않아서 표준 구조가 무참히 깨지는 현실에 직면합니다.

호환성 문제는 이러한 Solution에 국한된 것이 아니고 안드로이드 표준 배포 버전인 v1.1과 v1.5 간에도 문제로 인식되고 있는 상황입니다. v1.5 플랫폼에서 Application을 개발하는 개발자는 v1.1 플랫폼에서도 정상 동작하는지 확인을 해야 하고 이를 위해서 v1.5 SDK부터는 Virtual Device 개념을 도입해서 v1.1, v1.5 등 버전별로 Emulator를 별도 생성할 수 있습니다.

Linux가 Kernel 단에서는 구조적으로 호환성을 확보했다고는 하나 난립하는 Shell로 인해서 하나의 Shell에 익숙해진 사용자가 다른 Shell을 사용하지 못하는 현상이 안드로이드 플랫폼에서도 동일하게 발생하지 않을까 심각하게 우려가 되고 있습니다.

이 부분이 안드로이드 플랫폼의 생사의 기로에 영향을 끼칠 불행의 씨앗이 아닐까 싶습니다.

오늘은 기술적인 얘기가 주로 언급되었는데 다음번에는 안드로이드 플랫폼의 가장 큰 특장점인 Open Access에 대해서 얘기를 해볼까 합니다.

Open Access 개념이 생소하고 글로 얼마나 이해를 잘 시킬 수 있을지 모르겠지만 상당히 획기적인 개념이고 안드로이드 플랫폼이 극찬받는 이유 중의 하나이므로 시간을 할애해서 이해를 하시면 좋은 경험이 될 듯 합니다.

Android에 대한 小考(소고) – Java

※ Daum 소규모 지인 위주의 카페에 안드로이드 초기 느낀 점을 지인들과 공유하기 위해서 적은 글인데 어딘가 따로 정리가 필요해서 블로그로 복사합니다.

1.첫인상 – Java라니….
안드로이드에 대한 첫인상은 도대체 그 정체를 알 수 없는 놈이었습니다.
구조적으로 Windows 같은 General Purpose 계열의 OS도 아니고 그렇다고 Embedded System에 맞는 OS도 아니고..
쌩뚱맞은 Linux에 더 쌩뚱맞은 Java라니…

Linux Kernel이야 REX에서 L4 micro kernel로 자연스럽게 적응되는 과정이 있었다고 하더라도 (물론 L4가 적용되면서 REX에서 잘 돌던 코드들이 System Panic 현상을 무수히 발생시켜 죽어라 고생했지만…) 그 동안 단말에서 Java 기반으로 시스템을 구성하려는 수 많은 시도가 있었지만 결국은 C기반의 대세를 뒤집지 못한 상황을 많이 보았던 터라 플랫폼에서 Java 언어만을 지원하는 혁명적인 상황에 좀 당혹스러웠습니다.
아이폰은 Objective-C로 개발한다고 하던데 이러한 부분에 대한 타협점이 아니었을까 생각합니다.

현 시점에서의 결론은 안드로이드를 공부하다보니 역시 머리좋은 넘들이 만들어 놓은 거라 구조도 잘 잡아 놓고 구석 구석 꼼꼼하게 고민한 흔적들이 보인다는 것입니다. 아직 실제 프로젝트를 수행하는 단계가 아니고 공부하는 단계이다 보니 단점보다는 장점이 더 많이 보이는 게 어쩔 수 없는 현상으로 당분간은 좋은 점만 나열할 것 같네요…

2.Why Java
Open Market이라는 큰 그림상에서 보안을 비롯하여 안정성을 쉽게 확보하기 위한 불가피한 결론으로 보입니다.

천문학적인 금액을 투입한 Windows도 보안이 뚫리는 마당에 아무리 Linux Kernel을 사용한다고 한들 Virus를 비롯한 특정 application에 의한 단말 Panic 현상을 방지할 만한 뾰족한 수가 없지 않았을까 합니다.
(나중에 따로 언급하겠지만 요즘 이러한 방어 구조들이 망가지고 있어서 심히 우려스럽습니다만…)

Java 엔지니어보다 C 엔지니어가 절대적으로 많은 우리나라 제조사들에게는 안드로이드가 대세가 되기까지는 상당한 기간이 소요될 만한 부정적인 요소가 될 것 같습니다.