[지디넷코리아]7년 전 필자는 UML이라는 단어조차 들어본 적 없었다. 국내에서는 그래도 꽤 잘하는 비주얼 베이직 프로그래머라고 자부했는데 당시 봇물같이 쏟아지던 약어들에 질려 UML이라는 알파벳 세 글자로 이루어진 '신규어'에 별 신경을 쓰지 않았다.

몇 년이 지난 후, 필자도 객체지향이라는 무림 강호에 몸을 던지지 않을 수 없는 시점에 이르러서, 그 몇 년 전에 들었던 UML이라는 것이 무림에 출사표를 던지기 위한 필수 무공이었다는 사실을 깨달았다. 그리고 그 이름도 원망스러운 디자인 패턴!

비주얼 베이직이라는 한물간 초식에서는 ‘꽤’ 강자라고 생각했던 필자는 객체지향이라는 드넓은 무림에 발을 들여서는 초고수가 되어야 되겠다는 결심을 했고, 높은 내공을 쌓기 위한 필수 비급이라는 UML과 디자인 패턴을 익히기 시작했다. 그러면서 필자가 느낀 것은? ‘초고수는 아무나 하는 것이 아니구나’하는 것이었다.

필자는 디자인 패턴에 한이 맺힌 사람이다. 디자인 패턴을 며칠 밤씩 새워 가면서 공부할 때 느낀 고통은 이루 말할 수 없다. 가끔씩 감동을 느낄 때도 있었지만 대부분의 경우가 이해하기 힘들고 패턴에 따라 프로그램을 작성하기는 더 힘든 경우가 많았다.

결국은 객체지향에 대한 기초 지식이 부족하기 때문이라는 사부님의 조언을 듣고는 HTDP와 SICP 등의 패러다임 입문서, 리스코프나 메이어 등의 객체지향 이론서 등을 짧은 영어 실력에 열심히 번역하며 읽었다. 객체지향 디자인을 제대로 이해하기 위해서는 UML은 필수사항이었고, UML에 관련된 책도 열심히 사서 읽었다. 그때부터 필자의 머릿속에는 이상한 고정 관념이 생기기 시작했다.

결국은 내공이 좀 쌓이고, 디자인 패턴과 UML을 어렵지 않게 응용해서 프로그램을 짤 수 있는 수준이 되었을 무렵에, 필자는 병적으로 디자인 패턴과 UML에 집착하기 시작했다. 래쇼날 로즈 등의 케이스 툴을 사용해 설계를 하고 있으면, 화면에 보여 지는 여러 예쁜 아이콘들을 보면서 ‘아, 나는 살아 있구나’하는 존재의 가치를 느끼곤 했다.

그렇게 열심히 익힌 기술들을 이용해서 프로그램을 열심히 개발하던 어느 날 밤, 필자는 어떤 의문을 가지게 되었다. 왜 내가 동작하는 코드를 개발하지 않고 그림을 그리고 있을까? 프로그램을 작성하는 목적이 잘 동작하는 프로그램을 작성하는 것이지 출력해서 벽에 걸어놓을 미술 작품을 만들고자 하는 것이 아니지 않은가?

필자는 플라톤의 동굴의 비유에 비견될 만한 엄청난 진리를 깨달았다. UML이든, 디자인 패턴이든 꼭 필요한 부분에만 사용하면 되는 것이고, 프로그램을 작성하기 전 개념을 잡거나 최종적으로 정리하는데 유용한 도구, 특히 UML은 개발자들 간의 상호 커뮤니케이션에 아주 유용한 도구가 될 수 있다는 것을 알게 되었다.

필자는 UML 케이스 툴을 만드는 업체에 근무하는 개발자 몇 명을 잘 알고 있다. 대학원에서 꽤 실력을 쌓아 어렵게 취업한 후배들인데, 업체에 근무한지 3개월쯤 되면 이런 말을 한다.

1년쯤 근무하면 이런 말들을 한다.

3년쯤 근무한 후배는 이런 말을 한다.

악순환의 반복이랄지, 디자인 패턴과 UML이 남긴 폐해랄지, 이런 현상은 매년 계속된다.

아키텍트 입장에서 UML
필자가 조선 업계에서 근무할 때, 새로운 시리즈를 시작할 경우(배는 하나의 설계로 여러 척을 찍어낸다) 먼저 모형을 만들어서 테스트를 하는 것을 본 적이 있다. 모형을 만들어 수영장 같은 곳에서 테스트를 해 보고 실제로 배가 목표한 만큼의 성능을 낼 수 있는지 테스트 한다. 또한, 배를 설계할 때 거대한 캐드 시스템으로 설계한 후 파도와 바람 등에 견딜 수 있는지를 테스트한다.

