실리콘밸리는 AI에 올인하지만, 영수증은 우리가 받는다

Ron Johnson의 말이 불편할 만큼 맞는 이유

실리콘밸리는 지금 AI 쇼핑에 베팅하고 있다. Apple Store를 설계한 Ron Johnson은 그게 틀렸다고 말한다. "Apple의 진짜 경쟁력은 항상 사람이었다"는 주장은 기술 커뮤니티에서 구세대의 저항처럼 읽힐 수 있다.

하지만 나는 그 기사를 읽으면서 쇼핑 경험 논쟁보다 훨씬 더 실용적인 문제가 먼저 떠올랐다. AI가 모든 소비자 접점에 붙는 세상을 만들려면, 그 인프라를 굴리는 비용은 대체 얼마인가. 대형 리테일러에게 AI 추천 엔진은 마케팅 예산 한 줄이다. 우리 같은 팀에게는 매달 클라우드 영수증이 실제로 온다.

Ron Johnson이 "사람이 더 낫다"고 말할 때, 작은 팀이 진짜로 물어야 할 질문은 다른 데 있다. AI가 더 낫냐 나쁘냐가 아니라, 내 팀이 그 AI를 감당할 수 있느냐. 이 질문을 앞에 놓고 계산하면, 실리콘밸리가 당연하게 여기는 전제들이 하나씩 흔들리기 시작한다.

우리가 실제로 치르는 비용

우리는 현재 콘텐츠 자동화, 검수, 가드 봇 등 다양한 목적으로 Claude API를 매일 호출한다. 봇 하나가 글 하나를 만들 때 LLM을 두 번 거친다. 초안 생성은 Haiku로, 품질 검수는 Sonnet으로. 이 조합이 정착된 건 기술적인 이유가 아니라 순전히 비용 계산 때문이었다.

Claude Haiku와 Sonnet의 토큰 단가 차이는 입력 기준으로 약 4배, 출력 기준으로도 비슷한 배수가 붙는다. 하루 수십 건의 글을 생성하는 워크플로에서 Sonnet을 전 단계에 쓰면 비용이 눈에 띄게 올라간다. 처음엔 그냥 "좋은 모델 쓰면 되지"라고 생각했는데, 실제로 한 달치 영수증을 뜯어보고 나서야 아키텍처를 다시 그렸다.

그래서 도달한 원칙이 하나 있다. 대량 처리는 싼 모델로, 판단이 필요한 관문에만 비싼 모델을 쓴다. 글 초안 10개를 만드는 건 Haiku로 충분하다. "이 글이 AdSense 정책에 위배되는가"를 판단하는 검수 한 번에는 Sonnet을 쓴다. 그 판단이 틀리면 계정 자체가 위험해지기 때문이다.

재시도 비용도 들여다봐야 한다. 우리는 본문이 1,500자 미만이면 1회 자동 재생성하는 규칙을 코드에 박아뒀다. 재생성률이 평균 10%만 돼도 월간 토큰 비용이 그만큼 오른다는 뜻이다. 프롬프트 품질이 청구서 금액을 직접 결정한다는 얘기이고, 이건 대부분의 팀이 처음엔 계산에 안 넣는 항목이다.

"LLM 0"이 때로는 최선이다

실리콘밸리의 AI 쇼핑 비전이 놓치는 것이 있다. 모든 자동화에 AI가 필요하지 않다는 사실.

우리가 운영하는 봇 중 일부는 의도적으로 LLM 호출이 0이다. 소셜 미디어 발행 봇은 DB에서 실데이터를 꺼내 고정 템플릿에 채워 넣는다. 팩트가 맞고 포맷이 정해져 있는 콘텐츠에 AI가 끼어들면 비용만 올라가고 환각 리스크가 생긴다. 콘텐츠 가드 봇들도 마찬가지다. Wikipedia 파싱, 외부 API 교차검증, 정규식 패턴 매칭으로 가짜 정보를 걸러내는 작업에 LLM을 쓰지 않는다. 비용이 0원인 동시에 오히려 더 정확하다.

이 결정이 처음부터 쉬운 건 아니었다. "AI를 쓰면 더 잘하지 않을까?"라는 충동이 항상 있다. 직접 실험해보니, 잘 설계된 규칙 기반 로직이 비정형 LLM 출력보다 훨씬 신뢰할 만한 경우가 많다. 특히 이진 판단, 즉 발행 허용/차단, 정상/격리 같은 결정에서는 규칙이 AI를 이긴다. 느리지 않고 빠르고, 틀리지 않고 일관적이다.

Ron Johnson이 "사람이 기술보다 낫다"고 주장하는 맥락과 구조적으로 닮아 있다. 자동화가 항상 더 싸고 빠르다는 전제는 참이 아니다. AI도 마찬가지다.

실제 시나리오: 새 기능에 AI를 붙일까 말까

