목차

• AgentCore Identity: 누가 무엇을 할 수 있는가
• AgentCore Gateway: 적절한 도구 사용, 토큰 낭비 방지
• AgentCore Memory: 에이전트가 기억하는 것
• AgentCore Runtime: Firecracker, MicroVMs 및 컨테이너
• 보너스: 네트워크 마법 없이 수행하는 교차 계정(cross-account) 및 교차 리전(cross-region) 설정
  • 예시 1: Runtime 타겟 — 네트워크가 필요 없으므로 존재하지 않음
  • 예시 2: MCP 타겟 — 시맨틱 검색(semantic search), 하지만 네트워크는 직접 구축
  • 어떤 것을, 언제 사용할 것인가
• 비용
• 결론을 대신하여

AgentCore 플랫폼은 Amazon의 스토어와 최종 고객의 문제를 해결해 온 20년 이상의 AWS 경험을 바탕으로 구축되었습니다. 이 서비스는 컴퓨팅(compute), 네트워크(network), 스토리지(storage) 및 데이터베이스(databases)에 대해 우리가 이미 구축해 온 많은 아이디어를 재구성하며, 소프트웨어 정의 네트워크(software-defined networking)를 깊이 있게 알지 못해도 계정 간 및 리전 간의 연결을 가능하게 합니다. 또한 레거시 시스템을 새로운 에이전트에 연결하는 방법도 제공합니다. 플랫폼은 여러 기능으로 구성되어 있으며, 하나씩 살펴보겠습니다: Identity, Gateway, Memory, 그리고 Runtime입니다.

AgentCore Identity: 누가 무엇을 할 수 있는가

AgentCore Identity는 워크로드 ID (workload identity)라고 불리는 추상화 계층을 통해 에이전트의 ID와 외부 서비스 및 도구에 대한 액세스를 관리합니다. 외부 서비스용 키는 bedrock-agentcore-identity! 접두사 아래 Secrets Manager에 보관됩니다. 실제로 이 서비스는 식별 흐름(identification flow) — 즉, 누가 무엇을 하고자 하는지, 그리고 그것이 승인되었는지 여부를 관리합니다. 이를 통해 rogue behavior(비정상 동작)가 없음을 보장합니다. 에이전트는 당신이 부여한 만큼의 액세스 권한만을 가집니다.

두 가지 형태의 인증(authentication) 및 인가(authorization)가 제공됩니다.

2LO (2-legged OAuth) — 에이전트가 사전에 발급된 토큰을 사용하여 외부 시스템에 자신을 증명합니다. 이는 귀하를 대신하여 무엇을 할 수 있는지 정확히 정의하는 일종의 통행증과 같습니다. 비밀 정보(secrets)는 Secrets Manager에 보관됩니다. iGaming 분야에서 2LO는 어떻게든 피해야 할 일종의 금기 사항입니다. 토큰이 엄격한 정책에 따라 KMS 키로 암호화되어 있는지 여부와 상관없이, PAT(Personal Access Token)라는 단어는 정보 보안 (infosec) 커뮤니티에서 강한 감정을 불러일으킵니다. 마치 왕좌의 게임 (Game of Thrones)에서 드래곤 주변의 "드라카리스 (dracarys)"와 비슷합니다.

3LO (3-legged OAuth) — 여기에는 세 당사자가 있습니다: 에이전트, 사용자, 그리고 제3자 시스템입니다. 에이전트 자체는 Jira, Confluence 또는 GitHub에서 어떠한 권한도 가지고 있지 않습니다. 에이전트가 처음으로 귀하를 대신하여 동작할 것을 요청할 때, 시스템은 앱이 카메라에 접근해도 되는지 묻는 것과 마찬가지로 동의 화면을 보여줍니다. 이 화면에는 에이전트가 무엇을 할 수 있는지(예: 티켓 읽기만 가능)가 정확히 명시되며, "허용 (Allow)"을 누르면 시스템은 해당 권한만을 가진 토큰을 발행하고 AgentCore Identity가 이를 귀하를 위해 저장합니다. 그 이후부터 에이전트는 해당 토큰으로 작동하며 승인된 작업만 수행할 수 있으며, 그 이상은 불가능합니다. 각 시스템(Jira, Confluence, GitHub)에 대한 동의는 별도로 이루어지며 각기 고유한 권한을 가집니다.

2LO 예시:

resource "aws_bedrockagentcore_api_key_credential_provider" "github" {
  name               = "github-pat-token"
  api_key_wo         = local.envs["GITHUB_PAT"]
...

하지만 Identity와 키는 이야기의 절반일 뿐입니다. 에이전트에게는 해당 키로 접근할 수 있는 도구(tools)도 필요합니다. 여기서 Gateway가 등장합니다.

AgentCore Gateway: 토큰 낭비 없는 적절한 도구 선택

AgentCore Gateway를 사용하면 Lambda 함수, Smithy 모델, OpenAPI 호환 API 및 외부 MCP 서버에 연결할 수 있습니다. 또한 매우 중요한 문제도 해결합니다. 에이전트에게 너무 많은 도구를 부여하면, 에이전트가 종종 실수하여 잘못된 도구를 선택하는 경우가 발생합니다. 이는 토큰 비용을 발생시키며, 그 비용은 고객이 지불하게 됩니다. 이것이 바로 Gateway가 시맨틱 검색 (semantic search)을 사용하여 올바른 도구를 찾는 이유입니다.

Terraform 코드는 게이트웨이 (gateway)와 그 대상 (target)을 정의합니다. OpenAPI 스키마 (schema)는 JSON 형식으로 인라인 (inline) 전달할 수 있으며, 만약 YAML 형식이라면 Terraform 함수인 jsonencode(yamldecode(...))를 사용하여 변환합니다. 한 가지 특이사항이 있습니다. 대상이 AgentCore 런타임 (Runtime) 에이전트인 경우, 게이트웨이에는 프로토콜 유형 (protocol type)이 설정되어 있지 않아야 합니다. 즉, 런타임 대상은 protocol_type = "MCP"가 설정된 게이트웨이에 추가될 수 없습니다.

data "aws_iam_policy_document" "gtw_plcy" {
  statement {
    sid     = "GetResourceOauth2Token"
...

때때로 외부 서비스에 대한 액세스 외에도, 에이전트가 최종 사용자에 대한 정보를 기억하여 사용자의 컨텍스트 (context)를 기반으로 더 가치 있는 솔루션을 제공하기를 원할 때가 있습니다. 이는 AgentCore 메모리 (Memory)를 통해 수행됩니다.

AgentCore Memory: 에이전트가 기억하는 것

메모리는 전략 (strategy)에 따라 사용자 선호도 (user preference, 사용자가 좋아하는 것), 시맨틱 (semantic, 컨텍스트로부터의 사실), 요약 (summarization), 그리고 커스텀 (custom)으로 나뉩니다. 장기 기록 (long-term records)의 추출은 비동기 (asynchronous) 방식으로 이루어지며 시간이 소요됩니다. 생성 시점에도 한 가지 특이사항이 있습니다. 각 전략은 다음 전략의 생성을 차단합니다. 즉, 두 개 이상의 전략을 설정하는 경우, 각 설정 사이에 대기 시간이 필요합니다. 경험적으로 약 190초 정도이며, 아래 코드에서는 안전을 위해 300초로 설정했습니다. Terraform에서는 다음과 같이 작성합니다.

resource "aws_iam_role" "bedrock_memory_role" {
  name               = "bedrock-agentcore-memory-role"
  assume_role_policy = data.aws_iam_policy_document.assume_role.json
...

기록은 계층적 네임스페이스 (hierarchical namespaces)에 저장되며, 쓰기 시점에 {actorId}와 {sessionId}가 실제 값으로 대체됩니다.

지금까지 설명한 모든 내용이 에이전트 자체에서 어떻게 결합되는지 살펴보겠습니다. 장기 메모리로부터 읽어오고, 게이트웨이 (SigV4 서명이 포함된 MCP)를 통해 도구 (tools)와 통신하며, 해당 턴 (turn)을 이벤트 (event)로 기록하는 과정입니다.

"""Repo Ops 에이전트 — AgentCore 런타임 (Runtime) 엔트리포인트 (entrypoint).

모든 요청의 흐름:
...

하지만 이 코드는 어딘가에 존재해야 합니다. 이제 제가 인터뷰에서 항상 얼어붙곤 하는 부분에 대해 다룰 차례입니다.

AgentCore Runtime: Firecracker, MicroVMs, 그리고 컨테이너 (containers)

저는 항상 AgentCore Runtime이 무엇인지 어떻게 설명해야 할지 고민해 왔습니다. MicroVMs, 가상 머신 (virtual machines), 컨테이너 (containers), 그리고 프로세스 (processes)에 관한 질문은 언제나 설명하기가 어렵습니다. 어쩌면 저 자신도 완전히 이해하지 못하고 있는 것일지도 모르고, 혹은 그 심연이 너무 깊어서 간단히 설명하기 어려운 것일지도 모릅니다. 그래서 저는 조금 떨어진 곳에서부터 시작하기로 했습니다. 아마도 이러한 질문들이 제가 인터뷰에서 답변을 망설이게 만드는 바로 그 지점들이기 때문이기도 할 것입니다.

오해를 풀기 위해, MicroVM부터 시작하겠습니다.

애플리케이션(AI 애플리케이션 포함)을 배포하는 두 가지 옵션은 가상 머신 (virtual machine)과 컨테이너 (container)입니다. 차이점은 다음과 같습니다. 컨테이너는 애플리케이션의 모든 의존성 (dependencies)과 라이브러리 (libraries)를 패키징하며 호스트와 공통된 커널 (kernel) 및 운영체제 (operating system)를 공유하는 반면, 각 가상 머신은 자신만의 커널, 자신만의 운영체제, 그리고 할당된 전용 리소스 영역을 가집니다. 커널은 드라이버를 통해 하드웨어를 관리합니다. 즉, 커널은 CPU 시간과 메모리에 대한 제한 없는 접근 권한을 갖지만, 애플리케이션은 그렇지 않습니다.

일반적으로 가상 머신이 컨테이너보다 더 안전하다고 가정됩니다. 왜 그럴까요? 아마도 컨테이너가 호스트와 커널을 공유하기 때문일 것입니다.

그것이 가상 머신에 비해 컨테이너를 불안전하게 만드는지에 대해서는 논란의 여지가 있습니다. 가상 머신을 사용하면 패칭 (patching), 드라이버 관리 (driver management)가 필요하며 시작 속도가 느립니다. 또한 distroless 컨테이너라는 옵션도 있습니다. 쉘 (shell)도 없고 패키지 관리자 (package managers)도 없으며, 오직 최종 애플리케이션에 필요한 것만 포함합니다.

MicroVM은 가상 머신의 강력한 격리 (isolation) 특성을 제공하면서도 느린 시작 속도 문제를 해결하려고 시도합니다. 각 머신은 자신만의 가상화된 커널을 가지고 옵니다. AWS Lambda의 기반이 되는 MicroVM 기술인 Firecracker를 사용하면 초당 최대 150개의 MicroVM을 실행할 수 있으며, 각 MicroVM은 약 125ms 만에 부팅됩니다.

그렇다면 가상 머신(Virtual Machine)과 컨테이너(Container)가 AgentCore Runtime과 무슨 상관이 있을까요? Firecracker는 AgentCore Runtime의 배후에 위치합니다. 즉, 컨테이너를 배포하면 그것이 Firecracker 가상 머신 위에서 실행되는 구조입니다. 이를 통해 최대 수준의 격리(Isolation)를 제공합니다. 하이퍼바이저(Hypervisor) 수준에서 차단되므로, 하나의 Firecracker 머신이 다른 머신의 리소스를 사용할 수 없습니다. 동시에 모든 종속성을 포함한 컨테이너 형태로 어떤 AI 애플리케이션이라도 가장 쉽게 배포할 수 있게 해줍니다. Firecracker 프로세스 자체와 더불어, 호스트는 jailer라고 불리는 프로그램도 실행합니다. 이는 가상 머신이 침해될 경우를 대비해 가상 머신을 감싸는 두 번째 방어 계층(샌드박스, Sandbox) 역할을 합니다.

이 기술은 모든 고객의 데이터, 메모리 및 프로세스의 보안과 격리를 보장합니다. AgentCore Runtime은 Lambda, 컨테이너 및 인스턴스에 대한 Amazon의 경험을 바탕으로 구축되었습니다.

Runtime을 사용하면 SDK나 프레임워크에 관계없이 8080 포트에서 HTTP를 노출하는(MCP 서버의 경우 포트는 8000입니다) 모든 AI 에이전트 또는 MCP 서버를 배포할 수 있습니다. AWS는 이 서비스의 개념이 프레임워크에 구애받지 않는(Framework agnostic) 것이라고 밝힙니다. 즉, 기업의 가장 소중한 자산인 데이터를 보호하며 에이전트를 위한 미래의 안전한 안식처가 되는 것입니다. 메모리, 액세스 관리(Access management), 타 서비스와의 연결성, 그리고 에이전트 평가(Agent evaluation)와 결합하여 하나의 완전한 AI 플랫폼을 형성합니다.

애플리케이션을 준비하는 단계는 세 가지입니다.

• 애플리케이션이 위치할 컨테이너 이미지 레지스트리(Container image registry) 생성:

resource "aws_ecr_repository" "agent_repo" {
  name                 = "agent-repo"
  image_tag_mutability = "IMMUTABLE"
...

• 애플리케이션의 모든 종속성을 포함한 Dockerfile 작성:

# AgentCore Runtime은 오직 Gr