OpenAI API 위에 SaaS를 만들었다가 마진이 사라진 이야기 — AI 래퍼 스타트업의 비용 최적화 사례

이 팀이 만든 제품은 기업 내부 문서(계약서, 회의록, 기술 문서)를 업로드하면 요약·검색·Q&A를 제공하는 SaaS였다. 아키텍처는 단순했다. Next.js 프론트엔드, Supabase 백엔드, 그리고 핵심 로직은 전부 OpenAI API 호출이었다.

문서 업로드 → 청킹 → 임베딩(text-embedding-3-large) → Pinecone 저장 → 사용자 질의 시 RAG 파이프라인으로 GPT-4 Turbo 호출. 2024년 기준으로는 가장 흔한 구조였고, 프로토타입에서 프로덕션까지 8주밖에 걸리지 않았다.

문제는 비용 구조에 있었다. 이 팀의 CTO가 공개한 월별 비용 내역은 다음과 같다.

MRR $9,200에서 인프라 비용 $7,150을 빼면 $2,050이 남는다. 여기서 4명의 인건비, 사무실, SaaS 도구 비용을 빼면 실질 마진은 마이너스였다. 고객이 늘수록 적자가 커지는 구조다. 이 팀의 CTO는 이렇게 썼다: "우리는 OpenAI의 리셀러였지, SaaS 회사가 아니었다."

이 팀은 6개월에 걸쳐 다섯 가지 최적화를 순차적으로 시도했다. 각 전략의 효과와 한계를 정리한다.

가장 먼저 시도한 것은 프롬프트 엔지니어링이었다. 시스템 프롬프트를 1,200토큰에서 400토큰으로 줄이고, RAG 청크 크기를 조정해 컨텍스트 윈도우 사용량을 평균 35% 감소시켰다. 결과적으로 GPT-4 Turbo 비용이 월 $4,800에서 $3,100으로 떨어졌다.

하지만 이것만으로는 부족했다. 토큰을 아무리 줄여도, GPT-4 Turbo의 입력 단가($10/1M tokens)와 출력 단가($30/1M tokens) 자체가 높기 때문이다. 프롬프트 최적화는 20~40% 절감이 한계라는 게 이 팀의 결론이었다.

두 번째 전략은 요청 유형별로 모델을 나누는 것이었다. 단순 요약은 GPT-4o Mini로, 복잡한 분석 질의만 GPT-4 Turbo로 라우팅했다. 분류기는 키워드 규칙 기반으로 시작해서 나중에 간단한 classifier 모델로 교체했다.

이 전략의 효과는 컸다. 전체 요청의 약 60%가 GPT-4o Mini로 처리 가능했고, GPT-4o Mini의 단가는 GPT-4 Turbo 대비 약 1/20 수준이었다. 모델 계층화만으로 LLM 비용이 추가로 45% 감소했다.

세 번째는 시맨틱 캐싱이었다. 같은 문서에 대해 비슷한 질문이 반복되는 패턴을 발견한 이 팀은, 질의 임베딩 간 코사인 유사도가 0.95 이상이면 캐시된 응답을 반환하도록 했다. Redis에 캐시 레이어를 추가하는 데 이틀이 걸렸다.

캐시 히트율은 평균 22%였다. "생각보다 낮다"고 느낄 수 있지만, 캐시가 작동하는 22%는 API 호출이 완전히 사라지는 것이므로 비용 절감 효과는 확실했다. 다만, 문서가 업데이트될 때 캐시 무효화 로직이 복잡해지는 문제가 있었다.

네 번째 시도는 Llama 3 70B를 직접 호스팅하는 것이었다. AWS에서 A100 GPU 인스턴스(p4d.24xlarge)를 프로비저닝하고, vLLM으로 서빙 환경을 구축했다. 이론상으로는 API 비용을 GPU 임대 비용으로 대체하면 토큰당 단가가 1/5 이하로 떨어진다.

하지만 현실은 달랐다. p4d.24xlarge의 온디맨드 가격은 시간당 $32.77이다. 월 24시간 가동하면 약 $23,600. 트래픽이 적은 시간대에도 GPU가 놀고 있어야 했다. 스팟 인스턴스를 섞으면 비용이 줄지만, 중단 리스크가 생긴다. 고객 120곳 규모에서는 셀프호스팅이 API보다 오히려 비쌌다.

