AI 기능으로 인한 지출 폭증을 막아낸 방법

몇 달 전, 저는 사이드 프로젝트에 AI 기반 챗봇을 추가하겠다는 기발한 생각을 했습니다. 다들 아시다시피 그 과정은 이렇습니다. 사용자가 질문을 입력하면, 앱이 이를 LLM (Large Language Model)으로 보내고, 유용한 답변이 나타나는 방식이죠. 간단해 보이죠? 바로 맞습니다.

틀렸습니다.

열정적으로 해킹(Hacking)을 이어간 지 2주 만에 작동하는 프로토타입을 만들었습니다. 그러고 나서 첫 AWS 청구서가 도착했습니다. 제 OpenAI API 비용은 단 일주일 만에 조용히 87달러까지 불어나 있었습니다. 고작 활성 사용자 50명 정도인 취미 프로젝트치고는 말이죠. 마치 수도꼭지를 실수로 틀어놓은 것 같은 기분이었습니다.

여기서 제가 시도했던 것들, 실패했던 것들, 그리고 기능을 유용하게 유지하면서 비용을 마침내 통제할 수 있었던 접근 방식을 소개합니다.

초기 설정 (그리고 숨겨진 비용)

저는 전형적인 RAG (Retrieval-Augmented Generation) 스타일의 챗봇을 구축했습니다. 사용자 질문을 임베딩(Embedding)하고, 벡터 데이터베이스(Vector Database)를 검색하며, 프롬프트(Prompt)에 컨텍스트(Context)를 추가한 뒤 GPT-4를 호출하는 방식이었습니다. 코드는 깔끔했고, 응답은 인상적이었으며, 사용자들은 좋아했습니다. 하지만 컨텍스트 길이에 따라 요청당 약 0.02~~0.05달러의 비용이 발생했습니다. 사용자당 하루 20~~30회의 요청을 고려하면 계산 결과는 처참했습니다.

문제를 해결하기 위한 저의 첫 번째 시도는 GPT-3.5-turbo로 전환하는 것이었습니다. 토큰당 비용은 확실히 저렴했지만, 매번 방대한 프롬프트를 보내고 있었기 때문에 여전히 비쌌습니다. 총 청구 금액은 주당 40달러로 떨어졌지만, 여전히 지속 가능하지는 않았습니다.

효과가 없었던 것들

저는 몇 가지 흔한 "해결책"들을 시도해 보았지만 모두 역효과를 냈습니다.

Rate limiting (속도 제한) – 사용자당 시간당 요청 수를 10개로 제한했습니다. 사용자들은 봇이 느리고 반응이 없다고 불평했습니다. 하루 만에 사용자의 절반을 잃었습니다.
Context truncation (컨텍스트 절단) – 벡터 검색 결과의 상위 개수를 3개에서 1개로 줄였습니다. 답변은 얕아졌고 종종 틀렸습니다. 사용자들도 이를 눈치챘습니다.
Caching responses (응답 캐싱) – 정확히 일치하는 질문-답변 쌍을 캐싱했습니다. 하지만 자연어의 특성상 사용자가 똑같은 질문을 두 번 하는 경우는 거의 없었습니다. 캐시 히트율(Cache hit rate)은 5% 미만이었습니다.

저는 막다른 길에 다다랐습니다. 앱에는 양질의 답변이 필요했지만, 매번 새롭게 생성할 비용을 감당할 수 없었습니다.

실제로 효과가 있었던 접근 방식

토큰 수와 로그를 한참 동안 들여다본 끝에, 저는 문제가 단순히 모델 비용만이 아니라 **중복 계산 (redundant computation)**에 있다는 것을 깨달았습니다. 유사한 질문들에 대해 LLM이 거의 동일한 컨텍스트를 다시 처리하고 중복되는 답변을 생성하고 있었던 것입니다.

단순히 정확히 일치하는 요청뿐만 아니라, 의미론적으로 유사한 (semantically similar) 요청을 캐싱할 수 있는 더 스마트한 방법이 필요했습니다. 또한 품질이 결정적이지 않은 무거운 작업에는 더 저렴한 제공업체를 사용해야 했습니다.

1단계: 임베딩 (embeddings)을 활용한 시맨틱 캐싱 (Semantic caching)

정확히 일치하는 프롬프트를 캐싱하는 대신, 모든 사용자 질문의 **임베딩 (embedding)**을 생성된 답변과 함께 저장했습니다. 새로운 요청이 들어올 때마다 (작고 저렴한 모델을 사용하여) 새 질문의 임베딩을 계산한 다음, 코사인 유사도 (cosine similarity)를 사용하여 캐시에서 가장 유사한 과거 질문을 검색합니다. 만약 유사도가 임계값(저는 0.92를 사용합니다)을 넘으면, LLM 호출 없이 캐시된 답변을 즉시 반환합니다.

다음은 단순화된 Python 구현 예시입니다:

import numpy as np
from sentence_transformers import SentenceTransformer
from sklearn.metrics.pairwise import cosine_similarity
...

이 캐시를 통해 **약 40%의 히트율 (hit rate)**을 확인했습니다. 예를 들어, "비밀번호를 어떻게 재설정하나요?"라고 묻는 사용자와 "비밀번호 변경 방법은?"이라고 묻는 사용자가 이제 동일한 항목에 도달하게 된 것입니다. 이는 즉시 API 비용을 거의 절반으로 줄여주었습니다.

2단계: 작업에 적합한 모델 선택하기

캐싱을 사용하더라도 진정으로 새로운 질문에 대해서는 답변을 생성해야 했습니다. 저는 더 저렴한 모델 제공업체들을 실험하기 시작했습니다. 그때 저는 모든 LLM이 동일하게 만들어진 것이 아니며, 모든 작업에 GPT-4가 필요하지는 않다는 사실을 발견했습니다.

저는 ai.interwestinfo.com(빠르고 저렴한 모델을 제공합니다)에서 찾은 엔드포인트를 포함하여 여러 API 엔드포인트를 테스트했습니다. 단순한 FAQ 스타일의 질문의 경우, 저렴한 모델이 GPT-4만큼이나 잘 작동했습니다. 복잡하고 다단계 추론이 필요한 경우에만 비용이 많이 드는 모델로 라우팅(routing)하도록 했습니다.

저는 간단한 라우터 (router)를 구축했습니다:

import requests

def generate_answer(question, context):
...

3단계: 프롬프트 최적화 (Prompt optimization)

또한 프롬프트 (Prompt)도 다듬었습니다. 이전에는 벡터 검색 (Vector search)이 각각 200 토큰인 청크 (Chunk) 5개를 반환했습니다. 저는 이를 2개의 청크로 줄이는 대신, 가장 관련성이 높은 것만 선택하도록 청크 선택 알고리즘을 개선했습니다. 이를 통해 답변 품질을 해치지 않으면서 컨텍스트 (Context) 크기를 60% 줄였습니다.

결과

시맨틱 캐싱 (Semantic caching) + 저렴한 모델 라우팅 (Model routing)을 구현한 후:

주간 비용이 $40에서 $7로 감소했습니다 (동일한 사용자 기반 기준)
응답 시간 (Response times)이 개선되었습니다. 대부분의 요청이 캐시 (Cache)에 적중했기 때문입니다.
사용자 만족도는 안정적으로 유지되었습니다. 저렴한 모델이 80%의 질의를 문제없이 처리했고, 나머지 20%에 대해서는 여전히 강력한 모델을 사용했습니다.

트레이드오프 (Trade-offs) 및 솔직한 주의사항

모든 것이 완벽한 것은 아닙니다:

시맨틱 캐시 메모리 사용량 (Semantic cache memory usage) – 수천 개의 질문에 대한 임베딩 (Embeddings)을 저장하다 보면 양이 쌓입니다. 저는 이를 관리 가능한 수준으로 유지하기 위해 제거 정책 (Eviction policy)이 적용된 Redis를 사용합니다.
임계값 튜닝 (Threshold tuning) – 임계값을 너무 높게 설정하면 캐시 적중 (Cache hits)을 놓치고, 너무 낮게 설정하면 약간 다른 질문에 대해 잘못된 답변을 반환합니다. 최적의 지점 (Sweet spot)을 찾기 위해 검증 세트 (Validation set)를 가지고 실험해야 했습니다.
모델 품질의 변동성 (Model quality variance) – 저렴한 모델은 때때로 환각 (Hallucinate) 현상이 더 많이 발생합니다. 저는 간단한 안전 점검 (Safety check)을 추가했습니다. 만약 답변에 "제 생각에는" 또는 "아마도"와 같은 불확실한 문구가 포함되어 있다면, 비용이 더 비싼 모델로 폴백 (Fallback)하도록 했습니다.
벤더 종속 (Vendor lock-in) – 저는 하나의 저렴한 API 제공업체를 하드코딩했습니다. 만약 그들이 가격을 변경하거나 서비스를 종료하면 저는 곤란해집니다. 다음번에는 인터페이스 (Interface) 뒤로 제공업체를 추상화할 것입니다.

다시 한다면 다르게 할 점

만약 처음부터 다시 시작한다면, 저는 다음과 같이 하겠습니다:

첫날부터 시맨틱 캐시를 구축하겠습니다 — 이것이 비용 대비 가장 큰 효과를 냅니다.
모든 사용자에게 배포하기 전에 모델 품질에 대한 A/B 테스트를 실시하겠습니다.
클라우드 계정에 비용 알림 (Cost alerts)을 조기에 설정하겠습니다 (부끄럽게도 저는 하지 않았습니다).
저렴한 모델에서도 사용자에게 더 나은 경험을 제공하기 위해 스트리밍 응답 (Streaming responses)을 사용하겠습니다.

진짜 교훈

웹 앱에 AI를 추가하는 것은 단순히 프롬프트 엔지니어링 (Prompt engineering)이나 모델 선택에 관한 문제가 아닙니다. 그것은 먼저 워크로드의 경제성 (Workload's economics)을 이해하는 것에 관한 문제입니다. 모든 API 호출에는 실제 달러 비용이 발생하며, 효율성을 고려하여 설계하지 않는다면 당신의 기능은 비용 문제로 사장되거나 사용자 불만으로 인해 사라지게 될 것입니다.

당신의 설정은 어떤 모습인가요? AI 기능을 출시할 때 이와 유사한 예상치 못한 비용 문제에 직면한 적이 있나요?

이 기사는 저의 개인적인 경험을 반영합니다. 언급된 제품 URL은 제가 평가한 여러 제공업체 중 하나일 뿐입니다. 항상 직접 벤치마크 (Benchmarks)를 수행하십시오.