AI가 코드를 쓴다면 왜 Python을 쓰는가 — 검증 비용이 언어를 다시 고른다

Python이 지난 10년간 1위였던 이유는 “사람이 빠르게 쓰고 빠르게 읽을 수 있기 때문”이었다. 그런데 이제 사람이 코드를 거의 쓰지 않고, 검토할 때 컴파일러가 곁에 있느냐 없느냐가 시간당 비용을 결정한다면, 그 1위의 근거는 그대로 유지되는가.

도입 — 다시 시작된 언어 전쟁

2026년 5월 1일, Medium에 올라온 한 편의 짧은 글이 Hacker News의 1면을 점령했다. 제목은 “AI가 너의 코드를 쓴다면 왜 Python을 쓰는가(If AI writes your code, why use Python?)”. 글 자체의 분량은 길지 않다. 핵심 주장은 단 한 줄로 요약 가능하다. “지난 10년간 빠르게 출하하는 것(fast-to-ship)이 빠르게 실행하는 것(fast-to-run)을 이겼다. 이제는 아니다(For the last decade, fast-to-ship beat fast-to-run. Not anymore).” 그러나 댓글은 922개가 달렸고, 종합 점수는 868점에 도달했다. 단일 블로그 글에 대한 반응으로는 이례적인 규모다.

이 글이 신경을 건드린 지점은 단순하다. Python이라는 언어가 지금까지 받았던 모든 변호가 — 가독성, 표현력, 학습 곡선, 풍부한 라이브러리 — 사실은 “사람이 코드를 쓴다”는 전제 위에서만 성립한다는 사실을 정면으로 들이밀었기 때문이다. 만약 그 전제가 흔들린다면, 즉 ChatGPT Codex나 Claude Code, Cursor 같은 에이전트가 새 코드의 70～90%를 만들어 내는 것이 평범한 일이 된다면, Python의 우위는 어디에 남는가.

문제의 원문 글이 마이크로소프트의 TypeScript 컴파일러 Go 이전 사건과 Discord의 Rust 채택, 그리고 Python 생태계 전반의 Rust 의존(uv, ruff, polars, pydantic-core 등) 같은 사례를 근거로 든 것이 우연이 아니다. 그것들은 모두 같은 방향을 가리키는 데이터 포인트들이다. “엔지니어 한 명을 1주일 더 행복하게 하는 비용”보다 “한 번 정착한 시스템을 5년 동안 운영하는 비용”이 다시 더 무거워졌다는 것. 그리고 그 5년 비용에는 이제 “AI가 만들어 낸 코드를 검증하는 비용”이라는 항목이 추가되었다는 것.

흥미로운 점은, 이 주장 자체가 새롭지 않다는 사실이다. 정적 타입 대 동적 타입 논쟁은 30년 묵은 논쟁이고, “Python은 진짜 production이 아니다”라는 주장도 새롭지 않다. 새로운 것은 그것이 원격 사용자 922명의 키보드를 동시에 두드리게 만든 맥락이다. 그 맥락은 한 줄로 요약된다. AI가 시간당 코드 양을 한 자릿수 늘렸기 때문에, 코드 한 줄당 검증 비용이 시스템 비용의 지배적 항목이 되었다. 그리고 검증 비용은 언어가 결정한다.

본문 1 — 원문이 말한 것: 트레이드오프의 축이 바뀌었다

원문의 논지를 정확히 정리해 보자. 글쓴이 NMitchem은 세 가지 관찰에서 출발한다.

첫째, Python의 진짜 정체는 이미 Rust로 갈아입었다. uv는 Rust로 쓰인 패키지 매니저다. ruff는 Rust로 쓰인 린터·포매터다. polars는 Rust로 쓰인 데이터프레임 라이브러리다. pydantic-core는 Rust로 쓰인 검증 코어다. ML 추론 엔진들도 점점 더 Rust로 옮겨가고 있다. 즉, “Python 생태계가 점점 더 Python 모자를 쓴 Rust 생태계가 되어 가고 있다(The Python ecosystem is increasingly a Rust ecosystem wearing a Python hat)“는 것이다.

