장기 실행 에이전트(Long-running Agents)

장기 실행 AI 에이전트는 여러 시간, 며칠, 심지어 몇 주에 걸쳐 계속해서 일을 진행할 수 있는 에이전트입니다. 여러 개의 컨텍스트 윈도우와 샌드박스를 넘나들면서도, 실패에서 복구하고, 구조화된 산출물을 남기며, 중단된 지점에서 다시 이어서 작업할 수 있습니다.

지난 2년 동안 우리가 떠올리는 전형적인 “AI 에이전트”는 약간 영리한 루프를 얹은 채팅 창에 가깝습니다. 사용자가 목표를 입력하면, 에이전트가 몇 가지 툴을 호출하고, 토큰이 흘러나오는 걸 지켜보다가, 인내심이 다하거나 컨텍스트 윈도우가 가득 차면 작업이 멈추는 식이었죠. 이 패러다임은 꽤 멀리까지 우리를 데려다주었지만, 분명한 한계가 있습니다. 모델은 금방 잊어버립니다. 실제로는 끝나지 않았는데 “작업 완료”를 선언합니다. 아홉 턴 전에 고쳤던 버그를 다시 도입하기도 합니다. 전체 구조 자체가 한 번에 끝나는 “한 세션”을 전제로 설계되어 있기 때문입니다.

장기 실행 에이전트는 그다음 단계입니다. 아이디어 자체는 단순합니다. 여러 세션과 여러 샌드박스, 어쩌면 며칠 또는 몇 주에 걸쳐서도 어떤 목표에 대해 계속 전진(progress)을 이어가는 에이전트죠. 그리고 다음 세션이 이전 세션이 끝났던 지점부터 자연스럽게 이어받을 수 있을 만큼 작업 공간을 깔끔하게 유지하는 에이전트이기도 합니다. 엔지니어링은 훨씬 어렵습니다. 단순히 땜질하는 수준이 아니라, 지속성(persistence), 복구(recovery), 검증(verification)을 제대로 해결해야 합니다. 모델의 컨텍스트 윈도우 바깥에 존재하는 상태(state) 계층을 만들어야 하고, 세션 간 핸드오프를 설계해서, 에이전트가 “다른 샌드박스와 다른 컨텍스트 윈도우”에서 깨어났을 때 제정신을 잃지 않도록 해야 합니다.

이 글은 무엇이 달라졌는지, 누가 이 문제를 밀어붙이고 있는지, 그리고 엔지니어가 이 모든 것을 처음부터 직접 구현하지 않고도 오늘날 장기 실행 에이전트를 어떻게 활용할 수 있는지에 대한 정리입니다.

“장기 실행(long-running)”이 실제로 의미하는 것

실제 현업에서는 “long-running”이라는 말을 최소 세 가지 다른 의미로 쓰고 있습니다. 이 셋을 구분해서 보는 것이 도움이 됩니다.

장기 범위 추론(Long-horizon reasoning). 에이전트가 많은 수의 의존적인 단계를 계획하고 실행해야 하는 경우입니다. 이 영역은 대부분 모델 품질의 문제입니다. 일관성, 계획 능력, 열 단계 전에 한 잘못된 선택에서 다시 회복하는 능력 같은 것들이죠. METR는 이를 time horizon 이라는 지표로 추적하고 있는데, 이는 최전선(frontier) 모델이 50% 신뢰도로 완료할 수 있는 작업의 길이를 추정합니다. 핵심 결과는, 이 지표가 2019년 이후 약 7개월마다 두 배가 되어 왔다는 점입니다. 그리고 올해 초 발표된 TH1.1 업데이트는 8시간 이상 걸리는 작업의 개수를 두 배로 늘렸습니다. 이 곡선이 그대로 유지된다면, 최전선 에이전트는 2028년쯤에는 ‘하루 단위’ 작업을, 2034년쯤에는 ‘연 단위’ 작업을 완수할 수 있게 됩니다.

장기 실행(Long-running execution). 에이전트의 프로세스 자체가 여러 시간, 여러 날 동안 계속 돌아가는 경우입니다. 코드 작업일 수도 있고, 리서치 스윕일 수도 있고, 24/7 모니터링 서비스일 수도 있습니다. 이 기간 동안 모델은 수천 번 호출될 수도 있습니다. 이 영역은 대부분 하니스(harness) 설계의 이야기이고, 이 글에서 주로 다루는 부분이기도 합니다.

지속적인 에이전시(Persistent agency). 에이전트가 개별 작업을 넘어서는 아이덴티티를 갖는 경우입니다. 시간을 두고 기억을 축적하고, 사용자 선호를 학습하고, 언제나 사용할 수 있는 상태를 유지합니다. 이쪽은 Memory Bank 스타일의 장기 실행 형태입니다.

실제 프로덕션 에이전트에서는 이 셋이 섞여 있습니다. 현실적인 서비스에서는 장기 실행 안에서 장기 범위 추론이 돌아가고, 그 뒤에는 지속적인 에이전시 가 받치고 있는 구조가 됩니다. 하지만 각 영역에서 부딪히는 엔지니어링 문제는 서로 다르고, 이를 해결하는 제품들도 다릅니다.

