제안요청서(RFP)와 제안서 작성의 기본

프로젝트는 계약에서 시작되는 경우가 많습니다. 발주하는 쪽은 제안요청서(RFP, Request for Proposal)로 무엇이 필요한지 알리고, 수행하는 쪽은 제안서로 어떻게 해낼지 답합니다. 이 두 문서가 잘 쓰이면 뒤의 프로젝트가 순조롭고, 모호하면 계약 뒤에 다툼이 생깁니다. 두 문서의 기본을 정리합니다.

발주하는 쪽: 제안요청서에 담을 것

제안요청서는 공급자가 같은 조건에서 비교 가능한 제안을 내도록 돕는 문서입니다. 보통 다음을 담습니다.

배경과 목적: 왜 이 사업을 하는지, 무엇을 얻고 싶은지
범위와 요구사항: 해야 할 일과 결과물, 기능과 성능 요구
일정과 장소: 언제까지, 어디서
제출 형식: 목차, 분량, 제출 방법과 마감
평가 기준: 기술과 가격을 어떤 비중으로 평가하는지
계약 조건: 대금 지급, 검수, 하자 보수 같은 조건

평가 기준을 미리 밝혀 두면 공급자가 무엇에 힘을 줘야 할지 알 수 있고, 선정 결과에 대한 이의도 줄일 수 있습니다.

수행하는 쪽: 제안서는 질문에 대한 답이다

제안서는 회사 소개서가 아닙니다. 발주자가 제안요청서에서 물은 것에 하나하나 답하는 문서입니다. 좋은 제안서는 다음 흐름을 따릅니다.

요구 이해: 발주자의 목적과 요구를 우리 말로 다시 정리해, 정확히 이해했음을 보여 줍니다.
해결 방안: 요구마다 어떻게 해결할지 구체적으로 제시합니다.
수행 계획: 일정, 조직, 투입 인력, 리스크와 대응을 보여 줍니다.
근거: 비슷한 일을 해 본 경험, 인력의 자격을 제시합니다.
가격: 제안요청서가 요구한 형식으로 명확하게 제시합니다.

요구사항 대비표를 만든다

제안서를 쓰기 전에 제안요청서의 요구사항을 하나씩 뽑아 표로 만들고, 제안서의 어느 쪽에서 답하는지 이어 두세요. 이렇게 하면 빠뜨린 요구가 없는지 확인할 수 있고, 평가자도 답을 쉽게 찾습니다. 제안요청서에 질의응답 기간이 있다면 모호한 요구를 이때 꼭 물어보세요. 다른 공급자의 질문과 답도 공개되기도 해, 발주자의 관심사를 읽는 단서가 됩니다. 평가자는 짧은 시간에 여러 제안서를 읽기 때문에, 찾기 쉬운 제안서가 좋은 인상을 줍니다.

제안 전략을 세운다

같은 요구에 여러 회사가 답하므로, 우리가 왜 더 나은지 분명해야 합니다.

핵심 메시지: 발주자가 가장 걱정하는 것에 대한 우리만의 해법을 한두 문장으로 정합니다.
강점과 약점: 경쟁사와 비교해 우리의 강점은 앞세우고, 약점은 대응책으로 보완합니다.
지킬 수 있는 약속만: 수주를 위해 무리한 일정이나 범위를 약속하면 그 부담은 프로젝트팀이 집니다. 제안서는 계약 문서의 일부가 되는 경우가 있어, 그 약속이 그대로 의무가 될 수 있습니다.

정리

제안요청서는 공급자가 비교 가능한 제안을 내도록 목적, 범위, 평가 기준을 밝히는 문서이고, 제안서는 그 질문에 하나하나 답하는 문서입니다. 요구사항 대비표로 빠짐없이 답하고, 핵심 메시지로 차별점을 보여 주되 지킬 수 있는 것만 약속하세요.

참고(확인 2026-10-03)

PMI, A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 6판, 2017 (조달 관리, 입찰 문서와 공급자 선정 기준. 조달 프로세스는 6판 기준)