에이전트가 같은 실패를 반복하면 모델부터 바꿔야 할까요?
코딩 에이전트가 테스트 실패를 고쳤다가 다시 되돌립니다. 리서치 에이전트는 이미 확인한 자료를 또 찾고, 문서 에이전트는 앞에서 확정한 조건을 긴 작업 끝에 잊어버려요. 이런 장면이 반복되면 더 강한 모델을 붙이는 게 가장 빠른 해결책처럼 보입니다.
하지만 실패 원인이 지식이나 추론 능력이 아니라 작업 상태의 손실, 완료 판정의 부재, 실패 후 복구 규칙의 빈칸이라면 모델을 바꿔도 같은 문제가 남습니다. NVIDIA의 AVO 사례가 흥미로운 이유도 Claude Opus 5 자체보다, 모델이 긴 작업을 계속하도록 둘러싼 하네스가 전면에 등장했기 때문이에요.
다만 제목에 등장하는 약 30점과 100점을 단순한 전후 성적으로 읽어서는 안 됩니다. 두 실행은 하네스만 바꾼 통제 실험이 아니에요. 이번 사례에서 가져갈 것은 ‘70%포인트 상승’이라는 숫자가 아니라, 에이전트를 평가할 때 모델과 실행 시스템을 분리해 비교하는 방법입니다.
30점에서 100점으로 오른 통제 실험은 아닙니다
AVO는 새로운 언어 모델이 아니라 장기 자율 작업을 위한 에이전트 시스템입니다. 주 에이전트가 상황 조사, 계획, 구현, 평가를 반복하고, 영속 메모리는 이전 시도와 평가 결과를 다음 실행에 남깁니다. 별도의 감독자는 탐색이 정체되거나 비생산적인 반복에 빠졌을 때 개입합니다.
Claude Opus 5 기반 AVO는 ARC-AGI-3 공개 세트의 25개 환경, 183개 레벨을 모두 완료해 100.00 RHAE를 기록했습니다. 환경에 취한 행동은 6,624회였습니다. RHAE는 레벨 완료 여부와 첫 시도 인간 기준 대비 환경 행동 효율을 함께 반영합니다. 내부 추론이나 도구 호출은 환경 상태를 바꾸지 않는 한 행동 수에 포함되지 않아요.
NVIDIA가 함께 언급한 약 30%는 ARC Prize의 별도 Claude Opus 5 평가입니다. AVO 실행과는 추론 설정, 에이전트 시스템, 평가 구성이 달랐습니다. NVIDIA도 이 차이가 AVO만의 기여도를 직접 측정하지 않는다고 밝혔어요. 따라서 “하네스가 정확히 70%포인트를 만들었다”거나 “성능을 3.3배 높였다”고 계산할 수 없습니다.
100점은 AGI 달성이나 실무 성공률 100%를 뜻하지 않습니다.
결과는 문제가 공개된 세트에서 나왔습니다. ARC Prize 기술 보고서는 공개 환경에 맞춘 하네스가 과적합될 수 있어 공개 세트 점수를 AGI 진전의 유효한 측정으로 보지 않는다고 설명합니다. 동시에 이런 하네스 연구가 업무 자동화에는 경제적 가치가 있을 수 있다고 구분해 말합니다.
하네스가 관리하는 것은 답변이 아니라 작업의 연속성입니다
하네스의 역할은 모델에 긴 프롬프트를 씌우는 데 그치지 않습니다. 모델 호출 사이에서 무엇을 기억할지, 어떤 도구를 실행할지, 결과를 누가 판정할지, 실패했을 때 계속할지 중단할지를 관리합니다.
| 반복되는 실패 | 먼저 확인할 하네스 요소 | 비교할 기록 |
|---|---|---|
| 이미 한 조사나 수정을 다시 함 | 목표·확정 사실·이전 시도를 남기는 영속 상태 | 중복 도구 호출과 반복 실패 횟수 |
| 틀린 결과를 완료로 선언함 | 테스트·스키마·정적 분석 같은 외부 판정기 | 완료 선언 후 검증 실패율 |
| 실패 뒤 같은 전략만 반복함 | 실패 기록과 복구 정책 | 실패 후 복구율과 사람 개입 횟수 |
| 긴 실행에서 목표를 잃음 | 진척과 예산을 보는 감독 계층 | 목표 이탈, 중단 시점, 완료 건당 비용 |
다른 실험도 하네스 설정의 영향이 작지 않다는 점을 보여줍니다. OpenAI는 GPT-5.6 Sol이 공식 하네스에서 공개 세트 13.3%를 기록했지만, 추론 상태 유지와 컨텍스트 압축을 함께 적용한 Responses API 하네스에서는 38.3%를 기록했고 출력 토큰은 6분의 1로 줄었다고 보고했습니다. 두 설정을 동시에 적용했기 때문에 각각의 기여도는 분리할 수 없지만, 같은 모델도 실행 상태를 다루는 방식에 따라 결과와 비용이 달라질 수 있다는 사례입니다.
입력 표현에도 하나의 정답은 없었습니다. VISTA는 같은 Claude Opus 5에 512×512 렌더링 이미지와 다시 조회할 수 있는 원형 시각 메모리를 사용해 공개 25개 환경에서 100.00을 기록했습니다. 행동 수는 7,542회였습니다. AVO는 64×64 텍스트 그리드로 6,624회를 보고했지만, 백엔드와 메모리 구조가 달라 이 차이만으로 우열을 판단할 수 없습니다.
오늘은 실패 사례를 교정용과 보류용으로 나눠보세요
첫 행동은 멀티 에이전트 시스템을 새로 만드는 일이 아닙니다. 과거 실행 로그에서 재현 가능한 실패 사례를 모아 하네스를 수정하며 열어볼 교정용 묶음과 수정이 끝날 때까지 열어보지 않을 보류용 묶음으로 먼저 나누세요. 한 사례를 계속 고친 뒤 그 사례에서 다시 성공한 것은 일반화의 증거가 아닙니다. 공개·관찰된 환경에 맞춘 하네스가 처음 보는 환경으로 이전되지 않을 수 있다는 ARC Prize의 경고와 같은 문제예요.
- 업무와 판정 기준이 같은 사례 묶음을 만듭니다. 결제 버그 수정이라면 회귀 테스트 통과, 변경 파일 범위 준수, 중복 청구 0건처럼 모든 사례에 적용할 완료 조건을 정하세요. 하네스 설계에 사용할 교정용 사례와 마지막 평가에만 사용할 보류용 사례를 분리하고, 어떤 사례가 어느 묶음인지 기록합니다.
- 현재 구성을 교정용 묶음에서 기준선으로 실행합니다. 모델, 추론 설정, 입력, 도구 권한을 고정하세요. 시드나 온도처럼 변동을 통제할 수 있다면 같은 값으로 맞춥니다. 고정할 수 없다면 각 구성을 같은 사례에서 여러 번 실행해 한 번의 성공이나 실패가 결론을 좌우하지 않게 합니다.
- 분모가 보이는 기준선 표를 만듭니다. ‘완료율 60%’만 적지 말고 ‘10개 사례에서 6개 완료’ 또는 ‘5개 사례를 각 3회 실행해 15회 중 9회 완료’처럼 과제 수와 반복 횟수를 함께 남기세요. 반복 실패, 실패 후 복구, 사람 개입, 모델 호출량, 토큰, 실행시간과 비용도 같은 실행 단위로 기록합니다. ARC-AGI-3의 행동 효율에는 내부 추론과 도구 호출 비용이 모두 담기지 않으므로 실무 비용은 따로 재야 합니다.
- 영속 상태부터 하나씩 추가합니다. 목표, 확정 사실, 시도한 접근, 평가 결과와 남은 작업을 다음 실행에 전달한 뒤 같은 교정용 묶음을 동일 조건으로 다시 평가하세요. 이어서 외부 판정기, 실패 후 복구 정책, 감독 계층을 한 번에 하나씩 붙이고 직전 구성과 비교합니다.
- 구성을 확정한 뒤 보류용 묶음을 처음 엽니다. 교정용 사례에서 가장 나았던 구성을 더 손보지 않고 보류용 사례에 적용하세요. 기준선도 같은 보류용 묶음과 실행 조건에서 평가해 완료 건수, 복구 건수와 비용을 비교합니다. 보류 결과를 보고 다시 하네스를 수정했다면 그 사례는 이제 교정용이므로, 최종 확인에는 새로운 보류 묶음이 필요합니다.
- 마지막에 모델만 교체합니다. 확정한 하네스, 같은 사례 묶음, 같은 권한과 판정 기준을 유지한 채 모델을 바꾸세요. 그래야 모델 변경 효과와 하네스 변경 효과를 분리해 볼 수 있습니다.
교정용 작업 상태는 거창할 필요가 없습니다. 다음처럼 판정 가능한 정보와 데이터 분할부터 남길 수 있어요.
{
"task_id": "bugfix-017",
"split": "calibration",
"goal": "결제 실패 후 중복 청구 없이 재시도되도록 수정",
"expected_checks": [
"회귀 테스트 통과",
"변경 파일 범위 준수",
"중복 청구 0건"
],
"prior_attempts": [],
"budget": {"max_model_calls": 20}
}성공 기준에는 분모와 보류 결과가 필요합니다.
예를 들어 교정용 10개 사례를 각 3회 실행했다면 완료율과 복구율을 총 30회 중 몇 회인지 기록하세요. 한 가지 하네스 요소를 추가했을 때 그 비율이 좋아지고 반복 실패·사람 개입·완료 건당 토큰·시간·비용도 함께 나아졌는지 봅니다. 마지막으로 설계 과정에서 열어보지 않은 보류용 사례에서도 같은 방향의 변화가 나타나야 다음 업무로 확장할 근거가 생깁니다. 사례가 적다면 확정적인 개선률 대신 실행 건수와 관찰 결과를 그대로 보고하세요.
도구를 연결했다고 장기 작업이 안전해지는 것은 아닙니다
장기 작업의 오류는 한 번의 오답보다 누적된 상태 손상으로 나타날 수 있습니다. DELEGATE-52 연구는 52개 전문 분야의 장기 문서 편집에서 19개 LLM을 평가했고, 프런티어 모델도 작업 종료 시 문서 내용의 평균 25%를 손상시켰다고 보고했습니다. 도구 사용만 추가해서는 성능이 개선되지 않았고, 문서 크기와 상호작용 길이, 방해 파일이 늘수록 손상이 커졌습니다.
이 결과를 코딩이나 게임 에이전트의 오류율로 그대로 대입할 수는 없습니다. 대신 실무에서 확인할 경고는 분명해요. 도구 호출 성공과 업무 완료를 같은 것으로 취급하면 안 됩니다. 외부 판정기가 결과를 확인하고, 실패 상태가 다음 단계로 넘어가기 전에 복구하거나 중단할 수 있어야 합니다.
다음 에이전트 평가표에는 모델 이름만 적지 마세요. 사용한 메모리, 완료 판정기, 복구 정책, 감독 조건과 실행 예산을 함께 적어야 같은 시스템을 다시 비교할 수 있습니다. NVIDIA의 100점이 보여준 가장 실용적인 변화는 최고 모델을 고르는 법보다 평가 단위를 모델에서 전체 실행 시스템으로 넓힌 데 있습니다.
