이번 편의 질문입니다. 제안서에는 "할 수 있다"고 썼습니다. 그런데 증명할 수 있나요?
어느 제안서나 위험을 줄이고 더 빨리 끝내며 품질을 높이고 비용을 아끼겠다고 약속합니다. 평가위원은 하루 종일 모든 입찰자에게서 이런 약속을 읽다 보니 곧이곧대로 믿지 않는 법을 배웠습니다. 평가위원은 증거를 보고 마음을 바꿉니다. 이 증거를 APMP Body of Knowledge에서는 증거 포인트(Proof Point)라고 부릅니다. 우리가 제시한 기능이 실제로 작동하고 효과가 달성 가능하다는 것을 보여주는 검증 가능한 사실입니다. 한 줄로 줄이면 기능과 효과는 주장이고 증거 포인트는 그 주장을 믿을 이유입니다.
이 시리즈는 APMP Foundation Study Guide에 요약된 APMP Body of Knowledge를 하나씩 짚어봅니다. 9편에서는 기능이 어떻게 효과가 되고 효과가 어떻게 차별화 요소가 되는지 다뤘습니다. 이번 편은 그 주장들에 필요한 마지막 조각을 채웁니다.
증거 포인트란 무엇인가
Body of Knowledge는 증거 포인트를 솔루션의 기능과 효과에 대해 검증 가능한 근거를 제공하는 사실로 정의합니다. 핵심 단어는 두 개입니다. 형용사나 슬로건이 아니라 사실이어야 하고 평가위원이 확인하고 싶다면 확인할 수 있도록 검증 가능해야 합니다.
증거 포인트는 윈 테마와 차별화 요소를 떠받칩니다. 고객에게 우리를 골라야 하는 이유를 말해도 독립적인 무언가가 뒷받침하기 전까지 그 이유는 모두 주장일 뿐입니다. Study Guide는 그 뒷받침이 없으면 평가위원이 기능이 검증된 것인지, 효과가 정말 달성될지 의심하기 시작한다고 경고합니다. 의심은 위험으로 인식되고 위험은 감점으로 이어집니다.
| 요소 | 말하는 것 | 예시 (정보시스템 운영 전환 사업) |
|---|---|---|
| 기능 | 우리가 하거나 제공하는 것 | 기관별로 한 곳씩 단계적으로 전환하고, 단계마다 원복 계획을 둔다 |
| 효과 | 고객이 얻는 것 | 새 시스템이 오픈되는 동안에도 서비스가 멈추지 않는다 |
| 증거 포인트 | 고객이 믿어야 하는 이유 | 2021년 이후 공공기관 14곳 전환, 약속한 중단 시간을 넘긴 사례 0건. 각 기관의 검수 보고서로 확인 가능 |
앞의 두 줄은 어느 입찰자나 쓸 수 있지만 세 번째 줄은 그 일을 실제로 해본 회사만 쓸 수 있습니다. 그래서 증거 포인트가 차별화가 됩니다.
기능과 효과만 적으면 평가위원에게 믿어달라고 부탁하는 셈입니다. 증거 포인트를 붙이면 믿을 이유가 생깁니다.
증거 포인트가 윈 테마를 완성한다
Body of Knowledge에 분명하게 나와 있듯이 효과적인 윈 테마에는 효과, 기능, 그리고 하나 이상의 증거 포인트가 들어 있습니다. 세 번째가 빠지면 평가위원은 앞의 두 가지를 우리 말만 듣고 믿어야 합니다. Study Guide의 설명대로라면 평가위원은 그 대신 솔루션의 약점을 짚고 수행 위험을 보게 될 것입니다.
그래서 증거를 모으는 일은 행정 업무로 넘길 수 없는 전략 업무입니다. 입찰 또는 제안 책임자는 캡처 매니저(수주 책임자)와 함께 수주 전략을 합의하고 그 전략에 어떤 증거가 필요한지 정해야 합니다. 순서가 중요합니다.
- 어디서 이길 것인가? 고객의 우선순위와 그 위에서 우리가 가진 강점.
- 평가위원이 기억할 윈 테마는 무엇인가?
- 각 테마를 믿게 하려면 무엇이 필요한가? 평가위원이 봐야 할 구체적인 사실.
- 그 사실은 어디에 있고 누가 가지고 있는가?
4단계로 바로 건너뛰는 팀은 가진 사례를 전부 모아놓고 나중에 끼워 넣으려 합니다. 그렇게 만든 제안서는 증거로 빽빽해도 어떤 메시지도 뒷받침하지 못합니다. 증거는 전략에서 거꾸로 찾아 들어가야 합니다.
Study Guide에 따르면 특히 이미 거래하고 있거나 거래하고 싶은 고객에게 가장 가치 있는 증거는 두 가지, 고객의 칭찬과 발주처의 공식 수행 평가입니다. 둘 다 고객 쪽에서 나온 것이라 쉽게 무시할 수 없습니다.
증거 포인트는 어디에서 나오는가
증거 포인트 대부분은 비슷한 일을 어떻게 수행했는지를 보여줍니다. Body of Knowledge에 나열된 다양한 형태를 무엇을 증명하는지에 따라 묶으면 다음과 같습니다.
| 유형 | 예시 | 증명하기 좋은 것 |
|---|---|---|
| 성과 데이터 | 유사 사업의 프로젝트 지표, SLA 달성, 납기, 품질 지표 | 기능이 작동하고 효과가 달성 가능하다는 것 |
| 사례 | 사례 연구, 성공 사례, 교훈 | 이 고객과 비슷한 문제를 이해하고 있다는 것 |
| 고객의 목소리 | 인용문, 추천 문구, 감사 인사, 수행 평가 | 평가위원과 비슷한 누군가가 만족했다는 것 |
| 외부 인정 | 수상, 업계 평가 등급, 인증, 외부 감정 | 편향 없는 제3자가 판단한 경험과 품질 |
| 규모 | 사업부, 지역, 자회사, 사업 전체를 합산한 데이터 | 수행할 수 있는 규모와 체력 |
| 벤치마크 | 업계 기준과 비교한 결과 | 기준을 넘어선다는 것. 기준만 맞추는 경쟁사를 은근히 견제(고스팅)합니다 |
| 회복 | 고객이 인정한, 우리가 해결한 문제 | 일이 틀어졌을 때 믿을 수 있다는 것 |
Study Guide 기준으로 가장 이상적인 출처는 비슷한 고객에게 성공적으로 제공한 비슷한 솔루션입니다. 닮을수록 평가위원이 상상해야 할 부분이 줄어듭니다.
잘 수습한 문제도 증거다
마지막 줄에 놀라는 팀이 많습니다. 성공 사례 말고도 증거 포인트가 될 수 있는 이야기가 있기 때문입니다. Body of Knowledge에 따르면 문제를 정면으로 마주한 끝에 불만을 가진 고객과 오래가는 관계를 만든 이야기는 설득력이 매우 강할 수 있습니다.
이유는 현실적입니다. 어떤 수행사든 가끔은 좋지 않은 결과를 냅니다. 그럴 때 평가위원은 문제가 있었다는 사실보다 그다음의 대응을 봅니다. 기록이 깨끗하기만 하면 압박 속에서 어떻게 행동하는지 보여줄 것이 없습니다. 그보다는 문제를 제대로 해결한 빠른 조치와 해결되었다고 동의하는 고객의 확인이 더 좋게 비칠 수 있습니다.
예를 들어 레거시 연계 장애로 전환이 한 주말 늦어진 상황을 떠올려 보세요. 우리 팀은 네 시간 안에 서비스를 복구하고 남은 전환 계획을 고객과 함께 다시 짰습니다. 그 고객이 나중에 계약을 연장하고 추천서까지 써줬다면 그 이야기는 어떤 성공 사례도 증명하지 못하는 것을 증명합니다. 평가위원은 문제가 한 번도 없는 회사보다 문제가 생겼을 때 책임지는 회사를 찾습니다.
제안요청서가 나오기 전에 시작한다
제안요청서가 공고되면 팀은 요구사항 분석, 목차 구성, 원고 작성, 리뷰, 수정을 한꺼번에 해야 합니다. 그때 "비슷한 사례 있나요?"라고 물으면 대개 답이 늦거나 막연하게 돌아옵니다. 그래서 Body of Knowledge는 수주 전략을 이해하는 즉시, 고객이 제안요청서를 내기 훨씬 전에 증거 포인트를 쌓아두라고 조언합니다.
일찍 모으는 데 도움이 되는 세 가지 습관이 있습니다.
- 유형의 균형을 맞춥니다. 추천 문구만 열 개 모으지 마세요. 이야기의 각 부분을 어떤 종류의 증거가 가장 잘 뒷받침하는지 따져봅니다.
- 같은 발주처의 과거 공고를 읽습니다. 같은 발주처는 입찰마다 같거나 비슷한 정보를 요구하는 경우가 많습니다. 나라장터에서 과거 공고와 제안요청서를 모아 반복해서 요구하는 것(실적, 성과 지표, 인력 자격)을 정리하고 그 증거를 지금 모으기 시작합니다. 그 패턴 자체가 고객 인텔리전스입니다.
- 빈틈을 찾습니다. 제안하려는 기능 뒤에 증거가 없다면 일찍 알아야 캡처 매니저가 손을 쓸 수 있습니다. 예를 들어 그 일을 해본 컨소시엄 파트너를 더하는 식입니다.
수집은 제안요청서가 나온 뒤에도 이어집니다. 이 시점에는 요구사항이 확정되고 수주 전략도 더 날카로워집니다. 이때의 데이터 콜은 제안요청서가 구체적으로 요구하는 것을 채워 신뢰성, 설득력, 요구사항 충족을 높입니다.
구체적인 답을 받아내는 데이터 콜
증거는 데이터에서, 데이터는 사람에게서 나옵니다. 그 사람이 바로 PM, 수행 인력, 재무팀, 그리고 컨소시엄 파트너입니다. 이들에게 보내는 요청을 Body of Knowledge에서는 데이터 콜(data call)이라고 부르며 증거의 품질은 요청의 품질에 달려 있습니다.
"좋은 성공 사례 있으면 보내주세요"라고 하면 받는 게 별로 없습니다. 답하는 사람이 무엇이 필요한지 모르기 때문입니다. 쓸모 있는 데이터 콜은 네 가지를 명시합니다.
- 답할 책임이 있는 담당자(POC)
- 정확히 필요한 데이터: 어떤 사업, 어떤 지표, 어떤 기간
- 제출 방법에 대한 구체적인 안내: 양식, 단위, 근거 문서
- 분명한 마감일
이 글을 위해 쓴 예시입니다.
데이터 콜: 서비스데스크 전환, ○○보건기관 입찰
담당: 2024년 지자체 서비스데스크 사업 수행 PM. 목요일 오후 5시까지 보내주세요.
1. 오픈 후 첫 90일 동안 처리한 요청 건수와 최초 응답 시간 중앙값 (월간 SLA 보고서 기준, 보고서 첨부)
2. 전환 중 서비스 중단이 있었다면 날짜, 시간, 원인, 해결 방법
3. 2024년과 2025년 고객 만족도 점수 (조사명, 척도, 응답자 수)
4. 고객 측 PM을 레퍼런스로 밝혀도 되는지, 3월 12일 감사 메일을 인용해도 되는지
좋은 요청을 보내도 답은 자주 너무 일반적으로 돌아옵니다. Study Guide는 답이 구체적이 될 때까지 계속 물으라고 조언합니다. "많이"에는 횟수가, "크게 절감"에는 금액이 필요합니다. 결국 파고들어야 하는 사람은 담당자이므로 담당자와 좋은 협업 관계를 맺어두면 큰 차이가 납니다.
| 담당자의 첫 답 | 한 번 더 물은 뒤 |
|---|---|
| "전환은 많이 해봤습니다." | 2021년 이후 14개 기관 전환, 약속한 중단 시간을 넘긴 사례 0건 |
| "응대가 빠릅니다." | 2025년 6,200건 기준 최초 응답 시간 중앙값 38분, 고객사 SLA 보고서 기준 |
| "고객 만족도가 아주 높습니다." | 고객사 연례 조사에서 3년 연속 5점 만점에 4.6점 (응답자 410명) |
| "비용을 많이 줄였습니다." | 통합 후 라이선스 비용 31%, 연간 약 120만 달러 절감, 고객사 예산 보고서 기준 |
점검 기준: 설득력, 구체성, 신뢰성
Body of Knowledge 기준으로 모든 증거 포인트는 세 가지 성질을 갖춰야 합니다. 아무리 자랑스러운 성과라도 하나라도 빠지면 제안서에서는 약해집니다.
| 기준 | 뜻 | 던져볼 질문 |
|---|---|---|
| 설득력 (Persuasive) | 이번 고객의 목표와 요구사항을 충족하거나 넘어서는 기능과 효과를 뒷받침한다 | "그래서 이게 우리 사업과 무슨 상관이죠?"에 답할 수 있는가? |
| 구체성 (Tangible) | 사실과 수치로 정량화되어 있다 | 얼마나, 몇 번, 얼마나 빨리, 어느 기간 동안? |
| 신뢰성 (Credible) | 고객이 검증할 수 있는 근거가 있다 | 평가위원이 물으면 누가 또는 무엇이 확인해줄 수 있는가? |
정확하고 확인할 수 있게
어림수 대신 정확한 숫자를 씁니다. "1시간 이내"보다 "38분"이 더 믿음이 갑니다. 고객이 증거 포인트를 검증할 수 있어야 하므로 제안서에 각 증거의 출처를 밝히고 구체적인 고객 레퍼런스와 인용을 제시해야 합니다. 고객의 말을 직접 인용할 때는 반드시 먼저 허락을 받습니다. Body of Knowledge가 제시하는 출처는 다음과 같습니다.
- 이름이 밝혀진 사업, 사례 연구, 그리고 거기서 얻은 교훈
- 고객이 직접 확인할 수 있는 보고 도구
- 업계 평가, 수상, 등급 같은 독립적인 제3자
- 회사의 규모와 체력을 보여주는 합산 데이터
- 업계 기준을 충족하거나 넘어선다는 비교
- 구체적인 성취로 이어진 결과
합산할 때는 무엇을 셌는지 밝힙니다. 사업부, 지역, 자회사, 사업별 결과를 합쳐 규모를 보여주는 것은 정당한 방법이지만 그 합계에는 근거가 있어야 합니다.
숫자가 무엇을 뜻하는지 설명한다
숫자만 있으면 정보일 뿐입니다. Study Guide는 숫자의 의미를 설명하고 데이터를 성취에 맞추라고 합니다. 절감한 비용, 낮춘 가격, 높인 효율, 받은 상, 오른 만족도, 줄어든 대기 시간 같은 것들입니다. 두 문장을 비교해 보세요.
숫자만
"송장 처리 시간이 20% 줄었습니다."
숫자와 의미
"송장 처리 시간이 20% 줄어, 재무팀이 월 마감을 이틀 앞당기고 지연 지급 가산금을 더 이상 내지 않게 되었습니다."
평가위원은 우리가 얼마나 잘했느냐보다 그 결과가 자기 조직의 위험, 비용, 일정, 품질에 무엇을 뜻하느냐를 묻습니다. 거기에 답하면 숫자는 증거가 붙은 효과가 됩니다.
증거 라이브러리를 만들고 최신으로 유지한다
증거 포인트 상당수는 여러 입찰에서 다시 쓸 수 있습니다. 그래서 매번 처음부터 다시 찾는 팀은 시간을 크게 낭비하고도 가장 좋은 증거를 놓칩니다. Body of Knowledge는 증거 포인트 데이터를 저장소에 모아두되 정기적으로, 그리고 무언가 바뀔 때마다 갱신하라고 권합니다. 숫자는 낡고 담당자는 떠나며 고객 인용 허락은 다시 받아야 할 수도 있습니다.
항목마다 최소한 사업명, 고객, 범위, 측정한 결과, 기간, 근거 문서, 확인해줄 사람, 인용이나 이름 사용 가능 여부를 기록합니다. 어떤 조직은 재사용 콘텐츠를 최신으로 유지하는 일만 맡는 지식 관리자(Knowledge Manager)를 둡니다. 이 사람은 고객 디브리핑에서 얻은 교훈, 즉 평가위원이 어떤 증거에 설득되었고 어떤 증거에는 그렇지 않았는지도 되돌려줄 수 있습니다. 그러면 자료 창고가 학습 시스템이 되어 제안서를 할 때마다 더 설득력 있게 만듭니다.
피해야 할 다섯 가지 실수
- 제안요청서를 기다린다. 그때는 빈틈을 찾을 시간도, 메울 시간도 없습니다. 공고 전에 우리 회사와 컨소시엄 파트너에게 상세한 데이터 콜을 보냅니다.
- 기능에 영업을 맡긴다. 기능은 가득한데 그 기능이 작동한다는 증거는 부족한 제안서가 많습니다. 검증된 성취가 있어야 신뢰가 생깁니다.
- 효과만으로 충분하다고 생각한다. 그 효과가 이전에 실제로 일어났음을 보여주지 않으면 고객은 효과가 실현될 거라고 믿지 않을 수 있습니다. 가장 강한 증거 포인트는 우리의 효과가 경쟁사보다 낫다는 것까지 보여줍니다.
- 일반적인 문장을 그대로 둔다. "고객 만족도가 높습니다"라고 쓰면 "얼마나요?"라는 물음이, "인력을 빠르게 투입할 수 있습니다"라고 쓰면 "증명해 보세요"라는 요구가 돌아옵니다. 평가위원이 "누가 그래요?"라고 물을 수 있다면 아직 증거 포인트가 아닙니다.
- 증거를 강조 박스에 가둔다. 가장 좋은 증거는 강조 박스로 돋보이게 하되 거기에만 두지 마세요.
마지막 실수는 "주요 실적"이나 "수행 사례" 섹션을 따로 두고 본문의 나머지는 근거 없는 주장으로 채운 제안서에서 흔히 보입니다. Body of Knowledge 기준으로 증거 포인트는 기능·효과 표, 기술 서술, 그림 설명 캡션, 그래픽, 이력서, 수행 실적, 그리고 가격 설명까지 문서 전체에 흘러야 합니다.
따로 떨어진 증거
"검증된 방법론으로 전환 위험을 최소화합니다." (세 섹션 뒤의 실적 표에 과거 사업이 나열되어 있다.)
본문에 녹아든 증거
"단계적 전환으로 전환 기간에도 서비스가 멈추지 않습니다. 2021년 이후 14개 기관을 전환하면서 약속한 중단 시간을 넘긴 적이 한 번도 없습니다. 2024년 지자체 사업의 고객 측 PM이 레퍼런스로 확인해 드릴 수 있습니다."
다음 제안서를 위한 체크리스트
- 윈 테마와 차별화 요소 속 주장을 나열하고 각각 옆에 평가위원이 믿게 만들 사실을 적습니다.
- 캡처 매니저와 함께 수주 전략에 필요한 증거를 제안요청서 전에 정합니다.
- 같은 발주처의 과거 공고를 검토하고 늘 요구하는 증거부터 모읍니다.
- 증거 유형의 균형을 맞춥니다. 성과 데이터, 고객의 목소리, 외부 인정, 규모, 벤치마크, 회복 사례.
- 데이터 콜을 보냅니다. 담당자, 필요한 데이터, 안내, 마감일을 담아 사내와 컨소시엄 파트너에게 보내고 막연한 답이 숫자가 될 때까지 다시 묻습니다.
- 증거 포인트마다 점검합니다. 설득력, 구체성, 신뢰성. 정확한 숫자를 쓰고 출처를 밝히며 고객 인용은 허락을 받습니다.
- 숫자마다 이 고객의 위험, 비용, 일정, 품질에 무엇을 뜻하는지 설명합니다.
- 모든 섹션에 증거를 녹이고 가장 좋은 것은 강조 박스로 돋보이게 합니다.
- 입찰과 디브리핑이 끝날 때마다 증거 라이브러리를 갱신합니다.
Contrl에서는
AI는 우리 회사의 경험에 대해 자신감 있는 문장을 쓸 수는 있지만 그것을 증명하는 사실을 지어낼 수는 없습니다. 증거는 우리 회사의 기록에서 나와야 합니다. Contrl에서는 전략 인터뷰에서 우리 회사에 대해 알려준 수치가 윈 테마의 강점이 됩니다. 어떤 페이지가 여전히 "풍부한 경험"처럼 막연하게 말한다면 실제 수치를 담은 채팅 피드백 한 줄로 그 페이지를 다시 쓸 수 있습니다. 각 페이지에는 대응하는 제안요청서 요구사항도 표시되므로 어떤 주장이 어디에 있는지 보고 모든 주장 옆에 증거가 붙어 있는지 확인할 수 있습니다.
다음 편 예고
증거는 평가위원이 우리가 해낼 수 있다고 믿게 만들고 가격은 평가위원이 우리를 고를 수 있는지를 정합니다. 11편은 Competitive Price to Win을 다룹니다. 우리는 가격을 정하고 있나요, 아니면 이길 수 있는 가격을 역산하고 있나요?
이 글은 APMP Body of Knowledge를 요약한 APMP Foundation Study Guide 4.2판(© 2025 APMP)을 바탕으로 한 독립적인 학습용 해설입니다. 원문을 풀어 쓰고 해설한 것으로, APMP의 승인을 받은 글이 아닙니다. 기능·효과·증거 예시, 증거 유형 분류, 회복 시나리오, 데이터 콜 예시, 막연한 답과 구체적인 답 비교표, 송장 처리 예시, 전후 비교 문단은 이 글을 위해 쓴 것이며, 수치는 예시입니다. 공식 원문과 자격 정보는 apmp.org에서 확인하세요.