만약 여러분이 LLM 판사 (LLM judge)를 루프에 포함하여 무언가를 구축하고 있다면, 이것은 여러분을 함정에 빠뜨릴 실패 모드(failure mode)이며, 여러분은 그것이 일어나는 것을 알아차리지 못할 것입니다. 저 또한 그 반대의 경우를 찾으러 가기 전까지는 알아차리지 못했습니다.

사건이 일어난 순서대로 이야기를 들려드리겠습니다.

내가 만들고 있었던 것

저는 특정한 것을 측정하고 싶었습니다. AI 코딩 에이전트 (AI coding agent)가 단순히 파일 하나를 읽는 것을 넘어, 실제 코드베이스 (codebase)를 탐색하며 "내가 이것을 변경하기 전에, 어디에서 이 모델에 의존하고 있는가?"라는 질문에 답할 수 있는가 하는 점입니다. 이것은 유지 관리자 (maintainer)가 위험한 리팩토링 (refactor)을 하기 전에 머릿속으로 답하는 질문이며, 에이전트가 자신 있게 틀리기 쉬운 질문이기도 합니다.

그래서 저는 벤치마크 (benchmark)를 구축했습니다. 실제 앱의 핵심 모델인 Chatwoot의 Inbox를 선택하고, 에이전트에게 제거 변경 (teardown change)을 수행하기 전에 모든 의존성 (dependent)을 찾아내라고 요청했습니다. 두 가지 방식으로 실행했습니다. 하나는 grep을 사용하고 추론하는 일반적인 에이전트이고, 다른 하나는 쿼리할 수 있는 코드베이스의 구조적 지도 (structural map)를 전달받은 동일한 에이전트입니다. 동일한 모델, 동일한 프롬프트 (prompt), 동일하게 고정된 커밋 (pinned commit)을 사용했습니다. 그 차이를 측정했습니다.

이러한 벤치마크의 함정은 채점 (grading)에 있습니다. 수백 개의 감사 (audit) 결과를 눈으로 직접 확인할 수는 없습니다. 그래서 요즘 모두가 그러하듯, 저도 AI 판사 (AI judge)의 도움을 받았습니다. 모델에게 에이전트의 감사 내용을 전달하고, 분석이 얼마나 완전하고 정확한지 점수를 매기도록 요청했습니다. 저렴하고, 빠르며, 확장성이 좋습니다.

그 결정이 전체 프로젝트를 거의 침몰하게 만들 뻔한 결정이었습니다.

무승부처럼 보였던 실행 결과

첫 번째 실제 시나리오인 Chatwoot를 실행했습니다. 두 가지 방식이 실행되었고, 판사가 점수를 매겼습니다.

판사는 두 결과가 무승부라고 판정했습니다.

그 결과는 저를 멈춰 세웠습니다. 왜냐하면 저는 두 가지 트랜스크립트 (transcript)를 모두 확인했기 때문입니다. 일반 에이전트는 흩어져 있는 의존성 몇 개를 찾고 멈췄습니다. 지도를 가진 에이전트는 전체 세트를 모두 훑었습니다. 두 감사는 결코 같지 않았습니다. 하나가 다른 하나보다 분명히 더 완전했습니다. 하지만 판사는 이를 구별하지 못했습니다.

저는 판사가 일반 실행에 대해 실제로 작성한 내용을 확인했습니다. 판사가 사용한 단어는 "철저하다 (exhaustive)"였습니다.

판사가 철저하다고 부른 감사는 44%만 완료된 상태였습니다.

왜 속았는가

이 메커니즘은 여러분이 구축하게 될 모든 평가 (eval)에 일반화될 수 있는 내용이기에 깊이 생각해 볼 가치가 있습니다.

판사는 각 답변을 그 자체의 가치로만 평가하고 있었습니다. 판사는 일반 에이전트(plain agent)의 감사(audit) 내용을 읽고, 그것이 잘 쓰였으며, 내부적으로 일관되고, 자신감이 있으며, 철저한 작업물처럼 구조화되어 있다고 판단했습니다. 나열된 모든 종속성(dependent)은 실제 존재하는 것이었습니다. 아무것도 조작되지 않았습니다. 텍스트 내부에서 사용 가능한 모든 신호로 볼 때, 그것은 완벽한 작업물처럼 보였습니다.

