Eternity's Chit-Chat

aeternum.egloos.com



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

인지적 설계 절차

소프트웨어 설계라는 말에는 과학적이고 공학적인 냄새를 풍기는 무언가가 있다. 그 안에는 모든 요구사항을 긁어 모아 설계라는 틀에 부어 넣기만 하면 그 즉시 문제를 해결하기에 적합한 소프트웨어 코드가 만들어진다는 환상을 심어 준다. 그리고 대부분의 방법론은 우리로 하여금 정갈하고 올곧은 황금길을 따라 가기만 하면 아무런 문제 없이 깔끔하고, 아름다운 코드를 얻게 되리라고 주장한다.

 

그러나 예상과 달리(그리고 방법론자들의 주장과 달리) 소프트웨어 설계 과정은 그렇게 합리적이지도, 과학적이지도 않다. 모든 요구사항을 수집하고, 수집된 요구사항을 바탕으로 문제 도메인을 분석하고, 분석 결과를 바탕으로 설계를 수행하는 순차적인 방식은 소프트웨어 설계의 본질을 제대로 설명하지 못 한다. 오히려 설계란 정확하게 그 절차를 설명하기 어려울 정도로 복잡한 정신적인 과정이라고 할 수 있다.

 

Robert L. Glass는 소프트웨어 설계를 인지적인 절차로 보았다.

 

전문 설계자들은 설계 작업에서 핵심을 파악할 때 경험적, 시행착오적 접근 방법을 사용한다는 것이다. 관련된 문제에 대한 예전의 설계를 기반으로 해서 설계 솔루션을 하나 생각하고, 마음 속으로 이 솔루션에 대표적인 데이터를 조금 넣어 보고, 이 데이터에 대한 작동을 모의 실험한 다음, 이 솔루션에서 데이터에 대한 출력을 뽑아낸다.

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

 

그에 따르면 소프트웨어 설계가 단순히 과학적이고 합리적인 방식으로 이루어진다고 설명하는 것으로는 부족하다. 과거에 유사한 소프트웨어를 다루어 봤던 경험을 바탕으로 효과적인 설계에 이를 수 있다. 그리고 설계를 구성할 수 있는 여러 가지 방식이 존재하기 때문에 – Bill Cutis의 말처럼 최고의 설계자들이 모인 방에서 두 명의 설계자가 동의한다면 그게 다수 의견이다 최적의 설계에 이르는 길은 다양한 설계를 시험해 보고 실패를 통해 성장하는 시행 착오적인 방법이다. 이것은 일반적인 방법론에서 볼 수 있는 합리적인 방식과는 거리가 멀다.

 

그렇다면 설계의 본질은 신속한 모델링과 시뮬레이션이다. 그리고 설계의 핵심 요소는 해결책을 제안하고 실패를 허용하는 능력이다! … 직전 시뮬레이션의 끝에는 항상 실패하는 모델, 즉 문제를 풀기에 불충분한 설계안이 있다. 따라서 성공하려면 실패하는 능력과 실패를 극복하는 능력이 필수적이다. … 설계 수행 면에서, 설계자는 기존에 생각하던 설계 본질이 틀렸다는 사실을, 오히려 시행착오를 거쳐가며 반복하던 엉성한 절차가 바로 설계 핵심이라는 사실을 이해해야 한다.

-       Robert L. Glass 소프트웨어 컨플릭트 2.0

 

인지적 설계 절차는 실패실패 극복이라는 두 가지 핵심어로 요약할 수 있다. 하나의 설계를 구상한다. 한 번에 완벽한 설계를 만드는 것은 불가능하기 때문에 초기 설계는 이상적인 솔루션과는 거리가 멀고 다양한 결함을 내포할 수 밖에 없다. 그러나 초기 설계는 다양한 대안을 탐색할 수 있는 피드백을 제공한다. 초기 설계의 실패를 발판으로 삼아 좀 더 유연하고 적절한 설계에 이를 수 있다.

 

설계의 본질이 실패를 통해 발전해 가는 과정이라면 실패를 촉진하고 대안을 탐색할 수 있는 방식이 필요하다. 린 개발 방식의 실천 도구 집합에 포함되어 있는 반복iteration과 피드백feedback을 활용하면 이 문제를 해결할 수 있다. 소프트웨어 설계에 대한 다양한 연구 결과를 통해 뛰어난 솔루션을 설계하기 위해서는 반복과 피드백이 필수적이라는 사실을 알 수 있다.

 

