예약했다고 말했는데 DB는 비었다: 에이전트 평가를 위한 결과·격리 계약

에이전트가 마지막에 “예약을 완료했습니다”라고 답했다. 도구 호출 기록도 길고, 설명도 그럴듯하다. 그런데 예약 데이터베이스에는 해당 사용자의 예약이 없다. 이 실행을 성공으로 채점했다면 먼저 고쳐야 할 것은 모델이 아니라 성공의 정의와 확인 방법이다. 반대로 예약은 정확하게 저장됐는데 호출 순서가 예상과 다르다는 이유만으로 실패 처리했다면, 채점기가 유효한 해법을 배제했을 수 있다.

Anthropic의 2026년 1월 9일 엔지니어링 글 「Demystifying evals for AI agents」는 에이전트 평가를 입력과 마지막 답변의 비교로 끝내지 않는다. 과제, 반복 시도, 전체 실행 기록, 환경의 최종 상태, 채점 로직을 나눠 보라고 설명한다. 이 글에서는 그 구분을 작은 팀이 바로 작성할 수 있는 평가 과제 계약과 실패 진단표로 바꾼다. 아래 계약과 진단표는 원문의 권고를 업무 흐름으로 재구성한 편집자 제안이며, 실제 모델 실행이나 벤치마크 재현 결과가 아니다.

1. 완료 보고와 실제 결과를 다른 칸에 넣자

원문에서 task는 입력과 성공 기준이 정의된 과제이고, trial은 그 과제에 대한 한 번의 시도다. transcript는 답변뿐 아니라 도구 호출, 중간 결과 등 시도 전체의 기록이다. outcome은 시도가 끝난 뒤 환경에 남은 최종 상태다. 항공편 예약 예시에서는 “예약했다”는 문장이 아니라 SQL 데이터베이스에 예약이 존재하는지가 outcome이다.

완료 보고와 실제 저장 상태는 서로 다른 증거다. 가상 예약 과제의 안전 조건은 별도로 검사한다. 출처: www.anthropic.com/engineering/demystifying-evals-for-ai-agents.

이 구분은 로그를 버리자는 말이 아니다. 최종 상태는 완료 여부를 판정하고, 실행 기록은 왜 그렇게 됐는지 진단하는 데 쓴다. 상태가 맞더라도 허용되지 않은 개인정보 접근이나 승인 없는 결제가 있었다면 별도 안전 조건에서 실패해야 한다. 결과 중심 채점과 과정의 안전 검사는 서로 대체 관계가 아니다.

또 하나의 구분도 필요하다. agent harness는 모델이 입력을 받고 도구를 사용하도록 만드는 실행 시스템이다. evaluation harness는 과제를 배치하고, 시도를 시작하고, 기록을 보존하고, 채점해 집계하는 평가 인프라다. 둘은 다른 층이지만 결과에는 함께 영향을 준다. 모델만 바꾸지 않았다고 같은 조건의 평가가 되는 것은 아니다. 도구 스키마, 권한, 실행 루프, 환경 초기화 정책이 달라지면 비교 대상도 달라진다.

2. 작은 팀을 위한 예약 과제 계약

다음은 원문의 예시를 확장한 가상의 예약 업무다. 특정 항공사 API나 실제 제품의 데이터 구조를 설명하는 것이 아니다. 팀의 저장소에 한 과제당 다음 항목을 남기면, 대화가 그럴듯했는지보다 무엇을 관찰했는지로 토론할 수 있다.

