바이럴이 터지면 인프라 청구서도 터진다

바이럴이 터지는 순간, 진짜 문제는 청구서다

Cal AI가 음식 사진 한 장으로 칼로리를 추정해주는 앱으로 2년 만에 $30M(약 420억 원) 매출을 올리고 MyFitnessPal에 인수됐다. 인플루언서 수백 명을 동원한 마케팅이 주효했다는 분석이 주를 이루지만, 운영 비용 렌즈로 이 케이스를 읽으면 전혀 다른 이야기가 보인다.

핵심부터 말하면, AI 이미지 분석 앱은 바이럴을 탈수록 마진이 무너지는 구조적 위험이 있다. 순수 소프트웨어와 달리 사용자가 늘어날수록 API 호출이 선형으로 늘고, 그 비용이 서버보다 훨씬 빠르게 올라가기 때문이다. 다만 이 위험은 미리 설계로 막을 수 있다. 문제는 "나중에 최적화하면 되지"라는 생각이 통하지 않는다는 것.

이미지 한 장이 텍스트 수백 줄보다 비싼 이유

AI 채팅 서비스를 써본 사람이라면 텍스트 API 비용 감각은 어느 정도 있다. GPT-4o mini로 짧은 문장 하나 처리하는 데 $0.0001도 안 한다. 그런데 이미지가 들어오는 순간 계산이 완전히 달라진다.

OpenAI GPT-4o 기준으로 음식 사진 한 장(저해상도 타일 1장 + 고해상도 처리 기준)을 분석하면 인풋 토큰만 대략 7001,500토큰이 나간다. 가격으로 환산하면 이미지 한 건에 $0.01$0.025 수준이다. 텍스트라면 1,000토큰에 $0.00015인 것과 비교하면 100배 가까운 차이다.

이제 Cal AI 규모로 계산해보자. DAU 50만 명이 하루 23장씩 찍으면 하루 API 호출 100150만 건. 건당 $0.015로만 잡아도 하루 $15,000~$22,500, 월 $450,000~$675,000이 된다. $30M 연매출이 있어도 이 숫자는 압도적이다. 실제로는 캐싱, 온디바이스 모델, 에스컬레이션 구조 등으로 이 비용의 상당 부분을 줄였을 것이다. 그런데 그 아키텍처가 없는 상태에서 인플루언서 캠페인이 터지면 어떻게 될까.

인플루언서 캠페인이 숨기는 비용 방정식

성공적인 인플루언서 캠페인의 특징이 있다. 며칠 안에 폭발한다. 채널 하나가 1,000만 뷰를 넘기면 앱 다운로드가 하루 수만 건 단위로 몰리고, 신규 사용자들은 첫날에 평균보다 훨씬 많은 사진을 찍는다(호기심 때문에). 즉 CAC(고객 획득 비용)와 API 비용이 동시에 터지는 구간이 생긴다.

이 시점에 앱이 느려지거나 응답을 못 하면 바이럴이 역효과가 된다. 앱 스토어 리뷰에 "서버 터짐", "응답 없음"이 박히기 시작하고, 그 리뷰들이 또 검색에 뜬다. 인플루언서 마케팅 비용을 아무리 잘 써도 인프라 병목에서 다 새어나가는 구조다. Cal AI가 이 함정을 어떻게 피했는지 공개된 기술 문서는 없지만, $30M 매출과 인수까지 이어진 걸 보면 준비가 됐거나 빠르게 대응했거나 둘 중 하나다.

작은 팀일수록 이 준비가 더 어렵다. 엔지니어가 2~3명이면 비용 최적화 레이어를 미리 짤 여유가 없다. 그냥 가장 정확한 모델 하나 붙여서 빠르게 출시하는 게 우선이 된다. 그러다 트래픽이 터지면 그때서야 청구서를 보고 뒤늦게 구조를 바꾸려 한다.

AI 비용 설계: 세 가지 원칙

설계 단계에서 비용 구조를 잡는 원칙은 세 가지로 정리된다.

