LLM을 제품에 붙이고 월정액을 설계할 때, 대부분의 기획은 비슷한 순서로 흘러간다. 예상 사용자 수를 잡고, 대화량을 추정하고, 여기에 API 단가를 곱해 마진을 얹는다. 종이 위에서는 합리적인 계산이다. 문제는 실제 사용 패턴이 이 순서를 처음부터 뒤집는다는 점이다.
LLM 기반 안내 서비스의 현장 운영 사례를 보면, 기획 단계에서 예상한 하루 토큰 사용량과 실제 사용량 사이에 3.8배 차이가 났다. 이 격차는 사용자 수 오차가 아니라 대화 구조 자체에서 비롯됐다. 대화가 길어질수록 이전 기록 전체를 매 요청에 포함해야 하기 때문에, 사용자가 한 명 늘 때보다 한 세션이 길어질 때 토큰 사용량이 훨씬 빠르게 증가한다. 아이들이 로봇에게 퀴즈를 내거나 끝말잇기를 반복하는 식의 행동, 즉 기획자가 상정하지 않은 패턴이 피크 원가를 결정한다.
이 구조를 이해하고 나면 질문이 달라진다. "요금을 얼마로 받을까?"가 아니라 "한 세션이 어디까지 길어져도 우리가 감당할 수 있는가?"
왜 평균 사용량 추정은 틀릴 수밖에 없는가
LLM 대화 비용이 일반 API 호출 비용과 다른 점은 컨텍스트 누적이다. 첫 질문은 시스템 프롬프트 정도만 입력 토큰으로 들어가지만, 다섯 번째 질문에서는 앞선 네 번의 대화가 통째로 다시 전송된다. 대화가 열 번 이어지면 입력 토큰은 기하급수적으로 쌓인다.
기획 단계에서 "사용자당 평균 3턴"으로 잡았더라도, 실제 운영에서 20퍼센트의 사용자가 10턴 이상을 이어가면 전체 토큰 비용이 계획과 완전히 다른 숫자가 된다. 평균은 이 꼬리 부분을 보정하지 못한다. 월정액 수익 모델에서 손실은 평균이 아니라 꼬리에서 발생한다.
여기에 사용자 행동의 예측 불가능성이 더해진다. 도구로 사용하는 사람은 짧게 묻고 떠나지만, 호기심이 생긴 사람은 길게 대화하고, 아이들은 시스템이 상정하지 않은 방식으로 반복 입력한다. 이 차이를 기획 단계에서 예측하기 어렵다면, 예측이 빗나갔을 때 손실을 제한하는 구조를 먼저 만드는 편이 낫다.
비교 축 1. 요금 결정의 출발점이 어디인가
월정액을 설계하는 방식은 크게 두 가지로 나뉜다. 예상 사용량에서 출발하는 방식과, 원가 상한에서 역으로 계산하는 방식이다.
예상 사용량 기반 접근은 유동인구, 전환율, 평균 대화 턴, 턴당 토큰을 곱해 월간 예상 토큰량을 만들고, 여기에 API 단가를 곱해 원가를 구한 뒤 마진을 더해 요금을 정한다. 계산이 단순하고 영업에서 근거로 제시하기 쉽다. 단, 실제 사용 패턴이 예상보다 꼬리가 두꺼울 때 손실을 막을 안전망이 없다.
원가 상한 역산 접근은 순서가 반대다. 먼저 "이 제품에서 로봇 한 대당 한 달에 API 비용으로 얼마까지 쓸 수 있는가"를 정한다. 이 숫자가 정해지면 여기서 역으로 하루 허용 토큰량, 세션당 허용 턴 수, 피크 시간대 동시 접속 상한이 도출된다. 요금은 이 상한이 커버하는 사용량을 기준으로 결정한다.
두 방식의 차이는 불확실성을 누가 부담하느냐다. 예상 사용량 기반 접근은 예측 오차를 공급사가 고스란히 흡수한다. 원가 상한 역산 접근은 초과 사용에 대한 처리 방식, 즉 속도 제한, 추가 과금, 응답 큐 등을 계약 전에 설계해 두기 때문에 예측 오차의 영향을 통제 가능한 범위로 묶는다.
어떤 방식이 항상 낫다고 단정하기 어렵다. 사용 패턴이 예측하기 쉬운 폐쇄형 서비스라면 예상 사용량 기반도 작동한다. 반면 불특정 다수를 상대하거나 행동 패턴이 다양한 공개 서비스라면, 원가 상한을 먼저 정하지 않으면 월정액의 손익 구조가 실제 운영에서 뒤집힐 가능성이 높다.
비교 축 2. 피크를 어떻게 다루는가
월정액에서 평균 사용량이 아니라 피크가 수익성을 결정한다는 점은 이미 통신, 클라우드, 스트리밍 인프라에서 오랫동안 확인된 구조다. LLM 서비스도 같은 논리가 적용된다.
피크 사용량을 추정하는 방식 중 하나는 유동인구(N)와 전환율(p)로 시간대별 대화 건수를 구한 뒤, 대화당 턴 수와 턴당 토큰을 곱해 토큰 사용량으로 환산하는 것이다. 이때 평균값이 아니라 상위 95퍼센트 구간을 기본 제공량의 기준으로 삼으면, 일반적인 운영 범위 대부분을 월정액 안에서 처리하면서도 극단적 피크만 별도 조건으로 분리할 수 있다.
상위 5퍼센트의 초과 트래픽을 어떻게 처리하느냐는 제품 설계 결정이다. 응답 속도를 줄이거나, 추가 슬롯 과금을 적용하거나, 특정 시간대 이후 요청을 큐에 넣는 방식이 있다. 어느 쪽이든 계약 전에 정해두지 않으면, 피크가 발생할 때마다 내부에서 즉흥적으로 결정해야 하고 고객과의 기대 차이가 생긴다.
비교 축 3. 토큰을 줄이는 방법의 트레이드오프
원가 상한을 정한 뒤에는 그 범위 안에서 실제 호출 비용을 낮추는 설계가 필요하다. 접근 방법은 크게 세 가지이며, 각각 적합한 조건이 다르다.
반복 질문 캐싱은 답이 고정된 질문을 사전에 등록해 LLM을 호출하지 않는 방식이다. 특정 사례에서는 전체 질문의 약 46퍼센트가 이 범주에 해당했고, 해당 요청의 응답 시간이 2.1초에서 0.05초로 줄었다. 호출 비용도 0이다. 단, 캐시는 답이 변하지 않는 질문에만 유효하다. 표현이 달라도 같은 답을 원하는 경우를 얼마나 정확히 묶느냐가 적중률을 결정한다.
질문 경로 분리는 복잡도에 따라 규칙 기반, 경량 모델, 상위 모델로 요청을 나누는 방식이다. 단순한 위치 확인은 규칙으로, 짧은 개방형 질문은 소형 모델로, 조건이 복잡한 추천이나 설명은 상위 모델로 보낸다. 이 방식은 상위 모델 호출 횟수를 줄이는 동시에, 단순 요청에 반복해 보내던 컨텍스트도 함께 줄인다. 경로 분류 기준을 잘못 잡으면 경량 모델이 처리하지 못하는 질문이 응답 오류로 이어질 수 있다.
컨텍스트 압축은 전체 대화 기록 대신 최근 핵심만 요약해 다음 요청에 전달하는 방식이다. 특정 사례에서는 입력 토큰이 58퍼센트 줄었다. 단, 요약 과정에서 어떤 정보를 남기고 버릴지를 정하는 규칙이 필요하고, 이 규칙이 부정확하면 대화 흐름이 끊기거나 이전 정보를 잘못 전달할 수 있다.
세 방식을 함께 적용하면 전체 토큰 비용을 크게 줄일 수 있다. 하나씩 적용 순서를 정한다면, 캐싱이 가장 구현이 단순하고 효과가 즉각적이므로 먼저 시작하는 편이 낫다.
공급사 단가 협상에서 미리 정해야 할 것들
원가 상한을 계산했다면 그다음은 API 공급사와의 단가 협상이다. 표준 가격표를 그대로 쓰면 원가 상한이 좁아지기 때문에, 협상에서 조정 가능한 조건을 명확히 해두는 것이 중요하다.
월간 최소 사용량 약정은 공급사에 물량 예측 가능성을 주는 대신 단가를 낮추는 근거가 된다. 단, 약정량을 실제 사용량보다 높게 잡으면 미달 시 고정 손실이 발생하므로, 보수적으로 예상한 하한선을 기준으로 약정하는 것이 안전하다.
피크타임 동시 접속 슬롯과 초당 최대 요청 수 상한도 단가에 영향을 준다. 무제한으로 열어두면 응답 지연은 줄지만 단가를 낮추기 어렵다. 현장 시간대별 요청량을 분석해 감당 가능한 상한을 정한 뒤, 이를 계약서에 명시하면 초과분의 과금 조건을 협의할 근거가 생긴다.
약정 초과분과 미달분의 과금 조건은 계약서에 구체적으로 적어야 한다. 할인율만 보고 계약하면, 실제 운영에서 예상과 다른 패턴이 나왔을 때 어느 쪽이 추가 비용을 부담하는지 불분명해진다.
월정액 고객이 원하는 것과 공급사가 설계해야 하는 것의 간극
고객이 월정액을 원하는 이유는 대개 예산 예측 가능성이다. 매달 변하는 청구서는 내부 결재와 비용 배분을 복잡하게 만든다. 이 요구 자체는 합리적이다.
문제는 고객의 예측 가능성을 공급사의 불확실성으로 전환하는 계약 구조다. 고객이 매달 같은 금액을 내는 동안, 공급사는 피크 사용량에 따라 달라지는 API 비용을 고정 수익으로 감당해야 한다. 이 간극을 좁히려면 "얼마를 받을지"가 아니라 "어디까지를 기본 제공에 포함하고, 그 범위를 넘으면 어떻게 할지"를 먼저 정해야 한다.
이 설계가 요금 협의보다 앞에 있어야 한다. 요금을 먼저 제시하고 나중에 원가를 맞추려 하면, 실제 운영에서 사용량이 늘 때마다 수익 구조가 흔들린다. 원가 상한을 먼저 정한 뒤 요금을 역산하면, 적어도 어느 사용량까지 월정액이 버티는지를 숫자로 확인한 상태에서 계약 테이블에 앉을 수 있다.
LLM 기반 제품의 월정액을 처음 설계한다면, 요금표 작성보다 먼저 할 일이 있다. 하루 최대 허용 토큰량을 정하고, 그 숫자가 어떤 사용 패턴에서 깨지는지 시뮬레이션하는 것이다. 그 시뮬레이션 결과가 요금, 계약 조건, 기술 설계를 한 방향으로 정렬하는 기준이 된다.
