"AI를 위한 AI"를 안 쓰는 비용 감각

"AI를 위한 AI"가 청구서에 남기는 것

Apple CEO가 "AI를 위해 AI를 출시하지 않겠다"고 말했을 때, 대부분의 분석은 빅테크 경쟁 포지셔닝 이야기로 흘렀다. 우리 같은 팀 입장에서 읽히는 맥락은 다르다. Apple은 PR 선언이고, 우리는 그 청구서를 직접 받는 쪽이다.

"정말 필요한지 먼저 묻는다"는 태도가 Apple에겐 브랜드 포지션이라면, 작은 팀에겐 월 비용을 통제하는 가장 현실적인 감각이다. 단, 이 원칙을 맹목적으로 따르다 보면 품질 게이트가 무너지는 함정이 있다. 그 지점도 아래에서 다룬다.

토큰 비용은 이렇게 조용히 불어난다

LLM API 비용은 처음엔 별거 아닌 것처럼 보인다. 테스트 단계에서 하루 몇백 건 호출해도 몇 달러 수준이라 감각이 잘 안 온다.

문제는 봇이 늘고 발행 빈도가 오르면서다. 하루 60건 글 생성, 건당 평균 출력 2,000 토큰이면 하루 약 12만 토큰 출력이다. Claude Sonnet 계열(출력 기준 약 $15/백만 토큰)로 전량 돌리면 생성 비용만 한 달에 약 $54. 여기에 검수 라운드, 리트라이, 시스템 프롬프트 입력 토큰까지 더하면 실 청구액은 3~4배 불어난다.

같은 작업을 Haiku 계열(출력 기준 약 $4~5/백만 토큰)로 돌리면 동일 볼륨에서 비용이 3분의 1 이하다. "그 차이가 얼마나 된다고"로 넘기기엔, 이 비용이 쌓이는 시점이 대개 수익이 아직 불안정한 초기라는 게 문제다. 스케일이 커질수록 초반의 설계 결정이 고정비처럼 굳어버린다.

또 한 가지 간과하기 쉬운 것이 있는데, 실패한 호출의 비용이다. 품질 게이트를 통과 못 한 초안도 토큰이 나간다. 재생성 루프가 3회 돈다면 그 태스크의 실질 비용은 표면적으로 보이는 것의 세 배다. 이 비용은 로깅하지 않으면 거의 보이지 않는다.

"LLM 0 = 비용 0"을 설계에 박아두기

우리 팀이 최근 신설한 봇들을 보면 흥미로운 패턴이 있다. 소셜 자동발행 봇, 앱 출시 알림 봇, 콘텐츠 가드 봇 — 이 셋의 설계 메모에는 공통적으로 "LLM 0 = 비용 0"이라는 문구가 박혀 있다. Holodex API로 소속사를 교차검증하는 버튜버 가드 봇도, 규칙 기반으로 발행을 차단하는 kpop 뉴스 가드도 LLM 호출이 없다.

처음엔 단순히 빠르게 만들기 위해 LLM을 안 쓴 거였는데, 직접 운영해보니 이게 오히려 더 신뢰할 수 있는 구조였다. 규칙 기반 판단은 환각이 없고, API 쿼터 걱정이 없고, 프롬프트가 엣지케이스를 잘못 처리하는 일도 없다. 대신 로직을 코드로 명시해야 하니 설계 단계에서 더 깊이 생각하게 되는데 — 이것 자체가 부작용이 아니라 장점이었다.

Apple CEO가 말한 "AI를 위한 AI" 경계와 정확히 같은 맥락이다. LLM이 못 해서 안 쓰는 게 아니라, 이 태스크는 LLM이 필요 없다는 판단을 설계 단계에서 먼저 내리는 것. 이 판단 하나가 운영 비용 구조 전체를 바꾼다.

모델 티어 선택이 비용 설계의 핵심

LLM을 써야 하는 태스크라면, 다음 질문은 어떤 모델이냐다. 우리는 본문 생성 기본값을 Haiku 계열로 고정하고, 검수·판단 단계만 Sonnet 이상으로 올린다.

이 구분이 중요한 이유는 태스크별 특성이 다르기 때문이다. 본문 생성은 볼륨이 크고 반복적이라 모델 선택이 비용 전체에 미치는 영향이 크다. 반면 검수는 결과가 발행/차단을 결정하므로 품질이 더 중요하다. Haiku로 초안을 뽑고 Sonnet으로 게이트를 거는 구조는 비용과 품질 양쪽을 어느 정도 잡는 현실적 절충이다.

