내가 좋아하는 스프링과 RoR 외에 최근에 관심을 가지고 지켜보고(만) 있는 것이 있다면 Seam/WebBean이다. 마침 이번 JCO 컨퍼런스에서 Seam/WebBean 관련 발표들이 있었다는 얘기를 듣고 흥미로웠는데, 발표자료를 하나 발견해서 훑어봤다.  "오픈소스에서 JEE6의 표준스펙이 되기까지"라는 발표제목에서 알 수 있듯이 Seam/WebBean은  오픈소스 기술로 출발해서 자바표준이 된 또 하나의 사례이다. 하이버네이트가 JPA라는 표준 EJB서브기술로 등극한 것에 이은 두번째 개빈 킹의 표준만들기 작품이다.

Seam팀에서는 먼 옛날 구닥다리 기술이라고 비아냥대는 detached object를 사용하는 "세션-모델 애트리뷰트" 방식의 SpringMVC 기술조차도 잘 사용하지 못하는, 평범한 request scope + cookie, url parameter, httpsession 스타일을 선호하는 개발자들에게 갑자기 conversational/contextual/stateful 어쩌고 기술이 쉽게 받아들여질지는 의심스럽긴 하다. EJB 전성시대에 조차 인정받지 못했던 stateful 기술에 대한 반감과 각종 선입견들을 넘어설만한 획기적이고 매력적인 무엇인가를 느낄 수 있어야 할텐데… 당장에 이 발표자료를 읽어보면 후반에 등장하는 문구처럼 "머리가 지끈 아프다". 로드 존슨이 방만하다고 비꼰 @Bijection의 방대한 애노테이션에 일단 기가 죽는다. 게다가 아직은 찬밥신세인 JPA/Hibernate에 묶여있는 것도 조금은 한계로 느껴진다. 물론 ibatis를 사용하는 방법이 있기는 한 것 같은데(Seam과 스프링을 함께 써서..) 과연 Seam의 특징과 장점을 유지하면서 transparent persistence기술을 사용하지 않을 수 있는 것인지 의심스럽다.

발표내용을 보면 기존 EJB에서 1% 미만의 사용률을 가지는 Entity빈은 문제가 있어서 Hibernate스타일의 JPA로 대치되었고, 나머지 SessionBean, MDB 등은 "괜찮다"라고 슬며시 넘어갔는데, 사실 Stateful SB도 기존의 EntityBean 못지 않게 거의 외면 당한 것이 아닌가? SFSB가 멀쩡했다면 구지 Seam이 새로운 stateful기술을 들고 나오지 못했을 것이다. 그런면에서 기존 stateful 기술(특히 SFSB)의 단점과 한계를 설명하고, 그것을 Seam에서는 어떻게 효과적으로 극복했는가에 대한 설명이 없다면 Seam/WebBean을 곱게 바라보기가 쉽지 않을 것이다.

또 한가지 발표자료에서 불편하게 느껴지는 것은 표준에 대한 강조이다. "표준은 중요하다" 항목에 보면 "모든 기술은 표준으로 연결되어야 한다"고 전제 한 뒤, EJB3, JSF와 같은 표준을 포용한 Seam이 결국엔 자신도 표준 기술이 되어서 표준기술로 천하통일을 이루었다는 식의 설명이 나온다.

과연 EJB3가 성공한 표준기술인가? JSF는? 나는 아니라고 생각한다. 두가지 다 그 자체로는 그다지 성공하지 못한 부족한 점이 많은 기술이다. EJB3와 JSF가 그토록 좋은 표준이라면 Seam/WebBean이 등장할 이유가 없다. EJB3에 부족한 많은 부분들, 불편한 부분을 커버해주기 위해서 등장한 것이 Seam이 아니던가? 또한 대부분의 개발자들에게 욕을 먹은 것이 역시 JSF가 아닌가? 오죽하면 JSF를 쓰기 위해서는 어쩔 수 없이 JSF의 불편한 많은 점을 극복하게 해주는 Seam을 쓸 수 밖에 없다는 얘기가 나올까. 그러니 Seam은 기존의 불완전하고, 한계가 있는 표준기술을 그나마 사용하게 만들어주기 위해서 등장했다고 볼 수 있다. 게다가 Seam은 그 표준에 매여있지도 않다. EJB3를 사용하지 않고 일반 POJO를 사용할 수 있다. 그것이 Seam의 한가지 장점이다. 그렇다면 구지 EJB3는 왜 사용했어야 했을까 의심스럽다.

Seam이 표준기술을 효과적으로 지원하고, 잘 포용한 덕에 새로운 표준으로 인정받았는지는 모르겠지만, "모든 기술은 표준으로~"라는 식으로 강조하기엔 자바에서 표준기술의 권위는 이미 빛바랜지 오래가 아닐까.

 

