콤퓨타지식 AI Agent는 어떻게 며칠 동안 일을 계속할까? State·Checkpoint·Runtime의 원리
페이지 정보
본문
작성일
AI Agent에게 5분짜리 작업을 맡기는 것과 며칠 동안 이어지는 업무를 맡기는 것은 기술적으로 다른 문제입니다.
사용자가 질문하면 AI가 답변하는 일반적인 대화에서는 하나의 요청을 처리하고 결과를 반환하면 작업이 끝날 수 있습니다.
하지만 AI Agent에게 프로그램 개발이나 자료 분석처럼 오랜 시간이 필요한 업무를 맡긴다면 상황이 달라집니다.
Agent는 현재 어디까지 작업했는지 알아야 하고, 만들어놓은 파일을 보존해야 하며, 실행 중 오류가 발생해도 작업 전체를 처음부터 다시 시작하지 않아야 합니다.
사용자가 연결을 종료해도 작업을 계속할 수 있어야 하고, 필요하다면 사람의 승인을 기다렸다가 다시 업무를 이어갈 수도 있어야 합니다.
이러한 구조를 이해하려면 먼저 런타임(Runtime), 문맥(Context), 메모리(Memory), 상태(State), 체크포인트(Checkpoint)가 각각 어떤 역할을 하는지 구분할 필요가 있습니다.
■ Long-running Agent는 단순히 AI를 오래 켜두는 기술이 아니다
장기 실행 AI Agent(Long-running AI Agent)는 몇 시간 또는 며칠처럼 오랜 시간에 걸쳐 여러 단계의 작업을 수행하는 Agent를 의미합니다.
여기서 중요한 것은 단순한 실행시간이 아닙니다.
예를 들어 AI Coding Agent가 다음과 같은 작업을 수행한다고 가정해보겠습니다.
프로젝트 분석
↓
개발환경 구성
↓
라이브러리 설치
↓
코드 수정
↓
테스트
↓
오류 발견
↓
코드 재수정
↓
사람의 승인
↓
배포
이 과정이 몇 시간에 걸쳐 진행되다가 중간에 Agent의 실행환경이 종료됐다고 생각해보겠습니다.
다시 Agent를 실행했을 때 수정한 파일과 설치한 패키지, 현재 진행 단계까지 모두 사라진다면 단순히 실행시간을 늘리는 것만으로는 장기 업무를 수행하기 어렵습니다.
그래서 장기 실행 Agent에서는 오래 실행할 수 있는 능력과 작업을 이어갈 수 있는 능력을 구분해야 합니다.
Microsoft 역시 장기 실행 Agent에서 단순한 백그라운드 실행(Background Execution)과 프로세스 중단 이후 작업을 복구하는 복원 가능한 실행(Resilient Execution)을 서로 다른 문제로 구분합니다.
■ Runtime은 AI Agent가 실제로 일하는 작업 공간이다
런타임(Runtime)은 프로그램이나 AI Agent가 실제로 실행되는 환경입니다.
Agent가 모델을 호출하고, 코드를 실행하고, 파일을 만들고, 외부 도구를 사용하려면 이러한 작업이 수행될 컴퓨팅 환경이 필요합니다.
쉽게 비유하면 AI 모델이 일을 판단하는 두뇌라면 Runtime은 실제 업무를 수행할 수 있도록 컴퓨터와 작업공간을 제공하는 실행환경에 가깝습니다.
Amazon Bedrock AgentCore Runtime의 경우 실시간 상호작용뿐 아니라 장시간 작업과 비동기 작업을 지원하며, MicroVM에서는 최대 8시간, Instances에서는 최대 14일까지 Session을 실행할 수 있습니다.
하지만 Runtime이 오래 유지된다고 해서 Agent가 이전 업무를 자동으로 모두 기억하는 것은 아닙니다.
여기서부터 State와 Storage의 문제가 시작됩니다.
■ State는 ‘현재 업무가 어디까지 진행됐는가’를 나타낸다
상태(State)는 Agent가 현재 어떤 작업을 수행하고 있으며 업무가 어디까지 진행됐는지를 나타내는 정보입니다.
예를 들어 홈페이지를 수정하는 Agent라면 다음과 같은 정보가 State에 해당할 수 있습니다.
17개 작업 중 11개 완료
회원가입 기능 수정 중
테스트 42개 중 39개 통과
결제 기능은 사람의 승인 대기 중
마지막으로 수정한 파일은 signup.php
이 정보는 단순한 대화 내용과는 성격이 다릅니다.
Agent가 장시간 업무를 수행하려면 무엇을 알고 있는가뿐 아니라 무엇을 하고 있었는가를 관리해야 하기 때문입니다.
Microsoft는 장기 실행 Agent에서 Runtime이 실행 관련 메타데이터를 보존하는 것과 별개로, 실제 업무의 의미 있는 진행 상태는 Agent 애플리케이션이 보존해야 한다고 설명합니다.
■ Memory와 State는 같은 개념이 아니다
AI Agent를 설명할 때 State와 자주 혼동되는 개념이 메모리(Memory)입니다.
둘은 관련되어 있지만 같은 개념으로 보는 것은 정확하지 않습니다.
예를 들어 개발 Agent가 다음 정보를 가지고 있다고 생각해보겠습니다.
Memory
이 고객의 홈페이지는 PHP 기반이다.
고객은 기존 디자인을 최대한 유지하기를 원한다.
이 프로젝트에서는 특정 라이브러리를 사용한다.
반면 현재 업무가
회원가입 기능 수정 중
↓
API 연결 완료
↓
UI 테스트 완료
↓
모바일 테스트 대기
상태라면 이것은 현재 작업의 State에 가깝습니다.
따라서 간단하게 구분하면,
Memory
Agent가 이후에도 참고해야 할 정보
State
현재 업무가 어느 상태에 있는지를 나타내는 정보
라고 이해할 수 있습니다.
실제 AWS AgentCore 역시 일시적인 Session Context와 Session 이후에도 보존해야 하는 대화 기록·선호도·중요 정보 등을 구분하고, 후자에는 별도의 AgentCore Memory 사용을 안내합니다.
■ Context는 지금 판단하기 위해 AI에게 주어진 정보다
여기에 하나를 더 구분해야 합니다.
문맥(Context)입니다.
Context는 AI 모델이 현재 요청을 처리하고 판단하기 위해 참고할 수 있도록 제공된 정보라고 볼 수 있습니다.
예를 들어
현재 사용자의 요청
이전 대화
관련 문서
도구 실행 결과
현재 작업 상태
필요한 프로젝트 정보
등이 모델의 판단을 위해 Context로 구성될 수 있습니다.
따라서 Memory에 저장된 정보가 필요할 때 Context로 불러와질 수도 있고, 현재 State 역시 Agent가 다음 행동을 결정할 수 있도록 Context에 포함될 수 있습니다.
즉 세 개를 완전히 분리된 저장소처럼 이해하기보다는 역할을 구분하는 것이 중요합니다.
Context
지금 판단하기 위해 참고하는 정보
Memory
나중에도 활용하기 위해 보존하는 정보
State
현재 업무가 어디까지 진행됐는지를 나타내는 정보
입니다.
■ Checkpoint는 ‘여기까지 작업했다’를 저장하는 지점이다
장기 실행 Agent에서 중요한 또 하나의 개념은 체크포인트(Checkpoint)입니다.
Checkpoint는 작업 도중 특정 시점의 진행 상태를 저장해두고, 문제가 발생했을 때 그 지점부터 다시 업무를 이어갈 수 있도록 하는 구조입니다.
예를 들어 Agent가 100단계의 업무를 수행한다고 생각해보겠습니다.
1단계
↓
10단계
↓
Checkpoint A
↓
20단계
↓
30단계
↓
Checkpoint B
↓
40단계에서 오류 발생
이때 아무런 상태도 저장하지 않았다면 처음부터 다시 작업해야 할 수 있습니다.
하지만 30단계까지 완료됐다는 Checkpoint가 존재한다면 마지막으로 안전하게 저장된 지점을 기준으로 작업을 재개할 수 있습니다.
Microsoft의 Durable State Store 역시 Framework Checkpoint, 중간 작업물, 대화 기록 등을 Container의 수명보다 오래 보존할 수 있도록 설계되어 있습니다.
AWS도 장기 분석 작업에서 Session Storage를 Checkpoint 저장에 활용하는 구성을 공식 사용 사례로 제시합니다.
■ Persistent Storage는 작업 결과가 사라지지 않게 한다
State와 Checkpoint를 만들어도 저장할 공간이 없다면 실행환경이 사라질 때 함께 없어질 수 있습니다.
그래서 장기 실행 Agent에는 지속 저장소(Persistent Storage)가 중요합니다.
일반적인 일시적 실행환경(Ephemeral Environment)에서는 Container나 MicroVM이 종료되면서 내부 데이터도 사라질 수 있습니다.
반면 Persistent Storage를 사용하면 실행환경이 종료된 이후에도 필요한 데이터를 보존할 수 있습니다.
AWS AgentCore의 Session Storage는 Agent가 사용하던 파일 시스템을 Session Stop/Resume 사이에서도 유지할 수 있습니다.
예를 들어 Coding Agent가
소스코드 작성
↓
Package 설치
↓
Build Artifact 생성
↓
Session 종료
후 다시 같은 Session으로 돌아왔을 때 이전 Workspace를 복원해 테스트와 수정을 계속할 수 있습니다.
AWS의 Instances 방식에서는 최대 실행시간에 도달해 기존 Instance가 종료되더라도 Persistent Volume을 유지한 뒤 같은 runtimeSessionId로 새로운 Instance를 생성해 다시 연결할 수도 있습니다.
■ Background Execution은 사용자가 기다리지 않아도 AI가 일하게 한다
장기 실행 Agent에서는 비동기 실행(Asynchronous Execution)도 중요합니다.
일반적인 Chat 서비스에서는
사용자 요청
↓
AI 처리
↓
사용자 대기
↓
결과 반환
이라는 구조가 자연스럽습니다.
하지만 Agent에게 6시간짜리 업무를 맡겼다면 사용자가 브라우저를 열어놓고 6시간 동안 응답을 기다리는 방식은 비효율적입니다.
그래서 장기 실행 Agent에서는
사용자
↓
작업 요청
↓
Agent가 작업 시작
↓
사용자 연결 종료
↓
Background에서 계속 작업
↓
사용자가 나중에 다시 접속
↓
진행 상황 또는 결과 확인
같은 구조를 사용할 수 있습니다.
AWS AgentCore도 수분 또는 수시간이 걸리는 작업을 시작한 뒤 사용자에게 즉시 작업 시작 사실을 반환하고, Agent가 Background에서 계속 처리하도록 하는 비동기 구조를 지원합니다.
■ Retry와 Recovery도 구분해야 한다
Agent 작업에서 오류가 발생했다고 해서 모든 경우가 같은 것은 아닙니다.
대표적으로 재시도(Retry)와 복구(Recovery)를 구분할 수 있습니다.
Retry는 실행 중인 작업에서 오류가 발생했을 때 같은 작업을 다시 시도하는 방식입니다.
예를 들어 외부 API 호출이 일시적으로 실패했다면 잠시 후 다시 호출할 수 있습니다.
반면 Recovery는 Agent가 실행되던 Process 자체가 Crash하거나 재배포되는 등 기존 실행환경을 잃었을 때 저장된 진행 상태를 이용해 업무를 다시 이어가는 것에 가깝습니다.
Microsoft도 장기 실행 Agent 문서에서 Retry와 Recovery를 별개의 개념으로 설명합니다.
따라서 장기 업무에서는 단순히
“실패하면 다시 실행한다”
만으로 충분하지 않을 수 있습니다.
어디까지 완료됐는지 확인하고, 이미 실행된 작업을 다시 수행해도 되는지 판단하고, 필요한 경우 마지막 Checkpoint에서 작업을 재개해야 합니다.
■ 작업을 복구할 때도 새로운 문제가 생긴다
Agent가 작업을 복구할 수 있게 만들면 또 다른 문제가 생깁니다.
같은 행동을 두 번 실행하면 어떻게 될까요?
예를 들어 쇼핑 Agent가 결제를 진행하다 Process가 중단됐다고 가정해보겠습니다.
실제로는 결제가 완료됐는데 Agent가 그 사실을 저장하기 전에 중단됐다면, 복구된 Agent가 결제를 다시 실행할 수도 있습니다.
프로그램 개발에서는 파일을 한 번 더 수정하는 것으로 끝날 수도 있지만,
결제
메일 발송
예약
데이터 삭제
주문
처럼 외부 세계에 영향을 미치는 행동에서는 중복 실행이 실제 문제로 이어질 수 있습니다.
그래서 장기 실행 Agent에서는 멱등성(Idempotency)과 이미 실행한 작업을 식별할 수 있는 기록도 중요합니다.
Microsoft는 복구 가능한 Agent를 설계할 때 Checkpoint와 함께 Idempotency Key나 Side-effect Watermark 등을 이용해 이미 수행한 외부 작업이 중복 실행되지 않도록 관리할 것을 설명합니다.
■ Human-in-the-loop는 Agent의 작업을 중간에 멈출 수도 있다
장기 실행 Agent가 모든 업무를 처음부터 끝까지 자동으로 처리해야 하는 것은 아닙니다.
특정 단계에서 사람의 판단이 필요한 경우에는 작업을 일시 정지할 수 있습니다.
예를 들어 홈페이지 수정 Agent라면
코드 분석
↓
수정안 작성
↓
테스트
↓
실제 서버 반영 전 사람 승인
↓
배포
같은 구조를 사용할 수 있습니다.
이러한 방식을 사람 개입형 구조(Human-in-the-loop)라고 합니다.
이때도 State와 Checkpoint가 중요합니다.
사람이 몇 시간 뒤 승인하더라도 Agent가
어떤 작업을 했고,
왜 승인을 요청했고,
승인 이후 어디서부터 작업을 계속해야 하는지
알 수 있어야 하기 때문입니다.
■ Long-running Agent에는 종료 조건도 필요하다
Agent가 오래 일할 수 있다고 해서 오래 일하는 것이 항상 좋은 것은 아닙니다.
목표가 불명확하거나 오류를 반복하는 Agent가 계속 실행된다면 불필요한 Token과 컴퓨팅 자원을 사용할 수 있습니다.
따라서 장기 실행 Agent에서는
업무 완료 조건
최대 실행시간
재시도 횟수
비용 한도
오류 발생 조건
사람의 승인 여부
중단 조건
등을 함께 관리할 필요가 있습니다.
실제로 AWS AgentCore Runtime에서도 Session의 최대 수명과 Idle Timeout 같은 Lifecycle Setting을 두고 있습니다. 비동기 작업 상태를 잘못 갱신하면 불필요하게 Session이 최대 수명까지 유지될 수 있다는 주의사항도 공식 문서에 명시되어 있습니다.
즉 Long-running Agent에서 중요한 것은 단순히 얼마나 오래 실행할 수 있는가가 아니라, 언제 계속하고 언제 멈출 것인가를 관리하는 것입니다.
■ Long-running Agent는 여러 기술이 함께 작동하는 시스템이다
장기 실행 AI Agent의 구조를 정리하면 다음과 같습니다.
사용자가 업무 요청
↓
Runtime
Agent가 실제 작업을 수행할 실행환경 제공
↓
Context
현재 판단에 필요한 정보 구성
↓
State
현재 업무 진행 상태 관리
↓
Memory
이후에도 필요한 정보 보존
↓
Persistent Storage
파일과 작업 데이터를 실행환경 밖에 보존
↓
Checkpoint
안전하게 다시 시작할 수 있는 진행 지점 저장
↓
Background Execution
사용자가 연결되어 있지 않아도 업무 진행
↓
오류 또는 중단 발생
↓
Retry / Recovery
재시도하거나 저장된 상태에서 작업 복구
↓
필요한 경우 Human-in-the-loop
↓
완료 조건 확인
↓
업무 종료
따라서 Long-running Agent는 단순히 AI 모델이 더 오랫동안 생각하는 기술이라고 보기 어렵습니다.
AI 모델이 장시간 업무를 수행할 수 있도록 실행환경을 제공하고, 현재 진행 상태를 기록하고, 파일과 결과물을 저장하고, 작업 중단에 대비해 Checkpoint를 만들고, 오류가 발생하면 복구하고, 필요한 순간에는 사람의 판단을 요청하는 여러 기술이 함께 작동하는 시스템에 가깝습니다.
AI Agent의 작업 시간이 길어질수록 중요한 것은 모델의 Context Window만이 아닙니다.
AI가 무엇을 알고 있는가와 함께, 지금 무엇을 하고 있으며 어디까지 했고 문제가 생기면 어디서부터 다시 시작할 것인가를 관리하는 기술이 필요합니다.
────────────────────
■ 용어 정리
런타임(Runtime)
AI Agent가 실제 프로그램과 도구를 실행하며 작업하는 컴퓨팅 환경.
문맥(Context)
AI 모델이 현재 판단을 내리기 위해 참고하는 정보.
메모리(Memory)
Agent가 이후의 작업이나 상호작용에서도 활용하기 위해 보존하는 정보.
상태(State)
Agent가 현재 수행하고 있는 업무의 진행 상황을 나타내는 정보.
체크포인트(Checkpoint)
작업이 중단됐을 때 특정 지점부터 다시 시작할 수 있도록 저장한 진행 상태.
지속 저장소(Persistent Storage)
실행환경이 종료되어도 필요한 파일과 데이터를 보존하는 저장공간.
비동기 실행(Asynchronous Execution)
사용자가 결과를 계속 기다리지 않아도 Agent가 백그라운드에서 업무를 수행하는 방식.
복구(Recovery)
Agent의 Process나 실행환경이 중단된 뒤 저장된 상태를 이용해 작업을 이어가는 과정.
멱등성(Idempotency)
같은 작업이 여러 번 요청되더라도 결과가 의도치 않게 중복되지 않도록 만드는 성질.
사람 개입형 구조(Human-in-the-loop)
AI가 특정 단계에서 사람의 검토·판단·승인을 받은 뒤 다음 작업을 진행하는 구조.
────────────────────
■ 함께 읽으면 좋은 글
콤퓨타이슈
「AI Agent는 이제 며칠 동안 일한다 — OpenAI·AWS가 만드는 ‘장기 실행 AI’ 인프라」
────────────────────
■ 참고자료
AWS — Use isolated sessions for agents
https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-sessions.html
AWS — File system configurations for AgentCore Runtime
https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-filesystem-configurations.html
AWS — Host agent or tools with Amazon Bedrock AgentCore Runtime
https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agents-tools-runtime.html
AWS — Handle asynchronous and long running agents with Amazon Bedrock AgentCore Runtime
https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-long-run.html
AWS — Instances - Amazon Bedrock AgentCore
https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-instances-how-it-works.html
Microsoft — Durable state store for Microsoft Foundry hosted agents
https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/agent-state-store
Microsoft — Resilience for long-running Microsoft Foundry hosted agents
https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/long-running-agent-resilience