결제 파싱 오류를 LLM 교차검증으로 조기 포착한 정산 파이프라인 개선

파싱 데이터 신뢰도 문제

알림 페이로드에서 결제 정보를 뽑아 쓰는 파이프라인을 운영 중인데, 포맷이 자주 바뀜. 정규식으로 떠받치다가 한 글자 차이로 금액이 0원으로 들어가는 사고가 났음. 사후에 보면 "사람이 봤으면 다 보였을 텐데" 싶은 케이스가 대부분이라 LLM으로 한 번 더 훑게 했음.

왜 서버 프록시인가

클라이언트에서 직접 모델 호출하면 키 노출 + 요금 폭주 두 개 다 터짐. 그래서 백엔드에 검증 전용 중계 레이어를 하나 두고 정리함.

• 수집기는 원문(raw)과 1차 파싱 결과(JSON) 둘 다 게이트웨이로 넘김
• 게이트웨이는 모델 키를 들고 있고, 캐시·레이트리밋·프롬프트 템플릿 관리
• 검증기는 모델 응답을 정규화해서 1차 결과와 필드 단위로 비교

교차검증 규칙

핵심은 "LLM을 정답으로 두지 않는 것". 둘 다 의심하고 차이가 날 때만 사람이 보게 함. 모델 환각 한 방에 정산 데이터 오염되면 복구 비용이 훨씬 큼.

운영하면서 배운 것

[수집] -> [1차 파서] -> [게이트웨이] -> [LLM]
                \                /
                 [교차검증] -> 결과

• 프롬프트는 짧게. 원문 + 필드 스키마 + 예시 한 개면 충분. 길게 쓰니 오히려 환각 늘어남
• 캐시 키를 원문 해시로 잡아서 같은 알림이 재처리될 때 모델 안 부르게 했음. 비용이 거의 1/4 수준으로 떨어짐
• timeout은 짧게(2~3초). 검증은 어차피 비동기라 늦으면 1차 결과로 통과시키는 편이 나음
• "검증 결과가 의심스러움" 자체를 메트릭으로 뽑으니 1차 파서가 어디서 깨지는지가 한눈에 보임

회고

"파싱 정확도 100% 만들겠다"는 환상 버리고 "틀렸을 때 빨리 잡아낸다"로 방향 튼 게 컸음. 1차 파서는 더 안 건드리고 검증 레이어만 진화시키면 되니까 유지보수 부담도 줄었음. LLM을 단일 의사결정자가 아니라 두 번째 의견 으로 끼워 넣는 패턴은 다른 도메인에도 그대로 옮겨 쓸 만하다고 느꼈음. 다음