한빛출판네트워크

제공 : 한빛 네트워크
저자 : chromatic
역자 : 이호민
원문 : Does Enterprise Development Have to Be Painful? (Part Two)

기업용 애플리케이션 개발은 힘들어야만 하는가? (Part 1)에서 언급했듯이, 최소한의 교육과 지도를 통해(내가 문제점에 전혀 빠져 나올지 못할 때는 한 두 명의 컨설턴트로부터 도움을 받았었다) 내가 얼마나 성취할 지를 보기 위한 SAP 연구소의 도전 과제의 일환으로, SAP 넷위버 복합환경 (이하 SAP 넷위버 CE)를 사용하여 기업용 소프트웨어 개발의 세계를 탐험하고 있다.

나는 최고의 접근 방법으로 그들의 시스템을 사용해 간단한 자장식(self-contained)의 애플리케이션을 빌드하는 것을 결정했다. 할 수 있는 한 적은 코드를 작성하고, 그들의 도구들에서 많은 부분을 사용할 것이다. 나는 만기일, 설명, 연관된 카테고리를 가진 테스크들을 추적하기 위한 작은 테스크 트래커 애플리케이션의 개발에 착수했다. 전체 애플리케이션은 두 모델로 구성되어 있는데, 비니지스 로직과 유져 인터페이스가 그것이다. SAP 넷위버 CE는 이러한 비지니스 객체와 그들의 관계들을 빌드하고 관리, 설치(deploy)하기 위한 엄청난 양의 도구들 제공한다. 따라서 나는 이것이 좋은 기초 경험이라고 생각했다. 이것은 일반적인 CRUD-형 애플리케이션으로, CRUD는 데이터를 만들기(Create), 읽기(Read), 갱신(Update), 삭제(Delete) 하기 위한 코드들을 가지고 있음을 말한다.

너무 단순해 보이는가? 만약 내가 추후에 만들 애플리케이션들이 이런 종류 들 뿐이라면 그럴 수도 있다. 이 경우 SAP의 도구들은 분명 과하다. 나는 클러스터링이나 모니터링, 이중 안전 장치된 설치 그리고 롤백을 위해 하루 동안 내가 무슨 일을 했는지 기록하는 일들이 필요하지 않다. 하지만 그것들은 실제 애플리케이션 세계에서 실제로 사용되는 시스템의 부분들을 연습하기 위한 내가 상상할 수 있는 최소한의 애플리케이션이었다. 그 테스크 트래커를 빌드하고 설치 하는 것은, 실제로 팀에서 더 큰 애플리케이션을 빌드하고 설치할 때 수행하는 것과 같은 일이었다. 내가 이런 애플리케이션을 개발하고 빌드하기 위해 여러 달의 연구시간을 가질 필요는 없었다. 나는 디자인을 하는데 하루가 걸렸으며, 나 스스로 애플리케이션을 빌드 하려면 그 일만을 한다고 가정했을 때 이틀 가량이 필요할 것이라고 예상 할 수 있었다.

SAP 넷위버 CE 에는 무엇이 들어있나?

SAP 넷위버 CE는 크게 두 부분으로 구성되어 있다. 첫째는 엔터프라이즈 급 인스톨에서 서버 컴포넌트로 대형 데이타베이스, 클러스터, 서비스 레지스트리, 사용자 관리, 중앙 설정에 상응하는 것들이다. 거의 모든 부분에서 나는 일부 설정이 제대로 동작하는지 확인 하고자 할 때는 제외하고는 이 부분을 무시하였다. 시스템의 두번째 부분은 이클립스 상에 구축된 IDE이다. 여러분은 이미 이클립스를 사용하고 있거나 혹은 다른 IDE를 사용하며 시각적인 모델링 작업을 하는 대신에 코드 더미들을 직접 작성하는 것도 상관 없다고 할 지도 모르겠지만, 여러분은 이 IDE가 매우 편리하다고 느낄 것이다.

