언해본

Martin Fowler – 설계와 개발의 분리

글쓰는 프로그래머 2010. 7. 17. 10:07

원문 http://www.martinfowler.com/articles/newMethodology.html#SeparationOfDesignAndConstruction

소프트웨어 개발 방법론은 흔히 토목공학 혹은 기계공학과 같은 공학분야에서 비롯된다. 이들 공학은, 작업을 시작하기 전, 계획단계를 주로 강조한다.

엔지니어들은 무언가를 만들기 위해 무엇이 필요한지, 필요한 것들이 서로 어떻게 조합되어야 하는지를 아주 정교하게 보여주는 일련의 설계도를 그린다. 다리에 가해지는 부하를 어떻게 해결해야 하는 지와 같은 수많은 결정이 이러한 설계도를 작성하는 과정에서 이뤄진다. 이렇게 작성된 설계도는 다른 그룹, 종종 다른 회사에 전달되어 설계도에 따라 다리를 만들게 된다. 시공을 하는 동안 몇 가지 문제에 부딪히곤 하지만 이러한 문제는 흔히 작다.

설계도는 건축물을 구성하는 구조물을 기술하고, 이러한 구조물들이 어떻게 조합되어야 하는지를 알려주기 때문에, 상세 시공 계획을 위한 기초가 된다. 이러한 계획을 통해서, 어떠한 작업이 행해져야 하고, 그들 작업간의 연관관계를 알 수 있다. 또한 합리적이고 예측 가능한 일정계획과 예산수립을 가능케 하며, 사람들이 어떤 작업을 해야 하는지를 자세히 알게 한다. 아울러, 시공을 머리를 써야 하는 일에 익숙하지 않은 사람에게도 가능케 한다.

여기서 알 수 있는 것은, 근본적으로 다른 두 가지 작업이 있다는 것이다. 설계는 예측하기 어렵우며, 비싸고 창의적인 사람이 필요하지만, 시공은 예측하기 비교적 쉽다는 것이다. 일단 우리가 설계도를 갖게 되면, 우리는 시공을 위한 계획을 할 수 있으며, 시공 계획을 갖게 되면, 많은 예측 가능한 방법으로 시공을 할 수 있다는 것이다. 토목공학에서 시공은 설계와 계획보다 아주 많은 비용과 시간이 든다.

소프트웨어 공학 방법론의 접근 방법은 다음과 같은 것으로 보인다.

우리는 낮은 기술등급의 사람을 쓸 수 있는 예측 가능한 계획을 원한다. 이것을 위해서 개발로부터 설계를 분리해야 한다. 따라서 일단 계획이 세워지고, 개발이 곧장 이뤄질 수 있도록 하려면, 어떻게 소프트웨어 설계를 해야 할 것인가에 초점을 맞춰야 한다.

이를 위한 설계는 어떤 양식을 가져야 할까? 많은 사람들에게 이것은 UML과 같은 설계 표기법의 역할이다. 만약에 우리가 UML을 통해서 충분한 설계를 할 수 있다면, 우리는 개발 계획을 작성할 수 있고, 개발 작업을 진행하는 coder에게 설계 산출물을 전달 할 수 있다.

그러나 여기에 중요한 질문이 있다. 예측 가능한 개발을 위한 소프트웨어 설계를 할 수 있나? 만약 그렇다면, 이러한 접근 방법이 가치가 있을 만큼, 설계에 소요되는 비용이 충분이 작은가?

이것은 또다시 몇몇 질문을 떠오를 게 한다.

첫째, 프로그래머에게 전달할 수 있는 UML 과 같은 설계를 하는 것이 얼마나 어려운가? UML과 같은 설계는 종이로 봤을 때는 아주 그럴 듯 하게 보이지만 실제로 이것을 프로그램하려고 하면 심각한 결함을 갖고 있음을 알게 된다. 토목공학자들이 사용하는 모델은 수 많은 세월 동안의 경험에 기반한 것이다. 더욱이 중요한 이슈는 수학적 분석에 따라서 작성되게 된다. UML과 같은 다이어그램을 통해서 우리가 할 수 있는 유일한 체크방법은 동료검토다. 동료검토가 유용하긴 하지만, 설계에 있어서의 오류는 종종 코딩과 테스팅 동안에만 나타난다. 유능한 설계자 – 나 또한 유능하다고 생각하곤 하지만 - 조차도 소프트웨어 설계가 개발되는 과정에서 나타나는 오류로 깜짝깜짝 놀라곤 한다.

또 다른 이슈는 비용에 관련되는 것이다. 다리를 만들 때 설계에 들어가는 비용은 전체 작업의 약 10%정도이다. 소프트웨어에 있어서 코딩에 들어가는 시간은 무척이나 작은데, 맥코넬에 따르면 대규모 프로젝트에 있어서 코딩과 단위 테스트에 들어가는 시간은 15%에 불과하다. 다리 건설의 비율과 거의 완벽히 반대인 것이다. 개발과정의 모든 테스트를 포함한다 할지라도 설계는 여전히 50%가 된다. 이러한 점은 다른 공학분야와 다른, 소프트웨어 설계의 본성에 대한 중요한 의문점을 발생케 한다.

이러한 종류의 질문은 Jack Reeves로 하여금 다음과 같은 결론을 이끌어 냈다.

소스코드가 설계이며 구축과정은 실제로는 컴파일러와 링커를 사용하는 단계이다. 실제로 구축과정상의 작업은 자동화되어야 한다.

결국 이러한 생각들은 몇 가지 중요한 결론에 도달하게 된다.

  • 소프트웨어에 있어서 구축과정은 아주 싸며 거의 무료다
  • 소프트웨어에 있어서 모든 노력은 설계이며 따라서 창조적이고 뛰어나 능력의 사람들을 요구한다.
  • 창조적인 작업은 계획하기가 쉽지 않으며 따라서 예측하기란 거의 불가능에 가깝다.
  • 소프트웨어의 개발에 있어 전통적인 공학적 비유를 하는 것은 매우 조심스럽게 접근해야 하는 것이다. 소프트웨어를 개발하는 것은 일반적인 공학적 활동과는 다른 종류의 활동이며 다른 절차를 요구한다.