AWS 에이전트 아키텍처
SageMaker AI와 Bedrock AgentCore를 한 멀티모델 흐름으로 연결합니다
AWS 공식 예제는 Qwen 3.5 9B와 두 Claude 모델을 Strands Agents로 오케스트레이션하고 AgentCore Runtime에 배포합니다.
이 글에서 다룰 내용
AWS 서비스별 역할, Qwen 3.5 9B 배포, Strands Agents 라우팅, OpenTelemetry 토큰 추적
이 글에서 다룰 내용
AWS 멀티모델 AI 에이전트의 전체 구조, Amazon SageMaker AI와 Amazon Bedrock AgentCore의 역할, Qwen 3.5 9B 연결 방식, Strands Agents를 활용한 모델 라우팅, 토큰 관측성과 OpenTelemetry 적용 방법
왜 멀티모델 AI 에이전트가 필요할까요?
하나의 모델 호스팅 방식만으로 모든 요구를 맞추기는 어렵습니다. AWS 공식 기술 글은 관리형 Bedrock 모델과 비용·도메인 요구에 맞춘 SageMaker AI 자체 호스팅 모델을 에이전트 프레임워크를 다시 쓰지 않고 조합하는 방법을 제시합니다.
공식 예제에서는 Claude Haiku 4.5가 요청을 분류하는 오케스트레이터를 맡습니다. Claude Sonnet 4.6은 예산 배분을, SageMaker AI에 배포한 Qwen 3.5 9B는 금융 분석과 포트폴리오 구성을 담당합니다.
이 구조의 핵심은 단순히 모델을 여러 개 연결하는 데 있지 않습니다. 모델 선택 기준과 실패 대응 방식을 명확하게 설계하는 것이 더 중요합니다.
각 AWS 서비스의 역할부터 나누기
Amazon SageMaker AI는 Qwen 3.5 9B 같은 오픈 모델을 직접 배포하고 운영하는 계층으로 활용할 수 있습니다. 모델 아티팩트를 준비한 뒤 실시간 추론 엔드포인트로 배포하면 애플리케이션에서 API 형태로 호출할 수 있습니다.
Amazon Bedrock AgentCore Runtime은 이 멀티에이전트 애플리케이션을 배포하는 관리형 실행 환경입니다. 공식 글의 범위에서 AgentCore는 전체 workflow 실행과 자동 OpenTelemetry 계측을 제공하지만, SageMaker의 OpenAI 호환 endpoint 호출에는 별도 토큰 계측이 필요합니다.
Strands Agents는 이 둘을 이어 주는 에이전트 프레임워크 역할을 합니다. 요청 분석, 모델 선택, 도구 실행, 결과 정리 같은 흐름을 비교적 간결하게 구성할 수 있습니다.
SageMaker AI는 자체 호스팅 모델 경로, Bedrock은 관리형 모델 경로, AgentCore Runtime은 실행 환경, Strands Agents는 오케스트레이션 프레임워크라고 구분하면 구조가 선명해집니다.
Qwen 3.5 9B를 SageMaker AI에 배포하기
AWS 예제는 Qwen 3.5 9B를 vLLM 0.22.1 컨테이너와
ml.g6e.2xlarge
인스턴스에 배포합니다. 이 예제 인스턴스는 L40S 48GB GPU 1개를 사용하며 최대 모델 길이는 32,768로 설정합니다.
배포 뒤 SageMaker AI의 OpenAI 호환 endpoint를
AsyncOpenAI
client로 호출합니다. 장기 실행 session에서도 인증이 끊기지 않도록
generate_token()
을 이용해 bearer token을 요청마다 갱신하는 방식입니다.
운영 환경에서는 최대 출력 토큰과 동시 요청 수에도 제한을 두는 편이 안전합니다. 작은 모델이라고 무제한 호출하면 대기열이 길어지고 비용도 예상보다 빠르게 늘어날 수 있습니다.
개인정보나 사내 문서를 다룬다면 네트워크 격리와 IAM 권한도 함께 설계해야 합니다. 모델 배포보다 접근 권한을 먼저 좁히는 방식이 운영 사고를 줄이는 데 도움이 됩니다.
Strands Agents로 모델 라우팅 구성하기
공식 예제의 오케스트레이터는 사용자 의도를 분류한 뒤 Strands Agents의 agents as tools 패턴으로 예산 agent 또는 금융 분석 agent를 호출합니다. 전자는 Bedrock의 Claude Sonnet 4.6을, 후자는 SageMaker AI의 Qwen 3.5 9B를 사용합니다.
라우팅 규칙은 처음부터 지나치게 복잡하게 만들 필요가 없습니다. 작업 유형, 입력 길이, 보안 등급, 예상 비용처럼 확인 가능한 조건부터 사용하는 것이 좋습니다.
SageMaker endpoint는 Strands Agents의
OpenAIModel
에 연결되고 Qwen agent는 도구로 감싸집니다. 전체 애플리케이션은
bedrock-agentcore-starter-toolkit
을 통해 AgentCore Runtime에 배포됩니다.
첫 번째 모델이 시간 초과나 형식 오류를 일으켰을 때 사용할 대체 경로도 필요합니다. 다만 무조건 고가 모델로 재시도하기보다는 재시도 횟수와 전환 조건을 명시해야 비용 폭증을 막을 수 있습니다.
토큰 관측성과 OpenTelemetry 적용하기
멀티모델 환경에서는 전체 호출 횟수만 봐서는 문제를 찾기 어렵습니다. 모델별 입력 토큰, 출력 토큰, 지연 시간, 오류율, 재시도 횟수를 함께 기록해야 합니다.
여기에 필요한 것이 토큰 관측성입니다. 어떤 요청이 어느 모델로 전달됐고, 몇 개의 토큰을 사용했으며, 최종 응답까지 얼마나 걸렸는지 추적하는 방식입니다.
AgentCore Runtime은 Bedrock 모델 호출을 자동 계측하지만, Strands의
OpenAIModel
을 거치는 SageMaker endpoint는 기본 상태에서
gen_ai.chat
token span이 생성되지 않습니다. 공식 예제는 사용자 정의 OpenTelemetry span을 만들고
result.metrics.accumulated_usage
에서 입력·출력·전체 token 수를 기록합니다.
vLLM streaming 응답에서 token 사용량을 받으려면
stream_options: {"include_usage": True}
도 필요합니다. 이 설정이 없으면 span을 추가해도 누적 token 수가 0으로 남을 수 있습니다.
단, 프롬프트 원문과 모델 응답을 그대로 수집하면 개인정보나 기밀 정보가 로그에 남을 수 있습니다. 운영 로그에는 식별자와 통계값을 중심으로 저장하고, 본문 수집은 별도 승인과 마스킹 정책을 적용하는 편이 안전합니다.
구축 순서와 운영 체크포인트
처음에는 공식 예제처럼 오케스트레이터와 역할이 분명한 전문 agent부터 연결하는 편이 좋습니다. 어떤 업무를 Qwen 3.5 9B와 Bedrock 모델에 맡길지는 실제 품질·지연·비용 검증 결과로 정해야 합니다.
그다음 Strands Agents의 라우팅을 AgentCore Runtime에 배포하고 SageMaker bearer token 갱신과 Bedrock model access를 확인합니다. 정상 호출 뒤 사용자 정의 span과 CloudWatch Transaction Search를 연결하면 token 단위 추적이 가능합니다.
마지막으로 OpenTelemetry 추적 데이터를 보면서 라우팅 기준을 조정합니다. 비용이 낮아도 실패율이 높은 경로는 개선해야 하고, 품질 차이가 작다면 더 빠르고 저렴한 모델의 비중을 높일 수 있습니다.
AWS 멀티모델 AI 에이전트의 완성도는 연결한 모델의 개수보다 운영 데이터에서 결정됩니다. 작게 구축하고 실제 호출 결과를 측정하면서 모델 선택 규칙을 다듬는 접근이 가장 현실적입니다.
한 줄 요약: SageMaker AI의 Qwen 3.5 9B와 Bedrock의 Claude를 AgentCore Runtime·Strands Agents로 연결하고, 누락된 SageMaker token 정보를 OpenTelemetry로 보완하는 것이 핵심입니다.
