맨먼스미신

한줄평.

맨먼스미신(늦어진 소프트웨어에 인력을 투입하면 더 늦어진다), 은탄환은 없다(소프트웨어의 일정, 예산, 결함등의 문제를 급격히 해결해 줄 방법은 없다)는 40년 전에 주장되었지만 현재까지도 유효한 주장이다.

책과 저자 소개

“맨먼스미신”[1]은 소프트웨어 공학 분야에서는 고전 중에 고전이다. 프레데릭 브룩스 2세 교수님이 저자이며 강중빈이 번역하고 인사이트에서 출판한 책을 보았다. 프레더릭 브룩스 교수님은 현재 87세이신데도 아직까지 현역으로 대학에서 연구와 교육을 하고 계신다.

브룩스 교수님이 더 대단하다고 생각되는 건 현재 연구하는 주제들이 책에서 주장하신 소프트웨어의 본질적인 어려움을 차근차근 해결하기 위한 연구들이라는 점이다. 그 연구들은 가상환경 설계, HCI, 3D Interactive Computer Graphics, Scientific Visualization이다. 교수님 웹페이지(http://www.cs.unc.edu/~brooks/)에서도 볼 수 있다.

책 후기에 적힌 “신은 인류 중 오직 일부에게만 아무런 대가 없이도 열정으로 기꺼이 했을 일로 생계를 삼는 특권을 부여하셨다. 나는 너무나 감사하다” 이 말에 지치지 않는 열정으로 살고 계시는 것을 알 수 있으며 그러한 점을 존경하게 된다. 이분에 대한 존경심으로 이후 내용에서 이 분을 저자라고 지칭하기 보단 교수님으로 지칭한다.

“맨먼스미신” 초판은 1975년에 출간되었으며, “은탄환은 없다”라는 논문은 1986년에 기고된 것이다. 이 둘이 모두 포함한 20주년 기념판인 이 책도 1995년 만들어졌다. 초판은 지금으로부터 43년 전에 나온 것을 알고 나서야 책 내용의 낯선 기술, 제품, 사례들이 나에게 낯설었는지 알 수 있었다. 책 뒤에 실린 부록인 “조금 오래된 컴퓨터 이야기”를 먼저 봤으면 낫지 않았을까 생각한다.

서평 개요

이 책은 “개발자, 한 달에 책 한권 읽기” 독서 모임[2]에서 10월에 선정한 책이다. “맨먼스미신”은 책 제목만 들어왔었고 브룩스 법칙인 ”늦어진 소프트웨어 프로젝트에 인력을 추가로 투입하면 더 늦어지게 된다” 말만 알고 있었다. 실제 책을 읽어볼 생각조차 안 하고 있었는데 이번에 좋은 기회가 됐다. 지난 서평이였던 “프로그래밍의 정석”에서도 “브룩스 법칙”과 “은 탄환은 없다”가 설명되어 있어 지난 책과 이번 책을 연계해서 보게 되었다. 이전 책 내용을 자세히 이해할 수 있던 계기가 되었다.

전반적인 책 구성

이 책의 메뉴를 살펴보면 초반에 문제현상과 원인을 제시하고 이를 해결하는 방법을 제안하는 순서로 구성되어 있다. 후반부 챕터는 기념판으로 다시 쓰면서 논란과 화제가 많이 된 맨먼스미신과 은 탄환은 없다를 교수님이 다시 재논의한 챕터가 들어가있다. 자신의 주장이 계속 맞다라고 주창하는 게 아니라 틀린 것은 확실히 잘못되었다라고 인정하는 모습이 교수님에 대한 존경심을 불러일으키게 한다.

교수님은 설계에서 개념적 일관성을 지키는게 중요하다고 강조한다. 교수님 책 구성에서도 개념적 일관성을 지키는 것을 보여 주었다. 최근 저서인 “디자인오브디자인”에서 이 점을 알 수 있다.

내가 본 핵심부분

지난 서평에서 모든 챕터를 요약하니 분량이 너무 많아져서 읽기가 부담스러웠다. 이번 서평은 책에서 핵심이라고 생각된 부분만 써서 적당한 분량으로 조절하였다. 소개할 챕터는 “맨먼스미신”과 “맨먼스미신, 20년 후”을 이어서 소개하고 “은 탄환은 없다”와 “은 탄환은 없다를 다시 쏘다”를 연결해서 소개한다.

맨먼스미신. 한 문장으로 얘기하면 브룩스의 법칙, “늦어진 소프트웨어 프로젝트에 인력을 추가로 투입하면 더 늦어지게 된다.”이라 할 수 있다. 사람들이 인력을 투여하는 것에는 사람과 일정이 서로 교환 가능하다라는 잘못된 인식이 깔려 있다고 한다. “프로그래밍의 정석”에서 아래 공식으로 이를 잘 설명한다. 

man x month ≠ month x man

사람과 일정은 상호교환되지 않는다.

ex) 6 men x 2 months ≠ 2 months x 6 men

