RFP, RFI, RFQ의 목적과 차이, 발주·제안 단계별 작성 항목을 한눈에 정리한 실무 가이드입니다.

RFP·RFI·RFQ를 구분해야 하는 이유

RFP, RFI, RFQ는 모두 외부 공급사와 협업을 시작할 때 쓰지만, 묻는 내용과 쓰는 시점이 다릅니다. 세 문서를 한 장의 제안서처럼 취급하면 시장 조사와 요구사항 정의, 가격 비교가 뒤섞여 의사결정 근거가 약해질 수 있습니다. 반대로 목적을 나누면 발주 조직은 필요한 정보를 순서대로 모으고, 공급사는 무엇을 답해야 하는지 명확히 이해할 수 있습니다.

실무에서는 RFI로 시장과 가능한 방식부터 살핀 뒤, RFP로 과업과 평가 기준을 알리고, RFQ로 같은 조건에서 가격과 납기 조건을 비교하는 흐름이 흔합니다. 다만 모든 프로젝트가 세 문서를 모두 요구하는 것은 아닙니다. 구매 규모, 기술 난이도, 내부 준비 수준에 맞춰 필요한 문서만 선택하되, 각 문서의 질문 범위가 겹치지 않도록 관리하는 것이 핵심입니다.

RFI: 시장과 가능성을 확인하는 사전 정보 요청

RFI는 Request For Information의 약자로, 특정 솔루션이나 공급 역량에 관한 정보를 수집하는 문서입니다. 아직 구매 조건을 확정하지 않았거나 내부에 충분한 기술 지식이 없을 때 특히 유용합니다. 발주자는 해결하려는 업무 문제, 현재 운영 환경, 알고 싶은 기술·운영·지원 항목을 제시하고, 응답 기업은 제공 가능 범위와 사례, 제약 조건을 설명합니다.

좋은 RFI는 정답을 유도하기보다 비교 가능한 정보를 얻도록 설계합니다. 예를 들어 보유 기능, 연동 방식, 데이터 보관 위치, 도입 기간, 고객 지원 체계, 유사 프로젝트 경험을 같은 형식으로 요청할 수 있습니다. 이 단계에서 가격을 확정적으로 요구하기보다는 예산 범위에 영향을 주는 변수와 시장의 일반적인 제공 방식을 파악하는 데 집중하면 이후 RFP의 요구사항이 현실적이 됩니다.

RFP·RFI·RFQ 차이와 제안서 작성 체크리스트 관련 정보 카드

RFP: 과업과 평가 기준을 제시하는 제안 요청서

RFP는 Request For Proposal, 즉 제안 요청서입니다. 발주자가 해결할 과제와 기대 성과를 설명하고, 공급사에게 수행 방법과 운영 계획을 제안해 달라고 요청하는 문서입니다. 단순히 기능 목록만 나열하기보다 사업 배경, 목표, 대상 사용자, 현재 문제, 필수 조건과 선택 조건을 구조화해야 합니다. 공급사가 같은 문제를 이해한 상태에서 서로 다른 실행안을 제시할 수 있어야 비교가 가능합니다.

RFP에는 과업 범위, 산출물, 일정, 역할 분담, 보안·품질 기준, 제안서 제출 형식, 질의응답 일정, 평가 방식이 포함되는 경우가 많습니다. 평가 항목은 기술 적합성, 수행 경험, 운영 역량, 일정 현실성, 비용 등으로 나누고 배점 또는 우선순위를 사전에 알리는 편이 공정합니다. 확정되지 않은 조건은 추정이라고 표시해 공급사가 가정을 명확히 적도록 유도하세요.

RFQ: 동일 조건에서 견적을 비교하는 요청서

RFQ는 Request For Quotation의 약자로, 규격과 수량, 납품 조건이 비교적 명확할 때 가격 제안을 받는 문서입니다. 제품 구매나 표준화된 서비스처럼 비교 기준을 맞출 수 있는 경우에 적합합니다. 공급사가 다른 전제에서 금액을 제시하면 숫자만 비교하기 어렵기 때문에, 품목별 사양, 수량, 단가 표시 방식, 세금 포함 여부, 유지보수 범위, 납기와 결제 조건을 빠짐없이 적어야 합니다.

