컨텍스트 윈도우란? AI의 거의 모든 것을 설명하는 한계

쉬운 말로 풀어본 설명

컨텍스트 윈도우는 모델이 한 번에 눈앞에 놓고 볼 수 있는 텍스트의 총량입니다. 지금 대화에 대해 모델이 아는 모든 것이 그 안에 들어가야 합니다. 당신이 준 지시, 서로 주고받은 모든 메시지, 업로드한 모든 파일, 그리고 지금 막 쓰려는 답변까지요.

머릿속에 그려두면 좋은 그림이 있습니다. 모델은 당신과의 대화를 사실 전혀 기억하지 못합니다. 메시지를 보낼 때마다 지금까지의 대화 전체가 처음인 것처럼 통째로 건네지고, 모델은 그걸 다 읽은 다음 이어질 답변을 씁니다. 컨텍스트 윈도우는 그 대화록을 올려놓아야 하는 책상의 크기입니다. 책상이 꽉 차면 무언가는 내려놓아야 합니다.

AI가 스무 번쯤 주고받을 때까지는 또렷하다가 갑자기 앞뒤가 안 맞는 말을 하거나, 처음에 정해둔 조건을 잊거나, 이미 준 파일을 다시 달라고 하는 이유가 여기 있습니다. 헷갈린 게 아닙니다. 대화의 앞부분이 책상 밖으로 밀려난 것입니다.

혼동이 워낙 많은 부분이라 하나는 지금 바로 구분해 두는 게 좋습니다. 컨텍스트 윈도우는 메모리와 다릅니다. ChatGPT나 Claude 같은 제품에는 별도의 메모리 기능이 있어서, 대화와 대화 사이에 당신에 대한 사실을 저장해 두었다가 새 대화에 조용히 끼워 넣습니다. 그건 모델 위에 얹어 만든 제품 기능입니다. 컨텍스트 윈도우는 모델 자체의 고정된 성질이고, 어떤 메모리 기능도 그 크기를 키워주지는 않습니다.

토큰, 그리고 어림잡는 법

컨텍스트 윈도우는 단어가 아니라 토큰으로 잽니다. 모델은 단어를 읽지 않고 조각을 읽기 때문입니다. 흔한 단어는 보통 토큰 하나, 길거나 드문 단어는 여러 조각으로 쪼개지고, 문장 부호와 공백도 함께 셈에 들어갑니다.

기억해 둘 만한 대략의 환산은 이렇습니다.

• 토큰 1개는 영어로 약 4글자, 단어로 치면 4분의 3 정도입니다.
• 토큰 1,000개는 영어 단어로 대략 750개, 보통 산문으로 한 장 반쯤 됩니다.
• 코드는 더 빽빽합니다. 기호와 들여쓰기, 낯선 식별자 때문에 3글자에 토큰 1개 정도로 보시면 됩니다.
• 다른 언어는 효율이 떨어집니다. 토크나이저에 덜 반영된 언어는 같은 뜻을 담는 데 토큰이 두세 배까지 들 수 있어서, 토큰당 요금을 내고 있다면 알아둘 만합니다.

이렇게 잡아두면 홍보 자료에서 보는 숫자들을 그려볼 수 있습니다.

컨텍스트 윈도우	대략 이 정도 분량
토큰 8,000개	긴 기사 한 편
토큰 32,000개	주석 붙은 짧은 논문
토큰 128,000개	300쪽짜리 책 한 권
토큰 200,000개	빽빽한 기술 매뉴얼, 또는 중간 규모 코드베이스
토큰 1,000,000개	책 여러 권, 또는 1년 치 회의록

이 표가 감추고 있는 중요한 사실이 있습니다. 한계는 메시지 하나가 아니라 대화 전체에 걸립니다. 128,000 토큰 윈도우는 매번 128,000 토큰씩 보낼 수 있다는 뜻이 아닙니다. 모델이 쓴 답변까지 포함한 모든 것의 누적 합계가 그 숫자 아래에 머물러야 한다는 뜻입니다.

윈도우를 실제로 채우는 것들

윈도우가 차는 속도에 다들 놀라는데, 그 안에 들어가는 것 대부분이 눈에 보이지 않기 때문입니다. 보통의 채팅 세션에서 모델은 매 차례마다 아래를 전부 읽고 있습니다.