둘째, TypeScript 진영도 같은 방향을 향한다. 마이크로소프트는 2025년에 TypeScript 컴파일러를 Go로 다시 쓰기 시작했다고 발표했다. 세상에서 가장 큰 TypeScript 사용자가 자기네 컴파일러를 다른, 더 어려운 언어로 옮겼다. 이유는 명확하다. 컴파일 속도가 Type-aware 도구 체인 전체의 속도를 결정하는데, JS/TS로 쓰인 컴파일러로는 그 속도를 더 끌어올릴 여지가 없었기 때문이다. 트레이드오프의 산수가 바뀌었다는 신호다.

셋째, Discord의 사례. Discord는 2020년에 자사의 Read States 서비스를 Go에서 Rust로 옮겨 GC 정지(GC pause)를 거의 영(0)에 가깝게 만들었다. 이것은 옛날 일이지만, 같은 회사가 2024년 이후 Rust로 새 서비스를 점점 더 많이 짓고 있다는 것이 원문의 포인트다. “엔지니어가 Rust를 배우는 비용”이 한 번 지불하면 끝나는 일회성 투자라면, “GC가 매 요청마다 50ms씩 잡아먹는 비용”은 트래픽이 늘수록 복리로 늘어나는 만성 지출이다.

여기까지가 원문의 사실 기반이다. 그 위에 NMitchem이 얹은 결론은 두 가지로 나뉜다. (1) Python과 TypeScript의 옛 변호 — “개발자 경험이 좋아서” — 는 사실 “사람이 직접 쓸 때만 좋다”는 뜻이었고, AI가 키보드를 잡으면 그 변호의 효력이 소멸한다. (2) 따라서 새 프로젝트는, 특히 장기 운영을 전제로 하는 새 프로젝트는, Rust 또는 Go 같은 언어로 시작하는 것이 합리적이다. 글의 마지막 일화는 그 결론을 미니어처로 보여준다. 글쓴이는 자신이 Rust를 모르는 팀과 함께 AI에게 Rust 코드를 짜게 해, 같은 기능을 Electron으로 짰을 때보다 1/10 크기에, 더 빠른 런타임을 가진 앱을 출시했다고 적었다. “사람들은 Rust를 배울 필요조차 없었다(The humans never had to learn Rust to get there).”

이 결말 일화가 댓글창의 가장 격렬한 반응을 끌어냈다. j_w는 이렇게 받아쳤다. “그래, 그리고 아무도 그 앱을 알지도 쓰지도 않으니, 그건 중요하지 않다. 아무도 쓰지 않을 제품을 일화로 드는 건 글을 마무리하는 좋은 방법이 아니다(Yeah and nobody knows or cares about the app, so it doesn’t matter).” vhantz는 더 짧게 잘랐다. “좋다. 멀지 않은 미래에 이걸 다시 돌아보자(Let’s look back on this not too far in the future).” 두 댓글은 같은 의심을 가리킨다. AI가 “낯선 언어로 동작하는 코드”를 만들어 줄 수는 있지만, 그 코드를 5년 뒤에 디버깅하는 일은 여전히 사람의 몫이고, 그 사람이 언어를 모르면 그 코드는 결국 폐기 비용으로 남는다.

원문의 주장은 그래서 둘로 쪼개 평가해야 한다. “Python의 옛 변호가 약해졌다”는 명제는 거의 모든 댓글이 동의한다. “그러므로 Rust로 새로 시작하는 것이 정답”이라는 처방은 의견이 갈린다.

본문 2 — HN의 결: 세 갈래의 답

HN 댓글창 922개를 단순화하면, AI 시대 언어 선택에 관한 답은 세 갈래로 갈라진다. 각 갈래가 가진 합리성과 한계를 정확히 짚어 보자.