RFQ의 목적은 최저가만 찾는 데 있지 않습니다. 총소유비용, 보증 조건, 교체·환불 기준, 배송·설치 책임, 계약 기간 중 가격 변동 조건도 함께 봐야 실제 비용을 판단할 수 있습니다. 비교표에는 필수 사양 충족 여부와 예외 조건을 별도 열로 두고, 견적 유효기간과 문의 마감일을 명시하세요. 금액이 큰 계약은 내부 구매·법무 기준과 공개된 입찰 절차도 함께 확인하는 것이 안전합니다.

한눈에 보는 선택 기준과 진행 순서

새로운 기술이나 공급 시장을 잘 모르면 RFI부터 시작합니다. 필요한 결과와 수행 범위는 알지만 해결 방법을 비교하고 싶다면 RFP가 중심 문서가 됩니다. 사양과 수량이 이미 정해져 여러 업체의 조건을 공정하게 비교하려면 RFQ를 사용합니다. 실제 프로젝트에서는 RFI 응답으로 후보와 조건을 정리하고, RFP로 실행안을 평가한 뒤, 우선 협상 대상 또는 적격 업체에게 RFQ를 보내는 방식도 활용됩니다.

문서 순서는 조직의 승인 절차와 예산 확정 시점에 맞춰 조정할 수 있습니다. 중요한 점은 단계가 바뀔 때 결정된 사실과 남은 가정을 기록하는 것입니다. RFI에서 들은 기능을 자동으로 필수 요건으로 옮기지 말고, 사용자·보안·운영 부서의 검토를 거치세요. RFP 평가 결과와 RFQ 비교 결과도 같은 의사결정 기록에 연결하면 담당자가 바뀌어도 선정 근거를 추적하기 쉽습니다.

RFP·RFI·RFQ 차이와 제안서 작성 체크리스트 확인 정보 카드

작성 전 준비: 요구사항을 질문으로 바꾸기

문서를 쓰기 전에는 해결하려는 문제를 한 문장으로 정리하고, 성공을 판단할 지표를 합의하세요. 그다음 현재 상태, 제약 조건, 이해관계자, 반드시 지켜야 할 일정과 예산 범위를 목록화합니다. 요구사항은 기능·성능·보안·운영·교육·전환처럼 분류하고, 각 항목을 필수·우대·검토로 나누면 응답의 우선순위가 선명해집니다. 모호한 표현 대신 측정 방법이나 확인 자료를 요청하는 질문을 사용하세요.

예를 들어 안정적 지원이 필요하다는 문장만 두기보다 지원 시간, 장애 접수 채널, 응답 목표, 정기 점검 범위를 답하도록 요청할 수 있습니다. 개인정보나 중요 정보가 관련되면 적용 법령의 개별 해석을 요구하기보다 보안 담당 부서가 확인할 통제 항목과 증빙 자료를 명시하는 편이 좋습니다. 요구사항 원본과 변경 이력을 관리하고, 공개 전에는 현업·구매·보안·재무 담당자의 검토 책임을 정해 두세요.

응답을 공정하게 비교하는 평가표 만들기

응답 양식을 통일하면 제안서의 문장력보다 실제 적합성을 비교하기 쉬워집니다. 회사 정보, 유사 경험, 제안 범위, 일정, 투입 인력, 위험 관리, 비용, 계약 조건을 같은 목차로 받도록 안내하세요. 평가표는 필수 요건 충족 여부를 먼저 확인하고, 그다음 가중치가 있는 정성 평가와 비용·일정 같은 정량 평가를 분리하는 방식이 이해하기 쉽습니다. 탈락 사유와 보완 요청 기준도 미리 정하면 절차의 신뢰도가 높아집니다.

평가위원은 이해관계 충돌 여부를 사전에 확인하고, 질문과 답변은 가능한 한 모든 참여사에 같은 기준으로 공유합니다. 제안 발표가 있다면 시간, 시연 범위, 질의 방식, 추가 자료 허용 범위를 통일하세요. 점수만으로 결론을 내리기 어려운 경우에는 핵심 위험, 전제 조건, 협상 필요 항목을 별도 기록합니다. 최종 선정 뒤에도 평가표와 주요 의사결정 근거를 보관하면 계약 이행과 다음 조달의 품질 개선에 도움이 됩니다.

제출 전 체크리스트와 공식 확인 경로

