[마소]오픈소스를 이용한 시스템통합 그 즐거운 도전의 시작

1회, 오픈소스를 이용한 시스템 통합, 그 즐거운 도전의 시작
2회, 첫번째 도전! 스트럿츠와 벨로시티의 통합

3회, 약한 결합도 아키텍처를 위한 대안 기술, 스프링
4회, OR 맵핑 도구의 선두 주자, 하이버네이트

 

이번 기획은 값 비싼 상용 웹 애플리케이션 서버나 개발 도구 등과 비교해 결코 뒤지지 않는 J2EE 기반 오픈소스만을 활용해 경쟁력 있는 시스템 통합이 가능하다는 것을 보여주기 위해 준비됐다. 이를 통해 그동안 오픈소스에 대한 잘못된 인식을 바로 잡고, 오픈소스로도 실제 e비즈니스 시장을 성공적으로 공략할 수 있다는 것을 보여주고자 한다. 또한 연재와 함께 웹을 통해 오픈소스 프로젝트가 진행되고 있으니 오픈소스에 관심이 있는 독자 여러분들의 많은 참여 바란다. <편집자 주>

최근 IT 경기 침체로 인해 해외 시장으로 눈을 돌리고, 기업 경쟁력을 재고하게 되면서부터 대형 SI 업체를 중심으로 바람직한 변화의 바람이 불고 있다. 기업 내의 CMO 조직을 중심으로 CMM, SPICE, CMMI에 기반 한 조직 프로세스 개선이 이루어지고, 프로젝트 성공률을 높이기 위한 다양한 PM 기법들이 도입되며, 프레임워크 도입과 방법론 적용을 통해 자체 솔루션의 경쟁력을 높이기 위한 다양한 연구가 활발하게 진행되고 있다. 하지만 그러한 노력에도 불구하고 실제로 국내 SI 프로젝트의 수준은 비약적인 기술 발전을 이루어내지 못하고 있다. 그 이유 중 하나는 이러한 변화를 이끌고 있는 리더 그룹과 실제 개발자들 사이의 기술 격차가 너무 크다는 데 있다. 또한 자금력이 부족한 중소규모 SI 업체들은 이러한 변화를 수용하기에 충분한 연구 인력도 없고, 기술 지원도 받지 못하고 있는 실정이다.

##########0*

<그림 1> 오픈소스 통합 배포판이 왜 필요한가?

논쟁의 중심에 선 오픈소스
최근 비하이브(Beehive)라고 명명된 BEA의 오픈소스 프로젝트와 2004 자바원 컨퍼런스에서 논의된 '오픈소스 자바'가 IT 업계의 핫이슈로 떠오르고 있다. 자바 개발자 커뮤니티의 규모를 키움으로써 MS 닷넷 기술의 거센 도전에 대응하겠다는 전략적 판단과 단일 기업인 MS에 비해 JCP가 가지는 느린 의사 결정의 한계를 극복하는 방안으로 오픈소스가 고려되고 있는 것이다. 비록 IBM, 썬, BEA, 오라클 등과 같은 자바 진영에 포진한 메이저 회사들이 오픈소스를 이용한 정책 변화에 한 목소리를 내고 있지는 않지만, 최소한 자바 커뮤니티는 많은 기업들에게 자바와 닷넷의 선택은 ‘둘 다’가 아닌 ‘둘 중 하나’가 되리라는 것을 알고 경쟁력 강화에 힘을 쏟고 있는 듯하다. 그러한 상황에서 자바가 지금과 같은 위치를 계속 고수할 수 있는지의 여부는 중소기업 시장을 장악할 수 있느냐와 개발자(개발 회사)들에게 자바가 여전히 매력적인 기술임을 확신시킬 수 있느냐에 달렸다고 볼 수 있다.

J2EE 관련 오픈소스 기술
IT 개발환경은 경기 침체로 인해 오히려 바람직한 변화를 겪고 있다. 하지만 이러한 변화를 이끌고 있는 선두 그룹과 일반 개발자들 사이에 너무 큰 기술 격차가 존재함으로써 변화로 인한 효과는 크지 않은 실정이다. 또한 닷넷의 거센 도전에 대항하기 위해 자바 진영에서는 오픈소스를 활용한 다양한 해결책을 제시하고 있고 그것은 업계의 큰 관심과 다양한 논쟁을 불러일으키고 있다. 하지만 국내에서는 오픈소스가 지닌 커다란 가능성에 대해 완전히 수긍하지 못하고 있는 분위기다. 그 이유는 오픈소스의 장점을 제대로 보여줄 수 있는 가이드라인이 부재하다는 데 있다.

