제안서에서 Compliance와 Responsiveness는 어떻게 다른가요?

Compliance는 고객이 명시한 요구사항과 제출 지침(목차 구성, 분량, 서식, 모든 요구사항)을 정확히 지키는 일입니다. Responsiveness는 한 걸음 더 나아가 요구사항 뒤에 있는 목표, 우려, 핫버튼(고객이 가장 중요하게 여기는 관심사)에 답하며 RFP에 적혀 있지 않은 것까지 포함합니다. 준수는 했지만 응답성이 없는 제안서도, 그 반대도 있을 수 있습니다. 이기는 제안서는 둘 다 갖추고 있습니다.

컴플라이언스 매트릭스란 무엇인가요?

제안팀이 내부에서 쓰는 작업용 표입니다. 고객이 명시하거나 암시한 모든 요구사항을 나열하고 각 요구사항의 출처, 답변 담당자, 제안서 내 답변 위치, 우리 솔루션이 얼마나 충족하는지를 기록합니다. APMP Body of Knowledge는 규모와 관계없이 작성 전에 만들고 정정공고나 질의 답변이 나올 때마다 업데이트하라고 권합니다.

컴플라이언스 매트릭스와 응답 매트릭스는 무엇이 다른가요?

컴플라이언스 매트릭스는 팀용으로, 모든 요구사항과 담당자, 준수 상태를 관리합니다. 응답 매트릭스는 여기서 파생되어 제안서와 함께 제출하는 표로, 각 요구사항의 답이 제안서 어디에 있는지 평가위원에게 보여줍니다. 나라장터의 조견표가 같은 역할을 합니다. 분량 제한 때문에 별도 표를 넣기 어렵다면 요구사항 번호를 목차와 소제목에 넣습니다.

미준수 때문에 입찰을 다시 고민해야 하는 경우는 언제인가요?

많은 항목에서 미준수이거나 부분 준수에 그친다면 이 사업을 계속 추진해야 하는지부터 다시 물어야 합니다. 제안서 작성 중 요구사항이 바뀌어 전체 준수율이 90% 아래로 떨어졌다면 Bid/No-Bid 판단을 다시 하는 편이 합리적입니다.

요구사항에 응답성 있게 답하려면 어떻게 써야 하나요?

먼저 준수한다고 분명히 밝히고 그 요구사항이 이 고객에게 왜 중요한지 설명합니다. 비슷한 고객에게서 배운 점을 더한 뒤 시험 결과, 레퍼런스, 수치 같은 근거로 마무리합니다. 기능보다 고객이 얻는 효과를 먼저 씁니다.

Compliance와 Responsiveness: 이기는 제안서가 반드시 지키는 두 가지

다음 제안서를 쓰기 전에 먼저 답해 볼 질문이 하나 있습니다. 이기는 제안서가 무엇인지 말로 설명할 수 있나요?

경험 많은 제안 담당자일수록 답을 감으로는 알지만 막상 말로 풀어내기는 어렵습니다. 예전에는 그래도 괜찮았지만 지금은 다릅니다. AI가 100페이지짜리 초안을 몇 분 만에 써내는 시대가 됐습니다. 누군가는 그 초안을 판단하고 무엇이 "좋은" 제안서인지 AI에게 알려줘야 합니다. 기준을 말로 하지 못하면 두 가지 다 할 수 없습니다.

이 시리즈에서는 APMP(Association of Proposal Management Professionals, 글로벌 제안 전문가 협회)의 Body of Knowledge를 APMP Foundation Study Guide의 요약을 따라 살펴보며 제안 전문가들이 공유하는 기준을 하나씩 짚어봅니다. 첫 주제는 Foundation의 출발점인 Focus on the Customer(고객 중심) 영역의 Identifying Requirements for Compliance and Responsiveness(Compliance와 Responsiveness를 위한 요구사항 식별)입니다.

일러스트: Compliance와 Responsiveness라고 적힌 두 기둥 위에 Winning Proposal이 놓여 있다 — 이기는 제안서는 두 기둥 위에 서 있습니다. 하나만 빠져도 무너집니다.

