Scrum vs Kanban: 육상 선수와 회전 초밥

프롤로그 - "우리도 애자일 해야 하는 거 아냐?"

스타트업을 시작하고 처음 스프린트를 돌리려던 날, 이런 고민이 시작됐다:

"우리도 요즘 다들 하는 애자일(Agile) 개발 해보자!"

나: "좋아, 그런데 그게 뭔데?"

구글링: "...Scrum이나 Kanban 하면 된대."

나: "???"

왜 공부하게 되었나

회사가 성장하면서 폭탄이 터졌습니다:

• 문제 1: "이 기능 언제 나와?" → 아무도 모름
• 문제 2: 개발자마다 동시에 10개씩 잡고 있음 → 아무것도 안 끝남
• 문제 3: 급한 버그 생김 → 누가 고쳐야 하는지 모름

"Scrum으로 정리해 보자!"

그때부터 Scrum과 Kanban을 공부했습니다.

처음엔 뭐가 이해가 안 갔나

처음 Scrum 문서를 읽었을 때 머리가 복잡했습니다:

• Scrum이랑 Kanban이 뭐가 달라?
• Sprint가 뭐야? 마라톤 아니고?
• Daily Standup이 왜 필요해? 매일 회의하라고?
• WIP Limit가 뭐야? 일 제한하면 늦어지는 거 아냐?

무엇보다 "그냥 할 일 목록 만들면 되는 거 아냐?"라는 생각이 들었습니다.

Jira 같은 툴 설치하고, Sprint 이름 붙이면 Agile 하는 거 아닌가요?

결론부터 말하자면, 그게 아니었습니다.

깨달음의 순간 - "육상 vs 회전 초밥"

이해가 안 갔는데, 문서를 찾다 만난 비유를 읽고 와닿았습니다:

Scrum = 육상 선수 (Sprint): "100m 달리기하는 선수야. 출발 신호 울리면 → 전력으로 달림 → 결승선! 잠깐 쉬고 → 다음 레이스 준비.

2주 Sprint: 월요일 시작 → 금요일까지 전력으로 달림 → 데모! 주말 쉬고 → 다음 Sprint 시작."

Kanban = 회전 초밥 (Flow): "초밥이 컨베이어 벨트 위를 흐름. 손님이 하나 집어먹으면 → 주방에서 하나 더 올림. 멈추지 않고 계속 흐름.

일거리가 들어옴 → 처리 → 완료 또 들어옴 → 처리 → 완료 끝없이 흐름."

"아, 스타일이 완전 다르구나!"

그때 이해했습니다. Scrum과 Kanban은 단순히 보드 툴의 차이가 아니라, 일하는 방식 자체가 다른 거였습니다.

1. Scrum: 2주 단위 전력질주

핵심 개념

Sprint: 보통 2주 단위로 끊어서 개발합니다.

Sprint Planning (월요일):
"이번 2주 동안 이 3가지 기능 만들기로 했어.
딴 거 시키지 마."

Daily Standup (매일 아침 15분):
"어제 뭐 했어?"
"오늘 뭐 할 거야?"
"막히는 거 있어?"

Sprint Review (금요일):
"완성된 기능 데모합니다!"

Retrospective (금요일 오후):
"뭐가 잘됐고, 뭐가 개판이었나?"

처음에는 "이거 회의 너무 많은 거 아냐?"라고 생각했습니다.

근데 실제로 해보니, 이 리듬이 결국 이거였다: 팀을 하나로 묶는 박자표.

실제 경험

제가 팀에서 도입했을 때:

Before Scrum

CEO: "이 기능 급해! 바로 만들어!"
개발자 A: "네... (하던 거 중단)"

3일 후
CEO: "저번에 시킨 거 진행 어때?"
개발자 A: "어? 그거요? 급한 거 하느라..."

1주일 후
개발자 A:
- Task 1 (40% 완성)
- Task 2 (30% 완성)
- Task 3 (20% 완성)
- Task 4 (10% 완성)

문제: 아무것도 안 끝남. 모든 걸 시작했지만 끝난 건 하나도 없음.

After Scrum

