AI 자체 검증 정확도, 다시 확인시킬수록 떨어진 이유

AI 에이전트가 만든 결과, 누가 맞다고 확인하나

에이전트에게 홈페이지 카피를 쓰게 하거나, 고객 문의 회신 초안을 뽑게 하거나, 코드 한 줄을 고치게 하는 일은 어렵지 않다. 어려운 쪽은 그다음이다 — 그 결과물이 실제로 맞는지 누가 확인하느냐다.

팀이 있으면 동료가 한 번 더 본다. 혼자서 이 일을 다 처리하다 보면 매번 사람이 붙어 확인할 시간이 없다. 그렇다고 확인을 건너뛰면 틀린 결과가 그대로 고객에게 나가는 위험을 그냥 떠안는 셈이 된다. 시간과 정확도 사이에서 하나를 포기해야 하는 구조였다.

더 곤란한 지점은 '얼마나 자주 틀리는지'조차 세어 본 적이 없었다는 것이다. 결과물을 보고 그때그때 감으로 '됐다' 또는 '아니다'라고 판단했을 뿐, 실패가 몇 건 중 몇 건인지, 어떤 유형의 실패가 반복되는지는 기록으로 남지 않았다. 판단 기준이 사람의 기분에 따라 매번 조금씩 달라지는 셈이었다.

숫자로 남지 않으면 개선됐는지도 알 수 없다. 지난주보다 이번 주에 결과물이 더 나아졌는지, 아니면 그저 운이 좋았던 것인지 구별할 방법이 없었다. 그래서 가장 먼저 필요했던 건 새 도구가 아니라, 지금 상태를 숫자로 붙잡아 두는 방법이었다.

그래서 처음 든 생각은 단순했다. AI에게 AI를 확인시키면 되지 않을까. 에이전트가 만든 결과물을 다른 AI에게 다시 보여 주고 판단을 시키거나, 같은 에이전트에게 '다시 한번 확인해 봐'라고 시키면 사람 손을 덜 들이고도 정확도를 끌어올릴 수 있을 것 같았다.

그런데 이 생각 자체에 함정이 하나 숨어 있었다. 판정 도구부터 먼저 만들고 그 도구가 잡아내는 항목만 문제로 보는 방식이다 — 실제로 어디서 실패가 나는지 보지도 않고 채점 기준부터 세우면, 채점하기 쉬운 항목만 채점하게 되고 정작 놓치면 안 되는 실패는 그대로 지나간다. 이 함정을 알아채지 못한 채로 자동 판정부터 만들었다면, 판정 결과가 좋아 보여도 실제 실패율은 그대로였을 가능성이 크다.

먼저 확인한 숫자 — AI 심사자는 전문가와 64~68%만 일치했다

AI에게 AI를 심사시키는 방법(LLM-as-Judge)을 실제로 도입하기 전에, 이 방법이 이미 얼마나 쓸 만한지부터 확인했다. 2025년에 나온 여러 연구를 찾아보니 답이 그렇게 밝지 않았다. AI 심사자가 내린 판단과 사람 전문가가 내린 판단이 일치하는 비율은 64%에서 68% 사이였다.

10건 중 3~4건꼴로 사람과 다른 판단을 내린다는 뜻이다. 게다가 이 불일치가 무작위로 흩어져 있지 않았다. 연구들은 위치 편향(먼저 보여준 답을 더 좋게 평가하는 경향)과 점수 편향(특정 점수대에 몰리는 경향)을 실제로 확인했다고 적고 있었다.

위치 편향은 특히 곤란했다. 같은 결과물이라도 심사자에게 어떤 순서로 보여 주느냐에 따라 점수가 달라진다는 뜻이었고, 이건 심사 대상의 품질과는 상관없는 문제였다. 점수 편향도 마찬가지였다 — 심사자가 특정 점수대로 몰리는 경향이 있으면, 그 점수는 결과물의 실제 수준보다 심사자의 습관을 더 많이 반영하게 된다.

