AWS Deep Insight Part 2 — Context Window 한계를 넘는 4 계층 Context Engineering

35번(Part 1 아키텍처)·34번(Part 3 인프라)의 가운데 — Layer 1 격리 / Layer 2 프롬프트 / Layer 3 파일 외부화 / Layer 4 검증·안전장치, Anthropic 권장 패턴의 산업 검증

AWS Korea SA Team 의 Deep Insight 시리즈 Part 2 (2026.4.8 발행) 를 분석한다. Context Window 한계 (Claude Sonnet 4.5 = 200K) 를 넘는 복잡 작업을 수행하기 위한 4 계층 방어 체계 — Layer 1 (멀티 에이전트 격리, 25K 토큰 제한) / Layer 2 (출력 예산·표준 응답·Self-contained 코드) / Layer 3 (write_and_execute_tool 95% 절약, all_results.txt 통신 버스, Claude Skills 지연 로딩) / Layer 4 (Validator 0.01 오차, OptimizedValidator 우선순위, Summarizing ConversationManager 50% 요약) — 를 정리한다. Anthropic 5 편 (Effective Context Engineering, Code Execution with MCP, Multi-Agent Research, Writing Effective Tools, Effective Harnesses for Long-Running Agents) 의 권장 패턴이 한 시스템에서 통합 구현된 사례이며, 32번 Harness-aware Context Engineering 패턴의 산업 검증이다. Deep Insight 시리즈 (Part 1 → 35번, Part 2 → 본 글, Part 3 → 34번) 가 본 글로 완성된다.

Agent
Architecture
Engineering
저자

Kwangmin Kim

공개

2026년 04월 28일

1 이 글의 위치와 출처

이 글은 24-Agent-Architecture 시리즈의 일곱 번째 하네스 분석 이며, AWS Deep Insight 시리즈 3 부작 중 Part 2 단독 분석이다. 본 글로 Deep Insight 시리즈 분석이 완성된다.

번호 주제 자료 성격
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 차 자료
36번 (이 글) AWS Deep Insight Part 2 (Context Engineering) AWS 공식 1 차 자료
출처와 범위 명시
  • 1 차 자료: AWS 공식 기술 블로그 “Context Window 한계를 넘어서 – Deep Insight 개발 여정 으로 배우는 Context Engineering 실전 기법” (Yoonseo Kim, Jesam Kim, Jiyun Park, Kyutae Park, Gonsoo Moon, 곽영화 / 2026.4.8 발행 / Amazon Bedrock AgentCore, AWS Fargate, Strands Agents)
  • 시리즈 위치: AWS 가 공개한 3 부작 중 Part 2 (Context Engineering 4 계층 기법) 단독 분석. Part 1 (시스템 아키텍처) 은 35번, Part 3 (인프라) 는 34번 포스트
  • 본 글로 시리즈 완성: Deep Insight 의 Part 1·2·3 분석이 본 글로 완료된다
  • 34번·35번과의 관계: Part 2 는 35번 (Part 1) 의 8 에이전트 아키텍처 위에서 동작하며, 34번 (Part 3) 의 인프라 결정 (S3 외부화) 의 소프트웨어 차원 동기 를 제공한다
  • Anthropic 권장 패턴 매핑: 본 글이 인용하는 Anthropic 의 5 편 (Effective Context Engineering for AI Agents (2025.09), Code Execution with MCP (2025.11), How We Built Our Multi-Agent Research System, Writing Effective Tools for Agents, Effective Harnesses for Long-Running Agents) 은 본 글 작성 시점에 원문 미참조 — 본 글에서는 Part 2 본문에서 직접 인용한 문장만 다룸

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

35번 (Part 1) 과 34번 (Part 3) 만으로는 Deep Insight 시스템에 빠진 핵심 영역이 있다.

2.1 34번·35번이 답하지 않은 질문

질문 35번 (Part 1) 처리 34번 (Part 3) 처리 Part 2 의 답
왜 Coder Context 가 25K 미만에 머무르나 “압축된 결과만 전달” 만 언급 미언급 4 계층 방어 체계 전체 설명
all_results.txt 의 알고리즘은 존재만 언급 외부화 결정만 언급 Structured Note-Taking 의 누적 패턴
95%/90%/98.7% 절약 같은 정량 수치는 없음 비용 breakdown 만 각 기법의 토큰 절감률 명시
Skills 시스템의 작동 방식은 skill_tool 만 언급 미언급 YAML frontmatter + lazy loading
Validator 의 우선순위 검증 알고리즘은 “0.01 오차” 만 미언급 OptimizedValidator 의 4 단계 필터링
Context overflow 발생 시 어떻게 되나 미언급 미언급 SummarizingConversationManager 의 50% 요약

즉 Part 2 는 소프트웨어 차원의 Context 관리 알고리즘 을 다룬다. Part 1 이 무엇을 만드는지, Part 3 가 어디서 실행하는지를 답한다면, Part 2 는 어떻게 토큰을 효율적으로 다루는지 를 답한다.

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

시리즈 Part 2 가 보강하는 것
31번 동심원 Context 층의 구체적 구현 4 계층 검증
32번 Harness-aware Context Engineering 본 글의 4 계층이 정확히 그 패턴의 산업 사례
33번 산업 카탈로그 OpenAI 7 도구 중 “Repository 문서화 + 관측 가능성” 의 실제 구현
30번 trade-off Claude Code “잊음” 약점을 4 계층으로 우회하는 사례

특히 32번에서 정의한 Harness-aware Context Engineering 의 패턴 (“응답 텍스트로 정보 보존”, “의도적 redundancy”) 이 Part 2 의 4 계층에서 어떻게 산업 차원으로 격상되는지 본 글이 정밀 검증한다.

3 Context Engineering 정의 — 200K 한계의 실제 사례

3.1 정의

Part 2 본문은 Context Engineering 을 다음과 같이 정의한다.

“Context Engineering 은 LLM 의 제한된 Context window 내에서 에이전트가 최고 성능을 낼 수 있도록 정보를 최적화하는 기술이다.”

3.2 200K 컨텍스트의 한계 — 실제 시나리오

Claude Sonnet 4.5 모델은 200K Context Window 를 제공한다. 그러나 실제 프로덕션 작업은 이를 쉽게 초과한다.

예시 시나리오: “판매 데이터 분석 + DOCX 리포트 생성”

단계 시간
데이터 로드와 탐색 5 분
카테고리별 매출 분석 3 분
시계열 분석 + 차트 5 개 생성 10 분
통계 검사 검증 3 분
최종 리포트 생성 5 분
합계 15 분 / 150K 토큰 이상

단일 Context 에서 처리하면 발생하는 문제:

문제 결과
Context window 초과 중간 실패
오래된 Context 누적 성능 저하
오류 발생 시 전체 재실행 필요
Context 길이 증가 중요 정보 attention 감소
토큰 과금 비용 증가

3.3 Anthropic 의 핵심 관찰

Part 2 는 Anthropic 의 다음 인용으로 문제를 정형화한다.

“Context window 에 토큰이 많아질수록 모델이 정보를 정확히 기억하는 능력이 감소한다.” — Anthropic, “Effective Context Engineering for AI Agents” (2025.09)

