다시 꺼낸 양날의 검
UML
(Unified Modeling Language)

어느덧 10년 이상의 역사를 가지게 된 UML. 그 긴 세월만큼이나 UML은 개발자들의 오랜 화두로 자리매김해 왔지만 이를 바라보는 시각은 예나 지금이나 뚜렷하게 엇갈리고 있다. 실제로 UML을 충분히 써보지 않은 이들도 UML이 ‘양날의 검’이라는 데 대부분 동의한다. 이를 올바르게 활용하지 않으면 오히려 개발 작업을 더디게 만드는 장애가 될 수 있음을 알기 때문이다. 그래서일까 여전히 많은 개발자들이 실제 업무에서 UML의 도입을 망설이고 있다. UML에 바탕을 둔 많은 도구와 방법론이 소개되어 왔음에도 UML을 바라보는 ‘불편한() 인식’이 사라지지 않은 까닭이다. 지금이라도 서서히 바꿔보자. 3인의 필자가 전하는 편안한 이야기 속에서 UML을 다시금 돌아보고 실제 개발 환경과의 하모니도 모색해 보자.

기획ㆍ정리 | 전도영 기자 mir@imaso.co.kr

절반의 성공, UML
개발자의 미래를 열어라!

‘It’s time to do your stuff.’ 이 말처럼 이제는 UML(Unified Modeling Language)이 가진 이상과 가능성이 실현될 때가 되었다는 생각이 든다. UML은 현재 소프트웨어 업계에서 가지고 있는 많은 고민들을 해결할 수 있는 열쇠를 지녔다. 하지만, 여전히 많은 장벽들이 존재하고 있는 것도 사실이다. 그렇다면 모든 장벽들이 없어지기만을 기다려야 하는 것일까

임철홍 imich@skcc.com

UML이 세상에 알려지고 10년의 세월이 흘렀다. 그래서일까 UML 이야기를 하는 것이 마치 오래된 이야기를 하는 것 같은 느낌이다. 혹자는 이미 지나가버린 기술에 대한 이야기를 하는 것 아니냐고 반문할지도 모르겠다.
그러나 정말 UML이 제대로 활용되어 그 역할을 충분히 하고 있는지는 의문이다. 현재 많은 프로젝트에서는 CBD 방법론 채택을 꺼리고 있다. 모델링이 어렵고 산출물이 많다는 이유에서다. 물론 프로젝트의 입장에서는 정말 큰 문제임에 틀림없다. 많은 프로젝트에서 모델링 작업은 적잖은 시간이 소요될 뿐 아니라, 때론 복잡하고 불필요한 작업으로 인식된다. 대개의 경우 UML 다이어그램(Diagram)을 산출물의 그림으로써만 활용할 뿐이다. 그럼 UML은 실패한 것일까 그렇지 않다. 필자의 시각에서 보면 절반의 성공은 거뒀다고 본다. 프로젝트에서 요구사항 획득이나 분석단계의 모델, 그리고 초기 설계의 모델로 UML은 충분히 제 역할을 하고 있고 그만한 가치가 있다고 생각한다. 그럼 나머지 절반에서는 어떨까 이 글을 통해 잃어버린 나머지 절반에 대해 함께 생각해봤으면 한다.

객체 지향 기술과 UML

1970년대 초부터 다양한 분야에서 연구되어 온 객체 지향 기술은 1990년대에 들어서면서 다양한 방법론들과 표기법들을 등장시켰다. 그 중에서 특히 유스케이스(Use case) 개념을 기반으로 한 이바 야콥슨(Ivar Jacobson)의 ‘Object Oriented Soft ware Engineering(OOSE)’와 비즈니스/데이터 시스템의 분석을 강조하는 제임스 럼바(James Rumbaugh)의 ‘Object-Model ing Technique(OMT)’, 그리고 디자인과 구현 분야에 강한 그래디 부치(Grady Booch)의 ‘Booch method’가 주목을 받게 되었다. 이 각각의 방법론은 그 시발점이 달랐지만, 궁극적으로 유사한 방향으로 발전하게 될 것이라는 결론을 얻게 되었다.

