LLM 안내로봇의 월정액을 설계하며 마주한 문제들

로봇이 말을 잘할수록 비용이 커졌다

저는 자율주행 로봇 회사의 전략기획팀장으로서, LLM 기반의 백화점 안내로봇을 신사업을 추진한 경험이 있습니다. 당시 정식 계약을 앞두고 실제 사용량과 운영비를 확인하기 위해 백화점 1층 중앙 로비에서 PoC를 진행했습니다. 

기존 제품들은 화면에서 매장을 선택하면 로봇에 있는 디스플레이를 통해 위치를 알려줬지만, 저희는 음성 질문을 대화형 LLM으로 처리하고 직접 안내하는 서비스를 제공했습니다. PoC 비용은 시범 운영 범위에 맞춰 미리 정한 금액으로 고객사에 청구했고요. 

이후 정식 계약에서 제안할 월 리스료를 설계하려면, 실제 사용량에 따라 달라지는 우리 회사의 LLM API 원가를 계산해야 했습니다. 그래서 기획 단계에서는 “3층 여성복 매장 어디로 가야 해?” 같은 길 안내가 가장 많을 것으로 예상했습니다. “5만 원대 부모님 선물 추천해 줘”, “지하 1층 푸드코트에서 인기 있는 메뉴가 뭐야?” 같은 질문도 규칙 기반으로 처리하도록 준비했습니다.

그러나 문제는 주말에 드러났습니다. 로봇 주변에 방문객이 몰리면서 질문 수가 늘었고, 질문의 종류도 저희 예상과 달랐습니다. 목적지만 확인하고 떠나는 사람도 있었지만, 아이들은 주로 로봇에게 퀴즈를 냈습니다. “너 몇 살이야?”, “노래 한 곡 불러줘”처럼 안내와 상관없는 질문도 이어졌죠. 끝말잇기를 하거나 같은 질문을 여러 번 반복하는 경우도 있었습니다.

저희가 기획 단계에서 잡은 기준은 로봇 1대당 하루 200~300건의 대화와 약 50만 토큰이었습니다. 백화점 유동인구와 로봇 앞 체류 시간을 바탕으로 계산한 수치였지만, 실제 현장에서는 대화 한 건의 길이가 예상보다 빠르게 늘어났습니다.

대화가 길어질수록 입력 토큰도 함께 증가했습니다. 자연스러운 대화를 위해 이전 대화 기록을 매번 요청에 포함했기 때문입니다. 첫 질문에서는 기록이 거의 없지만, 다섯 번째나 열 번째 질문에서는 앞선 대화가 그대로 다시 전송됩니다. 이용자가 한 명 더 느는 것보다 한 세션이 길어지는 쪽이 토큰 사용량에 더 크게 영향을 주는 구간이 있었습니다.

오픈 첫 주말, 대시보드에서 API 호출 로그와 토큰 사용량을 확인했습니다. 로봇 1대의 하루 사용량은 약 190만 토큰으로, 예상치의 3.8배였습니다.
 

하루 사용량을 월 기준으로 환산해 리스료와 비교하자 문제가 분명해졌습니다. 고객사에서 받는 금액보다 우리 회사가 클라우드 LLM 공급사에 내야 할 API 비용이 커질 수 있었습니다. 사용자가 늘수록 호출당 변동비가 빠르게 늘어나는 구조였습니다.

그때부터 질문은 “어떤 모델을 붙일까?”에서 “한 번의 대화에 얼마가 드는가?”로 바뀌었습니다. 좋은 답변을 만드는 일과 그 답변을 계속 제공할 수 있는 원가를 만드는 일은 별개의 문제였습니다. 고객사에 월정액을 제시하려면, 먼저 우리가 부담할 수 있는 비용의 상한부터 정해야 했습니다. 다음 장에서는 왜 백화점이 종량제가 아닌 월정액을 원했는지부터 살펴보겠습니다.
 

미리 요점만 콕 집어보면?

