Long-Running Agents: 장시간 실행 에이전트의 아키텍처와 설계 패턴
목차
개요
Long-Running Agents는 Addy Osmani가 작성한 글로, 여러 세션과 샌드박스를 넘나들며 수일 또는 수주에 걸쳐 목표를 향해 지속적으로 전진하는 에이전트를 다룬다. 현재 두 가지 중요한 변화가 이 주제를 현실적으로 만들고 있다. 첫째, 경제적 타당성의 임계점을 넘었다는 점이다. 10시간 자율 실행으로 전체 기능 구현이나 복잡한 리서치 태스크를 완수할 수 있게 되었다. 둘째, 정체성 지속성이 에이전시의 본질을 바꾼다는 점이다. 에이전트가 상태 없는 시스템에서는 불가능했던 맥락적 이해를 축적할 수 있게 된다. 이 글에서는 장시간 실행 에이전트가 직면하는 문제와 주요 플랫폼들의 아키텍처 해법, 그리고 실전에서 적용할 수 있는 설계 패턴을 정리한다.
장시간 실행의 세 가지 유형
장시간 실행 에이전트를 이해하려면 먼저 “장시간”이 의미하는 바를 세 가지로 구분해야 한다.
장기적 추론(Long-horizon reasoning)
여러 턴에 걸쳐 의존적인 단계를 계획하고 실행하는 것이다. METR 연구에 따르면 프론티어 에이전트는 2028년까지 하루 단위 태스크를, 2034년까지 1년 단위 태스크를 완수할 수 있을 것으로 예측된다.
장시간 실행(Long-running execution)
수천 번의 모델 호출과 함께 에이전트 프로세스가 수 시간 또는 수 일 동안 실행되는 것이다. 이는 주로 하네스 엔지니어링 과제다.
지속적 에이전시(Persistent agency)
여러 상호작용에 걸쳐 메모리를 축적하고 선호도를 학습하며 지속적인 정체성을 갖는 에이전트다.
에이전트가 부딪히는 세 가지 벽
모든 장시간 실행 에이전트는 공통적으로 세 가지 근본적인 장벽에 직면한다.
유한한 컨텍스트(Finite context)
컨텍스트 윈도우가 채워지면서 “컨텍스트 부패(context rot)”가 발생한다. 하드 한계에 도달하기 전부터 성능이 저하된다.
지속 상태 없음(No persistent state)
메모리 없이 각 세션이 빈 상태로 시작된다. 이전 세션의 기억이 없는 상태에서 작업이 재개된다.
자기 검증 없음(No self-verification)
모델이 자신의 작업을 지나치게 낙관적으로 평가한다. 생성자와 평가자가 동일한 모델일 경우 신뢰할 수 있는 검증이 이루어지지 않는다.
주요 아키텍처 접근법
The Ralph Loop: 가장 단순한 실용적 접근
The Ralph Loop는 배시 스크립트 기반의 루프로, 실무에서 활용 가능한 가장 단순한 형태의 장시간 에이전트 접근법이다. 핵심 동작 방식은 다음과 같다.
- 외부 파일(
prd.json)에서 다음 태스크를 읽는다. - 태스크와 지속 메모 파일을 결합해 프롬프트를 구성한다.
- 에이전트를 호출한다.
- 검증 체크를 실행한다.
- 결과를
progress.txt에 추가한다. - 태스크 목록을 업데이트하고 반복한다.
핵심 인사이트는 “상태는 에이전트의 컨텍스트 외부에 존재한다”는 것이다. 에이전트 자체는 기억상실 상태지만, 파일시스템은 그렇지 않다.
Anthropic: Brain/Hands/Session 분리
Anthropic은 두 편의 기반 논문을 통해 아키텍처를 제시했다.
첫 번째 논문 Effective Harnesses for Long-Running Agents는 2에이전트 패턴을 설명한다.
| 역할 | 설명 |
|---|---|
| Initializer 에이전트 | 환경 설정, 요구사항을 구조화된 feature-list.json으로 확장 |
| Coding 에이전트 | 점진적 진행, 테스트 실행, 진행 노트 남기기 |
테스트 래칫(Test ratchet)은 버그를 숨기기 위해 실패하는 테스트를 삭제하는 것을 방지한다.
두 번째 논문 Scaling Managed Agents는 세 가지 구성 요소를 분리하는 방식을 제안한다.
| 구성 요소 | 설명 |
|---|---|
| Brain | 모델과 하네스 루프 |
| Hands | 임시 샌드박스 실행 환경 |
| Session | 생각, 도구 호출, 관찰의 추가 전용 이벤트 로그 |
세션을 이벤트 로그로 취급하는 패턴은 복구를 가능하게 한다. 새 컨테이너가 wake(sessionId)를 호출하여 로그로부터 상태를 재구성한다.
Cursor: Planners/Workers/Judges 구조
Cursor는 세 가지 역할로 구성된 아키텍처를 사용한다.
| 역할 | 역할 설명 |
|---|---|
| Planners | 코드베이스를 지속적으로 탐색하고 태스크를 생성, 하위 플래너 스폰 가능 |
| Workers | 상호 조정 오버헤드 없이 집중적으로 실행하는 실행자 |
| Judges | 반복 완료를 판단하고 재시작 조건을 결정 |
주목할 발견은 “시스템의 동작 대부분은 하네스나 모델보다 에이전트를 어떻게 프롬프트하느냐에서 비롯된다”는 점이다. 또한 백그라운드 클라우드 에이전트를 통해 노트북을 닫아도 장시간 태스크가 계속 실행되며, 에이전트별 git worktree와 PR 기반 머지를 지원한다.
Google: Gemini Enterprise Agent Platform
Google은 같은 아키텍처 패턴을 엔터프라이즈 규모로 제품화했다.
| 구성 요소 | 설명 |
|---|---|
| Agent Runtime | 서브세컨드 콜드 스타트, 온디맨드 샌드박싱 |
| Agent Sessions | 커스텀 세션 ID로 대화 기록 지속 |
| Memory Bank | 사용자 정체성 범위의 장기 메모리 큐레이션 |
| Agent Registry/Identity/Gateway | 에이전트 플릿의 운영 제어 |
| Agent Observability/Simulation | 감사 및 테스트 기능 |
다중일 자율 실행에 대한 SLA를 제공하며, 정체성과 감사 추적이 내장되어 있다.
5가지 프로덕션 설계 패턴
Checkpoint-and-Resume
N 단위마다 중간 상태를 디스크에 기록한다. 장애로부터 우아하게 복구할 수 있다.
Delegated Approval
에이전트가 전체 실행 상태를 유지한 채로 일시 정지한다. 인간이 상태 지연 문제 없이 검토할 수 있다.
Memory-Layered Context
세션에서 메모리를 큐레이션한다. 정체성 제어를 통해 “메모리 드리프트”를 방지한다.
Ambient Processing
콘텐츠 모더레이션, 이상 탐지 등 이벤트 스트림에서 에이전트를 운영한다. 정책 집행은 하드코딩이 아닌 게이트웨이 레이어에서 이루어진다.
Fleet Orchestration
코디네이터가 별도 정체성을 가진 전문 에이전트에게 위임한다. 연쇄 장애를 방지한다.
실전 구현 경로
구체적인 사용 시나리오에 따라 구현 경로가 달라진다.
자체 리포지토리에서 개발하는 경우, Claude Code, Cursor, Antigravity를 활용한다. 타입 체크와 린트를 위한 훅을 추가하고, 사전에 계획 파일을 작성하며, 완료 검증에 Ralph Loop를 사용하는 것이 권장된다. 장시간 야간 작업에는 worktree에서 실행한다.
호스팅 제품을 구축하는 경우, 런타임을 직접 구축하지 않고 Google Agent Platform, Claude Managed Agents, 또는 ADK/Claude Agent SDK로 자체 호스팅하는 것을 권장한다. 이 솔루션들은 brain/hands/session 분리와 옵저버빌리티를 기본 제공한다.
자율 운영 작업의 경우, Memory Bank 지속성과 ADK + Cloud Run + Cloud Scheduler 스택이 “에이전트가 N시간마다 실행되고 상태를 축적”하는 패턴을 처리한다.
현재의 한계
장시간 실행 에이전트는 아직 여러 실질적인 한계를 안고 있다.
첫째, 비용 문제다. 24시간 프론티어 모델 실행은 명시적인 예산과 서킷 브레이커를 필요로 한다.
둘째, 보안 문제다. 공격 표면이 넓기 때문에 brain/hands 분리가 중요하다. 모델이 생성한 코드에서 자격 증명에 접근할 수 없어야 한다.
셋째, 정렬 드리프트다. 여러 컨텍스트 윈도우 요약을 거치면서 목표의 충실도가 떨어진다.
넷째, 검증 문제다. 24시간의 활동을 감사하려면 PR, 커밋, 브리핑 등 구조화된 아티팩트가 필요하다.
다섯째, 인간 역할의 변화다. 자율 실행에 적합한 정밀한 스펙을 작성하는 능력이 코드를 직접 작성하는 능력보다 중요해진다.
결론
채팅 창과 밤새 실행할 수 있는 에이전트의 차이는 대부분 그것을 감싸는 상태(state), 세션(session), 구조화된 핸드오프(structured handoffs)에 있다. 주요 AI 연구소들은 별도의 모델 루프, 샌드박스, 내구성 있는 세션 로그를 분리하고, 계획/생성/평가를 분리하며, 메모리를 관리형 서비스로 노출하는 동일한 아키텍처 형태로 수렴하고 있다. 다음 프론티어는 공유 작업에 대한 다수의 장시간 실행 에이전트 조정, 자신의 트레이스를 읽고 하네스를 개선하는 에이전트, 적시 도구 및 컨텍스트 어셈블리다. 실행 시작 전 명시적인 완료 조건을 작성하고, 생성자와 평가자를 분리하며, 프롬프트보다 세션 로그에 투자하는 것이 가장 중요한 실천 원칙이다.