외주 개발 ·
RFP 뜻과 작성법: 외주 맡기기 전 한 장짜리 제안요청서 양식
RFP(제안요청서)는 개발사에 제안을 요청하는 문서예요. RFP 뜻과 RFI · RFQ 차이, 스타트업 외주에 맞는 한 장짜리 RFP 항목과 그대로 복사해 쓰는 양식을 정리했어요.
외주 개발을 알아보다 보면 "RFP 보내 주세요"라는 말을 자주 들어요. 막상 RFP 양식을 검색해 보면 수십 쪽짜리 공공기관 문서부터 나와요.
스타트업이 처음 외주를 맡길 때는 그렇게 두꺼울 필요가 없어요. 한 장이면 충분해요.
개발 에이전시를 8년간 운영하며 수많은 RFP를 받아 봤어요. 제안서를 쓰기 쉬웠던 RFP와 어려웠던 RFP는 분명히 달랐어요.
그 경험을 바탕으로 비개발자 창업자 입장에서 RFP 뜻과 꼭 넣을 항목, 바로 복사해 쓰는 한 장 양식을 정리했어요.
RFP 뜻이 뭔가요?
RFP는 Request for Proposal의 줄임말이에요. 우리말로는 제안요청서라고 불러요.
"이런 서비스를 만들고 싶어요. 어떻게 만들지, 얼마가 들지 제안해 주세요"라고 개발사에 건네는 문서예요. 개발사는 이 문서를 읽고 제안서와 견적서를 보내 줘요.
RFP가 하는 일은 크게 두 가지예요.
- 여러 개발사에 같은 내용으로 물어볼 수 있어요. 그래야 돌아온 제안을 나란히 놓고 비교할 수 있어요.
- 만들 내용을 글로 남길 수 있어요. 나중에 "그건 말한 적 없어요" 같은 다툼을 줄여 줘요.
RFP, RFI, RFQ는 무엇이 다른가요?
셋 다 개발사에 무언가를 요청하는 문서예요. 다만 물어보는 내용이 서로 달라요.
| 구분 | 뜻 | 언제 쓰나요 | 받는 것 |
|---|---|---|---|
| RFI (Request for Information) | 정보요청서 | 어떤 방법이 있는지 아직 모를 때 | 회사 소개, 비슷한 실적, 가능한 방식 |
| RFP (Request for Proposal) | 제안요청서 | 풀 문제는 정했고, 푸는 방법을 제안받고 싶을 때 | 만드는 방법, 일정, 견적 |
| RFQ (Request for Quotation) | 견적요청서 | 만들 것이 다 정해졌고 가격만 비교할 때 | 가격, 걸리는 기간(납기) |
큰 회사는 RFI → RFP → RFQ 순서로 세 문서를 다 쓰기도 해요. 후보 업체를 넓게 모으고 제안을 받아 본 뒤, 마지막에 가격을 비교해요.
스타트업 외주는 보통 RFP 하나면 충분해요. 아직 화면이 다 정해지지 않아서 가격만 묻는 RFQ는 이르고, RFI를 따로 보낼 만큼 후보 업체가 많지도 않거든요.
스타트업 외주에도 RFP가 필요한가요?
말로만 설명해도 견적은 받을 수 있어요. 문제는 개발사마다 다르게 알아듣는다는 점이에요.
예를 들어 전화로 "예약 앱 만들고 싶어요"라고만 해 볼게요. 어떤 곳은 카드 결제까지 넣어서 계산하고, 어떤 곳은 결제를 빼고 견적을 내요. 이러면 한 곳이 3,000만 원, 다른 곳이 5,000만 원을 불러도 서로 비교할 수가 없어요.
같은 내용을 적은 한 장짜리 RFP를 보내면 이런 오해가 줄어요. 업체마다 견적이 왜 다른지도 한눈에 보여요. 받은 견적서를 읽는 방법은 외주 개발 견적서 읽는 법에 따로 적었어요.
공공 RFP처럼 두껍게 쓰면 어떤 문제가 생기나요?
공공 소프트웨어 사업의 RFP는 수십 쪽으로 두꺼워요. 필요한 기능을 하나하나 번호를 붙여 세세하게 적어요. 여러 업체가 공정하게 경쟁해야 하고, 나중에 감사도 받아야 하기 때문이에요.
스타트업이 이 양식을 그대로 따라 하면 네 가지 문제가 생겨요.
- 모르는 것까지 정한 척하게 돼요. 빈칸을 채우려고 아직 정하지 않은 화면과 규칙까지 억지로 적게 돼요.
- 개발사는 적힌 대로만 만들어요. 그게 실제 고객에게 맞는지는 다 만든 뒤에야 알 수 있어요.
- 중간에 바꾸기 어려워요. 적힌 내용이 곧 계약 범위가 되어서, 나중에 고치려면 추가 비용이 붙어요.
- 문서 쓰는 데만 몇 주가 가요. 그동안 정작 서비스는 하나도 만들어지지 않아요.
정해진 것은 분명히 적고, 안 정해진 것은 안 정해졌다고 솔직히 적는 게 좋은 RFP예요. 이 이야기는 기획서가 두꺼울수록 위험한 이유에 더 자세히 썼어요.
한 장짜리 RFP에는 무엇을 넣나요?
우리 서비스를 설명하는 칸은 일곱 개면 돼요. 여기에 개발사에 물어볼 질문 칸(8번) 하나를 더 붙이면 끝나요.
| 칸 | 적을 것 | 왜 필요한가요 |
|---|---|---|
| 1. 한 줄 소개 | 누구의 어떤 불편을 푸는지 | 개발사가 방향을 잡아요 |
| 2. 사용자 | 쓰는 사람의 종류(고객 · 운영자 등) | 화면 수가 여기서 정해져요 |
| 3. 꼭 있어야 할 기능 | 첫 버전에 없으면 안 되는 것 3~7개 | 견적의 뼈대예요 |
| 4. 나중에 해도 되는 기능 | 있으면 좋은 것 | 견적을 나눠 받을 수 있어요 |
| 5. 참고 서비스 | 비슷한 서비스 주소와 좋은 점 | 말보다 빨라요 |
| 6. 형태와 일정 | 웹 · 앱, 원하는 출시 시점 | 기술과 인원이 정해져요 |
| 7. 아직 정하지 않은 것 | 결제 방식, 수익 모델 등 | 개발사가 제안할 여지를 줘요 |
예산 범위를 적을지는 직접 고르시면 돼요. 예산을 적으면 그 안에서 가능한 범위를 제안받고, 안 적으면 개발사가 생각하는 규모를 볼 수 있어요.
특히 7번(아직 정하지 않은 것) 칸이 중요해요. 이 칸이 비어 있으면 개발사는 모든 계획이 다 정해진 줄 알고 그대로 견적을 내요.
그대로 복사해 쓰는 RFP 양식은 어떻게 생겼나요?
아래 내용을 복사해서 메모장이나 노션에 붙여 넣고 빈칸만 채우면 돼요. 한 장을 넘기지 않는 게 목표예요.
# [서비스 이름] 제안요청서 (RFP)
작성일: 2026-__-__
보내는 사람: 회사 이름 / 이름 / 연락처
제안 회신 기한: 2026-__-__
## 1. 한 줄 소개
(누구)의 (어떤 불편)을 (어떻게) 풀어요.
## 2. 사용자
- 고객:
- 운영자(관리자):
- 그 밖에:
## 3. 꼭 있어야 할 기능 (첫 버전)
1.
2.
3.
## 4. 나중에 해도 되는 기능
-
-
## 5. 참고 서비스
- 주소: / 좋은 점:
- 주소: / 좋은 점:
## 6. 형태와 일정
- 형태: 웹 / 앱(아이폰 · 안드로이드) / 둘 다
- 원하는 출시 시점:
- 예산 범위(선택):
## 7. 아직 정하지 않은 것
-
-
## 8. 제안서에 담아 주실 것
- 만드는 방식과 일정
- 화면 · 기능 목록과 견적(포함 · 미포함 항목 구분)
- 소스코드 · 서버 · 도메인 계정을 넘기는 방법
- 출시 뒤 하자보수 기간과 유지보수 조건
8번 칸은 개발사에 묻는 공통 질문이에요. 모든 개발사가 같은 질문에 답하면 제안서를 비교하기가 훨씬 쉬워져요.
참고로 8번의 소스코드는 프로그램 설계도 원본이고, 하자보수는 출시 뒤에 발견된 오류를 무료로 고쳐 주는 기간이에요.
RFP 항목은 어떻게 채우나요?
동네 필라테스 스튜디오의 예약 서비스를 만든다고 가정하고 채워 볼게요.
- 1. 한 줄 소개: "회원이 카톡으로 하던 수업 예약을 직접 하게 해요."
- 2. 사용자: 회원, 강사, 원장(운영자). 쓰는 사람이 세 종류면 화면도 세 갈래로 나뉜다는 걸 개발사가 바로 알 수 있어요.
- 3. 꼭 있어야 할 기능: 수업 시간표 보기, 예약과 취소, 남은 수강권 횟수 보기, 원장이 시간표 올리기. 첫 버전은 이 네 개면 충분해요.
- 4. 나중에 해도 되는 기능: 카드 결제, 대기 예약, 출석 체크. 첫 버전에서는 수강권을 현장에서 팔아도 돼요.
- 5. 참고 서비스: 지금 쓰는 예약 앱 주소와 함께 "시간표가 한눈에 보여서 좋아요"처럼 좋았던 점을 한 줄로 적어요.
- 6. 형태와 일정: "웹으로 먼저 만들고 싶어요. 다음 달 안에 회원 20명이 써 보면 좋겠어요."
- 7. 아직 정하지 않은 것: "취소 마감을 몇 시간 전으로 할지 모르겠어요. 수강권 환불 규칙도 아직 못 정했어요."
이렇게 채우면 한 장이 채 안 돼요. 그래도 개발사가 견적을 내기에는 충분해요.
RFP를 보낸 뒤에는 무엇을 보나요?
개발사에서 제안서가 오면 금액보다 먼저 아래 세 가지를 확인해 보세요.
- 7번 칸에 어떻게 답했나요? 아직 안 정해진 것을 어떻게 함께 정할지 제안하는 곳이 좋은 파트너예요.
- 화면 · 기능 목록이 있나요? 세부 목록 없이 총액만 적혀 있으면 다른 곳과 비교할 근거가 없어요.
- 8번 질문에 다 답했나요? 특히 계정 명의와 하자보수 조건을 빼먹은 곳은 계약 전에 꼭 다시 물어보세요.
업체를 고를 때 물어볼 질문 15개는 외주 업체 선정 체크리스트에 정리해 뒀어요. 견적서 여러 장을 나란히 놓고 비교하는 법은 외주 개발 견적 비교에 있어요.
글보다 화면을 먼저 그려 보면 어떤가요?
RFP를 아무리 잘 써도 글만으로는 한계가 있어요. "시간표가 한눈에 보이게"라는 똑같은 문장을 보고도 개발사마다 다른 화면을 떠올려요.
그래서 RFP에 화면 초안 그림(와이어프레임)을 같이 붙이면 오해가 크게 줄어요. 종이에 손으로 대충 그려서 찍은 사진도 괜찮아요. 어떤 화면을 어디까지 준비하면 되는지는 와이어프레임 · 화면설계서 준비하기에 적었어요.
손으로 직접 그리기 어려우면 AI에게 맡겨도 돼요. (주)헤이제임스의 셀프 견적에 서비스 설명을 넣으면 AI가 직접 눌러 볼 수 있는 화면 샘플(프로토타입)을 그려 줘요.
그 화면을 보며 기능을 넣고 빼면 견적이 바로 바뀌고, 견적서도 내려받을 수 있어요. 완성된 화면 주소를 RFP에 같이 붙여 보내셔도 돼요.
정리하면
- RFP는 제안요청서예요. RFI는 정보, RFQ는 가격을 묻는 문서예요.
- 스타트업 외주는 한 장짜리 RFP 하나면 충분해요.
- 정해진 것은 분명히, 안 정해진 것은 안 정해졌다고 적어요.
- 글만 보내지 말고 화면 그림을 같이 붙이면 견적이 정확해져요.
RFP를 쓰기 전에 화면부터 보고 싶으면 셀프 견적에서 서비스 설명을 넣어 보세요. 화면과 견적이 같이 나와요.
자주 묻는 질문
RFP와 기획서는 같은 건가요?
비슷해 보이지만 목적이 달라요. RFP는 개발사를 고르기 전에 제안을 받으려고 쓰는 문서예요. 반면에 기획서는 무엇을 어떻게 만들지 세세하게 정한 문서라서, 보통 개발사를 정한 뒤에 같이 다듬어요.
RFP에 예산을 꼭 적어야 하나요?
꼭 적지 않아도 돼요. 예산을 적으면 그 안에서 가능한 범위를 제안받고, 안 적으면 개발사가 보는 적정 규모를 알 수 있어요. 처음이라 감이 없다면 비워 두고 받아 본 뒤에 정해도 돼요.
헤이제임스에도 RFP를 보내야 하나요?
안 보내셔도 돼요. 풀 문제와 고객을 말로 설명해 주시면 돼요. 화면을 같이 보며 4시간 한 세션에 만들고, 한 세션은 550만 원(부가세 포함)이에요.
쓴 사람 — 제임스
연세대 컴퓨터과학을 전공한 23년차 개발자예요. 개발 에이전시를 8년간 운영하며 스타트업 플랫폼 350개를 만들었고, 연매출 100억 원 커머스 기업의 CTO를 지냈어요. 정부지원사업을 받아도 봤고 심사위원도 해 봤어요. 최근 2년은 AI로 개발을 효율화하는 데 집중하고 있어요.