이 명제는 31번에서 다룬 attention dilution 현상과 정확히 일치한다.

3.4 Context Engineering 의 본질

Part 2 본문은 다음을 강조한다.

“Context Engineering 은 단순한 기법 모음이 아니다. 아키텍처 설계부터 프롬프트 작성, 도구 구현, 검증 시스템까지 — 각 계층이 상위 계층이 놓친 부분을 보완하는 계층적 학문이다.”

이 표현이 4 계층 방어 체계의 출발점이다.

4 4 계층 방어 체계 — 핵심 원리

Deep Insight 가 Anthropic 의 권장 기법들을 4 가지 계층으로 체계화한 표.

계층 접근 방식 핵심 원리 실패하는 경우 (다음 계층이 보완)
Layer 1: 아키텍처 멀티 에이전트 구조로 Context 격리 큰 작업을 여러 에이전트로 분리, 각 에이전트가 독립 Context 사용 격리만으로 부족 → Layer 2
Layer 2: 프롬프트 프롬프트로 Context 유입량 제어 행동 규칙 지정 + 출력 제어 프롬프트로도 부족 → Layer 3
Layer 3: 도구 파일 기반 Context 외부화 (“Context 에는 포인터만, 데이터는 파일에”) 무거운 컨텐츠는 컨텍스트에 의존하지 않고 파일로 분리 그 외 문제 → Layer 4
Layer 4: 검증/안전장치 검증 에이전트 + 안전장치로 품질 보증 오류 잡고 Context overflow 방지 최종 방어선

4.1 32번 Harness-aware Context Engineering 과의 정합

32번에서 정의한 패턴은 다음과 같았다.

“Harness-aware Context Engineering — 하네스 내부 메커니즘을 직접 만들지 않지만, 그 메커니즘의 한계·편향·부작용을 예측해 Context 층에서 방어적으로 설계하는 접근.”

Part 2 의 4 계층이 정확히 이 패턴이다. AWS Deep Insight 는:

  • Layer 1·2 는 32번의 패턴 그대로 (격리·프롬프트 차원의 방어)
  • Layer 3 은 32번을 인프라 차원으로 격상 (파일 시스템으로 외부화)
  • Layer 4 는 32번에 추가 — overflow 자체를 다루는 안전장치

즉 Part 2 는 32번 패턴의 산업 사례 + 확장 이다.

4.2 31번 동심원 모델과의 관계

4 계층이 31번 동심원 어디에 위치하는가.

┌─────────────────────────────────────────────────────────┐
│  Harness                                                 │
│   (Part 3 = 34번 포스트의 영역)                            │
│  ┌─────────────────────────────────────────────────┐  │
│  │  Context — 4 계층 방어 (이 글의 영역)              │  │
│  │  ┌────────────────────────────────────────┐    │  │
│  │  │  Prompt — 8 에이전트 시스템 프롬프트    │    │  │
│  │  │  (Part 1 = 35번 포스트의 영역)          │    │  │
│  │  └────────────────────────────────────────┘    │  │
│  └─────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────┘

3 계층이 Part 1·2·3 으로 깔끔히 분담된다. Part 2 가 가장 풍부한 영역 인 이유는 Context 층이 Prompt 와 Harness 사이의 가장 활발한 엔지니어링 격전지이기 때문이다.

5 Layer 1 — 멀티 에이전트 Context 격리

5.1 단일 에이전트의 한계

Part 2 본문은 다음과 같이 단일 에이전트의 한계를 정리한다.

“단일 에이전트로 작업하면 사용자 요청부터 데이터 탐색, 분석, 차트 생성, 검증, 리포트까지 모든 정보가 하나의 Context 에 누적되어 쉽게 Context window 를 넘긴다.”

5.2 멀티 에이전트의 효과 — 25K 토큰 한계

Multi-Agent 구조에서는 각 에이전트가 독립 Context 를 사용한다. 결과:

“가장 많은 Context 를 사용하는 Coder 에이전트조차 전체 Context 가 25K 토큰을 넘지 않는다.”

200K 윈도우의 모델에서 25K 토큰은 12.5% 사용. 단일 에이전트가 150K 까지 채우는 것과 비교하면 약 1/6 수준 으로 절약된다.

각 에이전트는 자신에게 필요한 정보만 받아 작업하고, 다른 에이전트에게는 자신의 작업이 완료되었다는 신호와 간단한 요약만 전달한다.

5.3 shared_state — 4 가지 정보만 공유

에이전트 간 Context 격리의 핵심은 공유 정보를 최소화 하는 것이다. Deep Insight 는 Python 딕셔너리 자료구조를 활용한 공유 변수 shared_state 를 두고, 여기에 4 가지 정보만 저장한다.

정보 내용
messages 이전 에이전트의 마지막 메시지 (전체 대화 이력 X)
clues 각 에이전트로부터 수집된 압축 요약
full_plan Planner 가 생성하고 Tracker 가 업데이트하는 체크리스트
history 에이전트명과 메시지의 간단한 이력

5.4 CLUES_FORMAT — 압축 통신의 강제

clues 는 CLUES_FORMAT 이라는 정해진 형식으로 전달된다. 수만 토큰의 전체 대화가 아니라 핵심 결과만 압축 한다.

# coder_agent_tool.py — Context 전달 형식
CLUES_FORMAT = "Here is clues from {}:\n\n<clues>\n{}\n</clues>\n\n"
RESPONSE_FORMAT = "Response from {}:\n\n<response>\n{}\n</response>\n\n*Please execute the n..."

# Coder 완료 후: clues 에 압축된 결과만 추가
clues += CLUES_FORMAT.format("coder", response["text"])

이 형식이 의미하는 바는 명확하다. 에이전트 간 통신은 자유 형식이 아니라 강제된 압축 형식 을 거친다. 형식이 없으면 LLM 이 장황한 통신을 생성할 위험이 있고, 그 비용이 누적된다.

5.5 Anthropic 권장 패턴과의 일치

Part 2 본문이 인용하는 Anthropic 권장 패턴.

“Anthropic 의 ‘How We Built Our Multi-Agent Research System’ 블로그에서도 동일한 패턴을 권장 한다. 그리고 Strands Agents SDK 의 Agents-as-tools 패턴은 이 격리를 프레임워크 수준에서 지원한다.”

Strands SDK 의 Agents-as-tools 패턴 = Anthropic 권장 패턴의 SDK 구현체. 이 패턴 덕분에 Deep Insight 팀은 격리를 직접 구현할 필요 없이 사전 구현된 패턴을 활용 했다.

5.6 31번·33번·35번 매핑

시리즈 Layer 1 매핑
31번 동심원 Context 층 “외부 데이터 주입” 의 패턴 — 단일 컨텍스트가 아닌 다중 컨텍스트의 통신
33번 Anthropic 가축 모델 8 에이전트가 모두 가축 — 한 컨텍스트 망가져도 다른 컨텍스트 유지
35번 8 에이전트 3 레이어 Layer 1 의 핵심 인프라 — 35번이 정의한 구조가 Context 차원에서 작동

6 Layer 2 — 프롬프트로 Context 유입량 제어

