평가 격차(The Eval Gap): 에이전트에게 관찰 가능성(Observability)은 있지만, 성능이 좋은지는 알 수 없는 이유

한번 곱씹어 볼 만한 수치가 있습니다. 1,300명 이상의 실무자를 대상으로 조사한 LangChain의 2026 State of Agent Engineering 보고서에 따르면, 프로덕션(production) 환경에서 에이전트를 실행하는 팀의 89%가 관찰 가능성(observability)을 구현했지만, 평가(evaluations)를 구현한 팀은 52%에 불과했습니다. 이 37%포인트의 격차는 대부분의 에이전트 품질이 조용히 무너지는 지점입니다.

만약 여러분이 LLM 에이전트를 출시했다면, 비록 그 이름을 명명하지 않았더라도 이미 이 격차를 느끼고 있을 것입니다. 여러분에게는 트레이스(traces)가 있습니다. 대시보드(dashboards)도 있습니다. 어떤 세션이든 다시 재생하여 에이전트가 추론(reasoning)하고, 도구(tools)를 호출하며, 응답하는 과정을 지켜볼 수 있습니다. 하지만 누군가 "이번 주에 성능이 실제로 나아지고 있나요, 아니면 나빠지고 있나요?"라고 묻는다면, 솔직한 대답은 어깨를 으쓱하는 것뿐일 것입니다. 일어난 모든 일을 볼 수는 있지만, 그중 무엇이 좋았는지는 여전히 알 수 없습니다.

이것이 바로 관찰 가능성(observability)과 평가(evaluation)의 차이이며, 이 둘을 혼동하는 것은 현재 에이전트 엔지니어링(agent engineering)에서 가장 비용이 많이 드는 실수입니다.

관찰 가능성(Observability)은 무엇이 일어났는지 알려줍니다. 평가는 그것이 _옳았는지_를 알려줍니다.

관찰 가능성(Observability)은 현미경과 같습니다. 그것은 궤적(trajectory)을 보여줍니다. 즉, 에이전트가 쿼리(query)를 받았고, 문서 3개를 검색(retrieve)했으며, 이러한 인자(arguments)로 search_orders 도구를 호출했고, 이 응답을 받았으며, 이 답변을 생성했다는 식입니다. 디버깅(debugging)에는 매우 귀중한 정보입니다. 하지만 사용자에게 중요한 질문, 즉 "답변이 정확하고, 도움이 되며, 안전했는가?"라는 질문에 대해서는 완전히 침묵합니다.

평가(Evaluation)는 트레이스(trace) 위에 놓인 판단 계층입니다. 평가은 동일한 궤적을 가져와 다음과 같이 질문합니다. 에이전트가 올바른 도구를 호출했는가? 도구가 에러를 반환했을 때 에이전트가 복구(recover)했는가? 최종 답변이 검색한 내용에 사실적으로 근거(factually grounded)했는가, 아니면 그럴싸하게 들리는 주문 번호를 환각(hallucinate)했는가? 환불 정책을 따랐는가, 아니면 임의로 만들어냈는가?

많은 팀이 전자는 갖추고 있지만 후자는 갖추지 못한 이유는 간단합니다. 관찰 가능성(observability)은 프레임워크와 함께 제공되지만, 평가(Evals)는 직접 구축해야 하기 때문입니다. 그리고 평가를 제대로 구축한다는 것은 대부분의 엔지니어링 팀이 해결할 준비가 되어 있지 않은 문제에 직면함을 의미합니다. 즉, '무엇이 좋은 결과물인지'에 대한 라벨링된 예시(labeled examples)가 필요하며, 그 예시들은 신뢰할 수 있어야 합니다. 이는 도구(tooling)의 문제이기 훨씬 이전에 데이터의 문제입니다.

에이전트 평가의 3단계

이 격차를 줄이고 있는 팀들은 하나의 거대한 평가를 실행하는 것이 아닙니다. 그들은 이미 테스트를 생각하는 방식과 깔끔하게 매칭되는 세 가지 단계로 평가를 인프라로서 실행하고 있습니다.

