장기 실행 에이전트

지난 2년간 "AI 에이전트"를 떠올리면 대부분 채팅 창에 루프 로직을 얹은 구조를 상상했다. 목표를 입력하면 에이전트가 몇 가지 도구를 호출하고, 토큰이 스트리밍되는 걸 지켜보다가, 작업이 막히거나 컨텍스트 윈도우가 꽉 차면 포기하는 방식이다. 이 패러다임이 상당한 진전을 이끈 건 사실이지만, 분명한 한계가 있다. 모델은 이전 내용을 잊는다. 작업이 끝나지 않았는데도 "완료"라고 선언한다. 아홉 턴 전에 고쳤던 버그를 다시 들여온다. 결국 이 구조 전체가 한 번의 세션을 전제로 설계되어 있다.

Long-running AI agents

장기 실행 에이전트는 그 다음 단계다. 개념 자체는 간단하다. 여러 세션과 샌드박스에 걸쳐, 경우에 따라 며칠에서 몇 주에 걸쳐 목표를 향해 꾸준히 진행하는 에이전트. 다음 세션이 이전 세션이 멈춘 지점을 이어받을 수 있도록 작업 공간을 깔끔하게 유지한다. 하지만 이걸 실제로 구현하는 건 훨씬 어렵다. 표면만 봉합하는 수준이 아닌, 진짜 지속성, 복구, 검증 문제를 풀어야 한다. 모델의 컨텍스트 윈도우 바깥에 존재하는 상태 레이어를 만들고, 새로운 세션이 낯선 샌드박스에서 눈을 떴을 때 혼란 없이 작업을 이어갈 수 있도록 세션 간 핸드오프를 설계해야 한다.

이 글에서는 무엇이 달라졌는지, 누가 이 문제를 밀어붙이고 있는지, 그리고 엔지니어가 지금 당장 처음부터 다 만들지 않고도 장기 실행 에이전트를 활용할 수 있는 방법을 정리해보려 한다.

"장기 실행"이 실제로 의미하는 것

"장기 실행"이라는 말은 실제로 적어도 세 가지 다른 의미로 쓰인다. 각각을 구분해두면 훨씬 명확해진다.

장기 추론(Long-horizon reasoning). 서로 의존 관계에 있는 수많은 단계를 걸쳐 계획하고 실행하는 능력이다. 이는 주로 모델 품질의 문제다. 일관성, 계획 수립 능력, 열 단계 전에 잘못된 방향으로 빠진 것을 바로잡는 능력. METR은 이를 타임 호라이즌(time horizon) 지표로 추적하고 있다. 최신 프론티어 모델이 50% 신뢰도로 완수할 수 있는 작업의 최대 소요 시간을 추정하는 지표다. 핵심 결과는 이 수치가 2019년 이후 약 7개월마다 두 배씩 늘어나고 있다는 것이다. 올해 초 공개된 TH1.1 업데이트에서는 평가 세트에 포함된 8시간 이상 작업의 수가 두 배로 늘었다. 이 추세가 유지된다면, 2028년에는 프론티어 에이전트가 하루 단위 작업을, 2034년에는 1년 단위 작업을 완수하게 된다.

장기 실행(Long-running execution). 에이전트의 프로세스가 몇 시간 또는 며칠에 걸쳐 실행되는 것이다. 코딩 작업일 수도 있고, 리서치 탐색일 수도 있으며, 24시간 모니터링 서비스일 수도 있다. 한 번의 실행 동안 모델이 수천 번 호출될 수 있다. 이는 주로 하네스(harness)의 문제이며, 이 글에서 집중적으로 다루는 영역이기도 하다.

지속적 에이전시(Persistent agency). 단일 태스크를 넘어서 유지되는 정체성을 갖는 에이전트다. 기억을 축적하고, 사용자 선호도를 학습하며, 항상 접근 가능한 상태로 존재한다. Memory Bank 방식의 장기 실행이 이에 해당한다.

실제로는 이 세 가지가 뒤섞인다. 진짜 프로덕션 에이전트는 지속적 에이전시를 기반으로 한 장기 실행 환경 안에서 장기 추론을 수행한다. 하지만 각 영역의 엔지니어링 문제는 서로 다르고, 이를 해결하는 제품들도 마찬가지다.

왜 지금 중요한가

이 작업이 지금 시점에 중요한 이유가 두 가지 있다.

