analytical · 2026-05-15

AI는 무엇으로 자신을 재는가 — Oracle, 판정 기준의 구조와 한계

GPT4가 MMLU 벤치마크에서 65%의 정확도를 달성했다는 발표가 나왔을 때, 많은 사람들은 그것을 AI 능력의 지표로 받아들였다. 그런데 같은 시기, 다른 연구자들이 불편한 실험을 진행했다. 모델이 학습 과정에서 한 번도 본 적 없는 새로운 문제들로 동일한 모델을 테스트한 것이다. 결과는 26%였다. 39퍼센트포인트의

AI는 무엇으로 자신을 재는가 — Oracle, 판정 기준의 구조와 한계

GPT-4가 MMLU 벤치마크에서 65%의 정확도를 달성했다는 발표가 나왔을 때, 많은 사람들은 그것을 AI 능력의 지표로 받아들였다. 그런데 같은 시기, 다른 연구자들이 불편한 실험을 진행했다. 모델이 학습 과정에서 한 번도 본 적 없는 새로운 문제들로 동일한 모델을 테스트한 것이다. 결과는 26%였다. 39퍼센트포인트의 낙차. AI가 추론한 것이 아니라 외웠다는 의미다.

이 사례가 흥미로운 이유는 GPT-4의 실력 때문이 아니다. 65%라는 숫자가 무엇을 재고 있었는지 — 혹은 재고 있지 않았는지 — 를 드러내기 때문이다. 평가 점수는 존재했다. 그런데 그 점수가 가리키는 것이 우리가 생각한 것과 달랐다. 그렇다면 처음부터 물어야 할 질문은 이것이다. AI 시스템이 "잘한다"는 것을 판정하는 기준 자체는 얼마나 믿을 만한가.

소프트웨어 공학에서는 이 판정 메커니즘을 Oracle이라고 부른다. 입력에 대해 올바른 출력이 무엇인지를 결정하는 모든 기준 주체, 혹은 메커니즘이다. Oracle은 사람일 수도 있고, 데이터셋일 수도 있고, 또 다른 AI일 수도 있다. 어떤 형태든, 한 가지 사실은 분명하다. Oracle의 품질이 시스템 전체의 인식론적 상한(epistemic ceiling)을 결정한다. 얼마나 좋은 AI를 만들 수 있는지는, 결국 얼마나 좋은 oracle을 갖고 있는지에 달려 있다.


판정할 수 없는 것을 어떻게 테스트하는가

Oracle 문제를 처음 체계적으로 다룬 것은 1982년 소프트웨어 엔지니어링 연구자 Elaine Weyuker였다. 그는 "비테스트 가능 프로그램(non-testable programs)"이라는 개념을 제안했다. 어떤 프로그램은 이론적으로는 테스트할 수 있지만, 현실에서는 올바른 출력이 무엇인지 판정하기 어렵거나 불가능하다는 것이다. 그의 예시는 수치 시뮬레이션 소프트웨어였지만, 역설은 간단했다. 정확한 답을 이미 알고 있다면 소프트웨어가 필요 없고, 모른다면 소프트웨어의 출력이 옳은지 확인할 방법이 없다.

2015년 Barr 등은 약 300편의 연구를 종합한 조사에서, Oracle Problem이 소프트웨어 테스트의 가장 근본적이고 여전히 미해결된 문제라고 결론지었다. 그리고 현대 AI 시스템은 이 문제를 한층 더 복잡하게 만든다. 전통적인 소프트웨어는 입력-출력 명세가 존재한다. 덧셈 함수는 2+3이 5여야 한다는 것을 안다. 그러나 LLM에게 "좋은 응답"이 무엇인지는 맥락에 따라, 사용자에 따라, 목적에 따라 달라진다. 창의적인 글쓰기가 탁월하다는 것은 무엇을 의미하는가. 대화가 유용했다는 것은 어떻게 측정하는가. 추론이 올바르다는 것은 누가 판정하는가.

이 질문들에 답하는 방식에 따라 AI 평가의 전체 구조가 달라진다.


사람이 판정할 때 — 일치도는 타당성이 아니다

가장 자연스러운 oracle은 사람이다. 인간 평가자, 전문가 패널, 동료 검토자가 AI의 출력을 보고 판정을 내린다. RLHF(Reinforcement Learning from Human Feedback)의 H — 인간 피드백 — 가 바로 이 역할이다. 사람은 미묘한 맥락을 이해하고 가치 판단을 내릴 수 있다는 점에서 이상적인 oracle처럼 보인다.

