---
type: knowledge
domain: product
status: active
last-reviewed: 2026-07-26
aliases:
  - 역할별 산출물
  - 개발 역할별 산출물
---

# 역할별 개발 산출물

> 한 줄 정의
> 제품·소프트웨어·SI 프로젝트에서 각 역할이 다음 역할에 넘겨야 할 최소 결과물과 완료 증거. 역할은 직급이 아니라 **결과에 대한 책임 단위**이고, 산출물은 문서뿐 아니라 코드·설정·테스트·결정·승인 기록까지 포함한다.

> [!IMPORTANT] 산출물의 기준은 “작성했는가”가 아니다
> 다음 역할이 이전 대화를 재구성하지 않고 **착수·검증·승인**할 수 있어야 산출물이다. 한 사람이 여러 역할을 맡아도 역할별 계약은 분리하고, 구현자와 최종 판정자는 가능하면 나눈다.

> [!TIP] 역할별 실행 가이드
> 실제 기획 순서·복사용 파일·완료 체크리스트는 [[00_역할별 기획 허브]]에서 역할을 선택한다.

## 모든 산출물의 공통 완료 계약

| 필수 정보 | 확인 질문 |
|-----------|-----------|
| 목적·요구사항 연결 | 어떤 문제·요구사항을 해결하는가? |
| 책임 | 최종 Owner, Reviewer, Approver가 누구인가? |
| 상태·버전 | Draft / Review / Approved / Deprecated 중 무엇이며 최신본인가? |
| 완료 증거 | 테스트 결과·지표·스크린샷·서명처럼 제3자가 확인할 근거가 있는가? |
| 미결·범위 밖 | 확인 필요, 알려진 제약, 후속 작업, 하지 않은 검사가 드러나는가? |
| 다음 소비자 | 누가 이 결과를 받아 어떤 결정을 하거나 작업을 시작하는가? |

산출물별 최종 Owner는 한 명으로 둔다. 공동 작업자는 여러 명이어도 “누가 끝을 책임지는가”가 둘이면 실제로는 아무도 책임지지 않는다.

## 기획·설계 역할

| 역할 | 필수 산출물 | 완료 증거 | 다음 소비자 |
|------|-------------|-----------|-------------|
| 사업·제품 책임자 | 문제 정의, 대상 사용자, 기대 성과·KPI, 예산·기한 제약, 우선순위와 최종 승인 | 목표 수치·의사결정권자·중단 조건이 명시됨 | PM, 프로젝트 책임자 |
| PM·PO·BA | PRD 또는 요구 브리핑, 범위/범위 밖, 우선순위 백로그, 리스크·의존성, 요구사항 추적표(RTM), 수용·완료 조건 | 요구마다 ID·Owner·검증 방법이 있고 조건 실행 시 PASS/FAIL이 남 | 디자인, Tech Lead, QA |
| UX 리서처·UI/UX 디자이너 | 조사 근거, 사용자 여정·흐름, 정보 구조, 와이어프레임·목업, 상태 명세, 디자인 토큰·구현 핸드오프 | 기본·빈·로딩·오류·권한 상태와 반응형·접근성 기준이 모두 확인됨 | Frontend, 디자인 리뷰어 |
| Tech Lead·아키텍트 | 시스템 경계·구성도, API·데이터 계약, 비기능 요구, ADR, 작업 분해·파일 소유권, 통합·리뷰 계획, 배포·롤백 전략 | 대안·결정 이유·영향·의존성이 기록되고 각 작업의 입력/출력/담당이 겹치지 않음 | 전문 구현자, 리뷰어 |

PM은 **무엇과 완료 기준**을 책임지고, Tech Lead는 **어떻게와 작업 경계**를 책임진다. 요구사항 문서가 특정 라이브러리·구현법을 몰래 확정하거나, 기술 설계가 제품 우선순위를 바꾸면 역할 경계가 무너진다.

## 구현 역할