CEO: "이 기능 급해!"
Scrum Master: "Sprint 중이라 안 됩니다.
               다음 Sprint Planning 때 우선순위 논의해요."

CEO: "그럼 언제?"
Scrum Master: "다음 주 월요일 Sprint Planning에서요."

2주 후
3개 기능 완성! ✅

효과: 명확한 완성 타이밍. 중요한 건 "시작한 개수"가 아니라 "끝낸 개수"였습니다.

Scrum Roles

Product Owner (PO):
- 역할: "뭐 만들지" 결정
- "사용자가 이 기능 원해!"
- Product Backlog 우선순위 관리

Scrum Master (SM):
- 역할: 프로세스 지킴이
- "스프린트 중에는 요구사항 추가 안 됩니다!"
- 팀 방해 요소 제거

Development Team:
- 역할: 실제 개발
- "네, 2주 안에 만들겠습니다"
- 자율적으로 업무 분배

처음에는 "Product Owner랑 PM이랑 뭐가 달라?"라고 생각했는데, 정리해본다면 이렇습니다:

• PM: 프로젝트 관리 (일정, 자원, 리스크)
• PO: 제품 가치 극대화 (무엇을, 왜 만들까)

Story Point 추정 - 삽질 경험담

Sprint Planning 때 가장 어려웠던 게 "이 일, 며칠 걸려?"였습니다.

처음엔 시간으로 추정했습니다:

"로그인 기능? 음... 3일?"

실제: 5일 걸림 (테스트, 버그 수정 포함)

시간 추정은 틀리기 일쑤였습니다. 그래서 받아들였다: Story Point 방식.

Story Point란?

상대적 복잡도를 숫자로 표현:

피보나치 수열: 1, 2, 3, 5, 8, 13, 21...

1 Point: 아주 쉬움 (오타 수정)
3 Point: 보통 (간단한 CRUD API)
5 Point: 복잡함 (결제 연동)
8 Point: 매우 복잡 (새 인증 시스템)
13 Point: 거대함 (분리 필요)

핵심: "3일" 대신 "로그인은 회원가입보다 2배 복잡"

Planning Poker

팀원이 동시에 카드 뒤집기:

PO: "로그인 기능 Story Point는?"

개발자들 (동시에 카드 뒤집기):
- 철수: 5
- 영희: 3
- 민수: 8

논의:
민수: "OAuth 연동 때문에 8이라고 봤어요"
철수: "아, 그럼 맞네. 5→8로 수정"

이 방식이 와닿았다: 팀 전체가 합의하니까 "나만 모르나?" 불안감이 사라졌습니다.

Velocity: 팀 속도 측정

Velocity = Sprint마다 완료한 Story Point 합계

Sprint 1: 20 Point 완료
Sprint 2: 18 Point 완료
Sprint 3: 22 Point 완료

평균 Velocity: 20 Point/Sprint

이제 Sprint Planning이 현실적으로 바뀌었습니다:

Before:
PO: "이번 Sprint에 이 10개 다 해줘!"
개발자: "무리인데..."
PO: "열심히!"

After:
PO: "이번 Sprint 계획: 총 35 Point"
SM: "우리 Velocity 20인데요?"
PO: "아, 그럼 20 Point까지만"

Burndown Chart: 진행 상황 시각화

Story Point
    ^
 20 |●
    |  ●
 15 |    ●
    |      ●
 10 |        ●
    |          ●
  5 |            ●
    |              ●
  0 +-----------------> Day
    1 2 3 4 5 6 7 8 9 10

이상적: 직선으로 감소
실제: 계단식 감소 (Task 완료 시점)

Burndown Chart 보면서 이해했다:

• 차트가 평평: 일이 안 끝나고 있음 → 도움 필요
• 차트가 급격히 떨어짐: Task 완료됨 → 순조로움
• 차트가 올라감: 스코프 추가됨 → 경고!

2. Kanban: 멈추지 않는 흐름

핵심 개념

Board: To Do → In Progress → Done

┌─────────┬──────────────┬────────┐
│ To Do   │ In Progress  │  Done  │
├─────────┼──────────────┼────────┤
│ Task A  │ Task B       │ Task E │
│ Task C  │ Task D       │ Task F │
│ Task G  │              │        │
└─────────┴──────────────┴────────┘