• AI 제품의 PoC부터 상용화까지 원가와 요금 구조를 맡는 PM·전략기획자는 실제 사용량을 기준으로 월정액을 설계해야 합니다. 분석 결과보다 많은 토큰 사용량으로 가격 결정 전략을 재설정 했던 백화점 안내 로봇 PoC 사례로 효과적인 가격 결정 전략을 제시합니다.
• 최소 사용량 약정과 피크타임 동시성 상한을 조건으로 공급 단가를 약 24% 낮추고, 고객사가 원하는 월정액 요금에 상위 95% 사용량을 반영했습니다.
• 빈출 질문 캐시, 규칙·1B 경량 모델, 대화 맥락 압축을 적용해 전체 토큰 비용을 70% 이상 줄인 과정을 정리합니다.

백화점은 왜 종량제가 아니라 월정액을 원했나?

고객사와 요금제를 협의할 때, 저는 처음에 종량제를 생각했습니다. 로봇이 처리한 대화 수나 사용한 토큰을 기준으로 매달 청구하면 계산이 단순했습니다. 사용량이 적은 달에는 고객사도 적게 내고, 많이 쓴 달에는 그만큼 비용을 부담하면 됩니다. 공급자 입장에서는 손실을 줄일 수 있는 방식이기도 했습니다.

하지만 백화점 구매팀의 기준은 달랐습니다. 구매팀은 방문객이 얼마나 올지, 주말에 로봇을 얼마나 오래 사용할지와 별개로 연간 예산을 먼저 확정해야 했습니다. 매달 청구서가 달라지면 내부 결재와 비용 배분이 어려워집니다. 기술적으로는 합리적인 종량제가, 구매 절차 안에서는 예측하기 어려운 변동비가 되는 셈입니다.

백화점이 원한 것은 명확했습니다. 로봇 한 대를 운영하는 데 매달 얼마가 드는지, 추가 예산을 언제 승인해야 하는지를 계약 전에 알고 싶어 했습니다. “사용한 만큼 정산하면 되지 않느냐”는 말로는 이 요구를 해결할 수 없었습니다. 그래서 월정액 요금제를 놓고 다시 계산했습니다. 고객사에 고정 금액을 제시하면 영업은 쉬워질 수 있지만, 공급사에는 다른 문제가 생깁니다.

평일 낮처럼 사용량이 적은 날과 주말 피크타임의 사용량을 같은 금액으로 묶어야 하기 때문입니다. 주말마다 대화량이 늘면 고객사는 같은 금액을 내지만, 우리는 LLM 공급사에 더 많은 변동비를 지불해야 합니다.

월정액은 고객사에 비용을 예측할 수 있게 해주는 대신, 공급사에 사용량의 불확실성을 넘기는 계약이었습니다. 이 구조를 모른 채 월 리스료를 정하면, PoC에서 겪은 190만 토큰의 하루 사용량이 그대로 손실로 돌아올 수 있었습니다.

결국 요금제 협의에서 먼저 정해야 할 것은 월 얼마를 받을지가 아니었습니다. 어디까지 기본 요금에 포함할지, 그 사용량을 넘었을 때 누가 어떤 방식으로 부담할지를 정하는 일이었습니다. 그러려면 두 가지 계산이 필요했습니다. 공급사에 지불하는 토큰 단가를 낮추는 일과, 피크타임에 발생할 사용량을 예측하는 일입니다.

다음 장에서는 첫 번째 문제부터 다루겠습니다. 표준 API 가격표를 그대로 적용하지 않고, 공급사와 어떤 조건을 맞바꿔 단가를 낮췄는지 설명하겠습니다.

먼저 낮춘 것은 모델이 아니라 공급 단가였다

월정액을 제시하기 전에 표준 API 가격표를 놓고 다시 계산했습니다. 로봇 1대가 하루에 사용하는 토큰과 공급사의 100만 토큰당 단가를 곱하고, 여기에 하드웨어 감가상각과 통신비를 더했습니다. 고객사에서 받는 월 리스료와 나란히 놓으니, 사용량이 예상보다 조금만 늘어도 남는 금액이 빠르게 줄어드는 구조였습니다.

이 계산에서 모델을 바꾸는 방법도 검토했습니다. 하지만 모델을 낮추면 답변 품질이나 복잡한 질문에서 문제가 생길 수 있었습니다. 아직 현장 사용 패턴을 충분히 모르는 상태에서 모델부터 바꾸면, 비용은 줄어도 안내로봇의 역할을 축소하는 결과가 될 수 있었습니다. 우선 모델의 기능을 줄이기보다 공급 단가 자체를 낮추는 쪽으로 방향을 잡았습니다.

