---
title: "번은 좋은데, 이제 앤트로픽 품에 있어서 불안하다는 얘기"
published: 2026-05-04T16:45:00.000Z
canonical: https://jeff.news/article/2151
---
# 번은 좋은데, 이제 앤트로픽 품에 있어서 불안하다는 얘기

글쓴이는 번이 빠르고 실용적인 자바스크립트 런타임이라는 점은 인정하지만, 앤트로픽 인수 이후 장기적인 방향을 신뢰하기 어려워졌다고 말한다. 특히 클로드 코드의 품질 저하, 과금 혼란, 서드파티 하네스 제한 사례를 보며 번도 같은 제품 운영 방식에 휘말릴 수 있다고 우려한다.

## 번은 여전히 좋은데, 소유자가 마음에 걸림

- 글쓴이는 먼저 선을 확실히 긋고 시작함. 번(Bun)은 좋은 소프트웨어임
  - 빠르고 실용적이고, 타입스크립트(TypeScript) 작은 스크립트나 앱, 테스트, 툴링 작업에서 꽤 편하다고 봄
  - Node.js의 진지한 대안, 더 빠른 설치, 더 빠른 테스트, 덜 비대한 툴체인을 원하기 때문에 오히려 번이 잘되길 바라는 쪽임

- 그런데 2025년 12월 앤트로픽(Anthropic)이 번을 인수하면서 불안이 생김
  - 당시 발표는 듣기 좋았음. 오픈소스 유지, 엠아이티 라이선스 유지, 기존 팀 유지, 고성능 자바스크립트 툴링과 Node.js 호환성 로드맵 유지
  - 게다가 클로드 코드(Claude Code)가 수백만 사용자에게 번 실행 파일로 배포되니, 앤트로픽도 번을 망가뜨릴 이유가 없다는 논리였음
  - 그땐 설득력 있었는데, 지금은 그 믿음에 금이 갔다는 게 글의 핵심임

> [!IMPORTANT]
> 이 글은 “번이 기술적으로 별로다”가 아님. “앤트로픽의 제품 운영 방식이 번에도 영향을 줄 수 있다”는 신뢰 리스크 얘기임.

## 클로드 코드가 경고 신호가 됨

- 글쓴이는 앤트로픽 모델 자체를 까는 글은 아니라고 함
  - 클로드 오퍼스 계열은 여전히 코딩, 글쓰기, 추론, 일반 개발 작업에서 강력하다고 평가함
  - 문제는 모델이 아니라 그 위에 얹힌 제품 레이어, 특히 클로드 코드의 현재 사용 경험임

- 클로드 코드는 1년 전만 해도 “개발자 워크플로가 바뀌겠다”는 느낌을 줬던 도구였음
  - 프로젝트를 읽고, 집중된 코드 수정을 하고, 명령을 실행하고, 실수를 고치고, 계속 진행하는 에이전트형 도구였음
  - 자동완성 중심에서 에이전트 중심 개발로 넘어갈 수 있겠다는 확신을 준 초기 도구 중 하나였다고 함

- 그런데 2026년 4월부터 개발자들 사이에서 불만이 터짐
  - 품질 저하, 사용량 제한 동작, 서드파티 하네스 제한, 헷갈리는 과금, 느린 커뮤니케이션이 주요 불만으로 언급됨
  - 앤트로픽은 엔지니어링 포스트모템에서 기본 추론 강도 감소, 오래된 세션 버그, 코딩 품질을 해친 프롬프트 변경 같은 제품 레이어 문제를 인정함
  - 글쓴이는 이 인정 자체는 좋게 보지만, 동시에 “이런 문제가 실제로 있었다”는 증거로도 봄

## 오픈클로 사건이 특히 찜찜함

- 오픈클로(OpenClaw) 관련 과금·제한 논란은 글쓴이가 보기엔 꽤 심각한 신호임
  - 보도에 따르면 앤트로픽은 클로드 코드 구독자에게 오픈클로 같은 서드파티 하네스를 쓰려면 추가 비용을 내야 한다고 안내함
  - 여기까지만 해도 논란인데, 더 이상한 건 저장소 히스토리에 오픈클로 문자열이 있기만 해도 클로드 코드가 요청을 거부하거나 추가 과금을 유발할 수 있다는 보고였음

- 테오(Theo)가 언급한 사례는 개발자 입장에서 꽤 황당함
  - 최근 커밋의 제이슨(JSON) 조각에 오픈클로 언급이 있으면, 빈 저장소에서 `claude -p "hi"`만 호출해도 해당 동작이 트리거될 수 있다는 식의 보고였음
  - 글쓴이는 이게 사실이라면 실제 코드 레벨 개발 경험을 꼼꼼히 도그푸딩하지 않고 정책을 밀어 넣은 제품처럼 보인다고 봄