첫 번째는, 무엇을 위임할 수 있는지에 대한 경제적 기준이 바뀌고 있다는 것이다. 10분 동안 실행되는 에이전트는 질문에 답하고, 문서를 요약하고, 작은 버그를 고친다. 10시간 동안 실행되는 에이전트는 기능 전체를 책임지고, 6분기 동안 백로그에 쌓여 있던 마이그레이션을 완수하고, 예전에는 주니어 분석가가 밤새워 해야 했던 리서치를 수행한다. Anthropic이 지난 가을 Claude Sonnet 발표에서 구체적인 수치를 공개했다. 내부 테스트에서 30시간 이상 자율 코딩을 진행했고, 그중 한 실행에서는 1만 1천 줄 규모의 Slack 유사 앱이 만들어졌다. 이미 "이 작업을 맡겨도 될까?"라는 질문의 답이 뻔하지 않은 수준을 넘어섰다.

두 번째는, 지속성이 에이전트의 본질 자체를 바꾼다는 점이다. 상태가 없는 에이전트는 질문에 답하고 사라진다. 장기 실행 에이전트는 컨텍스트를 쌓아간다. 지난주에 어떤 경쟁사가 어떤 방향으로 움직였는지, 화요일에 어떤 테스트가 두 번 실패했는지, "그 대시보드"라고 하면 보통 무엇을 말하는지. Anthropic의 Project Vend는 이를 가장 공개적으로 보여준 초기 사례였다. Claude 인스턴스가 한 달 동안 실제 사무실 자판기 사업을 운영하면서 재고를 관리하고, 가격을 책정하고, 공급업체와 소통했다. 실패가 많았고, 2단계에서는 훨씬 나은 성과를 보였지만, 핵심은 수익성이 아니었다. 에이전트가 몇 번의 턴이 아닌 몇 주에 걸쳐 일관된 정체성을 유지해야 할 때 어떤 기묘한 일관성 문제가 생기는지를 관찰하는 것이었다.

지금 프로덕션 에이전트를 만드는 모든 팀이 부딪히는 문제가 바로 그것이다.

장기 실행 에이전트가 맞닥뜨리는 세 가지 벽

올해 읽은 거의 모든 글에서 공통적으로 등장하는 세 가지 벽이 있다.

유한한 컨텍스트. 100만 토큰 윈도우도 결국 꽉 찬다. 게다가 윈도우가 가득 찰수록 모델 성능이 점진적으로 떨어지는 컨텍스트 부패(context rot)는 하드 리밋에 도달하기 훨씬 전부터 시작된다. 24시간짜리 실행은 어떤 컨텍스트 윈도우에도 들어가지 않는다. 무언가 다른 방식이 필요하다.

지속되는 상태 없음. 새 세션은 백지에서 시작된다. Anthropic이 과학 컴퓨팅 관련 포스트에서 표현한 방식이 가장 명쾌하다. "교대 근무로 일하는 엔지니어들로 구성된 소프트웨어 프로젝트를 상상해보라. 새로 투입되는 엔지니어는 이전 교대에서 무슨 일이 있었는지 전혀 기억하지 못한다." 명시적인 지속성 전략 없이는, 교대가 바뀔 때마다 생산성이 크게 떨어진다.

자기 검증 불가. 모델은 자기 작업을 채점할 때 일관되게 후한 점수를 준다. "다 됐어?"라고 물으면 실제보다 훨씬 자주 "네"라고 답한다. 작업 품질을 별도로 검증하는 기준이 없으면, 30% 완성된 결과물을 자신 있게 배포하는 에이전트를 만들게 된다.

장기 실행 에이전트 설계는 대부분 이 세 가지 문제에 대한 답이다. 주요 AI 연구소들은 비슷한 방향의 해법으로 수렴했지만, 구현의 표면 영역은 각기 다르다.

랄프 루프: 실무자들이 쓰는 단순한 장기 실행 에이전트

랄프 루프(Ralph loop)(때로는 랄프 위검 기법이라고도 불린다)는 Geoffrey Huntley와 Ryan Carson이 알린 장기 실행 에이전트의 비교적 "단순한" 실무 구현 방식이다. 참조 구현은 문자 그대로 하나의 bash 스크립트로, 다음을 반복한다.

목록에서 아직 완료되지 않은 다음 작업을 선택한다(prd.json 또는 동등한 것).
작업, 관련 컨텍스트, 그리고 누적된 메모를 포함한 프롬프트를 구성한다.
에이전트를 호출한다.
테스트나 기타 검사를 실행한다.
발생한 일을 progress.txt에 추가한다.
작업 목록을 업데이트한다(완료, 실패, 차단).
1단계로 돌아간다.

