5 production challenges in multi-agent systems and how Deep Insight solved them

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AWS의 Deep Insight는 역할별 Claude 모델과 8개 에이전트, 실행 흐름 제어 및 운영 인프라를 결합해 다중 에이전트 시스템의 프로덕션 전환에 필요한 다섯 가지 과제에 대응한다.

📌 핵심 요약

• AWS Solutions Architecture 팀은 프롬프트 개선만으로 해결하기 어려운 실행 순서, 검증, 예외 처리 문제에 대응하기 위해 데이터 분석용 다중 에이전트 시스템 Deep Insight를 구축했다.
• Deep Insight는 CSV와 자연어 요청으로 분석 계획을 만들고 사용자 승인을 거쳐 분석·시각화·계산 검증을 수행하며, 인용 포함·미포함 DOCX 보고서와 PNG 차트를 생성한다.
• 8개 에이전트의 협업에는 Strands Agents SDK의 Graph 패턴과 Agents-as-Tools 패턴을 결합한다. Amazon Bedrock의 Claude Haiku는 기본 라우팅, Extended Thinking을 활성화한 Opus는 계획 수립, Sonnet은 실행 역할에 배정한다.
• 배포 방식은 약 10분 만에 설정하는 로컬 CLI 기반 Self-Hosted, 비개발자도 사용할 수 있는 Web, 세션 격리와 프라이빗 VPC 배포를 지원하는 Managed AgentCore의 세 가지이며, 모두 같은 다중 에이전트 아키텍처를 공유한다.
• 글은 실행 흐름, 모델 선택, 안정적 운영, AI 생성 코드의 안전한 실행, 모니터링이라는 다섯 과제를 제시한다. 운영 구성에는 Amazon Bedrock AgentCore, AWS Fargate와 Application Load Balancer, Amazon DynamoDB·Amazon SNS·Amazon Cognito가 포함되지만, 제공된 본문은 Planner의 분석 계획 예시 중간에서 끝난다.

🧩 주요 포인트

1. 프롬프트만으로 실행·검증을 통제하기 어렵다는 문제 → Graph로 에이전트 간 순서를 정의하고 Agents-as-Tools로 전문 작업을 호출하는 구조가 핵심이다.
2. 라우팅·계획·실행의 요구 수준이 다르다는 점 → Claude Haiku·Opus·Sonnet을 역할별로 배정해 비용과 추론 역량을 작업에 맞춘다.
3. 공통 에이전트 구조와 세 가지 배포 방식 → 개발에서 검증한 에이전트를 프로덕션으로 이어가되, 세션 격리·코드 실행 환경·운영 감시는 별도의 인프라 과제로 다룬다.

🧠 상세 정리

1. 프로토타입을 넘어설 때 드러나는 실행 통제 문제

원문은 오픈소스 프레임워크와 클라우드 서비스 덕분에 에이전트 시제품을 며칠 만에 만들 수 있지만, 실제 업무에 투입하면 다른 문제가 시작된다고 설명한다. 에이전트가 업무 논리를 따르지 않거나 검증 단계를 건너뛰고 예외 상황을 놓치는 문제는 프롬프트 수정, 예시 추가, 모델 교체 뒤에도 반복될 수 있다는 것이다. 그 이유로 에이전트가 고정된 명령 순서를 실행하기보다 문맥에 따라 스스로 판단한다는 특성을 들며, 사고 방식과 검증 시점, 실패 시 행동까지 설계해야 한다고 주장한다. AWS Solutions Architecture 팀은 이러한 과제에 대응하기 위해 Deep Insight를 구축했으며, 이 글을 포함한 3부작에서 Anthropic이 제안한 Context Engineering 기법의 적용 경험과 구현상의 절충, AWS 운영 경험을 공유한다고 소개한다.

2. Deep Insight의 입력과 승인 기반 분석 과정

Deep Insight는 CSV 파일과 자연어 요청을 받아 전문 에이전트들이 데이터를 불러오고 분석하며, 차트를 생성하고 계산을 검증한 뒤 인용을 갖춘 DOCX 보고서를 만드는 시스템이다. 시연에서는 가상의 식품 기업 Yummy Food의 광고 데이터인 yummy-food-market.csv와 열 정의 파일 column_definitions.json을 입력하고, 영업·마케팅 관점의 분석과 차트, 인사이트, 보고서 생성을 요청한다. 시스템은 곧바로 분석을 실행하는 대신 먼저 분석 계획을 작성해 사용자에게 제시하고, 승인을 받은 뒤 작업을 진행한다. 결과물은 인용이 있는 버전과 없는 버전의 DOCX 보고서 두 가지 및 PNG 차트이며, 웹 시연은 데이터 업로드부터 계획 검토, 실시간 스트리밍, 완성된 보고서 다운로드까지의 흐름을 보여준다고 설명한다.

3. 개발부터 프로덕션까지 이어지는 세 가지 배포 방식

Deep Insight는 전체 설치 가이드와 함께 GitHub에 공개되어 있으며, 개발과 프로덕션 요구에 맞춘 세 가지 배포 방식을 제공한다. Self-Hosted는 로컬 CLI에서 실행하고 모든 에이전트·프롬프트·워크플로 코드를 직접 다룰 수 있어 빠른 반복 개발에 적합하며, 원문은 설정에 약 10분이 걸린다고 설명한다. Web은 브라우저에서 데이터 업로드, 사람의 개입을 통한 분석 계획 검토, 보고서 다운로드를 지원해 코드를 작성하지 않는 사용자도 접근할 수 있게 한다. Managed AgentCore는 Amazon Bedrock AgentCore 런타임에 에이전트를 배포하고 전체 시스템을 프라이빗 VPC 안에서 운영하며, 별도의 AWS Fargate에 사용자 정의 Code Interpreter를 둔다. 이 방식에서는 사용자별로 격리된 환경에서 에이전트가 동시에 실행되며, 세 방식 모두 같은 다중 에이전트 아키텍처를 공유하므로 개발에서 검증한 에이전트를 그대로 프로덕션에 배포할 수 있다고 설명한다.

4. 다섯 가지 운영 과제와 기술 구성의 대응 관계

원문은 프로덕션 다중 에이전트 시스템의 과제를 실행 흐름 제어, 역할별 LLM 선택, 안정적인 운영, AI 생성 코드 실행의 보안 문제 완화, 시스템 모니터링과 관리의 다섯 가지로 구분한다. 실행 흐름에는 Strands Agents SDK를, 모델 선택에는 Amazon Bedrock을 사용하며, 관리형 런타임과 모니터링·세션 격리·프라이빗 VPC 배포에는 Amazon Bedrock AgentCore를 연결한다. 코드 실행은 AWS Fargate와 Application Load Balancer를 통해 세션별 임시 샌드박스 컨테이너에서 격리하고, 사용자 정의 Code Interpreter를 사용하는 접근을 제시한다. 운영 관리에는 Amazon DynamoDB, Amazon SNS, Amazon Cognito를 활용한 관리자 대시보드와 실패 알림 체계를 제시하지만, 제공된 본문에서는 이 구성의 세부 구현까지 설명하지 않는다. 또한 코드와 보고서 내용을 모두 생성하는 특성 때문에 책임 있는 AI 통제도 후속 운영 설명에서 다룬다고 예고한다.

5. 독립된 문맥을 가진 8개 에이전트의 역할 분담

상세 아키텍처에서는 8개 에이전트가 각자의 독립된 문맥에서 전문 작업만 수행하고, 압축된 결과만 다음 단계에 전달해 하나의 결과물을 완성한다고 설명한다. 첫 번째 계층의 Coordinator는 요청을 분류하고 Planner는 작업을 단계로 나누며, Plan Reviewer는 사용자 피드백을 수집해 실행할 계획을 확정하는 과정에 참여한다. 두 번째 계층의 Supervisor는 계획에 따라 적절한 전문 에이전트를 호출하고, 세 번째 계층에서는 Coder가 분석 코드를 작성·실행하며 Validator가 계산을 검증한다. Reporter는 최종 보고서를 만들고 Tracker는 진행 상황을 추적하므로, 분석 실행과 계산 검증, 결과 문서화가 서로 다른 역할로 분리된다. 이러한 구조는 각 에이전트가 전체 작업 이력을 모두 떠안기보다 자신의 전문 작업에 집중하고 필요한 결과를 전달하도록 설계한 것이다.

6. Graph와 Agents-as-Tools로 결합한 실행 흐름

Deep Insight는 Strands Agents SDK의 두 패턴을 결합해 에이전트 간 이동 순서와 전문 작업 호출 방식을 함께 제어한다. Graph 패턴은 Coordinator에서 Planner, Plan Reviewer를 거쳐 Supervisor로 이어지는 실행 순서를 방향 그래프로 정의하고, 사용자가 수정을 요청하면 Planner로 되돌아가는 조건부 분기를 둔다. 원문은 다음 단계를 조건으로 결정하는 방식이 사람의 개입과 오류 처리처럼 복잡한 워크플로를 구성하기 쉽게 만든다고 설명한다. Agents-as-Tools 패턴에서는 Supervisor가 Coder, Validator, Reporter, Tracker를 필요할 때만 도구처럼 호출하며, 각 에이전트는 독립된 문맥에서 작업한 결과만 반환한다. 따라서 큰 흐름을 정하는 그래프와 전문 작업을 위임하는 호출 구조를 결합해, 전문성을 유지하면서 문맥 사용량을 줄이는 것이 설계의 핵심이다.

7. Coordinator의 요청 분류와 역할별 Claude 모델 선택

Coordinator는 사용자 요청의 진입점으로서 기본 인사에는 직접 응답하고, 데이터 분석처럼 복잡한 요청은 handoff_to_planner 표시를 통해 Planner로 전달한다. 라우팅 기준은 프롬프트에 담겨 있으며, 도구 사용이나 추론 또는 여러 단계의 사고가 필요한 요청은 Planner로 보내도록 한다. 구현 예시는 Coordinator를 그래프의 시작점으로 지정하고, 조건을 충족할 때 Planner로 이동하는 간선을 추가하는 방식으로 이 결정을 실행 흐름에 연결한다. 원문은 단순 분류 역할에 가벼운 Claude Haiku를 사용해 기본 인사에 Opus 수준의 비용을 들이지 않고 빠르게 응답하는 점을 주요 설계 결정으로 강조한다. 전체 모델 배정에서는 Amazon Bedrock을 통해 기본 라우팅에 Haiku, 계획 수립에 Opus, 실행에 Sonnet을 선택하며, 작업별 요구에 따라 모델의 비용과 역량을 맞추는 방향을 제시한다.

8. Planner의 작업 분해와 제공된 본문의 범위

Planner는 본격적인 작업 전에 큰 요청을 작은 단계로 나누고 전문 에이전트들이 이를 하나씩 수행하게 해, 각 에이전트가 다루는 문맥을 작게 유지하는 역할을 맡는다. 계획 수립에는 Extended Thinking을 활성화한 Claude Opus를 사용하며, 에이전트별 구체적 작업을 체크리스트로 작성해 full_plan 변수에 저장하고 요청을 5~10개의 명확한 단계로 나눈다고 설명한다. Yummy Food 예시에서 Coder의 작업에는 데이터 구조 파악, 소비자 구매와 광고 채널·제품 범주 분석, 전환율·CPA·ROAS 계산, 5개 이상의 차트 생성, 마케팅 인사이트 도출과 검증용 계산 메타데이터 생성이 포함된다. 이어지는 Validator 작업에는 검증 대상 식별, 원본 데이터의 직접 로딩과 재계산, 채널별 성과 지표 검증이 제시되지만, 제공된 본문은 해당 목록 중간에서 끝난다. 따라서 전체 계획의 나머지 항목이나 후속 운영 설명의 구체적인 구현·성과는 이 자료만으로 확인할 수 없다.

🧾 핵심 주장 / 시사점

• Deep Insight의 설계는 에이전트의 판단에 모든 실행 순서를 맡기기보다, 에이전트 간 이동과 사용자 승인 지점을 구조로 정의하는 데 무게를 둔다.
• 독립된 문맥, 압축된 결과 전달, 실행 전 작업 분해는 전문 에이전트가 처리해야 할 정보의 범위를 줄인다는 공통 목적을 가진다.
• 원문은 운영 과제와 대응 기술을 제시하지만 제공된 범위에는 세부 운영 구현이나 정량적 성과 검증이 없어, 설계 설명과 검증된 성과를 구분해 읽을 필요가 있다.

✅ 액션 아이템

• Strands Agents SDK의 Graph 패턴과 Agents-as-Tools 패턴을 활용한 실행 순서·사용자 승인·전문 작업 호출 구조 검토.
• 기본 라우팅·계획 수립·실행 요구에 따른 Claude Haiku·Opus·Sonnet의 역할별 배정 검토.
• 세션 격리와 프라이빗 VPC 요구를 기준으로 Self-Hosted·Web·Managed AgentCore 배포 방식의 적합성 비교.

❓ 열린 질문

• Strands Agents SDK의 Graph 패턴에서 사용자 승인과 검증 단계는 어떤 조건으로 연결되는가?
• Claude Haiku·Opus·Sonnet의 역할별 배정은 비용과 결과 품질에 어느 정도 영향을 주는가?
• 제공된 본문에서 상세 설명이 끝나지 않은 Amazon Bedrock AgentCore와 AWS Fargate의 운영·격리 구성은 어떻게 구현되는가?