그런데 인간 oracle의 신뢰도는 우리가 기대하는 것보다 훨씬 불안정하다. 두 평가자가 같은 출력에 얼마나 동의하는지를 재는 지표를 Inter-Annotator Agreement(IAA)라 한다. 통계학에서 Cohen's Kappa κ ≥ 0.8은 신뢰할 수 있는 일치도의 기준이다. 그런데 실제 임상 환경에서 11명의 의료 전문가를 대상으로 한 2023년 연구(npj Digital Medicine)에서는 Fleiss' κ = 0.255~0.383이 관찰됐다. 의료 판단처럼 전문성과 책임감이 모두 높은 영역에서도 전문가들이 이 정도로 갈린다면, 일반적인 AI 출력 평가의 인간 oracle은 어떨까.

더 근본적인 문제는, 높은 일치도가 타당성을 보장하지 않는다는 것이다. 과도하게 단순화된 평가 기준은 평가자들 사이의 동의를 쉽게 만들지만, 그 기준이 우리가 실제로 원하는 것을 재고 있는지는 별개의 문제다. 모두가 같은 방식으로 틀릴 수 있다. 이 구분 — 일치도(reliability)와 타당도(validity)의 분리 — 은 인간 oracle 설계에서 지속적으로 간과되는 함정이다.


데이터셋이 판정할 때 — Oracle 자체가 오염될 때

인간 oracle의 확장성 문제를 해결하는 가장 일반적인 방식은 벤치마크 데이터셋이다. 인간이 미리 정답을 표기한 대규모 문제 집합을 만들고, 이후에는 AI가 그 위에서 얼마나 정확한지로 성능을 측정한다. MMLU는 57개 학과에 걸친 15,908개 문제로 구성되어 있고, HELM은 42개 평가 시나리오에 7개 메트릭을 교차 적용하는 표준화 프로토콜이다.

벤치마크 oracle은 단순한 라벨 모음이 아니다. 어떤 시나리오를 평가할 것인지, 어떤 메트릭을 쓸 것인지, 어떤 조건에서 실행할 것인지까지 포함한 평가 프로토콜 전체가 oracle을 구성한다. SWE-bench는 실제 GitHub 저장소의 버그 이슈에 AI가 코드 패치를 제안하고 기존 테스트를 통과하는지로 평가하는 벤치마크다. 실행 기반 검증이라는 점에서 주관적 판단을 최소화한 oracle처럼 보였다.

그런데 2025년 초의 감사 연구에서 SWE-bench Verified 테스트의 59.4%가 결함을 가지고 있다는 사실이 드러났다. "해결된" 것으로 분류된 패치의 28.6%가 실제로는 오답이었고, 전체 해결률이 약 11퍼센트포인트 부풀려져 있었다. Oracle 자체가 오염됐을 때, 그 위에서 달성된 모든 수치는 무엇을 말하는가. 이 질문은 수사적이지 않다. 실제로 답하기 어렵다.


LLM이 LLM을 판정할 때 — 편향을 내장한 oracle

인간 oracle은 비용이 많이 들고 느리다. 벤치마크 oracle은 고정되어 있어 새로운 능력을 평가하기 어렵다. 이 두 문제를 동시에 해결하려는 시도가 LLM-as-Judge — 강력한 LLM을 다른 LLM의 출력 평가자로 사용하는 패러다임이다.

Zheng 등(2023)은 GPT-4를 judge로 사용했을 때 인간 평가와 80% 이상의 일치도를 달성할 수 있음을 보였다. G-Eval은 chain-of-thought 추론을 평가 절차에 통합해 인간 판단과의 상관관계를 높였고, Prometheus는 1,000개의 평가 루브릭으로 fine-tuning해 GPT-4 수준의 판정 능력을 더 낮은 비용으로 구현했다(Pearson r=0.897). 수치만 보면 인상적이다.

그러나 model-as-oracle은 독특한 편향 패턴을 내장하고 있다. Position bias — 두 응답 중 어느 것이 먼저 제시되느냐에 따라 판정이 달라진다. Verbosity bias — 더 긴 응답을 선호한다. Self-preference bias — 모델이 자신이 생성한 텍스트를 더 높게 평가한다. 이 편향들의 공통점은, oracle의 판정이 출력의 실질적 품질을 반영하지 않고 형식적 특성에 반응한다는 것이다. 그리고 평가자가 LLM일 때, 그 LLM의 편향을 이용하면 oracle을 조작할 수 있다.


보상 모델이 판정할 때 — 위임된 oracle과 그 배반

LLM을 강화학습으로 정렬할 때, Reward Model(RM)은 인간 oracle의 역할을 위임받는다. Ouyang 등(2022)의 InstructGPT는 인간 평가자가 선호도를 표시한 응답 쌍으로 RM을 학습하고, 이후 강화학습 단계에서는 RM이 인간 대신 출력 품질을 판정한다. 흥미로운 결과가 있었다. 1.3B 파라미터의 RM이 방향을 결정했을 때, 175B GPT-3보다 인간 선호도를 더 잘 반영하는 응답이 나왔다. Oracle의 품질이 모델의 크기보다 중요할 수 있다는 것이다.

