새로운 사업 공고가 올라왔습니다.
RFP를 다운로드합니다.
187페이지.
사업 배경부터 추진 목적, 과업 범위, 기능 요구사항, 보안 지침, 수행 조건, 평가 기준까지 빼곡하게 들어 있습니다.
제안팀은 이 문서를 읽기 시작합니다.
중요한 부분에는 형광펜을 긋습니다.
엑셀을 하나 열어 요구사항을 옮깁니다.
앞에서 본 내용과 비슷한 문장이 뒤에서 다시 나오면 두 페이지를 번갈아 확인합니다.
그리고 누군가 묻습니다.
“이거 AI한테 읽히면 되는 거 아닌가요?”
물론 가능합니다.
200페이지를 넣고 이렇게 물어볼 수 있습니다.
“이 RFP를 요약해줘.”
몇 분도 걸리지 않습니다.
사업 목적, 주요 과업, 일정, 예산, 핵심 요구사항까지 꽤 훌륭하게 정리합니다.
그런데 제안팀에게 정말 필요한 것이 ‘요약’일까요?
제안팀은 RFP를 요약하기 위해 읽지 않습니다
제안서를 준비하면서 RFP를 읽는 이유는 명확합니다.
무엇에 답해야 하는지 찾기 위해서입니다.
예를 들어 RFP 42페이지에 이런 내용이 있다고 해보겠습니다.
“시스템은 장애 발생 시 서비스 연속성을 확보할 수 있도록 이중화 구성을 고려하여야 한다.”
그리고 96페이지에는 이런 내용이 있습니다.
“장애 대응 및 복구 방안을 구체적으로 제시한다.”
142페이지 평가기준에는 다시 등장합니다.
“시스템 안정성 및 장애 대응 체계의 적정성 — 10점.”
사람이 읽으면 이 세 문장이 연결되어 있다는 것을 알 수 있습니다.
42페이지는 요구사항이고,
96페이지는 제안서에 작성해야 할 내용이며,
142페이지는 그 내용을 얼마나 중요하게 평가하는지 알려줍니다.
문장은 세 군데에 흩어져 있지만 제안팀에게는 하나의 문제입니다.
“장애 대응을 어떻게 제안해서 10점을 받을 것인가?”
RFP를 읽는다는 것은 결국 이런 관계를 찾아내는 일입니다.
그래서 AI에게도 ‘읽는 목적’이 필요합니다
AI에게 200페이지를 전달하고 단순히 내용을 요약하게 하는 것과,
수주에 필요한 정보를 찾아달라고 하는 것은 다른 작업입니다.
수주 AI가 RFP를 읽는다면 문서를 몇 페이지로 줄이는 것에서 끝나서는 안 됩니다.
문서 곳곳에 흩어진 정보를 찾아 구조화해야 합니다.
무엇을 해야 하는가.
기능·성능·보안·운영 등 고객이 요구한 사항을 찾습니다.
무엇을 반드시 지켜야 하는가.
사업 기간, 인력 조건, 인증, 제출 규격처럼 놓치면 안 되는 조건을 구분합니다.
무엇을 제안해야 하는가.
제안서에서 구체적으로 설명해야 할 항목을 찾아냅니다.
무엇으로 평가받는가.
평가항목과 배점, 정성·정량 기준을 연결합니다.
이렇게 바뀌면 200페이지짜리 문서는 더 이상 하나의 긴 문서가 아닙니다.
제안팀이 실제로 대응해야 하는 ‘수백 개의 문제’로 바뀝니다.
여기서부터 AI가 할 수 있는 일이 달라집니다
RFP 안의 정보가 구조화되면 그다음 질문을 할 수 있기 때문입니다.
이 요구사항은 제안서 어디에서 대응해야 하는가.
비슷한 요구사항이 다른 페이지에도 존재하는가.
배점이 높은 평가항목과 연결된 요구사항은 무엇인가.
우리가 반드시 준비해야 하지만 아직 대응하지 않은 항목은 무엇인가.
그리고, 이 요구사항을 증명할 우리 회사의 실적과 기술은 무엇인가.
지난 1화에서 이야기했던 ‘찾는 AI’와 ‘연결하는 AI’가 이때부터 일을 시작할 수 있습니다.
AI가 RFP를 제대로 읽어야 그다음 AI도 제대로 움직일 수 있는 셈입니다.
200페이지를 20페이지로 줄이는 것보다 중요한 것
RFP 요약은 분명 유용합니다.
사업을 빠르게 파악하고 전체적인 방향을 이해하는 데 큰 도움이 됩니다.
하지만 실제 제안 업무에서는 한 단계가 더 필요합니다.
200페이지를 20페이지로 줄이는 것이 아니라,
200페이지 안에 숨어 있는 수백 개의 의사결정 포인트를 찾아내는 것.
이 차이는 꽤 큽니다.
요약 과정에서는 중요도가 낮다고 판단해 생략한 한 문장이 실제로는 제안서의 필수 요구사항일 수도 있습니다.
본문에서는 짧게 언급된 조건이 평가표에서는 높은 배점을 가지고 있을 수도 있습니다.
서로 다른 장에 떨어져 있어 별개의 내용처럼 보였던 요구사항이 실제로는 하나의 평가항목으로 연결될 수도 있습니다.
그래서 수주 AI가 RFP를 읽을 때 중요한 것은 단순히 얼마나 많은 내용을 기억하는지가 아닙니다.
어떤 정보를 찾아야 하는지 알고 있는가.
그리고
찾은 정보 사이의 관계를 이해할 수 있는가.
여기에 있습니다.
사람이 놓치지 않기 위해 만든 표를, AI도 필요로 합니다
경험이 많은 제안팀일수록 RFP를 읽은 뒤 바로 글을 쓰지 않습니다.
요구사항 목록을 만들고,
Compliance Matrix를 만들고,
평가항목과 제안서 목차를 연결하고,
담당자를 배정하고,
대응 여부를 계속 확인합니다.
이런 표를 만드는 이유는 단순합니다.
놓치지 않기 위해서입니다.
AI도 마찬가지입니다.
RFP를 읽고 그럴듯하게 이해했다고 말하는 것보다,
어떤 요구사항을 찾았고,
어디에서 찾았으며,
어떤 평가항목과 연결되고,
어디에서 대응해야 하는지를
하나씩 확인할 수 있어야 합니다.
그래야 사람이 AI의 결과를 검토할 수도 있습니다.
AI가 사람을 대신해 RFP를 읽는 것에서 끝나는 것이 아니라,
사람과 AI가 같은 기준으로 RFP를 바라볼 수 있는 형태로 바꾸는 것.
저희는 이 과정이 더 중요하다고 생각합니다.
결국 좋은 제안은 ‘잘 읽는 것’에서 시작합니다
제안서를 잘 쓰는 방법에 대해서는 많은 이야기가 있습니다.
메시지를 명확하게 만들고,
차별점을 강조하고,
논리를 설계하고,
보기 좋은 페이지를 만드는 것.
모두 중요합니다.
하지만 그보다 앞에 있는 일이 있습니다.
고객이 무엇을 요구했는지 정확히 읽는 것.
읽지 못한 요구사항에는 답할 수 없습니다.
잘못 이해한 요구사항에는 좋은 전략을 만들 수 없습니다.
그리고 요구사항과 평가기준의 관계를 놓치면 열심히 만든 제안이 정작 중요한 곳에 힘을 쓰지 못할 수도 있습니다.
그래서 수주 AI의 첫 번째 역할 역시 화려하지 않습니다.
먼저, 제대로 읽는 것입니다.
200페이지를 순식간에 읽는 AI보다 중요한 것은,
200페이지에서 우리가 답해야 할 것을 하나도 놓치지 않는 AI입니다.
수주를 만드는 기술은 그곳에서부터 시작됩니다.
다음 회차 예고
3화. AI는 우리 회사의 과거 제안서를 어떻게 기억할까?
RFP에서 고객의 요구사항을 찾았습니다.
그다음에는 이런 질문이 남습니다.
“그래서 우리에게 이걸 할 수 있다는 근거가 있는가?”
과거 제안서, 수행실적, 기술자료, 발표자료까지. 회사 안에는 이미 수많은 수주 경험이 쌓여 있습니다.
다음 회차에서는 흩어져 있던 회사의 수주 지식을 AI가 어떻게 찾고,
현재의 제안에 다시 활용할 수 있는지 이야기해보겠습니다.