이 글에는 좋은 내용이 많지만, 몇 달 안에 버려지는 AI 생성 프로젝트가 떠오름. 프로젝트의 가치는 생성된 코드량보다 실전 검증을 얼마나 거쳤는지에 있고, 성숙한 기존 코드가 새 재작성보다 낫다
기존 Zig 코드베이스는 이미 검증됐지만 Rust 재작성은 테스트 통과 외에는 검증이 0에 가깝고, unsafe Rust로 파일별 직역을 했다면 출발점인 Zig보다 무엇이 나은지도 불분명함. 이후 안전한 Rust로 옮겨 운영 환경과 다수 사용자에게 검증받아야 의미가 생긴다
사실상 Bun이 포크된 셈인데 Zig판과 Rust판 중 무엇이 살아남든 상관없으며, 이것을 Zig의 적합성 문제로 받아들일 이유도 없음

AI 프로젝트는 즉흥적으로 생성되기 때문에 버려짐. 매몰 비용은 오히려 역경과 침체기를 견디게 하는 장점이 될 수 있지만, 순간적인 아이디어와 Claude 프롬프트만으로 만든 결과물에는 애착이 생기지 않는다
평범한 프로그래머인 나도 매일 수십 가지 멋진 아이디어를 떠올리지만 검토를 견디는 것은 극소수고, 며칠 뒤에는 그마저 노력할 가치가 없어 보인다. 아이디어는 원래 저렴했고 이제 개념 증명까지 저렴해졌으므로, 한 달도 투자하지 않은 Show HN에는 관심이 가지 않음

상당한 실전 검증을 거친 안전한 Rust에 도달하려면 어딘가에서 시작해야 하니, 우선 직역한 뒤 점진적으로 개선하기로 한 것임
Zig 진영은 C보다 충분한 이점이 없어 진지한 용도로 쓰이지 못하고 대표 프로젝트마저 떠난 탓에 Zig가 시작부터 가망 없는 언어일까 걱정하는 듯함. Zig 이슈 추적기에서 segfault를 검색해 보면 Rust 같은 대안 앞에서 미래 효용을 의심하는 이유를 알 수 있음

Zig와 달리 이제 명확하고 범위가 제한된 unsafe 경계가 생겼고, 이를 하나씩 고칠 수 있다는 점이 더 나음

글의 도입부는 지나치게 냉소적임. Anthropic과 OpenAI의 지인들을 보면 이들은 가까운 미래에 에이전트가 프로그래밍 대부분을 맡고 자신들도 일자리를 잃을 것이라고 실제로 믿는다
반AI 진영을 가르치려고 메시지를 관리하는 것이 아님

AI 생성 프로젝트가 빨리 버려지는 이유를 실전 검증 부족이라고 단정할 수는 없음. 일반적인 개인 프로젝트도 대개 일정 시간이 지나면 버려지고, 코드를 훨씬 빨리 작성할 수 있게 되면서 개인적 효용·배움·즐거움의 한계효용 체감점에 더 빨리 도달하는 것일 수도 있음

Andrew가 직설적으로 말한 것 자체보다, 글이 명백한 인신공격이면서도 아니라고 주장하는 이중적 태도가 더 큰 문제임
이 글을 읽고 Zig로 무언가 만들고 싶지 않아졌다. 어떤 기술적 결정을 내리든 Zig의 종신 자비로운 독재자(BDFL)가 이런 글을 쓸 수 있기 때문이며, Python이나 Rust 등 다른 공동체 지도부가 이처럼 행동하는 모습은 상상하기 어려움

더 심각한 것은 이런 태도가 Zig 공동체에 퍼지는 조짐이 보인다는 점임. 아직 다수가 아니더라도 친절한 사람들이 더 따뜻한 공동체로 떠나면 남은 집단에서 이런 성향의 비중은 커짐

Andrew는 옳은 일을 진심으로 중시해서 강한 견해를 가졌지만, 멀리서 판단하는 것보다 더 인내심 있고 포용적인 사람이라고 변호하고 싶음
누군가는 Andrew가 Bun을 공격했다고 보고, 나는 Andrew를 향한 반응을 인신공격으로 볼 수 있다. 선입견을 걷어내면 양쪽이 모두 잘못했거나 어느 쪽도 잘못하지 않은 것으로 봐야 하며, 멀리서 상황을 판단할 때 개인의 선입견이 지나치게 큰 영향을 준다는 점을 의식해야 함

