LLM 컨텍스트 윈도우(Context Window)란 무엇인가? (실제 환각(Hallucination) 사례를 통한 설명)
요약
LLM의 단기 기억 역할을 하는 컨텍스트 윈도우의 개념과 토큰 단위 측정 방식을 설명합니다. 컨텍스트 제한이 어떻게 정보 망각과 환각(Hallucination)을 유발하는지 구체적인 사례를 통해 다룹니다.
핵심 포인트
- 컨텍스트 윈도우는 모델이 한 번에 처리할 수 있는 토큰의 총량임
- 정보가 윈도우 범위를 벗어나면 모델은 이전 지시사항을 망각함
- 긴 문맥의 중간에 위치한 정보를 놓치는 'Lost in the Middle' 현상 존재
- 컨텍스트 윈도우 크기 증가가 환각 문제를 완전히 해결하지는 않음
만약 ChatGPT나 Claude를 사용하면서 긴 대화 도중 이전에 했던 말을 "잊어버리거나", 사실이 아닌 내용을 자신 있게 지어내는 것을 경험해 본 적이 있다면 — 당신은 컨텍스트 윈도우(context window) 문제에 직면한 것입니다.
이것이 실제로 무엇인지, 왜 존재하는지, 그리고 어떻게 환각(hallucination)을 직접적으로 유발하는지 자세히 살펴보겠습니다.
컨텍스트 윈도우(Context Window)란 무엇인가?
컨텍스트 윈도우(context window)는 LLM이 한 번에 "보고" 추론할 수 있는 텍스트의 양을 의미합니다. 이를 모델의 단기 기억(short-term memory) 또는 모델의 책상 공간이라고 생각하면 쉽습니다.
모델이 응답을 생성하는 데 사용하는 모든 것 — 시스템 프롬프트(system prompt), 채팅 기록(chat history), 업로드된 문서, 그리고 모델 자신의 이전 답변들 — 은 모두 그 책상 위에 올라가 있어야 합니다. 일단 책상이 가득 차면, 오래된 것들은 가장자리 밖으로 떨어져 나갑니다. 모델은 더 이상 그것을 볼 수 없게 됩니다.
컨텍스트 윈도우는 단어가 아닌 토큰(Tokens)으로 측정됩니다
LLM은 단어로 읽지 않습니다 — 대신 토큰(tokens), 즉 텍스트의 작은 조각(영어 기준으로 대략 단어의 3/4 정도) 단위로 읽습니다.
- "Hallucination"은 3~4개의 토큰이 될 수 있습니다.
- 1,000단어 분량의 기사는 대략 1,300~1,500개의 토큰입니다.
따라서 "128K 컨텍스트 윈도우" 또는 "1M 컨텍스트 윈도우"라는 말을 듣는다면, 이는 입력(input)과 출력(output)을 합쳐서 모델이 보유할 수 있는 총 토큰 수를 의미합니다.
| 모델 시대 | 일반적인 컨텍스트 윈도우 |
|---|---|
| 초기 GPT-3 (2020) | ~2K 토큰 (몇 페이지 분량) |
| ... |
윈도우가 커질수록 모델은 전체 코드베이스(codebase), 책, 또는 긴 대화를 한 번에 시야에 담을 수 있습니다. 하지만 크기만으로는 환각(hallucination)을 해결할 수 없습니다. 때로는 환각이 사라지는 것이 아니라, 환각의 유형이 달라질 뿐입니다.
그렇다면 이것이 환각(Hallucinations)과 무슨 상관인가요?
환각(hallucination)은 모델이 거짓이거나 지어낸 내용을 마치 사실인 것처럼 말하는 것을 의미합니다. 컨텍스트 윈도우의 제한은 이것을 일으키는 가장 크고 예측 가능한 원인 중 하나입니다. 그 방식은 다음과 같습니다.
예시 1: 전형적인 "망각"형 환각
당신은 긴 대화를 나누고 있습니다. 대화 초반에 당신은 이렇게 말했습니다:
"내 프로젝트는 Python 3.9를 사용하며, 외부 라이브러리는 허용되지 않습니다."
50개의 메시지가 지난 후, 당신은 버그 수정을 도와달라고 요청합니다. 모델은 requests 라이브러리를 사용하라고 제안합니다.
발생한 현상: 당신의 제약 사항이 컨텍스트 윈도우 (Context Window) 밖으로 밀려난 것입니다. 모델이 부주의한 것이 아니라, 말 그대로 해당 지시 사항을 더 이상 볼 수 없게 된 것입니다. 그래서 모델은 그 빈자리를 "합리적인" 기본 답변으로 채워 넣습니다. 이것은 지식의 공백이 아니라, 손실된 컨텍스트 (Context)로 인해 발생하는 환각 (Hallucination)입니다.
예시 2: "중간에서의 상실 (Lost in the Middle)"
긴 컨텍스트 (Long-context) 모델에 대한 연구는 반복적으로 직관에 반하는 사실을 발견했습니다. 모델은 컨텍스트 윈도우의 시작과 끝 부분에 있는 정보를 회상하는 데 가장 능숙하며, 기술적으로 모든 내용이 포함되어 있음에도 불구하고 중간에 묻혀 있는 정보를 회상하는 데는 더 서툽니다.
예시: 당신이 50페이지 분량의 계약서를 붙여넣고 "해지 조항이 무엇인가요?"라고 묻습니다. 만약 그 조항이 27페이지에 있다면, 모델은 해지 조항에 대해 자신 있게 설명할 수도 있지만, 그것은 실제 조항이 아닐 수 있습니다. 모델이 거짓말을 하는 것이 아니라, 약해진 신호로부터 그럴듯하게 들리는 답변을 재구성하는 것입니다.
예시 3: 요약을 통한 컨텍스트 오버플로 (Context Overflow)
일부 도구들은 공간을 확보하기 위해 대화의 오래된 부분을 사용자 모르게 요약하거나 잘라내는 방식으로 "너무 많은 텍스트"를 처리합니다. 이는 사용자에게는 보이지 않는 과정입니다.
예시: 당신이 코딩 어시스턴트에게 200개의 메시지 이전에 정의한 함수를 리팩토링(Refactor)해달라고 요청합니다. 시스템은 해당 채팅 부분을 "사용자가 헬퍼 함수를 정의함"이라는 한 줄로 조용히 요약해 버렸습니다. 이제 어시스턴트는 그 함수가 어떻게 생겼는지 _추측_해야 하며, 그 과정에서 그럴듯하지만 틀린 매개변수 (Parameter) 이름을 만들어냅니다.
예시 4: 대규모 컨텍스트에서의 문서 간 혼동
거대한 컨텍스트 윈도우를 가지고 있더라도, 유사한 문서들을 많이 집어넣으면 (예: 10개의 이력서, 또는 유사한 라이브러리의 API 문서 5개) 모델이 문서 간의 세부 사항을 섞어버릴 수 있습니다.
예시: 당신이 두 개의 유사한 REST API 문서를 업로드하고 특정 엔드포인트 (Endpoint)에 대해 묻습니다. 모델은 두 API의 필드들을 혼합하여 답변하는데, 이는 어느 문서에도 존재하지 않는 환각된 하이브리드 결과물입니다. 여기서는 더 많은 컨텍스트가 도움이 되지 않았으며, 오히려 혼란을 줄 재료를 더 추가한 꼴이 되었습니다.
이것이 개발자에게 중요한 이유
만약 여러분이 LLM(대규모 언어 모델)을 활용하여 챗봇, RAG(검색 증강 생성 (Retrieval-Augmented Generation)) 애플리케이션, 코딩 어시스턴트 등을 구축하고 있다면, 컨텍스트 윈도우 (Context Window)는 단순히 배경적인 세부 사항이 아닙니다. 이는 신뢰성을 직접적으로 결정짓는 요소입니다. 몇 가지 실질적인 교훈은 다음과 같습니다:
- "모델이 기억할 것"이라고 가정하지 마세요. 긴 대화에서는 초반의 세부 사항들이 소리 없이 유실됩니다. 중요한 제약 사항은 주기적으로 반복해 주세요.
- 위치가 중요합니다. 프롬프트에 문서를 채워 넣는 경우, 가장 중요한 콘텐츠를 중간에 묻어두지 말고 시작 부분이나 끝 부분에 배치하세요.
- 크다고 해서 무조건 더 좋은 것은 아닙니다. 1M(100만) 토큰 윈도우라고 해서 모델이 그 전체 범위에서 동일하게 뛰어난 추론 능력을 보여준다는 의미는 아닙니다.
- 모든 것을 쏟아붓는 대신 검색 (RAG)을 사용하세요. 지식 베이스 전체를 붙여넣는 대신, 각 쿼리에 해당하는 관련 청크 (Chunks)만 검색하여 가져오세요. 노이즈가 줄어들면 혼란도 줄어들고, 환각 (Hallucination)도 줄어듭니다.
- 소리 없는 절단 (Truncation)을 주의하세요. 도구가 대화 기록을 요약할 때 이를 알려주지 않는다면, 긴 세션이 진행되는 동안 요약이 일어나고 있다고 가정해야 합니다.
요약
컨텍스트 윈도우는 토큰 (Tokens) 단위로 측정되는 모델의 작업 기억 (Working Memory)입니다. 정보가 이 범위를 벗어나거나 범위 내에서 묻혀버리면, 모델은 "모르겠습니다"라고 말하는 대신 그 공백을 그럴듯한 무언가로 채워 넣습니다. 그것이 바로 환각 (Hallucination)이며, 컨텍스트 윈도우를 이해하는 것이 이를 예측하고 방지하기 위한 첫 번째 단계입니다.
이 내용이 유익했다면, 핵심 AI/LLM 개념에 대한 초보자 친화적인 설명을 더 보기 위해 팔로우해 주세요.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기