컨피규레이션 중심의 개발 (한글)
코드 수정과 중복에 대한 실질적 접근 방식
난이도 : 중급
Steve McDuff, Software team leader, IBM, Intel, Microsoft,HP
2007 년 1 월 09 일
코드 중복은 사건이 발생하기를 기다리는 것과 비교할 수 있습니다. 누군가가 코드를 수정하고 이것을 중복 소스로 전달하는 것을 잊어버리기를 기다리는 것과 같은 이치입니다. 그 결과는 차이가 있겠지만, 그 규모가 어떻든지 중복은 문제의 근원이 됩니다. 이 글에서 IBM 개발자 Steve McDuff가 치료책으로서 설정 중심 개발을 제안합니다.
설정 중심 개발(configuration-driven development)과 모델 중심 개발(model-driven development)의 차이는 전자는 클래스, 필드, 관계 같은 코드의 모델로 제한되지 않는다는 점이다. 설정 중심 개발(CCD)은 애플리케이션 내에서 설정될 수 있는 모든 것을 포괄한다. 예를 들어, 특정 비즈니스 규칙이 애플리케이션에 일관되게 적용되어야 하는 아키텍처에서, 설정 파일을 사용하여 그러한 규칙을 설정 및 적용할 수 있다.
이 글에서, 설정 중심 개발을 소개하고, 이것으로 코드 중복과 수정 문제를 해결하는 방법을 설명한다.
코드 중복과 수정
다음과 같은 컴포넌트들로 구성된 애플리케이션으로 작업한다고 생각해 보자.
- 데이터베이스
- 웹 서비스 애플리케이션 프로그램 인터페이스(API)가 있는 미들웨어 서버
- 웹 기반 사용자 인터페이스가 있는 미들웨어 서버
- 미들웨어 API를 사용하는 THICK 클라이언트
그림 1. 매개변수
그림 1을 보면, 스트링의 길이 같은 간단한 매개변수들이 네 개의 모든 컴포넌트들에 영향을 미치는 것을 알 수 있다. 또한, 다음과 같은 사용자 문서와 단위 테스트 영역에도 영향을 미친다.
사용자 문서:
- THICK 클라이언트
- 웹 기반 사용자 인터페이스
- 웹 서비스 API
단위 테스트 영역:
- 데이터베이스
- 웹 서비스 API
- 웹 기반 사용자 인터페이스
- thick 클라이언트
그림 2는 그림 1의 매개변수의 영향력을 묘사한 것이다.
그림 2. 의존성 과잉
갑자기 스트링 길이 같이 단순한 것이 네 군데가 아닌, 10 개의 다른 곳에 중복되었다. 스트링 길이 매개변수는 예제에 불과하다. 많은 비즈니스 규칙 유형들이 일반 애플리케이션에 이와 비슷하게 영향을 미칠 수 있다. 스트링 길이와 최소/최대 숫자 값처럼, 몇 가지 규칙들은 거의 모든 애플리케이션에 공통적이다. 다른 규칙들은 특정 애플리케이션에 필요에 맞게 특화된다. 애플리케이션이 체크아웃, 체크인 메커니즘을 사용하여 동시성을 방지하는가? 어떤 정보를 클라이언트에서 가져오고, 서버에서 가져올 것인지에 대한 규칙이 있는가? 이러한 모든 요소들이 작동하고, 가장 간단한 코드 변경을 쉽게 수행할 수 있도록 하는가?
전통적인 솔루션
정보 중복은 전혀 새로운 문제는 아니며, 이를 방지하는 여러 툴들과 기술이 존재하고 있다. 이 섹션에서는 정보 중복과 관련한 가장 일반적인 솔루션을 제안하고자 한다.
- 개발 프로세스
- 어떤 개발팀들은 과잉 정보 수정을 엄격한 개발 프로세스의 일부로 채택하여, 정보 중복을 해결한다. 이 솔루션은 감독과 리뷰가 필요하기 때문에 귀찮은 일이기도 하지만, 효과적이다.
- 잘 설계된 코드
- 잘 짜인 코드는 상수의 재사용과 짝을 이루면서 코드 중복 문제를 줄일 수 있다. 코드 중심 솔루션은 애플리케이션의 모든 부분들이 같은 언어로 작성될 때 가장 큰 효과를 볼 수 있다.
- 모델 중심 툴
- 모델 중심 개발 개념은 애플리케이션 모델을 하나의 설정으로 읽는 것이다. 모델 중심 툴의 가장 큰 장점은 객체들과 이들의 관계와 관련된 지루한 작업들을 자동화 한다는 점이다. 다음은 모델 중심 개발용 툴들이다.
- Eclipse Modeling Framework (EMF): 클래스와 필드의 레이아웃을 저장한다. 자바 클래스, 네트워크 인터페이스, 심지어는 애플리케이션의 데이터베이스 매핑까지 생성한다. 객체들을 생성함으로써, EMF는 getters, setters, equals, copy, clone, serialization 같은 메소드를 작성하는 지루한 과정을 자동화한다. EMF는 많은 객체 정의들을 저장할 수 있는 설정 파일들을 사용한다. 멀티 유저 환경에서, 이러한 파일들을 합병할 경우 몇 가지 문제가 일어날 수 있다. EMF는 애플리케이션의 객체들, 이들의 관계, 메소드로 국한된다. 커스텀 비즈니스 규칙을 다루는 것과 관련한 지원 사항이 없다.
- UML2: 클래스 관계 다이어그램, 필드, 로직을 통해 애플리케이션을 설명한다. UML의 장점은 언어 중립적이라는 점이다. 논리적 디자인이 만들어지면, 많은 언어들로 객체들을 생성할 수 있다.
- Ruby on Rails: 데이터베이스 스키마에서 모델의 설정을 추출한다. 그런 다음, 비즈니스 로직, 웹 기반 사용자 인터페이스, 단위 테스트를 수행할 테스트 베드를 만든다. 가장 큰 장점은 데이터베이스 스키마 변경이 쉽게 코드에 적용될 수 있다는 점이다.
CDD 작동 방법
설정 중심 개발의 기초를 이미 설명했다. 작동 방법을 이해할 수 있도록, 예를 들어 설명하겠다. 이 섹션에서는, 우리 팀이 Rational Portfolio Manager의 개발에 사용했던 설정 중심 개발 솔루션을 설명하도록 하겠다.
XML 파일로 설정 저장하기
설정 중심 개발에서, 개발자들은 주로 XML 파일로 수정한다. 애플리케이션과 관련된 다른 모든 파일들은, 런타임 시 또는 구현 시 선택된 부분들을 생성할 때, 이 파일에서 설정을 읽는다. Rational Portfolio Manager의 경우, 다음과 같은 컴포넌트와 정보들을 설정 파일에 저장했다.
애플리케이션 객체들
- 관계
- 문서화
- 밸리데이션 규칙
- 체크인/체크아웃 작동 방식
- 애플리케이션 보안 프레임웍에서의 제약 사항
- 데이터베이스 매핑
- 시각적인 레이아웃에서의 배치
에러 코드
- 고유 식별자
- 문서
- 런타임 시 생성한 메시지
- 사용한 매개변수
웹 서비스 인터페이스 정의
- 노출된 메소드
- 문서
- 밸리데이션 규칙과 함께 사용한 매개변수
- 애플리케이션 보안 프레임웍에서의 제약 사항
그림 3은 전형적인 설정 중심의 구현 과정이다.
그림 3. 설정 중심 구현 프로세스 샘플
필요한 툴
다음 툴들은 설정 중심 개발에 필수적이다.
- 편집용 툴
- 대부분의 경우, 간단한 텍스트 에디터로 XML 파일들을 편집할 수 있다. 좋은 XML 에디터는 파일이 수정될 때 문법을 검사하고, XML 태그 편집을 단순화 한다.
- 읽기용 툴
- XML 파일을 활용하려면, XML 파일을 애플리케이션에 넣을 수 있는 툴이 필요하다. 예를 들어, 자바 라이브러리 Betwixt를 사용하여 자바 파일을 XML 설정들로 채울 수 있다.
- 객체 생성을 위한 툴
- 설정 파일을 읽었다면, 제품의 다른 부분들에 정보를 주어야 한다. 이 시점에는 몇 가지 옵션들이 있다. 소프트웨어에 설정 파일들을 삽입하여, 이들이 런타임 시 읽힐 수 있도록 한다. 또 다른 방법은, Apache Commons의 Java Velocity 엔진 같은 툴을 사용하여 코드와 문서를 만드는 것이다.
규칙
대부분의 애플리케이션 개발자들은 다음과 같은 규칙들을 잘 알고 있다. 하지만, 설정 중심 개발에서는 자바 개발이나 익스트림 프로그래밍과는 다르게 적용한다.
1. 단순함을 유지하라!
설정 파일들은 이해하기 쉽고 변경하기도 쉬워야 한다. 옳은 소리이긴 하지만, 숙련된 XML 사용자들은, 읽고 이해하기 어려운 XML을 실행하는 신택스 같이, CDD 방식과는 잘 맞지 않는 고급 기능들을 사용한다.
2. 적절하게 변화할 필요도 있다!
사전 설치된 어떤 XML 레이아웃도 모든 개발자의 필요를 맞출 수 없다. 해결책은 여러분의 XML 레이아웃을 여러분의 필요에 맞게 맞추는 것이다. 도메인 또는 소프트웨어 아키텍처에 따라, 클래스나 필드 정의에 사용되는 XML 애트리뷰트는 매우 다양하다. 이러한 진화는 사용자가 “단순함을 유지하라”는 규칙을 깨지 않도록 한다. 위 예제에서, 다른 제품 정황에서는 쓸모 없는 많은 설정 매개변수들이 많이 있음을 쉽게 알 수 있다. 어떤 툴도 구현을 단순화 할 수는 없다.
3. 조기에, 자주 유효성 검사를 하라!
개발 프로세스 초기에 잡힌 에러들은 해결하기가 가장 쉽다. 이러한 원칙에 따라, 가능한 빨리 설정에 대한 유효성 검사를 수행하라. 예를 들어, XSD나 DTD 파일을 사용하여 설정 파일의 XML 구조를 검사할 수 있다. 커스텀 밸리데이션 규칙을 적용해야 한다면, 망설이지 말고 밸리데이션 툴을 구현하라. 이러한 툴을 만드는데 드는 시간은 투자할 가치가 있다.
효과, 대가, 한계
새로운 방식을 채택하기 전에, 그 효과는 물론이고, 대가 계산 및 한계에 대해서 생각해야 한다. 이 섹션에서는 이 세 가지 부분에 대해서 생각해 보고자 한다.
효과
- 중복 감소
- 첫 번째 효과는 정보 중복이 줄어든다는 점이다. 이는 제품의 관리성과 전체적인 품질을 높인다.
- 특정 벤더에 얽매이지 않는다.
- XML을 편집할 때 기본 툴을 사용함으로써, 특정 벤더의 툴에 얽매이지 않는다. XML 파일을 읽고 편집할 수 있는 많은 오픈 소스 툴들이 있다.
- 소스 컨트롤
- 일부 솔루션은 아웃풋을 합병이 거의 불가능한 상용 XML 포맷에 저장한다. 그러한 XML 파일들간 레퍼런스는 문제를 일으킨다. 단 한 팀에게만 설정 파일을 수정할 권한을 주는 것은 효율적이지 못하다. 사람들이 편집한 XML 파일은 멀티-유저 환경에서 CVS, Subversion, Clearcase 같은 소스 컨트롤 툴과도 잘 작동한다.
- 작업에 맞는 툴
- 대부분의 툴들은 매우 일반적인 필요를 다루지만, 모든 프로젝트 마다 고유의 필요가 있기 마련이다. 이것 때문에 모든 필요를 다 맞출 수 있는 툴을 찾기가 힘든 것이다. 커스텀 설정 파일들은 자신의 프로젝트와 관련된 정보만 포함시킬 수 있는 장점이 있다.
- 기술 독립성
- 일부 툴은 설정 파일들을 사용하여 애플리케이션을 기반 기술로부터 고립시킨다. 예를 들어, Hibernate는 설정 파일에 데이터베이스와 객체들 간 관계를 저장하고, 벤더 스팩의 데이터베이스 구현으로부터 사용자를 독립시킨다. 이것은 완벽하지는 않지만, 앞으로 애플리케이션 진화에 도움이 된다는 측면으로 볼 때 바람직하다.
대가
- 올바른 구조 확립하기
- 올바른 구조를 확립하기 위한 초기 비용은 무시 못한다. 올바른 툴을 사용한다 하더라도 문제는 일어나기 마련이다. 설정 중심 개발은 중대형 프로젝트에 알맞다.
- 빌드 프로세스 복잡성
- 설정 파일에서 애플리케이션 일부를 생성할 때, 빌드 프로세스는 복잡해질 수 있다. 적절한 빌드 자동화를 사용하여, 가격을 낮출 수 있다.
한계와 문제점
- 비즈니스 규칙 복잡성
- 기본 개념들은 설정 파일들로 쉽게 매핑되지만, 복잡한 비즈니스 규칙들은 완전히 다른 문제이다. 작은 변화에도 복잡한 규칙이 등장한다면, 그러한 변화들만 저장하는 설정 파일을 만들 수 있다. 효율성 측면에서, 복잡한 비즈니스 규칙들을 코드에 두고, 반복적인 개념은 설정 파일에 저장하는 것이 최상의 방법이다.
- 인프라스트럭처 비용
- 작은 프로젝트의 경우, 인프라스트럭처를 확립하는 비용이 프로젝트 비용 보다 더 많이 든다. 게다가, 작은 프로젝트는 정보 과잉 문제를 겪지 않는다.
XML 코드 샘플
Listing 1은 리소스(또는 사용자) 구조를 나타내는 XML 파일 샘플이다. 다음은 이 샘플 XML 코드의 애트리뷰트 리스트이다.
- Class: 자바 클래스의 이름
- Extends: 부모 자바 클래스의 이름
- Abstract: 클래스가 추상 클래스인지, 자바에 없는 것인지를 나타냄.
- TestReady: 코드 제너레이터가 클래스용 단위 테스트를 만들어 내는지의 여부를 나타냄.
- Field name: 필드에 대한 자바 변수 이름
- Field type: 필드에 사용된 자바 유형
- Field label: 특정 필드에 대한 사용자 인터페이스에 사용되는 레이블
- Field min and max: 스트링의 최대/최소 길이 또는 값
- Field default: 객체 생성시 필드에 적용하는 디폴트 값
- Field composite: 필드가 레퍼런스인지, 합성 관계인지를 나타냄.
- Field valid types: 추상 객체들의 어레이에 저장될 수 있는 유효 유형들.
- Field mandatory: 객체가 생성될 때 이 필드가 필수적인지의 여부를 나타냄.
- Field readable: 사용자가 필드를 읽을 수 있는지의 여부를 나타냄.
- Inherited field overrides
Listing 1. 리소스(또는 사용자) 구조를 나타내는 샘플 코드
<?xml version="1.0"?>
<object
class="sample.Resource"
abstract="false"
extends="sample.BaseObject"
testready="false"
documentation="A resource represents a user of the system.">
<rule
type="create"
documentation="To create a resource,
the user must have the administrator
security rights" />
<rule
type="update"
documentation="A resource has the right to modify
itself. Only administrators have the right to modify
resources otherwise." />
<rule
type="delete"
documentation="Administrators have the right
to delete a resouce." />
<field
name="active"
label="Active"
type="java.lang.Boolean"
default="true" />
<field
name="calendar"
label="Calendar"
type="sample.WorkCalendar"
composite="false" />
<field
name="contactGroupAssignments"
type="sample.ContactGroupAssignment[]"
composite="true">
<valid-type
class="sample.ContactGroupAssignment" />
</field>
<field
name="name"
label="Full Name"
type="java.lang.String"
mandatory="true"
max="35" />
<field
name="password"
label="Password"
type="java.lang.String"
min="3"
max="16"
readable="false" />
<!-- BaseObject -->
<inherited
name="parent"
mandatory="true">
<valid-type class="sample.ResourceFolder" />
<invalid-type class="sample.Project" />
</inherited>
</object> |
설정 파일을 사용하여, 다음을 만들 수 있다.
- 데이터베이스 레이아웃
- 웹 서비스 인터페이스
- 자바 모델 클래스
- 사용자 문서
- 레이블을 사용하고 툴 팁과 도움말 파일 관련 문서를 삽입하는 사용자 인터페이스
- 설정 애트리뷰트와 규칙을 위한 단위 테스트 프레임웍
맺음말
이상적으로는, 설정 중심 개발을 사용하여 전체 제품을 구현할 수 있다. 개발 프로세스는 두 단계로 구성된다.
- 필요한 추상 툴을 구현한다.
- 제품 완성을 위해 툴을 조합하는 방법을 나타내는 설정 파일을 사용하여, 애플리케이션을 구현한다.
설정 중심 개발은 완전히 새로운 개념은 아니지만, 제약이 많은 현대적인 환경에서 이를 효과적으로 운영하는 것은 도전이 되는 문제이다. 이 글에서는, 설정 중심 개발 프로세스 성공에 필수적인 요소들에 대해 짚어보았다.
기사의 원문보기
참고자료
교육
- Explore model-driven development (MDD) and related approaches (Tracy Gardner and Larry Yusef, developerWorks, March 2006)
- 다중 스레드 애플리케이션 프로그래밍을 쉽게 (한글) (Ze'ev Bubis와 Saffi Hartal, developerWorks, 2002년 2월): 생산자-소비자 행위를 간단하게 구현할 수 있도록 하는 Consumer 클래스
- Automation for the people: Continuous Inspection (Paul Duvall, developerWorks, August 2006)
- 디벨로퍼웍스 웹 개발 존 (한글 페이지): Web 2.0, Ajax, wikis, PHP, mashups, 기타 웹 프로젝트의 참고자료
- Technology bookstore
- developerWorks technical events and webcasts
제품 및 기술 얻기
토론
필자소개
 |
|
| |
Steve McDuff는 Rational Portfolio Manager 웹 서비스 인터페이스 부분 개발 팀 리더이다.
|
