12. 컨텍스트 윈도우란 무엇인가

3부는 1부에서 깔아둔 "attention은 유한하다"는 직관이 본격적으로 펼쳐지는 곳입니다. 2부가 어떻게 말할지였다면, 3부는 무엇을 보게 할지입니다. 코드 없이도 따라올 수 있게 썼고, 개발자 심화는 🔧로 분리했습니다.

컨텍스트 윈도우란

2장에서 "모델의 세계는 지금 컨텍스트에 든 것이 전부"라고 했습니다. 그 컨텍스트가 담기는 그릇이 컨텍스트 윈도우(context window)입니다. 모델이 한 번의 응답을 만들 때 볼 수 있는 텍스트의 최대 분량이며, 토큰(2장) 단위로 셉니다.

비유하자면 작업용 책상입니다. 책상이 넓으면 더 많은 자료를 펼쳐놓을 수 있지만, 책상이 아무리 넓어도 무엇을 올려놓느냐가 작업의 질을 결정합니다. 관련 없는 서류로 책상을 가득 채우면, 정작 중요한 자료가 묻힙니다.

📌 핵심: 컨텍스트 윈도우는 모델이 한 번에 "볼 수 있는" 양의 상한입니다. 그 상한은 용량이지 효과가 아닙니다.

윈도우 안에서 모든 것이 경쟁한다

이 그릇 안에는 당신이 타이핑한 질문만 들어가는 게 아닙니다. 3장에서 봤듯 여러 요소가 함께 들어가 같은 공간을 나눠 씁니다.

flowchart TB
    subgraph WIN["컨텍스트 윈도우 (유한한 그릇)"]
        sys["시스템 프롬프트"]
        hist["이전 대화 기록"]
        docs["붙여넣은 자료"]
        tools["도구·검색 결과"]
        usr["이번 질문"]
        out["생성될 출력 공간"]
    end

    note["모두 같은 한도를 나눠 쓴다<br/>= 하나가 커지면 다른 것의 자리가 줄어든다"]
    WIN -.-> note

    classDef ctx fill:#ede9fe,stroke:#8b5cf6,color:#4c1d95
    classDef prompt fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
    classDef out fill:#dcfce7,stroke:#22c55e,color:#14532d
    classDef warn fill:#fee2e2,stroke:#ef4444,color:#7f1d1d
    class sys,hist,docs,tools ctx
    class usr prompt
    class out out
    class note warn

중요한 결과: 출력도 같은 윈도우를 씁니다. 입력으로 그릇을 거의 다 채우면, 모델이 답을 쓸 공간이 부족해집니다. 그래서 "긴 자료 + 긴 답"을 동시에 원하면 윈도우 한계에 부딪힐 수 있습니다.

💡 팁: 대화가 길어질수록 이전 기록이 윈도우를 점점 잠식합니다. "왜 갈수록 모델이 앞 내용을 까먹지?"의 흔한 원인입니다(15장에서 상세히). 자리가 부족해지면 오래된 대화가 잘려 나가거나, 핵심이 묻혀 활용도가 떨어집니다.

용량은 커지는데, 왜 다 넣으면 안 되나

최신 모델의 컨텍스트 윈도우는 매우 커졌습니다(수십만~수백만 토큰대도 있습니다). 그러면 "이제 다 넣어도 되는 것 아닌가?"라는 생각이 자연스럽습니다. 하지만 1부에서 본 두 가지 이유로, 큰 용량이 곧 "다 넣어도 됨"을 뜻하지 않습니다.

이유 1: attention 예산은 유한하다. 4장에서 본 것처럼, 모델이 긴 컨텍스트의 모든 부분에 똑같이 주의를 기울이지 못합니다. 윈도우를 채울수록 주의가 묽어집니다. 한 제공자의 정리처럼, 좋은 컨텍스트 설계는 "원하는 결과를 끌어낼 고신호 토큰의 가장 작은 집합을 찾는 것"입니다.

이유 2: 무관한 내용은 능동적 방해물이다. 관련 없는 자료는 그냥 무시되는 게 아니라, 모델을 엉뚱한 방향으로 끌 수 있습니다(3장 컨텍스트 의존의 나쁜 면). 책상 위 무관한 서류가 집중을 흐트러뜨리듯이.

⚠️ 흔한 실수·미신: "컨텍스트 윈도우가 200만 토큰이니 책 한 권을 통째로 넣자"는 흔한 함정입니다. 용량 안에 들어간다고 모델이 그것을 균일하게 잘 활용한다는 뜻은 아닙니다. 실제로 일부 연구·실무 보고는 기술적 최대치보다 훨씬 못 미치는 지점부터 추론 품질이 떨어지기 시작한다고 말합니다. 용량과 효과를 혼동하지 마세요. (이 주제는 14장 "중간 소실"에서 깊이 다룹니다.)

토큰을 직관적으로 가늠하기

정확한 토큰 수를 외울 필요는 없지만, 대략의 감은 유용합니다.

⚠️ 흔한 실수·미신: "한국어는 영어와 토큰 수가 비슷하다"고 가정하면 어긋납니다. 한국어·일본어 등은 같은 의미라도 영어보다 더 많은 토큰을 쓰는 경향이 있습니다. 한국어 자료를 다룰 때는 체감보다 토큰이 더 든다고 보는 편이 안전합니다.

🔧 개발자 노트: API에서는 입력·출력 토큰이 모두 비용·지연·윈도우 한도에 반영됩니다. 토크나이저로 사전에 토큰 수를 재거나, 제공자가 주는 토큰 카운터를 쓰면 윈도우 초과를 예방할 수 있습니다. 또한 윈도우 한도와 별개로, 효과적 길이는 더 짧을 수 있으니(이유 1·2), 한도를 다 쓰는 설계는 피하세요. 긴 입력이 불가피하면 13~15장의 선별·요약·압축 기법을 적용합니다.

컨텍스트 엔지니어링의 출발 질문

이 모든 것이 한 가지 질문으로 모입니다.

"이 작업의 결과를 좌우할, 가장 작은 고신호 정보 집합은 무엇인가?"

이 질문이 3부 전체를 관통합니다. 13장은 "무엇을 넣고 뺄까", 14장은 "긴 컨텍스트에서 무엇이 묻히나", 15장은 "오래된 것을 어떻게 정리하나"를 다루는데, 전부 이 출발 질문의 변주입니다.

🧪 직접 검증법: 긴 자료를 넣어 답이 신통치 않을 때, 정반대로 시도해보세요 — 자료를 절반 이하로 줄여 핵심만 남기고 같은 질문을 해보는 겁니다. 짧은 버전이 더 나으면, 문제는 "정보 부족"이 아니라 "신호 희석"이었던 것입니다. 이 역방향 검증이 컨텍스트 엔지니어링의 출발점입니다.

이 장에서 배운 것

• 컨텍스트 윈도우는 모델이 한 번에 볼 수 있는 텍스트의 최대 분량으로, 토큰 단위로 센다. 작업용 책상에 비유된다.
• 시스템 프롬프트·대화 기록·자료·도구 결과·질문·출력이 모두 같은 윈도우를 나눠 쓴다. 출력 공간도 여기 포함된다.
• 용량이 커도 attention 예산은 유한하고, 무관한 내용은 능동적 방해물이 되므로 "다 넣어도 됨"이 아니다.
• 한국어는 영어보다 토큰을 더 쓰는 경향이 있어, 체감보다 분량이 크다고 보는 편이 안전하다.
• 컨텍스트 엔지니어링의 출발 질문은 "결과를 좌우할 가장 작은 고신호 정보 집합은 무엇인가"이다.

✍️ 확인 문제

1. "컨텍스트 윈도우가 크니까 회의록·이메일·메모를 전부 넣고 요약시키자"는 접근의 문제를, 이 장의 두 가지 이유(attention 예산, 무관 정보의 방해)로 설명해보세요.

1. 대화가 길어질수록 모델이 초반 내용을 놓치는 현상을, 이 장의 "윈도우 안 경쟁" 개념으로 설명해보세요.

1. (실습) 30페이지 제품 매뉴얼이 있고, 사용자 질문은 "환불 절차가 어떻게 되나요?"입니다. "출발 질문"에 따라, 윈도우에 무엇을 넣고 무엇을 뺄지 한 문단으로 전략을 적어보세요.

다음 → 13. 무엇을 넣고 무엇을 뺄까
이전 ← 11. 구분자와 구조화 · 목차