본문으로 건너뛰기

긴 컨텍스트를 위한 프롬프팅

중급
What you'll learn
  • 긴 문서를 프롬프트 어디에 넣어야 하는지(위, 아래가 아니라) 그리고 그것이 최대 ~30%까지 왜 중요한지
  • <document> / <source> 태그로 여러 문서를 구조화하는 방법
  • 긴 문서 답변을 훨씬 더 근거 있게 만드는 인용문 추출 트릭
  • 1M 컨텍스트가 잘못된 도구일 때 — 그리고 검색이나 청킹이 맞을 때
  • 컨텍스트 인식과 압축이 Sonnet 5에서 어떻게 판도를 바꾸는지

긴 컨텍스트는 판도를 바꾼다 — 그리고 조용히 답변을 망칠 수도 있다. Sonnet 5, Opus 5, Opus 4.6/4.7이 기본으로 1M 토큰 윈도우를 탑재(베타 헤더 없음)하기 때문에, 모든 것을 붙여넣고 잘 되기를 바라는 유혹이 생긴다. 그러지 마라. 훌륭한 긴 컨텍스트 프롬프트와 형편없는 프롬프트의 결정적 차이는 구조 — 각 부분을 어디에 두고 어떻게 라벨링하느냐다.

실제로 결과를 바꾸는 네 가지 기법​

Guided walkthrough1 of 4
  1. 긴 문서와 참조 자료를 지시사항과 쿼리 위에 배치하고, 아래에 두지 마세요. Anthropic의 자체 테스트에 따르면 쿼리를 끝에 두면 응답 품질이 최대 30% 향상될 수 있습니다 — 특히 복잡한 다중 문서 입력에서 그렇습니다. 이것이 가장 큰 레버리지 하나입니다.

정형화된 형태​

Anthropic의 자체 템플릿 — 이것을 복사하기만 하면 1M 윈도우를 사용하는 대부분의 사람보다 이미 앞서 있습니다:

Long-context multi-document template

<documents>
<document index="1">
  <source>annual_report_2025.pdf</source>
  <document_content>
    {{ANNUAL_REPORT}}
  </document_content>
</document>
<document index="2">
  <source>competitor_analysis_q2.xlsx</source>
  <document_content>
    {{COMPETITOR_ANALYSIS}}
  </document_content>
</document>
</documents>

Find quotes from the two documents that are relevant to identifying strategic advantages we can press on in Q3. Place them in <quotes> tags with the source filename. Then, based only on those quotes, recommend three focus areas with a one-line justification each. Place your recommendations in <recommendations> tags.

이 프롬프트가 동시에 하는 세 가지 움직임을 주목하세요:

  1. 문서 먼저, 질문 마지막 — 실제 요청은 자료 아래에 위치합니다.
  2. 이름이 있는 소스 — 모든 문서에 Claude가 인용할 수 있는 파일명이 있습니다.
  3. 인용문 → 답변 — Claude는 무엇을 추천하기 전에 스스로 근거를 세워야 합니다.

컨텍스트 부패: 왜 더 많은 토큰 ≠ 더 나은 답변인가​

더 많은 컨텍스트가 자동으로 더 좋은 것은 아닙니다. 토큰 수가 증가함에 따라 정확도와 재현율이 저하됩니다 — Anthropic은 이것을 컨텍스트 부패(context rot) 라고 부릅니다. 모델은 긴 입력의 처음과 끝을 중간보다 더 안정적으로 사용하는 경향이 있습니다(고전적인 "중간에 길을 잃음" 효과).

실용적 결과:

  • 붙여넣기 전에 다듬어라. 관련 없는 섹션이 20%인 100k 토큰 덤프는 종종 60k 토큰의 큐레이팅된 버전에 밀립니다.
  • 중요도에 따라 순서를 정하라. 답변을 포함할 가능성이 가장 높은 문서를 <documents> 내부의 첫 번째에 배치하세요.
  • 프롬프트 캐싱은 금방 본전을 뽑는다. 안정적인 접두사 설계(시스템 프롬프트 + 문서가 턴마다 동일)는 캐시된 접두사를 토큰 가격의 ~10%로 읽는다는 뜻입니다. 프롬프트 캐싱을 참조하세요.
Watch out
  • 1M 윈도우 ≠ 유용한 주의력의 1M 토큰. 책상을 채울수록 정확도는 저하됩니다.
  • 거대한 붙여넣기의 중간에 요청을 파묻으면 그것은 과소평가됩니다.
  • Sonnet 5 / Opus 5에서 200k 입력 토큰을 초과하면 긴 컨텍스트 요금이 적용됩니다 — 리포지토리를 붙여넣기 전에 모델 페이지를 확인하세요.

1M 컨텍스트가 잘못된 도구일 때​

