LLM이 '빠르고 작은' 코드 열풍을 부추긴다 — Rust와 Zig가 다시 주목받는 이유
Fast and Hard Code
Armin Ronacher는 LLM이 언어 선택의 장벽을 낮추면서 개발자들이 성능과 크기에 집중하게 되었고, 그 결과 Rust와 Zig 같은 '어려운 언어'를 선택하는 프로젝트가 늘고 있다고 말합니다. Cloudflare의 Artifacts(순수 Zig로 작성된 Git 프로토콜 엔진)와 Vercel의 fx(Zig 기반 코딩 에이전트)가 그 예입니다. 또한 DWARF, eBPF, 커스텀 네트워크 드라이버 등 이전에는 접근하기 어려웠던 기술을 다루는 개발자도 늘고 있습니다. LLM 덕분에 더 많은 개발자가 빠르고 작은 소프트웨어를 추구할 수 있게 되었다는 관점입니다.
LLM은 언어 선택을 예전보다 훨씬 덜 중요하게 만들었다. 선택이 마음에 들지 않으면 다른 언어로 다시 작성할 수 있고, 프로그래머로서 전혀 모르는 언어를 선택하게 할 수도 있다.
HN 토론
79- qsera
> 갑자기 사람들이 DWARF 파일, eBPF, 커스텀 네트워크 드라이버, 커스텀 암호화, 그리고 정말 오래된 컴퓨팅 하드웨어로 정말 인상적인 작업을 하는 것을 보게 되었습니다. 이러한 것들 중 상당수는 이전에는 많은 개발자에게 금지된 영역이었습니다. 어떤 경우(예: 암호화)에는 아는 사람들이 의도적으로 접근을 막았기 때문에 오히려 밀쳐내기도 했습니다.
이전에는 적어도 우리 중 일부는 무언가를 이해해야만 했습니다. 이해 없이는 우리가 정말로 원하는 일을 할 수 없었기 때문입니다. 그들 중 일부는 열정을 갖고 계속 파고들었고, 우리 중 일부는 그 경험을 바탕으로 더 나은 것을 만들기도 했습니다.
이제는 아무도 아무것도 이해할 필요가 없으며, 이제 우리는 더 나은 것을 결코 갖지 못할 것입니다.
- willtemperley
어느 정도는 사실이라고 생각하지만, LLM이 주제에 대해 얼마나 많은 정보를 가지고 있는지에 크게 달려 있습니다.
수학은 처음부터 오픈소스였기 때문에 놀라울 정도로 잘합니다. 알고리즘도 비슷한 이유로 훌륭합니다. C 바인딩은 선례가 많아서 식은 죽 먹기입니다. 하지만 언어의 최첨단 기능을 사용하는 데는 형편없습니다. 아직 데이터가 많지 않기 때문입니다.
이 기준으로 그들이 무엇을 잘하는지 예측하는 것은 꽤 쉬운 일이라고 생각합니다. UI 디자인에 왜 그렇게 약한지 모르겠지만요.
- noduerme
암호화에 대해 잘 알지 못하는 사람으로서, '커스텀 암호화'라는 말만으로도 몹시 무섭다는 것을 알 만큼은 알고 있습니다.
- superjose
상황에 따라 다르다고 말하고 싶습니다.
소프트웨어가 얼마나 진화하고 사용될 것인지에 따라 달라집니다.
우리가 수년간 패턴을 발견하고 특별한 문법을 만든 이유는 특정 도메인 문제를 더 효율적으로 해결하고 시간이 지나도 진화할 수 있는 시스템을 갖기 위해서였습니다.
유일한 상수는 변화입니다.
LLM이 코드를 만들어내지만(그리고 훌륭한 지식으로 인상적인 결과물을 내놓지만), 개발자는 특정 임계점을 넘기 위한 노하우를 갖추어야 합니다.
모르는 언어로 작성하는 것은 처음에는 괜찮아 보일 수 있습니다. 하지만 한계에 부딪히면, LLM이 근본 원인을 제거하는 대신 우회하는 특정 문제점이나 비효율성을 발견하게 될 것입니다.
예를 들어, 저는 몇 주 동안 Effect.ts를 배우고 있습니다. LLM을 많이 사용했지만, 그 전에 먼저 수동 코딩을 여러 차례 해야 했습니다.
합성 가능성, 세부 사항, 어디서 어떻게 깨지는지, 문법이 어떻게 형성되는지, 그리고 라이브러리 주변에서 겪었던 관찰 가능성 문제를 어떻게 구조화할 수 있는지 이해하기 위해서였습니다.
그 과정을 거치지 않았다면 코드 품질은 평균 이하였을 것입니다. 처음에는 분명하지 않았겠지만, 시스템이 진화하고 피드백에 적응하기 시작하면, 취약해지고 기존 고객에게 영향을 미치는 등의 문제가 발생했을 것입니다.
저는 물건을 깨지 않고 빠르게 움직이는 것을 좋아합니다.
- jbstack
> 한 가지는 분명합니다: 언어에 익숙해지는 행위는 더 이상 중요하지 않다는 것입니다.
이 기사의 전제에 대해 전적으로 동의하지 않습니다.
물론, 에이전트의 작업이 신뢰할 수 있는지 전혀 신경 쓰지 않는다면 언어를 배울 필요가 없습니다. 하지만 자신의 작업에 신경 쓰고 100% '바이브 코드'만 내놓지 않는 개발자라면, 최소한 에이전트의 출력을 검토하고, 코드를 따라가며, 커밋 여부를 정보에 입각해 결정할 수 있을 만큼 언어에 익숙해야 합니다.
흥미롭게도, 언어를 배우는 나의 접근 방식이 근본적으로 바뀌었다는 것을 발견했습니다. 예전에는 그 당시 나에게 중요한 한두 가지 언어에 대한 책을 공부했습니다. 목표는 능숙해지는 것이었습니다. 이제는 흥미로운 패러다임을 보여주는 다양한 언어(예: Haskell -> 함수형, Elixir -> 동시성)에 대해 읽기로 선택합니다. 프로그래밍 책을 흥미로운 논픽션 책처럼 읽습니다: 비교적 빠르게 처음부터 끝까지 읽고, 그다음에는 끝입니다. 이렇게 하면 에이전트 코딩에 유용한 '친숙함'을 얻을 수 있고, 모든 난해한 문법이나 라이브러리 호출을 배우는 수고는 하지 않아도 됩니다. 나의 우선순위는 깊이(한두 가지 언어를 정말 잘 배우기)보다는 폭(많은 언어와 패러다임을 개괄적으로 파악)이 되었습니다.