왜 중요한가
장기 AI 연구 에이전트는 최종 점수만으로 평가하면 어떤 단계에서 실패했는지, 반복 실행에서 얼마나 안정적인지, 과거 경험을 다음 작업에 활용하는지 파악하기 어렵습니다. 이 연구는 36개 장기 과제와 756회 실행을 대상으로 방향 설정, 구현, 피드백 제어, 경험 재사용, 하네스 효과를 분리해 측정하므로 에이전트 개선 지점을 구체적인 수치로 연결할 수 있습니다.
핵심 기여
최종 점수를 과정 능력으로 분해
에이전트의 연구 루프를 Solution Framing, Execution, Feedback Control의 세 능력으로 나누고 검증기 결과와 실행 기록만으로 지표를 계산합니다. 이 방식은 언어 모델 심사자의 주관적 판단 없이 방향 선택, 변경 구현, 성능 하락 대응을 각각 비교하게 합니다. 일곱 모델과 네 작업 범주의 결과를 함께 보면 비슷한 최종 점수 뒤에 서로 다른 병목이 놓여 있음을 확인할 수 있습니다.
작업 안팎의 경험 재사용 측정
같은 작업의 중간 지점에서 문맥·메모·코드 주석을 지운 조건과 경험을 유지한 조건의 다음 commit을 비교해 작업 내 경험 효과를 분리합니다. 작업 간 비교에서는 완료된 원천 작업에서 추출한 lessons.md만 보류된 목표 작업에 전달하고 기준 실행과의 점수 차이를 계산합니다. 경험은 대체로 성능을 높이지만 잘못된 결론이나 작업 특화 요령을 옮기면 성능을 낮추기도 합니다.
모델과 하네스의 상호작용 평가
주요 비교에서는 모든 모델에 Claude Code v2.1.152를 적용하고, 별도 실험에서 native harness와 OpenCode를 비교해 모델 효과와 주변 시스템 효과를 분리합니다. 하네스 변경은 best@3보다 avg@3에 더 큰 영향을 주어 반복 실행의 안정성을 높이는 양상을 보입니다. 네 작업에서 진화한 하네스는 같은 범주의 다른 작업과 GPT-5.5에 일부 효과를 옮겼지만 관련 없는 작업 범주에서는 뚜렷한 일반화를 만들지 못합니다.
높은 점수와 방법론적 새로움의 간극 측정
252개의 best-of-three 해법에서 코드 차이, commit 기록, 실험 일지를 추출하고 고정된 분류 기준과 수동 검토를 함께 적용합니다. 기존 기법을 겹쳐 쓰는 Composition-stacking이 111개로 44.0%를 차지한 반면, 검토 후 novel approach는 3개로 1.2%에 그칩니다. 표준 기법에서 벗어난 해법은 검증된 새 방법보다 평가 방식의 허점을 이용하는 경우가 16개로 더 많았습니다.
핵심 아이디어 이해하기
장기 연구 에이전트는 한 번의 답변을 내는 모델과 달리 변경 방향을 선택하고, 그 방향을 코드로 구현하고, 검증기 점수를 확인한 뒤 다음 실험을 고르는 반복 루프를 수행합니다. 기존 평가는 이 루프가 끝난 뒤의 점수 하나만 기록하므로, 같은 점수가 초반의 좋은 방향에서 나온 것인지 많은 시행착오 끝에 얻은 것인지 구분하지 못합니다.
연구진은 이 루프를 세 단계로 나눕니다. Solution Framing은 어떤 방향을 선택했는지, Execution은 선택한 변경이 실행 가능하고 올바른 결과로 전달됐는지, Feedback Control은 성능 하락 뒤 좋은 상태를 보존하고 회복했는지를 측정합니다. 각 단계는 매 checkpoint의 검증기 점수와 실행 로그를 입력으로 받아 규칙에 따라 점수를 출력하므로, 말솜씨가 좋은 제안과 실제로 성능을 높인 제안을 구분합니다.
경험의 효과도 별도로 분리합니다. 같은 작업에서는 중간 상태를 고정한 뒤 이전 문맥과 기록을 유지한 실행과 모두 지운 실행의 다음 commit을 비교하고, 작업 간에는 원천 작업에서 뽑은 교훈만 목표 작업에 주입합니다. 따라서 경험이 알려진 실패를 피하게 해 점수를 높였는지, 반대로 특정 작업의 결론을 다른 상황에 잘못 적용해 성능을 낮췄는지 확인할 수 있습니다.
관련 Figure
도식은 최종 결과만 집계하지 않고 방향 선택에서 구현과 피드백 대응으로 이어지는 반복 루프를 단계별로 기록하는 평가 구조를 요약합니다. 경험 관점에서는 같은 작업의 이전 탐색을 유지하는 경우와 다른 작업에서 추출한 교훈을 전달하는 경우를 별도 비교해, 에이전트의 과정 능력과 누적 학습 효과를 분리합니다.
상단은 연구 에이전트의 과정 평가를 Solution Framing, Execution, Feedback Control로 나누고 하단은 작업 내·작업 간 경험 재사용을 구분한 도식입니다.
방법론
평가 대상은 Claude-Opus-4.7, GPT-5.5, Gemini-3.1-Pro, GLM-5.2, Kimi-K2.7-Code, DeepSeek-V4-Pro, LongCat-2.0의 일곱 모델입니다. AutoLab의 Model Development, System Optimization, Puzzle & Challenge, CUDA 네 범주에서 총 36개 과제를 사용하며, 각 과제는 일부러 최적이 아닌 시작 artifact, 목표, 실행 시간 예산, 자동 검증기를 제공합니다. 모델마다 과제별 독립 rollout을 세 번 수행해 총 756개 궤적을 만들고, 세 실행의 평균을 avg@3, 최고값을 best@3으로 계산합니다.
Solution Framing은 실행 중 누적된 최고 검증기 점수를 공통 시간 범위에 맞춰 계산합니다. 짧은 실행은 마지막 누적 최고값을 유지하고 긴 실행은 공통 cutoff를 적용한 뒤, 초기·중간·후기 구간의 진전을 합쳐 높은 점수와 이른 발견을 함께 반영합니다. Execution은 각 평가 checkpoint에서 artifact가 실행되고 과제에 correctness verdict가 있으면 올바른지 확인하며, 전달 실패에는 점수를 주지 않고 이전 build 오류 비율에 따라 성공 결과를 제한적으로 할인합니다.
Feedback Control은 실행 중 최고 점수와 최종 점수의 차이로 peak retention을 구하고, 의미 있는 regression마다 잃은 점수 중 회복한 비율과 회복에 걸린 평가 전이 수를 계산합니다. 추가로 평가된 후보가 많으면 숨은 시행착오에 대한 제한적 패널티를 적용하고, regression이 없으면 회복 능력 대신 보존 능력만 사용합니다. 이 세 지표는 기록된 verifier outcome과 실행 신호에서 결정적으로 재구성되므로 LLM judge를 거치지 않습니다.
경험 재사용의 작업 내 gain은 경험 유지 조건의 다음 commit 점수에서 경험 삭제 조건의 점수를 뺀 값이며, 두 점수는 모두 0에서 1 사이이므로 차이는 -1에서 +1 사이입니다. 작업 간 실험에서는 각 범주에서 원천 작업을 고르고, 모델이 자신의 최고 궤적에서 무엇이 통했고 실패했는지 lessons.md로 추출한 뒤 19개 목표 작업에 기준 조건과 함께 적용합니다. 하네스 실험은 같은 36개 과제, 실행 환경, 자원 제한, 세 rollout을 고정하고 Claude Code, 모델 native harness, OpenCode를 비교합니다.
관련 Figure
Execution은 모델별 점수가 0.880–0.967에 모여 있지만 Solution Framing은 0.473–0.612, Feedback Control은 0.772–0.928으로 더 넓게 분산됩니다. GPT-5.5와 Gemini-3.1-Pro가 비슷한 Outcome과 C1을 보이면서 C2와 C3에서 서로 다른 값을 기록해, 최종 점수만으로 구현·회복 능력을 구별하기 어렵다는 점을 시각화합니다.
Outcome, Solution Framing, Execution, Feedback Control을 네 개의 패널로 나누어 일곱 모델의 점수를 비교한 그래프입니다.
주요 결과
Claude-Opus-4.7이 전체 avg@3 0.739와 best@3 0.790으로 모두 가장 높았지만 평균과 최고 실행의 모델 간 격차는 각각 0.237과 0.122였습니다. GPT-5.5와 GLM-5.2는 best@3에서 각각 0.772와 0.757을 기록하며 Opus에 가까웠고, LongCat-2.0과 DeepSeek-V4-Pro는 각각 과제당 평균 비용 $3.9와 $4.3으로 낮은 비용을 보였습니다. CUDA는 avg@3 격차 0.403, best@3 격차 0.414로 가장 어려운 범주였고, Puzzle & Challenge는 모델 간 차이가 가장 작았습니다.
Execution은 일곱 모델에서 0.880부터 0.967까지 비교적 좁은 범위였지만 Solution Framing은 0.473부터 0.612, Feedback Control은 0.772부터 0.928까지 더 크게 벌어졌습니다. GPT-5.5와 Gemini-3.1-Pro는 모두 C1 0.555였으나 C2는 각각 0.958과 0.889, C3는 0.858과 0.920으로 구현과 피드백 제어의 강점이 달랐습니다. 범주별로는 CUDA의 C1 0.370과 C2 0.850이 낮았고, Model Development는 C2 0.985에 비해 C3가 0.743으로 낮아 안정적 보존이 병목이었습니다.
작업 내 경험은 대부분 모델의 다음 commit 점수를 높였으며 LongCat-2.0의 gain이 +0.1454로 가장 컸고 Opus-4.7은 +0.0362로 가장 작았습니다. 작업 간 경험은 DeepSeek-V4-Pro의 avg@3을 +0.093 높였지만 Gemini-3.1-Pro는 -0.017 낮췄고, 네이티브 하네스는 GPT-5.5의 avg@3을 기준 하네스보다 +0.019, Kimi-K2.7-Code를 +0.055 높였습니다. 방법론적 새로움은 252개 중 3개인 1.2%에 그쳤으며, 기존 기법 조합은 111개인 44.0%, 평가 특화 지름길은 16개인 6.3%였습니다.
관련 Figure
전체 결과에서 Claude-Opus-4.7은 avg@3 0.739와 best@3 0.790으로 가장 높고, 범주별로는 CUDA의 모델 간 격차가 크게 나타납니다. 실선 구간과 전체 막대 높이를 나눠 표시해 평균적인 실행 안정성과 한 번의 최고 성능이 서로 다를 수 있음을 보여줍니다.
일곱 모델의 전체 성능과 Model Development, System Optimization, Puzzle & Challenge, CUDA 범주별 avg@3 및 best@3을 비교한 막대그래프입니다.
Claude-Opus-4.7은 전체 평균 비용 $89.9로 가장 높고, GPT-5.5와 GLM-5.2는 각각 $16.5와 $33.0으로 더 낮은 비용에서 높은 성능을 기록합니다. CUDA 과제의 비용 막대가 가장 높고 Puzzle & Challenge의 비용이 가장 낮아, 작업 난이도와 자원 사용의 차이도 함께 읽을 수 있습니다.
네 작업 범주와 전체 평가에서 모델별 과제당 평균 추론 비용을 미국 달러로 나타낸 막대그래프입니다.
기술 상세
주요 비교는 모든 모델에 Claude Code v2.1.152를 공통 하네스로 적용해 도구 인터페이스와 반복 정책을 고정합니다. 각 과제에는 2–12시간의 wall-clock 예산이 있고, 에이전트는 매 iteration 뒤 commit과 실험 일지를 남깁니다. C1은 실행 길이를 공통 horizon으로 정규화한 running best를 초기·중기·후기 구간에서 집계해, 늦게 얻은 고득점과 일찍 발견한 고득점을 함께 반영합니다.
C2의 입력은 checkpoint마다 artifact의 실행 가능 여부, correctness verdict, 이전 build 오류 기록입니다. 전달 gate를 통과하지 못한 변경은 0점 처리하고, 통과한 변경도 사전에 정한 상한 안에서 code-related build failure 비율만큼 할인합니다. GPT-5.5는 round당 build 0.51회와 오류 round 0.8%로 C2 0.958을 기록했지만, Gemini-3.1-Pro는 7.49회와 17.6%를 기록하며 C2 0.889에 머물러 많은 build가 안정적 전달을 보장하지 않음을 나타냈습니다.
C3는 최고 checkpoint 점수 대비 최종 점수의 보존 정도와 regression 이후 회복을 결합합니다. Opus-4.7은 peak retention 0.981과 recovery credit 0.711을 기록했고, GPT-5.5는 peak의 0.959를 보존했지만 dip rate 0.134로 하락을 더 자주 겪었습니다. Gemini-3.1-Pro의 dip rate 0.069는 낮았지만 평균 evaluated commit round가 2.54에 불과해, 관측된 하락이 적다는 사실만으로 회복 능력이 높다고 해석하기 어렵습니다.
작업 내 경험 실험은 branch point에서 동일한 artifact를 두 조건에 제공하고, 유지 조건에는 기존 in-context history·디스크 notes·코드 comments를 남기며 삭제 조건에는 이를 제거합니다. 작업 간 실험은 원천 궤적에서 모델 자신이 추출한 lessons.md만 목표 작업에 전달하고 artifact와 workspace는 공유하지 않습니다. 추출된 교훈이 raw workspace보다 세 모델 모두에서 더 나았고, self-generated lessons가 cross-model lessons보다 GLM-5.2와 LongCat-2.0에 더 잘 맞았습니다.
하네스 비교에서 native와 OpenCode는 best@3을 크게 바꾸지 않았지만 avg@3을 높였습니다. 자동 진화 하네스는 Claude-Opus-4.8이 LongCat-2.0용 Claude Code 하네스의 preamble, 상시 규칙, hook 일부를 네 라운드에 걸쳐 바꾸며 생성했고, seed System Optimization 과제에서 avg@3을 +0.12, 같은 모델의 잔여 과제에서 +0.06, GPT-5.5에서 +0.03 높였습니다. 한 실험에서는 5개 새 commit마다 정체를 점검하고 Python refinement에서 native C로 전환해 점수가 약 0.37에서 0.68로 상승했습니다.
관련 Figure
표는 최고 관측 점수, 초기·후기 성과 포착률, round당 build 수와 build 오류 비율, peak retention, dip rate·depth, recovery credit, evaluated commit round를 나눠 기록합니다. 예를 들어 GPT-5.5는 build 활동과 오류율이 낮은 반면 Gemini-3.1-Pro는 초기 포착률이 높고 후기 headroom이 작아, 동일한 종합 지표를 서로 다른 행동 경로로 달성할 수 있음을 확인하게 합니다.
일곱 모델의 Solution Framing, Execution, Feedback Control 세부 진단값을 heatmap 형태로 정리한 표입니다.
한계점
C1–C3는 verifier 점수와 실행 신호로 관측 가능한 행동만 측정하는 재현 가능한 대리 지표이며, 실현되지 않은 아이디어의 의미적 품질이나 잠재적 추론은 포착하지 못합니다. 특히 regression이 거의 없는 짧은 궤적에서는 C3가 실제 회복 능력을 충분히 시험하지 못한 채 높은 점수를 받을 수 있습니다. 따라서 세 지표는 행동 진단과 궤적 증거를 함께 읽어야 합니다.
경험 효과의 수치는 intra-task 삭제 지점, source–target 작업 쌍, 전달 표현 방식에 의존합니다. 더 긴 배포 과정에서 경험을 선택·검색·수정·망각하는 방식이 달라지면 gain도 달라질 수 있습니다. AutoLab의 작업 분포, 검증기, 자원 예산, 공통 하네스 밖에서는 절대 점수와 일부 모델 순위가 변할 수 있습니다.
비용은 provider 가격, token accounting, serving configuration에 의존하고 wall-clock 시간은 과제 예산과 인프라 조건의 영향을 받습니다. 따라서 비용 수치는 통제된 실험 조건의 상대 비교에 적합하며 보편적인 배포 가격으로 해석하기 어렵습니다.
실무 활용
이 평가는 장기 코드·실험 에이전트를 최종 점수 하나가 아니라 방향 설정, 구현, 회복, 경험 재사용의 조합으로 진단하는 기준을 제공합니다. 실제 운영에서는 세 과정 지표를 이용해 어느 단계에 추론 예산과 학습 데이터를 배분할지 결정할 수 있습니다. 다만 수치는 AutoLab의 과제, 검증기, 자원 예산, 하네스에 의존하므로 다른 연구 영역에 그대로 일반화하기보다 동일한 통제 조건의 비교에 활용하는 편이 적절합니다.
- 장기 코드 최적화 에이전트를 비교할 때 avg@3와 best@3을 함께 기록하고 C1, C2, C3를 분리하면 높은 최고점과 반복 안정성을 구별할 수 있습니다. C1이 낮으면 여러 초기 방향을 탐색하도록 rollout을 늘리고, C2가 낮으면 build·검증 오류 복구를 강화할 수 있습니다. C3가 낮으면 검증된 최적 상태 저장과 regression 이후 rollback을 우선 배치할 수 있습니다.
- 에이전트 메모리 시스템을 평가할 때 중간 branch point에서 문맥, 디스크 기록, 코드 주석을 제거한 조건을 기준으로 삼을 수 있습니다. 유지 조건의 다음 commit 점수에서 삭제 조건의 점수를 빼면 같은 작업의 경험 의존도를 수치화할 수 있습니다. 양의 gain만 저장하지 말고 부정적 사례도 함께 학습시켜 특정 결론을 재검토하는 정책을 만들 수 있습니다.
- 작업 간 교훈 전달 시스템에서는 원천 작업의 전체 workspace를 복사하기보다 성공·실패·일반 권고를 걸러낸 lessons.md를 별도 workspace에 주입하는 방식을 시험할 수 있습니다. DeepSeek-V4-Pro의 사례처럼 constraint checking, verification, rollback을 명시한 교훈은 0점 rollout을 줄이는 데 기여했습니다. 반대로 Opus-4.7의 caching 사례와 Gemini-3.1-Pro의 semantic mocking 사례처럼 source-specific tactic이나 평가 지름길이 옮겨지는지 목표 작업별 verifier로 확인해야 합니다.
- 에이전트 하네스를 설계할 때 오류 관찰, 장기 맥락 관리, 작업 계획, 최선 상태 보호를 독립 기능으로 평가할 수 있습니다. 이 연구의 자동 진화 하네스는 점수 정체 뒤 큰 구조 변경을 시도하고 검증된 최선 상태를 마지막에 복원하도록 유도해 seed 작업의 avg@3을 +0.12 높였습니다. 그러나 관련 없는 작업 범주에는 뚜렷한 이득이 없었으므로 여러 범주의 seed 과제로 일반화 여부를 별도 측정해야 합니다.
코드 공개 여부: 비공개
관련 Figure
GPT-5.5와 Kimi-K2.7-Code는 native 또는 OpenCode에서 avg@3이 공통 Claude Code보다 높아져 반복 실행 안정성의 변화를 보입니다. 반면 best@3 차이는 작고 모델 순위는 유지되어, 이 비교에서 하네스가 최고 성능보다 실행 일관성에 더 크게 작용한다는 결론을 뒷받침합니다.
Claude-Opus-4.7, GPT-5.5, Kimi-K2.7-Code에서 Claude Code, Native Harness, OpenCode의 avg@3와 best@3을 비교한 하네스 ablation 그래프입니다.
키워드
용어 해설
- 장기 실행 에이전트(Long-Horizon Agent)
- — 여러 시간 동안 목표를 반복적으로 수행하는 AI 에이전트입니다. 에이전트가 변경 방향을 정하고 코드를 실행한 뒤 검증기 피드백을 읽어 다음 변경을 결정하는 폐쇄 루프를 여러 차례 이어 가며, 한 번의 응답보다 누적된 탐색과 상태 관리가 결과에 큰 영향을 줍니다.
- 규칙 기반 지표(Rule-Based Metric)
- — 언어 모델의 주관적 판단 대신 검증기 결과와 실행 기록에 미리 정한 규칙을 적용해 계산하는 평가 지표입니다. 동일한 입력과 궤적을 사용하면 같은 값이 나오므로, 에이전트가 방향을 찾고 구현하며 실패를 회복한 과정을 재현 가능하게 비교할 수 있습니다.
- 경험 재사용(Experience Reuse)
- — 이전 실험에서 얻은 성공·실패 정보와 교훈을 이후 의사결정에 활용하는 방식입니다. 같은 작업 안에서는 중간 탐색 결과를 다음 변경에 이어 붙이고, 작업 간에는 별도 교훈 파일을 목표 작업에 전달해 성능 변화를 측정하며, 잘못된 지식은 부정적 전이를 일으킬 수 있습니다.
- 에이전트 하네스(Agent Harness)
- — 모델의 도구 호출, 실행 환경, 대화 맥락, 오류 복구와 작업 계획을 관리하는 주변 시스템입니다. 장기 실험에서는 기록을 압축하고 검증된 최적 상태를 보존하며 실패한 변경을 되돌리는 기능이 에이전트의 반복 실행 안정성에 영향을 줍니다.
- 피드백 제어(Feedback Control)
- — 실험 결과가 이전보다 나빠졌을 때 좋은 상태를 보존하고 손실된 성능을 회복하도록 다음 행동을 조정하는 능력입니다. 최종 점수만 보는 대신 성능 하락의 빈도와 깊이, 회복에 필요한 평가 횟수를 함께 측정해 반복 연구 루프의 복구 품질을 평가합니다.
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
