[Spring] MVC 패턴에서의 5가지 계층에 대한 정보

스프링을 통해 최근 자바 커뮤니티의 관심이 집중되고 있는 IoC 컨테이너와 AOP에 대한 개념을 접해보도록 하자. 그리고 스프링을 스트럿츠와 연동하기 위해 필요한 절차에 대해서도 알아보자. 

자바를 이용해 기업용 비즈니스 시스템을 구축하는 것은 보통 일이 아니다. 개발자들은 복잡도를 낮추기 위해 MVC 패턴이 녹아있는 n-계층 C/S 환경을 구성하기 시작했으며, 점차 시간이 흘러가면서 대규모 웹 애플리케이션은 다음의 다섯 가지 계층으로 일반화되어 적용되고 있다. 

◆ 프리젠테이션 계층(Presentation Layer) 

◆ 제어 계층(Control Layer) 

◆ 비즈니스 로직 계층(Business Logic Layer) 

◆ 퍼시스턴스 계층(Persistence Layer) 

◆ 도메인 모델 계층(Domain Model Layer) 

다양한 프로젝트를 경험하면서 자바 커뮤니티는 최상의 실천 사례들을 디자인 패턴의 힘을 빌어 J2EE/EJB 패턴으로 구체화시켜 나갔다. 그 중 가장 널리 알려진 것은 코어 J2EE 패턴과 EJB 패턴이다. 개발자들은 J2EE 기술의 장점을 최대한 살리기 위해서는 패턴에 기반한 아키텍처의 구성이 무엇보다 중요하다는 사실을 깨닫기 시작했으며, 그 아키텍처의 구현인 WAF(Web Application Framework)들이 수없이 많이 쏟아져 나오기 시작했다. 

WAF들의 춘추전국 시대는 스트럿츠와 웹워크(WebWork)에 의해 일단락 된 듯하다. 우리나라의 경우 스트럿츠는 실질적인 웹 애플리케이션 프레임워크의 표준으로 자리잡았다고 볼 수 있다. 

많은 개발자들은 스트럿츠를 사용함으로써 좋은 프레임워크가 어떤 코드가 어디에 위치되어야 하는지를 알려주는 가이드라인을 형성해 주며, 자연스럽게 좋은 설계를 이끌어내는 장점이 있음을 알게 되었다. 또한 좋은 설계를 위해 필수적인 기본 패턴들이 미리 구현되어 있어 훨씬 더 중요한 애플리케이션 로직 자체에 집중할 수 있는 여유를 준다는 점도 깨달았다. 

최근 들어 자바 커뮤니티는 엔터프라이즈 영역에서 주류를 이루던 J2EE 기술에 대한 대안적 기술들의 등장에 많은 관심을 쏟고 있다. 그 대부분은 특정 업체의 주도가 아닌 개발자들의 경험을 바탕으로 하는 창조적인 아이디어에 기반한 것이며 오픈소스 형태로 진행 중이다. 

뿐만 아니라 J2EE 기술 자체도 JSP 2.0과 JSF(Java Server Faces), 그리고 EJB 3.0, 타이거(J2SE 5.0)라는 큰 변화를 앞두고 있는 형편이다. 이처럼 다양한 대안적 기술들이 존재하는 상황에서 우리는 각 계층을 구현하기 위해 어떤 기술을 선택하고, 또 각각을 어떻게 하나의 아키텍처로 통합해야 하는 것일까? 

이러한 궁금증을 가져본 독자들이라면 마크 이글의 글(오픈소스 자바 프로젝트를 응용한 웹 애플리케이션 개발)을 한번쯤 읽어볼 필요가 있다. 그는 아키텍처를 구성하는 각각의 계층들이 애플리케이션 내에서 명확히 구별되는 기능을 가지고 있으며, 서로 다른 계층을 침범하거나 그 기능에 있어 중복되는 점이 없어야 한다고 주장한다. 그의 글을 토대로 각 계층에서 제공해야 하는 기능은 무엇인지, 또한 제공하지 말아야 할 기능은 무엇인지를 간단히 살펴보도록 하자. 


1. 프리젠테이션 계층 

◆ 역할 : 프리젠테이션 계층은 말 그대로 사용자 인터페이스에 불과하다. 식당을 예로 들면 손님이 접하게 되는 메뉴판과 전달될 음식을 차려놓는 식탁에 해당한다. 

◆ 기능 : 사용자가 선택할 수 있는 기능이 표시되어 있어야 하고, 요청에 필요한 부가적인 정보 전달을 위한 입력 양식이 있어야 한다. 또한 전달된 자료를 효과적으로 보여주기 위한 프리젠테이션 로직이 포함된다. 하지만 비즈니스 로직이나 퍼시스턴스 계층에서 처리하는 일을 직접 수행하거나(스크립트 릿 사용), 각 계층의 컴포넌트와 직접적인 통신이 있어선 안된다. 

