장기 실행 AI 에이전트를 위한 체크포인트와 안전한 재개 설계
수일간 실행되는 AI 에이전트의 상태 외부화, 체크포인트, 멱등 키, 하트비트 기반 재개 아키텍처를 정리한다.
2026-09-01 · 최초 발행 2026-08-02
중단을 전제로 설계해야 하는 실행
OpenAI가 워싱턴 D.C.에서 공개한 Astra는 여러 에이전트 팀이 장기간 난제를 함께 처리하는 구조를 핵심 특성으로 제시했다. 실행 시간이 수 초를 넘어 수 시간·수일에 이르면, 한 번의 요청과 응답으로 끝난다는 전제에서 만든 타임아웃·세션·재시도 정책은 더는 유효하지 않다.
이 환경에서는 네트워크 단절, 인증 토큰 만료, 배포에 따른 프로세스 재시작 가운데 적어도 하나가 발생한다. 문제는 발생 여부가 아니라 언제 끊기느냐에 있다.
따라서 프로세스 메모리나 세션 내부 변수에만 진행 정보를 보관할 수 없다. 외부 저장소에 상태를 남기고, 중간 지점에서 이어서 실행하며, 이미 수행한 외부 쓰기나 발송을 다시 수행하지 않도록 멱등성까지 함께 설계해야 한다.
체크포인트만 저장하는 구현은 흔한 함정이다. 실행은 재개되더라도 메일 발송이나 외부 시스템 쓰기가 중복될 수 있다. 마지막 성공 단계만 재개 위치로 삼는 방식도 충분하지 않다. 부분 완료된 단계라면, 실제 완료 여부를 판별할 근거가 있어야 한다.
실행 상태를 프로세스 밖으로 꺼내기
실행 컨텍스트는 데이터베이스나 객체 저장소처럼 프로세스 외부에 둔다. 모델 세션에만 상태가 남아 있다면 세션 종료는 곧 상태 손실이다. 외부 상태 저장은 복구뿐 아니라 실행 현황을 외부에서 조회하는 기반이기도 하다.
상태 스키마에는 버전 필드가 필요하다. 수일 동안 실행되는 작업에서는 중간에 코드가 배포될 수 있고, 새 버전이 이전 버전이 기록한 상태를 읽어야 한다.
상태 크기에도 경계를 둬야 한다. 대용량 산출물은 상태 레코드에 직접 넣기보다 참조로 남기고, 갱신마다 저장 비용이 커지지 않도록 관리한다.
체크포인트는 재실행 비용이 큰 경계에 둔다. 값비싼 도구 호출을 마친 직후가 대표적인 후보가 된다. 체크포인트에는 입력 해시도 함께 기록해야 재개 시 입력 변경 여부를 확인할 수 있다. 기록 자체가 실패할 수 있으므로, 저장 성공을 확인한 뒤 다음 단계로 진행한다.
재개가 중복 실행으로 이어지지 않게 하는 방법
외부에 영향을 주는 호출마다 과제 식별자와 단계 식별자를 조합한 멱등 실행 키를 부여한다. 같은 키로 다시 요청되면 실제 호출을 반복하지 않고, 앞선 결과를 반환하도록 만든다.
외부 시스템이 멱등 키를 지원하지 않는 경우에는 자체 실행 대장을 둘 수 있다. 호출 직전에 대장을 조회하면 대장 기록과 실제 호출 사이에 간극은 남지만, 중복 실행 범위는 크게 줄일 수 있다.
부작용은 별도 기록으로 관리한다. 무엇을 언제 어디에 썼는지가 남아 있어야 재개 여부를 판단할 수 있고, 사후 감사도 가능하다. 되돌릴 수 있는 부작용과 되돌릴 수 없는 부작용을 구분해 기록하면 롤백 가능한 범위에 맞춰 재개 전략을 선택할 수 있다.
재개 위치는 마지막 체크포인트가 아니라 마지막으로 일관성이 확인된 지점이어야 한다. 부분 완료 단계는 완료 판정 로직을 통과한 경우에만 건너뛴다. 재개 횟수도 상태에 누적한다. 같은 위치에서 반복적으로 재개된다면 복구가 아니라 무한 루프일 수 있다.
하트비트와 좀비 세션을 운영 대상에 포함하기
수일 단위 실행에 전체 실행 시간을 기준으로 한 단일 타임아웃을 적용하는 방식은 의미가 없다. 실행 주체가 주기적으로 하트비트를 갱신하고, 별도 감시자가 만료를 탐지하는 구조가 필요하다.
하트비트 주기와 만료 임계값은 분리해 설정한다. 두 값이 같으면 일시적인 지연도 즉시 실패로 판정될 수 있다.
하트비트가 끊긴 실행은 회수해 재개 대상 큐로 보내야 한다. 회수하지 않으면 예산만 소비하는 실행이 남는다. 이 과정에서 해당 실행이 보유했던 자원 잠금도 해제해야 하며, 잠금이 남아 있으면 재개 작업 역시 막힌다.
도입 시 먼저 정할 운영 규칙
업무마다 최대 허용 실행 시간을 정하고, 초과 시 자동 중단하도록 한다. 상한이 없으면 실패한 실행과 아직 진행 중인 실행을 구분하기 어렵다. 시간뿐 아니라 과제 단위 비용에도 상한을 둬야 짧은 시간 동안 대량 호출이 발생하는 이탈을 막을 수 있다.
체크포인트 주기는 재실행 비용과 기록 비용의 균형으로 정한다. 값싼 단계마다 저장하면 저장소 부하가 커지고, 너무 드물게 저장하면 중단 후 재실행 손실이 커진다. 단계 수보다 누적 비용을 기준으로 주기를 정하는 편이 실무에서 더 안정적이다.
수동 재개 명령과 자동 재개 조건은 함께 문서화한다. 장애가 난 뒤에 절차를 찾는 상황은 실제로 발생한다. 되돌릴 수 없는 부작용이 절반만 발생한 상태처럼 재개보다 사람 판단이 필요한 조건도 명시해야 한다.
멱등 키가 필요한 외부 호출은 목록으로 관리한다. 누락된 호출 하나가 중복 결제나 중복 발송으로 이어질 수 있다. 새 외부 연동을 추가할 때 멱등성 검토를 체크리스트에 넣는 방식이 유효하다.
예산 소진에 따른 중단과 실패에 따른 중단은 별도로 기록한다. 원인이 다르면 대응도 달라진다. 진행 상황은 완료율보다 완료된 단계 목록으로 보고하는 편이 낫다. 동적으로 계획이 바뀌는 실행에서는 완료율을 신뢰하기 어렵기 때문이다. 보고 주기를 정하고, 무응답 시간이 임계값을 넘으면 알림을 발생시킨다.
장기 실행 에이전트는 배치 작업과 같은 운영 대상으로 등록할 필요가 있다. 실행 목록, 담당자, 재개 권한, 중단 권한을 분명히 하고 재개·중단 이력을 감사 로그로 보존한다. 자율 실행의 범위가 넓을수록 사후 설명 책임도 커진다.
실행 방식별로 달라지는 비용과 복원력
| 구분 | 체크포인트 재개 | 실패 시 전체 재실행 |
|---|---|---|
| 구현 부담 | 높음 | 낮음 |
| 실패 후 소요 시간 | 잔여 단계만 | 처음부터 |
| 토큰 비용 | 잔여분만 | 전량 재소비 |
| 중복 부작용 위험 | 멱등 설계로 통제 | 전면 재발생 |
| 상태 스키마 관리 | 필요 | 불필요 |
| 적합 조건 | 수 시간 이상 실행 | 수 분 내 실행 |
전체 재실행은 구현이 단순하고 상태 스키마 관리가 필요 없으므로 짧은 실행에는 합리적이다. 하지만 실행이 수 시간을 넘으면 한 번의 실패가 하루치 리드타임 손실과 전량 토큰 비용으로 돌아오며, 외부 부작용도 처음부터 다시 발생한다.
체크포인트 재개는 잔여 단계만 수행해 손실을 국소화한다. 대신 상태 스키마 버전 관리, 재개 지점 판정, 멱등 키 부여라는 부담을 감수해야 한다. 실행 시간이 재개 구현 비용을 넘는 지점이 판단 기준이며, 수 시간 단위 실행에서는 재개 설계가 사실상 필수가 된다.
세션 내 메모리 유지는 접근이 빠르고 직렬화 부담이 없어 구현은 간결하다. 그러나 프로세스 재시작, 세션 만료, 인스턴스 교체를 견디지 못하고 외부에서 실행 상태를 조회할 수도 없다. 수일 단위 실행에서는 배포 한 번으로도 세션이 끊길 수 있으므로 외부 저장이 유일한 선택지가 된다. 이때의 핵심은 저장 여부가 아니라 어느 입자도로 저장할지를 정하는 일이다.
장기 단일 실행은 문맥이 이어지고 조율 코드가 필요 없다는 장점이 있지만, 한 지점의 오류가 전체를 무효화할 수 있고 진행 상태의 외부 관측도 어렵다. 짧은 작업을 연쇄하는 방식은 재시도와 관측, 실패 격리가 쉬운 대신 작업 사이의 인계 데이터를 명시적으로 규격화해야 하며 문맥 손실도 발생한다. 문맥 의존이 강한 추론 과제에는 단일 실행이, 단계 경계가 뚜렷한 처리 과제에는 분할 연쇄가 유리하다. 실무에서는 큰 단위로 나누고 각 단위 내부에 체크포인트를 두는 절충이 흔하다.
기존 시스템 운영 원칙을 에이전트에 적용하기
장기 실행 에이전트는 분산 트랜잭션의 사가 패턴과 유사한 문제를 만난다. 전체 원자성을 보장할 수 없으므로 단계별 보상 동작과 멱등성으로 일관성을 확보해야 한다. 부작용 대장은 보상 트랜잭션의 근거가 되며, 수행 이력이 없다면 보상도 설계할 수 없다.
실행 중단은 장애가 아니라 정상 시나리오로 분류해야 한다. 과제 단위로 복구 목표 시점과 복구 목표 시간을 정의하면, 적절한 체크포인트 주기를 도출할 수 있다. 재개 절차는 문서에만 두지 않고 훈련 대상으로 포함해야 한다. 실제로 수행해 본 적 없는 절차는 장애 시점에 작동하지 않는다.
하트비트 감시와 좀비 세션 회수는 배치 운영에서 오래 사용된 패턴이다. 에이전트 실행을 완전히 새로운 운영 문제로 보기보다, 기존 작업 스케줄러의 운영 관행을 이식하는 편이 빠르다. 실행 목록·상태·비용을 한 화면에서 확인할 수 있어야 수일짜리 실행을 운영할 수 있다.
플랫폼 기본 기능으로 편입되는 재개 체계
장시간 협업 실행을 전면에 내세운 모델이 등장하면서 체크포인트와 재개는 에이전트 플랫폼의 기본 제공 기능으로 편입되는 흐름이다.
멱등 실행 키는 외부 연동 API의 표준 요구사항으로 확산되고, 이를 지원하지 않는 시스템을 연결하기 위한 실행 대장 패턴도 일반화되는 방향이다. 과제 단위 예산 상한과 자동 중단은 비용 통제의 기본 장치로 자리 잡고, 실행 상태·부작용 대장·트레이스를 통합 조회하는 운영 콘솔은 에이전트 도입의 필수 구성 요소로 요구될 전망이다.
Sources
- Exclusive: OpenAI Previews 'Astra' AI Model in DC | The Information
- OpenAI previews Astra model built to coordinate long-running agents | RuntimeWire
- Altman Demos 'Astra' Model on Capitol Hill: OpenAI Bets on Multi-Agent, Long-Horizon Task Capabilities | BigGo Finance
- OpenAI Previews 'Astra' Multi-Agent Model Family to US Policymakers | AI Weekly
- OpenAI's Astra Model Series: Multi-Agent Collaboration, Washington Demos, and the New Rules for AI | Studio Global AI