1. 시스템 프롬프트. 당신이 무언가 입력하기도 전에 제품이 먼저 보내는 지시입니다. 어떻게 행동할지, 어떤 도구가 있는지, 오늘 날짜, 안전 규칙 같은 것들이죠. 흔히 수천 토큰이고, 당신 눈에는 보이지 않습니다.
2. 커스텀 지시나 메모리. 제품이 당신에 대해 저장해 두었다가 자동으로 끼워 넣는 모든 내용입니다.
3. 이전 메시지 전부. 당신 것과 모델 것 모두 통째로 들어갑니다. 모델이 쓴 긴 답변도 셈에 들어가고, 보통 이쪽이 가장 크게 차지합니다.
4. 업로드한 파일 전부, 또는 거기서 뽑아낸 부분입니다. 40쪽짜리 PDF는 대략 20,000에서 30,000 토큰입니다.
5. 도구와 검색 결과. 웹 검색 한 번이 다섯 페이지를 끌어오면, 지금까지의 대화 전체보다 더 많은 양이 붙을 수 있습니다.
6. 지금 생성 중인 답변. 출력도 입력과 같은 예산을 나눠 씁니다.

짧게 느껴진 대화가 한계 근처에 가 있을 수 있는 이유가 이것입니다. 당신은 짧은 메시지 여덟 개를 보냈지만, 모델은 긴 답변 여덟 개를 썼고, 당신은 문서 두 개를 붙였으며, 모델은 검색을 세 번 돌렸습니다. 그중 눈에 보이는 부분은 전체의 10퍼센트쯤일 겁니다.

엉킨 대화의 해법이 그토록 자주 "새 대화를 시작하세요"인 이유이기도 합니다. 모델의 기분을 초기화하는 게 아닙니다. 책상을 치우는 것입니다.

표기된 크기와 실제로 쓸 만한 크기

가장 중요한데 가장 적게 이야기되는 부분입니다. 모델의 품질은 한계 직전까지 그대로 유지되다가 절벽처럼 뚝 떨어지지 않습니다. 서서히 나빠지고, 한계에 한참 못 미쳐서부터 나빠지기 시작합니다.

가장 잘 기록된 사례는 흔히 중간에서 길을 잃는 현상(lost in the middle)이라고 불립니다. 긴 문서의 앞부분에 특정 사실을 넣어두면 모델이 찾아냅니다. 끝부분에 넣어도 찾아냅니다. 그런데 200쪽 한가운데에 묻어두면 찾아내는 정확도가 눈에 띄게 떨어집니다. 긴 입력 전체에 주의가 고르게 퍼지지 않고, 양 끝이 더 많이 가져갑니다.

긴 입력 곳곳에 흩어진 여러 사실을 엮어야 하는 작업이면 더 어려워집니다. 건초 더미에서 바늘 하나 찾기는 이미 풀린 문제입니다. 바늘 네 개를 찾아 그 사이의 관계까지 따지는 일은 아직 그렇지 않은데, 사람들이 큰 컨텍스트 윈도우를 쓰는 이유가 바로 그런 작업입니다.

그러니 표기된 숫자는 편하게 쓸 수 있는 범위가 아니라 최대 수용량으로 보세요. 실제 사용에서 나온 실용적인 기준은 이렇습니다. 표기된 윈도우의 절반쯤까지는 믿을 만하게 동작하고, 그 너머는 믿기보다 확인하는 편이 낫습니다. 300쪽짜리 계약서에 해지 조항이 없다고 모델이 말한다면 직접 확인하세요. 특히 그 조항이 문서 한가운데 있을 만한 경우라면요.

비교할 때 따라오는 결론은 이렇습니다. 100만 토큰 윈도우를 가진 모델이 20만 토큰 모델보다 긴 문서를 자동으로 더 잘 다루는 것은 아닙니다. 더 잘 받아들일 뿐입니다. 그 전체에 걸쳐 제대로 추론하는지는 별개의 문제이고, 알아보는 방법은 답을 이미 알고 있는 문서로 직접 시험해 보는 것뿐입니다.

한계에 도달하면 벌어지는 일

넘쳤을 때의 처리 방식은 제품마다 다르고, 내가 쓰는 제품이 어느 쪽인지 알면 이상해 보이던 동작들이 많이 설명됩니다.

처리 방식	겉으로 보이는 것	주로 어디서
오류 발생	길이 관련 메시지와 함께 요청이 거부됨	대부분의 직접 API 사용
조용한 잘라내기	알림 없이 오래된 메시지부터 버려짐	많은 채팅 화면
요약 누적	오래된 메시지를 요약으로 압축	채팅 제품에서 점점 흔해짐
검색 방식	매 차례 문서에서 관련된 부분만 꺼내옴	문서, 지식베이스 도구

진짜 문제를 만드는 건 조용한 잘라내기입니다. 아무것도 알려주지 않기 때문입니다. 증상은 이렇습니다. 처음에 정해둔 규칙을 모델이 갑자기 무시하고, 한 시간 전에 고쳐둔 말투로 되돌아가고, 이미 답한 질문을 다시 묻습니다. 모델이 고장 난 게 아닙니다. 그 지시들이 더 이상 책상 위에 없을 뿐입니다.

