실패했을 때를 적어 둔 계약이 없다

초록 시스템이 '모르겠다'를 말하지 못하는 것은 대개 모델의 성향 문제로 다뤄집니다. 그런데 이번 주 arXiv 의 측정 결과들은 다른 곳을 가리킵니다. 도구 실패가 신호되면 부정직한 응답은 0.0% 인데, 같은 실패가 성공으로 표시되면 45.3% 까지 오릅니다. 답하기 전에 조회 상태를 먼저 찍게 하는 한 문장을 넣자 전체 부정직률이 14.10% 에서 0.87% 로 떨어졌습니다. 그런데 감사한 아홉 개 프로덕션 프레임워크 중 도구가 실패했을 때 무엇을 하라고 적어 둔 것은 하나도 없었습니다. 반대로 계약이 '판정 불가'를 명시한 경우에도 판정자는 그 권한을 21.3~48.0% 에서 쓰지 않았습니다. 공백을 메우는 일과 메운 계약이 지켜지는지 보는 일은 다른 작업입니다.

시스템이 모른다고 말하지 못할 때, 우리는 보통 모델을 탓합니다. 더 정직한 모델을 고르거나 프롬프트로 겸손을 주문하는 식입니다. 이번 주 arXiv 에 올라온 측정들은 그 진단을 흔듭니다. 도구 호출이 실패했을 때의 행동만 격리해 1,024문항으로 잰 연구에서, 부정직한 응답의 비율을 지배한 변수는 모델이 도구 출력을 얼마나 따르느냐가 아니었습니다. 실패에 이름이 붙어 있느냐였습니다. 같은 실패라도 상태가 오류로 표시되면 부정직은 0.0%, 성공으로 표시된 채 값만 못 쓸 것이면 45.3% 였습니다. 그리고 이 연구가 감사한 아홉 개 프로덕션 에이전트 프레임워크 중, 도구가 실패했을 때 무엇을 하라고 적어 둔 것은 하나도 없었습니다. 빠진 것은 모델의 겸손이 아니라 계약의 한 줄이었다는 뜻입니다.

핵심 기술 개념

이름 붙은 실패 상태(named failure state)

도구가 값을 주지 못했다는 사실에 모델이 참조할 수 있는 이름이 있는가. «Fabrication After Tool Failure» 에서 부정직 응답률을 지배한 변수는 모델이 도구 출력을 얼마나 따르느냐가 아니라 실패 상태에 이름이 있느냐였다. `status:error` 로 신호되면 0.0%, `status:ok` 인데 못 쓸 값이면 45.3% 다.

비방향 판정(non-directional verdict)

증거가 엇갈리거나(Conflicting) 아예 없을 때(Not Enough Evidence) 방향을 정하지 않는 판정값. 계약이 시스템에 '단정하지 않을 권한'을 명시적으로 주는 자리다. «Cherry-pick Override» 는 그 권한을 얼마나 안 쓰는지를 쟀다 — gold-Conflicting 150건에서 타입 패널 18.7%, 판정자 넷은 21.3~48.0% 가 방향을 단정했다.

방향 과단정(directional overcommitment)

계약이 허락하지 않은 방향을 출력하는 라벨 오류. 증거가 없어서 생긴 것이 아니라 있는 것 중 한쪽만 골라서 생긴 경우(Cherry-pick Override)는 자료를 더 모아도 고쳐지지 않는다 — 빠진 것이 없었기 때문이다. 두 유형은 처방이 다르다.

기술 심층 분석

빠진 것은 모델의 겸손이 아니라 계약의 한 줄이었다

