깨끗한 데이터로는 안 보이던 구멍: 진짜 법원 문서를 흉내 낸 스트레스 시험으로 파서를 다시 쟀다

3줄 요약

• 사건 파일을 흐름·당사자·증거·모순·기한으로 구조화하는 엔진을, 진짜 법원 문서를 흉내 낸 방해물 세트로 다시 측정하고 네 군데를 고쳤다.
• 이게 중요한 이유는 만든 사람이 통제하는 깨끗한 데이터에서 나온 만점이 제품의 실제 신뢰도가 아니기 때문이다. 진짜 문서에는 만든 사람이 예상하지 못한 잡음이 가득하다.
• 빌더에게 남는 교훈은 하나다. 고치기 전에 재라. 그것도 실제 사용 환경을 최대한 닮은 조건으로 재라.

깨끗한 시험은 만점인데 진짜 문서를 흉내 내니 다섯 중 하나만 맞혔다

측정 없이 고치면 무엇을 고쳤는지 모른다. 그래서 이번에는 손대기 전에 새 시험대를 먼저 만들었다. 실제 소장과 답변서를 흉내 낸 조건을 한곳에 모은 스트레스 세트다. 법원 이름과 사건 번호가 섞여 있고, 절차에 드는 비용 항목이 본안 금액 옆에 나란히 놓여 있고, 한글로 쓴 금액과 아라비아 숫자가 함께 붙어 있고, 여러 페이지에 걸쳐 있고, 스캔 인식 신뢰도가 낮은 대목과 별지가 들어 있다.

내가 직접 만들어 구조를 다 아는 깨끗한 서른 건에서는 백 퍼센트가 나온다. 그런데 같은 엔진을 이 스트레스 세트에 통과시키자 기준 점수가 다섯 중 하나로 떨어졌다. 노출된 구멍은 네 군데였다. 이건 실패라기보다 값이 나가는 측정이다. 출시 전에, 진짜 문서를 만나기 전에 드러났으니까.

방해물이 곧 제품의 실제 환경이다

파서가 흔들리는 지점은 대부분 진짜 문서에만 있는 잡음에서 나왔다. 법원 이름·사건 번호·절차 비용은 사람이 보면 당연히 배경이지만, 규칙 기반 엔진에게는 전부 본안 숫자의 주의를 빼앗는 미끼다. 네 군데 구멍의 뿌리를 하나씩 진단했다.

• 피고 쪽이 "얼마를 초과하지 않는다" 같은 상한 표현을 써서 원고 금액에 맞서는데, 표현 형태가 달라 서로 경쟁 대상으로 묶이지 못하고 그냥 지나쳐지던 문제.
• 절차에 드는 비용 항목이 바로 앞 문장의 본안 대상어에 잘못 달라붙어, 엉뚱한 청구 항목의 금액으로 오인되던 문제.
• 손해배상금처럼 금액이 수식하는 대상어인데 인식 목록에 없어서 아예 잡히지 않던 문제.
• "얼마를 공제한 금액"에서 나온 순액이, 공제된 항목 쪽으로 귀속돼 진짜 대상과 어긋나던 문제.

네 군데를 고치되, 하나도 기존 걸 깨지 않았다

새 걸 잡으려는 어떤 변경도 기존 깨끗한 데이터를 깨면 그 즉시 되돌린다는 규칙을 그대로 지켰다. 이번 네 건은 전부 무회귀로 통과했다. 스트레스 점수는 다섯 중 하나에서 다섯 중 다섯으로 올라갔고, 기존 관문 시험·오탐 없음·존부 판정·역할 분리는 전부 그대로였다.

과정에서 사소하지만 값진 실수도 하나 잡았다. 특정 표현을 걸러내려고 어미가 붙은 형태를 그대로 조건에 넣었더니, 조사가 붙은 실제 문장과 맞지 않아 작동하지 않았다. 어간만 남겨 조건을 다시 잡고서야 걸렸다. 남은 한 가지는 숫자 병기 없이 순수 한글로만 쓴 금액을 아직 못 읽는 대목인데, 실무에서는 대개 아라비아 숫자가 함께 붙어 검출되므로 우선순위를 낮췄다.

오늘 하루를 관통한 판단

고치기 전에 재라. 그리고 재는 조건은 내가 통제하는 깨끗한 데이터가 아니라 제품이 실제로 만날 환경을 닮게 만들어라. 만든 사람이 다 아는 데이터에서 나온 만점은 자신감은 줘도 신뢰도는 주지 못한다. 진짜 문서를 흉내 낸 방해물 앞에서 점수가 다섯 분의 일로 떨어지는 걸 눈으로 봐야, 무엇을 왜 고치는지가 분명해진다. 측정이 먼저고 수정은 그다음이다. 순서가 반대면 무엇을 고쳤는지도 모른 채 좋아진 기분만 남는다.

맥락

이 엔진의 진짜 자산은 개인용 앱 화면이 아니라 그 밑에서 사건 파일 뭉치를 구조화하는 부분이다. 판단을 내리지 않고 구조만 잡는다는 제약이, 오히려 프라이버시가 의무인 쪽에는 맞는 설계다. 어제 정답 비공개 홀드아웃으로 검증의 신뢰도를 세웠다면, 오늘은 그 검증대를 실제 문서에 더 가깝게 끌어당겼다. Receipts not promises.