모델 문서에 기재된 컨텍스트 윈도우(Context Window) 숫자는 용량 사양일 뿐, 보증이 아닙니다. 200K 토큰을 광고하는 모델은 200K 토큰을 기꺼이 받아들이겠지만, 그 토큰들을 처리하는 품질은 해당 한계치에 도달하기 훨씬 전부터 떨어지기 시작합니다. 만약 전체 윈도우가 동일하게 잘 작동한다고 가정하고 프로덕션 기능을 구축한다면, 긴 입력값에서만 나타나는 버그를 배포하게 될 것입니다. 여기 토큰 예산(Token Budgets)이 실제로 어떻게 작동하는지, 그리고 윈도우가 당신을 조용히 속이는 것을 어떻게 방지할 수 있는지에 대해 설명합니다.

상자에 적힌 숫자가 당신이 얻는 숫자가 아닙니다

광고된 컨텍스트 윈도우(Context Window)는 사용 가능한 품질이 아닌 용량을 설명합니다. 긴 컨텍스트(Long Context) 동작에 관한 연구에 따르면, 모델은 입력의 시작과 끝 부분에 훨씬 더 많은 주의(Attention)를 기울이는 반면, 중간에 묻힌 콘텐츠는 명시된 제한 범위 내에 있더라도 놓치는 것으로 나타납니다. 사람들은 이를 '중간에서 길을 잃는 문제(Lost in the middle problem)'라고 부르며, 이는 프롬프트로 해결할 수 있는 버그가 아니라 어텐션(Attention) 메커니즘이 작동하는 방식에서 기인합니다.

이 격차는 대부분의 팀이 예상하는 것보다 더 큽니다. 200K 윈도우를 주장하는 모델들도 실제로는 약 130K 토큰 부근에서 측정 가능한 품질 저하를 보입니다. 이는 모델이 답변을 거부하는 것이 아닙니다. 당신이 비용을 지불하고 보낸 토큰을 사용하는 능력이 조용히 저하되는 것입니다. 만약 중요한 지시 사항이 거대한 프롬프트의 중간에 위치한다면, 그것이 확실히 읽혔다고 가정하지 말고 '어쩌면 읽혔을 수도 있다'라고 취급하십시오.

모든 것이 하나의 예산을 공유합니다

가장 큰 오해는 컨텍스트 윈도우(Context Window)가 입력만을 위한 것이라고 생각하는 것입니다. 그렇지 않습니다. 제한은 입력(Input)과 출력(Output) 토큰을 합친 총합에 적용됩니다. 당신의 시스템 프롬프트(System Prompt), 대화 기록(Conversation History), 검색된 모든 문서(Retrieved Documents), 사용자 질의(User Query), 그리고 모델 자체의 응답(Response)이 모두 동일한 풀(Pool)에서 차감됩니다.

이는 사람들이 끊임없이 겪는 결과를 초래합니다. 관대한 시스템 프롬프트 (System Prompt)와 긴 대화 기록 (Chat History)이 결합되면 답변을 위한 공간이 거의 남지 않을 수 있습니다. 모델은 사전에 경고를 주지 않습니다. 사고 과정 중간에 예산이 소진되어 응답이 잘리거나(Truncated), API가 요청을 즉시 거부합니다. 출력(Output)이 입력(Input)과 동일한 공간을 두고 경쟁한다는 사실을 받아들이고 나면, 가장 긴 세션에서 답변이 끊기는 현상에 더 이상 놀라지 않게 될 것입니다.

큰 컨텍스트가 느려지고 비싸지는 이유

긴 프롬프트는 품질만을 위협하는 것이 아닙니다. 매 호출마다 시간과 비용을 소모하게 만듭니다. 어텐션 (Attention) 단계는 모든 토큰을 다른 모든 토큰과 비교하므로, 핵심 연산량은 입력 길이의 제곱에 비례하여 증가합니다. $QK^T$ 행렬은 $n imes n$ 크기이므로, 컨텍스트를 두 배로 늘리면 모델이 수행해야 할 작업량은 대략 네 배로 늘어납니다. 한 연구에 따르면 컨텍스트가 15,000단어일 때 지연 시간 (Latency)이 7배 증가하는 것으로 측정되었습니다. 이는 빠릿한 답변과 사용자가 포기하게 만드는 로딩 스피너 사이의 차이입니다.

비용 또한 동일한 곡선을 따릅니다. LLM API는 입력과 출력 모두 토큰당 비용을 청구하기 때문입니다. 추가되는 모든 대화 기록이나 검색된 컨텍스트 토큰은, 그것이 제 역할을 하든 못하든 매 요청마다 지출되는 비용입니다. 만약 청구 금액이 계속 상승한다면, 과도하게 큰 프롬프트가 원인인 경우가 많으며, 이를 다듬는 것은 모델을 변경하지 않고도 추론 비용을 절감하는 가장 빠른 방법 중 하나입니다.

