▲

Left-Pad (2024)

 (azerkoculu.com)
1P by GN⁺ 3일전 | ★ favorite | 댓글 2개
  • left-pad 사건은 오픈소스 커뮤니티와 NPM, 그리고 기업 간의 규칙과 가치 충돌을 보여주는 대표적 사례임
  • 패키지 삭제 결정은 논리나 분노, 탐욕이 아닌 진심과 내적 원칙에서 비롯된 행동임
  • NPM이 Kik Messenger의 요구에 굴복하며 자신들의 규칙을 어긴 상황에서, 작성자는 모든 패키지 삭제를 선택함
  • 사건 이후 오픈소스에 대한 열정이 변화하며 사업, 마케팅, 팀 운영 등 새로운 분야로 관심이 이동함
  • left-pad 사건은 개발자, 스타트업 업계에 오픈소스의 본질과 의사결정의 복잡성을 다시 생각하게 하는 계기가 됨

사건의 배경과 결정

  • left-pad 사건이 일어난 지 8년이 지난 시점에서, 작성자는 개인적인 경험과 생각을 공유함
  • 사건 당시 대부분의 시간을 신호가 닿지 않는 자연 속에서 보내며 자기 성찰을 하였고, 패키지 삭제 결정도 이 과정에서 이루어진 선택임
  • 이 결정은 논리적 판단, 분노, 탐욕이 아니라 자신의 내면 원칙, 즉 "NPM이 자신들의 규칙을 어긴다면, 내 모든 패키지도 지워져야 한다"라는 신념에서 시작됨
  • 엄격한 "규칙주의자"라기보다는 규칙의 정신 자체를 더 중시하는 자세였음
  • Kik Messenger와 같은 기업이 오픈소스 커뮤니티에 위협을 가하고 힘을 행사하는 상황에서, NPM은 스스로 정한 규칙을 무시하며 기업 이익을 우선함

NPM과 커뮤니티의 갈등 구조

  • 작성자는 Kik의 위협을 두려워하지 않았지만, NPM은 Kik을 잃는 것을 두려워함
  • 사건을 단순히 "분노한 남자가 대기업에 저항했다"고 해석하는 것은 사건의 맥락과 시간적 흐름, 결정의 무게를 간과한 단순화된 시각임
  • NPM 측은 갑작스럽거나 예상치 못한 일이 아니었음에도, 전반적으로 개발자에게 고압적인 태도를 보였으며, 일련의 부합되지 않는 결정들로 모든 책임을 작성자에게 전가함

패키지 구조와 영향

  • 작성자의 오픈소스 작업은 대부분 Unix 철학에 따라 작은 역할로 나뉘어 있어 350개 이상의 패키지로 구성됨
  • 표면적으로는 사용 흔적이 거의 없었지만, NPM이 사용 통계를 공개하지 않아 영향 범위를 파악할 수 없는 상황이었음
  • 사용자는 패키지 삭제의 실제 파급 효과를 알 방법이 없었고, NPM 역시 영향도 조사나 무분별한 삭제로 인한 문제 방지에 노력을 기울이지 않음

8년 후의 변화와 성장

  • left-pad 사건 몇 달 뒤에 본업을 그만두고 미국을 떠나, 모로코, 요르단, 튀르키예, 인도네시아 등 새로운 환경에서 자기만의 길을 찾아나감
  • 오픈소스에 대한 열정이 단절되는 죽음 같은 순간과 새로운 관심사로 다시 태어나는 순간을 경험함
  • 현재는 사업, 마케팅, 회사 및 팀 운영 등 다양한 분야에 프로그래밍과 동일한 열정으로 임함
  • 인생은 계속 이어진다는 메시지를 전하며, left-pad 사건은 자유로운 결정과 커뮤니티의 가치, 그리고 의사결정 과정의 복잡성을 되짚는 계기로 남았음
▲
ndrgrd 2일전  [-]

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