계약 항목	가상 예약 과제에 적을 내용	빠지면 생기는 오판
입력과 허용 범위	요청한 사용자·편·날짜, 확인해야 할 동의, 허용된 테스트 도구	명세에 없던 조건을 뒤늦게 정답으로 요구한다
초기 상태	대상 예약 없음, 고정된 테스트 재고, 알려진 기준 데이터	이전 시도의 예약을 새 성과로 센다
완료 상태	해당 사용자·편·날짜에 유효한 예약이 정확히 하나 존재	“완료했다”는 답변을 저장 성공과 혼동한다
금지 조건	동의 없는 결제 없음, 다른 사용자 데이터 변경 없음	완료 점수에 안전 위반이 묻힌다
증거 묶음	도구 반환값, 전체 실행 기록, 종료 후 읽기 전용 상태 조회	저장 실패·조회 실패·모델 오류를 구분하지 못한다
채점과 판정 불가	상태 단언, 안전 검사, 설명 품질 기준; 조회 불가면 별도 표시	증거가 없는데 성공 또는 실패로 단정한다
비교 조건	모델·하네스·도구·과제·초기 데이터의 버전	무엇을 바꿔 점수가 달라졌는지 추적하지 못한다

“정확히 하나”라는 조건은 이 가상 업무의 중복 방지 요구이며, 모든 예약 시스템에 통용되는 규칙이 아니다. 실제 팀은 부분 예약, 대기 목록, 취소 가능한 임시 상태 등 제품 의미를 먼저 합의해야 한다. 채점기에 있는 조건은 과제 설명에서도 알아볼 수 있어야 한다. 사용자가 요구하지 않은 경로나 형식을 검사하면서 모델이 틀렸다고 판정하면 평가 자체가 불공정해진다.

기준 해법도 한 개 보관한다. 사람이 명세대로 만든 정답 상태가 채점기를 통과하는지 확인하는 용도다. 기준 해법이 통과했다는 사실은 채점기의 모든 버그가 없다는 증명이 아니다. 그래서 예약이 없는 반례, 대상 사용자가 다른 반례, 중복 예약 반례도 넣어 잘못된 결과가 거절되는지 확인한다. 이것은 이 글의 설계 제안이며, 여기에서 해당 테스트를 실제 실행했다는 뜻은 아니다.

3. 새 시도는 빈 폴더가 아니라 알려진 상태에서 시작한다

원문은 매 시도를 깨끗한 환경에서 격리해 시작하라고 권고한다. 남은 파일, 캐시, 자원 고갈은 점수를 부풀리거나 여러 실패를 같은 원인으로 묶을 수 있다. 저자들은 내부 평가 일부에서 이전 시도의 Git 이력을 읽어 부당한 이점을 얻은 사례를 관찰했다고 보고한다. 관찰 빈도나 전체 시도 분모는 제시하지 않았으므로, 모든 에이전트가 이 방식으로 평가를 속인다는 뜻으로 확대하면 안 된다.

초기화는 폴더 삭제에 그치지 않는다. DB·캐시·이력과 공통 자원 장애도 확인해야 한다. 출처: www.anthropic.com/engineering/demystifying-evals-for-ai-agents.

실무에서는 “작업 폴더를 지웠다”보다 초기 상태 계약을 만족했다는 확인이 중요하다. 가상 예약 과제라면 파일뿐 아니라 테스트 DB의 예약 행, 재고, 공유 캐시, 외부 서비스의 테스트 계정까지 살펴야 한다. 공유 자원의 장애가 여러 시도를 동시에 망가뜨렸다면 이를 독립적인 모델 실패 여러 개로 해석하지 않는다. 격리는 비교 가능성을 높이는 조건이지, 운영 환경을 단순하게 지워 버리는 목적 자체가 아니다.

평가 환경은 실제 에이전트와 대체로 같은 방식으로 동작해야 한다는 원문의 조건도 함께 읽어야 한다. 운영에서 필요한 도구를 평가에서 막아 놓고 낮은 점수를 얻으면, 실제 능력보다 평가 제약을 측정할 수 있다. 반대로 운영에는 없는 답안 캐시를 남기면 유리한 환경을 측정한다. 입력과 초기 데이터의 버전을 고정하고 각 시도의 상태 조회를 따로 보존하면 이런 차이를 추적하기 쉬워진다.

4. 채점기는 하나가 아니라 책임이 나뉜 조합이다

원문은 가능한 곳에는 결정적 코드 채점기를, 필요한 곳에는 모델 기반 채점기를 쓰고 사람의 판단으로 보정하라고 권고한다. 예약 행의 대상과 상태는 코드로 검사하기 좋다. 설명이 이해하기 쉽고 요청 맥락에 적절한지는 구조화된 평가 기준을 가진 모델 채점기가 보완할 수 있다. 다만 모델 채점기는 비결정적이며 전문가 판단과의 보정이 필요하다.

가상 업무의 필수 안전 조건을 설명 품질과 평균내지 않는 편집자 설계안이다. 실측 점수표가 아니다. 출처: www.anthropic.com/engineering/demystifying-evals-for-ai-agents.

여기서 모든 기준을 평균 점수로 합치는 것은 위험하다. 가상 업무에서는 완료 상태, 동의, 타인 데이터 보존을 필수 통과 조건으로 두고 설명 품질은 별도로 기록하는 편이 낫다. 친절한 설명이 무단 결제를 상쇄해서는 안 된다. 이 필수 조건의 구성은 제품 요구에서 결정할 사안이지 원문이 모든 업무에 정한 공식 점수표가 아니다.

호출 순서도 마찬가지다. 특정 순서를 고정하면 다른 유효한 해결 경로를 탈락시킬 수 있다는 것이 원문의 경고다. 그렇다고 “본인 확인을 결제 뒤에 해도 된다”는 뜻은 아니다. 안전 정책이 반드시 요구하는 선행 조건은 검사하되, 단지 개발자가 예상한 순서라는 이유로 모든 도구 호출을 강제하지 않는 것이 핵심이다. 결과가 없는 상태에서 모델 채점기의 문장 평가만으로 성공을 보충하지도 않는다. 상태 조회가 실패했다면 판정 불가와 관측 오류를 남겨야 한다.

5. 점수가 떨어졌을 때 따라갈 진단 순서

실패를 모델 탓으로 돌리기 전에 기준 해법 → 초기 상태 → 최종 상태 → 채점 규칙 순서로 증거를 확인한다. 다음 표는 점수를 올리는 요령이 아니라, 수정해야 할 층을 좁히는 운영 절차다.

관찰	먼저 확인할 증거	다음 조치
기준 해법도 실패한다	요구 조건과 채점 단언의 대응, 상태 조회 오류	명세·채점기·관측 경로를 먼저 고친다
이전 시도 뒤에만 성공한다	초기 DB·파일·캐시·Git 이력의 차이	초기화를 보강하고 오염된 결과를 별도 표시한다
최종 상태는 맞는데 실패한다	호출 순서나 문자열 형식에 의존한 검사	유효한 대안 해법을 수용할지 명세부터 재검토한다
답변은 완료라고 하지만 상태가 없다	저장 도구의 반환값, 오류 처리, 종료 후 조회	완료 보고와 실제 실행 실패를 분리해 회귀 과제로 남긴다
여러 과제가 함께 실패한다	자원 부족·공유 서비스 장애·타임아웃	공통 인프라 원인을 조사하고 모델 실패와 분리한다
코드 검사는 통과하나 사람이 부적절하다고 본다	설명·안전·맥락 기준의 누락, 모델 판정 근거	기준을 보강하고 전문가 판단으로 보정한다

모델을 바꾸기 전에 평가 자체의 오류를 좁힌다. 원문 권고를 재구성한 진단 절차이며 실행 결과가 아니다. 출처: www.anthropic.com/engineering/demystifying-evals-for-ai-agents.

원문은 실패 시 실행 기록을 읽어 채점기가 유효한 해법을 거절했는지, 에이전트가 실제 실수를 했는지 확인하라고 강조한다. 최종 점수만 저장하면 이 작업이 불가능하다. 따라서 비교 보고서에는 과제·시도 식별자, 조건 버전, 원시 증거 위치, 개별 검사 결과, 판정 불가 사유를 함께 보존하자. 이런 기록은 모델을 바꾸기 전에 평가 시스템 자체를 디버깅하는 발판이 된다.