일정이 늦어지게 되는 이유를 아래 두 가지로 설명한다. 첫째는 투입된 인력에게 프로젝트 적응 교육(기술적인 내용, 목표, 전략, 업무 계획 등)을 하기 위해 기존 인력이 현재 프로젝트 진행을 중지하고 교육을 하게 되어 다시 일정이 늘어난다는 것이다.

둘째는 추가 인력을 투입하기 위해 기존 조직 구조와 업무 재분배를 해야 하는데 이를 위한 팀들과 팀원간의 의사소통의 수고가 더 들게 되고 결국 개인의 개별 업무 시간마저 잠식해 버린다는 것이다.

다시 읽어보면 너무 당연한 말이다. 책을 읽으며 내가 느낀 바는 얄팍한 수로 해결하려고 하지마라라는 것이다. 그래서인지 교수님이 아래 문장을 서두에 한 번하고 말미에 한 번더 반복하여 강조한다.

부족한 시간 탓에 망가진 소프트웨어 프로젝트 수는 다른 이유로 그렇게 된 경우를 모두 합한 것보다도 많다.

맨먼스 미신, 20년 후. 교수님이 맨먼스미신 20주년 기념판을 쓰면서 이야기한 옳았던 내용과 틀렸던 내용이 무엇인지 보자.

옳은 내용의 핵심은 개념적 일관성과 아키텍트에 관한 것이다. 개념적 일관성을 갖춘 깔끔하고 우아한 프로그래밍 제품이라면 일관된 심성모델을 모든 사용자에게 제공해야 한다. 응용 분야, 응용 전략, 동작과 매개 변수를 지정할 때의 사용자 인터페이스 등이 여기에 포함된다.

대규모 프로젝트에서는 인원, 시스템의 규모가 소규모 프로젝트와는 질적으로 다르므로 일관성을 얻기 위해 계획적이고 소수의 아키텍트에 의한 영웅적인 관리가 필요하다고 한다. “외과 수술 팀”장과 “귀족정치, 민주주의, 시스템 설계”장에서 팀구조 구성 방법과 소수 아키텍트를 유지하는 방법을 자세히 설명한다.

일관성을 아주 잘 지킨 매킨토시의 사례가 개념적 일관성을 잘 설명해 주고 있다. WIMP(Window, Icon, Menu, Pointing device)는 탁상이라는 익숙한 비유를 도입했다. 여기에서 일관성을 그대로 유지한 부분과 확장한 부분이 소개된다.

유지된 예로는 아이콘을 끌어서 놓는 동작이나 선택하는 동작은 물건을 이동 시키고 집는 동작에서 유추할 수 있다. Window의 크기를 늘리고 모양을 바꾸며 디스켓 아이콘을 휴지통에 넣어 실제 디스켓이 나오는 방식은 탁상 비유를 충실히 따르면서 그 확장에도 일관성이 있는 예이다.

매킨토시에서 주목한 또 다른 면은 교수님이 주장한 “직접적 포함”이다. 맥 인터페이스를 여러 응용 프로그램에 걸쳐 사용할 수 있게 인터페이스 요소들을 직접 포함 시켰다. 개발자들이 자기만의 인터페이스를 만들기보다 그냥 그것을 쓰는 편이 더 쉽고 빠르게 하여 통일성을 자연스럽게 장려한 것이다.

