한 줄 요약: 컨텍스트 윈도우는 "넣을 수 있는 최대치"일 뿐 "넣어야 할 양"이 아니다. 컨텍스트가 길어질수록 비용은 늘고 정확도는 떨어지므로, 필요한 것만 넣고 자주 비우는 습관이 실력이다.
컨텍스트 윈도우란
모델이 한 번에 처리할 수 있는 최대 토큰 수입니다. 입력(시스템 프롬프트 + 대화 기록 + 파일)과 출력을 합친 양이 이 안에 들어와야 합니다. 2026년 10월 기준 Claude의 최신 모델들은 최대 100만 토큰을 지원합니다. 대략 중간 규모 코드베이스 하나, 또는 두꺼운 소설 여러 권 분량입니다.
그렇다면 레포지토리를 통째로 넣으면 될까요? 대부분의 경우 아닙니다. 이유는 세 가지입니다.
길게 넣으면 생기는 세 가지 문제
1. 비용과 속도. 4편에서 본 것처럼 입력 토큰은 매 턴 다시 과금됩니다. 50만 토큰을 넣고 10턴을 대화하면 캐싱 없이 500만 토큰이고, 첫 응답까지의 대기 시간도 길어집니다.
2. 컨텍스트 열화(context rot). 입력이 길어질수록 모델이 특정 정보를 정확히 찾아 쓰는 능력이 떨어지는 현상입니다. 2편의 어텐션을 떠올리면 이해가 됩니다. 어텐션은 합이 1인 비율을 입력 속 토큰들에 나눠 주는 방식이라, 관련 없는 토큰이 많아질수록 정말 중요한 토큰이 받는 비율은 작아집니다. 특히 긴 문서의 중간에 있는 정보를 놓치기 쉽다는 연구 결과("Lost in the Middle", 2023)가 알려져 있습니다. 이후 모델들은 문장을 그대로 찾아내는 단순한 "바늘 찾기" 시험에서는 크게 나아졌지만, 2025년 Chroma의 Context Rot 보고서에서는 당시 최신 모델 18종을 시험한 결과, 문서에서 특정 정보 찾기나 주어진 단어 그대로 따라 쓰기처럼 쉬운 작업에서도 입력이 길어질수록 정답률이 떨어지고 결과가 들쭉날쭉해졌습니다.
3. 오염된 맥락. 긴 디버깅 대화에는 틀린 가설, 폐기된 코드, 실패한 시도가 쌓입니다. 모델은 이것도 다 맥락으로 읽기 때문에, 이미 버린 접근으로 되돌아가거나 예전 버전 코드를 섞어 쓰기도 합니다. "모델이 갑자기 멍청해진 것 같다"는 느낌의 흔한 원인입니다.
실무 원칙: 컨텍스트 위생
- 작업 하나에 대화 하나. 기능 A를 끝내고 버그 B로 넘어갈 때는 새 대화(Claude Code라면
/clear)로 시작합니다. - 두 번 고쳐도 안 되면 리셋. 같은 문제에 두어 번 실패했다면, 더 따져 묻기보다 지금까지 알아낸 사실만 정리해 새 대화에 넣는 편이 더 빠릅니다.
- 파일 전체보다 관련 부분. 3,000줄 파일에서 문제가 되는 함수와 그것이 호출하는 타입 정의만 주면 충분한 경우가 많습니다.
- 로그는 잘라서. 에러 로그 1만 줄 대신 첫 에러와 스택 트레이스만 넣습니다.
- 중요한 지시는 처음과 끝에. 긴 문서를 넣을 때는 문서를 앞에, 질문과 지시를 맨 뒤에 두는 것이 일반적으로 더 좋습니다.
에이전트 도구들은 컨텍스트가 차면 이전 대화를 요약해 압축(compaction)하는 기능을 갖고 있습니다. 편리하지만 요약 과정에서 세부 사항이 사라지므로, 중요한 결정은 규칙 파일이나 메모 파일에 따로 기록해 두는 편이 안전합니다(7편).
생성 파라미터: 출력을 조절하는 다이얼
API를 직접 호출하면 다음 값들을 조정할 수 있습니다. 채팅 앱과 코딩 도구는 이 값을 대신 정해 두고 있습니다.
| 파라미터 | 하는 일 | 코딩에서의 감각 |
|---|---|---|
max_tokens | 출력 토큰의 상한. 닿으면 답이 중간에 끊김 | 큰 파일을 생성할 때 넓게, 분류 작업은 작게. 응답의 stop_reason이 max_tokens면 잘린 것 |
temperature | 확률 분포를 날카롭게(낮게) 또는 평평하게(높게) | 조정할 수 있는 모델이라면 추출·분류는 낮게, 아이디어·네이밍은 높게. 현행 Claude 모델은 조정 불가(아래) |
top_p | 확률 상위 p%에 드는 후보만 남김 | temperature와 함께 건드리지 말 것. 보통 하나만 조정 |
stop_sequences | 특정 문자열이 나오면 생성 중단 | 특정 태그까지만 받고 싶을 때 |
| effort | 답하기 전 생각에 들일 노력 수준(low~max) | 어려운 디버깅은 높게, 단순 변환은 낮게 |
주의할 점이 있습니다. 2026년 10월 현행 Claude 모델에서는 샘플링 파라미터를 바꿀 수 없습니다. Fable 5.x와 Opus 5.5는 temperature·top_p·top_k를 아예 받지 않고, Sonnet 5.5와 Haiku 5.5는 기본값이 아닌 값을 보내면 400 에러를 냅니다. 출력의 성격은 effort와 프롬프트로 조절합니다. 다른 제공자나 이전 모델에서는 여전히 쓰이는 다이얼이지만, 그때도 temperature 0이 결과를 100% 같게 보장하지는 않습니다. 결정적인 결과가 꼭 필요하다면 파라미터보다 출력 형식을 고정하고(JSON 스키마 등) 검증 로직을 두는 편이 훨씬 확실합니다.
코딩 실습 (30분): 줄 속의 바늘 찾기
컨텍스트 열화를 직접 느껴 봅니다.
- 본인 프로젝트에서 파일 20~30개를 이어 붙여 큰 텍스트를 만든다.
- 그 중간 어딘가의 함수 하나에 미묘한 버그(예:
<=를<로)를 심는다. - "이 코드에서 페이지네이션 버그를 찾아줘"라고 묻는다. 그다음 관련 파일 2개만 넣고 같은 질문을 한다.
- 정답률, 응답 시간,
usage의 토큰 수를 비교해 표로 남긴다.
대부분 "적게 넣은 쪽이 더 빠르고, 더 싸고, 더 정확하다"는 결과가 나옵니다. 그렇다면 무엇을 넣을지는 누가 고를까요? 그것이 6·7편의 주제입니다.
정리
- 컨텍스트 윈도우 = 입력 + 출력의 최대치. 용량이 커도 다 채울 필요는 없다.
- 길수록 비용↑, 속도↓, 정확도↓, 맥락 오염 가능성↑.
- 작업마다 새 대화, 관련 부분만, 중요한 지시는 끝에.
- 생성 파라미터보다 출력 형식 고정과 검증이 더 확실하다.
다음 편: 원리 편을 마무리하고, 활용 편의 첫 주제로 코딩을 위한 프롬프트 작성법을 다룹니다.
출처: Lost in the Middle: How Language Models Use Long Contexts (Liu et al., 2023) · Chroma — Context Rot: How Increasing Input Tokens Impacts LLM Performance (2025)