공급사와의 협상에서 처음 제시한 조건은 월간 최소 사용량 약정이었습니다. 우리가 일정량의 토큰을 꾸준히 사용하겠다고 약속하면, 공급사도 물량을 예측할 수 있습니다. 공급사 입장에서는 매달 바뀌는 소규모 요청을 처리하는 것보다, 어느 정도의 물량이 들어올지 알고 운영하는 편이 낫습니다. 그 예측 가능성을 단가 협상의 근거로 삼았습니다.

다만 최소 사용량 약정만으로는 충분하지 않았습니다. 백화점의 주말에는 요청이 특정 시간대에 몰립니다. 하루 전체 사용량이 같더라도 한꺼번에 요청이 들어오면 공급사 서버가 처리해야 하는 부담이 달라집니다. 그래서 무제한 동시 접속을 요구하는 대신 피크타임에 허용할 동시 접속 슬롯과 초당 최대 요청 수(RPS)를 함께 정했습니다.

이 조건은 우리에게도 선택이 필요했습니다. 슬롯을 무제한으로 열어 두면 방문객이 몰리는 순간 응답 지연을 줄일 수 있지만, 공급 단가를 낮추기 어렵습니다. 반대로 상한을 너무 낮추면 로봇이 대답하지 못하는 순간이 생길 수 있습니다. 현장 운영팀과 시간대별 요청량을 맞춰 보면서, 감당할 수 있는 수준의 상한을 협의했습니다.

결과적으로 100만 토큰당 공급 단가를 약 24% 낮췄습니다. 할인율 자체보다 중요한 것은, 고객사 요금과 API 원가를 비교할 때 사용할 기준이 생겼다는 점이었습니다. 표준 가격표를 그대로 적용할 때와 비교해, 사용량이 늘어도 어느 정도까지는 월정액 안에서 감당할 수 있는지 다시 계산할 수 있었습니다.

팁 1. 공급사 단가 협상 때 합의할 세 가지 조건

• 첫째, 최소 약정량이 실제 예상 사용량과 맞는지 확인합니다. 약정량을 지키지 못하면 이익이 아닌 엄청난 고정 비용이 발생할 수 있습니다.
• 둘째, 피크타임 동시성·RPS 상한을 현장 운영팀이 감당할 수 있는지 확인합니다.
• 셋째, 약정 초과분과 미달분의 과금 조건을 계약서에 명시합니다. 할인율과 함께 이 조건을 봐야 월정액의 API 원가를 예측할 수 있습니다.

단가를 낮추는 일은 월정액의 손실 가능성을 줄여 주었습니다. 하지만 이것만으로는 주말에 실제로 얼마나 사용될지 알 수 없었습니다. 다음 장에서는 백화점의 유동인구와 대화 데이터를 이용해 기본 요금에 포함할 사용량을 계산한 과정을 설명하겠습니다.

월정액을 제시하려면 피크 사용량부터 계산해야 했다

공급 단가를 낮춘 뒤에도 한 가지가 남았습니다. 백화점에 매달 얼마를 요구할 것인가였습니다. 평균 사용량만 보고 요금을 정하면 계산은 쉽습니다. 하지만 평균은 주말 오후처럼 요청이 몰리는 시간을 설명하지 못합니다. 월정액에서 문제가 되는 것은 평일의 평균이 아니라, 특정 시간대에 얼마나 많이 몰리느냐였습니다.

통신사의 얼랑(Erlang) 통화량 산정과 우버의 피크 호출량 예측 방식에서 포아송 도착 모형을 참고했습니다. 평균값이 놓치는 피크를 찾는 데 목적이 있었습니다. 백화점 데이터에는 몇 가지 값을 넣었습니다. 먼저 유동인구를 N, 로봇에게 말을 거는 비율을 p로 두었습니다. 두 값을 곱하면 해당 시간대에 발생할 대화 요청 수를 추정할 수 있습니다.