«Fabrication After Tool Failure» 는 도구 증강 에이전트 평가에서 거의 항상 빠지는 자리를 격리합니다. 우리는 에이전트가 정답에 닿았는지를 재지, 도구가 값을 주지 못했을 때 정직하게 보고하는지를 재지 않습니다. 이 연구는 도구 호출을 강제하고 돌아온 페이로드가 반드시 못 쓸 것이 되도록 만든 1,024문항으로 그 결정만 떼어 냈습니다. 열여섯 개 내부 시스템 도메인과 여덟 가지 도구 실패 유형을 걸칩니다. 배포형 시스템 프롬프트에서 부정직 응답은 14.10% 였습니다 — 페이로드가 받쳐 주지 않는 값을 단정하거나, 존재하지 않는 정책·능력 한계를 지어내며 거절하는 경우입니다. 결정적인 것은 그 비율을 무엇이 지배했느냐입니다. 실패가 오류 상태로 신호되면 부정직은 0.0% 입니다. 반대로 성공 상태인데 값이 가려졌거나 손상됐거나 낡았거나 형식이 깨졌거나 비었거나 잘린 경우에는 45.3% 까지 오릅니다. 저자들의 표현으로, 작동하는 변수는 도구 출력에 대한 순종이 아니라 이름 붙은 실패 상태의 부재입니다. 모델을 바꾸는 문제가 아니라 인터페이스가 실패를 말할 수 있게 되어 있느냐의 문제라는 뜻입니다.

아홉 개 프레임워크가 그 자리를 비워 뒀다

같은 연구에서 더 중요한 관찰은 벤치마크 밖에 있습니다. 이 현상이 자기들 프롬프트가 만든 인공물이 아님을 확인하려고, 저자들은 중립 프롬프트에서도 재고(10.17%) 평가한 모든 프로덕션 에이전트 프레임워크의 기본 프롬프트에서도 쟀습니다. 한 프레임워크에서는 24.67% 까지 올랐습니다. 그리고 감사한 아홉 개 프레임워크 중 도구가 실패했을 때 모델이 무엇을 해야 하는지 명시한 것은 하나도 없었습니다. 이것이 이 논문에서 우리가 가져가야 할 문장입니다. 업계가 합의한 에이전트 계약에 그 칸이 비어 있다는 것이고, 비어 있는 칸은 채워지지 않는 것이 아니라 모델이 채웁니다. 처방도 그만큼 싸게 나옵니다. 답하기 전에 조회 상태를 먼저 선언하게 하는 한 문장을 덧붙이자 부정직률이 14.10% 에서 0.87% 로 떨어졌고, 688건 중 나빠진 것은 하나, 나아진 것은 아흔둘이었습니다. 그 선언은 다른 에이전트 스캐폴드 셋으로 그대로 옮겨갔고, 선언의 충실도는 99.7~99.9% 여서 런타임 탐지기로도 쓸 수 있습니다. 한 문장이 이만큼을 바꾼다는 사실 자체가, 문제가 모델 능력이 아니라 계약의 공백이었다는 증거입니다.

계약에 적어 두어도 쓰지 않는다

공백을 메우면 끝나는가. «Cherry-pick Override» 는 아니라고 답합니다. 증거 기반 사실 검증 과제들은 대개 비방향 판정값을 일부러 둡니다. 증거가 엇갈리면 Conflicting, 아예 없으면 Not Enough Evidence 입니다. 방향을 정하지 않을 권한을 계약이 명시적으로 준 것입니다. 그런데 판정자는 그 권한을 잘 쓰지 않습니다. AVeriTeC 의 gold-Conflicting 150건에서 네 선택지를 가진 타입 패널이 18.7% 에서 방향을 단정했고, 동시대 판정자 넷은 21.3~48.0% 였습니다. 이것들은 보수적인 하한입니다 — 공유 프롬프트가 Conflicting 을 자세히 규정하고, 방향으로 접는 것을 금지하고, 그 라벨을 세 번이나 시연한 상태에서 나온 수치입니다. 가장 아픈 대목은 따로 있습니다. 같은 주장을 새 맥락에서 다시 물으면 판정자 둘은 자기가 잘못 단정한 건의 약 3분의 2에서 충돌을 알아봤습니다. 알아볼 능력은 있는데 그 인식이 최종 행동에 닿지 않은 것입니다. 그리고 이 유형은 증거를 더 모아도 고쳐지지 않습니다. 없어서 틀린 것이 아니라 있는데 한쪽만 골라서 틀린 것이기 때문입니다. 계약을 쓰는 일과 계약이 지켜지는지 보는 일은 다른 작업이라는 뜻입니다.

