컨텍스트 엔지니어링: AI 출력이 평범한 이유와 입력을 개선하는 방법

출력이 평범한 이유는 입력이 과도하거나, 오래되었거나, 순서가 잘못되었기 때문입니다. 프롬프트 문장이 잘못된 게 아닙니다. Anthropic의 공식 문서도 이를 명확하게 밝히고 있습니다: "더 많은 컨텍스트가 자동으로 더 나은 결과를 보장하지는 않습니다. 토큰 수가 증가할수록 정확도와 재현율이 저하되는데, 이를 컨텍스트 로트(context rot)라고 합니다" (Claude Platform 문서). 컨텍스트 엔지니어링이 이 문제의 해결책이며, Anthropic은 이를 "LLM 추론 중 최적의 토큰(정보) 집합을 선별하는 것"으로 정의합니다 (Anthropic Engineering).

수치는 최대주의적 습관에 가혹합니다. NoLiMa에서 128K 이상의 컨텍스트를 광고하는 13개 모델 중 11개가 32K 토큰에서 단문 컨텍스트 점수의 절반 이하로 떨어졌습니다 (arXiv:2502.05167).

이 글은 에이전트 프레임워크를 구축하는 개발자가 아니라, ChatGPT, Claude, Gemini, Copilot을 실제로 사용하는 사람들을 위한 플레이북입니다: 어떤 제품에서 어떤 설정을 조정해야 하는지, 그리고 그게 어느 정도 가치가 있는지.

컨텍스트 엔지니어링이 프롬프트 마법을 대체한 이유

출력이 평범하다면, 프롬프트 문구 자체가 문제인 경우는 드뭅니다. 컨텍스트 엔지니어링은 이 문제를 해결하기 위한 실践입니다. Anthropic은 이를 "LLM 추론 중 프롬프트 외부에서 입력될 수 있는 모든 정보를 포함해 최적의 토큰 집합을 선별하고 유지하는 전략의 총체"로 정의하며, 프롬프트 엔지니어링의 자연스러운 발전으로 봅니다 (Anthropic Engineering). 질문이 "어떻게 표현할까?"에서 "어떤 컨텍스트 구성이 모델의 원하는 동작을 가장 잘 이끌어낼까?"로 바뀐 것입니다.

"어떻게 표현할까?"에서 "윈도우에 무엇을 넣을까?"로

표현은 여전히 세부적으로 중요합니다. 다만 더 이상 핵심 레버리지가 거기에 있지 않습니다. 완벽하게 표현된 질문이라도 과도하고 절반만 관련된 윈도우에 맞부딪히면, 깔끔한 윈도우에 던진 투박한 질문에 집니다. 이 글의 나머지 대부분은 그 주장에 대한 근거입니다.

우리가 추적하는 212개의 프롬프트 엔지니어링 도구 대부분이 여러분이 입력하는 문장을 최적화합니다. 윈도우를 공유하는 나머지 다섯 가지 요소를 건드리는 도구는 거의 없습니다.

실제로 제어 가능한 다섯 가지 입력

모든 요청은 여러분이 보고 변경할 수 있는 부분들로 윈도우를 구성합니다:

• 시스템 지침: 커스텀 GPT의 지침 필드, Claude 프로젝트의 설명, 또는 저장소의 CLAUDE.md 파일.
• 메모리: 제품이 세션 간에 저장한 정보로, 보통 전체 텍스트를 보여주지 않습니다.
• 첨부 문서와 그 파싱 품질 — 전체 스택에서 가장 과소평가된 변수입니다.
• 검색된 청크: 도구가 검색을 수행한다면, 검색기가 관련성 있다고 판단한 내용.
• 이전 대화 턴 — 20개 메시지 전에 포기한 막다른 길까지 포함해서.
• 도구 정의: 실제 도구가 호출되든 안 되든 토큰을 소비합니다.

여섯 가지이며, 모두 제품 UI에서 제어할 수 있습니다. 프레임워크도, API 키도 필요 없습니다.

이 글은 에이전트 시스템을 구축하는 사람이 아닌, ChatGPT, Claude, Gemini, Copilot을 사용하는 사람들을 위한 입력 측 플레이북입니다. 어떤 제품에서 어떤 설정을 조정하고, 2026년 수치가 그 가치를 어떻게 말하는지.

AI 컨텍스트 윈도우 설명: 광고 크기 vs 실제 사용 가능 크기