배를 만들 때는 엄청난 비용과 시간이 소모되기 때문에 모형을 만들거나 컴퓨터상에서 수치로 테스트한다. 컴퓨터로 만들건, 정말 모형을 만들건, 그렇게 만들어진 것을 모델이라고 하고, 대부분의 경우 모형을 만드는 비용이 실제 배를 만드는 것보다 비용이 훨씬 적게 소모되므로 모델 테스트를 한다. 이런 모델을 만들어 테스트 해보는 과정을 ‘모델링’이라고 부른다.

배를 지을 때도 선실의 세부 구조나 엔진의 동작들은 모델링하지 않는다. 모델링이라는 것은 어떤 것이 실제로 잘 동작하는지를 알아보려고 만드는 것이다. 실제 크기대로 배를 지어 바다에서 항해해 가며 파도와 바람의 영향을 최소화하거나 풍랑에 버틸 수 있을지를 테스트 해 본다는 것은 비용이 너무 많이 드는 일이다. 모델을 만드는 이유는 모델을 만드는 비용이 실제 물건을 만드는 것보다 훨씬 적은 비용으로 설계가 제대로 되었는지 알고 싶어서이다.

소프트웨어를 만들 때도 이와 같은 이치가 적용된다. 하지만 소프트웨어를 설계할 때 사용하는 이 UML이라는 것은 조선 엔지니어나 토목 엔지니어들이 모델링을 하기 위해 사용하는 미니어처나 캐드 모델과 비교해 볼 때 훨씬 비효율적이고 테스트하기 곤란하다. UML 다이어그램에는 다른 공학 모델과 비교해 보았을 때 확고한 시험 기준을 세우기도 곤란하고 평가를 내릴 때도 주관적인 관점이 상당부분 차지할 수 밖에 없다.

조선이나 건축에서 모델을 만드는 것은 실제 배나 건물을 짓는 것과 비교할 때 비교도 할 수 없을 만큼의 적은 비용이 들지만, 소프트웨어를 설계하는 입장에서 실제 프로그램을 작성하는 것과 UML을 사용한 설계를 비교했을 때 비용적인 측면에서나 생산성적인 측면에서나 그렇게 차이 나지 않는다.

사실, UML을 사용해서 테스트하는 것보다 소스코드를 직접 수정하는 것이 비용이 훨씬 적게 들고 손쉬운 경우도 있다. 개발자의 입장에서는 더욱 그러하다. 하지만 UML을 사용해야 하는 이유는 무엇일까? 잘 사용하면 비용 절감의 효과를 가져 올 수 있고, 포괄적인 설계가 가능하다는 것이다.

UML 다이어그램이라는 것은 앞서 이야기 했듯이 다른 공학에 비해 모델을 사용했을 때 실제 건축물(소프트웨어에서는 실제 동작하는 코드)을 작성하는 것보다 비용이 명확하게 절약되는지가 명확하지 않다. 필자는 실제 프로그램을 작성하는 것보다 UML 다이어그램을 작성하는 것이 훨씬 시간이 많이 드는 경우를 허다하게 봤다(사실 그렇게 하지 않으면 제대로 된 프로그램이 나오지 않는 경우가 대부분이다).

UML 다이어그램은 세부적인 설계를 하기 보다는 포괄적인 설계를 구성하였을 때 그 전체적인 비용의 절감 효과를 가져 올 수 있다. 세부적인 그림을 UML 다이어그램으로 표시하기 보다는 전체적인 그림을 UML 다이어그램으로 표시하고 세부적인 표현은 코드로 작성하는 등의 탄력성 있는 설계 운영이 전체를 UML로 설계하는 것보다 훨씬 나은 효율을 가져올 수 있다는 것이다.

실제로 아키텍트들의 설계는 이러해야 한다. 아키텍트들은 UML 다이어그램을 세부적으로 표현하기 보다는 전체적인 그림을 그리고, 그린 그림이 실제 소프트웨어로 동작했을 때 바르게 동작할 수 있을 것인지를 개발자들과 토론하고 설계를 수정한다.

