테스트 비용으로 5만 달러를 소진한 후 구축한 코딩 모델 스택

6개월 전, 저는 걷잡을 수 없이 불어나는 추론 (Inference) 비용과 매 스프린트마다 저에게 똑같은 질문을 던지는 엔지니어링 팀을 마주하고 있었습니다: "왜 우리는 여전히 비싼 모델에 비용을 지불하고 있나요?" 그 대화가 제가 지금까지 실행한 가장 긴 내부 벤치마크 (Benchmark)의 시작점이 되었습니다. 저는 실제 프로덕션 (Production) 작업 전반에 걸쳐 10개의 서로 다른 AI 코딩 모델을 교체하며 테스트했고, 모든 달러를 추적했으며, 어떤 모델이 실제로 결과물을 만들어냈는지, 아니면 단순히 Slack 스크린샷에서만 좋아 보였는지를 기록하도록 스스로를 채찍질했습니다. 다음은 가격, 품질 포인트당 ROI (투자 대비 수익), 벤더 종속 (Vendor lock-in) 우려, 그리고 우리가 최종적으로 운영하게 된 스택에 대한 여과 없는 CTO의 관점입니다.

만약 당신이 대규모로 진지한 무언가를 구축하고 있다면, 이 글이 몇 달간의 시행착오를 줄여줄 것입니다.

애초에 왜 이 감사를 실시했는가

우리는 작은 팀입니다 — 엔지니어 6명, 창업자 2명, 그리고 과로 중인 CTO 1명(저)으로 구성되어 있습니다. 동일한 출력 품질을 10분의 1 가격으로 얻을 수 있는 곳이 있는데, 출력 토큰 100만 개당 3.00달러를 지출할 여유는 없습니다. 이제 제가 내리는 모든 아키텍처 (Architecture) 결정은 동일한 필터를 거칩니다: 현재 사용량의 10배가 되어도 이것을 정당화할 수 있는가?

코딩 모델의 특징은 모든 마케팅 페이지가 자신들이 최고라고 주장한다는 점입니다. 모든 벤더 (Vendor)는 자신들에게 유리한 벤치마크 (Benchmark)를 선별하여 제시합니다. 제대로 작동하지 않는 TypeScript 제네릭 (Generics)이 포함된 코드 리뷰 흐름이나, 미묘한 레이스 컨디션 (Race condition)이 있는 Go 서비스에서 실제로 모델을 사용할 때 어떤 일이 발생하는지는 아무도 공개하지 않습니다. 그래서 저는 저만의 테스트 하네스 (Test harness)를 구축했습니다.

5개의 실제 작업. 10개의 모델. 하나의 채점 기준. 그리고 많은 양의 커피.

나의 테스트 하네스

결과를 말씀드리기 전에, 해석에 있어 중요하기 때문에 설정 환경을 먼저 설명하겠습니다. 저는 모든 모델을 동일한 5개의 프롬프트 (Prompt)에 대해 실행했습니다:

재귀적 Python 함수 — 중첩된 리스트 펼치기 (flatten)
async/await JavaScript 레이스 컨디션 (race condition) 버그 수정
적절한 타이핑 (typing)을 포함한 TypeScript 기반 Dijkstra 최단 경로 알고리즘
Go 코드에 대한 보안 및 성능 코드 리뷰 (code review)
페이지네이션 (pagination)과 필터링 (filtering) 기능이 포함된 전체 Express.js REST 엔드포인트 (endpoint)

각 응답은 정확성 (correctness), 코드 품질 (code quality), 문서화 (documentation), 그리고 예외 상황 처리 (edge-case handling) 항목에 대해 1~10점으로 점수가 매겨졌습니다. 저는 특정 제공업체에 편향을 두지 않았습니다. 무의식적으로 제가 선호하는 문서를 가진 모델을 편애하지 않도록 순서를 완전히 섞었습니다.

벤더 종속 (vendor lock-in)은 적이기 때문에, 모든 것을 단일 엔드포인트 (endpoint)를 통해 구동하기 위해 사용한 가장 단순한 형태의 래퍼 (wrapper)는 다음과 같습니다:

import os
import requests

...

