Kwangmin Kim - AWS Deep Insight Part 1 — 5 가지 문제와 8 에이전트 3 레이어 아키텍처

1 이 글의 위치와 출처

이 글은 24-Agent-Architecture 시리즈의 여섯 번째 하네스 분석 이며, AWS Deep Insight 시리즈 3 부작 중 Part 1 단독 분석이다.

번호	주제	자료 성격
31번	Prompt · Context · Harness 세 층위 정의	학술 정의
30번	Claude Code vs Copilot CLI 5 대 축 비교	본인 통제 실험
32번	AGENT_GUIDE 체계 3 층 해부, Cross-cutting Concern	자체 체계 분석
33번	산업 사례 카탈로그	저널리즘 2 차 자료
34번	AWS Deep Insight Part 3 (인프라) 단독 분석	AWS 공식 1 차 자료
35번 (이 글)	AWS Deep Insight Part 1 (시스템 아키텍처) 단독 분석	AWS 공식 1 차 자료

출처와 범위 명시

1 차 자료: AWS 공식 기술 블로그 “프로덕션 Multi-Agent 시스템이 해결해야 할 5 가지 문제 – Deep Insight 아키텍처로 배우는 실전 설계” (Yoonseo Kim, Jesam Kim, Jiyun Park, Kyutae Park, Gonsoo Moon, 곽영화 / 2026.4.1 발행 / Amazon Bedrock, AgentCore, Fargate, Strands Agents)
시리즈 위치: AWS 가 공개한 3 부작 중 Part 1 (시스템 아키텍처) 단독 분석. Part 3 (인프라) 는 34번 포스트, Part 2 (Context Engineering 기법) 는 추후 36번 포스트 예정
34번과의 관계: Part 3 가 다룬 인프라 결정 (코드 실행 분리·S3 외부화·VPC 격리) 은 본 글의 솔루션 상세 2 영역의 세부 확장 에 해당한다. 본 글은 그 인프라가 무엇을 위해 만들어진 지를 시스템 설계 차원에서 답한다
Part 2 미참조 영역: Note-taking, 파일 외부화, Skills, Prompt Caching 의 구체 알고리즘은 Part 2 영역으로, 본 글에서는 결과 (예: 캐싱으로 토큰 비용 90% 절감) 만 일반화해 다룸
자료 출처: GitHub aws-samples/sample-deep-insight 에 전체 오픈소스로 공개됨

2 왜 Part 1 이 별도로 필요한가

34번 포스트는 Part 3 의 인프라 결정 (AgentCore + Fargate + S3 + VPC) 만 다뤘다. 그러나 인프라는 무엇을 위해 만든 것인지 라는 상위 설계 의도가 빠지면 불완전한 그림이 된다.

2.1 34번이 답하지 않은 질문

질문	34번에서의 처리	Part 1 의 답
왜 Multi-Agent 인가, 단일 Agent 면 안 되나	다루지 않음	5 가지 문제 정의 + 8 에이전트 3 레이어 구조
8 개 에이전트의 역할 분담은 어떻게 결정됐나	“Planner / Coder / Validator / Reporter” 만 등장	Coordinator · Plan Reviewer · Supervisor · Tracker 까지 8 개 전체 역할 명시
에이전트별 모델 선택의 근거는	“Sonnet 4.6 메인 + Haiku 4.5 일부” 만 언급	역할별 Haiku/Opus/Sonnet 매핑 + Extended Thinking + Prompt Caching 전략
같은 아키텍처가 다른 도메인에도 통용되는가	다루지 않음	LG전자 ChatInsight (288 배), TechRecon (re:Invent 2025) 사례

즉 Part 1 은 시스템 설계 의도, Part 3 는 그 설계를 인프라로 구현하는 방법 의 관계다. 두 글이 합쳐져야 Deep Insight 의 전체 그림이 완성된다.

2.2 31~33번 시리즈와의 관계

시리즈 포스트	Part 1 이 보강하는 것
31번 동심원	Multi-Agent Orchestration 층이 Harness 층 위로 추가됨을 사례 검증
33번 누비다 3 AI 분리	8 에이전트 3 레이어 — 더 세분화된 분리 사례
33번 Anthropic 가축 모델	“각 에이전트 = 가축, 망가지면 교체” 의 실제 구현
33번 OpenAI 7 도구 (`AGENTS.md`, Linter, 리뷰 자동화)	Validator + Tracker 에이전트가 리뷰 자동화 + 진행 추적의 역할

3 Deep Insight 시스템 개요

3.1 입출력 정의

항목	내용
입력	CSV 데이터 파일 + 컬럼 정의 JSON + 자연어 분석 프롬프트
출력	DOCX 보고서 (인용 포함 / 미포함 2 종) + 차트 그래프 (PNG)

3.2 데모 시나리오

가상의 식품 판매 기업 Moon Market 의 신선식품 판매 데이터 (moon-market-fresh-food-sales.csv) 를 분석한 사례가 공식 데모로 공개됐다.

프롬프트: "세일즈 및 마케팅 관점으로 분석을 해주고, 차트 생성 및 인사이트도
          뽑아서 docx 파일로 만들어줘"

→ Deep Insight 가 분석 계획 생성 → 사용자 승인 (HITL) → 데이터 분석 →
  최종 DOCX 보고서 + 차트 PNG 출력

3.3 3 가지 배포 옵션

같은 Multi-Agent 아키텍처 위에 3 가지 배포 모드가 제공된다.

옵션	환경	적합 사용처	Part 3 (34번) 와의 관계
Self-Hosted	로컬 CLI, 약 10 분 설정	빠른 반복 개발·테스트	34번이 분석한 인프라 결정 이전의 출발점
Web	브라우저 UI, FastAPI + SSE	비개발자·비즈니스 유저	HITL 모달·분석 진행 스트리밍
Managed AgentCore	100% Private VPC + AgentCore Runtime + Fargate	엔터프라이즈 (보안·확장성)	34번 분석의 본 영역

세 옵션이 동일한 Multi-Agent 아키텍처 를 사용한다는 점이 핵심이다. 개발 환경에서 검증한 에이전트를 그대로 프로덕션에 배포할 수 있다. 이 통일성이 Deep Insight 설계의 핵심 강점 중 하나다.