> [!WARNING]
> 개발자 도구에서 “텍스트 하나가 히스토리에 있다는 이유로 동작과 과금이 달라짐”은 진짜 위험한 패턴임. 예측 가능성이 깨지면 도구 신뢰도도 같이 깨짐.

## 그래서 번까지 걱정된다는 논리

- 번은 클로드 코드 안에 깊게 들어가 있고, 클로드 코드는 지금 나빠지는 방향으로 보인다는 게 글쓴이의 연결고리임
  - 번 자체가 나쁘다는 얘기도 아니고, 번 팀이 신경을 안 쓴다는 얘기도 아님
  - 문제는 번 팀과 제품이 앤트로픽 안으로 더 통합될수록, 앤트로픽의 정책과 제품 문화도 같이 따라올 수 있다는 점임

- 글쓴이가 걱정하는 건 “번에서도 클로드 코드 같은 일이 생기지 않을까”임
  - 예측 불가능한 제한, 이상한 과금, 실제 사용 흐름을 충분히 테스트하지 않은 변경이 개발자 툴체인에 들어오면 타격이 큼
  - 런타임과 패키지 매니저는 프로젝트의 바닥에 깔리는 도구라, 한번 신뢰가 흔들리면 갈아타기 고민이 바로 시작됨

## 당장은 피엔피엠으로 돌아감

- 글쓴이는 자기 프로젝트 일부를 번에서 피엔피엠(pnpm)으로 옮기고 있음
  - 번이 제공하던 내장 타입스크립트 지원, 번들러, 테스트 도구는 분명 편하다고 인정함
  - 피엔피엠은 Node.js 대체재도 아니고 번 대체재도 아니며, 그냥 패키지 매니저임
  - 하지만 글쓴이가 일상에서 번을 가장 자주 쓰던 지점은 빠른 설치, 모노레포 지원, 합리적인 디스크 사용량 같은 패키지 관리였고, 이건 피엔피엠도 잘함

- 그렇다고 모두에게 번을 버리라고 말하진 않음
  - 새 프로젝트라면 피엔피엠을 추천하겠다는 정도의 결론임
  - 기존 프로젝트는 당장 떠날 이유가 없다면 번을 계속 써도 된다고 함
  - 다만 2025년 12월 인수 직후보다 지금은 상황을 덜 신뢰하게 됐고, 1년 뒤 이 예측이 맞는지 다시 보겠다고 마무리함

---

## 기술 맥락

- 번은 단순 패키지 매니저가 아니라 런타임, 번들러, 테스트 러너, 타입스크립트 실행 환경까지 묶은 툴체인이에요. 왜 매력적이냐면 작은 프로젝트든 모노레포든 자바스크립트 개발에서 따로 붙이던 도구를 한 번에 줄여주기 때문이에요.

- 그런데 이런 도구는 성능만 보고 고르기 어렵습니다. 왜냐하면 런타임이나 패키지 매니저는 프로젝트 구조, CI, 배포, 개발자 로컬 환경에 깊게 들어가거든요. 나중에 정책이나 호환성이 흔들리면 단순 라이브러리 하나 교체하는 것보다 비용이 훨씬 커져요.

- 글쓴이가 피엔피엠으로 돌아가는 이유도 “피엔피엠이 번보다 모든 면에서 낫다”가 아니에요. 본인이 실제로 번에서 가장 많이 쓰던 기능이 패키지 설치와 모노레포 관리였고, 그 부분은 피엔피엠으로도 충분히 해결되기 때문이에요.

- 앤트로픽 인수의 장점도 분명 있어요. 자금, 배포력, 클로드 코드라는 실사용 동기가 있으니까요. 하지만 개발자 도구는 예측 가능성과 신뢰가 핵심이라, 클로드 코드에서 보인 과금·제한·품질 이슈가 번의 장기 리스크로 읽히는 거예요.

## 핵심 포인트

- 앤트로픽은 2025년 12월 번을 인수했고, 번은 오픈소스와 엠아이티 라이선스를 유지한다고 발표함
- 글쓴이는 클로드 코드가 한때 훌륭했지만 2026년 4월 이후 품질, 제한, 과금, 소통 문제로 크게 흔들렸다고 봄
- 오픈클로 관련 제한과 과금 사례는 개발자 도구에서 예측 불가능한 제품 정책이 얼마나 치명적인지 보여줌
- 글쓴이는 번을 완전히 버리라고 하진 않지만, 새 프로젝트 추천은 피엔피엠 쪽으로 기울었다고 밝힘

## 인사이트

이 글은 번의 기술 품질보다 ‘누가 운영하느냐’가 개발자 도구 선택에 얼마나 큰 변수인지 짚는 글임. 런타임이나 패키지 매니저는 한번 프로젝트에 들어오면 갈아타기 비용이 크기 때문에, 성능만 보고 고르기엔 이제 리스크 계산이 필요함.