AI 기능의 비용 구조, 기획자가 고려할 점

 

AI 기능을 기획할 때 가장 많이 놓치는 부분이 비용 구조입니다.
기존 기능은 한 번 개발하면 추가 비용이 거의 없었는데, LLM 기반 기능은 사용량에 비례해서 계속 비용이 발생해요.
저희 팀도 이걸 몰라서 한 번 크게 당황한 적이 있었고, 그 뒤로는 기획 단계에서부터 비용을 반드시 같이 계산하게 됐습니다.
이번 글에서는 기획자 입장에서 AI 기능 비용을 어떻게 다뤄야 하는지 정리해보려고 해요.

 

토큰이라는 낯선 단위

처음엔 "토큰"이라는 단위 자체가 낯설었습니다.
글자 수와 비슷한 개념이라고 대충 이해했는데, 실제로는 한글이 영어보다 토큰을 더 많이 소비한다는 걸 나중에야 알았어요.
같은 의미의 문장이라도 한글로 쓰면 토큰 수가 꽤 늘어나서, 예상 비용을 계산할 때 이 부분을 놓치면 실제 비용이 예상보다 훨씬 크게 나옵니다.
저희는 실제 사용자 발화 샘플 200개를 모아서 평균 토큰 수를 먼저 측정하고, 그걸 기준으로 예상 비용을 잡는 방식으로 바꿨어요.

 

예상보다 많이 나온 사례

저희가 처음 사내 문서 검색 챗봇을 열었을 때, 예상 호출량을 하루 500건 정도로 잡았습니다.
그런데 오픈 첫 주에 하루 2,000건 가까이 호출이 들어왔어요.
알고 보니 몇몇 사용자가 같은 질문을 조금씩 바꿔서 여러 번 반복 입력하고 있었고, 저희가 만든 폴백 로직도 실패할 때마다 내부적으로 재시도 호출을 하도록 되어 있었습니다.
그 결과 한 달 예상 비용의 세 배 가까운 청구서를 받고서야 문제를 알아챘어요.
그 뒤로는 재시도 횟수에 상한을 걸고, 사용량이 예상치의 150%를 넘으면 알림이 오도록 모니터링을 붙였습니다.

 

캐싱으로 줄일 수 있는 부분

똑같거나 비슷한 질문이 반복되는 경우, 매번 모델을 새로 호출하는 건 낭비입니다.
저희는 자주 나오는 질문 패턴을 모아서, 응답을 캐싱해두고 일정 기간 재사용하는 구조를 만들었어요.
전체 호출의 30% 정도가 이 캐시로 대체되면서, 비용이 눈에 띄게 줄었습니다.
다만 캐싱한 답변이 오래돼서 정책이 바뀐 내용을 그대로 보여주는 위험도 있어서, 캐시 유효 기간을 문서 갱신 주기와 맞춰서 관리해야 했어요.

 

가격 정책을 설계할 때의 고민

사용자에게 직접 과금하는 AI 기능이라면, 비용 구조를 가격 정책에도 반영해야 합니다.
저희는 한 유료 기능에서 "무제한 사용"을 내세웠다가, 일부 사용자가 하루에 수백 번씩 호출하면서 원가를 훌쩍 넘기는 상황을 겪었어요.
결국 월 사용량에 합리적인 상한을 두고, 그 이상은 추가 요금을 받는 구조로 바꿨습니다.
사용자 입장에서는 아쉬울 수 있지만, 서비스가 지속 가능하려면 이 부분을 명확히 하지 않으면 안 된다는 걸 그때 배웠어요.

 

PRD에 비용 항목을 넣기 시작한 이유

이런 일을 몇 번 겪고 나서, 저희는 PRD에 "예상 비용" 섹션을 필수로 넣기 시작했습니다.
예상 호출량, 평균 토큰 수, 월 예상 비용, 그리고 예상치를 초과했을 때의 대응 방안까지 이 네 가지를 반드시 채우도록 했어요.
처음엔 이 섹션을 채우는 게 귀찮다는 반응도 있었는데, 실제로 예산 초과 사고를 겪은 뒤로는 다들 이 섹션의 필요성에 동의하게 됐습니다.

 

모델을 고를 때도 비용을 함께 본다

같은 기능이라도 어떤 모델을 쓰느냐에 따라 비용 차이가 꽤 큽니다.
저희는 모든 기능에 가장 성능 좋은 모델을 쓰려다가, 실제로는 더 가벼운 모델로도 충분한 품질이 나오는 기능이 많다는 걸 테스트를 통해 확인했어요.
간단한 분류나 요약 작업은 저렴한 모델로 돌리고, 복잡한 추론이 필요한 기능에만 성능이 좋은 모델을 쓰는 식으로 나누고 나서 전체 비용이 40% 가까이 줄었습니다.

 

구독형 AI 도구 비용도 놓치기 쉽습니다

