Left-Pad 사건 8년 후 회고 (2024)

 (azerkoculu.com)
1P by GN⁺ | ★ favorite | 댓글 2개
  • left-pad 사건은 8년 뒤에도 오픈소스 의존성과 패키지 관리 권한을 둘러싼 대표 사례로 남아 있으며, Azer Koçulu는 당시 결정을 다시 설명함
  • 비공개 결정은 분노나 탐욕보다 자기성찰에서 나온 선택이었고, NPM이 스스로 만든 규칙을 어긴 상황이 핵심 배경이었음
  • Kik Messenger의 압박 속에서 NPM이 오픈소스 커뮤니티보다 다른 가치를 우선했다고 보며, 이 판단이 모든 패키지 삭제로 이어짐
  • 삭제 대상은 350개 이상 패키지였지만, 사용 통계와 GitHub 활동만으로 실제 영향 범위를 알기 어려웠음
  • NPM 스크립트 실행 후 약 10분 만에 React 등 여러 프로젝트가 깨졌고, 몇 시간 안에 모듈이 복구되며 상황은 정상화됨

left-pad 사건 당시의 판단

  • left-pad 사건이 일어난 지 8년이 지났고, Azer Koçulu는 실제 작업에 집중하기 위해 그동안 이 주제를 피하는 편이 낫다고 여겼음
  • 2016년 대부분의 주말을 신호가 닿지 않는 외딴 곳에서 캠핑하던 시기에 비공개 결정을 내림
    • 논리, 분노, 탐욕이 아니라 자연 속 자기성찰과 마음에서 나온 선택이었다고 설명함
  • 판단의 원칙은 단순했음
    • NPM이 자체 규칙을 깨고 자신의 패키지 하나를 제거한다면, 같은 기준으로 자신의 패키지 전부도 제거해야 한다는 것이었음
  • 규칙 자체보다 규칙 뒤의 정신이 더 중요하다고 봄
    • 다른 맥락에서는 좋은 이유로 소유자 허가 없이 패키지 삭제를 요구할 수도 있다고 인정함
    • 그러나 이 경우에는 Kik Messenger가 “we’ll bang on your door”, “take down your accounts” 같은 위협으로 NPM 기반 오픈소스 커뮤니티에 힘을 행사했다고 봄
  • 사건을 “화난 사람이 기업 이익에 항의했다”로만 보면 이메일 날짜와 타임라인, 압박 속에서 버티는 상황, 다른 의식 상태에서 결정이 움직이는 방식을 놓치게 됨

삭제 과정과 영향

  • NPM 입장에서 삭제는 갑작스럽거나 예상 못 한 일이 아니었다고 봄
    • 먼저 NPM에 자신의 모듈 제거를 요청했고 답변을 기다렸음
    • 마감 시한을 정하지 않았기 때문에 NPM은 API와 도구를 조정해 전환을 부드럽게 만들 기회가 있었다고 봄
    • 대신 NPM은 모든 패키지를 한 번에 제거하는 스크립트를 제공함
  • 자신의 오픈소스 작업은 대부분 Unix 철학처럼 한 번에 한 가지 일을 하는 작은 패키지였음
    • 패키지는 350개 이상이었고 모두 최적화되고 테스트되어 있었음
    • 겉으로는 인기가 없어 보였고, NPM은 사용 통계를 보여주지 않았으며, 90%는 GitHub 활동도 거의 없었음
    • 일반 사용자 입장에서는 비공개가 어떤 영향을 낼지 알기 어려웠음
  • NPM이 준 스크립트를 실행한 뒤 몇 분간 자리를 비웠고, 약 10분 안에 친구가 Twitter에서 화제가 됐다고 알려줌
    • 350개 이상 패키지 중 하나가 React와 여러 프로젝트를 깨뜨림
    • 이후 짧은 블로그 글을 쓰고 자신의 오픈소스 작업을 넘겼으며, GitHub 저장소 소유권을 자원자들에게 이전함
    • 몇 시간 안에 모듈이 복구되며 상황은 정상으로 돌아감
  • 몇 달 뒤 직장을 그만두고 미국을 영구히 떠났으며, Morocco, Jordan, Türkiye, Indonesia에서 1년을 보냄
  • left-pad는 오픈소스에 깊이 마음을 두던 자신의 일부가 사라지고 새로운 것이 자리 잡은 죽음과 재탄생 같은 순간이었고, 지금은 프로그래밍만큼 회사 만들기와 운영에도 열정을 갖고 있음

