AI가 코드를 작성한다면, 왜 Python을 쓰는가?

• AI 보조 개발로 언어 선택 기준이 사람의 작성 속도에서 AI의 수정 능력과 런타임 성능으로 이동함
• 2026년 Claude Opus 4.7, GPT-5.5, Gemini 3.1, DeepSeek V4가 SWE-bench Verified 80% 를 넘김
• Rust는 컴파일러 피드백 루프가 AI의 자기수정을 돕고, Go와 Swift도 빠른 타입 검사로 에이전트에 유리함
• TypeScript 컴파일러의 Go 포팅, Rust 기반 C 컴파일러, Rue, Ladybird JS 엔진 포팅처럼 대규모 전환이 이미 진행 중
• Python·JavaScript 생태계도 Rust 도구와 래퍼 의존이 커지지만, Prisma·PyTorch·소규모 언어 같은 예외는 남아 있음

AI 보조 개발이 바꾼 언어 선택 기준

• 새 프로젝트의 기본 선택지는 오랫동안 Python이나 TypeScript였음
  • 생태계가 크고, 채용 풀이 넓으며, 빠르게 데모를 만들 수 있었기 때문
  • Rust, Go, C++는 10~100배 성능을 줄 수 있었지만 학습 기간, 작은 인재 시장, 까다로운 빌드 시스템이 비용으로 작용함
  • 그래서 먼저 Python 버전을 출시하고 “나중에 성능을 개선하겠다”고 했지만, 실제로는 그대로 유지되는 경우가 많았음
• AI가 어려운 언어를 다루기 시작하면서 이 거래가 흔들림
  • 언어 선택에서 “사람이 빨리 작성할 수 있는가”보다 “AI가 잘 작성·수정할 수 있는가”와 런타임 성능의 비중이 커짐

어려운 언어가 AI에게 먼저 쉬워짐

• 2년 전 GPT-4는 Rust 함수 작성 중 존재하지 않는 crate 이름을 지어내는 수준이었음
• 2026년 4월에는 Claude Opus 4.7, GPT-5.5, Gemini 3.1, DeepSeek V4가 몇 주 간격으로 SWE-bench Verified에서 80%를 넘김
• 연구소들은 시스템 작업을 명시적으로 최적화하는 중
  • 동시성 버그
  • 경쟁 상태
  • 계획 단계에서 발견되는 아키텍처 결함
• CtrlAltDwayne은 Rust가 2026년에 강한 이유를 메모리 안전성이나 성능보다 컴파일러 피드백 루프에서 찾음
  • AI가 C++보다 Rust를 더 잘 작성함
  • Rust의 컴파일러 오류 메시지가 모델의 실시간 자기수정을 돕는 신호가 됨
  • Rust는 AI 보조 개발에 맞게 10년 먼저 “우연히 설계된” 언어처럼 작동함
• 같은 논리는 정도 차이는 있지만 Go와 Swift에도 적용됨
  • 강한 타입 시스템과 빠른 컴파일·검사 루프가 에이전트에게 촘촘한 반복 사이클을 제공함
  • 사람에게 어려웠던 시스템 언어가 에이전트에게는 오히려 쉬운 대상이 될 수 있음

실제로 출시된 사례들

• Microsoft의 TypeScript 컴파일러 Go 포팅

  • Microsoft는 TypeScript 7.0 beta를 출시하며 10년 된 TypeScript 코드베이스를 Go로 포팅함
  • TypeScript 7.0 beta는 6.0보다 대략 10배 빠름
  • Anders Hejlsberg의 판단에 따르면 Go는 엔지니어링 비용의 일부만으로 대부분의 성능 이점을 제공함
  • 가장 큰 JS/TS 조직 중 하나가 대표 도구에 더 어렵고 빠른 언어를 선택할 만큼 노력 대비 효과의 계산이 바뀜

• Claude 에이전트 16개로 만든 Rust 기반 C 컴파일러

  • Anthropic 연구자 Nicholas Carlini는 16개의 Claude 에이전트를 병렬로 조율해 Rust로 프로덕션 C 컴파일러를 작성함
  • 규모는 10만 줄이며, x86·ARM·RISC-V에서 Linux 6.9를 부팅함
  • QEMU, FFmpeg, SQLite, PostgreSQL, Redis를 컴파일하고 Doom도 실행함
  • 총비용은 거의 2,000개의 Claude Code 세션에 걸쳐 2만 달러 미만이었음
  • Rust로 작성한 C 컴파일러는 과거에는 대학원 논문급 작업이었지만, 이제 예외적인 작업만은 아니게 됨

