애자일과 스크럼, 결국 뭐가 다른 거야? — 개발 현장에서 쓸 수 있는 기초 정리

들어가며

이 글에서는 애자일과 스크럼의 관계를 정리하고, 현장에서 바로 활용하기 위해 필요한 최소한의 지식을 모아봤습니다. 새로 팀에 합류하는 분이나 독학으로 쌓은 지식을 업데이트하고 싶은 분을 위한 글입니다.

애자일이란?

한 문장으로 정리하면

애자일(Agile)은 특정 방법론이 아니라, 소프트웨어 개발의 "사고방식"이자 "가치관" 입니다. 그 출발점은 2001년 17명의 소프트웨어 개발자들이 모여 발표한 "애자일 소프트웨어 개발 선언(Agile Manifesto)"입니다.

4가지 가치

애자일 선언은 오른쪽을 왼쪽보다 더 가치 있게 여긴다고 표현합니다.

여기서 주의할 점은 "왼쪽에 가치가 없다"고 말하는 게 아니라는 점입니다. 양쪽 모두 가치가 있지만, 오른쪽에 더 비중을 둔다는 것이 애자일의 입장입니다.

12가지 원칙 (발췌)

선언의 바탕에는 12가지 원칙이 있습니다. 전부 외울 필요는 없지만, 특히 자주 등장하는 것 세 가지만 소개합니다.

1. 가치 있는 소프트웨어를 조기에 지속적으로 제공함으로써 고객 만족을 최우선으로 합니다.
2. 개발 중 언제라도 요구사항 변경을 환영합니다.
3. 동작하는 소프트웨어를 2~3주에서 2~3개월의 가능하면 짧은 주기로 자주 제공합니다.

"짧은 주기로 동작하는 것을 내보낸다"와 "변화를 환영한다"—이 두 가지가 애자일의 핵심이라고 할 수 있습니다.

스크럼이란?

애자일과의 관계

이 부분이 자주 혼동되는 포인트입니다. 도식으로 보면 다음과 같습니다.

애자일（사고방식/가치관）
├── 스크럼（프레임워크） ← 가장 널리 보급
├── XP（익스트림 프로그래밍）
├── 칸반（Kanban）
└── 기타...

즉, 스크럼은 애자일을 실천하기 위한 구체적인 프레임워크 중 하나입니다. 애자일 ≠ 스크럼이며, 스크럼 ⊂ 애자일이 올바른 관계입니다.

스크럼의 3-5-3

스크럼은 "3가지 책무(Accountabilities), 5가지 이벤트, 3가지 산출물"로 구성됩니다. 2020년판에서는 기존의 "역할"이라는 용어가 "책무"로 바뀌었고, 각 산출물에는 커밋먼트가 추가되었습니다（프로덕트 백로그 → 프로덕트 목표, 스프린트 백로그 → 스프린트 목표, 인크리먼트 → 완료의 정의）.

3가지 책무

• 프로덕트 오너（PO）: 프로덕트의 가치를 최대화할 책임자. 무엇을 만들지 우선순위를 결정합니다.
• 스크럼 마스터（SM）: 스크럼이 올바르게 기능하도록 지원합니다. 팀의 코치이자 장애를 제거하는 사람.
• 개발자（Developers）: 실제로 프로덕트를 만드는 사람들. 엔지니어, 디자이너, QA 등.

5가지 이벤트

3가지 산출물

• 프로덕트 백로그: 하고 싶은 것 전부의 우선순위 목록. PO가 관리합니다.
• 스프린트 백로그: 이번 스프린트에서 할 일 목록. 개발자가 관리합니다.
• 인크리먼트: 스프린트에서 완성된 동작하는 프로덕트.

스프린트 사이클

[플래닝] → [개발 + 데일리 × N일] → [리뷰] → [회고] → 다음 스프린트로

이 사이클을 고정된 기간으로 반복하는 것이 스크럼의 기본 리듬입니다.

구체적인 예시로 스크럼 심화하기

여기서부터는, 추상적인 설명만으로는 와닿지 않는 부분을 가상의 프로덕트를 소재로 깊이 살펴봅니다.

