프레임워크 활용전략

엔터프라이즈 자바 기반의 애플리케이션 개발을 업으로 살아가는 개발자라면, 지난 자바원 2006 컨퍼런스를 지켜보며 고민에 빠졌을 것이다. 포화 상태에 이른 것만 같은 수많은 기술적 대안의 홍수 속에서 과연 무엇을 선택해야 하고 또 어떻게 적용할 것일까? 3부에서는 실무에서 애플리케이션 프레임워크를 구축하는 과정을 소개함으로써, 프레임워크 기반 개발이 갖는 장점과 가능성을 통해 개발자들이 안고 있는 고민을 해결할 수 있는 가이드라인을 살펴보고자 한다.

IT 분야에서 사용하는 용어는 여러 가지 의미를 가지거나 모호한 단어들이 많기 때문에 정확한 용어의 의미를 이해하지 않고서는 글의 내용을 올바로 이해하기 힘들다.

GoF의 디자인 패턴으로 유명한 랄프 존슨(Ralph Johnson) 교수는 프레임워크를 “소프트웨어의 구체적인 부분에 해당하는 설계와 구현을 재사용이 가능하게끔 일련의 협업화된 형태로 클래스들을 제공하는 것”이라고 정의하였다.

프레임워크는 라이브러리와 달리 애플리케이션의 틀과 구조를 결정할 뿐 아니라, 그 위에 개발된 개발자의 코드를 제어한다. 프레임워크는 구체적이며 확장 가능한 기반코드를 가지고 있으며, 설계자가 의도하는 여러 디자인 패턴의 집합으로 구성되어 있다.

프레임워크는 그 정의만큼이나 분류 방식도 다양하다. 기술/도메인에 의해 웹 개발에 사용되는 프레임워크들을 구별하면 다음과 같다.

① 웹MVC 프레임워크

② Persistent/ORM 프레임워크

③ Configuration 프레임워크

④ 테스팅 프레임워크

⑤ 로깅 프레임워크

⑥ 보안 프레임워크

⑦ 도메인 프레임워크(보험, 회계, 제조, 고객관리, 유통, 콘텐츠 관리 등)

⑧ 종합/애플리케이션 프레임워크

한편, 프레임워크는 개발방식에 따라 자체 개발 프레임워크, 상용 프레임워크, 그리고 오픈소스 프레임워크로 구별하기도 한다.

프레임워크 도입의 허와 실

프레임워크를 도입했을 때의 장점은 이루 헤아릴 수 없을 만큼 많다. 프레임워크는 코드의 중복 및 코드 내의 복잡성을 제거함으로써 심플한 코드의 개발을 가능하게 한다. 또한 프레임워크가 가진 설계 구조와 의도가 자연스럽게 적용되어, 전체 애플리케이션이 아키텍처를 따르는 좋은 설계를 유지하도록 돕는다.

프레임워크는 개발을 쉽고 편하게 해준다. 프레임워크의 내부는 복잡할 수 있지만, 그 프레임워크를 사용하는 방법은 쉽기 때문이다.

잘 설계된 프레임워크는 표준화된 심플한 코드(Simple &Clean Code)의 작성을 유도함으로써 자연스럽게 개발 생산성을 높여준다. 또 반복된 작업을 단순화시켜 애플리케이션의 요구사항을 구현하는데 집중할 수 있도록 돕는다. 이와 같은 장점으로 인해 자바EE 분야에서 프레임워크는 성공적인 프로젝트 수행을 위한 필수 조건으로 자리 잡은 지 오래다.

그러나 프레임워크의 도입에 장애물로 작용하는 요인도 많다.

개발팀에게 익숙하지 않은 프레임워크의 도입은 개발팀을 교육해야 하는 부담도 있을뿐더러 새로운 기술에 대한 적응 시간을 필요로 한다. 또한 프레임워크가 요구하는 기술 요구 조건을 개발팀의 수준이 따라가지 못할 때에는 오히려 개발 생산성이 저하된다. 뿐만 아니라 의도와는 달리 질 낮은 쓰레기 코드를 양산할 위험이 있다.

개인적인 야망이나 실력 과시의 목적으로 최신/고급 기술의적용에 집착하는 권위적인 아키텍트들에 의해 현장에서 검증되지 않은 최신 기술이 유행처럼 마구잡이로 도입된다면, 프레임워크는 개발을 지연시키는 최대의 적이 될 수도 있다. 적절한 평가나 검증 과정을 거치지 않은 기술의 도입은 기술 자체의 결함이나 제품의 버그로 인해 개발이 지연될 수 있기 때문이다.

