EJB3가 JNDI를 이용하는 초급레벨의 DI를 지원(공식적으로 DI라는 개념을 가지고 나온 것은 아니지만)하자 "JNDI에 의존하는 게 무슨 DI냐"라며 EJB킬러였던 로드 존슨은 바로 씹어 버렸다.

EJB를 포함하는 풀 JEE표준기술이 떠야 돈을 버는 WAS 업체에 입사하고, 스스로 스펙을 주도하며 EJB3에 올인했던 레드햇/JBoss의 개빈 킹은 나중에 "스프링은 사실 사설(proprietary) JNDI 구현에 불과하다, DI컨테이너 그까짓거 3시간이면 만든다"라며 반박했다. 그리고 망해가는 EJB3를 구하기 위해서 씸을 들고 나온다.

미친 밥이라는 별명을 가진 구글의 밥 리는 "시대가 어느 때인데 XML로만 설정이 가능한 DI기술이 머냐. 스프링 개발자들은 구글의 자바 책임자인 조쉬 블록의 Effective Java를 읽고 자바 기초나 더 배우고 와라"는 유명한 비난을 한 뒤에 스스로의 발언에 책임지기 위해서(스프링에 대해서 잘 모르고 비난한 부분에 대해서는 나중에 무리뭉실 사과했다)  구글 주스라는 애노테이션 기반의 초경량 초고성능(스프링보다 100배?) 순수 DI 프레임워크를 만든다.

로드 존슨은 스프링은 XML이면 충분하다는 기존의 고집을 꺽고 드디어 애노테이션 설정을 도입한 스프링 2.5를 내놓는다. 그 결정의 배경에 대해서 "EJB3와 구글 주스의 설정방식에 대한 개발자들의 높은 관심"라고 이야기했다.

씸은 미련하게 EJB3나 표준기술에 종속되어 있으려 하지 않았다. 오히려 스스로를 중심으로 놓으려는 노력을 해왔다. EJB3 stateful 빈 대신 단순 POJO나 스프링을 이용할 수 있도록 하고 있고, JPA대신 하이버네이트를 이용해도 된다. 심지어 JSF라는 단일 뷰 기술을 벗어나서 다른 비표준 컴포넌트 방식의 웹 프레임워크도 포용하려고 하고 있다.  결국 씸은 기존 표준 기술을 잘 사용하기 위해서라는 명분을 지키려는 노력 대신 스스로를 표준으로 만들려는 시도를 하기 시작했고, 그래서 씸의 핵심을 가지고 WebBeans라는 이름으로 표준화 작업을 진행했다. 재밌게도 그 이름은 파이널 드래프트에서 보면 Contexts and Dependency Injection for the Java EE platform라고 바뀌어 있다. 사실상 자바에서 최초로 표준화되는 DI 스펙으로 만들려는 시도였을까.

이에 대응해서 스프링의 로드 존슨과 구글 주스의 밥 리가 손을 잡고 보다 일반적인 DI스펙인 Dependency Injection for Java라는 이름의 JSR-330 스펙을 제출했다. 이건 DI컨테이너에 대한 스펙이 아니라, 단지 표준 애노테이션에 대한 스펙이었다.

그리고 어찌 저찌 하다가 이게 이 JSR-330을 JSR-299에 통합하게 된다는 얘기가 들려오기 시작했다.

http://www.javapattern.info/283

http://www.infoq.com/news/2009/08/dependency-injection-javaee6

인포큐에 올라온 글에 링크된 코멘트를 보면 각 진영의 대표자들이 어떤 생각을 하는지 잘 알 수 있다. 놀새님의 긍정적인 코멘트와 달리 사실 내부적으로는 그다지 달가워 하지 않는다는 느낌이다.

  • Gavin King: I think it would be a huge mistake to introduce a second set of annotations which are semantically identical to those in 299 and address the exactly the same problem
  • Bob Lee: While 299 may be fine for small scale EE applications and cute examples, its global configuration and lack of explicitness makes it unsuitable for the multi-million line applications like we have at Google. We can easily support 299-style configuration on top of Guice, but we can’t do everything we do with Guice using 299. We have no reason to switch. Personally, I think you’ve innovated far too much in 299 and don’t fully understand the implications on maintainability of users’ code.

JSR-299에 대해서 아예 투표를 포기해버린 스프링소스에 대해서 무책임하다는 등의 비난이 있기도 했는데, 그에 반해서 JSR-330에 대해서는 레드햇은 명시적으로 기권을 하면서 반대의사를 분명히 했다. 투표에 일단 반대를 하지 않은 이유는 긍정적인 다른 커뮤니티의 반응과 수고 때문이라고 두고보겠다고 하지만 아무튼 맘에 안든다는 분명한 의사표시를 한 것이다.

재밌는 것은 그 기권투표를 하면서 레드햇이 남긴 코멘트이다.

Red Hat is deeply skeptical of the value of this JSR, since it envisages the existence of a separate container that is not part of the SE or EE platforms, and whose semantics and programming model are sufficiently ill-defined that portability of applications between different containers would be impossible for all but the most trivial of applications. This is a break from the Java tradition of "write once, run anywhere".

레드햇은(아마 개빈킹?)상세한 표준이 있기 때문에 표준 JavaEE컨테이너의 구현서버에서 호환성있게 동작할 수 있게 만들 수 있는 WebBeans에 비해서 SE를 포함해서 범용적인 인터페이스의 규약만 가지고 있는 JSR-330은 스프링이나 주스 같은 비표준 컨테이너들이 필요하기 때문에 포터블하지 못하게 되고 결국 자바의 기본원칙인 WORA를 위반하는 꼴이 된다고 이야기 한다.

대충 여기까지가 그동안 관찰한 것들이고.

 

내 생각을 좀 말해보자면, 일단 나는 표준에 별 관심이 없다. 표준의 가치를 무시하는 것은 아니지만, 현실적으로 최신표준 들은 그다지 별 영향력도 명분도 효력도 없다. 단지 표준 구현을 해야 하는 WAS 벤더들이나 오픈소스로 떠서 인기를 끈 프레임워크 들이 표준화를 통해서 주도권을 잡고 명예도 얻고자 하려고 할 때 가지는 관심사일 뿐. 적어도 기본적인 JEE(서블릿?)와 JSE 플랫폼을 무시하지만 않는다면 최신 표준기술을 쫒아야 할 현실적인 이유는 없다.

기술적으로는 나는 밥 리의 의견에 일단 동의한다.

나는 씸을 좋아하고 잘 만들어진 프레임워크라고 생각한다. RoR 처럼 매우 자기주장이 강한만큼 스스로 모든 것을 다 결정해서 통합적으로 제공해주고 있고, 스프링을 쓸 때처럼 선택의 고민이 거의 없으므로 맘편하게 사용할 수 있다. RoR처럼 씸도 적절한 환경과 조건에 맞게 사용되어지면 될 것이라고 생각한다.

하지만 이미 몇년간 구현해서 사용되어진 독점기술이 표준으로 옷을 입는다고 해서 그것이 당장 서버 환경에 포터블하게 호환성이 있는 애플리케이션이 될 것이라고 기대하는 것은 우수운 일이라는 것은 왠만한 개발자들이라면 다 알것이다. JEE6표준이 마무리 되도 그것을 풀로 지원하는 WAS들은 빨라야 1-2년 후에나 나올 것이고, 그 사이 WebBeans의 RI인 씸은 WebBeans 스펙에서 역시 한참 더 벗어나 있을 것이다. 그때가서 씸의 최신 기능을 포기하고 단지 서버간의 호환성을 위해서 초기 WebBean 스펙을 따라서 개발하려고 하는 개발자가 있을까? 그나마 JPA스펙은 하이버네이트의 개빈 킹이 주도했지만, JDO와 TopLink라는 유사한 경쟁 ORM과의 충분한 공통점을 이끌어내서 만들어졌기 때문에 상대적으로 하이버네이트를 가진 JBoss에게만 유리한 것은 아니었다. 하지만 WebBeans는 JPA와는 상황이 완전히 다르다. 그런 점을 무시하고 표준이니 호환성이니 하는 명분을 들이미는 것은 우습다.

그런면에서 레드햇의 코멘트는 사실 낯간지럽다. 스스로 JSF와 EJB/JPA 등의 사용을 장려하며 표준기술의 옹호자인 것처럼 해온 씸이지만, 사실상 표준 기술의 단점을 가장 크게 부각시키고, 씸이라는 비표준 컨테이너에 종속된 기술로 몰아간 것도 역시 씸이다. 물론 나는 그걸 잘한 일이라고 본다. 그냥 표준기술(JSF-EJB3-JPA)을 연결해 쓰자고 했다면 씸이라는 것 자체가 존재할 이유도 없었을 테고. 표준기술만 쓰기에는 너무 한심했으니까.

물론 밥 리의 "WebBeans는 작은 규모의 애플리케이션이나 장난감 예제에나 적합할 만한 수준"이라는 것은 솔직하지만 좀 심한 비난인듯 하다. 하지만 JSR-330이 JSR-299를 포용할 수는 있지만, 그 반대는 안된다는 주장에는 동의한다. 사실 JSR-330은 DI가 원래 추구하려는 기본 아이디어인 컨테이너 비의존적인 POJO개발이 가능한 DI의 장점을 가장 잘 드러내는 것이라고 생각한다. 레드햇의 유치한 비난과 달리 JSR-330은 오히려 더 포터블 하다. 스프링에서 내가 만든 코드의 상당 부분, 특히 핵심 로직은 스프링 API에 의존하지도 않고 DI를 위한 애노테이션 정도만 사용된  POJO이니 이를 쉽게 EJB나 씸 등으로 포팅 가능하지만, 그 반대는 쉽지 않을 것이다. 이미 특정 기술에 대한 편애를 가지고 만들어진 기술과 범용적이고 비침투적이어야 한다는 강박속에서 만들어진 기술과의 차이점이라고 할 수 있을 것이다. 어느 것이 더 낫다는 면에서가 아니라 어느 것이 더 포용적인가에 대한 문제이다.

차라리 JSR-330이 먼저 정의되고, JSR-299가 JSR-330에 의존적인 스펙으로 간다면 가장 좋았을 것이라고 생각하지만, 표준화 작업에서는 이미 WebBeans가 워낙 많은 노력을 해온마당에 그러기는 적절치 않고, 아예 비슷한 DI 방법에 대해서 두가지 애노테이션이 존재하는 것도 우스운 꼴이 델테고 현실적인 해결책은 역시 두 스펙의 통합이 될 것 같다.

 

스프링은 convesational, stateful한 개발을 지원하지 못하는 것으로 오해하는 사람들도 많은데, 이미 스프링, 주스에도 다 있었던 Scope라는 개념은 얼마든지 영리한 방식의 유연한 stateful 개발을 지원한다. 씸조차 스프링 자체는 전혀 건드리지 않고도 그 확장포인트인 Scope 등을 이용해서 스프링 빈이 씸의 컨버세이션, 컨텍스트 관리를 지원하게 만드니까 말이다. http://docs.jboss.org/seam/1.2.0.GA/reference/en/html/spring.html

처음 얘기한대로 나는 표준이 어떻게 결정나든지 별 관심이 없다. 자바를 쓴다면야 스프링을 계속 쓰겠지만 필요하면(JSF를 쓴다면) 씸을 붙여서 사용할 수도 있을 것이고, 필요에 따라 씸만 쓸지도 모르겠다.

어쨌든 JSR-299(330)이 나오더라도 쉽게, 씸은 먼저 나서서 스프링과의 통합을 지원해야 하지만 스프링은 씸에 관심조차 안두는 이 상황은 쉽게 바뀌지 않을 것이다.

 

참 그리고 항상 말하는 거지만 스프링은 DI프레임워크가 아니다. 스프링을 DI프레임워크 취급하는 것은 자바를 인터페이스라고 하는 것과 마찬가지이다. 

Related posts:

  1. JSR-330 Dependency Injection for Java 최종 승인
  2. 마이크로 DI(dependency injection)
  3. EJB3의 Dependency Injection
  4. Dependency Injection의 Dependency란 무엇인가?
  5. DI의 본질 – 다이나믹 (타입) 언어는 Dependency Injection이 필요없는가?
  6. Code Organization & Cyclic Dependency Problem
  7. Spring 3.0 (7) Spring 3.0 Dependency Matrix
  8. Spring 3.0 (42) Spring Dependency Matrix 업데이트
  9. Spring 3.0 (53) Spring Dependency Matrix 업데이트

Facebook comments:

to “Dependency Injection 표준화?”

  1. 디피디나이는 뭐야? 뭘 거부하나?
    고열로 고생하다고 제목으로 알리는거야?
    열은 내렸엄?

  2. 영회/ 너 때문에 다시 오르고 있어

  3. 그대, 아픈거 맞습니까. 아픈 몸으로 이런 장타를…
    몸도 생각해야지요..

  4. 저도 금요일에 정리하고 일요일에 예약 포스팅으로 걸어 놨는데 그 사이 이미 더 깔끔히 정리해주셨군요 ㅎㅎ

  5. 찬욱/ 너가 정리한 것을 보니 더욱 299와 짬뽕이된 330의 모습이 잘 안 그려지는 구만.
    아마도 중복 애노테이션을 없앤다는 명분으로 스펙은 하나가 될지 몰라도 299가 330 위에 만들어지는 모습이 되지 않을까 싶은데. 299로 통합된다고 330의 SE까지 확장한 DI개념이 축소되지는 않을 것 같으니 말이지.
    아무리 봐도 WebBeans가 기존 DI기술들을 제끼고 독주하려다 발목잡힌 느낌인데.. 아님 말고.

  6. 저도 그런 기분이 강하게 드는걸요@@

  7. 과거의 EJB 때문에 개발자를 바보취급(?) 하는 너무 염격한 기술은
    별로 안 좋아하게 됐습니다.
    표준으로 한번 정하면 바꾸기도 힘든데,
    저런거까지 표준으로 만들어야 하나? 하는 생각도 들구요.
    Web Application 사용자들이 직접 보게 되는 화면에 대한
    표준인 W3C standards는 사용자와 개발자를 위해서
    지키는게 좋다는 생각을 가지고 있습니다만,

    Web app개발에 사용하는 기술이야
    기술 사용자 (Java를 사용하는 개발자) 들이 알아서
    고를수 있게 놔둬도 충분할꺼 같은데,
    우리가 바보도 아니고…ㅡ_ㅡ;;;

    JBoss Seam에 대해 자세히 알아보지 않아서
    Seam에 대한 섣부른 판단은 위험하고…
    제가 Spring을 쓰는 이유는 사용자가 자유롭게 기술을
    고를수 있기 때문이기도 하고,
    가만보면 어차피 Spring 없었어도 간편하게 만들어 썼을텐데
    이미 만들어서 테스트까지 해놓은거
    안 쓸 이유도 없기 때문이기도 하죠.

    Spring 쓰기전에 간단한 수준의 framework를 만들어 썼는데
    나중에 Spring을 알게 되서 보니 Spring의 DI와 SpringMVC랑
    비슷하더라구요. 제가 만든 초보 단계 수준의 것에 비해
    이미 잘 만들어서 테스트 까지 해놓은걸 안 쓸 이유가 없었죠.

    암튼 정치 싸움 같은 저 표준 전쟁이 좀 맘에 안 드네요.
    결국 2년씩 싸우다가 JPA처럼
    “어! 쓸만한데!!!
    (알고 보니…)
    아니! 이런 중요한게 없어? 없는게 뭐 이렇게 많아?”
    처럼 될것 같아서…

  8. 그나저나 VMware에서 SpringSource 인수 했다는 뉴스보고 깜짝 놀랐습니다.
    언제 이런 얘기가 오갔는지 모르겠네요. 처음 듣는거 같은데,
    VMware는 최근에 Google로부터 (예전에 MS에 있었던) 커널기술자도
    스카웃하고… 이 회사 요즘 아주 잘 나가나 봅니다. :)

  9. Kevin/ 그러게요.
    VMWare는 아주 잘 나가죠.

  10. Affinity may be the Coptis trifolia groenlandica this scarves the particular bears skin color community.
    nike tn http://basketniketnpascherfr.blogspot.com/

  11. When you need a fantastic sales of your own importance, number relations.
    Nike Air Max 180 http://www.fr-marque.fr/nike-air-max.html/

  12. Usually do not speak of your ultimate pleasure to at least one not as fortuitous besides your lifestyle.
    ugg boots uk http://www.uggbootsuksalecheaps.co.uk/

  13. Anywhere int he planet could possibly be body, but nevertheless , to a single customer could possibly be the.
    louis vuitton online shop http://www.louisvuittontaschen2013.com/

  14. True love is going to be stimulated main concern for any everything while the expansion of that which you passion.

  15. Want to improve your google rank? http://tiny.cc/orh6tw

  16. Want to improve your google rank? http://goo.gl/YzNKa

  17. Want to jump your google rank? http://tiny.cc/iioeuw

  18. Want to make money with your blog? http://tiny.cc/iioeuw

  19. Investigate THIS Site

  20. what are mbt shoes Dependency Injection 표준화? » Toby’s Epril

  21. The next time I read a blog, I hope that it doesnt disappoint me as much as this one. I imply, I know it was my option to read, but I actually thought youd have something fascinating to say. All I hear is a bunch of whining about one thing that you would fix in case you werent too busy looking for attention.

Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha