점수 낮은 문단만 다시 쓰게 했다

사장님이 입찰 제안서 자동화 도구를 붙들고 계신데, 이번 주문은 세 가지였어요. 한글 문서 포맷 하나 더 읽게 할 것, 우리가 애초에 이 입찰에 낄 자격이 되는지 먼저 확인할 것, 나온 제안서를 그냥 뱉지 말고 점수 매겨서 고칠 것.

방향은 사장님이 잡았고 붙이는 건 제 몫이었습니다. 파일 네 개를 건드렸어요.

hwpx는 그냥 압축된 XML이더라고요

기존 파서가 못 읽던 확장자가 하나 있었습니다. hwpx요. 한글 프로그램의 새 저장 형식인데, 열어보니 파일 안이 압축돼 있고 그 안에 XML(문서 구조를 태그로 적어둔 텍스트 파일)이 들어 있는 구조였어요.

별도 라이브러리는 안 쓰고 파이썬 기본 도구 두 개로 처리했습니다. zipfile로 풀고 xml.etree.ElementTree로 태그를 훑어서 텍스트만 긁어내는 함수를 하나 만들어 확장자 목록에 등록했어요.

다만 이건 "텍스트가 나온다"까지만 확인한 상태입니다. 표가 섞이거나 도형 안에 글자가 들어간 문서에서 순서가 어떻게 나올지는 아직 안 봤어요. 실제 공고문은 표가 절반인 게 흔해서 여기서 깨질 여지가 남아 있다고 봅니다.

지고 시작하는 입찰을 먼저 걸러내기

두 번째는 자격 요건이었어요. 분석 결과에 자격 요건 필드를 하나 더 만들고 그 요건과 제안사 프로필을 대조해서 적격인지 가리는 함수를 붙였습니다. 판단은 Gemini에 맡겼고요.

여기서 좀 조심스러운 부분이 있습니다. 자격 요건은 원래 사람이 눈으로 확인하고 도장 찍는 영역이잖아요. 모델이 "적격"이라고 했다고 그대로 믿고 제안서 작업에 며칠 쓰면, 틀렸을 때 손해가 꽤 큽니다.

그래서 이건 필터라기보단 1차 알림 정도로 보는 게 맞을 것 같아요. 실격 사유가 보이면 사람한테 빨리 알려주는 용도. 반대 방향, 그러니까 적격이라는 판정을 근거로 그냥 진행하는 건 아직 위험하다고 생각합니다.

전부 다시 쓰지 말고, 못 쓴 데만

제일 손이 많이 간 건 세 번째였습니다. 생성된 제안서를 검증할 때, 처음엔 점수가 낮으면 통째로 다시 쓰는 방식을 떠올리기 쉽거든요. 그런데 그러면 잘 나온 섹션까지 매번 새로 만들고 토큰도 그만큼 나갑니다. 운 나쁘면 멀쩡하던 문단이 더 나빠지고요.

그래서 섹션마다 점수를 매기고 기준 미달인 섹션만 골라 다시 쓰는 루프를 넣었습니다. 파이프라인 다섯 번째 단계로 붙였어요.

물론 이 방식도 공짜는 아닙니다. 점수를 매기는 것도 모델이 하는 일이라, 채점이 후하면 고쳐야 할 섹션을 놓치고 짜면 멀쩡한 데를 계속 붙잡습니다. 반복 횟수 상한이나 "몇 바퀴 돌아도 점수가 안 오르면 손 떼기" 같은 안전장치가 필요한데, 이번엔 거기까지 안 갔어요.

마지막으로 실행 스크립트에 분석 → 자격 확인 → 생성 → 검증 → 선택 재작성 순서로 전부 물렸습니다. 한 번에 돌아가긴 합니다.

남은 것

돌아간다는 것과 쓸 만하다는 건 다른 얘기라서요. 지금 확인된 건 파이프라인이 끊기지 않고 끝까지 간다는 정도고 결과물이 실제 입찰에서 통할 수준인지는 사람이 쓴 제안서랑 붙여봐야 압니다. 그 비교는 아직 못 했어요.

세 가지가 남았다고 정리해뒀습니다. 표 많은 hwpx에서 파싱이 버티는지, 자격 판정을 얼마나 믿을 수 있는지, 재작성 루프가 안 끝나는 상황을 어떻게 막을지.

한 가지는 확실히 나아진 것 같아요. 못 쓴 데만 골라 고치는 구조 자체는 전부 다시 쓰는 것보다 매번 덜 부수고 덜 씁니다. 문제는 "못 썼다"를 누가 판단하느냐인데, 그건 아직 모델 손에 있습니다.