WIP 제한: 더 빨리 끝내려면 덜 시작하라

"개발자가 5명이니까 5개 작업을 동시에 진행하면 되겠네요?"

아닙니다.

오히려 2개만 진행하면 더 빨리 끝납니다.

이게 WIP(Work In Progress) 제한의 마법입니다.

멀티태스킹의 환상

월요일 아침, 여러분의 작업 목록을 보면 어떤가요?

버그 수정 30%, 신기능 개발 20%, 코드 리뷰 대기중, 문서 작성 10%, 회의 준비...

금요일 저녁이 되면?

버그 수정 70%, 신기능 개발 40%, 코드 리뷰 대충함, 문서 작성 15%, 회의 준비 급하게...

완료된 작업: 0개

컨텍스트 스위칭의 비용

작업을 전환할 때마다 우리 뇌는 비용을 지불합니다.

function calculateSwitchingCost(numberOfTasks) {
  const baseProductivity = 100;
  const switchingPenalty = 20; // 작업당 20% 손실
  
  if (numberOfTasks === 1) {
    return baseProductivity;
  }
  
  const productivity = baseProductivity - (numberOfTasks - 1) * switchingPenalty;
  return Math.max(productivity, 20);
}

console.log("1개 작업:", calculateSwitchingCost(1), "%"); // 100%
console.log("3개 작업:", calculateSwitchingCost(3), "%"); // 60%
console.log("5개 작업:", calculateSwitchingCost(5), "%"); // 20%

5개 작업을 동시에 하면 생산성이 20%로 떨어집니다.

작업 전환할 때마다 현재 상태 저장, 다음 작업 기억해내기, 파일 열기, 집중력 회복...
한 번 전환에 43분이 낭비됩니다. 하루 5번 전환하면? 3.5시간이 사라집니다.

WIP 제한의 원리

리틀의 법칙 (Little's Law)

평균 대기시간 = WIP / 처리율

WIP 제한 없이 10개 작업을 동시에 하면 각 작업이 5일씩 걸립니다.
WIP를 3개로 제한하면? 1.5일만에 끝납니다.

적게 시작해야 빨리 끝납니다.

칸반 보드로 WIP 관리

class KanbanBoard {
  constructor() {
    this.columns = {
      backlog: { limit: null, tasks: [] },
      todo: { limit: 5, tasks: [] },
      doing: { limit: 2, tasks: [] },  // 핵심: WIP 제한!
      review: { limit: 3, tasks: [] },
      done: { limit: null, tasks: [] }
    };
  }
  
  canAddToColumn(columnName) {
    const column = this.columns[columnName];
    if (!column.limit) return true;
    return column.tasks.length < column.limit;
  }
}

Doing 컬럼에 2개 제한을 걸면, 새 작업을 시작하려면 기존 작업을 끝내야 합니다.
이게 Pull 시스템입니다.

실제 적용 사례

5명 팀이 WIP 제한을 도입한 결과입니다.

Before: 무제한 WIP

• 진행중 작업: 15개
• 평균 완료 시간: 2주
• 월간 완료: 8개
• 팀 스트레스: 높음

After: WIP 제한 도입 (3개)

• 진행중 작업: 3개
• 평균 완료 시간: 3일
• 월간 완료: 20개 (2.5배 증가!)
• 팀 스트레스: 낮음

WIP 제한 설정 방법

적절한 WIP 찾기

function findOptimalWIP(teamSize, taskComplexity) {
  // 기본 공식: 팀 크기의 50-70%
  let baseWIP = Math.floor(teamSize * 0.6);
  
  const adjustments = {
    simple: 1.2,      // 간단한 작업: WIP 늘려도 OK
    medium: 1.0,      // 중간: 기본값
    complex: 0.7,     // 복잡한 작업: WIP 줄이기
    research: 0.5     // 연구/탐색: 더 줄이기
  };
  
  return Math.max(1, Math.floor(baseWIP * adjustments[taskComplexity]));
}

// 5명 팀, 복잡한 작업
console.log(findOptimalWIP(5, "complex")); // 2개 권장

단계별 도입

Week 1: 현재 상태 측정

• 진행중 작업 수 기록
• 완료 시간 측정
• 병목 지점 파악

Week 2: 느슨한 제한

• 현재 WIP의 70% 수준으로 제한
• 예외 허용
• 팀 피드백 수집

Week 3-4: 최적화

• WIP 점진적 감소
• 병목 해결
• 프로세스 개선

병목 현상 찾기

WIP 제한의 또 다른 장점은 병목을 즉시 발견할 수 있다는 것입니다.

현재 컬럼이 가득 차고 다음 컬럼이 비어있으면? 다음 컬럼이 병목입니다.
코드 리뷰가 병목이라면 리뷰 프로세스를 개선해야 합니다.

WIP 제한의 부가 효과

품질 향상

WIP 제한 전: 버그 발생률 15%, 테스트 커버리지 45%
WIP 제한 후: 버그 발생률 5%, 테스트 커버리지 75%

집중도가 올라가니 실수가 줄어듭니다.

예측 가능성

WIP 제한 전: "2주쯤?" → 실제 1~6주
WIP 제한 후: "3일 (±1일)" → 실제 2~4일

예측 정확도가 30%에서 85%로 올라갑니다.

흔한 실수와 해결책

실수 1: 너무 엄격한 시작

현재 WIP 20개를 첫날부터 3개로 줄이면 팀이 반발합니다.
20 → 15 → 10 → 7 → 5처럼 점진적으로 줄이세요.

실수 2: 예외 없는 규칙

class FlexibleWIP {
  handleEmergency(task) {
    if (task.priority === "CRITICAL") {
      // 긴급 상황에는 임시로 +1 허용
      this.currentLimit = this.baseLimit + 1;
      console.log("긴급 작업으로 WIP 임시 증가");
      
      // 단, 다른 작업 하나를 보류
      return "다른 작업 하나를 백로그로 이동하세요";
    }
  }
}

마무리

WIP 제한은 직관에 반하는 개념입니다.

"더 많이 시작하면 더 많이 끝낸다"는 착각에서 벗어나야 합니다.

진실: 덜 시작해야 더 많이 끝납니다.

핵심 원칙:

• 동시 작업을 제한하라
• 완료에 집중하라
• Pull 시스템을 사용하라
• 병목을 찾아 해결하라

다음 스프린트에 WIP 제한을 시도해보세요.
첫 주는 어색하겠지만, 곧 그 효과에 놀라게 될 겁니다.

---

"Stop starting, start finishing."

효과적인 프로젝트 관리가 필요하신가요? Plexo를 확인해보세요.