한 줄 정의

관리형 에이전트는 실행 환경, 메모리, 도구 사용, 신원, 로그를 클라우드 관리 계층에서 제공하는 배포 방식이야. Agent가 목표를 받고 여러 단계를 이어 가는 실행 구조라면, 이 방식은 그 구조를 운영 환경에 올릴 때 필요한 런타임과 통제 장치를 서비스가 직접 제공해. 영문 자료에서 managed agents라고 적힌 경우도 이 운영 범위를 가리키는지 먼저 봐야 해.

2026년 4월 28일 AWS와 OpenAI가 발표한 구체 사례는 Amazon Bedrock의 OpenAI 기반 관리형 에이전트야. 이 preview는 Amazon Bedrock 안에서 최신 OpenAI 모델과 OpenAI 하네스를 쓰고, 각 에이전트의 신원, 행동 로그, 기본 컴퓨트 환경을 AWS 관리 계층에서 제공하는 흐름으로 읽어야 해.

어떻게 작동하나

작동 흐름은 “모델을 부른다”가 아니라 “에이전트를 운영 가능한 단위로 배포한다”는 뜻이야. 팀은 에이전트가 해야 할 일, 쓸 도구, 필요한 메모리와 스킬, 접근해야 할 AWS 데이터나 서비스 경계를 정해. 관리형 런타임은 추론 실행, 메모리, 스킬, 행동 로그를 같은 환경에서 기록하고 제어해. AWS 제품 페이지는 모든 추론이 Amazon Bedrock에서 돌고 데이터가 AWS를 떠나지 않는다고 설명해.

AWS가 공개한 구분은 세 층으로 보면 덜 헷갈려.

  • 모델 층: OpenAI 모델이 reasoning, 즉 여러 단계를 따져 보는 판단 과정과 생성 작업을 맡아.
  • 하네스 층: OpenAI 에이전트 하네스(agent harness)가 장기 작업 조향, 도구 사용, 여러 단계 워크플로를 조직해.
  • 운영 층: AWS 관리 계층이 에이전트 신원, 행동 로그, AWS 안의 실행 환경, AgentCore 기본 컴퓨트 환경을 제공해.

예를 들어 고객지원 에이전트를 만든다면 단순 답변 생성만으로는 부족해. 주문 기록을 읽는 권한, 환불 API 호출 조건, 사람이 승인해야 하는 금액 기준, 상담 로그 보관, 실패한 도구 호출 재시도 규칙이 같이 필요해. 관리형 경로는 이런 운영 부품을 AWS 계정과 보안 기준 안에서 통합하도록 돕는 서비스야.

다른 장면은 사내 리서치나 문서 작업 에이전트야. 회의 전 자료를 찾고, 내부 문서를 읽고, 작업 목록을 만들고, 후속 액션을 남기는 흐름에서는 context, 즉 작업 문맥의 유지, 메모리, 도구 검색, 관측 가능성이 중요해져. 여기서 Agents SDK는 개발자가 코드로 에이전트 루프를 설계하는 도구이고, 관리형 서비스는 그 루프를 AWS 인프라와 감사 기준 안에서 실행해.

왜 중요한가

이 개념이 중요한 이유는 에이전트 도입의 중심 질문을 바꾸기 때문이야. “모델이 복잡한 일을 잘하나” 다음에는 바로 “그 에이전트가 어떤 권한으로 행동하고, 어느 환경에서 실행되고, 어떤 로그를 남기고, 실패하면 누가 볼 수 있나”가 따라와. 기업 환경에서는 이 두 번째 질문이 실제 배포를 막는 경우가 많아.

Amazon Bedrock과의 차이도 여기서 갈려. Bedrock은 여러 모델 접근, 보안 통제, 미세 조정, 오케스트레이션을 담는 큰 플랫폼이야. OpenAI 기반 Bedrock 관리형 에이전트는 그 안에서 agent를 빠르게 배포하는 특정 경로야. 같은 발표에 나온 Codex on Bedrock도 별도 항목이야. Codex는 명령줄 도구(CLI), 데스크톱 앱, VS Code 확장 같은 제품 사용 흐름이고, 이 항목은 기업이 자기 업무용 agent를 AWS에서 운영할 때 보는 실행 계층이야.

Agent Platform과 비교하면 범위가 더 선명해. Agent Platform은 여러 모델과 프레임워크까지 포괄하는 운영 프레임워크를 가리킬 수 있어. 반면 AWS 발표의 Bedrock 구현은 OpenAI 모델과 OpenAI 에이전트 하네스에 최적화된 관리형 경로야. 모든 에이전트 프레임워크를 같은 방식으로 받아 주는 범용 표준이라고 읽으면 범위가 넓어져.

주의해서 볼 점

첫째, 2026년 4월 28일 발표 기준으로 OpenAI models on AWS, Codex on AWS, OpenAI 기반 Bedrock 관리형 에이전트는 모두 제한적 미리보기야. 그래서 일반 출시처럼 가격, 리전, 계정 접근, 모델별 기능이 모두 확정됐다고 읽으면 안 돼.

둘째, 관리형이라는 말이 보안 책임을 없애지는 않아. AWS 문서는 각 agent가 자기 신원을 갖고 행동을 로그로 남긴다고 설명하지만, 어떤 도구를 허용할지, 어떤 행동에 사람 승인을 둘지, 비용과 실패를 어떤 대시보드에서 볼지는 여전히 팀이 정해야 해. Eval도 자동으로 끝나는 게 아니라 운영 중 샘플링과 실패 사례 검토가 필요해.

셋째, 로그와 reasoning을 섞으면 안 돼. 행동 로그는 에이전트가 어떤 도구를 호출했고 어떤 작업을 했는지 감사하기 위한 기록이야. 모델 내부의 숨은 사고 과정 전체가 그대로 공개된다는 뜻이 아니야. 실무에서는 행동 로그, 도구 결과, 승인 기록, 최종 응답을 따로 놓고 봐야 원인 분석이 가능해.