Brain💡 핵심 인사이트
스프린트 리뷰는 2주간의 스프린트가 꼬박 끝나는 마지막 날, 개발팀이 완성한 '작동하는 소프트웨어(Increment)'를 제품 책임자(PO)와 실제 고객(이해관계자)들 앞에서 시연(Demo)하고 피드백을 받는 가장 축제 같은 공식 이벤트입니다.
파워포인트(PPT) 슬라이드를 보여주는 자리가 아니라, 진짜 돌아가는 코드를 직접 눌러보며 시장성을 검증하는 자리입니다.
Ⅰ. 스프린트 리뷰의 목적 (Inspect & Adapt)
과거 폭포수 개발에서는 1년 뒤에 완성된 제품을 보여주고 "이거 우리가 원한 거 아닌데요?"라는 치명적인 거절을 당했습니다. 애자일에서는 이 비극을 피하기 위해 **2주마다 제품의 일부를 시연하고, 고객의 반응을 살피며 방향을 미세 조정(Adapt)**합니다.
- 성과 공유 (데모): "저희가 이번 2주 동안 이렇게 훌륭한 로그인 기능과 장바구니 기능을 만들었습니다!"
- 백로그 재조정: 시연을 본 PO와 고객이 "생각보다 장바구니 버튼 위치가 불편하네요. 다음 스프린트 때 이거 수정하는 작업을 1순위로 올립시다"라며 즉각적인 방향 전환(피벗)을 논의합니다.
Ⅱ. 스프린트 리뷰의 진행 절차
보통 2시간 내외로 진행되며 편안하고 캐주얼한 분위기에서 이루어집니다.
- 스프린트 결과 발표: PO가 이번 스프린트에서 '완성된(Done)' 백로그 아이템과 아쉽게 완료하지 못한 아이템을 투명하게 설명합니다.
- 시연 (Live Demo) ★: 개발팀이 나서서 코드가 어떻게 동작하는지 실제 시스템 화면을 띄워놓고 클릭해 가며 고객에게 보여줍니다. (PPT나 스크린샷으로 대충 때우는 것은 엄격히 금지됩니다.)
- 피드백 수렴: 참가자들(영업팀, 고객, 임원)이 제품을 직접 써보고, 시장 상황의 변화나 새로운 아이디어를 거침없이 쏟아냅니다.
- 백로그 갱신: 쏟아진 아이디어를 PO가 즉석에서 판단하여 '제품 백로그'에 새로운 티켓으로 추가하거나 기존 순위를 변경합니다.
Ⅲ. '완료(Done)'의 정의와 엄격함
스프린트 리뷰 무대에 올릴 수 있는 결과물은 오직 **"완료의 정의(Definition of Done, DoD)"**를 완벽하게 충족한 아이템뿐입니다.
- 코딩은 끝났지만 테스트를 안 했거나, QA는 통과했지만 서버에 배포되지 않은 아이템은 리뷰 시간에 시연할 수 없습니다. (99% 완성도 0%로 간주합니다.)
- 이렇게 미완성된 아이템은 스프린트 리뷰의 '성과'에서 가차 없이 제외되고 다음 스프린트로 이월됩니다. 이는 품질 저하(기술 부채)를 막기 위한 애자일의 강력한 룰입니다.
Ⅳ. 회고(Retrospective)와의 차이점
초보자들이 리뷰와 회고를 자주 헷갈립니다.
- 스프린트 리뷰 (Review): 제품의 **결과물(Product)**을 봅니다. 고객과 외부인이 참석하여 "이 기능 멋지네요"라고 제품 자체에 대해 토론합니다.
- 스프린트 회고 (Retrospective): 팀의 **일하는 방식(Process)**을 봅니다. 고객은 나가고 철저히 스크럼 팀(PO, SM, 개발팀)만 밀실에 남아 "이번 주에 형이 자꾸 지각해서 서버 늦게 띄운 거 짜증 났어요, 다음엔 그러지 맙시다"라며 팀워크와 프로세스를 고치는 자리입니다.
📢 섹션 요약 비유: 스프린트 리뷰는 요리학교의 **'신메뉴 시식회'**입니다. 학생들(개발팀)이 2주간 밤새 고안한 새로운 요리(소프트웨어)를 진짜 심사위원과 손님(PO, 고객)들의 식탁에 올려놓고 맛을 보여줍니다. "조금 더 짜게 해주세요"라는 피드백을 적어뒀다가 다음 주 요리(다음 스프린트) 레시피에 즉시 반영하는 축제의 현장입니다.