제안요청서 작성법 2026, 비교 견적 받는 RFP 7항목

제안요청서(RFP)는 여러 업체에 같은 기준으로 견적을 요청하려고 발주자가 먼저 쓰는 문서다. 이 문서 하나가 있으면 업체마다 다른 잣대로 뽑아 온 견적을 나란히 놓고 비교할 수 있다. 없으면 같은 요구인데도 견적이 두세 배씩 벌어진다. 2026년 기준으로도 홈페이지·웹앱 외주에서 견적 편차의 대부분은 실력 차가 아니라 요청서가 부실해서 생긴다. 이 글은 비교 가능한 견적을 받아 내는 RFP 7가지 항목과 작성 순서를 정리한다.

핵심 요약

• 제안요청서(RFP)는 "무엇을, 왜, 언제까지, 어떤 기준으로 뽑겠다"를 한 문서에 담아 여러 업체에 동일하게 보내는 발주 문서다.
• 꼭 들어갈 7가지는 배경·목적, 사업 범위, 요구사항, 산출물, 일정, 예산 범위, 평가·선정 기준이다.
• 같은 RFP를 받은 업체들의 견적은 항목이 정렬돼 사과 대 사과로 비교된다 — 이것이 RFP의 유일하고 진짜인 목적이다.
• 요구사항정의서·과업지시서와는 목적·시점·작성자가 다르다. RFP는 계약 전 업체를 고르려고 발주자가 쓴다.
• 예산은 숨기지 말고 범위로 열어 두는 편이 정확한 견적을 부른다.

제안요청서가 견적을 비교 가능하게 만드는 이유

견적이 업체마다 다른 이유는 대부분 실력이 아니라 해석 차이다. "간단한 예약 홈페이지"라는 한 줄을 놓고 A업체는 달력 하나 붙인 5페이지를 떠올리고 B업체는 회원·결제·문자 알림까지 붙은 시스템을 떠올린다. 두 견적을 나란히 놓으면 B가 비싸 보이지만 실제로는 서로 다른 물건에 값을 매긴 셈이다. 비교 자체가 성립하지 않는다.

제안요청서는 이 해석의 폭을 좁힌다. 범위·요구사항·산출물을 발주자가 먼저 못 박아 두면, 업체들은 같은 그림을 보고 값을 매긴다. 그제야 견적서의 숫자가 "누가 더 싸냐"가 아니라 "같은 일을 누가 어떻게 하겠다는 거냐"를 말해 준다. 발주 상담을 하다 보면, 견적서 세 장을 들고 와 "왜 이렇게 다르냐"고 묻는 분이 많다. 열에 아홉은 세 업체에 서로 다른 말로 요청했기 때문이다.

여기서 한 가지 오해를 짚고 간다. RFP는 발주자가 기술을 다 알아야 쓸 수 있는 문서가 아니다. 기술 명세는 업체가 제안서에 채워 오는 몫이고 발주자는 "무엇을 이루고 싶은지"와 "어떤 조건은 반드시 지켜야 하는지"만 분명히 하면 된다. 기술을 몰라서 RFP를 못 쓰는 게 아니라, 목적을 안 정해서 못 쓴다.

목적을 정한다는 건 거창한 일이 아니다. "전화로만 받던 예약을 온라인으로 옮기고 싶다"거나 "지금보다 상담 문의를 더 받고 싶다"처럼, 사이트가 풀어야 할 문제를 한 줄로 적으면 그게 목적이다. 이 한 줄이 있으면 업체는 거기에 맞는 화면과 기능을 제안한다. 없으면 저마다 상상한 범위로 값을 매긴다. 실제로 "예쁘게 만들어 주세요"만 들고 오는 발주와 "예약 전화를 줄이고 싶어요"를 들고 오는 발주는, 받아 오는 견적의 정확도가 처음부터 다르다.

제안요청서에 꼭 들어가는 7가지 항목

