에이전트도 쉬운 일을 쉬운 일로 알아야 한다

제일 먼저 든 생각

좋은 에이전트는 어려운 일을 푸는 능력만으로 평가되기 쉽다. 그런데 실제 업무 자동화에서 더 자주 부딪히는 문제는 반대다. 쉬운 일을 쉬운 일로 처리하지 못한다. 이미 본 파일을 다시 읽고, 필요 없는 의존성을 확인하고, 한 줄 수정에 작은 코드베이스 감사를 붙인다. 결과는 맞지만 경로가 너무 비싸다.

이 논문은 그 답답함에 이름을 붙인다. LLM 에이전트가 과도하게 문맥을 모으는 문제를 실행 중복(execution redundancy)으로 보고, 작업을 시작하기 전에 난이도와 필요한 정보 범위를 추정하는 능력이 필요하다고 주장한다.

핵심은 더 많이 생각하는 에이전트가 아니라, 먼저 얼마나 생각해야 하는지 가늠하는 에이전트다.

‘맥락을 많이 읽는 것’은 항상 신중함이 아니다

논문의 출발점은 아주 실무적이다. 에이전트가 이미 여러 번 다룬 프로젝트에서 간단한 아이콘 교체를 요청받았다고 하자. 필요한 것은 기존 마크업을 찾아 같은 방식으로 바꾸는 일이다. 하지만 에이전트는 디렉터리를 다시 훑고, 라이브러리를 확인하고, 구조를 다시 분석한 뒤에야 두 줄을 고친다.

저자들은 이것을 지식 부족이나 검색 실패로 보지 않는다.

“이 행동은 지식이나 검색의 실패도, 단순히 기억의 문제도 아니다.”

“This behavior is not a failure of knowledge or of retrieval, nor merely of memory.”

문제는 작업 난이도 판단이다. 지금 필요한 정보가 무엇인지, 이미 본 정보 중 무엇이 무관한지, 검증 가능한 최소 경로가 무엇인지 빠르게 정하지 못하면 에이전트는 안전해 보이는 최대문맥 우선(maximum-context-first) 전략으로 기운다.

E3: 추정하고, 실행하고, 실패하면 넓힌다

논문이 제안하는 E3는 Estimate, Execute, Expand의 약자다.

1. Estimate: 작업 난이도, 필요한 범위, 예상 위험, 초기 실행 지점을 추정한다.
2. Execute: 최소 충분 경로(minimum-sufficient execution)로 먼저 해결한다.
3. Expand: 검증이 실패할 때만 범위를 넓힌다.

이 방식은 “대충 하자”가 아니다. 오히려 검증을 전제로 한 절약이다. 작은 수정은 작은 경로로 처리하고, 실패 신호가 있을 때만 검색과 분석을 확장한다. 사람 엔지니어가 자주 하는 방식과 비슷하다. 먼저 눈앞의 수정 지점을 확인하고 테스트를 돌린다. 안 되면 그때 주변 구조를 넓게 본다.

논문은 MSE-Bench라는 121개 수정 작업 벤치마크와 실제 오픈소스 라이브러리에서의 LLM-Case 하네스를 통해 이 접근을 평가했다. 초록 기준으로 E3는 가장 강한 기준선과 같은 100% 성공률을 보이면서 비용 85%, 토큰 91%, 검사 파일 92%를 줄였다고 보고한다. 실제 모델 하네스에서도 과독해(over-reading)는 더 약하지만 여전히 관찰됐고, E3가 비슷한 성공 조건에서 가장 가볍고 빠른 정책이었다고 설명한다.

물론 이 수치는 논문이 설정한 시뮬레이터와 작업 조건 안에서 읽어야 한다. 모든 업무 에이전트에 그대로 일반화할 결과라기보다, “실행 범위 추정”이라는 평가 축을 선명하게 보여준 결과에 가깝다.

원문 첫 페이지. 에이전트의 성능을 정답률뿐 아니라 실행 중복과 비용으로 함께 보려는 논문이다.

자동화 설계에서 바로 써먹을 수 있는 관점

Deciflow 업무 자동화로 가져오면 이 논문은 에이전트 프롬프트보다 운영 규칙 쪽에 가깝다. “항상 충분히 조사하라”는 지시가 안전해 보이지만, 반복 업무에서는 낭비를 만든다. 반대로 “빨리 처리하라”만 넣으면 위험한 생략이 생긴다.

그래서 에이전트 실행 전에 이런 작은 분류가 필요하다.

• 단순 수정: 파일 위치가 분명하고 검증 방법이 있는 작업. 최소 탐색 후 바로 수정한다.
• 중간 작업: 영향 범위가 2~3개 모듈에 걸릴 수 있는 작업. 관련 파일만 읽고 검증한다.
• 복합 작업: 아키텍처, 데이터, 배포 영향이 있는 작업. 처음부터 넓게 본다.

핵심은 작업 유형마다 읽을 수 있는 파일 수, 검색 횟수, 검증 방식의 기본값을 다르게 두는 것이다. 에이전트에게 “자율적으로 잘해봐”라고 맡기는 대신, 쉬운 일의 예산을 작게 잡고 실패했을 때만 넓히게 만든다.

평가 지표도 바뀌어야 한다

이 논문이 제안하는 Agent Cognitive Redundancy Ratio(ACRR)는 에이전트가 필요한 최소 실행 비용 대비 얼마나 더 썼는지를 보려는 지표다. 실제 현장에서는 논문식 지표를 그대로 쓰기 어렵더라도 비슷한 관찰은 가능하다.

예를 들어 자동화 로그에 다음을 남길 수 있다.

• 수정 전 읽은 파일 수
• 검색·도구 호출 횟수
• 작업 시작부터 첫 수정까지 걸린 시간
• 검증 실패 후 확장한 범위
• 최종 성공 여부와 재작업 여부

정답률만 보면 과하게 읽는 에이전트가 좋아 보일 수 있다. 하지만 직원들이 실제로 쓰는 자동화에서는 대기 시간, 토큰 비용, 불필요한 변경 위험도 성능이다. 쉬운 일을 빨리 끝내는 능력은 사소한 최적화가 아니라 채택률의 문제다.

오늘 남길 질문

우리 에이전트 워크플로에는 ‘이 일은 쉬운가’를 먼저 판단하는 단계가 있는가?

없다면 다음 실험부터 해볼 만하다. 반복 업무 20개를 모아 단순·중간·복합으로 나누고, 각 등급별로 허용 탐색 범위와 검증 루틴을 다르게 설정한다. 그리고 정답률뿐 아니라 읽은 파일 수, 첫 수정까지의 시간, 실패 후 확장 횟수를 함께 본다.

에이전트를 똑똑하게 만드는 일은 더 큰 문맥창을 주는 것만이 아닐 수 있다. 때로는 “이 정도면 충분하다”를 먼저 판단하게 하는 일이 더 큰 자동화 품질 차이를 만든다.

원문 정보

• 제목: Do AI Agents Know When a Task Is Simple? Toward Complexity-Aware Reasoning and Execution
• 저자: Junjie Yin, Xinyu Feng
• 연도/게시일: 2026
• 출처: arXiv
• arXiv: 2607.13034v1
• PDF: https://arxiv.org/pdf/2607.13034

원문 논문: Do AI Agents Know When a Task Is Simple? Toward Complexity-Aware Reasoning and Execution