AI가 코드를 작성한다면, 왜 Python을 사용해야 하는가?

지난 10년 동안은 실행 속도보다 빠른 출시가 중요했습니다. 이제는 아닙니다.

새 프로젝트를 위한 언어를 선택하는 것은 대개 쉬운 문제였습니다. 생태계가 거대하고, 인재 풀이 풍부하며, 금요일까지 인상적인 데모를 만들 수 있는 Python 또는 TypeScript를 사용하면 되었습니다. Rust, Go, C++ 등은 10~100배의 성능을 제공했지만, 그 대가를 치러야 했습니다. 6개월간의 적응 기간, 더 좁은 인재 시장, 그리고 개발자를 괴롭히는 빌드 시스템(build system)이 그것입니다. 그래서 여러분은 Python 버전을 출시하고 고객에게 판매하며, 나중에 "성능을 최적화하겠다"라고 스스로에게 약속했습니다. 하지만 실제로 그렇게 하는 경우는 드물었고, 다른 누구도 그렇게 하지 않았기에 그것으로 충분했습니다.

그 거래는 끝났습니다. AI가 어려운 언어들을 잘 다루게 되었기 때문에 끝난 것입니다.

어려운 언어들이 먼저 쉬워졌다

2년 전만 해도 GPT-4는 crate 이름을 환각(hallucination)하지 않고는 Rust 함수를 작성할 수 없었습니다. 2026년 4월까지 Claude Opus 4.7, GPT-5.5, Gemini 3.1, 그리고 DeepSeek V4는 불과 몇 주 간격으로 모두 SWE-bench Verified에서 80% 이상의 점수를 통과했습니다. AI 연구소들은 시스템 작업(systems work)에 최적화하고 있습니다. 즉, 계획 단계에서 동시성 버그(concurrency bugs), 경쟁 상태(race conditions), 그리고 아키텍처 결함(architectural flaws)을 식별하도록 하고 있습니다.

지난달 CtrlAltDwayne가 올린 트윗이 가장 명확한 설명을 제공했습니다:

"2026년 Rust를 사용해야 하는 가장 강력한 근거는 메모리 안전성(memory safety)이나 성능이 아닙니다. AI가 C++보다 Rust를 더 잘 작성한다는 점입니다. 컴파일러 피드백 루프(compiler feedback loop)가 매우 긴밀하여 모델이 실시간으로 스스로를 수정합니다. 모든 에러 메시지는 무료 학습 신호(training signal)가 됩니다. Rust는 그 중요성을 깨닫기 10년 전부터 우연히 AI 보조 개발(AI-assisted development)을 위해 설계되었습니다." via X.com

동일한 논리가 Go와 Swift에도 정도의 차이는 있지만 적용됩니다. 강력한 타입 시스템(type systems)과 빠른 컴파일 및 확인 루프(compile-and-check loops)는 에이전트(agents)에게 가장 긴밀한 반복 주기(iteration cycle)를 제공합니다. 인간에게 가장 어려웠던 시스템 언어들이 에이전트에게는 가장 쉬운 언어로 판명된 것입니다.

실제로 출시된 것들

단 한 분기 동안 무엇이 출시되었는지 살펴보십시오.

Microsoft는 TypeScript 컴파일러를 Go로 다시 작성했습니다. 가장 많이 사용되는 JavaScript의 상위 집합(superset)을 만드는 팀은 지난주 TypeScript 7.0 beta를 출시했습니다. 이는 10년 된 TypeScript 코드베이스를 Go로 포팅함으로써 6.0보다 약 10배 더 빨라졌습니다. Anders Hejlsberg의 논리는 다음과 같습니다. Go는 아주 적은 엔지니어링 비용으로 대부분의 성능 이점을 제공했습니다. 지구상에서 가장 큰 JS/TS 기업이 자사의 핵심 도구를 위해 더 어렵고 빠른 언어를 선택했으며, 그 이유는 그들 앞의 노력 계산법(effort calculus)이 바뀌었기 때문입니다.

