컨텍스트 윈도우 이해하기: 토큰 한도와 긴 입력을 다루는 법

컨텍스트 윈도우(context window)는 대규모 언어 모델(LLM)이 요청 하나를 처리할 때 사용할 수 있는 전체 토큰 공간입니다. 모델이 읽는 입력과 생성하는 출력이 모두 이 안에 들어갑니다. 윈도우가 1M 토큰이라면 지시문, 문서, 대화 기록뿐 아니라 응답도 같은 공간을 나눠 써야 합니다. 추론을 수행하는 모델에서는 그 과정도 포함됩니다. 공간을 가득 채울 수 있다는 것과 모델이 그 안의 모든 세부 정보를 정확하게 활용한다는 것은 별개입니다.

AI의 컨텍스트 윈도우란 무엇인가요?

컨텍스트 윈도우를 작업대에 비유해 보겠습니다. 작업대 위에는 문서와 지시사항, 아직 끝내지 못한 작업이 놓여 있습니다. 작업대가 넓으면 자료를 더 많이 펼칠 수 있지만, 실제로 작업할 자리도 남겨 두어야 합니다. 문서를 전부 펼쳐 놓았다고 해서 필요한 조항이 저절로 눈에 들어오는 것도 아닙니다.

토큰은 모델이 처리하는 단위입니다. 단어 하나보다는 단어의 일부에 해당하는 경우가 많습니다. 텍스트, 코드 등 각종 입력은 모델별 규칙에 따라 토큰으로 변환됩니다. 페이지 수나 파일 크기로 수용량을 짐작하지 말고 실제 요청의 토큰 수를 계산해야 합니다. Google의 토큰 가이드에서 이 차이를 설명합니다.

입력에는 채팅창에 직접 입력하지 않은 내용도 포함될 수 있습니다.

• 어시스턴트의 동작을 정하는 시스템 지시문
• 현재 메시지와 유지된 대화 기록
• 모델이 수행할 수 있는 작업을 설명하는 툴 정의
• 툴 실행 결과, 검색한 문서 구절, 이미지, 문서

Anthropic은 컨텍스트 계산 방식에 이러한 구성 요소가 포함된다고 명시합니다. 사용자가 짧게 질문했더라도 실제 요청은 매우 클 수 있습니다.

컨텍스트 윈도우와 토큰 한도는 어떻게 다른가요?

컨텍스트 윈도우는 요청 전체의 크기를 제한하고, 출력 한도는 그중 모델이 생성하는 부분의 상한을 정합니다. 추론 모델은 사용자에게 보이는 답변을 내놓기 전에 생성 토큰 예산의 일부를 추론에 사용할 수 있습니다. OpenAI도 입력, 출력, 추론이 같은 윈도우를 사용한다고 설명합니다.

입력과 출력이 윈도우를 공유한다면 다음 원칙으로 예산을 잡습니다.

입력 토큰 + 생성용으로 확보한 토큰이 컨텍스트 윈도우 안에 들어가야 합니다.

모델이 추론 토큰을 생성 예산에 포함한다면 그만큼도 확보해야 합니다. 별도로 정해진 최대 출력 한도도 지켜야 합니다. 출력 한도를 크게 설정한다고 공간이 늘어나지는 않습니다.

AI 툴의 컨텍스트 윈도우로 무엇을 알 수 있나요?

해당 요청에서 모델이 얼마나 많은 자료를 한꺼번에 고려할 수 있는지 알 수 있습니다. 다만 모델이 그 자료를 얼마나 정확하게 활용할지, 애플리케이션이 세션 사이에 무엇을 저장할지, 저장한 자료 중 무엇을 다음 요청에 다시 넣을지는 알 수 없습니다.

고객 지원 담당자에게는 실무에서 바로 체감되는 차이입니다. 헬프데스크에 티켓이 저장되어 있어도 어시스턴트의 현재 입력에는 빠져 있을 수 있습니다. 개발자 입장에서도 대화 기록을 저장하는 일과 다음 모델 요청을 구성하는 일은 따로 다뤄야 합니다.

Claude·GPT-6·Gemini 4의 컨텍스트 윈도우 크기

아래 주요 API 모델은 대략 백만 토큰 규모의 윈도우를 제공합니다. 하지만 눈에 띄는 용량 수치만큼 출력 규칙도 중요합니다. 2026년 10월 16일 각 개발사의 공개 모델 페이지를 기준으로 확인했습니다. 각 행은 해당 개발사 페이지로 직접 연결됩니다. 아래 수치는 API 사양이며, 일반 사용자용 채팅 요금제나 개별 애플리케이션에서도 같은 한도를 제공한다는 뜻은 아닙니다.

