스스로 정답을 못 보는 시험을 설계한 이유: 정답 비공개 홀드아웃 검증

3줄 요약

• 사건 파일 뭉치를 흐름·당사자·증거·모순·기한으로 구조화하는 엔진을, 구현한 쪽이 정답을 절대 못 보는 방식으로 검증했다.
• 이게 중요한 이유는 법률 도구의 진짜 자산이 화면이 아니라 그 밑 엔진이고, 엔진의 신뢰도는 "누가 채점하느냐"가 아니라 "만든 사람이 답을 볼 수 있느냐"에서 갈리기 때문이다.
• 빌더에게 남는 교훈은 하나다. 규칙으로 못 넘는 선을 만나면, 억지로 넘기지 말고 "확정" 대신 "확인 요망"으로 낮춰라.

검증의 신뢰도는 채점자가 아니라 정답 접근권에서 갈린다

만든 사람이 정답표를 손에 쥐고 있으면 그건 검증이 아니라 자기 채점이다. 그래서 이번에는 역할을 셋으로 쪼갰다. 시험 문제를 내는 쪽, 정답표를 보관하는 쪽, 그리고 실제로 엔진을 돌려 결과만 제출하는 구현 쪽. 구현하는 나는 정답을 한 글자도 열지 않았다. 새 문제 다섯 건을 정답 없이 입력만 받아 엔진에 통과시키고, 원시 출력과 빌드 지문만 넘겼다. 채점은 정답을 쥔 다른 쪽이 한다.

이 구조가 번거로워 보여도 이유는 분명하다. 이미 손에 익은 서른 건짜리 깨끗한 데이터로는 백 퍼센트가 나온다. 그런데 그 서른 건은 내가 만들면서 구조를 다 아는 데이터다. 처음 보는 다섯 건을 넣자마자 그동안 안 보이던 구멍이 드러났다. 이건 실패가 아니라 값이 나가는 실패다. 출시 전에 발견했으니까.

무회귀 원칙, 새 걸 잡으려다 있던 걸 깨면 배포 금지

새 케이스를 잡으려는 어떤 변경도 기존 깨끗한 데이터의 정확도를 떨어뜨리면 그 즉시 되돌린다. 이게 하루 종일 나를 붙잡은 규칙이었다.

• 처음 보는 사건에서 금액 모순을 잡으려고 동의어 처리를 넣었더니 깨끗한 데이터 정확도가 백에서 아흔둘로 내려갔다. 즉시 롤백.
• 문장 단위로 문맥을 다시 끊어보려 했더니 이번엔 예순셋까지 무너졌다. 다시 롤백.
• 결국 실제 문서의 자동 줄바꿈이 만드는 가짜 문장 경계를 좌표로 구분하는 방식만 살아남았다. 이건 깨끗한 데이터를 건드리지 않으면서 실제 파일만 고쳤다.

시도 세 번 중 두 번은 통째로 되돌렸다. 남은 건 기준선 하나뿐이었다. 검증에서 무회귀는 "발전이 느려도 신뢰가 무너지지 않는다"는 뜻이다. 법률 도구에서는 이 순서가 반대면 안 된다.

규칙이 못 넘는 선을 인정하는 게 설계다

같은 형태라도 의미가 다르면 규칙만으로는 구분할 수 없다. 이날 가장 값진 발견이었다.

한 사건에서 원고가 "빌려준 돈 3천만"이라 쓰고 피고가 "빌린 돈 2천5백"이라 쓰면 이건 진짜 금액 다툼이다. 그런데 다른 사건에서는 같은 단어 조합이 원금과 잔액을 가리키는, 모순이 아닌 경우였다. 둘은 겉모양이 똑같다. 구분하는 유일한 기준은 "이게 같은 원금 인스턴스를 가리키느냐"라는 의미 판단이고, 이건 동의어 사전으로는 절대 못 한다.

그래서 결론은 억지로 규칙을 늘리는 게 아니라 등급을 나누는 것이었다. 수치가 같은 항목에서 확실히 충돌하면 "확정 모순", 당사자 진술이 반대로 갈리지만 확신이 어려우면 "확인 요망 후보", 근거가 부족하면 "미분류". 후보에는 화면에 "당사자 진술이 다를 가능성이 있으니 원문을 확인하십시오"라고만 띄운다. 확정이라고 우기지 않는다.

여기서 재미있는 반전이 있다. 이 도구는 법적 판단을 하지 않고 구조만 잡는다. 개인 사용자에게는 이게 제약처럼 보이지만, 변호사에게는 오히려 정확히 원하는 모습이다. 변호사는 AI가 대신 판단하는 걸 원하지 않는다. 파일을 정리하고 흐름을 지도로 보여주기만 바란다. 우리의 제약이 그들의 필요 기능과 같은 지점에서 만난다.

오늘 관통한 판단 하나

검증을 설계할 때 가장 먼저 물어야 할 것은 "채점을 누가 하느냐"가 아니라 "만든 사람이 정답을 볼 수 있느냐"였다. 정답 접근을 끊는 순간, 백 퍼센트가 나오던 데이터가 감추고 있던 구멍이 드러난다. 그리고 규칙이 못 넘는 선을 만나면 그 선을 인정하고 등급을 낮추는 편이, 억지로 규칙을 늘려 신뢰를 깎는 것보다 낫다. Receipts not promises. 오늘의 영수증은 정답을 스스로 숨긴 시험지 한 장이다.