며칠씩 혼자 돌아가는 AI 에이전트, 어떻게 설계하나? 장기 실행 에이전트 5가지 패턴 (id.news.hada.io)

한줄 요약

AI 에이전트가 단일 채팅 세션을 벗어나 며칠~몇 주 단위로 자율 실행되며, 이를 뒷받침하는 아키텍처 패턴이 업계 표준으로 수렴 중이다.

무엇이 달라지나?

장기 실행 에이전트(Long-Running Agent)는 단순히 "오래 돌아가는 챗봇"이 아니다. 컨텍스트 윈도우를 여러 번 넘나들고, 실패를 스스로 복구하며, 중단 지점부터 재개하는 완전히 다른 실행 패러다임이다.

왜 지금 이게 중요한가? 에이전트가 10분 동안 실행되면 간단한 버그 수정 수준에 머문다. 그런데 10시간 단위로 실행되면 6분기 동안 미뤄온 마이그레이션을 완료하거나, 주니어 애널리스트급 리서치 결과물을 만들어낼 수 있다. Anthropic의 내부 테스트에서는 Claude Sonnet이 30시간 이상 자율 코딩을 수행해 11,000줄짜리 Slack 스타일 애플리케이션을 만들어낸 사례가 공개됐다. Google의 Project Vend에서는 Claude 인스턴스 하나가 한 달간 실제 자판기 사업을 운영하며 재고 관리, 가격 설정, 공급업체 커뮤니케이션을 처리했다.

이 흐름을 뒷받침하는 수치도 있다. METR의 time horizon 지표에 따르면, 프론티어 모델이 50% 신뢰도로 완료할 수 있는 작업 시간이 2019년 이후 약 7개월마다 두 배씩 늘어나고 있다. 이 추세가 이어진다면 하루 단위 작업은 2028년, 연간 단위 작업은 2034년에 해결 가능한 범위에 들어온다.

장기 실행 에이전트가 부딪히는 세 가지 구조적 한계

현재 에이전트 설계가 며칠 단위 실행에서 실패하는 이유는 세 가지로 명확하다.

첫째, 컨텍스트 소진이다. 1M 토큰 윈도우도 결국 바닥난다. 채워지기 전부터 컨텍스트 부패(context rot)가 발생해 모델 성능이 점진적으로 저하된다.

둘째, 세션 간 상태 공백이다. 새 세션은 완전한 백지에서 시작한다. Anthropic은 이를 "이전 교대 근무에서 무슨 일이 있었는지 전혀 모르는 채로 출근한 엔지니어"에 비유했다.

셋째, 자기 검증 편향이다. 모델이 스스로 작업 완료 여부를 판단할 때 긍정 편향이 일관되게 나타난다. 실제로는 30%밖에 완료되지 않은 결과물을 완성됐다고 제출하는 상황이 발생한다.

실무에서 어떤 의미인가?

Anthropic, Google, Cursor 세 곳이 각자 독립적으로 개발했지만 결론적으로 유사한 구조로 수렴한 것이 흥미롭다. 핵심은 Brain(모델 루프) / Hands(실행 샌드박스) / Session(이벤트 로그)의 분리다.

Cursor는 이를 Planner-Worker-Judge 구조로 구현했다. 초기에는 에이전트들이 공유 파일에 동등하게 접근하는 방식을 시도했지만 병목과 과도한 위험 회피 행동이 나타났다. 현재 프로덕션 구조에서는 Planner가 코드베이스를 탐색해 작업을 생성하고, Worker가 독립적으로 실행하며, Judge가 반복 완료 여부를 판단한다. 흥미로운 발견은 "시스템 동작의 대부분은 하네스나 모델보다 프롬프트에 의해 결정된다"는 점이다.

Google은 이를 플랫폼 수준으로 끌어올렸다. Cloud Next '26에서 공개된 Gemini Enterprise Agent Platform은 Agent Runtime(수일 단위 자율 실행, 서브초 콜드 스타트), Agent Sessions(대화 이력과 이벤트 영속화), Memory Bank(장기 커레이션 메모리)를 포함한다. Payhawk 사례에서 Memory Bank 기반 에이전트가 경비 제출 시간을 50% 이상 단축했다는 결과가 나왔다.

