AI 에이전트는 정답만 맞으면 될까. 에이전트 평가가 모델 평가보다 어려운 이유와 인디 빌더가 봐야 할 신호 3 가지

📅 2026.08.02 | ✍️ 경제 흐름을 읽어주는 형

오늘 아침 형이 챙긴 글은 한 개발자가 직접 겪은 이야기야. 이 사람은 AgentEval Forge라는 걸 만들고 있어. AI 에이전트가 일을 제대로 하는지 채점해 주는 오픈소스 시험대야. 처음엔 예전에 모델 성능 채점해 본 경험이 있으니 이번 것도 그 연장이겠거니 했대. 그런데 만들면 만들수록 그 생각이 틀렸다는 걸 깨달았다는 거야. 형이 이 글을 고른 이유는 여기 담긴 한 문장 때문이야. 모델을 평가할 땐 답이 좋은지만 물으면 되는데, 에이전트를 평가할 땐 이 시스템을 믿고 맡겨도 되는지를 물어야 한다는 거지. 얼핏 비슷해 보여도 이 둘은 완전히 다른 질문이야. 이 개발자가 만드는 시험대만 봐도 그래. 상황별 시나리오 묶음, 일부러 골탕 먹이는 함정 사례, 에이전트가 밟아 간 경로 채점, 판을 새로 짤 때마다 나빠진 곳을 되짚는 회귀 추적까지 다 담으려고 하거든. 답 하나 채점하는 것과는 무게가 다른 일이야.

왜 다른지 짚어 볼게. 모델은 입력을 넣으면 답 하나를 뱉어. 그 답이 좋은지만 보면 돼. 그런데 에이전트는 답 하나로 끝나지 않아. 도구를 고르고, 실패하면 다시 시도하고, 중간에 상태를 기억하고, 비용을 쓰고, 위험한 행동을 할지 말지 매 순간 정해. 다시 말해 답이 아니라 일하는 과정 전체가 평가 대상이 되는 거야. 이 개발자가 계속 되뇌는 문장이 바로 그거야. 과정이 중요하다. 에이전트가 마지막에 그럴듯한 답을 내놨어도 거기까지 오는 길이 엉망이었을 수 있거든. 처음에 엉뚱한 도구를 골랐다가 운 좋게 수습했거나, 쓸데없이 같은 일을 반복했거나, 더 나은 길이라면 다섯 배는 적게 썼을 비용을 태웠거나 말이야. 결과만 보면 성공으로 채점하지만 실제론 사고였던 셈이지. 그럼 여기서 인디 빌더가 건질 신호를 세 갈래로 풀어보자.

【 핵심 체크포인트 】

1. 정답만 보면 속는다.

에이전트가 마지막에 내놓은 답이 맞았다고 그 판을 통째로 잘한 걸로 치면 위험해. 엉뚱한 도구를 먼저 쥐었다가 늦게 겨우 수습했는데도 최종 답만 보면 성공으로 잡히거든. 형이 여기서 읽는 신호는 이래. 인디 빌더가 자기 에이전트를 점검할 땐 결과 하나만 볼 게 아니라 거기까지 어떻게 갔는지를 같이 봐야 해. 운으로 맞은 건지, 안전한 길로 맞은 건지는 완전히 다른 얘기야. 겉으로 드러난 답 뒤에 숨은 과정을 들여다보는 습관이 곧 실력이 돼.

2. 에이전트 평가는 채점이 아니라 릴리스 규율에 가깝다.

이 개발자는 에이전트를 제대로 보려면 다섯 가지를 다 챙겨야 한다고 정리했어. 첫째 답이 맞았는지, 둘째 거기까지 온 과정이 알뜰하고 안정적이었는지, 셋째 도구를 옳게 골랐는지, 넷째 넘지 말아야 할 선을 지켰는지, 다섯째 비용과 속도가 감당할 만했는지야. 형이 인디 빌더한테 하고 싶은 말은 이래. 이건 시험 점수 매기기가 아니라 이 버전을 정말 세상에 내보내도 되는지를 따지는 출시 점검에 가까워. 점수 한 줄이 올랐다고 좋아할 게 아니라, 뭐가 나아졌고 뭐가 나빠졌고 뭐가 더 비싸지고 뭐가 더 위험해졌는지를 같이 봐야 해.

