안녕하세요! 나우캐스트(Nowcast)의 요타(よーた)입니다.

데이터 & AI 솔루션 사업부에서 AI Full-Cycle Engineer라는 직종으로 AI 에이전트 개발 및 데이터 기반 정비를 수행하고 있습니다.

최근 AI Engineer World's Fair 2026에 참가하고 왔습니다. AI Engineer World's Fair(이하 AIE WF)는 AI 에이전트 및 LLM 애플리케이션의 개발·운용에 관한 실천적 지식이 공유되는 샌프란시스코에서 개최된 기술 컨퍼런스입니다.

이번 참가 내용 중 특히 실무와 직결된다고 느낀 테마 중 하나가 Evals and Agent Improvement입니다.

AI 에이전트는 PoC(Proof of Concept) 단계라면 비교적 쉽게 동작합니다. 프롬프트(Prompt)를 작성하고, 도구(Tool)를 전달하고, 몇 번 시도해서 그럴싸한 출력이 돌아오면 "동작했다"라고 말할 수 있습니다.

하지만 실제 서비스(Production)에서 문제가 되는 것은 그 이후입니다.

• 에이전트가 실패했을 때, 어디서 실패했는가
• 수정을 통해 정말로 개선되었는가
• 이전에 가능했던 기능을 망가뜨리지는 않았는가
• 평가기(Eval) 자체는 신뢰할 수 있는가

이러한 부분들을 모호하게 둔 채 에이전트를 운용하면, 결국 "그럴듯한 출력을 보고 프롬프트를 수정하는" 수준에 머물게 됩니다.

이 기사에서는 AIE WF에서 들은 내용을 바탕으로, 에이전트의 실패를 어떻게 관측하고, 평가하고, 개선으로 연결할지를 정리합니다.

1. 에이전트는 "동작했다"만으로는 부족하다

인상적이었던 점은 에이전트를 "한 번 동작하는 것"이 아니라, "지속적으로 평가하고 개선하는 대상"으로 다루는 관점입니다.

AI 에이전트는 단일 LLM 호출이 아닙니다. 도구 호출(Tool call), 검색(Retrieval), 추론(Reasoning), 중간 출력, 최종 출력을 포함하는 다단계 시스템입니다.

따라서 최종 출력만 봐서는 실패 원인을 알 수 없습니다.

예를 들어, 최종 출력이 그럴싸하게 틀렸더라도 원인은 여러 가지일 수 있습니다.

• 취득한 정보가 나빴다
• Tool call의 인자(Argument)가 틀렸다
• 중간 추론 과정에서 해석을 잘못했다
• 마지막 문장화 과정에서 근거 이상의 내용을 작성했다

따라서 에이전트 개발에서 중요한 것은 단순히 최종 답변을 살펴보는 것이 아니라, 실패를 관측 가능하게 만드는 것입니다.

1.1 Evals도 평범하게 거짓말을 한다

한편, Evals를 도입한다고 해서 안심할 수 있는 것도 아닙니다.

특히 LLM as a Judge에는 몇 가지 전형적인 편향(Bias)이 존재합니다. Kumar 씨의 세션에서는 다음과 같은 편향이 소개되었습니다.

• position bias: 먼저 제시된 선택지를 고르기 쉬운 경향
• sycophancy: 사용자나 후보 답변에 아부하기 쉬운 경향
• self-preference: 동일한 모델 패밀리의 출력을 선호하는 경향
• verbosity bias: 길고 자신만만해 보이는 답변을 높게 평가하는 경향

또한, Arize의 워크숍에서도 유사한 편향이 소개되었습니다.

즉, LLM as a Judge는 "평가기"이기는 하지만, "진리"는 아닙니다.

따라서 이 기사에서는 단순히 "Evals를 도입한다"는 것을 넘어, 에이전트의 실패를 관측하고, 평가를 단계적으로 키워나가며, 그 평가 자체도 의심하면서 개선 실험으로 연결하는 것으로 파악합니다.

