Bun의 Zig→Rust 이식 논쟁, 진짜 쟁점은 AI가 코딩을 끝냈다는 서사

• Bun의 Zig에서 Rust로의 이식 논쟁은 겉으로는 언어 선택 이야기인데, 글쓴이는 진짜 쟁점을 Anthropic의 AI 마케팅 서사로 봄

  • Bun은 빠른 Node.js 대체재에 가까운 TypeScript 런타임이고, 원래는 Zig로 작성된 대표적인 대형 Zig 코드베이스였음
  • 그런데 Bun이 Anthropic에 인수된 뒤, 창업자 Jarred Sumner가 Zig 코드베이스를 unsafe Rust로 대규모 이식했고, 그 실험이 며칠 만에 메인라인에 병합됨
  • 이 설명은 병합 후 두 달이나 지나서 나왔고, 그 사이 “AI가 빠르게 Rust 재작성했다”는 식의 자극적인 헤드라인이 먼저 퍼짐

• 글쓴이가 가장 불편해하는 건 “Rust 이식” 자체가 아니라, Anthropic이 이걸 “AI가 소프트웨어 엔지니어링을 끝낼 수 있다”는 서사에 태우는 방식임

  • Anthropic은 1,320억 달러 투자를 유치했고, 1조 달러 이상 기업가치의 IPO까지 거론되는 회사라서, 아직 수익성보다 미래 영향력을 팔아야 하는 입장임
  • 그래서 “코딩은 사라지고, 소프트웨어 엔지니어링도 사라지고, 결국 인간 노동 대부분이 사라진다”는 이야기가 단순한 농담이 아니라 투자자·경영진·정책 결정자의 의사결정에 영향을 줌
  • 글쓴이는 Anthropic을 문학적으로 말하면 “믿을 수 없는 화자(unreliable narrator)”라고 표현함. 좀 세게 말하면, 자기 제품을 팔기 위해 세상을 그렇게 보이게 만드는 쪽이라는 얘기임

Bun 이식의 기본 구도

• 커뮤니티가 보게 된 선택지는 대충 두 가지 이야기로 갈림

  • Anthropic/Bun 쪽 이야기: Bun은 합리적인 시도를 다 했지만 Zig로는 메모리 버그를 감당하기 어려웠고, Rust가 필요했음
  • Andrew Kelley 쪽 이야기: 문제는 Zig가 아니라 Bun의 엔지니어링 방식, 특히 AI 에이전트에 코드 작성과 리뷰를 과하게 맡긴 운영 방식임
  • 글쓴이의 해석은 더 현실적임. 메모리 버그라는 진짜 문제가 있었고, Rust 이식은 여러 선택지 중 하나였는데, Anthropic 입장에서는 새 모델과 AI 코딩 능력을 홍보하기에 너무 좋은 선택지였다는 것

• Bun의 Rust 이식 방식 자체에는 배울 점도 있다고 봄

  • 특히 곧바로 “안전한 Rust다운 재설계”를 한 게 아니라, unsafe Rust로 파일 단위 이식을 해서 리스크를 줄이고 나중에 재설계할 길을 열었다는 점은 꽤 현실적인 현대화 전략임
  • 글쓴이는 이런 자동화 이식 기법이 앞으로 더 중요해질 거라고 봄. Darpa의 TRACTOR 같은 C→Rust 변환 연구나 형식 기법(Formal Methods)과 결합하면 더 단단해질 수 있다는 얘기도 나옴
  • 즉 “AI를 쓰지 말자”가 아니라, AI로 할 수 있는 이동 경로가 늘어났을 때도 어디로 갈지 판단하는 건 여전히 엔지니어링이라는 입장임

빠진 건 트레이드오프 설명

• 글쓴이가 Bun의 설명에서 가장 크게 지적하는 건 기술 결정문서의 기본 재료가 부족하다는 점임

  • 좋은 기술 결정 설명에는 보통 동기, 검토한 선택지, 각 선택지의 장단점이 들어감
  • Bun 글에는 메모리 버그라는 동기는 있었고, 다른 선택지를 언급하긴 했지만, 장단점 비교가 거의 없었다고 봄
  • 특히 “Bun is better in Rust” 식으로 장점만 늘어놓으면, 이미 답을 정해놓고 사후 정당화하는 느낌을 주기 쉬움

• Rust 이식의 obvious한 비용 중 하나는 빌드 시간인데, 이런 이야기가 충분히 공개되지 않았다는 점도 찝음

  • 일반적으로 큰 Rust 코드베이스는 메모리 안전성을 얻는 대신 컴파일 시간이 늘어나는 비용을 치름
  • Bun은 과거에 빌드 성능이 중요해서 Zig 컴파일러를 포크할 정도였으니, Rust 이식 후 기여자 빌드 시간이 늘었다면 그건 꽤 중요한 트레이드오프임
  • 글쓴이는 “그 비용이 있어도 전체적으로 이득이었다”고 설명하면 오히려 더 신뢰가 생겼을 거라고 봄

• 더 이상한 대목은 스타일 가이드와 엔지니어링 규율을 제대로 검토하지 않은 듯 보이는 부분임

  • Bun 측은 메모리 버그가 자주 발생했다고 말하고, 글쓴이는 관련 수정 커밋이 주당 약 4개 수준이었다고 셈함
  • 그런데 메모리 버그가 반복된다면 먼저 소유권 규칙, 포인터 전달 규칙, 할당 규칙 같은 팀 차원의 스타일과 리뷰 체계를 세우는 게 자연스러움
  • Zig 쪽 대표 사례로 TigerBeetle이 나오는데, 이 프로젝트는 TigerStyle이라는 강한 규율과 테스트 전략으로 매우 높은 신뢰성을 만든 사례로 소개됨

