Amazon Bedrock AgentCore로 구축하는 AgentOps (1): 파운데이션과 게이트웨이

본 사례는 AWS 3A(Agentic AI Acceleration) 프로그램에서 재사용 가능한 레퍼런스 asset으로 개발되었습니다.

이 글은 프로덕션 환경에서 에이전틱 AI를 운영하기 위한 2부작 시리즈입니다. 파운데이션을 세우는 것에서 시작해, 이를 안정적으로 운영하는 AgentOps까지 다룹니다.

Part 1: Amazon Bedrock AgentCore로 구축하는 AgentOps (1): 파운데이션과 게이트웨이 (이번 글)
Part 2: Amazon Bedrock AgentCore로 구축하는 AgentOps (2): 관측성, 평가 그리고 AgentOps

처음 생성형 AI가 등장했을 때를 떠올려 보면 구조는 무척 단순했습니다. 채팅 메시지나 검색 쿼리, 이미지, 문서 같은 입력을 넣으면 그에 맞는 응답을 돌려주는 챗봇이었습니다. 그런데 생성형 AI가 에이전틱 AI로 발전하면서 이야기가 달라졌습니다. 이제 에이전트는 단순히 모델 입력에 응답하는 것을 넘어 스스로 추론하고, 계획하고, 행동하는 존재가 되었습니다. 최근의 에이전틱 AI는 여러 도구와 RAG, 그리고 이를 관장하는 오케스트레이터까지 갖춘 훨씬 복잡한 구조를 가집니다.

요즘 자주 언급되는 “하네스 엔지니어링(harness engineering)”도 유사한 맥락입니다. 실제로 프로덕션 단계에서는 모델 자체의 성능만큼이나, 모델을 어떤 도구, 메모리, 가드레일, 위임 경로로 둘러싸는가가 최종 품질을 좌우합니다.

이제 우리는 이런 에이전틱 애플리케이션을 하나둘이 아니라 대규모로 배포하고 운영해야 하는 단계에 와 있습니다. 이 글은 바로 그 지점, 곧 생성형 AI와 에이전틱 AI 애플리케이션을 프로덕션에 안전하게 올리고 확장하려면 어떤 아키텍처가 필요한가에 대한 이야기입니다.

이 글의 중심에는 AgentOps가 있습니다. DevOps가 개발과 운영을 묶어 소프트웨어를 안정적으로 배포하고 운영하는 방법론이라면, AgentOps는 스스로 계획하고 행동하는 에이전트를 안전하고 효율적으로 배포하고 운영하기 위한 프로세스입니다. 모델을 고르고 도구를 붙여 에이전트를 만드는 데서 끝나지 않고, 빌드부터 거버넌스, 관측, 평가, 최적화, 그리고 다시 배포로 이어지는 운영의 라이프사이클 전체를 다룹니다.

이 글은 두 편으로 구성된 시리즈입니다. Part 1(이번 글)에서는 에이전틱 AI의 파운데이션 요소와 게이트웨이 패턴, 그리고 실전 데모를 다루고, Part 2에서는 관측성·평가·최적화와 AgentOps 라이프사이클을 실전 데모와 함께 살펴봅니다. 이번 글에서 함께 살펴볼 내용은 다음과 같습니다.

에이전틱 AI 아키텍처의 파운데이션 요소
게이트웨이로 모델, 도구, 에이전트 접근을 통합하기 (LLM/Tool/Agent Gateway와 Agent Registry)
게이트웨이의 실제 동작을 확인하는 데모

이를 위해, 에이전트를 대규모로 안전하게 구축·배포·운영할 수 있도록 지원하는 관리형 서비스인 Amazon Bedrock AgentCore를 활용했습니다.

Figure 1. AgentOps 데모 메인 화면

왜 프로덕션으로 가는 길이 어려울까

PoC를 프로덕션으로 전환해 본 분이라면, 그 과정이 결코 만만치 않다는 것을 잘 아실 겁니다. 성능, 확장성, 보안, 거버넌스 등 기존 애플리케이션을 프로덕션에 올릴 때 겪던 과제들은 에이전틱 AI에서도 그대로 적용됩니다.

문제는 에이전틱 AI가 요구하는 것이 여기서 끝나지 않는다는 점입니다. 에이전트는 정해진 규칙에 반응하는 것이 아니라 스스로 추론하고 계획하며, 긴 세션에 걸쳐 행동합니다. 바로 이 자율성이 이전에는 없던 새로운 차원의 과제를 만들어 냅니다.

에이전틱 AI의 ‘실패’는 잘못된 예측이 아니라 잘못된 행동입니다. 민감한 데이터에 자율적으로 접근하는 에이전트에게는 적절한 격리, ID 제어, 가드레일, 지속적인 모니터링과 평가, 그리고 때로는 사람의 직접 감독까지 필요합니다.

정리하면 이렇습니다. PoC가 ‘가능성’이라면, 프로덕션은 그 가능성을 책임질 수 있는 구조 위에서만 작동해야 합니다. 그 구조를 우리는 파운데이션(Foundation)이라고 부릅니다.

파운데이션을 바라보는 두 가지 시선

파운데이션을 구축하는 데에는 출발점이 다른 두 가지 관점이 있습니다.

개발팀 관점은 애플리케이션에서 출발합니다. 에이전틱 애플리케이션을 만들어 가면서 그 아래 기반을 점진적으로 갖춰 나갑니다.
플랫폼, IT팀 관점은 기반에서 출발합니다. 중앙 플랫폼을 먼저 세우고, 그 위에 여러 팀과 애플리케이션을 순차적으로 온보딩합니다.

방향은 정반대지만 핵심은 똑같습니다. 흩어진 컴포넌트를 통합하고, 거버넌스를 중앙에서 일관되게 제어한다는 것입니다.

파운데이션의 실제 모습

Figure 2. 파운데이션 구성 요소

파운데이션을 구성하는 요소들을 펼쳐 보면 다음과 같습니다.

오케스트레이션 레이어는 에이전트 내부 동작 아키텍처를 어떻게 구성할지 다룹니다.
중심에는 모델 레지스트리와 에이전트·도구 레지스트리가 있고, 이에 대한 접근을 일관되게 제공하는 게이트웨이가 있습니다.
런타임은 에이전트를 구축하고 실행하는 환경입니다(완전 관리형, 서버리스, 컨테이너).
데이터 레이어는 분산된 데이터를 수집·인덱싱하고, 벡터·그래프 저장소에 저장하며, 에이전트를 위한 장기와 단기 메모리를 제공합니다.
그리고 이 모든 레이어를 관통하는 세 기둥인 운영(Operations), 보안(Security), 관측성(Observability)이 항상 함께 작동합니다.

이 요소들이 모여 비로소 하나의 파운데이션을 이룹니다. 그리고 이를 구축하는 데 AWS의 두 가지 서비스를 활용합니다.

Amazon Bedrock: 생성형 AI 애플리케이션을 위한 완전 관리형 서비스입니다. Amazon, Anthropic 등 다양한 제공업체의 최신 모델을 API 호출만으로 사용할 수 있고, 비용, 지연 시간, 정확도의 균형을 맞추는 기능과 함께 모델 커스터마이징, RAG, 가드레일을 손쉽게 적용할 수 있습니다.
Amazon Bedrock AgentCore: 에이전틱 AI 애플리케이션을 위한 완전 관리형 서비스입니다. Strands Agents, CrewAI, LangGraph, LlamaIndex 등 다양한 오픈소스 프레임워크로 만든 에이전트를 컨테이너화해 런타임에 배포할 수 있습니다. 또한 파운데이션의 운영 레이어를 구성하는 폭넓은 기능을 제공합니다. 세션별 격리 실행을 위한 Runtime, 단기와 장기 기억을 분리하는 Memory, 도구를 묶어 관리하는 Gateway, 도구 호출을 제어하는 Policy, 자격 증명을 다루는 Identity, 트레이스, 로그, 메트릭을 자동 수집하는 Observability, 코드 실행, 브라우저 조작을 위한 샌드박스(Code Interpreter, Browser), 프로덕션 트래픽을 점검하는 Evaluations, 그 결과를 프롬프트 추천, A/B 테스트로 잇는 Optimization, 그리고 조직 전체의 에이전트, 도구, MCP 서버, 스킬을 하나의 거버넌스된 카탈로그로 모으는 Agent Registry까지, 프로덕션에 꼭 필요한 공통 레이어를 관리형으로 제공합니다.

덕분에 개발자는 에이전트 설계 그 자체에 집중할 수 있고, 공통 레이어는 AgentCore 위에서 손쉽게 구축할 수 있습니다. 아래에서 소개할 데모 역시 Bedrock과 AgentCore 위에서 동작합니다.

게이트웨이로 접근을 통합하라

파운데이션의 주요 요소 중에 게이트웨이에 대해 먼저 살펴보겠습니다. 전체 파운데이션 아키텍처에서 게이트웨이는 클라이언트와 런타임 사이에 위치해, 안전하고 통합된 접근을 제공하는 핵심 레이어입니다. 핵심 게이트웨이 패턴에는 세 가지가 있습니다.

이제 이 게이트웨이 아키텍처가 실제로 어떻게 동작하는지, 데모를 통해 확인해 보겠습니다. 먼저 각 게이트웨이의 개념을 살펴본 뒤, 실제 구현 데모로 넘어갑니다.

게이트웨이	무엇을 모으나	핵심 기능
LLM Gateway	흩어진 모델	통합 API, 접근/인증, 속도 제한, 가드레일, 비용 귀속
Tool Gateway	흩어진 도구	도구 검색, 표준화된 접근, 중앙 레지스트리, MCP 지원
Agent Gateway	흩어진 에이전트	에이전트 검색, 에이전트 간 안전한 연결, A2A 지원

LLM Gateway: 모델 접근을 한곳에서

우리가 사용하는 모델은 Amazon Bedrock에 있을 수도, 직접 호스팅 중일 수도, AWS 외부 제공자의 것일 수도 있습니다. LLM Gateway는 이렇게 흩어진 모델을 하나의 통합 API로 묶어, 개발자가 일관된 방식으로 그리고 허용된 만큼만 접근하도록 오케스트레이션합니다.

바로 이 위치에서 토큰 비용 제어와 권한 관리가 가능해집니다. 팀별 API 키로 사용량과 활동을 추적하고, 엔터프라이즈 전체 가드레일을 적용하기에도 더없이 적합한 지점입니다. 특히 최근 Claude Code, Codex, Kiro 같은 에이전틱 도구가 기업 내부에 빠르게 확산되면서 개인별, 팀별 사용량 추적과 비용 제어 요구가 커지고 있는데, LLM Gateway를 두면 이런 요구를 한 레이어에서 일관되게 해결할 수 있습니다.

Tool Gateway & Agent Gateway: 흩어진 자원을 한 점으로

에이전트가 다루는 도구가 늘어나면 곧 문제가 생깁니다. 에이전트마다 어떤 도구가 어디에 있고 어떻게 인증하는지를 개별적으로 관리하다 보면, 도구가 10개, 20개로 늘어나는 순간 그 구조는 더 이상 유지하기 어려워집니다. 도구 하나를 추가하거나 위치를 옮길 때마다 모든 에이전트 코드를 손봐야 합니다.

Tool Gateway는 흩어진 도구들을 표준화된 단일 접근점 뒤로 모아 이 문제를 풀어 줍니다. 에이전트는 개별 도구가 어디에 어떻게 구현되어 있는지 신경 쓸 필요 없이, 게이트웨이라는 하나의 창구만 바라보면 됩니다. 도구가 바뀌어도 에이전트 코드는 그대로입니다.

에이전트 수가 늘어나면 같은 문제가 이번엔 에이전트들 사이에서 반복되고, 이를 Agent Gateway가 해결합니다. 요점은 둘 다 동일합니다. 도구든 에이전트든, 흩어진 자원을 표준화된 하나의 지점으로 모으고, 그 지점에서 일관된 통제와 거버넌스를 적용한다는 것입니다.

이 Tool Gateway 기능을 Amazon Bedrock AgentCore Gateway가 관리형으로 제공합니다. Lambda 함수, OpenAPI 스키마를 따르는 RESTful 서비스, 또는 기존 MCP 서버를 타겟으로 연결하면, 게이트웨이가 이들을 하나의 MCP 엔드포인트로 묶어 노출합니다. 에이전트는 MCP 클라이언트로 접속해 시맨틱 검색으로 도구를 조회·호출하며, 에이전트가 AgentCore 런타임 안에서 실행되든 밖에서 실행되든 똑같은 방식으로 사용할 수 있습니다.