특히 1995년 가을, 부치와 럼바가 통합된 방법론을 발표했는데 이것이 이른바 통합 모델링 언어, 즉 UML(0.8 버전)의 시초였다. 이후 야콥슨이 그의 방법론인 OOSE를 UML에 통합하면서 본격적인 표준 모델링 언어의 탄생을 예고했다. 1997년 1월에 UML 1.0을 후보로 제출했고, 같은 해 7월에 IBM, ObjecTime, Plati num Technologies, Ptech 등의 진영에서 제출한 또 다른 후보의 내용이 추가되어 UML 1.1로 버전업되었다. OMG는 이 후보에 대한 산업계의 피드백을 수렴한 후, 1997년 12월 UML 1.1을 공식적으로 채택하게 된다. 이후 UML은 OMG의 RTF(Revi sion Task Force)의 관리 하에 산업계의 의견을 수렴하고, 이를 바탕으로 여러 차례 마이너 버전 업그레이드를 경험한다. UML 1.2는 단순히 오탈자 수정 등을 목적으로 했던 편집용 버전이었고, 1998년 12월에 채택된 UML 1.3이 현재 널리 쓰이고 있다.

[그림1] UML의 변천사

UML 1.4는 UML 1.3에 객체제약언어(Object Constraint Language, OCL)를 추가한 버전이고, UML 1.5는 액션 시멘틱(Action Semantics)을 추가했다. 이어서 2003년 8월에 공식적으로 UML 2.0이 발표되었다.

S/W 세상의 공통 언어 UML

UML이 국내에 처음 소개된 이후, 지원 툴과 객체지향/CBD 방법론의 보급에 따라 UML이 이제 보편화되어 활용되고 있다. OMG의 UML 정의에 따르면 UML은 S/W시스템의 가시화, 명세(설계), 구현, 문서화를 지원하는 도형으로 표현된 언어 표준이다. 이 UML을 활용해 S/W의 분석과 설계, 그리고 구축과 관련된 산출물을 정의할 수 있고, 이러한 산출물을 통해 의사소통에도 활용할 수 있다.

[표1] 마르미III 바법론의 단계 및 산출물

흔히 UML을 객체지향 방법론이나 CBD 방법론 등과 혼동하는 경우가 있지만, 엄밀히 말해 개별 방법론에서 특정 Activity의 산출물을 UML로 정의해 활용하는 것이다. 모든 객체지향 및 CBD 방법론에서 UML을 활용하고 있으므로 UML은 곧 S/W 세상의 공통어라고 할 수 있다.

UML은 <그림 2>와 같이 Use case, Class, Object, Activity, State, Sequ ence, Collaboration, Package, Com ponent, Deployment Diagram으로 구성되어 있다. 개별적인 다이어그램의 활용법은 이미 많이 소개되어 있으므로, 관련 Resource를 구하기는 어렵지 않다.

그럼 한 가지 예로 국산 CBD 방법론인 마르미III에서 UML이 어떻게 활용되고 있는지를 살펴보자. 마르미III는 <표 1>과 같은 Activity와 산출물로 구성되어 있다(테스트, 개발 전략 등은 생략하고 모델과 관련된 부분만 명시).

[그림3] 지원자 컴포넌트의 Class Diagram

[그림4] 지원자 컴포넌트의 지원 등록 Sequence Diagram(일부 생략)

[그림5] 모델과 메타모델의 관계

유스케이스 모형 기술서, 클래스 모형 기술서, 컴포넌트 명세서, 컴포넌트 설계서 등의 산출물이 모두 UML로 표현된다. <그림 3>은 컴포넌트 설계서의 활용 사례이다. 이는 컴포넌트를 구성하는 요소간의 Class Diagram과 Sequence Diagram으로 구성되어 있다. 사례 컴포넌트는 채용에 관련된 업무 가운데 채용 지원에 관한 컴포넌트로, 지원자의 개인 정보와 경력, 학력, 스킬 등에 대한 정보를 가지고 있다.

채용 지원자에 대한 정보 입력을 위한 Sequence Diagram은 <그림 4>와 같다. 이는 채용 지원자에 대한 개인정보, 스킬, 학력에 대한 정보를 생성한다.

새로운 시작 UML 2.0

UML 2.0이 등장하게 된 배경에는 UML 1.x의 태생적 한계가 있었다. 채택되는 과정에서 충분한 검토를 거치지 못한 UML 1.x는 구조적으로 여러 가지 문제점을 안고 있었다. 가장 심각한 문제는 당시 OMG가 추진하고 있던 MDA 전략의 핵심인 MOF와 UML의 메타모델이 100% 호환되지 않는다는 점이었다. UML 2.0은 UML 1.x 대와 비교해 많은 부분이 변경되었다. 변경된 특성을 요약하면 다음과 같다.

아키텍처의 개선

