13개의 프로그래밍 언어 전반에 걸쳐 Claude Code가 얼마나 효율적으로 코드를 생성하는지 비교하는 정량적 벤치마크 (Quantitative benchmark)입니다.

자세한 논의는 다음 블로그 포스트를 참조하세요: Which Programming Language Is Best for Claude Code? / 日本語版

최소한 프로토타이핑 (Prototyping) 규모의 작업에 있어서는 Ruby, Python, 그리고 JavaScript (TypeScript 제외)가 Claude Code에 가장 적합한 것으로 보입니다. 가장 빠르고, 저렴하며, 안정적입니다.

"정적 타이핑 (Static typing)이 AI 환각 (Hallucination) 버그를 방지한다!" 대 "동적 타이핑 (Dynamic typing)이 토큰 (Tokens)을 절약한다!" — 정성적인 논쟁은 풍부하지만, 정량적인 데이터는 부족합니다. 이 실험은 그 간극을 메우는 것을 목표로 합니다.

우리는 Claude Code (Opus 4.6)에게 다양한 프로그래밍 언어로 Git의 단순화 버전인 mini-git을 구현하도록 요청하였고, 각 언어별 소요 시간, 비용, 그리고 코드 라인 수 (Lines of code)를 측정했습니다.

작업은 두 단계로 나뉩니다:

v1 (새 프로젝트): init, add, commit, log 구현.
v2 (기능 확장): status, diff, checkout, reset, rm, show 추가.

프롬프트는 단순히 다음과 같습니다: "SPEC-v1.txt를 읽고, 이를 구현하며, test-v1.sh가 통과하는지 확인하세요." v2도 이와 유사합니다.

카테고리	언어
동적 (Dynamic)	Python, Ruby, JavaScript, Perl, Lua
...

Python/mypy는 mypy --strict로 검증되는 완전한 타입 어노테이션 (Type-annotated)이 포함된 Python 코드를 작성합니다. Ruby/Steep은 steep check로 검증되는 RBS 타입 시그니처 (Type signatures)를 작성합니다. 이를 통해 동일한 언어 내에서 타입 체크 오버헤드 (Type-checking overhead)를 직접 비교할 수 있습니다.

각 언어는 20회씩 실행되었습니다. 라이브러리 의존성에 따른 변동을 피하기 위해 커스텀 해시 알고리즘 (SHA-256 아님)을 사용했습니다.

| 언어 | 테스트 통과 (v1+v2) | 시간 (v1+v2) | 평균 비용 | LOC (v2) |
|---|---|---|---|
| Ruby | 40/40 | 73.1s ± 4.2s | $0.36 | 219 |
| ... |

총 600회의 실행 (15개 구성 × 2개 단계 × 20회 시행) 중 단 3회만 실패했습니다: Rust (2회) 및 Haskell (1회).

Ruby, Python, JavaScript가 상위 3위입니다 — 빠르고 (73–81초), 저렴하며 ($0.36–0.39), 안정적입니다 (낮은 표준편차). 4위부터는 분산 (Variance)이 급격히 증가합니다.

시간과 비용은 강한 상관관계가 있습니다:

OCaml (216), Ruby (219), Haskell (224)이 가장 압축적입니다. C는 517행으로 눈에 띄게 많습니다. 주목할 점은 코드 라인 수 (LOC)가 적다고 해서 반드시 더 빠르거나 저렴한 생성 (Generation)을 의미하지는 않는다는 것입니다. OCaml과 Haskell은 압축적이지만 속도는 중간에서 낮은 수준입니다.

Python (32.9s)과 Ruby (33.2s)가 앞서고 있으며, JavaScript (36.0s)가 그 뒤를 잇습니다. Ruby/Steep은 105.0s가 소요되어 일반 Ruby보다 3.2배 느립니다. v1은 빈 디렉토리에서 시작하므로, 프로젝트 설정 파일 (Cargo.toml, package.json 등)이 필요한 언어들은 추가적인 오버헤드 (Overhead)가 발생합니다.

v2에서는 격차가 줄어듭니다. 상위 3개는 Ruby (40.0s), Python (41.8s), JavaScript (45.1s)로 유지됩니다. Perl (45.7s), OCaml (47.1s), Lua (47.2s)가 그 뒤를 바짝 쫓고 있습니다. Haskell은 가장 적은 LOC를 가졌음에도 불구하고 99.6s로 가장 느립니다.

타입 검사기 (Type-checker) 오버헤드: Python/mypy는 Python보다 1.61.7배 느리며, Ruby/Steep은 Ruby보다 2.03.2배 느립니다.

