Agile Note 일곱 번째

[제임스 브룩스의 The Mythical Man-Month  리뷰]

지난 글의 연장선상에서 소프트웨어 개발의 불확실성에 대한 오랜 고전인 제임스 브룩스의 '맨먼스 미신(The Mythical Man-Month)'에 대해 같이 공유하고자 합니다. 소프트웨어 공학 분야에서는 워낙 고전에 속하는 책이라 많은 분들이 이미 읽어보셨거나, 내용에 대해 알고 계시리라 짐작합니다.

 

1975년에 초판이 발행된 만큼 지금의 소프트웨어 개발 방법론, 개발 기술, 관리방법 등에서 많은 차이가 있지만, 40여 년이 지난 지금도 여전히 유효한 명제들과 교훈들을 제시하고 있습니다. 제임스 브룩스의 책 내용을 기반으로 개인적인 생각을 덧붙이는 형태로 정리해 보겠습니다.

 

# The Mythical Man-Month

책의 두 번째 챕터인 The Mythical Man-Month 시작 페이지에 다음과 같은 문구가 나옵니다. "Good cooking takes time. If you are made to wait, it is to serve you better, and to please to you"

많은 것을 시사하는 경구입니다. 불확실성을 가지고 시작하는 것들이 좋은 결과를 가져오기 위해서는 시간이 필요하다는 의미와 좋은 품질을 기대하려면 역시 시간이 걸린다는 의미로 해석됩니다. 시간이 소프트웨어 개발에 어떤 의미를 가지는지 짚어보고, 왜 많은 소프트웨어 개발이 일정과 품질 측면에서 실패로 낙인 찍히는지에 대한 고찰입니다.

 

브룩스는 소프트웨어 개발이 실패하는 이유에 대해 다섯 가지 이유를 주요 원인으로 꼽을 수 있습니다. 첫 번째는 어렵고 부족한 견적 기술 때문이라고 주장합니다.(여전히 타당한 명제) 두 번째는 견적 방식에서 노동력과 작업 진행의 상관관계를 혼동하여 인력과 작업 기간이 상호 교환 가능한 관계라는 가정에 바탕을 두고 있습니다. 세 번째는 견적 수치에 대한 확신이 없기 때문에 업무 진행의 확신을 가지지 못합니다. 네 번째는 진행상황이 제대로 관리, 모니터링되지 못합니다. 마지막으로 일정 지연에 대해 대부분 그저 인력을 더 투입하는 것으로 대응합니다.

 

2020년 현재 SI사업에서 일어나는 일에 위의 다섯 가지 원인을 대입하여도 전혀 이상하지 않습니다. 다만 기능점수(Function Point) 기반의 데이터들이 축적된 특정 업무 도메인에서는 개발규모의 추정에 대한 불확실성이 어느 정도는 해소되었거나 추정의 정확성이 높아지고 있다고 이해됩니다.

 

그러나 SI 개발현장에서는 여전히 브룩스의 다섯 가지 일정 지연 원인에 대해 흔하게 들을 수 있는 상황입니다. 책에서 언급한 개발자들의 낙관주의 역시 개발현장에서 심심치 않게 만나볼 수 있습니다. "이번엔 확실히 작동합니다." 또는 "마지막 Bug, Defect까지 다 해결되었습니다." 그러나 소프트웨어는 여전히 다른 결함들로 오작동합니다.

 

도로시 세이어스(Dorothy Sayers)는 그녀의 책, 장인의 생각(The Mind of the Maker)에서 창작활동을 세 가지 단계로 구분합니다. 아이디어(개념), 구현, 상호작용의 3 가지 단계로 구분하면서 인간이 만드는 사물들의 불완전함과 모순은 구현 과정에 들어가서야 비로소 뚜렷하게 드러난다고 합니다.

 

다시 말하면, 개념 또는 아이디어는 그 자체로서 불완전성(Incompletenesses)과 불일치성(Inconsistencies)을 내포하고 있고, 설계와 구현의 구체화 단계를 거치면서 비로소 명확한 모습을 드러낸다는 의미로 해석하면 될 것 같습니다. 소프트웨어가 가지는 자연적인 특성 자체가 '개념의 구체화'라는 본질적인 불확실성을 내포하기 때문에 도로시 세이어스의 이론에 대비해 '구체화된 상품 또는 서비스로서의 소프트웨어의 모양'이라는 것이 초기단계에서는 얼마나 추정하기 어렵고 불확실한 것인지 다시 한번 상기시켜 줍니다.

 

브룩스는 개발 공수의 추정에 사용되는 전제 중, 견적과 일정에 사용되는 노력의 단위 즉 Man-Month가 상호 교환 가능하다는 전제가 매우 잘못된 사고방식임을 매우 일관되게 비판하고 있습니다. "Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth." 인력과 기간은 상호 커뮤니케이션이 필요하지 않은 작업자들에게 임무가 분할될 때에만 상호 교환 가능한 상품이라고 주장합니다. 예를 들면 목화의 수확이나 벼의 수확 등에 인력을 동원할 경우가 해당합니다.

 

