토비의 스프링 3이 나오기까지의 이야기를 담은 토비 스토리 네 번째 이야기.

다시 2007년. 스프링 책을 어떤 식으로 쓸 것인지 질문을 받으면 항상 이런 얘기를 했다. 기존 스프링 책들은 1장에서 스프링 역사로부터 시작해서 J2EE과 스프링의 관계 등등의 장황한 스프링 소개를 한 뒤에, 바로 2장에서 IoC를 몽땅 다루고, 3장에서 AOP를, 4장에서 JDBC를 다루는 식으로 접근한다. 내가 느낀 문제는 스프링을 처음 접하는 사람에게 스프링의 프로그래밍 모델이 뭔지 감을 잡기도 전에 2장에서 스프링의 모든 DI 고급기법까지 다 설명하는 것이다. DI가 뭔지 아직 감을 잡지도 못한 사람한테 나도 아직 잘 사용하지 못하는 빈의 라이프사이클 메소드니 빈/빈팩토리 포스트프로세서니 하는 것까지 다 설명을 해버리면 여기서 벌써 기가 죽는다. 머리 속에선 스프링이란 뭔가 복잡한 설정방법을 알아야 하는 것이라고 단정짓게 된다. 그리고 나서 바로 AOP로 넘어간다. AOP는 더 가관이다. AOP를 다루는 장의 처음 몇 페이지는 온통 생소한 용어소개 뿐이다.  AOP, 애스팩트, 조인포인트, 포인트컷, 위빙, 어드바이스, 인트로덕션, 횡단관심이 어쩌고 저쩌고. 아무리 깔끔한 정의를 적어놨다고 한들 용어가 머리속에 제대로 들어올리가 없다. AOP를 이용한 로깅이니 보안이니 하는 예제까지 다루고 포인트컷 표현식 따위나 포인트컷 확장 빈 등록, 자동 빈 생성기 이런 것들이 마구 소개되는 것을 보면 일단 AOP는 제껴두자고 마음을 먹게 된다. SpringMVC는 어떤가? 갑자기 7가지 디스패처서블릿의 전략이 쭉 소개된다. 그리고 공포의 SimpleFormController가 떡 하니 등장하면 정말 기가 팍 죽는다. 어려운 SpringMVC를 쓰느니 익숙한 스트럿츠1을 사용하든지, 아니면 일단 처음 접근(만)은 간단한 웹워크, 스트럿츠2가 더 나아보일 것이다.

모 교육센터의 강사로 활동했던 친한 형 한명은 스프링을 제대로 공부해보겠다고 여러 책을 붙잡고 밤낮을 끙끙댔음에도 도무지 뭐가 뭔지 모르겠다는 푸념을 하기도 했다. 특히 AOP는 설명을 아무리 읽고 또 읽어도 이해가 되지 않는, 안드로메다 외계 테크롤로지로 보인다는 것이다. 그냥 배껴서 쓸 수 있는 예제 하나 없을까 찾기에 바빴다. 아마 적지 않은 개발자들이 그런 비슷한 과정을 밟지 않을까 하는 생각이 들었다. 스프링이 유행이라니까 다음 프로젝트부터 적용하라는 위로부터의 일방적인 지시가 떨어지고, 급한 마음에 시중에 나와있는 책들을 구해서 공부를 해보는데 이게 난생 처음 들어보는 용어와 복잡해보이는 XML이 난무하고, 책의 예제를 따라해봐도 대충 어떻게 배껴서 비슷하게 만들면 되겠다는 감은 오지만 도대체 스프링이 뭔지, 뭐하러 쓰는지 마음에 다가오는 것이 없고, 이걸 도대체 뭐하러 써야 하나하는 불만이 들기 쉽상일 것이다. 내가 직접 들은 그런 불만만 해도 적지 않다. 사실 그런 유행에 휩쓸려 스프링을 급하게 사용하기 시작하다가 스프링에 안좋은 인상만 남게 되는 일도 흔했다. 그래서 한동안은 스프링을 쓰지 말라고 말려야 겠다는 생각이 들기도 했다. 그래서 블로그에 "스프링을 쓰기 위해서 스프링을 쓰지 말자"라는 얘기를 적기도 했다. 단지 스프링이 유행이니까 사용해야겠다는 생각으로 스프링을 사용하지는 말라는 얘기다.

