---
type: knowledge
domain: business
status: active
last-reviewed: 2026-07-27
---
# 외주 개발 산출물

> 한 줄 정의
> 외주·SI 프로젝트에서 단계별로 만들어야 하는 문서 산출물의 지도. 목록 자체보다 **"이 산출물이 없으면 뭐가 터지는가"**가 핵심 — 계약·검수·인수인계의 근거가 되는 것만 진짜 산출물이고, 나머지는 검수 통과용 종이다.

## 산출물은 단계의 부산물이 아니라 계약의 연결점

발주사가 산출물을 요구하는 진짜 이유는 세 가지뿐이다: **(1) 검수 근거** — "됐다"를 판정할 기준, **(2) 인수인계** — 개발사가 떠난 뒤 운영·유지보수의 자립, **(3) 책임 경계** — 분쟁 시 "합의했다"의 증거. 이 셋 중 어디에도 안 걸리는 문서는 만들 필요를 의심하라. 반대로 이 셋에 걸리는데 계약에 없으면 무상 노동으로 새어나간다.

> [!WARNING] 산출물 목록은 착수 전 계약에 못 박는다
> "당연히 주는 줄 알았다"는 [[SI 수주와 범위 관리]]의 분쟁 1순위. 어떤 문서를, 어느 수준으로, 어느 마일스톤에 전달하는지를 제안·계약 단계에서 산출물 목록(deliverable list)으로 확정한다. 운영매뉴얼 하나가 잔금 지급을 몇 주 미룬다.

## 고객사 제출 산출물 목록 (계약 첨부용 체크리스트)

> [!TIP] 이 목록을 그대로 계약서의 "납품 산출물 목록"으로 쓴다
> 핵심은 항목 나열이 아니라 **각 항목에 전달 마일스톤을 붙이는 것** — 마일스톤이 없으면 "종료 시 일괄 제출"로 밀려 잔금 지급이 지연된다.

**1. 착수·기획** — 마일스톤: 착수
- [ ] 착수보고서
- [ ] 요구사항정의서 (SRS)
- [ ] WBS·일정계획서
- [ ] 요구사항 추적표 (RTM) *— 이후 단계마다 갱신*

**2. 설계** — 마일스톤: 설계 완료
- [ ] 시스템구성도 (아키텍처)
- [ ] 메뉴구조도 / 프로그램 목록
- [ ] 화면정의서 (스토리보드)
- [ ] 기능사양서 (기능정의서)
- [ ] ERD · 테이블정의서
- [ ] API 정의서 (인터페이스 정의서)
- [ ] 코드정의서 (공통코드)

**3. 개발** — 마일스톤: 개발 완료
- [ ] 소스코드 일체 (저장소 이관)
- [ ] 단위테스트 코드·결과
- [ ] 형상관리·버전 이력
- [ ] 빌드·배포 스크립트

**4. 테스트·검수** — 마일스톤: 검수
- [ ] 테스트계획서
- [ ] 테스트케이스 (시나리오)
- [ ] 테스트결과서 (결함·조치 이력 포함)
- [ ] 검수확인서

**5. 이관·운영** — 마일스톤: 이관
- [ ] 시스템(설치·구축) 매뉴얼
- [ ] 운영(관리자) 매뉴얼
- [ ] 사용자 매뉴얼
- [ ] 인수인계서 (계정·라이선스·기술스택·주의사항)
- [ ] 교육 자료 (사용자/운영자 교육 시)

**6. 종료** — 마일스톤: 종료·잔금
- [ ] 완료보고서 (최종 결과보고서)
- [ ] 산출물 목록 (납품 확인용)
- [ ] 하자보수 계획서 / 유지보수 이관 계획

## 단계별 산출물 지도

> [!NOTE] 정본은 위의 계약 첨부용 체크리스트다
> 아래 지도는 같은 항목을 **"없으면 터지는 것"** 관점으로 부연한 것이다. 항목의 추가·삭제·이름 변경은 체크리스트에서 먼저 하고 지도를 따라 맞춘다.

