5장. 최소 세트와 확장 세트
이 장의 목적
프로젝트 규모와 복잡도에 따라 산출물 세트를 어떻게 고를지 기준을 제시한다. 3개, 10개, 12개, 30개, 35개는 숫자 목표가 아니라 복잡도에 맞는 권장 시작점이다. 어떤 세트를 언제 확장해야 하는지도 함께 다룬다.
1. 왜 산출물 세트를 규정하는가
모든 프로젝트가 같은 문서 세트를 필요로 하지는 않는다. 단순한 과제에 과도한 문서 체계를 올리면 실행 속도가 떨어지고, 복잡한 과제에 최소 문서만 두면 정합성이 무너진다.
세트를 규정하는 이유는 두 가지다.
- 필요한 문서를 빠뜨리지 않기 위해
- 필요 없는 문서를 습관적으로 늘리지 않기 위해
세트는 문서 수를 세는 방식이 아니라, 복잡도에 맞는 최소 안전 장치를 정하는 방식이다.
2. 복잡도 진단 기준
세트를 고르기 전에 먼저 현재 과제의 복잡도를 진단해야 한다. 이 책은 복잡도를 두 단계로 본다.
첫째, 도메인 복잡도다.
- 규칙과 예외가 많은가
- 상태 전이와 분기 판단이 많은가
- 운영/정책과 기능 구현이 강하게 얽혀 있는가
둘째, 협업 복잡도다.
- 이해관계자가 많은가
- 개발, QA, 운영, 디자인 등 여러 역할이 함께 움직이는가
- 변경 이력과 승인 구조가 중요한가
이 두 축이 모두 낮으면 최소 세트로도 충분할 수 있다. 둘 중 하나라도 높아지면 확장 세트가 필요하다.
3. L1~L4 복잡도 가이드
L1. 단순 기능 또는 개인 과제
- 규칙이 단순하다
- 예외가 적다
- 협업 인원이 적다
- 빠른 검증이 우선이다
L2. 소규모 팀 과제
- 기본 정책과 예외가 존재한다
- 기능 간 연결이 조금씩 생긴다
- 개발·기획·디자인 협업이 필요하다
L3. 중간 이상 복잡도 과제
- 예외와 분기 규칙이 많다
- 운영 정합성이 중요하다
- 여러 문서 간 추적성과 승인 구조가 필요하다
L4. 고복잡도 또는 장기 운영 과제
- 도메인 규칙이 많고 빈번히 바뀐다
- 여러 팀이 동시에 참조한다
- 정책, 흐름, 판단, 구현, 검증이 모두 분리돼야 한다
- 변경 영향 추적과 운영 거버넌스가 필수다
이 레벨은 절대 평가가 아니라, 어느 정도 세트가 필요한가를 결정하는 실무용 진단 틀이다.
복잡도 레벨과 세트 크기의 대응은 아래와 같다. 두 축이 모두 낮은 경우부터 권장 세트를 시작점으로 삼는다.
| 복잡도 레벨 | 권장 시작 세트 | 핵심 조건 |
|---|---|---|
| L1 (단순) | 3개 세트 | 규칙 단순, 협업 인원 소수 |
| L2 (소규모 팀) | 10개 세트 | 기본 정책과 예외 존재, 기획·개발·디자인 협업 |
| L2~L3 (기본 협업+인터페이스) | 12개 세트 | 정책 분리와 API·화면 검토까지 필요 |
| L3 (중간 이상) | 30개 세트 | 다수 이해관계자, 추적성·운영 정합성 필요 |
| L4 (고복잡도) | 35개 세트 | 장기 운영, 배포·롤백·런북까지 필요 |
4. 세트별 구성과 적용 맥락
아래 표는 현재 원고에서 설명한 세트별 대표 산출물을 한눈에 정리한 것이다. 여기서 3개, 10개, 12개, 30개, 35개는 절대적인 문서 목록 번호라기보다, 프로젝트 복잡도에 따라 권장되는 세트 규모를 뜻한다.
| 세트 | 적용 맥락 | 대표 산출물 |
|---|---|---|
| 3개 세트 | 아이디어 검증, 개인 프로젝트, 매우 단순한 기능 | 문제 정의 또는 간단한 목표 문서 / PRD 또는 기능 범위 문서 / 최소 사양 또는 완료 기준 문서 |
| 10개 세트 | 소규모 팀, 스프린트 단위 과제 | RIB / 문제 정의 / 범위 정의 / PRD / NFR / 시나리오 / AC / 사양서 / 테스트케이스 / Decision Log |
| 12개 세트 | 기본 협업 구조에 정책·API·프로토타입까지 필요한 과제 | 기능 분류 체계 / 문제 정의 / 범위 정의 / PRD / NFR / 우선순위 매트릭스 / 시나리오 / AC / 정책서 / 사양서 / API 명세서 / UI/UX 프로토타입 |
| 30개 세트 | 중규모 팀, 분기 단위 프로젝트 | 도메인별 정책 분리 문서 / BPMN / DMN / 기능별 사양 문서 / 검증 문서 연결 체계 |
| 35개 세트 | 대규모 팀, 플랫폼, 장기 운영 프로젝트 | 30개 코어 세트 + 이해관계자 맵 / 가정·제약사항 목록 / 배포 계획서 / 롤백 계획서 / 런북 |
4-1. 세트별 실제 권장 문서 목록
아래 목록은 이 책 내부 기준과 기존 부록·가이드에서 반복되는 문서 구성을 기준으로 정리한 권장 목록이다. 모든 프로젝트가 같은 목록을 그대로 가져가야 한다는 뜻은 아니며, 복잡도와 협업 구조에 따라 여기서 줄이거나 확장할 수 있다.
3개 세트 권장 목록
| 번호 | 산출물 |
|---|---|
| 1 | RIB(축약형) 또는 문제 정의/범위 통합 문서 |
| 2 | PRD(축약형) 또는 기능 범위 문서 |
| 3 | 최소 사양서 또는 완료 기준 문서 |
10개 세트 권장 목록
| 번호 | 산출물 |
|---|---|
| 1 | 요구사항 입력 브리프(RIB) |
| 2 | 문제 정의서 |
| 3 | 범위 정의서 |
| 4 | 제품 요구사항 정의서(PRD) |
| 5 | 비기능 요구사항 명세서(NFR) |
| 6 | 시나리오 |
| 7 | 인수 조건(AC) |
| 8 | 사양서 / 상세설계서(FS/SDD) |
| 9 | 테스트케이스(TC) |
| 10 | 결정 로그(Decision Log) |
12개 세트 권장 목록
| 번호 | 산출물 |
|---|---|
| 1 | 기능 분류 체계 |
| 2 | 문제 정의서 |
| 3 | 범위 정의서 |
| 4 | 제품 요구사항 정의서(PRD) |
| 5 | 비기능 요구사항 명세서(NFR) |
| 6 | 우선순위 매트릭스 |
| 7 | 시나리오 |
| 8 | 인수 조건(AC) |
| 9 | 정책서 |
| 10 | 사양서 / 상세설계서(FS/SDD) |
| 11 | API 명세서 |
| 12 | UI/UX 프로토타입 |
30개 세트 권장 목록
| 번호 | 산출물 |
|---|---|
| 1 | 기능 분류 체계 |
| 2 | 요구사항 입력 브리프(RIB) |
| 3 | 문제 정의서 |
| 4 | 범위 정의서 |
| 5 | 제품 요구사항 정의서(PRD) |
| 6 | 비기능 요구사항 명세서(NFR) |
| 7 | 피처 정의 |
| 8 | 시나리오 |
| 9 | 인수 조건(AC) |
| 10 | 프로젝트 정책서 |
| 11 | 결정 모델 표기법(DMN) |
| 12 | 권한 정책 매트릭스 |
| 13 | 비즈니스 프로세스 모델 표기법(BPMN) |
| 14 | 정보 구조도(IA) |
| 15 | 콘텐츠 모델 정의서 |
| 16 | 개체-관계 다이어그램(ERD) |
| 17 | 테이블 정의서 |
| 18 | 데이터 사전 |
| 19 | 시스템 아키텍처 문서(SAD) |
| 20 | 사양서 / 상세설계서(FS/SDD) |
| 21 | API 명세서 |
| 22 | UI/UX 프로토타입 |
| 23 | 테스트케이스(TC) |
| 24 | 테스트 계획서(TP) |
| 25 | 운영 정책서(OPD) |
| 26 | 요구사항 추적 매트릭스(RTM) |
| 27 | 결정 로그(Decision Log) |
| 28 | 변경 이력(Changelog) |
| 29 | 준비 완료 기준(DoR) |
| 30 | 완료 기준(DoD) |
35개 세트 권장 목록
35개 세트는 30개 코어 세트에 아래 5개를 추가한 운영 보강 세트로 본다.
| 추가 번호 | 산출물 |
|---|---|
| 31 | 이해관계자 맵 |
| 32 | 가정·제약사항 목록 |
| 33 | 배포 계획서 |
| 34 | 롤백 계획서 |
| 35 | 런북 / 운영 절차서 |
4-2. 세트별 제외 가능 문서와 확장 트리거
아래 표는 지금 세트에서 당장 넣지 않아도 되는 문서와 어느 시점에 다음 세트로 넘어가야 하는지를 정리한 것이다. 기준은 문서 수가 아니라 해석 비용, 협업 비용, 운영 리스크가 실제로 커졌는가에 둔다.
| 현재 세트 | 지금은 제외 가능하거나 후순위로 둘 문서 | 다음 세트로 확장해야 하는 트리거 |
|---|---|---|
| 3개 세트 | 정책서 / BPMN / DMN / 테스트케이스 / RTM / 운영 문서 | 정책과 예외가 문장 안에서 반복 충돌함 / 구현 기준을 개발자가 암묵적으로 보완함 / 테스트 기준이 구두로만 남음 / 협업 인원이 늘어나 범위 재설명이 반복됨 |
| 10개 세트 | 기능 분류 체계 / 우선순위 매트릭스 / 정책서 / API 명세서 / UI/UX 프로토타입 | 화면 검토와 인터페이스 정의가 별도 문서 없이 불안정함 / 정책과 규칙을 PRD나 사양서 안에 계속 섞어 쓰게 됨 / 무엇부터 구현할지 우선순위 충돌이 생김 |
| 12개 세트 | BPMN / DMN / 권한 정책 매트릭스 / IA / ERD / RTM / DoR / DoD / 운영 정책서 | 예외와 분기 규칙이 많아짐 / 여러 역할과 상태 전이가 얽힘 / 데이터 구조와 시스템 연동을 별도 설계해야 함 / 검증과 승인 이력을 추적하지 않으면 운영 리스크가 커짐 |
| 30개 세트 | 이해관계자 맵 / 가정·제약사항 목록 / 배포 계획서 / 롤백 계획서 / 런북 | 여러 팀이 동시에 배포와 운영 전환에 관여함 / 장애나 롤백 시나리오를 사전에 문서화해야 함 / 운영 절차가 개인 경험에 의존하기 시작함 |
| 35개 세트 | 리스크 레지스터 / 변경 요청서(CR) / 테스트 결과 보고서(TSR) / 모니터링 계획서 / 우선순위 매트릭스 보강본 | 운영 규모가 커져 위험·변경·관측을 별도 통제해야 함 / 릴리스 승인에 테스트 결과와 모니터링 계획이 필수로 요구됨 / 변경 요청과 우선순위 조정이 상시 업무가 됨 |
5. 세트 선택 실무 원칙
5-1. 모든 기능에 모든 문서가 필요한 것은 아니다
단순한 기능 하나에 BPMN, DMN, 상세 사양, RTM까지 모두 요구하면 문서 체계가 부담이 된다.
5-2. 하지만 복잡한 기능에 최소 세트만 두면 더 큰 비용을 낸다
예외와 분기, 상태 전이, 운영 영향이 많은 기능은 문서를 생략할수록 나중에 해석 비용이 커진다.
5-3. 언제 산출물을 추가하고 언제 멈출 것인가
다음 중 하나라도 발생하면 세트를 확장해야 한다.
- 정책과 예외가 문장 안에서 반복 충돌한다
- 흐름과 판단을 분리하지 않으면 설명이 길어진다
- 구현 기준을 개발자가 암묵적으로 보완한다
- 테스트케이스가 뒤늦게야 작성된다
반대로 이 문제가 아직 없고 협업 범위도 작다면 최소 세트에서 멈춰도 된다.
6. 세트와 레이어의 관계
세트는 문서 수의 문제가 아니라 레이어 적용 깊이의 문제다.
- 3개 세트는 일부 레이어만 최소한으로 사용한다.
- 10개 세트는 방향, 구현, 검증 레이어를 기본 분리한다. 정책서(규칙 레이어)는 포함되지 않는다.
- 12개 세트는 10개 세트에 규칙(정책서) 레이어와 경험(프로토타입·API 명세) 레이어를 추가한다.
- 30개, 35개 세트는 정책, 흐름, 판단, 운영 연결까지 세분화한다.
즉, 세트가 커질수록 문서가 늘어나는 것이 아니라 레이어 분리가 더 엄격해진다.
7. 가상 적용 예시 2. 주문 기능 하나를 어떤 문서 패키지로 나눌 것인가
주문 기능 하나를 추가한다고 가정하자. 겉보기에는 단일 기능처럼 보이지만, 실제로는 결제 전후 상태, 재고 차감, 취소 가능 조건, 운영 예외, 고객 공지까지 연결될 수 있다.
이 기능이 단순한 내부 테스트 수준이라면 3개 또는 10개 세트로도 출발할 수 있다. 하지만 결제 상태, 주문 취소, 환불, 운영 알림, 재고 정책이 함께 얽히기 시작하면 정책서, BPMN, DMN, 사양서, 테스트케이스가 분리돼야 한다.
핵심은 기능 이름이 아니라 그 기능이 끌고 오는 규칙과 협업 복잡도다. 주문 기능 하나도 단순 과제일 수 있고, 고복잡도 과제일 수도 있다.
8. 이 장의 핵심 메시지
모든 프로젝트가 같은 문서 세트를 필요로 하지는 않지만, 복잡도에 맞는 최소 세트는 반드시 필요하다.
세트는 문서를 많이 만들자는 제안이 아니다. 프로젝트의 복잡도와 협업 비용에 맞춰, 어떤 레이어까지 분리해야 안전한지를 결정하는 기준이다.
9. 다음 장으로의 연결
이 장에서는 프로젝트 규모와 복잡도에 따라 어떤 문서 세트를 선택해야 하는지 봤다.
이제 마지막으로 남는 질문은 이것이다.
이 문서들 중 어떤 문서가 최종 기준이며, 변경은 어떻게 통제해야 하는가?
다음 장에서는 Source of Truth와 버전관리 원칙을 다룬다. 문서 세트를 정했다면, 그다음에는 어떤 문서를 최종 기준으로 보고 변경과 승인을 어떻게 통제할지 정해야 한다.