다른 분들이 스프링의 기술 top을 발표했으니 저는 지난 해 스프링과 관련한 아쉬웠던 것들을 한번 적어봅니다.
1. 스프링소스
로드존슨이 프리랜서 시절부터 사용하던 회사명인 Interface21을 SpringSource라고 바꾸고 재작년과 작년에 두번에 걸처서 VC로부터 큰 투자를 받았습니다. 투자사가 돈을 낼 때는 큰 수익을 기대하고 있는 것이고, 대부분 기업의 수익을 통한 배당보다는 IPO나 대형 기업에 인수되어져서 큰 차익을 얻는 것이 목표입니다. 그런면에서 VC에 투자를 받은 기업이 망하지 않고 버틴다면 언젠가 JBoss, MySQL 등과 같이 합병되거나 RedHat처럼 상장을 해야합니다. 오픈소스제품을 기반으로 한 비즈니스라는 가장 힘들고 도전적인 일을 시작한 스프링개발자들도 같은 선택을 해야했고, 그 과정에서 VC의 투자는 필수적이지요. 문제는 VC의 투자 이후에 상당한 경영상의 태클이 들어온다는 것입니다. JBoss가 VC투자 이후에 Apache의 Geronimo개발팀이 JBoss코드 일부를 무단 사용했다고, 변호사를 통해서 경고서한을 보낸 것은 충격적인 일이었습니다. 오픈소스라고 해도 저작권이 있고, 지켜야 할 라이선스 조항이 있다는 것은 알고 있지만, 그렇게 거칠고 딱딱한 방법을 동원해야했나는 생각이 들어서 JBoss에 한참 정이 떨어지기도 했죠. 원인은 VC로부터의 압박이 아니었을까 생각했습니다. 마찬가지로 스프링소스 또한 VC의 투자를 받고 덩치를 키우고 관련업체들을 인수하기 시작하면서부터 VC로부터 많은 압박을 받았을게 분명합니다. 가장 중요한 것은 상장이든 인수든, 그에 필요로 하는 성장하는 수익구조를 가지고 있어야 한다는 것이죠. 스프링소스의 컨설턴트들이 스프링을 사용하는 각국의 대형프로젝트에 가서 컨설팅을 하고 그로부터 댓가를 받는 것으로는 규모를 무한하게 키우지 않는 한 큰 이익을 내기 힘듭니다. 몇년전 ThoughtWorks가 상당히 성공한 최신 IT컨설팅업체임에도 상장할만큼의 성공적인 수익을 내지 못해서, 초기 투자자들이 투자비를 회수한다고 난리를 쳤다는 얘기를 듣기도 했지요. 스프링 소스는 그에 비하면 아직 작은 업체입니다. 그렇다고 무작정 컨설턴트 숫자를 늘리면 질은 떨어지겠지요. 결국 선택은 상용제품과 지속적인 서비스를 판매하는 것입니다. 그래서 등장한 것이 Spring Tool Suite을 비롯한 Spring Enterprise입니다. 또 service subscription을 판매하는 것을 통해서 안정적인 수입을 만들어 내는 것입니다. 로드 존슨이 재작년 TSE에서 앞으로 스프링 소스의 주력 마케팅 타겟은 포츈500 기업이라고 얘기했습니다. 그를 위해서 본부를 실리콘벨리로 옮기고 로드 존슨은 주로 그 오피스에서 일을 하고 있죠. 문제는 오픈소스가 아무리 성공적으로 도입되었다고 한들, 모든 기업이 다 그 개발업체에게 상용 서비스를 받으려하지 않는 다는 것이죠. JBoss가 전체 WAS순위 4위인가 하던데.. JBoss를 도입한 업체 중, 상용 서비스를 받고 있는 곳은 7% 정도라는 얘기를 들은 적이 있습니다. 상용서버라면 아마도 90% 이상이겠죠(기한이 지나서 서비스를 갱신 안하는 곳정도를 제외하면..). 기본적인 라이선스 비용도 없는데다, 상용서비스의 비율도 사실 매우 작기 때문에 단순하게 오픈소스공개 후 상용서비스라는 공식은 사실상 이미 실패한 것이나 다름없습니다. 그래서 뭔가 오픈소스에는 없는 부가기능과 가치를 가지는 전용제품이 필요한 것이고, 그것이 바로 Spring Enterprise입니다. 과연 얼마나 많은 기업이 스프링소스로부터 서비스를 받고 있을까요? 잘 모르겠습니다만, 생각보다 그리 많지는 않아보입니다. STS같은 경우는 개인적인 사용만 무료로 허용되어있지만, 사실 회사에서도 그냥 다 쓰지요. 왠만한 기술적인 질문은 자체적인 온라인 커뮤니티나 수많은 공개된 자료에서 답을 찾을 수 있습니다. 요청하면 로드 존슨이 달려와서 해주는게 아니라면 구지 돈을 주고 조금 더 전문적인 서비스를 받을만한 절박함이 없습니다. 또 기술력이 있는 대형기업이라면 스스로 스프링을 개선하고 확장해서 사용합니다. TSE등에서 사례발표를 한 많은 대형 금융기관이나 LInkedIn등의 적용사례를 보면, 자체적인 기술력으로 스프링을 얼마든지 편리하게 사용하도록 개선하고, 관련 툴을 만들어서 적용하고 있습니다. 아직까지 스프링소스가 제공하는 상용제품과 서비스가 그런 업체들에게 줄 수 있는 특별한 부가가치가 없어보입니다. 반면에 보수적이고 덩치가 큰 기업은 안정적이고 지속적인 서포트가 관건입니다. 스프링이 구버전 호환성이 뛰어나다고 해도 구지 꼭 필요하지 않으면 신규버전으로 업그레이드 안하는 것이 보수적인 기술정책을 가진 회사들의 사고방식입니다. 얼마전까지 Spring1.x를 고집했던 atlassian과 같은 ISV도 마찬가지지요. 그러기 위해서 구버전의 지속적인 유지보수가 보장되야 하는데, 각 브랜치를 계속 디버깅하고 관리한다는 것은 오픈소스 개발업체로는 큰 부담입니다. 그만큼의 보상이 필요하죠. 그래서 스프링소스가 올해 큰 악수를 하나 둡니다. 바로 유지보수정책의 변화이죠. 구버전도 3년간 유지보수 버전을 제공하지만, 바이너리 릴리스는 상용서비스 업체에만 제공하고 오픈소스로는 맨 프로젝트 소스만 제공한다는 것이죠. 어떻게 생각하면, 상용서비스를 받는 업체에게는 그만큼의 만족감을 주고, 오픈소스로 찾는 이들에게는 조금의 수고만으로 더 안정적인 유지보수 서비스를 제공한다는 면에서 사실 윈-윈하는 정책이었습니다. 하지만, 스프링소스의 정책의 변화에 대한 친절한 홍보 부족과 스프링을 시기하는 인간들의 비열한 공격으로 스프링소스의 정체을 오해한 많은 개발자들이 생겨났고, 상처 받은 스프링의 신뢰를 회복하느라 로드 존슨이 꽤 땀을 빼야 했습니다. 연말에 열린 S1A에서 느낀 점은 그런면에서 스프링소스의 긴장감을 잘 보여줍니다. 이전과 다르게 딱딱해진 컨퍼런스도 그랬고, 많은 참석자들이 "왜 돈을 내고 와서 마케팅 발표를 들어야 하는지 모르겠다"는 푸념도 참 안타까웠습니다. 그들의 열정과, 오픈소스와 비즈니스를 동시에 지켜야 하는 현실적인 고민, 그리고 최선의 정책도 다 이해합니다만... 개발자들은 그렇게 이해심많고 착하지만은 않으니 걱정이지요.
고군분투하는 스프링소스의 비즈니스와 그에 휘둘릴지도 모르는 오픈소스 스프링을 올해의 안타까웠던 스프링관련 첫번째로 꼽습니다.
2. KSUG
KSUG는 스프링사용자들의 만남을 명분으로 한, 공개세미나 팀이었죠. 그러다 오프라인의 한계를 넘기 위해, 또 오프라인 행사준비에 점점 한계를 느끼는 운영팀의 이런 저런 핑계 때문에 올해 온라인 커뮤니티로 변신을 꾀했습니다. 원래 목표는 포럼과 블로그, 그리고 스크린캐스트의 활성화였죠. 포럼은 그럭저럭 자리를 잡고, 한동안 스프링관련 좋은 토론과 질의응답이 이어졌습니다만, 홍보의 부족으로 아직도 대부분의 스프링개발자들은 이런 공간이 있는 줄도 모르고 있는 상황이고, 쉽고 편하게 질문과 생각을 나누기에는 아직 분위기가 그렇게 잘 형성되어있지 않습니다. 반쯤의 성공이라고 봐야 할까요.
KSUG블로그는 새로운 필진의 등장으로 좋은 글들이 많이 올라옴에도 불구하고 역시 홍보의 문제 때문인지 방문자가 적고, 올라오는 글에 대한 포럼에서의 피드백과 토론이라는 기대에는 거의 부합하지 못하고 있습니다. 주제의 어려움도 한 이유이고, 근본적으로 온라인에서의 기술적인 토론이 점점 사라져가는 그런 추세 때문인지도 모르겠습니다. 어쩌면 다들 너무 마음이 바쁘기 때문일지도...
스크린캐스트는 몇분이 올려준 것을 제외하면 사실 처음 생각했던 것을 거의 진행하지 못했습니다. SpringOSGi/DM을 주제로 잡고, 일단 IBM DW에 유료(하지만 그쪽 정책에 따라 시간은 짧은 심플한) 버전을 올려서, 툴이나 운영비를 위한 수익을 만들고, 바로 뒤이어 KSUG에 길고 충분한 내용을 담은 풀 버전을 올리자는 것이 처음 계획이었습니다. 물론 못했죠. IBM DW에만 좋은 것을 제공하고 끝났습니다. 물론 순서대로 보면 안녕회 회장이 먼저 시리즈를 시작해야 하기 때문에 뒤를 따라야 하는 저는 시작도 못했다고 변명할 수 있습니다만, 어쨌든 게으름 내지는 무성의 함이 원인이었던 것 같습니다. 특히, 오프라인 세미나때 못했던 @MVC의 온라인 스크린캐스트 제공은, 별다른 관심도 받지 못한채로 그냥 흐지부지 되었습니다.
여러모로, KSUG의 올 한해는 아쉬움이 많이 남습니다. 스프링 보급이나 홍보의 시대는 지났고, 진정으로 스프링을 사용하는 사람들끼리 효과적인 교류를 가지자는 취지의 KSUG가 그냥 가까운 몇 사람들과의 친목을 다지는 수준에서 머물른 것이 아닌가 하는 아쉬움이 큽니다. 물론 KSUG를 통해서 본격적으로 등장하신 여러 분들이 있다는 면에서 보람도 있긴합니다만... 지켜지지 않는 약속을 남발한, 저를 포함한 운영진의 반성이 필히 요구되는 한해였습니다.
nhn과의 후원관계에 대한 상호 오해에서 일어난 사건은 가장 씁쓸한 기억으로 남습니다.
3. 애니프레임과 기업의 기술공개
애니프레임에 대해서는 사실 아쉬움은 없습니다. 기술적인 아쉬움이야 일정 부분 있을 수 있겠습니다만, 현장에서의 치열한 논쟁과 부딫침 속에서 어쨌든 만들어지고 사용되어진 제품을 오픈소스 프로젝트로 공개했다는 점에서 일단 90점을 먹고 들어가기에 애니프레임 공개은 2008년 스프링관련 최고의 사건이 아니었나 생각합니다. 사실 애니프레임의 공개를 바라보면서 기대했던 것은 다른 경쟁 기업이나 대형업체들이 자신들의 애플리케이션 프레임워크나 플랫폼을 덩달아 공개하지 않을까 하는 것이었습니다. 여기저기서 SDS의 그런 깜짝 공개에 놀라서, 자신들의 프레임워크도 공개하려고 추진한다는 소식도 들어왔습니다만, 작년 말까지 별다른 공개는 없었습니다. 그런면에서 애니프레임은 여전히 독보적입니다. 하지만, 스프링관련 프레임워크의 공개를 통한 경쟁과 상호발전을 기대했던 분들에게는 여전히 아쉬움이 남습니다. 세계적으로도 기업의 표준 프레임워크가 오픈소스로 공개된 예는 거의 없습니다. 스프링소스가 보유하고 있는 ROO도 몇년째 비공개 상태죠. 사실 뒤를 이어서 기선님이 주도해서 OSAF2.0의 마일스톤 버전이 공개됐습니다만, 정말 아무런 관심도 못끌고 잊혀져버렸습니다.
애니프레임과 관련해서 주변의 KSUG멤버들의 모습을 관찰해 본 결과, 대부분은 애니프레임을 제대로 공부하거나 사용해보지 않고, 겉으로 나타난 몇가지 사실만 가지고 그냥 비판만 하기에 급급하더군요. 엔지니어로서 참 안좋은 태도였던 것 같습니다. 좀 더 진지하게 공개된 오픈소스 프로젝트에 대해서 살펴보고, 부족한 부분은 제안하고, 기여하려는 마음을 가진 개발자들이 없다면, 앞으로 어떤 기업에서 어떤 프로젝트가 공개된다 할지라도 별 의미가 없지 않을까 하는 생각이 들기도 했습니다.
4. OSGi/SpringDM
1.0정식버전이 공개가 된 SpringDM이 2008년의 아쉬움의 4위입니다. 솔직히 SpringDM1.0은 1.0이 아닙니다. 적어도 엔터프라이즈 개발에서의 OSGi 적용을 명분으로 둔 SpringDM이라면 웹을 포함한 full layer의 지원을 완성하고 1.0을 릴리스했어야 한다고 생각됩니다. 하지만 1.0은 SpringMVC나 Web레이어의 지원이 없는 채로 공개되었고, 현재 1.2마일스톤 버전이 나온 지금도 아직 그 부분에서의 지원은 완벽하다고 보여지지 않습니다. 물론 기술적으로는 충분한 제공이 되긴 했지만, 부족한 문서나 샘플도 그렇고, SpringIDE에 통합되지 않은 면도 그렇고, 아직도 많은 이슈를 남겼다는 면에서 SpringDM이 진정한 OS-JEE-i를 위한 기술로 자리 잡기에는 아직도 한계가 있어 보입니다. 그 와중에 tomcat과 결합해서 손쉽게 OSGi 애플리케이션을 서버환경에서 사용하게 만들어주는 SpringDMServer가 공개되었습니다. 역시 1.0이 공개되긴 했지만, 아직도 현장에서 사용하기에는 한참 부족합니다. 핵심은 구현은 되었다고 보이지만, 사용의 편의성도 불편하고, 아직 계획만 되어있고 만들어지지 않은 기능도 엄청납니다(Rop Harrop의 키노트 발표에 보면 한 50가지 정도가 남았더군요...).
플랫폼의 변경이라는 이 커다란 변화가 쉽게 오리라고 생각하지는 않지만, 수많은 기업들이 OSGi에 뛰어들고 매진하고 있는 마당에 가장 앞서있다고 하는 SpringDM과 관련 기술이 이 정도 레벨에서 머물고 빠르게 발전하지 못하고 있는 것은 아쉬움입니다. 그나마 좋은 소식은 SpringDM 2가 OSGi의 엔터프라이즈 컴포넌트 기술의 차기 표준이 되었다는 점인데.. 그부분에 SpringDM개발팀의 여력이 많이 뺐긴 것은 아닌지 하는 의심도 좀 들긴합니다.
5. 준비안된 스프링의 도입열풍
스프링이 이제 메인스트림 기술로 완전히 자리잡은 듯 합니다. 국내의 보수적인 대형 SI들이 적극 사용하거나, 사용을 고려하고 있다는 면에서 이미 충분히 주류기술이 된 것처럼 보입니다. 하지만 이런 열기 속에서 정작 스프링을 스프링 답게 사용하지 못하는 모습이 자주 눈에 띕니다. 스프링을 2주 공부하고 책에 나온 예제 정도 배낀후, 자신이 이전에 개발하던 스타일로 나머지는 멋대로 떡칠한 코드를 가지고 고급 스프링 컨설턴트로 현장에 들어가는 사람들을 본적이 있습니다. 스프링을 도입했지만 귀찮게 새로운 기술을 공부해야 했던 것 말고 뭐가 좋은지 모르겠다는 현장의 푸념도 들려옵니다. 살펴보면 스프링을 그저 가져다 넣기만 했지, 스프링의 기본적인 개발철학조차도 이해못한 채로 엉망으로 사용을 한 경우들입니다. 주위에 그런 얘기가 너무 많이 들려옵니다. 시중에 공개된 스프링책의 어떤 것도 스프링의 진정학 개발원리와 철학, 목표를 얘기해주고 있지 못합니다. 스프링을 그저, 가져다가 넣고 예제 몇개 살펴보고, 샘플 카피해서 사용하면 되는 툴로 이해하는 경우도 많이 보았습니다. 그런 준비안된 스프링 도입, 무비판적인 수용이 결국 스프링에 대한 반감을 많이 키우기도 해서인지, 최근에는 스프링을 도입하는 것을 "감정적으로" 꺼려하는 사람들의 이야기도 들었습니다.
기술적으로 보자면, 애플릿을 제외하면 자바에서 스프링을 도입하지 않을 곳이 없다고 생각합니다. 하지만, 기술적인 적합성만으로 무엇이든 가져다 사용할 수 없는 것이 현장의 현실입니다. 충분한 학습과 전략수립 없이 사용해봐야 큰 효과를 못보는 것이 스프링입니다. 그런면에서 과열된 스프링의 인기는, 얼마 지나지 않아서 스프링에 대한 거부감 내지는 오해를 크게 불러오지 않을까 하는 우려를 낳게 합니다.
그러면에서 좋은 스프링의 교육과 가이드 서적, 안내들이 아쉬웠던 2008년 이었습니다.
다음은 내년의 스프링관련 기대종목을 꼽아봅니다.
1. Spring 3.0
누가 뭐래도 내년 스프링관련 가장 큰 소식은 Spring3.0의 발표입니다. 스프링이 처음으로 크게 진화하고 변화한 모습을 보여주는 것이 바로 3.0입니다. 지겹게 끌고 다녔던 JDK1.4도 이제 EOSL되버렸고, 스프링도 과감하게 Java5+로 변신합니다. 그동안 오래 지연했던 애노테이션의 도입도, 2.5에서 본격적으로 사용하기 시작하면서 3.0에서는 거의 애노테이션 만으로 기존의 XML에서 했던 것을 대부분 수용할 수 있는 단계로까지 발전합니다.
물론 이전 버전과의 API레벨에서의 완벽한 호환은 보장합니다. 이전 설정방법도 당연히 보존됩니다. 하지만 Controller 계층구조가 deprecate되버리는 과감한 변신이 들어갑니다. 또 웹과 관련된 부분이 대폭 지원이 되며, SWF와 JavaConfig이 core에 대거 합병되버립니다. 릴리스 일정은 아직은 올 4월입니다.
2. SpringDMServer
SpringDM/OSGi의 성공여부는 SpringDM Server에 달려있다고 생각해도 좋을 정도로 서버환경의 중요성은 매우 높습니다. 친절한 WAS가 없고 버그 투성이던 시절에의 악몽이 다시 되풀이 된다면 누구도 OSGi로 갈아타려고 하지 않을 것 같습니다. STS가 툴에서의 지원을 완벽하게 해주고, SpringDMServer가 서버로서의 안정성을 보장해 준다면, SpringDM 방식의 개발이 본격화 되지 않을까 싶습니다. 동시에 관련 서적도 빨리 등장하면 좋겠다는 기대를 해봅니다. 국내에 SpringDM 서적을 출간하려고 진행하는 분이 있다는 소식을 들었는데... 과연 어떤 내용일지 기대반 우려반입니다.
3. SpringBatch 2.0
스프링배치의 약진이 놀랍습니다. 이토록 빨리, 스프링관련 기술이 현장에 보급이 된 예는 batch말고는 없었던 것 같습니다. 그만큼 현장의 수요가 많고, 필요성이 높다는 것을 알 수 있는 것 같습니다. 누군가 배치 개발은 SI의 꽃이다라고 했던 것 같은데, 최초의 배치 프레임워크라는 캐치프레이즈와 함께 등장한 스프링배치가 그동안 빠르고 많은 변화를 거쳐서 본격적인 2.0시대로 들어갑니다. 액센추어라는 세계최고의 SI업체와의 합작으로 발전하고 있는 스프링배치 프로젝트가 좋은 결과를 가져와서, 대형 IT업체가 오픈소스 발전에 깊이있게 관여하는 것이 더욱 많아질 것을 기대해봅니다.
4. 스프링 스터디와 교육
KSUG에서 만남을 통해서 시작된 스프링관련 스터디 그룹(http://springstudyclub.tistory.com/)의 활동이 안정적인 단계에 다다른 것 같습니다. 사용자의 교류중 가장 깊이있게 지속될 수 있는게 있다면 바로 스터디그룹입니다. 하지만 바쁜 일정과 참여자의 선지식의 격차, 경험의 차이가 가져오는 한계가 있을 텐데 그것을 어떻게 잘 극복하고 효과적인 스터디 문화를 만들어 나갈지 주목해 볼만합니다. 다음 스터디 기수의 주제는 TDD라고 합니다. 스프링 스터디인데 왠 TDD? 라고 생각할지 모르겠지만, TDD는 아주 좋은 스프링스터디의 주제라고 생각합니다. 러퍼런스 매뉴얼과 책에 다 나와있는 내용을 그저 반복해서 나누는 것이 스터디가 아니라, 참여자 스스로 고민하고 발전할 수 있는 기회를 가지는 것이 스터디의 바른 모습이라고 보입니다. 더군다나 테스팅은 스프링의 백미입니다. 테스트없는 스프링은 상상도 할 수 없고, 스프링 없는 TDD 또한 생각하기도 끔찍합니다.
동시에 스프링과 관련된 고급레벨의 좋은 교육프로그램이 많이 등장하기를 기대해봅니다. 애니프레임과 같은 스프링을 적용한 실용제품에 대한 교육도 좋고, 스프링을 알고 사용하기는 하지만 스프링의 철학과 전략을 깊이 이해하기를 원하는 사람들을 위한 중고급 레벨의 교육도 등장할 때가 아닌가 생각이 됩니다. 개인적으로 생각하고 있는 것이 있기는 한데, 여러가지 여건상 때가 되면 공개를 해보겠습니다.
5. 스프링 서적
이건 순전히 개인적인 기대입니다만.. 올해는 스프링의 철학과 개념에 충실하면서, 스프링의 다양성을 이해하고 전략적인 접근을 할 수 있도록 도와주는 멋진 책이 출간될 것 같습니다. :)
기타 탈락한 후보들...
- Grails : 다른 분들의 기대와 다르게 저는 Grails가 올해 크게 주목받을 기술이라고 생각하지 않습니다. 물론 Grails가 얼마나 뛰어난 제품이고 스프링과 잘 접목된다는 것을 알지만, 언어가 바뀐 다는 것이 주는 갭은 생각보다 크고, 그것을 뛰어넘기에는 아직은 충분한 준비가 되어있지 않습니다. 그런면에서 Grails는 찻잔 속의 돌풍으로 끝나지 않을까 하는 우려가 있습니다. RoR조차도 기대와 다르게 확산되고 있지 못하는게 현실이죠.
Grails가 성공하려면 Groovy라는 언어가 먼저 빠르게 자바 개발자들에게 확신이 되는 것이 우선이라고 봅니다. 또한 현재는 형편없는 툴의 지원이 확실하게 발전해야 하겠죠. 그만큼의 발전이 빠르게 일어날 수 있을 만큼의 커뮤니티가 형성되는 것이 관건으로 보입니다. 오라클이 Grails를 지원하겠다는 발표를 했다고 하는데.. 글세요.
- KSUG: 큰 변화는 없을 것이라고 생각됩니다. 웨비나 얘기가 오고 가기는 하는데, 비용문제도 그렇고 헌신적으로 발표할 사람도 그렇고, 사실 아직은 부정적입니다. 그래도 포럼이 서서히 알려지고 커뮤니티로서의 기능은 꾸준히 올라갈 것 같습니다.
휴.. 이제 끌입니다.
1. 스프링소스
로드존슨이 프리랜서 시절부터 사용하던 회사명인 Interface21을 SpringSource라고 바꾸고 재작년과 작년에 두번에 걸처서 VC로부터 큰 투자를 받았습니다. 투자사가 돈을 낼 때는 큰 수익을 기대하고 있는 것이고, 대부분 기업의 수익을 통한 배당보다는 IPO나 대형 기업에 인수되어져서 큰 차익을 얻는 것이 목표입니다. 그런면에서 VC에 투자를 받은 기업이 망하지 않고 버틴다면 언젠가 JBoss, MySQL 등과 같이 합병되거나 RedHat처럼 상장을 해야합니다. 오픈소스제품을 기반으로 한 비즈니스라는 가장 힘들고 도전적인 일을 시작한 스프링개발자들도 같은 선택을 해야했고, 그 과정에서 VC의 투자는 필수적이지요. 문제는 VC의 투자 이후에 상당한 경영상의 태클이 들어온다는 것입니다. JBoss가 VC투자 이후에 Apache의 Geronimo개발팀이 JBoss코드 일부를 무단 사용했다고, 변호사를 통해서 경고서한을 보낸 것은 충격적인 일이었습니다. 오픈소스라고 해도 저작권이 있고, 지켜야 할 라이선스 조항이 있다는 것은 알고 있지만, 그렇게 거칠고 딱딱한 방법을 동원해야했나는 생각이 들어서 JBoss에 한참 정이 떨어지기도 했죠. 원인은 VC로부터의 압박이 아니었을까 생각했습니다. 마찬가지로 스프링소스 또한 VC의 투자를 받고 덩치를 키우고 관련업체들을 인수하기 시작하면서부터 VC로부터 많은 압박을 받았을게 분명합니다. 가장 중요한 것은 상장이든 인수든, 그에 필요로 하는 성장하는 수익구조를 가지고 있어야 한다는 것이죠. 스프링소스의 컨설턴트들이 스프링을 사용하는 각국의 대형프로젝트에 가서 컨설팅을 하고 그로부터 댓가를 받는 것으로는 규모를 무한하게 키우지 않는 한 큰 이익을 내기 힘듭니다. 몇년전 ThoughtWorks가 상당히 성공한 최신 IT컨설팅업체임에도 상장할만큼의 성공적인 수익을 내지 못해서, 초기 투자자들이 투자비를 회수한다고 난리를 쳤다는 얘기를 듣기도 했지요. 스프링 소스는 그에 비하면 아직 작은 업체입니다. 그렇다고 무작정 컨설턴트 숫자를 늘리면 질은 떨어지겠지요. 결국 선택은 상용제품과 지속적인 서비스를 판매하는 것입니다. 그래서 등장한 것이 Spring Tool Suite을 비롯한 Spring Enterprise입니다. 또 service subscription을 판매하는 것을 통해서 안정적인 수입을 만들어 내는 것입니다. 로드 존슨이 재작년 TSE에서 앞으로 스프링 소스의 주력 마케팅 타겟은 포츈500 기업이라고 얘기했습니다. 그를 위해서 본부를 실리콘벨리로 옮기고 로드 존슨은 주로 그 오피스에서 일을 하고 있죠. 문제는 오픈소스가 아무리 성공적으로 도입되었다고 한들, 모든 기업이 다 그 개발업체에게 상용 서비스를 받으려하지 않는 다는 것이죠. JBoss가 전체 WAS순위 4위인가 하던데.. JBoss를 도입한 업체 중, 상용 서비스를 받고 있는 곳은 7% 정도라는 얘기를 들은 적이 있습니다. 상용서버라면 아마도 90% 이상이겠죠(기한이 지나서 서비스를 갱신 안하는 곳정도를 제외하면..). 기본적인 라이선스 비용도 없는데다, 상용서비스의 비율도 사실 매우 작기 때문에 단순하게 오픈소스공개 후 상용서비스라는 공식은 사실상 이미 실패한 것이나 다름없습니다. 그래서 뭔가 오픈소스에는 없는 부가기능과 가치를 가지는 전용제품이 필요한 것이고, 그것이 바로 Spring Enterprise입니다. 과연 얼마나 많은 기업이 스프링소스로부터 서비스를 받고 있을까요? 잘 모르겠습니다만, 생각보다 그리 많지는 않아보입니다. STS같은 경우는 개인적인 사용만 무료로 허용되어있지만, 사실 회사에서도 그냥 다 쓰지요. 왠만한 기술적인 질문은 자체적인 온라인 커뮤니티나 수많은 공개된 자료에서 답을 찾을 수 있습니다. 요청하면 로드 존슨이 달려와서 해주는게 아니라면 구지 돈을 주고 조금 더 전문적인 서비스를 받을만한 절박함이 없습니다. 또 기술력이 있는 대형기업이라면 스스로 스프링을 개선하고 확장해서 사용합니다. TSE등에서 사례발표를 한 많은 대형 금융기관이나 LInkedIn등의 적용사례를 보면, 자체적인 기술력으로 스프링을 얼마든지 편리하게 사용하도록 개선하고, 관련 툴을 만들어서 적용하고 있습니다. 아직까지 스프링소스가 제공하는 상용제품과 서비스가 그런 업체들에게 줄 수 있는 특별한 부가가치가 없어보입니다. 반면에 보수적이고 덩치가 큰 기업은 안정적이고 지속적인 서포트가 관건입니다. 스프링이 구버전 호환성이 뛰어나다고 해도 구지 꼭 필요하지 않으면 신규버전으로 업그레이드 안하는 것이 보수적인 기술정책을 가진 회사들의 사고방식입니다. 얼마전까지 Spring1.x를 고집했던 atlassian과 같은 ISV도 마찬가지지요. 그러기 위해서 구버전의 지속적인 유지보수가 보장되야 하는데, 각 브랜치를 계속 디버깅하고 관리한다는 것은 오픈소스 개발업체로는 큰 부담입니다. 그만큼의 보상이 필요하죠. 그래서 스프링소스가 올해 큰 악수를 하나 둡니다. 바로 유지보수정책의 변화이죠. 구버전도 3년간 유지보수 버전을 제공하지만, 바이너리 릴리스는 상용서비스 업체에만 제공하고 오픈소스로는 맨 프로젝트 소스만 제공한다는 것이죠. 어떻게 생각하면, 상용서비스를 받는 업체에게는 그만큼의 만족감을 주고, 오픈소스로 찾는 이들에게는 조금의 수고만으로 더 안정적인 유지보수 서비스를 제공한다는 면에서 사실 윈-윈하는 정책이었습니다. 하지만, 스프링소스의 정책의 변화에 대한 친절한 홍보 부족과 스프링을 시기하는 인간들의 비열한 공격으로 스프링소스의 정체을 오해한 많은 개발자들이 생겨났고, 상처 받은 스프링의 신뢰를 회복하느라 로드 존슨이 꽤 땀을 빼야 했습니다. 연말에 열린 S1A에서 느낀 점은 그런면에서 스프링소스의 긴장감을 잘 보여줍니다. 이전과 다르게 딱딱해진 컨퍼런스도 그랬고, 많은 참석자들이 "왜 돈을 내고 와서 마케팅 발표를 들어야 하는지 모르겠다"는 푸념도 참 안타까웠습니다. 그들의 열정과, 오픈소스와 비즈니스를 동시에 지켜야 하는 현실적인 고민, 그리고 최선의 정책도 다 이해합니다만... 개발자들은 그렇게 이해심많고 착하지만은 않으니 걱정이지요.
고군분투하는 스프링소스의 비즈니스와 그에 휘둘릴지도 모르는 오픈소스 스프링을 올해의 안타까웠던 스프링관련 첫번째로 꼽습니다.
2. KSUG
KSUG는 스프링사용자들의 만남을 명분으로 한, 공개세미나 팀이었죠. 그러다 오프라인의 한계를 넘기 위해, 또 오프라인 행사준비에 점점 한계를 느끼는 운영팀의 이런 저런 핑계 때문에 올해 온라인 커뮤니티로 변신을 꾀했습니다. 원래 목표는 포럼과 블로그, 그리고 스크린캐스트의 활성화였죠. 포럼은 그럭저럭 자리를 잡고, 한동안 스프링관련 좋은 토론과 질의응답이 이어졌습니다만, 홍보의 부족으로 아직도 대부분의 스프링개발자들은 이런 공간이 있는 줄도 모르고 있는 상황이고, 쉽고 편하게 질문과 생각을 나누기에는 아직 분위기가 그렇게 잘 형성되어있지 않습니다. 반쯤의 성공이라고 봐야 할까요.
KSUG블로그는 새로운 필진의 등장으로 좋은 글들이 많이 올라옴에도 불구하고 역시 홍보의 문제 때문인지 방문자가 적고, 올라오는 글에 대한 포럼에서의 피드백과 토론이라는 기대에는 거의 부합하지 못하고 있습니다. 주제의 어려움도 한 이유이고, 근본적으로 온라인에서의 기술적인 토론이 점점 사라져가는 그런 추세 때문인지도 모르겠습니다. 어쩌면 다들 너무 마음이 바쁘기 때문일지도...
스크린캐스트는 몇분이 올려준 것을 제외하면 사실 처음 생각했던 것을 거의 진행하지 못했습니다. SpringOSGi/DM을 주제로 잡고, 일단 IBM DW에 유료(하지만 그쪽 정책에 따라 시간은 짧은 심플한) 버전을 올려서, 툴이나 운영비를 위한 수익을 만들고, 바로 뒤이어 KSUG에 길고 충분한 내용을 담은 풀 버전을 올리자는 것이 처음 계획이었습니다. 물론 못했죠. IBM DW에만 좋은 것을 제공하고 끝났습니다. 물론 순서대로 보면 안녕회 회장이 먼저 시리즈를 시작해야 하기 때문에 뒤를 따라야 하는 저는 시작도 못했다고 변명할 수 있습니다만, 어쨌든 게으름 내지는 무성의 함이 원인이었던 것 같습니다. 특히, 오프라인 세미나때 못했던 @MVC의 온라인 스크린캐스트 제공은, 별다른 관심도 받지 못한채로 그냥 흐지부지 되었습니다.
여러모로, KSUG의 올 한해는 아쉬움이 많이 남습니다. 스프링 보급이나 홍보의 시대는 지났고, 진정으로 스프링을 사용하는 사람들끼리 효과적인 교류를 가지자는 취지의 KSUG가 그냥 가까운 몇 사람들과의 친목을 다지는 수준에서 머물른 것이 아닌가 하는 아쉬움이 큽니다. 물론 KSUG를 통해서 본격적으로 등장하신 여러 분들이 있다는 면에서 보람도 있긴합니다만... 지켜지지 않는 약속을 남발한, 저를 포함한 운영진의 반성이 필히 요구되는 한해였습니다.
nhn과의 후원관계에 대한 상호 오해에서 일어난 사건은 가장 씁쓸한 기억으로 남습니다.
3. 애니프레임과 기업의 기술공개
애니프레임에 대해서는 사실 아쉬움은 없습니다. 기술적인 아쉬움이야 일정 부분 있을 수 있겠습니다만, 현장에서의 치열한 논쟁과 부딫침 속에서 어쨌든 만들어지고 사용되어진 제품을 오픈소스 프로젝트로 공개했다는 점에서 일단 90점을 먹고 들어가기에 애니프레임 공개은 2008년 스프링관련 최고의 사건이 아니었나 생각합니다. 사실 애니프레임의 공개를 바라보면서 기대했던 것은 다른 경쟁 기업이나 대형업체들이 자신들의 애플리케이션 프레임워크나 플랫폼을 덩달아 공개하지 않을까 하는 것이었습니다. 여기저기서 SDS의 그런 깜짝 공개에 놀라서, 자신들의 프레임워크도 공개하려고 추진한다는 소식도 들어왔습니다만, 작년 말까지 별다른 공개는 없었습니다. 그런면에서 애니프레임은 여전히 독보적입니다. 하지만, 스프링관련 프레임워크의 공개를 통한 경쟁과 상호발전을 기대했던 분들에게는 여전히 아쉬움이 남습니다. 세계적으로도 기업의 표준 프레임워크가 오픈소스로 공개된 예는 거의 없습니다. 스프링소스가 보유하고 있는 ROO도 몇년째 비공개 상태죠. 사실 뒤를 이어서 기선님이 주도해서 OSAF2.0의 마일스톤 버전이 공개됐습니다만, 정말 아무런 관심도 못끌고 잊혀져버렸습니다.
애니프레임과 관련해서 주변의 KSUG멤버들의 모습을 관찰해 본 결과, 대부분은 애니프레임을 제대로 공부하거나 사용해보지 않고, 겉으로 나타난 몇가지 사실만 가지고 그냥 비판만 하기에 급급하더군요. 엔지니어로서 참 안좋은 태도였던 것 같습니다. 좀 더 진지하게 공개된 오픈소스 프로젝트에 대해서 살펴보고, 부족한 부분은 제안하고, 기여하려는 마음을 가진 개발자들이 없다면, 앞으로 어떤 기업에서 어떤 프로젝트가 공개된다 할지라도 별 의미가 없지 않을까 하는 생각이 들기도 했습니다.
4. OSGi/SpringDM
1.0정식버전이 공개가 된 SpringDM이 2008년의 아쉬움의 4위입니다. 솔직히 SpringDM1.0은 1.0이 아닙니다. 적어도 엔터프라이즈 개발에서의 OSGi 적용을 명분으로 둔 SpringDM이라면 웹을 포함한 full layer의 지원을 완성하고 1.0을 릴리스했어야 한다고 생각됩니다. 하지만 1.0은 SpringMVC나 Web레이어의 지원이 없는 채로 공개되었고, 현재 1.2마일스톤 버전이 나온 지금도 아직 그 부분에서의 지원은 완벽하다고 보여지지 않습니다. 물론 기술적으로는 충분한 제공이 되긴 했지만, 부족한 문서나 샘플도 그렇고, SpringIDE에 통합되지 않은 면도 그렇고, 아직도 많은 이슈를 남겼다는 면에서 SpringDM이 진정한 OS-JEE-i를 위한 기술로 자리 잡기에는 아직도 한계가 있어 보입니다. 그 와중에 tomcat과 결합해서 손쉽게 OSGi 애플리케이션을 서버환경에서 사용하게 만들어주는 SpringDMServer가 공개되었습니다. 역시 1.0이 공개되긴 했지만, 아직도 현장에서 사용하기에는 한참 부족합니다. 핵심은 구현은 되었다고 보이지만, 사용의 편의성도 불편하고, 아직 계획만 되어있고 만들어지지 않은 기능도 엄청납니다(Rop Harrop의 키노트 발표에 보면 한 50가지 정도가 남았더군요...).
플랫폼의 변경이라는 이 커다란 변화가 쉽게 오리라고 생각하지는 않지만, 수많은 기업들이 OSGi에 뛰어들고 매진하고 있는 마당에 가장 앞서있다고 하는 SpringDM과 관련 기술이 이 정도 레벨에서 머물고 빠르게 발전하지 못하고 있는 것은 아쉬움입니다. 그나마 좋은 소식은 SpringDM 2가 OSGi의 엔터프라이즈 컴포넌트 기술의 차기 표준이 되었다는 점인데.. 그부분에 SpringDM개발팀의 여력이 많이 뺐긴 것은 아닌지 하는 의심도 좀 들긴합니다.
5. 준비안된 스프링의 도입열풍
스프링이 이제 메인스트림 기술로 완전히 자리잡은 듯 합니다. 국내의 보수적인 대형 SI들이 적극 사용하거나, 사용을 고려하고 있다는 면에서 이미 충분히 주류기술이 된 것처럼 보입니다. 하지만 이런 열기 속에서 정작 스프링을 스프링 답게 사용하지 못하는 모습이 자주 눈에 띕니다. 스프링을 2주 공부하고 책에 나온 예제 정도 배낀후, 자신이 이전에 개발하던 스타일로 나머지는 멋대로 떡칠한 코드를 가지고 고급 스프링 컨설턴트로 현장에 들어가는 사람들을 본적이 있습니다. 스프링을 도입했지만 귀찮게 새로운 기술을 공부해야 했던 것 말고 뭐가 좋은지 모르겠다는 현장의 푸념도 들려옵니다. 살펴보면 스프링을 그저 가져다 넣기만 했지, 스프링의 기본적인 개발철학조차도 이해못한 채로 엉망으로 사용을 한 경우들입니다. 주위에 그런 얘기가 너무 많이 들려옵니다. 시중에 공개된 스프링책의 어떤 것도 스프링의 진정학 개발원리와 철학, 목표를 얘기해주고 있지 못합니다. 스프링을 그저, 가져다가 넣고 예제 몇개 살펴보고, 샘플 카피해서 사용하면 되는 툴로 이해하는 경우도 많이 보았습니다. 그런 준비안된 스프링 도입, 무비판적인 수용이 결국 스프링에 대한 반감을 많이 키우기도 해서인지, 최근에는 스프링을 도입하는 것을 "감정적으로" 꺼려하는 사람들의 이야기도 들었습니다.
기술적으로 보자면, 애플릿을 제외하면 자바에서 스프링을 도입하지 않을 곳이 없다고 생각합니다. 하지만, 기술적인 적합성만으로 무엇이든 가져다 사용할 수 없는 것이 현장의 현실입니다. 충분한 학습과 전략수립 없이 사용해봐야 큰 효과를 못보는 것이 스프링입니다. 그런면에서 과열된 스프링의 인기는, 얼마 지나지 않아서 스프링에 대한 거부감 내지는 오해를 크게 불러오지 않을까 하는 우려를 낳게 합니다.
그러면에서 좋은 스프링의 교육과 가이드 서적, 안내들이 아쉬웠던 2008년 이었습니다.
다음은 내년의 스프링관련 기대종목을 꼽아봅니다.
1. Spring 3.0
누가 뭐래도 내년 스프링관련 가장 큰 소식은 Spring3.0의 발표입니다. 스프링이 처음으로 크게 진화하고 변화한 모습을 보여주는 것이 바로 3.0입니다. 지겹게 끌고 다녔던 JDK1.4도 이제 EOSL되버렸고, 스프링도 과감하게 Java5+로 변신합니다. 그동안 오래 지연했던 애노테이션의 도입도, 2.5에서 본격적으로 사용하기 시작하면서 3.0에서는 거의 애노테이션 만으로 기존의 XML에서 했던 것을 대부분 수용할 수 있는 단계로까지 발전합니다.
물론 이전 버전과의 API레벨에서의 완벽한 호환은 보장합니다. 이전 설정방법도 당연히 보존됩니다. 하지만 Controller 계층구조가 deprecate되버리는 과감한 변신이 들어갑니다. 또 웹과 관련된 부분이 대폭 지원이 되며, SWF와 JavaConfig이 core에 대거 합병되버립니다. 릴리스 일정은 아직은 올 4월입니다.
2. SpringDMServer
SpringDM/OSGi의 성공여부는 SpringDM Server에 달려있다고 생각해도 좋을 정도로 서버환경의 중요성은 매우 높습니다. 친절한 WAS가 없고 버그 투성이던 시절에의 악몽이 다시 되풀이 된다면 누구도 OSGi로 갈아타려고 하지 않을 것 같습니다. STS가 툴에서의 지원을 완벽하게 해주고, SpringDMServer가 서버로서의 안정성을 보장해 준다면, SpringDM 방식의 개발이 본격화 되지 않을까 싶습니다. 동시에 관련 서적도 빨리 등장하면 좋겠다는 기대를 해봅니다. 국내에 SpringDM 서적을 출간하려고 진행하는 분이 있다는 소식을 들었는데... 과연 어떤 내용일지 기대반 우려반입니다.
3. SpringBatch 2.0
스프링배치의 약진이 놀랍습니다. 이토록 빨리, 스프링관련 기술이 현장에 보급이 된 예는 batch말고는 없었던 것 같습니다. 그만큼 현장의 수요가 많고, 필요성이 높다는 것을 알 수 있는 것 같습니다. 누군가 배치 개발은 SI의 꽃이다라고 했던 것 같은데, 최초의 배치 프레임워크라는 캐치프레이즈와 함께 등장한 스프링배치가 그동안 빠르고 많은 변화를 거쳐서 본격적인 2.0시대로 들어갑니다. 액센추어라는 세계최고의 SI업체와의 합작으로 발전하고 있는 스프링배치 프로젝트가 좋은 결과를 가져와서, 대형 IT업체가 오픈소스 발전에 깊이있게 관여하는 것이 더욱 많아질 것을 기대해봅니다.
4. 스프링 스터디와 교육
KSUG에서 만남을 통해서 시작된 스프링관련 스터디 그룹(http://springstudyclub.tistory.com/)의 활동이 안정적인 단계에 다다른 것 같습니다. 사용자의 교류중 가장 깊이있게 지속될 수 있는게 있다면 바로 스터디그룹입니다. 하지만 바쁜 일정과 참여자의 선지식의 격차, 경험의 차이가 가져오는 한계가 있을 텐데 그것을 어떻게 잘 극복하고 효과적인 스터디 문화를 만들어 나갈지 주목해 볼만합니다. 다음 스터디 기수의 주제는 TDD라고 합니다. 스프링 스터디인데 왠 TDD? 라고 생각할지 모르겠지만, TDD는 아주 좋은 스프링스터디의 주제라고 생각합니다. 러퍼런스 매뉴얼과 책에 다 나와있는 내용을 그저 반복해서 나누는 것이 스터디가 아니라, 참여자 스스로 고민하고 발전할 수 있는 기회를 가지는 것이 스터디의 바른 모습이라고 보입니다. 더군다나 테스팅은 스프링의 백미입니다. 테스트없는 스프링은 상상도 할 수 없고, 스프링 없는 TDD 또한 생각하기도 끔찍합니다.
동시에 스프링과 관련된 고급레벨의 좋은 교육프로그램이 많이 등장하기를 기대해봅니다. 애니프레임과 같은 스프링을 적용한 실용제품에 대한 교육도 좋고, 스프링을 알고 사용하기는 하지만 스프링의 철학과 전략을 깊이 이해하기를 원하는 사람들을 위한 중고급 레벨의 교육도 등장할 때가 아닌가 생각이 됩니다. 개인적으로 생각하고 있는 것이 있기는 한데, 여러가지 여건상 때가 되면 공개를 해보겠습니다.
5. 스프링 서적
이건 순전히 개인적인 기대입니다만.. 올해는 스프링의 철학과 개념에 충실하면서, 스프링의 다양성을 이해하고 전략적인 접근을 할 수 있도록 도와주는 멋진 책이 출간될 것 같습니다. :)
기타 탈락한 후보들...
- Grails : 다른 분들의 기대와 다르게 저는 Grails가 올해 크게 주목받을 기술이라고 생각하지 않습니다. 물론 Grails가 얼마나 뛰어난 제품이고 스프링과 잘 접목된다는 것을 알지만, 언어가 바뀐 다는 것이 주는 갭은 생각보다 크고, 그것을 뛰어넘기에는 아직은 충분한 준비가 되어있지 않습니다. 그런면에서 Grails는 찻잔 속의 돌풍으로 끝나지 않을까 하는 우려가 있습니다. RoR조차도 기대와 다르게 확산되고 있지 못하는게 현실이죠.
Grails가 성공하려면 Groovy라는 언어가 먼저 빠르게 자바 개발자들에게 확신이 되는 것이 우선이라고 봅니다. 또한 현재는 형편없는 툴의 지원이 확실하게 발전해야 하겠죠. 그만큼의 발전이 빠르게 일어날 수 있을 만큼의 커뮤니티가 형성되는 것이 관건으로 보입니다. 오라클이 Grails를 지원하겠다는 발표를 했다고 하는데.. 글세요.
- KSUG: 큰 변화는 없을 것이라고 생각됩니다. 웨비나 얘기가 오고 가기는 하는데, 비용문제도 그렇고 헌신적으로 발표할 사람도 그렇고, 사실 아직은 부정적입니다. 그래도 포럼이 서서히 알려지고 커뮤니티로서의 기능은 꾸준히 올라갈 것 같습니다.
휴.. 이제 끌입니다.
Prev
Rss Feed