5가지 코딩 작업에 10개의 AI 모델을 실행해 보았습니다 — 전체 데이터 공개

지난 주말, 저는 주방 테이블을 정리하고 새 노트(저는 구식이라 종이 노트를 사용합니다)를 펼친 뒤, 3일간의 벤치마크 마라톤이 된 실험을 시작했습니다. 제 목표는 간단했습니다. 2026년에 어떤 AI 모델이 실제로 "최고의 코딩 어시스턴트 (best coding assistant)" 왕관을 차지할 자격이 있는지, 그리고 더 많은 비용을 지불하는 것이 실제로 더 나은 코드와 상관관계가 있는지 알아내는 것이었습니다.

저는 직업상 데이터 과학자 (data scientist)이기 때문에, 단순히 느낌만으로 이 모델들을 판단할 수는 없었습니다. 점수를 매기고, 그래프를 그리고, 회귀 분석 (regression)을 수행하듯 수치를 계산해야 했습니다. 다음은 제가 모든 증거와 함께 알아낸 모든 내용입니다.

이 벤치마크를 실행하게 된 이유

이전에도 데인 적이 있습니다. 지난 분기에 Twitter 스레드를 바탕으로 "최고 등급"의 코딩 모델을 선택하여 우리 팀의 파이프라인 (pipeline)에 통합했는데, 미묘하게 오류가 있는 PR (Pull Request)을 세 번 연속으로 만들어내는 것을 목격했습니다. 그때 깨달았습니다. 일화적인 순위는 가치가 없다는 것을요. 저만의 데이터가 필요했습니다.

제 샘플 크기는 결국 10개 모델 × 5개 작업 = 50개의 점수가 매겨진 상호작용이 되었습니다. 이것이 영원한 승자를 선언할 만큼 통계적으로 견고할까요? 아니요, 하지만 명확한 패턴을 파악하고 최악의 함정을 피하기에는 충분합니다. 우리가 추구하는 것은 인과관계 (causation)가 아닌 상관관계 (correlation)입니다.

먼저 라인업을 살펴보겠습니다.

라인업: 가격순으로 정렬된 10개 모델

단 하나의 프롬프트 (prompt)를 실행하기도 전에 몇 가지 눈에 띄는 점이 있었습니다. 가격 차이가 엄청납니다. $0.20인 Ga-Standard와 $3.00인 Kimi K2.5 사이에는 15배의 차이가 납니다. 만약 $3 모델이 $0.25 모델보다 10점 만점 기준으로 단 1점만 더 높게 점수를 받는다면, 그것은 형편없는 거래입니다. 스포일러를 하자면: 정확히 그런 일이 일어났습니다.

테스트 설정 방법

언어/관심 분야당 하나씩 총 5개의 작업을 선정했습니다. 이 작업들을 선택한 이유는 일상적인 엔지니어링 업무의 핵심을 다루기 때문입니다:

1. 함수 구현 (Function implementation) — Python에서 중첩된 리스트를 재귀적으로 평탄화(flatten)하기
2. 버그 수정 (Bug fix) — JavaScript에서 async/await 레이스 컨디션 (race condition) 진단하기
3. 알고리즘 (Algorithm) — 적절한 타이핑 (typing)을 적용하여 TypeScript로 구현한 Dijkstra의 최단 경로 알고리즘
4. 코드 리뷰 (Code review) — Go 서비스의 보안 및 성능 리뷰
5. 전체 기능 구축 (Full feature build) — Express.js를 사용한 페이지네이션 및 필터링 기능이 포함된 REST 엔드포인트

점수는 가중치가 적용된 네 가지 차원에 따라 1~10점으로 매겨졌습니다: 정확성 (correctness, 40%), 코드 품질 (code quality, 25%), 문서화 (documentation, 15%), 그리고 예외 케이스 처리 (edge-case handling, 20%). 모든 모델은 재시도 없이 정확히 동일한 순서로 정확히 동일한 프롬프트를 받았습니다. 저는 유리한 결과만 골라내지(cherry-pick) 않았습니다. 두 번째 기회도 주지 않았습니다. 제가 점수를 매긴 것은 바로 첫 번째 응답이었습니다.