전송하기 전에 토큰을 계산하세요

측정하지 않는 예산은 관리할 수 없습니다. 요청을 보내기 전에 프롬프트의 각 부분이 실제로 얼마만큼의 비용을 차지하는지 계산하십시오. 이 한 가지 습관만으로도 컨텍스트 윈도우 (Context Window)를 조용히 갉아먹는 시스템 프롬프트의 비대화와 통제되지 않는 대화 기록을 찾아낼 수 있습니다.

import { encoding_for_model } from "tiktoken";

const enc = encoding_for_model("gpt-4o");
...

실제 세션에 대해 이를 한 번 실행해 보면, 대개 한 부분이 예산을 독점하고 있음을 발견하게 될 것입니다. 열에 아홉은 몇 달 동안 다듬지 않은 비대한 시스템 프롬프트이거나, 매 턴마다 계속 커지는 제한 없는 대화 기록입니다.

프로덕션 환경에서 예산 모니터링하기

로컬에서 카운팅하는 것이 첫 번째 단계입니다. 프로덕션(Production) 환경에서는 한계에 부딪힌 후가 아니라, 한계에 도달하기 전에 핫 패스(Hot path)에서 예산을 확인하고 경고를 받아야 합니다. 효과적인 규칙은 다음과 같습니다: 모든 호출 시 토큰 사용량(Token usage)을 로그로 남기고, 사용량이 컨텍스트 제한(Context limit)의 80%를 초과하면 경고를 발생시키십시오. 이렇게 하면 요청이 실패하기 시작하기 전에 대응할 수 있는 여유를 확보할 수 있습니다.

const CONTEXT_LIMIT = 128000; // 모델의 실제 제한값으로 설정하세요

function checkBudget({ inputTokens, maxOutputTokens }, requestId) {
...

한계선을 넘었을 때, 해결책이 더 큰 모델을 사용하는 것인 경우는 드뭅니다. 해결책은 더 적게 보내는 것입니다. 이전 대화 내용을 요약(Summarize)하고, 오래된 검색 청크(Retrieved chunks)를 버리며, 검색(Retrieval)에 의존하여 프롬프트에 모든 것을 채워 넣는 대신 쿼리에 필요한 구절만 가져오십시오. 만약 검색 레이어(Retrieval layer)를 구축하고 있다면, 탄탄한 컨텍스트 관리를 위한 RAG (RAG to manage context) 설정이 대부분의 가지치기(Trimming) 작업을 대신 해줄 것입니다.

지금 바로 확인해야 할 세 가지

1. 오늘 당장 시스템 프롬프트(System prompt)의 토큰 수를 로그로 남기십시오. 만약 수천 토큰을 넘는다면, 아마도 더 이상 필요하지 않은 지침들을 포함하고 있을 가능성이 높습니다.
2. 프롬프트의 시작과 끝을 활용하십시오. 가장 중요한 단일 지침은 맨 위나 맨 아래로 옮기되, 절대 중간에 두지 마십시오.
3. 다음 배포(Deploy) 전에 80% 사용량 경고를 추가하십시오. 그래야 컨텍스트 윈도우(Context window)가 조용히 실패하는 대신, 거의 가득 찼음을 미리 알려줄 수 있습니다.

이 중 어떤 것도 거창한 플랫폼을 필요로 하지 않습니다. 토큰 카운터(Token counter), 하나의 예산 확인(Budget check), 그리고 80% 경고만 있으면 사용자가 문제를 발견하기 전에 대부분의 컨텍스트 문제를 잡아낼 수 있습니다. 과도하게 큰 프롬프트가 비용에 어떤 영향을 미치는지 알고 싶다면, LLM 파이프라인 비용 계산기 (LLM pipeline cost calculator)를 통해 수치를 계산해 보고 실제 가격에 맞춰 예산을 산정해 보십시오.

모델 비용을 절감하는 방법에 대해 더 깊이 알고 싶다면, 제 사이트 (my site)에서 더 자세히 다루고 있습니다.

만약 이 과정을 귀하의 사이트에 엔드 투 엔드 (end-to-end)로 직접 구축하고 싶다면, 바로 제가 수행하는 작업의 종류입니다.

귀하의 설정이 다르다면 댓글을 남겨주세요. 사람들이 실제 프로덕션 (production) 환경에서 실제로 어떤 토큰 예산 (token budgets)을 실행하고 있는지 궁금합니다.