새 기능을 기획할 때 우리 팀이 거치는 계산을 구체적으로 쓰면 이렇다.

"사용자 검색어에 맞는 답변을 AI로 즉시 생성하는 기능"을 붙인다고 가정한다. 하루 검색 1,000건, 그중 AI 호출이 필요한 쿼리가 30%라면 하루 300 호출이다. 쿼리 평균 200 토큰, 응답 500 토큰 기준으로 Sonnet을 쓰면 하루 토큰 비용은 소규모 팀 입장에서 꽤 부담스러운 숫자가 된다. 월로 환산하면 서버 한 대 임대비에 맞먹거나 넘는다.

여기서 선택지는 세 가지다. 기능 자체를 포기한다. Haiku로 다운그레이드하고 품질 손실을 받아들인다. 호출 수 자체를 줄이는 아키텍처를 설계한다. 세 번째 방향은 캐싱을 적극 활용하거나, 사전 분류 로직으로 LLM이 필요한 쿼리만 걸러내거나, 실시간 대신 배치 처리로 전환하는 방식이다.

우리 팀은 대개 세 번째 옵션부터 검토하고, 안 되면 두 번째로 간다. 첫 번째, 즉 기능 포기는 최후 수단이지만 실제로 가끔 선택한다. AI가 반드시 필요한 기능이 아닌데 비용이 과하면, 그냥 안 붙인다.

실리콘밸리 식 사고방식은 그 첫 번째 선택지를 아예 테이블 위에 올리지 않는다. "AI를 안 쓰는 건 퇴보"라는 프레임이 있기 때문이다. 그런데 우리한테는 월말에 영수증이 실제로 온다.

토큰 너머의 숨은 비용들

토큰 비용만 계산하면 절반밖에 안 본 것이다.

서버 idle 비용이 있다. LLM 응답을 기다리는 동안 서버 프로세스는 대기 중이다. 배치 봇은 큰 문제가 없지만, 실시간 응답이 필요한 서비스는 LLM 레이턴시, 평균 2~5초가 동시 요청 처리 용량에 직결된다. 더 비싼 인스턴스가 필요해지거나 큐 아키텍처를 새로 짜야 하는 상황이 된다. 기능 하나를 추가했을 뿐인데, 서버 스펙까지 따라 올라간다.

그리고 실수의 비용. 환각이 발행되면 수동 정정, 콘텐츠 검수, 최악의 경우 AdSense 계정 위험이다. 이건 토큰 비용과 비교할 수 없을 만큼 크다. 그래서 비싼 Sonnet을 검수에 쓰는 건 보험료 개념이다. 아껴서 나중에 더 크게 나가는 것보다, 관문 하나에 비싼 모델을 쓰는 쪽이 실제로 저렴하다.

AI 쇼핑 플랫폼들이 앞으로 맞닥뜨릴 문제도 이와 같은 구조다. 스케일이 커질수록 숨어있던 비용 항목들이 하나씩 드러난다. 대기업은 그걸 비용으로 흡수하거나 VC 돈으로 덮는다. 작은 팀은 설계 단계에서 막지 않으면, 나중에 서비스를 끄는 수밖에 없다.

지금 당장 써먹을 수 있는 것들

현재 LLM 호출 목록을 먼저 만들어라. 지금 AI를 쓰는 모든 작업을 나열하고, "이 결과가 A면 x, B면 y"로 분기가 가능한 판단인지 확인한다. 이진 분류, 패턴 매칭, API 교차검증으로 해결되는 작업에는 AI가 필요 없다. 이걸 규칙 기반으로 교체하는 것만으로도 비용이 의미 있게 준다. 처음엔 사소해 보이지만, 매일 수백 번 호출되는 로직이라면 이야기가 달라진다.

모델 티어를 분리해라. 초안·대량 처리는 가장 싼 모델, 최종 판단·품질 관문에만 비싼 모델. 동일 파이프라인에 최상위 모델을 전 단계에 박는 건 지속 불가능하다. 비싼 모델은 "틀리면 안 되는 한 번"에만 써야 제값을 한다.

신기능 추가 전 월간 호출 수와 예상 비용을 먼저 계산해라. 스프레드시트 한 줄이면 된다. 하루 X 호출에 Y 토큰을 곱하고, Z 단가에 30일을 곱한다. 이 숫자가 현실적으로 감당 가능한지 확인하고 시작하는 팀이, 나중에 스케일 다운하는 팀보다 훨씬 덜 고생한다.

Ron Johnson은 감성적인 이유로 AI에 회의적이다. 우리가 AI 인프라에 신중한 이유는 영수증 때문이다. 출발점은 달라도, 같은 질문으로 귀결된다. 이게 정말 이 비용만큼의 가치가 있나.

원문: AI News & Artificial Intelligence | TechCrunch