스펙 시트의 숫자는 저장 한도이지, 성능 보증이 아닙니다. 백만 토큰을 수용하는 모델은 기꺼이 받아들이고 나서 3,000개로 작업할 때보다 더 나쁜 답을 줄 수 있습니다. 광고된 윈도우를 방의 천장으로 생각하세요 — 작업할 수 있는 책상 크기가 아닙니다.

실제로 윈도우에 포함되는 것들

생각보다 훨씬 많습니다. API 요청의 모든 부분이 동일한 예산을 차지합니다: 시스템 프롬프트, 도구 결과를 포함한 스레드의 모든 메시지, 이미지와 PDF, 도구 정의 자체, 확장된 사고를 포함한 모델의 자체 출력 (Claude Platform 문서). 캐시된 접두사도 윈도우를 차지합니다. 프롬프트 캐싱은 해당 토큰에 대해 지불하는 비용을 변경하지만, 토큰이 카운트되는지 여부는 바꾸지 않습니다.

따라서 짧게 느껴지는 대화가 실제로는 첨부 PDF, 도구 스키마, 이전 추론의 40,000개 토큰을 담고 있을 수 있습니다. 그게 백과사전 페이지들이 빠뜨리는 부분입니다.

스펙 시트에 없는 32K 절벽

NoLiMa 벤치마크는 질문과 건초더미 속에 숨겨진 답변 사이의 문자 그대로의 단어 중복을 제거하고, 128K 이상의 컨텍스트를 주장하는 13개 모델을 실행했습니다. 1K 토큰 이하에서는 잘 작동했습니다. 32K에서는 13개 중 11개가 단문 컨텍스트 기준선의 절반 이하로 떨어졌고, Llama 3.1 70B는 94.3%에서 42.7%로 하락했습니다 (NoLiMa, arXiv:2502.05167). 이 프리프린트는 2025년 2월로 아래 표의 모든 모델보다 앞선 것입니다. 발견의 패턴은 최신 연구에서도 유효하지만, 구체적인 수치는 현재 성적표가 아닌 오래된 증거입니다.

현재 윈도우의 실제 크기 (2026년 수치)

Anthropic은 베타 헤더나 추가 요금 없이 1M 윈도우를 제공합니다 (Claude Platform 문서). OpenAI는 명목상 더 크고 가격 정책이 다릅니다: GPT-5.4에서 272K 입력 토큰을 초과하면 전체 세션이 입력 2배, 출력 1.5배로 청구됩니다 (OpenAI API 문서). 거기서 과도한 컨텍스트는 품질 세금이 아니라 실제 청구 항목입니다.

공급업체 간 용량을 비교할 때는 요약본이 아닌 모델의 공식 스펙 페이지를 확인하세요. 2026년에만 윈도우가 두 번 변경되었고, 오래된 표가 넘쳐납니다. 당사의 324개 AI 모델 디렉터리가 올바른 페이지를 찾는 출발점이 됩니다.

컨텍스트 로트: 더 많이 추가할수록 출력이 나빠지는 이유

저하에는 메커니즘이 있으며, 신비롭지 않습니다. 트랜스포머는 n개의 토큰에 걸쳐 n² 쌍별 관계를 모델링해야 하므로, 토큰을 추가할 때마다 다른 모든 토큰이 모델의 주의를 조금 더 차지하려 경쟁합니다. Anthropic의 엔지니어링 팀은 이를 인간의 작업 기억과 유사한 유한한 주의 예산으로 부르며, 컨텍스트가 늘어남에 따라 주의가 "얇게 펴진다"고 말합니다. 그들의 처방은 명확합니다: "원하는 결과의 가능성을 최대화하는 최소한의 고신호 토큰 집합"을 찾으세요.

주의 예산 문제

Anthropic의 자체 제품 문서는 이를 포장하지 않고 인정합니다. "더 많은 컨텍스트가 자동으로 더 나은 결과를 보장하지는 않습니다," 플랫폼 문서는 이렇게 말합니다. "토큰 수가 증가할수록 정확도와 재현율이 저하되는데, 이를 컨텍스트 로트라고 합니다." 1M 토큰 윈도우를 판매하는 공급업체가 직접 채우지 말라고 하는 것입니다.

같은 질문, 같은 답변, 375배의 노이즈

