컨텍스트 엔지니어링 (Context Engineering): LLM이 실제로 무엇을 보는지 결정하는 규율

프롬프트 엔지니어링 (Prompt engineering)은 "이 지시사항을 어떻게 표현할 것인가?"를 묻습니다. 반면 컨텍스트 엔지니어링 (Context engineering)은 "모델이 정확한 답변을 생성하기 위해 어떤 정보가, 어떤 형태로, 어떤 순서로, 그리고 얼마나 많이 필요한가?"를 묻습니다.

오랫동안 암묵적인 사고 모델은 "LLM에 더 많은 컨텍스트를 제공할수록 성능이 좋아진다"는 것이었습니다. 이는 틀렸습니다. 관련성이 낮은 내용으로 가득 찬 20,000-토큰 (token) 윈도우는 정밀하게 큐레이션된 정보가 담긴 4,000-토큰 윈도우보다 더 나쁜 답변을 생성합니다. 더 큰 윈도우는 컨텍스트 품질 문제를 제거하는 것이 아니라, 오히려 증폭시킵니다.

컨텍스트 윈도우 (Context Window)는 예산이다

컨텍스트 윈도우를 채워 넣어야 할 컨테이너가 아니라, 서로 경쟁하는 항목들이 있는 예산으로 취급하십시오. 전체 윈도우에서 고정 할당량(시스템 프롬프트 (system prompt), 출력 예약분 (output reserve), 안전 마진 (safety margin))을 차감하면, 남은 부분은 검색된 청크 (retrieved chunks), 대화 기록 (conversation history), 그리고 메모리 (memory)에 나누어 할당될 동적 예산이 됩니다.

첫 번째 질문은 항상 다음과 같아야 합니다: "더 많이 포함하기보다, 더 적게 선택하는 능력을 키울 수 있는가?"

네 가지 메모리 유형, 네 가지 목적

에피소드형 (Episodic) — 대화 기록 (conversation history). 연속성을 위한 최우선 순위입니다. 무제한으로 늘어나므로 압축이 필요합니다.
시맨틱형 (Semantic) — 사용자에 대한 지속적인 사실 (역할, 팀, 선호도). 압축되어 있으며, 검색된 콘텐츠 이전에 시스템 프롬프트 (system prompt)에 주입됩니다.
절차형 (Procedural) — 재사용 가능한 워크플로 (workflows) 및 표준 운영 절차 (SOPs). 쿼리 유형이 일치할 때 선택적으로 검색됩니다.
작업형 (Working) — 단일 요청 내의 중간 결과 (에이전트 루프 (agentic loop) 출력). 일시적이며 요청 범위 내에서만 유효합니다.

각 유형은 내구성, 업데이트 빈도, 토큰 비용 (token cost)이 다릅니다. 이들을 구분 없이 하나의 저장소로 혼합하는 것이 메모리 아키텍처에서 가장 흔히 발생하는 실수입니다.

구조화된 주입 패턴 (Structured Injection Patterns)

**XML 태그 (XML tags)**를 사용한 섹션 경계 구분 (<documents>, <user_context>, <instructions>) — 모델에게 정보 유형이 시작되고 끝나는 지점에 대한 명확한 앵커(anchor)를 제공합니다.
인덱싱된 문서 (Indexed documents) — 인용(citation)을 추적할 수 있도록 청크(chunk)에 인덱스 라벨을 붙입니다.
순서의 중요성 (Ordering matters) — 가장 관련성이 높은 콘텐츠를 먼저 배치(초두 효과, primacy effect)하고, 사용자 쿼리를 마지막에 배치(최신 효과, recency effect)합니다.
그라운딩 지침 (Grounding instruction)은 선택 사항이 아님 — 제공된 컨텍스트(context)만 사용하고, 정보가 불충분할 경우 이를 알리도록 명시적인 지침을 내립니다.

중간 소실 (Lost-in-the-Middle)

모델은 컨텍스트 창(context window)의 시작과 끝 근처에 있는 콘텐츠에 더 강력하게 주의(attention)를 기울입니다. 중간에 묻혀 있는 정보는 주의를 덜 받게 됩니다. 완화 방법:

관련성 순서에 따른 주입 (Relevance-ordered injection, 가장 높은 점수부터)
샌드위치 패턴 (Sandwich pattern, 중요한 콘텐츠를 시작과 끝 모두에 배치)
능동적 관련성 필터링 (Active relevance filtering, 적합하더라도 점수가 낮은 청크는 제외)
더 작고 조밀한 창 (Smaller, tighter windows, 평범한 많은 청크보다 고품질의 적은 청크 사용)

대화 압축 (Conversation Compression)

100회 차례의 대화는 검색된 전체 컨텍스트 예산을 모두 소모합니다. 단순한 절단(truncation) 방식은 초기 단계의 중요한 제약 조건들을 유실합니다. 해결책:

고정된 턴을 포함한 슬라이딩 윈도우 (Sliding window with pinned turns) — 중요한 턴(사용자 제약 조건, 결정 사항)은 절대 절단하지 않습니다.
점진적 요약 (Progressive summarization) — Haiku(저렴하고 기계적인 작업)를 사용하여 오래된 세그먼트를 3~5문장의 요약본으로 압축합니다.

테스트 가능한 컨텍스트 조립 (Context Assembly Is Testable)

조립 계층(assembly layer)에 대해 단위 테스트(Unit test)를 수행하세요: 예산 준수 여부, 순서 보존 여부, 절단 시 중요한 턴의 생존 여부, 청크 중간 절단 발생 여부 등을 확인합니다. 모든 조립 실패는 예측 가능한 RAGAS 지표 시그니처를 생성합니다. 즉, 컨텍스트 정밀도(context precision)가 떨어지면 노이즈가 섞인 포함을 의미하며, 충실도(faithfulness)가 떨어지면 모순이 발생했음을 의미합니다.

전체 기사 읽기

이 내용은 컨텍스트 엔지니어링에 대한 저의 심층 분석을 요약한 것입니다. 전체 기사에서는 실제 운영 환경에서의 구현 사례와 함께 이 전문적인 규율(discipline) 전체를 다룹니다.

👉 컨텍스트 엔지니어링 (Context Engineering): LLM이 실제로 무엇을 보는지 결정하는 규율 — 전체 기사

전체 기사에는 다음 내용이 포함되어 있습니다:

Python 데이터 클래스 (dataclasses)를 활용한 컨텍스트 창 예산 산정 (Context window budget accounting)
구현 패턴을 포함한 네 가지 메모리 유형 (일화적 (episodic), 의미적 (semantic), 절차적 (procedural), 작업 (working) 메모리)
에이전트 기반 검색 루프 (agentic retrieval loops)로부터의 작업 메모리 브리지 (Working memory bridge)
문서 인덱싱을 통한 XML 구조화된 주입 (XML-structured injection)
초두/최신성 (Primacy/recency) 순서 전략
핵심 턴 고정 (critical turn pinning)을 활용한 점진적 요약 (Progressive summarization)
중간 소실 (Lost-in-the-middle) 완화 (코드와 함께 4가지 전략 제시)
모순 탐지 및 해결 (Contradiction detection and resolution)
노이즈 분류 체계 (Noise taxonomy) (오래된 (stale), 지엽적인 (tangential), 중복된 (redundant), 과도하게 검색된 (over-retrieved))
컨텍스트 조립 (context assembly) 유닛 테스트
RAGAS 평가 파이프라인과의 AssemblyMetadata 통합
RAGAS 지표 → 조립 실패 매핑 테이블
프로덕션 체크리스트 (19개 항목)