이 숫자를 먼저 확인한 게 다행이었다. 만약 이 숫자를 안 보고 AI 심사자를 그대로 최종 판정으로 썼다면, 10건 중 3~4건은 틀린 판정을 정답으로 착각한 채 지나갔을 가능성이 크다. 그래서 이 시점부터 규칙 하나를 정했다 — AI 심사자를 쓰더라도 단독으로 쓰지 않고, 자동으로 도는 시험이나 사람이 직접 표본을 확인하는 절차와 반드시 같이 쓴다. 심사 프롬프트에도 왜 그렇게 판단했는지 근거를 적게 요구한다.

그래서 세운 가설 — 여럿이 함께 보면 나아질 것

AI 심사자 하나로는 부족하다는 걸 알았으니, 다음 가설은 자연스러웠다. 하나가 아니라 여럿에게 물으면 어떨까. 사람 조직에서도 중요한 결정은 한 사람이 아니라 여러 명의 의견을 모아 내리는 경우가 많다. 그 방식을 그대로 옮기면 통할 듯했다.

• 가설 A — AI 여러 개(예: 4개)를 한 그룹으로 묶어 토론을 시키고 다수결로 최종 판단을 낸다
• 가설 B — 심사자를 따로 두지 않고, 결과물을 만든 에이전트 자신에게 '다시 확인해 봐'라고 한 번 더 시킨다
• 가설 C — 이미 널리 쓰이는 공개 벤치마크 점수를 기준으로 삼아, 우리 상황에 맞는 시험 문제를 따로 안 만든다

셋 다 그럴듯했다. 가설 A는 한 명의 편향을 여럿이 상쇄해 줄 거라는 기대였고, 가설 B는 사람도 자기 글을 한 번 더 읽으면 오탈자를 잡아내듯 AI도 스스로 다시 보면 실수를 잡을 거라는 기대였다. 가설 C는 이미 많은 곳이 검증한 기준을 새로 만들 필요가 없다는 기대였다. 셋 다 실제로 적용하기 전에, 이미 나와 있는 실험 결과부터 찾아봤다.

세 가설 모두 매력적이었던 진짜 이유는 하나다 — 도메인을 아는 사람 한 명이 직접 매번 확인하는 방식보다 훨씬 적은 시간으로 같은 수준의 확신을 얻을 수 있어 보였기 때문이다. 사람 손을 덜 들이면서도 정확도는 그대로거나 더 나아진다면, 그보다 좋은 조합은 없어 보였다.

다수결도, 자기 재확인도 왜 정확도를 더 떨어뜨렸나

가설 A부터 무너졌다. 2026년 8월 13일 발표된 멀티에이전트 연구가 AI 4개를 한 그룹으로 묶어 토론시킨 실험을 다뤘는데, 결과는 기대와 반대였다. 4인 투표 그룹은 토론 끝에 의견을 일찍 좁혀 버렸고, 그 과정에서 새로 나온 증거가 다른 구성원에게 제대로 전달되지 않았다. 그 결과 그룹 판단의 정확도가 한 명이 판단할 때보다 오히려 낮아졌다.

가설 B도 무너졌다. '다시 확인해 봐'라는 지시를 강한 모델에게 준 실험(Self-refine)에서, 자기 재확인을 거친 뒤 정확도는 16.7%였다. 같은 방식을 약한 모델에게 줬을 때는 26.8%였다. 강한 모델이 스스로 다시 확인했는데도, 약한 모델보다 오히려 더 낮은 정확도를 기록했다.

가설 C도 무너졌다. 공개 벤치마크로 널리 쓰이던 SWE-bench Verified가 2026년에 폐기됐는데, 이유는 어려운 문제로 분류된 항목 중 59.4%가 실제로는 결함이 있는 문제였고 이미 나와 있는 최상위 모델들이 그 문제들에 노출(오염)돼 있었기 때문이었다. 공개 점수는 마케팅 자료로만 참고할 수 있을 뿐, 우리 결과물이 실제로 맞는지 판단하는 근거로는 쓸 수 없었다. 밖에서 빌려 온 잣대 세 개(AI 심사자·다수결·공개 벤치마크)가 전부 같은 방향을 가리키고 있었다.

진짜 원인 — 판단을 쪼갤수록 정보가 사라진다

세 가지 실패를 나란히 놓고 보니 원인이 하나로 모였다. 판단하는 목소리를 늘릴수록 정확도가 올라갈 거라 가정했는데, 실제로는 목소리를 늘릴수록 근거가 흩어지고 있었다.

