애자일 적용 0x0001
2020년 11월 개정 공식 Scrum Guide(Ken Schwaber, Jeff Sutherland)를 근거로 재정리한 스크럼 노트. 이전 메모에 섞여 있던 부정확한 표현 — "iteration == Sprint", "데일리 미팅 시간을 전날 실적에 맞춰 단축", "측정 → 수정의 반복이 곧 스크럼" — 을 가이드 원문 기준으로 정정한다.
스크럼의 정의와 이론적 기반
스크럼(Scrum)은 "복잡한 문제에 대한 적응형 해결책을 통해 가치를 생성하도록 돕는 경량 프레임워크"다. 방법론(methodology)이 아니라 프레임워크(framework)라는 점이 중요하다. 가이드는 의도적으로 불완전하게(purposefully incomplete) 작성되었으며, 상세한 작업 지시 대신 사람들의 관계와 상호작용을 규율하는 최소한의 규칙만 정의한다. 그 안에서 어떤 기술과 기법을 쓸지는 사용하는 팀의 집합 지성이 채운다.
스크럼의 토대는 **경험주의(empiricism)**와 **린 사고(lean thinking)**다. 경험주의란 "지식은 경험에서 나오며, 의사결정은 관찰된 것에 근거한다"는 주장이다. 여기서 흔한 오해를 정정한다. 스크럼은 "아무 지표나 계속 측정하는 일반적인 측정 활동"이 아니다. 경험주의는 다음 세 기둥으로 구체화된다.
- 투명성(transparency): 작업과 과정이 그것을 수행하는 사람과 결과를 받는 사람 모두에게 보여야 한다. 투명성이 낮은 산출물은 가치를 깎고 리스크를 키우는 의사결정으로 이어진다.
- 검사(inspection): 산출물과 합의된 목표를 향한 진행을 빈번하고 부지런히 점검해 바람직하지 않은 편차를 조기에 발견한다. 스크럼의 다섯 이벤트가 이 검사의 주기(cadence)를 제공한다.
- 적응(adaptation): 과정이 허용 한계를 벗어나거나 결과물이 받아들일 수 없는 상태라면 즉시 조정한다. 가이드는 "적응 없는 검사는 무의미하다(inspection without adaptation is considered pointless)"고 명시한다.
따라서 "측정 → 수정 → 측정 → 수정"이라는 표현은 반만 맞다. 측정(검사)은 수단일 뿐이고, 투명성 위에서 검사하고 그 결과로 즉시 적응하는 순환 전체가 스크럼이다. 통계적 공정 관리(SPC) 같은 외부 측정 기법은 스크럼이 규정하는 요소가 아니며, 프레임워크 안에서 선택적으로 쓸 수 있는 보조 기법에 지나지 않는다.
스프린트는 임의의 "반복"과 동의어가 아니다
이전 메모의 "iteration == Sprint"는 정정이 필요하다. 반복(iteration)은 어떤 작업을 되풀이하는 일반 개념이고, 스프린트(Sprint)는 스크럼이 규칙과 함께 정의한 특정한 이벤트다. 가이드가 부여하는 조건은 다음과 같다.
- 고정 길이, 한 달 이하다. 이전 스프린트가 끝나자마자 새 스프린트가 즉시 시작되며, 일관성을 위해 길이를 수시로 바꾸지 않는다.
- 다른 모든 이벤트를 담는 컨테이너다. Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective와 실제 작업 전부가 스프린트 안에서 일어난다.
- 스프린트 동안에는 Sprint Goal을 위험에 빠뜨리는 변경이 없어야 하고, 품질은 하락하지 않아야 하며, Product Backlog는 필요에 따라 정제된다. 범위(scope)는 배운 내용에 따라 Product Owner와 재협상할 수 있다.
- 매 스프린트는 완료(Done) 상태의 사용 가능한 Increment를 만들어야 한다. 가이드는 각 스프린트를 "하나의 짧은 프로젝트"로 볼 수 있다고 말한다.
- 취소는 Sprint Goal이 쓸모없어졌을 때뿐이며, Product Owner만 취소 권한을 가진다.
스프린트가 예측 가능성을 주는 이유는 단순히 "개발을 잘게 쪼갰기" 때문이 아니라, 최소 매월 한 번 목표를 향한 진행을 검사하고 적응하는 주기가 구조적으로 보장되기 때문이다. 스프린트 기간이 너무 길면 Sprint Goal이 무효화되고 복잡성과 리스크가 커진다고 가이드는 경고한다.
스크럼 팀과 책임(accountability)
스크럼의 기본 단위는 하나의 스크럼 팀으로, Scrum Master 한 명, Product Owner 한 명, 그리고 Developers로 구성된다. 전형적으로 10명 이하이며, 팀 안에는 하위 팀도 계층도 없다. 팀은 교차기능(cross-functional — 매 스프린트 가치를 만드는 데 필요한 모든 기술을 보유)이면서 자기관리(self-managing — 누가, 언제, 어떻게 할지를 남의 간섭 없이 스스로 결정)한다. 가이드는 "역할(role)"이 아니라 "책임(accountability)"이라는 용어를 쓴다.
- Product Owner: 스크럼 팀의 작업으로 만들어지는 제품의 가치 극대화에 책임을 진다. Product Goal을 수립하고 명시적으로 전달하며, Product Backlog 항목을 만들고 명확히 전달하고, 순서를 매기고, 백로그가 투명하고 누구나 이해할 수 있도록 보장한다. Product Owner는 위원회가 아닌 한 사람이며, 이해관계자들은 그를 설득하는 방식으로만 백로그 변경을 시도한다. 그의 결정이 조직 전체의 존중을 받아야 성공할 수 있다.
- Developers: 매 스프린트 사용 가능한 Increment의 모든 측면을 만드는 데 전념하는 사람들이다. Sprint의 계획인 Sprint Backlog를 만들고, Definition of Done을 지켜 품질을 주입하고, 매일 Sprint Goal을 향해 계획을 적응하며, 전문가로서 서로에게 책임을 진다.
- Scrum Master: Scrum Guide에 정의된 대로 스크럼이 확립되도록 책임을 지며, 스크럼 팀의 효과성에 책임을 진다. 팀을 섬기는 진정한 리더(true leaders who serve)로서, 자기관리와 교차기능성을 코칭하고, 진행을 가로막는 장애물 제거를 일으키며, 모든 스크럼 이벤트가 긍정적이고 생산적으로 타임박스 안에서 열리도록 한다.
이벤트와 타임박스
스크럼의 다섯 이벤트는 각각 형식적인 검사·적응의 기회이며, 규칙성을 만들고 스크럼에 정의되지 않은 회의의 필요를 줄인다.
| 이벤트 | 목적 | 타임박스 (한 달 스프린트 기준) |
|---|---|---|
| Sprint | 모든 이벤트와 작업의 컨테이너 | 한 달 이하, 고정 길이 |
| Sprint Planning | 스프린트에서 수행할 작업을 배치 | 최대 8시간 |
| Daily Scrum | Sprint Goal을 향한 진행 검사와 Sprint Backlog 적응 | 15분 |
| Sprint Review | 스프린트 결과 검사와 향후 적응 결정 | 최대 4시간 |
| Sprint Retrospective | 품질과 효과성을 높일 방법 계획 | 최대 3시간 |
더 짧은 스프린트에서는 각 이벤트도 보통 더 짧게 잡는다.
여기서 두 번째 정정이 필요하다. Daily Scrum은 15분으로 고정이다. "어제 10분 걸렸으니 오늘은 10분으로 잡는다" 식으로 전날 실적에 따라 타임박스를 동적으로 조정하는 규칙은 가이드 어디에도 없다. 복잡성을 줄이기 위해 스프린트의 매 업무일 같은 시간, 같은 장소에서 열리며, Developers를 위한 이벤트다(Product Owner나 Scrum Master가 Sprint Backlog 항목 작업에 참여 중이라면 Developers로서 참가한다). 구조와 기법은 Developers가 자유롭게 선택하되, 초점은 Sprint Goal을 향한 진행과 다음 근무일의 실행 가능한 계획이어야 한다. 참고로 널리 알려진 "어제 한 일 / 오늘 할 일 / 장애물" 세 가지 질문 포맷은 2017년 개정에서 가이드 본문에서 제거되었다.
산출물과 약속(commitment)
스크럼의 산출물(artifact)은 작업이나 가치를 나타낸다. 각 산출물에는 투명성과 집중을 보장하는 **약속(commitment)**이 하나씩 붙는다.
- Product Backlog — 약속: Product Goal. 백로그는 제품 개선에 필요한 것들의 창발적(emergent)이고 순서가 매겨진 목록이며, 팀이 수행하는 작업의 단일 원천이다. Product Goal은 제품의 미래 상태를 서술하는 스크럼 팀의 장기 목표로, 하나를 달성하거나 포기하기 전에는 다음 목표로 넘어가지 않는다. 나머지 백로그는 그 Product Goal을 채울 "무엇(what)"을 정의하며 창발한다.
- Sprint Backlog — 약속: Sprint Goal. Sprint Goal(왜), 이번 스프린트에 선택한 Product Backlog 항목들(무엇), Increment를 전달할 실행 가능한 계획(어떻게)으로 구성된다. Sprint Goal은 스프린트의 단일 목표로 Sprint Planning에서 만들어져 종료 전에 반드시 확정된다. Developers의 약속이지만, 달성에 필요한 정확한 작업 내용에는 유연성을 부여하며, 팀이 각자 다른 과업이 아니라 함께 일하도록 응집력과 집중을 만든다.
- Increment — 약속: Definition of Done. Increment는 Product Goal을 향한 구체적인 디딤돌로, 이전 Increment들과 더해져 함께 동작하도록 철저히 검증된, 사용 가능한 결과물이다. Definition of Done은 Increment가 제품의 품질 기준을 충족할 때의 상태에 대한 형식적 서술이다. DoD를 충족하지 못한 항목은 릴리스할 수 없을 뿐 아니라 Sprint Review에 낼 수도 없고, Product Backlog로 되돌아간다. 조직 표준 DoD가 있으면 모든 팀이 그것을 최소 기준으로 따라야 한다.
예측(forecast)과 약속(commitment)의 구분
세 번째 정정 지점이다. Sprint Planning에서 Developers가 이번 스프린트에 완료할 수 있다고 선택한 항목 묶음은 **약속이 아니라 예측(forecast)**이다. 가이드는 "Developers가 자신들의 과거 성과, 다가오는 역량(capacity), Definition of Done을 더 많이 알수록 스프린트 예측에 더 확신을 갖는다"고 표현한다. 반면 약속(commitment)은 Sprint Goal에 대해 지는 것이다. 일을 하다가 예상과 다르다는 것을 알게 되면, Developers는 Product Owner와 협력해 Sprint Goal에 영향을 주지 않는 범위 안에서 Sprint Backlog의 범위를 재협상한다.
이 구분을 무시하고 "선택한 항목 전부를 무조건 끝내겠다는 약속"으로 운영하면, 야근과 품질 하락을 부르는 데스마치가 된다 — 이는 스크럼이 아니라 스크럼의 이름을 빌린 범위 고정 관리다. 가이드는 진도 예측 기법(burn-down, burn-up, 누적 흐름도 등)이 유용함을 인정하면서도, "이것들이 경험주의의 중요성을 대체하지는 않는다. 복잡한 환경에서 무슨 일이 일어날지는 알 수 없으며, 이미 일어난 일만이 미래 의사결정에 사용될 수 있다"고 단서를 단다.
리스크와 짧은 피드백 루프
스크럼에서 리스크를 줄이는 핵심 수단은 타임박스와 검사·적응 주기다. 가이드는 "더 짧은 스프린트는 더 많은 학습 주기를 만들고 비용과 노력의 리스크를 더 작은 시간 틀로 제한하기 위해 사용될 수 있다"고 말한다. 이는 검사 기회를 자주 만들어 잘못된 방향에 추가로 투자하는 시간을 줄일 수 있다는 뜻이지, 모든 손실이 한 스프린트 비용으로 제한된다는 보장은 아니다.
빅뱅(big-bang) 방식 — 마지막에 한 번에 통합하고 검증하는 방식 — 은 방향 오류를 늦게 발견할 위험이 크다. 스프린트 방식은 매 스프린트 끝에 사용 가능한 Increment를 이해관계자와 검사할 기회를 제공하므로 더 일찍 적응할 가능성을 높인다. 다만 잠복 결함이나 잘못된 시장 가정은 자동으로 드러나지 않는다. 효과는 Increment의 투명성, 이해관계자의 참여와 검사의 질에 달려 있다. 이전 메모에서 언급한 "upside risk / downside risk"는 금융과 일반 리스크 관리에서 온 용어로, Scrum Guide의 용어가 아니다.
예시: 1주 스프린트의 흐름
한 달 스프린트 기준 타임박스의 비례 축소 예시다(가이드는 짧은 스프린트에서 이벤트가 보통 더 짧다고만 규정하므로, 아래 시간은 운영 예시일 뿐 규칙이 아니다).
- 월요일 10:00 — Sprint Planning(약 2시간): Product Owner가 이번 스프린트의 가치 제안을 하고, 팀이 Sprint Goal을 확정한다(why). Developers가 백로그 항목을 선택해 예측하고(what), DoD를 충족하는 작업 계획을 세운다(how).
- 매일 09:30 — Daily Scrum(15분, 같은 시간·장소): Sprint Goal을 향한 진행을 검사하고 오늘의 실행 계획을 조정한다.
- 수요일 — Product Backlog 정제(refinement): 다음 스프린트 후보 항목을 쪼개고 상세화한다. 정제는 별도 회의가 아니라 지속적인 활동이다.
- 금요일 14:00 — Sprint Review(약 1시간): 완성된 Increment를 이해관계자와 함께 검사하고 환경 변화를 공유해 다음 행보를 협업으로 정한다. 발표회가 아니라 작업 세션이다.
- 금요일 15:30 — Sprint Retrospective(약 45분): 개인, 상호작용, 프로세스, 도구, DoD 관점에서 이번 스프린트를 검사하고 가장 효과 큰 개선을 가능한 한 빨리 실행할 방법을 정한다. 팀은 필요하면 이를 다음 Sprint Backlog에 추가할 수 있다. 이로써 스프린트가 종료되고, 다음 스프린트는 즉시 시작된다.
측정: 유용한 지표와 지표 게이밍 경고
스크럼은 특정 지표를 규정하지 않지만, 경험주의를 뒷받침하는 관측 수단으로 다음이 자주 쓰인다.
- 번업/번다운 차트와 누적 흐름도(cumulative flow): 스프린트 진행과 병목의 시각화. 예측의 재료이지 성적표가 아니다.
- 처리량(throughput)과 사이클 타임(cycle time): 흐름 기반 예측 근거.
- 스프린트 외부로 새는 결함 수(escaped defects): DoD의 실효성을 검사하는 품질 신호.
- Sprint Goal 달성률: 팀이 "태스크 나열"이 아니라 목표 중심으로 일하고 있는지의 신호.
단, Goodhart의 법칙 — "측정이 목표가 되는 순간, 그것은 좋은 측정이기를 멈춘다" — 을 항상 경계해야 한다. 속도(velocity)를 목표로 삼으면 스토리 포인트 인플레이션이 일어나고, 추정 단위는 각 팀 안에서만 통하는 상대값이므로 팀 간 속도 비교는 무의미하다. 개인 단위 지표(개인별 완료 포인트, 코드 라인 수 등)는 협업과 자기관리를 파괴한다. 지표는 평가의 도구가 아니라 검사와 적응의 근거로만 쓸 때 경험주의와 정합된다.
흔한 실패 모드
- 형식적 스크럼(zombie/mechanical Scrum): 이벤트는 전부 열지만 투명성·검사·적응이 없어 결과가 바뀌지 않는 상태.
- Daily Scrum의 보고회화: Developers의 계획 조정이 아니라 관리자에게 상태를 보고하는 자리로 변질.
- 무권한 Product Owner: 실권한이 없거나 위원회로 운영되어 백로그 순서가 외부 압력에 흔들림.
- DoD의 부재 또는 협상화: 마감 압력으로 DoD를 양보하면 기술 부채가 Increment에 누적된다.
- Sprint Goal 무시: Planning에서 목표 없이 태스크만 배정하면 집중과 응집이 사라진다.
- Retrospective 생략: 적응이 멈추고 같은 문제가 스프린트마다 재발한다.
- 예측의 약속화: forecast를 scope commitment로 강요해 크런치와 품질 하락을 유발.
- 스프린트 길이의 임의 변경: 주기가 흐트러져 검사·적응의 cadence가 붕괴한다.
- Water-Scrum-fall: 요구 분석과 릴리스는 폭포수로 두고 개발 구간만 스프린트로 돌리는 절름발이 도입.
도입 체크리스트
- 팀 전원이 Scrum Guide 원문(13쪽 분량)을 한 번 이상 읽었는가
- Product Owner가 한 명이고, 백로그 순서 결정에 대한 조직의 존중과 실권한이 있는가
- 팀이 10명 이하이고, 하위 팀 없이 교차기능·자기관리로 운영되는가
- Definition of Done이 문서화되어 모든 백로그 항목에 동일하게 적용되는가
- 스프린트 길이가 한 달 이하로 고정되고, 다섯 이벤트가 모두 타임박스 안에서 열리는가
- Product Backlog, Sprint Backlog, Increment 세 산출물이 누구에게나 투명하게 보이는가
- Sprint Goal을 확정하지 않고 Sprint Planning을 끝내는 일이 없는가
- Retrospective에서 선택한 개선이 구체적인 후속 행동으로 이어지는가
- 매 스프린트 사용 가능한 Increment가 만들어지는가(Review를 릴리스 게이트로 쓰지 않는가)
- 지표가 인사 평가가 아닌 검사·적응의 근거로만 사용되는가