컨텍스트 엔지니어링: 토큰 예산과 캐싱으로 런타임 정보를 설계하는 법

2025년 6월, Shopify CEO 토비 뤼트케와 AI 연구자 안드레이 카르파티가 거의 동시에 "컨텍스트 엔지니어링(Context Engineering)"이라는 용어를 공개적으로 사용하며 AI 개발 커뮤니티의 주목을 받았다. 같은 해 7월 Gartner는 "컨텍스트 엔지니어링이 대세이고, 프롬프트 엔지니어링은 구시대"라는 리포트를 발표했다. 단순히 AI에게 "좋은 질문"을 던지는 것에서, AI가 최선의 응답을 생성할 수 있도록 전체 정보 환경을 설계하는 방향으로 패러다임이 이동하고 있다.

프롬프트 엔지니어링만으로 안 되는 이유

LangChain의 2025년 에이전트 엔지니어링 현황 보고서에 따르면, 57%의 조직이 이미 AI 에이전트를 프로덕션에 배포했지만, 32%는 품질 문제를 가장 큰 장벽으로 꼽았다. 흥미롭게도 이 실패의 주요 원인은 LLM 자체의 능력 부족이 아니라 빈약한 컨텍스트 관리였다. 2026년 Context Management 현황 보고서에서는 IT·데이터 리더의 82%가 "프롬프트 엔지니어링 단독으로는 AI를 대규모로 운영하기에 불충분하다"고 답했다.

프롬프트 엔지니어링의 한계는 구조적이다. 단일 요청-응답 사이클에서는 잘 작성된 프롬프트로 충분할 수 있다. 하지만 에이전트가 수십 단계의 작업을 자율적으로 수행하고, 도구를 호출하며, 이전 대화 내용을 기억하고, 외부 데이터를 참조해야 하는 복잡한 시나리오에서는 프롬프트 한 줄의 최적화가 전체 시스템 품질에 미치는 영향이 미미해진다. 에이전트가 "무엇을 하라"는 지시보다 "어떤 정보를 가지고 있는가"가 출력 품질을 좌우한다.

컨텍스트를 이루는 조각들

컨텍스트 엔지니어링은 AI 에이전트가 고품질 응답을 생성하도록 필요한 모든 정보와 실행 환경을 체계적으로 설계하는 실천이다. 여기서 "컨텍스트"는 단순히 프롬프트 텍스트가 아니라 에이전트가 추론 시점에 접근할 수 있는 모든 정보의 총합을 의미한다.

시스템 프롬프트(System Prompt)는 에이전트의 역할, 행동 지침, 제약 조건을 정의하는 기반 레이어다. 컨텍스트 엔지니어링 관점에서 시스템 프롬프트는 고정된 텍스트가 아니라 에이전트의 상태와 작업 유형에 따라 동적으로 구성되는 구조체다. 코드 리뷰 작업 시에는 코딩 컨벤션과 보안 체크리스트가, 고객 응대 작업 시에는 제품 정책과 에스컬레이션 규칙이 시스템 프롬프트에 포함되는 식이다.

인컨텍스트 학습(In-Context Learning, ICL)은 추가 파인튜닝 없이 컨텍스트 내 예시(few-shot examples)만으로 에이전트의 행동 패턴을 조정하는 기법이다. 고품질 예시 선택, 예시 순서 최적화, 태스크별 예시 풀 관리가 핵심 설계 과제이며, 예시의 품질과 다양성이 에이전트 출력의 일관성을 직접적으로 결정한다.

툴 스펙(Tool Specifications)은 에이전트가 호출할 수 있는 외부 도구의 명세다. 도구 이름, 설명, 입출력 스키마가 명확하지 않으면 에이전트는 잘못된 도구를 선택하거나 올바른 도구를 잘못된 방식으로 호출한다. 툴 스펙 설계는 사용자 문서를 작성하는 수준의 정밀함이 요구된다.

메모리 레이어(Memory Layer)는 에이전트가 대화 이력, 이전 작업 결과, 사용자 선호도를 저장하고 검색하는 시스템이다. 메모리는 단기·장기·에피소딕·의미론적 메모리로 분류된다.

RAG 파이프라인(Retrieval-Augmented Generation)은 외부 지식 베이스에서 관련 정보를 검색하여 컨텍스트에 주입하는 메커니즘이다. 검색 품질이 전체 응답 품질의 천장을 결정하므로, 임베딩 모델 선택·청킹 전략·재순위화(reranking) 알고리즘이 핵심 설계 변수다.

⤢✕

최적화 단위가 다르다: 문장이냐, 파이프라인이냐

두 접근법의 차이는 단순히 "범위의 차이"가 아니라 설계 철학의 차이다.

프롬프트 엔지니어링은 정적 텍스트 최적화를 지향한다. 특정 태스크에 대한 최선의 지시문을 찾아 고정하는 작업이다. Chain-of-Thought, Few-shot, Zero-shot, 역할 부여 등의 기법이 모두 더 나은 지시문을 작성하는 방법론이다. 최적화 단위가 "문장"이고, 평가 단위가 "단일 응답 품질"이다.

컨텍스트 엔지니어링은 동적 정보 아키텍처 설계를 지향한다. 에이전트가 실행되는 매 순간 최적의 컨텍스트가 조립되도록 시스템을 설계하는 작업이다. 최적화 단위가 "정보 파이프라인"이고, 평가 단위가 "에이전트 세션 전체의 품질"이다.

구분	프롬프트 엔지니어링	컨텍스트 엔지니어링
최적화 단위	개별 프롬프트 텍스트	전체 정보 환경
시간 범위	단일 요청-응답	멀티스텝 에이전트 세션
주요 기술	CoT, Few-shot, 역할 부여	RAG, 메모리, 툴 스펙, 상태 관리
실패 진단	프롬프트 재작성	파이프라인 병목 분석
스케일링	수동 반복 개선	시스템적 자동화
핵심 역량	언어적 직관	정보 아키텍처 설계

실무에서 두 접근법은 배타적이지 않다. 컨텍스트 엔지니어링 시스템 안에서도 개별 구성요소(시스템 프롬프트, ICL 예시)를 최적화할 때 프롬프트 엔지니어링 기법이 사용된다. 차이는 설계의 주된 관심사가 어디에 있는가다.

컨텍스트 윈도우는 토큰 예산으로 나눈다

현대 LLM의 컨텍스트 윈도우는 128K~1M 토큰으로 대폭 확장되었지만, 무한하지 않다. 컨텍스트가 길어질수록 추론 비용이 증가하고, "Lost in the Middle" 현상(컨텍스트 중간부의 정보를 모델이 간과하는 경향)이 두드러진다. 컨텍스트 윈도우 최적화는 컨텍스트 엔지니어링의 핵심 실천 과제다.

⤢✕

핵심 전략은 토큰 예산 할당(Token Budget Allocation)이다. 컨텍스트의 각 구성요소에 토큰 예산을 할당하고, 예산 내에서 가장 관련성 높은 정보만 포함시킨다. RAG 결과는 재순위화 후 상위 K개만 포함하고, 대화 히스토리는 슬라이딩 윈도우 방식으로 오래된 내용을 압축·요약한다.

컨텍스트 캐싱(Context Caching)은 비용 최적화의 핵심 도구다. Anthropic Claude API의 프롬프트 캐싱 기능을 활용하면 시스템 프롬프트나 자주 사용되는 문서가 포함된 컨텍스트를 서버 측에 캐싱하여 재사용 시 토큰 비용을 90%까지 절감할 수 있다. 자주 변경되지 않는 컨텍스트 구성요소를 캐시 경계(cache boundary) 기준으로 배치하는 것이 설계 원칙이다.

컨텍스트도 감사·통제 대상이다

IBM, Neo4j, Salesforce 등 엔터프라이즈 기업들이 컨텍스트 엔지니어링을 도입하면서 새로운 거버넌스 과제가 부상했다. 에이전트가 어떤 정보에 접근하고 어떤 컨텍스트로 추론하는지를 추적·감사할 수 있어야 한다는 요구다.

추적 가능성(Traceability)은 에이전트가 특정 응답을 생성할 때 어떤 컨텍스트 구성요소가 사용되었는지 기록해야 한다는 원칙이다. 어떤 문서가 RAG 검색 결과로 포함되었는지, 어떤 메모리가 활성화되었는지, 어떤 도구 호출이 실행되었는지 모두 로깅되어야 한다.

접근 제어(Access Control)는 에이전트가 접근할 수 있는 데이터 소스와 도구를 역할 기반으로 제한해야 한다는 원칙이다. 고객 지원 에이전트는 고객 데이터에만 접근하고, 내부 분석 에이전트는 재무 데이터에 접근하는 식으로 격리해야 한다.

컨텍스트 오염 방지(Context Poisoning Prevention)는 악의적이거나 잘못된 정보가 컨텍스트에 주입되어 에이전트를 오도하는 공격을 방어해야 한다는 원칙이다. RAG 파이프라인의 데이터 소스 검증, 툴 실행 결과의 무결성 확인이 필수다.

컨텍스트 엔지니어링은 프롬프트 엔지니어링을 부정하는 것이 아니라 그 위에 구축되는 더 넓은 설계 패러다임이다. AI 에이전트가 단일 질문에 답하는 수준을 넘어 수십 단계의 복잡한 작업을 자율적으로 수행하는 시대에, "무엇을 하라"는 지시보다 "어떤 정보를 가지고 있는가"가 에이전트 성능을 결정하는 핵심 변수가 된다.