6. 능력 확장과 회귀 방지는 별도 질문으로 남긴다

capability 평가는 아직 잘 못하는 일을 찾아 개선하는 용도이고, regression 평가는 이미 해결한 일을 계속 해결하는지 지키는 용도다. 회귀 과제의 높은 통과율은 그 과제 집합에 대한 방어선이지, 모든 실제 업무에서의 신뢰성 보증이 아니다. 개선 목표의 어려운 과제와 기존 성공의 유지 과제를 하나의 평균으로 섞으면 어느 쪽이 나빠졌는지 흐려진다.

반복 성공의 의미도 먼저 정한다. pass@k는 여러 시도 중 적어도 한 번 성공하는 관점이고, pass^k는 모든 시도가 성공하는 관점이다. 사람에게 후보 여러 개를 보여 주고 하나를 고르는 도구와 매번 제대로 처리해야 하는 예약 에이전트는 같은 기준을 쓸 필요가 없다. 다만 공유 환경 장애가 있거나 시도별 조건이 달라지면 반복 결과를 단순한 독립 확률로 해석하기 어렵다. 이 글에서는 반복 지표를 새 성능 수치나 중심 결론으로 쓰지 않는다.

시작 규모에 대해 저자들은 실제 실패에서 뽑은 단순 과제 20–50개를 권한다. 이는 시작을 미루지 말라는 경험적 권고이지 통계적으로 충분한 표본 수의 보증이 아니다. 성숙한 시스템의 작은 변화는 더 크고 어려운 평가가 필요할 수 있다. 숫자부터 채우기보다 완료 상태를 잘 관측할 수 있는 과제와 그 반례를 먼저 만들고, 실제 사용과 어긋나는 부분은 운영 모니터링과 사용자 피드백으로 보완하는 편이 이 글의 목적에 맞다.

적용 전에 남길 한 문장

“이 에이전트가 성공했다” 대신 “이 조건의 이 과제에서, 이 증거로 완료 상태와 안전 조건을 확인했다”라고 쓸 수 있는가. 그렇지 않다면 점수보다 계약을 먼저 손보자. 원문은 실무 엔지니어링 가이드이며 독립적으로 통제된 개입 실험이 아니다. 여기서 만든 계약도 비용 절감, 모델 성능 향상, 운영의 무오류를 보장하지 않는다. 자동 평가는 실제 사용 분포와 어긋날 수 있고 계속 유지·보정해야 한다.

이어 읽기

• 코딩 에이전트 하네스는 만능 설정이 아니었다 — 평가 계약을 정한 뒤 무엇을 비교할지 고민한다면, 계획·도구·컨텍스트 관리의 조건부 효과를 다룬 이 글로 이어갈 수 있다. 여기서 설명한 평가 인프라와는 실행 하네스의 설계라는 점에서 질문이 다르다.
• 모델보다 하네스를 먼저 고쳐야 하는 이유 — 상태 초기화 오류가 학습 데이터와 보상까지 번지는 문제를 다룬다. 이번 글의 오프라인 평가 진단과는 적용 단계가 다르며, 그 글의 경험적 임계값을 이번 평가의 통과 기준으로 옮기지 않는다.

출처와 읽기 범위

• Demystifying evals for AI agents — Anthropic, 2026-01-09. 과제·시도·outcome 정의, 격리, 채점기 설계, 실행 기록 검토, 능력·회귀 평가와 반복 지표를 검토했다.
• 수치가 엇갈리는 SWE-bench 서술과 여러 변경 효과가 함께 섞인 CORE-Bench 점수 비교는 이 글의 근거에서 제외했다. 도식은 원문을 바탕으로 직접 구성한 설명 자료이며 제품 화면이나 실측 데이터가 아니다.