LLM 컨텍스트 윈도우 예산 설계

LLM 제품을 운영하다 보면 곧바로 부딪히는 문제가 있습니다. 모델의 최대 컨텍스트 길이는 커졌는데, 그렇다고 모든 정보를 무조건 다 넣는 방식이 좋은 결과를 보장하지는 않는다는 점입니다. 실제로는 정확도, 지연 시간, 비용, 회귀 위험이 함께 움직입니다.

컨텍스트는 저장소가 아니라 작업 메모리다

많은 팀이 컨텍스트 윈도우를 “많이 넣을수록 안전한 버퍼”처럼 다룹니다. 하지만 모델 입장에서는 그 창이 단순 저장소가 아니라 현재 작업을 위한 메모리입니다.

그래서 컨텍스트 설계는 “최대한 많이 넣기”가 아니라 무엇을 남기고 무엇을 버릴지 결정하는 편집 시스템이어야 합니다.

실무에서는 토큰 예산을 다음 네 영역으로 나누면 운영이 쉬워집니다.

이 구분이 중요한 이유는, 장애가 날 때 어느 구간이 비대해졌는지 바로 볼 수 있기 때문입니다. 예를 들어 RAG 문서 조각이 늘어났는지, 대화 히스토리 누적이 문제인지, 아니면 출력 토큰 상한이 너무 큰지 구분해야 대응이 가능합니다.

운영 중인 챗 시스템에서 흔히 보는 실수는 모든 대화 기록을 계속 유지하는 것입니다. 하지만 오래된 기록 중 상당수는 현재 작업과 직접 관계가 없습니다.

좋은 전략은 보통 다음 순서입니다.

즉, 히스토리는 누적이 아니라 재구성 대상입니다.

RAG 시스템에서는 상위 문서를 많이 붙일수록 정확도가 오를 것 같지만, 실제로는 관련도 낮은 조각이 섞이면 답변 품질이 떨어집니다.

예를 들어 정책 질문과 코드 디버깅 질문은 필요한 문맥 폭이 다릅니다. 같은 예산 정책을 모든 질의에 적용하면 낭비가 커집니다.

컨텍스트 예산 설계는 감각으로 운영하면 금방 흔들립니다. 최소한 아래 항목은 기록해야 합니다.

이 다섯 항목만 있어도 “정확도는 유지하면서 비용을 줄일 수 있는지”를 판단할 수 있습니다.

컨텍스트 윈도우는 넓을수록 좋은 자원이 아니라, 신호를 배치하는 제한된 예산입니다. 잘 운영하는 팀은 최대 길이를 자랑하지 않고, 어떤 정보를 어떤 순서로 어떤 상한 안에서 넣을지 체계적으로 설계합니다.