Chroma는 GPT-4.1, Claude 4, Gemini 2.5, Qwen3을 포함한 18개 모델을 테스트했고, 단순한 검색 및 단어 복제 작업에서도 긴 입력에서 신뢰성이 떨어진다는 것을 발견했습니다 (Chroma). LongMemEval 실행이 핵심입니다. 모든 모델 패밀리가 관련 턴만 포함한 약 300 토큰의 집중된 프롬프트에서 전체 대화 이력을 담은 약 113k 토큰의 전체 프롬프트보다 훨씬 좋은 성능을 보였으며, Claude 모델이 가장 큰 격차를 보였습니다. 같은 질문, 같은 답변이 양쪽 컨텍스트에 있었습니다. 달라진 유일한 변수는 주변의 관련 없는 내용의 양이었습니다.

Chroma는 또한 모든 18개 모델에서 섞인 건초더미보다 논리적으로 일관된 문서에서 더 낮은 점수를 받았다고 발견했습니다. 일관된 주변 텍스트가 모델이 착지할 그럴듯한 장소를 더 많이 제공하기 때문입니다. 이 보고서는 2025년 7월 14일에 발표되어 1년 이상 지났고 현재 모델 세대보다 앞선 것입니다.

그 효과는 사라지지 않았습니다. MonitorBench에서 800k 토큰의 무해하고 관련 없는 액션을 앞에 추가하자 Opus 4.6의 재현율이 98.6%에서 88%로 떨어졌습니다 (arXiv:2605.12366). 작업 자체는 아무것도 바뀌지 않았습니다. 패딩만 달라졌습니다.

일반적인 사용에서 문제가 되는 상황

이미 이름 없이 경험해봤을 것입니다. 메시지 12번에서 요청을 완벽하게 처리했던 대화가 메시지 90번에서 일반적인 내용을 생성하는 경우 — 요청 내용이 78개의 절반쯤 포기한 초안 메시지 아래 묻혀 있기 때문입니다. 철저함을 위해 40개 소스를 추가한 NotebookLM 노트에서 8개일 때보다 더 모호한 답변이 나오는 경우. 한 시간 전에 명시한 제약을 모델이 잊어버리고 자신 있게 그것을 무시해서 재작성하는 코딩 세션.

그것 중 어느 것도 모델이 게을러지는 게 아닙니다. 제 역할을 하지 못하는 토큰에 주의 예산을 쓰고 있는 것입니다.

문서 준비: 거의 모든 사람이 건너뛰는 단계

프롬프트에서 문서를 어디에 놓느냐가 받는 답변을 바꿉니다. 20,000 토큰 이상의 입력의 경우, Anthropic의 프롬프팅 문서는 긴 데이터를 맨 위, 즉 쿼리, 지침, 예시 위에 놓으라고 합니다: "쿼리를 끝에 두면 특히 복잡한 다중 문서 입력에서 테스트 시 최대 30%까지 응답 품질을 향상시킬 수 있습니다" (Claude Platform 문서). 대부분의 사람들은 반대로 합니다. 질문을 먼저 입력하고 그 아래에 보고서를 붙여넣습니다.

긴 내용을 맨 위에 놓으세요

같은 문서가 그대로 복사할 가치가 있는 구조를 제공합니다: 각 문서를 <document> 태그로 감싸고 <source>와 <document_content> 하위 태그를 사용하면, 모델이 한 파일이 어디서 끝나고 다음이 시작되는지 알 수 있습니다 (Claude Platform 문서). 그런 다음 답변하기 전에 관련 구절을 인용하도록 요청하세요. 이 한 줄이 모델로 하여금 반쯤 기억하는 내용을 재구성하는 대신 텍스트에서 증거를 찾도록 강제하며, 답변이 잘못 보일 때 확인할 수 있는 것을 제공합니다.

<document>
  <source>Q3-board-deck.pdf</source>
  <document_content>...full text here...</document_content>
</document>
<document>
  <source>renewal-contract-2026.pdf</source>
  <document_content>...full text here...</document_content>
</document>

Before answering, quote the passages you relied on.
Question: which renewal terms conflict with the Q3 revenue plan?

모델이 출처를 인용할 수 있도록 소스를 태그하세요