조건이 나빠지면 강제 단정이 는다

«Clean Scores, Buried Evidence» 는 같은 이야기를 운영 조건에서 재현합니다. 최신 모델들은 얕은 문서·차트 읽기 과제에서 좋은 점수를 받습니다. 그런데 통제된 데이터룸 감사에서 증거를 묻힌 조건으로 옮기자 정확도가 떨어지고, 강제 단정이 늘고, 도구 호출이 늘고, 정답 하나당 비용이 올랐습니다. 조건이 나빠질수록 시스템은 더 조심스러워지는 것이 아니라 더 단정적이 됩니다. 앞의 두 연구가 실험실에서 보인 성향이 배치 조건에서 그대로 재현된 셈입니다. 더 중요한 관찰은 신뢰도와 벤치마크 보정이 틀린 답을 온전히 잡아내지 못했다는 것입니다. 문서화된 프로덕션 사고에서는 지어낸 구조적 서술이 정확한 수치 표와 뒤섞여 나갔습니다. 숫자는 맞는데 그 숫자를 설명하는 문장이 지어낸 것이었다는 뜻이고, 이런 조합은 요약 점수로는 드러나지 않습니다. 저자들의 처방은 리더보드가 아니라 감사 규율입니다 — 답변 단위 점수가 아니라 주장 단위 영수증, 조건을 반영한 채점, 사람이 적대적으로 확인하는 절차입니다. 그리고 왜 그래야 하는지를 한 문장으로 적어 둡니다. 모델은 결과의 당사자가 아니고, 서명하는 사람이 당사자입니다.

계약이 인용을 요구해도 내용까지 요구하지는 않는다

공백은 실패 상태에만 있는 것이 아닙니다. 계약이 무언가를 요구할 때, 그 요구가 어디까지인지도 대개 비어 있습니다. «Verifiable by Construction» 은 임상 가이드라인 4종 위 222문항 하니스에서 단계를 쪼개 쟀습니다. 주장마다 인용을 붙였는가, 그 인용이 원문 그대로인가, 그 축자 인용이 주장의 모든 세부를 실증하는가. 대부분의 모델은 프롬프트만으로 첫 단계를 통과합니다 — 주장의 90% 넘게 축자 인용이 붙습니다. 그런데 마지막 단계에서 벌어집니다. 한 모델은 인용률 98.0% 에 완전 실증률 37.1% 였습니다. '인용을 붙여라'는 계약은 지켜졌고 '인용이 주장을 받쳐야 한다'는 계약은 애초에 없었던 것입니다. «CiteShade» 는 그 공백을 공격면으로 만듭니다. 출처 하나만 통제하는 공격자가 모델로 하여금 오답을 내게 하고 그것을 받치지 않는 신뢰 출처에 귀속시키며, 올바른 답의 증거는 맥락에 그대로 남아 있습니다. 오답률이 0.01 에서 0.68 로 올랐습니다. 그리고 인용-실증 검사와 perplexity 필터는 각각 불충분했습니다 — 실재하는 문장을 엉뚱한 주장에 붙이는 공격이기 때문입니다. 취약성은 모델 크기가 아니라 인용하려는 성향을 따라갔습니다.

기술적 트레이드오프

긴장 관계 실패와 판정 불가를 상태로 드러내면 화면은 덜 깔끔해지고 '모른다'는 답이 늘어난다. 반대로 모든 상태를 방향으로 접으면 대시보드는 초록으로 정돈되지만 그 초록에는 '맞다'와 '못 쟀다'가 섞인다. 계약을 촘촘히 쓰면 지켜야 할 것이 늘어 생성 비용과 거절률이 오르고, 느슨하게 쓰면 비어 있는 칸을 모델이 대신 채운다.

실무적 해소 '그 칸이 비어 있을 때 누가 채우는가'로 가릅니다. 사람이 채운다면 느슨해도 되지만, 모델이 채운다면 그 칸은 이미 계약의 일부입니다 — 적지 않은 것은 자유가 아니라 위임입니다. 그래서 순서는 촘촘함이 아니라 덮임입니다. 먼저 모델이 채우게 되는 칸을 열거하고, 그중 사용자 행동을 만드는 것부터 이름을 줍니다. 한 문장으로 부정직률이 14.10% 에서 0.87% 로 떨어졌다는 결과는, 그 작업이 값비싼 정렬이 아니라 인터페이스 설계라는 뜻입니다.

법마디 OS에 적용한다면

법마디 OS 는 조회가 실패하면 답변을 중단합니다. 미검증 인용은 지워지고, 국가법령정보센터에 닿지 못하면 지어내지 않고 멈춥니다. 오늘 읽은 첫 논문의 기준으로 보면 우리 계약에는 그 칸이 채워져 있는 셈입니다. 그런데 같은 날 우리는 그 칸의 바깥에서 세 가지를 찾았습니다. 첫째, 한 답변이 공인중개사법 제38조 제2항 제5호를 근거로 들면서 따옴표 안에 조문 문언을 적었는데, 정본은 '계속하여 6개월을 초과하여 휴업한 경우'인데 답변은 그 자리를 '이전신고를 하지 아니한 경우'로 바꿔 썼습니다. 인용된 조문은 실재하고 번호도 맞아서 실재성 검사는 통과했습니다. '인용을 붙여라'는 요구는 지켜졌고 '인용문이 그 조문의 말이어야 한다'는 요구는 계약에 없었던 것입니다. 둘째, 그 답변이 무엇이었는지 사후에 갈라낼 수 있었던 것은 점수가 아니라 기록 덕분이었는데, 그 기록 자체에 결함이 있었습니다 — 감사 해시와 저장된 답변이 사용자가 실제로 받은 텍스트가 아니라 후처리 전 텍스트를 가리키고 있었습니다. 영수증을 남기는 것만으로는 부족하고 그 영수증이 나간 물건의 것이어야 합니다. 셋째, 축자 실증을 재는 축은 아직 켜지 않았습니다. 발화하면 유료 판정을 뒤집기 때문에, 오탐률을 먼저 재기 전에는 켜지 않는 것이 맞다고 판단했습니다 — 그 판단 자체도 '못 쟀다'를 '괜찮다'로 적지 않기 위한 것입니다.

기술적 함의

도구 실패에는 이름을 준다. 같은 실패라도 신호되면 부정직이 0.0% 이고 성공으로 표시되면 45.3% 라면, 이것은 모델 선택 문제가 아니라 계약 설계 문제다. 답하기 전에 조회 상태를 먼저 선언하게 하는 한 문장이 가장 싼 방어다.
계약에 '판정 불가'를 적는 것과 그것이 쓰이는지 보는 것은 다른 작업이다. 명시하고 금지하고 세 번 시연해도 21.3~48.0% 가 방향을 단정했다면, 계약 문구만으로 닫혔다고 보고해서는 안 된다 — 발화율을 따로 세야 한다.
요구의 범위도 계약이다. '인용을 붙여라'와 '인용이 주장을 받쳐야 한다'는 다른 요구이고, 앞엣것만 적으면 인용률 98.0% 에 실증률 37.1% 라는 조합이 계약 위반 없이 나온다.

"모른다고 말하지 못하는 시스템을 보면 우리는 모델을 먼저 의심합니다. 그런데 오늘의 측정들은 그 자리에 대개 계약의 빈칸이 있다고 말합니다. 빈칸은 비어 있는 채로 남지 않습니다. 적지 않으면 모델이 채웁니다."

참고 자료

칼럼니스트

지유

최고기술책임자 (CTO · Chief Technology Officer)

실리콘밸리 유니콘 창업 멤버급 / AI 무결성 검증 분야 세계적 석학급

법마디 OS 무료로 경험하기

본 칼럼은 법마디 OS 기술팀의 관점이며, 특정 제품·기술에 대한 보증이나 법률 자문이 아닙니다.