함께 보면 좋은 글 β

ndrgrd   [-]

영향이 컸던 사건이지만 패키지 작성자의 글을 읽지 않아도 그의 잘못보다는 얽힌 회사들과 시스템의 잘못이 크다고 생각합니다.

답변달기
GN⁺   [-]
Hacker News 의견들

  • 블로그 글의 절반은 맥락을 놓친 느낌이라 잘 이해하지 못했지만, left-pad 당사자가 사후 분석을 쓴 점은 좋음
    다만 “NPM이 내 모듈이 널리 쓰이는지 확인하고, 깨뜨리지 않고 공개 취소하는 방법을 고려했어야 한다”는 주장은 이상하게 들림. NPM의 공개 취소 기능 설계가 잘못된 건 맞지만, 누군가 공개 취소할 때마다 회사 직원이 수동으로 전부 검토하길 기대했다는 뜻이라면 합리적이지 않아 보임. NPM이라는 회사가 레지스트리를 큐레이션하는 게 아니라 공공 서비스처럼 호스팅하는 쪽에 가까움
    그래도 작성자를 크게 탓하긴 어려움. 그가 left-pad 사건을 일으키지 않았더라도 머지않아 다른 누군가가 터뜨렸을 것이고, NPM은 더 나은 공개 취소 정책으로 문제를 고쳤음: https://docs.npmjs.com/policies/unpublish#packages-published...

    • 2016년 3월 18일 npm, Inc.의 CEO Isaac Z. Schlueter가 Kik Interactive와 Koçulu 양쪽에 메일을 보내 kik 패키지 소유권을 Kik Interactive로 수동 이전하겠다고 했고, Koçulu가 실망을 표하며 플랫폼을 떠나겠다고 하자 Schlueter가 그가 등록한 273개 모듈을 지우는 명령을 제공했음
      Koçulu는 2016년 3월 22일 그 명령을 실행해 자신이 배포했던 모든 패키지를 제거했을 뿐이고, 나중에 NPM은 자기들의 실패를 작성자 탓으로 돌렸음
    • 맥락은 https://en.wikipedia.org/wiki/Npm_left-pad_incident를 보면 됨
    • NPM은 실제로 레지스트리를 큐레이션함. 주로 소비자에게 취약점을 알리고 악성 패키지를 제거하는 식임
    • 예전에 Sourceforge를 쓸 때는 프로젝트를 삭제하려면 먼저 허가를 받아야 하는 정책이 있었고, left-pad 이후 그 이유를 이해하게 됨

  • JavaScript와 그 생태계를 21세기의 Visual Basic 역병처럼 피하는 입장에서, 이 이야기에서 가장 흥미로운 부분은 Koçulu가 한동안 기술계와 거리를 두고 멋진 하이킹·캠핑·트레일 탐험을 했는데도, 8년 뒤에도 여전히 자신을 설명해야 한다고 느낀다는 점임
    기술은 변덕스러운 뮤즈 같음. 우리 nerd들은 기술에 집착하고 그 봉사 속에서 자신을 깎아내리지만, 기술은 늘 다시 빛으로 불러냄
    Morris worm 때 현장에 있었고 몇 주 동안 그 영향을 줄이는 일을 했던 사람으로서, 현재 도구로 세상을 바꾸는 기술을 만들 능력에는 근본 문제가 있다고 봄. 기술의 조직적·윤리적 실패를 이해하려 덜 애쓸수록, 기술은 적용되는 영역에서 생산적 변화를 만들기 어려워짐
    나도 이제 한 달쯤, 그리고 수백 번의 컴파일 실패쯤 뒤면 안식년을 가질 것 같은데, 몇 년 뒤 돌아왔을 때 내가 필요에 맞춰 다른 규모와 맥락으로 만들어 둔 기술 공간이 어떻게 보일지 생각하게 됨
    기술자들이 더 자주, 더 진지하게 안식년을 갖는 일이 어느 정도 표준이 되어야 할지도 모름. 그래야 우리의 기술적 역량을 짓누르는 윤리적 딜레마를 이해할 맥락을 얻을 수 있음

  • 사소한 점이지만 “대부분의 오픈소스 작업은 Unix 철학을 따랐고, 패키지는 한 번에 한 가지 일을 했다”는 문장은 애매함
    가장 obvious한 예로 libc가 Unix 철학에 어긋난다고 보는 사람은 보통 없음. 논쟁은 명령어나 데몬이 너무 많은 일을 하는지, 혹은 합성 가능하지 않은지에서 벌어짐. 최근 대표 사례는 systemd임

    • left-pad 소동은 오히려 NPM 패키지 세분화가 너무 작아져서, 패키지 단순성의 이점보다 패키지 관리 오버헤드가 더 커진 지점에 도달했음을 보여줬음
    • libc가 Unix 철학에 어긋난다고 보는 사람은 꽤 있음. 원한다면 지금 그렇게 말해줄 수도 있음
      현대적인 libc는 Unix 철학에 상당히 반함. 전통적인 Unix의 libc는 훨씬 단순했고 많은 함수가 그냥 시스템 호출이었음. 오늘날 libc의 일부는 libm 같은 별도 라이브러리로 분리돼 있었고, NSS나 복잡한 DNS 해석 프레임워크 같은 건 아예 없었음
    • “한 가지 일을 하라”의 반대편에는 그 한 가지 전체를 해야 한다는 조건이 있음
    • Unix 철학은 쓸모없거나 어쩌면 해로울 수도 있음. “한 가지”가 잘 정의되어 있지 않아서 실제로는 아무것도 더하지 못하고 논쟁만 낳기 때문임
      Eclipse도 “IDE 플랫폼이라는 한 가지 일”을 한다고 말할 수 있지만, Unix 개발자들이 그런 뜻으로 말한 건 아니라고 봄. 마찬가지로 11줄짜리 함수 하나만 담은 라이브러리를 만들라는 뜻도 아니었을 것임
      실제 조언은 “프로그램이나 라이브러리는 너무 많이도, 너무 적게도 하려 해서는 안 된다” 정도여야 함. 어느 정도가 너무 많거나 적은지는 결국 많은 프로그래밍 지침처럼 감각과 경험이 필요함
    • Unix 철학은 최대 텍스트 세그먼트 크기가 64KiB였던 16비트 미니컴퓨터에서 강력한 대화형 프로그래밍 환경을 얻는 방법을 알려주는 철학임. 지금 휴대폰에서 쓰는 libc는 1MiB로 16배 크니, 적어도 libc의 90%는 Unix 철학에 반함
      Lions book이나 APUE를 읽고, 다른 한편으로 pthreads 매뉴얼이나 ANSI C의 setlocale() 명세를 읽은 뒤 이 둘이 같은 철학을 나타낸다고 결론 내릴 수는 없어 보임. Ayn Rand가 Epicurus와 같은 철학의 대표자라고 보는 수준으로, 둘 중 어느 쪽에도 진지하게 관여하지 않았다는 뜻임

  • 이 사건에서 가장 강하게 남은 건 JavaScript 커뮤니티가 의존성에 너무 의존했다는 점이었음
    11줄짜리 코드 패키지 https://en.wikipedia.org/wiki/Npm_left-pad_incident#Backgrou...를 공개 취소했을 뿐인데 왜 그렇게 많은 비난이 갔는지 모르겠음. 그로 인해 얼마나 큰 좌절이 생길지 완전히 이해하지 못했다는 점도 글에서 말하고 있음
    NPM에는 사용 통계가 없었고 GitHub 활동도 거의 없어서, 사용자 입장에서는 패키지 공개 취소의 영향을 알 수 없었음. 근본 원인은 akoculu가 패키지를 내린 일이 아니라, 의존성 과잉, npm 정책, 그리고 코드를 캐시하거나 벤더링하지 않는 빌드 시스템 쪽에 더 가깝다고 봄

  • Azer Koçulu는 NPM 생태계의 재앙이었던 적이 없음. 누구도 left-pad를 쓰라고 강요하지 않았고, 그렇게 많은 프로젝트에 들어간 이유는 지저분한 전이 의존성 때문임
    반면 Jon Schlinkert는 이런 마이크로 라이브러리를 일부러 만들고, 널리 쓰이는 정상 프로젝트인 handlebars-helpers에 넣으면서도 실제 사용하는 프로젝트에 통합할 의지는 전혀 없어 보임. 낚이고 싶으면 handlebars-helpers를 쓰고, 아니면 그 라이브러리를 그만 쓰면 됨

    • 게다가 그는 NPM이 직접 제공한 스크립트를 실행했을 뿐임. 마이크로 패키지 상황이 터무니없었던 건 맞지만 Azer Koçulu는 잘못한 게 없음
      NPM이 그의 패키지를 강제로 가져갔고, 실행하면 위험한 게 분명한 스크립트를 제공한 게 문제였음. Azer Koçulu가 비난을 받았다는 것 자체가 우스움
      Jon Schlinkert는 전형적인 마케팅식 민폐 인물로 보이고, 개인적으로는 NPM과 Github에서 금지되어야 한다고 봄

  • kik 패키지의 버전 기록이 이상함. 9년 전에 보안용 점유 패키지로 대체되어 있음: https://www.npmjs.com/package/kik?activeTab=versions

    • 가장 큰 아이러니는 Kik이 그렇게 간절히 원했던 kik 패키지가 결국 사실상 아무것도 아니라는 점임
      Kik은 부주의하고 꽤 추잡한 회사로 드러남. 암호화폐 관련 논란도 있었지만, 기억나는 핵심은 Kik에서 포르노, 특히 아동 성착취물이 성행했다는 점이고, 이 Darknet Diaries 에피소드에서도 다뤄짐: https://darknetdiaries.com/episode/93/
      그런 관점에서는 Azer Koçulu가 그들에게 꺼지라고 한 게 꽤 통쾌함
    • 결국 이 모든 일이 아무것도 아닌 걸 위해 벌어진 셈인가 봄

  • left-pad가 패키지였다는 것 자체가 꽤 웃김. 아주 작은 유틸리티 함수를 쓰려고 CDN, 프록시, 빌드 파이프라인 등을 통해 얼마나 많은 바이트가 오갔을지 생각하게 됨
    기존 해결책을 활용하는 건 좋지만, 문자열 패딩이 필요할 때 “아마 이걸 위한 패키지가 있겠지”라고 생각하는 건 잘 이해가 안 됨

    • 당시 논의 중 일부는 left-pad 같은 마이크로 패키지에 끝없이 의존하던 웹 개발자들에게 꼭 필요한 경종이었다는 흐름이었음
      인기를 얻고 GitHub stars를 받기 위해 패키지를 배포하는 문화도 있었고, NPM으로 설치할 수 있는 걸 직접 구현하면 “바퀴 재발명”이라고 고집하는 개발자들도 있었음. 지금도 단순한 기능이어도 마이크로 패키지를 선호하는 개발자들과 많이 일하는데, 그들에게는 그게 “유지보수 감소”를 뜻함
    • 패키지의 원래 구현 https://en.wikipedia.org/wiki/Npm_left-pad_incident도 원하는 O(n)이 아니라 O(n²) 동작이 되었을 것처럼 보임
    • 프로젝트 안에서 누군가 이미 작성한 유틸리티 함수를 가져다 쓰는 것과, 생태계 안에서 누군가 이미 배포한 패키지를 가져다 쓰는 것 사이의 질적 차이가 정말 그렇게 큰가 싶음
      둘이 당연히 같지는 않지만, 충분히 발전한 도구가 있다면 둘을 비슷하게 다루고 싶어 하는 걸 이해 못 할 정도로 멀리 떨어져 있지는 않아 보임
    • 지금 AI도 비슷하지 않나 싶음. 단순 웹 검색으로 해결될 프롬프트가 얼마나 많은가
      복사·붙여넣기에 단계만 더 붙은 셈임
    • 최대 코드 재사용 과시이고, 복사·붙여넣기는 패배자나 하는 일임

  • “NPM 쪽에서는 개발자를 깔보는 전반적 태도를 봤고, 그것이 일련의 비합리적 결정을 낳고 결국 모든 비용을 내 탓으로 돌리게 했다”는 대목이 있는데, NPM은 이 사건 이후에도 그다지 배우지 못한 것 같음

  • 이 사건은 일어나서 다행이었음. 이름 선점은 실제 문제이고, 애매할 때는 사용자가 가장 덜 놀라는 쪽을 택해야 함
    사용 통계가 없었던 것도 큰 문제였고, 그냥 공개 취소할 수 있었던 것도 큰 문제였음. 인프라가 의견 강한 개인이 만든 사소한 10줄짜리 코드에 의존하는 것도 당시와 지금 모두 실제 문제임. 이 상황에서 진짜로 누군가에게 책임이 있다고 보긴 어렵고, 누구도 누구에게 빚진 건 없지만 모두가 배울 수는 있음

  • top-10 npm 패키지 몇 개를 유지보수하는 입장에서 보면 이 글은 완전히 말이 됨
    어느 순간부터 NPM은 커뮤니티와 협력하지 않게 되었음. Microsoft 인수로 굳어졌지만, 그 훨씬 전부터 분명했음
    npm 운영 방식에는 균열이 많았고, 커뮤니티나 메인라인 Node 팀과도 잘 협력하지 않았으며, 상업적 지속 가능성을 향한 밀어붙이기는 매우 거슬리고 강압적으로 느껴졌음. 팀원들 중 여럿도 다소 거친 평판이 있었음
    Oakland 사무실을 방문한 적도 있는데, 꽤 흥미로운 상호작용들이 있었고 특별히 긍정적이지는 않았지만 자세한 내용은 남겨둠
    당시 공개 취소 구멍은 잘 알려져 있었음. 모두가 left-pad가 인터넷을 망가뜨렸다고 비난했지만, 그 전체를 심각하게 잘못 관리한 npm 책임을 따지는 사람은 거의 없었음
    기억이 맞다면 npm은 유지보수자의 뜻에 반해 패키지를 강제로 복구했는데, 이는 좋게 봐도 그들이 섬긴다고 주장한 사람들과의 단절이고 나쁘게 보면 법적으로도 의심스러움. 그 직후부터 플랫폼 남용에도 별로 신경 쓰지 않게 되었고, core.js 광고 스팸 같은 일이 있었으며, 표준·호환성 등에서도 커뮤니티와 제대로 협력하지 않았음
    npm@5 릴리스는 재앙이었음. 패키지 잠금 파일 도입은 더 나쁠 수 없을 정도였고, 기억으로는 다음 Node.js 메이저 릴리스에 맞춰 내보내려는 압박이 있었음. Node 팀이 npm이 준비되길 기다리지 않았던 느낌이었는데, npm이 영리 기업이거나 적어도 그렇게 행동한다는 점을 생각하면 그건 오히려 좋은 일이었다고 봄
    끝없는 치명적 버그가 이어지던 시기의 커뮤니티 대응과, 압박을 넣는 커뮤니티를 부끄럽게 만드는 태도, 경건한 척하는 자세는 npm이 더 이상 자유·오픈소스 소프트웨어의 대리인이 아니었다는 증거였음. left-pad가 그 전인지 후인지는 기억나지 않지만, 머릿속에서는 생태계가 길게 쇠퇴하던 하나의 흐름으로 남아 있음
    지금 npm 패키지는 사소한 작업을 하는 작은 패키지들의 밈이 되었고 모두가 조롱함. 돌이켜보면 최선은 아니었을 수 있음. 하지만 맥락이 중요함. npm은 새롭게 떠오르던 인기 기술을 위한 최초의 매우 접근성 높은 패키지 관리자였고, 거의 전적으로 커뮤니티가 관리했으며, 검색 시스템도 좋고 GitHub의 “소셜 코딩” 정신과도 밀접하게 통합돼 있었음
    Node 초창기에 존재했고, ES5조차 없던 시절이라 var와 prototype을 쓰던 때였음. JavaScript 모범 관행도 제대로 없었고, Joyent가 Node.js를 커뮤니티에 넘기기 전이었으며, Io.js 포크와 Node 0.10/0.12의 긴 정체에서 벗어나기 전이기도 했음
    누구도 최선의 방식을 몰랐음
    작성자를 완전히 이해함. 보안 관점에서는 left-pad가 일어난 데 정말 감사함. 작성자의 의도가 그렇지 않았더라도, 자신들이 섬긴다고 주장하는 커뮤니티와 분리된 기업 이해관계에 의존할 때 어떤 위험이 생기는지 사람들에게 선명하게 보여줬음. 공급망 보안, 중복성 등에 관한 많은 대화를 시작했고, 장기적으로 업계를 조금 더 낫게 만들었음

    • 프로그래밍 언어용 최초의 패키지 관리자도 아니었고, 그 정도로 작은 패키지가 어리석다는 점은 이미 많은 사람이 짚었음
      npm, 그리고 JavaScript 전반은 주로 유행의 피해자임
답변달기