컨텍스트 윈도우의 이해

컨텍스트 윈도우는 모델이 한 번의 호출에서 입력과 출력을 합쳐 다룰 수 있는 토큰의 최대 개수다. 시스템 프롬프트, 도구 정의, 대화 이력, 사용자 메시지, 그리고 모델이 생성할 응답까지 모두 이 하나의 예산 안에서 경쟁한다. 토큰은 단어가 아니라 단어 조각 단위이며, 한국어는 영어보다 토큰을 더 많이 소비하는 경향이 있다는 점도 실무에서 중요하다. claude-opus-4-8은 표준 200K 윈도우를 제공하며, 1M 컨텍스트 변형(모델 ID 표기상 [1m])을 통해 최대 100만 토큰까지 확장할 수 있다. 다만 윈도우가 크다는 것이 곧 "무한히 쌓아도 된다"는 뜻은 아니다.

시험이 반복해서 묻는 핵심 개념은 무상태(stateless) API다. Messages API는 대화를 서버에 저장하지 않는다. 모델은 이전 턴을 "기억"하지 않으며, 매 호출마다 클라이언트가 전체 대화 이력과 그동안의 모든 도구 호출·도구 결과를 다시 처음부터 전송해야 한다. 따라서 에이전트 루프가 길어질수록 입력 토큰은 단조 증가한다. 윈도우가 차오르는 이유는 "모델이 잊어버려서"가 아니라 "클라이언트가 매번 모든 것을 다시 보내기 때문"이다. 이 인과를 거꾸로 설명하는 선택지는 함정이다. 에이전트가 도구를 20번 호출했다면 21번째 호출에는 그 20번의 요청과 결과가 전부 입력에 포함된다.

윈도우가 가득 차면 두 가지 문제가 나타난다. 첫째, 입력이 한도를 초과하면 호출 자체가 실패하거나 오래된 메시지가 잘려 맥락이 끊긴다. 둘째, 한도에 도달하기 전이라도 입력이 매우 길어지면 모델이 중간에 묻힌 정보를 놓치는 경향(중간 소실)이 생겨 응답 품질이 떨어진다. 그래서 "윈도우에 들어가기만 하면 된다"는 가정은 틀렸다. 들어가더라도 핵심 정보가 잡음에 묻히면 성능은 저하된다.

비용 관점에서 반드시 알아야 할 함정이 하나 더 있다. 1M 윈도우를 쓰더라도 입력이 일정 임계(약 200K 토큰)를 넘어가면 장문 컨텍스트(long-context) 가격 구간으로 진입해 토큰 단가가 올라간다. 즉 윈도우를 키우는 것은 공짜가 아니며, "큰 윈도우 = 좋은 설계"가 아니라 "필요한 만큼만 채우는 것 = 좋은 설계"다. 시험은 "대화가 길어져 비용이 폭증했다"는 시나리오에서 단순히 윈도우를 키우는 선택지를 오답으로, 이력을 줄이거나 캐싱·요약을 적용하는 선택지를 정답으로 배치한다.

응답의 usage 필드는 이 예산을 진단하는 도구다. input_tokens, output_tokens와 더불어 cache_creation_input_tokens, cache_read_input_tokens가 함께 보고되므로, 어느 호출에서 토큰이 급증했는지, 캐시가 실제로 적중했는지를 추적할 수 있다. 토큰을 측정하지 않고 추측으로 최적화하는 것은 아키텍트의 태도가 아니다.

정리

• 컨텍스트 윈도우는 입력과 출력을 합친 토큰 예산이며, 시스템 프롬프트·도구 정의·이력·응답이 모두 그 안에서 경쟁한다.
• Messages API는 무상태이므로 매 호출마다 전체 이력과 도구 결과를 다시 보낸다. 윈도우가 차는 원인은 "모델의 망각"이 아니라 "클라이언트의 재전송"이다.
• claude-opus-4-8은 200K 표준, [1m] 변형으로 최대 1M 토큰을 제공하지만, 약 200K를 넘으면 장문 가격 구간으로 단가가 오른다.
• 윈도우에 들어가더라도 입력이 길면 중간 정보 소실로 품질이 떨어진다. "큰 윈도우"가 아니라 "필요한 만큼만 채우기"가 정답이다.
• usage의 토큰·캐시 필드로 실제 소비를 측정하고 최적화 효과를 검증한다.