---
type: knowledge
domain: product
status: active
last-reviewed: 2026-07-27
---

# 역할별 기획 운영 가이드

> 한 줄 정의
> 역할별 템플릿을 실제 외주 프로젝트 기록으로 바꾸고, 중복 없이 검토·검수·인계하는 공통 운영 규칙. 모든 기록의 최종 용도는 **검수 근거·인수인계·책임 경계 증빙**이다.

## 지식 원본과 프로젝트 기록을 분리한다

- 이 폴더의 문서는 **원본 가이드·빈 템플릿**이다. 프로젝트 사실을 직접 채워 넣지 않는다.
- 실제 기록은 `40_프로젝트/{프로젝트}/기획/` 아래에 복사한다.
- 원본 템플릿을 개선할 때는 특정 발주사·계약의 이름·사람·금액·일정·비밀값을 제거해 일반화한다.

권장 프로젝트 구조:

```text
40_프로젝트/{프로젝트}/기획/
├── 00_프로젝트 브리프.md
├── 10_역할별/
│   ├── {역할}/
│   │   ├── 00_역할 계획.md
│   │   ├── 10_결정 기록.md
│   │   ├── 20_산출물.md
│   │   └── 90_완료 증거.md
├── 80_RACI.md
└── 90_승인·인계/
    └── {YYYY-MM-DD} {보내는 역할}→{받는 역할}.md
```

## 역할을 활성화하는 기준

1. 이 역할이 없으면 놓칠 **독립적인 결정 또는 위험**이 있는가?
2. 그 결정의 소비자(다음 역할 또는 발주사)가 누구인지 분명한가?
3. 이 역할이 책임지는 **납품 산출물 또는 검수 근거**가 계약 산출물 목록에 있는가?

세 질문 중 둘 이상이 아니면 별도 역할을 만들지 않는다. [[50_역할 활성화 체크리스트]]에서 최소 구성을 고르고, 발주사 측 카운터파트(발주 담당·현업 검수자·최종 승인자)를 함께 확인한다.

## 작성 순서

1. **입력 고정** — 계약 범위(포함·제외), 요구사항 ID, 참조 문서, 현재 사실, 제약을 적는다.
2. **질문과 가정 분리** — 발주사에 확인한 사실과 아직 검증하지 않은 가정을 섞지 않는다. 가정은 확인 기한과 함께 남긴다.
3. **결정 기록** — 선택, 대안, 근거, 영향, 되돌림 비용을 남긴다. 발주사 합의가 필요한 결정은 합의 근거(회의록·메일)를 링크한다.
4. **산출물 작성** — 다음 역할이 사용할 계약과 파일을 만들고, [[외주 개발 산출물]]의 납품 목록 중 어느 항목에 해당하는지 연결한다.
5. **자체 체크** — 역할별 `90_... 완료 체크리스트`를 실행한다.
6. **독립 검토·승인** — 위험에 맞는 Reviewer·Approver가 실제 파일을 본다. 발주사 검수 대상이면 검수자는 수행사 작성자와 분리한다.
7. **인계** — [[30_핸드오프 템플릿]]으로 다음 행동과 미결을 명시한다.

## 범위 밖 요청과 발주사 지연의 처리

- **범위 밖 요청은 거절이 아니라 CR로 회부한다.** 어느 역할이 받았든 즉시 수락하지 말고 "됩니다, 일정·비용 영향은 산정 후 회신"으로 응답하고 CR 문서를 남긴다. 무료로 해준 10개의 "사소한 것"이 일정 붕괴의 실체다 ([[SI 수주와 범위 관리]]).
- **발주사 지연도 기록한다.** 자료 미제공·결정 지연·검수 지연은 발생 즉시 날짜와 일정 영향을 기록하고 공지한다 — 종료 시점 책임 공방의 방어 자료다.
- **나쁜 소식일수록 빨리.** 지연을 검수일에 알리는 것이 신뢰를 죽인다. 서프라이즈 제로가 원칙.

