Search Results : 만져보

CloudFoundry(그냥 줄여서 클파라고 써야지)는 VMWare가 주도해서 만들고 있는 오픈소스 PaaS다. 요즘 잘 나가는 클라우드 서비스의 하나인데, 그 중에서도 플랫폼을 제공하는 클라우드라고 해서 Platform as a Service라고 하고 PaaS(미국애들은 주로 패스라고 읽고, 나는 그냥 파스라고 한다)라고 줄여서 부른다. 클라우드도 그렇지만 플랫폼이라는 말도 워낙 느슨하게 정의되어서 여기저기다 마구 쓸 수 있는 말이라 플랫폼을 클라우드 스타일의 서비스로 제공한다는 PaaS도 마구 가져다 쓰는 경향이 있다. 그래서 그 중에서 애플리케이션을 배포하고 운영하는 런타임 환경을 제공하는 플랫폼을 다시 구분해서 애플리케이션 플랫폼(AP)라고 하고, 그런 플랫폼을 aPaaS라고 구분해서 말하는 사람도 있다. 클라우드와 PaaS 얘기하자면 끝이 없을 것 같으니 대충 접고.

아무튼, 클파는 오픈소스 프로젝트다. 그래서 원하면 클파 소스를 가져다가 맘대로 사용할 수 있다. 아파치2 라이선스니 수정해서 상용으로 다시 팔아먹어도 되고, 고친 소스를 공개하지 않아도 된다. 나름 참여도 활발하다. 처음부터 특정 언어와 서비스에 종속적이지 않게 설계되었기 때문에, 마음만 먹으면 자신이 사용하는 언어와 런타임환경, 각종 서비스 등을 추가할 수도 있다. 내가 처음봤을 땐 자바(톰캣), 루비(Rails, Sinatra), Node 정도의 런타임에 MySQL, MongoDB, Redis, RabbitMQ 정도의 서비스를 지원하는 구조였는데, 소스가 공개되고 오픈소스로 알려지니 다양한 커뮤니티와 기업에서 언어와 서비스 등을 계속 추가해서 지금은 PHP, Python, Scala(Lift) 등도 들어가고 PostgreSQL, MongoDB, Neo4J와 같은 서비스도 지원하기 시작했다. 각 언어 런타임과 서비스의 확장 모듈을 만들어서 클파 개발팀에 제공하면 일정한 과정을 밟아서 공식 소스에 반영하고, VMWare가 직접 운영하는 cloudfoundry.com이라는 클파 기반의 퍼블릭 PaaS에 올려주기도 한다. 최근에는 Iron Foundry라는 이름으로 닷넷을 지원하도록 확장한 클파도 나왔다.

