애자일 완전 정복 2편: 스크럼(Scrum), 계획보다 빠른 실행의 비밀

들어가며: 마인드셋만으로는 부족하다

1편에서 우리는 애자일이 왜 탄생했는지, 그리고 4가지 핵심 가치가 무엇인지를 살펴봤습니다.

그런데 이런 의문이 남습니다. "좋아, 철학은 이해했어. 그래서 내일 출근하면 어떻게 일하라는 거지?"

애자일이 엔진이라면, 스크럼(Scrum)은 그 엔진을 실제로 굴리는 기어입니다. 추상적인 가치를 구체적인 회의, 역할, 결과물로 변환해주는 가장 널리 쓰이는 애자일 프레임워크입니다.

전 세계 애자일 팀의 약 87%가 스크럼을 사용하고 있다는 조사 결과가 있을 만큼, 스크럼은 사실상 애자일의 표준 구현체입니다. 이번 편을 읽고 나면 스크럼을 이론적으로 이해하는 것을 넘어, 내일 당장 팀에 적용하거나 혼자서도 활용할 수 있는 수준이 될 것입니다.

1. 왜 이름이 스크럼(Scrum)인가

스크럼이라는 이름은 럭비에서 왔습니다. 럭비에서 스크럼은 양 팀이 서로 맞붙어 공을 놓고 경쟁하는 대형인데, 특히 팀 전체가 어깨를 맞대고 협력하여 공을 전진시키는 장면을 가리킵니다.

소프트웨어 개발에 이 이름을 붙인 이유는 명확합니다.

전통적인 워터폴 방식이 이어달리기라면(A가 끝내야 B가 시작), 스크럼은 럭비입니다. 팀 전체가 동시에 움직이고, 상황이 바뀌면 즉시 방향을 틉니다. 혼자서 영웅이 되는 구조가 아니라, 팀 전체가 한 방향으로 밀어붙이는 구조입니다.

스크럼의 이론적 뿌리: 경험주의(Empiricism)

스크럼은 세 가지 기둥 위에 세워져 있습니다.

투명성(Transparency): 프로젝트의 모든 상황을 팀 전체가 공유합니다. 진행이 늦어지고 있다는 사실, 특정 기능이 예상보다 복잡하다는 사실을 숨기지 않습니다. 불편한 진실을 일찍 공유할수록 대응 시간이 생깁니다.
검사(Inspection): 목표를 향해 올바른 방향으로 가고 있는지 주기적으로 확인합니다. 스프린트가 끝날 때마다 결과물을 직접 확인하는 것이 바로 검사의 핵심입니다.
적응(Adaptation): 검사 결과 경로 수정이 필요하다면 즉시 방향을 바꿉니다. 애초 계획을 고수하는 것이 미덕이 아닙니다. 현실에 맞게 빠르게 조정하는 것이 스크럼의 핵심 능력입니다.

이 세 가지는 단순한 원칙이 아닙니다. 스크럼의 모든 이벤트와 산출물이 이 세 기둥을 중심으로 설계되어 있습니다.

2. 스크럼의 구성 요소: 3-5-3 법칙

스크럼의 전체 구조는 단순합니다. 3가지 역할, 5가지 이벤트, 3가지 산출물. 이것이 전부입니다.

이 숫자가 의미하는 것은 스크럼이 의도적으로 단순하게 설계되었다는 것입니다. 복잡한 프로세스와 문서로 무거워진 기존 방식의 반성에서 탄생했기 때문에, 스크럼 자체는 놀랍도록 가볍습니다.

3. 3가지 핵심 역할 (Roles)

역할 1. 프로덕트 오너 (Product Owner, PO)

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

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

PO에 대한 흔한 오해가 두 가지 있습니다.

첫째, PO는 개발팀에게 "어떻게 만들라"고 지시하지 않습니다. PO는 무엇을, 왜 만들어야 하는지를 정의할 뿐, 방법은 개발팀이 결정합니다.

둘째, PO는 고객의 모든 요구사항을 다 수용하는 사람이 아닙니다. 오히려 반대입니다. 수십 가지 요구사항 중에서 지금 당장 가장 중요한 것 3가지를 골라내는 거절의 용기가 필요한 자리입니다.

역할 2. 스크럼 마스터 (Scrum Master, SM)

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

SM은 **서번트 리더(Servant Leader)**입니다. 팀이 최고의 성과를 낼 수 있도록 장애물을 제거해주는 사람입니다.

구체적으로 SM이 하는 일은 이렇습니다.

스크럼 프로세스가 올바르게 진행되도록 가이드합니다
데일리 스크럼에서 나온 장애물을 실제로 해결합니다
외부에서 오는 방해(긴급 요청, 범위 확장 시도 등)로부터 팀을 보호합니다
팀 내 갈등이나 소통 문제를 중재합니다
스크럼을 처음 도입하는 팀을 코칭합니다