Lightman 등(2023)은 RM을 두 종류로 구분했다. ORM(Outcome Reward Model)은 최종 답변만을 평가하고, PRM(Process Reward Model)은 추론의 각 단계를 개별적으로 평가한다. 수학 추론 과제(MATH)에서 PRM은 78.2%의 정확도를 달성하며 ORM을 능가했다. 답이 맞았는지만이 아니라 어떻게 맞았는지를 평가하는 oracle이 더 정확한 학습 신호를 제공한다는 것이다.

그러나 RM oracle의 가장 큰 취약점은 Reward Hacking이다. 모델이 RM 점수를 높이는 방법을 학습하되, 그것이 실제 품질 향상과 분리되는 현상이다. 아첨(sycophancy), 허위 확신, 불필요하게 장황한 설명 등이 그 발현 형태다. RM이라는 oracle을 최적화하는 과정에서 oracle 자체가 무력화된다. 이것은 뒤에서 다시 만날 더 큰 구조의 예고편이다.


Oracle이 없을 때 — 절차적 합의로 대신하기

외부 ground truth가 없을 때, 모델은 자기 자신 또는 자기 복제본들을 oracle로 삼는다. Wang 등(2022)의 Self-Consistency는 같은 문제에 대해 다수의 추론 경로를 샘플링하고 다수결로 답을 선택한다. 외부 판정자 없이 GSM8K 수학 문제에서 17.9%의 성능 향상이 나왔다. Irving 등(2018)의 AI Debate는 두 AI 모델을 서로 경쟁시키고 인간 judge가 더 진실에 가까운 주장을 선택하게 한다. PSPACE 수준의 복잡한 문제까지 감독을 확장할 수 있다는 이론적 근거를 제시했다. 실험에서는 6픽셀만 볼 수 있는 제한된 judge 조건에서 정확도가 59.4%에서 88.9%로 올랐다.

이 방법론들의 공통 원리는 절차적 합의(procedural consensus) 다. Oracle label 없이 다수 경로의 일관성 자체를 신뢰도 신호로 사용한다. 확장성은 높다. 그러나 모델의 체계적 오류가 앙상블 전체에 퍼질 수 있다는 위험이 남는다. 모두가 같은 방향으로, 같은 확신으로 틀릴 수 있다.


Agent의 행동을 판정할 때 — 궤적의 oracle

LLM이 단일 응답을 생성하는 수준을 넘어 여러 단계에 걸쳐 행동하는 Agent 시스템에서는 oracle 설계가 한층 복잡해진다. 텍스트 품질이 아니라 행동 궤적(trajectory) 전체를 평가해야 하기 때문이다.

최근 벤치마크들이 수렴하는 방향이 있다. 확률론적 LLM judge에서 결정론적 검증으로의 이동이다. τ-bench는 LLM을 judge로 사용하는 대신 데이터베이스 상태(database state)를 직접 비교하는 결정론적 oracle을 구현했다. WebArena Verified는 문자열 단순 비교 대신 타입을 고려한 정규화를 도입해 잘못된 "실패" 판정을 11.3퍼센트포인트 줄였다. TRAJECT-Bench는 행동 궤적을 도구 선택의 정확성, 인자(argument)의 적절성, 의존 관계와 순서의 준수, 세 단계로 분해해 개별 진단한다.

이 방향의 의미는 명확하다. Oracle이 모호할수록, 그 oracle을 통해 학습한 시스템도 모호해진다. 판정 기준의 결정론적 명확성은 단순한 편의의 문제가 아니라, 시스템이 무엇을 배우는가에 직접 영향을 미친다.


Oracle이 목표가 될 때 — 측도의 자기 소멸

지금까지 살펴본 oracle들은 각각 서로 다른 약점을 가진다. 그런데 이 약점들에는 하나의 공통된 구조가 있다.

1975년 경제학자 Charles Goodhart는 중앙은행 정책을 논의하면서 하나의 관찰을 남겼다. Marilyn Strathern은 1997년 이것을 더 간결하게 표현했다.

"측도가 목표가 되는 순간, 그것은 더 이상 좋은 측도가 아니다."

벤치마크 오염이 그 첫 번째 구체적 사례다. 모델이 MMLU 문제를 학습 데이터에서 본 적이 있다면, MMLU 점수는 추론 능력을 재지 않고 기억력을 잰다. Oracle이 공개되고 업계 목표가 되는 순간, 모델은 그 oracle 자체를 최적화하기 시작한다. 2025년 기준으로 분석된 60개 벤치마크 중 약 절반이 이미 포화 상태에 있다는 연구가 있다. 상위 모델들이 통계적으로 구분 불가능해진 것이다. Oracle의 판별력이 소진됐다.