UML 1.x 대의 물리적 메타모델을 개선해 메타-메타모델인 MOF와 완벽하게 호환될 수 있게 했다. 여기서 메타모델이란 모델을 정의하는 모델로, 이들의 관계를 도식화 하면 <그림 5>와 같이 2개의 계층으로 나타난다.
메타모델 계층의 Class 클래스나 Association 클래스는 메타 클래스로서 각각의 UML 모델 요소, 즉 클래스와 연관 관계를 정의하는 데 사용된다. 모델 계층의 Person 클래스와 Car 클래스는 Class 클래스의 인스턴스이고, 이들 클래스간의 연관 관계는 Association 클래스의 인스턴스이다. 즉 우리가 일반적으로 작성하는 모델들은 모델 계층에 속하고, UML의 스펙은 메타모델 계층에 속한다. 마찬가지로 UML 메타모델에 대한 메타모델이 필요한데, 바로 MOF가 메타-메타모델로서 이 역할을 맡는다. UML 메타모델의 모든 모델 요소들을 MOF로 완벽하게 정의함으로써 MDA의 모델링 언어로 UML을 사용할 수 있게 되었다.

MDA(Model Driven Architecture)

MDA는 아키텍처를 소프트웨어 도구를 이용해 만들어냄으로써 실제 소프트웨어 개발 과정에서 특정 애플리케이션을 쉽게 작성하고, 또한 애플리케이션을 다양한 변경 요구에 맞게 쉽게 변경하는 것을 의미한다. 즉, 모델링으로부터 애플리케이션 코드를 자동으로 생성하고 구현하는 것이다. MDA의 기본 개념은 PIM(Platform Independent Model, 플랫폼 독립 모델)과 PSM(Platform Specific Model, 플랫폼 종속 모델)으로 구분된다. 두 가지 개념 모두 개별 업무에 대한 로직을 포함하고 있지만, PIM은 절대적으로 플랫폼 또는 미들웨어에 대한 종속성이 없는 모델을 말하고, 반대로 PSM은 플랫폼 또는 미들웨어에 대한 종속성이 모델 내에 존재하는 것을 의미한다. 또한 비즈니스 모델은 개별적인 서비스/비즈니스에 대한 모델을 의미하고, 분석 모델은 이러한 서비스/비즈니스에 기초한 실제 개발 모델을 의미한다. 이 두 가지 모델은 모두 플랫폼 독립 모델, 즉 플랫폼의 영향을 전혀 받지 않는 모델이 되는 것이다.

컴포넌트 기반 개발(CBD) 지원

UML 2.0은 EJB나 COM+와 같은 최신 기술이 적용된 CBD를 완벽하게 지원하도록 확장되었다. 컴포넌트를 ‘내부가 은닉(캡슐화)되고 런타임 시 대체 가능한 시스템 모듈’로 재정의하고, 아울러 이를 명세하고 설계하고 개발하는 데 필요한 개념들과 조립하는 데 필요한 개념들을 모델링 가능한 모델 요소들을 새롭게 추가했다.

<그림 6>은 분석 수준의 블랙박스 컴포넌트 명세를 위한 표기법이다. 먼저 좌측의 동그란 원이 붙은 막대 표시는 컴포넌트가 제공할 서비스를 명세하는 제공 인터페이스(Provided Inter face)이다. 한편 반대쪽의 반원이 붙은 막대 표시는 컴포넌트가 외부 환경으로부터 제공받는, 즉 요청하는 서비스를 명세한 요청 인터페이스(Required Interface)이다.

[그림6] 블랙박스 컴포넌트의 명세

<그림 7>은 설계 수준의 화이트박스 컴포넌트 표기법으로 인터페이스에 대한 명세뿐 아니라, 이를 구현하고 있는 컴포넌트 내부의 모델 요소들을 설계할 수 있도록 지원한다. <그림 7>에서 <<realizations>> 키워드는 Order 컴포넌트를 실현하는 컴포넌트 내부의 클래스들을 의미하고, <<artifacts>> 키워드는 이 컴포넌트의 물리적 배포 단위(파일)를 나타낸다.

[그림7] 화이트박스 컴포넌트의 명세

UML 2.0은 언급한 모델요소 이외에도 컴포넌트 내부와 외부 환경을 완전히 분리해 재사용성을 극대화 하는 포트(Port)의 개념들을 새롭게 도입하는 등 실질적인 CBD 지원을 위해 많은 부분을 강화했다.

비즈니스 프로세스 모델링 지원

