컨텍스트 윈도우: 길수록 정말 좋은가

모델 소개에서 빠지지 않는 항목이 컨텍스트 길이입니다. 숫자가 계속 커지면서 "이제 책 한 권을 통째로 넣을 수 있다"는 말도 나옵니다. 실제로 가능합니다. 다만 가능한 것과 좋은 것은 다릅니다.

컨텍스트를 길게 쓰면 비용이 늘고 응답이 느려지며, 어떤 경우에는 정확도까지 떨어집니다. 긴 컨텍스트는 편리한 기본값이 아니라 트레이드오프가 분명한 선택입니다.

이 글에서는 컨텍스트 윈도우가 무엇인지, 길게 쓸 때 실제로 무슨 일이 일어나는지, 그리고 긴 문서를 다루는 세 가지 방법을 어떤 기준으로 고를지 정리합니다. 개별 모델의 컨텍스트 길이는 수시로 바뀌므로 다루지 않습니다. 각 제공사의 모델 문서에서 확인하시기 바랍니다.

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

컨텍스트 윈도우(context window) 는 모델이 한 번의 요청에서 다룰 수 있는 토큰의 최대 개수입니다. 여기에는 다음이 모두 포함됩니다.

• 시스템 프롬프트
• 이전 대화 내역 전체
• 이번 질문
• 첨부한 문서·이미지
• 모델이 생성할 응답

마지막 항목을 놓치기 쉽습니다. 입력으로 한도를 거의 채우면 응답을 쓸 공간이 남지 않아 답변이 중간에 잘립니다. 제공사에 따라 입력과 출력 한도를 따로 두기도 하므로 문서를 확인해야 합니다.

LLM의 동작 원리에서 설명했듯 모델은 상태를 저장하지 않습니다. 대화가 이어지는 것처럼 보이는 이유는 서비스가 지난 대화를 매 요청마다 다시 넣어 주기 때문입니다. 그래서 대화가 길어질수록 매 요청의 입력이 누적되어 커집니다.

한도를 넘으면 오류가 나거나, 서비스가 앞부분을 잘라내거나 요약본으로 대체합니다. 긴 대화에서 "아까 말한 걸 잊었네"라는 인상을 받는 것이 이 지점입니다.

길게 쓰면 비용이 제곱으로 늘지는 않지만

긴 컨텍스트의 첫 번째 대가는 비용입니다. 과금은 토큰 수에 비례하므로, 100페이지 문서를 매 요청마다 넣으면 그만큼 입력 토큰이 누적됩니다. 대화형 서비스에서는 이 비용이 대화 길이에 따라 빠르게 늘어납니다.

두 번째 대가는 지연입니다. 트랜스포머 구조의 셀프 어텐션은 모든 토큰이 모든 토큰을 참조하므로, 기본 형태에서는 토큰 수의 제곱에 비례하는 계산이 필요합니다. 실제 구현에는 이를 완화하는 여러 최적화가 들어가 있지만, 길어질수록 첫 응답까지의 시간이 늘어난다는 경향은 남습니다.

중간에 있는 내용이 묻힙니다

세 번째 대가는 덜 알려져 있지만 더 중요합니다. 입력이 길어지면 중간 부분의 정보를 놓치는 경향이 관찰됩니다.

긴 문맥에서 특정 정보를 찾아 답하게 하는 실험을 하면, 그 정보가 앞쪽이나 뒤쪽에 있을 때보다 가운데 있을 때 정확도가 떨어지는 패턴이 여러 연구에서 보고되었습니다. 사람이 긴 글에서 앞뒤는 기억하고 중간은 흐릿하게 기억하는 것과 비슷합니다.

실무적으로 두 가지 결론이 나옵니다.

중요한 지시는 앞이나 뒤에 놓으세요. 긴 자료 사이에 핵심 요구사항을 끼워 넣으면 반영되지 않을 수 있습니다. 자료를 먼저 제시하고 질문과 지시를 맨 뒤에 다시 한 번 적는 구성이 안정적입니다.

"넣어 두면 알아서 찾겠지"는 위험합니다. 관련 없는 내용이 많이 섞일수록 신호가 희석됩니다. 긴 컨텍스트는 관련 자료를 선별해 넣을 때 가장 잘 작동합니다.

긴 문서를 다루는 세 가지 방법

