1.2 Equinox의 역사

Equinox는 2004년 Eclipse Foundation의 요청에 의해서 Eclipse 3.0에 탑재되어 세상에 처음으로 선보이게 된다. 이때의 Eclipse는 버전 2.1에서 3.0으로 업그레이드가 되었는데 단순히 1.0이 버전업되는 것보다 훨씬 더 많은 변화를 가져왔으며, 바로 그것이 Equinox의 탑재였다. 이전에는 수많은 기능들이나 모듈들이 플러그인 형태로 다운로드 되거나 인스톨되었는데, OSGi기반의 번들 형식으로 변경되어 재설계되고 Dynamic Module 시스템으로 제공된것이다. 이미 2003년초 Eclipse Foundation은 단순히 Eclipse를 통합된 하나의 IDE가 아닌 RCP(Rich Client Platform)로의 확장을 목표로 전체적인 시스템 아키텍쳐의 재설계를 가져가게 된다. 그때 바로 OSGi Framework 기반의 구조가 논의끝에 설계되었고, 탑재된 제품은 IBM의 SMF 3.x를 근간으로 Eclipse에 최적화된 Equinox가 탄생하게 된다. Eclipse 최적화 기간은 약 18개월정도였으며 이때 하나의 Framework로 선택된 SMF-OSGi가 Equinox로 재탄생하여 RCP, JDT, PDE 기반의 Eclipse Platform의 핵심 컴포넌트로 탄생하게 되었다. 초기 Equinox는 OSGi R3를 기반으로 하고 있었으나 현재 R4 SPEC으로 버전업되었고, 현재에도 OSGi Alliance의 VEG(Vehicle Expert Group), MEG(Mobile Expert Group)와 협의하에 지속적으로 발전해 나가고 있다. Eclipse Equinox Project에는 몇가지 특징적인 요소들이 있었는데, 프로젝트의 산실인 Incubator 활용, Open Source Community 지원, 그리고 마지막으로 신기술의 개념 도입 등이 그것이다. 우선 Equinox를 구현하기위해서 많은 OSGi 및 Eclipse 오픈소스 단체 및 동호회에 개발인력을 구하였고 SPEC을 선정하면서 요구사항에 도움받았으며, 이러한 개발의 집합체 및 통로로 Incubator를 활용하였다. Incubator는 말그대로 산실의 의미를 가지게 되는데, 현재 Equinox가 개발된 이후에도 여전히 Incubator를 통해서 많은 서비스 번들과 프로젝트들이 수행되고있다. 한편 신기술과 신개념 도입은 AOP(Aspect Oriented Programming)를 Java에 접목한 AspectJ와 Security 부분을 Incubator를 통하여 동시에 추진하였다. 이러한 특징들은 하나의 회사나 벤더가 독립적으로 개발할 때 나타나는 현상과는 다른 측면으로 공동의 광범위한 오픈소스의 지원과 빠르게 변하는 신기술의 적극적인 대응에 부합된다고 볼수있다.

[그림 2. OSGi 개발 로드맵]

1.3 Eclipse의 선택

Eclipse는 무엇 때문에 OSGi를 선택하게 되었을까? 아니 어쩌면 그보다 왜 Eclipse는 2.1에서 3.0으로 급격한 변화를 해야했으며 그 당시 가지고 있었던 고민들이 무엇인지 살펴볼필요가 있다.

지난 2006년 10월 덴마크에서 열린 JAOO Conference에서 “The OSGi Foundation for Eclipse” 라는 주제로 발표했던 Jeff McAffer는 “그 당시 Eclipse Foundation에서는 전세계 S/W Market의 흐름을 눈여겨 보고 있었다. Eclipse의 발전을 신기술의 도입에 초점을 둔 것이 아니라 시장의 흐름과 고객의 요구에 모든 우선순위를 두고 있었다” 라고 하였다. 과연 Eclipse에서 보았던 S/W 시장의 문제점과 고객들의 불만, 요구사항은 무엇이었을까? 그것은 다음과 같이 몇가지로 요약할 수가 있다.

1) The Limited Binary Software Portability Problem (이식성 또는 재사용성의 문제점) : 이식성과 재사용성은 이전부터 많이 회자되는 이슈였고, 또한 그것을 해결하기위해서 컴포넌트, 재사용성에 대한 도구, 툴들이 많이 시장에 발표되었으나, 여전히 그것에 대한 시장은 크지않았고 사용자들은 재사용성과 이식성에 대한 불만을 가지고 있었다. 더욱이 과거 PC기반의 S/W가 대부분이던 시절에서 모바일-임베디드-PC-서버에 이르는 다양한 하드웨어와 플랫폼 환경이 나타나기 시작하였으며 사용자 환경도 윈도우에서 리눅스, 웹이라는 환경들이 점차 확산되는 실정이었다. 이러한 개발 및 사용자 환경에서 향후 개발된 S/W의 이식성과 재사용성, 다양한 플랫폼의 지원은 더욱 더 중요한 요소로 작용할것이 분명하다고 예측하였다.

2) The Complexity of Building Heterogeneous Software Systems (소프트웨어의 복잡성) : 날로 증가하는 S/W 코드는 매우 심각할정도이다. 일반적인 DVD 플레이어는 백만라인의 코드를 가지고 있고, BMW의 신규 차량은 50여개의 디바이스가 네트워킹되어 제어 및 관리가 되고있으며(그것 모두 S/W로 구현되어있지 않은가?) 심지어 Eclipse 2.x 에도 2백5십만 라인의 코드가 담겨져있다. 어떻게 보면 이러한 코드의 급격한 증가는 OOAD, OOP의 한계에서 찾을 수가 있을 것 같다. Object 개념은 심플하고, 재사용성에 분명 장점이 있으나 최근 두드러지게 나타나는 네트워크를 통해 연동되고, 함께 운영되는(Collaboration) 환경에서는 오히려 그 장점이 퇴색되게된다. 다양한 서비스들은 요구하게되는 시스템에서는 Loose-coupled 된 인터페이스가 더욱 효율적이나 현재의 OOP에서는 오히려 오브젝트간의 복잡성을 증가하고 그 결과로 자연히 코드의 수가 늘어나게 된다. 또한 오브젝트간의 유연한 Flexibility도 Plug-in 형태의 구조로 개발자가 직접 정의하고 구현해야하는 상황에 이르게 되었다.

[그림 3. 증가하는 S/W 복잡도]

3) Managing the Software Life-Cycle (효율적인 소프트웨어 관리의 문제점) : 최근 오픈소스와 인터넷의 발달로 과거와는 비교할수없을정도로 빠르게 버전업과 디버깅, 그리고 패치가 이루어지며, 다양한 플랫폼에서 인터넷을 통하여 실시간으로 요구사항과 기능들이 추가되고 수정된다. 따라서 과거의 업그레이드 방식과는 다르게 원격에서 실시간으로 동적인 시스템 업그레이드 및 관리 형태가 요청되는 시대가 되었다.

이러한 문제점들과 사용자들의 요구사항을 분석한 Eclipse Foundation에서는 해결방안으로 몇가지 특징과 솔루션, 아키텍쳐들을 설계하게 되는데, 그 당시 새로운 시스템으로 설계시 필요한 요구사항은 크게 4가지였다. 가장 중요한 요소로 Reliability, Large Scale Distribution, Wide Range of devices, Collaborative 등을 정의하고 이것을 구현하기 위한 기술적인 대안으로 SOA, Framework, Dynamic Module를 선택하게 된다.

그렇다면 그것은 과연 무엇을 뜻하는가? 바로 OSGi의 특징과 일치한 부분이 매우 많지않은가? 이러한 분석과 결과로 Eclipse Foundation은 1999년부터 개발되고 발전되어 온 OSGi를 Eclipse의 기본 Framework로 탑재할것을 결정하게 된다. 그 후로 SMF를 통해서 OSGi 솔루션에서 선두주자인 IBM에 기술 지원을 요청하게 되고 자연스럽게 Eclipse로의 통합이 이루어지게 된다 (물론 어쩌면 이것은 당연한 결과였는지도 모른다. Eclipse 역시 IBM에서 개발되어 오픈소스로 공개한 개발툴이고 오픈소스로 공개되었다할지라도 여전히 Eclipse Foundation에서 가장 강력한 힘을 발휘하고 있는 것 역시 사실이다. 마치 SUN에서 Java를 오픈소스로 공개하고 JCP를 통하여 관리하고 있지만 여전히 SUN이 Java 세계에서 가지고 있는 무소불위의 힘은 무시할 수가 없는 것과 마찬가지 이치인것이다) 암튼 이렇게해서 IBM은 Eclipse에서 Equinox까지 이르는 개발툴과 Framework를 자연스럽게 통합하여 하나의 거대한 Platform으로 발전시키는 중요한 역할을 담당하게 된다.

[그림 4. Eclipse-Equinox Service Architecture]

한편 좀 더 자세하게 Eclipse에서 OSGi를 탑재한 이유들을 살펴보면 위에서의 문제점을 분석하고 그 해결방안으로 제시하게 되는 데, 지난 2005년 IBM Systems Journal에 실린 “The Eclipse 3.0 Platform – Adopting OSGi Technology” (O.Gruber, B.J. Hargrave, J.McAffer, T.Watson) 에서는 다음과 같이 설명하였다. Reliability, Large Scale Distribution, Wide Range of devices, Collaborative의 요구사항에 SOA, Framework, Dynamic Module의 기본적인 아키텍쳐를 제시하고, 이제는 확실하게 OSGi 입장에서 기능과 장점들을 기술해놓고 있다.

[그림 5. Eclipse-Equinox System Architecture]

1) Extensible : 확장성을 가장 높은 우선순위에 두고 있다. 대단히 정확한 지적이다. 단순히 하나의 개발툴에서 개발환경(PDE), 플랫폼(RCP)으로 발전하기위해서는 단순히 플러그인을 다운로드하여 기능을 추가하는 것에 그쳐서는 안된다. 새로운 Application, Framework 심지어 Server로서 확장이 가능해야 할것이다.

2) Light, Dynamic Module : 빠르고 다양한 기능과 컨텐츠 심지어 서버들을 실시간으로 원격에서시스템의 중단없이 추가, 업데이트 할 수 있는 관리 기능이 필요하며 가능해야 할것이다. 또한 네트워크도 유/무선 통합된 환경이어야하므로, 가볍고 코드가 작아야 한다.

3) Platform Independence : 단순히 윈도우, 리눅스 환경의 문제가 아니다. 모바일-임베디드-PC-서버에 이르는 다양한 하드웨어와 O/S가 있기에 그 위에서 운영되는 플랫폼에 독립적으로 컨텐츠가 운영되고 서비스가 사용되어야 한다.

[그림 6. Eclipse-Equinox Platform Build]

4) Rich Eco Systems – Open Source Community : 오픈소스 단체와 지원을 최대한 빠르고 정확하게 수용할 수 있는 구조와 프로세스가 정립되어 있어야 한다. 빠르게 발전하는 기술과 트랜드를 적절히 대응하기 위해서는 오픈소스의 활용을 최적 극대화 해야만 한다.

5) Native Look and Feel – 윈도우만의 환경이 아니기에, 다양한 플랫폼과 디바이스에 적용될수있는 그리고 직관적으로 사용자들에게 경험되고 다가갈수있는 GUI가 필요하게 될것이다. 하나의 프로세스와 직관적인 경험이 플랫폼과 디바이스에 독립적으로 사용하게 해야할것이다