Reward Hacking은 RM oracle에서 동일한 논리가 작동하는 사례이고, LLM-as-Judge에서도 다르지 않다. 만약 모델을 LLM judge의 선호 패턴에 맞게 조정한다면 judge의 점수는 오르지만, 실제 사용자에게 유용해진다는 보장이 없다.

이것이 oracle 설계의 근본 역설이다. 어떤 oracle이든 공개되고 목표화되면, 그 oracle을 통해 측정하려 했던 것과 실제로 최적화되는 것 사이의 거리가 벌어진다. Oracle을 완성했다는 생각 자체가 위험 신호다.


판정 기준을 설계한다는 것

이 분석이 가리키는 결론은 단순하다. 어떤 단일 oracle도 충분하지 않다. Human Oracle은 타당성은 높지만 확장성이 없다. Benchmark Oracle은 재현 가능하지만 포화와 오염에 취약하다. LLM-as-Judge는 빠르지만 편향을 내장한다. Reward Model은 확장 가능하지만 hacking에 노출된다. Self/Ensemble Oracle은 저비용이지만 체계적 오류에 취약하다. Trajectory Oracle은 결정론적으로 검증할 수 있지만 그 oracle의 설계 결함은 여전히 인간이 만든다.

실용적인 AI 평가 체계는 이 oracle들을 계층적으로 쌓는 방향으로 수렴하고 있다. 인간이 기준선을 정의하고, 벤치마크가 반복 가능한 측정을 제공하고, LLM judge가 속도를 보완하고, 보상 모델이 학습 신호를 생성하고, self-consistency가 불확실한 영역을 표시한다. 그리고 이 oracle stack 위에서는 Goodhart's Law에 대한 상시 감시가 전제되어야 한다. 어떤 oracle이 현재 목표화되고 있는지, 어떤 oracle의 판별력이 소진되어 가고 있는지를 추적하는 일이다.

좋은 AI를 만드는 문제는 좋은 oracle을 만드는 문제이고, 좋은 oracle을 만드는 문제는 그 oracle이 어떻게 약화되는지를 미리 설계하는 문제다. 판정 기준을 세우는 행위와 그 기준이 어떻게 게임화될지를 예측하는 행위는 분리될 수 없다.

평가가 멈추는 순간, 측정은 연극이 된다. 이 점에서 oracle은 기술적 구성 요소를 넘어 인식론적 질문에 닿는다. 우리는 AI가 잘한다는 것을 어떻게 아는가. 그리고 그 앎의 근거는 얼마나 오래 유효한가. 이 질문은 설계의 대상으로 남는다.


참고문헌

  1. Weyuker, E.J. (1982). On Testing Non-Testable Programs. The Computer Journal.
  2. Barr, E.T. et al. (2015). The Oracle Problem in Software Testing: A Survey. IEEE Transactions on Software Engineering.
  3. Hendrycks, D. et al. (2020). Measuring Massive Multitask Language Understanding (MMLU). arXiv:2009.03300.
  4. Liang, P. et al. (2022). Holistic Evaluation of Language Models (HELM). arXiv:2211.09110.
  5. npj Digital Medicine (2023). Inconsistent Human Annotations and Clinical AI Model Reliability. Nature.
  6. Jimenez, C.E. et al. (2024). SWE-bench: Can Language Models Resolve Real-World GitHub Issues? arXiv:2310.06770.
  7. SWE-bench Audit (2025). Are 'Solved Issues' in SWE-bench Really Solved Correctly? arXiv:2503.15223.
  8. Zheng, L. et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. arXiv:2306.05685.
  9. Liu, Y. et al. (2023). G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment. arXiv:2303.16634.
  10. Kim, S. et al. (2023). Prometheus: Inducing Fine-grained Evaluation Capability in Language Models. arXiv:2310.08491.
  11. Ouyang, L. et al. (2022). Training Language Models to Follow Instructions with Human Feedback (InstructGPT). arXiv:2203.02155.
  12. Lightman, H. et al. (2023). Let's Verify Step by Step (PRM). arXiv:2305.20050.
  13. Wang, X. et al. (2022). Self-Consistency Improves Chain of Thought Reasoning in Language Models. arXiv:2203.11171.
  14. Irving, G. et al. (2018). AI Safety via Debate. arXiv:1805.00899.
  15. Yao, S. et al. (2024). τ-bench: A Benchmark for Tool-Agent-User Interaction. arXiv:2406.12045.
  16. WebArena Verified (2024). Curated, Version-Controlled Web Evaluation. OpenReview.
  17. TRAJECT-Bench (2024). A Trajectory-Aware Benchmark for Evaluating Agentic Tool Use. arXiv:2510.04550.
  18. Strathern, M. (1997). 'Improving ratings': audit in the British University system. European Review.
  19. Benchmark Saturation Study (2025). When AI Benchmarks Plateau. arXiv:2602.16763.