AI 에이전트 운영, Bedrock AgentCore에 어디까지 맡길까

AI 에이전트는 잘 작동하지만 주변 인프라까지 별도의 제품처럼 개발하고 운영해야 하는 상황이라면 Amazon Bedrock AgentCore를 시범 도입해 볼 만합니다. AWS가 현재 안내하는 모듈형 서비스와 기능은 13개입니다. 이 가운데 구체적인 운영 부담을 덜어 주는 것부터 선택하되, 에이전트의 업무 동작에 대한 책임은 계속 직접 맡아야 합니다.

2026년 10월 30일 기준 AWS의 공개 제품 페이지와 문서를 대조해 확인했습니다. 아래 구성 요소 목록은 AgentCore 제품 페이지에 연결된 개발자 개요 문서를 따릅니다. 각 요소가 어떤 자체 개발 작업을 대신할 수 있는지는 이 글의 엔지니어링 분석입니다.

Amazon Bedrock AgentCore란 무엇인가요?

AgentCore를 사용하면 프로덕션 환경에서 에이전트를 운영하는 데 필요한 작업 중 일부를 AWS에 맡길 수 있습니다. 에이전트는 모델을 활용해 다음 행동을 선택하고, 툴을 호출하며, 주어진 과제를 수행하는 소프트웨어입니다. 이 실행 루프가 로컬에서 응답한다고 해도 자격 증명과 실행 환경, 상태 관리, 접근 제어, 디버깅에는 여전히 상당한 작업이 필요합니다.

공연장을 떠올려 보면 이해하기 쉽습니다. 에이전트의 동작이 공연이라면 Runtime은 무대와 지원 설비를 제공하고, 접근 제어는 출입을 관리합니다. 메모리는 유용한 맥락을 보존하고, 관측 기능은 어떤 일이 일어났는지 기록합니다. 다만 공연의 목적을 정하고 성공 여부를 판단하는 일은 여전히 직접 해야 합니다.

AWS는 AgentCore의 지원 범위를 “Any framework. Any model.”, 즉 어떤 프레임워크든, 어떤 모델이든이라고 명시합니다. 제품 페이지에는 LangChain, OpenAI Agents SDK, Claude Agent SDK, Strands SDK와 자체 프레임워크가 나열되어 있습니다. 이는 AWS가 설명하는 플랫폼 차원의 지원 범위입니다. 모든 선택 기능의 연동 방식이 같거나 마이그레이션에 아무 작업도 필요 없다는 약속은 아닙니다. AWS 제품 개요.

에이전트 실행 루프를 누가 관리할지도 선택할 수 있습니다. Runtime에서는 직접 작성한 에이전트 코드를 배포합니다. Harness에서는 설정으로 에이전트를 정의하고, AWS의 오픈 소스 에이전트 프레임워크인 Strands Agents를 기반으로 하는 AWS 관리형 루프를 사용합니다. Harness 문서도 이 차이를 명확히 설명합니다. 이미 작동하는 오케스트레이션 코드가 있는 개발 조직이라면 Runtime 경로부터 검토하는 편이 좋습니다.

Bedrock Agents와 AgentCore는 어떻게 다른가요?

AgentCore가 나왔다는 이유만으로 기존 Amazon Bedrock Agents 배포를 옮길 필요는 없습니다. AWS는 현재 Bedrock Agents 사용자가 계속 해당 서비스를 이용할 수 있다고 안내합니다. AgentCore를 검토할 이유는 그 실행 환경이나 연동, 운영 기능이 필요한 구체적인 요구 사항이 있을 때입니다. AWS FAQ.

이제 두 서비스를 단순히 ‘관리형 루프 대 인프라’로 구분하기는 어렵습니다. AgentCore 역시 Harness를 통해 관리형 루프를 제공합니다. 먼저 오케스트레이션 코드를 직접 관리할지 결정한 뒤 그에 맞는 경로를 선택해야 합니다. 이때 더 넓은 관점의 AI 에이전트 아키텍처 가이드도 함께 참고하면, 호스팅을 선택하다가 의도치 않게 애플리케이션 전체를 재설계하는 일을 피할 수 있습니다.

AI 에이전트 운영: AgentCore 구성 요소별로 맡길 수 있는 일

직접 개발하고 운영해야 할 작업을 기준으로 구성 요소를 고르는 것이 좋습니다. AWS 문서에 따르면 이 기능들은 함께 사용할 수도, 독립적으로 사용할 수도 있는 모듈형 기능입니다. 마지막 열은 AWS가 기반 서비스를 제공하더라도 애플리케이션 쪽에서 계속 책임져야 할 영역입니다.

고객 지원 어시스턴트라면 Runtime, Gateway, Identity가 당장 필요할 수 있습니다. 이후 재방문 고객의 맥락이 유용해질 때 Memory를 추가하면 됩니다. 외부 리소스의 이용 권한을 구매하지 않는 어시스턴트라면 Payments는 필요하지 않습니다. 조직 안에서 승인된 리소스를 찾는 일이 어려워졌을 때는 Registry가 유용해집니다. 도입한 구성 요소의 수를 늘리는 것 자체가 목표가 되어서는 안 됩니다.

Code Interpreter와 Runtime은 서로 다른 문제를 해결합니다. Runtime은 에이전트를 호스팅하고, Code Interpreter는 에이전트가 실행하는 코드를 위한 샌드박스를 제공합니다. 부족한 것이 격리된 코드 실행 환경뿐이라면 오케스트레이션을 옮기기 전에 AI 에이전트 코드 샌드박스 가이드로 해당 요구 사항부터 비교하는 편이 좋습니다.

여전히 직접 결정해야 하는 아키텍처

관리형 인프라와 애플리케이션의 권한 판단 사이에 경계를 그어야 합니다. 고객 지원 워크플로를 예로 들면, 에이전트가 주문을 조회하고 상태를 설명한 뒤 후속 조치를 제안할 수 있습니다. AWS는 실행 환경과 접근 인프라를 제공할 수 있지만, 누구의 주문인지 확인하고 해당 조치를 허용할지는 애플리케이션이 판단해야 합니다.

Bedrock AgentCore Runtime: 실행 격리만으로 세션 소유자가 정해지지는 않습니다

Runtime은 어느 고객의 세션인지 몰라도 실행 환경을 격리할 수 있습니다. AWS 문서는 세션마다 전용 microVM 환경을 제공해 컴퓨팅, 메모리, 파일시스템 리소스를 분리한다고 설명합니다. 같은 문서에서 AgentCore는 세션과 사용자의 매핑을 강제하지 않으며, 클라이언트 백엔드가 그 관계를 관리해야 한다고 명시합니다. Runtime 세션 문서.

고객 지원 어시스턴트에서 브라우저가 보낸 세션 식별자만으로 해당 고객의 세션이라고 판단해서는 안 됩니다. 요청을 인증하고, 백엔드에서 접근이 허용된 세션을 확인한 뒤, 후속 시스템 접근도 그 고객의 범위로 제한해야 합니다. 인프라의 격리 경계와 애플리케이션의 권한 판단은 서로 다른 책임입니다.

Bedrock AgentCore Memory: 어떤 맥락을 남길지 먼저 정해야 합니다

Memory가 맥락 관리 인프라를 대신하더라도, 그 안에 무엇을 저장할지는 직접 결정해야 합니다. AWS는 단기 대화 맥락과 여러 세션에 걸쳐 유지되는 장기 정보를 지원합니다. Memory 문서.

고객이 간결한 답변을 선호한다는 사실을 기억하는 것과 주문 잔액의 기준 데이터를 저장하는 것은 다른 일입니다. 업무 기록의 기준 데이터는 애플리케이션에서 관리해야 합니다. 에이전트가 최신 기록을 어떻게 조회할지, 대화에서 얻은 어떤 정보를 보존해도 되는지, 기억한 선호가 더 이상 맞지 않을 때 어떻게 처리할지를 정해야 합니다. 메모리 서비스가 이런 데이터 설계까지 대신해 주지는 않습니다.

Bedrock AgentCore MCP: Gateway가 연결을 담당합니다

툴 연결을 위해 비슷한 개발 작업을 반복하고 있다면 Gateway가 유용합니다. Model Context Protocol, 줄여서 MCP는 에이전트에 툴을 제공하기 위한 공통 인터페이스입니다. Gateway는 API와 AWS Lambda 함수를 MCP 호환 툴로 전환하고 기존 MCP 서버에 연결할 수 있습니다. 현재 문서에는 다른 에이전트와 모델로 요청을 라우팅하는 기능도 설명되어 있습니다. Gateway 문서.

주문 어시스턴트라면 범용 데이터베이스 쿼리 툴을 제공하기 전에 배송 상태 확인처럼 범위를 좁힌 작업부터 제공하는 것이 좋습니다. Gateway는 호출을 전달할 수 있습니다. 그러나 그 작업이 무엇을 의미하는지, 어떤 기록에 접근할 수 있는지, 재시도할 때 같은 부수 효과가 반복될 수 있는지는 여전히 API에서 결정해야 합니다.

Bedrock AgentCore Identity: 자격 증명 외에 업무 규칙도 필요합니다

Identity는 누가 어떤 자격 증명으로 작업하는지를 담당하고, Policy는 게이트웨이에서 허용되는 작업을 통제합니다. Identity는 AWS 리소스와 외부 서비스에 접근하기 위한 워크로드 ID와 자격 증명 관리 기능을 제공합니다. 사용자를 대신해 작업하는 경우도 포함됩니다. Identity 문서.

Policy는 연결된 AgentCore Gateway를 통과하는 트래픽을 평가한 뒤 툴 접근을 허용합니다. 이 적용 범위를 정확히 이해해야 합니다. 에이전트가 게이트웨이를 거치지 않고 직접 보내는 별도의 네트워크 호출까지 게이트웨이 정책으로 통제된다고 가정해서는 안 됩니다. 민감한 작업은 정해진 정책 적용 지점을 통과하도록 하고, 우회 경로를 제한해야 합니다. Policy 문서.

고객 지원용 ID에는 주문 조회를 허용하되 환불 처리는 금지할 수 있습니다. 모델 지침에는 이 업무 흐름을 명시하고, 실제 권한은 툴과 권한 검사 계층에서 강제해야 합니다.

Bedrock AgentCore Observability: 트레이스가 있어도 업무 성공은 따로 판단해야 합니다

Observability는 에이전트의 동작 과정을 재구성하고, Evaluations는 그 동작을 평가하는 데 도움이 됩니다. AgentCore는 실행 과정 시각화와 OpenTelemetry 호환 텔레메트리를 제공하며, 대시보드는 Amazon CloudWatch를 기반으로 합니다. OpenTelemetry는 트레이스와 메트릭을 위한 표준 형식입니다. AWS는 기본 제공 메트릭과 애플리케이션에 직접 계측을 추가해 수집하는 트레이스 및 업무 메타데이터를 구분합니다. Observability 문서.

고객 지원 어시스턴트에서는 요청한 주문 조회가 완료되었는지, 후속 조치가 승인되었는지를 기록해야 합니다. 툴 호출이 기술적으로 성공했더라도 실제 업무 질문에는 엉뚱한 답을 할 수 있습니다.

Evaluations는 모델 기반 판정을 포함한 기본 제공 평가와 사용자 정의 평가를 지원합니다. 직접 대표성 있는 사례를 정의하고, 중대한 영향을 미치는 실패는 검토해야 합니다. 평가 문서에는 지원하는 프레임워크와 계측 경로가 명시되어 있습니다. 플랫폼의 폭넓은 호환성이 모든 기능에 그대로 적용된다고 해석하지 말고, 선택한 경로를 확인해야 합니다.

설계에 영향을 주는 제한 사항

컴퓨팅 환경의 수명과 필요한 상태의 보존 기간을 구분해야 합니다. AWS의 현재 수명 주기 문서에 따르면 기본 유휴 제한 시간은 15분, microVM의 최대 컴퓨팅 수명은 8시간입니다. 사용자 계정에서 관리형 Amazon Elastic Compute Cloud 용량을 실행하는 대안인 Instances는 용량 공급자 설정에 따라 수명을 최대 14일까지 설정할 수 있습니다. 수명 주기 설정, Instances.

논리적 세션은 새로 프로비저닝된 컴퓨팅 환경에서 재개될 수 있습니다. 기본적으로 메모리와 로컬 파일시스템의 상태는 컴퓨팅 환경의 수명 주기에 종속됩니다. 세션 스토리지를 설정하면 중지와 재개를 거치는 동안에도 파일시스템 데이터를 보존할 수 있습니다. 중단 후에도 반드시 남아 있어야 하는 데이터를 명확히 정해야 합니다. 세션 수명 주기와 스토리지.

도입할 기능을 확정하기 전에 AWS의 리전별 기능 지원표를 확인해야 합니다. 특정 리전에서 실행해야 하는 애플리케이션이라면 ‘AWS에서 제공한다’는 사실만으로는 충분하지 않습니다.

AgentCore는 언제 도입할 만한가요?

구체적인 운영 공백이 배포를 막고 있고, 이를 해결할 관리형 구성 요소가 요구 사항에 맞을 때 도입을 검토합니다. 실행 격리, 권한에 따른 툴 접근, 상태 보존, 문제 진단 가능성, 그리고 이 기능들을 직접 운영할 때의 부담을 기준으로 판단하는 것이 좋습니다.

개발자라면 이미 작동하는 에이전트 로직이 호스팅이나 툴 연동 때문에 배포되지 못하고 있을 때 시범 도입을 시작할 수 있습니다. 기존 실행 루프를 Runtime에서 유지하면 프레임워크와 배포 플랫폼을 동시에 바꾸는 것보다 실험 범위를 좁힐 수 있습니다.

운영 담당자라면 모든 에이전트에 같은 자격 증명 처리, 접근 통제, 장애 조사 기능이 필요할 때 도입 이유가 더 분명해집니다. 진단해야 할 실패 상황까지 포함해 이런 책임 영역을 검증할 수 있는 워크플로를 선택하는 것이 좋습니다.

기술 도입 의사결정자라면 어떤 반복 작업이 사라지고 어떤 새로운 연동 작업이 남는지를 따져야 합니다. AWS 설정, 권한 설계, 애플리케이션 동작, 온콜 대응에는 여전히 명확한 담당자가 필요합니다.

현재 스택이 필요한 통제 기능을 이미 제공하고 해결할 구체적인 문제가 없다면 도입을 미루는 편이 좋습니다. 이전하려면 현재 스택이 제공하지 못하는 기능처럼 별도의 이유가 있어야 합니다. 워크플로가 정해진 작업을 고정된 순서로 실행하며 다음 행동을 에이전트가 선택할 필요도 없다면 지금의 방식을 유지하면 됩니다.

비용이 의사결정을 좌우한다면 AWS의 AgentCore 요금 안내와 이 사이트의 Amazon Bedrock 요금 가이드를 함께 참고하는 것이 좋습니다.

AWS CLI로 첫 시범 도입 시작하기

AWS의 코드 기반 템플릿으로 시작한 뒤, 대표적인 업무 작업 하나를 추가합니다. 이 절차는 현재 Runtime 빠른 시작 문서와 전체 CLI 가이드를 따릅니다. 문서를 바탕으로 정리한 절차이며, 이 글을 위해 실제 배포를 테스트한 것은 아닙니다.

전체 가이드의 요구 사항은 Node.js 20.12 이상, npm, Python 3.10 이상, Python 의존성 관리 도구인 uv, 설정을 마친 AWS 자격 증명, 배포 권한, 모델 접근 권한입니다. 이 템플릿은 CodeZip을 사용하므로 Docker는 필요하지 않습니다.

1. 1

   설치와 프로젝트 생성

   개발용 AWS 계정이나 환경을 사용합니다.

   npm install -g @aws/agentcore
   agentcore --version
   agentcore create --name MyProject --template agent-python-strands

   템플릿에는 agent라는 이름의 Runtime과 AgentCore Memory 리소스가 포함됩니다. 생성된 설정에서 두 리소스를 모두 확인해야 합니다.

2. 2

   로컬 테스트

   cd MyProject
   agentcore dev --mode browser

   로컬 인스펙터에서 에이전트를 테스트한 뒤, 같은 터미널에서 다음 작업을 진행하기 전에 서버를 중지합니다.

3. 3

   빌드, 배포, 호출

   agentcore build
   agentcore deploy
   agentcore status
   agentcore invoke --runtime agent --payload '{"prompt":"Hello, what can you do?"}'

   배포 시 AWS Cloud Development Kit, 즉 CDK를 통해 AWS 리소스가 프로비저닝됩니다.

4. 4

   실행 내역 확인과 리소스 정리

   agentcore logs runtime
   agentcore traces runtime list

   시범 도입 프로젝트의 디렉터리에서 다음 명령을 실행하면 해당 프로젝트의 리소스와 배포된 스택을 제거합니다.

   agentcore remove all --yes
   agentcore deploy --yes

프로덕션 트래픽을 연결하기 전에 인사말을 테스트 주문 조회처럼 범위가 정해진 과제로 바꿉니다. 권장 수용 기준은 애플리케이션에 맞춰 정해야 합니다. 올바른 데이터가 반환되는지, 무단 접근이 거부되는지, 실패한 툴 호출이 트레이스에 나타나는지, 중단 후 복구 동작을 파악했는지 확인하는 것이 좋습니다. 이는 시범 도입의 판단 기준이며 AWS의 성능을 주장하는 내용은 아닙니다.

과도한 기대는 어디서 생기나요?

실행을 관리형 서비스에 맡겼다는 사실이 에이전트의 업무 판단이 옳다는 것을 입증하지는 않습니다. 호스팅, 트레이싱, 평가, 정책 적용은 서로 다른 문제를 해결합니다. 유용한 과제를 고르고, 허용할 행동을 정하고, 실패를 살펴보는 책임은 어느 기능도 대신해 주지 않습니다.

‘어떤 프레임워크든 지원한다’는 말을 ‘연동 작업이 필요 없다’는 뜻으로 받아들여서도 안 됩니다. 플랫폼이 유연하더라도 도입하는 각 서비스의 의존성, 인증, 계측, 인터페이스 규약은 직접 검증해야 합니다.

모든 구성 요소를 도입하는 것 역시 프로덕션 준비가 끝났다는 증거가 되지 않습니다. 읽기 전용 고객 지원 어시스턴트에 결제 권한이나 불필요한 브라우저를 추가한다고 더 나아지지는 않습니다. 구체적인 과제에 필요할 때 기능을 추가하고, 늘어난 권한도 함께 검토해야 합니다.

다음 업무일에 바로 할 일

기존 에이전트 작업 하나를 골라 무엇을 운영해야 해서 진행이 지연되는지 적어 봅니다. 그 지연을 없애는 데 필요한 AgentCore 기능만 시범 도입합니다. 이후의 배포 방식, 실패 처리, 관리 부담을 현재 스택과 비교하고, 확인된 근거가 뒷받침할 때 도입 범위를 넓히는 것이 좋습니다.

AI 시스템 개발과 운영에 필요한 실전 가이드를 뉴스레터로 받아 보세요.