멀티 에이전트 시스템의 5가지 프로덕션 과제와 Deep Insight가 이를 해결한 방법

멀티 에이전트 시스템을 구축하는 것은 이제 꽤 간단합니다. 이를 프로덕션에 배포하는 것이야말로 진짜 도전이 시작되는 지점입니다. 오픈 소스 프레임워크와 클라우드 서비스 덕분에 며칠 안에 에이전트를 세팅할 수 있습니다. 도구 호출 몇 번, 프롬프트 몇 줄이면 인상적으로 보이는 무언가를 만들 수 있습니다. 하지만 팀이 파일럿을 넘어 실제 비즈니스 애플리케이션으로 나가려는 순간, 익숙한 벽에 부딪히게 됩니다. 에이전트를 프로덕션에 넣어본 적이 있다면 다음과 같은 좌절이 낯설지 않을 것입니다:

에이전트가 왜 우리의 비즈니스 로직을 따르지 않고, 검증 단계를 건너뛰거나, 엣지 케이스를 놓칠까?

프롬프트를 조정하고, 예시를 더 추가하고, 모델을 바꿔봐도 같은 문제가 계속 반복됩니다. 그 이유는 에이전트가 고정된 순서의 지시를 따르지 않기 때문입니다. 에이전트는 맥락에 기반해 스스로 판단합니다. 지시만으로는 부족합니다. 에이전트가 어떻게 사고하고, 언제 검증하며, 문제가 생겼을 때 무엇을 할지 설계해야 합니다. 바로 이 때문에 프롬프트 엔지니어링만으로는 벗어나 에이전트의 전체 인지 아키텍처와 실행 흐름을 설계하는 것이 중요해졌습니다.

이러한 과제에 정면으로 대응하기 위해 AWS Solutions Architecture 팀은 다음을 구축했습니다 심층 인사이트, 프로덕션 수준의 멀티 에이전트 시스템입니다. 본 시리즈에서는 세 개의 포스트에 걸쳐 Deep Insight를 구축하면서 팀이 직접 얻은 교훈을 공유합니다. 우리는 Anthropic이 제안한 Context Engineering 기법(멀티 에이전트 아키텍처, 구조화된 노트 작성, human-in-the-loop 등)을 실제 프로덕션 환경에 어떻게 적용했는지 살펴봅니다. 또한 그 과정에서 마주한 트레이드오프(코드 포함)와 이 에이전트를 AWS에 배포하고 운영하며 얻은 운영상의 인사이트도 다룹니다.

블로그 시리즈 개요

• 파트 1: 멀티 에이전트 시스템의 5가지 생산 과제와 Deep Insight가 이를 해결한 방법.
• 2부: 컨텍스트 윈도우를 넘어서: Context Engineering 기법과 Deep Insight가 이를 적용한 방법.
• Part 3: 엔지니어링 실무에서의 하네스: Deep Insight를 dev에서 production으로 이전하기.

이 글은 3부작 시리즈의 Part 1입니다. 프로덕션 수준의 멀티 에이전트 시스템이 반드시 해결해야 하는 5가지 핵심 과제를 정의하고, 스택의 각 계층이 이를 어떻게 다루는지 다음 내용부터 보여줍니다: Strands Agents SDK 그리고 Amazon Bedrock 까지 Amazon Bedrock AgentCore, Application Load Balancer, 그리고 AWS Fargate. 2부와 3부에서는 Context Engineering과 프로덕션 배포를 다룹니다.

Deep Insight 소개

Deep Insight는 복잡한 데이터 분석을 자동화된 인사이트로 전환하는 멀티 에이전트 시스템입니다. CSV 파일과 자연어 프롬프트가 주어지면, 전문화된 에이전트들(Coordinator, Planner, Supervisor, Coder, Validator, Reporter, Tracker)의 계층 구조가 분석 작업에 협업으로 참여합니다. 이들은 함께 데이터를 로드하고, 분석을 수행하고, 차트를 생성하고, 계산을 검증하며, 인용이 포함된 전문 보고서(.docx)를 작성합니다.

