공수 산정 (5) 맨먼스는 왜 나눌 수 없는가 — 18.7명을 넣어도 안 되는 6가지 이유

어떤 외주 건의 개발 문서를 검토하면서 전체 소요를 산정했습니다. 나온 숫자는 약 56 맨먼스였습니다. 그리고 이 숫자를 문서에 적는 순간, 다음에 어떤 질문이 올지 이미 알 것 같다는 생각이 들었습니다.

그렇다면 56명이 한 달씩 넣으면 한 달에 끝나는 걸까요.

Brooks가 1975년에 답한 질문입니다. 『The Mythical Man-Month』는 소프트웨어 공학에서 가장 많이 인용되는 책 중 하나이고, 맨먼스 신화는 이제 상식에 가깝습니다. 다만 상식이라는 것이 실제 대화에서는 잘 작동하지 않습니다. "그건 맨먼스 신화입니다"라고 답하면 대화가 끝나지 않습니다. 상대 입장에서는 "그건 아는데, 그래서 몇 명이면 됩니까"가 당연한 다음 질문입니다.

원론을 인용하는 것으로는 이 질문이 닫히지 않습니다. 그래서 이번에는 구체적인 숫자로 답해 보기로 했습니다.

먼저 산술 — 90일에 넣으려면 몇 명인가

발주처가 규정한 기간은 90일이었습니다. 90일은 3개월이고, 영업일로 환산하면 61.5일입니다. 공표 임금 산정에서 쓰는 월 20.5일 규약을 그대로 적용한 값입니다. 여기에 하루 8시간을 곱하면 한 사람이 90일 동안 낼 수 있는 최대치가 나옵니다. 1인당 492 인시입니다.

총량은 9,216 인시로 산정했습니다. 나누면 답이 나옵니다.

9,216 인시 ÷ 492 인시/인 = 18.7명

발주처가 규정한 팀은 6개 역할 6명이었습니다. 18.7명은 그 3.1배입니다.

역할별로 쪼개면 그림이 조금 더 선명해집니다. 규정된 편성에서 각 역할이 실제로 몇 명이어야 하는지를 따로 계산해 봤습니다.

역할	규정 대비 필요 배수
아키텍트	1.1배
데이터	4.1배
프론트엔드	3.7배
도메인	3.5배
백엔드	3.4배
ML	2.9배

눈에 걸린 건 아키텍트였습니다. 6개 역할 중 "한 역할에 한 명"이라는 가정이 성립하는 건 아키텍트 하나뿐이고, 나머지 다섯은 전부 3~4배였습니다.

그런데 18.7명을 넣어도 안 됩니다

여기까지는 나눗셈입니다. 그리고 나눗셈이야말로 맨먼스 신화의 정확히 그 지점입니다. 18.7이라는 숫자를 내놓는 순간 "그럼 19명 붙이면 되겠네요"가 따라옵니다.

안 됩니다. 그런데 흥미로운 건, 왜 안 되는지에 대한 근거를 제가 만들 필요가 없었다는 점입니다. 발주처 문서는 꽤 정교했습니다. 기능마다 검증 가능한 수용 기준이 붙어 있고 선행 의존성이 표로 정리돼 있어서, 요구사항 문서로서는 상당히 잘 만든 축에 속했습니다. 그리고 애석하게도 그 정교함이 자기 일정을 반박하는 재료가 됐습니다.

① 단계를 병렬로 돌리는 것을 문서가 금지하고 있었습니다

문서 자신이 각 단계가 끝나는 시점에 게이트 기준 충족 여부로만 다음 단계 진입을 허가한다고 규정해 뒀습니다. 품질 관리 관점에서는 훌륭한 규정입니다. 다만 이 규정에는 산술적인 부작용이 하나 있습니다.

게이트로 단계를 끊으면 인시를 단계 간에 이월할 수 없습니다. 3단계에 여유가 있다고 해서 그 인시를 1단계로 당겨 쓸 수 없다는 뜻입니다. 그런데 "총량 ÷ 인원 = 기간"이라는 계산은 인시가 프로젝트 전 구간에서 자유롭게 흐른다고 가정할 때만 성립합니다. 즉 이 문서 아래에서는 총량을 인원으로 나누는 계산 자체가 성립하지 않습니다.

실제로 필요한 건 평균 19명이 아니라 단계별로 22명, 26명을 붙였다 뗐다 하는 편성입니다. 평균이라는 말이 숨기고 있던 것이 여기서 드러납니다.

② 문서가 임계경로를 스스로 지목했습니다

문서에는 임계경로가 어디인지, 그리고 왜 그것이 임계인지까지 정리돼 있었습니다. 문서 품질이 높다는 증거고, 검토하면서 감탄한 부분이기도 합니다.

그런데 임계경로는 정의상 인원을 늘려서 단축되지 않는 구간입니다. CPM에서 임계경로란 바로 그 성질로 정의되는 개념입니다. 그러니까 이 문서는 임계경로를 지목하는 순간, 인원 증원이 통하지 않는 구간이 존재한다는 것을 이미 인정한 셈입니다. 제가 발견해서 지적한 게 아니라 문서가 먼저 적어 뒀습니다.

