AI 에이전트를 위한 컨텍스트 엔지니어링 (Context Engineering): 2026년 실무자를 위한 심층 분석

모델 전쟁은 끝났다. 하네스 (Harness) 전쟁이 시작되었다.
프롬프트 엔지니어링 (Prompt Engineering)이 실패한 이유 (그리고 그것을 대체한 것)
에이전트 컨텍스트 윈도우 (Context Window)의 해부
하네스 (The Harness): 컨텍스트 엔지니어링의 런타임 (Runtime)
컨텍스트 정책 설계: 윈도우를 위한 채우기 규칙 (Fill Rules)
컨텍스트 불안 (Context Anxiety) 및 압축 전략 (Compaction Strategies)
멀티 에이전트 컨텍스트 핸드오프 (Multi-Agent Context Handoffs)
AGENTS.md 구축하기: 래칫 원칙 (The Ratchet Principle)
MCP: 대규모 컨텍스트 엔지니어링
벤치마크 (Benchmarks) 및 토큰 경제학 (Token Economics)
프로덕션 컨텍스트 엔지니어링 체크리스트
결론

1. 모델 전쟁은 끝났다. 하네스 (Harness) 전쟁이 시작되었다.

당신을 멈춰 세울 만한 숫자가 하나 있습니다. Terminal Bench 2.0에서 한 팀이 모델을 단 한 번도 바꾸지 않고 코딩 에이전트를 상위 30위에서 상위 5위로 끌어올렸습니다. 그들은 오직 하네스 (harness)만을 변경했습니다.

동일한 모델입니다. 다른 스캐폴딩 (scaffolding), 다른 컨텍스트 정책 (context policies), 더 정교한 백프레셔 (backpressure) 신호. 결과는 상위 5위였습니다.

2026년 초 Viv Trivedy가 발표하고 HumanLayer 팀이 독립적으로 확인한 이 결과는, 현재 응용 AI 엔지니어링 (applied AI engineering)의 최전선에서 일어나고 있는 모든 것을 요약합니다. 지난 2년 동안 엔지니어들은 다음 방정식의 왼쪽 부분에 집착해 왔습니다.

AI 에이전트 (AI Agent) = LLM 모델 + 하네스 (Harness)

모든 블로그 포스트, 모든 벤치마크, 모든 Twitter 스레드는 어떤 모델이 더 똑똑한지, 환각 (hallucination)을 덜 일으키는지, React를 더 잘 작성하는지에만 끊임없이 집중했습니다. 그 대화도 괜찮았습니다. 하지만 시스템의 나머지 절반을 완전히 놓치고 있었습니다.

모델을 감싸고 있는 프롬프트 (prompts), 도구 (tools), 컨텍스트 정책 (context policies), 훅 (hooks), 샌드박스 (sandboxes), 서브 에이전트 (subagents), 피드백 루프 (feedback loops), 그리고 복구 경로 (recovery paths)인 하네스 (harness) — 바로 이곳에 2026년의 실제 레버리지 (leverage)가 존재합니다. 그리고 그 하네스를 잘 설계하는 규율에는 이름이 있습니다: 바로 **AI 에이전트를 위한 컨텍스트 엔지니어링 (context engineering for AI agents)**입니다.

이것은 프롬프트 엔지니어링 (prompt engineering)의 단순한 재브랜딩이 아닙니다. 이는 근본적으로 다른 학문 분야입니다. AI 에이전트를 위한 컨텍스트 엔지니어링 (context engineering for AI agents)은 이전의 그 어떤 것과도 다른 도구 (tooling), 다른 실패 모드 (failure modes), 그리고 다른 최적화 목표 (optimization targets)를 가집니다. 이 포스트는 이것이 무엇을 의미하는지, 왜 중요한지, 그리고 실제로 어떻게 수행하는지에 대한 실무자의 심층 분석입니다.

Context Engineering for AI Agents — Architecture Overview

2. 프롬프트 엔지니어링이 실패한 이유 (그리고 그것을 대체한 것)

