스크럼(Scrum), 제대로 쓰고 있습니까?
이름만 애자일인 조직과, 실제로 돌아가는 스크럼 팀의 차이는 어디서 오는가
스크럼은 지금 개발 팀이 가장 많이 채택하는 애자일 프레임워크다. 하지만 "우리 스크럼 해요"라고 말하는 팀 중 실제로 스크럼이 제대로 돌아가는 팀은 의외로 드물다. 스탠드업 미팅만 하고 끝내거나, 스프린트 기간도 들쭉날쭉하거나, 회고는 분기에 한 번 하는 경우가 허다하다.
이 글에서는 스크럼의 구조를 실무 관점에서 정리한다. 이론보다는 "왜 이렇게 설계됐는가"와 "어떻게 써야 실제로 효과가 있는가"에 집중한다.
스크럼이란 무엇인가
스크럼은 복잡한 제품을 만들기 위한 가벼운 프레임워크다. 2020년 개정된 공식 가이드 기준으로, 스크럼은 세 가지 기둥 위에 서 있다.
검사(Inspection) — 스프린트 결과물과 프로세스를 주기적으로 점검한다.
적응(Adaptation) — 검사 결과를 바탕으로 방향과 방식을 빠르게 조정한다.
핵심은 "계획대로 실행"이 아니라 "빠른 피드백 루프"다. 불확실성이 높은 환경에서 작은 단위로 일하고, 자주 점검하고, 방향을 조정하는 구조다.
세 가지 역할
스프린트: 스크럼의 심장
스크럼은 스프린트(Sprint)라는 고정 기간 단위로 돌아간다. 통상 1~4주, 대부분의 팀은 2주를 택한다. 스프린트가 끝날 때마다 "실제로 동작하는" 제품 증분(Increment)을 만드는 것이 목표다.
스프린트 도중에는 목표(Sprint Goal)를 바꾸지 않는다. 외부 요청이 들어와도 현재 스프린트는 지키고, 다음 스프린트 백로그에 추가하는 것이 원칙이다. 이 "불간섭 원칙"이 팀에 집중할 공간을 준다.
네 가지 공식 이벤트
| 이벤트 | 타이밍 | 목적 | 시간 제한 |
|---|---|---|---|
| Sprint Planning | 스프린트 시작 | 무엇을, 어떻게 만들지 계획 | 2주 스프린트 기준 최대 4시간 |
| Daily Scrum | 매일 | 진행 상황 동기화, 장애물 파악 | 15분 |
| Sprint Review | 스프린트 종료 | 완성된 증분을 스테이크홀더에게 시연, 피드백 수집 | 최대 2시간 |
| Retrospective | 리뷰 후 | 프로세스와 협업 방식 개선 | 최대 1.5시간 |
데일리 스크럼은 "어제 뭐 했고, 오늘 뭐 할 거고, 장애물이 뭔지"를 공유하는 자리다. 진행 보고를 올리는 회의가 아니라, 팀이 스스로 오늘의 계획을 맞추는 시간이다. 스크럼 마스터나 PO가 주도하는 게 아니라 개발자들이 주도하는 것이 맞다.
세 가지 산출물
- Product Backlog — PO가 관리하는 전체 작업 목록. 끊임없이 변하고 다듬어진다.
- Sprint Backlog — 이번 스프린트에서 개발팀이 선택한 작업 묶음. 팀이 소유한다.
- Increment — 스프린트에서 완성되어 실제 사용 가능한 제품. "Done의 정의"를 충족해야 한다.
스크럼이 잘 안 되는 이유
많은 팀이 스크럼 형식은 갖추되 본질은 놓친다. 자주 보이는 패턴은 이렇다.
- 스탠드업이 상태 보고 회의로 변질된다 — PO나 리더에게 "보고"하는 구조가 되면 안 된다.
- 스프린트 중간에 외부 요청이 끊임없이 들어온다 — PO가 백로그를 통해 교통정리를 해야 한다.
- 회고를 형식적으로 한다 — 불만 토로로 끝나거나, 결론 없이 끝나면 의미가 없다. 반드시 다음 스프린트에 적용할 액션 아이템이 나와야 한다.
- 스프린트 리뷰를 내부 보고로만 쓴다 — 실제 스테이크홀더, 가능하면 사용자의 피드백을 받는 자리여야 한다.
언제 스크럼이 적합한가
스크럼이 모든 팀에 맞는 건 아니다. 스크럼은 요구사항이 자주 바뀌고, 불확실성이 높으며, 팀이 긴밀하게 협업할 수 있는 환경에서 가장 효과적이다.
반대로 작업이 명확하게 정의되어 있고 흐름 관리가 더 중요한 팀이라면, 칸반이 더 잘 맞을 수 있다. 스크럼과 칸반을 섞은 스크럼반(Scrumban)을 쓰는 팀도 많다.
댓글