Claude의 현재 모델 페이지에 따르면 표에 나온 모델의 윈도우 크기와 출력 상한은 모두 같습니다. 따라서 윈도우 크기만으로 모델을 고르기는 어렵습니다. 실제 작업에서 어떤 답을 내놓는지 비교해야 합니다.

GPT-6 Astra, GPT-6.1 Sol, GPT-6 Luna도 표에 표시된 용량이 같습니다. 윈도우가 같아도 정보 추출, 계획 수립, 코딩에서는 서로 다르게 동작할 수 있습니다. 사양은 얼마나 담을 수 있는지를 보여 줄 뿐, 품질 순위를 매겨 주지는 않습니다.

Gemini 4 Argon의 long decode 허용량 역시 입력과 출력이 공유하는 윈도우에 포함됩니다. Google에 따르면 API는 요청한 출력량을 입력을 넣고 남은 공간으로 제한하며, 추론도 그 예산을 사용합니다. 입력으로 윈도우를 가득 채운 뒤 그 위에 큰 출력량을 더 얹을 수는 없습니다. 정확한 규칙은 Gemini 토큰 계산 방식에서 확인할 수 있습니다.

계산 예시: 프롬프트는 들어가는데 응답 공간은 부족하다면

프롬프트가 백만 토큰이라면 실제로 응답에 쓸 수 있는 공간은 모델의 최대 출력 수치보다 작아집니다.

GPT-6 Astra의 공식 한도를 예로 들어 보겠습니다. 지시문, 툴, 대화 기록, 원문 문서를 합친 요청의 입력이 1,000,000 토큰이라고 가정합니다. 실제 작업을 측정한 결과가 아니라 예산 계산을 위한 예시입니다. 여기에 모델이 허용하는 최대치인 생성 토큰 128,000개를 전부 확보하려고 합니다.

계산은 다음과 같습니다.

• 윈도우: 1,050,000 토큰
• 입력을 넣고 남은 공간: 1,050,000 − 1,000,000 = 50,000 토큰
• 계획한 입력과 출력의 합: 1,000,000 + 128,000 = 1,128,000 토큰
• 부족한 공간: 78,000 토큰

입력은 들어갑니다. 하지만 계획한 응답 예산까지는 들어가지 않습니다. 남은 공간 안에서 추론과 사용자에게 보이는 답변을 모두 처리해야 합니다.

출력 허용량 전체를 확보하려면 입력은 최대 922,000 토큰이어야 합니다. 1,050,000 − 128,000으로 계산한 값이며, 워크플로에 필요한 추가 여유 공간은 아직 빼지 않은 상태입니다. 모든 작업에서 최대 출력량을 확보할 필요는 없습니다. 작업에 필요한 출력량에 맞춰 예산을 잡으면 됩니다.

윈도우가 커져도 정보 활용이 정확해지지 않는 이유

요청이 한도 안에 들어가더라도 모델은 그 안의 근거를 놓친 답변을 내놓을 수 있습니다. API가 프롬프트를 받아들였어도 답변 품질에는 문제가 생긴 것입니다.

Anthropic은 컨텍스트 엔지니어링 가이드에서 컨텍스트가 길어질수록 필요한 정보를 찾아 활용하는 능력이 떨어질 수 있다고 설명합니다. 이런 문제는 명백한 응답 거부로 드러나지 않을 수도 있습니다. 어시스턴트가 예외 조항을 놓치거나, 이전 정책과 이를 대체한 새 정책을 섞거나, 관련 있어 보이는 인접 구절을 근거로 답할 수 있습니다.

Nelson F. Liu 등이 발표한 논문 Lost in the Middle에서는 문서 질의응답과 키-값 검색 성능이 관련 정보의 위치에 따라 달라졌습니다. 중간에 놓인 근거는 앞이나 뒤에 놓인 근거보다 활용하기 어려울 수 있었습니다. 이는 과거 연구 결과이며, 위 표의 현행 모델을 평가한 벤치마크는 아닙니다.

긴 컨텍스트에서의 품질은 실제 작업으로 측정해야 합니다. 모든 모델이 어느 순간부터 일제히 신뢰성을 잃는 보편적인 토큰 수는 없습니다.

고객 지원 어시스턴트라면 정답을 이미 알고 있는 정책 예외 사례로 소규모 평가 세트를 만듭니다. 해당 정책만 담은 간결한 요청과 무관한 정책까지 넣은 긴 요청을 비교합니다. 답을 결정하는 구절을 앞부분, 중간, 뒷부분으로 옮겨 봅니다. 답변이 올바른 예외 조항을 적용하고 정확한 출처를 인용하는지 확인합니다.

