AWS 기술 블로그
Context Window 한계를 넘어서 – Deep Insight 개발 여정으로 배우는 Context Engineering 실전 기법
AI 에이전트를 프로덕션 수준으로 개발하는 것과 단순 데모를 만드는 것은 전혀 다른 문제입니다. 간단한 질의응답은 잘 작동하지만, 데이터 분석 후 리포트를 생성하는 것처럼 여러 단계를 거치는 실제 업무는 Context Window 한계, 성능 저하, 비용 증가 등의 벽에 부딪힙니다. 이러한 문제를 해결할 수 있는 방법으로 다양한 Context Engineering 기법들이 제안되고 있지만, 실제로 어떻게 적용해야 하는지는 여전히 많은 개발자들의 고민거리입니다.
AWS Korea SA Team은 이러한 과제를 직접 풀기 위해 ‘Deep Insight‘라는 프로덕션급 Multi-Agent 시스템을 개발했습니다. 이번 블로그 시리즈에서는 AWS Korea SA Team이 Deep Insight를 개발하며 직접 경험하고 해결한 내용을 3회에 걸쳐 공유합니다. Multi-Agent Architecturing, Structured Note-Taking 등 Anthropic이 제안한 Context Engineering 기법들을 실제 프로덕션 환경에 어떻게 적용했는지, 어떤 trade-off가 있었는지 코드와 함께 살펴보고, 이 에이전트를 AWS에 배포하고 운영하며 얻은 인사이트까지 실전에서 검증된 방법들을 상세히 다룹니다.
[시리즈 블로그 보기]
- Part 1: 프로덕션 Multi-Agent 시스템이 해결해야 할 5가지 문제 – Deep Insight 아키텍처로 배우는 실전 설계
- Part 2: Context Window 한계를 넘어서 – Deep Insight 개발 여정으로 배우는 Context Engineering 실전 기법
- Part 3: 개발에서 운영까지 – Deep Insight 에이전트를 AWS에 안전하게 배포하는 방법 (발행 예정)
첫 번째 블로그에서는 프로덕션 Multi-Agent 시스템이 해결해야 할 5가지 핵심 문제를 정의하고, Strands Agents SDK, Amazon Bedrock 및 Bedrock AgentCore, 그리고 AWS Fargate가 각각 어떤 계층의 문제를 해결하는지를 코드와 함께 소개했습니다. 이번 두 번째 블로그에서는 이 아키텍처 위에서 Context Window 한계를 극복하기 위한 4가지 계층의 핵심 기법과 구체적인 구현 방법을 다룹니다. 마지막 세 번째 블로그에서는 로컬 개발 환경에서 나아가 AWS VPC 상에 보안을 갖춘 Private 네트워크 구조로 에이전트를 배포하고 운영하기까지, 실제 운영에 필요한 모든 과정을 안내합니다.
Context Engineering이란?
Context Engineering은 LLM의 제한된 Context window 내에서 에이전트가 최고 성능을 낼 수 있도록 정보를 최적화하는 기술입니다.
Claude Sonnet 4.5 모델은 200k Context window를 제공하지만, 실제 프로덕션 환경의 복잡한 작업은 이 한계를 쉽게 초과합니다. 예를 들어 “판매 데이터를 분석해서 DOCX 리포트를 만들어줘” 라는 단순해 보이는 요청도 실제로는 데이터 로드와 탐색(5분) -> 카테고리별 매출 분석(3분) -> 시계열 분석 및 차트 5개 생성(10분) -> 통계 검사 검증(3분) -> 최종 리포트 생성(5분)으로 이어질 수 있으며, 총 15분 동안 150K 토큰 이상을 소비할 수 있습니다. 이런 작업을 단일 Context에서 처리하면 여러 문제가 발생합니다. Context window가 초과되어 중간에 실패하거나, 오래된 Context로 인해 성능이 저하되고, 오류 발생 시 전체를 재실행해야 합니다. 또한 Context가 길어질수록 중요한 정보에 대한 attention이 감소하는 문제가 발생하며, 토큰당 과금 구조에서 Context 비효율은 곧 비용 증가로 이어집니다.
“Context window에 토큰이 많아질수록 모델이 정보를 정확히 기억하는 능력이 감소합니다.”
— Anthropic, “Effective Context Engineering for AI Agents” (2025.09)
Context Engineering은 바로 이런 문제를 해결하는 실전 기술입니다. 그런데 Context Engineering은 단순한 기법 모음이 아닙니다. 아키텍처 설계부터 프롬프트 작성, 도구 구현, 검증 시스템까지 — 각 계층이 상위 계층이 놓친 부분을 보완하는 계층적 학문입니다. 이번 블로그에서는 Deep Insight가 Context를 효율적으로 관리하기 위해 적용한 4가지 계층의 Context Engineering 기법을 상세히 소개합니다.
Context Window를 넘어서는 작업을 처리하는 방법
Anthropic은 장기 실행 작업, 즉 Long-Horizon Tasks를 처리하기 위한 여러 기법들을 제안했습니다. Deep Insight는 이들을 실제 프로덕션 환경에 적용했습니다. 기법들을 개별적으로 나열하는 대신, Deep Insight가 이를 어떻게 4가지 Layer로 체계화했는지 살펴보겠습니다.
| 계층 | 접근 방식 | 핵심 원리 | 실패하는 경우 (다음 계층이 보완) |
| Layer 1: 아키텍처 | 멀티 에이전트 구조를 통해 Context 격리하기 | 큰 작업을 여러 에이전트로 분리, 각 에이전트가 독립적 Context 사용 | 격리만으로 부족한 경우
(→ Layer2로 보완) |
| Layer 2: 프롬프트 | 프롬프트로 Context 유입량 제어하기 | 행동 규칙 지정 및 출력 제어 | 프롬프트로도 부족한 경우
(→ Layer3로 보완) |
| Layer 3: 도구 | 파일 기반 Context 외부화
(“Context에는 포인터만, 데이터는 파일에”) |
무거운 컨텐츠는 컨텍스트에 의존하지 않고 파일로 분리하여 유지 | 그 외 문제가 발생하는 경우
(→ Layer4) |
| Layer 4: 검증/안전장치 | 검증 에이전트와 안전장치로 품질 보증하기 | 오류를 잡고 Context overflow를 방지하는 독립적 장치 구현 | 최종 방어선 |
각 계층을 순서대로 살펴보겠습니다. Layer 1부터 4까지, 아래에 이어지는 섹션 1, 2, 3, 4를 통해 각 계층이 왜 필요하고 이전 계층만으로는 왜 부족한지를 함께 설명합니다.
1. 멀티 에이전트 구조를 통해 Context 격리하기
전문화된 에이전트들이 각자 독립적인 Context에서 작업하고, 압축된 결과만 상위 에이전트에 전달하는 방식입니다. Deep Insight는 Coordinator, Planner, Plan Reviewer, Supervisor, 그리고 Tool Agents (Coder, Validator, Reporter, Tracker)로 구성된 계층 구조를 사용합니다.
이 구조는 Context 관리에 있어 아주 명확한 효과를 가져다 줍니다. 단일 에이전트로 작업하면 사용자 요청부터 데이터 탐색, 분석, 차트 생성, 검증, 리포트까지 모든 정보가 하나의 Context에 누적되어 쉽게 Context window를 넘기는 반면, Multi-Agent 구조에서는 각 에이전트가 독립적인 Context를 사용합니다. 그 결과 가장 많은 Context를 사용하는 Coder 에이전트조차 전체 Context가 25K 토큰을 넘지 않습니다. 각 에이전트는 자신에게 필요한 정보만 받아 작업하고, 다른 에이전트에게는 자신의 작업이 완료되었다는 신호와 간단한 요약만 전달합니다.
에이전트 간 Context 격리의 핵심은 공유 정보를 최소화하는 것입니다. Deep Insight는 Python 딕셔너리 자료구조를 활용한 공유 변수 shared_state를 두고, 여기에 4가지 주요 정보만 저장합니다.
shared_state 딕셔너리 내에 저장되는 정보:
messages: 이전 에이전트의 마지막 메시지 (전체 대화 이력이 아님)clues: 각 에이전트로부터 수집된 압축 요약full_plan: Planner가 생성하고 Tracker가 업데이트하는 체크리스트history: 에이전트명과 메시지의 간단한 이력
이 중 특히 clues는 “CLUES_FORMAT”이라는 정해진 형식으로 전달됩니다. 수만 토큰에 달하는 각 에이전트의 전체 대화가 아닌, 핵심 결과만 압축하여 전달하는 것입니다.
Anthropic의 “How We Built Our Multi-Agent Research System” 블로그에서도 동일한 패턴을 권장합니다. 그리고 Strands Agents SDK의 Agents-as-tools 패턴은 이 격리를 프레임워크 수준에서 지원합니다. 이렇게 사전 구현된 패턴을 활용함으로써 오케스트레이터가 전문가에게 위임하는 자연스러운 계층 구조를 생성하며, 각 에이전트는 자신의 Context 내에서만 작업하도록 할 수 있습니다.
2. 프롬프트로 Context 유입량 제어하기
Layer 1의 멀티 에이전트 격리만으로 충분할까요? 아닙니다. 각 에이전트가 독립적인 Context를 가지더라도, 에이전트 내부에서 불필요하게 긴 응답을 생성하면 Supervisor의 Context가 빠르게 누적됩니다. Layer 2는 프롬프트를 통해 각 에이전트의 출력을 적극적으로 제한합니다.
“가장 강력한 모델과 간단한 프롬프트로 시작하세요. 그리고 실제로 관찰된 실패 사례를 바탕으로 점진적으로 구체적인 지침을 추가하세요.“
— Anthropic, “Effective Context Engineering for AI Agents” (2025.09)
Deep Insight의 프롬프트는 단순한 역할 설명이 아니라, Context에 유입되는 토큰량을 적극적으로 제어하는 설계 도구입니다. 이러한 설계를 실제 코드에서 어떻게 구현했는지를 아래의 [구현 상세 2-1, 2-2, 2-3] 섹션에서 설명하겠습니다.
구현 상세 2-1: 에이전트별 출력 토큰 예산 명시
각 에이전트의 프롬프트에는 응답의 최대 토큰 수가 명시되어 있습니다. 이는 에이전트가 불필요하게 긴 응답을 생성하여 Supervisor의 Context를 오염시키는 것을 방지합니다.
| 에이전트 | 출력 토큰 예산 | 이유 |
| Coder | 1,000 ~ 1,500 토큰 | 분석 코드는 파일에 저장되므로, 상태/완료 작업/인사이트 요약만 반환 |
| Validator | 800 토큰 | 검증 결과는 citations.json에 저장, 요약만 반환 |
| Reporter | 1,000 토큰 | 보고서는 DOCX 파일로 생성, 생성 결과 요약만 반환 |
Anthropic의 “Writing Effective Tools for Agents” 블로그에서는 도구가 간결한 응답(CONCISE)과 상세한 응답(DETAILED)을 선택할 수 있는 옵션을 제공하여 Context 효율성을 높이라고 제안합니다. Deep Insight는 이를 각 에이전트의 시스템 프롬프트에 명시하여 구현했습니다. 모든 에이전트가 아래와 같은 동일한 표준화된 응답 형식을 사용합니다.
구현 상세 2-2: Self-contained 코드 철학 명시
Coder 에이전트의 프롬프트에는 “변수는 스크립트 간에 유지되지 않는다”는 규칙이 명시되어 있습니다. 이 규칙에 따르면 모든 스크립트는 필요한 import를 전부 포함하고, 데이터를 직접 로드해야 합니다. 프롬프트에는 아래와 같이 ‘잘못된 예시’와 ‘올바른 예시’가 함께 제공됩니다.
이 규칙이 Context engineering과 관련된 이유는, 이전 스크립트의 변수를 참조하려면 에이전트가 이전 대화를 “기억”해야 하고, 이는 Context에 과거 코드가 계속 남아있어야 함을 의미하기 때문입니다. Self-contained 원칙을 통해 과거 코드를 Context에서 안전하게 제거할 수 있습니다.
구현 상세 2-3: Supervisor의 섹션 완료 규칙 명시
Supervisor의 프롬프트에는 “현재 에이전트 섹션의 모든 체크리스트가 [x]가 될 때까지 다음 에이전트로 넘어가지 않는다”는 규칙이 있습니다. 이 규칙은 코드 로직이 아니라 프롬프트로 강제됩니다.
왜 이 규칙을 프롬프트로 지시하는 걸까요? Supervisor가 LLM으로서 ‘plan’의 상태를 읽고 동적으로 판단해야 하기 때문입니다. 코드로는 “Coder의 작업이 의미적으로 완료되었는가”를 판단하기 어렵지만, 프롬프트로 지시하면 LLM이 Tracker 에이전트의 업데이트 결과를 읽고 스스로 판단할 수 있습니다.
3. “Context에는 포인터만, 실제 데이터는 파일에”
Layer 1이 에이전트 간 격리를, Layer 2가 에이전트 내부의 출력을 제한합니다. 하지만 Coder 에이전트가 100줄짜리 Python 코드를 생성하면, 그 코드 자체가 Context에 들어옵니다. 프롬프트로 “짧게 응답하라”고 지시하더라도, 어떤 코드는 짧게 쓸 수 없는 코드도 있죠. Layer 3은 도구 설계를 통해 무거운 컨텐츠를 Context 바깥으로, 즉 파일시스템으로 내보내는 역할을 합니다. 아래 [구현 상세 3-1, 3-2, 3-3 , 3-4]에서 자세한 구현 방식을 공유합니다.
구현 상세 3-1: Write and Execute Tool로 코드를 Context 밖으로 빼기
Coder 에이전트를 구현하면서도 Context 관리에 많은 고민이 필요했습니다. Coder의 경우 Planner가 전달해준 데이터 분석 계획을 읽고, 데이터 분석을 위한 Python 코드를 작성하고, 실행하여 시각화 그래프 파일을 생성하는 역할을 합니다. 그런데 만약 생성된 코드의 길이가 너무 길어지는 경우에는 어떨까요? 기존 방식대로라면 파일 작성 tool과 실행 tool을 따로 호출해야 하고, 100줄짜리 코드가 그대로 Context에 추가됩니다. 또 다른 코드를 작성하면 또 150줄이 추가되고, 이런 식으로 Context에 1000줄 이상의 코드가 누적됩니다. 이러한 문제를 해결하기 위해 Deep Insight의 Coder 에이전트는 write_and_execute_tool 이라는 도구 구현을 통해 코드 작성과 실행을 하나의 도구로 통합하여, 코드 내용이 Context에 남지 않도록 합니다.
아래는 Coder 에이전트가 사용하는 write_and_execute_tool 도구의 실제 구현 코드 일부입니다. 파일을 작성하고 즉시 실행한 뒤, Context에는 “105줄을 작성했고 실행 성공했으며 5개 카테고리 분석 완료”라는 요약만 반환합니다. 코드 100줄은 파일에만 저장되고, Context에는 3줄 정도의 요약만 남습니다. 이것만으로 95%의 토큰을 절약할 수 있습니다. (write_and_execute_tool 코드 전체가 궁금하시다면 Deep Insight Github에서 코드를 참고하실 수 있습니다)
# 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“실행 계층에서 데이터를 먼저 필터링하면 Context로 전달되는 토큰을 98.7% 줄일 수 있습니다 (150K → 2K).”
— Anthropic, “Code Execution with MCP” (2025.11)
구현 상세 3-2: Coder 에이전트 — 공통 로직을 모듈로 재사용하기
데이터 분석 코드를 작성하다보면 공통 모듈을 반복적으로 사용하게 되는데, 이를 LLM이 매번 새 코드로 작성하게 하면 쉽게 토큰 낭비로 이어지게 됩니다. Coder 에이전트는 반복되는 토큰 생성 및 컨텍스트 반복을 방지하기 위해, 사용되는 함수를 모듈로 정의하고 import하여, 매번 재생성하지 않도록 구현되어 있습니다.
만약 첫 번째 분석에서 to_python_type()이나 track_calculation() 같은 유틸리티 함수를 정의하면, 두 번째 분석에서도 동일한 함수를 다시 정의해야 합니다. 10개 분석을 수행하면 200-300줄의 중복 코드가 발생하게 되죠. Deep Insight는 첫 작업 전에 coder_analysis_utils.py라는 모듈을 생성합니다. 이 모듈에는 numpy 타입을 Python native 타입으로 변환하는 함수, 계산 메타데이터를 추적하는 함수, JSON으로 저장하는 함수 등이 포함됩니다. 이후 모든 분석에서는 이 모듈을 import해서 사용하기만 하면 됩니다. 유틸리티 함수 20-30줄을 매번 재생성하는 대신, import문 2줄로 해결됩니다. 이로써 토큰이 절약될 뿐 아니라 일관성도 보장되고 디버깅도 쉬워집니다.
# 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),
"description": description, "formula": formula,
"source_file": source_file, "source_columns": source_columns,
"importance": importance
})
def save_calculation_metadata(path="./artifacts/calculation_metadata.json"):
"""추적된 모든 계산을 JSON으로 저장"""
with open(path, 'w', encoding='utf-8') as f:
json.dump({"generated_at": datetime.now().isoformat(),
"calculations": _calculations}, f, ensure_ascii=False, indent=2)
구현 상세 3-3: Structured Note-Taking으로 작업물 영구 저장 및 전달하기
그럼 각 에이전트는 자신의 긴 작업물을 Context로 넘기지 않고서 어떻게 서로에게 전달할까요? Deep Insight는 all_results.txt라는 파일에 모든 분석 결과를 구조화해 축적하는 Structured Note-taking 방식을 활용합니다. 즉 중요한 결과를 Context 밖, 즉 파일 시스템에 저장하고 필요할 때만 읽어오는 것이죠.
예를 들면 Coder 에이전트는 각 분석 작업을 완료한 후에 아래와 같은 로직으로 분석 내용을 all_results.txt 파일에 업데이트합니다.
Coder가 분석을 완료할 때마다 상세한 결과를 이 파일에 기록합니다. 그리고 이후 Reporter가 최종 리포트를 작성할 때가 되면 이 파일을 읽어 모든 축적된 분석 결과를 활용합니다. Coder 외의 다른 에이전트의 협업 방식도 동일하게 all_results.txt를 활용합니다.
이 방식의 효과는 명확합니다. Note-Taking 없이 작업하면 Coder가 Supervisor에게 상세한 결과를 매번 작업이 끝날 때마다 전달해야 하고, 이는 Supervisor의 Context에 계속 누적됩니다. 하지만 Note-Taking을 사용하면 “카테고리별 매출 분석 완료, 주요 인사이트 3개 발견, 상세 결과는 all_results.txt에 저장됨” 이라는 30토큰 정도의 간단한 메시지만 전달하고, Reporter가 필요할 때 파일을 읽으면 됩니다.
그리고 사실 이 패턴은 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] 업데이트) |
“필요 시점에 로딩하는 것이 사전 전체 로딩보다 우수하다.”
— Anthropic, “Effective Context Engineering for AI Agents” (2025.09)
구현 상세 3-4: Claude Skills로 필요한 지식만 로드하기
모든 전문 지식을 시스템 프롬프트에 넣지 않고, Claude Skills를 활용하여 필요할 때만 로드하는 방식입니다. PDF 처리, DOCX 생성, XLSX 분석, 데이터 시각화, 통계 분석, 리포트 작성 등 모든 가이드를 시스템 프롬프트에 포함하면 150K 토큰을 소비합니다. 모든 에이전트가 불필요한 정보까지 로드하고, Context window를 압박하며, 새로운 Skill을 추가하려면 모든 에이전트를 재배포해야 합니다.
Deep Insight의 Skills 시스템은 다르게 작동합니다. 에이전트 시작 시점에는 5K 토큰의 기본 지침만 로드하고, skill 목록에는 이름과 간단한 설명만 포함합니다. 사용자가 “README 파일 만들어줘”라고 요청하면 에이전트는 “readme-generator skill이 필요하겠군”이라고 판단하고 skill_tool(skill_name="readme-generator")를 호출합니다. 그러면 SkillLoader가 “readme-generator/SKILL.md” 파일을 읽어 15K 토큰의 상세한 가이드를 반환합니다.
# 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)
각 Skill은 YAML frontmatter와 상세한 마크다운 가이드로 구성된 SKILL.md 파일로 정의됩니다. name, description, license, allowed-tools 등의 메타데이터와 함께 Overview, When to Use This Skill, 상세 지침, Best Practices 등을 포함합니다.
새로운 skill을 추가하려면 단순히 ‘skills/’ 디렉토리에 새 폴더를 만들고 SKILL.md 파일을 작성하면 자동으로 발견됩니다.
초기 시스템 프롬프트는 95% 작게 유지하면서, 필요할 때 15K 토큰을 추가로 사용하는 방식으로 유연성과 효율성을 모두 확보할 수 있습니다.
4. 검증 에이전트와 안전장치로 품질 보증하기
Layer 1,2,3을 통해 Context를 효율적으로 관리하더라도, 한 가지 근본적인 위험이 남습니다. 멀티 에이전트 구조에서 Context를 격리하면 각 에이전트가 다른 에이전트의 작업을 직접 볼 수 없습니다. Coder가 계산을 잘못해도 Reporter는 그 결과를 그대로 보고서에 넣게 됩니다. Layer 4는 이 문제를 해결하는 최종 방어선입니다.
“검증 도구를 제공하여 에이전트가 자신의 작업을 검증할 수 있도록 하세요. 진행 상황을 명시적으로 체크포인트하세요.”
— Anthropic, “Effective Harnesses for Long-Running Agents” (2025.11)
구현 상세 4-1: Tracker/Validator 에이전트 — 진행 추적과 품질 보증하기
Tracker는 plan의 체크리스트를 실시간으로 업데이트하여 진행 상황을 투명하게 관리합니다. Coder가 데이터 로드를 완료하면 Supervisor가 Tracker를 호출하고, Tracker는 “데이터 로드 완료 (1,000 rows, 5 columns)”라는 정보를 바탕으로 plan의 해당 항목을 [ ]에서 [x]로 업데이트합니다. 이를 통해 사용자와 시스템 모두 현재 어디까지 진행되었는지 정확히 알 수 있습니다.
Validator는 Coder가 수행한 수치 계산을 독립적으로 재실행하여 정확성을 보장합니다. Coder가 생성한 calculation_metadata.json을 읽고, 각 계산을 소스 데이터에서 다시 수행하여 결과를 비교합니다. 0.01 오차 범위 내에서 일치하면 검증을 통과한 것으로 표시하고, 불일치하면 오류를 플래그합니다. 검증된 계산은 citations.json에 저장되어 Reporter가 리포트에 포함할 수 있습니다.
구현 상세 4-2: 우선순위 기반 검증 최적화
모든 계산을 검증하는 것은 비효율적입니다. Deep Insight의 OptimizedValidator 구현체는 계산의 중요도(importance)에 따라 검증 범위를 동적으로 조절합니다:
- 계산이 50개 초과 시 공격적 필터링: high 전체 + medium 10개만 검증
- 계산이 20개 초과 시 보통 필터링: high 전체 + medium 15개 검증
- 계산이 20개 이하 시 대부분 검증: high + medium 전체 + low 5개
또한 타입 안전 비교를 적용합니다. numpy 타입과 Python native 타입 간의 비교 문제를 해결하기 위해, 모든 값을 float()으로 변환한 후 절대값 차이가 0.01 미만인지 확인합니다:
구현 상세 4-3: SummarizingConversationManager — 최후의 안전장치
위의 모든 기법을 적용해도 예외적인 상황에서 Context가 overflow될 수 있습니다. 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", {})
)Context window가 초과되면, 가장 오래된 메시지의 50%를 LLM으로 요약하여 하나의 메시지로 대체합니다. 최근 10개 메시지는 항상 보존되므로 현재 작업의 맥락은 유지됩니다. 요약 프롬프트 (summarization.md)는 clues, plans, tracking status를 반드시 원문 그대로 보존하도록 지시합니다.
구현 상세 4-4: 선택적 프롬프트 캐싱을 통한 비용 최적화
Context Engineering은 토큰 절약뿐 아니라 비용 최적화도 포함합니다. Deep Insight는 에이전트별로 프롬프트 캐싱을 선택적으로 활성화합니다.
| 에이전트 | 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가 네이티브로 지원하는 기능입니다.
마무리
여기까지 이번 블로그에서는 Context window를 넘어서는 복잡한 작업을 수행하는 Deep Insight 에이전트가 Context를 효율적으로 관리하기 위한 4가지 계층의 엔지니어링 방법들을 상세히 소개했습니다.
- Layer 1 (아키텍처 수준 격리): 멀티 에이전트 구조를 통해 각 에이전트가 독립적인 Context에서 작업하고, 압축된 요약만 전달합니다.
- Layer 2 (프롬프트 기반 제어): 출력 토큰 예산, 표준화된 응답 형식, Self-contained 코드 철학으로 Context 유입량을 적극적으로 제한합니다.
- Layer 3 (파일 시스템 활용): write_and_execute_tool로 코드를 Context 밖에 유지하고, 파일 시스템을 에이전트 간 통신 버스로 활용하며, 필요한 지식만 지연 로딩합니다.
- Layer 4 (검증 및 안전장치): Validator의 독립적 계산 재검증, Tracker의 진행 상태 추적, SummarizingConversationManager의 overflow 방지, 선택적 프롬프트 캐싱으로 품질과 비용을 모두 관리합니다.
각 계층은 상위 계층이 놓친 부분을 보완하는 방어 체계를 이룹니다. 아키텍처 격리로 부족하면 프롬프트가 출력을 제한하고, 프롬프트로도 부족하면 도구가 컨텐츠를 외부에 유지하며, 그래도 문제가 발생하면 검증이 이를 잡아냅니다.
이 기법들은 Deep Insight 팀이 독자적으로 발견한 것이 아닙니다. Anthropic의 “Effective Context Engineering for AI Agents”, “Code Execution with MCP”, “How We Built Our Multi-Agent Research System” 등의 엔지니어링 블로그에서 독립적으로 권장하는 패턴과 일치하며, Strands Agents SDK에 내장된 기능(SummarizingConversationManager 구현체, 프롬프트 캐싱, Agents-as-tools 패턴)으로 구현되어 있습니다.
프로덕션에서 동작하는 에이전트를 만들 때는 LLM 모델 자체의 Context window에 의존하는 것만으로는 부족할 수 있습니다. 이 블로그가 Context Engineering 기법을 익히는 데 도움이 되길 바랍니다.
Deep Insight는 오픈소스로 공개되어 있습니다. 코드를 직접 확인하고 여러분의 도메인에 맞게 확장해 보시기 바랍니다.
- GitHub: https://github.com/aws-samples/sample-deep-insight
- Workshop: Deep Insight Workshop (한국어 | English)