AI 에이전트는 작업이 단순한지 아는가? 복잡도 인식형 추론·실행 (E3)

TL;DR Highlight

작업 범위를 먼저 추정하고 실패할 때만 넓혔더니 비용이 85% 줄었다

Who Should Read

코딩 에이전트가 한 줄 수정에도 파일을 전부 읽어 토큰과 시간이 낭비돼 고민인 에이전트 개발자

Core Mechanics

에이전트는 쉬운 일에도 다 읽는다
- 불확실하면 컨텍스트를 최대한 모으는 maximum-context-first 습관이 있다고 논문은 말한다.
- 두 줄짜리 아이콘 교체도 작은 코드 감사처럼 처리된다는 사례로 시작한다.
E3: 추정, 실행, 확장 순서
- 먼저 난이도·범위·위험·확신도를 가볍게 추정한다.
- 최소 경로(찾기→수정→검증)로 실행하고, 검증이 실패할 때만 범위를 한 단계씩 넓힌다.
추정은 낙관적이어도 된다
- 추정이 틀려도 확장 단계가 복구해 주는 안전망이다.
- 확장을 빼면 성공률이 85.1%로 떨어지고, 추정을 빼면 성공은 유지되지만 비용이 20% 오른다.
쉬운 작업일수록 낭비 비율이 크다
- 모든 파일을 읽는 방식은 쉬운 작업에서 최소 비용 대비 낭비 비율(ACRR)이 가장 크다.
- 논문도 이 경향이 부분적으로 수식상 당연한 결과라고 인정한다.
실제 gpt-4o에서는 효과가 훨씬 작다
- gpt-4o는 "전부 읽어라" 프롬프트에도 파일을 1~4개만 열었다.
- E3는 가장 적게 쓰고 가장 빨랐지만 차이는 작고 작업별로 들쭉날쭉했다.

Evidence

시뮬레이터에서 비용 85% 절감
- MSE-Bench 121개 작업에서 Max-Context-First 대비 비용 84.9%, 토큰 90.9%, 검사 파일 92.2% 감소했고 성공률은 둘 다 100%다.
- 평균 비용은 122.85에서 18.55로 줄었다.
강한 적응형 베이스라인 대비
- Adaptive Retrieval 대비 비용 16.0%, 검사 파일 66.8% 감소했고 성공률은 같은 100%다.
- 대신 툴 호출은 약 14% 더 썼다.
Fixed ReAct는 싸지만 불안정
- 성공률이 66.9%이고 Level 3를 전부 실패한다.
- 인덱스 import를 따라가지 않아 간접 수정 위치에 닿지 못한다.
표현을 바꿔도 성공률 유지
- 지시문을 어휘가 겹치지 않게 바꾸자 추정 정확도가 85.1%에서 66.9%로 떨어졌다.
- E3 성공률은 100%를 유지했고 비용은 18.55에서 20.17로 8.7%만 올랐다.
gpt-4o 실험 결과
- toml 라이브러리로 5개 작업을 3회씩 실행했을 때 E3는 thorough 에이전트보다 토큰 18%, 지연 18% 적었고 ReAct보다는 토큰 4%, 지연 5% 적었다.
- 성공률은 thorough 80%, ReAct 100%, E3 93%다.

How to Apply

에이전트 시스템 프롬프트에 추정 단계 추가하기
- 오늘 코딩 에이전트 프롬프트에 "먼저 범위·난이도·위험을 추정하고 최소 경로로 시작하라"를 넣어라.
- 같은 작업 몇 개로 토큰 수와 열어 본 파일 수를 전후 비교하라.
검증 실패 시에만 범위 확장하게 만들기
- 테스트나 린트 실패를 확장 트리거로 삼아 파일 수준을 한 단계씩 올리게 하라.
- 확장 횟수 상한 K를 정하고, 이전 검색 결과는 재사용하게 하라.
작업별 낭비 지표 측정하기
- 작업마다 최소 필요 토큰을 기준으로 실제 토큰과 열어 본 파일 수를 로깅하라.
- 쉬운 작업에서 낭비 비율이 큰지 확인하라.
간접 의존 작업은 확장 경로 열어두기
- 별칭이나 re-export처럼 grep으로 안 잡히는 의존성이 있는 저장소에서는 import 추적 단계를 확장 레벨에 포함하라.
- 추정 단계에서는 이를 놓쳐도 확장에서 복구되게 하라.