우리는 이 아키텍처를 나중에 자세히 살펴볼 것입니다. 먼저 실제 작동 모습을 보겠습니다. 데모를 위해 가상의 식품 회사인 Yummy Food의 광고 데이터를 입력합니다(yummy-food-market.csv) 및 열 정의 파일(column_definitions.json)를 제공하고 프롬프트를 입력하세요: 이를 영업 및 마케팅 관점에서 분석하고, 차트와 인사이트를 생성한 뒤, .docx 보고서를 작성하십시오. Deep Insight는 분석 계획을 생성하여 사용자의 승인을 요청하고, 승인되면 분석을 실행합니다.

이어지는 Deep Insight 웹 데모 영상 은 데이터 업로드와 분석 계획 검토부터 실시간 스트리밍, 완성된 보고서 다운로드까지 전체 워크플로를 보여줍니다.

어떻게 사용해 볼 수 있나요?

Deep Insight는 GitHub 에 오픈 소스로 공개되어 있으며 전체 설정 가이드를 제공하고, 개발부터 프로덕션까지 아우르는 세 가지 배포 옵션을 제공합니다.

첫 번째는 Self-Hosted 버전으로, CLI를 통해 로컬에서 실행됩니다. 모든 에이전트, 프롬프트, 워크플로에 대한 코드 수준의 전체 접근 권한을 갖추고 신속한 반복 작업에 최적화되어 있습니다. 약 10분 만에 설정이 완료되어 개발에 적합합니다. (Self-Hosted 데모 영상은 YouTube.)

두 번째는 웹 버전으로, 코드를 작성하지 않고도 데이터 업로드, 분석 계획 검토(Human-in-the-Loop, HITL), 보고서 다운로드를 할 수 있는 브라우저 기반 UI로, 비개발자도 쉽게 사용할 수 있습니다. (앞선 데모 영상은 웹 버전이 작동하는 모습을 보여줍니다.)

세 번째는 Managed AgentCore 버전으로, 어떤 프레임워크나 모델로도 대규모 에이전트를 구축, 연결, 최적화할 수 있는 플랫폼인 Amazon Bedrock AgentCore로 구동되는 프로덕션 배포 옵션입니다. 이 버전은 Amazon Bedrock AgentCore의 기능인 AgentCore 런타임에 에이전트를 배포합니다. 시스템은 완전히 프라이빗 가상 프라이빗 클라우드(VPC) 내에서 실행되며, 사용자 지정 Code Interpreter는 AWS Fargate에 별도로 호스팅되고, 에이전트는 사용자별로 격리된 환경에서 동시에 실행됩니다. 세션 격리와 프라이빗 VPC 배포가 필요하다면 이것이 적합한 선택입니다. Part 3에서 배포 및 운영을 자세히 다룹니다.

세 가지 버전 모두 동일한 멀티 에이전트 아키텍처를 공유하므로, 개발 환경에서 검증된 에이전트를 그대로 프로덕션에 배포할 수 있습니다.

솔루션 개요

프로덕션 수준의 멀티 에이전트 시스템을 구축하는 일은 좋은 프롬프트만으로는 부족합니다. 에이전트가 어떻게 협업하는지, 어떻게 추론하는지, 어떻게 배포하는지, 코드를 어디서 안전하게 실행하는지, 운영 상태를 어떻게 모니터링하는지를 다루기 위해 적절한 기술 스택과 인프라가 필요합니다. Deep Insight는 이 다섯 가지 핵심 영역의 문제를 해결합니다. 에이전트가 코드와 보고서 콘텐츠를 모두 생성하기 때문에, Solution detail 2에서 프로덕션을 위한 책임 있는 AI 통제 방안도 다룹니다.

다음 아키텍처 다이어그램(그림 1)은 이를 한눈에 보여줍니다. 녹색 박스는 Strands Agents 멀티 에이전트 구조를 나타내며, 앞 표의 과제 1과 2를 다룹니다. 이에 대해서는 이어지는 Solution detail 1: Multi-agent system design 섹션에서 자세히 설명합니다. 다이어그램에 표시된 나머지 인프라 구성 요소는 과제 3, 4, 5를 다루며, 이는 Solution detail 2: Production deployment and operations에서 살펴봅니다.

그림 1: 솔루션 아키텍처

Solution detail 1: 멀티 에이전트 시스템 설계

Deep Insight는 8개의 에이전트가 협력하여 하나의 고품질 결과물을 만들어내는 멀티 에이전트 아키텍처를 사용합니다. 각 에이전트는 자체적인 독립 컨텍스트에서 작동하고, 전문 작업만 수행하며, 압축된 결과만 전달합니다.

그림 2: 멀티 에이전트 구조

코디네이터(Coordinator)는 사용자 요청을 라우팅하고, 플래너(Planner)는 작업을 개별 단계로 분해하며, 플랜 리뷰어(Plan Reviewer)는 사용자 피드백을 수집하고, 슈퍼바이저(Supervisor)는 계획에 따라 적절한 전문 에이전트를 호출합니다. 코더(Coder)는 데이터 분석 코드를 작성·실행하고, 밸리데이터(Validator)는 계산을 검증하며, 리포터(Reporter)는 최종 보고서를 생성하고, 트래커(Tracker)는 진행 상황을 추적합니다. 이를 세 개의 계층에 걸쳐 설명하겠습니다:

• [1번째 계층] 코디네이터 → 플래너 → 플랜 리뷰어: 요청 분석 및 실행 계획 수립.
• [2번째 계층] 슈퍼바이저: 전문 에이전트 오케스트레이션.
• [3번째 계층] 코더, 밸리데이터, 리포터, 트래커: 전문 작업 실행.

이러한 에이전트들 간의 실행 흐름을 제어하기 위해 Strands Agents SDK의 두 가지 핵심 패턴이 결합되었습니다. 첫째, Graph 패턴 은 에이전트들의 실행 순서와 흐름을 방향성 그래프로 정의합니다. 요청은 Coordinator, Planner, Plan Reviewer, 그 다음 Supervisor의 순서로 흐르며, 수정 요청 시 Planner로 되돌아가는 조건 분기가 있습니다. 조건에 따라 다음 단계를 결정하면 HITL 및 오류 처리 같은 복잡한 워크플로우를 간단하게 만들 수 있습니다. 둘째, Agents-as-Tools 패턴 은 Supervisor가 전문화된 에이전트(Coder, Validator, Reporter, Tracker)를 필요할 때에만 도구로 호출할 수 있게 합니다. 각 에이전트는 독립적인 컨텍스트에서 작업하고 결과만 반환하므로, 도메인 전문성을 유지하면서 컨텍스트 사용을 최소화합니다.

이 섹션에서는 이 아키텍처가 라우팅, 계획 수립, 오케스트레이션 문제를 어떻게 해결하는지 보여줍니다.

[1번째 레이어] Coordinator에서 Planner, 그리고 Plan Reviewer

이 레이어는 사용자 요청을 승인된 실행 계획으로 변환합니다.

1.1 Coordinator (라우팅): 모든 요청에 비용이 많이 드는 오케스트레이션이 필요한 것은 아닙니다

Coordinator는 사용자 요청의 진입점입니다. 기본적인 인사는 직접 처리하고, 데이터 분석과 같은 복잡한 작업은 handoff_to_planner 마커와 함께 Planner로 라우팅합니다.

핵심 설계 결정은 모델 선택입니다. Coordinator는 분류만 수행하므로 경량화된 Claude Haiku를 사용하여 기본 인사에 Opus 수준의 비용을 들이지 않으면서 빠른 응답을 제공합니다.

# builder.py: conditional edges for routing decisions
builder.set_entry_point("coordinator")
builder.add_edge("coordinator", "planner", condition=should_handoff_to_planner)

라우팅 조건은 Coordinator의 프롬프트에서 나옵니다. 도구, 추론 또는 다단계 사고가 필요한 모든 요청은 Planner로 전달됩니다.

1.2 Planner (계획 수립): 복잡한 분석은 실행 전에 분해가 필요합니다

Deep Insight의 멀티 에이전트 구조에서 Planner 에이전트는 에이전트들 간에 작업을 분배하는 중요한 역할을 합니다. 실질적인 작업이 시작되기 전에 큰 작업을 더 작은 단계로 나누고, 각 전문 에이전트가 한 번에 하나씩 실행하도록 하여 각 에이전트의 컨텍스트를 작게 유지합니다.

Planner는 Extended Thinking을 켠 Claude Opus 모델을 사용하여 분석 계획을 수립합니다. 계획을 각 에이전트에 할당된 구체적인 작업을 명시하는 [ ] 체크리스트 형식으로 구성하여 full_plan 변수에 저장합니다. 요청을 다음 예시와 같이 5~10개의 명확한 단계로 분해합니다:

## title
Yummy Food Consumer Purchase Patterns and Advertising Effectiveness Analysis Report

## steps

### 1. Coder: Comprehensive Data Analysis and Insight Generation
- [ ] Load all data files from './data/*' path and understand structure
- [ ] Analyze consumer purchase history (patterns, preferences, customer segments)
- [ ] Analyze advertising data by channel (cost, effectiveness, channel comparison)
- [ ] Category-level analysis (fresh food, convenience food, health food ad effectiveness)
- [ ] Calculate key business metrics (conversion rate, CPA, ROAS, etc.)
- [ ] Generate visualizations (5+ charts, consumer segment charts)
- [ ] Derive strategic marketing insights
- [ ] Generate calculation metadata (for validation)

### 2. Validator: Calculation Verification and Citation Metadata Generation
- [ ] Identify verification targets and extract filter calculations
- [ ] Load data files directly and perform recalculations
- [ ] Verify accuracy of per-channel performance metrics
- [ ] Validate data consistency of visuals and graphs
- [ ] Generate citation metadata (reference numbers for verified items)

### 3. Reporter: Marketing Analysis Report Generation
- [ ] Write report overview
- [ ] Create structured report using verified analysis results
- [ ] Insert visualizations and analysis sections
- [ ] Present marketing strategy recommendations and improvement proposals
- [ ] Generate professional marketing report in DOCX format

1.3 Plan Reviewer

Plan Reviewer는 계획을 사용자에게 제시하고 승인 또는 수정 피드백을 수집하는 HITL 노드입니다. 피드백이 있으면 계획을 수정하기 위해 Planner로 되돌아갑니다. 승인되면 작업을 Supervisor에게 전달합니다. 무한 루프를 방지하기 위해 최대 수정 횟수(MAX_PLAN_REVISIONS)가 설정되어 있습니다.

# builder.py: Plan Reviewer's bidirectional conditional edges
builder.add_edge("plan_reviewer", "planner", condition=should_revise_plan)
builder.add_edge("plan_reviewer", "supervisor", condition=should_proceed_to_supervisor)
builder.set_max_node_executions(25)

웹 버전에서 Plan Reviewer는 브라우저 모달을 표시하여 사용자가 계획을 읽고 승인하거나 수정 피드백을 입력할 수 있게 합니다. 300초 카운트다운이 끝나면 응답이 없을 경우 계획이 자동으로 승인됩니다.

그림 3: 웹 UI에서의 Plan Reviewer 에이전트 실행

계획 수립이 없으면 에이전트가 실행 시점에 모든 것을 결정하고, 중간 수정 시 이전 작업이 무효화되며, 사용자는 진행 상황을 전혀 볼 수 없습니다. Planner와 Plan Reviewer를 통해 사용자는 계획을 검토 및 수정하고, 진행 상황을 실시간으로 모니터링하며, 실패한 단계만 다시 실행할 수 있습니다.

[2번째 레이어] Supervisor (오케스트레이터): 전문화된 에이전트에는 지휘자가 필요합니다

Supervisor는 Planner의 full_plan 을 순서대로 실행하며, Layer 3 에이전트(Coder, Validator, Reporter, Tracker)를 Tool Use를 통해 자신에게 등록된 도구로 호출합니다.

# nodes.py: registering sub-agents as tools on the Supervisor
agent = strands_utils.get_agent(
    agent_name="supervisor",
    system_prompts=apply_prompt_template(prompt_name="supervisor", prompt_context={}),
    model_id=os.getenv("SUPERVISOR_MODEL_ID", os.getenv("DEFAULT_MODEL_ID")),
    prompt_cache_info=(True, "default"),
    tool_cache=True,
    tools=[coder_agent_tool, reporter_agent_tool, tracker_agent_tool, validator_agent_tool],
    streaming=True,
)

Supervisor의 시스템 프롬프트는 엄격한 워크플로우 규칙을 정의합니다:

• 필수 실행 순서: Coder, Tracker, Validator, Tracker, Reporter, Tracker: 각 에이전트가 실행된 후 Tracker가 호출되어 진행 상황을 추적하므로, Supervisor가 전체 작업 상태를 관리할 수 있습니다.
• 섹션 완료 규칙: Supervisor는 현재 에이전트의 모든 체크리스트 항목이 [x]로 표시될 때까지 다음 에이전트로 넘어가지 않습니다.
• 컨텍스트 보존: Supervisor는 clues와 full_plan 변수를 각 도구 에이전트에 전달하여 전체 컨텍스트를 유지하고 정보 손실을 방지합니다.

[3번째 계층] Coder, Validator, Reporter, Tracker: 분업이 품질을 끌어올립니다

각 Layer 3 에이전트(Coder, Validator, Reporter, Tracker)는 다음과 같이 래핑되며 PythonAgentTool Supervisor로부터 Tool Use 호출을 받습니다. 각 에이전트는 자체적인 시스템 프롬프트, 모델 ID, 도구 세트를 갖는 독립적인 Agent() 인스턴스로 Strands SDK에서 생성됩니다.

Supervisor는 Planner의 체크리스트를 바탕으로 다음 순서로 도구 사용(Tool Use) 호출을 실행합니다:

1. Coder – 데이터를 로드하고, 분석 코드를 작성·실행하며, PNG 차트를 생성하고, 결과를 all_results.txt에 누적한 뒤 calculation_metadata.json 검증을 위해 남겨둡니다.
2. Tracker (1차) – 완료된 체크리스트 항목을 [ ]에서 [x]로 업데이트하며, Supervisor는 이를 통해 진행 여부를 판단합니다.
3. Validator – 원본 데이터를 기준으로 calculation_metadata.json 의 각 계산을 다시 수행합니다. 0.01 이내의 오차는 통과하고, 불일치는 표시됩니다. 검증된 계산 결과는 citations.json 에 기록되어 Reporter가 인용합니다.
4. Tracker (2차) – Validator의 완료 상태를 체크리스트에 반영합니다.
5. Reporter – all_results.txt와 citations.json 을 읽어 최종 DOCX 보고서를 인용 포함 버전과 인용 제외 버전, 두 가지 버전으로 생성합니다.
6. Tracker (3차) – 모든 작업의 최종 완료 상태를 반영합니다.

Tracker는 모든 에이전트가 실행된 후에 동작하여 Supervisor가 진행 상황을 추적하고 완료 규칙(모든 항목이 [x]가 될 때까지 다음 단계로 넘어가지 않음)을 강제할 수 있게 합니다. 도구 없이 LLM 추론만으로 체크리스트를 업데이트하기 때문에 오버헤드가 거의 없습니다.

에이전트별 LLM 모델 구성

Deep Insight는 각 에이전트의 역할에 맞게 모델과 설정을 조정합니다. 이는 단순한 모델 선택이 아니라 비용과 품질을 최적화하기 위한 아키텍처적 결정입니다.

슈퍼바이저, 코더, 리포터 에이전트는 프롬프트 캐싱(Prompt Caching)을 사용하여 시스템 프롬프트와 도구 정의를 캐시함으로써, 반복 호출 시 입력 토큰 비용을 최대 90 퍼센트까지 절감합니다. 코디네이터는 한 번만 실행되며, 검증기와 트래커는 매번 다른 컨텍스트로 실행되기 때문에 캐싱이 효과가 없어 비활성화 상태로 유지됩니다. 이러한 선택적 캐싱 전략은 의도적인 비용/성능 트레이드오프입니다.

솔루션 상세 2: 프로덕션 배포 및 운영

Solution detail 1이 정의한 것이 시스템이 무엇을 하는가라면, 이 섹션은 시스템이 어디서 어떻게 안전하게 실행되는지를 정의합니다. 여기 이후의 모든 내용은 프로덕션 운영을 위한 인프라 결정을 다룹니다. 구체적으로 이 섹션은 LLM이 생성한 코드의 보안 실행 환경과 팀을 위한 운영 가시성을 다룹니다.

1. 코드 실행: LLM이 생성한 코드에는 보안 실행 환경이 필요합니다

Coder 에이전트는 데이터 분석을 위해 Python을 작성하고 실행합니다. Self-Hosted 버전에서는 다음을 통해 로컬에서 실행되지만 subprocess.run(), 프로덕션(AgentCore)에서는 보안과 격리가 필수적입니다. LLM이 생성한 코드를 프로덕션 서버에서 직접 실행하는 것은 위험합니다. 모델이 시스템 파일을 삭제하거나, 무한 루프로 리소스를 소진하거나, 다른 사용자의 분석 데이터에 접근할 수 있기 때문입니다. Deep Insight는 AWS Fargate와 ALB를 통한 세션별 휘발성 컨테이너로 이 문제를 해결합니다. 이러한 구성 요소들은 격리되어 실행되지 않습니다. 그림 1에서 보여지듯, AgentCore 런타임, ALB, Fargate 태스크는 모두 동일한 프라이빗 VPC 내에서 실행됩니다. VPC 엔드포인트는 퍼블릭 인터넷을 거치지 않고 이들을 Amazon Simple Storage Service(Amazon S3), Amazon Bedrock, Amazon Elastic Container Registry(Amazon ECR)에 연결합니다. 보안 그룹은 어떤 구성 요소가 Code Interpreter 컨테이너에 접근할 수 있는지 제한합니다. AWS Identity and Access Management(IAM) 역할은 각 구성 요소를 필요한 AWS 리소스로만 범위를 한정합니다. Amazon CloudWatch는 Amazon Bedrock AgentCore의 기능인 AgentCore Observability로부터 컨테이너 로그와 관측 데이터를 수집합니다.

• 사용자 정의 컨테이너 Docker 이미지: 멀티 에이전트 시스템을 위한 폰트, 시스템 라이브러리, Python 패키지가 사전 최적화된 샌드박스입니다.
• 컨테이너 격리: 각 분석 세션은 직접적인 인터넷 접근이 없는 프라이빗 VPC 서브넷의 독립적인 Fargate 컨테이너를 받습니다.
• 2단계 실행: LLM이 생성한 코드는 base64로 인코딩되어 HTTP로 전송되고, 파일에 기록되며(Step 1), 그 후 subprocess를 통해 실행됩니다(Step 2).
• 세션 어피니티: ALB 스티키 세션 쿠키가 코드를 여러 번 실행하더라도 에이전트가 동일한 컨테이너로 다시 라우팅되도록 합니다.
• 아티팩트 관리: 차트, 보고서, 로그는 분석이 완료되면 Amazon S3에 업로드됩니다. 컨테이너는 1시간 후 자동으로 종료됩니다.

컨테이너 격리는 인프라를 보호하지만, 에이전트가 생성하는 내용을 규율하지는 않습니다. Validator 에이전트는 계산을 재검증합니다. 하지만 업로드된 데이터에 숨겨진 프롬프트 인젝션 지시문을 탐지하거나, LLM이 생성한 텍스트에서 유해하거나 근거 없는 콘텐츠를 선별하지는 않습니다. 프로덕션 배포에서는 책임 있는 AI 제어 수단으로 Amazon Bedrock Guardrails를 추가할 것을 권장합니다. 사용자 프롬프트와 업로드된 데이터에 콘텐츠 필터와 프롬프트 공격 탐지를 적용하고, 에이전트 출력에 맥락적 근거 확인(contextual grounding check)을 적용하여 보고서 텍스트가 원본 데이터와 검증된 계산에 근거하도록 하십시오.

2. 운영 및 모니터링: 팀에는 가시성이 필요합니다

프로덕션 시스템은 코드만으로 완성되지 않습니다. 팀은 시스템 상태를 평가하고, 문제를 진단하고, 결과를 검토해야 하므로, Deep Insight는 Web UI와 Ops 대시보드를 제공합니다.

Web UI (deep-insight-web)

AgentCore 네이티브 프로토콜(AgentCore Native Protocol)을 통해 백엔드와 통신하는 FastAPI 기반 웹 인터페이스입니다.(boto3.invoke_agent_runtime())을 통해 백엔드와 통신하는 FastAPI 기반 웹 인터페이스입니다. 사용자는 데이터를 업로드하고 프롬프트를 입력한 후, Server-Sent Events(SSE) 스트리밍을 통해 진행 상황을 모니터링합니다. 플랜이 생성되면 모달을 통해 사용자가 승인하거나 수정 피드백을 줄 수 있습니다(HITL). 완성된 보고서는 직접 다운로드할 수 있습니다. 한국어와 영어가 모두 지원됩니다.

그림 4: Deep Insight 웹 버전 스크린샷

Ops 대시보드 (deep-insight-web/ops)

Ops 대시보드는 선택 사항입니다. Deep Insight는 이것 없이도 잘 작동하지만, 필요한 팀을 위해 다음 기능을 추가합니다:

• 태스크 추적: 상태, 토큰 사용량, 경과 시간을 포함한 모든 분석 태스크 지표가 Amazon DynamoDB에 기록됩니다.
• 장애 알림: 분석이 실패하면 Amazon SNS를 통해 관리자에게 즉시 이메일이 전송됩니다.
• 관리자 대시보드: 전용 관리자 대시보드는 Amazon Cognito를 통한 JSON Web Token(JWT) 인증으로 보호되어 안전한 태스크 모니터링을 제공합니다.

그림 5: Deep Insight Ops 대시보드 스크린샷

그림 6: Deep Insight Ops 대시보드 상세 보기

Deep Insight 아키텍처 확장

Deep Insight의 멀티 에이전트 아키텍처는 데이터 분석 보고서 생성이라는 단일 도메인에 국한되지 않습니다. 다음 두 가지 예는 계층적 오케스트레이션 설계 원칙이 전혀 다른 도메인에서도 여전히 효과적임을 보여줍니다.

사례 1: LG전자: Agentic AI 기반 마케팅 인사이트 추출 시스템

