핵심 인사이트 (3줄 요약)
- 본질: 칸반 (Kanban)은 작업 흐름을 보이게 하고, WIP (Work In Progress) 제한으로 동시에 진행하는 일을 줄이는 흐름 관리 방식이다.
- 가치: 완료를 늦추는 가장 큰 원인은 시작을 너무 많이 하는 것이다. WIP 제한은 병목을 숨기지 않고 드러나게 만든다.
- 판단 포인트: WIP 숫자는 기분이 아니라 데이터로 정해야 한다. 팀 용량, 사이클 타임, 막히는 구간을 보고 조정해야 한다.
Ⅰ. 개요 및 필요성
칸반 (Kanban)은 작업을 카드로 시각화하고, 다음 단계로 끌어오는 pull 방식으로 흐름을 관리하는 기법이다. 요구사항 분석 단계에서 칸반을 쓰면 '아직 안 끝난 일'이 어디에서 쌓이는지 바로 볼 수 있다. 특히 요구 수집, 정제, 검토, 승인처럼 대기 구간이 많은 팀에서 효과가 크다.
WIP (Work In Progress) 제한은 한 단계에 동시에 두는 작업 수를 제한하는 규칙이다. 제한이 없으면 사람은 시작하기 쉬운 일을 계속 벌리지만, 완료는 늦어지고 전환 비용만 늘어난다.
Backlog → Ready → Doing [WIP 3] → Review [WIP 2] → Done
↑ 막히면 다음 단계가 아니라 병목을 먼저 본다
- 📢 섹션 요약 비유: 책상 위에 숙제가 너무 많으면 아무것도 끝나지 않으니, 펼쳐 놓는 공책 수를 줄이는 것과 같다.
Ⅱ. 아키텍처 및 핵심 원리
칸반의 핵심은 '보이는 흐름'과 '제한된 진행 중 작업'이다. 보드의 열은 상태를, 열 위의 숫자는 허용량을 뜻한다. 이 숫자가 차면 새 작업을 더 넣는 대신 현재 작업의 정체를 해결해야 한다. 결국 WIP 제한은 속도를 늦추는 장치가 아니라, 완료율을 높이기 위한 제어 장치다.
| 보드 요소 | 의미 | 판단 포인트 |
|---|---|---|
| Backlog | 아직 착수 전인 항목 | 우선순위가 명확한가 |
| Ready | 바로 시작 가능한 항목 | 정의가 충분한가 |
| Doing | 실행 중 작업 | WIP 제한이 있는가 |
| Review / Blocked | 검토 / 대기 상태 | 병목이 어디인지 드러나는가 |
| Done | 완료 | 완료의 정의가 일관적인가 |
작업 흐름의 원리
요청 유입 → 분석 → 구현 → 검토 → 완료
│ │ │ │
└────── WIP 제한이 병목을 드러낸다 ──────┘
WIP를 줄이면 처음에는 불편하지만, 기다림이 줄고 사이클 타임이 짧아진다. 여기서 중요한 것은 숫자 자체보다, 숫자가 팀의 실제 병목과 맞는가이다.
- 📢 섹션 요약 비유: 주방에서 동시에 여러 냄비를 올려두는 것보다, 딱 적당한 수만 관리하는 편이 더 빨리 나온다.
Ⅲ. 비교 및 연결
칸반은 스크럼 (Scrum)과 자주 비교되지만, 둘의 목적은 다르다. 스크럼은 시간 박스와 역할을 통해 반복 학습을 강조하고, 칸반은 흐름과 제한을 통해 지속적인 개선을 강조한다. 요구사항 분석 단계에서는 정해진 스프린트보다, 들어오는 요청이 계속 바뀌는 환경에서 칸반이 더 자연스럽다.
| 비교 축 | 칸반 | 스크럼 |
|---|---|---|
| 운영 리듬 | 지속 흐름 | 스프린트 중심 |
| 제어 방식 | WIP 제한 | 스프린트 백로그와 약속 |
| 변경 수용 | 상대적으로 유연 | 스프린트 중 변경에 제약 |
| 핵심 지표 | Cycle Time / Throughput | 번다운 / 목표 달성률 |
또 하나의 연결은 pull 시스템이다. 들어오는 대로 시작하는 push 방식은 처리량을 착각하게 만들지만, 칸반은 완료 가능한 만큼만 당겨오게 해 병목을 숨기지 않는다. 필요하면 CFD (Cumulative Flow Diagram)로 누적 흐름을 보며 열별 체류 시간을 확인할 수 있다.
- 📢 섹션 요약 비유: 줄 서는 손님이 많아도 한 번에 몇 명만 받는 식당이, 실제로는 더 빨리 돌아가는 경우가 있다.
Ⅳ. 실무 적용 및 기술사 판단
실무에서 WIP 제한은 팀원 수와 똑같이 맞추는 것이 아니라, 병목과 작업 종류에 따라 조정해야 한다. 분석 대기, 고객 확인 대기, 개발 대기처럼 막히는 구간이 있다면 그 구간의 WIP를 더 낮춰야 한다. 너무 높게 잡으면 보드는 예쁘지만 아무도 끝내지 못한다.
체크리스트
- 열마다 WIP 숫자가 실제로 지켜지는가?
- 막힌 작업을 별도 표시하고 우선 해결하는가?
- 사이클 타임과 throughput를 꾸준히 보고 있는가?
- 보드 열이 상태가 아니라 책임 분담처럼 바뀌지 않았는가?
안티패턴
-
WIP 제한을 '엄격한 벌점'처럼 운영하는 경우
-
열이 너무 많아 보드만 복잡해지는 경우
-
상태만 보고 병목 원인을 분석하지 않는 경우
-
📢 섹션 요약 비유: 장난감을 한꺼번에 너무 많이 꺼내면 치우는 데 더 오래 걸리는 것과 같다.
Ⅴ. 기대효과 및 결론
칸반과 WIP 제한의 기대효과는 리드타임 단축, 병목 가시화, 우선순위 명확화다. 하지만 보드는 관리 도구일 뿐이고, 실제 개선은 막힌 이유를 제거할 때 생긴다. 그래서 칸반은 '현황판'이 아니라 '흐름 제어판'으로 써야 의미가 있다.
결론적으로 WIP 제한은 팀을 덜 일하게 만드는 규칙이 아니라, 더 자주 끝내게 만드는 규칙이다. 완료를 늘리고 싶다면 시작을 줄여야 한다는 역설을 기억하면 된다.
- 📢 섹션 요약 비유: 한 번에 많이 들고 가는 것보다, 적게 들고 여러 번 가는 편이 결국 더 빨리 정리된다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|---|
| Kanban | 작업 흐름을 보이게 하는 방법 |
| WIP (Work In Progress) | 동시에 진행하는 작업의 상한 |
| Pull system | 완료 가능한 만큼만 끌어오는 방식 |
| Cycle Time | 작업이 끝나는 데 걸리는 시간 |
| Throughput | 단위 시간당 완료 수 |
| CFD (Cumulative Flow Diagram) | 흐름과 정체를 보는 누적 그래프 |
📈 관련 키워드 및 발전 흐름도
요청 유입
│
▼
보드에 시각화
│
▼
WIP 제한으로 pull
│
▼
완료와 측정
흐름을 줄여야 완료가 늘어난다는 점이 칸반의 핵심이다.
👶 어린이를 위한 3줄 비유 설명
- 책상 위에 공책을 너무 많이 펼치면 정리가 어려워요.
- 딱 몇 개만 놓고 끝내면 더 빨리 치울 수 있어요.
- 칸반은 '많이 시작하지 말고, 끝낼 수 있게 하자'고 말해요.