영수증 OCR 후처리에서 GPT-4o vision과 Gemini 2.0 Flash를 1,200장으로 직접 재본 결과

"Flash가 싸던데" 정도의 체감으로 넘기기 찝찝해서 숫자로 박아봤다. OCR로 뽑은 텍스트를 정형 JSON으로 후처리하는 단계에서 vision 모델만 GPT-4o에서 Gemini 2.0 Flash로 교체하고 비교한 기록이다.

환경

• 대상: 영수증·명함을 정형 JSON으로 후처리 (필드: 상호, 금액, 일자 등)
• 입력: 거의 인쇄체 영수증, 하루 수만 장 유입
• 평가: 샘플 1,200장을 떼서 같은 프롬프트로 양쪽 실행, 정답은 수기 라벨

정확도 (필드 단위로 정확히 맞은 비율)

차이가 난 곳은 거의 손글씨와 흐린 영수증이었다. 인쇄체만 추리면 격차가 1%p 안쪽으로 좁혀졌다. 어차피 뒤에 금액 합계 검산 룰을 한 겹 걸어둬서, 필드가 틀린 건 대부분 거기서 다시 걸린다.

비용·처리량

정확한 단가표를 봐야 하지만 우리 토큰 길이 기준으로 Flash가 GPT-4o의 약 1/10이었다. 그래서 GPT-4o일 땐 야간 배치로만 돌리던 작업을 Flash는 실시간으로 돌려도 청구서가 부담스럽지 않았다. 처리량 병목이 사실상 사라졌다.

코드 펜스 함정

Flash가 가끔 JSON을 마크다운 코드 펜스에 싸서 던져 파싱이 깨졌다.

```json
{"store": "...", "amount": 12000}

정규식으로 펜스를 벗기는 대신 요청에 `response_mime_type="application/json"`를 박으니 펜스 없이 순수 JSON으로 돌아온다. 후처리 정규식을 짜기 전에 이 옵션부터 확인하는 게 맞다.

결론은 내 워크로드 한정이다. 정확도가 생명인 도메인이면 이 글은 무시해도 된다. 내 케이스는 정확도보다 처리량·비용이 중요해서 인쇄체 비중이 높은 점까지 보고 Flash로 굳혔다. 손글씨 비중이 높으면 결과가 다를 것이다.