틀렸다고 한 내용은 “버리기 위한 계획”, “바벨탑은 왜 실패하였는가?” 챕터에서 한 주장들이다. “버리기 위한 계획” 챕터에서는 대부분 프로젝트에서 나오는 첫 시스템에 문제가 있을 수 밖에 없으니 처음부터 변경될 수 있게 고려한 계획을 하라는 것이다. 이 주장에서 가정된 프로젝트 개발프로세스가 폭포수 개발 모델로 전제하였는데 이게 잘못되었다라고 한다. 폭포수 모델은 시스템 테스트가 전체 과정의 마지막에 있게 되어 사용자 테스트도 마지막에 하게 된다는 것이다. 결국 테스트로 알게 되는 사용상의 오류, 불편함, 불충분한 성능을 마지막에 알게 된다. 이러한 오류가 있는 개발모델을 전제한 버리기 위한 계획도 역시 테스트를 마지막에 하게되어 개선이 마지막되어 문제라는 것이다.

또 다른 틀린 내용은 “바벨탑은 왜 실패하였는가?”에서 프로젝트 워크북에 있다고 한다. 프로젝트 워크북은 프로젝트 진행 시 생산될 문서들로 구성된 하나의 체계이다. 여기에 문제가 된 것은 모든 업무 내용을 모두의 시선 아래 드러내라고 한 것이다. 교수님은 이를 통해 상호간에 압박이 되고 여러 사람이 보게 되면서 결함과 버그를 실제 발견하여 품질 관리에 도움이 된다고 하였다.

하지만 변화를 받아들여야 할 때 모든 공개는 이를 더디게 한다. 그래서 교수님이 문제에 대한 대안으로 받아들인 주장은 파르나스의 정보은닉이다. 정보은닉이란 코드의 모듈이 잘 정의된 인터페이스로 캡슐화되어야 하며, 모듈 내부 구조는 담당한 프로그래머의 사유물로서 외부에 노출되지 않아야 한다는 것이다. 이로 인해 변경에 대해 강건하며, 변화를 염두에 두는 설계에 더 적합하게 된다고 한다. “버리기 위한 계획”에서 주장한 변화와 맥을 맞추게 된다.

은 탄환은 없다. 이 말은 소프트웨어의 일정, 예산, 결함등의 문제를 급격하게 해결할 방법이 없다는 것이다. 방법이 없는 이유는 소프트웨어에 본질적인 어려움이 있어서 이다. 본질적 어려움이란 마음속에 개념적 구조물을 만드는 과정이 어렵다는 것을 의미한다. 그렇다면 왜 개념적 구조물을 만드는 과정이 어려운가? 소프트웨어에 내재된 속성, 즉 복잡성, 호환성, 변경 가능성, 비가시성 때문이다라고 주장한다.

• 복잡성: 소프트웨어 시스템이 인간이 만들어 낸 대부분의 사물보다 복잡하며 상태의 수가 자릿수가 다를 정도로 상태가 많고 이 상태들이 비선형적으로 상호작용하여 전체 복잡도의 증가율이 비선형적으로 급증함을 의미한다.
  
  
• 호환성: 자연계를 연구하는 물리학자들은 무언가 일관된 원칙이 발견될 것이라는 굳은 믿음에 기초한다. 반면 소프트웨어는 여러 인간에 의해 각기 설계되었다. 각각의 소프트웨어는 상당 부분 임의성을 띄는 인터페이스를 가지고 있으며 만들어진 시기도 각각 다르다. 이런 각기 다른 인터페이스를 맞추는 건 복잡성을 더 초래한다.
  
  
• 변경 가능성: 소프트웨어는 순수한 사고의 부산물로 자동차처럼 제조되는 물건이 아니기에 변경의 압박을 가장 많이 받는다. 특히나 성공한 소프트웨어는 사용자들의 요구로 변경이 불가피하다. 또한 성공한 소프트웨어는 만들때 동작하도록 의도된 장비들보다도 수명이 오래 간다. 새 장비들과 호환을 이루기 위해 변경되어야 한다.
  
  
• 비가시성: 소프트웨어의 실체가 본질적으로 공간에 포함되지 않아 기하학적 표현으로도 존재하지 않는다. 구조를 한정짓고 단순화시키는 것은 가능하나 이렇게 하면 결핍이 발생한다. 결핍은 한 사람의 설계과정을 지연시키고 사람들 사이의 의사소통도 저해시킨다.