첫 번째는 모델 티어 분리다. 모든 요청을 가장 비싼 모델로 보내는 건 가장 빠른 설계지만 가장 비싼 설계다. Cal AI 식으로 말하면, 닭가슴살이나 흰 쌀밥처럼 명확한 음식은 경량 온디바이스 모델로 처리하고, 신뢰도 점수가 낮을 때만 클라우드 멀티모달 API로 에스컬레이션하면 된다. 텍스트 LLM도 마찬가지다. 패턴이 반복되는 단순 태스크는 Haiku, 판단이 필요한 검수는 Sonnet. 이 분리만으로 비용이 절반 이하로 떨어진다.

두 번째는 결과 캐시다. 비슷한 입력에 비슷한 출력이 나오는 작업이라면, 임베딩 유사도 기반으로 캐시를 걸 수 있다. 칼로리 앱이라면 같은 음식 사진들의 임베딩을 코사인 유사도로 비교해서 임계치 이상이면 캐시된 결과를 돌려주는 방식이다. 글 생성 봇이라면 동일 키워드로 이미 생성된 글이 있으면 재생성을 건너뛰는 가드가 이 역할을 한다.

세 번째는 비용 경보를 코드로 박는 것이다. 클라우드 청구 알림은 일/월 단위다. 바이럴은 시간 단위로 폭발한다. Anthropic Usage API를 시간당 폴링해서 토큰 소비량이 전날 동 시간대 대비 200%를 넘으면 즉시 알림이 와야 한다. 청구서 받고 나서 대응하면 이미 수백만 원이 나간 뒤다.

우리 시나리오: 봇이 바이럴을 타면

우리 팀은 지금 12개 봇이 매일 수십 건의 글을 AI로 생성하고, review_loop(discord-review.service)가 모든 발행 후보를 Claude Sonnet으로 검수한다. 현재 규모에선 문제없다. 하지만 가령 lotto.hedvion.com이 커뮤니티에서 바이럴을 타서 하루 방문자가 갑자기 10배 뛰면 어떻게 될까.

직접 계산해보니 가장 먼저 터지는 건 API 비용이 아니라 Anthropic Rate Limit이었다. Haiku와 Sonnet은 분당 토큰 한도가 있고, 봇들이 동시에 평소보다 많은 요청을 보내면 각 봇이 차례로 타임아웃에 걸려 줄줄이 죽는다. 봇이 죽으면 다음 cron 트리거까지 복구가 안 된다. 비용 문제보다 이 가용성 문제가 더 먼저 온다.

여기서 필요한 건 두 가지다. 각 봇의 Sonnet 호출에 시간당 최대 호출 수 제한(rate cap)을 코드로 박는 것, 그리고 Haiku와 Sonnet 호출 비율을 주간 단위로 리뷰하는 루틴을 만드는 것이다. 특정 봇이 단순 반복 태스크에 Sonnet을 남용하고 있다면 바로 눈에 띈다. 이 두 가지만 해도 비용과 가용성을 동시에 잡을 수 있다.

지금 바로 점검할 세 가지

Cal AI의 성공은 마케팅 이야기로만 소비하기엔 아깝다. 이 케이스가 진짜로 가르쳐주는 건, AI 추론 비용이 얼마나 비선형으로 오를 수 있는가다.

AI를 쓰는 소규모 팀이라면 지금 당장 이 세 가지를 확인하라.

현재 API 호출 중 같은 입력이 반복될 가능성이 있는 작업에 캐시가 없다면, Redis TTL 캐시 하나만 붙여도 비용을 20~40% 줄일 수 있다. 구현 시간 반나절이면 된다.

비싼 모델이 담당하는 작업이 정말 비싼 모델만 할 수 있는 작업인지 한 번은 검증해야 한다. "90% 정확도면 충분한 작업"에 99% 모델을 쓰는 건 순수한 낭비다. Haiku로 먼저 시도하고 출력 품질이 기준 이하일 때만 Sonnet으로 재시도하는 로직이 장기적으로 비용 구조를 바꾼다.

트래픽이 갑자기 2배 뛰었을 때 API 비용이 2배가 되는지, 아니면 10배가 되는지를 미리 계산해보라. 선형이면 괜찮다. 비선형이라면 설계 어딘가에 구멍이 있다는 신호다. 그 구멍을 바이럴이 터지기 전에 찾는 게 사후 대응보다 열 배 쌀다.

원문: AI News & Artificial Intelligence | TechCrunch