AI 에이전트가 데모 단계를 넘어 프로덕션 환경에 도입되면서 팀들은 벤치마크 점수만으로 비즈니스 가치를 가늠하기는 어렵다는 사실을 깨닫고 있습니다. 새로운 프론티어 모델이 출시되어 벤치마크 순위 상위권에 오르고 프로덕션에 도입되더라도, 정작 비즈니스 메트릭과 코드 개발 속도는 제자리인 경우가 흔합니다. 이 글에서는 표준 모델 벤치마크를 넘어 에이전트를 평가하기 위한 5가지 원칙을 소개합니다.

새로운 소프트웨어 시대에 필요한 새로운 정확성의 개념

소프트웨어 3.0 시대로 접어들면서 무엇이 소프트웨어를 '정확하게' 만드는지에 대한 정의도 달라져야 합니다.

소프트웨어 1.0(코드가 곧 소프트웨어): 디지털 시대를 열었습니다. 코드가 모든 세부 사항을 명시적으로 정의했으므로 정확성의 기준이 명확했습니다.

소프트웨어 2.0(모델이 곧 소프트웨어): 고도화된 컴퓨터 비전과 챗봇 시대를 이끌었습니다. 정확성의 기준이 데이터와 모델 설계를 통해 결정되는 통계적 메트릭으로 이동했습니다.

소프트웨어 3.0(프롬프트가 곧 소프트웨어): 인간과 머신의 상호작용 방식을 바꾸었습니다. 하지만 아직 정확성을 명확하게 정의하지 못하고 있습니다. 정확성을 정의하는 것이 진정한 가치를 실현하는 핵심입니다.

소프트웨어 3.0의 두 가지 주요 과제:

검증 장애물: 우리는 스스로 평가하는 속도보다 더 빠르게 해결책을 생성할 수 있는 머신을 만들었습니다.⁷이제 이 분야의 발전 속도는 검증기를 얼마나 잘 구축할 수 있는지에 달려 있습니다. 

재귀적 신뢰 문제: 대규모 언어 모델(LLM)을 사용해 LLM을 평가하면 재귀적 신뢰 문제가 발생합니다.⁶LLM으로 생성한 평가기는 평가 대상인 LLM이 가진 모든 문제를 상속합니다.

AI의 첫 번째 단계가 연구자들의 승리였다면, 이러한 고충은 다음 단계가 실제 태스크에서 무엇이 '좋은 것'인지 정의할 수 있는 사람들에게 달려 있음을 보여줍니다.⁹

AI 평가 시스템을 지지하는 5가지 요소

에이전트 평가 시스템은 5가지 영역으로 나눌 수 있습니다.

1.  실제로 무엇을 측정하고 있는가?

모델을 측정하고 있다고 생각하기 쉽지만, 실제로는 서로 다른 3개 계층에서 변동성이 발생하는 전체 스택을 측정하고 있습니다.⁵

데이터와 하네스 구성의 차이가 모델 간 차이보다 더 큰 영향을 미칠 수 있습니다.

하네스의 지배적 영향: 수많은 현대적인 벤치마크에서는 기본 모델을 바꾸는 것보다 평가 하네스를 바꾸는 것이 순위 변동에 더 큰 영향을 미치기도 합니다.² Brand의 분석에 따르면 커맨드라인 인터페이스(CLI) 하네스는 표준화된 최첨단(SOTA) 성능 기록을 무의미하게 만듭니다. 같은 모델이라도 하네스가 달라지면 점수가 완전히 달라지기 때문입니다.²

하네스를 동일하게 유지하더라도 데이터 자체가 결과의 신뢰성을 떨어뜨릴 수 있습니다. 정답 데이터는 사실 그 자체가 아니라 하나의 주장에 불과합니다. 잘못되었거나, 오염되었거나, 오래된 정보일 수 있습니다. 잘못된 정답 데이터를 기반으로 하면 정밀하게 보정된 잘못된 결론에 도달하게 됩니다. 하네스와 데이터의 영향이 함께 누적되면 세 번째 문제인 응답 유도로 이어집니다. 모델의 점수는 역량의 하한선일 뿐 상한선은 될 수 없습니다.

2.  출력 외에 무엇을 평가해야 하는가?

평가에서 무엇을 살펴봐야 하는지에 관한 문제입니다. Lee는 평가 대상을 5가지로 구분하지만, 대부분의 팀은 첫 번째 항목만 다룹니다.⁴