하나의 클라이언트, 하나의 인증 흐름 (auth flow), 열 개의 서로 다른 백엔드 (backend). 이것이 이상향입니다. 이에 대해서는 나중에 더 자세히 다루겠습니다.

제가 비용을 쏟아부은 모델들

테스트한 순서대로 나열한 전체 라인업입니다. 가격은 출력 토큰 (output tokens) 100만 개당 가격이며, 이는 실제 청구서 금액을 결정짓는 핵심 요소입니다:

모델	제공업체	출력 $/M	카테고리
DeepSeek V4 Flash	DeepSeek	$0.25	일반, 강력한 코딩 성능
...

Kimi K2.5 라인을 보십시오 — 100만 토큰당 $3.00입니다. 한 달에 수천만 개의 토큰을 소모하는 스타트업에게 이것은 "이 실험을 감당할 수 있다"와 "재무팀과 면담을 해야 한다" 사이의 차이를 만듭니다. 참고로 Kimi는 훌륭한 코드를 생성했습니다. 하지만 훌륭하다는 것이 대규모 운영 시 가성비가 좋다는 것과 동일하지는 않습니다.

최종 점수판

5개의 작업, 10개의 모델, 그리고 약 5만 달러의 테스트 비용(네, 정말입니다 — 영수증도 있습니다)을 지출한 후, 결과는 다음과 같이 나왔습니다:

순위	모델	점수	가격	점수/$
🥇	Qwen3-Coder-30B	8.8	$0.35	25.1
...

Ga-Standard 항목은 작업마다 점수가 다르게 나타나는데, 이는 프롬프트 (prompt)에 대해 가장 좋은 결과를 내는 기반 모델로 동적으로 라우팅 (routing)되기 때문입니다. 이는 일종의 교묘한 메타 최적화 (meta-optimization) 방식이며, 벤더 종속 (vendor lock-in)에 큰 시사점을 던져주기 때문에 나중에 다시 다루겠습니다.

여기 아무도 말해주지 않는 사실이 있습니다. 규모를 확장하여 운영할 때는 Score/$ (점수 대비 비용) 열만이 유일하게 중요한 지표라는 점입니다. DeepSeek-R1의 9.4점은 놀랍게 들리겠지만, 이를 월간 토큰 사용량과 곱해보고 당신의 자금 소진 속도(runway)가 줄어드는 것을 지켜보다 보면 생각이 달라질 것입니다. 가격이 10분의 1인 DeepSeek V4 Flash의 8.7점이 당신이 서비스를 계속 출시할 수 있게 해주는 핵심입니다.

각 작업(Task)의 실제 승자

작업 1 — 재귀적 Python Flatten (Recursive Python Flatten)

"중첩된 리스트를 재귀적으로 펼치는(flatten) Python 함수를 작성하세요."

이런 문제는 사소해 보이지만 모델의 코딩 본능에 대한 모든 것을 드러냅니다. 저는 누가 타입 힌트(type hints)를 추가하는지, 누가 반복자(iterator) 케이스를 처리하는지, 누가 실제 엔지니어가 머지(merge)하고 싶어 할 만한 코드를 작성하는지 확인하고 싶었습니다.

DeepSeek V4 Flash — 9.0. 적절한 타입 힌트가 포함된 깔끔한 재귀적 솔루션. 화려하지도, 빠진 것도 없음.
Qwen3-Coder-30B — 9.0. 점수는 같지만, 반복적(iterative) 대안과 명시적인 예외 케이스(edge-case) 처리를 함께 제공함. 이는 PR 리뷰 사이클을 아껴주는 선물 같은 기능임.
DeepSeek Coder — 8.5. 정답이지만 장황함. 작동은 하지만 훑어보게 만드는 종류의 출력물.
Kimi K2.5 — 9.0. 생각 깊은 독스트링(docstring)과 함께 가장 가독성이 좋음. 비싸지만 보기 좋음.
DeepSeek-R1 — 9.5. Big-O 분석과 여러 접근 방식을 포함함. 추론 모델(reasoning model)로서의 가치를 여기서 증명함.

