▲

Bun(JS 런타임)이 Zig에서 Rust로 바이브 포팅되고 있음

 (github.com/oven-sh)
4P by GN⁺ 3시간전 | ★ favorite | 댓글 2개
  • Bun 창시자 Jarred Sumner가 Zig → Rust 포팅 가이드(PORTING.md)를 claude/phase-a-port 브랜치에 커밋하며, AI 에이전트를 활용한 대규모 언어 전환 실험이 공개됨
  • 포팅은 Phase A(파일 단위로 로직만 초벌 번역, 컴파일 불필요)와 Phase B(크레이트별 컴파일 통과)로 나뉘며, 약 300개의 타입·관용구 매핑 규칙을 LLM에게 제공하는 방식
  • Sumner 본인이 Hacker News에서 "리라이트를 확정한 것이 아니며, 이 코드가 전부 버려질 가능성이 높다"고 밝혀, 현 시점에서는 실험적 탐색 단계
  • 커뮤니티에서는 Anthropic 인수 이후 Zig의 AI 기여 금지 정책과의 충돌, Bun이 이미 Zig를 포크해 운영 중인 점, Rust 생태계의 안전성 이점 등이 배경으로 거론됨
  • PR 대부분이 @robobun(AI 봇)에 의해 자동 생성되고 CodeRabbitAI와 Claude가 리뷰하는 구조로 진행되어, AI 주도 대규모 코드 마이그레이션의 현실적 가능성과 한계를 보여주는 사례

포팅 가이드(PORTING.md) 핵심 구조

  • 포팅 대상은 Zig 파일 하나를 동일 디렉토리에 .rs 파일로 변환하는 것이며, Phase A에서는 로직의 충실한 재현이 목표이고 컴파일 여부는 무관
  • tokio, rayon, hyper, async-trait, std::fs, std::net 등 외부 비동기·I/O 크레이트 사용 금지 — Bun이 자체 이벤트 루프와 시스콜을 소유하기 때문
  • async fn 금지, 모든 비동기 처리는 Zig와 동일하게 콜백 + 상태 머신 방식 유지
  • 확신할 수 없는 부분은 // TODO(port):로, 성능 관련 Zig 관용구는 // PERF(port):로 표시하여 Phase B에서 처리

타입·관용구 매핑 규칙

  • []const u8 → &[u8](절대 &str 아님), ?T → Option<T>, anyerror!T → Result<T, bun_core::Error> 등 약 50개 이상의 타입 매핑 테이블 제공
  • defer x.deinit() → 삭제 후 impl Drop으로 대체, errdefer → scopeguard 사용, comptime → const generic·const fn·macro_rules!로 변환
  • 문자열은 바이트 기반 처리 원칙: std::string::String이나 &str 사용을 금지하고 &[u8]/Vec<u8> 사용 — Bun이 WTF-8과 임의 바이트를 다루기 때문
  • @intCast → T::try_from(x).unwrap()(항상 검사), @truncate → x as T(의도적 래핑), @bitCast → transmute 등 Zig 내장 함수별 Rust 대응 정리

크레이트 맵과 소유권 모델

  • @import("bun").X 등 Zig 네임스페이스를 bun_str, bun_sys, bun_jsc, bun_alloc 등 약 30개 Rust 크레이트에 1:1 매핑
  • AST/파서 크레이트는 bumpalo::Bump 아레나 유지, 그 외 크레이트는 글로벌 mimalloc 할당자 사용으로 allocator 파라미터 삭제
  • bun.ptr.Owned → Box<T>, bun.ptr.Shared → Rc<T>, bun.ptr.AtomicShared → Arc<T> 등 포인터 소유권 매핑

커뮤니티 반응 (Lobsters·HN)

  • "정말 Rust로 전환하려는 건지, Anthropic LLM의 쇼케이스인지" 의문을 제기하는 의견 다수
  • Zig의 AI 기여 금지 정책과 Anthropic의 AI 중심 개발 워크플로 간 충돌이 배경일 수 있다는 추측, 다만 음모론 수준이라는 자평도 함께 존재
  • 약 300개 규칙을 LLM이 충실히 따를 수 있는지에 대한 회의적 시각 — "~16k 토큰이라 서브에이전트에게는 적당하다"는 긍정적 평가도 병존
  • "Phase A에서 컴파일 안 되는 코드를 먼저 만드는 접근이 기존 코딩 에이전트 사용법과 정반대"라는 흥미로운 관찰
  • Bun의 Zig 포크 유지 부담, Zig의 잦은 브레이킹 체인지, 아직 베타 단계인 언어에 핵심 제품을 의존하는 리스크 등이 전환 동기로 언급됨

함께 보면 좋은 글 β

▲
GN⁺ 2시간전  [-]
Hacker News 의견들

  • Bun에서 일하고 있고, 이건 내 브랜치임
    이 스레드는 전체적으로 과잉 반응임. 동작하지 않는 코드에 댓글이 302개나 달렸지만, 아직 다시 작성하겠다고 확정한 게 아니고 이 코드가 전부 폐기될 가능성도 매우 높음
    동작하는 버전이 어떤 모습인지, 어떤 느낌인지, 성능은 어떤지, Bun의 테스트 묶음을 통과시키고 유지보수 가능하게 만드는 일이 얼마나 어려운지 보고 싶음. 실현 가능한 Rust 버전과 Zig 버전을 나란히 비교해보고 싶음

    • 실험 브랜치에 실험 커밋 하나 올렸다고 일부 사람들이 열광적 반응을 터뜨리는 건 아쉬움. 감정을 잠깐 내려놓고 장점 기준으로 보면, 이런 접근을 연구하려는 동기에는 아마 동의할 사람들도 많을 것임
      “Bun 테스트 묶음을 통과시키고 유지보수 가능하게 만들기 어렵냐”는 부분은, 매달 에이전트로 코드 이식 과정을 완전히 추상화할 기회가 새로 생기고 있고 모두 언어학 기반이라는 점에서 흥미로운 시대임
      비슷하게 흥미롭고 닮은 사례를 찾는다면 몇 달 전 Cloudflare가 Next.js를 이식한 vinext를 볼 만함. 초반에는 적응 문제가 있었지만 지금은 몇몇 운영 프로젝트에서 큰 문제 없이 쓰고 있음
      [0] - https://github.com/cloudflare/vinext
    • Bun 작업은 좋아하지만, 최근 프로젝트 품질에 대한 우려가 계속 나오는 걸 어떻게 보는지 궁금함. 일부는 흔한 Twitter식 혐오일 수 있지만 실제 문제도 있음
      운영에 영향을 주는 버그가 방치된 상태에서 JavaScript 런타임 안에 이미지 처리나 웹뷰를 왜 추가하는지 사람들이 묻는 건 타당해 보임. 예를 들어 우리에게 가장 큰 차단 요소 중 하나는 https://github.com/oven-sh/bun/issues/6608이고, 2023년에 보고됐는데 3년 뒤에도 여전히 영향을 받고 있음
    • Rust를 검토하는 주된 동기가 무엇인지 궁금함
      참고로 마지막으로 Bun을 써봤을 때는 Bun.write 같은 부분에서 Rust가 도움이 됐을 법한 버그 몇 개를 만났음
      [0]: https://mastrojs.github.io/blog/2025-10-29-what-struggled-wi...)
    • 정당한 연구에 이렇게 큰 반발이 나오는 건 아쉬움. Bun은 일부에게, 특히 Rust에 불만이 있고 어떤 이유로든 Zig가 “Rust를 이기길” 바라는 사람들 사이에서 Zig의 대표 프로젝트처럼 여겨지는 경우가 있음
      결국 언어나 도구와 상관없이 프로젝트와 상황에 가장 맞는 선택을 하면 됨. 개인적으로 이 실험은 흥미롭고 어떻게 전개될지 궁금함. 관용적인 Rust를 쓰려면 사고방식 전환이 필요하니, LLM이 시간이 지나며 거기에 얼마나 잘 적응하는지도 볼 만함
    • 결과가 차분하게 궁금함
      코드가 우아하고, 단지 유지보수 가능할 뿐 아니라 미래 친화적이고 성능 좋은 형태가 되길 바람

  • HN 현재 상위 글이 Anthropic의 Bun 인수 때문에 Bun을 걱정하는 내용인 상황에서 이걸 보니 흥미로움. 거기 상위 댓글은 “Anthropic은 자기 코드베이스에서 실험하지, Bun 팀이 같은 식의 바이브 코딩 실험을 하진 않을 것” 같은 분위기였음
    그런데 지금 보이는 건 바이브 코딩으로 하는 대규모 작업처럼 보임
    결과는 시간이 말해주겠지만, Bun 유지보수자들이 여기서 무엇을 하고 있고 왜 하는지 설명해주면 좋겠음

    • 최근 Zig에 개선을 업스트림하려 했지만, Zig가 엄격한 AI 코드 금지 규칙을 갖고 있어서 막혔음. 이 반응이 Zig에 압박을 넣으려는 것인지, 아니면 실용적 이유로 옮기는 것인지는 각자 판단할 일임
      아마 둘 다 조금씩일 것 같음
    • 이게 생각보다 큰 작업은 아닐 수도 있음. 지난 몇 주 동안 AI로 Postgres를 Rust로 다시 작성하는 실험을 해봤는데, AI는 이런 재작성 작업에 상당히 뛰어났음
      참고할 기존 코드베이스가 있으면 바이브 코딩에서 생기는 많은 문제가 줄어듦. 잘 동작하는 기존 아키텍처가 있고, 대조할 테스트 묶음도 있음
      한 달 동안 아무것도 없는 상태에서 Postgres 테스트 묶음의 95% 이상을 통과하는 상태까지 왔음. Jarred가 Bun을 만든 사람이라면 훨씬 빠르게 갈 수 있을 것 같음
      [0] https://github.com/malisper/pgrust
    • 이 팀들 사이에 겹치는 사람이 있는지는 모르겠지만, Anthropic 자체는 Rust 생태계에 꽤 투자하고 있는 것처럼 보임
      최근 내부 도구 일부를 Connect RPC의 공식 Rust 구현으로 제안했음. Protobuf 기반 라이브러리 묶음이라 새 Rust 기반 Protobuf 컴파일러인 Buffa도 포함됨
      [0]: https://github.com/orgs/connectrpc/discussions/7#discussionc...
      [1]: https://connectrpc.com/
      [2]: https://github.com/anthropics/buffa
    • Claude가 Zig보다 Rust를 더 잘 다룰 것 같음
    • 왜 꼭 설명해야 하는지 모르겠음. 이건 초기 리팩터링과 언어 이전을 위한 기반 작업처럼 보일 뿐이고, 아직 실제로 Zig에서 Rust로 바꾸겠다고 확정한 것도 아님
      투자자라서 시간을 효과적으로 쓰는지 보고 싶은 거라면 이해하지만, 그 외 사람들에게 왜 중요한지는 잘 모르겠음

  • 시대가 바뀐 게 흥미로움. 2015년에는 이미 성숙한 코드베이스였던 Go 런타임 전체가 C에서 Go로 반자동 재작성됐음. 유지보수자 중 한 명이 그들이 쓰던 C의 부분집합을 대상으로 C-to-Go 변환 도구를 만들어 컴파일되고 동일한 출력을 내게 했고, 이후 결과 코드를 사람이 다시 손봐 더 Go답고 최적화된 형태로 만들었음
    이제는 그냥 언어 모델에게 요청할 수 있음
    슬라이드:
    https://go.dev/talks/2015/gogo.slide#3
    흥미롭게 닮은 점도 있음

    We had our own C compiler just to compile the runtime.
    Bun 팀도 자체 Zig 포크를 유지하고 있음

    • 여기서 큰 차이는 C-to-Go 도구가 아마 결정적이었다는 점임. 여러 번 돌려도 정확히 같은 결과가 나왔을 것임
      사람이 변환 도구를 작성하고 이해하고 테스트하고 버그를 잡았기 때문에 그 결과를 신뢰할 수 있음
      LLM은 비결정적임. 독립적으로 10번 변환시키면 10개의 다른 결과가 나오고, 일부는 크게 다를 수도 있음. 매번 전체를 완전히 검토하지 않고는 검증할 방법이 없음
      사람이 만든 결정적 변환 도구가 완벽하거나 오류가 없다는 뜻은 아니지만, LLM보다 훨씬 더 큰 신뢰를 쌓을 수는 있음

  • 링크된 커밋은 이 제목을 뒷받침하기엔 그다지 설득력이 없어 보임. Claude가 Zig 코드를 Rust로 대량 재작성 중인 브랜치가 있고, 현재 773,950줄 추가와 151줄 삭제 상태임
    [0]: https://github.com/oven-sh/bun/compare/claude/phase-a-port

    • 충격적임. Jarred가 처음 Stripe를 떠났을 때도 대시보드 코드를 다시 쓰는 1만 줄 이상 PR을 여러 개 남겼고, 그걸 처리하는 데 몇 달이 걸렸음. 75만 줄짜리 차이는 사실상 검토 불가능함

    • 이 작업 규모가 궁금해서 cloc 기준 상위 5개를 뽑아봤음

      Language files blank comment code

      Zig 1298 79693 60320 571814
      TypeScript 2600 67434 115281 471122
      JavaScript 4344 36947 37653 290873
      C++ 583 27129 19117 215531
      C 111 21577 83914 199576

  • 성공 가능성은 있지만 더 느린 접근으로, git 커밋 기록을 잠금 단계처럼 따라가며 각 커밋의 동작 의도를 적용하는 방식이 떠오름
    이렇게 한다면 Rust 구현이 문제를 피해간 덕분에 특정 버그 수정 커밋들을 건너뛸 수 있었는지도 알고 싶음

    • 흥미로운 생각이고 더 작은 프로젝트로 한번 시도해볼 수도 있겠음. Bun에는 커밋이 15,000개 이상이라, 수천수만 번의 API 요청 없이 끝내려면 커밋 묶음을 한 프롬프트에서 처리하는 방법이 필요할 것임
    • Bun 이슈 트래커에는 세그멘테이션 오류가 많음. Rust로 가면 상당수를 피해갈 것 같음

  • 최근 Bun/Anthropic이 Zig 컴파일 시간에 불만을 보였던 걸 보면, 즉 바이브 코딩으로 만든 4배 컴파일 속도 향상 PR이 받아들여지지 않았던 점을 감안하면, 기본 Zig보다도 아마 4배 더 긴 컴파일 시간을 내는 언어로 옮기려는 건 “흥미로운” 움직임처럼 보임

    • Zig가 실제로 Rust보다 더 빨리 컴파일된다는 데는 매우 회의적임
      비슷한 코드를 Zig와 C++로 작성해봤는데, 콜드 컴파일은 C++이 여러 배 빨랐고 증분 컴파일은 C++에서 즉시 끝났음
      Rust 프로젝트가 느리게 컴파일되는 주된 이유는 과도한 의존성 사용과 코드 내 메타프로그래밍 남용 때문이라고 봄
      Zig는 여러 컴파일 단위가 없어서 컴파일 병렬화가 되지 않음

  • 이 AI 이식이 어떻게 끝날지 매우 궁금함. 언어나 프레임워크가 프로젝트 발목을 잡고 있지만, 순수하게 사람 힘만으로 다시 작성하기엔 너무 큰 여러 활성 프로젝트에 관여하고 있음
    동적 언어보다 Rust 바이브 코딩에서 더 성공적이었음. Rust 컴파일러의 엄격함이 AI 에이전트가 더 나은 코드를 만들도록 강제하는 것 같기도 함. 확실하진 않고, 내가 Rust에 덜 익숙해서 더 잘하는 것처럼 느끼는 걸 수도 있음

    • Rust는 LLM을 많은 감독 없이 돌리기에 좋은 선택임. 내 경험상 진행 상황을 강하게 모니터링하고, 만들거나 이식하는 대상의 설계 소유권을 사람이 가져야 함
      테스트 하네스는 필수임. 각 반복마다 테스트를 실행해서 다른 부분을 깨지 않았는지 확인해야 함
      지금 TypeScript를 Rust로 이식하는 중이고, 그 과정에서 많이 배웠음. 진행 중인 작업은 여기서 볼 수 있음 https://github.com/mohsen1/tsz/
      배운 점을 공유할 수 있음
    • 몇 가지 작업에서는 Rust 대신 Go를 목표로 삼고 있음. 그래도 비슷하게, Go 프로그래머는 아니지만 충분히 잘 되는 것 같음. 다만 수십 년 동안 다양한 코드베이스를 다뤄왔기 때문에 완전히 순진하게 접근하는 건 아님
      세부 코드 검토를 못 하는 내 한계를 보완하는 방법은 테스트, 통합 테스트, 종단 간 테스트가 내가 신경 쓰는 모든 걸 덮도록 만드는 것임. 그게 없으면 세부 작업을 건너뛰지 않았다고 확신할 수 없음
      벤치마크와 스트레스 테스트도 시키고, 잠재 병목을 찾도록 코드베이스를 분석시켰음. 몇 가지 문제를 찾아 고친 뒤에는 더 나아졌음. 마지막으로 비판적 검토, 리팩터링 기회 탐색 등을 시키면 다음에 고칠 목록을 꽤 잘 만들어줌
      메모리 누수 검사기와 정적 분석 도구를 돌리게 하는 것도 좋은 전략임. 이런 방식으로 찾을 문제가 줄어들면 코드는 아마 끔찍하진 않음. 적어도 어떤 국소 최적점에는 도달한 셈임
      코드 검토가 없다는 건 꽤 끔찍하게 들리지만, AI 보조 코딩에서는 빠르게 가장 큰 병목이 되고 있음. 그 병목을 없애는 건 무섭지만 가능한 코드 양을 몇 단계 끌어올림. 엄격한 컴파일러와 엄격한 메모리 관리는 몇몇 버그 범주를 제거하는 데 도움이 됨
      예전에는 내가 이해하는 언어로 이 작업을 했음. 더 큰 커밋을 일상적으로 다루기 시작하면 검토가 문제가 됨
      이런 큰 코드베이스 작업은 시간이 갈수록 훨씬 쉬워지고 좋아질 거라고 봄. 이 유형의 엔지니어링에서 마주치는 주된 골칫거리는 모델이 의도적으로 지름길을 택하고, 정상 경로 테스트만 하고, 핵심 작업을 나중으로 미루려는 경향임
      많은 모델이 토큰 사용량을 아끼도록 편향돼 있는 것 같음. 꽤 짜증나지만 후속 프롬프트와 테스트로 보완하기는 쉽고, 추가 프롬프트 없이도 더 잘 행동하도록 모델이 조정되면 덜한 문제가 될 것 같음
    • 그건 더닝 크루거 효과임. 그래도 인정은 했음
    • 맞음, 쓰레기 같은 Rust 코드를 생성함
      “내가 Rust에 덜 익숙해서 더 잘하는 것처럼 느끼는 걸 수도 있다”라니, 그럴 수도 있겠다고 봄

  • Zig가 성공하길 바라지만 아직 1.x가 아니니 Bun처럼 큰 코드베이스는 큰 호환성 깨짐 변경을 처리하는 데 어려움이 있을 것 같음
    게다가 Bun은 Zig 포크를 쓰고 있음 https://x.com/bunjavascript/status/2048427636414923250?s=20

  • 왜 claude-code를 Rust로 다시 작성하지 않는지 모르겠음
    Anthropic이 claude-code가 Bun을 쓰기 때문에 Bun 팀을 인수했고, 아마 Rust가 “더 낫다”는 이유로 Bun을 Zig에서 Rust로 이식하려는 것 같음. 다시 말해 claude-code를 “더 좋게” 만들고 싶은 걸 텐데, 왜 이렇게 복잡하게 가는지 모르겠음
    가진 LLM 능력을 생각하면 claude-code를 바로 Rust로 써서 최고의 상태로 만들 수 있을 것임

    • 그들은 자기들의 너무 노골적인 “풀뿌리” 마케팅에 넘어가진 않았을 것이고, 훌륭한 엔지니어라면 누구나 알듯이 LLM이 이 작업에 맞는 도구가 아니라는 것도 알 것임
      Bun도 마케팅용 묘기로 보기 쉬움
    • 내가 알기로 claude code는 React를 터미널 UI로 렌더링한 것임. React를 정말 쓰고 싶어 하는 모양임. AI를 너무 많이 하면 뇌에 그런 일이 생기나 봄

  • 지금까지 claude/codex의 놀라움은 대부분 기존 라이브러리의 경계 조건 안에서 만들어지는 애플리케이션에 묶여 있었음. 모델은 인간이 지금까지 만든 Python, requests, ffmpeg 같은 훌륭한 작업물을 직접 활용함
    하지만 괴물이 그 제약 밖으로 뻗어나가는, 즉 라이브러리, DLL, 바이너리를 다시 쓰고 패치하고 이름 바꾸고 재구축하는 단계가 기대됨. 그렇게 되면 라이브러리는 녹아 없어지고, 애플리케이션은 더 효율적이고 안전하며 통합적이지만 완전히 비인간적인 기술 스택의 흔들리는 모래 위에 떠 있게 될 것임
    해석 가능성이나 보안 같은 면에서 분명 끔찍한 생각이지만, 특히 전담 중앙화된 노력이 있다면 작동 불가능하다고 단정하기도 어려움. 수십 년간의 기초적이고 점진적인 개발을 완전히 기계가 다시 쓰는 전면적 슬롭화와 해석 가능성이 반드시 상호 배타적인지도 명확하지 않음

