애자일 제대로 알기 3편: Kanban · Lean · 흐름(Flow) — WIP 제한과 Little's Law
서론
이전 글에서 Scrum은 고정 길이 스프린트로 리듬을 만드는 접근이라고 했다. 그런데 모든 일이 그 리듬에 맞지는 않는다.
운영·장애 대응·고객 지원·인프라 작업을 떠올려 보자. 일이 불규칙하게 들어오고, 우선순위는 수시로 바뀌며, 어제 없던 긴급 건이 오늘 1순위가 된다. 이런 일을 2주짜리 스프린트에 욱여넣으면, 긴급 건이 끼어들 때마다 스프린트 목표가 깨진다.
Kanban은 다른 답을 낸다. 고정 반복을 두지 않고, 일의 흐름(flow)을 시각화한 뒤 진행 중 작업(WIP)을 제한해 흐름을 관리한다. 뿌리는 도요타의 Lean이다. 그래서 3편은 Lean의 유산에서 출발해 Kanban의 6 프랙티스와 WIP 제한, “WIP를 줄이면 왜 빨라지는가”(Little’s Law), 흐름 지표, 그리고 Scrum과 Kanban을 언제 무엇으로 골라야 하는지까지 다룬다.
대상 독자는 스프린트가 자꾸 깨지는 운영·지원 성격의 팀, Scrum 말고 다른 선택지를 보고 싶은 사람이다. 1–2편을 안 봐도 되지만, 보면 “흐름도 결국 검사·적응”이라는 연결이 더 잘 보인다.
- 1편 — 애자일은 왜 등장했나 — 선언문 · 4가치 · 12원칙
- 2편 — Scrum — 경험적 프로세스 제어와 3-5-3
- 3편 — Kanban · Lean · 흐름(Flow) (이 글)
- 4편 — 실천과 측정 — XP부터 벨로시티 · DORA까지
- 5편 — 스케일링과 가짜 애자일
- 6편 — 실전: 유저스토리에서 릴리스까지
- 7편 — 디스커버리: 유저스토리는 어디서 오는가
TL;DR
- Kanban은 흐름 기반이다 — 고정 반복(스프린트) 없이, 일의 흐름을 시각화하고 진행 중인 작업량을 제한해 관리한다. 인입이 불규칙하고 우선순위가 자주 바뀌는 일에 강하다.
- 뿌리는 Lean(도요타 생산 방식)이다 — 낭비를 없애고, 밀어내기(push)가 아니라 당겨오기(pull)로 일을 흘린다. 빈 자리가 생겨야 다음 일을 당겨온다.
- 진행 중인 작업량 제한이 핵심 레버다 — Little’s Law(리드타임 = 진행 중인 작업량 ÷ 처리량)에 따라, 처리량이 같아도 진행 중인 작업량을 줄이면 리드타임이 짧아진다. 멀티태스킹 세금이 줄어 처리량 자체도 보통 올라간다.
- 흐름은 벨로시티가 아니라 흐름 지표로 본다 — 리드타임 · 사이클타임 · 처리량, 그리고 누적 흐름도로 병목을 읽는다.
- Scrum과 Kanban은 양자택일이 아니다 — 계획적 기능 개발은 Scrum, 불규칙 인입(운영·지원)은 Kanban, 둘을 섞으면 Scrumban.
1. Lean의 유산 — 도요타에서 소프트웨어로
1.1 도요타 생산 방식에서 출발
Lean(린)은 도요타 생산 방식(TPS, Toyota Production System)에서 정리된 생산 철학이다. 핵심은 두 가지로 요약된다 — 낭비(waste)를 없애고, 흐름을 끊지 않는다.
여기서 “Kanban(칸반, 看板)“이라는 말도 나왔다. 도요타 공장에서 칸반은 “이 부품을 더 채워라”를 알리는 시각 신호 카드였다. 앞 공정은 뒤 공정이 신호(칸반)를 보낼 때만 부품을 만든다. 즉 재고를 미리 쌓지 않고, 필요한 만큼만 당겨서 만든다.
소프트웨어로 넘어오며 두 흐름으로 갈라졌다. 하나는 Lean의 사고방식을 개발에 적용한 Lean Software Development(메리·톰 포펜딕, 2003)이고, 다른 하나는 칸반 신호를 지식 노동에 적용한 Kanban 방법(데이비드 앤더슨)이다. 1절은 전자(사고방식), 2절은 후자(실천)를 본다.
1.2 Lean Software Development 7원칙
포펜딕 부부는 Lean을 소프트웨어용 7원칙으로 옮겼다. 전부 외울 필요는 없고, “낭비 제거 + 빠른 흐름 + 사람 신뢰 + 전체 보기”로 묶어 읽으면 된다.
| 원칙 | 한 줄 의미 |
|---|---|
| 낭비를 없앤다 | 가치를 더하지 않는 모든 것(미완 작업·불필요 기능·대기·재작업)을 줄인다 |
| 학습을 증폭한다 | 짧은 주기로 만들어 보며 배운다 — 1편의 짧은 반복 루프 |
| 가능한 늦게 결정한다 | 되돌리기 어려운 결정은 정보가 가장 많은 시점까지 미룬다 |
| 가능한 빨리 전달한다 | 빨리 흘려보내야 피드백도 빨라진다(흐름의 핵심) |
| 팀에 권한을 준다 | 일하는 사람이 방법을 정한다 — 2편의 자기관리 |
| 통합성을 내재화한다 | 품질을 나중에 검사하지 말고 만드는 과정에 심는다 |
| 전체를 본다 | 한 단계만 최적화하지 말고 흐름 전체를 최적화한다 |
이 중 첫 번째 낭비가 Lean의 출발점이다. 소프트웨어의 대표적 낭비는 미완 작업(끝나지 않아 가치 0인 재고), 불필요한 기능(아무도 안 쓰는 것 — 1편 10원칙 단순성), 작업 전환(멀티태스킹 비용), 대기(다음 단계를 기다리는 시간)다. WIP 제한은 이 중 미완 작업과 작업 전환을 동시에 줄이는 장치다(3절).
1.3 밀어내기(push) vs 당겨오기(pull)
흐름을 망치는 가장 흔한 패턴은 밀어내기(push)다. 앞 단계가 뒤 단계의 여력과 무관하게 일을 떠넘기면, 뒤 단계 앞에 일이 쌓이고 전체가 막힌다.
| 방식 | 일이 흐르는 방법 | 결과 |
|---|---|---|
| 밀어내기(push) | 앞 단계가 완료되면 뒤로 떠넘김(여력 무관) | 병목 앞에 미완 작업이 쌓임, 리드타임 폭증 |
| 당겨오기(pull) | 뒤 단계가 여력이 생길 때만 앞에서 당겨옴 | WIP가 묶여 있어 흐름이 일정, 병목이 드러남 |
Kanban은 철저히 당겨오기(pull) 기반이다. “할 일이 있으니 일단 시작”이 아니라, “내 자리가 비었을 때만 다음 일을 당겨온다.” 이 한 가지 규칙이 다음 절의 WIP 제한으로 구체화된다.
2. Kanban — 흐름을 시각화하고 WIP를 제한한다
2.1 Kanban 방법이란
Kanban 방법은 기존 프로세스를 갈아엎지 않고 “지금 하는 일에서 시작해 점진적으로 진화시키는” 접근이다. Scrum처럼 새 역할·이벤트를 강제로 도입하지 않는다. 지금의 흐름을 보드에 그대로 그려 놓고, 거기서 조금씩 개선한다.
그래서 Kanban은 Scrum보다 도입 저항이 작다. 역할도 스프린트도 바꾸지 않고, “우리 일이 어떻게 흐르는지 일단 눈에 보이게 하자”로 시작할 수 있다.
2.2 여섯 가지 프랙티스
Kanban은 여섯 가지 실천으로 정리된다.
| 프랙티스 | 무엇을 |
|---|---|
| 시각화 | 일의 흐름을 보드로 드러낸다(단계별 컬럼) |
| WIP 제한 | 각 단계에 동시에 둘 수 있는 일의 수를 제한한다 |
| 흐름 관리 | 일이 막히는 곳을 보고 흐름을 매끄럽게 한다 |
| 정책 명시화 | ”언제 다음 단계로 넘기나” 같은 규칙을 적어 둔다 |
| 피드백 루프 | 정기적으로 흐름을 검토한다(2편 검사·적응의 흐름 버전) |
| 협력적·실험적 개선 | 작게 바꿔 보고 결과로 판단해 진화시킨다 |
2.3 칸반 보드와 WIP 제한
칸반 보드는 일의 흐름을 단계별 컬럼으로 그린 것이다. 카드(일) 하나가 왼쪽에서 오른쪽으로 흘러간다.
flowchart LR
BL["백로그"] --> TODO["할 일"] --> DOING["진행 중<br/>WIP ≤ 3"] --> REV["검토<br/>WIP ≤ 2"] --> DONE["완료"]여기서 컬럼 위의 WIP ≤ N이 핵심이다. WIP(Work In Progress)는 “지금 동시에 진행 중인 일의 수”이고, WIP 제한은 그 수의 상한이다. 예컨대 “진행 중” 컬럼의 WIP 제한이 3이면, 거기 카드가 3장 차 있는 한 새 일을 시작할 수 없다. 한 장이 다음 단계로 넘어가 자리가 비어야 비로소 “할 일”에서 하나를 당겨온다(pull).
규칙은 한 줄이지만 효과는 크다. WIP 제한은 “일단 다 벌여 놓는” 습관을 구조적으로 막는다. 왜 이게 오히려 더 빨리 끝내게 하는지는 다음 절의 Little’s Law가 설명한다.
3. WIP를 줄이면 왜 빨라지나 — Little’s Law
3.1 Little’s Law
흐름에는 단순하지만 강력한 항등식이 있다. Little’s Law(리틀의 법칙)다.
평균 리드타임 = 평균 WIP ÷ 평균 처리량여기서 리드타임은 일이 시작돼 끝날 때까지 걸린 시간, 처리량은 단위 시간당 끝낸 일의 수다. 직관은 줄 서기와 같다 — 앞에 선 사람이 많을수록(WIP↑), 처리 속도가 같다면 내 차례까지 오래 걸린다(리드타임↑).
숫자로 보면 분명하다.
- 팀이 동시에 30건을 붙잡고 있고(WIP=30), 주당 10건을 끝낸다(처리량=10건/주)면 → 평균 리드타임 = 30 ÷ 10 = 3주.
- 처리량은 그대로 두고 WIP만 15로 줄이면 → 리드타임 = 15 ÷ 10 = 1.5주. 절반이 된다.
즉 리드타임을 줄이는 가장 직접적인 레버는 일을 더 빨리 하는 게 아니라 동시에 벌여 놓는 일을 줄이는 것이다.
flowchart LR
IN["새 일 유입"] --> SYS["진행 중 작업 WIP개<br/>(동시에 붙잡은 일)"]
SYS --> OUT["완료 · 처리량(주당 N개)"]3.2 WIP를 줄이면 처리량도 보통 오른다
Little’s Law는 “처리량이 같을 때”를 가정하지만, 실제로는 WIP를 줄이면 처리량 자체도 올라가는 경우가 많다. 이유는 네 가지다.
- 멀티태스킹 세금이 준다 — 동시에 여러 일을 붙잡으면 작업 전환 비용(컨텍스트 스위칭)으로 각 일이 다 느려진다. 적게 잡으면 한 건당 더 빨리 끝난다.
- 병목이 드러난다 — WIP를 제한하면 일이 특정 단계에 막히는 게 즉시 보인다. 그 단계에 사람을 몰아 병목을 푼다.
- 피드백이 빨라진다 — 적게 벌여 놓으면 결함이 빨리 드러나 재작업이 준다(Lean의 낭비 제거).
- 미완 재고가 준다 — 끝나지 않은 일은 가치가 0이고 시간이 갈수록 노후화·충돌 위험만 키운다.
핵심: “바쁘게 다 벌여 놓는 것”과 “빨리 끝내는 것”은 다르다. WIP를 낮추는 건 게으름이 아니라, 흐름을 빠르게 하는 가장 확실한 손잡이다.
4. 흐름 지표 — 무엇을 측정하나
Scrum이 벨로시티(스프린트당 완료량)를 본다면, Kanban은 흐름 지표를 본다. 흐름이 빠르고 일정한지를 직접 재는 값들이다.
| 지표 | 정의 | 무엇을 말해 주나 |
|---|---|---|
| 리드타임(lead time) | 일을 요청·착수 약속한 시점부터 완료까지 | 고객이 체감하는 전체 대기 시간 |
| 사이클타임(cycle time) | 실제 작업을 시작한 시점부터 완료까지 | 팀이 손대고 있는 동안의 시간 |
| 처리량(throughput) | 단위 시간당 완료한 일의 수 | 팀이 실제로 내보내는 속도 |
| WIP | 지금 진행 중인 일의 수 | 흐름에 묶여 있는 재고의 양 |
참고: 리드타임과 사이클타임의 경계는 팀마다 정의가 조금씩 다르다. 중요한 건 “어디서 시작해서 어디서 끝나는지”를 팀이 명시적으로 합의하는 것이다(Kanban 4번째 프랙티스, 정책 명시화).
이 흐름을 한 그림으로 보는 도구가 누적흐름도(CFD, Cumulative Flow Diagram)다. 시간에 따라 각 단계에 쌓인 일의 수를 누적 영역 그래프로 그린 것으로, 읽는 법은 단순하다.
- 밴드(띠)의 폭 = 그 단계의 WIP. 폭이 점점 넓어지면 그 단계가 병목이다.
- 유입선과 완료선의 수평 거리 ≈ 평균 리드타임.
- 두 선의 기울기 = 일이 들어오고 나가는 속도. 유입이 완료보다 가파르면 WIP가 계속 쌓인다.
벨로시티와 흐름 지표 중 무엇이 더 정직한 측정인지, 그리고 측정이 KPI가 되면 왜 망가지는지는 4편(실천과 측정)에서 본격적으로 다룬다.
5. Scrum vs Kanban — 언제 무엇을
둘은 양자택일이 아니다. 하지만 성격이 뚜렷이 다르니, 일의 종류에 맞춰 고르면 된다.
| 항목 | Scrum | Kanban |
|---|---|---|
| 리듬 | 고정 길이 스프린트(타임박스) | 연속 흐름, 고정 반복 없음 |
| 변경 수용 | 스프린트 중엔 범위 고정(목표 보호) | 우선순위 바뀌면 언제든 다음 항목 교체 |
| 역할 | PO·SM·개발자 규정 | 규정된 역할 없음(기존 역할 유지) |
| WIP 제한 | 스프린트 백로그가 암묵적 한도 | 컬럼별 명시적 WIP 제한 |
| 핵심 지표 | 벨로시티 | 리드타임·사이클타임·처리량 |
| 변화 방식 | 정해진 프레임워크를 도입 | 지금 하는 것에서 점진적 진화 |
| 잘 맞는 일 | 계획적 신규 기능 개발 | 불규칙 인입(운영·지원·버그·인프라) |
대략의 선택 기준은 이렇다.
- Scrum — 한 목표에 집중해 신규 기능을 계획적으로 만드는 팀. 리듬과 목표 보호가 도움이 된다.
- Kanban — 인입이 불규칙하고 우선순위가 자주 바뀌는 일. 운영·유지보수·지원·플랫폼 팀에 잘 맞는다.
현실에서는 둘을 섞은 Scrumban도 흔하다. Scrum의 역할·이벤트(스프린트·회고)는 유지하되, 보드에 컬럼별 WIP 제한과 풀(pull)을 들여오는 식이다. “스프린트는 좋은데 스프린트 중간에 일이 막히는 게 안 보인다” 싶을 때 자연스러운 절충이다.
중요한 건 프레임워크 이름이 아니다. Scrum이든 Kanban이든, 1편의 짧은 피드백 루프와 2편의 검사·적응을 실제로 돌리고 있는지가 본질이다.
정리
3편의 핵심을 한 줄씩 정리하면 다음과 같다.
- Kanban은 흐름을 관리한다 — 고정 반복 없이 흐름을 시각화하고 WIP를 제한한다. 불규칙하게 인입되고 우선순위가 자주 바뀌는 일에 강하다.
- 뿌리는 Lean이다 — 낭비를 없애고 밀어내기 대신 당겨오기로 일을 흘린다. WIP 제한이 그 당겨오기를 구체화한다.
- WIP 제한이 핵심 레버다 — Little’s Law(리드타임=WIP÷처리량)로 리드타임을 직접 줄이고, 멀티태스킹 세금을 줄여 처리량까지 올린다.
- 흐름 지표로 본다 — 리드타임·사이클타임·처리량·CFD. 벨로시티 대신 흐름의 속도와 병목을 직접 잰다.
- Scrum과 Kanban은 일의 종류로 고른다 — 계획적 기능 개발은 Scrum, 불규칙 인입은 Kanban, 섞으면 Scrumban. 본질은 프레임워크가 아니라 검사·적응 루프다.
다음 편은 실천과 측정이다. 지금까지가 “어떤 틀로 일하나”였다면, 4편은 “그 안에서 무엇을 어떻게 만드나(XP의 엔지니어링 프랙티스 — TDD·CI·리팩토링)“와 “그걸 어떻게 측정하나(스토리포인트·벨로시티의 함정·DORA)“를 다룬다. 특히 이번 편의 흐름 지표와 4편의 벨로시티·DORA가 만나, “측정이 KPI가 되면 왜 망가지는가”로 이어진다.
부록
A. 용어 정리
| 용어 | 한 줄 정의 |
|---|---|
| Lean(린) | 도요타 생산 방식에서 정리된, 낭비를 없애고 흐름을 끊지 않는 생산 철학 |
| 도요타 생산 방식(TPS) | 적시 생산·당겨오기·지속 개선을 핵심으로 하는 도요타의 생산 시스템 |
| 낭비(waste) | 가치를 더하지 않는 모든 것 — 미완 작업·불필요 기능·대기·작업 전환·재작업 |
| Kanban(看板) | 원래 도요타의 “더 채워라” 시각 신호 카드. 지식 노동에선 흐름을 시각화·관리하는 방법 |
| 풀 시스템(pull) | 뒤 단계가 여력이 생길 때만 앞에서 일을 당겨오는 방식(밀어내기 push의 반대) |
| WIP(Work In Progress) | 지금 동시에 진행 중인 일의 수. WIP 제한은 그 상한 |
| Little’s Law | 안정 상태에서 평균 리드타임 = 평균 WIP ÷ 평균 처리량이 성립한다는 항등식 |
| 리드타임 / 사이클타임 | 요청·착수부터 완료까지 / 실제 작업 시작부터 완료까지 |
| 처리량(throughput) | 단위 시간당 완료한 일의 수 |
| 누적흐름도(CFD, Cumulative Flow Diagram) | 시간에 따라 각 단계에 쌓인 일의 수를 누적 영역으로 그린 흐름 분석 그래프 |
| Scrumban | Scrum의 역할·이벤트에 Kanban의 흐름·WIP 제한을 섞은 하이브리드 |
B. 외부 참조
- Kanban: Successful Evolutionary Change (David J. Anderson) — Kanban 방법의 정립
- Lean Software Development (Mary & Tom Poppendieck) — Lean 7원칙의 소프트웨어 적용
- Little’s Law 개요 — 리드타임·WIP·처리량의 관계