짧은 주의 사항: 저는 global-apis.com/v1이라는 단일 통합 엔드포인트를 통해 테스트했으므로 네트워크 지연 시간 (network latency) 변수를 중립화했습니다. 만약 이 실험을 재현하시려면 저와 동일한 방식을 권장합니다.

Python 10줄로 자신만의 테스트 환경 구축하기

사람들이 제가 실제로 이 모델들을 어떻게 호출하는지 항상 물어보기 때문에, Global API를 가리키는 OpenAI 호환 클라이언트를 사용한 최소한의 예시를 소개합니다:

import os
from openai import OpenAI

...

이 단 한 번의 설정 변경이 특정 벤더에 종속되는 것(vendor lock-in)과 이 포스트의 사례처럼 공정한 비교(apples-to-apples) 벤치마크를 실행할 수 있는 것 사이의 차이를 만듭니다. 또한 이를 통해 저는 도구를 다시 작성하지 않고도 DeepSeek, Qwen, Kimi 사이를 자유롭게 전환할 수 있었습니다.

주요 수치 (The Headline Numbers)

자, 두구두구. 제가 한 시간 동안 뚫어지게 쳐다봤던 마스터 테이블을 공개합니다. 점수(Score)는 다섯 가지 작업 전체의 평균이며, "가치 (Value)"는 제가 가장 좋아하는 열입니다. 이는 출력 비용 1달러당 점수를 의미합니다.

Ga-Standard에 붙은 별표(*)는 한 단락을 할애할 가치가 있습니다. 왜냐하면 이 연구 전체에서 가장 기이한 결과이기 때문입니다. Ga-Standard는 단일 모델이 아닙니다. 이는 프롬프트에 가장 적합한 기반 모델을 선택하는 라우팅 레이어 (Routing Layer)입니다. 이 모델의 점수는 작업에 따라 변동되지만 (그래서 별표를 표시했습니다), 평균적으로는 체급을 훨씬 뛰어넘는 성능을 보여줍니다. 만약 작업 부하가 이질적 (Heterogeneous)이라면, 이는 진정으로 흥미로운 선택지입니다. 하지만 일관되고 재현 가능한 동작이 필요하다면, 단일 모델을 선택해야 합니다.

가격과 품질 사이의 상관관계는... 약합니다

잠시 통계학자의 관점에서 살펴보겠습니다. 10개 모델 전체에 대해 토큰 100만 개당 가격 대비 평균 점수를 그래프로 그려보면, 피어슨 상관 계수 (Pearson correlation coefficient)는 대략 r ≈ 0.18로 나타납니다. 이는 매우 약한 양의 상관관계이며, n=10인 상황에서 통계적으로 유의미하지도 않습니다. 쉬운 말로 하자면: 더 많은 비용을 지불한다고 해서 반드시 더 나은 코드를 얻을 수 있는 것은 아닙니다.

이 점을 잠시 곱씹어 보십시오. 3.00달러인 Kimi K2.5는 9.0점을 받았습니다. 0.25달러인 DeepSeek V4 Flash는 8.7점을 받았습니다. 0.3점의 품질 차이를 위해 12배나 더 많은 비용을 지불하는 셈입니다. 이것은 가치가 아니라, 일종의 사치세 (Luxury tax)입니다.

높은 가격이 정당화될 수 있는 유일한 모델은 DeepSeek-R1뿐이지만, 이 또한 잠시 후에 설명할 특정 사용 사례에 국한됩니다.

작업 1: Python Flatten 테스트

프롬프트는 다음과 같았습니다: "중첩된 리스트를 재귀적으로 평탄화(Flatten)하는 Python 함수를 작성하세요."

사소해 보이죠? 하지만 얼마나 많은 모델이 이 문제를 과하게 생각하는지 알게 되면 놀라실 겁니다. 제가 매긴 점수는 다음과 같습니다:

DeepSeek-R1이 이 항목에서 승리했으며, 솔직히 놀랍지 않았습니다. 추론형 (reasoning-style) 모델들은 "작업 과정을 설명하라"고 요청했을 때 매우 뛰어난 성능을 보이는데, 이는 말 그대로 단계별로 생각하도록 설계되었기 때문입니다. 다만 주의할 점은, R1은 출력 토큰 100만 개당 2.50달러의 비용이 든다는 것입니다. 30줄짜리 함수 하나를 실행할 때는 1센트 미만의 아주 적은 비용이 들지만, 대량의 워크로드 (bulk workloads)에서는 이 프리미엄 비용이 부담이 될 수 있습니다.

작업 2: JavaScript 레이스 컨디션 (Race Condition)

이것은 제가 가장 좋아했던 작업입니다. 저는 모든 모델에게 다음과 같은 결함이 있는 코드를 주었습니다:

let data = null;
fetch('/api/data').then(r => r.json()).then(d => data = d);
console.log(data); // 항상 null을 출력함

fetch 때문에 고생해 본 사람이라면 누구나 이 버그를 쉽게 알아챌 수 있습니다. 즉, console.log가 프로미스 (promise)가 해결(resolve)되기 전에 동기적 (synchronously)으로 실행된다는 점입니다. 흥미로운 지점은 모델들이 버그를 찾아냈는지 여부(모두 찾아냈습니다)가 아니라, 그 버그를 어떻게 설명하고 무엇으로 수정했느냐 하는 것이었습니다.

최상위권의 공동 순위는 실질적입니다. DeepSeek V4 Flash와 Qwen3-Coder-30B 모두 완벽하게 해결했으며, 두 모델 모두 저렴합니다. 만약 제가 디버깅 도움을 받기 위해 특정 모델을 선택해야 한다면, 이 두 모델 중 하나를 선택하고 남은 비용을 아낄 것입니다.

작업 3: TypeScript에서의 다익스트라 (Dijkstra) 알고리즘

가장 어려운 순수 알고리즘 작업입니다. 저는 "TypeScript로 구현한 다익스트라 최단 경로 알고리즘"을 요청했습니다. 제가 정말로 확인하고 싶었던 것은 모델들이 적절한 타입 (types)을 사용하는지(이상적으로는 Map<Vertex, number> 우선순위 구조) 아니면 단순히 타입 어노테이션 (type annotations)만 덧붙인 채 any가 가득한 JavaScript 방식으로 회귀하는지 여부였습니다.

이것은 DeepSeek-R1이 2.50달러의 가치를 증명하는 작업입니다. 추론 모델 (Reasoning models)은 그래프 알고리즘 (graph algorithms)에서 확실히 빛을 발합니다. R1이 보여준 타입 안정성 (type-safety) 처리는 솔직히 제가 본 것 중 최고였습니다. 전체 제네릭 (generics)을 갖춘 적절한 최소 힙 (min-heap)을 구축했습니다. 만약 진지한 알고리즘 작업을 수행하고 있다면, 특히 이 카테고리에서는 추론 계층 (reasoning tier)을 사용할 가치가 있습니다.

작업 4: Go 코드 리뷰 (Go Code Review)

저는 세 가지 보안 이슈(문자열 연결을 통한 SQL 인젝션 (SQL injection), 제한 없는 쿼리 (unbounded query), 공유 맵 (shared map)에 대한 뮤텍스 (mutex) 누락)가 포함된 200줄짜리 Go 서비스를 제공하고 리뷰를 요청했습니다. 기준은 다음과 같았습니다: 모델이 세 가지 이슈를 모두 찾아냈는가, 그리고 단순히 "보안 추가를 고려하세요"라고 말하는 대신 코드 수준의 수정 사항을 제안했는가?

여기서도 저는 DeepSeek-R1에게 승리를 주었지만, DeepSeek V4 Pro는 3배 더 저렴하면서도 모든 것을 잡아냈다는 점에서 가치 있는 언급 (honorable mention)을 받을 자격이 있습니다.

작업 5: Express.js REST 엔드포인트 (Express.js REST Endpoint)

"전체 기능" 스트레스 테스트입니다. 저는 적절한 상태 코드 (status codes), 유효성 검사 (validation), 그리고 최소한의 기본 테스트를 포함하며, 페이지네이션 (paginated) 및 필터링 (filtered) 기능이 있는 사용자 엔드포인트를 요청했습니다. 이것은 실제 프로덕션 작업을 모방하는 작업이므로, it