UML 1.x는 Activity를 상태 차트의 부분 집합(Subset)으로 정의하고 있다. 이러한 구조는 비즈니스 프로세스 모델링(Work flow 모델링)시 Activity Diagram이 가져야 할 특징들을 담아내는 데 한계가 있었다. UML 2.0은 이러한 제약사항들을 극복하기 위해 Activity를 상태 차트의 메타모델로부터 완전히 분리시키고, 추가적으로 필요한 다양한 모델 요소들을 새롭게 정의하고 있다. <그림 8>에서 내부의 작은 타원들은 더 이상 분할되지 않는 행위의 최소 단위인 액션을 나타낸다. Activity는 이러한 액션들의 집합으로 정의될 수 있다.

[그림8] Activity 사례

<그림 8>은 주문 처리(Process Order) Activity의 사례인데, 이 Activity는 Order 타입의 Requested Order란 객체를 입력 파라미터로 받고 있으며 주문 완료란 선행조건과 주문 종료란 후행 조건을 갖는다. 여기서 <<singleCopy>>란 키워드는 이 Activity가 1회만 실행되어 공유 및 사용된다는 의미이다. Activity Diagram이 갖는 또 하나의 중요한 의미는 액션을 이용해 메소드의 상세 로직까지 모델링이 가능해졌다는 점이다. 이는 기존의 골격(Skeleton) 수준의 코드 생성이 아니라 상세 수준의 코드까지 생성해 낼 수 있음을 의미한다. 액션은 MDA 구현을 위한 필수 요소라 할 수 있다.

리얼타임 시스템 모델링 지원 강화

UML 2.0은 리얼타임 시스템 모델링에 필요한 개념 및 모델 요소들을 대폭 강화시켰다. 대표적인 예로 Interaction Diagram의 일종인 Timing Diagram을 새롭게 추가해 리얼타임 시스템에서 중요하게 다루는 시간에 따른 상태 변화를 모델링 할 수 있게 되었다.

리얼타임 시스템 모델링 시 주로 사용되는 Timing Diagram은 시간 흐름에 따른 상태 변화를 모델링하는 데 사용된다. <그림 9>에서 가로축은 시간의 경과를, 세로축은 라이프라인의 상태 변화를 각각 나타낸다. 만일 특정 시간(2)에 Code 이벤트가 발생하면 Idle 상태에 있던 사용자는 WaitCard 상태로 변화한다. 이후 일정 기간(기간 제약)내에 CardOut 이벤트가 발생하면 WaitAccess 상태로 바뀌고, 이후 OK 이벤트가 발생하면 일정 시간(시간 제약) 내에 다시 Idle 상태로 되돌아온다.

[그림9] Timing Diagram

UML 영역의 확장

UML은 UML 프로파일을 통해 다양한 도메인에 대한 상세 모델을 제공하고 있다. 궁극적으로는 MDA를 실현하기 위한 상세 모델로써 다음의 프로파일이 존재한다.

- Platform Independent Model (PIM) & Platform Specific Model (PSM) for Software Radio Components (also referred to as UML Profile for Software Radio)
- UML Profile for CORBA
- UML Profile for CORBA Component Model (CCM)
- UML Profile for CORBA and CORBA Component Model (CCM) [This specification, nearly complete, will supersede the separate profiles listed just above.]
- UML Profile for Enterprise Application Integration (EAI)
- UML Profile for Enterprise Distributed Object Computing (EDOC)
- UML Profile for Modeling QoS and Fault Tolerance Charac teristics and Mechanisms
- UML Profile for Schedulability, Performance and Time
- UML Profile for System on a Chip (SoC)
- UML Profile for Systems Engineering (SysML)
- UML Testing Profile

이처럼 시스템에 대한 모델링, 컴포넌트 모델, 임베디드(SoC), 애플리케이션 통합 (EAI) 등의 다양한 분야를 지원하고 컴포넌트 구현을 위해 EJB를 위한 UML 프로파일을 활용할 수 있다. UML 프로파일에 대한 이해를 위해 EJB UML 프로파일에 대해 살펴보자. EJB UML 프로파일과 관련해서는 <표 2>와 같이 스테레오 타입이 정의되어 있다.

표준에서 명시한 스테레오 타입을 활용해 모델링을 하면, 해당 객체가 실제 구현 레벨에서 어떤 객체가 되는지를 알 수 있다. 여기서 <<EJBRemoteInterface>>로 표시된 객체는 EJB의 remote 객체임을 알 수 있다. MDA 환경에서 이용하면 이러한 스테레오 타입 기준으로 실제 구현 객체로의 자동적인 생성을 할 수 있다.

[표2] EJB의 UML 프로파일

현재 UML을 다양하게 적용하기 위한 시도가 계속되고 있다. S/W 아키텍처를 정의하는 ADL(Architecture Description Language)에서의 활용이나 온톨로지(Ontology) 분야를 위한 학계의 연구가 그 대표적인 예다.