어떤 것이 한국의 개발 문화에 맞는 최선의 프레임워크인가 하는 질문에 대한 정답은 없다. 프로젝트의 성격, 규모, 투입되는 인력 등 모든 조건이 동일한 프로젝트는 없다. 다만 조건에 따라 정답이 달라지는 탓이다. 하지만, 한 가지 확실한 것은 좋은 프레임워크는 개발자로 하여금 즐겁게 일할 수 있도록 도와준다는 사실이다.

적절한 비유가 될지 모르겠지만, 필자는 애플리케이션과 프로그래밍의 관계가 마치 자식과 부모의 관계와 같다는 느낌을 자주 받는다. 잘 설계된 프레임워크는 내가 내 아이에게 되어 주고 싶은 좋은 부모의 모습과 닮아 있다. 프레임워크가 지향하는 기술구조와 철학이 애플리케이션에서 드러날 수 있어야 한다.

기계가 대신할 수 있는 복사/붙이기 식의 개발이 아닌 사람만이 할 수 있는 애플리케이션 로직의 개발에 집중할 수 있도록 도와주어야 한다. 또 애플리케이션이 프레임워크에 종속되는 일이 없도록 해야 한다. 개발자들이 특정 프레임워크가 아닌 좋은 프로그래밍 기법에 관심을 가질 수 있도록 자연스레 유도할 수 있어야 한다.

프레임워크 도입 전략

J2EE 개발의 초창기에는 상당수의 업체들이 자체적으로 프레임워크를 개발했다. 하지만, 자체 개발 방식의 프레임워크는2006 자바원 컨퍼런스에서 발표된「엔터프라이즈 자바 기반의 애플리케이션 개발을 망치는 10가지 방법」의 다섯 번째 항목에 자리했을 정도로 위험한 일이다.

해당 세션을 발표한 카메론 퍼디(Cameron Purdy)는 자체적으로 프레임워크를 개발하려는 생각이 들 때마다, 스스로에게 자신이 프레임워크를 개발하는 비즈니스를 하고 있는지 물어보기를 권하고 있다.

프레임워크의 개발은 매우 힘들고 높은 비용을 수반하는 작업이며, 이미 수없이 많은 뛰어난 프레임워크들이 개발되어 있다.

불필요하고 성공 가능성이 낮은 작업에 시간을 쏟을 필요가 없다는 뜻이다. 물론 우리에게 주어진 문제를 해결하기 위한 최적의 프레임워크는 존재하지 않을지도 모른다. 그러나 기존의 잘 알려진 프레임워크는 오랜 기간 사용되며 축적되어온 경험을 바탕으로, 여러분이 직접 개발했을 때 필연적으로 수반되는 시행착오를 줄인 정제된 형태라는 점을 기억해야 한다.

그렇다면 우리에게 주어진 과제는 무엇일까? 우리가 해야 할 일은 크게 도입 결정을 위한 프레임워크의 평가 및 검증, 애플리케이션 프레임워크 구축을 통한 추상화이다.

현재 자바를 이끌어 가고 있는 두 기둥은 JxE(JSE,JEE)와 오픈소스 기술로 이들은 엔터프라이즈 자바 시스템 개발에 있어서 핵심적인 역할을 담당하고 있다. 자바는 오픈소스 기반의 웹MVC(Mobile View Controller) 프레임워크만 150여 개에 이를 정도로 다양한 분야의 방대한 제품군을 자랑한다.

하지만 이처럼 무수히 많은 프레임워크 중에서 뛰어난 품질과 지속적인 개발능력을 가진 프레임워크는 매우 적다. 제품 수준에 다다르기 전에 사장되는 프레임워크가 대부분으로 현장에서 적용되고 검증되는 제품이 매우 적다는 뜻이다.

잘못된 프레임워크의 도입이나, 필요한 프레임워크를 도입하지 않아서 생기는 피해는 크기 때문에, 다양한 제품을 신중하게분석/검토할 필요가 있다. 빠르게 발전하는 기술 흐름을 고려하지 않고, 레퍼런스의 개수만으로 프레임워크를 평가하는 것은 옳지 않다. 또한 프레임워크가 지니고 있는 기능적인 관점에서만 접근하는 것도 충분하지 못하다.

