병목

제품이 늦게 나온다는 말은 오래전부터 있었지만 어디가 늦은지를 가리키는 말은 없었습니다. 그래서 대응도 늘 같았습니다. 전원이 더 빨리 움직이자는 것이었습니다. 개발자는 야근을 하고 디자이너는 시안을 줄였는데, 기능 하나가 나가기까지 걸리는 시간은 그대로였습니다.

주간 회의에서 "왜 이번 주도 세 건밖에 못 나갔죠" 라는 질문이 나오면 개발자는 "제 몫은 화요일에 다 끝냈습니다" 라고 답하고, 디자이너는 "시안은 월요일에 넘겼어요" 라고 답합니다. 각자 자기 구간에서는 아무도 늦지 않았는데 밖으로 나간 결과물은 세 건입니다. 아무도 거짓말을 하지 않았고, 아무도 어디를 봐야 하는지 몰랐습니다.

병목은 그 자리에 이름을 붙인 말입니다. 모두를 고르게 몰아붙이는 대신 가장 느린 한 곳을 찾아 거기만 손보자는 발상입니다. 흐름을 눈에 보이게 그려 두고 진행 중 작업을 제한하는 칸반이 퍼지면서 함께 쓰이게 됐습니다. 단계별로 그려 두지 않으면 어디가 가장 느린지 잴 방법이 없기 때문입니다.

한 흐름이 밖으로 내보내는 양은 가장 느린 구간이 내보내는 양과 같습니다. 그 앞뒤가 아무리 빨라도 그렇습니다.

기능 하나는 기획 · 디자인 · 개발 · 코드 리뷰 · 검수를 거쳐 나갑니다. 코드 리뷰는 변경을 합치기 전에 동료가 코드를 읽어 보는 절차입니다. 한 주에 처리할 수 있는 건수가 기획은 여덟, 디자인은 여섯, 개발은 다섯인데 리뷰는 둘이라면, 그 주에 밖으로 나가는 기능은 둘입니다. 앞의 세 단계가 만든 여유분은 리뷰 앞에 줄을 설 뿐입니다. 병의 몸통이 넓어도 물이 나오는 속도는 좁은 목이 정합니다. 이름도 거기서 왔습니다.

병목이 있는 흐름에는 세 가지가 같이 나타납니다.

1. 그 구간 앞에 대기가 쌓입니다. 작업 한 건을 카드 한 장으로 두고 상태별 칸에 늘어놓은 칸반 보드에서 리뷰 대기 칸만 아홉 장까지 불어납니다.
2. 그 구간 뒤는 한가합니다. 검수를 맡은 사람은 올라오는 게 없어 다른 팀 일을 돕습니다.
3. 다른 구간을 빠르게 해도 전체가 그대로입니다. 개발자를 둘 더 붙여 개발 능력을 여덟으로 올려도 나가는 기능은 여전히 둘입니다.

어디가 병목인지는 감이 아니라 두 가지로 확인합니다. 하나는 시간 차이입니다. 요청이 들어온 순간부터 재는 리드 타임이 9일인데 실제로 손을 대기 시작한 뒤부터 재는 사이클 타임이 이틀이라면 이레는 줄에 서 있었던 것입니다. 9일 중 작업한 이틀의 비율이 흐름 효율입니다. 다른 하나는 상태별 카드 수를 시간축에 쌓아 그린 누적 흐름도입니다. 어느 칸의 띠가 날마다 두꺼워지면 그 칸은 들어오는 양이 나가는 양보다 많다는 뜻입니다.

병목은 한자리에 머물지 않습니다. 리뷰가 한 주에 여섯 건을 처리하게 되면 이제 개발이 가장 느린 구간이 되고 전체 속도는 다섯에 맞춰집니다. 한 번 고치고 끝나는 일이 아닙니다.

여러 단계를 거쳐 무언가가 나가는 흐름이면 어디에나 씁니다. 개발 과정에서만 쓰는 말이 아닙니다.