• Steve Klabnik의 Rue

  • The Rust Programming Language 공동 저자이자 13년차 Rust 베테랑인 Steve Klabnik은 Claude와 함께 Rue라는 새 시스템 언어를 2주 만에 만듦
  • 결과물은 대략 7만 줄의 Rust였음
  • 그는 이번 2주 작업이 이전에 한두 달 들였던 시도보다 더 멀리 갔다고 밝힘

• Ladybird JavaScript 엔진의 Rust 포팅

  • Ladybird 브라우저 창시자이자 C++ 엔지니어인 Andreas Kling은 Claude Code와 Codex에 수백 개의 작은 프롬프트를 주며 Ladybird의 JavaScript 엔진을 C++에서 Rust로 2주 만에 포팅함
  • 결과는 대략 2만 5천 줄의 Rust였고, C++ 원본과 바이트 단위 동등성을 달성함
  • test262와 Ladybird 테스트를 합쳐 6만 5천 개 이상에서 회귀가 없었음
  • 같은 작업을 손으로 했다면 여러 달이 걸렸을 것이라고 밝힘

약해지는 “생태계” 논리

• Python과 JavaScript의 가장 강한 논리는 언어 자체보다 생태계였음
  • FastAPI, Django, PyTorch, React, Next.js, npm의 400만 패키지 같은 기반이 있었음
  • 팀이 기능을 며칠 만에 출시할 수 있었던 이유는 생태계가 문제의 90%를 이미 해결했기 때문
• 이 장점은 지난 10년간 결정적이었지만, 최근 2년 사이 약해지고 있음
• Python 생태계 내부도 점점 Rust 기반 구성요소에 의존함
  • pydantic의 전체 검증 코어는 Rust 라이브러리임
  • pandas 대안인 Polars는 Rust로 작성됨
  • Hugging Face tokenizers와 orjson도 Rust임
  • JetBrains 2025 Python survey에 따르면 Python 바이너리 확장에서 Rust 사용률은 1년 만에 27%에서 33% 로 증가함
• 개발 도구 기반도 같은 방향으로 움직임
  • Charlie Marsh가 2022년 설립한 Astral은 Rust로 작성된 ruff, uv, ty를 출시했고, 세 도구의 월간 다운로드 수는 0에서 수억 회로 증가함
  • 2026년 3월 19일 OpenAI가 Astral을 인수했으며, uv가 Codex의 컴퓨트 시간을 주당 약 100만 분 절약한다고 봄
  • 10주 전에는 Anthropic이 Bun을 인수함
  • Bun은 월간 다운로드 700만, GitHub 스타 8만 9천을 기록했고, “AI 주도 소프트웨어 엔지니어링의 필수 인프라”로 불림
  • Evan You의 VoidZero는 Rolldown-Vite를 출시함
  • 이 Rust 번들러는 GitLab의 2.5분 빌드를 40초로 줄이고 메모리 사용량을 100분의 1로 낮춤
• Vercel 제품 부문 부사장 Lee Robinson은 “JS에서 최적화의 정점에 도달했다”고 말함
• Python과 JavaScript에서 가져다 쓰는 패키지는 점점 더, 직접 출시하기 어렵다고 여겨졌던 언어로 작성된 코드의 래퍼가 되고 있음
  • 이제 그런 언어로 직접 출시할 수 있다면 래퍼는 오버헤드처럼 보이기 시작함

패치보다 포팅이 쉬워지는 변화

• 기존 오픈소스 생태계의 선순환은 패치 중심이었음
  • Python이 쉬워서 선택함
  • 의존성 버그를 발견함
  • 수정하고 upstream에 반영함
  • 생태계가 더 건강해짐
• 에이전트는 기여의 단위를 패치에서 포팅으로 옮기는 중
• Flask 창시자 Armin Ronacher는 1월에 에이전트를 사용해 Rust 라이브러리 MiniJinja를 Go로 포팅함
  • 전체 실행 시간은 10시간이었음
  • 이 중 3시간은 감독했고 7시간은 무인으로 진행됨
  • 실제 사람 시간은 45분이었음
  • API 비용은 60달러였음
