Zig 창시자는 진실을 말하지만, Antropic은 허풍을 떨고 있다.

 (raymyers.org)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Anthropic이 소프트웨어 엔지니어링의 종말을 미래 가치로 내세우는 가운데, Bun의 Zig→Rust 전환도 AI가 엔지니어링을 대체할 수 있다는 홍보 서사에 활용됐다는 비판
  • Bun은 메모리 버그를 전환 이유로 들었지만, 대안과 장단점 비교가 부족하고 Rust의 느린 컴파일 같은 비용도 공개하지 않아 사후 정당화로 비칠 수 있음
  • Zig를 다르게 운용하는 선택지도 있었으며, TigerBeetle의 TigerStyle은 정적 메모리 할당과 시뮬레이션 테스트로 use-after-free를 차단하는 사례를 보여줌
  • unsafe Rust로 파일별 이식한 방식은 위험을 줄이고 향후 재설계를 가능하게 한 합리적 접근이지만, 백만 줄 규모의 AI 변환은 받아들이면서 사람이 읽을 몇 줄의 포인터 관리 코드를 문제 삼는 태도는 일관성이 부족함
  • 에이전트 하네스, Rust의 borrow checker, 가독성 규칙, 인간 검토가 계속 필요하므로 코딩 에이전트 도입과 소프트웨어 엔지니어링 폐기는 같은 선택이 아님

Anthropic이 내세우는 소프트웨어 엔지니어링 종말

  • Anthropic은 코딩에 이어 소프트웨어 엔지니어링과 대부분의 인간 노동까지 사라질 것이라는 서사를 적극적으로 밀고 있음
  • 회사는 1,320억 달러의 투자를 유치했고 기업가치 1조 달러 이상의 IPO에 접근하고 있지만, 수익성을 보여주지 못하는 상황에서 가상적인 미래 영향력을 판매해야 하는 처지임
  • 이런 이해관계 때문에 Anthropic은 신뢰할 수 없는 화자(unreliable narrator) 로 봐야 하며, 메시지의 진위뿐 아니라 경영진·세계 지도자·퇴직연금 운용자의 판단에 미치는 영향도 중요함
  • AI 서사는 아키텍처·제품·인력 배치 결정에 영향을 주고, 해고 공포와 뒤처질 것이라는 경고, Doom Trolling 속에서 냉정한 판단을 어렵게 만듦
  • 소프트웨어 분야의 AI를 평가할 때는 Anthropic의 이해관계와 홍보 목적을 고려한 회의적 검토가 필요함

Bun의 Zig→Rust 전환과 뒤늦은 해명

  • Anthropic/Bun은 Zig로 작성된 Bun을 Rust로 옮긴 결정을 메인 브랜치에 병합하고 두 달이 지나서야 해명함
  • Zig 창시자 Andrew Kelley는 반론을 공개하고, 이례적으로 직설적인 어조로 Bun의 기술과 조직 운영을 비판함
    • 언어를 바꿨다는 이유로 이전 언어의 리더가 개인적 결함까지 공격하는 선례가 될 수 있다는 평판상 부담이 있음
    • 일부는 이를 “meltdown”이라 불렀지만, 공개적으로 짚어야 할 문제를 짚었다고 볼 여지도 있음

직설적인 비판을 판단하는 기준

  • 불교의 올바른 말(right speech)은 모든 발언이 다음 다섯 기준을 충족해야 한다고 봄
    • 사실인가
    • 도움이 되는가
    • 시기적절한가
    • 친절한가
    • 친절함에서 출발했는가
  • Andrew Kelley의 대응은 사실이지만 불친절한 말에 해당하며, 통상적인 예의를 벗어나더라도 문제를 공개적으로 지적할 필요가 있었는지가 쟁점임

Bun·Zig·AI 기여 정책의 관계

  • Bun은 더 빠른 NodeJS에 비유되는 TypeScript 런타임이고, Zig는 현대적인 C에 비유되는 시스템 프로그래밍 언어임
  • Bun은 최근까지 Zig로 작성됐으며 가장 큰 Zig 코드베이스 중 하나였음
  • 두 프로젝트의 AI 기여 정책은 정반대임
  • Anthropic이 Bun을 인수한 뒤 창업자 Jarred Sumner는 Zig 코드를 unsafe Rust로 옮기는 대규모 에이전트 실험을 진행했고, 결과는 며칠 후 병합돼 공식 버전이 됨
  • 관련 당사자 가운데 Bun을 계속 Zig로 유지하자고 요구하는 쪽은 없어 보이며, 논쟁은 전환 자체보다 그 이유와 홍보 방식에 집중됨
  • 에이전트를 이용한 대규모 언어 전환은 적절한 상황이라면 다시 시도할 만한 기술적 실험임

