이번 편의 질문은 이것입니다. 제안요청서의 요구사항마다, 제안서의 몇 페이지에서 답했는지 바로 짚을 수 있습니까?
평가위원이 한쪽에는 우리 제안서를, 다른 쪽에는 제안요청서를 펼쳐 놓았다고 생각해 보세요. 요구사항 4.3.2에 이르러 페이지를 넘기기 시작합니다. 답은 아마 어딘가에 있을 겁니다. 두 섹션에 나뉘어 있을 수도 있고 고객의 표현 대신 우리 표현으로 쓰여 있을 수도 있습니다. 찾지 못하면 점수를 줄 수 없습니다. 컴플라이언스 매트릭스는 이런 순간을 막습니다. 모든 요구사항을 나열하고 제안서에서 그 답이 있는 곳을 가리키는 표입니다. 제안팀은 체크리스트이자 작업 계획으로 쓰고 평가위원은 지도로 씁니다.
이 시리즈는 APMP Foundation Study Guide에 요약된 APMP Body of Knowledge를 차례로 살펴봅니다. 1편에서는 Compliance와 Responsiveness의 차이를 설명하면서 컴플라이언스 매트릭스와 응답 매트릭스를 나란히 소개했습니다. 이번 편부터 전략을 실제 산출물로 바꾸는 Create Deliverables 파트가 시작되는데 그 첫 주제가 매트릭스 자체입니다. 무엇을 담는지, 언제 만드는지, 누가 쓰는지, 어떻게 정확하게 유지하는지를 다룹니다.
컴플라이언스 매트릭스란 무엇이고, 누구를 위한 것인가
Body of Knowledge는 컴플라이언스 매트릭스를 두 가지 일을 하는 도구로 설명합니다. 제안서 작성 과정을 관리하는 일과 고객에게 준수를 보여주는 일입니다. 두 일 모두 왼쪽에 요구사항, 오른쪽에 답이 있는 위치를 두는 단순한 구조에 기댑니다.
그래서 매트릭스는 두 독자를 위한 체크리스트입니다.
- 제안팀은 모든 요구사항에 답변, 담당자, 목차상의 자리가 있는지 확인합니다.
- 평가위원은 요구사항에서 우리 답변으로 헤매지 않고 바로 갑니다.
두 번째 독자는 과소평가하기 쉽습니다. 제안서 평가만 하는 평가위원은 드물고 많은 평가위원이 해당 사업의 기술 분야 전문가도 아닙니다. Study Guide는 평가위원의 일을 최대한 빠르고 쉽게 만들라고 조언하면서 제안요청서가 요구하지 않더라도 매트릭스를 넣으라고 합니다. 위치는 제안요청서 요구사항을 다루는 첫 섹션 앞입니다. 평가위원이 본문보다 지도를 먼저 만나게 됩니다.
발주처가 제안요청서와 함께 자체 매트릭스를 주는 경우도 있습니다. 거기 담긴 항목은 고객의 필수 요건으로 받아들이되 그것이 전부라고 여기지는 마세요. 이 점은 아래에서 다시 다룹니다.
매트릭스가 다뤄야 할 준수의 세 층위
'준수'는 흔히 "요구사항에 답했는가"로 좁혀지지만 Body of Knowledge는 더 넓게 봅니다. 제안서가 준수를 지키면 고객은 경험 많고 전문적이며 함께 일하기 편한 업체라는 인상을 받는데 그 인상은 세 층위에 달려 있습니다.
| 층위 | 다루는 것 | 점검 질문 |
|---|---|---|
| 제출 지침 | 제안서를 어떻게 내야 하는가 | 요구한 형식과 제출 방식을 따랐는가? 모든 질문에 답하고 모든 서식과 첨부를 채웠는가? 정확한 담당자에게, 정확한 곳으로, 마감 전에 내는가? |
| 요구사항 | 고객이 해 달라는 일 | 그 서비스를 실제로 제공할 수 있는가? 투입하겠다는 인력이 정말 참여할 수 있는가? 각 요구사항 뒤의 니즈에 답했는가? 충족할 수 없는 요구사항이 있는가? |
| 내부 준수 | 우리 조직의 규칙 | 법무 등 내부 요건을 충족했는가? 사업 기회를 CRM 등 정해진 곳에 등록했는가? 적절한 사람과 관리 단계가 참여했는가? 제출 승인을 받았는가? |
두 번째 층위만 추적하는 매트릭스로는 서식 하나가 빠지거나 업로드가 늦어 첫 번째 층위에서 질 수 있습니다. 아무도 승인하지 않은 제안서가 나가 세 번째 층위에서 질 수도 있습니다. 그래서 많은 팀이 제출 지침과 내부 승인을 별도의 행이나 같은 파일의 별도 시트로 관리해 제출 전에 확인할 곳을 하나로 만듭니다.
작성 전에 만든다
이 파트에서는 시점이 가장 중요한 원칙입니다. 컴플라이언스 매트릭스는 목차와 마찬가지로 제안요청서의 구조를 그대로 따라야 하고 목차와 함께, 내용 기획과 작성이 시작되기 전에 만들어야 합니다. 초안을 다 쓰고 나서 만드는 것은 벽을 다 세운 뒤에 평면도를 그리는 것과 같습니다. 문제가 어디 있는지는 알게 되지만 무엇을 옮기기엔 이미 비쌉니다.
일찍 만든 매트릭스는 색인이 할 수 없는 일을 합니다.
- 작성자의 실행 계획이 됩니다. 작성자마다 자기 섹션이 답해야 할 요구사항을 정확히 봅니다.
- 제안요청서를 묶음으로 나눕니다. 요구사항을 묶어 원가와 가격을 산정해야 하는 사람을 포함해 적절한 사람에게 보낼 수 있습니다.
- 책임을 분명히 합니다. 요구사항마다 이름이 붙으니 입찰 매니저나 제안 매니저가 후속 관리를 하기가 훨씬 쉬워집니다.
- 누락 가능성을 줄입니다. 빈틈이 아직 메울 시간이 있을 때 빈칸으로 드러납니다.
목차를 잡는 동안 행마다 물어볼 만한 질문이 있습니다. 어느 섹션에서 답하는가? 누가 쓰는가? 리뷰어는 어디서 확인하는가? 끝났다는 것을 어떻게 아는가?
컴플라이언스 매트릭스는 마지막에 붙이는 색인이 아닙니다. 처음부터 보고 짓는 설계도입니다.
제안요청서를 한 줄씩 분해한다
매트릭스는 흔히 분해(shredding)라고 부르는 작업에서 시작합니다. 제안요청서를 한 줄씩 읽으며 요구사항을 각각 별도의 행으로 떼어내는 일입니다. 영문 제안요청서라면 shall, must, will 같은 의무 표현이, 국내 제안요청서라면 "~하여야 한다", "~할 것", "제시할 것" 같은 표현이 신호입니다. '명시', '설명', '제출', '입증', '논의' 같은 지시 동사도 마찬가지입니다.
요구사항은 무리 지어 다니는 경우가 많습니다. 아래는 이 글을 위해 쓴 문단으로, 서비스 사업 제안요청서에서 흔히 볼 수 있는 형태입니다.
제안요청서 3.4 전환. 수행사는 전환을 이끌 핵심 인력을 명시하여야 하며, 기존 사업자로부터 서비스를 중단 없이 이관하는 계획을 설명하여야 한다. 제안사는 작성한 서식 C(전환 일정표)를 제출하여야 하며, 전환 기간 동안 주간 현황 보고서를 제공한다.
이 문단을 한 행으로 두면 일부만 답하기 쉽습니다. 작성자가 이관 계획은 자세히 쓰면서 인력은 지나가듯 언급하고 서식은 잊어버립니다. 분해하면 각각 배정하고 쓰고 확인할 수 있는 네 행이 됩니다.
| 제안요청서 번호 | 요구사항(고객 표현 그대로) | 제안서 섹션 | 담당자 | 상태 |
|---|---|---|---|---|
| 3.4 (가) | 전환을 이끌 핵심 인력을 명시 | 2.1 전환 조직 | 인사 담당 | 초안 |
| 3.4 (나) | 기존 사업자로부터 서비스를 중단 없이 이관하는 계획을 설명 | 2.2 전환 방안 | 솔루션 아키텍트 | 검토 중 |
| 3.4 (다) | 작성한 서식 C(전환 일정표)를 제출 | 첨부 C | 입찰 코디네이터 | 미착수 |
| 3.4 (라) | 전환 기간 동안 주간 현황 보고서를 제공 | 2.4 관리 및 보고 | 수행 PM | 초안 |
Study Guide는 분해의 이점을 두 가지 더 짚습니다. 작성자는 무엇에 답해야 하는지, 리뷰어는 무엇을 확인해야 하는지 정확한 목록을 얻습니다. 또 요구사항이 각자 행을 차지하므로 제안요청서 변경 공고나 목차 변경이 생겨도 표 전체를 다시 만들 필요 없이 몇 칸만 고치면 됩니다.
목록에 없는 요구사항을 찾는다
제안요청서의 번호 붙은 요구사항이나 발주처가 준 매트릭스에 모든 것이 들어 있다고 가정하지 마세요. Body of Knowledge는 요구사항이라고 표시되지 않은 요구사항도 있다고 경고합니다. 이런 요구사항은 사업 배경, 현황 및 문제점, 과업 범위의 한 문장 같은 본문 설명 속에 들어 있습니다. "현재 담당자가 매달 상당한 시간을 보고서 수작업 대사에 쓰고 있다" 같은 문장이 고객이 이 사업을 발주한 진짜 이유일 수 있습니다.
이런 요구사항을 찾아 답하면 준수의 빈틈을 메우는 것 이상의 효과가 있습니다. 문서 전체를 읽고 이해했다는 것을 고객에게 보여주면서 1편에서 다룬 Responsiveness로 한 걸음 나아갑니다.
정렬할 수 있는 스프레드시트로 관리한다
Body of Knowledge는 실용적인 이유로 스프레드시트를 권합니다. 매트릭스는 계속 바뀌기 때문입니다. 섹션 번호가 바뀌거나 변경 공고가 요구사항을 고치면 해당 칸을 고치고 다시 정렬하면 됩니다. 정렬을 바꾸면 한 표로 사람마다 다른 질문에 답할 수도 있습니다.
| 정렬 기준 | 답하는 질문 | 주로 묻는 사람 |
|---|---|---|
| 제안요청서 순서 | 고객의 요구사항이 고객의 순서대로 빠짐없이 추적되고 있는가? | 입찰 매니저, 최종 준수 검토자 |
| 제안서 목차 | 우리 목차의 각 부분은 무엇에 답해야 하는가? | 작성자, 볼륨 리드 |
| 담당자 | 각자 무엇을 언제까지 책임지는가? | 입찰 매니저, 각 작성자 |
| 상태 | 아직 미착수, 초안, 검토 중인 것은 무엇인가? | 입찰 매니저, 경영진 |
1편에서 기본 열 구성을 제안했습니다. 실무에서는 여기에 섹션별 분량 제한과 요구사항이 연결된 평가 항목을 더하는 팀이 많습니다. 작성자가 무엇을 써야 하는지와 그것이 어떻게 채점되는지를 함께 볼 수 있기 때문입니다.
고객의 번호와 표현을 따른다
평가위원이 매트릭스를 훨씬 쉽게 쓰게 만드는 습관이 두 가지 있습니다.
제안요청서의 번호 체계를 씁니다. 매트릭스에서도, 제안서 자체에서도요. Study Guide는 이것이 우리가 원하는 서술 흐름과 부딪힐 수 있다고 인정하지만 그래야 평가위원이 앞뒤로 오가지 않고 체크리스트를 따라가며 채점할 수 있습니다. 우리 이야기에 다른 흐름이 필요하다면 고객의 구조를 버리지 말고 그 구조 안에서 풀어내세요.
고객의 표현을 씁니다. 매트릭스에서 요구사항을 우리 용어로 바꿔 쓰지 말고 각 행을 제안요청서가 쓴 동사로 시작하세요. 작성자는 그 동사를 보고 평가위원이 기대하는 답의 종류를 알 수 있습니다.
| 제안요청서가 이렇게 말하면… | 평가위원이 기대하는 것은… |
|---|---|
| 명시(Identify) | 일반적인 설명이 아니라 구체적인 이름, 항목, 역할 |
| 설명(Describe) | 어떻게 작동하는지: 단계, 순서, 책임 |
| 제출(Provide) | 산출물: 서식, 계획서, 증빙을 첨부하거나 포함 |
| 입증(Demonstrate) | 작동한다는 증거: 성과, 레퍼런스, 증거 포인트 |
| 논의(Discuss) | 대안과 장단점을 포함한 우리의 판단 근거 |
우리 용어로 바꾼 소제목
"2.2 끊김 없는 마이그레이션 방법론" — 평가위원이 이것이 제안요청서 3.4 (나)에 대한 답이라는 것을 직접 알아내야 합니다.
고객의 용어를 쓴 소제목
"2.2 서비스 중단 없는 이관 계획 (제안요청서 3.4 나)" — 평가위원이 자기 표현 그대로의 요구사항과 그 번호를 바로 봅니다.
한 장의 매트릭스, 다섯 명의 독자
입찰 매니저만 여는 매트릭스는 반만 쓰이는 셈입니다. Body of Knowledge는 같은 문서를 팀원마다 어떻게 읽는지 정리합니다.
| 역할 | 매트릭스를 쓰는 방법 |
|---|---|
| 입찰 매니저·제안 매니저 | 제안 내용의 마스터 계획이자, 요구사항마다 원가·가격 산정이나 답변을 맡을 사람에게 보내는 도구 |
| 볼륨 리드 | 자기 볼륨의 요구사항이 모두 다뤄졌는지 보는 체크리스트 |
| 작성자 | 각 섹션에 무엇을 써야 하는지 알려주는 안내서 |
| 리뷰어 | 각 섹션에 무엇이 있어야 하는지 정의한 평가 도구 |
| 경영진 | 계획과 그 뒤의 전략을 한눈에 보는 개요 |
Study Guide의 요약대로, 그래서 매트릭스는 답변 배정표 역할도 합니다. 입찰 매니저는 이 표로 여러 기여자에게 일을 나눠주고 하나하나 챙깁니다.
제출할 때까지 최신으로 유지한다
매트릭스는 기획 단계에서 만들지만 정확하게 유지하는 일은 제안서가 나갈 때까지 계속됩니다. Body of Knowledge는 갱신이 필요한 변화를 이렇게 정리합니다.
- 목차: 섹션의 이름, 번호, 순서, 분량 배정이 바뀔 때.
- 팀: 섹션 작성자가 바뀔 때.
- 제안요청서: 지침, 평가 기준, 요구사항, 변경 공고가 바뀔 때.
팀원 한 명에게 매트릭스 갱신 책임을 분명히 맡기세요. 낡은 매트릭스는 팀이 계속 믿고 움직이기 때문에 없는 것보다 나쁩니다. 리뷰, 컬러 팀 점검, 최종 준수 확인 모두 기준이 되는 표만큼만 정확합니다.
탈락 사유 항목과 부분 준수 행을 챙긴다
매트릭스를 확정하기 전에 특히 살펴야 할 행이 두 종류 있습니다. 첫째, 탈락 사유로 표시된 요구사항입니다. 하나라도 놓치면 제안서가 아예 평가되지 않을 수 있으니 분명히 표시하고 가장 먼저 확인하세요. 둘째, '부분 준수'나 '미준수'로 표시된 행입니다. 하나씩 고객의 요구사항과 대조해 솔루션이나 답변을 완전 준수에 더 가깝게 바꿀 수 있는지 따져 보세요. 남는 빈틈을 정직하게 설명하는 방법은 1편에서 다뤘습니다.
제출용 버전: 응답 매트릭스, 조견표, 그리고 설득의 도구
팀이 쓰는 매트릭스와 제출하는 표는 같은 문서가 아닙니다. 제출용 버전은 Body of Knowledge에서 응답 매트릭스라고 부르고 실무에서는 요구사항 조견표나 대비표라고도 부릅니다. 담당자와 상태는 빼고 평가위원에게 필요한 요구사항, 제안요청서 번호, 우리가 답한 위치만 남깁니다. 분량 제한 때문에 별도의 표를 넣을 여유가 없다면 1편에서 설명한 대로 같은 참조를 소제목에 넣을 수 있습니다.
제안요청서가 이 표의 양식을 정해 두었다면 그대로 따르세요. 하지만 Study Guide에 따르면 대부분의 제안요청서는 양식을 정하지 않으며 그 덕분에 이 표가 위치를 가리키는 것 이상의 일을 할 수 있습니다. 예를 들어 주요 요구사항 옆에 고객에게 주는 효과를 짧게 적는 열을 두면 무미건조한 색인이 윈 테마가 한 번 더 드러나는 자리가 됩니다.
| 제안요청서 번호 | 요구사항 | 답변 위치 | 고객에게 주는 의미 |
|---|---|---|---|
| 3.4 (나) | 서비스를 중단 없이 이관하는 계획 설명 | 2.2절, 14–17쪽 | 기관별 단계 전환과 단계마다 원복 계획으로 민원 창구가 계속 열려 있음 |
| 5.1 | 24시간 서비스 데스크 운영 | 3.1절, 22–24쪽 | 주간과 야간을 한 팀이 맡아, 야간 별도 인력에게 문의가 넘어가지 않음 |
추가 열은 짧고 사실적으로 쓰세요. 모든 평가위원이 반드시 쓰는 표에 들어가니 귀한 자리지만 표를 훑어보기 어렵게 만들어서는 안 됩니다.
흔한 실수
- 매트릭스를 마지막에 만든다. 그때는 빈틈을 기록할 수만 있을 뿐 막을 수 없습니다.
- 고객이 준 목록을 믿는다. 제안요청서의 번호 붙은 요구사항과 발주처가 준 매트릭스의 항목 수는 실제 요구사항 수와 다를 수 있습니다. 본문 설명도 읽으세요.
- 갱신하지 않는다. 변경 공고가 오고 목차와 작성자가 바뀌는데 아무도 표를 고치지 않습니다. 그 순간부터 팀은 잘못된 계획으로 일합니다.
- 고객의 표현을 바꿔 쓴다. 우리 용어가 더 나을 수 있어도 평가위원의 체크리스트와 맞춰 보기 어려워집니다.
- 준수에서 멈춘다. Body of Knowledge는 Compliance와 Responsiveness가 중요하지만 고객이 따지는 전부는 아니라고 분명히 말합니다. 완벽하게 준수한 제안서에도 차별화 요소, 효과, 이길 수 있는 가격이 필요합니다.
다음 제안서를 위한 체크리스트
- 제안요청서 전체를 읽습니다. 무엇을 만들기 전에 사업 배경과 과업 범위의 설명까지 읽습니다.
- 한 줄씩 분해합니다. 의무 표현이나 지시 동사마다 행 하나, 제안요청서의 번호와 표현은 그대로.
- 본문에서 찾은 숨은 요구사항을 더하고 탈락 사유 항목을 표시합니다.
- 목차와 함께 매트릭스를 만듭니다. 작성 전에, 모든 행에 제안서 섹션, 담당자, 상태를 붙입니다.
- 세 층위를 모두 다룹니다. 제출 지침, 요구사항, 내부 승인.
- 스프레드시트로 관리하고 역할마다 필요한 정렬 화면을 공유합니다.
- 갱신 담당자를 한 명 정해 목차, 팀, 제안요청서가 바뀔 때마다 고치게 합니다.
- 확정 전에 부분 준수와 미준수 행을 모두 다시 검토하고 메울 수 있는 것은 메웁니다.
- 응답 매트릭스(조견표)를 제출합니다. 요구사항에 답하는 첫 섹션 앞에 두거나 소제목에 제안요청서 번호를 넣습니다. 고객이 양식을 주었다면 그대로, 없다면 짧은 효과 열을 더합니다.
Contrl에서는
컴플라이언스 매트릭스는 제안요청서를 분해하고 요구사항마다 어디서 답할지 정하는 첫 작업에 가장 오래 걸립니다. Contrl에 제안요청서를 올리면 요구사항, 제안서 목차, 평가 기준을 추출하고 요구사항마다 그 목차의 섹션에 연결하므로 한 페이지도 쓰기 전에 매트릭스가 생깁니다. 슬라이드가 작성되면 각 페이지가 자신이 답하는 제안요청서 요구사항을 밝힙니다. 그래서 요구사항과 페이지의 연결은 누군가 잊지 않고 고쳐야 하는 별도의 표가 아니라 페이지 위에 그대로 남습니다.
다음 편 예고
매트릭스를 보면 숫자를 요구하는 요구사항까지 모든 요구사항이 어디서 답해질지 알 수 있습니다. 13편은 원가·가격 데이터(Cost and Pricing Data)를 다룹니다. 가격 뒤에는 무엇이 있는지, 공공과 민간 고객이 그것을 보자고 하는 방식은 왜 그렇게 다른지, 가격 산정 논리를 보여주는 것이 왜 제안서 전체의 신뢰를 높이는지 살펴봅니다.
이 글은 APMP Body of Knowledge를 요약한 APMP Foundation Study Guide 4.2판(© 2025 APMP)을 바탕으로 한 독립적인 학습용 해설입니다. 원문을 풀어 쓰고 해설한 것으로, APMP의 승인을 받은 글이 아닙니다. 제안요청서 예시 문단과 분해한 행, 정렬 기준표와 지시 동사표, 소제목 비교, 숨은 요구사항 문장, 효과 열 예시는 이 글을 위해 쓴 것이며 예시입니다. 공식 원문과 자격 정보는 apmp.org에서 확인하세요.