프레임워크는 무엇보다 광고/홍보가 아닌 TSS나 포럼, 블로그와 같은 개발자 커뮤니티를 통한 정보 수집과 자체적인 검증 전략을 필요로 한다.

애플리케이션 프레임워크 구축

JEE 기반 애플리케이션 개발에서는 일반적으로 다양한 기능과 목적을 가진 한 개 이상의 프레임워크를 사용한다. 하지만 프레임워크 간의 호환성이나, 배타성, 영향력 등을 고려하면, 여러 개의 프레임워크가 원활하게 조합되도록 하는 것은 쉬운 일이 아니다.

JEE 아키텍처를 구성하는 각 계층별로 선정된 프레임워크를 나열하는 것(예: SiteMesh + Struts + Spring + iBatis)에 그치는 단순 프레임워크의 조합은 애플리케이션 구조를 필요 이상으로 복잡하게 만들 수 있다. 보다 효과적으로 프레임워크를 활용하려면 애플리케이션이 프레임워크를 사용하는 일관적인 틀(framework)을 만들어 줘야 한다. 애플리케이션 레벨의「프레임워크를 위한 프레임워크(Framework of Frameworks)」가 필요하다는 뜻이다. 여기에서는 이를 애플리케이션 프레임워크(Application Framework)라고 표현하고자 한다.

Application Framework = Framework of Frameworks

애플리케이션 프레임워크는 도메인 영역 또는 개발팀의 특성에 적합한 형태로 조합된 서브 프레임워크를 사용하는 표준화된 패턴(프레임워크 사용 패턴)을 제공해야 한다. 또 필요에 따라 프레임워크의 확장 또는 추가 개발도 요구된다. 애플리케이션 프레임워크를 구축하는 과정을 일반화시키면 다음과 같이 7단계절차로 표현할 수 있다.

1단계: 애플리케이션의 특징/요구사항/제한 조건 파악

애플리케이션 프레임워크를 구성하는 첫 단계는 개발할 애플리케이션의 기능적/비기능적 요구사항을 파악하는 것이다. 그중에서도 특히 신중히 고려되어야 할 것들을 정리하면 다음과 같다.

◆성능 요구조건, 도메인과 로직의 복잡도

◆사용 기술의 제약, 환경/OS/서버/JDK Version

◆통합되어져야 할 시스템

◆개발팀의 수준/특성/구성

◆개발규모, 확장성, 유연성

2단계: 요구조건을 충족하는 후보 프레임워크 선정 및 검증

웹 MVC, 비즈니스, 트랜잭션, 영속성 처리, 설정, 리모팅, 보안, 로깅, 테스팅, 국제화/지역화 등 애플리케이션이 필요로 하는 각 기능별로 후보 프레임워크를 선정하고 검증한다. 이 때 주의할 점은 다양한 조합 구조를 검토해 봄으로써, 프레임워크 간의종속성 및 호환성을 점검해 보아야 한다는 것이다. 또한 특정 기술에 얽매이지 않는 유연한 구조를 통해, 이후의 기술 변화에 따른 프레임워크의 변경으로 인한 영향력을 최소화 할 수 있는 지도 살펴보아야 한다.

3단계: 개별 프레임워크 기능 확장

각 영역별 프레임워크의 선정이 끝나면 필요한 기능들을 프레임워크의 확장 기능을 활용해서 커스터마이징한다. 확장성이 떨어지는 프레임워크의 코어 소스를 수정할 경우, 버전 업그레이드에 어려움이 있을 수도 있다. 오픈소스 프레임워크를 사용하는 경우 재배포의 의무가 있을 수도 있으니 라이선스를 꼼꼼히 검토해 보아야 한다.

4단계: 상위(High-Level) 추상계층 도입

분명한 이유와 효과에 대한 확신이 없는 추상계층의 도입은 바람직하지 않다. 하지만 애플리케이션이 하위 프레임워크를 개별적으로 사용하는 것보다는 추상적인 계층을 통해서 접근하는 것이 유리한 경우, 애플리케이션의 필요에 따라 두 단계 이상의 계층에 독립적으로 접근하는 것이 가능할 수도 있다.

5단계: 검증용 샘플 애플리케이션 구현

애플리케이션 프레임워크는 테스트 커버리지가 100%에 이를 정도로 단위 테스트, 통합 테스트를 철저히 작성하고 자동화해야한다. 프레임워크의 버그는 일반 애플리케이션의 버그보다 훨씬 더 큰 문제를 야기할 수 있기 때문이다. 애플리케이션 프레임워크를 구성하는 하위 프레임워크를 업그레이드 하고자 할 때 이전버전과의 호환성을 체크할 수 있도록 작성한다. 애플리케이션 프레임워크를 검증하기 위한 샘플 애플리케이션은 단순한 예제 차원의 샘플 코드에 만족해선 안 된다.