Layer 1 의 멀티 에이전트 격리만으로 충분하지 않다. 각 에이전트가 독립 Context 를 가지더라도, 에이전트 내부에서 불필요하게 긴 응답을 생성하면 Supervisor 의 Context 가 빠르게 누적된다.

6.1 Anthropic 의 핵심 원칙

“가장 강력한 모델과 간단한 프롬프트로 시작하라. 그리고 실제로 관찰된 실패 사례를 바탕으로 점진적으로 구체적인 지침을 추가하라.” — Anthropic, “Effective Context Engineering for AI Agents” (2025.09)

이 원칙이 Layer 2 의 출발점이다. 추상적 규칙이 아니라 관찰 기반 규칙 이 누적되어야 한다.

6.2 구현 2-1 — 에이전트별 출력 토큰 예산 명시

각 에이전트의 프롬프트에는 응답의 최대 토큰 수가 명시 되어 있다.

에이전트 출력 토큰 예산 이유
Coder 1,000 ~ 1,500 토큰 분석 코드는 파일에 저장되므로, 상태/완료 작업/인사이트 요약만 반환
Validator 800 토큰 검증 결과는 citations.json 에 저장, 요약만 반환
Reporter 1,000 토큰 보고서는 DOCX 파일로 생성, 생성 결과 요약만 반환

예산이 명시적 텍스트 라는 점이 중요하다. LLM 이 본문 안에서 자기 출력 길이를 자체 검열하도록 강제한다.

6.3 표준화된 응답 형식

Anthropic 의 “Writing Effective Tools for Agents” 블로그가 제안한 CONCISE / DETAILED 옵션을 Deep Insight 는 모든 에이전트에 동일한 표준 응답 형식으로 구현했다.

## Status
[SUCCESS | PARTIAL_SUCCESS | ERROR]

## Completed Tasks
- [Task 1 from FULL_PLAN — Tracker 가 매칭할 수 있도록 정확한 표현 사용]
- [Task 2 — 구체적으로, 일반적이지 않게]

## Key Insights
- [수치와 비율이 포함된 핵심 발견 1]
- [비즈니스 함의가 포함된 핵심 발견 2]

## Generated Files
- ./artifacts/chart.png — 간단한 설명
- ./artifacts/calculation_metadata.json — N 개의 계산

이 형식이 가져다주는 효과:

효과 설명
결정론적 파싱 Tracker 가 ## Completed Tasks 섹션을 정규표현식으로 파싱 가능
압축 강제 4 개 섹션 외 자유 서술 금지
에이전트 간 호환성 모든 에이전트가 같은 형식 → Supervisor 의 처리 로직 통일

6.4 구현 2-2 — Self-contained 코드 철학

Coder 에이전트의 프롬프트에는 “변수는 스크립트 간에 유지되지 않는다” 는 규칙이 명시된다. 즉 모든 스크립트는 필요한 import 를 전부 포함하고, 데이터를 직접 로드해야 한다.

# WRONG — Turn 1 에서 정의한 변수를 Turn 2 에서 사용 시도
# Turn 1:
df = pd.read_csv('data.csv')
total = df['Amount'].sum()

# Turn 2:
print(f"Total: {total}")  # NameError: name 'total' is not defined

# CORRECT — 모든 스크립트가 self-contained
import pandas as pd
df = pd.read_csv('./artifacts/cache/df_main.csv')  # 캐시에서 로드
total = df['Amount'].sum()
print(f"Total: {total}")

6.4.1 왜 이 규칙이 Context Engineering 인가

Part 2 본문의 핵심 통찰:

“이전 스크립트의 변수를 참조하려면 에이전트가 이전 대화를 ‘기억’ 해야 하고, 이는 Context 에 과거 코드가 계속 남아있어야 함을 의미한다. Self-contained 원칙을 통해 과거 코드를 Context 에서 안전하게 제거할 수 있다.”

즉 Self-contained 코드는 단순한 코딩 스타일이 아니라 Context 관리 전략의 일부 다. 코드가 self-contained 면 → 과거 코드가 Context 에 없어도 됨 → 과거 코드를 압축 / 제거 가능 → Context 부담 감소.

6.5 구현 2-3 — Supervisor 의 섹션 완료 규칙은 프롬프트로 강제

Supervisor 의 프롬프트에는 다음 규칙이 있다.

“현재 에이전트 섹션의 모든 체크리스트가 [x] 가 될 때까지 다음 에이전트로 넘어가지 않는다.”

이 규칙은 코드 로직이 아니라 프롬프트로 강제 된다. Part 2 본문의 설명:

“Supervisor 가 LLM 으로서 ‘plan’ 의 상태를 읽고 동적으로 판단해야 하기 때문이다. 코드로는 ‘Coder 의 작업이 의미적으로 완료되었는가’ 를 판단하기 어렵지만, 프롬프트로 지시하면 LLM 이 Tracker 에이전트의 업데이트 결과를 읽고 스스로 판단할 수 있다.”

6.5.1 하네스 미니멀리즘의 또 다른 사례

이 패턴은 34번에서 다룬 “stderr 그대로 LLM 반환” + 35번 Tracker 의 “도구 없이 LLM 추론만” 과 동형이다.

하네스 미니멀리즘의 3 사례:

  • 34번: 별도 retry 로직 없이 stderr 를 LLM 에 그대로 반환 → LLM 추론으로 자체 복구
  • 35번: Tracker 가 도구 없이 LLM 추론만으로 체크리스트 갱신
  • 36번 (이 글): Supervisor 의 섹션 완료 판단을 코드 로직 없이 프롬프트로 LLM 에 위임

세 사례 모두 LLM 의 추론 능력을 신뢰 하고 인프라를 단순화한다. AWS Deep Insight 의 일관된 설계 철학이다.

7 Layer 3 — “Context 에는 포인터만, 데이터는 파일에”

Layer 1 이 에이전트 간 격리, Layer 2 가 에이전트 내부 출력 제한을 다뤘다. 그러나 Coder 에이전트가 100 줄짜리 Python 코드를 생성하면, 그 코드 자체가 Context 에 들어온다. 프롬프트 로 “짧게 응답하라” 고 지시해도 어떤 코드는 짧게 쓸 수 없다.

Layer 3 의 본질:

“도구 설계를 통해 무거운 컨텐츠를 Context 바깥으로, 즉 파일시스템으로 내보내는 역할.”

7.1 구현 3-1 — write_and_execute_tool 로 코드를 Context 밖으로

7.1.1 문제

기존 방식: 파일 작성 tool 과 실행 tool 을 따로 호출.

단계 Context 누적
Coder 가 100 줄 코드 작성 → write_tool 호출 100 줄 코드가 Context 에 추가
다음 분석을 위해 150 줄 코드 작성 +150 줄
10 회 반복 1000 줄 이상의 코드가 Context 에 누적

7.1.2 해결

write_and_execute_tool — 코드 작성과 실행을 하나의 도구로 통합. 코드 내용이 Context 에 남지 않도록 한다.