떠나면서 Zig를 나쁘게 보이게 하는 오해의 소지가 있는 글을 쓰지 않고, Zig 재단과 잡힌 회의에 연락 없이 불참하지 않는다면 괜찮을 것임

Rust에는 설계상 BDFL이 없고, Python도 이 모델에서 벗어난 것으로 기억함. 개인 기여자가 화를 내며 공격적인 글을 쓸 수는 있어도 Zig처럼 언어를 대표하는 단일 인물은 없음

Andrew 편에 서고 싶음. Sumner의 작업을 수년간 지켜본 입장에서 Kelley의 비판은 불친절하더라도 상당 부분 사실이고, 결과물이 유용하고 멋지더라도 처음부터 끝까지 자기 홍보용 영향력 행사에 가까웠다
나 역시 하루 8시간 에이전트 기반 개발을 하고 팀에 Node 대신 Rust와 Deno를 쓰자고 권해 왔지만, 이 재작성은 정당화가 빈약했고 Dario 일행이 성공시킨 긴 홍보전의 연장선으로 보임. 표현을 더 점잖게 했다면 잘 받아들여졌겠지만, 홍보팀이 대필한 글 대신 솔직한 생각을 내놓은 점은 높이 평가함

이번 소동에서 얻은 교훈은 격한 답변을 게시하기 전에 1~2일 묵히고 가까운 친구에게 보여줘야 한다는 것임. Andrew가 나중에 고친 결론부 정도를 첫 개정판부터 내놓는 편이 좋음

재작성의 사전 정당화는 빈약했지만 Jarred가 답답해한 이유는 예시 없이도 이해됐음
JavaScript 가비지 수집기와 상호작용하면서 Bun에 고유한 어려움이 생긴다는 설명은 유용했지만 Andrew는 이를 전혀 다루지 않았다. 새 코드를 기존 테스트 모음으로 검증했다는 설명도, 테스트까지 분위기 코딩으로 번역돼 믿을 수 없다고 생각했던 오해를 풀어줬다. 테스트가 모든 버그를 잡지 못한다는 사실은 Zig를 포함한 모든 소프트웨어에 해당함
결국 메모리 비안전 언어가 막대한 결함 비용을 만든다는 관점과 “실력을 키워 버그를 쓰지 말라”는 대응의 충돌에 AI 논쟁, Anthropic의 참여, Andrew의 Linus식 화법이 더해져 확산된 것임

회사 외부의 누구에게 재작성을 정당화해야 한다고 보는 사고방식 자체가 이상함

기술적 사안에서는 홍보 문구보다 Linus처럼 있는 그대로 말하는 태도가 좋고, 홍보용 표현은 비기술 고객에게나 쓰면 됨

Anthropic과 Andrew Kelley의 글을 같은 방식으로 읽었는지 의문임. Anthropic은 프로그래밍 언어를 파는 회사가 아니며, Bun의 Rust 재작성 글에는 최종 사용자에게 제품이 어떻게 개선됐는지 보여주는 기술 세부 사항이 많았다
반면 Zig 측 대응은 인신공격으로 가득한 신랄한 칼럼에 가까움. 나는 Codex를 쓰고 Zig나 Rust 어느 쪽에도 이해관계가 없어 바깥에서 지켜보는 입장임

Anthropic도 분명 프로그래밍 언어 시장에 이해관계가 있음. AI가 특정 언어로의 재작성을 쉽게 만든다면 성공담은 해당 언어와 AI 회사를 연결하고, AI로 작성하기 쉬운 Rust의 성공은 Anthropic에도 이익이 됨
또한 성공적인 재작성을 홍보할 때는 기존 코드가 얼마나 나빴는지처럼 서사에 불리한 요소를 숨기는 경우가 많고, 이번에도 중요한 측면들이 빠졌음
Andrew Kelley의 글(https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...)은 Jarred의 낮은 공학 기준, Zig 재단과의 회의에 연락 없이 불참하는 등 부실한 대외 관계, Rust 전환 과정에서 Zig를 나쁜 선택으로 묘사해 생긴 피해, 그에 따른 ZSF의 분노를 다룬다
피상적으로만 보면 언어 창시자가 전 사용자를 공격한다고 우려할 만하지만, Bun의 글만 읽고 나도 품었던 그 인상이 부당한 이유를 Kelley가 밝혔다. 일부 인신공격은 분명하며 나중에 추가된 마지막 절에서도 이를 다룸