최소한 개발할 시스템의 한 단면(Vertical Slice)을 이루는 대표적인 유즈 케이스를 다루는 애플리케이션이어야 한다. 본격적인 개발에 들어가서 뒤늦게 발견된 유즈 케이스들로 인해 애플리케이션 프레임워크가 자주 변경된다면, 개발팀은 혼란에 빠져 애플리케이션 프레임워크의 사용으로 인해 얻게 된 생산성과 품질을 스스로 포기할 지도 모른다.

6단계: 애플리케이션 프레임워크 평가

샘플 애플리케이션을 통해 단계 1에서 도출된 요구사항에 대한 해답을 애플리케이션 프레임워크가 제공해 주는지에 대해 평가한다. 이때 특히 주의 깊게 검토해야 할 부분은 다음과 같다.

◆ 심플한 코드로 작성 되는가

◆ 필요로 하는 충분한 성능을 가졌는가

◆ 애플리케이션 코드의 통일성이 있는가

◆ 프레임워크나 기술에 어느 정도 종속적인가

◆ 개발생산성이 뛰어난가

◆ 학습 난이도가 너무 높지 않은가

개발 프로세스 정립 및 문서화

마지막으로 애플리케이션 프레임워크를 바탕으로 샘플 애플리케이션을 개발하는 과정을 통해 정립된 개발 프로세스와 애플리케이션 프레임워크의 사용법을 문서화한다. 이 과정에서 주의할것은 프로세스를 위한 프로세스, 문서를 위한 문서가 되지 않아야 한다는 점이다.

7단계: KAF를 활용한 사례 연구

KAF(KAIST Application Framework)는 위에서 언급한 일곱 가지 단계를 통해 개발되어, 현재 카이스트 학사시스템 개발에 사용되고 있는 오픈소스 중심의 애플리케이션 프레임워크이다. JDK 5.0 및 표준 J2EE 서비스를 기반으로 하며, 각 계층 별로 요구사항을 만족하는 오픈소스 프레임워크들이 사용되고 있다. (SpringFramework IoC/DI/AOP/AspectJ, Hibernate/Annotation, Junit/EasyMock/Spring Mock, Log4J, Axis, DWR, SpringMVC, JSP/JSTL, Sitemesh, Acegi SecurityFramework 등)

각 계층에 사용된 오픈소스 프레임워크를 조합하기 위한 기술로 Spring IoC가 사용되었다. Generic DAO, Generic Enum, Hibernate Generic UserType, SpringContextController,SpringBind Custom Tag, Grid/Tree/Tab Control, ClusteredCache Framework, Paging/Order Framework, AjaxFramework, WebService/Remoting 등의 프레임워크 확장이 사용되었다.

KAF 애플리케이션 스택의 구조는 <그림 3>과 같다. (회색으로 표시된 부분이 표준 J2EE 기술/오픈소스 프레임워크이고, 검은색으로 표시된 부분이 각 계층별로 확장된 KAF이다. 개발자들은 KAF를 바탕으로 파란색으로 표시된 도메인 객체와 컴포넌트를 개발하도록 설계되어 있다.) 개발에 필요한 입력 파일은 ERD를 토대로 작성된 도메인 모델 관계 다이어그램과, 화면과 업무 로직이 포함된 개발사양서가 전부이다.

지금부터 KAF를 토대로 해서 애플리케이션 프레임워크가 어떻게 개발 생산성을 향상시킬 수 있는지에 대한 사례를 살펴보도록 하자.

● Spring + Hibernate + Generic/Annotation?

프레임워크의 확장 방법은 크게 기존의 프레임워크에 없는 공통 기능을 수평적으로 확장하는 방법과, 반복되는 작업이나, 복잡한 처리 과정을 감추고 확장성을 높이기 위해 추상화된 계층을 프레임워크의 위에 얹는 수직적 확장 방법으로 나뉜다.

KAF의 기반이 되는 스프링(Spring) 프레임워크는 크게 네 가지의 기능 확장 방법을 제공한다. 먼저, 잘 설계된 인터페이스 기반의 API를 기반으로 구현 클래스를 만들어 DI(DependentyInjection)를 이용하는 방법을 들 수 있다.

