예전에 객체는 지향의 대상인가라는 글을 쓴 적이 있다. 요지는 Object-oriented가 정말 '객체지향'으로 번역되는 것이 맞느냐, 객체는 지향의 대상이 아니다라는 글이다. 그리고 이 글에 대해서는 류광님께서 훌륭한 논의를 해 주셨다.
최근 프로젝트를 진행하면서, 지인들과 논의를 하면서 느끼는 점은 많은 사람들이 특정 기술이나 패러다임을 말 그대로 '지향'한다는 것이다. 주된 지향의 대상은 조금씩 다르다. 어떤 사람은 서비스를, 어떤 사람은 객체를, 어떤 사람은 애스펙트를, 어떤 사람은 스프링 프레임워크를, 어떤 사람은 DB를...
물론 본인도 특정 기술을 편애하고 지향한다는 점에서는 다르지 않다. 다만 말하고 싶은 것은 우리의 진짜 지향할 바는 조금 달라야 하지 않을까하는 점이다.

서비스는 본인도 자신 없으므로 넘어가고,
그나마 본인이 짬밥 좀 먹은 객체지향을 예를 들면, Custom DTO나 anemic domain object는 객체지향적이 아니다라던가 하는 의견이 많다. 본인도 DTO 지옥에 빠져본 경험이 있는만큼, 그러한 의견에 대해서 동의한다. 하지만 한가지 더 가지고 있는 생각이라면, 과연 잘 만든 객체 못 만든 객체가 그렇게 중요한가이다.
DTO 지옥 속에서도 시스템은 오픈 날짜에 잘 돌아갔고 프로젝트는 성공했다. 어쨌든 DTO와 anemic domain object도 자바 VM 입장에서는 충분히 훌륭한 객체였다는 증거이고, 프로젝트는 그러한 상황을 견뎌낼 수 있었다는 이야기다. 또한 듣자하니 운영에도 별 문제가 없다고 한다. 하지만 반대로 anemic domain object 대신 rich한 domain object를 만들고자 했다면 어땠을까? 과연 분석/설계자들이 시간내에 anemic domain object가 아닌 무언가를 제대로 만들어낼 수 있었을까? 그러한 시스템을 SM들이 문제없이 인계받아 운영할 수 있었을까?

스프링도 살펴보자. 본인은 스프링을 편애하는데 이유는 딱 두가지다.
스프링이 정식 릴리즈 되는 순간을 국내에서는 가장 먼저(적어도 세 손가락?) 목격한 사람인 것이 첫번째고, 두번째는 스프링 EJB 보다는 훨씬 단순한 객체만 가지고(EJB는 뭔가를 코드에 삽입하게 만들지만, 스프링은 거의 그런 것이 없다. 그럼에도 불구하고 스프링 또한 암시적인 제약은 분명히 가하고 있다.) 기술적 아키텍처나 테크니컬한 문제와 97.5% 떨어져서 "도메인 문제 해결에 자바 코드를 집중할 수 있게 하는" 프레임워크이기 때문이다. 그리고 보너스로 "이제껏 등장한 각종 개념들을 색출하여 분리할 수 있는" 프레임워크이기 때문이다. 즉, 완전한 "SoC"의 밑바탕에 필요한 거의 모든 것을 갖췄기 때문이다.

그러나 아직까지 스프링은 그 자체로 지향의 대상에 머물고 있는 것으로 보인다. 하지만 시간이 걸리더라도 결국 우리가 가야할 곳은 "스프링"이 아니라 제대로된 객체가, 컴포넌트가, 서비스가 오픈일에 맞춰 만들어지고, 그리고 운영단계에서도 살아 숨쉬며 개선되는 그런 시스템과 그러한 시스템을 만들고 운영하는 방법에 있지 않을까 한다.

스프링 인 액션 2판은, 독자들이 그런 모습을 그려가며 읽어 주셨으면 한다. 책에서 설명하는, 스프링이 POJO 기반의 프로그램을 가능하게 하는 메커니즘도, IoC나 AOP도, 시큐리티나 메시징, 웹 MVC 도 중요하지만, 그것들을 왜 스프링은 엮으려고 하는지...를 궁금해 하면서 읽어 주셨으면 한다. 책에서 상세하게는 언급되어 있지 않지만 힌트들이 곳곳에 숨어있다. 그리고 이러한 점이 바로 Spring in Action SE 원서에 좋은 평가를 준 이유가 아닐까 싶다. 얼마전에 서울에서 만났던 토비님이 높이 평가하는 Pro Spring 1판(본인도 읽었으며 역시 강추. 안타깝게도 번역판은 없다. Toby님은 2판도 읽으셨다 한다.)도 같은 맥락이라고 생각한다.

금방은 아니겠지만, 현재 국내 스프링 커뮤니티의 활성도도 그렇고 거기에 계시는 지인들의 수준도 높으므로, 스프링을 바탕으로 한 베스트 프랙티스, 노하우, 기법, 방법론 등이 오래지 않아 정립될 것이라 믿는다. 고객도 만족하고 개발자도 해피하게 개발할 수 있는 그런 수준으로 말이다.



사족이지만 지금 만들고 있는 시스템은, '개발자 러닝커브 없애기'가 제 1과제였다. 이 시스템에서도 스프링을 쓰고 있지만, 스프링은 단 한가지 목적으로 쓰인다. DBCP를 이용한 데이터소스 설정이 그것이다. 그리고 나는 이 시스템 설계가 매우 잘되었다고 생각한다.
  1. Commented by Favicon of https://springframework.tistory.com BlogIcon 영회 at 2008.12.24 12:49 신고

    블로그 옮겨오신거 오늘에야 알았습니다.

  2. Commented by Favicon of http://gyumee.egloos.com BlogIcon 박성철 at 2009.06.07 20:30

    좋은 글 잘 읽었습니다. 정말 공감이 가네요.
    그런데 솔직히 스프링을 "지향"하기ㄹ라도 했으면 좋겠ㄴ습니다. ^^

    • Commented by Favicon of http://entworks.tistory.com BlogIcon entworks at 2009.06.10 18:38

      스프링이 주는 가치를 누가 정리좀 해줘서,
      대규모 JEE 프로젝트에서도 MUST로 쓰였으면 좋겠습니다.
      물론 스프링이 모든 문제의 해결책은 아니지만요.