저자는 Ruby 커미터 (Committer)이므로, 해석을 받아들일 때 어느 정도 주의가 필요합니다. 데이터와 코드는 이 저장소 (Repository)에서 확인할 수 있으니, 의구심이 든다면 직접 검증해 보시기 바랍니다.

단일 요인만으로 결과를 설명할 수는 없습니다. 가능성 있는 기여 요인은 다음과 같습니다:

타입 시스템 (Type system): 이 벤치마크에서 동적 언어 (Dynamic languages)는 일관되게 더 빠르고 안정적입니다.
간결성 (Conciseness): 코드가 짧을수록 일반적으로 생성 속도가 빠르지만, OCaml/Haskell은 압축적임에도 불구하고 느립니다 (높은 사고 토큰 (Thinking-token) 사용).
절차적 vs 함수형 (Procedural vs functional): 상위 3개를 제외하면 절차적 언어와 함수형 언어 사이에 큰 격차는 없습니다. OCaml은 특히 v2에서 47.1s를 기록하며 JavaScript와 경쟁할 만한 성능을 보였습니다.
언어 난이도 (Language difficulty): C의 메모리 관리 (Memory management), Rust의 소유권 모델 (Ownership model), Haskell의 모나드 (Monads)/순수성 (Purity) 등은 AI에게 오버헤드를 추가할 수 있습니다.
AI 친숙도 (AI familiarity): Python/Ruby/JavaScript는 학습 데이터 (Training data)가 더 많이 존재할 가능성이 높습니다. Ruby/Steep이 Python/mypy에 비해 더 큰 오버헤드를 보이는 것은 Steep에 대한 AI의 친숙도가 낮음을 반영할 수 있습니다.

가능성 있는 시나리오는 — 테스트는 통과하지만, 테스트되지 않은 경로에서 타입 오류 (Type errors)가 발생할 수 있다는 점입니다. 그럼에도 불구하고, 600번의 실행 중 유일한 실패는 Rust와 Haskell(둘 다 정적 타입 언어이며, 둘 다 상대적으로 "어려운" 언어임)에서 발생했습니다.

개인적으로는 그렇습니다. 반복적인 개발 과정("프롬프트(prompt) → 대기 → 생각 → 프롬프트")에서, 30초와 60초의 차이는 흐름(flow)과 집중력에 상당한 영향을 미친다고 생각합니다.

네 — 정적 타이핑(static typing)은 더 큰 규모에서 빛을 발할 수 있습니다. 공정한 대규모 교차 언어 벤치마크(cross-language benchmark)가 수행된다면 가치 있을 것입니다. 기여를 환영합니다.

실제 프로젝트에서는 프레임워크의 가용성이 중요하며 — 만약 런타임 속도(runtime speed)가 필수적이라면, 컴파일 언어(compiled language)가 더 나은 선택일 수 있습니다. 이 벤치마크는 언어 수준의 차이를 격리하기 위해 의도적으로 외부 라이브러리를 피했습니다(SHA-256 대신 커스텀 해시 사용).

ruby benchmark.rb # 모든 언어 × 3회 실행
ruby benchmark.rb --lang python --trials 1 # 단일 언어 빠른 테스트
ruby report.rb # 결과/report.md 생성
...

요구 사항: Ruby, Claude Code CLI (claude), 그리고 대상 언어의 툴체인(toolchains).

main 브랜치: 벤치마크 도구, 사양(specs), 테스트, 결과 및 도표

data 브랜치(orphan): 검증을 위해 생성된 소스 코드 및 Claude JSON 로그

적어도 프로토타이핑 규모의 작업에 있어서는 Ruby, Python, 그리고 JavaScript(TypeScript 아님)가 Claude Code에 가장 적합한 것으로 보입니다.

정적 타이핑은 더 큰 규모에서 유리해질 수 있습니다 — 누군가 이를 테스트해 보아야 합니다.

전형적인 전략 — 즉, 동적 언어(dynamic language)로 시작하여 프로젝트가 성숙함에 따라 정적 언어로 마이그레이션(migrate)하는 방식 — 이 여전히 올바른 선택일 수 있습니다. 코딩 에이전트(coding agents)는 언어 간 마이그레이션에 매우 능숙해 보이므로(검증 필요), 이는 점점 더 현실적인 옵션이 되고 있습니다.

• 2026년 3월에 평가되었습니다. AI 발전 속도를 고려할 때, 몇 달 후에는 결과가 다르게 보일 수 있습니다.
• 이 실험은 Claude for Open Source Program의 지원을 받았습니다. 6개월간의 무료 Claude Max 20x를 제공해 준 Anthropic에 감사드립니다!