왜 이게 중요한가

제가 지금 이 작업이 매우 중요하다고 보는 이유는 두 가지입니다.

첫 번째는, 경제적으로 “위임(delegate)”할 수 있는 일의 범위가 상전이(phase change)를 겪고 있기 때문입니다. 10분 동안만 돌아가는 에이전트는 질문에 답하거나, 문서를 요약하거나, 작은 버그 하나를 고치는 정도까지 할 수 있습니다. 10시간 동안 돌아가는 에이전트는 전체 기능(feature)을 통째로 맡거나, 6분기째 백로그에 쌓여 있던 마이그레이션을 끝내거나, 예전에는 주니어 애널리스트가 밤새 뛰어야 했던 수준의 리서치 스윕을 수행할 수 있습니다. Anthropic이 작년 가을 Claude Sonnet 발표에서 이를 숫자로 잘 보여줬습니다. 내부 테스트에서 30시간 이상 자율 코딩을 진행했고, 그 중 한 번의 실행은 11,000줄 규모의 Slack 스타일 앱을 만들어 냈습니다. 이 정도면 이미 “이걸 진짜 에이전트에게 맡겨야 할까?”라는 질문이 더 이상 자명하지 않은 수준까지 온 겁니다.

두 번째는, 지속성이 에이전트의 정체성을 근본적으로 바꾸기 때문입니다. 상태가 없는(stateless) 에이전트는 질문에 답하고 사라집니다. 장기 실행 에이전트는 컨텍스트를 축적합니다. 지난주에 어느 경쟁사가 어떤 방향으로 움직였는지, 화요일에 어떤 테스트가 두 번 플레이크(flake)났는지, 당신이 보통 “그 대시보드”라고 말할 때 무엇을 의미하는지 같은 것들입니다. Anthropic의 Project Vend는 이걸 가장 공개적으로 보여준 초기 사례였습니다. Claude 인스턴스에 실제 사무실 자판기 사업을 한 달 동안 맡겨서, 재고 관리, 가격 설정, 공급업체와의 커뮤니케이션을 모두 처리하게 했습니다. 물론 시행착오가 많았고, 두 번째 단계는 훨씬 잘 돌아갔지만, 포인트는 수익성이 아니었습니다. 몇 주가 아니라 몇 턴 단위가 아닐 때, 에이전트가 어떤 이상한 일관성(coherence) 문제를 드러내는지 지켜보는 실험이었죠.

지금 프로덕션 에이전트를 만드는 모든 팀이 겪고 있는 문제들이 바로 이 문제들입니다.

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

올해 제가 읽은 대부분의 글에서 공통으로 등장하는 세 가지 벽이 있습니다.

유한한 컨텍스트. 100만 토큰짜리 윈도우도 결국은 찹니다. 게다가 하드 리밋에 도달하기 훨씬 전부터 컨텍스트 부식(context rot) — 윈도우가 꽉 차갈수록 모델 성능이 서서히 떨어지는 현상 — 이 시작됩니다. 24시간짜리 실행을 지금 로드맵에 있는 어떤 컨텍스트 윈도우에도 그대로 욱여넣을 수는 없습니다. 뭔가 다른 해법이 필요합니다.

지속 상태 없음. 새로운 세션은 늘 백지 상태에서 시작합니다. Anthropic이 과학 컴퓨팅 포스트에서 제시한 비유가 가장 깔끔합니다. “매번 새로 출근하는 엔지니어가 이전 근무자가 무엇을 했는지 전혀 모르는 상태에서 교대하는 소프트웨어 프로젝트를 떠올려보라.” 명시적인 지속성 전략이 없으면, 교대할 때마다 생산성이 붕괴합니다.

자기 검증 부재. 모델이 스스로를 채점할 때는 일관되게 긍정 편향이 있습니다. “끝났냐?”고 물으면, 실제보다 훨씬 자주 “예”라고 답합니다. 작업이 기준을 충족했다는 별도의 신호가 없다면, 진행률이 30%밖에 안 되는데도 자신 있게 “완료”라고 선언하는 에이전트를 얻게 됩니다.

장기 실행 에이전트 설계는 대부분 이 세 문제에 대한 답입니다. 대형 랩들은 서로 비슷한 형태의 답에 수렴해 왔지만, 노출되는 표면적은 꽤 다릅니다.

Ralph 루프: 실무에서 쓰이는 비교적 단순한 장기 실행 에이전트 패턴

Ralph 루프(가끔 Ralph Wiggum 기법이라고도 불립니다)는 실무에서 쓰이는 비교적 “단순한” 장기 실행 에이전트 패턴 중 하나로, Geoffrey Huntley와 Ryan Carson이 널리 알렸습니다. 레퍼런스 구현은 말 그대로 bash 스크립트 하나인데, 루프는 다음과 같이 돕니다.