오픈소스를 가져다 아예 독자적인 상용 서비스를 제공하는 곳(http://appfog.com/)도 있다. 여기서 클파에 php 런타임을 추가했고, 이를 다시 클파 프로젝트에 기증한 것으로 알고 있다. 또, SDS에서는 CAPE(Cloud Application Platform for Enterprises)라는 이름으로 클파 기반의 자체 PaaS 솔루션을 만들고 있다고 한다. 작년에 열린 애니프레임 오픈 세미나에서 발표된 자료(http://www.anyframejava.org/node/1322) 를 보면 PaaS와 클파에 대한 많은 정보를 얻을 수 있다. 최근에 CAPE을 오픈소스로 공개하기로 한 것을 철회한다는 공지가 떴는데, 그렇다는 건 원래 오픈소스로 공개할 계획이 있었나보다. 비공개로 전환한 건 이유가 있겠지만 쫌 아쉽네.

클파 자체에 관한 자료와 정보는 인터넷에 많이 있으니 찾아보면 된다.

클파는 4가지 정도 형태로 사용될 수 있다.

하나는 VMWare가 운영하는 cloundfoundry.com에서 제공하는 퍼블릭 PaaS 서비스다. 기본적으로 무료로 사용해볼 수 있다. 어느 단계가 되면 유료 서비스로도 제공될 것 같다. 과금방법에 대해서 논의가 있었던 것 같은데 어떻게 진행됐나 모르겠네.

다른 하나는 Micro Cloud Foundry라는 이름으로 제공되는 개발자용 클라우드 VM을 사용하는 것이다. 이건 cloudfoundry.com과 거의 유사한 환경을 가진 서버를 VMWare player나 vsphere 등을 통해서 개발 환경에서 손쉽게 클파를 경험해볼 수 있게 만든 것이다. 만약 퍼블릭 클파를 사용할 것이라면, 일단 로컬에 이 마이크로 클파(줄여서 마클파라고 부르는)를 설치하고 일단 여기에 애플리케이션을 배포하고 서비스를 구성해서 충분한 테스트를 한 뒤에 퍼블릭 클파에 배포하면 될 것이다.

PaaS을 만약 기업내부 시스템의 운영에 도입하고 싶다면 어떨까? 가상화 환경이나 기업내 IaaS처럼 애플리케이션의 런타임 환경도 간단히 구성해서 운영하는 데 사용하고 싶다면, 프라이빗한 PaaS를 도입해야 한다. 보통 PaaS는 DB나 메시징 시스템과 같은 서비스도 PaaS안에 두고 사용하도록 하는데, 규모가 큰 엔터프라이즈 서비스를 이미 운영한다면 PaaS에서 기업내 서비스 리소스로 연결하는 브릿징 기능도 필요하다. 이런 기능을 갖춘 PaaS를 프라이빗 PaaS라고 한다. 클파의 경우는 VMWare 주도로 오래전부터 프라이빗 PaaS가 개발되왔다. 작년 vForum에서 발표한 것에 따르면 올해 봄쯤 공식적으로 공개된다고 하는데. 아무튼 모든 클파 개발자들이 이 프로젝트에 매달리는지 요즘 몇달간 오픈소스 클파의 업데이트가 전혀 없다.

지금까지 말한 세가지는 모두 VMWare가 클파 프로젝트를 기반으로 다양한 형태의 서비스와 솔루션을 만든 것이다. 만약 프라이빗 PaaS를 구성한다거나, 독자적인 사용 퍼블릭 PaaS 환경을 구축하고 싶다면 이 때는 클파 프로젝트를 활용해서 독자적인 PaaS를 개발하거나 구성해야 한다. 이미 클파는 상당히 완성도가 높은 제품이기 때문에 이를 활용해서 실전에 사용하는 것도 별 무리는 없을 듯 하다.

얘기가 샜네.. – -;

그동안 클파.com이나 마클파의 사용에만 관심을 가졌는데, 지난 달부터는 클파를 이용해서 나만의 PaaS 환경을 꾸려서 개발할 때도 쓰고 고객에 필요에 맞게 프라이빗 PaaS환경을 구축해주는 데도 사용하려고 마음을 먹고 클파를 들여다 보기 시작했다.

클파 프로젝트는 github(github.com/cloudfoundry)에 모두 올라와 있다.

프로젝트가 여러개인데, 그 중에서 vmc는 클라이언트에서 클파를 관리하고, 앱을 배포하고, 모니터링하는데 사용하는 클라이언트 툴이다. vcap은 VMWare Cloud Application Platform의 약자로, 클파 서버의 핵심이다. vcap-services에는 각 서비스의 gateway와 node가 들어있는데 vcap의 submodule이다. vcap-java는 vcap의 자바버전이 아니고, 스프링 프레임워크 지원기능이다. 클파는 런타임과 서비스외에 프레임워크 모듈이 있는데, 사용 프레임워크에 따라서 부가적인 기능을 제공하게 해줄 수 있다. 자세한 건 스프링소스 블로그에 4개의 시리즈로 연재되어있으니 그거 참고. vcap-java-client는 아마 STS의 클파 모듈에서 사용하는 자바 버전의 클라이언트 모듈인 것 같은데 한번도 안 들여다봐서 확실치는 않다.

아무튼, 이 프로젝트들을 잘 활용하면 나만의 클파, PaaS를 만들 수가 있다.

가장 먼저 해볼 일은 이 소스를 가지고 서버에 클파를 설치하는 것이다. 그리고 나서 서비스도 바꿔보고, 클파 소스도 건드려가며 자기가 원하는 최적의 PaaS환경을 만들면 된다.

그런데 클파가 간단히 설치가 될까? 그렇지 않다. 클파를 설치한다는 말부터 다시 생각해봐야 할 것 같다.

클파랑 가장 비슷한 것을 꼽자면 APM 서비스를 제공하는 웹호스팅인 것 같다. APM이 설치되어있고, ftp로 앱을 올릴 수 있고, 각종 웹기반의 어드민 툴을 이용해서 DB설정도 해주고 그런 것. 물론 클파는 APM보다 100배쯤 더 강력하고 편리하지만.

그럼 APM을 설치하고 싶다는 건 무슨 의밀까? OS까지는 설치됐다 치면, 두가지 방법이 있을 것이다. 하나는 사람들이 만들어 놓은 APM 한방설치 패키지를 이용하는 것이다. 나는 써본적 없지만 그런 패키지를 이용하는 사람들은 주변에 많이 봤다. 인스톨러 하나 돌리면 Apache, PHP, MySQL에 설정 프로그램까지 다 한번에 깔리는 것이다. 가장 편하다. 하지만 내가 아파치의 모듈을 좀 다르게 구성하고 싶거나, PHP 버전을 달리한다거나, MySQL도 다른 걸로 바꾸고 싶다면? 그러면 APM 한방설치 툴보다는, 각각의 서비스를 독립적으로 설치하고 설정을 통해서 이를 손쉽게 사용할 수 있도록 만드는게 낫다. 거기에 APM에 올라가는 앱을 관리하는 편리한 툴이 있으면 그걸 마지막으로 얹으면 원시적인 PaaS가 하나 완성되는 것이다.

클파도 마찬가지다. 만약 한방 설치가 가능한 패키지가 있다면, 또는 아예 설치가 완료된 VM 이미지가 있으면 그걸 올리면 가장 편할 거다. 하지만 그런 패키지는 없다. APM과 비교하면 훨씬 많은 서비스가 필요하고, 그렇기 때문에 OS 종류와 버전도 많이 탄다. 그래서 한방 설치는 힘들다. Ubuntu 11.10에는 apt-get으로 한번에 설치할 수 있는 cloudfoundry-server 패키지가 있긴 하지만, 클파 자체가 옛날 버전이라 최신 VMC랑 연결해서 사용해보면 잘 안 맞는다.

VCAP 프로젝트 페이지(https://github.com/cloudfoundry/vcap)를 열어보면 하단 문서에 install 스크립트를 사용하는 방법이 나와있다. Ubuntu 10.04 64bit 서버 버전이라면 이 인스톨 스크립트로 설치가 가능한 것처럼 되어있지만, 설치할 패키지를 모두 따로 모아두었다 그걸 가져와서 설치하는게 아니라 각각 서비스와 관련 툴을 직접 해당 홈페이지에서 가져와 빌드하는 것도 많이 있기 때문에 시간이 지나면 이런 스크립트로는 한방 설치가 어려워진다. 최근엔 업데이트도 잘 안해줘서 더욱 그렇고. 사실 이 인스톨 스크립트는 그냥 설치에 대한 가이드 정도로 참고해야지, 이걸로 설치해보고 안된다고 클파 꼬졀다고 하는 건, 철지난 APM 한방설치 인스톨러 가져다가 해보고는 설치 안된다고 APM 꼬졌네 하는 거랑 다를바 없다.

결국 제대로 클파를 다뤄보려면 필요한 컴포넌트와 서비스 등을 직접 구성하고, 최종적으로 이를 모두 연결해서 PaaS 서비스를 제공해주는 클파 핵심 컴포넌트를 셋업하고 사용할 줄 알아야 한다.

많은 사람들은 클파가 VMWare의 vSphere에만 깔리는 벤더 종속적인 제품이라고 오해하기도 하는데, 마클파랑 프라이빗 클파라면 모를까 오픈소스 클파는 아니다. 또, VCAP의 설치 스크립트나 안내만 보고 Ubuntu에만 설지된다고 하는 사람도 있는데 역시 잘못된 얘기다. 클파는 인프라 종류와 OS, 버전등에 종속적이지 않다. 실제 사용할 서비스만 제대로 구성해주고 클파가 동작하도록 루비환경만 잘 잡아주면 된다. 클파는 루비로 만들어졌거든.

아무튼, 그래서 지난 한달간 틈틈이 클파를 설치해봤는데, 기본 스크립트를 이용해서 Ubuntu 10.04에도 설치해봤고, Ubuntu 자체 패키지로 11.10에도 설치해봤고, 패키지 없이 직접 필요한 컴포넌트를 구성해가며 Ubuntu 11.10과 CentOS 6.0에도 설치했다. 너무 오래되지 않은 Linux 계열 OS라면 별 문제 없이 설치할 수 있다. OS X에도 당연히 잘 될거고. 조금 손을 보면 윈도 서버에도 가능할 것이라고 본다.

일단 클파를 서버 한대에 설치해서 사용해보고, 그리고 멀티 노드로 확장해보는 것도 재밌을 것이다. 클파는 내부에 여러 서비스 컴포넌트들이 있는데, 실제 앱을 설치하고 관리하는 DEA 같은 경우는 서버를 계속 확장해서 늘릴 수 있다. 당연히 MySQL이나 MongoDB같은 서비스도 별도의 서버에 셋업해도 되고. 클파 아키텍처가 매우 유연하기 때문에 원하는맘큼 손쉽게 확장할 수 있다. 클파 아키텍처에 관해선 http://www.springsource.org/node/3478 에서 잘 설명하고 있으니 이걸 보면 감이 잡힐 거다.

기본적으로 클파 서버 구성에 대한 가이드는 VCAP의 setup폴더에 있는 install과 vcap_setup 두개의 설치 스크립트를 참고하면 되는데, 이 두가지 다 좀 엉망이다. 현재 오픈소스로 공개된 vcap에서는 사용하지도 않는 서비스도 마구 깔고. 이리 저리 중복해서 까는 것도 있고. 아무튼 그대로 다 따라하면 쓸데없는 게 많이 깔린다. 클파를 기본적으로 구동하는데 필요로 하는 핵심만 골라서 설치하면 된다.

내가 구성해본 가장 기본 환경은 java, ruby(rails, sintra), node(0.4) 런타임에 mysql 정도인데, 일단 이정도로 시작하고 mongdo, rabbit, redis, neo4j 정도 붙여나가면서 만져보면 될 듯. staging plugin을 참고해서 django, grails, lift, php 등을 사용하도록 구성해봐도 좋을테고. 어쨌든 자기가 사용할 필요가 있는 서비스와 컴포넌트만 골라서 설치할 수 있으면 된다.

현재 vcap install 스크립트는 php, python도 설치하는데 아직 vcap에 바로 연결되는 것도 아니고, 당장 필요한 게 아니면 설치할 필요없다. 루비도 rvm으로 1.8.7과 1.9.2를 설치하고, 또 apt-get으로도 설치하는데. 그냥 rvm으로 1.9.2만 설치해도 충분하다. 나중에 staging 서비스 올라갈 때 manifests 보고 1.8을 찾는데 필요하지 않으면 그냥 manifests에서 1.8 항목을 지워도 그만.

Linux 서버를 어느 정도 다뤄본 사람이라면 install 스크립트 따라가면서 차근차근 설치해보면 어렵지 않을 것이다. 간혹 예전 버전을 설치한다거나, 앞에서 설치한 걸 또 깐다거나 하는 부분이 있는데 이런 건 상식적으로 생각해보고 생략하면 된다.

bin/vcap 실행 스크립트에서 Run 모듈의 self.services 메소드를 찾아서 서비스 항목을 빼주면 필요없는 gateway, node가 뜨지 않을 것이다. 또 스크립트에 버전이 명시된 것들도 있는데(erlang, redis, ruby 등등) 그냥 최신 버전 써도 아직은 별 문제되는 것을 못 봤다. 기본적으로 설치 스크립트는 Ubuntu 환경에서 돌아가는 것으로 작성되서, CentOS 등에서 설치하려면 필요한 라이브러리를 잘 찾아서 넣어줘야 한다. 빌드하다 에러나면 메시지 잘 보고 관련 패키지를(주로 –devel로 끝나는 라이브러리) 설치해주는 것으로 충분하다.

자기만의 클라우드 PaaS를 만들어서 사용해보고 싶은 사람이 있으면 한번쯤 서버환경을 꾸며 놓고(메모리만 넉넉하면 VMWare에 서버 설치하고 해봐도 될테고) 클파 깔아서 사용해보면 재밌을 것이다.

앞으로는 다양한 종류의 서비스와 런타임을 구성해보고 클파의 각 컴포넌트들이 어떻게 동작하는지 좀 더 연구해볼 생각이다.

혹시 비슷한 관심이 있는 분들이 있다면 작은 모임(클파사용자모임?)을 만들어서 서로 정보도 주고 받으며 교류해봐도 좋겠다.

이제 겨우 M2로 달려가고 있는 3.0의 빌드작업, Maven리포지토리로의 배포, 각 모듈과 라이브러리의 의존관계와 선택옵션에 대한 분석을 대략 마쳤다.

이제 할 작업은

  • 표준(혹은 권장) Spring POM 구성
  • 표준(혹은 권장) Spring Archetype 개발
  • 표준(혹은 권장) Spring Project Wizard 개발
  • Spring Learning Test & Reference Impl. 프로젝트 진행
  • 이런 작업의 결과를 준비하고 있는 스프링 3.0 서적에 적절히 포함시키기

이다.

초기에는 스프링 프로젝트를 새로 구성할 때 감에 의존해서 대충 라이브러리를 넣어서 만들었다. 그러다 클래스낫파운드 에러가 나면 그때 필요한 라이브러리를 다시 뒤져서 추가해서 돌아가면 쓰고 아니면 다시 시도하고 했다. 1.0시절에는 라이브러리도 얼마 되지 않았다. 모듈도 복잡하게 나눠져 있지 않았고.

점점 라이브러리가 증가하고 모듈도 복잡해지게된 2.x에서는 테스트-주도-라이브러리-찾기 방법을 사용해서 필요한 프로젝트를 구성했다. 사용할 기능을 넣은 테스트 코드를 만들고, 그것을 실행하기 위해서 필요로 하는 클래스를 포함한 jar파일을 검색해서 하나씩 추가해 넣고 사용했다.

프로젝트 하나 구성해놓고 쭉 가면 좋겠지만, 나처럼 스프링의 전반적인 기능을 한번씩 만져보고 다양한 샘플을 만들어가면서 공부하려는 사람에게는 그런 방법은 참 답답했다. 특히 그 많은 jar파일의 홍수 속에서 버벅대는 SVN과 삽질을 하다보면 새로 프로젝트 구성하는 작업 자체가 너무 짜증이 났다.

그래서 택한 방법이 Maven이었고, Archetype이었다. 나름 Maven POM에 내가 잘 사용하는 구성을 가진 표준 POM을 만들고, 최소한의 샘플코드와 설정을 담은 archetype을 만들어서 하루에도 여러차례 새로운 프로젝트를 만들어서 사용할 수 있었다.

하지만 다양한 기능의 조합을 사용하려고 할때마다 매번 수작업으로 POM의 라이브러리의 60여개가 넘는 라이브러리를 만져야 했고, Central 리포지토리에 올라온 엉망인 transitive dep. 설정 때문에 짜증나는 exclude처리도 해야 했다. 그냥 모듈과 라이브러리 몽땅 집어넣고 썼으면 했을 때가 많았던 것 같다.

AppFuse같은 스타트업 툴 조차도 거의 일반적으로 사용하는 라이브러리를 몽땅 가져다가 넣는 것으로 해결을 봤다. 기껏 웹 프레임워크로 구분을 했을 뿐이고. 그것도 2.x에 와서는 별로 인기를 끌지 못했다. (동국이가 넣은 오류가 있는 한글 메시지 파일 때문에도 꽤 고생했던 기억이… 고쳤나 모르겠네)

그때부터 구상했던 것이 일종의 wizard 방식으로 스프링의 프로젝트 구성을 해주는 툴이었다.

Maven의 archetype은 아주 단순하고 고정된 스타일의 프로젝트에 겨우 사용할만 한 수준이기 때문에 애초부터 고려의 대상이 아니었다. 물론 그만큼도 해주는 것이 없으니 일단 사용하긴 했지만 말이다.

이클립스의 프로젝트 위저드 기능 정도의 인터렉티브한 세팅을 통해서 프로젝트가 만들어지는 것이 이상적일 것이다. 그렇다고 해도 100여개가 넘는 라이브러리와 모듈을 버전이 바뀜에도 계속 가지고 있는 플러그인을 만드는 것도 문제가 있다. 결국 Maven이나 Ant/Ivy의 사용은 필수이다.

고맙게도 SpringSource가 OSGi/DM을 띄우기 위해서 다양한 라이브러리를 재패키징 해서 리포지토리를 통해서 제공하고 있다. Exclude 삽질을 안해도 되서 얼마나 고마운지 모르겠다.

남은 것은 그 백여개 + 스프링에서 직접 제공하지 않지만 많이 사용되는 프레임워크 등의 수많은 조합들을 커버할 수 있을만한 POM의 구성 또는 다이나믹 생성 툴이다.

 

표준(혹은 권장) Spring POM 구성

그것을 위해서 일차적으로 표준 POM을 구성해봤다. 18개의 모듈을 직접 매 프로젝트에 넣고, 60여개가 넘는 선택 라이브러리(필수나 provided는 빼고)를 매번 선택하는 것은 별로 바람직하지 않을 것이다. 따라서 그것을 최소한의 공통 조합으로 정리하고 POM으로 만들었다.

떠오르는(과연…) 스프링 중심 오픈소스 프로젝트 그룹인 OpenSprout를 통해서 opensproutpom이라는 표준 POM을 제공한다.

여기에는 거의 대부분의 애플리케이션에서 사용하는 공통 스프링 기능을 담은 core, 그리고 선택적 모듈인 aspects, context.support, jms, orm(내부에 hibernate, jdo, jpa(내부에 다시 벤더별로…)), oxm(라이브러리별로), web.servlet, web.portlet의 옵셔널 POM으로 구성된다.

예를 들어서 스프링을 JDBC를 이용해서 DB액세스하며 표준 AOP를 사용하면서 애플리케이션 컨텍트스 방식으로 쓸 것이라면 Core만 있으면 된다. 거기다 하이버네이트 ORM을 쓰고 싶으면 Hibernate POM을, SpringMVC를 사용하고 싶으면 web.servlet POM을 넣으면 된다. 각각의 선택적인 기능은 해당 POM의 옵션을 다시 재구성할 수 있다.

물론 스프링의 세부 모듈 POM을 가지고 일일히 설정해도 되지만, 지난 며칠간 분석해본 것처럼 모든 선택 라이브러리가 사실상 표준인 것도 많다. 구지 Core, Beans, Context 따위는 일일히 따로 설정하는 것 자체가 번거로운 삽질일 뿐이다. 이렇게 분석의 결과를 토대로 표준(이라고 하면 좀 이상해서 권장이라고 할까도 생각중..) 스프링 애플리케이션 POM을 제공한다. Ivy.xml도 제공해야겠고.

현재 만들어진 POM의 목록은 다음과 같다. 타이핑하기 귀찮아서 Maven 로그를 복사.

[INFO] opensproutpom ………………………………….. SUCCESS [3.547s]
[INFO] basepom ……………………………………….. SUCCESS [0.172s]
[INFO] springpom ……………………………………… SUCCESS [0.015s]
[INFO] springpom.core …………………………………. SUCCESS [0.000s]
[INFO] springpom.aspects ………………………………. SUCCESS [0.031s]
[INFO] springpom.contextsupport ………………………… SUCCESS [0.031s]
[INFO] springpom.jms ………………………………….. SUCCESS [0.032s]
[INFO] springpom.orm ………………………………….. SUCCESS [0.031s]
[INFO] springpom.orm.hibernate …………………………. SUCCESS [0.015s]
[INFO] springpom.orm.jpa ………………………………. SUCCESS [0.016s]
[INFO] springpom.orm.jpa.eclipselink ……………………. SUCCESS [0.000s]
[INFO] springpom.orm.jpa.toplink ……………………….. SUCCESS [0.016s]
[INFO] springpom.orm.jpa.openjpa ……………………….. SUCCESS [0.015s]
[INFO] springpom.orm.jpa.toplink ……………………….. SUCCESS [0.000s]
[INFO] springpom.orm.jdo ………………………………. SUCCESS [0.016s]
[INFO] springpom.oxm ………………………………….. SUCCESS [0.031s]
[INFO] springpom.oxm.castor ……………………………. SUCCESS [0.016s]
[INFO] springpom.oxm.jibx ……………………………… SUCCESS [0.000s]
[INFO] springpom.oxm.xmlbeans ………………………….. SUCCESS [0.015s]
[INFO] springpom.oxm.xstream …………………………… SUCCESS [0.000s]
[INFO] springpom.oxm.jaxb2 …………………………….. SUCCESS [0.016s]
[INFO] springpom.webservlet ……………………………. SUCCESS [0.047s]
[INFO] springpom.webservlet.webportlet ………………….. SUCCESS [0.016s]

여기까지가 첫번째 작업.

 

표준(혹은 권장) Spring Archetype 개발

Maven의 아키타입은 기능의 제한이 너무 많고, 작성하기가 워낙 까다롭고 번거로워서 피하고 싶지만, 그래도 몇줄 입력하는 것으로 프로젝트 하나를 뚝딱 구성할 수 있는 것은 아직 이것뿐이다. 일단 내가 주로 사용하는 구성을 이용해서 표준 프로젝트 스타트업 샘플을 만들고, AppFuse처럼 archetype으로 구성한다. 다양한 학습용 프로젝트에서 사용할 수 있겠지.

 

표준(혹은 권장) Spring Project Wizard 개발

이게 사실 궁극적으로 하고 싶은 것이다. 이클립스 플러그인으로 프로젝트 위저드를 개발하는 것이다.

스프링의 사용하고자 하는 기능을 자유롭게 선택하면 그것에 최적화된 구성으로 프로젝트를 만들어주는 것이다. Maven이나 Ivy방식으로 다운로드 가능하게 구성 할 수도 있고, 또는 직접 라이브러리를 프로젝트에 다운해서 포함시켜주는 것도 가능할 것이다. 또 사용하려고 하는 기능을 구현한 최소한의 참조 코드와 기본 설정도 만들어진 프로젝트에 제공해주는 것이다.

이 정도 기능이 있다면 초보자 뿐 아니라 고급 사용자도 쉽게 새로운 프로젝트를 깔끔한 설정을 가진 구조로 쉽게(길어야 선택까지 해서 1분이면 되겠지) 만들어 사용할 수 있을 것이다.

이건 아무래도 좀 시간이 걸릴 작업이지만, 아무튼 올해 초반에 꼭 만들어서 공개하고 싶다.

 

Spring Learning Test & Reference Impl. 프로젝트 진행

스프링의 기능을 분석하고 공부하기 위한 학습테스트와 참조구현 프로젝트를 진행하는 것도 여기에 연결이 될 것이다. 그동안 비공개로 개인적으로 학습테스트를 만들어왔는데, 이번에는 오픈소스 프로젝트로 구성해서 여러 사람이 함께 진행해보는 것이 어떨까 하는 기대도 해본다. (과연…)

학습테스트에서는 단순한 테스트 코드로 기능을 적용해볼 수도 있겠지만, 간단하더라도 하나의 완성된 애플리케이션으로 만들어봐야 할 경우가 많다. 그런면에서 참조구현이 될 수도 있지 않을까 싶다. 영회가 몇년전부터 하겠다고 큰소리 쳐온 것이 바로 스프링의 Ref. Impl인데.. 이번에 과연 참여할 것인가 모르겠다. 아마도.. !@#%$%^

Maven의 멀티모듈 프로젝트가 그런면에서 매우 효과적이다. M2Eclipse의 지원도 빵빵하고, 또 오픈소스 프로젝트 한다고 받은 IDEA 라이센스도 있으니 그것도 한번 써봐야겠다.

 

이런 작업의 결과를 준비하고 있는 스프링 3.0 서적에 적절히 포함시키기

Spring 3.0을 기준으로 책을 쓰고 있다. 개념설명하고 주요한 API 레퍼런스처럼 나열하다보면 끝날 수도 있다. 하지만 그런 두터운 책을 가지고도 자신이 원하는 프로젝트를 스프링의 필요한 기능을 가져다가 구성하고 사용할 수 없다는 것이 비극이다. 아마 3.0 시리즈로 쓰는 글에 등장했던 자료들이 좀 더 다듬어져서 스프링의 실제적인 사용전략과 참고정보로 책에 들어갈 것이다. 그 책에서는 적어도 초보자가 자신이 사용하고 싶은 기능을 가진 스프링 프로젝트를 스스로의 힘으로 만들어서 사용할 수 있도록은 도와줄 테니까.

뭐 이름은 바꿀 생각이지만 처음에 Agile Java 책에서 따온 Agile Spring이라는 이름을 썼던 것에서 알 수 있듯이,  이 책에서 설명하는 대부분의 스프링 기능은 그것을 확인해볼 수 있는 테스트코드가 함께 제공될 것이다. 바로 학습테스트이다. 테스트를 만들지 않으면서 스프링을 제대로 쓴다고 하지 마라.. 이게 책에서 끊임없이 강조할 내용이다.

차근 차근 해보자.

SpringOne 2007 첫째날이 지나갔다. SpringOne은 TheSpringExperience와 함께 스프링 프레임워크와 관련기술만 을 전문적으로 다루는 국제적인 컨퍼런스이다. TSE는 매년 겨울에 미국에서 열리고, SpringOne은 여름에 유럽에서 개최된다. 오래전부터 JavaPolis라는 유럽의 대표적인 자바컨퍼런스를 주관해온 BeJUG(벨기에 자바유저그룹)이 주관하는 또 하나의 국제컨펀런스이다.

IMG_0009.JPG

오프닝 키노트는 스프링의 아버지이자 Interface21의 CEO인 로드존슨에 의해서 시작됐다. 최근 스프링을 둘러싼 가장 큰 관심사는 바로 최근에 벤처캐피탈로부터 천만달러의 투자를 받은 Interface21의 앞으로의 행보와 그에 따른 스프링의 변화가 어떤 것이냐 하는 것이다.

IMG_0031.JPG

사실 오픈소스 개발은 그 자체로는 아무런 수익을 기대할 수 없다. 따라서 Interface21은 스프링 프레임워크 자체의 개발에 많은 시간을 사용하기는 하지만 동시에 컨설팅이나 교육과 같은 수익 사업을 해야했다. 방대한 분량의 프레임워크를 미션크리티컬한 시스템에서도 안정적이고 신뢰성 있게 사용할 만큼 완벽하게 개발하고 발전시키는 일은 매우 힘든 일일 것이다. 스프링은 그 규모와 명성에 비해서는 사실 소규모의 개발자에 의해서 개발되어왔다. 스프링의 핵심 프레임워크를 개발하는 개발업무의 FTE(Full Time Equivalent)를 산정하면 1이라고 한다. 다른 일을 병행해야 하는 스프링 개발자들이 순수하게 스프링 프레임워크의 개발에 투자할 수 있는 시간은 다 합쳐서 겨우 1명이 풀타임으로 일하는 수준이라는 것이다. 그런면에서 최근에 스프링의 개발 이슈트래커를 보는 내 마음이 사실 답답했다. 코어 프레임워크의 경우 거의 90%이상이 유겐횔러 한 사람에 의해서 개발된다. 거의 대부분의 개발태스크가 다 그에게 할당되어있다. 그러는 사이 약 500여개에 달하는 사용자들의 많은 요구사항과 패치들이 아직 제대로 검토도 못된 채로 오랜 시간 방치되어있는 상태였다.

그런면에서 로드존슨의 이번 투자유치 결정은 상당히 중요한 의미를 가진다. 로드존슨은 투자받은 자금의 상당 부분은 스프링 프레임워크의 개발자들이 개발자체에 전념할 수 있도록 하는데 사용하겠다고 했다. 1FTE였던 코어프레임워크의 개발수준을 3FTE로 올리겠다고 했다. 역시 1FTE였던 SpringWeb(SpringMVC+SpringWebFlow)는 5FTE로 향상시킨다. 이제까지는 전임 개발자는 없고 contribution에 의해서만 개발되던 Spring.NET은 1FTE+contribution의 형태로 발전한다. 그를 위해서 Spring.NET의 개발자가 Interface21에 조인했다.

이렇게 스프링 자체를 좀 더 빠르게 발전하면서도 안정적이고 견고하게 만들어나가는데 투자된 자금의 상당 부분이 사용될 것이다.

또 다른 사용용도로 제시된 것은 비기술직 스태프의 확충이다. 스프링과 Interface21이 주요 타겟으로 하고 있는 Fortune 500업체들을 상대하며 발전하기 위해서 홍보, 법률, 운영, 마케팅, 비서 업무와 같은 분야의 직원을 영입하고 본격적인 시장진출을 위해서 실리콘벨리에 미국HQ를 만들기로 했다. 이제로드 존슨은 주로 미국에 상주하면서 실리콘벨리의 업체와의 협력이나 대규모 고객들을 관리하는 일을 담당하게 될 것이라고 한다.

개발팀도 개발센터를 만들어 모여서 함께 작업할 수 있는 구조로 발전했다고 한다. 코어 개발은 영국의 한 지역에 개발팀이 모여서 작업을 하고 웹팀은 미국 플로리다에, 툴 팀은 캐나다 뱅쿠버에 오피스를 두고 개발업무를 담당하는 구조로 활동한다.상당히 글로벌한 개발, 운영 조직으로 변모하는 것으로 볼 수 있다.

결과적으로 이번에 투자되는 벤처자금은 보다 나은 스프링을 개발하고 많은 협력파트너와의 협업과 스프링의 보다 폭 넓은 적용을 위해서 사용하는 것이다.

이번에 투자를 결정한 Benchmark라는 벤처캐피털은 오픈소스 프로젝트에 대한 투자로 유명한 회사이다. 이미 RedHat, JBoss, MySQL 등의 오픈소스 기반 업체에 대한 투자를 성공적으로 했고, eBay와 Second Life의 투자도 담당했던 회사이기도 하다. Benchmark의 투자담당자가 가장 주목한 부분은 바로 스프링이 가지고 있는 견고한 커뮤니티라고 한다. 그가 했다는 말이 인상적이다. “커뮤니티는 결코 많은 돈으로도 살 수 없는 것입니다”.

로드존슨은 이어서 스프링과 협력하는 파트너 회사들에 대한 소개를 해줬다. 이미 잘 알려진대로 BEA, Oracle, IBM, GigaSpace 같은 회사들이 스프링을 최신 제품의 핵심기술로 사용하고 전략적인 파트너쉽을 가지고 Interface21과 함께 일하고 있다. BEA의 WebLogic10서버가 스프링을 코어로 사용하고 있고 WebLogic의 EJB가 스프링 빈으로 만들어진다는 것은 흥미롭다. 더 나가서 고성능의 리얼타임 서버를 위해서 만들어진 WebLogic Event Server도 그 서비스를 스프링으로 만들어서 동작하도록 설계되어있다고 한다. Oracle의 차세대 미들웨어도 스프링 기반으로 되어있으며 TopLink팀과 Interface21의 협력도 잘 알려져 있다. Oracle Depot라는 최근에 소개된 사이트는 스프링 기반으로 개발되었다고 한다. IBM은 IBM WebSphere의 공식인증기술로 스프링이 사용될 수 있도록 Interface21과 협력해서 인증프로세스를 진행하고 있다고 한다. 고성능의 안정적인 기술을 검증하는 복잡한 프로세스인데 스프링의 모든 기능을 그에 맞게 진행하고 있다. 아마 다음번 IBM의 표준 개발 프레임워크는 스프링이 되자 않을까 싶다.

이어서 새롭게 Spring.NET의 간단한 데모가 이어졌다. Visual Studio에서 동작하는 스프링의 코드가 무척 신선했다. 거의 핵심적인 스프링의 모든 기능이 이미 Spring.NET에 다 구현되어있다. Spring.NET과 NHibernate가 .NET에도 오픈소스의 바람을 일으킬지는 지켜봐야 할 일이다. 로드존슨은 지난 MS TehEd에서 Spring.NET을 발표했다고 한다. MS외의 개발자를 강사로 잘 세우지 않는 TechEd의 특징을 본다면 Spring.NET에 대한 MS의 관심 또는 흥미가 어느정도인지 알 수 있을 것이다. 덕분에 로드존슨은 99년 이후로 한번도 만져보지 않은 Visual Studio를 써봤다고.

다음으로 Ben Hale이 SpringWebFlow에 대한 간단한 시연을 했다. 작년에는 키노트에 SpringMVC를 시연 했었는데 이제 SWF로 바뀌었다. 그 자체로 뛰어나긴 하지만 로우레벨 MVC 프레임워크로 제한적인 SpringMVC보다 이제는 보다 추상적이고 웹개발에 필요한 다양한 기능을 제공하는 SWF가 스프링의 본격적인 스프링의 웹 기술로 사용될 것으로 예상된다.

IMG_0036.JPG

다음에 소개된 것은 SpringBatch. SpringBatch는 메인프레임이 주도하는 대규모 배치, 백엔드 시장을 타겟으로 만들어진 스프링의 새로운 모듈이다. 작년에 영국의 송금전문백본업무를 담당하는 VOCA라는 곳이 메인프레임 기반에서 스프링 기반으로 새롭게 애플리케이션을 재구축하고 성공적으로 운영되어서 화제가 됐었다. 한해에 수십조에 달하는 이런 대규모 배치시장에 스프링이 본격적인 도전을 시작했다.

마지막으로 Spring2.1에 관한 소개. 스프링2.1은 7월 말에 파이널이 나온다고 한다. 생각했던 대로 지금 쓰고 있는 책은 스프링2.1을 타겟으로 할 수 있을 것 같다. Spring2.1의 가장큰 변화는 지금까지 XML이 주로 사용되왔던 스프링 빈 설정을 자바5의 어노테이션을 이용해서 할 수 있도록 만든 것이다. 어노테이션 설정의 도입에 관해서 로드존슨은 간단히 “고객과 엔드유저가 원하는 것이 옳은 것이다”라는 말로 간결히 설명했다. 뭐 더 논쟁이 필요할까.

스프링2.1의 또 다른 주요기능으로는 SCA의 지원이다. 스프링 빈을 간단하게 SCA composite형태로 제공하는 기능을 제공한다. 또 다른 한가지는 JPA지원의 확장이라고 한다. 그 밖에 스프링을 더 편하게 쓸 수 있도록 하는 많은 기능이 추가됐다. 마일스톤상 다음 버전이 3.0이니 스프링 프레임워크는 2.1에서 한동안 지속될 것이다.

마지막으로 로드존슨은 스프링의 앞으로의 모습을 The Eclipse Effect라는 것으로 설명했다. IDE영역에는 사실상의 표준기술로 자리잡은 Eclipse라는 주도적인 제품이 있고 그것을 중심으로 커뮤니티와 벤더와 유저가 기술을 발전시켜나가며 통일된 모습을 보여주는 것을 Eclipse Effect라고 설명했는데 Enterprise Java영역에는 스프링이 그 역할을 담당하게 될 것으로 기대한다고 했다. 대단한 자신감이다.

첫번째 세션은 Chris Richardson의 Improving application design with a rich domain model.

IMG_0066.JPG

스 프링을 처음 사용하던 시절부터 관심있게 보던 블로그의 주인공이다. 작년에는 POJO In Action이라는 책도 내놓았다. 발표내용은 아주 기초적인 것이었다. Procedural 스타일의 Fat Service를 리팩토링을 통해서 Rich Domain 기반의 Thin Service모델로 바꾸는 것을 실제 예를 통해서 설명했줬다.

기억에 남는 특이한 주장은 @Configurable이나 @Transactional 어노테션을 가능하면 사용하지 말라는 것. 이유는 어노테이션이 달린 오브젝트는 POJO가 아니기 때문이다. Adrian Colyer의 주장과 완전히 배치되는 것이지만 나름 일리가 있다. @Configurable을 사용하지 말아야 하는 또다른 이유는 LTW가 가지는 성능저하. 차라리 Hibernate Interceptor나 Manual Injection을 사용하라고 했다. 사실 그렇게 만들어 쓰기엔 너무 번거롭다고 생각되지만 크리스는 service레이어가 없는 완전한 Domain중심의 아키텍처보다는 어느정도의 로직과 facade역할을 서비스가 담당하게 하고 순수한 로직만을 domain object에 넣자는 중도적인 입장이다. 이럴 경우 repository나 다른 service와 도메인간의 커뮤니케이션은 주로 service가 담당하게 될테니 사실 특별한 서비스 등에 의존적이지 않는한 domain object에 injection을 사용할 필요는 없을 것이다.

매우 차분하고 조용조용히 이야기하는 모습이 인상적이었다. 반응은.. 그다지. 사실 hard-core DDD에 대한 전략이나 이슈들을 다뤘으면 하는 기대가 많았을 텐데 너무 기초적인 내용이라…

그 다음 시간은 BEA의 EJB 팀 리더이자 OpenJPA 프로젝트의 리더이기도한 Patrick Linskey의 Writing JPA application 시간. 사실 JPA에는 깊은 관심을 가지지 못해서 기존에 쓰던 Hibernate와의 차이가 무엇인지 듣고 싶었다. Hibernate3를 쓰는 사람에게라면 사실 큰 차이는 없는 것 같다. 흥미로운 것은 상당히 많은 내용이 JPA spec자체에는 없다는 것. EJB의 느슨한 스펙과 비슷하게 느껴진다. Perssimistic locking, caching을 포함한 많은 기존 JPA 스펙에 없는 것들이 다음 버전에는 추가된다고 한다. 어느 세월에 다음 버전을 기다릴 수 있을까. 결국 JPA도 본격적으로 쓰려면 특정 구현에 종속적으로 갈 수 밖에 없지 않은가 생각된다.

IMG_0068.JPG

Annotation방식의 매핑은 사실 대형 시스템에는 적합하지 않다는 설명도 있었다. 이미 EJB3의 어노테이션은 “낚시”에 불과하다는 것을 알고있다. 제대로 된 본격적인 시스템을 개발하려면 복잡한 xml설정이 필수이다. JPA의 xml 사용은 조금 다른 의미를 가진다. JPA의 매핑 어노테이션은 그 자체로 충분한 기능을 제공한다. 그럼에도 어노테이션보다는 XML이 권장되는 이유는 환경마다 다른 설정을 위해서이다. 메타데이터를 분리해야하는 그런 케이스들이 많기 때문이다. 어느 정도 규모를 가진 시스템이라면 DTAP(development, test, accepance, production)의 각 단계마다 각기 다른 매핑설정을 사용할 가능성이 높다. 그런경우 XML만을 사용해서각 단계의 설정을 독립시키거나 annotation + xml의 혼합모델을 사용하는 것이 바람직하다른 것.

다음은 SCA. Interface21의 CTO인 Adrian Colyer의 발표. 서비스 컴포넌트의 생성과 조합, 연동에 관한 언어 독립적인 프로그래밍 모델이다. 흥미로운 내용이긴 하지만 과연 기존의 수많이 등장했던 모델들보다 어떤 장점이 있는지는 잘 모르겠다. 스프링은 빈을 그대로 SCA composite으로 노출 할 수 있다. SCA의 성공여부는 좀 더 지켜봐야겠다. 자칫 대형 벤더들의 비싼 솔루션 판매용 미끼로 사용되어지는 것은 아닐런지…

다음은 최근 오라클에 인수된 Tangosol의 Coherence에 대한 시간. Data Grids – Extreme Transaction Processing Infrastructure for Spring Applications. Coherence의 동작원리에 대해서 시물레이션을 통해서 상세하게 설명을 들었는데 나름 흥미롭다. 마스터/슬레이브나, 허브 방식이 아닌 P2P구조로 메인, 백업을 유지하는 구조로 최적화해서 동작한다고 한다. 하이버네이트나 스프링과도 잘 연동되고. 관심이 가긴 하는데 오라클 솔루션이 된 후로 가격정책이 오리무중이다. 발표자도 잘 모른다고 한다. 브랜드가 붙으니 뻥튀기 될라나…

IMG_0082.JPG

마치막 세션은 Pragmatic SOA – Substance, not hype.

SOA에 관한 오랜 경험을 가진 Arjen Poutsma에 의해서 진행. Arjen은 작년 SpringOne에서 “SOA에서 가장 중요한 것은…. 사랑” 이라는 명언을 남긴 사람으로 기억한다. 이번에도 기억에 남는 말을 하나 남겼다. “SOAP over HTTP는 SOA의 가장 최악의 기술이다”. 차라리 JMS나 email을 쓰란다. 2000년 TechEd에서 SOAP에 대해서 자랑스럽게 소개하던 Don Box가 생각난다. 한때는 가장 좋아하는 사람이었는데 MS로 들어가면서 사람이 다 망가져버렸다.

그밖에,

유럽에서 열리는 컨퍼런스가 미국에서 열리는 것과 결정적으로 다른 것은 모이는 사람들이 다 영어로만 대화하지 않는다는 것. 유럽 25개국에서 온 사람들이 모여있는데 사실 자기들끼리는 영어보다는 더 편하게 얘기할 수 있는 언어가 많은 것 같다. 개인적으로 영어로 얘기하면 어짜피 같이 버벅대니 더 편하긴 한데, 쉬는 시간에 한참 떠들고 있는 사람들이 있어서 좀 껴볼라면 이건 외계어! 아침엔 노르웨이에서 온 Espen이라는 착하게 생긴 놈과 얘기를 나누었다. 스프링을 처음 도입하려고 하면 고객이나 컨설팅 업체에서 거부감도 보이고 싫어하기도 했지만 결국엔 다들 만족하고 좋아했다는 데에 공감. 저녁에는 파티가 있었다. 프랑스에서온 이름은 기억나지 않지만 무척이나 친절하고 매너좋은 사람과 얘기를 나누었다. 한국에서 왔다는 것에 매우 놀라는 듯. 이번 컨퍼런스에는 동양인이 전혀 보이지 않는다. 그나마 한 명 만난 사람은 중국계 벨기에인.

IMG_0095.JPG

컨퍼런스 장소는 Metropolis Business Center라는 곳인데, 2층은 25개 관을 가진 대형 멀티플렉스 극장이다. 세션은 모두 극장의 몇개관을 이용해서 진행한다. 극장이라 스크린이 무지 크고 좌석도 계단식이라 스크린이 잘 보여서 편리하다. 이클립스의 폰트를 키우지 않아도 제일 뒷자리에서도 잘 보인다. 의자도 푹신한게 잠겨서 잠들기 딱 좋다. 이런 데는극장이 항상 꽉 차는게 아닐테니 이렇게 운영하는 것도 나쁘지 않은 것 같다. 한국이라면 어림 없을테지.

IMG_0071.JPG

거의 없다고 본다.

과격한 얘기인 것 같지만 그게 현실이다.

자신이 오픈소스 소프트웨어를 사용하는(OS,애플리케이션,프레임워크,라이브러리 뭐든지…) 사람이라면 가슴에 손을 얹고 생각해보자. 그 소스코드를 제대로 들여다 본적이 얼마나 되는가? 그 소스를 수정하거나 개선한 적은? 하다못해 버그리포트나 패치 제출이라도 해본적은?

공개된 소스라는 것은 대부분의 개발자들에겐 오픈소스를 쓴다고 폼낼 때 언급할 수 있는 허울 좋은 장식품일 뿐이다. 소스코드를 통한(학습,개선,개발.. 뭐든) 개발자의 실력향상? 나도 한 때는 그런 얘기를 하고 다녔다는게 요즘은 그 사실이 부끄럽기만 하다.

왜 소스코드가 공개된 오픈소스인데 코드를 잘 안볼까?

일단 관심이 없다.

가져다 쓰기도 바쁘다. 아니 가져다 쓰는 것도 제대로 안하는 경우가 더 많다. 오픈소스 라이브러리의 평균 기능 활용률이 5%라고 한다. 코드 작성하기도 바쁜 오픈소스개발자들과 기여자들이 힘들게 만들어준 사용자 매뉴얼, 레퍼런스 매뉴얼, 각종 API문서들. 절대로 안읽는다. 여기서 걸리는 사람이 일단 대부분.

그래도 자신은 오픈소스 (를 사용하는) 개발자던가, 전문가라던가, 관심이 많다던가 하면 요즘 최신유행에 앞서나가는 사람 같아 보이니 오픈소스에 대한 관심은 무지 많다. 이왕이면 좀 이름있고 유명한 제품을 쓰거나 관심을 가지려고 노력한다. 물론 그 품질과 가치는 구지 큰 상관이 없이 말이다.

소수의 개발자들이 이것을 극복하고 코드에 관심을 가져본다.

그리고 코드를 다운받거나 리포지토리에서 가져와 열어본다. 그리고 금방 좌절한다.

완벽한 설계문서와 커멘트가 달린 코드를 분석한다고 해도 그것이 얼마나 어려운 작업인지는 남이 만든 코드랑 씨름해본 사람은 잘 알 것이다. 하물며 이건 설계문서 따위는 기대도 안하겠고 제대로 된 API설명이나 코멘트도 구경하기 힘든게 거의 대부분의 오픈소스 코드들이다. (물론 예외는 분명 있다. 시비걸지 말자) 또 오픈소스제품이라고 코드의 품질이 좋다는 것은 환상일 뿐이다. 오픈걸레코드라고 부르고 싶은 코드들도 아주 많다. 오죽하면 기존의 무슨무슨 제품 코드가 손을 댈 수 없을 만큼 지저분해서 완전 새로 만들었어요하며 등장하는 제품이 그렇게도 많을까. 넷스케이프 소스가 공개되었을때 얼마나 광분했었던가 그 소스코드를 컴파일하려면 메모리가 더 필요하다고 해서 한동안 메모리 추가하는 개발자들이 많았다. 그런데 결과적으로 그 소스코드는 도저히 손댈 수 없는 스파게티+암호 코드. 결국 모질라 프로젝트는 맨땅에서 다시 시작했다고 한다. 어이가 없지만 사실이다.

설계문서가 없을때 코드의 제작의도와 디자인을 그나마 알 수 있는 것이 바로 테스트이다. 테스트코드! TDD가 유행한지도 한참됐고 제대로된 QA팀도 없으니 오픈소스는 테스트코드가 잘 만들어져있을꺼야라는 생각으로 유명 오픈소스제품의 코드의 테스트코드를 집중적으로 뒤져본 적이 있다. 결론은 한심한 수준이다. 오픈소스코드를 통해서 테스트코드 작성기법이나 TDD를 배우자라는 꿈은 바로 접는게 좋을 듯 하다. 얼마전에 TDD메일링리스트에서도 비슷한 얘기가 나온적이 있는데 결론은 별로 참고할만한게 없다이다.

그중에서 그나마 코드 품질이 좀 낫다고 생각하는 코드를 본격적으로 살펴보기 시작했다고 하자. 그래도 별 도움이 안된다. 코드만 가지고 전체 설계구조를 그려서 이해하기가 쉽지 않다. 제대로 분석하고 공부하려면 시간이 상당히 걸린다.

결론은 오픈소스 코드는 거의 대부분의 개발자에게는 별 도움도 안되고 상관도 없다. 엘리트 개발자들에게는 물론 예외겠지만.

내 얘기를 해보자면,

내가 처음 프로그래밍을 배우던 80년대 초중반에는 각종 컴퓨터잡지와 서적은 온통 소스코드로 가득차있었다. 하루 종일 책에 나온 코드를 입력하고 실행해보고 이리저리 만져보고 분석해보고 하는게 유일한 할 일이었다. 나는 처음에 플로피디스크도 없는 애플II를 사용해서 게임도 못했고 온종일 코드입력과 분석을 통한 공부만 했다.

그러던 어느날 애플에 기본으로 탑재된 정수베이직(Apple Integer Basic인가 이름이 잘 기억이 안난다)의 소스코드가 통채로 실린 책을 발견했다. 6502어셈블리코드가 수백페이지 가득찬 그 책이 한동안 나의 보물이었다. 그게 정말 개발한 개발자들이 공개한 코드인지 디스어셈블한 코드를 리버스엔지니어링적으로 분석해서 재구성한 코드였는지는 잘 모르겠지만 아무튼 당시로는 가장 규모있는 제품의 소스코드였다. 나이는 어렸지만 코드를 읽는 것의 재미에 푹 빠져 살던 때였다.

내가 가장 많은 소스코드를 접했던 마소잡지에 어느날 한글과 관련된 무슨 라이브러리 기사가 나면서 황당하게도 소스코드가 없다는 것을 알았다. 정XX라는 유명한 개발자가 왜 내 소스를 니들이 다 보려느냐면서 바이너리만 달랑 이달의 디스켓으로 제공하고 소스를 공개를 안했던 것이다. 그때 얼마나 분개했던지.

그 후로 소스코드도 저작권이 있는 사유재산이라 함부로 공개해달라고 할 수도 없으며 아예 구경조차 못하고 바이너리만 구해서 써야하는 것이 당연해지는 시기가 다가왔다. 이찬진씨의 마소에 연재된 컴퓨터에서 쓰는 한글에 관한 연구인가 하는 글과 관련코드자료를 볼때는 이러다가 워드프로세서 코드를 공개해주는 것이 아닐까 하고 엄청나게 기대했었는데.. 몇개월 뒤 공개된 아래아한글이라는 제품은 역시나 소스가 없는 바이너리뿐. 게다가 상용이라. -_-

그 후로는 그저 공개된 API스펙을 보고 SDK를 이용하는 식의 개발에 빠져살았다.

그러다 리눅스를 만났다. 공개된 OS의 소스코드가 있다는 사실에 놀랐다. 나도 커널도 만져보고 나만의 OS도 만들어보고 하는 꿈에 빠져 한동안 살았다. 하지만 설치하기도 너무 벅찬 (최초로 486에 리눅스 설치할때 거의 일주일이 걸렸다) 리눅스는 그 커널소스를 몇번 보다가 이해도 잘 안되고 귀찮아서 덮어버렸다.

그리고는 한동안 MS기술에 푹 빠져 살다보니 오픈소스에 대한 관심은 멀어졌다. 리눅스는 쭉 써왔지만 파워유저 또는 서버관리자 이상의 관심을 가지지는 않았다. 많은 경우 소스를 받아서 컴파일을 해서 썼지만 그 소스를 열어본 적은 거의 없다. 특히 C소스의 경우 읽기가 난해한 경우가 대부분이었다. CMU SNMP소스를 가져다 고쳐서 제품을 개발해야했던 때를 빼면 거의 관심을 두지 않았던 것 같다.

그러다 우연히 H****NetKorea이라는 회사에서 의뢰를 받아서 일본의 개발자들이 만든(그러나 더 이상 기술지원을 안해주는) 소스코드를 분석해서 설계자료와 앞으로 수정과 유지보수에 필요한 자료를 만들어주는 일을 한적이 있다. 거의 한달가까이 매일 밤을 새며 씨름하면서 수만라인의 C소스 코드를 분석해서 수백페이지짜리 자료를 만들어서 건네주었다. 기술적으로 매우 난해한 코드였지만 코드를 분석하는 즐거움을 다시 경험했던 시간으로 기억에 남는다.

그리고…

드디어 자바세계로 발을 들이고 나서. 톰캣을 비롯한 오픈소스 제품을 사용하기 시작했다. 하지만 소스에 대한 관심은 전혀 없었다. 쓰기도 바쁘니까.

그러다가 결국 소스코드를 다운 받아 뜯어보게 되는 상황이 생겼다. JBoss를 처음 사용하고 있었는데 이것이 버그가 있는지 어떤 기능에서 분명히 오동작을 하는 것이었다. 포럼을 뒤지고 질문을 올렸지만 아무도 관심이 없었다. 오기가 나서 소스를 분석해보자 하고 소스를 받았다. 코드를 살펴보고 일단 기겁을 했다. 이해가 안됐기 때문이다. -_- 오기로 매달렸다. 그 때 처음 ClassLoader를 공부하기도 하면서 (JBoss의 자체 클래스로더 구현은 상당히 독특하다) 한동안 JBoss와 Tomcat의 분석에 빠져살았다. 그리고 내가 원하는 부분을 찾아서 디버깅을 한 끝에 필요한 부분을 수정해서 사용할 수 있었다(물론 다음 버전에서 버그는 패치되었다). 한김에 버그수정이 아니라 내가 사용하기에 편리한 기능을 넣어보기도 하고 다양한 변화를 주면서 코드를 가지고 많은 작업을 해봤다. 내친김에 같이 사용하던 DB인 PostgreSQL의 소스도 분석을 했다. DB의 구현은 어떻게 했을까 오랜동안 궁금했던 것이었는데 코드를 보면서 적은 부분이지만 구현방식에 대해서 많은 것을 알 수 있었던 것 같다.  

그 후로는 오픈소스는 물론이고 심지어 소스코드가 공개안된 상용제품도 디컴파일이 되는 경우엔 코드를 한번쯤 열어서 살펴보는 것이 자연스럽게 된 것 같다. 그래봐야 대부분의 경우 말그대로 살펴보는 수준이었지만.

그러던 내가 오픈소스의 코드에 깊이 관심을 가지게 된 것은 SpringFramework을 접하면서부터 이다. 스프링은 뭔가 달랐다. 누구는 너무 양이 많다고 비난을 하지만 오픈소스 제품중 그토록 친절한 API문서를 가진 것은 처음봤다. 코드의 양은 많았지만 구조와 기능을 이해하는 것은 조금만 노력하면 힘들지 않았다. 유연한 설계 덕택인 듯 하다. 덕분에 시간이 날 때마다 코드를 들여다보고 많은 것을 배우려고 노력하고 있다. 또 그 배운 지식을 활용해서 스프링을 확장 또는 응용해서 쓰는 것도 가능해졌다. 적어도 스프링 만큼 오픈소스라는 말이 그 말 그대로 다가온 것은 없었던 것 같다. 그 배경에는 개발동기와 배경, 철학부터 기능에 대한 자세한 설명을 담은 여러권은 책과 상세한 레퍼런스문서 그리고 API문서의 역할이 컸다. 또한 방대한 양의 테스트코드는 거의 압권이다. 모든 코드가 다 TDD로 개발된 것은 아니지만 테스트 코드 자체에서 배울 수 있는 것 또한 대단하다.

어쩌면 스프링코드를 공부하면서 오픈소스를 사용하는 개발자에게 소스코드는 가치가 있다는 생각을 품게됐는지도 모르겠다. 하지만 스프링 외의 코드를 보면서 그와 같은 감동 내지는 영향을 받은 것은 아직은 없다. 사실 얼마 안되는 분량의 JUnit코드조차 모든 코드의 리비전을 다 가져와 어떻게 JUnit자체가 TDD방식으로 만들어졌는가를 이해하려고 해봤는데 짧은 시간에 제대로 이해하기가 쉽지 않았다.

요즘 유명 오픈소스 커미터들의 인기가 대단하다. 많은 개발자들이 오픈소스 커미터를 꿈꾸고 있다. 내 주변에만도 상당하다. 오픈소스 커미터(개발자보다 커미터라는 말이 더 폼이나는지 요즘엔 어디서나 커미터라고 한다)가 되는 방법에 대한 강의도 여럿 보았다. 오픈소스 개발자가 인기를 얻고 주목을 받는 것 자체는 반가운 일이다. 하지만 폼나는 오픈소스 커미터라는 명성에 대한 관심의 1/10 정도 만이라도 오픈소스 코드에 관심을 가진다면 자신에게 더 유익이 될 것 같다는 생각이 든다. 오픈소스 개발자는 고사하고 제대로된 사용자가 되고 싶어하는 마음만이라도 가졌으면 싶을 때도 많다.

언어,문화적인 제약이 있는 대부분의 한국 개발자가 외국의 유명 오픈소스 제품의 커미터가 되는 것은 아주 운이 좋거나 대단한 실력과 노력이 동시에 필요할 것이다. 하지만 그게 무슨 대단한 의미가 있을까? 이미 두터운 커뮤니티를 통한 개발이 활발이 진행되는 곳에 구지 끼어 들어갈 필요가 뭐가 있을까? 자신의 명성과 커리어를 위해서라면 모르겠지만.
(내용이 문제가 있는 문장이라 생략합니다) 그 참된 가치를 안다면 그 것을 이루기 위해서는 많은 댓가를 지불할 각오를 해야 할 것이다. 

그럴 자신이 없다면 차라리 지금 사용하고 있는 오픈소스를 (직접 고치지는 말고) 확장해서 써보자. 요즘의 왠만한 프레임워크나 툴, 제품들은 다 편리하게 확장할 수 있는 확장포인트나 플러그인 개발방법를 제공한다. 그런 것을 개인적으로 (또는 팀에서) 필요에 따라 확장해서 사용해보고 좋다면 공개를 해보자. 구지 그것을 원래 오픈소스 사이트를 통해서 공개할 필요도 이유도 없다. 자기 블로그에 올려도 그만 아닌가. 그것을 통해서 나도 다른 사람들에게 조금씩 더 기여할 수 있다면 그것만으로 오픈소스 기술과 커뮤니티는 발전할 수 있을 것이다. 확장을 위한 수고는 코드를 다 분석하고 커미터가 되기 위해서 노력하는 것에 비하면 대부분 훨씬 쉽다.

그런면에서 요즘에 많이 하고 있는 각종 스터디 그룹등에서 자신들이 공부하면서 작성한 코드를 공개하는 것은 정말 잘하는 일이다. 비록 학습과정이라 어설픈 것도 있고 대단한 프로그램이 아닐지 몰라도 비슷한 수준의 비슷한 관심을 가지고 있는 사람들에게는 그 짧은 코드 하나가 많은 도움을 줄 수 있다. 또 그것을 공개한 사람도 피드백을 통해서 유익을 얻을 수 있을테고. 이게 괜히 어줍잖게 복잡한 소스코드를 가지고 뭔가 폼나는 일을 하려고 하는 (그러다 대부분 결심만 하고 말지만) 사람들보다 더 오픈소스 정신에 가까운 일이 아닐까?

 

ps. (태클이 두려워서 :) ) 진심으로 오픈소스 개발자가 되고 싶은 분들은 꿈을 잃지 마시고 꾸준히 노력하시길. 또 갈수록 오픈소스 코드의 수준이 올라가고 TDD 또는 잘 만들어진 테스트코드를 가진 제품도 많이 등장하고 있으니 오픈소스의 코드 품질을 너무 무시하지만은 말기를.

 

발목 다친지 삼일째. 어제 밤부터 진통제를 끊어보려고 했는데 통증이 생각보다 심해서 OTL. 다시 진통제로 버티는 중이다.

어제는 정형외과병원에 갔다. 응급실에서 찍은 엑스레이사진을 들고. 목발질이 서투른 것도 있지만 팔로 버텨줘야 하는 무게가 만만치 않은 관계로 그거 좀 목발 짚고 다녔다고 이제는 팔꿈치가 욱신거린다. 병원에 가면서 본 엑스레이 사진에는 두군데 – 발목과 발뒤꿈치 아래에 – 체크가 되어있었다. 뼈에 이상이 있는 것으로 보인다는 것 같은데 나는 아무리 봐도 뭐가 어떤지 모르겠다. 의사들은 그 미묘한 명도차이를 해석해 내는 재주가 있나보다 하면서 병원에 도착. 그런데 거기서 만난 의사는 엑스레이 척 보고 발목 잡고 좀 만져보더니 뼈는 전혀 이상이 없다고 했다!!! 저런. 바보같은 응급실 의사의 오진이었다. 다만 발목주위의 인대가 심하게 다쳤으니까 충분히 안정을 취하면서 기다리면 나을 거라고 했다.

불행 중 다행인가. 뼈에는 이상이 없는 관계로 깁스는 하지 않고 까만색 다리보정기만 장착을 해주었다. 보정기를 입혀주면서 간호사가 그걸 “Darth Vader Boot”라고 부른다고 알려주었다. 두툼한 검은색 부츠처럼 생긴 것이 영락없는 스타워즈 3 마지막 장면에서 잘린 다리를 대신해서 연결해주는 검은색 의족과 똑같이 생겼다. 깁스는 아니지만 튼튼한 플라스틱으로 되어있어서 단단하게 발목을 고정해 주고 필요에 따라서는 벗을 수도 있어서 상당히 편리하다.

얼마나 더 이렇게 하고 있어야 할런지.. 그래도 생각했던 것보다는 좀 빨리 나을 수 있을 것 같아서 다행이다.

[##_1C|423711.jpg|width="450" height="338"| _##]

다스베이더 부츠를 장착한 모습

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha