제안요청서(RFP) 쓰는 법, 외주 맡기기 전 목차와 예시

제안요청서(RFP)는 여러 곳에 같은 조건으로 제안과 견적을 받기 위해 보내는 요청 문서입니다. 무엇을 만들지 · 언제까지 · 어느 범위의 예산으로 · 무엇을 보고 고를지를 적어 보내면, 돌아온 제안서를 같은 기준으로 나란히 놓고 비교할 수 있습니다. 프로그램이나 홈페이지 개발을 외주로 맡기기 전이라면 목표 한 줄과 기능 목록부터 적고, 나머지 칸은 아래 순서대로 채웁니다.

제안요청서란 무엇인가요

RFP는 Request for Proposal의 줄임말로, 제안요청서와 같은 문서입니다. 받는 쪽(개발사)은 이 문서를 보고 어떻게 만들지 · 누가 맡을지 · 얼마가 들지를 담은 제안서를 보내옵니다. 그래서 제안요청서는 답을 적는 문서가 아니라 같은 질문을 같은 모양으로 던지는 문서입니다.

견적 요청과 다른 점은 '어떻게'까지 제안받는다는 데 있습니다. 화면 수 · 연동 · 검수 기간처럼 금액을 맞추는 조건은 개발 견적 비교의 일곱 줄에 있습니다. 제안요청서는 여기에 배경 · 목표 · 평가 기준 · 제출 형식을 더해, 만드는 방법과 일정 계획까지 비교할 수 있게 합니다.

제안요청서 작성에 드는 시간의 대부분은 기능 목록입니다. 목록이 준비돼 있으면 나머지 칸은 반나절이면 채워지고, 이 문서가 프로그램 개발 외주의 범위를 정하는 첫 기준이 됩니다. 개발 제안요청서라고 해서 기술 용어를 쓸 필요는 없습니다. 어떤 언어나 서버로 만들지는 제안받는 쪽이 적어 올 내용이고, 맡기는 쪽은 누가 무엇을 하려고 쓰는 프로그램인지를 적습니다. 다만 이미 쓰는 서버나 꼭 이어야 할 프로그램처럼 정해진 조건은 범위 칸에 적습니다.

제안요청서·요구사항 정의서·과업지시서는 무엇이 다른가요

세 문서는 목적이 다릅니다 — 제안요청서는 업체를 고르려고, 요구사항 정의서는 만들 내용을 확정하려고, 과업지시서는 계약하고 검수하려고 씁니다. 셋 가운데 가장 자세한 것은 요구사항 정의서입니다.

과업지시서는 공공 용역에서 흔히 쓰는 이름입니다. 민간 계약에서는 계약서에 붙이는 업무 범위 문서가 같은 일을 하고, 작은 외주라면 제안요청서의 범위와 기능 목록을 계약서 붙임으로 옮겨 그 역할을 대신하기도 합니다. 요구사항 정의서를 쓰는 방법은 프로그램 개발 의뢰 전 요구사항 정리에 있습니다.

제안요청서는 어떤 순서로 쓰나요

여섯 단계입니다. 앞의 세 단계가 무엇을 만들지, 뒤의 세 단계가 어떻게 고를지를 정합니다.

1. 배경과 목표 — 지금 어떻게 일하고 무엇이 불편한지 두세 줄로 적고, 목표는 숫자를 넣어 한 줄로 적습니다. 예를 들어 '주문 접수에 드는 시간을 하루 2시간에서 30분으로 줄인다'처럼 적습니다.
2. 사용자와 화면 목록 — 관리자 · 직원 · 고객 중 누가 쓰는지 적고, 화면은 이름만 나열합니다. 화면 목록을 뽑는 방법은 화면 설계서 쓰는 법에 있습니다. 웹으로 만들지 앱으로 만들지 정하지 못했다면 그 칸은 제안받되, 쓰는 사람과 필요한 기기 기능은 적어 둡니다 — 판단 기준은 웹앱과 앱의 차이에 있습니다.
3. 필수 · 선택 기능과 만들지 않는 것 — 필수는 없으면 오픈하지 않는 기능, 선택은 예산 안에서 넣을지 제안받을 기능입니다. 이번에 만들지 않는 것도 한 줄 적습니다.
4. 일정 · 예산 범위 — 오픈 희망일과 그 날짜여야 하는 이유를 적고, 예산은 하한과 상한의 폭으로 적습니다.
5. 평가 기준 — 무엇을 보고 고를지 항목과 비중을 미리 공개합니다. 제안서가 그 순서로 돌아와 나란히 놓기 쉬워집니다.
6. 질의 기간과 제출 형식 — 제안 마감 전에 질문을 받는 기간과 답하는 방식을 정합니다. 한 곳에서 온 질문의 답은 모든 곳에 같이 보냅니다. 분량 · 파일 형식 · 마감 시각 · 결과를 알릴 날짜도 여기서 적습니다.