1단계: 모든 변경 사항에 대한 빠른 점검 (fast checks on every change). 이것은 에이전트 세계의 단위 테스트(unit tests)입니다. 에이전트가 유효한 인자(arguments)와 함께 예상된 도구(tool)를 호출했는가? 지연 시간(latency)과 토큰 예산(token budget)을 준수했는가? 명백한 거부(refusal)나 루프(loop)를 피했는가? 이것들은 비용이 저렴하고 결정론적(deterministic)이며, 모든 PR(Pull Request)에서 실행됩니다. 이는 프롬프트 수정으로 인해 특정 카테고리의 입력에 대한 도구 호출(tool-calling) 기능이 망가지는 것과 같은 어리석은 회귀(regressions)를 잡아냅니다.

2단계: 품질 회귀 테스트 스위트 (quality regression suites). 여기서부터 어려워지는데,

LLM-as-judge(판사로서의 LLM)에 대한 불편한 진실은 이것입니다: 정렬되지 않은(unaligned) 판사는 자신감 있게 거짓말을 한다는 점입니다. 에이전트(agent)의 출력을 점수 매기는 모델은 자체적인 편향(biases)을 가지고 있습니다. 즉, 더 긴 답변을 선호하고, 정확성보다는 자신감 있는 어조에 보상을 주며, 실제 전문가라면 즉각적으로 잡아낼 도메인 특화 오류(domain-specific errors)를 놓칩니다. 만약 판사가 품질이 94%라고 말하는데 사용자들이 이탈(churning)하고 있다면, 당신의 판사는 틀린 것이며, 대시보드와 현실이 완전히 괴리(decoupled)될 때까지 당신은 그 사실을 알 수 없을 것입니다.

해결책은 인간의 판단(human judgment)에 맞춘 교정(calibration)입니다. 대표 샘플을 추출하여 자격을 갖춘 인간이 점수를 매기게 한 다음, LLM 판사의 점수가 인간의 점수와 상관관계(correlate)를 가질 때까지 프롬프트(prompt)와 루브릭(rubric)을 조정해야 합니다. 동일한 LangChain 데이터는 이것이 왜 중요한지를 보여줍니다. 평가(evals)를 실행하는 팀의 약 60%가 여전히 미묘하고 중대한 사안에 대해 LLM-as-judge에 의존하기보다 인간의 검토(human review)에 의존하고 있으며, 이는 LLM-as-judge에 의존하는 것보다 더 높은 비중입니다. 인간의 검토는 자동화로 사라져가는 구식 방식이 아닙니다. 그것은 자동화를 신뢰할 수 있게 만드는 정답(ground truth)입니다.

이 부분은 아무도 좋아하지 않는데, 왜냐하면 엔지니어링처럼 보이지 않는 노동이기 때문입니다. 실제 도메인 전문 지식을 갖춘 사람 — 의료 에이전트를 위한 임상의, 코딩 에이전트를 위한 개발자, 금융 봇을 위한 금융 분석가 — 이 직접 앉아서 수백 개의 궤적(trajectories)을 주의 깊게 판단해야 합니다. 그 판단의 품질이 전체 평가 시스템 품질의 상한선(ceiling)이 됩니다. 쓰레기 같은 참조 레이블(reference labels)은 쓰레기 같은 판사를 만들고, 이는 당신에게 엄청난 자신감을 가지고 거짓말을 하는 대시보드를 만들어냅니다.

이것이 데이터 품질과 연결되는 지점

여기서 한 가지 실질적인 아이디어를 얻는다면, 그것은 바로 이것입니다: 당신의 평가 시스템은 그 밑바탕에 있는 인간이 레이블링한 데이터만큼만 훌륭할 수 있습니다. 프레임워크가 아닙니다. 대시보드도 아닙니다. 바로 레이블(labels)입니다.

그렇기 때문에 에이전트 품질에 진심인 팀들은 평가 데이터(evaluation data)를 학습 데이터(training data)에 적용하는 것과 동일한 엄격함으로 다룹니다. 즉, 명확한 루브릭(rubrics), 전문가 어노테이터(expert annotators), 불일치를 잡아내기 위한 다회차 검토(multiple passes), 그리고 레이블 자체의 일관성을 확인하기 위한 측정된 평가자 간 신뢰도(inter-rater reliability)를 적용합니다. 이것이 바로 고품질의 모델 평가 및 QA (model evaluation and QA) 작업이 구축되는 핵심 원칙입니다. 여기에는 벤치마크 데이터셋 구축, 루브릭에 따른 응답 점수 산정, 환각(hallucination) 탐지, 그리고 해피 패스(happy-path) 테스트로는 절대 드러나지 않을 실패 모드(failure modes)를 찾기 위한 레드팀(red-teaming) 활동이 포함됩니다.