3. 진짜 실패는 깔끔한 데모가 아니라 현실 데이터에서 드러난다.

이 사람이 예전 작업에서 배운 게 있어. 잘 정돈된 예제로 돌릴 땐 멀쩡하던 시스템이 진짜 저장소, 진짜 기록, 진짜 뒤죽박죽 이름 앞에선 갑자기 흔들리더라는 거야. 도구를 잘못 쓰는 순간도, 넘지 말아야 할 선을 넘는 순간도 다 거기서 나와. 기술적으로 맞는 답과 실제로 내보내도 되는 답이 슬금슬금 벌어지는 지점이지. 형이 여기서 읽는 신호는 이래. 자기 에이전트를 매끈한 예시로만 시험하면 진짜 약점을 못 봐. 지저분하고 애매한 실제 상황에 밀어 넣어 봐야 어디서 무너지는지가 보여.

【 형 빌드 cross-reference 】

이번 글은 형이 붙잡고 있는 것들이랑 곧바로 맞물려.

첫째는 MINDCHANGE 하네스야. AI가 내놓은 결과를 스스로 다시 검사하게 만드는 자가검증 장치인데, 오늘 두 번째 신호와 정확히 맞닿아. 에이전트를 볼 때 과정이 알뜰하고 안정적이었는지 챙기라는 말이 곧 이 하네스가 하는 일이거든. 한 걸음마다 이게 원래 시킨 일이 맞는지 스스로 되짚게 만들면, 마지막 답이 우연히 맞아떨어진 건지 제대로 된 길로 온 건지가 갈려. 결과 한 줄 뒤의 과정을 붙드는 도구라는 점에서 오늘 이야기와 그대로 겹쳐.

둘째는 num_ctx 하네스야. 언어 모델이 긴 입력을 조용히 잘라먹고도 멀쩡한 척 답하는 순간을 잡아내는 검증 도구인데, 세 번째 신호와 이어져. 에이전트를 여러 단계로 돌리면 눈에 안 보이는 곳에서 조용히 어긋나는 지점이 늘어나. 겉으로는 다 처리한 척하는데 속으로는 절반만 본 상황 말이야. 매끈한 예제에선 안 보이다가 진짜 데이터 앞에서 터지는 게 바로 이런 숨은 실패야. 그 조용한 어긋남을 미리 잡아내는 장치라 오늘 글과 정면으로 이어져.

셋째는 agent-starter-kit이야. 텔레그램에서 AI 에이전트를 붙여 돌리는 키트인데, 오늘 이야기의 넷째 다섯째 잣대와 맞물려. 에이전트한테 어떤 도구를 쥐여 주고 어디까지 권한을 줄지, 사고가 나면 어떻게 끌지를 처음부터 갖춰 두는 게 이 키트의 핵심이거든. 오늘 글이 말한 도구 선택과 안전선 지키기를 실제로 붙여 돌릴 때 챙겨야 할 대목이 바로 그거야. 평가로 알아챈 약점을 키트 쪽 설계에 곧바로 되먹일 수 있어.

【 결론 】

오늘 글을 한 문장으로 줄이면 이래. 모델은 답이 좋은지만 물으면 되지만 에이전트는 그 시스템을 믿고 맡겨도 되는지를 물어야 하고, 그 답은 결과가 아니라 거기까지 온 과정 전체에 숨어 있어. 오늘 점검할 질문은 셋이야. 내 에이전트가 우연이 아니라 안전한 길로 답을 맞혔는지, 점수 한 줄 말고 비용과 위험까지 같이 살폈는지, 그리고 매끈한 예시가 아니라 진짜 지저분한 데이터로 시험해 봤는지야. 스스로 움직이는 능력은 이미 AI가 가져갔어. 이제는 그 움직임의 과정을 끝까지 되짚고 검증하는 사람이 이겨.

출처 = Why Agent Evaluation Is Harder Than Model Evaluation (dev.to, Debashish Ghosal, 2026.08.01)

이 글은 2026년 8월 2일 뉴스와 데이터를 기반으로 AI 도구를 활용해 재작성했어.