이 모델링은 간단하였다. 비록 객체-관계 맵퍼(object-relational mapper)에게 내 데이터베이스의 구조를 전달하기 위해 (또는 내가 사용할 스키마를 생성하도록 하기 위해) 텍스트 에디터를 사용하여 약간의 선언 코드를 작성해야 했었지만 IDE에 포함되어 있는 그 모델 디자인 툴은 사용하기 쉬웠다. 테이블을 생성 하는 것에 신경을 쓸 필요도 없었으며 컬럼들을 고르거나 JOIN 오퍼레이션을 위해 데이터를 최적화 할 필요도 없었다. 이 추상층이 나의 애플리케이션의 라이프 사이클에 전반에 있었기 때문에 나는 버전 관리나 스카마의 변화에 따라 데이터를 이주하는 것에 대해 걱정할 필요가 없었다.

태스크와 카테고리 모델들을 선언하는 작업은 새 비지니스 객체를 생성하거나 메뉴에서 사용 가능한 속성 타입들을 선택하는 일들 만큼 쉬웠다. 비록 마우스를 사용하는 것이 짧은 선언문들을 텍스트 에디터에서 직접 작성하는 것보다 느릴 수도 있겠지만, 내가 그 UI가 비효율적이라고 느끼지 못할 만큼 화면 넘어에서는 충분한 메타데이터들이 왔다 갔다 하며 나에게 필요한 다른 작업들을 충분히 수행해 줬다.

진행 과정 중 이 과정은 쉬웠던 부분으로, 내장된 튜토리얼의 도움말을 따라 매우 빠르게 두 개의 모델을 빌드하고 연동(associated)할 수 있었다.

비지니스 객체들의 모델링

모델이라는 단어에서 이 모델들이 비니지스 로직을 포함하고 있을 것이라고 생각할 수 있다. 맞다. 하지만, 이 부분이 내가 처음으로 문제에 봉착한 부분 이었다. 모델들은 오퍼레이션(비지니스 로직)들을 가지고 있고 IDE를 사용해서 쉽게 그것들을 선언할 수 있다. 예를 들면, 내가 모든 오픈된 태스크들의 리스트를 반환하는 오퍼레이션이 필요하다면 여러분은 전체 모델의 모음을 특정한 설정 값으로 걸러내는 오퍼레이션을 만들 수 있을 것이다. 하지만 메타데이터들을 만드는 부분(나는 이 부분이 숨겨져 있다고 생각한다)과 분리하고 여러분의 모델을 위한 자바 빈에 메쏘드 조각을 추가해 보면 제대로 동작하지 않는다. 여러분은 반드시 적절히 SAP 자바 API들을 사용하여 이와 같은 거르개를 수행하는 코드를 작성해야 한다. 도우미(help) 시스템에서 -모호한 부분이 있지만- 쿼리 필터를 어떻게 작성해야 하는지에 대한 정보를 약간 얻을 수 있기는 하다. (이와 마찬가지로, 튜토리얼에서 제공하는 예제들에도 빠진 코드가 있어 제대로 API를 작성하기 힘들다.)

기본적인 모델 구조에서 여러분은 IDE에서 오퍼레이션들을 모델하고, 입/출력 타입들을 선택하며(이 둘은 컴포지트 애플리케이션 프레임워크에서 제공되며 여러분이 직접 모델화 해야 한다) 오퍼레이션들이 던져야 하는 예외들도 선택할 수 있다. IDE는 여러분을 위해 여러분의 모델 빈(bean)들에 메써드들을 만들어 주지만 껍데기만 있고 구현은 null을 반환하게 되어있다. 나머지 코드들을 구현하는 것은 직접 해야 한다. 내가 처음 만들어 본 것은 열린 상태의 태스크들 모듬을 반환하는 오퍼레이션으로 모든 태스크들을 open 상태 값으로 필터링 했다. 본래는 상태 값의 종류를 파라미터로 전달받는 것이 바른 접근 방법이라고 생각하고 모델화 하였지만, 파라미터 없이 메써드 안에서 처리하는 것이 맞는 방법 이었다.