그동안 소프트웨어 분야의 생성성을 높인 해결책들은 본질적 문제를 해결하기 보단 개념적 구조물(소프트웨어)을 구현하는 과정 즉 부수적인 문제를 해결하는 것들이었다. 고급언어, 시분할방식, 통합된 프로그래밍 환경이 여기에 속한다. 부수적 해결책만으로는 본질적 어려움을 해결할 수 없다. 지금 시점에도 생산성을 극적으로 올린 방법론과 도구가 없음을 보면 아직도 본질적 어려움이 해결되지 않았음을 알 수 있다.

그러나 본질적 문제를 겨냥한 시도들도 있었다. 소프트웨어 패키지 상품, 요구사항 상세화와 고속 프로토타이핑, 점진적 개발 등이다. 패키지 상품은 만들 고민이 필요없는 가장 급진적 해결책이라고 한다. 하지만 아직 패키지의 범용화 수준이 몇몇 예외를 제외하곤 수년간 별로 변하지 않았다라고 주장하였다.

요구사항 상세화와 고속 프로토타이핑은 무엇을 만들지에 대해 정하는 일로 본질적 문제를 가장 잘 겨냥한 시도이다. 프로토타입을 통해 요구사항을 더 정확하게 정의할 수 있으며, 프로토타입과 실제 제품이 반복적으로 개발되는 과정이 점진적 개발 과정인 것이다. 현재의 애자일 방법론에서 이 개념을 엿볼수 있다.

은 탄환은 없다를 다시 쏘다. “은 탄환은 없다”는 1986년에 발행된 논문이다. 교수님이 이번 챕터 시작에서 얘기했듯이 맨먼스미신은 불합리함을 밀쳐내는 주제이기에 많은 사람들이 받아들이고 싶어하고 논쟁이 거의 없었다. 이와 달리 “은 탄환은 없다”는 사람들이 가질 수 있는 마법같은 해결책은 없다라고 바램을 단칼에 자르는 내용이라 받아들이기가 쉽지 않았던 것이다. 논문 발행 10년뒤에도 교수님에게 반박 논문, 편지, 에세이들이 계속 쏟아져 보내졌다는 걸보면 알수 있다.

21세기 현재까지 많은 기술의 발달에도 불구하고 교수님이 얘기한 소프트웨어의 본질적인 어려움을 해결하여 생산성을 눈에 띄게 해결한 것이 없기에 이제는 과거보다 좀 더 많은 사람들이 받아들였을 것이다. 이번 챕터는 투고자들이 보낸 개선사항과 반론들을 다루면서 역시나 은 탄환은 없다를 재확인하게 된다.

이 전 논문에서 논점을 명확히 못한 부수적이라는 용어를 다시 설명하여 나 역시도 다시 쏘다 챕터롤 통해 본질적과 부수적이라고 한 부분을 명확히 알 수 있었다. 아래에 내가 이해할 수 있게된 구절을 발췌한다.

소프트웨어 제작에서 ‘본질적’이라고 한 부분은 마음속에서 개념적 구조물을 만드는 과정이며, ‘부수적’이라고 한 부분은 그 구조물을 구현하는 과정에 해당한다. 

…(중략)...

소프트웨어를 만드는 노력 중에서 개념적 구조물을 정확하고 질서정연하게 표현하는 데 연관된 부분은 얼마나 되며, 그 구조물을 마음속에서 빚어내는 데 드는 노력은 또 얼마나 되는가? 결함을 찾아내고 수정하는 일은, 그 결함이 어떤 예외 상황을 놓치는 경우처럼 개념적인 것인지, 또는 포인터 사용이나 메모리 할당 실수처럼 개념을 표현하는 일에 관련된 것인지에 따라 양쪽에 부분적으로 모두 해당된다.

…(중략)...

“은 탄환은 없다”에서 명백히 주장하는 바는, 부수적인 부분이 전체의 9/10에 못 미치다면 마법으로든 뭐든 그것을 완전히 제거한다해도 생산성에 자릿수 하나만큼의 향상을 가져올 수는 없다는 것이다. 우리는 본질적인 것을 공략해야 한다.

소개된 반론은 데이비드 하렐과 케이퍼스 존스의 주장에 대해서 이다.