첫 번째 갈래: “Python은 여전히 정답이다 — 학습 데이터와 가독성 때문에.”

bryanrasmussen은 LLM을 쓸 때의 세 가지 규칙을 이렇게 정리한다. (1) 본인이 잘 아는 언어를 써라, 읽기 쉬워야 추가 작업이 가능하다. (2) 학습 데이터가 큰 언어를 써라, LLM이 더 효율적이다. (3) 읽기 쉬운 언어를 써라. “Python은 학습 데이터가 크고 읽기도 쉽다(python has a large training set and it is easy to read)“는 결론이다. _boffin_도 같은 맥락을 짧게 짚는다. “AI로는 brainfuck도 쓸 수 있지만, Python과 같은 결과는 안 나온다(I could write in brainfuck with ai, but I presume, wouldn’t get the same results than if going with python).” 이 갈래의 핵심은, AI 모델 자체가 인터넷 코드를 학습한 결과물이고, 그 코드의 절대량에서 Python이 압도적이라는 것이다.

이 갈래의 가장 강력한 변호는 luodaint가 댓글로 정리했다. “에이전트가 90%의 코드를 만들어도, 모든 diff는 결국 내 리뷰 큐에 들어온다. Python의 가독성은 쓸 때의 장점이 아니라 리뷰할 때의 장점이다. 내가 코드를 읽고, 이해하고, 의도대로 동작하는지 판단해야 한다. 그게 나머지 10%이고, 결정적인 10%다(Code readability of Python isn’t an advantage during write; it’s an advantage while reviewing).” 즉, 원문이 “사람은 키보드에서 손을 뗀다”고 가정한 데 반해, 이 갈래는 “사람은 리뷰어로 자리만 옮긴다”고 본다. 그리고 리뷰어 역할은 가독성에 대한 의존을 줄이지 않고, 오히려 늘린다.

두 번째 갈래: “이제 정적 타입이 이긴다 — 컴파일러가 검증을 떠맡으니까.”

pshirshov의 댓글이 이 갈래의 정수다. “컴파일러나 타입 시스템에 더 많이 떠넘길 수 있을수록, 피드백 루프가 짧아지고 에이전트가 더 잘 동작한다. 엄격하게 강제되는 정적 타입이 없다는 점이, Python에서 에이전트가 일찍 실패하게 만드는 원인이다. 내 의견으로는 Rust와 Scala가 에이전틱 워크플로의 가장 좋은 타깃이다(Rust and Scala are the best targets for agentic flows).” slashdev는 더 단언적이다. “정적 대 동적 언어 논쟁은 결정적으로 끝났고, 정적이 이겼다(The static vs dynamic language debate is decisively over and static has won).” 그는 자기 회사에서 50명의 엔지니어가 거의 100% Rust로 일하고, 자기는 더 이상 손으로 코드를 쓰지 않는다고 적었다. AI가 작년만 해도 borrow checker를 잘 다루지 못했지만, 지금은 자기보다 까다로운 lifetime 이슈를 더 잘 다룬다는 관찰도 곁들인다.

bob1029는 동일한 논리를 .NET 사례로 옮긴다. “내가 가진 약 50MB 분량의 .NET 코드베이스 모음에서 C#의 강력한 타입이 모든 것을 레일 위에 올려놓는 핵심 척추 역할을 한다. 코드 편집은 몇 달 동안 무결했고, 한 번에 20개 파일을 건드리는 apply_patch가 성공적으로 작동했다. LLM의 코드 편집 성능은 타입 시스템의 엄격함을 보정하고 나면 거의 언어 무관한 것 같다. 더 정확히 말하면, 컴파일 시점에 얼마나 유용한 정보가 돌아오는가의 문제다(LLM code editing performance might be mostly language agnostic once we compensate for the strictness of the type system).” 이것은 매우 중요한 통찰이다. 모델 자체의 능력 차이가 아니라, “에이전트가 자기 일을 검증할 수 있는 신호의 양”이 결과를 가른다는 것. 컴파일 에러 메시지는 단위 테스트보다 빠르고, 단위 테스트보다 비용이 적게 든다. p4bl0의 표현으로는 “사람이 100% 교정하지 않을 코드를 자동 생성한다면, 컴파일러가 가능한 한 많은 오류를 잡을 수 있는 가장 안전한 언어를 쓰는 게 항상 낫다(it’s always better to use the safest possible language so that the compiler can catch most of the errors).”