# write_and_execute_tool.py
def _handle_write_and_execute_tool(file_path, content, timeout=300):
    """Write a Python script and immediately execute it."""
    # Step 1: Write file
    with open(file_path, 'w', encoding='utf-8') as f:
        f.write(content)

    # Step 2: Execute immediately
    result = subprocess.run(
        f"python {file_path}",
        shell=True,
        capture_output=True,
        timeout=timeout
    )

    # Return only summary
    return f"Written {len(content.split(chr(10)))} lines to {file_path}\n" \
           f"Execution successful\n" \
           f"Output: {result.stdout[:500]}"  # Only first 500 chars

7.1.3 효과

“파일을 작성하고 즉시 실행한 뒤, Context 에는 ‘105 줄을 작성했고 실행 성공했으며 5 개 카테고리 분석 완료’ 라는 요약만 반환한다. 코드 100 줄은 파일에만 저장되고, Context 에는 3 줄 정도의 요약만 남는다. 이것만으로 95% 의 토큰을 절약 할 수 있다.”

7.1.4 Anthropic 의 더 강한 사례

Part 2 는 Anthropic 의 더 극단적 사례를 인용한다.

“실행 계층에서 데이터를 먼저 필터링하면 Context 로 전달되는 토큰을 98.7% 줄일 수 있다 (150K → 2K).” — Anthropic, “Code Execution with MCP” (2025.11)

7.1.5 34번 Decision 1 의 2-step 실행과의 관계

34번에서 Fargate 의 2-step 실행 (Base64 인코딩 → 파일 저장 → subprocess) 을 분석했다. 본 글의 write_and_execute_tool 은 그 인프라적 분리의 소프트웨어 차원 동기 다.

차원 설계
Part 2 (이 글) — 소프트웨어 동기 Context 에 코드가 누적되지 않도록 도구로 통합
Part 3 (34번) — 인프라 분리 통합된 도구를 Fargate 컨테이너에서 안전 실행

7.2 구현 3-2 — Coder 공통 모듈로 토큰 낭비 방지

7.2.1 문제

데이터 분석 코드는 공통 모듈을 반복 사용한다. LLM 이 매번 새로 작성하면:

호출 토큰
첫 번째 분석에서 to_python_type(), track_calculation() 정의 20~30 줄
두 번째 분석에서 동일 함수 재정의 20~30 줄
10 개 분석 수행 200~300 줄의 중복 코드

7.2.2 해결 — 첫 작업 전 모듈 생성

Deep Insight 는 첫 작업 전에 coder_analysis_utils.py 모듈을 생성한다. 이후 모든 분석에서 import 만 한다.

# coder_analysis_utils.py — 첫 작업 시 생성되는 공통 모듈
import numpy as np
import json
from datetime import datetime

_calculations = []

def to_python_type(value):
    """numpy/pandas 타입을 Python native 타입으로 변환"""
    if isinstance(value, (np.integer, np.int64)): return int(value)
    elif isinstance(value, (np.floating, np.float64)): return float(value)
    elif isinstance(value, np.ndarray): return value.tolist()
    return value

def track_calculation(calc_id, value, description, formula,
                      source_file, source_columns, importance):
    """계산 메타데이터를 추적 — Validator 가 나중에 독립적으로 검증"""
    _calculations.append({
        "id": calc_id, "value": to_python_type(value),
        # ...
    })

7.2.3 효과

효과 설명
토큰 절약 유틸리티 함수 20~30 줄 → import 문 2 줄
일관성 보장 모든 분석이 동일 함수 사용
디버깅 용이 단일 모듈에서 수정

이 패턴은 일반 소프트웨어 엔지니어링의 DRY (Don’t Repeat Yourself) 원칙을 LLM 출력에 적용 한 사례다.

7.3 구현 3-3 — Structured Note-Taking 으로 작업물 영구 저장

7.3.1 핵심 질문

각 에이전트는 자신의 긴 작업물을 Context 로 넘기지 않고서 어떻게 서로에게 전달할까?

7.3.2 해결 — all_results.txt 누적 패턴

Deep Insight 는 all_results.txt 라는 파일에 모든 분석 결과를 구조화해 축적한다.

with open('./artifacts/all_results.txt', 'a', encoding='utf-8') as f:
    f.write(f"""
## 카테고리별 매출 분석 (완료 시각: 14:32)
- 최고 매출 카테고리: 과일 (417,166,008 원, 전체의 45%)
- 상위 3 개 카테고리: 과일, 채소, 육류 (전체의 78%)
- 생성 파일: ./artifacts/category_sales_chart.png
""")

Coder 가 분석을 완료할 때마다 상세한 결과를 이 파일에 기록한다. 이후 Reporter 가 최종 리포트를 작성할 때 이 파일을 읽어 모든 축적된 분석 결과를 활용한다.

7.3.3 효과 비교

방식 Coder → Supervisor 통신
Note-Taking 없음 매 작업마다 상세 결과를 Supervisor 에 전달 → Supervisor Context 누적
Note-Taking 사용 “카테고리별 매출 분석 완료, 주요 인사이트 3 개 발견, 상세는 all_results.txt” → 30 토큰 정도

Reporter 가 필요할 때 파일을 읽으면 된다.

7.3.4 파일 시스템 = 에이전트 간 통신 버스

이 패턴은 all_results.txt 에만 국한되지 않는다. Deep Insight 는 파일 시스템 자체를 에이전트 간 통신 버스로 활용 한다.

파일 작성자 소비자 역할
all_results.txt Coder Reporter 분석 결과 누적 기록
calculation_metadata.json Coder Validator 수치 계산의 출처/수식/값 기록 (검증용)
citations.json Validator Reporter 검증된 인용 데이터 (보고서에 [1], [2] 삽입)
coder_analysis_utils.py Coder 모든 스크립트 공유 유틸리티 함수 (한 번 작성, 반복 import)
full_plan (shared_state) Planner / Tracker Supervisor 체크리스트 상태 ([x] 업데이트)

5 개 파일이 5 가지 통신 채널이 된다. 메시지 큐나 별도 IPC 인프라 없이 파일 시스템만으로 에이전트 간 통신이 작동한다.

7.3.5 Anthropic 의 핵심 원칙

“필요 시점에 로딩하는 것이 사전 전체 로딩보다 우수하다.” — Anthropic, “Effective Context Engineering for AI Agents” (2025.09)

Note-Taking 의 본질은 이 원칙의 구현이다. 모든 정보를 Context 에 사전 로딩하지 않고, 필요한 순간에만 파일에서 읽어온다.

7.3.6 32번 Harness-aware Context Engineering 과의 정확한 일치

32번에서 정의한 패턴.

“응답 텍스트로 정보 보존 — 모델 응답 자체를 정보 보존 매체로 활용”

Deep Insight 의 Note-Taking 은 이 패턴의 인프라 차원 격상 이다. 32번이 모델 응답에 정보를 담는다면, AWS 는 그 정보를 다시 파일에 외부화한다. 같은 패턴, 더 영속적인 구현.

7.4 구현 3-4 — Claude Skills 로 필요한 지식만 로드

7.4.1 문제

모든 전문 지식 (PDF 처리, DOCX 생성, XLSX 분석, 데이터 시각화, 통계 분석, 리포트 작성 등) 을 시스템 프롬프트에 넣으면:

항목 비용
시스템 프롬프트 150K 토큰
모든 에이전트가 불필요한 정보까지 로드 Context window 압박
새 Skill 추가 모든 에이전트 재배포 필요

7.4.2 해결 — Skills 시스템 (Lazy Loading)

Deep Insight 의 Skills 시스템은 다르게 작동한다.

단계 동작
에이전트 시작 시점 5K 토큰의 기본 지침만 로드 + skill 카탈로그 (이름·간단 설명만)
사용자 요청 분석 에이전트가 “readme-generator skill 이 필요” 판단
Skill 호출 skill_tool(skill_name="readme-generator")
SkillLoader readme-generator/SKILL.md 파일을 읽어 15K 토큰 가이드 반환

7.4.3 Skill 정의 형식

각 Skill 은 YAML frontmatter + 마크다운 가이드 로 구성된 SKILL.md 파일이다.

---
name: readme-generator
description: README 파일 자동 생성
license: MIT
allowed-tools: [file_read, write_and_execute_tool]
---

# README Generator

## Overview
...

## When to Use This Skill
...

## 상세 지침
...

## Best Practices
...

새 skill 추가는 skills/ 디렉토리에 새 폴더를 만들고 SKILL.md 작성 만 하면 자동 발견된다.

# 1. Skill Discovery (초기화 시)
from src.utils.skills.skill_utils import initialize_skills

available_skills, skill_prompt = initialize_skills(
    skill_dirs=["./skills"],
    verbose=True
)

# 2. System Prompt 에 추가 (5K 토큰의 카탈로그만)
system_prompt = base_prompt + skill_prompt

# 3. 런타임 — Agent 가 필요할 때 skill 로드
# Agent 가 판단: "README 작성이니 readme-generator skill 이 필요하겠군"
# → skill_tool(skill_name="readme-generator")
# → SKILL.md 전체 내용 반환 (15K tokens)

7.4.4 효과

“초기 시스템 프롬프트는 95% 작게 유지하면서, 필요할 때 15K 토큰을 추가로 사용하는 방식으로 유연성과 효율성을 모두 확보.”

비교 토큰
모든 Skill 사전 로드 150K
Lazy Loading 시작 5K (95% 절감)
필요 시점 로드 +15K (필요한 1 개 Skill)

7.4.5 32번 Skill-based Pattern 의 산업 검증

32번에서 다룬 Skill-based Prompt Engineering 의 cross-cutting concern 패턴이 정확히 이 구현이다. AWS 는 같은 패턴을 자체 SDK 에 통합했다.

비교 32번 (이 블로그) Deep Insight
Skill 정의 guides/*.md + Claude Code .claude/commands/*.md skills/*/SKILL.md (YAML frontmatter)
Skill 카탈로그 AGENT_GUIDE.md 라우팅 테이블 skill_prompt 자동 생성
Lazy Loading Claude Code Skill tool skill_tool(skill_name=...)
자동 발견 디렉토리 스캔 디렉토리 스캔

같은 패턴이 다른 SDK 로 구현된다는 것이 검증된다.

8 Layer 4 — 검증 에이전트와 안전장치

Layer 1·2·3 으로 Context 를 효율적으로 관리하더라도 한 가지 근본적 위험이 남는다. Multi-Agent 구조에서 Context 를 격리하면 각 에이전트가 다른 에이전트의 작업을 직접 볼 수 없다. Coder 가 계산을 잘못해도 Reporter 는 그 결과를 그대로 보고서에 넣게 된다.

Layer 4 의 본질:

“검증 도구를 제공하여 에이전트가 자신의 작업을 검증할 수 있도록 하라. 진행 상황을 명시적으로 체크포인트하라.” — Anthropic, “Effective Harnesses for Long-Running Agents” (2025.11)

8.1 구현 4-1 — Tracker / Validator

에이전트 역할 출력
Tracker plan 의 체크리스트를 실시간 업데이트 → 진행 상황 투명 관리 업데이트된 full_plan
Validator Coder 가 수행한 수치 계산을 독립적으로 재실행 → 정확성 보장 citations.json

8.1.1 Validator 의 동작 (35번에서 이미 다룸 — 여기서는 짧게)

  • calculation_metadata.json 을 읽고 소스 데이터에서 재계산
  • 0.01 오차 범위 내 일치 시 통과, 불일치 시 플래그
  • 검증된 계산은 citations.json 에 저장 → Reporter 가 인용으로 포함

8.2 구현 4-2 — OptimizedValidator (우선순위 기반 최적화)

8.2.1 문제

모든 계산을 검증하는 것은 비효율적이다. 100 개 계산에 100 회 검증을 수행하면 시간·비용 부담이 크다.

8.2.2 해결 — 우선순위 기반 동적 필터링

Deep Insight 의 OptimizedValidator 는 계산의 중요도 (importance) 에 따라 검증 범위를 동적으로 조절한다.

계산 수 검증 정책
50 개 초과 공격적 필터링 — high 전체 + medium 10 개
20 개 초과 보통 필터링 — high 전체 + medium 15 개
20 개 이하 대부분 검증 — high + medium 전체 + low 5 개

이 정책의 본질은 Validator 자체에도 Context 예산이 있다 는 인식이다. Layer 1~3 으로 다른 에이전트의 Context 를 절약했어도 Validator 가 무한정 검증하면 그 자체가 병목이 된다.

8.2.3 타입 안전 비교

# validator.md — 타입 안전 수치 비교
try:
    match = abs(float(expected) - float(actual)) < 0.01
except:
    match = str(expected) == str(actual)

numpy 타입과 Python native 타입 간 비교 문제를 해결하기 위해, 모든 값을 float() 으로 변환한 후 절대값 차이가 0.01 미만인지 확인. try/except 로 변환 실패 시 문자열 비교로 fallback.

작은 코드지만 Validator 의 신뢰성 의 근간이 된다. numpy float64 와 Python float 가 비교 실패로 잘못된 불일치 플래그를 만들면 시스템 전체 신뢰가 떨어진다.

8.3 구현 4-3 — SummarizingConversationManager (최후의 안전장치)

8.3.1 문제

위의 모든 기법을 적용해도 예외적인 상황에서 Context 가 overflow 될 수 있다.

8.3.2 해결 — Strands SDK 의 SummarizingConversationManager

Deep Insight 는 Strands Agents SDK 가 제공하는 SummarizingConversationManager 를 안전장치로 사용한다.

# strands_sdk_utils.py — 에이전트 생성 시 안전장치 설정
agent = Agent(
    model=llm,
    system_prompt=system_prompts,
    tools=tools,
    conversation_manager=SummarizingConversationManager(
        summary_ratio=0.5,           # overflow 시 가장 오래된 50% 를 요약
        preserve_recent_messages=10,  # 최근 10 개 메시지는 항상 보존
        summarization_system_prompt=apply_prompt_template("summarization", {})
    )
)

8.3.3 동작 메커니즘

시점 동작
Context window 초과 직전 가장 오래된 메시지의 50% 를 LLM 으로 요약 → 하나의 메시지로 대체
최근 10 개 메시지 항상 보존 (현재 작업 맥락 유지)
summarization.md 프롬프트 clues, plans, tracking status 를 반드시 원문 보존하도록 지시

