전체 전제에는 동의하지 않음: 인수 전에도 Bun은 언젠가 수익화 방법을 찾아야 했음
모회사가 다른 소프트웨어인 Claude Code에서 나쁜 관행을 보인다고 해서, 그게 곧 Bun을 더 나쁘게 만들 거라고 보는 건 과함. 걱정은 이해하지만 Bun에 대해서는 아직 낙관적임
Claude Code는 Anthropic의 핵심 제품이고 성장도 극단적으로 빠르며, 작은 변경도 과금 문제로 이어질 수 있음. 반면 Bun은 JavaScript 런타임이라 최고의 런타임이 되는 데 집중할 수 있고, Anthropic의 매출이나 손익에 직접 영향을 주지 않아 Claude Code처럼 남용 때문에 급히 패치를 낼 필요도 적음
앞으로 몇 년간 어떻게 될지는 아직 불확실하지만, 인수 직후인 지금은 크게 걱정하지 않음
사람들이 남용이라는 설명을 너무 빨리 받아들이는 게 흥미로움. 대형 AI 연구소들이 구독을 많이 쓰는 사용자에게서 금전적으로 이익을 내지 못한다는 건 오래전부터 알고 있었고, 어떤 에이전트나 실행 도구를 쓰는지와 무관함. 수익이 나는 공정한 가격은 사용량 기반 토큰 과금임
이 연구소들은 제3자 실행 도구가 기반 대형 언어 모델을 범용재로 만들 위험이 있으니 그 경쟁을 죽이려 하고, 동시에 서로 얼마나 오래 손해를 감수할 수 있는지 치킨게임을 하고 있음
결국 제품 가격을 제대로 매겨야 하는데, 그때까지 모든 경쟁을 죽였기를 바라는 수밖에 없음. 하지만 그 게임은 이미 지고 있는 듯함. 유용한 모델은 매년 더 작아지고 실행 비용도 낮아져서, 구독 사용자 기반 없이도 제3자 실행 도구 개발이 계속될 임계점을 넘었음
핵심 베팅이었던 “유용한 AI에는 극도로 비싼 하드웨어가 필요하다”는 이미 실패했고, 사용자를 생태계에 묶어둔 뒤 나중에 수익화하겠다는 두 번째 베팅도 실패할 것임. 결국 제품 자체의 실력으로만 경쟁해야 하고, 그건 훨씬 덜 수익성 있음
“인수 전에도 Bun은 언젠가 수익화 방법을 찾아야 했다”는 상황 자체가 말이 안 된다고 봄. 사람들이 언젠가 수익화해야 하는 JavaScript 런타임에 이미 의존하게 된 것도 이상하고, 업계에서 가장 큰 적자를 내는 분야의 대표적 적자 기업 중 하나에 인수됐는데도 아직 희망을 갖는 것도 기묘함
기업의 정책과 문화가 제품에 미치는 영향을 과소평가하는 듯함
어떤 팀들은 이제 AI에 전부 걸고, 코드도 직접 보지 말자는 식으로 움직임. 실제로 봤고 결과는 예상 가능한 수준임. 어느 정도까지는 잘 돌아가지만, 특히 팀마다 기술 용어와 이해가 다를 때 복잡성이 쌓이면서 실수도 누적되고, 결국 소프트웨어가 실제로 어떻게 동작하는지 아는 사람이나 팀이 없어짐
사람이 테스트하거나 품질 보증을 하지 않고, 단위 테스트와 통합 테스트에 더해 AI가 브라우저나 도구를 제어하게 하는 흐름도 있음. Anthropic의 문화가 Bun 팀의 운영 방식과 사고방식을 바꿀 수도 있음
이런 문화와 사고방식이 표준이 된다면 모델이 훨씬 좋아지거나, 아니면 소프트웨어 품질이 내려갈 것임
Matt Pocock의 좋은 발표가 있음: https://youtu.be/v4F1gFy-hqg
“코드는 싸지 않다. 나쁜 코드는 지금까지 중 가장 비싸졌다. 바꾸기 어려운 코드베이스를 가지고 있으면 AI가 제공할 수 있는 풍요를 활용할 수 없기 때문이다. 좋은 코드베이스에서는 AI가 정말, 정말 잘한다.”
나쁜 코드가 스스로 누적되기 시작하면 빠져나오기 매우 어려워짐
같은 논리라면 인수 전 GitHub도 언젠가 수익화 방법을 찾아야 했음. 모회사 Microsoft가 Embrace, Extend, Extinguish나 MS Windows에서 나쁜 관행을 보였다고 해서 GitHub도 나빠질 거라고 보는 건 과하니, 걱정은 이해하지만 GitHub에 대해 낙관적이라는 식의 주장과 다르지 않음
Anthropic은 JavaScript 커뮤니티 전체를 위해서가 아니라, Claude Code에 대한 투자를 보호하고 키우기 위해 Bun을 인수했음. 당연해 보이지만 짚고 넘어가야 함. 장기적으로 결과는 인센티브를 따라갈 것임
사람들이 왜 Node 대신 Deno나 Bun을 쓰는지 모르겠음. JavaScript 런타임 경쟁자가 있다는 건 좋지만, Node에서 갈아탔을 때 얻는 이점을 잘 모르겠음
Bun은 REPL이 없고 JavaScript 엔진도 더 나쁘며, Deno는 제한적이고 성가신 권한 시스템이 붙은 Node 같고 sqlite도 없다고 봤음. 둘 다 성능이 좋다고 하지만 골라낸 벤치마크에서만 그런 듯하고, 1년 전쯤 직접 해본 작업 부하에서는 둘 다 Node보다 느렸음
다만 예전에 작은 ERP 도구를 납품할 때 프로젝트를 *.exe로 감싸는 도구가 Bun 쪽이 가장 탄탄해서 Bun을 쓴 기억이 있음. 의존성 없는 JavaScript라 전체는 Node로 만들고 배포만 Bun으로 했는데, 그 경험은 확실히 Node보다 좋았음
Bun의 개발자 경험은 Node보다 훨씬 좋고, 특히 TypeScript 프로젝트에서 차이가 큼
Deno는 사용자가 별도의 설치 단계 없이 그냥 실행하면 돼서 좋음
Bun은 원래도 제대로 운영된 적이 별로 없었음. 기능마다 버그와 빈틈이 많았고, 릴리스마다 몇 개를 고치면 다른 게 깨졌음
지난 패치 릴리스 하나에 대부분의 소프트웨어가 메이저 버전 두 번 동안 겪을 만큼의 주요 기능과 깨지는 변경을 넣었음
기본적으로 스크립트 실행기와 npm 패키지 관리자로만 쓰는데도 “좋은” 버전을 찾는 데 드는 작업량이 놀라울 정도임. 패치 버전에서 설치 중 갑자기 멈춘 적이 여러 번 있었고, 그 때문에 한동안 업그레이드도 못 했음
두 마이너 버전 전쯤에는 trustedDependencies와 함께 postinstall 스크립트를 완전히 망가뜨린 것 같음. 릴리스 노트에는 한마디도 없고 GitHub 이슈에도 아무도 보고하지 않은 듯했음. 1.1쯤에는 Bun이 postinstall에서 trustedDependency 빌드를 하게 만들 수 있었는데 이후로는 안 됐고, 몇 달째 깨져 있음
설치 중 멈추는 문제에 대한 GitHub 이슈가 있음. 보안 스캐너가 전체 의존성 목록을 명령행 인자로 넘기는데, Linux의 큰 모노레포에서는 ARG_MAX를 넘겨버림
spawn이 오류 없이 조용히 멈추고, 스캐너가 postinstall과 별개라 --ignore-scripts도 도움이 안 됨. 적어도 1.3.5부터 깨져 있음
이 업계의 인수는 대체로 어느 정도 필연적인 결말로 이어짐. 인수된 소프트웨어는 원래 팀원들이 보상을 챙기고 떠나면서 나빠지고, 기존 문화가 새 소유자의 문화로 대체됨
Bun이 예외가 될 수도 있지만, 걱정이 근거 없다고는 할 수 없음
Anthropic CEO는 AI가 인간 프로그래머를 거의 대체할 것처럼 과장된 예측을 자주 해왔고, Anthropic은 그 믿음을 Claude Code에 적용해 유지보수 불가능한 스파게티로 만들어가고 있음
Bun이 최근 제공한 최고의 기능은 이식 가능한 바이너리임. 사용자들이 오래된 Linux 배포판을 쓰는 경우가 많아서 이식성이 매우 중요함. Node와 Deno는 더 최근 Linux, 정확히는 최신 glibc를 요구함
“Bun에서 일한다”는 표현은 엄청난 과소표현임. Anthropic에 대한 우려는 있지만, Jarred가 이끌고 있다면 Bun이 잘못될 것 같지는 않음. 더 큰 조직의 안정성과 자금을 잘 활용하고 있을 거라고 봄
칼 가는 웹사이트 백엔드를 Bun에서 Node로 옮기는 데 몇 시간을 썼고, 잠금 효과를 피하게 되어 기분이 좋음. 처음에는 Bun에 꽤 열성적이었지만 점점 확신이 줄었음
그리울 기능은 태그드 템플릿 리터럴로 sqlite 질의하기, Bun.password.verify가 기본으로 argon2를 쓰는 점, HTML 가져오기, JSX 변환, .env 파일 자동 로딩임 https://burlyburr.com에서 https://backend.burlyburr.com를 호출함
그리운 기능을 되돌리는 작은 헬퍼 라이브러리를 쓰면 되지 않나 싶음. Node에는 최소한 SQLite와 Argon2가 들어 있으니, 문제가 인터페이스라면 쉽게 고칠 수 있음
Node도 .env 자동 로딩과 sqlite를 지원함
Bun은 인수 전에도 잘 작동했다고 생각하지 않음. 작은 스크립트에는 계속 썼지만, 직장에서 Bun으로 서비스를 배포하진 않았을 것임
메모리 문제와 고쳐지지 않는 비호환성 때문에, Node.js에 개선 여지가 있음을 잘 드러낸 괜찮은 장난감 정도로 봤음
예를 들어 https://github.com/oven-sh/bun/issues/14102를 계속 지켜봤는데, 결국 라이브러리들이 “Bun이면 x를 하라”는 분기를 넣게 됐고, 이건 호환성의 반대임
몇 프로젝트에서 운영 환경에 써보려 했지만 둘 다 Bun에서 Node로 되돌려야 했음. 하나는 말한 것처럼 큰 메모리 누수가 있었고, 다른 하나는 TextDecoderStream 같은 곳에서 API 차이로 오류가 났음. Bun v2 전에는 다시 시도하지 않기로 했음
Claude Code와 Anthropic의 흐름은 무언가를 사용자에게서 억지로 숨기려는 쪽으로 보임. xxx.yy를 읽는 동작이 파일 1개 읽기나 2개 읽기로 바뀌었을 때 생긴 난리를 기억하는 사람도 있을 것임
이런 변경이 더 이어졌고, 설정이 불가능하거나 매우 어려웠음. 사업적 의도는 이해함. 최대한 AI를 쓰게 만들고, 인간을 루프에서 빼며, 더 많은 학습 데이터와 더 많은 토큰 사용량을 얻는 것임
하지만 그 결과 Claude Code는 훨씬 나빠지고 훨씬 덜 신뢰할 수 있게 됐다고 봄. 운전대를 사용자에게서 몰래 빼앗으려는 시도처럼 느껴짐. 그 논리를 따라가면 점점 더 많은 것들이 합리화됨
지금으로서는 주로 불신만 크게 생겼음
원글에 동의하고, 어떤 사람들에게는 아직 이른 반응처럼 느껴질 수 있다는 점도 이해함
우리는 예전과는 크게 다른 세상에 살고 있고, 사람들이 윤리적 우려를 더 의식하며 과거의 실수를 반복하지 않기 위해 버티려는 의지도 더 강해졌음
기술적 기준에서는 이른 판단일 수 있지만, 윤리적 우려라는 기준에서는 말이 됨. 부정행위는 예전처럼 쉽게 되돌릴 수 없고, 그런 결정이 만드는 큰 영향을 피하려면 선제 조치가 필요함
사람들이 예전보다 윤리적 우려를 더 의식한다는 근거가 궁금함. 예전보다 더 윤리적으로 의식한다고 보이진 않음. 예를 들어 BDS 쪽 사람이 조금 늘어난 건 보이지만, 그 밖에는 별로 모르겠음
Firefox와 Safari가 Chrome OS 플랫폼 API를 도입하지 않는다는 불만이나, Chrome을 여기저기 배포하는 현실을 보면 사람들이 윤리적 고려를 지키며 버틴다고 보기 어렵다고 봄
글쓴이는 마지막에 Bun에서 좋아하지만 pnpm에는 없는 것들을 열거함. 목록은 대체로 네이티브 TS 지원, Vite식 번들러, Vitest/Jest식 테스트 실행기임
번들러를 제외하면 Node에도 이미 전부 있음. 테스트 실행기 문법은 다를 수 있지만, TypeScript는 기본으로 “그냥 동작”하고 내장 테스트 실행기도 충분히 쓸 만함. Bun을 두고 그렇게 애도할 필요가 있는지는 잘 모르겠음
공정하게 말하면 Node는 Deno와 Bun이 도전하기 전까지 이런 것들이 없었음. Deno만으로는 어떤 이유에서인지 큰 변화를 만들지 못했지만, Bun의 존재는 Node 기술 운영 위원회에 실제 영향을 줬음
Jarred Sumner의 영리한 소셜 미디어 마케팅이 현재 추진력의 상당 부분을 만들었다고도 볼 수 있음. 사람들이 이야기하게 만들었고, 그 덕분에 Node도 좋아졌음
또한 Bun이 Node API를 최대한 많이 지원하려고 밀어붙인 덕분에 Deno도 같은 수준의 호환성으로 움직였고, 이제 대부분의 코드는 사실상 런타임에 덜 묶임. 실제 운영 환경에서 Bun을 쓸지는 모르겠지만, Bun이 존재한 것만으로 JavaScript 생태계가 크게 나아졌으니 반가움
Node가 언제 네이티브 TypeScript를 추가했나? 의존성 없이 node main.ts를 바로 실행할 수 있음?
TypeScript 컴파일러 재작성까지 고려하면 Bun의 관련성은 더 줄어듦
솔직히 Bun은 가끔 모듈 테스트하는 것 말고는 많이 써보지 않았음. 일상적으로는 주로 Deno를 쓰고, 지난 몇 년간 많은 셸 스크립트도 Deno로 작성했음
최신 사용성은 꽤 마음에 들었고, 저장소의 모듈을 직접 참조하는 방식은 셸 스크립트에 특히 좋음
다만 기능을 열어둔 채 충분한 수익화를 할 수 있을지, 아니면 최소한 다른 사람들이 복제할 수 있게 할 수 있을지는 걱정됨. 그래서 일부 우려는 이해됨
Hacker News 의견들
전체 전제에는 동의하지 않음: 인수 전에도 Bun은 언젠가 수익화 방법을 찾아야 했음
모회사가 다른 소프트웨어인 Claude Code에서 나쁜 관행을 보인다고 해서, 그게 곧 Bun을 더 나쁘게 만들 거라고 보는 건 과함. 걱정은 이해하지만 Bun에 대해서는 아직 낙관적임
Claude Code는 Anthropic의 핵심 제품이고 성장도 극단적으로 빠르며, 작은 변경도 과금 문제로 이어질 수 있음. 반면 Bun은 JavaScript 런타임이라 최고의 런타임이 되는 데 집중할 수 있고, Anthropic의 매출이나 손익에 직접 영향을 주지 않아 Claude Code처럼 남용 때문에 급히 패치를 낼 필요도 적음
앞으로 몇 년간 어떻게 될지는 아직 불확실하지만, 인수 직후인 지금은 크게 걱정하지 않음
이 연구소들은 제3자 실행 도구가 기반 대형 언어 모델을 범용재로 만들 위험이 있으니 그 경쟁을 죽이려 하고, 동시에 서로 얼마나 오래 손해를 감수할 수 있는지 치킨게임을 하고 있음
결국 제품 가격을 제대로 매겨야 하는데, 그때까지 모든 경쟁을 죽였기를 바라는 수밖에 없음. 하지만 그 게임은 이미 지고 있는 듯함. 유용한 모델은 매년 더 작아지고 실행 비용도 낮아져서, 구독 사용자 기반 없이도 제3자 실행 도구 개발이 계속될 임계점을 넘었음
핵심 베팅이었던 “유용한 AI에는 극도로 비싼 하드웨어가 필요하다”는 이미 실패했고, 사용자를 생태계에 묶어둔 뒤 나중에 수익화하겠다는 두 번째 베팅도 실패할 것임. 결국 제품 자체의 실력으로만 경쟁해야 하고, 그건 훨씬 덜 수익성 있음
어떤 팀들은 이제 AI에 전부 걸고, 코드도 직접 보지 말자는 식으로 움직임. 실제로 봤고 결과는 예상 가능한 수준임. 어느 정도까지는 잘 돌아가지만, 특히 팀마다 기술 용어와 이해가 다를 때 복잡성이 쌓이면서 실수도 누적되고, 결국 소프트웨어가 실제로 어떻게 동작하는지 아는 사람이나 팀이 없어짐
사람이 테스트하거나 품질 보증을 하지 않고, 단위 테스트와 통합 테스트에 더해 AI가 브라우저나 도구를 제어하게 하는 흐름도 있음. Anthropic의 문화가 Bun 팀의 운영 방식과 사고방식을 바꿀 수도 있음
이런 문화와 사고방식이 표준이 된다면 모델이 훨씬 좋아지거나, 아니면 소프트웨어 품질이 내려갈 것임
Matt Pocock의 좋은 발표가 있음: https://youtu.be/v4F1gFy-hqg
“코드는 싸지 않다. 나쁜 코드는 지금까지 중 가장 비싸졌다. 바꾸기 어려운 코드베이스를 가지고 있으면 AI가 제공할 수 있는 풍요를 활용할 수 없기 때문이다. 좋은 코드베이스에서는 AI가 정말, 정말 잘한다.”
나쁜 코드가 스스로 누적되기 시작하면 빠져나오기 매우 어려워짐
사람들이 왜 Node 대신 Deno나 Bun을 쓰는지 모르겠음. JavaScript 런타임 경쟁자가 있다는 건 좋지만, Node에서 갈아탔을 때 얻는 이점을 잘 모르겠음
Bun은 REPL이 없고 JavaScript 엔진도 더 나쁘며, Deno는 제한적이고 성가신 권한 시스템이 붙은 Node 같고 sqlite도 없다고 봤음. 둘 다 성능이 좋다고 하지만 골라낸 벤치마크에서만 그런 듯하고, 1년 전쯤 직접 해본 작업 부하에서는 둘 다 Node보다 느렸음
다만 예전에 작은 ERP 도구를 납품할 때 프로젝트를
*.exe로 감싸는 도구가 Bun 쪽이 가장 탄탄해서 Bun을 쓴 기억이 있음. 의존성 없는 JavaScript라 전체는 Node로 만들고 배포만 Bun으로 했는데, 그 경험은 확실히 Node보다 좋았음Bun은 원래도 제대로 운영된 적이 별로 없었음. 기능마다 버그와 빈틈이 많았고, 릴리스마다 몇 개를 고치면 다른 게 깨졌음
지난 패치 릴리스 하나에 대부분의 소프트웨어가 메이저 버전 두 번 동안 겪을 만큼의 주요 기능과 깨지는 변경을 넣었음
기본적으로 스크립트 실행기와 npm 패키지 관리자로만 쓰는데도 “좋은” 버전을 찾는 데 드는 작업량이 놀라울 정도임. 패치 버전에서 설치 중 갑자기 멈춘 적이 여러 번 있었고, 그 때문에 한동안 업그레이드도 못 했음
두 마이너 버전 전쯤에는 trustedDependencies와 함께 postinstall 스크립트를 완전히 망가뜨린 것 같음. 릴리스 노트에는 한마디도 없고 GitHub 이슈에도 아무도 보고하지 않은 듯했음. 1.1쯤에는 Bun이 postinstall에서 trustedDependency 빌드를 하게 만들 수 있었는데 이후로는 안 됐고, 몇 달째 깨져 있음
spawn이 오류 없이 조용히 멈추고, 스캐너가 postinstall과 별개라
--ignore-scripts도 도움이 안 됨. 적어도 1.3.5부터 깨져 있음Bun에서 일하고 있는데, 이 글은 좀 혼란스러움. 개인적으로도 Bun 팀도 매일 Bun을 직접 쓰며 개선하고 있고, 개발 속도는 오히려 더 빨라졌음. Anthropic 합류 이후 Bun의 안정성도 크게 좋아졌음
다음 Bun 버전에 들어갈 것들은 Windows x64 바이너리 17MB 축소 [0], Linux 바이너리 8MB 축소 [1], 남아 있는 자식 프로세스를 재귀적으로 종료하는
--no-orphansCLI 플래그 [3], Mongoose/MongoDB 같은 데이터베이스 클라이언트의 메모리 사용을 크게 줄이는 클라이언트 TCP 및 Unix 소켓용 SSL 컨텍스트 캐싱 [4], fetch의 실험적 HTTP/3 및 HTTP/2 클라이언트 [5],Bun.serve()의 실험적 HTTP/3 지원 [6], 내장 이미지 처리 라이브러리Bun.Image[7] 등임여기에
node:fs, Worker, BroadcastChannel, MessagePort의 신뢰성 개선도 함께 들어감Anthropic 인수 덕분에 Bun은 더 이상 매출을 내는 사업이 될 필요가 없음. Claude Code가 Bun에 의존하고, 많은 소프트웨어 엔지니어가 Claude Code에 의존해 일을 하므로 Bun을 더 좋게 만들 강한 인센티브가 있음
[0]: https://github.com/oven-sh/bun/pull/30219
[1]: https://github.com/oven-sh/bun/pull/30098
[2]: https://github.com/oven-sh/WebKit/pull/211
[3]: https://github.com/oven-sh/bun/pull/29930
[4]: https://github.com/oven-sh/bun/pull/29932
[5]: https://github.com/oven-sh/bun/pull/29863
[6]: https://github.com/oven-sh/bun/pull/30032
Bun이 예외가 될 수도 있지만, 걱정이 근거 없다고는 할 수 없음
Anthropic CEO는 AI가 인간 프로그래머를 거의 대체할 것처럼 과장된 예측을 자주 해왔고, Anthropic은 그 믿음을 Claude Code에 적용해 유지보수 불가능한 스파게티로 만들어가고 있음
칼 가는 웹사이트 백엔드를 Bun에서 Node로 옮기는 데 몇 시간을 썼고, 잠금 효과를 피하게 되어 기분이 좋음. 처음에는 Bun에 꽤 열성적이었지만 점점 확신이 줄었음
그리울 기능은 태그드 템플릿 리터럴로 sqlite 질의하기,
Bun.password.verify가 기본으로 argon2를 쓰는 점, HTML 가져오기, JSX 변환,.env파일 자동 로딩임https://burlyburr.com에서 https://backend.burlyburr.com를 호출함
https://nodejs.org/api/sqlite.html#databasecreatetagstoremax...
.env자동 로딩과 sqlite를 지원함Bun은 인수 전에도 잘 작동했다고 생각하지 않음. 작은 스크립트에는 계속 썼지만, 직장에서 Bun으로 서비스를 배포하진 않았을 것임
메모리 문제와 고쳐지지 않는 비호환성 때문에, Node.js에 개선 여지가 있음을 잘 드러낸 괜찮은 장난감 정도로 봤음
예를 들어 https://github.com/oven-sh/bun/issues/14102를 계속 지켜봤는데, 결국 라이브러리들이 “Bun이면 x를 하라”는 분기를 넣게 됐고, 이건 호환성의 반대임
Claude Code와 Anthropic의 흐름은 무언가를 사용자에게서 억지로 숨기려는 쪽으로 보임.
xxx.yy를 읽는 동작이 파일 1개 읽기나 2개 읽기로 바뀌었을 때 생긴 난리를 기억하는 사람도 있을 것임이런 변경이 더 이어졌고, 설정이 불가능하거나 매우 어려웠음. 사업적 의도는 이해함. 최대한 AI를 쓰게 만들고, 인간을 루프에서 빼며, 더 많은 학습 데이터와 더 많은 토큰 사용량을 얻는 것임
하지만 그 결과 Claude Code는 훨씬 나빠지고 훨씬 덜 신뢰할 수 있게 됐다고 봄. 운전대를 사용자에게서 몰래 빼앗으려는 시도처럼 느껴짐. 그 논리를 따라가면 점점 더 많은 것들이 합리화됨
지금으로서는 주로 불신만 크게 생겼음
원글에 동의하고, 어떤 사람들에게는 아직 이른 반응처럼 느껴질 수 있다는 점도 이해함
우리는 예전과는 크게 다른 세상에 살고 있고, 사람들이 윤리적 우려를 더 의식하며 과거의 실수를 반복하지 않기 위해 버티려는 의지도 더 강해졌음
기술적 기준에서는 이른 판단일 수 있지만, 윤리적 우려라는 기준에서는 말이 됨. 부정행위는 예전처럼 쉽게 되돌릴 수 없고, 그런 결정이 만드는 큰 영향을 피하려면 선제 조치가 필요함
글쓴이는 마지막에 Bun에서 좋아하지만 pnpm에는 없는 것들을 열거함. 목록은 대체로 네이티브 TS 지원, Vite식 번들러, Vitest/Jest식 테스트 실행기임
번들러를 제외하면 Node에도 이미 전부 있음. 테스트 실행기 문법은 다를 수 있지만, TypeScript는 기본으로 “그냥 동작”하고 내장 테스트 실행기도 충분히 쓸 만함. Bun을 두고 그렇게 애도할 필요가 있는지는 잘 모르겠음
Jarred Sumner의 영리한 소셜 미디어 마케팅이 현재 추진력의 상당 부분을 만들었다고도 볼 수 있음. 사람들이 이야기하게 만들었고, 그 덕분에 Node도 좋아졌음
또한 Bun이 Node API를 최대한 많이 지원하려고 밀어붙인 덕분에 Deno도 같은 수준의 호환성으로 움직였고, 이제 대부분의 코드는 사실상 런타임에 덜 묶임. 실제 운영 환경에서 Bun을 쓸지는 모르겠지만, Bun이 존재한 것만으로 JavaScript 생태계가 크게 나아졌으니 반가움
node main.ts를 바로 실행할 수 있음?솔직히 Bun은 가끔 모듈 테스트하는 것 말고는 많이 써보지 않았음. 일상적으로는 주로 Deno를 쓰고, 지난 몇 년간 많은 셸 스크립트도 Deno로 작성했음
최신 사용성은 꽤 마음에 들었고, 저장소의 모듈을 직접 참조하는 방식은 셸 스크립트에 특히 좋음
다만 기능을 열어둔 채 충분한 수익화를 할 수 있을지, 아니면 최소한 다른 사람들이 복제할 수 있게 할 수 있을지는 걱정됨. 그래서 일부 우려는 이해됨