요약 누적은 그보다 낫지만 손실이 있습니다. 요약은 요지를 남기고 구체적인 것을 버리기 때문에, "시너지라는 단어는 절대 쓰지 마"라는 조건이 "사용자에게 문체 선호가 있음" 정도로 살아남습니다. 그건 아무 도움이 되지 않습니다.

실제로 효과가 있는 요령

들이는 노력 대비 효과가 큰 순서로 정리했습니다.

주제가 바뀌면 새 대화를 시작하세요. 가장 값어치 있는 습관 하나입니다. 긴 대화는 그 앞의 모든 것을 비용으로 짊어지는데, 이제는 상관없어진 곁가지까지 포함됩니다. 긴 대화가 더 많이 아는 게 아닙니다. 더 비싸고 더 묽어질 뿐입니다.

질문은 긴 자료 앞이 아니라 뒤에 두세요. 문서를 먼저 붙여넣고 그다음에 물으면, 질문이 답이 생성되는 지점 가까이에 놓여서 긴 입력에서의 정확도가 눈에 띄게 올라갑니다. 붙여넣기가 먼저, 질문이 나중입니다.

중요한 조건은 다시 못 박으세요. 열다섯 번쯤 주고받은 뒤부터는, 중요한 규칙을 그 규칙이 필요한 메시지에서 다시 말해주세요. "다시 한번 말하지만, 격식 있는 문체로, 글머리 기호 없이, 400단어 이내로" 같은 식으로요. 한 줄이면 되고, 잘려나가도 살아남습니다.

책 전체가 아니라 필요한 쪽만 보내세요. 손해배상 조항을 확인받아야 한다면 그 조항과 앞뒤 부분만 주세요. 양보다 정확한 범위가 낫습니다. 더 빠르고, 더 싸고, 더 정확합니다.

의식적으로 요약하고 다시 시작하세요. 작업 세션이 길어지면 정리된 인수인계를 요청하세요. 현재 상태, 내린 결정, 남은 질문, 지켜야 할 조건 이렇게요. 그걸 새 대화에 붙여넣으세요. 알맹이는 남고 잡음은 사라지며, 모델이 곧바로 또렷해지는 게 느껴질 겁니다.

들어가지 않는 자료에는 검색 방식을 쓰세요. 자료가 정말로 어떤 윈도우보다도 크다면, 답은 더 큰 윈도우가 아니라 질문마다 관련된 조각만 꺼내오는 것입니다. 문서 도구들이 안에서 하는 일이 바로 그것입니다.

오류만이 아니라 품질 저하도 지켜보세요. 답변이 두루뭉술해지거나, 말을 흐리는 일이 잦아지거나, 형식 지시를 무시하기 시작하면 윈도우 깊숙이 들어와 있을 가능성이 큽니다. 모델이 나빠졌다고 결론 내리기 전에 새로 시작해 보세요.

윈도우는 실제로 얼마나 필요할까요?

가장 큰 숫자를 찾아다니지 말고, 하는 일에 윈도우를 맞추세요.

하는 일	필요한 크기	이유
이메일, 초안 작성, 짧은 질문	요즘 모델이면 아무거나	한계 근처에도 가지 않습니다
긴 문서 편집	10만 이상	문서에 그 문서를 두고 나눈 대화까지
계약서, 규정 검토	20만 이상, 확인은 필수	문서와 그에 대한 추론까지, 위의 단서 포함
코드베이스 전체 추론	구할 수 있는 최대치	코드는 토큰이 빽빽하고 파일을 넘나드는 추론엔 폭이 필요
수개월 치 기록 분석	최대치 또는 검색 방식	힘으로 밀기보다 검색 방식이 나은 경우가 많음
API로 제품 개발	생각보다 작게, 캐싱 활용	긴 프롬프트가 비용과 지연의 주범

대부분의 사람에게 솔직한 답은, 컨텍스트 윈도우가 구독을 고르는 결정적 기준은 아니라는 것입니다. 글의 품질, 생태계, 가격이 더 중요합니다. 결정적 기준이 되는 상황은 딱 하나입니다. 일반적인 윈도우에 담기지 않는 분량의 자료를 일상적으로 넣어야 하는 경우죠. 그때는 차이가 미미한 정도가 아니라, 되느냐 안 되느냐의 차이가 됩니다.

직접 확인해 보고 싶다면, 같은 긴 문서를 두세 모델에 넣어보고 이미 알고 있는 내용과 답을 대조하는 게 현실적인 방법입니다. Whizi 같은 작업 공간이면 이게 쉬운데, GPT, Claude, Gemini, Grok, DeepSeek이 구독 하나 뒤에 함께 있어서 Gemini의 아주 큰 윈도우와 Claude의 꼼꼼한 종합이 클릭 한 번 거리이기 때문입니다. 모델을 나란히 비교하기를 보시거나, 더 넓은 결정은 AI 모델 고르는 법에서 읽어보세요.