코딩 에이전트에 가장 적합한 프로그래밍 언어는 무엇일까?

• 코딩 에이전트에게 가장 좋은 프로그래밍 언어는?

  • 흔히 동적 타입 언어는 코드가 짧아서 LLM 토큰도 적게 사용한다는 주장이 있음

  • 기존 소규모 벤치마크에서는 언어에 따라 생성 코드의 토큰 수가 2배 이상 차이 나는 경우도 있었음

    • C와 Clojure 사이에서 약 2.6배 차이가 관찰되기도 함

    • J, Clojure처럼 표현력이 높은 언어가 특히 유리하게 나타남

  • 이를 근거로 Ruby, Clojure, J 같은 간결한 언어가 AI 코딩에 더 적합하다는 주장도 나옴

  • 하지만 Dan Luu는 이런 결과가 대부분 Rosetta Code 수준의 매우 작은 프로그램에서 나온 것이라 실제 개발에 그대로 적용하기 어렵다고 지적

• 작은 프로그램의 토큰 효율이 실제 개발 성능으로 이어지는지는 불분명

  • 기존 벤치마크에서는 70~100 토큰 정도의 코드로 해결할 수 있는 문제가 많음

  • 코드가 수천~수만 토큰으로 커지고 디버깅과 테스트가 필요한 실제 작업에서는 다른 요소들이 훨씬 중요해질 수 있음

  • 그래서 단순한 코드 길이 대신 에이전트가 실제 프로그램을 얼마나 잘 구현하는지를 직접 비교

• 첫 번째 실험: Zstd decoder를 처음부터 구현

  • 에이전트에게 Zstd RFC를 제공하고 완전한 decoder 구현을 요청

  • 인터넷 접근은 차단

  • 평가용 테스트는 에이전트에게 공개하지 않음

  • 여러 프로그래밍 언어에서 동일한 작업을 수행

  • GPT 계열 코딩 에이전트의 서로 다른 reasoning effort 설정도 비교

  • 주요 평가 기준은

    • 실제 테스트 통과율

    • 토큰 및 실행 비용

    • 구현 성공률

• 결과는 ‘동적 타입 vs 정적 타입’으로 설명되지 않았음

  • Medium effort에서는 일부 동적 언어가 조금 더 좋아 보임
    

    

  • Ultra effort에서는 정적 언어와 동적 언어의 순위가 뒤섞임
    

    

  • 정적 타입 언어가 일관되게 우수하지도 않았고

  • 동적 타입 언어가 일관되게 우수하지도 않았음

  • 즉 타입 시스템 하나만으로 코딩 에이전트 성능을 예측하기 어려움

• 코드가 짧은 언어가 반드시 LLM에도 유리하지 않았음

  • J처럼 극단적으로 간결한 언어는 단순 토큰 벤치마크에서 매우 좋은 결과를 보임

  • 하지만 Zstd 같은 실제 구현 작업에서는 이런 이점이 거의 나타나지 않음

  • 프로그램의 표현 밀도가 높다고 해서 에이전트가 정확하게 코드를 작성하는 것은 아님

  • 토큰 수 자체보다 모델이 해당 언어에 얼마나 익숙한지가 더 중요한 것으로 보임

• 주류 언어일수록 상대적으로 좋은 결과를 보이는 경향

  • GitHub에서 많이 사용되는 언어와 에이전트 성능 사이에 약한~중간 정도의 상관관계가 관찰됨

  • 인기 언어에서는

    • 정확도가 더 높은 경향

    • 구현 비용이 더 낮은 경향

  • 가능한 이유로는

    • 학습 데이터에 더 많은 코드가 존재

    • RL 및 코딩 에이전트 학습 환경에서 더 자주 사용

    • 컴파일러 오류나 일반적인 문제 해결 패턴을 모델이 더 많이 학습

  • 즉 언어 자체의 특성보다 모델이 그 언어를 얼마나 많이 경험했는지가 더 중요할 가능성이 있음

• 두 번째 실험: Pandoc 관련 ProgramBench

  • Zstd와 성격이 다른 작업에서도 같은 현상이 나타나는지 확인

  • 이번에는 테스트 일부를 에이전트에게 제공

  • 최종 평가는 별도의 hidden test로 수행

  • 

    
    결과 역시 특정 언어 분류가 압도적인 우위를 보이지 않음

    • 정적 언어가 특별히 우수하지 않음

    • 동적 언어도 특별히 우수하지 않음

    • 코드가 매우 간결한 언어도 특별한 이점이 없음

  • 반면 비주류 언어가 상대적으로 좋지 않은 경향은 다시 나타남

