컨텍스트 윈도우에 두 번 지불하기
업데이트 September 1, 2026 · 최초 게시 September 1, 2026
컨텍스트 윈도우는 용량으로 광고됩니다. 200,000 토큰, 백만 토큰, 필요한 만큼 담을 수 있다는 식입니다. 하지만 용량은 과금 단위가 아닙니다. 과금되는 것은 보내는 양이며, 여러 턴으로 이어지는 대화에서는 매 턴마다 거의 전부를 다시 보냅니다.
이것이 두 번째 지불입니다. 20턴짜리 대화의 시작에 올린 30,000 토큰 문서는 입력 30,000 토큰이 아니라 600,000 토큰에 가깝습니다. 두 번째 턴도, 스무 번째 턴도 그 문서를 다시 보내기 때문입니다.
아무도 계산하지 않는 산술
비용은 대화 길이에 선형으로 늘지 않고 제곱에 비례해 늘어납니다. 턴 수가 두 배가 되면 컨텍스트가 계속 쌓인다고 가정할 때 입력 토큰은 대략 네 배가 됩니다. "메시지당 비용"을 모델링하고 메시지 수를 곱하는 팀은 긴 세션을 크게 과소 예측하며, 그 오차는 바로 여러분이 붙잡고 싶은 사용자에게서 가장 크게 나타납니다.
여기에 세 번째 비용이 붙는 경우도 많습니다. 여러 제공업체는 긴 컨텍스트 임계값을 넘는 요청에 할증 요율을 적용합니다. 첨부 파일 하나가 그 선을 넘기면, 초과한 토큰만이 아니라 입력과 출력을 포함한 호출 전체가 다시 가격이 매겨질 수 있습니다.
무엇을 측정할 것인가
컨텍스트 활용률을 추적하세요. 보낸 토큰 대비 모델이 실제로 필요로 한 토큰의 비율입니다. 이 분야에서 낭비 지표에 가장 가까운 값입니다. 입력 토큰은 요청이 아니라 대화 단위로 집계하고 p99를 지켜보세요 — 중앙값보다 스무 배 비싼 세션이 바로 그 구간에 있습니다.
장문 컨텍스트 가격 임계값을 넘는 요청에 대해 알림을 설정하세요. 이것은 점진적인 변화가 아니라 계단식 변화이므로, 일별 합계에서는 아무것도 눈에 띄지 않습니다.
가장 저렴한 것부터, 세 가지 해결책
안정적인 접두부를 캐시하세요. 대화 중에 시스템 프롬프트와 로드된 문서가 바뀌지 않는다면, 프롬프트 캐싱으로 반복되는 비용을 극히 일부로 줄일 수 있습니다. 여러 턴으로 이루어진 제품이라면 이것이 가장 수익률이 높은 단일 변경입니다.
기록을 의도적으로 줄이세요. 오래된 턴은 다시 보내는 값만큼의 가치를 거의 하지 못합니다. 긴 대화의 앞부분을 요약하고 원시 턴은 버리세요. 흐름은 유지하면서 그 부분에 대해 전액을 계속 내는 일은 멈출 수 있습니다.
코퍼스가 아니라 발췌문을 보내세요. 검색(retrieval)이 바로 이런 용도입니다. 창이 문서 전체를 담을 만큼 크다고 해서 문서 전체를 넣어야 하는 이유가 되지는 않습니다.
관련 글
관련 글
이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 →