마감이 코앞인데 일이 한참 밀려 있으면 누구나 비슷한 생각을 합니다. 사람을 더 넣으면 일이 빨리 끝나지 않을까 하는 생각입니다. 이삿짐을 나르거나 밭을 갈 때처럼 손이 많을수록 일이 빨리 끝나는 경우가 분명히 있기 때문입니다.

그런데 소프트웨어 개발에서는 오히려 반대의 일이 자주 벌어집니다. 이미 늦어진 프로젝트에 사람을 더 넣으면 일정이 더 늦어진다는 것입니다. 이 경험칙은 처음 정리한 사람의 이름을 따서 ‘브룩스의 법칙(Brooks’s Law)’이라고 부릅니다.

본 자료에서는 브룩스의 법칙이 생겨난 배경과 맨먼스라는 단위에 숨은 착각, 사람을 더해도 빨라지지 않는 이유와 소통 경로가 늘어나는 셈법, 그리고 법칙을 피하는 방법과 한계까지 차근차근 정리합니다.

브룩스의 법칙의 원리와 활용

법칙의 탄생과 맨먼스의 착각

프레더릭 브룩스(Frederick P. Brooks Jr.)는 1960년대 미국 IBM에서 대형 컴퓨터 System/360과 그 운영체제 OS/360의 개발을 이끈 컴퓨터 과학자입니다. OS/360은 당시로서는 손꼽히게 큰 소프트웨어 프로젝트였고, 수많은 개발자가 투입되었지만 일정은 계속 밀렸습니다.

브룩스는 이때의 경험을 바탕으로 1975년 책 「맨먼스 미신(The Mythical Man-Month)」을 펴냈습니다. 이 책에서 그는 “늦어진 소프트웨어 프로젝트에 인력을 더하면 더 늦어진다(Adding manpower to a late software project makes it later)”라는 문장을 남겼고, 이 문장이 브룩스의 법칙으로 불리게 되었습니다.

맨먼스(Man-Month)는 한 사람이 한 달 동안 하는 일의 양을 뜻하는 단위입니다. 10맨먼스짜리 일이라면 한 사람이 열 달, 열 사람이 한 달에 끝낼 수 있다고 계산하는 식입니다. 브룩스는 이 계산이 서로 이야기할 필요 없이 일을 똑같이 나눌 수 있을 때만 맞으며, 사람과 달을 서로 바꿔 쓸 수 있다는 생각 자체가 착각이라고 지적했습니다.

이 책은 반세기가 지난 지금도 소프트웨어 공학의 고전으로 꼽힙니다. 1995년에 나온 20주년 기념판에는 생산성을 단번에 크게 끌어올리는 마법 같은 방법은 없다는 내용의 글 「은 탄환은 없다(No Silver Bullet)」도 함께 실렸습니다. 브룩스는 컴퓨터 구조와 소프트웨어 공학에 이바지한 공로로 1999년 튜링상(Turing Award)을 받았습니다.

사람을 더해도 빨라지지 않는 이유

늦어진 프로젝트에 새 사람을 넣으면 당장은 일손이 늘어난 것처럼 보입니다. 하지만 실제로는 다음과 같은 이유로 일정이 더 밀리기 쉽습니다.

(1) 익히는 데 시간이 든다
새로 온 사람은 프로젝트의 구조와 지금까지의 결정, 작업 방식을 익혀야 제 몫을 할 수 있습니다. 그동안 기존 사람들은 자기 일을 멈추고 새 사람을 가르쳐야 하므로, 처음 몇 주는 오히려 전체 속도가 떨어집니다.

(2) 나눌 수 없는 일이 있다
어떤 일은 아무리 사람을 늘려도 정해진 순서대로 거쳐야 합니다. 브룩스는 이를 “아기를 낳는 데는 아홉 달이 걸린다. 몇 명의 여성을 배정하든 마찬가지다”라는 말로 설명했습니다.

(3) 맞춰 보는 일이 늘어난다
일을 잘게 나눌수록 나눈 조각들을 다시 이어 붙이고, 서로 맞는지 확인하고, 생각을 맞추는 일이 늘어납니다. 사람이 많아질수록 이 조정에 드는 시간이 빠르게 커집니다.

이 세 가지가 겹치면 새 사람이 제 몫을 하기 시작하는 시점보다 기존 일정이 먼저 무너집니다. 그래서 늦어진 일을 사람 수로 메우려는 시도는 결과적으로 더 큰 지연을 낳는 경우가 많습니다.

소통 경로가 늘어나는 셈법

브룩스의 법칙을 가장 잘 보여 주는 것은 소통 경로의 수입니다. 팀원 모두가 서로 이야기를 나눠야 한다면, 사람 수를 n이라 할 때 소통 경로는 n(n-1)/2개가 됩니다. 사람 수는 하나씩 늘어나도 경로의 수는 그보다 훨씬 빠르게 늘어납니다.

• 3명인 팀(Team of 3): 소통 경로는 3개입니다.
• 5명인 팀(Team of 5): 소통 경로는 10개로 늘어납니다.
• 10명인 팀(Team of 10): 소통 경로는 45개가 됩니다.
• 20명인 팀(Team of 20): 소통 경로는 190개에 이릅니다.

사람이 두 배가 되면 경로는 네 배 가까이 늘어나는 셈입니다. 회의와 메시지, 확인 작업이 그만큼 늘어나고, 정작 프로그램을 만드는 데 쓸 시간은 줄어듭니다. 어느 순간부터는 사람을 더할수록 전체 생산성이 오히려 떨어지는 지점에 이르게 됩니다.

법칙을 피하는 방법과 한계

브룩스의 법칙은 사람을 늘리지 말라는 뜻이 아니라, 언제 어떻게 늘릴지 신중하게 정하라는 뜻에 가깝습니다. 실제 개발 현장에서는 다음과 같은 방법으로 이 함정을 피하려 합니다.

• 작은 팀(Small Team): 한 팀의 인원을 적게 유지해 소통 경로를 줄입니다. 아마존의 ‘피자 두 판 팀’ 원칙이 잘 알려진 예입니다.
• 모듈화(Modularity): 일을 서로 독립된 조각으로 나누고 조각 사이의 약속을 분명히 정해, 팀끼리 주고받을 이야기를 줄입니다.
• 일찍 늘리기(Early Staffing): 사람이 필요하다면 일정이 밀린 뒤가 아니라 프로젝트 초반에 넣어 익힐 시간을 확보합니다.
• 범위 조정(Scope Cut): 이미 늦었다면 사람을 더하기보다 기능을 줄이거나 일정을 다시 잡는 편이 나을 때가 많습니다.

다만 이 법칙에도 한계가 있습니다. 브룩스 스스로도 훗날 이 법칙이 지나치게 단순화한 말이라고 인정했습니다. 테스트나 문서 작성처럼 잘게 나누기 쉬운 일이나, 이미 프로젝트를 잘 아는 사람이 합류하는 경우에는 사람을 더해 실제로 빨라지기도 합니다. 협업 도구와 자동화가 발달한 오늘날에는 소통에 드는 수고가 예전보다 줄어든 만큼, 법칙이 얼마나 강하게 작용하는지는 팀과 일의 성격에 따라 달라집니다.

결국 브룩스의 법칙은 일의 속도가 사람 수만으로 정해지지 않는다는 사실을 일깨워 줍니다. 손을 더하기 전에 일이 어떻게 나뉘고 사람들이 어떻게 이어지는지를 먼저 살펴보는 것, 그것이 일정을 지키는 개발의 첫걸음입니다.