4 5 가지 핵심 문제 — 활용 기술 매핑

Part 1 은 프로덕션 Multi-Agent 시스템이 반드시 해결해야 할 문제를 5 가지로 정의한다.

#	문제	활용 기술	방법 요약
1	멀티 에이전트 간 실행 흐름 제어	Strands Agents SDK	Graph 패턴 + Agents-as-tools 패턴
2	에이전트별 LLM 모델 선택	Amazon Bedrock	역할별 Claude 모델 (Haiku · Opus · Sonnet)
3	안정적 운영	Amazon Bedrock AgentCore	관리형 런타임 + 세션 격리 + Private VPC
4	LLM 생성 코드 실행의 보안 위험	AWS Fargate + ALB	세션별 임시 샌드박스 컨테이너
5	시스템 모니터링·관리	DynamoDB + SNS + Cognito	작업 추적 + 장애 알림 + 인증

4.1 33번 카탈로그와의 매핑

이 5 문제는 33번에서 정리한 산업 사례 패턴과 직접 매핑된다.

Part 1 의 5 문제	33번 카탈로그 매핑
1. 실행 흐름 제어	Anthropic 가축 모델 (역할별 분리) + 누비다 3 AI 분리
2. 모델 선택	OpenAI Project 1M 의 “역할별 도구” 사상
3. 안정적 운영	OpenAI 7 도구 중 “관측 가능성”
4. 코드 실행 보안	OpenAI 7 도구 중 “Worktree” (격리 실행)
5. 모니터링·관리	OpenAI 7 도구 중 “Repository 문서화 + 관측 가능성”

산업 카탈로그(33번)에서 추상으로 정리된 5 가지 트렌드가 하나의 시스템에서 5 가지 기술 결정 으로 통합 구현된다.

4.2 31번 동심원과의 매핑

5 문제 각각이 31번 동심원 어느 층의 문제인지 표시한다.

문제	31번 층위
1. 실행 흐름 제어	Orchestration (33번 5 층 갱신 모델)
2. 모델 선택	Harness (모델·환경 결정)
3. 안정적 운영	Harness (런타임)
4. 코드 실행 보안	Harness (Sandbox)
5. 모니터링·관리	Harness (관측 가능성)

5 가지 중 4 가지가 Harness 층 에 속하고 1 가지가 Orchestration 층이다. Prompt 와 Context 층은 Part 2 가 별도로 다루는 것이 자연스럽다 (36번 포스트 예정).

5 솔루션 1: Multi-Agent 시스템 설계 — 8 에이전트 3 레이어

5.1 전체 구조

Deep Insight 는 총 8 개 에이전트 가 3 레이어 로 협업하는 멀티에이전트 아키텍처다.

┌─────────────────────────────────────────────────────────────┐
│ Layer 1 — 요청 분석 및 실행 계획 수립                           │
│   Coordinator  →  Planner  →  Plan Reviewer (HITL)            │
│   (Haiku)         (Opus)         (사용자 승인)                  │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│ Layer 2 — 전문 에이전트 오케스트레이션                          │
│   Supervisor (Sonnet)                                         │
│     └─ Tool Use 로 Layer 3 에이전트 호출                       │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│ Layer 3 — 전문 작업 실행                                       │
│   Coder         Validator      Reporter      Tracker          │
│   (Sonnet)      (Sonnet)       (Sonnet)      (Sonnet)         │
│   ↓             ↓              ↓             ↓                │
│   분석 코드     계산 검증       DOCX 작성    체크리스트 갱신     │
└─────────────────────────────────────────────────────────────┘

각 에이전트는 독립적인 context 에서 전문 영역의 작업만 수행하고, 압축된 결과만 다음 에이전트에게 전달한다. 이 격리가 전체 시스템 context 사용량을 최소화하면서도 전문성을 유지하는 핵심이다.

5.2 Layer 1 — Coordinator → Planner → Plan Reviewer

5.2.1 Coordinator (라우팅) — 모든 요청에 비싼 오케스트레이션이 필요하지는 않다

Coordinator 는 사용자 요청의 진입점이다. 다음 두 경로로 분기한다.

요청 유형	처리
단순 인사말·자기소개	직접 응답
데이터 분석·복잡 작업	`handoff_to_planner` 마커를 응답에 포함 → Planner 라우팅

핵심 설계 결정 — 모델 선택: Coordinator 는 빠른 분류만 수행하므로 가장 경량인 Claude Haiku 를 사용한다. 단순 인사말에 Opus 급 비용을 지출하는 낭비를 방지하고 사용자에게 빠른 응답을 제공하기 위함이다.

# builder.py — 조건부 엣지로 라우팅 결정
builder.set_entry_point("coordinator")
builder.add_edge("coordinator", "planner", condition=should_handoff_to_planner)

5.2.2 Planner (계획 수립) — 복잡한 분석은 실행 전에 분해가 필요하다

Planner 는 사용자 요청을 받아 5~10 개의 명확한 단계 로 분해하고, 각 단계를 어느 전문 에이전트에 배정할지 명시한다. 결과는 [ ] 체크리스트 형식의 full_plan 변수로 저장된다.

모델 선택: Claude Opus + Extended Thinking (확장 사고, 약 8192 토큰) 활성화. 심층 사고가 필요한 계획 수립이라 비용이 비싸도 최고 품질을 우선한다.

full_plan 의 실제 형태 (Moon Market 데모 인용):

## title
Yummy Food 소비자 구매 패턴 및 광고 효과 분석 보고서

## steps

### 1. Coder: 종합 데이터 분석 및 인사이트 도출
- [ ] './data/*' 경로의 모든 데이터 파일 로드 및 구조 파악
- [ ] 소비자 구매 이력 데이터 분석 (구매 패턴, 선호도, 고객 시그먼트)
- [ ] 매체별 광고 데이터 분석 (비용, 효과, 채널 비교)
- [ ] 카테고리별 분석 (신선식품, 간편식, 건강식품 광고 효과)
- [ ] 핵심 비즈니스 지표 계산 (전환율, CPA, ROAS 등)
- [ ] 시각화 생성 (차트 5 개 이상, 소비자 시그먼트 차트)
- [ ] 마케팅 관점의 전략적 인사이트 도출
- [ ] 계산 메타데이터 생성 (검증용)