답변달기
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • 솔직하게 말해 이 블로그 글의 절반은 무슨 말인지 잘 모르겠는 느낌, 뭔가 맥락을 놓친 기분이 드는 상황이지만 "left pad guy"가 사건을 정리하는 점은 마음에 드는 포인트임
    그런데 다음과 같은 주장은 좀 이상하다는 느낌

    하지만 여전히 NPM이 내 모듈들이 얼마나 많이 쓰이는지 조사하고, 아무것도 깨지지 않게 unpublishing을 처리할 방법을 고민하지 않은 이유를 이해하지 못하겠음
    물론 NPM의 unpublish 방식이 잘못 설계된 것은 맞지만, 작성자가 말하는 건 누군가가 unpublish할 때마다 매번 수작업으로 확인해주길 기대했다는 의미로 느껴짐. 이런 기대감은 합리적으로 보이지 않음. NPM은 레지스트리를 큐레이션하는 조직이 아니라, 공공 서비스를 제공하는 주체라는 인식
    그래도 저자를 탓하긴 어렵다는 입장, "left-pad incident"를 저자가 유발하지 않았다면 머지않아 누군가가 했을 일이었을 것으로 생각. NPM은 문제를 수정했고, 더 나은 unpublish 정책도 마련함
    NPM의 새로운 unpublish 정책 참고 정보로 제공

    • 이 블로그 글의 절반을 이해 못 하겠다는 당신의 말
      원인은 당신이 아직 al-Ghazali를 읽지 않았기 때문이라고 생각.
      (이건 글에서 가장 거만하고 자기중심적인 부분임)

    • 참고 맥락은 Npm left-pad incident 위키피디아에서 확인 가능

    • 2016년 3월 18일, npm의 CEO Isaac Z. Schlueter가 Kik Interactive와 Koçulu 양측에 이메일을 보내 kik 패키지의 소유권을 Kik Interactive로 수동 이전할 것이라고 알림
      Koçulu가 npm의 결정에 실망감을 표현하고 더 이상 플랫폼에 참여하고 싶지 않다고 말하자, Schlueter는 그에게 등록한 모든 273개의 모듈을 삭제할 수 있는 명령어를 제공
      Koçulu는 3월 22일 그 명령어를 실행해 본인이 올린 모든 패키지를 삭제
      저자는 NPM 측에서 직접 알려준 명령어를 실행했을 뿐인데, 이후 NPM은 이 책임을 모두 저자에게 돌렸음

    • NPM이라는 회사는 NPM 레지스트리를 큐레이션하지 않는다
      실제로는 큐레이션을 함, 대표적으로 보안 취약점 신고를 받고 사용자에게 알리거나, 악의적인 패키지를 삭제하는 역할

    • 예전에 Sourceforge를 사용했을 때는 프로젝트 삭제 전에 반드시 허락을 요청해야 했던 정책이 있었음
      left-pad 이후에 그 이유를 확실히 이해하게 됨

  • 사소한 얘기지만

    내 오픈소스 프로젝트는 대부분 유닉스 철학을 따라 패키지들이 한 번에 한 가지 일만 하도록 설계했음
    아무도 libc가 유닉스 철학에 어긋난다고 주장하지 않음. 논쟁은 종종 명령어나 데몬이 너무 많은 기능을 가지는지(systemd가 대표적 예시), 혹은 조합성이 떨어지는지 여부로 일어남

    • left-pad 사태는 NPM 패키지의 세분화가 지나치게 작아져서, 패키지 단순화의 이점보다 오버헤드가 훨씬 커졌음을 보여준 사례라고 생각

    • 아무도 libc가 유닉스 철학에 어긋난다고 말하지 않는다
      오히려 많은 사람들이 그렇게 제안했고, 나 역시 그것이 맞다고 생각
      최신 libc는 전통적 유닉스 철학과는 전혀 다름
      예전의 libc는 더 단순했고, 여러 기능은 libm 등 별도 라이브러리로 분리됐으며 복잡한 DNS 등은 존재하지 않았음

    • 'do one thing'에 상반되는 점은, '온전히 한 가지 일을 다 해야 한다'는 것임
    • 유닉스 철학은 16비트 미니컴퓨터에서 강력한 대화형 프로그래밍 환경을 만들기 위한 지침
      현재 내가 휴대폰에서 쓰는 libc는 1MiB로, 전통적인 유닉스의 16배나 큼
      최소 90%의 libc가 유닉스 철학에 반한다는 결론
      Lions Book이나 APUE를 읽은 뒤 pthreads 매뉴얼이나 ANSI C setlocale() 명세를 보면 완전히 다른 철학임을 알 수 있음
      서로 다른 철학인데 같다고 여긴다면, 두 철학 어느 쪽에도 진지하게 공감 못 한다는 방증
    • "유닉스 철학"은 쓸모 없는 철학, 심지어 해로울 수 있음
      왜냐면 'one thing'의 의미가 명확치 않아 실제로는 아무런 도움이 안 되고 논쟁만 유발
      Eclipse도 'IDE라는 한 가지 일'만 한다고 볼 수 있으나, 그게 유닉스 개발자들이 의도했던 바는 아님
      11줄짜리 함수만 있는 라이브러리를 만들라는 의미도 아님
      진짜 조언은 "프로그램이나 라이브러리가 너무 많이도, 너무 적게도 하지 말자" 정도여야 함
      어디까지가 많고 어디까지가 적은지 판단하는 것은 결국 경험과 감각의 문제

  • 이 글을 써준 akoculu에게 감사
    나는 이 사건이 자바스크립트 커뮤니티, 즉 의존성에 너무 많이 의존한 생태계의 명확한 사례라고 생각
    왜 많은 사람들이 너를 그렇게 탓하는지는 모르겠음
    11줄짜리 코드를 가진 패키지를 unpublish 했을 뿐이고, 그로 인한 부작용 자체를 완전히 예측하지는 못했을 것
    작성자가 글에서 직접 언급

    NPM도 사용 통계를 잘 보여주지 않았고, Github에도 거의 활동이 없는 상황
    사용자 입장에서는 패키지를 언퍼블리시하는 영향력을 알기 어려웠음
    근본적인 원인을 akoculu의 unpublish에서 찾기보다는 의존성 과잉, npm 정책, 빌드 시스템의 캐싱/벤더링 부족에 있다고 생각
    사건 배경 위키 참고

  • kik 패키지의 버전 히스토리가 이상함
    9년 전 보안 홀딩 패키지로 대체됐음
    kik 패키지 버전 히스토리

    이번 사건의 가장 큰 아이러니는 kik 패키지임
    kik가 그렇게까지 차지하고 싶어 했던 kik 패키지는 결국 아무 쓸모가 없음
    그리고 Kik라는 회사는 부주의하고 문제가 많은 곳으로 밝혀짐
    크립토 관련 논란도 있었고, 암암리에 아동 포르노 등의 유통 플랫폼으로 거론되는 회사라는 점
    Darknet Diaries 93화 참고
    그래서 Azer Koçulu가 Kik에 대해 단호하게 거절한 점이 오히려 통쾌함

    결국 이 모든 일이... 결국 아무 의미도 없게 됐다는 결론?

  • left-pad가 패키지로 존재한다는 자체가 꽤 웃긴 상황
    문자열 패딩 함수 하나 때문에 CDN, 프록시, 빌드파이프라인 등을 통해 어마어마한 바이트가 이동
    기존 솔루션을 잘 활용하는 것엔 동의하지만, 단순히 문자열 앞을 채우는 함수를 두고 "아마 패키지가 있을 거야"라고 생각하게 된 상황은 이해하기 어려움

    당시 논쟁의 일부는 웹 개발자들의 마이크로 패키지에 대한 맹목적 집착을 일깨우는 계기였음
    인기, github star를 위해 패키지 릴리즈를 하는 문화도 있었음
    또 한편으론, npm으로 설치할 수 있는 것이면 어떤 함수든 직접 구현하지 않으려는 문화도 강했음
    현재 나와 함께 일하는 많은 개발자들도 여전히 간단한 패키지까지 선호하는 경우가 많음
    그들에게는 "유지보수 부담이 줄어든다"는 논리
    참 아이러니한 현실

    패키지의 원래 구현 또한 O(n)이 아니라 O(n^2)의 비효율 연산을 유발할 것으로 보임
    위키 참고

    타인의 프로젝트 내 유틸리티 함수를 참고하는 것과, 생태계 전체에 이미 퍼져 있는 패키지를 사용하는 것 사이에 품질상의 큰 차이가 있을까?
    같은 건 아니지만, 충분히 발전한 툴링을 가진 환경에서 두 접근이 실제로 그리 멀지 않다고 생각

    최대한 코드 재사용을 추구하는 현상, copy-paste는 한물간 방법이라는 강박

    혹시 이거 AI와 비슷한 상황 아닐까?
    단순 검색으로도 풀 수 있는 문제를 무수히 많은 프롬프트와 함께 AI에게 또 물어보는 현실
    C&P에 불필요한 단계를 하나 더 얹은 구조

  • 유닉스 철학은 "한 가지 일을 잘 하자"
    left-pad는 두 번째 조건(잘 하자)을 놓침
    이렇게 많은 프로젝트가 순진한 구현을 그대로 쓴 점이 놀라웠음
    더 최적화된 구현이 더 빠르고 더 작을 수 있음

    자바스크립트 문화를 잘 모르긴 하는데, npm 다운로드 수를 경쟁적으로 늘리는 풍조가 존재했던 것으로 기억
    left-pad는 주간 140만 다운로드, is-even은 16만 다운로드
    어떤 이들은 장난삼아, 어떤 이들은 라이브러리의 인기 지표를 올리려고 마이크로 패키지를 의존성에 추가
    react 기반의 유명한 라이브러리 내부에 is-even 같은 패키지를 넣는 것에 대해 반대하는 목소리도 있었음
    "직접 작성할 수 있는 코드라도 무조건 가져와라"는 식의 엄격한 원칙 때문
    관련 스토리: is-odd 패키지가 일주일간 3백만 번 설치된 이유

    '비순진적 구현(nonnaive implementation)' 예시가 궁금

  • npm 인기 패키지 메인트레이너임
    정말 공감할 수 있음
    npm은 어느 순간부터 커뮤니티 협업에서 멀어지기 시작
    마이크로소프트에 인수되며 더욱 견고해졌지만, 그 이전부터도 징후가 많았음
    npm의 여러 운영 방식, 커뮤니티/Node 팀과 비협조적이던 태도, 상업화에만 치중한 모습, 일부 구성원의 평판 등 여러 모로 거슬리는 점이 많았음
    Oakland 사무실 방문했던 기억이 있는데, 그랬던 날의 상호작용은 그리 긍정적이지 않았으므로 상세하게 말하진 않겠음
    unpublish 허점은 당시 모두가 인지하고 있던 문제였음
    모두 'left-pad가 인터넷을 망쳐놨다'는 식으로 저자만 탓했지만, 실제로는 npm 부실 운영 문제가 더 컸다고 생각
    기억이 맞다면, 메인터이너 본인 의사에 반해 패키지를 강제로 복구시켰고, 이는 npm이 자신들이 대변한다는 커뮤니티 수준에서 완전히 분리된 조치(최소한 법적으로도 이상함)
    이후 npm은 abuse, 스팸 등 관리에 관심을 거의 두지 않았고(core.js 광고 스팸 등), 커뮤니티와의 표준, 호환성 논의도 거의 안 했음
    npm@5 릴리즈도 대실패, 패키지 락파일 도입도 난리였음
    (Node 팀이 npm 준비를 기다리지 않고 출시한 것도 오히려 좋은 판단으로 봄)
    그 시점 커뮤니티와의 소통은 대형 버그, 커뮤니티 탓, 고압적 태도 등으로 엉망
    npm이 더 이상 오픈소스 정신의 대변자가 아니게 된 방증
    left-pad가 그 전이었는지 후였는지 기억이 가물가물하지만, 당시 생태계 전체가 장기적인 침체와 혼란기였음
    npm 패키지는 사소한 함수로도 독립 패키지(밈)처럼 여겨지지만, 맥락을 생각해보면 npm은 emergent popular technology(새롭게 떠오르는 기술)에 대한 최초의 접근성 높은 패키지 매니저였고, 커뮤니티 주도로 운영되며, Github와도 유기적으로 통합된 시스템이었음
    Node 초기(ES5도 없고 var, prototype 쓰던 시절), Joyent가 Node.js를 커뮤니티에 넘기기도 전, Io.js 포크 및 Node 0.10/0.12의 장기 정체기 이전이었음
    모두가 모범 사례가 뭔지 잘 몰랐던 시기
    저자의 입장에 정말 공감
    보안 관점에서 보면, left-pad 사건은 의도와 다르게 생태계 내 기업들/공동체가 분리된 현실과 공급망 보안에 대해 큰 각성을 준 사건
    중복성 강화와 보안에 관한 중요한 논의를 촉발시켰음
    업계가 결과적으로 더 나아지는 계기였다고 생각
    오랜만에 읽어보니 흥미로움

    npm은 어떤 언어의 최초 패키지 매니저가 아니었고, 이렇게 작은 패키지들이 많다는 점에 이미 많은 사람이 경고를 했었음
    npm과 JS 생태계 전반이 유행(trend)의 희생양이라는 생각

  • left-pad 당시의 관련 토론
    Hacker News 논의

  • 왜 Java는 Apache Commons, Google Guava처럼 신뢰받는 유틸리티 라이브러리가 있는데 JS는 그런 게 없을까?

    자바스크립트에도 Lodash 같은 신뢰되는 유틸리티 라이브러리가 존재. 과거에 비해 대부분의 기능은 이제 표준 라이브러리에 탑재
    사실 Lodash는 left-pad 사건 3개월 전부터 pad/padStart/padEnd 기능을 제공
    Lodash pad 문서

    가장 중요한 원인은 문화, 그리고 잘 짜인 표준 라이브러리, 그리고 300개 넘는 쓸모없는 패키지를 의존성에 쑤셔넣는 걸 방지하는 도구의 유무 순서라고 생각

    Maven은 정말 잘 설계된 도구(아이러니하게도 늘 욕만 먹지만), Java가 성공한 비밀 요인
    npm 같은 상업적 타협이 없는 이유는, Java에는 잘 지원되는 비영리·커뮤니티 기반의 Apache Foundation이 존재(이런 구조는 매우 드물고, Java 복잡한 법적 역사 덕분에 생겨난 운 좋은 결과)
    (JS에도 훌륭한 라이브러리는 많음. 문제는 패키지 관리가 지나치게 중앙집중화되고 관리가 부실했던 점)

    Google Guava는 lodash에 더 가깝고, left-pad와는 다름

    예전에는 Jquery, Underscore 같은 라이브러리가 그 역할을 해줬음

  • 빌드에 필요한 모든 의존성을 사내에서 미러링하지 않는 회사들이 너무 신기하게 느껴짐
    빌드 과정 전체를 오프라인에서 클린빌드할 수 있어야 하고, 다운로드 캐시에만 의존하는 건 운에 맡기는 꼴

    내 프로젝트는 언제나 dependencies를 내부에 벤더링
    예측 가능하고 오프라인으로도 빌드 가능, 저장 공간 비용도 저렴함

답변달기