Amazon Bedrock AgentCore를 활용한 풀스택 AI 에이전트 구축

이 글은 Amazon Bedrock AgentCore Runtime에 배포된 개인화된 AWS 어시스턴트인 AWS Briefing Agent를 구축하며 얻은 아키텍처, 구현 및 교훈을 기록하는 시리즈 포스트의 첫 번째 글입니다.

Part 1: Bedrock AgentCore에서 풀스택 AI 에이전트 구축
Part 2: 데이터 수집 (Data Ingestion): RSS 피드, 지식 베이스 (Knowledge Base), S3 벡터 (S3 Vectors) 및 메타데이터 필터링 (Metadata Filtering)
Part 3: Strands Agents + AgentCore Runtime - 완벽한 조합
Part 4: 에이전트에 메모리 (Memory) 추가하기
Part 5: API Gateway 실험하기
Part 6: 관찰 가능성 (Observability) 및 평가 (Evaluations)
Part 7: 제3자 통합 (Third Party Integrations) - ID (Identity), 게이트웨이 (Gateway) 및 Slack 알림 (Slack Notifications)

왜 에이전트를 구축해야 할까요? 지난 몇 년 동안 생성형 AI (Generative AI)에서 에이전트형 AI (Agentic AI)로의 급격한 변화가 있었습니다. 처음에는 프롬프트 (Prompt)를 입력받아 응답을 반환하는 어시스턴트로 시작되었습니다. 당시에는 인상적이었지만, 여전히 주로 반응적이었으며 인간의 입력에 의존했습니다. 그 후, 작업을 더 작은 단계로 나누고 독립적으로 실행할 수 있는 초기 AI 에이전트의 등장을 목격했습니다. 지난 1년 동안 이는 인간의 감독을 최소화하거나 전혀 필요로 하지 않고 복잡한 작업을 완료할 수 있는 완전 자율형 멀티 에이전트 시스템 (Multi-agent systems)으로 진화했습니다.

이러한 변화는 빠르게 가속화되고 있습니다. Gartner는 2028년까지 모든 기업용 소프트웨어 앱의 3분의 1 이상에 에이전트형 AI (Agentic AI)가 포함될 것이며, 일상적인 업무 결정의 최소 15%가 AI 에이전트에 의해 자율적으로 내려질 것이라고 예측합니다. 기업들에게 질문은 이제 에이전트가 기업 시스템의 일부가 될 것인가가 아니라, 어떻게 하면 에이전트를 안전하고 신뢰할 수 있게 구축하고 대규모로 운영할 것인가입니다.

이 블로그 시리즈의 목표는 Amazon Bedrock AgentCore의 다양한 기능을 사용하여 에이전트형 애플리케이션을 구축함으로써, AgentCore의 역량을 더 잘 이해하고 이들이 어떻게 함께 사용될 수 있는지 보여주는 것입니다.

왜 AgentCore Runtime인가요? Amazon Bedrock AgentCore는 에이전트를 호스팅하는 작업에 특화되어 설계된 AWS 서비스입니다.

제가 계속해서 듣고 있는 흔한 말 중 하나는, Bedrock AgentCore가 이벤트 기반 애플리케이션 (event driven applications)에 대한 AWS Lambda와 같은 관계를 에이전트 기반 애플리케이션 (agentic applications)에서 가진다는 것입니다. 그 중심에는 에이전트 코드를 실행하기 위한 보안 런타임 (secure runtime)을 제공하는 AgentCore Runtime이 있습니다. AgentCore Runtime은 세션 기반 격리 (session-based isolation)를 제공하며, 여기서 모든 세션에는 격리된 CPU, 메모리 및 파일 시스템 리소스를 가진 전용 Firecracker 마이크로VM (microVM)이 할당됩니다 (이는 AWS Lambda 및 AWS Fargate의 기반이 되는 것과 동일한 경량 가상화 기술입니다). 세션이 종료되면 LLM의 상태 정보는 장기 메모리 (long-term memory)로 복사되고 전체 마이크로VM은 파괴됩니다. 세션 간에 공유되는 상태가 없으므로 세션 간 데이터 유출을 방지할 수 있습니다. AgentCore Runtime은 프레임워크에 구애받지 않으며 (framework-agnostic), Strands Agents, LangGraph, CrewAI와 같은 모든 인기 있는 프레임워크를 지원합니다. 또한 Amazon Bedrock, Anthropic Claude, Google Gemini, OpenAI에서 제공하는 모델이나 심지어 온프레미스 (on-premises)에 호스팅된 모델 등 모든 LLM과 함께 작동합니다. 최대 8시간까지의 긴 세션을 지원하므로 복잡한 다단계 작업이나 시간이 소요되는 백그라운드 프로세스를 처리할 수 있습니다. 사전 할당된 리소스에 대해 비용을 청구하는 전통적인 컴퓨팅 서비스와 달리, AgentCore Runtime은 실제 활성 CPU 및 메모리 사용량에 대해서만 비용을 지불하는 사용량 기반 요금제 (consumption-based pricing)를 사용합니다. 이를 통해 I/O 대기 시간 및 유휴 시간은 무료이며, 초 단위로 계산된 실제 리소스 소비량에 대해서만 비용이 청구됩니다. 런타임은 용량 계획 (capacity planning) 없이도 수요에 따라 0에서 수천 개의 동시 세션까지 자동으로 확장되며, 중단 시부터 우아하게 복구할 수 있는 체크포인팅 (checkpointing)과 같은 신뢰성 기능을 포함합니다. AWS Briefing Agent 아키텍처: AWS Briefing Agent의 상위 수준 아키텍처 개요는 아래와 같습니다: AWS Briefing Agent 클라이언트는 AWS Amplify Hosting에 호스팅된 Next.js 정적 사이트입니다. 이는 amazon-cognito-identity-js SDK를 사용하여 Amazon Cognito와 직접 통합되며, 전체 로그인, 회원가입 및 이메일 인증 흐름을 구현합니다.

AWS Briefing Agent 자체는 Strands Agents SDK로 구축되어 AgentCore Runtime에 Docker 컨테이너로 배포되는 Python 애플리케이션입니다. @aws/agentcore CLI는 전체 배포 수명 주기(deployment lifecycle)를 관리합니다. agentcore deploy를 실행하면, CLI는 AWS CodeBuild를 트리거하여 Docker 이미지(ARM64)를 빌드하고, 이를 Amazon ECR에 푸시한 다음, AgentCore Runtime에 배포합니다. AgentCore Memory는 두 가지 내장 메모리 전략을 사용하여 세션 전반에 걸쳐 지속적인 사용자 지식을 제공합니다. SEMANTIC 메모리 전략은 대화에서 사실적 정보와 지식을 추출합니다 (예: 사용자가 Lambda 및 EKS를 사용한다는 사실). USER_PREFERENCE 메모리 전략은 대화에서 사용자 선호도를 식별하고 추출합니다 (예: 사용자가 기술적인 심층 분석을 선호한다는 사실). 에이전트는 각 호출(invocation)이 시작될 때 관련 메모리 기록을 검색하여 이를 컨텍스트(context)로 주입하며, 이를 통해 새로운 세션의 첫 메시지부터 개인화된 브리핑을 가능하게 합니다. AgentCore Observability는 모든 Bedrock API 호출, 도구 호출(tool invocations) 및 메모리 작업을 계측(instrument)하는 데 사용됩니다. 이는 런타임 설정에서 enableOtel: true를 설정하고 opentelemetry-instrument 래퍼 명령어를 사용하는 것만으로 완전히 수행됩니다. Span은 CloudWatch Transaction Search에 나타나며, CloudWatch GenAI Observability 대시보드에는 세션과 트레이스(traces)가 채워져 개별 호출을 상세히 조사(drill into)할 수 있는 기능을 제공합니다. AgentCore Evaluations는 유용성(Helpfulness), 목표 성공률(Goal Success Rate), 정확성(Correctness)에 대한 내장 평가기(evaluators)를 사용하여 에이전트 응답에 대한 온라인 품질 평가를 수행하도록 구성됩니다. 이러한 지표는 프런트엔드에 표시되어 각 사용자별로 에이전트가 얼마나 잘 수행하고 있는지에 대한 지표를 제공합니다. Bedrock Knowledge Base는 모든 공지사항, 블로그 게시물 및 보안 게시판을 저장하는 Amazon S3 Vectors를 기반으로 생성됩니다. 6시간마다 실행되는 인제스션(ingestion) Lambda는 각 항목을 metadata.json 파일과 함께 .txt 파일로 S3 버킷에 기록한 후 Knowledge Base 동기화를 트리거합니다.

에이전트는 날짜 범위 및 서비스 이름에 대한 메타데이터 필터가 포함된 Strands 검색 도구(retrieve tool)를 통해 지식 기반(KB)에 질의하며, 이를 통해 "이번 주 Bedrock의 새로운 소식은 무엇인가요?"와 같은 질문이 가능해집니다. AgentCore Gateway는 관리형 MCP (Model Context Protocol) 엔드포인트를 노출하며, 에이전트는 런타임 시 도구 탐색(tool discovery)을 위해 이 엔드포인트에 연결합니다. Slack 통합은 Slack의 chat.postMessage API를 가리키는 OpenAPI 명세로 정의되며, Gateway 타겟으로 등록됩니다. 에이전트는 MCP 프로토콜을 통해 사용 가능한 도구를 동적으로 탐색합니다. Gateway는 이 Slack 통합에 대한 인증 및 자격 증명 주입(credential injection)을 처리하며, 저장된 봇 토큰을 외부 Slack API 호출 시 Bearer 헤더로 첨부합니다. AgentCore Identity는 Slack 봇 토큰을 토큰 볼트(token vault) 내의 API 키 자격 증명로 저장합니다(Secrets Manager를 통해 저장 시 암호화됨). 에이전트가 Slack으로 브리핑을 보내는 도구를 호출하면, AgentCore Identity가 봇 토큰을 검색하여 외부 요청에 자동으로 주입합니다. 에이전트 코드는 토큰을 직접 보거나 처리하지 않습니다. AgentCore Registry는 에이전트, MCP 서버, 도구, 기술(skills) 및 사용자 정의 리소스를 위한 관리형 카탈로그입니다. 팀은 리소스를 게시하고, 승인 워크플로를 통해 액세스를 제어하며, 인간과 AI 에이전트 모두가 의미론적(semantic) 및 키워드 검색을 사용하여 도구를 탐색할 수 있도록 할 수 있습니다. Slack 통합이 작동하면, 브리핑 에이전트와 등록된 Slack 도구는 AgentCore Registry에 등록됩니다. 이를 통해 조직 내의 다른 에이전트들이 해당 도구를 발견할 수 있게 됩니다. AWS 브리핑 에이전트 작동 사례: 우리는 새로운 사용자를 생성하고 AWS 브리핑 에이전트 프런트엔드의 홈 화면에 로그인합니다. 에이전트를 처음 사용할 때, 관심 분야와 선호하는 브리핑 스타일에 대한 정보를 제공하라는 요청을 받습니다. 이 정보는 메모리에 추가되어 에이전트가 응답을 개인화할 수 있도록 합니다. 우리는 가장 관심 있는 서비스의 세부 정보를 에이전트에게 제공할 수 있습니다.

이 시점에서 에이전트는 지식 베이스 (Knowledge Base)에서 검색한 상위 공지 사항들을 가져와 브리핑 요약 (briefing summary) 형태로 표시합니다. 또한 우리는 Gateway를 통해 Slack과 연동했습니다. 이는 브리핑 에이전트 (Briefing Agent)에게 세부 정보를 우리의 Slack 채널에 게시하도록 요청할 수 있음을 의미합니다. 즉, 우리가 Slack 채널에 접속하면 브리핑 내용과 함께, 원본 블로그 게시물이나 공지 기사로 바로 이동할 수 있는 모든 링크가 포함된 새로운 메시지를 확인할 수 있습니다.