이것을 표준으로 삼기 전에 한 가지 주의사항: 공급업체마다 다릅니다. Anthropic은 긴 데이터를 먼저 놓도록 하지만, Google의 가이드라인은 반대로 지침을 마지막에 두라고 합니다. 따라서 Gemini 튜토리얼에서 가져온 프롬프트 템플릿을 Claude에 붙여넣으면 겉으로 보기에는 문제없어 보여도 성능이 떨어질 수 있습니다. 실제로 사용하는 모델에서 같은 문서 세트를 두 가지 방식으로 실행해 보세요, 각각 10개 질문으로. 더 좋은 순서를 유지하세요. 최대 30% 차이에 비해 20분의 작업입니다.

파서 선택이 모델이 실제로 보는 것을 결정합니다

이것 중 어느 것도 잘못 추출된 내용을 구해낼 수 없습니다. 한 줄로 이어진 스캔된 인보이스 표, 열 단위로 섞인 두 컬럼 논문, 문장 중간에 삽입된 각주: 모델은 그 쓰레기를 충실하게 읽고 그것을 기반으로 답변합니다. 추출 단계가 정확도의 상한선을 설정하고, 그 아래의 모든 것은 이에 의해 제한됩니다. 파서를 품질 결정으로 취급하고 가장 어려운 실제 파일에서 두세 가지를 테스트한 후 결정하세요. 당사 디렉터리에는 217개의 AI 문서 및 PDF 도구가 있으며, 좋은 도구와 나쁜 도구의 차이는 마케팅 페이지가 아닌 출력에서 나타납니다.

검색 위생: 더 많은 청크보다 더 적고 좋은 청크가 낫습니다

검색 레이어를 구축하기 전에 필요한지 먼저 확인하세요. Anthropic의 자체 가이드라인은 지식 베이스가 200,000 토큰 미만(약 500페이지)이라면 검색 없이 전체 내용을 프롬프트에 포함시킬 수 있다고 합니다 (Anthropic Engineering). 대부분의 내부 위키, 제품 핸드북, 정책 문서가 이 한계 이내에 들어옵니다.

검색이 정말 필요한가요?

코퍼스가 맞는다면, 벡터 데이터베이스를 건너뛰세요. 청킹 결정, 임베딩 드리프트, 올바른 단락이 프롬프트에 들어가지 못하는 조용한 실패의 전체 클래스를 피할 수 있습니다. 프롬프트 캐싱과 함께 사용하면 동일한 200k 토큰을 매번 호출할 때 전액 지불하지 않아도 됩니다.

그 크기를 초과하면 검색이 선택 사항이 아니게 되고, 품질은 복합적으로 작용하는 소소한 수정들의 집합이 됩니다.

복합적으로 작용하는 세 가지 수정

Anthropic이 하나씩 벤치마킹했습니다. 임베딩 전에 각 청크에 청크별 컨텍스트를 앞에 추가하면 상위 20 검색 실패가 5.7%에서 3.7%로 줄어들었는데, 약 35% 감소입니다. 컨텍스트 BM25 하이브리드 검색을 추가하면 실패가 2.9%로, 49% 감소. 리랭킹 패스를 레이어로 추가하면 1.9%로, 총 67% 감소가 됩니다 (Anthropic Engineering). 각 단계는 자체적으로는 평범해 보이고, 세 가지를 합치면 첫 번째 단계의 개선 효과가 대략 세 배가 됩니다.

도구 정의 줄이기도 중요합니다

도구 스키마는 컨텍스트입니다. 모델에게 40개의 도구 정의를 주고 두 개만 필요하다면, 38개의 방해 요소 비용을 지불한 것입니다. RAG-MCP 작업은 모든 스키마를 나열하는 대신 관련 스키마만 검색했고, 프롬프트 토큰이 절반 이상 줄어든 반면 도구 선택 정확도는 13.62%에서 43.13%로 올랐습니다 (arXiv:2505.03275). 이는 청크 선택과 같은 원칙을 한 레이어 위에 적용한 것입니다.

Anthropic의 서브 에이전트 패턴은 이것을 한 단계 더 확장합니다: 전문화된 에이전트가 검색을 수행하고 조정 에이전트에게 약 1,000~2,000 토큰의 압축된 요약을 반환하므로, 메인 컨텍스트는 원시 검색 기록을 볼 일이 없습니다 (Anthropic Engineering). 직접 구축하는 대신 컴포넌트를 선택한다면, 당사 디렉터리에는 550개의 AI 에이전트와 이러한 패턴을 기본으로 구현한 검색 및 에이전트 프레임워크가 있습니다.

