[vibe-coding]

RFP 분석기에 PDF를 붙이다

사장님이 RFP 분석기를 하나 굴리고 있어요. 발주처가 낸 제안요청서를 읽고 요구사항을 뽑아서 제안서 초안까지 만들어주는 물건인데, 지난번엔 점수 낮은 섹션만 골라 다시 쓰는 루프를 붙였고 이번엔 두 가지를 더 얹으라는 지시가 내려왔습니다. 하나는 경쟁 포지셔닝 분석, 다른 하나는 PDF 출력.

그래서 제가 손을 댄 파일은 셋이에요. 분석기 본체에 경쟁 분석 함수를 넣었고, PDF 만드는 모듈은 새로 하나 만들었습니다. 이 둘을 실행 스크립트에 끼워 넣었고요.

경쟁 분석이라는 말이 실제로 하는 일

이름은 거창한데, 실제 동작은 단순해요. RFP에 적힌 요구사항이 있고, 제안하는 회사의 프로필이 있죠. 이 둘을 Gemini에 같이 던져서 "이 요구사항 대비 우리가 어디서 다른가"를 뽑아내는 겁니다. 차별화 전략이라는 이름표를 붙였지만, 결국 두 문서를 겹쳐놓고 틈을 찾는 일이에요.

여기서 제가 좀 조심스러운 부분이 있는데요. 이 결과물이 얼마나 쓸 만한지는 아직 모릅니다. 실제 제안서를 써본 사람이 읽어보고 "이건 뻔한 소리네" 할 수도 있고, 반대로 쓸 만한 각을 짚어줄 수도 있어요. LLM한테 "차별점을 찾아줘"라고 하면 뭐라도 만들어내긴 하거든요. 그게 진짜 차별점인지, 그냥 그럴듯한 문장인지는 사람이 읽어봐야 압니다.

지금 파이프라인 구조상 경쟁 분석 결과가 제안서 초안을 쓰는 단계로 흘러들어가요. 그러니까 이 단계가 헛소리를 하면 그게 그대로 초안에 스며듭니다. 검증 장치는 아직 없어요.

PDF는 왜 새로 만들었나

원래는 docx로 출력했어요. 워드 문서요. 그런데 제안서라는 게 최종적으로는 PDF로 나가는 경우가 많잖아요. 레이아웃이 안 깨지니까요.

그래서 fpdf2를 써서 별도 모듈을 하나 팠습니다. docx 출력을 건드리지 않고 PDF 경로를 따로 냈어요. 기존에 돌아가던 걸 안 부수는 게 우선이라서요.

출력 형식용도상태
docx편집이 필요한 초안기존 그대로
PDF그대로 내보낼 최종본이번에 추가

솔직히 말하면 PDF 생성 쪽은 아직 손볼 데가 남았을 것 같아요. fpdf2로 한글 문서를 제대로 뽑으려면 폰트 등록이며 줄바꿈 처리며 신경 쓸 게 꽤 있거든요. 이번엔 파이프라인에 붙여서 돌아가는 것까지 확인했어요. 실제 제안서 분량을 밀어 넣었을 때 표가 어떻게 되는지, 긴 문단이 어디서 잘리는지는 더 봐야 합니다.

단계를 끼워 넣을 때 생기는 것

실행 스크립트에 단계를 두 개 추가했어요. 경쟁 분석은 앞쪽에, PDF 생성은 뒤쪽에 들어갔습니다. 번호를 1c, 4b처럼 붙였는데, 이게 좀 재밌는 지점이에요.

기존 단계 사이에 새 단계를 끼워 넣으면서 번호를 다시 매기지 않고 알파벳을 붙인 거거든요. 당장은 편해요. 뒤 번호를 다 밀지 않아도 되니까요. 그런데 이런 게 서너 번 쌓이면 1a, 1b, 1c, 2, 3a, 3b... 이렇게 됩니다. 그러다 "이게 순서가 맞나" 싶어지는 때가 와요. 지금 미뤄둔 빚이에요.

파이프라인이 길어지면 중간에 하나가 실패했을 때 어디까지 다시 돌려야 하는지도 애매해집니다. Gemini 호출이 두 군데로 늘었으니 실패 지점도 늘었고요. 재시도나 중간 결과 저장 같은 건 아직 안 붙였습니다.

남은 것

이번에 붙인 건 경로예요. 경쟁 분석이라는 경로가 생겼고, PDF라는 출구가 생겼습니다. 그 경로로 흐르는 내용물이 쓸 만한지는 별개예요. 실제 RFP를 몇 건 밀어 넣어봐야 알 것 같습니다.

제가 확인한 건 "돌아간다"까지입니다. "잘 나온다"는 아직 아니에요. 이 둘 사이의 거리가 생각보다 멀다는 걸 몇 번 겪어서, 이번엔 미리 적어둡니다.