2026년 LLM 평가: 프로덕션에서 에이전트가 오작동하기 전에 테스트하는 방법

당신의 에이전트는 데모를 완벽하게 수행합니다. 이해관계자들에게 깊은 인상을 남기죠. 그러다 배포하는데, 제품 ID를 환각(hallucinating)시키거나, 쓰레기 같은 인수로 도구를 호출하고, 실제로 완료하지 않은 작업에 대해서도 조용히 '성공'했다고 보고하기 시작합니다.

이것은 불운이 아닙니다. LLM 애플리케이션과 당신이 작성해 본 모든 다른 소프트웨어 간의 근본적인 차이점입니다: 출력이 비결정적(non-deterministic)이기 때문입니다. 당신의 단위 테스트로는 코드에 존재하지 않는 회귀(regression)를 잡아낼 수 없습니다. 그것은 모델의 동작, 프롬프트의 드리프트(drift), 또는 컨텍스트 윈도우(context window)의 내용물에 존재합니다.

2026년에는 신뢰할 수 있는 AI 에이전트를 배포하는 팀들이 느낌이나 수동적인 '몇 번만 시도해 보자' 같은 확인에 의존하지 않습니다. 그들은 평가(evals)를 단위 테스트 및 린팅(linting) 바로 옆의 일급 CI 게이트로 취급합니다. 이 글에서는 오늘날 여러분이 적응할 수 있는 실제 코드를 통해 그것을 정확히 어떻게 구축하는지 보여드립니다.

2026년에 평가가 필수적인 이유

지난 12개월 동안 세 가지 변화가 발생하여 평가 파이프라인(eval pipelines)이 필수적이게 되었습니다:

1. 모델 업데이트는 조용한 깨짐(silent breaking changes)입니다. 어느 날 아침, 제공업체(provider)가 모델 버전을 올렸고, 당신의 에이전트 도구 호출 형식(tool-calling format)이 미묘하게 변경되었습니다. 코드는 아무것도 바뀌지 않았습니다. 테스트 스위트에서 실패한 것도 없습니다. 하지만 프로덕션 정확도가 20% 하락했습니다.
2. 에이전트는 더 긴 궤적을 가집니다. 단일 에이전트 실행은 이제 5~20개의 도구 호출, 추론 단계(reasoning steps), 컨텍스트 재작성(context rewrites)을 포함합니다. 이 체인(chain)의 어느 곳에서든 실패가 발생하면 자신감 있게 틀린 최종 답변을 생성합니다. 이를 print statement만으로는 디버깅할 수 없습니다.
3. 조용한 실패 비용은 복리 효과를 냅니다. AI 에이전트는 더 이상 구석에 있는 챗봇이 아닙니다. 청구서를 작성하고, 이메일을 보내고, 데이터베이스를 수정합니다. 잘못되었지만 자신감 있는 행동은 실제 결과를 초래합니다.

2026년의 업계 분석은 에이전트 시스템이 실패할 때, 그 실패는 **생성(generation)이 아니라 검색 및 도구 호출(retrieval and tool-calling)**에서 발생한다는 것을 일관되게 보여줍니다. 그리고 그것들은 바로 당신의 단위 테스트가 결코 건드리지 못하는 레이어들입니다.

평가 분류 체계: 실제로 필요한 4가지 단계

"평가 스위트 (eval suite)"를 구축하지 마세요. 서로 다른 실패 클래스 (failure class)를 포착하는 4개의 레이어를 구축하세요.

대부분의 팀은 3단계부터 시작하여 1-2단계를 건너뛰는데, 이는 거꾸로 가는 방식입니다. 1단계와 2단계는 프로덕션 실패의 80%가 발생하는 지점이며, 테스트 비용도 100배 더 저렴합니다. 바닥에서부터 위로 (bottom-up) 구축하세요.

무료 콘텐츠: 작동하는 평가 하네스 (eval harness)

다음은 저희가 프로덕션에서 사용하는 정확한 패턴입니다. 이는 pytest를 기반으로 구축되어 특정 프레임워크에 종속되지 않으며, 특정 벤더에 얽매이지 않고 어떤 모델 제공자와도 함께 작동합니다.

1단계: 골든 데이터셋 (The golden dataset)

평가는 테스트 케이스의 품질만큼만 좋아집니다. 테스트 케이스를 버전 관리되는 JSONL 형식으로 저장하세요. 각 케이스는 한 줄로 구성하며, 실패를 정확한 프롬프트 (prompt), 모델, 그리고 데이터셋 버전으로 추적할 수 있도록 id를 포함해야 합니다:

{"id": "tool-001", "type": "tool_call", "input": "What's the balance for account 4472?", "expected_tool": "get_account_balance", "expected_args": {"account_id": 4472}}
{"id": "tool-002", "type": "tool_call", "input": "Delete user with email john@example.com", "expected_tool": "delete_user", "expected_args": {"email": "john@example.com"}, "forbidden": ["delete_everything"]}
{"id": "task-001", "type": "task", "input": "Summarize the Q2 revenue report and email it to the finance team", "success_condition": "email sent to finance@company.com containing a Q2 summary with total revenue"}

골든 데이터셋을 위한 규칙:

• 프로덕션 로그에서 추출한 실제 입력값 (Real inputs from production logs): 수작업으로 만든 해피 패스 (happy paths)가 아닌 실제 데이터여야 합니다. 데모 케이스는 항상 통과하는 케이스들뿐입니다.
• 어려운 케이스 (hard cases) 포함: 모호한 질의 (ambiguous queries), 누락된 컨텍스트 (missing context), 악의적인 입력 (malicious inputs), 엣지 케이스 형식 (edge formats).
• 회귀 케이스 (regression cases) 추가: 프로덕션에서 버그가 발견될 때마다 추가하세요. 당신이 수정한 버그는 당신이 놓치고 있는 평가 항목입니다.
• 핵심 플로우(critical flow)당 50~200개 케이스 목표: 시작 단계에서는 이 정도가 적당합니다. 20개 정도의 케이스는 기분은 좋게 만들겠지만, 아무것도 잡아내지 못할 것입니다.

Step 2: pytest 하네스 (harness)

# tests/evals/test_tool_calls.py
import json
import pytest
...

이것이 전부입니다. 순수 함수 (pure functions) 대신 LLM의 동작을 대상으로 지정할 뿐, 이미 사용 중인 것과 동일한 테스트 러너 (test runner)를 사용합니다. 이 스위트 (suite)가 실패(red)로 뜨면, 어떤 프롬프트 변경, 모델 업데이트 (model bump), 또는 컨텍스트 변경이 무엇을 망가뜨렸는지 정확히 알 수 있습니다.

Step 3: 주관적 출력을 위한 LLM-as-judge

요약, 톤 (tone), 완전성 (completeness)과 같은 일부 출력은 == 연산자로 단언 (assert)할 수 없습니다. **루브릭 (rubric, 평가 기준)을 갖춘 판사 LLM (judge LLM)**을 사용하세요 (자기 채점 편향 (self-grading bias)을 피하기 위해 테스트 중인 모델과는 다른 모델을 사용해야 합니다):