이 팀의 CTO는 "셀프호스팅이 경제적으로 의미 있으려면 최소 MAU 1만, 일일 추론 요청 50만 건 이상은 되어야 한다"고 추정했다. 4인 스타트업이 감당할 규모가 아니었다.

마지막으로 이 팀이 시도한 것은 GPT-4o Mini를 자사 도메인 데이터로 파인튜닝하는 것이었다. 6개월간 축적된 고객 질의-응답 쌍 약 15,000건을 학습 데이터로 사용했다. OpenAI의 파인튜닝 API를 사용했고, 학습 비용은 1회당 약 $200이었다.

결과는 인상적이었다. 파인튜닝된 GPT-4o Mini가 기존 GPT-4 Turbo + RAG 파이프라인의 응답 품질 90%를 재현했다. 특히 자사 도메인(계약서·회의록)에 특화된 요약 작업에서는 GPT-4 Turbo와 거의 차이가 없었다. 비용은 GPT-4 Turbo 대비 1/15 수준.

5가지 전략을 모두 거친 뒤, 이 팀이 정착한 아키텍처는 다음과 같은 하이브리드 구조였다.

여기에 시맨틱 캐싱(히트율 22%)과 프롬프트 최적화를 결합한 결과, 월 LLM 비용이 $6,000에서 $1,100으로 감소했다. 인프라 총비용은 $2,200 수준이 되었고, MRR $9,200 대비 인프라 비율이 24%로 떨어졌다. 비로소 인건비를 포함해도 흑자가 가능한 구조가 됐다.

이 사례에서 추출할 수 있는 실무 교훈은 명확하다.

첫째, API 비용을 고정비가 아니라 변동비로 계산해야 한다. 고객이 2배 늘면 API 비용도 2배 가까이 늘어난다. SaaS의 전통적인 강점인 "규모의 경제"가 AI 래퍼에서는 작동하지 않는다. 가격 모델을 설계할 때 반드시 토큰 소비량을 시뮬레이션해야 한다.

둘째, 모델 선택은 아키텍처 결정이다. 처음부터 모든 요청에 최고 성능 모델을 쓰는 것은 "모든 API 엔드포인트를 c5.4xlarge에서 돌리는 것"과 같다. 요청 분류기를 만들고, 각 유형에 맞는 모델을 배정하는 것이 첫 번째 최적화여야 한다.

셋째, 파인튜닝은 과소평가되어 있다. 많은 팀이 파인튜닝을 "나중에 할 일"로 미루지만, 도메인 특화 작업에서는 파인튜닝된 소형 모델이 범용 대형 모델보다 비용 대비 성능이 압도적으로 높다. 이 팀의 경우, 파인튜닝 단 한 번($200)으로 월 $3,000 이상을 절감했다.

넷째, "API 위에 UI를 얹는 것"은 제품이 아니다. 이 팀이 마진을 살릴 수 있었던 진짜 이유는 6개월간 축적된 고객 데이터로 파인튜닝을 했기 때문이다. 데이터가 없었다면 GPT-4o Mini 파인튜닝도 불가능했다. AI 래퍼의 진짜 moat는 UI가 아니라, 고객 데이터에서 오는 모델 특화다.

다섯째, 셀프호스팅의 손익분기점을 냉정하게 계산해야 한다. GPU 인스턴스 비용, 운영 인력, 모델 업데이트 주기를 모두 포함하면, 트래픽이 충분하지 않은 스타트업에서는 API가 거의 항상 더 싸다. 이 팀의 추정에 따르면, 일일 추론 50만 건 이상부터 셀프호스팅이 경제적 의미를 가진다.

이 사례를 참고하여, AI API 기반 SaaS를 기획 중인 팀이 출시 전에 반드시 계산해야 할 항목을 정리한다.

이 팀은 이 계산을 출시 후에야 했다. "출시 전에 했다면 가격 정책을 완전히 다르게 설계했을 것"이라고 회고했다. 구체적으로는, 사용량 기반 가격(토큰 소비에 연동)이나 티어별 기능 제한을 처음부터 적용했을 것이라고 한다.