UI 만들어 내기

나는 백엔드 모델이 프론트엔드 UI와 상호작용하기 위한 가장 올바르고 순수한 디자인을 찾는다는 방향으로 작업했고, 구제적으로는 비쥬얼 컴포져를 통해 이를 수행하였다.비쥬얼 컴포져는 UI 구축 도구로 거의 모든 부분을 드래그-앤-드롭으로 설정 가능한 지능형 위젯들을 포함하여 SVG등의 웹 기술들을 사용해 만들어 졌다. 코드는 필요 없었다. 웹 서비스들이 제대로 설치(deploy)되어 있다면 비쥬얼 컴포져가 그것을 사용할 수 있다. 이것은 여러분이 만든 확실한 WSDL 파일을 비쥬얼 컴포져가 접근할 수 있는 위치에 두어야 한다는 것을 의미한다.

나는 이 과정에서 문제에 봉착했다. 비지니스 모델들을 웹 서비스로 보여주는 방법은 여러 가지가 있었다. 프로젝트 네비게이터에 있는 콘텍스트 메뉴에서 모델들을 직접 보여주기 위한 옵션을 선택할 수 있다. 여러분은 또한 비지니스 모델들과 분리되어 자신만의 오퍼레이션들을 사용해 서비스 하도록 모델링 할 수도 있다. 나는 애플리케이션 서비스를 통하는 방법이 올바를 것이라고 가정했다. 하지만 내가 확인한 튜토리얼과 문서들 모드는 애플리케이션 서비스에 대해서는 매우 잘 되어 있었던 반면 생성된 메써드의 바디에 무엇을 담을지에 대해선 매우 적은 양의 정보만을 제공했다. 비지니스 로직을 작성하는 일은 편안했지만, 하지만 오퍼레이션들의 타입에 대해서는 좋은 참고문헌을 찾을 수 없었고 이런 로직을 수행하기 위해 준비되거나 제공된 API들을 찾을 수도 없었다.

만들어진 비지니스 모델들이 비지니스 모델 인스턴스들을 추가, 읽기, 갱신, 삭제 하기 위한 CRUD 메쏘드들을 모두 포함한다고 해도 생성된 애플리케이션 서비스는 기본적으로 아무 동작도 하지 않는다. 나는 오퍼레이션들을 비니지스 모델들과 연결하는 쉬운 방법을 알 수 없었다. 예상하건대 그 오펴레이션들을 직접 보여주는 방법이나 애플리케이션 서비스에 포함하는 것이 가능할 것이다. 비지니스 객체들을 모델링 하는 것과, 애플리케이션의 종류에 따라 각기 다른 API들을 포함해야 한다는 구조적인 규칙이 있다는 것을 이해할 수 있었지만, 이렇게 강제된 제약사항이 내가 수행하고 있는 간단한 목적에는 너무 과한 것처럼 보였다. (아마도 더 큰 프로젝트 에서는 그런 제약이 중요한 역활을 할 것이다.)

나는 테스트 모델들을 바로 웹 서비스로 보여주기로 결정했다. 비쥬얼 컴포져에서 사용하기 위해 웹 서비스를 내 SAP 서버에 등록하고 설정하는 것은 이 과정 중 가장 복잡한 부분이었다. IDE에서 웹 서비스들을 (웹 서비스 브라우져를 실행해) 테스트 하고, IDE 내부에서와 SAP 넷위버 서버에 서비스를 설치하는 것에 대한 설정을 하고, SAP 넷위버 관리자에서 웹 서비스들의 설치 위치를 만들고 있던 도중에 내게 도움을 주기 위해 아만다가 다가 왔다. 그때 까지는 비쥬얼 컴포져의 데이터 컴포넌트에서 내 웹 서비스들을 보기 위해서는 비주얼 컴포져를 재 시작 해야 했지만, 그 이후로는 시스템을 재 시작할 필요 없이 비쥬얼 컴포져의 서비스 검색 위젯에서 우 클릭을 하면 된다는 것을 알 수 있었다.

