에이전트 호출 비용이 2일에 30달러였다.

돌이켜보면 아키텍처 설계에서 가장 큰 맹점은 “비용”이라는 축이었다. 모델 라우팅을 설계할 때 나는 성능만 생각했다. 구현은 kimi-k2.7-code, 리뷰는 deepseek-v4-pro, 계획은 qwen3.7-max — 각 작업에 “가장 좋은” 모델을 붙여줬다. 스펙 시트를 보는 기분이었다.

2주 지나서 알았다. 가장 좋은 모델이 가장 좋은 결과를 내는 게 아니었다.

무엇이 문제였나

솔직히 말하면, 내가 한 실수는 단순했다. “코드 생성”이라고 하면 무조건 kimi-k2.7-code를 써야 한다고 생각했다. 그게 “코드 생성 특화” 모델이니까.

그런데 내가 cron으로 돌리는 작업 대부분은 코드 생성이 아니라 글쓰기와 문서 편집이었다:

content-manager-periodic: 블로그 포스트 초안 작성 (글쓰기)하는 >wiki-compile: P2-hippocampus 데이터 → wiki 페이지 컴파일 (문서 편집) implementer: 작은 버그 수정, config 변경 (단순 구현)

이런 작업에 kimi-k2.7-code나 deepseek-v4-pro를 쓰는 건… 100m 달리기에 페라리를 쓰는 거다. 가는데, 그게 문제가 아니라 너무 비싸다.

그래서 어떻게 바꿨나

원칙 하나를 세웠다:

계획과 검증은 고급 모델. 수행은 저급 모델.

글쓰기와 코드 생성은 “수행”에 속한다. 복잡한 추론이 아니라, 이미 정해진 방향으로 실행하는 작업이다.

변경 전후를 표로 정리하면 이렇다:

프로필성능 최적화 (이전)비용 최적화 (현재)절감률 implementerkimi-k2.7-code ($0.012)deepseek-v4-flash ($0.00038)97% content-manager-periodicdeepseek-v4-pro ($0.0035)제거됨 (content-curator.py로 대체)100% wiki-compiledeepseek-v4-pro ($0.0035)deepseek-v4-flash ($0.00038)89% reviewerdeepseek-v4-pro ($0.0035)deepseek-v4-pro유지 plannerqwen3.7-max ($0.0356)qwen3.7-max유지 reviewer-criticalqwen3.7-max ($0.0356)qwen3.7-max유지

핵심은 양쪽 끝단을 비대칭으로 만든 것이다:

검증/계획 (reviewer, planner, reviewer-critical): Pro/Max 유지. 이건 quality gate니까 타협하면 안 된다. 수행 (implementer, wiki-compile, content-manager): 전부 Flash로 통일. 여기서 quality drop은 거의 없었다.

content-manager-periodic의 완전한 제거

가장 큰 변화는 content-manager-periodic 프로필의 완전한 삭제다.

이 프로필은 2시간마다 LLM을 호출해서 “지금 쓸 만한 글이 있는가?”를 판단하고, 있으면 draft를 작성했다. 2시간마다 LLM 호출 × 하루 12회 = 하루 약 $0.042. 작아 보이지만, 한 달이면 $1.26 — 그리고 이 작업이 실제로 publish로 이어진 비율은 낮았다.

그래서 $0짜리 Python 스크립트로 통째로 바꿨다.

6개의 cron job이 content_curator.py 하나로 합쳐졌다:

content-manager-periodic (2h, LLM) content-news-trigger (LLM) content-insight-trigger (LLM) content-series-trigger (LLM) content-planner (LLM) trend-evaluate-trigger (LLM) ↓ content-curator (08:00/15:00, Python heuristic) ← $0

이 스크립트가 하는 일:

  1. 모든 소스(세션 로그, git log, kanban 완료, 트렌드 하베스터 keep 리스트)에서 후보를 수집
  2. Heuristic scoring — 규칙 기반 점수화 (LLM 호출 없음)
  3. 임계값 이상이면 kanban에 task 생성 (editor agent가 처리)
  4. 임계값 미만이면 SILENT — 아무 일도 일어나지 않음

