두 달 정도 작업했던 사이트 하나를 지난 주말에 오픈했다. 사이트오픈 후에 의례 따르는 뒤치닥 거리도 대충 마무리 된 것 같다. 이제 슬슬 계획했던 Bliki+Forum 프로그램을 만들기 시작해야겠다. 프로젝트 이름을 KoalaBear로 바꿨다.

남은 것은 어떤 기술을 써서 만들 것인가 인데, 이게 고민이다.

Spring3.0 + OSAF3, SpringROO, Grails, 아니면 Seam? 또는 RoR 이나 다른 언어로된 프레임워크를 써보고 싶기도 하고.

매번 프로젝트마다 새로운 기술을 적용해보는 것이 나의 즐거움이긴 한데.. 한동안 새 프로젝트가 많이 없었던 관계로 이번엔 좀 선택의 폭이 커졌다. 가장 마음이 끌리는 것은 SpringROO와 Grails인데… 흠흠. 좀 더 고민해봐야겠다.

대용량, 고성능 사이트를 만들 것도 아니고, 알고리즘이 복잡할 것도 아니고, 흠..

이왕이면 구글의 GAE/J에 올렸으면 좋겠다 싶기도 한데, Grails는 이미 가능하다고 했고 SpringROO는 모르겠다.  Runtime Weaving이 있으니 아마 불가능할 것 같다.

정 하나를 선택하기가 힘들다면 SpringROO로 일부를 만들어서 Grails의 Spring 통합기능으로 붙여볼까?

물개 승권이의 꼬임에 넘어가 오픈씨드(OpenSeed)의 기술고문으로 활동하기로 결정한지 4년이 넘었다. 나는 한국에서 일할 때는 자바를 본격적으로 사용하지 않았다. 주로 MS쪽과 유닉스 서버기술에 매진했으니 말이다. 자바를 시작한 것이 호주로 이민한 후였고 그러니 한국의 자바 개발자들은 아는 사람이 거의 없는 상태였다. 스프링과 하이버에니트에 대한 개인적인 생각을 남기던 내 블로그를 보고 연락해온 승권이를 통해서 처음 한국의 자바개발자 커뮤니티를 접하게 되었다. 이름하여 오픈시드. 아직 싹도 피우지 못한 씨앗상태의 자바 오픈소스 기술 – 그 중에서도 스프링, 하이버네이트, 벨로시티 등을 한국의 엔터프라이즈 자바 영역에 보급하게 하자는 순수한 목적을 가지고 시작한 온라인 커뮤니티였다. 자신의 평일저녁과 주말시간을 거의 희생하다시피 해서 많들어낸 많은 튜토리얼과 가이드문서를 만들어 공개하고, 관심을 가지는 많은 개발자들과 채팅을 통해서 정보를 나누기도 하고, 문서와 행사 등을 통해서 좋은 발표를 해나가는 등의 눈부신 활약을 보여주었다. 하지만 설립자인 곰땡이 종하와 물개 모두 1-2년만에 지쳐 떨어져 나가버리고 오픈시드는 그저 한국에 최초로 오픈소스만을 위한 자바 커뮤니티라는 네임벨류 하나만 가진채로 방치되어버리다 문을 닫기에 이르렀다.

그게 씨앗이 되었는지 어쨌는지는 모르겠지만, 스프링과 하이버네이트 등의 신흥 자바 오픈소스 기술의 가치가 서서히 알려지게 되었고 하이버네이트는 아직은 좀 약세이긴하지만, 적어도 스프링은 한국내에서도 주류 기술로 당당히 자리잡은 듯 하다.

2년전쯤에 한동안 문을 닫았던 오픈시드를 물개와 같이 일하게 된 것을 계기로 다시 오픈했다. 그때 가졌던 생각은 일방적인 기술문서나 자료제공과 같은 소모적인 것 말고 상호교류가 가능한 포럼을 중심으로 하고, 오픈소스 프레임워크를 더 잘 활용할 수 있도록 도움이 될만한 자체 오픈소스 개발 프로젝트를 진행하자는 것이었다. 그렇게 해서 오픈씨드 2기가 시작되었지만 인생의 진로에 대해서 고민에 빠져있던 물개는 맨날 빼기만 했고, 원래 천성이 게으르고 남 앞에 나서기를 꺼려하는 내 소극적인 성격 탓에 프로젝트는 구상만 하던 중에 시간만 흘러갔다. 그러던 중에 (유명)오픈소스 활동도 안하면서 오픈소스에 대해서 떠든다고 비난을 받기도 했고, 오픈소스라고는 리눅스 뿐인줄 아는 노벨상 수상자인 모대학 총장의 변덕 탓에 참여하던 프로젝트가 휘둘리고 치사한 소리(오픈소스로 만들면 보안도 취약, 비용도 더 많이든다라고)도 들어가면서 오픈소스라는 것 자체에 환멸을 느끼기도 했다.