1.2 작게 시작하기: LLM as a Judge로 바로 뛰어들지 말 것

평가 기반은 작게 시작해야 합니다.

처음부터 완벽한 평가 기반이나 자동 개선 메커니즘을 만드는 것은 어렵습니다. 미성숙한 평가 기준인 상태에서 자동 개선을 돌리면, 품질 개선이 아니라 "평가의 허점을 찌르는 최적화"가 되어버립니다.

현실적으로는 다음과 같은 순서로 키워나가는 것이 좋아 보입니다.

Trace
↓
Error Analysis
...

여기서 중요한 것은 곧바로 LLM as a Judge로 뛰어들지 않는 것입니다.

출력의 필수 항목, enum, 참조 ID 등은 LLM에게 평가를 맡길 필요가 없습니다. 코드로 간단히 검증할 수 있습니다. LLM as a Judge를 정말로 사용해야 하는 곳은 코드로 판정하기 어려운 의미론적(Semantic) 품질입니다.

작게 시작한다는 것은 평가를 대충 한다는 뜻이 아닙니다. 관측할 수 있는 것, 코드로 방어할 수 있는 것, LLM에게 판단을 맡길 것, 인간이 확인해야 할 것을 구분하는 것입니다.

2. Trace: 에이전트의 실패를 관측하기

에이전트 개선의 첫걸음은 Trace입니다.

이번 AIE WF를 통해 이미 많은 기업에서 Observability 기반 도입은 전제 조건이 되어가고 있다는 느낌을 받았습니다.

이는 단순히 로그를 남기는 차원의 이야기가 아니라, 에이전트(Agent)의 행동을 사후에 분석, 비교, 개선하기 위한 데이터를 남기는 것이 중요하다는 점을 많은 기업이 인식하고 있다는 방증이라고 생각합니다.

이 점은 이전에 제가 작성했던 글과도 관련이 있는 생각입니다.

해당 글에서 Observability에 대해 다음과 같이 정리했습니다.

관측 단위는 "처리가 실행된 단위"가 아니라, "나중에 비교·교체·개선하고 싶은 단위"로 나누어야 한다.

이는 AIE WF에서의 Trace/Evals 이야기와도 그대로 연결됩니다.

Trace를 나누는 방식이 잘못되면 실패가 보이지 않습니다. 실패가 보이지 않으면 Eval(평가)도 작성할 수 없습니다. Eval을 작성할 수 없으면 개선 실험도 할 수 없습니다.

에이전트 개선에 있어 Trace는 개선 루프(Improvement Loop)의 토대라고 할 수 있습니다.

3. Evals: 저렴하게 방어할 수 있는 것부터, 의미적인 품질로

Trace를 확보했다면, 다음에 해야 할 일은 Eval을 만드는 것입니다.

단, 여기에서도 순서가 있습니다.

3.1 Code-Based Eval: 결정적으로 판정할 수 있는 것을 방어하기

Code-Based Eval은 LLM을 사용하지 않고 결정적으로 판정할 수 있는 평가입니다.

예를 들어 다음과 같은 것들은 Code-Based Eval로 확인해야 합니다.

• 필수 항목이 채워져 있는가
• 참조 ID가 후보 리스트에 존재하는가
• 추출된 값의 근거 텍스트가 원본 페이지에 존재하는가

이전 글에서도 LLM 출력을 pageId나 구조화된 데이터(Structured Data)로 제한하고, ID 검증 및 에비던스(Evidence) 검증을 코드 측면에서 수행하는 설계에 대해 썼습니다.

Eval의 관점에서도 마찬가지로, 코드로 판정할 수 있는 것은 코드로 검증하는 편이 더 저렴하고, 빠르며, CI(지속적 통합)에 올리기도 쉽습니다.

예를 들어, Arize의 워크숍에서는 금융 상품을 수집하여 리포트를 작성하는 에이전트에 대해, 종목 코드가 지정된 범위 내에 있는지 체크하는 Eval을 다음과 같이 소개했습니다.