세 번째 갈래: “사람의 친숙도가 모든 것을 이긴다.”

fbrncci의 댓글이 이 갈래의 표상이다. “왜 Python인가? 10년 넘게 써 왔고, 디버그할 줄 알며, 에이전트가 거대한 발등 찍기로 끝날 무언가를 쓸 때 10초 안에 냄새를 맡을 수 있기 때문이다. 다른 언어로는 그렇지 않다 — 다시 많이 배워야 한다. 그래서 나는 Python을 선호한다. AI가 코드를 쏟아내는 속도에서도 어느 정도 통제 감각이 남는다. Go나 Rust로 했다면 ‘AI 보조 프로그래밍’보다는 ‘vibecoding’에 가까웠을 것이다(then it would feel more like ‘vibecoding’ than AI assisted programming, just yolo the whole product).” 이 시각은 첫 번째 갈래와 비슷해 보이지만, 강조점이 다르다. Python의 객관적 우위가 아니라, 개인의 누적 경험이 검증 비용을 좌우한다는 주장이다. fxj의 표현으로는 “당신이 LLM이 만든 것을 이해하려 할 때 삶을 가장 덜 복잡하게 만들어 주는 언어를 써야 한다(use the language that you know best to make your life as uncomplicated as possible).”

이 세 번째 갈래는 종종 무시되지만 가장 현실적이다. 한 명의 개발자가 같은 사양의 Rust 코드와 Python 코드를 검토할 때, Rust가 객관적으로 더 안전하더라도, 그 사람이 lifetime을 처음 본다면 검토 시간은 10배가 된다. 그 시간 동안 다른 일을 못 한다. 검증 비용은 언어의 속성이 아니라, 언어와 사람의 곱이다.

세 갈래를 종합하면, AI 시대의 언어 선택은 단일한 정답이 없다. 다만 평가 축이 셋이라는 점은 분명하다. (1) AI가 그 언어를 얼마나 잘 쓰는가 — 학습 데이터 양과 모델의 도메인 친숙도. (2) 그 언어가 AI의 출력을 얼마나 잘 검증해 주는가 — 타입 시스템, 컴파일러, 정적 분석의 양. (3) 그 언어를 사람이 얼마나 잘 읽고 디버그할 수 있는가 — 팀의 누적 경험. Python은 (1)에서 압도적, (3)에서 매우 강력, (2)에서 약하다. Rust는 (2)에서 압도적, (1)에서 점점 강력해지는 중, (3)에서는 팀에 따라 0～100. Go는 세 축에서 모두 7～8점쯤. TypeScript는 (1)이 강하고 (2)가 중간, 하지만 런타임 에러 표면이 여전히 크다.

본문 3 — 도메인이 결정한다: 새 프로젝트는 무엇으로 시작할 것인가

세 가지 평가 축을 받아들인다고 해도, 새 프로젝트를 시작할 때 어떤 언어를 고를 것인가는 여전히 의사결정이 필요하다. 도메인별로 정리하는 것이 가장 실용적이다.