공공 소프트웨어 사업은 소프트웨어진흥법 개정으로 2013년부터 발주 시 요구사항을 상세하게 제시할 의무가 생겨 제안요청서 틀이 사실상 정해져 있다. 민간 홈페이지·앱 발주에는 그런 강제가 없다. 대신 발주자가 스스로 최소 뼈대를 갖춰야 한다. 규모와 상관없이 다음 일곱 가지는 넣는 편이 좋다. 각 항목이 빠지면 견적의 어느 부분이 흔들리는지 함께 적었다.

항목	무엇을 적나	빠지면 생기는 일
배경·목적	왜 만드는지, 이 사이트로 이루려는 것	업체가 방향을 못 잡아 엉뚱한 제안이 온다
사업 범위	만들 화면·기능의 경계, 포함·제외 목록	범위 해석이 갈려 견적이 두세 배 벌어진다
요구사항	기능·디자인·성능 등 지켜야 할 조건	계약 후 "그건 말 안 했잖아요" 분쟁이 난다
산출물	넘겨받을 결과물(소스·디자인 원본·매뉴얼)	완성 뒤 소스코드나 원본을 못 받는다
일정	오픈 희망일, 중간 점검 시점	착수 시기·순서가 뒤엉킨다
예산 범위	쓸 수 있는 금액대(상한이라도)	범위를 모르는 과잉·과소 견적이 온다
평가·선정 기준	무엇을 보고 업체를 고를지	가격만 보고 골라 재작업으로 더 든다

이 가운데 발주자가 가장 자주 빼먹는 항목이 산출물과 평가 기준이다. 산출물을 안 적으면 사이트는 받았는데 소스코드·디자인 원본은 업체가 쥐고 있어 나중에 다른 업체로 옮길 때 처음부터 다시 만들어야 하는 일이 생긴다. 여기에 유지보수·하자보수를 몇 개월 포함하는지까지 적어 두면, 견적 편차의 숨은 원인을 미리 거른다. 견적이 갈리는 진짜 이유는 기능 개수보다 이 산출물·소유권·유지보수 범위인 경우가 많은데, 가장 싼 견적이 알고 보면 "유지보수·소스 제외"라서 사후에 더 드는 식이다. 평가 기준을 안 적으면 결국 최저가로 기울고 그 최저가가 가장 비싼 선택이 되곤 한다. 그래서 평가 기준에는 가격 하나만 두지 말고 비슷한 규모의 포트폴리오가 있는지, 오픈 뒤 유지보수를 어떻게 하는지, 제시한 일정을 지킬 근거가 있는지를 함께 넣는다. 이 네 축에 가중치를 나눠 두면 나중에 마음이 흔들려도 처음 세운 기준으로 돌아올 수 있다.

제안요청서 양식과 템플릿, 형식은 어디까지 갖출까

"제안요청서 양식"을 검색해 남의 표준 템플릿을 통째로 받아 쓰는 경우가 많은데, 민간 홈페이지 발주에서는 형식보다 내용이 먼저다. 화려한 표지와 목차를 갖춘 스무 쪽짜리 문서보다, 앞의 일곱 항목을 A4 두세 장에 또렷하게 적은 쪽이 업체에게 훨씬 쓸모 있다. 형식은 다음 세 가지만 지키면 충분하다.

• 항목마다 제목을 달아 업체가 제안서에서 같은 순서로 답하게 만든다. 그래야 여러 제안서를 줄 맞춰 비교할 수 있다.
• 필수 조건과 희망 조건을 나눠 표시한다. "반드시"와 "가능하면"을 섞어 적으면 업체마다 어디까지가 필수인지 다르게 읽어 견적이 흔들린다.
• 참고 사이트나 보유 자료가 있으면 링크·파일로 함께 첨부한다. 말로 백 번 설명하는 것보다 참고 사이트 두어 개가 방향을 더 정확히 전한다.