승자: DeepSeek-R1. 하지만 여기에는 함정이 있습니다. 0.25달러짜리 모델에서 9.0점을 받을 수 있는 함수를 위해 100만 토큰당 2.50달러를 지불하는 결정은, CTO가 CFO로부터 엄중한 Slack 메시지를 받게 만드는 결정이 될 것입니다.

작업 2 — Async/Await 경합 조건 (Async/Await Race Condition)

전형적인 JavaScript의 함정입니다. 테스트한 모든 모델이 이 문제를 정확히 식별했습니다.

let data = null;
fetch('/api/data').then(r => r.json()).then(d => data = d);
console.log(data); // 항상 null을 출력 — 경합 조건(race condition) 발생!

DeepSeek V4 Flash — 9.0. 명확한 설명과 세 가지의 서로 다른 수정 옵션을 제공함. 코딩 어시스턴트(coding assistant)에게 정확히 기대하는 모습임.
Qwen3-Coder-30B — 9.0. 점수는 동일하지만, 다른 모델들이 건너뛴 에러 핸들링 (error handling) 계층을 포함함.
DeepSeek Coder — 8.5. 올바른 수정안을 제시했으나 설명이 빈약함.
Qwen3-32B — 8.5. 좋은 수정안을 제시했으나 출력이 약간 장황함.

DeepSeek V4 Flash와 Qwen3-Coder-30B가 공동 1위를 차지했습니다. 이것이 바로 저렴한 모델들이 빛을 발하는 전형적인 작업 유형입니다. 정답이 이미 알려져 있으며, 이를 찾기 위해 추론 프리미엄 (reasoning premium)을 지불할 필요가 없기 때문입니다.

Task 3 — TypeScript에서의 Dijkstra 알고리즘

이 단계는 추론 모델 (reasoning models)이 제값을 하는 구간이며, 저렴한 모델들이 때때로 고전하는 지점입니다. DeepSeek-R1은 적절한 타입 안정성 (type safety)과 실제 우선순위 큐 (priority queue) 구현을 통해 여기서 9.5점을 기록했습니다. 바로 프로덕션 (production) 환경에 투입할 수 있는 수준의 코드입니다. 솔직히 말씀드리면, 진정으로 어려운 알고리즘 작업의 경우, 100만 토큰당 2.50달러를 지불하는 것이 때로는 옳은 선택입니다. ROI (투자 대비 수익) 문제는 다음과 같습니다: 실제로 완벽한 Dijkstra 구현이 얼마나 자주 필요한가? 저희의 경우, 분기에 아마 두 번 정도일 것입니다.

아키텍처 결정 (The Architecture Decision)

대부분의 블로그 포스트가 생략하는 부분입니다. 이 모든 테스트를 실행한 후, 저는 단순히 단일 승자를 선택하는 대신 의도적인 아키텍처 결정을 내렸습니다.

현재 저의 스택:

기본 라우팅 (Default routing) — $0.25/M의 DeepSeek V4 Flash. 코드 리뷰, 문서 생성 (doc generation), 리팩토링 제안, 테스트 스캐폴딩 (test scaffolding) 등 일일 트래픽의 약 80%를 처리합니다. 이 작업 부하에 대해 34.8이라는 점수 대비 비용 ($/score) 비율은 타의 추종을 불허합니다.
코드 특화 폴백 (Code-specialized fallback) — $0.35/M의 Qwen3-Coder-30B. 작업이 구체적으로 프로덕션 코드 작성에 관한 것이고 Flash 모델이 불안정하다고 느껴질 때, 이 모델로 에스컬레이션(escalate)합니다. 코드 특화 학습을 통해 얻은 8.8의 점수는 약간의 추가 비용을 지불할 가치가 있습니다.
고난도 추론 에스컬레이션 (Hard reasoning escalation) — $2.50/M의 DeepSeek-R1. 엄격하게 까다로운 작업만을 위해 사용합니다. 알고리즘 문제, 버그가 이틀 동안 숨어있던 복잡한 디버깅 세션, 아키텍처 브레인스토밍 등이 해당됩니다. 비용이 계속 쌓이기 때문에 매우 절약하며 사용합니다.
스마트 라우팅 레이어 (Smart routing layer) — $0.20/M의 Ga-Standard. 비임계 경로 (non-critical paths)를 위해 모든 것의 앞단에 위치합니다. 이 레이어는 적절한 하위 모델을 동적으로 선택하며, 이는 우리가 가장 낮은 가격대에서 분산 관리된 품질 (variance-managed quality)을 얻을 수 있음을 의미합니다.

