RFP 작성법: 제안사가 정확히 견적 내는 제안요청서 실무 예시와 워드 양식 (양식 다운로드)

RFP 작성법이 막막하다면 글 하단의 제안요청서 워드 빈 양식과 작성 체크리스트를 다운로드해 바로 채워 볼 수 있다. 좋은 제안요청서는 문서를 길게 쓰는 것이 아니라 사업 목표, 포함·제외 범위, 요구사항, 산출물, 검수 기준과 제안서 작성 기준을 같은 조건으로 제공해 여러 업체의 견적을 비교할 수 있게 만든다. 이번 글에서는 초보 IT PM도 활용할 수 있도록 RFP 목차, 요구사항 좋은 예·나쁜 예, 빈칸 템플릿과 평가표까지 한 번에 정리해 보았다!

RFP 워드 양식 다운로드 안내

본문을 읽으며 바로 적용할 수 있도록 다음 두 파일을 함께 준비했다.

• RFP 작성 가이드와 검토 체크리스트: 구성 항목, 좋은 요구사항 예시, 견적 비교 기준과 배포 전 점검 항목을 빠르게 확인하는 참고 문서
• 제안요청서 빈 양식: 사업 개요부터 요구사항, 산출물, 일정, 평가 기준과 질의·제출 정보까지 직접 입력하는 실무용 Word 서식

두 파일은 이 글의 첨부파일에서 내려받을 수 있다. 먼저 작성 가이드로 빠진 항목을 확인하고, 빈 양식에 실제 사업 정보를 채우면 처음부터 표를 만들지 않아도 된다. 미확정 내용은 임의로 확정하지 말고 담당자와 확인할 값으로 남겨 두자.

RFP란 무엇인가?

RFP는 Request for Proposal의 약자로, 우리 조직이 해결하려는 문제와 필요한 업무를 설명하고 공급사에 수행 방법·일정·비용을 포함한 제안을 요청하는 문서다. 한국어로는 보통 제안요청서라고 부른다.

단순히 “홈페이지를 만들어 주세요”라고 요청하면 업체마다 가정하는 페이지 수, 관리자 기능, 데이터 이전 범위, 테스트 수준이 달라진다. 총액만 비교하면 싸 보이는 견적이 실제로는 필수 범위를 제외했을 수도 있다. 그래서 RFP에는 적어도 다음 질문의 답이 들어가야 한다.

• 왜 이 사업을 하는가?
• 지금 무엇이 문제인가?
• 어디까지 맡기고 어디부터는 맡기지 않는가?
• 어떤 기능과 품질 조건을 충족해야 하는가?
• 무엇을 납품하고 어떤 기준으로 검수하는가?
• 제안사는 어떤 형식으로 일정과 비용을 제시해야 하는가?
• 발주사는 무엇을 기준으로 제안서를 평가하는가?

공공 정보화 사업의 실제 제안요청서도 사업 개요, 현황, 상세 요구사항, 수행 조직과 일정, 계약상 책임, 법적 제약 등을 구체적으로 제시한다. 국가 지속가능발전목표 포털의 제안요청서 사례처럼 실제 문서를 보면 요구사항을 기능만으로 끝내지 않고 운영·보안·품질·프로젝트 관리까지 나누는 이유를 이해하기 쉽다.

RFP·과업지시서·요구사항 정의서는 어떻게 다를까?

세 문서는 연결되지만 쓰는 시점과 목적이 다르다.

문서	핵심 목적	주로 쓰는 시점	핵심 내용
RFP·제안요청서	여러 제안사에 해결 방법과 견적을 요청	업체 선정 전	배경, 범위, 요구사항, 제안 형식, 평가 기준
과업지시서	계약 후 수행해야 할 업무와 책임을 통제	발주·계약 단계	과업 범위, 산출물, 일정, 보고, 검수, 책임
요구사항 정의서	제품이 충족해야 할 기능과 조건을 상세화	기획·분석·개발 단계	기능, 입력·처리·출력, 예외, 비기능, 인수 조건

