RFP 요구사항 상세화와 제안서 평가 기준 정하기
요구사항이 흐릿하면 견적도 분쟁도 흔들립니다
외주 개발 발주에서 가장 먼저 흔들리는 지점은 코드가 아니라 요구사항입니다. 제안요청서(RFP)에 무엇을 만들지가 흐릿하면, 받은 제안서끼리 비교가 되지 않고 견적의 근거도 제각각이 됩니다. 결국 착수 이후에 "이건 범위 안이다, 밖이다"를 두고 다투게 됩니다.
이 문제는 데이터로도 드러납니다. 미국 프로젝트관리협회(PMI)는 목표를 달성하지 못한 프로젝트의 약 47%에서 부정확한 요구사항 관리가 원인으로 지목되었다고 보고했습니다(PMI, Requirements Management, 2014). 또한 지난 12개월간 완료된 프로젝트의 52%가 범위의 통제되지 않은 변경, 즉 스코프 크리프를 겪었고 이는 5년 전의 43%보다 오른 수치입니다(PMI, Pulse of the Profession, 2018). 발주 문서 단계에서 요구사항을 정리해 두는 일이 비용과 분쟁을 줄이는 출발점인 이유입니다.
RFP에 담을 요구사항 체크리스트
기능 목록과 우선순위
기능은 "회원 관리"처럼 뭉뚱그리지 말고, 수행 주체와 동작, 조건이 드러나게 쪼개 적습니다. 예를 들어 "운영자는 가입 승인 대기 목록을 조회하고 일괄 승인할 수 있다"처럼 씁니다. 그다음 각 기능에 우선순위를 붙입니다. 자주 쓰는 방식은 필수, 권장, 선택으로 나누거나 MoSCoW(Must, Should, Could, Won't)로 구분하는 것입니다. 우선순위가 있으면 예산이 빠듯할 때 무엇을 먼저 만들지 합의가 쉽고, 제안사도 1차 범위와 추후 범위를 나눠 견적할 수 있습니다.
비기능 요구사항
화면에 보이지 않지만 비용을 크게 가르는 항목입니다. 다음을 수치가 아니더라도 조건으로 명시하세요.
- 성능: 동시 접속 규모, 응답 지연 허용 범위, 대용량 처리 여부
- 보안: 개인정보 처리 여부, 권한 체계, 로그 보관, 관련 법령 준수 범위
- 호환성: 지원 브라우저, 모바일 대응, 기존 시스템 및 외부 API 연동
- 운영: 배포 환경, 모니터링, 장애 대응과 유지보수 범위
산출물 정의
납품받을 결과물의 형태를 미리 적어 두면 완료 기준을 두고 다툴 일이 줄어듭니다. 소스 코드와 저장소 이관, 화면 설계서와 API 명세, 데이터베이스 구조, 배포 및 운영 문서, 테스트 결과, 하자보수 기간과 범위를 목록으로 요구하세요. 특히 소스 코드 소유권과 이관 방식은 계약 분쟁이 잦은 지점이므로 RFP에서 먼저 짚는 편이 안전합니다.
비교 가능한 제안을 받는 평가 기준
평가 기준을 RFP에 미리 공개하면 제안사가 그 기준에 맞춰 제안서를 구성하므로, 받은 문서들을 같은 잣대로 비교할 수 있습니다. 보통 아래 항목에 가중치를 둡니다.
- 요구사항 이해도: 우리 기능 목록을 제대로 해석했는지, 빠진 범위나 추가 제안이 있는지
- 수행 방법과 일정: 단계별 계획, 산출물 시점, 소통 방식
- 수행 이력: 유사 도메인 경험과 투입 인력 구성
- 견적의 근거: 금액이 어떤 산정 방식에서 나왔는지
견적을 볼 때는 산정 근거를 확인하세요. 국내 공공 및 상당수 민간 사업은 기능점수(FP) 방식으로 개발비를 산정하는 기준을 참고합니다. 한국소프트웨어산업협회(KOSA)의 SW사업 대가산정 가이드는 2025년 개정에서 개발과 운영을 함께 묶은 사업의 경우 개발비는 기능점수로, 운영 및 유지관리비는 투입공수로 산정한 뒤 합산하는 기준을 추가했습니다(KOSA, SW사업 대가산정 가이드 2025년 개정판). 제안사마다 산정 방식이 다르면 총액만 비교하기 어려우니, RFP에서 산정 근거를 함께 제출하도록 요청하는 편이 좋습니다.
마무리
RFP는 완벽하게 쓰는 문서가 아니라, 제안사가 같은 조건에서 같은 범위를 견적하도록 돕는 문서입니다. 기능을 동작 단위로 쪼개고 우선순위를 붙이며, 비기능 요구와 산출물, 평가 기준을 함께 적어 두면 비교 가능한 제안과 근거 있는 견적을 받을 수 있습니다. 요구사항 정의부터 함께 다듬어 발주를 준비하고 싶다면 SI 및 업무 시스템 개발 서비스에서 상담 과정을 참고하실 수 있습니다.