긴 컨텍스트는 "그냥 코드베이스를 붙여넣기"가 검색을 구축하는 것보다 더 간단하게 느껴지기 때문에 유혹적입니다. 때로는 그렇습니다. 종종 그렇지 않습니다. 다음과 같은 경우 대안을 선택하세요:

신호1M 붙여넣기보다 더 나은 대안
수천 개의 쿼리에 걸쳐 동일한 문서가 필요함검색 + RAG — 더 저렴하고 더 빠름
사용자가 매 턴마다 자신의 문서를 가져옴문서 업로드가 있는 Files API
답변에는 전체 코드베이스가 필요하지만 자주 다시 묻는 경우안정적인 접두사 코드베이스 스냅샷에 대한 프롬프트 캐싱
라인 단위의 감사 가능한 인용이 필요함청크 ID가 있는 검색 → "붙여넣기 어딘가"가 아니라 청크 인용
지연 시간이 원샷 품질보다 더 중요함청크 + 재순위, 그런 다음 상위 k만 전달

경험 법칙: 매 턴마다 다시 붙여넣기를 주저할 정도라면, 아마도 검색이 필요합니다.

Sonnet 5로 무엇이 바뀌는가 (컨텍스트 인식)​

Sonnet 5, Sonnet 4.6, Sonnet 4.5, Haiku 4.5는 이제 컨텍스트 인식을 갖추고 있습니다 — API가 시스템 프롬프트에 실행 중인 예산을 주입하므로 모델이 스스로 페이스를 조절할 수 있습니다:

<budget:token_budget>1000000</budget:token_budget>

각 도구 호출 후, API는 이를 업데이트합니다:

<system_warning>Token usage: 350000/1000000; 650000 remaining</system_warning>

이러한 태그를 여러분이 보내는 것이 아닙니다 — API가 보냅니다. 실용적 효과: 긴 에이전트 실행에서 Sonnet 5는 벽에 부딪히기 전에 사전에 요약하거나 넘겨주며, 추측하지 않습니다. Opus 4.7+, Fable 5, Mythos 5는 태그가 주입되지 않습니다; 대신 task budgets (beta)를 통해 명시적 예산을 부여하세요.

흔한 실수​

  • 지시사항 뒤에 문서 붙여넣기 — 가장 흔한 실수 하나. 요청 위로 옮기세요.
  • <source> 메타데이터 없음 — Claude는 report.pdf 대신 "그 문서"를 인용합니다; 다운스트림 도구는 검증할 수 없습니다.
  • 하나의 거대한 <document> 덩어리 — 여러 소스를 하나로 축소하면 Claude가 구분할 수 없습니다; 파일당 하나씩 사용하세요.
  • 긴 입력에 대해 직접 답을 요청하기 — ~20k 입력 토큰을 초과하는 것에 대해서는 항상 먼저 인용문을 요청하세요.
  • 캐싱이 자동이라고 가정 — 그렇지 않습니다. 캐시 중단점과 TTL은 프롬프트 캐싱을 참조하세요.
  • 압축이 존재한다는 것을 잊음 — Claude 4.6+의 매우 긴 에이전트 실행의 경우, 서버 측 압축이 오래된 턴을 자동으로 요약합니다.

지금 시도하기​

일반적으로 원시로 붙여넣을 20k+ 토큰 문서를 가져오세요. 위의 템플릿으로 감싸고, 요청을 맨 아래에 두고, 첫 번째 지시사항으로 "관련 인용문을 먼저 추출하라"를 추가하세요. 답변을 이전 프롬프트와 비교해 보세요 — 차이는 대개 미묘하지 않습니다.

Check yourself

0/5
  1. 긴 컨텍스트 프롬프트에서 긴 문서는 어디에 배치해야 합니까?
  2. 인용문 추출 기법이란 무엇입니까?
  3. 900k 토큰 코드베이스가 있고 하루 500개의 유사한 쿼리를 예상합니다. 원시 1M 붙여넣기를 이기는 것은 무엇입니까?
  4. '컨텍스트 부패'란 무엇입니까?
  5. Sonnet 5에서 <budget:token_budget> 태그를 누가 주입합니까?
Key takeaways
  • 긴 형식 데이터는 맨 위에; 요청은 맨 아래에 — 복잡한 입력에서 최대 ~30% 더 나음.
  • 모든 문서를 <source> 메타데이터가 있는 <document>로 감싸세요; 답변 전에 <quotes>를 요청하세요.
  • 1M 컨텍스트 ≠ 무료 — 컨텍스트 부패는 실재하며, 200k 입력 토큰을 초과하면 긴 컨텍스트 요금이 시작됩니다.
  • 동일한 코퍼스가 많은 쿼리를 처리할 때는 RAG를 사용하세요; 긴 컨텍스트를 경제적으로 만들려면 압축과 프롬프트 캐싱을 사용하세요.

다음​