AI 에이전트, 데모는 되는데 실전에선 왜 무너질까 — 평가(eval)가 답이다
AI 에이전트, 데모는 되는데 실전에선 왜 무너질까 — 평가(eval)가 답이다
결론부터 말씀드릴게요. AI 에이전트를 만드는 일은 이제 어렵지 않습니다. 프레임워크와 표준 아키텍처를 쓰면 기본 에이전트는 금방 돌아가죠. 진짜 어려운 건 그걸 실전에서 믿고 맡기는 것이고, 데모와 프로덕션 사이의 그 절벽을 건너게 해주는 사다리가 바로 평가(evaluation, 줄여서 eval — 에이전트가 일을 제대로 했는지 채점하는 체계) 입니다. 핵심은 하나예요. 최종 답이 맞았는지가 아니라, 그 답에 이르는 과정을 채점해야 한다는 겁니다.
데모는 완벽한데 실전은 왜 무너질까요
시연 자리에서는 에이전트가 척척 답을 내놓습니다. 그런데 실제 업무에 태우면 이상하게 자꾸 삐끗하죠. 많은 분이 "모델이 부족한가" 싶어 더 좋은 모델로 갈아탑니다. 하지만 원인은 대개 모델이 아니라 검증 체계의 부재입니다.
여기서 요리에 비유해 볼게요. 접시에 담긴 최종 요리만 맛보면 합격 도장을 찍기 쉽습니다. 그런데 조리 과정(위생, 순서, 불 조절)이 엉망이었다면, 다음 손님 때는 같은 맛이 안 나옵니다. 시식만으로는 그걸 알 수 없죠. 에이전트도 똑같아요. 데모에서 답이 맞은 건 "이번엔 운이 좋았을 뿐"일 수 있습니다.
비결정성이라는 함정
LLM(대규모 언어 모델)은 비결정적(non-deterministic, 같은 질문에도 매번 조금씩 다르게 반응하는 성질)입니다. 그래서 에이전트가 엉뚱한 경로를 밟고도 정답에 도달할 수 있어요. 최종 답만 보면 멀쩡해 보이지만, 그 안을 열어보면 상황이 다릅니다.
예를 들어 엉뚱한 도구를 호출했는데 우연히 맞는 데이터가 돌아왔거나, 실패한 단계를 여러 번 재시도한 끝에 겨우 성공했거나, 저렴한 방법으로 될 일을 비싼 방법으로 처리했을 수 있습니다. 겉보기엔 성공이지만 조건이 조금만 달라지면 그대로 무너지죠. 이렇게 잘못된 과정으로 얻은 정답을 흔히 거짓 양성(false positive)이라고 부릅니다. 겉으로는 통과처럼 보이지만 실제로는 프로덕션 리스크인 셈이에요.
해법은 '궤적'을 채점하는 평가입니다
그래서 최종 출력만 보는 방식으로는 부족합니다. 봐야 할 건 궤적(trajectory, 에이전트가 답에 이르기까지 밟은 전체 과정) 이에요. 어떤 도구를 어떤 순서로 불렀는지, 중간 추론은 타당했는지, 재시도와 오류 처리는 어땠는지까지 통째로 채점하는 겁니다.
시험 채점에 비유하면 이해가 쉬워요. 정답만 맞으면 만점을 줄까요? 풀이 과정이 요행이었다면, 숫자만 살짝 바꾼 문제에서 바로 틀립니다. 운전 시험도 마찬가지죠. 목적지에 도착했다고 합격이 아니라 신호, 차선, 속도 같은 주행 과정을 봅니다. 에이전트 평가도 '도착'이 아니라 '주행'을 봐야 합니다.
실무에서는 에이전트를 통째로 두고 채점하지 않습니다. 라우터(요청을 어디로 보낼지 결정하는 부분), 스킬 1, 스킬 2처럼 개별 단계로 분해한 뒤 각 단계를 따로 평가하죠. 그래야 어디서 무너지는지 콕 짚어낼 수 있습니다.
평가를 코드 테스트처럼 다루는 eval-driven development
여기서 한 발 더 나아가면 평가를 배포를 막는 자동화 테스트처럼 쓰는 방식이 나옵니다. 소프트웨어 개발에서 테스트를 통과해야 배포하듯, 에이전트도 변경할 때마다 "이게 정말 더 나아졌나"를 자동으로 검증하고 통과해야 내보내는 거예요. AI 에이전트에 CI/CD(코드를 자동으로 검증하고 배포하는 개발 규율)를 입히는 셈입니다.
이 방식의 진짜 가치는 순서에 있습니다. 고객이 문제를 신고하기 전에 팀이 먼저 잡아냅니다. 그리고 에이전트 개발은 한 번에 끝나는 직선이 아니라 순환에 가까워요. 대표 테스트 케이스를 만들고, 단계별로 쪼개 실험하고, 실제 운영 데이터로 테스트 케이스와 채점 기준을 다시 손보는 과정을 계속 도는 겁니다.
관찰가능성과 평가는 짝이지만 같은 게 아닙니다
자주 헷갈리는 두 개념을 정리하고 갈게요. 관찰가능성(observability, 지금 운영 중인 시스템에서 무슨 일이 벌어지는지 들여다보는 것) 은 사후 진단입니다. "지금 뭐가 일어나고 있나"에 답하죠. 반면 평가는 사전 게이트예요. "이 변경이 실제로 품질을 올리나"에 답합니다. 배포 전후로 역할이 다릅니다.
특히 에이전트 관찰가능성은 단순한 모델 모니터링과 다릅니다. 여러 차례 주고받는 멀티턴 대화의 실패는 개별 호출 하나만 보면 절대 안 드러나요. 전체 세션의 인과를 이어 붙인 트레이스(trace, 관련된 처리 단계들을 하나로 묶어 흐름을 보여주는 기록)에서만 보입니다.
AI로 AI를 채점하는 LLM-as-judge, 심판도 관리 대상입니다
평가를 규모 있게 자동화하려면 사람이 일일이 채점하기 어렵죠. 그래서 LLM-as-judge(LLM을 정해진 기준으로 응답을 채점하는 심판으로 쓰는 것) 가 등장합니다. 강력한 방법이지만 함정도 있어요. 심판 역시 완벽하지 않습니다. 프롬프트가 모호하거나, 모델에 편향이 있거나, 채점 가이드라인이 흐릿하면 채점 결과가 들쭉날쭉해집니다.
그래서 심판 프롬프트 자체를 계속 다듬어야 합니다. 무엇을 어떤 기준으로 채점할지 명확히 할수록 일관성과 공정성, 정확성이 올라가죠. 심판을 세워뒀다고 끝이 아니라, 심판도 꾸준히 관리해야 할 대상이라는 뜻입니다.
실전에 태우려는 기업이라면
여기까지 오면 도구와 표준도 궁금하실 텐데요. 대표적으로 Arize Phoenix 같은 오픈소스 관찰가능성·평가 플랫폼이 있습니다. 명령 하나로 직접 띄울 수 있고, OpenTelemetry(처리 기록을 표준 형식으로 실어 나르는 규약)와 OpenInference 같은 표준을 써서 특정 회사 기술에 묶이지 않게 설계돼 있어요. 충실성, 관련성, 환각, 유해성 같은 평가자를 내장하고 있고, LangGraph나 CrewAI, 주요 에이전트 SDK 등 프레임워크를 가리지 않고 붙습니다.
기업 관점에서 이 이야기를 정리하면 이렇습니다. "만드는 것"과 "믿고 맡기는 것"은 전혀 다른 문제예요. 평가 체계 없는 에이전트는 시연용 장난감에 머뭅니다. 실제 업무에 태우려면 ① 업무를 대표하는 테스트 케이스, ② 최종 답이 아닌 과정을 보는 궤적 평가, ③ 통과해야만 배포되는 게이트, 이 세 가지가 세트로 필요합니다. AI 전환(AX)을 고민하는 조직일수록, 화려한 데모보다 이 평가 체계를 먼저 갖추는 쪽이 결국 빠릅니다.
자주 묻는 질문 (FAQ)
Q. 에이전트가 답을 잘 내놓는데도 평가가 필요한가요?
네, 오히려 그럴 때 더 필요합니다. 답이 맞았다는 건 이번 한 번의 결과일 뿐이에요. 비결정성 때문에 엉뚱한 과정으로도 정답이 나올 수 있어서, 과정을 채점하지 않으면 조건이 바뀌는 순간 무너집니다.
Q. 관찰가능성 도구만 붙이면 평가는 안 해도 되나요?
둘은 짝이지만 역할이 다릅니다. 관찰가능성은 "지금 무슨 일이 일어나나"를 사후에 보여주고, 평가는 "이 변경이 정말 품질을 올리나"를 배포 전에 판정합니다. 진단만으로는 나쁜 변경이 나가는 걸 막지 못해요.
Q. 궤적 평가는 무엇을 채점하나요?
최종 출력만이 아니라 에이전트가 밟은 전체 과정을 봅니다. 어떤 도구를 어떤 순서로 호출했는지, 중간 추론은 타당했는지, 재시도와 오류 처리는 어땠는지까지요. 운전 시험에서 도착이 아니라 주행을 채점하는 것과 같습니다.
Q. LLM으로 채점하면 결과를 믿어도 되나요?
기본은 강력하지만 심판도 편향과 모호함의 영향을 받습니다. 프롬프트가 흐릿하면 채점이 들쭉날쭉해지죠. 심판 프롬프트와 채점 기준을 명확히 다듬을수록 일관성과 정확성이 올라갑니다.
