RFP·RFI·RFQ 뜻과 차이: 제안서·견적 요청을 제대로 쓰는 법

RFP·RFI·RFQ, 먼저 한 줄로 구분하기

세 약어는 모두 외부 공급자와 대화할 때 쓰지만 목적이 다릅니다. RFI는 시장과 해결 방법을 알아보기 위한 정보 요청, RFP는 문제 해결 방식과 수행 역량을 비교하기 위한 제안 요청, RFQ는 사양이 상당히 확정된 뒤 가격과 납기 조건을 받는 견적 요청입니다. 가장 흔한 실패는 아직 무엇을 살지 정하지 못했는데 RFQ부터 보내는 것입니다. 이 경우 공급자는 서로 다른 전제를 놓고 숫자만 내므로 비교표가 무의미해집니다. 반대로 단순 소모품을 살 때 장문의 RFP를 쓰면 시간과 참여 업체의 비용만 늘어납니다.

약어의 뜻과 쓰는 시점

RFI는 Request for Information의 약자입니다. 조직 내부에 경험이 부족하거나 기술·시장 변화가 커서 선택지를 넓혀야 할 때 씁니다. RFP는 Request for Proposal로, 목표와 평가 기준은 정했지만 구체적인 해법은 공급자의 설계를 보고 결정할 때 알맞습니다. RFQ는 Request for Quotation이며 품목, 수량, 규격, 납품 장소처럼 비교 가능한 조건이 고정됐을 때 사용합니다. 세 문서는 순서대로 반드시 거치는 절차가 아니라 불확실성의 크기에 따라 고르는 도구입니다. 예를 들어 사무용 비품 재구매는 RFQ만으로 충분하지만, 고객 데이터가 연동되는 신규 시스템은 RFI 뒤 RFP가 안전합니다.

어떤 문서를 보낼지 고르는 판단표

아래 표에서는 발주자의 현재 상태를 기준으로 문서를 고릅니다. 실제 업무에서는 예산 승인 여부와 계약 방식도 함께 확인해야 합니다. 특히 공공·대기업 절차에서는 내부 규정의 명칭이 일반 용례와 다를 수 있으므로, 문서 이름보다 평가와 계약의 근거가 무엇인지 먼저 확인하세요.

RFI 작성법: 답을 요구하기보다 지형을 파악하기

좋은 RFI는 공급자에게 무료 컨설팅 보고서를 요구하는 문서가 아닙니다. 우리 조직의 배경, 해결하려는 업무상 불편, 예상 사용자 수, 현재 시스템, 반드시 지켜야 할 제약을 짧고 정확하게 제시한 뒤 선택지와 사례를 묻습니다. 기능 목록을 지나치게 고정하면 새로운 방식을 발견할 기회를 잃습니다. 반대로 “좋은 솔루션을 알려 달라”처럼 막연하면 답변 품질이 낮아집니다. 답변 형식, 분량, 회신 기한, 질의 접수 창구를 정해 두면 여러 업체의 정보를 같은 기준으로 검토할 수 있습니다. 받은 답변은 바로 계약 판단에 쓰기보다 RFP의 요구사항과 위험 항목을 다듬는 재료로 활용하세요.

RFP 작성법: 결과·범위·평가 기준을 분리하기

RFP의 중심은 기능 나열이 아니라 성공의 정의입니다. “문의 처리 시간을 줄인다”보다 “반복 문의의 40%를 셀프서비스로 전환하고 담당자 인수인계 시간을 줄인다”처럼 측정 가능한 결과를 씁니다. 그 다음 포함 범위와 제외 범위를 나눕니다. 데이터 이전, 교육, 운영 인수, 장애 대응은 본문 한쪽에 흩어두면 견적에서 빠지기 쉬우므로 별도 표로 명시합니다. 평가 기준도 미리 공개해야 합니다. 가격 30점, 구현 역량 30점, 일정·운영 계획 25점, 보안·계약 조건 15점처럼 가중치를 정하면 발표가 매끄러운 업체만 유리해지는 일을 줄일 수 있습니다. 관련 업무의 기본 용어가 낯설다면 엑셀 주요 함수 가이드처럼 비교표를 정리하는 도구도 함께 준비해 두면 좋습니다.