2025년 6월, Andrej Karpathy는 진지한 엔지니어들이 자신의 업무를 어떻게 생각해야 하는지에 대해 조용히 프레임을 재설정하는 스레드를 게시했습니다:

_"'프롬프트 엔지니어링'보다 '컨텍스트 엔지니어링'에 +1표를 던집니다. 사람들은 프롬프트를 일상적인 사용에서 LLM (대규모 언어 모델)에 주는 짧은 작업 설명으로 연관 짓습니다. 하지만 모든 산업용 LLM 애플리케이션에서, 컨텍스트 엔지니어링은 다음 단계를 위해 컨텍스트 윈도우 (context window)를 딱 적절한 정보로 채우는 섬세한 예술이자 과학입니다."

Karpathy는 더 나아가 설명했습니다: 컨텍스트 엔지니어링은 작업 설명, 퓨샷 예시 (few-shot examples), RAG (검색 증강 생성), 관련 멀티모달 (multimodal) 데이터, 도구 스키마 (tool schemas), 상태 (state), 이력 (history), 압축 전략 (compacting strategies)을 포함하며, 모델이 잘 수행하기 위해 무엇을 보아야 하는지 알 수 있을 정도로 LLM 심리학을 잘 이해하는 "예술"을 포함합니다.

Shopify의 CEO Tobi Lutke도 같은 주에 이에 동의했습니다:

_"프롬프트 엔지니어링보다 '컨텍스트 엔지니어링'이라는 용어가 정말 마음에 듭니다. 이는 핵심 기술을 더 잘 설명합니다. 즉, LLM이 작업을 타당하게 해결할 수 있도록 모든 컨텍스트를 제공하는 예술입니다."

"프롬프트 엔지니어링"의 문제는 기술력 자체가 아니라, 의미론적 연상 (semantic association)에 있었습니다. 대부분의 사람들은 "프롬프트 엔지니어링"이라는 말을 들으면 "교묘한 문구 작성"을 떠올렸습니다. 그렇게 추론된 정의가 굳어져 버린 것입니다. 챗봇에 무언가를 타이핑하는 것을 가리키는, 웃기도록 가식적인 용어가 되어버렸습니다.

**컨텍스트 엔지니어링 (Context engineering)**은 그런 문제를 겪지 않습니다. 추론된 정의, 즉 모델의 컨텍스트 (context)로 흘러 들어가는 정보를 정교하게 구성하는 것이 거의 의도된 정의와 일치하기 때문입니다.

컨텍스트 엔지니어링이 실제로 다루는 범위

프로덕션 에이전트 시스템 (production agent system)에서 컨텍스트 엔지니어링은 다음 사항들을 제어합니다:

시스템 프롬프트 (system prompt)에 무엇을 넣을 것인가와 모델의 이해를 위해 이를 어떻게 구조화할 것인가
어떤 도구 (tools)를 노출할 것인가와 그 스키마 (schemas)를 어떻게 작성할 것인가 (설명이 부실한 도구는 모델에게 보이지 않습니다)
메모리 (memory)를 어떻게 관리할 것인가 — 장기 저장소 (long-term stores)에서 무엇을, 얼마나, 언제 가져올 것인가
대화 기록 (conversation history)을 어떻게 압축할 것인가 — 컨텍스트 제한 (context limits)에 걸리지 않으면서 유효한 작업 범위 (task horizon)를 확장하기 위해
상태 (state)를 어떻게 전달할 것인가 — 에이전트 간 또는 컨텍스트 리셋 (context resets) 시에
모델이 무엇을 보지 말아야 하는가 — 네거티브 컨텍스트 엔지니어링 (negative context engineering), 토큰 (tokens)을 낭비하기 전에 무관한 정보를 필터링하는 것

