견적 요청서 양식과 작성법: 같은 조건으로 개발 외주 견적 받기

2026.10.227분

이 글은 「처음 맡기는 개발 외주, 발주 문서 준비」 시리즈의 마지막 3편입니다. 1편 요구사항 정의서 작성법과 2편 화면설계서 작성법, 메뉴구조도와 와이어프레임에서 만든 두 문서를 붙여 견적을 요청하는 단계이니, 앞 편을 먼저 보시면 이해가 쉽습니다.

견적 요청서가 없으면 견적이 비교되지 않는 이유

견적 요청서는 "이 조건으로 견적을 내 주세요"라고 업체에 보내는 안내문입니다. 1편의 요구사항 정의서와 2편의 화면설계서를 붙여서 언제까지, 어떤 형식으로, 무엇을 포함해 답해 달라고 정하는 문서입니다. 두 쪽이면 됩니다.

이 문서 없이 전화나 메일로 "필라테스 예약 앱 견적 좀 주세요"라고 하면, 업체마다 다른 앱을 그리고 견적을 냅니다. 한 곳은 관리자 페이지를 넣고, 한 곳은 디자인을 빼고, 한 곳은 서버 비용을 별도로 둡니다. 돌아온 금액이 제각각이면 발주자가 볼 수 있는 것은 숫자뿐입니다. 같은 문서를 같은 날 보내고 같은 항목으로 답을 받아야 비교가 시작됩니다.

한 곳만 받으면 비싼지 싼지 알 수 없고, 너무 많이 받으면 질문에 답하고 미팅하는 시간을 감당하지 못합니다. 두세 곳에 보내고 각 업체의 질문에 제대로 답하는 편이 낫습니다.

공공 입찰 제안요청서와 다른 점

'제안요청서' 또는 'RFP'로 검색하면 나라장터에 올라오는 공공기관 문서가 많이 나옵니다. 입찰 공고에 붙는 서류라 길고, 양식도 기관마다 정해져 있습니다. 이 글의 견적 요청서는 민간 사업자가 업체 몇 곳에 보내는 안내문이라 그 형식을 따를 필요가 없습니다. 실무자가 요구사항을 더 세밀하게 적고 평가 기준을 세우는 방법은 RFP 요구사항 상세화와 제안서 평가 기준 정하기에 따로 있습니다.

양식 구성: 다섯 부분을 채우면 됩니다

퍼스트핍이 만든 양식은 워드와 한글 두 형식이고 내용은 같습니다. 요청 정보, 프로젝트 요약, 첨부 문서, 견적서에 넣어 달라고 요청할 항목, 진행 방식 다섯 부분으로 두 쪽 안에 들어갑니다.

1. 요청 정보

회사 상호, 담당자 이름과 연락처, 요청일, 회신 희망일, 회신 방법을 적습니다. 회신 희망일은 마감이 아니라 "이때쯤 받아서 함께 비교하고 싶다"는 날짜입니다. 날짜가 없으면 견적이 제각각 다른 때에 오고, 너무 촉박하면 업체가 질문할 틈 없이 짐작으로 견적을 냅니다. 회신 방법을 이메일로 정하면 견적서와 질문이 한 곳에 모입니다.

2. 프로젝트 요약

서비스 이름, 한 줄 설명, 플랫폼(웹, iOS, Android, 관리자 페이지), 희망 착수일과 오픈일, 예산 범위를 적습니다. 예산을 공개하면 업체가 그 범위 안에서 가능한 구성을 제안하고, 비공개로 두면 업체가 생각하는 적정 금액을 먼저 볼 수 있습니다.

3. 첨부 문서 체크

요구사항 정의서(1편 엑셀 양식), 화면설계서(2편 파워포인트 양식), 참고 자료 세 칸에 첨부 여부를 표시합니다. 모든 업체가 같은 첨부를 받았다는 사실이 여기에 남고, 나중에 "그 기능은 못 들었다"는 말이 나올 때 돌아갈 자리가 됩니다. 화면설계서가 아직 없으면 없다고 표시하고 보내도 됩니다.

4. 견적서에 꼭 넣어 달라고 요청할 항목

체크 목록이며, 전부 표시해 보내기를 권합니다.