### 1. 기획·분석 (What)

| 산출물 | 정의 | 없으면 터지는 것 |
|--------|------|-----------------|
| 요구사항정의서(RFP 대응·SRS) | 기능/비기능 요구를 관찰 가능한 문장으로 | 검수 기준의 원본이 없음 → "다 됐나요" 무한 반복 |
| WBS·일정계획 | 작업 분해 + 마일스톤 + 지불 조건 | 지연 책임 공방의 근거 소실 |
| 요구사항 추적표(RTM) | 요구 ↔ 설계 ↔ 구현 ↔ 테스트 매핑 | **결과보고서의 본체가 비어버림** (아래 참조) |

### 2. 설계 (How)

| 산출물 | 정의 | 없으면 터지는 것 |
|--------|------|-----------------|
| 시스템구성도(아키텍처) | 서버·네트워크·외부연동·데이터흐름 | 인수 후 운영자가 시스템 전체 모양을 모름 |
| 화면정의서(스토리보드) | 화면별 레이아웃·요소·동작·전이 | 디자인/개발 재작업, "이 화면 이렇게 하기로 했나요" 분쟁 |
| 기능사양서(기능정의서) | 각 기능의 입력·처리·출력·예외·권한 | 구현자마다 해석 갈림 → 검수 시 어긋남 |
| ERD·테이블 정의서 | 데이터 모델·컬럼·제약·관계 | DB 이관·유지보수 불가 |
| API 정의서(인터페이스 정의서) | 엔드포인트·요청/응답·에러코드·인증 | 연동 개발 지연, 외부팀 협업 붕괴 |
| 코드정의서(공통코드) | 공통코드 체계·값·의미 | 데이터 해석 불일치, 이관·연동 시 코드 매핑 분쟁 |
| 프로그램 목록·메뉴 구조도 | 산출 프로그램·화면·권한의 전체 목록 | 검수 범위 산정 불가 |

### 3. 개발·구현

| 산출물 | 정의 | 없으면 터지는 것 |
|--------|------|-----------------|
| 소스코드 + 형상관리 이력 | 실제 코드 + Git 저장소·브랜치 전략 | 소유권·재현성 분쟁, 인수 후 빌드 불가 |
| 단위테스트 코드·결과 | 기능 단위 검증 | 회귀 방어 소실 |
| 형상관리·버전 이력 | 버전 규칙·릴리스 이력 | 어느 버전이 검수본인지 불명 |
| 빌드·배포 스크립트 | 재현 가능한 배포 절차(IaC 포함) | "개발사 컴퓨터에서만 됨" |

### 4. 테스트·검수

| 산출물 | 정의 | 없으면 터지는 것 |
|--------|------|-----------------|
| 테스트계획서 | 범위·시나리오·환경·기준 | 검수 = 즉흥 클릭, 통과 여부 주관적 |
| 테스트케이스·시나리오 | 케이스별 전제/입력/기대결과 | 재검증 불가, 인수인계 시 회귀 못 함 |
| 테스트결과서(결함보고 포함) | 케이스별 PASS/FAIL + 결함 조치 이력 | **검수 서명의 근거** — 이게 잔금 트리거 |
| 검수확인서 | 발주사 서명, 완료 조건 충족 확인 | 프로젝트 종료 선언 불가 |

### 5. 이관·운영

| 산출물 | 정의 | 없으면 터지는 것 |
|--------|------|-----------------|
| 시스템(설치·구축) 매뉴얼 | 설치·환경설정·재구축 절차 | 서버 교체·재해복구 시 재구축 불가 |
| 운영(관리자) 매뉴얼 | 일상 운영·관리자 기능·장애 대응 | 운영팀 자립 불가 → 무상 지원 요청 지속 |
| 사용자 매뉴얼 | 최종 사용자 사용법 | 현업 교육·CS 부담 |
| 유지보수·인수인계서 | 구조·기술스택·주의점·계정·라이선스 | 하자보수/유지보수 경계 분쟁 |
| 교육 자료 | 사용자·운영자 교육용 자료 | 교육 없이 인수 → 오사용·문의 폭증 |