Try It

복사해서 바로 해보기

# Claude Code 또는 ChatGPT 시스템 프롬프트/첫 지시에 붙여넣기 (논문 E3 방법의 간이 버전)

너는 코딩 에이전트다. 아래 순서로 일하라.
1. Estimate: 작업을 읽고 난이도(1~3), 수정할 파일 범위, 위험, 확신도를 한 줄로 적어라. 파일을 전부 읽지 마라.
2. Execute: 가장 작은 경로로 시작하라. 키워드를 검색해 해당 위치만 열고 수정한 뒤 테스트로 검증하라.
3. Expand: 검증이 실패하거나 확신도가 낮을 때만 범위를 한 단계 넓혀라. 직접 수정 위치를 모두 보고, 그래도 안 되면 import와 re-export를 따라가라. 이전에 찾은 검색 결과는 재사용하라. 확장은 최대 {{최대확장횟수 예: 3}}번까지 한다.

작업: {{수정 지시}}
저장소 경로: {{경로}}

이어서 해 볼 것: 같은 작업을 "먼저 전부 읽어라" 프롬프트로도 돌려서 토큰 수와 열어 본 파일 수를 비교해 보라.

Terminology

ACRRAgent Cognitive Redundancy Ratio. 실제 비용이 오라클 최소 비용을 얼마나 초과했는지 나타내는 비율이다. 0이면 낭비가 없고, 4면 필요한 비용의 5배를 쓴 것이다.

Maximum-context-first불확실하면 일단 컨텍스트를 최대한 모은 뒤 행동하는 방식이다. 이사 전에 집 안 모든 물건을 꺼내 보는 것과 같다.

Initial operating point정답은 아니지만 탐색을 짧고 안정적으로 만들어 주는 출발점 추정이다. 내비게이션이 먼저 대략의 경로를 잡는 것과 비슷하다.

Oracle작업에 필요한 최소 경로를 미리 알고 있는 기준선이다. 정답지를 가진 채점자와 같다.

MSE-Bench논문이 만든 121개 편집 작업의 결정적·오프라인 벤치마크다. 작업마다 최소 필요 경로가 정해져 있다.

Related Resources

Original Abstract (Expand)

Large language model (LLM) agents increasingly automate multi-step engineering and informatics workflows, yet they rarely ask how much effort a task actually requires. They often follow a maximum-context-first strategy--re-reading files and dependencies they have already seen--turning a one-line edit into a small code-base audit. We argue the missing capability is task-aware execution-scope estimation: judging a task's difficulty, the information it truly needs, and the shortest reliable path before committing budget. We formalize minimum-sufficient execution and the Agent Cognitive Redundancy Ratio (ACRR), and propose E3 (Estimate, Execute, Expand): the agent estimates an initial operating point, executes a minimum viable path, and expands scope only when verification fails. On MSE-Bench--a deterministic benchmark of 121 edits in a capability-controlled simulator--E3 matches the strongest baseline's 100% success while cutting cost by 85%, tokens by 91%, and inspected files by 92%, and further beats a strong adaptive retrieval baseline by 16%; the gains survive held-out instruction wording and essentially every cost weighting. A companion real-model harness (LLM-Case) corroborates the effect on a live gpt-4o agent editing a real open-source library, with every candidate patch graded by actually running the project's real pytest suite against a measured oracle: the over-reading is milder but real, and E3 is the leanest and fastest policy at comparable task success--its one shortfall a provider rate-limit, not a wrong edit. We frame this as a controlled probe of execution redundancy, not a measurement of any deployed agent, and position task-aware execution as a step toward engineering-grounded AI (EGAI)--agents whose effort is anchored in the engineering reality of the task. We release the framework and benchmark.