AI 에이전트의 오류를 고쳤다면, 같은 조건에서 다시 실패하는지 확인할 사례를 남겨야 한다. 실패 당시 질문만 복사해서는 부족하다. 입력 자료의 버전, 도구 응답, 시작 상태와 통과 조건을 함께 고정해야 변경 전후를 비교할 수 있다. 이처럼 이미 가능했던 동작이 수정 뒤에도 유지되는지 확인하는 평가가 회귀 테스트다.
이번 AI Agent Fast Learning은 Trace와 Span으로 오류 위치를 찾는 방법 다음 단계다. 아래 문서와 기록은 모두 학습용 합성 예시다. 실제 서비스 장애를 재현하거나 특정 모델의 성능을 측정한 결과가 아니다.
실패 기록과 테스트 사례는 다르다
가상의 문서 비교 에이전트가 보관 기간을 거꾸로 보고했다고 하자. 이전 문서에는 30일, 새 문서에는 60일이라고 쓰였는데 결과는 “60일에서 30일로 단축됐다”였다. 이 문장만 저장하면 오류의 흔적은 남는다. 그러나 다음 실행에서 조회 문서가 바뀌거나 앞선 대화가 섞이면 같은 조건을 다시 시험했다고 말하기 어렵다.
테스트 사례에는 이전 문서 A v1, 새 문서 A v2와 비교 방향을 넣는다. 통과 조건은 문장을 똑같이 쓰는 것이 아니라 “이전 값 30일, 새 값 60일, 변경 방향 증가”를 정확히 식별하는 것이다. 근거의 문서 버전까지 연결해야 다른 자료에서 우연히 같은 숫자를 찾은 답을 걸러낼 수 있다.
Anthropic은 에이전트 평가에서 한 번의 실행 기록과 환경에 남은 최종 결과를 구분하고, 회귀 평가를 기존에 처리하던 작업을 계속 처리하는지 묻는 평가로 설명한다. 이 글에서는 그 구분을 문서 비교 사례에 적용한다. 공식 자료: Demystifying evals for AI agents
비교 전에 사례와 채점 기준을 고정한다
문서 버전, 도구 응답, 시작 상태, 기대 결과, 비교할 시스템 버전과 채점 규칙을 고정한다. 정상 변경뿐 아니라 변경 없음, 구버전만 확보된 상황, 허용된 복구 뒤에도 자료를 확보하지 못한 상황을 포함한다. 보류만 반복하거나 늘 변경이 있다고 답하는 방식이 통과하지 않도록 하기 위해서다. 사례 구성과 일반화 평가의 기본 원칙은 기존 평가 설계 글에서 다뤘다. 여기서는 그 사례로 얻은 수정 전후 결과를 어떻게 읽을지 집중한다.
pytest의 fixture는 테스트에 필요한 초기 자료와 상태를 준비한다. 다만 격리 범위는 fixture의 scope와 외부 저장소 구성에 달려 있다. fixture를 사용했다는 사실만으로 앞선 대화나 외부 파일까지 초기화됐다고 판단하지 않는다. pytest 공식 fixture 문서
결과를 채점하되 중요한 경계도 확인한다
정답 문장을 완전히 일치시키는 채점은 “보관 기간이 늘었다”와 “보관 기간이 연장됐다”를 다르게 취급할 수 있다. 날짜·숫자·버전처럼 명확한 항목은 구조화된 값으로 대조하고, 설명이 원문을 과장했는지는 별도 기준으로 읽는 편이 낫다. 문장의 자연스러움과 근거의 정확성을 하나의 총점에 섞으면 무엇이 나빠졌는지 놓치기 쉽다.
도구 호출 순서는 반드시 필요한 제약만 검사한다. “A 조회 뒤 B 조회”를 요구하지 않았다면 두 자료를 병렬로 가져온 정답도 유효할 수 있다. 다만 “조회 실패 후 외부 게시 금지”처럼 작업의 권한과 부작용에 관한 조건은 최종 문장이 맞아도 별도로 확인해야 한다. 정답을 냈다는 사실이 잘못된 실행을 지우지는 않는다.
수정 전후를 비교하는 작은 기록 양식
아래 항목을 한 사례에 붙여 두면 수정할 때마다 무엇을 다시 확인할지 정하기 쉽다. 빈칸은 실제 실행 뒤에 채운다. 예시의 기대 결과는 설계된 기준이며 관측 결과가 아니다.
사례 ID: retention-direction-01 요청: 문서 A v1과 A v2의 보관 기간 비교 고정 입력: v1=30일, v2=60일 시작 상태: 새 대화, 결과 없음 기대 결과: 30→60 증가, 두 버전 근거 연결 금지 결과: 감소 주장, 없는 근거 인용 변경 대상: [프롬프트 / 코드 / 모델 중 기입] 수정 전: [실행 결과와 실패 항목] 수정 후: [실행 결과와 실패 항목] 추가 영향: [다른 사례의 새 실패 여부] 확인 범위: [모의 도구 / 실제 연결]
실행이 달라질 수 있는 모델이라면 한 번의 성공만으로 안정성을 판단하지 않는다. 비교할 반복 횟수와 조건을 미리 정하고, 통과 횟수뿐 아니라 실패한 사례의 종류를 남긴다. 모의 응답 시험에서 통과했어도 인증 만료나 실제 서비스의 응답 변화는 별도 연결 시험에서 드러날 수 있다. 이번 글에서는 모델 호출이나 연결 시험을 수행하지 않았다.
총점 대신 이전 버전에서 바뀐 칸을 찾는다
회귀 검사표에는 사례마다 기준 버전과 후보 버전의 결과를 나란히 둔다. 다음은 실제 측정값이 없는 판정 양식이다. 단순한 통과율 비교와 달리, 고치려던 오류와 새로 깨진 동작의 위치를 보존한다.
| 기준 → 후보 | 의미 | 다음 확인 |
|---|---|---|
| 실패 → 통과 | 해당 조건에서 수정 효과의 증거 | 채점 기준까지 바꾼 결과인지 대조 |
| 통과 → 실패 | 회귀 의심 | 자료·환경 변화와 제품 오류를 구분 |
| 실패 → 실패 | 문제가 남아 있음 | 같은 실패인지 새 실패인지 확인 |
| 통과 → 통과 | 이번 조건에서 기능 유지 | 금지 행동도 없었는지 확인 |
| 미실행 → 통과 | 첫 관측 | 개선이라고 집계하지 않음 |
| 통과 → 평가 환경 오류 | 비교 불가 | 환경을 복구한 뒤 별도 실행으로 재평가 |
예를 들어 새 문서 파일이 테스트 폴더에 없어 평가 실행기 자체가 시작되지 않았다면, 에이전트가 자료 부족에 잘 대응했는지는 아직 모른다. 반면 “도구가 조회 실패를 반환한다”는 조건을 의도적으로 넣었고 에이전트가 값을 지어냈다면, 환경 오류가 아니라 그 사례의 제품 실패다. 실패라는 글자 하나로 묶지 말고, 의도한 시험 조건이 성립했는지부터 확인한다.
이 문서 비교 작업에 적용할 공개 전 규칙도 구체적으로 적을 수 있다. 고치려던 방향 오류가 통과로 바뀌었는지, 기존 정상·변경 없음 사례가 유지됐는지, 버전 불일치·조회 실패 상황에서 근거 없는 완료 주장이 없는지 확인한다. 중요한 칸이 미실행이면 통과로 채우지 않는다. 환경 오류를 분모에서 조용히 제외하지 말고, 계획한 실행 수와 통과·제품 실패·평가 환경 오류·미실행 수를 함께 기록한다. 반복 실행 수와 고유 사례 수는 따로 센다. 한 번의 통과→실패는 회귀 의심 신호다. 모델 출력이 변동한다면 같은 조건의 반복 결과를 더 확인해야 한다. 이 규칙은 보편적인 배포 기준이 아니라 위 문서 비교 작업의 위험을 고려한 설계 제안이다.
테스트 자료가 바뀌면 비교 이력도 나눈다
서비스 규칙이 바뀌어 정답 자체를 고쳐야 할 때도 있다. 기존 사례의 기대 결과를 덮어쓴 뒤 어제와 오늘의 점수를 비교하면, 에이전트의 변화와 시험지의 변화가 섞인다. 사례에 개정 번호를 붙이고 바뀐 입력·기대 결과·이유를 남긴다. 가능하면 기준 버전과 후보 버전을 새 사례 묶음에서 모두 다시 평가한다. 이전 기록은 당시 조건의 결과로 보존한다.
문서를 익명화하며 기관명만 바꾼 경우에도 조건이 그대로 유지됐는지 읽어야 한다. 날짜나 단위를 지우다가 오류를 일으킨 조건까지 없애면 안전한 자료는 얻어도 유효한 회귀 사례는 잃을 수 있다. 공개용 합성 사례와 접근이 통제된 실제 사례를 같은 증거라고 보고하지 않는다.
회귀 테스트의 통과율을 일반 성능으로 읽지 않는다
회귀 사례는 개발 중 반복해서 볼 수 있다. 알려진 실패가 돌아오는지 막는 것이 목적이기 때문이다. 그 사례에 맞춰 프롬프트를 고친 뒤 얻은 통과율은 처음 보는 문제를 얼마나 잘 푸는지 보여주지 않는다. 새로운 문제로의 일반화는 별도의 평가 자료로 확인해야 한다. 이 차이는 개발 세트와 최종 평가 세트를 나누는 방법에서 이어 볼 수 있다.
오늘 만들 첫 사례는 크게 잡을 필요가 없다. 틀린 문장 하나를 고르고, 그 문장을 낳은 입력 조건과 금지할 결과를 적어 보자. 그리고 기준과 후보의 결과를 나란히 놓고, 회귀 의심과 비교 불가가 어느 칸에 남았는지 표시한다. 오류 보고가 다음 수정의 검사 항목으로 남을 때, 같은 실수를 매번 처음부터 조사하는 일을 줄일 수 있다.
자료 확인: 2026년 10월 8일. Anthropic의 2026년 1월 9일 에이전트 평가 글과 pytest 공식 fixture 문서를 대조했다. 사례·도식·기록 양식은 이 글에서 구성한 학습용 설계 제안이다. 실제 모델 평가 결과, 제품 성능 또는 장애 해결 실적을 제시하는 글이 아니다.