이런 사고를 전제로 브룩스는 다음과 같이 Man-Month의 상호 교환 메커니즘을 비판합니다. 원문이 더욱 이해가 와 닿기 때문에 원서에 있는 문장을 그대로 옮겨 보겠습니다. 'Since software construction is inherently a systems effort - an exercise in complex interrelationships - communication effort is great, and it quickly dominates the decrease in individual task time brought about by partitioning. Adding more men then lengthens, not shortens, the schedule.'

 

 

브룩스의 법칙 (그림출처: by    Dave Nicolette  ·  Mar. 11, 18 · Agile Zone · Analysis)

매우 큰 재난급의 위험이 오히려 작은 일정 지연보다 다루기가 쉽다고 합니다. 사실 큰 재난은 대대적인 추진력, 근본문제에 대한 인식, 새로운 접근 방법 등으로 대체가 가능하다고 예상합니다. 그러나 일정은 조금씩이지만 어느 순간 돌이킬 수 없게 늦어져 버립니다. 브룩스는 큰 문제의 경우 팀 전체 또는 회사 전체가 나서서 문제에 당면했을 당시에 바로 맞서 나가면 어느 정도 해결 가능하지만, 매일 조금씩 늦어지는 것은 인지하기도 어렵고, 사전에 방지하기도 그리고 만회하기도 어렵다고 말하고 있습니다.

 

요즘 현장에서 마주하는 가장 큰 이슈도 역시 수면 위에 나타나지 않은, 축적된 작은 문제들의 총합으로 인해 발생하는 일정 지연인 경우가 많습니다. 이 문제는 별도의 주제로 다룰 수 있도록 하겠습니다.

 

# Aristocracy, Democracy and System Design

브룩스는 소프트웨어의 개념적 무결성을 어디까지 희생해야 하는지에 대해서도 일관된 주장을 펼치고 있습니다. 효율성과 개념적 무결성을 원한다면 똑똑한 인원 몇 명만으로 설계와 개발이 되어야 할 것이지만, 대형 시스템의 경우 충분한 인력을 투입하여 제품을 적절한 시기에 세상에 선보여야 하고 일관성과 통합성을 조화시켜야 한다고 주장합니다.

 

현대적 어플리케이션의 경우 다양한 기술의 조합과 Polyglot을 가능하게 하는 요소들로 인해 일관성과 통합성에 대해 새로운 접근의 필요성이 대두되었습니다. Cloud Native로 대변되는 어플리케이션 현대화는, 특히 마이크로서비스 아키텍처 기반의 어플리케이션 설계/개발과 운영에 이르는 프로세스와 도구, 방법론에 이르는 총체적 'RETHINK'를 필요로 합니다.

 

건축물의 설계자는 예산에 기초해서 작업해야 합니다. 그리고 건축가가 사용한 기술은 결국 나중에 하도급업자에 의하여 실제 건축현장에서 확인되고 수정되고는 합니다.(본문 중에서) 그러나 어플리케이션 현대화라는 관점에서 보면 클라우드 네이티브 환경과 마이크로서비스 아키텍처 기반의 개발방식은 다양한 건축가가 본인이 원하는 기술로 디자인한다는 의미와 일치할 수 있습니다. 통합성, 일관성, 효율성에 대해 새로운 접근을 필요로 하는 이유입니다.

 

# Estimation

추정에 대한 많은 이야기들이 초기 개발단계의 불확실성을 전제로 하고 있습니다. 그리고 소프트웨어의 설계변경은(특히 대형 시스템으로 갈수록) 피하기 어려운 필연적 현상으로 간주하고 있습니다. 그래서 브룩스는 "The Only Constancy is Change Itself."라고 언급하면서 변화를 당연한 것으로 인정하라고 주장합니다.

 

책에서 전달하고자 하는 핵심은 개발자는 손으로 만질 수 있는 제품이 아니라, 사용자의 필요에 부응하는 만족을 전달하는 것이라고 강조합니다. 그리고 실제 요구사항과 그 요구사항에 대한 사용자의 관점은 프로그램이 구축되고, 시험되고, 사용되는 과정을 거치면서 변화할 수밖에 없다는 것입니다. 즉 개발과정에서 요구사항이 변화할 개연성이 크다는 것을 전제로 하라는 의미로 받아들여집니다.

 

그러나 이러한 변화 또는 변경에 대해서 의무적으로 받아들이자는 논리가 아니고 제약과 지침을 통하여 '불가피하게 수용해야 하는 작업을 구별해내고 이것에 초점을 맞추자'라는 것이 논지의 핵심입니다. 결국 시스템의 변경에 대비할 수 있는 계약과 위험관리체계가 얼마나 중요한 지를 언급하는 것이라 볼 수 있습니다.

 

# Maintenance

일반적으로 널리 쓰이는 프로그램의 경우, 유지관리 총비용은 대개 개발비용의 40% 또는 그 이상에 이른다고 합니다.(현대적 SW 경우 일부는 맞고 일부는 틀린 것 같습니다.) 그리고 이 비용은 사용자의 숫자에 영향을 받지 않는다고 주장합니다. 왜냐하면 사용자가 많을수록 오류도 그만큼 많아지기 때문입니다.

 

