학습 목표:
- '케이스가 수백 개 모일 때까지 기다리자'가 왜 틀렸는지, 그리고 초기 단계의 변경은 효과 크기가 커서 몇 개의 케이스만으로도 버전을 구분할 수 있는 이유 설명하기
- 다음 원칙에 따라 평가 케이스 묶음 설계하기 — 실제 사용에 뿌리를 두고, 엣지 케이스로 보강하고, 가능하면 채점을 자동화하고, 케이스별 품질보다 개수를 앞세우고, 모호한 케이스를 의도적으로 포함하되 각각에 검증 가능한 결과를 짝지어 두기
- 홀드아웃 세트로 프롬프트가 '이 문제들만 통과하는 모델'로 과적합되는 것을 막고, 자동 평가가 볼 수 없어서 수동 테스트로 잡아야 하는 문제가 무엇인지 식별하기
전제: 레슨 1–4('완료된 것처럼 보인다' ≠ 완료됐다, 종료 상태 우선의 검증 대상, 결정론적 검증기, LLM 판정자) | 이전: << 레슨 4 | 다음: 레슨 6 >>
이런 장면을 본 적이 있을 것입니다. 누군가 제안합니다. "우리 에이전트용 평가 세트를 만들어야 합니다." 다른 사람이 답합니다. "평가 세트는 통계적 유의성을 가지려면 케이스가 수백 개는 있어야 하지 않나요? 열 개 스무 개 돌려 봐야 의미 없는 점수만 나오고 정보보다 오해를 더 많이 줍니다. 실제 사용자 케이스를 먼저 모으고, 충분히 쌓이면 그때 만듭시다."
전문가처럼 들립니다. 원칙 있어 보입니다. 그러고 나서 6개월이 지나고, 케이스는 공유 문서에 그대로 있고, 프롬프트는 서른 번 고쳐졌고, 그 수정 중 어느 것이 개선이었고 어느 것이 퇴행이었는지 아무도 말하지 못합니다.
Anthropic이 자사 멀티 에이전트 리서치 시스템에 대해 쓴 엔지니어링 회고는 이 핑계를 직접 지목합니다. AI 개발 팀들이 평가를 만드는 것을 미룬다는 이야기를 자주 듣는데, 테스트 케이스가 수백 개인 큰 평가만 쓸모 있다고 믿기 때문이다. 그러나 실제로는 미루지 말고 예시 몇 개로 소규모 테스트를 당장 시작하는 편이 가장 좋다1.
이 레슨이 정리하는 것이 바로 그것입니다. 초기에 작은 세트가 왜 정말로 통하는지, 케이스 하나는 어떤 모습이어야 하는지, 그 케이스들을 어떻게 고르는지, 그리고 '에이전트를 이 문제들만 잘 푸는 전문가로 길들이는 것'을 어떻게 막는지입니다.
용어부터 시작합시다. 효과 크기란 변경으로 벌어진 간격이 얼마나 큰가를 말합니다. 71.2%에서 72.4%로 옮겨 간 것입니까, 아니면 30%에서 80%로 뛴 것입니까? 간격이 클수록 필요한 표본은 적고, 간격이 작을수록 더 많이 필요합니다. 신비한 이야기가 아니라 물 두 컵 중 어느 쪽이 더 뜨거운지 가릴 때 쓰는 상식과 같습니다. 30도 차이는 손만 대면 알고, 0.5도 차이는 온도계를 요구합니다.
에이전트 개발 초기는 앞쪽에 속합니다. 공식 회고가 명확히 말합니다. 에이전트 개발 초기에는 낮게 달린 열매가 많아서 변경이 극적인 영향을 주는 경향이 있다. 프롬프트를 조금 손대는 것만으로 성공률이 30%에서 80%로 오를 수 있고, 효과 크기가 이 정도라면 테스트 케이스 몇 개만으로도 변화를 알아볼 수 있다1.
이런 상황을 그려 보십시오. 케이스가 6개 있고, 변경 전에는 2개가 통과했고, 변경 후에는 5개가 통과합니다. p값이 필요합니까? 아닙니다. 필요한 것은 이 버전의 프롬프트를 고정해 두고 다음 30%→80% 개선을 찾으러 가는 것입니다.
그들이 시작한 규모도 신비할 것이 없습니다. 실제 사용 패턴을 대표하는 질의 20개 정도의 세트입니다1. 20은 마법의 임계값이 아니라, 오후 한나절이면 끝내서 그날 바로 쓸 수 있는 분량일 뿐입니다.
반대 방향도 성립합니다. 에이전트가 이미 80%대에 올라 있고 남은 변경이 1~2%포인트만 움직인다면, 몇 개의 케이스로는 정말 구분되지 않습니다. 그때는 케이스가 더 필요합니다. 하지만 그 시점에는 이미 동작하는 평가 세트가 있고, 그것을 늘리는 일은 맨땅에서 만드는 것보다 훨씬 쉽습니다. 자를 먼저 손에 쥐고 정밀도를 논하십시오. 자가 정밀해질 때까지 재는 것을 미루지 마십시오.
평가 세트는 '프롬프트 더미'가 아닙니다. 프롬프트 더미로는 출력을 눈으로 훑는 것밖에 못 하는데, 두 번 읽으면 지겹고 세 번 읽으면 자기기만이 됩니다.
도구 엔지니어링 글은 직설적입니다. 모든 평가 프롬프트에는 검증 가능한 응답이나 결과가 짝지어져 있어야 하고, 검증기는 정답과 샘플링된 응답의 정확한 문자열 비교처럼 단순할 수도 있고 Claude를 동원해 응답을 판정하게 하는 것처럼 고급일 수도 있다2. 이것은 레슨 2의 성공 기준, 레슨 3의 결정론적 검증기, 레슨 4의 LLM 판정자와 곧바로 이어집니다. 그 레슨들이 어떻게 검증할지를 가르쳤다면, 이 레슨은 무엇을 검증할지를 가르칩니다.
그러므로 쓸 만한 케이스 하나에는 최소한 세 가지 구성 요소가 분명히 적혀 있어야 합니다.
데이터로 구조화하면 이런 모양입니다.
여기서 expected 필드는 종료 상태와 관찰 가능한 증거를 기술하는 것이지 '에이전트가 거쳐야 할 사고의 순서'를 기술하는 것이 아닙니다. 레슨 2의 결론이 그대로 적용됩니다. 같은 목표에 대해 에이전트는 여러 유효한 경로를 택할 수 있으므로 경로를 하드코딩하지 마십시오. 도구 엔지니어링 글도 상기시킵니다. 에이전트가 각 도구의 목적을 파악했는지 측정하기 위해 호출을 기대하는 도구를 선택적으로 지정할 수 있지만, 유효한 경로가 여럿일 수 있으므로 과도하게 지정하거나 특정 전략에 과적합되지 않도록 하십시오2.
mustCallTools 필드를 보면 레슨 2의 expectedTools가 떠오를 수 있습니다. 둘의 관계는 확실히 못 박아 둘 가치가 있습니다. 부정 단언(mustNotContain, mustNotCallTools — '변경해 드렸습니다'라고 말하지 말 것, 주문번호를 추측해서 조회하지 말 것)은 본질적으로 '일어나면 안 되는 일이 일어나지 않았다'를 기술하는 종료 상태 가드레일이라 엄격하게 강제할 수 있습니다. 긍정 도구 단언(특정 도구를 반드시 호출했어야 한다)은 레슨 2의 궤적 단언이고, 그때의 세 가지 규율이 그대로 적용됩니다. 집합 포함 관계만 단언할 것, 정말 신경 쓰는 도구 한둘만 나열할 것, 단언은 실패했지만 종료 상태는 통과했다면 즉시 실패시키지 말고 관찰 기록을 남길 것. 딱 한 경우에만 단단해집니다. 응답의 핵심 정보가 그 도구의 반환값에서만 나올 수 있을 때입니다. 케이스 cs-003이 바로 이 유형입니다. '이미 출고'라는 판단은 getOrder에서만 나올 수 있으므로, 도구를 호출하지 않았다면 그 진술은 지어낸 것이고, 따라서 이 긍정 단언은 강제할 수 있습니다. 애매하면 무른 쪽으로 취급하십시오.
하나 더. 이 케이스의 mustNotContain에는 '변경해 드렸습니다'가 들어 있는데, 에이전트가 말로만 배송지를 바꿔 주겠다고 하고 실제로는 아무것도 하지 않는 것을 막기 위한 것입니다. 이 '말로만 완료'가 바로 레슨 1의 주제입니다.
아래 다섯 규칙은 Claude 플랫폼의 '테스트와 평가' 문서에 있는 설계 원칙과 도구 엔지니어링 글의 실천을 하나의 체크리스트로 합친 것입니다. 각 규칙 뒤의 인용이 출처를 가리킵니다.
하나: 실제 사용에 뿌리를 두십시오. 실제 사용에 뿌리를 둔 평가 과제를 많이 만들어 내십시오2. 실제 과제 분포를 반영하는 평가를 설계하십시오3. 기준은 간단합니다. 이 프롬프트가 실제 로그에서 복사한 것이 아니라면, 그것을 가리키며 '지난주에 사용자 세 명이 정확히 이렇게 물었다'고 말할 수 있습니까? 아니라면 아마 책상 앞에서 상상한 것입니다.
둘: 엣지 케이스를 빠뜨리지 마십시오. 공식 문서는 '실제 과제 분포를 반영하라' 바로 뒤에 주의를 덧붙입니다. 엣지 케이스를 반영하는 것을 잊지 마십시오3. 실제 분포가 몸통이고 엣지 케이스는 보험입니다. 전부 엣지 케이스로 채운 평가 세트는 당신을 오도합니다. 한 달에 두 번 나타나는 문제를 고치느라 한 달을 쓰게 됩니다.
셋: 가능하면 채점을 자동화하십시오. 자동 채점이 가능하도록 문제를 구성하십시오. 예를 들어 객관식, 문자열 일치, 코드 채점, LLM 채점입니다3. 이것이 평가 세트를 반복해서 돌릴 수 있는지를 결정합니다. 통과/실패를 판정하려고 5분씩 읽어야 하는 케이스는 열 개쯤 쓰고 나면 두 번 다시 돌리고 싶지 않아집니다.
넷: 품질보다 개수를 앞세우십시오. 공식 표현은 이렇습니다. 신호가 다소 약하더라도 자동 채점되는 문제가 많은 편이, 사람이 손으로 고품질 채점하는 문제가 적은 편보다 낫습니다3. 가장 직관에 어긋나면서 시간을 가장 많이 아껴 주는 규칙입니다. 케이스 하나의 채점 기준을 완벽하게 다듬는 대신 케이스를 열 개 더 쓰는 데 시간을 쓰십시오.
다섯: 모호한 케이스를 의도적으로 모으십시오. 문서는 포함할 가치가 있는 테스트 케이스 유형을 명시적으로 하나 나열합니다. 사람끼리도 평가 합의에 이르기 어려운 모호한 테스트 케이스입니다3. 이것은 점수를 올리려고 넣는 것이 아니라 이견을 드러내려고 넣는 것입니다. 에이전트가 이런 케이스에서 갈팡질팡한다면, 그것은 제품 차원의 규칙 자체가 정해지지 않았다는 신호입니다. 제품이 풀어야 할 문제이지 프롬프트 엔지니어링으로 고칠 문제가 아닙니다.
'설계 원칙'은 아니지만 똑같이 중요한 점이 하나 더 있습니다. 평가 환경을 너무 단순하게 만들지 마십시오. 도구 엔지니어링 글은 도구를 충분한 복잡도로 시험하지 못하는 지나치게 단순하거나 피상적인 '샌드박스' 환경을 피하라고 권합니다. 좋은 평가 과제는 여러 번의 도구 호출을, 어쩌면 수십 번을 요구할 수 있습니다2. 데이터베이스 조회 한 번으로 답이 나오는 문제는 당신의 에이전트가 일곱 번째 도구 호출쯤에서 컨텍스트를 잃는지 아닌지를 알려 주지 않습니다.
성실하게 케이스 20개를 만들고 프롬프트를 다듬기 시작했다고 합시다. 첫 버전은 8개 통과, 한 번 고치니 12개, 또 고치니 16개, 또 고치니 19개. 훌륭합니다.
문제는 이것입니다. 그 19개 중 얼마가 에이전트가 정말 강해져서 나온 것이고, 얼마가 당신이 이 20개 문제의 특징을 슬그머니 프롬프트에 심어 넣어서 나온 것입니까? 예를 들어 7번 케이스가 계속 실패하는 것을 보고 시스템 프롬프트에 '반품 문의는 7일 무조건 환불 정책을 우선 인용할 것'이라는 줄을 추가합니다. 7번은 통과하지만, 실제로 한 일은 그 문제의 답을 써 준 것입니다.
이 현상을 과적합이라고 부릅니다. 모델(이 맥락에서는 프롬프트와 도구를 합친 구성 전체)이 과제 자체의 규칙성이 아니라 학습 재료의 특징을 배우는 것입니다.
도구 엔지니어링 글이 내놓는 처방은 한 문장이지만 결정적입니다. 그들은 '학습용' 평가에 과적합되지 않았음을 확인하기 위해 홀드아웃 테스트 세트에 의존했습니다2.
홀드아웃 세트란 처음부터 따로 떼어 두고 일상적인 튜닝 동안에는 보지도 돌리지도 건드리지도 않는 케이스 묶음입니다. 그 가치는 전적으로 '오염되지 않았다'는 데서 나옵니다. 팀 합의로 성문화해 둘 만한 규율이 몇 가지 있습니다.
dev로 기록합니다). 홀드아웃 세트는 릴리스 직전이나 구조적 변경(모델 교체, 도구 설명 재작성, 하네스 루프 변경) 이후에만 돌립니다.짚어 둘 만한 흔한 엔지니어링 관행이 하나 있습니다. 평가를 CI에 걸어서 커밋마다 dev 세트를 자동으로 돌리고, 이전 버전과 점수를 비교하고, 점수가 떨어지면 막는 것입니다. 이것은 표준적인 엔지니어링 관행이고 오케스트레이션은 파이프라인에 달려 있어 이 과정에서는 다루지 않습니다. 레슨 6에서 '실제로 돌아가는 평가 트랙'을 만들 것이고, 그것을 CI에 붙일지는 당신의 선택입니다.
평가 세트를 만들었고 돌아가고 점수도 좋다면, 사람 테스트는 없애도 됩니까?
아닙니다. 공식 회고는 분명합니다. 자동 평가가 있는 세상에서도 수동 테스트는 여전히 필수입니다1. 이유는 에이전트를 테스트하는 사람이 평가가 놓치는 엣지 케이스를 찾아내기 때문입니다. 흔치 않은 질의에서의 환각 답변, 시스템 장애, 미묘한 출처 선택 편향 같은 것들입니다1.
세 번째 범주는 특히 전형적이라 따로 언급할 만합니다. 그들의 사람 테스터들이 알아챈 것은 이렇습니다. 초기 에이전트들은 학술 PDF나 개인 블로그처럼 권위는 있지만 검색 순위가 낮은 출처 대신, SEO에 최적화된 콘텐츠 팜을 일관되게 골랐습니다1.
이 편향이 어떻게 보이는지 잠시 생각해 보십시오. 개별 사례는 하나하나 멀쩡해 보입니다. 에이전트는 인용이 달리고 출처가 있고 그럴듯한 답을 내놓습니다. 사실 확인 통과, 인용 형식 통과, 완전성 통과, 그리고 당신의 채점 차원 어디에서도 문제가 잡히지 않습니다(루브릭에 마침 레슨 4의 '출처 품질' 차원이 들어 있고 그 기준이 충분히 날카롭지 않은 한). 그런데 출력 백 개를 함께 놓고 보면 패턴이 드러납니다. 찾기 가장 쉬운 종류의 콘텐츠를 체계적으로 고르고 있는 것입니다.
당신의 평가 세트는 이런 부류의 패턴을 미리 볼 수 없습니다. 평가 세트는 당신이 이미 아는 실패 양상을 근거로 쓰였기 때문입니다. 생각해 보지 못한 양상에는 당연히 그것을 막는 케이스도 없습니다. 수동 테스트는 평가를 대체하는 것이 아니라 평가 세트에 새 항목을 공급합니다. 그런 패턴을 발견할 때마다 케이스로 성문화해 두면 다음부터는 자동으로 확인됩니다.
또 한 부류는 자연스럽게 평가 세트에 속합니다. 문서가 '보장되지 않는다'고 명시한 동작입니다. 도구 사용 문서가 좋은 예를 제공합니다. 사용자의 프롬프트에 어떤 도구의 필수 파라미터를 전부 채울 만한 정보가 들어 있지 않으면, Claude Opus는 파라미터가 빠졌다는 것을 알아채고 그것을 되묻는 경우가 훨씬 많습니다. 그러나 문서는 곧바로 이 동작이 보장되지 않으며 특히 더 모호한 프롬프트와 능력이 낮은 모델에서 그렇다고 못 박습니다4.
'훨씬 많다'와 '보장되지 않는다'는 신호입니다. 이것이 당신의 시나리오에서 성립하는지는 직접 테스트하는 수밖에 없습니다. 제품 로직이 의존하고 있는데 문서는 확률적으로만 기술하는 동작이라면, 케이스 몇 개로 계속 감시할 가치가 있습니다.
이 레슨을 다시 모아 봅시다.
도구 엔지니어링 글의 순서는 이렇습니다. 도구의 빠른 프로토타입을 세우고 로컬에서 테스트하는 것으로 시작하고, 그다음 이후의 변경을 측정하기 위해 포괄적인 평가를 돌립니다2. '이후의 변경'이라는 대목에 주목하십시오. 평가는 현재 상태에 점수를 매기고 끝내려는 것이 아니라, 그 가치가 이후의 모든 변경을 측정 가능하게 만드는 데 있습니다. 평가가 있으면 '이 버전의 프롬프트가 더 낫다'가 느낌에서 결론으로 바뀝니다.
에이전트 구축에 관한 글은 한 걸음 더 나갑니다. 다른 모든 LLM 기능이 그렇듯 성공의 열쇠는 성능을 측정하고 구현을 반복해서 다듬는 것이고, 다시 말하지만 복잡도는 결과를 확실히 개선한다는 것이 입증될 때만 추가를 고려해야 합니다5.
이 말은 맥락과 함께 읽을 때 무게가 실립니다. 앞선 아홉 개 과정에서 배운 기법들, 멀티 에이전트 분업, 메모리 시스템, 컨텍스트 압축, 체크포인트 복구는 하나같이 복잡도를 더합니다. 평가 세트가 없으면 '이걸 추가해서 정말 나아졌는가'에 답할 수 없고, 그러면 감으로 추가하는 수밖에 없으며, 감으로 추가하기 시작하면 계속 추가하게 됩니다. 평가 세트는 화려한 설계를 덜어 낼 수 있게 해 주는 증거입니다.
마지막으로 비례에 관한 이야기입니다.
이 과정이 인용하는 1차 출처를 전부 뒤졌지만, '케이스가 몇 개면 평가 세트로 충분한가'에 대한 임계값을 주는 곳은 한 군데도 없었습니다. 있는 것은 시작 규모(실제 질의 20개 정도)와 방향성 지침(케이스별 품질보다 개수를 앞세울 것)뿐입니다. 그러니 그 숫자를 찾아다니지 말고, '최소 50개'라고 아무렇지 않게 인용하는 사람도 믿지 마십시오.
진짜 기준은 이 레슨의 첫머리에 나온 것입니다. 지금 당신이 하는 변경의 효과 크기를 놓고 볼 때, 지금 가진 케이스로 그 차이를 구분할 수 있는가?
케이스 개수는 필요한 분해능을 따라가는 것이지 어떤 심리적 숫자를 따라가는 것이 아닙니다.
그럼 이 케이스 묶음을 실제로 어떻게 돌릴 것인지, 과제마다 루프를 하나씩 어떻게 돌리고 채점을 어떻게 계층화하고 통과율 말고 무엇을 더 추적할지는 레슨 6입니다. 이 레슨에서 가져가야 할 것은 케이스 묶음 그 자체입니다.
>> 레슨 6: 실습: 에이전트를 위한 평가 트랙 만들기
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
Writing effective tools for agents — with agents — Anthropic Engineering — https://www.anthropic.com/engineering/writing-tools-for-agents ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11
Define success criteria and build evaluations — Claude API documentation — https://platform.claude.com/docs/en/test-and-evaluate/develop-tests ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9
Tool use with Claude — Claude API documentation — https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview ↩ ↩2
Building Effective AI Agents — Anthropic Engineering — https://www.anthropic.com/engineering/building-effective-agents ↩ ↩2
과제: 평가 케이스 10개의 초안을 쓰십시오. 코드는 필요 없고 표나 목록이면 됩니다. 구성 요건은 이렇습니다.
각각에 대해 세 가지 구성 요소를 분명히 쓰십시오. 프롬프트 요약, 검증 가능한 결과, 어느 유형의 검증기인가(결정론적 / 판정자 / 둘 다).
세 가지를 산출하십시오.
id, prompt, expected(또는 루브릭 참조), 검증기 유형, tags. 완전히 채워진 인스턴스를 최소 3개 제시하십시오.prompt : 에이전트에게 주는 입력 (사용자가 말할 법한 방식으로 쓸 것)expected : 검증 가능한 결과 (종료 상태, 문자열, 상태 변화, 또는 루브릭)verifier : 누가 판정하는가 — 결정론적 검증기 또는 LLM 판정자{
"id": "cs-003-address-change-after-ship",
"prompt": "주문 배송지 바꿀 수 있나요? 주문번호 SO-88213이고, 이사했어요.",
"expected": {
"mustCallTools": ["getOrder"],
"mustContain": ["이미 출고"],
"mustNotContain": ["변경해 드렸습니다"]
},
"verifier": "deterministic"
}