근거는 맞았는데 옮겨 적기가 틀리는 문제
모델이 올바른 판례를 검색해 놓고도 사건번호 한 글자를 잘못 옮겨 적는 오류는, 검색 실패와는 다른 층위에서 다른 방식으로 잡아야 합니다.
초록 환각(hallucination)을 논할 때 흔히 '근거가 없는데 지어냈는가'만 살핍니다. 그러나 실무에서는 전혀 다른 오류 유형이 반복됩니다. 모델이 올바른 근거 자료를 검색·주입받았음에도, 그 근거를 답변에 옮겨 적는 과정에서 세부 표기(사건번호·조문 항 번호·날짜)를 미세하게 틀리는 오전사(誤轉寫) 오류입니다. 이 글은 이 두 오류 유형을 구분하고, 검색-교정(retrieve-and-revise) 패러다임과 원자적 사실 검증 개념을 빌려 법마디 OS가 실제로 구현한 DOCKET_REPAIR 메커니즘의 설계 원리를 분석합니다.
2026년 7월, 법마디 OS의 품질 점검 로그에서 흥미로운 실패 사례가 하나 포착됐습니다. 재산분할 관련 질의에 답하며 모델은 프롬프트에 정확히 주입된 판례 '2000므582'를 근거로 삼았습니다. 그런데 정작 최종 답변 본문에는 '2000스582'라는, 존재하지 않는 사건번호가 적혀 있었습니다. 검색은 완벽했습니다. 옮겨 적는 과정에서 한 글자가 바뀐 것입니다. 이 오류는 기존의 환각 탐지 프레임과 잘 들어맞지 않습니다. 근거가 없어서 지어낸 것이 아니라, 근거는 있었는데 전사(轉寫) 과정에서 손상된 것이기 때문입니다. 이런 오류를 다루려면 '근거가 있는가'를 넘어 '옮겨 적은 결과가 근거와 정확히 일치하는가'를 별도로 검증하는 계층이 필요합니다.
핵심 기술 개념
오전사(誤轉寫, Transcription Error)
모델이 올바른 근거 자료를 확보했음에도, 그 내용을 답변으로 옮겨 적는 과정에서 발생하는 세부 표기 오류입니다. 검색·그라운딩 실패와는 원인이 다릅니다.
검색-교정(Retrieve-and-Revise)
모델의 초안 생성을 그대로 신뢰하지 않고, 초안을 다시 검색 근거와 대조해 불일치하는 부분만 교정하는 후처리 패러다임입니다.
원자적 사실(Atomic Fact)
긴 문장을 더 이상 쪼갤 수 없는 최소 단위의 개별 사실 진술로 분해한 것으로, 문장 전체가 아니라 사실 단위로 진위를 판정할 수 있게 합니다.
충실성(Faithfulness)
모델의 출력이 실제로 존재하는 사실인지(정확성)와는 별개로, 주어진 근거 자료의 내용을 얼마나 정확히 반영하는지를 가리키는 개념입니다.
기술 심층 분석
두 개의 서로 다른 실패: 근거 부재와 근거 손상
인용 오류는 원인에 따라 최소 두 층위로 나뉩니다. 첫째는 애초에 근거가 없는데도 답을 만들어내는 경우로, 이는 검색·그라운딩 단계에서 막아야 합니다. 둘째는 근거는 정확히 검색됐지만 그 근거를 답변 문장으로 옮기는 생성 단계에서 세부 표기가 손상되는 경우입니다. 법마디 OS의 실제 사고 사례에서, 판례 '2000므582'는 프롬프트에 정확히 주입돼 있었습니다. 모델은 그 판례의 법리(재산분할 기준)를 정확히 이해하고 활용했지만, 사건번호를 옮겨 적으며 '므'를 '스'로 잘못 표기했습니다. 이 두 실패는 발생 지점이 다르므로 대응도 달라야 합니다. 근거 부재는 검색 단계에서 차단하는 것이 정답이지만, 근거 손상은 생성 이후 별도의 대조·교정 단계가 있어야만 잡을 수 있습니다. 하나의 게이트로 두 문제를 동시에 해결하려 하면 둘 다 어설프게 처리하게 됩니다.
검색-교정 패러다임: 초안을 신뢰하지 않는 설계
구글 리서치가 제안한 RARR(Researching and Revising What Language Models Say) 프레임워크는 모델의 첫 출력을 최종본이 아니라 '초안'으로 취급합니다. 초안에서 검증이 필요한 주장을 뽑아 그 주장을 뒷받침할 근거를 별도로 검색하고, 검색된 근거와 초안이 어긋나면 초안을 근거에 맞게 수정합니다. 이 구조의 핵심은 생성과 검증을 하나의 호출로 합치지 않는다는 점입니다. 법마디 OS의 DOCKET_REPAIR 메커니즘도 같은 철학을 따릅니다. 모델이 생성한 답변에서 사건번호를 추출한 뒤, 그 사건번호가 검증 자산에 존재하지 않으면 곧바로 삭제하는 대신, 동일 연도·접수번호를 가진 '표기만 다른' 후보가 검증 자산에 있는지부터 조회합니다. 즉 삭제를 최종 판단으로 삼지 않고, 교정 가능성을 먼저 검토하는 구조입니다.
원자적 사실 단위로 대조해야 하는 이유
FActScore 논문은 긴 텍스트의 사실성을 평가할 때 문장 전체를 하나의 단위로 보지 말고, 더 이상 쪼갤 수 없는 개별 사실(원자적 사실)로 분해해 각각을 독립적으로 검증해야 정확한 평가가 가능하다고 제안합니다. 인용 오전사 탐지에도 같은 원리가 적용됩니다. '대법원 2000. 2. 28. 선고 2000므582 판결, 재산분할 기준'이라는 인용을 하나의 덩어리로 검증하면, 사건번호 한 글자의 오류가 전체 인용의 무결성 문제로 뭉뚱그려집니다. 반면 법원명·선고일·사건번호·판시요지를 각각의 원자적 단위로 쪼개 대조하면, '사건번호만 틀렸고 나머지는 정확하다'는 세밀한 진단이 가능해집니다. 이 세밀한 진단이 있어야만 '전체 삭제'가 아니라 '해당 필드만 교정'이라는 더 나은 대응이 가능해집니다.
교정은 새로운 환각을 만들 수 있다 — 3중 가드의 필요성
여기서 위험한 함정이 있습니다. '표기가 비슷하니 교정하자'는 판단 자체가 잘못된 판례를 정답으로 둔갑시키는 새로운 환각을 만들 수 있습니다. 예를 들어 '2000다582'와 '2000므582'가 둘 다 실재하는 서로 다른 사건이라면, 어느 쪽이 모델의 진짜 의도였는지 표기 유사성만으로는 알 수 없습니다. 법마디 OS의 DOCKET_REPAIR는 이 위험을 세 겹의 가드로 통제합니다. 첫째, 후보가 유일해야 합니다. 동일 표기로 실재하는 이종 사건이 있으면 모호하다고 보고 교정을 포기합니다. 둘째, 인용 문맥과 검증 자산의 판시요지가 실제로 내용상 일치해야 합니다. 표기만 비슷하고 내용이 다르면 교정하지 않습니다. 셋째, 교정된 사건번호가 실제로 존재함을 다시 한번 확인합니다. 이 세 조건을 모두 통과했을 때만 교정하고, 하나라도 어긋나면 기존의 안전한 기본값, 즉 삭제로 되돌아갑니다.
인용 생성과 인용 검증을 분리하는 이유
ALCE(Enabling Large Language Models to Generate Text with Citations) 연구는 모델이 문장을 생성하면서 동시에 인용을 붙이는 방식과, 생성 이후 별도 단계에서 인용의 정확성을 평가하는 방식을 구분해 다룹니다. 이 구분이 중요한 이유는, 생성 시점의 모델은 유창함과 근거 반영을 동시에 최적화하려 하다 보니 세부 표기의 정확성이 희생되기 쉽기 때문입니다. 반면 생성이 끝난 뒤 별도의 검증 단계에서는 오직 '이 표기가 근거와 정확히 일치하는가'만을 목적으로 대조할 수 있어 더 엄밀합니다. 법마디 OS의 아키텍처가 생성(Stage 2)과 검증(Stage 4)을 물리적으로 분리해 둔 것도 같은 이유입니다. 생성 단계는 자연스러운 답변을 만드는 데 집중하고, 검증 단계는 그 결과물이 실제 근거와 한 글자도 다르지 않은지를 독립적으로 재확인합니다.
기술적 트레이드오프
긴장 관계 교정을 적극적으로 허용할수록 더 많은 콘텐츠를 살릴 수 있지만, 잘못된 교정이 새로운 오류를 만들 위험도 함께 커집니다. 반대로 교정을 전혀 허용하지 않고 무조건 삭제하면 안전하지만, 명백히 사소한 오타 하나 때문에 정확한 법리 설명 전체가 통째로 사라지는 손실이 발생합니다.
실무적 해소 법마디 OS는 이 긴장을 '교정의 기본값은 삭제'라는 원칙으로 해소합니다. 즉 교정은 예외적으로만 허용되는 상향 조정이며, 유일성·내용일치·존재재확인이라는 세 조건을 모두 통과했을 때만 발동합니다. 세 조건 중 하나라도 애매하면 즉시 기존의 안전한 기본 동작(삭제)으로 복귀합니다. 이렇게 설계하면 교정 기능이 새로운 환각 통로가 될 위험을 최소화하면서도, 확실히 안전하다고 판단되는 오전사만 선별적으로 구제할 수 있습니다. 완전 자동화된 판단이 아니라 다중 가드를 통과한 경우에만 작동하는 '보수적 교정'이 핵심입니다.
법마디 OS에 적용한다면
현재 DOCKET_REPAIR는 판례 사건번호의 오전사만을 대상으로 합니다. 이 설계를 다른 엔티티 유형으로 일반화할 수 있습니다. 예를 들어 조문의 항·호 번호가 프롬프트에는 정확히 주입됐는데 답변에서 다른 항으로 바뀌어 옮겨 적히는 경우, 또는 날짜나 금액이 근거 자료와 미세하게 다르게 표기되는 경우에도 같은 3중 가드(유일 후보·내용일치·존재재확인) 구조를 그대로 적용할 수 있습니다. 이를 위해서는 엔티티 유형별로 '유사 후보를 찾는 방법'과 '내용 일치를 판정하는 방법'을 각각 정의하는 공통 인터페이스가 필요합니다. 사건번호는 연도·접수번호가 같고 부호만 다른 후보를 찾지만, 조문 항 번호는 같은 조문 안에서 실재하는 항 목록을 대조하는 방식이 될 것입니다. 이렇게 엔티티별 탐지·교정 로직을 공통 프레임으로 추상화하면, 향후 새로운 오전사 패턴이 발견될 때마다 전체 파이프라인을 새로 설계하지 않고 해당 엔티티의 후보탐색·일치판정 함수만 추가하면 되는 확장 가능한 구조를 만들 수 있습니다.
기술적 함의
- 환각 방지는 '근거의 존재 여부'만이 아니라 '근거를 옮겨 적은 결과의 정확성'까지 별도로 검증해야 완결됩니다.
- 자동 교정 기능은 그 자체로 새로운 오류의 통로가 될 수 있으므로, 교정의 기본값은 항상 '더 안전한 쪽(삭제)'이어야 하며 교정은 엄격한 조건을 통과했을 때만 예외적으로 허용해야 합니다.
- 생성과 검증을 하나의 호출로 합치지 않고 물리적으로 분리할수록, 각 단계가 유창함과 정확성이라는 서로 다른 목표에 온전히 집중할 수 있습니다.
"완벽한 검색보다 어려운 것은, 완벽하게 검색된 근거를 한 글자도 틀리지 않고 옮겨 적었는지를 의심하는 일입니다."