초창기 리눅스는 소수의 전문가 그룹의 전유물이었고, 유닉스를 위협할 단지 가능성 있는 기술에 불과했다. 그러나 레드햇과 같은 배포판이 복잡도를 감추고 일반인에게 쉽게 다가갈 수 있도록 흩어져 있는 오픈소스들을 하나로 통합함으로써 비로소 운영체제로써 자신만의 확고한 영역을 가질 수 있게 되었다. 필자는 바로 이러한 배포판이 다양하고 강력한 오픈소스 기술을 많이 확보하고 있는 J2EE 개발 분야에 꼭 필요하다고 생각한다.

자바를 지원하는 오픈소스 도구로 검증받은 우수한 솔루션이 너무나 많이 존재하고 있다. 톰캣, Resin, Enhydra 와 같은 다양한 JSP 컨테이너가 있고, JBoss, JOnAs와 같은 EJB 컨테이너도 있으며, 이클립스, NetBeans와 같은 우수한 IDE와 수많은 플러그인들이 있다. JUnit, CVS, Ant, log4j와 같은 오픈소스 기술들은 이미 일반화된 지 오래고, Struts, Turbine, Velocity, Spring과 같은 공개된 프레임워크와 Castor, Hibernate와 같은 O/R 맵퍼, MDA 지원을 위한 AndroMDA까지 그 자체로도 충분히 경쟁력 있는 개발 환경이 구축될 수 있을 만큼 오픈소스 시장은 성숙해 있다. 이제 개발자에게 필요한 것은 Struts가 MVC 개념을 지원할 기본 프레임워크로 훌륭하다거나, 이클립스를 쓰면 상용 자바 IDE 툴 못지않게 개발 생산성이 높아진다거나, Hibernate가 엔티티 빈이 갖는 약점들을 극복해줄 대안이 될 수 있다거나 하는 단편적인 지식이 아니다. 다양한 대안들 중에서 한 가지 기술이나 툴을 선택하고, 그것이 자신이 수행하는 프로젝트에 어떻게 적용되어야 할지 고민하는 그 순간에 이미 경쟁력을 상실할 수 있을 만큼 기술은 빠르게 변화하고 짧은 시장진입기간(Time to market)이 요구되기 때문이다. 외국의 경우 J2EE 기반 기술을 주로 다루는 오픈소스 컨설팅 기업들이 이러한 고민을 덜어 줄 다양한 활동을 펼치고 있지만, 안타깝게도 국내에는 그러한 사례가 전혀 없다.

<그림 2> J2EE 기반 오픈소스 통합 배포판의 개념

<그림 2>는 필자가 생각하고 있는 J2EE 기반 기술을 위한 오픈소스 통합 배포판의 개념을 정리한 것이다. 우선 다양한 오픈소스 기술이나 제품들 중에서 가장 최적의 조합을 선택해 미리 설정된 형태로 압축해서 배포한다. 다행인 점은 자바의 특징상 리눅스의 아나콘다와 같은 별도의 설치 프로그램이 필요 없다는 것이다. 단지 압축을 풀고, 필요한 환경 변수 몇 가지를 설정해주는 것만으로 설치를 끝낼 수 있다.

배포판에 포함된 모든 기술을 필요로 하지 않을 경우도 있다. 그래서 필요한 항목을 선택한 다음 내장된 Ant를 이용해서 간단하게 빌드할 수 있도록 설정해 두는 것이 좋다. 오픈소스 통합 배포판에서 가장 중요한 것은 미리 경험한 다양한 문제에 대한 경험을 함께 전달해야 한다는 것이다. 그래서 오픈소스 통합 배포판에 포함된 기술들을 사용해서 프로젝트를 진행하는 방법론과 그 방법론이 적용된 적당한 규모의 예제가 포함되어야 할 것이다. 오픈소스는 결국 개발자들의 자발적인 관심과 참여로 성장하게 된다. 따라서 개발자를 아우를 수 있는 커뮤니티의 지원 역시 필수적인 요소라 할 수 있다.

이를 위해 이번 기획에서는 VSSH(Velocity+Struts+Spring+Hibernate)로 명명된 최초의 오픈소스 통합 배포판을 독자 여러분과 함께 개발해 나가고자 한다. 총 8회의 연재 중 1부는 VSSH의 근간을 이루는 VSSH 프레임워크의 개발에 초점을 맞추어 진행될 것이며, 2부는 완성된 VSSH 프레임워크를 이용해서 온라인 경매 프로그램을 개발하는 과정을 통해 다양한 오픈소스 도구들이 어떻게 활용될 수 있는지에 대한 가이드라인을 제시하게 될 것이다. 이를 위해 작은 포럼을 오픈했다. 방대한 주제를 짧은 지면에 다 소개할 수 없기 때문에 기사에서 미처 다루지 못한 내용들은 포럼을 통해 알려드릴 예정이므로 관심이 있는 독자는 꼭 방문해 이 프로젝트에 적극 참여해 주기 바란다.  나눌수록 깊어지는 게 어디 정 뿐이겠는가.