이것이 작동하는 이유는 아래에서 소개할 하네스들이 작동하는 이유와 같다. 상태가 에이전트의 컨텍스트 밖에 존재하기 때문이다. prd.json은 계획이고, progress.txt은 실험 노트이며, AGENTS.md은 수시로 갱신되는 규칙서다. 에이전트 자체는 기억이 없지만, 파일시스템은 그렇지 않다. 각 반복은 새로 시작하지만, 디스크에서 충분한 상태를 읽어들여 작업을 이어간다. Carson의 Compound Product은 이 개념을 여러 루프의 연결로 확장한다. 일일 보고서를 읽는 분석 루프, PRD를 만드는 기획 루프, 코드를 작성하는 실행 루프. 이는 Anthropic이 독자적으로 도달한 플래너-제너레이터-이밸류에이터 3단계 구조의 오픈소스 버전과 거의 같다.

이에 대한 더 자세한 내용은 자기 개선 에이전트(Self-improving agents)에서 다뤘다. 작업 목록 구조, 진행 파일, QA 게이트, 모니터링, 실제로 마주치는 실패 유형까지 포함된다. 짧게 요약하면, bash 스크립트와 JSON 파일 하나만으로도 하룻밤 만에 작동하는 장기 실행 에이전트를 만들 수 있다. Google과 Anthropic이 제품화한 것의 대부분은 이 패턴을 대규모에서도 복구 가능하고, 안전하며, 관측 가능하게 만드는 작업이다.

아래에서 소개할 주요 AI 연구소들의 이야기는 그 프로덕션 수준의 완성도를 위해 각자가 선택한 방식들이다.

Anthropic: 하네스, 그리고 브레인/핸즈/세션 분리

Anthropic은 엔지니어링에 대해 가장 공개적으로 이야기해온 곳이다. 처음부터 끝까지 읽어볼 만한 글이 두 편 있다.

첫 번째는 "장기 실행 에이전트를 위한 효과적인 하네스(Effective harnesses for long-running agents)"로, 자율 풀스택 개발을 위한 2-에이전트 하네스 구조를 설명한다. 초기화 에이전트(initializer agent)는 프로젝트 시작 시 단 한 번 실행되어 환경을 설정하고, 프롬프트를 구조화된 feature-list.json으로 구체화하며, 이후 세션들이 시작 시 실행할 init.sh을 작성한다. 이후 코딩 에이전트(coding agent)가 반복적으로 호출되며, 각 세션에서 기능 하나를 점진적으로 진행하고, 테스트를 실행하고, claude-progress.txt 메모를 남기고, 커밋한다. 프롬프트에는 테스트 래칫("테스트를 삭제하거나 수정하는 것은 기능 누락이나 버그로 이어질 수 있으므로 허용되지 않는다")이 포함되어, 에이전트가 실패한 테스트를 삭제해서 "통과"시키는 흔한 실패 패턴을 차단한다. InfoQ의 분석은 이를 플래너, 제너레이터, 이밸류에이터 3단계 구조로 확장한다. 생성과 평가를 분리하는 것이 중요한 이유가 같기 때문이다. 모델은 자기 작업을 너무 후하게 평가한다.

두 번째는 "관리형 에이전트 확장: 브레인과 핸즈의 분리(Scaling Managed Agents: Decoupling the brain from the hands)"로, Claude Managed Agents(4월 초 출시된 Anthropic의 호스팅 런타임) 뒤에 있는 아키텍처 글이다. 핵심 주장은 에이전트를 세 가지 독립적으로 교체 가능한 구성 요소로 나눠야 한다는 것이다. 브레인(Brain)은 모델과 이를 호출하는 하네스 루프다. 핸즈(Hands)는 도구가 실제로 실행되는 격리된 임시 실행 환경이다. 세션(Session)은 모든 생각, 도구 호출, 관찰 결과가 기록되는 추가 전용 이벤트 로그다.

추상적으로 들리지만 실제로는 그렇지 않다. Anthropic의 표현을 빌리자면, "하네스의 모든 구성 요소는 모델이 스스로 할 수 없는 것에 대한 가정을 담고 있다." 이 구성 요소들을 단단히 결합해두면, 가정 하나가 낡아버렸을 때(예: 모델이 예전에는 명시적인 플래너가 필요했지만 이제 자체적으로 계획을 세운다) 전체 시스템을 한꺼번에 바꿔야 한다. 반면 분리해두면 하네스는 상태가 없어지고, 샌드박스는 가축, 애완동물이 아닌(cattle, not pets) 존재가 되며, 브레인이 충돌해도 실행이 유실되지 않는다. 새 컨테이너가 wake(sessionId)을 호출해 로그에서 상태를 복원한다. Anthropic에 따르면 샌드박스가 준비되기 전에 추론을 미리 시작할 수 있게 됨으로써 p50 기준 첫 토큰 응답 시간이 약 60%, p95에서는 90% 이상 단축됐다고 한다.

