Context Length Exceeded: 요청을 줄이고 결과를 검증하는 방법
컨텍스트의 각 구성 요소를 측정하고 중복 및 불필요한 이력을 제거하며 출력 여유를 남겨 필수 정보가 보존되었는지 확인합니다.
목차
Context Length Exceeded: 요청을 줄이고 결과를 검증하는 방법
Context length exceeded는 프롬프트의 절반을 무작정 지워서 해결하면 안 됩니다. 먼저 전체 예산을 계산하고 모델을 확인한 다음, 요청을 구성하는 각 요소를 측정하세요. 그 뒤 기계적인 중복, 관련 없는 이력, 용량이 큰 도구 결과를 제거합니다. 다시 보낸 후에는 오류가 사라졌는지뿐 아니라 필수 사실과 완전한 답변이 유지되었는지도 확인해야 합니다.
컨텍스트 윈도우를 채우는 요소
컨텍스트는 마지막 사용자 프롬프트만이 아니라 한 요청 전체의 작업 메모리입니다. 단순화하면 다음과 같습니다.
system instructions
+ conversation history
+ current message
+ images and documents
+ tool definitions
+ tool results
+ output / thinking budget
= total context usageAnthropic의 컨텍스트 윈도우 문서는 시스템 프롬프트, 모든 메시지, 이미지, 문서, 도구 정의, 도구 결과, 생성되는 답변을 명시적으로 포함합니다. 프롬프트 캐싱은 재사용 토큰의 비용을 바꾸지만, 그 토큰을 윈도우에서 제거하지는 않습니다.
코드에 “보편적인 한도”를 고정하지 마세요. 컨텍스트 윈도우와 초과 시 동작은 선택한 모델과 API에 따라 달라집니다. 설정하는 날 현재 모델 카드를 확인해야 합니다.
가장 무거운 구성 요소 찾기
| 구성 요소 | 측정할 항목 | 안전한 축소 방법 |
|---|---|---|
| 시스템 지침 | 반복 규칙과 긴 예시 | 중복을 합치고 필수 제약은 남기기 |
| 이력 | 메시지별 토큰과 오래된 분기 | 관련 없는 분기를 제거하거나 검증 가능한 요약으로 바꾸기 |
| 파일과 RAG 조각 | 문서별 크기, 중복, 관련성 낮은 조각 | top_k를 낮추고 중복 제거 후 필요한 절만 전달하기 |
| 도구 정의 | 사용하지 않는 도구와 긴 설명 | 현재 단계에 필요한 도구만 전달하기 |
| 도구 결과 | 전체 JSON, 로그, HTML, base64, 반복 응답 | 필요한 필드·링크·식별자만 남기고 큰 데이터는 프롬프트 밖에 저장하기 |
| 출력 예산 | max_tokens와 사고 예산 | 현실적인 여유를 남기거나 큰 결과를 단계로 나누기 |
Claude에는 요청을 보내기 전에 메시지와 도구를 계산하는 Token Counting API가 있습니다. 다른 제공자라면 제공되는 자체 카운터를 사용하세요. 로컬 tokenizer는 조기 경고에는 유용하지만, 다른 모델의 서버 측 계산을 보장하지는 않습니다.
BetterToken 최신 API 문서를 열고 짧은 test request를 실행한 뒤 Dashboard에서 찾으세요. context를 줄이기 전후의 input, output, cache tokens를 비교하고 input tokens 감소로 수정이 실제 call에 반영됐는지 확인합니다. Dashboard는 전체 prompt를 표시하지 않으며 전송 전 token counting을 대체하지 않습니다.
의미를 잃지 않고 크기 줄이기
1. 기계적인 중복 제거
반복된 시스템 규칙, 여러 메시지에 들어간 같은 파일, 중복 RAG 조각, 여러 번 삽입한 스키마, 반복해서 붙인 전체 로그를 찾으세요. 작업 자체는 바꾸지 않고 분량만 줄이므로 가장 안전한 단계입니다.
2. 관련 없는 이력 제거
장기적으로 필요한 사실과 대화의 임시 흐름을 분리합니다. 목표, 확정된 결정, 필수 제약, 열린 질문은 보존하세요. 오래된 추론, 기각한 대안, 이미 처리한 도구 결과는 삭제하거나 구조화된 요약으로 압축할 수 있습니다.
나쁜 요약은 “통합을 논의했다”라고만 말합니다. 좋은 요약에는 선택한 endpoint, 스키마 버전, 확정된 제약, 확인된 사실, 다음 단계가 들어갑니다.
3. 파일, RAG, 도구 결과 압축
문서 전체 대신 관련 절만 전달하세요. 도구 결과에는 전체 HTTP 응답이나 로그가 아니라 다음 단계에 필요한 필드만 남깁니다. 요청을 맞추기 위해 출처나 필수 데이터를 버리면 안 됩니다. 작업을 검증 가능한 여러 단계로 나누는 편이 낫습니다.
4. 답변을 위한 공간 남기기
입력과 출력은 같은 예산을 공유합니다. 요청이 윈도우를 거의 채우면 모델은 완전한 답변을 쓸 공간이 부족할 수 있습니다. 선택적 입력을 줄이고, 현실적인 출력 예산을 설정하거나, 결과를 나누세요. 기계적 중복보다 먼저 핵심 사실을 줄이지 마세요.
5. 측정한 뒤에만 모델 변경
안전하게 나눌 수 없는 문서에는 더 큰 컨텍스트 모델이 적합할 수 있습니다. 하지만 중복을 제거하지 않은 채 더 큰 윈도우로 옮기면 다음 오류를 미룰 뿐이고 정보 밀도도 떨어질 수 있습니다.
전송 전 최소 점검
components = count_by_section(request)
estimated_input = sum(components)
reserved_output = requested_output_budget
if estimated_input + reserved_output approaches current_model_window:
remove exact duplicates
drop irrelevant history
compact tool results and retrieved chunks
count again
send only after required facts and constraints remain presentapproaches를 고정 비율로 바꾸지 않은 것은 의도적입니다. 필요한 여유는 카운터 정확도, 모델, 사고 과정, 해당 API의 동작에 따라 달라집니다.
수정 결과 검증 방법
새 요청을 다음 체크리스트와 비교하세요.
- API가 더 이상
context length exceeded또는prompt is too long을 반환하지 않는다. - 출력 예산 때문에 잘리지 않고 응답이 정상적으로 완료된다.
- 응답에 모든 필수 사실, 제약, 요청된 형식이 포함되어 있다.
- 인용이나 링크가 전달한 출처와 여전히 일치한다.
- 도구 호출이 올바른 인수를 사용하고 압축 과정에서 중요한 결과가 사라지지 않았다.
- 새 입력 사용량이 원래보다 실제로 낮다.
오류가 사라졌지만 모델이 핵심 제약을 잊었다면 수정은 실패입니다. 필수 블록을 복원하고, 관련성이 낮은 이력이나 큰 도구 결과를 제거해 공간을 만드세요. 답변이 잘리면 출력 예산을 별도로 점검해야 합니다. 이것도 같은 전체 윈도우의 일부입니다.
요약
실무 순서는 모델 식별 → 구성 요소 계산 → 정확한 중복 제거 → 관련 없는 이력 추출 → 파일과 도구 결과 압축 → 답변 공간 확보 → 재전송 → 품질 검증입니다. 이 순서는 컨텍스트를 임의로 잘린 사실 묶음으로 만들지 않고 원인을 해결합니다.
