AI 기능을 제품에 붙일 때 승부는 ‘모델 성능’이 아니라 비용과 속도에서 갈립니다. CAC는 점점 오르는데, AI 호출비가 마진을 갉아먹고 응답 지연이 온보딩을 끊어버리면 전환율은 그냥 내려갑니다. 그래서 지금 필요한 건 “더 똑똑한 모델”이 아니라 더 똑똑한 운영이에요.
최근 dev.to의 두 글이 같은 결론을 다른 각도에서 보여줍니다. 하나는 LLM Gateway를 OpenAI 호환 API로 5분 만에 붙이고(모델 스위칭 1줄), 호출당 비용·지연을 대시보드에서 추적하는 방법(출처: dev.to/smakosh)이고, 다른 하나는 Claude Code가 기본값(고가 Opus) 때문에 비싸지는 구조를 라우팅으로 84%까지 줄인다는 실전 수치(출처: dev.to/robinbanner)입니다. 여기에 Go 기반 SSE(Server-Sent Events) 스트리밍 구현이 더해지면(출처: dev.to/itodona) 체감 지연까지 같이 잡힙니다.
맥락을 그로스 관점으로 번역해보면 명확합니다. (1) 게이트웨이/라우팅은 ‘모델 선택’을 코드가 아니라 정책으로 바꿉니다. 즉, 기능팀이 바빠도 비용 실험(cheap→expensive)을 운영에서 즉시 걸 수 있어요. (2) 에이전트형 도구(Claude Code)는 한 번의 사용자 액션이 내부적으로 10~30번 호출로 폭증합니다. 이때 “사소한 질문까지 프리미엄 모델로” 보내면, ARPU가 따라오기 전에 COGS가 먼저 터집니다. (3) 스트리밍(SSE)은 총 처리 시간이 같아도 TTFT(Time To First Token)을 줄여 “기다린다”는 감각을 없애고, 이탈을 줄입니다. 유저는 8초짜리 무응답보다 8초 동안 한 글자씩 나오는 답을 더 빨리 느끼거든요.
시사점은 세 가지입니다. 첫째, LLM Gateway 같은 통합 계층을 ‘비용 통제판’으로 써야 합니다. OpenAI 호환 엔드포인트로 붙이면 기존 SDK/코드를 거의 안 건드리고, 모델 문자열만 바꿔 A/B 테스트가 가능합니다. “gpt-4o vs claude-haiku vs gemini-flash”를 기능 비교가 아니라 원가/전환율 비교로 돌릴 수 있는 거죠.
둘째, 모델 라우팅은 곧 마진 방어입니다. dev.to 사례처럼 작업을 난이도별로 분류해 cheap(파일 읽기/확인)→mid(디버깅/리뷰)→premium(아키텍처/리팩토링)으로 보내면, 같은 UX를 유지하면서 비용이 급락합니다. 이거 바이럴 될 것 같은데? “우리 AI가 싸고 빠르다”는 메시지는 결국 가격 정책(프리미엄 기능/사용량 과금)에도 바로 연결됩니다. LTV를 키우기 전에 COGS를 낮추면, CAC를 더 공격적으로 써도 버팁니다.
셋째, SSE 스트리밍은 온보딩 퍼널의 friction을 직접 깎습니다. WebSocket까지 갈 필요 없이 HTTP 기반으로 프록시/로드밸런서 친화적으로 구현되고, 브라우저 자동 재연결 같은 이점도 큽니다(출처: dev.to/itodona). 특히 AI 첫 사용 구간에서 “첫 답이 늦게 온다”는 이유로 나가는 유저를 줄이면 D1이 움직이고, D1이 오르면 D7도 따라오는 경우가 많습니다. 빨리 테스트해봐야 돼요: 스트리밍 적용 전/후로 TTFT, 첫 세션 완료율, 첫 메시지 이후 2번째 액션 전환율부터 보세요.
전망은 더 간단합니다. 앞으로 AI 제품의 기본 스택은 “모델”이 아니라 게이트웨이(관측/통제) + 라우팅(원가 최적화) + 스트리밍(체감 속도)로 표준화될 가능성이 큽니다. 모델은 계속 바뀌고 단가는 흔들리지만, 이 3가지는 어떤 모델을 쓰든 성장 지표에 직접 연결됩니다. 결국 승자는 ‘가장 똑똑한 모델’이 아니라 가장 빠르게 실험하고, 가장 싸게 운영하며, 가장 덜 기다리게 만드는 팀일 겁니다.