LLM 토큰 예산은 언제 줄이고 언제 더 써야 할까

LLM 토큰 예산은 무조건 아끼거나 무조건 늘리는 값이 아니라 요청 유형에 따라 배분해야 하는 운영 판단이다.

단순 변환·분류, 문서 근거 답변, 긴 이력 의존 요청은 서로 다른 토큰 예산을 가져야 한다.
문서 근거, 긴 이력, 여러 조건 비교가 필요한 요청은 더 많은 토큰 예산을 쓸 이유가 있다.
판단 기준은 비용을 줄였을 때 답의 근거와 결론이 흔들리는지다.
토큰 예산은 품질, 지연, 비용 중 무엇을 먼저 지켜야 하는 요청인지에 따라 달라진다.

좋은 토큰 예산은 가장 짧은 입력이 아니라, 답의 품질을 해치지 않는 가장 작은 입력을 찾는 일이다.

토큰 예산은 요청 유형별로 다르게 줘야 한다

LLM 기능을 운영하는 독자에게 필요한 첫 판단은 “모든 요청에 같은 컨텍스트 길이를 줄 필요가 없다”는 것이다. 토큰 예산(token budget)은 한 요청에 어느 정도 입력 문맥과 출력 여유를 허용할지 정하는 기준이다. 비용을 줄이려면 무조건 줄이는 것이 아니라, 줄여도 답이 흔들리지 않는 요청부터 찾아야 한다.

요청 유형은 크게 나눠볼 수 있다. 단순 문장 변환, 분류, 짧은 형식 변경은 입력 자체가 답의 대부분을 제공한다. 문서 근거 답변은 질문보다 근거 문단의 선택이 더 중요하고, 긴 대화 이력 의존 요청은 이전 조건을 잃으면 결론이 달라질 수 있다. 이런 요청들을 같은 예산으로 처리하면 단순 요청은 비싸지고, 복잡한 요청은 근거가 부족해진다.

초기 분류는 다음처럼 잡을 수 있다. 아래 표는 어떤 요청군인지 가르는 분류표다. 아직 무엇을 줄일지 결정하는 표가 아니라, 같은 토큰 예산을 쓰면 안 되는 요청을 먼저 나누기 위한 기준이다.

요청 유형	컨텍스트 판단	예산 방향
단순 변환·분류	현재 입력만으로 답이 거의 결정됨	짧은 예산을 기본값으로 둔다
문서 근거 답변	답의 근거가 특정 문단에 있음	관련 문단 중심으로 중간 예산을 둔다
긴 대화 이력 의존 요청	이전 조건을 잃으면 결론이 바뀜	필요한 이력만 남긴 긴 예산을 허용한다

명시적 가상 시나리오를 보자. 한 서비스가 “문장을 공손하게 바꿔줘”라는 요청과 “지난 상담 이력을 바탕으로 환불 가능성을 정리해줘”라는 요청에 같은 컨텍스트 길이를 허용한다고 하자. 첫 번째 요청은 짧은 입력으로 충분하지만, 두 번째 요청은 이전 조건을 잃으면 답이 틀어질 수 있다. 같은 토큰 예산을 쓰면 한쪽은 낭비가 되고 다른 한쪽은 품질 보호가 된다.

운영 지표로는 입력 토큰 수, 출력 토큰 수, p95 latency, 재질문 비율, 답변 수정률을 함께 볼 수 있다. 입력을 줄였는데 재질문이나 수정률이 늘지 않는다면 예산을 줄여도 되는 요청일 가능성이 높다. 입력을 줄인 뒤 답이 근거를 잃거나 사용자가 같은 질문을 반복한다면 그 요청은 더 긴 컨텍스트가 필요한 후보다.

줄일지 유지할지는 품질 손실의 위치로 판단한다

토큰 예산을 줄일 때 가장 위험한 방식은 모든 요청에서 같은 비율로 문맥을 잘라내는 것이다. 컨텍스트는 균일한 덩어리가 아니다. 어떤 부분은 답의 결론을 좌우하고, 어떤 부분은 단순 반복이나 형식 안내에 가깝다. 예산 조정은 길이보다 기여도를 기준으로 해야 한다.

다음 기준을 쓰면 판단이 단순해진다. 앞의 표가 요청 유형을 나누는 표라면, 아래 표는 실제 조치를 고르는 action decision 표다.

