▲

Bun 지원이 이제 제한되고 폐기 예정으로 전환됨

 (github.com/yt-dlp)
1P by GN⁺ 16시간전 | ★ favorite | 댓글 1개
  • 이 이슈는 아직 Open 상태이며, 다음 yt-dlp 및/또는 ejs 릴리스부터 Bun 지원 범위를 1.2.11 이상 1.3.14 이하로 제한하고 지원 자체도 폐기 예정으로 전환함
  • yt-dlp는 Bun을 ejs 호환 JavaScript 런타임으로 계속 쓰되, 유지 부담이 커지면 Bun 지원을 완전히 제거할 권리를 남겨둠
  • 최소 지원 버전은 기존 1.0.31에서 1.2.11로 올라가며, 1.2.0 이전 Bun으로 ejs 패키지를 빌드하면 ejs 잠금 파일이 무시되어 최근 npm 공급망 공격을 고려할 때 보안상 큰 우려가 된다고 봄
  • 1.2.0이 아니라 1.2.11을 하한으로 잡은 이유는 1.2.11 이전 Bun에서는 ejs 테스트 스위트를 실행할 수 없기 때문임
  • 상한은 1.3.14로 정해졌으며, 이 버전이 원래 Zig 코드베이스에서 빌드된 마지막 릴리스라는 점이 근거로 제시됨
  • Bun이 최근 Claude를 사용해 Rust로 재작성됐고 개발 방향이 “완전히 vibe-coded”되는 쪽으로 보인다는 점이 향후 유지보수 부담과 신뢰 문제로 제기됨
  • 한 댓글은 Deno도 “vibe coded”되고 있다고 반박했지만, 관리자는 Claude를 사용하는 것과 Claude에 완전히 의존하는 것 사이에는 큰 차이가 있다고 답함
  • 1.3.4부터 1.3.14까지도 Anthropic 인수 이후 “vibe coding” 영향을 받았을 수 있으니 지원에서 제외해야 하는 것 아니냐는 질문에는, 관리자가 검토하겠다고 답함
  • 일부 사용자는 실제 문제가 발생하기 전부터 최신 Bun 실행을 막는 것은 근거 없는 선제 제한이며, 경고나 플래그를 두고 계속 실행할 수 있게 해야 한다고 반대함
  • 다른 댓글은 --js-runtimes에 Bun 바이너리 경로를 직접 넘길 수 있으므로, 최신 Bun은 평소대로 쓰고 yt-dlp 전용으로 정적 Bun 1.3.14를 지정하는 우회가 가능하다고 설명함
  • 관련 공지로 Node v20·v21 지원 중단 이슈와 Deno 최소 지원 버전을 v2.3.0으로 올리는 이슈가 함께 연결됐고, EJS 위키 문서는 아직 이번 변경을 반영하지 않았다고 안내됨
  • 관리자는 Hacker News 유입 댓글을 의식해, 댓글을 달기 전 실제로 yt-dlp에서 Bun을 쓰는 문제에 관심이 있는지 먼저 생각해 달라는 고정 댓글을 남김

