Migrating multi-model AI agents to Amazon Bedrock AgentCore runtime

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon ECS와 AWS Fargate에서 운영하던 의료 AI 에이전트를 Amazon Bedrock AgentCore runtime으로 이전해, 기존 에이전트 로직·3개 모델 백엔드·벡터 검색을 유지하면서 인프라 관리 부담을 줄이는 구현을 소개한다.

📌 핵심 요약

• AgentCore runtime은 컨테이너 수명주기, 확장, ID 관리, 관측 가능성을 관리형으로 제공하며, 기존 Hugging Face smolagents 기반 의료 에이전트를 데코레이터로 감싸 배포한다.
• 3개 모델 백엔드는 Amazon SageMaker AI의 BioM-ELECTRA-Large-SQuAD2, Amazon Bedrock의 Llama 3.1 70B Instruct by Meta, BioM-ELECTRA-Large-SQuAD2를 제공하는 컨테이너형 모델 서버다. Amazon OpenSearch Service는 벡터 기반 의료 지식 검색을 담당한다.
• AgentCore runtime은 특정 모델이나 프레임워크를 요구하지 않는다. 이전 글의 Claude 3.5 Sonnet V2 by Anthropic 대신 이번 구현에서 Llama 3.1 70B Instruct by Meta를 선택했으며, CLI의 --framework Strands는 템플릿 지정이고 실제 코드는 Hugging Face smolagents를 사용한다.
• 배포에는 AWS 권한과 리전별 서비스·모델 접근성, AWS CLI 2.0 이상, Node.js 20 이상, Python 3.10 이상, AWS CDK, AgentCore CLI, Docker 등이 필요하다. 컨테이너 이미지는 2 GB 제한에 맞추며, agentcore deploy -y의 배포 시간은 약 10~15분이고 CLI 또는 boto3로 호출을 시험한다.
• Amazon ECS와 AWS Fargate 방식은 컨테이너·네트워킹·확장 동작을 직접 제어하고 설정하는 반면, AgentCore runtime은 운영 설정 부담을 줄인다. 이 구현은 시연용 샘플이며, 원문은 의료 등 민감한 질의를 처리하는 운영 배포에서 Amazon Bedrock Guardrails를 콘텐츠 필터링과 근거 검증의 표준 통제로 사용하도록 설명한다.

🧩 주요 포인트

1. 기존 로직에 데코레이터를 적용하는 BYO 방식 → 에이전트 기능을 보존하면서 컨테이너 운영 책임을 AgentCore runtime으로 옮기는 것이 마이그레이션의 핵심이다.
2. 전문 생의학 모델·범용 추론 모델·자체 호스팅 백엔드와 Amazon OpenSearch Service의 결합 → 질의 유형에 맞는 모델 선택과 지식 검색을 유지하며, Hugging Face Messages API 호환 형식으로 요청·응답을 일관되게 처리한다.
3. Amazon ECS와 AWS Fargate의 직접 제어와 AgentCore runtime의 관리형 운영 사이의 선택 → 운영 부담 감소뿐 아니라 필요한 설정 제어 수준, 리전별 접근성, 2 GB 이미지 제한, Amazon Bedrock Guardrails 적용을 함께 검토해야 한다.

🧠 상세 정리

1. 이전의 배경과 유지하려는 기능

여러 모델을 사용하는 에이전트형 AI 애플리케이션은 컨테이너 오케스트레이션, 확장 정책, ID 관리, 관측 가능성을 함께 운영해야 하므로 인프라 복잡성이 커진다. 원문은 이러한 관리 업무 때문에 팀이 에이전트 로직 개발보다 인프라에 더 많은 시간을 쓰는 상황을 문제로 제시한다. Amazon ECS와 AWS Fargate를 사용하는 기존 방식은 배포 구성을 완전히 제어할 수 있지만, 워크로드가 발전하고 확장되면 내장 운영 기능을 제공하는 관리형 런타임을 선택할 수 있다. 이번 구현은 이전 글에서 소개한 의료 AI 에이전트를 Amazon Bedrock AgentCore runtime으로 옮기는 사례다. 목표는 기존 에이전트 로직과 3개 모델 백엔드의 오케스트레이션, 벡터 기반 지식 검색 기능을 보존하면서 인프라 관리 부담을 줄이는 것이다.

2. 의료 질의 처리와 전체 아키텍처

