[reinvent 2025] GenAI 배포를 위한 DevEx 개선: Dynatrace + Amazon Bedrock

들어가며

GenAI 기술이 급속도로 발전하면서, 많은 기업들이 AI 에이전트를 활용한 혁신적인 애플리케이션을 개발하고 있습니다. 그러나 Gartner는 2027년까지 약 40% 이상의 Agentic AI 프로젝트가 취소될 것으로 예측하고 있습니다. 그 이유는 바로 POC(Proof of Concept) 단계에서 프로덕션으로 전환하는 과정에서 발생하는 복잡성과 운영 과제 때문입니다.

이번 세션에서는 AWS의 Principal Solution Architect인 Simone Pomata와 Dynatrace의 Developer Experience 리더인 Sean ODell이 이러한 문제를 해결하기 위한 실질적인 접근법을 제시했습니다. 특히 Dynatrace와 AWS의 강력한 파트너십, Amazon Bedrock Agent Core의 핵심 기능, 그리고 AI Observability를 통한 에이전트 모니터링이 이번 세션의 핵심 주제였습니다

Dynatrace and AWS Better Together

세션의 시작은 Dynatrace와 AWS의 전략적 파트너십에 대한 소개로 이루어졌습니다. AWS re:Invent 2025에서 Dynatrace는 3일 연속 메인 스테이지 키노트에 소개되었으며, 이는 두 기업 간의 깊은 협력 관계를 보여줍니다. Dynatrace는 AWS의 매우 가치 있는 파트너로 인정받고 있으며, 특히 AI 워크로드의 Observability 영역에서 핵심적인 역할을 수행하고 있습니다.

AWS와 Dynatrace의 협력은 단순한 기술 통합을 넘어, 개발자 경험을 근본적으로 개선하는 데 초점을 맞추고 있습니다. Sean ODell은 Observability 분야에서 8~9년간의 경험을 바탕으로, 새로운 기술이 등장할 때마다 직면하는 가장 큰 과제는 “어떻게 정보를 추출할 것인가”라고 설명했습니다.

AWS는 Bedrock Agent Core를 설계하면서 OpenTelemetry를 기반으로 로그, 트레이스, 메트릭을 표준화된 방식으로 노출하도록 구축했으며, 이를 통해 사용자가 CloudWatch뿐만 아니라 Dynatrace와 같은 서드파티 플랫폼에서도 데이터를 활용할 수 있도록 선택권을 제공합니다.

세션에서 강조된 핵심은 Dynatrace가 AWS의 100개 이상의 서비스 통합을 제공하며, 클라우드 네이티브 환경에서 완전한 Observability를 실현한다는 점입니다. 특히 AI 파일럿 프로젝트의 95% 실패율을 줄이기 위해서는 Modernization과 Advanced Automation Observability가 필수적이며, Dynatrace는 이러한 요구사항을 충족시키는 플랫폼으로 자리잡고 있습니다.

Amazon Bedrock Agent Core

Amazon Bedrock Agent Core는 Agentic AI 워크로드를 프로덕션 환경에서 안정적으로 운영할 수 있도록 설계된 완전 관리형 서비스입니다.

에이전트 자체를 구성하는 것은 큰 문제가 아닙니다. 정말 어려운 점은 이러한 에이전트를 프로덕션 환경으로 확장하는 것입니다. 에이전트가 부서 내에서 많은 도구와 잠재적으로 다른 에이전트들에 접근해야 하는 시나리오를 생각해보십시오. 이는 조직 내에서, 그리고 조직 외부로까지 확장될 수 있습니다. 인프라와 애플리케이션 계층을 포함한 모든 레이어를 관리해야 한다면 대규모로 수행하기 매우 복잡할 수 있습니다.

실제로 이것이 Gartner가 2027년까지 40% 이상의 Agentic AI 프로젝트가 취소될 것이라고 믿는 이유 중 하나입니다. 많은 흥분과 잠재력이 있는 POC에서 비즈니스 가치를 얻는 프로덕션으로 이동하는 것이 상당히 어렵기 때문입니다.

전용 인프라와의 런타임, 메모리 기능, Identity, 도구 검색 및 상호작용, 고급 기능, Observability 등 이 모든 것을 처음부터 새로 만드는 것은 상당히 어려울 수 있습니다. 그래서 Amazon Bedrock Agent Core를 출시했습니다