역할 심화

프로덕트 오너（PO）— 김민준의 하루

PO의 일은 "우선순위를 결정한다"고 한 마디로 표현되지만, 실제로는 훨씬 복잡합니다. FitLog 팀 PO 김민준의 전형적인 하루는 이렇습니다.

• 오전: 최근 릴리즈의 이용 데이터를 보고, 이탈률이 높은 화면을 파악. CS팀에서 올라온 요청을 정리.
• 오후: 이해관계자（마케팅, 경영진）와 미팅하며 Q3 사업 목표와 프로덕트 목표를 맞춤.
• 사이사이: 개발자의 "이 스펙, 이쪽 구현이 더 가벼운데 어떻게 생각하세요?"라는 문의에 즉답.
• 주간: 백로그를 리파인먼트하고 상위 아이템의 인수 조건을 구체화.

핵심은 PO는 "사용자 가치"와 "비즈니스 가치" 양쪽을 짊어지고 있다는 점입니다. "기능 A와 기능 B, 어느 쪽을 먼저 만들까?"의 판단 기준을 가지기 위해, 사용자 리서치부터 데이터 분석, 경영 회의까지 소화해야 합니다.

스크럼 마스터（SM）— 이서준의 개입 예시

SM은 "회의 퍼실리테이터"라고 생각하기 쉽지만, 본질은 팀의 자율을 이끌어내는 코치입니다. FitLog 팀 SM 이서준이 실제로 하는 일들을 나열해보면:

• 데일리 스크럼에서 개발자 A가 매일 "어제도 이 버그 조사하고 있었어요"라고 말하는 것을 알아채고, 1on1으로 "어려운 거 있어요? 도움이 필요해요?"라고 말을 건넴.
• PO와 개발자 사이에서 "스펙 해석"이 매번 어긋나는 것을 관찰하고, 회고에서 이 문제를 안건으로 올림.
• 다른 부서에서 "긴급 대응 부탁해요!"라고 개발자에게 직접 요청이 들어오는 것을 막고, "요청은 PO 경유로"라는 규칙을 재철저히 함.
• 팀이 익숙해진 타이밍에 스크럼 이벤트의 형식을 재검토하는 제안을 함（예: 데일리 형식 변경）.

SM은 아무것도 안 하는 것처럼 보이지만, 실제로는 팀의 환경을 지속적으로 정비하고 있는 역할입니다. "요즘 SM이 한가해 보인다"는 말은, 사실 팀이 자율적으로 돌아가기 시작한 좋은 징조이기도 합니다.

개발자（Developers）— "자기 관리"란 무엇인가

2020년판 스크럼 가이드에서는, 스크럼 팀 전체가 **자기 관리형（self-managing）**으로 정의되어 있습니다. 개발자의 자기 관리는 구체적으로 다음과 같은 형태로 나타납니다:

• 스프린트에서 "무엇을" 할지는 PO와 상담해서 결정하지만, "어떻게" 구현할지는 개발자가 결정함.
• 태스크를 위에서 할당받는 것이 아니라, 스스로 가져감.
• 견적은 개발자가 냄（PO나 상사가 아님）.
• 품질 기준（완료의 정의）을 지키는 책임은 개발자에게 있음.

iOS 담당 박지훈이 "이 API, 응답이 느려서 UX가 나쁘다"고 알아차렸다면, 백엔드 담당 강도윤에게 직접 상담해서 개선한다—이런 가로의 연계가 자연스럽게 발생하는 것이 건강한 스크럼 팀입니다.

이벤트 심화

스프린트 플래닝 — 실제 진행 예시

FitLog 팀의 2주 스프린트 플래닝은 이런 흐름으로 진행됩니다（소요시간 약 4시간）.

Part 1: 왜 이 스프린트는 가치 있는가?（스프린트 목표 설정）

PO 김민준: "이번 스프린트의 목표는 '사용자가 과거 30일의 트레이닝 추이를 그래프로 확인할 수 있는 상태로 만드는 것'으로 하고 싶습니다. 지난달 리서치에서, 지속률이 높은 사용자일수록 그래프 기능을 더 많이 쓴다는 것을 알게 됐거든요."

