게임 개발자가 긴 AI 대화 비용을 추정하는 방법
게임 내 긴 AI 대화에 드는 비용을 추정하려면 전체 플레이어 세션에 걸쳐 사용된 토큰을 측정하고, 캐시되지 않은 입력, 캐시된 입력 및 출력을 구분한 다음, 선택한 모델의 현재 요금을 적용하십시오. 마지막으로 플레이어가 각 길이별로 실제로 진행한 세션 수를 기준으로 결과에 가중치를 부여합니다. 짧은 프롬프트 테스트나 단 한 번의 “평균” 세션만으로는 후반 턴에서 반복 전송되는 대화 기록, 캐시 미스(cache miss), 비정상적으로 긴 플레이 세션을 놓칠 수 있습니다.
1. 추정하려는 단위를 정의하십시오
먼저 명확한 단위를 선택하십시오. 예를 들어 대화 세션당, 활성 플레이어 일수(player-day)당 또는 1,000개 세션당 모델 추론 비용 등으로 설정할 수 있습니다. 세션 기준 추정을 진행할 경우 세션의 시작과 종료 시점을 정의하십시오. ‘첫 대화 요청부터 30분간 요청이 없을 때까지’와 같은 실용적인 규칙을 세울 수 있으나, 이러한 타임아웃은 측정상의 선택일 뿐 보편적인 표준은 아닙니다. 다른 개발자가 추정치를 재현할 수 있도록 이를 기록해 두십시오.
플레이어 메시지만 세지 말고 모델 요청 수를 계산하십시오. 한 번의 상호작용으로도 여러 번의 호출(예: 응답 생성 후 별도의 도구 처리 호출)이 트리거될 수 있으며, 재시도로 인해 호출이 더 늘어날 수 있습니다. 게임에서 음성, 이미지 입력, 검색(retrieval) 또는 도구를 사용하는 경우, 해당 모델 토큰을 기록하는 것 외에도 이들을 별도의 비용 필드로 관리하십시오. 제공업체의 요금 체계에는 일반 텍스트 토큰 요금 외에도 도구 수수료나 모달리티별 요금이 포함될 수 있습니다. 예를 들어 OpenAI는 별도의 도구 요금을 명시하며 내장 도구에 사용된 모델 토큰은 선택한 모델의 요율로 청구된다고 명시하고 있습니다(OpenAI API pricing).
2. 요청당 실제 토큰을 측정하십시오
모든 호출에 대해 제공업체, 모델 식별자, 타임스탬프, 세션 식별자, 요청 목적, 입력 토큰 수, 출력 토큰 수 및 보고된 캐시 토큰이나 추론(reasoning) 토큰 분석 내역을 기록하십시오. 재시도, 오류, 도구 호출, 호출 완료 여부를 수집하십시오. 별도로 정당화된 제품 목적에 필요한 경우가 아니라면 대화 내용은 저장하지 않는 것이 좋습니다. 비용 추정에는 대개 토큰 총합과 운영 메타데이터만으로 충분합니다.
완료된 호출에 대해 제공업체가 보고한 사용량을 기본 측정 기준으로 사용하십시오. 사전(preflight) 토큰 계산은 프롬프트 구성 테스트에 유용하지만 최종 청구 필드와 일치하지 않을 수 있습니다. OpenAI의 문서에 따르면 보고된 출력에는 눈에 보이는 텍스트 외에도 일부 서식 및 도구 구조 토큰 등이 포함되며, 플레이어에게 보이는 내용만으로 출력을 추정하지 말 것을 권장합니다(OpenAI token-counting guide). Google의 Gemini 문서 또한 사용량 메타데이터에서 프롬프트, 캐시된 콘텐츠, 후보 출력 및 생각(thinking) 토큰 수를 구분합니다(Gemini token guide).
신규 플레이어, 복귀 플레이어, 짧은 대화와 긴 대화, 프로덕션 프롬프트 및 도구 구성을 포함하는 대표 표본을 구축하십시오. 표본 추출 단위는 세션으로 유지해야 합니다. 40턴 대화는 40개의 독립적인 플레이어 세션으로 취급하기보다 누적 비용을 가진 하나의 관측값으로 유지되어야 합니다. 프로토타입 단계에서는 고정된 스크립트 대화 세트가 프롬프트 변경 사항을 비교하는 데 도움이 되며, 출시 후에는 관측된 세션 데이터를 기반으로 예측을 진행해야 합니다.
3. 대화 기록 증가와 컨텍스트 재사용을 고려하십시오
대다수 대화 시스템에서 각 요청에는 현재 사용자 턴과 함께 대화 기록의 일부 또는 전체가 포함됩니다. 대화 기록이 반복적으로 재전송되면 플레이어 메시지가 짧더라도 턴이 진행됨에 따라 입력 토큰이 증가할 수 있습니다. 모델로 전송되는 실제 요청 페이로드를 측정하십시오. 구현 방식이 매번 진정으로 동일한 양을 전송하는 것이 아니라면 1턴 프롬프트 크기에 턴 수를 단순히 곱하지 마십시오.
캐싱은 대상이 되는 반복 입력에 적용되는 요율을 변경하지만, 전체 대화가 무료가 된다거나 영구 세션이 캐시 히트(cache hit)를 보장한다는 의미는 아닙니다. OpenAI는 프롬프트 캐싱을 변경되지 않은 프롬프트 접두사(prefix)의 재사용으로 설명하며, 새로운 입력은 여전히 처리되어야 한다고 명시합니다. 제공되는 캐시 진단 기능을 통해 캐시 읽기와 캐시 미스를 측정할 수 있습니다(OpenAI prompt-caching guide). Anthropic 또한 캐시 쓰기와 캐시 읽기를 구분하며 각각의 요율과 캐시 유지 시간을 게시하고 있습니다(Anthropic pricing and prompt caching).
원격 분석(telemetry) 데이터에서 제공업체가 보고하는 경우 캐시되지 않은 입력 토큰, 캐시된 입력 토큰, 캐시 쓰기 토큰을 구분하십시오. 대상 요청 대비 캐시 히트 비율과 실제로 캐시된 것으로 청구된 입력 토큰의 비중을 기록하십시오. 이 둘은 서로 다른 질문에 답합니다. 반복되는 접두사가 작다면 요청 전반의 히트율이 높더라도 캐시된 전체 토큰의 비중은 완만할 수 있습니다. 캐시 적용 요건, 최소 크기, 만료 시간, 프롬프트 접두사 안정성, 모델 지원 여부는 제공업체마다 다르므로 사용량 데이터로 확인된 절감액만 반영하십시오.
4. 투명한 계산식을 통해 요율을 적용하십시오
100만 토큰당 가격이 책정된 모델의 경우, 각 세션을 다음과 같이 계산하십시오:
세션 비용 = (캐시되지 않은 입력 × 입력 요율 + 캐시된 입력 × 캐시된 입력 요율 + 캐시 쓰기 × 캐시 쓰기 요율 + 출력 × 출력 요율) ÷ 1,000,000 + 기타 적용 가능한 요금
배포된 구성의 정확한 모델, 엔드포인트, 모달리티, 리전 및 서비스 등급에 해당하는 요율을 사용하십시오. 요율과 모델 카탈로그는 변경되므로 예산을 편성하기 직전에 제공업체의 요금 페이지에서 직접 확인하십시오. 캐시에서 저장된 토큰과 기간에 대해 비용을 청구하는 경우 스토리지 비용을 포함하십시오. 예를 들어 Gemini의 공개 요금표에는 유료 사용을 위한 토큰 범주와 특정 컨텍스트 캐싱 구성에 대한 저장 시간당 요금이 나열되어 있으며, 청구 관련 문서에는 입력, 출력, 캐시된 토큰 및 캐시 저장 기간이 청구 가능 요인으로 명시되어 있습니다(Gemini pricing; Gemini billing).
직접 계산해 보면 가정된 내용이 명확해집니다. 예시를 위해 한 세션에 할당되어 측정된 호출에 캐시되지 않은 입력 토큰 18,000개, 캐시된 입력 토큰 12,000개, 출력 토큰 6,000개가 포함되어 있다고 가정해 보겠습니다. 2026년 12월 31일까지 유효하도록 게시된 Gemini 3.8 Flash 유료 등급 요율(100만 입력 토큰당 $0.75, 100만 캐시 토큰당 $0.075, 100만 출력 토큰당 $3.75)을 적용하면 적용 가능한 캐시 저장 비용이나 기타 요금을 제외하고 $0.0135 + $0.0009 + $0.0225 = $0.0369가 산출됩니다. 이 예시는 나열된 캐시 토큰이 캐시 요율로 청구된다고 가정하며 측정된 총계 외의 초기 캐시 생성 비용은 포함하지 않습니다. 요율은 기간 한정이므로 이후 기간을 추정할 때는 다시 확인해야 합니다(Gemini pricing).
5. 세션 길이의 분포를 활용하십시오
임의로 선택한 하나의 “일반적인” 세션에 총 플레이어 수를 곱한 뒤 이를 예측치라고 부르지 마십시오. 관측된 세션을 턴 수 또는 기타 유용한 길이 구간별로 그룹화하고, 각 구간 내 평균 비용을 계산한 다음, 세션에서 차지하는 비중으로 각 구간에 가중치를 부여하십시오. 평균값과 함께 중앙값 및 상위 백분위수를 함께 유지하십시오. 평균값은 세션 볼륨을 곱했을 때 총 사용량을 추정하는 데 쓰이며, 백분위수는 더 짧거나 비정상적으로 긴 세션의 비용을 파악하는 데 유용합니다.
예를 들어 표본에 짧은 세션이 많고 매우 긴 세션이 소수 포함되어 있다면 각 구간의 세션 점유율과 구간별 비용을 모두 보고하십시오. 그러면 10,000개 세션에 대한 예측치는 모든 세션이 전체 중앙값과 유사하다고 가정하는 대신 ‘구간별 세션 수 × 구간별 평균 비용의 합계’로 계산할 수 있습니다. 게임 모드, 언어, 플랫폼 또는 신규 플레이어와 복귀 플레이어 간에 사용량 차이가 상당하다면 이들 그룹을 세분화(층화)한 후 결합하십시오. 세그먼트 분류 여부는 분석적 결정이므로 각 세그먼트가 토큰 사용량이나 요청 동작을 변화시킬 수 있는 이유를 설명해야 합니다.
6. 불확실성을 문서화하고 추정치를 업데이트하십시오
표본 수집 날짜, 세션 경계 규칙, 모델 및 엔드포인트, 프롬프트 버전, 관측된 세션 수, 캐시 히트 정의, 가격 페이지 조회 날짜, 포함된 수수료 및 제외된 구성 요소를 포함하는 간결한 가정 기록을 유지하십시오. 설명되지 않은 버퍼를 임의로 두기보다는 관측 가능한 입력값(예: 세션 길이 구성, 출력 크기, 측정된 캐시 히트 비율)을 변경하여 낙관적(low), 기본(central), 비관적(high) 시나리오를 제시하십시오. 관측된 세션을 벗어난 예상 행동은 측정된 사실이 아닌 명시적 시나리오로 취급하십시오.
추정치는 계측 체계와 청구 대상 카테고리가 갖춰진 만큼만 완전할 수 있습니다. 로거(logger) 외부로 라우팅된 호출, 재시도, API에 노출되지 않는 캐시 토큰 카테고리, 모델 측 추론 토큰, 저장 기간, 미디어 처리 또는 토큰 요율 이외의 제공업체 수수료 등은 누락될 수 있습니다. 가능한 경우 표본 사용량을 제공업체의 청구 보고서와 대조하여 확인하고, 중대한 격차를 조사하며, 모델, 프롬프트, 캐싱 동작 또는 플레이어 대상 기능을 변경한 후에는 계산을 다시 실행하십시오. 그 결과물은 관측된 워크로드에 대한 문서화된 운영 비용 추정치이며, 향후 세션이나 청구서 금액이 이와 정확히 일치할 것이라는 보증은 아닙니다.