RFQ 작성법: 가격표가 아니라 총비용을 비교하기

RFQ에서 가장 중요한 것은 같은 조건으로 답하게 만드는 일입니다. 품목 코드나 성능 기준, 수량, 납품 장소, 희망 납기, 설치·배송·교육 포함 여부, 세금 표기, 견적 유효 기간을 통일합니다. 월 사용료만 낮고 초기 구축비·연동비·유지보수·해지 비용이 높은 경우가 많으므로 총소유비용을 따로 묻습니다. 대체 사양을 허용한다면 원안과 대안을 분리해 적게 하고, 대안이 충족하지 못하는 조건도 명시하세요. 납품 후 검수 기준과 하자 대응 시간을 적지 않으면 가장 싼 견적이 결국 가장 비싼 선택이 될 수 있습니다.

실무 진행 순서: 발송 전부터 선정 후까지

문서 발송은 절차의 중간일 뿐입니다. 아래 체크리스트처럼 내부 의사결정자와 검토 기록을 먼저 정리하면 일정이 밀리는 일을 줄일 수 있습니다.

1. 문제와 성공 지표를 한 문장으로 합의합니다.
2. 예산 범위, 계약 가능 시점, 보안·법무 제약을 확인합니다.
3. RFI·RFP·RFQ 중 필요한 문서와 대상 업체를 정합니다.
4. 질의 응답은 모든 참여 업체에 같은 내용으로 공유합니다.
5. 제안서는 평가표에 따라 독립적으로 채점한 뒤 합산합니다.
6. 선정 후에는 약속한 범위·일정·검수 기준을 계약서와 대조합니다.

기간과 비용을 현실적으로 잡는 법

소규모 구매는 RFQ 준비부터 선정까지 며칠 안에 끝날 수 있지만, 여러 부서가 참여하는 RFP는 요구사항 합의만 1~3주가 걸리기도 합니다. 공급자에게 제안 준비 시간을 너무 짧게 주면 상세한 계획보다 기존 자료를 재활용한 답변이 들어옵니다. RFI는 보통 1~2주, RFP는 질의 기간과 발표를 포함해 3~6주 정도의 여유를 잡되, 프로젝트 복잡도와 내부 결재 단계를 반영해야 합니다. 비용은 공급자 가격만이 아니라 평가 참여자의 시간, 법무·보안 검토, 파일럿과 전환 비용까지 포함해 보세요. 예산 상한을 공개할지 여부는 시장 상황에 따라 다르지만, 전혀 공개하지 않으면 규모가 지나치게 다른 제안이 모일 수 있습니다.

자주 하는 실수와 예방책

첫째, 요구사항을 길게 적으면서 우선순위를 표시하지 않는 실수입니다. 반드시 필요한 조건과 있으면 좋은 조건을 나누세요. 둘째, 특정 업체의 제품명이나 구현 방식에 맞춘 문장입니다. 정당한 호환성 요건이 아니라면 성과·인터페이스·보안 기준으로 바꾸는 편이 공정합니다. 셋째, 질의 답변을 한 업체에만 주는 일입니다. 공정성과 비교 가능성이 흔들립니다. 넷째, 견적의 단가만 보고 설치·운영·갱신 비용을 놓치는 일입니다. 다섯째, 최종 발표가 끝난 뒤 평가표를 새로 만드는 일입니다. 점수표는 발송 전에 승인받고 변경 이력을 남기세요. 문서 정리 과정에서 표기와 버전이 섞이지 않도록 비슷한 용어를 구분하는 방법처럼 명명 규칙도 통일하면 좋습니다.

FAQ: 제안·정보·견적 요청에서 많이 묻는 질문

RFI를 보냈다고 반드시 RFP를 해야 하나요?

아닙니다. RFI 결과로 구매를 보류하거나, 조건이 충분히 표준화됐다면 RFQ로 넘어갈 수 있습니다.

RFP에서 가격은 공개해야 하나요?

필수는 아니지만 예산 범위나 상한을 알려 주면 실행 불가능한 제안을 줄일 수 있습니다. 내부 정책을 우선하세요.

RFQ에 대체안을 받아도 되나요?

가능합니다. 다만 기준 사양 견적과 대체안 견적을 분리하고, 차이와 영향도를 명확히 요청해야 비교가 됩니다.