실무에서는 RFP에 핵심 요구사항을 넣고, 선정된 제안사의 제안 내용과 협의 결과를 반영해 과업지시서와 상세 요구사항 정의서를 구체화한다. 다만 계약 범위에 영향을 주는 중요한 조건을 “선정 후 협의”로 모두 미루면 견적의 전제가 달라지므로 주의해야 한다.

제안사가 정확히 견적 내는 RFP 구성 8가지

1. 사업 배경과 목표

조직 소개보다 먼저 이번 사업이 해결해야 할 문제와 성공 상태를 쓴다.

나쁜 예

노후화된 서비스를 최신 트렌드에 맞게 개선한다.

좋은 예

모바일 회원가입 과정에서 본인인증 이후 이탈이 발생하고 있다. 이번 사업은 가입 흐름과 오류 안내를 개선하고, 운영자가 단계별 상태를 확인할 수 있는 관리 기능을 구축하는 것을 목표로 한다. 실제 목표값은 {{기준 데이터와 목표 수치 — 내부 확인 후 입력}}으로 확정한다.

성과 수치가 아직 확인되지 않았다면 그럴듯한 숫자를 만들지 않는다. 측정 지표, 기준 시점, 데이터 담당자를 빈칸으로 남겨 실제 값으로 교체하는 편이 안전하다.

2. 현황과 문제

제안사가 현재 환경을 이해해야 기존 시스템 연동, 데이터 이전, 운영 중단 위험을 견적에 반영할 수 있다.

• 현재 사용자 흐름과 주요 문제
• 운영 중인 서비스와 관리자 기능
• 연동 대상 시스템과 담당 조직
• 보유 데이터의 종류와 대략적인 범위
• 기존 문서·소스·디자인 자산의 제공 가능 여부
• 기술·보안·운영상 제약

보안상 RFP에 공개할 수 없는 정보는 무리하게 넣지 말고, 제공 시점과 열람 조건을 명시한다.

3. 포함 범위와 제외 범위

견적 차이가 가장 크게 벌어지는 부분이다. 기능 목록만 쓰지 말고 채널, 사용자 유형, 관리자, 연동, 데이터, 운영 환경까지 범위를 확인한다.

## 수행 범위
- 포함:
  - 모바일 웹 회원가입 화면 개편
  - 이메일·휴대전화 인증 연동
  - 가입 단계별 상태를 확인하는 관리자 화면
  - 기존 회원 데이터 호환 검증
- 제외:
  - 로그인 이후 마이페이지 개편
  - 인증 서비스 이용료
  - 다국어 화면 제작
  - 운영 콘텐츠 입력 대행

제외 범위를 적는다고 일을 줄이는 것은 아니다. 서로 다른 가정을 없애 추가 비용과 일정 분쟁을 예방하는 장치다.

4. 상세 요구사항

요구사항은 가능하면 고유 ID를 붙이고 유형별로 나눈다. 기능 요구사항뿐 아니라 성능, 보안, 데이터, 인터페이스, 접근성, 운영, 프로젝트 관리 요구사항도 사업에 필요한 만큼 포함한다.

항목	작성 내용
요구사항 ID	추적 가능한 고유 번호
구분	기능·성능·보안·데이터·연동·운영 등
요구사항명	한눈에 구분되는 이름
상세 설명	대상, 조건, 처리, 결과, 예외
우선순위	필수·선택 또는 합의한 기준
검수 기준	완료 여부를 확인할 방법과 증빙
관련 자료	화면, 정책, 데이터, 시스템 문서

요구사항은 정확성, 명확성, 완전성, 일관성, 수정 가능성, 추적 가능성을 갖춰야 한다. 특히 편리하게, 빠르게, 직관적으로처럼 사람마다 해석이 달라지는 표현은 확인 가능한 조건으로 바꾼다.

 

 

 

나쁜 예

사용자가 편리하게 회원가입할 수 있어야 한다.

좋은 예

FR-01 비회원 사용자는 이메일 주소, 비밀번호, 필수 약관 동의를 입력해 가입을 요청할 수 있어야 한다. 이메일이 이미 등록된 경우 중복 가입을 생성하지 않고 안내 문구를 표시한다. 정상 가입 시 회원 레코드를 생성하고 완료 화면으로 이동한다. 입력 규칙과 오류 문구는 확정된 화면정의서를 따른다.