세션을 이벤트 로그로 다루는 발상은 대부분의 팀이 과소평가하는 부분이다. 이것이 장기 실행 에이전트를 복구 가능하게 만드는 핵심이다. 이게 없으면 컨테이너 장애가 곧 세션 장애가 되고, 오래된 스냅샷을 뒤져가며 디버깅해야 한다. 이게 있으면 에이전트의 기억은 현재 실행 중인 프로세스 밖에서 독립적으로 존재하는, 쿼리 가능한 결과물이 된다.

과학 컴퓨팅 분야 독자들을 위해 Anthropic의 장기 실행 Claude 포스트는 이를 더 단순한 스택으로 정리한다. 에이전트가 학습하면서 직접 수정하는 살아있는 계획서 CLAUDE.md, 이식 가능한 실험 노트 CHANGELOG.md, 실행 및 조율 레이어인 tmux와 SLURM, git, 그리고 에이전트가 작업 완료를 선언할 때 정말 다 됐는지 다시 확인하도록 컨텍스트로 다시 밀어 넣는 for 루프인 랄프 루프로 구성된다. 대표 사례 연구로, Claude Opus 4.6이 며칠에 걸쳐 구축한 볼츠만 방정식 풀이 코드가 참조 CLASS 구현과 1% 미만의 오차로 일치했다. 연구자가 몇 달에서 몇 년을 들여야 했을 작업이 압축된 결과다.

세 글 모두에서 동일한 패턴이 반복된다. 명시적인 계획 파일, 명시적인 진행 파일, 세션 간 구조화된 핸드오프, 생성과 평가의 분리, 그리고 에이전트가 일찍 멈추지 못하도록 막는 루프.

Cursor: 플래너, 워커, 저지

Cursor의 "장기 실행 자율 코딩 확장(Scaling long-running autonomous coding)"도 올해 반드시 읽어야 할 글이다. Anthropic이 우회한 벽들에 정면으로 부딪혔다.

첫 번째 시도는 수평적 조율 모델이었다. 동등한 지위의 에이전트들이 잠금(lock)을 이용해 공유 파일에 쓰는 방식이었다. 병목이 생기고 에이전트들이 위험을 회피하게 되면서, 커밋하지 않고 제자리를 맴도는 문제가 발생했다. 두 번째 시도에서는 락을 낙관적 동시성 제어(optimistic concurrency control)로 교체했다. 병목은 해소됐지만 조율 문제는 여전했다. 세 번째 설계가 현재 프로덕션에서 돌아가는 것이며, 문제의 대부분을 해결했다고 밝힌 방식이다.

플래너(Planner)는 코드베이스를 지속적으로 탐색하며 작업을 생성한다. 재귀적으로 서브 플래너를 생성할 수 있다.
워커(Worker)는 집중된 실행자다. 다른 워커와 조율하지 않고, 큰 그림도 신경 쓰지 않는다.
저지(Judge)는 반복이 완료됐는지, 재시작이 필요한지를 결정한다.

이 글에서 두 가지가 눈에 띈다. 첫째, "시스템의 동작 중 놀랄 만큼 많은 부분이 하네스나 모델보다 에이전트를 어떻게 프롬프팅하느냐에 달려 있다"는 것이다. 둘째, 다른 모델이 다른 역할에 배치된다. Cursor의 보고에 따르면, 장기 자율 작업에서는 GPT 모델이 Opus보다 나은 성과를 보였는데, Opus가 일찍 멈추고 지름길을 택하는 경향이 있었기 때문이다. 같은 작업이라도 역할이 다르면 모델도 달라진다. 모델 매칭이 설계의 일부가 되고 있다.

