인프라팀이 스크럼을 도입했습니다. 그런데 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를 제한하면 ① 잦은 컨텍스트 전환이 줄고 ② 한 단계가 막히면 즉시 드러나며 ③ 팀이 '끝내기'에 집중합니다. 무제한으로 일을 벌이면 모두가 바쁘지만 아무것도 완성되지 않는 상태가 됩니다 — 운영팀이 흔히 빠지는 함정입니다.
보드의 병목 읽기 — 직접 확인
칸반 보드는 카드가 어디 쌓이는지로 병목을 드러냅니다. 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 제한 + 긴급 레인. 약속 단위를 없애고 '흐름'을 관리하면, 긴급 건이 와도 다음 카드를 당겨오는 자연스러운 모델이 됩니다. 제품과의 동기화는 주간 리뷰로 맞춥니다. "모두 같은 방법론"이 아니라 "각 팀에 맞는 방법론"이 협업을 살립니다.
인프라/SRE 팀을 운영한다면, 이 모듈의 판단이 팀의 지속가능성을 좌우합니다. 장애·티켓·요청이 불규칙하게 들어오는 운영 업무에 칸반(WIP 제한·긴급 레인)을 적용하면, 팀이 과부하 없이 흐름을 유지하고 병목(예: 배포 승인 대기)을 데이터로 드러내 자동화 우선순위를 정할 수 있습니다. PM은 제품팀(스크럼)과 운영팀(칸반)이 서로 다른 리듬으로 돌아가도, 주간 동기화 지점에서 의존성을 맞추도록 조율합니다. 방법론을 신념이 아니라 도구로 다루는 것 — 그것이 성숙한 조직의 표시입니다.
이것으로 Phase 1(개발의 큰 그림)을 마칩니다. 다음 Phase에서는 이 흐름의 출발점 — 요구사항을 정의하고(PRD·유저스토리) 우선순위를 매기는 제품관리 실무를 다룹니다.