호출당 과금되는 API 비용 말고도, 팀에서 쓰는 여러 구독형 AI 도구의 비용이 은근히 쌓인다는 것도 뒤늦게 알게 됐습니다.
디자인팀은 이미지 생성 도구를, 마케팅팀은 카피 생성 도구를, 개발팀은 코드 어시스턴트를 각자 따로 구독하고 있었는데, 나중에 전사적으로 모아보니 월 구독료만 합쳐서 꽤 큰 금액이 나왔어요.
게다가 비슷한 기능을 하는 도구를 두세 개씩 중복으로 쓰고 있는 경우도 발견했습니다.
저희는 이걸 계기로 반기에 한 번씩 "AI 도구 구독 현황"을 전사적으로 취합해서 검토하는 자리를 만들었고, 첫 검토에서만 중복 구독 두 건을 정리해서 연간 비용을 꽤 아낄 수 있었어요.
API 비용만 신경 쓰다가 이런 구독료를 놓치면, 정작 큰 비용 누수는 다른 곳에서 새고 있을 수 있다는 걸 배웠습니다.

 

예산을 분기별로 다시 검토하는 프로세스

한 번 계산한 비용 예측이 계속 맞을 거라고 기대하면 안 된다는 것도 배웠습니다.
사용자 수가 늘거나 기능이 입소문을 타면 호출량이 예상과 완전히 달라지고, 반대로 모델 가격 자체가 분기마다 바뀌는 경우도 있었어요.
실제로 저희가 쓰던 모델 하나는 반년 사이에 가격이 두 번 조정됐는데, 한 번은 내려갔고 한 번은 올라갔습니다.
그래서 지금은 모든 AI 기능의 비용을 분기별로 다시 검토하는 걸 정례화했어요.
분기 시작 시점에 예상 호출량을 다시 잡고, 이전 분기 실제 사용량과 비교해서 오차가 20% 이상이면 원인을 반드시 찾아보게 했습니다.
이 프로세스를 도입한 뒤로는 예상치 못한 청구서를 받는 일이 확실히 줄었어요.

 

프리미엄 요금제를 설계하며 겪은 딜레마

비용 구조를 알고 나면, 가격 정책을 짤 때 예전보다 훨씬 조심스러워집니다.
저희가 프리미엄 요금제를 새로 설계할 때, 마케팅팀은 "경쟁사보다 저렴하게 가자"는 의견이었고, 저는 원가 계산 결과를 근거로 "이 가격이면 사용량이 많은 사용자 구간에서 오히려 손해를 본다"고 반박해야 했습니다.
숫자를 들고 회의에 들어가니 마케팅팀도 쉽게 반박하지 못했고, 결국 사용량 구간을 세분화해서 상위 5% 사용자에게는 별도 요금제를 적용하는 방식으로 절충했어요.
이 경험을 통해, 가격 정책 논의에서 기획자가 비용 구조를 정확히 들고 있으면 협상의 무게가 완전히 달라진다는 걸 느꼈습니다.
반대로 비용 근거 없이 "적당히 이 정도면 괜찮지 않을까요"라고 말했다면, 아마 마케팅팀 의견에 그대로 끌려갔을 거예요.

 

환율 변동이라는 예상 밖의 변수

해외 API를 쓰다 보니, 환율 변동이 비용에 영향을 준다는 것도 뒤늦게 알게 된 부분이었습니다.
달러 기준으로 과금되는 모델을 쓰고 있었는데, 환율이 오르면서 같은 사용량인데도 원화 기준 비용이 눈에 띄게 올라간 달이 있었어요.
처음엔 "사용량이 늘었나" 하고 로그를 뒤졌는데, 알고 보니 사용량은 그대로였고 환율만 달랐습니다.
그 뒤로는 비용 대시보드에 환율 변동 항목을 따로 표시해서, 이게 사용량 문제인지 환율 문제인지 한눈에 구분할 수 있게 만들었어요.
작은 디테일이지만, 이걸 모르고 있었다면 매달 원인 파악에 시간을 낭비했을 거라고 생각합니다.

 

개발팀과 비용을 두고 벌인 줄다리기

비용을 챙기다 보면 개발팀과 의견이 부딫히는 순간도 있었습니다.
개발팀은 더 좋은 모델, 더 긴 컨텍스트를 쓰고 싶어 했고, 저는 항상 "그만큼 비용이 늘어나는데 실제로 사용자가 체감할 정도의 품질 차이인가"를 되물어야 했어요.
한 번은 이 논쟁이 꽤 길어졌는데, 결국 실제 사용자 샘플로 두 모델의 응답을 블라인드 테스트해보자는 데 합의했습니다.

결과는 흥미로웠어요.
더 비싼 모델의 응답을 사용자들이 더 선호한 비율은 58%로, 압도적이라고 보기엔 애매한 차이였습니다.
이 결과를 근거로, 비용에 크게 민감한 기능에는 저렴한 모델을 쓰고, 사용자 만족도가 핵심 지표인 기능에만 비싼 모델을 쓰는 식으로 타협점을 찾았어요.
이 경험 이후로는 "더 좋은 모델을 쓰고 싶다"는 의견이 나올 때마다, 감이 아니라 실제 블라인드 테스트로 검증하자는 게 팀의 기본 절차가 됐습니다.

 

AI 기능의 비용은 한 번 계산하고 끝나는 게 아니라, 사용량 패턴이 바뀔 때마다 계속 다시 봐야 하는 항목이라는 걸 느낍니다.
기획자가 비용까지 고려해야 하나 싶었는데, 실제로 겪어보니 비용 구조를 모르면 좋은 기능도 오래 살아남지 못한다는 걸 알게 됐어요.

다음엔 사용량에 따라 자동으로 모델을 전환하는 구조도 한번 다뤄보고 싶습니다.