3,100개 궤적으로 본 장기 에이전트의 붕괴 지점
짧은 작업을 잘하는 에이전트가 긴 작업도 비슷하게 잘할 거라고 기대하기 쉽다. 현실은 그렇게 매끈하지 않다. 한 단계의 작은 실수가 다음 단계의 전제가 되고, 초반에 받은 제약은 뒤로 밀리며, 마지막에는 실패 원인조차 찾기 어려운 궤적이 남는다.
HORIZON 논문은 이 문제를 웹 탐색, 운영체제, 데이터베이스, 로봇 조작이라는 네 영역에서 비교했다. 연구진은 700개가 넘는 과제에서 GPT-5-mini와 Claude-4-Sonnet 계열을 실행해 3,100개가 넘는 궤적을 모았다. 핵심은 단순히 "몇 번 행동했나"가 아니라, 과제를 끝내려면 원래 몇 번의 유효 행동과 몇 겹의 하위 목표가 필요한지를 따로 본 데 있다.
50번 움직였다고 긴 과제는 아니다
에이전트가 같은 실패를 50번 반복해도 과제 자체는 짧을 수 있다. 논문은 이를 구분하려고 두 척도를 쓴다. H*는 최적 정책이 과제를 끝내는 데 필요한 최소 유효 행동 수다. s는 중첩된 하위 목표나 조건 분기의 깊이다.
연구진은 s를 늘리는 두 방법을 사용했다. 깊이 확장은 건너뛸 수 없는 중간 절차를 추가한다. 폭 확장은 여러 독립 과제를 한 워크플로로 묶고 전환·검증·상태 추적 비용을 더한다. 이 구분 덕분에 에이전트가 헤매서 길어진 기록과, 애초에 긴 의존 사슬을 가진 과제를 섞지 않는다.
그림 1. HORIZON의 과제 길이 측정, 통제된 확장, 전이 구간 탐색, 일곱 실패 범주 진단 흐름. 하나의 보편 임계값을 주장하지 않는다. 출처: arxiv.org/html/2604.11978v1.
하나의 붕괴 숫자는 없었다
네 영역 모두 구성 깊이가 커질수록 성공률이 비선형으로 떨어졌다. 완만하게 낮아지다가 어느 구간에서 급격히 무너지는 모양이었다. 하지만 무너지는 위치는 같지 않았다. 웹과 로봇 조작은 작은 확장에도 빠르게 약해졌고, 운영체제와 데이터베이스는 이 실험에서 조금 더 긴 구간까지 버텼다.
따라서 "에이전트는 20단계부터 실패한다" 같은 보편 숫자는 만들 수 없다. 같은 s라도 화면 상태를 읽는 웹 작업, 셸 명령, SQL, 물리 조작은 관측 가능성과 행동 의미가 다르다. 논문이 말하는 붕괴 지점도 단일 임계값이 아니라, 성공률이 급락하고 복구 가능한 국소 오류가 궤적 전체의 탈선으로 바뀌는 전이 구간이다.
실패는 일곱 갈래로 겹쳤다
연구진은 실패를 환경, 지시 이해, 잘못된 가정, 계획 오류, 파국적 망각, 과거 오류 누적, 메모리 한계로 분류했다. 이 일곱 범주는 서로 배타적이지 않다. 한 궤적에서 초반 제약을 놓치고, 잘못된 상태를 사실로 가정한 뒤, 그 오류를 다음 행동들이 계속 증폭할 수 있다.
특히 긴 작업에서 두드러진 범주는 파국적 망각, 과거 오류 누적, 메모리 한계였다. 계획 오류도 치명적이다. 앞부분의 잘못된 하위 계획은 뒤의 모든 선택을 비싼 되돌리기로 만든다. 더 큰 모델 하나로 이 문제를 덮기 어렵다는 논문의 결론이 여기서 나온다.
LLM 판정기는 진단을 넓히지만 정답지는 아니다
수천 개 궤적을 사람이 전부 읽기 어렵기 때문에 연구진은 궤적 전체와 일곱 범주 정의를 LLM 판정기에 넣었다. 사람 두 명이 함께 분류한 40개 궤적에서 평가자 간 카파는 0.61이었다. 사람 한 명과 LLM 판정기의 일치는 0.84였다.
높은 일치는 자동 진단을 운영에 넣을 근거가 되지만, 40개는 작은 검증 표본이다. 판정기는 실패의 첫 지점과 근거 문장을 남기는 보조 장치로 쓰는 편이 안전하다. 점수 하나만 저장하면 왜 실패했는지 다시 확인할 길이 없다.
운영에서는 세 가지 장치를 먼저 넣을 만하다
첫째, 계획을 한 번 만든 뒤 끝까지 밀어붙이지 말고 단계 경계마다 전제와 실제 상태를 다시 확인한다. 둘째, 초반 제약을 일반 대화 기록에 묻지 말고 별도 체크리스트나 상태 객체로 보존해 매 단계 다시 띄운다. 셋째, 실패한 호출을 성공한 것으로 간주한 채 진행하지 않도록 도구 결과와 환경 변화를 명시적으로 확인한다.
여기에 복구 비용도 함께 재야 한다. 최종 성공률만 보면 중간에 열 번 헤맨 뒤 우연히 성공한 실행과, 네 단계로 안정적으로 끝난 실행이 같다. 실제 서비스라면 첫 오류 위치, 되돌리기 횟수, 제약 재검증 여부, 중간 상태의 신뢰도를 남겨야 한다.
이 결과를 읽을 때 남겨야 할 경계
이 논문은 심사 중인 v1 프리프린트다. 네 영역은 서로 다른 환경과 과제 구성법을 사용했고, 궤적을 독립적으로 재실행하거나 3,100개 전체를 사람이 다시 분류한 연구도 아니다. 공식 프로젝트 페이지는 계속 바뀔 수 있으므로, 이 글은 논문 v1의 "3,100개 이상"이라는 고정 표현을 기준으로 삼았다.
그래도 질문은 선명하다. 에이전트 평가에서 필요한 것은 더 긴 단일 점수가 아니라, 과제의 본래 길이와 구성 깊이를 통제한 뒤 어디서 계획·기억·상태 확인이 끊기는지 보는 일이다. 오래 일하는 에이전트를 만들려면 모델 교체보다 먼저 궤적을 되돌릴 수 있게 설계해야 한다.
참고 자료
이 글은 공개 논문과 공식 프로젝트 자료를 바탕으로 한 해설이다. 제품 사용 후기나 독립 재현 결과가 아니며, 원고 구성과 표현 정리에 AI 도구를 사용했다.
댓글
댓글 쓰기