템플릿을 굳이 찾는다면 공공 소프트웨어 사업의 제안요청서 항목 구성을 참고하되, 민간 규모에 맞게 덜어 내는 편이 낫다. 공공 RFP는 법정 요건 때문에 항목이 방대해서, 소규모 발주자가 그대로 옮기면 오히려 핵심이 묻힌다. 내가 만들려는 게 어떤 유형인지, 범위가 어디까지인지부터 감이 안 선다면 홈페이지 제작 안내에서 유형별 구성과 시작 범위를 먼저 훑어보고 RFP의 범위 항목을 채우면 수월하다.

소상공인이나 1인 사업자라면 공공식 격식을 다 갖출 필요가 없다. 앞의 일곱 항목을 한두 쪽에 눌러 담은 경량 RFP 한 장이면 충분하다. 표지·목차·회사 소개 같은 형식 요소를 걷어 내고 목적 한 단락, 범위 표 하나, 예산 범위, 평가 기준 네 줄만 남겨도 업체는 같은 기준으로 견적을 낸다. 문서를 갖추는 목적은 격식이 아니라 비교 가능성 하나라는 걸 기억하면, 어디까지 힘을 뺄지 판단이 선다.

요구사항정의서·과업지시서와 무엇이 다른가

세 문서는 이름이 비슷해 자주 섞인다. 핵심 차이는 목적과 시점이다. 제안요청서는 계약 전 여러 업체를 고르려고 발주자가 쓴다. 요구사항정의서는 무엇을 만들지 상세히 규정하는 명세이고 과업지시서는 계약 후 수행할 일을 지시하는 문서다.

구분	제안요청서(RFP)	요구사항정의서	과업지시서
목적	업체 선정·비교 견적	만들 것의 상세 규정	수행 업무 지시
시점	계약 전	발주 준비~착수	계약 후
작성자	발주자	발주자(또는 함께)	발주자
깊이	목적·조건 중심	화면·기능 단위 상세	업무·책임 범위

실무에서는 RFP에 요구사항을 통째로 담기보다, RFP에는 범위와 핵심 조건만 적고 상세는 별도 요구사항정의서로 붙이는 경우가 많다. 요구사항을 어디까지 적어야 하는지는 요구사항 정의서 작성법에서 화면·기능·데이터·예외 네 갈래로 나눠 정리해 두었다. RFP를 처음 쓴다면 그 문서를 요구사항 항목의 채움표로 함께 쓰면 된다.

여러 업체에 보내 비교 견적 받는 순서

문서를 갖췄다면 실제 비교는 순서를 지켜야 깔끔하다. 아래 절차대로 하면 같은 조건에서 견적을 받아 나란히 비교할 수 있다.

1. RFP 초안을 쓰고 범위·예산·일정 세 항목이 서로 모순되지 않는지 한 번 읽는다.
2. 후보 업체 3~4곳을 추린다. 너무 많으면 비교가 힘들고 두 곳뿐이면 기준이 안 선다.
3. 같은 RFP를 동시에 보내고 질의응답 기한과 제출 기한을 같게 준다.
4. 들어온 제안서를 평가 기준표에 맞춰 항목별로 점수를 매긴다.
5. 가격이 가장 다른 두 곳에 "왜 이 금액인지"를 물어 범위 해석 차이를 확인한다.
6. 최종 후보와 범위·산출물·일정을 다시 맞춘 뒤 계약 조건을 확정한다.

3번의 질의응답 기한도 자주 생략되는데, 업체가 RFP를 읽다 생긴 질문을 정해진 기간에 모아 받고 그 답을 모든 후보에게 똑같이 공유하면, 한 업체만 추가 정보를 얻어 유리해지는 일을 막을 수 있다. 순서에서 가장 많이 놓치는 대목은 4번과 5번이다. 제안서를 받으면 총액부터 보게 되는데, 총액이 아니라 "그 총액이 무엇을 포함하는지"를 봐야 한다. 견적 항목을 같은 기준으로 뜯어보는 방법은 홈페이지 개발 외주 견적 비교에 항목별로 정리해 두었다.

제안요청서 없이 견적을 받으면 생기는 일

