토큰과 컨텍스트 윈도우 — RAG 비용은 어디서 나오고 무엇을 넣을 것인가

RAG에서 비용이 새는 지점은 대개 둘이다. 대화 히스토리를 자르지 않고 전부 재전송하는 것, 그리고 top-k를 습관적으로 크게 잡는 것. 둘 다 "일단 많이 넣으면 안전하다"는 직관에서 나오는데, 실제로는 비용만 늘고 답변 품질은 오히려 떨어진다.

이 글은 그 직관이 왜 틀렸는지를 토큰 단위에서 설명하고, 적게 넣어야 한다면 무엇을 넣을 것인가라는 다음 질문까지 이어서 답한다. 토큰과 컨텍스트 윈도우의 구조, 한국어가 비싼 구조적 이유, 컨텍스트를 공유 예산으로 보는 관점, 그리고 중복 문서를 걷어내는 MMR 알고리즘을 다룬다.

용어 정리

네 개 축이 서로를 물고 있다

RAG 운영의 핵심 개념은 독립된 주제가 아니라 하나의 순환이다.

이 글은 앞의 두 축을 다룬다. 나머지 두 축은 로컬 LLM 운영과 비동기와 트레이싱에서 이어진다.

토큰 — 과금 단위이자 한계 단위

토큰은 LLM이 텍스트를 이해·처리하기 위해 분할한 최소 단위이고, 나누는 과정을 토큰화라고 한다. 방식은 셋으로 나뉜다.

서브워드 방식의 대표 알고리즘이 BPE다. 자주 등장하는 문자 쌍을 반복적으로 병합해 서브워드 사전을 구성한다. "Machine learning"이 ["Ma","chine","learn","ing"]으로 쪼개지는 식이다.

토큰이 중요한 이유는 둘이다. 하나는 문맥 이해 — 토큰화 결과에 따라 모델이 의미를 파악하는 정확도가 달라진다. 다른 하나는 더 직접적이다. 토큰 사용량이 곧 비용이다.

한국어는 왜 더 비싼가

동일한 4턴 대화를 모델별·언어별로 측정한 결과다. 측정 대상은 시스템 프롬프트 1개와 인사말 수준의 사용자·어시스턴트 발화 각 1개다.

행 간 비교는 하지 말 것. gpt-3.5-turbo 73 → gpt-4-1106-preview 132로 뛴 것은 후자가 한국어를 더 비싸게 처리해서가 아니다. 토큰 ID 열을 보면 후자는 <|im_start|>가 27, 91, 318, 5011, 91, 29처럼 문자 단위로 쪼개져 있다. 측정 도구가 해당 템플릿의 특수토큰을 단일 토큰으로 인식하지 못한 결과다. 의미 있는 비교는 같은 행 안의 한/영 배율과 동일 토크나이저 계열 간 비교뿐이다.

여기서 나오는 결론은 둘이다.

원인은 언어의 난이도가 아니라 토크나이저다. BPE 사전이 영어 코퍼스 중심으로 학습됐기 때문에 한국어가 더 잘게 쪼개진다.

컨텍스트 윈도우와 max_tokens는 다르다

비대칭에 주의한다. 컨텍스트가 128,000 토큰이어도 출력은 최대 4,096 토큰인 모델이 있다. "128K 모델"이라고 해서 128K짜리 답변이 나오지 않는다. 입력은 128K까지 받되 답변은 4K가 상한이다. 긴 문서 요약·번역을 설계할 때 이 비대칭을 모르면 "왜 답변이 자꾸 잘리는가"에 답할 수 없다.

컨텍스트 윈도우는 공유 예산이다

실무에서 비용이 새는 지점이 대개 두 곳이라는 것이 이 표에서 드러난다. 대화 히스토리를 자르지 않고 전부 재전송하면 10턴째에는 1턴 대비 입력 토큰이 몇 배가 되어 있다. 그리고 RAG top-k를 습관적으로 크게 잡으면 k=10과 k=3의 차이가 그대로 매 호출 비용 차이가 된다.

단가에서 읽어야 할 것은 숫자가 아니라 패턴

절대 단가는 시간이 지나면 바뀌지만 이 네 패턴은 유지된다. 특히 출력이 입력의 3배라는 구조는 어디를 먼저 줄일지의 순서를 정해 준다.