이 중 그 어느 것도 "챗봇에 무언가를 타이핑하는 것"이 아닙니다. 이것은 시스템 엔지니어링 (systems engineering)입니다. 트랜스포머 (transformers)가 긴 시퀀스 (sequences)를 어떻게 처리하는지, 어텐션 패턴 (attention patterns)이 거리에 따라 어떻게 저하되는지, 그리고 컨텍스트가 채워짐에 따라 특정 모델들이 어떻게 행동하는지를 이해해야 합니다. 이것은 하나의 실질적인 학문 분야이며, 2026년에는 기능적인 에이전트와 프로덕션급 에이전트를 구분 짓는 핵심 역량이 될 것입니다.

3. 에이전트 컨텍스트 윈도우 (Agent Context Window)의 구조

컨텍스트 윈도우 (context window)를 엔지니어링하기 전에, 그것이 무엇을 포함하고 있는지에 대한 정확한 멘탈 모델 (mental model)이 필요합니다. 대부분의 개발자는 컨텍스트를 "대화 기록"이라는 하나의 거대한 단일체로 생각합니다. 하지만 프로덕션 에이전트 시스템에서 컨텍스트 윈도우는 상충하는 우선순위를 가진 **계층화된 리소스 (layered resource)**로 이해하는 것이 더 적절합니다.

다음은 코딩 에이전트 컨텍스트 윈도우의 전형적인 분해 구조이며, 가장 정적인 것부터 가장 동적인 순서로 나열되어 있습니다:

레이어 1: 시스템 프롬프트 (윈도우의 3–8%)

시스템 프롬프트 (System Prompt)는 에이전트의 헌법과 같습니다. 이는 에이전트의 정체성, 능력, 제약 사항, 출력 형식에 대한 기대치 및 관례를 정의합니다. 대화 턴 (Conversation turns)과 달리, 이는 압축하여 없앨 수 없습니다. 이곳의 모든 토큰은 추론 호출 (Inference call)당 발생하는 영구적인 비용입니다.

설계 규칙: 시스템 프롬프트를 핫패스 코드 (Hot-path code)처럼 취급하세요. 하중을 견디는 데 필수적이지 않은 모든 것은 제거하십시오. 3,000토큰으로 줄일 수 있는 10,000토큰 규모의 시스템 프롬프트는 매 호출마다 7,000토큰을 낭비하고 있는 것입니다.

레이어 2: 도구 스키마 (Tool Schemas) (윈도우의 5–15%)

노출되는 모든 도구는 컨텍스트 (Context)를 점유합니다 — 함수 이름, 설명, 파라미터 (Parameters), 그리고 예시들이 포함됩니다. 잘못 설계된 도구 스키마는 도구당 800–1,500토큰의 비용을 발생시킬 수 있습니다. 도구가 20개라면, 모델이 작업 컨텍스트의 단 한 줄을 처리하기도 전에 도구 오버헤드 (Tool overhead)로만 최대 30,000토큰을 사용하게 됩니다.

설계 규칙: 현재 작업 단계와 관련된 도구만 노출하세요. 계획 에이전트 (Planning agent)에게 파일 쓰기 도구는 필요하지 않습니다. 코드 실행 에이전트 (Code-execution agent)에게 웹 검색 도구는 필요하지 않습니다. 현재의 하위 작업 (Sub-task)을 기반으로 활성 도구 세트를 선택하는 동적 도구 라우팅 (Dynamic tool routing)은 컨텍스트 엔지니어링에서 가장 레버리지가 높은 최적화 방법 중 하나입니다.

레이어 3: 퓨샷 예시 (Few-Shot Examples) (윈도우의 0–20%)

퓨샷 예시 (Few-shot examples)는 컨텍스트 윈도우 내에서 토큰당 가장 강력한 투자입니다. 잘 선택된 3-샷 (3-shot) 예시는 5,000토큰 규모의 설명적인 시스템 프롬프트보다 출력 품질을 더 효과적으로 향상시킬 수 있습니다. 하지만 과잉 공급하기 가장 쉬운 요소이기도 합니다.

