클라우드 에이전트 이야기가 늘어나면서 많은 팀이 같은 착각을 한다. 로컬에서 잘 되던 자동화를 그냥 원격에서 더 오래 돌리면 될 것이라고 보는 것이다. 하지만 장기 실행 에이전트는 단순히 실행 시간이 긴 챗봇이 아니다. 2026년 5월 21일 Cursor가 durable execution을 전면에 내세운 이유도 여기에 있다. 오래 돌리는 작업은 상태 유지, 실패 복구, 격리, 승인 전달 방식까지 별도로 설계해야 한다.
이 글은 메인 허브 글인 AI 에이전트 실행 환경 설계 가이드: 프롬프트보다 운영 구조가 중요한 이유에서 이어지는 후속 편이다. 그 글이 실행 환경 전체 구조를 다뤘다면, 여기서는 왜 장기 실행 작업이 별도 계층을 요구하는지에만 집중해 본다.
왜 장기 실행 작업은 채팅형 자동화와 다른가
짧은 요청은 실패해도 다시 시키면 된다. 하지만 리서치 수집, 코드 변경 초안, 대규모 문서 정리, 여러 시스템을 거치는 발행 파이프라인은 중간 상태가 중요하다. 어느 단계까지 끝났는지, 무엇이 외부 시스템에 반영됐는지, 다시 시작하면 중복 실행이 생기지 않는지를 알아야 한다.
즉 장기 실행 작업의 핵심은 “얼마나 오래 도느냐”보다 “중간 상태를 얼마나 안정적으로 다루느냐”에 있다. 이 점에서 durable execution은 편의 기능이 아니라 운영 모델에 가깝다.
내구 실행이 실제로 해결하는 문제
첫 번째는 상태 복구다. 네트워크 문제, API 제한, 외부 서비스 지연은 자동화에서 흔하다. 이런 일이 생길 때 작업 전체를 처음부터 다시 돌리면 비용과 오류가 함께 커진다. 내구 실행 계층은 마지막 성공 상태를 기준으로 이어서 수행할 수 있게 만들어야 한다.
두 번째는 재시도 정책이다. 실패를 만났을 때 무조건 즉시 반복하면 외부 시스템을 더 망가뜨릴 수 있다. 반대로 사람 호출만 남기면 자동화 가치가 사라진다. 그래서 재시도 횟수, 간격, 포기 조건을 작업 종류별로 다르게 둬야 한다.
세 번째는 환경 격리다. 장기 실행 작업은 임시 파일, 인증 맥락, 캐시가 쌓이기 쉽다. 이 상태가 다음 작업으로 섞이면 결과 설명이 어려워진다. 전용 VM이나 분리된 실행 컨테이너가 강조되는 이유는 보안뿐 아니라 같은 조건을 반복 재현하기 위해서이기도 하다.
한국 실무에서 특히 문제가 되는 지점
한국 팀에서는 메신저 승인, 문서 기반 협업, 여러 SaaS 연결이 동시에 일어나는 경우가 많다. 그래서 장기 실행 에이전트는 기술적으로만 안정하면 끝나지 않는다. 사람이 자리를 비운 동안에도 상태를 이해할 수 있어야 하고, 승인 요청이 오면 맥락이 함께 전달되어야 하며, 실패 시 누가 어디서 이어받을지 보여 줘야 한다.
예를 들어 밤새 돌아가는 콘텐츠 파이프라인이라면 다음 네 가지가 최소 기준이 된다.
- 어느 단계에서 멈췄는지 사람이 한눈에 볼 수 있어야 한다.
- 승인 보류 중인지 시스템 실패인지 구분되어야 한다.
- 재실행 시 이미 반영된 외부 쓰기 액션을 건너뛸 수 있어야 한다.
- 다음 날 확인하는 사람도 로그만으로 상황을 복기할 수 있어야 한다.
이 기준이 빠지면 장기 실행 자동화는 사람을 덜 쓰는 시스템이 아니라 사람이 더 불안해지는 시스템이 되기 쉽다.
내구 실행 설계에서 먼저 나눠야 할 세 층
실무에서는 장기 실행 구조를 세 층으로 나누면 판단이 쉬워진다.
1. 계획 층
무엇을 할지 정하는 단계다. 리서치 범위, 생성할 초안, 필요한 도구 세트, 승인 필요 여부를 여기서 정리한다.
2. 실행 층
실제로 API를 호출하고 파일을 만들고 외부 시스템에 쓰는 단계다. 이 층은 재시도와 상태 저장 기준이 가장 엄격해야 한다.
3. 승인 층
고위험 액션 직전에 사람 확인을 받는 단계다. 승인 자체보다 중요한 것은 승인 메시지에 어떤 맥락을 싣느냐이다. 결과 요약, 변경 범위, 실패 시 영향이 함께 있어야 사람이 빠르게 판단할 수 있다.
이 세 층이 섞이면 durable execution이 있어도 운영은 불안정해진다. 반대로 층이 분리되면 모델이 바뀌어도 구조는 유지된다.
언제 로컬보다 클라우드가 유리한가
모든 작업을 클라우드 에이전트로 옮길 필요는 없다. 하지만 다음 조건이 겹치면 클라우드 쪽이 유리해진다.
- 작업 시간이 길고 중간 실패 확률이 높다.
- 여러 외부 시스템을 순차적으로 건드린다.
- 사람이 실시간으로 화면을 보지 않는다.
- 재실행과 복구 절차를 표준화해야 한다.
반대로 짧은 초안 작성, 단일 시스템 조회, 사람이 바로 옆에서 확인하는 작업은 로컬 기반으로도 충분할 수 있다. 핵심은 클라우드가 더 멋져 보여서가 아니라, 내구 실행과 상태 복구가 실제로 필요한지 따지는 것이다.
바로 적용할 체크리스트
- 장기 실행 작업의 중간 상태를 어디에 저장할지 먼저 정한다.
- 단계별 재시도 횟수와 포기 조건을 분리한다.
- 외부 쓰기 액션에는 중복 실행 방지 키를 둔다.
- 승인 요청에는 결과 요약과 영향 범위를 함께 보낸다.
- 실행 환경을 작업별로 격리해 같은 오류를 재현할 수 있게 만든다.
클라우드 에이전트 내구 실행은 결국 모델 고도화의 이야기가 아니다. 사람이 자리를 비운 동안에도 작업을 설명 가능하게 유지하는 운영 구조의 이야기다. 이 기준으로 보면 durable execution은 부가 기능이 아니라 장기 실행 자동화의 기본 골격에 가깝다.