컨텍스트 엔지니어링

🔄

프롬프트에서 컨텍스트로

~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

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