1. 작업 목록(prd.json⁠ 등)에서 아직 끝나지 않은 다음 작업을 하나 고른다.
2. 해당 작업, 관련 컨텍스트, 지속 노트 등을 포함해 프롬프트를 구성한다.
3. 에이전트를 호출한다.
4. 테스트나 기타 체크를 실행한다.
5. 진행 상황을 progress.txt⁠에 append 한다.
6. 작업 목록을 업데이트한다(완료, 실패, 블록됨 등으로 상태 변경).
7. 1단계로 돌아간다.

이 패턴이 잘 작동하는 이유는, 아래에서 소개할 다른 하니스들과 마찬가지로 “상태를 에이전트 컨텍스트 바깥에 두기” 때문입니다. prd.json⁠은 플랜이고, progress.txt⁠는 실험 노트이며, AGENTS.md⁠는 롤링 룰북입니다. 에이전트 자체는 기억을 못 해도, 파일 시스템은 기억합니다. 매 반복(iteration)은 항상 새로 시작하지만, 디스크에서 필요한 상태를 다시 읽어와 자연스럽게 이어갈 수 있습니다. Carson의 Compound Product는 이 아이디어를 확장해 여러 루프를 체인으로 엮습니다. 데일리 리포트를 읽는 분석 루프, PRD를 생성하는 기획 루프, 코드를 작성하는 실행 루프 같은 식이죠. 이는 Anthropic이 독립적으로 도달한 planner–generator–evaluator 3단계 구조의 오픈소스 버전과도 매우 비슷합니다.

이 주제에 대해서는 제가 Self-improving agents에서 더 깊게 다루었습니다. 작업 리스트 구조, 진행 파일, QA 게이트, 모니터링, 실제로 부딪히게 될 실패 모드까지요. 짧게 요약하면, bash 스크립트 하나와 JSON 파일만으로도 하루 저녁이면 쓸 만한 장기 실행 에이전트를 만들 수 있다는 것입니다. 다만 Google과 Anthropic이 이후에 제품화한 부분은 이 패턴을 “복구 가능하고, 안전하며, 관측 가능한 형태로” 스케일링하는 데에 들어간 작업들입니다.

아래에서 살펴볼 대형 랩들의 스토리는, 결국 이 프로덕션 레벨 준비성을 어떻게 비용으로 치르느냐의 다른 버전이라고 볼 수 있습니다.

Anthropic: 하니스, 그리고 brain/hands/session 분리

Anthropic은 이 분야에서 엔지니어링 내용을 가장 공개적으로 공유해 온 곳입니다. 꼭 처음부터 끝까지 읽어볼 만한 글이 두 개 있습니다.

첫 번째는 “Effective harnesses for long-running agents”입니다. 여기서는 자율 풀스택 개발을 위한 2-에이전트 하니스를 설명합니다. initializer 에이전트는 프로젝트 시작 시 한 번만 실행되어 환경을 세팅하고, 프롬프트를 구조화된 feature-list.json⁠으로 확장하고, 이후 세션에서 부팅 시마다 실행할 init.sh⁠를 작성합니다. 이후에는 coding 에이전트가 반복해서 깨어나, 각 세션마다 하나의 기능에 대해 점진적인 진전을 만들어내고, 테스트를 실행하고, claude-progress.txt⁠에 노트를 남기고, 커밋하도록 합니다. 여기에 테스트 래칫(ratchet) — “테스트를 삭제하거나 수정해서 통과시키는 것은 절대 허용되지 않는다. 이는 기능 누락이나 버그를 야기할 수 있기 때문이다” — 를 프롬프트에 명시해, 실패하는 테스트를 그냥 지워버리는 에이전트의 매우 흔한 실패 모드를 막습니다. InfoQ의 정리 글은 이를 planner, generator, evaluator 삼각 구조로 확장해 설명합니다. 모델은 자기 작업을 관대하게 채점하는 경향이 있기 때문에, 생성과 평가를 분리하는 것이 중요하다는 논리입니다.

두 번째는 “Scaling Managed Agents: Decoupling the brain from the hands”입니다. 이는 4월 초에 출시된 Claude Managed Agents (Anthropic에서 제공되는 런타임)의 아키텍처를 설명하는 글입니다. 요지는, 에이전트에는 독립적으로 교체 가능한 세 가지 컴포넌트가 있다는 것입니다. Brain은 모델과 이를 호출하는 하니스 루프입니다. Hands는 실제로 툴이 실행되는 샌드박스이자 단명(ephemeral) 실행 환경입니다. Session은 생각, 툴 호출, 관측 결과를 모두 기록한 append-only 이벤트 로그입니다.

이런 이야기는 추상적으로 들리지만 사실 매우 구체적인 설계입니다. Anthropic의 표현대로라면, “하니스의 모든 컴포넌트는 모델이 혼자서는 할 수 없는 것에 대한 가정을 코드로 표현한 것” 입니다. 이 컴포넌트들이 서로 강하게 결합되어 있으면, 어떤 가정이 더 이상 유효하지 않을 때(예: 예전에는 모델이 계획을 따로 필요로 했지만, 이제는 자체적으로 잘 계획한다), 시스템 전체를 한꺼번에 고쳐야 합니다. 반대로 이들을 분리해 두면, 하니스는 상태가 없는(stateless) 레이어가 되고, 샌드박스는 애완동물이 아니라 가축(cattle)이 되며, brain이 크래시해도 실행 중인 런 전체를 잃지 않습니다. 새로운 컨테이너는 wake(sessionId)⁠를 호출해서 로그로부터 상태를 복원합니다. Anthropic은 이러한 구조 덕분에, 샌드박스 준비가 끝나기 전에 추론을 먼저 시작할 수 있게 되면서 time-to-first-token이 p50 기준 약 60%, p95 기준 90% 이상 줄었다고 보고했습니다.

