본문 바로가기

이글루스

Eternity's Chit-Chat

검색페이지 이동

사이드 메뉴

이글루스 블로그 정보

설계의 본질, 그리고 UML - 1부

앱으로 보기

본문 폰트 사이즈 조절

이글루스 블로그 컨텐츠

UMLUnified Modeling Language은 소프트웨어의 정적인 구조와 동적인 행위, 그리고 그와 관련된 다양한 관점을 표현하기 위한 그래픽적인 표기법이다. 인간이 지닌 시각적, 공간적인 해석 능력은 다이어그램에 녹아 있는 다양한 정보를 빠르게, 그리고 효과적으로 이해할 수 있도록 하기 때문에 UML을 적절하게 사용하면 태생적으로 존재할 수 밖에 없는 프로젝트 관련자들 간의 불완전한 커뮤니케이션을 보완할 수 있다.

 

UML을 사용하면서 발생하는 전형적인 문제는 UML을 통해서 전체 설계를 전달해야 한다는 압박에 시달릴 때 나타난다. 이런 유형의 프로젝트에서는 UML을 사용해서 소프트웨어 구조를 표현해야 하고 모든 정보는 코드가 아니라 설계 문서에 나타나야 한다. 최악의 케이스는 UML로 모든 부분에 대한 선행 설계up-front design를 작성하고 이로부터 코드를 생성하는 경우다. 이와 같은 접근방법을 시도했던 몇몇 프로젝트에 몸 담았던 적이 있었지만 결과는 참담했다. (그 프로젝트에서 모델 관리 및 코드 생성을 가이드하는 역할을 맡았던 경험 때문에 이와 같은 접근방법에 대해 더욱 더 부정적인 시각을 가지게 되었는지도 모르겠다.)

 

UML은 프로그래밍 언어로 사용하기에는 너무나 무겁고 커뮤니케이션의 용도로 사용하기에는 너무나 가볍다. 프로젝트의 목적은 사용자의 요구사항을 만족시키는 실행 가능한 소프트웨어를 만드는 것이다. 코드가 아니라 다이어그램과 관련된 산출물 작성이 프로젝트의 진행에 있어 병목지점으로 밝혀진다면 UML 중독에 시달리고 있는지 살펴 보아야 한다. 이런 경우 다이어그램과 코드 간의 불일치를 해소하는데 귀중한 프로젝트 자원을 소모하고 있는 경우가 많다. 문서화를 위해 라운드 트립 CASE 도구를 사용하는 것은 고통을 감소시키기 보다는 오히려 증가시키는 경향이 있다.

 

프로젝트 중간에 작성된 다이어그램을 아무도 들춰보지 않는다면 이미 커뮤니케이션 촉진제로서의 기능을 상실했다는 증거다. 최종 코드는 설계 문서와 무관하게 작성되고 대부분의 커뮤니케이션은 코드와 화면을 통해서 이루어진다. 지속적으로 코드와 문서 간의 동기화를 맞추려던 시도는 실패로 끝이 나고 프로젝트가 종료되는 시점에 최종 코드의 모습을 반영해서 문서를 만드는 빅뱅 방식으로 종지부를 찍게 된다.

 

문제는 UML 그 자체에 있는 것이 아니라 UML을 사용하는 우리의 접근 방식에 있다. UML은 프로그래밍 언어가 아니다. 따라서 코드를 위한 템플릿으로 UML을 사용해서는 안 된다. UML은 분명 유용한 커뮤니케이션 도구로 활용될 수 있지만 UML만으로 충분한 커뮤니케이션이 가능할 것이라고 기대해서는 안 된다. 커뮤니케이션의 본질은 프로젝트 참여자 간의 대화와 공유 경험이며 UML은 이를 자극시켜 커뮤니케이션의 효과를 촉진시킬 수 있을 뿐이다.

 

그렇다면 UML을 올바르게 사용하기 위해서는 어떻게 해야 할까? 이에 대한 해답을 찾기 위해서는 과거에서 현재까지 프로젝트 개발 과정에서 끝없이 나타나고 있는 몇 가지 거북한 진실과 대면해야 한다. 우선 얼핏 UML과 무관해 보이는 프로젝트 역할 분담에서부터 이야기를 시작해 보자.

 

오류의 역사

소프트웨어 개발은 다른 성숙한 분야에 비해 상대적으로 그 역사가 짧기 때문에 다양한 분야로부터 메타포를 받아 들였다. 가장 대표적인 것이 제조manufacturing와 건축architecture이며 두 분야는 소프트웨어 개발에 필요한 어휘와 개념을 제공하기도 했지만 개발 프로세스와 사람이라는 관점에서 부정적인 영향을 끼치기도 했다.

 

제조manufacturing는 소프트웨어 개발에 대한 메타포로 자주 사용되곤 한다. 이 메타포로부터 얻게 되는 한 가지 결론은 고도로 숙련된 엔지니어는 설계를, 덜 숙련된 노동자는 제품을 조립한다는 것이다. 이 은유는 소프트웨어 개발은 모든 것이 설계라는 한 가지 단순한 이유로 많은 프로젝트를 엉망으로 만들어 왔다.
-       Eric Evans, Domain-Driven Design

 

