금요일 오후 4시, 120쪽짜리 공공 RFP가 도착했습니다. 제출은 다음 주 수요일.
박 PM은 형광펜을 들고 첫 장부터 읽기 시작합니다. 50쪽쯤에서 "이거 아까 본 보안 요건이랑 같은 건가?" 헷갈리기 시작하고, 80쪽에서 발견한 "ISMS 인증 보유 필수" 한 줄이 30쪽의 자격 요건과 충돌하는지 확인하려 다시 앞으로 넘깁니다. 밤 11시, 절반쯤 읽었고 요건 목록은 아직 머릿속에만 있습니다.
옆자리 정 PM은 다르게 시작했습니다. RFP 본문을 사내 승인된 분석 도구에 넣고, "요건을 빠짐없이 추출해 필수/선택으로 나누고, 기술·보안·운영으로 분류하고, 원문 위치와 함께 표로 만들라"고 지시합니다. 10분 뒤 80여 개 요건이 분류된 초안 표가 나옵니다. 정 PM은 이 표를 검토 대상으로 삼아, 원문과 한 줄씩 대조하며 잘못 분류된 것, 누락된 필수 요건, 모호해서 질의해야 할 항목을 골라냅니다.
차이는 'AI가 똑똑해서'가 아닙니다. 정 PM은 AI를 초안 작성기로 쓰고 자신은 검증·판단에 시간을 썼습니다. 사람이 처음부터 읽어 만드는 것과, AI 초안을 사람이 검증하는 것 — 이 모듈은 후자의 방법을 다룹니다.
- 1RFP/RFI에서 AI로 요구사항을 추출하고 필수/선택으로 분리하는 작업 흐름을 설명할 수 있다
- 2요건을 기술·보안·운영으로 분류하고 질의사항 목록과 준수 여부 매트릭스를 도출하는 방법을 적용할 수 있다
- 3AI 분류 결과에서 요건 누락·과대해석을 사람이 검증하는 절차를 수행할 수 있다
- 4계약·발주 문서를 외부 AI에 입력할 때의 보안 위험과 사내 승인 절차의 필요성을 설명할 수 있다
- 5공공·대기업 RFP 제안 준비 맥락에서 AI 초안과 사람 판단의 역할 분담을 구분할 수 있다
RFP 분석은 왜 '읽기'가 아니라 '구조화'인가
긴 문서에서 사람이 가장 자주 놓치는 것 — 흩어진 요건
RFP(제안요청서)와 RFI(정보요청서)는 한 곳에 요건을 모아두지 않습니다. 자격 요건은 앞쪽 일반 조항에, 기술 요건은 중간 과업 명세에, 보안 요건은 별첨에, 평가 배점은 또 다른 장에 흩어져 있습니다. 사람이 처음부터 끝까지 읽어도 이 요건들이 결국 몇 개이며 무엇이 필수인가를 머릿속에서 합치기 어렵습니다.
AI가 잘하는 일이 바로 이 구조화입니다. 긴 문서를 훑어 "요구사항으로 보이는 문장"을 뽑아내고, 비슷한 것끼리 묶고, 표 형태로 정렬하는 작업을 빠르게 합니다. 다만 AI는 "이게 정말 필수인가", "이 모호한 문장이 무엇을 뜻하는가"를 확정할 권한이 없습니다. 그건 사람의 판단 영역입니다.
| 작업 단계 | AI가 하는 일(초안) | 사람이 하는 일(확정) |
|---|---|---|
| 요건 추출 | 문서 전체에서 요구 문장 후보 나열 | 누락된 요건 보완, 중복 정리 |
| 필수/선택 분리 | "필수·반드시·하여야" 등 표현으로 1차 분류 | 평가 배점·실격 조건과 대조해 확정 |
| 기술/보안/운영 분류 | 정의에 따라 범주 배정 | 경계가 모호한 항목 재분류 |
| 질의사항 도출 | 모호·상충 문장을 질문 후보로 표시 | 실제 질의할지, 어떻게 물을지 결정 |
| 준수 매트릭스 | 요건별 준수 상태 초안 | 부분·불가 항목의 근거·보완 방안 작성 |
핵심은 AI = 초안, 사람 = 확정이라는 역할 분담입니다. 이 경계를 흐리면 — AI 출력을 그대로 제안서에 옮기면 — 필수 요건 누락이나 과대해석이 그대로 평가자에게 전달됩니다.
확대
필수와 선택을 가르는 것은 '단어'가 아니라 '평가 규칙'
AI는 보통 "반드시", "하여야 한다", "필수" 같은 표현으로 필수 요건을 1차 추정합니다. 하지만 RFP의 진짜 필수 여부는 평가 방식이 정합니다.
- 자격 요건(정량): 못 채우면 곧바로 실격. (예: 특정 인증 보유, 유사 실적 N건)
- 필수 기능 요건: 미충족 시 큰 감점, 사실상 수주 불가.
- 선택·가점 요건: 있으면 가점, 없어도 실격은 아님.
같은 "지원한다"라는 문장도, 그것이 자격 요건 표에 있으면 실격 사유고 가점 항목에 있으면 선택입니다. 그래서 필수/선택 분리는 단어 매칭이 아니라 그 요건이 평가표 어디에 연결되는지를 사람이 확인해 확정해야 합니다. AI에게는 "평가 배점·실격 조건과 연결해 표시하라"고 지시하되, 최종 라벨은 사람이 답니다.
어떤 작업을 AI에 맡기고, 어떤 판단을 사람이 할까
프롬프트 비교 — 'RFP 분석해줘' vs 검증 가능한 요청
나쁜 프롬프트 → 좋은 프롬프트 — 근거 인용을 강제하면 환각이 줄어든다
제안 일정에 쫓겨 RFP를 그냥 던지면, 그럴듯하지만 검증할 수 없는 요약이 나옵니다. 두 프롬프트를 비교해 보세요.
❌ 나쁜 프롬프트 — 형식도, 근거 요구도 없다
이 RFP 분석해서 요건 정리해줘.
[RFP 본문 …]
→ AI는 "주요 요건은 보안 인증, 가용성, 유지보수 체계입니다…" 같은 줄글 요약을 줍니다. 각 요건이 원문 몇 쪽에 있는지 없어 대조가 불가능하고, 필수인지 가점인지도 뭉뚱그려집니다. 별첨에 숨은 보안 인증 필수 요건을 빠뜨려도(누락) 아무도 모릅니다. 모호한 문장을 AI가 임의로 "지원함"으로 확정해(과대해석) 버리기도 합니다.
✅ 좋은 프롬프트 — 분류 정의 + 원문 위치·근거 인용 강제 + 불명 분리
역할: 당신은 공공/대기업 RFP 분석을 돕는 제안 보조자입니다.
아래 RFP 본문에서 모든 요구사항을 빠짐없이 추출해 표로 정리하세요.
분류 정의:
- 기술: 기능·성능·아키텍처·연동·데이터 처리
- 보안: 인증/권한·암호화·보안인증(ISMS 등)·개인정보·망분리
- 운영: 유지보수·SLA·장애대응·교육·인력투입·산출물 제출
각 요건마다 다음 열을 채우세요:
| 요건ID | 원문 위치(조항/페이지) | 요건 요약 | 분류 | 필수여부(필수/선택/불명) | 판단 근거(원문 표현 인용) |
규칙:
1. 원문에 없는 요건을 지어내지 마라. 근거 문장을 못 찾으면 그 행을 만들지 마라.
2. "필수/반드시/하여야 한다/…한 자에 한함" 같은 강제 표현은 근거 칸에 그대로 인용하라.
3. 강제성이 모호하면 필수여부를 '불명'으로 두고, 모호·상충 문장은 '질의 후보'로 따로 모아라.
4. 마지막에 "누락 의심 — 확인 필요" 목록을 별도로 출력하라(빠뜨린 게 있을 수 있다는 전제로).
[RFP 본문 …]
→ 출력 예시 (좋은 프롬프트 결과 일부)
| 요건ID | 원문 위치 | 요건 요약 | 분류 | 필수여부 | 판단 근거(인용) |
| R-07 | p.83 별첨2 | ISMS 인증 보유 | 보안 | 필수 | "ISMS 인증을 보유한 자에 한함" |
| R-12 | p.41 §3.2 | 99.9% 가용성 | 운영 | 필수 | "가용성 99.9% 이상을 보장하여야 한다" |
| R-15 | p.52 §4.1 | 모바일 지원 | 기술 | 불명 | "모바일 환경을 고려한다" (강제성 모호)
[질의 후보] R-15: '고려한다'가 필수 구현인지 권고인지 불명 → 발주처 질의
[누락 의심 — 확인 필요] 평가배점표(p.110)의 가점 항목이 요건으로 추출됐는지 재확인
핵심 강화는 세 가지입니다 — 분류 정의를 줘 기준을 고정, 원문 위치·근거 인용을 강제(인용 못 하면 행을 안 만들게 해 환각 차단), 강제성 모호는 '불명', 누락 의심은 별도 목록으로 빼 사람이 볼 곳을 가리킵니다. 인용 강제는 RFP·계약처럼 긴 문서를 다룰 때 환각을 막는 가장 강한 장치입니다.
직접 해보기 — 요건 분류 프롬프트와 준수 매트릭스
분류 작업은 기준이 흐리면 결과도 흔들립니다. 각 범주의 정의와 예시를 주고, 출력 형식을 표로 고정하는 프롬프트를 만듭니다. 아래는 사내 승인된 도구에 입력할 프롬프트 예시입니다(원문은 보안 검토를 거친 뒤 입력).
역할: 당신은 공공/대기업 RFP 분석을 돕는 제안 보조자입니다.
아래 RFP 본문에서 모든 요구사항을 추출해 표로 정리하세요.
분류 정의:
- 기술: 시스템 기능, 성능, 아키텍처, 연동, 데이터 처리 관련 요건
- 보안: 인증/권한, 암호화, 보안 인증(ISMS 등), 개인정보, 망분리 관련 요건
- 운영: 유지보수, SLA, 장애대응, 교육, 인력 투입, 산출물 제출 관련 요건
각 요건마다 다음 열을 채우세요:
| 요건ID | 원문 위치(조항/페이지) | 요건 요약 | 분류(기술/보안/운영) | 필수여부(필수/선택/불명) | 판단 근거(원문 표현) |
규칙:
1. 원문에 없는 요건을 만들지 마세요. 추론한 경우 '불명'으로 표시하세요.
2. "필수/반드시/하여야 한다" 등 강제 표현이 있으면 근거 칸에 그 표현을 인용하세요.
3. 모호하거나 상충하는 문장은 별도로 '질의 후보'로 표시하세요.
[여기에 RFP 본문]
핵심은 세 가지입니다 — 정의를 줄 것(분류 기준 고정), 원문 위치와 근거를 함께 출력하게 할 것(사람이 대조 가능), 추론한 항목은 '불명'으로 분리하게 할 것(과대해석 차단).
프롬프트: 정의 + 출력 형식 고정1단계에서 추출·분류한 요건을 준수 여부 매트릭스로 옮깁니다. 준수 상태는 준수(O)·부분(△)·불가(X) 세 가지로 표시하고, 부분·불가 행은 사람이 직접 근거와 보완 방안을 적습니다. AI에게는 초안만 만들게 하고, 회색지대 판단은 제안 담당자가 합니다.
| 요건ID | 요건 요약 | 필수여부 | 준수상태 | 근거 / 보완 방안 |
|---|---|---|---|---|
| R-01 | ISMS 인증 보유 | 필수 | 준수(O) | 2025년 ISMS 인증서 보유(별첨 제출) |
| R-02 | 99.9% 가용성 SLA 보장 | 필수 | 부분(△) | 단일 리전 99.5% 구성 가능. 99.9%는 멀티리전 추가 구성 시 충족 — 제안에 옵션으로 명시 |
| R-03 | 국산 DBMS 사용 | 필수 | 불가(X) | 현재 표준 스택은 PostgreSQL. 국산 DBMS 적용 시 일정 N주 추가 — 협력사 연계 검토 필요 |
| R-04 | 24시간 장애대응 체계 | 필수 | 준수(O) | 운영팀 3교대 + 협력사 야간 당직 계약으로 충족 |
| R-05 | 모바일 앱 제공 | 선택(가점) | 부분(△) | 반응형 웹 제공. 네이티브 앱은 차기 단계 — 가점 확보 위해 범위 협의 필요 |
이 표가 그대로 제안서의 요건 대응표가 되고, 동시에 내부적으로는 제안 리스크 목록이 됩니다. 부분(△)·불가(X) 행이 곧 리스크 — 일정·비용·협력사 조정이 필요한 지점입니다.
확대
준수 상태를 O·△·X로 판정하는 순간, 부분(△)·불가(X) 행의 개수가 그대로 보완해야 할 제안 리스크의 개수가 됩니다. 특히 필수 요건인데 X인 행은 실격으로 직결되므로, 단순 리스크가 아니라 "입찰 참여 여부를 다시 따져야 하는 신호"로 다룹니다.
매트릭스: 요건·필수여부·준수상태·근거요건 추출의 가장 큰 위험은 빠뜨린 필수 요건입니다 — 보이지 않으니 사람도 놓칩니다. 1단계 분류표를 받은 같은 대화에 아래를 이어 넣어, AI가 스스로 누락·과대해석을 훑게 하세요.
[자기검증] 위 요건 분류표를 사람이 평가표와 대조하기 전에 스스로 점검하라.
1) RFP 본문에서 강제 표현("하여야 한다", "…한 자에 한함", "필수")이 있는 문장 중
위 표에 빠진 것이 있는지 다시 훑어 "누락 의심" 목록에 추가하라.
2) 필수여부를 '필수'로 단 행마다, 근거 칸에 실제 원문 인용이 있는지 확인하라.
인용이 없으면 '불명'으로 내려라(추측으로 필수를 달지 마라).
3) 자격요건·평가배점표(보통 별도 장)의 항목이 요건 표에 반영됐는지 교차 확인하라.
AI가 "1) p.96 '관련 실적 3건 이상을 갖춘 자에 한함'이 표에 없음 → 누락 의심(자격요건, 실격 가능)"처럼 잡아 주면, 그 행이 사람이 가장 먼저 원문과 대조할 1순위입니다. 다만 이 자기검증은 사람 대조를 대신하지 않습니다 — 필수 요건 하나가 곧 수주 여부이므로, 최종 라벨은 반드시 사람이 평가표와 한 줄씩 맞춰 확정합니다.
자기검증 프롬프트 → 사람 최종 대조- 1단계 출력 표에 "원문 위치" 칸이 비어 있는 요건이 있다면, AI가 근거 없이 추론했을 가능성 — 원문에서 직접 찾아 확인하거나 삭제
- "불명"으로 표시된 요건은 사람이 원문을 다시 읽어 필수/선택을 확정해야 할 1순위 검토 대상
- "질의 후보"로 표시된 항목은 그대로 발주처 질의서(Q&A) 초안이 된다 — 모호·상충 문장을 공식 질의로 정리
- 준수 매트릭스에서 부분(△)·불가(X) 행의 개수 = 제안 리스크의 개수. 이 행들이 일정·비용·협력사 협의 지점
- 필수 요건인데 준수상태가 불가(X)인 행이 있다면 — 입찰 참여 여부 자체를 재검토해야 하는 핵심 신호
- 검증 후: AI가 처음 만든 표와 사람이 확정한 표의 차이(재분류·누락보완·근거추가)가 바로 "AI가 못 하고 사람이 한 일"
현장에서 자주 보는 함정
증상: 시간에 쫓겨 AI가 만든 요건 분류표를 검증 없이 제안서 대응표로 사용. 제출 후 평가에서 "필수 보안 인증 요건에 대한 대응이 누락됨"으로 감점 또는 결격 통보를 받습니다.
원인: AI는 별첨에 흩어져 있던 보안 인증 요건을 선택(가점)으로 잘못 분류했거나 아예 추출하지 못했습니다(누락). 강제 표현이 명시적이지 않은 한국어 RFP("...을 갖춘 자에 한함" 같은 우회 표현)에서 자주 발생합니다. AI는 문장의 강제성을 항상 정확히 읽지 못하고, 사람은 그 출력을 원문과 대조하지 않았습니다.
해결 방향:
- AI 분류 결과의 필수/선택 라벨은 평가표·자격요건과 한 줄씩 대조해 사람이 재확정한다(이 모듈 1단계 검증).
- "불명"·"질의 후보"로 표시된 항목을 우선 검토 — 여기가 누락·과대해석이 숨는 곳.
- 필수 요건은 준수 매트릭스에서 준수상태가 비어 있지 않은지 끝까지 확인. 빈 칸 = 미대응 신호.
- 한 사람이 만들고 한 사람이 끝내지 않는다 — 추출·검증을 다른 사람이 교차 확인하면 누락이 줄어든다.
함정의 본질은 'AI가 틀렸다'가 아니라 **'AI 초안을 사람이 확정하는 단계를 건너뛴 것'**입니다. AI는 시간을 벌어줄 뿐, 책임을 대신 지지 않습니다.
심화 — 누락만 잡으면 절반이다: 과대 약속과 제안 전략은 AI 밖의 일
심화: 제안서는 계약 문서가 된다 — AI 검증의 방향을 뒤집어야 하는 이유
이 모듈의 검증 절차는 주로 한 방향을 봅니다 — AI가 요건을 빠뜨리지 않았는가(누락). 그런데 실무 사고는 반대 방향에서도 터집니다. AI가 요건보다 더 많이 약속해 버리는 방향입니다.
- 과대 기재는 수주 후에 청구서로 돌아옵니다: 제안서는 낙찰되면 통상 계약의 일부로 편입됩니다. AI가 초안에 자신 있게 적은 "지원합니다", "제공합니다" 한 문장이, 검수 단계에서 발주사가 이행을 요구하는 근거가 됩니다. 그래서 누락 검증(요건을 빠뜨렸나)과 별도로 역방향 검증 — 제안서의 모든 확약 문장을 뽑아 실현 근거가 있는지 대조하는 절차 — 이 필요합니다.
- 입찰 참여 판단은 매트릭스 밖에 있습니다: 준수 매트릭스가 전부 O여도 들어가면 안 되는 사업이 있습니다. 과도한 지체상금, 무제한 하자보수, 산출물 지식재산권 전부 귀속, 비현실적 일정 같은 독소 조항의 위험 가중치는 조직의 수행 경험과 재무 판단의 영역입니다. AI는 조항을 찾아줄 수는 있어도, 그것을 우리 회사가 감당할 수 있는가는 답하지 못합니다.
- 모두가 같은 AI를 쓰면 제안이 닮아갑니다: 경쟁사도 같은 도구로 같은 RFP를 분석합니다. AI가 잘 만드는 부분(요건 대응표, 표준 구성)은 상향 평준화되어 차별성이 사라집니다. 평가를 가르는 것은 결국 AI가 못 만드는 것 — 발주사 도메인에 대한 이해, 유사 수행 경험의 구체성, 투입 조직의 실제 역량입니다. AI로 아낀 시간을 어디에 쓰는가가 진짜 격차를 만듭니다.
상황: 제안 마감에 쫓겨 기술 부문 초안을 AI로 만들었고, 검토는 요건 누락 여부 중심으로만 했습니다. 낙찰 후 검수 단계에서 발주사가 제안서 47쪽의 "이중화 구성을 통한 실시간 무중단 전환을 지원합니다" 문구를 근거로 시연을 요구했습니다. 실제 우리 구성은 수동 전환(수 분 소요)이었고 RFP 원문의 요건도 이중화 구성 수준이었지만 — 제안서가 스스로 요건 이상을 약속해 버린 것입니다. 결국 무상 추가 개발과 일정 연장으로 마무리됐습니다.
원인: AI는 이중화라는 키워드에서 업계의 표준 마케팅 문구(실시간 무중단)를 끌어와 살을 붙였고, 검증은 RFP 요건 대비 누락만 봤지 제안서가 요건을 초과 약속하는 방향은 아무도 점검하지 않았습니다. 제안서가 계약 문서로 편입된다는 사실, 그래서 AI 초안의 문장 하나하나가 이행 의무의 후보라는 인식이 없었습니다.
진단: 제안서 전체에서 확약 표현("지원한다", "제공한다", "보장한다", "이내에")을 기계적으로 추출해 목록을 만들고, 각 문장을 두 기준과 대조합니다 — RFP가 실제로 요구한 수준인가(초과 약속 여부), 그리고 우리가 근거를 가진 약속인가(구현·실적·계약으로 입증 가능한가). 초과이면서 근거 없는 문장의 목록이 곧 이행 리스크 목록입니다.
해결: (1) 제안서 검증에 역방향 절차를 추가합니다 — 확약 문장 추출은 AI에 시키되(모으는 속도는 AI가 빠르므로), 각 문장의 실현 근거 확인과 수위 조정은 기술 책임자가 서명으로 확정합니다. (2) 확약 표현의 수위 규정을 둡니다 — 근거 없는 문장은 "협의를 통해 지원 가능" 수준으로 낮추거나 삭제합니다. (3) 준수 매트릭스의 O 판정에도 근거(구현 방식·보유 실적) 칸을 채워, 매트릭스가 그대로 이행 계획이 되게 합니다 — 제안이 계약·검수로 이어지는 구조는 계약·과업범위·M/M·검수에서 다룹니다. 수주는 끝이 아니라 약속의 시작이고, AI가 만든 약속이라도 이행하는 것은 사람과 조직입니다.
공공기관·대기업 RFP 제안은 한국 IT 서비스(SI/SM) 직무의 핵심 업무 중 하나입니다. 발주 공고가 뜨면 제안 담당 PM은 수십에서 백 쪽이 넘는 RFP를 며칠 안에 읽고, 요건 대응표를 만들고, 질의서를 제출하고, 입찰 참여 여부를 판단해야 합니다. 이 압축된 일정에서 AI는 요건 추출·분류·매트릭스 초안을 빠르게 만들어 사람이 검증·판단에 집중하도록 시간을 벌어줍니다.
다만 이 업무에는 두 가지 현실적 제약이 있습니다. 첫째, 계약·발주 문서는 민감 정보입니다. 미공개 RFP, 예산, 보안 구성이 담긴 원문을 사내 승인 없이 외부 상용 AI에 입력하면 정보 유출과 비밀유지(NDA) 위반이 됩니다. 회사의 AI 사용 정책 — 승인된 도구인지, 민감정보를 마스킹해야 하는지, 온프레미스/사내 모델을 써야 하는지 — 를 입력 전에 반드시 확인하세요. 둘째, 최종 책임은 사람입니다. 평가에서 필수 요건 하나를 놓치면 회사가 사업을 잃습니다. AI 출력은 검토 대상 초안이지 제출물이 아닙니다.
그래서 이 업무에서 당신의 가치는 'AI를 쓸 줄 안다'가 아니라, AI에게 무엇을 시키고 무엇을 직접 검증·판단하는지 그 경계를 안다는 데 있습니다. 빠른 초안과 책임 있는 확정을 나눠 다루는 사람이 짧은 제안 일정에서 품질을 지킵니다.
관련 모듈로 더 깊이:
- 범위와 요구사항 — RFP에서 뽑은 요건을 프로젝트 범위로 정리하는 원리
- 계약·과업범위·M/M·검수 — 발주 문서의 요건이 계약·범위·검수로 이어지는 SI 맥락
- 고급 프롬프트 패턴과 AI 도구 연계 — RFP 분석 결과를 제안 준비 워크플로로 묶는 도구 연계의 다음 단계
다음 모듈에서는 RFP 분석으로 도출한 요건과 산출물을, 제안서 작성·일정 관리·문서 협업으로 이어주는 AI 도구 연계(통합) — 여러 도구를 하나의 제안 준비 워크플로로 묶는 방법을 다룹니다.