4인 투표 그룹에서는 누군가 뒤늦게 발견한 증거가 이미 조기 수렴된 다수 의견에 밀려 반영되지 못했다. 자기 재확인에서는 모델이 참고할 새로운 근거 없이 같은 생각을 다시 되뇌기만 했다 — 원래 답이 맞았어도 틀렸어도, 다시 확인하는 과정 자체에 외부 신호가 없으니 결과가 개선될 이유가 없었다. 공개 벤치마크에서는 문제 자체가 오염돼 있어 애초에 비교 기준으로 쓸 수 없는 상태였다.

셋의 공통점은 '검증하는 쪽'이 새로운 근거 없이 같은 판단을 여러 번 반복하거나, 여러 판단을 그대로 평균 낸다는 점이었다. 근거가 새로 들어오지 않으면 몇 번을 반복해도, 몇 명이 모여도 정확도는 올라가지 않았다.

공개 벤치마크가 무너진 이유도 결국 같은 줄기다. 벤치마크 문제는 우리 업무와 상관없이 밖에서 만들어진 문제라, 우리 결과물이 맞는지와는 애초에 관계가 약했다. 오히려 가장 자연스러운 시험 문제는 실제로 우리 제품을 쓰는 사람이 요청한 일 그 자체였다. 남이 만든 잣대를 빌리는 대신, 우리 업무에서 실제로 나온 요청과 실패를 그대로 시험 문제로 쓰는 편이 훨씬 정직했다.

비유하면 이렇다. 사람 셋이 같은 서류를 검토하고 각자 서로 다른 부분에서 의심스러운 대목을 찾았다고 하자. 셋이 곧바로 모여 토론하고 다수결로 결론을 내면, 먼저 목소리를 낸 한두 명의 의견 쪽으로 쏠리기 쉽고 나머지가 각자 찾아낸 의심스러운 대목은 최종 결론에 반영되지 못한 채 묻힌다. 반대로 한 사람이 셋의 발견을 전부 전달받아 하나씩 짚어 가며 판단하면, 적어도 발견된 것 중 무엇을 채택하고 무엇을 기각했는지는 근거와 함께 남는다. 여러 목소리를 합의로 뭉치는 절차 자체가 근거를 지우는 방향으로 작동한다는 뜻이다.

조치 — 한 사람이 최종 판단하고, 실패부터 직접 본다

그래서 방향을 반대로 잡았다. 목소리를 늘리는 대신 하나로 모았다. 최종 판단은 도메인을 아는 사람 한 명이 내린다 — 팀이 없는 지금은 그 한 명이 곧 본인이다. AI 심사자는 그 판단을 돕는 보조 신호로만 쓰고, 자동으로 도는 시험과 사람이 직접 표본을 확인하는 절차를 함께 병행한다.

판단 기준을 세우는 순서도 바꿨다. 판정 도구부터 만드는 대신, 실패한 사례부터 직접 들여다봤다. 에이전트가 실제로 처리한 기록 20~50개를 사람이 하나씩 검토하고, 그중에서 반복되는 실패 유형 3~5개를 뽑아냈다.

이 단계를 완벽하게 끝내려고 욕심내지도 않았다. 처음부터 30~50개를 다 채우려 들면 시작조차 늦어진다. 그래서 유형별로 2~5개씩만 모아 시드 10~15개로 먼저 굴리고, 실제로 굴려 보면서 부족한 부분을 확인한 뒤 규모를 늘려 나가는 방식을 택했다.

실제로 뽑히는 실패 유형은 이런 식이다 — 있지도 않은 기능을 있는 것처럼 불러오려는 경우, 로그인·권한 확인 절차를 빠뜨린 채 넘어가는 경우, 흔치 않은 경계 상황을 아예 놓치는 경우. 이런 유형은 한 번 겪고 나서야 눈에 들어온다. 판정 도구부터 만들었다면 이런 구체적인 유형을 미리 떠올리지 못했을 가능성이 크다.

