AI가 잊어버리는 이유는 무엇입니까?
LLM은 장기 기억이 없습니다 — 최근 토큰의 슬라이딩 윈도우만 "볼" 수 있으며, 이 윈도우 밖의 모든 것은 잊혀지거나 압축됩니다. 이 글에서는 이것이 프롬프트에 어떤 의미인지, 그리고 이러한 한계 내에서(및 그 주변에서) 어떻게 작업하는지 설명합니다.
컨텍스트 윈도우란 무엇입니까?
컨텍스트 윈도우는 LLM이 다음 출력을 생성할 때 고려할 수 있는 최대 텍스트 양(토큰 단위)입니다.
GPT-5.5에 128k 토큰 컨텍스트 윈도우가 있는 경우, 모델은 대화의 마지막 128,000개 토큰(약 96,000단어)을 "볼" 수 있습니다. 그 이전의 모든 것은 모델에게 보이지 않으며 응답에 영향을 미치지 않습니다.
토큰 대 단어: 토큰은 단어가 아닙니다. 평균적으로 1토큰 ≈ 4자 또는 약 0.75단어입니다. 4,000토큰 컨텍스트 윈도우 ≈ 일반 영어 텍스트 3,000단어입니다. 한국어 텍스트는 문자 인코딩으로 인해 단어당 약 2토큰이 필요합니다.
컨텍스트 윈도우 크기는 모델마다 크게 다릅니다:
| 모델 | 컨텍스트 윈도우 |
|---|---|
| GPT-5.5 mini | 4k 토큰 (≈ 3,000단어) |
| GPT-5.5 | 128k 토큰 (≈ 96,000단어) |
| Claude Opus 4.8 | 200k 토큰 (≈ 150,000단어) |
| Gemini 3.1 Pro | 2,000,000 토큰 (≈ 1,500,000단어 — 현재 이용 가능한 최대 컨텍스트) |
| 로컬 모델 (Ollama, LM Studio) | 4k~128k+ 설정 가능, 사용 가능한 VRAM에 의해 제한 |
모든 모델에서 원칙은 동일합니다: 윈도우 밖의 모든 것은 보이지 않습니다.
AI가 "잊어버리는" 이유
대화의 총 토큰 수(시스템 프롬프트 + 채팅 기록 + 사용자 입력 + 도구 + 예상 출력)가 컨텍스트 윈도우를 초과하면, 오래된 부분은 잘리거나 요약되거나 완전히 삭제됩니다.
이것은 인간의 망각과 같은 기억 상실이 아닙니다. 모델은 "생각한 다음 잊어버리는" 것이 아닙니다. 잘린 텍스트를 문자 그대로 보지 않습니다 — 모델의 입력 공간에 더 이상 존재하지 않습니다.
컨텍스트 한계에 도달했을 때 일반적인 증상:
- AI가 30개 메시지 전에 준 지시사항을 무시하거나 모순됩니다
- 긴 창작 이야기에서 모델이 이전에 설정한 캐릭터 이름, 세부사항, 제약을 잊어버립니다
- 많은 순서에 걸친 연구 채팅에서 사실이 혼동되거나 모델이 정보를 재발명합니다
- AI가 설명 없이 갑자기 어조를 바꾸거나 원래 제약을 위반합니다
실제로 무슨 일이 일어나고 있는가
대부분의 채팅 인터페이스는 다음 세 가지 전략 중 하나를 사용합니다:
- 1가장 오래된 메시지 삭제 — 가장 최근 N개 메시지가 윈도우에 맞습니다; 더 오래된 메시지는 완전히 삭제됩니다
- 2이전 대화 요약 — 시스템이 초기 메시지를 간략한 요약("이전에 X, Y, Z에 대해 논의했습니다...")으로 압축하여 컨텍스트를 보존합니다
- 3시스템/개발자 프롬프트 고정 — 시스템 메시지는 고정된 채 사용자 메시지가 순환합니다
이 모든 방법은 "요점"을 보존하지만 구체적인 세부사항을 잃습니다. 모델이 원래 지시사항을 더 이상 보지 못하면 따를 수 없습니다.
컨텍스트 윈도우와 환각
컨텍스트 과부하는 환각을 증폭시킵니다 — 원본 정보가 더 이상 보이지 않을 때 모델이 그럴듯한 추측으로 빈칸을 채우기 때문입니다.
패턴은 이렇습니다: 50개 메시지 전에 언급한 것을 AI에게 참조하도록 요청합니다. 하지만 그 메시지가 컨텍스트 윈도우에서 벗어났습니다. 모델은 실제 사실에 접근할 수 없으므로 현재 컨텍스트에서 추론한 것을 기반으로 그럴듯하게 들리는 답변을 생성합니다. 결과: 조작.
이것이 높은 컨텍스트의 긴 채팅이 집중된 짧은 교환보다 더 많은 환각을 생성하는 이유입니다. 모델이 추론 능력을 잃는 것이 아닙니다 — 불완전한 정보로 작업하는 것입니다.
상호작용은 직접적입니다: 더 적은 컨텍스트 → 근거 부족 → 증가된 환각 위험.
이 효과는 이미 무작위성을 높이는 높은 온도 및 top-p 설정으로 인해 증폭됩니다.
프롬프트 설계가 윈도우 내 유지에 어떻게 도움이 되는가
프롬프트를 전략적으로 구성하면 고정된 컨텍스트 예산 내에서 더 많은 것을 달성할 수 있습니다.
중요한 지시사항을 앞에 배치하십시오. 가장 중요한 제약사항, 규칙, 정의를 시스템 프롬프트 또는 첫 번째 사용자 메시지에 배치하십시오. 이것들은 20순서 후에 묻힌 지시사항보다 컨텍스트에서 벗어날 가능성이 적습니다.
반복을 피하십시오. 이미 한 번 설명한 것이 있다면 다시 붙여넣지 마십시오. 대신 참조하십시오: "위 요약에서 논의한 바와 같이..." 이것이 토큰을 절약합니다.
명시적으로 요약하십시오. 모델에게 지금까지의 주요 결정사항, 제약사항 또는 사실을 요약하도록 요청하십시오. 그런 다음 분산된 이전 컨텍스트에 의존하는 대신 그 요약에서 다음 응답을 구축하십시오.
순서에 집중하십시오. 단일 다중 주제 독백은 컨텍스트를 비효율적으로 사용합니다. 별도의 좁은 범위의 교환으로 나누십시오.
컨텍스트 윈도우 크기 (2026)
긴 문서 작업
전체 책이나 수백 페이지의 PDF를 단일 컨텍스트 윈도우에 붙여넣는 것은, Gemini 3.1 Pro의 200만 토큰 윈도우에서도, 모델이 여러 다른 섹션에 동시에 효과적으로 집중할 수 없기 때문에 비효율적입니다.
1,000페이지 책 ≈ 250,000 토큰. 기술적으로 Gemini 3.1 Pro는 이를 처리할 수 있습니다. 실제로 모델의 추론은 크게 다른 섹션에 걸쳐 질문에 답변하도록 요청받을 때 저하됩니다. 긴 문서를 위한 더 나은 접근 방식:
- 1섹션을 순차적으로 처리하십시오. 한 번에 하나의 챕터나 섹션을 추출하고 분석하십시오. 섹션별로 집중된 질문을 하십시오: "섹션 3의 주요 결론은 무엇입니까?" 그런 다음 다음 섹션으로 이동하십시오.
- 2계층적 요약. 1~10페이지에서 주요 요점을 추출한 다음 11~20페이지에서, 이러한 요약을 챕터 수준 요약으로 결합하십시오. 그런 다음 챕터를 문서 수준 요약으로 결합하십시오.
- 3구조화된 추출. 더 높은 수준의 질문을 하기 전에 문서를 표, JSON 또는 글머리 기호 목록으로 변환하십시오. 이것은 정보를 압축합니다.
- 4RAG(검색 증강 생성)를 사용하십시오. 정말 큰 문서 세트(100+ 페이지)의 경우 검색 기반 시스템이 더 효과적으로 작동합니다.
컨텍스트 전략 비교
RAG 검색은 100페이지 이상의 문서 세트에서 비용과 정확성 모두에서 전체 붙여넣기보다 우수합니다.
| 전략 | 최적 용도 | 토큰 비용 | 정확성 |
|---|---|---|---|
| 전체 문서 붙여넣기 | 짧은 문서(10k 토큰 미만) | 높음 | 높음(윈도우 내인 경우) |
| 순차적 섹션 분석 | 보고서, 책 | 중간 | 섹션별로 높음 |
| 계층적 요약 | 50페이지 이상 문서 | 낮음 | 중간(압축 손실) |
| RAG 검색 | 100페이지 이상 문서 세트 | 쿼리당 낮음 | 높음(관련 조각 검색) |
PromptQuorum이 컨텍스트 관리를 돕는 방법
컨텍스트 한계 근처에서 작업하는 것은 각 모델이 다른 한계, 잘림 동작, 가격 책정 및 (로컬 LLM의 경우) VRAM 요구사항을 가지고 있기 때문에 복잡합니다. PromptQuorum은 이러한 제약을 투명하게 만듭니다: 전송 전에 각 모델이 얼마나 많은 컨텍스트를 소비하는지, 언제 오버플로가 예상되는지 확인할 수 있습니다.
로컬 LLM의 컨텍스트 윈도우 조정
LM Studio 또는 Ollama에서 모델을 실행하면 컨텍스트 윈도우 크기를 구성할 수 있습니다. 기본적으로 도구는 종종 모델의 최대값(예: 7B 모델의 경우 32k)으로 설정합니다. 하지만 그것이 실제로 필요한 것인 경우는 거의 없습니다.
PromptQuorum은 LM Studio와 통합되어 작업별 컨텍스트 윈도우를 조정할 수 있습니다: 가벼운 빠른 Q&A에는 4k를 선택하고; 심층 문서 분석에는 32k를 선택하고; 긴 대화에는 64k를 선택하십시오.
자동 컨텍스트 오버플로 검사
PromptQuorum은 전송 전에 확인합니다: 시스템 프롬프트 + 현재 대화 기록 + 새 입력 + 예상 출력 길이가 주어졌을 때, 각 모델에 구성된 컨텍스트 윈도우에 맞습니까?
오버플로가 예상되면 PromptQuorum이 경고하거나 전송 전에 대화를 정리/요약하도록 요청합니다. 더 이상 놀라운 잘림이 없습니다.
컨텍스트 윈도우 ↔ VRAM 트레이드오프
로컬 모델의 경우 더 큰 컨텍스트 윈도우는 상당히 더 많은 VRAM을 필요로 합니다. 7B (Q4_K_M) 모델은 4k 컨텍스트에서 ~5 GB, 32k 컨텍스트에서 ~8–10 GB, 128k 컨텍스트에서 ~12–14 GB VRAM이 필요합니다. 사용 가능한 VRAM을 초과하면 프로세스가 충돌하거나 CPU 추론으로 폴백됩니다(10–100배 느림).
로컬 배포에 사용 가능한 가장 긴 컨텍스트 윈도우를 가진 모델에 대해서는 장문 컨텍스트 로컬 LLM을 참조하십시오.
다중 모델 인식
GPT-5.5(128k 윈도우), Claude(200k 윈도우) 및 로컬 7B 모델(선택한 32k 윈도우)에 프롬프트를 전송할 때, PromptQuorum은 자동으로 세 가지 한계 내에서 프롬프트를 유지합니다. 하나의 프롬프트, 여러 모델, 수동 재작성 없음.
컨텍스트 관리를 위한 실용적인 레시피
레시피 1: 하나의 프로젝트에 대한 긴 채팅 — 이전 결정을 잃지 않고 단일 프로젝트에 대한 다중 순서 대화를 유지합니다.
- 1시스템 프롬프트에 프로젝트의 주요 제약사항(범위, 대상, 어조, 기술적 한계)을 한 번 임베드하십시오. 반복하지 마십시오.
- 210~15회 교환마다 모델에게 현재 상태를 요약하도록 요청하십시오: "지금까지 한 가장 중요한 5가지 결정은 무엇입니까?"
- 3분산된 이전 메시지에 의존하는 대신 그 요약을 다음 순서의 컨텍스트로 사용하십시오.
- 4PromptQuorum에서 32k–64k 컨텍스트 윈도우를 설정하고 오버플로 경고를 활성화하여 언제 요약해야 하는지 알 수 있습니다.
레시피 2: 긴 보고서 분석 — 50~100페이지 문서에서 인사이트를 추출합니다.
- 1문서를 3~5개 섹션(챕터, 부분)으로 나누십시오.
- 2각 섹션에 대해 집중된 프롬프트를 작성하십시오: "이 섹션의 주요 결과를 5개의 글머리 기호로 요약하십시오."
- 3각 섹션에서 5개의 요약을 수집하십시오.
- 4마지막 순서에서 질문하십시오: "이러한 섹션 요약을 고려할 때 전체 결론은 무엇입니까?"
- 5컨텍스트 한계 내에 잘 머물렀으며 "책에서 길을 잃은" 문제를 피했습니다.
레시피 3: 컨텍스트 윈도우 가장자리에서 프롬프트 사용 — 오버플로 없이 거의 전체 컨텍스트 윈도우를 사용합니다.
- 1예산을 계산하십시오: 컨텍스트 윈도우 크기 − 시스템 프롬프트 토큰 − 예상 출력 토큰 = 입력 + 기록에 사용 가능한 토큰.
- 2예: 128k 윈도우, 200토큰 시스템 프롬프트, 1k 출력 버퍼 = 126.8k 사용 가능한 토큰.
- 3전송 전에 PromptQuorum에서 확인하십시오: "이 입력에 몇 개의 토큰이 사용됩니까?"
- 4한계에 가까워지면 가장 오래된 순서를 잘라내거나 계속하기 전에 요약하십시오.
- 5이것은 한계에 무작위로 부딪히는 것이 아니라 의도적으로 한계 근처에서 작업하게 합니다.
레시피 4: 제한된 VRAM을 가진 로컬 LLM — 충돌 없이 로컬 모델을 효과적으로 실행합니다.
- 1모델의 VRAM에 맞는 보수적인 컨텍스트 윈도우(8k–16k)로 시작하십시오.
- 2PromptQuorum 설정에서 해당 윈도우 크기의 VRAM 요구사항을 확인하십시오.
- 3작업을 실행하십시오. 오버플로가 발생하면 대화를 요약하고 요약에서 다시 시작하십시오.
- 4한계에 가까워지지 않으면 컨텍스트 윈도우를 천천히 늘리고 다시 테스트하십시오.
- 5하드웨어와 작업에 맞는 모델의 "적절한 크기" 컨텍스트 윈도우를 찾으십시오.
컨텍스트 윈도우의 일반적인 실수
- "모델이 이전 모든 채팅을 기억합니다." 아닙니다. 모든 새 대화는 이전 채팅의 제로 컨텍스트로 시작합니다. 채팅 내에서도 교환이 컨텍스트 윈도우를 초과하면 사라집니다.
- "매 순서마다 동일한 긴 컨텍스트를 붙여넣겠습니다." 이것은 토큰을 낭비하고 도움이 되지 않습니다 — 모델은 여전히 300페이지를 효과적으로 추론할 수 없습니다. 대신 요약하고 요약을 참조하십시오.
- "다섯 가지 다른 프로젝트를 하나의 긴 대화에 혼합하겠습니다." 각 프로젝트가 토큰을 두고 경쟁합니다. 컨텍스트가 채워지면 세부사항이 잘립니다. 프로젝트별로 별도의 채팅을 사용하십시오.
- "AI가 추론을 잘 못합니다 — 온도나 top-p 때문인 것 같습니다." 그럴 수도 있습니다. 하지만 먼저 컨텍스트 윈도우를 확인하십시오. 모델이 원래 제약을 더 이상 보지 못한다면 매개변수 문제가 아닙니다; 누락된 정보입니다.
- "로컬 LLM에서 컨텍스트 윈도우를 최대화하겠습니다." 그러면 VRAM이 부족해지고 프로세스가 충돌하며 추론이 느린 CPU 모드로 폴백됩니다. 대신 하드웨어에 맞게 컨텍스트를 설정하십시오.
- "앱이 오버플로에 대해 경고했지만 어쨌든 전송했습니다." 경고를 신뢰하십시오. 오버플로는 자동 잘림, 숨겨진 환각, 낭비된 토큰으로 이어집니다. 먼저 요약하십시오.
프롬프트에서 컨텍스트 윈도우를 관리하는 방법
- 1모델의 컨텍스트 윈도우를 확인하십시오: GPT-5.6 = 128k 토큰, Claude Opus 4.8 = 200k 토큰, Gemini 3.1 Pro = 2M 토큰. 로컬 모델은 다양합니다(일반적으로 4k–128k). 시작하기 전에 한계를 파악하십시오.
- 2시스템 프롬프트에 중요한 지시사항을 먼저 배치하십시오: 협상 불가능한 제약사항과 역할 정의를 먼저 배치하십시오. 순서가 컨텍스트에서 벗어나면 20턴 후에 묻힌 지시사항은 모델에 보이지 않습니다.
- 3계속하기 전에 긴 대화를 요약하십시오: 10~15회 교환마다 모델에게 "지금까지 내린 가장 중요한 5가지 결정은 무엇입니까?"라고 물어보십시오. 그런 다음 분산된 이전 메시지에 의존하는 대신 그 요약을 다음 순서의 컨텍스트로 사용하십시오.
- 4긴 문서는 전체가 아니라 섹션 단위로 처리하십시오: 100페이지 보고서를 챕터로 나누십시오. 챕터별로 집중된 질문을 하고 마지막에 요약을 결합하십시오. 이렇게 하면 "책 속에서 길을 잃는" 컨텍스트 혼란을 방지할 수 있습니다.
- 5전송 전에 컨텍스트 오버플로를 모니터링하십시오: PromptQuorum을 사용하거나 수동으로 계산하십시오: (사용 가능한 컨텍스트) − (시스템 프롬프트 토큰) − (예상 출력 토큰) = (최대 입력 토큰). 이 예산 내에서 유지하십시오.
- 6로컬 LLM의 경우 VRAM에 맞게 컨텍스트 윈도우 크기를 조정하십시오: 컨텍스트 윈도우 크기는 KV 캐시 VRAM 증가를 좌우합니다. 7B(Q4_K_M) 모델은 32k 컨텍스트에서 약 8~10GB, 128k에서 약 12~14GB를 사용합니다. 모든 것을 최대화하는 대신 하드웨어 한계를 테스트하십시오.
자주 묻는 질문
모델이 이전 채팅을 기억합니까?
아닙니다. 모든 새 대화 세션은 제로 기록으로 시작합니다. 모델은 현재 컨텍스트 윈도우 내의 토큰만 봅니다. 이전 채팅을 참조하려면 현재 대화에 관련 부분을 복사해야 합니다.
AI가 20개 메시지 전에 제가 준 지시사항을 왜 무시했습니까?
그 지시사항이 컨텍스트 윈도우에서 벗어났을 가능성이 높습니다. 모델이 더 이상 보지 못하므로 따를 수 없습니다. 해결책: 시스템 프롬프트에서 중요한 지시사항을 반복하거나 대화 중간에 모델에게 지시사항을 요약하고 재삽입하도록 요청하십시오.
더 큰 컨텍스트 윈도우가 항상 더 낫습니까?
아닙니다. 더 큰 윈도우는 더 많은 콘텐츠를 포함할 수 있지만, 비용(처리할 토큰이 더 많음)도 증가하고, 로컬 모델의 경우 VRAM 사용량도 증가합니다. 작업에 맞는 컨텍스트 윈도우를 선택하십시오: 간단한 Q&A에는 4k, 긴 대화에는 32k, 문서 분석에는 128k+. 크다는 것이 "더 나은" 것이 아닙니다 — *적절한* 것이 더 낫습니다.
컨텍스트 한계에 도달했을 때 어떻게 알 수 있습니까?
모델의 응답이 어조를 바꾸거나, 이전 지시사항과 모순되거나, 이전에 설정한 세부사항을 추적하지 못합니다. 전송 전에 PromptQuorum의 컨텍스트 오버플로 검사를 사용하십시오 — 한계에 가까워질 때 경고합니다.
컨텍스트 윈도우 크기가 로컬 모델의 VRAM에 어떤 영향을 미칩니까?
7B (Q4_K_M) 모델은 4k 컨텍스트에서 ~5 GB VRAM, 32k 컨텍스트에서 ~8–10 GB, 128k 컨텍스트에서 ~12–14 GB가 필요합니다. 증가는 엄격하게 선형적이지 않습니다. 하드웨어 한계를 알려면 PromptQuorum의 VRAM 계산기를 확인하십시오.
PromptQuorum 같은 도구가 컨텍스트 오버플로를 방지할 수 있습니까?
예. PromptQuorum은 프롬프트의 토큰 수, 구성된 컨텍스트 윈도우, 모델의 실제 한계를 확인한 다음 오버플로가 예상되면 전송 전에 경고합니다. 그런 다음 계속하기 전에 잘라내거나 요약할 수 있습니다.
다른 모델이 긴 컨텍스트를 다르게 처리합니까?
예. Claude Opus 4.8은 200k 토큰에 걸쳐 집중력을 잘 유지합니다. GPT-5.5는 128k에서 안정적입니다. 더 작은 모델(예: LLaMA 3.1 7B)은 컨텍스트 윈도우가 기술적으로 더 크더라도 8k–16k 이상에서 추론 일관성을 잃는 경우가 있습니다. 가장 안전한 접근 방식: 특정 모델과 작업을 테스트하십시오.
컨텍스트 윈도우와 모델 메모리의 차이점은 무엇입니까?
컨텍스트 윈도우는 모델이 각 추론에서 읽는 활성 토큰 버퍼입니다 — 현재 대화를 담고 있습니다. 모델 메모리(가중치)는 훈련 후 고정되어 일반 언어 패턴을 담고 있습니다. 컨텍스트 윈도우는 모델이 하나의 응답에서 참조할 수 있는 것을 확장합니다; 모델 가중치는 런타임에 변경할 수 없습니다.
관련 읽기
- 모든 프롬프트에 필요한 5가지 구성 요소 — 컨텍스트가 제약이 되기 전에 프롬프트를 구성하는 방법
- AI 환각: AI가 사실을 꾸며내는 이유 — 컨텍스트 누락이 환각 위험을 증가시키는 이유
- RAG 설명: AI 답변을 실제 데이터에 근거시키는 방법 — 원시 컨텍스트 대신 검색으로 대규모 문서 세트를 처리하는 방법
출처
- OpenAI, 2026. "API reference: Models and context windows" — 모델별 토큰 한계 및 가격 책정에 관한 공식 문서
- Anthropic, 2026. "Claude model context windows and token costs" — Claude Opus 4.8 200k 컨텍스트 윈도우 및 현재 모델 문서
- Raffel et al., 2020. "Exploring the Limits of Transfer Learning with a Unified Text-to-Text Transformer" — 트랜스포머의 컨텍스트 윈도우 효과에 관한 기초 연구