스크럼이란 무엇인가? 역할과 산출물로 이해하는 Scrum 구조

애자일 선언문을 읽고 나면 이런 질문이 남는다. "좋아, 철학은 이해했어. 그래서 내일 출근하면 실제로 어떻게 일하라는 건데?"

스크럼은 이 질문에 대한 가장 널리 쓰이는 답이다. 애자일 마인드셋을 현실의 역할, 회의, 결과물로 구체화한 프레임워크다. 이름은 익숙하지만 실제로 어떻게 생겼는지 제대로 아는 사람은 생각보다 많지 않다. 데일리 스크럼이 스크럼의 전부라고 생각하거나, 스크럼 마스터를 프로젝트 관리자로 오해하는 경우가 흔하다.

스크럼을 처음 이해할 때는 모든 용어를 한 번에 외울 필요가 없다. 먼저 세 가지 역할과 세 가지 산출물만 잡아도 구조가 보인다.

왜 이름이 스크럼인가

스크럼이라는 이름은 럭비에서 왔다. 럭비에서 스크럼은 양 팀이 어깨를 맞대고 한 방향으로 밀어붙이는 대형이다.

소프트웨어 개발에 이 이름을 붙인 이유는 분명하다. 워터폴 방식이 이어달리기라면 — A가 끝내야 B가 시작하는 — 스크럼은 럭비다. 팀 전체가 동시에 움직이고, 상황이 바뀌면 즉시 방향을 튼다. 혼자 영웅이 되는 구조가 아니라, 팀 전체가 함께 움직이는 구조다.

스크럼의 세 기둥

스크럼은 경험주의(Empiricism)라는 철학 위에 세워져 있다. 사전에 완벽한 계획을 세우는 대신, 실제로 해보면서 배우고 조정하는 방식이다. 이 철학은 세 가지 기둥으로 표현된다.

투명성(Transparency). 프로젝트의 모든 상황을 팀 전체가 공유한다. 진행이 늦어지고 있다는 사실, 특정 기능이 예상보다 복잡하다는 사실을 숨기지 않는다. 불편한 진실을 일찍 공유할수록 대응할 시간이 생긴다.

검사(Inspection). 목표를 향해 올바른 방향으로 가고 있는지 주기적으로 확인한다. 스프린트가 끝날 때마다 결과물을 직접 확인하는 것이 검사의 핵심이다.

적응(Adaptation). 검사 결과 경로 수정이 필요하다면 즉시 방향을 바꾼다. 처음 계획을 고수하는 것이 미덕이 아니다. 현실에 맞게 빠르게 조정하는 것이 스크럼의 핵심 능력이다.

이 세 기둥은 단순한 원칙이 아니다. 스크럼의 모든 역할과 이벤트와 산출물이 이 세 기둥을 중심으로 설계되어 있다.

세 가지 역할

스크럼에서 역할은 직급이 아니다.

누가 위에 있고 누가 아래에 있는지를 정하는 장치가 아니라, 어떤 책임을 누가 맡을지를 분명히 하기 위한 구분이다. 스크럼에는 세 가지 역할이 있다. 프로덕트 오너, 스크럼 마스터, 개발팀이다.

프로덕트 오너(Product Owner)

PO는 제품의 방향을 책임지는 사람이다. 무엇을 만들지, 어떤 순서로 만들지를 결정한다.

PO의 핵심 도구는 제품 백로그(Product Backlog) 다. 제품에 필요한 모든 기능과 요구사항을 한 곳에 모아두고, 끊임없이 우선순위를 조정한다. 팀이 지금 이 순간 가장 가치 있는 일을 하도록 만드는 것이 PO의 가장 중요한 역할이다.

PO에 대한 흔한 오해가 두 가지 있다. 첫째, PO는 개발팀에게 어떻게 만들라고 지시하지 않는다. 무엇을, 왜 만들어야 하는지를 정의할 뿐, 방법은 개발팀이 결정한다. 둘째, PO는 고객의 모든 요구사항을 다 수용하는 사람이 아니다. 수십 가지 요구사항 중에서 지금 가장 중요한 것을 고르고, 나머지는 뒤로 미룰 수 있어야 한다.

스크럼 마스터(Scrum Master)

SM은 프로젝트 관리자로 오해받는 경우가 많다. 하지만 전혀 다른 역할이다. SM은 팀에게 일을 지시하거나 진행 상황을 보고받는 자리가 아니다.