메모리 기능: 각 도구에서 조정할 설정

모든 소비자용 AI 제품은 이제 여러분이 입력하지 않은 것들을 컨텍스트에 주입합니다. 저장된 사실, 이전 대화, 앱 활동, 업로드된 프로젝트 파일. 채팅 앱에서 컨텍스트 엔지니어링을 할 수 없습니다 — 첫 번째 단어 전에 윈도우에 무엇이 있는지 알아야 합니다.

잘못된 메모리는 메모리가 없는 것보다 더 나쁩니다. 모델이 사실로 취급하는 고신호처럼 보이는 텍스트이며, 주의가 가장 강한 지침 근처에 자리 잡습니다. 오래된 직함, 이전 클라이언트 이름, 일회성 작업을 위해 한 번 설정한 선호도: 각각이 그 이후의 모든 답변을 조용히 편향시킵니다.

ChatGPT: 두 개의 독립적인 토글

ChatGPT의 메모리는 하나가 아닌 두 가지 메커니즘입니다. 저장된 메모리는 개별적으로 읽고 삭제할 수 있는 개별 저장 사실이며, 대화 기록 참조는 별도의 검색 경로를 통해 이전 대화에서 가져옵니다 (Embrace The Red). 하나를 끄면 다른 것은 계속 실행됩니다. 저장된 메모리를 지운 후에도 출력이 지난달 프로젝트처럼 보인다면, 기록 토글이 놓친 것입니다.

Claude: 프로젝트 지식과 대화 중 메모리 기록

2026년 8월 25일 Cowork 통합 이후, Claude는 세션 경계에서만이 아닌 대화 도중에도 메모리를 기록하므로, 대화에서 말한 내용이 이후 세션으로 이어집니다 (TechCrunch). 이는 무심코 한 말이 지속적인 컨텍스트가 될 수 있음을 의미합니다.

프로젝트 지식이 더 좋은 레버입니다. 직접 선택한 코퍼스이기 때문입니다. Anthropic의 200,000 토큰 기준(약 500페이지) 이내로 유지하면 검색 레이어 없이 전체를 포함시킬 수 있습니다 (Anthropic). 아카이브가 아닌 독서 목록처럼 정리하세요.

Gemini: '끄기'가 '삭제'가 아닌 세 개의 중첩 시스템

Gemini는 개인 컨텍스트, 직접 작성한 저장 정보, 연결된 Google 앱의 활동을 레이어로 쌓습니다. 소스를 비활성화하면 새로운 기록이 중단됩니다. 이미 저장된 것은 제거되지 않으므로, 감사를 위해서는 각 제어 항목을 개별적으로 방문해서 끄는 게 아니라 삭제해야 합니다.

NotebookLM: 소스 제한 대안

NotebookLM은 노트북에 포함할 수 있는 소스 수에 상한이 있으며, 그 제한이 유리하게 작용합니다. 다른 세 도구가 건너뛸 수 있게 하는 큐레이션을 강제합니다 — Anthropic이 처방하는 것과 동일한 원칙: 원하는 결과를 얻기 위한 최소한의 고신호 토큰 집합을 찾으세요 (Anthropic). 80개가 아닌 8개의 문서가 필요한 질문이라면, 거기서 시작하세요.

하나의 도구를 메모리 담당 어시스턴트로 선택하고 나머지는 깔끔하게 유지하세요. 당사 디렉터리의 13,174개 AI 앱 중에서 항목별로 메모리를 감사 가능하게 만드는 도구가 모든 것을 기억한다고 약속하는 도구보다 더 가치 있습니다.

프로젝트 수준 지침은 재사용 가능한 컨텍스트입니다

가장 저렴한 컨텍스트는 한 번 작성하는 컨텍스트입니다. 이제 모든 진지한 AI 도구에는 모든 세션에 주입되는 상시 지침을 위한 슬롯이 있습니다: 저장소의 AGENTS.md와 CLAUDE.md, Claude 프로젝트, ChatGPT 커스텀 지침, Copilot 지침 파일. 대부분의 사람들은 그 슬롯을 비워두고 새 대화마다 같은 세 단락의 배경을 다시 입력합니다.

상시 지침 파일이 재설명보다 나은 이유

