🎯 컨텍스트 엔지니어링

🔄

프롬프트에서 컨텍스트로

~2024 → 2025 — 범위의 확장

PART 1 · 프롬프트에서 컨텍스트로

프롬프트에서 컨텍스트로

컨텍스트의 정의에서 엔지니어링의 등장까지

🔄

"어떻게 쓸까"에서 "무엇을 넣을까"로

모델이 보는 입력 전체가 컨텍스트입니다 — 에이전트 시대에 폭증하며 관리가 어려워졌고, 그래서 엔지니어링이 필요해졌습니다.

• 컨텍스트란 — 모델이 보는 입력 전체
• 왜 어려운가 — 에이전트의 반복 조립·폭증
• 그래서 — 컨텍스트 엔지니어링의 등장 (2025)
• 효과 — 품질과 비용을 좌우

takeaway

프롬프트 기법만으로는 한계입니다 — 모델에 무엇을 보여줄 것인가가 새로운 설계 대상이 됩니다.

PART 1 · 프롬프트에서 컨텍스트로

컨텍스트란 무엇인가

사용자가 보내는 건 질문 한 줄 — 모델이 실제로 보는 훨씬 큰 입력 전체

정의

컨텍스트(Context) = 모델이 응답을 만들기 직전에 보는 입력 전체. 시스템 프롬프트, 도구 정의, 검색 문서, 대화 기록, 메모리가 모두 포함됩니다.

사용자가 보는 것

"지난 분기 매출 요약해줘" ▍

질문 한 줄 — 약 0.03K 토큰

모델이 보는 것 — 컨텍스트

System Prompt — 역할·규칙~2K

도구 정의 20개~15K

검색된 문서 5개 (RAG)~25K

메모리 — 관련 기억~10K

대화 기록 — 이전 턴 전부~50K

"지난 분기 매출 요약해줘"0.03K

takeaway

질문은 전체 입력의 0.1%도 되지 않습니다 — 응답 품질은 나머지 99.9%, 즉 컨텍스트의 품질이 결정합니다.

PART 1 · 프롬프트에서 컨텍스트로

왜 관리가 어려워졌는가

단일 대화에서는 문제없던 컨텍스트 — 에이전트 시대의 폭증과 매 호출 달라지는 입력

프롬프트 엔지니어링 (~2024) 정적 프롬프트 1개를 잘 작성
사람이 직접 입력하는 단일 대화
기법: Few-shot, CoT, Role Prompting → 컨텍스트 엔지니어링 (2025~)
매 호출마다 동적으로 컨텍스트 조립
에이전트가 수백 번 모델 호출 — 매번 다른 입력

왜 지금 필요한가 단일 대화: 사람이 직접 프롬프트 관리
컨텍스트 = System Prompt + User Message
수동 최적화로 충분 → 에이전트: 도구 결과·메모리·검색 결과가 매번 합류
컨텍스트 = 6개 레이어의 동적 조합
자동화된 전략이 필수

PART 1 · 프롬프트에서 컨텍스트로

그래서 — 컨텍스트 엔지니어링

폭증하고 매번 달라지는 입력 — 사람이 아니라 시스템이 담당하는 설계

정의

컨텍스트 엔지니어링(Context Engineering) = 모델이 보는 전체 입력 — 시스템 프롬프트, 도구 정의, 참조 문서, 대화 기록, 메모리 — 을 시스템으로 설계하는 분야입니다. (2025년 Karpathy·Tobi Lütke가 공식화)

전체 윈도우가 대상

프롬프트 엔지니어링이 사용자 메시지 한 줄에 집중한다면, 컨텍스트 엔지니어링은 윈도우 전체를 설계.

에이전트 시대의 필수

도구 결과·메모리·검색 결과가 매 호출 합류 — 사람이 아닌 시스템이 컨텍스트를 조립.

5대 전략으로 구성

LangChain 4대 전략(Write · Select · Compress · Isolate) + 배치·형식(Optimize Format) — 검증된 전략의 조합으로 설계.

PART 1 · 프롬프트에서 컨텍스트로

컨텍스트가 결정하는 것

같은 모델, 같은 프롬프트 기법이라도 — 컨텍스트 품질이 최종 성능을 결정

68→98% 컨텍스트 최적화 전후 정확도 (Strands 자체 벤치마크 — 코드 조사 태스크)

55% context_manager="auto" 비용 절감 (같은 벤치마크 — 토큰 절반, 더 나은 결과)