여기에 시간당 평균 대화량 λ를 놓고 어느 시간대에 요청이 집중되는지 보정했습니다. 마지막으로 대화당 평균 턴 수 T와 턴당 평균 토큰 L을 적용해 요청을 토큰 사용량으로 바꿨습니다.

계산 순서는 단순했습니다.

• N × p로 방문객 중 실제 대화로 이어지는 건수를 추정합니다.
• 시간당 평균 대화량 λ로 평일과 주말, 시간대별 차이를 보정합니다.
• 대화당 턴 수 T와 턴당 토큰 L을 적용해 예상 토큰량을 계산합니다.

이때 N, p, λ, T, L을 모두 한꺼번에 곱하지 않았습니다. 유동인구와 전환율은 전체 대화량을 추정하고, λ는 시간대별 집중도를 보정하는 값이기 때문입니다. 기준을 섞으면 사용량을 부풀릴 수 있고, 평균만 보면 주말 피크를 놓칠 수 있어 두 값을 나눠 맞춰 봤습니다.

그다음에는 기본 요금에 어느 정도의 사용량을 넣을지 정했습니다. 모든 가능성을 월정액에 포함하면 고객사에는 편하지만, 공급사가 감당해야 할 비용이 과도하게 커집니다. 그래서 주말 피크를 포함한 사용량 분포에서 상위 95% 구간까지를 기본 요금의 기준으로 삼았습니다. 일반적인 사용량 대부분을 월정액 안에서 처리하되, 그 범위를 넘어서는 요청은 별도의 조건으로 분리하는 방식입니다.

상위 5%의 트래픽은 비정상적인 수치라고 가정하지 않았습니다. 방문객이 몰린 날일 수도 있고, 아이들이 로봇 앞에서 오래 머문 날일 수도 있습니다.

다만 그 비용까지 아무 조건 없이 공급사가 부담하면 월정액의 의미가 사라지고 가격 경쟁력에서 밀릴 수밖에 없습니다. 그래서 초과 구간에는 응답 속도를 조절하거나 추가 슬롯 과금을 적용하는 하이브리드 요금 체계를 수립했습니다.

이렇게 계산하고 나서야 백화점에 월정액을 제시할 수 있었습니다. 고객사는 매달 예상할 수 있는 금액을 내고, 우리는 평균 이하의 사용량을 가정한 요금 덕분에, 주말마다 손실을 보는 일을 피할 수 있었습니다. 월정액은 결국 피크 사용량을 어디까지 기본 요금에 포함할지 정하는 가격 정책(pricing) 전략이었습니다.

이제 요금의 상한을 계산했으니, 실제 호출 수를 줄일 차례였습니다. 다음 장에서는 모든 질문을 클라우드 LLM으로 보내지 않도록 요청을 나눈 과정을 설명하겠습니다.

모든 질문을 클라우드 LLM에 보내지 않았다

사용량의 상한을 계산한 뒤에는 클라우드 LLM을 호출하지 않아도 되는 질문을 구분했습니다. 모든 질문을 같은 모델이 답변하면 단순한 요청까지도 가장 비싼 모델이 답변하게 됩니다.

첫 번째로 처리한 것은 자주 반복되는 질문이었습니다. “화장실 어디예요?”, “유모차 대여소 위치 알려줘”처럼 답이 정해져 있고 반복해서 나오는 질문이 있었습니다. 이 질문 50개를 로컬 캐시에 등록하고, 로봇 안에서 바로 응답하도록 바꿨습니다. 전체 질문의 약 46%가 이 범주에 들어왔습니다.

캐시에 등록된 요청은 클라우드 LLM을 호출하지 않았습니다. 따라서 해당 요청의 LLM 호출 비용은 0원이었습니다. 응답 시간도 2.1초에서 0.05초로 줄었습니다. 여기서 중요한 것은 ‘전체 응답 시간이 0.05초가 된 것’보다 캐시로 처리할 수 있는 질문의 경로가 그만큼 많아졌다는 점입니다.

질문 표현이 달라도 같은 답을 요구하는 경우가 있었습니다. 의미 유사도 기반으로 묶었다면 시맨틱 캐싱, 정해진 문구를 매칭했다면 빈출 질문 캐시라고 부르는 편이 정확합니다. 용어보다 어떤 요청이 어떤 조건에서 캐시에 들어갔는지를 설명하는 것이 우선이었습니다.