10개 저장소와 124개 풀 리퀘스트에 걸친 연구에서 저장소 수준 AGENTS.md 파일이 에이전트의 동작에 미치는 영향을 측정했는데, 결과는 정확성만의 문제가 아니었습니다. 중간 실행 시간이 28.64% 감소했으며, 98.57초에서 70.34초로 줄었고, 출력 토큰도 비슷한 완료율에서 16.58% 줄었습니다 (arXiv:2601.20404). 에이전트가 이미 알고 있는 것들을 파악하기 위한 탐색을 멈춘 것입니다.

이것이 한 문장으로 요약한 논거입니다. 좋은 상시 컨텍스트는 모델을 더 빠르고 저렴하게 만들 뿐 아니라 더 정확하게 만듭니다. 에이전트가 토큰을 소비하는 대부분이 여러분의 관례를 재발견하는 것이기 때문입니다. 당사 디렉터리의 260개 AI 코딩 어시스턴트 중에서 선택한다면, 도구가 프로젝트 지침 파일을 읽는지 여부가 대부분의 기능 비교보다 더 좋은 필터입니다.

실제로 포함해야 할 것들

직접 읽을 만큼 짧게 유지하세요. 다섯 가지가 자리를 차지할 가치가 있습니다:

• 코드가 공지하지 않는 관례 — 어떤 테스트 러너가 실제이고 어떤 것이 더 이상 사용되지 않는지.
• 여러분의 어휘. "계정"과 "테넌트"가 여기서 다른 의미라면, 한 번 명시하세요.
• 원하는 출력 형태를 원하는 형식으로 — diff, 표, 다섯 개의 불릿.
• 짧은 금지 목록. 생성된 파일은 건드리지 말 것, 묻지 않고 의존성 추가하지 말 것.
• 소스 오브 트루스가 어디 있는지 — 그래야 모델이 추측하는 대신 그것을 쿼리합니다.

도구가 스스로 읽을 수 있는 것은 제외하세요. 디렉터리 트리, 파일 목록, 재서술된 함수 시그니처, README 요약. 에이전트가 한 번의 호출로 가져올 수 있는 것을 중복하는 데 쓰인 토큰이며, 중요한 지침과 주의를 경쟁합니다. 파일이 무시되기 시작하면 재작성하세요 — 보통은 너무 길어졌다는 신호입니다.

컨텍스트 과부하는 비용입니다

엉성한 컨텍스트는 출력 품질뿐 아니라 청구서에도 비용이 됩니다. 두 가지 가격 메커니즘이 이를 구체적으로 보여주며, 둘 다 동일한 원칙에 보상을 줍니다: 작고, 안정적이고, 정렬된 접두사.

GPT-5.4의 272K 단계 함수

OpenAI의 GPT-5.4는 최대 128,000 출력 토큰으로 1,050,000 토큰의 컨텍스트 윈도우를 제공하지만, 272K 입력 토큰 이상의 프롬프트는 "전체 세션에 대해 입력 2배, 출력 1.5배로 청구됩니다" (OpenAI API 문서). 잘 읽으세요. 한 번 선을 넘는다고 초과분에만 조금 더 청구되는 게 아닙니다. 전체 세션, 출력까지 포함해서 재가격 책정됩니다. 따라서 300K 토큰 덤프를 한 번 부주의하게 붙여넣으면 그 이후의 모든 턴에서 입력 청구서가 두 배가 됩니다.

어차피 답변을 저하시킬 가능성이 가장 높은 토큰에 두 배를 지불하는 것입니다.

캐싱은 안정적인 접두사에 보상을 줍니다

Claude API는 캐시 읽기를 기본 입력의 0.1배, 즉 90% 할인으로 가격 책정하며, 캐시 쓰기는 5분 TTL에 1.25배, 1시간 TTL에 2배입니다 (Claude Platform 문서). 작업 예시: 100k 토큰을 10번 재사용하면 캐시 없이 $5.00인 것이 $1.075, 즉 78.5% 절감됩니다.

이 할인은 접두사가 바이트 단위로 일치할 때만 적용됩니다. 캐싱은 정확한 접두사를 키로 사용하므로, 문서를 재정렬하거나, 시스템 프롬프트에 타임스탬프를 넣거나, 턴 사이에 도구 정의를 섞으면 읽기 가격 대신 쓰기 가격을 다시 지불합니다. 캐시를 따뜻하게 유지하는 습관은 재현율을 높게 유지하는 것과 동일합니다: 안정적인 내용을 고정된 순서로 앞에 두고, 마지막에는 쿼리만 변경하세요.

