클로드 코드가 가장 잘 다루는 프로그래밍 언어는 무엇일까

AI 에이전트 시대가 본격적으로 열리면서 우리가 프로그래밍 언어를 선택하는 기준이 근본적으로 흔들리고 있다. 과거에는 인간 개발자의 가독성이나 실행 성능, 혹은 생태계의 크기가 가장 중요한 지표였다면 이제는 AI 에이전트가 얼마나 효율적으로 코드를 생성하고 검증할 수 있는지가 새로운 척도로 부상했다. 최근 엔도 유스케가 클로드 코드(Claude Code)를 활용해 13개 프로그래밍 언어의 생산성을 정량적으로 분석한 결과는 이런 변화를 아주 명확하게 보여준다. 단순히 어떤 언어가 좋다는 주관적인 논쟁을 넘어 시간과 비용이라는 구체적인 수치로 증명된 데이터는 우리가 앞으로 어떤 언어로 개발을 시작해야 할지에 대해 많은 시사점을 던져준다.

이번 실험은 클로드 4.6 오퍼스 모델을 기반으로 한 클로드 코드 에이전트에게 미니 깃(mini-git)을 구현하게 하는 방식으로 진행되었다. 깃의 핵심 기능인 초기화, 추가, 커밋, 로그를 구현하는 첫 번째 단계와 상태 확인, 차이점 비교, 체크아웃, 리셋 기능을 추가하는 두 번째 단계로 나누어 총 20회씩 반복 측정했다. 비교 대상이 된 언어는 파이썬, 루비, 자바스크립트 같은 동적 언어부터 고, 러스트, 자바, C 같은 정적 언어, 그리고 리스프 계열의 스킴이나 함수형 언어인 하스켈까지 폭넓게 포함되었다. 실험의 결과는 놀라웠다. 루비, 파이썬, 자바스크립트가 속도와 비용, 안정성 모든 면에서 압도적인 1위 그룹을 형성했기 때문이다.

이 세 가지 동적 언어는 프로젝트를 처음 시작하는 단계에서 평균 73초에서 81초 정도의 시간만을 소모했다. 비용 측면에서도 0.36달러에서 0.39달러 수준으로 가장 저렴했다. 반면 정적 타입 언어들은 이보다 1.4배에서 2.6배 더 느리고 비쌌다. 고(Go)는 101.6초, 자바는 115.4초가 걸렸으며 러스트는 113.7초를 기록했다. 심지어 타입 체크 기능을 추가한 파이썬이나 루비의 경우 순수 동적 버전보다 훨씬 더 많은 시간과 비용이 들어갔다. 이는 타입 시스템이 AI의 환각을 방지해줄 것이라는 일반적인 기대와는 상반되는 결과다. 실제로 총 600번의 테스트 실행 중 실패한 케이스는 단 3번뿐이었는데, 그 실패가 발생한 언어는 아이러니하게도 강력한 정적 타입을 자랑하는 러스트와 하스켈이었다.

동적 언어가 AI 에이전트에게 유리한 이유는 여러 가지가 있겠지만 가장 큰 요인은 코드의 간결성과 설정의 단순함으로 보인다. 클로드 코드는 프로젝트를 시작할 때 빈 디렉토리에서 작업을 시작한다. 이때 자바나 러스트 같은 언어는 프로젝트 구조를 설정하고 빌드 파일을 작성하는 등 부수적인 작업에 많은 토큰을 소모한다. 반면 파이썬이나 루비는 단일 파일에 바로 로직을 작성하기 시작할 수 있다. 이런 설정 단계의 오버헤드가 초기 단계인 v1에서 큰 격차를 만들어냈다. 또한 루비와 파이썬은 AI가 학습한 데이터셋이 압도적으로 많기 때문에 에이전트가 코드를 작성할 때 주저함이 적고 생각하는 토큰(Thinking Tokens)을 덜 사용하는 경향을 보였다.

정적 타입 언어가 무조건 나쁘다는 의미는 아니다. 이전 글에서 고(Go)의 명확성이 에이전틱 워크플로우에서 강력한 무기가 될 수 있다고 언급했듯이, 대규모 프로젝트로 넘어갈수록 타입 시스템의 가치는 커질 것이다. 하지만 이번 벤치마크는 프로토타이핑 단계나 소규모 기능을 빠르게 구현할 때는 동적 언어가 주는 이점이 확실하다는 것을 보여준다. 특히 반복적인 개발 과정에서 에이전트의 응답을 기다리는 시간은 개발자의 흐름(Flow)을 결정짓는 핵심 요소다. 30초를 기다리는 것과 60초를 기다리는 것은 단순히 2배의 차이가 아니라 개발자가 집중력을 유지하느냐 다른 곳으로 눈을 돌리느냐를 가르는 큰 차이다.