평가 점수는 업체에 공개해야 하나요?

계약·조달 규정에 따라 다릅니다. 공개 여부와 피드백 범위를 사전에 정해 두고 일관되게 적용하세요.

작은 프로젝트도 RFP가 필요한가요?

해법이 여러 개이고 실패 비용이 큰 경우에는 규모가 작아도 간단한 RFP가 도움이 됩니다. 반대로 규격이 정해진 반복 구매라면 RFQ가 효율적입니다.

제안서에 비밀 정보를 넣어도 되나요?

최소한만 제공하고, 필요하다면 비밀유지 약정과 자료 열람 권한을 먼저 정하세요.

평가표를 만드는 구체적인 방법

평가표는 공급자의 우열을 가르는 장식이 아니라, 내부에서 무엇을 중요하게 보는지 합의하는 문서입니다. 먼저 탈락 조건을 점수와 분리합니다. 개인정보 처리, 필수 인증, 계약 가능 여부처럼 충족하지 않으면 진행할 수 없는 항목은 ‘적합·부적합’으로 확인합니다. 그 다음 점수 항목은 서로 겹치지 않게 만듭니다. 구현 계획과 기술 역량을 별도 항목으로 둘 때는 계획에는 일정·인력·위험 대응을, 역량에는 유사 사례·담당자 경험·검증 방법을 보도록 정의합니다. 가격은 초기 비용과 반복 비용을 나누고, 제안 범위 밖 비용이 무엇인지 확인한 뒤 비교해야 합니다.

채점자는 제안서를 읽기 전에 배점 정의를 함께 읽어야 합니다. 예를 들어 5점은 요구사항을 구체적 근거로 충족하고 위험 대응까지 제시한 경우, 3점은 기본 접근은 있으나 근거나 실행 순서가 부족한 경우처럼 앵커를 적어 둡니다. 발표 점수는 말솜씨에 치우치기 쉬우므로, 문서에 없던 약속은 회의록에 남기고 계약 조건에 반영 가능한지 별도 확인하세요. 평가가 끝난 뒤에는 최고점만 보지 말고 항목별 편차도 살펴야 합니다. 가격은 낮지만 운영 대응 점수가 현저히 낮다면 전환 뒤의 부담을 다시 계산해야 합니다.

이해관계 충돌도 사전에 관리합니다. 평가자가 특정 업체와 최근 거래나 친족·고용 관계가 있다면 내부 기준에 따라 신고하고 참여 범위를 조정합니다. 질의 답변, 점수 원본, 합산표, 선정 사유는 버전을 구분해 보관하세요. 나중에 왜 이 업체를 골랐는지 설명할 수 있어야 계약 협상과 내부 보고가 모두 쉬워집니다.

계약·검수로 이어지는 인수인계 포인트

선정 통보가 끝났다고 제안서의 모든 문장이 계약이 되는 것은 아닙니다. 최종 협상에서는 제안서의 약속을 산출물, 책임자, 마감일, 검수 기준으로 바꿔야 합니다. ‘사용하기 편한 화면’처럼 주관적인 표현은 대표 사용자 시나리오, 처리 시간, 오류율, 접근성 기준처럼 확인 가능한 문장으로 고칩니다. 데이터 이전이 있다면 제공 주체, 정제 책임, 백업, 되돌리기 계획을 나누고, 테스트 데이터와 실제 데이터의 보안 수준도 분리합니다.

검수는 마지막 하루의 행사보다 중간 점검의 연속에 가깝습니다. 착수 직후에는 요구사항 목록과 변경 요청 절차를 확인하고, 설계 단계에는 화면·연동·권한의 기준선을 승인합니다. 개발 또는 납품 중에는 주간 보고의 형식을 정해 일정 지연과 의사결정 대기를 드러내세요. 최종 검수 전에는 시나리오별 통과 기준, 장애 등급, 수정 기한, 재검수 범위를 합의합니다. 공급자가 운영을 맡는다면 장애 접수 시간, 응답 시간, 정기 보고, 종료 시 자료 반환까지 계약서에 넣는 것이 안전합니다.