준수와 응답은 서로 다른 일

Body of Knowledge는 이 주제를 간단한 주장으로 시작합니다. 이기는 제안서는 준수하고(compliant) 응답한다(responsive). 이 둘은 서로 다르면서 똑같이 중요한 일입니다. 고객의 요구사항을 찾아내 충족하는 일이 하나, 고객의 비즈니스 니즈에 답하는 일이 다른 하나입니다.

	Compliance	Responsiveness
무엇인가	고객이 명시한 요구사항과 지침을 충족하는 것	그 요구사항 뒤에 있는 목표, 우려, 가치에 답하는 것
어디서 오나	주로 공고 문서: 요구사항, 지침, 질문, 규격	주로 공고 문서 밖: 입찰 전후로 고객에 대해 알게 된 것
없으면	제안서가 탈락할 가능성이 높다	가격 경쟁으로 끌려간다
있으면	경쟁에 남는다	다른 입찰자보다 앞선다

왜 둘 다 필요한지는 질문 하나로 알 수 있습니다. 우리 제안서와 경쟁사 제안서가 모두 100% 준수했는데 둘 다 응답성은 없다고 해 봅시다. 고객은 무엇으로 고를까요? 대개 가장 싼 쪽을 고르거나 제안서와 상관없는 다른 요인으로 고릅니다. Compliance로 최종 후보에는 오를 수 있지만 승자를 정하지는 못합니다. 가격이 싸서가 아니라 가장 좋은 선택이어서 뽑히고 싶지 않으신가요?

일러스트: 100% COMPLIANT 도장이 찍힌 두 제안서가 저울 위에서 균형을 이루고, 평가위원이 한쪽에 가격표를 떨어뜨리려 한다 — 모두가 완벽하게 준수하고 아무도 응답하지 않으면 가격표가 승부를 가릅니다.

Compliance로 탈락을 막고 Responsiveness로 이깁니다.

Compliance: 더도 덜도 아니게

APMP의 정의에 따르면 준수한 제안서는 고객의 요구사항과 제출 지침을 충족하고 고객의 질문에 답하며 규격에 대응합니다. 그 이상도 이하도 아닙니다. 실무에서는 네 가지로 나뉩니다.

구조: 지정된 목차, 순서, 번호 체계를 그대로 써서 고객이 지시한 대로 구성합니다.
분량: 페이지 제한을 지킵니다.
서식: 글꼴, 글자 크기, 여백, 파일 형식 같은 서식 규정을 따릅니다.
충족: RFP의 모든 요구사항을 빠짐없이 충족합니다.

유능한 팀도 "이상도 아니다" 쪽에서 자주 걸려 넘어집니다. 50페이지 제한에 60페이지를 내는 건 아무리 정성을 들였어도 지침 위반입니다. 평가위원은 50페이지에서 읽기를 멈출 수도 있고 제안서를 아예 제쳐둘 수도 있습니다. 요구하지 않은 자료를 첨부하는 것도 마찬가지입니다. 준수하지 않은 제안서는 탈락할 가능성이 높습니다. 공공 입찰에서는 위험이 하나 더 있습니다. 준수하지 않은 제안서가 낙찰되면 경쟁사가 이의를 제기할 수 있습니다.

요구사항은 RFP 안에만 있지 않다

Body of Knowledge에는 놓치기 쉬운 관점이 하나 있습니다. 요구사항은 공고 문서에 적힌 것만이 아닙니다. 고객은 공고 전 미팅, 질의응답, 지나가는 말 한마디까지 사업 기간 내내 요구사항을 전합니다. 암시만 되는 요구사항도 있지만 고객에게 중요하기는 마찬가지입니다. APMP의 지침에 따르면 공고 문서에 있든 없든 이런 요구사항을 모두 찾아내 하나의 컴플라이언스 매트릭스에 모아 정리해야 합니다.

자발적 제안(unsolicited proposal)에서는 이게 더 중요합니다. 기댈 RFP가 없으니 고객의 요구사항과 문제를 얼마나 정확히 기록했느냐에 따라 그 제안이 이길 수 있는지가 크게 갈립니다.