이는 Composer 2(Cursor 3에 탑재되는 자체 프론티어 코딩 모델)와 백그라운드 클라우드 에이전트와 연결된다. 백그라운드 클라우드 에이전트는 노트북이 아닌 Anysphere 클라우드 인프라에서 실행되는 장기 실행 작업이다. 8시간짜리 리팩터링이나 코드베이스 전체 마이그레이션도 노트북 뚜껑을 닫아도 중단되지 않는다. 로컬에서 작업을 시작하다가 30분이 걸릴 것 같으면 클라우드에서 실행(run in cloud)을 누르고, 나중에 폰에서 다시 연결할 수 있다. 각 에이전트는 격리된 git 워크트리에서 실행되고 PR을 통해 병합된다. 로컬과 원격 사이의 핸드오프는 아직 대부분의 팀이 해결하지 못한 부분이며, Cursor는 이것이 별도의 제품 영역이 되어야 한다고 보고 있다.

결국 Anthropic과 비슷한 구조다. 역할이 분리되고, 세션이 지속되며, 워커 옆에 저지가 붙고, 장기 작업은 git을 조율 기반으로 삼아 클라우드 샌드박스에서 실행된다.

Google: Agent Platform의 장기 실행 에이전트

2주 전 Cloud Next '26에서 Google은 Vertex AI를 Gemini Enterprise Agent Platform으로 통합하고, 장기 실행 에이전트를 명시적인 SLA가 붙은 하나의 제품으로 공식화했다.

이 글과 관련된 주요 구성 요소는 다음과 같다.

Agent Runtime은 "며칠 동안 자율적으로 실행"하는 에이전트를 지원하며, 1초 미만의 콜드 스타트와 온디맨드 샌드박스 프로비저닝을 제공한다. 공개 사례로 소개된 영업 prospecting 시퀀스는 한 주에 걸쳐 진행되는데, 이 기능이 어떤 형태로 쓰이는지 잘 보여준다.
Agent Sessions는 대화와 이벤트 히스토리를 유지한다. 자체 CRM이나 DB 레코드에 매핑되는 커스텀 세션 ID를 지정할 수 있어, 에이전트 상태가 별도의 AI 사일로가 아닌 비즈니스 상태 옆에 존재한다.
Agent Memory Bank는 장기 메모리 레이어로, Next '26 기준 정식 출시됐다. 세션에서 기억을 추려 사용자 정체성 단위로 범위를 지정하고, 다음 에이전트 호출 시 관련 내용을 가져올 수 있는 검색 API를 제공한다. Payhawk는 Memory Bank 기반 에이전트로 경비 자동 제출 시간을 50% 이상 단축했다고 밝혔다.
Agent Sandbox는 강화된 코드 실행 환경을 담당한다.
Agent-to-Agent Orchestration, Agent Registry, Agent Identity, Agent Gateway, Agent Observability, Agent Simulation은 프로덕션 에이전트 플리트를 운영할 때 직접 만들어야 했던 거의 모든 운영상의 문제를 커버한다. 기업이 실제로 배포하려면 반드시 필요한 암호화 기반 신원 확인 및 감사 로그까지 포함된다.

아키텍처 측면에서 이는 Anthropic이 설명한 것과 동일한 브레인/핸즈/세션 분리 구조다. 다만 플랫폼 규모에서 제품화됐고, ADK(코드 중심 개발 도구)와 Agent Studio(시각적 도구)와 함께 제공된다. Google Cloud 위에서 개발한다면, 세션 로그나 메모리 스토어를 처음부터 설계할 필요가 없다. ADK 에이전트를 Memory Bank와 Sessions에 연결하고 Agent Runtime에 배포하면, 지속성 문제는 해결된다.

Anthropic과 Cursor가 묘사한 패턴과 얼마나 닮았는지 주목할 만하다. 다만 각각 SLA가 붙은 별도 서비스로 분리됐을 뿐이다. 3년 전이라면 이 모든 걸 직접 만들어야 했다. 이제는 "분리된 브레인, 핸즈, 세션" 구조 중 어떤 버전을 빌려 쓸지 선택하면 된다.

프로덕션 장기 실행 에이전트를 위한 5가지 패턴

Shubham Saboo와 내가 정리한 다섯 가지 설계 패턴은, 실제로 작동하는 장기 실행 에이전트와 데모를 구분 짓는 요소들이다. Google에만 국한된 내용은 아니지만, Agent Runtime이 제공하는 프리미티브에 깔끔하게 매핑되므로 여기서 간략하게 짚어볼 가치가 있다.