class MentionsEvaluator(CodeEvaluator):
def evaluate(
self,
...

LLM이 잘못된 정보를 참조하고 있는지와 같은 거친 수준의 검증이라면, 이 Code-Based Eval만으로도 충분히 검증할 수 있습니다.

3.2 LLM as a Judge: 의미적인 품질을 확인하기

물론 코드로 평가하기 어려운 의미적인 품질도 있습니다. 이러한 평가에는 LLM as a Judge가 유효합니다.

Arize의 워크숍에서는 Correctness / Faithfulness / Actionability 등의 관점을 나누어 LLM에게 평가를 맡기는 사례가 소개되었습니다.

특히, 하나의 Evaluator는 하나의 관점(Dimension)만 바라봐야 한다는 점이 중요한 포인트입니다.

다음은 워크숍에서 소개된 예시입니다.

from phoenix.evals import ClassificationEvaluator
actionability_template = """
You are an expert financial analyst evaluator. Your task is to judge whether
...

이 예시와 함께, 좋은 판정 기준(Rubric) 프롬프트를 작성하는 방법도 소개되었습니다.

• Role을 명확히 하기
• pass/fail 평가 기준을 구체적으로 작성하기
• 입력 데이터와 평가 대상을 XML tag 등으로 명확히 구분하기
• 출력 선택지는 프롬프트 외부에 작성하기

여기서 특히 중요하다고 느낀 점은 평가 기준을 책상 위에서(머릿속으로만) 만들지 않는 것입니다.

Trace를 읽고, 에러나 에지 케이스(Edge Case)를 평가하며, 실제 실패 사례로부터 평가 기준을 만듭니다.

다음은 이 워크숍에서 나온 문구인데, 매우 실천적이라 공감이 갑니다.

오늘 발견한 Failure가 내일의 Criteria가 된다.

3.3 Meta Evaluation: Judge 자체를 의심하기

LLM as a Judge를 만들었다고 해서 끝이 아닙니다.

이 Evaluator 자체를 평가해야 합니다.

흐름은 간단합니다.

1. 실제 Trace를 몇 개 선정한다
2. 사람이 정답 라벨(Ground Truth)을 붙인다
3. 동일한 Trace를 LLM as a Judge에게 평가하게 한다
...

기준으로는 사람의 라벨과 일치율이 80~85% 정도인 것을 목표로 하는 것이 좋다고 합니다. 100% 일치한다면 소수의 데이터에 과적합(Overfitting)되었을 가능성도 있습니다.

4. Trace Mining과 Auto Improvement

Trace와 Eval이 갖춰져야 비로소 개선 루프(Improvement Loop)를 만들 수 있습니다.

4.1 Trace는 개선 데이터가 된다

Langchain 세션에서 인상적이었던 점은 Observability(관측성)와 Continual Learning(지속적 학습)을 동전의 양면처럼 다루고 있었다는 점입니다.

에이전트가 환경에서 동작하면 tool call, 중간 출력, 최종 출력 등이 Trace로서 남게 됩니다.

이것들은 단순한 로그가 아니라 개선 데이터입니다.

Trace를 통해서는 실패 분류, Eval 데이터셋, 회귀 테스트(Regression Test), 프롬프트·Tool 개선용 데이터, 증류(Distillation)나 Fine-Tuning(미세 조정)용 데이터를 만들 수 있습니다.

먼저 v1을 만들어 실행한다. Trace를 수집한다. Trace를 정리·분류한다. 그 데이터로 개선 실험을 한다.

소박하지만 상당히 실무적이라고 느꼈습니다.

4.2 평가 결과를 개선 실험으로 연결하기

워크숍에서는 Judge의 평가 이유 텍스트를 사용하여 에이전트의 프롬프트를 개선하는 흐름이 소개되었습니다.

구체적으로는, 평가에서 실패한 Trace를 모으고, 그 Judge 결과를 LLM에 전달하여 프롬프트를 개선하게 합니다. 그 후, 개선된 에이전트를 동일한 실패 데이터셋에 대해 실행하여 실험 결과로서 비교합니다.

이 그림은 Arize AX를 전제로 하고 있지만, 운영 트래픽(Production Traffic)에서 Trace가 생성되고, 온라인 Eval을 통해 평가되며, 실패 이유가 평가 이유 텍스트로 축적되고, 이를 바탕으로 수정안을 만들고, 수정안을 실험으로 검증한 뒤 다시 운영 환경으로 되돌리는 루프를 보여주고 있었습니다.

이 이상적인 루프가 잘 돌아간다면, 에이전트는 운영 환경으로부터 지속적으로 개선되어 나갈 것입니다.

단, 평가가 어긋나 있다면 개선도 어긋납니다. 검증되지 않은 LLM as a Judge를 믿고 개선 루프를 돌리면, 에이전트가 정말로 좋아지는 것이 아니라 Judge의 편향(Bias)에 최적화될 가능성이 있습니다.

4.3 Auto Improvement는 출발점이 아니라 도달점이다

Trace와 Eval이 갖춰지면, 그 결과를 사용하여 에이전트를 자동으로 개선할 수도 있습니다.

다른 세션에서는 그 예로 GEPA가 소개되었습니다. GEPA는 평가 점수뿐만 아니라 Trace, Tool의 에러, Evaluator의 피드백과 같은 텍스트 정보도 LLM이 분석하게 함으로써 프롬프트의 개선 후보를 만드는 기법입니다.

자세한 내용은 GEPA의 리포지토리나 GEPA를 간단히 사용할 수 있는 optimize_anything을 참조하십시오.

GEPA와 같은 자동 개선 메커니즘 자체는 혁신적이며 앞으로 주류가 될 것이라고 생각합니다. 다만, 여기서 주의해야 할 점은 Auto Improvement가 출발점이 아니라는 것입니다.

Trace가 있고, Error Analysis(에러 분석)가 있고, Code-Based Eval이 있고, LLM as a Judge가 있으며, 그 Judge 자체의 신뢰성을 검증하고 나서야 비로소 Auto Improvement로 나아가는 의미가 있습니다.

5. 요약

AIE WF의 Evals 관련 세션들을 통해 알 수 있었던 것은 에이전트 개발의 중심이 바뀌고 있다는 점입니다.

지금까지는 좋은 프롬프트를 작성하는 것, 강력한 모델을 선택하는 것, Tool을 연결하는 것에 주목이 쏠리는 경향이 있었습니다.

하지만 에이전트를 운영 환경에서 운용하려면 실패를 관측하고, 평가하고, 개선 실험으로 연결하는 루프가 필수불가결합니다.

처음부터 크게 시작할 필요는 없습니다.

먼저 Trace를 남긴다. Trace로부터 실패를 분류한다. Eval을 만든다. 그 Eval 또한 인간 라벨(Human Label)로 검증한다. 마지막으로 평가 결과를 개선 실험으로 연결한다.

AIE WF에서 얻은 가장 실무적인 배움은, 에이전트 개선은 마법이 아니라 관측 가능한 학습 루프로 설계해야 한다는 것이었습니다.

이번 글에서는 Eval에 집중하여 소개했지만, 에이전트는 프롬프트만으로 이루어지지 않습니다. 특히 Context, Harness, 그리고 Loop의 설계가 필수적입니다.

다음 글에서는 이 Context / Harness / Loop Engineering에 관한 세션을 소개하며, 2026년 시점에서의 현재 위치를 깊이 있게 다루어 보겠습니다.

참고한 세션·워크숍

참고한 세션·워크숍

• From Vibes to Production: Evaluating and Shipping AI Agents That Work, Laurie Voss (Arize AI)
• Evals in AI: A Deep Dive, Tejas Kumar (IBM)
• Improving Agents is a Data Mining Problem, Vivek Trivedy (LangChain)
• Self-Improvement of Context, Harness, and Model Weights through Reflective Optimization, Lakshya Agrawal (GEPA의 제작자 및 유지보수 담당자)

토론