
AI시대의 제안서 작성 가이드 · Ep.02
위험은 쓰인 문장에 없다.
쓰이지 않은 자리에 있다.
RFP 독해: 발주자가 쓰지 않은 것을 읽는다 · HFC Consulting
제안 착수 회의에서 RFP를 함께 읽는다. 대부분의 시간은 적힌 것을 확인하는 데 쓰인다. 요구사항 목록, 제출 서류, 평가 배점. 회의가 끝날 무렵 아무도 묻지 않은 질문이 남는다. 여기 적히지 않은 것은 누구의 몫인가.
수행 단계에서 터지는 분쟁의 대부분은 RFP에 적힌 문장 때문이 아니다. 적히지 않은 자리를 양쪽이 서로 다르게 채웠기 때문이다. 그리고 그 빈자리는 계약 후에는 언제나 수급인 쪽으로 기운다.
침묵의 세 종류
RFP의 침묵은 균질하지 않다. 세 가지로 나눠 읽어야 대응이 달라진다.
첫째, 의도된 여백. 발주자가 확정하지 못한 영역을 열어 둔 것이다. 요구 확정도가 낮은 사업에서는 자연스럽다. 문제는 그 여백의 크기가 가격에 반영되지 않을 때다. 6기 Ep.03 (요구사항은 어디까지 쓰고 어디부터 맡기나)이 발주자 쪽에서 다룬 주제가, 이쪽에서는 공수 산정의 불확실 구간으로 나타난다.
둘째, 관행에 기댄 생략. "일반적인 수준으로", "업계 표준에 따라" 같은 문구다. 발주자는 자신이 아는 관행을, 수급인은 자신이 아는 관행을 떠올린다. 두 관행이 같았던 사업을 나는 본 적이 없다.
셋째, 인지되지 않은 공백. 가장 위험하다. 발주자도 그 항목이 필요하다는 것을 모른다. 데이터 이행 리허설, 기존 시스템 인터페이스 규격, 운영 이관 범위 — 검수 직전에야 "당연히 포함 아니냐"는 말과 함께 나타난다.
대응은 종류마다 다르다. 첫째는 가격에 불확실 구간을 실어야 하고, 둘째는 사전질의로 관행의 내용을 문서에 고정해야 하며, 셋째는 우리 쪽에서 먼저 제안서에 명시해 범위를 선점해야 한다. 세 침묵을 구분하지 않고 "질의하겠습니다" 하나로 대응하면, 정작 질의로는 메울 수 없는 공백이 남는다.
"등"이라는 글자를 세는 이유
과업범위 문단에서 "등"은 무한 확장의 문법이다. 6기 Ep.02 ("등"이라는 한 글자의 대가)에서 발주자에게 권했던 것은 이 글자를 지우라는 것이었다. 수급인 입장에서 할 일은 반대다. 지워지지 않은 "등"을 전부 찾아, 각각이 어디까지를 뜻하는지 사전질의로 좁힌다.
범위만이 아니다. 완료의 정의가 없는 RFP는 검수 단계에서 정의된다. 그때의 정의권은 발주자에게 있다. 6기 Ep.07 (검수기준은 계약이 아니라 RFP에서 태어난다)이 말한 것이 이것이다. 검수기준이 RFP에 없다면, 그 사업의 완료 조건은 아직 존재하지 않는다.
리스크 스캔: 세 면을 훑는다
RFP 수령 후 첫 이틀 안에, 문서를 세 면으로 나눠 훑는다. 이 스캔의 산출물은 두 가지다. 사전질의 초안과, 가격에 실을 리스크 항목 목록.
RFP 리스크 스캔 체크리스트 (범위·기준·조건 3분면)
① 범위 — "등"·"일체"·"전반"의 출현 위치를 전부 표시했는가
② 범위 — 제외 범위(Out of Scope)가 명시되어 있는가, 없다면 우리가 제안서에 쓸 것인가
③ 범위 — 기존 시스템 연계 대상과 인터페이스 규격이 특정되어 있는가
④ 기준 — 검수기준이 업무 지표로 적혀 있는가, "협의"로 미뤄져 있는가
⑤ 기준 — 산출물 목록과 승인 절차·승인 주체가 명시되어 있는가
⑥ 기준 — 성능·품질 요구가 측정 가능한 수치로 되어 있는가
⑦ 조건 — 지체상금·하자담보 조항이 통상 범위인가
⑧ 조건 — 지식재산권 귀속과 재사용 권리가 어떻게 설계되어 있는가
⑨ 조건 — 발주기관 협조 사항(자료 제공·현업 참여·환경 제공)이 의무로 적혀 있는가
⑩ 조건 — AI 도구·데이터 반출 제약이 우리 개발 방식과 충돌하지 않는가
스캔은 한 사람이 하지 않는다. 범위는 아키텍트가, 기준은 품질 담당이, 조건은 계약 담당이 각각 읽고 한자리에 모인다. 세 사람이 같은 문서에서 서로 다른 위험을 짚어 낼 때, 그 목록이 제안 전략의 출발점이 된다.
⑨는 특히 빠지기 쉽다. 발주기관의 자료 제공이 늦어져 일정이 밀려도, RFP에 협조 의무가 없으면 그 지연은 수급인의 책임이 된다. 협조 사항의 부재는 침묵이 아니라 조항이다.
예상 반론과 대응
반론. "열흘 안에 제안서를 써야 하는데 이런 스캔까지 할 시간이 없다."
대응. 스캔은 이틀이고, 제안서 작성은 그 이틀 위에서 빨라진다. 범위가 특정되지 않은 채 쓰는 제안서는 결국 다시 쓰게 된다. 그리고 사전질의 마감은 대개 제안서 마감보다 훨씬 앞에 있다 — 스캔을 미루면 질의 기회 자체가 사라진다.
반론. "AI로 RFP를 요약시키면 리스크도 뽑아 주지 않는가."
대응. 생성형 도구는 적힌 것을 요약하는 데 유능하다. 이 글의 주제는 적히지 않은 것이다. 도구는 문서에 없는 인터페이스 규격이 왜 필요한지 알지 못한다. 그 판단은 유사 사업의 수행 경험에서 나온다. 요약은 도구에 맡기고, 빈자리 판별에 사람의 시간을 쓰는 것이 올바른 분업이다.
체크포인트 — 침묵은 세 종류 / "등"은 세어서 질의로 좁힌다 / 검수기준 없는 RFP는 완료 조건이 없는 사업 / 협조 사항의 부재도 조항이다 / 스캔의 산출물은 질의서와 리스크 가격
잘 읽는다는 것은 빠짐없이 읽는다는 뜻이 아니다. 무엇이 없는지 알아보는 것이다.
본 글의 내용은 법률 자문을 대체하지 않으며, 실제 제안·계약 시 법무 검토를 권장합니다.
📎 더 읽을거리
APMP — 제안·비드 관리 전문가 국제 협회. RFP 분석과 제안 프로세스의 표준적 논의.
Shipley Associates — 비드·캡처 방법론의 사실상 표준. RFP 요구사항 매트릭스(Compliance Matrix) 개념의 원류.
HFC의 관점
검토 중인 RFP가 있다면, 세 면 스캔을 함께 해 드립니다. 발주자 시리즈를 쓴 눈으로 어느 자리가 비어 있는지 짚어 드립니다.
1영업일 이내 답변 · 주식회사 에이치에프씨 컨설팅 · 대표이사 장기석
'IT 인사이트 > AI시대의 제안서 작성 가이드' 카테고리의 다른 글
| AI 활용 조건에 답하기: 약속해도 되는 것과 안 되는 것 (06/08) (0) | 2026.08.05 |
|---|---|
| 제안서: 차별화는 형용사가 아니라 증거다 (05/08) (0) | 2026.08.05 |
| 가격: 저가 수주의 청구서는 수행 단계에 온다 (04/08) (0) | 2026.08.05 |
| 사전질의: 질문은 전략이다 (03/08) (0) | 2026.08.05 |
| RFP가 도착한 날: 들어갈 것인가, 접을 것인가 (01/08) (0) | 2026.08.05 |