애자일 반복수행 계획서와 평가서로 관리하는 개발 사이클
애자일 개발에서 반복수행 계획서와 평가서를 연결해 목표, 리스크, 성과 지표, 개선 활동을 관리하는 방법을 정리한다.
2026-08-14 · 최초 발행 2025-05-23
반복주기의 실행 범위를 문서로 맞춘다
애자일 개발에서 반복수행 계획서(Iteration Plan)는 특정 반복주기(Sprint/Iteration)에 팀이 처리할 일을 합의하는 문서다. 무엇을 구현할지뿐 아니라 어떻게 진행하고 언제까지 끝낼지, 예상되는 리스크는 무엇인지까지 한데 정리한다.
계획서가 있으면 우선순위에 따라 개발을 진행하면서 프로젝트 리스크를 일찍 식별할 수 있다. 반복주기 목표는 명확한 비즈니스 목표로 두고 SMART(Specific, Measurable, Achievable, Relevant, Time-bound) 원칙에 맞춘다.
계획에는 해당 주기에 구현할 사용자 스토리 또는 기능 목록을 담는다. 각 백로그 아이템에는 우선순위, 예상 소요시간, 담당자를 연결하고, 아이템은 개발·테스트·검토 같은 실제 작업으로 다시 분해한다. 기술적 리스크와 일정 리스크의 대응 전략, 팀원별 가용 시간과 외부 의존성도 함께 확인해야 한다.
대형 금융 시스템 개발 프로젝트에서 작성한 2주 단위 스프린트 계획은 다음과 같다.
반복주기: Sprint #5 (2023.10.01 - 2023.10.14)
목표: 고객 계좌 관리 기능 구현 및 보안 프로토콜 적용
백로그 아이템:
1. [US-145] 고객 계좌 생성 기능 (8 Story Points, 담당: 김개발)
2. [US-146] 계좌 정보 조회 API (5 Story Points, 담당: 이서버)
3. [US-150] 보안 인증 프로토콜 적용 (13 Story Points, 담당: 박보안)
작업 분해:
- [US-145] 계좌 생성
* DB 스키마 설계 (1d)
* 비즈니스 로직 구현 (2d)
* 단위 테스트 작성 (1d)
* UI 구현 (1d)
리스크:
- 보안 프로토콜 적용 시 기존 기능과의 충돌 가능성
* 대응전략: 점진적 적용 및 회귀 테스트 강화
평가서는 다음 반복의 입력값이 된다
반복수행 평가서(Iteration Assessment)는 반복주기가 끝난 뒤 성과와 과정을 기록하고 평가하는 문서다. 목표 달성 여부를 확인하는 데서 끝나지 않고, 다음 계획에서 바꿔야 할 내용을 도출하는 역할을 맡는다.
평가서에는 계획 대비 실제 목표 달성도와 미달성 원인을 기록한다. 완료한 스토리 포인트 수인 속도(Velocity), 결함 수와 테스트 커버리지 같은 품질 지표, 작업 흐름과 병목 현상 같은 프로세스 지표도 함께 본다. 기술적 발견사항, 프로세스 개선점, 팀 협업에서 얻은 학습은 다음 반복주기에서 실행할 개선 활동으로 구체화한다. 이때 새로 식별한 리스크와 기존 리스크의 상태도 갱신한다.
앞선 금융 시스템 개발 프로젝트의 Sprint #5 평가는 다음과 같이 남길 수 있다.
반복주기: Sprint #5 (2023.10.01 - 2023.10.14) 평가
목표 달성도:
- 계좌 생성 기능: 100% 완료
- 계좌 정보 조회 API: 80% 완료 (성능 테스트 미완료)
- 보안 인증 프로토콜: 50% 완료 (통합 과정에서 예상치 못한 이슈 발생)
성과 지표:
- 계획 대비 완료율: 76% (26 중 19.5 SP 완료)
- 결함 발견: 7건 (심각: 1, 보통: 3, 경미: 3)
- 테스트 커버리지: 78% (목표: 80%)
학습 내용:
- OAuth 2.0 적용 시 레거시 시스템과의 호환성 문제 발견
- DB 트랜잭션 처리 최적화 방안 도출
개선 사항:
- 보안 모듈 적용 전 통합 테스트 강화 (담당: 박보안, 다음 스프린트)
- API 성능 테스트 자동화 도구 도입 (담당: 이서버, 2주 이내)
계획과 평가를 PDCA로 연결하는 방식
두 문서는 독립된 산출물이 아니다. 계획서는 Plan을, 개발 활동은 Do를, 평가서는 Check를, 평가에서 정한 개선 활동은 Act를 담당한다. 개선 활동이 다음 반복수행 계획서에 반영돼야 이 순환이 끊기지 않는다.
이전 평가서의 개선 사항은 다음 계획서에 명시적으로 포함한다. 미완료 작업은 우선순위를 다시 조정하고, 여러 반복주기에 걸친 성과 지표는 팀 역량을 파악하고 속도(Velocity) 예측 정확도를 높이는 데 사용한다. 문서를 형식적 산출물이 아니라 개선 도구로 다루려면 투명한 평가와 건설적 피드백을 허용하는 팀 문화도 필요하다.
문서가 현실을 반영하도록 운영한다
계획 단계에서는 팀의 실제 역량과 가용 시간을 반영해 작업량을 정하고, 과거 성과 데이터를 예측의 근거로 쓴다. 각 백로그 아이템에는 완료 여부를 객관적으로 판단할 수 있는 완료 기준(Definition of Done)을 둬야 모호한 상태 때문에 작업이 지연되는 일을 줄일 수 있다. 작업량과 소요시간은 하향식으로 정하기보다 팀 구성원이 함께 논의한다.
평가에서는 주관적 판단만으로 결론을 내리지 않고 측정 가능한 지표와 정성적 평가를 함께 사용한다. 회고는 개인 책임을 묻기보다 시스템의 개선점을 찾는 비난 없는 회고(Blameless Retrospective)로 운영한다. 개선 방향을 추상적으로 남기는 대신, 담당자와 기한이 분명한 실행 항목으로 작성해야 다음 반복주기에 반영할 수 있다.
반복주기 문서 템플릿
반복수행 계획서는 목표, 백로그, 작업 분해, 리스크, 이전 평가에서 이어진 개선 활동을 한 문서에서 확인할 수 있도록 구성한다.
# 반복수행 계획서
## 기본 정보
- 반복주기: [번호]
- 기간: [시작일] ~ [종료일]
- 팀: [팀명]
## 목표
- [명확한 비즈니스 목표 기술]
## 백로그 아이템
| ID | 설명 | 우선순위 | 스토리포인트 | 담당자 |
|----|------|----------|--------------|--------|
| | | | | |
## 작업 분해
| 백로그 ID | 작업 | 예상 소요시간 | 담당자 |
|-----------|------|---------------|--------|
| | | | |
## 리스크 및 대응 전략
| 리스크 | 영향도 | 대응 전략 |
|--------|--------|-----------|
| | | |
## 이전 반복주기에서 반영할 개선사항
- [구체적인 개선 활동 목록]
평가서에는 목표 달성도, 성과 지표, 학습 내용, 개선 사항과 다음 반복주기에 고려할 내용을 남긴다.
# 반복수행 평가서
## 기본 정보
- 반복주기: [번호]
- 기간: [시작일] ~ [종료일]
- 팀: [팀명]
## 목표 달성도
| 목표 | 계획 | 실제 | 달성율 | 미달성 사유 |
|------|------|------|---------|------------|
| | | | | |
## 성과 지표
- 완료된 스토리 포인트: [수치]
- 결함 발견 건수: [수치] (심각: X, 보통: Y, 경미: Z)
- 테스트 커버리지: [수치]%
- 기타 지표: [관련 지표]
## 주요 학습 내용
- [기술적 발견사항]
- [프로세스 관련 인사이트]
- [팀 협업 관련 학습]
## 개선 사항
| 항목 | 책임자 | 기한 | 진행상태 |
|------|--------|------|----------|
| | | | |
## 다음 반복주기 고려사항
- [다음 계획에 반영할 사항]
계획-평가 체계가 바꾸는 프로젝트 운영
규칙적인 계획과 평가를 반복하면 프로젝트 진행 상황을 명확히 파악하고, 문제를 조기에 발견해 일정 지연을 줄일 수 있다. 지속적인 개선은 생산성 향상으로 이어지고, 품질 지표 모니터링은 결함을 일찍 찾는 기반이 된다. 작업 우선순위와 진행 상황을 문서화하면 팀 내부와 이해관계자 사이의 공통 이해도 형성된다.
금융권 핀테크 스타트업 A사의 결제 시스템 개발 프로젝트에서는 체계적인 반복수행 계획-평가 도입 전 평균 일정 지연이 35%였고, 릴리스 후 심각한 결함은 월 평균 5건이었다. 도입 6개월 후 일정 준수율은 93%였으며 심각한 결함은 월 평균 1건 이하로 감소했다. 도입 1년 후에는 팀 생산성이 25% 향상되고 출시 주기가 30% 단축됐다.
반복수행 계획서와 평가서는 문서 작성 자체가 목적이 아니라, 계획과 실행 결과를 다음 반복에 연결하는 관리 장치다. 이 연결이 유지될 때 애자일 팀은 프로젝트의 예측 가능성과 품질을 함께 다룰 수 있다.