RAG가 무조건 정답이라고 믿어왔다면, 한 번쯤 의심해볼 필요가 있습니다. 250페이지 보고서 12건과 인터뷰 전사 80건을 직접 다뤄본 뒤, 저는 그 믿음을 조금 내려놓았습니다. 어떤 상황에서 무엇을 선택해야 하는지, 실제 수치와 함께 풀어봅니다.
토큰효율: 한국어 환경에서 1M 컨텍스트는 얼마나 실용적인가
RAG(Retrieval-Augmented Generation)는 쉽게 말해 질문과 관련 있는 텍스트 조각만 뽑아 모델에게 전달하는 방식입니다. 즉, 수백만 토큰짜리 문서 전체를 모델에 넣는 대신, 필요한 부분만 꺼내 쓰는 검색 우선 구조입니다. 비용이 낮고 응답 속도가 빠르다는 장점 때문에 오랫동안 표준처럼 여겨져 왔습니다.
그런데 Gemini 1.5 Pro가 최대 1M 토큰의 컨텍스트 윈도우를 지원하면서 상황이 달라졌습니다. 컨텍스트 윈도우란 모델이 한 번에 처리할 수 있는 토큰의 최대 범위를 의미합니다. 이 범위 안에 있는 내용만 모델이 '기억'한 채로 답을 생성하므로, 범위가 넓을수록 문서 전체를 통째로 이해하는 것이 가능해집니다.
문제는 한국어입니다. 벡터임베딩(Vector Embedding) 기반의 토큰화 과정에서 한국어 텍스트는 영문 대비 평균 1.6배 더 많은 토큰을 소비합니다. 벡터임베딩이란 텍스트를 숫자 벡터로 변환해 의미적 유사성을 계산할 수 있게 만드는 기술인데, 이 변환 과정에서 한국어 형태소 특성상 토큰이 더 잘게 쪼개집니다. 제가 직접 써봤는데, 영문 보고서 100페이지 분량이 약 8만 토큰이라면 같은 내용의 한국어 번역본은 12만~13만 토큰까지 올라갔습니다. 1M 컨텍스트가 실효적으로는 60만 토큰짜리 영문 컨텍스트와 비슷하게 작동하는 셈입니다.
그렇다고 RAG가 완전한 해답은 아닙니다. RAG는 검색 품질에 전적으로 의존하기 때문에, 질문이 모호하거나 문서 전반에 걸친 맥락 파악이 필요한 경우에는 핵심 인용을 놓치기 쉽습니다. 제 외주 프로젝트에서 기존 RAG 파이프라인의 핵심 인용 발견율은 38%에 불과했습니다. 토큰 비용을 아끼려다 결과물의 정확도를 희생하는 구조였던 것입니다.
의사결정: RAG와 롱컨텍스트, 언제 무엇을 써야 하나
롱컨텍스트를 써봐야 한다고 주장하는 분들도 있고, RAG 파이프라인의 안정성을 강조하는 분들도 있습니다. 저는 두 관점 모두 틀리지 않았다고 봅니다. 다만 상황에 따라 선택이 달라져야 한다는 점을 실제 데이터로 확인했습니다.
제가 리서치 외주에서 Gemini 1.5 Pro의 롱컨텍스트를 선택한 이유는 명확했습니다. 250페이지 보고서와 인터뷰 전사 자료를 다루는 작업에서는 특정 키워드로 조각을 뽑아내는 것보다, 전체 맥락을 한 번에 이해하는 것이 훨씬 중요했습니다. 실제로 RAG 방식의 핵심 인용 발견율 38%가 롱컨텍스트 전환 후 81%로 올랐고, 외주 결과물 제출 사이클은 평균 21일에서 9일로 단축되었습니다. 솔직히 이건 예상 밖이었습니다. 절반 이하로 줄어들 줄은 몰랐거든요.
반면 수십만 건의 단순 문서를 인덱싱해 특정 정보를 조회하는 작업이라면 RAG가 여전히 유리합니다. LLM Ops(대규모 언어 모델 운영) 관점에서 보면, 매 쿼리마다 1M 토큰을 모델에 밀어 넣는 것은 비용과 지연 시간 측면에서 비효율적입니다. LLM Ops란 언어 모델을 서비스 환경에서 안정적으로 운영하고 최적화하는 일련의 프로세스를 뜻합니다.
의사결정 기준을 정리하면 다음과 같습니다.
- 문서 전체 맥락 파악이 핵심인 작업(코드베이스 분석, 리서치 종합, 인터뷰 전사 분석): 롱컨텍스트 우선
- 대용량 문서 인덱싱 및 단순 키워드 조회: RAG 우선
- 한국어 문서 처리: 토큰 소비량 1.6배를 반드시 고려한 후 선택
- 비용 민감도가 높은 반복 쿼리 작업: RAG가 유리하나, 컴퓨팅 비용 하락 추세를 감안해 재검토 필요
멀티모달(Multimodal) 처리 관점도 무시할 수 없습니다. 멀티모달이란 텍스트 외에 이미지, 영상, 오디오 등 여러 형태의 데이터를 통합적으로 처리하는 기능을 말합니다. 44분 분량의 영상을 약 69만 6천 토큰으로 변환해 타임코드 기반 질의응답을 처리하는 사례처럼, 롱컨텍스트는 RAG가 아직 따라오지 못하는 영역이 분명히 존재합니다. 대규모 언어 모델의 추론 속도가 초당 500토큰 수준까지 올라오고 있다는 점을 감안하면(출처: Groq 공식 사이트), 속도 문제도 시간이 해결해줄 가능성이 높습니다.
프롬프트패턴: 1M 컨텍스트를 제대로 쓰는 방법
롱컨텍스트를 도입했다고 해서 바로 좋은 결과가 나오지는 않습니다. 저는 외주 5건에 반복 적용하면서 세 가지 프롬프트 패턴을 라이브러리로 정리했고, 평균 결과 정확도가 35% 향상되는 것을 확인했습니다.
앵커링(Anchoring) 패턴은 모델이 긴 문서를 처리할 때 중간 부분의 정보를 희석하는 현상, 이른바 '중간 손실(Lost in the Middle)' 문제를 완화하기 위한 방식입니다. 문서 서두에 핵심 질문과 기대 출력 형식을 명시적으로 선언해 모델이 전체 문서를 그 기준으로 읽도록 유도하는 기법입니다. 두 번째는 구조화(Structuring) 패턴으로, 입력 문서를 섹션별로 레이블링해 모델이 어느 영역에서 근거를 찾아야 하는지 경로를 미리 제시하는 방식입니다. 세 번째는 요약 우선(Summary-First) 패턴입니다. 이는 전체 문서를 넣기 전에 각 소문서의 요약을 선행 입력해 모델의 주의 자원을 효율적으로 배분하는 방식입니다. 특히 한국어 환경에서는 불용어 제거와 요약 전처리를 병행하면 토큰 소비를 실질적으로 줄일 수 있습니다.
제 경험상 이 세 패턴을 분기마다 결과 정확도와 함께 측정하고 갱신하는 것이 중요합니다. 실제로 분기 단위 갱신을 통해 평균 14%의 토큰 효율 개선을 측정했습니다. AI 언어 모델의 성능과 활용 방식은 빠르게 바뀌기 때문에, 한 번 만든 프롬프트 패턴을 영구적으로 쓰는 것은 위험합니다. 구글 딥마인드 연구에 따르면 긴 컨텍스트에서 발생하는 정보 손실 패턴은 모델 버전마다 다르게 나타납니다(출처: Google DeepMind), 패턴 라이브러리의 정기 검증이 단순한 권고가 아니라 필수 작업인 이유입니다.
한국 가이드 차원에서 보면, 토큰 효율 모니터링 분기 보고 모델을 운영하며 분기당 평균 25% 토큰 절감을 목표로 삼는 것이 현실적입니다. 단순히 롱컨텍스트를 쓰겠다는 결정보다, 어떻게 쓸 것인지를 문서화하고 측정하는 구조가 더 중요하다는 것이 제 결론입니다.
RAG냐 롱컨텍스트냐의 선택은 기술 스펙이 아니라 작업의 성격과 비용 구조로 판단해야 합니다. 저는 당분간 고정밀 분석 외주에는 롱컨텍스트를, 반복 조회가 많은 구조에는 RAG를 병행할 계획입니다. 컴퓨팅 비용이 계속 내려가는 추세라면, 몇 년 안에 이 선택 자체가 의미 없어질 수도 있습니다. 지금 당장은 자신의 작업 패턴을 먼저 분석하고, 그에 맞는 프롬프트 패턴 라이브러리를 하나씩 쌓아가는 것이 가장 실용적인 시작점이라고 봅니다.