J2EE 아키텍트들에게 화면은 상대적으로 가볍게 취급되거나 개발자나 디자이너가 처리해야할 문제로만 인식되는 경향이 있다. 그러나 화면은 아키텍트에 의해 해결되어야 하는 많은 기술적 문제를 내포하고 있으며 반드시 표준화 되어야 한다
2002년 여름에 공공 프로젝트에 투입되었다. 공공 프로젝트의 특징 중 하나가 비즈니스가 명확하지 않다는 사실이다. 물론 SI 구축 프로젝트 현장에서 고객과 업무협의를 하다 보면 비즈니스가 명확하지 않다는 느낌을 받을 수 있겠지만 보통 일반 기업체 시스템 구축 프로젝트에서는 고객의 요구사항이 명확하지 않은 것이지 그 업무는 명확하다. 그러나 공공 기관의 경우는 다르다 모든 업무가 국내에서 유일무이한 경우가 많고 업무자체가 불확실한 요소가 많다. 신규사업 일 경우나 관련 법률이 바뀌려고 하는 경우는 더욱더 그러하다. 고객의 업무에 대해서 아주 어설픈 윤곽만 잡을 수 밖에 없다. 업무 파악도 다 하기 전에 어느덧 코딩을 하기 시작한다. 이제부터 개발자의 슬픔(?)이 시작된다. 팀의 모든 개발자가 해당 프로젝트 기반기술 혹은 구현 언어에 대한 지식이 많다면 큰 문제가 없지만 - 요즘은 프로젝트 경험이 많은 중급 기술자라 할지라도 해당 프로젝트 환경에 익숙해 지려면 적지 않은 시간이 소요되는 것이 SI 개발자 현실이다. - 그렇지 못한 경우 라던가 프로젝트 경험이 별로 없는 개발자에겐 기술에 대한 혹은 구현 언어의 문법에 대한 거대한 장벽이 개발자를 더욱 암울하게 하는 것이 사실이다. 업무에 대한 어설픈 윤곽을 조금은 더 명확하게 그려보고자 하려는 의지는 쉽게(?) 무너지고 코딩 하기에 바빠진다. 프로젝트에서 한 친구가 이런 고민 가운데 구현을 해 가다가 갑자기 이런 얘기를 던진다. 업무는 대강 알겠는데 화면 구성을 어떻게 해야 할지 모르겠다는 것이다. 나와 몇몇 개발자가 모여 이런 저런 얘기를 하기 시작했다. 나는 해당 프로젝트에서 S/W 아키텍트 역할을 수행하고 있어 적용 프레임웍과 기술 지원 등의 역할을 가지고 있어서 업무에 대해서는 많을 것을 알고 있지 못한 상태였다. 얘기를 하다 보니 해당 시스템은 불특정 다수를 사용자로 하는 즉, 대 국민 서비스 시스템과 해당 기관의 직원들만 사용하는 업무 시스템으로 크게 분류할 수 있었다. 사실 이러한 사항을 파악하는데 적지 않은 시간을 소비했다. 지금 생각해 보면 싱거울 정도로 단순한 문제였지만 그 당시에는 업무에 대해서 명확하게 알지 못하고 또 그 업무에 대해서 설명해 줄 수 있는 업무 담당자가 없는 상황이라 더욱 혼란스러웠던 기억이 난다. 어쨌든 이런 고민을 최초 제기한 개발자 뿐만 아니라 다른 개발자 들도 비슷한 고민을 하고 있었다는 것을 알게 되어 나는 크게 인터넷 스타일(?) 화면과 인트라넷 스타일 화면에 대한 표준 정의를 하게 되었다. 인트라넷 스타일이야 이쪽 동네에서 밥 먹고 사는 엔지니어라면 혹은 4GL개발 환경을 경험한 개발자라면 누구나 쉽게 이해하는 CRUD형 화면 구성이다. 지금도 많은 프로젝트에서 인트라넷 스타일 화면을 웹으로 구성하고 있다.
보통 기본 Main 화면에서 생성/조회/수정/삭제가 이루어 진다. 요즘은 화면 컴포넌트를 활용하여 마치 4GL용 화면처럼 웹을 구성하므로 화면 네비게이션이 그다지 복잡하지 않다. 물론 세부적으로 한단계 더 내려가면 더 상세한 요소 화면 스타일까지 얘기가 되어야 겠지만 지금은 이런 정도만 언급하겠다. 문제는 인터넷 스타일 화면이다. 물론 단순 CRUD성 화면도 있겠지만 절차적인 화면 흐름, 예를 들면 쇼핑몰에서 상품선택 -> 수량결정 -> 발송처 정보 입력 -> 카드정보입력 -> 결제 등등의 절차적인 화면 네비게이션이 필요하다.
중간 중간 팝업 창도 뜨면서 큰 줄기의 흐름이 존재하는 화면 구성이다. 이런식으로 업무 성격별 화면 네비게이션을 제시한 후 프로젝트 개발자들은 업무 정의를 보다 원활하게 할 수 있었다.
이프로젝트 이후 필자는 화면에 대해 좀더 깊은 고민을 시작했다. 개발자들이 화면 때문에 고민하는 것은 무엇인가? Grid컴포턴트 같은 UI컴포넌트 보다 좀더 추상화된 관점에서 재사용 요소는 없는가? 왜 웹시스템의 고객은 C/S화면을 요구하는가, 그들의 요구를 충족시킬 방법은 무엇인가? 이러한 문제를 해결하는데 아이디어를 준 것은 디자인 패턴이었다. 그것은 네비게이션을 포함한 화면의 유형을 분석 표준화하고 그 화면과 연관된 서버로직 까지를 패턴화하는 것이었다. 본문에서 필자는 그 아이디어를 소개할 것이다.
화면의 표준화를 단순히 디자인의 영역으로 보는 경향이 있다. 폰트의 크기나 배치 입력 박스의 모양등 사실 기능적으로 동일하지만 어떻게 화면을 꾸민 것인가에 대한 표준을 화면 표준화의 전부로 인식하곤 한다. 물론 이러한 부분도 중요하다 그러나 이것이 화면 표준화의 전부라고 보기에는 좀 부족하다. 비즈니스를 구현하는 개발자에게 있어 화면에서 가장 궁금한 것은 무엇인가? 업무를 분석하는 사람에게 정리되어야 하고 전달되어야 하는 화면 관련 문제는 무엇인가? 그것은 폰트의 크기나 색깔 보다는
기타 등등…
이러한 것들이 결정되고 가이드 되어야 한다. 결정사항들이 정확히 정리되고 개발자에게 전달되지 않으면 화면에 너무 많은 스파게티 코드가 존재하게 되고 오픈 시점에 화면에서 비롯되는 수많은 문제가 발생한다. 화면에 관한 결정사항들을 포괄적으로 표준화해야 하는데 많은 결정사항들이 업무 기능과 기술의 문제가 복합적으로 영향을 준다. 따라서 표준을 보통의 화면 단위인 페이지 단위로 정리하거나 UI컴포넌트 단위로 정리하게 되면 경우의 수가 많고 정리하는데 어려움이 발생한다.
화면의 기본단위 화면영역(Screen Area)
화면은 사용자의 시스템에 대한 직접적 요구를 반영하는 곳이다. 분석과 설계가 직관적이어야하며 분석/설계 결과는 컴퓨터를 잘모르는 사람들도 이해 가능해야 한다. 또한 구현의 관점에서도 명확해야 한다. 이러한 목적에서 화면에 대한 분석/설계는 화면의 추상적인 구성요소를 결정하는 것으로부터 접근되어야 한다. 화면의 구성요소를 윈도우의 UI컴포넌트의 구성으로 보게 되면 너무 다양하고 기능성을 반영하지 못하기 때문에 화면 자체를 정형화 하는데 어려움을 야기한다.
[그림 5]
따라서 화면을 추상화하기 위해서는 좀 더 큰 단위인 화면을 영역의 관점에서 보아야 한다. 예를들어 화면 영역에는 조회 조건을 입력하는 조회영역 검색 이벤트가 발생하면 서버로부터 결과를 조회하여 화면에 출력하는 리스트 영역 그중에 하나가 선택되면 편집 영역에서 데이터가 편집될 것이다.
각 영역은 여러 개의 UI컴포넌트로 구성될 것이다. 이렇게 화면을 영역으로 정의하게 되면 자연스럽게 화면에서 필요로하는 이벤트들이 정의 될 수 있게 된다. 이벤트는 클라이언트 이벤트와 서버 이벤트로 구분할 수 있다.
클라이언트 이벤트
화면안에서 처리되는 이벤트를 의미한다. 조회결과에서 한건을 선택했을 때 편집 영역으로 데이터를 넘겨주고 편집 상태로만들 때 사용되는 이벤트가 클라이언트 이벤트이다
서버 이벤트
서버의 서비스를 호출해야만 하는 이벤트이다. 조회 영역에 검색 조건을 입력하고 검색 버튼을 누른경우 서버에서 데이터가 조회될 것이다. 이런경우를 서버 이벤트라 한다
화면의 성격이나 아키텍쳐적 결정 혹은 사용되는 기술셋에 따라 동일한 이벤트가 클라이언트 이벤트가 되기도하고 서버 이벤트가 되기도 한다. 예를 들어 조회결과에서 한건을 선택하는데 편집하기 위한 칼럼이 모두 조회되지 않은 경우 서버의 서비스를 호출하여 편집하기 위한 데이터를 조회해야 한다. 이런경우 이벤트의 성격이 변경되는 것이다. 또 다른 경우로 화면 네비게이션이 변경되는 경우에도 이벤트의 성격은 변경된다. 한 화면에서 조회 결과영역과 편집 영역이 같이 있는 경우는 클라이언트 이벤트였던 것이 화면이 둘로 분리되어 편집영역이 새로운 창에서 존재하는 경우 서버 이벤트가 된다. 따라서 이벤트의 성격은 화면 네비게이션이 결정되고 아키텍쳐적인 고려가 된 이후에 결정된다.
여기서 대부분 화면에서 어떤 역할의 관점에서 정의되었는데 트리나 텝영역 같은 경우는 구현의 특수성으로 인해 정의된 경우이다. 리스트 영역 같는 경우에는 업무 화면에서 차지하는 비중이 큼으로 특별히 페이징 리스트를 별도로 정의하고 있다. 화면영역에 대한 구현 기술은 업무 목적에 맞게 다양할 것이다. 예를 들어 입력항목을 InputBox에 'Y','N'으로 하느냐 CheckBox를 사용하느냐는 파급이 적기 때문에 중요도가 떨어진다. 그러나 페이징이나 TAB화면 등은 사용되는 UI컴포넌트가 중요하다. 따라서 영역의 대상은 기술적 혹은 기능적 목적에 의해 정의된다.
그럼 페이징 리스트 영역( 
)을 간단히보자.
[그림 6]
페이징 리스트 영역은 리스트 데이타를 화면에 출력하고 체크후 삭제,한로우 선택, 패이지이동 등의 이벤트가 필요하다
화면영역은 구성형태와 이벤트를 가지게 된다. 화면 영역은 모여서 어플리케이션 패턴의 기초가 된다
화면네비게이션
역을 업무 목적에 맞게 나열하고 페이지에 배치하면 업무를 위한 화면네비게이션이 완성된다. 정리된 화면 네비게션 만큼의 어플리케이션 패턴이 만들어 진다. 화면네비게이션은 업무를 처리하기 위한 절차가 되지만 실제 프로젝트에서는 업무를 분석해가는 수단이 되기도 한다. 예를 들어 고객 관리의 화면 네비게이션을 알면 사원관리의 네비게이션도 쉽게 이해하고 기본적으로 필요한 로직(화면으로부터 발생한)을 이해한다. 이점은 동일한 화면 영역을 사용함으로써 발생하는 현상이다. 정형화된 화면 네비게이션을 추출하기 위해서는 경험적 요소가 필요하다. 프로젝트의 레거시시스템을 검토하거나 비슷한 업무도메인의 다른 시스템을 분석하는 것이 좋은 방법이다. 다음은 화면네비게이션의 예이다.
단순 게시판 네비게이션
메인화면(리스트창)이 선택되면 기본 리스트가 조회되고 검색을 통해서 추가 검색할 수도 있다. 조회된 리스트에서 한건을 선택하면 상세조회가 되고 수정이나 신규를 선택할 수 있다. 수정된 값은 저장을 통해서 상세창에서 저장 모습이 보여
[그림 7]
진다. 상세창이나 수정창에서 목록을 선택하면 무조건 첫화면으로 이동한다. 첫화면에서는 여러건을 삭제할 수 있고 상세창에서는 한건을 삭제할수 있다. 다만 상세창에서 삭제 이후는 자동으로 리스트 창으로 이동한다.
한화면에서 리스트 조회후 수정 네비게이션
한화면만을 이용하는 구성이다. 조회 영역에 검색조건을 입력하고 검색을 선택하면 리스트가 조회되고 조회된 리스트에서 한건을 선택후 수정/저장하거나 리스트에서 몇건을 선택하여 삭제할 수 있다.
한화면으로 로직을 처리함으로 선택 이벤트는 일반적으로 클라이언트 이벤트가 된다.
[그림 8]
예에서 보듯이 화면 네비게이션은 업무를 위해 필요한 화면 영역을 조립하고 페이지를 분할하여 상호 이벤트 관계를 기술하는 형식으로 표현된다. 이러한 정리는 화면의 흐름을 보다 추상적으로 바라볼수 있게 함으로써 업무에 필요한 화면네비게이션과 나아가 화면 때문에 필요한 서버로직으로 효과적으로 파악할 수 있게 한다.
아키텍쳐적 결정
프로젝트 시작시에는 화면 네비게이션 유형이 결정되는 것과 별도로 아키텍쳐 설계가 이루어 진다. 아키텍쳐 설계시에는 다양한 기술적 결정사항들이 판단된다. 따라서 서버 이벤트 구성은 절대적으로 아키텍쳐 결정에 영향을 받는다. 전체 프레임웍을 설계하는 것과 어플리케이션 패턴은 밀접하게 연관되어 있는데 그 중에서도 최상위 클래스 구성 , Layer분할, 역할과 구성단위 등이 직접적인 영향을 받는다.
이벤트 구성 단위
먼저 서버 이벤트를 구성하는 단위에 대한 결정이 필요하다. 만약 서블릿이 서버사이드 이벤트를 처리한다면 하나의 패턴에서 발생하는 이벤트를 하나의 서블릿이 처리할 것인지 아니면 각 이벤트 별로 서블릿을 정의할 것인지에 대한 선택이 필요하다.
[그림 9]
이벤트 처리 클래스의 구성 방법은 어플리케이션 프레임웍에 영향을 받게 되는데. Struts(아파치) 프레임웍을 사용한다면 개별 클래스(action클래스)로 구성하는게 일반적이다. 그러나 한 개의 클래스로 구성하는 것도 장점이 있다. 보통 하나의 패턴 안에서는 각 이벤트간에 중복 코드가 발생하는 경향이 있는데 메소드(이벤트)들이 하나의 클래스로 구현되면 중복 코드를 제거하는 효과가 있다.
Layer에 대한 결정
서버 이벤트의 처리 로직에 대한 Layer를 몇 개로 가져갈 것인가에 대한 결정이 필요하다. Layer를 나눌때는 필요한 역할을 판단하고 분할 하는 것이 일반적이다. 어플리케이션 패턴은 기업 정보 시스템을 가정함으로 Transaction과 Data Access역할이 필요하게 된다. 또한 네트웍을 통해 전달되는 이벤트를 받아야 하기 때문에 서버의 역할되 필요하다. 이렇게 3계층으로 분할하는 것이 보통이다
이벤트 헨들러는 서블릿 혹은 Struts를 사용하면 Action클래스가 된다. 비즈니스 로직 부분은 Transaction 관리 역할이 있다. 따라서 EJB로 작성된다. 그러나 EJB Command Pattern(GoF)을 사용하는 경우 비즈니스 로직 클래스는 단순한 자바 객체로 정의된다. 데이터 접근 계층은 SQL을 사용하는계층으로써 SQL문, DB접근 로직등을 포함한다.
어플리케이션 패턴과 그것을 통해 얻은 것들
어플리케이션 패턴은 화면으로부터 시작하여 DB접근까지 어플리케이션을 유형화 한것이다. 다음은 정의된 패턴 중에 하나이다
ListToEdit 패턴
개요
List To Edit는 조건을 통한 리스트 검색결과를 바탕으로 선택된 1건의 Data에 대해 수정이 이루어지는 흐름 구성이다. 아래에 판단기준에 해당하는 경우에 사용 할 수 있다
- 리스트 조회 후 1건 Data의 수정이 기본 업무인 경우 사용한다.
- Multi 건의 Data에 대해 조회 및 삭제를 수행한다.
- 1건의 Data에 대해 등록 및 변경을 수행한다
화면 흐름 및 이벤트명세
두개의 화면으로 구성되며 6개의 이벤드를 갖는다
[그림 10]
[1]페이지 이벤트
- 검색 : 조건영역의 조건에 따른 자료를 조회하여 리스트 영역을 보여준다.<서버 이벤트>
- 신규 : Edit Detail 화면으로 분기한다. (신규모드) <서버 이벤트>
- 삭제 : 리스트 영역에서 선택된 Data에 대해 삭제를 수행한다. <서버 이벤트>
- 선택 : 리스트 영역의 Row를 클릭하면 Edit Detail 화면으로 분기한다. (수정모드) <서버 이벤트>
[2]페이지 이벤트
- 목록 : Linkable List 화면으로 분기한다. <서버 이벤트>
- 저장 : 신규/수정 Data를 저장한 후 Get Detail View로 분기한다. <서버 이벤트>
Layer별 클래스
화면의 이벤트를 처리하기 위한 클래스 구성도이다. 여기서 클래스 명칭이나 각 클래스간의 호출방법 등은 통상 아키텍트에 의해 디자인 가이드로써 제시된다.
[그림 11]
각 서버 이벤트를 Action클래스가 담당한다.
Servlet + Command Pattern을 사용한다.
비즈니스 로직영역의 로직은 Biz클래스가 담당한다.
EJB + Command Pattern을 사용한다.
패턴을 위한 Data Access는 DAC(Data Access Control)가 담당한다.
DB Transaction관리는 Biz에서 시작 종료된다.(EJB사용)
로직 추가에 대한 가이드
검색 영역에 대한 초기화가 필요한 경우 xxxInitAction을 수정한다.
서버 이벤트에 대한 입력 값의 검증을 위해서는 별도의 Validation클래스를 구성하고 Action클래스에서 호출하도록한다.
Core Business 로직은 Biz클래스에 구현하지 않고 별도의 클래스를 두어 처리한다.
화면에 추가적인 서버 이벤트(버튼)가 필요한 경우 해당 이벤트를 처리하기 위한 Action, Biz클래스를 추가한다.
DAC클래스에 로직 추가 요건이 발생하면 메소드를 추가한다.
제약사항
Action간에는 상호 호출할 수 없다
Biz간에는 상호 호출할 수 없다
|
어플리케이션 패턴은 프로젝트에서 많은 문제에 직간접적으로 도움이 되었다먼저 전체 시스템의 복잡도를 한눈에 파악할 수 있었다. 업무 분석을 통해서 만들어진 전체 시스템의 기능요구에 대해서 패턴을 맵핑하였다. 맵핑된 패턴는 업무에서 구현해야할 화면의 복잡도와 서버 사이드에서 구현해야 할 클래스/메소드 수를 정확히 파악할 수 있게 되었다.
둘째로 개발자들에게 구현해야하는 화면의 종류를 조기에 전달할 수 있었다. 전체 화면 대비 약 70%의 화면을 패턴화하여 정형화함으로써 다수의 경험이 부족한 개발자에 대한 효과적인 교육이 가능하였고 또한 소수의 기술 수준이 높은 인력에게 패턴화하지 못한 30%의 화면에 대해 집중할 수 있게 함으로써 기술 인력의 영량을 효율화 할 수 있었다.
그리고 전체 업무의 개발 단위와 진척관리를 패턴화된 어플리케이션+코어 비즈니스+기타핵심 어플리케이션으로함으로써 프로젝트의 진행 상태를 명확히할 수 있었다.
또한 코드의 품질을 높일 수 있었다. 소스의 설명문의 작성자를 보지않으면 20명이 넘는 인력이 개발하였음에도 코딩 패턴이 동일하여 누가 작성하였는지 알 수 없었다. 패턴화된 어플리케이션의 코드에선 메소드 명칭까지도 명확히 결정됨으로써 자연스럽게 Naming Rule이 지켜졌고 개발자는 업무를 이해하는데 보다 집중할 수 있었다. 즉 각 패턴별로 샘플과 템플릿을 제공함으로써 코드의 일관성으로 유지할 수 있었다.
마지막으로
아직은 어플리케이션 패턴 관점의 접근은 아이디어 수준이고 몇몇의 프로젝트에서 조심스럽게 응용되고 있다. 좋은 점도 있었지만 어려움도 있었다. 그러나 거시적으로 향후 프로젝트의 재사용이나 품질의 관점, 개발의 편리성 등등을 고려할 때 패턴기반의 개발 접근은 프레임웍이나 컴포넌트와는 또다는 가치를 제공할 수 있을 것이다
참고 문헌
- Design Patterns: Elements of Reusable Object-Oriented Software (GoF)
- Core J2EE Patterns: Best Practices and Design Strategies ( Deepak Alur, John Crupi and Dan Malks)
- Patterns of Enterprise Application Architecture (Martin Fowler)