• 라이브러리를 언어 간 포팅하는 일이 45분짜리 작업이 되면, 다른 사람의 라이브러리에 수정사항을 올리는 논리는 약해짐
  • “패치할 수 있는데 왜 포크하지 않는가”가 아니라 “포크할 수 있는데 왜 패치하는가”가 됨
• Armin Ronacher는 가치가 코드에서 테스트와 문서로 이동하고 있다고 봄
  • 좋은 테스트 스위트가 코드보다 더 가치 있을 수 있음
• PyPI와 npm을 만든 루프는 지금도 작동하지만, 2028년에도 그대로 작동할지는 명확하지 않음

여전히 남는 예외

• 모든 변화가 한 방향으로만 흐르지는 않음
• 어떤 경우에는 여전히 기존 선택이 맞음
  • Prisma는 Rust query engine을 제거하고 TypeScript/WASM 코어로 옮김
  • 번들 크기는 85% 감소했고, 쿼리는 최대 3.4배 빨라짐
  • 네이티브 Rust 바이너리는 서버리스 런타임에 불리함
• PyTorch는 딥러닝 연구의 약 85% 를 여전히 차지함
  • 모델 가중치는 어떤 언어로 감싸는지에 영향을 받지 않기 때문에 이 위치가 쉽게 바뀌지는 않음
• AI가 모든 시스템 언어를 똑같이 잘 다루는 것은 아님
  • Zig, Haskell, Gleam 같은 더 작은 언어는 현재 AI 생성 품질이 Rust나 Go와 같지 않음
  • 훈련 데이터가 모델이 도울 수 있는 범위를 결정함
  • Rust와 Go는 GitHub에 충분히 많이 올라와 있어 유리한 위치에 있음
  • Zig, Haskell, Gleam은 아직 그 곡선의 불리한 쪽에 있음

왜 이 변화가 지속될 수 있는가

• Python과 TypeScript의 기존 방어 논리는 사실 개발자 경험의 방어였음
  • 사람의 아이디어와 출시 제품 사이의 마찰을 최소화했기 때문에 선택됐음
  • Rust는 런타임에서 느린 언어가 아니라, 새벽 2시에 출시해야 할 때 느린 언어였음
• 이제 에이전트가 어려운 부분을 맡기 시작함
  • 사람의 역할은 “코드 작성”에서 “시스템 설계와 출력 검토”로 이동함
  • 이 흐름에서는 Python의 문법적 편의가 분기마다 덜 중요해짐
  • 더 어려운 언어의 런타임 이점은 서비스가 프로덕션에서 실행되는 매일 누적됨
• Armin Ronacher는 2월 글 A Language For Agents에서 코딩 비용이 급격히 내려가며 생태계의 폭이 덜 중요해진다고 봄
• 지난 20년간의 언어 선택은 “사람이 코드를 작성하고, 사람은 저수준 언어에서 느리다”는 제약을 중심으로 형성됐음
  • 이 제약이 사라지기 시작함
• Stack Overflow 2025 설문에서 Rust는 10년 연속 가장 존경받는 언어였고 72% 를 기록함
  • Gleam은 70%
  • Elixir는 66%
  • Zig는 64%
  • 선호는 이미 있었고, 도구가 이제 그 선호를 따라잡고 있음

에이전트에 쉬운 언어로 가는 다음 단계

• Karpathy는 2월에 LLM이 소프트웨어의 제약 지형 전체를 바꾼다고 말함
  • C에서 Rust로 포팅하는 흐름에서 그 조짐이 보인다고 봄
  • Rust조차 LLM의 대상 언어로는 최적에 가깝지 않다고 덧붙임
• 현재의 승자는 시작점일 뿐이며, 최종 형태는 더 멀리 있을 수 있음
• @RealRichomie는 4월 24일에 프로그래밍의 미래가 사람에게 가장 쉬운 언어가 아니라 에이전트에게 가장 쉬운 언어로 갈 것이라고 말함
  • 엔지니어들이 Rust나 Tauri를 전혀 몰랐던 상태에서 Mac 앱을 출시함
  • 결과물은 Electron 버전 대비 약 10분의 1 크기였고, 런타임 성능이 높았음
  • 사람은 Rust를 배울 필요 없이 그 결과에 도달함
• 다음 프로젝트가 반드시 Python을 기본값으로 삼을 필요는 없음