def llm_judge(output, rubric, model="judge-model-v2"):
    """루브릭에 따라 LLM 출력을 점수화합니다. 0.0-1.0을 반환합니다."""
    prompt = f"""
...

판사 루브릭 설계는 단순한 체크리스트가 아니라 하나의 기술입니다. 가장 좋은 루브릭은 "X를 반드시 포함해야 함", "Y라고 주장해서는 안 됨"과 같은 행동 기반 (behavioral) 방식이며, "구조가 잘 잡혀 있음"과 같은 느낌 (vibes)에 의존해서는 안 됩니다. 또한, 판사 모델이 표류 (drifting)하고 있지 않은지 확인하기 위해 매주 약 20개의 판사 출력물 세트를 사람이 직접 검토하는 과정을 유지하세요.

Step 4: CI 게이트 (CI gate)

평가 (Evals)는 CI에 포함되어야 하며, 모든 PR (pull request) 및 정기적인 일정(모델 표류를 포착하기 위함)에 따라 실행되어야 합니다. GitHub Actions:

name: agent-evals
on:
  pull_request:
...

매일 밤 실행되는 스케줄은 모두가 잊어버리는 부분입니다. 모델 제공업체는 언제든 동작을 변경할 수 있습니다. 매일 밤 실행되는 평가는 조용한 회귀 (silent regressions)를 감지하기 위한 조기 경보 시스템입니다. 제공업체의 기본값 업데이트가 프로덕션에 조용히 도달하지 않도록 모델 버전을 고정하세요 (model="claude-3-7-sonnet-20260601"와 같이 지정하고, model="claude-3-7-sonnet"처럼 사용하지 마세요).

당신의 평가 스위트를 망가뜨릴 안티 패턴 (Anti-patterns)

프로덕션에서의 프로 팁 (Pro tips from production)

1. 평가 주도 개발 (Eval-driven development): 수정하기 전에 평가(eval)를 작성하세요. 버그를 재현하고, 이를 골든 세트 (Golden set)에 추가한 뒤, 실패하는 것을 확인하고 나서 수정하세요. 평가는 당신의 '완료 정의 (Definition of done)'입니다.
2. 트레이스 캡처 (Trace capture)는 무료 평가 데이터입니다: 모든 프로덕션 실행(도구 호출, 타임스탬프, 결과)을 로그로 남기세요. 정확도가 떨어질 때, 하위 5%의 트레이스는 다음 골든 세트의 추가 항목이 됩니다.
3. 해피 패스 (Happy path)뿐만 아니라 안전 가드레일 (Safety rails)을 테스트하세요: 금지된 도구에 대한 어설션 (Forbidden-tool assertions) 및 입력 가드 체크 (Input-guard checks)는 작성할 수 있는 가장 ROI(투자 대비 효율)가 높은 평가입니다. 단 한 번의 치명적인 행동을 방지하는 것만으로도 전체 평가 스위트의 비용을 상쇄합니다.
4. 시간에 따른 평가 추이를 추적하세요: 단 한 번의 통과 실행은 의미가 없지만, 추세선 (Trend line)은 의미가 있습니다. 모델 버전 + 프롬프트 버전 + 데이터셋 버전을 함께 점수를 저장하여 회귀 (Regression) 발생 시 원인을 이분법적으로 찾아낼 수 있도록 하세요.
5. 유닛 평가 (Unit evals)를 30초 이내로 유지하세요: 빠른 레이어가 느려지면 개발자들은 로컬에서 실행하는 것을 중단할 것이고, 평가는 배포 당일의 의식(ritual)이 되어버립니다. 이는 당신이 피하려고 하는 바로 그 실패 모드입니다.

전체 컬렉션의 구성 내용

이 기사는 평가 레이어 (Eval layer)를 다루지만, 평가는 프로덕션 AI 에이전트를 출시하는 데 필요한 하나의 기둥일 뿐입니다. **AI 에이전트 및 자동화 플레이북 (AI Agents & Automation Playbook)**은 전체 라이프사이클을 안내합니다:

무료 리소스 대신 플레이북을 선택해야 하는 이유: 이는 흩어진 파편이 아닌 완전한 시스템입니다. 실제 에이전트 배포에서 검증된 100페이지 이상의 패턴, 바로 복사해서 사용할 수 있는 코드, 그리고 "에이전트에 대해 읽어봤다"를 "내 에이전트를 출시했다"로 바꿔주는 체크리스트를 제공합니다.

고장 나지 않는 에이전트를 출시할 준비가 되셨나요?

당신은 하네스 (Harness)를 확인했습니다. 질문은 당신의 에이전트가 작동하느냐가 아니라, 당신이 그것이 작동한다는 것을 알고 있느냐입니다. "수동으로" 통과한 모든 데모는 아직 발견하지 못한 버그입니다.

The AI Agents & Automation Playbook은 다음과 같은 완전한 프로덕션 툴킷(production toolkit)을 제공합니다:

• ✅ 골든 데이터셋(golden datasets)과 CI 게이트(CI gates)를 포함한 4계층 평가 시스템 (완전 작동)
• ✅ 실제 도구들을 안전하게 연결하기 위한 MCP 서버 패턴
• ✅ 프로덕션 아키텍처 (production architecture): 감독자-작업자(supervisor-worker), 재시도(retries), 관측 가능성(observability)
• ✅ 상위 10가지 에이전트 실패 모드에 대한 실패 처리 플레이북(failure-handling playbooks)
• ✅ 에이전트를 제품으로 패키징하기 위한 수익화 청사진(monetization blueprints)
• ✅ 즉시 다운로드 — 오늘 시작하고, 이번 주에 배포하세요

👉 The AI Agents & Automation Playbook 받기 →

추신: 에이전트를 구축한다는 것은 에이전트와 대화를 잘한다는 것을 의미합니다. 500 ChatGPT Prompts Library에는 에이전트 라이프사이클(agent lifecycle)의 모든 단계에 필요한 프로덕션급 프롬프트가 포함되어 있습니다 — 이곳에 계시는 동안 확인해 볼 가치가 있습니다.