하렐은 브룩스 교수님이 1970년부터 글을 쓴 1986년까지를 관찰하여 은탄환이 없다라고 판단하는 것 같다라고 생각한 것 같다. 그래서 시간대를 훨씬 과거인 1950년부터 1986년까지로 확대하여 사고실험을 하면 당시보다 10배 이상의 생산성 향상이 있었다라고 주장하였다. 

브룩스 교수님의 이에 대한 반론으로 1950년 시대에는 부수적 어려움이 본질적인 어려움을 압도하는 상황이었기에 그 둘을 비교하는 건 불합리하다라고 한다. 컴퓨터 하드웨어 발전 역사를 봐도 이 두 시대는 너무 현격한 차이가 있는 것을 알 수 있다. 1950년대는 진공관 CPU와 천공카드로 입출력을 했었다. 1980년대는 고밀도 트랜지스터 CPU와 광디스크와 모니터, 키보드를 입출력으로 사용했었다.

또 다른 하렐의 주장으로 소프트웨어의 개념적 구조를 도표로 표현할 본질적 방법이 존재한다라는 것이다. 이에 교수님은 하렐이 말한 각기 다른 측면을 표현하기 위해 여러 도표가 필요하며 어떤 경우는 도표로 나타낼수 없다는 점에 대해선 동의하나 역시나 개념적 구조를 3차원 공간에 담을 수 없으며 평면이든 그 이상의 차원이든 도표 하나에 개념적 설계를 대응시킬 자연스런 방법은 없다는 것이다. 

다른 사람의 반론인 존스의 주장은 품질에 집중하면 생산성은 따라온다라는 것이다. 그는 체계적 품질 관리의 부재와 일정 붕괴 사이에 강한 상관관계가 있음을 데이터로 의견 제시를 하였다.

교수님은 보엠과 코키의 주장을 보여주며 이를 반론하였다. 보엠은 IBM 우주 왕복선용 소프트웨어 사례처럼 극단적으로 품질을 추구할 경우 생산성이 다시 하락하였다라고 주장했다. 코키의 주장에는 1970년대에 공학적 원리들을 소프트웨어 생산에 적용한 것은 소프트웨어 제품의 품질, 시험 용이성, 안정성, 예측 가능성을 높이기 위함이었지, 딱히 소프트웨어 생산의 효율 때문은 아니었음을 유의해야 한다라며 품질에 집중보단 대형 사고의 회피를 염두한 것들이라고 하였다.

챕터 말미에 객체 지향 프로그래밍과 프로그램 재사용 방법이 상당히 좋은 개념과 방법이긴 하나 이것들 역시 은 탄환은 되지 못했다고 한다. 객체 지향 프로그래밍의 ‘모듈화’, ‘캡슐화’, ‘상속’은 상당히 장래성이 있지만 그 당시 프로그래머들에게 재교육이 미비하여 설계 원리를 이해하여 설계하는 것이 부족하다고 한다. 재사용 방법은 소프트웨어 본질을 공략하여 만들 필요 없이 사용하는 것으로 좋은 방안이나 재사용 프로그램을 만들 때 비용이 많이 들고 이를 사용자가 잘 사용하기 위한 좋은 문서화 작업도 어렵다고 한다.

소감

책을 다 보고 나니 책속의 기술이나 장치들은 오래되었으나 그 안에 담긴 주제는 현재까지도 변하지 않고 그대로 인 것을 보면 감탄하게 된다. 아직도 현장에 계시는 것을 보면 존경심이 든다. 최근의 함수형 프로그래밍과 도메인 주도 개발(DDD)들이 대두되는 걸 보면 소프트웨어 본질적 어려움을 해결하기 위한 점진적 시도가 계속된다라는 걸 알 수 있다. 또한 부수적 어려움을 해결하기 위한 애자일 방법론, 테스트 주도 개발(TDD) 등이 시도 중이다. 이러한 현상들을 보면 교수님이 21세기 지금도 여전히 “은 탄환은 없다”라고 하실 것 같다.

각주

[1] 맨먼스미신 도서: http://www.aladin.co.kr/shop/wproduct.aspx?ISBN=8966261329

[2] 개발자, 한 달에 책 한 권 읽기 모임: https://www.facebook.com/dev.reader/