검수 기준 예시

• 정상 정보 입력 시 회원 레코드가 한 건 생성된다.
• 중복 이메일 입력 시 신규 회원이 생성되지 않는다.
• 필수 약관 미동의 시 가입 요청을 진행할 수 없다.
• 정상·오류·중단 흐름의 테스트 결과를 제출한다.

5. 산출물과 검수·인수 기준

기획서, 디자인, 개발 결과물처럼 이름만 쓰면 파일 형식, 포함 내용, 승인 주체가 달라질 수 있다. 각 산출물에 다음을 붙인다.

• 산출물명과 제출 형식
• 제출 시점과 버전 관리 방법
• 반드시 포함할 내용
• 검토자와 최종 승인자
• 수정 횟수 또는 결함 처리 원칙
• 검수 방법과 통과 기준
• 소스·계정·라이선스·저작권 인계 범위

예를 들어 테스트 결과서라면 대상 요구사항 ID, 수행 환경, 예상 결과, 실제 결과, 결함 상태가 포함되어야 한다고 적을 수 있다.

6. 일정과 수행 방식

고정된 마감일만 제시하지 말고 중요한 마일스톤과 의존 조건을 함께 보여 준다.

• 제안 요청·질의·제안서 제출 일정
• 착수 예정일과 목표 완료일
• 분석·설계·개발·테스트·오픈 마일스톤
• 발주사 검토와 의사결정에 필요한 기간
• 정기 보고와 회의 방식
• 상주·비상주, 원격 협업 등 수행 조건
• 다른 프로젝트나 외부 기관에 의존하는 일정

실제 일정이 확정되지 않았다면 {{목표 오픈일 — 내부 일정 확정 후 입력}}처럼 표시한다. 근거 없는 날짜를 확정값처럼 적으면 제안사가 무리한 인력 투입을 전제로 견적할 수 있다.

7. 제안서와 견적서 작성 기준

비교 가능한 제안을 받으려면 제출 형식을 통일해야 한다.

## 제안서 작성 기준
- 회사 및 유사 프로젝트 수행 경험
- 요구사항별 구현 방안과 충족 여부
- 프로젝트 조직도와 역할별 투입 계획
- 단계별 일정과 주요 산출물
- 품질·보안·위험·변경 관리 방안
- 가정, 제약, 제외 항목

## 견적서 작성 기준
- 기획·디자인·개발·QA·PM 등 항목별 비용
- 선택 기능의 별도 비용
- 외부 서비스·라이선스·인프라 비용
- 부가세 포함 여부
- 무상 하자보수 범위와 기간
- 추가 작업의 단가 또는 산정 방식

총액 한 줄만 받으면 업체별 범위 차이를 찾기 어렵다. 비용 항목, 가정, 제외 사항, 선택 옵션을 분리해 달라고 요청하자.

8. 평가 기준과 질의 절차

평가 기준을 미리 정하면 발표 분위기나 친숙함에 흔들리지 않고 제안서를 비교하기 쉽다.

평가 영역	확인 질문	배점 예시
요구사항 이해	문제와 범위를 정확히 이해했는가?	20
수행 방안	구현·검수·전환 방법이 구체적인가?	25
인력과 경험	실제 투입 인력의 역할과 경험이 적절한가?	20
일정·위험 관리	의존성과 위험 대응이 현실적인가?	15
비용	범위 대비 비용 근거가 투명한가?	20
합계		100

배점은 예시일 뿐이다. 실제 사업의 중요도와 조직의 구매 절차에 맞춰 확정해야 한다. 질문 접수 기한, 답변 방식, 설명회 여부, 제안서 제출 형식도 함께 안내하고 모든 제안사에 동일한 정보를 제공한다.

회원가입 개선 RFP 요구사항 예시

아래 예시는 작성 방식을 보여 주기 위한 간단한 샘플이다.