핵심은 요약 정책에 protected zone 이 있다 는 점이다. clues, plans, tracking status 는 시스템의 운영 상태이므로 요약 대상에서 제외해야 한다. 그렇지 않으면 요약 후 Tracker 가 plan 을 잃는 등의 연쇄 실패가 발생한다.

8.3.4 32번 Protected Zone 패턴의 산업 사례

32번에서 정의한 “절대 규칙 5 개의 중복 배치” 패턴 + 30번에서 다룬 Copilot CLI 의 protected zone 추정과 정확히 같은 사상이다.

차원 32번 30번 추정 Part 2 (이 글)
보호 대상 절대 규칙 5 개 Custom instruction 파일 clues, plans, tracking status
보호 메커니즘 3 곳에 중복 배치 압축 대상 제외 요약 프롬프트가 원문 보존 강제
실패 시 결과 가이드 누락 규칙 손실 시스템 운영 상태 손실

세 사례가 같은 패턴이다. 시스템 운영의 핵심 정보는 어떻게든 보호 되어야 한다.

8.4 구현 4-4 — 선택적 프롬프트 캐싱 (Part 1 과 중복, 짧게)

35번 (Part 1) 에서 자세히 다룬 프롬프트 캐싱 매트릭스가 Layer 4 에도 등장한다. 캐싱은 단순한 비용 최적화가 아니라 Context 처리의 안정성 에도 영향을 준다.

에이전트 Prompt Cache Tool Cache 이유
Supervisor Yes Yes 반복 호출, 시스템 프롬프트·도구 정의 큼
Coder Yes Yes 여러 분석 스크립트 순차 실행, 매번 동일 프롬프트
Reporter Yes Yes 섹션별 점진적 보고서 생성, 프롬프트 재사용
Coordinator No No 단 한 번 호출
Validator No No 매번 다른 데이터
Tracker No No 경량 작업

캐싱은 시스템 프롬프트와 도구 정의에 cache point 를 삽입 하여 반복 호출 시 입력 토큰 비용 최대 90% 절감. Strands Agents SDK 가 네이티브 지원.

9 4 계층 방어 체계의 종합 — 토큰 절감률 매트릭스

각 기법의 정량적 효과를 한 표로 정리한다 (Part 2 본문에 명시된 수치).

계층 기법 절감률 / 효과
Layer 1 멀티 에이전트 격리 단일 에이전트 150K → 25K (Coder 기준) — 약 83% 절감
Layer 2 출력 토큰 예산 (정량 미명시 — 표준화 효과)
Layer 2 Self-contained 코드 과거 코드 Context 제거 가능 (정량 미명시)
Layer 3 write_and_execute_tool 95% 절감 (코드 100 줄 → 요약 3 줄)
Layer 3 MCP 데이터 필터링 (Anthropic) 98.7% 절감 (150K → 2K)
Layer 3 Claude Skills lazy loading 95% 절감 (시스템 프롬프트 150K → 5K)
Layer 4 OptimizedValidator (계산 수에 따라 동적 — high/medium/low)
Layer 4 선택적 프롬프트 캐싱 최대 90% 절감 (입력 토큰 비용)

각 기법이 다른 차원의 절감을 만들고, 곱셈 효과로 작용한다. 결과적으로 200K 윈도우의 모델에서 Coder 가 25K 미만, 1 세션 비용 ~$4.13 (34번 분석) 이라는 효율이 나온다.

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

본 글이 시리즈의 마지막이므로, 31~35번과 본 글 (36번) 의 통합 매핑을 정리한다.

10.1 31번 동심원 모델

31번 정의 Part 2 검증
Context Engineering = “무엇을·언제·얼마나 보여줄지” 결정 4 계층 방어 체계가 정확히 그 정의의 산업 사례
RAG ≠ Context Engineering Layer 3 의 Note-Taking 이 RAG 가 아닌 Context Engineering 의 한 사례
동심원 포함 관계 Context 층 구현이 Prompt(Part 1) 와 Harness(Part 3) 의 가운데 위치

특히 31번에서 “Context Engineering 의 범위” 표를 만들 때 외부 데이터 주입 (RAG), 대화 히스토리 관리, Tool result 배치, 시스템 프롬프트 조립, 윈도우 예산 배정, Long-context 전략 6 가지를 나열했다. Part 2 는 그 6 가지 중 5 가지를 모두 다룬다.

31번 Context 범위 Part 2 의 구현
외부 데이터 주입 (Layer 3 의 파일 외부화로 변형)
대화 히스토리 관리 Layer 4 SummarizingConversationManager
Tool result 배치 Layer 2 표준화된 응답 형식
시스템 프롬프트 조립 Layer 3 Claude Skills lazy loading
윈도우 예산 배정 Layer 2 출력 토큰 예산 + Layer 1 25K 한계
Long-context 전략 (전체 4 계층이 long-context 회피 전략)

10.2 30번 Trade-off 우회

30번에서 정리한 5 대 축을 본 글 4 계층이 어떻게 우회하는가.

30번 5 대 축 Claude Code 약점 Part 2 의 우회
Auto-compaction 자동 압축으로 정보 손실 Layer 4 SummarizingConversationManager — 명시적 압축 + protected zone
Tool result lifecycle clear 되어 후반 참조 불가 Layer 3 Note-Taking — 영속 파일 보존
응답 길이 제약 25/100 단어 강제 Layer 2 출력 토큰 예산 — 명시적·에이전트별
Skill 로딩 Eager 메타로 컨텍스트 폭발 Layer 3 Skills lazy loading — 카탈로그만 5K
Protected zone 불확실 Layer 4 요약 프롬프트의 보호 영역 명시

5 대 축이 모두 우회된다. Claude Code/Copilot CLI 의 trade-off 는 단일 LLM 가정에서 발생 인데, 8 에이전트 + 4 계층으로 분리하면 trade-off 자체가 분해된다는 30번의 결론이 다시 검증된다.

10.3 32번 Harness-aware Context Engineering 의 산업 검증

32번에서 정의한 패턴이 본 글에서 어떻게 격상되는가.