솔직히 내가 좋아하는 제품이 어쩌면 우현히 오픈소스제품이었을 뿐이지 오픈소스이기 때문에 그것을 선택한 것은 아니라는 생각이다. 나는 스프링과 하이버네이트가 소스가 공개되지 않은 상용제품이고, 어느정도 적절한 가격의 라이센스 비용을 받는다고 한다해도 역시 그것을 선택했을 것이다. 물론 지금만큼 매력적이게 생각하지는 않았을지는 몰르겠지만.

 

어쨌든 공개한 오픈시드의 기술포럼은 물개의 마지막 노력으로 공개 온라인 교육과 스크린캐스트 출시라는 주목받지는 못한 마지막을 장식하고 쓸쓸히 사라졌다. 프로젝트 역시 흐지부지 되었고.

 

그러는 중에 자주 이름이 오르내리던 것이 바로 스프링과 하이버네이트 기반 프레임워크인 OSAF(OpenSeed Application Framework)이었다. 사실 몇번의 공개발표 기회에서 이름을 언급하고 공개를 한다고 하긴 했는데, 제대로 공개하는데는 실패했다. OSAF의 기원은 내가 스프링과 하이버네이트를 이용한 ERP와 협업 솔루션 프로젝트를 진행 하면서 만들었던 작은 프레임워크이다. 물론 그때는 딱히 이름은 없었던 인-하우스 프레임워크였다. 물개랑 친해지면서 그 얘기를 했더니 얼른 공개프레임워크로 만들었으면 좋겠다고 나를 꼬셨고, 결국 물개와 같이 진행하는 새로운 프로젝트의 자체 프레워크를 개발하면서 공식적으로 openseed 타이틀을 단 OSAF를 개발했다.

그럼 왜 이런 프레임워크라는 것이 필요한 것일까? 이미 우리는 스프링과 하이버네이트를 비롯한 수십여가지의 공개된 자바 오픈소스 프레임워크를 사용하고 있다. 그럼에도 왜 또 프레임워크라는 것을 만드는가? 사실 이 질문이 내가 가장 많이 받기를 기대한 질문이었는데 한번도 이 것을 물어보는 사람을 만나지 못했던 것 같다.

스프링은 범용적인 프레임워크이다. 물론 스프링의 기본적인 구조를 따라 그대로 개발해도 상관없다. 심지어 어떤 프레임워크들은 스프링과 하이버네이 또는 iBatis를 가져다가 프로젝트 뼈대만 만들어놓고 그것이 프레임워크라고 우기기도 한다. 솔직이 그건 그냥 프레임워크 스택이라고 부르는게 맞다는 생각이다. 어쨌든 범용적인 프레임워크는 확장을 전제로 한다. 스프링은 스스로도 확장하는 프레임워크이고, 그것을 활용해서 각각의 컨텍스트에 맞도록 재구성하거나 기능을 추가해서 사용하도록 권장한다.

가장 좋은 접근 방법은 프로젝트 마다 프레임워크를 만드는 것이다. 요즘에는 전사적 프레임워크 또는 SI업체(아 참.. 요즘은 IT서비스업체라고 해야지)의 개발 표준 프레임워크 등을 만드는 것이 유행이다. 시간이 나면 다시 얘기해보고 싶지만 기본적으로 잘못된 발상이다. 모든 프로젝트의 특징과 환경이 동일하다면 모를까 어찌 하나의 프레임워크로 모든 것을 커버하려는지 모를일이다. 그러니 나중에는 특징도 없는 초대형 공통모듈 덩어리가 되기 쉽상이겠지. 공유될 수 있는 기술표준과 프로토콜 또는 정책에 최소한의 공통분모를 담아서 기준을 만든 뒤 매 프로젝트마다 그 특성에 맞도록 프레임워크를 만들어 접근하는 것이 바람직하다는 것이 내 생각이다. 뭐 현실적으로 맥도널드처럼 갈 수 밖에 없다면 할 말은 없겠지만.

 

스프링을 확장해서 프레임워크를 만드는 이유는 2가지 이다. 하나는 스프링의 사용전략과 정책에 대한 틀을 프레임워크에 담는 것이다. 추상레이어링 또는 폴리시 프레임워크 스타일의 접근 방법이다. 그런 것이 없다면 스프링을 사용하는 방법은 수만가지쯤 되니 개발자마다 중구난방의 코드가 나올 위험이 있다. 또 한가지는 도메인의 특성 또는 환경에 따른 기술적인 특성을 담은 프레임워크로의 확장이다. 재활용 가능한 디자인/구현 패턴과 구체적인 뼈대코드의 집합이 프레임워크이다. 당연히 하나의 프로젝트라면 그런 결정이 프레임워크를 통해서 나타나야 한다. 참.. 공통모듈/API와 유틸API는 그 자체로는 프레임워크라고 볼 수 없다.

 

아무튼.. 그렇게 프로젝트를 하면서 나온 다양한 프레임워크를 정리해서 오픈소스로 공개해보자는 나이브한 발상을 가지고 OSAF를 실전 프로젝트에서 뽑아내보자는 생각을 했는데, 생각보다 일이 컸다.  가장 큰 문제는 애플리케이션 프레임워크라는 것에 대한 과도한 기대에 대한 부담이다. 모든 상황에 다 들어맞는 만능 프레임워크는 없다. 이미 만능 프레임워크 겪인 스프링 등이 존재한다. 그것을 추상화하고 특별화 하는 것이 일명 애플리케이션 프레임워크 또는 FoF(Framework of Frameworks)이다. 하지만 공개될 프레임워크를 기대하는 개발자들은 자기 상황에 딱 들어맞는 것을 기대하고 요구할 것이 뻔하다. 그런 요구들을 충분히 상상할 수 있으므로 그것들을 추가해서 만들다보면 사실 처음 생각했던 것보다 훨씬 큰 – 자칫 특징이 사라져버린 비대한 프레임워크가 나올게 뻔하다. 또 한가지 문제는 실전 프로젝트에 적용한 만큼 저작권 등에 대해서 어느정도 고객의 양해를 구하고 공개에 대해 동의를 얻었다 할지라도 실제 공개를 하자면 제거해야 할 것들이 많다. 현실적으로 사용이 불가피한 각종 상용제품과의 연동부분 또는 확장부분이 그렇고. 실제 디자인과 혼합되어있는 UI관련 모듈이 그렇고.

스프링시큐리티의 리더 벤 알렉스가 만들어 호주의 가장 큰 마트체인에 적용해서 성공시킨 ROO라는 스프링 기반의 뛰어난 DDD 애플리케이션 프레임워크는 이미 3년전부터 공개하겠다고 선언했지만, 아직도 못하고 있다. 이번 S1A에서 다시 세션이 있던데.. 역시 조만간 공개는 힘들다는 얘기가 나올게 분명하다. 위와 같은 이유에서 이다. 그래서 내가 아는한 제대로 만들어져 공개된 단 한개의 스프링 기반의 범용 애플리케이션 프레임워크는 존재하지 않았다. 그런걸 하겠다고 큰소리는 아니지만 떠벌렸으니 그 부담이 얼마나 컸는지 모른다.

 

물론 물개가 오픈시드 2기 시절 한번 그 당시 만들어 쓰던 버전의 다운그레이드 버전을 공개를 하긴했다. 정식 프로젝트 사이트는 아니지만 샘플 애플리케이션과 소스를 다운 받을 수 있게 만들고, 강의 동영상/스크린캐스트로 공개했다. 재밌는 것은 그토록 공개 안하냐고 따지던 사람들은 다 어디갔는지 관심도 반응도 없었다. 실망이었다.

 

