본 원고는 마이크로소프트 2008년 5월에 기고한 기사입니다.참조시 출처만 밝히시면 됩니다
안드로이드를 사전에서 찾아보면, 그리스어가 어원이고 “인간을 닮은 것”이라고 나온다. 그렇다. 확실히 구글의 안드로이드는 자바 플랫폼을 많이 닮아있다. 하지만, 안드로이드가 인간이 아니듯 구글의 안드로이드 플랫폼은 정확하게 자바는 아니다. 오픈소스가 IT업계의 큰 트랜드로 자리잡은 이 시점에 나타나는 문제점들의 하나는 급격한 소스의 파생이다. fork라고도 하는데, 어쩌면 구글의 안드로이드는 Java의 Fork가 될수도 있겠다. 구글은 왜 모바일과 임베디드 업계에서 점차로 확산되는 J2ME를 채택하지 않았을까? 더 나아가서 채택하지 않았으면서 왜 J2ME의 아키텍쳐를 템플릿으로 참조하여 안드로이드 플랫폼을 탄생시켰을까? 아마도 그것은 SUN의 자바에 대한 극히 폐쇄적인 JCP 정책과 항상 뒤늦은 대응정책때문이었을것이다. SUN은 JCP를 통해서 자바의 로고와 스펙 그리고 업그레이드에 대한 독립적인 그리고 독자적인 권한을 가진다. 항상 남보다 빠르게 시대를 이끌어오고 오픈으로 마켓을 리딩하는 구글로서는 자바 환경에서 독립적인 그리고 무소불위의 권한을 가진 SUN이 자사의 모바일 전략에 큰 걸림돌로 여겨졌을것이다 (물론 뛰어난 자바의 기술력과 확장성은 탐이 났겠지만) 결국 자바와 극히 비슷한(J2ME의 CDC환경) 안드로이드 플랫폼은 일반적인 JVM이 아닌 독립적인 DALVIK이라는 VM을 탄생시켰고, DEX fille이라는 native Dalvik format을 개발자들에게 선물하였다.
[그림 1] 안드로이드와 OSGi 공통 분야
물론, 모바일 업계에서 아직 J2ME-CLDC/MIDP는 메인 스트림이 아직 아니다. 점차 스마트폰을 중심으로 확산은 되고 있지만, 제조업체마다 독립적인 API, 서로 다른 RMI 방식, 고급 UI를 지향하면서 무거워져만가는 GUI 모듈, manifest를 위한 거대한 XML 타입 등 다양한 모바일 실행 환경에 대한 문제점들이 나타나고 있다. 구글은 이러한 문제점들을 해결하고 더욱 고급화되는 UI, 멀티태스킹과 강력한 애플리케이션과 관리솔루션을 J2ME 벤치마킹을 통해서 개선하고자 했다. 하지만, 오픈된 안드로이드 아키텍쳐에는 구글이 플랫폼 구조와 애플리케이션 구동에는 많은 관심을 보여왔지만, J2ME-OSGi 플랫폼에 비해서 독립적인 모듈구조, 애플리케이션의 라이프 싸이클, 애플리케이션을 통합 관리할 수 있는 미들웨어 부분에서 약점을 드러내고 있다. 이러한 문제점들은 OSGi 프래임워크에서 장점으로 내세울수있는 부분이며, 따라서 안드로이드를 오픈한지 얼마되지않은 구글 입장에서는 OSGi를 안드로이드 플랫폼에 통합/연동하거나 안드로이드-OSGi 솔루션으로 확대될것을 기대하는 개발자들이 많이 나타나고 있다. 또한 이러한 개발자들의 요구에 맞춰서 몇몇 전문 벤더에서는 안드로이드-OSGi 솔루션을 이미 개발하여 시장에 진입하려고 하고 있다. 그렇다면, 안드로이드와 OSGi의 차이점과 서로의 연동이 우리에게 가져다주는 장점은 무엇인가? 우선 안드로이드와 OSGi는 크게 VM을 지원하는 방식이 다르다.
[그림 2] 안드로이드와 OSGi 차이
OSGi는 하나의 VM 위에서 구동되어, 각 서비스 또는 애플리케이션이 번들 타입으로 작동하게 된다. 따라서 리소스, 데이터 공유가 쉽고 각 번들의 결합을 통해서 서비스의 생성와 참조가 쉽다. 하지만, 안드로이드는 하나의 VM에서 하나의 프로세스가 애플리케이션으로 구동되어 작동된다. 따라서 프로세스간 데이터, 리소스 공유시 IPC, 메타포어 등을 통해야한다. 하지만, 안정성과 보안 측면에서는 OSGi 보다 우월하다고 할수있다. 그러나, PC 애플리케이션이나 서버급의 엔터프라이즈가 아닌 모바일, 임베디드 환경에서는 더 작은 메모리로 빠르게 서로를 공유하고 참조할 수 있는 그리고 번들, 서비스의 모듈성이 보장되는 OSGi 구조가 훨씬 더 효율적이다.
[그림 3] 효율적인 OSGi 컴포넌트의 참조와 공유
또한 안드로이드에서 오브젝트의 모듈성에 대해서 문제점이 노출되고 있는데, 그것은 바로 DexFile의 구성이다. 표준 클래스 로더가 바이트코드를 로드하기위해서 반드시 하나의 JAR파일과 함께 작성되어야 한다. 따라서 JAR 파일내에 위치한 번들을 찾기위해 번들-클래스패스(Bundle-Classpath) 같은 기능을 사용하기 위해서는 JAR 파일 전체를 핸들하는 불필요한 메모리 누수가 발생하게 된다. 이러한 문제점들은 하나 내지 소수의 애플리케이션을 작성하고 구동할때보다, 다수의 애플리케이션들이 구동될때에 치명적인 약점으로 나타날수가 있다. 그렇다면 OSGi와 안드로이드가 결합될때에 가져다주는 장점은 무엇인가? 그것은 단연 번들의 재사용성이다. J2ME, J2SE를 기반으로 하는 수많은 기존의 번들 코드를 그래도 사용할 수가 있고, 또한 기존의 코드를 이용하여 다양한 서비스의 참조 내지 생성을 통해 안드로이드용 애플리케이션을 빠르게 작성할 수가 있다. 또한 안드로이드 플랫폼에서 작성하는 애플리케이션에 비해서 OSGi 프래임워크에서 지원하는 다이나믹한 코드의 모듈성과 강력한 번들 라이프싸이클 관리시스템으로, 안드로이드 애플리케이션은 실제로 구현하는 Activity 코드와 GUI 부분에 집중해서 개발하기 때문에 코드를 기존의 애플리케이션에 비해서 작은 바이트 코드를 개발할 수가 있다. 마지막으로 강력한 개발툴의 지원이다. 이미 OSGi는 이클립스에 통합이 되어있고, RCP & eRCP라는 개발방법론으로 임베디드-모바일-데스크탑에 이르기까지 다양한 플랫폼에서 전세계 자바 개발자들에게 가광을 받고있다. 이러한 통합된 개발환경과 방법론으로 전세계 자바개발자들에게 안드로이드는 더욱 쉽게 다가갈수가 있을것이다. Android-OSGi 솔루션은 이러한 장점 때문에 기본의 OSGi 업계의 강자인 IBM과 Prosyst에서는 작년 구글에서 오픈된후부터 강력하게 드라이브하고 있다.
한편 Android-OSGi은 쉽게 통합되고 연동될수가 있는것인가? 이에 대한 답변으로 올해 3월 미국 캘리포이나에서 열린 Eclipse 개발자 컨퍼런스 “EclipseCON”에서 찾아볼수가 있었다. EclipseCON은 과거 이클립스라는 개발툴의 오픈소스 개발자들이 모여서 시작된 작은 컨퍼런스인데, 재작년부터 OSGi DevCON과 통합되어서 Eclipse 뿐만 아니라 RCP, OSGi, Server Framework 등 다양한 주제들로 꾸며진다. 이번 OSGi 개발자 세션 역시 별도로 열렸는데, 이번 컨퍼런스에서 IBM의 B.J Hargrave가 Android-OSGi 통합이라는 주제로 큰 호응을 받았다. 위에서 이야기했듯이 Android-OSGi 솔루션에는 IBM, Prosyst 등의 전문 벤더와 스프린트, 모토롤라, 노키아 등의 핸드셋 제조업체등이 큰 관심을 보이면서 드라이브를 하고 있는데, Hargrave는 이번 발표에서 Apache-Felix와 안드로이드 연동 사례, 그리고 실제 상용화 솔루션을 제공하고 있는 Prosyst 사례를 들면서 개발 방법론을 강의하였다. Android-OSGi 연동은 크게 두가지로 이루어진다. 하나는 안드로이드 플랫폼에 프레임워크의 탑재하는 부분과 또 하나는 다이나믹한 번들의 수정 또는 개발이다.