올바른 출력이 잘못된 추론 과정을 가릴 수 있습니다. 실패한 테스트를 수정하는 코딩 에이전트를 예로 들어보겠습니다. 이 에이전트가 도큐멘테이션 API를 쿼리했지만 404 오류를 받고, 재시도하거나 오류를 보고하는 대신 학습 데이터에 기반해 그럴듯한 패치를 생성한다고 가정해 보겠습니다. 테스트는 통과하지만, 이는 근본 원인을 해결한 것이 아니라 증상만 덮어버린 결과입니다. 출력 평가에서는 '통과'로 판정됩니다. 트레이스 평가는 에이전트가 관련 도큐멘테이션을 전혀 읽지 않은 채 할루시네이션에 기반해 수정 사항을 만들어냈다는 사실을 보여줍니다. 여러 평가 영역을 함께 다루지 않으면 큰 사각지대가 생길 수 있습니다.⁴

이 문제는 에이전트의 출력을 넘어 에이전트가 영향을 미치는 시스템까지 이어집니다. 에이전트는 자신이 작동하는 환경을 변화시킵니다. 최종 상태만 기록하고 각 단계별 변화량을 포착하지 않는 평가는 실패를 특정 작업에 귀속시킬 수 없습니다. 변경 사항은 근거이고, 최종 상태는 판정입니다.⁴

3.  재현 가능한 평가에는 어떤 인프라가 필요한가?

평가 인프라 아키텍처 중 직접 제어할 수 있는 영역입니다.⁴

에이전트에게 필요한 것은 데이터세트가 아니라 실행 환경입니다.⁴ 에이전트에는 격리된 파일 시스템과 데이터베이스 스냅샷이 필요합니다. 실험 간에는 변경 가능한 상태를 절대 공유해서는 안 됩니다. 데이터 플레인은 재현 가능하고 격리되어 있으며 계측 가능한 환경을 제공해야 하므로 엔지니어링 측면에서 더 어려운 과제입니다.

이러한 실행 환경도 각 시험 실행이 완전히 초기화된 상태에서 시작할 때만 의미가 있습니다. 실행 간 격리가 없으면 에이전트 기능이 아닌 인프라 아티팩트를 측정하게 됩니다.¹ Anthropic은 Claude가 이전 시험 실행의 Git 기록을 악용하는 사례를 발견했습니다.¹ 실행 간에 상태를 공유하면 서로 연관된 실패가 발생해 결과가 왜곡됩니다. 모든 테스트 실행에는 완전히 깨끗한 환경이 필요합니다.

4.  어떤 메트릭을 최적화해야 하는가?

목표에 따라 성공 여부는 서로 다른 4가지 메트릭으로 정의할 수 있습니다. ^{1, 3, 7}

검증기의 법칙: AI가 특정 태스크를 해결하도록 학습시키는 난이도는 해당 태스크의 검증 가능성에 비례합니다. 현실 세계의 태스크는 '유용함'을 판단할 명확한 검증기가 없기 때문에 발전이 더딥니다. 이 분야의 발전을 가로막는 것은 모델의 역량이 아니라 검증기를 구축하는 우리의 능력입니다.⁷ 

이러한 패턴은 소프트웨어에서도 나타납니다. 단위 테스트로 쉽게 검증할 수 있는 새로운 개별 기능은 빠르게 생성되는 반면, 근본적인 아키텍처 변경이 필요한 상위 수준의 목표는 해결되지 않은 채 남습니다. 그 결과 PR이 계속 늘어나면서 유지 관리자의 검토 부담이 커지고, 정작 핵심 목표는 달성하지 못하는 상황이 발생합니다. 반대로 잘 설계된 소프트웨어는 플라이 휠 효과를 만들어냅니다. 일관되고 원칙적인 설계를 갖춘 코드 베이스는 아키텍처적으로 건전한 개별 기능을 최대한 많이 만들어낼 수 있으므로, 임시방편과 땜질식 해결책이 난무하는 코드 베이스보다 에이전트로부터 훨씬 더 큰 효용을 얻을 수 있습니다.

검증 가능성은 개선이 가능한지를 보여주고, 비용은 그 개선이 실용적인지를 보여줍니다. 비용을 고려하지 않은 정확도는 큰 의미가 없습니다.³ 많은 'SOTA' 결과는 비용보다 역량에 지나치게 유리하게 평가됩니다. 비용과 정확도를 함께 최적화하면 정확도에는 거의 영향을 주지 않으면서 비용을 크게 줄일 수 있습니다.3

5.  시간이 지나면서 어떻게 개선할 수 있는가? 

개선은 일반적으로 평가 주도 개발(EDD) 사이클이라고 하는 반복적인 피드백 루프를 통해 이루어집니다.⁸