설계 규칙: 동적 퓨샷 검색 (Dynamic few-shot retrieval)을 사용하세요. 예시들을 벡터 데이터베이스 (Vector database)에 저장하십시오. 현재 작업과 의미론적으로 가장 유사한 2~3개를 검색하여 사용하세요. 10개의 정적 예시를 모든 프롬프트에 박아 넣지 마십시오.

레이어 4: RAG 검색 컨텍스트 (RAG-Retrieved Context) (윈도우의 10–30%)

외부 지식이 필요한 에이전트의 경우, 검색된 청크 (Retrieved chunks)는 종종 컨텍스트 윈도우에서 가장 큰 가변적 구성 요소가 됩니다. 상위 k개를 검색하여 모두 쏟아붓는 단순한 RAG (Naive RAG) 방식은 컨텍스트 엔지니어링의 안티 패턴 (Anti-pattern)입니다.

설계 규칙: 주입하기 전에 재정렬(re-rank) 및 압축(compress)할 것. 20개의 청크(chunk)를 검색한 후, 현재 쿼리(query) 및 현재 에이전트 상태(agent state)와의 관련성에 따라 재정렬하고, 하위 절반을 요약한 뒤 포함시키십시오.

레이어 5: 작업 상태 및 이력 (Task State and History) (윈도우의 20–40%)

대화 이력 — 에이전트가 지금까지 수행한 작업, 호출한 도구(tool), 그리고 도구가 반환한 결과 — 은 장기적 작업(long-horizon tasks) 수행 시 컨텍스트 윈도우(context window)를 급격히 소모하는 주범입니다. 각 단계에서 500 토큰의 이력을 소비하는 100단계 작업의 경우, 작업이 끝나기 전에 50,000 토큰의 상태(state)가 누적됩니다.

설계 규칙: 초기에 압축하고 지속적으로 압축할 것. 컨텍스트 윈도우가 가득 찰 때까지 압축을 기다리지 마십시오. 임계값(high-water mark, 예: 윈도우의 60%)을 설정하고 선제적으로 압축(compaction)을 트리거하십시오.

레이어 6: 현재 단계 입력 (Current Step Input) (윈도우의 5–15%)

실제 현재 작업, 쿼리(query) 또는 관찰(observation)입니다. 이것이 모델이 실제로 추론하도록 요청받는 대상입니다. 엔지니어들은 흔히 레이어 1~5에 너무 많은 컨텍스트를 밀어 넣어, 모델이 레이어 6에 도달했을 때 주의력 용량(attention capacity)이 저하된 상태가 되게 만듭니다.

설계 규칙: 항상 작업을 위한 여유 공간(headroom)을 확보할 것. 작업이 도달하기 전 이미 115K가 차 있는 128K 컨텍스트 윈도우는, 15K의 여유가 있는 32K 윈도우보다 기능적으로 더 나쁩니다.

4. 하네스(The Harness): 컨텍스트 엔지니어링의 런타임(Runtime)

컨텍스트 엔지니어링은 텍스트 파일 내에서 일어나는 것이 아니라, 코드 내에서 일어납니다. **하네스(harness)**는 매 호출마다 무엇을 주입할지, 무엇을 압축할지, 어떤 도구를 활성화할지, 언제 권한을 넘길지(hand off), 그리고 언제 멈출지를 결정하는 런타임(runtime)입니다.

Viv Trivedy의 공식:

"에이전트 = 모델 + 하네스. 당신이 모델이 아니라면, 당신은 하네스입니다."

하네스에는 구체적으로 다음이 포함됩니다:

시스템 프롬프트 (System prompts), CLAUDE.md, AGENTS.md, 스킬 파일 (skill files)
도구 (Tools), MCP 서버 (MCP servers), 그리고 해당 도구들의 설명
번들링된 인프라스트럭처 (filesystem, sandbox, browser)
오케스트레이션 로직 (Orchestration logic) (하위 에이전트 생성 (subagent spawning), 핸드오프 (handoffs), 모델 라우팅 (model routing))
훅 (Hooks) 및 미들웨어 (middleware) (압축 트리거 (compaction triggers), 지속 (continuation), 린트 체크 (lint checks))
관측성 (Observability) (로그 (logs), 트레이스 (traces), 비용 및 지연 시간 측정 (cost and latency metering))

정밀한 엔지니어링을 위해서는 **스캐폴딩 (Scaffolding)**과 하네스 (Harness) 사이의 구분이 중요합니다:

**스캐폴딩 (Scaffolding)**은 행동을 정의하는 계층입니다: 모델이 무엇을 보는지, 어떤 도구에 대해 알고 있는지, 모델의 응답이 어떻게 파싱되는지를 결정합니다. 이는 모델의 세계 모델 (world-model)을 형성합니다.
**하네스 (Harness)**는 실행 계층입니다: 루프를 구동하고, 도구 호출 (tool calls)을 처리하며, 언제 멈출지를 결정합니다.

Claude Code, Cursor, Codex, Aider는 모두 하네스입니다. 이들은 모두 동일한 기반 모델을 실행할 수 있습니다. 사용자가 이들 사이에서 경험하는 행동적 차이는 모델의 차이가 아니라, 거의 전적으로 하네스 설계의 차이에서 기인합니다.

다음은 최소한의 구조를 갖춘 완전한 Python 하네스 스켈레톤 (skeleton)입니다:

import anthropic
from typing import Generator

...

ContextPolicy 객체는 하네스의 핵심이며, 컨텍스트 엔지니어링의 주요 접점 (surface area)입니다. 다음 단계에서 이를 구축해 보겠습니다.

5. 컨텍스트 정책 설계: 윈도우를 위한 채우기 규칙 (Fill Rules)

**컨텍스트 정책 (Context policy)**은 각 모델 호출 시 컨텍스트 윈도우 (context window)에 무엇을 넣을지를 규정하는 규칙 세트입니다. 오늘날 대부분의 에이전트 프레임워크는 명시적인 컨텍스트 정책이 없거나 (시스템이 충돌할 때까지 모든 것을 집어넣음), 아주 사소한 정책만을 가지고 있습니다 (한도를 초과하면 왼쪽에서부터 잘라냄).

두 방식 모두 프로덕션 시스템에는 충분하지 않습니다.

다음은 더 완전한 ContextPolicy 구현 예시입니다:

from dataclasses import dataclass, field
from typing import Callable
import tiktoken
...

여기서 핵심적인 통찰은 컨텍스트 정책 (context policy) 설계가 모델의 역할이 아니라는 점입니다. 그것은 하네스 엔지니어 (harness engineer)의 역할입니다. 모델은 스스로 자신의 컨텍스트를 압축하기로 결정할 수 없으며, 더 적은 수의 도구 (tools)를 노출하도록 선택할 수도 없습니다. 이 모든 과정은 모델이 호출되기 전, 하네스 계층 (harness layer)에서 발생합니다.

6. 컨텍스트 불안 (Context Anxiety) 및 압축 전략 (Compaction Strategies)

2026년 초, Anthropic은 모든 에이전트 개발자가 반드시 어휘 목록에 포함해야 할 용어를 발표했습니다: 바로 컨텍스트 불안 (context anxiety) 입니다.

Anthropic의 엔지니어링 블로그에 따르면:

"모델은 컨텍스트 윈도우 (context window)가 채워짐에 따라 긴 작업에서 일관성을 잃는 경향이 있습니다. 일부 모델은 또한 '컨텍스트 불안 (context anxiety)'을 보이기도 하는데, 이는 모델이 자신의 컨텍스트 한계에 도달했다고 판단하는 지점에 가까워질수록 작업을 조기에 마무리하려는 현상을 말합니다."

컨텍스트 불안은 다음과 같은 형태로 나타납니다:

작업 중간에 발생하는 성급한 "작업을 완료했습니다"라는 선언
긴 컨텍스트의 후반부 작업에서 발생하는 품질 저하
윈도우가 채워짐에 따라 증가하는 환각 (hallucination) 비율
더 짧고 덜 철저한 도구 호출 (tool calls) 및 추론 흔적 (reasoning traces)