## 기존 실행 정본을 재사용한다

역할 폴더는 "누가 무엇을 결정하고 넘기는가"를 다룬다. 아래 실행 템플릿·체크리스트가 이미 있으면 새 양식을 만들지 않고 연결한다. 외주에서는 각 정본이 대응하는 납품 산출물의 초안 뼈대가 된다.

| 역할·주제 | 기존 정본 | 대응 납품 산출물 |
|-----------|-----------|-------------------|
| PM·요구 명세 | [[PRD-템플릿]], [[PROJECT-SPEC-TEMPLATE]] | 요구사항정의서(SRS)·RTM |
| Tech Lead·기술 결정 | [[ADR-TEMPLATE]], [[API-명세-템플릿]], [[데이터-모델-템플릿]] | 시스템구성도·API 정의서·ERD |
| Data·ML 평가 | [[평가-계획-템플릿]] | 테스트계획서(평가 파트) |
| Frontend | [[프론트엔드-체크리스트]] | 화면 구현 검증 근거 |
| Backend | [[백엔드-체크리스트]] | API 구현 검증 근거 |
| UX·UI | [[디자인-체크리스트]] | 화면정의서(스토리보드) |
| Security·Privacy | [[보안-체크리스트]] | 보안 점검 결과 |
| 설계 리뷰 | [[설계-리뷰-체크리스트]] | 설계 검토 기록 |
| Release·운영 | [[배포-운영-체크리스트]] | 이관 절차·운영 매뉴얼 입력 |

## 상태와 변경 규칙

| 상태 | 의미 | 다음 행동 |
|------|------|-----------|
| Draft | 가정·미결이 남은 초안 | 작성자가 보강 |
| Review | 입력·결정·산출물이 채워짐 | Reviewer 검토 |
| Approved | 승인자가 대상 버전을 확인 | 다음 역할 착수 또는 발주사 전달 |
| Deprecated | 더 최신 결정이 대체 | 대체 문서 링크 |

- 파일명에 `최종`, `진짜최종`을 붙이지 않는다. 버전·상태·날짜를 메타데이터로 관리한다 — 어느 버전이 검수본인지 불명하면 분쟁의 씨앗이다.
- 중요한 변경은 기존 문장을 조용히 바꾸지 말고 변경 이유와 영향을 남긴다. 발주사와 합의한 문서(검수 기준·범위)의 변경은 CR 절차를 거친다.
- 산출물별 Accountable Owner는 한 명, Reviewer·Approver는 필요에 따라 둔다.

## 완료 판정

> [!WARNING] 완료 주장은 검수 근거가 아니다
> 체크박스를 채웠다는 사실보다 연결된 테스트결과·지표·스크린샷·결정·서명이 중요하다. 실행하지 못한 검사는 `미수행: {이유}`로 남긴다. 검수 기준·기대값은 **착수 전 발주사와 합의된 것만 유효**하다 — 사후 합의는 분쟁 원인이다.

- 요구사항과 산출물이 ID로 연결된다 (RTM에 반영).
- 범위 밖(Out of Scope)과 알려진 제약이 드러난다.
- 다음 소비자가 해야 할 행동이 한 문장으로 명확하다.
- 되돌리기 비싼 결정에는 승인과 롤백·재검토 조건이 있다.
- QA·검수자는 작성자의 요약만 믿지 않고 요구사항 원본과 실제 산출물을 확인한다.
- 산출물이 검수·계약 근거로 쓸 수 있는 상태인가 — 판정 기준은 [[요구사항과 완료 조건]]의 PASS/FAIL 기계 검증 형식.

## 관련 문서

- [[00_역할별 기획 허브]]
- [[10_산출물 메타데이터 템플릿]]
- [[20_RACI 템플릿]]
- [[30_핸드오프 템플릿]]
- [[역할별 개발 산출물]]
- [[요구사항과 완료 조건]]
- [[외주 개발 산출물]]
- [[SI 수주와 범위 관리]]