### 6. 종료

| 산출물 | 정의 | 없으면 터지는 것 |
|--------|------|-----------------|
| 최종 결과보고서 | 요구사항 추적표 + 산출물 종합 | 종료 근거 없음 |
| 산출물 목록 | 납품 파일·버전의 확인 목록 | "받았다/안 받았다" 분쟁, 잔금 지연 |
| 하자보수 계획서 | 무상 기간·범위·접수 경로·응답 기한 | 하자보수 명목 무상 지원이 무한정 이어짐 |

## 무게중심 — 다 만들지 말고 이걸 만들어라

> [!NOTE] 20개를 형식적으로 채우는 것보다 아래 4개가 살아있는 게 검수를 끝낸다.

- **요구사항 추적표(RTM)** — 결과보고서의 진짜 본체. 요구 항목마다 구현 위치·검수 결과가 채워지면 "다 됐나요?"라는 질문이 소멸한다 ([[SI 수주와 범위 관리]] §결과보고서).
- **테스트결과서** — 검수 서명과 잔금의 트리거. PASS/FAIL이 기계 검증 가능한 [[요구사항과 완료 조건]] 형식일 때만 힘을 갖는다.
- **API 정의서 + ERD** — 인수 후 유지보수의 생존선. 이 둘 없이 코드만 넘기면 "블랙박스 인계"다.
- **운영매뉴얼 + 인수인계서** — 개발사가 떠난 뒤의 자립. 이게 부실하면 하자보수 명목의 무상 지원이 무한정 이어진다.

나머지(예쁜 스토리보드 PDF, 상세 화면정의서)는 재작업 리스크가 큰 초기에만 가치가 있고, 후반엔 코드가 진실이 된다. **문서를 코드와 동기화할 수 없으면 그 문서는 착수 시점 합의용으로만 쓰고, 최종본은 코드·테스트에서 역생성한다.**

## 안티패턴

- **산출물을 검수일에 몰아서 작성** — 개발과 분리된 사후 문서는 코드와 어긋난 픽션이다. 단계 종료 시점에 그 단계 산출물을 확정한다.
- **화면정의서·기능사양서에 섞인 구현 지시** — 요구는 what, 설계는 how ([[요구사항과 완료 조건]]). 사양서가 코딩 방식을 지정하면 설계 결정을 몰래 내린 것.
- **테스트결과서 = 스크린샷 첨부** — PASS/FAIL 판정 기준이 없는 캡처는 검수 근거가 아니다.
- **매뉴얼 없이 "구두 인수인계"** — 담당자 퇴사 한 번에 시스템이 미궁이 된다.
- **추적표 없는 결과보고서** — 서술만 있는 종료 보고는 "무엇이 안 됐는지"를 숨긴다.

## 에이전트 적용

- 산출물 생성 에이전트에 이 지도를 배선: 요구사항정의서 → RTM → 기능사양서 → 테스트케이스를 **한 추적 ID로 관통**시키면 문서 간 정합이 자동 유지된다.
- API 정의서·ERD·테스트결과서는 코드·스키마·CI 결과에서 **역생성**이 가장 정확한 지점 — 손으로 쓰지 말고 소스에서 뽑는다.
- 화면정의서·운영매뉴얼처럼 사람 판단이 필요한 문서는 에이전트가 초안 → 사람 검수 게이트.

## 관련 문서

- [[SI 수주와 범위 관리]] — 산출물의 계약·검수·분쟁 관리 관점
- [[요구사항과 완료 조건]] — 검수 기준·테스트결과서의 원형
- [[우선순위와 스코프]] — 1차/2차 산출물 분리
- [[기획 원리]] — 요구사항정의서의 뿌리
- [[설계 결정과 리뷰]] — 설계 산출물의 판단 기준