대부분의 개선작업은 시간이 경과하면서 전체 시스템의 구조를 무너뜨려 시스템의 무질서와 혼란을 가중시킬 위험이 크다고 합니다. 원래 내재된 설계 결함을 개선하는 데는 노력을 기울이기 점점 어렵게 되고 시스템의 상태는 더 나빠집니다. 소프트웨어를 탑재한 하드웨어 장비들은 변하고, 설정도 달라지고, 사용자 요구사항도 변하여 시스템은 특정 시점의 미래에 더 이상 사용이 어려운 상황이 도래합니다. 새로운 설계가 필요한 시점이라고 할 수 있습니다.

 

# Waterfall

제임스 브룩스는 그 당시 뿐만 아니라 그 후로도 오랫동안 소프트웨어 개발 방법론으로 득세하고 있는 폭포수 방식에 대해 비판적인 논지를 펼치고 있습니다.

 

그는 폭포수 방식의 근본적인 오류로서 프로젝트가 각 과정을 한 번만 거친다고 가정하는 점을 강조하고 있습니다. 즉 아키텍처는 훌륭하고 사용하기 쉽고, 구현 설계는 안정적이며 완벽하고, 테스트가 진행됨에 따라 실현 과정에서 문제점을 고쳐나갈 수 있다는 가정 자체가 오류라는 것입니다. 이를 달리 표현하면 폭포수 기반 개발방식의 모든 오류나 문제점들은 그것을 구현하는 과정에서 분명히 존재할 것이라고 가정하지만, 컴포넌트 테스트와 시스템 테스트를 거치는 과정에서 대부분의 오류나 문제점들을 바로잡을 수 있을 것이란 결론을 바탕에 깔고 있는 것입니다.

 

각 단계별로 발생할 수 있는 오류들의 개선 가능성을 너무 높게 보는 것 자체가 잘못된 것이라는 지적과 함께 개발 초기에 완벽한 설계가 가능할 것이라고 예측하는 것도 폭포수 방식의 치명적인 결함이라고 비판합니다. 그는 당시에 나선형 방법론(점증적, 반복적 개발방식)등에 간단히 언급하고 있지만, 폭포수 방식의 대안으로써 명확한 무엇인가를 제시하고 있지는 않습니다.

 

# Epilogue

책에서 언급한 내용 중 훌륭한 야구선수의 덕목에 대해 언급한 부분이 마음에 와 닿습니다. 내용은 다음과 같습니다. "어떤 야구 감독은 훌륭한 선수와 훌륭한 팀의 덕목으로 비물리적 재능인 감투정신(Hustle)을 꼽는다. 이것은 훌륭한 개발팀이 되는 데에도 필수적이다. 감투정신은 완충과 여분의 능력으로 일상적인 사고에 대비하여 작은 재난을 예측하고 방지할 수 있게 해 준다."

 

개발기술의 발달과 소프트웨어가 처리하는 업무의 복잡도/난이도가 급속하게 발전하면서 기존 소프트웨어 개발인력들이 보유한 Technical Skill Set도 매우 빈번하게 재정의 되어야 하는 시대가 되었습니다. 그리고 이에 따른 회색지대가 항상 생겨나고 있습니다. 개발팀의 입장에서 모든 구성원들이 Hustle Player가 되기를 바랄 수는 없겠지만 구성원들의 감투정신으로 메워줘야 할 부분들이 너무 많이 생겨나는 것이 현실입니다.

 

소프트웨어 개발에서 은 총알(Silver Bullet)은 없지만, 점점 발전하고 있는 개발을 지원하는 도구들(자동화된 Code Generation Tool 등), 테스팅 도구, 위험관리도구 등과 함께 현대적 관리기법들은 소프트웨어 개발의 불확실성을 조금씩 제거해 나가고 있습니다. 물론 다양한 도메인 영역에서의 경험 기반 축적도 이런 불확실성 제거에 도움을 주고 있습니다.

 

애자일 또는 폭포수 방식의 양자택일 관점이 아니라, 소프트웨어 개발의 불확실성을 전제로 했을 때 어떻게 접근하는 것이 일관성, 통합성, 효율성을 확보할 수 있을 것인가라는 문제의식에서 출발하는 것이 바람직할 것으로 생각됩니다. 같은 기능을 하는 소프트웨어 개발을 전제로 했을 때 조차도 고객 환경의 상이함, 커뮤니케이션 방식, 아키텍처에 대한 선호도, 기술 스택에 대한 선호도, 요청사항의 구체성 등 달라지는 것이 매우 많습니다.

 

불확실성이 전제된 개발임을 팀구성원 전체가 인지하고, 불확실성을 구체화시키는 작업으로서 소프트웨어 개발에 동의한다면, 애자일을 사용하든 폭포수를 사용하든 상관없이 방법론 자체가 가지고 있는 부족한 부분을 어떻게 보완할 수 있을 것인지에 대해 초점을 맞추는 것이 더 바람직한 접근이라고 생각합니다.