ID	구분	요구사항	우선순위	검수 기준
FR-01	기능	이메일·비밀번호·필수 약관 동의로 회원가입을 요청한다.	필수	정상 가입과 필수값 누락 테스트 통과
FR-02	기능	등록된 이메일이면 중복 가입을 생성하지 않고 안내한다.	필수	중복 데이터 미생성 및 안내 문구 확인
IF-01	연동	발주사가 지정한 인증 서비스와 연동한다.	필수	정상·실패·시간 초과 응답 처리 확인
DA-01	데이터	기존 회원 데이터 구조와 신규 가입 데이터의 호환성을 검증한다.	필수	샘플 이관 결과와 오류 목록 제출
SE-01	보안	비밀번호와 인증 정보는 확정된 보안 정책에 따라 처리한다.	필수	보안 점검 결과와 조치 내역 제출
OP-01	운영	관리자는 가입 단계와 실패 사유를 권한 범위 안에서 조회한다.	선택	권한별 조회 범위와 로그 확인

보안 기준, 응답 시간, 데이터 보존 기간처럼 전문 판단이 필요한 항목은 내부 보안 담당자와 기술 담당자의 검토를 받아 구체적인 기준을 확정한다.

바로 복사해 쓰는 RFP 빈칸 템플릿

아래 내용을 복사해도 되고, 표가 포함된 문서가 편하다면 글의 첨부파일 RFP_빈양식.docx를 다운로드해 작성하면 된다.

# {{사업명}} 제안요청서

## 1. 사업 개요
- 사업명:
- 추진 배경:
- 해결할 문제:
- 사업 목표:
- 기대 결과:
- 목표 지표와 기준일:

## 2. 현황과 제약
- 현재 업무·서비스 흐름:
- 기존 시스템·연동 대상:
- 보유 데이터:
- 제공 가능한 자료:
- 기술·보안·운영 제약:

## 3. 수행 범위
- 포함 범위:
- 제외 범위:
- 발주사 제공 사항:
- 제안사 담당 사항:

## 4. 요구사항
| ID | 구분 | 요구사항명 | 상세 설명 | 우선순위 | 검수 기준 | 관련 자료 |
|---|---|---|---|---|---|---|
| FR-01 | 기능 |  |  | 필수 |  |  |

## 5. 산출물과 인수 기준
| 산출물 | 형식 | 제출 시점 | 포함 내용 | 검토자 | 통과 기준 |
|---|---|---|---|---|---|
|  |  |  |  |  |  |

## 6. 일정과 수행 조건
- 제안 일정:
- 착수 예정일:
- 목표 완료일:
- 주요 마일스톤:
- 회의·보고 방식:
- 수행 장소·협업 도구:

## 7. 제안서·견적서 작성 기준
- 제안서 목차:
- 요구사항 대응표:
- 투입 인력 계획:
- 항목별 견적:
- 별도 비용과 제외 사항:
- 가정과 제약:
- 유지보수·하자보수 조건:

## 8. 평가와 질의
- 평가 항목과 배점:
- 질의 접수 기간·방법:
- 답변 공개 방식:
- 제안서 제출 기한·형식:
- 담당 부서와 연락 방법:

RFP 작성할 때 자주 하는 실수

목표 대신 기능 목록만 적는다

기능이 필요한 이유를 모르면 제안사는 더 나은 대안을 제시하기 어렵다. 배경과 목표를 먼저 제시하고 기능을 연결한다.

포함 범위만 있고 제외 범위가 없다

제안사는 불확실성을 위험 비용으로 반영하거나 자기 기준으로 제외한다. 채널, 데이터, 외부 서비스, 콘텐츠, 운영 지원에서 제외되는 항목을 확인한다.

“협의한다”는 말로 중요한 조건을 미룬다

세부 조정은 필요하지만 견적과 계약 범위를 바꾸는 핵심 조건까지 미루면 비교가 불가능해진다. 미확정 항목은 미확정이라고 표시하고, 제안사가 적용한 가정과 대안을 따로 쓰게 한다.

산출물 이름만 적고 인수 기준은 쓰지 않는다

제출과 완료는 다르다. 누가 어떤 기준으로 검토하고, 수정 후 무엇을 확인해야 인수하는지 적는다.