• 언어별 특정 함정이 전체 결과를 크게 좌우하기도 함

  • Clojure는 Zstd 테스트에서 특히 좋지 않은 성능을 보임

  • 하지만 원인은 동적 타입이라는 언어 특성보다는 특정 API 사용 실수였음

  • Medium 실행 40회 중 36회에서 byte 변환 과정의 128~255 값 처리와 관련된 비슷한 오류가 발생

  • 모델이 특정 언어에서 반복적으로 같은 실수를 하는 패턴이 존재한다는 것

  • Rust에서도 cargo 명령을 잘못 사용한 뒤 수정하는 행동이 반복적으로 나타남

  • 따라서 한 벤치마크의 결과만으로

    • “Rust는 LLM에 좋은 언어”

    • “Clojure는 LLM에 나쁜 언어”

    • 같은 일반적인 결론을 내리기 어려움

• AI 코딩 벤치마크 자체의 신뢰성도 중요한 문제

  • 기존 ai-coding-lang-bench를 조사하면서 여러 평가 오류를 발견

  • 일부 테스트는 잘못된 executable 경로를 실행하고 있었음

  • 한 Go 에이전트가 해당 문제를 symlink 생성으로 해결

  • 이후 다른 언어의 테스트에서도 실제로는 Go executable이 실행되는 문제가 발생

  • 테스트 조건문의 양쪽 branch가 모두 pass를 호출해 사실상 검증을 하지 않는 사례도 존재

  • 에이전트가 테스트 코드와 환경을 모두 볼 수 있어 테스트에 맞춰 환경 자체를 수정하는 것도 가능했음

• Rust의 낮은 점수도 실제 언어 문제와 관계없었던 사례

  • 기존 벤치마크에서는 Rust 실패 원인을 ownership 등의 언어 복잡성 때문이라고 해석

  • 하지만 올바른 executable을 사용해 다시 평가하자 Rust가 만점을 기록

  • 벤치마크 결과만 보고 언어 특성에 대한 설명을 붙이면 쉽게 잘못된 결론에 도달할 수 있음

  • AI 코딩 벤치마크에서는 숫자를 보기 전에 실제로 무엇을 측정하고 있는지 확인하는 것이 중요

• ‘동적 언어가 AI 코딩에 유리하다’는 가설

  • 현재 실험에서는 뚜렷한 근거가 없음

  • 동적 타입 언어가 항상 코드 생성 비용이 낮거나 정확도가 높은 것도 아님

• ‘간결한 언어가 토큰 효율 때문에 유리하다’는 가설

  • 작은 코드에서는 사실일 수 있음

  • 하지만 실제 규모의 구현 작업에서는 확인되지 않음

  • 코드 토큰 수 감소가 디버깅 실패나 잘못된 구현 비용을 상쇄할 정도의 장점으로 이어지지 않음

• ‘프로젝트가 커지면 정적 타입 언어가 유리하다’는 가설

  • 이번 실험에서는 명확하게 확인되지 않음

  • 컴파일러와 타입 시스템의 피드백이 도움이 될 수 있지만 이를 일반적인 성능 우위로 연결할 근거는 부족

• ‘널리 사용되는 언어가 AI 코딩에 유리하다’는 가설

  • 이번 실험에서는 가장 가능성이 있어 보이는 결과

  • 모델의 학습 데이터와 코딩 경험이 많은 언어가 상대적으로 안정적인 성능을 보임

  • 다만 상관관계가 강한 것은 아니므로 이것 역시 확정적인 법칙은 아님

• ‘인터넷에 나쁜 코드가 많은 언어는 LLM도 코드를 못 짤 것이다’라는 가설

  • PHP처럼 품질이 낮은 코드가 많이 공개된 언어에서는 모델 성능도 낮을 것이라는 예상이 가능

  • 하지만 이번 테스트에서는 그런 효과가 뚜렷하게 나타나지 않음

• ‘AI 시대에는 Haskell 같은 강력한 언어가 유리하다’는 주장도 확인되지 않음

  • 사람이 작성하기 어렵더라도 AI가 대신 작성하면 강력한 타입 시스템이나 추상화를 가진 언어가 유리할 수 있다는 주장

  • 이번 벤치마크에서는 특별한 장점이 확인되지 않음