Anthropic의 연구원인 Nicholas Carlini는 16개의 Claude 에이전트를 병렬로 운영하여 Rust로 프로덕션급 C 컴파일러를 작성하도록 지시했습니다. 100,000줄에 달하는 이 컴파일러는 x86, ARM, RISC-V에서 Linux 6.9를 부팅합니다. 또한 QEMU, FFmpeg, SQLite, PostgreSQL, Redis를 컴파일하며, Doom을 실행할 수 있습니다. 총 비용은 약 2,000회의 Claude Code 세션에 걸쳐 20,000달러가 조금 안 되는 수준이었습니다.

Rust로 작성된 C 컴파일러는 과거에는 대학원 학위 논문 주제였습니다. 이제는 더 이상 그렇지 않습니다.

The Rust Programming Language의 공동 저자이자 13년 경력의 Rust 베테랑인 Steve Klabnik은 Claude를 사용하여 2주 만에 Rue라는 새로운 시스템 언어를 구축했습니다. 약 70,000줄의 Rust 코드로 이루어져 있습니다. 그의 말에 따르면 다음과 같습니다:

"이번에 2주 동안 작업한 것이 지난번에 한두 달 동안 보낸 시간보다 더 진전이 있었습니다."

Ladybird 브라우저의 제작자이자 경력직 C++ 엔지니어인 Andreas Kling은 Claude Code와 Codex를 수백 개의 작은 프롬프트로 유도하여 Ladybird의 JavaScript 엔진을 C++에서 Rust로 2주 만에 포팅했습니다. 약 25,000줄의 Rust 코드로 작성되었으며, C++ 원본과 바이트 단위로 일치(byte-for-byte parity)하고, 65,000개 이상의 test262 및 Ladybird 테스트 전체에서 회귀(regression)가 전혀 없었습니다.

"직접 손으로 했다면 똑같은 작업을 하는 데 수개월이 걸렸을 것입니다."

이 중 그 어떤 것도 2024년에는 불가능했습니다. 2025년에는 간신히 가능했습니다. 2026년 초에는 흔한 일이 되고 있습니다.

"하지만 생태계가..."라는 말은 이제 그만

Python과 JavaScript를 지지하는 가장 강력한 논거는 결코 언어 그 자체였던 적이 없습니다. 그것은 바로 생태계였습니다: FastAPI, Django, PyTorch, React, Next.js, 그리고 npm의 400만 개 패키지들 말입니다. “우리 팀은 생태계가 이미 모든 문제의 90%를 해결해 두었기 때문에 며칠 만에 기능을 출시할 수 있습니다.” 지난 10년 동안 이것은 결정적인 요소였습니다. 하지만 지난 2년 동안 이 논거는 조용히 침식되어 왔습니다.

당신이 import pydantic을 할 때, 전체 검증 코어는 Rust 라이브러리입니다. pandas의 대안인 Polars는 Rust입니다. Hugging Face의 tokenizers는 Rust입니다. orjson도 Rust입니다. JetBrains의 2025년 Python 설문조사가 이러한 원격 측정(telemetry) 데이터를 포착했습니다: Python 바이너리 확장(binary extensions)을 위한 Rust 사용량이 1년 만에 27%에서 33%로 급증했습니다.

Python 생태계는 점점 더 Python 모자를 쓰고 있는 Rust 생태계가 되어가고 있습니다.

배관(plumbing) 작업도 동일한 궤적을 따르고 있습니다. 2022년 Charlie Marsh가 설립한 Astral은 ruff, uv, ty를 출시했습니다. 세 가지 모두 Rust로 작성되었으며, 세 가지 모두 월간 다운로드 수가 0에서 수억 건으로 급증했습니다. 2026년 3월 19일, OpenAI는 Astral을 인수했습니다. 내부적인 인수 명분은 uv가 Codex의 컴퓨팅 시간을 매주 약 100만 분 절약해 준다는 것이었습니다. 10주 전, Anthropic은 Bun(월간 다운로드 700만 건, GitHub 스타 8.9만 개)을 인수하며 이를 “AI 주도 소프트웨어 엔지니어링을 위한 필수 인프라”로 규정했습니다. Evan You의 VoidZero는 Rolldown-Vite를 출시했는데, 이는 Rust 기반 번들러(bundler)로 GitLab의 2.5분 빌드 시간을 메모리 사용량을 100배 줄이면서 40초로 단축시켰습니다.