session-as-event-log 개념은 대부분의 팀이 과소평가하는 부분입니다. 이게 장기 실행 에이전트를 “복구 가능한 것”으로 만들어 줍니다. 이게 없으면, 컨테이너가 죽는 순간 세션 자체가 죽어버리고, 이미 오래된 스냅샷을 디버깅해야 합니다. 이게 있으면, 에이전트의 메모리가 현재 실행 중인 프로세스와 독립된, 질의 가능한 아티팩트로 남게 됩니다.

과학 컴퓨팅 쪽을 보면, Anthropic의 장기 실행 Claude 포스트는 이를 더 단순한 스택으로 정리합니다. CLAUDE.md⁠는 에이전트가 학습해 가며 계속 편집하는 살아 있는 플랜 문서, CHANGELOG.md⁠는 휴대 가능한 연구 노트, tmux + SLURM + git⁠은 실행 및 조정 레이어입니다. 여기에 Ralph 루프라는, 에이전트가 작업 완료를 주장할 때마다 “정말 끝난 게 맞느냐”고 다시 묻고, 아니라면 다시 컨텍스트 안으로 되돌리는 for⁠ 루프가 있습니다. 대표적인 사례는 며칠에 걸쳐 Claude Opus 4.6이 만든 볼츠만 해석기(Boltzmann solver)입니다. 이는 기존 CLASS 구현과의 오차를 1% 이내로 맞추며, 연구자 몇 달~몇 년 분량의 일을 압축해서 수행했습니다.

세 글에서 공통으로 보이는 패턴은 같습니다. 명시적인 플랜 파일, 명시적인 진행 파일, 세션 간 구조화된 핸드오프, 생성과 평가의 분리, 그리고 에이전트가 너무 일찍 멈추지 못하게 막는 루프입니다.

Cursor: planner, worker, judge

Cursor의 “Scaling long-running autonomous coding”은 올해 읽어야 할 또 하나의 핵심 글입니다. 이 글에서는 Anthropic이 다소 추상적으로 넘어간 벽들을 Cursor가 정면으로 마주한 이야기가 나옵니다.

첫 번째 설계는 평면(flat)한 조정 모델이었습니다. 동등한 권한을 가진 에이전트들이 잠금(lock)을 사용해 공유 파일에 쓰기를 조율하는 구조였습니다. 이는 곧 병목이 되었고, 에이전트들이 지나치게 위험을 회피하면서, 커밋 대신 같은 곳을 맴도는 상황을 만들었습니다. 두 번째 시도에서는 락을 낙관적 동시성 제어(optimistic concurrency control)로 바꾸어 병목은 줄였지만, 조정 문제 자체는 해결하지 못했습니다. 세 번째 설계가 현재 프로덕션에서 돌아가는 구조이며, Cursor가 “대부분의 문제를 해결했다”고 표현하는 모델입니다.

• Planners는 코드베이스를 지속적으로 탐색하고, 작업(task)을 만들어 냅니다. 필요하면 재귀적으로 하위 플래너를 스폰(spawn)할 수 있습니다.
• Workers는 집중된 실행자입니다. 서로 간 조정을 신경 쓰지 않고, 큰 그림을 고민하지도 않습니다.
• Judges는 언제 한 이터레이션이 끝났는지, 언제 다시 시작해야 하는지를 결정합니다.

이 글에서 특히 눈에 띄는 점은 두 가지입니다. 첫째, “시스템의 행동 대부분은 하니스나 모델 자체보다, 에이전트들을 어떻게 프롬프트하느냐에 의해 결정된다” 는 점입니다. 둘째, 역할에 따라 다른 모델을 쓰는 구조입니다. Cursor는 “길게 자율적으로 작업하는” 용도에는 GPT 계열 모델이 Opus보다 더 낫다고 보고했습니다. Opus는 중간에 멈추거나, 지름길을 택하려는 경향이 있었기 때문입니다. 같은 작업이더라도, 역할이 달라지면 쓰는 모델도 달라지는 셈입니다. 이 매칭 자체가 설계의 한 축이 되어가고 있습니다.

