인프라팀이 스크럼을 도입했습니다. 그런데 2주 스프린트 셋째 날, 프로덕션 장애와 긴급 보안 패치 요청이 동시에 들어옵니다. 스프린트에 약속한 작업은 그대로인데 긴급 일이 밀려듭니다. "이걸 어느 스프린트에 넣죠?"가 매번 반복됩니다. 같은 애자일이라도 일의 성격에 따라 맞는 틀이 다릅니다. 스크럼이 안 맞는 자리에 스크럼을 욱여넣으면 팀이 지칩니다. 방법론은 신념이 아니라 도구 — "이 일에는 무엇이 맞나"를 판단하는 것이 핵심입니다.
- 1칸반·스크럼·워터폴을 "주기·약속·변화 대응" 축으로 구분할 수 있다
- 2WIP 제한이 흐름을 개선하는 원리를 설명할 수 있다
- 3업무 성격(예측 가능 vs 유입 불규칙)에 따라 적합한 방식을 고를 수 있다
- 4워터폴이 여전히 합리적인 상황을 식별할 수 있다
세 가지 방식, 한눈에 비교
주기·약속·변화 대응으로 가르는 세 방식
세 방식은 "일을 어떤 주기로, 무엇을 약속하며, 변화에 어떻게 대응하는가"가 다릅니다.
| 기준 | 워터폴 | 스크럼 | 칸반 |
|---|---|---|---|
| 주기 | 한 번에 길게 순차 | 고정 스프린트(2주) | 연속 흐름(주기 없음) |
| 약속 단위 | 전체 범위·일정 | 스프린트 단위 커밋 | 약속 없음, 우선순위 큐 |
| 변화 대응 | 어렵다(후반 변경 비쌈) | 스프린트 경계에서 | 언제든 다음 카드 교체 |
| 적합 | 요구 확정·규제·하드웨어 | 제품 개발·예측 가능한 팀 | 운영·지원·유입 불규칙 |
| 핵심 도구 | 단계 게이트·문서 | 스프린트·번다운 | 보드·WIP 제한 |
핵심: 방법론은 일의 성격에 맞춘다. 제품 기능 개발은 스크럼이, 인프라 운영·장애 대응은 칸반이 자주 맞습니다. 둘을 섞은 '스크럼반(Scrumban)'도 흔합니다.
확대
위 그림처럼 워터폴·스크럼·칸반은 같은 "애자일" 계열이라도 주기·약속 단위·변화 대응 방식이 완전히 다릅니다. 방법론 선택은 신념이 아니라 일의 성격에 맞추는 것입니다.
WIP 제한 — 칸반의 심장
동시에 적게 붙잡아야 더 빨리 끝난다
칸반의 핵심은 보드 시각화 + WIP(진행 중 작업) 제한입니다. "In Progress: 최대 3" 같은 한도를 둡니다.
To Do In Progress (WIP≤3) Done
[A][B][C] [D][E][F] ← 꽉 참 [X][Y]
[G]...
→ G를 시작하려면? 못 한다. In Progress가 한도(3).
→ D/E/F 중 하나를 '끝내야' G를 당겨온다.
→ 즉, "시작"보다 "완료"를 강제 → 흐름이 빨라지고 병목이 보인다.
WIP를 제한하면 ① 잦은 컨텍스트 전환이 줄고 ② 한 단계가 막히면 즉시 드러나며 ③ 팀이 '끝내기'에 집중합니다. 무제한으로 일을 벌이면 모두가 바쁘지만 아무것도 완성되지 않는 상태가 됩니다 — 운영팀이 흔히 빠지는 함정입니다.
확대
위 그림처럼 In Progress 한도에 카드가 꽉 찬 상태에서 Code Review 단계 체류 시간이 길어지면, 그 병목이 즉시 보드에 드러납니다. WIP 제한은 "가장 바쁜 단계"가 아니라 "가장 막힌 단계"를 찾아 자원을 집중하게 합니다.
확대
위 그림처럼 업무 성격(유입 불규칙 여부, 예측 가능성, 요구 확정 여부)에 따라 적합한 방법론이 결정됩니다.
보드의 병목 읽기 — 직접 확인
칸반 보드는 카드가 어디 쌓이는지로 병목을 드러냅니다. PM·인프라는 단계별 카드 수와 체류 시간으로 흐름의 건강을 읽습니다.
단계 카드수 평균 체류
To Do 12 -
In Progress 3 1.5일 ← WIP 한도 3, 정상
Code Review 8 4일 ← 여기 쌓임! 병목
Done 20 -
해석: 개발은 끝나는데 'Code Review'에서 4일씩 묶임
→ 리뷰어 부족/리뷰 우선순위 낮음. 흐름 전체가 여기서 막힘.
echo '단계별 카드 수 + 체류시간 확인'- 카드가 가장 많이 쌓이고 체류시간이 긴 단계가 병목 — 위 예에선 Code Review. 흐름 개선은 가장 바쁜 단계가 아니라 "가장 막힌 단계"를 푸는 것
- In Progress가 WIP 한도에 상시 닿아 있고 To Do만 쌓이면 → 처리 능력 < 유입. 인력 보강 또는 유입(범위) 조절 신호
- 리뷰/배포 단계 체류가 길면 → 그 활동의 담당·우선순위 문제. 인프라라면 "배포 대기"가 병목인지 확인(자동화로 해소 가능)
- 긴급 건이 자주 끼어들어 계획 작업이 안 끝나면 → 긴급 전용 레인(swimlane)과 WIP를 분리해 일반 흐름 보호
상황: 제품팀과 보조를 맞추려 인프라/운영팀에도 2주 스프린트를 도입했는데, 장애·긴급 요청이 끊임없이 끼어들어 매 스프린트 약속을 못 지킵니다. "또 못 끝냈다"가 반복되며 팀이 무력감을 느낍니다.
원인: 운영성 업무는 유입이 불규칙하고 우선순위가 수시로 바뀝니다. 고정 스프린트의 '미리 약속' 모델과 근본적으로 맞지 않습니다. 방법론을 일의 성격이 아니라 '통일성'을 위해 강제한 것이 문제입니다.
진단 — 점검:
□ 들어오는 일의 50% 이상이 계획에 없던 긴급/임시인가?
□ 스프린트 커밋을 3회 연속 못 지켰는가?
□ 우선순위가 스프린트 중간에 자주 뒤집히는가?
세 개 중 둘 이상이면 스크럼이 안 맞는 업무입니다.
해결: 운영팀은 칸반으로 전환합니다 — 우선순위 큐 + WIP 제한 + 긴급 레인. 약속 단위를 없애고 '흐름'을 관리하면, 긴급 건이 와도 다음 카드를 당겨오는 자연스러운 모델이 됩니다. 제품과의 동기화는 주간 리뷰로 맞춥니다. "모두 같은 방법론"이 아니라 "각 팀에 맞는 방법론"이 협업을 살립니다.
심화 — 칸반은 규율이 빠지면 '그냥 할 일 보드'로 퇴화한다
심화: WIP 한도가 장식이 되는 순간 — 칸반 퇴화의 신호와 처방
스크럼은 안 돌아가면 세리머니가 삐걱거려서 시끄럽게 티가 납니다. 칸반은 반대로 조용히 죽습니다 — 강제하는 리듬이 없기 때문에, 몇 가지 규율이 무너져도 보드는 그대로 걸려 있고 아무도 이상함을 못 느낍니다. 퇴화의 신호와 처방을 알아야 칸반을 칸반으로 유지할 수 있습니다.
- WIP 한도가 장식이 됨: 'In Progress ≤ 3'이라 써 놓고 카드 5장이 걸려 있어도 아무 일도 일어나지 않으면, 그것은 칸반이 아니라 그냥 보드입니다. 한도 초과를 '규칙 위반 딱지'가 아니라 "지금 무엇부터 끝내야 하나"라는 팀 대화의 트리거로 운영해야 한도가 살아 있습니다.
- 긴급 레인 인플레이션: 긴급 레인이 생기면 요청자마다 자기 건을 긴급이라 부르기 시작합니다. 처방은 정원(예: 동시 1장)과 투입 기준·투입 권한자를 보드에 명문화하고, 월간 긴급 비율을 재는 것 — 20%를 넘으면 레인의 문제가 아니라 유입 관리의 실패입니다.
- 컬럼 정책 부재: '리뷰로 넘기는 조건', 'Done의 조건'이 사람마다 다르면 팀은 같은 보드를 보며 서로 다른 이야기를 합니다. 각 컬럼의 통과 조건을 보드에 명시(explicit policy)해야 카드 위치가 정보가 됩니다.
- 케이던스 부재로 보드가 썩음: 스프린트 같은 강제 주기가 없으므로, 보충(replenishment)·정리 리듬을 명시적으로 정하지 않으면 3주째 안 움직이는 카드와 영원한 blocked가 쌓입니다. 주 1회 보충 미팅과 'N일 이상 정체 카드 스윕'을 팀의 케이던스로 못 박아야 합니다.
- '언제 돼요?'에 답하는 법: 칸반의 예측 도구는 velocity가 아니라 사이클 타임 분포입니다. "이 유형 카드의 85%는 9일 안에 끝났습니다"처럼 분포로 답하면, 스프린트 약속 없이도 이해관계자에게 예측을 줄 수 있습니다 — 운영팀이 처리 기한 약속(SLA)을 걸 때의 근거가 바로 이것입니다.
정리하면, 칸반 도입은 보드를 거는 일이 아니라 정책과 케이던스를 설치하는 일입니다. 보드만 걸면 몇 달 안에 반드시 퇴화합니다.
상황: 스크럼이 안 맞아 칸반으로 전환한 운영팀. 석 달 뒤 보드를 보니 In Progress에 카드 14장(명목 한도 4), 그중 6장은 2주째 그대로이고, 절반에 '긴급' 라벨이 붙어 있습니다. 주간 회의에서 "그 티켓 언제 되나요?"라는 질문에 돌아오는 답은 "보드에 올라가 있어요"뿐입니다.
원인: 칸반의 형식(보드)만 도입하고 규율(WIP 강제, 컬럼 정책, 케이던스)은 도입하지 않았습니다. 한도 초과를 아무도 막지 않으니 '일단 시작'이 쌓였고, 긴급의 기준이 없으니 요청자마다 긴급을 붙였으며, 보충·정리 리듬이 없으니 죽은 카드가 보드에 그대로 남았습니다.
진단: 누적 흐름 다이어그램(CFD)에서 In Progress 밴드가 계속 넓어지는지 확인합니다 — 유입이 완료를 초과한다는 증거입니다. 카드별 마지막 업데이트 일자로 5일 이상 정체 카드를 집계하고, 긴급 라벨 비율을 계산합니다(이 팀은 48%였고, 그 시점에 '긴급'은 이미 아무 정보도 담고 있지 않았습니다).
해결: 한 번의 대청소가 아니라 규율의 재설치가 필요합니다 — ① In Progress를 실제 진행 중인 4장만 남기고 나머지는 To Do로 되돌립니다(시작 취소는 실패가 아닙니다) ② 긴급 레인 정원 1장과 투입 기준을 보드에 명문화합니다 ③ 주 1회 보충 미팅을 고정하고 7일 정체 카드는 자동 에스컬레이션합니다 ④ 사이클 타임을 재기 시작해 '언제 되냐'에 분포로 답합니다. 이 팀은 한 달 뒤 평균 사이클 타임이 11일에서 4일로 줄었습니다 — 일을 덜 받아서가 아니라, 덜 벌려서입니다.
인프라/SRE 팀을 운영한다면, 이 모듈의 판단이 팀의 지속가능성을 좌우합니다. 장애·티켓·요청이 불규칙하게 들어오는 운영 업무에 칸반(WIP 제한·긴급 레인)을 적용하면, 팀이 과부하 없이 흐름을 유지하고 병목(예: 배포 승인 대기)을 데이터로 드러내 자동화 우선순위를 정할 수 있습니다. PM은 제품팀(스크럼)과 운영팀(칸반)이 서로 다른 리듬으로 돌아가도, 주간 동기화 지점에서 의존성을 맞추도록 조율합니다. 방법론을 신념이 아니라 도구로 다루는 것 — 그것이 성숙한 조직의 표시입니다.
이것으로 Phase 1(개발의 큰 그림)을 마칩니다. 다음 Phase에서는 이 흐름의 출발점 — 요구사항을 정의하고(PRD·유저스토리) 우선순위를 매기는 제품관리 실무를 다룹니다.
실전 랩으로 손에 익히기: 방법론 선택 실습 — 프로젝트 성격을 진단해 스크럼·칸반·워터폴을 근거 있게 고릅니다.
관련 모듈로 더 깊이:
- 애자일과 스크럼 — 스크럼의 스프린트·역할·세리머니를 자세히
- SDLC — 이 방법론들이 놓이는 전체 개발 생애주기
- 로드맵과 이슈 트래킹 — 칸반 보드·이슈 트래킹으로 흐름을 가시화하는 도구