숫자 없이 도입 결정을 내리는 팀들
AI 코딩 도구 도입을 검토할 때 대부분의 팀은 '쓸 만한가?'라는 질문에서 멈춘다. 그리고 유튜브 데모나 트위터 후기를 근거로 결정을 내린다. 현장에서 60일 이상 프로덕션 환경을 돌려본 정량 데이터는 거의 없다. 마케팅 자료나 해커톤 데모가 실제 ROI 판단의 자리를 차지하고 있는 게 현실이다.
최근 이 공백을 메우는 드문 사례 세 개가 동시에 나왔다. 각각 다른 각도에서 AI 도구의 비용 구조를 들여다봤는데, 겹쳐 읽으면 팀 리드가 내일 당장 써먹을 수 있는 프레임이 만들어진다.
60일 ERP 프로덕션: 숫자로만 말하기
dev.to에 프랑스 개발자 Michel Faure가 올린 회고는 'AI 코딩 어시스턴트 60일 리뷰' 중 내가 본 것 중 가장 냉정하다. Claude Code를 ERP 프로덕션에 58일간 실제 투입한 결과, 커밋 984개, TypeScript/TSX/JS/JSX 합산 131,628줄의 코드가 쌓였다. 일평균 커밋 16개. 혼자서.
이 숫자만 보면 'AI가 다 짜준 거 아냐?'라고 생각할 수 있다. 하지만 글의 핵심은 다른 데 있다. 아키텍처 결정 문서 74개, Supabase 마이그레이션 276개, 프로젝트 규칙 18개, 도구 운용 독트린(doctrine)이 9번 개정됐다는 사실이다. 코드 생산량보다 운용 규칙의 진화 속도가 더 중요한 지표다.
특히 'falsify-before-fix' 사례가 인상적이다. 버그를 발견하자마자 냅다 커밋했다가 롤백하는 사이클을 반복하다가, 결국 픽스 키워드를 입력하는 순간 물리적으로 개입하는 스킬을 코드로 커밋했다. 텍스트 규칙은 압박 상황에서 무너지고, 물리적 인터럽터만 살아남는다는 교훈이다. 5~10분의 사전 탐지가 30~90분의 롤백 비용을 막았다는 계산도 명확하다. 버그 2~3건/주 기준으로 월 1일치 공수가 회수된다.
월 $187 청구서가 만든 하이브리드 아키텍처
솔로 개발자 Sam Hartley의 사례는 다른 차원의 비용 문제를 다룬다. GPT-4o, Claude Sonnet, Gemini Pro를 동시에 쓰다가 월 $187.42 청구서를 받고 멈췄다. 인터넷 요금, 스트리밍 구독, VPS 비용을 합친 것보다 많았다.
해법은 RTX 3060 중고 GPU $150 구매 + Ollama + Qwen 2.5 7B 설치였다. 단순 질의(리팩터, 요약, 정규식 설명)의 85%는 로컬 모델로 처리 가능했다. 남은 복잡한 추론과 아키텍처 설계만 클라우드 API로 라우팅하는 30줄짜리 파이썬 스크립트가 전부였다.
12개월 비용 비교: - 클라우드 단독: $187 × 12 = $2,244/년 - 하이브리드 첫 해: GPU $150 + 전기료 $144 + API $300 = $594/년 - GPU 회수 후: $444/년
절감액 $1,650. GPU 투자 회수 기간 4개월 미만. 여기서 팀 규모로 스케일업하면 숫자는 달라지지만 구조는 같다.
주목할 부분은 로컬 모델의 실패 지점을 정직하게 명시했다는 점이다. 멀티테넌트 앱의 RLS 스키마 설계에서 로컬 모델이 데이터 누출 취약점을 놓쳤다. GPT-4o는 잡았다. 레이스 컨디션 디버깅에서도 클라우드 모델이 2문장으로 짚은 걸 로컬은 3단락 설명 후에도 버그를 못 찾았다. 80%는 로컬, 20%는 클라우드—이 경계를 어디에 그을지 판단하는 게 핵심이다.
프로덕션 LLM 비용 최적화: 7가지 레버
세 번째 글(dev.to, @mzunain)은 프로덕션에서 LLM을 운용하는 팀을 위한 체계적 정리다. GPT-4를 모든 요청에 쓰면 100만 건/월 기준 약 $14,000이 나간다. 이걸 해결하는 레버는 7개다.
- 모델 티어링: 복잡도에 따라 GPT-4 → GPT-3.5-Turbo → 로컬 모델로 분기. 60~80% 비용 절감.
- 프롬프트 최적화: 800토큰짜리 장황한 요청을 150토큰으로 압축. 5~10배 토큰 절감.
- 캐싱: 반복 쿼리를 캐시 처리. 동일 쿼리 90%+ 비용 절감.
- 파인튜닝: 도메인 특화 GPT-3.5 파인튜닝으로 요청당 $0.05 → $0.002. 초기 비용 $100~500, 고볼륨 환경에서 월 $10,000 이상 절감.
- 스트리밍: 부분 응답으로 지연 인식 개선 + 조기 종료 가능.
- 배치 처리: 실시간 불필요한 워크로드를 야간 배치로. 50% 절감.
- 비용 모니터링: 요청별, 피처별, 사용자별 비용 추적 없이 최적화는 불가능.
이 중 팀 리드가 가장 먼저 챙겨야 할 것은 7번 모니터링이다. 측정 안 된 건 최적화할 수 없다.
팀 리드를 위한 실전 프레임
세 사례를 엮으면 AI 코딩 도구의 비용 구조를 판단하는 3단계 프레임이 나온다.
1단계: 워크로드 분류 먼저 어떤 쿼리가 얼마나 발생하는지 모르면 어떤 모델 조합이 최적인지 계산할 수 없다. Hartley의 30줄 라우터, Faure의 44개 세션 문서, 티어링 구현 코드—모두 분류 없이는 작동하지 않는다.
2단계: 실패 지점을 설계에 반영 로컬 모델이 RLS 취약점을 놓친 것처럼, AI 도구는 반드시 실패하는 구간이 있다. 그 구간을 모른 채 도입하면 비용 절감이 아니라 품질 리스크가 된다. Faure의 독트린이 9번 개정된 이유가 여기 있다.
3단계: 규칙은 텍스트가 아니라 코드로 CLAUDE.md에 텍스트로 적힌 규칙은 압박 상황에서 무너진다. Faure가 증명했다. 팀에 AI 도구를 도입할 때도 마찬가지다. 운용 규칙은 워크플로우에 물리적으로 삽입돼야 작동한다.
AI 도구 비용, 결국 설계의 문제다
'Claude Code 쓰면 생산성 얼마나 오르나요?'라는 질문 자체가 틀렸다. 도구가 아니라 그 도구를 어떻게 운용하는지가 ROI를 결정한다. 60일 ERP 회고가 말하는 건 Claude Code의 성능이 아니라, 58일 동안 독트린을 9번 개정하면서 만들어낸 운용 구조다.
팀에 AI 코딩 도구를 도입하기 전, 답해야 할 질문은 이 세 가지다. 워크로드를 분류했는가? 실패 지점을 파악했는가? 규칙을 코드로 강제할 수 있는가.
이 세 가지 없이 도입하면, 청구서는 늘고 품질 신뢰는 흔들린다. 숫자가 그걸 말해주고 있다.