함께 보면 좋은 글 β

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

  • 결정이 이해됨. 유지보수자가 직접 작성하지 않은 코드가 대부분이라면 코드베이스를 제대로 이해하기가 어렵지 않겠나 싶음
    전체 재작성 코드를 검토하는 것도 사실상 불가능함. 정확히 100만 줄이나 되는 코드가 있음 https://github.com/oven-sh/bun/pull/30412

    • Zig에서 Rust로 바뀌었다고 해서 특정 파일이 무엇을 담고 어떻게 동작하며 다른 파일과 어떻게 연결되는지 갑자기 모르게 되는 건 아니라고 봄
      결국 같은 내용을 다른 문법으로 쓴 것에 가깝고, 그래서 Rust 개발자 눈에는 보기 안 좋게 보이는 듯함. Bun 개발자들은 자신들에게 익숙해 보이는 코드를 원했던 것 같음
      다만 이건 2.0이라고 불렀어야 했다고 생각함. 그러면 이렇게 서두르는 느낌도 덜했을 것임. 1.3.14에도 회귀가 몇 개 있는데, 지금은 작은 Rust 관련 화재가 너무 많아서 아무도 크게 신경 쓰지 않는 분위기임
      더 큰 문제는 Bun이 반짝이는 새 기능을 계속 좇고 끝까지 마무리하지 않는다는 점임. 테스트는 Vitest의 대부분이지만 전부는 아니고, Jest도 대부분이지만 전부는 아니며, pnpm도 대부분이지만 전부는 아님. 이제 이미지 기능도 들어와서 sharp의 대부분이지만 전부는 아님. 개발 서버도 Vite의 대부분이지만 역시 전부는 아님. 장기 실행 프로세스는 Node와 대체로 비슷하지만 메모리 누수가 있고, 이게 Rust 전환의 동기였을 것 같음
      이미지 루틴 글을 봤을 때 마음이 가라앉았음. 또 다른 반짝이는 대상이었고, 테스트 버그와 겹쳐서 결국 완전히 Vitest로 옮겼음
    • 대략 200만 줄의 Zig 코드는 작성할 수 있었는데, 그 안에 포함된 같은 테스트 스위트를 계속 쓸 수 있는데도 100만 줄 Rust 코드는 검토할 수 없다는 말은 설득력이 약함
      이 재작성 자체가 좋은 아이디어이고 잘될 것이라고 확신하지는 않지만, 그 반대 논리도 마찬가지로 납득하기 어렵다
    • 이건 이직률이 높은 기업 문화에서는 꽤 흔함. 10년 된 수백만 줄짜리 코드베이스를 “유지보수”하는 팀에 배정되고, 팀에서 가장 오래 있던 사람도 1~2년 된 경우가 있음
      그 100만 줄 이상이 뭘 하는지 아무도 모름. 그걸 열정적으로 다루는 사람도 없음. 요구사항을 받아서, 건드려야 하는 표면만 제외하고 나머지는 전부 블랙박스로 취급함
      그래서 같은 일을 하는 백그라운드 서비스 구현이 14개, 같은 역할의 의존성이 8개, 겹치는 프레임워크가 6개, 스타일과 접근법의 완전한 불일치가 생김. 그래도 별로 중요하게 여겨지지 않음
    • 지금 맡고 있는 꽤 큰 코드베이스 중에는 에이전트형 도구로 생성한 사람이 동작 방식을 거의 이해하지 못하는 것도 있음
      순수한 “바이브 코딩”보다는 낫다고 보지만, 중요하지 않은 부분이라면 괜찮아도 정말 깊이 생각해야 하는 핵심 인프라에서는 받아들이기 어렵다
    • 그들은 Windows도 지원하는데, Windows는 현재 유지보수자가 작성하지 않은 코드가 수백만 줄에 달함

  • 누군가의 인종이나 종교를 차별하는 것도 아님. 대규모 바이브 코딩된 표면적을 원하지 않는다면 굳이 변명해야 하나 싶음
    개발자로서의 “예술적” 재량에 속하고, 소프트웨어에는 본질적으로 의견이 들어간다는 사실을 잊은 것 같음

    • GitHub 이슈의 일부 글을 보면, 자기 종교가 침해당했다고 느끼는 사람도 있는 것 같음
    • 댓글을 보면 많은 사람이 제목이 Bun 자체에 관한 것이라고 가정하는 듯함
    • 맞음. 포크해서 최소 버전 숫자만 올리는 것도 어렵지 않을 것임. 실제로 보진 않았지만 어딘가 숫자 하나만 바꾸면 될 가능성이 큼
      동작한다면 계속 동작할 것임. 다만 그들은 그걸 지원하고 유지보수하며 이슈를 해결하고 싶지 않은 것뿐임
    • 인종이나 종교 차별과 비슷하다고 볼 수도 있음. 임의적이고 의미 없는 기준으로 배제한다는 점에서 그렇다
      Rust로 포팅된 Bun이 모든 측정 가능한 면에서 더 낫다면, 테스트를 모두 통과하고 성능이 같거나 더 좋고 기존 버그도 고친다면, 어떤 언어로 작성됐고 어떻게 구현됐는지가 왜 중요한가 싶음. 핵심은 품질이 더 높다는 점임
      Bun 팀이 Rust 버전을 릴리스하고 승인했을 때 믿지 못한다면, 2주 전 Zig 버전은 왜 믿었는지도 논리적으로 맞지 않음. yt-dlp 개발자들이 어리석어 보이게 됨

  • Bun 쓰는 걸 정말 좋아해서, Anthropic 인수 이후 방향이 이렇게 바뀌는 게 좀 슬픔
    배터리 포함식의 좋은 Node를 원하지만, 그게 바이브 코딩된 것이길 바라지는 않음

    • 바이브 코딩된 변환 때문에 실제로 큰 문제가 생긴 적이 있었나 궁금함
      합병을 지지한다는 뜻은 아님. 이런 YOLO식 엔지니어링 접근에는 반대함. 다만 발표 이후 소식을 못 봐서 전환이 어떻게 진행되는지 궁금함
    • Bun 팀에 따르면, Anthropic 인수 전부터 이미 몇 달 동안 바이브 코딩되고 있었다고 함
    • 인수 당시에는 사람들이 Bun이 대체로 기존처럼 계속 갈 수 있을 거라고 기대했는데, 결국 그 기대가 완전히 뒤집히고 망가진 게 참 웃김
      물론 끔찍하게 슬픈 의미에서 웃기다는 뜻임
    • “바이브 코딩” 때문에 생긴 구체적 문제가 확인되지 않았다면, 실제 근거를 확인하지 않고 무조건 거부하는 반응 자체가 비판하는 행동과 비슷한 것 아닌가 싶음

  • 이 결정은 엔지니어링보다 정치적 판단에 가까워 보임. Rust 재작성 이후 Bun에서 세그멘테이션 오류, 메모리 부족, 보안 취약점, 버그가 늘어난 걸 봤나?
    물론 아직 재작성본이 들어가지도 않았으니 봤을 리 없음. AI 개입을 생각할 때 기분이 나쁘다는 이유로 결정하는 것처럼 보임
    엔지니어링 도구는 기분이 아니라 원하는 일을 해내는지로 고름. Bun에 버그가 늘고 더 나쁜 소프트웨어처럼 느껴지면 쓰지 않겠지만, 그 판단은 데이터에 기반할 것임. Jarred는 Bun으로 인상적인 일을 많이 했고, 자기 품질 기준을 못 맞춘 재작성본을 내보낼 가능성은 낮아 보이니 지켜볼 생각임

    • 반대로, Bun의 새 개발 프로세스가 세그멘테이션 오류, 메모리 부족, 보안 취약점을 늘리는지 yt-dlp 쪽이 실험해줄 의무는 없음
      보안 취약점 증가 가능성이 합리적으로 있다고 생각하면서 사용자에게 실험하는 건 오히려 부주의하다고 볼 수 있음
      책임 있는 선택은 “지금 main에서 잘라낸 새 Bun 릴리스에서 우리 소프트웨어 실행을 즉시 지원하지 않겠다”에 가까움
      다만 향후 릴리스를 다시 평가하려는 계획이 아니라, 앞으로도 절대 지원하지 않겠다는 의도처럼 보이는 점은 아쉬움. 물론 yt-dlp 개발자들이 누구에게 빚진 것은 아님
    • 꼭 정치적인 건 아님. yt-dlp가 정치적으로 행동하는 것일 수는 있지만, 핵심 의존성을 프로덕션에서 6개월~1년 널리 쓰이기 전까지 채택하지 않는다는 원칙은 일반적으로 정치가 아님
      100만 줄 전체 재작성은 이전과 같은 ABI를 가진 사실상 새 런타임이고, 많은 하위 소비자에게는 프로덕션 의존성으로 삼기 불편한 대상임
      논의를 위해 Bun이 전부 사람이 손으로 다시 썼다고 해도 상황은 같았을 것임. 이런 결정은 꽤 표준적이라고 생각하고, 개인적으로 Bun의 LLM 재작성 품질도 전반적으로 좋을 것 같지만, 내 제품이나 회사를 걸지는 않겠음. 위험한 변경은 내 소프트웨어에서 내가 선택하고 싶지, 하위 의존성 때문에 강제로 떠안고 싶지 않음
    • 세그멘테이션 오류, 메모리 부족, 다른 문제가 늘어날 때까지 기다리면 이미 문제 회피에 실패한 것임. 이 방향이 맞다고 보고, 역사가 누가 옳은지 보여줄 것임
    • 프로젝트에서는 거버넌스가 매우 중요함. Bun 작성자들이 새 소유자에게 무릎을 꿇은 건 우선순위가 어디 있는지 보여줌
      버그가 터져 모든 게 망가지기 시작할 때까지 앉아서 기다리지는 않을 것임
      “도구가 원하는 일을 하는지”만 보고 고른다는 식으로 생각하는 사람의 프로젝트라면, 내 의존성에서 제거할 것임
    • 엔지니어링의 핵심 요소 중 하나는 현재 궤적을 예측하는 것임. 그런 점에서 나쁜 느낌을 주는 도구를 피하는 건 충분히 말이 됨
      열차 사고가 될 도구에서 벗어나기 가장 쉬운 때는 아직 통합하기 전임

  • 이건 Rust 변환에 관한 것이지만, 아직 릴리스되지는 않았음
    “예상 가능한 호환성 및 보안 문제”라고 하는데, Zig 버전 Bun도 꽤 많이 크래시남
    yt-dlp가 왜 예상 가능한 호환성 문제가 있는지 자세한 근거를 링크해줬으면 좋겠음. 두 프로젝트 모두 테스트 스위트가 있으니 이상적인 세계에서는 빠른 재작성이 가능해야 함
    상황을 더 자극하지 않으려는 것일 수도 있지만, 구체적으로 발견한 문제가 있다면 보고 싶음
    Bun.rs는 마이너 릴리스가 아니라 1.4나 2.0이고, 알파/베타 릴리스도 있었으면 함

    • 실제로 어떤 프로젝트가 Bun.rs에서 심각한 회귀를 보고 데이터를 보여줬다면 얘기가 다름
      하지만 공개된 지 일주일밖에 안 됐고, 지금까지는 실제 회귀 데이터가 거의 안 보임. 더 “그냥 마음에 안 든다”식의 투덜거림에 가까워 보임

  • 이 논리는 “libfoo가 vim 대신 emacs로 개발되기 시작했으니 더는 신뢰할 수 없다”와 크게 다르지 않게 읽힘
    물론 완전히 같지는 않지만, 비슷하게 느껴지는 이유가 있음
    소프트웨어에서 유일한 진실은 내 사용 사례에서 동작하느냐임. AI 이전에도 작성자가 엄밀하게 진행했는지, 아니면 될 때까지 무작위로 시도했는지 알 수 없었음
    다시 말해 방법론이나 사용 도구를 조사해서 소프트웨어를 판단하지 않았음. 테스트 스위트가 없거나 엉망인 소프트웨어도 많이 썼고, 메모리 안전성을 좋아하는 사람들도 C로 작성된 도구를 쓰며 그 반대도 마찬가지임
    그래서 “AI 사용 방식이 마음에 안 들어서 쓰지 않겠다”는 논리는 작성자의 편집기 선택이 마음에 안 들어 사용을 중단한다는 말만큼이나 설득력이 약하게 들림

    • 물건이 어떤 방식으로 만들어졌는지 실제로 걱정하고, 그 과정에 동의하는지에 따라 결정을 내리는 사람들은 분명히 있음
      그렇지 않았다면 공정무역 초콜릿/커피 같은 개념도 존재하지 않았을 것임
    • 그 비유는 너무 나갔음. 같은 경기장도 아니고 인접한 경기장도 아닌 것으로 읽어야 함
    • 그럼 한 단계 더 나아가서, 매달 첫 번째 월요일마다 전체 코드베이스를 새 언어로 다시 쓰는 cron 작업을 걸었다고 해보자. Rust에서 C++로, Go로, Swift로 갔다가 다시 돌아오는 식임
      제품을 쓰는 고객에게도 이게 유지보수자가 편집기를 바꾼 것과 거의 같고, 무관한 세부사항일까?
    • 대부분은 사용한 텍스트 편집기가 작성된 코드에 의미 있는 영향을 주지 않는다고 생각할 것임
      하지만 LLM에 대해서도 그렇게 말할 사람은 많지 않을 것임
      바이브 Bun이 예전 Bun만큼 좋거나 더 좋을 수도 있지만, 지금 시점에서 우리가 어떻게 알 수 있나?
      또 “소프트웨어가 엄밀하게 만들어졌는지 알 수 없었고, 방법론으로 판단하지 않았다”는 말도 사실이 아님. 어떤 사람들은 프로젝트를 채택하기 전이나 계속 사용할지 결정할 때 감당 가능한 수준의 엄밀함이 있는지 직접 확인함. 나도 중요한 곳에서는 그렇게 함
      더 많은 사람은 평판 신호를 쓰는데, 완벽하진 않아도 상관관계가 있고 충분할 수 있으며 직접 수동 검토보다 훨씬 쉬움

  • 개발 작업에서 LLM을 사용하는 방식을 설명할 새 용어가 절실함. “바이브 코딩”에는 엄격한 정의가 있지만 아무도 신경 쓰지 않는 분위기임
    Rust 포팅이 원래 정의처럼 100% “바이브”로만 이뤄졌다고 믿기는 정말 어려움
    긍정이든 부정이든 감정이 뒤섞인 진흙탕이 됐고, “바이브 코딩”을 일반적인 LLM 사용 비하어처럼 쓰면 실제로 어떤 문제를 말하는지 파악하기가 너무 어려워짐
    나는 개발을 보조하는 데 LLM을 쓰고 있고, 엔지니어가 중요하게 여길 만한 모든 측정 기준에서 더 좋은 일을 더 빠르게 하고 있음

    • 바이브 코딩은 원래 “분위기에 맡기고 [...] 코드가 존재한다는 사실조차 잊는 것”을 뜻했음
      https://x.com/karpathy/status/1886192184808149383
      이 특정 포팅의 경우 너무 빠르게 진행돼서, 사람이 번역의 타당성을 검증하지 않았다는 점은 분명해 보임. 앞으로 수동 검증이 실제로 이뤄질지도 불분명함
      다만 Dijkstra 기준으로 보면 AI가 등장하기 훨씬 전부터 대부분의 소프트웨어 프로젝트는 이미 “바이브 코딩”을 하고 있었음. 분위기에 맡기고 정확성이 존재한다는 사실을 잊는 식으로
      복잡한 코드의 정확성을 보장하는 일은 어렵지만, 이제 데이터센터 안에 해커 10억 명이 있는 시대가 되면서 점점 선택 사항이 아니게 될 것임
      추가: “Bun의 미릴리스 Rust 포트에는 unsafe 블록 13,365개가 있음”
      https://news.ycombinator.com/item?id=48239790
    • LLM을 써서 더 빠르게 좋은 일을 하고 있다는 주장과 달리, 연구들은 더 빠르지 않을 수 있고 오히려 느릴 수도 있음을 시사함
      워낙 새로운 기술이라 연구가 어렵지만, 낙관적으로 봐도 실증적 증거는 일부 영역에서 약 3% 향상 정도만 보임
      코드 작성은 우리 업무에서 병목인 경우가 드묾

  • 왜 이 결정에 이렇게 압박감을 느끼는 사람이 많은지 모르겠음. 진짜 바이브 코딩 애호가라면 더 나은 yt-dlp를 직접 바이브 코딩하거나 기존 것을 포크해서 필요한 대로 만들 수 있지 않나?

    • 바이브 코딩 덕분에 소프트웨어 만들기가 하찮을 정도로 쉬워졌고, 누구나 순식간에 만들 수 있다는 말을 많이 들었음
      심지어 사람들은 모든 일에 대해 일회성 개인용 소프트웨어를 바이브 코딩할 거라는 얘기도 있었음
      그렇다면 바이브 코더들이 어떤 소프트웨어 결정에도 불평할 이유가 없어야 함. 더 마음에 드는 개인 포크를 바이브 코딩하는 건 식은 죽 먹기여야 하지 않나? 그게 바이브 코딩의 약속 아니었나?
    • 게다가 yt-dlp는 이미 제3자 인터프리터 플러그인 지원이 있음. 그들은 Bun을 직접 지원하고 싶지 않다고 말하는 것뿐이고, 다른 사람이 원하는 걸 쓰도록 할 인프라는 이미 있음
      이건 타인의 시간과 노력으로 유지되는 프로젝트에 대해 사람들이 흔히 느끼는 잘못된 권리 의식임. 자기 원하는 기능을 위해 남의 시간과 노력을 마음대로 자원봉사시키려는 태도는 계속 충격적임
      일을 하는 사람들이 결정을 내릴 권리가 있고, 마음에 안 들면 직접 포크하면 됨. 이 생태계는 처음부터 그래 왔음
      yt-dlp는 지금도 의외로 손대기 쉬운 편임
    • 많은 AI 팬에게는, 전부는 아니지만, 이게 거의 종교처럼 작동함. 서로 각자 살고 역사가 어떤 소프트웨어 구축 방식이 더 나은지 보여주게 놔두는 데 만족하지 않고, 모두가 자기들에게 동의해야 한다고 요구함
      직장에서도 그런 상황을 겪고 있는데, AI에 관해서는 정직한 기술적 이견이 허용되지 않는 게 정말 미치게 함

  • Bun 재작성에 대해 어떻게 느껴야 할지 모르겠음
    한편으로는 코드베이스 대부분이 검토되지 않았다는 점이 매우 무섭게 느껴짐
    다른 한편으로는 들은 바로는 회귀가 거의 없이 테스트를 통과한다고 함
    그쪽 경험이 부족해서 그런 걸 수도 있지만, 나는 테스트를 그 정도로 신뢰해서 코드를 읽지 않고 완전히 의존하지는 않을 것 같음

답변달기