Context Rot 토큰 수 증가 시 성능 하락 현상 (Chroma 연구)

🏗️

컨텍스트 윈도우 구조

6-Layer Architecture — 각 레이어가 독립 설계 대상

PART 2 · 컨텍스트 윈도우 구조

윈도우 구조

모델에 들어가는 입력의 해부도 — 레이어별 성격과 토큰 예산

🏗️

입력 = 6개 레이어의 합산

레이어마다 성격과 최적화 전략이 다릅니다 — 각각을 독립 설계 대상으로 다룹니다.

• 6-Layer — System Prompt부터 Optimize Format까지
• 토큰 소비 — 대화 기록이 최대 소비원
• 토큰 예산 — 한정된 자원의 배분
• 원칙 — 필요한 것만, 올바른 순서로

takeaway

1M 컨텍스트라도 무한이 아닙니다 — 무엇을 넣고 무엇을 뺄지가 핵심 설계 결정입니다.

PART 2 · 컨텍스트 윈도우 구조

6-Layer Architecture

모델에 들어가는 입력 = 6개 레이어의 합산 — 각각을 독립적으로 최적화

System Prompt

불변 지시어 — 역할, 규칙, 형식. 모든 호출에 고정. Prompt Caching 대상.

RAG Results

벡터 검색·키워드 검색 결과. 질문과 관련된 외부 지식. Select 전략으로 필터링.

Tool Results

에이전트가 도구를 호출한 결과. API 응답, DB 쿼리 결과. Compress로 핵심만 추출.

Memory

이전 대화 요약, 사용자 선호도, 에피소드 기억. 장기/단기 구분하여 Select.

Conversation

현재 세션의 대화 기록. Sliding Window 또는 Summarizing으로 Compress.

Optimize Format

콘텐츠 레이어가 아닌 배치 원칙 — 중요 정보는 앞뒤에(Lost in the Middle 대응).

PART 2 · 컨텍스트 윈도우 구조

요청 한 건의 토큰 소비

프로덕션 에이전트의 요청 1건을 구성하는 소비원 — 대화 기록이 최대 소비원

소비원 (대응 레이어)	토큰 규모 (예시)	특성
System Prompt	~2K	고정 — 모든 호출에 동일
Tool Definitions (System 소속)	~15K	도구 20개 기준 — 배포 시에만 변경
RAG Results	~25K	문서 5개 기준 — 질문마다 교체
Tool Results	~10K	루프가 돌수록 누적 — Compress 대상
Memory	~10K	관련 기억만 선별하여 주입
Conversation (대화 기록)	~50K+	턴마다 증가 — 최대 소비원
사용자 입력	~0.1K	매번 다름 — 가장 작지만 가장 동적

takeaway

위 예시만 더해도 요청 1건에 110K+ 토큰 — 멀티턴이 쌓이면 더 커집니다. 압축과 선별 없이는 비용이 대화 길이에 비례해 늘어납니다.

PART 2 · 컨텍스트 윈도우 구조

토큰 예산 관리

컨텍스트 윈도우 = 한정된 자원 — 무엇을 넣고 무엇을 뺄지가 핵심 설계 결정

1M 컨텍스트라도

무한이 아님

• 토큰이 많을수록 비용 선형 증가
• 중간에 묻힌 정보는 활용도 하락 (PART 4에서 상세)
• 추론 시간 증가 (KV Cache 메모리)
• 불필요한 정보 = 노이즈 = 정확도 하락

1M 토큰을 다 채우는 것이 목표가 아닙니다. 관련 없는 정보를 넣으면 오히려 성능이 떨어집니다.

필요한 것만, 올바른 순서로

설계 원칙

• 관련성 높은 정보만 Select
• 큰 결과물은 Compress하여 핵심만
• 중요한 정보는 앞/뒤에 배치 (Optimize Format)
• 독립 실행 가능한 서브태스크는 Isolate

적은 토큰으로 높은 정확도를 달성하는 것이 컨텍스트 엔지니어링의 목표입니다.

takeaway

목표는 윈도우를 채우는 것이 아니라 적은 토큰으로 높은 정확도를 내는 것입니다 — 관련 없는 정보는 노이즈입니다.

🎯

5대 전략

Write · Select · Compress · Isolate · Optimize Format

PART 3 · 5대 전략

5대 전략

컨텍스트 윈도우를 다스리는 다섯 가지 접근

🎯

Write · Select · Compress · Isolate · Optimize Format

