에이전틱 AI와 Amazon Bedrock AgentCore를 활용한 전문가 팀 시뮬레이션 - Amazon Web Services

에이전틱 AI와 Amazon Bedrock AgentCore를 활용한 전문가 팀 시뮬레이션 이 글은 AWS Spatial Computing Blog에 게시된 Simulating Expert Teams with Agentic AI and Amazon Bedrock AgentCore 를 한국어로 번역 및 편집하였습니다. 소개 여러 전문 분야에 걸친 기술적 질문에 답하는 것은 단순히 정답을 찾는 문제가 아닙니다. 가장 어려운 부분은 그 답을 제공할 수 있는 적절한 사람들을 조율하는 일인 경우가 많습니다. 만약 AI가 전문가 팀을 대체하는 것이 아니라, 초기 리서치와 종합 과정을 가속화하는 방식으로 이 조율을 보완할 수 있다면 어떨까요? 복잡한 기술 질문이 여러 도메인에 걸쳐 있을 때, 답을 찾는 과정에는 상당한 마찰이 수반됩니다. 자율 로봇 시스템 구축에 관한 질문이라면 IoT 전문가, 생성형 AI 실무자, 공간 컴퓨팅 전문가, HPC 엔지니어의 의견이 필요할 수 있습니다. 각 전문가는 깊은 전문성을 보유하고 있지만, 이들의 집단 지식을 조율하는 데는 시간이 걸립니다. 조직에는 다양한 전문 도메인에 걸쳐 뛰어난 전문가들이 있지만, 이들을 조율하는 것 자체가 장벽이 될 수 있습니다. 어떤 전문가를 참여시킬지 파악하고, 질문에 대해 방향을 맞추고, 각자의 관점을 하나의 일관된 답변으로 종합하는 과정이 그렇습니다. 예를 들어, AWS에는 7개의 전문 그룹으로 구성된 Advanced Computing 조직이 있습니다: HPC, 양자 컴퓨팅, 비주얼 컴퓨팅, 공간 컴퓨팅, IoT, 기술 파트너십, 그리고 이머징 테크놀로지(주로 응용 생성형 AI에 집중)입니다. 고객 질문은 이 중 두세 개 도메인에 걸치는 경우가 많습니다. 전문가들이 깊은 도메인 전문성을 유지하면서 경계를 넘어 협업하는 팀 구조는 잘 작동하지만, 분산된 전문성을 가진 모든 조직이 그렇듯 조율에는 시간이 걸립니다. 이 관찰에서 하나의 실험이 시작되었습니다: 바로 이 팀 구조를 그대로 반영하는 멀티 에이전트 AI 시스템을 구축하면 어떨까 하는 것이었습니다. 각 도메인을 대표하는 7개의 AI 에이전트와, 질문을 라우팅하고 각 질의에 적합한 팀을 구성하는 코디네이터로 말입니다. 이 시스템은 에이전틱 AI 애플리케이션을 구축하고 배포하기 위한 AWS의 관리형 서비스인 Amazon Bedrock AgentCore에서 실행됩니다. 에이전트 자체는 멀티 에이전트 오케스트레이션을 위한 오픈소스 SDK인 AWS Strands Agents로 구축되었습니다. 이 시스템은 초기 리서치와 크로스 도메인 조율을 처리하여 아키텍처 초안이나 솔루션 접근 방식을 생성합니다. 그런 다음 인간 전문가가 이를 검증하고, 다듬고, 최종 결정을 내릴 수 있습니다. 이는 조율 병목을 해소합니다: 적절한 전문가를 찾고, 미팅을 잡고, 관점을 종합하는 데 며칠을 보내는 대신, 몇 분 만에 출발점을 얻을 수 있습니다. 아래 예시에서 볼 수 있듯이, 이 시스템은 며칠에서 수 주가 걸릴 수 있는 리서치를 한 번의 상담으로 압축할 수 있습니다. 핵심 가치는 완벽한 답이 아니라, 인간 전문가가 초기 리서치 대신 개선 작업에 집중할 수 있도록 하는 초안 작성 시간의 단축입니다. 이 글에서는 이 시스템의 작동 방식을 살펴보고, 실제 질의를 처리하는 과정을 시연하며, 여러분이 적용할 수 있는 패턴을 도출합니다. 조직 내 유사한 시스템을 구축하려는 경우, 실용적인 예제를 통해 Amazon Bedrock AgentCore의 작동 방식을 배우고 싶은 경우, 또는 에이전트 AI가 어떤 유형의 문제를 해결할 수 있는지 탐색하려는 경우 모두에게 구체적인 구현 세부 사항을 제공합니다. 전체 구현 코드는 인프라 코드, 에이전트 정의, 배포 스크립트를 포함하여 GitHub에서 확인할 수 있습니다. 솔루션 개요 이 구현의 핵심은 AWS Strands Agents로 구축된 코디네이터 기반 스웜(coordinator-orchestrated dynamic swarm) 패턴입니다. 코디네이터 에이전트가 들어오는 질의를 분석하고 응답 방식을 결정합니다: AgentCore Memory에 저장된 과거 상호작용을 확인하거나, 간단한 후속 질문에는 직접 답변하거나, 7개의 도메인 전문가 에이전트 풀에서 임시 스웜을 동적으로 생성합니다. 각 전문가 에이전트는 해당 도메인을 전문으로 하는 AWS 솔루션즈 아키텍트처럼 응답하도록 설계되어 있습니다. 코디네이터는 질의에 따라 어떤 전문가 에이전트를 참여시킬지 선택합니다. 간단한 질문은 한 명의 전문가만 필요할 수 있고, 복잡한 멀티 도메인 질문은 두세 명이 스웜으로 함께 작업해야 할 수 있습니다. 선택된 에이전트들은 핸드오프를 통해 협업하며, 답을 향해 나아가면서 서로 질문을 주고받습니다. 각 전문가 에이전트는 최신 정보가 담긴 도메인별 지식 베이스에 접근할 수 있습니다—서비스 문서, 고객 성공 사례, API 사양, 솔루션 가이드 등이 포함됩니다. 에이전트가 정보가 필요하면 지식 베이스를 실시간으로 질의하고, 결과를 읽은 뒤, 더 깊이 파고들거나 명확히 하기 위해 다시 질의할 수 있습니다. 결과적으로 각 에이전트가 전문화된 지식 베이스에서 에이전틱 RAG(Retrieval Augmented Generation)를 수행하고, 에이전트들이 번갈아가며 서로의 응답을 기반으로 발전시키는 동적 멀티 에이전트 시스템이 만들어집니다. 여러분이 LLM에 질문하고, 결과를 읽고, 솔루션을 향해 후속 질문을 하는 방식을 생각해 보세요. 이 에이전트들도 같은 일을 하지만, 각각 다른 도메인 전문성을 가져옵니다. 한 에이전트의 응답이 다른 에이전트의 질의에 대한 컨텍스트가 됩니다. 이들의 관점은 단일 에이전트나 단순한 지식 베이스 조회로는 불가능한 방식으로 결합됩니다. 이면에서 시스템은 에이전트 호스팅을 위한 Amazon Bedrock AgentCore Runtime, 도구 접근을 위한 AgentCore Gateway, 대화 연속성을 위한 AgentCore Memory를 기반으로 실행됩니다. AWS Lambda가 AgentCore Gateway를 통한 도구 호출을 처리하고, Amazon Bedrock Knowledge Bases가 에이전트 질의와 관련된 도메인별 문서를 제공합니다. 이 구성 요소들이 어떻게 맞물리는지 살펴보겠습니다. AWS 아키텍처 그림 1은 이 멀티 에이전트 시스템을 구동하는 AWS 인프라를 보여줍니다. 중심에는 Amazon Bedrock AgentCore가 있습니다. 이 구현은 AgentCore의 세 가지 기능을 사용합니다: 에이전트 코드 호스팅을 위한 Runtime, MCP(Model Context Protocol)를 통한 안전한 도구 접근을 위한 Gateway, 대화 연속성을 위한 Memory입니다. AgentCore는 인증을 위한 Identity와 모니터링을 위한 Observability도 제공하지만, 이 구현에서는 사용하지 않습니다. 에이전트 코드 자체는 AgentCore Runtime의 서버리스 컨테이너에서 실행됩니다. 시스템이 배포되면 AWS Cloud Development Kit(CDK)가 에이전트 코드에서 Docker 컨테이너를 자동으로 빌드하고, Amazon Elastic Container Registry(Amazon ECR)에 푸시하고, 런타임이 이를 사용하도록 구성합니다. 런타임은 수요에 따라 자동으로 확장되며 실제 사용량에 대해서만 과금됩니다. 전문가 에이전트가 지식 베이스를 질의해야 할 때는 AgentCore Gateway를 거칩니다. Gateway는 AI 에이전트를 도구 및 데이터 소스에 연결하기 위한 업계 표준으로 빠르게 자리잡고 있는 개방형 표준인 Model Context Protocol(MCP) 위에 구축되어 있습니다. MCP는 에이전트가 각 백엔드에 대한 커스텀 통합 없이 도구를 발견하고 호출할 수 있는 표준화된 방법을 제공합니다. 에이전트 생태계가 성장함에 따라 에이전트 코드를 수정하지 않고도 Gateway를 통해 새로운 도구를 추가할 수 있다는 점에서 이는 중요합니다—에이전트가 MCP를 통해 사용 가능한 도구를 자동으로 발견하기 때문입니다. AgentCore Gateway는 다양한 백엔드에 연결하기 위한 여러 타겟 유형을 지원합니다: AWS Lambda 함수, OpenAPI 사양, 또는 커스텀 MCP 서버입니다. 이 구현에서는 어떤 전문가 에이전트가 요청하는지에 따라 적절한 지식 베이스로 라우팅하는 단일 Lambda 타겟을 사용합니다. 인증에는 Amazon Cognito와 함께 OAuth를 사용하여 인가된 에이전트만 지식 베이스에 접근할 수 있도록 합니다. Lambda 함수는 에이전트로부터 도메인 이름과 질의 텍스트를 받습니다. 7개의 지식 베이스는 Amazon Bedrock Knowledge Bases를 사용하여 구축되며, 각각 도메인별 문서가 담긴 Amazon S3 버킷에 연결됩니다. 문서를 업로드하면 서비스가 자동으로 청킹하고, 임베딩을 생성하고, 벡터 검색을 위해 인덱싱합니다. AgentCore Memory는 두 가지 상호 보완적인 메커니즘을 통해 대화 연속성을 제공합니다. 세션 내 단기 메모리의 경우, 시스템은 사용자와 AI 시스템 간의 최근 대화 이력(최근 몇 번의 교환)을 로드하여 에이전트의 컨텍스트에 직접 추가합니다. 이를 통해 같은 대화 내에서 자연스러운 후속 질문이 가능합니다. 세션 간 장기 메모리의 경우, AgentCore Memory는 대화의 의미와 관계를 이해하기 위해 처리하는 시맨틱 메모리 전략을 사용합니다. 이를 통해 코디네이터가 몇 주 후에도 과거 지식을 검색하여 질문에 답할 수 있습니다. 이 조합은 현재 대화가 자연스럽게 느껴지면서도 시간이 지남에 따라 조직적 지식을 축적하는 것을 의미합니다. 멀티 에이전트 시스템 아키텍처 AWS 아키텍처를 설명했으니, 이제 에이전트들이 실제로 어떻게 협업하여 질문에 답하는지 살펴보겠습니다. 그림 2는 멀티 에이전트 협업 패턴을 보여줍니다. 코디네이터는 각 질의를 분석하고 어떤 전문가 에이전트를 참여시킬지 결정합니다. “AWS PCS가 뭔가요?”와 같은 간단한 질문에는 HPC 에이전트만 선택합니다. AI 기반 예측 유지보수를 갖춘 디지털 트윈 구축에 관한 복잡한 질문에는 공간 컴퓨팅(디지털 트윈 아키텍처), IoT(센서 데이터 수집), 생성형 AI(예측 유지보수를 포함한 전통적 ML도 담당) 세 에이전트를 선택할 수 있습니다. 코디네이터가 전문가 에이전트를 선택하면, AWS Strands Agents의 스웜 구성을 사용하여 해당 전문가들의 임시 팀을 생성하는 advcomp_swarm 이라는 도구를 호출합니다. 멀티 에이전트 아키텍처에서 이 그룹핑은 때때로 핸드오프 패턴이라고 불립니다—그룹 내의 각 에이전트가 다른 모든 에이전트와 직접 소통할 수 있는 에이전트 집합입니다. 각 전문가 에이전트는 문제에 대한 사고 방식을 형성하는 도메인별 시스템 프롬프트를 가지고 있습니다. HPC 에이전트는 고성능 컴퓨팅을 전문으로 하는 AWS 솔루션즈 아키텍트처럼 사고합니다. 양자 에이전트는 양자 알고리즘과 Amazon Braket에 대해 생각합니다. 생성형 AI 에이전트는 Amazon Bedrock, AgentCore, 머신러닝 서비스에 집중합니다. 에이전트들은 핸드오프를 통해 협업합니다. 한 에이전트가 분석을 완료하면 다음 팀원에게 명시적으로 핸드오프하며, 이를 통해 각 에이전트가 이전 에이전트의 결과를 기반으로 발전시켜 나가는 대화 스레드가 형성됩니다. 시스템에는 스웜당 최대 20회 핸드오프, 20회 반복, 총 실행 시간 30분이라는 제한이 적용됩니다. 이러한 제약 조건은 협업의 집중도를 유지하고 무한 실행을 방지합니다. 지식 베이스 접근은 AgentCore Gateway를 통해 이루어집니다. 에이전트가 정보가 필요하면 도메인 이름과 검색 질의를 포함하여 query_knowledge_base 도구를 호출합니다. 에이전트는 OAuth를 통해 Amazon Cognito에서 얻은 JSON 웹 토큰(JWT)을 요청에 포함합니다. Gateway가 토큰을 검증하고 AWS Lambda 함수로 라우팅합니다. Lambda 함수는 도메인을 적절한 Amazon Bedrock Knowledge Base에 매핑하고 RetrieveAndGenerate API를 호출합니다. 이 API는 벡터 검색을 수행하여 관련 문서 청크를 찾은 다음, 파운데이션 모델을 사용하여 해당 청크를 일관된 답변으로 합성합니다. 에이전트는 이 합성된 응답을 받고 더 깊이 파고들거나 명확히 하기 위해 다시 질의할 수 있습니다. 각 에이전트는 자신의 도메인 지식 베이스에만 접근할 수 있습니다. HPC 에이전트는 HPC 지식 베이스를, 양자 에이전트는 양자 지식 베이스를 조회하는 식입니다. 이러한 분리는 우리가 재현하고자 하는 인간 조직 구조를 반영합니다. 각 전문가가 자신의 도메인에 대한 깊은 전문성을 갖는 것처럼요. 설계 근거는 다음과 같습니다. 도메인별 에이전트 프롬프트와 집중된 지식 베이스 접근을 결합하면 에이전트가 전문화된 관점을 유지하는 데 도움이 됩니다. 이는 하나의 에이전트에 100개의 도구를 부여하는 것보다 전문화된 에이전트들에게 도구를 분산시키는 것이 더 효과적인 것과 같은 원리입니다. 여러 전문가가 협업하면, 이들의 지식 베이스 접근이 합쳐져 도메인 전반에 걸친 포괄적인 커버리지를 제공합니다. 메모리 시스템은 이 전체 과정에서 작동합니다. 코디네이터가 전문가 에이전트 스웜을 호출하기 전에, AgentCore Memory에서 관련 과거 대화를 확인합니다. 충분한 정보를 찾으면 전문가를 소집하지 않고 즉시 답변합니다. 이 메모리 우선 접근 방식은 후속 질문에 대한 효율성을 높입니다. 스웜이 완료된 후, 코디네이터는 어떤 에이전트가 참여했는지를 포함하여 대화를 메모리에 저장합니다. 이를 통해 시스템이 시간이 지남에 따라 유사한 질문에 더 잘 답할 수 있는 학습 루프가 만들어집니다. 전체 요청 흐름은 다음과 같습니다: 사용자가 질의 제출 → 코디네이터가 메모리 확인 → 필요시 코디네이터가 전문가 에이전트를 선택하고 스웜 도구 호출 → MCP 도구를 갖춘 전문가 스웜 생성 → 에이전트들이 핸드오프를 통해 협업하며 지식 베이스 질의 → Gateway가 인증하고 AWS Lambda가 Bedrock Knowledge Bases 질의 → 스웜이 최종 응답 합성 → 코디네이터가 대화와 학습 내용을 메모리에 저장. 이 아키텍처는 효율성(메모리 우선), 전문성(도메인 전문가), 최신 정보(지식 베이스 접근)의 균형을 맞춥니다. 실제 동작 살펴보기 시스템의 다양한 측면을 보여주는 세 가지 질의를 살펴보겠습니다: 단일 에이전트 지식 검색, 멀티 에이전트 협업, 그리고 에이전트 간 반복적 주고받기입니다. 질의 1. 그림 3: AWS PCS에 대한 단일 전문가 지식 검색 데모 영상 이 간단한 질문은 기준선 역할을 합니다. 코디네이터가 HPC 에이전트를 선택하고, HPC 에이전트가 HPC 지식 베이스를 질의합니다. 응답은 AWS Parallel Computing Service(PCS)가 HPC 워크로드를 실행하기 위한 관리형 서비스이며, AWS ParallelCluster와는 다른 서비스임을 설명합니다. 이 질의의 경우, 멀티 에이전트 시스템과 직접적인 LLM 호출 모두 비슷한 수준의 답변을 제공합니다—모델이 AWS PCS에 대한 정보를 학습 데이터에 포함할 만큼 최신이기 때문입니다. 이는 기준선을 확립합니다: 파운데이션 모델이 학습 데이터에 최신 정보를 가지고 있을 때, 두 접근 방식 모두 잘 작동합니다. 질의 2. 이 질의는 멀티 에이전트 협업을 보여줍니다. 코디네이터가 질의를 분석하고 세 가지 기술 도메인을 식별합니다: 공간 컴퓨팅(디지털 트윈 아키텍처와 3D 시각화), IoT(카메라 및 센서 데이터 수집), AI/ML(예측 유지보수와 내비게이션). 이 세 전문가 에이전트로 팀을 구성합니다. 에이전트들은 핸드오프를 통해 협업하며, 각각 이전 에이전트의 작업을 기반으로 발전시킵니다. IoT 에이전트가 먼저 AWS IoT Core, 2,800대 카메라를 위한 Amazon Kinesis Video Streams, 엣지 처리를 위한 AWS IoT Greengrass, 자산 모델링을 위한 AWS IoT SiteWise로 데이터 수집 레이어를 설계합니다. 공간 컴퓨팅 에이전트에게 핸드오프하면, 이 IoT 기반 위에 Visual Asset Management System(VAMS)을 활용한 3D 공간 매핑, Amazon DynamoDB의 공간 인덱싱, 시각화를 위한 AWS IoT TwinMaker를 추가합니다. 마지막으로, 생성형 AI 에이전트가 지능 계층을 추가합니다. AWS Strands Agents와 Amazon Bedrock AgentCore Runtime을 활용한 멀티 에이전트 내비게이션 시스템, 예측 정비를 위한 Amazon SageMaker(일반적으로 시계열 예측에 전통적 ML 모델 사용), 그리고 자연어 질의를 위한 Amazon Bedrock Knowledge Bases로 구성됩니다. 각 에이전트는 이 협업 과정에서 도메인별 지식 베이스를 여러 번 질의합니다. IoT 에이전트는 “AWS IoT SiteWise 자산 모델링”과 “2,800대 디바이스를 위한 플릿 프로비저닝”을 질의합니다. 공간 에이전트는 “공간 데이터 관리”와 “병목 감지”를 질의합니다. 생성형 AI 에이전트는 “AgentCore 멀티 에이전트 오케스트레이션”과 “AWS Strands Agents 협업”을 질의합니다. 이러한 실시간 질의는 추천 사항이 현재 AWS 기능을 반영하도록 보장합니다. 이 결과물은 출발점이지 최종 답변이 아닙니다. 인간 전문가가 서비스 선택을 검증하고, 누락된 구성 요소를 채우고, 특정 제약 조건에 맞게 조정해야 합니다. 이것이 의도된 워크플로입니다. 시스템이 초기 리서치와 종합을 처리하고, 인간이 검증하고 개선합니다. 이를 LLM 직접 호출 결과와 비교해 보겠습니다. LLM은 “서드파티 디지털 트윈 플랫폼을 고려하라”, “전통적 ML을 먼저 사용하라”, “생성형 AI는 금상첨화”와 같은 일반적인 가이드를 제공합니다. LLM의 응답은 신중하고 특정 벤더에 치우치지 않아 옵션을 탐색할 때는 합리적이지만, AWS 구현 세부 사항이 필요할 때는 구체성이 떨어집니다. 멀티 에이전트 시스템은 구체적인 서비스, 통합 패턴, 구현 단계를 포함한 상세한 AWS 특화 아키텍처를 제공합니다. 흥미롭게도, 코디네이터의 상위 수준 요약은 LLM 직접 응답과 크게 달라 보이지 않습니다. 둘 다 디지털 트윈, IoT, AI를 언급합니다. 진정한 가치는 에이전트 트레이스에 있습니다. IoT 에이전트가 데이터 계층을 설계하고, 공간 컴퓨팅 에이전트가 그 기반 위에 시각화를 추가하며, 생성형 AI 에이전트가 공간 컨텍스트에 지능을 통합합니다. 세 개의 개별 답변을 단순히 이어 붙인 것이 아니라, 각 계층이 이전 계층에 의존하는 일관되고 통합된 아키텍처입니다. 인간 리뷰어는 이러한 대화를 깊이 파고들어 추론 과정을 이해하고, 특정 선택에 의문을 제기하며, 접근 방식을 개선할 수 있습니다. 질의 3. 이 질의는 수퍼바이저 아키텍처를 넘어서는 네트워크 협업 패턴을 보여줍니다. 사용자가 명시적으로 전문가들에게 “함께 제안서를 다듬고”, “서로의 논거에 허점을 찾으라”고 요청하여, 에이전트들이 선형 핸드오프 체인이 아닌 여러 차례 주고받으며 반복하는 시스템의 반복 모드를 트리거합니다. 질의 2의 공장 디지털 트윈은 수퍼바이저 패턴(코디네이터가 IoT, Spatial, 생성형 AI 워커 에이전트에게 작업을 할당하고 각각 코디네이터에게 응답)이나 네트워크 패턴(워커 에이전트가 서로 직접 소통 가능, 에이전트 간 모든 통신 경로 사용 가능) 중 어느 것으로든 해결할 수 있습니다. 하지만 이 기상 시뮬레이션 질의는 특히 네트워크 접근 방식의 이점을 받습니다. 수퍼바이저가 기술적으로 HPC와 생성형 AI 워커 에이전트 사이에서 메시지를 주고받을 수는 있지만, 수퍼바이저 아키텍처는 반복적 개선을 위해 설계된 것이 아닙니다—작업 위임에는 뛰어나지만, 워커 에이전트가 서로의 가정에 도전하고 문서를 기반으로 주장을 검증하는 다중 라운드 토론을 촉진하는 데는 적합하지 않습니다. 네트워크 패턴은 워커 에이전트가 서로 직접 핸드오프할 수 있게 하여, 코디네이터 중재 교환이 아닌 (에이전트) 피어 리뷰를 통해 제안이 개선되는 대화 스레드를 만듭니다. 먼저, 이 질의에 대해 LLM 직접 호출이 어떤 결과를 내는지 살펴보겠습니다. 응답은 멀티 에이전트 토론을 시뮬레이션하며, 기상 데이터의 패턴 인식에 생성형 AI가 과연 올바른 접근인지 그 전제 자체에 의문을 제기하고, 생성형 AI를 추가하기 전에 전통적인 컴퓨터 비전과 딥러닝부터 시작할 것을 권장합니다. 단계별 구현 전략(1~3개월, 3~6개월, 6개월 이후)을 제시하고, 시뮬레이션 빈도, 관심 있는 특정 패턴, 데이터 보존 정책에 대한 확인 질문으로 마무리합니다. 이는 가치 있는 전략적 사고입니다. LLM이 가정에 반박하고 구현에 들어가기 전에 요구사항을 정제하도록 돕는 것입니다. 생성형 AI가 적합한지 아직 탐색 중이거나 여러 클라우드 제공업체를 검토하고 있다면, 이 즉각적인 응답이 양질의 전략적 가이드를 제공합니다. 멀티 에이전트 시스템은 다른 접근 방식을 취합니다. GenAI 에이전트가 초기 AI 아키텍처를 제안합니다: 스트리밍 추론이 가능한 Amazon Bedrock Agents, NetCDF(Network Common Data Form) 데이터 처리를 위한 Amazon SageMaker Processing, 그리고 비용 추정치입니다. 그러나 HPC 에이전트가 다섯 가지 구체적인 가정에 이의를 제기합니다: Bedrock이 실시간 스트리밍을 지원할 수 있는가? SageMaker가 NetCDF 전처리에 적합한 도구인가? 격리를 위해 별도의 VPC를 사용해야 하는가? 일일 10TB 처리의 현실적인 비용은 얼마인가? 기상학자들에게 설명 가능성을 어떻게 제공할 것인가? GenAI 에이전트는 지식 베이스를 조회하여 주장을 검증한 후 아키텍처를 수정합니다: SageMaker에서 AWS Batch로 전환하고(“맞는 말이야!”라고 인정하며), 3~5초 지연 시간의 Bedrock 스트리밍을 확인하고, 상세 비용 내역(월 총 $15,000$19,000)을 제시하며, 설명 가능성을 위한 Bedrock의 트레이스 기능을 설명합니다. HPC 에이전트는 자체 지식 베이스를 기반으로 이러한 수정 사항을 검증합니다. FSx 내보내기 경로, VPC 아키텍처, 네트워크 격리 패턴을 확인한 후, S3 접두사 분리와 같은 구체적인 개선 사항을 덧붙여 최종 설계를 승인합니다. 이 주고받는 과정에서 두 에이전트 간 3회의 핸드오프를 포함한 4회의 상호작용이 이루어졌습니다. 이를 코디네이터가 워커 에이전트에게 작업을 할당하고 각각 한 번씩만 응답하는 슈퍼바이저 패턴과 비교해 보세요. 네트워크 방식은 워커 에이전트들이 서로의 제안에 이의를 제기하고, 문서를 기반으로 검증하며, 양측이 합의에 도달할 때까지 반복적으로 개선할 수 있게 합니다. HPC 에이전트의 최종 응답에는 VPC 서브넷 레이아웃, 보안 그룹 사양, S3 수명 주기 정책에 대한 구체적인 세부 사항이 포함되어 있으며, 이는 반복적인 개선 과정을 통해 도출된 것입니다. 멀티 에이전트 시스템은 사용자가 이미 대략적인 방향을 결정하고, 상세한 AWS 특화 구현 계획을 도출하는 데 집중할 때 가장 효과적입니다. AWS 솔루션을 원한다는 것이 확실하고 검증된 통합 지점을 갖춘 프로덕션 수준의 사양이 필요하다면, 멀티 에이전트 시스템은 협업을 통해 도출된 검증 가능한 아키텍처 세부 사항을 제공합니다. 트레이드오프는 실행 시간(수 초가 아닌 6분 이상)이지만, 추적 가능한 추론(“내 KB에서 FSx 내보내기 기능을 확인했습니다”), 전문가의 이의 제기를 거쳐 수정된 검증된 비용 추정치, 그리고 즉시 구현 가능한 구체적인 사양을 얻을 수 있습니다. 오늘날 대부분의 AI 생성 결과물이 그렇듯, 이 제안서도 인간의 검토가 필요합니다. 인간 솔루션즈 아키텍트는 오류를 발견하거나, 누락된 구성 요소를 식별하거나, 비용 가정에 의문을 제기하거나, 시스템이 알지 못하는 특정 제약 조건에 맞게 조정할 수 있습니다. 하지만 백지 상태에서 시작하여 FSx 내보내기 구성, Bedrock 스트리밍 기능, VPC 격리 패턴, 여러 서비스에 걸친 비용 모델을 며칠간 리서치하고, 도메인 전문가들과 통합 지점을 검증하는 대신, 문서에 기반한 크로스 도메인 권장 사항이 담긴 상세한 출발점을 확보할 수 있습니다. 이 시스템은 며칠 또는 몇 주가 걸릴 수 있는 리서치와 조율을 추적 가능한 추론이 담긴 6분짜리 컨설팅으로 압축했습니다. 이것이 핵심 가치입니다: 완벽한 답이 아니라, 인간 전문가가 초기 리서치 대신 개선에 집중할 수 있도록 초안 작성 시간을 단축하는 것입니다. 단일 전문가 지식 검색에서 다중 전문가 협업, 그리고 반복적인 상호 검토로 이어지는 이 과정은 멀티 에이전트 시스템의 역량 범위를 보여줍니다. 단순한 질문은 빠르고 정확한 답을 얻습니다. 복잡한 문제는 필요한 만큼의 조율된 전문성을 확보합니다. 그리고 깊이 얽힌 도메인에 걸친 질문은 단 한 번의 핸드오프가 아닌, 에이전트들이 함께 반복적으로 다듬는 과정을 통해 더 나은 결과를 얻습니다. 결론 여러 도메인에 걸친 전문성을 조율하는 것은 현실적인 문제입니다. 전문성은 조직 내에 존재합니다. 병목은 적합한 인재를 신속하게 한자리에 모으는 것입니다. 이 시스템은 초기 리서치와 초안 솔루션 작성을 가속화하여 그 조율을 보강합니다. 이 글에서 설명한 시스템은 AWS의 실제 Advanced Computing 팀 구조를 모델로 했습니다: 7명의 도메인 전문가 에이전트, 질문을 라우팅하는 코디네이터, 그리고 지식 베이스를 통한 최신 문서 접근입니다. 시스템이 초기 리서치와 종합을 담당하고, 인간 전문가가 검증하고 다듬습니다. 대체가 아닌 보강입니다. 공장 디지털 트윈 사례가 이를 잘 보여줍니다: 세 명의 전문가 에이전트가 협업하여 IoT 데이터 수집, 공간 시각화, AI 기반 내비게이션이 함께 작동하는 통합 아키텍처를 설계했습니다. 시스템은 며칠이 걸릴 수 있는 리서치와 크로스 도메인 조율을 추적 가능한 추론과 검증된 통합 지점이 담긴 6분짜리 컨설팅으로 압축했습니다. 이는 멀티 에이전트 오케스트레이션, 실시간 지식 접근, 대화 메모리를 결합했을 때 무엇이 가능해지는지를 보여줍니다. 이러한 역량은 기술 팀의 업무 방식을 보강할 수 있습니다 — 복잡한 문제에 착수하기 위한 초기 진입 장벽을 낮추고, 대화 전반에 걸쳐 컨텍스트를 유지하며, 분산된 전문성을 조율하는 것입니다. 조직에서 멀티 에이전트 시스템을 도입해 보고 싶으신가요? - 코드 체험하기: 전체 구현 코드가 배포 가이드 및 인프라 코드와 함께 GitHub에 공개되어 있습니다 - AWS에 문의하기: 유사한 시스템 구현에 대한 안내를 받으려면 담당 AWS 어카운트 팀 또는 솔루션즈 아키텍트에게 연락하세요 - 전문 지원: 에이전트 AI 및 고급 컴퓨팅 전문성이 필요하시면, 어카운트 팀을 통해 AWS Advanced Computing – Emerging Technologies 팀과 연결을 요청하세요