스프린트 목표는 기능 목록이 아니라, 달성하고 싶은 상태로 표현하는 것이 핵심입니다.

Part 2: 이번 스프린트에서 무엇을 할 수 있는가?（백로그 아이템 선택）

PO가 제시한 상위 아이템에 대해, 개발자가 플래닝 포커로 견적을 내고 자신들의 capacity에 맞는 양을 선택합니다.

Part 3: 선택한 일을 어떻게 완성할 것인가?（태스크 분해）

선택한 백로그 아이템을 개발자가 구체적인 태스크로 분해합니다.

개발자 박지훈: "'그래프 표시 화면' 아이템을 분해하면 API 설계, iOS 구현, Android 구현, E2E 테스트, 4개 태스크가 됩니다. API 설계를 먼저 해야 병렬화할 수 있으니, 첫날은 강도윤 집중으로 가겠습니다."

데일리 스크럼 — 좋은 예 vs 나쁜 예

❌ 좋지 않은 데일리（보고회화）

"어제는 API 구현을 했습니다. 오늘은 테스트를 작성하겠습니다. 어려운 점은 없습니다."
"저는 화면 구현을 진행했습니다. 오늘도 이어서 하겠습니다."
……（15분간 담담하게 계속됨）

이것은 진척 보고이며, 검사와 적응이 되지 않습니다.

✅ 좋은 데일리（검사와 적응）

개발자 박지훈: "그래프 렌더링 라이브러리, 예상보다 동작이 무겁습니다. 스프린트 목표 달성을 위해 다른 라이브러리로의 교체를 검토하고 싶습니다. 플래닝 후 추가 조사로 2시간 필요합니다."
개발자 강도윤: "그러면 제 API 구현을 하루 앞당겨서 지원에 들어갈 수 있어요."
개발자 박지훈: "그러면 세부 내용은 이 다음 30분에 둘이서 정리하죠."

스프린트 목표에 대해 오늘 어떻게 움직일지를 재계획하는 자리—이것이 본래의 모습입니다.

스프린트 리뷰 — 데모만이 아니다

리뷰에서 자주 있는 오해는 "동작하는 것을 데모하고 끝"이라는 것입니다. 본래의 리뷰는 이해관계자를 참여시킨 대화의 자리입니다.

• 개발자가 동작하는 인크리먼트를 데모함
• 이해관계자가 직접 써보고 피드백함
• "시장 상황이 바뀌었다", "예상 사용자의 반응이 달랐다" 등 외부 정보를 공유
• 이를 바탕으로 프로덕트 백로그를 다음을 향해 조정

즉, 리뷰는 "과거의 검사"뿐만 아니라 "미래의 계획에 대한 입력"도 겸하고 있습니다.

스프린트 회고 — 형식화를 막는 팁

회고는 "KPT（Keep/Problem/Try）로 진행하는 것"이라고 생각하기 쉽지만, 형식은 뭐든 상관없습니다. 팀 상황에 따라 형식을 바꾸는 것은 유효하지만, 그것은 수단이지 목적이 아닙니다.

FitLog 팀이 시도하는 변형들:

그리고 Try를 반드시 하나로 좁혀, 다음 스프린트 첫날에 착수합니다. "전부 하자"는 것은 아무것도 안 하는 것과 같습니다.

산출물 심화

프로덕트 백로그 — 좋은 아이템의 크기

프로덕트 백로그 아이템（PBI）은 자주 사용자 스토리 형식으로 작성됩니다.

As a [어떤 사용자가]
I want to [무엇을 하고 싶다]
So that [왜 그렇게 하고 싶은가]

FitLog의 좋은 PBI 예시:

제목: 과거 30일의 트레이닝 추이 그래프 표시

조깅을 지속하는 사용자로서, 과거 30일간의 주행 거리 추이를 그래프로 보고 싶다. 왜냐하면, 나의 노력을 시각화함으로써 동기를 유지하고 싶기 때문이다.

인수 조건:

• 홈 화면에 "추이" 탭이 추가됨
• 최근 30일의 일별 주행 거리가 꺾은선 그래프로 표시됨
• 데이터가 0건인 날은 그래프 상에서 공백이 됨
• 그래프 탭으로 해당 날의 상세 화면으로 이동

❌ 나쁜 PBI 예시: "그래프 기능 구현" ← 무엇을 위해, 누구를 위해 인지 불명확

PBI는 INVEST 원칙（Independent / Negotiable / Valuable / Estimable / Small / Testable）을 만족하는 크기가 바람직합니다.

스프린트 백로그 — 프로덕트 목표와의 연결

스프린트 백로그는 "태스크 리스트"가 아니라, 3가지 요소로 이루어진 계획입니다.

1. 스프린트 목표（왜）: 이번 스프린트에서 달성하고 싶은 상태
2. 선택한 PBI（무엇을）: 프로덕트 백로그에서 선택한 아이템
3. 실행 계획（어떻게）: 태스크 분해와 진행 방식

스프린트 목표: 과거 30일의 트레이닝 추이를 그래프로 확인할 수 있는 상태로 만들기
├─ PBI 1: 추이 그래프 표시 화면 [8 pt]
│   ├─ Task: API 엔드포인트 설계
│   ├─ Task: iOS 구현
│   ├─ Task: Android 구현
│   └─ Task: E2E 테스트
├─ PBI 2: 그래프 탭으로 상세 이동 [3 pt]
│   └─ ...
└─ PBI 3: 빈 데이터 시의 표시 개선 [2 pt]
    └─ ...

인크리먼트 — "완료의 정의（DoD）"

인크리먼트는 "동작하는 프로덕트"라고 설명되지만, 무엇을 완료로 볼 것인지는 팀에서 명확히 정의해야 합니다. 이것이 **완료의 정의（Definition of Done, DoD）**입니다.

FitLog 팀의 DoD 예시:

• 코드 리뷰에서 2명 이상의 Approve
• 단위 테스트 커버리지 80% 이상
• E2E 테스트 통과
• 접근성 체크 완료（VoiceOver / TalkBack）
• PM이 인수 조건 확인하고 OK
• 릴리즈 노트 초안 작성

DoD를 충족하지 못한 것은 "미완성"으로 다음 스프린트로 넘깁니다. "80% 완성된 기능" 10개를 쌓아두는 것보다, "100% 완성된 기능" 5개를 내보내는 것이 스크럼의 사고방식입니다.

벨로시티 — 팀의 "속도"를 측정한다

여기까지 읽으면서 "PBI 옆에 있던 [8 pt]가 뭐지?"라고 생각한 분도 있을 것입니다. 이것이 스크럼을 실무에서 운영하는 데 중요한 벨로시티（Velocity） 이야기로 이어집니다.

정의

벨로시티란 1스프린트당 팀이 완료시킨 백로그 아이템의 규모 합계값입니다. 일반적으로 다음과 같이 정의됩니다.

벨로시티 = 해당 스프린트에서 "완료의 정의"를 충족한 PBI의 스토리 포인트 합계

중요한 것은:

• 완료된 PBI만 카운트합니다（80% 완성 = 0으로 처리）
• 단위는 스토리 포인트（SP） 가 일반적（시간이 아님）
• 스프린트 단위로 계측하고, 복수 스프린트의 이동 평균으로 보는 경우가 많음

스토리 포인트란?

스토리 포인트는 작업의 상대적인 크기를 나타내는 단위입니다. "인일"이나 "시간" 같은 절대값이 아니라, "저 기준 태스크에 비해 얼마나 큰가"라는 상대적인 비교로 견적합니다.

자주 사용되는 것은 피보나치 수열（1, 2, 3, 5, 8, 13, 21...）입니다. 숫자가 커질수록 간격이 넓어지는 것은, "큰 태스크일수록 불확실성이 높고, 세밀한 구분에 의미가 없다"는 사고방식을 반영한 것입니다.

FitLog 팀의 견적 기준 예시:

구체적인 예시: FitLog 팀의 벨로시티 추이

FitLog 팀의 최근 6스프린트 실적을 살펴봅시다.