<화면 1> VSSH 포럼(http://java.techedu.net/phpBB2)

오픈소스를 이용한 프레임워크 개발 사례
사실 오픈소스 통합 배포판이란 용어가 사용된 적은 없지만 이 아이디어는 전혀 새로운 것이 아니다. 이미 국내외에서 이와 유사한 연구가 진행되고 있으며, 실무에 활용되고 있는 것도 많다. 여기서 잠시 이번 연재와 관련된 다양한 국내외 사례에 대해 살펴보도록 하겠다.

해외 사례, EJOSA와 OnJava
지난 달 본지에서 필자가 소개한 EJOSA(Enterprise Java Open Source Architecture)는 오픈소스 통합 배포판에 대한 직접적인 아이디어를 제공했다. EJOSA는 오픈소스만을 이용해서 구현된 J2EE 기반의 엔터프라이즈용 아키텍처이다. Enhydra와 JOnAs에서 동작하도록 설정되어 있으며, DB는 Firebiard DBMS를 사용한다. 개발 도구는 NetBeans를 추천하고 있고, 기본 프레임워크는 Velocity, AndroMDA, 세션 빈과 연동되는 Hibernate 기술을 사용하고 있다.

<그림 3> EJOSA의 구조도

EJOSA의 첫 번째 장점은 개발자가 오픈소스를 찾아다니는 수고를 덜어주었다는 점이다. EJOSA 내에는 앞에서 설명한 각종 툴과 프레임워크 외에도 Ant, XDoclet, JUnit, AspectJ, JDom, Lucene 등 개발에 필요한 각종 오픈소스들이 미리 설정된 채로 통합되어 있다. 개발자로 하여금 단지 매뉴얼에 나와 있는 대로 설정 파일을 수정하고, Ant를 실행하는 것만으로 필요한 도구들을 사용할 수 있게 도와준다. 두 번째 장점은 방법론과 예제, 경험이 포함된 풍부한 문서를 제공하고 있다는 것이다. 단지 각종 오픈소스들을 압축해서 배포하는 것이 아니라, 모델 중심의 개발 방법론을 EJOSA를 이용해서 실천하는 방법이 각종 도구의 사용법과 함께 친절하게 설명되어 있고, 그 방법론에 따라 개발된 각종 예제가 문서와 함께 공개되어 있다. 하지만 Enhydra나 JOnAs와 같이 EJOSA에 기본으로 탑재된 도구들은 국내에서 관심을 얻고 있지 못한 이질적인 것이었고, MDA라는 방법론 자체가 아직 국내에 도입되기에는 이른 감이 있었다.

때마침 오라일리가 운영하는 OnJava.com에서 「Wiring Your Web Application with Open Source Java」라는 기사가 등록되었다. EJOSA는 WAS나 개발도구와 같은 오픈소스 도구들을 중심으로 통합이 이루어진데 반해, OnJava에 소개된 내용은 별도의 프레임워크로 이미 널리 알려져 있는 Struts, Spring, Hibernate를 통합하고자 시도하고 있다.

<그림 4> Struts, Spring, Hibernate 프레임워크를 결합한 아키텍처 개요도

참고로 우리가 함께 개발하게 될 VSSH는 EJOSA의 아이디어를 기본 토대로 해서 국내 개발자들에게 친숙한 오픈소스 도구들이 구성에 포함될 것이며, OnJava.com에 소개된 것과 같이 유명 프레임워크들을 통합한 프레임워크가 제공될 것이다.

국내 사례, SAF와 JCF
국내에서 개발된 많은 프레임워크는 썬의 블루프린트에 포함된 WAF(Web Application Framework)와 아파치 자카르타의 Struts가 가장 많은 영향을 끼쳤다. SK C&C의 JGarnet이나, 컴포넌트베이시스의 CB*Framework와 같은 프레임워크 소개서에는 WAF와 Struts를 토대로 개발되었음이 명시되어 있다. 특히 올해 5월 KCSC(한국소프트웨어컨소시엄)의 'SW Architecture & Framework 개발 및 프로젝트 적용 사례 세미나'에서는 오픈소스 프레임워크를 결합하여 자사의 독창적인 프레임워크를 구현하고자 하는 시도가 보고되었다. 그 중에서 대표적인 2개의 사례에 대해 간단히 살펴보자.
처음 소개할 내용은 세림정보기술의 SAF(Selim Application Framework)이다. 세림은 초기에 디자인 패턴을 이용한 프레임워크를 자체 개발했으나, 높은 유지보수 비용으로 인해 오픈소스인 Struts를 활용하는 쪽으로 방향을 선회했다. 이것은 Struts가 발전하면 SAF도 함께 진화하는 것을 뜻한다. SAF는 기본적으로 <그림 5>와 같이 Struts를 활용한 파이프라인 아키텍처를 채택하고 있다.

<그림 5> SAF의 파이프라인 아키텍처

SAF의 특징은 디자인 패턴을 중심으로 Struts를 확장하여 WAF와 유사한 아키텍처를 지니고 있다는 것이다. SAF의 현재 버전은 뷰 처리를 Velocity 및 Tiles를 이용해서 구현하고 있고, XML에 기반한 DAO 패턴을 자체 구현하여 영속성 처리를 하고 있는데, 다음 버전에는 JSF와 다양한 O/R 맵퍼를 연동할 계획을 갖고 있다고 한다.

<그림 6> SAF의 최종 아키텍처

두 번째 소개할 내용은 대우정보시스템의 JCF(J2EE Core Framework)이다. JCF는 대우정보시스템의 J2EE 애플리케이션 개발을 위한 표준 애플리케이션 프레임워크로서, 분석, 설계, 구현, 테스트, 관리에 이르는 종단간(end-to-end) 개발 프로세스를 효과적으로 수행하기 위한 통합 프레임워크이다. 또한 J2EE 애플리케이션 개발의 전 공정에서 개발자들이 따라야 할 표준지침이기도 하다. JCF의 오픈소스의 활용 측면에서 주목할만한 측면을 많이 갖추고 있다.

<표 1> JCF의 구성

JCF의 구성에서 보듯이 JCF 역시 무게 중심은 오픈소스를 통합한 프레임워크 자체에 있다. 하지만 이클립스, Ant, JUnit, XDoclet 등의 오픈소스 도구들이 개발에 활용되고 있다는 점과 그것을 효과적으로 뒷받침하는 개발 표준 및 개발지침, 활용 경험 등이 문서화되어 가이드라인으로 제공되고 있다는 점에 주목해야 한다. 또한 프레임워크에서 Spring이 무게중심에 있다는 것도 특이한 점이다. Spring은 비즈니스 로직 처리에 강점이 많은 Struts와 같은 오픈소스 프레임워크이다. Spring 프레임워크는 3회 연재에서 자세히 다룰 것이므로 우선 Struts나 Hibernate와 같은 기존 기술과 경쟁적이지 않은 자연스러운 협력이 가능한 구조를 갖추고 있다는 것 정도만 알아두도록 하자.
지금까지 오픈소스 통합 배포판과 관련한 국내외 관련 사례들을 간단히 살펴보았다. 해외의 사례들은 오픈소스 도구의 활용에 많은 강점을 지니고 있고, 오픈소스 기술의 통합 자체에도 많은 관심을 쏟고 있다.

반면에 국내의 사례들은 주로 검증받은 상용 도구를 이용해서 CBD 방법론을 적용한 시스템 통합에 사용될 프레임워크에 관심이 집중되어 있음을 알 수 있다. 특히 Struts, Velocity 등의 프레임워크 통합과 관련해서는 외국에 뒤쳐지지 않은 많은 연구가 이미 진행되어 있고, 이러한 사례들이 2003년을 기점으로 폭발적으로 증가하고 있다는 사실은 기억해 둘만 하다. 이것은 자바 기반의 오픈소스 프로젝트들이 실무에 충분히 활용될 수 있을 만큼 안정화되고 있다는 걸 뜻하며, 사용 저변이 크게 확대되고 있음을 반증하는 것이기도 하다. 또한 각 기업의 발표 자료를 통해 공공, 금융, 제조를 비롯한 각종 e비즈니스 시스템 구축에 이미 다양한 오픈소스 기술들이 침투해 있다는 사실도 확인할 수 있었다. 덕분에 오픈소스 기술을 활용한 레퍼런스를 확보하는 작업이 그리 어렵지 않을 듯 하다.

오픈소스 통합 배포판 프로젝트 VSSH
앞서 얘기한 대로 VSSH는 지금부터 우리가 함께 만들어 나갈 오픈소스 통합 배포판의 프로젝트 이름이다. VSSH는 전체적으로 <그림 7>과 같이 구성된다. 지금부터 VSSH의 구성 요소들에 대해 간단히 알아보도록 하자.

<그림 7> VSSH의 구성

VSSH 프레임워크
VSSH의 가장 핵심적인 부분으로 Velocity, Struts, Spring, Hibernate로 구성된 프레임워크이다. 앞으로 4회에 걸쳐 이 부분을 집중적으로 다루게 될 것이다. J2EE 애플리케이션은 크게 프리젠테이션, 제어, 비즈니스 로직, 데이터 처리라는 4개의 레이어로 구성된다. 각각은 이미 독자적인 사용자 층을 확보하고 있는 오픈소스 기술들이지만, VSSH에서 Velocity는 사용자 뷰를 결정짓는 프리젠테이션 계층에서 사용되고, Struts는 제어 계층, Spring은 비즈니스 로직 계층, Hibernate는 데이터 처리 계층을 담당하게 될 것이다. VSSH 프레임워크는 적당한 계층에 각 기술을 단순히 나열하는 데 그치는 게 아니라 가장 효율적인 통합 방안을 함께 고민할 것이다. 2회에서는 Struts와 Velocity를 연결하는 방법에 대해 살펴보고, 3회에서는 Struts와 Spring을 결합하는 방법 및 Spring에서 비즈니스 로직을 처리하는 가이드라인을 제공할 것이다. 마지막 4회에서는 Spring과 Hibernate를 통합하는 방법과 그 기반 위에서 컴포넌트를 구성하는 방법을 살펴볼 것이다. 연재가 끝날 때쯤이면 이달의 디스켓과 포럼을 통해 VSSH 프레임워크 및 사용 가이드를 다운받을 수 있도록 하겠다.

VSSH 환경
VSSH 환경은 완성된 VSSH 프레임워크가 동작되는 운영 환경과 개발 환경으로 구성된다. 개발 환경은 이클립스와 관련 플러그인으로 구성되며, 그와 대응되는 NetBeans에 대해서도 소개될 것이다. 동작 환경은 아파치 웹 서버와 톰캣이 내장된 JBoss가 사용되며, 데이터베이스는 HSQLDB를 사용할 예정이다. 그 밖에 JUnit, Ant, CVS, XDoclet, log4j가 기본적인 개발 환경에 포함된다. 저작권에 문제가 없는 범위 내에서 각 도구 및 관련 플러그인은 미리 설정된 형태로 압축시켜 배포할 예정이며, 환경 설정을 끝낸 프로젝트 파일이 샘플로 포함될 것이다. VSSH의 나머지 부분은 2부에서 다루게 될 것이다.

Open CBD 방법론
CBD 방법론이라고 해서 거창한 걸 준비하고 있는 것은 아니다. 개발팀이 10～30명 수준이라고 가정하고, CBD96과 UML Component, 마르미 III를 토대로 가벼운 CBD 개발 프로세스를 정립해서 VSSH 사용에 대한 가이드라인을 제공하고자 한다. 여기에는 포함된 각 오픈소스 기술의 매뉴얼과 산출물 양식 및 적용 샘플, 컴포넌트 표준 스펙 및 코딩 규칙 등이 포함될 것이다. 이미 자사의 개발 방법론을 갖춘 팀에게는 매력이 없을 수도 있겠지만 VSSH를 이용하고자 하는 소규모 개발팀에게는 가장 필요한 내용일 것이다.

VSSH 활용 샘플
1부는 이론적인 설명이 많은 관계로 회원가입 및 로그인/아웃을 처리하는 간단한 예제를 가지고 진행할 것이다. 하지만 적당히 규모가 있는 샘플 애플리케이션이 없으면 VSSH가 완성되더라도 참조 모델이 없어 막막할 것이다. 따라서 2부의 내용은 VSSH를 이용해서 가칭 OpenAuction이라고 이름 지은 온라인 경매시스템 개발 과정을 따라가며 진행할 생각이다.

VSSH 프레임워크를 구성하는 각 기술의 선정 배경
VSSH를 준비하면서 가장 고민했던 부분은 서로 다른 장단점을 갖고 있는 수많은 오픈소스 도구들 중에서 어떤 것을 선택하느냐 하는 문제였다. VSSH는 특정 오픈소스 기술을 설명하려는 것이 아니라 오픈소스를 중심으로 SI 프로젝트가 진행되기 위한 가이드라인을 제공하는 것이 목적이기 때문이다. VSSH 프레임워크를 구성하는 각 요소 기술들은 각 영역별로 국내에서 가장 많이 알려진 것을 선정하기 위해 노력했다. 그 이유는 특별히 기술 지원을 약속할 업체가 없는 오픈소스 기술이기 때문에 참고할 자료가 많아야 유리하다고 판단했기 때문이다. 이 글을 읽고 있는 독자들도 이 연재에서 다루는 모든 기술을 짧은 기사를 통해 모두 익히겠다는 욕심은 버렸으면 한다(기사에서 다루지 못한 각 요소 기술에 대한 참고자료들을 아이마소와 포럼을 통해 꾸준히 등록할 수 있도록 노력할 계획이다). 그보다 각 기술이 어떻게 결합되어 시너지 효과를 발휘하는지, 그리고 어떻게 실제 프로젝트에 적용 가능한지를 중심으로 기사를 읽어 나가면 좋겠다. "난 Turbine의 기능이 더 뛰어나다고 생각하는데 왜 하필 Struts를 쓰는거야?"라든가, "OJB가 썬의 JDO 스펙을 준수하는데다 자카르타 프로젝트로 진행되는데 Hibernate를 포함시킨 근거는 뭐야?"와 같은 딴지는 사양하는 바이다. 필자는 자신 있게 무엇이 더 훌륭하다고 내세울 만큼 실력이나 안목이 뛰어난 사람이 아니다. 다만 지금 이 시기에 VSSH와 같은 시도가 꼭 필요하다고 생각되어 바쁜 일상을 쪼개 쥐어짜낸 한 웅큼의 용기를 손에 쥐고 다소 무모한 프로젝트를 시작한 여러분과 똑 같은 한 사람의 개발자일 뿐이다.

프리젠테이션 계층, Velocity
프리젠테이션 계층에 Velocity를 쓸 것인지를 두고 가장 많은 고민을 했다. 기존의 JSP에 JSTL이나 Struts 태그 라이브러리를 섞어 사용하는 것만으로도 충분히 로직과 분리된 뷰 개발이 가능하기 때문이다. 하지만 뷰는 개발자와 성격이 다른 웹 디자이너들과 공동 작업이 필요한 특수한 영역이기 때문에 드림위버와 궁합이 좋은 Velocity를 사용하기로 결심했다. 그로 인해 템플릿 엔진에 대한 개념을 이해해야 하고, 값 객체의 자동 맵핑을 위한 유틸리티 클래스 개발과 같은 추가적인 부담이 생겼지만 그것을 보상할 만한 충분한 이점이 있다고 믿는다.

제어 계층, Struts
제어 계층에 사용할 프레임워크를 Struts로 선정하는 것은 크게 어려운 일이 아니었다. Webwork2가 발표되었고, Turbine이나 Expresso와 같은 충분히 경쟁력 있는 프레임워크가 많이 존재하지만, 국내에서는 Struts가 확실한 입지를 굳힌 것 같다. 굳이 선정 배경을 이야기한다면, 많은 사용자 층에 의한 충분한 자료, 벤더들의 확실한 지원, 검증된 다양한 레퍼런스를 쉽게 구할 수 있다는 점이 Struts를 제어 계층에 사용한 이유다. 무엇보다 발생 가능한 다양한 문제들과 그 해결책이 이미 알려져 있어 다양한 프레임워크를 통합하고자 시도하는 VSSH 프레임워크의 안정성을 향상시키는 데 큰 도움이 되리라 생각한다.

비즈니스 로직 계층, Spring
비즈니스 로직 계층은 Spring을 사용할 것인지, 말 것인지를 결정해야 했다. EJB를 사용한다면 Spring을 사용하지 않고도 알려진 J2EE 패턴/EJB 패턴을 이용해서 WAS의 성능을 빌어 견고한 애플리케이션 개발이 가능하다. 하지만 EJB를 사용하지 않고 일반 자바 객체 POJO(Plain Of Java Object)만을 이용해서 개발할 경우까지 함께 고려한다면, 문제의 여지가 있었다. 또한 제어 계층의 Struts와 데이터 처리 계층의 Hibernate를 직접 연결하는 것은 자칫하면 계층간의 연결을 강하게 만들 위험이 있었으며, 컴포넌트 구현을 위한 기본 스펙을 만드는 것도 까다로웠다. Spring은 개발자인 Rod Johnson이 저술한 『Expert One-on-One J2EE Development without EJB』라는 책에 소개된 것처럼 EJB의 사용에 드는 비용을 줄여준다. Spring 프레임워크가 그 자체로써 경량급 컨테이너라고 불리는 이유는 EJB가 가지는 컨테이너의 의존성, 배포 비용을 줄여주기 때문이다. 이 점은 개발 도구와 WAS가 짝을 지어 사용되는 국내 개발 환경에서 Spring을 반드시 사용해야 할 이유가 되기에 충분했다. Spring은 WAS나 개발 환경, 연결된 다른 프레임워크에 대해 의존성이 낮은 비즈니스 로직을 개발해내기 위해 도입되었으며, 최근 관심을 끌고 있는 AOP(Aspect Oriented Programming)를 적용해볼 기회를 제공하기도 한다.

데이터 처리 계층, Hibernate
데이터 처리 계층에서 EJB 엔티티 빈은 처음부터 고려 대상에서 제외시켰다. 이는 EJB 2.0 스펙의 발표와 함께 욕심내어 진행한 프로젝트에서 엔티티 빈의 사용으로 인해 문제가 오히려 복잡해진 경험이 있었기 때문이다. 그 당시 CMP/CMR에 대한 개발 툴의 지원은 기대했던 것만큼 만족스럽지 못했고, EJBQL은 마치 미완성인 기술처럼 허점을 드러냈다. 결국 CRUD 처리를 위한 단순한 기능은 CMP 방식의 엔티티 빈으로 구현하고, 복잡하거나 성능이 중요한 부분은 JDBC를 사용해서 직접 DAO를 구성하는 방식으로 분할해서 구현한 다음, Business Delegate 객체를 만들어서 그 과정을 로직에 숨기는 것으로 만족해야 했다. 지금은 많은 부분이 개선됐지만, 그러한 경험은 자연스럽게 엔티티 빈의 대안 기술인 O/R 맵퍼에 관심을 두게 만들었다. 초기에는 JDO(Java Data Object) 스펙을 구현한 자카르타의 OJB와 Castor JDO를 고려해 보았다. 하지만 이클립스를 비롯한 통합개발환경의 지원이 미약해서 생산성이 떨어지는 문제가 있었다. 그래서 상용 제품과 비교해 기능적으로 뒤쳐지지도 않으면서, 다양한 기존 프레임워크와 연동이 쉽고 Hibern8IDE를 비롯한 각종 개발 도구가 공개되어 있는 Hibernate를 최종적으로 선택하게 되었다. 또한 Hibernate는 효율적인 개발을 돕는 풍부한 레퍼런스를 가지고 있으며, 커뮤니티의 지원도 훌륭했다. Hibernate의 사용은 추후 JDO의 구현이 활성화되더라도 O/R 맵퍼에 대한 이해를 바탕으로 쉽게 적응할 수 있는 장점도 갖추고 있다.

VSSH 제어 계층을 구성하는 Struts
이제 VSSH 프레임워크에서 모든 제어를 관리할 Struts에 대해 살펴보도록 하자. 프레임워크의 필요성이나, Struts에 대한 설치 및 활용 방법은 이미 널리 알려져 있으므로 생략하겠다. 기본적인 내용에 대해 도움이 필요한 독자는 VSSH 포럼을 통해 질문을 올려주기 바란다. 여기서는 Struts 그 자체보다 Struts 내에 적용된 디자인 패턴을 이해함으로써 프레임워크에서 제어가 이루어지는 기본적인 원리를 알아보도록 하겠다. 그 과정을 통해 Struts를 이용해서 다양한 응용을 시도할 수 있는 내공이 쌓이기를 바란다.

Struts 구현에 사용된 J2EE 패턴
<표 2>는 Struts 구현에 사용된 J2EE 패턴과 그 패턴이 구현된 클래스를 정리한 것이다.

<표 2> Struts에 사용된 패턴 및 그 패턴이 구현된 컴포넌트

여기서 가장 핵심이 되는 것은 Front Controller 패턴과 View Helper 패턴이 결합된 일종의 매크로 패턴인 Service to Worker 패턴이다.

Service to Worker 패턴
Service to Worker 패턴은 블루프린트에 소개된 Core J2EE Pattern의 하나로, Struts의 제어 과정을 이해하기 위해 반드시 학습해야 하는 기본 패턴이라고 할 수 있다. <그림 8>은 이 패턴의 클래스 다이어그램이다.

<그림 8> Service to Worker 패턴의 클래스 다이어그램

여기서 주목할 것은 클라이언트의 모든 요청이 예외 없이 Controller라고 이름 붙은 서블릿으로 전달되고 있다는 것이다. 이를 위해 web.xml에서 다음과 같이 *.do로 끝나는 모든 URL에 대해서 ActionServlet이 책임을 지도록 서블릿 맵핑을 설정해 줘야 한다.

<servlet>
    <servlet-name>action</servlet-name>
<servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
</servlet>
<servlet-mapping>
    <servlet-name>action</servlet-name>
    <url-pattern>*.do</url-pattern>
</servlet-mapping>

클라이언트의 요청을 처리하기 위한 중앙 집중적인 접근 포인트를 제공하는 이러한 설계 패턴을 Front Controller라고 부르는데, 이 점은 모델 2 방식의 J2EE 개발에 있어 가장 핵심이 되는 특징이다. *가 포함된 URL 패턴이 특정 서블릿과 연결되어 있다면 Front Controller 패턴이 적용된 것이라고 생각해도 좋을 것이다. Front Controller 패턴을 사용하면 시스템 서비스, 로그 기록, 보안, 뷰 관리, 페이지 이동 등의 모든 코드를 한 곳에서 관리하기 때문에, 코드의 중복을 방지할 수 있는 이점과 함께 뷰와 애플리케이션 로직을 분리시킴으로써 코드의 유지 보수가 쉬워지는 이점이 있다. Front Controller는 JSP로 개발하는 JSPFront 방식과 서블릿으로 개발하는 ServletFront 방식으로 나뉘는데, 서블릿을 Front Controller로 사용하는 것이 일반적이다.

Controller
Struts에서 요청을 처리하는 시작점이 되는 것은 ActionServlet인데, 내부적으로 ActionServlet의 동작은 RequestProcessor의 process() 메쏘드를 실행시킴으로써 이루어진다. 따라서 Controller를 확장할 때는 ActionServlet을 직접 확장하는 것보다 RequestProcessor를 확장한 새로운 클래스를 만들고, struts-config.xml에서 controller 요소에 processorClass 속성을 지정해서 변경하는 것이 좋다. RequestProcessor는 다음과 같은 15 단계를 통해 동작한다.

01. processPath() : ActionMapping에서 사용할 URL Path 처리
02. processLocale() : 국제화 지원을 위한 언어 로케일 처리
03. processContent() : 기본 문서 타입 지정(초기값 : text/html)
04. processNoCache() : HTTP 헤더를 설정해서 요청이 캐시되는 것을 막음
05. processPreprocess() : 기능 확장을 위한 예비 메소드
06. processMapping() : 앞에서 구한 Path를 이용해서 실행할 ActionMapping 결정
07. processRoles() : 보안을 위한 접근 제어 목적으로 설정된 Role 확인
08. processActionForm() : ActionMapping과 연결된 폼빈(ActionForm) 초기화
09. processPopulate() : 폼 빈에 값을 채워넣음
10. processValidate() : 폼 빈의 입력값에 대한 유효성 체크 - validate() 호출
11. processForward() : 액션 맵핑에 forward 지정이 된 경우 해당 파일로 포워드
12. processInclude() : 액션 맵핑에 include 지정이 된 경우, 실행 결과를 응답에 포함
13. processActionCreate() : Action 클래스 인스턴스 생성
14. processActionPerform() : Action 클래스 실행 - execute() 메쏘드 호출
15. processActionForward() : Action의 실행결과인 ActionForward에 의해 제어 이동

이 과정 중 제어의 이동과 관련된 부분은 01, 06, 11, 13～15의 6개 과정이다. 다음과 같이 struts-config.xml이 구성되어 있다고 가정하자(이처럼 FrontController에서 제어를 관리하는 데 필요한 자원 맵핑 정보를 설정 파일을 통해 논리적으로 유지하는 것을 Logical Resource Mapping 전략이라고 한다). http://java.techedu.net/login.do와 같이 호출될 경우 첫 번째 단계인 processPath()에서 URL과 *.do가 제거된 login이 path로 결정된다. 결정된 path 정보를 가지고 6번째 단계인 processMapping()에서 <action-mappings>에 설정된 action을 결정해서 ActionMapping 클래스를 만들게 된다. 만일 처리 요청이 단순 포워드라면, 11번째 단계를 통해 Action을 통하지 않고 바로 해당 JSP 파일로 포워드된다. 그렇지 않다면 13번째에서 15번째 과정을 통해 Action이 만들어지고, 실행되며 그 결과인 ActionForward에서 지정한 곳으로 결과를 포워드시키는 것이다.

<struts-config>
    <global-forwards>
        <forward name="main" path="/main.jsp" />
    </global-forwards>
    <action-mappings>
        <action path="/main" forward="/main.jsp" />
        <action path="/login" type="com.seal.LoginAction" scope="request" input="login.html">
            <forward name="admin" path="/member.jsp" />
        </action>
<action-mappings>
</struts-config>

Dispatcher
Struts는 네비게이션과 뷰 관리를 담당할 Dispatcher 컴포넌트로써 Action 클래스를 사용하는데, 요청에 관련된 세부 사항들을 Action에게 알리고 Action이 응답을 책임지도록 위임한다. 이것을 FrontController의 "Command and Controller" 전략이라고 부른다. 이 전략은 기존에 잘 알려진 Command 패턴에 Front Controller와 결합한 제어의 이동 역할을 더한 것이라고 볼 수 있다.

Helper
Service to Worker 패턴에서 Dispatcher는 Helper를 사용하여 뷰 역할을 수행하는 JSP로 데이터를 보낸다. 비즈니스 데이터를 자바빈즈 형태의 뷰 컴포넌트로 만들어 JSP로 넘기는 이러한 구조를 View Helper 패턴이라고 한다. Struts에서는 이러한 Helper 역할을 ActionForm이 담당하고 있다. 지금까지 설명한 Service to Worker 패턴의 동작 순서를 시퀀스 다이어그램으로 표시하면 <그림 9>와 같다.

<그림 9> Service to Worker 패턴의 시퀀스 다이어그램

Service to Worker 패턴의 동작 과정을 코드로 이해하고 싶다면, Manning에서 출판된 『Web Development with JSP』라는 책의 9장에 나와 있는 FAQ 시스템 구축 예제를 살펴보길 권하고 싶다. FAQ 예제에는 Command and Controller 전략이 적용된 Service to Worker 패턴을 구현한 서블릿 방식의 FrontController가 포함되어 있다. 또한 웹의 동기화로 인한 약점을 극복할 수 있도록 MD5 알고리즘이 적용된 Synchronizer Token 패턴도 구현되어 있다. Manning의 책은 인포북에서 번역되어 한글판으로도 나오고 있으므로 꼭 한번 예제를 따라해 보기 바란다.

독자의 참여가 프로젝트 성공의 열쇠다
‘오픈소스를 이용한 시스템 통합’이라는 주제로 기사를 작성해 달라는 부탁을 받은 것이 정확히 3개월 전이였던 걸로 기억한다. 즐거운 도전이 될 것 같은 생각에 무심코 시작한 일이 관련 자료를 조사하고 기획을 다듬어나가는 과정에서 부담이 될 만큼 큰 프로젝트로 발전해 버리고 말았다. 필자는 오픈소스 기술이 온 세상을 뒤덮어야 한다고 주장하는 광신도는 아니다. 독자 여러분과 마찬가지로 지금껏 J빌더나 웹로직 워크˜