실제 RFP에서 요구사항이 숨어 있는 곳

많은 공고, 특히 공공 사업은 요구사항을 하나의 체크리스트로 주지 않습니다. 문서 여기저기에 흩어져 있어서 직접 모아야 합니다.

참여조건: 면허, 인증, 재무 기준, 수행 실적. 하나라도 못 맞추면 아예 입찰할 수 없습니다.
필수요구사항: 범위, 기능, 성능에 대해 "~해야 한다", "반드시 포함"이라고 적힌 항목. 충족하지 못하면 부적격이나 큰 감점입니다.
작성지침: 분량, 서식, 목차, 글꼴, 파일 형식, 제출 방법. 지키지 않으면 감점되거나 형식 미비로 접수되지 않습니다.
정정공고와 질의 답변: 작성을 시작한 뒤에 위 항목 중 무엇이든 조용히 바꿀 수 있습니다.

Compliance를 갖추려면 이 모두를 함께 충족해야 합니다. 발주처가 체크리스트를 주지 않아도 필요한 건 똑같으니 직접 만들어야 합니다.

Responsiveness: "알고 있다"는 것을 보여주기

Responsiveness는 Compliance를 넘어섭니다. 응답성 있는 제안서는 고객의 목표, 밑바닥의 우려, 핵심 이슈와 가치에 답합니다. 그중 상당수는 공고 문서에 한 번도 나오지 않습니다. 이런 제안서는 조달을 끝내는 데 그치지 않고 고객이 비즈니스 목표를 이루도록 돕습니다. Body of Knowledge에 따르면 Responsiveness에는 다음이 포함됩니다.

고객의 명시된 니즈와 숨은 니즈를 이해하고 둘 다에 답하기
각 요구사항이 고객에게 왜 중요한지 알고 있음을 보여주기
우리 솔루션으로 고객이 얻을 효과를 설명하기
고객의 언어로, 고객의 용어를 써서 쓰기
고객의 예산 안에서 가격을 제시하기
고객의 신념과 문화에 공감하고 있음을 보여주기
우리에게 맡겨도 안전하다는 근거를 보여주기

같은 요구사항, 두 가지 답변

Study Guide는 일부러 아주 평범한 예를 듭니다. 요구사항이 "노란 종이박스를 제공할 것"이라고 해 봅시다. 답하는 방법은 두 가지입니다.

준수만

"당사는 노란 종이박스를 제공합니다."

요구사항은 정확히 충족했지만 거기까지입니다.

준수 + 응답

똑같이 시작한 뒤 박스가 왜 중요한지 설명합니다. 안에 값비싼 제품이 들어가기 때문입니다. 비슷한 고객에게서 배운 점, 곧 박스는 튼튼할 뿐 아니라 가볍고 직원이 들기 쉬워야 한다는 점도 덧붙입니다. 우리 박스가 두 조건을 모두 충족한다고 설명하고 근거로 부속서의 제3자 시험 결과를 제시합니다.

일러스트: 같은 노란 박스가 두 번 그려져 있고, 오른쪽에는 Protects valuables, Lightweight, Easy to carry, Test results 설명이 붙어 있다 — 같은 박스, 같은 요구사항. 응답성 있는 답변은 박스가 왜 중요한지 설명하고 근거로 뒷받침합니다.

두 답변 모두 준수했지만 고객의 업무를 이해하고 있다는 느낌은 두 번째만 줍니다. 두 번째 답변에는 거의 모든 요구사항에 쓸 수 있는 틀이 있습니다.

확약한다: 요구한 것을 제공한다고 분명히 밝힙니다.
이유를 말한다: 이 요구사항이 이 고객에게 왜 중요한지 고객의 말로 씁니다.
아는 것을 더한다: 비슷한 고객에게서 배운, 고객이 미처 적지 않았을 수도 있는 것을 덧붙입니다.
증명한다: 시험 결과, 레퍼런스, 수치로 뒷받침합니다.

우리 자랑에서 고객 이야기로

Responsiveness는 제안서가 우리 회사 이야기만 할 때 가장 흔하게 부족해집니다. 예를 들어 "24시간 무중단 서비스" 요구사항에 대한 흔한 답변은 제품 소개서처럼 읽힙니다.