같은 결정을 둘러싼 세 가지 해석

  • Zig와 Rust 중 하나를 선택하려는 개발자에게, 최대 규모 Zig 사용자 중 하나가 결정을 뒤집은 사건은 중요한 판단 자료가 됨
  • Anthropic/Bun의 해석은 합리적인 방법을 모두 시도했지만 Zig로는 메모리 버그를 감당하기 어려웠다는 것임
  • Andrew Kelley의 해석에 따르면 AI 에이전트가 코드 작성과 리뷰를 과도하게 맡는 등 Bun의 엔지니어링 결정 때문에 코드베이스가 엉망이 됨
  • 더 평범한 가능성은 실제 메모리 문제에 여러 해법이 있었지만 경영진이 Rust 재작성을 선택하기 쉬웠다는 것임
    • 새 Fable 모델의 능력을 홍보할 수 있었음
    • Anthropic이 이미 Rust를 사용하고 있었음
    • Zig 프로젝트는 Anthropic 제품 사용에 공개적으로 반대함
  • Rust 전환은 사업적으로 합리적일 수 있지만, 홍보는 AI가 재작성을 수행할 만큼 강력하다는 데 집중함
    • AI가 use-after-free를 미리 잡지 못했다는 사실은 이 서사와 충돌함
  • Anthropic의 확성기를 통한 과장은 Jarred Sumner와 Andrew Kelley의 판단을 직접 비교하게 만들며, 의도하지 않게 Zig의 평판에도 영향을 줄 수 있음

기술 논쟁에 개인 신뢰성이 들어온 이유

  • 우선 책임을 물어야 할 주체는 Bun 창업자 개인보다 이 사건을 AI 서사에 활용하는 Anthropic임
  • Anthropic이 Jarred Sumner의 신뢰성을 이용해 자사 메시지를 강화하는 만큼, 이에 대응하려면 그의 판단과 행동도 평가할 수밖에 없음
  • 기술 쟁점만 논의하는 편이 바람직하지만 Anthropic의 메시지가 기술적 비교보다 볼거리와 홍보에 의존하면 개인 신뢰성까지 논쟁에 들어오게 됨
  • 당사자가 공개적으로 한 말과 행동을 정리하는 것만으로 비방처럼 보인다면, 그 행동 자체도 문제의 일부일 수 있음

상시 크런치와 Bun의 조직 환경

  • Bun의 2022년 채용 공지는 첫 9개월이 매우 고될 것이며, 일하지 않는 시간이 많은 형태의 일과 삶의 균형을 중시한다면 맞지 않을 것이라고 경고함
  • 상시 크런치 모드는 건강과 생산성 모두에 해로우며, 지식 노동에 관한 경험적 연구에서도 반복적으로 확인됨
  • 주 90시간 근무를 자랑하는 관리자보다 구성원이 밤에 잘 수 있도록 보호하는 관리자를 선택해야 함
  • Andrew Kelley가 Bun 팀 관계자에게 들었다는 평가는 소통 부족, 비현실적 기대, 낮은 공감, 경험 부족으로 요약되지만 전언이라는 한계가 있음
  • 다만 이 평가는 채용 공지에서 공개한 극단적인 근무 환경과도 일치함
  • 나쁜 업무 환경에서도 훌륭한 기술은 나올 수 있으며, Bun 자체는 쓸 만하고 흥미로운 도구임
  • 코드에 버그가 많고 유지보수하기 어려웠다는 평가는 외부 비판에 그치지 않고, Bun이 Rust 전환의 근거로 내세운 상태이기도 함

unsafe Rust 이식 방식의 실질적 가치

  • 전환 과정의 기술적 세부 사항은 다른 현대화 프로젝트에도 재사용할 가치가 있음
  • Bun은 처음부터 안전한 Rust로 재설계하지 않고 unsafe Rust로 파일 단위 이식을 수행함
    • 기존 구조를 유지해 초기 전환 위험을 줄임
    • 이후 안전성을 개선하고 재설계할 수 있는 기반을 마련함
  • AI 기반 자동화로 언어 선택을 과거보다 쉽게 되돌릴 가능성이 있지만, 자동 재작성에는 여전히 장단점과 의미 차이가 있음
  • 여러 재작성 기법을 조합하고 형식 기법(Formal Methods)으로 강화하는 것도 가능함
  • DARPA의 TRACTOR는 모든 C 코드를 Rust로 옮기는 연구 프로그램이며, 공개된 평가 보고서는 자동 변환 기술의 현황을 다룸
  • 에이전트가 오래된 코드에 더 많은 선택지를 제공하더라도, 현대화 목표를 정하려면 판단과 의사소통이 계속 필요함

