AI 에이전트가 한 번의 질문에 답하는 도구에서 며칠 동안 상태를 유지하는 작업자로 바뀌고 있다. 지속시간이 길어질수록 비용·권한·기억을 통제하는 운영체계가 제품 경쟁력의 핵심이 된다.
긴 세션이 바꾸는 운영 문제
AWS는 2026년 8월 Amazon Bedrock AgentCore의 런타임 인스턴스가 최대 14일 동안 지속되는 프로덕션 에이전트 작업을 지원한다고 밝혔다. 장기 실행은 코드작성, 연구, 데이터 처리처럼 여러 단계가 필요한 업무를 가능하게 한다. 동시에 사용자가 자리를 떠난 뒤에도 모델이 외부 도구와 데이터에 접근하는 시간이 길어진다.
짧은 호출에서는 실패가 한 번의 오류로 끝나지만 장기 작업에서는 작은 판단 착오가 누적된다. 중간 상태 저장, 재시작 지점, 사람이 개입할 조건, 예산 상한을 설계하지 않으면 성능 향상이 운영 위험으로 바뀐다.
데이터를 옮기지 않는 구조의 장단점
구글클라우드는 2026년 7월 Borderless Lakehouse를 소개하며 AWS·Azure·온프레미스에 있는 데이터를 옮기지 않고 분석하는 방향을 제시했다. 데이터 복제를 줄이면 지연과 중복 비용을 낮출 수 있지만, 권한 체계와 감사 로그가 여러 환경에 걸쳐 일관돼야 한다.
장기 에이전트가 분산 데이터에 접근하면 모델 권한과 데이터 권한을 분리해야 한다. 에이전트가 사용할 수 있는 도구, 각 도구의 행위 범위, 특정 시간 이후의 재승인을 각각 관리해야 한다. 단일 API 키로 모든 경계를 넘는 구조는 편리하지만 사고 반경도 넓힌다.
기업이 먼저 세울 네 가지 한도
첫째 세션별 비용 한도, 둘째 외부행동 횟수 한도, 셋째 민감데이터 노출 한도, 넷째 사람 승인 없는 연속 실행시간 한도가 필요하다. 결과 정확도만 측정하면 장기 실행의 중간 실패와 복구 비용을 놓친다. 성공률과 함께 중단률, 재시작 비용, 권한 거부율을 관찰해야 한다.
전망은 분명하다. 클라우드 경쟁은 모델 목록보다 통제면의 품질로 이동한다. 오래 실행되는 에이전트를 안전하게 중지하고 설명하며 복구할 수 있는 사업자가 신뢰를 얻는다. 기업은 시범사업 단계부터 운영 지표와 감사 가능성을 제품 요구사항으로 넣어야 한다.
판단을 바꿀 조건
이 분석은 현재 공개된 수치와 제도 문서를 기준으로 한 조건부 판단이다. 이후 원자료의 수정, 시행 일정의 변경, 계약 조건이나 집행 세칙의 공개가 나오면 결론도 달라질 수 있다. 특히 발표 규모와 실제 집행액, 평균치와 취약 구간, 명목 목표와 비용 부담 주체를 구분해야 한다. 후속 평가는 같은 지표를 같은 주기로 다시 확인하고, 유리한 수치만 고르지 않으며, 예상과 다른 결과가 나타났을 때 원인을 외부 충격과 설계 실패로 나눠 검토해야 한다. 독자는 단일 전망보다 어떤 조건에서 위험이 커지고 줄어드는지를 중심으로 판단할 필요가 있다.
출처 및 확인 시각
- Amazon Web Services — Runtime instances: persistent compute for production AI agents on Amazon Bedrock AgentCore (2026-08-06, 확인 2026-08-20 17:25 KST)
- Google Cloud — Introducing the Borderless Lakehouse (2026-07-29, 확인 2026-08-20 17:25 KST)
- Amazon Web Services — Secure AI agents with temporal policies in Amazon Bedrock AgentCore (2026-08-06, 확인 2026-08-20 17:25 KST)
이 글은 공개된 1차 자료를 대조해 작성한 독립 분석이며 특정 자산의 매수·매도를 권유하지 않는다.
의견을 남겨주세요