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

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

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

효과적인 모델링을 위한
UML의 전략적 활용

처음으로 개발자의 UML 사용을 돕던 시절, 모델링 도구의 단축키 조합으로 복잡하게 엉켜있는 선들을 빠르게 풀어주면 놀라곤 했다. 지금 그때를 떠올리면 웃음이 난다. 이제 많은 프로젝트에서 UML을 사용하고 익숙한 사람들을 흔히 만날 수 있다. 그러나 UML의 활용 행태는 5년이 지난 지금도 별반 나아지지 않았다. 이제 여러분들이 UML에 대한 경험을 조금이라도 갖고 있다면 지금이야말로 어떤 일을 위해 그것을 사용하고 어떻게 해야 효과적이고 생산적으로 활용할 수 있을지를 고민해야 한다.

안영회 younghoe@epril.com

UML에 대해 잘 모르는 고객을 만나면 흔하게 볼 수 있는 패턴이 있었다. UML에 대해서도 그렇고, RUP나 CBD 방법론과 같은 비교적 새로운 기술이나 기법을 적용하면 무언가 획기적으로 바뀔 것이라고 오해하고 있다는 사실이다. 과연 그런가 UML을 적용했다고 해서 소프트웨어 개발 현장의 문제가 획기적으로 개선되는가

UML에 대한 미신

상식적으로 생각해보자. UML이 새로운 기술이기 때문에 선택했다고 가정해보자. 새로운 기술이니까 관계자들이 배우는 데 시간이 필요하다. 몇 시간 혹은 몇 일 교육으로 새로운 기술을 배울 수 있는가 물론, UML 문법 정도는 단 몇 시간만으로도 학습할 수 있다. 하지만, 문법을 익혔다고 언어를 유창하게 구사하는가 문법책을 독파하면 영어를 자유롭게 구사할 수 있는가 UML 역시 언어다. UML을 통해 요구사항이나 제약조건, 혹은 시스템의 구성이나 행위를 자유롭게 묘사할 수 있으려면 상당히 오랜 경험이 요구된다. UML에 대한 충분한 이해가 없는 작업자가 작성된 모델을 통해 원활한 의사소통을 진행할 가능성은 지극히 낮다. 데이터모델 작성을 위한 ERD가 현장에서 널리 쓰이기까지 오랜 시간이 걸렸다. UML도 예외가 될 수는 없다.

한 가지 사례를 살펴보자. 모처에서 해외에 발주를 내리고 설계서를 영문으로 작성해야 했다. 직원들 모두가 영어에 익숙한 것도 아니고, UML을 이용해 설계 사양서(specification)를 작성하기로 결정했다. 여기까지는 상당히 합리적으로 일이 진행된 것이다. 자연어를 사용하면 혼선의 여지가 많은데 언어권과 문화권까지 다른 상황이었다. UML을 사용하면 보다 엄격하면서 간결하게 설계에 관련된 요구사항과 제약조건을 명시할 수 있다. UML을 본래 취지에 맞게 사용하려는 시도였다. 그러나, 명시하려는 수준의 세밀함에 문제가 있었다. 클래스 사이의 관계나 메시지 이름에서 자연어를 모두 배제하려는 시도를 했다. UML의 확장 메커니즘을 활용하면 도메인 고유의 문법을 만들어낼 수 있는데 그와 유사한 시도였다. 게다가 개발사의 고유 영역으로 볼 수 있는 시스템의 내부 동작 메커니즘까지 제약을 두려고 했다. 워낙 시스템의 오류가 대형사고가 될 수 있는 미션 크리티컬(Mission-critical) 시스템이었기에 많은 것들을 담으려는 의도였다.

필자는 고객에게 방법을 설명해주었고, 그에 필요한 노력과 비용을 언급했다. 고객의 반응은 UML과 RUP에 왜 그런 것이 포함되어 있지 않느냐는 것이었다. UML이 그 자체로 특정 산업에 대해 해줄 수 있는 것은 아무것도 없다. 과연 고객이 알고 있던 UML은 어떤 것이었을까

