컨텍스트 윈도우
컨텍스트 윈도우(context window)는 AI 모델이 한 번에 참고할 수 있는 글의 양이다. 지금 하는 대화에서 모델이 볼 수 있는 범위 전체를 가리키며, 모델이 만들어 낼 답까지 여기에 포함된다.
모델이 학습한 지식과는 다른 것이다. 학습 지식이 "알고 있는 것"이라면, 컨텍스트 윈도우는 "지금 눈앞에 펼쳐 놓은 것"에 가깝다.
왜 이것이 문제가 되나
AI 도구를 쓰다가 겪는 흔한 상황들이 대부분 여기서 나온다.
- 긴 문서를 넣었더니 앞부분 내용을 모르는 것처럼 답한다
- 대화를 오래 이어 갔더니 처음에 한 말을 잊어버린다
- 코드를 여러 개 넣었더니 일부만 보고 답한다
- API를 부르니 "prompt is too long" 오류가 난다
모델이 멍청해진 것이 아니라 자리가 모자란 것이다. 이 구분을 못 하면 "이 모델은 별로다"라는 잘못된 결론에 도달한다.
비유로 이해하기
책상 위에 펼쳐 놓을 수 있는 서류의 양이라고 생각하면 가깝다.
책상이 크면 여러 서류를 동시에 펼쳐 놓고 앞뒤를 오가며 볼 수 있다. 책상이 좁으면 새 서류를 놓기 위해 이미 놓인 것을 치워야 한다. 치운 서류의 내용은 더 이상 볼 수 없다.
중요한 것은 이 책상이 매 요청마다 새로 차려진다는 점이다. 모델은 지난 대화를 "기억"하는 것이 아니라, 매번 지금까지의 대화 전부를 다시 받아서 읽는다. 대화가 길어질수록 매 요청에서 읽어야 할 양이 늘어나는 이유가 여기에 있다.
무엇이 컨텍스트를 차지하나
답을 만드는 데 관여하는 모든 것이 들어간다. 사용자가 방금 친 질문만이 아니다.
| 항목 | 설명 |
|---|---|
| 시스템 프롬프트 | 도구가 미리 심어 둔 지시 |
| 대화 기록 전체 | 이전 질문과 답변 전부 |
| 첨부한 파일·문서 | 넣은 만큼 그대로 |
| 이미지 | 이미지도 토큰으로 환산된다 |
| 도구 정의 | 도구 이름·설명·스키마 |
| 도구 실행 결과 | 검색 결과, 파일 내용 등 |
| 모델의 사고 과정 | 답하기 전 내부적으로 생각한 것 |
| 모델의 답변 | 만들어 낸 답도 포함 |
마지막 두 줄을 놓치기 쉽다. Anthropic 공식 문서는 모델이 생성한 답과 사고(thinking) 토큰도 컨텍스트에 들어간다고 명시한다.[1]
즉 "입력 100만 토큰을 넣을 수 있다"가 아니다. 입력과 출력을 합쳐 100만이다.
토큰이란
컨텍스트는 글자 수가 아니라 토큰 단위로 잰다. 토큰은 모델이 글을 자르는 단위로, 단어보다 작고 글자보다 큰 경우가 많다.
OpenAI는 대략적인 기준으로 영어 기준 1토큰 ≈ 4글자 ≈ 0.75단어를 제시한다. 정확한 값은 내용과 언어에 따라 달라진다.
한국어는 더 많이 든다
위의 "4글자당 1토큰"은 영어 기준이고, 한국어에는 그대로 적용되지 않는다.
같은 내용을 담아도 한국어가 영어보다 토큰을 더 많이 쓴다. 토크나이저가 대체로 영어에 맞춰 만들어졌기 때문이다.
한국어의 토큰 배수는 확정된 숫자가 없다.
측정한 사람과 토크나이저에 따라 결과가 크게 갈린다. 공식적으로 발표된 값이 아니므로 이 위키에서는 특정 배수를 적지 않는다.
실무에서 필요한 결론은 하나다 — 영어 기준으로 계산한 비용과 분량이 한국어에서는 더 나온다. 여유를 두고 잡아야 한다.
정확히 알아야 한다면 각 제공사의 토큰 계산 API로 실제 텍스트를 재 보는 것이 맞다.
토크나이저가 바뀌면 값도 바뀐다
같은 글이라도 모델 세대에 따라 토큰 수가 달라진다.
Anthropic은 Claude Opus 4.7 세대부터 새 토크나이저를 쓰며, 같은 텍스트가 이전 대비 약 30% 더 많은 토큰이 된다고 공식 문서에서 밝히고 있다.
컨텍스트가 커졌다고 같은 분량이 더 들어가는 것이 아니라는 뜻이고, 기존에 세워 둔 비용 계산도 다시 해야 한다는 뜻이다.
왜 한계가 있나
창을 무한정 키우지 못하는 이유가 있다.
모델이 답을 만들 때는 들어온 토큰 하나하나가 다른 모든 토큰과 어떤 관계인지를 따진다. 그래서 토큰이 2배로 늘면 따져야 할 관계는 2배가 아니라 4배로 늘어난다.
여기에 그 계산 결과를 담아 둘 메모리도 필요하다. 컨텍스트를 늘리면 계산량과 메모리가 함께 불어난다는 뜻이고, 이것이 창 크기가 곧 비용과 속도로 이어지는 이유다.
컨텍스트 부패도 이와 무관하지 않다. 봐야 할 것이 많아질수록 어디에 주의를 둘지가 흐려진다.
사고 토큰과 컨텍스트
최근 모델은 답하기 전에 내부적으로 생각하는 과정을 거친다. 이 사고 과정도 토큰이고, 컨텍스트를 차지하며 과금된다.
| 항목 | 처리 |
|---|---|
| 과금 | 출력 토큰으로 계산 |
| 컨텍스트 | 차지한다 |
| 최대 출력 한도 | max_tokens 안에 포함된다
|
세 번째가 실무에서 걸린다. 최대 출력을 12.8만으로 잡아도 그중 상당 부분을 사고가 써 버리면 실제 답변에 쓸 자리가 줄어든다.
이전 턴의 사고는 남나
모델에 따라 다르다.
Claude의 경우 Opus 4.5 이후 Opus 계열, Sonnet 4.6 이후 Sonnet 계열, Fable 5는 이전 사고 블록을 그대로 유지한다. 유지되는 만큼 다음 요청에서 입력 토큰으로 다시 과금된다.
그 이전 세대와 모든 Haiku 계열은 자동으로 걷어낸다. 대화 내용에 쓸 자리를 남기기 위해서다.
적응형 사고를 쓰면 사고량이 요청마다 달라진다. 모델이 알아서 얼마나 생각할지 정하기 때문에, 사고 토큰 사용량을 미리 예측하기 어렵다.
도구를 붙이면 컨텍스트가 준다
도구 정의 자체가 매 요청 입력 토큰으로 들어간다. 도구를 하나라도 넘기면 시스템 프롬프트가 자동으로 추가되기 때문이다.
Claude 기준 도구 사용 시스템 프롬프트만으로 이 정도가 든다.
| 모델 | 토큰 |
|---|---|
| Claude Opus 5 | 286~406 |
| Claude Sonnet 5 | 354~474 |
| Claude Haiku 4.5 | 496~588 |
| Claude Opus 4.7 | 675~804 |
여기에 도구 이름·설명·스키마, 호출 블록, 실행 결과가 더해진다.
실행 결과가 가장 크다. 웹 검색 결과나 파일 내용이 통째로 들어오기 때문에, 도구를 몇 번만 불러도 컨텍스트가 크게 잠식된다. 앞서 말한 도구 결과 비우기가 필요한 이유가 여기에 있다.
모델별 크기
2026년 8월 기준이다.
| 모델 | 컨텍스트 | 최대 출력 |
|---|---|---|
| GPT-5.6 Sol · Terra · Luna | 105만 | 12.8만 |
| Claude Fable 5 · Opus 5 · Sonnet 5 | 100만 | 12.8만 |
| Claude Sonnet 4.6 · Opus 4.6~4.8 | 100만 | 12.8만 |
| Claude Haiku 4.5 | 20만 | 6.4만 |
| Claude Sonnet 4.5 | 20만 | — |
불과 몇 세대 만에 다섯 배로 늘었다. Claude는 4.5 세대에서 20만이던 것이 4.6 세대에서 100만이 됐다.
GPT-5.6은 총 105만 중 최대 입력이 92.2만 토큰이다. 나머지는 출력과 내부 처리 몫이라, 총량과 넣을 수 있는 양은 다르다.
이미지나 PDF에는 별도의 제한이 걸리기도 한다. Claude의 경우 100만 토큰 모델은 한 요청에 이미지·PDF 페이지 600장, 20만 토큰 모델은 100장이 상한이다.
다 차면 어떻게 되나
도구마다 다르게 처리한다. 이것이 혼란의 큰 원인이다.
| 상황 | 동작 |
|---|---|
| API — 입력만으로 이미 초과 | 400 오류. "prompt is too long"
|
| API — 입력 + 최대 출력이 초과 | 요청은 받되, 생성 중 한도에 닿으면 중단 |
| 채팅 서비스 | 오래된 대화부터 조용히 밀어낸다 |
세 번째가 가장 위험하다. claude.ai 같은 채팅 화면은 컨텍스트를 선입선출로 관리한다. 즉 오래된 내용이 소리 없이 사라진다. 오류가 뜨지 않으니 사용자는 모델이 잊어버린 줄 모르고, "왜 아까 말한 걸 무시하지?"라고 느끼게 된다.
크다고 좋은 것은 아니다
컨텍스트 윈도우에 대한 가장 큰 오해가 여기 있다.
Anthropic 공식 문서는 이렇게 쓰고 있다 — "더 많은 컨텍스트가 자동으로 더 나은 것은 아니다. 토큰 수가 늘어날수록 정확도와 회상 능력이 떨어지며, 이를 컨텍스트 부패(context rot)라 부른다."
즉 100만 토큰을 꽉 채워 넣으면 오히려 답이 나빠질 수 있다.
컨텍스트를 다루는 원칙
- 얼마나 넣을 수 있느냐보다 무엇을 넣느냐가 중요하다
- 관련 없는 자료는 빼는 편이 낫다. 넣으면 비용도 늘고 정확도도 떨어진다
- 창이 커졌다고 다 채우는 것은 최적화가 아니라 낭비다
넣을 자료를 고르는 일이 곧 성능 관리가 됐다는 뜻이다.
컨텍스트를 관리하는 방법
압축
대화가 길어지면 앞부분을 요약해 자리를 비우는 방식이다. Anthropic은 이를 서버에서 자동으로 처리하는 compaction을 제공한다 (Claude 4.6 이후 모델, 베타).
요약이므로 세부 내용은 사라진다. 오래 도는 작업에서는 중요한 정보를 따로 파일이나 메모로 남겨 두는 편이 안전하다.
압축 덕분에 컨텍스트 한도를 넘겨서도 대화를 이어 갈 수 있다. 다만 이어지는 것은 요약본 위에서이지, 원문이 그대로 남는 것은 아니다.
컨텍스트 편집
통째로 요약하지 않고 특정 부분만 골라 비우는 방식이다.
- 도구 결과 비우기 — 오래된 검색·파일 읽기 결과를 지운다
- 사고 블록 비우기 — 이전 턴의 생각 과정을 지운다
에이전트처럼 도구를 많이 부르는 작업에서 효과가 크다. 도구 실행 결과가 컨텍스트를 가장 빨리 잡아먹는 항목이기 때문이다.
컨텍스트 인식
일부 모델은 자기가 얼마나 남았는지를 안다.
Claude Sonnet 5, Sonnet 4.6, Sonnet 4.5, Haiku 4.5는 매 요청의 시스템 프롬프트에서 전체 예산을 받고, 도구를 부를 때마다 남은 양을 통보받는다.
Token usage: 35000/200000; 165000 remaining
덕분에 남은 자리에 맞춰 작업을 조절할 수 있다. 자동으로 동작하며 사용자가 켤 것은 없다.
모든 모델이 받는 것은 아니다. Claude Opus 4.7 이후 Opus 계열과 Fable 5는 이 태그를 받지 않는다. 대신 작업 단위로 예산을 직접 지정하는 별도 기능이 베타로 제공된다.
프롬프트 캐싱은 해결책이 아니다
캐싱은 돈을 아끼는 것이지 자리를 아끼는 것이 아니다.
프롬프트 캐싱을 쓰면 반복되는 앞부분이 정가의 10%로 계산된다. 비용은 크게 줄지만, Anthropic 문서가 명시하듯 캐시된 부분도 컨텍스트 윈도우를 그대로 차지한다.
"캐싱을 켰으니 더 넣어도 된다"는 잘못된 판단이다. 무엇에 얼마를 내느냐가 바뀔 뿐, 들어가느냐 마느냐는 그대로다.
감을 잡는 기준
토큰이라는 단위가 와닿지 않는 것이 문제이므로, 공식 문서에 나온 예시로 기준을 세워 둔다.
| 자료 | 대략 토큰 |
|---|---|
| 일반 웹페이지 (10 kB) | 약 2,500 |
| 문서 페이지 (100 kB) | 약 25,000 |
| 논문 PDF (500 kB) | 약 125,000 |
이 기준으로 보면 이렇게 읽힌다.
- 20만 토큰 창 — 논문 한 편 남짓. 두 편이면 거의 찬다
- 100만 토큰 창 — 논문 여덟 편 안팎
생각보다 여유가 없다. 100만이라는 숫자가 크게 들리지만 PDF 몇 개와 대화 기록이 쌓이면 금방 채워진다.
여기에 한국어는 영어보다 토큰을 더 쓴다는 점까지 감안하면 실제 여유는 위 계산보다 줄어든다고 보는 편이 안전하다.
도구에서 만나는 컨텍스트
로컬 실행 도구의 함정
모델이 지원하는 크기와 도구가 실제로 쓰는 크기는 다르다.
Ollama의 기본 컨텍스트는 4,096 토큰이다. 100만 토큰을 지원하는 모델을 돌려도 설정을 바꾸지 않으면 4,096만 쓴다. 오류 없이 조용히 잘리기 때문에 알아채기 어렵다.
로컬 모델이 "생각보다 못한다"는 인상의 상당 부분이 여기서 온다.
OLLAMA_CONTEXT_LENGTH 나 num_ctx 로 늘리되,
늘린 만큼 메모리를 더 먹는다는 점은 감안해야 한다.
코딩 도구
Cursor나 Claude Code 같은 도구는 무엇을 컨텍스트에 넣을지 스스로 고른다. 파일 전체를 넣기도 하고 일부만 넣기도 한다.
범위를 좁혀 요청하는 편이 대개 결과가 낫다. "이 프로젝트 전체를 고쳐 줘"보다 "이 파일의 이 함수를 고쳐 줘"가 정확도와 비용 양쪽에서 유리하다. 컨텍스트 부패를 피하는 실전 방법이기도 하다.
작업이 길어지면 도구가 대화를 자동으로 압축하기도 한다. 이때 세부 내용이 요약으로 바뀌므로, 압축 전에 결정 사항을 파일로 남겨 두면 이어지는 작업에서 같은 설명을 반복하지 않아도 된다.
컨텍스트를 아끼는 실전 방법
효과가 큰 것부터 정리한다.
① 넣을 것을 고른다
가장 효과가 크고, 가장 자주 건너뛰는 단계다.
- 관련 없는 파일은 넣지 않는다
- 문서 전체 대신 필요한 절만 넣는다
- 검색 결과를 통째로 넘기지 않고 요약해서 넘긴다
"혹시 필요할까 봐" 넣는 자료가 컨텍스트 부패의 주범이다. 비용도 늘고 정확도도 떨어지는 양쪽 손해다.
② 대화를 나눈다
주제가 바뀌면 새 대화를 시작하는 편이 낫다. 이어 가면 앞의 내용이 계속 따라다니며 매 요청 비용을 올린다.
작업 단위로 끊는 습관이 긴 대화를 관리하는 것보다 단순하고 확실하다.
③ 중요한 것은 밖에 적어 둔다
압축이든 선입선출이든 오래된 내용은 결국 사라진다.
여러 세션에 걸치는 작업이라면 결정 사항과 규칙을 파일이나 메모로 남겨 두고 필요할 때 다시 넣는 구조가 안전하다. Claude Code의 규칙 파일 같은 것이 그 역할을 한다.
④ 도구 결과를 정리한다
에이전트 작업에서는 도구 실행 결과가 컨텍스트를 가장 빨리 먹는다. 쓰고 난 결과를 비우는 설정이 있으면 켠다.
⑤ 캐싱은 비용용으로만 쓴다
반복되는 앞부분이 있으면 캐싱으로 비용을 크게 줄인다. 다만 자리는 그대로 차지한다는 것을 기억한다.
세대별로 어떻게 늘었나
컨텍스트는 최근 몇 년간 가장 빠르게 커진 수치다. Claude 계열만 봐도 한 세대 만에 다섯 배가 됐다.
| 세대 | 컨텍스트 | 변화 |
|---|---|---|
| Claude 4.5 | 20만 | |
| Claude 4.6 | 100만 | 5배 |
| Claude 4.7 | 100만 | 토크나이저 교체 (같은 글이 약 30% 더 많은 토큰) |
| Claude 5 | 100만 |
4.6에서 크기가 늘고, 4.7에서 세는 방식이 바뀌었다. 두 변화가 연달아 오면서 체감 용량은 발표된 배수만큼 늘지 않았다.
이 조합이 실무에서 혼란을 만든다. "5배 늘었다"는 발표만 보고 계산을 세워 두면 실제로는 그만큼 안 들어간다. 창의 크기와 세는 방식을 함께 봐야 한다.
어떤 상황에서 무엇이 문제인가
| 증상 | 원인 | 대처 |
|---|---|---|
| 앞부분을 잊는다 | 컨텍스트 초과로 밀려남 | 새 대화 시작, 중요 내용 재입력 |
| 문서 뒷부분만 안다 | 앞부분이 잘림 | 나눠 넣기, 창이 큰 모델로 |
| 답이 점점 흐려진다 | 컨텍스트 부패 | 관련 없는 자료 제거 |
| "prompt is too long" | 입력만으로 한도 초과 | 자료 줄이기 |
| 답이 중간에 끊긴다 | 최대 출력 도달 | 출력 한도 확인, 나눠 요청 |
| 로컬 모델이 이상하다 | 도구 기본값이 작음 | num_ctx 확인
|
| 비용이 예상보다 크다 | 대화 누적 + 사고 토큰 | 대화 나누기, 캐싱 |
세 번째 줄이 가장 알아채기 어렵다. 오류도 없고 잘림도 없는데 답의 질만 서서히 떨어지기 때문이다.
흔한 오해
"컨텍스트가 크면 기억력이 좋은 것이다"
아니다. 컨텍스트는 기억이 아니라 매 요청 다시 읽는 자료다. 대화창을 새로 열면 아무것도 남지 않는다.
"100만 토큰이면 100만 토큰을 넣을 수 있다"
아니다. 답변과 사고 과정까지 포함한 총량이다. GPT-5.6은 105만 중 최대 입력이 92.2만이다.
"많이 넣을수록 정확해진다"
반대인 경우가 많다. 공식 문서가 컨텍스트 부패를 명시한다. 관련 없는 자료는 빼는 편이 낫다.
"캐싱하면 컨텍스트를 아낀다"
아니다. 비용만 준다. 자리는 그대로 차지한다.
"모델이 나를 기억한다"
아니다. 대화창을 새로 열면 백지에서 시작한다. 별도의 메모리 기능이 있는 서비스는 그 기능이 내용을 저장했다가 다시 넣어 주는 것이다.
"긴 컨텍스트는 비싸다"
제공사에 따라 다르다. Anthropic은 100만 토큰 전 구간을 같은 단가로 청구한다. 공식 문서가 "90만 토큰 요청도 9천 토큰 요청과 같은 토큰당 단가"라고 명시한다.
자주 묻는 것
대화가 길어지면 왜 앞부분을 잊나?
컨텍스트가 가득 차 오래된 내용이 밀려났기 때문이다. 중요한 내용은 새 대화를 시작하며 다시 넣어 주는 편이 확실하다.
내 문서가 컨텍스트에 들어가는지 어떻게 아나?
API를 쓴다면 토큰 계산 API로 보내기 전에 재 볼 수 있다. 응답의 사용량 필드에도 실제로 쓴 토큰이 나온다.
PDF 하나가 얼마나 차지하나?
크기에 비례한다. OpenAI 문서의 예시로는 일반 웹페이지(10 kB)가 약 2,500토큰, 문서 페이지(100 kB)가 약 25,000토큰, 논문 PDF(500 kB)가 약 125,000토큰이다. 논문 몇 편이면 20만 토큰 창은 금방 찬다.
사고 과정도 컨텍스트를 먹나?
먹는다. 출력 토큰으로 과금되고 컨텍스트에도 들어간다. 모델에 따라 이전 턴의 사고 블록을 자동으로 걷어내기도 한다.
컨텍스트를 늘리면 느려지나?
넣는 양이 늘면 처리할 것이 늘어난다. 비용과 지연 양쪽이 함께 올라간다고 보는 편이 맞다.
어느 정도가 적당한가?
작업에 필요한 만큼만이다. 창의 크기가 아니라 지금 답하는 데 실제로 쓰이는 자료인가를 기준으로 판단한다.
컨텍스트가 큰 모델로 바꾸면 해결되나?
부분적으로만 그렇다. 잘림 문제는 해결되지만 컨텍스트 부패는 오히려 커질 수 있다. 넣을 것을 고르는 일은 그대로 남는다.
창이 큰 모델이 항상 더 비싼가?
제공사에 따라 다르다. Anthropic은 100만 토큰 전 구간을 같은 단가로 매기므로 창이 크다는 것 자체로 더 비싸지지는 않는다. 다만 많이 넣으면 넣은 만큼 입력 토큰으로 과금되므로 실제 지출은 늘어난다.
이미지도 토큰을 먹나?
먹는다. 이미지도 토큰으로 환산되어 컨텍스트에 들어가고 예산에 계산된다. Claude 기준으로 한 요청에 넣을 수 있는 이미지·PDF 페이지 수에도 별도 상한이 있다.
여담
컨텍스트 경쟁은 몇 년 사이 가장 빠르게 움직인 수치다. 초기 모델이 수천 토큰이던 것이 20만이 되고, 다시 100만이 됐다. 숫자가 마케팅 포인트가 되면서 발표마다 강조되는 항목이 되기도 했다.
그런데 정작 공식 문서는 "크다고 좋은 것이 아니다"라고 적어 두었다. Anthropic은 컨텍스트 부패를 문서에 명시하며 "컨텍스트에 무엇을 넣을지 고르는 일이 공간이 얼마나 남았는지만큼 중요하다"고 쓴다. 파는 쪽이 직접 브레이크를 건 셈이라 눈에 띈다.
"컨텍스트 엔지니어링"이라는 말이 생긴 것도 이 무렵이다. 프롬프트를 잘 쓰는 것(프롬프트 엔지니어링)에서 한 걸음 나아가, 무엇을 넣고 무엇을 뺄지 설계하는 일이 별도의 기술로 다뤄지기 시작했다. 창이 좁을 때는 "다 못 넣는다"가 문제였는데, 창이 커지자 "다 넣으면 안 된다"가 문제가 된 것이다.