답변달기
▲
GN⁺ 3시간전  [-]
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로 리팩터링하려는 듯함
    문제는 언어 설계가 구현 방향을 강하게 밀어붙일 수 있고 실제로도 그러므로, 나중에 풀어내기 힘든 꼬임이 생길 가능성이 크다는 점임
    결국은 오래된 방식의 수작업 재작성이 더 나은 길이었을 것 같음

    • 관용적이고 안전한 코드로 만드는 건 다음 단계에서 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 정책을 채택하길 바람

  • 말 그대로 잘못된 방향임
    중간 규모, 즉 수십만 줄 이상 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은 설계 방식이 꽤 특수함
    • 배경을 말하면, 1만~10만 줄 사이의 Rust 코드베이스를 대략 6개 정도 유지보수했지만 10만 줄을 넘는 건 없었음
      또 2만 줄짜리 Rust 프로그램이 30만 줄짜리 Go 프로그램의 핵심 기능을 구현한 사례도 몇 개 알고 있음
      그래서 정확히 말한 조건과는 다름
      하지만 1만~10만 줄 범위에서는 유지보수자로서 Rust에 매우 만족함
      이 정도 크기는 프로그램이 충분히 집중될 만큼 작으면서도 하나의 핵심 아이디어를 충실히 구현할 만큼 큼
      이 크기에서는 언어 자체와 도구가 모두 큰 자산이었고, 적어도 내 개인적 경험으로는 그랬음
    • cargo-nextest는 현재 주석과 빈 줄을 제외하고 Rust 코드 84k줄이고, 단독 유지보수자로서 내 개인적 품질 기준에 맞춰 다른 언어로 작성하는 건 가능하지 않다고 봄

  • 아마 이 때문일 수도 있음: https://github.com/oven-sh/bun/issues/28001

    • Rust가 정확히 어떻게 이걸 잡았을지 설명해 줬으면 함
      이건 시간적 메모리 안전성 문제가 아님
답변달기