그러던 중 작년 TSE에서 만난 S모사의 프레임워크팀 팀장으로부터 팀에서 개발한 프레임워크를 오픈소스로 공개하겠다는 얘기를 들었다. 그리고 몇달후 등장한 것이 그 유명한 애니프레임이다. 솔직히 게으른 탓에 아직 제대로 들여다 보지는 못했다. 기술과 소스의 질에 대한 이런 저런 비난의 소리도 들렸다. 그럼에도 나는 박수를 쳐주고 싶었다. 아무도 못했던 것을 먼저 했기에. 솔직이 그런 비난을 하는 사람들은 자신이 만들거나 사용하던 프레임워크를 떳떳히 공개할 용기나 관심이나 있을까 궁금하다.

OSAF 따위는 잊고 살던 중에 KSUG를 만들었다. 스프링을 제법 사용하기는 하는데 "제대로" 사용하고 그 가치를 모두 누렸으면 좋겠다는 의도였다. 2달에 한번 꼴로 공개세미나를 하는 강행군 끝에 영회랑 같이 뻗었다. 원래 의도대로 모일 수 있는 온라인 공간을 만들어 운영하는 것으로 일단 할 일을 했다고 생각하고 넘어갔다.

 

그러는 중에 스물스물 올라오는 것들이 있다. 이런 좋은 방법과 고민해서 얻은 결과를 다른 사람들도 좀 혜택을 받게 하고, 또 피드백을 통해서 더 좋게 발전시킬 수 있으면 좋겠다는 그런 생각이다. 블로그에 그저 메모한답시고, 또는 아무 생각없이 올렸던 간단한 기술적인 글이나 코드조각에 그것이 도움이 되었다고 고맙다고 답글 달아주는 분들을 보면.. 좀 더 많은 것을 공개해도 될텐데 하는 생각이 들었다.

그러는 중에 최근에 프로젝트를 같이 했던 우리의 호프 기선이가 OSAF 프로젝트를 했으면 좋겠다는 의견을 냈다. 사실 기선이가 참여하는 프로젝트가 경기침체로 현재 좀 지연이되면서 시간이 남아서, 또는 실연의 아픔을 잊기 위해서 이리 저리 손을 대었던, 최근 프로젝트에 적용하려고 간단히 만든 프레임워크를 OSAF라고 다시 이름 붙여서 공개하고 발전시켰으면 좋겠다는 얘기였다.

내가 만들어 쓰던 프레임워크들은 스프링의 버전에 따라 계속 새롭게 만들어졌다. 어떤 것은 스프링의 버전이 높아지면서 기존의 프레임워크가 했던 일을 훨씬 세련되고 깔끔하게 스프링 내에서 해버려서 더 이상 필요없게 된 것들도 있고, 스프링 자체의 발전에 따라 좀 더 나은 아이디어를 적용할 기회도 만들어지고 그랬기 때문이다. 스프링 2.5를 처음 적용한 프로젝트를 하면서 가졌던 생각은 2.5가 추구하는 극대화된 간결함을 살려보자는 것이었다. 그래서 Generics를 최대한 모든 영역에 적용시키고, Convention을 적용한 CoC개념을 살짝 도입해서 CRUD+검색+소팅+페이징+엑셀다운로드라는 비즈니스 애플리케이션에 전형적으로 나타나는 기본 틀을 프레임워크가 최대한 처리해주고, 사용자는 Convention과 틀만 만들면 되도록 하는 것이 주 목적이다. 일종의 RAD를 추구하는 그런 목적을 가진 프레임워크이다. 고맙게도 Spring2.5는 빈 설정을 비롯한 많은 부분의 반복적이고 노가다성의 작업을 스프링이 말끔히 제거해주고 있다. 그것을 극대화 시켜보는 것이 그 프레임워크의 목적이었다. 문제는 워낙 급한 일정 탓에 사실 일주일도 안되는 시간에 모두 완성시키고 끝냈다는 것 정도. 그래도 스프링2.5의 베스트프랙티스에 대해서 많은 고민을 하게 해준 시간이었다.

 

아무튼 기선이는 그것을 공개하고 싶어했다. 노가다 작업은 기선이에게 맡기고 나 몰라라 하고 있었는데 가끔 소식이 들어왔다. 상용 자바스크립트 제품을 사용한 것과 주요한 UI쪽 기술들은 손을 못대서 간단한 것으로 축소시키고 부족했던 테스트와 문서등을 좀 보강해서 얼렁뚱땅 정리하더니, 한동안 SpringDM/OSGi까지 적용시킨다고 매일 12-1시까지 끙끙매는 모습이었다. 자꾸 손을 대니 일은 늘어나고 다시 바쁜 일들이 찾아오고 해서 그냥 부족해도 공개를 하기로 했다.

 

