테스트는 통과했는데 배포해도 될까: AgentLens로 에이전트 퇴행 원인 좁히기

코딩 에이전트의 새 버전이 테스트를 통과했다. 그런데 사용자가 요구한 승인 대기를 건너뛰었거나, 도구 호출이 중간에 깨졌는데 마지막 답변만 정상적으로 끝났다면 배포해도 될까? 이때 필요한 것은 종합 점수 하나가 아니라 무엇이 달라졌는지 되짚을 수 있는 실행 근거다. 먼저 후보의 종료 사유와 도구 오류를 확인하고, 같은 과제를 수행한 기준 실행과 지시 준수·검증·도구 사용을 나눠 비교하자. 필수 제약 위반은 다른 점수가 높아도 별도로 보류하는 편이 맞다. 이것이 이 글에서 제안하는 배포 전 판단 순서다.

예를 들어 기준 버전은 수정 전 승인을 기다렸고 후보는 바로 수정했다고 가정하자. 둘 다 좁은 테스트를 통과해도 지시 준수는 같지 않다. 이 장면은 설명을 위한 구성 예시이며 직접 실행한 실험이 아니다. AgentLens가 제공하는 궤적 리뷰는 이런 차이를 숫자 뒤에 묻지 않고 근거와 함께 읽게 하려는 접근이다. 형식 검증을 없애는 도구도, 안전성을 인증하는 도구도 아니다.[1, §3.2–3.4]

1. 결과 한 칸에서 실행 기록으로 시야 넓히기

AgentLens의 평가 단위인 궤적은 사용자 메시지, 에이전트 답변, 도구 호출, 파일 수정, 명령 실행, 검증 시도와 저장소의 최종 상태를 포함한다. 테스트나 파일 상태처럼 확인 가능한 조건에는 형식 검증을 적용하고, 그와 함께 LLM 판정자가 항목별 점수와 서술형 리뷰를 만든다. 리뷰의 근거 포인터를 따라가면 왜 낮게 평가했는지 해당 실행 구간으로 돌아갈 수 있다.[1, §1·3.2]

검사 결과와 과정 리뷰는 보완 관계입니다. 형식 검증을 없애거나 안전성을 인증하는 구조가 아닙니다. 출처: arxiv.org/abs/2607.06624v2.

실무에서 이 구조가 유용한 이유는 실패를 한 종류로 취급하지 않기 때문이다. 결과물이 불완전한 것, 금지된 파일을 고친 것, 도구 인자를 잘못 보낸 것, 실행하지 않은 검사를 통과했다고 말한 것은 대응 방법이 다르다. 마지막 답변만 읽으면 이 구분이 사라질 수 있다. 반대로 테스트 실패가 있어도 정확한 원인 위치를 찾았는지, 오류에서 회복했는지 같은 과정 정보는 남는다. 과정이 좋았다고 실패를 성공으로 바꾸자는 뜻이 아니라, 수정할 대상을 구체화하자는 뜻이다.

공개 논문의 실험 범위도 먼저 고정해야 한다. 초기 폴드는 Java 시나리오 16개에 기본 사용자와 toxic 사용자 두 페르소나를 적용한, 에이전트당 궤적 32개다. 논문에는 helpful 페르소나 설명도 있지만 이 공개 실험 분모에 포함되지 않는다. 따라서 이를 독립적인 과제 32개나 모든 언어·실제 사용자에 대한 검증으로 읽으면 안 된다. 모델뿐 아니라 제공자, 에이전트 루프, 도구 인터페이스, 실행 정책이 합쳐진 시스템을 비교한 결과다.[1, §3.1·4.1·5]

2. 평균 점수보다 먼저 볼 여섯 칸

LLM 판정 항목은 End Result, Instruction Compliance, Pitfalls, Pleasantness, Tool Calls 다섯 가지다. 여기에 Formal Verification을 더한 여섯 구성요소의 단순 평균이 Quality Index, 즉 QI다. 테스트 통과율과 판정 점수는 생성 방식이 다르므로 원래 항목을 보존한 채 읽는 것이 중요하다.[1, §3.2–3.3]

QI 구성요소를 분리해 읽기 위한 설명표입니다. 높은 평균으로 필수 제약 위반을 상쇄하지 말자는 것은 이 글의 운영 제안입니다. 출처: arxiv.org/abs/2607.06624v2.

항목	배포 전 확인할 질문	되돌아갈 근거
Formal Verification	설정된 검사가 실제로 통과했나?	검증기 출력, 테스트·빌드 결과
End Result	사용자가 원한 결과를 끝냈나?	최종 파일 상태와 요구사항
Instruction Compliance	승인 대기와 파일 경계를 지켰나?	사용자 지시와 행동 순서
Pitfalls	조기 완료·검증 누락·반복 실패가 있었나?	오류 이후 흐름과 완료 선언
Pleasantness	설명이 정확하고 작업 상태를 오도하지 않나?	사용자에게 전달한 보고와 실제 상태
Tool Calls	적절한 도구와 인자를 쓰고 오류에서 회복했나?	요청 인자, 응답, 재시도 기록

