RFP 작성: 요구사항을 제안과 계약의 기준으로 만드는 법

제안요청서는 사업의 기준을 먼저 정하는 문서다

정보시스템 구축이나 소프트웨어 개발 사업에서 발주자는 잠재 공급업체에 공식 제안을 요청한다. 이때 사업 목적, 범위, 예산, 기술 제약, 평가 방식을 체계적으로 담은 문서가 RFP(Request for Proposal), 즉 제안요청서다.

공급업체는 RFP를 기준으로 기술 제안서와 가격 제안서를 작성하고, 발주자는 제출물을 비교·평가해 수행 업체를 선정한다. 요구사항이 불명확한 상태로 시작하면 범위가 커지거나 비용이 늘어날 수 있다. RFP는 발주자와 수주자 사이의 기술적·행정적 합의를 문서화해 이런 불확실성을 줄이는 역할을 한다.

RFI로 시장을 확인하고 RFP를 구체화한다

RFP를 내기 전에 정보요청서(RFI, Request for Information)를 활용하는 경우가 있다. RFI의 목적은 공급업체의 일반 현황과 기술 보유 상태를 파악하는 데 있다.

발주자는 RFI를 통해 전문업체의 수행 역량과 제안 요구사항의 실현 가능성을 미리 검토할 수 있다. 여기서 수집한 기술 동향과 업계 역량 정보는 이후 RFP의 요구사항을 구체적이고 현실적인 수준으로 다듬는 근거가 된다.

⤢✕

RFP에 담아야 할 사업 정보

RFP의 세부 구성은 사업 성격에 따라 달라진다. 다만 공공기관이나 대규모 기업 프로젝트에서는 사업의 맥락, 요구사항, 제안 방식, 입찰 절차를 빠짐없이 연결하는 구성이 필요하다.

사업의 배경과 범위

사업명, 추진 배경, 목적, 기간, 예산 규모를 제시한다. 공급업체가 프로젝트의 전체 맥락을 파악할 수 있도록 하는 부분이다.

현재 운영 중인 시스템 상태나 비즈니스 프로세스의 한계도 함께 기술한다. 새 사업으로 해소하려는 통점(Pain Point)을 분명히 해야 제안의 방향이 사업 목적과 어긋나지 않는다.

추진 방식과 목표 구조

추진 체계, 추진 일정, 목표 시스템 구성도를 제시해 사업을 어떤 방향으로 이끌지 설명한다. 이는 수행 과정의 기준점이 된다.

RFP의 중심에는 기술 요구사항, 성능 요구사항, 인터페이스 요구사항, 보안 요구사항이 놓인다. 이 요구사항은 가능한 한 구체적으로 정의해야 한다.

제안서와 입찰의 운영 기준

제안서 목차, 분량 제한, 제출 방법을 안내한다. 모든 업체가 같은 형식으로 제안서를 제출하도록 해 평가의 공정성을 확보하기 위한 기준이다.

입찰 참가 자격, 평가 방법, 배점 기준, 협상 절차도 명시한다. 입찰 참여 업체가 준비 과정에서 숙지해야 할 행정적 절차다.

요구사항은 측정 가능한 조건으로 적는다

성능 요구사항을 “성능이 좋아야 한다”처럼 표현하면 제안 단계와 수행 단계 모두에서 해석이 갈릴 수 있다. 예를 들어 “동시 접속자 1000명 시 응답 시간 3초 이내”처럼 측정 가능한 조건으로 쓰면 공급업체와 발주자가 같은 기준을 공유할 수 있다.

변경 관리와 리스크 대응 방안도 RFP 단계에서 가이드를 제시할 필요가 있다. 이후 발생할 수 있는 분쟁을 예방하고, 프로젝트 수행 중 유연한 의사결정을 지원하는 기준이 된다.

요구 현황 분석에는 전문 컨설팅을 활용할 수 있으며, 업계 표준 기술을 반영하는 방법도 있다. 특정 업체의 기술에 과도하게 치우치지 않으면서 발주자의 비즈니스 목표를 달성할 요구사항을 도출해야 한다.

명확한 RFP는 사업 범위를 드러내고 수행 업체를 선정할 기준을 제공한다. RFI로 시장의 역량을 파악한 뒤 이를 RFP에 반영하면 사업의 실현 가능성과 성공률을 높일 수 있다.

Sources

소프트웨어 진흥법 및 제안요청서 작성 가이드라인 (과학기술정보통신부)
정보시스템 구축·운영 지침 (행정안전부)
IT 프로젝트 관리 전문가 가이드 (PMBOK 기반 소프트웨어 공학 체계)
공공 소프트웨어 사업 제안요청서 표준 목차 및 작성 요령 실무 가이드