뜨거운 감자: 현재 AI 에이전트의 가장 큰 병목은 모델도, 프레임워크도, 비용도 아님. 에이전트가 실제로 작동하는지 제대로 평가할 방법이 없다는 것임
Hot take: the biggest bottleneck in AI agents right now isn't models, frameworks, or even cost. It's that nobody knows how to properly evaluate if their agent is actually working
핵심 요약
AI 에이전트의 성능을 객관적으로 평가할 표준화된 방법이 없어 실무자들이 큰 어려움을 겪고 있음.
- 평가 방법 부재 — 기존 소프트웨어와 달리 에이전트의 복잡한 추론 과정을 검증할 표준화된 테스트 체계가 없음
- 평가 기법의 한계 — 결과물 확인, 로그 검토, LLM-as-judge 등 기존 방식은 편향되거나 실효성이 낮음
- 실무적 고충 — 에이전트의 복잡성이 증가함에 따라 측정 불가능한 기반 위에 시스템을 쌓아 올리는 불안감이 큼
- 대안적 접근 — 결과 기반 체크, 무작위 샘플링, 회귀 알림 등 임시방편적인 방법으로 대응 중임
저는 약 14개월 동안 에이전트를 구축하고 배포해 왔습니다. 간단한 RAG 체인으로 시작해서 다단계 도구 호출 에이전트로 넘어갔고, 지금은 매일 실제 비즈니스 로직을 처리하는 몇 가지 프로덕션 워크플로우를 운영하고 있습니다.
그런데 저를 밤잠 설치게 하는 문제가 하나 있습니다. 제 에이전트가 정말 잘 작동하는지 도무지 모르겠다는 겁니다.
결과물을 만들어낸다는 건 압니다. 사용자들이 저에게 소리 지르지 않는다는 것도 압니다(대부분의 날에는요). 대시보드의 오류율이 '괜찮아' 보인다는 것도 압니다. 하지만 누군가 저에게 "당신의 에이전트는 실제로 얼마나 잘 수행하나요?"라고 물으면 저는 얼어붙습니다. 에이전트에게 그게 대체 무슨 의미일까요?
전통적인 소프트웨어에는 단위 테스트, 통합 테스트, 부하 테스트가 있습니다. 명확한 통과/실패가 있죠. 분류 모델에는 정밀도, 재현율, F1 점수가 있습니다. 깔끔한 숫자죠. 하지만 모호한 사용자 요청을 받아, 어떤 도구를 호출할지 결정하고, 스스로 알아낸 순서대로 도구를 호출하고, 체인 중간의 오류를 처리하며, 15가지 방식으로 옳을 수 있는 최종 결과물을 만들어내는 에이전트를 어떻게 평가해야 할까요?
제가 시도해 본 방법들과 각각 실패한 이유는 다음과 같습니다:
"최종 결과물만 확인하기" — 물론이죠, 하지만 완전히 잘못된 추론 과정을 통해서도 같은 정답에 도달할 수 있습니다. 에이전트가 운이 좋았을 수도 있죠. 저는 몇 주 동안 완벽한 요약을 만들어내는 에이전트를 본 적이 있는데, 나중에 실패 사례를 추적해 보니 전체 데이터 소스를 계속해서 조용히 건너뛰고 있었다는 걸 깨달았습니다. 누락된 소스가 우연히 중복되는 내용이었기 때문에 요약은 괜찮아 보였던 거죠. 그게 아닐 때까지는요.
"모든 단계를 기록하고 검토하기" — 2주 동안 이렇게 해봤습니다. 저도 삶이 있습니다. 일일 실행의 5%만 추적을 검토하는 데도 몇 시간이 걸렸습니다. 그리고 검토를 멈추는 순간, 다시 희망 고문으로 돌아가게 됩니다.
"LLM을 사용하여 결과물 판단하기" — LLM-as-judge. 블로그 포스트에서는 아주 좋아 보이죠. 실제로는 판단자(judge)도 자신만의 편향과 실패 모드를 가지고 있고, 이제는 그 판단자를 평가해야 합니다. 끝없는 굴레죠. 저는 제 판단자가 "잘 쓰였고 일관성 있다"는 이유로 전체 섹션을 환각으로 만들어낸 결과물에 9/10점을 주는 것을 목격했습니다. 고맙다 친구야.
"골든 데이터셋과 비교하기" — 이건 좁은 범위의 작업에는 효과적입니다. 사용자가 무엇이든 물어볼 수 있고 도구 체인이 동적인 개방형 에이전트 워크플로우에서는요? 실제 사용 사례의 3% 이상을 커버하는 골든 데이터셋을 구축할 수 있기를 행운을 빕니다.
그래서 제가 내린 결론은 — 이게 옳다고 말하는 건 아닙니다만 — 다음과 같은 엉성한 조합입니다:
- 결과 기반 체크(다운스트림 시스템이 실제로 올바르게 업데이트되었는가?)
- 무작위 샘플링을 통한 사람의 검토(고통스럽지만 정직함)
- 회귀 알림(안정적인 입력에서 갑자기 동작이 변할 때)
- 사용자 불만율을 지연 지표로 활용(네, 창피한 일입니다)
그럭저럭 작동은 합니다. 하지만 버터 나이프로 수술을 하는 기분입니다.
정말 화가 나는 건 업계 전체가 더 복잡한 에이전트 — 멀티 에이전트 시스템, 자율 루프, 다른 에이전트를 생성하는 에이전트 — 를 만들기 위해 질주하고 있는데, 단일 작업을 수행하는 단일 에이전트에 대한 평가 이야기조차 기본적으로 '느낌(vibes)'에 의존하고 있다는 점입니다.
우리는 측정할 수 없는 기반 위에 복잡성을 쌓아 올리고 있습니다.
다른 분들도 이 문제로 고생하고 계신가요? 울고 싶어지지 않는 평가 접근 방식을 찾으셨나요? 제가 찾을 수 있는 모든 블로그 포스트와 논문을 읽어봤지만, 대부분 (a) 장난감 예제에서만 작동하거나 (b) 유지 관리에 10명의 팀이 필요한 것들이라 정말로 묻고 싶습니다.
