Brain💡 핵심 인사이트
스크럼은 애자일 철학을 현업에서 가장 널리 실천하게 해주는 **구체적인 '팀 관리 및 개발 프레임워크'**입니다.
럭비 경기에서 팀이 스크럼을 짜고 똘똘 뭉쳐 돌진하듯, 복잡한 프로젝트를 스프린트(Sprint)라는 1~4주의 짧은 타임박스로 쪼개어, 3가지 역할, 4가지 이벤트, 3가지 산출물을 통해 끊임없이 반복 개발하는 것이 핵심입니다.
Ⅰ. 스크럼의 3-3-4-3 구조
스크럼은 방대한 매뉴얼이 없습니다. 단 10페이지 남짓한 스크럼 가이드(Scrum Guide)가 제시하는 역할, 이벤트, 산출물의 규칙만 엄격하게 지키면 시스템이 굴러갑니다.
1. 3가지 역할 (Roles)
계급이나 직급 없이 수평적인 3가지 역할만 존재합니다.
- 제품 책임자 (PO, Product Owner): "무엇을(What) 만들 것인가?"를 결정합니다. 제품의 비전을 쥐고 백로그(요구사항)의 우선순위를 정하는 비즈니스 대표입니다.
- 스크럼 마스터 (SM, Scrum Master): 팀의 '서번트 리더'입니다. 개발에 개입하지 않고, 팀이 스크럼 규칙을 잘 지키도록 돕고 외부의 방해(회의 차출 등)로부터 개발팀을 보호하는 방패막이입니다.
- 개발 팀 (Development Team): "어떻게(How) 만들 것인가?"를 결정합니다. 기획, 디자인, 코딩, 테스트 기능을 모두 갖춘 3~9명의 다기능(Cross-functional) 전문가들이며, 스스로 일을 분배합니다.
2. 3가지 산출물 (Artifacts)
- 제품 백로그 (Product Backlog): 이 제품이 궁극적으로 가져야 할 모든 기능과 요구사항(유저 스토리)을 우선순위대로 쌓아놓은 거대한 위시리스트입니다. (주인: PO)
- 스프린트 백로그 (Sprint Backlog): 이번 주(스프린트)에 당장 개발하기로 떼어온 구체적인 작업(Task)들의 목록입니다. (주인: 개발팀)
- 증분 (Increment): 이번 스프린트가 끝났을 때 만들어진, 당장 배포해도 문제없을 만큼 '완전히 작동하는' 소프트웨어 결과물입니다.
3. 4가지 공식 이벤트 (Events) + 스프린트
모든 이벤트는 끝나는 시간이 엄격히 정해진 타임박스(Timebox) 형태로 운영되어 시간 낭비를 막습니다.
- 스프린트 (Sprint): 이 모든 이벤트가 담기는 1~4주의 짧은 반복 개발 주기(그릇)입니다.
- 스프린트 계획 회의 (Sprint Planning): 첫날 모여서 "이번 주엔 백로그에서 이거이거 뽑아서 개발합시다"라고 목표를 정합니다.
- 일일 스크럼 (Daily Scrum): 매일 아침 15분간 서서(Stand-up), 어제 한 일, 오늘 할 일, 장애 요소를 빠르게 공유하여 팀의 싱크를 맞춥니다.
- 스프린트 리뷰 (Sprint Review): 스프린트 마지막 날, 만들어진 '증분'을 고객과 PO 앞에서 시연(Demo)하고 피드백을 받습니다.
- 스프린트 회고 (Sprint Retrospective): 리뷰가 끝난 후 개발팀끼리 모여 "이번 주에 우리가 일하는 방식(프로세스)에서 무엇이 좋았고 무엇이 엉망이었나?"를 반성하고 다음 주 개선책을 찾습니다.
Ⅱ. 스크럼의 생명 주기 흐름
- PO가 고객 요구를 수집해 제품 백로그를 작성합니다.
- 계획 회의를 통해 상위 3개 아이템을 가져와 스프린트 백로그를 만듭니다.
- 2주간의 스프린트를 전력 질주하며, 매일 15분씩 일일 스크럼으로 장애물을 제거(SM 역할)합니다.
- 2주 뒤 작동하는 결과물을 **리뷰(시연)**하고, 회고를 통해 프로세스를 깎고 다듬은 뒤, 다시 다음 스프린트를 시작합니다.
📢 섹션 요약 비유: 스크럼은 100km 마라톤을 한 번에 뛰는 것이 아니라, 1km씩 전력 질주(스프린트)를 100번 반복하는 릴레이입니다. 1km를 뛸 때마다 감독(PO)에게 "이 방향이 맞습니까?" 물어보고(리뷰), 선수들끼리 물을 마시며 "다음 1km는 호흡을 이렇게 맞추자"라고 작전을 짜며(회고) 방향을 끝없이 보정합니다.