어쨌든 Seam과 그런 스타일의 기술에 계속 끌리는 것이 있다.  이런 all-in-one 스타일의 통합프레임워크(일명 unframework)가 주는 장점이 분명히 있고, 어쩌면 스프링이 제공하는 수많은 선택의 자유에서 방황하는 개발자들이 가끔은 불쌍하기에 Seam처럼 상대적으로 쉽게 접근할 수 있는 강압적인 프레임워크와 도구들이 많이 등장했으면 하는 바램도 있다. 사실 사내표준이니, 기업통합 프레임워크니 하는 것들을 많이 만들어 지고 있지만, Seam수준으로 어느정도 자신만의 스타일과 장점을 극대화하고 매우 편리하게(제한된 기술범위와 응용방식 안에서 쉽게 배우고 빠르게 개발이 가능한) 사용할 수 있도록 만들어지는 통합프레임워크는 별로 찾아보기 힘들다. 공개가 안되서 내가 잘 모를지도 모르겠지만… 글세?

 

그나저나 스프링소스는 결국 ROO를 공개하지 않을 모양인가보다. ROO와 같은 매력적인 통합 프레임워크가 진작에 등장했다면 Seam못지 않게 인기를 끌었을 테지만, 그렇게 특정 스타일의 애플리케이션 구조를 (의도와 상관없이) 강제하기에는 스프링의 야망의 폭이 너무 큰듯하다. 더욱 막강해진 애노테이션 기반 설정과 바로 쓸 수 있는 conversational scope의 지원, SWF 코어의 도입, JSF2의 전폭적인 지원등이 예정된 Spring3.0이 나오면 Seam과 비슷한 스타일의, 그러면서 더욱 유연한 프레임워크를 한번 만들어볼까 궁리중이다.

일단 Seam을 좀 더 깊이 공부하고 실전에 한번 적용도 해봐야겠다. Seam+EJB3+Spring의 짬뽕 프로젝트를 한번 만들어보면 어떨까. 흠흠.. 마루타가 되줄 프로젝트가 어디 없을까.

내가 관심을 가지고 가장 많이 사용하는 프레임워크는 당연히 스프링이다. 지난 5년동안 참여한 개발 프로젝트의 90%에 스프링을 적용했다.  RoR도 스프링 다음으로 관심은 많지만 아직 많은 사용을 못하고 있다. 최근에는 씸(Seam – 한글로 적으니 영…)에 대해서 관심을 가지기 시작했다.

한국에서는 JSF, EJB3와 함께 거의 무시되는 분위기지만 해외에서의 인기는 제법 높다. 그건 아마도 JSF의 인기 때문일 것이다. 한동안 JSF는 자바에 위협이었던(지금은 전~혀 아니지만) 닷넷의 개발자를 끌어오기 위한 미끼 였다는 얘기도 있었다. 비주얼 툴과 컴포넌트 방식의 웹 UI 개발에 익숙한 닷넷 개발자를 유혹하기에 좋은 도구라는 것이다. 하지만 그 인기에도 불구하고 JSF는 꽤 많은 단점으로 욕을 엄청 먹어왔다. 어쩌면 JSF의 구세주로 등장한 것이 바로 씸인 듯 하다. 많은 개발자들이 JSF를 쓰려면 씸을 사용하라고 추천한다. 가만히 보면 씸을 쓰기 위해서 씸을 쓰는게 아니라, JSF 때문에 씸을 사용하는지도 모르겠다. 물론 씸 개발팀에서는 말도 안되는 소리라고 반박하겠지만, 제법 많은 글에서 “스프링을 사용하다가 JSF를 쓰기 위해서 씸으로 바꿨다”라는 이야기를 볼 수 있으니 그것이 씸의 인기에 중요한 역할을 했음은 인정할 수 밖에 억다.

사실 씸은 스프링과 매우 성격이 다른 프레임워크다. 심지어 프레임워크라고 불리는 것도 별로 좋아하지 않는 듯 하다. Seam in Action에서는 unframework라는 말로 Seam은 단지 프레임워크가 아니라고 설명한다. 오히려 애플리케이션 스택이라고 불리기를 원하는 것 같다. 물론 스프링도 애플리케이션 프레임워크지만, 그 성격은 많이 다르다. 씸은 RoR에 더 가깝다. 그 자체로 특정한 스타일을 강제하는, 고정적인 틀을 가진 개발 플랫폼이라고 볼 수 있다. 그에 반해 스프링은 너무하다고 싶을 정도로 제한이 없는 무한한 옵션을 제공하는 프레임워크이다. 그래서 어떤 면에서 보면 스프링이 낫다. 사용자들에게 충분한 선택권을 주고, 어떤 기술과도 스프링의 철학을 따라서 잘 융합하도록 만들어 준다. 반면에 스프링은 너무 불친절하다. 스프링을 공부하고나서 바로 스프링으로 만드는 애플리케이션은 이런 이런 기술을 써서 이런 구조로 만든다는 것을 알 수 있을까? 스프링에는 그런게 없다. 모든 도로를 달릴 수 있는 자동차가 있다고 해서, 최고의 운전경로를 내놔라라고 할 수 없는 것과 마찬가지이다. 그것은 개발자와 그 환경에 달려있다. 그런면에서 개발자가 지는 짐이 많다. 그 유연함을 혜택으로 볼 수도 있지만, 반면에 불편함으로 느낄 수도 있다. 그래서 애니프레임처럼 스프링을 특화된 틀로 다시 제한하고 연관 기술과 사용유형을 제한하는 스프링 기반 프레임워크가 필요한 것이다. 반면에 씸은 RoR처럼 강한 주장을 가지고 있는 프레임워크이다. 기술도 제한되어있다. EJB, Hibernate, JSF가 필수이다. (좀 더 자료를 찾아보니 EJB, Hibernate, JSF가 기본이기는 하지만 필수는 아니다. EJB대신 POJO모델을 사용할 수도 있고, 최근에 나온 버전에서는 Wicket도 지원하기 시작했다) 내부 구조도 매우 강한 결합을 가지고 있다. 따라서 한편으로는 매우 딱딱하게 느껴지기도 한다. 반면에 어떤 이들에게는 매우 편한 기술이 될 수도 있다. 별 고민을 안하고 따라가면 되니까 학습하기도 훨씬 낫다.

따라서 스프링과 씸을 바로 비교하는데는 문제가 있다. 각각 지지하는 프로그래밍 철학도 다를 뿐더러, 근본적으로 다른 층위에 존재하는 기술이기 때문이다. 씸이 선호하는 상태를 가진(stateful) 대화형(covnersational) 구조와 스프링의 기본(단지 기본이지 제한이 아니다) 모드인 상태가 없는(stateless) 방식의 싱글톤 구조에는 차이가 있다. 개빈 킹은 공공연히 스프링이 퍼뜨리고 있는 stateless 방식의 프로그래밍 모델의 문제에서 개발자들을 도와주기 위해 한차원 높은 상태를 가진 대화형 기술의 씸을 개발했다고 말한다. 하지만 정확하게 따져보면 잘못된 공격이다. 스프링은 상태가 없는 모델을 강제하지 않는다. 바로 여기에 스프링의 강점이 있다. 스프링은 얼마든지 프로토타입 모델, 세션 레벨 스코프 및 임의의 스코프를 가지는 프로그래밍 모델을 지원한다. 이미 2.0부터 지원된 기능이다. 그것을 이용해서 얼마든지 상태를 가진 프로그래밍 모델을 스프링에 적용할 수 있다. 대표적인 것이 바로  스프링 웹 플로우이다.

그래서 씸은 스프링이 아니라 스프링 웹 플로우와 비교되야 마땅하다.

자료를 찾아보다가 Seam과 Spring(Web Flow)를 비교한 멋진 글을 발견했다. 개인 블로그에 쓰던 글을 깔끔한 문서로 정리해놨다. 보고 감탄이 절로 나왔다. 꼼꼼하게 읽어보면 씸과 SWF의 특징과 차이, 장단점을 이해할 수 있을 것이다.

SWF는 매우 빠른 속도로 발전하고 있다. JSF지원도 대폭 강화되었다. 아마도 씸을 의식한 것이 아닌가 생각된다. 물론 그 시작은 매우 오래전에 출발한 것이지만.

씸이 가장 강세인 부분은 아마 개발툴 부분일 것이다. 수천억에 레드햇에 인수된 제이보스의 자금력 덕분인지, 좋은 툴 회사를 인수해서 빵빵한 개발툴을 제공하고 있다. 마침 베타버전으로 제공되고 있어서 JBoss Developer Studio를 사용해보고 있는데, 정말 스프링이 이만큼 좋은 툴을 제공하면 얼마나 좋을까 하는 부러운 마음이 들게 할만큼 매력적이다.

물론, 스프링 자체는 툴로서 발전하기에는 제한이 많다. 당장에 프로젝트 생성부터 스프링은 무한한 옵션을 가지고 있으니 제한적인 상위 프레임워크로 만들기 전에는 프로젝트 생성 위저드 하나 제공하기 쉽지 않다. 그에 반해서 툴의 지원이 중요한 SWF는 상대적으로 SpringIDE의 지원을 많이 받고 있다. 하지만 아직 IDE개발이 그다지 빠르게 진행된다는 느낌은 받지 못해서 아쉽다.

여전히 나는 스프링이 가장 매력적이다. 나름 빵빵한 기술과 장점으로 무장한 씸이 스프링을 열심히 공격하면서 위세를 떨치려 하고 있지만 스프링의 절대적인 위치는 쉽게 흔들지 못할 것으로 보인다. 그럼에도 스프링의 약한 부분에 대해서 매우 강한 대안을 제시하고, 일종의 틈새를 잘 만들어서 인기를 끌고 있는 씸이 그렇게 만만하게 보이지많은 않는다. 최근에 개빈킹이 정성을 들인 웹빈이니 하는 것들도 등장하고(JCO 컨퍼런스에서 발표도 한다지…) 여러모로 관심의 대상으로 떠오르고 있다.

어설프게 알고 비판을 하거나, 역시 소개 글 정도나 읽고는 대단한 것처럼 떠벌리거나, 잘 아는 척하는 것은 별로 좋지 않다. 제대로 공부를 해보자.

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha