새 팀의 첫 주. 캘린더가 회의로 가득 찹니다 — 플래닝, 데일리, 리뷰, 회고, 그루밍... PM인 당신은 "이걸 다 왜 하지?" 싶고, 인프라 담당인 당신은 "내 배포 작업은 어느 스프린트에 넣어야 하지?"가 막막합니다. 세리머니 이름을 외우는 건 쉽습니다. 어려운 건 각 자리가 '무엇을 위한 것이고, 빠지면 무엇이 깨지는가'를 아는 것입니다. 애자일의 리듬을 이해하면, 회의는 의례가 아니라 팀이 같은 방향으로 달리는 박자가 됩니다.
- 1애자일이 워터폴의 어떤 한계에서 등장했는지 설명할 수 있다
- 2스프린트가 "고정 길이 반복 주기"라는 성격을 설명할 수 있다
- 34가지 세리머니(플래닝/데일리/리뷰/회고)의 목적을 각각 구분할 수 있다
- 4백로그·번다운으로 스프린트 진행 상태를 읽을 수 있다
왜 애자일인가
요구가 바뀌는 세상에서 '한 번에 다 계획'은 깨진다
워터폴은 요구→설계→개발→테스트→배포를 한 번에 길게 갑니다. 요구가 초기에 확정되고 안 바뀐다면 잘 동작합니다. 그러나 웹·앱 서비스는 출시 전에 시장·사용자가 바뀌고, "다 만들고 보니 원하던 게 아닌" 일이 잦습니다.
애자일은 이 문제를 작게 만들고 빨리 피드백받아 방향을 자주 교정하는 것으로 해결합니다. 애자일 선언의 4가지 가치:
프로세스·도구 < 개인과 상호작용
포괄적 문서 < 동작하는 소프트웨어
계약 협상 < 고객 협업
계획 준수 < 변화 대응
오른쪽도 가치 있지만 왼쪽을 더 중시한다는 상대적 선언입니다. [[sdlc-overview]]의 단계를 없애는 게 아니라, 작은 단위로 반복하는 것이 핵심입니다. 스크럼은 이를 구현하는 가장 흔한 프레임워크입니다.
스크럼의 구성요소
스프린트 · 백로그 · 역할 · 세리머니
스크럼은 몇 가지 요소로 리듬을 만듭니다.
- 제품 백로그(Product Backlog): 만들 것들의 우선순위 목록(PO 소유). [[requirements-prd]]의 유저스토리가 여기 쌓입니다.
- 스프린트(Sprint): 고정 길이(보통 2주) 반복 주기. 시작 때 백로그에서 이번에 할 것을 골라 스프린트 백로그로.
- 증분(Increment): 스프린트 끝에 나오는 '잠재적 출시 가능' 결과물.
- 세리머니 4종(아래).
제품 백로그(전체 우선순위)
│ 스프린트 플래닝에서 일부 선택
▼
스프린트 백로그 ──(2주 개발·데일리로 동기화)──▶ 증분(동작하는 결과)
│ │ 리뷰(데모·피드백)
└──────────── 회고(방식 개선) ◀────────────────┘
스프린트 진행 상태 읽기 — 직접 확인
PM·인프라는 매 카드를 짜지 않아도, 보드(To Do/In Progress/Done)와 번다운 차트로 스프린트가 건강한지 읽을 수 있습니다.
번다운 차트(이상): 잔여 작업이 매일 우하향해 스프린트 끝에 0에 수렴
포인트
30 ●
20 ●─● ← 이상선(점선)을 따라 내려감
10 ●─●
0 ───────────● (마지막 날 0)
위험 신호:
- 중반까지 평평하다가 막판 급락(또는 못 끝냄) → 후반 몰림
- In Progress 컬럼에 카드가 쌓임(WIP 과다) → 동시작업 과부하
- 매 스프린트 미완료 이월 반복 → 약속(커밋) 과다 또는 추정 부정확
echo '보드 컬럼별 카드 수 + 잔여 포인트 추세 확인'- 번다운이 중반까지 거의 평평하면 → 작업이 후반에 몰리는 중. 인프라 배포가 마지막 날 몰리지 않도록 일정을 당겨 협의
- In Progress(WIP) 카드가 팀 인원보다 많으면 → 다들 여러 개를 동시에 붙잡아 아무것도 안 끝나는 상태. "끝내기"를 "시작하기"보다 우선
- 미완료 이월이 매 스프린트 반복되면 → 커밋 과다 또는 추정 부정확 신호. 회고에서 다룰 1순위 개선 항목
- 리뷰에서 데모할 "동작하는 증분"이 없으면 → 스프린트가 "바빴지만 출시 가능한 결과는 없음". 작업을 더 작게 쪼개는 신호
상황: 데일리 스탠드업이 매일 30~40분으로 늘어지고, 한 명씩 관리자에게 상세 보고를 하는 자리가 됩니다. 팀은 "회의가 일을 방해한다"고 느낍니다.
원인: 세리머니의 목적이 흐려졌습니다. 데일리는 '팀이 서로 동기화하고 blocker를 드러내는 15분'인데, '관리자 보고'로 변질되면 상세 논의가 끼어들어 시간이 폭증합니다.
진단 — 점검:
□ 데일리가 15분을 넘기는가?
□ 한 사람이 말할 때 나머지가 듣기만 하나(보고형)?
□ 상세 기술 논의가 데일리 안에서 벌어지나?
해결: 데일리는 "어제/오늘/막힌 것" 3가지만 짧게, 상세 논의는 'parking lot'으로 빼서 관련자끼리 따로. 목적은 동기화와 blocker 노출이지 보고가 아닙니다. 세리머니는 형식이 아니라 목적으로 운영해야 부담이 아닌 리듬이 됩니다. 회고에서 "데일리가 길다"를 개선 액션으로 다룹니다.
인프라/SRE로서 애자일 팀에 속하면, 당신의 작업(파이프라인 구축, 모니터링 추가, 마이그레이션)도 백로그 아이템으로 들어가고 스프린트에 배치됩니다. "인프라는 따로"가 아니라 같은 리듬에 올라타는 것이 협업의 핵심입니다 — 특히 배포·릴리스 작업이 스프린트 마지막 날에 몰리지 않도록 플래닝에서 미리 목소리를 내야 합니다. PM은 세리머니를 '의례'가 아니라 '피드백 루프'로 운영해, 매 스프린트 끝의 리뷰·회고에서 방향과 방식을 함께 교정합니다.
다음 모듈에서는 스크럼 외의 흐름 — 칸반, 그리고 워터폴과의 비교로 "언제 어떤 방식을 택할지"를 다룹니다.