멀티태스킹의 환상과 해결책
"개발자가 5명이니까 5개 작업을 동시에 진행하면 되겠네요?"
아닙니다.
오히려 2개만 진행하면 더 빨리 끝납니다.
이게 WIP(Work In Progress) 제한의 마법입니다.
월요일 아침, 여러분의 작업 목록을 보면 어떤가요? 버그 수정 30%, 신기능 개발 20%, 코드 리뷰 대기중, 문서 작성 10%, 회의 준비...
금요일 저녁이 되면 버그 수정 70%, 신기능 개발 40%, 코드 리뷰 대충함, 문서 작성 15%, 회의 준비 급하게...
완료된 작업: 0개
작업을 전환할 때마다 우리 뇌는 비용을 지불합니다. 기본 생산성은 100%인데, 작업 전환마다 20%씩 손실됩니다. 1개 작업은 100%, 3개 작업은 60%, 5개 작업은 20% 생산성입니다.
5개 작업을 동시에 하면 생산성이 20%로 떨어집니다.
작업 전환할 때마다 현재 상태 저장, 다음 작업 기억해내기, 파일 열기, 집중력 회복까지 한 번 전환에 43분이 낭비됩니다. 하루 5번 전환하면 3.5시간이 사라집니다.
리틀의 법칙에 따르면 평균 대기시간은 WIP를 처리율로 나눈 값입니다. WIP 제한 없이 10개 작업을 동시에 하면 각 작업이 5일씩 걸립니다. WIP를 3개로 제한하면 1.5일만에 끝납니다.
적게 시작해야 빨리 끝납니다.
칸반 보드에서 Doing 컬럼에 2개 제한을 걸면, 새 작업을 시작하려면 기존 작업을 끝내야 합니다. 이게 Pull 시스템입니다. Backlog와 Done 컬럼은 제한이 없고, Todo는 5개, Doing은 2개, Review는 3개로 제한합니다.
5명 팀이 WIP 제한을 도입한 결과입니다.
무제한 WIP에서는 진행중 작업 15개, 평균 완료 시간 2주, 월간 완료 8개, 팀 스트레스 높음이었습니다.
WIP 제한 도입(3개) 후에는 진행중 작업 3개, 평균 완료 시간 3일, 월간 완료 20개(2.5배 증가), 팀 스트레스 낮음으로 개선되었습니다.
적절한 WIP는 팀 크기의 50-70%를 기본으로 합니다. 작업 복잡도에 따라 조정합니다. 간단한 작업은 1.2배, 중간은 1.0배, 복잡한 작업은 0.7배, 연구나 탐색 작업은 0.5배입니다. 5명 팀, 복잡한 작업의 경우 2개를 권장합니다.
단계별 도입은 첫 주에 현재 상태를 측정합니다. 진행중 작업 수 기록, 완료 시간 측정, 병목 지점 파악을 합니다. 두 번째 주에는 느슨한 제한을 적용합니다. 현재 WIP의 70% 수준으로 제한하고, 예외를 허용하며, 팀 피드백을 수집합니다. 세 번째와 네 번째 주에는 최적화를 진행합니다. WIP를 점진적으로 감소시키고, 병목을 해결하며, 프로세스를 개선합니다.
WIP 제한의 또 다른 장점은 병목을 즉시 발견할 수 있다는 것입니다. 현재 컬럼이 가득 차고 다음 컬럼이 비어있으면 다음 컬럼이 병목입니다. 코드 리뷰가 병목이라면 리뷰 프로세스를 개선해야 합니다.
품질 향상 측면에서 WIP 제한 전에는 버그 발생률 15%, 테스트 커버리지 45%였지만, WIP 제한 후에는 버그 발생률 5%, 테스트 커버리지 75%로 개선되었습니다. 집중도가 올라가니 실수가 줄어듭니다.
예측 가능성 측면에서 WIP 제한 전에는 "2주쯤?"이라고 하면 실제 1~6주였지만, WIP 제한 후에는 "3일 (±1일)"이라고 하면 실제 2~4일입니다. 예측 정확도가 30%에서 85%로 올라갑니다.
첫 번째 실수는 너무 엄격하게 시작하는 것입니다. 현재 WIP 20개를 첫날부터 3개로 줄이면 팀이 반발합니다. 20 → 15 → 10 → 7 → 5처럼 점진적으로 줄이세요.
두 번째 실수는 예외 없는 규칙입니다. 긴급 상황에는 임시로 +1을 허용하되, 다른 작업 하나를 백로그로 이동해야 합니다.
WIP 제한은 직관에 반하는 개념입니다.
"더 많이 시작하면 더 많이 끝낸다"는 착각에서 벗어나야 합니다.
진실: 덜 시작해야 더 많이 끝납니다.
핵심 원칙은 동시 작업을 제한하고, 완료에 집중하며, Pull 시스템을 사용하고, 병목을 찾아 해결하는 것입니다.
다음 스프린트에 WIP 제한을 시도해보세요. 첫 주는 어색하겠지만, 곧 그 효과에 놀라게 될 겁니다.
효과적인 프로젝트 관리가 필요하신가요? Plexo를 확인해보세요.