그 실패 유형을 바탕으로 우리 업무에 맞춘 시험 문제 모음(골든 데이터셋)을 만들었다. 처음에는 유형별로 2~5개씩, 총 10~15개로 시작했다 — 정상적으로 처리되는 사례 70%, 경계에 걸친 사례 25%, 일부러 어렵게 만든 사례 5%의 비율이다. 이후 시간이 지나며 30~50개로 늘리는 계획을 세웠는데, 이때는 정상 사례 60%·경계 사례 25%·일부러 어렵게 만든 사례 10%·과거에 실제로 틀렸던 사례를 다시 넣는 몫 5%로 비율을 다시 짰다.

판정하는 도구 자체는 크게 늘리지 않았다. 여러 명이 나눠 평가하는 별도 플랫폼을 새로 들이지 않고, 사례별 입력·기대 결과·판단 과정에 대한 힌트·제약 조건을 파일 하나에 정리하고 간단한 스크립트로 관리한다. 도구를 키우기보다 실패 사례를 계속 채워 넣는 쪽을 우선했다.

이 순서를 지키는 이유는 분명하다. ROUGE·BERTScore 같은 이미 만들어진 지표만 계속 추적하는 방식(eval theater)은 측정하기 쉬운 지표만 재고 정작 중요한 실패는 못 본 채 넘어가게 만든다. 반대로 실패 사례를 먼저 사람이 직접 읽고 유형을 나눈 뒤에 그 유형에 맞춘 채점 기준을 세우면, 적어도 우리가 이미 겪은 실패는 다시 놓치지 않는다.

재측정 결과 — 바뀐 기준과 배포를 막는 선

판단 기준을 바꾼 뒤에는, 정확도를 재는 잣대 자체도 다시 정했다. 다수결이나 자기 재확인 대신 아래 두 가지를 핵심 지표로 삼는다.

• 1회 시도 정답률(pass@1) — 사례 하나당 목표 70% 이상
• 5회 시도 중 1회 이상 성공(pass@5) — 목표 90% 이상
• 사람이 직접 개입해야 하는 비율(Escalation Rate) — 상한 10%
• 성공 1회당 들어간 비용(Cost-per-success) — 계속 추적

성공 1회당 비용을 따로 추적하는 이유는 단순하다. 정답률만 보면 시간과 비용을 얼마든지 더 들여서 억지로 끌어올릴 수 있다. 그렇게 끌어올린 정답률은 실제로 쓸 수 있는 방식인지와는 별개 문제다. 그래서 정답률과 비용을 항상 같이 놓고 본다. 비용을 무시하고 정답률만 좇으면, 결국 사람이 매번 붙어 확인하던 예전 방식보다 오히려 더 느리고 비싼 절차를 만들게 된다.

여기에 배포를 막는 선도 하나 넣었다. 이 시험 문제 모음에서 잰 1회 시도 정답률이 이전보다 5% 이상 떨어지면, 그 상태로는 새 버전을 내보내지 않는다. 모델 버전이 바뀔 때는 전체를 다시 처음부터 잰다.

일을 진행하는 순서도 정해 뒀다. 첫 1주차에는 실패 기록을 모아 유형을 나누고, 2주차에는 시드 10~15개로 시험 문제 모음을 만들어 1회 시도 정답률의 기준선을 잰다. 3~4주차에는 사례를 30~50개로 늘리고 매주 자동으로 도는 재시험 결과를 확인한다. 새로운 실패가 나오면 그 자리에서 바로 시험 문제 모음에 추가한다 — 나중으로 미루지 않는다.

재시험은 사람이 매번 손으로 돌리지 않고 자동으로 돈다. 사람 손이 필요한 자리는 결과를 읽고 판단하는 마지막 단계뿐이다. 이 재시험을 한 번 돌리고 끝내는 일회성 점검으로 두지 않은 이유가 있다. 시험 문제 모음이 한 번 만들어지고 그대로 멈추면, 그 뒤로 새로 생기는 실패는 계속 눈에 안 보이는 채로 쌓인다. 그래서 매주 정기적으로 재시험 결과를 보고받는 자리를 따로 만들고, 새 실패가 확인되면 그 주 안에 시험 문제로 되돌려 넣는 방식을 규칙으로 정했다.

