외주 개발 산출물 문서 총정리 2026 — 제안요청서·요구사항 정의서·화면 정의서·WBS

# 외주 개발 산출물 문서 총정리 2026 — 제안요청서·요구사항 정의서·화면 정의서 양식과 WBS

문서가 부실하면 견적이 두 배로 벌어진다

소프트웨어 외주에서 같은 프로젝트에 견적이 1,200만 원과 2,800만 원으로 나오는 일이 흔하다. 업체의 단가 차이가 아니라 대부분 요구사항이 비어 있어서 생긴다.

요구사항이 불명확하면 개발사는 두 가지 중 하나를 한다.

• 최악을 가정하고 리스크를 견적에 얹는다 → 비싸진다
• 최선을 가정하고 싸게 부른다 → 나중에 추가 비용으로 돌아온다

어느 쪽도 발주처에 좋지 않다. 문서를 갖추는 것은 형식이 아니라 견적을 비교 가능하게 만드는 작업이다.

문서 지도 — 누가 언제 쓰는가

발주처가 직접 써야 하는 것은 사실상 두 개다 — 제안요청서와 요구사항 정의서. 나머지는 개발사가 만들고 발주처가 검토·승인한다.

⚠️ 이 구분을 모르면 "요구사항 명세서를 주세요"라는 요청에 당황하게 된다. 명세서는 원래 개발사가 정의서를 받아 구체화하는 문서다.

제안요청서(RFP) — 업체를 부르기 전에 쓴다

제안요청서는 여러 업체에게 같은 조건으로 제안을 받기 위한 문서다. 이게 없으면 업체마다 다른 전제로 견적을 내서 비교 자체가 불가능해진다.

최소 항목은 다음과 같다.

• 발주 배경과 목적 (왜 만드는가)
• 과업 범위 — 무엇을 만들고 무엇은 제외인가
• 주요 기능 목록 (개략 수준으로 충분)
• 기존 시스템·데이터 현황
• 희망 일정과 예산 범위
• 제안서 제출 형식과 마감
• 평가 기준과 배점
• 문의 창구

예산 범위를 밝히는 것을 꺼리는 경우가 많은데, 밝히는 편이 대체로 낫다. 범위를 모르면 업체는 과잉 제안을 하거나 아예 참여를 포기한다. "5,000만 원 내외" 정도만 적어도 제안의 질이 달라진다.

요구사항 정의서 — 가장 중요한 한 장

외주 성패의 대부분이 이 문서에서 갈린다. 그런데 실무에서 가장 자주 생략된다.

거창하게 쓸 필요는 없다. 핵심은 화면 목록과 규칙이다.

화면 목록만 정확해도 견적 편차가 크게 줄어든다. 견적을 가르는 실제 변수가 기능 개수가 아니라 화면 개수이기 때문이다.

요구사항 정의서와 명세서(SRS)는 다르다

혼동이 잦아 정리해 둔다.

정의서는 업무 언어로, 명세서는 기술 언어로 쓰인다. 발주처가 명세서까지 쓸 필요는 없다.

기능 정의서·화면 정의서 — 착수 후 첫 산출물

계약 후 개발사가 가장 먼저 내놓아야 할 문서다. 이걸 안 주고 바로 개발에 들어가는 업체는 경계하는 게 맞다.

기능 정의서는 기능을 목록으로 세우고 각각의 입력·처리·출력을 정의한다. 기능 ID를 붙여 두면 나중에 검수와 변경 관리가 쉬워진다.

화면 정의서(화면설계서)는 화면 단위로 다음을 담는다.

• 화면 레이아웃 (와이어프레임)
• 각 항목의 입력 규칙 (필수 여부, 형식, 길이)
• 버튼별 동작과 이동 화면
• 권한별로 보이는 것과 안 보이는 것
• 오류 메시지

⚠️ 화면 정의서 검토를 대충 넘기면 나중에 되돌리기 어렵다. 이 시점의 수정은 문서만 고치면 되지만, 개발이 끝난 뒤의 수정은 비용이 몇 배다. 실제로 쓸 사람이 이 문서를 봐야 한다.

WBS와 일정표 — 진척을 볼 수 있게 만든다

WBS(Work Breakdown Structure)는 할 일을 쪼개 나열한 표다. 거창한 도구가 필요 없고 스프레드시트로 충분하다.

WBS의 진짜 용도는 일정 관리가 아니라 "지금 어디까지 왔는지 합의"다. 이게 없으면 납기 직전에야 지연을 알게 된다.

주 1회 갱신을 계약서에 넣어 두는 것을 권한다.

과업지시서 — 관공서·공공기관이라면 필수

민간 발주에서는 제안요청서로 갈음하는 경우가 많지만, 공공 발주에서는 과업지시서가 계약 문서의 일부가 된다.

민간이라도 다음 경우에는 준비하는 편이 안전하다.

• 과업 범위 다툼이 예상될 때
• 여러 업체가 나눠 참여할 때
• 발주 담당자가 바뀔 가능성이 있을 때

과업지시서에 없는 일은 추가 과업이다. 이 원칙 때문에 범위 다툼이 줄어든다.

계약서에서 빠뜨리면 안 되는 4가지

용역 계약서 양식은 어디서 구해도 비슷하지만, 아래 네 가지는 표준 양식에 없거나 흐릿하게 적혀 있다.