체크포인트와 재개(Checkpoint-and-resume). 며칠에 걸친 실행에서 가장 흔한 실패 원인은 컨텍스트 유실이다. 에이전트가 4시간에 걸쳐 문서 200개를 처리하다 201번째에서 오류가 나면, 체크포인트가 없으면 처음부터 다시 시작해야 한다. 에이전트를 장기 실행 서버 프로세스처럼 다뤄야 한다. 중간 상태를 디스크에 기록하고, N 단위 작업마다 체크포인트를 남기고, 장애에서 복구한다. Agent Runtime 샌드박스는 영구 파일시스템을 제공하지만, 적절한 체크포인트 단위를 선택하는 건(매 단계마다도, 마지막에만도 아닌) 개발자의 몫이다.

위임된 승인(Delegated approval, 휴먼 인 더 루프). 대부분의 "휴먼 인 더 루프" 구현은 이렇다. 상태를 JSON으로 직렬화하고, 웹훅을 쏘고, 누군가 응답해주길 기다린다. 그 사이 상태는 낡아지고, 알림은 묻히고, 에이전트는 약간 달라진 세계로 역직렬화된다. 장기 실행 런타임은 에이전트가 추론 흐름, 워킹 메모리, 도구 히스토리, 대기 중인 액션 등 전체 실행 상태를 그대로 유지한 채 일시 정지할 수 있게 해준다. 몇 시간의 사람 시간이 흐르는 동안 에이전트는 컴퓨팅을 전혀 소비하지 않으며, 1초 미만의 지연으로 재개된다. Google의 Mission Control이 이를 위한 받은 편지함 역할을 한다. 이 패턴은 벤더에 상관없이 적용 가능하다.

메모리 레이어드 컨텍스트(Memory-layered context). 7일짜리 에이전트에는 세션 상태 이상이 필요하다. Memory Bank는 장기 큐레이션 메모리를, Memory Profiles는 저지연 조회를 담당한다. 프로덕션에서 실제로 겪게 되는 실패 유형은 메모리 드리프트(memory drift)다. 에이전트가 몇 가지 비전형적인 상호작용에서 절차적 지름길을 학습하고 이를 광범위하게 적용하기 시작하는 현상이다. 메모리를 마이크로서비스 관리하듯 통제해야 한다. Agent Identity는 어떤 에이전트가 어떤 메모리 뱅크를 읽고 쓸 수 있는지 제어하고, Agent Registry는 어떤 버전의 에이전트가 실행 중인지 추적하며, Agent Gateway는 통신 레이어에서 정책을 집행한다. 감사 대상이 "내 에이전트가 무엇을 하고 있는가?"에서 "내 에이전트가 무엇을 기억하고 있으며, 그것이 행동에 어떤 영향을 미치는가?"로 바뀐다.

앰비언트 처리(Ambient processing). 모든 장기 실행 에이전트가 사람과 대화하는 건 아니다. 일부는 Pub/Sub 스트림이나 BigQuery 테이블에 상주하며 이벤트 발생 시 행동한다. 콘텐츠 모더레이션, 이상 탐지, 수신함 분류 같은 것들이다. 설계 초반에 내려야 할 중요한 결정은 정책을 에이전트에 하드코딩하지 않는 것이다. Gateway에 정의해두면 플리트 전체가 재배포 없이 정책 변경을 반영할 수 있다. 앰비언트 에이전트는 장시간 비지도 상태로 실행되며, 수백 개를 업데이트하는 유일한 현실적인 방법은 정책 레이어를 한 번만 수정하는 것이다.

플리트 오케스트레이션(Fleet orchestration). 실제 시스템에서 에이전트는 하나가 아니다. 코디네이터가 전문화된 에이전트들(리드 리서처 에이전트, 스코어링 에이전트, 아웃리치 에이전트)에게 하위 작업을 위임하고, 각각이 서로 다른 기간 동안 독립적으로 실행된다. 각 전문 에이전트는 자체 Identity(아웃리치 에이전트가 스코어링용 재무 데이터를 읽지 못하도록), 자체 정책 집행, 자체 Registry 항목을 갖는다. 이는 분산 시스템이 수십 년간 사용해온 코디네이터/워커 구조와 같다. 새로운 점은 ADK가 이를 그래프 기반 워크플로로 선언적으로 처리하고, 특정 전문 에이전트의 잘못된 배포가 다른 에이전트로 전파되지 않는다는 것이다.

이 패턴들은 서로 조합된다. 컴플라이언스 시스템이라면 문서 처리에 체크포인트, 검토 게이트에 위임된 승인, 세션 간 지식 공유에 메모리 레이어링, 전문 에이전트 조율에 플리트 오케스트레이션을 함께 쓸 수 있다. 항상 같은 질문에서 시작한다. 에이전트가 수행해야 하는 가장 긴 단일 작업의 소요 시간은 얼마인가? 몇 분 단위라면 장기 실행 에이전트가 필요 없다. 몇 시간이나 며칠이라면, 이 패턴들이 출발점이 된다. 코드 예제가 포함된 전체 글에서 각 패턴을 깊이 있게 다룬다.

그래서 지금 당장 어떻게 만들 수 있나?

현실적인 질문이고, 무엇을 만드느냐에 따라 답이 달라진다.

자신의 저장소에서 장기 실행 코딩 작업이 필요한 개발자라면. Claude Code(또는 Antigravity, Cursor, Codex)를 그냥 쓰면 된다. 하네스는 이미 갖춰져 있다. AGENTS.md은 파일럿의 체크리스트처럼 다뤄라. 짧게, 실제 실패를 겪고 나서 한 줄씩 추가하는 방식으로. 타입 검사와 린트 훅을 추가해 실패가 에이전트에게 피드백되도록 하라. 에이전트가 시작하기 전에 계획 파일을 작성하라. 에이전트가 완료됐다고 하는데 믿기지 않을 때는 랄프 루프를 써라. 몇 시간이 걸리거나 밤새 실행해야 하는 작업은 노트북을 닫아도 중단되지 않도록 워크트리에서 실행하고, 의미 있는 단위마다 진행 상황을 커밋하도록 하라. 대부분의 사람에게 가장 권장할 만한 방법이고, 지금 당장 가장 큰 레버리지를 얻을 수 있는 지점이다.

호스팅 에이전트 제품을 만들고 있다면. 런타임은 직접 만들지 마라. 관리형을 선택하라. 현재 진짜 선택지는 세 가지다. Google Agent Platform(Agent Engine + Memory Bank + Sessions), Claude Managed Agents, 또는 ADK, Claude Agent SDK, Codex SDK 위에서 직접 구성해 자체 호스팅하는 방식이다. 트레이드오프는 언제나 같다. 관리형을 선택하면 브레인/핸즈/세션 분리, 관측 가능성, 신원 관리, 감사 추적이 기본으로 따라온다. 자체 호스팅을 선택하면 제어권을 갖고, 각 역할에 특이한 모델을 쓸 수 있다(Cursor의 방식). 대부분의 팀에게 올바른 출발점은 관리형 런타임에 자체 ADK 또는 SDK 코드로 실제 루프를 구현하는 것이다.

자율적이고 운영적인 목적(모니터링, 리서치, 운영)으로 쓴다면. Memory Bank 방식의 지속성이 필요한 영역이고, Claude Code에는 없는 부분이다. ADK + Memory Bank + Cloud Run + Cloud Scheduler 조합이 "N시간마다 에이전트 실행, 상태 축적, 임계값 도달 시 알림" 구조로는 가장 깔끔한 스택이다. 작업이 실질적으로 병렬이고 실패 유형도 다르기 때문에, IDE 코딩보다 Cursor의 플래너/워커/저지 분리가 더 중요해지는 영역이기도 하다.

어떤 방향을 선택하든 공통으로 중요한 것들이 있다.

에이전트가 시작하기 전에 완료 조건을 문서화하라. 장기 실행에서 레버리지가 가장 큰 단 하나의 행동이다. Anthropic 하네스 포스트에서는 기능 목록이라 부르고, Cursor에서는 플래너의 태스크 스펙이라고 한다. 어떻게 부르든, 명시적이고 테스트 가능한 완료 기준이 담긴 외부 파일이어야 한다. 에이전트가 실행 중에 완료의 정의를 몰래 바꾸지 못하도록 하는 것이 목적이다.

이밸류에이터와 제너레이터를 분리하라. 자기 채점은 실패 패턴이다. 플래너/워커/저지 파이프라인, 또는 제너레이터/이밸류에이터 쌍은 스타일 선호가 아닌 진짜 아키텍처 패턴이다. 같은 모델을 다른 역할에, 다른 프롬프트로 쓰더라도 마찬가지다.

프롬프트가 아니라 세션 로그에 투자하라. 추가 전용 이벤트 로그가 에이전트를 복구 가능하고, 디버깅 가능하고, 감사 가능하게 만드는 것이다. 영구 저장소에서 지난 24시간 동안 에이전트가 한 일을 재구성할 수 없다면, 그것은 LLM을 호출하는 장기 실행 셸 스크립트일 뿐, 장기 실행 에이전트가 아니다.

