우리는 모든 AI API 호출에서 필요 이상으로 3.75배 더 많은 비용을 지불하고 있었습니다 — 이를 어떻게 발견했는지 소개합니다

우리의 Anthropic 청구 금액은 예상보다 높았습니다. 5명의 엔지니어가 AI 기능을 빠르게 출시하고 있었지만, 각 기능이 실제로 얼마의 비용을 발생시키는지에 대한 가시성은 전혀 없었습니다. 서비스를 구축하기 시작한 이후로 아무도 우리의 AI API 사용량을 검토하지 않았습니다. 마침내 우리가 확인했을 때 발견한 내용은 다음과 같습니다.

청구서가 도착하다

LLM (Large Language Model)으로 서비스를 구축하는 모든 팀은 이 순간을 맞이합니다. API 청구서가 도착하고 누군가 "왜 이렇게 높죠?"라고 물으면, 아무도 지켜보고 있지 않았기 때문에 누구도 제대로 된 답변을 하지 못합니다.

우리는 무모하게 행동한 것이 아니었습니다. 그저 제품을 만들고 있었을 뿐입니다. AI 기능을 추가하고, 프롬프트 (Prompt)를 반복 개선하며, 제품을 출시하고 있었습니다. 비용에 대한 논의는 항상 나중에 해야 할 일처럼 느껴졌습니다.

그리고 그 '나중'이 찾아왔습니다.

우리가 발견한 것

우리에게는 divergence-detector.js라는 서비스가 있습니다. 이 서비스의 역할은 매일 밤 실행되어 ETF 흐름 신호가 기초 자산 섹터 신호와 모순되는 상황을 찾아내고, 발견된 각 괴리에 대해 2문장으로 된 쉬운 영어 설명을 생성하는 것입니다.

관련된 부분은 다음과 같습니다:

const response = await client.messages.create({
  model: 'claude-sonnet-4-6',
  max_tokens: 150,
...

claude-sonnet-4-6. max_tokens: 150.

잠시 이 부분을 생각해보세요.

우리는 출력 토큰 100만 개당 15달러인 Anthropic의 중간 단계 추론 모델 (Reasoning Model)을 사용하여, 150 토큰으로 제한된 출력을 생성하고 있었습니다. 단 두 문장 말입니다. 매일 밤 말이죠.

claude-haiku-4-5는 출력 토큰 100만 개당 4달러이며, 동일한 품질로 2문장의 구조화된 설명을 처리할 수 있습니다. 우리는 매 호출마다 필요 이상으로 3.75배 더 많은 비용을 지불하고 있었습니다.

아무도 눈치채지 못했습니다. 몇 주 동안이나 그렇게 실행되고 있었습니다.

왜 모든 팀에게 이런 일이 발생하는가

이것은 우리에게만 일어나는 독특한 실수가 아닙니다. 구조적인 문제입니다.

LLM으로 구축을 시작할 때, 여러분은 기본적으로 가장 좋은 모델을 선택합니다. 그것이 가장 좋은 결과물을 만들어내기 때문입니다. 여러분은 빠르게 반복 작업을 수행하고 있으며, 아직 최적화 (Optimising) 단계는 아니며, 비용은 추상적으로 느껴집니다.

그러다 제품을 출시합니다. 기능은 잘 작동합니다. 여러분은 다음 작업으로 넘어갑니다. 모델 선택은 시스템을 지탱하는 핵심 요소가 됩니다. 무언가 망가질까 봐 아무도 그것을 건드리려 하지 않습니다. 비용은 배경에서 조용히 복리로 쌓여갑니다.

데이터베이스 쿼리는 검토됩니다. SQL은 최적화됩니다. 인덱스(Index)가 추가됩니다. 하지만 AI API 호출은 어떤가요? 그것들은 코드베이스에 그대로 남아 첫날에 하던 일을 영원히 반복합니다.

문제는 개발자들이 부주의해서가 아닙니다. 개발 워크플로우(Development workflow) 내에 이를 알려줄 도구가 없기 때문입니다. 린터(Linter), 리뷰어(Reviewer), CI 체크(CI check) 중 그 어디에도 없습니다. 비용은 청구서가 도착하기 전까지는 보이지 않습니다.

우리가 만든 것

우리는 모든 PR(Pull Request)에서 AI API 사용량을 스캔하고, 무언가가 병합(Merge)되기 전에 자동으로 비용 분석 댓글을 게시하는 GitHub Action을 만들었습니다.

실제 PR에서는 다음과 같이 보입니다:

댓글에는 다음 내용이 표시됩니다:

• 베이스 브랜치(Base branch) 대비 비용 차이 — "이 PR은 월 +$44를 추가합니다" 또는 "변동 없음". 첨부된 스크린샷에서는 이 PR이 추가 비용을 0% 발생시킨다고 나타냅니다.
• 경고(Warnings) — 특정 수정 권장 사항과 함께 비싼 모델을 오용하는 경우에 대한 경고
• 중복된 AI 호출 패턴 — 서비스 레이어(Service layer)를 공유해야 하는 패턴
• 누락된 재시도/백오프(Retry/Backoff) 로직 — 속도 제한(Rate limits) 상황에서 시스템을 중단시킬 수 있는 로직
• 프롬프트 캐싱(Prompt caching) 기회 — 재사용되는 시스템 프롬프트(System prompts)를 통해 입력 비용을 최대 90%까지 절감 가능

divergence-detector.js에서 발견된 내용은 ⚠️ WARN으로 나타납니다:

[EXPENSIVE_MODEL_FOR_CAPTION_OUTPUT] claude-sonnet-4-6 used with 
max_tokens=150. Outputs ≤300 tokens on structured inputs strongly 
suggest a classification/summarisation task — not a reasoning task. 
...

특정 파일, 특정 문제, 특정 수정 방법. 일반적인 경고가 아닙니다.

작동 방식

이것은 런타임 모니터링(Runtime monitoring)이 아닌 정적 분석(Static analysis)입니다.

스캐너는 JS/TS 파일을 탐색하여 AI SDK 호출 지점을 찾고, 모델 이름과 max_tokens 값을 추출한 다음, 일련의 탐지 규칙을 적용합니다. divergence-detector.js를 잡아낸 복합 규칙은 다음과 같습니다:

프리미엄 모델 + max_tokens ≤ 300 = 이것이 추론(Reasoning) 작업이 아닌 분류(Classification) 또는 요약(Summarisation) 작업임을 나타내는 강력한 신호

또한 베이스라인(Baseline)을 추적합니다. main 브랜치로 푸시(Push)될 때, 현재 스캔 결과를 GitHub Actions 캐시(Cache)에 저장합니다. 모든 PR(Pull Request) 시에는 해당 베이스라인을 불러와 차이(Delta)를 계산합니다. 따라서 단순히 총액이 아니라, 해당 PR이 월간 청구 금액에 무엇을 추가하는지를 확인할 수 있습니다.

탐지하는 항목:

• 단순한 출력을 위해 사용되는 고비용 모델
• 프롬프트 캐싱(Prompt Caching)이 적용되지 않은 대규모 정적 시스템 프롬프트
• 서비스 레이어(Service Layer)를 공유할 수 있음에도 동일한 모델을 호출하는 여러 파일
• 재시도 로직(Retry Logic)이 없는 API 호출

탐지하지 못하는 항목:

• 런타임에 생성되는 프롬프트 (Runtime-constructed prompts, 런타임에 조립되는 동적 콘텐츠)
• 실제 토큰 소비량 (이를 위해서는 Helicone 또는 제공업체의 사용량 대시보드를 사용하세요)
• 멀티턴(Multi-turn) 흐름에서 대화 기록 증가로 인한 비용

이를 AI 비용을 위한 린터(Linter)라고 생각하세요. 런타임 소비량을 측정하는 계량기가 아니라, 커밋(Commit) 시점에 구조적인 문제를 잡아내는 도구입니다.

지원되는 제공업체 및 언어

제공업체(Providers): Anthropic · OpenAI · Google Gemini · AWS Bedrock · LangChain

언어(Languages): JavaScript · TypeScript · JSX · TSX · MJS · CJS

2분 만에 모든 리포지토리에 추가하기

.github/workflows/ai-scan.yml 파일을 생성하세요:

name: AI Architecture Scan

on:
...

그게 전부입니다. API 키가 필요하지 않습니다. 외부 서비스도 필요 없습니다. 베이스라인 저장을 위해 GitHub Actions 캐시를 사용하므로, 해당 Action이 이미 가지고 있는 권한 외에 추가적인 권한은 전혀 필요하지 않습니다.

첫 번째 실행 시 베이스라인을 설정합니다 (아직 차이는 나타나지 않음). 그 이후의 모든 PR에서는 전체 비용 비교 테이블이 표시됩니다.

첫 실행 시 예상되는 결과

PR에서 Action이 처음 실행될 때 다음과 같은 메시지를 보게 됩니다:

📋 main에 대한 첫 번째 스캔 — 아직 베이스라인이 없습니다. 다음 PR에서 이 베이스라인 대비 비용 차이가 표시됩니다.

이는 정상적인 현상입니다. 먼저 워크플로(Workflow) 파일을 main에 푸시한 다음, PR을 생성하세요. 두 번째 실행부터 전체 차이(Delta) 테이블이 표시됩니다.

링크

• GitHub Marketplace: https://github.com/marketplace/actions/ai-architecture-scanner
• Repo: https://github.com/kavyarani7/ai-arch-scanner
• 의존성 없음 (Zero dependencies) — 순수 Node.js 내장 기능 사용
• 무료, 오픈 소스, MIT 라이선스

마지막으로 한 가지 (One Last Thing)

임계값(Thresholds)이나 게이트(Gates)를 설정하기 전에 여러분의 코드베이스(Codebase)에서 직접 실행해 보세요. 무엇을 찾아내는지 확인해 보시기 바랍니다. 실제 운영 중인 코드베이스(Production codebase)에서 수행하는 첫 번째 스캔은 거의 항상 "어라, 왜 우리가 이런 식으로 했지?"라고 생각하게 만드는 호출을 최소 하나 이상 찾아냅니다.

그 순간이 바로 이 도구의 핵심 목적입니다.

여러분의 코드베이스에서 발견한 가장 비용이 많이 드는 AI 패턴은 무엇인가요? 댓글로 남겨주세요. 서로 다른 팀들에서 어떤 것들이 나타나는지 진심으로 궁금합니다.