스프린트 1: 18 pt（완료 PBI: 5 + 5 + 3 + 3 + 2）
스프린트 2: 22 pt（완료 PBI: 8 + 5 + 5 + 2 + 2）
스프린트 3: 25 pt（완료 PBI: 8 + 8 + 5 + 3 + 1）
스프린트 4: 23 pt
스프린트 5: 26 pt
스프린트 6: 24 pt
─────────────────────
최근 3스프린트 평균: 24.3 pt ← 현재의 벨로시티

이 팀은 1스프린트당 약 24포인트를 처리할 수 있다는 것을 알 수 있습니다.

벨로시티의 용도

벨로시티가 안정되면, 다음과 같이 사용할 수 있게 됩니다.

1. 스프린트 플래닝의 capacity 파악

PO 김민준: "다음 스프린트 후보 PBI, 합계 32포인트 있어요."
개발자 박지훈: "최근 평균이 24포인트니까, 상위 26포인트 분（8+8+5+3+2）을 맡는 것이 현실적이에요."

"의지로 어떻게든 한다"가 아니라, 실적 기반으로 합의할 수 있는 것이 큰 가치입니다.

2. 릴리즈 계획 예측

프로덕트 백로그 전체가 180포인트, 벨로시티가 24포인트라면, 나머지 180 ÷ 24 = 약 7.5스프린트로 완료 예상이라는 예측을 세울 수 있습니다.

이것이 있으면 "대략 Q3 말에 릴리즈할 수 있을 것 같다"는 이해관계자에 대한 설명을 근거 있게 할 수 있게 됩니다.

3. 견적 정확도의 지속적 개선

"예상 5포인트였는데, 실제로는 10포인트 분의 노력이 들었다"는 어긋남이 보이면, 회고에서의 논의 재료가 됩니다.

자주 있는 안티패턴

벨로시티는 편리한 반면, 잘못 사용하면 팀을 망칩니다.

❌ 안티패턴 1: 벨로시티를 KPI로 만들기

"지난달보다 이번 달 벨로시티가 높지 않으면 안 된다", "다른 팀보다 낮은 건 게으른 것"—이것은 최악의 사용 방법입니다.

벨로시티는 팀 고유의 상대값이며, 팀 간에 비교하는 것은 의미가 없습니다. 또한 "벨로시티를 높여라"라고 압박하면, 팀은 견적을 부풀릴 뿐이며 실제 생산성은 변하지 않습니다（오히려 내려갑니다）.

❌ 안티패턴 2: 스토리 포인트 = 시간

"1포인트 = 4시간"으로 고정해서 사용하기 시작하면, 스토리 포인트의 의미가 없어집니다. 상대 견적의 장점（불확실성의 표현, 논의의 효율화）이 사라져, 그냥 공수 견적으로 퇴화합니다.

❌ 안티패턴 3: 미완성 PBI의 부분 점수를 카운트

"8포인트의 PBI가 7할 완료됐으니 5.6포인트 분 계상"—이것은 해서는 안 됩니다. 완료의 정의를 충족하지 않은 PBI는 0포인트가 원칙입니다.

이유: 벨로시티는 "다음 스프린트에서 완성할 수 있는 양"을 예측하기 위한 지표입니다. 진행 중인 작업을 카운트하면 예측이 틀어집니다.

❌ 안티패턴 4: 팀 구성 변경 직후의 값을 믿기

멤버가 늘거나 줄거나, 기술 스택이 바뀌면 벨로시티는 리셋됩니다. 새로운 체제로 3~4스프린트 돌린 후에, 다시 평균을 구하는 것이 원칙입니다.

벨로시티를 사용하지 않는 선택지

최근에는 "벨로시티를 쫓지 않는" 팀도 늘고 있습니다. 대안 지표로 다음과 같은 것들이 있습니다:

• 스루풋（Throughput）: 완료 PBI 수（포인트를 붙이지 않고, PBI 크기를 맞추고 수만 세는）
• 사이클 타임（Cycle Time）: PBI가 착수에서 완료될 때까지의 시간
• 리드 타임（Lead Time）: PBI가 작성에서 완료될 때까지의 시간

