Eternity's Chit-Chat

aeternum.egloos.com



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

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을 프로그래밍 언어와 같은 수준으로 사용할 수 없는 이유를 이해하기 위해서는 소프트웨어 설계의 본질이 무엇인지에 관해 고민해 보아야 한다.


핑백

  • 소프트웨어 개발자는 늘어나는데 생산성이 높아지지 않는 이유는? | Popit 2016-10-13 00:14:19 #

    ... 할 경우의 문제점에 대하여 설계 작업과 개발 작업을 분리할 경우 발생할 수 있는 한계점을 다루고 있는 다음 글을 읽어보면 많은 부분에서 공감할 수 있을 것이다. 설계의 본질, 그리고 UML – 1부 설계의 본질, 그리고 UML – 2부 설계의 본질, 그리고 UML – 3부 소프트웨어 개발에 있어 세분화, 분업화로 인하여 얻을 수 ... more

덧글

  • 몽몽이 2009/07/04 14:16 #

    동의할 수 없는뎁셔... 설계를 마치 pseudo code 생산처럼 생각하는 것 같네요.
    분석-설계는 다 검증입니다. 각 단계에서 break down하고 검증할 것은 충분히 할 수 있습니다.
    다이어그램을 검증과 의사 소통의 도구로 사용하지 않는 것은 UML 탓이 아니라 사람 탓입니다.
    UML 기반으로 성공한 프로젝트도 얼마든지 많이 있고 참여도 많이 했습니다.
  • 이터너티 2009/07/04 15:54 #

    제 글의 요지를 잘못 이해하신것 같습니다.
    글에서 설명한 것 처럼 UML을 사용하면 불완전한 커뮤니케이션을 효과적으로 보완할 수 있고 말씀하신 것처럼 구현에 들어가기 전에 정합성이나 방향성을 검증할 수 있습니다.
    중간에 적은 것처럼 저 역시 "문제는 UML 그 자체에 있는 것이 아니라 UML을 사용하는 우리의 접근 방식에 있다"라고 생각합니다.
    제가 문제라고 생각하는 부분은 UML과 같은 다이어그램 자체를 설계라고 생각하고 코딩 과정에서 오는 피드백을 무시하려는 사람들의 태도입니다.
    또한 설계자와 구현자를 분리하는 것이 더 높은 생산성을 낸다는 제조 메타포 관점에 대한 비판입니다.
    단계별 인력 분리와 피드백을 최소화하려는 waterfall 모델의 단점을 떠올리시면 이해가 빠르리라 생각됩니다.
    이 글의 요지가 UML의 무용론을 주장하는 것이 아니고 UML을 가치있고 효과적으로 사용하기 위한 방안을 탐구하고자 하는 것이라는 점을 놓치신 것 같습니다.
  • 왕언니 2009/07/06 01:03 # 삭제

    좋은글 감사합니다. 글의 요지가 UML에 있는 것이 아니라 설계자와 개발자가 일방적으로 UML로 의사소통한다면 불완전한 인간인지라 서로간 받아들이지 못하는 한계가 있다.
    그러므로 UML을 중심으로 분리하여 접근하는 방식이 프로젝트를 꼭 돕는다고는 볼 수 없다.
    대충 이렇게 생각하면 되나요.
  • 이터너티 2009/07/06 13:53 #

    예, 비슷하다고 보시면 됩니다.
    UML로 그려진 다이어그램은 설계가 아니며, UML은 의사소통을 촉진시키기 위한 도구 정도로 사용할 때 가장 효과적이라는 것입니다.
    MDA나 Executable UML을 효과적으로 적용할 수 있는 분야가 있겠지만 변경이 잦고 요구사항이 유동적인 대부분의 일반적인 프로젝트에서는 이런 식의 정형화된 접근 방법이 프로젝트의 흐름을 방해한다고 생각합니다.
    그리고 "UML을 중심으로 분리하여 접근하는 방식이 프로젝트를 꼭 돕는다고 볼 수 없다"라기 보다는 일반적인 프로젝트의 경우 "UML을 중심으로 분리하여 접근하는 방식은 프로젝트에 득보다는 실이 많다"라는 의미로 보시는게 좋을 것 같습니다.
    이어지는 글에서 좀 더 이해하기 쉽게 풀어 쓰도록 하겠습니다.
    방문해 주셔서 감사합니다. ^^
  • Kevin 2009/07/21 22:51 # 삭제

    대학시절 소프트웨어개발 프로세스를 순서대로
    제대로 밟는 프로젝트가 필수과목이었습니다.
    10명을 한팀으로 해서 진행했는데,
    작성한 문서만 천 페이지 이상이 나오더군요.

    전공이 IT 임에도 불구하고,
    저희팀에는 software engineering 쪽에 관심이 있거나
    잘하는 애들이 하나도 없어서
    기술적인건 전부다 떠 맡았던 적이 있습니다.
    물론 저는 좋아하는거라서 일부러 그런거지만요.

    System Design, DB Design, Programming 에
    기술적이지 않은것까지...
    가령 SRS작성이라던가, UI 검토하는거라던가 기타 등등...

    아무튼 원래 좋아하는 쪽이라 기쁜맘으로 참여를 하고,
    system design하면서 UML 다이어그램을 100장도 넘게
    그렸었는데, 나름대로 신경을 많이써서 그중에
    한 30장 정도 최종적으로 선별해서 그걸 기초로
    Design 관련 문서를 작성하고,

    나중에 그걸 토대로 Programming 해야 하는 상황에서 보니...
    UML이 확실히 도움이 되고
    전체적으로 이해 하는데 많이 편하긴 했는데,
    구현을 하려니 뭔가 안 맞는게 있다거나
    구현중에 잘못된게 발견된다거나 해서
    UML을 수정해야 하는 일이 발생하더군요.

    안하면 서로 따로 노니 이건 뭐 그야 말로 종이쪼가리가 될판이고...
    다행히 디자인이고 프로그래밍이고 혼자서 해서,
    UML 수정하는데 아무 문제도 없었지만,
    그때 든 생각이,
    '이거 만약에 아키텍트가 그려주고 그대로 하라고 하고선
    구현에서 문제 발생해서 보고 했는데,
    그냥 그대로 하라고 우기거나
    신경 쓰지말고 알아서 구현하라고 하고 UML 수정 안 하면
    골치 아프거나 문서랑 실제 소프트웨어랑 차이가 나는 상황이
    발생하겠구나.' 라는 생각을 했었습니다.
    그당시 맡은게 많아서 힘들긴 했지만,
    (그 학기 끝나고 한달을 앓아 누워있었습니다. ㅠ_ㅠ
    덕분에 방학은 물건너...)
    학생으로서 쉽게 얻기 힘든 좋은 경험을 했다는 생각이 듭니다.

    운이 좋게 첫직업으로 참여한 개발 프로젝트에서도
    제가 설계와 구현을 제맘대로 할수 있어서
    그런 문제가 없었는데, 역시 진행하면서 같은 점을 느꼈구요.

    도구로 써야할 UML을 설계도로 착각해서
    집착하는게 어떤건지 정말 공감이 많이 됩니다.

    설계한 분이 직접 구현을 해본 경험이 있다면 그렇지 않을거란
    생각이 듭니다만, 가끔 보면 아키텍트라는 분이
    실제 프로그래밍 경험이 거의 전무하다시피한 분도 계시던데,
    구현 경험도 없이 어떻게 설계를 한다는건지...
    말씀하신데로 소프트웨어 개발은 제조나 건축과는 차이가 나는데 말이죠.

    아무튼 좋은글 써주셔서 고맙습니다. :)
  • 코즈 2009/12/07 10:49 #

    좋은 글 감사합니다~
    (_ _)
  • 귀뫄뉘 2010/11/03 11:42 # 삭제

    기술적으론 훌륭한 기술이 참 많은데, 실무에선 기술적 문제가 아닌 다른 문제로 인해 적용이 어려운 경우가 많더군요. 좋은 글 잘 봤습니다.
  • 이터너티 2010/11/04 15:07 #

    감사합니다. 저희 일이 사람과 컴퓨터와의 일이라기 보다는 사람과 사람 간의 일이라는 생각이 강하게 들더군요. 기술적인 문제보다는 사람과의 문제를 먼저 해결할 수 있는 방법을 찾는게 가장 좋다고 생각합니다.
※ 로그인 사용자만 덧글을 남길 수 있습니다.