이 질문표는 원문의 항목을 배포 검토 관점으로 풀어 쓴 편집적 해석이다. QI가 조금 올랐다는 이유만으로 금지 파일 수정이나 필수 승인 생략을 상쇄해서는 안 된다. 또한 판정의 서열형 점수와 그 평균은 성공 확률이 아니다. 우리 서비스에서 반드시 지켜야 할 조건은 별도 차단 기준으로 남기고, QI는 그 뒤에 읽을 요약 지표로 두자는 제안이다.

3. 기준 실행과 후보 실행으로 원인 좁히기

종료 사유와 실제 도구 응답을 먼저 확인하고, 같은 과제의 기준 실행과 후보 실행을 항목별로 비교한다. AgentLens의 쌍별 비교는 같은 과제의 두 궤적과 해당 항목의 개별 리뷰를 받아 차이를 설명한다. 원시 궤적은 구체적인 도구 호출이나 오류 문구 같은 세부 사항을 확인하는 데 쓰인다. 비교할 때 과제와 판정 항목을 맞추는 이유다.[1, §3.4]

아래 진단표는 논문과 공개 구현을 바탕으로 작성한 운영 제안이며, 로컬 벤치마크 실행이나 탐지 정확도 검증 결과가 아니다.

보이는 신호	먼저 확인할 기록	가능한 다음 조치	아직 말할 수 없는 것
테스트는 통과, 승인 대기 생략	지시문·타임라인·Instruction Compliance 리뷰	후보 배포 보류 후 실행 정책 검토	테스트가 통과했으니 안전하다는 결론
정상적인 마지막 답변, 비정상 종료	종료 사유·예외·Tool Calls와 Pitfalls 리뷰	도구 계층과 하네스 오류부터 분리	모델 추론 능력 자체가 하락했다는 결론
QI는 비슷한데 특정 항목 하락	같은 과제의 항목별 근거와 실제 변경	영향 과제를 추려 쌍별 리뷰	종합 점수가 같으니 품질도 같다는 결론
한 번만 형식 검증 실패	동일 조건의 반복 기록과 실패 지점	불안정 과제를 분리해 재평가	단발 실패가 확정적인 버전 퇴행이라는 결론

배포 검토를 위한 편집적 진단 순서입니다. 공개 README에서 쌍별 비교는 별도 수동 단계이며 자동 비교 알림까지 연결된 것은 아닙니다. 출처: arxiv.org/abs/2607.06624v2.

논문에는 병렬 도구 호출의 경쟁 상태 때문에 ConcurrentModificationException이 발생한 사례가 나온다. 겉보기에 평범한 마지막 답변보다 종료 사유와 Pitfalls 쌍별 리뷰가 디버깅에 유용한 단서를 제공했다. 다만 예시의 p값은 0.089다. 이를 0.05 기준에서 통계적으로 유의한 결과라고 부르면 안 된다. 경고와 구체적인 오류 근거가 있다는 사실과 보편적인 탐지 성능을 입증했다는 주장은 다르다.[1, §3.6·4.3 Example 2]

기준 실행을 남길 때에는 모델 이름뿐 아니라 제공자, 하네스 버전, 과제·설정 해시, 판정 모델과 실행 정책도 함께 기록하는 편이 좋다. 이 중 여러 조건을 동시에 바꾸면 어떤 변경이 차이를 만들었는지 좁히기 어렵다. 이는 결과가 전체 시스템의 성능이라는 논문의 범위와 공개 README의 실행 메타데이터 설명에서 도출한 운영 제안이지, 이 글에서 수행한 인과 실험은 아니다.[1, §4.1·5; 2, Interpreting Reports]

4. 평균이 안정적이어도 개별 과제는 흔들릴 수 있다

논문은 자체 호스팅한 GLM-5.1의 동일 설정을 다섯 번 실행했을 때 QI 평균이 67.28, 표준편차가 0.94였다고 보고한다. 척도는 0–100이다. 하지만 시나리오와 페르소나를 조합한 32개 평가 지점 중 형식 검증을 매번 통과한 것은 15개, 매번 실패한 것은 1개였고, 나머지 16개는 통과 여부가 섞였다.[1, §3.5.1·Figure 2]

논문이 보고한 동일 설정 5회 반복의 형식 검증 결과입니다. 32개는 독립 시나리오 수가 아니며 다른 모델의 변동폭으로 일반화할 수 없습니다. 출처: arxiv.org/abs/2607.06624v2.

