금요일 오후 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는 시간을 벌어줄 뿐, 책임을 대신 지지 않습니다.
공공기관·대기업 RFP 제안은 한국 IT 서비스(SI/SM) 직무의 핵심 업무 중 하나입니다. 발주 공고가 뜨면 제안 담당 PM은 수십에서 백 쪽이 넘는 RFP를 며칠 안에 읽고, 요건 대응표를 만들고, 질의서를 제출하고, 입찰 참여 여부를 판단해야 합니다. 이 압축된 일정에서 AI는 요건 추출·분류·매트릭스 초안을 빠르게 만들어 사람이 검증·판단에 집중하도록 시간을 벌어줍니다.
다만 이 업무에는 두 가지 현실적 제약이 있습니다. 첫째, 계약·발주 문서는 민감 정보입니다. 미공개 RFP, 예산, 보안 구성이 담긴 원문을 사내 승인 없이 외부 상용 AI에 입력하면 정보 유출과 비밀유지(NDA) 위반이 됩니다. 회사의 AI 사용 정책 — 승인된 도구인지, 민감정보를 마스킹해야 하는지, 온프레미스/사내 모델을 써야 하는지 — 를 입력 전에 반드시 확인하세요. 둘째, 최종 책임은 사람입니다. 평가에서 필수 요건 하나를 놓치면 회사가 사업을 잃습니다. AI 출력은 검토 대상 초안이지 제출물이 아닙니다.
그래서 이 업무에서 당신의 가치는 'AI를 쓸 줄 안다'가 아니라, AI에게 무엇을 시키고 무엇을 직접 검증·판단하는지 그 경계를 안다는 데 있습니다. 빠른 초안과 책임 있는 확정을 나눠 다루는 사람이 짧은 제안 일정에서 품질을 지킵니다.
관련 모듈로 더 깊이:
- 범위와 요구사항 — RFP에서 뽑은 요건을 프로젝트 범위로 정리하는 원리
- 계약·과업범위·M/M·검수 — 발주 문서의 요건이 계약·범위·검수로 이어지는 SI 맥락
- 고급 프롬프트 패턴과 AI 도구 연계 — RFP 분석 결과를 제안 준비 워크플로로 묶는 도구 연계의 다음 단계
다음 모듈에서는 RFP 분석으로 도출한 요건과 산출물을, 제안서 작성·일정 관리·문서 협업으로 이어주는 AI 도구 연계(통합) — 여러 도구를 하나의 제안 준비 워크플로로 묶는 방법을 다룹니다.