### 2. Validator: 계산 검증 및 인용 메타데이터 생성
- [ ] 검증 대상 식별 및 필터 계산 추출
- [ ] 데이터 파일을 직접 로드하여 재계산 수행
- [ ] 채널별 성과 지표 정확도 검증

이 체크리스트가 이후 Supervisor 의 실행 기준이 된다. 계획이 명시적인 텍스트 데이터 라는 점이 중요하다 — Tracker 가 매 단계 후 [x] 로 갱신할 수 있는 구조가 여기서 만들어진다.

5.2.3 Plan Reviewer (HITL) — 사용자 검토 노드

Plan Reviewer 는 생성한 계획을 사용자에게 보여주고 승인 또는 수정 피드백을 받는 HITL (Human-in-the-Loop) 노드다.

동작	처리
사용자 승인	Supervisor 로 작업 이관
사용자 수정 요청	Planner 로 되돌아가 계획 재작성
무한 루프 방지	`MAX_PLAN_REVISIONS` 로 최대 수정 횟수 제한
응답 없음	카운트다운 타이머 (300 초) 후 자동 승인

# builder.py — Plan Reviewer 의 양방향 조건부 엣지
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)

Web 버전에서는 Plan Reviewer 가 브라우저 모달 창을 표시하여 사용자가 계획을 읽고 승인하거나 수정 피드백을 입력한다. 34번에서 분석한 S3 polling + keepalive 패턴이 이 모달의 통신 인프라 다.

5.2.4 Layer 1 의 의의 — 계획 없는 실행의 위험

Part 1 은 다음과 같이 명시한다.

“Planning 없이 작업하면 에이전트가 즉석에서 모든 것을 결정해야 하고, 중간에 방향 전환이 필요하면 이전 작업이 무효화된다. 또한 사용자는 진행 상황을 전혀 파악할 수 없다.”

Layer 1 의 3 단계 (라우팅 → 계획 → 검토) 가 다음을 보장한다.

단순 요청에 비싼 오케스트레이션을 낭비하지 않음 (Coordinator)
계획이 텍스트로 명시되어 추적 가능 (Planner)
사용자가 계획을 검토·수정 가능 + 단계별 진행 상황 실시간 확인 (Plan Reviewer)
특정 단계 실패 시 해당 단계만 재실행 가능 (체크리스트 구조)

5.3 Layer 2 — Supervisor (오케스트레이터)

Supervisor 는 Planner 가 생성한 full_plan 의 체크리스트를 순서대로 실행하는 오케스트레이터다. 핵심 특징은 3rd layer 의 전문 에이전트들을 Tool Use 로 호출 한다는 점이다.

# nodes.py — Supervisor 에이전트에 Sub Agent 를 Tool 로 등록
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,
)

5.3.1 Supervisor 의 워크플로우 규칙 3 가지

규칙	내용
필수 실행 순서	Coder → Tracker → Validator → Tracker → Reporter → Tracker. 각 에이전트 실행 후 Tracker 호출이 필수
섹션 완료 규칙	현재 에이전트의 모든 체크리스트가 `[x]` 가 될 때까지 다음 에이전트로 넘어가지 않음
컨텍스트 보존	각 도구 에이전트에 `clues` 변수와 `full_plan` 변수를 전달 — 전체 컨텍스트 유지, 맥락 손실 방지

이 3 규칙이 Layer 2 의 본질이다. Supervisor 는 LLM 추론으로 “다음에 뭐 할지” 를 결정하지 않고, 명시된 체크리스트를 순서대로 채워가는 결정론적 실행 을 한다.

5.4 Layer 3 — Coder · Validator · Reporter · Tracker

Layer 3 의 4 에이전트는 PythonAgentTool 로 래핑되어 Supervisor 의 Tool Use 호출을 받는다. 각각 독립된 Agent() 인스턴스, 자체 시스템 프롬프트, 모델 ID, 도구 세트를 갖는다.

에이전트	역할	보유 도구	주요 출력물
Coder	데이터 분석·차트 생성·인사이트 도출	`write_and_execute_tool`, `bash_tool`, `file_read`, `skill_tool`	`*.png` 차트, `calculation_metadata.json`
Validator	수치 계산 재검증·인용 생성	`write_and_execute_tool`, `bash_tool`, `file_read`	`citations.json`, `validation_report.txt`
Reporter	DOCX 보고서 생성	`write_and_execute_tool`, `bash_tool`, `file_read`	`final_report.docx`, `final_report_with_citations.docx`
Tracker	체크리스트 진행 상태 업데이트	없음 (LLM 추론만)	업데이트된 `full_plan`

5.4.1 표준 실행 흐름

Supervisor 가 Planner 의 체크리스트를 기반으로 다음 순서로 호출한다.

순번	에이전트	작업
1	Coder	데이터 로드 + 분석 코드 작성·실행 → 차트 PNG + `all_results.txt` 누적 + `calculation_metadata.json`
2	Tracker (1차)	Coder 완료 항목 `[ ]` → `[x]` 갱신
3	Validator	`calculation_metadata.json` 을 읽고 소스 데이터에서 재계산 → 0.01 오차 범위 내 일치 시 통과, 불일치 시 플래그. 검증된 계산은 `citations.json` 에 저장
4	Tracker (2차)	Validator 완료 상태 갱신
5	Reporter	`all_results.txt` (분석 결과) + `citations.json` (인용 메타데이터) 를 읽어 최종 DOCX 2 종 (인용 포함/미포함) 생성
6	Tracker (3차)	모든 작업의 완료 상태 최종 반영

5.4.2 Tracker 의 존재 이유 — 미니멀리즘의 정수

Tracker 가 매 에이전트 실행 후 반복 실행되는 이유는, Supervisor 가 “현재 어디까지 완료되었 는지” 를 정확히 파악 하고 섹션 완료 규칙을 강제하기 위함이다.

특히 Tracker 는 도구 없이 LLM 추론만으로 체크리스트를 갱신 한다. 즉 별도 상태 머신이나 DB 없이 “계획 텍스트를 LLM 이 읽고 [ ] 를 [x] 로 바꿔주는” 순수 LLM 작업이다. 이는 34번에서 다룬 “stderr 를 그대로 LLM 에 반환” 패턴과 동형이다.