데모: e-커머스 데이터 분석 에이전트로 보는 게이트웨이 아키텍처

Figure 3. 데모 아키텍처 구성도

실제 데모를 보겠습니다. e-커머스 데이터 분석 에이전트를 프로덕션 레벨로 운영하기 위해, 앞서 소개한 세 가지 게이트웨이 패턴을 그대로 구현했습니다.

LLM Gateway: 모든 Bedrock 모델 호출을 가로채고, 환경 변수로 모델 라우팅(quality/cost/balanced)하며, PII 마스킹과 OTEL 스팬 기록을 수행합니다.
Tool Gateway: AgentCore Gateway를 활용해 어떤 도구들이 에이전트에 연결되고 활용되는지 확인할 수 있습니다.
Agent Gateway: Sub-Agent를 하나의 MCP 도구로 취급해, 역시 AgentCore Gateway 위에서 관리하도록 구현했습니다.

사용자가 “데이터를 분석해줘” 같은 질문을 던지면 Strands Agents로 구현되어 AgentCore Runtime 위에서 실행되는 메인 오케스트레이터 에이전트가 요청을 받습니다. 이 에이전트가 질문의 성격을 판단해, 게이트웨이를 통해 적절한 도구나 에이전트를 호출합니다.

멀티 에이전트 토폴로지(A2A)는 다음과 같이 구성했습니다.

런타임	역할
ecommerce_analytics (메인)	매출, 애드혹 SQL은 직접 처리, 도메인 질문은 위임
reviews_specialist	리뷰 점수, 감성, 카테고리 만족도
logistics_specialist	배송 정시율, 셀러 성과

메인 에이전트는 도메인 특화 질문이 들어오면 전문 에이전트(reviews_specialist, logistics_specialist)에 위임하고, 결과를 종합해 응답합니다.

게이트웨이에는 6개의 도구가 등록되어 있습니다. 5개는 Aurora에 저장된 주문, 리뷰, 배송 데이터를 조회하는 데이터 도구이고, 나머지 하나는 작업을 다른 에이전트에게 넘기는 도구입니다.

0. 전체 데모 영상

1. 채팅 화면

Figure 4. 채팅 화면

사용자가 “2017년 매출 상위 5개 카테고리”를 물으면 에이전트가 Tool Gateway를 통해 데이터를 조회하고 응답합니다. LLM Gateway 화면에서는 등록된 모델과 호출 내역을 확인할 수 있습니다.

2. LLM Gateway & Tool Gateway

Figure 5. LLM Gateway & Tool Gateway 모니터링 대시보드

LLM Gateway 대시보드에서는 모델별 요청량, 토큰 사용량, 비용이 실시간으로 집계됩니다. Tool Gateway에서는 에이전트가 동작하면서 어떤 도구가 선택, 호출됐는지 실시간으로 확인할 수 있습니다.

3. Agent Gateway (A2A)

Figure 6. Agent Gateway를 통한 멀티 에이전트 협업

도메인 특화 질문이 들어오면 메인 에이전트가 Agent Gateway (A2A)를 통해 전문 에이전트에 위임하고, 결과를 통합해 응답합니다. Agent Gateway 화면에서는 지금까지의 질문에 답하기 위해 오케스트레이터에서 전문 에이전트로 핸드오프가 일어난 것을 확인할 수 있습니다.

4. Agent Registry

Figure 7. Agent Registry 화면

Agent Registry에서는 AWS Agent Registry 기능을 바탕으로 등록된 에이전트, 도구, 스킬을 승인 여부와 함께 확인하고, 시맨틱 검색으로 관련 도구나 에이전트를 검색·연결할 수 있습니다. 새로운 도구의 사용을 승인하는(publish/approve/deprecate) 거버넌스 워크플로우도 함께 제공합니다.

지금까지 에이전틱 AI를 프로덕션으로 올리기 위한 파운데이션의 핵심 요소인 게이트웨이 아키텍처를 살펴보고, 데모를 통해 실제 동작을 확인해 보았습니다. 다음 편(Part 2)에서는 에이전트의 품질과 안전성을 지속적으로 보장하기 위한 관측성(Observability)과 평가(Evaluation), 그리고 이 모든 것을 하나의 운영 프로세스로 통합하는 AgentOps 라이프사이클을 살펴보겠습니다.

AWS 기술 블로그