WIP가 의지가 아니라
시스템인 이유

1-1 보론. 멈춘 일은 보이지 않는다 — WIP가 의지가 아니라 시스템인 이유

핵심 질문: WIP를 칼같이 3개로 지켰는데, 왜 여전히 아무것도 안 끝날까?

원글은 "시작하지 말고 끝내라"를 신경과학과 리틀의 법칙으로 두껍게 떠받친 강한 글입니다. 혼자 바카라상 앞에 앉아 내 머릿속 과제 수를 줄이는 문제라면, 거의 완벽한 처방이죠.

그런데 그 처방을 들고 팀 한가운데로 들어가면 한 가지 전제가 무너집니다 — 내 WIP가 정말 내 것일 때만 통한다는 전제입니다. 실무에서 진행 중인 일의 절반은 내가 시작한 게 아니라 밖에서 밀려들어온 것이고, 또 절반은 내가 끝낼 수 없는 상태—누군가의 리뷰를 기다리고, 답을 기다리고, 의존성에 막혀—멈춰 있습니다.

한 사람을 따라가 보겠습니다. 은수와 같은 팀의 백엔드 개발자 도현. 그 역시 가상의 인물이지만, 아마 당신 팀에도 한 명쯤 있을 겁니다.

도현은 원글을 읽고 그 자리에서 규칙을 정했습니다.

동시에 3개 이상의 일을 진행하지 않는다.

깔끔했습니다. "Stop Starting, Start Finishing"을 모니터 옆에 붙여두기까지 했죠. 그리고 일주일 뒤, 도현은 더 적은 일을 붙들고 있었는데도 첫 글보다 더 막막해졌습니다.

이 보론은 그 일주일에 관한 이야기입니다. 결론을 먼저 말하면 이렇습니다 — WIP 문제는 의지의 문제가 아니라 시스템의 문제다. 그리고 진짜 병목은 내 바카라상 위가 아니라, 보이지 않는 곳에 멈춰 있다.

"Stop Starting"이 "Start Idling"이 될 때

수요일 오후, 도현의 WIP는 정확히 3개였습니다. 규칙대로였죠.

결제 API 리팩터링 — PR을 올렸고, 시니어의 리뷰를 이틀째 기다리는 중

로그 적재 버그 — 인프라팀에 "이 큐가 왜 막히냐"고 물어두고 답을 기다리는 중

신규 가입 이벤트 핸들러 — 지금 손대고 있는, 유일하게 실제로 굴러가는 일

도현은 규칙을 지키느라 네 번째 일을 시작하지 않았습니다. 그런데 묘한 일이 벌어졌습니다. 세 번째 일이 잠깐 손이 빌 때—빌드를 기다리거나 생각을 정리할 때—평소 같으면 다른 걸 집어 들었을 텐데, WIP가 꽉 찼으니 그럴 수 없었습니다. 앞의 두 개는 도현이 뭘 한다고 풀리는 게 아니었고요. 리뷰어가 봐줘야 하고, 인프라팀이 답해줘야 했으니까.

결과적으로 도현은 한도가 꽉 찬 채로 놀고 있었습니다. 끝난 건 없었습니다. 둘은 남의 손에 멈춰 있고, 하나만 느릿느릿 가고 있었죠.

원글의 만트라가 여기서 배신합니다. "Stop Starting, Start Finishing"이, 도현에게는 "Stop Starting, Start Idling"—시작도 멈췄지만 완료도 멈춘 상태—이 되어버린 겁니다. 글이 자랑하던 풀(Pull) 시스템이, 당길 게 없으니 사람을 놀게 만들었습니다.

문제의 정체는 이겁니다. 원글은 WIP를 "동시에 진행 중인 일의 개수"라고 했지만, 도현의 WIP 3개 중 실제로 진행 중인 건 1개뿐이었습니다. 나머지 둘은 진행 중이 아니라 멈춰 있는 일이었죠. 활성(active) WIP과 차단된(blocked) WIP을 한 칸에 욱여넣고 세니까, 숫자는 3인데 흐름은 1이었던 겁니다.

Lean 연구자들은 이걸 자원 효율(resource efficiency)과 흐름 효율(flow efficiency)의 차이로 설명합니다(Modig & Åhlström). 도현은 자기 자원(머릿속 슬롯)을 꽉 채우는 데는 성공했지만, 정작 일이 흐르는 효율은 1/3로 떨어진 거죠. 바쁜 것과 흐르는 것은 다릅니다.

리틀의 법칙은 시스템 법칙이다

원글의 가장 강한 카드는 리틀의 법칙이었습니다. W = L/\lambda — 진행 중인 일(L)을 줄이면 리드타임(W)이 준다. 맞는 말입니다. 다만 원글은 이 시스템 법칙을 개인 처방으로 축소했습니다.

리틀의 법칙은 원래 대기열 전체에 대한 법칙입니다. 도현이 줄여야 할 L은 "도현의 바카라상 위 개수"가 아니라 "그 일이 결제 API라는 흐름을 통과하는 동안 시스템 안에 쌓인 전체 재공품"입니다. 그런데 도현이 통제한 건 자기 로컬 슬롯 하나뿐이었죠. 그래서 자기 바카라상은 깨끗했지만, 일은 리뷰 대기 큐와 인프라팀 응답 큐라는, 도현 눈에 안 보이는 곳에 쌓여 있었습니다.

이게 제약 이론(Theory of Constraints)이 오래전부터 경고한 함정입니다. Goldratt이 『The Goal』에서 말했듯, 병목이 아닌 곳을 아무리 최적화해도 시스템 전체 처리량은 1도 늘지 않습니다. 도현이 자기 작업 속도를 두 배로 올려도, 리뷰가 이틀씩 걸리는 한 결제 API는 이틀+α에 끝납니다. 도현의 의지가 닿지 않는 곳에 진짜 병목이 있었던 거죠.

제품 개발 흐름을 연구한 Reinertsen은 이걸 한 문장으로 못박습니다. "가장 큰 비용은 보이지 않는 큐에 있다." 우리가 관리해야 할 건 사람의 가동률이 아니라 큐의 길이인데, 큐는 바카라상 위에 안 보이니 아무도 관리하지 않는다는 겁니다. 도현의 멈춘 일 두 개가 정확히 그 보이지 않는 큐였습니다.