Eternity's Chit-Chat

aeternum.egloos.com



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

커뮤니케이션의 불완전성과 이론 구축으로서의 프로그래밍

커뮤니케이션은 불완전하다. 의미 전달을 위해 음성 신호를 사용하는지 문자 체계를 사용하는 지 여부와 상관없이 완벽한 커뮤니케이션이라는 목적을 달성하는 것은 불가능하다. 일반적인 생각과 달리 커뮤니케이션의 본질은 정확한 의미 전달에 있지 않다. 오히려 커뮤니케이션의 본질은 참여자 간의 공유 경험을 자극하는데 있다.

 

이해를 돕기 위해 어떤 특정한 설계 문제를 토의하기 위해 회의실에 모인 개발자들간의 대화를 살펴 보자. 만약 회의 참석자 대부분이 설계 경험이 적은 초보자로 구성되어 있거나 함께 협력했던 경험이 전무하다면 설계 중에 오가는 대화의 양상은 다음과 같을 것이다.

 

실행 시 요금 정책이 변경되어야 하기 때문에 메소드 내부에 조건문을 추가해서 적절한 계산 로직을 선택할 수 있도록 해야 합니다. 하지만 요금 정책은 쉽게 변경되고 종류도 다양하기 때문에 조건문으로 해결하는 것 보다는 인터페이스를 하나 추출하고 인터페이스를 구현하는 구체적인 클래스를 여러 개 만들어 이 클래스에 위임하도록 하는 편이 좋을 것 같네요.”

 

만약 회의 참여자들이 디자인 패턴에 대해 알고 있다면 어떨까?

 

요금 정책에 STRATEGY 패턴을 사용하도록 하죠.”

 

디자인 패턴에 대한 전문 지식은 없지만 바로 전 프로젝트에서 함께 프로젝트를 수행했던 경험이 있다면?

 

요금 정책 부분도 단말기 수수료 정책과 동일한 방식으로 구현하도록 하죠.”

 

커뮤니케이션의 정확성과 효율성은 전달 매체나 내용의 길이, 그 형식과는 무관하다. 커뮤니케이션의 성패는 참여자 간의 공유 경험을 얼마나 효과적으로 자극할 수 있느냐에 달려 있다. 커뮤니케이션의 정확도와 효율성이 화자와 청자 간의 공유 경험에 의존한다는 사실을 염두에 둔다면 커뮤니케이션이 완벽할 수도, 완전할 수도 없다는 사실을 이해할 수 있다. 어떤 누구도 동일한 경험을 공유할 수는 없으며 특정한 경험을 공유한다고 해도 그 경험을 자극시키기 위해 전달해야 하는 내용은 청자의 상황이나 인지 능력에 의존적이기 때문이다.

 

대부분의 프로젝트에서 설계 문서를 작성하는 이유는 소프트웨어의 구조와 설계 의도를 커뮤니케이션하기 위해서이다. 그렇다면 효과적인 커뮤니케이션의 수준을 어떻게 정해야 할까? 커뮤니케이션의 수준은 설계 문서를 작성하는 사람과 설계 문서를 보게 되는 사람 간의 공유 경험을 기반으로 해야 한다. 그리고 커뮤니케이션의 본질이 그런 것처럼 설계 문서만으로는 완벽한 의미 전달이 불가능하다는 사실을 인지해야 한다.

 

컴퓨터 산업에서 의미하는 바를 실제적으로 설명할 수는 있지만, 설계 명세서와 설계 문서를 작성할 때는 그렇지 못하다는 것은 명백한 아이러니가 아닐 수 없다. 게다가 우리는 요구사항이나 설계를 완벽하게 열거하기를 바란 적이 결코 없다. 독자가 어느 정도 경험이 있다고 가정해 볼 때 더 많은 경험이 있다고 가정하면 우리는 좀 더 적게 작성할 것이고, 경험이 좀 부족하다고 가정하면 더 많이 작성해야 할 것이다.

-       Alistair Cockburn, Agile 소프트웨어 개발

 

대화나 설계 문서를 통해서 완벽한 커뮤니케이션이 불가능하다면 최종적으로 선택할 수 있는 매체는 프로그램 코드뿐이다. 설계 문서는 시간의 흐름에 뒤쳐질 가능성이 크고, 담을 수 있는 내용이나 상세 정도에 제약이 따르지만 코드는 그렇지 않다. 코드는 소프트웨어의 현실이다. 그러나 불행하게도 코드만으로 소프트웨어에 대한 모든 측면을 커뮤니케이션 할 수 있다는 주장 역시 받아들이기는 어렵다. 이를 이해하기 위해서는 설계의 또 다른 측면을 살펴볼 필요가 있다.

 