간단해 보이지만, WIP Limit이 핵심이었습니다.

WIP Limit (핵심!)

WIP = Work In Progress (진행 중인 일)

In Progress 칸: 최대 2개만!

개발자: "Task B, D 하는 중..."
PM: "Task H도 급한데!"
개발자: "In Progress 꽉 찼어요.
        B나 D 끝내고 시작할게요."

처음에는 "일 제한하면 늦어지는 거 아냐?"라고 생각했습니다.

근데 정리해본다면, 오히려 빨라졌습니다.

효과: 병목 방지, 멀티태스킹 지옥 탈출

실제 경험

제가 운영팀에 도입했을 때:

Before Kanban

개발자 상태:
- 버그 #1 (40% 진행)
- 버그 #2 (20% 진행)
- 버그 #3 (10% 진행)
- 버그 #4 (5% 진행)

PM: "버그 하나라도 빨리 끝내!"
개발자: "다 급해서..."

1주일 후:
- 버그 #1 (70% 진행)
- 버그 #2 (40% 진행)
- 버그 #3 (30% 진행)
- 버그 #4 (20% 진행)

완료: 0개 ❌

문제: 멀티태스킹 지옥. Context Switching 비용 폭발.

After Kanban

WIP Limit = 1

개발자 상태:
- 버그 #1 (100% 완료!) ✅

PM: "버그 #2는?"
개발자: "지금 시작합니다"

3일 후:
- 버그 #2 (100% 완료!) ✅

완료: 2개 ✅

효과: 완료 속도 ↑. 고객 만족도 ↑.

Cycle Time vs Lead Time

Kanban 하면서 배운 중요한 지표:

Lead Time (리드 타임):
요청 시점 → 완료 시점
"고객 입장 시간"

Cycle Time (사이클 타임):
작업 시작 → 완료 시점
"실제 작업 시간"

예시:
버그 리포트: 월요일 9시
작업 시작: 화요일 10시
완료: 수요일 3시

Lead Time: 30시간 (월 9시 → 수 3시)
Cycle Time: 17시간 (화 10시 → 수 3시)
Wait Time: 13시간 (월 9시 → 화 10시)

이해했다: Lead Time이 길면 고객 불만, Cycle Time이 길면 프로세스 문제.

WIP Limit 도입 전후 비교 예시:

Before WIP Limit:
Lead Time: 평균 5일
Cycle Time: 평균 2일
Wait Time: 평균 3일 (다른 일 하느라 대기)

After WIP Limit (2개):
Lead Time: 평균 2.5일
Cycle Time: 평균 2일
Wait Time: 평균 0.5일

결과: Lead Time 50% 감소 가능!

JIRA/Linear 설정 팁

실제로 Kanban 툴 설정할 때 시행착오가 많았습니다. 받아들였다: 툴 설정도 스킬입니다.

Column 설계

Bad:
To Do → Doing → Done

Better:
Backlog → To Do → In Progress → Code Review → Done

Best (예시):
Backlog → Ready → In Dev → In Review → Testing → Done
         (WIP: -)  (WIP: 2)  (WIP: 3)   (WIP: 2)

각 Column에 WIP Limit 걸기!

Automation 규칙

JIRA Automation:
1. PR 생성 → "In Dev" → "In Review" 자동 이동
2. PR 머지 → "In Review" → "Testing" 자동 이동
3. 3일간 움직임 없으면 → Slack 알림

이런 자동화 덕분에 "카드 옮기는 거 깜빡했어요" 문제가 사라졌습니다.

3. Scrum vs Kanban 비교

항목	Scrum	Kanban
리듬	2주 Sprint 반복	계속 흐름 (Time-box 없음)
계획	Sprint Planning (정기)	수시로 (Pull System)
변경	Sprint 중 ❌	언제든지 ✅
회의	Daily, Review, Retro	필수 회의 없음
Roles	PO, SM, Dev Team	역할 정의 없음
적합	제품 개발 (Feature)	운영/유지보수 (Bug, Support)
목표	Sprint 완료	빠른 처리 속도 (Throughput)
측정	Velocity, Burndown	Cycle Time, Lead Time

