나는 Bun이 걱정된다

(wwj.dev)

6P by GN⁺ 13시간전 | ★ favorite | 댓글 3개

Bun은 빠른 JavaScript 런타임이자 TypeScript 작업을 편하게 해주는 도구지만, Anthropic의 2025년 12월 인수 이후 제품 정책과 운영 방식의 영향을 받을 수 있다는 우려가 커짐
인수 발표에서는 Bun이 오픈소스와 MIT 라이선스를 유지하고 같은 팀이 계속 개발한다고 밝혔으며, Claude Code가 Bun 실행 파일로 배포되기 때문에 Anthropic이 Bun을 안정적으로 유지할 직접적 동기가 있다고 밝힘
2026년 4월 이후 Claude Code는 품질 저하, 제한 동작, 서드파티 하네스 제한, 과금 혼란, 느린 커뮤니케이션 문제가 제기됐고, Anthropic의 engineering postmortem은 기본 추론 노력값 감소와 프롬프트 변경 같은 제품 계층 문제를 원인으로 봄
TechCrunch와 Gigazine 보도에 따르면 Claude Code는 OpenClaw 같은 서드파티 하네스 지원에 추가 비용을 요구하거나 git 히스토리의 OpenClaw 언급만으로 요청 거부·추가 과금 동작을 유발할 수 있어 예상 밖 동작이 드러남
Bun 자체나 Bun 팀의 품질 문제가 아니라 Anthropic의 정책이 Bun에 스며들 가능성이 불안을 만들며, 일부 프로젝트는 패키지 관리 용도로 pnpm으로 옮기고 새 JavaScript·TypeScript 프로젝트에도 pnpm을 추천하는 쪽으로 바뀜

Bun에 대한 우려가 커진 배경

Bun은 빠르고 실용적인 JavaScript 런타임으로, 작은 스크립트·앱·테스트·도구에서 TypeScript 작업을 편하게 만들어줌
빠른 설치, 빠른 테스트, 더 나은 번들링, 줄어든 도구 체인 부담 때문에 Node.js 대안으로 성공하길 기대받는 도구임
우려의 핵심은 Bun 자체의 품질이 아니라, Bun이 Anthropic 안으로 들어간 뒤 제품 정책과 운영 방식의 영향을 받을 수 있다는 데 있음

Anthropic 인수와 초기 기대

Anthropic은 2025년 12월 Bun을 인수했음
인수 발표에 따르면 Bun은 계속 오픈소스와 MIT 라이선스를 유지하고, 같은 팀이 계속 개발하며, 로드맵도 고성능 JavaScript 도구와 Node.js 호환성에 집중함
발표에는 “Claude Code ships as a Bun executable to millions of users. If Bun breaks, Claude Code breaks. Anthropic has direct incentive to keep Bun excellent.”라는 문장이 포함됨
당시에는 Claude Code가 Bun 위에서 동작하므로 Anthropic이 Bun을 빠르고 안정적으로 유지할 직접적 동기가 있다고 볼 수 있었음
그 논리는 지금도 타당하지만, Anthropic의 소프트웨어 제품 운영 방식에서 균열이 보이기 시작했다는 불안이 생김

Claude Code에 대한 평가 변화

Anthropic의 모델 품질 자체가 핵심 우려는 아님
Claude Opus 4.6으로 추정되는 모델군은 코딩, 글쓰기, 추론, 일반 개발 작업에서 여전히 좋은 모델군으로 평가됨
문제는 모델 주변의 제품 계층이며, 현재 Claude Code 사용성이 크게 나빠졌다는 판단이 핵심임
약 1년 전 Claude Code는 프로젝트를 읽고, 집중된 수정 사항을 만들고, 명령을 실행하고, 실수를 고치며 계속 진행할 수 있는 도구로 느껴졌음
당시 Claude Code는 개발자 워크플로가 자동완성 중심에서 에이전트 중심으로 바뀔 수 있다는 확신을 준 초기 AI 코딩 도구 중 하나였음
2025년 12월에도 Claude Code는 이미 나빠지고 있었지만 여전히 쓸 만했고, Bun 인수도 Anthropic이 코딩 도구의 미래를 만들고 있다는 관점에서는 납득 가능했음

2026년 4월 이후 Claude Code 문제

2026년 4월 개발자들은 Claude Code의 품질, 제한 동작, 서드파티 하네스 제한, 혼란스러운 과금, 느린 커뮤니케이션을 문제 삼기 시작함
Anthropic은 engineering postmortem을 공개했고, 기본 추론 노력값 감소, 오래된 세션 버그, 코딩 품질을 해친 프롬프트 변경 같은 제품 계층 문제를 원인으로 봄
이 사후 분석은 아무 일도 없었던 것처럼 넘어가는 것보다는 나았고, Anthropic이 자신들의 책임을 인정한 드문 경우로 받아들여짐
TechCrunch 보도에 따르면 Anthropic은 Claude Code 구독자에게 OpenClaw와 다른 서드파티 하네스 지원을 위해 추가 비용을 내야 한다고 알림
Gigazine 보도에 따르면 git 히스토리에 OpenClaw가 있기만 해도 Claude Code가 요청을 거부하거나 추가 과금을 유발할 수 있음
해당 보도는 Theo의 발언을 인용해, JSON blob 안의 최근 커밋에 OpenClaw가 언급된 것만으로도 빈 저장소에서 claude -p "hi"를 직접 호출할 때 동작이 트리거될 수 있었다고 전함
관련 장면은 영상 클립으로도 확인 가능함
이런 동작은 실제 코드 수준의 사용 경험을 충분히 내부에서 써보지 않은 채 변경 사항을 내보내는 제품처럼 보이게 만듦
외부에서 보기에 Claude Code는 더 많은 제한, 이상한 과금, 커밋 텍스트에 따라 달라지는 예상 밖 동작으로 잘못된 방향으로 가고 있음
이런 흐름은 엔시티피케이션(enshittification) 으로 표현됨