필자는 프로젝트를 시작할 때 전체 소프트웨어의 요구사항을 격자 형태로 나누고 각 부분을 개개의 개발자들에게 할당하는 경우를 본 적이 있다. 큰 부분으로 나뉜(이 큰 부분으로 나누는 것조차 PM급의 아키텍트가 하지 않는다. 그러한 큰 부분은 대 부분의 기업형 응용 프로그램이라면 부서별 또는 업무별로 자연스럽게 할당되어 있기 마련이다) 업무 분할대로 각 개발자가 ER-Diagram부터 클래스 다이어그램, 컴포넌트 다이어그램까지 작성하는 경우를 실제로 본 적이 있다.

큰 수정 없이 프로젝트가 진행되어 다행이었지만, 한 부분이라도 어긋난 부분이 있었다면 엄청난 비용이 소모되었을 것이다(사실 그렇게 작성된 프로그램은 전체적인 소프트웨어의 부품이 유기적으로 동작하는 소프트웨어가 아니고 각 부품이 각기 따로 동작하는 작은 프로그램들의 집합일 수밖에 없고, 실제로도 그러했다).

개발자 입장에서 UML
자, 이제 개발자 입장에서 UML을 생각해 보자. 실제로 개발자가 UML 다이어그램의 모든 부분을 다 알아야 하는가? 개발자가 프로그램을 작성하기 위해서 UML의 메타 모델을 모조리 이해하고 각 프로젝트와 다른 케이스 도구들에서 쓰이는 스테레오 타입들을 다 알아야 한다는 것이다.

필자는 여기에 반대한다. 필자는 주로 닷넷 기술들을 가지고 소프트웨어를 작성하고 강의하고 컨설팅을 수행하는데, 사실 닷넷 기술은 너무 빠른 속도로 변화하고 있다. 곧 출시될 비주얼 스튜디오 2005와 MS-SQL 서버 2005는 닷넷 프레임워크 2.0을 기반으로 하는데, 닷넷 프레임워크 2.0은 1.1 버전과는 상당히 다른 모습을 보여준다.

C#이나 비주얼 베이직 닷넷 같은 언어적인 측면에서만 봐도, 겉으로 보기에도 제네릭(Generic)이 포함되는 등 상당히 많은 부분이 변하였다(필자는 이 부분에서 상당히 불만이 많다. MS는 이런 부분을 발표만 하고는 다른 이야기가 없다.

여러 잡지에 소개되는 글들을 봐도 이런 기능들이 추가되었다. 이런 내용만 있지 실제적으로 테스트 해 볼 수 있는 코드를 제시하거나 근본적인 변화를 이야기하는 경우는 드물다). ASP.NET 2.0만 해도 ASP.NET 프레임워크가 전체적으로 변화한 부분도 몇 군데 있을 뿐더러 사용자 정의 컨트롤이 상당히 많이 추가되고 변화함으로 인해서 새로 익혀야 할 부분이 늘어났다.

ADO.NET도 마찬가지다. 개발자의 부담은 가중되고 실제적으로 필드에서 사용되어야 할 코드와 컨트롤들의 사용법을 익히는 것과 UML의 전체적인 내용을 학습하는 것 사이에서 갈등하게 된다.

디자인 패턴도 이럴 때 부담이 된다. 개발자 누구나가 디자인 패턴과 UML을 사용할 수 있어야 하고 열심히 학습해야 한다는 것은 알고 있지만, 현실적으로 당장 사용하여야 할 요소 기술과 끝이 보이지 않는 기반 기술을 사이에 두고 갈등하다 보면 당연히 당장 사용하게 되는 요소 기술 쪽으로 치우칠 수밖에 없다.

이럴 때 누군가에게 "UML을 조금 알아야 되겠는데 어떤 책을 봐야 되겠습니까?"라고 물어보면 그 누군가는 책을 산더미처럼 던져주고(보통 이런 경우에 이유 없이 원서를 권하는 경우가 많다. 안 그래도 바빠 죽겠는데 원서가 포함된 책 뭉텅이를 받은 개발자의 입에서는 욕 빼고는 나올 것이 없다) 이 책의 내용들을 거의 다 숙지해야 제대로 쓸 수 있다는 교과서의 화신 같은 이야기를 하게 된다. 사실, 이 말은 격무에 시달리는 개발자들에게 UML을 공부하지 말라는 이야기와 동일하게 밖에는 안 들린다.

개발자들은 프로젝트에 투입될 때 UML의 어떤 부분을 알아야 하는가? 사실 UP의 모든 부분을 다 안다는 것은 업무 형태와 업무량으로 볼 때 거의 불가능 하다고 볼 수 있다. 그렇다고 UML을 전혀 모르는 상태에서 개발에 투입되었다면 그 개발자의 앞길은 십자가를 지고 골고다 언덕을 오르는 예수님의 모습처럼 보일 것이 뻔하다. UML을 효과적으로 사용하기 위한 효과적인 길을 알아보자.

의사소통 수단으로서 UML
초보 개발자라면, 우선 UML의 표기법에 익숙해져야 한다. 이렇게 생긴 아이콘은 클래스고, 이렇게 생긴 화살표는 실제화고(물론 실제화를 이해하기 위해서는 객체지향을 이해하여야 한다는 원론적인 이야기를 피하기는 힘들다. 산 너머 산이다) 이렇게 생긴 화살표는 집단화이고 등의 표기법(Notation)을 익히는 것이 중요하다. 개발은 혼자 하는 것이 아니기 때문이다. UML은 개발자들끼리 설계 개념에 대한 의견을 주고받을 때 굉장히 편리한 도구로 사용될 수 있다. UML의 표기는 매우 명확한 의미를 전달해 줄 수 있다.

개발 경로로서의 UML
UML은 기업 형 소프트웨어를 작성할 때 구조의 개발 경로를 작성할 때 유용하다. PM이 이렇게 개발해라 하는 지시를 내리면 사실 그 지시라는 것은 추상화 된 개념이라서 바로 프로그램으로 옮기기가 곤란한 경우가 대부분이다. 이런 경우, 어떤 객체를 먼저 작성하여야 하고 어떤 객체는 어떤 객체에 의존하고 하는 식의 로드맵이 필요한데, UML은 이런 도구로서도 훌륭하다.

개발 경로로서 UML 다이어그램을 활용하려 한다면, 클래스 다이어그램, 객체 다이어그램, 시퀀스 다이어그램, 협력 다이어그램을 읽을 수 있고 작도할 수 있어야 한다. UML 표기법을 완벽하게 익힐 필요까지는 없을 테고, 적당히 다른 사람과 상호 통신할 수 있을 정도의 수준이면 충분하다.

스테레오 타입 등은 잘 알아야 하지 않느냐고? 처음엔 잘 몰라도 된다. "<<", ">>"가 붙은 기호는 스테레오 타입이라고만 아는 것으로 충분하다. UML이라는 것은 쓰다보면 이해가게 되어있는 아주 신기한 물건이다.

언제 다이어그램을 그려야 하는가?
UML은 도구일 뿐 그 자체가 목적이 되어서는 안된다. UML이 목적이 되는 경우도 물론 있긴 하다(대부분의 경우 UML이 목적이 되는 경우는 작성된 소프트웨어가 클라이언트 또는 감리에 의해 검수 받을 때뿐이다). UML을 남용하는 것은 소프트웨어 개발에 큰 걸림돌이 될 수 있다. 하지만 남용하지 말고 아껴서 사용한다면 큰 도움을 줄 수 있다. 예전의 ‘약 좋다고 남용 말고..."라는 표어는 UML에서 그대로 통한다.

다이어그램을 그려야 하는 경우 어떤 지침을 따르는 것이 좋을까? 모든 개발자들이 설계에서 특정한 부분의 구조를 이해해야 할 경우 다이어그램을 그리는 것이 좋다. 그림이 완벽할 필요는 없다. 모든 개발자들이 이해했다고 생각되면 그만 그리면 된다.

개발자들 간에 구조에 대한 분쟁이 일어날 경우 그림을 그리고 그림을 판독할 수 있는 중재자를 구할 때. UML 다이어그램은 아주 명확한 의미를 전달 할 수 있기 때문에 같은 생각이지만 다른 말을 통일시켜주는 역할을 할 수 있다. 새로운 아이디어를 떠올리고 그 아이디어를 주위 개발자 또는 상급자에게 칭찬받고 싶을 때 UML 다이어그램을 작성한다. 말로 떠드는 것보다 한번 보여주는 것이 200%의 효과를 발휘한다.

“백문이 불여일견”일 필요가 있을 때 UML 다이어그램을 작성한다. 그리고 마지막으로 클라이언트에게 ‘있어 보이는’ 문서를 보여줘야 할 필요가 있을 때 작성한다. 부차적인 설명이 없이도 다들 이해하리라 믿는다.@

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.