4. 실제 - Scrum 도입 사례

제품 개발팀 (5명)

Sprint 1 (2주):
- 로그인 기능 (8 Point)
- 회원가입 기능 (5 Point)
- 비밀번호 찾기 (5 Point)
총: 18 Point (팀 Velocity: 20)

Sprint Planning (월요일 10시, 2시간):
PO: "이 3개만 만들기로 결정!"
개발자들: Story Point 합의

Daily Standup (매일 9:30, 15분):
철수: "어제 로그인 API 완성, 오늘 테스트. 막힌 거 없음"
영희: "회원가입 UI 80%, 오늘 완성 예정. CSS 이슈 있음"
민수: "CSS 봐줄게"

Sprint Review (금요일 2시):
CEO에게 데모 → "오, 괜찮네!" → 피드백 받음

Retrospective (금요일 4시):
Good: API 문서화 잘됨
Bad: CSS 충돌 많았음
Action: Tailwind 도입 검토

결과: 2주마다 확실한 결과물. CEO 만족도 ↑.

5. 실제 - Kanban 도입 사례

고객 지원팀 (3명)

Board:
┌──────────┬───────────┬────────┐
│ Backlog  │ Doing(2)  │  Done  │
├──────────┼───────────┼────────┤
│ Bug #15  │ Bug #12   │ Bug #8 │
│ Bug #16  │ Bug #13   │ Bug #9 │
│ Bug #17  │           │ Bug #10│
│ Bug #18  │           │ Bug #11│
└──────────┴───────────┴────────┘

WIP Limit: 2개

새 버그 발생 → Backlog 추가
Bug #12 완료 → Done
Bug #15 시작 → Doing 이동

Priority Lane (긴급):
P0 (긴급): 즉시 처리
P1 (높음): 당일 처리
P2 (보통): 3일 이내
P3 (낮음): 2주 이내

결과: 지속적 처리, 빠른 대응. 고객 컴플레인 50% 감소.

6. Scrum의 함정

함정 1 - Sprint 중간에 급한 일

Sprint 3일차

CEO: "경쟁사가 새 기능 냈어! 우리도 급해!"

Scrum Master: "Sprint 중이라 안 됩니다"
CEO: "회사 망하는데?!"
SM: "..."

해결책:

1. 정말 긴급하면 Sprint 중단 (Sprint Abnormal Termination)
   • Sprint 버리고 새 Sprint 시작
   • 단, 팀 사기 ↓, 남용 금지
2. 다음 Sprint에 최우선 배정
   • 현실적으로 이게 Best
   • 긴급함의 99%는 "2주 기다릴 수 있음"

함정 2 - 비현실적 목표

Sprint Planning

PO: "이번에 10개 기능 만들자! (총 80 Point)"
개발자: "2주에 80 Point는 무리... 우리 Velocity 20인데"
PO: "열심히 하면 되지!"

2주 후
완성: 3개 (20 Point) ❌
미완성: 7개 (60 Point)

팀 사기 ↓↓↓

해결: Velocity 측정 + Historical Data

Sprint Planning (개선):

PO: "이번 Sprint 목표: 80 Point!"
SM: "최근 3개 Sprint Velocity 확인:
     Sprint 1: 18 Point
     Sprint 2: 22 Point
     Sprint 3: 20 Point
     평균: 20 Point"
PO: "그럼 20 Point까지만"

2주 후
완성: 5개 (20 Point) ✅

팀 사기 ↑↑↑

함정 3 - Daily Standup이 1시간

Bad Daily Standup:

철수 (20분): "어제 로그인 API 만들었는데요,
            그 과정에서 JWT 토큰 이슈가 있어서...
            (상세 설명 10분)
            그래서 Stack Overflow 찾아보니..."

영희 (15분): "저도 비슷한 문제 겪었는데..."

1시간 후 종료

해결: 15분 타이머 + 상세 논의는 After Meeting

Good Daily Standup (15분):

철수 (2분): "어제: 로그인 API 완성
           오늘: 테스트 작성
           이슈: JWT 토큰 문제"

