LLM의 컨텍스트 길이 제약을 고려해 RosettaCode 데이터와 GPT-4 토크나이저로 여러 프로그래밍 언어의 토큰 효율을 비교하고 그 의미를 살펴본다.
URL: https://martinalderson.com/posts/which-programming-languages-are-most-token-efficient/
2026년 1월 8일 · Martin Alderson
저는 인간이 점점 더 이상 코드를 직접 쓰지 않게 되는 상황에서, 프로그래밍 언어와 툴링에 어떤 일이 벌어질지 생각해 보려고 해왔습니다. 최근에 에이전트가 코드 포팅을 얼마나 잘하는지에 대해 글을 썼는데, 그게 인간과 비교했을 때 LLM이 어떤 제약을 갖는지에 대해 조금 더 생각하게 만들었습니다.
LLM이 갖는 가장 큰 제약 중 하나는 컨텍스트 길이입니다. 현재의 트랜스포머 아키텍처에서는 컨텍스트 윈도우가 길어질수록 메모리 사용량이 크게 증가하기 때문에, 이 문제는 해결하기가 어렵습니다. 그리고 지금의 메모리 부족 상황을 생각하면, 세상이 당장 메모리로 넘쳐난다고 보기도 어렵습니다.
그렇다면 소프트웨어 개발 에이전트에게는 프로그래밍 언어가 실제로 얼마나 ‘토큰 효율적’인지가 큰 차이를 만들 수 있고, 미래에는 언어 선택의 요소가 될 수도 있지 않을까 싶습니다. 코딩 에이전트의 컨텍스트 윈도우 중 상당 부분이 코드일 텐데, 더 토큰 효율적인 언어라면 더 긴 세션을 가능하게 하고, 결과를 내기 위해 필요한 리소스도 줄일 수 있을 것입니다.
TOON처럼(JSON을 더 토큰 효율적으로 인코딩하는 방식) 이미 그런 시도는 본 적이 있습니다. 하지만 프로그래밍 언어는 어떨까요?[1]
이 주제를 조사하던 중 RosettaCode 프로젝트를 알게 됐습니다. 스스로를 ‘프로그래밍 크레스토마시(progamming chrestomathy) 사이트’라고 소개하는데(개인적으로 이 표현이 정말 마음에 듭니다). 1,000개가 넘는 프로그래밍 ‘과제(task)’가 있고, 사람들이 다양한 언어로 이를 구현해 둔 저장소입니다. 거의 1,000개에 달하는 프로그래밍 언어로의 기여가 있습니다.
이 데이터셋의 GitHub 미러를 찾아서, Claude Code를 이용해 비교를 만들라고 요청했습니다. 토크나이저로는 Hugging Face의 Xenova/gpt-4 토크나이저를 사용했는데, 이는 OpenAI의 GPT-4 토크나이저를 커뮤니티가 포팅한 것입니다.
그 다음 Claude Code에게 가장 인기 있는 프로그래밍 언어들 중(대략 제 경험과도 비슷한) 일부를 선정하게 한 뒤, 이 19개 언어 모두에 해답이 기여된 과제들만 골라 토크나이저에 통과시켰습니다. Rosetta Code 데이터셋에 과제가 너무 적어서 TypeScript는 포함하지 않았습니다.
이 데이터셋과 접근법에는 수많은 한계와 편향 가능성이 있습니다! 이는 과학적 연구라기보다는, 어느 정도는 같은 종류의 과제에 대한 해법을 비교해 보는 흥미로운 관찰로 봐야 합니다.
업데이트: APL에 대해 묻는 분들이 많아서, 더 작은 ‘유사 과제’ 세트로 다시 돌려 봤습니다. APL은 110 토큰으로 4위를 했습니다. APL의 유명한 간결함이 LLM에게는 오히려 장점이 아니었습니다. 토크나이저가 APL의 심볼 세트에 최적화되어 있지 않아서, 그 독특한 글리프들(⍳, ⍴, ⌽ 등)이 각각 여러 토큰으로 쪼개지기 때문입니다.
제가 비교한 언어들 사이에서 C(가장 토큰 효율이 낮음)와 Clojure(가장 효율이 높음) 사이에는 2.6배의 매우 의미 있는 격차가 있었습니다.
예상대로 동적 언어가 훨씬 토큰 효율적이었습니다(타입을 전혀 선언하지 않아도 되면 토큰을 많이 아낄 수 있습니다). 다만 분석한 동적 언어 중에서는 JavaScript가 가장 장황했습니다.
하지만 제게 놀라웠던 건 Haskell이나 F# 같은 일부 함수형 언어가 얼마나 토큰 효율적인가였습니다. 가장 효율적인 동적 언어들보다 겨우 조금 덜 효율적인 정도였습니다. 이는 의심할 여지 없이 매우 효율적인 타입 추론 시스템 덕분일 것입니다. 저는 LLM에게는 타입이 있는 언어를 쓰는 데 장점이 정말 많다고 생각합니다. 최소한 컴파일을 통해 문법 오류나 메서드 환각(hallucination)에 대한 빠른 피드백을 받을 수 있기 때문입니다. LSP를 쓰면 더 도움이 됩니다.
컨텍스트 윈도우의 80%가 코드 읽기, 수정, diff라고 가정하면, Haskell이나 F#를 쓰는 것은 Go나 C#를 쓰는 것보다 잠재적으로 훨씬 더 긴 개발 세션을 가능하게 할 것입니다.
페타플롭 단위의 연산 성능을 가지고 있으면서도, ‘작은’ 컨텍스트 윈도우에서 코드의 장황함이 중요해질 수 있다는 이 기묘한 미래가 정말 흥미롭습니다. LLM은 소프트웨어 엔지니어링을 바라보는 제 멘탈 모델을 계속 깨뜨립니다.
수천 명의 독자가 매달 제 이메일을 받아봅니다. AI 발전, LLM, 경제의 교차점에 관한 최근 글과, 그 밖에 읽을 가치가 있는 것들을 담습니다. 군더더기 없고, 스팸도 없습니다.
구독하기
© 2025 Martin Alderson | 뉴스레터 | 연락처 | RSS
구독하기
월 최대 1회, 스팸 없음.
감사합니다! 구독이 완료되었습니다.