코딩 어시스턴트라면 구현 파일과 이를 호출하는 코드가 모두 필요한 질문을 던집니다. 관련 자료만 넣었을 때의 답변을 먼저 확인한 뒤 무관한 파일을 추가합니다. 긴 요청에서 결과가 나빠졌다면 용량을 더 확보하는 것만으로는 오류의 원인을 알 수 없습니다.

독특한 문장을 찾아내는 데 성공했다면 검색 능력을 판단할 때 유용한 근거가 됩니다. 하지만 그것만으로 상충하는 문서를 조정하거나 긴 작업 내내 모든 제약조건을 지킬 수 있다고 결론 내릴 수는 없습니다.

컨텍스트 길이 초과 오류가 나면 어떻게 해야 하나요?

개발자는 실제로 구성된 요청을 확인해야 합니다. 운영 담당자는 세션을 이어 가기 전에 현재 작업 상태를 보존해야 합니다. 어느 쪽이든 입력 자체가 거부된 것인지, 답변을 생성하다 공간이 부족해 멈춘 것인지 구분해야 합니다.

Anthropic 문서에 따르면 현재 Claude 모델은 입력만으로 윈도우를 초과하면 프롬프트 길이 초과 오류를 반환합니다. 입력은 들어가지만 생성 중 윈도우 경계에 도달하면 대신 model_context_window_exceeded를 반환하며 응답이 중단될 수 있습니다. 시스템이 예전 메시지를 알아서 버렸다고 가정하지 말고 실제 오류나 중단 사유를 확인해야 합니다. Claude의 컨텍스트 초과 처리 방식을 참고하면 됩니다.

1. 1

   애플리케이션이 보내는 전체 토큰 수를 확인합니다

   지시문, 대화 메시지, 툴 정의, 검색한 구절, 툴 실행 결과를 함께 살펴봅니다. 사용하는 요청 형식을 지원한다면 제공사의 토큰 계산 기능을 활용하고, 그 추정치를 응답에 표시된 사용량과 비교합니다. Anthropic의 토큰 계산 엔드포인트는 구조화된 메시지와 여러 입력 유형을 지원하지만, 서버 툴과 일부 파일 소스에는 제약이 있습니다.

2. 2

   생성에 필요한 공간을 확보합니다

   모델의 윈도우 크기, 출력 상한, 실제로 확보할 출력량을 기록합니다. 해당되는 모델에서는 추론도 포함합니다. 그만큼 입력 예산을 줄여야 합니다. 남은 토큰을 전부 문서를 더 넣을 수 있는 공간으로 계산해서는 안 됩니다.

3. 3

   계속 쌓이는 자료를 찾습니다

   반복되는 검색 결과, 통째로 들어간 로그, 중복 문서, 더 이상 진행하지 않는 대화 갈래를 찾습니다. 코딩 에이전트에는 실패한 테스트와 관련 함수가 필요할 수 있습니다. 하지만 이전에 성공한 모든 명령의 전체 출력을 매 턴마다 넣어야 하는 경우는 드뭅니다. 다음 행동을 검증하는 데 필요한 근거를 남깁니다.

4. 4

   작업을 이어 갈 메모를 남깁니다

   세션을 다시 시작하거나 대화를 압축하기 전에 목표, 확정한 결정, 미해결 문제, 관련 원문 위치, 다음 행동을 보존합니다. 고객 사례를 처리하는 담당자라면 현재 요청과 적용되는 정책의 예외 조항을 남깁니다. 정확한 문구가 중요할 때는 원문을 다시 열어 확인합니다.

5. 5

   변경 후에도 답이 맞는지 확인합니다

   줄인 요청으로 실패했던 작업을 다시 수행합니다. 필요한 근거가 들어 있는지, 답이 맞는지 확인합니다. 프롬프트는 이제 한도 안에 들어가는데도 결정적인 세부 정보를 계속 놓친다면 무작정 더 줄이지 말고 자료 선택과 정보 활용 과정을 살펴봐야 합니다.

짧고 안정적인 워크플로가 이미 정확한 답을 내고 한도를 지키고 있다면 모델을 바꿀 필요는 없습니다. 광고하는 윈도우 크기가 더 크다는 사실만으로는 이전할 이유가 되지 않습니다.

검색·요약·대화 압축·프롬프트 캐싱, 언제 무엇을 써야 하나요?

