컨텍스트 윈도우는 모델이 한 번에 '볼 수 있는' 토큰 총량의 상한입니다. 프롬프트, 대화 기록, 검색으로 가져온 자료, 그리고 모델이 이미 생성한 답변까지 모두 순서대로 하나의 시퀀스에 나열됩니다. 윈도우가 결정하는 것은 모델의 '작업대' 크기이지, 모델이 얼마나 똑똑한지가 아닙니다. 1M 토큰 윈도우에는 수천 페이지 분량의 문서가 들어가지만, 모델이 그 모든 페이지를 제대로 활용할 수 있다는 뜻은 아닙니다.
컨텍스트 윈도우 안에는 실제로 무엇이 들어 있을까
윈도우 안에 들어 있는 것은 파일이 아니라 토큰입니다. 프롬프트, 대화 기록, 검색 조각, 도구 호출 결과는 모두 토큰으로 잘려 순서대로 하나의 시퀀스에 채워집니다. 모델은 위치 인코딩으로 앞뒤를 구분할 뿐, '폴더'라는 개념은 없습니다. 1M 토큰은 한글로 환산하면 수십만 자, 천 페이지가 넘는 문서 분량입니다. 다만 이는 '들어간다'는 의미일 뿐, '기억한다'는 뜻이 아니라는 점에 유의해야 합니다.
어텐션 메커니즘에 숨겨진 청구서
모델이 이 시퀀스를 읽어내는 수단은 셀프 어텐션입니다. 새 토큰을 하나 생성할 때마다 그 이전의 모든 토큰과 일일이 관련도를 계산하므로, 계산량은 시퀀스 길이에 대해 제곱으로 증가합니다. 길이가 2배가 되면 어텐션 부분의 계산량은 4배가 되는 것입니다. 더 큰 청구서는 KV 캐시입니다. 추론 시 각 토큰의 키·값 벡터를 재계산하지 않기 위해 GPU 메모리에 상주시켜야 합니다. Llama-3.1-8B를 예로 들면 토큰당 약 128KB의 캐시가 필요해, 128K 컨텍스트는 약 16GB, 1M 토큰은 약 128GB의 VRAM을 소비합니다. '윈도우 2배'는 결코 무료가 아닙니다. VRAM을 직접 갉아먹고, 첫 토큰 응답을 늦추며, 긴 컨텍스트 API 호출 요금을 끌어올립니다.
들어가는데, 왜 찾지 못하는 걸까
청구서를 감당할 수 있다는 것과 잘 쓴다는 것은 별개의 문제입니다. 어텐션 가중치는 softmax로 정규화되어 합이 항상 1이 됩니다. 토큰이 많아질수록 각 토큰에 돌아가는 어텐션은 얇게 희석됩니다. 스탠퍼드대학교의 2023년 실험 'Lost in the Middle'은 이를 생생하게 보여주었습니다. 핵심 정보를 컨텍스트의 앞이나 끝에 두면 모델은 빠르고 정확하게 찾아냅니다. 하지만 한가운데 숨기면 정답률이 20%포인트 이상 떨어지고, 컨텍스트를 주지 않은 것만 못해지기도 합니다. 더 큰 격차는 평가 방식에 숨어 있습니다. '건초더미 속 바늘 찾기(needle-in-a-haystack)' 테스트는 '한 문장을 찾을 수 있는가'만 묻는데, 이는 거의 모든 모델이 만점을 받습니다. 반면 NVIDIA의 RULER 벤치마크가 멀티홉 추적·집계 같은 실제 태스크로 바꾸면, 32K 지원을 표방한 모델 중 32K 길이에서 합격 수준을 유지하는 것은 절반뿐이었습니다. 표기 윈도우와 실효 윈도우 사이에는 흔히 수 배의 차이가 납니다.
널리 퍼진 세 가지 오해
오해 1: 윈도우가 클수록 모델이 더 잘 기억한다. 윈도우는 작업대이지 하드디스크가 아닙니다. 윈도우를 넓혀도 모델 파라미터 속 '장기 지식'이 늘어나지 않으며, 한 번에 펼쳐놓을 수 있는 자료가 늘어날 뿐입니다. 대화가 끝나고 윈도우가 비워지면 모델은 아무것도 '기억'하지 않습니다. 대화를 넘나드는 장기 기억을 맡는 것은 검색 증강 생성과 같은 외부 기억 메커니즘입니다.
오해 2: 긴 컨텍스트가 RAG를 구식으로 만든다. 지식 베이스 전체를 윈도우에 쏟아붓는 것은 비싸고 느립니다. 입력 토큰은 양만큼 과금되고, 초대형 컨텍스트에서는 첫 토큰 지연과 VRAM 소비가 모두 실제 비용이 됩니다. 엔지니어링 현장의 주류는 오히려 반대입니다. 먼저 시맨틱 검색으로 가장 관련 높은 몇 개 조각으로 좁힌 뒤, 윈도우 안에서 정독합니다. 여러 문서를 넘나들며 답을 엮어야 하는 질문에는 GraphRAG 같은 구조화 검색 기법도 있습니다. 긴 윈도우와 검색은 경쟁자가 아니라 파트너입니다.
오해 3: 토큰 수 = 유효 기억. 표기 1M 토큰 모델이라도 진짜 추론이 필요한 태스크에서는 실효 길이가 표기 값의 몇 분의 일에 그칠 수 있습니다. '들어간다'와 '잘 쓴다'는 별개의 문제입니다. 다음에 모델 카드의 숫자를 볼 때는 한마디 더 물어보세요. '내 태스크 길이에서는 정확도가 얼마나 남는가'라고요.
윈도우 크기 숫자, 도대체 어떻게 읽어야 할까
먼저 태스크를 봅니다. 계약서 몇 건을 읽거나 코드 저장소를 분석하는 정도라면 수십K~128K로 충분한 경우가 대부분입니다. 전체 코퍼스 대상 Q&A에서는 병목이 윈도우 상한이 아니라 검색 품질에 있는 경우가 많습니다. 다음으로 실효성을 봅니다. RULER나 LongBench 같은 긴 컨텍스트 벤치마크에서 목표 길이에서의 실제 성능을 확인하세요. 표기 최대값만 보지 마십시오. 마지막으로 비용을 봅니다. 긴 컨텍스트 입력 토큰은 단가가 높고, KV 캐시는 동시 실행 수를 제한합니다. 윈도우는 크다고 좋은 것이 아니라, '충분한 길이 안에서 가장 안정적이고 비용이 가장 낮은' 것이 정답입니다.
