학습 목표:
- '올바른 단계를 기록해 두고 하나씩 대조한다'가 에이전트를 반드시 오판하는 이유를 이해하고, 대신 종료 상태 평가로 갈아타기
- 복잡한 워크플로에서 모든 단계를 검증하는 대신 '기대한 상태 변화가 일어났다'를 확인하는 개별 검증 체크포인트 몇 개 짚어내기
- 흐릿한 요구사항을 측정 가능하고 달성 가능한 다차원 성공 기준으로 바꾸고, 궤적 단언을 어디까지 가져갈지 알기
전제: 레슨 1을 마쳤고, 실행할 수 있는 검사가 없으면 여러분 자신이 검증 루프가 된다는 것을 알고 있어야 합니다 | 이전: 레슨 1 << | 다음: 레슨 3 >>
여러분은 에이전트에 검증을 붙이기로 합니다. 첫 충동은 거의 모두 같습니다. '표준 절차'를 기록하는 것입니다. 작업을 손으로 한 번 통과시키며 모든 단계를 적어 둡니다 — 1단계는 search 를 호출해야 하고, 2단계는 fetch_page, 3단계는 write_note — 그리고 그것을 정답지로 저장합니다. 그다음부터는 에이전트가 실행할 때마다 호출 순서를 이 정답지와 한 단계씩 대조합니다. 하나라도 어긋나면 실패입니다.
세 번 돌립니다. 세 번 다 실패입니다.
출력을 확인해 봅니다. 요약문 세 편, 사실은 정확하고, 출처는 믿을 만하고, 요청한 관점도 전부 다뤘습니다. 다른 것은 경로뿐이었습니다. 첫 실행은 출처 세 개를 검색하고 그것으로 충분했고, 두 번째는 열 개를 검색했고, 세 번째는 검색에 앞서 용어 정의부터 찾아봤습니다. 이것이 바로 Anthropic이 자신들의 멀티 에이전트 리서치 시스템에서 관찰한 것입니다. 시작점이 동일해도 에이전트는 목표에 도달하기 위해 완전히 다르지만 유효한 경로를 택할 수 있고, 하나는 출처 세 개를 검색하고 다른 하나는 열 개를 검색하거나, 같은 답을 찾는 데 서로 다른 도구를 쓸 수도 있습니다1.
실패한 것은 에이전트가 아닙니다. 여러분의 검증 방법입니다.
전통적인 평가에는 깊이 묻혀 있는 기본 전제가 하나 있습니다. 입력 X가 주어지면 시스템은 경로 Y를 따라 출력 Z를 내놓아야 한다 — 매번 같은 단계로1. 이 전제는 결정론적 시스템에서 너무나 자연스럽게 성립해서, 대부분의 사람은 그것이 전제라는 사실조차 알아채지 못한 채 지냅니다. 에이전트는 그것을 단번에 뒤집습니다.
정말로 불편한 것은 '경로가 달라진다'만이 아닙니다. 다음 문장입니다.
"Because we don’t always know what the right steps are, we usually can't just check if agents followed the “correct” steps we prescribed in advance. Instead, we need flexible evaluation methods that judge whether agents achieved the right outcomes while also following a reasonable process."1
(올바른 단계가 무엇인지 늘 아는 것은 아니기 때문에, 미리 규정해 둔 '올바른' 단계를 에이전트가 따랐는지 확인하는 것만으로는 대개 충분하지 않습니다. 대신 에이전트가 합리적인 프로세스를 밟으면서 올바른 결과에 도달했는지를 판정하는, 유연한 평가 방법이 필요합니다)
'올바른 단계가 무엇인지 늘 아는 것은 아니다' — 이것이 핵심입니다. 여러분이 기록한 경로는 유일하게 올바른 경로가 아닙니다. 그것은 그때 마침 여러분이 지나간 경로일 뿐입니다. 그것을 정답지로 격상시켰기 때문에 다른 모든 방식이 오류가 되어 버린 것입니다.
후반부에도 주목하세요. '합리적인 프로세스를 밟으면서'. 이것은 프로세스를 완전히 무시하라는 뜻이 아닙니다. 하나의 고정된 경로를 잣대로 삼지 말라는 뜻입니다.
Anthropic의 접근은 직설적입니다. 턴별 분석이 아니라 종료 상태 평가에 집중하라 — 에이전트가 특정 프로세스를 따랐는지가 아니라 올바른 최종 상태에 도달했는지를 판정하라는 것입니다1. 이 접근은 에이전트가 같은 목표로 가는 다른 경로를 찾을 수 있음을 인정하면서도, 의도한 결과를 내놓는 것은 여전히 보장합니다1.
먼저 '종료 상태'를 쉬운 말로 정의합시다. 작업이 끝난 뒤 환경에서 관찰할 수 있고 사후에 검증할 수 있는 상태입니다. 파일 시스템에 어떤 파일이 생겼는지, 그 데이터베이스 레코드의 필드가 지금 어떤 값인지, 티켓에 어떤 라벨이 붙어 있는지, 돌아온 JSON에 status: "resolved" 가 있는지.
쓸 만한 리트머스 시험이 하나 있습니다. 종료 상태는 명사이지 동사가 아닙니다. 'rename_file 을 호출했다'는 동사이고, '모든 파일 이름이 특정 형식과 일치한다'는 명사입니다. 검증은 명사만 받습니다.
왼쪽 열은 에이전트가 개별 읽기 네 번 대신 일괄 읽기 한 번을 쓰는 순간, 결과가 동일해도 실패합니다. 오른쪽 열은 어떻게 읽는지 신경 쓰지 않습니다 — 'downloads/ 가 지금 어떤 모습인가'를 서술할 뿐, 어떻게 그렇게 됐는지와는 무관하기 때문입니다.
종료 상태 단언을 쓸 때 놓치기 쉬운 자리가 하나 있습니다. 바뀌지 말아야 할 것도 적어 두라는 것입니다. 위의 '파일 개수가 실행 전과 같다'가 그것입니다. 에이전트가 파일 두 개를 같은 이름으로 바꿔 두 번째가 첫 번째를 덮어써도, '모든 파일 이름이 유효하다' 검사는 멀쩡히 통과합니다. 종료 상태 단언은 '기대한 변화가 일어났다'와 '기대하지 않은 변화는 일어나지 않았다'를 둘 다 지켜야 합니다.
종료 상태 평가는 '프로세스를 완전히 무시한다'가 아닙니다. 출처의 바로 다음 문장이 빠져나갈 길을 줍니다. 복잡한 워크플로라면 모든 중간 단계를 검증하려 들지 말고, 특정 상태 변화가 일어났어야 하는 개별 체크포인트로 평가를 쪼개라는 것입니다1.
표현을 눈여겨보세요 — '특정 상태 변화가 일어났어야 한다', 여전히 상태이고 여전히 명사입니다. 관찰 지점을 '결승선'에서 '가는 길의 몇 지점'으로 옮겼을 뿐입니다.
용어 충돌 주의: 이 시리즈 9번째 코스에서 말하는 '체크포인트'는 컨텍스트 저장을 뜻합니다. 에이전트의 실행 중 상태를 디스크에 써 두어 크래시 후 거기서 재개할 수 있게 하는 것으로, 목적은 복구입니다. 이 레슨에서 말하는 '체크포인트'는 상태 검증을 뜻합니다. 흐름의 어떤 지점에서 기대한 상태 변화가 일어났음을 확인하는 것으로, 목적은 타당성 확인입니다. 위치는 자주 겹치지만(체크포인트를 찍는 자리에서 검증도 하는 것은 자연스럽습니다) 푸는 문제가 다릅니다. 논의에서 섞으면 혼란해지므로, 아래에서는 이 레슨의 것을 '검증 체크포인트', 9번째 코스의 것을 '복구 체크포인트'라 부르겠습니다.
검증 체크포인트를 더할 값어치가 있는지는 세 가지를 봅니다.
셋 다 해당하지 않으면 더하지 마세요.
어디에 두는가. 상태가 실질적으로 변하는 자리에 두지, 도구 호출마다 두는 것이 아닙니다.
체크포인트 둘, 종료 상태 하나. 단언 셋이 마이그레이션 전체를 관장합니다. '모든 중간 단계를 검증한다'로 갔다면 이 워크플로는 수십 개의 단언을 낳았을 것이고, 그 대부분은 정당한 구현 차이를 벌주는 것이었을 겁니다.
'올바른 종료 상태'라는 말은 구체적인 숫자나 분명한 판정에 닿아야 합니다. 그러지 않으면 '맞아 보인다'로 돌아온 것뿐입니다. 공식 문서는 성공 기준에 두 가지 강한 요구를 답니다.
하나 더 있습니다. 대부분의 사용 사례는 여러 성공 기준에 걸친 다차원 평가를 필요로 합니다2.
공식 문서의 완전한 예시는 한 문장입니다(괄호 안의 주석은 원문의 것입니다).
"The sentiment analysis model should achieve an F1 score of at least 0.85 (Measurable, Specific) on a held-out test set* of 10,000 diverse Twitter posts (Relevant), which is a 5% improvement over the current baseline (Achievable)."2
(감정 분석 모델은 다양한 Twitter 게시물 10,000건으로 이루어진 홀드아웃 테스트 세트에서 최소 0.85의 F1 점수를 달성해야 하며, 이는 현재 기준선 대비 5% 개선에 해당합니다)
이 문장은 뜯어 볼 값어치가 있습니다. 구성 요소 하나하나가 특정한 실패 양상을 막고 있기 때문입니다.
마지막 행이 '달성 가능'의 구체적인 방법입니다. 임계값은 바람에서 역산하는 것이 아니라 현재 상태에서 한 걸음 나아간 것입니다. 기준선이 없다면 가장 순진한 구현을 한 버전 돌려 그 점수를 기준선으로 삼으세요. 기준선조차 돌릴 수 없을 때는 숫자를 급히 정하지 마세요.
더 앞선 질문이 하나 있습니다. Anthropic이 에이전트에 적합한 상황을 서술할 때 이렇게 말합니다. 에이전트는 대화와 행동이 둘 다 필요하고, 성공 기준이 분명하며, 피드백 루프를 만들 수 있고, 의미 있는 사람의 감독을 통합한 작업에서 가장 큰 값어치를 더합니다3. 거꾸로 읽어 보세요. 이 작업에 대해 아무리 해도 성공 기준을 쓸 수 없다면 문제는 검증 단계에 있는 것이 아닙니다. 이 작업은 애초에 에이전트에 통째로 맡겨 혼자 돌리게 할 것이 아니었습니다. 기준을 쓸 수 없다면 처음부터 끝까지 지켜봐야 합니다 — 레슨 1에서 말했듯이 그 순간 여러분 자신이 검증 루프가 됩니다.
종료 상태 평가는 '결과가 올바른가'를 잡지만, 한 종류의 문제는 놓칩니다. 여러분이 새로 쥐여 준 그 도구를 에이전트가 실제로 알아보는가입니다.
공식 문서는 선택적인 추가 항목을 줍니다. 프롬프트-응답 쌍마다, 작업을 푸는 데 에이전트가 호출하리라 기대하는 도구를 선택적으로 명시해 두면, 평가 중에 에이전트가 각 도구의 목적을 제대로 파악했는지 잴 수 있습니다4. 이것이 궤적 단언입니다 — 순서를 판정하지도, 횟수를 판정하지도 않고, 특정 도구가 궤적에 나타났는지만 판정합니다.
쓸모 있을 때는 이렇습니다. search_internal_docs 도구를 막 추가했고, 사내 절차에 관한 질문에는 에이전트가 그것을 쓰기를 바랍니다. 그런데 에이전트는 공개 웹을 검색해 충분히 비슷한 답을 찾아오고, 종료 상태 검증은 그래도 통과합니다. 그 차이는 궤적만 볼 수 있습니다.
한계는 바로 다음 문장에 쓰여 있습니다. 작업을 올바르게 푸는 유효한 경로가 여럿일 수 있으므로, 지나치게 명세하거나 특정 전략에 과적합하지 않도록 하라는 것입니다4.
구체적인 경계는 이렇습니다.
평가를 한 번 돌리고 통과율만 손에 쥐면 할 말이 없어집니다 — 78%가 무슨 뜻일까요? 다음에 프롬프트를 손봐야 할까요, 도구를 손봐야 할까요?
공식 문서는 최상위 정확도 외에 이런 지표들을 수집하기를 권합니다. 개별 도구 호출과 작업 전체의 총 소요 시간, 총 도구 호출 횟수, 총 토큰 소비량, 그리고 도구 에러4. 이 지표들은 판정에 참여하지 않습니다. 진단에 참여합니다.
공식 문서는 두 가지 독법을 줍니다.
이 둘이 공유하는 것이 있습니다. 손가락이 모델이 아니라 도구 설계를 가리킨다는 점입니다. 중복 호출이 많은 것은 대개 한 번에 20건씩만 가져올 수 있어 열 페이지를 넘겨야 하기 때문이고, 파라미터 에러가 많은 것은 대개 그 필드에 어떤 형식이 필요한지를 도구 설명이 밝히지 않았기 때문입니다. 이런 문제는 도구 쪽에 뿌리가 있습니다 — 시스템 프롬프트에 '호출을 줄여라'나 '파라미터를 꼼꼼히 써라'를 덧붙이는 것만으로는 대개 통하지 않고, 도구의 파라미터 설계와 설명을 손봐야 합니다.
이 줄기를 따라가면 몇 개가 더 나옵니다(아래는 공식이 보증한 것이 아니라 위의 두 가지에서 미루어 본 엔지니어링 판단이니 여러분의 데이터에서 직접 확인하세요). 통과율은 그대로인데 토큰 소비가 두 배가 됐다면 이 변경은 공짜가 아닙니다. 한 부류의 작업만 소요 시간 분산이 유독 크다면 재시도나 맴돌기가 숨어 있을 가능성이 큽니다. 에러가 도구 하나에 몰려 있다면 프롬프트를 의심하지 말고 그 도구부터 보세요.
평가를 한 번 돌리면 최소한 이 열들은 떨어져야 합니다. 레슨 6에서 평가 하네스를 만들 때 그대로 씁니다(열 폭을 아끼려 입력·출력 토큰은 하나로 합칩니다).
하나: 모든 중간 단계를 검증하려 들지 마세요1. 이 레슨에서 가장 깨지기 쉬운 경계입니다. '많이 검증할수록 안전하다'는 직관이 너무 강하기 때문입니다. 실제 결과는 반대입니다. 단언이 촘촘해질수록 정당한 차이가 더 많이 벌을 받고, 평가는 더 시끄러워지며, 결국 빨간불을 무시하기 시작합니다 — 그 지점에서 완전히 쓸모없어집니다.
둘: 궤적 단언을 기본값으로 만들지 마세요. 궤적 단언을 더하는 비용이 워낙 싸서 expectedTools 항목 하나쯤은 힘도 안 들이고 씁니다. 열 번째 항목쯤이면 이미 실질적으로 전략을 규정하고 있고, 형식만 여전히 '단언'이라 부르고 있을 뿐입니다. 하나 더할 때마다 스스로에게 물으세요. 이 도구를 호출하지 않으면 출력이 정말로 깨지는가? 답이 '꼭 그렇지는 않다'라면 더하지 마세요.
셋: 실행 뒤에 임계값을 정하지 마세요. 0.82라는 점수를 보고 '0.8이면 충분하지'라고 말하는 것과, 0.86을 보고 '0.85는 돼야지'라고 말하는 것은 같은 자기기만입니다. 임계값은 실행 전에 정하고, 그 근거를 적어 두세요.
>> 레슨 3: 결정론적 검증기: 통과/실패를 내는 검사만이 유효하다
How we built our multi-agent research system — Anthropic Engineering — https://www.anthropic.com/engineering/multi-agent-research-system ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12
Define success criteria and build evaluations — Claude API documentation — https://platform.claude.com/docs/en/test-and-evaluate/develop-tests ↩ ↩2 ↩3 ↩4 ↩5
Building Effective AI Agents — Anthropic Engineering — https://www.anthropic.com/engineering/building-effective-agents ↩ ↩2
Writing effective tools for agents — with agents — Anthropic Engineering — https://www.anthropic.com/engineering/writing-tools-for-agents ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
invoices/ 의 PDF 200개를 "YYYYMMDD_vendor.pdf" 형식으로 바꾸기user.spec.ts 의 should reject expired token 테스트가 실패한다. 에이전트에 고치게 하기이것을 측정 가능한 다차원 성공 기준으로 다시 쓰세요. 차원마다 네 항목을 모두 쓰세요. 지표의 이름은 무엇인지, 어떻게 측정하는지, 임계값은 얼마인지, 왜 그 임계값이 현실적으로 달성 가능한지. 그다음 어느 차원이 종료 상태를 검증하고 어느 차원이 중간 체크포인트를 두는지 근거와 함께 정하세요. 최소 세 차원. 코드는 필요 없습니다.
작업: downloads/ 의 인보이스 PDF 이름을 "date_vendor.pdf" 형식으로 바꾸기
단계 기반 검증(깨지기 쉬움) 종료 상태 검증(안정적)1. list_files 호출 downloads/ 에 원래 파일 이름이 남아 있지 않다2. 각각에 read_pdf 호출 모든 파일 이름이 ^\d{8}_[a-z0-9-]+\.pdf$ 와 일치한다3. extract_date 호출 파일 개수가 실행 전과 같다, 잃거나 늘어난 것이 없다4. 각각에 rename_file 호출 파일 이름의 날짜가 PDF 내용의 인보이스 날짜와 일치한다작업: user 테이블을 옛 스키마에서 새 스키마로 마이그레이션
검증 체크포인트 1(테이블 생성 후): new_users 테이블이 존재하고, 열이 목표 스키마와 정확히 일치한다검증 체크포인트 2(데이터 적재 후): new_users 행 수 == old_users 행 수, 기본 키 중복 없음종료 상태: 앱이 새 테이블을 읽고 스모크 테스트(가장 기본적인 '돌아가는가' 검사)를 통과한다, old_users 는 old_users_backup 으로 이름이 바뀌어 있다
확인하지 않는 것: CREATE TABLE 을 썼는지 템플릿에서 복사했는지,한 번에 적재했는지 배치로 나눴는지, 배치가 몇 개였는지, 배치당 몇 행이었는지.// 평가 케이스 하나의 모양: 종료 상태 판정은 필수, 궤적 단언은 선택
const evalCase = {
id: 'invoice-rename-003',
prompt: 'downloads/ 의 이번 달 인보이스를 date_vendor.pdf 형식으로 이름 바꿔 줘',
// 필수: 실행 후 환경이 어떻게 됐는지 확인한다(쓰는 법은 레슨 3에서)
checkEndState: async (env) => { /* ... */ },
// 선택: 순서나 호출 횟수와 무관하게, 최소한 이 도구들은 건드렸기를 기대한다
expectedTools: ['read_pdf', 'rename_file'],
};
case_id | passed | duration_ms | tool_calls | tokens_in | tokens_out | tool_errors