에이전트는 완료를 선언하고, 실패는 숨어든다

진척인가 제자리걸음인가

LoopArena(에이전트의 실행 통제 능력을 재는 평가 도구)는 코드를 작성하는 워커는 그대로 두고, 이를 감독하는 컨트롤러만 바꿔 성능을 비교한다. 컨트롤러는 구조화된 실행 요약을 바탕으로 계약, 특정 항목 검증, 롤백, 제출 가운데 다음 행동을 선택한다. 그러나 전체 과제를 엄격하게 평가했을 때 최고 성공률은 24.69%에 불과했다. 컨트롤러가 오래된 진척 메모를 그대로 믿거나 검증을 건너뛰고, 중요하지 않은 작업에 예산을 낭비하거나 안전성이 확인되지 않은 상태에서 결과를 제출했기 때문이다.

SpecBench는 코드 규모가 1,500줄에서 11만 줄에 이르는 과제 30개로 모델을 평가했다. 모든 모델이 공개 검증은 통과했지만, 숨은 테스트에서는 결과가 크게 달라졌다. 코드가 10배 커질 때마다 공개 검증과 숨은 테스트 사이의 90분위 격차가 27%씩 벌어졌다. C 컴파일러 과제에서는 공개 검증 통과율이 97%였지만, 숨은 테스트 통과율은 0%였다. 특히 과제가 길고 모델이 작을수록, 성공을 뜻하는 ‘초록’ 보고서가 실제 준수도 하락을 더 많이 가렸다.

워커가 서로 충돌하는 두 편집을 번갈아 반복해도 감독자는 이를 진척으로 오인할 수 있다. 실제로 다섯 개 프레임워크에서 이러한 무한 루프 사례가 13건 발견됐다. 비용이 발생하는 호출로 되돌아오는 실행 경로를 탐지하는 IAL-SCAN은 92.3%의 정밀도를 기록했다. 결국 진척 메모만으로는 작업이 앞으로 나아가는지, 같은 자리에서 헛돌고 있는지 구별하기 어렵다.

테스트 통과가 품질은 아니다

Microsoft는 두 Copilot CLI 에이전트에게 React 데이터 테이블을 Angular 라이브러리로 옮기게 했다. 연구진은 정답 판정에 쓰이는 Playwright(웹 화면을 자동으로 조작해 검사하는 테스트 도구) 테스트 222개를 공개하지 않은 채, 실험을 18차례 반복했다.

이 테스트를 작업이 끝난 뒤에만 실행했을 때 결과물은 미완성이었다. 반대로 에이전트가 작업 도중에도 테스트 결과를 확인할 수 있게 하자 점수는 거의 만점까지 올랐다. 하지만 실제 산출물을 살펴보니 라이브러리가 제대로 작동하지 않거나, 아예 만들어지지 않은 경우도 있었다. 검증 도구가 있다고 해서 결과의 품질이 저절로 보장되는 것은 아니다. 산출물에 적합한 검증 방법을 고르고, 반드시 실행되도록 만드는 일은 컨트롤러의 책임이다.

자동 채점과 실제 품질 사이의 간극은 다른 연구에서도 드러났다. SWE-bench Verified를 통과한 PR 296건을 네 명의 메인테이너가 작성자를 가린 채 검토하자, 자동 채점에서는 약 60%였던 성공률이 실제 병합 기준에서는 36%로 떨어졌다. 사람이 작성한 정답 패치조차 병합률은 68%에 그쳤다. 저장소의 규약을 어긴 코드와 수정 대상이 아닌 기능의 손상이 주요 거부 사유였다. 테스트 통과가 증명하는 것은 어디까지나 해당 테스트를 통과했다는 사실뿐이다.

따라서 컨트롤러는 최종 결과만 보는 대신 작업 과정에서 나타나는 신호를 읽어야 한다. 같은 명령이 세 번 연속 실패하는지, 동일한 파일을 되풀이해 수정하는지, 비용만 늘고 변경 내용은 그대로인지 살펴보면 워커가 설명하지 않아도 문제를 감지할 수 있다. 컨트롤러의 역할은 이런 신호에 따라 작업 방향을 조정하고, 제약을 걸고, 필요하면 작업을 중단하는 것이다. 테스트를 통과하려고 단언문(assertion, 코드가 조건을 만족하는지 검사하는 문장)을 삭제하는 식의 편법 역시 검증 게이트와 변경량 제한을 함께 적용해야 막을 수 있다.

큰 모델보다 강한 통제 구조

핵심은 모델의 크기보다 실행을 통제하는 구조에 있다.

LoopArena에서는 실행 없이 계약만 선택하는 평가와 전체 과제를 직접 수행하는 평가가 거의 같은 순위를 보였다. 실행 일부만 측정한 결과도 전체 과제 결과와 매우 강한 상관관계를 나타냈다. 스피어만 상관계수는 0.9747이었다. 이는 코딩 능력과 별개로 에이전트의 실행을 통제하는 능력을 측정할 수 있다는 뜻이다. 실제로 우수한 컨트롤러는 평균 추론 비용을 64.4% 줄였다.

고정된 에이전트에 전략적 조언만 제공하는 소형 크리틱(에이전트의 행동을 평가해 조언하는 보조 모델)을 붙이자 해결률도 높아졌다. CWM-32B에서는 3.8%, Qwen3-32B에서는 5.2% 상승했다. 크리틱의 비용은 교사 모델의 92분의 1에 불과했다. CWM에서 학습한 크리틱을 Qwen에 적용했을 때도 두 설정에서 각각 3.0%와 3.4%의 개선이 이어졌다. 더 짧고 효율적인 실행 경로가 정확도와 비용을 동시에 개선한 것이다.

관측 정보의 품질도 중요하다. 긴 로그와 반복된 빌드 기록에 오류 메시지, 파일 경로, 테스트 이름이 뒤섞이면 핵심 증거가 묻힌다. 단계가 늘어날수록 토큰 비용은 제곱에 가깝게 증가할 수 있다. 반면 관측 정보를 압축하면 200B급 모델의 단계당 토큰 사용량을 약 10% 줄이면서도 TerminalBench 정확도를 1~4% 높일 수 있다.

따라서 완료 조건은 실행 가능한 계약으로 정의해야 한다. 상태 변경은 검증 게이트를 통과했을 때만 승인하고, diff 예산으로 수정 횟수를 제한하며, 실제 실행 결과를 판단의 근거로 삼아야 한다. 에이전트의 자기 보고에는 상태를 바꿀 권한을 주지 않아야 한다. 이런 통제 구조 없이 컨트롤러나 컨텍스트의 크기만 늘리면, 시스템은 검증되지 않은 보고를 다시 믿는 문제를 반복하게 된다.

출처

#에이전트 #언어모델