판사는 완벽한 작업물에 무엇이 포함되어야 하는지 전혀 몰랐습니다. 그런 사실을 전달받은 적이 없었기 때문입니다. 비교할 대상이 없었기에, "철저해 보인다"는 것이 판사가 점수를 매길 수 있는 유일한 축이었고, 일반 에이전트의 감사는 매우 철저해 보였습니다. 그것은 아름답게 쓰인 절반(half)에 불과했습니다.

이것이 바로 'AI가 AI를 평가하는(AI-grades-AI)' 모든 설정에 깔린 함정입니다. 판사는 자신이 평가하는 대상과 동일한 사각지대를 물려받습니다. 둘 다 동일한 텍스트를 읽고 있습니다. 둘 다 무엇이 '존재하지 않는지'는 알지 못합니다. 자신감 있고 유창하며 절반만 완성된 답변은 절반만 완성된 것처럼 읽히지 않습니다. 그것은 완성된 것처럼 읽힙니다. 그리고 "완성된 것처럼 읽힌다"는 점은 참조 기준(reference)이 없는 판사가 매달리게 되는 정확한 신호입니다.

이것은 제가 코딩 에이전트(coding agents)에서 폭로하기 위해 벤치마크 전체를 구축하고 있었던 바로 그 실패 사례였으며, 심지어 저의 채점 방식에도 스며들어 있었습니다. 벤치마크가 스스로를 치켜세울 뻔했으며, 저는 아무렇지 않게 그 결과(동점)를 발표했을 것입니다.

상황을 반전시킨 해결책

해결책은 더 나은 판사 모델을 사용하는 것이 아니었습니다. 참조 기준이 없는 더 똑똑한 모델은 똑같은 실수를 더 유창하게 저지를 뿐입니다.

해결책은 바로 참조 기준(reference)이었습니다.

실행 전, 저는 이미 수동으로 정답지(answer key)를 만들어 두었습니다. 소스 코드에서 추출하여 Inbox의 모든 실제 종속성을 정확한 file:line에 고정해 두었습니다. grep 검색으로 지나치기 쉬운 흩어진 11개의 종속성들은 에이전트들에게 보이지 않게 숨겨두었습니다. 저는 내내 정답 목록을 가지고 있었지만, 단지 판사에게 주지 않았을 뿐이었습니다.

그래서 저는 판사의 업무를 변경했습니다. 이것이 완성된 것처럼 읽히는지 평가하는 것을 중단시켰습니다. 대신, 정직한 감사라면 반드시 포함해야 할 검증된 목록을 제공하고, 각 항목을 체크하도록 했습니다. 찾았는지, 정확한 라인에 고정되었는지, 아니면 찾지 못했는지를 확인하게 한 것입니다.

그 즉시 동점 상황은 사라졌습니다. 매핑된 에이전트(mapped agent)는 모든 것을 커버했습니다. 단순한 에이전트는 절반만을 커버했습니다. 동일한 감사(audit)를 수행했고, 동일한 판사 모델(judge model)을 사용했습니다. 유일하게 변한 점은 판사가 이제 정답이 무엇이어야 하는지를 알고 있었다는 사실뿐입니다.

그 실험 이후, 전체 시리즈에서 정답 참조가 없는 판사(reference-blind judge)는 퇴출되었습니다. 그 이후 제가 발표한 모든 점수는 정답 참조 방식(reference-aware)이며, 고정된 정답 키(fixed key)를 기준으로 채점됩니다. 정답 근처를 모호하게 짚어내는 것에 대해서는 점수를 주지 않습니다. 인용(citation)이 정확한 라인에 위치해야 하며, 그렇지 않으면 점수로 인정되지 않습니다.

평가(evals)를 구축하는 모든 이를 위한 규칙

이 내용에서 한 가지만 기억한다면 다음과 같습니다.

정답 참조가 없는 LLM 판사는 정확성(correctness)을 측정하지 않습니다. 그것은 자신감(confidence)과 유창성(fluency)을 측정하고, 그에 대해 보상을 줄 뿐입니다.

만약 당신이 측정하고자 하는 것이 자신감이라면 괜찮습니다. 하지만 답변이 '맞는지'를 측정하고 있다고 생각한다면 그것은 재앙입니다. 답변이 틀렸지만 글은 잘 써진 경우, 즉 당신이 가장 잡아내야 하는 상황에서 이 두 가지는 정확히 분리됩니다.

구체적으로, 이 사건 이후 제 점수를 신뢰할 수 있게 만든 요소들은 다음과 같습니다:

→ 실행 전 미리 제작된 수동 정답 키(hand-built answer key): 이를 통해 평가 대상(bench)이 도구가 생성한 결과에 맞춰 '정답'의 정의를 몰래 재정의할 수 없도록 합니다.
→ 판사는 문장의 분위기(vibe)가 아니라 해당 키를 기준으로 채점합니다.
→ 모든 주장은 실제 file:line 단위로 확인됩니다. "올바른 영역을 언급함"과 같은 부분 점수는 없습니다.
→ 정답 키는 에이전트들에게는 숨겨져 있으며 오직 판사만이 볼 수 있습니다. 따라서 정보가 유출되는 대신 변별력을 발휘합니다.

이 중 특별하거나 생소한 것은 없습니다. 단지 당신을 당혹스럽게 만들 수 있는 평가와 그렇지 않은 평가 사이의 차이일 뿐입니다.

내 벤치마크를 넘어 이것이 중요한 이유

제가 이 이야기를 계속하는 이유는 벤치마크 때문이 아닙니다. 정답(ground truth) 없이 모델이 판단하게 두는 모든 곳에서 동일한 맹점이 나타나기 때문이며, 현재 그곳은 매우 많습니다. AI가 고객 지원 티켓을 채점하고, AI가 AI가 작성한 코드를 검토하며, AI가 자신의 RAG 답변을 채점하는 상황들 말입니다. 이 모든 경우에서 "출력이 읽기에 좋다"는 요소가 실제보다 훨씬 더 큰 역할을 하고 있으며, 유창하게 틀린 답변이 정답처럼 높은 점수를 받고 있습니다.

또한, 이것은 우연이 아니라 해당 벤치마크(benchmark)가 코딩 에이전트(coding agents)를 측정하기 위해 나아간 바로 그 지점이기도 합니다. 일반적인 에이전트의 감사(audit) 결과는 완성된 것처럼 읽히지만 실제로는 절반이 누락되어 있습니다. 구조적 지도(structural map)는 에이전트와 판사(judge)에게 믿어야 할 이야기가 아닌, 대조하여 확인할 수 있는 정답(ground truth)을 제공합니다. 지도는 무엇이 무엇에 의존하는지를 계산합니다. 추론하고 요행을 바라는 것이 아닙니다. 이것이 바로 단순히 더 똑똑한 모델을 기다리는 것이 아니라, 여러분의 에이전트에 지도를 연결(wiring)해야 하는 이유입니다. 더 똑똑한 모델은 더 설득력 있는 이야기꾼(storyteller)일 뿐이며, 설득력 있다는 점이 바로 문제입니다.

나를 속였던 버전을 실행해 보세요

이를 가장 명확하게 체감하는 방법은 제가 거의 속을 뻔했던 그 절반의 과정을 재현해 보는 것입니다.

여러분의 코드베이스에서 리팩터링(refactor)하기 불안한 모델을 하나 선택하세요. 그리고 에이전트에게 냉정하게 물으세요. "이 모델이 해체(torn down)되는 방식을 변경하기 전에, 이 모델에 의존하는 모든 곳을 찾아줘." 에이전트가 제공하는 감사 결과를 읽어보세요. 그것은 완벽해 보일 것입니다. 그것이 바로 함정입니다.

그런 다음, 대조할 수 있는 실제 참조(reference)를 제공하세요.

→ curl -fsSL https://luuuc.github.io/sense/install.sh | sh
→ 잘 모르는 저장소(repo)에서 sense scan 실행
→ 에이전트를 연결하기 위해 sense setup 실행

다시 질문하고, 두 결과의 차이(diff)를 확인하세요. 그 차이는 첫 번째 감사가 자신 있게 침묵했던 부분이며, 제 판사가 동점으로 평가했던 것과 동일한 간극입니다. 이를 직접 세어보는 것이 제가 보여드릴 수 있는 그 어떤 벤치마크보다 더 설득력이 있을 것입니다.

벤치마크, 정답지, 판사 프롬프트(judge prompts), 모든 트랜스크립트(transcript).

공개 사항: 저는 해당 실험에서 지도를 제작했습니다. 저를 당황하게 했던 판사를 포함하여 모든 것이 공개되어 있으므로, 저를 믿는 대신 직접 작업 내용을 확인하실 수 있습니다.

추신: 저는 여전히 44%만 완료된 감사 결과에 대해 판사가 "철저하다(exhaustive)"라고 작성한 로그를 가지고 있습니다. 그것은 제가 받아본 것 중 가장 유용한 오답이며, 그 이후로 제가 발표한 모든 점수 뒤에 정답지를 배치해 둔 이유이기도 합니다.