스튜디오가 Unity에서 Unreal로 전환하자 Unity가 기존 코드 품질과 근무 환경을 공격하는 글을 냈다고 상상해 보면, Zig가 대응한 것 자체가 이상함

이는 장인주의와 산업주의의 오래된 충돌임. Andrew는 모든 개발자가 자부심 있는 장인이기를 바라는 전통에 속함
Java, JavaScript, Python, C#은 완벽주의적이지 않은 개발자도 큰 사고 없이 일할 수 있는 안전장치를 제공해 C++ 중심 산업을 장악했다. C와 C++의 성능 이점은 컸지만 점점 더 적대적인 환경에서 상당한 숙련이 필요했다
Rust와 Swift는 가비지 수집 언어보다 성능 예측 가능성이 높으면서 비슷하거나 더 강한 안전성을 제공했고, Rust의 아이디어는 이 영역에서 새로운 언어들이 폭발적으로 등장하게 했다. 다만 상당수는 산업 요구에서 출발한 Rust보다 장인주의에 가까움
자동차에 비유하면 Java와 JavaScript 등은 일반 안전 차량, C/C++는 이륜 오토바이, Rust는 빠르지만 탑승자를 보호하는 랠리카, Zig는 사륜 오토바이나 오픈휠 카트에 가깝다. 쉽게 미끄러지지는 않아도 전복되면 매우 위험함
시간과 비용 제약을 무시하는 장인들은 조심스러운 개발자만 있으면 된다고 여기지만, 산업 현장에서는 좋은 코드를 쓸 수 있어도 90%는 제약 속에서 작업하므로 내 코드든 남의 코드든 믿기 어렵다. Zig에는 장점이 많지만 처음부터 안전보다 해킹의 자유를 선호하는 사람들을 위한 언어였음

바이너리 크기와 속도 개선은 Rust 재작성 자체와 큰 관련이 없고, Zig 코드베이스에 비슷한 노력을 들여도 가능했을 것임. 재작성을 홍보하기 위해 이 수치가 좋아 보이도록 추가 작업한 측면이 있음
메모리 안전성도 AI, 테스트, 그리고 상위 수준 퍼징이 아니라 Zig 팀이 권한 통합 퍼저를 사용했다면 비슷하게 확보했을 수 있다. 그래도 Bun 같은 프로젝트에는 더 성숙한 Rust가 좋은 선택일 수 있음
Andrew의 관점은 무슨 일이 있었는지 이해하는 데 필수적이었다. 일부 표현은 더 부드러울 수 있었지만, 나쁜 관리가 관계 악화와 부실한 공학 결과의 직접 원인이라면 이를 밝히는 것은 인신공격이 아니라 필요한 맥락임

코드를 대신 작성해 프로그래머 생산성을 높인다는 제품이 자체 언어를 팔지 않는다는 이유로 언어 시장과 무관하다고 보는 것은 근시안적임
특히 Zig 지도부는 분위기 코딩을 공개적으로 싫어하고 업계를 비판했으며, 프로젝트는 해당 제품으로 만든 기여 요청을 거부하고 있음

이 논쟁에는 정작 기술적 실체가 부족함. Bun의 Rust 이식이나 Andrew의 공격적 글, 골드러시에서 삽을 파는 Anthropic에는 관심이 없고 구체적인 기술 내용을 보고 싶다
Jarred가 제시한 Rust 전환 동기는 근거가 다소 부족해도 타당해 보이지만, Andrew는 그것이 실제 문제가 아닌 이유나 Zig에서 정석적으로 어떻게 해결할지 반박하지 않았다. 특히 Bun의 실제 Zig 코드에 근거해 논점을 분석해 주길 바람

Bun 측이 제시한 사실만 보면 재작성의 기술적 타당성이 부족하며, 대부분의 경우 재작성은 나쁜 공학이므로 놀랍지 않음
Bun은 Zig 경험이 부족한 사람이 거대한 범위와 복잡성에도 불구하고 시작했고, 처음부터 다른 언어의 코드를 재작성한 프로젝트였다. esbuild의 JavaScript·TypeScript 변환기를 Go에서 Zig로 한 줄씩 옮긴 뒤 몇 년 만에 전체 코드베이스를 버리고 또 다른 언어로 재작성했다면 더 다룰 것이 무엇인지 의문임

Andrew의 요지는 Bun 코드가 원래 나빴다는 것이고, Jarred가 유해한 인물이어서 이 논쟁에 참여할 가치도 없다고 암시한 것으로 읽힘