ML/데이터 도메인 — Python의 압도가 단기간에 안 깨진다. rchowe의 댓글이 정확하다. “Python은 특히 AI/ML 쪽에서 Rust보다 훨씬 더 성숙한 생태계를 가졌다. 어떤 ML 알고리즘을 한다는 Rust crate를 발견했지만 정확하지 않았다. Claude로 대체품을 만들 수 있긴 했지만(Python has a much more mature ecosystem than Rust, especially for AI/ML stuff).” 라이브러리 lock-in은 언어 우위가 아니라 데이터 무게의 문제다. Hugging Face, scikit-learn, PyTorch, JAX, polars, ray, mlflow 같은 도구들의 호환성 표면은 Python이다. 새로운 데이터 파이프라인이 Rust로 시작되어도, 두 번째 컴포넌트가 Python을 부르는 순간 경계가 생기고, 경계는 비용이다. 이 도메인에서는 “Python으로 시작하되, hot path만 Rust로 떼어 낸다”는 패턴이 여전히 우세하다. polars와 pydantic-core가 정확히 그 패턴이다.

시스템/인프라 도메인 — Rust 또는 Go가 디폴트가 되어 가는 중. 새로 쓰이는 데이터베이스, 런타임, 프록시, 오케스트레이터 들의 거의 전부가 Rust나 Go로 시작된다. Cloudflare의 Pingora, ScyllaDB의 새 모듈들, Tigerbeetle, Materialize, Restate, dragonfly까지. 이 도메인의 특징은 “오류 한 건의 비용이 매우 크다”는 것이고, 이는 컴파일러 검증의 가치가 가장 큰 도메인이라는 뜻이다. AI가 인프라 코드를 쓰는 비중이 늘어나면, 이 도메인의 Rust 점유율은 더 빨라질 것이다. slashdev의 회사 사례 — 50명이 거의 100% Rust로 작업, 손으로 코드를 쓰지 않음 — 가 시스템 도메인의 미리 보기에 가깝다.

웹 백엔드 — TypeScript와 Go의 경쟁이 새로 시작된다. 마이크로소프트가 TypeScript 컴파일러를 Go로 옮긴 사건은 상징이다. fulafel의 댓글은 그 신호를 정확히 읽는다. “내 경험상 Go가 TS나 JS보다 어렵다고 보는 사람은 거의 없다. TS는 꽤 복잡하고 JS는 발등 찍기 범위다(Go is absolutely an easier/simpler language than JS/TS).” 동시에, 같은 언어로 프론트와 백엔드를 쓴다는 TypeScript의 옛 변호는 여전히 강력하다. 따라서 이 도메인은 “팀에 프론트엔드와 백엔드 코드 공유 비중이 큰가”가 결정 변수다. 그게 크면 TypeScript, 작으면 Go. 새로 시작한다면 어느 쪽도 합리적이다.

CLI/데스크톱/임베디드 — Rust가 점점 디폴트. ripgrep, fd, bat 같은 CLI는 이미 Rust 표준이 되었고, Tauri는 Electron의 자리를 점점 빼앗고 있다. 원문의 마지막 일화는 이 도메인에서 가장 잘 들어맞는다. 메모리, 바이너리 크기, 시작 시간이 사용자 경험에 직접 닿는 도메인이기 때문이다. AI가 잘 안 쓰는 부분(예: unsafe Rust, 복잡한 lifetime)은 여전히 작은 표면이고, 일반 CLI 코드 영역에서는 모델이 충분히 잘 한다.

스크립트/일회성 자동화 — Python이 영구히 1등. 이 도메인의 특징은 “검증 비용이 거의 0”이라는 것이다. 한 번 돌리고 버리는 코드는 컴파일러의 보호가 필요 없다. AI가 30초 만에 만들어 주고 곧장 실행해 보면 끝이다. scotty79가 “Rust를 시도해 봤지만 개발이 너무 느리게 느껴졌다(I tried using Rust but the development just seemed too slow)“고 말한 영역이 정확히 이쪽이다. 일회성 영역에서 Python의 위치는 흔들리지 않는다.

이 도메인 매핑이 시사하는 바는, 원문이 제시한 “Rust가 새로운 디폴트”라는 명제가 절반만 맞다는 것이다. 시스템·CLI·임베디드에서는 그 말이 빠르게 진실이 되어 간다. 그러나 ML과 일회성 스크립트에서는 그 말이 향후 5년 안에도 거짓일 가능성이 크다. 웹 백엔드와 데스크톱은 전환 중이다. 즉, AI 시대의 언어 선택은 “Python이냐 Rust냐”가 아니라 “언어 폴리글랏(polyglot)이 더 빨리, 더 깊이 진행된다”는 것이다. 한 명의 개발자가 5년 전에는 Python+JavaScript 두 언어로 일했다면, 지금은 Python+TypeScript+Go+Rust 네 언어를 동시에 다루는 것이 평범해진다. 그것이 가능한 이유는 정확히 AI가 언어 전환 비용을 낮추기 때문이다. fxj의 농담 — “재미 삼아 LISP, COBOL, FORTRAN, APL, J 같은 걸 배워 봐도 좋다” — 은 전혀 농담이 아닐 수 있다. 모델이 그 모든 언어를 알고 있다면, 사람이 깊이 알아야 할 언어의 수는 늘어나는 게 아니라 줄어들 수도 있다.

결론

리드 질문으로 돌아가자. Python의 1위는 그대로 유지되는가. 답은 “유지되지만 좁아진다”이다.

Python이 1위를 지키는 영역은 여전히 두 곳이다. 첫째, ML과 데이터 도메인. 라이브러리 무게가 언어 자체보다 무거운 곳에서 Python의 lock-in은 깨지지 않는다. 둘째, 일회성 자동화와 스크립트. 검증 비용이 0에 가까운 영역에서 컴파일러의 보호는 사치다. 이 두 영역에서 Python은 향후 10년도 1위일 것이다.

그러나 그 외 모든 영역 — 시스템, 인프라, CLI, 임베디드, 새로 짓는 웹 백엔드 — 에서 Python의 점유율은 줄어든다. 그 자리를 채우는 것은 Rust(검증 우위) 또는 Go(단순함과 컴파일 속도 우위)다. TypeScript는 프론트엔드를 지키지만, 백엔드에서는 Go에게 점차 밀린다. 이 변화의 동력은 한 가지다. AI가 코드 출하량을 한 자릿수 늘렸기 때문에, 시스템 비용에서 검증 비용이 차지하는 비중이 한 자릿수 늘었고, 검증 비용은 컴파일러가 결정한다.

원문이 놓친 한 가지는 사람의 역할이다. luodaint가 정확히 짚었듯이, 사람은 키보드에서 손을 떼는 것이 아니라 리뷰어 자리로 옮긴다. 그리고 리뷰어 자리에서는 가독성이 줄어드는 것이 아니라 늘어난다. 그래서 미래의 언어는 “AI가 잘 쓰면서 동시에 사람이 잘 읽는” 언어가 우세할 것이다. 그 두 조건을 모두 만족시키는 후보는 — 학습 데이터가 풍부하고 컴파일러가 강력하고 문법이 단순한 언어 — 현재로서 Go가 가장 가깝고, Rust는 두 번째이며, Python은 가독성 항목에서만 여전히 강력하다.

따라서 AI 시대의 언어 선택을 한 줄로 요약하면 이렇다. 새 프로젝트는 도메인을 먼저 보고, 도메인이 시스템·인프라·CLI라면 Rust나 Go를, ML·데이터·자동화라면 Python을, 웹이라면 팀 구성을 보고 TypeScript나 Go를 선택하라. 그리고 어떤 선택을 하든, 컴파일러가 검증의 절반을 떠맡을 수 있는 언어가 5년 운영 비용에서 유리하다는 사실을 잊지 마라. Python이 1위였던 이유는 사람이 빠르게 쓰기 위해서였다. 이제 사람은 빠르게 검토해야 한다. 그리고 검토는, 컴파일러가 곁에 있을 때 가장 빠르다.