LLM을 쓰다 보면 “이 모델은 context window가 크다”라는 말을 자주 보게 됩니다. 그런데 막상 입문 단계에서는 이게 정확히 무엇을 뜻하는지, 왜 중요한지 감이 잘 안 올 수 있습니다.
context window는 아주 단순하게 말하면 모델이 한 번의 처리에서 참고할 수 있는 입력 범위입니다. 질문, 시스템 프롬프트, 이전 대화, 첨부 문서, 검색 결과까지 모두 이 범위 안에 들어갑니다.
이 글에서는 아래 내용을 정리합니다.
- context window가 무엇인지
- 토큰 제한이 왜 중요한지
- 긴 대화나 긴 문서에서 어떤 문제가 생기는지
- 실무에서 어떻게 다루는지
핵심은 context window가 크다고 무조건 좋은 것이 아니라, 모델이 어떤 정보를 얼마만큼 안정적으로 활용할 수 있는지가 더 중요하다는 점입니다.
Context window란 무엇인가
모델은 무한한 길이의 입력을 한 번에 처리하지 못합니다. 대신 일정 범위 안의 토큰만 보고 다음 출력을 생성합니다. 이 범위가 바로 context window입니다.
여기에는 보통 아래가 함께 들어갑니다.
- 시스템 프롬프트
- 사용자 질문
- 이전 대화 기록
- 검색으로 가져온 문서
- 도구 사용 결과
즉, context window는 단순히 “문서 몇 장까지 읽는다”가 아니라 모델이 현재 판단에 사용할 수 있는 작업 공간에 가깝습니다.
왜 중요한가
AI 앱이 복잡해질수록 모델에게 넣어야 하는 정보가 많아집니다.
예를 들면:
- 긴 문서 요약
- 여러 문서 비교
- 대화 히스토리가 긴 챗봇
- 코드베이스 일부를 함께 보는 코딩 도우미
이때 context window가 작으면 중요한 정보를 잘라내야 하고, 크면 더 많은 정보를 함께 넣을 수 있습니다.
큰 context window가 항상 답은 아닌 이유
입문자 입장에서 제일 헷갈리는 부분이 여기입니다. window가 크면 더 많은 정보를 넣을 수 있는 것은 맞습니다. 하지만 아래 문제가 여전히 생길 수 있습니다.
- 중요한 정보가 뒤로 밀려 눈에 덜 띌 수 있음
- 노이즈가 많아져 핵심 판단이 흐려질 수 있음
- 비용이 커질 수 있음
- 지연 시간이 늘어날 수 있음
즉, 많이 넣는 것과 잘 넣는 것은 다릅니다.
긴 대화에서 자주 생기는 문제
채팅형 서비스에서는 대화가 길어질수록 예전 맥락이 점점 뒤로 밀립니다. 그러면 모델이:
- 초반 제약 조건을 놓치거나
- 이미 말한 사실을 다시 묻거나
- 스타일 지시를 잊어버리거나
- 앞서 정한 결론과 다른 방향으로 흐를 수 있습니다
그래서 긴 대화에서는 모든 기록을 계속 붙이기보다 요약 메모리나 핵심 상태만 유지하는 방식이 자주 쓰입니다.
긴 문서에서는 어떻게 할까
문서가 너무 길면 한 번에 모두 넣기보다 나눠서 다루는 경우가 많습니다.
대표적인 방식은:
- chunking
- retrieval
- section별 요약
- 단계적 질문
즉, 큰 context window가 있어도 문서를 구조적으로 나눠 넣는 전략이 여전히 중요합니다.
RAG와 context window의 관계
RAG는 필요한 문서 조각만 골라 context에 넣어주는 방식입니다. 그래서 context window가 제한되어 있을 때 특히 중요합니다.
모든 문서를 한 번에 넣지 않고, 지금 질문에 필요한 부분만 가져오면:
- 비용을 줄이고
- 노이즈를 줄이고
- 정확성을 높일 수 있습니다
즉, context window와 RAG는 경쟁 관계라기보다 함께 쓰이는 경우가 많습니다.
자주 하는 오해
1. context window가 크면 모델이 모든 걸 완벽히 기억한다
아닙니다. 들어갈 수 있는 양과 실제로 잘 활용하는 능력은 다릅니다.
2. 긴 문서는 무조건 한 번에 다 넣는 게 좋다
오히려 중요한 정보가 묻힐 수 있습니다.
3. context window 문제는 최신 모델로만 해결된다
모델 선택도 중요하지만, chunking과 retrieval 같은 설계가 훨씬 더 큰 차이를 만드는 경우가 많습니다.
FAQ
Q. context window는 메모리와 같은 뜻인가
완전히 같지는 않습니다. 현재 처리에 사용할 수 있는 입력 범위에 더 가깝습니다.
Q. window가 큰 모델이 항상 더 비싼가
대체로 입력량이 늘면 비용과 지연이 커질 수 있습니다. 실제 운영에서는 품질과 비용을 같이 봐야 합니다.
Q. 긴 문서를 다루려면 무조건 큰 window가 필요할까
꼭 그렇지는 않습니다. 적절한 검색과 분할 전략만으로도 충분히 좋은 결과를 낼 수 있습니다.
Read Next
- 검색 기반으로 필요한 문서만 가져오는 구조는 RAG 가이드와 이어집니다.
- 모델 비교 관점에서는 LLM 벤치마크 가이드도 함께 읽어보면 좋습니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.
먼저 읽어볼 가이드
검색 유입이 많은 핵심 글부터 이어서 보세요.
- 미들웨어 트러블슈팅 가이드: Redis vs RabbitMQ vs Kafka 개발자를 위한 미들웨어 트러블슈팅 허브 글입니다. Redis, RabbitMQ, Kafka 중 어떤 증상부터 먼저 봐야 하는지와 어떤 문제 패턴이 각 시스템에 가까운지 정리합니다.
- Kubernetes CrashLoopBackOff: 먼저 볼 것들 startup failure, probe, config, resource limit 관점에서 CrashLoopBackOff를 어떻게 나눠서 봐야 하는지 정리한 가이드입니다.
- Kafka consumer lag가 계속 늘 때: 트러블슈팅 가이드 Kafka consumer lag가 계속 늘어날 때 무엇부터 봐야 하는지 정리합니다. poll 주기, 처리 속도, rebalance, consumer 설정까지 실전 기준으로 다룹니다.
- Kafka Rebalancing Too Often 가이드 Kafka consumer group에서 rebalance가 너무 자주 일어날 때 membership flapping, poll timing, protocol, assignment churn을 어떤 순서로 봐야 하는지 설명하는 실전 가이드입니다.
- Docker container가 계속 재시작될 때: 먼저 확인할 것들 exit code, command failure, environment mistake, health check 관점에서 Docker restart loop를 푸는 실전 가이드입니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.