여섯째 단계를 빼먹기 쉽습니다. 질의 기간이 없으면 업체마다 다른 가정으로 빈칸을 채워, 조건을 맞춰 보낸 문서가 다시 제각각의 제안서로 돌아옵니다.

제안요청서 목차는 어떻게 구성하나요

여섯 단계를 마치면 아래 여덟 칸이 채워집니다. 오른쪽 칸은 전화 · 메신저로 주문을 받는 회사를 가정한 예시로, 요구사항 정리 글의 주문 업무와 같은 장면입니다.

범위 칸의 '만들지 않는 것'이 가장 많은 오해를 줄입니다. 한 줄이라도 적어 두면 업체가 그 기능을 넣은 금액과 뺀 금액을 따로 계산하지 않아도 됩니다. 금액 점수는 필수 기능을 모두 담은 제안끼리만 비교하고, 필수가 빠진 제안은 점수를 매기기 전에 빠진 줄을 표시해 둡니다.

제안요청서 양식을 따로 구하지 않아도 이 여덟 칸을 문서 하나에 차례로 옮기면 양식이 됩니다. 기능 목록 칸은 한 줄에 기능 하나씩 기능 이름 · 쓰는 사람 · 필수 여부를 적습니다. 예를 들어 '주문 등록 · 접수 담당 · 필수', '월별 판매 집계 · 대표 · 선택'처럼 적으면 업체가 화면 수를 셀 수 있습니다.

제안서가 모두 오면 평가 기준표에 따라 두 사람 이상이 따로 점수를 매긴 뒤 평균을 냅니다. 점수가 가까운 두 곳과는 한 시간 정도 설명을 듣는 자리를 잡아, 제안서의 일정표를 함께 넘기며 단계마다 누가 맡는지 듣습니다. 평가 기준을 제안요청서에 미리 적는 이유가 여기 있습니다 — 기준이 먼저 있어야 점수가 사람마다 흔들리지 않습니다.

자주 묻는 질문

예산을 적어야 하나요

폭으로 적습니다. 제안요청서에서는 여기에 한 줄을 더 붙입니다 — '이 폭 안에서 선택 기능을 몇 개까지 넣을 수 있는지 함께 제안해 주십시오.' 그러면 같은 예산으로 필수 기능 위에 무엇을 더 얹을 수 있는지가 제안서마다 드러나, 금액이 아니라 구성으로 비교할 수 있습니다. 정확한 금액을 몰라도 하한과 상한만 정하면 됩니다.

몇 곳에 보내나요

세 곳에서 다섯 곳이면 비교에 충분합니다. 보내는 곳이 늘수록 질문에 답하고 제안서를 읽는 시간도 그만큼 늘어납니다. 보내기 전에 같은 종류의 사례가 있는 곳인지 확인하고, 짧은 통화로 제안할 뜻이 있는지 먼저 물어 둡니다. 홈페이지를 맡길 곳이라면 후보를 추리는 여섯 가지 기준은 홈페이지 제작 업체 고르는 법에 있습니다.

공공 표준 템플릿을 그대로 써도 되나요

그대로 쓰지 않고 목차 이름 정도만 참고합니다. 과학기술정보통신부가 2022년 7월 배포한 「공공SW사업 제안요청서 작성 예시」는 공공기관 발주 담당자가 소프트웨어 사업 관련 법 · 제도 항목을 제안요청서에 반영하도록 만든 예시와 점검표입니다. 민간 외주에는 해당하지 않는 칸이 많아 위 여덟 칸 기준으로 줄여 씁니다. 칸이 많을수록 업체가 채울 빈칸도 늘어 제안서가 늦게 옵니다.

제안서와 제안요청서는 무엇이 다른가요

제안요청서는 맡기는 쪽이 보내는 질문지이고, 제안서는 받는 쪽이 보내는 답안지입니다. 제안서를 쓰는 쪽이라면 받은 제안요청서의 평가 기준 순서대로 목차를 짜면 그것이 양식이 됩니다.

오늘 할 일

지난주에 실제로 처리한 일 다섯 건을 떠올리며 필요한 기능을 열 줄 적은 뒤, 각 줄을 '꼭 있어야 함'과 '있으면 좋음' 두 칸으로 나누십시오. 기준은 하나입니다 — 그 기능이 없어도 오픈할 수 있으면 '있으면 좋음'입니다. 두 칸이 나뉘면 제안요청서의 기능 목록과 범위 칸이 절반쯤 채워집니다. 30분이면 됩니다.

만들 프로그램의 목표와 기능 목록 초안을 적어 문의로 보내 주시면, 제안요청서 빈칸과 화면 수를 함께 정리해 회신드립니다.

이어서 읽기 — 제안서 양식, 목차 10칸과 채운 예시·작성 순서 · 비밀유지계약서, 조항 10칸 양식과 NDA 예시