발주자라면 제목과 문서 목적, 제출 마감, 문의 창구, 비밀유지 조건, 평가 일정이 서로 일치하는지 점검하세요. RFP에는 범위와 산출물, RFQ에는 비교 가능한 사양과 비용 조건, RFI에는 탐색하려는 정보 범위가 분명히 드러나야 합니다. 응답자라면 요구사항별 답변 위치, 미충족 항목, 가정 조건, 견적의 포함·제외 범위를 숨기지 말고 명시해야 합니다. 불명확한 부분은 마감 전에 공식 질의 절차로 확인하는 것이 좋습니다.

공공기관 또는 공공조달과 관련된 절차는 기관별 공고와 국가종합전자조달시스템의 최신 안내를 우선 확인하세요. 민간 계약도 회사의 구매 정책, 개인정보 처리 기준, 보안 검토 절차를 따르는 것이 기본입니다. 이 글은 용어와 일반적인 문서 구성에 관한 정보이며, 개별 입찰·계약의 적법성이나 결과를 판단하지 않습니다. 중요한 계약 조건은 해당 조직의 구매·법무 담당자 및 공식 공고문으로 최종 확인하세요.

RFI 질문 예시: 답변 형식을 먼저 설계하기

RFI의 질문은 공급사의 홍보 문구를 모으는 데 그치지 않고 다음 단계의 판단 재료를 얻도록 만들어야 합니다. 회사와 서비스의 기본 정보, 유사 고객의 운영 사례, 지원 가능한 기능 범위, 구현 시 필요한 고객 측 준비 사항, 연동 가능한 시스템, 예상 리드타임을 각각 구분해 묻습니다. 가능하다는 답변만 받기보다 적용 조건, 제한 사항, 표준 제공과 추가 개발의 구분을 적도록 요청하면 과장된 비교를 줄일 수 있습니다.

응답 형식에는 표나 선택지를 활용해 비교 가능성을 높일 수 있습니다. 예를 들어 각 기능마다 제공 여부, 제공 방식, 추가 비용 발생 가능성, 참고 사례를 같은 칸에 쓰도록 합니다. 아직 사업자를 고르는 단계가 아니라는 점과 RFI 응답이 계약 또는 구매 약속이 아니라는 점도 안내하세요. 회신 자료의 사용 범위와 비밀 정보 처리 원칙을 사전에 명확히 하면 공급사도 더 구체적인 정보를 제공하기 쉬워집니다.

RFP 목차 예시: 빠뜨리기 쉬운 운영 조건

RFP의 기본 목차는 배경과 목표, 현황, 과업 범위, 요구사항, 산출물, 일정, 제안서 작성 안내, 평가와 계약 조건으로 구성할 수 있습니다. 여기에 도입 이후 운영 주체, 장애 대응, 교육, 데이터 이전, 종료 또는 전환 시 인수인계 조건을 넣으면 실제 서비스 생애주기까지 검토할 수 있습니다. 개발 또는 시스템 도입 과제라면 테스트 환경, 검수 기준, 사용자 수용 테스트의 책임과 완료 조건도 문서화하는 편이 좋습니다.

특히 범위 밖 항목을 명시하는 일은 분쟁 예방에 도움이 됩니다. 발주자가 제공할 데이터·접근 권한·의사결정 일정과 공급사가 제공할 인력·문서·교육 자료를 구분하세요. 일정표에는 중간 검토와 승인 지연 가능성을 고려한 의사결정 지점을 표시합니다. 경쟁사나 특정 제품을 염두에 둔 표현 대신 문제와 성능 기준을 중심으로 작성하고, 불가피한 호환성 요구는 근거와 검증 방식을 함께 적는 것이 바람직합니다.

RFQ 비교표: 총비용과 예외 조건을 함께 보기

RFQ 비교표의 첫 행에는 모든 참여사가 반드시 충족해야 하는 규격을 둡니다. 이후 품목 또는 서비스 단위별 수량, 단가, 할인, 세금, 배송·설치·교육 비용, 유지보수 비용, 계약 갱신 비용을 분리해 받으면 총비용을 계산하기 쉽습니다. 초기 견적이 낮아도 필수 옵션이나 운영 지원이 제외되어 있다면 실제 의사결정에서 비용이 커질 수 있습니다. 포함·제외 항목은 금액과 같은 중요도로 확인해야 합니다.

