Anthropic: Demystifying evals for AI agents

 

들어가며

AI 에이전트를 개발하고 있다면 누구나 공감할 고민이 있습니다. "이게 정말 개선 된 게 맞나?"

 

단순한 챗봇을 넘어 도구를 사용하고 복잡한 작업을 수행하는 '에이전트'는 그 자율성 때문에 평가하기가 매우 까다롭습니다.

 

최근 Claude를 만든 Anthropic 팀이 자신들의 경험과 고객사(Descript, Notion 등)의 사례를 바탕으로 AI 에이전트 평가(Evaluation) 방법론을 상세히 공개했습니다.

 

이번 글은 그 내용을 바탕으로 Anthropic이 제시한 AI 에이전트 평가 방식이 어떤 고민에서 출발했고, 어떤 접근들을 사용하고 있는지 가볍게 정리해보려 합니다.

 

 

 

 

AI 에이전트 평가, 생각보다 까다로운 이유

요즘 AI 에이전트(Agent)가 여기 저기서 주목받고있습니다. 자율성도 있고, 지능적이고, 유연하기까지 하니까 여러가지 잠재성을 가지고 있으니까요.

 

그런데 아이러니하게도, 에이전트를 유용하게 만드는 바로 그 능력들 때문에 평가하는 건 은근히 골치 아픈 일이 되어버렸습니다.

 

단순히 “정답을 맞췄냐”로 판단할 수 없는 , 왜 에이전트 평가가 유독 까다로운지 하나씩 살펴보겠습니다.

 

 

1. 스노우볼 효과: 다중 턴(Multi-turn)과 오류 누적

출처 : Anthropic blog

 

에이전트는 챗봇처럼 한 번 대답하고 끝나는 게 아닙니다. 도구도 호출하고, 상태도 바꾸고, 결과 보면서 전략도 수정하고... 꽤 긴 호흡(Multi-turn)으로 움직입니다.

 

문제는 여기서 생깁니다. 초반에 아주 작은 실수를 하나 했다고 쳐보면, 단일 턴이라면 그냥 틀리고 말겠지만, 에이전트는 그 실수를 기반으로 다음 행동을 하게됩니다.

 

뒤로 갈수록 오류가 눈덩이처럼 불어나서(Compound), 결국 프로젝트 전체가 엉망이 될 수도 있습니다. 어디서부터 꼬였는지 찾기도 쉽지않게 됩니다.

 

 

2. 너무 창의적이라서 문제.

최신 모델들은 가끔 우리가 정해둔 평가 기준을 뛰어넘을 정도로 창의적일 때가 있습니다.

 

가상의 시나리오:

에이전트에게 비행기 항공권 예약을 시켰더니, 정책상 허점을 기가 막히게 찾아내서 사용자한테 훨씬 싼 티켓을 구해줬습니다.

 

사용자 입장에선 매우 좋은 결과이지만,

 

미리 작성해둔 정적인 평가 스크립트 입장에서는 "정해진 절차 위반"으로 실패 처리될 수도 있습니다. 더 나은 결과를 가져왔는데 점수는 깎이는, 좀 억울한 상황이 생길 수 있습니다.

 

 

3. 실행할 때마다 달라요 (비결정성)

같은 질문을 던져도 에이전트의 행동은 매번 조금씩 다를 수 있습니다. 이게 사실 에이전트의 매력이기도 한데, 평가자 입장에선 곤란합니다.

 

한 번 성공했다고 해서 "오, 완벽해!"라고 단정 짓긴 좀 어렵거든요. 진짜 실력인지 운인지 알려면 여러 번 돌려봐야(Trials) 하는데, 이러면 돈도 시간도 생각보다 많이 소요됩니다.

 

 

4. "말"보다 "결과"가 중요하니까

에이전트 평가는 텍스트만 비교하는 거랑은 차원이 좀 다릅니다. 최종 상태(Outcome)가 진짜 바뀌었는지를 봐야 하니까요.

 

• 에이전트: "항공권 예약 완료했습니다!" (출력)
• 실제 확인: 데이터베이스에 진짜 내 이름으로 예약이 들어갔나? (결과)

 

말만 번지르르하게 하고 실제론 DB에 아무것도 없다면 꽝이잖아요. 그래서 텍스트 매칭을 넘어, 실제 환경 변화까지 추적할 수 있는 복잡한 인프라가 필요해집니다.

 

 

5. 정답이 딱히 없을 때 (모호성과 주관성)