변경은 피할 수 없지만 기록 없이 추가하는 일은 피할 수 있습니다. 새로운 요구가 생기면 목적, 영향 범위, 비용·일정 변화, 승인자를 한 장의 변경 요청서에 적습니다. 작은 수정이라도 누적되면 예산과 일정이 흔들립니다. 반대로 당초 요구 중 더 이상 필요 없는 항목은 제거 여부를 명확히 해 공급자와 발주자 모두의 기대치를 맞추세요.

바로 써 보는 발송 전 최종 점검

발송 버튼을 누르기 전에는 문서를 처음 보는 동료에게 다섯 가지를 물어보면 좋습니다. 이 일을 왜 하는지 한 문장으로 이해되는지, 꼭 필요한 결과가 무엇인지, 공급자가 답해야 할 형식이 분명한지, 일정과 질의 창구가 하나로 정리됐는지, 무엇을 기준으로 선정하는지입니다. 이 질문에 문서 안에서 바로 답을 찾을 수 없다면 공급자도 같은 지점에서 멈춥니다. 파일명에는 프로젝트명·문서 종류·버전·날짜를 넣고, 배포 목록과 첨부 파일의 버전을 대조하세요.

마지막으로 받는 사람의 입장에서 부담을 점검합니다. 지나치게 많은 서식이나 불필요한 증빙 요구는 좋은 업체의 참여를 줄일 수 있습니다. 반면 보안·개인정보·납기·책임 범위처럼 나중에 바꾸기 어려운 조건은 초기에 분명히 해야 합니다. 목적에 맞는 RFI, RFP, RFQ를 고르고 비교 가능한 답변 틀을 제공하는 것만으로도 구매와 프로젝트의 품질이 크게 달라집니다.

규모별로 간단하게 적용하는 예시

직원 열 명 안팎의 팀이 협업 도구를 바꾸려는 경우를 생각해 보세요. 필요한 인원, 현재 쓰는 파일 저장소, 필수 연동, 월 예산, 교육 가능 시간을 적고 세 업체에 RFI를 보내면 과도한 기능을 줄일 수 있습니다. 이후 후보가 두세 개로 좁혀졌는데 도입 지원과 데이터 이전의 방식이 다르다면 짧은 RFP로 전환합니다. 반대로 이미 사용 중인 프린터의 소모품처럼 모델과 수량, 납품일이 확실하다면 RFQ 한 장이면 충분합니다.

중견 조직의 시스템 교체는 더 많은 준비가 필요합니다. 사용자 부서별 요구를 그대로 붙여 넣기보다 공통 목표와 우선순위를 정리하고, 인터페이스·권한·감사 로그 같은 필수 조건을 별도 부록에 둡니다. 공급자는 질문을 통해 빈칸을 찾고, 발주자는 모든 질문에 같은 기준으로 답해야 합니다. 이 작은 원칙들이 나중의 변경 비용과 선정 논란을 줄이는 가장 확실한 방법입니다.

담당자가 기억할 핵심 정리

불확실성이 크면 RFI로 배움을 먼저 만들고, 해결 방식의 경쟁이 필요하면 RFP로 제안을 비교하며, 사양이 확정됐으면 RFQ로 총비용을 견적받습니다. 문서의 길이보다 중요한 것은 참가자 모두가 같은 질문을 받았는지입니다. 목표, 범위, 일정, 평가, 계약·검수 기준을 한 흐름으로 연결해 두면 공급자는 더 정확히 답하고 발주자는 더 자신 있게 선택할 수 있습니다.

다음 프로젝트에서는 이전 문서를 그대로 복사하기보다, 바뀐 목표와 현재의 제약부터 확인하세요. 표준 양식은 시간을 아끼지만 과거의 가정을 그대로 가져올 위험도 있습니다. 작은 구매라도 비교 조건을 통일하고, 큰 프로젝트라면 변경과 의사결정의 기록을 남기는 습관이 결국 비용과 시간을 지키는 방법입니다.

마무리 확인

문서를 보낸 뒤에도 질의 응답, 제출본, 평가표, 협상 결과를 같은 폴더와 같은 버전 규칙으로 관리하세요. 이 기록은 다음 구매의 템플릿이 되고, 담당자가 바뀌어도 결정의 맥락을 이어 주는 가장 실용적인 자산입니다.