이번 주에 실행할 수 있는 컨텍스트 감사

이 중 어느 것도 API 키나 엔지니어링 티켓이 필요하지 않습니다. 모든 항목은 이미 있는 설정입니다.

다음 긴 세션 전 여섯 가지 체크

1. 1어제 것을 연장하는 대신 새 대화를 시작하세요. Chroma의 집중된 프롬프트(~300 토큰의 관련 턴)가 테스트한 모든 모델 패밀리에서 113k 토큰 전체 기록을 이겼으며, Claude가 가장 큰 격차를 보였습니다 (Chroma).
2. 2저장된 메모리를 읽고 오래된 것을 삭제하세요. 저장된 사실은 도움이 되든 안 되든 주입됩니다.
3. 312개의 평범한 문서보다 3개의 좋은 문서를 첨부하고, 각각을 <document> 태그와 <source> 하위 태그로 감싸서 모델이 구분할 수 있게 하세요 (Claude 문서).
4. 4긴 내용을 질문 위에 두세요. 20k 토큰 이상의 입력에서 그 순서는 Anthropic의 테스트에서 최대 30% 더 나은 응답 가치가 있습니다 (Claude 문서).
5. 5상시 지침을 한 번 작성해 두세요. 저장소 수준 AGENTS.md는 124개 PR에서 중간 실행 시간을 28.64%, 출력 토큰을 16.58% 줄였습니다 (arXiv).
6. 6해당 접두사를 턴마다 동일하게 유지하세요. 안정적인 접두사는 0.1배 입력 가격으로 캐시를 활용합니다 (Claude 문서).

대부분의 나쁜 출력을 고치는 한 가지 습관

프롬프트를 다시 작성하기 전에, 이미 윈도우에 있는 것을 보고 무언가를 제거하세요. Anthropic의 자체 문서가 말합니다: "더 많은 컨텍스트가 자동으로 더 나은 것은 아닙니다" (Claude 문서). 묻는 방식을 바꾸기 전에 모델에게 주는 것을 바꾸세요.

자주 묻는 질문

컨텍스트 엔지니어링이란 무엇이며, 프롬프트 엔지니어링과 어떻게 다른가요?

Anthropic은 컨텍스트 엔지니어링을 "프롬프트 외부에서 입력될 수 있는 모든 정보를 포함해 LLM 추론 중 최적의 토큰 집합을 선별하고 유지하는 전략의 총체"로 정의합니다 (Anthropic Engineering). 프롬프트 엔지니어링은 요청을 어떻게 표현할지 묻습니다. 컨텍스트 엔지니어링은 원하는 동작을 가장 잘 이끌어낼 가능성이 높은 컨텍스트 구성이 무엇인지 묻고, 시스템 프롬프트, 도구 결과를 포함한 모든 메시지, 이미지와 PDF, 도구 정의, 확장된 사고를 포함한 모델의 자체 출력 등 윈도우를 차지하는 모든 것을 다룹니다 (Claude Platform 문서). Anthropic은 이를 프롬프트 엔지니어링을 대체하는 것이 아닌 자연스러운 발전으로 봅니다.

더 큰 컨텍스트 윈도우가 항상 더 나은 AI 출력을 의미하나요?

아닙니다. 광고된 컨텍스트와 실제 사용 가능한 컨텍스트는 다른 숫자입니다: NoLiMa 벤치마크는 128K 이상을 지원한다고 주장하는 13개 모델을 테스트했고, 32K 토큰에서 13개 중 11개가 단문 컨텍스트 기준선의 절반 이하로 점수를 받았으며, Llama 3.1 70B는 94.3%에서 42.7%로 하락했습니다 (arXiv:2502.05167, 2025년 2월). Anthropic의 자체 플랫폼 문서는 명확하게 말합니다: "더 많은 컨텍스트가 자동으로 더 나은 것은 아닙니다. 토큰 수가 증가할수록 정확도와 재현율이 저하됩니다" (Claude Platform 문서). 윈도우를 채우는 것은 선형이 아닌 단계별로 비용이 발생합니다. OpenAI는 272K 입력 토큰 이상의 GPT-5.4 프롬프트를 전체 세션에 대해 입력 2배, 출력 1.5배로 청구합니다 (OpenAI API 문서).

