Scrum vs 칸반: 차이점, 그리고 작은 팀에 맞는 쪽은
Weft 창업자 Andrei Finogeev ·
Scrum은 한 달 이하의 고정된 스프린트로 일을 계획하고, 세 가지 책임(Product Owner, Scrum Master, 개발자)과 스프린트마다 네 가지 이벤트가 있습니다. 칸반에는 스프린트도, 정해진 역할도 없습니다. 일은 보드 위를 끊임없이 흐르고, 팀은 진행 중인 일의 양을 명시적으로 제한합니다. 여러 명의 팀에 고정된 전달 리듬과 주기마다 안정적인 목표가 필요하면 Scrum을, 일이 예측할 수 없게 들어오고 우선순위가 매일 바뀌면 칸반을 고르세요. Scrumban은 그 사이에 있습니다. 칸반의 흐름에, 도움이 될 때만 스프린트를 더합니다.
Scrum vs 칸반 vs Scrumban: 한눈에 보는 비교표
Scrum은 2020년 스크럼 가이드의 정의를, 칸반은 칸반 가이드(v2025.5)의 정의를 따릅니다. Scrumban에는 공식 가이드가 없어서, 그 열은 보통 어떻게 운영되는지를 설명합니다.
| Scrum | 칸반 | Scrumban | |
|---|---|---|---|
| 리듬 | 한 달 이하의 고정된 스프린트를 연달아 진행 | 연속적인 흐름, 반복 주기 없음 | 연속적인 흐름. 스프린트는 선택이며 보통 1~2주 |
| 역할 | Product Owner, Scrum Master, 개발자 | 정해진 것 없음 | 정해진 것 없음. 우선순위는 한 사람이 맡는 경우가 많음 |
| 회의 | 스프린트 계획, 데일리 스크럼(15분), 스프린트 리뷰, 스프린트 회고 | 정해진 것 없음 | 팀이 쓸모 있다고 느끼는 것만. 보통 계획과 리뷰 |
| 일의 양을 제한하는 것 | 팀이 그 스프린트에 하기로 한 범위 | 진행 중 작업에 대한 명시적인 제한 | 진행 중 작업 제한, 그리고 있다면 스프린트 목표 |
| 주기 중간의 범위 변경 | 스프린트 목표는 고정. 스프린트 백로그는 다듬을 수 있음 | 언제든지: 자리가 나면 다음 항목을 당겨 옴 | 언제든지. 스프린트 목표는 과녁이지 자물쇠가 아님 |
| 주요 지표 | 스프린트 목표와 제품 목표를 향한 진척 | 진행 중 작업, 처리량, 작업 항목 경과 시간, 사이클 타임 | 보통 칸반의 흐름 지표 |
| 보드 | 선택. 스프린트마다 초기화 | 방법의 핵심. 계속 유지됨 | 계속 유지됨. 스프린트는 그 일부를 잘라 낸 것 |
| 가장 잘 맞는 곳 | 하나의 목표를 향해 만드는 10명 안팎의 제품 팀 | 지원, 운영, 그리고 계획에 없던 일이 들어오는 모든 사람 | 흐름과 단기 목표를 함께 원하는 작은 팀과 1인 창업자 |
Scrum이란
Scrum은 1995년 OOPSLA 콘퍼런스에서 Ken Schwaber와 Jeff Sutherland가 처음 발표했고, 오늘날의 규칙은 2020년 스크럼 가이드입니다. 스크럼 팀은 보통 10명 이하이고, 스프린트 단위로 일합니다. 스프린트는 한 달 이하의 고정된 길이를 가진 이벤트로, 앞 스프린트가 끝나자마자 시작됩니다.
스프린트마다 네 가지 이벤트가 있습니다. 스프린트 계획(한 달짜리 스프린트에서 최대 8시간)에서 스프린트 목표를 정하고 일을 고릅니다. 데일리 스크럼은 개발자를 위한 15분짜리 점검입니다. 스프린트 리뷰(최대 4시간)는 결과를 이해관계자에게 보여 주고, 스프린트 회고(최대 3시간)는 팀이 어떻게 일했는지 돌아봅니다.
Scrum에는 세 가지 산출물이 있고, 각각 약속이 하나씩 붙습니다. 제품 백로그(제품 목표), 스프린트 백로그(스프린트 목표), 인크리먼트(완료의 정의)입니다.
칸반이란
칸반 가이드는 칸반을 "프로세스를 통한 가치의 흐름을 최적화하기 위한 전략"으로 정의합니다. 도요타가 더 생산할 때를 알리려고 쓴 카드 시스템에서 왔고, 2000년대에 지식 노동에 맞게 바뀌었습니다.
실천은 세 가지입니다. 워크플로를 정의하고 시각화하기, 그 안의 항목을 능동적으로 관리하기, 그리고 워크플로를 개선하기. 단 하나의 엄격한 규칙은 시스템 안의 사람들이 시작과 완료 사이에 있는 항목 수를 명시적으로 통제하는 것, 즉 진행 중 작업(WIP) 제한입니다.
칸반은 역할도, 스프린트도, 회의도 정하지 않습니다. 추적하는 것은 네 가지 흐름 지표, 곧 진행 중 작업, 처리량, 작업 항목 경과 시간, 사이클 타임입니다.
장단점
Scrum
- 고정된 리듬: 다음 결과가 언제 나오는지 모두가 앎
- 스프린트마다 분명한 목표가 팀이 표류하지 않게 잡아 줌
- 제품과 프로세스를 점검하는 시점이 내장되어 있음
- 스프린트마다 네 가지 이벤트는 2~3명 팀에게 실제 시간 비용
- 급한 일은 다음 스프린트까지 기다리거나 계획을 깨뜨림
- 책임마다 사람이 필요한데, 창업자 한 명은 그걸 나눌 수 없음
칸반
- 이미 가진 보드에서 바로 시작. 설치할 것은 WIP 제한뿐
- 새 일을 언제든 당겨 올 수 있음
- 흐름 지표로 일이 어디서 막히는지 보임
- 기한이나 목표가 내장되어 있지 않아 오래 걸리는 일은 표류할 수 있음
- WIP 제한이 없으면 컬럼 달린 할 일 목록일 뿐
- 앞날 계획은 전적으로 팀 몫
무엇을 고를까
- 로드맵이 안정적인 5~10명의 제품 팀
- Scrum. 여러 사람이 2주쯤마다 하나의 목표에 합의해야 할 때 이벤트는 들인 시간만큼 값을 합니다.
- 지원, 운영, 또는 들어오는 요청으로 돌아가는 팀
- 칸반. 일은 올 때 옵니다. 스프린트 계획보다 WIP 제한과 분명한 Done 컬럼이 더 중요합니다.
- 1인 창업자 또는 2~5명의 팀
- Scrumban. WIP 제한이 있는 연속적인 보드를 두고, 1~2주 스프린트를 단기 목표로 쓰세요. Scrum 이벤트를 전부 갖출 필요는 없습니다.
Scrumban: 중간 지점
Scrumban은 Scrum 팀이 당겨 오는(pull) 흐름으로 옮겨 가는 방법으로 Corey Ladas가 설명한 것입니다. 실제로는 초기화되지 않는 WIP 제한 칸반 보드에, 일의 일부를 묶는 선택적인 타임박스로 스프린트를 더한 것입니다. 규칙과 보드 설정 방법은 전체 가이드에 정리했습니다: Scrumban이란?
AI 에이전트가 일의 일부를 할 때
ChatGPT, Claude, Cursor, Codex가 당신 대신 작업을 맡는다면 Scrum의 이벤트에는 참석할 사람이 없습니다. 에이전트는 스탠드업에 오지 않으니까요. 그래도 중요한 것은 칸반이 주는 것들입니다. 무엇이 진행 중인지 보여 주는 보드, 작업 열 개가 한꺼번에 시작되지 않게 하는 WIP 제한, 그리고 카드가 언제 끝난 것인지에 대한 분명한 규칙.
병목도 옮겨 갑니다. 에이전트는 일을 빨리 끝내고, 느린 단계는 그들이 한 일에 대한 당신의 검토가 됩니다. 당신을 기다릴 수 있는 완료된 작업의 양에 제한을 두는 것은 사람 컬럼에 대한 WIP 제한입니다.
Weft는 바로 이를 위해 만든 Scrumban 보드입니다. 컬럼, 선택적인 스프린트, 당신의 검토를 기다릴 수 있는 완료 작업의 양에 대한 제한이 있고, AI는 시작하기 전에 작업을 맡고, 진행을 보고하고, 당신만 정할 수 있는 일이 있으면 멈추고 묻습니다.
자주 묻는 질문
Scrum과 칸반은 같은 건가요?
아니요. 둘 다 애자일 방식이고 둘 다 보드를 자주 쓰지만, Scrum은 역할과 이벤트가 정해진 고정 스프린트로 일을 계획하고, 칸반은 연속적인 흐름에 정해진 역할이 없으며 진행 중 작업에 명시적인 제한을 둡니다.
칸반에서도 스프린트를 하나요?
칸반 자체로는 아닙니다. 칸반 가이드는 반복 주기를 정하지 않습니다. 칸반 보드에 스프린트를 더하는 팀은 보통 Scrumban을 하고 있는 것입니다.
Scrum 스프린트는 어떻게 진행되나요?
스프린트는 한 달 이하의 고정된 기간입니다. 스프린트 목표를 정하는 스프린트 계획으로 시작하고, 개발자는 15분짜리 데일리 스크럼으로 모이며, 결과를 보는 스프린트 리뷰와 프로세스를 돌아보는 스프린트 회고로 끝난 뒤 다음 스프린트가 바로 시작됩니다.
Scrumban은 누가 만들었나요?
이 용어는 Corey Ladas가 만든 것으로 알려져 있습니다. 그는 에세이와 2009년 책에서 Scrum 팀이 칸반식 당겨 오기(pull)로 옮겨 가는 방법으로 Scrumban을 설명했습니다.
Scrum은 애자일과 같은 건가요?
아니요. 애자일은 2001년 애자일 선언에 담긴 가치와 원칙이고, Scrum과 칸반은 그것을 따르는 구체적인 일하는 방식 두 가지입니다.
혼자 일하는 개발자도 Scrum을 쓸 수 있나요?
쓰인 그대로는 어렵습니다. Scrum은 세 가지 책임이 따로 있는 팀을 전제로 합니다. 혼자 일하는 개발자는 보통 도움이 되는 부분 — 백로그와 짧은 스프린트 목표 — 만 남기고 보드는 칸반처럼 운영합니다. 그게 바로 Scrumban입니다.
출처
2026년 11월 11일에 읽음.