토큰 산정 감각

여기서 파생되는 환산표다.

이 환산이 유용한 이유는 컨텍스트 윈도우와 max_tokens의 비대칭을 한 번에 체감시키기 때문이다. 128K 컨텍스트에는 한글 A4 28장이 들어가지만, 답변은 4K — A4 한 장이 상한이다. 넓은 입력 윈도우는 여유지 목표가 아니다.

비용 절감 레버 8가지

3번이 이 글의 나머지 절반으로 이어진다. top-k를 줄이려면 남는 자리에 무엇을 넣을지 더 잘 골라야 한다.

MMR — 적게 넣는다면 무엇을 넣을 것인가

유사도 top-k만 쓰면 생기는 일

벡터 검색은 기본적으로 쿼리와의 유사도 상위 k개를 반환한다. 문제는 상위 k개가 서로 거의 같은 내용일 수 있다는 점이다.

이 경우 5개 슬롯을 썼지만 실제로 전달된 정보는 1개다. 결과는 셋이다.

발상 — 관련성과 다양성을 함께 본다

레스토랑에서 메뉴를 고르는 상황에 비유하면 이해가 빠르다. 피자를 좋아하지만 피자만 다섯 개 시키고 싶지는 않다. MMR은 **취향(쿼리 관련성)**과 **이미 고른 것과의 차별성(문서 간 다양성)**을 동시에 평가한다.

수식

MMR = arg max      [ λ · Sim1(Di, Q)  −  (1 − λ) · max Sim2(Di, Dj) ]
      Di ∈ R \ S                                    Dj ∈ S

말로 풀면 이렇다. 쿼리와의 관련성 점수에서, 이미 뽑은 문서들 중 가장 비슷한 것과의 유사도를 벌점으로 뺀다. 그 값이 가장 큰 문서를 다음으로 뽑는다.

핵심은 max Sim2 — 평균이 아니라 최댓값이다. 이미 뽑은 문서 중 하나라도 매우 비슷하면 그 순간 벌점이 커진다. 평균을 쓰면 "대부분 다르지만 하나와 완전히 같은" 문서를 걸러내지 못한다.

동작 흐름

주목할 점은 탐욕적(greedy)·순차적 알고리즘이라는 것이다. 한 번에 k개를 고르는 게 아니라 하나씩 뽑으며, 뽑을 때마다 나머지 후보의 점수가 재계산된다. 그래서 순서 자체가 의미를 갖는다.

계산 예시

λ = 0.5, k = 3 조건으로 액션 영화를 고르는 상황이다.

유사도만 썼다면 A → B → C가 되어 A와 B가 사실상 같은 영화였을 것이다. B의 2회차 점수가 음수로 떨어지는 것이 MMR의 작동 방식을 그대로 보여준다.

위 수치는 알고리즘 동작을 보이기 위해 구성한 설명용 값이다.

λ 튜닝

LangChain의 lambda_mult가 이 λ에 해당하며 기본값은 0.5다.

fetch_k가 k와 같으면 MMR은 꺼진 것과 같다

MMR은 후보 풀이 넓어야 다양성을 고를 여지가 생긴다.

fetch_k를 k와 같게 두면 MMR은 사실상 무력화된다. 고를 후보가 없으니 유사도 순서를 거의 그대로 내보낸다. 반대로 fetch_k를 과도하게 키우면 문서 간 유사도 계산이 O(fetch_k × k)로 늘어 검색 지연이 증가한다.

retriever = vectorstore.as_retriever(
    search_type="mmr",
    search_kwargs={
        "k": 4,               # 최종 반환 문서 수
        "fetch_k": 20,        # MMR 후보 풀 크기
        "lambda_mult": 0.7,   # 1.0에 가까울수록 관련성 우선
    },
)

docs = retriever.invoke("환불 정책이 어떻게 되나요?")

언제 MMR을 쓰지 말아야 하나

"MMR을 기본으로 켠다"는 선택은 그래서 틀렸다. 질의 유형별로 λ를 다르게 두는 것이 실제 설계다.

토큰당 과금 자체를 없앨 수는 없는지 — 즉 변동비를 고정비로 바꾸는 선택은 로컬 LLM 운영에서 다룬다.