③ 둘로 쪼갤 수 없는 노드가 첫 게이트를 넘지 못합니다

선행 의존성 표를 그래프로 옮기다가, 인증과 테넌시가 서로를 선행 의존성으로 참조하고 있는 것을 봤습니다. A가 B를 기다리고 B가 A를 기다리는 상호 참조 구조입니다.

CPM 표준에서 이런 구조는 두 개의 작업이 아니라 하나의 분할 불가 통합 작업 단위로 취급합니다. 순서를 정할 수 없으니 쪼갤 수 없고, 쪼갤 수 없으니 2명 이상을 나눠 투입하는 것 자체가 불가능합니다. 인원을 얼마로 잡든 이 노드의 소요는 그대로입니다.

그리고 이 노드 하나가 캘린더로 17.5일입니다. 문서가 규정한 첫 단계 상한은 14일이었습니다. 팀이 6명이든 19명이든 54명이든, 첫 게이트에서 이미 3.5일이 모자랍니다.

④ 첫 단계에 10명이 할 일이 없습니다

인원을 늘리려면 그 인원이 동시에 할 일이 있어야 합니다. 그런데 문서는 데이터 모델 확정과 아키텍처를 첫 단계의 산출물로 규정했습니다.

산출물이라는 건 그 단계가 끝나야 나온다는 뜻입니다. 즉 D0 시점에는 설계도가 없습니다. 설계도가 없는데 10명이 병렬로 짤 것이 없습니다. 병렬화의 전제 조건을 첫 단계가 아직 만들지 못한 상태라, 인원을 넣을 자리 자체가 존재하지 않습니다.

⑤ 사람을 넣으면 조율 채널이 제곱으로 늘어납니다

Brooks가 지적한 고전적인 항목입니다. 사람이 n명이면 서로 조율해야 하는 채널은 n(n−1)/2개가 됩니다. 인원은 선형으로 늘지만 채널은 제곱으로 늘어납니다.

인원	조율 채널	6명 대비
6명 (규정 편성)	15	기준
19명 (산술상 필요)	171	11배
54명	1,431	95배

인원이 3배가 되면 조율 비용은 11배가 됩니다. 여기서 더 밀어 넣어 54명이 되면 1,431개 채널, 95배입니다. 얻는 것은 선형이고 지불하는 것은 제곱이라, 어느 지점부터는 사람을 넣을수록 느려집니다.

⑥ 표준 모델이 90일을 추정 정의역 밖으로 규정합니다

앞의 다섯 개는 이 프로젝트의 사정입니다. 여섯 번째는 프로젝트와 무관한 공개 표준의 이야기라 성격이 조금 다릅니다.

COCOMO II에는 일정 압축을 다루는 파라미터(SCED)가 있습니다. 이 모델이 인정하는 최대 압축 한도는 25%입니다. nominal 개발기간의 75%가 모델의 바닥이고, 그 바닥에서조차 노력배수 1.43배를 부과합니다. 일정을 25% 당기면 총 노력이 43% 늘어난다는 뜻입니다.

이 규모의 nominal 개발기간은 14개월입니다. 여기에 0.75를 곱한 10.5개월이 COCOMO II가 인정하는 최단 일정입니다. 그런데 요구된 기간은 90일, 즉 3개월이고 이는 nominal의 21%입니다.

이 지점이 중요하다는 생각이 들었습니다. 21%는 75%보다 조금 낮은 정도가 아닙니다. 모델의 정의역 밖입니다. 90일은 공격적인 일정이 아니라 COCOMO II가 추정 자체를 거부하는 구간입니다. 모델이 "그건 어렵습니다"라고 답하는 게 아니라 "그건 제가 답할 수 있는 질문이 아닙니다"라고 답하는 자리입니다.

"물리적 대기를 배제하면?" — 배제해도 안 됩니다

여기서 나올 수 있는 반문이 하나 있습니다. 산정에 들어간 기간 중에는 외부 API 승인 심사나 데이터 파트너 계약처럼 우리가 일을 안 하고 기다리는 시간이 섞여 있습니다. 그러니 그 대기를 빼고 순수 개발만 보면 90일이 되지 않겠느냐는 반문입니다.

합리적인 반문입니다. 그리고 이 반문에 답하려면 두 가지를 구분해야 합니다.

• 물리적 대기 — 외부 API 승인 심사, 데이터 파트너 계약, 수용 기준 측정 창, 시계열 축적. 우리가 손을 놓고 기다리는 시간입니다.
• 작업 순서 의존 — 임계경로, 분할 불가 노드. 이건 기다림이 아니라 노동 자체의 성질입니다.

둘 다 겉보기에는 "시간이 걸린다"로 보이지만 성격이 완전히 다릅니다. 물리적 대기는 운이 좋으면 줄어들 여지가 있습니다. 심사가 빨리 나올 수도 있고 계약이 순조로울 수도 있습니다. 반면 작업 순서 의존은 운의 문제가 아닙니다. 설계가 끝나야 구현이 시작되는 것은 사정이 아니라 일의 구조입니다.