“LLM이 판단해야 하는가?” → 대부분의 경우 “아니오.”

이게 아키텍처의 taste다.

결과: 65% 비용 절감

지표성능 최적화비용 최적화변화 2일 예상 소모$30.07$10.46-65% 1일 예상 소모$15.04$5.23-65% implementer 호출당 비용$0.012$0.00038-97% 불필요한 LLM cron6개0개-6 jobs

숫자로 보면 간단하다. 2일에 30달러 → 10달러. 일주일이면 약 $105 → $37.

하지만 진짜 인사이트는 숫자가 아니다.

여기서 배운 것

“비싼 모델을 쓴다고 좋은 결과가 나오는 게 아니다.”

이건 내가 수십 번 cron 로그를 확인하면서 깨달은 거다. kimi-k2.7-code로 생성한 코드와 deepseek-v4-flash로 생성한 코드 사이에 품질 차이는 거의 없었다. 어차피 reviewer가 검증한다. 어차피 implementer는 이미 정해진 디자인을 실행할 뿐이다.

진짜 차별화가 필요한 건 무엇을 할지 결정하는 순간(planner)과 완성된 결과를 검증하는 순간(reviewer)이다. 그 사이의 “실행”은 Flash로도 충분하다.

이걸 다이어그램으로 그리면 이렇다:

graph TD P[“Plannerqwen3.7-max$0.0356/call「무엇을 할지 결정」”] –>|task| I[“Implementerdeepseek-v4-flash$0.00038/call「실행 (코드/문서)」”] I –>|result| R[“Reviewerdeepseek-v4-pro$0.0035/call「품질 검증」”] R –>|pass| RC[“Reviewer-Criticalqwen3.7-max$0.0356/call「최종 승인」”]

style P fill:#7b5f3d,color:#fff style RC fill:#7b5f3d,color:#fff style R fill:#4a90d9,color:#fff style I fill:#50c878,color:#000

Max 모델이 필요한 곳은 두 곳뿐. 나머지는 Flash로 충분하다.

content-curator.py가 증명한 것

이번 비용 최적화에서 가장 큰 구조적 변화는 content-curator.py다.

6개의 cron job이 각각 LLM을 호출해서 “지금 글 쓸까?”를 묻던 구조를, 하나의 Python 스크립트 + heuristic rule set으로 바꿨다. LLM 호출 횟수: 하루 18회 → 0회.

이게 가능했던 이유는 간단하다. “글을 써야 하는가?”라는 판단은 LLM이 할 필요가 없는 작업이기 때문이다.

콘텐츠 후보 판단은: 최근 git commit이 있는가? → 있으면 점수 + narrative arc에 아직 안 다룬 주제인가? → 있으면 점수 + kanban에 완료된 task가 있는가? → 있으면 점수 + weight가 특정 임계값을 넘었는가? → 넘으면 kanban 생성

이 모든 건 if/else와 dict lookup으로 충분하다. LLM은 필요 없다.

다음은?

비용 최적화는 여기서 끝이 아니다. 지금 진행 중인 것:

  1. Groq 무료 티어: llama-3.1-8b-instant (14,400 RPD로 유일하게 여유), qwen3-32b (60 RPM) — 내부 작업은 완전 무료로 전환 중
  2. 모델별 실제 품질 측정: Flash로 대체한 작업들의 품질을 정량적으로 추적. “괜찮다”가 아니라 숫자로 증명
  3. 스크립트 fastpath 확대: cron job 중 LLM 호출 없이 Python/shell로 처리 가능한 것은 모두 script-only로 전환

Build Log #17. 모델 라우팅을 “성능”에서 “비용”으로 다시 설계한 기록. 비싼 도구가 아니라, 적절한 도구를 적절한 위치에 — 그게 진짜 engineering taste다.