브룩스의 법칙

일정이 밀렸다는 보고가 올라오면 가장 먼저 나오는 제안은 거의 정해져 있습니다. 사람을 더 붙이자는 것입니다. 남은 일의 양을 사람 수로 나누면 필요한 기간이 나온다는 계산이 머릿속에 먼저 서기 때문입니다. 두 사람이 넉 달 걸릴 일이라면 네 사람이면 두 달일 것 같습니다.

이 계산을 대규모로 시험해 본 사례가 1960년대 IBM의 운영체제 개발 프로젝트였습니다. 일정이 밀리자 인원을 대거 투입했는데 일정은 더 밀렸습니다. 당시 이 프로젝트를 이끈 프레더릭 브룩스는 1975년에 그 경험을 정리한 책을 내면서, 사람과 기간을 맞바꿀 수 있다고 보는 사고방식 자체가 잘못됐다고 적었습니다. 사람 하나가 한 달 일한 양을 뜻하는 단위를 예산 계산에 쓰다 보니, 그 단위를 반대 방향으로도 쓸 수 있다고 착각하게 된다는 지적이었습니다.

그 전까지 이 현상은 개별 팀의 사정으로만 이야기됐습니다. 인원을 늘렸는데 더 늦어지면 새로 온 사람의 실력이 문제였거나 관리가 허술했던 것으로 정리됐습니다. 브룩스의 법칙은 그 결과가 특정 팀의 사정이 아니라 구조에서 나온다고 못 박았습니다. 잘 뽑고 잘 관리해도 늦어진 프로젝트에 인원을 더하면 그 시점부터 한동안은 더 늦어집니다.

인원이 늘면 일하는 손도 늘지만 동시에 세 가지 비용이 같이 늘고, 늦어진 프로젝트에서는 뒤쪽이 앞쪽보다 큽니다.

1. 가르치는 시간이 듭니다. 새로 온 사람이 제 몫을 하기까지 걸리는 램프업 기간 동안 누군가는 코드 구조와 배포 절차와 지난 결정의 이유를 설명해야 합니다. 그 설명을 할 수 있는 사람은 지금 가장 바쁜 사람입니다. 결과적으로 한 명이 늘어난 첫 몇 주 동안 팀의 산출은 오히려 줄어듭니다.
2. 소통 경로가 제곱으로 늘어납니다. 세 명이 일하면 서로 맞춰야 할 짝은 세 쌍이지만 여덟 명이 되면 스물여덟 쌍이 됩니다. 사람은 두 배 반 늘었는데 맞춰야 할 자리는 아홉 배가 넘습니다. 회의 시간이 늘고, 같은 결정을 두 번 설명하게 되고, 두 사람이 같은 파일을 동시에 고쳐 놓는 일이 생깁니다.
3. 쪼갤 수 없는 일이 남습니다. 어떤 작업은 순서를 바꿀 수 없어서 사람을 더 붙여도 기간이 줄지 않습니다. 결제 모듈의 설계가 끝나야 그 위에 화면을 붙일 수 있다면, 설계 단계에 세 명을 더 넣어도 설계가 사흘 만에 끝나지는 않습니다. 아홉 명이 달라붙어도 아이 하나가 한 달 만에 태어나지는 않는 것과 같습니다.

세 비용은 프로젝트가 늦어진 상태일수록 커집니다. 여유가 있을 때라면 가르치는 시간을 감당할 사람이 있지만, 이미 밀린 팀에서는 가르칠 사람이 곧 마감을 쥔 사람입니다. 그래서 같은 인원 추가가 프로젝트 초기에는 도움이 되고 막바지에는 해가 됩니다.

이 말이 실제로 나오는 자리는 셋입니다.