다만 이 구조에는 함정이 있다. Haiku 초안의 품질이 워낙 낮으면 Sonnet 검수를 통과 못 해 재생성 루프가 돌고, 결국 Sonnet을 두 번 쓰는 꼴이 된다. 우리가 발행 게이트에 "본문 1,500자 미만 차단" 로직을 코드로 강제한 것도 이 이유에서다. 짧은 초안은 검수에 넘기기 전에 생성 단계에서 한 번 더 돌린다. 프롬프트에 "길게 써줘"라고 부탁하는 게 아니라 코드로 강제하는 것. 부탁은 무시되지만, 코드는 무시되지 않는다.

우리 팀이 실제로 선택한 설계

봇이 16개를 넘어가면서 "이 봇 왜 이렇게 토큰 많이 쓰지?"를 체계적으로 추적하기 시작했다. 비용 구조를 뜯어보는 것 자체가 자연스럽게 설계 리뷰가 됐고, 그 과정에서 잘못된 선택들이 드러났다.

소셜 발행 봇을 예로 들면, 초기에 LLM으로 각 포스트 카피를 동적 생성하는 방식을 검토했다. 하루 사이트당 3건, 3사이트면 9건. 건당 생성과 스타일 검수면 토큰이 꽤 나온다. 그런데 팩트가드 요구사항이 발목을 잡았다. 명칭, 숫자, 날짜를 LLM이 틀릴 경우 오히려 발행 신뢰도가 떨어진다는 판단이 나왔다.

결국 DB 실데이터 + 고정 템플릿 조립 방식으로 설계했고, 카피라이팅 스타일만 Sonnet을 쓰는 구조로 정착했다. 이 선택 하나로 해당 봇의 LLM 비용이 사실상 제로에 가까워졌고, 발행 정확도는 오히려 올라갔다.

실제로 해보니 알게 된 것이 있는데 — LLM이 필요한 태스크와 아닌 태스크의 경계는 써보기 전까지 잘 안 보인다. 우선 붙여보고, 비용을 추적하면서 분리해나가는 게 현실적이다. 처음부터 완벽하게 설계하려다 아무것도 못 만드는 것보다, 만들고 나서 비용을 보면서 다듬는 쪽이 낫다. 단, 로깅은 처음부터 해야 한다.

지금 바로 써먹을 수 있는 점검 방법

AI 인프라 비용을 줄이기 위해 새 도구를 도입하거나 계약을 바꾸기 전에, 지금 운영 중인 코드를 먼저 들여다볼 것을 권한다. 각 LLM 호출 지점에 다음 세 가지를 대입해보라.

이 태스크에 LLM이 없어도 되는가. 규칙으로 처리 가능한 분류, 외부 API 교차검증, 고정 포맷 조립이라면 LLM을 빼라. 비용이 줄고 예측 가능성이 올라간다. 환각 리스크도 없어진다. 이걸 먼저 물어야 하는데, 대부분의 팀이 "LLM으로 하면 편하니까"로 곧장 넘어간다.

볼륨이 큰 태스크에 Sonnet 계열을 쓰고 있지 않은가. Haiku와 Sonnet의 출력 토큰 단가 차이는 3~4배다. 코드에서 모델명을 명시적으로 관리하고, "좋은 모델 쓰면 되지"로 묵시적으로 흐르게 두지 않는다. 볼륨 태스크는 Haiku, 판단과 검수는 Sonnet — 이 원칙을 코드에 박아두는 것만으로 월 비용이 눈에 띄게 달라진다.

재생성 루프가 얼마나 도는지 모니터링하고 있는가. 품질 게이트 탈락 후 재생성이 자주 발생한다면 비용은 청구서에 두 배로 찍힌다. 게이트 통과율이 낮은 봇은 모델을 올리기 전에 프롬프트를 먼저 개선하는 게 비용 감소로 직결된다. 리트라이 횟수를 로깅하고 있지 않다면, 지금 당장 추가하는 것만으로도 숨어 있던 비용 낭비를 찾을 수 있다.

Apple의 AI 자제 선언이 작은 팀에겐 결국 이 감각으로 번역된다. "이걸 왜 LLM에 넣어야 하지?"를 설계 단계에서 묻는 습관. 그게 월 청구서에 직접 찍힌다.

원문: AI News & Artificial Intelligence | TechCrunch