LG전자 국내영업본부는 Deep Insight와 동일한 멀티 에이전트 아키텍처를 기반으로 ChatInsight를 구축했습니다. 이전에는 데이터 분석 요청에 2–3주가 걸렸고 마케터와 데이터 사이언티스트 사이에서 의도가 손실되었습니다. Coordinator는 복잡도에 따라 라우팅하고, Planner는 태스크를 추적하며, Supervisor는 Coder와 Reporter를 오케스트레이션하고, 에이전트 간 상태는 all_results.txt 파일을 통해 누적으로 전달됩니다. 3일이 걸리던 분석은 이제 30분이 걸리며, 이는 288배의 생산성 향상입니다. SQL을 모르는 마케터도 에이전트가 데이터를 탐색하고 전략을 제안하도록 할 수 있습니다(자세한 내용은 AWS Tech Blog의 LG전자 Agentic AI 인사이트 추출 시스템).

그림 7: LG전자 Agentic AI 마케팅 인사이트 시스템 아키텍처

사례 2: TechRecon: AI 기반 기술 정찰 에이전트(re:Invent 2025)

AWS re:Invent 2025(세션 SNR203)에서 발표된 TechRecon은 Deep Insight의 아키텍처를 기술 전략에 적용한 사례입니다. 기업과 산업 분야가 주어지면 Researcher가 기술 트렌드를 수집하고, Coder가 분석하며, Validator가 검증하고, Reporter가 Landscape Analysis와 Technical Position Paper를 작성합니다. 이 아키텍처는 Deep Insight와 거의 동일하며, Strands Agents SDK의 Graph 패턴과 Extended Thinking, Prompt Caching으로 구축되었고 Researcher가 Coder를 대신해 기본 실행 에이전트로 동작합니다. 이는 이 설계가 범용 패턴임을 보여줍니다. 에이전트의 역할과 프롬프트만 바꾸면 동일한 오케스트레이션 구조로 전혀 다른 문제를 해결할 수 있습니다.

그림 8: TechRecon 결과

(자세히 보기: TechRecon GitHub | AWS re:Invent 세션 영상)

결론

프로덕션에서 동작하는 에이전트를 만드는 것은 모델 성능의 문제가 아니라 아키텍처의 문제입니다. Deep Insight는 검증된 해답을 제시합니다:

• 워크플로 관리: Strands Agents SDK의 Graph 패턴이 에이전트 간 실행 순서를 정의하고 HITL 분기를 구현하며, Agents-as-Tools 패턴을 통해 Supervisor는 필요할 때만 전문 에이전트를 호출합니다.
• 추론 엔진: 비용과 품질을 최적화하기 위해 Amazon Bedrock의 Claude 모델을 역할별로 할당합니다(먼저 Haiku, 다음으로 Opus, 그다음 Sonnet).
• 배포: Amazon Bedrock AgentCore는 세션 격리, 프라이빗 VPC 배포, OpenTelemetry 관측성을 갖춘 관리형 런타임을 제공합니다.
• 코드 실행: Application Load Balancer와 Fargate 기반의 Amazon Elastic Container Service(Amazon ECS)를 통해 LLM이 생성한 코드의 실행을 세션별 임시 샌드박스 컨테이너로 격리하여, 시스템 파일 접근, 리소스 고갈, 의도치 않은 데이터 노출과 같은 보안 문제를 방지합니다.
• 운영: Web UI의 SSE 스트리밍과 운영 대시보드(DynamoDB + Cognito + SNS)가 팀 전체에 가시성을 제공합니다.

LG전자의 마케팅 인사이트 시스템과 re:Invent 2025의 TechRecon 사례는 이러한 설계 원칙을 검증했습니다.

2부에서는 이 아키텍처 위에서 컨텍스트 윈도우 한계를 극복하기 위한 네 가지 계층의 Context Engineering 기법, 즉 아키텍처 수준의 격리부터 프롬프트 설계, 도구 최적화, 검증 안전장치까지 살펴보고, Anthropic의 엔지니어링 연구와 우리의 접근 방식을 비교합니다.

Deep Insight는 오픈 소스입니다. 코드를 살펴보고 여러분의 도메인에 맞게 확장해 보세요.

• GitHub
• 워크숍: Deep Insight Workshop(영어 | 한국어)

저자 소개