스크럼과 칸반, 무엇이 다른가
두 방식은 자주 한데 묶여 불리지만 규칙의 구성이 다릅니다. 아래 표는 스크럼 가이드(2020)와 칸반 방법에 대한 일반 참고 자료(위키백과)에서 확인되는 내용만 간추린 것입니다.
| 비교 항목 | 스크럼 | 칸반(칸반 방법) |
|---|---|---|
| 핵심 단위 | 한 달 이하의 고정 길이 스프린트 | 보드 위를 흐르는 작업 항목 |
| 핵심 규칙 | 이벤트 5개(스프린트, 스프린트 계획, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고) | 작업 시각화, 진행 중 작업(WIP) 제한 |
| 역할 | 개발자, 프로덕트 오너, 스크럼 마스터의 3개 책임 | 새 역할을 규정하지 않음(자료에서 별도 역할 규정이 확인되지 않음) |
| 작업 투입 방식 | 스프린트 계획에서 스프린트 골과 함께 정함 | 용량이 허락할 때 다음 작업을 당겨 옴(풀 방식) |
| 유래 | 1986년 논문과 1990년대 소프트웨어 실무 | 1940~50년대 도요타 생산 현장 |
두 방식을 섞어 쓰는 팀도 있습니다. 2008년 코리 래다스가 낸 책 『스크럼반』은 칸반으로 스크럼을 개선하자는 제안으로 소개됩니다(위키백과 기준).
실제 사례 세 가지
사례 1. 워터폴이라는 이름의 뜻밖의 출발: 로이스의 1970년 논문 (오해의 사례)
애자일을 설명할 때 단골로 등장하는 비교 대상이 "워터폴(폭포수)" 방식, 즉 요구 분석에서 설계, 구현, 시험으로 단계가 순서대로 흘러가는 개발 방식입니다. 이 모델의 대표적 그림은 윈스턴 로이스가 1970년에 쓴 「대형 소프트웨어 시스템의 개발 관리」의 도식으로 알려져 있습니다. 그런데 위키백과 설명에 따르면 로이스는 이 순차 모델을 그대로 권한 것이 아니라, 시험을 맨 끝에서만 하면 위험하고 실패를 부른다고 지적하며 위험을 줄이는 추가 단계를 제안했습니다. "워터폴"이라는 이름 자체도 1976년 벨과 세이어의 논문에서 처음 쓰였을 가능성이 있다고만 서술되어 있습니다(해당 서술에는 더 나은 출처가 필요하다는 표시가 붙어 있음). 이 사례에서 배울 점은 용어가 퍼지는 과정에서 원래 주장이 단순화되기 쉽다는 것, 그리고 고객이 완성품을 보기 전에는 요구사항을 정확히 알기 어렵다는 순차 방식의 약점이 오래전부터 지적되어 왔다는 것입니다.
사례 2. 슈퍼마켓에서 공장으로: 도요타의 칸반 (제조업의 사례)
위키백과에 따르면 1940년대 말 도요타는 슈퍼마켓이 진열대를 채우는 방식을 연구했습니다. 손님이 상품을 집어 가면 그만큼만 다시 채우는 원리를 공장에 옮겨, 각 공정을 앞 공정의 "고객"으로 보았습니다. 이 논리는 1953년 도요타 본사 공장의 기계 가공 라인에 적용되었다고 합니다. 자재가 소비되면 그 신호가 상류 공정으로 전달되어 더 만들고 가져오게 하는 풀(pull) 방식이어서, 예측이 아니라 수요가 생산을 끌고 갑니다. 각 지점에 쌓이는 재고의 상한을 정하고 한도를 넘으면 해결할 문제의 신호로 읽는다는 발상이 지금의 WIP 제한과 이어집니다. 이 아이디어가 소프트웨어로 건너온 과정은 데이비드 앤더슨의 2010년 저서가 설명하는 2004년 마이크로소프트 프로젝트와 2006~2007년 코르비스 프로젝트로 소개됩니다. 다만 위키백과의 해당 서술에는 출처가 더 필요하다는 표시가 있어, 정확한 계보는 원 자료를 확인하는 편이 안전합니다.
사례 3. 100년 넘은 막대 그래프: 간트 차트의 계보 (도구의 사례)
간트 차트라는 이름은 헨리 간트(1861~1919)에서 왔지만, 위키백과는 폴란드의 카롤 아다미에츠키가 1896년에 "이런 종류의 첫 도구"인 하르모노그람을 만들었다고 정리합니다. 그는 러시아어와 폴란드어로만 발표해 널리 알려지지 못했습니다. 간트는 1910~1915년경 일상적 작업의 생산성을 재는 목적으로 차트를 설계했고, 제1차 세계대전 중 미국이 초기 주요 활용 사례로 꼽힙니다. 1929년에는 간트의 협력자 월터 폴라코프가 소련에 소개해 제1차 5개년 계획 수립에 쓰였다고 합니다. 1980년대 개인용 컴퓨터와 1990년대 말 웹 도구가 보급되면서 누구나 쓰는 도구가 되었습니다. 한계도 같은 자료에 적혀 있습니다. 일정의 가정을 "평평하게" 보여 주어 불확실성과 변경에 대응하기 어렵고, 의존 관계를 선으로 이으면 금방 복잡해집니다. 그럼에도 널리 쓰인 이유는 대안이 없었던 탓이 클 수 있다는 해석도 함께 소개됩니다. 이 사례에서 배울 점은 널리 쓰인다는 사실과 그 도구가 모든 상황에 적합하다는 사실은 다르다는 것입니다.
직접 해보기: 우리 팀 용어 점검표
- 용어 맞추기: 팀원 각자 "스프린트", "마일스톤", "완료"를 한 문장으로 적어 비교해 봅니다. 서로 다르면 그 차이를 먼저 합의합니다.
- 백로그 정리하기: 해야 할 일을 한곳에 모아 순서를 매깁니다. 스크럼 가이드는 프로덕트 백로그를 "순서가 매겨지고 계속 다듬어지는 목록"으로 설명합니다.
- 보드 만들기: 할 일 / 진행 중 / 완료 세 열로 시작하고, '진행 중' 열에 동시에 둘 수 있는 카드 수의 상한(WIP 제한)을 팀이 정해 봅니다. 상한이 가득 차면 새 일을 당기기 전에 막힌 일을 먼저 풉니다.
- 짧은 공유 회의 규칙: 매일 짧은 회의를 연다면 시간 상한과 진행 방식을 팀이 정해 둡니다. 스크럼 가이드는 데일리 스크럼을 15분으로 두되, 진행 구조는 개발자가 고르도록 합니다.
흔한 오해와 정정
- 오해: 애자일은 계획이나 문서를 하지 않는 방식이다. 실제: 애자일 선언은 "포괄적 문서보다 동작하는 소프트웨어"처럼 무엇을 더 중시하는지를 말할 뿐, 대비되는 항목에도 가치가 있다고 밝힙니다.
- 오해: 애자일과 스크럼은 같은 말이다. 실제: 애자일은 가치와 원칙이고, 스크럼은 그 정신을 구현하는 여러 방법 중 하나입니다.
- 오해: 데일리 스크럼은 반드시 "어제·오늘·장애" 세 질문으로 한다. 실제: 2020년판 스크럼 가이드는 개발자가 원하는 구조와 기법을 고르게 하고, 스프린트 골을 향한 진행에 초점을 맞추도록만 요구합니다.
- 오해: 스프린트는 1~4주 사이면 된다. 실제: 가이드의 규정은 "한 달 이하의 고정 길이"입니다. 그 안에서 며칠~몇 주로 할지는 팀이 정합니다.
- 오해: 워터폴은 로이스가 권장한 모델이다. 실제: 위키백과 설명에 따르면 로이스는 순차 모델의 위험을 지적하며 보완을 제안한 쪽이었습니다.
한계와 논쟁
애자일의 효과를 뒷받침하는 증거는 상당 부분 일화적이고 결정적이지 않다는 평가가 위키백과에 서술되어 있습니다. 의료기기나 항공처럼 규제가 엄격한 분야에서는 초기에 부적합하다는 시각이 있었고, 이후 적응 방안이 개발되었다고 합니다. 스크럼에 대해서는 이벤트가 생산적 작업 시간을 잡아먹는다는 비판, 시간제 팀이나 분산 팀에서 적용이 어렵다는 지적이 있습니다. 한 체계적 문헌 검토는 분산 스크럼이 프로젝트 성공에 뚜렷한 영향이 없었다고 정리한 것으로 소개됩니다. 애자일 선언 서명자였던 마틴 파울러와 론 제프리스도 형식만 흉내 낸 "가짜 애자일" 적용을 비판해 왔습니다. 이 글은 일반적인 설명이며, 특정 조직의 방법론 도입 판단에는 스크럼 가이드·애자일 선언 같은 원 자료와 팀 상황을 함께 살펴보셔야 합니다.
자주 묻는 질문
스크럼과 칸반은 어떻게 다른가요?
스크럼은 한 달 이하의 고정 길이 스프린트와 정해진 이벤트·책임을 가진 틀이고, 칸반은 작업을 보드에 시각화하고 진행 중 작업 수를 제한하며 흐름을 관리하는 방식입니다. 둘을 함께 쓰는 팀도 있습니다.
스탠드업 미팅은 왜 서서 진행하나요?
앉아서 하는 회의보다 길어지는 것을 막으려는 관습으로 설명되곤 합니다. 스크럼 가이드는 서서 하라고 규정하지 않고 15분이라는 시간 상한과 목적(스프린트 골을 향한 진행 점검)만 정합니다.
백로그는 단순한 할 일 목록과 무엇이 다른가요?
스크럼 가이드는 프로덕트 백로그를 "순서가 매겨지고 계속 다듬어지는 목록"이자 팀 작업의 단일 출처로 설명합니다. 즉 순서를 매기고 계속 유지·갱신한다는 점이 핵심입니다.
마일스톤과 스프린트 골은 같은 것인가요?
다릅니다. 마일스톤은 프로젝트 진행 중 특정 단계의 완료를 나타내는 이정표이고, 스프린트 골은 스크럼 가이드에서 한 스프린트의 "단일 목표"를 뜻합니다. 쓰이는 틀과 범위가 다른 용어입니다.
애자일을 도입하면 간트 차트는 쓰지 못하나요?
간트 차트는 일정을 보여 주는 도구이지 방법론이 아니므로 사용 여부는 팀이 정합니다. 다만 위키백과는 간트 차트가 일정의 가정을 평평하게 보여 변화에 대응하기 어려운 한계가 있다고 지적하므로, 변경이 잦은 일에는 그 한계를 염두에 두는 것이 좋습니다.
이어서 읽어 보세요
- 칸반 보드 가이드: 보드 구성과 흐름 관리를 더 자세히
- 간트 차트 가이드: 일정표 읽고 만드는 법
- KPI 설정 실무 가이드: 목표를 측정 가능한 지표로 바꾸기
- 비즈니스 필수 약어 완전정복: 회사에서 자주 쓰는 다른 약어