LLM이 바꾸는 언어 선택: 왜 개발자들이 '어려운 언어'로 몰리나

프로그래밍 언어를 고르는 기준이 조용히 바뀌고 있다. Rust 개발자로 오랫동안 일해 온 아르민 로나허(Flask·Jinja 등의 저자로 알려진 lucumr 블로그 운영자)는 최근 글에서, 대규모 언어 모델(LLM)과 에이전트가 언어 선택의 무게를 크게 줄이고 있다고 진단한다. 핵심은 단순하다. 새로운 언어에 익숙해지는 과정, 즉 문법과 관용구를 익히며 겪던 마찰이 사람에게는 여전히 크지만 에이전트에게는 별 의미가 없다는 것이다.

그 결과 언어 선택이 예전만큼 돌이키기 어려운 결정이 아니게 됐다. 마음에 들지 않으면 다른 언어로 다시 쓰게 하면 되고, 심지어 자신이 전혀 모르는 언어를 고르는 것도 가능해졌다. 이렇게 되면 사람들은 언어의 실제 학습 곡선보다 그 언어가 내세우는 '마케팅'에 따라 선택하는 경향이 강해진다. 로나허는 예전이라면 Rust를 택하지 않았을 사람들이 이제 Rust로 코드를 출시하는 모습을 흥미롭게 지켜본다고 말한다.

빠른 소프트웨어라는 분위기 전환

그는 이 변화의 배경으로 두 가지 최근의 기류를 꼽는다. 하나는 '빠른 소프트웨어를 원한다'는 이야기가 부쩍 늘었다는 점이고, 다른 하나는 LLM이 동작을 망가뜨리지 않으면서 코드를 최적화하는 데 탁월하다는 인식이다. 미첼 하시모토, 찰리 마시, 재러드 섬너, 다니엘 르메르처럼 성능에 집착해 온 개발자들이 공교롭게도 에이전트가 코드를 쓰는 방식에도 우호적이라는 점을 그는 지적한다. 이들의 영향인지 아닌지는 몰라도, 성능 지향의 흐름에 합류하는 사람이 늘고 있다는 것이다.

주목할 만한 대목은 지식의 문턱이 낮아졌다는 주장이다. 이른바 '오토리서치' 같은 방식에서는 모든 최적화 요령을 알 필요 없이 에이전트에게 문제를 맡기면 된다. 다만 그는 지식이 있으면 크게 도움이 된다는 단서를 분명히 붙인다. 즉 에이전트가 진입 장벽을 낮춘 것은 맞지만, 전문성이 무의미해졌다는 뜻은 아니다.

Rust만이 아니라 Zig까지

빠르고 작게 만들려는 프로젝트들이 점점 '어려운 언어'를 택하는 흐름은 Rust에 국한되지 않는다. 로나허는 Zig를 예로 든다. Zig는 창시자와 코어 커뮤니티 상당수가 AI에 부정적임에도 오히려 수혜를 보고 있다는 것이다. 그는 Cloudflare의 새 Artifacts 서비스가 순수 Zig로 작성된 Git 프로토콜 엔진을 약 100KB짜리 WebAssembly 모듈로 컴파일해 쓰고 있으며, Vercel이 작고 빠르다고 내세운 Zig 코딩 에이전트 fx를 공개했다는 사례를 든다. 그가 보기에 이런 프로젝트들은 대체로 LLM의 도움을 받아 만들어졌다.

언어뿐 아니라 다루는 기술 자체가 어려워지는 현상도 같이 나타난다. 그는 DWARF 디버그 정보, eBPF, 커스텀 네트워크 드라이버, 자체 암호화, 아주 오래된 컴퓨팅 하드웨어 같은 영역에서 인상적인 작업을 하는 사람들을 목격했다고 전한다. 이런 분야는 과거 많은 개발자에게 접근 자체가 어려웠고, 특히 암호화처럼 아는 사람들이 의도적으로 문턱을 높여 온 영역도 있었다.

한국 실무자에게 의미하는 것

국내 개발 조직에도 시사점이 적지 않다. 그동안 '팀에 아는 사람이 없어서' 선택지에서 빠졌던 시스템 언어나 저수준 기술이, 에이전트를 붙이면 현실적인 후보가 될 수 있다는 이야기다. 성능 요구가 뚜렷한 모듈을 Rust나 Zig로 다시 쓰거나, WebAssembly로 크기를 줄이는 시도가 기술적으로는 한결 가벼워진다. 다만 이는 언어를 '평가'하는 능력까지 대체하지 못한다. 마케팅에 이끌린 선택이 늘어난다는 것은, 팀이 실제로 유지보수와 디버깅을 감당할 수 있는지에 대한 판단을 오히려 더 중요하게 만든다.

로나허 자신도 이 변화를 낙관 일변도로 보지는 않는다. 그는 세상에 질 낮은 코드(slop)가 더 많아질 수도 있다고 인정한다. 그럼에도 결론은 균형에 가깝다. 빠르고 작은 것을 원하는 개발자가 더 많아지는 방향, 즉 진입 장벽이 낮아진 만큼 도전하는 사람의 수가 늘어나는 쪽에 무게를 둔다. 이 글은 통계나 벤치마크가 아니라 한 베테랑의 관찰과 몇몇 사례에 기댄 에세이인 만큼, 추세의 크기를 단정하기보다 방향의 신호로 읽는 편이 적절하다.