| 역할 | 필수 산출물 | 완료 증거 | 다음 소비자 |
|------|-------------|-----------|-------------|
| Frontend | 화면·컴포넌트·상태 구현, 단위/통합 테스트, Backend 계약 의존성, 시각 검증 결과 | 수용 조건, 상태 명세, 320~1440px 반응형, 키보드·WCAG 접근성, 콘솔 오류 여부 확인 | Tech Lead, QA |
| Backend | API 계약, 도메인·비즈니스 로직, 입력 검증·오류 정책, 단위/통합 테스트, 로그·메트릭 | 요청/응답/상태코드가 명시되고 권한·실패·타임아웃 경로까지 재현됨 | Frontend, Database, QA |
| Database | 스키마·ERD, 마이그레이션·인덱스, 데이터 영향, 운영 적용·롤백 절차 | 무결성·호환성·잠금 위험을 검토하고 적용/롤백을 재현함 | Backend, DevOps, 운영 |
| Data·ML | 데이터셋·라벨 기준, 데이터 가정·품질 규칙, 베이스라인과 평가 리포트, 추론 입출력 계약, 모델 버전·롤백 | 고정 평가셋의 목표 지표와 재현 절차가 있고 데이터 누수·편향·실패 조건을 기록함 | Backend, QA, 운영 |
| DevOps·SRE | CI/CD, IaC·환경 변수 명세, 배포·롤백 절차, 헬스체크·모니터링·알림, 런북 | 새 환경에서 빌드·배포·복구가 반복 가능하고 비밀값 노출 검사가 통과함 | Release, 운영 |
| Security·Privacy | 위협 모델, 인증·인가·암호화 구현, 데이터 분류·보존 기준, 보안 테스트·취약점 조치표 | 위험별 심각도·근거·Owner·기한이 있고 출시 차단 이슈가 해소되거나 명시적으로 승인됨 | Tech Lead, QA, 승인자 |

구현자의 공통 산출물은 **실제 변경물 + Result Card**다. Result Card에는 최소한 변경 파일, 구현·계약 요약, 실행한 검증, 알려진 제약·후속 작업, 미수행 검사를 적는다. 자기 보고는 통합을 돕는 전달물이지 최종 품질 판정이 아니다.

## 검증·출시·인계 역할

| 역할 | 필수 산출물 | 완료 증거 | 다음 소비자 |
|------|-------------|-----------|-------------|
| 코드·디자인·문서 리뷰어 | 판정, 심각도별 발견, 파일·섹션·재현 절차, 수정 방향, 미검토 영역 | Critical/High는 실제 결함과 근거가 있고 취향은 Low/Nit로 보정됨 | 구현자, Tech Lead |
| QA·독립 Judge | 요구사항↔테스트 매핑, 테스트 케이스·실행 결과, 회귀 결과, 결함·재현 절차, PASS/FAIL/CONDITIONAL 판정 | 원본 요구와 실제 변경물을 독립 대조하고 미수행 항목을 통과로 세지 않음 | 제품 책임자, Release |
| Release·운영 | 출시 체크리스트, 버전·변경 내역, 배포·롤백 계획, 운영 런북, 모니터링 기준, 릴리즈 보고 | 자동 테스트·커버리지·보안 게이트를 통과하고 사람 승인과 복구 경로가 확인됨 | 운영자, 사용자 |
| SI·문서화·인수인계 | 작업 개요, 제안서, 요구사항, WBS, 데모, 결과보고서, SLA, 견적서, 주간 보고서, 도메인 맵과 운영·사용자 매뉴얼 — **계약 납품물 목록의 정본은 [[외주 개발 산출물]] 체크리스트**이고 이 세트는 그 문서 작성용 템플릿 매핑이다 | 확인 못 한 수치는 표시되고 RTM으로 요구↔설계↔구현↔테스트↔검수가 추적됨 | 발주사, 운영·유지보수 |
| 고객·업무 책임자 | 사용자 검수 결과, 예외 승인, 산출물 인수 확인, 미해결 사항과 하자보수 합의 | 승인자·날짜·대상 버전·조건부 승인 항목이 기록됨 | 프로젝트 종료·정산 |