이는 또한 추론 및 인간 피드백 데이터 (reasoning and human-feedback data)의 영역과도 밀접하게 겹칩니다. 선호도 순위 지정(preference ranking), 에이전트 궤적 수정(agent trajectory correction), 도구 사용 검증(tool-use validation) 등이 그 예입니다. 다단계 에이전트 궤적(multi-step agent trajectory)을 살펴보고 정확히 어느 지점에서 잘못되었는지 찾아내는 기술은, 모델을 개선하기 위해 RLHF 데이터를 생성하든 모델을 측정하기 위해 평가 레이블(eval labels)을 생성하든 동일한 기술입니다. 학습을 위한 양질의 인간 피드백을 생성하는 파이프라인은 평가를 위한 신뢰할 수 있는 판사(judge)를 생성하는 파이프라인과 같습니다. 대부분의 팀은 첫 번째 캘리브레이션(calibration) 실행 결과, 판사와 전문가의 의견이 사례의 3분의 1에서 일치하지 않는다는 사실을 깨닫고 나서야 이 점을 고통스럽게 깨닫게 됩니다.

구체적인 시작점

모든 것을 한꺼번에 해결하려고 할 필요는 없습니다. 만약 귀하의 팀이 관찰 가능성(observability)은 갖추고 있지만 평가(evals)는 갖추지 못한 89%와 48% 사이에 속해 있다면, 첫 주에 바로 실행할 수 있는 조치는 다음과 같습니다:

1. 트레이스(traces)에서 100개의 실제 운영 트래젝토리(production trajectories)를 추출하세요. 성공 사례, 불만 사항, 그리고 기이한 엣지 케이스(edge cases)가 적절히 섞여 있는 것이 이상적입니다.
2. 루브릭(rubric)을 작성하세요. 3~5개의 차원을 설정하고, 각 차원에는 구체적인 통과/실패(pass/fail) 기준을 포함해야 합니다. 귀하의 제품에 있어 "근거가 있는(grounded)" 것과 "정책을 준수하는(policy-compliant)" 것이 실제로 무엇을 의미하는지 스스로 정의하도록 강제하세요.
3. 도메인 전문가(domain expert) — 진짜 전문가를 — 섭외하여 100개 모두를 수동으로 채점하게 하세요. 두 명의 전문가가 얼마나 자주 일치하는지 측정하십시오. 만약 일치하지 않는다면, 루브릭이 너무 모호하다는 뜻입니다. 무언가를 자동화하기 전에 이를 먼저 수정하십시오.
4. 이제 LLM-판사(LLM-judge)를 구축하고, 단 하나의 자동화된 점수라도 신뢰하기 전에 해당 100개의 인간 라벨(human labels)을 기준으로 검증하십시오.

이러한 순서 — 인간의 정답(ground truth)을 먼저 구축하고, 자동화를 그 다음에 배치하는 것 — 가 게임의 핵심입니다. 3단계를 건너뛰고 곧바로 LLM-as-judge로 뛰어드는 팀들은 대시보드가 현실과 동떨어지게 되는 팀들입니다.

관찰 가능성(Observability)은 에이전트가 _무언가_를 했다는 것을 알려줍니다. 정직한 인간 라벨링 데이터에 기반한 평가(Evaluation)는 에이전트가 올바른 일을 했는지를 알려줍니다. 에이전트가 실제 운영 환경에서 실질적인 결정을 내리는 2026년에는, 이것은 있으면 좋은 기능(nice-to-have)이 아닙니다. 그것은 신뢰할 수 있는 에이전트와, 그저 고해상도로 실패하는 모습을 지켜보고만 있어야 하는 에이전트 사이의 차이입니다.

저는 SyncSoft.AI에서 근무하고 있으며, 이곳의 이중 언어 구사 및 SME(도메인 전문가) 주도 팀들은 AI 팀을 위한 평가 데이터셋, 인간 피드백 데이터, 그리고 QA 파이프라인을 구축합니다. 만약 평가 격차(eval gap)로 고군분투하고 있으며 귀하의 유스케이스(use case)에 적합한 양질의 참조 데이터가 어떤 모습인지 논의하고 싶다면, 언제든 의견을 나누고 싶습니다 — 언제든 연락해 주세요.