그래서 계산해 봤습니다. 물리적 대기를 전부 0으로 놓아도 — 심사가 즉시 나오고 계약이 당일 체결되고 측정 창이 없다고 가정해도 — 임계경로만으로 5.34개월입니다. 90일이 3개월이니 여전히 2배 가까이 됩니다.

그리고 이 숫자에는 곁들일 사실이 하나 있습니다. 법정 FP 산식으로 낸 캘린더가 5.43개월이었습니다. 임계경로는 발주처 문서의 의존성 표만 보고 그렸고, FP 산식은 공표 상수만 넣었습니다. 두 방법은 서로를 전혀 모릅니다. 그런데 5.34와 5.43에서 만났습니다. 이 정도 일치는 맞추려고 해서 나오는 게 아니라는 생각이 들었습니다.

인원과 무관하게 캘린더를 먹는 것들

맨먼스 논의는 대개 조율 비용과 학습 곡선에서 멈춥니다. 그런데 실무에서 더 자주 발목을 잡는 건 따로 있었습니다. 아예 인원이라는 변수가 들어가지 않는 항목들입니다.

가장 선명한 건 수용 기준의 측정 창입니다. 어떤 기능의 수용 기준이 "성공률 98%"라고 해 봅시다. 이걸 ±1% 정밀도로 입증하려면 수천 건의 연속 가동이 필요하고, 그건 시간이 흘러야 쌓입니다. 파이프라인을 10벌 복제하고 엔지니어를 10명 붙여도 시간이 흐르는 속도는 같습니다. 코딩이 끝나는 것과 수용 기준이 충족되는 것은 서로 다른 사건입니다.

더 극단적인 항목도 있었습니다. 어떤 기능의 수용 기준은 후행 성과와의 상관이었습니다. 예측을 내놓고, 그다음에 실제 결과가 나오고, 그제서야 둘 사이의 상관을 잽니다. 이 조건은 인원과도 예산과도 완전히 무관합니다. 오직 시간의 경과만이 이 조건을 충족시킵니다. 돈으로도 사람으로도 살 수 없는 종류의 항목입니다.

나머지 둘은 더 단순합니다.

• 외부 계약과 심사 — 상대방 조직의 법무 검토 큐는 우리 팀 규모와 아무 상관이 없습니다.
• 시계열 축적 — 3개월치 시계열은 3개월 뒤에 생깁니다. 여기엔 논쟁의 여지가 없습니다.

맨먼스는 자원이 아니라 총량입니다

결국 이 모든 것이 한 문장으로 모입니다. 맨먼스는 총 노동량이지 교환 가능한 자원이 아닙니다. 사람과 달을 곱해서 만든 단위지만, 곱셈이 성립한다고 해서 나눗셈이 성립하는 것은 아닙니다.

Brooks의 책 제목이 『The Mythical Man-Month』인 이유가 정확히 이것이라는 생각이 들었습니다. 신화적인 것은 "맨"이 아니라 "먼스"입니다. 사람과 달이 서로 교환 가능하다는 그 가정이 신화입니다.

그리고 50년이 지나도 여전히 유효한 비유가 있습니다.

아이 한 명이 태어나는 데 9개월이 걸린다고 해서, 산모를 9명 붙이면 1개월이 되지는 않습니다.

이 비유가 오래 살아남은 건 재미있어서가 아니라 정확해서였습니다. 임신은 분할 불가 노드이고, 산모 9명은 조율 채널 36개입니다.

가장 강력했던 건 제가 한 말이 아니었습니다

돌이켜 생각해보면, 이 계산에서 정말 남는 건 Brooks의 논지가 아닙니다. 그건 50년 된 상식이고, 상식은 대화를 닫지 못합니다. 남는 건 그 상식을 어떻게 꺼내 놓느냐였습니다.

위의 여섯 가지 중 넷은 제가 발견한 게 아닙니다. 단계 게이트 규정도, 임계경로 지목도, 상호 참조하는 의존성도, 첫 단계 산출물의 순서도 전부 발주처 문서에 이미 적혀 있었습니다. 제가 한 일은 흩어져 있던 조항들을 한자리에 모아 산술과 나란히 둔 것뿐입니다. 나머지 둘은 공개된 표준과 고전에서 왔습니다. n(n−1)/2도 COCOMO II의 SCED 파라미터도 제 것이 아닙니다.

그러니까 이 논증에는 제 의견이 한 줄도 없습니다. 그리고 그게 이 논증의 힘이었습니다. "당신 일정이 틀렸습니다"는 논쟁이 되지만, "당신 문서가 이 단계를 병렬로 돌리는 것을 금지하고 있습니다"는 논쟁이 되지 않습니다. 그건 반박이 아니라 확인입니다. 상대 문서가 스스로 규정한 제약으로 상대 일정을 반박하면, 반박할 대상이 제가 아니라 자기 자신이 됩니다.

다만 여기에는 뒷이야기가 있습니다. 이렇게 만든 문서는 확실히 반박하기 어려웠는데, 반박하기 어려운 것과 읽히는 것은 전혀 다른 문제였습니다. 그건 다음 편의 이야기입니다.