컨텍스트 로트란 무엇이며 어떻게 피할 수 있나요?

컨텍스트 로트는 요청의 토큰 수가 증가함에 따라 정확도와 재현율이 저하되는 현상이며, Anthropic이 자체 문서에서 이름을 붙였습니다 (Claude Platform 문서). Chroma의 컨텍스트 로트 연구는 GPT-4.1, Claude 4, Gemini 2.5, Qwen3을 포함한 18개 모델을 테스트했고, 단순한 검색 및 단어 복제 작업에서도 긴 입력에서 신뢰성이 떨어진다는 것을 발견했습니다. LongMemEval 테스트에서는 모든 모델 패밀리가 약 113k 토큰의 대화 기록에 묻힌 같은 질문보다 약 300 토큰의 집중된 프롬프트에서 더 잘 수행했으며, Claude 모델이 가장 큰 격차를 보였습니다 (Chroma, 2025년 7월). 중요한 구절만 붙여넣고, 새 주제는 기존 대화를 연장하는 대신 새 대화를 시작하고, 전문화된 에이전트가 전체 기록이 아닌 1,000~2,000 토큰의 압축된 요약을 조정 에이전트에게 반환하도록 하여 피할 수 있습니다 (Anthropic Engineering).

ChatGPT, Claude 또는 Gemini 메모리를 꺼야 하나요?

작업에 따라 다릅니다. 메모리는 여러분이 선택하지 않은 토큰을 모든 것이 중요한 윈도우에 주입하기 때문입니다 (Claude Platform 문서). 모델이 역할, 스타일, 스택을 알면 다시 입력하지 않아도 되는 일상적인 작업의 경우, 켜두세요. 특정 문서의 고위험 분석의 경우, 메모리를 끈 상태로 새 대화를 시작하세요. Chroma가 모든 모델 패밀리가 관련 없는 기록 약 113k 토큰에 둘러싸인 것보다 집중된 약 300 토큰 프롬프트에서 더 잘 답했다는 것을 발견했기 때문입니다 (Chroma). 메모리를 모든 턴에 지불하는 시스템 프롬프트로 취급하고, 시스템 프롬프트를 정리하듯 정리하세요.

RAG가 필요한가요, 아니면 문서를 프롬프트에 붙여넣으면 되나요?

Anthropic의 가이드라인은 소규모에서는 검색이 불필요한 경우가 많다고 말합니다: "지식 베이스가 200,000 토큰 미만(약 500페이지)이라면 전체 지식 베이스를 프롬프트에 포함시킬 수 있습니다" (Anthropic Engineering, 2024년 9월). 그 이상에서는 Anthropic의 벤치마크에서 검색 위생이 복합적으로 작용합니다: 임베딩 전에 청크별 컨텍스트를 앞에 추가하면 상위 20 검색 실패가 5.7%에서 3.7%로 줄고, 컨텍스트 BM25 하이브리드 검색을 추가하면 2.9%, 리랭킹 패스를 추가하면 1.9%로 총 67% 감소합니다. 코퍼스가 맞는다면, 붙여넣기가 더 나은 기본값이며, 프롬프트 캐싱으로 재사용 비용이 기본 입력의 0.1배로 저렴합니다 (Claude Platform 문서).

긴 문서를 프롬프트에서 질문 앞에 놓아야 하나요, 뒤에 놓아야 하나요?

Claude의 경우, 긴 데이터를 맨 위, 쿼리, 지침, 예시 위에 두세요. Anthropic의 프롬프팅 문서는 20k 토큰 이상의 입력에 대한 구체적인 규칙으로 이것을 제시하며 "쿼리를 끝에 두면 특히 복잡한 다중 문서 입력에서 테스트 시 최대 30%까지 응답 품질을 향상시킬 수 있습니다"라고 말합니다 (Claude Platform 문서). 같은 문서에서 각 문서를 <document> 태그와 <source>와 <document_content> 하위 태그로 감싸고, 답변하기 전에 관련 구절을 인용하도록 모델에게 요청하라고 권장합니다. 공급업체마다 순서에 동의하지 않으므로, 한 공급업체의 요리책에서 복사한 템플릿이 다른 모델에서 성능이 떨어질 수 있습니다. 자체 작업에서 두 순서를 한 번씩 실행해 보는 것이 좋습니다.