이 그림의 핵심은 낮은 평균 변동이 개별 과제의 안정성을 보증하지 않는다는 점이다. 새 버전에서 실패가 나오면 전체 평균만 재확인하지 말고 해당 시나리오·페르소나의 반복 기록을 보자. 이 결과는 특정 모델·제공자·설정에 대한 논문 보고이며 모든 에이전트의 변동폭이나 신뢰구간이 아니다. 여기서는 원문 데이터를 다시 그렸을 뿐 벤치마크를 재현하지 않았다.

판정자도 완전한 정답지는 아니다. 논문이 GPT-5.5와 Sonnet 4.6을 판정자로 바꿔 비교한 157개 과제·항목 비교에서는 승자가 달라진 비율이 약 23%였다. 약 18%는 각 판정자가 자기 계열을 선호하는 방향, 약 5%는 반대 방향이었다. 이는 그 비교의 반올림된 보고치이지 보편적인 판정 오류율이 아니다. 정식 판정자–인간 일치도 연구는 아직 제시되지 않았으며, 순위표 실험의 고정 판정자는 GPT-5.4다.[1, §3.5.3·Table 5·5]

5. 도입 전에 비용·권한·공개 구현의 간격 확인하기

공개 README의 수집 단계에는 에이전트와 사용자 시뮬레이터 자격 증명이 필요하고, 평가 단계에는 판정 모델 자격 증명이 필요하다. GitHub MCP를 쓰는 시나리오는 토큰도 사용한다. IDE 기반 수집기와 CLI 에이전트용 어댑터는 연결 경로가 다르다. 평가 코드가 공개됐다는 것과 무료·로컬 전용으로 돌아간다는 것은 별개다. 논문은 Opus 4.7 단일 실행 비용이 미화 100달러를 넘을 수 있다고 적는다. 이는 논문 속 사례이며 현재 가격표나 전체 평가 비용의 보장이 아니다.[1, §5; 2, Quick Start·Collecting Runs]

도입을 검토한다면 평가용 저장소를 실제 운영 저장소와 분리하고, 필요한 범위만 가진 자격 증명과 비용 한도를 준비하는 편이 좋다. 장시간 궤적에는 코드·메시지·도구 응답이 담길 수 있으므로 외부 판정 모델에 전달할 데이터의 범위를 먼저 정하자. 이 보안·예산 경계는 이 글의 운영 권고이며, AgentLens 자체가 정보 유출을 막아 준다는 뜻이 아니다. 이 글을 위해 API 키를 입력하거나 에이전트·벤치마크를 실행하지 않았다.

또 하나의 함정은 논문의 내부 파이프라인과 공개 자동화를 같은 것으로 읽는 것이다. 논문은 내부 야간 파이프라인에서 기준 실행을 고르고 비교·알림을 연결했다고 설명한다. 그러나 고정 커밋의 공개 README는 compare_2_runs를 별도 수동 단계라고 명시한다. run-benchmark.yml에 쌍별 비교가 연결되어 있지 않으므로, 저장소를 포크하고 실행하는 것만으로 자동 기준 비교 알림까지 완성된다고 약속할 수 없다.[1, §3.6; 2, Development Notes]

6. 배포 회의에 가져갈 결론

이 논문에서 가져올 실용적인 변화는 새로운 순위표보다 검토 자료의 형태다. 테스트 결과 옆에 항목별 리뷰, 해당 실행 구간의 근거, 종료 사유, 기준 대비 차이를 함께 놓자. 그다음 필수 제약 위반은 차단하고, 도구·제공자·하네스 장애와 작업 결과의 문제를 분리해 수정 범위를 좁힌다. 차이가 작거나 실행이 불안정하면 반복 평가와 사람의 근거 검토를 남겨 두자.

다만 초기 Java 폴드와 시뮬레이션 사용자, 자체 에이전트 중심의 설계라는 한계는 남는다. 제삼자 제공자의 처리량·가용성도 비교에 영향을 준다. AgentLens를 모든 언어에 검증된 배포 승인 장치로 읽기보다, 테스트 통과 뒤에도 남는 질문을 근거로 토론하는 틀로 읽는 것이 이 글의 결론이다.[1, §5]

출처와 읽은 범위

• [1] AgentLens 논문 v2: §3.1–3.6, §4.1·4.3, §5와 Figure 2·Table 5를 중심으로 고정 PDF 본문을 확인했다. 최초 제출은 2026년 7월 7일, v2 제출은 7월 14일이다. 이 글의 예정일은 논문 발표일이 아니다.
• [2] 공개 구현 README, 커밋 07c563b0c7c38824259a75833ee90e8d2853ceec: How It Works, Collecting Runs, Running Evaluations, Interpreting Reports, Development Notes. 공개 구현과 논문의 내부 자동화 설명을 구분했다.

출처 확인일은 2026년 10월 15일이다. 본문의 진단표와 그림은 위 고정 근거를 바탕으로 직접 구성했다. 실제 제품 화면, 로컬 실행 결과, 독립 재현 또는 측정한 성능 개선을 뜻하지 않는다.