SM: "JWT 이슈는 Standup 끝나고 철수, 영희만 남아서 논의"

영희 (2분): "어제: 회원가입 UI
           오늘: 완성 예정
           이슈: 없음"

15분 완료 ✅

7. Kanban의 함정

함정 1 - WIP Limit 없음

Board:
┌──────┬────────────────┬──────┐
│ Todo │ In Progress(?) │ Done │
├──────┼────────────────┼──────┤
│      │ Task 1         │      │
│      │ Task 2         │      │
│      │ Task 3         │      │
│      │ Task 4         │      │
│      │ Task 5         │      │
│      │ Task 6         │      │
│      │ Task 7         │      │
│      │ Task 8         │      │
└──────┴────────────────┴──────┘

개발자: "다 하는 중이에요!"
PM: "언제 끝나는데?"
개발자: "...모르겠어요"

문제: Kanban이라 부르지만 그냥 To-Do List. "In Progress"가 쓰레기통.

해결: WIP Limit 강제

Board:
┌──────┬───────────────┬──────┐
│ Todo │ In Progress(2)│ Done │
├──────┼───────────────┼──────┤
│ Task │ Task 1        │ Task │
│ Task │ Task 2        │ Task │
│ Task │ (FULL!)       │ Task │
└──────┴───────────────┴──────┘

PM: "Task 3도 급해!"
개발자: "In Progress 꽉 찼어요. Task 1 끝내는 중"
PM: "알겠어요"

명확한 우선순위!

함정 2 - 우선순위 혼란

Backlog:
- 버그 A (치명적, 서비스 다운)
- 기능 B (CEO 요청)
- 버그 C (오타)
- 기능 D (좋긴 한데...)

개발자: "어떤 거부터요?"
PM: "...다 급해"
개발자: "순서 정해주세요"
PM: "알아서 해"

해결: Priority Lane + SLA

┌─────────┬──────┬──────────┬──────┐
│ Backlog │ P0   │ Doing(2) │ Done │
├─────────┼──────┼──────────┼──────┤
│ 기능 D  │ 버그A│ 버그A    │      │
│ 버그 C  │      │ 기능B    │      │
│         │      │          │      │
└─────────┴──────┴──────────┴──────┘

Rule:
P0 (긴급): WIP Limit 무시하고 즉시 투입
P1 (높음): 우선 처리
P2 (보통): 순서대로

8. Agile Anti-Patterns: "애자일인 척"

실제로 많은 회사가 "우리 애자일 해요!"라고 하지만, 들여다보면...

Anti-Pattern 1: Agile-fall (Waterfall의 탈을 쓴 애자일)

CEO: "우리 Scrum 해요!"

실제:
6개월 사전 기획 → Sprint는 구현만
변경 요청 → "기획서에 없어요"
Sprint Review → 형식적 보고

이건 Waterfall...

특징:

• Sprint는 있지만 기획은 6개월 전에 끝남
• "애자일"인데 변경이 안 됨
• Daily Standup이 진행 보고회

Anti-Pattern 2: Scrum-but

"We do Scrum, but..."

"Scrum 하는데, Sprint는 1개월이에요"
→ 그건 Mini-Waterfall

"Scrum 하는데, Retrospective는 안 해요"
→ 그럼 개선이 어떻게 되나요?

"Scrum 하는데, 중간에 요구사항 계속 추가돼요"
→ 그건 Scrum이 아니라 Chaos

Anti-Pattern 3: Zombie Scrum

Daily Standup:
철수: "어제 코딩, 오늘 코딩, 이슈 없음"
영희: "어제 코딩, 오늘 코딩, 이슈 없음"
민수: "어제 코딩, 오늘 코딩, 이슈 없음"

(아무도 듣지 않음, 눈 풀린 채로 의식의 흐름)

Sprint Review:
"데모... 없어요. 완성 안 됐어요"

Retrospective:
"개선사항... 딱히 없는데요?"

정리해본다: 형식만 따르고 정신은 죽은 Scrum.

올바른 Agile이란?

❌ Wrong:
"Jira 쓰니까 애자일!"
"Daily Standup 하니까 Scrum!"

