💡 핵심 인사이트
칸반(Kanban)은 도요타 자동차 공장의 재고 관리 시스템에서 유래한 애자일 방법론으로, 거대한 화이트보드(칸반 보드)에 업무 티켓을 붙여 팀의 모든 작업 흐름(Workflow)을 한눈에 시각화하는 것이 특징입니다.
핵심은 개발자들이 과로로 쓰러지지 않고 병목 현상을 막기 위해, 각 작업 단계마다 들어갈 수 있는 티켓의 개수를 엄격히 제한하는 'WIP(진행 중인 작업) 제한' 룰입니다.
Ⅰ. 칸반 보드의 구조 (시각화)
스크럼이 '2주 단위의 엄격한 타임박스(스프린트)'에 갇혀 돌아간다면, 칸반은 스프린트 같은 고정된 기간이 없습니다. 파이프라인에 물이 흐르듯 끊임없이 티켓이 왼쪽에서 오른쪽으로 흘러가는 연속적인 흐름(Continuous Flow) 모델입니다.
사무실 벽이나 지라(Jira), 트렐로(Trello)에 다음과 같은 열(Column)을 가진 칸반 보드를 만듭니다.
[ To Do (할 일) ] [ In Progress (개발 중) ] [ Review (코드 검토) ] [ Done (완료) ]
[티켓1] [티켓3] [티켓5] [티켓6]
[티켓2] [티켓4] [티켓7]
개발자는 아침에 출근해서 'To Do'에 있는 티켓 하나를 집어 'In Progress' 칸으로 드래그하고 코딩을 시작합니다. 개발이 끝나면 'Review' 칸으로 넘기는 식입니다. 이 보드 하나만 보면, 팀장이나 PM은 "아, 지금 리뷰 단계에 일감이 잔뜩 쌓여서 배포가 안 나가고 있구나"라는 병목(Bottleneck) 구간을 1초 만에 시각적으로 발견할 수 있습니다.
Ⅱ. 칸반의 영혼: WIP 제한 (Work In Progress Limit)
단순히 포스트잇을 옮기는 것은 칸반이 아닙니다. 칸반을 칸반이게 만드는 유일무이한 규칙이 바로 WIP(진행 중인 작업) 제한입니다.
WIP 제한의 원리와 효과
- 룰: 칸반 보드의 각 열(Column) 머리맡에 수용할 수 있는 티켓의 최대 개수를 적어둡니다.
- 예:
[In Progress (최대 3개)],[Review (최대 2개)] - 상황: 팀원 4명이 'In Progress' 칸에서 3개의 티켓을 개발 중입니다(WIP 한계 도달). 이때 코딩이 끝난 개발자 A가 잉여 시간이 남았습니다.
- 전통적 방식(Push): A는 'To Do'에서 새로운 티켓 4번째를 집어와서 개발을 시작합니다. 결국 개발 중인 미완성 코드가 산더미처럼 쌓이고 리뷰팀이 터져 나갑니다.
- 칸반 방식 (Pull 시스템): WIP 제한이 3개이므로 A는 절대 새로운 티켓을 가져올 수 없습니다. 대신 A는 코딩을 멈추고, 병목이 터지고 있는 'Review' 칸으로 달려가서 동료들의 코드를 리뷰해 주어 막힌 배수관을 뚫어냅니다(우측으로 물을 빼냄).
- 결과: "하던 일 마저 끝내라(Stop starting, Start finishing)." 여러 개를 동시에 만지작거리는 멀티태스킹의 비효율을 극단적으로 막고, 기능이 100% 완료되어 라이브 서버에 배포되는 사이클 속도를 엄청나게 앞당깁니다.
Ⅲ. 스크럼 vs 칸반 (어느 팀에 적합한가?)
- 스크럼 (Scrum): 2주라는 고정된 일정을 지켜야 하며, 그사이에 요구사항 변경이 절대 불가합니다. 계획이 뚜렷한 신규 프로덕트 개발팀에 적합합니다.
- 칸반 (Kanban): 고정된 스프린트가 없고 요구사항을 수시로 꼈다 뺐다 할 수 있습니다. 매일매일 어디서 에러가 터질지 모르는 IT 운영/유지보수(SM) 팀이나 헬프데스크, 긴급 장애 대응팀에 완벽하게 들어맞습니다. (장애 티켓이 생기면 맨 위에 붙이고 즉시 처리하면 됨).
📢 섹션 요약 비유: 스크럼이 정해진 코스(2주) 요리를 코스 순서대로 한상차림으로 내놓는 고급 레스토랑이라면, 칸반은 뷔페식 **'회전초밥집'**입니다. 주방장은 한 번에 접시 5개(WIP 제한)까지만 레일 위에 올릴 수 있으며, 손님(고객)이 초밥 하나를 먹어 치워야만(Done) 비로소 새 초밥 하나를 만들어 낼 수 있는 엄격한 컨베이어 벨트 흐름 통제 시스템입니다.