매우 안타까운 사실은 수 년의 시간이 흐른 최근에도 비슷한 고객을 만났다는 점이다. 오랫동안 계속되어온 시스템의 문제와 비효율적인 프로세스를 UML과 CBD 적용으로 한방에 해결할 것으로 기대하고 자문을 요청한 고객이었다. 필자는 현실적으로 가능한 것과 그렇지 못한 것을 분리해 이야기해주었다. 처음에는 뭔가 명쾌해지는 것 같은 표정을 짓던 고객의 얼굴은 이야기가 점점 더 세부적으로 들어가자 못마땅한 표정으로 바뀌었다. 오랜 시간 누적된 문제를 특정 기술의 도입 자체만으로는 결코 해결할 수 없다는 단순한 진리를 스스로 확인한 것이라 생각된다.

아무리 훌륭한 도구라고 해도 사용하는 사람이 해야 할 일을 제대로 했을 때만 빛이 나는 법이다. 잘 모르는 기술을 다룰 때라고 해도 상식에 기초해 판단한다면 말도 안 되는 미신에 현혹되지 않을 수 있다. 이제 UML을 제대로 활용하기 위한 방법을 이야기해보고자 한다. 서적이나 인터넷을 조금만 검색하면 찾을 수 있을 법한 모델링 기법은 생략하겠다. 그보다는 효과적으로 UML을 사용하기 위한 전략을 살펴보자.

[그림1] UML의 다이어그램 구성

UML로 누가, 무엇을 할 것인가

어떠한 이유에서든 UML을 채택했다면 UML이라는 수단을 어떤 목적으로 활용할 것인지를 결정해야 한다. ‘UML의 용도야 뻔한 것 아닌가’와 같은 순진한 생각은 각자의 소중한 시간을 불필요한 일을 하는 데 허비하게 만들 수 있다. 시스템을 개발하는 프로젝트라면 가장 먼저 고객과 개발자 사이에서의 합의된 개발 범위를 설정한다. 이번 프로젝트에서는 어떤 것을 만들어낼지 합의를 보는 과정이다. UML을 적용하는 데 있어서도 이러한 전략적인 결정은 반드시 필요하다. 많은 경우 이러한 결정은 생략되고, 이미 만들어진 특정 방법론에서 요구하는 산출물을 작성하게 된다. 작성한 사람은 열심히 그렸지만, 어느 순간 아무도 보지 않는 모델이 되어 버리는 경우를 흔히 접할 수 있다.

아무도 보지 않는 상황은 어쩌면 미리 예견할 수 있을 법한 일이다. UML을 적용하기로 했을 때 실제 작업자 수준으로 모델을 활용할 사람들의 범위를 결정했는가 그래서 모델을 작성하는 사람이 모델을 보게 될 담당자들을 고려해 작성했는가 모델은 불특정 다수를 위해 만들어내는 예술이나 문학작품이 아니다. 의사소통을 위해 작성하는데 의사소통 대상이 불분명하다니 어찌된 일인가

시스템 개발 과정에서 모델을 작성하는 것이라면 최소한 모델을 작성하는 작업자와 요구사항을 전해주는 사용자, 그리고 개발이 완료된 이후에 모델을 책임질 담당의 요구가 제대로 모델로 표현되었는지 확인할 수 있어야 하고, 완성된 모델은 이를 책임지는 담당자가 충분히 이해하고 관리할 수 있어야 한다. 이를 위해서는 적절한 사전 조율이 필요하고, 잘못된 부분이 있으면 조기에 개선할 수 있어야 한다. 그래야만 공을 들여 만든 모델이 제구실을 하게 된다.

모델을 통해 의사소통 할 주체가 결정되었다면 적용 범위에 대한 결정이 필요하다. 다음 그림은 UML 2.0을 구성하는 13가지의 다이어그램과 계층 관계를 묘사한 것이다(현재 UML의 최신 버전은 2.1.1이다).

13가지 다이어그램을 충분히 활용해야 좋은 모델을 만들 수 있을까 UML 자체에 대한 교육이 목적이 아니라면, 13가지 다이어그램을 모두 활용해야 하는 경우는 없다. 오히려 다이어그램의 종류가 적을수록 이해가 쉬워지기도 한다. 다이어그램은 꼭 필요한 만큼 사용해야 더 효과를 발휘한다. 각각의 다이어그램 용도는 서적이나 전문가의 조언을 구하면 된다. 하지만, UML을 어떤 일에 사용하고 무엇을 표현하는 데 활용할 것인지 결정하지 못했다면 다이어그램의 용도를 알았다고 해서 무슨 쓸모가 있는가

실제로 대형 SI 프로젝트에서는 시스템 개발 범위가 잘 나타나는 유스케이스 다이어그램, 구조적인 관점을 나타내는 클래스 다이어그램(class diagram) 및 패키지 다이어그램(package diagram), 그리고 동적인 묘사를 위한 액티비티 다이어그램(ac tivity diagram)과 시퀀스 다이어그램(sequence diagram) 정도가 주로 활용된다. 그렇지만, 아주 특화된 용도로 사용되는 시스템을 위해 굳이 유스케이스 다이어그램을 작성할 필요가 있는가 시스템을 구성하는 수많은 모듈의 복합적인 상태에 따라 시스템의 구동방식이 달라지는 경우라면 클래스 다이어그램과 시퀀스 다이어그램만으로 모델링이 가능할까 또한 UML로는 묘사하기 힘든 작업이 발생했다면 어떻게 할 것인가

분명한 용도를 알고 있을 때만 효과적으로 UML을 사용할 수 있다. 용도를 결정하는 것은 막연하게 짐작하기도 어렵다. 대개는 모델링을 충분히 활용해본 이후에 적절한 모델링 범위를 판단할 수 있다.

실용적인 모델링과 설계 접근을 다룬 DDD(Domain-Driven Development)에서는 모델에서 불필요한 사항을 제거하는 것을 모델링의 중요한 성공요인으로 언급하고 있다. 특히나 대규모 시스템의 모델링인 경우에는 필수적인 작업이다. 시스템을 구성하는 무수히 많은 컴포넌트와 클래스를 지속적으로 모델링 할 필요가 있을까

한번은 모델이 너무 커져서 모델링 작업을 제대로 수행할 수 없음을 토로하는 고객을 만난 일이 있다. 모델 파일이 너무 커서 작업을 진행하다가 모델링 도구가 죽어버리는 현상이 빈번하게 발생하는 경우였다. 고객은 다른 모델링 도구의 추천을 원했다. 하지만, 문제의 가장 큰 원인은 불필요하게 커진 모델이었다. 급하게 모델링 작업을 하느라 역공학(Reverse Engineering)을 수행한 결과를 그대로 모델에 포함시켜 둔 것이다. 기업용 정보 시스템에서라면 역공학으로 만들어낸 모델은 아주 특수한 경우를 제외하고는 전혀 쓸모가 없다. 그런 쓰레기 정보를 모델에 포함시켜 오랜 기간 작업이 지연되고, 엄청난 교체 비용을 감수하려고 하는 것은 안타까운 일이었다.

