당신의 에이전트는 정말 좋아졌나요, 아니면 「그렇게 느껴질」 뿐인가요?
마지막 업데이트
좋은 에이전트 평가는 「이번 주 에이전트가 더 나빠진 것 같다」는 모호한 느낌을 팀이 실제로 행동할 수 있는 숫자로 바꿔줍니다. Anthropic 엔지니어링 팀이 쓴 《Demystifying evals for AI agents》는 Claude Code 같은 제품을 출시하면서 얻은 교훈을 압축해 담은 좋은 글입니다. 이 글에서는 읽고 나서 깊이 와닿았던 몇 가지를 공유합니다.
에이전트 평가는 왜 생각보다 어려운가
싱글 턴 LLM 평가는 깔끔합니다（프롬프트를 넣고, 응답을 받고, 평가자가 채점합니다）. 에이전트는 그 단순함을 완전히 무너뜨립니다. 여러 턴에 걸쳐 도구를 사용하고, 환경 상태를 바꾸며, 중간 결과에 따라 전략을 조정하기 때문에 실수가 전파되고 부작용이 누적됩니다. 궤적이 못생겨 보여도 최종 결과가 완벽할 수 있고 그 반대도 가능합니다.
Memex 자체의 지식베이스 에이전트를 예로 들어보죠. 무언가를 기록하면, 에이전트는 LS, Grep, Read, Edit, Write 같은 도구와 상위 수준의 「인사이트 업데이트」, 「정리 건너뛰기」 등의 행동으로 여러 턴에 걸쳐 파일 시스템을 만집니다. 어떤 결과는 객관적으로 검증 가능합니다（파일이 제대로 쓰였는가? 링크가 살아 있는가?）. 어떤 결과는 본질적으로 주관적입니다（이 슬라이스가 맞는가? 이 인사이트는 보여줄 가치가 있는가?）.
에이전트 평가가 어려운 이유
Memex 지식베이스 에이전트를 예시로
fact_id 링크는 유지되는가?구조는 P.A.R.A.를 따르는가?
분류가 합리적인가?
분할 단위가 맞는가?
에이전트는 다양한 도구를 갖추고 멀티 턴으로 호출하며, 상태를 바꾸고 변화에 따라 전략을 조정합니다. 최종 산출물은 객관적으로 검증 가능한 부분과주관적으로만 판단 가능한 부분을 모두 포함하며, 평가는 양쪽을 모두 다뤄야 합니다.
평가 프레임워크의 용어
Anthropic의 글은 이후 논의를 다루기 쉽게 만드는 작지만 정확한 용어를 정의합니다.
- 태스크（Task）：입력과 성공 기준이 명확한 단일 테스트 케이스.
- 시도（Trial）：하나의 태스크에 대한 단일 시도. 출력이 흔들리므로 여러 번 실행합니다.
- 평가자（Grader）：출력의 어떤 측면에 점수를 매기는 로직. 한 태스크에 여러 개 가능.
- 트랜스크립트（Transcript）：시도의 완전한 기록. 추론과 도구 호출 포함.
- 결과（Outcome）：시도 종료 시 환경의 최종 상태.
- 평가 하네스（Eval harness）：시도를 편성하고 단계를 기록하며 결과를 집계하는 러너.
- 평가 스위트（Eval suite）：어떤 능력이나 행동을 측정하는 관련 태스크의 모음.
Anthropic의 평가 프레임워크
harness, suite, task, grader, metric, trial 의 계층 관계
평가 하네스는 실행 환경을 제공하고 에이전트를 정의하며 스위트를 배포하고 태스크를 병렬 실행하며 모든 단계를 기록하고 평가자를 적용해 결과를 집계합니다.
세 가지 에이전트 평가자 유형
유용한 평가 설계는 보통 세 가지 평가자를 결합하며, 태스크의 각 측면에 가장 적합한 도구를 선택합니다.
코드 기반 평가자
문자열 매칭, 유사도 계산, 도구 호출 검증, 단위 테스트 통과/실패 등으로 결과를 채점합니다. 평가자 자체가 결정적인 코드라서 빠르고, 저렴하며, 객관적이고, 재현 가능하며, 디버그가 쉽습니다. 유효한 변형에 취약하고 주관적 품질에 약하므로 기계적으로 검증할 수 있는 출력에만 사용합니다.
모델 기반 평가자（LLM-as-judge）
LLM-as-judge가 자연어로 작성된 루브릭을 적용합니다. 참조 답안이나 다중 평가단을 추가하면 신뢰도를 높일 수 있습니다. 단, 확률적인 평가자로 확률적인 에이전트를 채점하는 셈이라 신뢰성을 유지하려면 사람 평가와의 보정이 필수입니다.
사람 기반 평가자
SME 검토, 크라우드 판단, A/B 테스트, 평가자 간 일치도. 느리고 비싸지만 모호한 품질의 골드 스탠다드입니다. 주된 역할은 모델 기반 평가자의 보정과, 자동 채점이 흔들리는 주관적 경계의 해결입니다.
에이전트를 어떻게 평가하나요?
에이전트 평가는 보통 세 가지 평가 방식을 결합합니다
비결정성: pass@k vs pass^k
에이전트 행동은 실행마다 변동합니다. 어제 통과한 태스크가 오늘은 실패할 수 있습니다. 원문은 이를 다루기 위한 두 개의 보완적 지표를 제시합니다.
pass@k: k 번 중 최소 1 회 성공
pass@k는 k회 시도 중 적어도 한 번 성공할 확률입니다.k가 커지면 상승합니다. 더 많이 시도할수록 「최소 한 번 성공」할 가능성이 높아지고, 보통 pass@1이 첫 시도 성공에 대해 신경 쓰는 값입니다（최종 사용자는 거의 재시도하지 않으므로）.
pass^k: k 번 모두 성공
pass^k는 k회 시도 모두 성공할 확률입니다.k가 커지면 하강합니다. 더 많은 시도에서 일관성을 요구할수록 기준이 높아집니다. 「매번 잘 작동해야」 하는 사용자 대상 에이전트는 이 숫자에 사활이 걸립니다.
에이전트 평가에서 비결정성 포착하기
Anthropic은 두 개의 보완적인 지표를 권장합니다
몇 번 시도해야 적어도 한 번 성공하는가. pass@1이 100%에 가깝기를 원합니다. 첫 시도에 완료되는 것이 이상적입니다.
연속 k회 모두 성공할 수 있는가. 허용 가능한 k가 클수록 에이전트가 프로덕션에서 안정적으로 작동함을 의미합니다.
k=1에서 두 곡선은 동일합니다（둘 다 회당 성공률）.k=10에 이르면 정반대 이야기를 합니다.pass@k는 100%에 가까워지고 pass^k는 0%에 가까워집니다. 어느 쪽을 쓸지는 만족시켜야 할 사용자 기대에 달려 있습니다.
처음부터 평가를 만드는 권장 사항
원문 후반부는 실용적인 조언으로 가득합니다. 여기서는 우리가 자주 다시 들춰보는 핵심을 요약합니다.
Anthropic의 평가 권장 사항
왜 / 언제 / 어떻게
효과적인 평가는 팀이 자신감을 가지고 에이전트를 출시할 수 있게 합니다. 프롬프트를 바꾸든, 런타임을 바꾸든, 모델을 업그레이드하든 평가는 「에이전트가 정말 좋아졌는가?」라는 핵심 질문에 답합니다.
에이전트 개발의 모든 단계에서 평가는 유용합니다. 초기에는 성공 기준을 명확히 하게 만들고, 후기에는 품질 드리프트를 막아줍니다. 빨리 시작할수록 구축 비용이 낮아집니다.
여러 평가자를 의도적으로 결합하고, 점수가 어떻게 합쳐지는지 결정하세요: 가중? 전부 통과? 하이브리드?
실제 실패 사례에서 가져온 20–50개의 단순한 태스크로 시작하세요. 적은 샘플도 초기 반복에 큰 가치를 줍니다（80/20 규칙）.
두 명의 도메인 전문가가 같은 판정을 내릴 만큼 명확한 태스크를 작성하세요.0% pass@100은 무능한 에이전트가 아닌, 망가진 태스크의 신호입니다.
해야 함과 하지 말아야 함 양쪽을 모두 다루어 한쪽 최적화를 피하세요.
평가 환경을 격리하세요. 공유 상태, 남은 파일, 자원 부족은 시도의 독립성을 망칩니다.
평가 스위트를 살아있는 산출물로 다루세요. 트랜스크립트를 읽고, 안정된 능력 태스크는 회귀 스위트로 「졸업」시키며, 점수가 의외라면 평가자를 다시 살펴보세요.
도메인 전문가와 프로덕트 팀에게 기여를 개방하세요. 그들이 사용자와 요구사항에 가장 가깝습니다.
원문은 Harbor, Braintrust, LangSmith,Arize, Langfuse 같은 평가 프레임워크도 언급합니다. Memex의 에이전트 하네스에서 더 사용해본 뒤 경험을 공유하겠습니다.
에이전트 평가가 Memex에 의미하는 바
Memex는 당신의 휴대폰에서 멀티 에이전트 시스템 전체를 실행합니다. Card Agent, PKM Agent, Comment Agent, Insight Agent, 그리고 당신이 직접 만드는 커스텀 에이전트. 각 에이전트는 자율적이고, 도구를 사용하며, 지식베이스의 상태를 변경합니다. Anthropic의 어휘는 우리가 품질을 생각하는 방식과 깔끔하게 매핑됩니다. 기록 종류별로 태스크를 정의하고, 검증 가능한 결과와 판단할 수밖에 없는 출력에 평가자를 섞으며, 사용자가 매일 보는 경험에 pass^k 스타일의 신뢰성 목표를 둡니다.
평가는 「더 나은」이 무엇을 의미하는지에 대해 우리 자신과 나누는 대화입니다. 그 대화를 일찍 시작할수록 에이전트는 슬롯머신보다, 매 릴리스마다 더 나아지는 동료처럼 느껴집니다.
전체 원문은 Anthropic 엔지니어링 블로그에서 확인하세요. Memex의 구현이 궁금하다면 소스 코드가 공개되어 있고 휴대폰에서 AI 에이전트를 실행하는 데 실제로 필요한 것글이 에이전트 아키텍처를 더 깊이 다룹니다.
FAQ: AI 에이전트 평가 자주 묻는 질문
AI 에이전트 평가란 무엇인가요?
에이전트 평가는 AI 에이전트에 대한 프로그램적 테스트입니다. 입력 태스크를 주고, 자체 도구로 실행하게 한 뒤, 트랜스크립트와 최종 상태에 대해 평가자가 점수를 매깁니다. 단일 턴 LLM 테스트와 달리 에이전트 평가는 다단계 도구 사용, 상태 변화, 부분 점수를 다뤄야 합니다.
pass@k 와 pass^k 의 차이는 무엇인가요?
pass@k는 k번 시도 중 적어도 한 번 성공할 확률로 k가 클수록 높아지고, pass^k는 k번 모두 성공할 확률로 k가 클수록 낮아집니다. pass@1은 첫 시도 성공률 지표로, pass^k는 「매번 잘 작동해야」 하는 사용자 대상 에이전트의 신뢰성 지표로 쓰입니다.
코드/모델/사람 평가자, 어떤 것을 써야 하나요?
셋 다 차원별로 적합하게 사용하세요. 코드로 결정적으로 검증할 수 있는 결과에는 코드 평가자, 자유 형식 출력과 톤에는 모델 평가자(LLM-as-judge), 모델 평가자 보정과 주관적 경계 해결에는 사람 평가자를 사용합니다. Anthropic은 하나만 고르지 말고 조합하라고 권장합니다.
에이전트 평가 스위트는 몇 개 태스크부터 시작하나요?
실제 실패 사례에서 가져온 20–50개면 시작하기 충분합니다. Anthropic은 80/20 법칙을 강조합니다. 잘 고른 소수의 태스크가 초기 반복에서 가장 큰 가치를 줍니다. 에이전트가 성숙하면 확장하고, 안정된 태스크는 회귀 스위트로 「졸업」시키세요.
왜 pass@100 = 0% 가 보통 망가진 태스크의 신호인가요?
프런티어 모델이 100번 시도해도 못 푼다면, 가장 가능성 높은 원인은 태스크가 모호하거나, 평가자가 너무 엄격하거나, 하네스가 유효한 해법을 막고 있다는 것입니다. Anthropic은 모델 능력을 의심하기 전에 태스크 명세와 평가자를 먼저 점검하라고 권장합니다.