Vercel의 제품 부사장(VP of Product)인 Lee Robinson은 다음과 같이 말했습니다: “우리는 JS로 최적화의 정점에 도달했습니다.”

“하지만 생태계가...”라는 주장에서 남은 것은 이것입니다: 당신이 Python과 JavaScript에서 임포트(import)하는 패키지들은 점점 더 당신이 사용할 수 없다고 들었던 언어로 작성된 코드의 래퍼(wrapper)가 되어가고 있습니다. 이제 당신은 해당 언어들로 직접 배포할 수 있으며, 래퍼는 점점 오버헤드(overhead)처럼 보이기 시작하고 있습니다.

포팅(port)할 수 있는데 왜 패치(patch)를 하나요?

과거의 오픈 소스 거래에는 양의 피드백 루프(positive feedback loop)가 있었습니다. 사용하기 쉽기 때문에 Python을 선택합니다. 의존성(dependency)에서 버그를 발견합니다. 그것을 수정합니다. 수정 사항을 업스트림(upstream)에 반영합니다. 그러면 생태계가 더 건강해집니다.

에이전트(Agents)는 특정한 방식으로 그 루프를 깨뜨렸습니다. 기여의 단위가 패치(patch)에서 포팅(port)으로 이동한 것입니다.

Flask의 제작자인 Armin Ronacher는 지난 1월, 에이전트를 사용하여 자신의 Rust 라이브러리인 MiniJinja를 Go 언어로 포팅했습니다. 이 작업은 총 10시간 동안 진행되었으며, 그중 3시간은 감독 하에(supervised), 7시간은 무인 상태로(unattended) 이루어졌습니다. 그의 실제 투입 시간은 45분이었습니다. API 비용은 60달러였습니다. 만약 언어를 넘나들며 라이브러리를 포팅하는 것이 45분짜리 작업이 된다면, 타인의 라이브러리에 수정 사항을 업스트림(upstreaming)해야 한다는 논거는 매달 약해질 것입니다. 포크(fork)할 수 있는데 왜 굳이 패치(patch)를 하겠습니까?

그의 개인적인 관찰은 다음과 같습니다:

"저에게 있어 가치는 코드에서 테스트와 문서로 이동하고 있습니다. 잘 짜여진 테스트 스위트(test suite)가 실제로는 코드보다 더 가치 있을 수도 있습니다."

PyPI와 npm을 구축했던 그 루프는 오늘날에도 여전히 작동합니다. 하지만 2028년에도 그것이 작동할지는 명확하지 않습니다.

이 논리가 깨지는 지점

이것이 모든 것을 완벽하게 설명하는 것은 아닙니다. 몇 가지 인정해야 할 사실이 있습니다.

첫째, 때로는 여전히 과거의 정답이 옳은 경우가 있습니다. Prisma는 Rust 쿼리 엔진을 제거하고 TypeScript/WASM 코어로 전환했습니다. 그 결과 번들 크기(bundle size)는 85% 감소했고, 쿼리 속도는 최대 3.4배 빨라졌습니다. 네이티브 Rust 바이너리는 서버리스 런타임(serverless runtimes)에 적합하지 않습니다. PyTorch는 여전히 딥러닝(deep-learning) 연구의 약 85%를 점유하고 있으며, 모델 가중치(model weights)는 그것을 어떤 언어로 감싸는지 상관하지 않기 때문에 이 상황은 변하지 않을 것입니다.

둘째, AI가 모든 시스템 언어(systems language)에서 동일하게 뛰어난 것은 아닙니다. Zig, Haskell, Gleam과 같은 규모가 작은 언어들은 (현재로서는) AI가 생성할 때 동일한 품질을 보여주지 못합니다.