특히 칸반과 조합하는 경우나, 견적 비용을 줄이고 싶은 성숙한 팀에서는 이러한 지표가 더 유효한 경우가 많습니다.

알아두어야 할 용어집

스크럼/애자일에는 독특한 용어가 많으며, 이를 알고 있느냐 없느냐에 따라 팀 내 커뮤니케이션 효율이 크게 달라집니다. 실례와 함께 깊이 파고들어 봅니다.

플래닝 포커（Planning Poker）

무엇을 하는가

플래닝 포커는 팀 전원이 PBI의 스토리 포인트를 견적하는 기법입니다. 경험이 풍부한 엔지니어 한 명이 "이것은 5포인트"라고 결정하는 것이 아니라, 멤버 전원이 동시에 카드를 내서 합의를 이끌어냅니다.

왜 굳이 "포커" 형식인가

소리가 큰 사람이나 경력 연수가 긴 사람의 의견에 끌려가버리는 "앵커링 효과"를 막기 위해서입니다. 먼저 "이거 8포인트지?"라고 누군가가 말하면, 다른 멤버는 "아니 3이라고 생각해"라는 반대 의견을 내기 어려워집니다. 전원이 동시에 카드를 내는 것으로 이를 막습니다.

진행 방법（FitLog 팀의 예시）

카드는 피보나치 수열（0, 1, 2, 3, 5, 8, 13, 21, ?, ☕）이 일반적입니다. "?"는 모른다, "☕"는 휴식을 의미합니다.

스텝 1: PBI 설명

PO 김민준: "다음은 '푸시 알림으로 리마인드를 보낸다'입니다. 사용자가 설정한 시각에, 그날 트레이닝 기록이 없으면 알림을 보냅니다."

스텝 2: 질의응답

개발자 박지훈: "알림 문구는 커스터마이즈 가능한가요?"
PO 김민준: "아니요, 고정 문구로 괜찮습니다."
개발자 강도윤: "서버 측의 알림 기반은 기존 것을 사용하는 상정인가요?"
PO 김민준: "네, 기존 기반을 사용하는 전제입니다."

스텝 3: 전원 일제히 카드 내기

스텝 4: 최고값과 최저값인 사람에게 설명해달라

최저인 강도윤: "BE 측은 기존 알림 기반의 호출 추가뿐이라서 3입니다."
최고인 한소희: "Android 측에서 사용자 설정 저장, 정기 잡, 알림 핸들링, 3가지 구현이 필요합니다. 전에 비슷한 걸 했을 때 고생해서 13 붙였어요."

스텝 5: 논의를 바탕으로 재투표

논의 결과, 전원이 "8" 근방으로 수렴. 최종적으로 8포인트로 합의.

포인트

• 빨리 투표시키지 않기: 질의응답으로 전제를 맞춘 후에 내기
• 어긋난 사람을 비난하지 않기: 어긋남은 정보의 차이이며, 그것을 공유하는 것이 목적
• 시간을 너무 쓰지 않기: 1 PBI당 5~10분이 기준. 결정이 안 되는 PBI는 리파인먼트로 돌려보내기

백로그 리파인먼트（Refinement）

무엇을 하는가

리파인먼트는 프로덕트 백로그를 정비하는 지속적인 활동입니다. 구체적으로는:

• 너무 큰 PBI를 분할
• 상위 PBI의 인수 조건을 구체화
• 오래된 PBI를 삭제
• 견적을 냄（플래닝 포커의 자리로 사용되는 경우가 많음）

언제 하는가

스크럼 가이드에서는 독립된 이벤트로 정의되어 있지 않지만, 많은 팀은 주 1회 1~2시간의 전용 슬롯을 잡습니다. 스프린트 중간 즈음에 설정하는 팀이 많습니다.

Ready의 정의（Definition of Ready）

현장에서는 DoD와 대비하여 이야기되는 개념으로, Ready의 정의（Definition of Ready） 가 있습니다. 리파인먼트를 통해 PBI가 Ready 상태가 되면 플래닝에 가져갈 수 있다는 사고방식입니다.

FitLog 팀의 Ready 정의 예시:

• 사용자 스토리 형식으로 작성됨
• 인수 조건이 3개 이상 있음
• 팀 전원이 내용을 이해하고 있음
• 8포인트 이하로 분할됨
• 외부 의존이 있는 경우, 의존처와 합의됨

INVEST 원칙（심화）

좋은 PBI가 충족해야 할 6가지 성질. 각각 구체적인 예로 살펴봅니다.

사용자 스토리의 계층 — 테마·에픽·스토리·태스크

프로덕트 백로그는 1차원 리스트이지만, 실무에서는 4계층으로 생각하는 경우가 많습니다.

테마（Theme）: 사용자 참여도 향상
└─ 에픽（Epic）: 트레이닝 지속을 촉진하는 구조
   ├─ 사용자 스토리: 과거 30일의 추이를 그래프로 볼 수 있다 [8 pt]
   │  ├─ Task: API 구현
   │  ├─ Task: iOS UI 구현
   │  └─ Task: Android UI 구현
   ├─ 사용자 스토리: 리마인드 알림을 받을 수 있다 [8 pt]
   └─ 사용자 스토리: 연속 기록 일수를 표시한다 [3 pt]

PBI（프로덕트 백로그 아이템）로 백로그에 나열되는 것은, 주로 에픽과 사용자 스토리입니다.

번다운 차트 / 번업 차트

번다운 차트（Burndown Chart）

스프린트 중의 잔여 작업 추이를 시각화하는 그래프. 이상선（균등하게 줄어드는 선）에 대해 실적이 어떻게 움직이는지를 봅니다.

잔여pt
24┤●
22┤  ●
20┤    ●─ 이상선 ────
18┤      ╲╲
16┤        ●（실적, 다소 지연）
14┤          ●
12┤            ╲
 0┤──────────────●
    Day1 Day3 Day5 Day7 Day10

실적이 이상선보다 계속 위에 있으면 → 스프린트 목표 달성이 위험한 신호. 빨리 대응（스코프 감소·지원 요청）을 검토합니다.

번업 차트（Burnup Chart）

완료량과 스코프를 별도의 선으로 표시하는 것. 스코프 변경이 발생했을 때 번다운보다 상황이 보기 쉽기 때문에, 릴리즈 계획 추적에 자주 사용됩니다.

MVP와 MMP

MVP（Minimum Viable Product）

가설 검증에 필요한 최소한의 프로덕트. Eric Ries의 『린 스타트업』으로 널리 알려진 개념.

FitLog의 MVP 예시: "사용자가 앱을 열어 수동으로 주행 거리를 기록하고, 과거 기록을 리스트로 볼 수 있다"만. 그래프도 알림도 SNS 연동도 없음. 이것으로 "사람들은 트레이닝 기록 앱에 돈을 낼까?"라는 가설을 검증합니다.

MMP（Minimum Marketable Product）

시장에 내놓아 팔 수 있는 최소한의 프로덕트. MVP보다 한 단계 풍부합니다. MVP는 내부/한정 사용자 대상, MMP는 일반 공개, 라는 이미지.

타임박스（Timebox）

스크럼 이벤트에는 최대 시간이 정해져 있습니다. 이것이 타임박스입니다.

타임박스의 효과:

• 논의의 발산을 막음: 시간이 한정되어 있으므로 본질적인 이야기에 집중
• 회의의 비대화를 막음: 연장을 허용하면 무한히 늘어남
• 빨리 끝나는 것도 OK: 목적이 달성되면 짧아도 됨

스파이크（Spike）

기술 조사나 불확실성 해소를 위해 행하는 타임박스 붙은 작업. XP에서 유래한 용어이지만 스크럼에서도 널리 사용됩니다.

사용해야 할 상황:

• "새 라이브러리로 이것을 실현할 수 있는지 불명확" → 1일 타임박스로 검증
• "기존 코드의 이 부분의 리팩터 비용을 예측할 수 없다" → 반나절로 조사
• "API 응답 속도가 요건을 충족하는지 불명확" → 시제품 제작

스파이크의 산출물은 코드가 아니라 지식입니다. 검증용으로 작성한 코드는 기본적으로 버립니다.

