프로그래밍 언어가 코딩 에이전트의 토큰 효율과 정확성에 미치는 영향

Zstd와 Pandoc 구현 평가에서는 동적 언어가 정적 언어보다 토큰 효율적이라는 기존의 강한 관계가 재현되지 않았으며, 과제와 추론 노력 수준에 따라 정확도·비용·시간 순위가 달라짐 70~109토큰으로 풀리는 Rosetta Code 같은 소형 문제는 실제 작업으로 일반화하기 어렵고, 경로 오류·잘못된 테스트·에이전트 개입도 언어별 결과를 쉽게 왜곡함 GPT-5.6 Sol의 medium·ultra 조건에서는 주류 언어가 대체로 유리했고, J 같은 희소·고밀도 언어의 우위는 나타나지 않았으며 언어 인기도와 정확도·비용 사이에 약하거나 중간 정도의 관계가 관찰됨 Clojure의 byte 변환 오류와 C·C++의 메모리 안전성 문제처럼 언어별 특이 실패가 점수를 크게 좌우하므로, 테스트 범위와 수정 비용까지 함께 봐야 실질적인 장단점을 판단할 수 있음 두 과제만으로 최선의 언어를 가릴 수는 없지만, 동적·정적 타입 분류만으로 LLM 코딩 성능을 예측한다는 강한 주장은 반박할 수 있으며 신뢰할 결론에는 다양한 현실적 과제와 엄격한 평가 검증이 필요함 기존 토큰 효율 평가의 주장과 한계 널리 인용되는 언어별 토큰 효율 비교는 간결한 동적 언어가 Rust·Go·C++ 같은 정적 언어보다 토큰을 절반에서 3분의 1 정도만 사용할 수 있다고 봄 비교에서는 C와 Clojure 사이에 2.6배 격차가 있었음 추가 실험에서는 J가 평균 70토큰으로 Clojure의 109토큰보다 적었으며, 배열 언어가 토큰 효율에 유리할 수 있다는 해석이 뒤따름 ai-coding-lang-bench도 동적 언어가 유리하다는 비슷한 결론을 냈음 첫 비교에 사용된 Rosetta Code 문제는 J 70토큰, Clojure 109토큰으로 해결될 만큼 작아 실제 구현 작업을 대표하기 어려움 caveman mode 평가 비교에서도 출력 몇 줄이 작업의 대부분인 문제에서 나타난 큰 이득이 조금 더 현실적인 문제에서는 사라졌음 사소한 과제의 성능은 일반화하기 어려우며, 평가가 의도한 대상과 실제 측정 대상도 쉽게 달라질 수 있음 결과를 보기 전에 공개한 예상 실험 결과를 확인하기 전에 다음 예상을 지인들에게 공개함 95% 확신으로 동적 언어와 정적 언어 사이의 전반적 우위 관계가 유지되지 않을 것으로 예상함 60% 확신으로 ultra 노력 수준에서는 정적 언어가 어느 정도 유리할 수 있다고 봄 컴파일러 피드백이 정확성이나 효율을 높일 수 있지만, Codex가...