어제 GeekNews에 오른 글 하나가 눈에 띄었습니다. “동적 언어가 코딩 에이전트에서 토큰을 더 적게 쓴다”는, 최근 몇 달 사이 개발자 커뮤니티에서 거의 정설처럼 돌던 주장이 실전 규모 과제에서는 재현되지 않았다는 내용이었습니다(GeekNews 원문).
저는 이 소식을 그냥 흥미로운 벤치마크 뉴스로 넘기기 어려웠습니다. 요즘 팀에서 새 프로젝트 스택을 정하거나 신규 입사자에게 “AI 도구를 잘 쓰려면 어떤 언어가 유리한가요”라는 질문을 받을 때마다, 다들 이런 종류의 벤치마크를 근거로 대기 시작했거든요. 코딩 에이전트 언어 선택 기준이 이제는 팀 의사결정과 커리어에 실제로 영향을 미치기 시작한 겁니다.
‘토큰 효율성’이 언어 선택 기준으로 떠오른 이유
이 논쟁의 출발점은 소프트웨어 개발자 마틴 알더슨(Martin Alderson)이 지난 1월 공개한 비교 실험입니다. 그는 프로그래밍 과제 아카이브인 RosettaCode 데이터를 활용해 19개 주요 언어의 토큰 소비량을 Hugging Face의 GPT-4 토크나이저로 측정했습니다.
알더슨이 자신의 블로그에서 밝힌 결과에 따르면, 같은 문제를 풀 때 C와 클로저(Clojure) 사이에 2.6배의 토큰 소비 차이가 났습니다. 이후 독자 제보로 추가 분석한 배열 언어 J는 평균 70토큰까지 내려가 클로저(109토큰)의 절반 수준이었다고 그는 설명합니다(원문 보기). LLM의 컨텍스트 윈도우 제약을 생각하면, 토큰을 적게 쓰는 언어가 더 긴 개발 세션을 가능하게 한다는 논리였죠.
실전 과제로 검증하니 통념이 흔들렸다
문제는 RosettaCode 과제 대부분이 70~109토큰 선에서 끝나는 짧은 문제라는 점입니다. 엔지니어 댄 루(Dan Luu)는 자신의 블로그에서 이 결과가 구글 AI 요약에까지 인용될 만큼 널리 퍼졌다고 지적하며, 훨씬 규모가 큰 두 가지 실전 과제로 직접 재검증에 나섰습니다(댄 루 블로그).
Zstd 디코더 구현 — medium과 ultra의 결과가 갈렸다
첫 번째 과제는 압축 포맷 zstd의 RFC 명세만 주고 디코더 전체를 구현하게 하는 실험이었습니다. 댄 루에 따르면 일반(medium) 난이도에서는 동적 언어 군집이 여전히 더 효율적인 쪽에 몰려 알더슨의 결론과 방향이 비슷했지만, 최대 추론 노력(ultra) 조건에서는 결과가 뒤섞여 상위권에 정적 언어가 더 많이 올라왔다고 합니다.
Pandoc 변환기 구현 — 밀도보다 ‘인기’가 변수였다
두 번째 과제인 문서 변환기(Pandoc) 구현에서도 정적·동적 여부나 언어의 ‘밀도’와 성공률·비용 사이에 뚜렷한 상관관계는 나타나지 않았습니다. 오히려 댄 루가 관찰한 건 언어의 GitHub 사용 빈도, 즉 대중성과 결과 사이의 약한~중간 수준 양의 상관관계였습니다. 생소한 배열 언어 J가 보여줬던 ‘우월함’도 실전 규모 과제에서는 재현되지 않았다고 그는 정리합니다.
왜 이런 반전이 나타날까 — 클로저의 버그가 보여주는 것
댄 루(Dan Luu)에 따르면 가장 토큰 효율적이라던 클로저는 정작 zstd 과제 테스트 상당수에서 실패했습니다. 원인은 ‘밀도’와 무관한, byte 변환이 128~255 구간에서 예외를 던지는 특이한 버그였다고 그는 설명합니다. 언어가 이론적으로 짧게 쓰인다는 것과, 에이전트가 그 언어로 정확하게 동작하는 코드를 만들어내는 것은 전혀 다른 문제라는 뜻입니다.
같은 시기 나온 학술 논문 “The Best Programming Language for Tokenmaxxing”(Wu, Anderson, Guha, 2026)도 참고할 만합니다. 이 연구는 Python·Java·Rust·OCaml 4개 언어와 5개 모델로 2,000개의 에이전트 실행 기록을 분석해, OCaml이 전 모델에서 가장 많은 토큰을 소비하고 Python이 가장 효율적이라는 결론을 냈다고 논문 저자들은 밝혔습니다(arXiv:2607.22807). 다만 댄 루는 이 논문 역시 4개 언어만 비교했고 소규모 과제를 썼다는 한계를 짚습니다.
그래서 저는 아직 우리 팀 스택을 바꾸지 않습니다
후배님이 만약 “AI 코딩 에이전트를 잘 쓰려면 동적 언어로 옮겨야 하나요”라고 물어본다면, 저는 코딩 에이전트 언어 선택을 벤치마크 헤드라인 하나로 정하지 말라고 답할 것 같아요. 벤치마크 하나가 널리 퍼졌다고 해서 팀 전체의 언어 표준이나 신규 채용 기준을 바꾸는 건 성급합니다. 실무에서는 팀원들의 숙련도, 기존 코드베이스, 채용시장에서의 인력 공급이 토큰 몇 퍼센트 차이보다 훨씬 크게 작용하거든요.
이번 사례가 흥미로운 건, ‘인기 있는 언어일수록 에이전트도 더 안정적으로 다룬다’는 방향성이 두 실험 모두에서 관찰됐다는 점이에요. 결국 학습 데이터가 많은 언어일수록 AI 도구의 도움을 더 안정적으로 받을 수 있다는, 어찌 보면 뻔하지만 실무적으로는 꽤 중요한 시사점입니다. 신기술 도입 여부를 판단할 때는 벤치마크 헤드라인보다 그 뒤의 실험 조건을 먼저 보시길 권해드려요.
시니어 개발자가 이런 벤치마크를 볼 때 체크할 것
- 과제 규모가 실무 작업과 비슷한가, 아니면 70~100토큰짜리 장난감 문제인가
- 결과가 하나의 난이도·모델 조건에서만 나온 것은 아닌가
- 결과 뒤에 언어 자체의 문제가 아니라 개별 라이브러리·버전의 버그가 숨어 있지는 않은가
- 대중성·채용시장·팀 숙련도처럼 벤치마크가 담지 못하는 변수를 함께 따졌는가
이 네 가지만 물어봐도 코딩 에이전트 언어 선택을 헤드라인 하나에 맡기는 실수는 피할 수 있습니다.
관련 글
- AI 도구가 개발자의 학습 방식 자체를 바꾸고 있다는 점에서는 LLM 학습법, 시니어 개발자가 남들과 다르게 쓰는 이유도 함께 보시면 좋습니다.
- AI 코드에 대한 조직의 시선이 갈리고 있다는 점에서는 AI 코드 금지, OpenJDK가 시니어 개발자에게 던진 질문도 참고할 만합니다.
- ‘실력’의 기준 자체가 흔들리는 시대라는 맥락에서는 개발자 실력을 재는 기준, AI 시대에 완전히 달라졌다를 읽어보세요.
📌 함께 보시면 좋은 글
이직·퇴사·연봉 협상을 혼자 판단하기 어렵다면
1:1 개발자 커리어 상담 신청하기 →
※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)
이직·퇴사, 지금 움직여도 될지 헷갈리시나요?
막연히 불안한 건지, 정말 시점이 온 건지 판단이 어려울 때가 있습니다.
5분 체크리스트로 지금 상태를 먼저 정리해보세요.
결론을 대신 내리기보다, 스스로 판단할 기준을 잡는 데 도움을 드립니다.
아직 확신이 없다면, 지금이 ‘고민 단계’인지부터 먼저 점검해보세요