윈도우의 서로 다른 문제를 겨냥하는 전략들 — 단일 적용이 아니라 조합이 프로덕션 표준입니다.

• Write — 명시 작성·외부 저장
• Select — 관련 정보만 선별
• Compress — 요약·오프로딩 압축
• Isolate — 서브태스크 격리
• Optimize Format — 배치·형식 최적화

takeaway

전략마다 겨냥하는 문제가 다릅니다 — 가장 큰 토큰 소비원이 어디인가가 전략의 비중을 결정합니다.

PART 3 · 5대 전략

5대 전략 범주

컨텍스트 윈도우의 서로 다른 문제를 겨냥하는 전략들

Write

• 모델에 명시적으로 정보를 작성하여 주입
• System Prompt, 가이드라인, 규칙 정의
• "모델이 모를 수 있는 것"을 직접 써준다

Select

• 관련 정보만 골라서 컨텍스트에 포함
• RAG 결과 필터링, 관련 기억만 추출
• 무관한 정보 = 노이즈 — 정확도 하락

Compress

• 긴 정보를 짧게 압축하여 토큰 절약
• 요약 · 핵심 추출 · 대화 기록 압축
• Strands: Summarizing + ContextOffloader

Isolate

• 독립 서브태스크를 분리해 위임
• 메인 컨텍스트 오염 방지
• 서브태스크마다 깨끗한 컨텍스트

Optimize Format

• 배치 순서와 형식을 최적화
• 중요 정보는 앞/뒤에 — 근거는 PART 4
• 마크다운 구조화, Checkpoint Injection

takeaway

다섯 전략은 조합해서 씁니다 — 각 전략이 다른 레이어에 적용되어 효과가 누적됩니다.

PART 3 · 5대 전략

시나리오별 1차 전략

워크로드의 최대 토큰 소비원이 어디냐에 따라 달라지는 우선 전략

시나리오	1차 전략	이유
고객 지원 챗봇 (다중 세션)	Write	세션 간 상태 지속이 필수
문서 Q&A	Select	대량 문서에서 관련 부분만
장기 실행 코딩 에이전트	Compress	대화 누적으로 윈도우 소진
멀티 도메인 업무 자동화	Isolate	도메인별 전문가 분리
반복 데이터 처리 파이프라인	Optimize Format	동일 구조 반복 최적화

takeaway

1차 전략을 정한 뒤 나머지를 얹습니다 — 대화가 길면 Compress, 문서가 많으면 Select, 도메인이 넓으면 Isolate 비중을 올립니다.

PART 3 · 5대 전략

Strands SDK 구현

5대 전략의 Strands Agents SDK 구현 대응

Write → System Prompt

Agent(system_prompt="...")
Skills 플러그인으로 JIT 주입

Select → Memory

AgentCoreMemorySessionManager
retrieval_config로 필터링

Compress → Context Manager

context_manager="auto"
Summarizing + ContextOffloader

Isolate → Subagent

Swarm, Graph
서브에이전트 위임

Optimize Format → 배치

정적 우선 프롬프트 구조
cachePoint 배치 (PART 5)

takeaway

Write는 system_prompt, Select는 Memory 검색, Compress는 context_manager, Isolate는 서브에이전트, Optimize Format은 배치 구조 — 다섯 전략 모두 대응 구현이 있습니다.

⚠️

실패 모드와 측정

Poisoning · Distraction · Confusion · Clash

PART 4 · 실패 모드와 측정

실패 모드와 측정

잘못된 컨텍스트가 만드는 4가지 실패와 그 정량 측정법

⚠️

Poisoning · Distraction · Confusion · Clash

컨텍스트가 잘못되면 모델이 아무리 좋아도 실패합니다 — 올바른 진단이 대응의 선행 조건입니다.

• Poisoning — 잘못된 정보의 오염
• Distraction — 무관한 정보의 산만
• Confusion — 모순 정보의 혼동
• Clash — 규칙과 컨텍스트의 충돌
• 측정 — 비용과 품질의 동시 추적

takeaway

실패 모드마다 대응 전략이 다릅니다 — 증상을 보고 원인을 진단해야 올바른 방어를 고를 수 있습니다.

PART 4 · 실패 모드와 측정

4대 실패 모드

컨텍스트가 잘못되면 모델이 아무리 좋아도 실패한다 — 방어해야 할 4가지

Poisoning (오염)

잘못된 정보가 컨텍스트에 포함
모델이 틀린 정보를 사실로 답변