하네스의 미니멀리즘 명제: 별도 retry 로직 없이 LLM 일반 추론으로 실패 복구 (34번 사례), 별도 상태 머신 없이 LLM 일반 추론으로 진행 추적 (35번 Tracker). 두 사례 모두 LLM 의 추론 능력을 신뢰 하고 인프라를 단순화한다.

5.4.3 Validator 의 0.01 오차 — 검증의 정량 기준

Validator 가 0.01 오차 범위 내 일치 를 통과 기준으로 삼는다는 점이 흥미롭다. 이는:

부동소수점 연산의 미세한 차이를 허용
동시에 비즈니스 의미가 있는 차이 (예: 1% 이상 차이) 는 불일치로 분류
계산 재현 가능성 (reproducibility) 의 정량화

이 기준이 명시되어 있어야 “검증 통과” 가 무엇인지 객관화된다. 그렇지 않으면 LLM 이 “비슷하다” 라고 자의적 판단할 위험이 있다.

5.5 컨텍스트 격리의 효과

Layer 3 각 에이전트가 독립 컨텍스트 에서 작업한다는 점이 전체 시스템의 핵심이다. 만약 8 에이전트가 같은 컨텍스트를 공유한다면:

Coder 가 데이터 분석 코드를 출력하면 그 텍스트가 Reporter 에게도 보임 (불필요)
Tracker 가 체크리스트만 보면 되는데 모든 분석 결과까지 봐야 함 (낭비)
컨텍스트가 8 배 빠르게 한계 도달

각 에이전트의 컨텍스트가 격리되고 압축된 결과만 다음 에이전트에 전달 되면 전체 토큰 비용이 선형이 아닌 로그 스케일에 가까워진다. 32번에서 정의한 Harness-aware Context Engineering 의 인프라적 극단이라고 볼 수 있다.

6 에이전트별 LLM 모델 구성 — Prompt Caching 으로 90% 절감

Deep Insight 는 각 에이전트의 역할에 맞게 서로 다른 모델과 설정을 사용한다. 이는 단순한 모델 선택이 아닌 비용과 품질을 최적화하는 아키텍처적 결정 이다.

6.1 모델·설정 매트릭스

에이전트	모델	Extended Thinking	Prompt Caching	역할 / 선택 이유
Coordinator	Haiku	X	X	빠른 라우팅 — 비용 최소화
Planner	Opus	O (~8192 토큰)	X	심층 사고 — 최고 품질 계획 수립
Supervisor	Sonnet	X	O	실행 오케스트레이션 — 캐싱으로 비용 절감
Coder	Sonnet	X	O	코드 생성·실행 — 반복 호출에 캐싱 효과적
Validator	Sonnet	X	X	수치 검증 — 매번 다른 데이터로 캐싱 불필요
Reporter	Sonnet	X	O	보고서 생성 — 긴 프롬프트에 캐싱 효과적
Tracker	Sonnet	X	X	상태 업데이트 — 경량 작업으로 캐싱 불필요

6.2 모델 선택의 3 가지 원칙

이 매트릭스에서 다음 3 가지 원칙이 도출된다.

6.2.1 원칙 1 — 작업 복잡도와 모델 등급의 매칭

복잡도	모델	사례
단순 분류·라우팅	Haiku	Coordinator
심층 추론·계획	Opus + Extended Thinking	Planner
일반 실행	Sonnet	나머지 5 에이전트

Haiku 를 단순 작업에 쓰는 것은 비용 절감 + 응답 속도 양쪽에 효과적이다. Coordinator 가 Sonnet 이었다면 단순 인사말에도 비싼 토큰 비용이 발생했을 것이다.

6.2.2 원칙 2 — Extended Thinking 은 계획 단계에만

Extended Thinking 은 Planner 만 활성화한다. Coder · Validator · Reporter · Tracker 는 비활성화. 근거:

Planner: 사용자 요청을 5~10 단계로 분해하는 일은 한 번의 큰 사고가 필요
나머지: 각자의 단계 작업은 명확히 정의돼 있어 추가 사고 비용이 가치 미만

이 결정이 계획과 실행의 비용 분리 를 만든다. 비싼 사고는 한 번만, 실행은 효율적으로.

6.2.3 원칙 3 — Prompt Caching 의 선택적 적용

캐싱 활성화	에이전트	이유
O	Supervisor, Coder, Reporter	시스템 프롬프트와 도구 정의가 반복 호출되어 캐싱 이점 큼
X	Coordinator	단 한 번 호출
X	Validator, Tracker	매번 다른 컨텍스트로 호출되어 캐싱 효과 낮음

Prompt Caching 으로 시스템 프롬프트와 도구 정의를 캐싱하여 반복 호출 시 입력 토큰 비용 최대 90% 절감.

6.2.4 34번 비용 분석과의 연결

34번에서 분석한 1 세션 비용 ~$4.13 의 Bedrock 토큰 breakdown 을 보면:

regular input    806K
output            91K
cache read       412K  (90% 할인 적용)
cache write       52K

cache read 가 412K 로 regular input 의 절반 가까이 된다. 이 caching 효과가 위 원칙 3 의 결과 다. 만약 모든 에이전트에 캐싱을 일괄 적용했다면 cache write 비용이 누적돼 오히려 비용 증가 가능성이 있다. 선택적 캐싱이 의도적 trade-off 라는 Part 1 의 명시는 이 미세 조정을 드러낸다.

6.3 33번 카탈로그와의 매핑

33번에서 정리한 산업 사례들은 “역할별 모델 분리” 패턴을 짧게 언급했다. AWS Deep Insight 의 이 매트릭스는 그 패턴의 세부 구현 을 보여준다.

33번 패턴	AWS Deep Insight 구현
누비다 3 AI 분리 (기획·코드·테스트)	7 역할 + 8 에이전트로 더 세분화
역할별 모델 매칭	Haiku/Opus/Sonnet 3 등급 매트릭스
비용 최적화	Prompt Caching 90% 절감

7 Strands Agents SDK 의 핵심 패턴 2 가지