문서가 컨텍스트에 안 들어가거나, 들어가도 비효율적일 때 선택지는 셋입니다.

1. 통째로 넣기

가장 단순합니다. 문서 전체를 프롬프트에 넣고 질문합니다.

• 좋은 경우 — 문서가 충분히 짧고, 전체를 훑어야 답할 수 있는 질문(전체 요약, 논조 분석, 문서 간 비교)일 때.
• 나쁜 경우 — 문서가 크고, 질문이 특정 부분에만 관련될 때. 매번 전체 비용을 내면서 정확도는 오히려 떨어집니다.

2. 나눠서 처리하고 합치기

문서를 조각으로 나눠 각각 처리한 뒤 결과를 모읍니다. 요약이라면 부분 요약을 만들고 그것들을 다시 요약합니다.

• 좋은 경우 — 전체를 빠짐없이 훑어야 하는 작업(전수 검토, 전체 요약, 모든 항목 추출).
• 주의할 점 — 조각 사이의 맥락이 끊깁니다. 앞 조각을 참조해야 이해되는 내용은 놓칠 수 있습니다. 단계마다 정보가 손실되고, 호출 횟수가 늘어 비용이 커질 수도 있습니다.

3. 검색해서 필요한 부분만 넣기

질문과 관련된 구간만 찾아서 넣습니다. RAG 파이프라인의 방식입니다.

• 좋은 경우 — 문서가 아주 많거나, 질문이 특정 부분에만 관련될 때. 대부분의 문서 질의응답이 여기에 해당합니다.
• 주의할 점 — 검색이 틀리면 답도 틀립니다. 구축과 운영 비용이 듭니다. "전체에서 몇 건인가" 같은 전수 집계형 질문에는 맞지 않습니다.

컨텍스트를 아끼는 실무 습관

• 대화 내역을 정리합니다. 오래된 부분을 요약으로 대체하거나, 주제가 바뀌면 새 대화를 시작합니다.
• 자료를 선별합니다. "혹시 몰라서" 넣는 문서가 가장 큰 낭비입니다.
• 형식을 줄입니다. 반복 키가 많은 JSON보다 표 형태가 토큰을 적게 씁니다. 토큰과 토크나이저에서 다룹니다.
• 출력 길이를 제한합니다. 출력 토큰은 대개 입력보다 비싸고 느립니다.
• 한국어 분량을 과소평가하지 마세요. 같은 내용이라도 영어보다 토큰을 많이 씁니다.

흔한 오해

"컨텍스트가 길면 모델이 기억력이 좋아진다." 기억이 아니라 매번 다시 읽는 것입니다. 한도가 크다는 것은 한 번에 읽을 수 있는 분량이 크다는 뜻일 뿐입니다.

"한도 안에만 들어가면 다 반영된다." 들어가는 것과 활용되는 것은 다릅니다. 중간에 묻히는 현상 때문에, 넣었는데 반영되지 않는 일이 생깁니다.

"긴 컨텍스트가 있으면 RAG는 필요 없다." 문서가 수천 건이면 여전히 다 넣을 수 없고, 넣을 수 있어도 비용과 정확도 면에서 검색이 유리한 경우가 많습니다. 둘은 대체재가 아니라 선택지입니다.

정리

• 컨텍스트 윈도우에는 시스템 프롬프트, 대화 내역, 첨부 자료, 생성할 응답이 모두 포함됩니다.
• 길게 쓰면 비용이 늘고 첫 응답까지의 시간이 길어집니다.
• 입력 가운데 위치한 정보는 활용도가 떨어지는 경향이 있으므로, 중요한 지시는 앞이나 뒤에 두세요.
• 긴 문서는 통째로 넣기, 나눠서 처리하기, 검색해서 넣기 중 작업 성격에 맞는 방법을 고릅니다.
• 전체를 훑어야 하면 분할 처리, 특정 부분을 찾아야 하면 검색이 적합합니다.
• 가장 단순한 방법부터 시도하고, 필요할 때 복잡한 구조로 옮기세요.

참고 자료

• Lost in the Middle: How Language Models Use Long Contexts — 입력 위치에 따른 정보 활용도 연구
• Anthropic — 긴 컨텍스트 활용 가이드 — 긴 입력 구성 요령
• Attention Is All You Need — 어텐션의 계산 구조