입찰제안서용 AI 솔루션 구축기 (1)

인턴 생활을 하면서 개인적으로 가장 인상 깊었던 건 제안서 작업의 규모였다. 백 페이지에 달하는 제안요청서(RFP)를 처음부터 끝까지 읽고, 요구사항과 배점표를 수동으로 뽑아내는 작업이 입찰마다 반복됐다. 보면서 자연스럽게 드는 생각이 있었다. 이거 AI로 자동화할 수 있지 않을까?

1. 문제

처음엔 단순하게 접근했다. 스크립트로 텍스트를 뽑아서 Gemini API에 통째로 던지면 되지 않을까 싶었는데, 두 가지 문제가 바로 터졌다.

첫째는 노이즈였다. 한글 문서(HWP, HWPX) 특성상 폰트 메타데이터나 표 레이아웃 같은 쓸모없는 데이터가 텍스트 안에 잔뜩 섞여 들어왔다. 둘째는 토큰이었다. RFP 텍스트가 10만 자를 넘어가는 경우가 많은데, 행정 절차나 서론 같은 불필요한 내용까지 전부 넘기다 보니 AI가 문맥을 잃거나 중요한 내용을 스킵하고 '정답일 것 같은 텍스트'를 생성하는 문제가 생겼다.

 

2. 구축

핵심 방향은 하나였다. AI에게 넘기기 전에 문서를 잘라내자.

문서의 위계 구조(I, 1, 가, 1) 등을 정규식으로 분석해 단락을 분해하는 파서를 만들었다. 해체된 수십 개의 섹션 중 헤더에 '요구사항', '과업내용', '배점표', '평가항목' 같은 키워드가 포함된 블록만 골라내는 방식이다. 결과적으로 11만 자짜리 RFP가 3~4만 자로 압축됐다. AI가 소화하기 훨씬 쾌적한 크기가 됐다.

배포는 LangChain과 Streamlit을 조합해 기획자들이 브라우저에서 파일을 올리고 결과를 바로 다운로드할 수 있는 GUI 앱 형태로 만들었다. 여러 파일을 한꺼번에 처리해야 하는 상황을 고려해 asyncio 비동기 병렬 처리도 붙였다. 10개의 문서를 동시에 구글 서버로 던져서 1~2분 안에 일괄 처리하는 구조다.

이후 오버스펙과 유지보수 비용 문제를 고려해 LangChain 의존성을 완전히 제거하고, 구글 순정 API만으로 동작하는 Lite 버전도 따로 분리했다.

 

3. 테스트

샘플(대구도시정비 등)를 돌려보니 원본 텍스트가 약 10만 자였는데, 핵심 압축 파서를 거치자 약 3만 자로 줄었다.

4개의 파일을 따로 추출하여 txt파일로 확인하였는데 핵심 요구사항만 남기고 나머지를 성공적으로 제거했다. 

4개의 서로 다른 RFP 문서를 드래그 앤 드롭으로 다중 업로드한 뒤 비동기 일괄 생성을 돌렸을 때, 약 3분여 만에 4개 문서 각각의 PPT 구조도(Blueprint.md)와 어필 포인트(Appeal.md)가 다운로드 버튼 형태로 화면에 떴다.

이정도로 구조화하고, 슬라이드 생성 지침을 제공해준다면 따로 수정할 필요 없이 젠스파크에 던져볼만 하다는 생각이 들었다. 아마 초기 제작본 제작시간(3인 2일~3일)을 1일이나 2일정도 단축시킬 수 있지 않을까? 물론 수정은 우리몫이겠지만 

 

4. 503 에러, 스트림릿 오류

스트림릿으로 배포하기 위해 Gemini 3.1pro, 2.5pro, 2.5 flash 등 다양한 모델로 테스트를 돌려봤는데 스트림릿에서는 503 에러가 간헐적으로 발생했다. 내 PC에서는 문제가 없었는데.

대응방안을 찾기위해 공부하고 있지만 정말 모르겠다. 왜 그러지...

 

결과적으로 잘 되면 3인 1주 분량의 작업을 2일 정도 단축할 수 있을 것으로 기대하고 있다. 실전 투입 후기는 나중에 올리도록 하겠다.