가격만 한 줄로 비교한다

낮은 가격이 같은 범위를 의미하는지 확인해야 한다. 요구사항 대응표와 항목별 견적, 제외 사항, 별도 비용을 나란히 비교한다.

평가 기준을 제안서를 받은 뒤 만든다

기준이 늦게 정해지면 평가자의 취향과 발표 인상에 좌우될 수 있다. 사업 목표와 필수 요구사항에 맞춰 평가 기준과 배점을 먼저 합의한다.

RFP 배포 전 체크리스트

• 사업 목표와 현재 문제가 한 문장으로 설명된다.
• 포함 범위와 제외 범위가 구분되어 있다.
• 발주사와 제안사의 역할이 나뉘어 있다.
• 요구사항에 ID, 조건, 결과, 예외, 검수 기준이 있다.
• 기능 외에 데이터·연동·성능·보안·운영 조건을 검토했다.
• 산출물의 형식, 제출 시점, 포함 내용이 명확하다.
• 검토자·승인자와 인수 기준이 정해져 있다.
• 일정에 발주사 검토와 외부 의존 기간이 반영되어 있다.
• 항목별 견적과 별도 비용을 요청한다.
• 제안사가 가정·제약·제외 항목을 밝히게 한다.
• 평가 항목과 배점이 사업 목표에 연결된다.
• 모든 제안사가 같은 질의 답변을 받을 절차가 있다.
• 개인정보·보안·저작권·라이선스 조건을 담당자가 검토했다.

RFP 작성법 FAQ

RFP는 상세할수록 좋은가요?

길이보다 의사결정에 필요한 정보가 정확한지가 중요하다. 목표와 제약은 분명히 하되, 제안사의 전문적인 해결 방법까지 발주사가 하나로 고정할 필요는 없다. 반드시 지켜야 할 조건과 제안 가능한 영역을 구분한다.

예산을 RFP에 공개해야 하나요?

조직의 구매 정책과 협상 방식에 따라 다르다. 공개한다면 예산 범위, 부가세 포함 여부, 외부 서비스 비용 포함 여부를 명시한다. 공개하지 않더라도 동일한 견적 항목과 산정 기준을 요청해야 비교가 가능하다.

요구사항이 아직 확정되지 않았는데 RFP를 보내도 될까요?

핵심 범위와 필수 요구사항이 불명확하면 먼저 사전 정보 요청이나 짧은 발견 단계가 필요할 수 있다. 그대로 발송해야 한다면 미확정 항목, 제안사가 둔 가정, 확정 절차와 변경 시 비용 산정 방식을 명시한다.

업체마다 견적 차이가 너무 크면 어떻게 확인하나요?

총액보다 요구사항 대응표, 투입 역할, 산출물, 제외 항목, 외부 비용, 하자보수 조건을 먼저 맞춰 본다. 같은 범위를 전제로 하지 않았다면 보완 질문을 동일하게 전달한 뒤 수정 견적을 비교한다.

RFP 작성법 핵심 정리

RFP 작성법의 핵심은 요구사항을 많이 적는 데 있지 않다. 모든 제안사가 같은 목표와 범위를 이해하고, 같은 기준으로 수행 방법·일정·비용을 제시하게 만드는 것이 중요하다. 사업 배경부터 범위, 요구사항, 산출물, 검수, 견적 양식, 평가 기준까지 연결하면 “무엇이 포함된 가격인지”를 훨씬 분명하게 비교할 수 있다. 좋은 RFP는 싼 견적을 받는 문서가 아니라, 예상 밖의 추가 비용과 일정 충돌을 줄이는 첫 번째 프로젝트 관리 도구다~

참고한 최신 출처

• 국가 지속가능발전목표 포털: 정보화 사업 제안요청서 사례
• 나라장터: 2026년 정보화 사업 제안요청서 사례
• KDI 경제정보센터: 공공 소프트웨어 사업 제안요청서 예시 배포 안내
• 중소벤처기업부: 정보화 사업 제안요청서 예시

 

RFP_빈양식.docx

0.04MB

RFP_작성_가이드_및_체크리스트.docx

0.04MB