조건	해석	likely response
입력을 줄여도 결론과 근거가 유지됨	과잉 문맥이 있었을 가능성	기본 컨텍스트를 줄인다
입력을 줄이면 제약 조건을 놓침	필요한 문맥이 잘렸을 가능성	해당 요청 유형은 긴 예산을 유지한다
짧은 요청에서도 지연이 길어짐	공통 프롬프트나 히스토리가 과도할 수 있음	기본 조립 규칙을 점검한다
복잡한 문서 요청에서만 비용이 큼	비용이 품질 유지와 연결될 수 있음	예외 예산을 허용하되 범위를 제한한다
긴 이력 요청에서 재질문이 줄어듦	이력이 답 품질에 기여하고 있음	필요한 이력은 유지하고 오래된 반복만 줄인다

이 표는 내부 운영 메모가 아니라 독자가 판단을 시작하기 위한 압축 기준이다. 핵심은 비용 절감이 품질 손실로 바뀌는 지점을 찾는 것이다. 답 품질이 유지되는 곳에서는 줄이고, 답의 근거가 사라지는 곳에서는 더 쓴다.

토큰 낭비가 중복 지시, 낮은 관련도 문단, 긴 히스토리 중 어디서 만들어지는지 아직 흐릿하다면 LLM 컨텍스트 조립은 어디서 토큰 낭비를 만들까를 먼저 보면 원인을 좁히기 쉽다. 전체적으로 왜 긴 컨텍스트가 비용과 지연을 키우는지는 LLM 컨텍스트가 길어질수록 왜 비용과 지연이 같이 커질까에서 큰 그림을 확인할 수 있다.

긴 컨텍스트는 예외가 아니라 근거가 있을 때 허용해야 한다

긴 컨텍스트를 완전히 피할 필요는 없다. 문제는 긴 컨텍스트가 기본값이 되는 순간이다. 기본값이 길면 단순 요청까지 비싸지고, 기본값이 짧으면 복잡한 요청에서 품질이 흔들린다. 따라서 요청을 몇 가지 예산 등급으로 나누는 방식이 더 안전하다.

예를 들면 단순 변환과 분류는 짧은 예산, 여러 조건을 비교하는 문서 답변은 중간 예산, 긴 이력과 원문 근거가 모두 필요한 요청은 높은 예산으로 둘 수 있다. 여기서 중요한 것은 각 등급에 관찰 가능한 조건을 붙이는 것이다. “중요한 요청” 같은 표현은 모호하다. “이전 대화의 특정 조건을 답에 반드시 반영해야 하는 요청”처럼 판단 가능한 기준이어야 한다.

상황별 분기는 이렇게 정리할 수 있다. 안전하게 줄여도 되는 경우는 입력을 줄여도 결론, 근거, 재질문 비율이 흔들리지 않는 요청이다. 긴 컨텍스트를 유지해야 하는 경우는 원문 근거, 이전 조건, 복수 문서 비교가 답의 정확도를 좌우하는 요청이다. 먼저 시험해야 하는 경우는 비용과 지연은 늘었지만 품질 손실 위치가 분명하지 않은 요청이다. 이때는 일부 요청에서만 문맥을 줄여 재질문 비율과 수정률이 변하는지 본다. 줄인 뒤 재질문이 늘지 않으면 안전한 축소에 가깝고, 줄인 뒤 조건 누락이 늘면 그 요청군은 더 긴 예산을 가져야 한다.

토큰 예산은 절약 항목이 아니라 품질을 어디에 쓸지 정하는 배분표다. 비용을 줄이는 가장 안전한 방법은 모든 문맥을 줄이는 것이 아니라, 답에 기여하지 않는 문맥부터 줄이는 것이다.

자주 묻는 질문

토큰 예산을 줄이면 답변 품질이 바로 떨어지나요?

요청 유형에 따라 다릅니다. 단순 변환이나 분류처럼 입력 자체가 충분한 요청은 줄여도 품질이 유지될 수 있습니다. 문서 근거와 이전 조건이 필요한 요청에서는 줄인 뒤 근거 누락이나 재질문 증가가 나타나는지 봐야 합니다.

어떤 요청에는 긴 컨텍스트 비용을 감수해야 하나요?

답이 여러 문서 조각, 긴 대화 이력, 복수 조건 비교에 의존한다면 긴 컨텍스트가 필요할 수 있습니다. 이때 판단 기준은 긴 입력을 넣었을 때 결론의 정확도나 제약 반영이 실제로 좋아지는지입니다. 단순히 불안해서 많이 넣는 것과 필요한 근거를 유지하는 것은 구분해야 합니다.

토큰 예산을 처음 나눌 때 무엇부터 보면 좋나요?

요청을 단순 변환, 짧은 분류, 문서 근거 답변, 긴 이력 의존 답변처럼 나누는 것부터 시작할 수 있습니다. 각 유형에서 입력 토큰, p95 latency, 재질문 비율을 같이 보면 줄여도 되는 영역이 보입니다. 비용만 보지 말고 품질 손실이 어디서 생기는지 함께 확인해야 합니다.