• Ralph Loop: 매번 Context를 초기화하는 방식도 비교

  • 이전 Context를 유지하는 방식과 매번 초기화하는 Ralph Loop 방식을 비교

  • Ralph Loop는 각 반복에서 기존 Context를 버리고 원래 Prompt부터 다시 시작하는 접근

    • 이전 reasoning의 잘못된 방향이나 불필요한 Context에 모델이 고착되는 것을 막는 것이 목적

  • 하지만 이번 실험에서는 Context를 계속 유지하는 방식이 Ralph Loop보다 더 좋은 결과를 보임
    

    

  • Context를 초기화하더라도 이전 실행에서 만들어진 코드와 파일은 그대로 남아 있기 때문에 Context Reset이 곧 State/Artifact Reset을 의미하지 않음

    • 잘못된 reasoning은 사라져도 이미 만들어진 잘못된 코드에 다시 끌려갈 수 있음

  • Medium을 여러 번 반복하는 것보다 높은 reasoning effort의 Ultra를 한 번 실행하는 편이 비용 대비 더 좋은 결과를 보이기도 함

    • Medium 반복은 한번 잘못된 해결 방향에 고착되면 이후 반복에서도 같은 코드를 계속 수정하면서 진전하지 못하는 경우가 있었음

  • LLM 코딩에서는 잘못된 구현에 계속 patch를 쌓는 것보다 큰 부분을 버리고 다시 작성하는 것이 더 효과적인 경우가 많음

    • 하나의 구현을 계속 고치기보다 여러 번 독립적으로 시도한 뒤 가장 좋은 결과를 선택하는 방식이 더 나을 수도 있음

  • Ralph Loop와 Context 유지 방식의 성능 차이는 이번 실험에서 일부 동적 타입 언어에서 더 크게 나타남

    • 정적 타입 언어는 Context를 잃더라도 타입과 코드 구조에 이전 의도가 어느 정도 남아 있을 가능성이 있음

    • 다만 하나의 실험만으로 정적 타입 언어가 Ralph Loop에 더 적합하다고 일반화할 수는 없음

• 코딩 에이전트 시대의 언어 선택에서 중요한 것

  • 단순히 생성되는 코드의 토큰 수가 적은가만 보는 것은 큰 의미가 없을 가능성이 높음

  • 실제 성능에는 다음 요소들이 더 중요할 수 있음

    • 모델이 해당 언어를 얼마나 잘 알고 있는가

    • 컴파일러와 테스트가 얼마나 좋은 피드백을 제공하는가

    • 라이브러리와 개발 도구가 얼마나 잘 구성되어 있는가

    • 모델이 해당 언어에서 반복적으로 어떤 실수를 하는가

    • 문제 영역에 필요한 라이브러리와 예제가 학습 데이터에 얼마나 존재하는가

• 결론

  • 현재 데이터만으로 AI 시대에 가장 좋은 프로그래밍 언어를 고르기는 어려움

  • 동적 타입, 정적 타입, 코드 간결성 같은 한 가지 특성만으로 에이전트 성능을 설명하기도 어려움

  • 오히려 모델이 충분히 많이 학습하고 사용해 본 주류 언어가 상대적으로 안정적인 선택일 가능성이 있음

  • 언어마다 특정 모델이 반복적으로 빠지는 함정도 존재하기 때문에 벤치마크 하나의 결과를 일반화하면 위험

  • AI 코딩 성능을 평가할 때는 언어의 이론적 특성보다 실제 규모의 작업 + hidden test + 독립적인 평가 환경이 중요

^{source http://danluu.com/pl-tokens/}

HN에서는 코딩 에이전트에 맞는 언어를 토큰 수만으로 가려내려는 접근에 대체로 선을 그었다. 간결한 동적 언어는 코드의 분량을 줄일 수 있지만, 문법이 압축됐다고 전체 작업 비용까지 낮아지지는 않는다. 기호 중심 문법은 토큰화에 불리할 수 있으며, 실제 세션에서는 코드 생성보다 오류 수정과 도구 호출, 검증에 더 많은 자원을 쓴다는 지적이 이어졌다.

실무에서는 정적 타입과 탄탄한 도구 체계를 중시했다. Go는 구현 방식이 비교적 일정하고 컴파일과 린트가 빨라 반복 작업을 줄인다는 평가를 받았다. Rust도 여러 오류를 컴파일 단계에서 잡아 런타임 디버깅을 덜어준다는 점에서 지지를 얻었다. Python은 짧은 작업과 풍부한 라이브러리에 강하지만, 복잡한 애플리케이션에서는 런타임 오류와 일관성 없는 구현이 쌓였다는 경험도 나왔다.

그러나 사소하거나 널리 알려진 소프트웨어를 재현하는 시험만으로 특정 언어의 우위를 확정하기는 어렵다. 이런 과제는 일반적인 구현 능력보다 학습 데이터에서 익힌 내용을 다른 언어로 옮기는 능력을 재기 쉽다. 검색과 외부 라이브러리를 막은 조건도 현실의 개발 방식과 거리가 있다. 장기 과제에서 언어별 성공률 차이가 작았다는 결과와, 같은 언어도 과제에 따라 효율이 달라졌다는 관찰도 신중한 해석을 요구한다.

팀은 코드 길이보다 에이전트가 결과를 얼마나 빠르고 정확하게 검증할 수 있는지 살펴야 한다. 타입 검사와 테스트, 정적 분석, 린트, 빠른 빌드가 갖춰지면 시행착오를 줄일 수 있다. 사람이 코드를 이해하고 검토할 수 있는지, 코드베이스가 작은 구성 요소와 명확한 경계로 나뉘었는지도 중요하다. 몇 토큰을 아끼기보다 팀의 숙련도와 과제에 맞는 생태계, 장기 유지보수 여건을 먼저 확인하는 편이 현실적이다.