좋은 소프트웨어 개발 제안요청서(RFP)는 업체마다 다른 형식의 제안서를 같은 기준으로 비교할 수 있게 해야 합니다. 중간 규모의 업무 시스템이라면 본문을 8~12페이지로 제한하고, 필수 범위·검수 기준·예산 구간·인수인계 산출물을 명확히 적는 것이 실무적입니다. 발표를 보기 전에 100점 평가표로 1차 채점하면 영업 역량과 실제 수행 역량을 구분하기 쉬워집니다.
RFP에서 먼저 결정해야 할 4가지
RFP는 상세 설계서가 아닙니다. 발주 범위를 정하고 위험을 드러내며 업체를 공정하게 비교하기 위한 문서입니다. 다음 네 가지가 선명해야 합니다: 해결할 사업 문제, 변경할 수 없는 제약, 완료를 인정할 검수 기준, 업체가 제출해야 할 증빙입니다.
| 항목 | 발주사가 얻는 답 | 권장 분량 |
|---|---|---|
| 사업 배경과 목표 | 업체가 진짜 문제를 이해했는가 | 1페이지 |
| 사용자와 핵심 업무 흐름 | 중요한 사용 시나리오가 범위에 포함되는가 | 1~2페이지 |
| 기능 범위 | 필수·선택·제외 항목이 무엇인가 | 2~3페이지 |
| 기술·보안 제약 | 기존 환경에서 안전하게 운영 가능한가 | 1~2페이지 |
| 일정과 검수 | 진척과 완료를 어떻게 확인하는가 | 1~2페이지 |
| 견적 양식 | 총비용을 같은 조건으로 비교할 수 있는가 | 1페이지 |
| 수행 증빙 | 제안 내용이 실제 인력과 경험으로 뒷받침되는가 | 1페이지 |
바로 사용할 수 있는 RFP 목차
1. 기능보다 사업 성과를 먼저 적습니다
“최신 운영 대시보드 구축”보다 “출고 정산 소요 시간을 2일에서 4시간으로 단축하고 오픈 3개월 내 월 마감 오류를 50% 줄인다”가 좋은 목표입니다. 현재 수치, 목표 수치, 목표 시점, 최종 승인자를 함께 적으십시오. 목표 수치가 아직 없다면 계약 전에 측정하는 진단 단계를 범위에 포함합니다.
2. 사용자와 실패하면 안 되는 업무 흐름을 정의합니다
사용자 그룹, 예상 인원과 트래픽, 권한, 핵심 업무 흐름 3~5개를 정리합니다. 각 흐름에는 시작 조건, 주요 단계, 완료 결과, 예외 상황을 포함합니다. 기존 화면과 프로세스가 있다면 개인정보를 제거한 자료를 첨부하되, 현재의 비효율까지 그대로 구현하도록 요구하지는 마십시오.
3. 필수·선택·제외·사전 검증 항목을 나눕니다
| 구분 | 의미 | 업체 답변 방식 |
|---|---|---|
| 필수 | 1차 운영 배포에 반드시 필요 | 기본 견적과 일정에 포함 |
| 선택 | 예산과 일정이 허용하면 진행 | 의존성과 함께 별도 견적 |
| 제외 | 이번 계약 범위 밖 | 견적과 전제에서 제외 |
| 사전 검증 | 데이터·연동·업무 확인 후 결정 | 유상 디스커버리와 의사결정 시점 제안 |
이 구분이 없으면 낮은 초기 견적 뒤에 필수 기능이 변경 요청으로 돌아올 수 있습니다. 모든 전제 조건과 제외 사항은 한 개 표로 제출하도록 요구하는 편이 좋습니다.
4. 연동, 데이터, 보안, 소유권을 적습니다
연동 대상 시스템, 사용 가능한 API나 파일 방식, 데이터 책임자, 호출 제한을 명시합니다. 클라우드 리전, 로그인 체계, 백업 복구 목표, 감사 로그 보관 기간, 개인정보 처리 조건도 포함합니다. 소스코드, 인프라 설정, DB 스키마, 배포 스크립트, 디자인 원본, 테스트 자산, 운영 문서는 발주사 소유 저장소와 계정에 납품하도록 요구합니다.
5. 검수 기준을 세 단계로 만듭니다
“정상 동작”처럼 해석이 갈리는 표현은 피하십시오. 기능 검수, 릴리스 검수, 운영 준비 검수로 나누면 누락을 줄일 수 있습니다.
| 검수 단계 | 증빙 예시 | 승인 담당 |
|---|---|---|
| 기능 | 테스트 시나리오, 시연 결과, 결함 현황 | 제품 책임자 |
| 릴리스 | 회귀 테스트, 부하 테스트, 보안 점검 | 업무·기술 책임자 |
| 운영 준비 | 운영 문서, 모니터링, 복구·롤백 기록 | 운영 책임자 |
모든 업체에 같은 견적 양식을 요구합니다
기본 구축비, 선택 항목, 전제 조건, 외부 라이선스, 클라우드 예상비, 월 운영비, 하자보수, 유지보수, 종료·이관 비용을 같은 표로 받으십시오. 요구사항이 불확실한 프로젝트에서 근거 없는 확정가를 받기보다 2~4주의 유상 디스커버리 후 상세 견적을 다시 받는 편이 예산 오차를 줄이는 경우가 많습니다.
| 계약 방식 | 적합한 상황 | 발주사 주요 위험 |
|---|---|---|
| 고정가 | 범위와 검수 기준이 안정적 | 잦은 변경 비용 또는 숨은 예비비 |
| 투입공수 | 우선순위가 계속 바뀌는 제품 | 성과 지표가 없으면 예산 통제가 약함 |
| 전담팀 | 발주사 제품 책임자가 지속 로드맵을 운영 | 활용하지 못한 인력 용량에도 비용 발생 |
| 디스커버리 후 개발 | 업무·데이터·연동 불확실성이 큼 | 진단 산출물이 개발 결정에 부족할 수 있음 |
100점 업체 평가표
제안 발표 전에 문서만으로 1차 채점을 완료하십시오. 이후 업체가 새로운 증빙을 제출할 때만 점수를 수정합니다. 두 명 이상이 독립적으로 평가하고 10점 이상 차이가 나는 항목은 근거를 다시 확인합니다.
| 평가 항목 | 배점 | 요청할 증빙 |
|---|---|---|
| 문제 이해와 범위 정의 | 20 | 전제·제외 사항, 위험 질문, 사전 검증안 |
| 수행 방식과 관리 체계 | 20 | 마일스톤, 데모 주기, 이슈 보고, 변경 관리 |
| 기술·보안 적합성 | 20 | 구조 개요, 보안 통제, 배포·롤백 방식 |
| 실제 투입 인력과 유사 경험 | 15 | 이력, 투입률, 시작 가능일, 유사 수행 증빙 |
| 품질과 인수인계 | 10 | 테스트 전략, 문서 목록, 소유권 이전 계획 |
| 총소유비용 | 10 | 구축·라이선스·클라우드·운영·종료 비용 |
| 커뮤니케이션 | 5 | 한국어 창구, 겹치는 근무시간, 주간 보고서 예시 |
4주 업체 선정 일정 예시
- 1~3일: 목표, 범위 구분, 제약, 평가표 확정
- 4~10일: RFP 배포와 공통 질의응답 운영
- 11~15일: 제안서 접수와 독립 채점
- 16~20일: 동일 질문 인터뷰와 기술 워크숍
- 21~25일: 레퍼런스 확인, 견적 정리, 계약 부속서 협상
- 26~30일: 업체 선정과 디스커버리 또는 개발 착수 승인
중간 규모 업무 시스템은 4주가 실무적인 기준입니다. 규제 산업이나 연동이 많은 시스템은 6~8주가 필요할 수 있습니다. 희망 착수일을 맞추기 위해 보안 검토, 레퍼런스 확인, 지식재산권과 인수인계 조항을 생략하지 마십시오.
국내 발주사가 확인할 커뮤니케이션 구조
해외 개발팀을 활용한다면 단가만 보지 말고 계약 주체와 책임 창구를 분리해 확인해야 합니다. 국내 법인과 계약하는지, 한국어로 요구사항과 장애를 조율할 담당자가 있는지, 베트남 등 실제 개발 조직과 몇 시간 근무가 겹치는지, 의사결정 기록은 어디에 남기는지 요청하십시오. Nextchain은 한국 법인과의 계약 및 한국어 커뮤니케이션 창구를 두고 베트남 개발 조직과 협업하는 구조를 운영합니다. 자세한 상담은 Nextchain 서비스 안내에서 시작할 수 있습니다.
제안서에서 발견되는 위험 신호
- 전제 조건, 제외 사항, 외부 비용 없이 총액 한 줄만 제시합니다.
- 데이터, 연동, 검수 질문을 하기 전에 납기부터 확정합니다.
- 영업 미팅에는 고경력자가 참석하지만 실제 투입 인력은 공개하지 않습니다.
- 운영 계정, 소스 저장소, 클라우드 결제를 개발사가 계속 소유해야 한다고 합니다.
- 테스트, 배포, 문서, 하자보수, 인수인계를 선택 항목으로 둡니다.
- RFP 내용을 반복할 뿐 위험한 전제에 질문을 제기하지 않습니다.
선정 전 계약과 인수인계 점검
우선협상 업체의 제안서를 그대로 계약서에 첨부하지 말고 계약 부속서로 변환하십시오. 범위, 일정, 견적표, 검수 절차, 핵심 인력, 보안, 지식재산권 이전, 하자보수, 종료 시 산출물이 계약상 의무가 되어야 합니다. 서명 전에는 소프트웨어 개발 외주 계약서 20개 조항 체크리스트와 함께 검토할 수 있습니다.
자주 묻는 질문
RFP는 얼마나 상세해야 하나요?
업체들이 같은 결과를 기준으로 견적을 낼 수 있을 만큼 상세하되 구현 방법까지 고정하지 않는 것이 좋습니다. 중간 규모 업무 시스템은 본문 8~12페이지와 별도 부록이면 충분한 경우가 많습니다.
예산을 공개해야 하나요?
승인된 예산 구간이 있다면 공개하는 편이 좋습니다. 업체가 예산에 맞는 방식을 제안할 수 있고 비교 불가능한 제안을 줄일 수 있습니다. 구간의 하단과 상단에서 각각 무엇을 제공하는지도 요청하십시오.
제안 기간은 며칠이 적당한가요?
일반 프로젝트는 7~10영업일, 규제 검토나 복잡한 연동이 있는 프로젝트는 그 이상이 필요합니다. 모든 업체가 같은 정보를 받도록 질의응답 문서를 공통으로 운영하십시오.
고정가와 투입공수 중 무엇이 안전한가요?
항상 안전한 방식은 없습니다. 범위와 검수가 안정적이면 고정가, 우선순위가 계속 바뀌면 투입공수가 적합합니다. 어느 방식이든 마일스톤, 전제 조건, 변경 절차가 명확해야 합니다.
소스코드와 클라우드 계정은 누가 소유해야 하나요?
저장소, 도메인, 클라우드 조직, 운영 데이터, 핵심 외부 계정은 발주사가 통제해야 합니다. 계약에는 합의한 대금 지급 시점에 프로젝트 지식재산권이 이전된다는 조항을 포함하십시오.
유지보수와 소통 역량은 어떻게 평가하나요?
하자보수 기간, 장애 등급별 응답시간, 월 지원 범위, 한국어 책임자, 겹치는 근무시간, 회의 주기, 비상 연락망, 주간 보고서 예시를 요청하십시오. 오픈 이후 실제 운영할 사람과 절차를 평가해야 합니다.
