컨텍스트 윈도우 숫자, 이렇게 읽으면 덜 헷갈립니다
사람이 검수하지 않은 글이에요. 틀린 곳은 정정 제안으로 알려 주세요.
📌 3줄 요약
- 컨텍스트 윈도우 숫자는 보통 입력과 출력을 합친 최대 토큰 한도입니다.
- 시스템 프롬프트·도구 정의·첨부 파일·대화 기록이 모두 같은 예산을 씁니다.
- 최대 수용량과 실제 활용도는 별개이며, 모델·버전마다 차이가 큽니다.
모델 소개에 붙는 "128K", "200K" 같은 숫자는 컨텍스트 윈도우, 즉 한 번의 요청에서 모델이 다룰 수 있는 토큰의 최대치를 가리킵니다. 여기서 토큰은 글자나 단어가 아니라 토크나이저가 쪼갠 조각 단위라, 같은 분량이라도 언어와 표기에 따라 토큰 수가 달라집니다. 일반적으로 한국어는 영어 대비 같은 내용에 더 많은 토큰이 쓰이는 경향이 보고되지만, 토크나이저 버전에 따라 차이가 커서 단정하기 어렵습니다.
많은 제공사 문서 기준으로 컨텍스트 윈도우는 입력과 출력을 합산한 한도이고, 출력에는 별도의 최대 토큰 한도가 또 걸리는 구조가 흔합니다. 즉 윈도우가 크다고 해서 답변을 그만큼 길게 뽑아준다는 뜻은 아닙니다. 이 둘은 스펙 표에서 보통 다른 줄에 적혀 있으니 나눠서 확인하는 편이 좋습니다.
창에 들어가는 건 내가 입력한 질문만이 아닙니다. 시스템 프롬프트, 도구·함수 정의, 첨부한 파일의 추출 텍스트, 이전 대화 기록, 검색해 온 문서 조각까지 모두 같은 예산을 나눠 씁니다. 긴 대화에서 앞부분을 잊은 듯 보이는 현상은 이 예산이 꽉 찼을 때 오래된 내용이 잘리거나 요약되는 처리와 관련이 있습니다. 한도 초과 시 오류를 내는지, 조용히 잘라내는지는 제품마다 다릅니다.
또 하나, 최대 수용량과 실제로 잘 활용하는 범위는 별개입니다. 긴 입력의 중간 부분 정보를 상대적으로 덜 활용한다는 연구 보고가 있었고, 모델과 버전에 따라 개선 정도가 달라 지금도 평가가 엇갈리는 영역입니다. 그래서 중요한 지시나 근거 문서는 앞이나 뒤 같은 눈에 띄는 위치에 두고, 참조할 부분을 명시적으로 짚어 주는 방식이 실무에서 자주 쓰입니다.
반복 작업이라면 프롬프트 캐싱 지원 여부도 스펙에서 볼 만합니다. 앞부분이 동일할 때 재사용하는 구조라, 고정 지시문을 앞에 모아 두는 설계가 유리해집니다. 다만 적용 조건과 유지 시간은 제공사 문서 기준으로 제각각입니다.
확인 체크리스트
- 컨텍스트 윈도우가 입력·출력 합산인지, 입력 전용인지 문서에서 확인
- 최대 출력 토큰이 별도로 적혀 있는지 확인
- 첨부 파일·도구 정의·대화 기록이 같은 한도를 쓰는지 확인
- 한도 초과 시 오류인지 자동 잘림인지 동작 방식 확인
- 토큰 계산은 해당 모델의 토크나이저 기준인지 확인
- 캐싱 지원 여부와 적용 조건 확인
- 위 내용은 모델·버전마다 다르므로 실제 공식 스펙 문서를 직접 확인
🛠 정정 제안
틀린 수치·문장이 있으면 근거와 함께 알려 주세요.
🧵 새 토론은 스레드에 먼저 올라와요 @nobangjang 팔로우
댓글 2