스크럼(Scrum)
[!tldr] 한줄 요약 복잡한 문제를 짧은 스프린트 주기로 실험하고 피드백받아 적응하는 경량 애자일 프레임워크로, 3가지 역할/5가지 이벤트/3가지 산출물로 구성된다.
핵심 내용
정의
스크럼은 "복잡한 문제에 대한 적응형 솔루션을 통해 가치를 창출할 수 있도록 돕는 경량 프레임워크"이다 (스크럼 가이드 2020). 프레임워크 자체는 단순하지만, 제대로 실천하기는 어렵다.
이론의 3가지 기둥 — 경험주의(Empiricism)
스크럼은 "경험을 통해 배운다"는 경험주의에 기반한다:
- 투명성(Transparency) — 작업과 진행 상황이 모두에게 보여야 한다
- 검사(Inspection) — 산출물과 진행 상황을 자주 점검한다
- 적응(Adaptation) — 문제가 발견되면 빠르게 조정한다
이 세 기둥은 바로 피드백 루프(Feedback Loop)의 구조 그 자체다.
5가지 가치
헌신(Commitment), 집중(Focus), 개방(Openness), 존중(Respect), 용기(Courage)
- 헌신 — 목표 달성과 서로 지원에 기여
- 집중 — 스프린트 작업을 우선적으로 추진
- 개방 — 작업과 도전 과제에 대한 투명한 소통
- 존중 — 팀원 각자의 능력과 전문성을 인정
- 용기 — 옳은 일과 어려운 문제 해결에 도전
3가지 역할
| 역할 | 책임 | 핵심 |
|---|---|---|
| 제품 책임자(Product Owner) | 제품 가치 극대화, 백로그 관리, 우선순위 결정 | 한 명의 개인, 위원회가 아님 |
| 스크럼 마스터(Scrum Master) | 프레임워크 정착, 장애 제거, 팀 효과성 향상 | 서번트 리더(Servant Leader) |
| 개발자(Developers) | 스프린트 증분 생성, 품질 준수, 일일 계획 조정 | 자기 조직화(Self-organizing) |
5가지 이벤트
스프린트(Sprint) — 모든 이벤트를 감싸는 컨테이너. 1~4주의 고정 주기.
| 이벤트 | 타임박스 | 목적 | 답하는 질문 |
|---|---|---|---|
| 스프린트 플래닝 | 최대 8시간 | 무엇을 어떻게 할지 계획 | "왜, 무엇을, 어떻게?" |
| 데일리 스크럼 | 15분 | 진행 상황 점검, 장애 공유 | "목표를 향해 잘 가고 있나?" |
| 스프린트 리뷰 | 최대 4시간 | 결과물 검사, 향후 조율 | "제대로 만들었나?" |
| 스프린트 레트로스펙티브 | 최대 3시간 | 프로세스 개선 | "어떻게 더 잘할 수 있나?" |
이벤트별 역할의 행동
스프린트 플래닝:
- PO: 백로그를 우선순위에 따라 준비하고, "무엇을/왜" 설명. "어떻게"에는 간섭하지 않는다
- SM: 타임박스를 지키고, PO-개발자 간 대화가 원활하도록 촉진
- Dev: 기술적 질문을 하고, "어떻게/얼마나"를 결정하여 스프린트 백로그를 구성
데일리 스크럼:
- PO: 참석은 선택. 참석해도 관찰자 역할
- SM: 15분 유지, 장애 해결. 궁극적으로는 개발자가 스스로 운영하는 것이 목표
- Dev: 동료 간 동기화. 보고가 아니라 "어제 X, 오늘 Y, 막힌 것 Z" 공유
스프린트 리뷰:
- PO: 완료/미완료 항목 구분, 이해관계자 피드백을 바탕으로 제품 백로그 조정
- SM: "데모쇼"가 아닌 양방향 대화가 되도록 촉진
- Dev: PPT가 아닌 실제 동작하는 소프트웨어를 시연
스프린트 레트로스펙티브:
- PO: 참석 여부는 팀이 결정. 참석 시 한 구성원으로 참여
- SM: 가장 중요한 역할. 심리적 안전감(Psychological Safety)을 보장하여 솔직한 대화 유도. 구체적 액션 아이템 도출
- Dev: 솔직하게 의견을 나누고, 다음 스프린트에서 실행할 개선 사항을 구체적으로 약속
3가지 산출물과 약속(Commitment)
| 산출물 | 설명 | 약속 |
|---|---|---|
| 제품 백로그(Product Backlog) | 제품 개선에 필요한 항목의 순위화된 목록 | 제품 목표(Product Goal) |
| 스프린트 백로그(Sprint Backlog) | 이번 스프린트에 할 일 + 실행 계획 | 스프린트 목표(Sprint Goal) |
| 증분(Increment) | 완료 기준을 충족한 결과물 | 완료의 정의(Definition of Done) |
완료의 정의(Definition of Done) — 제품에 필요한 품질 수치를 충족했을 때의 증분 상태에 대한 공식적 명세. 완료 기준을 충족하지 못한 항목은 스프린트 리뷰에서 릴리스될 수 없고, 다시 제품 백로그로 돌아간다.
Anti-Patterns — 스크럼이 잘 안 되는 패턴
카고 컬트 스크럼(Cargo Cult Scrum): 형식만 따라하고 원리를 이해하지 못하는 것. 데일리 스크럼이 보고회, 레트로에서 매번 같은 불만만 반복, 아무것도 바뀌지 않는다.
좀비 스크럼(Zombie Scrum): 스프린트마다 증분을 만들지만 실제로 릴리스하지 않는다. 피드백 루프가 팀 내부에서 끊기고 외부까지 도달하지 못한다.
미니 워터폴(Water-Scrum-Fall): 기획팀이 요구사항 확정 → 스프린트 N회 → QA팀 테스트 → 배포. 스프린트 안에서만 애자일이고 앞뒤로는 워터폴이다.
역할의 변질:
- 스크럼 마스터가 규칙 경찰이나 비서가 되는 것
- 제품 책임자가 의사결정권 없는 대리인이거나 작업 지시자가 되는 것
- 데일리 스크럼이 PO/SM에게 "보고"하는 형태가 되는 것
추정의 함정: 스토리 포인트가 성과 측정 도구로 변질되거나, 벨로시티를 팀 간 비교하면 투명성이 무너진다.
공통 원인: 스크럼의 "무엇(what)"만 도입하고 "왜(why)"를 이해하지 못했기 때문이다. 의도적 수련(Deliberate Practice)에서 다룬 것처럼, 형식적 반복과 의식적 실천의 차이가 여기서도 적용된다.
스크럼이 맞지 않는 경우
스크럼은 커네빈 프레임워크(Cynefin Framework)의 복합(Complex) 영역에서 가장 적합하다. 다음 경우에는 다른 접근법이 낫다:
- 문제가 이미 명확한 팀 (유지보수, 정기 운영) → 칸반(Kanban)이 더 적합
- 1~2명으로 구성된 팀 → 역할 분리가 불가능. 개인 칸반이 효율적
- 뭘 만들어야 하는지 모르는 탐색 단계 → 디자인 스프린트, 린 스타트업의 Build-Measure-Learn
- 긴급 대응 팀 (장애, 보안 인시던트) → 칸반의 WIP 제한
- 이미 자기 조직화된 시니어 팀 → XP의 실천법만으로 충분할 수 있음
스크럼은 도구이지 목적이 아니다. "우리 팀에 스크럼이 필요한가?"가 아니라 "우리 팀의 문제는 무엇이고, 어떤 피드백 루프가 필요한가?"가 먼저다.
예시
[!example] 이벤트별 역할 요약
이벤트 PO SM Dev 플래닝 무엇을/왜 설명 촉진, 타임박스 어떻게/얼마나 결정 데일리 (선택) 관찰 15분 유지, 장애 해결 동료 간 동기화 리뷰 완료 판단, 백로그 조정 대화 촉진 동작하는 SW 시연 레트로 (팀 결정) 한 구성원 안전한 환경 조성 솔직한 의견, 액션 약속
[!example] 스크럼 vs 칸반 — 언제 무엇을
기준 스크럼 칸반 업무 예측성 낮음 (복합 영역) 높음 (명확/복잡 영역) 변경 빈도 스프린트 내 안정 언제든 변경 가능 릴리스 주기 스프린트 단위 준비되면 즉시 역할 PO, SM, Dev 명확 역할 구분 없음 핵심 메커니즘 타임박스 (시간 고정) WIP 제한 (작업량 고정)
참고 자료
- 스크럼 가이드 2020 (한국어)
- 스크럼 가이드북 2020 - SK C&C Tech Blog
- 스크럼이란 무엇입니까? - Atlassian
- What is Scrum? - AWS
- 애자일 이야기 블로그
관련 노트
- 피드백 루프(Feedback Loop) - 스크럼의 4가지 이벤트가 곧 구조화된 피드백 루프
- 회고(Retrospective) - 스크럼의 프로세스 개선 이벤트
- 심리적 안전감(Psychological Safety) - 레트로스펙티브가 작동하기 위한 전제 조건
- 사용자 스토리(User Story) - 제품 백로그의 대표적 형식
- 익스트림 프로그래밍(XP) - 스크럼과 함께 쓰이는 기술적 실천법 중심의 방법론
- 의도적 수련(Deliberate Practice) - 형식적 반복 vs 의식적 실천의 차이
- 전문성 발달(Expertise Development) - 스크럼의 원리를 이해해야 카고 컬트를 피할 수 있다