참고로 Jarred Sumner가 이 건에 대해 HN에서 한 말은 이렇다고 함: Bun 작업자이고 이건 자기 브랜치이며, 이 스레드는 동작하지 않는 코드에 대한 과잉반응이라는 입장임
아직 재작성하겠다고 확정한 게 아니고, 이 코드가 전부 버려질 가능성도 매우 높다고 함
작동하는 버전이 어떤 모습인지, 성능은 어떤지, Bun 테스트 스위트를 통과시키고 유지보수 가능하게 만드는 난이도가 어떤지 보고 싶고, 실현 가능한 Rust 버전과 Zig 버전을 나란히 비교하고 싶다는 취지임
“거짓말은 진실이 신발을 신는 동안 지구 반 바퀴를 돈다”는 말이 떠오름
대중문화식 기술 해석은 대부분 즉각적 반응에 기대는 경우가 많음
Bun의 일반 풀 리퀘스트도 꽤 난장판임: https://github.com/oven-sh/bun/pulls?q=is%3Apr+
대부분은 @robobun이 자율적으로 만들고, GitHub 액션으로 중복 여부를 확인하며(Claude 기반), @coderabbitai와 @claude가 리뷰함
그 와중에 CI는 깨져 있고, @robobun은 자기가 만든 다른 PR과 중복된다는 이유로 자기 PR 일부를 결국 닫음
main 병합은 아직 사람이 함
이건 예상 못 했음
Bun은 Jarred의 성능 집착 때문에 칭찬받던 걸로 기억하는데, 코드베이스에서 LLM이 이렇게 날뛰게 둘 줄은 몰랐음
이건 말도 안 됨
“관용구 매핑”을 보면 unsafe가 도배되어 있고, Rust답지 않은 코드가 대량으로 나올 것 같음 @fieldParentPtr("field", ptr) 매핑은 특히 거칠어 보임
다만 “phase A”가 사실상 줄 단위 번역이고, 이후 프롬프트로 더 관용적이고 유지보수 가능한 Rust로 리팩터링하려는 듯함
문제는 언어 설계가 구현 방향을 강하게 밀어붙일 수 있고 실제로도 그러므로, 나중에 풀어내기 힘든 꼬임이 생길 가능성이 크다는 점임
결국은 오래된 방식의 수작업 재작성이 더 나은 길이었을 것 같음
관용적이고 안전한 코드로 만드는 건 다음 단계에서 LLM이 할 수도 있을 듯함
특히 Anthropic 정도의 자금력이 있으면, AI의 편한 점은 같은 코드를 반복해서 리팩터링해도 지치지 않는다는 데 있음
마이그레이션 자체와 별개로, 이들이 택한 방식이 특히 흥미로움
링크된 docs/PORTING.md에는 포팅 규칙이 약 300개 있는데, 어떤 LLM도 이걸 전부 “기억”하고 충실히 따르기엔 너무 많아 보임
Anthropic이 Bun을 소유하고 있으니 이 포팅에는 사실상 무한 토큰 예산이 있을 테고, 어쩌면 파일 수 * 규칙 수만큼 에이전트를 띄워 전부 지켜졌는지 “보장”하려 할 수도 있음
또 포팅을 두 단계로 나눔: A는 각 파일을 고립된 상태로 거칠게 포팅하고 컴파일이 깨질 것으로 예상, B는 전체를 연결해 컴파일되게 만듦
phase A에서는 에이전트에게 코드가 “컴파일될 필요는 없다”고 말하고, 각 포팅 파일을 출력 품질에 따라 낮음/중간/높음으로 채점하게 함
낮음은 로직이 틀림, 중간은 로직은 맞지만 컴파일되지 않음, 높음은 로직도 맞고 컴파일될 것 같다는 뜻임
내가 이해하고 쓰는 코딩 에이전트 방식과는 정반대라 결과가 궁금함
내 감각으로는 컴파일될 필요가 없다고 해서 명확한 “종료 목표”를 주지 않으면 결과가 매우 예측 불가능해지고, phase B에서 신뢰할 수 없는 코드 산더미를 리뷰해야 할 것 같음
빠르게 grep해 보니 이런 출력 품질 점수 1279개 중 약 3%는 낮음, 80%는 중간, 17%는 높음이었음
2026년 5월 기준으로 규칙 300개는 괜찮아 보임 PORTING.md는 약 16k 토큰이고, 주요 작업에 집중하고 있음
새 하위 에이전트에게는 나쁘지 않고 아마 이상적일 수도 있음
실제로 Rust 전환을 원하는 건지, 아니면 Anthropic LLM 테스트인지 궁금함
내 안의 음모론자는 Zig의 최근 AI 보조 기여 금지와 Mattew Lugg의 Bun 언어 포크 비판 때문에 이러는 거라고 말함
Anthropic이 Zig에서 가장 인기 있는 프로젝트 중 하나인 Bun을 다른 언어로 옮긴다면, 꽤 노골적인 힘 과시가 될 수 있음
물론 이 드라마성 가설을 완전히 믿지는 않고, 그냥 Anthropic의 두둑한 자금으로 제품을 보여주려는 것일 수도 있음
꽤 흥미로워 보임
한 번에 처리해야 할 규칙 묶음은 엄청난 코드 리뷰 주기를 거치지 않고는 검증이 불가능해 보임
토큰은 많겠지만, 이런 변환 뒤에는 코드를 사실상 검증하기가 매우 어려워질 것 같음
테스트도 같은 과정을 거쳐야 한다면, 결국 진실의 기준으로 남는 게 무엇인지 의문임
그래도 실험 자체로는 대단함
Node.js 킬러들이 어떻게 지내는지 보면, Deno는 권한 시스템이나 TypeScript 기본 지원 같은 미미한 개선을 제공했지만 세상을 뒤흔들지는 못했고, 이런 기능들도 Node.js로 역수입되고 있음
써본 바로는 개발자 경험이 의미 있게 낫지 않았고, pnpm 같은 훌륭한 도구 때문에 오히려 더 나쁜 경우도 있었음
더 빠를 수는 있지만 지난 5~6년 동안 내 사용 범위에서는 Node.js 성능 문제를 딱히 느끼지 못했음
JSR도 세상을 뒤흔들지 못했고, 커뮤니티는 대신 now 더 나은 경험을 제공하는 npmx를 만들었음
다만 Deno의 표준 라이브러리, 예를 들어 @std/collections는 꽤 좋아서 쓰고 있음
Bun은 범위가 너무 넓어서 처음부터 위험 신호가 많았지만, Jarred가 몇 년이 걸리더라도 최고의 만능 JS 런타임을 만들려는 듯해 조심스럽게 낙관했음
그런데 Anthropic에 인수되고 Jarred가 이제 꽤 많은 ~~바이브코딩~~ 에이전트식 개발을 하는 모습, 그리고 이번 바이브 포팅 소식까지 보니, 실험 브랜치라 해도 내가 쓸 프로젝트는 아니라는 판단이 굳어짐
그래서 Node.js가 여전히 지배함
진지하게 말하면 내장 TypeScript 기능과 SQLite는 대단함
완전히 반AI는 아니고, 아주 특정한 문제를 풀기 위해 작은 Python 스크립트나 웹앱을 바이브코딩하는 건 재미있고 유용하다고 봄
하지만 많은 움직이는 부분과 사용자가 있는 복잡한 프로젝트에서 대규모 “에이전트식 개발”은 기능 개발을 일시적으로 빠르게 해도 결국 프로젝트를 불안정하게 만들고 부풀리는 순손실이라는 확신이 반복해서 강해짐
VSCode, Cursor, mise, Perplexity 웹 UI 같은 예가 떠오름
스크롤할 때 버벅이지 않는 JS 드롭다운 하나 만드는 게 그렇게 어려운가 싶음
내가 의존하는 더 많은 큰 도구·라이브러리·프로젝트들이 이를 알아보고 더 엄격한 반AI 정책을 채택하길 바람
배경을 말하면, 1만~10만 줄 사이의 Rust 코드베이스를 대략 6개 정도 유지보수했지만 10만 줄을 넘는 건 없었음
또 2만 줄짜리 Rust 프로그램이 30만 줄짜리 Go 프로그램의 핵심 기능을 구현한 사례도 몇 개 알고 있음
그래서 정확히 말한 조건과는 다름
하지만 1만~10만 줄 범위에서는 유지보수자로서 Rust에 매우 만족함
이 정도 크기는 프로그램이 충분히 집중될 만큼 작으면서도 하나의 핵심 아이디어를 충실히 구현할 만큼 큼
이 크기에서는 언어 자체와 도구가 모두 큰 자산이었고, 적어도 내 개인적 경험으로는 그랬음
cargo-nextest는 현재 주석과 빈 줄을 제외하고 Rust 코드 84k줄이고, 단독 유지보수자로서 내 개인적 품질 기준에 맞춰 다른 언어로 작성하는 건 가능하지 않다고 봄
Lobste.rs 의견들
참고로 Jarred Sumner가 이 건에 대해 HN에서 한 말은 이렇다고 함: Bun 작업자이고 이건 자기 브랜치이며, 이 스레드는 동작하지 않는 코드에 대한 과잉반응이라는 입장임
아직 재작성하겠다고 확정한 게 아니고, 이 코드가 전부 버려질 가능성도 매우 높다고 함
작동하는 버전이 어떤 모습인지, 성능은 어떤지, Bun 테스트 스위트를 통과시키고 유지보수 가능하게 만드는 난이도가 어떤지 보고 싶고, 실현 가능한 Rust 버전과 Zig 버전을 나란히 비교하고 싶다는 취지임
대중문화식 기술 해석은 대부분 즉각적 반응에 기대는 경우가 많음
Bun의 일반 풀 리퀘스트도 꽤 난장판임: https://github.com/oven-sh/bun/pulls?q=is%3Apr+
대부분은 @robobun이 자율적으로 만들고, GitHub 액션으로 중복 여부를 확인하며(Claude 기반), @coderabbitai와 @claude가 리뷰함
그 와중에 CI는 깨져 있고, @robobun은 자기가 만든 다른 PR과 중복된다는 이유로 자기 PR 일부를 결국 닫음
main 병합은 아직 사람이 함
Bun은 Jarred의 성능 집착 때문에 칭찬받던 걸로 기억하는데, 코드베이스에서 LLM이 이렇게 날뛰게 둘 줄은 몰랐음
이건 말도 안 됨
“관용구 매핑”을 보면
unsafe가 도배되어 있고, Rust답지 않은 코드가 대량으로 나올 것 같음@fieldParentPtr("field", ptr)매핑은 특히 거칠어 보임다만 “phase A”가 사실상 줄 단위 번역이고, 이후 프롬프트로 더 관용적이고 유지보수 가능한 Rust로 리팩터링하려는 듯함
문제는 언어 설계가 구현 방향을 강하게 밀어붙일 수 있고 실제로도 그러므로, 나중에 풀어내기 힘든 꼬임이 생길 가능성이 크다는 점임
결국은 오래된 방식의 수작업 재작성이 더 나은 길이었을 것 같음
특히 Anthropic 정도의 자금력이 있으면, AI의 편한 점은 같은 코드를 반복해서 리팩터링해도 지치지 않는다는 데 있음
마이그레이션 자체와 별개로, 이들이 택한 방식이 특히 흥미로움
링크된
docs/PORTING.md에는 포팅 규칙이 약 300개 있는데, 어떤 LLM도 이걸 전부 “기억”하고 충실히 따르기엔 너무 많아 보임Anthropic이 Bun을 소유하고 있으니 이 포팅에는 사실상 무한 토큰 예산이 있을 테고, 어쩌면
파일 수 * 규칙 수만큼 에이전트를 띄워 전부 지켜졌는지 “보장”하려 할 수도 있음또 포팅을 두 단계로 나눔: A는 각 파일을 고립된 상태로 거칠게 포팅하고 컴파일이 깨질 것으로 예상, B는 전체를 연결해 컴파일되게 만듦
phase A에서는 에이전트에게 코드가 “컴파일될 필요는 없다”고 말하고, 각 포팅 파일을 출력 품질에 따라 낮음/중간/높음으로 채점하게 함
낮음은 로직이 틀림, 중간은 로직은 맞지만 컴파일되지 않음, 높음은 로직도 맞고 컴파일될 것 같다는 뜻임
내가 이해하고 쓰는 코딩 에이전트 방식과는 정반대라 결과가 궁금함
내 감각으로는 컴파일될 필요가 없다고 해서 명확한 “종료 목표”를 주지 않으면 결과가 매우 예측 불가능해지고, phase B에서 신뢰할 수 없는 코드 산더미를 리뷰해야 할 것 같음
빠르게 grep해 보니 이런 출력 품질 점수 1279개 중 약 3%는 낮음, 80%는 중간, 17%는 높음이었음
PORTING.md는 약 16k 토큰이고, 주요 작업에 집중하고 있음새 하위 에이전트에게는 나쁘지 않고 아마 이상적일 수도 있음
실제로 Rust 전환을 원하는 건지, 아니면 Anthropic LLM 테스트인지 궁금함
Anthropic이 Zig에서 가장 인기 있는 프로젝트 중 하나인 Bun을 다른 언어로 옮긴다면, 꽤 노골적인 힘 과시가 될 수 있음
물론 이 드라마성 가설을 완전히 믿지는 않고, 그냥 Anthropic의 두둑한 자금으로 제품을 보여주려는 것일 수도 있음
꽤 흥미로워 보임
한 번에 처리해야 할 규칙 묶음은 엄청난 코드 리뷰 주기를 거치지 않고는 검증이 불가능해 보임
토큰은 많겠지만, 이런 변환 뒤에는 코드를 사실상 검증하기가 매우 어려워질 것 같음
테스트도 같은 과정을 거쳐야 한다면, 결국 진실의 기준으로 남는 게 무엇인지 의문임
그래도 실험 자체로는 대단함
Node.js 킬러들이 어떻게 지내는지 보면, Deno는 권한 시스템이나 TypeScript 기본 지원 같은 미미한 개선을 제공했지만 세상을 뒤흔들지는 못했고, 이런 기능들도 Node.js로 역수입되고 있음
써본 바로는 개발자 경험이 의미 있게 낫지 않았고, pnpm 같은 훌륭한 도구 때문에 오히려 더 나쁜 경우도 있었음
더 빠를 수는 있지만 지난 5~6년 동안 내 사용 범위에서는 Node.js 성능 문제를 딱히 느끼지 못했음
JSR도 세상을 뒤흔들지 못했고, 커뮤니티는 대신 now 더 나은 경험을 제공하는 npmx를 만들었음
다만 Deno의 표준 라이브러리, 예를 들어
@std/collections는 꽤 좋아서 쓰고 있음Bun은 범위가 너무 넓어서 처음부터 위험 신호가 많았지만, Jarred가 몇 년이 걸리더라도 최고의 만능 JS 런타임을 만들려는 듯해 조심스럽게 낙관했음
그런데 Anthropic에 인수되고 Jarred가 이제 꽤 많은 ~~바이브코딩~~ 에이전트식 개발을 하는 모습, 그리고 이번 바이브 포팅 소식까지 보니, 실험 브랜치라 해도 내가 쓸 프로젝트는 아니라는 판단이 굳어짐
그래서 Node.js가 여전히 지배함
진지하게 말하면 내장 TypeScript 기능과 SQLite는 대단함
완전히 반AI는 아니고, 아주 특정한 문제를 풀기 위해 작은 Python 스크립트나 웹앱을 바이브코딩하는 건 재미있고 유용하다고 봄
하지만 많은 움직이는 부분과 사용자가 있는 복잡한 프로젝트에서 대규모 “에이전트식 개발”은 기능 개발을 일시적으로 빠르게 해도 결국 프로젝트를 불안정하게 만들고 부풀리는 순손실이라는 확신이 반복해서 강해짐
VSCode, Cursor, mise, Perplexity 웹 UI 같은 예가 떠오름
스크롤할 때 버벅이지 않는 JS 드롭다운 하나 만드는 게 그렇게 어려운가 싶음
내가 의존하는 더 많은 큰 도구·라이브러리·프로젝트들이 이를 알아보고 더 엄격한 반AI 정책을 채택하길 바람
Node를 더 낫게 만들도록 압박했기 때문임
Node는 예전엔 일부러 btoa를 구현하지 않았을 정도였음
하지만 결국 둘 다 각주로 남을 것 같음
말 그대로 잘못된 방향임
중간 규모, 즉 수십만 줄 이상 Rust 프로젝트를 유지보수하면서 큰 코드베이스에서의 확장성에 만족하는 Rust 유지보수자를 한 명도 못 봤음
Rust는 큰 코드베이스에 특히 훌륭하다고 봄:
https://matklad.github.io/2023/03/28/rust-is-a-scalable-language.html
https://ferrous-systems.com/blog/rust-as-productive-as-kotlin/
다만 효율적으로 다루려면 어느 정도 자신이 뭘 하는지 알아야 함:
https://matklad.github.io/2021/09/05/Rust100k.html
이런 맥락에서 Zig가 Rust와 비교해 어떤지는 잘 모름
TigerBeetle은 설계 방식이 꽤 특수함
또 2만 줄짜리 Rust 프로그램이 30만 줄짜리 Go 프로그램의 핵심 기능을 구현한 사례도 몇 개 알고 있음
그래서 정확히 말한 조건과는 다름
하지만 1만~10만 줄 범위에서는 유지보수자로서 Rust에 매우 만족함
이 정도 크기는 프로그램이 충분히 집중될 만큼 작으면서도 하나의 핵심 아이디어를 충실히 구현할 만큼 큼
이 크기에서는 언어 자체와 도구가 모두 큰 자산이었고, 적어도 내 개인적 경험으로는 그랬음
cargo-nextest는 현재 주석과 빈 줄을 제외하고 Rust 코드 84k줄이고, 단독 유지보수자로서 내 개인적 품질 기준에 맞춰 다른 언어로 작성하는 건 가능하지 않다고 봄아마 이 때문일 수도 있음: https://github.com/oven-sh/bun/issues/28001
이건 시간적 메모리 안전성 문제가 아님