스프링은 쉽지 않다. 왜냐하면 스프링은 쉽지 않은 자바 엔터프라이즈 애플리케이션의 개발을 다루고 있기 때문이다. 또 스프링은 한 가지 단순한 접근방법만 파는 대신 수 많은 옵션과 다른 프레임워크와의 조합을 적극적으로 제공하기 때문이기도 하다. 자유도가 매우 높은 RPG 게임과 비슷하다고나 할까. 대신 스프링을 관통하는 기본 원칙과 프로그래밍 모델, 디자인 패턴은 매우 명확하고 분명하다. 문제는 스프링 책이나 교육이라는 것이 지면과 시간의 한계 때문에 레퍼런스식 설명에 그치거나 아니면 간단한 예제 하나에  매몰되기 쉽상이라는 것이다. 특히 예제 중심의 접근은 초반에는 쉬워보이지만, 자칫하면 특정 방식의 스프링 사용방법이 전부이거나 가장 좋은 것이라는 잘못된 인식을 줄 수 있고, 예제 코드를 기계적으로 복사해서 전혀 컨텍스트가 다른 곳에서 사용하는 일이 일어날 수도 있다. 스프링이 지지하는 탄탄하고 일관된 프로그래밍 모델 + 다양한 기술의 선택과 조합 대신 개념 없는 대충대충 프로그래밍 모델 + 특정 기술과 개발 패턴의 기계적인 적용만 남게 되는 문제가 일어날 수 있다는 뜻이다.

물론 현명한 개발자들은 그런 자료와 서적, 교육 등을 통해서 얻은 지식을 기존 경험과 잘 결합시켜서 스프링의 본질이 무엇인지 깨닫고 지혜롭게 응용할 줄 알 것이다. 하지만 적지 않은 초보자들은 그런 오해를 하기 쉽다.

그래서 스프링 책을 쓰기가 막막했다. 어쨌든 스프링의 기술을 다뤄야 하니, IoC, AOP, JDBC, MVC 등의 내용을 하나씩 설명할 수 밖에 없을테고, 동시에 스프링을 통해서 만들어지는 엔터프라이즈 애플리케이션의 전체 그림, 그리고 실제 코드를 예제로 보여주지 않을 수도 없는 노릇이니 내가 우려하던 그런 문제들을 쉽게 피할 방법은 없다고 생각이 됐다. 그래도 스프링 설명을 너무 관념적으로 가져가거나 현실과 동떨어진 설명을 택하는 것은 피해야겠다고 생각했다. 예를 들어 DI를 설명하면서, 절대로 실전에서는 경험해본 적이 없을 것이 분명한 도메인 오브젝트 내의 DI를 들어 설명하는 것 따위는 피해야 할 것이라고 생각했다. 실전에서 자주 접하는 코드이면서, 그래도 스프링의 특징을 잘 드러낼 수 있는 POJO에 로직이 잘 드러나있는 그런 코드가 뭐가 없을까 하는 고민을 계속 했다.

그래서 한 동안은 쌈박한 예제 하나만 먼저 만들어보면 책을 쓰는 것은 어렵지 않겠다고 생각했다. 프로그래밍 서적에서 자주 사용되는 쇼핑몰이나 블로그 따위는 사실 스프링으로 만들만한 애플리케이션도 아니고, 스프링의 POJO 중심의 개발이 주는 장점을 보여줄만한 예제로서 적합하지도 않았다. 그래서 실제 SI현장의 도메인에서 예제를 찾아보려고 했다. 그렇다고 특정 도메인의 예제를 사용하면 도메인을 이해하지 못하는 독자들에게 이중의 부담이 될 수 있으니 누구나 쉽게 이해하고 알만한 것이 뭐가 없을까 고민했다. 나는 스프링으로 제조업체의 ERP 전체를 개발해본 경험이 있으니 제조업체의 다양한 도메인에 스프링을 어떻게 적용할지에 대한 충분한 이해는 있었다. 그 중 쉬운 것을 찾자면 재고 관리 시스템에 괜찮다는 생각이 들었다. 다양한 재고 관리 기법을 DI를 이용해서 교체해서 로직을 적용하는 것도 구상해봤다. 하지만 깔끔하게 책의 예제로 쓸만한 도메인 로직으로 축소해 내기가 쉽지는 않았다. 그래서 주변의 SI 전문가-컨설턴트에게 예제에 사용할만한 도메인 모델을 좀 요청해봤다.

여러명의 SI업체나 금융계에서 활동하는 컨설턴트에게 요청을 해봤지만 다들 대답만 시원하게 했을뿐 건네주는 것이 없었다. 실제 도메인의 모델을 다 주자니 복잡하기도 하고, 보안의 문제도 있고 그렇다고 책의 예제로 할만큼 단순화 하자니 귀찮고, 그래서 대답만 하고 다들 나몰라라. 대표적으로, 개발자가 아닌 CBD와 모델링 컨설턴트 출신의 영회는 자기가 교육할 때마다 쓰던 모델이 있으니 걱정말라고 큰소리만 뻥뻥 치고는 끝까지 모델 그림 한장 제공해주지 않았다.

그렇게 시간이 지나면서 쌈박한 예제 하나만 있으면, 이를 만들어가는 과정을 담아서 책을 쓰면 되겠다는 환상이 서서히 깨지기 시작했다. 예제에 사용할 도메인 모델과 로직은 얼마든지 내 스스로 만들어도 그만이라고 생각을 했지만, 문제는 특정 예제 하나를 중심으로 스프링을 설명하는 것이 얼마나 위험한지에 대한 염려가 커졌기 때문이다.

2007년 봄에 벨기에에서 열린 스프링원 유럽에 참석했을 때 스프링 2.1(당시엔 2.5가 아니고 2.1이 계획이었다)에 포함된 애노테이션을 이용한 DI 방식이 나온다는 것을 처음 알게됐다. 그리고 얼마지나서 2.1이 2.5로 버전이 바뀌어서 출시되면서 새롭게 @MVC 웹 기술이 포함되었다는 것도 보게됐다. 그 외에도 제법 다양한 방식으로 스프링의 기술의 폭이 넓어졌다. 스프링 애플리케이션을 만들 때 선택할 수 있는 옵션의 종류가 많아진 것이다. 그리고 그해 11월 샌프란시스코에서 열린 QCon에 참석했을 때 로드 존슨의 스프링 2.5 세션에 들어갔는데, 로드 존슨이 2.5의 새로운 기능을 소개하기에 앞서서 ‘스프링은 선택이다(Spring is about choice)’라느 유명한 말을 던지면서 스프링을 사용할 때 적절한 기술을 선택하고 조합하는 것이 얼마나 중요한지 강조하는 것을 들었다. 1.x에서는 엔터프라이즈 개발에 꼭 필요한 필수 기술을 추가하는 것에 집중했다면, 2.x에 들어와서는 다양한 기술과 설정에 대한 접근방법을 제공해서 개발자 자신의 선택의 폭을 넓히는 데 주력했다고 보여졌다. 그런 마당에 특정 접근방법 한 두가지밖에 적용할 수 없는 예제 하나로 책을 써버리면 적지 않은 사람들이 그게 스프링을 사용하는 유일한 내지는 최고의 방법이라고 오해하기 쉽상일 것이라는 걱정이 들었다. 그래서 그 즈음에 엔터프라이즈 애플리케이션 예제 하나를 완성해나가는 과정을 담아서 책을 쓰겠다는 생각을 포기했다.

또, 다시 고민 시작. 그러는 중에 정희용 편집장을 통한 측면 공격으로 상당한 내상을 입은데다, 쏟아져 나오기 시작하는 스프링 2.5책을 보면서 책을 빨리 내야 한다는 부담이 크게 가중되고 있었다.

그런데 사실 그때 가장 큰 고민은 앞으로 어디에서 살아야할 것인가 였다. 평화는 태어났고, 일단 처가와 본가를 오가며 생활은 할 수 었지만, 어디엔가 정착이 필요했다. 여러 가지 후보가 있었다. 일단 한국에서 계속 지낸다면 쉽게 일은 할 수 있을 듯 싶었다. 당시에 많은 기업에서 스프링 컨설팅이나 프레임워크 개발요청이 끊이지 않았다. 일은 내가 맘에 드는 것을 골라서 얼마든지 할 수 있는 상황이었다. 재외동포비자를 받았으니 장기체류를 하면서 내국인과 동일한 혜택을 받고 일하는 데도 아무런 문제가 없었다. 한편으로는 미국으로 가고 싶은 마음도 들었다. 미국에서도 끊임없이 호출이 있었다. 내가 말하기도 전에 먼저 이민변호사와 협의해서 이민에 필요한 수속과정을 알아보고 있던 기업도 있었다. 스폰서가 되줄테니 오기만 하라는 기업이 여럿 있었으니 원한다면 얼마든지 미국으로 가서 생활하고 장기적으로 미국으로 영구이주하는 것도 고려할 수 있는 상황이었다. 동시에 중국으로 가고 싶은 마음도 들었다. 2007년에 처음으로 방문했던 중국은 상당히 매력적이었다. 중국에 비즈니스를 시작하고 한국과 호주에 연계해서 일을 할 수 있겠다는 생각도 들었다. 투자를 하겠다는 사람도 나왔고 비즈니스 리서치를 위해서 여러 번 방문도 했고, 현지 코디네이터를 해주실 전문가도 알아두었다. 무엇보다도 한국과 가깝다는 것이 매력적이었다. 이렇게 한국, 미국, 중국을 놓고 저울질 하고 있었지만 한편으로는 호주 생각이 간절했다.

나의 20대 후반과 30대 초반을 보낸 곳. 안정적인 한국의 직장 생활을 포기하고 바닥으로 내려가 모든 것을 다 도전하면서 생활해왔던 시간들, 그리고 내가 좋아하는 깨끗하고 아름다운 자연과 친절한 사람들, 여유있는 삶 등등. 나에게는 제2의 고향과도 같은 곳이고 마음의 안정을 누릴 수 있는 곳이기도 하다. 특히 평화가 태어나고는 복잡한 서울이 싫어졌다. 뭔가 새로운 도전을 하면서 다른 곳으로 갈 수도 있었지만 아마도 그런 삶을 살다보면 평화와 같이 시간을 많이 보내기 힘들 것이라는 생각이 들었다. 돈이나 성공, 직업과 비즈니스의 안정보다는 가족과 많은 시간을 보낼 수 있는 평화로운 삶을 선택하고 싶다는 생각이 들었다. 한국에서 생활하는 동안 아침 6시에 집을 나서서 밤 11시 반이 되야 돌아오는 생활에 익숙해있었다. 평화는 자는 모습 밖에 보지 못했다. 주말에도 세미나나 각종 모임에 나가느라 많은 시간을 보낼 수 없었다. 같이 다닐만한 곳도 많지 않았다.

그래서 많은 고민 끝에 다시 호주로 돌아가기로 마음을 먹었다. 그와 동시에 본격적으로 책을 쓰는데 시간을 쓸 수 있겠다는 기대가 들었다.

그러던 어느날 기선이와 함께 분당의 KT IDC에 서버 작업 때문에 방문할 일이 있었다. 분당으로 가면서 기선이랑 이런 저런 얘기를 하는 도중에 갑자기 애자일 자바(Agile Java)라는 책이 떠올랐다. 애자일 자바는 테스트 코드를 이용해서 자바의 기능을 설명하는 독특한 방식으로 주목을 끌었던 자바 입문서이다. 영회가 만들어서 한 동안 활발한 활동을 펼치다 지금은 사라진 애자일 자바 네트워크(AJN)는 바로 이 책을 이용해서 스터디를 하는 모임으로 출발한 것이다. 아무튼 그 책의 독특한 설명방법이 떠오르면서, 스프링도 그렇게 설명할 수 있지 않을까 하는 생각이 들었다. 스프링과 테스트는 뗄 수 없는 관계다. 스프링이 POJO 프레임워크라고 본다면 POJO 프레임워크로서 스프링의 가치는 절반은 기술과 환경에 독립된 코드라는 것이 둘 수 있고 다른 절반은 POJO가 가지는 테스트 편의성에 둘 수 있을만큼 테스트는 스프링에서 아주 중요한 의미를 가진다. 당연히 스프링 책에서 테스트에 대한 내용을 충분히 넣고, 강조할 생각은 가지고 있었지만 아예 테스트를 이용해서 스프링의 기술을 설명할 생각은 미처 못하고 있었다. 그런데 갑자기 애자일 자바가 떠오르면서 내 책도 그렇게 가야겠다는 생각이 들었다. 책 이름은 애자일 자바를 배껴서 애자일 스프링!

일단 잠정적으로 책 이름은 애자일 스프링으로 정했고, 학습 테스트 코드를 활용해서 스프링의 다양한 기능을 보여주고 설명하는 방식으로 내용을 작성해야겠다는 생각이 들었다. 그러면 특정 방식에 제한되는 예제에 매몰되지 않고 스프링의 다양한 접근방법을 보여줄 수 있겠다는 생각이 들었다.

이렇게 해서 2007년이 지나가고 드디어 스프링 책을 쓰기 시작한 2008년 밝았다. 여기서부터는 내일 다시.

No related posts.

Facebook comments:

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha