생각하고 나누고 공감하기...

미국 시간 2008년 1월 25일 11시 25분에 스프링 프레임웍 홈페이지에 Spring Dynamic Module(지금까지 Spring OSGi라고 부르던 프로젝트의 정식 명칭) 1.0 발표 공지가 올라왔습니다. 매우 관심이 많이 가는 프로젝트입니다. 제가 보수적인 성향이 있어 보통 버전이 2.0 이상은 되야 겨우 검토하는 편이지만 이 프로젝트는 빨리 적용해보고 싶네요.

저는 스프링 프레임워크를 쓰기 전에 아파치 프로젝트 중 하나인 아발론 프레임워크를 사용했었습니다. 지금은 프로젝트가 중단되었고 Excalibur라는 후계자에 의해 명맥을 유지하고 있습니다.

제가 아발론을 사용했던 이유는 아파치의 Java Mail Server 프로젝트인 James를 기반으로 작업 할 일이 있었는데 이 James가 아발론을 사용해서 만들어졌기 때문입니다. 지금 제 작업물에는 James가 이제 남아 있지 않고 최근에는 아발론도 스프링프레임워크로 교체하고 있습니다. 아발론 프로젝트가 더는 진행 되고 있지 않는 문제도 있고 이 코드를 다른 개발자들과 함께 유지 보수하려면 스프링 프레임워크가 더 유리할 것 같기 때문입니다. 제가 스프링을 쓰고 싶기도 하구요. (사실 James 메일링 리스트에서도 한동안 스프링으로 James를 포팅하는 건에 대한 논의가 있었습니다. 아발론을 계속 쓰는 것으로 결론이 나기는 했지만 불씨는 여전히 남아 있다고 생각합니다.)

그런데 아발론과 스프링은 둘 다 IOC 컨테이너라고 분류될 수 있으면서도 개념이 아주 다른 프레임워크입니다. 물론 이 시점에서 스프링이 단순한 IOC 컨테이너가 아니라는 것은 알고 있다고 한마디 하고 넘어가야 할 것 같네요. 아발론도 단순한 IOC 컨테이너만은 아닙니다만... ㅎㅎ

아발론과 스프링의 차이점을 전부 비교할 생각은 없습니다. 제가 말하고 싶은 부분은 하나인데요. 아발론은 컴포넌트 수준에서의 IOC를 생각하고 만들어졌습니다. 반면에 스프링은 컴포넌트와 객체의 구별이 없습니다. 메뉴얼에서도 컴포넌트, 빈, 객체라는 서로 다른 용어가 섞여서 사용되는듯 합니다. 그래서 아발론을 먼저 사용했던 저는 처음에 스프링을 접하면서 어떤 수준에서 스프링 컨테이너에 객체 관리를 위임해야 할지 결정하기 참 어려웠습니다. 너무 많은 것을 스프링에 등록하는 것 아닌지 걱정도 들었구요.

그럼 객체와 컴포넌트는 어떻게 다른 것일까요? 아발론에서는 컴포넌트를 PC 슬롯에 설치하는 Add-On 보드로 비유합니다. VGA 카드나 사운드 카드 같은 확장 보드 말이죠. 반면에 객체는 그 보드를 만드는 데 사용된 칩이나 전자 부픔으로 얘기합니다. 즉 하나 이상의 객체가 모여서 어떤 기능을 하는 단위 모듈을 만들게 되면 그것을 컴포넌트라고 부르는 것이죠. 아발론에서는 객체들을 어떻게 구성해서 블럭(아발론에서 컴포넌트를 블럭이라고 함)를 만드는지는 관여하지 않습니다. 다만 이 블럭(컴포넌트)들을 관리해 줄 뿐이죠.

잠시 딴 얘기를 해보면... 제 생각에 요즘은 Java Bean이 실행 시 관리 유용성 때문에 필요 이상으로 많이 사용되는 것 아닌가... 그래서 자바 개발자들이 컴포넌트라는 개념을 잘 못 이해하고 있는 것 아닌가... 하는 생각을 하게 됩니다. 그래서 자바 바이트 코드 조작을 통한 객체 관리 방식이 자바 빈을 사용한 것보다 좋게 생각되구요. 좌우간....

다시 아발론을 정리를 하면 아발론은 컴포넌트(블럭)들을 관리하는 IOC 컨테이너로써 컴포넌트들의 라이프사이클을 관리하고 이 컴포넌트가 제공하는 서비스를 기반으로 통합 운영 환경을 제공합니다. 어떤 컴포넌트를 등록하면서 이 컴포넌트가 어떤 버전의 서비스에 종속되어 있는지 표기를 하면 그 서비스를 제공하는 컴포넌트를 찾아서 알려줌으로써 컴포넌트끼리 서로를 찾아서 한 시스템으로 운영되도록 해주는 것입니다.

아마 OSGi에 관심이 있는 분이라면 방금 제가 한 아발론의 설명이 친숙하다고 생각되실 것입니다. OSGi가 제공하는 환경이 바로 컴포넌트 기반의 서비스 지향 환경이기 때문입니다. Spring Dynamic Module을 사용하면 각각 독립된 Spring Application Context를 가지고 있는 모듈들을 한 OSGi 플랫폼 위에 설치하고 이 모듈들이 서로 자기가 필요한 서비스를 제공하는 다른 모듈들을 찾아서 사용할 수 있게 됩니다. HiveMind가 스프링에 비해서 장점이라고 얘기하던 부분이 이렇게 여러 어플리케이션을 한 프레임워크 위해서 동시에 운영할 수 있다는 것이었는데 OSGi를 통해서 스프링도 대규모 서비스 지향의 시스템을 구성할 수 있게 된 것입니다. 더 뛰어난 환경에서 말입니다.

어떤 분은 Application Context를 계층화해서 모듈은 자신만의 자식 Application Context을 개별적으로 구성하고 부모 Application Context로 이들을 통합하면 되지 않겠냐고 하실텐데 저도 그렇게 구성하려고 생각하고 보니 자식 Application Context에 등록되어 있는 빈들은 다른 자식 Application Context의 빈들을 찾지 못하더군요. 그래서 일종의 서비스 저장소 같은 공간을 따로 만들어서 그 곳에 각 모듈들이 자신의 서비스와 리퍼런스를 등록하고 자신이 필요로 하는 서비스가 있으면 이곳에서 직접 찾아서 가지고 가도록 해야만 했습니다. 결국 나중에는 자식 Application Context들을 다 하나로 통합해서 한 Application Context로 만들고 DI를 하도록 바꾸었구요.

솔직히 일반적인 웹 어플리케이션을 개발하면서 OSGi를 쓸 일이 얼마나 있을지는 모르겠습니다. 금융권처럼 일부 비지니스적으로 민감한 경우가 아니라면 말이죠. 하지만 저처럼 서버 프로그램을 개발하는 입장에서는 무척이나 반가운 선물입니다. 물론 당장은 제 업무에 이 이쁜 놈을 적용하지 못하겠지만 하루 빨리 써보고 싶은 마음이 간절합니다. 원래 이것이 없었으면 Jboss의 JMX 기반 서비스 지향 아키텍쳐를 써 볼 생각도 했었거든요.

이번 JCO 자바 개발자 컨퍼런스에서 가장 기대되는 부분 역시 Epril 대표 이일민님의 Spring OSGi 세션입니다.

참고로 제 코드처럼 아발론을 썼다가 최근에 스프링프레임워크로 바꾸는 프로젝트가 있습니다. 아실만한 분은 다 아실 아파치 Cocoon 입니다. 아마 OSGi를 사용하지 않을 것으로 보이지만 혹시 스프링을 사용해서 컴포넌트 기반의 시스템을 어떻게 개발하는지 관심이 있으시다면 대충 살펴보는 것도 좋을 듯싶습니다. 저는 너무 많이 포팅 작업을 진행했기 때문에 이 프로젝트에서 도둑질 할 것이 얼마 없을 것 같네요. 좀 일찍 알았으면 도움이 되었을 듯 한데 말이죠. 쩝.