Product Story

"당사 플랫폼은 이중화 아키텍처와 자동 Failover를 적용해 99.99% 가용성을 달성하며, 동종 프로젝트 12건에서 검증되었습니다."

Customer Story

"귀사 공장에서는 1분의 다운이 생산 라인을 멈추고, 멈춘 라인은 그대로 손실로 이어집니다. 그래서 가용성 수치가 아니라 '1분 이내 자동 복구'를 SLA로 약속합니다."

일러스트: 왼쪽에서는 업체 담당자가 서버 랙을 향해 메가폰으로 99.99%를 외치고, 오른쪽에서는 공장 라인 옆에서 1분 복구 스톱워치를 가리키며 고객이 고개를 끄덕인다 — Product Story는 우리가 가진 것을 말하고 Customer Story는 고객의 문제에서 시작합니다.

두 답변의 기술은 똑같고 출발점만 다릅니다. 첫 번째는 우리가 가진 것에서 출발합니다. 두 번째는 고객이 왜 그걸 요구했는지에서 출발해 그 이유에 맞는 약속을 합니다.

컴플라이언스 매트릭스와 응답 매트릭스

Body of Knowledge는 서로 연결된 두 도구를 소개합니다. 둘의 차이를 정확히 알아두면 좋습니다.

	컴플라이언스 매트릭스	응답 매트릭스
누구를 위한 것	우리 제안팀	고객의 평가위원
목적	요구사항 누락 방지	평가위원이 각 요구사항의 답을 바로 찾게 하기
언제 만드나	기획 초기, 작성 전에 만들고 정정공고 질의 답변, 목차 변경 때마다 업데이트	컴플라이언스 매트릭스에서 파생해 제안서와 함께 제출
제출하나	아니오	예, 모든 제안서에

일러스트: 제안팀이 컴플라이언스 매트릭스 표를 점검하고, 평가위원이 응답 매트릭스 지도를 따라 제안서의 해당 페이지를 찾아간다 — 컴플라이언스 매트릭스는 팀의 누락을 막고 응답 매트릭스는 평가위원이 답을 찾도록 돕습니다.

APMP의 지침에 따르면 규모나 일정과 상관없이 모든 입찰에서 컴플라이언스 매트릭스를 만들어야 합니다. 실무에서 쓸 만한 매트릭스에는 이런 열이 들어갑니다.

ID	요구사항	출처	담당	답변 위치	준수	메모 / 사유
R-014	장애 발생 시 자동으로 복구할 것	RFP 4.2.1	솔루션 아키텍트	2권 3.4	완전	SLA에 1분 이내 복구 약속
R-022	2시간 이내 현장 지원	RFP 5.1	서비스 책임자	2권 6.2	부분	수도권 2시간, 그 외 4시간. 원격 조치는 30분 이내
R-031	지역 내 수행 실적이 있는 업체 선호	공고 전 미팅(9/3)	영업 책임자	요약	완전	RFP에 없는 암묵적 요구사항

도구는 무엇이든 괜찮습니다. 엑셀이든 노션 같은 데이터베이스든 마인드맵이든 팀이 최신 상태로 유지하기만 하면 됩니다. 매트릭스는 작성 전에 이미 있어야 합니다. 암묵적 요구사항까지 모든 요구사항이 들어 있어야 하고 모든 작성자가 같은 버전을 보고 써야 합니다.

응답 매트릭스는 컴플라이언스 매트릭스에서 나옵니다. 각 요구사항에 대한 답이 어디에 있는지 보여주는 평가위원용 길잡이로, 나라장터의 조견표가 바로 이 역할을 합니다. 분량 제한 때문에 별도 표를 넣을 여유가 없다면 Body of Knowledge는 같은 정보를 목차와 소제목에 넣으라고 권합니다. 예를 들어 "3.4 자동 복구(RFP 4.2.1)"처럼 씁니다. 평가위원도 사람이라 답을 쉽게 찾을수록 자신 있게 점수를 줍니다.

미준수는 정직하게

