"평가위원이 '그걸 무엇으로 증명할 수 있습니까?'라고 물을 때"
APMP EP10의 주제는 Proof Points입니다.
지난 EP09에서 Feature가 어떻게 Benefit이 되고, 그 Benefit이 어떻게 Discriminator가 되는지를 다뤘다면, 이번 EP10은 그다음 질문을 다룹니다. 그렇게 만든 주장은 무엇으로 믿게 만들 것인가 하는 질문입니다.
제안서에 자주 등장하는 문장이 있습니다. "당사는 고객의 업무 효율을 높일 수 있습니다", "당사는 안정적인 운영을 제공할 수 있습니다", "당사는 전환 리스크를 줄일 수 있습니다." 문장 자체는 나쁘지 않습니다. 하지만 평가위원 입장에서는 한 번 더 묻고 싶은 질문이 남습니다. "Can you prove it?"
좋은 제안서는 평가위원에게 믿어달라고 요구하지 않습니다. 믿을 수밖에 없는 근거를 같이 보여줍니다. 그 근거가 오늘 다룰 Proof Point입니다. 이번 글에서는 APMP가 정리한 Proof Point의 원칙을 한국 제안서 실무에 맞춰 정리합니다. 마지막 한 섹션에서는 이 흐름을 제품 워크플로우에 박아 넣고 있는 Contrl 2차 클로즈 베타도 짧게 안내합니다.
1. Feature와 Benefit은 Claim, Proof Point는 Evidence
지난 글에서 본 Feature와 Benefit은 평가위원 입장에서 보면 모두 "우리가 그렇게 할 수 있다는 주장(Claim)"입니다.
- "담당자 처리시간을 단축할 수 있습니다."
- "요구사항 누락 위험을 줄일 수 있습니다."
- "전환 리스크를 낮출 수 있습니다."
이 문장들은 우리 입장에서 맞는 말입니다. 그런데 평가위원은 이 문장을 그대로 믿지 않습니다. 이런 의심이 남아 있기 때문입니다. 이 기능이 정말 검증됐는가, 이 Benefit이 실제로 달성 가능한가, 이 업체가 말한 대로 수행할 수 있는가.
Proof Point는 이 의심을 끊어주는 장치입니다.
Feature → Benefit (Claim, 주장)
+ Proof Point (Evidence, 증거)
= 평가위원이 믿을 수 있는 문장
좋은 제안서는 주장과 증거를 같이 가져갑니다. "시간을 줄일 수 있습니다"에서 끝나면 주장입니다. "시간을 줄일 수 있습니다. 유사 사업 4건에서 평균 28% 단축한 실적이 있습니다"까지 가야 증거가 됩니다.
2. Proof Point의 정의: Facts and Verifiable Evidence
APMP 원문은 Proof Point를 이렇게 정의합니다.
"Proof points are facts that provide verifiable evidence for your solution's features and benefits."
핵심 단어가 두 개입니다. 첫째, Facts(사실)입니다. 좋은 표현, 멋진 형용사, 인상적인 슬로건이 아닙니다. 사실이어야 합니다. 둘째, Verifiable evidence(검증 가능한 증거)입니다. 평가위원이 확인할 수 있어야 합니다.
이 두 가지를 통과하지 못하면 어떤 멋진 문장도 결국 "좋은 말" 정도로만 남습니다. 예를 들어 "우리는 고객 만족도가 높습니다"는 아직 약합니다. 얼마나 높은지, 어떤 조사인지, 언제 측정했는지, 누가 확인할 수 있는지가 같이 붙어야 비로소 Proof Point가 됩니다.
Proof Point는 제안서의 장식이 아닙니다. 우리의 핵심 메시지를 평가위원이 믿게 만드는 근거 구조입니다.
3. Proof Point는 성공 사례뿐 아니라 위기 대응에서도 나온다
Proof Point는 어디서 구해야 할까요. 가장 좋은 출처는 과거 수행 경험과 성과 데이터입니다. 유사 프로젝트에서 어떤 성과를 냈는가, 계약 성과·SLA·납기·품질 지표는 어떠했는가, 비슷한 고객에게 어떤 결과를 만들어줬는가 같은 질문에 답할 수 있는 자료들입니다. 여기에 고객의 추천 문구·감사 문구, 수상·인증·외부 평가가 더해질 수 있습니다.
여기서 한국 제안 현장에서 자주 놓치는 부분이 하나 있습니다. Proof Point는 성공 사례만 의미하지 않습니다. 어려운 상황을 어떻게 해결했는지도 강력한 증거가 됩니다.
예를 들어 고객 불만이 있었지만 빠르게 대응했고, 이후 장기적인 관계로 회복했다면, 이것도 매우 좋은 Proof Point입니다. 평가위원은 문제가 한 번도 없었던 업체를 찾는 게 아닙니다. 문제가 생겼을 때 책임 있게 해결할 수 있는 업체를 찾습니다.
그래서 좋은 증거는 "잘했습니다"에서 그치지 않습니다. "어려운 상황에서도 믿을 수 있었습니다"까지 보여줄 수 있어야 합니다. 이 관점이 들어가면 회사가 가진 사례의 가치가 두 배가 됩니다.
4. 모으는 순서: Win Strategy 먼저, RFP 이전부터
Proof Point를 모을 때 한국 제안팀이 자주 하는 실수가 있습니다. 가지고 있는 모든 사례를 일단 다 모아놓고, 나중에 제안서에 끼워 넣으려고 하는 것입니다. APMP 원문은 정확히 반대로 말합니다. 먼저 Win Strategy를 이해하고, 그 전략을 뒷받침하는 Proof Point를 찾아야 합니다.
1. 이번 사업에서 어디서 이길 것인가?
2. 평가위원에게 어떤 Win Theme를 기억시킬 것인가?
3. 그 Win Theme가 믿기려면 무엇을 증명해야 하는가?
4. 그 증거를 어디서 어떻게 구할 것인가?
이 순서가 흔들리면 자료는 많은데 제안서는 산만해집니다. 증거가 부족해 보이는 게 아니라, 전략 없이 늘어놓은 증거 때문에 핵심 메시지가 흐려지는 것입니다.
시점도 중요합니다. 원문은 Proof Point를 RFP 이전부터 모으라고 분명히 말합니다. RFP가 나온 뒤에는 분석·전략·목차·원고·리뷰·수정이 동시에 진행됩니다. 그때 가서 "혹시 유사 사례 있나요?"라고 묻기 시작하면 답이 늦거나, 너무 일반적인 답이 옵니다.
특히 한국에서는 같은 발주처가 비슷한 사업을 반복적으로 발주하는 경우가 많습니다. 과거 공고와 과거 제안서를 보면 반복되는 정보 요구가 보입니다. 이 고객은 어떤 실적을 자주 요구하는가, 어떤 성과 지표를 중요하게 보는가, 과거 제안서에서는 어떤 증거가 필요했는가 같은 패턴입니다. 이걸 미리 정리해 두면 RFP가 나오기 전부터 준비할 수 있는 것들이 보입니다.
Proof Point 수집은 한 번에 끝나는 일이 아닙니다. 먼저 준비하고, RFP 이후에 정교하게 맞추는 작업입니다.
5. Data Call의 핵심: "많이"를 "23회"로 바꾸는 일
Proof Point의 품질은 결국 데이터 요청(Data Call)의 품질에서 결정됩니다. 여기서 핵심은 한 가지입니다. 요청은 구체적이어야 합니다.
자주 보이는 실패 패턴부터 보겠습니다. "성과 좋은 사례 있으면 주세요." 이렇게 요청하면 대부분 좋은 답이 오지 않습니다. 답하는 쪽도 무엇을 줘야 할지 모르기 때문입니다.
좋은 데이터 요청은 다음 항목을 함께 묻습니다.
- 어떤 고객인가?
- 언제 수행했는가?
- 어떤 문제를 해결했는가?
- 몇 번 반복되었는가?
- 얼마나 줄었는가?
- 어떤 출처로 확인 가능한가?
- 고객 quote를 사용해도 되는가?
APMP 원문에 아주 좋은 예가 있습니다. POC가 "많이 해봤습니다(many times)"라고 답했다면 거기서 끝내면 안 됩니다. 몇 번인지 끝까지 물어야 합니다. "23 times"까지 가야 합니다. "비용을 크게 줄였습니다(significant reduction)"라고 답했다면, 얼마인지 물어야 합니다. "saved the customer $43 million"까지 파고들어야 합니다.
이 차이를 정리하면 다음과 같습니다.
| 흐릿한 표현 | 검증 가능한 증거 |
|---|---|
| 많이 해봤습니다 | 23회 수행했습니다 |
| 비용을 크게 줄였습니다 | 고객 비용을 4,300만 달러 절감했습니다 |
| 만족도가 높습니다 | 고객사 NPS 72점 |
| 빠르게 처리합니다 | 평균 처리시간 4시간에서 1시간으로 75% 단축 |
같은 회사, 같은 사례인데 평가위원이 받는 인상은 완전히 다릅니다. Data Call의 목적은 자료를 많이 받는 것이 아니라, 모호한 표현을 검증 가능한 증거로 바꾸는 것입니다.
6. 좋은 Proof Point의 세 가지 기준
APMP는 좋은 Proof Point가 통과해야 하는 기준을 세 가지로 정리합니다. 이 기준을 통과하지 못하면 아무리 자랑스러운 사례라도 제안서에서는 약해집니다.
| 기준 | 무엇을 본다 | 자가 점검 질문 |
|---|---|---|
| Persuasive | 고객 요구사항과의 연결성 | "이 증거가 이번 사업과 무슨 상관이 있는가?" |
| Tangible | 수치와 사실로 만질 수 있는가 | "얼마나 줄었고, 몇 번 수행했고, 얼마나 빨라졌는가?" |
| Credible | 검증 가능한 출처가 있는가 | "고객·보고서·시스템·인증으로 확인 가능한가?" |
이번 고객의 문제와 연결되지 않은 사례는 점수가 되지 않습니다. 아무리 멋진 성과라도 "그래서 이 사업과 무슨 상관이죠?"라는 질문에 답할 수 있어야 합니다. 그리고 추상적인 형용사가 아니라 손에 잡히는 숫자가 있어야 합니다. 마지막으로, 평가위원이 원하면 확인할 수 있는 경로가 있어야 합니다.
이 세 기준을 통과한 한 줄짜리 Proof Point가, 자랑하는 다섯 줄짜리 문장보다 훨씬 강력합니다.
7. 숫자는 보여주는 게 아니라 해석하는 것이다
여기서 한 발 더 들어가야 하는 부분이 있습니다. 숫자를 그대로 늘어놓는 것만으로는 부족합니다. 숫자는 해석되어야 합니다.
예를 들어 다음 두 문장을 비교해 보겠습니다.
① "처리 시간이 20% 줄었습니다."
② "처리 시간이 20% 줄어, 고객의 월말 마감 지연 리스크가 낮아졌습니다."
같은 숫자지만 의미가 다릅니다. ①번은 정보입니다. ②번은 고객 가치입니다. 평가위원이 점수를 주는 쪽은 ②번입니다. 평가위원이 알고 싶은 건 우리가 얼마나 잘했는지가 아니기 때문입니다. 평가위원이 알고 싶은 건 그 숫자가 자기 조직의 리스크·비용·일정·품질에 어떤 의미가 있는가입니다.
좋은 Proof Point는 숫자를 던지지 않습니다. 숫자에 의미를 붙여서 건네줍니다.
숫자만 있는 문장
→ 정보
숫자 + 고객 의미가 해석된 문장
→ Proof Point (= 고객 가치 + 증거)
8. Proof Point는 박스가 아니라 본문 전체에 깔려야 한다
한국 제안서에서 자주 보이는 또 다른 함정이 있습니다. 많은 제안서가 Proof Point를 한두 페이지의 박스 안에만 모아둡니다. "주요 실적", "수행 사례", "레퍼런스" 같은 별도 섹션을 만들어 두고, 본문에는 다시 일반적인 주장만 늘어놓는 식입니다.
APMP 원문은 정확히 이 점을 지적합니다. Proof Point는 callout box에만 들어가는 자료가 아닙니다. 다음 위치에 모두 들어가야 합니다.
- 기술 설명
- Benefit 설명
- 표와 그래픽의 캡션
- Action Caption
- Resume
- Past Performance
- 가격 내러티브
제안서 전체에 녹아 있어야 합니다. 평가위원 입장에서 보면 본문과 증거가 분리되어 있으면 "이 자료는 따로 챙겨온 거구나" 정도로 읽힙니다. 본문 문장 안에 사례·수치·출처가 같이 들어가야, 비로소 그 주장이 살아 있는 증거로 느껴집니다.
좋은 제안서는 증거가 본문 전체에 깔린 제안서입니다.
마무리
이번 EP10의 질문은 이것이었습니다.
우리의 주장은 무엇으로 증명되는가?
원문에 따라 답을 정리하면 이렇게 됩니다. Feature와 Benefit은 Claim입니다. 우리가 고객에게 좋아질 것이라고 말하는 내용입니다. Proof Point는 Evidence입니다. 그 Claim이 실제로 가능하다는 사실과 검증 가능한 증거입니다. 그리고 이 증거가 본문 전체에 깔리면 평가위원의 Confidence가 올라갑니다. 수행 리스크가 낮아 보이고, 선택 이유가 분명해 보입니다.
Claim : Feature / Benefit / 우리의 주장
+ Evidence : Proof Point / 사실과 검증 가능한 증거
= Confidence : 평가위원의 신뢰
마지막으로 피해야 할 실수도 한 번 더 정리하면 이렇습니다.
- RFP가 나온 뒤에야 증거를 찾기 시작하는 것
- Feature와 Benefit만 있으면 충분하다고 생각하는 것
- "만족도가 높다"처럼 일반적이고 검증 안 된 표현을 쓰는 것
- Proof Point를 별도 박스에만 넣고 본문에는 녹이지 않는 것
이 네 가지를 피하는 것만으로도 제안서의 설득력은 눈에 띄게 올라갑니다. 평가위원은 좋은 말을 믿지 않습니다. 평가위원은 검증 가능한 증거가 있는 주장을 믿습니다.
다음 EP11에서는 또 다른 질문이 기다리고 있습니다.
우리는 가격을 정하고 있는가, 이길 수 있는 가격대를 역산하고 있는가?
다음 글에서는 Competitive Price to Win 관점에서, 가격이 비용 계산을 넘어 고객과 경쟁 구도 속의 수주 작전으로 다뤄져야 하는 이유를 이어서 정리하겠습니다.


![[경제인뉴스] 낙후된 입찰 산업 구조에 등장한 AI 혁신, 클라이원트](/_next/image?url=https%3A%2F%2Fstorage.ghost.io%2Fc%2Ff6%2F4f%2Ff64fe473-5c2f-4f31-92ba-38e454e0581a%2Fcontent%2Fimages%2F2026%2F05%2F1--1-.jpg&w=3840&q=75)