WIP 제한（Work In Progress Limit）

동시에 진행하는 작업의 수를 제한하는 규칙. 칸반에서 유래하지만, 스크럼 팀에서도 도입이 늘고 있습니다.

예: "In Progress 열에는 동시에 3개까지"

효과:

• 완료에 집중: 5개를 반만 진행하는 것보다, 3개를 완료시키는 것이 가치가 나옴
• 병목이 보임: 막히는 장소가 명확해짐
• 멀티태스킹의 비용을 줄임: 컨텍스트 스위치는 생산성을 크게 떨어뜨림

기술적 부채（Technical Debt）

Ward Cunningham이 제창한 개념으로, 미래의 유지 보수성을 희생해서 지름길로 구현한 결과, 나중에 이자（추가 비용）를 지불하게 되는 상태를 빚에 비유한 것입니다.

종류:

• 의도적인 부채: "기한 우선으로 대충 구현, 나중에 리팩터"라고 알고 만드는 것
• 의도치 않은 부채: 지식 부족이나 설계 실수로 발생
• 환경적 부채: 주변 기술이 오래되면서 상대적으로 발생（레거시화）

그 외, 빠르게 알아두고 싶은 용어

자주 있는 오해와 함정

"문서를 쓰지 않는다"는 오류

애자일 선언의 "포괄적인 문서보다 동작하는 소프트웨어"를 곡해해서, 문서 제로로 돌진하는 팀을 봅니다. 동작에 필요한 문서는 쓴다는 것이 정답입니다.

"계획하지 않는다"도 오류

"변화에 대한 대응"을 방패로 계획을 포기하는 것도 NG입니다. 스크럼에는 복수 레이어의 계획（프로덕트 목표, 스프린트 목표, 데일리 계획）이 있습니다. 계획하지 않는 것이 아니라, 적응적으로 계획하는 것이 애자일입니다.

데일리 스크럼이 "보고회"가 되어 있다

PM이나 매니저에 대한 진척 보고회가 된 데일리 스크럼은, 본래의 목적을 잃은 것입니다. 데일리는 개발자를 위한, 개발자에 의한 검사와 적응의 자리입니다.

스프린트 길이가 자꾸 바뀐다

"이번에는 바쁘니까 3주로" "다음에는 1주일로 해보자"라고 바꾸면, 벨로시티（팀의 속도）를 측정할 수 없게 됩니다. 스프린트 길이는 고정하는 것이 원칙입니다.

애자일/스크럼이 맞지 않는 케이스

만능이 아닙니다. 다음과 같은 상황에서는, 다른 접근이 적합한 가능성이 있습니다.

• 요건이 완전히 고정되어 있어 변경이 거의 발생하지 않는 경우（예: 법규 대응）
• 안전성이 극도로 중요해서 단계적 릴리즈가 허용되지 않는 영역
• 팀이 극단적으로 대규모라서 조정 비용 쪽이 더 높아지는 경우

다만 대규모 스크럼（LeSS, SAFe 등）의 스케일링 기법도 있으므로, "규모가 크니까 무리"라고 바로 결론 내리는 것은 이릅니다.

마치며

• 애자일은 사고방식·가치관. "짧은 주기로 동작하는 것을 내보낸다" "변화를 환영한다"가 핵심
• 스크럼은 애자일을 실천하는 대표적인 프레임워크
• 스크럼은 "3가지 책무·5가지 이벤트·3가지 산출물"로 구성되며, 고정 기간의 스프린트를 반복
• 형식만 흉내 내면 형식화됩니다. 가치관의 이해가 먼저, 프레임워크는 그 다음

"스크럼을 하는 것"이 목적이 아니라, "가치 있는 프로덕트를 지속적으로 전달하는 것"이 목적입니다. 프레임워크는 그를 위한 도구로 보는 것이, 오래 함께 하는 비결이라고 생각합니다.

참고문헌

• 애자일 소프트웨어 개발 선언
• 스크럼 가이드 2020
• Jeff Sutherland『스크럼 — 일이 4배 빨라지는 "세계 표준" 팀 전술』