컨텍스트 엔지니어링

검증됨 · 확인 2026-07 · 고침 2026-08-09

컨텍스트 엔지니어링은 프롬프트 엔지니어링의 확장판이다. 프롬프트 엔지니어링이 단발성 요청에 좋은 시스템 프롬프트를 쓰는 일이라면, 컨텍스트 엔지니어링은 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 대비 하락, 여러 개면 가중된다고 관찰했다(수치는 실험 세팅 의존, 정성적으로만).

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

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

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

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

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

가장 가볍고 안전한 형태는 툴 결과 오프로딩이다 — 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 / thinking).
• 모든 assistant 턴이 thinking 으로 시작한다고 가정하지 마라. Claude thinking 은 adaptive — 요청마다 생각 여부/깊이를 모델이 정한다. 같은 대화에 thinking 있는 턴과 없는 턴이 섞인다.
• effort 를 중간에 바꾸면 캐시가 깨진다. effort 값이 프롬프트에 렌더되므로 요청 간 변경은 프롬프트 캐시를 무효화한다(cache_creation 재발생, cache_read 0). 대화 수명 동안 effort 를 고정하라.
• 한글은 토큰을 많이 먹는다. CJK 는 cl100k_base 기준 문자당 대략 1토큰으로 영어보다 약 4배. 같은 예산이라도 한국어 컨텍스트는 더 빨리 찬다.
• 롱컨텍스트 프리미엄 구조. 요청이 특정 토큰 임계값을 넘으면 롱컨텍스트 프리미엄 요금대로 올라가는 과금 구조가 존재해왔고 변화해왔다(구체 per-token 가격은 2026 LLM 지형도 — 모델 한눈에 first-party 표를 따르고, 집계 기사 수치는 인용하지 않는다).

실전 전술

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

참고

• 토큰과 컨텍스트 윈도우 — 토큰·컨텍스트 윈도우·lost-in-the-middle·토크나이저 함정
• 추론모델 (reasoning models / thinking) — thinking 토큰 과금·adaptive·effort 다이얼
• 에이전트 설계 패턴 — 서브에이전트 격리, 롱호라이즌 루프 설계
• 프롬프트 캐싱 — 캐시 프리픽스와 effort 변경이 캐시를 깨는 상호작용
• RAG 파이프라인 만들기 — 검색된 사실을 컨텍스트에 얼마나 넣을지
• 프롬프트 패턴 치트시트 — 프롬프트 엔지니어링(단발) 쪽 레퍼런스

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