압축과 컨텍스트 리셋을 1급 시민으로 다뤄라. Anthropic은 매우 긴 작업에서 요약을 통한 압축으로는 부족했다고 명시했다. 하네스가 세션을 해체하고 구조화된 핸드오프 파일에서 재구성하는 완전한 컨텍스트 리셋이 필요했다. 이는 본질적으로 새 엔지니어를 온보딩하는 방식과 같다.

현재 남아있는 진짜 한계들

아직 해결되지 않은 문제들이 있다.

비용. 프론티어 모델과 몇 가지 도구를 사용하는 24시간짜리 실행은 결코 저렴하지 않다. 예산, 서킷 브레이커, 도구 사용에 대한 하드 상한을 설정하지 않으면, 에이전트가 조용히 오후 한나절 만에 일주일치 API 예산을 소진할 수 있다. 해결 가능한 문제지만, 반드시 명시적으로 처리해야 한다.

보안. API 키, 클라우드 접근 권한, 셸 명령 실행 능력을 가진 장기 실행 에이전트는 채팅 세션보다 훨씬 넓은 공격 표면을 갖는다. 브레인/핸즈 분리 패턴이 여기서도 중요하다. 모델이 생성한 코드가 실행되는 샌드박스에서는 자격 증명에 접근할 수 없어야 한다. Anthropic이 Managed Agents의 장점으로 명시하는 부분이기도 하다.

정렬 드리프트(Alignment drift). 여러 컨텍스트 윈도우를 거치면 에이전트는 흐트러진다. 원래 목표가 요약되고, 다시 요약되면서 충실도가 떨어진다. 훅과 저지가 방어하기 위해 존재하는 것이 바로 이 문제다. "에이전트가 내가 요청하지 않은 일을 했다"는 가장 흔한 원인이기도 하다.

검증. 24시간의 자율 활동을 감사하는 것은 실질적으로 사람의 시간이 많이 드는 문제다. 관측 가능성과 구조화된 결과물(PR, 커밋, 브리핑, 테스트 실행 결과)이 이를 감당 가능하게 만드는 방법이다. 이것 없이는 로그를 스크롤하다가 중요한 걸 놓친다.

사람의 역할. 계속 돌아오게 되는 문제다. 에이전트가 하루 동안 실행할 수 있을 만큼 작업을 명확하게 정의하는 것은 그 작업을 직접 하는 것보다 어렵다. 가치가 높아지는 역량은 코드를 작성하는 능력이 아니다. 자율 실행자와 맞닿았을 때도 살아남는 스펙을 작성하는 능력이다.

앞으로의 방향

Google, Anthropic, Cursor는 대략 같은 구조로 수렴했다. 모델 루프와 실행 샌드박스와 지속 세션 로그를 분리하라. 계획과 생성과 평가를 나눠라. 압축, 훅, 컨텍스트 리셋을 기본으로 내장하라. 메모리를 모든 에이전트 호출이 쿼리할 수 있는 관리형 서비스로 제공하라.

차이는 표면 영역에 있다. Google Agent Platform은 신원 확인과 감사 추적을 기본으로 탑재한 엔터프라이즈 스택 버전이다. 패턴은 같다. Claude Managed Agents는 "Anthropic의 하네스, 호스팅 버전"이다. Cursor의 백그라운드 에이전트는 "장기 실행 코딩을 IDE 밖으로 꺼내 클라우드로"다.

다음 1년의 더 어려운 문제는 그 레이어들 각각이 아니라, 그 위에 있는 조율에 있다. 공유 코드베이스에서 동시에 실행되는 여러 장기 실행 에이전트. 자신의 트레이스를 읽고 자체 하네스를 수정하는 에이전트. 시작 시점에 미리 설정된 것이 아니라 작업에 맞게 도구와 컨텍스트를 즉석에서 조립하는 하네스. 그 지점에서 에이전트는 더 영리한 채팅 창처럼 보이는 것을 멈추고, 당신보다 오래 프로젝트에 있었던 동료처럼 보이기 시작한다.

모델은 여전히 핵심이다. 하지만 채팅 창과 밤새 돌려놓을 수 있는 에이전트 사이의 간극은 대부분 모델을 감싸는 상태, 세션, 구조화된 핸드오프에 있다. 지금 당장 학습 시간을 투자한다면, 바로 그 부분이다.

사전 독서가 필요하다면, 에이전트 하네스 엔지니어링(Agent Harness Engineering) 포스트에서 이 글이 전제하는 하네스 프리미티브를 다루고 있고, 자기 개선 에이전트(Self-improving agents)에서는 랄프 루프 패턴을 더 깊이 살펴본다.