LLM의 토큰 낭비는 모델 안에서만 생기는 문제가 아니라 요청을 만들기 전 컨텍스트 조립 단계에서 자주 시작된다.
- 시스템 지시, 사용자 질문, 대화 이력, 참고 문단이 하나의 요청으로 합쳐질 때 불필요한 내용이 섞일 수 있다.
- 낮은 관련도 문단과 중복 히스토리는 답 품질을 크게 높이지 못하면서 입력 토큰을 차지한다.
- 판단 기준은 “이 문맥이 현재 질문의 결론이나 근거를 바꾸는가”다.
- 입력 토큰 증가, p95 latency 상승, 답 품질 정체가 함께 보이면 조립 규칙을 의심해야 한다.
토큰 낭비는 긴 문서 하나보다, 매 요청에 조금씩 붙는 불필요한 문맥에서 더 조용히 커진다.
컨텍스트 조립은 여러 입력을 한 요청으로 묶는 단계다
LLM 서비스를 운영하거나 기획하는 독자가 비용 증가를 느낄 때, 먼저 볼 지점은 모델 호출 직전의 입력 묶음이다. 컨텍스트 조립(context assembly)은 사용자 질문에 시스템 지시, 이전 대화, 참고 문단, 출력 형식 안내를 붙여 하나의 요청으로 만드는 과정이다. 흐름은 보통 “기본 지시문을 붙이고 → 사용자의 현재 질문을 넣고 → 필요한 대화 이력과 참고 텍스트를 더하고 → 출력 형식을 지정하는” 식으로 이어진다. 이 단계가 넓게 설계되면 모델은 답에 필요하지 않은 문장까지 함께 읽는다.
문제는 각 조각이 따로 보면 그럴듯하다는 데 있다. 시스템 지시는 안전한 답변을 위해 필요하고, 대화 이력은 맥락을 유지하게 하며, 참고 문단은 근거를 제공한다. 하지만 모든 요청에 모든 조각을 같은 강도로 붙이면 다른 문제가 생긴다. 같은 주의 문구가 시스템 지시와 사용자 프롬프트에 중복되고, 관련도가 낮은 참고 문단이 함께 붙고, 현재 질문과 상관없는 긴 대화 이력까지 남으면 입력 토큰이 조용히 불어난다.
명시적 가상 시나리오를 보자. 내부 문서 검색 기능에서 사용자가 “이 정책의 적용 대상만 알려줘”라고 물었는데, 요청에는 정책 전문, 이전 질의응답 전체, 관련도가 낮은 문서 조각, 긴 출력 규칙이 함께 들어간다. 답에는 적용 대상 문단과 짧은 출력 형식만 필요했을 수 있다. 나머지는 품질 보험처럼 보이지만, 실제로는 처리 시간과 비용을 늘리는 문맥이 된다.
여기서 판단 기준은 분명하다. 어떤 문맥을 제거했을 때 결론, 근거, 제약 조건이 바뀌지 않는다면 그 문맥은 현재 요청에는 약한 후보일 수 있다. 전체 비용과 지연의 큰 그림은 LLM 컨텍스트가 길어질수록 왜 비용과 지연이 같이 커질까에서 먼저 잡을 수 있고, 여기서는 그 비용이 입력 조립 단계에서 어떻게 생기는지에 집중한다.
토큰 낭비는 중복, 낮은 관련도, 과도한 히스토리에서 자주 생긴다
컨텍스트 조립에서 가장 흔한 낭비는 세 가지다. 첫째, 같은 조건을 시스템 지시와 사용자 프롬프트에 반복해서 넣는 중복 지시다. 예를 들어 “짧게 답하라”는 지시가 기본 프롬프트와 사용자용 템플릿에 동시에 들어가면, 답의 방향은 거의 같지만 입력은 불어난다. 둘째, 현재 질문과 관련이 약한 참고 문단을 “혹시 몰라서” 함께 넣는 낮은 관련도 문맥이다. 환불 조건을 묻는 요청에 배송 예외, 멤버십 혜택, 오래된 이벤트 안내까지 붙는 식이다. 셋째, 이전 대화 전체를 계속 유지해 현재 질문과 상관없는 이력까지 읽히는 과도한 히스토리 보존이다. 사용자가 마지막에 단순 문장 수정만 요청했는데 이전 상담 흐름 전체가 계속 붙는다면 이 패턴을 의심할 수 있다.
이 낭비는 단순히 입력이 길다는 뜻이 아니다. 답에 필요한 문맥과 답을 흐리게 만드는 문맥이 섞인다는 뜻이다. 낮은 관련도 문단이 많아지면 모델은 어느 부분을 우선해야 하는지 더 복잡한 입력을 받는다. 결과적으로 입력 토큰은 늘고 p95 latency가 올라가는데, 답 품질 평가는 그대로일 수 있다.
운영 지표는 다음처럼 읽을 수 있다.
| 신호 | 가능한 원인 | 다음 점검 |
|---|---|---|
| 입력 토큰 분포가 넓어짐 | 요청별 조립 규칙이 일관되지 않음 | 어떤 요청에 어떤 조각이 붙는지 확인 |
| 짧은 질문의 응답 지연이 길어짐 | 불필요한 히스토리 또는 참고 문단 포함 | 질문 유형별 기본 컨텍스트 길이 확인 |
| 답 품질은 정체, 요청당 비용은 증가 | 추가 문맥의 기여도가 낮음 | 문맥 제거 후 결론 변화 여부 비교 |
| 동일 질문군에서 입력 토큰만 계속 증가 | 중복 지시나 기본 프롬프트 비대화 가능성 | 공통 지시문과 사용자 프롬프트 중복 확인 |
| 특정 요청만 지연이 튐 | 긴 문서나 긴 이력이 예외 없이 포함됨 | 예외 요청의 조립 경로 확인 |
이 표의 목적은 원인을 모델 성능으로 바로 돌리지 않게 하는 것이다. 모델이 갑자기 느려졌다고 보기 전에, 같은 요청에 붙는 입력이 달라졌는지 봐야 한다. 입력 토큰 증가와 p95 latency 상승이 함께 보이면 긴 히스토리나 참고 문단을 먼저 보고, 답 품질은 안정적인데 요청당 비용만 오르면 중복 지시나 낮은 관련도 문맥을 먼저 의심한다. 이 조합이 반복되면 컨텍스트 조립 레이어가 첫 번째 용의자가 된다.
답에 쓰이지 않는 문맥은 비용뿐 아니라 판단도 흐린다
토큰 낭비가 비용 문제로만 보이면 절반만 본 것이다. 답에 쓰이지 않는 문맥은 비용을 늘릴 뿐 아니라, 어떤 근거를 중심으로 답해야 하는지도 흐릴 수 있다. 특히 서로 다른 조건이나 오래된 대화 이력이 함께 들어가면 답변이 지나치게 조심스럽거나 일반적인 문장으로 흐를 수 있다.
상황별 분기는 이렇게 잡을 수 있다. 현재 질문이 단일 문장 변환이나 짧은 분류라면 과거 이력과 긴 참고 문단은 기본적으로 줄이는 후보가 된다. 질문이 여러 문서의 조건을 비교해야 한다면 긴 문맥이 필요하지만, 이 경우에도 관련도가 낮은 문단은 제거 후보로 남는다. 입력을 줄이는 기준은 “짧게 만들기”가 아니라 “현재 답에 필요한 근거만 남기기”다.
다만 이 글은 대응 전략을 완성하는 글이 아니다. 조립 단계에서 낭비가 중복 지시인지, 낮은 관련도 문단인지, 불필요한 긴 이력인지 확인했다면 다음 질문은 요청 유형별로 토큰 예산을 어떻게 다르게 줄 것인가다. 그 판단은 LLM 토큰 예산은 언제 줄이고 언제 더 써야 할까에서 이어진다.
좋은 컨텍스트 조립은 많이 넣는 기술이 아니라, 지금 질문에 필요한 문맥만 남기는 선별 과정이다. 이 차이를 놓치면 서비스는 품질 개선보다 비용 증가를 먼저 경험한다.
자주 묻는 질문
컨텍스트 조립 문제와 모델 성능 문제는 어떻게 구분하나요?
같은 유형의 요청에서 입력 토큰과 p95 latency가 함께 늘었는데 답 품질은 크게 변하지 않는다면 조립 문제를 먼저 봐야 합니다. 모델 성능 문제라면 입력 길이와 무관하게 오류 패턴이나 답변 품질 저하가 더 넓게 나타날 가능성이 큽니다.
대화 이력은 많이 남길수록 안전한가요?
현재 질문이 이전 조건에 의존한다면 이력이 필요합니다. 하지만 단순 변환이나 짧은 확인 요청에도 전체 이력이 붙으면 비용과 지연만 늘 수 있습니다. 이력은 전부 보존할 대상이 아니라 현재 답에 영향을 주는 조건 중심으로 다뤄야 합니다.
참고 문단을 줄이면 답이 부실해지지 않나요?
필요한 근거 문단을 줄이면 부실해질 수 있습니다. 하지만 관련도가 낮거나 중복된 문단을 줄이는 것은 품질 손실보다 비용 절감에 더 가까운 조정입니다. 제거 전후로 결론과 근거가 바뀌는지 비교하면 안전하게 판단할 수 있습니다.