사람도 그렇지만, 에이전트도 지시가 애매하면 곤란해집니다. 시키는 사람이 대충 말해놓고 "왜 내 의도대로 안 했어?"라고 하면 에이전트 입장에선 할 말이 없게됩니다.

 

또, 글쓰기 에이전트 같은 경우 '적절한 톤앤매너'나 '포괄적인 내용' 같은 기준은 사람마다, 또 상황마다 다르잖아요. 전문가들끼리도 의견이 갈릴 수 있는 부분이라 점수 매기기가 참 모호합니다.

 

 

---

 

 

요약하자면 AI 에이전트 평가는 '객관식 시험 채점'이라기보다는, 장기 프로젝트를 맡은 직원의 '인사 고과'를 매기는 것과 비슷합니다.

 

단순한 채점표보다는 훨씬 정교한 설계와 도구가 필요하고, 이 부분이 해결되어야 에이전트를 실무에 더 과감하게 도입할 수 있지 않을까 싶습니다.

 

 

 

 

에이전트 평가의 3가지 핵심 요소 (Anatomy of an Eval)

에이전트 평가 시스템이 제대로 돌아가려면 크게 세 가지 핵심 요소가 필요합니다. 작업(Task), 기록과 결과(Transcript & Outcome), 채점기(Grader)입니다.

 

 

1. 작업 (Task): 문제 정의가 반이다

평가의 시작점입니다. 에이전트에게 던져주는 '하나의 테스트 케이스'라고 보시면 됩니다.

• 단순 질문 그 이상: Agent를 평가하는 것은 단순히 질문을 하나 던지는 일에 그치지 않습니다. 예를 들어 코딩 에이전트라면, 사용할 도구와 서버 구축 같은 구체적인 과제를 준비해야 하고, 나아가 에이전트가 활동할 환경까지 함께 구성해줘야 합니다.
• 객관적인 명확성: 좋은 작업(Task)의 조건은 '명확성'입니다. 전문가 두 명에게 보여줬을 때, 둘 다 똑같이 "이건 성공이네", "이건 실패네"라고 판정할 수 있어야 합니다. 기준이 흔들리면 평가도 흔들리니까요.

 

2. 기록과 결과 (Transcript & Outcome): 말과 행동은 다르다

에이전트가 문제를 풀고 난 뒤 남긴 흔적들입니다. 여기서 중요한 건 '과정'과 '최종 상태'를 구분해서 봐야 한다는 점입니다.

• 트랜스크립트 (Transcript): 에이전트의 사고 과정, 도구 호출 로그 등 '어떻게' 풀었는지 보여주는 전체 기록입니다. 디버깅할 때 아주 중요하겠죠.
• 결과 (Outcome): 이게 핵심입니다. 에이전트가 뱉은 말(Output)이 아니라, 실제 환경이 어떻게 변했냐는 겁니다.
  • Output: "예약 완료했습니다!" (답변만 예약했다고 했을 수도 있음)
  • Outcome: 실제 DB에 예약 데이터가 생성됨 (진짜 수행한 결과)

말만 번지르르하게 하고 실제 일 처리는 안 됐을 수도 있으니, 우리는 'Outcome'을 더 유심히 볼 필요가 있습니다.

 

 

3. 채점기 (Grader): 점수는 누가 매길까?

이제 결과를 놓고 점수를 매겨야겠죠. 보통 세 가지 방식을 상황에 맞춰 섞어서 씁니다.

 

1. 코드 기반 (Code-based): 문자열이 일치하는지, 유닛 테스트가 통과했는지 봅니다. 빠르고 객관적이지만, 융통성은 좀 떨어집니다.

 

2. 모델 기반 (Model-based): LLM을 심판(Judge)으로 앉히는 방식입니다. "이 답변이 친절한가?" 같은 뉘앙스를 파악하는 데엔 좋지만, 심판도 AI라 가끔 오락가락할 때가 있습니다.

 

3. 인간 채점기 (Human): 결국 사람이 보는 게 가장 정확하겠죠(Gold Standard). 하지만 역시나 비용이 만만치 않고 속도가 느리다는 게 흠입니다. 보통은 모델 채점기를 교정할 때 참고용으로 씁니다.

 

 

 

 

Anthropic이 제안하는 에이전트 평가 방식

핵심은 간단합니다. 객관적인 건 코드로, 주관적인 건 LLM으로, 기준점은 사람이 잡자는 것입니다.

 

 

1. 세 가지 채점 도구의 장단점

Anthropic은 완벽한 하나의 도구는 없다고 봅니다. 대신 이 세 가지를 적절히 조합해서 쓰라고 조언합니다.

 

💻 코드 기반 (Code-based)

• 특징: 문자열 일치, 유닛 테스트 등.
• 장점: 빠르고, 싸고, 결과가 언제나 똑같습니다(객관적).
• 단점: 융통성이 제로입니다. 정답과 조금만 달라도 틀렸다고 할 수 있습니다.

 

🤖 모델 기반 (Model-based)

• 특징: LLM을 심판(Judge)으로 활용합니다.
• 장점: "친절한가?", "유용한가?" 같은 뉘앙스를 잘 파악합니다.
• 단점: 실행할 때마다 점수가 달라질 수 있고(비결정성), 가끔 엉뚱한 판단을 합니다.

 

👩‍💻 인간 채점 (Human)

• 특징: 전문가가 직접 봅니다.
• 장점: 가장 정확합니다(Gold Standard).
• 단점: 너무 비싸고 느립니다. 주로 모델 채점기를 교육(교정)하는 용도로 씁니다.

 

 

2. 실전 채점 전략 4가지

도구가 준비되었다면, 이제 어떻게 써야 할까요? Anthropic은 꽤 구체적인 가이드라인을 제안합니다.

 

 

① '확실한 것'부터 채점 (Code First)

모든 걸 LLM에게 물어볼 필요는 없습니다. 객관적으로 검증 가능한 부분은 무조건 코드 기반 채점기를 우선하는 게 좋습니다. 비용도 아끼고 신뢰도도 높일 수 있으니까요. 유연성이 꼭 필요한 부분에만 LLM을 투입하세요.

 

 

② 과정보다는 '결과(Outcome)'를

에이전트가 도구를 A → B 순서로 썼든, B → A 순서로 썼든 그건 중요하지 않을 수 있습니다.

에이전트가 창의적인 방법으로 문제를 해결했는데, "정해진 경로(Path)로 안 갔어!"라고 감점하면 억울하겠죠. 최종 결과물이 제대로 나왔는지를 보는 게 핵심입니다.

 

 

③ 0점 아니면 100점? 부분 점수를 주세요

복잡한 작업은 모 아니면 도로 평가하기 어렵습니다. 5단계 중 4단계를 성공했다면 그만큼의 진척도(Partial credit)를 인정해 줘야 합니다. 그래야 모델 성능이 개선되고 있는지 세밀하게 파악할 수 있습니다.

 

 

④ 평가 모델을 학습하세요

모델 기반 채점기를 그냥 믿으면 안 됩니다.

• 사람과 비교: 전문가의 판단과 LLM의 판단이 일치하는지 계속 맞춰봐야(Calibration) 합니다.
• 명확한 채점 기준: "잘 평가해 줘" 대신, 구체적인 채점 기준표를 줘야 합니다.
• 모르면 모른다고 하기: LLM이 판단 근거가 부족하면 억지로 채점하지 말고 "Unknown"을 뱉을 수 있는 탈출구를 마련해 주세요.

 

 

 

3. 상황별 맞춤 전략

수행하는 작업의 특성에 맞춰 채점 방식의 비중을 적절히 조절해야 합니다.

• 코딩 에이전트: 코드가 실제로 돌아가는지가 중요하죠. 유닛 테스트(결정론적 채점)가 메인입니다.
• 대화형 에이전트: 문제 해결도 중요하지만, 말투나 톤도 중요합니다. 잘 튜닝된 LLM 채점기의 역할이 큽니다.

 

 

 

 

"한 번 성공" vs "항상 성공": 핵심 지표 이해하기/pass@k vs pass^k

에이전트를 평가할 때 우리는 스스로에게 두 가지 질문을 던질 수 있습니다.

"한 번이라도 성공할 수 있나?" 아니면 "언제나 성공할 수 있나?"

이 질문에 대한 답이 바로 이 두 지표입니다.

 

 

1. pass@k: "한 번만 걸려라" (가능성)

이 지표는 에이전트의 잠재력(성공 가능성)을 측정합니다.

 

• 의미: k번 시도했을 때, 적어도 한 번 이상 정답을 맞힐 확률입니다.
• 특징: 시도 횟수(k)를 늘릴수록 점수는 올라갑니다.
  • 마치 골대 앞에서 슛을 10번 쏘게 해주는 것과 같습니다. 기회가 많으니 한 골이라도 넣을 확률(pass@10)은 거의 100%에 가까워지겠죠.
• 어디에 쓸까?: 코딩 에이전트나 아이디어 생성 도구처럼, 수많은 시도 중 '딱 하나의 정답'만 건지면 되는 경우에 유용합니다.

 

 

2. pass^k: "실수는 용납 못 해" (신뢰성)

반면, 이 지표는 에이전트의 일관성(Consistency)을 가혹하게 검증합니다.

 

• 의미: k번 시도했을 때, 모든 시도가 전부 성공할 확률입니다.
• 특징: 시도 횟수(k)가 늘어날수록 점수는 가파르게 떨어집니다.
  • 한 번 성공할 확률이 75%라도, 3번 연속으로 성공해야 한다면 확률은 42%로 뚝 떨어집니다. 조건이 훨씬 까다로워지는 거죠.
• 어디에 쓸까?: 고객 응대 에이전트처럼, 100번 질문해도 100번 다 친절하고 정확해야 하는 서비스에 필수적입니다.

 

 

🧐 한눈에 비교하기

출처 : Anthropic blog

결국 k=1일 때(한 번 시도)는 두 값이 같지만, 횟수를 늘릴수록 둘의 방향은 정반대로 갈라집니다.

 

구분	pass@k	pass^k
핵심 질문	"한 번이라도 성공하는가?"	"매번 성공하는가?"
측정 가치	성공 가능성 (Capability)	신뢰성 & 일관성 (Reliability)
k 증가 시	점수 상승 📈	점수 하락 📉
추천 분야	코딩, R&D (정답 발견이 중요)	고객 서비스 (안정성이 중요)

 

결국 "우리 에이전트 성능이 좋다"라고 말할 때, 그게 가끔 대박을 터뜨린다는 건지, 아니면 언제나 믿음직하다는 건지명확히 할 필요가 있어 보입니다.

 

 

 

 

앤스로픽이 제안하는 "평가 시스템 구축 8단계 로드맵"

출처: Anthropic 블로그

AI 에이전트를 개발하다 보면 성능을 평가하긴 해야 하는데, 어디서부터 손을 대야 할지 감이 잘 안 잡히기도 합니다.

Anthropic은 글에서 에이전트 개발 시 신뢰할 수 있는 평가 시스템을 만들기 위한 8단계 로드맵을 제안했습니다.

 

 

🛠️ 초기 평가 데이터셋, 어떻게 모을까?

 

0단계. 일단 일찍 시작하고 보기

 

많은 팀이 "수백 개의 데이터는 있어야 평가를 시작하지 않겠어?"라며 미루곤 하는데요. 사실 처음엔 20~50개 정도의 단순한 실패 사례만 있어도 충분합니다.

초기에는 시스템을 조금만 바꿔도 영향이 크게 나타나거든요. 80/20 법칙처럼, 최소한의 노력으로 최대의 효과를 내는 게 중요합니다. 나중에 시스템이 복잡해진 뒤에 성공 기준을 역설계하려고 하면 생각보다 훨씬 고생할 수 있거든요.

 

 

1단계. 지금 손으로 하고 있는 것들부터

평소에 릴리스 전이나 개발 중에 수동으로 체크하던 작업들, 혹은 사용자가 자주 물어보는 케이스부터 시작해 보세요.

이미 서비스 중이라면 버그 리포트나 고객 지원 문의를 살펴보는 것도 방법입니다.

실제 실패 사례를 테스트 케이스로 만들면, 자연스럽게 사용자에게 가장 가치 있는 부분에 집중하게 됩니다.

 

 

2단계. 정답이 명확한 작업 만들기

좋은 작업의 기준은 의외로 간단합니다. 전문가 두 명이 봤을 때 합격/불합격 판정이 똑같이 나와야 해요. 전문가조차 통과하기 힘든 작업이라면 에이전트에게는 더 무리겠죠.

 

• 모호함 없애기: 지시사항에 없는 내용을 결과물에서 기대하면 안 됩니다. (예: 경로를 안 알려주고 특정 경로에 파일을 만들라고 하기)
• 참조 솔루션(정답) 준비: 정답 예시를 미리 만들어두면, 이게 에이전트가 못하는 건지 아니면 문제 자체가 잘못된 건지 금방 알 수 있습니다.

 

 

3단계. 균형 잡힌 문제 세트 구성

 

에이전트가 '해야 할 일'만 테스트하면, 나중에는 시키지도 않은 일까지 다 하려고 드는 부작용이 생길 수 있습니다.

 

• 검색이 필요한 쿼리: "오늘 날씨 어때?"
• 지식으로 답할 수 있는 쿼리: "Apple 창업자가 누구야?"

 