이 구조는 Composer 2 (Cursor 3에 포함된 자체 프런티어 코딩 모델)와 백그라운드 클라우드 에이전트와 연결됩니다. 이는 Anysphere의 클라우드 인프라에서 돌아가는 장기 실행 작업입니다. 8시간짜리 리팩터링이나 코드베이스 전역 마이그레이션이 노트북 덮는다고 죽지 않습니다. 로컬에서 작업을 시작해 보다가, 30분 이상 걸릴 것 같으면 run in cloud 버튼을 눌러 클라우드로 넘기고, 나중에 휴대폰에서 다시 붙을 수도 있습니다. 각 에이전트는 격리된 git worktree에서 작업하고, 최종 결과는 PR 형태로 다시 메인 브랜치에 합쳐집니다. 로컬과 리모트 사이의 핸드오프는 대부분의 팀이 아직 제대로 풀지 못한 부분인데, Cursor는 이걸 아예 별도의 제품 경험으로 바라보는 쪽에 베팅하고 있습니다.

전체적인 모양은 Anthropic과 매우 비슷해집니다. 역할이 분리되어 있고, 세션이 내구성을 갖고 있으며, worker 옆에 judge가 있고, 오래 걸리는 작업은 클라우드 샌드박스에서 돌아가며 git이 조정의 공통 기반이 됩니다.

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

2주 전 Cloud Next ‘26에서 Google은 Vertex AI를 Gemini Enterprise Agent Platform에 통합하며, 장기 실행 에이전트를 이름 있는 제품, 이름 있는 SLA를 가진 기능으로 공식화했습니다.

이 글과 관련해 중요한 구성 요소는 다음과 같습니다.

• Agent Runtime은 “며칠 동안 자율적으로 실행되는 에이전트” 를 지원하며, 서브세컨드 콜드 스타트와 온디맨드 샌드박스 프로비저닝을 제공합니다. 런칭 글에서 예시로 든 유스케이스는, 일주일 동안 이어지는 세일즈 프로스펙팅 시퀀스였는데, 이는 Agent Runtime이 겨냥하는 작업의 모양새를 잘 보여줍니다.
• Agent Sessions는 대화 및 이벤트 히스토리를 지속적으로 보존합니다. 이를 사용자 측 CRM이나 DB 레코드에 매핑되는 커스텀 세션 ID와 연결할 수 있어, 에이전트의 상태가 별도의 AI 사일로가 아니라 기존 비즈니스 상태 옆에 붙어 있게 할 수 있습니다.
• Agent Memory Bank 는 장기 메모리 레이어로, Next ‘26 시점에서 GA(일반 공급) 상태입니다. 세션에서 유용한 메모리를 선별해 저장하고, 이를 사용자 아이덴티티 단위로 스코프(scope)하며, 다음 에이전트 호출이 관련 메모리를 조회할 수 있는 검색 API를 제공합니다. Payhawk는 Memory Bank 기반 에이전트를 사용해 경비 지출 자동 제출 시간을 50% 이상 줄였다고 보고했습니다.
• Agent Sandbox는 강화된 코드 실행 환경을 제공합니다.
• Agent-to-Agent Orchestration, Agent Registry, Agent Identity, Agent Gateway, Agent Observability, Agent Simulation 등은 프로덕션 에이전트 플릿을 직접 구축할 때 필요한 거의 모든 운영 관점을 다룹니다. 암호화된 아이덴티티와 감사 로그까지 포함한 엔터프라이즈 수준의 요구사항도 이 안에 녹아 있습니다.

아키텍처 관점에서 보면, 이는 Anthropic이 설명한 brain/hands/session 분리와 본질적으로 동일한 구조를 플랫폼 수준에서 제품화한 것입니다. 여기에 ADK (코드 기반 개발 키트)와 Agent Studio(비주얼 빌더)가 덧붙습니다. Google Cloud 안에서 개발한다면, 이제 세션 로그나 메모리 스토어를 처음부터 설계할 필요 없이, ADK 기반 에이전트를 Memory Bank와 Sessions에 연결하고, Agent Runtime에 배포하면 지속성 계층은 기본으로 해결됩니다.

Anthropic과 Cursor가 설명한 패턴과 거의 같은 모양을 띠지만, 이를 이름 붙은 서비스와 SLA로 분리해 제공한다는 점이 다릅니다. 3년 전이라면 이 모든 것을 직접 만들어야 했습니다. 지금은 “분리된 brain–hands–session”의 어떤 버전을 빌려 쓸지만 고르면 됩니다.

프로덕션 장기 실행 에이전트에서 공통으로 보이는 다섯 가지 패턴

Shubham Saboo와 저는 별도의 글에서 장기 실행 에이전트를 데모 수준에서 프로덕션 수준으로 끌어올리는 데 중요한 다섯 가지 설계 패턴을 정리했습니다. Google 전용 패턴은 아니지만, Agent Runtime이 노출하는 프리미티브와 잘 맞아떨어지기 때문에, 여기서는 짧게 요약해 보겠습니다.

체크포인트–리줌(checkpoint-and-resume). 며칠짜리 작업에서 가장 흔한 실패는 컨텍스트 손실입니다. 에이전트가 4시간 동안 200개의 문서를 처리하다가, 201번째 문서에서 에러를 만나면, 체크포인트가 없다면 처음부터 다시 시작해야 합니다. 에이전트를 장기 실행 서버 프로세스로 생각하고, 디스크에 중간 상태를 기록하고, N개 단위의 작업마다 체크포인트를 남기고, 실패 시 그 지점에서 복구하도록 설계해야 합니다. Agent Runtime 샌드박스는 지속 파일 시스템을 제공하지만, 얼마나 자주 체크포인트를 찍을지는 개발자가 직접 결정해야 합니다. (매 단계마다 찍는 것도, 마지막에만 찍는 것도 모두 좋지 않습니다.)

위임 승인(Delegated approval, 사람-개입 구조). 대부분의 “human-in-the-loop” 구현은 현실적으로 다음과 같습니다. 상태를 JSON으로 직렬화하고, 웹훅을 날려 누군가가 응답하기만을 기도합니다. 그러면 상태는 금방 낡고, 알림은 다른 것들 사이에 묻히며, 에이전트는 약간 달라진 세계를 다시 역직렬화하게 됩니다. 장기 실행 런타임은 에이전트가 풀 실행 상태(추론 체인, 작업 메모리, 툴 히스토리, 대기 중인 액션)를 그대로 둔 채 “일시정지”할 수 있게 해 줍니다. 몇 시간 동안 사람의 시간이 흘러도, 에이전트는 컴퓨트 리소스를 전혀 쓰지 않다가, 다시 “재개” 호출이 오면 서브세컨드 지연으로 그대로 이어서 실행합니다. Mission Control은 Google이 이를 위한 인박스로 제공하는 UI이고, 이 패턴 자체는 벤더 무관하게 적용할 수 있습니다.

메모리-레이어 컨텍스트(Memory-layered context). 7일 동안 돌아가는 에이전트는 세션 상태만으로는 부족합니다. Memory Bank는 장기 메모리를 다루고, Memory Profiles는 저지연 조회를 더해 줍니다. 실제 프로덕션에서는 메모리 드리프트(memory drift) 라는 실패 모드에 부딪히게 됩니다. 에이전트가 극히 일부 비정형 상호작용에서 배운 절차적 숏컷을 전체에 적용하기 시작하는 경우입니다. 메모리는 마이크로서비스와 같은 수준으로 거버넌스가 필요합니다. Agent Identity는 누가 어떤 Memory Bank를 읽고 쓸 수 있는지 제어하고, Agent Registry는 어떤 버전의 에이전트가 어디서 돌아가는지 추적합니다. Agent Gateway는 네트워크 상에서 정책을 집행합니다. 이때 감사(audit)의 질문은 “에이전트가 지금 무엇을 하고 있나?” 에서 “에이전트가 무엇을 기억하고 있고, 그 기억이 어떻게 행동을 바꾸고 있는가?” 로 바뀝니다.

앰비언트(배경) 처리(Ambient processing). 모든 장기 실행 에이전트가 사람과 대화하는 것은 아닙니다. 어떤 것들은 Pub/Sub 스트림이나 BigQuery 테이블 위에 앉아, 컨텐츠 모더레이션, 이상 탐지, 인박스 정리 같은 일을 하며 들어오는 이벤트를 처리합니다. 실제 아키텍처에서 초기에 해둘 만한 중요한 결정은, 정책을 에이전트에 하드코딩하지 않는 것입니다. Gateway 같은 레이어에 정책을 정의하면, 플릿 전체가 재배포 없이도 정책 변경을 곧바로 반영할 수 있습니다. 앰비언트 에이전트는 오랫동안 감독 없이 돌아가기 때문에, 수십 혹은 수백 개를 한 번에 업데이트하는 실질적인 방법은 이 정책 레이어뿐입니다.

플릿 오케스트레이션(Fleet orchestration). 실제 시스템에서는 에이전트가 한 명인 경우가 거의 없습니다. 하나의 코디네이터가 서브태스크를 여러 전문 에이전트에게 위임합니다(리드 리서처 에이전트, 스코어링 에이전트, 아웃리치 에이전트 등). 각 에이전트는 서로 다른 Identity(예: 아웃리치 에이전트는 스코어링용 재무 데이터를 읽지 못하도록), 각자의 정책 집행, 각자의 Registry 엔트리를 가집니다. 이는 수십 년간 분산 시스템에서 사용해 온 코디네이터/워커 패턴과 같은 모양새입니다. 새롭게 추가된 것은, ADK가 이를 그래프 기반 워크플로로 선언적으로 구성할 수 있게 해 준다는 점, 그리고 한 전문 에이전트에서 배포 사고가 나더라도 나머지에게 연쇄적으로 전파되지 않는다는 점입니다.

이 패턴들은 서로 조합할 수 있습니다. 예를 들어 컴플라이언스 시스템은 문서 처리를 위한 체크포인트, 리뷰 게이트를 위한 위임 승인, 세션 간 지식을 위한 메모리 레이어링, 여러 전문 에이전트를 조정하기 위한 플릿 오케스트레이션을 동시에 사용할 수 있습니다. 출발점이 되는 질문은 언제나 같습니다. “내 에이전트가 끊김 없이 수행해야 하는 가장 긴 작업 단위는 어느 정도인가?” 만약 답이 “몇 분”이라면, 장기 실행 에이전트까지는 필요 없습니다. 답이 “몇 시간” 또는 “며칠”이라면, 위 패턴들이 출발점이 됩니다. 코드 예제가 포함된 전체 글은 각 패턴을 더 깊게 다룹니다.

그렇다면 오늘 당장 실제로 어떻게 만들 수 있을까?

이건 실무적인 질문이고, 무엇을 만들고 있는지에 따라 답이 달라집니다.

자기 레포에서 장기 실행 코딩 작업을 돌려보고 싶은 개발자라면. 그냥 Claude Code (혹은 Antigravity, Cursor, Codex)를 쓰면 됩니다. 하니스는 이미 갖춰져 있습니다. AGENTS.md⁠는 파일럿의 체크리스트처럼 다루세요. 짧고, 실제 실패 경험으로 검증된 내용만 남겨야 합니다. 타입체크, 린트 훅을 추가해서 실패가 있으면 에이전트에게 그대로 피드백되도록 하세요. 에이전트가 시작하기 전에 플랜 파일을 작성하게 하세요. 에이전트가 “다 했다”고 주장하는데 믿기 어렵다면 Ralph 루프를 사용하세요. 수시간 또는 밤새 걸리는 작업이라면, 랩탑이 닫혀도 죽지 않도록 worktree에서 실행하고, 의미 있는 작업 단위마다 커밋을 남기게 하세요. 지금 시점에서 대부분의 사람이 택해야 할 길은 이쪽이며, 레버리지가 가장 큰 곳도 여기입니다.

호스팅된 에이전트 제품을 만들고 있다면. 런타임을 직접 만들지 마세요. 관리형(managed) 런타임을 고르세요. 오늘 시점에 현실적인 옵션은 세 가지입니다. Google의 Agent Platform (Agent Engine + Memory Bank + Sessions), Claude Managed Agents, 혹은 ADK, Claude Agent SDK, Codex SDK 같은 것 위에 직접 무언가를 얹어 자체 호스팅하는 방법입니다. 트레이드오프는 익숙한 것과 같습니다. Managed를 쓰면 brain/hands/session 분리, 관측 가능성, 아이덴티티, 감사 추적이 기본 제공됩니다. 자체 호스팅은 통제를 주고, “특이한 역할에는 특이한 모델”을 쓸 수 있도록 해 줍니다(Cursor 패턴처럼). 대부분 팀에게 적절한 출발점은, 관리형 런타임 위에 직접 작성한 ADK/SDK 코드로 실제 루프를 구현하는 것입니다.

완전히 자율적인 운영 작업(모니터링, 리서치, 운영) 쪽이라면. 이 경우에는 Memory Bank 스타일의 지속성이 필요하고, 이는 Claude Code 안에는 존재하지 않는 부분입니다. ADK + Memory Bank + Cloud Run + Cloud Scheduler 조합은 “N시간마다 실행되는 에이전트가 상태를 축적하고, 임계값을 넘으면 알림을 보내는” 구조를 위한 가장 깔끔한 스택 중 하나입니다. 이 영역에서는 Cursor의 planner/worker/judge 분리가 IDE 코딩보다 훨씬 더 중요해지기 시작합니다. 작업이 실제로 병렬이고, 실패 모드도 다르기 때문입니다.

어느 길을 택하든, 공통적으로 중요한 몇 가지가 있습니다.

에이전트가 시작하기 전에 ‘완료 조건(done-condition)’을 명시적으로 적어 두세요. 장기 실행에서 가장 레버리지가 큰 한 가지 습관입니다. Anthropic 하니스 글에서 이를 feature list라고 부르고, Cursor는 planner의 태스크 스펙이라고 부릅니다. 이름이 무엇이든, 명확하고 테스트 가능한 완료 기준을 담은 외부 파일이며, 에이전트가 런 도중에 슬며시 done 의 의미를 바꾸지 못하도록 하기 위한 장치입니다.

생성자(generator)와 평가자(evaluator)를 분리하세요. 자기 채점(self-grading)이 핵심 실패 모드입니다. planner / worker / judge 파이프라인이나 generator / evaluator 쌍은 스타일상의 선택이 아니라 하나의 아키텍처 패턴입니다. 같은 모델을 다른 역할로, 다른 프롬프트로 쓰더라도 분리하는 것이 중요합니다.

프롬프트뿐 아니라 세션 로그에 투자하세요. append-only 이벤트 로그가 에이전트를 복구 가능하고, 디버깅 가능하고, 감사 가능하게 만들어 줍니다. 지난 24시간 동안 에이전트가 무슨 일을 했는지 내구성 있는 스토리지에서 재구성할 수 없다면, 그것은 LLM을 호출하는 장기 실행 셸 스크립트일 뿐, 장기 실행 에이전트가 아닙니다.

컴팩션(compaction)과 컨텍스트 리셋을 1급 시민으로 다루세요. Anthropic은, 매우 긴 작업에서는 요약 기반 컴팩션만으로는 충분하지 않았고, 하니스가 세션을 완전히 종료한 뒤 구조화된 핸드오프 파일로부터 다시 세션을 재구성하는 ‘풀 컨텍스트 리셋’을 해야 했다고 명시합니다. 이는 본질적으로, 사람이 새 엔지니어를 온보딩할 때 하는 일을 기계적으로 구현한 것입니다.