그러므로 모델은 최소한으로 필요한 것만 유지해야 한다. 이를 위해서는 어떤 것이 중요하고 그렇지 않은지 분명하게 인지할 필요가 있다. 먼저 중요한 업무를 찾아내 모델링 범위를 명확하게 정립할 필요가 있다. 그리고 어떤 모델을 지속적으로 유지할 것인가를 결정해야 한다. 경우에 따라서는 모델링 과정이 매우 유용하지만, 결과로 만들어낸 다이어그램은 쓸모 없는 경우도 발생한다. 예를 들어 사용자에게는 너무나 분명한 업무이지만, 모델을 작성하는 분석자 입장에서는 전혀 생소한 일인 경우가 그렇다. 작업자가 사용자의 설명을 듣고, 시퀀스 다이어그램이나 액티비티 다이어그램을 작성하는 과정에서 작업의 흐름을 판단하게 될 수 있다. 이런 류의 다이어그램은 작업자의 모델링 과정에서는 매우 유용하지만 시스템 개발이 종료된 이후에는 짐이 될 수도 있다. 작성자가 사라지면 너무나 뻔한 내용이라 다이어그램은 아무도 보지 않는 채로 모델에 남겨져 있을 수 있다. 시스템을 사용하다가 일을 수행하는 방식이 바뀌었다면, 거들떠 보지도 않던 다이어그램을 찾아서 고치겠는가 결국 모델 전체적으로 볼 때는 오해를 낳을 수 있는 허점을 남겨두는 결과를 초래한다.

UML 도구의 합리적인 활용

필자는 호주업체가 만든 EA(Enterprise Architect)라는 도구를 처음 사용했을 때 매우 놀랐다. 조금 불편한 면들이 있었지만, 꽤나 가벼우면서 매력적인 기능을 제공했다. 당시 필자가 사용하던 두 제품은 모두 수 천 만원이었다. EA의 가격은 현재 300달러 정도니까 우리 돈으로 약 30만원 정도다. 처음에 필자는 너무 낮은 가격에 왠지 의심을 갖게 되었지만, 이는 주류 모델링 도구에 비교해도 전혀 모자람이 없었다.

필자 스스로도 모델링 도구에 대해 잘못된 고정관념을 갖고 있었던 것이다. 저가이지만 훌륭한 제품이었고, 7년이 넘는 기간 동안 지속적으로 기능 개선을 해오고 있는 모델링 도구도 있었다. 특정 모델링 도구의 고급 기능이 필요한 것이 아니라면 저가의 모델링 도구 구매를 통해 절감된 예산을 보다 유용한 곳에 사용할 수 있을 것이다.

한편, 모델링 도구의 코드 생성 기능이나 RTE(Round-trip Engineering)에 대한 일방적인 장점만을 좇아 해당 기능을 불필요하게 사용하는 경우도 흔히 볼 수 있다. 특히나 EJB 자동 생성과 같은 기능들은 특정 실행 환경에 종속된 모델을 만들어낸다. 이를 자칫 오용하면 모델링 도구의 기능 제약 때문에 시스템의 성능이나 아키텍처에 대한 중대한 의사결정에 제한을 가하는 웃지 못할 상황을 만들어낼 수도 있다.

경우에 따라서는 소프트웨어 형태의 모델링 도구가 적절하지 않은 경우가 있다. 모니터 화면의 제약으로 여러 사람이 둘러 앉아 긴밀하게 협업하는 것이 어려울 수 있다. 경험 많은 모델러의 경우 모델 작성 과정에서 종이나 화이트보드에 펜으로 그려가며 다른 사람과 협업을 하는 일을 흔하게 볼 수 있다.

[그림2] 펜과 포스트잇을 사용한 개념 모델링

<그림 2>는 필자가 성공적인 개념 모델링을 기념하기 위해 찍어둔 사진이다. 정리되지 않은 사항을 논의하기 위해 여러 명이 전지 앞에 앉아 브레인스토밍을 하고, 포스트잇의 위치를 바꿔가며 논의하는 것은 무척 효과적인 의사소통 수단이었다.

MDA와 DSL(Domain Specific Language

2001년 OMG(Object Management Group)는 MDA(Model Driven Architecture)라는 것을 내놓았다. 이미 1.4 버전에서 모델링 언어로써 충 분한 기능을 갖추고 있던 UML은 MDA의 기반으로 쓰이기 위해 다시 설계 되면서 1.5 버전에서 2.0 버전으로 승격된다. 초기에는 국내에서도 MDA 지원 도구의 도입이 시도되고 잠난 지금도 주류로 채택되진 못했다. 플랫폼 종속적인 부분 과 플랫폼과 무관한 업무 고유의 영역을 분리해 모델을 다룰 수 있는 점은 평가할 만하지만, 플랫폼 종속적인 부분을 특정 벤더의 실행 환경에 맡기는 일은 현실적으로 매우 위험한 발상이다.
MDA와 비교할 만한 것으로 언어지향 프로그래밍(Language oriented programming)이 있다. 언어지향 프로그래밍은 자바나 C#과 같은 범용 프로그래밍 언어로 직접 프로그램을 작성하는 방법을 취하지 않는다. 대신 소위 메타 프로그래밍(Meta programming)이라고 불리는 기법을 사용하 는데, 목표한 시스템 개발을 위한 프로그래밍을 하기 이전에 해당 업무 영 역이나 문제 영역에 알맞은 도메인 고유의 언어 즉, DSL(Domain Specific Language)을 먼저 개발하고 나서 DSL로 최종적으로 프로그램을 작성하 는 방식이다.
MDA와 언어지향 프로그래밍은 매우 다른 접근이지만 문제 영역을 특정 플랫폼이나 프로그래밍 언어와 분리시킨 접근 방식은 동일하다. 업무 영역 의 복잡도와 함께 기술적인 복잡도가 가중되고 변화가 가속화되면서 관심 의 분리(Separation of concerns)가 요구되는 것에 대한 반증이다.
DSL은 특정 도메인을 위한 프로그래밍 용도로 개발되기도 하지만, 종종 특 정 영역의 모델링 언어로 개발되기도 한다. 사실상 DSL을 활용하게 되면 모델링 언어와 프로그래밍 언어 사이의 경계 자체가 모호해진다. 특별히 모 델링을 위해 고안된 DSL을 DSML(Domain Specific Modeling Language)로 구분하기도 한다.

[그림3] Model Driven Architecture

UML을 넘어서

필자가 UML을 접한 지 8년 정도가 지났지만, 처음에 UML을 공부할 때 품었던 기대에 부응하는 모습은 아직까지 확인한 적이 없다. 그렇다고 필자가 회의론자이거나 UML 무용론자는 아니다. 부족함을 느껴야 발전할 수 있는 법이다. 다른 한편으로 이는 필자가 UML에 잘못된 기대를 갖고 있다는 반증이기도 하다.

단지 UML을 익히고 활용하는 것만으로도 굉장한 무언가를 기대했던 것 같다. 그러나 이름에서도 드러나듯 UML은 그저 난립하는 모델링 언어를 통일한 것에 지나지 않는다. 그것을 어떻게 활용해서 가치 있는 결과를 만들어낼지는 전적으로 UML을 활용하는 사람에 달려있다. 분명한 목적과 전략이 없다면 UML은 우리에게 아무 것도 주지 못한다. 혹시 지금도 어딘가에서 ‘단지 UML을 사용해야 한다’는 모호한 목적을 가지고 다이어그램을 만들고 있는 사람이 있다면 이 글이 한 번쯤 생각해볼 수 있는 기회를 제공해주었으면 하는 마음이다.

참고 자료
1. http://en.wikipedia.org/wiki/Unified_Modeling_Language
2. Domain-Driven Design, Eric Evans, Addison Wesley
3. http://sparxsystems.com/
4. http://en.wikipedia.org/wiki/Domain-specific_programming_language
5. http://www.omg.org/mda/
6. http://en.wikipedia.org/wiki/Language-oriented_programming
7. http://www.eclipse.org/gmt/gems/