그 외에 AutoProxing이나 2.0 버전에 추가된 AspectJ Weaving과 같이 AOP를 이용하는 방법, 다양한 서비스를 추상화 시킨 탬플릿을 이용하는 방법과 다른 프레임워크와의 연동을 빈(Bean) 형태로 노출하는 어뎁터(Adapter) 패턴을 이용하는 방법이 있다.

스프링은 하위 버전과의 호환성을 위해 아직도 JDK 1.3 버전을 사용하고 있다. 지금부터 소개할 내용은 KAF의 도메인 모델과 DAO를 개발하는 과정이다. 이 과정에서 어노테이션(Annotation)과 제네릭(Generic) 기능을 활용해서 조합 프레임워크의 기술 배경인 자바SE 5와 자바EE 5의 구조에 맞춰 스프링의 기능을 재구성하는 방법을 살펴볼 것이다.

● 도메인 모델

KAF는 영속성 처리를 위해 널리 알려진 오픈소스 O/R 맵핑프레임워크인 하이버네이트를 사용한다. KAF의 POJO(PlainOld Java Object) 기반 도메인 모델은 풍부한 표현력을 갖춘 어노테이션 기반의 도메인 모델(Rich/Annotated Domain Model)로써, 단순히 getter/setter만을 지니고 있는 Anemic 모델이 아니다.

해당 도메인에 포함되어 있어야 할 비즈니스 로직을 포함하며, 전통적인 하이버네이트 설정XML 파일이 아닌 어노테이션을 이용해서 O/R 맵핑 정보를 다룬다.

기존의 EJB(Enterprise Java Bean)가 가지고 있던 많은 문제점에 대한 해결 의지를 보이며 최근 소개된 EJB3에 대한 전망은 그다지 밝지 못한 듯하다. TSS에서 엔터프라이즈 자바 기술의 미래라는 이름으로 진행된 토론에서 로드 존슨은 6~700 페이지에 이르는 EJB3의 복잡한 스펙을 비판하고 나섰다.

심지어 왜 스프링 없이 JEE 개발을 진행하느냐며 되묻는 사람들까지 생겨나 스프링을 중심으로 불붙기 시작한 POJO 기반의 프로그래밍 모델에 대한 지지가 꺾일 기미를 보이지 않기 때문이다. 기술적으로도 특정 타입의 클래스만 지원하는 DI나 인터셉터를 이용한 매우 제한적인 AOP 기능 등 EJB3에게 후한 평가를 내리기가 쉽지 않다. 하지만 기존의 EJB 기술에서 분리된 CMP(Container-Managed Persistence) 기술인 JSR220, JPA(JavaPersistence API)는 많은 관심을 받고 있다.

JPA는 EJB3에서 CMP 엔진이 완전히 분리되었음을 의미하며, WebLogic EJB + Hibernate 또는 WebSphere CMP 엔진 + 별도의 JMS 엔진 등과 같이 보다 자유로운 기술 선택이 가능해짐을 뜻한다. 하이버네이트는 JPA의 설계에 참여하면서 JPA와 일치되는 부분은 호환성을 고려해 그대로 사용하고 있다.

따라서 하이버네이트에서 사용되는 어노테이션은 크게 javax.persistence로 시작하는 JPA의 것과, org.hibernate.annotations로 시작하는 하이버네이트의 어노테이션 확장으로 나뉜다. KAF는 이후 JPA를 지원하는 다른 CMP 엔진으로의 전환이 필요할 경우를 대비해 JPA의 어노테이션을 사용하고 있다.

<리스트1>의 어노테이션 중 @ColumnInfo는 KAF에서 추가한 것으로 도메인 모델 클래스 사양서를 자동 생성하기 위한 것이다. KAF를 이용한 방법론에서는 불필요한 문서 작업을 최소화하기 위해, 프로젝트 지식을 Confluence라는 엔터프라이즈 Wiki 시스템을 통해 관리하고 있으며 산출물이 필요할 때마다 워드나 PDF 등으로 변환해서 제출한다.

테이블 정의서와 유사한 도메인 모델 사양서는 DomainModelSpecGenerator라는 유틸리티를 Reflection API를 사용해 개발하여, 필요할 때마다 API 문서와 함께 자동 생성해서 사용하고 있다. @ColumnInfo는 이 중 설계자가 직접 기술해야 하는 한글명이나 관련 코드, 설명 등의 정보만을 입력하도록 하는 목적으로 사용되고 있다.

