LLM은 "심심한 언어"를 좋아한다 — Rust 대신 Python을 고르는 이유

AI가 짜는 코드, 왜 언어마다 품질이 다를까

Claude나 GPT한테 같은 기능을 Python으로 짜달라고 했을 때와 Rust로 짜달라고 했을 때, 결과물의 안정성이 꽤 다르다는 걸 느껴본 분 많으실 거예요. Python 코드는 거의 바로 돌아가는데, Rust 코드는 컴파일 에러부터 한참 잡아야 하고, 가끔은 존재하지도 않는 크레이트 이름을 만들어 내기도 하죠. 이번에 jry.io 블로그에 올라온 "Use Boring Languages with LLMs"라는 글이 바로 이 현상을 정면으로 다룹니다.

저자의 주장은 단순해요. LLM과 가장 잘 맞는 언어는 "심심한 언어"다. 여기서 심심하다는 건 나쁘다는 뜻이 아니에요. 오래되고, 사용자가 많고, 변화가 느리고, 인터넷에 코드 샘플이 차고 넘치는 언어를 말해요. Python, JavaScript, Java, Go 같은 것들이요.

왜 그런 일이 벌어지는가

이유를 풀어보면 LLM의 학습 방식과 직결돼요. LLM은 본질적으로 다음 토큰을 가장 그럴듯하게 예측하는 모델이에요. 그러니까 어떤 라이브러리, 어떤 패턴, 어떤 함수 이름이 학습 데이터에 많이 등장했을수록 잘 맞히고, 적게 등장했을수록 헛다리를 짚어요. 이게 우리가 흔히 말하는 "환각(hallucination)"의 한 원인이에요. 이게 뭐냐면, 모델이 그럴듯해 보이지만 실제로는 존재하지 않는 함수나 API를 자신 있게 적어내는 현상이에요.

자, 그럼 언어별로 보자고요. Python은 2003년쯤부터 본격적으로 인기를 끌었고, GitHub에 올라온 코드량이 어마어마하죠. 그 결과 LLM 입장에서 requests.get(url).json() 같은 패턴은 거의 "근육 기억" 수준이에요. 반면 Rust는 2015년 1.0 출시 이후 빠르게 성장했지만 절대량 자체는 아직 Python의 일부분에 불과하고, 게다가 에디션, 비동기 런타임(tokio vs async-std), 크레이트 버전 차이 같은 변화 요인이 너무 많아요. LLM이 학습할 때 본 코드가 지금 컴파일러로는 안 돌아가는 경우가 흔하다는 뜻이에요.

Zig는 더 극단적이에요. 1.0이 아직 안 나왔고, 1년 사이에 표준 라이브러리 함수 시그니처가 바뀌는 일이 다반사예요. 사람이 직접 짜도 어제 짠 코드가 오늘 안 돌아갈 판인데, LLM에게는 거의 지옥이죠.

그럼 우리는 Python만 써야 하나

저자의 답은 "그건 아니다"예요. 대신 언어 선택에 LLM 친화성을 의식적으로 한 축으로 넣자는 거예요. 예를 들어 빠르게 프로토타입을 돌리는 단계, 혼자서 사이드 프로젝트를 만드는 단계에서는 Python/JS/Go 같은 "심심한 언어"가 AI를 풀배율로 활용할 수 있게 해주죠. 반대로 성능이 절대적으로 중요한 핵심 모듈은 사람이 직접 Rust로 짜는 게 낫고요.

또 흥미로운 포인트는 "라이브러리도 심심한 걸 골라라"는 조언이에요. 같은 Python 안에서도, Django 같은 메이저 프레임워크는 LLM이 거의 완벽하게 다루는데, 최근에 나온 신생 비동기 프레임워크는 헛소리를 종종 합니다. JavaScript에서도 Next.js 14 App Router 같은 신문법은 LLM이 자주 틀려요. 학습 컷오프 시점과 라이브러리 변화 속도의 함수죠.

업계 맥락 — 같은 결의 다른 목소리들

사실 비슷한 통찰을 여러 사람이 다른 각도에서 말해왔어요. Simon Willison은 "LLM은 인기 있는 도구를 쓸수록 효율이 좋다"고 했고, DHH는 Rails가 AI 시대에 더 강해질 거라고 자주 강조해왔어요. Rails처럼 컨벤션이 강한 프레임워크는 LLM이 짜낼 코드의 분산이 작거든요. 결국 "AI와 잘 맞는 스택"이라는 새로운 평가축이 기술 선택의 한 기준이 되고 있다는 거예요.

한국 개발자에게 주는 시사점

국내에서도 Rust, Zig, Bun 같은 새 기술에 대한 관심이 정말 높잖아요. 좋은 일이긴 한데, 만약 "AI로 빠르게 만들고 빠르게 검증한다"가 팀의 핵심 전략이라면, 기술 스택을 정할 때 AI 친화성도 진지하게 따져볼 필요가 있어요. 특히 1~3인 규모의 스타트업이나 사이드 프로젝트라면, Go + Postgres + Vanilla JS 같은 "심심한 조합"이 의외로 가장 빠른 길일 수 있습니다.

반대로 채용 관점에서는 역설적인 결론이 나와요. "AI가 잘 못 짜는 영역"이 곧 "사람의 가치가 남는 영역"이거든요. Rust로 시스템 프로그래밍을 깊이 다룰 줄 안다면, AI 시대에도 본인의 시장 가치가 안 떨어지는 셈이죠.