> [!WARNING] QA 독립성
> QA는 구현자의 요약을 합격 근거로 삼지 않는다. **원본 요구사항 + 실제 변경물 + 직접 실행한 결과**로 판정한다. 구현자와 QA가 같은 사람이라면 최소한 컨텍스트와 체크리스트를 분리해 자기 확증을 줄인다.

## S-skills 파일 계약에 대응시키기

| 단계·역할 | 체크포인트 파일 | 핵심 내용 |
|-----------|-----------------|-----------|
| PM | `.state/pm-brief.md` | 요구 분석, 범위, 태스크, 리스크, 기계 검증 가능한 완료 조건 |
| Design | `.state/design-handoff.md` | 승인 목업, 정확한 CSS 변수·레이아웃·상태 계약 |
| 전문 구현자 | `.state/dev/{role}.md` | 변경 파일, 역할별 계약, 검증, 제약·후속 작업 |
| 리뷰어 | `.state/dev/_review-*.md` 또는 `.state/review-*.md` | 독립 렌즈별 판정과 근거 |
| Tech Lead | `.state/dev-summary.md` | 참여 역할, 실제 변경, 통합·리뷰 결과, 잔여 리스크 |
| QA | `.state/qa-verdict.md` | 완료 조건 1:1 대조, 실행 증거, 최종 판정 |
| Release·감사·회고 | `40_프로젝트/{프로젝트}/보고서/` | 사람이 다시 읽을 수 있는 영속 정리본 |

`pm-brief → design-handoff(필요 시) → Result Card·실제 변경물 → 독립 리뷰 → qa-verdict → release`가 최소 추적선이다. RUN_ID나 요구사항 ID 하나로 이 선을 관통시키면 중단 후 재개와 책임 추적이 쉬워진다.

## 프로젝트 규모에 맞춰 줄이기

- **작은 내부 변경**: 요구 브리핑 + 실제 변경물·테스트 + 독립 판정이면 충분하다.
- **UI 변경**: 디자인 상태 명세·핸드오프와 시각·접근성 검증을 추가한다.
- **데이터·보안·운영 위험 변경**: ADR·위협 모델·마이그레이션·롤백·런북을 추가한다.
- **외주·SI**: [[외주 개발 산출물]]의 계약·검수·인수인계 문서와 RTM을 추가한다.
- **규제·금전·개인정보 영향**: 독립 승인자와 승인 기록을 반드시 둔다.

모든 역할을 항상 세우거나 모든 문서를 항상 만들 필요는 없다. **활성화한 역할에는 소비 가능한 산출물을 요구하고, 필요가 없는 역할은 파이프라인에서 빼는 것**이 원칙이다.

## 안티패턴

- **회의·채팅이 산출물** — 결정과 완료 조건이 버전된 결과물로 남지 않아 다음 사람이 다시 해석한다.
- **역할명만 있고 산출물 계약이 없음** — “백엔드 담당”이 무엇을 넘겨야 끝나는지 알 수 없다.
- **검수 직전 문서 몰아쓰기** — 실제 구현과 어긋난 사후 픽션이 된다.
- **구현자 자기 QA** — 만든 사람이 자기 설명을 근거로 합격시킨다.
- **미수행을 빈칸으로 숨김** — 확인하지 않은 것이 통과한 것으로 읽힌다.
- **Owner가 둘 이상** — 공동 책임이라는 이름으로 최종 결정과 후속 조치가 떠다닌다.

## 관련 문서

- [[00_역할별 기획 허브]] — 15개 역할별 기획 폴더와 복사용 템플릿
- [[개발 파이프라인 분업]] — AI 역할 분리와 Judge 독립성
- [[요구사항과 완료 조건]] — PASS/FAIL 가능한 완료 기준
- [[외주 개발 산출물]] — 단계·계약·검수 관점의 납품물 (계약 납품물 목록의 정본)
- [[시나리오·예외사항 문서 작성법]] — QA·검수 시나리오 문서의 작성 규칙
- [[SI 수주와 범위 관리]] — 산출물 범위와 대금·책임 경계
- [[설계 결정과 리뷰]] — 기술 설계와 ADR의 판단 기준
- [[S-skills-하네스-패턴]] — 파일 계약의 검증된 구현 사례