무엇이 공간을 차지하는지에 따라 대응 방법을 고릅니다. 이 기법들은 서로 다른 문제를 해결하며, 함께 사용할 수도 있습니다.

전체 자료가 질문에 답하는 데 필요한 근거보다 훨씬 많다면 검색을 사용합니다. 검색 증강 생성(RAG)은 모델이 답하기 전에 선택한 원문 자료를 제공합니다. 고객 지원 어시스턴트라면 지식베이스 전체를 읽기보다 해당 반품 정책과 주문 기록을 가져와야 합니다. 에이전틱 RAG 가이드에서는 처음 찾은 근거가 부족할 때 에이전트가 다시 검색하는 방법을 다룹니다.

여기서 관건은 자료 선택입니다. 검색이 결정적인 예외 조항을 놓치면 모델도 이를 활용할 수 없습니다. 작업 전반에 걸쳐 문서의 세부 내용을 비교해야 한다면 문서 수를 제한하되 각 문서는 전문을 컨텍스트에 유지합니다. 문서 범위를 좁히면서 필요한 근거까지 빠지지는 않는지 평가해야 합니다.

지난 대화의 세부 내용을 이후에도 쓸 작업 상태로 정리할 수 있다면 요약을 사용합니다. 요약에는 무엇을 결정했는지, 무엇이 아직 불확실한지, 이를 뒷받침하는 자료가 어디에 있는지를 남겨야 합니다. 코드 수정 작업이라면 선택한 접근법, 현재 발생하는 오류 동작, 관련 파일 경로가 여기에 해당할 수 있습니다. 다음 판단이 문구에 달려 있다면 계약 조항이나 오류 메시지의 정확한 원문을 느슨한 의역으로 바꾸면 안 됩니다.

대화 자체가 공간의 대부분을 차지하게 되었다면 대화 압축(compaction)을 사용합니다. 대화 압축은 누적된 기록을 작업을 이어 가는 데 필요한 더 작은 컨텍스트로 대체합니다. Anthropic은 지나친 압축으로 중요한 세부 정보가 사라질 수 있다고 경고합니다. 따라서 압축한 대화를 무손실 기록 보관소로 여기지 말고 무엇이 남았는지 확인해야 합니다. Anthropic의 대화 압축 설명에서 그 득실을 다룹니다.

에이전트가 작업을 진행하는 동안 컨텍스트에 무엇을 넣고 어떻게 유지할지는 컨텍스트 엔지니어링 가이드에서 더 폭넓게 설명합니다.

유용한 입력이 반복된다면 프롬프트 캐싱을 사용합니다. 프롬프트 캐싱은 요청 앞부분에서 변하지 않고 일치하는 프롬프트 접두부의 처리 결과를 재사용합니다. 고정 지시문과 공통 자료를 변하는 내용보다 앞에 배치하고, 모델별 캐시 규칙을 따라야 합니다. OpenAI의 현재 가이드는 명시적 브레이크포인트 동작을 설명하며, Gemini 4 Argon의 모델 페이지에는 암시적 캐싱만 기재되어 있습니다. OpenAI 캐싱과 Gemini 캐싱 지원 문서를 참고하면 됩니다.

긴 프롬프트는 과금되는 입력 토큰 수를 늘립니다. 캐시가 적중하면 캐시 쓰기 규칙에 따라 반복 입력의 비용을 줄일 수 있지만, 해당 토큰은 여전히 윈도우를 차지합니다. 캐싱의 작동 원리는 별도 글에서 다룹니다.

프롬프트 앞부분을 압축하거나 다시 쓰면 캐시 재사용이 줄어들 수 있습니다. 고정된 접두부가 여전히 유용하다면 유지하고, 무관한 기록이 요청의 품질을 해친다면 제거합니다. 캐시 적중률이 높다고 답변까지 좋다는 보장은 없습니다.

긴 컨텍스트를 둘러싼 과장은 무엇인가요?

용량 수치로 측정할 수 없는 능력까지 입증하려는 경우가 많습니다. 윈도우 크기만으로는 모든 정보를 완벽하게 활용하는 능력, 영구적인 기억, 모든 검색 워크플로를 더 큰 프롬프트로 대체할 수 있는 능력을 증명할 수 없습니다.

더 큰 윈도우가 유용한 상황은 구체적입니다. 관련 근거를 한꺼번에 더 많이 봐야 하는 작업에서, 작은 요청으로는 핵심 관계가 사라지고 큰 요청으로 평가했을 때는 올바른 결과가 나오는 경우입니다. 이런 경우라면 더 큰 용량을 활용할 이유가 있습니다.