이런 식으로 상황에 맞게 행동하는지 균형 있게 섞어줘야 합니다. 편향된 평가는 결국 편향된 에이전트를 만들게 되니까요.

 

 

🏗️ 평가 환경과 평가자(Grader) 설계하기

 

4단계. 깨끗하고 독립적인 환경 구축

 

평가 환경이 들쭉날쭉하면 결과도 믿을 수 없겠죠. 각 테스트는 항상 아무것도 없는 깨끗한 상태에서 시작해야 합니다. 이전 테스트에서 남긴 파일이나 캐시 때문에 성공하거나 실패한다면, 그건 에이전트의 실력이 아니라 인프라 문제일 가능성이 높습니다.

 

 

5단계. 세심한 채점 기준 세우기

채점할 때는 가급적 규칙 기반(Deterministic) 방식을 먼저 고민해 보세요. LLM 평가자는 유연하긴 하지만 관리가 좀 까다롭거든요.

• 과정보다는 결과: 특정 도구를 순서대로 썼는지 따지기보다는, 최종 결과물이 맞는지를 보는 게 좋습니다. 에이전트가 우리가 생각지 못한 기발한 방법으로 정답을 찾을 수도 있으니까요.
• 부분 점수 활용: 아예 시작도 못한 에이전트와, 90%까지 하고 마지막에 삐끗한 에이전트는 다르게 대우해줘야 합니다.
• LLM 평가자 다듬기: LLM에게 채점을 맡길 땐 "모름" 옵션을 주고, 여러 항목을 한꺼번에 보게 하기보다는 하나씩 따로 평가하게 만드는 게 훨씬 정확합니다.

 

 

📈 장기적으로 유지하고 활용하기

 

 

6단계. 실행 기록(Transcript) 직접 보기

결과 점수만 보고 있으면 안 됩니다. 에이전트가 실제로 어떻게 움직였는지 기록을 직접 읽어봐야 해요. 그래야 에이전트가 진짜 바보짓을 한 건지, 아니면 평가자가 너무 까다로워서 정답을 오답 처리한 건지 알 수 있습니다. 점수가 안 오를 때 원인을 찾는 유일한 방법이기도 하고요.

 

 

7단계. '평가 포화' 상태 주의하기

어느 순간 모든 테스트를 100% 통과한다면, 이제 그 평가셋은 수명을 다한 겁니다. 성능 저하를 막는 용도로는 쓸 수 있겠지만, 더 나아지기 위한 지표는 못 되거든요. 이럴 땐 더 어렵고 복잡한 문제를 추가해서 기준치를 높여야 합니다.

 

 

8단계. 모두가 참여하는 평가 문화

평가체계는 한 번 만들고 끝나는 게 아니라 계속 살아 움직여야 합니다. 앤스로픽(Anthropic)에서는 전담 팀이 인프라를 관리하고, 실제 도메인 전문가나 PM들이 테스트 케이스를 직접 기여하는 방식이 가장 효과적이었다고 해요.

 

 

 

마치며: 에이전트 성능은 Eval에서 갈린다

결론적으로, 에이전트 개발의 핵심은 Eval 시스템입니다.

평가 없이 개발하면 개선인지 노이즈인지 구분하기 어렵고, 같은 문제를 반복해서 겪기 쉽습니다. 반대로 초반부터 Eval에 투자하면 실패 사례가 테스트 자산이 되고, 추측이 아닌 지표 기반으로 빠르게 개선할 수 있습니다.

 

특히 “요즘 성능이 별로인 것 같다” 같은 모호한 피드백을 구체적인 액션 아이템으로 바꿔준다는 점에서 Eval은 선택이 아닌 핵심 컴포넌트입니다. 완벽을 기다리기보다는 작게 시작하고, 실제 실패 로그를 기반으로 명확한 기준을 세우는 게 중요합니다. 지표만큼이나 로그를 직접 읽는 것도 여전히 강력한 방법이고요.

 

다만 기억할 점은, 완벽한 평가는 존재하지 않는다는 것입니다. 앤스로픽이 말하는 것처럼 평가는 ‘스위스 치즈 모델’에 가깝습니다.

자동화된 평가, 프로덕션 모니터링, 그리고 주기적인 인간 검토가 서로 겹쳐질 때 비로소 견고한 시스템이 됩니다.

 

지금 당장 할 수 있는 가장 쉬운 시작은, 실패한 로그 하나를 평가 데이터로 만드는 것입니다. 그 작은 한 걸음이 에이전트를 꾸준히 성장시키는 출발점이 됩니다.

 

REFERENCE

• https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

Demystifying evals for AI agents