그래서 나온 것이 바로 OSAF(OpenSprout App. Framework)이다. 음.. 이름이 OpenSeed에서 OpenSprout로 바꼈는데, 사실 여전히 OpenSeed이다. 다만 도메인 소유 이전문제랑 비용 등등이 많이 들었다는 이유 하나만으로 (변변한 후원업체도 없는 관계로. 흑…)  새로운 도메인을 만들었을 뿐이다. 다만, 이제는 씨앗(Seed)에서 적어도 싹(Sprout)으로는 가야하지 않겠냐는 생각에 이름을 Open Sprout로 지었다.

 

기선이가 수고해서 위키,이슈트래커,CI환경과 각종 프로젝트 정보 사이트를 구성하고 소스포지에 내가 오래전에 등록한 osaf 프로젝트를 이용해서 릴리즈를 해버렸다. 1.0 Milestone 1. 갈길이 멀긴 하지만 그래도 허접하지만 이렇게 등록해 놓고 보니 기분이 좋다. 비록 코드는 기선이가 거의 새로 만진 것이고, 나는 빌드 방법 좀 고민하느라 리뷰조차 못해서 아마도 손 대야 할 부분이 매우 많을 듯 하다.

그럼에도 이렇게 작은 한 발 내딪는 것이 가지는 의미는 크다. 비록 소속업체의 지원을 받아가며 빵빵하게 프레임워크를 개발하는 것도 아니고, 활동지원비가 나온다는 N모사 같은데 소속된 것도 아니고 그저 빠듯한 프로젝트 해가며 틈틈히 시간을 할애해가야하는 작업일지라도 누군가에게 도움이 되고, 좋은 의견과 비판을 통해서 재밌게 성장해나갔으면 싶다.

 

그래도 세계최초 OSGi에서도 구동가능한 스프링 기반 애플리케이션 프레임워크가 아닌가.

 

OSAF가 궁금하면 기선이의 블로그에 계속 관련 정보를 연재하고, 위키에도 올리고 있으니 참고하면 되겠다.

 

 

프로젝트 사이트는 위키는 다음과 같고.

http://www.opensprout.org/wiki/display/os/OpenSprout+Application+Framework

나머지는…

OpenSprout 홈 페이지: http://www.opensprout.org/wiki/display/os/Home
OSAF 배포 소식: http://www.opensprout.org/wiki/display/os/Release
OSAF JavaDoc: http://www.opensprout.org/api/
OSAF 이슈 트래커: http://www.opensprout.org/jira/browse/OSAF
OSAF 소스 코드 뷰: http://www.opensprout.org:9060/browse/OSAF/osaf/trunk
OSAF 커버리지: http://www.opensprout.org/coverage/

 

사실 내가 해보고 싶은 것은 이전에 Learning Test에 대해서 이야기했던 것을 구체적으로 스프링과 하이버네이트, AspectJ 등에 적용하는 것이다. 일명 LearningTest Project. 함께 공부하면서 레퍼런스 매뉴얼에 있는 기능을 그대로 테스트로 모두 구현해서 배우는(검증도하고) 프로젝트이다. 재밌지 않을까?

또 스프링의 다양한 프로젝트 구성을 편리하게 해줄 툴과 개발환경과 관련된 것도 프로젝트화 하려고 한다. 이전에 Irene이라고 잠깐 공개했다가 말았던 그것인데 Maven의 발전과 m2e 덕에 할 맛이 난다.

 

뭐든 처음 시작이 어려운 법이다. 관성이 붙으면 그때부터는 더 즐겁고 재밌게 할 수 있겠지. 다들 별로 관심이 없다면? 무슨 상관이랴. 내가 재밌고 즐거워서 한다는데.  얼릉 스프링 책 마무리하고 본격적으로 손을 대봤으면 좋겠다.

그나저나 위키랑 프로젝트 사이트 디자인이 엉망인데.. 이건 천재적 아티스트 물개를 시켜야 하는데 맨날 잠수만 타네…

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha