2004년 첫 번째 공식 버전을 공개한 이후에 스프링은 빠른 속도로 확산되고 자바 엔터프라이즈 프레임워크의 독보적인 위치를 차지했다. 스프링 3.0은 자바 5에 포함된 언어 차원의 개선을 반영했고, 약점으로 지적 받던 설정 기능까지 대폭 강화해 완성형에 이르렀다. 또한, 높아진 위상에 걸맞게 자바 표준 수립과 준수에 기여했고, 엔터프라이즈 애플리케이션의 발전과 함께하며 REST 지원과 같은 개발자 요구에 부응하고 있다. 이 글에서는 스프링 3.0의 기능뿐 아니라 국내 엔터프라이즈 환경에서의 위치를 함께 조망해 본다.
안영회 ahnyounghoe@gmail.com｜아이티와이즈 컨설팅 SE 그룹에서 컨설턴트로 일하고 있으며, 국내 대규모 프로젝트에서 다년간 방법론, 모델링, 아키텍처 수립, 프로젝트 관리 등의 다양한 역할을 수행하고 있다. 현재는 보험사 시스템 구축 프로젝트에서 소프트웨어 아키텍트로 일하고 있으며 한국스프링사용자모임(KSUG)의 공동 설립자이기도 하다. 본인의 블로그인 Younghoe.info를 통해 현장 경험 나누기를 즐기고 있으니 교류를 원하는 분은 언제라도 환영한다.
스프링 3.0의 새로운 기능만 훑어보면 처음으로 어노테이션(annotations) 기반 설정을 내놓은 스프링 2.5처럼 눈을 끄는 내용은 없다. 반면에 2.5가 마치 무언가를 마무리하지 못한 미완의 버전 같은 인상을 준다면 3.0은 비로소 명실상부한 차기 버전 스프링으로 다가온다.
자바 5 기반 완성형 설정을 제공하는 스프링 3.0
3.0은 프레임워크 기반부터 큰 변화가 가해졌다. 우선 언어 차원에서 추가된 자바 5의 어노테이션, 지네릭스(generics), 이늄(enum), 개선된 동시성(concurrency) 지원 등의 새로운 요소를 사용할 수 있고, 또 스프링 내부에서도 사용했다. 그리고 이미 제공하던 XML과 어노테이션 설정에 이어서 자바를 사용한 설정도 가능해졌다. 사실 자바 설정은 별도 프로젝트로 존재하던 자바콘픽(JavaConfig)을 스프링이 흡수하는 방식으로 이뤄졌다. 거기에 더해서 #{…}와 같은 식의 스프링 표현 언어(Spring expression language, 혹은 SpEL)를 도입해서 프로퍼티 값으로 다른 빈의 프로퍼티나 시스템 프로퍼티를 넣을 수 있게 했다. 이 정도면 완성형 설정 프레임워크라 부를 만하다. 물론, 스프링의 역할이 설정 프레임워크에 그치지는 않는다. 스프링의 높아진 위상에 맞춰 스프링소스의 JCP 참여가 늘면서 자연스럽게 자바 표준과도 궤를 같이 한다.
JSR-286(Portlet 2.0 API), JSR-303 (Bean Validation), JSR-330(Dependency Injection in Java)과 함께 JPA 2.0, JSF 2.0 등의 자바 표준을 지원한다. 특히, JSR-330은 로드 존슨(Rod Johnson)이 직접 스펙 리더로 참여해 구글 주스를 만든 밥 리(Bob Lee, ‘크래이지 밥’이라는 별명으로 유명하다)와 함께 의존성 주입을 위한 어노테이션을 표준화했다. 또한 스프링에서는 자바 1.4까지 부족했던 기능을 제공하는 클래스가 있었다. 이를 테면 라벨을 붙일 수 있는 이늄 기능(LabeledEnum)이나 ConcurrentMap 등이 예다. 이러한 요구가 자바 5에서 보강되자 중복되는 스프링 인터페이스나 클래스의 사용 자제를 권고(deprecated 처리)하는 꼼꼼함까지 잊지 않았다. 스프링 3.0의 강력해진 설정 능력은 이어지는 글을 통해 접할 수 있다.
스프링 웹 MVC의 REST 지원
기능 하나만 꼽을 경우 가장 눈에 띄는 건 역시 REST 지원이다. 2.5 버전까지는 REST를 지원하지 않아, 필자는 REST를 지원하는 다른 프레임워크에 눈을 돌린 일도 있다. 본격적으로 REST에 초점을 맞춘 다른 프레임워크와 비교해 봐도 스프링 3.0의 REST 지원은 꽤 만족스럽다. 무엇보다 REST를 위해 별도의 서비스 노출 방식을 쓰지 않고, 스프링 웹 MVC 컨트롤러에 어노테이션을 써서 사용할 수 있기 때문에 스프링 개발자라면 쉽게 익힐 수 있다. 더불어 같은 컨트롤러에서 REST 방식 처리도 수행하면서 동시에 종래의 방식 즉, 응답으로 뷰를 사용하는 방식을 함께 쓸 수도 있다. 또한, 스프링 웹서비스 프로젝트에 있던 OXM(Object XML Mappings) 기능을 내장해 XML 변환을 더 편리하게 할 수 있다.
자바의 모듈화를 선도하는 스프링
스프링 3.0의 큰 변화 중 하나는 바로 스프링 모듈을 하나로 묶은 spring.jar 파일이 사라졌다는 점이다. 스프링 사용자 입장에서야 파일 하나를 여러 개로 분리한 정도로 보일 수 있지만, 스프링 소스를 받아본 사람은 스프링 프레임워크 개발 시점의 이클립스 프로젝트 구성이나 빌드 방식이 얼마나 달라졌는지 알 수 있다. 이클립스 프로젝트가 여러 개로 나눠지고 빌드 방법도 상당히 복잡하다. 스프링 프레임워크 개발팀은 이전에 사용하던 프로젝트 구조와 빌드 방식을 버리고 애초에 스프링 웹 플로우(Spring Web Flow) 2.0 프로젝트에서 쓰던 빌드 체계를 채용했다. 아파치 재단에서 개발한 빌드 도구인 아이비(Ivy)를 채용했고, 배포 절차와 의존관계 관리를 체계적으로 정비했다. 복잡한 프로젝트 구조는 한편으로는 OSGi 기반의 모듈 단위 배포에 적합한 개발환경이기도 하다.
아직 엔터프라이즈 개발에서 널리 쓰이는 상황은 아니지만 눈여겨볼 시도라고 생각한다. 필자가 가장 즐겨 보던 블로그 저자가 최근 블로그를 닫고 모듈기반 아키텍처 패턴(Patterns of Modular Architecture)에 대한 글(
http://www.kirkk.com/modularity/)을 쓰면서 모듈화에 더 관심을 기울이게 되었다. 스프링 저자로 유명한 크레이그 월스(Graig Walls)도 모듈화에 관한 책 『Modular Java』를 출간한 바 있다. 모듈화를 위한 개발환경뿐 아니라 모듈 구동을 위한 플랫폼에 있어서도 스프링과 개발사인 스프링소스(SpringSource)의 역할은 상당하다. 사실 스프링은 자바 모듈화 플랫폼 표준인 OSGi를 엔터프라이즈 환경에 보급하는 데 깊이 관여하고 있다. 스프링의 단순하고 강력한 프로그래밍 모델을 OSGi 영역에 전파하는 스프링 다이내믹 모듈스(Spring Dynamic Modules for OSGi Service Platforms) 프로젝트와 OSGi 플랫폼 표준을 완벽하게 지원하는 스프링소스 DM 서버는 엔터프라이즈 환경의 모듈화 영역에선 가장 돋보이는 산물이다. 스프링 3.0을 내장한 완벽한 모듈 기반 자바 웹 서버인 이클립스 버고(virgo)는 스프링소스 DM 서버를 이클립스 재단에 기증한 결과물이다.
.jpg%22&type=m10000_10000)
<그림 1> 이클립스 재단 프로젝트인 이클립스 버고의 로고
스프링루와 스프링소스 툴 스위트
아무리 스프링을 쓴다고 해도 단순 반복적인 작업은 남게 마련이다. 한때 폭발적인 인기를 구가했던 루비 온 레일스(Ruby on Rails)는 관례를 따르면 뻔한 코드는 제거하거나 자동 생성해서 개발 편의성을 높였다. 이러한 인기는 스프링에도 영향을 미쳐 스프링소스가 그루비(Groovy) 기반 프레임워크인 그레일스(Grails)를 인수하게 했다. 그레일스를 사용하면 동적 언어의 편리함과 스프링의 강력함을 함께 누릴 수 있다. 하지만, 굳이 동적 언어를 쓰고 싶지 않은 개발자라면 맷 레이블(Matt Raible)의 애퓨즈(AppFuse)와 같은 RAD(Rapid Application Development) 도구를 사용해 편의성을 높일 수도 있다. 스프링 시큐리티(Spring Security)로 유명한 벤 알렉스(Ben Alex)는 최근 스프링루(Spring ROO)를 내놓았다. 스프링루는 애퓨즈를 연상시키지만 여러 가지 차이가 있다. 무엇보다 스프링소스가 주도하기 때문에 스프링소스가 내놓은 이클립스 확장 제품인 스프링소스 툴 스위트(Suite)와 강력하게 통합되어 있다는 점이 그 중 하나다. 스프링루에 대한 이야기는 이어지는 글에서 다루기 때문에 스프링소스 툴 스위트에 대해서만 조금 더 이야기를 나눠 보자.
스프링 애플리케이션 개발을 위해 이클립스 플러그인을 구상하는 일도 꽤 번거로운 일이다. 한번 구성하면 그만이 아니라 매번 개별 플러그인이 바뀌면 갱신해 줘야 하고, 이클립스 자체가 새로 나오면 이전에 쓰던 플러그인에서 이클립스 새 버전을 지원하는지부터 확인해야 했다. 스프링소스 툴 스위트는 바로 이 같은 번거로움을 대신해 준다. 새로운 이클립스 버전이 나오자마자 바로 새 버전의 스프링소스 툴 스위트를 내놓은 릴리즈 속도는 참으로 놀랍다. 필자도 처음에는 가능하면 일반적인 환경을 쓰려고 이클립스를 직접 구성해 사용했지만 최근엔 스프링소스 툴 스위트로 전환했다. 무료로 다운로드해서 쓸 수 있기 때문에 아직 써보지 못한 독자는 한번 체험해 보라고 권하고 싶다. 특히나 이클립스에서 스프링 설정 파일을 만들 때 복잡한 XML 코드를 복사했던 경험이 있거나 이클립스가 내장한 XML 편집기에서는 자바 편집기처럼 자동완성이 되지 않아 불평했던 독자라면 스프링소스 툴 스위트를 좋아하게 될 것이다. 다음은 스프링소스 툴 스위트의 다운로드 사이트 URL이다.
사라지는 스프링의 유산
필자가 스프링 프레임워크의 소스 코드를 보려고 시도한 이유는 웹 MVC 탓이다. 2006년 출간된 『‘Expert Spring MVC and Web Flow』 책은 스프링 웹 MVC의 복잡한 내부 처리 흐름에 대해 완벽하게 설명하고 있지만, 아쉽게도 필자가 웹 MVC를 고민하던 때는 출간 전이었다. 당시 빈약한 공식 참조 문서는 물론이고 『Spring in action』이나 『Pro Spring』 등의 책에서도 MVC 내용은 턱없이 부족했다. 폼(Form) 제출에 따른 POST 요청 처리 결과가 성공이냐 실패냐에 따라 후속 처리가 달라지는 SimpleFormController는 화면으로 나타나는 결과만으로는 유추할 수 없었다. 폼으로 입력한 값이 어떻게 커맨드 객체의 프로퍼티 값에 알맞은 데이터 타입으로 변환되어 저장되는지 그 과정을 알기 어려웠고, 값을 검증하는 시점도 참조 문서와 책으로는 답을 찾기 어려웠다.
그래서 결국 소스 코드에서 답을 찾을 수밖에 없었다. 그때 기억 중에 SimpleFormController를 완벽하게 이해했을 때 느낀 희열은 지금도 잊을 수 없다. 하지만, 시간이 흐르면 모두가 변한다. 조만간 스프링 프레임워크에서 Simple FormController는 볼 수 없을지도 모르겠다. 스프링 3.0에서 impleFormController는 기피 대상(deprecated)이다.
.jpg%22&type=m10000_10000)
<그림 2> 완벽하게 1.2 버전의 스프링 웹 MVC를 설명한 'Expert Spring MVC and Web Flow'
스프링 3.0에서는 무려 70개가 넘는 클래스(인터페이스나 어노테이션 타입 포함)가 기피 대상(deprecated)이며 언젠가는 사라질 것이다. 2.5 버전에서는 20개가 조금 넘었음을 고려하면 꽤 많은 숫자다. 권고가 아니라 아예 사라진 클래스도 있다. 물론, 사라진 클래스는 2.5에서부터 API 문서에서 사라진다고 알려졌던 클래스들이다. 스프링 3.0은 자바 5 활용과 함께 어노테이션 기반의 MVC 사용을 적극 권장하기 때문에 배치되는 클래스는 역사의 뒤안길로 물러서고 있다.
국내 SI에서도 사실상 표준
필자가 한국스프링사용자모임(KSUG)을 만들고 스프링에 관한 무료 세미나를 할 때만 해도 대부분 신기한 표정이었지만 몇 년 사이에 상황은 완전히 달라졌다. 최근에 만나는 개발자가 스프링을 안 써봤다고 하면 십중팔구 자바 자체를 안 쓰는 사람이다. 스프링이 3.0으로 진화하는 동안 국내 프로젝트에서도 EJB에 대한 잘못된 ‘미신’을 떨쳐 버릴 수 있었다. 스프링이 국내에 더 빨리 보급되지 못한 이유는 비단 EJB에 대한 미신 탓만은 아니다. 가장 큰 이유 중 하나가 부족한 문서와 교육이 아니었을까? 여기에는 애니프레임과 전자정부 표준 프레임워크가 기여한 바가 크다. KSUG에서도 시도했지만 문서화는 정말 시간과 노력이 많이 들어간다. 애니프레임 커뮤니티에 있는 한글 문서를 얼마나 많은 사람이 봤는지는 알 수 없지만, 애니프레임 공개 즈음에는 그만한 한글 설명은 어디에서도 찾을 수 없었다. 반갑게도 최근에 훌륭한 스프링 책이 번역서도 아닌 저서로 나오긴 했지만, 한글로 된 스프링 설명에 목마른 개발자는 무척 많았다. 2007년에 전자정부 표준 프레임워크에 대해 첫 번째 자문을 요청 받았을 때, 가장 먼저 조언한 이야기가 문서화 요구였다.
오픈소스인 스프링을 영어권이라면 쉽게 가져다 써서 효과를 볼 수 있는데, 한글 문서가 없어 상대적으로 우리나라 개발자는 소외되고 있다. 바로 수익을 기대할 수 없지만, 스프링 한글 문서화가 기여하는 가치는 매우 크기 때문에 정부가 하기에 적합하다는 생각이었다. 당시 자문을 요청한 분은 정권이 바뀌면서 사업에 참여하지 못했지만, 결과적으로 전자정부 표준 프레임워크도 한글 가이드를 남겼다. 그리고 전자정부 표준 프레임워크 교육을 통해 중소기업 개발자들이 10여 차례나 스프링을 무료로 교육받을 수 있었다. 스프링 보급을 더디게 했던 또 다른 이유로 국내 스프링 기술지원의 부재를 들 수 있다. 기업에서 섣불리 오픈소스를 쓰지 못하는 이유로 기술지원 업체가 없다는 사실을 꼽는 사람이 많다. 전자정부 표준 프레임워크 주요 인사 중 한 분은 스프링은 전자정부 표준 프레임워크가 낮은 비용으로 높은 품질을 갖는 데 공헌했고, 반대로 전자정부 표준 프레임워크가 스프링이 공공사업에 진출하는 데 일등 공신 역할을 했다고 설명했다. 아쉽게도 스프링소스는 한국에 지사가 없기 때문에 기술지원을 받기 어렵다.
반면에 전자정부 표준 프레임워크는 사업단에서 기술지원을 수행한다. 게다가 공공사업에 필요한 주요 공통 기능을 함께 제공하기 때문에 공공 프로젝트에 참여하는 상당수 개발자가 전자정부 표준 프레임워크를 통해 스프링을 접한다. 다만, 아쉽게도 전자정부 표준 프레임워크는 아직 스프링 3.0 채용 계획이 없다. 반면에 애니프레임은 지난 7월 공개한 4.5 버전부터 스프링 3.0을 채용했다.
.jpg%22&type=m10000_10000)
<화면 1> 스프링 3.0 기반의 애니프레인 4.5 버전 공개를 알리는 공지
전자정부 표준 프레임워크의 도전
8월 31일 전자정부 표준 프레임워크 오픈 커뮤니티 창립 기념 세미나 개최를 시작으로 전자정부 표준 프레임워크 사업단은 새로운 도전을 시작한다. 프레임워크는 오픈소스로 공개했지만 프레임워크를 만드는 과정은 공개가 아니었다. 사업단에서는 오픈소스 발전 과정에 대한 연구를 통해 지속적인 개선과 효율적 운영을 위한 개방형 혁신체계 도입을 목표로 오픈 커뮤니티를 운영할 예정이다. 쉽지 않은 도전이지만 시도만으로도 충분히 박수를 쳐주고 싶다. IBM이 처음 아파치 재단을 후원할 때도 오픈소스 진영은 IBM 탓에 오픈소스 정신이 무너질까 걱정하고, IBM 역시 전 세계에 흩어져 있는 개발조직과 일할 수 있을까 의문시했다고 한다. 하지만, 결국 성공했다. 중요한 것은 얼마나 오래 초심을 유지하며 꾸준히 이끌어 가느냐일 테니까. 어쨌든 전자정부 표준 프레임워크 사업단의 개발조직에 변화를 주려는 시도는 스프링이 미친 영향이라 할 수 있다.
범 기업적 협력체계를 꿈꾸며
전자정부 표준 프레임워크 개발을 주도한 기업이 바로 애니프레임을 개발한 기업이란 점을 고려하면 전자정부 표준 프레임워크가 스프링 3.0을 채용하지 못한 점은 아쉽다. 물론, 현실적으로 같은 기업이라고 해도 참여하는 조직이 다르고 각 프레임워크를 운영하는 주체도 다르고, 사용처도 차이가 있기 때문에 단순한 문제는 아니다. 필자는 다년간 여러 기업을 상대로 스프링을 기반으로 한 프레임워크를 개발했다. 스프링 자체가 프레임워크인데 또 프레임워크를 만드는 이유는 무엇일까? 사실 조직마다 기대하는 바가 달라 일반화해서 말하긴 어렵지만, 스프링 기술지원 회사가 없다는 점이 출발이라 할 수 있다. 조직 내에서 낮은 비용으로 프레임워크 기술지원을 수행하기 위해서는 중복 작업을 최대한 제거해야 한다. 기업이 개발하는 모든 시스템에서 혹은 유사 사업에서 반복적으로 쓰는 내용은 스프링을 기반으로 매번 만드는 것보다 기업 표준 프레임워크를 만들어 관리하는 편이 낫다.
하지만 유사한 사업을 하는 모든 기업이 각자 프레임워크 구축에 투자해야 할까? 이와 관련해서 한 가지 이야기가 떠오른다. 가까운 친척이 휴대폰 액세서리 사업을 하던 때였다. 국내 경쟁사와 함께 대만 회사와도 경쟁하던 터라 대만과 우리 기업 문화를 비교했다. 우리나라 회사는 경쟁사를 무너뜨리기 위해 출혈을 해서라도 새로운 설비를 구입하는 일이 잦은 반면에, 대만은 조합 형태로 설비를 구매하기 때문에 작은 규모에도 경쟁력을 갖는 모습이 부러웠다고 한다. 다시 스프링 이야기로 돌아오자. 우리나라에도 곳곳에 스프링 전문가가 꽤 있지만, 많은 프로젝트에서 스프링 전문가가 부족하다고 토로한다. 프로젝트에 상주로 참여해 일을 진행하는 풍토가 일반적인 우리 현실은 다시 대만의 조합문화를 떠올리게 한다.
혼자 힘으로는 프레임워크를 운영할 수 없는 기업이 십시일반 투자해 만든 프레임워크를 모두가 나눠 갖는 것은 어떨까? 우리 기업의 자산을 남에게 공개하기 어렵다고 생각할 수 있지만, 프레임워크가 다루는 내용은 대부분의 기업에서 핵심 영역이 아니다. 오히려 기반 공공재에 가까운 요소를 개발하는 데 협력해서 비용을 낮출수록 핵심 역량을 발휘하는 데 유리하지 않을까? 실제로 이클립스와 같은 주요 오픈소스 커뮤니티가 움직이는 방식을 보면 비슷한 점이 많다. 후원하는 주요 기업 중심의 전문가 그룹이 새 버전에 포함시킬 요구사항이나 기능을 결정한다. 필자는 이 원고를 작성하기 전에 고객을 대상으로도 이런 아이디어를 제안한 바 있다. 아직은 도입하기에 시기상조라 느꼈지만, 언젠가 때가 오면 다시 시도할 생각이다.
국내 저변 확대의 새로운 전기
얼마 전 국내 유명 솔루션 개발사가 OS 출시 후에 경영난을 겪은 바 있다. 그 회사가 갖고 있던 프레임워크는 금융 분야에서 독보적인 위치를 확보하고 있었다. 소스 코드 라이선스 문제로 분쟁에 휩싸였을 때, 해당 프레임워크 도입을 검토하던 고객 요구로 프레임워크 소스 코드를 분석한 일이 있다. 그 과정에서 스프링 프레임워크의 소스 코드가 패키지 이름만 해당 회사명이 들어가게 바뀌어서 포함되어 있다는 사실을 알고 놀란 일이 있다. 법적으로나 도의적으로나 문제가 있는 내용이지만, 이미 다른 기업과 법정 공방 중인 터였다. 경영난 이후에 해당 프레임워크를 사용하거나 도입을 검토하던 많은 기업이 회당 제품의 미래를 불투명하게 여겨 새로운 후보를 찾아 눈을 돌리고 있다.
이러한 상황은 스프링 3.0 도입의 새로운 전기일 수 있다. 그러나 금융권에서 필요로 하는 프레임워크에 대해 고객은 다양한 아키텍처를 통일성 있는 모습으로 수용하기를 기대한다. 이를 위해서는 스프링이 요구하는 선택 능력을 갖춘 개발자 혹은 설계자가 필요하다. 온라인 거래 처리를 위한 웹 애플리케이션에 스프링을 사용하는 경우와 배치 성격의 시스템에서 쓰일 때 스프링의 활용 방법이나 애플리케이션의 구성은 완전히 다르다. 마찬가지로 많은 트랜잭션을 감당하기 위해 비동기식 처리를 해야 하는 시스템은 어떨까? 아직 프레임워크에 대한 이해가 부족했던 2000년 초중반만 해도 대형 프로젝트에서 상식적으로 이해할 수 없도록 프레임워크를 구성하거나 사용하는 일을 흔히 목격할 수 있었다.
아직도 그런 일에 대해 목격하기란 어려운 일이 아니다. 그러나 스프링 도입과 함께 업계의 프레임워크에 대한 적용 능력도 나아졌다. 스프링의 역할이기도 하고, 산업 전체가 학습하기 위해 불가피한 시간을 보내온 것이기도 하다. 다행스러운 점은 적절한 시점에 독자들에게 추천할 책이 나왔다는 사실이다. 이어질 글의 필자이기도 한 토비님이 쓴 책은 스프링을 제대로 활용하는 데 훌륭한 동반자 역할을 해줄 것이다. 이미 필자는 이 책에 감탄해 추천사를 썼다. 단순히 스프링의 사용법만을 다루는 데에는 1,400페이지가 필요하지 않다. 스프링의 철학과 필요성뿐 아니라 주요 요소 기술까지 해박하게 잘 엮어낸 이 책을 통해 우리나라에도 비단 스프링 전문가가 아니라 훌륭한 엔터프라이즈 개발자가 만들어지길 기대한다.
.jpg%22&type=m10000_10000)
<그림 3> 스프링에 대한 깊은 이해를 돕는 서적, '토비의 스프링 3'
스프링 3.0과 어울리는 기술
앞서 스프링루와 스프링소스 툴 스위트를 이야기했지만 이외에도 스프링 3.0과 함께 쓰일 수 있는 도구나 기술은 많다. 『토비의 스프링 3』의 특징 중에 하나는 학습 테스트로 스프링 요소 기술을 확인해가며 익힌다는 점이다. 학습 테스트에 쓰이는 도구는 테스트 자동화 도구인 제이유닛(JUnit)이다. 자동화 테스트 활용은 스프링과 뗄 수 없는 관계에 있다. 필자가 발표했던 첫 번째 KSUG 세미나(그때는 이프릴 세미나였음) 주제는 스프링의 테스트 프레임워크를 다루는 내용이었다.
세미나를 준비하면서 스프링이 내장한 편리한 테스트 지원 기능에 필자도 놀랐던 기억이 생생하다. JUnit 4의 등장과 스프링의 어노테이션 기반 설정 채택과 함께 스프링의 테스트 프레임워크도 많이 발전했다. 필자가 참여하는 모든 프로젝트에서 주요 코드에 대해서는 반드시 테스트를 만들어 프로젝트 초반부터 회귀 테스트 기반을 구축한다. 스프링이 그렇게 하듯 프로젝트 상황에 맞춰서 적절한 범위에 한해 현실적인 방법을 선택해야 한다는 점은 꼭 기억해야 한다. 스프링을 잘 쓰는 개발자 상당수는 CI(Continuous Integration) 혹은 CTIP(Continuous Test & Integration Platform)라는 도구나 환경을 사용한다.
스프링을 쓰려면 CI 도구를 알아야 하는 것은 아니지만, 스프링이 엔터프라이즈 애플리케이션에 대한 설계와 프로그래밍의 모범 사례를 코드로 만들어낸 결과물이라면 CI 도구는 프로젝트 개발 과정, 그 중에서도 코드 통합과 테스트 환경에 대한 모범사례란 점에서 격이 맞는다. 스프링 3.0을 사용하는 개발자 중에 아직도 자동화 테스트를 작성하지 않는다면 최대한 빠른 시간에 시도해 보길 권한다. 만일, 의지가 있는데 방법을 모르는 분이라면 채수원 씨가 최근에 출간한 『테스트 주도 개발: 고품질 쾌속 개발을 위한 TDD 실천법과 도구』란 책은 좋은 선택이다. 반면에 데이터베이스를 연계하거나 아직 개발하지 않은 클래스를 사용하는 클래스에 대한 테스트를 어떻게 해야 하나 고민하는 독자라면 스프링 소스 코드를 받아서 테스트 코드를 정독하는 방법도 좋다.
.jpg%22&type=m10000_10000)
<그림 4> 자동화 테스트와 함께 TDD 등을 배울 수 있는 서적, '테스트 주도 개발 : 고품질 쾌속개발을 위한 TDD 실천법과 도구'
스프링 3.0과 어울리는 개발자
커뮤니티를 운영하면서 블로그 활동을 하다 보니 온라인에서 보내는 시간이 많다. 과거에는 기술적인 근거 없이 소문이나 개인적 취향을 근거로 스프링을 폄하하는 글이 많았다. 대개는 지나치게 복잡하다는 이유였다. 필자가 생각하기에는 인터넷에 나온 예제를 보고 한번 시도했다가 번거롭다고 느끼는 경험만으로 스프링에 대해 온라인에서 비난하는 행위 이상은 아니었다. 스프링은 Java EE 범용 프레임워크기 때문에 자연스레 다양한 선택을 수용해야 한다. 그럼에도 불구하고 단순함을 유지하는 기술력에 감탄하지 않을 수 없다.
스프링을 비난하던 개발자 중에는 자신이 만들어낸 코드에 대한 애착을 버리지 못해 ‘우물 안 개구리’의 우를 범하는 이도 있었다. 과거를 떠올려보면 스트럿츠(Struts)가 막 인기를 구가할 때도 자신이 만든 프레임워크에 비해 기능이 빈약하다고 폄하하던 이는 많았다. 시간이 지나면서 엔터프라이즈 프로그래머의 전반적인 성숙도가 높아졌다. 이제는 자기 것을 고집하는 우매함을 극복하려고 노력하는 개발자가 늘고 있다.
십 년 남짓 경력이 있는 이라면 과거에는 팀 동료와 코드를 공유하는 일이 드물고, 자기 코드를 보여주기를 극도로 꺼리던 개발자가 많았음을 기억할 것이다. 스프링의 아버지 로드 존슨이 J2EE에 대한 자신의 철학을 담은 책 『Expert One-on-One J2EE Development without EJB』는 많은 논란을 낳았다. 바로 Without EJB 때문인데, EJB 제품이나 EJB 기반 지식을 업무영역으로 삼았던 이들의 공격 탓이다. 필자는 Without EJB란 표현이 너무나 마음에 든다. 그 이유는 J2EE라는 더 큰 가치를 위해 과감하게 EJB를 극복한 J2EE 개발자의 창조적 파괴이기 때문이다.
.jpg%22&type=m10000_10000)
<그림 5> 스프링의 설계철학을 담고 있는 'Expert One-on-One J2EE Development without EJB'
얼마 전 클라우드 환경에서 아키텍트 역할을 하는 지인을 만났다. 지금 하고 있는 일을 ‘스프링 다음에 대한 것’이라고 설명했다. 스프링을 대치할 무언가가 아니라 조금 다른 범주의 일을 말했다. 클라우드 환경을 놓고 보면 스프링이 단일 노드를 위한 프레임워크라면 자신은 여러 노드를 관리하는 기술을 다룬다고 했다. 국내 환경에서는 클라우드 서비스를 제공하는 기업은 아직 드물고 서버 가상화 환경이 주류로 부상하려면 꽤 시간이 필요해 보인다. 사실 엔터프라이즈 환경에서는 전형적인 관계형 데이터베이스의 종속적인 프로그래밍 방식을 버리지 못해 NoSQL은 커녕 ORM(Object-Relational Mapping)이나 객체기반의 데이터 캐시 혹은 데이터 그리드조차 활용하는 사례가 매우 드물다.
필자는 스프링을 배우면서 안타까운 현실을 개탄할 시간을 아껴 가장 현실적인 방법을 찾으려고 노력한다. 필요하다면 진리로 믿었던 통념과 관성을 파괴하는 일도 마다하지 않아야 스프링과 같은 좋은 솔루션을 만들 수 있다.
스프링 3.0, 그 다음은
이 글을 쓰는 현재 시점에서 스프링 최선 버전은 3.0.4 버전이다. 첫 번째 마일스톤 버전 대상으로 현재 등록된 154개의 이슈는 주로 REST 보강을 포함한 MVC 개선이 많지만, 일일이 살펴보면 매우 다양하다. 심지어 녹색바탕의 API 문서가 읽기 불편하다고 표준 API 문서 형식으로 바꾸자는 이슈(SPR-6787)도 있다. 스프링소스의 웹 개발팀 리더인 키스 도날드(Keith Donald)가 올린 내용이다. 3.1 버전이 윤곽을 드러나기까지는 아직 한참의 시간이 남은 듯하다. 반면에 스프링소스의 전략은 좀 더 명확하다. WAS 수준에서 플랫폼 호환성을 이뤄낸 스프링은 로컬 환경과 클라우드 플랫폼을 넘나드는 플랫폼 호환성을 향해 나아가고 있다. 스프링의 다음 모습은 아마도 이러한 비전을 위한 기반 프레임워크일 것이다.
마무리
지금까지 스프링 3.0의 주요 기술을 훑어보고 3.0까지 진화한 스프링이 국내 엔터프라이즈 환경에서 차지하는 현주소를 살펴봤다. 그리고 독자들이 스프링 3.0과 함께 알아둬야 할 기술을 살펴보고, 조심스럽지만 스프링에 어울리는 개발자의 태도에 대해서도 운을 띄웠다. 그 가운데 『토비의 스프링 3』를 비롯한 여러 권의 책을 소개했다. 필자 역시 책을 읽고 있다. 스프링을 배우기 위함이지만, 동시에 스프링은 스프링 그 이상의 것을 알려 주기 때문이기도 하다. 아마 여러분이 이 글을 읽는 시점에는 필자가 블로그에 책을 읽은 소회를 쓰고, 여러분과 온라인에서나마 의견을 교류하길 기대한다.
댓글
댓글 쓰기