개요

**장기 실행 에이전트(Long-Running Agents)**는 단일 채팅 세션이 아니라, 수시간수일수주간 실행되며 여러 컨텍스트 윈도우와 샌드박스를 넘나들고, 실패에서 복구하고, 중단 지점부터 재개하는 에이전트 패러다임입니다.

핵심은 모델 자체보다, 상태, 세션, 메모리, 구조화된 핸드오프를 어떻게 설계하느냐에 있습니다.


한 줄 요약

“장기 실행 에이전트의 차별점은 더 똑똑한 모델이 아니라, 기억을 잃지 않고 며칠 동안 일할 수 있게 만드는 하네스다."


"장기 실행”의 세 가지 의미

1. Long-horizon reasoning

  • 많은 의존 단계를 거쳐 계획·실행하는 능력
  • 주로 모델 품질의 문제

2. Long-running execution

  • 프로세스가 수시간~수일 실행되고 모델이 수천 번 호출되는 구조
  • 주로 하네스 설계의 문제

3. Persistent agency

  • 단일 작업을 넘어서 정체성과 메모리를 유지하는 형태
  • 사용자 선호, 과거 상태, 축적 기억을 다룸

실제 프로덕션 에이전트는 세 가지가 겹치지만, 엔지니어링 해법은 서로 다릅니다.


왜 중요한가

  • 10분짜리 에이전트는 작은 버그 수정 수준
  • 10시간짜리 에이전트는 기능 개발, 마이그레이션, 장문 리서치 가능
  • 며칠 실행되는 에이전트는 사실상 턴 기반 챗봇이 아니라 자율 실행자에 가까워짐

즉, 단발성 답변과 실무 생산성 사이의 차이는 대부분 실행 지속성에서 발생합니다.


모든 장기 실행 에이전트가 부딪히는 세 가지 벽

유한한 컨텍스트

  • 1M 토큰도 결국 소진됨
  • 그 전에 context rot가 먼저 발생

영속 상태 부재

  • 새 세션은 기본적으로 백지 상태
  • 이전 근무 내용을 모르는 교대 엔지니어와 비슷한 문제

자기 검증 부재

  • 모델은 자기 작업을 과대평가하는 경향이 있음
  • 별도의 검증 신호 없이 “완료”를 너무 쉽게 선언

대표 패턴

Ralph 루프

  • prd.json이 계획
  • progress.txt가 랩 노트
  • AGENTS.md가 롤링 규칙집
  • 작업 선택 → 프롬프트 구성 → 에이전트 호출 → 테스트 → 진행 기록 → 반복

핵심은 모델은 기억상실이어도 파일시스템은 기억을 유지한다는 점입니다.

Planner / Generator / Evaluator 분리

  • 생성자와 평가자를 분리
  • 같은 모델 자기 채점 문제를 완화

Anthropic, Cursor, Google 모두 이 구조로 수렴합니다.

Brain / Hands / Session 분리

  • Brain: 모델 + 루프
  • Hands: 도구 실행 샌드박스
  • Session: append-only 이벤트 로그

이 분리 덕분에 샌드박스 장애가 세션 장애로 바로 번지지 않습니다.


주요 구현 예시

Anthropic

  • 2-에이전트 하네스 → planner / generator / evaluator 구조
  • Claude Managed Agents에서 brain / hands / session 분리
  • 추가 전용 세션 로그를 통해 복구와 재구성이 가능

Cursor

  • 초기 플랫 병렬 구조는 병목과 churning 유발
  • 현재는 Planner / Worker / Judge
  • 장기 작업은 클라우드 샌드박스와 git worktree 기반으로 수행

Google

  • Agent Runtime
  • Agent Sessions
  • Memory Bank
  • Agent Sandbox / Registry / Identity / Gateway / Observability

즉, 장기 실행 에이전트는 이제 연구 주제가 아니라 플랫폼 제품군으로 이동했습니다.


프로덕션 장기 실행 에이전트의 다섯 가지 패턴

  1. Checkpoint-and-resume 중간 상태 저장과 재개
  2. Delegated approval 사람 승인 동안 상태 보존하며 일시정지
  3. Memory-layered context 세션 메모리 + 장기 메모리 계층화
  4. Ambient processing 인간 대화 없이 이벤트 스트림에 반응
  5. Fleet orchestration 하나의 에이전트가 아니라 전문가 집단처럼 조정

실무적 교훈

  • 완료 조건을 외부 파일에 명시해야 함
  • 평가자와 생성자는 분리해야 함
  • 프롬프트보다 세션 로그에 투자해야 함
  • 압축과 전체 컨텍스트 리셋을 일급 시민으로 취급해야 함
  • 장기 실행에서는 메모리와 핸드오프가 모델보다 더 중요해짐

현재의 한계

  • 비용: 장시간 실행은 API 비용이 빠르게 커짐
  • 보안: 셸, API 키, 클라우드 접근 권한을 가진 에이전트는 공격 표면이 큼
  • alignment drift: 여러 번 요약·재시작하며 목표 충실도 저하
  • 검증: 24시간 활동을 사람이 감사하는 자체가 큰 비용

즉, 기술적으로 가능해져도 운영 가능성이 별도 문제입니다.


의미

장기 실행 에이전트는 단순히 “더 오래 돌아가는 챗봇”이 아닙니다.

핵심 변화는 다음과 같습니다.

  • 채팅 세션 → 세션 로그 기반 실행 시스템
  • 단일 호출 → 멀티 루프 오케스트레이션
  • 일회성 응답 → 상태를 축적하는 실행자
  • 모델 중심 → 하네스 중심

따라서 앞으로의 경쟁력은 모델 성능뿐 아니라, 상태·세션·핸드오프를 얼마나 잘 설계하느냐에 달려 있습니다.


관련 항목