30페이지짜리 계약서를 AI에 통째로 넘겼다가 오류 메시지를 받아본 분이라면 이 글이 반갑게 느껴질 겁니다. 저도 처음엔 당연히 전문을 다 붙여넣으면 된다고 생각했습니다. 그 생각이 완전히 틀렸다는 걸 알게 된 이후로 방식이 달라졌습니다. 긴 문서를 AI에 분석시킬 때 실제로 효과가 있었던 전략과, 그 과정에서 발견한 한계를 정리했습니다.
컨텍스트 윈도우와 토큰의 현실
AI 모델에 문서를 넘길 때 가장 먼저 부딪히는 한계가 컨텍스트 윈도우(context window)입니다. 컨텍스트 윈도우란 AI 모델이 한 번의 요청에서 처리할 수 있는 텍스트의 최대 분량을 의미합니다. 단위는 토큰(token)인데, 토큰이란 모델이 텍스트를 처리하는 최소 단위로 한국어 기준 한 글자가 대략 1~2토큰에 해당합니다.
제가 처음 30페이지 계약서를 넣었을 때 돌아온 건 분석 결과가 아니라 토큰 한계 초과 오류였습니다. 당시 쓰던 모델의 컨텍스트 윈도우를 넘겼던 겁니다. 그때서야 문서 전체를 한 번에 처리하는 게 당연한 게 아니라는 걸 실감했습니다.
해결책으로 처음 시도한 건 청킹(chunking) 방식이었습니다. 청킹이란 긴 문서를 일정 기준으로 잘게 쪼개 AI에 나눠서 넘기는 기법입니다. 계약서라면 섹션별로 구분하고, 해지 조건을 찾는다면 목차를 보고 관련 조항 섹션만 잘라서 넣었습니다. 토큰 사용량이 기존 대비 5분의 1로 줄었고, 결과의 정확도는 오히려 올라갔습니다. 불필요한 텍스트가 없어지니 모델이 핵심에 더 집중하는 것처럼 보였습니다.
이 경험은 문서 유형에 따라 전략이 달라져야 한다는 결론으로 이어졌습니다. 청킹이 효과적인 경우와 그렇지 않은 경우를 정리하면 다음과 같습니다.
- 계약서, 보고서, 기술 문서처럼 구조가 명확한 문서: 섹션 단위 청킹이 유효합니다.
- 소설이나 대화록처럼 흐름이 중요한 문서: 청킹하면 맥락이 끊겨 오히려 분석 품질이 떨어집니다.
- 법령, 규정집처럼 조항 간 상호 참조가 많은 문서: 섹션만 잘라내면 참조 관계가 손실됩니다.
문서를 어떻게 자르느냐만큼 어느 섹션을 잘라야 하는지 판단하는 것도 중요한 문제인데, 이 부분이 생각보다 까다로웠습니다.
두 단계 쿼리와 RAG의 실용적 차이
청킹 방식의 맹점은 금방 드러났습니다. 관련 섹션을 제가 직접 골라야 한다는 점이었습니다. 내용을 모르니까 AI에게 맡기는 건데, 정작 넣을 섹션을 제가 판단해야 한다면 본말이 전도되는 상황입니다. 결국 문서를 어느 정도 읽은 셈이 됩니다.
이 모순을 해결하려고 두 단계 요청 방식을 썼습니다. 첫 번째 요청에서 문서 목차나 섹션 제목만 넣고 어느 부분을 분석하면 되겠는지 물었습니다. 두 번째 요청에서 AI가 지목한 섹션만 넣고 실제 분석을 시켰습니다. 이 방식으로 토큰도 아끼고 정확도도 유지할 수 있었습니다.
이 접근이 커지면 RAG(Retrieval-Augmented Generation)가 됩니다. RAG란 방대한 문서 저장소에서 질문과 관련된 부분만 자동으로 검색해 AI에 함께 넘기는 아키텍처입니다. 사람이 섹션을 고르는 두 단계 방식을 자동화한 것이라고 보면 됩니다. LlamaIndex 같은 프레임워크는 이 RAG 패턴을 구현하는 도구로, 임베딩(embedding) 기반 유사도 검색을 통해 관련 청크를 자동으로 추려냅니다. 임베딩이란 텍스트를 수치 벡터로 변환해 의미적으로 유사한 내용을 찾을 수 있게 하는 기술입니다(출처: LlamaIndex 공식 문서).
다만 RAG가 만능은 아닙니다. 요약을 AI가 만들게 하면 요약 단계와 분석 단계에서 토큰이 두 번 소비됩니다. 경우에 따라서는 짧은 문서를 전문으로 한 번 처리하는 게 전체 토큰 비용 측면에서 더 저렴하게 나오기도 했습니다. 일반적으로 RAG가 무조건 효율적이라고 알려져 있지만, 제 경험상 문서 길이와 질문의 성격에 따라 직접 비교해보는 게 맞습니다.
중간 소실 문제와 컨텍스트 확장의 한계
컨텍스트 윈도우가 계속 커지고 있으니 이런 고민이 곧 필요 없어지지 않겠냐는 시각이 있습니다. Claude나 Gemini 최신 모델은 수십만 토큰을 처리할 수 있고, 전문을 통째로 넣어도 되는 시대가 빠르게 다가오고 있는 것은 사실입니다.
그런데 컨텍스트 윈도우가 넓어진다고 해서 긴 문서 처리가 완벽해지는 건 아닙니다. 여기서 주목해야 할 것이 소실 중간 문제(lost in the middle)입니다. 소실 중간 문제란 컨텍스트 내에서 앞부분과 끝부분에 있는 정보는 모델이 잘 참조하는 반면, 중간에 위치한 정보는 상대적으로 덜 반영되는 현상을 말합니다. 문서가 길수록 이 현상이 심화됩니다(출처: Anthropic 긴 컨텍스트 처리 가이드).
솔직히 이건 처음에 예상 밖이었습니다. 모델이 긴 텍스트를 받으면 균등하게 처리할 것이라고 막연히 생각했는데, 실제로는 위치에 따라 집중도가 다릅니다. 100페이지짜리 보고서의 50페이지에 박힌 핵심 데이터를 모델이 놓치는 경우가 생긴다는 뜻입니다.
이 문제를 우회하는 방법으로 질문을 문서 앞쪽이나 뒤쪽에 배치하거나, 중요한 내용을 프롬프트 상단에 따로 요약해서 넣는 방식이 있습니다. 저는 중요한 조항을 별도로 복사해 프롬프트 시작 부분에 붙인 뒤 전문을 이어 붙이는 방식을 써봤는데, 단순히 전문만 넣는 것보다 참조 정확도가 체감상 올랐습니다.
컨텍스트 윈도우 확장과 소실 중간 문제가 동시에 존재한다는 점은, 지금의 청킹과 RAG 전략이 1~2년 뒤에도 완전히 구식이 되기는 어렵다는 것을 시사합니다. 창이 넓어질수록 내부 주의(attention) 분산도 달라지기 때문에 단순히 크기만으로 해결되지 않습니다.
지금 쓰고 있는 방식이 모두 임시방편처럼 느껴질 수 있습니다. 저도 그렇게 생각했습니다. 하지만 문서 유형을 파악하고 질문의 범위에 맞게 컨텍스트를 설계하는 감각은, 모델 성능이 아무리 올라가도 사람이 갖춰야 할 역량으로 남을 것 같습니다. 당장 반복되는 문서 분석 작업이 있다면 두 단계 쿼리 방식부터 시도해보시길 권합니다. 생각보다 빠르게 결과가 달라질 겁니다.
참고: OpenAI API 텍스트 생성 가이드 (컨텍스트 윈도우) https://platform.openai.com/docs/guides/text-generation
LlamaIndex 공식 문서 (RAG 패턴) https://docs.llamaindex.ai
Anthropic 긴 컨텍스트 처리 가이드 https://docs.anthropic.com/en/docs/build-with-claude/long-context-tips
Anthropic 연구 블로그 (컨텍스트 평가) https://www.anthropic.com/research
OpenAI 임베딩 기반 검색 가이드 https://platform.openai.com/docs/guides/embeddings