채용에서는 서류를 한 주에 마흔 건 검토해도 면접 일정이 한 주에 여섯 건밖에 안 나오면 한 달에 만나는 후보가 스물넷에서 멈춥니다. 지원자를 더 모아도 합격자 수는 늘지 않습니다. 영업에서도 상담 요청이 하루 서른 건인데 계약서 검토를 한 명이 맡고 있으면 계약 속도는 그 한 명에게 맞춰집니다.

찾은 병목을 손보는 방법은 크게 셋입니다.

1. 그 구간의 처리 능력을 올립니다. 사람을 더 붙이거나, 손으로 하던 것을 자동으로 돌리거나, 한 사람이 도맡던 일을 나눕니다.
2. 그 구간으로 들어가는 양을 줄입니다. 한 칸에 동시에 올려 둘 수 있는 카드 수의 상한인 WIP 제한을 앞 칸에 겁니다. 앞 칸이 세 장을 넘기지 못하면 손이 빈 사람은 새 일 대신 밀린 리뷰를 돕게 됩니다.
3. 그 구간을 거치지 않아도 되게 만듭니다. 문구 한 줄 고치는 변경까지 전체 리뷰를 받는다면, 위험이 낮은 변경은 리뷰를 건너뛰도록 규칙을 바꿉니다.

1번이 제일 먼저 떠오르지만 대개 제일 비쌉니다. 2번과 3번은 사람을 늘리지 않고 그 주에 바로 해 볼 수 있습니다.

"지금 병목은 코드 리뷰예요. 개발자를 더 뽑아도 이번 분기에 나가는 기능 수는 그대로일 겁니다."

사람을 늘릴 곳이 개발이 아니라 리뷰라는 말입니다.

"이번 주는 디자인이 병목이라 개발 카드를 더 당기지 맙시다."

앞 구간에서 일을 더 꺼내 봐야 뒤에 줄만 길어진다는 뜻입니다.

"리뷰어를 늘렸더니 병목이 검수로 넘어갔어요."

앞의 병목은 풀렸고 이제 다음으로 느린 구간이 전체 속도를 정한다는 보고입니다.

페이지덱에서는 코드 리뷰를 태오가 거의 혼자 맡고 있었습니다. 개발자 다섯이 올린 변경이 전부 태오에게 모였고, 태오는 자기 개발 일정을 지키면서 하루 두 건쯤을 봤습니다. 주간 회의에서 지현이 누적 흐름도를 띄우자 리뷰 대기 띠만 3주째 두꺼워지고 있었습니다.

민서가 시안은 늘 화요일에 넘긴다고 하던 이유도 그 그래프에 있었습니다. 그 자리에서 리뷰를 볼 사람을 두 명 더 두고 개발 중 칸의 상한을 셋으로 내렸습니다. 상한을 내리자 손이 빈 개발자가 새 기능을 여는 대신 밀린 리뷰부터 보게 됐고, 3주 뒤 리뷰 대기 띠는 얇아졌습니다. 대신 검수 칸의 띠가 두꺼워지기 시작했습니다. 병목이 다음 구간으로 옮겨 간 것입니다.

병목을 사람 탓으로 읽는 경우가 가장 많습니다. 늦어지는 자리를 짚을 때마다 같은 이름이 나오니 그 사람이 느린 것처럼 보입니다. 실제로는 일이 그 자리로만 모이도록 흐름이 짜여 있는 것이고, 그 사람을 더 빠른 사람으로 바꿔도 다음 달에 같은 자리가 다시 막힙니다. 이대로 두면 지목당한 사람은 지쳐서 떠나고 흐름은 그대로 남습니다.

모든 구간이 쉬지 않고 돌아가야 좋다고 보는 것도 흔합니다. 누군가 손이 비어 있으면 낭비처럼 보이니 일을 더 꺼내 채우게 됩니다. 하지만 병목이 아닌 구간까지 꽉 채우면 결과물이 더 나가는 게 아니라 병목 앞의 줄만 길어집니다. 한 주에 나가는 건수, 곧 처리량은 그대로인데 한 건이 걸리는 시간만 늘어납니다.