최근 한 연구가 "AI 에이전트 벤치마크가 코딩에 과몰입한 나머지, 미국 노동시장의 92%를 사실상 평가 밖에 두고 있다"고 지적했습니다1. 이게 중요한 이유는 단순합니다. 벤치마크는 '성적표'이자 '개발 지도'라서, 우리가 무엇을 측정하느냐가 곧 무엇을 발전시키는지로 이어지기 때문입니다.
AI 에이전트 벤치마크가 코딩에 쏠리는 이유
코딩 과제는 채점이 쉽습니다. 패치를 만들었는지, 테스트가 통과했는지처럼 "정답/오답"을 자동으로 가를 수 있죠. 그래서 SWE 계열 리더보드가 빠르게 커졌고, 모델 비교도 간편해졌습니다(예: SWE-bench 같은 장기 소프트웨어 과제)2.
그런데 현실의 '일'은 대부분 정답이 하나가 아닙니다. 고객이 화났을 때 어떤 문장으로 진정시키는지, 영업에서 어떤 제안을 하는지, 병원에서 어떤 정보를 추가로 물어봐야 하는지처럼 모호함과 상호작용이 핵심입니다. 코딩형 벤치마크로는 이런 능력이 "점수화"되지 않으니, 모델이 좋아져도 현장 체감은 낮아지는 일이 생깁니다.
"실전형 평가"는 무엇을 봐야 하나: 도구·기억·복구력
현장에서의 에이전트는 한 번 답하고 끝나는 챗봇이 아니라, 목표를 향해 여러 단계를 밟고 도구를 고르고 실패를 복구하는 시스템에 가깝습니다. 아마존이 에이전트 평가를 '최종 답'만 보지 말고, 도구 선택 정확도, 멀티스텝 계획의 일관성, 메모리 검색 품질, 실패 감지와 복구까지 분해해 보자고 제안하는 이유가 여기에 있습니다3.
즉 "코딩을 잘하나?"보다 "업무를 끝까지 완주하나?"가 핵심입니다. 이메일에서 핵심 요청을 뽑아 티켓을 만들고, CRM을 열어 고객 이력을 확인하고, 일정 충돌을 피해서 미팅을 잡는 과정을 안정적으로 수행하는지처럼 말이죠.
보안·안전 벤치마크가 같이 가야 하는 이유
업무형 에이전트는 브라우저, 파일, 메신저, 터미널 같은 '강한 도구'를 쥐게 됩니다. 그래서 성능만 올리면 끝이 아니라, 위험한 지름길을 택하지 않는지(정보 유출, 정책 위반, 불필요한 파일 삭제 등)도 함께 평가해야 합니다. 실제 도구 환경에서 350개 이상의 멀티턴 과제를 통해 에이전트의 위험 행동을 측정하는 프레임워크가 나오는 흐름도 이런 배경입니다4.
한 줄로 요약하면, "업무를 잘하는 에이전트"는 "사고 안 치고 일 처리하는 에이전트"여야 합니다.
시사점: 벤치마크가 바뀌면 제품 로드맵이 바뀐다
팀에서 AI 에이전트를 도입하거나 만들 계획이라면, 리더보드 점수만으로 판단하기보다 우리 업무를 닮은 미니 벤치마크를 먼저 만드세요. 예를 들어 'CS 문의 분류→환불 정책 확인→고객 답변→티켓 업데이트'처럼 도구 사용과 예외 상황(정보 누락, 사용자가 화남, 정책 충돌)을 일부러 섞어 두는 겁니다.
그리고 평가지표는 "정답률" 하나로 끝내지 말고, 작업 완주율, 도구 선택 오류율, 재시도 후 회복률, 대화 맥락 유지(히스토리와의 일치) 같은 항목으로 쪼개 보세요. 코딩 벤치마크는 계속 중요하겠지만, 그 점수만으로 '일 잘하는 에이전트'를 뽑는 시대는 지나가고 있습니다. 결국 92%의 일을 평가하지 않으면, 92%의 현장에서는 AI가 어딘가 어설퍼 보일 테니까요.
참고
1AI agent benchmarks obsess over coding while ignoring 92% of the US labor market, study finds
2SEAL LLM Leaderboards: Expert-Driven Evaluations | Scale | SEAL by Scale AI
3Evaluating AI agents: Real-world lessons from building agentic systems at Amazon
4OpenAgentSafety: A Comprehensive Framework for Evaluating Real-World AI Agent Safety
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.