Bedrock Agent Core는 이러한 과제를 해결하는 AWS 서비스 세트로, 세 가지 범주로 구성됩니다.

배포(Deploying)

Runtime과 Identity 두 가지 서비스를 제공합니다. Runtime은 어떤 프레임워크와 모델이든 코드를 가져오기만 하면 서버리스 런타임에서 자동으로 확장하여 실행해줍니다. Identity는 에이전트가 다양한 서비스와 상호작용할 때 필요한 인증을 처리하며, SigV4, OAuth, API 키 등의 federation을 제공합니다.

향상(Enhancing)

Agent Core Gateway는 에이전트가 사용할 수 있는 모든 도구(Targets)를 볼 수 있는 중앙 MCP 서버입니다. API, 데이터베이스, Google Drive, Salesforce, Slack 같은 외부 도구에 접근할 수 있습니다.

Agent Core Memory는 단기 메모리와 장기 메모리로 구성됩니다. 이커머스 시나리오를 예로 들면, 단기 메모리는 현재 세션의 장바구니 정보를 기억하고, 장기 메모리는 과거 상호작용을 기억하여 개인화된 쇼핑 경험을 제공합니다.

Agent Core Browser는 완전 관리형 브라우저로 수십~수백 개의 병렬 세션을 격리된 환경에서 처리하며, Agent Core Code Interpreter는 LLM이 생성한 Python 코드를 실행하여 수학적 계산 같은 결정론적 작업을 정확하게 수행합니다.

모니터링(Monitoring)

Agent Core Observability는 에이전트의 상태와 성능을 모니터링하는 기능입니다. 기본 대시보드를 제공하며, 더 중요한 것은 Dynatrace가 고급 Observability를 수행할 수 있도록 메트릭, 로그, 스팬, 트레이스, 세션을 노출한다는 점입니다.

세션의 후반부는 Dynatrace의 AI Observability 솔루션에 집중되었습니다. Bedrock Agent Core가 기본적인 모니터링 기능을 제공하지만, Dynatrace는 이를 넘어서 End-to-End Observability를 제공합니다.

이 슬라이드는 Bedrock Agent Core의 Observability 아키텍처를 명확하게 보여줍니다. 상단에는 세 가지 에이전트 유형(Reasoning (Advanced Planning), ML/Computer Vision, Production/Workflow)이 있으며, 이들은 모두 중앙의 Amazon Bedrock Agent Core Observability로 데이터를 전송합니다.

이러한 구조는 사용자에게 Observability 도구 선택의 유연성을 제공하며, OpenTelemetry 표준을 통해 멀티 플랫폼 통합을 가능하게 합니다.

이 슬라이드는 Bedrock Agent Core의 실제 Observability 대시보드를 보여줍니다. 상단의 그래프는 시간에 따른 에이전트 실행 추이를 시각화하며, 각 바(bar)는 개별 에이전트 호출을 나타냅니다. 오른쪽에는 상세한 추론 단계(reasoning steps)와 실행 로그가 표시되어 있어, 개발자가 에이전트가 어떤 의사결정 경로를 거쳤는지 추적할 수 있습니다.

하단에는 에이전트 실행의 메타데이터와 속성 정보가 텍스트 형태로 제공되며, 이를 통해 각 호출의 파라미터, 응답 시간, 사용된 도구 등을 상세히 확인할 수 있습니다. 이러한 수준의 가시성은 디버깅과 성능 최적화에 필수적입니다.

이번 세션을 통해 GenAI 에이전트를 프로덕션 환경으로 확장할 때 직면하는 기술적 과제와 해결 방안을 명확히 이해할 수 있었습니다. Gartner가 예측한 40% 이상의 프로젝트 취소율은 POC에서 프로덕션으로의 전환이 얼마나 어려운지를 보여줍니다.

핵심은 세 가지 영역입니다. 첫째, 서버리스 런타임과 Identity 관리를 통한 안정적인 배포 환경 구축입니다. 둘째, Gateway를 통한 도구 통합, Memory를 통한 컨텍스트 관리, Browser와 Code Interpreter를 통한 고급 기능 제공입니다. 셋째, OpenTelemetry 기반의 표준화된 Observability 입니다.

앞으로 GenAI 에이전트 프로젝트를 진행할 때 완전 관리형 플랫폼과 표준화된 Observability를 초기 단계부터 고려한다면, POC to Production의 간극을 효과적으로 극복할 수 있을 것입니다.