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

3 hours ago 2

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로 옮긴 결정을 메인 브랜치에 병합하고 두 달이 지나서야 해명함
- 대규모 인프라 프로젝트라면 방향을 사전에 설명하는 편이 일반적임
- 해명이 늦어진 사이 Anthropic’s Bun Rust rewrite merged at speed of AI 같은 제목이 AI가 재작성을 빠르게 끝냈다는 인상을 확산함
Zig 창시자 Andrew Kelley는 반론을 공개하고, 이례적으로 직설적인 어조로 Bun의 기술과 조직 운영을 비판함
- 언어를 바꿨다는 이유로 이전 언어의 리더가 개인적 결함까지 공격하는 선례가 될 수 있다는 평판상 부담이 있음
- 일부는 이를 “meltdown”이라 불렀지만, 공개적으로 짚어야 할 문제를 짚었다고 볼 여지도 있음

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

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

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

Bun은 더 빠른 NodeJS에 비유되는 TypeScript 런타임이고, Zig는 현대적인 C에 비유되는 시스템 프로그래밍 언어임
Bun은 최근까지 Zig로 작성됐으며 가장 큰 Zig 코드베이스 중 하나였음
두 프로젝트의 AI 기여 정책은 정반대임
- Bun은 코드 기여가 거의 100% AI라고 밝힘
- 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개월이 매우 고될 것이며, 일하지 않는 시간이 많은 형태의 일과 삶의 균형을 중시한다면 맞지 않을 것이라고 경고함
상시 크런치 모드는 건강과 생산성 모두에 해로우며, 지식 노동에 관한 경험적 연구에서도 반복적으로 확인됨
- 관련 자료로 Empirical Software Engineering의 Human Factors 부분을 참고할 수 있음
주 90시간 근무를 자랑하는 관리자보다 구성원이 밤에 잘 수 있도록 보호하는 관리자를 선택해야 함
Andrew Kelley가 Bun 팀 관계자에게 들었다는 평가는 소통 부족, 비현실적 기대, 낮은 공감, 경험 부족으로 요약되지만 전언이라는 한계가 있음
다만 이 평가는 채용 공지에서 공개한 극단적인 근무 환경과도 일치함
나쁜 업무 환경에서도 훌륭한 기술은 나올 수 있으며, Bun 자체는 쓸 만하고 흥미로운 도구임
코드에 버그가 많고 유지보수하기 어려웠다는 평가는 외부 비판에 그치지 않고, Bun이 Rust 전환의 근거로 내세운 상태이기도 함

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

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

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

기술적 결정을 설명하려면 최소한 세 요소가 필요함
- 동기가 무엇인가
- 어떤 대안을 검토했는가
- 각 대안의 장단점은 무엇인가
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이라고 부르는 것은 인간 조직과 자동 실행 세션을 혼동함