AI 코딩 도구, '비쌀수록 좋다'는 편견에 도전하다: 2달러 미만으로 프로덕션 레벨 코드 얻기!
2026. 6. 24.
AI 코딩 도구, '비쌀수록 좋다'는 편견에 도전하다: 2달러 미만으로 프로덕션 레벨 코드 얻기!
수년간 제 워드프레스(WordPress) 사이트들은 오픈라이트스피드(OpenLiteSpeed, OLS) 기반으로 안정적으로 운영해왔습니다. OLS는 빠른 서버 성능을 자랑하고, LSCache는 정말 인상적이었죠. OLS와 워드프레스 조합은 순수 성능 면에서 거의 따라올 적수가 없다고 봐도 무방했습니다.
컨트롤 패널로는 사이버패널(CyberPanel)로 시작했습니다. 솔직히 MS 제품보다 더 많은 버그를 경험했다고 말해도 과언이 아닙니다. 게다가 개발팀은 유료 플랜으로 유도하기 위해 무료 기능들을 의도적으로 망가뜨리는 것 같았어요. 단순히 고칠 수 없는 버그가 아니라, 무료 티어 기능이 어떤 액션도 완료하지 못하게끔 설계된 듯한 버그들이었습니다.
두 가지 사례를 들어볼까요? 첫째, 워드프레스 설치. 몇 년 동안 아무 문제 없이 사용해왔던 기능인데, 사이버패널 v2.4.x부터 SQL 오류가 마지막 단계를 가로막았습니다. 파일은 모두 다운로드되어 있지만, 데이터베이스를 수동으로 생성하고 직접 설치를 진행해야 했죠. 이 정도면 직관적이지 못하다는 표현도 부족합니다.
둘째, Let's Encrypt SSL 인증서 생성은 지속적으로 실패했습니다. 생성된 설정 파일이 정확하지 않았기 때문입니다. 그리고 이 두 가지 경우 모두, "향상된" 유료 버전이 존재한다는 게 참 아이러니했습니다.
제 입장은 간단합니다. 오랫동안 잘 작동하던 기능이 갑자기 작동하지 않는다면, 유료 버전도 제대로 작동할 것이라는 보장이 없습니다. 내일이라도 정책이 바뀔지 누가 알겠어요? 이걸 '미끼 상술'이라고 단정 짓고 싶진 않습니다. 하지만 무료 기능이 수년간 문제없이 작동하다가 여러 후속 버전에서 계속해서 멈추고, 그 자리를 유료 대안이 채운다면... 질문은 그 자체로 답이 된다고 생각합니다. 저는 이 질문을 던졌고, 제 나름의 결론을 내린 후 해당 벤더를 블랙리스트에 올렸습니다.
그래서 저는 aaPanel로 넘어갔습니다. 더 쾌적하고 안정적이며 가벼웠죠. 하지만 OLS 관리 방식은 완전히 엉망이었습니다. OpenLiteSpeed를 직접 구성할 수 없고, 모든 것이 aaPanel의 추상화 레이어를 통해서만 이루어졌습니다. 결국 제 스택에 대한 제어권을 잃게 된 거죠. 포트 7080을 직접 건드리면 모든 것이 망가질 위험이 있었습니다. 그저 aaPanel 대시보드를 사용하는 수밖에 없었습니다. 더 이상 논할 가치도 없었죠.
그러다 제 사용 패턴이 바뀌기 시작했습니다. Astro나 준(quasi)-정적 사이트, PHP가 필요 없는 프로젝트들이 늘어났죠. 워드프레스 생태계를 벗어나는 순간 OLS의 매력은 빛을 잃었습니다. 반면에 Caddy는 HTTPS를 자동으로 처리하고, 설정 파일은 몇 줄의 읽기 쉬운 코드로 충분하며, OLS처럼 복잡한 리라이트(rewrite) 문제가 없었거든요.
결론적으로 이런 질문에 도달했습니다. "aaPanel/OLS를 Caddy와 커스텀 컨트롤 패널로 대체할 수 있을까?" GitHub에는 CaddyManager(별 1.1k개, 단일 기여자, 영원히 "초기 개발" 상태)와 CaddyGen(8시간 만에 만든 Caddyfile 생성기, 완성품이라기보다 PoC에 가까움) 같은 프로젝트들이 있었습니다. 하지만 프로덕션 환경에 바로 적용할 만한 것은 없더군요.
답은 명확했습니다. 잘 작성된 셸 스크립트와 최소한의 FastAPI 인터페이스면 충분할 것이고, 유지보수 측면에서도 훨씬 나을 겁니다. 물론 누군가는 그걸 직접 작성해야 했습니다. 바로 제가요.
하지만 이왕 만드는 거, 좀 더 효율적인 방법을 찾아보기로 했습니다. GitHub Copilot CLI나 Claude Code에 사양을 넘겨주는 것을 고려했습니다. 그런데 Copilot의 새로운 가격 정책을 보니, 입술만 살짝 적셔도 바로 청구서가 날아올 것 같더군요. 문득, DeepInfra 또는 OpenRouter에 연결된 OpenCode와 Kilo CLI 같은 대안 서비스에 관심이 생겼습니다. 그래, 이 기회에 제대로 벤치마킹해보자는 결정을 내렸습니다. 제가 실무에서 이 부분을 테스트해 봤을 때, 이런 자동화된 툴들이 과연 실질적인 가치를 제공할지 궁금했거든요.
📋 요약: 실제 VPS 프로젝트에서 8가지 도구/모델 조합을 테스트했습니다. 아키텍처 구상, 코드 구현 두 단계로 진행했고, 외부 코드 리뷰어가 평가를 내렸죠. 프로덕션 레벨로 판단된 유일한 툴킷은 총 1.94달러밖에 들지 않았습니다. 승리한 모델은 아마 여러분이 흔히 보던 비교 목록에는 없었을 겁니다.
💡 참고: 섹션 5 전까지는 코드 구현 단계에서 선택된 네 가지 구현체를 A, B, C, D로 표기합니다. 모델 이름은 외부 리뷰 결과가 나온 후에 공개됩니다. 배심원단을 익명으로 하는 것과 같은 이유죠. '라벨'을 보기 전에 '코드'를 먼저 평가해 주시길 바랍니다.
1. 테스트 프로젝트
요구사항은 의도적으로 구체적이었습니다. 우분투 24.04용 최소한의 VPS 관리 툴킷을 만드는 것이었죠. 웹 서버는 Caddy, PHP-FPM은 두 가지 버전(현재 버전 및 대체 버전), MariaDB와 PostgreSQL, 객체 캐싱을 위한 Valkey를 사용합니다. 모든 작업은 셸 스크립트로 처리하고, 자동화를 위한 FastAPI 인터페이스를 제공합니다. Docker나 별도의 컨트롤 패널은 사용하지 않고, 불필요한 추상화도 배제했습니다.
처리해야 할 사이트 유형은 네 가지였습니다.
- Static: HTML/정적 자산만 포함하며 PHP나 데이터베이스는 사용하지 않습니다.
- PHP: 커스텀 애플리케이션이며, 데이터베이스는 선택 사항입니다.
- WordPress: WP-CLI를 통한 완전 설치를 포함하며, 데이터베이스는 필수입니다.
- Reverse Proxy: 단순히 Caddy vhost가 로컬 포트로 요청을 전달하는 방식입니다. 동일 서버에서 Node.js, FastAPI, Go 애플리케이션 등이 실행되는 경우를 위한 거죠. Caddy가 HTTPS와 도메인을 처리하므로, 애플리케이션은 이 부분에 신경 쓸 필요가 없습니다. PHP-FPM이나 데이터베이스 없이
reverse_proxy블록과 포트 번호만으로 구성됩니다.
예상되는 작업은 전체 라이프사이클을 포함합니다. 서버 부트스트랩, 사이트 프로비저닝, 파괴적인 작업 전에 자동 백업을 포함한 삭제, 온디맨드(on-demand) 데이터베이스 생성, rsync를 통한 정적 배포, 백업, 그리고 서비스 관리 등이 필요했습니다.
왜 인공적인 벤치마크 대신 실제 프로젝트를 선택했을까요? 인공적인 벤치마크는 모델이 이상적인 조건에서 무엇을 할 수 있는지 테스트합니다. 반면 실제 프로젝트는 보안, 멱등성(idempotency), 파일 간 일관성, 셸과 파이썬 레이어 간의 오류 처리 등 제약 조건이 쌓였을 때 모델이 어떤 역량을 발휘하는지 보여주죠. 바로 이런 지점에서 모델들 간의 실제 차이가 드러납니다. 제가 실무에서 겪어본 바로는, 복잡한 실제 환경에서 코드의 견고함과 예측 가능성이 훨씬 중요합니다.
전체 기능 요구사항은 프로젝트의 GitHub 리포지토리에서 확인할 수 있습니다.
2. 방법론
테스트 프로토콜은 사람의 검증을 거쳐 두 가지 개별 단계로 진행되었습니다.
1단계 — 아키텍처 구상
동일한 기능 요구사항이 각 도구/모델 조합에 제출되었습니다. 추가적인 컨텍스트나 설정 파일, 예상되는 솔루션에 대한 힌트는 전혀 제공하지 않았습니다. 각 도구는 아키텍처, 프로젝트 구조, 각 스크립트의 역할 목록, API 경로 맵을 제안하도록 했습니다. 만약 잘 설계된 모델이라면, 어떤 결과물을 내기 전에 질문을 던졌을 겁니다.
2단계 — 구현
계획이 검증되고 결정이 내려지면, 단일 개발 프롬프트가 모든 도구에 제출되었습니다. 이 프롬프트에는 검증된 아키텍처, 확정된 10가지 기술 결정 사항, 스크립트-API 종료 코드 규칙이 포함되었으며, "서른 개의 파일을 종속성 순서대로 디스크에 저장하고, 요약이나 지름길은 사용하지 말라"는 명확한 지시가 있었습니다.
테스트된 조합
| 도구 | 모델 |
|---|---|
| Claude Code | Haiku 4.5 |
| Copilot CLI | Haiku 4.5 |
| OpenCode | Haiku 4.5 |
| OpenCode | GLM 5.2 |
| OpenCode | BigPickle (무료) |
| OpenCode | Gemini 3.1 Pro |
| OpenCode | DeepSeek V4 Pro |
| OpenCode | GPT-OSS-120B |
Devstral 2 (123B)도 테스트 계획에 있었습니다. 아쉽게도 이 모델은 OpenCode나 Kilo CLI의 모델 선택기에 나타나지 않았습니다. 두 플랫폼 모두 models.dev에서 카탈로그를 가져오는데, OpenRouter에서는 사용 가능함에도 불구하고 아직 인덱싱되지 않았기 때문입니다. OpenRouter 플레이그라운드를 통한 테스트에서는 API 접근이 가능했지만, 코딩 에이전트 외부에서는 우리가 측정하려는 대부분의 기능을 잃게 되므로 제외되었습니다. Devstral 2는 품질 문제가 아닌 순전히 기술적인 이유로 빠지게 되었습니다.
Haiku 4.5는 세 가지 다른 도구에서 세 번 등장합니다. 이것은 의도적인 배치였습니다. 모델의 영향을 배제하고 순수하게 '도구'의 영향을 분리하여 측정하기 위함이었죠.
코드 구현 단계는 네 가지 대표적인 구현체(A, B, C, D로 표기)에서 실행되었습니다. 이들은 섹션 5에서 그 정체가 밝혀집니다.
외부 리뷰
네 가지 구현체에서 생성된 코드는 벤치마크에 참여하지 않은 다른 모델에게 제출되었으며, 고정된 평가 기준(보안, 정확성, 멱등성, 코드 품질, 완성도)에 따라 평가되었습니다. 각 구현체당 다섯 개의 대표 파일(common.sh, site-create.sh, site-delete.sh, backup.sh, api/runner.py)이 선택되었고, 각 파일은 25점 만점으로 채점되었습니다.
3. 기획 단계 — 누가 정말 '생각'을 하는가?
기능 요구사항은 각 도구에 암묵적인 질문을 던집니다. "미리 정해진 솔루션이 없는 개방형 프로젝트가 주어졌을 때, 당신은 무엇을 할 것인가?"
가장 먼저 눈에 띄는 놀라운 점은, 테스트된 모델 중 어떤 모델도 계획을 제시하기 전에 질문을 하지 않았다는 것입니다. 단 하나도요. 모든 모델은 완전한 아키텍처를 먼저 제시한 다음, 마지막에 가서야 명확화를 요구했습니다. 이는 인간 아키텍트가 모호한 부분을 먼저 해결한 뒤 그림을 그리는 방식과는 정반대입니다.
이 점은 매우 중요합니다. 뒤늦게 제기된 여러 질문들은 만약 미리 물어봤다면 아키텍처 결정 사항을 바꾸었을 겁니다. 한 모델은 "디스크에 비밀 정보를 저장하지 않는다"는 원칙과 "자격 증명이 합법적으로 필요한 애플리케이션 설정 파일(가장 대표적인 예: wp-config.php)" 사이의 긴장을 식별해냈습니다. 이것은 정말로 중요한 질문입니다. 하지만 계획 후에 질문으로 나오니 그냥 각주 정도로 치부될 뿐이죠. 실제로 제가 팀 프로젝트를 할 때도, 기획 단계에서 이런 핵심 질문을 놓치면 나중에 큰 코 다칩니다.
계획에서 드러나는 것들
질문의 품질은 모델을 구별하는 첫 번째 신호입니다. 두 모델은 진정으로 중요한, 네다섯 개의 핵심 질문을 옵션과 권장 사항과 함께 제시했습니다. 다른 모델은 아카이브 형식, 로그 로테이션 등 아키텍처에 아무런 영향을 미치지 않을 여덟 가지 일반적인 질문을 던졌습니다.
제안된 구조는 두 번째 신호입니다. 오직 한 모델만이 자발적으로 bin/vpsmgr이라는 통합 CLI 진입점을 제안했는데, 이것이 여러 스크립트를 응집력 있는 도구로 만들어주는 핵심 디테일이었습니다. 다른 모델들은 이 부분을 생각하지 못했죠.
한 모델은 기획 단계부터 정규화되고 문서화된 종료 코드(exit code) 규칙을 제안한 유일한 모델이었습니다.
| 코드 | 의미 | HTTP |
|---|---|---|
| 0 | 성공 | 200 |
| 1 | 잘못된 입력 | 400 |
| 2 | 찾을 수 없음 | 404 |
| 3 | 충돌 | 409 |
| 4 | 누락된 종속성 | 422 |
| 5 | 내부 오류 | 500 |
이는 단순히 외형적인 것이 아닙니다. 셸 스크립트와 FastAPI 레이어 간의 계약입니다. 이 규칙이 없으면 HTTP 매핑이 임의로 이루어지고, 각 경로마다 다르게 구현될 수밖에 없습니다.
기획 단계 비용
| 도구 + 모델 | 토큰량 | 비용 |
|---|---|---|
| BigPickle | ~35k | $0 |
| GPT-OSS-120B | 20k | $0.003 |
| DeepSeek V4 Pro | 31k | $0.044 |
| GLM 5.2 | 43k | $0.06 |
| Copilot + Haiku 4.5 | ~60k | $0.07 |
| Haiku 4.5 (OpenCode) | 69k | $0.076 |
| Gemini 3.1 Pro | 27k | $0.095 |
| Claude Code + Haiku | — | Pro 구독료 |
Gemini 3.1 Pro는 가장 간결한 결과물(27k 토큰)을 고품질 계획과 함께 생성했습니다. OpenCode의 Haiku 4.5는 더 낮은 품질의 결과를 위해 69k 토큰을 소비했습니다. 토큰 볼륨이 반드시 품질을 예측하지는 않는다는 것을 보여주죠.
4. 코드 구현 단계 — 누가 정말 '결과물'을 내는가?
코드 구현 단계는 네 가지 선택된 구현체에 단일 개발 프롬프트를 제출하는 것으로 시작됩니다. 이 프롬프트에는 검증된 아키텍처, 확정된 10가지 기술 결정 사항, 종료 코드 규칙, 그리고 "서른 개의 파일을 종속성 순서대로 디스크에 저장하고, 요약이나 지름길은 사용하지 말라"는 명확한 지시가 포함되었습니다.
이 단계에서 모델 간의 차이가 구체적으로 드러납니다.
common.sh에서 드러나는 것들
공유 라이브러리인 common.sh는 가장 먼저 제공되는 파일입니다. 로깅, 비밀 정보 처리, 사이트 상태 관리, 비밀번호 생성 등 모든 것이 이 파일에 기반합니다. 결함 있는 common.sh는 이를 소싱하는 모든 스크립트에 오염을 가져오죠. 실무에서 common.sh 같은 핵심 라이브러리는 코드의 품질과 유지보수성을 좌우하는 가장 중요한 부분입니다. 저도 수없이 겪었죠.
모델 A는 98줄의 간결한 코드를 제공했습니다. 비밀 정보 가리기(secret redaction)는 워드프레스 패턴 10가지(솔트, 인증 키)를 명시적으로 커버했습니다. 이 특정 지점에서는 가장 완벽했습니다. 하지만 도메인 유효성 검사, require_cmd() 함수, 원자적(atomic) 상태 파일 쓰기 기능은 없었습니다.
모델 B는 310줄의 코드를 제공했습니다. readonly 키워드를 사용한 명명된 상수, RFC-1035 정규식을 사용한 normalize_domain(), 동시성 잠금, mktemp+mv를 이용한 원자적 쓰기 등 가장 풍부한 시스템 유틸리티 라이브러리를 포함했습니다. 하지만 비밀 정보 가리기는 워드프레스 솔트를 놓쳤습니다.
모델 C는 366줄의 코드를 제공했습니다. 가리기 패턴은 하드코딩되지 않고 환경 변수를 통해 구성할 수 있었습니다. jq가 없는 경우를 대비해 파이썬 폴백(fallback)이 있는 순수 셸 JSON 헬퍼를 포함했습니다. 프롬프트에 명시된 대로 <<>> 마커로 출력을 감싸는 print_credentials() 함수도 있었습니다. 설정 파일을 위한 render_template()은 Jinja 의존성 없이 구현되었습니다. 모호한 문자(0/O/1/l/I)를 제외한 비밀번호 생성 기능도 갖췄습니다. 개발 프롬프트에 명시된 모든 엣지 케이스를 예측한 유일한 구현체였습니다.
모델 D는 184줄의 코드를 제공했습니다. 이 벤치마크에서 가장 독창적인 아이디어를 선보였습니다. 종료 코드를 exit_input_error(), exit_conflict()와 같이 명명된 함수로 캡슐화하여, 단순히 exit 3를 호출하는 것보다 훨씬 가독성이 좋았습니다. 그리고 json_output() 함수를 common.sh에 직접 넣어 셸에서 API-ready JSON을 생성할 수 있게 했습니다. 하지만 원자적 쓰기나 require_cmd()는 없었습니다.
스스로 찾거나, 찾지 못하는 버그들
모델 C는 세션 도중 자신의 코드를 테스트했습니다. schemas.py를 작성한 후, 테스트 케이스로 실행하여 두 가지 버그를 발견하고 즉시 수정했습니다. Pydantic v2 유효성 검사기(cross-field 유효성 검사를 위한 model_validator 대신 field_validator로 잘못 구현)와 스키마 수준에서 적용되지 않은 상호 배제(mutual exclusion) 문제였습니다. 또한 render_template()에서 경로의 / 문제로 인해 깨지는 sed 치환 문제도 순수 Bash 파라미터 확장으로 교체하여 수정했습니다.
세션 마지막에 모델 C는 검증 요약을 제공했습니다. 모든 스크립트에 대한 bash -n, 모든 파일에 대한 Python AST 검사, OpenAPI 스펙을 통한 19/19 API 경로 검증, 18/18 Bash 헬퍼 테스트, PHP 폴백 규칙 검증(8.5→8.4, 8.4→없음, 7.x 거부)까지 포함했습니다.
모델 A는 완료하기 전에 셔뱅(shebang)을 확인했습니다. 모델 B는 문제 해결, curl 예제, 빠른 시작 등 잘 정리된 사용자 문서를 제공했습니다. 모델 D는 bash와 Python 구문을 검증했습니다. 하지만 이 세 모델 중 그 어느 누구도 기능적 로직을 테스트하지 않았습니다.
코드 구현 단계 비용
| 모델 | 토큰량 | 시간 | 코드 생성 비용 | 총 비용 |
|---|---|---|---|---|
| A | — | 2m58s | $0 | $0 |
| D | 1.29M | 9m42s | ~$0.19 | $0.24 |
| B | — | ~15m | Pro 구독료 | $20/월 |
| C | 4.42M | 23m37s | $1.67 | $1.73 |
모델 D는 9분 42초 만에 모델 C가 23분 37초 만에 제공한 결과물을 내놓았지만, 기능 테스트는 없었습니다. 모델 C는 세션 중에 코드를 실행하고 각 반복마다 컨텍스트를 다시 로드하기 때문에 3.4배 더 많은 토큰을 소비했습니다.
5. 외부 리뷰 — 그리고 공개
네 가지 구현체, 네 가지 보안 접근 방식. 편견 없이 결론을 내리기 위해, 코드 리뷰는 벤치마크에 참여하지 않은 다른 모델에게 맡겨졌습니다. 고정된 다섯 가지 기준(보안, 정확성, 멱등성, 코드 품질, 완성도)에 따라 평가되었죠. 각 구현체당 다섯 개의 대표 파일(common.sh, site-create.sh, site-delete.sh, backup.sh, api/runner.py)—총 20개 파일이 한 번에 로드되어 평가되었습니다.
리뷰 비용은 543k 토큰에 0.0766달러였습니다. 주니어 개발자 한 시간 인건비보다 열 배는 저렴한 가격이죠.
파일별 관찰 사항
site-create.sh에 대해 리뷰어는 모델 D에서 조용한 버그를 발견했습니다. SFTP 비밀번호가 생성되지만 호출자에게 캡처되거나 반환되지 않는 문제였습니다. 사용자는 자신의 자격 증명을 볼 수 없었고, 핵심 기능이 오류 메시지 없이 작동하지 않았죠. 모델 B에서는 세 개의 스크립트에서 함수 외부에서 local이 사용되어 런타임 오류를 일으키는 Bash 버그가 있었습니다. 이것들은 미묘한 버그가 아니라, 작업을 가로막는 치명적인 버그였습니다.
site-delete.sh에서는 모델 C만이 두 가지 호출 모드(대화형 TTY와 비대화형 API 호출을 위한 --confirm 플래그)를 모두 처리했습니다. 모델 D는 대화형 모드만 구현하여, 백업 건너뛰기 기능이 있는 API 기반 삭제를 막았습니다.
backup.sh에서 모델 A와 B는 eval "$POST_HOOK"를 사용하여 잠재적인 명령 주입(command injection) 취약점을 가지고 있었습니다. 모델 C는 아카이브 경로를 인수로 전달하여 더 안전한 방식을 택했습니다. 모델 A는 자동 아카이브 정리 기능을 구현하지 않았습니다.
api/runner.py에서 모델 C만이 asyncio를 사용했고, 자격 증명이 포함될 수 있는 표준 출력(stdout)을 절대 로깅하지 않았습니다. 모델 D에는 정의되었지만 호출되지 않는 build_command()라는 데드 코드(dead code)가 있었습니다. 모델 A는 타임아웃, 로깅, 오류 처리 기능이 전혀 없는 28줄의 코드를 제공했는데, 이로 인해 요청이 중단되면 API가 무기한 블록될 수 있었습니다.
심사 결과
| 기준 | A | B | C | D |
|---|---|---|---|---|
| 보안 | 3/5 | 3/5 | 5/5 | 2/5 |
| 정확성 | 3/5 | 2/5 | 5/5 | 2/5 |
| 멱등성 | 3/5 | 3/5 | 5/5 | 3/5 |
| 코드 품질 | 3/5 | 2/5 | 5/5 | 3/5 |
| 완성도 | 3/5 | 2/5 | 5/5 | 2/5 |
| 총점 | 15/25 | 12/25 | 25/25 | 12/25 |
바로 프로덕션에 배포 가능한 수준으로 판단된 것은 네 모델 중 단 하나, 모델 C (25/25)였습니다.
승자 공개
| 별칭 | 모델 | 도구 | 총 비용 |
|---|---|---|---|
| A | BigPickle | OpenCode | $0 |
| B | Haiku 4.5 | Claude Code | Pro 구독료 |
| C | GLM 5.2 | OpenCode | $1.73 |
| D | DeepSeek V4 Pro | OpenCode | $0.24 |
모델 B (Claude Code + Haiku 4.5)는 월 최소 20달러의 Pro 구독료로 실제 한계 비용이 가장 비쌌습니다. 이 모델은 12/25점을 받았고, 근본적인 Bash 버그로 인해 배포 불가능했습니다. 반면 모델 C (칭화대학교 THUDM 연구실의 GLM 5.2)는 25/25점을 받았고, 리뷰어가 프로덕션 레벨로 판단한 유일한 모델이었습니다. 이 모든 과정에 단 1.73달러가 들었을 뿐입니다.
솔직히 말하면, 저도 꽤 놀랐습니다. 흔히 거론되는 메이저 모델들이 아닌, GLM 5.2가 압도적인 우승을 차지했으니까요. 제가 예상했던 결과는 아니었습니다.
부록 — 모델 E: Kimi K2.7 Code
독자의 의견에 따라 게시 후에 추가된 모델입니다. 동일한 프로토콜, 동일한 개발 프롬프트, 동일한 Qwen 3.7 Plus 리뷰 기준을 적용했습니다.
| 별칭 | 모델 | 도구 | 총 비용 |
|---|---|---|---|
| E | Kimi K2.7 Code | OpenCode | $0.859 |
외부 리뷰 점수: 19/25
| 기준 | E |
|---|---|
| 보안 | 3/5 |
| 정확성 | 4/5 |
| 멱등성 | 4/5 |
| 코드 품질 | 4/5 |
| 완성도 | 4/5 |
프로덕션 레벨: 아니오. 치명적인 문제는 데이터베이스 비밀번호가 mysql -e 및 psql -c의 인수로 인라인으로 전달되어, 시스템의 모든 사용자가 /proc/*/cmdline에서 볼 수 있다는 점이었습니다. 해결책은 간단합니다(MYSQL_PWD / PGPASSWORD를 환경 변수로 사용하는 것)만, 적용되지 않았습니다.
리뷰어에 따르면 벤치마크에서 가장 모듈화된 아키텍처를 가졌습니다. 깔끔한 lib/ 분할과 일관된 멱등성 패턴을 보였죠. 하지만 보안상의 큰 간극으로 인해 GLM 5.2에 도전하기는 어려웠습니다.
순위에서의 위치: DeepSeek V4 Pro ($0.24, 12/25)와 GLM 5.2 ($1.73, 25/25) 사이에 위치합니다. 모델 B, D보다 더 나은 아키텍처/비용 비율을 가졌지만, 프로덕션 레벨은 아니었습니다.
6. 지능형 라우팅 — 진정한 경제학
이 벤치마크는 암묵적인 질문을 제기합니다. "모든 것에 GLM 5.2가 필요할까?"
아니요, 그렇지 않습니다. 그리고 이것이 아마도 이 실험에서 얻을 수 있는 가장 유용한 결론일 겁니다.
토큰당 1.40달러의 GLM 5.2는 복잡성이 정당화될 때, 예를 들어 아키텍처 설계, 보안, 파일 간 일관성, 핵심적인 의사 결정에 적합한 선택입니다. 하지만 실제 프로젝트에서는 이런 작업들이 전체 상호작용의 극히 일부에 불과합니다. 나머지는 상투적인 코드(boilerplate), 사소한 수정, 문서화, 커밋 메시지 같은 작업들이죠.
세 가지 레벨, 세 가지 모델
BigPickle은 완전한 32개 파일 구현에서 15/25점을 받았습니다. 50줄의 diff를 읽고 적절한 커밋 메시지를 작성하거나, 1064 You have an error in your SQL syntax 또는 Fatal error: Call to undefined function과 같은 오류를 디버깅하는 데는 충분히 유능합니다. 기존 코드로 README를 생성하는 것도 잘 해냅니다. 이런 작업에는 GLM 5.2의 깊이 있는 아키텍처적 사고가 과잉이며, BigPickle은 무료로 제공됩니다.
토큰당 0.44달러의 DeepSeek V4 Pro는 Haiku 4.5보다 5배 저렴하고 GLM 5.2보다 3~4배 저렴합니다. 간단한 코드 생성, CRUD 작업, 사소한 리팩토링, 인라인 문서화, 짧은 스크립트 등을 무리 없이 처리합니다. 1.29M 토큰과 9분 42초에 0.24달러로 코드 구현 단계를 완료한 것이 이를 증명합니다.
GLM 5.2는 복잡성이 이 범위를 넘어설 때, 즉 아키텍처 설계, 일관된 다중 파일 구현, 보안 결정, 간단치 않은 비즈니스 로직 등이 필요할 때 사용됩니다.
| 레벨 | 모델 | 비용 | 일반적인 사용 사례 |
|---|---|---|---|
| 무료 | BigPickle | $0 | 디버그, 커밋 메시지, 간단한 질문, SQL 오류 |
| 저예산 | DeepSeek V4 Pro | $0.44/M | 상투적 코드, CRUD, 문서화, 짧은 스크립트 |
| 프리미엄 | GLM 5.2 | $1.40/M | 아키텍처, 보안, 다중 파일 일관성, 복잡한 비즈니스 로직 |
각 레벨의 작업 비중은 프로젝트, 개발 주기, 그리고 '복잡성'을 어떻게 정의하느냐에 따라 달라집니다. 보편적인 정답은 없으며, 각 팀은 실제 사용량에 맞춰 자체적으로 기준을 조절해야 합니다. 제 개인적인 경험으로는, 이런 지능형 라우팅은 작업 효율성을 극대화하고 비용을 절감하는 핵심 전략이 될 수 있습니다. 이는 제가 앞으로 AI 코딩 어시스턴트를 활용하는 방식에 대한 로드맵과도 같습니다.
“ 💡 주목할 점: GLM 5.2는 BigPickle보다 기하급수적으로 비쌉니다. 코드 구현 단계에서 4.42M 토큰에 1.67달러 대 0달러였으니까요. 하지만 순수 텍스트 출력(계획, 아키텍처, 분석)은 토큰 소비량이 적고 비용이 거의 들지 않습니다. 이 벤치마크의 기획 단계에서는 0.06달러에 불과했죠. 비용이 치솟는 것은 바로 코드 구현 단계에서 반복적인 작업, 세션 내 테스트 실행, 그리고 누적되는 컨텍스트 때문입니다. 지능형 라우팅은 GLM 5.2를 이런 긴 컨텍스트가 정당화되는 작업에 정확히 할당하고, 나머지는 두 하위 티어에 맡기는 것을 의미합니다. ”
불편한 진실: 경쟁 모델과의 비교
GitHub은 2026년 6월 1일부터 토큰 기반 요금제로 전환되었습니다. Copilot의 Claude Sonnet 4.6은 대략 입력 토큰당 3.00달러, 출력 토큰당 15.00달러로 청구됩니다. 이 벤치마크의 GLM 5.2 세션(4.46M 토큰)을 Copilot + Sonnet 4.6으로 재현했다면, 기능 테스트도, 자체 수정도, 외부 리뷰도 없이 약 25달러가 들었을 것으로 추정됩니다.
Copilot Pro+는 월 39달러에 39달러 상당의 AI 크레딧을 포함합니다. 이와 같은 전체 세션은 월 예산의 3분의 2를 소모할 것입니다. 실제로 사용자들은 요금제 전환 당일, 두 번의 프롬프트만으로 월별 크레딧을 모두 소진했다고 보고했습니다.
최종 비율을 보자면: 모든 것을 포함하여 1.94달러 대 Copilot + Sonnet 기준 약 25달러. 외부 리뷰어가 프로덕션 레벨로 판단한 유일한 결과물을 얻는 데 13배나 저렴했습니다.
결론
1.94달러. 기획부터 구현, 외부 리뷰까지 이 벤치마크에 소요된 총 비용입니다. 리뷰어가 프로덕션 레벨로 판단한 유일한 툴킷을 얻는 데 말이죠.
이 숫자는 '비쌀수록 품질이 좋다'는 암묵적인 가정을 통해 안심감을 파는 AI 코딩 도구 시장에 불편한 질문을 던집니다. 월 39달러의 Copilot Pro+, 출력 토큰당 15달러의 Claude Sonnet, 전면에 내세워지는 유명 모델들... 하지만 이 벤치마크는 그런 인식이 잘못되었음을 시사합니다.
승자는 GLM 5.2였습니다. 이 모델을 개발한 THUDM 연구실은 칭화대학교 소속입니다. 아마 지난주에 여러분이 보았던 비교 목록에는 없었을 겁니다. GLM 5.2는 기획 단계부터 정규화된 종료 코드 규칙을 가진 유일한 아키텍처를 제시했고, 세션 중에 자신의 코드를 테스트한 유일한 구현체를 내놓았습니다. 또한, jq가 없는 경우를 대비한 Python 폴백 기능과 구성 가능한 비밀 정보 가리기 기능을 갖춘 유일한 common.sh를 만들었습니다. 그리고 배포 전에 세 가지 버그를 스스로 수정하기까지 했습니다.
두 가지 핵심 요약을 드리자면 다음과 같습니다.
첫째: 모델의 가격이 복잡한 작업에서 그 결과물의 품질을 예측하지 못합니다. Haiku 4.5는 Claude Code, Copilot CLI, OpenCode 세 가지 다른 도구에서 동일한 비용으로 동일한 결과를 내놓았습니다. 피드백 루프나 코드베이스 탐색이 없는 순수 텍스트 생성인 기획 단계에서는 도구의 영향은 측정할 수 없었습니다. 중요한 것은 모델 자체였습니다. 그리고 이 벤치마크에서 가장 눈에 띄지 않던 모델이 압도적으로 우위를 점했습니다.
둘째: 모든 토큰이 똑같은 가치를 가지는 것은 아닙니다. 0.06달러의 기획 단계와 1.67달러의 코드 구현 단계는 28배의 차이를 보였습니다. 이는 예외가 아니라, 문제의 본질적인 구조입니다. 계획은 수천 개의 토큰으로 이루어진 추론입니다. 반면 구현은 누적된 컨텍스트, 실행된 코드, 반복된 테스트로 이루어진 수백만 개의 토큰을 의미합니다. 작업 복잡성에 따라 0달러의 BigPickle, 토큰당 0.44달러의 DeepSeek V4 Pro, 토큰당 1.40달러의 GLM 5.2 사이를 지능적으로 라우팅하는 것 — 이것이 바로 AI 코딩 도구의 진정한 경제학입니다.
VPS Manager 툴킷은 네 가지 버전 모두 GitHub에서 확인할 수 있습니다.
{% github https://github.com/pcescato/LLM-Challenge %}
요구사항, 프롬프트, 평가 기준도 함께 공개되어 있습니다. 여러분도 직접 검증하고 싶다면 재현 가능합니다.
"저렴해서 좋지 않을 것이다? 그것은 잘못된 질문이었습니다."
원문: https://dev.to/pascal_cescato_692b7a8a20/too-cheap-to-be-good-think-again-4nj0 수집일: 2026-06-24 00:21:17