✅ Right:
"고객 피드백 빠르게 반영"
"2주마다 동작하는 제품 배포"
"팀이 스스로 개선"

결국 이거였다: Agile은 툴이나 프로세스가 아니라 마인드.

9. 혼합: Scrumban

Scrum의 장점:
- Sprint (주기적 리듬)
- Sprint Review (데모, 피드백)
- Retrospective (개선)

Kanban의 장점:
- WIP Limit (병목 방지)
- 유연한 우선순위
- 시각적 흐름

= Scrumban!

실제 사용

2주 Sprint + Kanban Board

Sprint Planning:
"이번 2주 목표:
 - 로그인 (8 Point)
 - 회원가입 (5 Point)
 - 총 13 Point (Velocity 고려)"

하지만:
- Kanban Board 사용 (To Do → Doing → Done)
- WIP Limit 적용 (Doing: 2개)
- 급한 버그는 중간 투입 가능 (단, Sprint 목표 조정)
- Daily Standup은 팀 결정 (우리는 격일)

Sprint Review + Retrospective는 유지:
- Review: 고객/CEO 피드백
- Retro: 팀 개선

Scrumban으로 바꾸면 이해하게 된다:

• Scrum의 리듬: 방향 잃지 않음
• Kanban의 유연함: 급한 일 대응

10. 팀 크기별 추천

팀 크기	추천	이유
1-2명	Kanban	회의 오버헤드 작음, 빠른 의사결정
3-7명	Scrum	조율 필요, Sprint 효과적, 최적 팀 크기
8-15명	Scrum + 여러 팀	팀 나누기 (각 5-7명), Scrum of Scrums
16명+	SAFe/LeSS	대규모 프레임워크 필요

팀 규모별 특징:

• 2명 팀 (초기): Kanban이 적합. Daily Standup? 옆 자리면 필요 없음.
• 5명 팀 (성장): Scrum 도입. 이제 조율 필요. Sprint로 리듬 생김.
• 팀 규모가 커질수록: 여러 팀으로 분리. 각각 Scrum. 주 1회 전체 Sync 권장.

11. 정리 - 선택 가이드

Scrum을 선택하세요 (If...)

• ✅ 새 제품 개발 중 (Product)
• ✅ 명확한 마일스톤 필요 (투자, 런칭)
• ✅ 팀 리듬 만들고 싶음 (신입 많음)
• ✅ 정기 데모/피드백 필요 (Stakeholder 많음)
• ✅ 팀 규모 3-7명

Kanban을 선택하세요 (If...)

• ✅ 운영/유지보수 업무 (Ops, Support)
• ✅ 요구사항 자주 바뀜 (초기 스타트업)
• ✅ 지속적 배포 환경 (DevOps, SaaS)
• ✅ 회의 싫어함 (Solo, 소규모)
• ✅ 우선순위 변동 심함

Scrumban을 선택하세요 (If...)

• ✅ Scrum 했는데 너무 경직됨
• ✅ Kanban 했는데 방향성 없음
• ✅ 두 방식의 장점만 원함
• ✅ 팀이 성숙함 (자율성 높음)

마치며 - "도구는 도구일 뿐"

처음엔 "Scrum vs Kanban, 뭐가 더 좋아?"라고 생각했습니다.

지금은 받아들였다:

"팀에 맞는 걸 골라라. 아니, 팀에 맞게 섞어라."

제가 배운 교훈:

• Scrum: 육상 선수처럼 전력질주 → 명확한 결과, 주기적 개선
• Kanban: 회전 초밥처럼 흐름 → 빠른 대응, 시각적 관리
• 혼합 가능: Scrumban으로 장점만 취하기

"맹목적으로 따르지 말고 팀에 맞게 조절하라"

Sprint가 1주가 되든, Daily Standup을 격일로 하든, WIP Limit을 3개로 하든, 중요한 건 "팀이 잘 돌아가느냐"입니다.

그리고 와닿았다: Agile의 핵심은 프로세스가 아니라 "빠른 피드백, 지속적 개선".

여러분 팀은 어떤 방식이 맞을까요? 시도해보고, 회고하고, 개선하세요.