지금 존재하는 현실적인 한계들

아직 제대로 풀리지 않은 문제들도 몇 가지 있습니다.

비용. 프런티어 모델과 여러 툴을 섞어 24시간 실행하는 것은 싸지 않습니다. 예산, 서킷 브레이커, 툴 사용 비용 상한선을 명시적으로 두지 않으면, 에이전트 하나가 오후 내에 일주일치 API 예산을 날려버리는 상황도 충분히 가능합니다. 풀 수 있는 문제지만, 의식적으로 조치해야 하는 부분입니다.

보안. API 키, 클라우드 접근 권한, 셸 명령 실행 능력을 가진 장기 실행 에이전트의 공격 표면은 한 번의 채팅 세션보다 훨씬 큽니다. 여기에서도 brain/hands 분리 패턴이 중요합니다. 모델이 생성한 코드가 실행되는 샌드박스에서는 자격 증명(credentials)에 접근할 수 없도록 막는 것이죠. Anthropic이 Managed Agents의 장점으로 꼽은 것들 중 하나도 바로 이 부분입니다.

정렬 드리프트(Alignment drift). 많은 컨텍스트 윈도우에 걸쳐 작업하다 보면, 에이전트는 초기 목표에서 서서히 벗어납니다. 원래의 목표가 한 번 요약되고, 또 다시 요약되다 보면, 의미가 점점 희미해집니다. 이것이 훅과 judge들이 방어하려는 바로 그 부분입니다. “에이전트가 내가 시키지 않은 일을 멋대로 해버렸다”는 현상이 가장 자주 발생하는 이유이기도 합니다.

검증(Verification). 24시간치 자율 활동을 감시·검토하는 것은 인간 시간 관점에서 진짜로 큰 문제입니다. 관측 가능성 툴과 구조화된 산출물(PR, 커밋, 브리핑, 테스트 실행 결과 등)이 이 문제를 해소하는 도구입니다. 이런 것이 없으면, 긴 로그를 스크롤만 하다가 중요한 것을 놓치게 됩니다.

인간의 역할. 제가 계속해서 돌아오게 되는 지점이 바로 이 부분입니다. 에이전트가 하루 동안 돌 수 있을 만큼 일을 “정확하게 정의하는” 것은, 그 일을 직접 하는 것보다 더 어려울 수 있습니다. 가치가 올라가고 있는 기술은 코드를 직접 쓰는 능력이 아니라, 자율 실행자에게 맡겼을 때도 버틸 수 있는 스펙을 작성하는 능력입니다.

앞으로의 방향

Google, Anthropic, Cursor는 거의 같은 형태에 수렴했습니다. 모델 루프는 실행 샌드박스와 분리하고, 둘 다는 내구성 있는 세션 로그와 다시 분리합니다. 계획(planning)과 생성(generation)과 평가(evaluation)을 나눕니다. 컴팩션과 훅, 컨텍스트 리셋을 처음부터 설계에 녹여 둡니다. 메모리는 어느 에이전트 호출에서든 질의할 수 있는 관리형 서비스로 노출합니다.

다른 점은 노출되는 표면적입니다. Google의 Agent Platform은 아이덴티티와 감사 체계를 내장한 엔터프라이즈 스택 버전입니다. 그 아래 깔린 패턴은 위에서 설명한 것과 같습니다. Claude Managed Agents는 “Anthropic 하니스를 Anthropic이 직접 호스팅하는” 버전입니다. Cursor의 백그라운드 에이전트는 “IDE에서 떼어내 클라우드로 옮긴 장기 실행 코딩”입니다.

앞으로 1년 정도 진짜 어려운 문제는, 이 각각의 레이어 내부가 아니라 그 위의 조정(coordination) 층에 있습니다. 하나의 공유 코드베이스 위에서 수많은 장기 실행 에이전트가 함께 일하는 문제. 자기 자신의 트레이스를 읽고, 자기 자신의 하니스를 패치하는 에이전트. 스타트업 시점에 미리 모든 툴과 컨텍스트를 박아 넣는 것이 아니라, 태스크에 맞춰 필요한 툴과 컨텍스트를 그때그때 조립하는 하니스. 이 단계에서 에이전트는 더는 “조금 똑똑한 채팅창”처럼 보이지 않고, 프로젝트에 나보다 오래 있었던 동료처럼 보이기 시작합니다.

모델은 여전히 구조 전체를 떠받치는 핵심입니다. 하지만, 채팅창과 “밤새 돌려도 되는 에이전트” 사이의 간극 대부분은 모델 바깥, 상태(state)와 세션, 구조화된 핸드오프에 있습니다. 지금이라면, 학습 시간을 어디에 써야 할지를 묻는다면 저는 그쪽에 투자하라고 말할 것입니다.

선행 읽기로는, 이 글에서 다룬 하니스 프리미티브를 정리한 Agent Harness Engineering과, Ralph 루프 패턴을 더 깊게 파고든 Self-improving agents를 추천합니다.