1. 일정 압박이 걸린 회의입니다. 날짜는 못 바꾸고 할 일은 그대로일 때 인원 투입이 유일한 해법처럼 보이는데, 이 법칙을 아는 사람이 그 자리에서 다른 손잡이를 꺼냅니다. 대개 범위를 줄이는 쪽입니다. 이번에 낼 기능을 셋에서 둘로 줄이는 결정이 사람 둘을 더 넣는 것보다 빠릅니다.
2. 헤드카운트 계획을 짜는 자리입니다. 조직이 둘 수 있는 인원 수를 정할 때, 언제 뽑느냐가 몇 명 뽑느냐만큼 중요해집니다. 다음 분기 마감을 앞두고 합류하는 세 명은 그 분기에 도움이 되지 않습니다.
3. 반대 방향으로도 쓰입니다. 사람을 더 넣어도 되는 조건을 따질 때입니다. 조건은 셋인데, 프로젝트 초반이라 배울 시간이 남아 있거나, 떼어 놓아도 되는 독립된 작업이 있거나, 새로 온 사람이 기존 사람을 거치지 않고 일할 수 있는 경우입니다. 문서 작업이나 테스트 환경 정비처럼 본 줄기와 떨어진 일이 여기 해당합니다.

크런치, 곧 출시 직전에 장시간 몰아 일하는 기간에 인원을 더하는 결정이 특히 자주 나오는데, 그때가 세 비용이 모두 가장 큰 시점입니다.

"지금 두 명 더 넣는다고 이번 달 안에 못 끝냅니다. 브룩스의 법칙이에요."

인원 투입으로는 이번 마감을 못 맞춘다는 말이고, 대개 범위를 줄이자는 제안이 뒤따릅니다.

"다음 분기 인원은 지금 뽑아야 합니다. 마감 한 달 전에 합류하면 그 분기는 못 씁니다."

채용 시점을 앞당기자는 요청입니다.

"이 작업은 떼어 낼 수 있어서 사람을 더 붙여도 됩니다."

기존 코드와 얽히지 않아 브룩스의 법칙이 잘 적용되지 않는 예외라는 판단입니다.

페이지덱에서 이 말이 나온 것은 기업 고객용 권한 관리 기능을 만들던 스프린트 중간이었습니다. 계약 조건에 출시 날짜가 박혀 있었고 진행은 예상보다 한 주 늦어져 있었습니다. 다른 팀에서 개발자 두 명을 빌려 오자는 안이 나왔습니다.

태오가 반대한 이유는 실력이 아니었습니다. 권한 구조를 설명하는 데 이틀이 걸리고 그 이틀을 쓸 사람이 지금 가장 바쁜 자기 자신이라는 것이었습니다. 대신 이번에 낼 범위에서 감사 로그 화면을 빼고 다음 주기로 미루자고 제안했고, 그 결정으로 날짜를 맞췄습니다. 빌려 온 두 명은 다음 주기가 시작될 때 합류했습니다.

사람을 절대 더하면 안 된다는 금지로 읽는 경우가 가장 많습니다. 문장이 단정적이라 규칙처럼 들리기 때문입니다. 하지만 이 법칙이 말하는 범위는 이미 늦어진 프로젝트에 한정됩니다. 초반에 인원을 늘리는 것이나, 다음 분기를 보고 미리 뽑는 것은 여기 해당하지 않습니다. 금지로 읽어 버리면 채용을 계속 미루다가 정작 늦어진 뒤에 급히 뽑는 쪽으로 가게 되고, 그건 이 법칙이 말리는 바로 그 행동입니다.

도구가 좋아졌으니 이제는 옛날 이야기라고 넘기는 오해도 있습니다. 문서가 정리돼 있고 개발 환경을 하루면 갖출 수 있으니 예전만큼 오래 걸리지 않는다는 생각입니다. 실제로 환경 설정에 드는 시간은 크게 줄었습니다. 다만 세 비용 중 줄어든 것은 그 하나뿐입니다. 지난 결정의 이유를 아는 것과 팀 안에서 누구에게 무엇을 물어야 하는지를 아는 데 걸리는 시간은 그대로이고, 소통 경로가 제곱으로 늘어나는 것도 그대로입니다. 오히려 팀이 여러 곳에 흩어져 일하면 그 비용은 커집니다.