단계·기능별 금액: 총액 하나로 오면 어느 기능이 비싼지 알 수 없습니다.
전체 기간과 단계별 일정: 발주자 쪽 준비(콘텐츠, 회원 데이터, 결제 가입)를 맞추는 데 필요합니다.
디자인 포함 여부: 빠져 있으면 나중에 디자인 비용이 따로 붙습니다.
서버·도메인·외부 서비스 비용: 개발비와 별도인지, 매달 얼마나 드는지, 누구 명의로 가입하는지입니다.
무상 하자보수 기간과 범위: 어디까지가 하자이고 어디부터가 추가 개발인지입니다.
유지보수 조건: 무상 기간이 끝난 뒤 월 비용이나 건당 비용이 있는지입니다.
소스코드·산출물 인계 범위: 소스코드, 디자인 원본, 서버 접속 정보를 어디까지 넘겨주는지입니다.
견적에서 제외한 항목: 업체가 "이건 안 넣었다"고 적는 칸입니다.
기능 목록에 대한 질문·제안: 요구사항 정의서를 읽고 생긴 질문과 다른 방식 제안입니다.

항목이 같아야 어느 업체의 어느 칸이 비었는지가 바로 보입니다. 받은 견적서를 읽는 방법은 개발 외주 견적서의 단가·범위·추가 비용 확인에서, 고정가와 투입공수 중 어느 방식으로 계약할지는 개발 외주 계약, 고정가와 투입공수 방식 비교에서 다뤘습니다.

5. 진행 방식

미팅 가능 여부, 질문을 받는 창구, 업체 선정 일정을 적습니다. 선정 일정을 적어 두면 업체는 인력 배정을 미리 잡고, 발주자는 결정을 미루지 않게 됩니다.

받은 견적을 비교하는 법: 금액은 마지막에 봅니다

먼저 볼 것은 제외 항목입니다. 어느 업체가 무엇을 뺐는지 적어 보면 금액 차이의 이유가 대부분 거기서 나옵니다. 그다음이 범위입니다. 가나다 필라테스 예시라면 회원권 차감과 복구, 강사 화면, 관리자 웹이 들어갔는지를 기능 목록 번호대로 맞춰 봅니다. 그 뒤에 하자보수와 인계 범위를 보고, 마지막에 금액을 봅니다.

견적서와 함께 오는 회신도 비교 대상입니다.

질문을 한다: 질문 없이 견적만 온 곳은 문서를 읽지 않았거나 자기 방식대로 가정했을 가능성이 있습니다.
미정 사항에 답한다: 1편의 미정·질문 칸에 답을 달아 보내는 곳은 개발 중에도 그렇게 설명해 줄 업체입니다.
제외 항목을 먼저 말한다: 안 넣은 것을 미리 적어 보낸 업체가 나중에 추가 비용 얘기를 덜 꺼냅니다.
다른 방식을 제안한다: "대기 신청 기능은 첫 오픈에서 빼고 운영해 보신 뒤 넣어도 된다"처럼 줄여 주는 제안은 신호가 좋습니다. 적지 않은 기능을 계속 더하는 제안은 조심해서 보세요.
약속한 날을 지킨다: 회신 희망일을 넘기면서 미리 연락도 없는 곳은 개발 일정도 비슷하게 흘러갈 가능성이 큽니다.

양식 다운로드와 시리즈 정리

개발 견적 요청서 양식 (워드, 39KB)

개발 견적 요청서 양식 (한글, 11KB)

세 편의 문서는 순서가 있습니다. 1편 요구사항 정의서(엑셀)에서 무엇을 만들지 적고, 2편 화면설계서(파워포인트)에서 그것이 어떤 화면으로 보일지 그리고, 3편 견적 요청서(워드·한글)로 두 문서를 붙여 같은 조건으로 견적을 받습니다. 외주 결과는 업체의 실력만큼 업체와 얼마나 같은 그림을 보고 있는지에 달려 있고, 이 문서들이 그 그림을 맞추는 도구입니다.

이 글은 「처음 맡기는 개발 외주, 발주 문서 준비」 시리즈 3편 중 3편입니다.

1편: 요구사항 정의서 작성법
2편: 화면설계서 작성법, 메뉴구조도와 와이어프레임
3편: 견적 요청서 양식과 작성법 (지금 보는 글)