학습 데이터(training data)가 모델이 당신을 도울 수 있는 범위를 결정합니다. Rust와 Go는 GitHub를 가득 채울 만큼 충분히 인기가 있었기에 복권에 당첨된 것과 같습니다. Zig, Haskell, Gleam은 여전히 그 곡선의 잘못된 쪽에 머물러 있습니다.

변화가 영구적인 이유

Python과 TypeScript에 대한 과거의 방어 논리는 사실 개발자 경험(developer experience)에 대한 방어였습니다. 해당 언어들은 인간의 아이디어와 출시된 제품 사이의 마찰을 최소화하기 때문에 선택되었습니다. Rust는 런타임(runtime)에서 결코 느리지 않았습니다. 다만 제품을 출시해야 하는 새벽 2시에 (개발 속도가) 느렸을 뿐입니다.

이제 에이전트(Agents)가 어려운 부분을 수행합니다.

인간의 역할은 “코드를 작성하는 것”에서 “시스템을 설계하고 결과물을 검토하는 것”으로 이동했습니다. 그러한 워크플로우(Workflow)에서는 Python의 인체공학적(Ergonomic) 이점이 분기마다 중요성이 줄어드는 반면, 더 어려운 언어의 런타임(Runtime) 이점은 서비스를 프로덕션(Production) 환경에서 운영하는 매일매일 복리로 쌓여갑니다.

Armin Ronacher는 그의 2월 에세이 <에이전트를 위한 언어 (A Language For Agents)>에서 다음과 같이 말했습니다:

“새로운 언어들이 성공할 수 있는 가장 큰 이유는 코딩 비용이 급격히 낮아지고 있기 때문입니다. 그 결과, 생태계의 폭은 점점 덜 중요해지고 있습니다.”

지난 20년 동안의 언어 선택은 단 하나의 제약 조건에 의해 형성되었습니다. 바로 인간이 코드를 작성하며, 인간은 저수준 언어(Low-level languages)에 느리다는 점입니다. 이제 그 제약 조건은 사라졌습니다. Stack Overflow의 2025년 설문조사에 따르면 Rust가 72%로 10년 연속 가장 존경받는 언어로 선정되었으며, Gleam이 70%, Elixir가 66%, Zig가 64%를 기록했습니다. 선호도는 항상 존재해 왔으며, 이제 도구(Tooling)가 마침내 그 선호도를 따라잡은 것입니다.

Karpathy는 2월에 더 넓은 관점을 다음과 같이 제시했습니다:

“LLM(대규모 언어 모델)은 소프트웨어의 제약 조건 지형 전체를 완전히 바꿉니다. C를 Rust로 포팅하려는 움직임이 가속화되는 것 등에서 이미 이러한 징후를 볼 수 있습니다.” 그는 또한 “Rust조차도 타겟 언어로서 LLM에 최적화된 상태는 전혀 아니다”라고 덧붙였습니다.

오늘날의 승자는 오프닝 무브(Opening move)일 뿐이며, 엔드게임(Endgame)은 훨씬 더 먼 미래에 있습니다.

새로운 체제에 대한 가장 명확한 진술은 4월 24일 X(구 트위터)의 @RealRichomie로부터 나왔습니다:

“프로그래밍의 미래는 인간에게 가장 쉬운 언어가 아닐 것입니다. 에이전트(Agents)에게 가장 쉬운 언어가 될 것입니다. 우리는 엔지니어들이 Rust(또는 Tauri)를 단 한 줄도 몰랐던 상태에서 Mac 앱을 출시했습니다. 결과는: 크기는 약 1/10 수준... 매우 높은 성능. 에이전트가 새로운 프로그래머입니다.”

팀원 중 누구도 알지 못하는 언어로, Electron 버전의 10분의 1 크기로, 런타임 성능은 더 빠르게 앱을 출시했습니다. 인간은 그 결과에 도달하기 위해 Rust를 배울 필요가 전혀 없었습니다.

당신이 시작할 다음 프로젝트가 반드시 Python을 기본값으로 선택할 필요는 없습니다.