납기와 공급 안정성도 비교표에 넣으세요. 재고 여부, 주문 후 리드타임, 대체품 승인 절차, 지연 시 통지 기준, 보증 기간과 수리 방식은 가격만으로 드러나지 않는 위험입니다. 제안 금액의 유효기간과 통화, 가격 조정 조항도 같은 기준으로 맞춥니다. 견적을 받은 뒤 사양을 변경했다면 모든 참여사에 변경 내용을 동등하게 알리고, 수정 견적의 버전과 날짜를 기록해 이전 금액과 섞이지 않게 관리합니다.

공정한 질의응답과 협상 기록 관리

질의응답 기간은 제안 품질을 좌우합니다. 질문 접수 방법과 마감 시간을 하나로 정하고, 특정 업체의 질문에서 나온 중요한 해석은 익명화해 전체 참여사에 공유하는 것이 일반적입니다. 답변 때문에 요구사항이 달라졌다면 단순 안내가 아니라 문서 개정 이력으로 남기고, 제출 마감이나 평가 일정에 미치는 영향도 함께 공지하세요. 구두 설명이나 비공식 대화에만 의존하면 서로 다른 전제가 생길 수 있습니다.

협상 단계에서는 최초 제안, 질의응답, 변경 요구, 최종 합의안을 버전별로 보관합니다. 가격만 재협상하기보다 범위·일정·품질·책임의 균형이 유지되는지 점검해야 합니다. 선정하지 않은 업체에 결과를 알릴 때에는 내부 정책이 허용하는 범위에서 절차와 향후 기회에 관한 안내를 제공할 수 있습니다. 민감한 평가 정보나 타사의 견적은 공유하지 않으며, 보안과 개인정보 관련 자료는 조직의 보관·접근 정책에 따라 관리하세요.

문서 품질을 높이는 최종 검토 순서

최종 검토는 먼저 제목과 목적이 맞는지 확인하는 것에서 시작합니다. RFI인데 가격 확정을 요구하거나 RFQ인데 해결 방법의 창의적 제안을 요구하는 식의 혼합이 없는지 봅니다. 다음으로 요구사항 번호, 표의 단위, 날짜, 연락처, 제출 파일 형식, 평가표의 항목이 서로 일치하는지 교차 점검합니다. 문서 작성자가 아닌 동료에게 읽어 달라고 요청하면 내부에서 당연하게 여긴 약어와 빠진 전제를 발견하는 데 도움이 됩니다.

공개 또는 배포 직전에는 첨부파일과 링크가 열리는지, 민감한 정보가 남아 있지 않은지, 질문 접수 채널이 작동하는지 확인하세요. 받은 응답은 정해 둔 저장소와 파일명 규칙으로 보관하고, 접근 권한을 최소한으로 설정합니다. 이 체크리스트는 일반적인 실무 안내이므로 계약 금액, 입찰 방식, 개인정보 처리 등 조직별로 중요한 사안은 최신 내부 규정과 공고 기관의 공식 안내를 기준으로 추가 검토해야 합니다.

마무리: 문서 목적을 분리하면 결정이 선명해집니다

RFI, RFP, RFQ는 이름이 비슷하지만 각각 시장 이해, 해결안 비교, 거래 조건 비교를 위해 쓰입니다. 시작 단계에서 문서의 목적과 답변 범위를 정하면 공급사에게 불필요한 작업을 요구하지 않고, 발주 조직도 필요한 정보를 더 빠르게 확보할 수 있습니다. 특히 복잡한 프로젝트일수록 요구사항, 평가 기준, 비용 조건을 한 문서에 모두 섞기보다 단계별로 확정된 내용을 이어 붙이는 방식이 검토와 승인에 유리합니다.

실무 담당자는 이 글의 체크 항목을 바탕으로 조직의 표준 양식을 점검해 볼 수 있습니다. 다음 프로젝트에서 바로 적용할 수 있는 첫 단계는 현재 사용하는 요청서에 문서 목적, 필수 응답 항목, 비교 기준, 질의응답 방법이 명확히 적혀 있는지 확인하는 일입니다. 이후 실제 응답 결과를 되돌아보며 자주 빠지는 질문과 계약 이행 중 발생한 쟁점을 다음 양식에 반영하면, 조달과 협업의 품질을 지속적으로 높일 수 있습니다.

공식 확인 경로