모든 요청은 제어 계층을 통해 처리되어야 한다는 뜻이다. 고급 레스토랑(엔터프라이즈 시스템)에서는 웨이터(지배인)를 통해서만 요구를 전달하고, 그 결과를 전해들어야 한다. 직접 주방장에게 주문을 하거나 자기가 직접 요리를 하는 것은 자기 집(프로토타입)이나 동네 자장면 가게(소규모 웹 애플리케이션)에서나 가능한 일이다. 

◆ 대안 기술 : 현재 가장 주류를 이루는 기술은 JSP 1.2와 JSTL과 같은 태그 라이브러리를 결합하는 방식이다. 과도기적인 형태로 벨로시티와 타일즈 태그 라이브러리가 결합된 형태도 현재 주목을 받고 있다. 하지만 점차적으로 JSF에 기반한 JSP 2.0에 주류 기술로 옮겨갈 가능성이 크고, 프리젠테이션 계층 개발에 있어서도 JSF를 지원하는 IDE를 채택하는 경우가 늘어날 것이다. 

◆ 주요 패턴 : Composite View 패턴 



2. 제어 계층 

◆ 역할 : 제어 계층은 프리젠테이션 계층과 비즈니스 로직 계층을 분리하기 위한 컨트롤러를 제공한다. 식당으로 치자면 지배인의 역할과 종업원의 역할을 병행하는 것이라고 볼 수 있다. 

◆ 기능 : 전체 시스템의 설정 상태를 유지해야 하며, 그를 통해 어떤 요청이 들어왔을 때 어떤 로직이 처리해야 하는지를 결정한다. 사용자 요청을 검증하고 로직에 요청을 전달하는 일과 로직에서 전달된 응답을 적절한 뷰에 연결짓는 것 역시 제어 계층의 몫이다. 

손님이 바다가재 요리를 요청했을 때 종업원은 그 요리가 서비스 가능한 것인지 또한 누구에게 시키면 되는지를 알고 있어야 한다는 뜻이다. 요청을 전달받은 요리사가 바다가재 요리를 주면 그것을 식탁까지 운반해 주는 것 역시 종업원의 몫이다. UI 검증, 요청 및 응답 전달, 로직에서 던져진 예외 처리, 도메인 모델을 뷰와 연결하기 등의 고유 기능 외에는 어떤 기능도 포함하지 않는다. 

◆ 대안 기술 : 현재 WAF들은 대부분 제어 계층의 핵심 기능을 포함한다. 터빈이나 에스프레소 등이 선전하고 있지만, 스트럿츠와 웹워크가 대세라고 생각된다. 당분간 별다른 대안 기술이 등장할 가능성은 적다. 오히려 스트럿츠를 확장시켜 자사 고유의 프레임워크로 최적화 시키는 작업이 활발히 진행될 것이다. 

◆ 주요 패턴 : Front Controller 패턴, Service to Worker 패턴(또는 Command 패턴), Intercepting Filter 패턴, Application Controller & Context Object 패턴 



3. 비즈니스 로직 계층 

◆ 역할 : 비즈니스 로직은 말 그대로 핵심 업무를 어떻게 처리하는지에 대한 방법을 기술하는 곳이다. 식당에서 종업원이 고객의 요구를 전달해 주면, 재료를 이용해 요리를 만드는 요리사라고나 할까? 비즈니스 로직 계층은 애플리케이션에서 가장 재사용될 확률이 높은 요소이기 때문에 신경 써서 설계해야 한다. 

◆ 기능 : 비즈니스 로직에는 핵심 업무 로직의 구현과 그에 관련된 데이터의 적합성 검증 외에도 다양한 부가적인 구현이 추가된다. 트랜잭션 처리라든가, 다른 계층들과 통신하기 위한 인터페이스를 제공한다거나, 해당 계층의 객체들간의 관계를 관리하는 것 등이 그것이다. 

비즈니스 로직 계층에 있어야 할 코드들이 프리젠테이션 계층이나 퍼시스턴스 계층에 여기저기 흩어져 있는 애플리케이션을 찾아보기란 그리 어려운 일이 아니다. 이런 구조는 각각의 계층을 모호하게 만들어 유지보수시 많은 시간을 필요로 하게 만든다. 

가장 신경 써서 개발해야 할 비즈니스 로직에 그동안 신경을 쓰지 못했다는 것. 프리젠테이션 계층과 퍼시스턴스 계층 사이의 다리 역할을 충실히 하도록 함으로써 애플리케이션에 유연성을 더하는 것. 그것이 스프링이 탄생하게 된 배경이라고 할 수 있다. 