소프트웨어 개발 활동의 궁극적인 목적은 실행 코드의 작성이다. 그리고 개발 활동의 최종 결과물은 실행되는 소프트웨어의 모든 것을 담고 있는 프로그램 텍스트다. 그러나 소프트웨어 개발을 단순하게 프로그램 텍스트를 작성하는 행위로 가정할 경우 소프트웨어 수정과 관련된 다양한 역학 관계를 이해하지 못하는 우를 범하게 된다.

 

BNF의 창시자로 유명한 Peter Naur는 소프트웨어 개발 과정을 프로그램 텍스트를 만들어 가는 과정이 아니라 설계를 관리하기 위한 이론을 정립해 가는 과정으로 보았다. Naur에 따르면 소프트웨어 개발에 있어 가장 중요한 결과물은 프로그램 텍스트가 아니라 소프트웨어의 개념적 무결성을 손상시키지 않으면서 프로그램을 수정할 수 있는 이론이다. 프로그램을 성장시키기 위한 이론을 정립하고 있는 프로그래머는 급격하게 변화하는 환경 속에서도 자신의 이론을 자유롭게 확장하거나 수정할 수 있다. 반면 프로그램의 현재 모습만을 인지하고 있는 프로그래머의 경우 개념적 무결성을 손상시킬 확률이 높다.

 

이론 구축 관점에서 보면, 프로그래머들이 기초 이론에 대한 제대로 된 이해 없이 프로그램을 수정한 결과 프로그램 텍스트가 쓸모 없게 되어버리는 현상을 이해할 수 있을 것이다. 사실, 단순하게 프로그램 텍스트의 변화나 실행의 외적 행동 변화로만 본다면, 주어진 수정 요구는 다양한 방법으로 모두 정확하게 이루어질 수 있다. 동시에 프로그램 이론과 관련하여 본다면 이러한 방법들은 서로 다르게 보여서 일부는 다른 나머지 이론에 완전히 모순되는 반면, 나머지는 이론에 순응하거나 자연스러운 방법으로 확장될 것이고 프로그램의 주요 부분에 통합되지 않은 부분적인 성격을 띨 것이다. 다양한 변화 특징의 차이는 프로그램 이론을 소유한 프로그래머만이 이해할 수 있다. 동시에, 프로그램 텍스트에 더해지는 변화의 특징은 프로그램이 얼마나 오래 살아남느냐 하는 문제에 부딪히게 된다. 프로그램의 품질을 유지하려면 모든 수정은 반드시 이론에 기초해야 한다.

-       Peter Naur, 이론 구축으로서의 프로그래밍

 

따라서 단지 코드만을 통해 프로그램을 이해하려는 시도 역시 실패할 수 밖에 없다. 프로그램을 이해하기 위해서는 프로그램을 구축하기 위해 사용된 이론에 대한 이해가 선행되어야 한다.

 

이제 현실을 직시해 보자. 어떤 누구도 설계 문서를 통해 완벽하게 커뮤니케이션 할 수는 없다. 어떤 집단도 완전히 동일한 공유 경험을 유지할 수는 없기 때문에 작성된 설계 문서의 의도 자체를 완벽하게 이해할 것이라 예상할 수는 없다. 나아가 설계를 커뮤니케이션하는 목적은 코드의 현 상태를 전달하는 것이 아니라 코드를 발전시키고 수정하기 위한 이론을 전달하는 것이어야 한다. 따라서 코드의 현재 상태를 있는 그대로 보여주는 어마어마한 양의 설계 문서는 그렇게 효율적이지도, 효과적이지도 않다. 게다가 설계는 인지적 절차이기 때문에 깔끔하게 설명하기 어려운 지저분한 경로를 따라 작성된다. 그렇다고 설계 문서를 사람의 머릿속에서 발생하는 인지 절차에 따라 작성할 경우 어느 누구도 그 과정 속에서 합리적인 설계 이론을 학습하지 못 할 것이다.

 

그렇다면 설계 문서를 어떻게 작성해야 할까? 설계를 합리적인 과정으로 설명할 수 있는 방법은 없는 것일까? 의외라고 생각할지도 모르지만 이에 대한 해답은 꽤나 오래 전에 나와 있었다. 그것도 방법론 전쟁이 일어나기 훨씬 전인 80년대에 말이다. 이제 David Parnas의 주장에 귀를 기울여 보자.