● GenericDao / GenericDaoHibernate

자바 개발자라면 누구나 이클립스 창을 두 개로 나누어 아래에 참조 코드를 놓고, 전체 코드를 복사한 다음 특정 부분만을 변경해서 저장하는 지겨운 반복 작업을 수행해 본 기억을 갖고 있을 것이다. 그러한 반복 작업을 강요하던 가장 대표적인 구성 요소가 CRUD를 수행하는 DAO(Data Access Object)의 개발이다.

스프링이 제공하는 HibernateDaoSupport에 의해 비록 많은 불편함을 제거되었다고는 하지만, 반복되는 CRUD 코드를 피할 수는 없다. 그래서 개발한 것이 자바5의 어노테이션 기능을 활용해서 HibernateDaoSupport를 확장한 GenericDao와 GenericDaoHibernate이다.

GenericDao/GenericDaoHibernate를 이용한 DAO 개발은 신중하게 선택된 스프링의 기능을 토대로 어노테이션의 기능을 빌어 확장한 KAF의 DAO 계층으로 인해 이전과는 비교할 수 없을 만큼 간편해 졌다.

<리스트 4>와 <리스트 5>는 앞에서 소개한어카운트(Account) 모델에 대해 완벽한 CRUD를 수행하는 완전한 DAO지만, 인터페이스와 구현을 모두 합쳐 단 일곱 줄의 코드로 이루어져 있다. 이 밖에 DAO를 개발하기 위해 개발자들이 겪어야 하는 수고는 KAF가 제공하지 않는 복잡한 검색 기능이필요할 경우 스프링의 HibernateDaoSupport 기능을 활용해서 추가하는 것뿐이다.

● KAF를 이용한 DB 마이그레이션

이제 KAF에서 DB 마이그레이션을 어떻게 처리하고 있는지 살펴보자. DB 마이그레이션 작업은 DB 전문가나 마이그레이션 대행업체 또는 상용 툴을 사용하여 프로젝트 개발 초기에 신속히 진행되어야 하는 만만치 않은 규모의 작업이다.

기존의 작업 방식은 업무 분석과 동시에 리거시 DB의 스키마 분석을 통해 새로운 DB에 맞는 SQL 스크립트를 생성하여 마이그레이션을 진행한다. 이 기종 DB로 데이터를 이관하려면 각 DB간의 SQL 호환성 문제부터 데이터 검증, 튜닝 등 신경 써야 할 부분이 많이 존재한다.

현재 진행 중인 프로젝트는 개발 시스템을 위해 별도의DB관리자를 배치할 수 없는 상황이었으며, 개발 초기 변경의 여지가 많았으므로 테스트용 DB 서버를 별도로 구축하지 않기로 결정된 상태였다.

이런 상황에 대한 대처로 우리는 사용하기 쉽고 가벼운 PostgreSQL을 각 개발자 PC에 설치하고, 필요한 DB 마이그레이션을 직접 수행하기로 결정했다.

시스템을 오픈했을 때 사용하게 될 Sybase와의 호환성은 Hibernate의 dialect만 변경해 주는 것으로 간단히 해결할 수 있기 때문에 굳이 테스트용 DB 서버를 고집할 이유도 없었다. (참고: 공통 코드나 우편번호와 같이 엑셀 파일로부터 마이그레이션 작업을 수행해야 하는 경우는 POI의 HSSF API를 토대로 Excel 처리를 전담할 유틸리티를 KAF에 추가함으로써 처리하였다.) DB 마이그레이션에 앞서 처리되어야 할 선행 작업은 다음과 같다.

◆ 모델 설계 : 업무분석을 통한 모델링

◆ 리거시 DB에서 모델 설계에 따른 필요한 데이터 추출을 위한 SQL작성

대개의 마이그레이션 작업은 프로시저를 작성하여 데이터를 이관하는 형태지만 KAF에서는 리거시 시스템의 데이터를 읽어오는 모듈은 SQL을 쉽게 활용하기 위해 스프링의 SimpleJdbcDaoSupport를 활용하였다. 리거시 데이터를 신규 DB에 저장하는 처리는 앞에서 설명한 GenericDao를 이용했다. 이제 기관 테이블의 예제를 마이그레이션 하는 과정에 대해 좀 더 자세히 살펴보자.

- 리거시 데이터 가져오기

스프링에서 제공하는 SimpleJdbcDaoSupport 클래스의 콜백메소드를 이용하여 기존 리거시 데이터를 List>형태로 담아온다.