Horst Rittel Melvin Webber "불명확한" 문제를 전체 혹은 일부분을 해결해야만 정의할 수 있는 문제로 정의하였다(1973). 본질적으로 이러한 역설은 문제를 명확하게 정의하기 위해서 문제를 일단 한 번 "해결"해야 하며, 작동하는 솔루션을 만들기 위해서 다시 한 번 문제를 해결해야 한다는 의미를 내포한다. 이러한 프로세스가 수십 년 동안 내려온 소프트웨어 개발에 있어서의 오랜 관습이다(Peters Tripp 1976).

-       Steve McConnel, Code Complete 2nd Edition

 

Guindon은 훌륭한 설계자들이 불명확한 문제, 즉 단일한 정답이나 해결책에 도달하는 길이 존재하지 않는 문제를 다루는 경우, 상위 수준 설계와 상세 해결책 사이를 오가는 것이 전형적임을 발견했다. … 많은 소프트웨어 개발 작업들이 긴든의 연구와 유사한 문제 해결 활동이다. … 오늘날에는 설계를 조사, 실험, 결과 확인을 짧고 반복적으로 수행하여 해결책을 찾는게 올바른 문제 해결 프로세스라는 의견이 널리 받아들여지고 있다. 다른 모든 설계와 마찬가지로 소프트웨어 개발도 이러한 학습 주기를 통해 가장 자연스럽게 얻어진다.

- Merry Poppendieck, Tom Poppendieck, 린 소프트웨어 개발

 

설계란 과학적이거나 합리적인 무엇이 아니다. 오히려 시도해보고 피드백을 통해 대안을 찾아가는 반복적인 과정이다. 여러 연구 결과로부터 얻을 수 있는 교훈은 설계의 적절성 여부를 판단하기 위한 가장 중요한 피드백은 설계를 구현으로 옮기는 과정에서 얻어 진다는 점이다. 따라서 구현 전에 설계를 고정시킬 경우 실패 극복을 통해 대안을 찾아가는 탐구 과정인 설계의 본질이 손상되며 구현 과정에서 개발자들은 설계를 무시하거나 효과적인 설계를 포기하는 극단적인 선택을 취하게 된다.

 


핑백

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

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

덧글

  • muscly 2009/07/20 23:19 # 삭제

    정말 공감가는 내용입니다.
    좋은 글 감사합니다~
  • 이터너티 2009/07/25 21:40 #

    이런 내용에 공감을 하지 못하시는 분들도 많으셔서 이런 류의 글을 쓸 때마다 약간 걱정이 되고는 합니다.
    공감하신다는 말씀이 많은 힘이 되네요. ^^
  • Kevin 2009/07/21 22:59 # 삭제

    이번에도 정말 좋은 글을 써 주셨네요. 고맙습니다.
    역시 공감이 많이 가는군요.

    UML관련 1번 글에서 말씀 하신거처럼,
    진짜 제조나 건축등을 기본으로 삼아서 문제가 생기거나
    프로젝트가 효율적이지 못하게 진행되는거 같습니다.

    하드웨어와는 다르게...
    Software is soft. 인데 말이죠.
    건물이야 한 40층짜리 건물 짓다가 20층쯤 올리고 나서
    "어? 이거 아니네?", "뭔가 이상하네?" 하고 만들던거 부수고
    새로 시작할수 있는게 아니기에,
    설계부분에서 충분히 검토후 그걸 토대로 그냥 건설을 해야하지만,
    소프트웨어 개발은 중도에 변경이 가능하고,
    가능할수 있게 충분히 유연해야 하는데 말이죠.

    전에 이터너티님께서 다른글에서 언급하신
    분석, 설계, 구현의 삼위일체가 여기서도
    중요한 역할을 하는거 같습니다.
    분석이 곧 설계고 설계는 구현해보므로써 증명되고,
    해보니 안되면 다시 분석, 설계 그리고 구현의
    반복을 통해서 좀더 명확한 답을 찾는게 정답인거 같습니다.

    갑자기,
    방법론만 가지고 입으로 소프트웨어 개발할것 같은
    아키텍트분과 대화했던게 생각나네요.
    진짜 답답해 죽는줄 알았습니다.
    System Requirement Specifications (SRS) 보면서도
    로그인이 functional이니 아니니 non-functional 이니 아니니
    이런거에만 집착하고 있더군요... @_@;
  • 이터너티 2009/07/25 21:44 #

    kevin님 잘 지내세요?
    제가 난해한 문장으로 써놓은 이야기를 쉽게 풀어주셨네요. ^^
    반복과 피드백을 통한 학습 과정을 통해 발전해 나가는 것이 소프트웨어 설계의 핵심이 아닐까 합니다.
    공감해 주셔서 감사합니다.
  • 코즈 2009/12/07 10:54 #

    감사히 잘 읽었습니다~~
    (_ _)
※ 로그인 사용자만 덧글을 남길 수 있습니다.