[GeekNews 요약] AI 에이전트의 새로운 지평: 장기 실행 에이전트의 등장과 미래
39
설명
최근 AI 에이전트 기술은 단순한 질의응답을 넘어, 수일에서 수주에 걸쳐 복잡한 목표를 자율적으로 달성하는 '장기 실행 에이전트'로 진화하고 있습니다. 이 글은 기존 에이전트의 한계를 극복하고, 지속적인 학습과 문제 해결 능력을 갖춘 차세대 에이전트의 핵심 개념과 주요 기술 동향을 심층적으로 다룹니다. 개발자 및 IT 전문가라면 이러한 패러다임 변화가 가져올 실질적인 기회와 도전 과제에 주목해야 할 것입니다.
### 배경 설명
지난 2년간 AI 에이전트의 주된 이미지는 '똑똑한 루프가 있는 채팅 창'이었습니다. 사용자가 목표를 입력하면 에이전트가 도구를 호출하고 토큰이 스트리밍되는 것을 지켜보는 방식이었죠. 그러나 이러한 단기적이고 단일 세션 중심의 패러다임은 명확한 한계를 드러냈습니다. 모델은 쉽게 이전 정보를 잊어버리고, 작업이 완료되지 않았음에도 '완료'를 선언하며, 이전에 해결했던 버그를 다시 도입하는 등 일관성 없는 모습을 보였습니다. 이는 에이전트가 하나의 컨텍스트 윈도우와 샌드박스 내에서만 작동하도록 설계되었기 때문입니다.
이러한 한계를 극복하고 AI의 활용 범위를 혁신적으로 확장하기 위해, 산업계는 에이전트가 수 시간, 수일, 심지어 수주 동안 지속적으로 작업을 수행하며 진전을 만들어나가는 '장기 실행 에이전트' 개념에 주목하기 시작했습니다. 이는 단순히 모델의 성능을 높이는 것을 넘어, 에이전트가 여러 컨텍스트 윈도우와 샌드박스를 넘나들며 실패로부터 복구하고, 구조화된 결과물을 남기며, 중단했던 지점부터 작업을 재개할 수 있도록 하는 근본적인 아키텍처 변화를 요구합니다. 특히, Anthropic의 Claude Sonnet이 30시간 이상 자율 코딩을 통해 11,000줄 규모의 Slack 스타일 앱을 개발한 사례는 장기 실행 에이전트가 경제적으로 위임 가능한 작업의 임계점을 넘어섰음을 시사하며, 이 기술이 왜 지금 이 시점에 가장 중요한 화두가 되고 있는지를 명확히 보여줍니다.
### 1. 장기 실행 에이전트의 정의와 중요성
장기 실행 에이전트(Long-running Agents)는 단순히 오랜 시간 작동하는 것을 넘어, 세 가지 핵심적인 의미를 내포합니다. 첫째, '장기 추론(Long-horizon reasoning)'은 에이전트가 여러 종속적인 단계를 거쳐 계획하고 실행하는 능력을 의미하며, 이는 주로 모델의 일관성, 계획 능력, 그리고 과거의 잘못된 결정으로부터 복구하는 능력과 관련됩니다. METR의 연구에 따르면, 프론티어 모델의 시간 지평(time horizon)은 2019년 이후 약 7개월마다 두 배씩 증가하고 있으며, 2028년에는 일 단위, 2034년에는 연 단위 작업을 수행할 수 있을 것으로 전망됩니다. 둘째, '장기 실행(Long-running execution)'은 에이전트의 프로세스가 수 시간 또는 수일 동안 지속되는 것을 의미하며, 코딩 작업, 연구 조사, 24시간 모니터링 서비스 등 다양한 시나리오에 적용됩니다. 이 글의 주요 초점은 바로 이 실행 지속성에 있습니다. 셋째, '영구적 에이전시(Persistent agency)'는 에이전트가 단일 작업을 넘어선 정체성을 가지며, 기억을 축적하고 사용자 선호도를 학습하며 항상 사용 가능한 상태를 유지하는 것을 의미합니다. 이 세 가지 요소는 실제 프로덕션 에이전트에서 서로 얽혀 작동하지만, 각각의 공학적 문제와 이를 해결하는 제품은 다릅니다. 이러한 장기 실행 에이전트의 등장은 경제적으로 위임 가능한 작업의 범위를 확장하고, 에이전트가 단순히 질문에 답하는 도구를 넘어 컨텍스트를 축적하고 학습하는 존재로 변화시킨다는 점에서 매우 중요합니다.
### 2. 기존 에이전트의 한계: 세 가지 장벽
장기 실행 에이전트의 필요성은 기존 AI 에이전트가 직면했던 세 가지 근본적인 한계에서 비롯됩니다. 첫째, '유한한 컨텍스트(Finite context)' 문제입니다. 아무리 큰 1M 토큰 윈도우라도 결국 가득 차게 되며, 컨텍스트 윈도우가 가득 찰수록 모델 성능이 점진적으로 저하되는 '컨텍스트 부패(context rot)' 현상이 발생합니다. 24시간 동안 실행되는 작업은 현재 로드맵에 있는 어떤 컨텍스트 윈도우에도 담을 수 없습니다. 둘째, '영구적 상태 부재(No persistent state)'입니다. 새로운 세션은 항상 백지 상태에서 시작합니다. Anthropic의 비유처럼, 이는 마치 이전 근무조의 상황을 전혀 기억하지 못하는 엔지니어들이 교대하는 소프트웨어 프로젝트와 같습니다. 명시적인 영구화(persistence) 전략 없이는 매 교대마다 생산성 재앙이 발생합니다. 셋째, '자체 검증 불가(No self-verification)' 문제입니다. 모델은 자신의 작업을 평가할 때 신뢰할 수 없을 정도로 긍정적인 경향을 보입니다. '작업이 완료되었는가?'라는 질문에 실제보다 더 자주 '예'라고 답합니다. 작업이 특정 기준을 충족하는지 확인할 별도의 신호 없이는, 30%만 완료된 작업을 완벽하게 자신하며 배포하는 에이전트를 얻게 될 것입니다. 장기 실행 에이전트 설계는 주로 이 세 가지 문제에 대한 해답을 찾는 과정입니다.
### 3. 주요 플레이어들의 해결 전략
주요 AI 연구소와 기업들은 장기 실행 에이전트의 세 가지 장벽을 극복하기 위해 유사하면서도 차별화된 접근 방식을 취하고 있습니다.
**Anthropic:** Anthropic은 엔지니어링 측면에서 가장 공개적인 행보를 보였습니다. 그들은 자율적인 풀스택 개발을 위한 두 에이전트 하네스(initializer agent와 coding agent)를 제시했으며, 특히 '뇌(Brain)', '손(Hands)', '세션(Session)'의 분리 아키텍처를 강조했습니다. 뇌는 모델과 이를 호출하는 하네스 루프, 손은 도구가 실행되는 샌드박스 환경, 세션은 모든 생각과 도구 호출, 관찰을 기록하는 이벤트 로그입니다. 이 분리 아키텍처는 각 구성 요소를 독립적으로 교체 가능하게 하여 시스템의 유연성과 복구 가능성을 크게 향상시킵니다. 세션을 이벤트 로그로 활용하는 아이디어는 에이전트의 메모리를 쿼리 가능한 아티팩트로 만들어 컨테이너 실패 시에도 상태를 재구성할 수 있게 합니다.
**Cursor:** Cursor는 '확장 가능한 장기 실행 자율 코딩'을 통해 Anthropic과는 다른 방식으로 문제에 접근했습니다. 그들은 초기 시도에서 겪었던 병목 현상과 에이전트의 위험 회피 성향을 극복하기 위해 '플래너(Planner)', '워커(Worker)', '심판(Judge)' 모델을 도입했습니다. 플래너는 코드베이스를 탐색하고 작업을 생성하며, 워커는 특정 작업에 집중하여 실행하고, 심판은 작업 완료 여부를 결정합니다. 특히, Cursor는 모델 자체의 특성이 에이전트의 역할에 중요하다고 지적하며, GPT 모델이 Opus보다 확장된 자율 작업에 더 적합하다고 보고했습니다. 이는 특정 역할에 맞는 모델 선택이 설계의 중요한 부분이 되고 있음을 보여줍니다.
**Google:** Google은 Cloud Next '26에서 Vertex AI를 Gemini Enterprise Agent Platform에 통합하며 장기 실행 에이전트를 공식 제품으로 출시했습니다. 그들은 Anthropic의 뇌/손/세션 분리 아키텍처를 플랫폼 스케일로 제품화하여, Agent Runtime, Agent Sessions, Agent Memory Bank, Agent Sandbox 등의 명명된 서비스를 제공합니다. 이는 개발자가 세션 로그나 메모리 저장소를 처음부터 구축할 필요 없이, ADK(코드 우선 개발 키트)를 통해 에이전트를 쉽게 구축하고 배포할 수 있도록 합니다. Google의 접근 방식은 엔터프라이즈 환경에서 필요한 신원 관리, 감사 로그 등의 운영적 요구사항까지 충족시키는 데 중점을 둡니다.
### 4. 프로덕션 환경을 위한 5가지 핵심 패턴
실제 프로덕션 환경에서 장기 실행 에이전트를 성공적으로 운영하기 위해서는 다음과 같은 다섯 가지 설계 패턴이 중요합니다.
**1. 체크포인트 및 재개(Checkpoint-and-resume):** 가장 흔한 다일간 실패는 컨텍스트 손실입니다. 에이전트가 수백 개의 문서를 처리하다 오류가 발생하면, 체크포인트 없이는 처음부터 다시 시작해야 합니다. 장기 실행 서버 프로세스처럼 에이전트를 다루어, 중간 상태를 디스크에 기록하고 N 단위 작업마다 체크포인트를 설정하여 실패로부터 복구해야 합니다. Agent Runtime의 영구 파일 시스템을 활용하되, 적절한 체크포인트 세분성을 결정하는 것이 중요합니다.
**2. 위임된 승인(Delegated approval - human-in-the-loop):** 대부분의 '휴먼-인-더-루프' 구현은 상태를 JSON으로 직렬화하고 웹훅을 발생시켜 사람의 응답을 기다리는 방식입니다. 이 경우 상태가 오래되거나 알림이 묻히는 문제가 발생할 수 있습니다. 장기 실행 런타임은 에이전트가 완전한 실행 상태(추론 체인, 작업 메모리, 도구 기록, 보류 중인 작업)를 유지한 채 일시 중지할 수 있게 합니다. 사람이 수 시간 동안 개입한 후에도 에이전트는 컴퓨팅 자원을 소비하지 않고 즉시 작업을 재개할 수 있습니다. Google의 Mission Control이 이러한 패턴을 지원합니다.
**3. 메모리 계층화된 컨텍스트(Memory-layered context):** 7일 동안 실행되는 에이전트는 단순히 세션 상태 이상의 것을 필요로 합니다. Memory Bank는 장기적으로 큐레이션된 메모리를 처리하고, Memory Profiles는 낮은 지연 시간으로 조회를 가능하게 합니다. 프로덕션에서 발생할 수 있는 실패 모드는 '메모리 드리프트(memory drift)'인데, 에이전트가 몇몇 비정형적인 상호작용으로부터 절차적 지름길을 학습하고 이를 광범위하게 적용하기 시작하는 현상입니다. 마이크로서비스를 관리하듯이 메모리를 관리해야 하며, Agent Identity, Agent Registry, Agent Gateway를 통해 메모리 접근 정책을 제어하고 에이전트의 행동 변화를 추적해야 합니다.
**4. 주변 처리(Ambient processing):** 모든 장기 실행 에이전트가 사람과 대화하는 것은 아닙니다. 일부는 Pub/Sub 스트림이나 BigQuery 테이블에서 이벤트를 수신하고 콘텐츠 조정, 이상 감지, 받은 편지함 분류 등의 작업을 수행합니다. 에이전트에 정책을 하드코딩하지 않고 Gateway에서 정의하여, 정책 변경 시 에이전트 재배포 없이도 업데이트가 반영되도록 하는 것이 중요합니다. 주변 에이전트는 장시간 무인으로 실행되므로, 수백 개의 에이전트를 업데이트하는 유일한 합리적인 방법은 정책 계층을 한 번 업데이트하는 것입니다.
**5. 플릿 오케스트레이션(Fleet orchestration):** 실제 시스템에서는 하나의 에이전트만 사용하는 경우는 드뭅니다. 코디네이터 에이전트가 하위 작업을 전문가 에이전트(예: 리드 연구원 에이전트, 점수 매기기 에이전트, 아웃리치 에이전트)에게 위임하고, 각 전문가는 독립적으로 다른 기간 동안 실행됩니다. 각 전문가는 고유한 신원(Identity)을 가지므로, 아웃리치 에이전트가 점수 매기기 에이전트의 금융 데이터를 읽을 수 없도록 합니다. ADK는 그래프 기반 워크플로우를 통해 이를 선언적으로 처리하며, 한 전문가의 배포 실패가 다른 전문가에게 연쇄적으로 영향을 미치지 않도록 합니다. 이 패턴은 수십 년간 분산 시스템에서 사용되어 온 코디네이터/워커 구조와 유사합니다.
### 5. 장기 실행 에이전트 구축 가이드라인 및 고려사항
장기 실행 에이전트를 구축하는 방법은 목표에 따라 달라집니다.
**개인 저장소에서 장기 실행 코딩 작업을 원하는 개발자:** Claude Code, Antigravity, Cursor, Codex와 같은 기존 도구를 활용하세요. AGENTS.md를 조종사의 체크리스트처럼 활용하고, 타입 체크 및 린트 훅을 추가하여 에이전트에게 실패를 알리세요. 에이전트 시작 전에 계획 파일을 작성하고, 에이전트가 완료를 주장할 때 믿기지 않는다면 Ralph 루프를 사용하세요. 멀티 시간 또는 야간 작업을 위해 워크트리에서 실행하여 노트북이 닫혀도 작업이 중단되지 않도록 하고, 의미 있는 작업 단위마다 진행 상황을 커밋하도록 합니다. 이것이 현재 가장 큰 레버리지를 얻을 수 있는 경로입니다.
**호스팅 에이전트 제품을 구축하는 팀:** 런타임을 직접 구축하지 말고 관리형 런타임을 선택하세요. 현재 세 가지 주요 옵션은 Google의 Agent Platform (Agent Engine + Memory Bank + Sessions), Claude Managed Agents, 또는 ADK, Claude Agent SDK, Codex SDK 위에 자체적으로 구축하여 호스팅하는 것입니다. 관리형 서비스는 뇌/손/세션 분리, 관찰 가능성, 신원, 감사 추적 기능을 기본으로 제공하며, 자체 호스팅은 제어권과 특이한 역할에 특이한 모델을 사용할 수 있는 유연성을 제공합니다. 대부분의 팀에게는 관리형 런타임과 자체 ADK 또는 SDK 코드를 결합하는 것이 좋은 시작점입니다.
**자율적이고 운영적인 작업(모니터링, 연구, 운영)을 수행하는 경우:** Memory Bank 스타일의 영구성이 필요하며, 이는 Claude Code에는 없는 부분입니다. ADK + Memory Bank + Cloud Run + Cloud Scheduler는 '에이전트가 N시간마다 실행되고, 상태를 축적하며, 임계값에 따라 경고를 발생시키는' 가장 깔끔한 스택입니다. 이 경우 Cursor의 플래너/워커/심판 분리 모델이 IDE 코딩보다 더 중요해지는데, 작업이 진정으로 병렬적이고 실패 모드가 다르기 때문입니다.
어떤 경로를 선택하든 몇 가지 중요한 원칙이 있습니다. 첫째, 에이전트가 시작하기 전에 '완료 조건'을 명확히 작성하세요. 이는 장기 실행에 있어 가장 중요한 요소입니다. 둘째, '평가자'를 '생성자'와 분리하세요. 자체 평가(self-grading)는 실패 모드입니다. 플래너/워커/심판 파이프라인 또는 생성자/평가자 쌍은 스타일적인 선호가 아닌 실제 아키텍처 패턴입니다. 셋째, 프롬프트뿐만 아니라 '세션 로그'에 투자하세요. 추가 전용 이벤트 로그는 에이전트를 복구 가능하고 디버깅 가능하며 감사 가능하게 만듭니다. 넷째, '압축(compaction)'과 '컨텍스트 재설정(context resets)'을 일등 시민으로 다루세요. Anthropic은 매우 긴 작업의 경우 요약만으로는 충분하지 않아, 하네스가 세션을 해체하고 구조화된 핸드오프 파일에서 재구축하는 완전한 컨텍스트 재설정이 필요했다고 명시했습니다. 이는 본질적으로 인간이 새로운 엔지니어를 온보딩하는 방식과 유사합니다.
### 가치와 인사이트
장기 실행 에이전트의 등장은 AI가 단순한 도구를 넘어 실질적인 '협력자'로 진화하고 있음을 의미합니다. 이는 기업과 개발자에게 전례 없는 가치와 실무적 영향을 미칠 것입니다. 첫째, 복잡하고 장기적인 프로젝트를 AI에 위임함으로써 인적 자원을 보다 전략적인 업무에 집중시킬 수 있습니다. 예를 들어, 수개월이 걸리던 코드 마이그레이션이나 대규모 연구 조사를 에이전트가 자율적으로 수행하게 하여 개발 주기를 단축하고 생산성을 극대화할 수 있습니다. 둘째, 에이전트가 컨텍스트를 축적하고 학습하는 능력을 갖추게 되면서, 특정 도메인이나 사용자 선호도에 최적화된 맞춤형 AI 솔루션 개발이 가능해집니다. 이는 고객 서비스, 데이터 분석, 소프트웨어 개발 등 다양한 산업 분야에서 AI의 활용도를 심화시킬 것입니다. 셋째, 체크포인트, 세션 로그, 평가자 분리 등의 설계 패턴은 에이전트의 신뢰성과 안정성을 크게 향상시켜, 프로덕션 환경에서의 실제 적용 가능성을 높입니다. 이제 개발자는 단순히 코드를 작성하는 것을 넘어, 에이전트가 명확하게 이해하고 실행할 수 있는 '명세서'를 작성하는 능력에 더 큰 가치를 두게 될 것입니다. 이는 인간과 AI의 협업 방식에 근본적인 변화를 가져오며, 새로운 직무와 기술 역량을 요구할 것입니다.
### 기술·메타
- **주요 플랫폼:** Google Agent Platform (Agent Engine, Memory Bank, Sessions), Anthropic Claude Managed Agents, Cursor
- **개발 도구/SDK:** Google ADK, Claude Agent SDK, Codex SDK
- **오픈 소스 패턴:** Ralph loop (Bash 스크립트, JSON 파일 기반)
- **실행 환경:** Cloud Run, Cloud Scheduler, tmux, SLURM, Git
- **아키텍처 패턴:** Brain/Hands/Session 분리, Planner/Worker/Judge 모델, Checkpoint-and-resume, Delegated approval, Memory-layered context, Ambient processing, Fleet orchestration
### 향후 전망
장기 실행 에이전트 기술은 현재 초기 단계에 있지만, Google, Anthropic, Cursor와 같은 주요 플레이어들이 유사한 아키텍처(모델 루프, 실행 샌드박스, 영구 세션 로그의 분리; 계획, 생성, 평가의 분리; 관리형 메모리 서비스)로 수렴하고 있다는 점은 이 분야의 미래 방향성을 명확히 보여줍니다. 앞으로 1년 동안 해결해야 할 더 어려운 문제들은 개별 계층에 있는 것이 아니라, 이들 계층 간의 '조정'에 있을 것입니다.
향후에는 공유 코드베이스에서 여러 장기 실행 에이전트가 협업하는 시나리오가 보편화될 것입니다. 에이전트가 자신의 실행 추적을 읽고 스스로 하네스를 패치하며, 작업에 필요한 도구와 컨텍스트를 시작 시점에 미리 구성하는 것이 아니라 '적시(just-in-time)'로 조립하는 형태로 진화할 것입니다. 이러한 발전은 에이전트가 단순한 '똑똑한 채팅 창'을 넘어, 프로젝트에 오랫동안 참여해 온 '동료'와 같은 존재로 인식되게 할 것입니다. 규제 측면에서는 AI의 자율성과 책임 범위에 대한 논의가 더욱 활발해질 것이며, 특히 보안, 비용, 정렬 드리프트(alignment drift), 검증(auditing)과 같은 현재의 한계점들이 중요한 변수로 작용할 것입니다. 이러한 문제들을 해결하기 위한 기술적 진보와 함께, AI 에이전트의 행동을 투명하게 추적하고 제어할 수 있는 새로운 거버넌스 프레임워크가 필요해질 것입니다. 궁극적으로, 모델 자체의 성능 향상만큼이나, 모델을 둘러싼 상태 관리, 세션 지속성, 구조화된 핸드오프 메커니즘이 장기 실행 에이전트의 성공을 좌우하는 핵심 요소가 될 것입니다.
📝 원문 및 참고
- 원문: [링크 열기](https://addyo.substack.com/p/long-running-agents)
- GeekNews 토픽: [보기](https://news.hada.io/topic?id=29255)
---
출처: GeekNews ([원문 링크](https://addyo.substack.com/p/long-running-agents))
댓글 0
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.