- 데이터 맵핑/등록

리스트 형태로 담아온 리거시 데이터를 신규 시스템의 도메인모델에 정확히 맵핑시켜 저장한 뒤에, GenericDao를 확장하여 개발한 DAO를 사용해서 저장한다.

- 애플리케이션 작성

우선순위에 따라 DB 마이그레이션을 수행할 애플리케이션을 작성한다.

- 마이그레이션 실행

엑셀 정보 마이그레이션과, 리거시 DB 마이그레이션을 자동으로 실행시켜줄 Ant 스크립트를 작성하여, 누구나 클릭 한번으로 마이그레이션을 실행할 수 있도록 준비한다.

● Context 프레임워크의 개발 및 스프링 MVC 확장

Context 프레임워크는 애플리케이션 정보를 일관된 방법으로 처리하기 위해 개발한 것이다. Context에 포함되는 정보는 로그인 사용자 정보와 권한, 검색 파라미터, 참조 파라미터, 그리드처리를 위한 페이지 정보와 정렬 순서, 코드와 같은 공통 레퍼런스 등이다.

KAF는 웹 MVC 프레임워크로 스프링 기반 구조의 장점을 가장 잘 활용할 수 있는 스프링 MVC를 채택하고, Context를 활용하여 컨트롤러와 UI 태그, 테스트 슈트 등을 확장해서 사용하고 있다. 이 부분의 구현은 상당히 복잡하기 때문에 지면 관계상 그 사용 과정만 간단히 소개하고자 한다.

KAF를 이용해서 학사관리시스템을 구현했다. 프로젝트를 진행하면서 고객으로부터 전달받은 핵심 요구사항은 오픈소스 기반, 표준 웹 준수, 웹 개발 경험이 없는 C/S 세대 전산실 직원이 쉽게 유지 보수할 수 있을 것의 세 가지였다.

처음 두 가지의 요구사항이야 충분히 환영할 만한 것이었지만, C/S 스타일에 익숙해진 고객의 눈높이에 맞는 UI를웹 표준을 준수하면서 그 흔한 액티브 X 컴포넌트 하나 사용하지 않고, 웹 개발 경험이 없는 직원들이 이후에 쉽게 유지보수 할 수 있도록 만드는 것은 쉽지 않은 일이었다.

- 화면 표준화 및 UI 컴포넌트의 개발

화면 표준에 대한 업무 분석팀과의 논쟁이 시작되었다. 80%이상의 화면을 표현해낼 수 있는 화면 및 제어 흐름의 표준과 UI컴포넌트 추출 작업을 끝낸 후, 스프링이 제공하는 spbind 태그를 쉽게 사용할 수 있는 spbind 확장 태그를 개발했다.

또 x라는 네임스페이스를 갖는 MultiSelect, AutoComplete Text, Calendar, Tree, Grid 등 총 71개의 UI 표준 태그의 개발을 완료할 수 있었다. 개발된 Context 프레임워크와의 연동을 위해서는 EL 내에 다시 EL이 표현되어야 했으나, 표준 EL에서 이를 지원하지 않아 Jasper 엔진의 소스를 분석하는 수고까지 해야 했다.

<리스트 12>와 <리스트 13>은 완성된 UI 컴포넌트를 사용해서 개발된 조회 화면과 그리드 화면의 샘플 코드이다. 복잡한 UI 구성은 UI 컴포넌트의 뒤에 감춰지고, 개발을 위해 반드시 필요한 정보 구조만을 표현하는 심플한 UI 개발이 가능해 졌음을 확인할 수 있다.

이로 인해 표준화면 구조를 따르는 JPS 페이지는 한명의 개발자가 하루에 몇 십 개도 거뜬히 개발할 수 있을 만큼의 생산성을 확보할 수 있었다. 물론 x태그를 위한 XML 스키마 개발 및 이클립스의 템플릿 기능과 같은 IDE의 도움을 얻은 결과이다.

- Context를 통한 애플리케이션 정보의 처리

Context는 유일하게 KAF의 전 계층에 걸쳐 사용된다. HTTP요청으로부터 넘어온 요청 파라미터 값을 처리하는 것부터, 화면에 뿌려질 코드나 Enum 값들에 대한 처리까지 담당하며, 계층간의 정보 공유를 전담하고 있기 때문이다.

KAF의 제어 클래스는 Context를 처리할 수 있도록 스프링MVC의 AbstractController와 SimpleFormController를 확장한 것이다.

사용자 입력은 Context에 의해 자동으로 처리되어 제어 클래스를 통해 비즈니스 로직을 담당하는 서비스 POJO에게 전달된다.

- 애플리케이션 프레임워크의 개발 및 도입 효과

현재 카이스트 학사시스템 개발 프로젝트에서는 KAF를 통해 믿기 힘들 정도의 생산성 향상을 보이고 있다. 디자이너는 본래의 역할을 수행하면서 하루 두 시간씩 두 달간의 교육을 받고, 하루에 DAO/BL/CTRL 화면을 포함한 컴포넌트를 두 개 이상 개발하고 있다.

업무 분석가는 PPT가 아닌 KAF의 UI 컴포넌트를 활용해서 더욱 빠르고 쉽게 직접 화면을 만들어 개발팀에게 전달하며, 업무 로직을 설명한다. 개발팀들은 비즈니스 로직을 제대로 구현하고 테스트하는데 집중하며 업무 시간 내에 빠른 속도로 할당된 작업을 마무리한다. 더 나은 개발 기술을 익히기 위해 퇴근 시간 이후에도 분위기에 이끌려 반 강제로 남아 있기 때문에 우리가 프로젝트 조직이냐, 학습 조직이냐 하는 투정을 부리기는 하지만.

물론 KAF가 완벽한 프레임워크가 되지 못한다는 것은 잘 알고 있다. 컨트롤러의 구현이 변경될 때마다 애플리케이션 서버를 재시작하는 것은 생각 이상으로 엄청난 시간 낭비이다.

그러한 이유로 우리는 동적 스크립트 언어의 지원을 반기며, Ruby on Rails와 유사한 Grails(Groovy+Spring+Hibernate)의 발전을 주의 깊게 살펴보고 있다. 보다 빠른 생산성 향상을 위해 KAF에 꼭 맞는 이클립스 플러그인을 개발해 모델 정보만 입력하면, 기본적인 컴포넌트의 골격은 자동으로 생성하도록 만들 계획도 가지고 있다.

아직도 복잡한 스프링 설정 파일을 단순화하기 위해 스프링 2.0의 향상된 설정 기능을 어떻게 멋지게 적용시킬 방법이 없을까 하는 고민도 잊지 않고 있다.

KAF는 OpenSeed 커뮤니티(http://openseed.net)에서 개발한 OSAF(OpenSeed Application Framework)를 기반으로 카이스트의 학사시스템이라는 도메인에 맞게 확장한 것이다. 현재OSAF는 0.22 버전으로 지금 이 시간에도 OpenSeed의 이일민 님에 의해 개발이 진행 중이다.

필자의 부족한 글에 아쉬움을 느끼는 분들은 곧 있을 OSAF의 소스 공개를 기다려 주시기를 바란다.

생산성을 10배 높여주는 이클립스 플러그인

필자는 스스로의 개발 생산성이 못마땅해서 많은 고민을 했던적이 있다. 그 때 그러한 고민을 하게 만든 괴물 같은 선배가 내게 선물로 준 것이 직접 개발한 「생산성을 10배 높여주는 이클립스 플러그인」이다.

선배의 말을 철석같이 믿는 순진한 필자는 호기심 반, 기대 반으로 그 플러그인을 설치하고 실행시켰다. 플러그인 설치 후에 생긴 버튼을 클릭하니, “물개, 지금 보다 10배만 더 열심히 일해~ *”라는 메시지 창이 뜨는 것이 아닌가. 이상하게도 그날은 평소보다 몇 배나 많은 일을 무척이나 즐겁게 처리했던 것 같다.

어떤 프레임워크가 좋은지, 어떤 개발 툴이 좋은지, 어떤 방법론이 좋은지에 대한 논쟁이 지금도 계속되고 있겠지만, 문득 높은 생산성을 유지한 채 좋은 품질의 소프트웨어를 만드는 열쇠는 잘 훈련된 개발자 본인과 그를 믿고 따뜻하게 보듬어 주는 동료들, 즉 개발자인 우리들 스스로가 지니고 있는 것이 아닌가 하는 생각을 해본다. @

참고자료

1. 오픈소스 기반의 엔터프라이즈 프레임워크를 활용한 시스템 개발전략, 이일민, 제 7회 한국 자바 개발자 컨퍼런스 2006

2. Spring을 이용한 애플리케이션 프레임워크 개발전략, 이일민, 기묘세미나 2006

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.