모든 것을 해 본 결과, 비쥬얼 컴포져를 사용해 UI를 구성하는 것은 간단한 일 이었다. 비쥬얼 컴포져는 버튼, 테이블 리스트, 입력 박스들을 포함하는 최소한의 메뉴들을 표현할 뿐이다. WSDL이 원격 호출과 변수 타입들을 포함하고 있기 때문에, UI 위젯을 적당한 파라미터와 연결하여 입/출력 디스플레이가 제대로 동작하는 것 같은 일을 쉽게 할 수 있다. 하나의 서식(form)에서 여러개의 웹 서비스들을 사용하는 것이 가능하며, UI은 한 부분(view)은 논리적인 관계들과 위젯들과 서비스들 간의 데이터의 흐름을 보여주고 다른 부분은 레이아웃 화면(view)을 보여 주여 실제 UI의 뷰 들을 재배치 하기 위한 화면으로 사용할 수 있다.

반나절 이상이 걸렸지만

모든 것이 함께 동작하도록 한 후에, 드디어 나는 작성하고-테스트하고-디버그 하는 사이클을 얻을 수 있었다. 내 실제 코드는 매우 조금 이었고, 내가 만든 서비스가 작은 것이었으며 몇 개 안 되는 오퍼레이션들을 가지고 있었음에도, 이 사이클은 빠르게 순환되지 않았다. SAP 서버와 IDE, 비쥬얼 컴포져를 수행하는 내 랩탑은 내가 만든 웹 서비스를 생성, 빌드하고 J2EE 서버에 배치하는데 수 분의 시간이 걸렸다. 그리고 비주얼 컴포져가 시작하는데도 몇 분의 시간이 걸렸다. 실험의 효율적인 사이클은 즉시 얻을 수도, 쉽게 얻을 수도 없다. 여려분이 비슷한 경험을 위한 일들을 수행하려 한다면, -컴포넌트들이 어떻게 연결되는지 알기 위한 용도로- 실존하는 간단하지 않은 애플리케이션을 파헤치는 것은 바람직하지 않다. 여러분이 각 부분들과 그들의 관계를 더 잘 이해할 수록 여러분의 실수를 수정하기 위해 역추적(backtrace)하고 재설치(redeploy) 하는 시간은 줄어들 것이다. 아무것도 없는 상태에서 모두 직접 해보려 한다면 시간이 매우 많이 필요할 것이다. 나는 또한 개발용으로 매우 뛰어난 성능의 기계를 사용하거나 서버용 머신을 개발용과 따로 운용하기를 권장한다.

간단한 애플리케이션을 빌드해 봄으로써 나는 이 시스템의 능력을 볼 수 있었다. 처음에는 모든 것이 제대로 동작하게 하는데 반나절 이상이 걸렸지만 이 일을 다시 수행하는 것은, 그리고 새 프로젝트를 수행하는 것은 더 쉽게 할 수 있을 것이다. 초기 시스템 설정과 웹 서비스의 설치를 제외하고는, 어렵고 시간을 잡아먹었던 부분은 문서가 듬성듬성 하거나 빠진 부분이 있을 때 뿐이었다.

이제 다음 작업은 이 애플리케이션의 설치와 배포를 위해 번들화 하는 것으로써 다음 기사에서 이에 관해 다루도록 하겠다.

---

저자 chromatic는 오라일리 오픈 테크놀로지 부서에서 자유/오픈소스 소프트웨어 운동을 추진하고 있습니다.