Fast and Hard Code

Armin Ronacher

빠르고 어려운 코드

원문은 Armin Ronacher님이 에 게재했습니다. 이 블로그 구독하기

트위터에서 유행하는 밈 중 하나는 “이제 프로그래밍은 해결됐다”는 것이다. 어느 정도까지 사실인지는 모르겠지만, 한 가지는 분명하다. 이제는 특정 언어에 익숙해지는 과정이 더 이상 중요하지 않으며, 인간에게는 마찰이 되던 것들이 에이전트에게는 해당하지 않는다는 점이다.

그 결과 LLM은 언어 선택이 예전만큼 중요한 문제가 아니게 만들었다. 선택이 마음에 들지 않으면 다른 언어로 다시 쓰면 되는 것처럼 보이고, 프로그래머인 자신이 전혀 모르는 언어를 고르게 할 수도 있다.

이는 결국 사람들이 언어의 마케팅을 보고 선택하는 경우가 훨씬 많아졌다는 뜻이기도 하다. 오랫동안 Rust를 써 온 프로그래머로서, 예전 같으면 Rust를 선택하지 않았을 사람들이 이제 Rust 코드를 내놓는 모습을 보는 것은 꽤 흥미롭다. 나는 그 이유 중 적어도 일부는 최근의 두 가지 분위기 변화 때문이라고 본다. 빠른 소프트웨어를 원한다는 이야기가 훨씬 많아졌고, LLM이 동작의 퇴화 없이 코드를 최적화하는 데 탁월하다는 이야기도 많아졌다는 것이다.

Mitchell Hashimoto, Charlie Marsh, Jarred Sumner, Daniel Lemire 같은 사람들을 비롯해 꽤 많은 이들은 언제나 빠르고 성능 좋은 소프트웨어에 대한 일종의 집착을 가지고 있었고, 마침 이들 모두 에이전트가 코드를 작성하는 것에 개방적이다. 그 영향 때문인지, 혹은 그와는 상관없이 이제 다른 사람들도 합류하고 있다. autoresearch 같은 것이 있기 때문이다. 모든 꼼수를 알 필요조차 없다. 그냥 에이전트를 붙이면 된다 — 물론 아는 것이 있으면 큰 도움이 되지만 말이다!

주위를 둘러보면 빠르고 작은 것을 지향하는 프로젝트가 많고, 이들은 점점 “어려운 언어”를 선택하고 있다. 그리고 혜택을 보는 것은 Rust만이 아니다. Zig조차 그렇다. 창시자와 핵심 커뮤니티 일부가 AI 자체에 대해 꽤 부정적인 입장을 가지고 있음에도 불구하고 말이다. 예를 들어 Cloudflare의 새로운 Artifacts 서비스는 순수 Zig로 작성된 Git 프로토콜 엔진을 사용해 약 100KB 크기의 WebAssembly 모듈로 컴파일되며, Vercel은 작고 빠르다고 홍보하는 Zig 코딩 에이전트인 fx를 출시했다. 내가 파악한 바로는 이 모든 프로젝트가 대부분 LLM의 도움을 받아 만들어졌다.

하지만 사람들이 덜 흔한 언어를 선택하는 것뿐만 아니라, 점점 “훨씬 더 어려운” 기술들을 다루고 있다는 점도 있다. 갑자기 DWARF 파일, eBPF, 커스텀 네트워크 드라이버, 커스텀 암호화, 정말 오래된 컴퓨팅 하드웨어 등으로 정말 인상적인 결과물을 만들어내는 사람들을 보게 됐다. 이런 것들 중 다수는 이전에는 많은 개발자에게 접근조차 불가능한 영역이었다. 어떤 경우(예: 암호화)에는 아는 사람들이 의도적으로 진입을 막았기 때문에 아예 밀려나기도 했다.

그러니 세상에는 슬롭이 더 많아질지도 모르지만, 빠르고 작은 것을 원하는 개발자도 더 많아질지 모른다.

이 글은 muse-spark-1.2-contributor 모델을 사용해 번역했습니다.

댓글