RFP(제안요청서)·요구사항 정의서 쓰는 법 — 홈페이지·시스템 소규모 발주용 양식
제안요청서 RFP와 요구사항 정의서 양식을 소규모 홈페이지·시스템 발주에 맞게 정리했습니다. RFP 목차 10가지, 기업 홈페이지 요구사항 정의서 예시 8줄, 제안서 비교 평가표를 담았고 빈 양식은 PDF로 받을 수 있습니다.
결론부터 적습니다. 작은 홈페이지 발주라도 RFP(제안요청서) 한 장과 요구사항 정의서 한 장이 있으면 여러 업체에서 같은 조건으로 견적을 받아 비교할 수 있습니다. 엔큐솔루션(NQ Solution)은 요구사항을 페이지 수가 아니라 기능 단위로 정리해 견적합니다. 아래 양식은 그 방식대로 만든 소규모 발주용 틀이며, 글 아래에서 PDF로 받을 수 있습니다.
RFP와 요구사항 정의서는 무엇이 다른가요?
RFP는 발주자가 업체에 «이런 일을 이런 조건으로 제안해 주세요»라고 보내는 문서입니다. 사업 개요, 목표, 일정, 예산 범위, 제안서 형식과 평가 방법이 들어갑니다. 공공 사업에서는 과업지시서와 함께 쓰는 경우가 많습니다.
요구사항 정의서는 RFP 안의 «무엇을 만들지»를 한 줄씩 쪼갠 표입니다. 기능 요구사항과 비기능 요구사항을 나누고, 줄마다 우선순위와 검수 기준을 붙입니다. 제안서는 업체가 RFP에 답해 보내는 문서입니다.
| 문서 | 쓰는 쪽 | 담는 것 | 쓰는 시점 |
|---|---|---|---|
| 제안요청서(RFP) | 발주자 | 사업 개요, 목표, 일정, 예산 범위, 평가 기준 | 업체를 찾기 전 |
| 요구사항 정의서 | 발주자, 업체와 함께 다듬음 | 기능·비기능 요구사항, 우선순위, 검수 기준 | RFP와 함께, 계약 전에 확정 |
| 제안서 | 업체 | 이해한 범위, 수행 방법, 일정, 금액, 사례 | RFP를 받은 뒤 |
| 과업내용서 | 양쪽 합의 | 계약서에 붙는 최종 범위 | 계약할 때 |
작은 발주에도 RFP가 필요한 이유
RFP 없이 «회사 홈페이지 견적 주세요»라고 물으면 업체마다 다른 홈페이지를 떠올리고 견적을 냅니다. 한 곳은 관리자 화면을 넣고, 다른 곳은 빼고, 또 다른 곳은 다국어를 따로 잡습니다. 견적이 두세 배씩 벌어지는 이유는 대개 여기에 있습니다.
A4 두세 장짜리 RFP라도 같은 문서를 여러 업체에 보내면 비교 기준이 생깁니다. 업체가 이해한 범위가 제안서에 그대로 드러나서 질문과 답도 짧아집니다.
RFP 목차는 이 열 가지면 충분합니다
| 순서 | 항목 | 적는 내용 |
|---|---|---|
| 1 | 사업 개요 | 회사·기관 소개, 사업 이름, 담당자 |
| 2 | 현재 상황 | 지금 쓰는 사이트·시스템, 불편한 점, 가진 자료 |
| 3 | 목표 | 문의 접수, 정보 공개, 업무 전산화 같은 목적 한두 줄 |
| 4 | 요구사항 | 기능·비기능 요구사항(별지 요구사항 정의서) |
| 5 | 범위 제외 | 이번에 하지 않을 일(결제, 모바일 앱 등) |
| 6 | 일정 | 희망 오픈 시점, 내부 검토 일정 |
| 7 | 예산 범위 | 상한 또는 구간 |
| 8 | 제안서 작성 지침 | 분량, 목차, 꼭 넣을 내용 |
| 9 | 평가 기준 | 평가 항목과 가중치 |
| 10 | 제출 방법 | 마감일, 제출처, 질의 창구 |
예산 범위는 적는 편이 낫습니다. 예산을 숨기면 업체는 가장 무난한 범위로 제안하고, 예산에 맞춘 우선순위 제안을 받을 기회가 사라집니다. «범위 제외»도 자주 빠집니다. 하지 않을 일을 적어야 제안서끼리 같은 범위로 비교됩니다.
요구사항 정의서 예시 — 기업 홈페이지
기업 홈페이지 한 건을 예로 들면 다음처럼 씁니다. 검수 기준은 «잘 되게»가 아니라 눈으로 확인할 수 있는 문장으로 적습니다.
| ID | 구분 | 요구사항 | 우선순위 | 검수 기준 | 비고 |
|---|---|---|---|---|---|
| F-01 | 기능 | 관리자가 공지사항을 등록·수정·삭제 | 필수 | 관리자에서 올린 글이 공개 화면에 바로 보임 | 첨부파일 포함 |
| F-02 | 기능 | 문의 폼 접수와 관리자 알림 | 필수 | 접수하면 관리자 메일이 오고 목록에서 처리 상태를 바꿈 | 개인정보 동의 칸 |
| F-03 | 기능 | 회사소개·사업 소개 문구를 관리자에서 수정 | 필수 | 지정한 칸을 고치면 공개 화면에 반영 | 수정 가능한 칸 목록 첨부 |
| F-04 | 기능 | 국문·영문 두 언어 | 선택 | 언어를 바꾸면 같은 페이지의 다른 언어로 이동 | 번역문은 발주자 제공 |
| F-05 | 기능 | 관리자 권한 구분(최고 관리자, 편집자) | 선택 | 편집자는 설정 메뉴에 들어갈 수 없음 | 없음 |
| N-01 | 비기능 | 모바일·태블릿 화면 대응 | 필수 | 폰 너비에서 가로로 넘치는 화면이 없음 | 없음 |
| N-02 | 비기능 | 검색엔진 기본 설정 | 필수 | 페이지별 제목·설명 입력, 사이트맵 제출 | 없음 |
| N-03 | 비기능 | 소스·계정 인도 | 필수 | 잔금 완납 뒤 소스와 관리자 계정 인도 | 계약서에 적음 |
우선순위는 필수와 선택 두 단계면 충분합니다. 예산이 모자라면 «선택»부터 덜어 내면 되므로 업체와 조정하기 쉽습니다.
제안서는 어떻게 비교하나요?
가격만 보면 범위를 가장 좁게 잡은 제안서가 이깁니다. 항목별 가중치를 RFP에 미리 적어 두고 같은 표로 채점합니다. 아래 가중치는 예시이며 사업 성격에 맞게 바꿉니다.
| 평가 항목 | 가중치(예시) | 보는 것 |
|---|---|---|
| 범위 이해 | 25% | 요구사항을 빠짐없이 이해했는지, 빠진 요구를 짚었는지 |
| 수행 사례 | 20% | 비슷한 기능을 만든 실제 사례 |
| 일정·진행 방식 | 15% | 단계별 산출물, 중간 확인 시점 |
| 유지보수·인도 조건 | 15% | 하자보수, 유지보수 계약, 소스 인도 |
| 가격 | 25% | 항목별 산출 근거, 부가세와 월 비용 구분 |
업체를 고른 뒤에는 요구사항 정의서를 한 번 더 다듬어 계약서의 과업 범위로 붙입니다. 계약서에서 볼 조항은 개발 외주 계약서·견적서에서 확인할 7가지에 정리했습니다.
엔큐솔루션은 요구사항을 이렇게 받습니다
RFP가 없어도 됩니다. 정식 의뢰서에 필요한 기능과 자료(파일 3개, 각 10MB까지)를 적어 보내면 고객 포털이 열리고, 요구사항과 견적, 계약이 한곳에 기록됩니다. 상담한 대표와 이사가 그 요구사항으로 설계하고 개발까지 이어 갑니다.
범위를 먼저 가늠하려면 예상 견적 계산기에서 유형과 기능을 골라 봅니다. 단가표 v1.1(2026-09-23 기준)에서 기업 홈페이지(6~9페이지)는 180만~350만원(부가세 별도), 4~6주입니다. 요구사항이 아직 흐릿하면 기획 서비스에서 요구사항 정리부터 함께합니다. 일정 감은 홈페이지 제작 기간에서, 앱·플랫폼을 작게 시작하는 법은 MVP 외주 범위에서 볼 수 있습니다.
자주 묻는 질문
제안요청서(RFP)와 과업지시서는 어떻게 다른가요?
RFP는 업체에 제안을 요청하는 문서이고, 과업지시서는 수행할 일의 내용과 조건을 정한 문서입니다. 소규모 발주라면 RFP에 요구사항 정의서를 붙여 과업지시서 역할까지 맡겨도 됩니다. 계약할 때는 합의한 최종 범위를 과업내용서로 붙입니다.
요구사항 정의서 양식에는 어떤 칸이 있어야 하나요?
ID, 구분, 요구사항, 우선순위, 검수 기준, 비고 여섯 칸이면 충분합니다. 이 가운데 검수 기준 칸이 가장 중요합니다. 이 글의 PDF 양식에 빈 표와 예시 줄을 함께 넣었습니다.
요구사항 정의서의 기능과 비기능은 어떻게 나누나요?
기능 요구사항은 사용자가 하는 일로, 공지 등록·문의 접수·로그인 같은 것입니다. 비기능 요구사항은 그 일이 돌아가야 하는 조건으로, 모바일 대응·속도·권한·소스 인도 같은 것입니다. 비기능 항목은 견적에서 자주 빠지므로 따로 적습니다.
홈페이지 구축 RFP에 예산을 꼭 적어야 하나요?
적는 편이 비교에 유리합니다. 상한이나 구간만 적어도 업체가 그 안에서 우선순위를 제안합니다. 금액 감이 없다면 예상 견적 계산기로 구간을 먼저 확인합니다.
RFP 없이 홈페이지 견적을 받아도 되나요?
받을 수 있습니다. 다만 여러 업체를 비교하려면 같은 요구사항 목록을 보내야 합니다. 엔큐솔루션은 정식 의뢰서에 적은 기능 목록으로 견적합니다.