시리즈: 생성형 AI 플랫폼 비교 완전 가이드 (총 9편) | 5회
1M 컨텍스트의 진짜 의미 — 장문 처리, 파일 업로드, 메모리 완전 비교
Summary
- 1M 토큰 컨텍스트는 "문서 처리 능력"이 아니라 "워크플로 설계 비용"을 바꾸는 것이다
- 컨텍스트 윈도우와 파일 업로드/보관 한도는 별개의 병목이므로 구분해서 봐야 한다
- 1M에 전부 넣으면 편하지만, 비용/지연/타임아웃 리스크도 함께 커진다
- 실무 최적은 1M으로 전체 조망 + RAG로 근거 보강하는 하이브리드 전략이다
이 글의 대상
- 긴 보고서나 논문을 AI로 요약/분석하려는 분
- "컨텍스트 윈도우"가 뭔지, 왜 중요한지 알고 싶은 분
- 여러 문서를 동시에 다루는 업무를 AI로 효율화하려는 분
- API로 장문 처리 파이프라인을 설계하는 개발자
목차
- 컨텍스트 윈도우란 무엇인가
- 플랫폼별 컨텍스트 윈도우 비교
- 컨텍스트와 파일 업로드는 다른 병목이다
- 1M 토큰의 진짜 가치
- 1M 토큰의 함정
- 하이브리드 전략 — 1M + RAG 조합
- 장문 관리 메커니즘 비교
- 시나리오별 플랫폼 추천
1. 컨텍스트 윈도우란 무엇인가
여러분, AI에게 한 번에 전달할 수 있는 텍스트의 최대 크기를 컨텍스트 윈도우라고 해요. 쉽게 말하면, AI의 "작업 메모리" 용량이에요.
책상 위 작업 공간을 생각해보세요. 책상이 넓으면 여러 문서를 동시에 펼쳐놓고 비교할 수 있죠. 좁으면 하나씩 꺼내서 봐야 하고요. 컨텍스트 윈도우가 큰 AI는 넓은 책상을 가진 셈이에요.
1M(100만) 토큰은 대략 한국어 기준 50만~75만 자, 영어 기준 75만 단어 정도예요. 일반적인 책 한 권이 10
15만 자 정도니까, 책 5
7권 분량을 한 번에 올려놓을 수 있다는 뜻이에요.
2. 플랫폼별 컨텍스트 윈도우 비교
각 플랫폼이 제공하는 컨텍스트 윈도우 크기가 상당히 달라요.
| 플랫폼 | 모델/플랜 | 컨텍스트 윈도우 | 비고 |
|---|---|---|---|
| Gemini | 1.5 Pro / 2.0 | 1M+ 토큰 | 앱에서는 플랜별 32K~1M 차등 적용 |
| Claude | Opus 4.6 | 200K (기본), 1M (베타) | compaction으로 긴 대화 관리 |
| ChatGPT | GPT-4o / o3 | 128K (API), 32K~196K (모드/티어별) | GPT-4o mini API 128K |
| Perplexity | 다양한 내부 모델 | 비공개 (제한적) | 검색 특화, 장문 처리는 약함 |
| Copilot | GPT-4o 기반 | 128K (추정) | Microsoft 365 연동 중심 |
눈에 띄는 건 Gemini와 Claude가 1M 토큰급을 제공하거나 확장 중이라는 점이에요. 반면 ChatGPT는 아직 128~196K 수준에 머물러 있어요.
3. 컨텍스트와 파일 업로드는 다른 병목이다
여기서 많은 분이 헷갈리는 부분이 있어요. "컨텍스트 윈도우가 크다"와 "파일을 많이 올릴 수 있다"는 같은 말이 아니에요.
파일 업로드/보관 한도
| 플랫폼 | 단일 파일 크기 | 텍스트 파일 토큰 한도 | 사용자 총 저장 용량 |
|---|---|---|---|
| OpenAI (ChatGPT) | 512MB/파일 | 텍스트 2M 토큰/파일 | 사용자당 10GB |
| Perplexity | 40MB/파일 | 제한적 | 별도 저장 없음 |
| Gemini | Google Drive 연동 | 플랜별 차등 | Google One 용량 |
| Claude | 프로젝트별 파일 업로드 | 200K~1M 토큰 범위 | 프로젝트 단위 관리 |
예를 들어 OpenAI는 512MB짜리 파일도 올릴 수 있지만, 그 파일의 내용 전체가 컨텍스트에 들어가는 건 아니에요. 파일은 "보관"되고, AI는 그 중 필요한 부분만 컨텍스트에 가져와서 처리하는 방식이에요.
반대로 Gemini는 컨텍스트 윈도우 자체가 1M이라서, 문서 전체를 컨텍스트에 넣어버리는 접근이 가능해요. 이 차이가 워크플로를 완전히 바꿔요.
4. 1M 토큰의 진짜 가치
1M 컨텍스트의 핵심 가치는 단순히 "많이 넣을 수 있다"가 아니에요. 청크 분할과 RAG 설계의 부담을 줄여준다는 데 있어요.
기존 방식 (작은 컨텍스트)
긴 문서를 처리하려면:
- 문서를 작은 조각(청크)으로 분할
- 각 청크를 벡터 임베딩으로 변환
- 질문과 관련 있는 청크만 검색(RAG)
- 검색된 청크를 컨텍스트에 넣어서 질의
이 과정에서 청크 경계에서 맥락이 잘리는 문제, 관련 없는 청크가 검색되는 문제 등이 발생해요.
1M 방식
문서 전체를 한 번에 넣고 바로 질문해요. 끝.
- 전체 문맥을 보존한 상태로 구조화 요약이 가능
- 문서 곳곳에 흩어진 정보를 교차 참조할 수 있음
- 청크 분할/RAG 파이프라인 구축 비용이 사라짐
이건 특히 "이 계약서 전체에서 위험 조항을 찾아줘", "이 논문의 방법론과 결론이 일관성 있는지 검토해줘" 같은 작업에서 큰 차이를 만들어요.
5. 1M 토큰의 함정
물론 1M에 전부 넣는 게 항상 좋은 건 아니에요. 알아둬야 할 현실적인 제약이 있어요.
비용 증가
API 기준으로, 입력 토큰에 비례해서 비용이 올라가요. 100만 토큰을 매번 넣으면 한 번 질의에 수 달러가 나갈 수 있어요. 같은 문서에 대해 반복 질의하면 비용이 눈덩이처럼 불어나요.
지연 증가
컨텍스트가 크면 TTFT(첫 토큰까지의 시간)도 길어져요. 4편에서 다뤘던 것처럼, 이 지연은 사용자 경험을 직접 해쳐요.
실패/타임아웃 리스크
1M 토큰 요청은 서버 리소스를 많이 사용하기 때문에, 피크 시간대에 타임아웃이 발생할 확률이 높아져요. "거의 다 됐는데 실패"하는 상황은 짧은 요청에서는 잘 안 생기지만, 대용량 요청에서는 현실적인 문제예요.
"많이 넣으면 잘 찾을까?" — Needle in a Haystack 문제
컨텍스트가 아무리 커도, AI가 그 안에서 특정 정보를 정확히 찾는 능력은 완벽하지 않아요. 특히 컨텍스트 중간에 있는 정보는 앞뒤에 있는 정보보다 놓칠 확률이 높다는 연구 결과도 있어요.
6. 하이브리드 전략 — 1M + RAG 조합
그래서 실무에서 가장 효과적인 접근은 하이브리드예요.
1단계: 1M으로 전체 조망
전체 문서를 한 번에 넣어서:
- 핵심 구조 파악
- 목차/요약 생성
- 주요 논점 식별
2단계: RAG로 근거 보강 및 반복 질의
1단계에서 파악한 구조를 바탕으로:
- 특정 섹션에 대한 심층 질의
- 인용 근거가 필요한 작업
- 반복적인 질의응답 (비용 절감)
이렇게 하면 1M의 장점(전체 맥락 보존)과 RAG의 장점(비용 효율, 정확한 근거 추출)을 모두 가져갈 수 있어요.
7. 장문 관리 메커니즘 비교
각 플랫폼이 장문/긴 대화를 관리하는 방식이 달라요. 이 차이가 실제 사용 경험에 큰 영향을 줘요.
| 플랫폼 | 장문 관리 메커니즘 | 특징 |
|---|---|---|
| Gemini | 컨텍스트 캐싱 | 같은 문서에 반복 질의 시 비용/지연 절감. 캐시된 컨텍스트를 재사용 |
| Claude | Compaction + 선택적 메모리 | 긴 대화에서 오래된 내용을 자동 압축. 중요 정보는 선택적으로 유지 |
| ChatGPT (OpenAI) | 파일 저장 + 프로젝트 | 파일을 사용자 공간에 보관하고, 필요 시 참조. 프로젝트 단위 관리 |
| Perplexity | 검색 기반 | 자체 컨텍스트보다 웹 검색 결과에 의존. 장문 처리는 약함 |
Gemini 컨텍스트 캐싱
같은 100만 토큰 문서에 대해 5번 질문한다고 가정해보세요. 캐싱 없이는 매번 100만 토큰을 보내야 해요. Gemini의 컨텍스트 캐싱은 첫 번째만 전체를 보내고, 이후에는 캐시에서 가져와서 비용과 지연을 대폭 줄여줘요.
Claude Compaction
Claude는 대화가 길어지면 이전 내용을 자동으로 "압축"해요. 10번째 메시지를 보낼 때, 1~5번째 메시지의 핵심만 요약해서 유지하는 방식이에요. 덕분에 컨텍스트 한도를 넘기지 않으면서도 이전 맥락을 어느 정도 기억할 수 있죠.
OpenAI 파일 저장
ChatGPT는 파일을 사용자 공간에 "보관"하는 접근이에요. 대화가 끝나도 파일이 남아있고, 다른 대화에서도 참조할 수 있어요. 컨텍스트 윈도우 자체는 작지만, 파일 저장이라는 다른 차원의 해법을 제공하는 셈이에요.
8. 시나리오별 플랫폼 추천
어떤 작업을 하느냐에 따라 최적의 선택이 달라져요.
긴 보고서/계약서 요약
| 순위 | 플랫폼 | 이유 |
|---|---|---|
| 1 | Gemini / Claude | 1M 컨텍스트로 전체를 한 번에 처리 가능 |
| 2 | ChatGPT (OpenAI) | 파일 업로드 후 부분 처리, 컨텍스트 한도 제약 |
| 3 | Perplexity | 40MB 파일 한도, 장문 처리 특화가 아님 |
논문/교재 학습 (반복 질의)
| 순위 | 플랫폼 | 이유 |
|---|---|---|
| 1 | Claude | 세션 지속 + compaction으로 장기 학습 대화에 강점 |
| 2 | ChatGPT | 프로젝트/파일 기능으로 문서 보관 + 반복 참조 |
| 3 | Gemini | 컨텍스트 캐싱으로 반복 질의 비용 절감 |
여러 문서 교차 정리
이건 상황에 따라 달라져요:
- 공개 웹 정보 교차 정리: Perplexity (검색 + 출처 제시 강점)
- 내부 파일 여러 개 비교: ChatGPT (파일 보관 + 프로젝트)
- 기업 환경 문서 관리: Copilot (Microsoft 365 연동)
- 대용량 문서 통째 비교: Gemini (1M 컨텍스트에 여러 문서 동시 투입)
핵심 정리
1. 1M 컨텍스트는 "용량"이 아니라 "워크플로 설계 비용"을 바꾸는 기능이다
2. 컨텍스트 윈도우 ≠ 파일 업로드 한도 — 두 가지 병목을 구분하라
3. 1M에 전부 넣으면 편하지만, 비용·지연·타임아웃 리스크도 커진다
4. 실무 최적: 1M으로 전체 조망 → RAG로 근거 보강/반복 질의
5. 시나리오에 따라 최적 플랫폼이 다르다 — 요약은 Gemini/Claude, 학습은 Claude, 교차 정리는 상황별FAQ
Q1. 컨텍스트 윈도우와 메모리는 같은 건가요?
A. 비슷하지만 달라요. 컨텍스트 윈도우는 "한 번의 대화에서 AI가 볼 수 있는 텍스트의 최대량"이고, 메모리는 "대화 간에 정보를 기억하는 기능"이에요. 컨텍스트 윈도우가 큰 것과 이전 대화를 기억하는 것은 별개예요.
Q2. 1M 토큰이면 한국어로 얼마나 되나요?
A. 대략 한국어 50만
75만 자 정도예요. 일반적인 A4 기준(1,500자/페이지)으로 약 330
500페이지, 책으로 치면 5~7권 분량이에요.
Q3. 왜 ChatGPT는 컨텍스트 윈도우를 더 안 늘리나요?
A. 컨텍스트 윈도우를 늘리면 연산 비용이 기하급수적으로 증가해요. OpenAI는 파일 저장/프로젝트 기능 같은 다른 방식으로 장문 처리 문제를 우회하는 전략을 택하고 있어요. 각 플랫폼의 기술적 철학 차이라고 볼 수 있어요.
Q4. RAG가 뭔가요?
A. Retrieval-Augmented Generation의 약자로, 쉽게 말하면 "필요한 정보를 검색해서 AI에게 넘겨주는 방식"이에요. 전체 문서를 넣는 대신, 질문과 관련 있는 부분만 찾아서 넣어주는 거예요. 비용과 속도 면에서 효율적이지만, 검색이 잘못되면 엉뚱한 답이 나올 수 있어요.
Q5. Gemini 컨텍스트 캐싱은 유료인가요?
A. API에서 컨텍스트 캐싱을 사용하면 캐시 저장 비용이 별도로 발생하지만, 반복 질의 시 입력 토큰 비용이 대폭 줄어들어서 총 비용은 오히려 절감돼요. 같은 문서에 3번 이상 질의한다면 캐싱이 이득이에요.
Q6. Claude compaction은 정보를 잃지 않나요?
A. 완전하지는 않아요. 압축 과정에서 세부 정보가 생략될 수 있어요. 중요한 정보는 명시적으로 "이건 기억해줘"라고 말하거나, 프로젝트 지식(Project Knowledge)에 고정해두는 게 안전해요.
Q7. 1M 컨텍스트에 이미지나 PDF도 넣을 수 있나요?
A. 네, Gemini와 Claude 모두 이미지와 PDF를 컨텍스트에 포함할 수 있어요. 다만 이미지는 텍스트보다 토큰을 많이 소모해요. 고해상도 이미지 한 장이 수백~수천 토큰을 차지할 수 있으니, 이미지가 많으면 실질적으로 넣을 수 있는 텍스트 양이 줄어들어요.
Q8. 파일을 올리면 AI가 학습에 사용하나요?
A. 플랫폼마다 정책이 달라요. 대부분의 유료 플랜과 API는 사용자 데이터를 모델 훈련에 사용하지 않겠다고 명시하고 있어요. 하지만 민감한 내부 문서라면 반드시 각 플랫폼의 데이터 정책을 확인하고, 가능하면 API를 통한 접근이 더 안전해요.
참고 자료 (References)
데이터 출처
| 출처 | 설명 | 링크 |
|---|---|---|
| Google AI Blog | Gemini 1M+ 컨텍스트 윈도우 및 캐싱 기술 | blog.google/technology/ai |
| Anthropic Docs | Claude 컨텍스트 윈도우, compaction, 프로젝트 지식 | docs.anthropic.com |
| OpenAI Help Center | ChatGPT 파일 업로드 한도 및 저장 정책 | help.openai.com |
| Perplexity FAQ | 파일 업로드 제한 및 지원 형식 | perplexity.ai |
| Microsoft Copilot 문서 | M365 Copilot 기능 및 RAG 기반 문서 활용 | learn.microsoft.com |
핵심 인용
"Long context is not just about fitting more text — it's about eliminating the engineering complexity of chunking, retrieval, and context management."
-- Google DeepMind, Gemini Technical Report
다음 편 예고
[6편] 도구, 에이전트, 자동화 — 플랫폼별 철학이 이렇게 다르다
- 함수호출 패러다임은 수렴했지만 구현 철학은 완전히 다르다
- 이메일/캘린더 자동화에서 "읽기"와 "쓰기"의 차이가 만드는 현실
- 보고서 파이프라인, 이메일 자동화, 리서치 요약 — 유즈케이스별 최적 조합