Distraction (산만)

무관한 정보가 attention을 분산
핵심을 놓치고 엉뚱한 답변

Confusion (혼동)

비슷하지만 다른 정보가 충돌
모델이 어떤 것을 따를지 혼란

Clash (충돌)

시스템 프롬프트와 컨텍스트가 모순
규칙 위반 또는 무시

takeaway

넷 다 모델이 아니라 컨텍스트의 문제입니다 — 문서 품질, 관련성 필터, 단일 소스, 우선순위 지정으로 각각 방어합니다.

PART 4 · 실패 모드와 측정

Lost in the Middle — 중간 정보의 실종

4대 실패 모드와 별개의 구조적 현상 — 긴 컨텍스트 중간 정보의 attention 약화 (Stanford NLP)

현상

구조적 한계

• 긴 컨텍스트의 중간 정보에 attention 약화
• 앞과 뒤의 정보는 상대적으로 잘 활용
• 컨텍스트가 길수록 심해짐
• 모델 교체로 해결되지 않는 구조적 문제

Stanford NLP 연구에서 확인된 LLM의 구조적 한계입니다. 프롬프트를 잘 써도 배치가 잘못되면 정보가 실종됩니다.

대응

Optimize Format

• 중요 정보를 앞(System Prompt 직후)에 배치
• 또는 뒤(사용자 질문 직전)에 배치
• Checkpoint Injection — 5 액션마다 목표 재확인 주입
• 근본 대응은 컨텍스트를 짧게 — Compress + Select

배치 순서가 곧 전략입니다. 에이전트가 길게 실행될수록 목표 재확인 주입이 방향 이탈을 막습니다.

takeaway

중간에 넣은 정보는 없는 것과 같아질 수 있습니다 — 중요한 것은 앞뒤로 배치하고, 나머지는 줄입니다.

PART 4 · 실패 모드와 측정

측정 지표

컨텍스트 엔지니어링의 효과를 정량적으로 측정하는 방법

지표	측정 대상	개선 방향
Task Completion Rate	에이전트가 태스크를 성공적으로 완료하는 비율	컨텍스트 품질 ↑ → 완료율 ↑
Correction Rounds	사용자가 "아니, 그게 아니라"를 반복하는 횟수	관련 정보 Select ↑ → 교정 ↓
Token Cost per Task	태스크 1건 완료에 소비되는 평균 토큰	Compress ↑ → 비용 ↓
Context Hit Rate	주입된 컨텍스트가 실제 답변에 사용된 비율	Select 정밀도 ↑ → 히트율 ↑

takeaway

토큰을 줄였는데 완료율이 떨어지면 의미 없는 최적화입니다 — 비용과 품질을 쌍으로 추적합니다.

💰

Prompt Caching

반복 컨텍스트 비용 90% 절감 — 컨텍스트 최적화의 마지막 단계

PART 5 · Prompt Caching

Prompt Caching

반복 컨텍스트의 재계산을 생략하는 비용 최적화

💰

반복 컨텍스트는 한 번만 계산

고정 프리픽스를 캐시에 저장해 재계산을 생략합니다 — 컨텍스트 최적화의 마지막 단계입니다.

• 원리 — 첫 호출 기록, 이후 참조
• 요율 — 읽기 0.1× · 기록 1.25×
• 구조 — 정적 우선 프롬프트 배치
• 적용 — Converse API cachePoint

takeaway

에이전트는 같은 시스템 프롬프트를 수백 번 재전송합니다 — 캐싱만으로 반복 구간 입력 비용이 90% 줄어듭니다.

PART 5 · Prompt Caching

캐시 있음 vs 없음

반복되는 시스템 프롬프트와 고정 문서를 캐시 — 비용을 극적으로 절감

캐시 없음

매번 전체 전송

• 모든 호출에 System Prompt 전체 전송
• 고정 문서(RAG 결과)도 매번 토큰 소비
• 에이전트: 100회 호출 × 전체 비용
• 장문 시스템 프롬프트일수록 비용 폭증

에이전트가 100번 모델을 호출하면, System Prompt 4,000 토큰 × 100회 = 40만 토큰을 동일 내용에 소비합니다.

캐시 있음

첫 회만 전송, 이후 90% 할인

• 첫 호출에 캐시 생성 (cache_write 비용)
• 이후 호출은 캐시 참조 (cache_read = 90% 할인)
• 에이전트: 1회 전체 + 99회 캐시
• TTL 기본 5분 (1시간은 일부 모델 한정) 내 재사용