모델 버전이 바뀔 때마다 처음부터 다시 재는 규칙도 같은 이유에서 나왔다. 판정 기준이 특정 모델의 습관에 맞춰 슬며시 굳어지면, 모델이 바뀌는 순간 그 기준 자체가 낡은 잣대가 돼 버린다. 그래서 새 버전이 들어올 때마다 시드 단계부터 다시 정답률을 재고, 이전 기준선과 나란히 놓고 비교한다.

결과물의 전체적인 품질을 볼 때는 4~5점짜리 채점표(Trace Grading)로 사람이 직접 점수를 매기는 방식도 함께 쓴다. 여러 명이 나눠 매기는 게 아니라, 이 채점표 역시 도메인을 아는 한 사람이 매긴다 — 목소리를 늘리지 않는다는 원칙을 처음부터 끝까지 여기서도 그대로 지킨다.

지표를 한꺼번에 다 갖추려 하지도 않았다. 순서를 정해 위에서부터 하나씩 쌓는다 — 1회 시도 정답률을 먼저 보고, 그다음 성공 1회당 들어간 비용, 그다음 사람 개입 비율, 그다음 채점표 점수, 그다음 5회 시도 성공률, 마지막으로 사람이 몇 분 걸리는 일을 AI가 대신 해내는지(Time Horizon)까지 순서대로 넓혀 간다. 처음부터 여섯 개를 동시에 재려고 하면 어느 지표도 제대로 못 재게 된다.

아직 못 채운 부분은 무엇인가

이 방식에도 남는 문제가 있다. 공개 벤치마크에 기대지 않기로 한 대신, 시험 문제 모음을 손으로 채워야 한다는 부담을 고스란히 떠안았다. 지금은 아직 시드 단계(10~15개)에 머물러 있고, 30~50개로 늘리는 확장 단계까지는 가지 못했다.

한 사람이 최종 판단하는 방식도 지금 규모에서만 성립하는 전제다. 팀이 없는 지금은 병목이 아니지만, 사람이 늘어나면 이 한 명이 오히려 병목이 될 수 있다. 그때는 도메인을 아는 전문가를 한 명 지정해 역할을 넘기는 방식으로 바꿔야 하는데, 그 전환 지점은 아직 정하지 않았다.

실제 사용자 요청을 가장 자연스러운 시험 문제로 삼기로 한 결정도 전제를 하나 깔고 있다. 실제로 들어오는 요청 자체가 충분히 쌓여야 그 안에서 경계 사례와 일부러 어렵게 만든 사례까지 골고루 뽑을 수 있다는 전제다. 지금처럼 요청량이 많지 않은 단계에서는 유형별로 2~5개씩 채우는 일도 예상보다 시간이 걸렸고, 이 부분은 사용량이 늘어야 자연스럽게 풀릴 문제로 남겨 뒀다.

정답률 목표를 처음부터 100%로 잡지 않은 데도 이유가 있다. 모든 사례를 다 통과시키려 하면, 그건 시험 문제 자체가 너무 쉬워졌다는 신호에 가깝다. 그래서 지금은 사례당 1회 시도 정답률 70% 선을 유지하는 쪽을 목표로 두고, 통과율이 그보다 훨씬 높아지면 오히려 시험 문제를 더 까다롭게 다시 짜야 한다고 본다. 70% 선은 목표이지 최종 성적표가 아니다 — 시드 10~15개를 넘어 30~50개로 늘려 가는 동안 이 숫자도 같이 다시 검토할 대상이다.

AI 심사자를 보조로만 쓰기로 정한 결정도 완전한 해법은 아니다. 여러 심사자를 묶어도 편향이 사라지지 않고 오히려 쌓일 수 있다는 점은 이미 확인했고, 그래서 자동 시험과 사람의 표본 확인을 병행하는 지금 방식이 최선이지, 완결된 해법은 아니라고 본다. AI 심사자를 더 적극적으로 쓰는 시도는 지금 순위에서 뒤로 미뤄 뒀다 — 도메인을 아는 사람이 최종 판단을 내리는 원칙을 먼저 지키고, 그다음에 시도할 항목이다.

같은 질문에 답이 계속 달라졌던 에이전트 사례에서도 확인했듯, 근거를 붙이는 절차만으로 정확도가 저절로 올라가지는 않는다. 비슷한 방식으로 결과물 검증 기준을 다시 짜고 싶다면 상담에서 구체적으로 짚어 볼 수 있다.