개념
verified · type: explanation · verified: 2026-07 · review: 180d · updated: 2026-08-09 · [concept, agentic]

컨텍스트 엔지니어링

에이전트가 여러 턴을 돌수록 답이 흐트러질 때, "무엇을 컨텍스트에 남기고 무엇을 버릴지"를 설계하려고 여는 문서.

컨텍스트 엔지니어링은 프롬프트 엔지니어링의 확장판이다. 프롬프트 엔지니어링이 단발성 요청에 좋은 시스템 프롬프트를 쓰는 일이라면, 컨텍스트 엔지니어링은 Anthropic 의 정의로 "the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference" — 즉 에이전트 lifecycle 전반에 걸쳐 컨텍스트 윈도우(context window)에 담기는 토큰을 반복적으로 큐레이션하는 일이다. 지도 원칙은 하나다: "the smallest set of high-signal tokens that maximize the likelihood of some desired outcome" — 원하는 결과 확률을 최대화하는 최소한의 고신호 토큰 집합.


왜 예산 문제인가

컨텍스트는 유한 자원이다. 트랜스포머는 모든 토큰이 다른 모든 토큰에 attend 하므로 n개 토큰에 n² pairwise 관계가 생기고, 이 "attention budget"이 토큰마다 조금씩 소진된다. 절벽처럼 갑자기 죽는 게 아니라 점진적으로 성능이 저하된다. Anthropic 은 이를 context rot 라 부른다 — 토큰이 늘수록 모델이 정보를 정확히 recall 하는 능력이 떨어진다.

이건 벤더 하나의 주장이 아니다. Chroma 의 context rot 연구(GPT-4.1·Claude 4·Gemini 2.5·Qwen3 등 18개 모델)도 "model performance varies significantly as input length changes, even on simple tasks"를 보였고, distractor 가 하나만 섞여도 baseline 대비 하락, 여러 개면 가중된다고 관찰했다(수치는 실험 세팅 의존, 정성적으로만).

관련해서 위치 효과도 있다. tokens-and-context-windows 의 lost-in-the-middle 참고 — 관련 정보가 프롬프트 중간에 있으면 처음·끝에 있을 때보다 성능이 떨어진다(U자형). 실무 결론: 중요한 내용은 컨텍스트의 맨 앞이나 맨 뒤에 둔다.


컨텍스트 예산을 어디에 배분하나

그림 — 컨텍스트 창은 예산이다
시스템
도구 정의
대화 히스토리
RAG · 문서
질문
출력 여유
창이 커도 공짜가 아니다 — 토큰은 돈이고, 채울수록 주의는 흐려진다. 어느 칸을 줄여 어디에 줄지가 이 절의 주제다.

한 턴의 컨텍스트는 대략 이렇게 나뉜다. 각 항목이 attention budget 을 먹으므로, "지금 이 태스크에 정말 필요한가"로 걸러야 한다.

배분 대상 원칙
시스템 프롬프트 / 역할 지시 짧고 고신호. 캐시 프리픽스로 고정(prompt-caching)
툴 정의 지금 턴에 안 쓸 툴은 뺀다. 너무 많으면 tool search 로
대화 이력 전부가 아니라 관련 슬라이스만. 오래된 건 요약/제거
검색된 사실(RAG) 상위 몇 개만. 나머지는 참조 링크로 (build-a-rag-pipeline)
툴 결과 대용량은 컨텍스트에 다 넣지 말고 외부에 두고 요약만

압축 vs 편집 vs 메모리 vs 서브에이전트 (선택표)

긴 에이전트 루프에서 컨텍스트가 한도에 근접할 때 쓰는 기법들이다. Anthropic 블로그는 아래 중 compaction · note-taking/memory · sub-agent 세 가지를 명시한다(제품명이 아니라 패턴 수준으로 이해하라).

기법 무엇을 하나 언제 쓰나 주의
압축(compaction) 한도에 근접한 대화를 요약해 새 컨텍스트 윈도우로 재시작 한 태스크가 윈도우를 다 채워갈 때 요약 시 아키텍처 결정·미해결 버그·구현 세부는 반드시 보존
편집(clearing) scaffold 안에서 규칙 기반 pruning 으로 오래된/불필요 토큰 제거 이력이 길지만 요약까진 과할 때 규칙이 핵심 정보를 지우면 손실. compaction(요약)과 다른 층위 (재확인 필요)
메모리(note-taking) 노트를 컨텍스트 윈도우 바깥 메모리에 지속 저장 세션/턴을 넘어 일관성이 필요할 때 working context 를 안 채우는 게 요점
서브에이전트 격리 전문 서브에이전트가 clean context 로 작업하고 응축 요약만 반환 하위 태스크가 깊은 탐색을 요구할 때 반환은 보통 1,000~2,000 토큰 요약. 부모 컨텍스트를 오염시키지 않음

가장 가볍고 안전한 형태는 툴 결과 오프로딩이다 — Anthropic 이 "the safest, lightest touch form of compaction"이라 부른다. 큰 툴 출력을 컨텍스트에 통째로 남기지 말고 외부에 두고 요약·참조만 남긴다. 여기서부터 시작하고, 그래도 부족하면 compaction → sub-agent 순으로 올린다.

경계 주의. Anthropic 이 "context editing"·"memory tool" 을 정확히 어떤 별도 베타 제품/API 이름으로 냈는지는 1차 확인 못 함(재확인 필요). 위 표는 패턴 이지 제품 스펙이 아니다.


긴 루프에서 컨텍스트가 썩는 방식 (gotcha)

  • 점진적 저하라 눈치채기 어렵다. 40턴째부터 답이 미묘하게 빗나가는데 에러는 안 난다. context rot 는 조용하다.
  • thinking 토큰이 예산을 먹는다. 추론모델은 내부 추론 토큰이 output 으로 과금되고 컨텍스트 공간도 차지한다. 이전 턴 thinking 블록이 남으면 input 으로 재과금된다. 상세는 reasoning-models.
  • 모든 assistant 턴이 thinking 으로 시작한다고 가정하지 마라. Claude thinking 은 adaptive — 요청마다 생각 여부/깊이를 모델이 정한다. 같은 대화에 thinking 있는 턴과 없는 턴이 섞인다.
  • effort 를 중간에 바꾸면 캐시가 깨진다. effort 값이 프롬프트에 렌더되므로 요청 간 변경은 프롬프트 캐시를 무효화한다(cache_creation 재발생, cache_read 0). 대화 수명 동안 effort 를 고정하라.
  • 한글은 토큰을 많이 먹는다. CJK 는 cl100k_base 기준 문자당 대략 1토큰으로 영어보다 약 4배. 같은 예산이라도 한국어 컨텍스트는 더 빨리 찬다.
  • 롱컨텍스트 프리미엄 구조. 요청이 특정 토큰 임계값을 넘으면 롱컨텍스트 프리미엄 요금대로 올라가는 과금 구조가 존재해왔고 변화해왔다(구체 per-token 가격은 models-overview first-party 표를 따르고, 집계 기사 수치는 인용하지 않는다).

실전 전술

  • 툴 결과 오프로딩부터. 가장 싸고 안전하다. 큰 출력은 외부 저장 + 요약 참조.
  • compaction 요약에 "보존 목록"을 명시하라. 아키텍처 결정·미해결 버그·구현 세부. 이걸 안 적으면 요약이 맥락을 날린다.
  • 깊은 하위 탐색은 서브에이전트로 격리하라. 부모 컨텍스트를 clean 하게 유지하고 응축 요약만 받는다 (agent-design-patterns).
  • 중요 지시는 앞이나 뒤에. 중간 매몰을 피한다.
  • 토큰은 추정하지 말고 세라. Claude 는 공개 토크나이저가 없으므로 count_tokens 엔드포인트, OpenAI 는 tiktoken. 다른 vocab 모델을 tiktoken 으로 세면 틀린다 (tokens-and-context-windows).
  • 덜 생각하게 하려면 프롬프트보다 effort 를 먼저 낮춰라. calibrated control 이 문구 튜닝보다 안정적이다.

참고

출처: 컨텍스트 엔지니어링 정의·context rot·3대 기법은 Anthropic 1차 [HIGH]. Chroma context rot 연구·토크나이저·롱컨텍스트 과금은 [aggregator/MED]. 제품 경계·수치는 정성적으로만. 원본 → 2026-07-25-concepts-core