컨텍스트 엔지니어링 — 프롬프트 문구가 아니라 정보 환경을 설계하는 일
시스템 프롬프트·메모리·RAG·도구 스펙을 런타임에 동적으로 조립하는 컨텍스트 엔지니어링의 구성요소와 토큰 예산 관리 기법을 정리한다.
2026-08-14 · 최초 발행 2026-05-08
프롬프트 문구에서 정보 환경으로
에이전트 AI 시스템의 성능을 결정하는 핵심 요인이 프롬프트 문구 작성에서 메모리·도구·지식 구조 설계로 이동하면서, 컨텍스트 엔지니어링이 2026년 AI 개발의 가장 중요한 직무 역량으로 부상했다. Anthropic, Neo4j, Weaviate 등 주요 AI 기업들이 공식 블로그에서 컨텍스트 엔지니어링을 프롬프트 엔지니어링의 후계자로 규정하고 있으며, Gartner는 2028년까지 기업용 AI 도구의 80%가 컨텍스트 엔지니어링을 핵심 설계 원칙으로 채택할 것으로 전망하고 있다.
프롬프트 엔지니어링이 "어떻게 질문하느냐"에 집중했다면, 컨텍스트 엔지니어링은 "어떤 정보가 요청을 둘러싸는가"에 집중한다. 단일 요청-응답 패턴에서는 프롬프트 품질이 결과를 좌우했지만, 다단계 계획·도구 호출·상태 유지가 필요한 에이전틱 시스템에서는 각 단계마다 모델이 수신하는 컨텍스트의 구성과 품질이 전체 작업 성공을 결정한다. 에이전트가 10단계의 작업을 수행할 때, 각 단계의 컨텍스트가 관련성 높은 정보로 구성돼 있지 않으면 중간 단계에서 방향을 잃거나 잘못된 결정을 내린다.
컨텍스트 엔지니어링은 2025년 중반부터 산업 현장에서 구체적 방법론으로 정립되기 시작했다. 독립적인 "프롬프트 엔지니어" 직무가 더 넓은 AI 시스템 설계 역할로 통합되고 있으며, 컨텍스트 윈도우를 하나의 희소 자원으로 취급하는 설계 방식이 표준화되고 있다.
컨텍스트를 이루는 구성요소들
시스템 프롬프트(System Prompt)는 에이전트의 페르소나, 목표, 제약, 사용 가능한 도구 목록을 정의하는 불변 기반층이다. 잘 설계된 시스템 프롬프트는 에이전트가 작업 전반에 걸쳐 일관된 행동 원칙을 유지하도록 하며, 토큰 예산의 약 10~15%를 차지하는 것이 적절하다 — 너무 장황하면 정작 중요한 작업 컨텍스트를 위한 공간이 줄어든다.
인컨텍스트 학습(In-Context Learning)은 few-shot 예제를 통해 모델이 원하는 출력 형식과 추론 패턴을 학습하게 하는 구성요소다. 특히 특수 도메인이나 특정 출력 형식이 필요한 경우, 잘 선택된 2~5개의 예제가 모델 파인튜닝 없이도 성능을 크게 향상시킨다.
도구 스펙(Tool Specifications)은 에이전트가 호출 가능한 도구의 이름, 설명, 파라미터 스키마를 컨텍스트에 포함시키는 요소다. MCP 표준을 따르는 도구 스펙은 LLM이 적절한 도구를 선택하고 올바른 인자를 구성하는 데 결정적 역할을 한다.
메모리 레이어(Memory Layer)는 에이전트가 이전 상호작용, 학습된 사실, 사용자 선호를 장기 보존하고 필요 시 검색해 컨텍스트로 주입하는 시스템이다. 특정 사건을 기억하는 에피소딕 메모리, 일반 지식을 담는 시맨틱 메모리, 작업 수행 방법을 담는 절차적 메모리 세 가지로 구분된다.
RAG 파이프라인은 외부 지식 베이스에서 관련 문서를 실시간 검색해 컨텍스트에 포함시키는 구성요소다. 순수 RAG와 컨텍스트 엔지니어링의 차이는, RAG가 후보 정보를 검색하는 데 집중하는 반면 컨텍스트 엔지니어링은 RAG 결과물을 포함한 모든 정보 소스에서 실제로 컨텍스트 윈도우에 진입할 내용을 선택하고 조립하는 상위 계층을 담당한다는 점이다.
런타임이 매 순간 컨텍스트를 다시 짠다
에이전틱 시스템의 컨텍스트는 정적으로 구성되지 않는다. 작업의 각 단계마다 현재 목표, 이전 행동 결과, 검색된 메모리, 도구 출력 등 서로 다른 정보 소스를 조합해 최적의 컨텍스트를 동적으로 조립해야 한다.
동적 컨텍스트 관리자(Dynamic Context Manager)는 목표, 메모리 현저성(salience), 작업 단계를 기반으로 실시간으로 컨텍스트를 큐레이션하고 진화시키는 인지 서브루틴이다. 이 관리자는 세 가지 핵심 판단을 내린다. 관련성 필터링은 현재 단계와 관련성이 낮은 이전 대화 내용, 오래된 도구 결과, 중복 정보를 컨텍스트에서 제거하는 것으로, 의미적 유사도 임계값과 시간 감쇠 함수를 결합해 관련성 점수를 산정한다. 컨텍스트 재구성 타이밍은 새로운 서브태스크 진입, 도구 결과 수신, 사용자 피드백 수령 등 특정 이벤트가 발생할 때 컨텍스트를 재조립하는 것이다 — 매 토큰 생성마다 재구성하면 불필요한 비용이 발생하므로, 의미 있는 상태 변화 지점을 트리거로 설정하는 것이 효율적이다. 예산 할당은 컨텍스트 윈도우의 토큰 예산을 시스템 프롬프트, 메모리, RAG 결과, 대화 기록, 도구 스펙 등 카테고리별로 동적으로 배분하는 것으로, 검색 집약적 작업에는 RAG 할당량을 늘리고 상태 추적이 중요한 작업에는 대화 기록 할당량을 확대한다.
제한된 토큰 안에 유용한 정보를 담는 법
컨텍스트 엔지니어링의 가장 실용적인 과제 중 하나는 제한된 토큰 예산 내에서 최대한 유용한 정보를 담는 것이다. 현대 LLM의 컨텍스트 윈도우는 128K~1M 토큰에 달하지만, 에이전트가 다단계 작업을 수행하면서 누적되는 정보는 이를 쉽게 초과한다.
슬라이딩 윈도우 요약(Sliding Window Summarization)은 가장 높은 효과 대비 비용 비율을 보이는 압축 기법이다. 오래된 대화 턴을 압축 요약으로 대체하고 최근 N개의 전체 턴만 유지함으로써 히스토리 전체를 유지하면서도 토큰 사용을 통제한다. 청크 수준 압축은 RAG로 검색된 문서를 전체 포함하는 대신, 현재 질의와 가장 관련 있는 문장이나 단락만 추출해 컨텍스트에 포함시키는 기법이다 — 재순위화(re-ranking) 모델을 통해 검색된 청크의 관련성을 재평가하고 상위 K개만 선택한다. 메모리 압축에서는 대화에서 추출된 엔티티, 관계, 팩트를 구조화된 형태로 저장하고, 원본 대화 내용 대신 압축된 표현을 컨텍스트에 주입한다. Zep과 같은 컨텍스트 엔지니어링 플랫폼은 사용자 데이터 소스를 통합해 통합 컨텍스트 그래프를 구축하고, 엔티티·관계·팩트를 자동 추출해 에이전트에 조립된 컨텍스트를 제공한다.
RAG는 컨텍스트 엔지니어링의 부품일 뿐이다
RAG(Retrieval Augmented Generation)와 컨텍스트 엔지니어링은 동일한 개념이 아니다. RAG는 컨텍스트 엔지니어링의 하위 구성요소이며, 컨텍스트 엔지니어링은 RAG를 포함한 모든 정보 소스를 조율하는 상위 계층이다.
순수 RAG 시스템은 "후보 정보를 어떻게 검색하느냐"에 집중하지만, 컨텍스트 엔지니어링은 "검색된 정보 중 어느 것을 실제로 컨텍스트 윈도우에 포함시킬 것인가"를 결정한다. RAG만으로는 해결할 수 없는 문제들이 있다 — 검색된 청크가 서로 모순되거나, 현재 작업 단계와 관련성이 낮거나, 메모리에 저장된 정보와 충돌하는 경우다. 컨텍스트 엔지니어링 관점의 완전한 RAG 파이프라인은 검색(Retrieval), 재순위화(Re-ranking), 압축(Compression), 예산 통제(Budget Control) 네 단계로 구성된다. 메모리 소비가 예산 한도에 가까워지면 검색 문서에 대한 압축이 자동으로 강화돼 컨텍스트 일관성이 유지된다.
재사용·캐싱·감사로 거버넌스를 세우기
컨텍스트 윈도우 최적화를 위한 거버넌스 전략은 세 원칙을 중심으로 구성된다. 재사용 가능 컨텍스트 블록은 자주 사용되는 시스템 프롬프트 섹션, 도메인 지식, 절차 가이드를 모듈화해 다수의 에이전트와 작업 유형에서 재사용하는 방식으로, 개발 효율을 높이고 컨텍스트 품질의 일관성을 보장한다. 캐싱 전략에서는 변경이 잦지 않은 컨텍스트 세그먼트(시스템 프롬프트, 정적 지식 기반)를 프롬프트 캐싱으로 처리해 토큰 비용을 절감한다 — Anthropic의 프롬프트 캐싱을 활용하면 캐시된 토큰 비용이 일반 입력 토큰 대비 최대 90% 절감된다. 컨텍스트 감사(Context Auditing)는 에이전트가 각 단계에서 실제로 컨텍스트를 어떻게 구성했는지 로깅하고 분석하는 관찰 가능성(observability) 실천으로, 어떤 정보가 에이전트 결정에 실제로 영향을 미쳤는지 추적하고 잘못된 결정의 근본 원인을 컨텍스트 구성 수준에서 식별할 수 있게 한다.
MCP 도구를 언제 컨텍스트에 넣을 것인가
MCP(Model Context Protocol)는 컨텍스트 엔지니어링에서 도구 스펙 계층을 표준화하는 핵심 인프라다. MCP를 통해 에이전트는 수천 개의 잠재적 도구 중 현재 작업에 필요한 도구만 선택적으로 컨텍스트에 포함시킬 수 있다. 도구 선택의 컨텍스트 엔지니어링 관점에서는, 모든 도구 명세를 컨텍스트에 포함시키는 것이 아니라 현재 작업 단계와 관련 가능성이 높은 도구만 동적으로 선택해 포함시키는 것이 최적이다. 100개의 MCP 서버가 연결된 환경에서 모든 도구 스펙을 컨텍스트에 담으면 수만 토큰이 소비되지만, 관련 도구만 선택하면 수백 토큰으로 줄일 수 있다.
컨텍스트 재구성 타이밍의 최적 트리거는 서브태스크 경계, 도구 호출 완료, 사용자 입력 수신, 장기 작업에서의 주기적 체크포인트다. 이 타이밍에 컨텍스트를 재평가하고 필요시 재조립함으로써 에이전트가 항상 현재 상황에 맞는 정보를 기반으로 추론하도록 보장한다.
컨텍스트 엔지니어링은 에이전틱 AI 시대가 요구하는 새로운 핵심 역량으로, 단순한 프롬프트 작성을 넘어 메모리 레이어, RAG 파이프라인, 도구 스펙, 토큰 예산 관리를 통합 설계하는 시스템 엔지니어링 역량이다. 2026년은 에이전틱 AI가 인상적인 데모에서 프로덕션 인프라로 전환되는 해로, 컨텍스트 엔지니어링의 숙련도가 AI 시스템의 실용적 가치를 결정짓는 핵심 변수가 되고 있다.
Sources
- https://neo4j.com/blog/agentic-ai/context-engineering-vs-prompt-engineering/
- https://blog.american-technology.net/context-engineering/
- https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- https://weaviate.io/blog/context-engineering
- https://dev.to/akshaygupta1996/context-engineering-giving-ai-agents-memory-without-breaking-the-token-budget-1ho5
- https://mentorcruise.com/blog/dynamic-context-engineering-for-ai-agents/
- https://towardsdatascience.com/rag-isnt-enough-i-built-the-missing-context-layer-that-makes-llm-systems-work/
- https://dev.to/serenitiesai/context-engineering-why-its-replacing-prompt-engineering-in-2026-1b4g
- https://www.epsilla.com/blogs/harness-engineering-evolution-prompt-context-autonomous-agents
- https://www.getzep.com/