[EP]제11회 한국 스프링 사용자 모임 세미나 후기 #2..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

SpringOne 2010 참관기 - 정상혁
얼마전에 열렸던 Spring과 Grooby를 주제로 하는 컨퍼런스인 SpringOne2GX 2010에 참석하셨던 내용을 생생하게 공유해 주셨습니다.

Keynote
로드 존슨이 키노트를 진행하였는데 J2EE Design and Development를 쓸 당시가 31세 정도였다고 하니 정말 대단하는 생각을 했습니다. 로드 존슨은 현재는 코딩은 안하고 있고 스프링소스의 전략과 개념적인 부분에 대해서만 집중하고 있는 것 같았습니다. 로드 존슨은 Portability, Pruductivity, Innovation에 대해서 얘기했는데 Portability는 이번 컨퍼런스에서 가장 중요하게 다뤄진 개념으로 여러 실행환경에서도 동작하게 하는 것을 목표로 하고 있으며 Productivity는 STS와 SpringRoo에 대한 부분이고 Innovation은 NoSQL에 대한 지원과 메시지큐등의 준비에 대한 부분이었습니다.

Spring 3.1
기존의 일관성을 그대로 유지하면서 최근 경향을 반영하였습니다. Cache Abstraction을 위해서 @Cacheable가 추가되었으며 <cache:annotation-driven />와 같이 기존의 Transaction과 유사한 시맨틱을 가지고 있습니다. 디폴트는 ConcurrentHashMap이며 모든 시나리오를 커버하려는 것은 아니고 80%정도의 시나리오를 커버하는 것이 목표입니다. 개발환경등을 분리할때 기존처럼 폴더를 나누거나 하는 등의 어려움을 없앨 수 있도록 Bean profile로 프로파일 개념을 도입하였습니다. Custom namespace에서 Java Config 확장을 지원하여 하위프로젝트들에서 설정의 간편화를 기대할 수 있게 되었습니다.

과거에는 XML을 사용하는 것이 컴파일도 안해도 되서 더 좋다는 추세였는데 이제는 Maven등으로 컴파일과 관리도 편해졌기 때문에 애노테이션등을 이용해서 다시 자바로 들어가고 있는 추세입니다.  3.1 GA는 2011년 3월경 3.2는 2011년말로 발표되었지만 여태 그랬듯이 출시일정은 그다지 믿지 않고 있으며 질의시간에서도 자신들은 일정보다는 완성도를 더 중시하고 있다고 대답하였답니다.

Spring과 Java EE6
인터넷에서 많은 논쟁이 있었던 내용으로 "시너지냐 경쟁이냐"라는 제목으로 유겐휠러가 발표를 했습니다. 시너지냐 경쟁이냐는 부분에서 유겐휠러는 시너지 관계라고 답했으며 JavaEE6 스펙을 잘 사용하는 방법이 스프링이고 스펙을 쓸수 없는 곳에서도 적용할 수 있도록 하고 있으며 스프링은 여전히 많은 선택권을 제공하고 있습니다.
왜 REST표준을 사용하지 않고 따로 쓰고 있냐는 비난도 많이 있었는데 스프링소스는 기존의 스프링 유저들의 경험을 중요하게 생각하고 있기 때문에 억지로 표준을 끼워맞추기 보다는 여러가지 선택권을 주는 쪽으로 진행하고 있습니다. 스프링은 거의 대부분의 경우에 젠틀하고 여유로운 모습으로 항상 다양한 선택권을 주는 쪽이었지만 유일하게 양보하지 않는다고 느껴지는 부분은 DI에 대한 부분이었습니다. DI의 표준은 JSR299이지만 유겐휠러도 이 표준에 대해서는 별로 좋지 않다는 식으로 회의감을 표명했습니다.

분산캐쉬
메모리를 Heap에 두지 않고 외부에 두어 GC가 필요없도록 하는 BigMemory라는 솔루션을 Teracotta가 내놓았으며 이것은 모든 경우에 적용되는 것은 아니고 캐쉬를 많이 쓸 경우 GC시간이 비약적으로 늘어나서 문제가 되는 경우에 대한 대안입니다. Gemfire는 스프링소스가 인수한 솔루션으로 유명한 곳의 레퍼런스들을 가지고 있으며 약간 Eh캐쉬랑 경쟁관계에 있지만 스프링은 이 2가지 모두 지원하고 있습니다.

NoSQL
Spring data 프로젝트를 통해서 NoSQL을 지원하며 Hadoop도 지원예정에 있습니다. 스프링으로 NoSQL을 사용하는 방법으로는 GORM으로 Redis나 Gemfire를 사용할수 있으면 SpringRoo에서도 Neo4j 애드온으로 지원하면 개발자가 선택적으로 로우레벨 API도 사용가능하도록 제공하고 있습니다.

RabbitMQ
RabbitMQ는 스프링 소스가 사들인 솔루션으로 Protocol기반의 메시징 큐이며 Active MQ같은 API기반의 JMS 메시지 표준이 있지만 다른 환경에 대한 지원을 위한 것입니다.

SpringRoo
SpringRoo에는 GWT, GAE, DB 리서브 엔지니어링이 추가되었으며 이번 컨퍼런스에서 편애라는 생각이 들 정도로 SpringRoo를 띄워주려는 분위기가 느껴졌는데 SpringRoo를 Grails급으로 격상시키려는 의도인듯 합니다. SpringRoo는 샘플코드의 전파경로로도 의미가 있다고 생각합니다.

Demo
SpringRoo에 대한 Demo는 지난 공감세미나에서 보여주셨던 MVC기반의 데모를 GWT기반으로 간단하게 시연해서 보여주셨습니다. 물론 이렇게 화면까지 만들어졌다고 다 끝난것은 아니고 여기에 스프링과 GWT와 ORM을 이해할 수 있어야 하지만 샘플코드로 공부하기에도 좋습니다.
이번 컨퍼런스에서 나온 Spring Insight 데모를 이어서 보여주었는데 Spring Insight는 모니터링 툴로써 구글과 협력하여 Speed Tracer 브라우저 플러그인으로 웹사이트의 동작을 녹화할수 있고 이에 대한 성능모니터링을 볼 수 있습니다. 성능 및 네트워크에 대한 모니터링도 제공하고 있으며 네트워크 모니터링에 대한 부분을 보면 JDBC사용에 대한 부분도 Trace가 되며 이를 클릭하면 Spring Insight와 연결되어 클라이언트와 서버의 모니터링을 한꺼번에 할 수 있습니다. 현재는 개발환경에서 무료로 쓸 수 있는데 성능저하 없이 Production모드에 적용하려는 시도가 있으며 현재 스프링에서도 JRebel과 비슷한 자동로딩을 지원할 수 있도록 개발하고 있습니다.

분석 - 스프링을 둘러싼 전략들
지난 10년을 돌아보면 현재의 스프링은 공존(co-located) 아키텍쳐로 모든 티어가 함께 있지만 과거 EJB시절에는 웹티어와 비즈니스 티어의 물리적인 분리를 하고 이것이 더 확장성이 있다는 주장이었습니다. 분산의 제1법칙은 분산하지 말라입니다. 로드 존슨이 이 분산아키텍쳐를 실제로 써보니 별로라는 인상을 받았고 미들티어가 따로 존재하지 않아도 수평적인 확장에 아무런 문제가 없다는 주장을 하였습니다.
과거 이렇게 분산했던 이유중에 하나는 이렇게 해야 미들웨어를 더 많이 팔수 있었기 때문이고 벤더들을 위한 구조이지 개발자와 사용자가 필요한 구조는 아니었습니다. 농담(?)으로 톰캣을 사용하지 않는 이유는 CTO가 벤더들과 골프를 치기 때문이라는 얘기가 있을 정도였습니다. 최근 EJB 3.1스펙도 스프링과 동일해졌습니다.

스프링의 프로그래밍 모델은 이미 보편적인 프로그래밍 모델이 된 Dependency Injection과 핵심로직에 침범적이지 않은 인프라성 코드인 AOP, 소비쪽에서는 변경할 필요가 없는 Portable Service Abstraction입니다. 이제는 DI는 스프링만의 것이 아니고 Eclipse 4.0이나 Android에서도 쓰이고 있으며 나중에 스프링을 안쓰게 되는 때가 오더라도 DI는 스프링이 프로그래밍에 남긴 것이 되지 않을까 생각합니다.

오픈프레임웍만으로는 돈이 되지 않기 때문에 비즈니스 모델에 대한 고민을 하게 되었습니다. 회사도 설립하고 투자도 받아서 수익을 발생시켜야 하는데 프레임웍만으로는 쉽지 않았기 때문에 Tomcat주도 업체인 Covalent등을 인수하고 2009년 VMWare에 인수되었습니다.

저장소는 분산되고 서비스는 통합되는 등 기술환경이 많이 변화되어 메시지큐도 필요해지고 모니터링 도구들도 더 발전한 것들이 필요하게 되었습니다.

실행환경에 Portability를 제공하는 레이어를 PaaS 클라우드를 준비합니다. OS수준의 가상화 환경에서 이미 JVM이 Portability를 가지고 있는데 프레임웍차원에서의 Portability가 어떤 의미가 있는가에 대해서 의문이 있을 수 있는데 그외 환경에서 필요하다고 주장하고 있으며 이는 서블릿스펙만 지원하고 있는 GAE이 가장 반길것으로 생각하고 있습니다.

논란이 있긴 하지만 점점 클라우드에 대한 요구는 늘어나고 있습니다. 클라우드 서비스에 올려서 Lock-in이 되면 업체입장에서는 리스크가 있지만 여러 클라우드 업체가 생겨나 옮겨다닐수 있게 되면 업체입장에서는 리스크가 줄어들고 스프링이 이 역활을 하려고 하고 있습니다. 이렇게 기능적인 부분을 스프링이 제공하면 PaaS 제공자는 안정성, 편의성, 가격정책으로 경쟁력을 가질 수 있습니다.

SpringOne2GX 2010에 대한 더 자세한 내용은 정상혁님이 블로그를 통해서 계속 올려주고 계십니다. 정상혁님의 발표자료는 KSUG블로그에 올라와 있습니다.

정상혁님의 발표는 저번에 SpringRoo에 대한 발표이후 두번째인데 약간 산만한 느낌을 주시면서(내용이 산만하다는 건 아닙니다.) 딱히 유머를 던지지 않아도 왠지 발표가 유쾌하게 느껴지는 매력이 있는것 같습니다. 스프링의 전략이나 각종 기술에 대한 얘기등 자칫 지루해 지기 쉬운 주제임에도 불구하고 중간중간 정상혁님의 경험이나 생각을 잘 섞어서 집중해서 들을수 있었던 것 같습니다. 값비싼 세미나의 내용을 공짜로 생생하게 전해듣게 되어 스프링 소스가 생각하고 있는 방향에 대해서 꼽씹어 볼 수 있는 시간이었던 것 같습니다.(전 특히 이런 총체적인 트랜드를 좀 이해하려고 하는 편이라...) 왠지 듣고나면 기분이 좋아지는 발표였네요.

Spring Framework 3.0을 이용한 RESTful 웹 서비스 구현 - 박찬욱
Spring 3.0이 나온지 어느새 1년 가까이 되었고 3.0에서의 큰 변화중 하나가 REST에 대한 지원이었습니다. REST는 JAXRS라는 표준이 있는데 스프링은 그 이전에 이미 애노테이션을 적용하고 있었기 때문에 JAXRS를 도입할 것인가 그대로 진행할 것인가에 대한 논의가 있었지만 현재는 스프링의 기존 애노테이션을 그대로 재사용하고 있습니다.

URL Template Variable Mapping을 지원하여 @RequestMapping에 템플릿 변수를 매핑할 수 있게 되었습니다. 뷰에도 변화가 있었는데 ContentNegotiatingViewResolver가 Request의 정보를 가지고 응답을 보낼 뷰를 결정하게 됩니다. RestTemplate으로 클라이언트사이드의 지원이 추가되어 JDBCTemplate처럼 사용할 수 있으면 테스트코드를 작성할 때도 유용합니다.

기존의 MVC코드에서는 일반적으로 상당히 긴 URL을 가지는 경우가 많습니다. 리소스기반으로 REST로 변경하면 URL을 줄일수 있고 view.jsp같은 액션은 HTTP 메서드로 구분하게 됩니다. ContentNegotiatingViewResolver가 뷰를 결정하는 방법은 .json이나 .xml같은 URL확장자를 통해서 하거나 ?RESPONSE_TYPE=JSON처럼 파라미터를 이용하거나 [application/json]같은 미디어타입(MediaType)을 이용해서 결정하게 됩니다.

REST를 통해서 JSON이나 XML로 데이터를 클라이언트에 내려주게 되고 이렇게 할 경우 서버측에 View는 존재하지 않게 됩니다. 때문에 데이터를 가져오기 위해서 jQuery등으로 Ajax로 데이터를 가져오게 되면 @RequestBody를 통해서 클라이언트가 body로 보낸 데이터를 받을 수 있습니다.

마지막으로는 REST개발시에 어려운 부분에 대해서 나누어 주셨는데 URL Design의 어려움, 요청단위 수립의 어려움등이 있었으며 Server Stateless, CLient Stateful 모델을 구현해야 했으며 아직 개발패턴이 정립되지 않았습니다. 반면 보안에 대한 부분으로 Resource에 대한 인증 및 접근 권한관리는 현재 나와있는 OAuth나 Digest같은 기술로도 이미 충분하다고 생각합니다.

유독 마지막 세션에 대한 정리가 좀 적은 것은 제가 집중해서 듣지 못했기 때문인데 이는 세션발표준에 나오던 설명의 흐름중 일부가 오해의 여지가 있다는 생각이 들어서 그 생각에 휩싸이면서 집중해서 듣지 못했습니다.

제가 생각에 휩싸인 부분은 설명 중에 나왔던 "REST는 뷰가 없이 JSON/XML로 프론트에 데이터를 내려주는 형태라서 프론트앤드에서 Ajax로 데이터를 가져와야 한다" 라는 부분 때문이었는데요 REST에는 Response의 형태는 따로 강제되지 않고 있기 때문에 REST에 대한 오해의 여지가 있다고 생각이 들었고 위 시나리오가 발표의 주흐름이었기 때문에 맞는가 아닌가하는 생각에 빠져서 그 뒤부터는 많이 집중을 못했었습니다.

하지만 이 부분은 KSUG 메일링을 통해서 세미나 후에 약간의 의견을 주고 받았었는데 한정된 발표시간에서 박찬욱님이 REST를 이용했을 때 View를 페이지마다 두지 않고 처리하는 하나의 예시를 설명하는 부분으로 강조되었던 부분이지 REST라는 기술에서 응답의 형태를 강제한다는 한정을 지려는 의도는 없으셨음을 확인했습니다.  알고 보니 이부분에 집착한 건 저뿐이고 대부분은 융통성있게 해석해서 받아들이셨더군요. ㅠㅠ

이 부분에 대한 논의에 구체적인 내용은 KSUG 그룹스에 있으므로 참고하시기 바랍니다.

뒷부분 세미나에 많이 집중하지 못한 것은 약간 아쉽지만 그래도 메일링을 통한 논의를 통해서 여러가지를 다시 생각해 보게 되었던 것 같습니다.

Epilogue

개인적으로 KSUG와 약간 연관이 있기에(더 정확히는 KSUG 운영진 분들과..) 너무나 당연한듯 참석한 세미나였지만 정말 얻은게 많은 알찬 세미나였다고 생각합니다.(이래서 10만원씩 하는 쓸데없는 컨퍼런스 보다는 이런 커뮤니티 세미나를 훨씬 좋아하게 되는...) 업무를 자바로 하고 있지는 않지만 그래도 봄싹에서 이런저런 활동하면 자바를 놓지는 않고 있었는데 올해 이런저런 많은 것들에 손을 대면서 자바에 상당히 소홀히 하게 되었었습니다. 알고는 있었지만 주변에 자바하는 사람들이 너무 많다보니 마치 저도 그 일원인양 크게 의식하지도 못하고 있었던 듯 한데 최근에 자바를 제가 얼마나 모르고 있는지에 대해서 크게 느끼고 있는 가운데 이번 KSUG세미나 많은 생각과 함께 동기부여에 대한 어느정도 기폭제가 되는 듯한 기분입니다. 듣고 넘어가는 게 아닌 스프링을 좀 더 적극적으로 배워봐야겠습니다. ㅎ