AIP-C01 공식 시험 가이드는 에이전트 구현 항목(2.1.1, 2.1.6, 2.1.7, 2.5.5)과 검색 항목(1.5.6)에서 Strands Agents, AWS Agent Squad, MCP(Model Context Protocol)를 이름으로 언급합니다. 앞선 "Bedrock Agents와 도구 통합" 글이 완전 관리형 에이전트를 다뤘다면, 이번 포스팅에서는 코드로 에이전트를 만드는 오픈소스 도구와 에이전트가 도구에 연결하는 표준 방식을 정리합니다. 각 도구가 무엇을 해결하는지, 시험에서 어떤 표현이 나오면 무엇을 골라야 하는지가 핵심입니다.
관리형 vs 코드 중심: 에이전트를 만드는 세 가지 선택지
| 구분 | Bedrock Agents | Strands Agents | AWS Agent Squad | |------|----------------|----------------|-----------------| | 형태 | 완전 관리형 서비스 | 오픈소스 SDK (Python, TypeScript) | 오픈소스 프레임워크 (Python, TypeScript) | | 핵심 아이디어 | Action Group·Knowledge Base를 설정 | 모델·도구·프롬프트만 정의하면 모델이 계획 | 분류기가 질문마다 가장 맞는 에이전트로 라우팅 | | 실행 위치 | AWS가 관리하는 런타임 | Lambda, Fargate, EKS, AgentCore Runtime 등 | 애플리케이션 안 | | 모델 | Bedrock 모델 | Amazon Bedrock을 비롯한 여러 공급자 | Bedrock, Anthropic, OpenAI 등 여러 공급자 | | 시험 표현 | "최소한의 코드로 관리형 에이전트" | "에이전트 동작을 코드로 세밀하게 제어" | "여러 전문 에이전트 중 하나로 요청 분배" |
세 가지는 경쟁 관계라기보다 필요한 제어 수준에 따른 선택입니다. 설정만으로 빨리 만들고 운영을 맡기고 싶다면 Bedrock Agents, 도구 호출 방식·메모리·다중 에이전트 구조를 코드로 직접 다루고 싶다면 Strands Agents, 이미 여러 에이전트(챗봇, Lex 봇, Lambda 기반 처리기)가 있고 그 앞에서 요청을 나눠 줄 라우터가 필요하다면 Agent Squad입니다.
Strands Agents: 모델이 스스로 계획하는 에이전트 SDK
Strands Agents는 AWS가 공개한 오픈소스 에이전트 SDK로, "모델 주도(model-driven)" 방식을 씁니다. 개발자가 단계별 흐름을 코드로 짜는 대신 모델, 도구 목록, 시스템 프롬프트만 정의하면, 어떤 도구를 어떤 순서로 부를지는 모델이 에이전트 루프 안에서 결정합니다.
도구는 Python 함수에 데코레이터를 붙여 만듭니다. 함수 이름, 타입 힌트, docstring에서 도구 명세가 자동으로 만들어지므로 공식 가이드 2.1.6이 말하는 "표준화된 함수 정의"가 됩니다.
도구 안에서 입력을 검증하고, 실패하면 모델이 이해할 수 있는 문장으로 이유를 돌려주는 것이 안정적인 도구 설계의 기본입니다.
여러 에이전트를 조합하는 패턴도 제공합니다.
에이전트를 도구로(agents as tools): 오케스트레이터 에이전트가 전문 에이전트를 도구처럼 호출합니다. 스웜(swarm): 에이전트들이 서로 작업을 넘겨주며 협업합니다. 그래프(graph): 노드와 연결을 정의하고 조건에 따라 경로를 고릅니다. 워크플로(workflow): 미리 정한 순서(DAG)대로 작업을 실행합니다.
대화 상태는 세션 관리자로 로컬 파일이나 S3에 저장할 수 있고, 에이전트 루프의 각 결정은 추적 데이터로 남아 OpenTelemetry로 내보낼 수 있습니다.
AWS Agent Squad: 질문을 가장 맞는 에이전트로 보내기
AWS Agent Squad(이전 이름 Multi-Agent Orchestrator)는 여러 전문 에이전트 앞에 서는 라우터입니다. 사용자 입력이 들어오면 분류기(classifier)가 각 에이전트의 설명과 대화 기록을 보고 가장 적합한 에이전트를 고르고, 선택된 에이전트가 답한 뒤 오케스트레이터가 대화 기록을 저장합니다. 그래서 사용자가 결제 질문을 하다가 배송 질문으로 넘어가도 맥락이 이어집니다.
SupervisorAgent를 쓰면 리드 에이전트가 팀 에이전트들을 병렬로 호출하고 결과를 하나의 답으로 합칩니다. "고객 문의를 의도별로 분류해 결제·배송·기술지원 전문 에이전트로 보낸다"는 시나리오가 대표적이며, 완전 관리형으로 같은 구조를 만들고 싶다면 Bedrock Agents의 멀티에이전트 협업(supervisor)이 대안입니다.
MCP: 에이전트와 도구를 잇는 표준 프로토콜
MCP는 AI 애플리케이션이 외부 도구와 데이터에 연결하는 방식을 표준화한 오픈 프로토콜입니다. 도구마다 다른 연동 코드를 짜는 대신, 한 번 만든 MCP 서버를 여러 에이전트와 IDE가 똑같은 방식으로 재사용할 수 있습니다.
호스트(host): 에이전트나 IDE 같은 AI 애플리케이션. 연결할 서버마다 MCP 클라이언트를 하나씩 만듭니다. 서버(server): 도구(tools), 리소스(resources), 프롬프트(prompts)를 제공합니다. 메시지는 JSON-RPC 2.0 형식이고, 같은 컴퓨터 안에서는 stdio, 원격 서버는 Streamable HTTP로 통신합니다.
공식 가이드 2.1.7은 AWS에서 MCP 서버를 어디에 올릴지를 묻습니다. 요청마다 독립적으로 끝나는 가벼운 도구는 Lambda로 만든 상태 없는(stateless) MCP 서버가, 의존성이 크거나 오래 실행되거나 연결을 유지해야 하는 복잡한 도구는 Amazon ECS(Fargate) 기반 MCP 서버가 맞습니다. 이미 있는 REST API나 Lambda 함수를 다시 짜지 않고 MCP 도구로 노출하고 싶다면 Amazon Bedrock AgentCore Gateway가 변환과 인증을 맡습니다.
검색 항목 1.5.6의 "벡터 검색을 위한 MCP 클라이언트"도 같은 맥락입니다. Knowledge Base 검색을 MCP 도구로 노출하면, 어떤 에이전트든 같은 방식으로 사내 지식을 검색할 수 있습니다.
!에이전트 하나, MCP로 연결하는 여러 도구
도구를 안정적으로 운영하기
에이전트가 자율적으로 도구를 부를수록 도구 쪽의 안전장치가 중요합니다.
입력 검증과 명확한 오류 메시지: 모델이 잘못된 파라미터를 넘겨도 도구가 거르고, 이유를 알려 모델이 다시 시도할 수 있게 합니다. 시간 제한과 멱등성: Lambda 타임아웃으로 무한 대기를 막고, 같은 호출이 두 번 들어와도 결과가 중복되지 않게 설계합니다. 최소 권한: 도구마다 별도의 IAM 역할을 두어 에이전트가 할 수 있는 일의 경계를 정합니다(2.1.3). 사람 확인: 환불·삭제처럼 위험한 작업은 바로 실행하지 말고 승인 단계를 둡니다. Bedrock Agents에서는 Return of Control로 실행을 애플리케이션에 넘기고, 워크플로 전체라면 Step Functions 콜백 패턴을 씁니다. 관측: 도구별 호출 횟수, 실패율, 지연, 에이전트 간 위임 흐름을 수집해 평소 기준선과 다른 패턴을 감지합니다(4.3.4).
AgentCore는 어디에 들어가나
Amazon Bedrock AgentCore는 어떤 프레임워크로 만든 에이전트든 AWS에서 운영할 수 있게 해 주는 관리형 구성 요소 모음입니다.
Runtime: 에이전트와 MCP 서버를 서버리스로 실행하고 세션을 격리합니다. Memory: 대화 안의 단기 기억과 세션을 넘는 장기 기억을 관리합니다. Gateway: API와 Lambda 함수를 MCP 도구로 바꿔 제공합니다. Identity: 에이전트가 외부 서비스에 접근할 때의 인증과 자격 증명을 관리합니다. Observability: OpenTelemetry 기반으로 에이전트 동작을 추적하고 CloudWatch로 확인합니다.
시험 가이드의 세부 항목 본문에는 AgentCore라는 이름이 나오지 않지만, Strands Agents와 MCP로 만든 에이전트를 운영 환경에 올리는 시나리오에서 자연스럽게 함께 등장하므로 구성 요소별 역할을 알아 두면 좋습니다.
시나리오로 연습하기
주문 상담 에이전트를 Bedrock 모델로 만들면서 도구 호출 순서, 재시도 방식, 대화 기록 저장 위치를 코드로 직접 제어하고 Lambda에 배포하려 한다. 정답은 Strands Agents입니다. 결제 챗봇(Lex), 배송 조회 Lambda, 기술지원 RAG 봇이 따로 있는데, 고객이 하나의 창에서 질문하면 알맞은 봇으로 연결되고 주제가 바뀌어도 맥락이 이어져야 한다. 정답은 AWS Agent Squad입니다. OpenAPI 명세가 있는 사내 HR REST API를 여러 팀의 에이전트가 공통 도구로 쓰게 하고 싶지만 API 코드는 바꿀 수 없다. 정답은 AgentCore Gateway로 MCP 도구화하는 것입니다. 문서 변환 도구가 큰 라이브러리를 쓰고 처리에 몇 분 이상 걸린다. 정답은 Amazon ECS(Fargate) 기반 MCP 서버입니다. 환율 조회처럼 요청마다 바로 끝나는 간단한 도구라면 Lambda 기반 MCP 서버가 가장 운영 부담이 적습니다.
시험 핵심 정리
"최소한의 코드로 관리형 에이전트" -- Amazon Bedrock Agents "모델·도구·프롬프트만 정의하는 코드 기반 에이전트" -- Strands Agents (model-driven) "Python 함수를 표준화된 도구로 정의" -- Strands의 @tool 데코레이터 "전문 에이전트를 도구처럼 호출" -- agents as tools 패턴 "질문마다 가장 맞는 에이전트로 라우팅하고 대화 맥락 유지" -- AWS Agent Squad (분류기) "리드 에이전트가 팀 에이전트를 병렬 호출해 결과 통합" -- Agent Squad SupervisorAgent "도구 연동 방식을 표준화해 여러 에이전트가 재사용" -- MCP (Model Context Protocol) "가볍고 상태 없는 MCP 도구" -- Lambda 기반 MCP 서버 "복잡하고 오래 실행되는 MCP 도구" -- Amazon ECS 기반 MCP 서버 "기존 API·Lambda를 코드 수정 없이 MCP 도구로" -- AgentCore Gateway "에이전트가 직접 실행하면 위험한 작업" -- Return of Control 또는 Step Functions 승인 단계 "도구 호출 실패율·지연 추적" -- CloudWatch 지표 + OpenTelemetry 추적