로그, 대화 기록, 원문 자료가 답변 공간을 밀어내고 있다면 지금 손봐야 합니다. 먼저 요청에 들어가는 내용을 개선합니다. 그래도 관련 자료가 다 들어가지 않으면 윈도우가 더 큰 모델을 검토합니다. 기존 워크플로가 안정적으로 작동하고 더 큰 사양 수치만이 유일한 동기라면 서둘러 바꾸지 않아도 됩니다.

컨텍스트 윈도우에 관해 자주 묻는 질문

AI 언어 모델의 컨텍스트 윈도우는 무엇인가요?

모델이 요청 하나에서 고려하는 입력과 생성하는 출력을 담을 수 있는 토큰 용량입니다. 추론 모델이라면 개발사의 규칙에 따라 추론에 쓰는 공간도 계산해야 합니다.

200K 컨텍스트 윈도우는 어느 정도 분량인가요?

200K는 200,000 토큰을 뜻합니다. 정해진 단어 수나 페이지 수를 의미하지는 않습니다. 입력과 출력이 윈도우를 공유한다면 생성할 출력도 들어갈 자리가 있어야 합니다. 선택한 모델의 토크나이저나 지원되는 토큰 계산 엔드포인트로 자료의 토큰 수를 확인해야 합니다.

프로그래밍에서 컨텍스트란 무엇인가요?

어떤 연산이 활용할 수 있는 주변 정보를 뜻합니다. LLM 애플리케이션에서는 현재 모델 요청을 위해 모은 지시문, 메시지, 참고 자료를 가리킵니다.

컨텍스트 엔지니어링의 예시는 무엇인가요?

고객 지원 어시스턴트에 현재 티켓, 적용되는 정책, 이전 결정사항을 간추린 기록을 제공하는 경우입니다. 전체 티켓 보관함을 전달하는 대신 필요할 때 추가 근거를 검색합니다.

컨텍스트 엔지니어의 연봉은 얼마인가요?

컨텍스트 윈도우 사양으로 연봉을 알 수는 없습니다. 채용할 때는 업무가 검색, 애플리케이션 개발, 평가, 인프라 중 어디에 해당하는지 정의한 뒤 해당 지역에서 비슷한 범위를 맡는 직무와 비교해야 합니다.

컨텍스트 엔지니어링은 어떻게 배우나요?

작은 애플리케이션이 보내는 전체 요청을 살펴봅니다. 지시문, 검색한 근거, 유지하는 대화 기록을 각각 따로 바꾸고, 정답을 알고 있는 결과와 답변을 비교합니다. 프롬프트가 왜 짧아졌는지만 설명하는 데 그치지 않고, 변경 후 정확성이 왜 높아졌는지 설명할 수 있어야 합니다.

컨텍스트 엔지니어링과 프롬프트 엔지니어링은 어떻게 다른가요?

프롬프트 엔지니어링은 모델에 주는 지시문과 예시에 초점을 맞춥니다. 컨텍스트 엔지니어링은 근거 선택, 툴 제공, 작업이 진행되는 동안 적절한 상태를 유지하는 일까지 다룹니다.

컨텍스트 엔지니어링에서 지켜야 할 원칙은 무엇인가요?

요청 전체의 토큰 예산을 계산하고, 출력 공간을 확보하며, 관련 근거를 남겨야 합니다. 요약할 때는 출처를 다시 찾을 수 있도록 위치도 보존합니다. 내용을 줄이거나 대화를 압축한 뒤에도 답이 맞는지 확인해야 합니다.

컨텍스트 엔지니어링에서 에이전트에 어떤 스킬을 제공하면 좋을까요?

출처 찾기, 관련 구절 확인, 작업 상태 보존에 집중할 수 있는 수단을 제공합니다. 각 툴은 불필요한 자료로 요청을 채우지 않으면서 다음 판단에 도움이 되는 결과를 내는지로 평가해야 합니다.

다음 업무에서 바로 해 볼 일

실패했거나 중요한 세부 정보를 놓친 요청 하나를 고릅니다. 전체 입력 토큰 수를 계산하고, 예상 출력에 필요한 공간을 확보한 뒤 질문에 답하는 데 도움이 되지 않는 가장 큰 덩어리를 찾습니다. 그 부분을 선택한 근거나 작업을 이어 갈 메모로 바꾸고, 정답을 알고 있는 작업을 다시 수행합니다. 근거와 결과가 모두 유지될 때만 줄인 요청을 채택합니다.

안정적인 AI 워크플로를 만드는 실무 가이드를 받아 보려면 뉴스레터를 구독하세요.