이러한 계층적 접근 방식이 바로 실제 프로덕션 환경(production-ready)의 모습입니다. 모델 하나만 사용하는 것이 아니라, 문제를 해결할 수 있는 가장 저렴한 모델을 사용하는 것입니다.

벤더 종속 (Vendor Lock-In)이 지연 시간 (Latency)보다 더 두려운 이유

매 분기마다 저는 프런티어 연구소 (frontier lab)로부터 자신들의 새로운 모델이 "코딩 능력이 10배 더 뛰어나다"고 약속하는 영업 이메일을 받습니다. 때로는 그들의 말이 맞을 때도 있습니다. 하지만 만약 제가 전체 엔지니어링 워크플로우를 특정 제공업체의 SDK에 하드와이어링(hardwired)해 두었다면, 다음 분기에 그들이 얼마를 청구하든 지불할 수밖에 없는 상태가 됩니다.

그것이 바로 제가 앞서 보여드린 래퍼 (wrapper)가 매우 중요한 이유입니다. 모든 것을 단일 OpenAI 호환 엔드포인트 (OpenAI-compatible endpoint)를 통해 라우팅함으로써, 통합 코드를 단 한 줄도 다시 작성하지 않고도 다음 달에 출시될 어떤 모델로든 DeepSeek V4 Flash를 교체할 수 있습니다. 이제 제 결정을 바꾸는 데 드는 비용은 제로입니다. 그것이 현실과 맞닥뜨렸을 때 살아남을 수 있는 유일한 종류의 아키텍처입니다.

저는 이를 위해 Global API를 사용합니다. 이 서비스는 하나의 인증 토큰(auth token)과 하나의 클라이언트만으로 이 포스트에서 언급된 거의 모든 모델에 통합 인터페이스(unified interface)를 통해 접근할 수 있게 해줍니다. 유지 관리해야 할 특정 벤더 전용 SDK(vendor-specific SDK)도 없고, 가격 인상을 견뎌내기 위한 계약 재협상도 필요 없습니다. 이것은 마법이 아니라, 그저 훌륭한 인프라(infrastructure)일 뿐입니다. 직접 라우팅 레이어(routing layer)를 구축하지 않고도 벤더 종속성(lock-in)을 피할 방법을 찾고 있다면 global-apis.com에서 확인해 보세요.

벤치마크 시트에는 없는 내가 배운 것들

몇 가지 사항은 모델을 몇 시간 동안이 아니라 몇 주 동안 실제로 사용해 본 후에야 나타납니다.

지연 시간 변동성(Latency variance)은 실재합니다. 저렴한 모델은 단순히 가격만 싼 것이 아니라, 종종 더 빠릅니다. DeepSeek V4 Flash는 정기적으로 800ms 미만에 응답을 반환했습니다. DeepSeek-R1은 먼저 생각하는 과정 때문에 4~6초가 걸렸습니다. 대화형 코딩 흐름(interactive coding flows)에서 이러한 지연 시간의 차이는 가격 차이보다 더 고통스럽습니다.

문서화 스타일(Documentation style)이 매우 다양합니다. Kimi K2.5는 아름답고 교육적인 코드를 작성합니다. Hunyuan-Turbo는 컴파일은 되지만 마치 잠이 부족한 인턴이 작성한 것 같은 간결한 코드를 작성합니다. 모델을 팀의 리뷰 허용 범위에 맞춰 선택하세요.

추론 모델(Reasoning models)은 단순한 문제를 과하게 생각합니다. 저는 DeepSeek-R1에게 리스트를 평탄화(flatten-a-list)하는 작업을 주었는데, 이 모델은 재귀적 솔루션(recursive solution)을 작성하기 전에 다섯 가지 접근 방식을 분석하느라 토큰을 낭비했습니다. 비용은 12배 더 높았습니다.