AI 코딩 에이전트에게 최적의 언어는 따로 없다 (danluu.com)

한줄 요약

AI 코딩 에이전트에게 '최적 언어'란 없다 — 작업 규모와 언어 지원 수준이 결론을 바꾼다.

---

AI 에이전트가 코드를 생성할 때 어떤 프로그래밍 언어를 선택해야 비용과 품질 모두 유리한지는, 외주 개발을 검토하는 팀이라면 한 번쯤 마주치는 실질적인 질문이다. 최근 이 주제로 꽤 자주 인용되는 주장이 있다. "파이썬처럼 타입 선언이 없고 코드가 짧은 동적 언어는 LLM이 소비하는 토큰 수가 적어서 비용이 절반 이하로 줄어든다"는 것이다. 언뜻 설득력 있게 들리지만, 실제 프로젝트에 적용하기 전에 이 주장의 근거를 따져볼 필요가 있다.

토큰 절감 주장, 왜 그럴듯해 보이는가

동적 언어가 토큰 효율적이라는 주장의 근거는 단순하다. 정적 타입 언어는 변수 선언, 타입 어노테이션, 보일러플레이트 코드가 많아서 같은 로직을 표현해도 코드 줄 수가 길어진다. AI 모델은 이 코드를 토큰 단위로 읽고 쓰므로, 코드가 길수록 입출력 비용이 늘어난다는 논리다.

실제로 간단한 알고리즘 문제를 여러 언어로 풀게 해보면 파이썬이나 루비 같은 언어가 자바나 러스트보다 눈에 띄게 짧게 나오는 건 사실이다. 문제는 이 차이가 실제 외주 개발 규모의 작업에서도 동일하게 유지되느냐는 점이다.

소규모 벤치마크의 함정

이 주장들을 뒷받침하는 벤치마크 대부분은 아주 작은 단위의 문제를 기반으로 한다. "피보나치를 구현하라", "문자열을 뒤집어라" 수준의 과제다. 이런 문제에서 전체 답안이 수십~백 토큰 수준이면, 언어마다 발생하는 구조적 차이가 극적으로 부각된다.

하지만 실제 앱 개발이나 웹 개발 외주 프로젝트에서 AI 에이전트에게 맡기는 작업은 이와 다르다. 인증 모듈을 만들고, 외부 API와 연동하고, 데이터베이스 스키마를 설계하고, 예외 처리를 촘촘히 짜는 작업에서는 언어의 구조적 특성보다 "AI 모델이 그 언어를 얼마나 잘 훈련받았는가"가 결과 품질을 훨씬 크게 좌우한다.

작은 문제에서 2~3배 차이 나던 토큰 효율 격차는, 수천 줄짜리 실제 코드베이스에서는 의미 있는 수준으로 유지되지 않는다. 작업이 복잡해질수록 언어 문법의 간결함보다 로직 자체의 복잡도가 토큰 소비를 지배하기 때문이다.

언어 선택보다 더 중요한 변수

외주 개발사 입장에서 언어 선택 시 실제로 고려해야 할 변수는 두 가지다.

첫째는 AI 모델의 해당 언어 지원 수준이다. 주요 AI 코딩 도구들은 파이썬, 자바스크립트, 타입스크립트, 고(Go), 러스트 등 주류 언어에 집중적으로 학습 데이터와 강화학습 환경을 투입하고 있다. 반면 사용자가 적은 비주류 언어는 AI가 만들어내는 코드의 정확도 자체가 낮다. 설령 토큰이 절반으로 줄어든다 해도, 잘못된 코드를 고치는 데 드는 비용이 훨씬 크다.

둘째는 노력 수준(effort level)에 따른 결과 차이다. AI 에이전트에게 최소한의 시도만 허용할 때와, 컴파일러 피드백을 받아 반복적으로 수정하도록 허용할 때 언어별 결과가 달라진다. 단순 시도에서는 동적 언어가 빠르게 동작하는 코드를 내놓는 경향이 있지만, 충분한 반복을 허용하면 정적 타입 언어도 비슷하거나 더 나은 완성도에 도달한다. 타입 시스템이 에러를 명시적으로 잡아주기 때문이다.

외주 개발 프로젝트에서의 실용적 결론

AI 에이전트를 활용한 앱 개발이나 웹 개발 외주를 검토할 때, 언어를 "토큰 비용이 적은 것"으로 고를 이유는 없다. 그 기준은 지나치게 단순화된 벤치마크에서 나온 것이고, 실제 프로젝트 맥락에서는 다음 기준이 더 합리적이다.

• 팀이 유지보수할 수 있는 언어인가
• AI 도구가 해당 언어에서 높은 품질의 코드를 생성하는가
• 프로젝트의 생태계와 라이브러리 지원이 충분한가

결국 "AI가 쓰기 쉬운 언어"는 AI가 많은 데이터로 훈련된 언어다. 그건 지금도 파이썬, 타입스크립트, 자바스크립트 같은 주류 언어들이다. 개발 외주를 맡길 때 언어 선택 논의가 나온다면, 토큰 효율 논쟁보다 이 세 가지 기준으로 판단하는 게 실질적으로 더 나은 결과를 만든다.