Bun으로 이어지는 불안

Bun은 Claude Code 안에 깊이 들어가 있고, Claude Code가 나빠지는 것처럼 보이기 때문에 Bun도 같은 방향으로 갈 수 있다는 우려가 생김
Bun이 나쁘거나 Bun 팀이 관심을 잃었다는 뜻은 아님
문제는 Bun과 Bun 팀이 Anthropic에 더 통합될수록 Anthropic의 정책도 함께 들어올 수 있다는 데 있음
Claude Code를 망가뜨린 것으로 보이는 정책이 Bun에도 영향을 주면, Bun에서도 팀이 자기 제품을 실제로 쓰지 않는 것처럼 보이는 문제가 나타날 수 있음
이런 가능성만으로도 일부 프로젝트에서 Bun 사용을 계속할지 확신하기 어려워짐

당분간 pnpm으로 이동

Bun은 pnpm보다 더 많은 기능을 한 도구 안에 제공함
Bun은 별도 빌드 단계 없이 TypeScript를 지원하고, Vite 대신 번들러를 제공하며, vitest 대신 테스트 기능을 제공함
이런 기능을 하나의 도구 체인으로 묶어 제공하는 점은 실제로 큰 장점임
pnpm은 Node.js 대체재도 아니고 Bun 대체재도 아니며, 패키지 매니저일 뿐임
다만 일상 작업에서 Bun을 가장 자주 쓰는 부분이 패키지 관리라면, 빠른 설치, 좋은 모노레포 지원, 합리적인 디스크 사용량은 Bun과 pnpm 모두 제공함
현재 Bun을 쓰는 프로젝트 일부는 Bun에서 벗어나 pnpm으로 옮기는 선택을 하게 됨
지금 JavaScript나 TypeScript 프로젝트에 무엇을 추천하느냐는 질문에는 pnpm이 답이 됨

Bun을 떠나야 한다는 권고는 아님

일부 프로젝트를 Bun에서 옮기고 있지만, 이를 일반적인 정답으로 받아들일 필요는 없음
새 프로젝트에는 pnpm이 말이 됨
기존 프로젝트는 떠날 만한 충분한 이유가 생기기 전까지 Bun을 유지하는 선택도 가능함

남은 가능성과 결론

Bun이 계속 훌륭한 상태를 유지하고, Bun 팀이 좋은 작업을 계속 내놓으며, Anthropic이 JavaScript 생태계에 맞는 판단을 할 수 있도록 자율성을 주길 바라는 상태임
Anthropic은 돈, 배포력, Bun의 성능과 안정성을 신경 쓸 실질적 이유를 갖고 있음
Bun은 여전히 이번 상황을 거치며 더 강해질 수도 있음
다만 2025년 12월보다 현재 상황에 대한 신뢰는 낮아짐
예전의 Claude Code는 Anthropic이 개발자 도구를 이해한다는 증거처럼 보였지만, 지금은 Anthropic이 제품을 장기적으로 유지하고 개선하는 데 필요한 것을 모를 수 있다는 경고처럼 보임
Bun은 여전히 훌륭하지만, 앞으로 어디로 갈지는 알기 어려움
1년 뒤 상황이 완전히 달라질 수 있으므로, 이 예측이 맞았는지 다시 확인할 계획임

▲

click 8시간전 [-]

bun 덕분에 node도 많이 바뀐건 인정하는데 리포지토리에서 AI끼리 PR로 북치고 장구치는거 보면 되던게 안되는 회귀 지뢰를 밟을까봐 두렵습니다.
anthropic 인수 전에는 bun 메인으로 썼었는데 이젠 다시 node로 돌아갔어요.
sfx 기능은 여전히 킬러 기능이라고 생각하는데 그게 필요없다면 당장 bun을 써야할 이유는 잘 모르겠습니다.

답변달기

▲

GN⁺ 13시간전 [-]

Hacker News 의견들

전체 전제에는 동의하지 않음: 인수 전에도 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보다 좋았음
- Deno에도 sqlite가 있음: https://docs.deno.com/examples/sqlite/
- 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에서 일하고 있는데, 이 글은 좀 혼란스러움. 개인적으로도 Bun 팀도 매일 Bun을 직접 쓰며 개선하고 있고, 개발 속도는 오히려 더 빨라졌음. Anthropic 합류 이후 Bun의 안정성도 크게 좋아졌음
다음 Bun 버전에 들어갈 것들은 Windows x64 바이너리 17MB 축소 [0], Linux 바이너리 8MB 축소 [1], 남아 있는 자식 프로세스를 재귀적으로 종료하는 --no-orphans CLI 플래그 [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이 최근 제공한 최고의 기능은 이식 가능한 바이너리임. 사용자들이 오래된 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 질의를 지원함
  https://nodejs.org/api/sqlite.html#databasecreatetagstoremax...
- 그리운 기능을 되돌리는 작은 헬퍼 라이브러리를 쓰면 되지 않나 싶음. 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로 작성했음
최신 사용성은 꽤 마음에 들었고, 저장소의 모듈을 직접 참조하는 방식은 셸 스크립트에 특히 좋음
다만 기능을 열어둔 채 충분한 수익화를 할 수 있을지, 아니면 최소한 다른 사람들이 복제할 수 있게 할 수 있을지는 걱정됨. 그래서 일부 우려는 이해됨