핑백

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

    ... 있는 다음 글을 읽어보면 많은 부분에서 공감할 수 있을 것이다. 설계의 본질, 그리고 UML – 1부 설계의 본질, 그리고 UML – 2부 설계의 본질, 그리고 UML – 3부 소프트웨어 개발에 있어 세분화, 분업화로 인하여 얻을 수 있는 한계가 있다는 것을 알고 있지만 아직도 많은 소프트웨어 개발회사는 제조업의 생산성 향상 방 ... more

덧글

  • phobia 2009/08/01 05:10 # 삭제

    Interesting and good article!
  • muscly 2009/08/07 17:52 # 삭제

    너무 재밌네요. 다음 편 기대됩니다~~
  • 화니 2009/10/16 19:04 # 삭제

    잘 정리 해주셔서 잘 읽었습니다.
    좋은 글 감사합니다.
  • 이터너티 2009/10/17 16:35 #

    감사합니다. 다음 글을 써야 하는데 요즘에 여유가 없어서 글이 잘 써지지 않네요.
    조만간 마무리하도록 하겠습니다. ^^
  • 코즈 2009/12/07 11:27 #

    감사히 잘 읽었습니다.
    1,2,3부를 통해 현업에서 아직 제대로 설계를 해 보지 못한 초급개발자로서 많은 부분 배웠습니다.
    회사에서는 많은 부분에서 문서화를 요구했고, 언제나 현재를 표현하는 문서를 작성해왔습니다.
    또, h/w설계팀, 펌웨어팀, s/w팀등이 맞물려 돌아가는 임베디드 개발환경에서는
    의사소통에 항상 문제가 있다고 느끼고 있었는데
    어떤 매개 수단을 사용할 것이냐가 아닌,
    어떤 구성원과 얘기를 할 것인지 먼저 생각하고
    그에 맞게 매개 수단을 결정해야겠다는 생각이 들었습니다.
  • 이터너티 2010/02/18 11:53 #

    좋은 의견 감사합니다. ^^
    항상 최선(best)의 설계보다 현재 상황에 적합한 좋은(good) 설계를 목표로 하는 것이 가장 좋은 결과를 가져오는 것 같습니다.
    좋은 설계를 위해서는 말씀하신 것처럼 의사소통 대상에 적절한 매개 수단을 찾는 것이 가장 중요한 것 같고요.
  • skymir37 2010/01/31 00:29 # 삭제

    분석 설계 미신, 설계의 본질 1,2,3 부 정말 감사히 잘 읽었습니다.
    근데 3부 마지막을 보니 다음 내용이 잇을 것 같은데 내용이 잘린 건지 4부가 있는 건지 궁급합니다. 요근래 제가 고민하고 있는 부분에 대해 새로운 관점을 제시하는 글이라 생각되어 더욱 감사합니다. 그리고 실례가 안된다면 이터너티 님의 간략한 프로필을 알고 싶습니다. 님의 글을 제가 인용할 일이 있을 것 같아서요... 그럼 새해 복많이 받으시고 좋은 글 감사합니다.
  • 이터너티 2010/02/12 14:07 #

    답변이 늦어 죄송합니다.
    말씀하신 것처럼 3분에서 완결은 아니고 전체 5부로 생각하고 진행 중인 글입니다.
    마무리를 해야지 하면서도 이런 저런 일로 마무리를 못 하고 있었네요.
    많은 분들이 공감을 해주셔서 감사하게 생각하고 있습니다.
    최대한 빨리 마무리 하도록 노력하겠습니다.
    거창하게 프로필이라고 할 것 까지는 없지만 간단하게 아래 URL 참고하시면 될 것 같습니다.

    http://www.ibm.com/developerworks/kr/library/opendw/20090728/index.html

    그럼 skymir37님도 새해 복 많이 받으세요. ^^
  • hermian 2010/02/18 11:02 # 삭제

    좋은 글 감사드립니다.
    4부, 5부가 기대 됩니다. ^^;;
    원래 글이란 칭찬도 필요하지만 독촉도 필요하다고 봅니다.
    새해 복 많이 받으세요.
  • 이터너티 2010/02/18 11:54 #

    예 제가 좀 더 부지런히 글을 올려야 하는데 잘 안되는군요. ^^
    hermian님도 새해 복 많이 받으세요.
  • wind 2010/04/26 15:18 # 삭제

    좋은 글 잘 읽었습니다.
    업무를 진행하면서 막연하게 가지고 있던 의문에 대해서
    다시 한번 되돌아 볼 수 있는 좋은 기회가 되었습니다.
    다음편이 이어지면 정말 좋겠네요...^^
  • 이터너티 2010/05/25 23:59 #

    좋게 평가해 주셔서 감사합니다. ^^
    조만간 다음 편을 올리도록 하도록 하겠습니다.
※ 로그인 사용자만 덧글을 남길 수 있습니다.