두 번째는 질문의 처리 경로를 나누는 일이었습니다. 위치 확인과 층별 매장 검색은 규칙 기반 시스템으로, 규칙만으로 어려운 짧은 질문은 1B 경량 모델로 보냈습니다. 여러 조건을 조합하는 선물·메뉴 추천처럼 설명이 필요한 질문만 클라우드 상위 모델로 넘겼습니다.

이렇게 나누면 상위 모델의 호출 횟수가 줄고, 단순 안내에서 반복해 보내던 맥락도 함께 줄어듭니다. 모든 질문을 규칙으로 처리하면 표현이 조금만 달라도 응답이 끊길 수 있으므로, 세 경로의 범위를 현장 질문 사례로 나눴습니다.

세 번째는 대화 맥락을 줄이는 일이었습니다. 이전에는 대화가 이어질수록 앞선 기록 전체를 매번 다시 보내 같은 입력 토큰을 반복해서 지불했습니다. 그래서 최근 2턴의 핵심만 요약해 다음 요청에 전달했습니다. 현재 질문에 필요한 정보만 남긴 결과 입력 토큰을 58% 줄였습니다. 요약문에 남길 정보와 남기지 않을 정보를 정하는 규칙도 함께 필요했습니다.

세 조치를 적용한 뒤 전체 토큰 비용은 70% 이상 줄었습니다. 캐시로 호출 자체를 없애고, 질문을 경량 모델로 처리하며, 입력 맥락을 줄인 효과가 합쳐진 결과였습니다.

팁 2. 토큰 비용 절감 효과를 확인할 운영 지표

• 토큰 사용을 줄인 뒤에도 절감 효과가 유지되는지 보려면 기기당 하루 호출량, 세션당 입력·출력 토큰, 질문 유형별 캐시 적중률과 모델별 호출 비중, 피크타임 동시 요청과 응답 시간을 함께 기록합니다. 월 요금 대비 API 변동원가까지 연결하면 기본 제공량과 초과 조건을 조정할 근거가 생깁니다.

측정한 지표는 캐시 범위, 경량 모델 적용 대상, 동시성 상한을 조정하는 기준이 됩니다. 당시 PoC에서는 비용 절감을 위해 고객 경험을 포기할 수도 있는 값싼 모델 혹은 로컬 모델로 대체하지 않았습니다. 질문을 나누고 필요한 경우에만 클라우드 LLM을 호출하며, 대화 맥락을 필요한 만큼만 전달하는 운영 설계를 적용했습니다.

마지막 파트에서는 공급 단가·호출 경로·기본 제공량을 월정액 요금과 연결해 손익을 판단하는 기준을 정리하겠습니다. 
 

사용량이 늘어도 손해 보지 않는 구조는 호출당 원가에서 시작됐다

백화점 PoC에서 처음 확인한 것은 로봇이 질문에 잘 답하는지였습니다. 하지만 정식 계약을 검토할 수 있는 구조를 만들기 위해서는 다른 숫자가 필요했습니다. 로봇 한 대가 하루에 몇 번 호출하는지, 한 세션에서 입력 토큰이 얼마나 쌓이는지, 피크타임에 요청이 얼마나 몰리는지를 함께 봐야 했습니다.

이 과정을 지나며 고객사 요금제와 기술 설계를 따로 정할 수 없다는 것을 알게 됐습니다. 영업에서 월정액을 약속하면 운영팀은 최대 사용량을 계산해야 하고, 개발팀은 그 사용량을 감당할 호출 경로를 만들어야 합니다.

이 과정을 거치며 제 질문도 “모델을 붙이면 비용이 얼마인가?”에서 “사용량이 늘면 한 건당 얼마가 남는가?”로 바뀌었습니다. 정식 계약을 준비하면서, 고객 요금과 API 변동원가를 실제 사용량에 연결해 그 답을 계산해야 했습니다. AI 제품의 원가는 선택한 모델만으로 정해지지 않습니다. 어떤 질문을 어디로 보내고, 기본 요금에 얼마의 사용량을 포함할지 설계하는 일이 제품의 손익을 좌우하기 때문입니다.
 

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.