SM이 잘 하는 팀은 개발자들이 개발에만 집중할 수 있습니다. 회의를 잡거나, 이해관계자를 설득하거나, 다음 스프린트를 준비하는 행정 업무를 SM이 처리해주기 때문입니다.

역할 3. 개발팀 (Development Team)

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

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

적정 규모는 3~9명을 권장합니다. 3명 미만이면 협업의 이점이 줄고, 9명을 넘으면 소통 복잡도가 기하급수적으로 증가합니다.

4. 5가지 이벤트 (Events)

이벤트 1. 스프린트 (Sprint)

스프린트는 스크럼의 심장입니다. 1주~4주의 고정된 기간 동안 하나의 목표를 향해 달리는 반복 사이클입니다.

가장 중요한 규칙은 기간의 고정입니다. 이번 스프린트가 어렵다고 기간을 늘리지 않습니다. 목표를 줄이더라도 기간은 지킵니다. 이 고정된 리듬이 팀에게 예측 가능성과 심리적 안정감을 줍니다.

처음 스크럼을 도입한다면 2주 스프린트를 권장합니다. 1주는 너무 짧아 계획과 회고에 쫓기고, 4주는 너무 길어 피드백이 늦어집니다.

스프린트가 끝나면 반드시 작동 가능한 결과물이 나와야 합니다. 80% 완성된 기능은 결과물이 아닙니다. 완성 기준을 팀이 사전에 합의해두는 것이 중요합니다.

이벤트 2. 스프린트 계획 (Sprint Planning)

스프린트 시작 전에 진행하는 회의입니다. 이번 스프린트에서 무엇을, 어떻게 할 것인지를 팀 전체가 함께 결정합니다.

회의는 두 파트로 나뉩니다.

파트 1 — 무엇을 할 것인가: PO가 백로그에서 우선순위가 높은 항목을 제시하고, 팀이 이번 스프린트에서 완료할 수 있는 양을 선택합니다. 이때 과거 스프린트에서 팀이 실제로 완료한 양(벨로시티)을 참고합니다.

파트 2 — 어떻게 할 것인가: 선택한 항목을 어떻게 구현할지 개발팀이 구체적인 작업으로 쪼갭니다. 이 결과가 스프린트 백로그가 됩니다.

2주 스프린트 기준 최대 4시간을 넘기지 않는 것을 권장합니다.

이벤트 3. 데일리 스크럼 (Daily Scrum)

매일 같은 시간, 같은 장소에서 15분 이내로 진행하는 짧은 동기화 회의입니다.

세 가지 질문이 전부입니다.

① 어제 내가 팀 목표를 위해 완료한 일은?
② 오늘 내가 팀 목표를 위해 할 일은?
③ 진행을 막는 장애물이 있는가?

여기서 흔히 하는 실수가 있습니다. 데일리 스크럼을 진행 보고 자리로 만드는 것입니다. 팀원들이 서로에게 보고하는 것이 아니라, 팀 전체가 목표를 향해 제대로 가고 있는지 함께 확인하는 자리입니다.

또 하나, 데일리 스크럼에서 나온 장애물을 그 자리에서 해결하려 하면 안 됩니다. 장애물을 확인하는 것으로 충분합니다. 해결은 회의 후 관련된 사람들끼리 별도로 합니다. 그래야 15분을 지킬 수 있습니다.

이벤트 4. 스프린트 리뷰 (Sprint Review)

스프린트가 끝나면 팀이 작동하는 결과물을 직접 시연하고, 이해관계자에게 피드백을 받는 자리입니다.

중요한 점은 발표 자료를 준비하는 것이 아니라는 것입니다. 실제로 작동하는 제품을 보여줍니다. 이 차이가 큽니다. 슬라이드로는 숨길 수 있는 것들이 실제 시연에서는 드러납니다.

리뷰에서 나온 피드백은 다음 스프린트의 백로그에 반영됩니다. 이 사이클이 제품을 점점 고객이 원하는 방향으로 진화시킵니다. 2주 스프린트 기준 최대 2시간을 권장합니다.

이벤트 5. 스프린트 회고 (Sprint Retrospective)

리뷰가 제품을 점검하는 자리라면, 회고는 팀의 일하는 방식을 점검하는 자리입니다.

세 가지 질문을 중심으로 진행합니다.

✅ 잘 된 것은 무엇인가? (계속 유지할 것)
🔧 개선할 것은 무엇인가? (다음에 바꿀 것)
💡 시도해볼 새로운 것은 무엇인가?