SM은 서번트 리더(Servant Leader)다. 팀이 최고의 성과를 낼 수 있도록 장애물을 제거해주는 사람이다. 스크럼 프로세스가 올바르게 진행되도록 가이드하고, 데일리 스크럼에서 나온 장애물을 실제로 해결하며, 외부에서 오는 방해로부터 팀을 보호한다. 팀 내 갈등이나 소통 문제를 중재하고, 스크럼을 처음 도입하는 팀을 코칭한다.

SM이 제 역할을 하는 팀에서는 개발자들이 제품을 만드는 일에 더 집중할 수 있다. 불필요한 회의를 줄이고, 이해관계자와의 충돌을 조율하고, 다음 스프린트가 흔들리지 않도록 환경을 정리해주기 때문이다.

개발팀(Development Team)

개발팀은 제품을 실제로 만드는 사람들이다. 개발자만을 의미하는 것이 아니다. 디자이너, QA 엔지니어, 데이터 분석가 등 제품을 완성하는 데 필요한 모든 역할이 포함된다.

스크럼에서 개발팀의 가장 큰 특징은 자기 조직화(Self-organizing)다. 누군가 오늘 할 일을 배정해주지 않는다. 팀 스스로 백로그를 보고, 이번 스프린트에서 무엇을 어떻게 할지 결정한다.

스크럼 팀은 너무 크지 않아야 한다. 사람이 적으면 필요한 역량이 부족해지고, 너무 많으면 소통 비용이 급격히 늘어난다. 예전에는 3~9명 규모가 자주 권장됐고, 최근 스크럼 가이드에서는 보통 10명 이하의 작은 팀을 전제로 한다.

세 가지 산출물

스크럼의 산출물은 팀이 지금 무엇을 향해 가고 있는지를 언제나 눈에 보이게 만든다. 전체 할 것, 이번에 할 것, 완성된 것.

제품 백로그(Product Backlog)

제품에 필요한 모든 기능, 개선사항, 버그 수정 목록이다. PO가 소유하고 관리한다.

백로그의 항목은 보통 사용자 스토리(User Story) 형식으로 작성한다.

나는 [사용자]로서,
[목적]을 위해,
[기능]을 원한다.

예를 들면 이런 식이다.

나는 쇼핑몰 고객으로서, 빠른 결제를 위해 카드 정보를 저장하고 싶다.

이 형식이 중요한 이유는 기능이 아닌 사용자의 가치에 초점을 맞추기 때문이다. "카드 저장 기능 구현"이 아니라, 왜 이 기능이 필요한지가 명확해진다.

백로그는 살아있는 문서다. 스프린트마다 새로운 항목이 추가되고, 불필요해진 항목은 삭제된다.

스프린트 백로그(Sprint Backlog)

이번 스프린트에서 실제로 할 항목만 뽑은 실행 목록이다. 제품 백로그의 부분집합이다.

스프린트 계획 회의에서 팀이 함께 선택하고, 스프린트 중에는 팀이 소유한다. PO도 스프린트 진행 중에는 스프린트 백로그의 항목을 바꿀 수 없다. 이것이 팀의 집중력을 지키는 핵심 장치다.

증분(Increment)

스프린트가 끝날 때마다 나오는 작동 가능한 결과물이다. 미완성이나 테스트 중인 기능은 포함되지 않는다.

팀은 스프린트 시작 전에 완료의 정의(Definition of Done) 를 합의해야 한다.

✅ 코드 리뷰 완료
✅ 단위 테스트 통과
✅ QA 테스트 통과
✅ 스테이징 환경 배포 완료

이 기준을 충족한 기능만이 증분에 포함된다. 완료 기준이 없으면 "거의 다 됐어요"가 영원히 계속된다.

단순한 구조가 가진 힘

스크럼의 전체 구조는 의도적으로 단순하다. 복잡한 프로세스와 문서로 무거워진 기존 방식의 반성에서 탄생했기 때문이다.

세 가지 역할은 누가 무엇을 결정하는지를 명확히 한다. 세 가지 산출물은 팀이 지금 어디를 향해 가고 있는지를 항상 눈에 보이게 만든다.

구조가 단순할수록, 팀이 실제 문제에 집중할 수 있는 공간이 생긴다.

스크럼의 목적은 팀을 더 바쁘게 만드는 것이 아니다. 더 자주 확인하고, 더 빨리 배우고, 더 작게 고치는 리듬을 만드는 것이다.