1. 오류 분석(관찰): 트레이스 로그를 검토하여 단순한 통과 또는 실패 결과를 확인합니다.

2. 가설 수립(진단): 실패 패턴의 명확하고 테스트 가능한 원인을 파악합니다.

3. 실험(테스트): 한 번에 하나의 변수만 변경합니다.

4. 측정(검증): 결과를 측정합니다.

5. 기준 개선(적응): 새로운 문제를 발견할 때마다 평가 룰을 업데이트한 후 1단계로 돌아갑니다.⁶

기준의 변화: 평가를 하기 전에 평가 기준을 미리 정할 수는 없습니다.⁶ 평가 기준은 실제로 관찰된 출력에 따라 달라집니다. 즉, 평가하려면 기준이 필요하지만 실제 평가 과정이 다시 그 기준을 정의하는 데 도움이 됩니다. 이는 결함이 아니라 개방형 시스템을 평가할 때 나타나는 특성입니다. 평가 시스템은 고정된 기준을 전제로 하기보다 평가 기준이 반복적으로 발전할 수 있도록 설계해야 합니다.

이 루프가 제대로 작동하려면 팀이 이를 일관되게 반복해서 실행해야 합니다. AI 제품에 과학적 방법론을 적용하는 것이 차이를 만듭니다. 특정 평가 툴보다 중요한 것은 샘플링, 주석 작성, 실험, 모니터링을 꾸준히 수행하는 것입니다. 실제로 이러한 체계는 단계적으로 성숙합니다. 처음에는 발견된 오류를 대상으로 평가기를 작성하고, 실패 유형이 안정화되면 평가 주도 개발로 발전해 나갑니다.

벤치마크와 프로덕션 간 격차 해소

이제 5가지 요소의 관점에서 소프트웨어 3.0의 두 가지 주요 고충을 살펴볼 수 있습니다. 제2요소와 제3요소는 단일 평가기나 공유 상태에만 의존하지 않도록 함으로써 재귀적 신뢰 문제를 완화합니다. 제4요소와 제5요소는 검증기 구축을 부차적인 작업이 아닌 핵심 엔지니어링 과제로 다룸으로써 검증 장애물에 대응합니다. 벤치마크 성능과 실제 가치 사이의 격차는 모델의 문제가 아니라 평가의 문제입니다. 이 격차를 해소하려면 평가를 핵심 엔지니어링 분야로 다뤄야 합니다. 이를 체화한 기업은 더 안정적이고 비용 효율적인 에이전틱 시스템을 출시할 수 있지만, 그렇지 못한 기업은 프로덕션에서 실패하는 인상적인 데모를 만드는 데 그칠 가능성이 큽니다.

프로덕션 지원 에이전트 시스템의 대규모 구축

AI 에이전트를 프로토타입에서 프로덕션으로 전환하려면 강력한 데이터 플레인 격리, 다중 영역 평가, 안정적인 클러스터 수준 거버넌스가 필요합니다. Red Hat OpenShift AI가 하이브리드 클라우드 전반에서 신뢰할 수 있는 LLM 애플리케이션을 테스트, 평가, 확장하는 데 필요한 엔터프라이즈 인프라를 어떻게 제공하는지 알아보세요. 파이프라인에서 EDD를 네이티브 방식으로 구현하려면 EvalHub가 Red Hat OpenShift 클러스터 전반에서 여러 프레임워크의 LLM 평가 작업을 어떻게 오케스트레이션하는지 살펴보세요.

참고 자료

^1.  Anthropic, 'AI 에이전트 평가 이해하기,' https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

^2.   Brand, 'Benches 2026,' https://florianbrand.com/posts/benches-2026

^3.  Kapoor 외, '중요한 AI 에이전트,' https://arxiv.org/abs/2407.01502

^4.  Lee, '숨겨진 기술 부채: 에이전트 평가 인프라,' https://leehanchung.github.io/blogs/2026/06/13/hidden-technical-debt-agent-evaluation-infra/

^5.  OpenAI, '신뢰할 수 있는 타사 평가,' https://openai.com/index/trustworthy-third-party-evaluations-foundations/

^6.  Shankar 외, '검증기를 검증하는 것은 누구인가?,' https://arxiv.org/abs/2404.12272

^7.  Wei, '검증의 비대칭성과 검증기의 법칙,' https://www.jasonwei.net/blog/asymmetry-of-verification-and-verifiers-law

^8.  Yan, 'LLM-as-Judge만으로는 제품을 구할 수 없다,' https://eugeneyan.com/writing/eval-process/

^9.  Yao, '후반전,' https://ysymyth.github.io/The-Second-Half/