회고가 형식적으로 흐르지 않으려면 한 가지를 지켜야 합니다. 회고에서 나온 개선 사항 중 딱 한 가지를 다음 스프린트에서 반드시 실행하는 것입니다. 개선 목록을 쌓아두기만 하면 아무것도 바뀌지 않습니다.

또한 회고는 개인을 비판하는 자리가 아닙니다. 사람이 아닌 프로세스를 점검합니다. "왜 이 작업자가 늦었나"가 아니라 "왜 이 작업이 예상보다 오래 걸렸나"를 묻는 것이 올바른 회고입니다.

5. 3가지 산출물 (Artifacts)

산출물 1. 제품 백로그 (Product Backlog)

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

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

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

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

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

백로그는 살아있는 문서입니다. 스프린트마다 새로운 항목이 추가되고, 불필요해진 항목은 삭제됩니다. PO는 지속적으로 우선순위를 재조정합니다.

산출물 2. 스프린트 백로그 (Sprint Backlog)

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

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

산출물 3. 증분 (Increment)

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

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

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

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

6. 스크럼이 실패하는 이유

스크럼을 도입했는데 오히려 더 힘들어졌다면, 아래 패턴 중 하나에 해당할 가능성이 높습니다.

① 데일리 스크럼이 보고 회의로 변질될 때

팀원들이 매니저에게 보고하는 자리가 되면, 데일리 스크럼은 공포의 시간이 됩니다. 솔직한 장애물 공유 대신 좋은 말만 늘어놓게 됩니다. 데일리 스크럼은 팀원들이 서로를 위해 동기화하는 자리입니다.

② PO 없이 스크럼을 도입할 때

명확한 우선순위 결정자 없이 스크럼을 하면 팀이 방향을 잃습니다. 모든 것이 급하고 모든 것이 중요해집니다. 진짜 PO 없이 스크럼 마스터 혼자 두 역할을 겸하면 반드시 문제가 생깁니다.

③ 스프린트 중간에 요구사항이 계속 바뀔 때

스프린트가 시작되면 그 기간만큼은 팀이 집중할 수 있어야 합니다. 중간에 요구사항이 계속 추가되면 스프린트의 의미가 없어집니다. 긴급한 요청은 다음 스프린트 백로그에 추가하는 것이 원칙입니다.

④ 회고를 형식적으로 진행할 때

"이번에도 잘 됐습니다. 다음에도 열심히 합시다."로 끝나는 회고는 없는 것만 못합니다. 회고에서 나온 개선 사항이 실제로 다음 스프린트에 반영되어야만 팀이 성장합니다.

7. 1인 개발자와 프리랜서를 위한 스크럼

스크럼은 팀이 있어야만 쓸 수 있는 것이 아닙니다. 1인 개발자, 프리랜서, 사이드 프로젝트에서도 충분히 활용 가능합니다.

핵심은 하나입니다. 요일별로 역할을 전환하는 것입니다.

시간	역할	하는 일
월요일 오전	PO 모드	이번 주 백로그 우선순위 3가지 선정
화~목	개발팀 모드	선정한 항목만 집중 실행
금요일 오후	SM 모드	이번 주 회고, 다음 주 준비

프리랜서에게 스크럼이 강력한 이유가 있습니다.

매주 작동하는 결과물을 클라이언트에게 시연하면 신뢰가 쌓입니다. 최종 납품 때 "이게 아닌데요"가 나오는 대신, 매주 피드백을 받으면서 방향을 맞춰갑니다. 3개월짜리 프로젝트에서 12번의 체크포인트가 생기는 셈입니다.

클라이언트는 자연스럽게 당신을 단순 작업자가 아닌 파트너로 인식하게 됩니다. 이것은 단가 협상에도, 장기 계약에도 직접적인 영향을 줍니다.

마치며

스크럼은 비효율을 숨기지 않습니다. 오히려 비효율을 드러내는 거울입니다.

처음 스크럼을 도입하면 기존에 숨겨져 있던 소통 문제, 우선순위 혼란, 기술 부채가 수면 위로 올라옵니다. 불편하지만, 그것이 스크럼이 제대로 작동하고 있다는 신호입니다.

중요한 것은 완벽한 스크럼이 아닙니다. 어제보다 조금 더 나은 방식으로 일하는 것입니다. 스프린트마다 하나씩 개선해 나가다 보면, 6개월 후 팀의 일하는 방식은 완전히 달라져 있을 것입니다.

완벽한 계획보다 투박한 결과물을 매주 내놓는 것이 승리의 길입니다.

애자일 마인드셋(1편)과 스크럼 프레임워크(2편), 이 두 편만 완전히 이해했다면 당신은 이미 많은 현업 개발자보다 애자일을 더 깊이 이해하고 있는 겁니다.