클라이언트 웹 인터페이스는 Amazon Bedrock AgentCore runtime에 연결되며, 런타임은 Hugging Face smolagents와 AgentCore 데코레이터를 사용하는 의료 에이전트 컨테이너를 호스팅한다. 이 에이전트는 3개 모델 백엔드를 조율하고, 질의에 적합한 백엔드를 지정해 처리할 수 있다. Amazon SageMaker AI의 BioM-ELECTRA-Large-SQuAD2는 전문 생의학 질의를 맡고, Amazon Bedrock의 Llama 3.1 70B Instruct by Meta는 더 폭넓고 복잡한 의료 추론에 사용된다. 세 번째 백엔드는 BioM-ELECTRA-Large-SQuAD2를 제공하는 컨테이너형 모델 서버다. Amazon OpenSearch Service는 의료 지식을 색인하고 벡터 유사도에 따른 문맥 검색을 지원하며, AWS Identity and Access Management는 보안과 접근 제어를 담당한다.

3. 백엔드 선택과 모델·프레임워크 독립성

세 백엔드는 서로 다른 배포 요구에 대응한다. Amazon SageMaker AI는 Hugging Face Hub 모델을 사용하는 관리형 엔드포인트와 자동 확장을 제공하고, Amazon Bedrock은 AWS API를 통한 기반 모델의 서버리스 접근과 복잡한 추론을 지원한다. 컨테이너형 모델 서버는 자체 호스팅과 도구 통합을 위한 선택지이며 Amazon ECS, Amazon EKS 또는 다른 컨테이너 환경에 배포할 수 있다. 세 백엔드는 Hugging Face Messages API 호환성을 구현해 선택한 모델 서비스와 관계없이 일관된 요청·응답 형식을 제공한다. 이전 글이 Claude 3.5 Sonnet V2 by Anthropic을 사용한 것과 달리 이번 글은 Llama 3.1 70B Instruct by Meta를 사용하며, 이를 필수 모델이 아닌 구현상의 선택으로 설명한다. Hugging Face smolagents 역시 참조 구현에 사용된 프레임워크로, BYO 방식은 특정 프레임워크에 맞춰 기존 에이전트 코드를 다시 작성할 필요가 없다는 점을 보여준다.

4. 시연용 구현의 범위와 배포 전제

원문은 이 솔루션을 시연 목적의 샘플 구현으로 명시하고, 의료 등 민감한 질의를 처리하는 운영 배포에서는 Amazon Bedrock Guardrails를 콘텐츠 필터링과 근거 검증의 표준 통제로 사용한다고 설명한다. 배포하려면 AgentCore runtime에 접근할 수 있는 AWS 계정과 IAM 역할 및 Amazon OpenSearch Service 도메인을 생성할 권한이 필요하다. 사용하는 AWS 리전에서 Amazon Bedrock 모델, Amazon SageMaker AI, Amazon OpenSearch Service에 접근할 수 있어야 하며 관련 리소스를 생성·관리할 IAM 권한도 갖춰야 한다. 도구 요건은 AWS CLI 2.0 이상, Node.js 20 이상, AWS CDK, AgentCore CLI, Python 3.10 이상, 설치 후 실행 중인 Docker, bedrock-agentcore Python SDK다. Node.js는 배포 CLI에 필요하고 Docker는 코드 실행 격리에 필요하며, 구현은 Python 3.10 이상과 smolagents, transformers 4.55.0 이상, boto3를 사용한다.

5. 데코레이터로 기존 에이전트 연결

AgentCore runtime 통합은 기존 로직을 데코레이터로 감싸는 구조이며, BedrockAgentCoreApp으로 애플리케이션을 초기화한다. @app.entrypoint는 요청이 도착했을 때 런타임이 호출할 함수를 지정하고, app.run()은 런타임 서버를 시작한다. 예제 진입점은 payload에서 prompt와 model_type을 읽으며, 각각 빈 문자열과 sagemaker를 기본값으로 사용한다. 이어 기존 vector_store로 TripleHealthcareAgent를 생성하고 agent.run에 사용자 입력과 모델 유형을 전달한 뒤 응답을 문자열로 반환한다. 원문은 데코레이터와 반환문 사이의 에이전트 로직이 독립 실행 버전과 동일하게 유지된다고 설명한다. 이 통합을 통해 애플리케이션은 기존 질의 처리 로직을 유지하고, 컨테이너 수명주기·확장·ID 관리·관측 가능성은 AgentCore runtime이 자동으로 처리한다.

6. 프로젝트 생성과 컨테이너 준비

프로젝트 설정은 npm으로 @aws/agentcore를 전역 설치한 뒤, AgentCore CLI로 healthcareagent 프로젝트를 생성하는 순서로 진행된다. 생성 예제는 에이전트 없이 시작하고 Container 빌드, Python, HTTP 프로토콜, Bedrock 모델 제공자, 메모리 없음으로 구성한 다음 기존 코드를 BYO 에이전트로 추가한다. 추가 명령은 ./agent-code의 healthcare_agentcore.py를 진입점으로 지정하고 PUBLIC 네트워크 모드를 사용하며, --framework Strands는 CLI 템플릿만 지정하므로 실제 Hugging Face smolagents 코드와 모순되지 않는다. pyproject.toml에는 Python 3.10 이상과 smolagents, transformers, boto3, OpenSearch 클라이언트, bedrock-agentcore 등 필요한 의존성을 정의한다. Dockerfile은 python:3.12-slim 이미지를 바탕으로 uv를 설치하고 의존성과 코드를 복사한 뒤 8080 포트를 노출하며 healthcare_agentcore.py를 실행한다. .dockerignore에서는 가상환경, Python 캐시, Git 디렉터리 등을 제외해 이미지 크기를 2 GB 제한 안에 유지하도록 구성한다.

7. 배포와 두 가지 호출 시험

프로젝트와 컨테이너 구성을 마치면 agentcore deploy -y 명령으로 배포한다. CLI는 컨테이너를 빌드하고 Amazon Elastic Container Registry에 푸시한 다음 AgentCore runtime 에이전트를 생성하며, 원문은 배포에 약 10~15분이 걸린다고 안내한다. 배포 후에는 AgentCore CLI와 boto3 SDK라는 두 경로로 같은 에이전트를 시험할 수 있다. CLI 예제는 메트포르민의 부작용을 묻는 prompt와 llama라는 model_type을 전달한다. boto3 예제는 us-west-2의 bedrock-agentcore 클라이언트에서 invoke_agent_runtime을 호출하며, agentRuntimeArn으로 배포된 에이전트를 지정하고 JSON 요청 형식과 모델 선택을 포함한 payload를 전달한다. 반환된 응답 스트림은 UTF-8로 디코딩해 출력하지만, 제공된 원문에는 실제 의료 응답 내용이나 성능 측정 결과가 제시되지 않는다.

8. 자체 관리 배포와 관리형 런타임의 차이

마지막 비교는 같은 에이전트를 어느 운영 방식으로 배포하느냐에 초점을 맞춘다. Amazon ECS와 AWS Fargate를 사용하는 독립 실행 버전에서는 사용자가 ECS 태스크 정의와 서비스 구성, 자동 확장 정책, 서비스별 IAM 역할, Amazon CloudWatch 기반 관측 가능성을 직접 설정한다. 배포도 Docker 빌드, Amazon ECR 푸시, ECS 서비스 업데이트로 진행되며, 이 방식은 컨테이너 구성과 네트워킹, 확장 동작을 완전히 제어할 수 있다는 장점이 있다. AgentCore runtime 버전은 같은 healthcare_agentcore.py에 데코레이터 패턴을 적용하고, 앞선 설명처럼 컨테이너 운영과 확장·ID 관리·관측 가능성을 런타임에 맡긴다. 따라서 원문이 제시하는 전환의 의미는 모델 기능의 교체보다 운영 책임의 이동에 있으며, 직접 제어가 필요한 정도와 관리 부담을 함께 고려하는 비교다. 제공된 원문은 AgentCore runtime 배포를 설명하는 마지막 문장 중간에서 끊겨 있어, 이후의 비교나 결론은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 이 사례는 모델 오케스트레이션과 검색 로직을 유지한 채 배포 계층을 바꾸는 접근을 보여주며, 기능 보존과 운영 책임 이전을 별도로 판단할 수 있게 한다.
• 백엔드의 요청·응답 형식이 일관되더라도 각 백엔드의 역할과 배포 특성은 다르므로, 인터페이스 통일이 모델 선택의 필요성까지 없애지는 않는다.
• 관리형 런타임으로의 이전은 운영 부담을 줄이지만, 원문이 별도로 제시한 서비스 접근 권한, 컨테이너 제한, 의료 질의에 대한 통제 요건은 여전히 검토 대상이다.

✅ 액션 아이템

• Amazon ECS와 AWS Fargate의 직접 제어 필요 수준과 AgentCore runtime의 운영 부담 감소를 비교해 이전 적합성 검토.
• 기존 Hugging Face smolagents 로직에 BYO 데코레이터 방식을 적용하고, 3개 모델 백엔드와 Amazon OpenSearch Service 검색의 유지 여부를 CLI 또는 boto3 호출로 확인.
• 배포 전 리전별 서비스·모델 접근성, AWS 권한, 2 GB 이미지 제한과 의료 질의 운영에 필요한 Amazon Bedrock Guardrails 적용 조건 확인.

❓ 열린 질문

• Amazon ECS와 AWS Fargate에서 직접 제어하던 컨테이너·네트워킹·확장 설정 중 AgentCore runtime 이전 결정에 영향을 주는 요구는 무엇인가?
• BioM-ELECTRA-Large-SQuAD2와 Llama 3.1 70B Instruct by Meta를 포함한 3개 모델 백엔드는 질의 유형에 따라 어떤 기준으로 선택할 것인가?
• 시연용 샘플을 의료 질의 운영에 적용할 때 Amazon Bedrock Guardrails의 콘텐츠 필터링과 근거 검증을 어떤 기준으로 확인할 것인가?