---
title: "36장. 애자일 개발의 요구사항"
description: "애자일 개발에서 목표·백로그·정제·수용 조건과 발견 활동을 연결해 요구 근거가 빠른 개발 과정에서 사라지지 않게 한다."
---
{/* v3:question */}
## 이번 장에서 해결할 질문
애자일 개발에서 요구사항을 없애지 않고 점진적으로 구체화하는 방법은 무엇인가?
{/* v3:objectives */}
## 학습 목표
학습 목표
- “애자일 개발에서 요구사항을 없애지 않고 점진적으로 구체화하는 방법은 무엇인가?”에 답하는 데 필요한 개념과 근거를 설명한다.
- 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.
{/* v3:concepts */}
## 핵심 개념
애자일 개발에서는 요구사항이 사라지는 것이 아니라 발견·상세화·검증·변경의 주기가 짧아진다. 백로그 항목이 짧다는 사실과 분석이 얕다는 것은 같은 말이 아니며, 대화를 강조한다는 이유로 정책·품질·데이터 책임을 기억에만 맡길 수도 없다.
이 장에서는 제품 목표, 백로그 정제, 사용자 스토리, 인수 조건과 반복적 검증이 요구사항 활동을 어떻게 분담하는지 다룬다. 필요한 시점에 필요한 만큼 상세화하되 장기적인 근거와 추적을 잃지 않고, 피드백을 다음 결정으로 연결하는 방법을 살펴본다.
### 1. 애자일에서도 요구 근거는 남는다
[애자일 선언](https://agilemanifesto.org/)은 오른쪽 항목에도 가치가 있음을 전제로 상호작용, 작동하는 소프트웨어, 고객 협력과 변화 대응을 더 중시한다. 문서·계약·계획을 없애라는 주장이 아니다. [2020 Scrum Guide](https://scrumguides.org/download.html)는 현재 공식판이며 Product Goal, Product Backlog, Sprint Goal, Increment와 Definition of Done을 정의한다. 그러나 Epic, Feature, User Story, Acceptance Criteria, Story Point와 Story Map은 Scrum이 의무화한 요소가 아니다. 팀이 필요에 따라 쓰는 보완 기법을 Scrum의 규칙처럼 가르치지 않는다.
[IREB RE@Agile 자료](https://cpre.ireb.org/en/downloads-and-resources/downloads)는 애자일 환경에서도 요구공학 관점과 기법을 연결해 다룬다. 이것 역시 Scrum의 역할·이벤트·산출물을 추가하는 규칙이 아니라, 목표·가치·이해관계자·품질과 피드백을 분석하는 보완 관점으로 사용한다.
이 장도 실제 Scrum Team과 승인된 Product Goal이 없는 교육용 사례다. `PG`, `EP`, `PBI`, `SG` 식별자는 모두 후보이며 10부의 `FR`을 임의로 대체하지 않는다. 요구 ID는 정책·규제·외부 계약과 장기 추적에 유용하고, 백로그 ID는 가치 전달과 학습의 작업 단위를 관리한다. 둘을 연결하되 똑같은 내용을 두 군데 복사하지 않는다.
첫 흐름은 Product Goal과 사용자 결과를 백로그의 근거로 두는 일이다. Product Goal은 기능 목록의 제목이 아니라 제품이 앞으로 도달하려는 상태를 표현한다. 수강신청 사례에서 `G-01`을 다음 Product Goal 후보로 옮길 수 있다.
> `PG-ENR-01`: 다음 학기 수강신청에서 학생이 자신의 신청 접수·판정 상태와 공개 가능한 이유, 가능한 다음 행동을 스스로 이해하고 회복할 수 있게 하여, 결과를 알 수 없어 발생하는 반복 제출과 첫 30분 수동 재처리를 줄인다.
이 목표는 “상태 화면을 개발한다”보다 넓고 `BR-001`의 50% 수치는 기준선 미확인으로 남긴다. 제품 목표의 성공은 화면 배포가 아니라 실제 반복 제출·수동 처리·이해도와 안전성 지표로 판단한다. 잘못된 승인이나 개인정보 노출을 줄이기 위해 `QR-003`, `QR-006`, `QR-011`을 보호 지표로 둔다.
목표에서 백로그로 내려갈 때 필요한 계층은 조직 규모와 도구에 맞춘다.
| 후보 수준 | 수강신청 예 | 역할 | 장기 추적 |
|---|---|---|---|
| Product Goal `PG-ENR-01` | 상태 이해·회복과 재처리 감소 | 방향과 성과 판단 | `G-01`, `BR-001` |
| Epic `EP-ENR-01` | 안전한 신청 생명주기 제공 | 여러 전달 단위를 묶는 가치 | `UR-001`, `SR-001` |
| Feature | 접수, 판정, 상태, 취소, 운영 회복 | 사용자·시스템 능력 | `FEAT-*`, `FR-*` |
| PBI | 짧은 주기에 완료 가능한 결과·학습 | 순서화·실행·검증 단위 | 관련 요구·시험·결정 |
계층이 깊다고 좋은 것은 아니다. 항목 하나가 목표와 연결되고 팀이 다음 결정을 내릴 수 있다면 충분하다. 같은 기능을 Epic·Capability·Feature·Story에 반복해 복사하면 상태 불일치만 늘어난다. 법규나 계약 요구처럼 반드시 보존해야 하는 원문은 요구 저장소에 두고 백로그에서 링크한다.
Product Backlog의 순서는 가치만으로 정하지 않는다. 사용자 피해, 정책 시행일, 학사 일정, 규칙·데이터 의존성, 기술·운영 위험, 학습 필요와 팀 용량을 함께 본다. “우선순위 1”이라는 숫자보다 왜 지금 필요한지, 무엇이 바뀌면 다시 정할지를 적는다.
| 백로그 후보 | 기대 결과 | 선행·위험 | 순서 근거 후보 |
|---|---|---|---|
| `PBI-RECEIPT-01` 내구 접수·중복 안전 | 제출 뒤 접수 여부를 다시 찾음 | 요청 ID·상태 모델 | 다른 흐름의 안전 기반 |
| `PBI-STATUS-01` 상태·사유 조회 | 결과를 알 수 없는 상태와 반복 제출 감소 | `FR-003`, 공개 사유 정책 | `PG-ENR-01` 직접 기여 |
| `PBI-PENDING-01` 규칙 실패 보류·재평가 | 자동 오승인 없이 회복 | 외부 연계·운영 절차 | 고위험 `IR-001` 조기 학습 |
| `PBI-CANCEL-01` 허용 취소 | 학생이 신청을 되돌림 | 상태·좌석 경합 | 생명주기 완결 |
| `PBI-NOTIFY-01` 보조 알림 | 상태 변경 인지 보조 | 채널·개인정보·중복 | 공식 상태 조회 뒤 배치 가능 |
`PBI-NOTIFY-01`을 먼저 만들면 눈에 보이는 결과는 빠르지만 공식 상태 조회가 없을 때 알림 유실·지연을 회복할 수 없다. 가치와 의존성을 함께 보면 `PBI-RECEIPT-01`, `PBI-STATUS-01`이 앞설 근거가 생긴다. 다만 실제 사용자 조사와 기술 위험이 다르면 순서를 바꾼다.
두 번째 흐름은 Epic·Feature·Story를 가치와 학습 단위로 분해하는 일이다. 큰 항목을 화면, API, 데이터 계층으로 수평 분할하면 각 스프린트 끝에 사용자 결과를 확인하기 어렵다. 가능한 한 하나의 얇은 흐름이 화면·업무 규칙·API·데이터·시험을 통과하도록 수직 분할한다.
`PBI-STATUS-01`은 다음처럼 단계화할 수 있다.
1. 학생이 자신의 신청 ID로 접수·처리 상태와 마지막 갱신 시각을 다시 확인한다.
2. 승인·거절에서 공개 가능한 사유와 다음 행동을 확인한다.
3. 규칙 장애 보류에서 원인 범주와 재평가·문의 경로를 확인한다.
4. 취소·늦은 응답·권한 만료에서 최신 상태로 안전하게 회복한다.
첫 단계가 가치를 주려면 인증, 객체 수준 인가, 최소 데이터와 기본 접근성이 포함돼야 한다. “백엔드 API만 먼저 완료”할 수는 있지만 그것은 기술 위험을 줄이는 활성화 작업이지 사용자 가치 Increment라고 부르지 않는다. 연구·시제품·아키텍처 탐색 항목도 기대 학습, 시간 제한과 결정 연결을 둔다.
스토리 맵은 이런 수직 분할을 대화하는 보조 도구다. Scrum의 필수 산출물은 아니며 사용자 활동 순서와 릴리스 절편을 함께 보는 데 쓸 수 있다. `FLOW-ENR-01`을 활동 축으로 놓으면 다음과 같다.
| 사용자 활동 | 탐색 | 신청 준비·제출 | 상태 이해 | 회복·취소 |
|---|---|---|---|---|
| 기본 과업 | 강좌 조회·상세 | 대상 확인·한 번 제출 | 접수·승인·거절 조회 | 허용 취소·다른 강좌 탐색 |
| 실패·경계 | 빈 결과·오래된 정보 | 중복 클릭·세션 만료 | 보류·응답 유실·권한 오류 | 취소 경합·늦은 판정 |
| 품질 횡단 | 접근성·성능 | 중복 안전·보안 | 최신성·개인정보·이해도 | 감사·복구·운영 관찰 |
첫 릴리스를 정상 흐름만 잘라 내는 방식은 위험하다. 수강신청에서는 응답 유실과 중복 제출이 곧 `G-01`의 문제이므로 기본 절편에 `FR-004`와 상태 재조회가 들어가야 한다. 대신 알림 채널 확대, 복잡한 필터 저장, 아직 정책이 없는 대기명단은 뒤로 미룰 수 있다. “최소”는 화면 수가 적다는 뜻이 아니라 목표를 안전하게 검증할 최소 완결 흐름이라는 뜻이다.
릴리스 후보를 비교할 때는 포함 항목과 함께 배우려는 것을 적는다.
| 절편 후보 | 포함 | 학습 질문 | 제외·후속 |
|---|---|---|---|
| `REL-ENR-01` 안전한 접수 확인 | 접수 ID, 중복 안전, 기본 상태 조회 | 재제출 대신 조회하는가? | 상세 사유·알림 |
| `REL-ENR-02` 설명 가능한 판정 | 승인·거절 사유, 보류, 다음 행동 | 문의·수동 처리가 줄어드는가? | 채널 개인화 |
| `REL-ENR-03` 회복 가능한 생명주기 | 취소 경합, 재평가, 운영 관찰 | 장애 뒤 불일치 없이 회복하는가? | 미승인 대기명단 |
릴리스 경계는 Sprint 경계와 같지 않을 수 있다. 여러 Increment를 모아 배포할 수 있지만 배포 지연의 이유와 Product Goal 학습 비용을 본다. 규제 승인, 학사 일정, 데이터 이관 때문에 정해진 전환 창이 있더라도 기능 토글·제한 사용자 검증·모의 부하처럼 더 일찍 증거를 얻을 방법을 찾는다. 배포와 출시, 완료와 수용을 같은 상태로 합치지 않는다.
사용자 스토리 형식은 대화를 촉발하는 도구다. “학생으로서 상태를 보고 싶다. 안심하기 위해서다”만으로 개발 준비가 되지 않는다. 다음 스토리 카드는 목적을 보존하면서 필요한 조건을 붙인 예다.
| 항목 | `PBI-STATUS-01` 후보 내용 |
|---|---|
| 사용자 결과 | 학생이 재제출하지 않고 자신의 신청 현재 상태·사유·다음 행동을 이해함 |
| 범위 | 자신의 신청 조회, 접수·보류·승인·거절·취소 표현 |
| 규칙·제약 | `FR-003`, `UI-001`, `QR-006`, `QR-007`, `QR-011` |
| 수용 예 | 상태를 색상에만 의존하지 않음, 다른 학생 ID 비노출, 기준 시각 제공 |
| 열린 질문 | 공개 사유 범위, 오래된 상태 허용 시간, 지원 경로 |
| 증거 | `SCR-STATUS-01`, `API-STATUS-01`, `TC-FR-003-01`, 사용자 관찰 |
작은 항목은 업무 위험까지 작다는 뜻이 아니다. 마지막 좌석과 중복 안전성은 한 화면 변화처럼 보여도 동시성 불변조건을 가진다. 분할할 때 보안, 접근성, 감사, 마이그레이션을 나중의 “비기능 스프린트”로 밀지 않는다. 각 얇은 흐름에 필요한 품질을 포함하고, 시스템 전체 부하·복구 시험은 별도 계획으로 누적한다.
세 번째 흐름은 refinement에서 조건·의존성·수용 기준을 대화로 구체화하는 일이다. Scrum Guide에서 Product Backlog refinement는 항목을 더 작고 정밀하게 나누고 설명·순서·크기 같은 세부를 더하는 지속 활동이다. 정식 회의 하나나 요구 분석가 한 사람의 작업으로 한정되지 않는다.
### 2. 정제와 안전한 릴리스 절편
refinement 입력은 사용자 증거, 정책·규칙, 운영 데이터, 설계 위험과 이전 Increment의 피드백이다. Product Owner는 가치와 순서를 책임지지만 규칙의 사실, 기술 실현성, 시험 가능성과 운영 회복을 혼자 결정하지 않는다. 업무·정책 책임자, 개발자, 시험·보안·데이터·운영 담당과 필요한 사용자가 함께 불확실성을 줄인다.
refinement 질문은 다음 순서가 유용하다.
- 이 항목이 어느 목표·사용자 결과와 연결되는가?
- 정상·경계·실패 상태에서 누가 무엇을 관찰해야 하는가?
- 적용 규칙·데이터·외부 서비스의 원천과 기준 시점은 무엇인가?
- 품질·보안·접근성·운영 제약을 이번 Increment에서 어떻게 만족하는가?
- 독립적으로 검증 가능한 더 작은 가치 또는 학습 단위는 무엇인가?
- 무엇이 아직 미결이고 누가 언제 결정해야 하는가?
수용 조건은 대화를 끝내는 체크리스트가 아니라 예제와 경계를 공유하는 수단이다. `PBI-PENDING-01`에 “오류를 처리한다” 대신 다음 예를 둔다.
```text
Given 신청 의도가 유효하게 접수됐고 규칙 서비스 제한 시간이 정해졌을 때
When 응답이 제한 시간을 넘기거나 필수 규칙 버전이 없으면
Then 자동 승인을 만들지 않고 보류·원인 코드·신청 ID를 기록하며
And 학생은 같은 ID로 현재 상태와 다음 확인 경로를 조회할 수 있다.
```
예제 하나가 전체 규칙을 대표하지 않는다. 무효 응답, 늦은 성공, 재평가 중 중복, 취소와 경합, 권한 만료를 시험 조건으로 더한다. Given-When-Then 형식을 강요하기보다 입력·사건·결과와 불변조건이 분명한지 본다.
“준비됨”을 별도 Definition of Ready로 운용할 수 있지만 Scrum의 공식 의무는 아니다. 엄격한 진입 서류로 만들어 학습을 막지 않고, 팀이 선택할 수 있을 만큼 목표·수용 예·의존성·열린 위험이 이해됐는지 확인하는 작업 정책으로 둔다. 불확실성을 0으로 만드는 것이 아니라 스프린트 안에서 관리 가능한 수준으로 줄인다.
Definition of Done은 개별 스토리의 업무 수용 조건과 다르다. Increment가 요구되는 품질 상태를 충족했다는 공통 설명이다. 수강신청 후보에는 코드·계약 시험, 접근성 점검, 객체 수준 인가, 로그 개인정보 확인, 추적 갱신, 운영 관찰과 문서·마이그레이션 조건을 포함할 수 있다. 조직 표준이 있으면 최소 기준으로 따르고 팀이 강화할 수 있다.
| 구분 | 질문 | 예 |
|---|---|---|
| 수용 조건 | 이 PBI가 의도한 업무 결과를 냈는가? | 보류에서 자동 승인 없음 |
| Definition of Done | Increment가 팀이 합의한 공통 품질 상태에 있는가? | 테스트·보안·관찰·문서 기준 충족 |
| Sprint Goal | 이번 Sprint가 왜 가치 있는가? | 학생이 접수 상태를 재제출 없이 다시 찾음 |
| Product Goal | 여러 Sprint가 향하는 장기 결과는? | 결과를 알 수 없는 상태와 수동 재처리 감소 |
네 번째 흐름은 구현 결과와 사용자 피드백으로 요구·순서를 갱신하는 일이다. Sprint Review는 완료 항목을 승인받는 시연회로만 쓰지 않는다. Product Goal을 향한 결과, 환경 변화와 이해관계자 피드백을 바탕으로 다음 할 일을 조정한다. 완료되지 않은 항목을 완료한 것처럼 시연하거나 수용 조건 일부를 다음 스프린트로 몰래 넘기지 않는다.
`PBI-STATUS-01`을 배포하거나 현실적인 시제품으로 검증한 뒤에는 다음을 함께 본다.
| 피드백·증거 | 가능한 해석 | 백로그 반응 후보 |
|---|---|---|
| 반복 제출 감소, 상태 조회 증가 | 공식 상태 조회가 회복 행동을 대체할 가능성 | 더 넓은 표본과 피크 기간 확인 |
| 보류를 좌석 대기명단으로 오해 | 용어·정책 경계가 불명 | `UI-001`과 사용자 설명 재정의 |
| 거절 사유 이해는 높지만 문의 지속 | 다음 행동·정책 설명 부족 가능 | 사유 공개·지원 흐름 PBI 추가 |
| 조회는 빠르나 다른 학생 ID 노출 | 가치보다 보안 불변조건 위반 | 릴리스 중단·결함·회귀 우선 |
| 알림 수신은 높으나 상태와 불일치 | 알림이 공식 상태처럼 사용됨 | 계약·문구·지연 처리 재설계 |
피드백은 요구를 자동으로 바꾸지 않는다. 한 사용자의 의견, 분석 지표, 운영 사건의 대표성과 원인을 확인하고 정책·계약·보안처럼 별도 권한이 필요한 변경을 구분한다. `CR-003`의 우선권 요구가 Sprint Review에서 제안돼도 Product Owner가 즉시 정책으로 확정할 수 없다. 정책 책임자 결정과 영향 분석 뒤 백로그와 장기 요구를 함께 갱신한다.
Scrum 이벤트마다 요구사항을 다루는 초점도 다르다. Sprint Planning에서는 Product Goal과 현재 증거를 바탕으로 이번 Sprint의 가치 목표와 선택 항목, 실행 가능성을 협의한다. Daily Scrum은 요구를 새로 승인하는 회의가 아니라 Sprint Goal을 향한 진행 계획을 개발자가 조정하는 자리다. Sprint Review에서는 결과와 환경 변화를 이해관계자와 함께 보고 백로그의 다음 선택을 조정한다. Retrospective는 사용자 요구가 아니라 팀의 품질·협업 방식과 Definition of Done을 개선한다. 이벤트 이름보다 이 판단이 실제로 이루어지는지가 중요하다.
Sprint 중 새 사실이 나오면 무조건 다음 Sprint로 미루거나 현재 범위를 조용히 바꾸지 않는다. Sprint Goal에 영향이 없는 상세화는 개발자와 Product Owner가 협력해 조정할 수 있다. 목표 자체가 무의미해졌거나 안전 불변조건을 만족할 수 없다면 투명하게 재계획한다. 완료 수를 지키려고 잘못된 요구를 구현하는 것은 예측 가능성을 높이지 않는다.
반복 개발에서는 요구 부채도 관리해야 한다. 근거 없는 항목, 계속 미뤄지는 규칙 결정, 수용 조건 없는 품질 요구, 테스트되지 않은 가정과 문서-동작 불일치를 쌓아 두면 속도가 빨라 보이다가 운영과 변경에서 비용이 폭발한다. 이를 문서 페이지 수가 아니라 위험으로 표현한다.
| 요구 부채 신호 | 위험 | 대응 후보 |
|---|---|---|
| 같은 질문이 refinement마다 반복 | 결정·출처 기록 부재 | 결정 로그와 소유자 지정 |
| 완료 뒤 수용 해석이 바뀜 | 예제·용어 합의 부족 | 수용 예와 업무 규칙 보강 |
| 품질 항목이 매번 뒤로 밀림 | 통합·릴리스 위험 누적 | Definition of Done과 품질 백로그 연결 |
| 사용자 피드백이 목표와 연결되지 않음 | 인기 의견이 순서를 지배 | Product Goal·지표·표본 근거 기록 |
| 오래된 PBI가 계속 이동 | 가치·의존·범위 불명 | 분할·재조사·삭제 결정 |
오래된 항목을 보관한다고 추적이 되는 것은 아니다. 더 이상 목표에 기여하지 않는 PBI는 삭제하되 이유와 관련 요구 상태를 갱신한다. 계약·정책 때문에 구현 의무가 남는다면 제품 우선순위만 내려서 해결할 수 없고 권한 있는 변경이 필요하다.
백로그 항목을 삭제하거나 순서를 내릴 때도 근거를 남긴다. 학습으로 가설이 반박됐는지, 목표가 바뀌었는지, 외부 의존이 막혔는지, 비용 대비 가치가 낮아졌는지를 기록한다. 완료 항목도 요구·규칙·운영 기준이 바뀌면 다시 작업이 필요하다. “Done”은 영구 불변이 아니라 그 시점의 Definition of Done과 수용 조건을 충족했다는 뜻이다.
추적은 거대한 행렬만을 의미하지 않는다. 작은 팀은 백로그 링크, 코드·시험 태그, 설계 결정과 자동 배포 기록으로 필요한 연결을 만들 수 있다.
링크의 강도는 위험에 맞춘다. 문구 실험에는 가벼운 연결로 충분할 수 있지만 학칙 판정, 좌석, 개인정보와 계약 의무는 안정된 요구 ID·규칙 버전·감사·시험까지 보존한다. 도구가 자동 연결해도 링크가 무엇을 의미하는지, 누가 갱신하는지 정한다.
애자일 환경의 변경 관리는 별도 대형 회의를 없앨 수 있어도 결정 책임을 없애지 않는다. Product Backlog의 순서는 Product Owner가 관리하지만 법·학칙 변경 권한, 예산·계약 조정과 위험 수용 권한은 조직 거버넌스에 남는다. 팀 내부의 가역적 설계 선택과 외부 의무 변경을 다른 흐름으로 다룬다.
계획 기반과 애자일의 차이는 요구사항 공학의 유무가 아니다. 계획 기반은 더 큰 합의 단위와 공식 기준선을 주로 사용하고, 애자일은 목표 아래 작은 백로그 단위로 상세화·검증·재순서를 자주 수행한다. 규제·조달 환경에서도 Sprint를 쓸 수 있고, 애자일 팀도 릴리스 기준선이나 계약 게이트를 가질 수 있다.
이 장에서 정리한 결과는 **목표-백로그 계층**, **가치·위험 기반 순서표**, **refinement 질문과 수용 예**, **Definition of Done 후보**, **Sprint 피드백-학습 기록**이다. 다음 장에서는 전달 주기보다 한 단계 앞서 문제·기회·결과를 탐색하고, 어떤 해법을 만들기 전에 가설을 반증 가능한 증거로 바꾸는 제품 환경을 다룬다.
### 3. 백로그 산출물과 인계
{/* v3:case */}
## 수강신청 사례에 적용
수강신청 사례의 결정·근거·남은 쟁점을 36장에서 다룬 기준으로 구분한다.
{/* v3:criteria */}
## 판단 기준과 흔한 오류
:::warning[판단하기 전에 확인]
- 결정이 확인 가능한 출처와 근거를 가지고 있는가?
- 구현·검증·변경에 필요한 다음 행동과 책임자가 분명한가?
:::
{/* v3:practice */}
## 직접 해보는 실습
1. **1. 대상 선택**
현재 프로젝트 산출물 중 이 장의 질문과 관련된 항목 하나를 고른다.
2. **2. 근거와 예외 표시**
본문의 판단 질문으로 누락된 근거와 예외를 표시한다.
3. **3. 다음 행동 기록**
확인할 책임자, 필요한 최소 증거와 다음 행동을 기록한다.
{/* v3:summary */}
## 핵심 요약
:::success[이 장에서 가져갈 기준]
애자일 개발에서 목표·백로그·정제·수용 조건과 발견 활동을 연결해 요구 근거가 빠른 개발 과정에서 사라지지 않게 한다.
:::
{/* v3:next */}
## 관련 도구와 다음 경로
학습 순서에 따라 다음 판단 주제로 이어갑니다.