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년 뒤에도 여전히 영향을 받고 있음
정당한 연구에 이렇게 큰 반발이 나오는 건 아쉬움. 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
왜 꼭 설명해야 하는지 모르겠음. 이건 초기 리팩터링과 언어 이전을 위한 기반 작업처럼 보일 뿐이고, 아직 실제로 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보다 훨씬 더 큰 신뢰를 쌓을 수는 있음
성공 가능성은 있지만 더 느린 접근으로, 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에 덜 익숙해서 더 잘하는 것처럼 느끼는 걸 수도 있다”라니, 그럴 수도 있겠다고 봄
왜 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, 바이너리를 다시 쓰고 패치하고 이름 바꾸고 재구축하는 단계가 기대됨. 그렇게 되면 라이브러리는 녹아 없어지고, 애플리케이션은 더 효율적이고 안전하며 통합적이지만 완전히 비인간적인 기술 스택의 흔들리는 모래 위에 떠 있게 될 것임
해석 가능성이나 보안 같은 면에서 분명 끔찍한 생각이지만, 특히 전담 중앙화된 노력이 있다면 작동 불가능하다고 단정하기도 어려움. 수십 년간의 기초적이고 점진적인 개발을 완전히 기계가 다시 쓰는 전면적 슬롭화와 해석 가능성이 반드시 상호 배타적인지도 명확하지 않음
Hacker News 의견들
Bun에서 일하고 있고, 이건 내 브랜치임
이 스레드는 전체적으로 과잉 반응임. 동작하지 않는 코드에 댓글이 302개나 달렸지만, 아직 다시 작성하겠다고 확정한 게 아니고 이 코드가 전부 폐기될 가능성도 매우 높음
동작하는 버전이 어떤 모습인지, 어떤 느낌인지, 성능은 어떤지, Bun의 테스트 묶음을 통과시키고 유지보수 가능하게 만드는 일이 얼마나 어려운지 보고 싶음. 실현 가능한 Rust 버전과 Zig 버전을 나란히 비교해보고 싶음
“Bun 테스트 묶음을 통과시키고 유지보수 가능하게 만들기 어렵냐”는 부분은, 매달 에이전트로 코드 이식 과정을 완전히 추상화할 기회가 새로 생기고 있고 모두 언어학 기반이라는 점에서 흥미로운 시대임
비슷하게 흥미롭고 닮은 사례를 찾는다면 몇 달 전 Cloudflare가 Next.js를 이식한 vinext를 볼 만함. 초반에는 적응 문제가 있었지만 지금은 몇몇 운영 프로젝트에서 큰 문제 없이 쓰고 있음
[0] - https://github.com/cloudflare/vinext
운영에 영향을 주는 버그가 방치된 상태에서 JavaScript 런타임 안에 이미지 처리나 웹뷰를 왜 추가하는지 사람들이 묻는 건 타당해 보임. 예를 들어 우리에게 가장 큰 차단 요소 중 하나는 https://github.com/oven-sh/bun/issues/6608이고, 2023년에 보고됐는데 3년 뒤에도 여전히 영향을 받고 있음
참고로 마지막으로 Bun을 써봤을 때는 Bun.write 같은 부분에서 Rust가 도움이 됐을 법한 버그 몇 개를 만났음
[0]: https://mastrojs.github.io/blog/2025-10-29-what-struggled-wi...)
결국 언어나 도구와 상관없이 프로젝트와 상황에 가장 맞는 선택을 하면 됨. 개인적으로 이 실험은 흥미롭고 어떻게 전개될지 궁금함. 관용적인 Rust를 쓰려면 사고방식 전환이 필요하니, LLM이 시간이 지나며 거기에 얼마나 잘 적응하는지도 볼 만함
코드가 우아하고, 단지 유지보수 가능할 뿐 아니라 미래 친화적이고 성능 좋은 형태가 되길 바람
HN 현재 상위 글이 Anthropic의 Bun 인수 때문에 Bun을 걱정하는 내용인 상황에서 이걸 보니 흥미로움. 거기 상위 댓글은 “Anthropic은 자기 코드베이스에서 실험하지, Bun 팀이 같은 식의 바이브 코딩 실험을 하진 않을 것” 같은 분위기였음
그런데 지금 보이는 건 바이브 코딩으로 하는 대규모 작업처럼 보임
결과는 시간이 말해주겠지만, Bun 유지보수자들이 여기서 무엇을 하고 있고 왜 하는지 설명해주면 좋겠음
아마 둘 다 조금씩일 것 같음
참고할 기존 코드베이스가 있으면 바이브 코딩에서 생기는 많은 문제가 줄어듦. 잘 동작하는 기존 아키텍처가 있고, 대조할 테스트 묶음도 있음
한 달 동안 아무것도 없는 상태에서 Postgres 테스트 묶음의 95% 이상을 통과하는 상태까지 왔음. Jarred가 Bun을 만든 사람이라면 훨씬 빠르게 갈 수 있을 것 같음
[0] https://github.com/malisper/pgrust
최근 내부 도구 일부를 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
투자자라서 시간을 효과적으로 쓰는지 보고 싶은 거라면 이해하지만, 그 외 사람들에게 왜 중요한지는 잘 모르겠음
시대가 바뀐 게 흥미로움. 2015년에는 이미 성숙한 코드베이스였던 Go 런타임 전체가 C에서 Go로 반자동 재작성됐음. 유지보수자 중 한 명이 그들이 쓰던 C의 부분집합을 대상으로 C-to-Go 변환 도구를 만들어 컴파일되고 동일한 출력을 내게 했고, 이후 결과 코드를 사람이 다시 손봐 더 Go답고 최적화된 형태로 만들었음
이제는 그냥 언어 모델에게 요청할 수 있음
슬라이드:
https://go.dev/talks/2015/gogo.slide#3
흥미롭게 닮은 점도 있음
사람이 변환 도구를 작성하고 이해하고 테스트하고 버그를 잡았기 때문에 그 결과를 신뢰할 수 있음
LLM은 비결정적임. 독립적으로 10번 변환시키면 10개의 다른 결과가 나오고, 일부는 크게 다를 수도 있음. 매번 전체를 완전히 검토하지 않고는 검증할 방법이 없음
사람이 만든 결정적 변환 도구가 완벽하거나 오류가 없다는 뜻은 아니지만, LLM보다 훨씬 더 큰 신뢰를 쌓을 수는 있음
링크된 커밋은 이 제목을 뒷받침하기엔 그다지 설득력이 없어 보임. Claude가 Zig 코드를 Rust로 대량 재작성 중인 브랜치가 있고, 현재 773,950줄 추가와 151줄 삭제 상태임
[0]: https://github.com/oven-sh/bun/compare/claude/phase-a-port
이 작업 규모가 궁금해서 cloc 기준 상위 5개를 뽑아봤음
Language files blank comment code
Zig 1298 79693 60320 571814TypeScript 2600 67434 115281 471122
JavaScript 4344 36947 37653 290873
C++ 583 27129 19117 215531
C 111 21577 83914 199576
성공 가능성은 있지만 더 느린 접근으로, git 커밋 기록을 잠금 단계처럼 따라가며 각 커밋의 동작 의도를 적용하는 방식이 떠오름
이렇게 한다면 Rust 구현이 문제를 피해간 덕분에 특정 버그 수정 커밋들을 건너뛸 수 있었는지도 알고 싶음
최근 Bun/Anthropic이 Zig 컴파일 시간에 불만을 보였던 걸 보면, 즉 바이브 코딩으로 만든 4배 컴파일 속도 향상 PR이 받아들여지지 않았던 점을 감안하면, 기본 Zig보다도 아마 4배 더 긴 컴파일 시간을 내는 언어로 옮기려는 건 “흥미로운” 움직임처럼 보임
비슷한 코드를 Zig와 C++로 작성해봤는데, 콜드 컴파일은 C++이 여러 배 빨랐고 증분 컴파일은 C++에서 즉시 끝났음
Rust 프로젝트가 느리게 컴파일되는 주된 이유는 과도한 의존성 사용과 코드 내 메타프로그래밍 남용 때문이라고 봄
Zig는 여러 컴파일 단위가 없어서 컴파일 병렬화가 되지 않음
이 AI 이식이 어떻게 끝날지 매우 궁금함. 언어나 프레임워크가 프로젝트 발목을 잡고 있지만, 순수하게 사람 힘만으로 다시 작성하기엔 너무 큰 여러 활성 프로젝트에 관여하고 있음
동적 언어보다 Rust 바이브 코딩에서 더 성공적이었음. Rust 컴파일러의 엄격함이 AI 에이전트가 더 나은 코드를 만들도록 강제하는 것 같기도 함. 확실하진 않고, 내가 Rust에 덜 익숙해서 더 잘하는 것처럼 느끼는 걸 수도 있음
테스트 하네스는 필수임. 각 반복마다 테스트를 실행해서 다른 부분을 깨지 않았는지 확인해야 함
지금 TypeScript를 Rust로 이식하는 중이고, 그 과정에서 많이 배웠음. 진행 중인 작업은 여기서 볼 수 있음 https://github.com/mohsen1/tsz/
배운 점을 공유할 수 있음
세부 코드 검토를 못 하는 내 한계를 보완하는 방법은 테스트, 통합 테스트, 종단 간 테스트가 내가 신경 쓰는 모든 걸 덮도록 만드는 것임. 그게 없으면 세부 작업을 건너뛰지 않았다고 확신할 수 없음
벤치마크와 스트레스 테스트도 시키고, 잠재 병목을 찾도록 코드베이스를 분석시켰음. 몇 가지 문제를 찾아 고친 뒤에는 더 나아졌음. 마지막으로 비판적 검토, 리팩터링 기회 탐색 등을 시키면 다음에 고칠 목록을 꽤 잘 만들어줌
메모리 누수 검사기와 정적 분석 도구를 돌리게 하는 것도 좋은 전략임. 이런 방식으로 찾을 문제가 줄어들면 코드는 아마 끔찍하진 않음. 적어도 어떤 국소 최적점에는 도달한 셈임
코드 검토가 없다는 건 꽤 끔찍하게 들리지만, AI 보조 코딩에서는 빠르게 가장 큰 병목이 되고 있음. 그 병목을 없애는 건 무섭지만 가능한 코드 양을 몇 단계 끌어올림. 엄격한 컴파일러와 엄격한 메모리 관리는 몇몇 버그 범주를 제거하는 데 도움이 됨
예전에는 내가 이해하는 언어로 이 작업을 했음. 더 큰 커밋을 일상적으로 다루기 시작하면 검토가 문제가 됨
이런 큰 코드베이스 작업은 시간이 갈수록 훨씬 쉬워지고 좋아질 거라고 봄. 이 유형의 엔지니어링에서 마주치는 주된 골칫거리는 모델이 의도적으로 지름길을 택하고, 정상 경로 테스트만 하고, 핵심 작업을 나중으로 미루려는 경향임
많은 모델이 토큰 사용량을 아끼도록 편향돼 있는 것 같음. 꽤 짜증나지만 후속 프롬프트와 테스트로 보완하기는 쉽고, 추가 프롬프트 없이도 더 잘 행동하도록 모델이 조정되면 덜한 문제가 될 것 같음
“내가 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로 써서 최고의 상태로 만들 수 있을 것임
Bun도 마케팅용 묘기로 보기 쉬움
지금까지 claude/codex의 놀라움은 대부분 기존 라이브러리의 경계 조건 안에서 만들어지는 애플리케이션에 묶여 있었음. 모델은 인간이 지금까지 만든 Python,
requests,ffmpeg같은 훌륭한 작업물을 직접 활용함하지만 괴물이 그 제약 밖으로 뻗어나가는, 즉 라이브러리, DLL, 바이너리를 다시 쓰고 패치하고 이름 바꾸고 재구축하는 단계가 기대됨. 그렇게 되면 라이브러리는 녹아 없어지고, 애플리케이션은 더 효율적이고 안전하며 통합적이지만 완전히 비인간적인 기술 스택의 흔들리는 모래 위에 떠 있게 될 것임
해석 가능성이나 보안 같은 면에서 분명 끔찍한 생각이지만, 특히 전담 중앙화된 노력이 있다면 작동 불가능하다고 단정하기도 어려움. 수십 년간의 기초적이고 점진적인 개발을 완전히 기계가 다시 쓰는 전면적 슬롭화와 해석 가능성이 반드시 상호 배타적인지도 명확하지 않음