Bun은 빠르게 움직이며 깨뜨리기를 원하고 Zig는 느리고 신중하게 움직이게 만듦
Bun은 셸 언어, SQLite/PostgreSQL 클라이언트 같은 기능을 최대한 빨리 출시하려 하므로 메모리 관리를 직접 신경 쓰지 않길 원한다. Zig는 메모리 관리와 수명을 직접 다루게 하고 Drop 같은 기능도 의도적으로 추가하지 않지만, Rust는 Drop 덕분에 더 잘 맞음
Python으로 SQL 데이터베이스를 만들지 않듯 Zig는 Bun에 맞는 도구가 아니며, Zig에서 정석적으로 해결할 사안이라기보다 Jarred가 프로젝트를 빠르게 전개하려는 방식의 차이임

원문은 이 문제를 직접 다루지만 좋은 면만 거의 선택적으로 담았음. 예를 들어 빌드 시간을 개선하려고 Zig 컴파일러까지 다시 작성했다고 하면서, 일반적으로 훨씬 느린 Rust 빌드 시간은 왜 전혀 다루지 않았는지 의문임

골드러시에서 삽을 파는 쪽은 데이터 센터와 에너지를 만드는 회사들이고, 토큰이 금에 해당함

Kelley의 견해 일부에는 동의하지만 문제는 어조임
Bun이 Rust에서 Zig로 재작성됐다면 Rust 핵심 팀원이 Sumner를 겨냥한 인신공격 글을 쓰면서 공격이 아니라고 주장했을 가능성은 낮다. Kelley가 원하는 글을 쓸 자유가 있듯, 성장 중인 언어의 BDFL이 만든 Zig의 공개 이미지에 사람들이 반응할 자유도 있음

Bun의 Rust 전환 글은 구체적인 선택지 비교와 영향 수치가 빠지고 결과를 편향되게 다뤄, 공학 블로그 글처럼 느껴지지 않았음
사람들이 이식의 기술적 근거보다 에이전트 활용에 더 관심을 보였던 것 같고, 기술적으로는 매우 실망스러웠음

같은 글을 읽었는지 의문임. 특정 코드 한 줄을 다루지는 않았지만 깊은 아키텍처 세부 사항, 메모리 안전성과 버그에 관한 근거, 대규모 에이전트 코딩 패턴이 반복해서 담겨 있었음

경영진과 임원에게 마케팅의 영향력이 얼마나 큰지, 특히 CEO 같은 자리에 오르는 사람들이 얼마나 사소한 감정에 휘둘릴 수 있는지 과소평가하면 안 됨
새 Fable 모델을 홍보할 기회라는 점과 Zig가 Anthropic 제품 사용에 공개적으로 반대한다는 점만으로도 Bun의 Rust 재작성은 사실상 결정돼 있었을 수 있음

어떤 형태로든 경영진이 개입했다고 보는 이유를 모르겠음. Jarred가 스스로 원하는 일을 했다는 쪽이 훨씬 그럴듯하고, 본인도 그렇게 말해 왔음

언어 전환 논쟁에서 왜 근무시간 기대치까지 다루는지 모르겠음. 그가 형편없는 관리자더라도 부정적인 소재를 억지로 찾는 듯 보임
Zig 측이 재작성 자체의 기술적 장점에 거의 집중하지 않는 것도 의미심장하다. Anthropic이 여러 개선을 내세웠지만 이를 반박하려는 시도조차 찾기 어렵다
내 프로젝트를 대규모 언어 모델로 재작성했더니 단점 없이 개선됐다는 결과가 나오면 크게 걱정해 대응할 텐데, 여기서는 엉뚱하게 근무시간을 논하고 있음

Anthropic이 소유한 프로젝트와 AI 생성 코드를 공개적으로 적대하는 언어 공동체 지도부 사이에는 명백한 이해 충돌이 있음
Andrew Kelley는 이 점만 말하고 멈추는 편이 나았고, Bun 창립자의 에너지와 동기에 관한 평가는 보탤 가치가 거의 없음

AI를 절대적으로 지지하거나 반대하는 양측이 타협하기는 어려움. 기술적 논거와 공격 대부분은 사후 합리화이며, 조직마다 맥락과 목표가 다를 뿐임
Kelley도 이를 알았지만 핵심을 흐리고 싶은 유혹을 참지 못한 듯하다. 과격한 글([0]: https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...)은 지나쳤지만, 앞으로 나아가자는 부록은 건전함. BDFL은 지나치게 밋밋하기보다 다소 매운 편이 낫다고 봄