AWS가 AgentOps를 정의했습니다. Amazon Bedrock AgentCore가 프로덕션 환경에서 에이전트를 실행하는 방식을 어떻게

DevOps는 소프트웨어를 안정적으로 배포하기 위한 공통된 어휘를 제공했습니다. MLOps는 모델을 위해 동일한 역할을 수행했습니다. 하지만 이 중 어느 것도 에이전트(Agents)에는 깔끔하게 적용되지 않습니다. 에이전트는 미리 결정된 워크플로우(Workflow)를 실행하지 않고, 여러 도구(Tools)를 가로질러 추론하며, 작업 도중에 하위 에이전트(Sub-agents)를 생성하고, 비선형적인 방식으로 비용을 발생시키는 시스템이기 때문입니다. AWS는 바로 다음에 올 단계에 대한 프레임워크를 방금 발표했으며, Amazon Bedrock AgentCore는 이를 실행하는 인프라입니다.

적절한 용어가 없었던 문제

표준 소프트웨어는 예측 가능한 방식으로 실패합니다. 테스트를 작성하고, 회귀(Regressions)를 잡아내며, 오류를 특정 라인으로 추적할 수 있습니다. 에이전트는 다르게 실패합니다. 동일한 입력이라도 메모리 상태, 도구 가용성, 그리고 이번에 LLM(Large Language Model)이 무엇에 가중치를 두기로 결정했느냐에 따라 다른 출력을 생성합니다. 멀티 에이전트 체인(Multi-agent chain)이 잘못된 답을 내놓을 때, 어떤 에이전트, 어떤 도구 호출(Tool call), 그리고 어떤 결정 지점이 오류를 유발했는지 파악하는 것은 진정으로 어려운 일입니다.

비용 문제 또한 구조적입니다. 단일 사용자 요청이 계층적 에이전트 체인이나 협업 스웜(Collaborative swarms) 전체로 퍼져나갈 수 있으며, 각 단계는 예산에 없던 도구를 호출하고 컴퓨팅 자원을 가동합니다. API 엔드포인트(Endpoint)를 제한하는 방식으로는 에이전트의 속도 제한(Rate-limit)을 걸 수 없습니다. 에이전트가 호출 횟수를 스스로 결정하기 때문입니다.

지금까지 부족했던 것은 더 나은 에이전트가 아니었습니다. 에이전트를 둘러싼 운영 규율(Operational discipline)이었습니다. 즉, 에이전트가 무엇에 접근할 수 있는지 어떻게 거버넌스(Govern)할 것인지, 어떻게 버전 관리 및 배포할 것인지, 어떻게 체계적으로 품질을 평가할 것인지, 그리고 사후에 결정을 어떻게 추적할 것인지에 대한 것입니다. AWS는 이를 AgentOps라고 부르고 있으며, 이는 MLOps가 DevOps를 확장한 것과 마찬가지로 GenAIOps의 에이전트적 확장(Agentic extension)으로 명시적으로 프레임화되었습니다.

AgentCore의 실제 작동 방식

Amazon Bedrock AgentCore는 실제 에이전트 배포가 실패하는 지점과 직접적으로 연결되는 네 가지 기둥(Pillars)을 중심으로 구조화되어 있습니다.

**거버넌스 및 보안 (Governance and Security)**은 멀티 에이전트 시스템 (multi-agent systems)에서 권한 부여 (authorization)가 기본적으로 모호하다는 인식에서 시작됩니다. 에이전트 A가 제한된 권한을 가진 사용자를 대신하여 에이전트 B를 호출할 때, 에이전트는 해당 제한 사항을 상속받아야 하지만 대부분의 에이전트 프레임워크에는 이를 강제하는 기능이 없습니다. AgentCore Identity는 요청이 체인을 통해 전파되는 동안 보안 경계를 유지하는 교차 에이전트 인증 프로토콜 (cross-agent authentication protocols)을 처리합니다. AgentCore Gateway는 API, Lambda 함수 및 외부 서비스를 단일 인증 엔드포인트 뒤에서 MCP 호환 도구로 변환하므로, 에이전트가 자격 증명 (credentials)을 직접 다루는 일이 없습니다. Cedar 기반의 정책 평가 (policy evaluation)는 도구 요청을 가로채고 실행 전에 결정론적 규칙 (deterministic rules)에 따라 이를 검증합니다. 이를 통해 단순히 역할 (role) 수준이 아니라, 호출 (per-call) 수준에서 "지금 이 작업을 수행할 권한이 있는가"에 대한 답을 제공합니다.

**빌드 및 운영 (Build and Operations)**은 모든 에이전트, 도구 및 메모리 설정을 버전이 지정된 독립적으로 배포 가능한 아티팩트 (artifact)로 취급합니다. 권장되는 구조는 네 개의 분리된 리포지토리 (repositories)입니다: 인프라 (계정 설정, 레지스트리, 시드 코드), 에이전트 (도구, 가드레일 및 프롬프트를 위한 공유 모듈이 포함된 솔루션 코드), 도구 (자체 CI/CD를 갖춘 MCP 서버), 그리고 애플리케이션 (에이전트를 사용하는 비즈니스 계층)입니다. 이러한 분리를 통해 독립적인 버전 관리와 명확한 소유권이 가능해집니다. AWS Agent Registry는 에이전트가 조직 전체에서 검색 가능해지기 전에 초안 (draft), 대기 (pending), 승인 (approved) 단계의 승인 워크플로 (approval workflow)를 갖춘 중앙 집중식 카탈로그를 제공합니다.

**평가 (Evaluation)**는 도구 정확도 (tool accuracy), 대화 턴 품질 (conversation turn quality), 세션 결과 (session outcome), 그리고 전체 시스템 동작 (full system behavior)의 네 가지 수준에서 실행됩니다. CI/CD 파이프라인은 인증 흐름 검증 (authentication flow validation) 및 멀티 에이전트 체인 (multi-agent chains) 전반의 권한 확인 (authorization checks)을 포함하여 7가지 테스트 차원에 걸쳐 프리 프로덕션 (pre-production) 환경에서 평가를 트리거합니다. 여기서 권한 확인이란 여러 에이전트를 통해 요청이 전파되는 것을 시뮬레이션하는 맞춤형 테스트 설정을 통해, 모든 단계에서 신원(identity)과 권한(permissions)이 제대로 전달되는지 확인하는 것을 의미합니다. 이는 대부분의 팀이 건너뛰는 부분이지만, 프로덕션 (production) 환경에서 문제가 발생했을 때 가장 중요한 부분입니다.

**관측성 (Observability)**은 결정 추적 (decision traces), 도구 호출 패턴 (tool invocation patterns), 지연 시간 및 에러율 (latency and error rates), 그리고 상호작용당 비용 (cost per interaction)의 네 가지 텔레메트리 (telemetry) 계층을 다룹니다. AgentCore Observability 대시보드는 각 에이전트 배포마다 별도의 커스텀 계측 (custom instrumentation)을 요구하지 않고도 이 모든 정보를 표면화합니다.

팀들이 실제로 이 기술을 사용하는 용도

AWS가 공개한 참조 아키텍처 (reference architecture)는 멀티 계정 AWS 설정(공유 서비스 계정, 사업 부문별 전용 dev/pre-prod/prod 계정)을 매핑합니다. 여기서 AgentCore Runtime은 배포를 담당하고, AgentCore Memory는 네임스페이스 기반 스코핑 (namespace-based scoping)을 통해 단기 및 장기 컨텍스트 (context)를 모두 처리하며, AgentCore Gateway는 모든 도구 액세스 (tool access)의 전면에 위치합니다.

메모리 아키텍처 (memory architecture)는 별도로 이해할 가치가 있습니다. 데이터 (RAG를 통해 액세스되며 전통적인 액세스 제어 (access controls)에 의해 관리되는 문서 및 지식 베이스)와 메모리 (에이전트의 작업 컨텍스트 (working context) — 대화 기록, 사용자 선호도, 각 세션과 함께 진화하는 상호작용 패턴) 사이에는 구분이 존재합니다. AgentCore Memory는 이 두 가지를 모두 처리하며, 생성 시점에 정의된 네임스페이스 (namespaces)를 통해 액터 (actor), 세션 (session) 또는 애플리케이션 (application) 수준에서 메모리의 범위를 지정합니다. AWS가 사용하는 보험 사례 — 사기 탐지 에이전트와 보험금 청구 에이전트 — 에서 각 에이전트는 도메인 특화 신호를 위한 전용 메모리 리소스를 가지는 동시에, IAM 정책에 의해 관리되는 공통 사용자 상세 정보 리소스를 공유합니다.

Swisscom은 기업 규모의 고객 지원 및 영업 에이전트에 AgentCore를 사용하는 프로덕션 참조 구현 (production reference implementation) 사례로 언급되었습니다.

이것이 보기보다 더 중요한 이유

AWS가 여기서 실제로 하고 있는 일은 "프로덕션 환경에서 에이전트를 어떻게 실행할 것인가"라는 문제를 팀별 임기응변이 아닌 해결된 문제로 만들기 위한 기반을 다지는 것입니다.

CI/CD 통합은 이 분야가 나아갈 방향에서 가장 중요한 부분입니다. 현재 에이전트를 소프트웨어로 취급하는 대부분의 팀은 웹 서비스를 배포하는 것과 동일한 방식으로 에이전트를 배포합니다. 즉, 코드를 푸시하고, 제대로 작동하기를 바라며, 프로덕션 환경에서 디버깅을 합니다. AgentOps 모델은 에이전트 배포를 모델 배포 (model deployment)와 더 유사하게 만듭니다. 버전이 지정된 아티팩트 (versioned artifacts), 평가 게이트 (evaluation gates), 단계적 출시 (staged rollouts), 그리고 AgentCore에 의해 자동으로 유지되는 불변의 런타임 버전 (immutable runtime versions)을 사용하는 방식입니다. 이것이 바로 기업 도입에 실제로 요구되는 인프라 규율 (infrastructure discipline)입니다.

Cedar 기반의 정책 계층 (policy layer)은 과소평가되어 있습니다. 실행 전 도구 호출 (tool calls)을 가로채고 결정론적 규칙 (deterministic rules)에 따라 이를 검증하는 정책 평가 (policy evaluation)는 "LLM에게 이것을 하지 말라고 지시했다"는 수준과는 차원이 다른 보증을 제공합니다. 이는 에이전트가 무엇을 시도하기로 결정하든 상관없이 강제할 수 있습니다. 모든 동작을 사용자의 IAM 역할 (IAM role)이 아닌 특정 에이전트 ID (agent identity)에 귀속시키는 ID 계층 (identity layer)과 결합되면, 컴플라이언스 (compliance) 및 감사 (audit) 팀이 실제로 활용할 수 있는 수단을 제공하게 됩니다.

AgentCore는 프레임워크 불가지론적 (framework-agnostic)이며 모델 불가지론적 (model-agnostic)입니다. 운영 계층 (operational layer)은 Strands Agents, LangGraph, CrewAI 또는 커스텀 하네스 (custom harness)를 실행하든 상관없이 작동합니다. 이것이 바로 핵심적인 전략입니다. 즉, 프레임워크가 진화하더라도 운영 인프라가 지속 가능한 계층 (durable layer)이 될 것이라는 점입니다.

가용성 및 액세스 (Availability and Access)

Amazon Bedrock AgentCore를 지금 바로 사용할 수 있습니다. 참조 아키텍처 (reference architecture) 및 구현 가이드는 AWS ML 블로그 포스트에 자세히 설명되어 있습니다. AgentCore Runtime, Memory, Gateway 및 Identity는 독립적인 구성 요소로 제공되므로, 전체 스택을 도입하지 않고도 원하는 기둥 (pillar)을 채택할 수 있습니다. 조직 전반의 에이전트 발견 (discovery) 및 승인 워크플로 (approval workflows)를 처리하는 AWS Agent Registry도 이번 릴리스의 일부입니다. 가격은 표준 Bedrock 사용량 기반 모델을 따르며, 블로그 포스트에는 각 기둥별 설정을 위한 지원 AWS 문서 링크가 포함되어 있습니다.

만약 멀티 에이전트 시스템 (multi-agent systems)을 구축하면서 아직 버전 관리된 아티팩트 (versioned artifacts), 평가 파이프라인 (evaluation pipelines) 또는 에이전트별 ID (per-agent identity) 없이 운영하고 있다면, 그 공백은 이제 단순히 언젠가 도달해야 할 베스트 프랙티스 (best practice)가 아니라 문서화된 운영 리스크 (operational risk)입니다.

MCP, 에이전트형 AI (agentic AI) 및 AI 인프라에 대한 더 많은 소식을 위해 팔로우하세요.