Deep Insight 의 멀티에이전트 실행 흐름은 Strands Agents SDK 가 제공하는 두 가지 핵심 패턴 조합으로 구현된다.

7.1 패턴 1 — Graph 패턴

에이전트들의 실행 순서와 흐름을 방향 그래프 로 정의한다.

Coordinator → Planner → Plan Reviewer → Supervisor
                ↑           │
                └───────────┘
            (수정 요청 시 조건부 분기)

Plan Reviewer 에서 사용자가 수정을 요청할 경우 조건부 분기를 통해 다시 Planner 로 돌아가 계획을 재작성한다. 상황에 따라 다음 단계를 동적으로 결정할 수 있어 HITL 이나 에러 처리 같은 복잡한 워크플로우 를 유연하게 구현할 수 있다.

7.2 패턴 2 — Agents-as-tools

Supervisor 가 Coder · Validator · Reporter · Tracker 같은 전문 에이전트들을 마치 도구처럼 필요 한 시점에만 호출 한다.

각 전문 에이전트는 독립적인 context 에서 작업을 수행하고 결과만 Supervisor 에게 반환하므로, 전체 시스템의 context 사용량을 최소화하면서도 전문성을 유지한다.

7.3 두 패턴의 조합 효과

패턴	해결하는 문제
Graph	흐름 제어 + 동적 분기 (HITL · 에러 처리)
Agents-as-tools	컨텍스트 격리 + 전문성 유지

두 패턴이 함께 작동하면 결정론적 워크플로우 + 격리된 전문 작업 의 조합이 만들어진다. 이것이 Layer 1 (Graph 로 흐름 정의) 과 Layer 2-3 (Agents-as-tools 로 전문 호출) 의 분리 근거다.

7.4 31번·33번 매핑

시리즈 개념	Strands 패턴 매핑
31번 Tool loop 정책	Graph 패턴이 명시적 그래프로 정형화
32번 Cross-cutting	Agents-as-tools 가 컨텍스트·실행을 cross-cutting
33번 Anthropic 가축 모델	Agents-as-tools 의 독립 인스턴스 = 가축 단위

8 솔루션 2 — 프로덕션 배포와 운영 (Part 3 와의 연결)

Part 1 의 솔루션 상세 2 는 인프라 결정의 요약 만 다룬다. 자세한 내용은 Part 3 (34번 포스트) 의 영역이다. 여기서는 Part 1 의 요약 수준에서 다루고 34번과의 연결을 명시한다.

8.1 코드 실행 안전성 — 5 가지 결정

Part 1 본문에 명시된 코드 실행 인프라 결정.

#	결정	Part 3 (34번) 에서의 상세
1	커스텀 컨테이너 도커 이미지 (한글 폰트·Python 패키지)	Decision 1 의 Dockerfile 분석
2	컨테이너 격리 (세션별 Fargate, Private VPC)	Decision 1 + Decision 3
3	2-step 실행 (base64 인코딩 + subprocess)	Decision 1 의 Base64 패턴
4	ALB Sticky Session (같은 컨테이너 라우팅)	Decision 1 의 ALB 분석
5	아티팩트 관리 (S3 업로드, 1 시간 후 자동 종료)	Decision 2 의 S3 외부화

5 가지가 모두 34번에서 자세히 분석됐다. 본 글은 Part 1 의 요약 수준만 인용한다.

8.2 운영 모니터링 — Web UI + Ops 대시보드

컴포넌트	기술 스택	역할
Web UI (deep-insight-web)	FastAPI + AgentCore Native Protocol + SSE	데이터 업로드, 실시간 분석 진행, HITL 모달, 보고서 다운로드, 한국어/영어 다국어
Ops 대시보드 (선택)	DynamoDB + SNS + Cognito	작업 추적 · 장애 알림 · 관리자 인증

Ops 대시보드는 필수가 아니다. Deep Insight 는 대시보드 없이도 정상 작동한다. 운영팀의 가 시성 요구가 있을 때만 추가하는 옵션이다. 이 분리가 인프라 모듈화 의 좋은 예다.

대시보드 기능	도구	설명
작업 추적	DynamoDB	상태·토큰 사용량·소요 시간 메트릭 기록
장애 알림	SNS	분석 실패 시 관리자에게 즉시 이메일
관리자 인증	Cognito JWT	대시보드 보호

Ops 대시보드 자체는 33번에서 정리한 OpenAI 7 도구 중 “관측 가능성” 의 구체 구현이다.

9 확장 사례 — 도메인 전이의 검증

Part 1 의 마지막 핵심 섹션은 Deep Insight 아키텍처가 도메인을 교체해도 동작하는 범용 패턴 임을 두 사례로 검증한다.

9.1 사례 1 — LG전자 ChatInsight (마케팅 인사이트 추출)

문제 상황:

LG전자 한국영업본부의 데이터 분석 워크플로우.

항목	as-is
분석 요청 → 결과 수령	2~3 주
마케터-데이터 사이언티스트	의도 유실
시장 타이밍	반복적으로 놓침

해결 — Deep Insight 아키텍처 채택:

컴포넌트	LG ChatInsight 의 구현
Coordinator	요청 복잡도 판단 + 라우팅
Planner	분석 전략 수립
Task Tracking	완료 상태 관리 (= Tracker)
Supervisor	Coder + Reporter 오케스트레이션
정보 전달	`all_results.txt` 누적 방식 그대로 적용

결과:

항목	as-is	to-be	개선
분석 시간	3 일	30 분	288 배 향상
SQL 지식 필요성	필수	불필요	마케터 직접 사용
분석 방법론 학습	필요	불필요	자율 데이터 탐색

288 배라는 수치는 Part 1 본문에 직접 명시된다. 33번에서 정리한 OpenAI Project 1M 의 “버그 40% 감소” 와 비슷한 정량 검증이지만, 출처가 LG전자라는 외부 기업이라는 점이 더 강한 검증 신호다.

9.2 사례 2 — TechRecon (re:Invent 2025 SNR203)

AWS re:Invent 2025 세션 SNR203 “A leader’s guide to emerging technologies” 에서 발표된 사례. Deep Insight 의 아키텍처를 기술 전략 도메인 에 적용했다.

TechRecon 의 입출력:

항목	내용
입력	회사명 + 산업 분야
Researcher 역할	Tavily 검색 + 웹 크롤링으로 신기술 동향 수집
출력 1	Landscape Analysis (신기술 전체 분석)
출력 2	Technical Position Paper (특정 기술 심층 분석)

아키텍처 비교:

컴포넌트	Deep Insight	TechRecon
Layer 1	Coordinator → Planner → Plan Reviewer	Router → Planner
Layer 2	Supervisor	Supervisor
Layer 3	Coder · Validator · Reporter · Tracker	Researcher · Coder · Validator · Reporter · Tracker
SDK	Strands Agents SDK	Strands Agents SDK GraphBuilder
기법	Extended Thinking + Prompt Caching	Extended Thinking + Prompt Caching

핵심 차이: Coder 대신 Researcher 가 주요 실행 에이전트라는 점뿐. 계층적 오케스트레이션과 컨텍스트 격리라는 설계 원리는 그대로 유지된다.

9.3 두 사례의 시사점

“Deep Insight 의 아키텍처가 특정 유스케이스에 종속된 것이 아니라, 도메인을 교체해도 동작하는 범용적인 설계 패턴임을 보여준다. 에이전트의 역할과 프롬프트만 교체하면, 동일한 오케스트레이션 구조 위에서 전혀 다른 문제를 해결할 수 있다.”

이 명제는 33번에서 추론한 “하네스 엔지니어링이 인프라·아키텍처·페르소나·오케스트레이션 4 차원 으로 확장 중” 이라는 진단을 2 개 외부 사례로 사후 검증 한다.

10 31~34번 시리즈와의 통합 매핑

Part 1 의 시스템 설계가 31~34번 각 포스트와 어떻게 연결되는지 통합 정리한다.

10.1 31번 동심원 모델

Part 1 의 8 에이전트 3 레이어가 31번 동심원 (또는 33번 5 층 갱신 모델) 의 어디에 위치하는가.

┌─────────────────────────────────────────────────────────┐
│  Orchestration — Strands Graph + Agents-as-tools         │  ← Part 1 의 핵심
│   ┌─────────────────────────────────────────────────┐  │
│   │  Harness — AgentCore + Fargate + S3 + VPC       │  │  ← Part 3 (34번)
│   │   ┌────────────────────────────────────────┐   │  │
│   │   │  Context — all_results.txt, citations  │   │  │  ← Part 2 (36번 예정)
│   │   │   ┌──────────────────────────────┐    │   │  │
│   │   │   │  Prompt — 8 에이전트 시스템  │   │   │  │
│   │   │   │  프롬프트 (본문 미공개)        │   │   │  │
│   │   │   └──────────────────────────────┘    │   │  │
│   │   └────────────────────────────────────────┘   │  │
│   └─────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────┘

각 층이 명확한 산출물로 구현된다. Part 1 (35번) → Orchestration / Part 2 (36번) → Context / Part 3 (34번) → Harness 의 분담이 자연스럽다.

10.2 30번 5 대 축 trade-off

30번 5 대 축	Part 1 의 우회
Auto-compaction	8 에이전트 컨텍스트 격리 — 압축 자체가 거의 불필요
Tool result lifecycle	각 에이전트가 결과를 압축해 다음 에이전트에 전달
응답 길이 제약	에이전트별 시스템 프롬프트로 자체 제어
Skill 로딩	Coder 의 `skill_tool` 명시적 호출
Protected zone	Layer 분리 자체가 인프라 차원의 protected zone

8 에이전트 분리가 30번 trade-off 를 거의 모두 우회한다. 이는 30번에서 추론한 “Claude Code vs Copilot CLI 의 약점은 단일 LLM 가정에서 발생” 이라는 점과 정합한다. 단일 LLM 을 8 개로 분해하면 trade-off 자체가 다른 형태로 변환 된다.

10.3 32번 Cross-cutting Concern

Part 1 의 멀티에이전트 시스템이 32번에서 정의한 cross-cutting 개념과 어떻게 연결되는가.

Cross-cutting 패턴	Part 1 에서의 사례
한 기법이 여러 층 관통	Strands Graph 패턴이 Orchestration + Context (clues 변수) + Prompt 모두에 영향
책임 경계 불명확성	Tracker 가 LLM 추론(=Prompt 영역) 으로 상태 갱신(=Harness 영역) 을 한다

32번에서 “Skill-based PE 가 cross-cutting 이다” 라고 했듯이, Part 1 의 Strands SDK 자체가 cross-cutting 프레임워크 다. SDK 한 줄 호출이 Orchestration·Context·Prompt 세 층을 동시에 설정한다.

10.4 33번 산업 카탈로그 + 34번 인프라 사례

Part 1 의 8 에이전트 3 레이어가 33번 카탈로그의 4 가지 사례에 어떻게 매핑되는가.

33번 사례	Part 1 매핑
OpenAI Project 1M (3 명·100 만 줄·40% 버그 감소)	정량 검증 — LG ChatInsight 288 배 향상이 같은 결의 검증
OpenAI 7 도구	Supervisor (리뷰), Tracker (관측), Validator (구조 테스트), Coder skill_tool (Linter)
Anthropic 분리 모델 (반려동물 vs 가축)	8 에이전트가 모두 가축 모델 — 한 에이전트 망가져도 교체 가능
누비다 3 AI 분리	Deep Insight 가 더 세분화 (3 → 8)
동료 스킬 (페르소나 보존)	(해당 없음 — Deep Insight 는 페르소나 차원 미구현)

5 가지 사례 중 4 가지가 Part 1 에서 통합 구현된다. 동료 스킬의 페르소나 차원만 미구현 이며, 이는 33번에서 분석한 “다음 1 년의 격전지는 Sandbox 분리와 페르소나 커스터마이즈” 와 정합한다.

11 Critical Reading — Part 1 의 한계와 일반화 가능성

34번에서와 같은 비판적 독해를 Part 1 에 적용한다.

11.1 한계 1 — Strands Agents SDK 의존

Strands Agents SDK 는 비교적 최근 (2025 년) 등장한 AWS 생태계 도구다. 다른 프레임워크 (LangGraph, AutoGen, CrewAI, Magentic-One) 와의 비교는 본문에 없다. Strands 의 우위 (또는 trade-off) 가 명확히 검증되지 않은 상태다.