제조 메타포에서 숙련된 엔지니어는 UML과 같은 표기법을 사용해서 구현에 필요한 설계 도면을 작성하고 덜 숙련된 노동자는 기계적으로 다이어그램에 명시된 요소를 프로그램 명령문으로 변환한다. 프로그래밍이란 설계 문서를 프로그램으로 변환시키는 것이므로 이 과정에서 오류를 줄이기 위해 자동으로 코드를 생성해주는 기법을 적용시키는 것이 효과적이다. 과연 그럴까?

 

제조 메타포를 기반으로 한 역할 분리는 근본적으로 두 가지 오류를 범하고 있다. 첫 번째 오류는 설계자와 구현자 간의 차이를 고려하지 않고 기계적으로 설계를 구현으로 변환할 수 있다는 믿음을 전제로 한다는 점이다. 유사한 경험과 경력을 가진 사람들 간에도 커뮤니케이션이 불완전해지는 경우를 자주 보게 된다. 하물며 서로 다른 역할과 경험을 기반으로 하는 두 계층 간에 다이어그램과 문서 중심의 커뮤니케이션이 가능하다는 근거 없는 믿음은 어디에서 기인한 것일까?

 

바로 여기에 문제가 있다. 만약 설계자가 코더보다 높은 수준의 기본단위를 사용한다면, 결과로 나오는 설계는 코더가 작업을 시작하는데 부적절할 것이다. 따라서 코더는 코딩을 하기 전에 적절한 수준의 설계를 추가하기 위해 시간을 소모해야 할 것이다. 이런 경우 코더는 설계자가 기대한 완전한 설계 솔루션과는 다르게 작업할 수 있으므로, 설계에서 코딩으로의 전환은 최상의 경우라도 불편할 테고, 보통은 많은 문제를 야기할 것이다.

반대의 경우도 동일한 문제가 발생한다. 만약 설계자의 경험이 부족하다면 설계자는 매우 상세한 수준의 설계를 만들 것이다. 그러나 이 설계자보다 경험이 많은 코더는 지나치게 상세한 수준의 설계를 받아들이지 않고 자신의 설계 아이디어로 대체할 것이다. 이는 설계자가 코더보다 똑똑하거나 숙련된 사람이어야 하는가에 대한 문제가 아니라, 그들이 같은 경험과 기본 단위를 가지고 있는가에 대한 문제이다.

-       Robert L. Glass, 소프트웨어 공학의 사실과 오해

 

작업이 더 작은 단계로 세분화될수록, 한 사람에서 또 다른 사람으로 정보를 전달하는 데에 더 많은 시간이 걸린다. 생산라인 접근 방식은 수작업 노동에는 잘 맞을 수 있다. 그러나 지적인 작업에는 형편없이 실패한다.

소프트웨어 개발은 팀원들의 머리에서 일어난다. 사람들을 특정 활동에 전문화시킴으로써 간단한 프로젝트의 딜리버리도 여러 경로를 통해야 한다. 각 경로는 실수와 결함에의 잠재성을 갖고 있는 값비싼 과정이다.

- Pete McBreen, 소프트웨어 장인 정신

 

제조 메타포의 두 번째 오류는 구현 전에 설계를 완성시키는 것이 가능하다고 가정한다는 점이다. 그러나 실제로는 개략적인 설계를 구현으로 옮기는 도중에 전체 구조에 대한 가장 중요한 통찰을 얻게 된다. 구현 전에 대략적인 설계를 동결시키는 방식은 구현으로부터 얻게 되는 피드백을 원천적으로 차단하는 역효과를 가져온다. 특히 CASE 툴을 사용해서 설계 문서를 다이어그램으로 표현하고 이를 별도의 산출물로 유지할 경우 문제가 더욱 커지게 되는데, 구현 변경이 곧 설계 문서의 변경을 의미하므로 이를 기피하게 되기 때문이다. 따라서 UML과 같은 표기법을 사용해서 설계를 동결시키고 이를 구현자에게 전달해서 프로그램을 구현하도록 하거나 코드를 생성하는 아이디어는 소프트웨어 개발에는 적합하지 않다.
 

두 번째 오류, 즉 미리 설계를 고정시키는 것이 불가능하고, 따라서 UML을 프로그래밍 언어와 같은 수준으로 사용할 수 없는 이유를 이해하기 위해서는 소프트웨어 설계의 본질이 무엇인지에 관해 고민해 보아야 한다.


포스트 공유하기

썸네일
이터너티님의 글 구독하기
덧글 8 관련글(트랙백) 2
신고
맨 위로
앱으로 보기 배너 닫기

공유하기

주소복사

아래의 URL을 길게 누르면 복사할수있습니다.

http://aeternum.egloos.com/m/1545662
닫기

팝업

모바일기기에서만 이용이 가능합니다.
운영체제가 안드로이드, ios인
모바일 기기에서 이용해주세요.

덧글 삭제

정말 삭제하시겠습니까?

비밀번호 확인

게시글 신고하기

밸리 운영정책에 맞지 않는 글은 고객센터로
보내주세요.

신고사유


신고사유와 맞지 않을 경우 처리되지 않을 수 있습니다.
저작권 위반/명예훼손 등은 고객센터를 통해 권리침해
신고해주세요.
고객센터 바로가기