RFP 자동 응답 초안 생성

한 주에 RFP 3건이 들어오고 답변 마감이 모두 다음 주로 겹치는 경우가 있습니다. 기술, 제안, 법무 내용이 한 PDF에 섞인 80페이지 문서에 답하려면 일주일이 걸립니다. 답변의 70%는 전년도에 비슷하게 작성했던 내용인데도 매번 새로 작성해야 하며, 이 부분에서 가장 많은 시간이 낭비된다고 알려져 있습니다.

RFP 자동 응답 초안 시스템은 이 일주일을 반나절로 줄입니다. LLM이 RFP를 항목 단위로 나누고, 사내의 과거 제안서와 기술 자료, 인증서를 검색해 항목별 초안을 자동으로 작성합니다. 담당자는 톤 수정과 가격 협상에 집중합니다.

이 가이드는 RFP 응답 초안 자동화의 도입 효과, 구축 도구, 도입 전 결정 사항을 정리했습니다.

도입 검토 대상

연간 RFP 응답이 30건을 넘으면 수작업으로 대응하기 어렵습니다. 다음과 같은 상황이 반복된다면 도입을 검토할 시점입니다.

회사 인증서와 연혁, 조직도를 한 달에 5번씩 다시 옮겨 적는 경우

마감일이 겹친 RFP 중 한 건을 분기마다 포기하는 상황

엔지니어가 답변 작성에 투입되어 본업이 지연되는 경우

담당자마다 답변 톤이 달라 검수 회의가 길어지는 경우

수주한 제안서와 탈락한 제안서의 차이를 분석할 시간이 없는 상황

도입 전후 비교

한 분기 정도 운영하면 제안팀의 업무 방식이 달라집니다. 가장 자주 보고되는 변화는 다음 5가지입니다.

초안 작성 시간은 한 건당 평균 24시간에서, 항목의 80%가 자동으로 작성되는 단계에 이르면 4~6시간으로 줄어듭니다.

동시 처리 가능 건수는 주 1건에서 주 3~4건으로 늘어나, 마감이 겹쳐 포기하는 RFP가 거의 없어집니다.

답변 일관성은 담당자마다 톤과 표현이 다르던 상태에서 사내 표준 표현 라이브러리를 일괄 인용하는 방식으로 바뀌고, 검수 회의 시간은 절반으로 줄어듭니다.

엔지니어 투입 시간은 한 건당 8시간에서 1시간 미만으로 줄어듭니다. 정밀 답변이 필요한 항목 2~3개만 검토합니다.

승률 분석은 연말에 한 번 하던 정성 분석에서, RFP마다 어떤 답이 점수에 기여했는지 자동으로 태깅하는 방식으로 바뀝니다.

처리 흐름

RFP가 메일함에 도착한 뒤 초안 PDF가 검수용 슬랙 채널에 전달되기까지 담당자와 시스템의 역할을 정리한 흐름도입니다. 화살표 위 숫자는 처리 순서입니다.

시스템 작동 단계

LLM이 처리하는 작업은 다음 4단계로 나뉩니다.

1단계: RFP 항목 분해와 분류. PDF에서 질문과 요건을 항목 단위로 추출합니다. "회사 개요", "기술 사양", "보안 인증", "납기 조건"처럼 카테고리를 자동 태깅하고 답변이 필요한 80~150개 셀로 변환합니다. 이 단계의 정확도가 전체 자동화율을 결정합니다.

2단계: 사내 자료 RAG 검색. 항목마다 과거 제안서, 기술 백서, 인증서, 수주 답변 라이브러리를 검색해 가장 가까운 답변 후보 3~5개를 가져옵니다. 사내 자료가 잘 정리되어 있을수록 자동화율이 높아지며, 70%까지 도달한다고 알려져 있습니다.

3단계: 항목별 초안 생성. Claude Sonnet 4.6 같은 LLM이 후보를 종합해 항목별 답변 초안을 작성합니다. 길이와 톤, 강조점은 미리 정한 템플릿을 따르고, 회사명이나 금액, 날짜 같은 변수만 RFP에 맞게 바꿉니다.

