일이 막히는 곳에는 병목이 있다
병목은 느린 사람이 아니라 좁은 구조에서 시작된다
프로젝트의 흐름은 일정 시점까지는 순조롭게 진행되다가, 특정 단계를 지나며 급격히 속도가 떨어지는 경우가 자주 발생합니다.
이럴 때 대부분의 팀은 개인의 의지나 역량 문제에서 원인을 찾는 경향이 있습니다.
하지만 실제 원인은 다르게 봐야 합니다.
업무 흐름 속에 협업이 몰리는 지점이나 의사결정이 한 사람에게 집중된 구간이 구조적으로 존재하기 때문입니다.
이처럼 작업이 정체되거나 속도가 느려지는 구간을 우리는 '병목'이라고 부릅니다.
병목은 느린 사람이 아니라 좁은 구조에서 시작된다
병목이란 전체 시스템의 흐름을 결정짓는 가장 느린 구간입니다.
물리적 시스템에서는 파이프의 가장 좁은 지름이 전체 유속을 제한하듯, 일의 흐름도 마찬가지입니다.
그런데 많은 팀에서는 병목을 사람에게서 찾습니다.
"그 사람이 느려서 그렇다"는 식으로.
하지만 진짜 원인은 대개 구조입니다.
정보가 한 곳으로만 몰리거나, 승인 권한이 특정인에게만 집중되거나, 협업 과정이 특정 단계를 중심으로만 돌아가는 구조.
주변에서 흔히 보이는 구조입니다.
이런 구조를 가진 조직을 지켜봤을 때 어땠나요?
대체로 일이 답답하게 흘러가지 않았나요?
직원 개개인을 살펴보면 멀쩡한데도 말이죠.
일의 속도는 의지가 아니라 구조에 의해 조절됩니다.
그리고 언제나 병목은 처음엔 아무도 눈치채지 못할 정도로 작고 조용하게 시작됩니다.
서류 하나, 회의 일정 하나, 응답 한 번의 지연이 쌓여 어느 순간 전체 리듬을 늦추고 있다는 걸 깨달았을 때는 이미 늦은 경우가 많습니다.
병목 하나가 전체를 지연시킵니다
병목 루프 예시:
[병목 발생] → [대기 시간 증가] → [전체 일정 밀림] → [압박 증가] → [품질 저하]
병목이 발생하고 시간이 지연되면 이런 루프도 발생합니다.
[병목 발생] → 시간 지연 → [책임 회피] → [병목 방치] → 반복
가장 느린 구간이 전체 프로젝트의 마감일을 정합니다. 아무리 나머지가 빨라도 병목은 시스템 전체의 속도를 정지시키는 지점이 됩니다.
이때 병목을 단순한 '사람 문제'로 다루면, 문제는 반복됩니다.
왜냐면 병목은 흐름의 어긋남에서 생기기 때문입니다.
시스템은 자연히 병목을 만든다
시간이 흐를수록 시스템은 정교해지기보다 무질서와 편중으로 기울게 됩니다.
처음엔 유연하게 분산되던 역할도 어느 순간 특정한 사람이나 팀에 집중됩니다.
잘한다는 이유로, 혹은 익숙하다는 이유로, 그 사람에게 일이 몰립니다.
그러다 보면 병목이 생기고, 병목은 피드백을 늦추고, 피드백 지연은 실수를 불러오고, 결국 팀 전체의 리듬이 어긋납니다.
병목은 구조의 피로가 쌓인 자리입니다.
고치지 않으면, 점점 더 느려집니다.
그리고 그 피로는 사람에게 전가됩니다.
구조가 만들어낸 지연을 사람의 책임으로 돌릴 때, 팀은 점점 말을 아끼고, 더 조심스러워지고, 결국 정지된 흐름 안에 갇히게 됩니다.
병목을 감지하는 신호들
늘 그 단계만 오면 검토 시간이 길어진다
특정 사람의 응답을 기다리는 시간이 길다
전체 일정이 아닌 '그 한 구간'에서 항상 딜레이가 시작된다
마감 전에 급하게 뭉쳐진 일이 한꺼번에 몰린다
이 신호들을 감지하는 게 병목 제거의 첫걸음입니다.
병목을 제거하는 전략들
1. 흐름 따라 병목 추적하기
프로젝트 타임라인을 시각화해 보세요.
지연이 가장 잦은 단계가 병목입니다.
2. 역할 분산 설계하기
승인, 검토, 결정 같은 기능이 특정인에게만 몰려 있다면, 두세 명 이상이 대체 가능하도록 구조를 바꿔보세요.
3. 예비 트리거 만들기
병목 전에 '미리 보는 체크리스트'나 '사전 검토 루틴'을 넣어 흐름을 미리 열어두세요.
병목은 '고장'이 아니라 '경고'입니다
속도가 느려졌다는 건 시스템이 '재설계를 요구하고 있다'는 뜻입니다.
사람이 느린 게 아닙니다.
구조가 좁은 것입니다.
병목을 바꾸면 흐름이 다시 살아납니다.
다음 편에서는 '루틴은 나쁘지 않다. 무의식적일 뿐'을 다뤄보겠습니다.
지겨운 반복처럼 보이는 루틴 속에도 사실은 중요한 리듬과 정보가 숨어 있습니다.