32번 패턴 Deep Insight 의 격상
응답 텍스트로 정보 보존 Layer 3 Note-Taking — 응답 → 파일로 한 단계 더 외부화
의도된 redundancy Layer 4 SummarizingConversationManager 가 clues/plans/tracking status 를 보호
CP-1/2/3 출력 의무 Layer 2 표준화된 응답 형식 (## Status / ## Completed Tasks / …)
절대 규칙 중복 배치 Layer 4 protected zone 정책

32번 패턴이 4 가지 항목 모두 본 글에 대응된다. Harness-aware Context Engineering 이 학술 정의가 아닌 실제 산업 사례에서 동작한다 는 사후 검증이다.

10.4 33번 산업 카탈로그

33번 사례 Part 2 매핑
OpenAI 7 도구 — Repository 문서화 Layer 3 파일 시스템 통신 버스 (5 파일)
OpenAI 7 도구 — 관측 가능성 Layer 4 Tracker 진행 상태
Anthropic 가축 모델 4 계층이 모두 가축 — 한 계층 망가져도 다음이 보완
누비다 3 AI 분리 Deep Insight 가 8 에이전트 + 4 계층으로 더 세분화
동료 스킬 페르소나 (해당 없음 — Deep Insight 는 페르소나 미구현)

33번에서 분석한 4 가지 트렌드가 Part 2 에서 통합 구현된다.

10.5 34번·35번 (Deep Insight 시리즈의 다른 부)

본 글이 34번·35번과 어떻게 연결되어 시리즈를 완성하는가.

차원 35번 (Part 1) 36번 (Part 2 — 본 글) 34번 (Part 3)
다루는 질문 무엇을 만드는가 어떻게 토큰을 다루는가 어디서 안전하게 실행하는가
31번 층위 Orchestration + Prompt Context Harness
핵심 산출물 8 에이전트 3 레이어 + Strands 패턴 4 계층 방어 + 정량 절감 매트릭스 AgentCore + Fargate + S3 + VPC
시간 차원 책임 분담 (계획·실행) 토큰 차원 (Context window 관리) 공간 차원 (격리·네트워크)
검증 도구 LG ChatInsight 288 배 Anthropic 5 편 권장 패턴 일치 22.5 분 / 79 Fargate / $4.13

세 부의 분담이 명확하다. Part 1 = 시스템 / Part 2 = 토큰 / Part 3 = 인프라.

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

11.1 한계 1 — Anthropic 권장 패턴에 대한 의존

Part 2 가 5 회 인용하는 Anthropic 권장 패턴.

인용 출처 발행
Effective Context Engineering for AI Agents 2025.09
Code Execution with MCP 2025.11
How We Built Our Multi-Agent Research System (시기 불명)
Writing Effective Tools for Agents (시기 불명)
Effective Harnesses for Long-Running Agents 2025.11

이 의존성은 양면적이다.

측면 평가
강점 산업 표준에 부합, 검증된 패턴
약점 Anthropic 의 입장에 종속, 다른 모델 (GPT, Gemini, Llama) 에서의 차이 미검증

특히 “Context window 에 토큰이 많아질수록 모델이 정보를 정확히 기억하는 능력이 감소한다” 는 주장은 모델별·태스크별로 차이가 있다 (예: long-context 모델의 needle-in-haystack 성능). Anthropic 의 일반화를 다른 모델에 그대로 적용할 때 주의가 필요하다.

11.2 한계 2 — Strands Agents SDK 의존

SummarizingConversationManager, Agents-as-tools, Prompt Caching 모두 Strands SDK 네이티브 기능이다. 다른 SDK (LangGraph, AutoGen, CrewAI) 에서 동일 기법 구현 시 디테일이 다르며, 본 글 은 Strands 를 전제한 코드를 보여준다.

다른 SDK 의 대응 기능:

기능 Strands LangGraph AutoGen
Conversation Manager SummarizingConversationManager Custom checkpointer BufferingConversation
Agents-as-tools 네이티브 Subgraph Tool registration
Prompt Caching 네이티브 Anthropic SDK 직접 Anthropic SDK 직접

같은 패턴을 다른 SDK 로 구현 가능하지만, 코드 형태가 다르다.

11.3 한계 3 — 정량 수치의 출처 검증 부족

본 글이 인용하는 정량 수치 (95% 절감, 90% 절감, 98.7% 절감, 25K 토큰, 150K 토큰) 는 Part 2 본문 명시이지만, 다음이 검증 부족이다.

수치 검증 부족 영역
Coder 25K 토큰 어떤 분석 복잡도 기준인가, 평균 / 중앙값 / 최악 케이스인가
95% 토큰 절감 (write_and_execute_tool) 100 줄 / 3 줄 비교는 단일 사례 — 평균 절감률은 다를 수 있음
98.7% 절감 (Anthropic MCP) “150K → 2K” 의 데이터셋 컨텍스트 미명시
90% 절감 (캐싱) “최대 90%” 는 cache hit 시점 — 평균 hit rate 는 별도

이 수치들은 유리한 케이스의 사례 일 가능성이 있다. 절감률을 자기 시스템에 일반화할 때 보수적으로 가정하는 것이 안전하다.

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

위 한계에도 불구하고, SDK·모델·도메인과 무관하게 일반화 가능한 패턴 은 다음 5 가지다.

패턴 본질 적용 영역
계층적 방어 상위 계층이 놓친 부분을 다음 계층이 보완 모든 Context Engineering
공유 변수 최소화 4 가지만 (messages/clues/full_plan/history) 공유 모든 multi-agent
표준화된 응답 형식 자유 서술 금지, 결정론적 파싱 가능 형식 모든 에이전트 통신
파일 시스템 = 통신 버스 별도 IPC 인프라 없이 파일로 에이전트 간 통신 모든 분산 워크플로우
Lazy loading + protected zone 시작은 가볍게, 필요 시 로드, 핵심 정보 보호 모든 Skill / 도구 시스템

이 5 가지는 AWS 가 아니어도, Strands SDK 가 아니어도 적용 가능하다.

12 Deep Insight 시리즈 완성 — 31~36 통합 정리

본 글로 24-Agent-Architecture 시리즈의 7 개 글이 완성된다. 통합 정리.

12.1 시리즈 전체 지도

┌─────────────────────────────────────────────────────────────┐
│ 31번 — Prompt · Context · Harness 세 층위 정의                  │
│   ↓                                                         │
│ 32번 — AGENT_GUIDE 체계 3 층 해부, Cross-cutting Concern        │
│   ↓                                                         │
│ 30번 — Claude Code vs Copilot CLI 5 대 축 trade-off            │
│   ↓                                                         │
│ 33번 — 산업 사례 카탈로그 (OpenAI/Anthropic/누비다)              │
│   ↓                                                         │
│ ┌── AWS Deep Insight 시리즈 (단일 시스템 심층 분석) ──┐         │
│ │  35번 — Part 1: 8 에이전트 3 레이어 (시스템)         │         │
│ │  36번 (이 글) — Part 2: 4 계층 Context Engineering   │         │
│ │  34번 — Part 3: 3 가지 인프라 결정 (인프라)          │         │
│ └─────────────────────────────────────────────────────┘     │
└─────────────────────────────────────────────────────────────┘

12.2 각 포스트의 핵심 기여

번호 핵심 기여
31 동심원 정의 — 학술적 출발점
32 Harness-aware Context Engineering 명명 — 자체 패턴 정형화
30 5 대 축 trade-off — 단일 LLM 한계
33 산업 카탈로그 — 외부 사례 종합
35 Deep Insight 시스템 — 8 에이전트 3 레이어
36 Deep Insight Context — 4 계층 방어
34 Deep Insight 인프라 — 3 가지 결정

12.3 시리즈가 대답한 핵심 질문 5 가지

  1. 하네스 엔지니어링이란 무엇인가 — 31번 (정의) + 33번 (산업 정의)
  2. 단일 LLM 의 한계는 어디서 오는가 — 30번 (trade-off) + 36번 (Context window)
  3. 이 한계를 어떻게 우회하는가 — 32번 (자체 패턴) + 35번·36번·34번 (AWS 통합 사례)
  4. 어떤 패턴이 산업 표준으로 수렴 중인가 — 33번 (카탈로그)
  5. 개인 / 소규모 팀이 어디까지 따라할 수 있는가 — 32번 (자체 한계) + 34번/35번/36번 (Critical Reading)

5 가지 질문에 7 개 글이 분담해 답한다.

12.4 향후 작업

작업 위치
LangGraph vs Strands Agents SDK 비교 신규 포스트 (37번 후보)
Deep Insight 의 LangGraph 포팅 분석 신규 포스트
Anthropic 5 편 권장 패턴 원문 분석 신규 시리즈 가능
페르소나 + 분리 엔지니어링 (33번 4 단계) 의 외부 사례 추적 33번 보강 또는 신규

13 결론

13.1 한 문장 요약

AWS Deep Insight Part 2 의 4 계층 Context Engineering — Layer 1 (멀티 에이전트 격리, 25K 토큰) + Layer 2 (출력 토큰 예산·표준 응답·Self-contained 코드) + Layer 3 (95% 절약 write_and_execute_ tool, 파일 통신 버스, Skills lazy loading) + Layer 4 (Validator 0.01 오차, OptimizedValidator 우선순위, SummarizingConversationManager 50% 요약, 선택적 캐싱 90% 절약) — 는 32번에서 정의한 Harness-aware Context Engineering 패턴의 산업 사례 + 격상이며, Anthropic 의 5 편 권장 패턴이 한 시스템에 통합 구현된 검증 사례다.

13.2 시리즈 갱신 정리

시리즈 Part 2 사례로 인한 갱신
31번 동심원 Context 층의 6 가지 범위 중 5 가지가 Part 2 의 4 계층에 대응됨이 검증
32번 Harness-aware Context Engineering 4 가지 핵심 패턴 (응답 보존·중복 배치·CP 출력·protected zone) 이 모두 산업 차원으로 격상됨
30번 trade-off 5 대 축이 4 계층으로 모두 우회됨
33번 산업 카탈로그 OpenAI 7 도구 + Anthropic 가축 모델 + 누비다 분리가 통합 검증
34번·35번 Deep Insight 시리즈 완성 (Part 1·2·3 모두 분석)

13.3 핵심 메시지 5 가지

  1. Context Engineering 은 단일 기법이 아닌 4 계층 방어 체계 — 격리·프롬프트·도구·검증이 서로를 보완하는 학문이다
  2. Coder 25K 토큰 한계가 가능한 이유 — 4 계층이 곱셈 효과로 작용해서 단일 에이전트 150K 대비 약 1/6 수준
  3. Anthropic 권장 패턴의 산업 검증 — 5 편 (Effective Context Engineering, Code Execution with MCP, Multi-Agent Research, Writing Effective Tools, Effective Harnesses) 의 패턴이 한 시스템에 통합 구현됨
  4. 하네스 미니멀리즘의 3 사례 (34번 stderr 반환 + 35번 Tracker LLM 추론 + 36번 Supervisor 섹션 완료 프롬프트) — AWS Deep Insight 의 일관된 설계 철학
  5. 파일 시스템이 에이전트 통신 버스 — 별도 IPC 인프라 없이 5 개 파일 (all_results.txt, calculation_metadata.json, citations.json, coder_analysis_utils.py, full_plan) 로 에이전트 간 통신이 작동

13.4 한계와 다음 단계

  • Anthropic 권장 패턴 원문 미참조: 5 편의 원문은 추후 별도 시리즈로 다룰 가치
  • Strands SDK 의존: LangGraph / AutoGen 비교 분석 필요
  • 정량 수치의 일반화 한계: 95%/90%/98.7% 는 유리한 케이스 — 자기 시스템에 보수적 가정
  • 개인 / 소규모 팀이 따라할 핵심 5 패턴: 계층적 방어·공유 변수 최소화·표준 응답·파일 통신·Lazy loading + protected zone

14 관련 주제

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

Deep Insight 시리즈 (본 글로 완성)

관련 아키텍처 분석

LangGraph 비교 (대안 SDK 분석 — placeholder)

15 참고문헌

15.1 1 차 자료 (AWS 공식)

  • AWS Korea SA Team (Yoonseo Kim, Jesam Kim, Jiyun Park, Kyutae Park, Gonsoo Moon, 곽영화). (2026.4.8). Context Window 한계를 넘어서 – Deep Insight 개발 여정으로 배우는 Context Engineering 실전 기법 (Part 2/3). AWS 기술 블로그. https://aws.amazon.com/ko/blogs/tech/context-engineering-from-deep-insight/
  • AWS Korea SA Team. (2026.4.1). Deep Insight Part 1 — 5 가지 문제와 8 에이전트 3 레이어 아키텍처. AWS 기술 블로그. — 본 블로그 35번 포스트 분석 대상
  • AWS Korea SA Team. (2026.4.22). 하네스 엔지니어링으로 본 Deep Insight (Part 3/3). AWS 기술 블로그. — 본 블로그 34번 포스트 분석 대상

15.2 Anthropic 권장 패턴 (Part 2 본문 인용)

  • Anthropic. (2025.09). Effective Context Engineering for AI Agents. (본 글 5 회 인용)
  • Anthropic. (2025.11). Code Execution with MCP. (98.7% 토큰 절감 사례)
  • Anthropic. (2025.11). Effective Harnesses for Long-Running Agents. (검증 도구 권장)
  • Anthropic. How We Built Our Multi-Agent Research System. (Multi-Agent 격리 패턴)
  • Anthropic. Writing Effective Tools for Agents. (CONCISE / DETAILED 응답 옵션)

15.3 오픈소스

  • AWS Samples. (2026). sample-deep-insight. GitHub. https://github.com/aws-samples/sample-deep-insight

15.4 Strands Agents SDK

  • AWS. (2025). Strands Agents SDK Documentation. (SummarizingConversationManager, Agents-as-tools, Prompt Caching 등의 정의 출처)
  • AWS. (2025). Strands SDK GitHub Repository.

15.5 Amazon Bedrock 공식 문서

  • Amazon. (2025). Claude on Amazon Bedrock — Prompt Caching. https://docs.aws.amazon.com/bedrock

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

  • LangChain. (2024). LangGraph Documentation. https://langchain-ai.github.io/langgraph
  • Microsoft. (2024). AutoGen Documentation.
  • CrewAI. (2024). CrewAI Framework.
출처 검증 주의

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

  • Anthropic 의 5 편 권장 패턴 원문은 본 글 작성 시점 미참조 — Part 2 본문에서 직접 인용한 문장만 다룸. 원문 분석은 별도 시리즈로 가능
  • 정량 수치 (95%, 90%, 98.7%, 25K 토큰) 는 Part 2 본문 명시 — 자기 시스템에 일반화할 때 보수적 가정 권장 (유리한 케이스 가능성)
  • Strands Agents SDK 와 LangGraph / AutoGen 의 동일 패턴 구현 비교는 본 글 범위 밖

본 글의 결론은 Part 2 본문에 직접 명시된 정보에 한정한다. Anthropic 권장 패턴의 원문 분석, 다른 SDK 비교, 페르소나 차원 (33번 4 단계) 의 추가 사례 추적은 별도 포스트로 다룰 가치가 있다.

Subscribe

Enjoy this blog? Get notified of new posts by email: