버그, 문서, 그리고 끝나지 않은 리더십의 과제

『The Mythical Man-Month』 마지막 몇 개 장(10, 13~15)은 개발 리더십, 버그와 테스트, 문서화에 대한 이야기입니다. 이 세 가지 주제는 책 전반에 걸쳐 반복적으로 등장하지만, 브룩스는 이 시점에서 '마지막으로 강조하고 싶은 것들'처럼 정리합니다.

놀랍게도, 이 주제들은 50년이 지난 지금도 우리 조직과 개발자들이 여전히 씨름하고 있는 문제입니다. 버그는 줄지 않고, 문서는 미뤄지고, 리더십은 종종 설계나 코드보다 더 풀기 어려운 이슈입니다.

버그는 어디서 오는가?

브룩스는 버그가 단순히 코드 실수 때문만은 아니라고 말합니다. 그의 핵심 주장은 이것입니다.

"버그의 대부분은 명세 부족 혹은 오해에서 비롯된다."

즉, '무엇을 만들지'가 명확하지 않거나, 팀원 간 이해가 엇갈리는 상황에서 개발을 시작하면, 코드가 맞더라도 결과는 틀릴 수밖에 없다는 것입니다.

오늘날에도 이 문제는 자주 일어납니다.

PO나 기획자가 말한 내용이 명확하지 않음

개발자가 기능을 구현한 뒤 리뷰 단계에서 "이게 아니었네"가 나옴

요구사항이 구현 도중 바뀌었지만 커뮤니케이션이 늦음

브룩스는 이를 방지하기 위한 방법으로 사양서(specification)의 중요성을 강조합니다.

그는 테스트보다 명세가 먼저이며, 테스트는 명세가 잘 되었을 때 비로소 유효하다고 말합니다.

이는 현대 소프트웨어에서도 마찬가지입니다. 우리가 TDD(Test Driven Development)를 이야기할 때, 핵심은 테스트 코드 자체보다 '기대 동작을 먼저 정의하라'는 철학이니까요.

테스트보다 더 중요한 건 리더십이다

브룩스는 테스트와 디버깅의 어려움도 지적합니다. 특히 다음과 같은 통찰이 인상적입니다:

“디버깅은 선형 수렴이 아니라, 점점 더 어려워지는 수렴이다.”

즉, 대부분의 버그는 개발 초기보다 마지막 10%에서 집중적으로 발생하며,

그 10%가 전체 일정의 50%를 차지하는 경우가 많다는 것입니다.

실제로도 배포 직전의 버그는 원인 파악도 어렵고, 수정도 부담스럽습니다.

이때 중요한 건 기술보다 리더십입니다.

마지막 10%의 문제를 끝까지 밀어붙이는 집중력

팀의 피로감 속에서도 품질 기준을 지키려는 의지

일정 압박 속에서도 수정보다 원인 파악을 우선하는 태도

이런 요소들이 결국 '신뢰할 수 있는 제품'을 만들어냅니다.

브룩스는 이런 태도를 단순히 개발자의 책임이 아니라, 리더의 책임으로 봅니다.

문서화는 죽지 않았다

브룩스는 70년대 중후반의 소프트웨어 프로젝트가 겪었던 실패 사례에서 "문서화의 부재"를 반복해서 지적합니다. 그는 이렇게 말합니다.

“구현은 계속되었지만, 시스템을 설명하는 문서는 없었다. 결국 유지보수도, 확장도 할 수 없었다.”

1980~90년대에는 워터폴 개발 모델이 유행하면서, 과도할 정도로 문서화가 강조되었습니다.

이후 애자일 문화가 확산되면서, "작동하는 소프트웨어가 최고의 문서"라는 주장과 함께 문서화는 경시되는 경향을 보였죠.

하지만 최근에는 이 흐름이 다시 바뀌고 있습니다. 다음과 같은 이유에서입니다.

시스템이 복잡해지고, 온보딩이 어려워짐

리모트 협업에서 문서가 사실상 유일한 정보 공유 수단이 됨

팀 간 경계가 많아질수록 '명시적인 기록'의 중요성이 커짐

지금의 문서는 예전처럼 두꺼운 PDF가 아니라, 다음과 같은 형태를 띱니다.

Notion, Confluence로 작성된 실시간 문서

API 명세서 (OpenAPI, Swagger 등)

README, ADR, Runbook 같은 운영 중심 문서

결국 중요한 건 형식이 아니라, 공유와 갱신이 일어나는가입니다.

리더십은 기술이 아니라 습관이다

브룩스는 책 후반부에서 기술적 통찰을 넘어서, 개발 리더십에 대해 이야기합니다.

특히 인상 깊은 문장은 이것입니다.

“훌륭한 리더는 정답을 아는 사람이 아니라, 팀이 정답을 찾도록 이끄는 사람이다.”

이는 50년 전에도, 지금도 동일한 진실입니다.

'코드 리뷰를 어떻게 할 것인가,

일정 압박 속에서 품질 기준을 어떻게 지킬 것인가,

피드백을 어떻게 줄 것인가'

이 모든 것이 결국 리더십의 문제입니다.

특히 기술 중심 조직에서는 다음과 같은 '숨은 리더십'이 더 중요합니다.

기술 부채를 계속 짚어주는 사람

불편한 의견을 용기 있게 꺼내는 사람

팀 분위기 속에서도 기술적 엄격함을 지키는 사람

이런 태도는 설계나 문서화, 테스트 등 눈에 잘 보이지 않는 부분에서 드러납니다.

그리고 그것이 프로젝트의 완성도를 좌우합니다.

마치며: 브룩스는 아직 끝나지 않았다

『The Mythical Man-Month』는 단지 과거의 통찰을 담은 책이 아닙니다.

이 책은 우리가 반복하는 실수를 정직하게 마주하게 만드는 '거울' 같은 책입니다.

버그, 문서, 리더십... 모두 수십 년이 흘렀지만 여전히 개발 현장에서 반복되고 있는 주제들입니다.

기술은 진보했지만, 사람과 팀, 조직의 본질은 크게 달라지지 않았기 때문입니다.

이 시리즈의 마지막 문장은, 브룩스의 메시지를 다시 떠올리며 마무리하고자 합니다.

“위대한 소프트웨어는 훌륭한 사람들과 훌륭한 협업에서 나온다.”

기술은 도구일 뿐입니다. 결국 문제를 해결하는 건, 사람입니다.