UML의 현실과 전망

UML은 이처럼 모델링을 위한 표준 이상의 비전과 가능성을 지녔다. 하지만 다음과 같은 문제점으로 인해 제대로 활용되지 못하는 게 사실이다.

● 모델링 언어에 대한 무관심과 무지
UML의 정의에서는 UML을 하나의 언어로 표현하고 있다. 언어는 자신만 알아서 되는 것이 아니라, 상대방도 함께 알아야만 상호 커뮤니케이션이 이뤄진다. UML이 발표된 지 오래되었고 관련 서적과 자료가 다수 존재함에도 여전히 UML을 모르는 사람이 많다.

● 전문 모델러의 부재
UML과 같은 모델링을 담당하는 사람과 실제 코드를 구현하는 개발자가 동일할 경우, 모델링의 필요성을 느끼지 못한다. 현재의 프로젝트에서 모델링은 개발자가 직접 수행하거나 업무 분석가가 수행하는 형태로 진행된다. 개발자와 업무 분석가 사이에서 역할을 수행할 전문 모델러가 없는 것이다.

● 모델링에 대한 인식 부족
작성된 모델은 대체로 아이디어 정리와 개발 표준 명시, 그리고 산출물을 만드는 용도 등으로만 활용된다. 프로젝트 분석이나 설계의 초기 단계에서만 활용하고, 나머지는 새롭게 구현하는 형태로 진행되고 있는 것이다. 모델을 그냥 보여주는 형태로만 활용되는 것이 아니라, 실제로 개발에 활용하는 모델이 되어야 할 것이다.

● 지원 툴의 기능 부족 및 기능의 무지
현재의 모델링 툴들은 MDA의 초기 기능을 어느 정도 가지고 있어 Class의 생성 등을 지원한다. 하지만 이를 위해서는 모델링이 상세히 구성되어야 하는데 툴에서의 지원 기능이 아직은 부족해 제대로 활용되지 못하고 있다. 또한 툴에서 제공하는 기능을 잘 활용하지 못하고, 오직 모델 만드는 데만 활용하는 것도 문제점으로 지적된다.

서두 부분에서 UML은 현재 절반의 성공을 거뒀다고 말했다. 필자가 말한 나머지 절반은 아마도 OMG에서 지향하고 있는 MDA일 것이다. 이는 모델링만 잘 하면 애플리케이션이 자동으로 만들어지고 변경되는 환경이다. 가까운 시일 내에 갑작스레 실현되지는 않겠지발전할 것이다. MDA가 실현된다면 다소 과장일 수 있지만, 개발자가 사라지고 모델러만 존재하게 될 것이다. 그때는 모델러를 개발자라 할지도 모른다.

그렇다면 지금 상황에서 UML을 어떻게 활용해야 할까 MDA가 실현되기까지 오래도록 기다릴 것인가 아니면 전체적인 흐름에 역행하더라도 UML을 아예 배제할 것인가 필자는 이럴 때 UML을 적극적으로 익히고, 더욱 더 확산시켜 UML이 주는 장점들을 최대한 활용해야 한다고 생각한다. 현재의 프로젝트 환경에서 UML과 툴이 제공하는 이점들을 잘 활용하면 프로젝트의 생산성과 품질 향상에 큰 도움이 될 것이다. 아울러 모델링 툴에서 제공하는 자동화 기능을 최대한 활용하면 단순 반복 작업을 크게 줄일 수 있다.

지금까지 UML의 시작과 활용 사례, 그리고 활용 전망 등을 살펴봤다. 개발자를 단지 ‘코드를 작성하고 구현하는 사람’이라고만 여긴다면 개발자가 할 일이 모두 사라지거나, 아니면 단순 작업을 하는 직업으로 인식될지도 모른다. 필자는 현재 화두가 되고 있는 S/W 아키텍처, 모델링 등이 모두 개발자의 영역이라고 생각한다. 또한 SOA, 웹2.0, 온톨로지 분야에 많은 개발자들의 힘과 노력이 요구되고 있다. 이러한 신기술 및 패러다임에 적극적으로 대처해 개발자의 입지를 더욱 확고히 하고 동시에 가치를 높이려는 시도가 필요하다. 아마 UML은 그런 노력의 중심에 머무르게 될 것이다.

참고문헌
1. http://www.omg.org/technology/documents/modeling_spec_catalog.htm - UML Specification
2. http://www.omg.org/technology/documents/profile_catalog.htm - UML Profiles Catalog
3. EJB UML Profile(JSR-000026 UML/EJB(TM) Mapping Specification 1.0)