Too cheap to be good? Think again.
I replaced aaPanel/OpenLiteSpeed with Caddy and shell scripts and turned the process into a benchmark. Two phases (architecture then code), one external code review. The winning model? Not the one you'd expect.
개요 #
비싼 AI 코딩 도구가 더 좋은 결과를 낸다는 통념을 실제 프로젝트로 검증한 벤치마크가 나왔다. 결론부터 말하면, 끝까지 프로덕션에 바로 투입할 만하다고 평가받은 유일한 결과물은 가장 비싼 모델도, 가장 유명한 모델도 아니었다.
저자는 자신의 VPS 운영 환경을 갈아엎는 실제 작업을 벤치마크로 만들었다. aaPanel과 OpenLiteSpeed를 Caddy와 잘 짜인 셸 스크립트로 대체하는 과제를, 8개의 도구/모델 조합에 똑같이 던졌다. 설계 단계와 구현 단계를 나눴고, 마지막엔 벤치마크에 참여하지 않은 외부 모델에게 코드 리뷰를 맡겨 점수를 매겼다.
전체 비용은 기획·구현·외부 리뷰를 다 합쳐 1.94달러. 그리고 우승 모델은 평소 비교 기사에서 보기 힘든 이름이었다.
왜 실제 프로젝트였나 #
벤치마크의 출발점은 저자의 운영 환경 교체였다. 오랫동안 WordPress 사이트를 OpenLiteSpeed에서 돌렸지만, 컨트롤 패널 쪽에서 계속 발목을 잡혔다. CyberPanel은 무료 기능이 버전이 올라갈수록 멀쩡히 되던 동작마저 막혔고, 같은 기능의 유료 버전이 늘 따라붙었다. 그래서 aaPanel로 옮겼지만 이번엔 OLS를 직접 건드릴 수 없는 추상화 계층에 갇혔다. 7080 포트를 손대면 전체가 깨질 위험이 있었다.
작업 환경도 바뀌었다. Astro 기반의 준정적 사이트가 늘면서 PHP가 필요 없는 프로젝트가 많아졌고, 그만큼 OLS의 매력은 사라졌다. Caddy는 HTTPS를 자동으로 처리하고 설정도 몇 줄이면 끝난다.
결론은 단순했다. 잘 짜인 셸 스크립트와 최소한의 FastAPI 인터페이스면 충분하고, 유지보수도 훨씬 쉽다. 누군가 그걸 써주기만 하면 됐다. 저자는 직접 짜는 대신 여러 AI 코딩 도구에 명세를 넘기기로 했고, 아예 벤치마크로 만들었다.
테스트 프로젝트 #
과제는 일부러 구체적으로 잡았다. Ubuntu 24.04용 최소 VPS 관리 툴킷이다. 웹 서버는 Caddy, PHP-FPM은 현행과 폴백 두 버전, 데이터베이스는 MariaDB와 PostgreSQL, 객체 캐시는 Valkey. 모든 작업은 셸 스크립트로, 자동화는 FastAPI 인터페이스로 처리한다. Docker도, 컨트롤 패널도, 불필요한 추상화도 없다.
다뤄야 할 사이트 유형은 네 가지다. 정적 사이트(HTML/에셋만), PHP 앱(DB 선택), WordPress(WP-CLI 전체 설치, DB 필수), 그리고 리버스 프록시. 마지막 유형은 같은 서버에서 도는 Node.js·FastAPI·Go 앱으로 요청을 넘기는 Caddy vhost일 뿐이다. HTTPS와 도메인은 Caddy가 맡고, 애플리케이션은 신경 쓸 게 없다.
기대하는 동작은 서버 부트스트랩, 사이트 프로비저닝, 삭제 전 자동 백업, 온디맨드 DB 생성, rsync 정적 배포, 백업, 서비스 관리까지 운영 전 주기를 아우른다. 합성 벤치마크가 이상적인 조건에서 모델이 무엇을 할 수 있는지 본다면, 실제 프로젝트는 제약이 겹겹이 쌓일 때 모델이 무엇을 하는지 본다. 보안, 멱등성, 파일 간 일관성, 셸과 파이썬 계층 사이의 오류 처리 — 차이는 바로 거기서 갈린다.
방법론 #
프로토콜은 사람이 끼어드는 검증을 사이에 두고 두 단계로 나뉜다.
1단계 — 설계. 동일한 기능 명세를 각 조합에 던진다. 추가 컨텍스트도, 설정 파일도, 정답에 대한 힌트도 없다. 도구는 아키텍처와 프로젝트 구조, 스크립트 목록과 책임, API 라우트 맵을 제안한다. 설계가 제대로 됐다면 결과물을 내놓기 전에 질문을 던진다.
2단계 — 구현. 계획이 확정되면 동일한 개발 프롬프트를 모든 도구에 던진다. 확정된 아키텍처, 열 개의 기술 결정, 스크립트→API 종료 코드 규약, 그리고 명확한 지시 하나가 들어간다. 파일 30개를 디스크에 순서대로 작성하라, 요약도 생략도 없이.
테스트한 조합은 다음과 같다.
| 도구 | 모델 |
|---|---|
| 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 |
Haiku 4.5가 서로 다른 세 도구에 세 번 등장하는 건 의도된 설계다. 모델과 무관하게 도구 자체의 영향을 분리해내기 위해서다. 코드 단계는 대표 구현 네 개를 골라 진행했고, 5장 공개 전까지는 A·B·C·D로만 부른다.
설계 단계 — 누가 실제로 생각하는가 #
가장 먼저 눈에 띄는 건, 어떤 모델도 계획을 내놓기 전에 질문하지 않았다는 점이다. 단 하나도. 모두 완성된 아키텍처를 먼저 던지고 마지막에 가서야 확인을 구했다. 모호한 지점에서 멈춰 서서 먼저 묻는 사람 아키텍트와는 정반대다.
이게 왜 중요한가. 나중에 던진 질문 중에는 처음에 물었다면 설계 결정을 바꿨을 만한 것들이 있었다. 한 모델은 "디스크에 비밀값을 두지 않는다"는 원칙과, 자격 증명이 정당하게 필요한 애플리케이션 설정 파일(대표적으로 wp-config.php) 사이의 긴장을 짚어냈다. 진짜로 막아 세워야 할 질문인데, 계획 뒤에 붙으니 각주가 돼버렸다.
질문의 질이 첫 번째 변별 신호였다. 두 모델은 옵션과 권고까지 곁들여 진짜 핵심 질문 네다섯 개를 던졌다. 다른 모델은 아카이브 포맷, 로그 로테이션 같은 일반론적 질문 여덟 개를 던졌는데, 아키텍처를 바꿀 만한 건 하나도 없었다.
제안한 구조는 두 번째 신호였다. 오직 한 모델만이 스크립트로 분기하는 통합 CLI 진입점 bin/vpsmgr를 자발적으로 제안했다. 스크립트 묶음을 하나의 일관된 도구로 만드는 디테일이다. 같은 모델은 설계 단계부터 정규화된 종료 코드 규약을 문서화해 내놓은 유일한 모델이기도 했다.
| 코드 | 의미 | HTTP |
|---|---|---|
| 0 | 성공 | 200 |
| 1 | 잘못된 입력 | 400 |
| 2 | 찾을 수 없음 | 404 |
| 3 | 충돌 | 409 |
| 4 | 의존성 누락 | 422 |
| 5 | 내부 오류 | 500 |
이건 장식이 아니다. 셸 스크립트와 FastAPI 계층 사이의 계약이다. 이게 없으면 HTTP 매핑이 제멋대로가 되고, 라우트마다 다르게 구현된다.
설계 단계 비용을 보면 토큰 양이 품질을 예측하지 못한다는 게 드러난다. Gemini 3.1 Pro는 27k 토큰으로 가장 간결한 양질의 계획을 냈고, OpenCode의 Haiku 4.5는 69k 토큰을 쓰고도 더 낮은 품질을 냈다.
코드 단계 — 누가 실제로 내놓는가 #
코드 단계의 차이는 공유 라이브러리 common.sh에서 가장 선명하게 드러난다. 모든 스크립트가 source하는 토대라, 여기가 부실하면 전부 오염된다.
- 모델 A — 98줄. 비밀값 마스킹이 WordPress 패턴 열 개(솔트, 인증 키)를 명시적으로 모두 덮는다. 다만 도메인 검증,
require_cmd(), 원자적 상태 파일 쓰기가 없다. - 모델 B — 310줄.
readonly상수, RFC-1035 정규식의normalize_domain(), 동시성 락,mktemp+mv원자적 쓰기까지. 시스템 유틸리티 라이브러리가 가장 풍부하다. 하지만 비밀값 마스킹이 WordPress 솔트를 놓쳤다. - 모델 C — 366줄. 마스킹 패턴을 환경 변수로 설정 가능하게 했고,
jq가 없을 때 파이썬으로 폴백하는 순수 셸 JSON 헬퍼를 갖췄다. 모호한 문자(0/O/1/l/I)를 뺀 비밀번호 생성까지. 개발 프롬프트에 문서화된 엣지 케이스를 전부 예측한 유일한 구현이다. - 모델 D — 184줄. 종료 코드를
exit_input_error(),exit_conflict()같은 명명 함수로 감싼 발상이 돋보인다. 다만 원자적 쓰기와require_cmd()가 없다.
결정적 차이는 스스로 버그를 잡느냐에서 갈렸다. 모델 C는 세션 중에 자기 코드를 직접 돌렸다. schemas.py를 쓴 뒤 테스트 케이스로 실행해 버그 두 개(Pydantic v2 검증기 오용, 스키마 수준 상호 배제 누락)를 찾아 바로 고쳤고, render_template()의 sed 치환 문제(경로의 /에서 깨짐)도 순수 bash 파라미터 확장으로 교체했다. 세션 끝에는 검증 요약까지 내놨다 — 전 스크립트 bash -n, 전 파일 Python AST, API 라우트 19/19, bash 헬퍼 18/18 확인. 나머지 셋은 문법 검사 정도에 그쳤고, 기능 로직을 테스트한 모델은 없었다.
비용 면에서 모델 D는 9분 42초 만에 끝낸 일을 모델 C는 23분 37초에 걸쳐 했지만, 그 대신 기능 테스트가 없었다. 모델 C가 토큰을 3.4배 더 쓴 건 세션 중 코드를 실행하며 매 반복마다 컨텍스트를 다시 불러왔기 때문이다.
외부 리뷰, 그리고 정체 공개 #
판정은 벤치마크에 참여하지 않은 모델에게 맡겼다. 구현마다 대표 파일 다섯 개(common.sh, site-create.sh, site-delete.sh, backup.sh, api/runner.py)를 보안·정확성·멱등성·코드 품질·완성도 다섯 기준, 25점 만점으로 채점했다. 리뷰 비용은 543k 토큰에 0.0766달러. 주니어 개발자 한 시간 인건비의 10분의 1이다.
파일별 지적이 날카로웠다. site-create.sh에서 리뷰어는 모델 D의 조용한 버그를 찾아냈다 — SFTP 비밀번호를 생성하고도 호출자에게 반환하지 않아 사용자가 자격 증명을 영영 못 본다. 오류 메시지도 없이 핵심 기능이 깨진 것이다. 모델 B는 함수 밖에서 local을 써 런타임 실패를 부르는 bash 오류가 세 군데 있었다. backup.sh에서 모델 A와 B는 eval "$POST_HOOK"로 명령 주입 위험을 안았고, 모델 C는 아카이브 경로를 인자로 넘겨 더 안전했다.
| 기준 | 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뿐이었다. 그리고 정체는 이랬다.
| 별칭 | 모델 | 도구 | 총비용 |
|---|---|---|---|
| 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 버그로 배포 불가였다. 우승은 칭화대 THUDM 연구소의 GLM 5.2. 25점 만점에, 리뷰어가 프로덕션 투입 가능하다고 판단한 유일한 결과물이었고, 비용은 1.73달러였다.
추가 검증 — 리뷰어를 늘려보다 #
단일 리뷰어가 편향을 부른다는 댓글 지적에 따라, 같은 프로토콜로 GPT-5.3 Codex와 Gemini 3.1 Pro Preview를 추가했다.
| 모델 | Qwen 3.7 Plus | GPT Codex | Gemini 3.1 Pro | 프로덕션 가능 |
|---|---|---|---|---|
| A (BigPickle) | 15/25 | 13/25 | 11/25 | 아니오 (3/3) |
| B (Claude + Haiku) | 12/25 | 12/25 | 18/25 | 아니오 (3/3) |
| C (GLM 5.2) | 25/25 | 17/25 | 25/25 | 예 (2/3) |
| D (DeepSeek V4 Pro) | 12/25 | 14/25 | 14/25 | 아니오 (3/3) |
| E (Kimi K2.7) | 19/25 | 13/25 | 21/25 | 조건부 (1/3) |
순위 C > E > D > A > B는 세 리뷰어 모두에서 동일하게 유지됐다. GLM 5.2는 두 독립 리뷰어에게서 25점 만점을 받은 유일한 모델이었다. 가장 엄격했던 GPT Codex는 GLM 5.2조차 17/25로 매기며 site-create.sh의 인자 파싱 버그와 common.sh의 set -euo pipefail 누락을 짚었는데, 모두 실재하는 문제다. 단일 리뷰어는 편향을 낳지만, 세 독립 리뷰어가 같은 순위로 수렴한 결과는 개별 점수보다 훨씬 강한 근거다.
정작 중요한 건 라우팅의 경제학 #
이 벤치마크가 던지는 질문은 이거다. 모든 작업에 GLM 5.2가 필요할까? 아니다. 그리고 그게 아마 가장 쓸모 있는 결론이다.
GLM 5.2(토큰당 $1.40/M)는 복잡도가 그 값을 정당화할 때 — 아키텍처, 보안, 파일 간 일관성, 중요한 결정 — 옳은 선택이다. 하지만 실제 프로젝트에서 그런 작업은 일부에 불과하다. 나머지는 보일러플레이트, 사소한 수정, 문서, 커밋 메시지다.
| 등급 | 모델 | 비용 | 전형적 용도 |
|---|---|---|---|
| 무료 | BigPickle | $0 | 디버그, 커밋, 간단한 질문, SQL 오류 |
| 저가 | DeepSeek V4 Pro | $0.44/M | 보일러플레이트, CRUD, 문서, 짧은 스크립트 |
| 프리미엄 | GLM 5.2 | $1.40/M | 아키텍처, 보안, 다중 파일 일관성 |
불편한 비교도 있다. GitHub는 2026년 6월 1일 토큰 과금으로 전환했다. Copilot의 Claude Sonnet 4.6은 입력 약 $3.00/M, 출력 $15.00/M 수준이다. 이 벤치마크의 GLM 5.2 세션(4.46M 토큰)을 Copilot + Sonnet 4.6으로 재현하면 약 25달러로 추산된다. 기능 테스트도, 자기 교정도, 외부 리뷰도 없이 말이다. 최종 비율은 전부 합쳐 $1.94 대 약 $25, 13배 차이다. 그것도 외부 리뷰어가 프로덕션 가능하다고 판단한 유일한 결과물에 대해서.
정리하며 #
이 벤치마크의 전체 비용은 1.94달러였다. 기획, 구현, 외부 리뷰까지 포함해서. 그리고 프로덕션에 바로 쓸 만하다고 평가받은 유일한 툴킷에 대해서.
여기서 두 가지를 건진다. 첫째, 모델의 가격은 복잡한 작업에서의 출력 품질을 예측하지 못한다. Haiku 4.5는 세 도구에서 같은 비용에 같은 결과를 냈고, 피드백 루프가 없는 설계 단계에서는 도구의 영향이 측정되지 않았다. 중요한 건 모델이었고, 벤치마크에서 가장 화려하지 않은 모델이 압도했다.
둘째, 모든 토큰이 같지 않다. 설계 단계는 0.06달러, 코드 단계는 1.67달러 — 28배 차이다. 이건 이상 현상이 아니라 문제의 구조다. 계획은 수천 토큰의 추론이고, 구현은 누적 컨텍스트와 실행된 코드, 반복 테스트로 쌓인 수백만 토큰이다. BigPickle($0), DeepSeek V4 Pro($0.44/M), GLM 5.2($1.40/M)를 작업 복잡도에 따라 영리하게 나눠 쓰는 것 — 그게 이 도구들의 진짜 경제학이다.
네 가지 버전의 VPS Manager 툴킷과 명세, 프롬프트, 평가 기준은 모두 GitHub 저장소에 공개돼 있다. 검증하고 싶다면 재현할 수 있다.
싸면 별로일 거라고? 그게 잘못된 질문이었다.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.