[231219][WIP] 타르구덩이에서 빠져나오기 위한 여정
Table of Contents
1 Disclaimer
이 글은 개인적인 기록을 위한 글이며, 사견이 깊게 관여하고 있음.
2 Man Month Myth
맨먼스미신은 프레드릭 브룩스의 저서이다.
2.1 타르구덩이
공룡, 매머드, 검치호랑이 같은 짐승들이 끈끈하게 붙 잡는 타르를 뿌리치기 위해 안간힘을 쓰고 있다. 몸부림이 거셀수록 타르는 더 얽혀들고,어떤 짐승도 거기서 벗어날 만큼 힘이 세거나 능 숙하지 못해서 마침내 가라앉고 만다.
대규모 시스템 프로그래밍이란 분야는 지난 10여 년간 이런 타르 구덩이 같았고, 수많은 거대하고 힘센 짐승들이 그 속에서 격렬히 몸 부림쳤다. 대부분은 어쨌거나 작동되는 시스템을 만들어서 헤쳐나왔지만, 목표와 일정과 예산을 충족한 경우는 드물었다. 크고 작고를 가 리지 않고 숱한 팀들이 차례로 타르 속에 얽혀들어갔다. 타르 속에서는 어느 쪽 발이라도 움직이는데 별 지장이 없으니 딱히 원인으로 지목할 만한 것을 찾기도 어렵다. 그러나 동시적이고 상호 작용하는 요인들이 쌓이면서 움직임은 점차로 둔해진다. 문제의 까다로움에 모두가 놀라게 되고, 그 본질을 분별해내는 일은 어려워진다.
하지만 문제를 해결하기 위해서는 먼저 문제가 뭔지 이해하려는 노력이 필요하다. 그러므로 이제 시스템 프로그래밍이라는 기예가 대체 어떤 것인지, 또 거기에 어떤 즐거움과 고달픔이 배어 있는지부터 알아보자.
2.2 맨먼스 미신
훌륭한 요리에는 시간이 필요합니다.혹시 저희가 기다리시게 했다면, 더 잘 섬겨 모셔서 만족을 드리기 위함입니다.
- 미국 뉴올리언스New Orleans 소재 앙투안Antoine 레스토랑의 메뉴판
2.2.1 맨먼스
두 번째 잘못된 사고방식은 추정 및 일정 관리에서 투입된 노력을 셈할 때 쓰는 단위에 나타나 있는데, 바로 맨먼스man-month라는 단위다. 사람과 일정이 교환 가능한 유일한 경우는, 어떤 일을 여러 사람에게 나눠줄 수 있으면서 서로 간에 소통할 필요가 없는 경우다(그림 2.1). 이것은 밀을 수확하거나 목화를 따는 일에는 들어맞겠지만, 시스템 프로그래밍에는 대략이라도 해당되지 않는다.
만약 작업에 순서가 있어서 나누기 어렵다면, 거기에 어떤 노력을 더 쏟아 붓더라도 일정에는 아무런 영향을 미치지 못한다. 아기가 세상에 태어나려면 임산부가 몇 명이든 아홉 달이 필요하다.
2.2.2 은 탄환은 없다: 소프트웨어 공학에 있어 본질과 부수성
하드웨어 분야의 전자공학, 트랜지스터 등이 기여한 것처럼 소프트웨어의 생산성, 신뢰성, 단순성에 기여할 만한 발명은 없을 것이다. 2년마다 두 배의 발전 같은 것은 더군다나 기대할 수 없다.
첫번째로, 소프트웨어 분야의 발전이 더딘 것을 이상하게 볼 것이 아니라 하드웨어의 진보가 이례적인 일임을 알아야 한다. 문명이 시작된 이래 그 어떤 기술도 30년 사이에 가격 대 성능 면에서 여섯 자리수 단위의 발전을 이루지는 못했다.
둘쨰로, 소프트웨어 분야의 발전에 내재된 어려움이 무엇인지 알아볼 것이다.
아리스토텔레스를 따라 이것을 본질적인 것, 즉 소프트웨어의 본성에서 비롯된 어려움. 그리고 부수적인 것, 즉 오늘날 소프트웨어 생산에 수반되지만 본질적이지 않은 어려움들로 나누고자 한다.
- 소프트웨어의 본질적 어려움
- 복잡성
소프트웨어 개체들은 그 크기에 비하면 인간이 만든 어떤 구 조물보다도 복잡한데, 이는 어느 하나라도 다른 것과 (최소한 문장 이 상의 수준에서는) 비슷하지 않기 때문이다. 만약 두 부분이 비슷하다 면 그 둘은 개방형이든 폐쇄형이든 하나의 서브루틴으로 묶을 수 있을 것이다. 이런 점에서 소프트웨어 시스템은 반복되는 요소를 허 다하게 포함하고 있는 컴퓨터, 건축물, 자동차와 근본적으로 다르다.
소프트웨어 개발의 많은 고전적 문제가 본질적 복잡성 및 그 비선형적 증가 양상에서 비롯된다. 복잡성 때문에 팀 구성원들 간 의사소통이 어려워지며, 그로 인해 제품 결함, 비용 초과, 일정 지연이 발생한다. 복잡성 때문에 프로그램의 모든 가능한 상태를 일일이 나열하거나 이해하는 일이 어려워지며, 그로 인해 신뢰성이 훼손된다. 함수의 복잡성 때문에 그것을 호출하는 일이 어려워지며, 그로 인해 프로그램이 사용하기 힘들어진다. 구조의 복잡성 때문에 부작용 없이 프로그램의 기능을 확장하는 일이 어려워진다. 구조의 복잡성 때문에 가시화되지 않은 상태가 생겨나서 보안상의 허점이 만들어진다.
기술적인 것뿐 아니라 관리적인 문제까지도 복잡성에서 비롯된다. 이 복잡성 때문에 전체를 개관하기가 힘들어지고, 그로 인해 개념적 일관성을 유지하는 일이 방해받는다. 미해결 사안들을 모두 찾아내고 통제하는 일이 어려워지며, 학습과 이해에 엄청난 부담을 주어 인원교체가 재앙이 된다.
- 변경 가능성
소프트웨어 개체는 끝없는 변경 요구에 노출되어 있다. 자동차의 리콜은 상당히 드문 일이며, 컴퓨터의 현장 교체는 약간 덜하다. 소프트웨어는 순수한 사고의 부산물이며 가변성이 무한하다. 건물도 실제로는 변경이 이루어지지만, 모두가 알고 있는 대로 그러려면 많은 비용이 든다는 사실이 변경을 바라는 이들의 변덕을 약화시킨다.
성공적인 소프트웨어는 모두 변경을 피할 수 없다. 이 변경에는 두 종류의 과정이 있다.
- 소프트웨어 제품이 유용하다고 판단되면, 사람들은 원래 의도된 범위의 가장자리 또는 그것을 벗어난 새로운 경우에 대해 그 소프트웨어를 시험하기 시작한다. 기능 확장에 대한 압박 은 주로 이처럼 기본 기능을 마음에 들어 하여 새로운 용도를 만들어 내는 사용자들로부터 비롯된다.
- 두 번째로, 성공적인 소프트웨어는 애초에 동작하도록 의도된 대상 장비의 통상적인 수명 이후까지 살아남는다. 새 컴퓨터는 아니더라도 최소한 새 디스크, 새 디스플레이, 새 프린터들이 나타나고 소프트웨어는 이런 새 장비들과 호환되어야만 한다.
요약하자면, 소프트웨어 제품은 응용 분야, 사용자, 법 조항, 주변 장비들이 만들어내는 문화적 모체 안에 파묻혀 있다. 이 모든 것은 지속적으로 변화하고, 그 변화는 소프트웨어 제품의 변경을 가차 없이 강제한다.
- 비가시성
소프트웨어는 보이지 않으며 시각화할 수도 없다. 기하학적 추상화는 강력한 도구다. 건물의 평면도는 설계자와 고객 모두에게 공간, 교통 흐름, 전망을 검토하도록 도와준다.
추상화된 형태이긴 하지만 기계 부품의 축척도와 볼-스틱 분자 모델도 같은 역할을 한다. 기하학적 실체는, 기하학적 추상화 속에 포착된다.
소프트웨어의 실체는 본질적으로 공간 안에 포함되지 않는다. 소프트웨어의 구조를 도표로 나타내려 시도한다면, 우리는 이내 그 구조가 여러 개의 directed graph 로 구성되며, 각각 서로 겹친다는 것을 알게 된다. (제어 흐름, 데이터 흐름, 의존 관계 패턴, 시간적 순서, 이름-공간 관계 등)
- 복잡성