우리 솔루션이 어떤 요구사항을 충족하지 못할 때도 있습니다. 일단 전부 "준수"라고 적고 나중에 어떻게든 맞추고 싶은 유혹이 생기죠. Body of Knowledge는 이를 경계합니다. 미준수는 고객이 제안서를 떨어뜨리는 가장 쉬운 이유이며 공공 입찰에서는 더욱 그렇습니다. 숨기면 문제를 뒤로 미룰 뿐입니다. 대신 이렇게 합니다.

얼마나 준수하는지 기록한다. 컴플라이언스 매트릭스에 완전 준수인지 부분 준수인지 적고 100% 충족하지 못하는 이유를 설명합니다. 고객은 이유를 알고 싶어 하고 또 알아야 합니다.
격차가 많으면 경고로 받아들인다. 많은 항목에서 미준수이거나 부분 준수라면 이 사업을 추진해야 하는지부터 다시 묻고 입찰하지 않는 결정도 제안할 수 있어야 합니다.
요구사항 변화를 살핀다. 정정공고로 전체 준수율이 90% 아래로 떨어지면 Bid/No-Bid 판단을 다시 합니다.

일러스트: COMPLIANCE라고 적힌 게이지의 바늘이 90% 눈금 바로 아래를 가리키고, 옆에 BID와 NO-BID 표지판이 있다 — 준수율이 90% 아래로 떨어지면 입찰 여부를 다시 판단합니다.

준수를 분명하게 보여주는 법

준수했는지 평가위원이 짐작하게 만들면 안 됩니다. Body of Knowledge는 공고 유형에 따라 쓰는 방법을 달리합니다.

질의응답형 RFP: 답변마다 첫머리에 요구사항을 다시 말하고 제공하겠다고 확약한 뒤 응답성 있는 설명을 덧붙입니다.
자발적 제안이나 정해진 질문 목록이 없는 제안: 고객의 핵심 요구사항을 어떻게 이해했는지 정리하고 각각에 분명한 준수 문장을 붙입니다.
요구사항이 명시된 RFP: 컴플라이언스 매트릭스와 응답 매트릭스를 씁니다.

요구사항이 고객에게서 왔든 우리 경험상 고객에게 필요하다고 판단한 것이든 목록에 올리고 응답성 있는 설명을 붙입니다.

고객을 계속 중심에 두기

마지막 베스트 프랙티스가 나머지를 하나로 묶습니다. 고객과 이해관계자의 핫버튼, 발주하는 사업을 이해했다면 그것을 보여줘야 합니다. 요약(Executive Summary)에서 고객의 비전, 목표, 핫버튼을 분명히 쓰고 그에 맞는 테마 문장을 제안서 전체에 녹여 넣습니다. 고객이 무엇을 원하는지 모르는 회사에 일을 맡길 이유는 없습니다.

Body of Knowledge는 고객 중심의 입찰자를 네 가지 습관으로 설명합니다.

각 권, 각 장, 각 문단에서 우리보다 먼저 고객을 언급한다.
우리보다 고객을 더 자주 언급한다.
고객의 비전과 핫버튼을 분명하게 쓴다.
기능보다 효과를 먼저 제시한다.

네 번째가 가장 중요합니다. 기능은 이 고객에게 실제 효과를 줄 때만 내세울 가치가 있습니다. Study Guide는 자동차 구매를 예로 듭니다. 강력한 엔진은 좋은 기능처럼 들리지만 안전과 환경을 중시하며 가족용 차를 찾는 부모에게는 상관이 없습니다. 고객이 신경 쓰지 않는 기능은 제안서에 넣을 필요가 없습니다.

모든 입찰에서 지킬 여섯 가지