빠진 것이 많은 기술적 의사결정 문서

  • 기술적 결정을 설명하려면 최소한 세 요소가 필요함
    • 동기가 무엇인가
    • 어떤 대안을 검토했는가
    • 각 대안의 장단점은 무엇인가
  • Richard Feldman이 Roc 컴파일러를 Rust에서 Zig로 옮긴 이유를 정리한 문서는 세 요소를 모두 갖춘 비교 사례임
  • Bun의 해명은 메모리 버그라는 동기를 제시했지만 검토한 대안은 일부만 다뤘고, 장단점 비교는 사실상 빠져 있음
  • 특히 장단점을 생략하면 처음부터 정답을 정한 뒤 근거를 붙인 사후 정당화처럼 보일 수 있음
  • 공개하지 않은 별도 이유가 있을 가능성도 배제할 수 없으며, 결정의 신뢰성을 높이려면 불리한 비용까지 함께 밝혀야 함

Rust의 장점만 나열한 비교

  • “Bun is better in Rust” 부분은 Rust 전환의 이점만 다루고 비용은 거의 제시하지 않음
  • 대규모 Rust 코드베이스는 일반적으로 안전성을 얻는 대신 느린 컴파일 시간이라는 비용을 지불함
  • Bun은 과거 컴파일 속도를 중요하게 여겨 Zig 컴파일러를 포크해 4배 개선을 시도함
  • Rust 이식으로 기여자의 빌드 시간이 늘었다면 이를 공개하고, 그 비용보다 안전성이 중요한 이유를 밝혀야 결정의 신뢰성이 높아짐
  • 전환 이후 이뤄진 다른 개선까지 Rust 재작성의 장점 목록에 섞어 넣어 언어 변경의 직접 효과가 과장될 수 있음

검토되지 않은 스타일 가이드 선택지

  • Bun에서 메모리 버그는 유일한 결함 원인은 아니지만, 개인 집계로 주당 4개의 수정 커밋이 필요할 만큼 빈번했음
  • 각 메모리 버그는 객체의 생성·소유·해제 방식에 관한 규약이 어딘가에서 깨졌다는 뜻이므로, 상황별 기대 동작을 명확히 정하는 방법부터 검토할 수 있음
  • 수동 메모리 관리는 규약의 범위를 넓히지만, 언어와 관계없이 효과적인 사용 지침이 필요하며 Rust에도 API 스타일 가이드가 있음

  • TigerBeetle이 보여주는 대안

    • 또 다른 대표적 Zig 코드베이스인 금융 트랜잭션 데이터베이스 TigerBeetle은 메모리 버그에 시달리지 않으며 가장 신뢰성 높은 데이터베이스 중 하나로 보임
    • TigerStyle과 시뮬레이션 테스트를 신뢰성의 기반으로 삼음
    • TigerStyle은 단순한 코딩 양식이 아니라 설계·메모리·테스트를 묶은 엔지니어링 철학임
    • 모든 메모리를 시작 시점에 정적으로 할당함
    • 초기화 이후에는 동적 할당이나 해제 후 재할당을 허용하지 않음
    • 예측하기 어려운 성능 변화를 피하면서 use-after-free를 차단함
    • 가능한 메모리 사용 패턴을 설계 단계에서 고려해 더 단순하고 빠르며, 추론과 유지보수가 쉬운 구조를 유도함
    • 모든 애플리케이션이 이 방식을 그대로 적용할 수는 없지만, 메모리 정책이 전체 설계 결정과 연결된다는 점을 보여줌

  • Bun 해명에 남은 공백

    • Bun은 TigerStyle과 Google의 31,000단어 C++ 스타일 가이드를 언급한 뒤, 스타일 가이드는 강제하기 어렵고 전통적으로 코드 리뷰·린터·정적 분석기에 의존한다고 정리함
    • 그러나 Bun이 실제로 어떤 스타일 가이드를 사용했고 왜 실패했으며, 4년 동안 어떻게 개선했는지는 다루지 않음
    • 큰 프로젝트에서 메모리 문제가 지속됐다면 현재 언어를 다르게 사용하는 선택지를 진지하게 시험했는지가 중요하지만, 이를 뒷받침할 근거가 부족함
    • 한 사람이 모든 맥락을 머릿속에 유지하고 회의를 하지 않는 운영 방식은 명시적 규약과 공유된 설계를 만들기 어렵게 함

