LLM 코딩 에이전트에 가장 적합한 프로그래밍 언어는 무엇인가? 실증적 평가

TL;DR

실증적 평가 결과, LLM 코딩 에이전트에 대해 단일 언어가 항상 다른 언어를 능가한다는 주장은 입증되지 않았으며, 동적 언어가 보편적으로 토큰 효율성이 높다는 주장도 지지되지 않는다.

배경: 토큰 효율성 주장

널리 인용되는 글은 동적 또는 간결한 언어가 명시적인 타입 선언을 생략하기 때문에 LLM 토큰 사용량이 적다고 주장한다. 이 글은 C(가장 비효율적)와 클로저(Clojure, 가장 효율적) 사이에 2.6배의 토큰 효율성 격차가 있으며, J 언어는 평균 70 토큰, 클로저는 109 토큰을 사용한다고 언급한다. 구글의 AI 요약도 이 주장을 반복한다:

"동적 타입 언어는 전통적인 정적 타입 언어보다 일반적으로 LLM 토큰 비용이 낮다. 명시적인 타입 선언을 생략하면 코드가 더 컴팩트해지기 때문이다."

이 주장은 여러 블로그 글과 논문에서 반복되었지만, 기반 실험에는 심각한 방법론적 결함이 있다.

원본 벤치마크가 신뢰할 수 없는 이유

단순한 문제 세트

원본 벤치마크는 로세타 코딩(Rosetta-Code) 문제를 사용했는데, 이 문제들은 70~109 토큰 내에서 해결할 수 있다. 이러한 매우 작은 프로그램은 거의 알고리즘 작업이 없으며, 대부분의 토큰은 부가적인 코드와 출력에 소비된다.
문제 크기가 커지면 토큰 효율성 격차는 사라진다. 이는 이전의 "동굴인 모드" 평가와 유사하며, 단순한 작업이 언어 간 차이를 과장했다.

ai-coding-lang-bench 저장소의 평가 결함

잘못된 실행 경로로 인해 루스트(Rust)가 실패한 것으로 보였지만, 올바른 바이너리로 재평가한 결과 루스트는 완벽한 점수를 받았다.
테스트 허니스 버그(예: 두 가지 브랜치 모두 pass를 포함하는 if 문)로 인해 에이전트가 테스트에 특화된 동작을 하드코딩할 수 있었다.
환경 조작 가능성: 에이전트가 테스트 파일을 심볼릭 링크로 연결하거나 수정할 수 있어, 후속 실행에서 잘못된 프로그램이 실행될 수 있었다.
일관되지 않은 툴체인(예: 오래된 Zig, 루스트용 rustfmt 누락)으로 인해 인위적인 불리함이 발생했다.

이러한 문제들로 인해 보고된 정적 대비 동적 언어의 격차는 신뢰할 수 없다.

저자가 수행한 새로운 평가

저자는 두 가지 더 크고 현실적인 벤치마크를 수행했다:

Zstd 디코더 – 인터넷 없이 Zstd RFC 전체를 구현하고 숨겨진 테스트 세트를 실행한다.
Pandoc ProgramBench – Pandoc의 일부를 구현하고 보류된 테스트 세트로 평가한다.

두 벤치마크 모두 x축에 비용(토큰), y축에 정확도 점수를 측정했으며, 선택적으로 시간 축을 전환할 수 있다.

Zstd 결과

중간 노력 수준에서 동적 언어는 정적 언어보다 약간 왼쪽에 집중되어 있어, 소량의 토큰 절약을 시사한다.
초고도 노력 수준에서는 이 우위가 사라졌으며, 여러 정적 언어(예: 루스트, Go)가 최고 성능을 기록했다.
매우 밀도 높은 언어(J)는 우세하지 않았으며, 그 이점은 완전히 사라졌다.
언어의 인기도는 정확도와 낮은 비용과 양의 상관관계를 보였으며, 더 널리 사용되는 언어는 더 큰 학습 데이터에 노출되어 있다는 것을 시사한다.

Pandoc 결과

정적 대비 동적 언어의 명확한 분할은 나타나지 않았다. 동적 언어가 항상 저렴하거나 더 정확한 것은 아니었다.
낯선 언어(예: J, Factor)는 성능이 낮았고, 주류 언어(파이썬, Go, 루스트)는 차트의 중상위권을 차지했다.
어셈블리는 예상대로 가장 낮은 성능을 보였으며, 저수준 코드를 작성하는 데 필요한 높은 인간 노력이 원인이다.

종합적 통찰

토큰 효율성 차이는 작고 작업에 따라 달라진다. 단순한 벤치마크에서 보인 극단적인 비율은 현실적인 작업에서는 사라진다.
인기도가 중요하다. 인기 있는 언어는 일반적으로 더 높은 정확도와 낮은 비용을 달성하며, LLM이 사전 훈련 중 더 많은 코드를 접했기 때문일 것이다.
희귀하고 밀도 높은 언어는 일반 사용자에게 실용적인 이점을 제공하지 않는다. 특수 언어용 모델을 훈련하거나 미세 조정하는 데 드는 노력은 소량의 토큰 절약보다 크다.

허커 뉴스 댓글에서 얻은 커뮤니티 통찰