재미있는 점은 코드의 길이(LOC)와 생성 비용이 항상 일치하지 않는다는 사실이다. 오캄(OCaml)이나 하스켈은 생성된 코드의 양이 매우 적었음에도 불구하고 비용과 시간 면에서는 중하위권에 머물렀다. 이는 에이전트가 해당 언어의 복잡한 문법이나 개념을 처리하기 위해 더 많은 추론을 수행했음을 시사한다. 즉 코드의 절대적인 양보다 에이전트가 얼마나 익숙하게 다룰 수 있는 언어인가가 생산성에 더 큰 영향을 미친다는 뜻이다. C 언어의 경우 500줄이 넘는 긴 코드를 생성해야 했기에 시간과 비용이 가장 많이 들었지만 적어도 에이전트가 로직을 짜는 데 있어서 하스켈처럼 고통스러워하지는 않았다.

타입 체크 도구의 오버헤드도 눈여겨볼 대목이다. 파이썬에 mypy를 적용하면 일반 파이썬보다 1.6배에서 1.7배 더 느려졌고, 루비에 Steep을 적용하면 2배에서 3.2배까지 느려졌다. 정적 타입이 버그를 줄여줄 수는 있겠지만 에이전트가 스스로 테스트를 돌리고 수정하는 루프를 가지고 있다면 타입 체크 과정 자체가 일종의 병목 현상이 될 수 있다. 타입 오류는 에이전트가 가장 쉽게 감지하고 수정할 수 있는 오류 중 하나이기 때문이다. 만약 에이전트가 타입 오류를 수정하지 못할 정도로 성능이 낮다면 그것은 언어의 문제가 아니라 모델의 지능 문제라고 봐야 한다.

결국 우리는 에이전트와 협업할 때 '언어의 이동성’을 적극적으로 활용해야 한다. 초기 프로토타이핑이나 기능 구현은 루비나 파이썬처럼 빠르고 비용 효율적인 언어로 진행하고, 프로젝트가 성숙해지고 안정성이 필요한 시점에 정적 타입 언어로 전환하는 전략이 유효해 보인다. 클로드 같은 고성능 모델은 코드의 언어 간 변환을 아주 훌륭하게 수행하기 때문이다. 과거에는 언어를 바꾸는 것이 대대적인 재작업을 의미했지만 이제는 에이전트에게 '이 파이썬 코드를 고(Go)로 다시 작성해줘’라고 명령하는 것만으로도 충분히 가능한 시나리오가 되었다.

물론 이번 실험이 모든 상황을 대변하지는 않는다. 외부 라이브러리 의존성이 크거나 런타임 성능이 극도로 중요한 경우에는 결과가 달라질 수 있다. 하지만 에이전트 중심의 개발 환경에서 개발 속도가 곧 품질의 한 차원이라는 점은 부정할 수 없다. 경쟁자가 우리보다 두 배 빠른 속도로 기능을 배포하고 있다면 우리가 정적 타입을 고수하며 신중함을 기하는 것이 과연 정답일지 고민해봐야 한다. 기술의 발전 속도가 인간의 인지 능력을 앞지르는 시대에는 가장 빠르고 유연하게 움직일 수 있는 도구가 승리할 가능성이 높다.

앞으로의 프로그래밍 언어 생태계는 에이전트 친화적인 방향으로 재편될 것이다. 인간이 읽기 좋은 코드를 넘어 에이전트가 추론하기 쉽고 불필요한 보일러플레이트가 없는 언어들이 더 각광받을 것이다. 루비와 파이썬이 이번 벤치마크에서 보여준 성과는 단순히 우연이 아니라 그만큼 AI가 학습하기에 구조적으로 명확하고 표현력이 풍부했다는 증거이기도 하다. 우리는 이제 언어를 선택할 때 '내가 이 언어를 얼마나 좋아하는가’보다 '나의 AI 파트너가 이 언어로 얼마나 최대의 성과를 낼 수 있는가’를 먼저 자문해봐야 한다.

정리하자면 루비, 파이썬, 자바스크립트는 클로드 코드 환경에서 가장 강력한 효율을 보여주는 삼총사다. 정적 타입 언어의 안정성은 분명 매력적이지만 초기 개발 단계에서의 높은 비용과 느린 피드백 속도는 무시하기 어려운 단점이다. 따라서 에이전트를 활용한 개발을 고려 중이라면 일단 가장 가벼운 언어로 시작할 것을 권한다. 그리고 시스템이 커졌을 때 정적 타입 언어로의 마이그레이션을 에이전트에게 맡기는 것이 현재로서 가장 지혜로운 전략이 아닐까 싶다. AI와 함께 걷는 이 길 위에서 우리는 도구에 얽매이기보다 도구를 어떻게 가장 효율적으로 부릴 것인가에 집중해야 한다.