1. 소스 코드 인도와 저작권 귀속 — 인도 시점과 형태(저장소 이관 여부)까지 명시한다
2. 하자보수 범위와 기간 — 무엇이 하자이고 무엇이 추가 개발인지 경계를 적는다
3. 검수 절차와 기준 — 며칠 안에 검수하고, 이의가 없으면 어떻게 되는지
4. 변경 관리 절차 — 요구사항이 바뀔 때 비용·일정을 어떻게 조정하는지

⚠️ 1번이 가장 자주 문제가 된다. 2~3년 뒤 기능을 추가하려는데 소스가 없으면 처음부터 다시 만들어야 한다. 개발비의 몇 배가 나중에 드는 항목이다.

발주 전 비용 산정 기준은 AI 개발 외주 비용·요구사항 정의 가이드에, 업체 검증 방법은 포트폴리오 실작동 확인법에 따로 정리했다.

검수 단계 문서 — 테스트 시나리오와 확인서

납품 직전에 필요한 문서 둘이다.

테스트 시나리오는 "이 조건에서 이렇게 하면 이런 결과가 나와야 한다"를 목록으로 만든 것이다. 개발사가 작성하되 발주처가 실제 업무 상황을 추가해야 쓸모가 있다.

검수 확인서는 검수 완료를 기록하는 문서다. 여기서 두 가지를 반드시 남긴다.

• 검수 시점에 미완료로 남은 항목과 처리 일정
• 검수 이후 발견된 하자를 어떻게 처리하는지

"일단 검수해 주시고 나머지는 나중에"에 서명하면 그 나머지는 대체로 오지 않는다. 미완료 항목을 문서에 남기는 것이 유일한 안전장치다.

문서 준비 순서 7단계

1. 제안요청서 초안 — 목적·범위·예산 범위
2. 요구사항 정의서 — 화면 목록과 업무 규칙 (가장 중요)
3. 업체 3곳 이상에 같은 문서로 견적 요청
4. 계약 — 소스 인도·하자보수·검수·변경 관리 4개 조항 확인
5. 착수 후 기능 정의서·화면 정의서 수령 및 검토 (실사용자 참여)
6. WBS 주 1회 갱신으로 진척 확인
7. 테스트 시나리오·검수 확인서 — 미완료 항목 명시

AI-Native 팀이 문서를 다루는 방식

나무숲은 AI-Native Team으로, 팀원 전원이 Claude Code Max 플랜을 기본 개발 환경으로 사용합니다. 산출물 문서는 만드는 것보다 코드와 어긋나지 않게 유지하는 것이 어렵다.

• 문서와 구현의 동기화 — 화면 정의서의 입력 규칙과 실제 코드의 검증 로직이 일치하는지 대조해, 문서만 남고 구현이 다른 상태를 막는다
• 기존 문서 구조화 — 발주처가 가진 HWP·엑셀 자료에서 요구사항을 추출해 정의서 초안으로 만든다
• 테스트 시나리오 생성 — 화면 정의서의 규칙에서 정상·예외 케이스를 뽑아 검증 목록을 자동으로 만든다

문서는 형식이 아니라 합의의 기록이다. 유지 비용을 낮춰야 실제로 갱신되고, 갱신돼야 쓸모가 있다. 이것이 AI-Native 개발 방식에서 문서를 다루는 관점이다.

AI 기능 없이 순수 웹·앱 개발이 필요하다면 포텐랩(Potenlab)도 좋은 선택이다. MVP부터 플랫폼 개발까지 전문으로 한다.

자주 묻는 질문

요구사항 정의서를 꼭 발주처가 써야 하나요?

개발사가 대신 써 주기도 하지만, 그 경우 "우리가 이해한 대로" 쓰이므로 반드시 검토해야 한다. 화면 목록만이라도 직접 적어 두면 그 뒤 논의가 훨씬 빨라진다.

양식을 어디서 구하나요?

공공기관 공고에 첨부된 과업지시서·제안요청서가 실무 기준으로 참고하기 좋다. 다만 그대로 쓰면 민간 프로젝트에는 과한 경우가 많으니 필요한 항목만 추린다.

문서를 다 갖추면 기간이 늘어나지 않나요?

초반 1~2주가 더 들지만, 재작업으로 잃는 시간이 그보다 크다. 특히 화면 정의서 검토를 건너뛰면 개발 후반에 몇 주가 날아간다.

제안요청서에 예산을 밝혀야 하나요?

범위 형태로 밝히는 편이 낫다. 예산을 모르면 업체는 과잉 제안을 하거나 참여를 포기한다.

기능 정의서와 화면 정의서 중 하나만 받아도 되나요?

화면 정의서가 더 중요하다. 실제로 쓸 사람이 이해할 수 있는 문서이고, 검수 기준이 되기 때문이다.

정리

외주 개발 문서는 많아 보이지만 발주처가 직접 쓰는 것은 제안요청서와 요구사항 정의서 둘뿐이다. 나머지는 개발사가 만들고 발주처가 검토한다.

그리고 실무에서 결과를 가르는 지점은 세 곳이다.

1. 요구사항 정의서의 화면 목록 — 견적 편차의 대부분이 여기서 생긴다
2. 화면 정의서 검토에 실사용자 참여 — 이 시점을 놓치면 되돌리는 비용이 몇 배다
3. 계약서의 소스 코드 인도 조항 — 몇 년 뒤 가장 비싸게 청구되는 누락이다

문서를 완벽하게 갖추라는 뜻이 아니다. 이 세 가지만 챙겨도 대부분의 사고가 예방된다.