◆ 대안 기술 : 지금까지 비즈니스 로직의 구현은 크게 EJB를 사용하는 것과 일반 자바 객체(POJO)를 사용하는 것으로 나눌 수 있었다. EJB를 사용하는 경우 개발자들의 많은 불만이 EJB 3.0을 사용함으로써 해결되리라 예상된다. 하지만 해외를 중심으로 해서 EJB를 사용하건, 사용하지 않건 비즈니스 로직들을 체계적으로 관리하는 IoC 컨테이너에 대한 관심이 증가하고 있는 추세이다. IoC 컨테이너에 대해서는 뒤에서 다시 자세히 살펴보도록 하겠다. 

◆ 주요 패턴 : Business Delegate 패턴, Session Facade 패턴, Service Locator 패턴, Application Service 패턴, EJB Home Factory 패턴 



4. 퍼시스턴스 계층 

◆ 역할 : 퍼시스턴스 계층은 데이터 처리를 담당하는 계층이다. 주로 데이터의 생성/수정/삭제/선택(검색)과 같은 CRUD 연산을 수행하게 된다. 식당으로 보자면 주방장이 사용할 재료를 담당하는 재료 담당자라고나 할까? 이 데이터는 주로 데이터베이스에서 처리되는 경우가 많아, 영속성을 의미하는 퍼시스턴스 계층이란 용어를 사용했다. 하지만 데이터가 처리되는 다른 업무 시스템이나, 웹 서비스, XML, 파일 시스템 등을 모두 고려한다면 레거시 개념을 갖는 EIS 계층이란 표현이 더 적합할 것이다. 

◆ 기능 : 이 계층에서 수행하는 일은 관계형 정보를 저장하고, 수정/삭제하는 것과, 그러한 일을 수행하는 데 필요한 질의문을 관리하는 것, 그리고 가져온 관계형 정보를 객체화시키는 일이다. 

◆ 대안 기술 : EJB 사용에 있어서 개발자들이 가장 불만스러워 하는 것은 CMP 방식의 엔티티 빈일 것이다. 그러한 불만은 객체 관계 맵핑(ORM)을 이용한 JDO라는 대안기술을 탄생시켰고, 또한 하이버네이트라는 또 하나의 오픈소스 기술을 실무로 끌여들였다. JDBC를 이용한 DAO 객체를 구성하는 방법도 소규모 애플리케이션에서는 여전히 인기를 끌고 있다. EJB 3.0과 JDO/하이버네이트, 그리고 JDBC를 이용한 POJO 방식 중 어떤 것이 개발자들에게 낙점될 지는 아직 미지수다. 

◆ 주요 패턴 : Data Access Object 패턴, Domain Store 패턴, Sequence Blocks 



5. 도메인 모델 계층 

◆ 역할 : 도메인 모델은 각 계층 사이에 전달되는 실질적인 비즈니스 객체라고 할 수 있다. 식당을 예로 든다면, 음식이 담긴 그릇이라고 비유할 수 있겠다. 

◆ 기능 : 도메인 모델 계층은 흔히 데이터 전송 객체(DTO) 형태로 개발자가 직접 제작해서, 리퀘스트나 세션과 같은 컨텍스트에 담아 넘기게 된다. 하지만 데이터베이스의 모든 정보를 일일이 객체로 만드는 것은 귀찮을 뿐 아니라, 계층간의 통신 과정에서 데이터가 유실될 위험도 있기 때문에 최근에는 도메인 모델을 서비스로 제공하여 자동화하는 경우가 많다. 

◆ 주요 패턴 : Data Transfer Object 패턴, Value List Handler 패턴 

지금까지 엔터프라이즈 시스템을 구축하기 위해 일반적으로 사용되는 다섯 계층에 대해 간단히 정리해 보았다. 뻔한 이야기들을 길게 늘여 쓴 이유는 2가지 사실을 강조하기 위해서이다. 첫째, 각각의 계층은 저마다의 분명한 역할이 존재하며, 그 역할을 충실히 수행할 수많은 대안기술(Alternative)들 사이에서 개발자는 무엇을 선택할 지 결정을 내려야 한다. 둘째, 각각의 기술들은 독립적으로도 충분한 가치를 지니고 있지만, 가장 장점을 발휘하는 제 위치에서 서로 연계되어 사용될 때 그 시너지 효과가 더욱 크다. 

약한 결합도를 가진 아키텍처 구성 
이 글을 읽는 상당수의 독자들은 애플리케이션을 개발할 때 스트럿츠를 사용해 본 경험이 있을 것이다. 프리젠테이션 계층에는 태그 라이브러리가 접목된 JSP를 이용했을 것이며, 업무 로직과 영속성 처리는 그 규모에 따라 POJO나 EJB를 적절히 섞어 사용했을 것이다. 하지만 정말 스트럿츠만으로 충분했었는지 묻고 싶다.