에이전트 리뷰와 스타일 가이드의 모순

  • Bun은 스타일 가이드를 강제하기 어렵다고 보면서도, 마이그레이션용 PORTING.md를 작성하고 에이전트가 전체 재작성 코드를 엄격한 지침에 따라 검토했다고 밝힘
  • PORTING.md 자체가 전환 범위에 특화된 스타일 가이드이므로, 에이전트 리뷰가 성공했다면 지침 강제 문제도 이미 해결한 셈임
  • 적절한 조건에서는 에이전트 리뷰가 작동할 수 있지만, 충분히 설계된 규칙과 검토 방식이 전제돼야 함
  • 같은 정신적 노력을 Zig 코드의 재설계와 규약 강화에 투입할 수도 있었으나, Bun은 재아키텍처보다 재작성을 택함
  • 공개되지 않은 여러 이유로 재작성이 올바른 선택이었을 수 있지만, 현재 해명만으로는 대안 비교가 충분하지 않음

백만 줄 재작성과 세 줄의 포인터 코드

  • Bun은 Zig에서 소유권 기대를 타입 수준에 드러내려면 SharedPtr(TCPSocket)과 deref() 같은 코드가 추가돼 기존 포인터 사용보다 덜 편리하다고 봄
  • 이 예에서는 인터페이스 경계에서 포인터 전달을 명확히 하기 위해 대략 세 줄의 코드가 늘어남
  • 검토하기 어려운 백만 줄 규모의 AI 생성 PR은 받아들이면서, 포인터 소유권을 명확히 하는 몇 줄을 가독성 문제로 거부하는 태도는 일관성이 부족함
  • Jarred Sumner는 수개월 동안 사람이 직접 코드를 입력하지 않았다고 밝힌 바 있음
  • 코드가 사람을 위한 것이 아니라면 SharedPtr 래퍼가 보기 불편하다는 이유는 약해지고, 사람을 위한 것이라면 가독성·검토 가능성·유지보수성을 계속 고려해야 함
  • AI 회사는 코드 가독성이 여전히 중요하다는 사실을 인정하기 꺼리지만, 이를 부정하면 소프트웨어 엔지니어링이 끝난다는 서사에는 맞아도 유지보수 현실과 충돌함
  • 코딩 에이전트가 기본적으로 유지보수성을 악화시킬 수 있다는 벤치마크도 있음

같은 사건이 드러내는 ‘AI만으로는 부족하다’

  • Bun의 대규모 에이전트 재작성은 기술 개선뿐 아니라 Anthropic이 “AI면 충분하다”는 메시지를 홍보하는 사업적 기능도 수행함
  • 그러나 같은 사례는 정반대로도 해석할 수 있음
    • LLM만으로 부족하므로 에이전트 하네스로 감쌈
    • AI만으로 메모리 안전성을 보장할 수 없어 Rust의 borrow checker를 선택함
    • 사람이 읽어야 하므로 포인터 래퍼의 가독성을 걱정함
    • 사람이 유지보수해야 하므로 기존과 익숙한 코드 구조를 강조함
    • Project Bunsen은 하이브리드 접근으로 Zig 버전 Bun에서 50개의 버그를 발견함
    • 오픈소스 관리자는 AI 슬롭이 만드는 부담, 기여자 검증 문제, AI 기여 선별 정책, 생성형 AI 정책 정비에 대응하고 있음
  • 에이전트가 만든 문제까지 더 많은 에이전트로 해결할 수 있다는 전제 아래, 더 나은 도구 대신 토큰을 사고 기술을 배우는 대신 SKILL.md를 붙이는 방식이 확산됨
  • 소프트웨어 팀의 심리를 이해하는 대신 병렬 에이전트 세션을 Team이라고 부르는 것은 인간 조직과 자동 실행 세션을 혼동함

코딩 에이전트 도입과 엔지니어링 폐기는 별개

  • Anthropic의 소프트웨어 엔지니어링 종말 캠페인은 AI 도구를 만드는 쪽과 사용하는 쪽 모두에 역효과를 낼 수 있음
  • 코딩 에이전트를 도입하더라도 사람이 코드를 이해하지 않는 Dark Software Factory를 이상적인 모델로 삼을 필요는 없음
  • 목표는 사람들이 원하는 것을 만들고 제대로 작동하게 하는 것이며, AI 거품은 원하지 않는 것을 낮은 품질로 만들도록 압박할 수 있음
  • AI를 활용하되 판단·학습·의사소통·가독성·유지보수성을 포기하지 않는 방향이 필요함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 글에는 좋은 내용이 많지만, 몇 달 안에 버려지는 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 재단과 잡힌 회의에 연락 없이 불참하지 않는다면 괜찮을 것임
    • Andrew의 글은 여러 차례 수정됐으므로 최신 개정판을 읽으면 우려가 해소될 수도 있음: https://github.com/andrewrk/andrewkelley.me/commits/master/p...
    • 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은 지나치게 밋밋하기보다 다소 매운 편이 낫다고 봄
답변달기