Claude Prompt Caching: cache_read는 input 대비 90% 저렴. 모델별 최소 토큰(Sonnet 4.6=1,024, Sonnet 4.5·Haiku 4.5·Opus 4.5+=4,096 — Bedrock 기준) 이상이면 적용됩니다.

takeaway

2회 이상 호출하면 이득입니다 — 호출 빈도가 높을수록 절감 폭이 커집니다.

PART 5 · Prompt Caching

캐시 요율과 제약

캐시는 공짜가 아님 — 기록 비용·TTL·격리 범위까지 알아야 설계 가능

항목	값	비고
캐시 읽기 (read)	입력 요율의 0.1×	반복 구간 90% 절감
캐시 기록 (write)	입력 요율의 1.25×	5분 TTL 기준 — 1시간 TTL 기록은 2×
TTL	기본 5분	캐시 적중 시 무료 갱신 — 1시간 TTL은 4.5 세대 + Sonnet 4.6 · Opus 4.6 · Opus 4.8 · Sonnet 5 · Opus 5 지원 (기록 2×)
체크포인트	최대 4개	system · toolConfig · messages 어디든 배치
최소 토큰	모델별 1,024~4,096	Sonnet 4.6=1,024 · Sonnet 4.5/Haiku 4.5/Opus 4.5+=4,096 (Bedrock 기준)
캐시 격리	Bedrock: AWS 계정 단위	Anthropic API: workspace 단위 — 조직 간 공유 없음

takeaway

기록은 1.25배 비싸지만 읽기가 0.1배입니다 — 두 번째 호출부터 이득이고, 적중이 이어지는 한 TTL은 무료로 갱신됩니다.

PART 5 · Prompt Caching

정적 우선 프롬프트 구조

고정 레이어를 상단에 쌓아 캐시하고, 가변 레이어만 하단에서 교체하는 구조

System Prompt (고정)

역할·규칙·형식 — 모든 호출에 동일 → 항상 캐시 대상

Tool Definitions (고정)

도구 스키마 목록 — 에이전트 수명 동안 변하지 않음

Reference Documents (준고정)

RAG 결과, 가이드 문서 — 세션 내 고정. cachePoint 지정

Conversation History (가변)

이전 대화 — 턴마다 증가. 캐시 어려움 → Compress 전략 적용

User Message (가변)

현재 질문 — 매번 다름. 캐시 불가

PART 5 · Prompt Caching

Prompt Caching 적용

Bedrock Converse API에서 캐시를 활성화하는 방법

import boto3

bedrock = boto3.client('bedrock-runtime', region_name='us-east-1')

response = bedrock.converse(
    modelId='us.anthropic.claude-sonnet-4-6',
    system=[
        {'text': '당신은 AWS Solutions Architect입니다. ...(긴 시스템 프롬프트)...'},
        # ① 캐시 체크포인트 — text와 같은 dict가 아니라 별도 블록 (단일 멤버 유니온)
        {'cachePoint': {'type': 'default'}},
    ],
    messages=[
        {'role': 'user', 'content': [{'text': '질문'}]}
    ],
)

# ② 응답의 usage에서 캐시 히트 확인
usage = response['usage']
# cacheReadInputTokens > 0이면 캐시 적중

• cachePoint — 여기까지의 프리픽스를 캐시하라는 표시. system · toolConfig · messages.content에 배치, 최대 4개
• 고정 레이어 바로 뒤에 삽입 — 긴 시스템 프롬프트 끝이 캐시 경계가 됨
• usage로 검증 — cacheWriteInputTokens는 첫 호출의 기록량, cacheReadInputTokens > 0이면 적중(90% 할인 구간)

PART 5 · Prompt Caching

다음 단계: 하네스 엔지니어링

컨텍스트도 결국 하네스의 일부 — 모델을 감싸는 전체 실행 환경을 설계

→

컨텍스트는 하네스의 한 레이어

프롬프트 → 컨텍스트를 마스터했다면, 이제 오케스트레이션·도구·메모리·가드레일·평가까지 포함하는 하네스 엔지니어링입니다.

• 오케스트레이션
• 도구
• 메모리
• 가드레일
• 평가
• AgentCore

takeaway

"무엇을 보여줄까"의 다음 질문은 "어떤 환경에서 실행할까"입니다 — 모델을 감싸는 실행 환경 전체의 설계로 이어집니다.