Anthropic의 Claude Managed Agents 아키텍처에서는 세션 이벤트 로그가 핵심이다. 컨테이너 장애가 발생해도 새 컨테이너가 wake(sessionId)를 호출해 로그로부터 상태를 재구성할 수 있다. 이 구조 덕분에 첫 토큰 생성 시간이 p50 기준 약 60%, p95 기준 90% 이상 단축됐다는 수치가 공개됐다.

다섯 가지 설계 패턴 정리

업계가 수렴하고 있는 프로덕션 패턴은 다음 다섯 가지다.

1. Checkpoint-and-Resume: 200개 문서 처리 중 201번째에서 실패하면 처음부터 다시 시작하는 구조는 장기 실행에서 치명적이다. N개 작업 단위마다 상태를 디스크에 저장하고, 장애 시 복구하는 구조가 필수다. 체크포인트 단위의 세밀도가 설계의 핵심 변수다.

2. Delegated Approval(Human-in-the-loop): 과거 방식은 상태를 JSON으로 직렬화 후 웹훅 대기였는데, 상태가 stale해지고 알림이 묻히는 문제가 반복됐다. 장기 실행 런타임에서는 에이전트가 전체 추론 체인과 작업 메모리를 유지한 채로 일시 정지하고, 검토 시간 동안 컴퓨팅 소비를 0으로 유지하다가 서브초 레이턴시로 재개하는 구조가 가능하다.

3. Memory-Layered Context: 7일 동안 실행되는 에이전트는 세션 상태 이상의 메모리가 필요하다. Memory Bank(커레이션된 장기 메모리)와 저레이턴시 조회를 조합한다. 주의할 점은 메모리 드리프트다. 에이전트가 비구조적 상호작용에서 절차적 지름길을 학습해 광범위하게 적용하는 현상이 나타난다. 메모리를 마이크로서비스처럼 거버닝하는 접근이 필요하다.

4. Ambient Processing: 인간과 대화 없이 Pub/Sub 스트림이나 BigQuery 테이블의 이벤트에 반응하는 에이전트 패턴이다. 콘텐츠 모더레이션, 이상 탐지, 인박스 분류 등에 활용된다. 정책을 에이전트에 하드코딩하지 않고 Gateway에 정의하면, 수백 개 에이전트를 재배포 없이 정책 변경할 수 있다.

5. Fleet Orchestration: 실제 시스템은 단일 에이전트가 아니라 조율자가 전문가 에이전트들에게 하위 작업을 위임하는 구조다. 각 전문 에이전트는 고유한 Identity, 정책, Registry 항목을 가진다. ADK는 이를 그래프 기반 워크플로로 선언적으로 처리한다.

이 다섯 패턴은 조합 가능하다. 컴플라이언스 시스템 예시: 문서 처리에 체크포인팅 + 리뷰 게이트에 위임 승인 + 세션 간 지식에 메모리 레이어링 + 전문가 조율에 플릿 오케스트레이션.

도입 전 체크포인트

장기 실행 에이전트를 도입하거나 설계할 때 실질적으로 점검해야 할 사항이다.

첫째, 런타임을 직접 만들려 하지 마라. 현재 Google Agent Platform(Agent Engine + Memory Bank + Sessions), Claude Managed Agents, ADK/Codex SDK 기반 셀프호스팅 중 선택하는 것이 현실적이다. Managed 옵션은 Brain/Hands/Session 분리, 옵저버빌리티, Identity, 감사 추적을 기본 제공한다.

둘째, 코딩 작업이라면 AGENTS.md를 파일럿 체크리스트처럼 관리하라. 짧게 유지하고, 실제 실패 경험에서 얻은 내용만 담는다. 타입체크와 린트 훅을 추가하고, 시작 전 계획 파일을 작성하라. 에이전트가 완료를 주장할 때 별도 검증 루프로 확인하는 과정이 필수다.

셋째, 멀티시간 또는 야간 작업은 git worktree에서 실행하라. 노트북을 닫아도 작업이 지속되고, 의미 있는 작업 단위마다 커밋이 쌓인다.

핵심 인식 전환은 이것이다. 생산성을 실질적으로 가르는 요소는 모델 자체가 아니라, 모델을 감싸는 상태(State), 세션(Session), 구조적 핸드오프(Handoff) 레이어다. 이 레이어가 견고하면 모델 교체도 부담이 없다.