4단계: 신뢰도 표시와 검수 라우팅. 항목마다 근거 강함, 중간, 약함의 3단계 신뢰도를 붙입니다. 강함은 자동 통과, 중간은 검수자, 약함은 엔지니어 검토로 자동 라우팅하므로, 검수자는 PDF 안에서 빨간색으로 표시된 항목만 확인하면 됩니다.

주요 실패 요인

가장 흔한 실패는 사내 자료를 정리하지 않은 상태에서 시작하는 것입니다. 과거 제안서가 개인 폴더에 흩어져 있고 버전이 섞여 있으면 RAG 검색이 관련 없는 답변을 가져옵니다. 도입 전 한 달을 자료 정리에 쓰는 것이 ROI가 가장 높은 것으로 평가됩니다.

두 번째는 환각입니다. 보안 인증이나 납기, 가격 같은 사실 항목을 LLM이 사실과 다르게 작성하면 입찰 자격 박탈로 이어질 수 있습니다. 사실 항목은 인증서 DB와 납기 캘린더 같은 별도 화이트리스트에서만 가져오도록 시스템에서 강제해야 합니다.

세 번째는 톤 일관성입니다. 같은 회사가 작성한 두 RFP 답변의 어조가 다르면 평가자의 신뢰를 잃습니다. 사내 표현 라이브러리(승인된 문장 200~500개)를 미리 만들고, LLM이 그 안에서만 인용하도록 설계합니다.

마지막은 검수자의 신뢰입니다. 검수자가 결국 모든 항목을 다시 확인해야 한다고 판단하면 자동화의 효과가 없습니다. 신뢰도 표시와 근거 인용, 자동 라우팅이 함께 작동해야 검수자가 빨간색으로 표시된 항목만 확인하는 구조가 됩니다.

성과 지표

RFP 자동 응답 시스템의 효과는 다음 4가지 지표로 측정합니다.

항목 자동화율은 전체 항목 가운데 LLM 초안이 그대로 통과한 비율입니다. 60% 이상이면 운영 단계로 봅니다.

한 건당 작성 시간은 도입 전 평균 대비 70% 이상 줄이는 것이 일반적인 목표입니다.

동시 처리 RFP 수는 월간 처리 건수가 2배 이상 늘면 정상 범위입니다.

입찰 승률은 절감한 시간을 정밀 답변에 쓰면서 5~10%p 오른 사례가 있습니다.

자동화율은 처음부터 60%를 목표로 잡지 않습니다. 30%에서 시작해 사내 자료가 정리되는 만큼 높여 가는 방식이 더 안정적인 것으로 알려져 있습니다.

자주 묻는 질문

사내 자료가 보안상 외부로 나갈 수 없는 경우에는 어떻게 하나요?

RAG 검색 인덱스를 사내 서버에 두고 LLM에는 검색 결과만 토큰 단위로 전달하는 구성이 일반적입니다. 추론도 외부로 보내지 않으려면 사내 GPU에 sLLM(Llama 3.1 70B 등)을 구동해 모든 처리를 사내에서 할 수 있습니다. 이 경우 정확도 차이는 5~10%p 정도로 보고됩니다.

한국어 RFP에서 잘 작동하나요?

Claude Sonnet 4.6과 GPT-5.5는 한국어 B2B 문서에서도 영어와 비슷한 수준의 정확도를 보입니다. 다만 RAG 검색이 제대로 작동하려면 사내 표현 라이브러리와 과거 제안서가 한국어로 정리되어 있어야 합니다. 자료가 영어로만 되어 있으면 자동화율이 절반으로 떨어집니다.

도입에 얼마나 걸리나요?

사내 자료가 잘 정리된 회사는 파일럿 프로젝트 3주, 운영 안정화까지 8주가 일반적입니다. 자료 정리부터 시작해야 하면 12~16주로 늘어납니다.

도입 시작 방법

사내에서 직접 시작한다면 항목 분해 정확도를 먼저 확인하고 사내 표현 라이브러리 100문장을 모으는 순서로 진행하는 것이 가장 빠릅니다.