RFP 전부터 시작한다. 공고가 나온 뒤에 Responsiveness를 고민하기 시작하면 이미 늦습니다. 고객의 진짜 우려를 이해하려면 신뢰가 필요한데 신뢰에는 시간이 걸립니다.
RFP를 끝까지 읽고, 한 번 더 읽는다. 요구사항 사이의 연결, 질의 답변, 미묘한 뉘앙스는 문서 전체에 흩어져 있습니다. 불분명한 점은 발주처가 정한 공식 절차로 질의합니다.
모든 입찰에서 컴플라이언스 매트릭스를 만든다. 작성 전에 만들고 바뀔 때마다 업데이트합니다. 응답 매트릭스(조견표)를 제출하거나 소제목에 요구사항 번호를 넣습니다.
미준수는 정직하게. 이유를 설명하고 대안을 제시합니다. 준수율이 90% 아래로 떨어지면 Bid/No-Bid를 다시 판단합니다.
준수를 분명히 밝힌다. 그리고 그 요구사항이 왜 중요한지 한 줄을 더합니다.
고객의 관점에서 쓴다. 고객을 먼저, 우리보다 더 자주 언급하고 효과부터 씁니다.

AI가 초안을 쓰는 시대에 이것이 의미하는 것

이 역량의 두 절반은 자동화 앞에서 처지가 전혀 다릅니다. Compliance는 대부분 기계적인 작업입니다. 모든 요구사항, 지침, 정정공고를 뽑아내고 각각에 답이 있는지 확인하는 일이죠. AI가 잘하는 일이니 맡겨야 합니다. 147페이지에 있던 "~해야 한다" 하나를 놓쳐서 떨어질 이유는 없습니다.

Responsiveness는 RFP만으로는 만들어낼 수 없습니다. 정의상 RFP에 적혀 있지 않은 것에 달려 있기 때문입니다. 고객이 왜 이 사업을 발주하는지, 지난번에 무엇이 잘못됐는지, 평가위원이 무엇을 걱정할지 같은 것들입니다. 공고 문서만 AI에게 넘기면 완벽하게 준수했지만 다른 입찰과 똑같은 제안서가 나옵니다. 고객이 가격으로 고를 수밖에 없는 바로 그 상황입니다. 올바르게 분담하면 준수 작업은 AI가 맡고 고객에 대한 이해는 사람이 가져옵니다. 그래야 AI가 그 이해를 바탕으로 쓸 수 있습니다.

Contrl에서는

저희가 만드는 제안서 작성 AI, Contrl은 Compliance 작업을 대신합니다. 작성을 시작하기 전에 RFP의 요구사항을 모두 뽑아 제안서 목차에 배정해 둡니다. Responsiveness는 사람에게 남겨둡니다. 짧은 전략 인터뷰로 고객, 우리 회사, 경쟁사에 대해 묻습니다. 그런 다음 고객 니즈, 우리의 강점, 고객이 얻는 효과가 담긴 윈 테마를 제안합니다. 사람이 하나를 고르면 모든 장이 그 테마로 쓰입니다.

Contrl이 완성한 슬라이드. 하단에 근거로 RFP 요구사항 FR-003, FR-006이 적혀 있다 — Contrl이 쓴 페이지마다 답하는 RFP 요구사항(여기서는 FR-003, FR-006)이 적혀 있어 준수 여부를 확인하기 쉽습니다. 페이지가 무엇을 주장할지는 사람이 고른 윈 테마에서 나옵니다.

다음 편 예고

Body of Knowledge에 따르면 Responsiveness는 시장과 문화에 따라 크게 다르고 RFP가 나오기 훨씬 전, 사업 개발 초기 단계부터 시작됩니다. 그래서 다음 주제는 고객 관계 관리(Customer Relationship Management)입니다. 고객은 공식 평가 규칙을 따라야 하지만 업종을 가리지 않고 잘 알고 호감이 가며 믿을 수 있는 상대를 고르는 경향이 있습니다. 2편에서는 입찰 전에 그 관계를 어떻게 쌓는지 살펴봅니다.

이 글은 APMP Body of Knowledge를 요약한 APMP Foundation Study Guide 4.2판(© 2025 APMP)을 바탕으로 한 독립적인 학습용 해설입니다. 원문을 풀어 쓰고 해설한 것으로, APMP의 승인을 받은 글이 아닙니다. 컴플라이언스 매트릭스 예시와 무중단 서비스 예시는 이 글을 위해 만든 것입니다. 공식 원문과 자격 정보는 apmp.org에서 확인하세요.