“AI가 다 한다”면서 왜 가독성을 걱정하나

• 글쓴이는 Bun 측 설명에서 약간 모순처럼 보이는 부분도 집요하게 물고 늘어짐

  • Bun 글은 Zig에서 소유권을 명확히 표현하려면 SharedPtr 같은 래퍼와 defer 호출이 늘어나 코드가 덜 예뻐진다고 예시를 듦
  • 그런데 같은 사람이 “우리는 몇 달 동안 직접 코드를 타이핑하지 않았다”고 말하는 상황이라면, 가끔 3줄 더 쓰는 게 정말 그렇게 큰 문제냐는 질문이 나옴
  • “사람이 코드를 안 읽어도 되는 시대”라고 말하면서 동시에 사람이 읽기 불편한 문법을 이유로 드는 건 앞뒤가 애매하다는 지적임

• 여기서 글쓴이가 끌어내는 결론은 꽤 날카로움. AI가 충분하지 않기 때문에 Rust도, 리뷰도, 가독성도, 익숙한 코드 구조도 여전히 필요하다는 것

  • LLM을 에이전트 하네스로 감싸는 이유도 AI가 혼자 충분하지 않아서임
  • Bun이 Rust의 borrow checker를 선택한 것도 AI가 use-after-free를 완전히 막아주지 못해서임
  • 포인터 래퍼가 읽기 어렵다고 걱정하는 것도 결국 사람 유지보수자가 여전히 중요해서임
  • 오픈소스 메인테이너들이 저품질 AI 기여를 걸러내느라 힘든 것도 AI가 충분하지 않다는 신호임

조직 운영 문제도 기술 문제로 돌아옴

• 글쓴이는 Bun의 초기 채용 문구도 끌고 와서, 이 프로젝트의 기술 문제가 조직 문화와 무관하지 않을 수 있다고 봄

  • 2022년 Oven의 채용 문구에는 첫 9개월 정도는 grind가 될 거고, 워라밸을 중시하면 맞지 않을 수 있다는 뉘앙스가 있었다고 함
  • 글쓴이는 이런 “항상 크런치 모드”가 지식 노동에서 건강에도 생산성에도 나쁘다는 건 이미 꽤 잘 알려진 사실이라고 말함
  • Andrew Kelley가 들었다는 Bun 팀 내부 경험도 “커뮤니케이션 부족, 비현실적 기대, 낮은 공감, 경험 부족” 같은 이야기였고, 글쓴이는 이게 공개된 채용 문구와 크게 다르지 않다고 봄

• 중요한 건 나쁜 환경에서도 좋은 기술이 나올 수는 있지만, 그 비용이 코드베이스에 쌓일 수 있다는 점임

  • 글쓴이는 Bun 자체를 써봤고 꽤 괜찮았다고 말함. 즉 제품을 싸잡아 까는 글은 아님
  • 다만 Bun 측이 스스로 “Zig 코드가 버그 많고 유지보수 어려웠다”고 말한다면, 그 원인을 언어 하나로 몰기 전에 팀 운영과 설계 규율도 같이 봐야 한다는 얘기임

• 최종 메시지는 꽤 단순함. AI 코딩 도구를 쓰되, “소프트웨어 엔지니어링이 끝났다”는 식의 과대서사는 경계하자는 것

  • AI 에이전트는 레거시 변환, 반복 작업, 코드 탐색에서 강력한 도구가 될 수 있음
  • 하지만 좋은 아키텍처 결정, 명확한 트레이드오프 설명, 리뷰 가능한 변경 단위, 팀 커뮤니케이션은 여전히 필요함
  • 글쓴이 표현을 빌리면, 더 나은 도구를 사는 대신 토큰을 사고, 기술을 배우는 대신 SKILL.md를 붙여넣고, 팀 운영을 배우는 대신 병렬 에이전트 세션을 “팀”이라고 부르는 흐름은 위험함

---

기술 맥락

• 이 사건에서 실제 기술 선택은 “Zig로 계속 가면서 규율을 강화할 것인가, Rust로 옮겨 컴파일러의 안전장치를 살 것인가”에 가까워요. Rust는 borrow checker로 메모리 안전성을 강하게 밀어붙일 수 있어서 use-after-free 같은 버그가 반복되는 팀에는 매력적인 선택이거든요.

• 다만 Rust로 옮긴다고 공짜는 아니에요. 큰 코드베이스에서는 빌드 시간이 늘 수 있고, unsafe Rust로 파일 단위 이식을 했다면 Rust의 안전성 이점을 처음부터 100% 얻는 것도 아니에요. 그래서 이런 결정은 “좋아졌다”만 말하면 부족하고, 어떤 비용을 받아들였는지 같이 설명해야 해요.

• Zig를 계속 썼을 때의 대안도 단순히 “참고 버틴다”가 아니에요. TigerBeetle처럼 메모리 할당 규칙, 스타일 가이드, 테스트 전략을 강하게 가져가면 Zig에서도 신뢰성 높은 시스템을 만들 수 있어요. 글쓴이가 답답해하는 부분은 Bun이 이 경로를 얼마나 진지하게 시도했는지 잘 보이지 않는다는 점이에요.

• AI 에이전트는 여기서 도구이자 논쟁의 불씨예요. 대규모 포팅을 빠르게 진행하는 데 도움을 줄 수 있지만, 왜 포팅하는지, 어떤 위험을 감수하는지, 결과를 어떻게 검증하는지는 여전히 사람이 설계해야 하거든요. 그래서 이 글의 결론은 AI 반대가 아니라, AI를 핑계로 엔지니어링 판단을 생략하지 말자는 쪽에 가까워요.