RFP 없이 "홈페이지 하나 얼마예요?"로 시작하면, 견적은 받지만 비교가 안 된다. 가상 예시로 보자. 한 소상공인이 예약 기능이 있는 홈페이지를 전화로만 세 곳에 문의했다. A는 90만 원, B는 260만 원, C는 500만 원을 불렀다. 알고 보니 A는 예약을 외부 링크로 연결하는 5페이지, B는 자체 예약 달력과 문자 알림, C는 회원·결제·관리자까지 붙인 시스템을 가정했다. 세 견적은 애초에 비교 대상이 아니었다. (가상 예시다.)

노바랩 공개 기준으로도 소개형 홈페이지는 150만 원대부터, 게시판·문의·예약 같은 기능이 붙는 표준형은 350만 원대부터, 쇼핑몰·예약 시스템은 400만 원대부터로 시작가 자체가 구간이 다르다. RFP에 범위를 어떻게 적느냐에 따라 같은 "홈페이지"라는 말이 이 구간 어디든 될 수 있다. 그래서 발주자가 먼저 범위를 좁히지 않으면, 업체가 상상한 범위만큼 견적이 벌어진다.

자주 하는 오해 세 가지를 짚는다. 첫째, "RFP는 큰 회사나 쓰는 것"이라는 오해 — 오히려 예산이 빠듯한 소규모일수록 재작업 여력이 없어 RFP가 더 필요하다. 둘째, "예산을 밝히면 그 금액에 맞춰 부른다"는 오해 — 오히려 예산을 아예 숨기면 업체마다 제각각 범위로 견적을 짜서 비교가 깨진다. 상한과 하한만 열어 두고 항목별로 단가를 뽑아 달라고 하면, 예산도 지키고 견적끼리 나란히 비교하는 것도 살릴 수 있다. 셋째, "RFP를 쓰면 유연성이 사라진다"는 오해 — RFP는 계약서가 아니라 요청서라, 제안을 받아 보고 범위를 조정하는 여지는 그대로 남는다.

제안요청서 작성 전 최종 점검

다 썼다면 보내기 전에 아래를 확인한다. 이 점검만 통과해도 견적 편차와 계약 후 분쟁이 크게 준다.

1. 배경·목적을 읽고 업체가 "무엇을 이루려는 사이트인지" 한 문장으로 되말할 수 있는가.
2. 범위에 "포함"뿐 아니라 "제외" 목록이 있는가 — 안 만들 것을 적어야 경계가 선다.
3. 산출물에 소스코드·디자인 원본·계정 권한이 명시돼 있는가.
4. 예산이 범위 또는 상한으로 열려 있는가.
5. 평가 기준에 가격 외의 항목(포트폴리오·유지보수·일정 준수)이 들어 있는가.

업체와 첫 미팅에서 이 문장을 그대로 물어보면 좋다. "저희 RFP를 읽고, 저희가 미처 안 적었지만 꼭 필요하다고 보시는 항목이 있으면 알려 주시겠어요?" 좋은 업체는 이 질문에 발주자가 놓친 범위를 짚어 준다. 발주 준비물 전반은 외주 발주 전 준비물 체크리스트에 정리해 두었으니 RFP를 쓰기 전에 함께 보면 된다.

상황에 맞춰 이렇게 정하면 된다. 요구가 명확하고 규모가 있으면 RFP와 요구사항정의서를 함께 갖춰 3~4곳에 돌린다. 아이디어 단계라 범위가 흐릿하면, RFP에 목적·예산·필수 조건만 적어 두 곳쯤에 보내 제안을 받아 보며 범위를 좁힌다. 처음 외주를 맡기는 경우라면 완벽한 RFP를 쓰려고 미루기보다, 경량 RFP라도 먼저 돌려 제안서를 받아 보는 편이 배우는 게 많다. 제안서에 담긴 업체들의 질문과 범위 제안이 다음 RFP를 훨씬 정확하게 만들어 준다. 어느 쪽이든 문서 없이 전화로만 견적을 받는 것보다는 낫다. 발주 방향이 정리되면 노바랩에 상담을 남겨 범위를 함께 맞춰 봐도 좋다.