프레임워크	Graph 패턴 지원	Agents-as-tools 지원
Strands Agents SDK	O (방향 그래프)	O (Tool 등록)
LangGraph	O (StateGraph)	O (Subgraph)
AutoGen	O (대화형 그래프)	O (역할 분리)
CrewAI	△ (제한적)	O (역할 분리)

같은 패턴이 다른 SDK 로도 가능하며, Strands 가 결정적 차별화 인지는 추가 검증이 필요하다.

11.2 한계 2 — 8 에이전트의 적정성

8 에이전트가 “최적” 인지는 본문에 정량 분석이 없다. 다음 질문이 남는다.

4~5 에이전트로 줄이면 어떤 성능·비용 차이가 발생하는가
16 에이전트로 더 세분화하면 어떤 비용 / 복잡도 trade-off 가 발생하는가
Tracker 의 별도 호출이 정말 필수인가 (Supervisor 가 직접 갱신할 수 있지 않은가)

특히 Tracker 가 LLM 추론만 하는데 별도 에이전트 인스턴스가 필요한가 는 미니멀리즘 관점에서 의문을 던질 수 있다. Supervisor 가 자체적으로 체크리스트 갱신 함수를 가질 수도 있다.

11.3 한계 3 — LG전자 288 배 사례의 비교 기준

“분석 시간 3 일 → 30 분” 의 288 배는 인상적이지만 다음이 명시되지 않았다.

3 일은 평균인가, 중앙값인가, 최악 케이스인가
30 분은 어떤 분석 복잡도 기준인가 (Moon Market 데모 같은 단순한 것인가, LG 의 실제 복잡 사례인가)
as-is 의 3 일에는 마케터-데이터 사이언티스트 커뮤니케이션 시간이 포함되는가
정확도·완성도 비교는 없는가 (속도만 288 배 빠르다고 의미가 같지는 않다)

이 정보 없이 288 배를 인용하면 선택 편향 위험이 있다. Critical Reading 의 정직성으로, “288 배” 는 AWS 보도 시점의 명시 수치라는 것 외에는 추가 검증이 필요한 정보로 다뤄야 한다.

11.4 일반화 가능한 핵심 패턴 4 가지

위 한계에도 불구하고, 클라우드·SDK·도메인과 무관하게 일반화 가능한 패턴 은 다음 4 가지다.

패턴	본질	이식 가능성
3 레이어 분리 (라우팅·계획·실행)	단순 요청과 복잡 작업을 다른 비용으로 처리	모든 환경
역할별 모델 매트릭스	작업 복잡도와 모델 등급 매칭	모든 LLM 환경
체크리스트 기반 진행 추적	LLM 추론으로 갱신 가능한 텍스트 상태	모든 환경
Agents-as-tools 컨텍스트 격리	전문 에이전트의 독립 컨텍스트 + 결과만 반환	모든 multi-agent 환경

이 4 가지는 Strands SDK 가 아니어도, AWS 가 아니어도 적용 가능하다. AWS Deep Insight 는 이 패턴들의 한 가지 구체화일 뿐이다.

12 Part 1 + Part 3 통합 — 한 시스템의 두 얼굴

이제 Part 1 (이 글) + Part 3 (34번) 을 합쳐 Deep Insight 의 전체 그림을 정리한다.

12.1 양 부의 책임 분담

영역	Part 1 (35번 — 이 글)	Part 3 (34번)
다루는 질문	“무엇을 하는가”	“어디서·어떻게 안전하게 실행하는가”
31번 층위	Orchestration + Prompt	Harness
핵심 산출물	8 에이전트 3 레이어 + Strands 패턴 + 모델 매트릭스	AgentCore + Fargate + S3 + VPC + Defense in Depth
검증 도구	LG ChatInsight 288 배, TechRecon 도메인 전이	22.5 분 / 79 Fargate / $4.13 실측

두 부가 합쳐져야 시스템 설계 + 인프라 구현 의 완전한 그림이 된다.

12.2 통합 스토리

무엇을 만드는가 (Part 1): CSV → DOCX 의 Multi-Agent 시스템. 8 에이전트가 3 레이어로 협업
왜 8 개로 나누는가 (Part 1): 컨텍스트 격리 + 역할별 모델 비용 최적화
어디서 실행하는가 (Part 3): 자체 인프라 — AgentCore Runtime + Fargate + S3 + VPC
어떻게 안전하게 실행하는가 (Part 3): Defense in Depth 4 층 + microVM 격리 + 프롬프트 인젝션 blast radius 제한
얼마나 효과적인가 (Part 1 + Part 3): LG 288 배 + 1 세션 $4.13 + LLM 추론이 코드의 61 배

12.3 36번 (Part 2) 가 채울 영역

Part 2 가 다룰 Context Engineering 4 가지 계층 기법:

예상 주제	본문에 짧게 등장한 단서
Multi-Agent Architecture	(Part 1 에서 다룸 — 36번에서는 Context 관점 보강)
Structured Note-Taking	`all_results.txt` 누적 패턴의 알고리즘
Skills	Coder 의 `skill_tool` 의 구체 구현
Prompt Caching 의 90% 절감	캐싱 전략의 세부 알고리즘
HITL	Plan Reviewer 의 모달·polling 메커니즘
Validator/Tracker	검증 자체의 알고리즘과 실패 처리

이 7 가지가 36번에서 깊게 다뤄질 것으로 예상된다. 본 글은 결과만 일반화해 다뤘다.

13 결론

13.1 한 문장 요약

AWS Deep Insight Part 1 은 8 에이전트 3 레이어 (Coordinator-Planner-Plan Reviewer / Supervisor / Coder-Validator-Reporter-Tracker) + Strands Agents SDK 의 Graph + Agents-as-tools 패턴 + 역할별 Claude 모델 매트릭스 (Haiku · Opus · Sonnet) 로 5 가지 핵심 문제를 해결하는 시스템 설계 사례이며, LG전자 ChatInsight (288 배 향상) 와 TechRecon (re:Invent 2025) 으로 도메인 전이 가능성 이 검증된다.

13.2 31~34번 시리즈의 갱신

시리즈	Part 1 사례로 인한 갱신
31번 동심원	Orchestration 층의 구체적 구현 패턴 (Strands Graph + Agents-as-tools) 추가
33번 5 층 갱신 모델	LG·TechRecon 로 도메인 전이 가능성 사후 검증
34번 Part 3 분석	인프라가 무엇을 위해 만들어졌는지 상위 설계 의도 보강
32번 cross-cutting	Strands SDK 자체가 3 층 cross-cutting 프레임워크임 검증
30번 trade-off	8 에이전트 분리로 단일 LLM trade-off 가 변형됨

13.3 핵심 메시지 5 가지

Multi-Agent 의 본질은 컨텍스트 격리 — 8 에이전트가 독립 컨텍스트에서 작업하고 압축된 결과만 다음에 전달하는 구조가 토큰 비용의 로그 스케일 가까운 절감을 만든다
모델 매트릭스가 비용 최적화의 핵심 — Haiku (단순 라우팅) · Opus (심층 사고) · Sonnet (실행) 매칭과 선택적 Prompt Caching 으로 비용·품질 trade-off 미세 조정
계획과 추적이 명시적 텍스트 — full_plan 체크리스트와 Tracker 의 [ ]→[x] 갱신이 LLM 추론으로 가능한 가장 단순한 상태 머신
하네스 미니멀리즘 — Tracker 가 도구 없이 LLM 추론만으로 동작 (35번) + stderr 그대로 LLM 에 반환 (34번). 별도 인프라 없이 LLM 추론 능력 신뢰
도메인 전이가 검증된 범용 패턴 — LG ChatInsight (288 배) + TechRecon (Coder→Researcher 만 교체) 로 Deep Insight 아키텍처가 데이터 분석에 한정되지 않는 범용 패턴임이 입증

13.4 한계와 다음 단계

이 글의 명시 한계: Strands SDK vs 타 프레임워크 (LangGraph, AutoGen, CrewAI) 비교 부족, 8 에이전트의 적정성 정량 분석 없음, LG 288 배 비교 기준 불명확. 추가 검증 필요
Part 2 (36번): Context Engineering 4 계층 기법 — Note-taking, Skills, Prompt Caching 의 세부 알고리즘
Part 3 (34번): 인프라 구현 결정 — 이미 분석 완료
개인 / 소규모 팀이 따라할 수 있는 핵심 패턴 4 가지: 3 레이어 분리·역할별 모델 매트릭스· 체크리스트 진행 추적·Agents-as-tools 컨텍스트 격리. AWS·Strands 가 없어도 적용 가능

14 관련 주제

선행 시리즈 (이 글의 전제)

관련 아키텍처 분석

LangGraph 비교 (대안 SDK)

향후 작성 예정 (Placeholder)

AWS Deep Insight Part 2 — Context Engineering 실전 기법 (Note-taking, 파일 외부화, Skills, Prompt Caching)

15 참고문헌

15.1 1 차 자료 (AWS 공식)

AWS Korea SA Team (Yoonseo Kim, Jesam Kim, Jiyun Park, Kyutae Park, Gonsoo Moon, 곽영화). (2026.4.1). 프로덕션 Multi-Agent 시스템이 해결해야 할 5 가지 문제 – Deep Insight 아키텍처로 배우는 실전 설계 (Part 1/3). AWS 기술 블로그. https://aws.amazon.com/ko/blogs/tech/practical-design-lessons-from-the-deep-insight-arch/
AWS Korea SA Team. (2026.4.22). 하네스 엔지니어링으로 본 Deep Insight (Part 3/3). AWS 기술 블로그. — 본 블로그 34번 포스트 분석 대상
AWS Korea SA Team. (2026). Deep Insight Part 2 — Context Window 한계를 넘어서 (Part 2/3). AWS 기술 블로그. (본 글 작성 시점 미참조 — 36번 포스트 예정)

15.2 오픈소스

AWS Samples. (2026). sample-deep-insight. GitHub. https://github.com/aws-samples/sample-deep-insight
AWS. (2026). Deep Insight Workshop (한국어 / English).

15.3 Strands Agents SDK

AWS. (2025). Strands Agents SDK Documentation. (Graph 패턴, Agents-as-tools 패턴 등의 정의 출처)

15.4 Amazon Bedrock 공식 문서

Amazon. (2025). Amazon Bedrock User Guide. https://docs.aws.amazon.com/bedrock
Amazon. (2025). Claude on Amazon Bedrock — Extended Thinking, Prompt Caching.
Amazon. (2025). Amazon Bedrock AgentCore Documentation.

15.5 확장 사례 (Part 1 본문 인용)

AWS Tech Blog. (2026). LG전자의 Agentic AI 기반 인사이트 추출 시스템 개발기. (LG ChatInsight 288 배 사례)
AWS re:Invent 2025. SNR203: A leader’s guide to emerging technologies — From insights to rapid action. (TechRecon 사례)
TechRecon GitHub Repository. (재인용 — Part 1 본문 링크)

15.6 멀티 에이전트 비교 프레임워크 (이 블로그 보강)

Microsoft. (2024). AutoGen Documentation.
LangChain. (2024). LangGraph Documentation. https://langchain-ai.github.io/langgraph
CrewAI. (2024). CrewAI Framework.

출처 검증 주의

본 글은 AWS 공식 블로그 Part 1 단독을 1 차 자료로 한다. 다음 항목은 추가 검증이 필요하다.

LG전자 ChatInsight “288 배 향상” 의 정확한 비교 기준 (3 일 / 30 분 의 정의·복잡도·정확도 비교 미명시)
TechRecon 의 구현 디테일 (re:Invent 2025 SNR203 강연 영상 + GitHub 별도 확인 필요)
Strands Agents SDK 와 LangGraph / AutoGen 의 비교 우위는 본문에 없음 — 추가 비교 분석 필요

본 글의 결론은 Part 1 본문에 직접 명시된 정보에 한정한다. Part 2 영역의 세부 메커니즘 (Note- taking, Skills, Prompt Caching 알고리즘) 은 결과만 일반화해 다루었다. Part 2 입수 시 36번 포스트로 별도 작성 예정.