"우리 결과에서는 어떤 모델(그림 5b)에 대해서도 언어 간 해결률 차이가 거의 보이지 않았다. 이는 AI 모델이 문법 패턴 매칭이 아닌 일반화된 프로그래밍 능력을 학습했음을 시사한다." – MirrorCode 논문 (파이썬, C, 루스트, Go, OCaml, 아다)【tadamcz】

"Go는 LLM에게 훌륭한 선택이다. 왜냐하면 대부분의 작업을 단일하고 일관된 방식으로 수행할 수 있고, 컴파일 시간 피드백이 빠르기 때문이다." – michaelteter【michaelteter】

"컴파일된, 강력한 타입, 불변 언어(예: Gleam, Lustre)는 훈련 데이터가 적어도 놀라울 정도로 잘 작동한다." – MichaelNolan【MichaelNolan】

"정적 타입은 빠른 검증 루프를 제공하지만, 현대 추론 기술을 사용하면 타입 주석의 토큰 오버헤드는 최소화될 수 있다." – jillesvangurp【jillesvangurp】

"실제로 중요한 요소는 언어 자체가 아니라 도구와 생태계이다. 빠른 빌드, 좋은 린팅, 신뢰할 수 있는 테스트 허니스는 LLM이 수행해야 하는 수정 루프 수를 줄인다." – jillesvangurp

"에이전트가 테스트 환경을 수정할 수 있다면 사기할 수 있으므로, 신뢰할 수 있는 평가를 위해서는 보류된 테스트가 필수적이다." – gr_norm【gr_norm】

이 댓글들은 두 가지 주제를 강화한다:

현대 LLM의 일반화된 프로그래밍 능력은 언어별 우위를 줄인다.
도구와 생태계(빠른 컴파일, 신뢰할 수 있는 린터, 표준 라이브러리)는 정적 대비 동적 언어의 이분법보다 전체 비용에 더 큰 영향을 미친다.

실무자들을 위한 실용적 권고

결정 요소	권고
주요 목표 – 토큰 비용	인기 있고 간결한 언어(파이썬, 자바스크립트/타입스크립트, Go)를 선택하라. 희귀하고 밀도 높은 언어의 토큰 절약은 실제 작업에서는 무시할 수 있다.
주요 목표 – 정확도/안전성	정적 타입 언어 중 강력한 컴파일러를 갖춘 언어(루스트, Go, 코틀린, 스위프트)를 선호하라. 컴파일 타임 검사로 수정 루프 수를 줄여 장기적으로 벽시계 시간과 토큰을 절약할 수 있다.
도구 가용성	빠른 빌드 주기와 통합 린터(Go의 `go test`, 루스트의 `cargo check`)를 갖춘 언어를 사용하라. 빠른 피드백 루프는 타입 주석의 토큰 오버헤드를 상회한다.
팀 전문성	인간 개발자의 익숙함이 선택을 주도하도록 하라. LLM은 어떤 언어에도 적응할 수 있지만, 최종 코드는 사람들이 유지보수할 수 있어야 한다.
희귀/도메인 전용 언어	충분한 토큰 예산이 있고 도메인이 진정으로 이점을 얻는 경우(예: 하드웨어 설명, 형식적 검증)에만 고려하라.
평가 방법론	언어 성능을 측정할 때는 비단순한 작업, 보류된 테스트 세트, 다양한 노력 수준(중간 대비 초고도)을 사용하라. 단일 작업, 장난스러운 문제 벤치마크는 피하라.

제한점과 미해결 질문

평가 대상은 Zstd와 Pandoc 두 가지 작업에 국한되었다. 웹 서비스, 데이터 파이프라인, 임베디드 시스템 등 더 다양한 작업 부하가 다른 패턴을 드러낼 수 있다.
프레임워크와 라이브러리의 영향은 분리되지 않았다. 풍부한 표준 라이브러리를 갖춘 언어는 핵심 언어가 길더라도 토큰 사용량을 줄일 수 있다.
메모리 안전성 차이(Rust vs. C)는 암시되었지만 완전히 측정되지 않았다. 향후 연구는 퍼즈 테스트나 세이니타이저를 점수에 통합할 수 있다.
에이전트 측 도구(예: 정적 분석, 속성 기반 테스트)가 전체 비용에 미치는 영향은 여전히 연구 과제이다.

결론

정적 언어 대비 동적 언어가 LLM 코딩 에이전트에 대해 분명히 더 토큰 효율적이라는 주장은 강력하고 비단순한 평가에 의해 지지되지 않는다. 현실적인 작업에서는 정적 언어와 동적 언어의 토큰 비용이 유사하며, 정적 언어는 컴파일 타임 검사로 인해 정확도와 안전성 측면에서 종종 우위를 점한다. 인기도와 도구 품질이 성공의 가장 강력한 예측 요소이다. 따라서 LLM 지원 코딩 프로젝트에 가장 적합한 언어는 정적 대비 동적 특성보다 개발자 익숙함, 도구 속도, 프로젝트 요구사항을 균형 있게 고려한 언어이다.

감사의 말

Max Bittker, Yossi Kreinen, Aaron Levin, Alan Boll, Luke Burton, Marco Primi, Milosz Danczak, Justin Blank에게 의견과 수정에 감사드립니다.

모든 인용된 댓글은 원문 그대로 재현되었으며, 원본 HN 사용자에게 귀속된다.