오픈소스 패키지 저장소, 연 10조 다운로드에 버티기 한계 왔다

• 오픈소스 패키지 저장소들이 이제 진짜 한계에 가까워지고 있음

  • Sonatype에 따르면 기업들이 매년 내려받는 오픈소스 코드 파일이 10조 건을 넘음
  • 이 숫자는 구글의 연간 검색량의 두 배 수준인데, 정작 저장소들은 거대 검색 인프라가 아니라 기부금과 소수 운영팀에 기대고 있음

• 특히 문제는 사람이 클릭해서 받는 트래픽이 아니라, 기계가 미친 듯이 때리는 트래픽임

  • 빌드 시스템, 지속적 통합 파이프라인, 보안 스캐너, 인공지능(AI) 도구가 패키지 저장소를 거의 콘텐츠 전송망처럼 사용함
  • Maven Central을 운영하는 Sonatype 쪽에 따르면 수요의 82%가 단 1%의 아이피에서 나온다고 함
  • 어떤 회사는 같은 코드를 하루에 수십만 번씩 내려받고, 다음 날도 또 똑같이 반복함

• 그래서 리눅스 재단 아래에 지속 가능한 패키지 저장소 워킹그룹이 새로 만들어짐

  • Sonatype, Alpha-Omega, Eclipse Foundation, OpenJS Foundation, OpenSSF, Packagist, Python Software Foundation, Ruby Central, Rust Foundation 등이 참여함
  • 각 저장소가 따로 버티는 대신, 돈·운영·보안·거버넌스 문제를 한 자리에서 논의하자는 흐름임

• 운영자들이 말하는 핵심은 “이건 더 이상 선의와 남는 시간으로 굴릴 수 없다”는 것임

  • 지금 저장소들은 인프라 기부, 클라우드 크레딧, 소수 유급 인력, 무급 자원봉사자에 많이 의존함
  • 그런데 다운로드 수요는 계속 늘고, 보안 리포트와 자동화 게시, 악성 트래픽도 같이 늘고 있음
  • 기부와 보조금은 소수 기업에 집중돼 있고, 실제 사용량 증가와 비례해서 늘어나는 구조도 아님

• 돈만 더 넣는다고 끝나는 문제도 아님

  • 경제적 지속 가능성: 인프라, 운영자, 유지보수자, 거버넌스 비용을 현실적으로 감당할 모델이 필요함
  • 공동 방어: 저장소끼리 공격 정보와 보안 대응 방식을 공유해야 자동화된 공격을 따라잡을 수 있음
  • 거버넌스: 유료화나 제한 정책을 도입하려면 커뮤니티가 납득할 수 있는 규칙과 법적 틀이 필요함
  • 생태계 교육: 기업들이 “공개 저장소는 무한 무료”라는 착각에서 벗어나야 함

• 개발자에게 바로 닿는 포인트는 의존성 다운로드 전략임

  • 사내 프록시나 캐시 없이 모든 빌드가 공개 저장소를 직접 때리는 구조라면, 이제 그 자체가 생태계 부담이자 장애 리스크임
  • 대규모 조직일수록 패키지 캐시, 내부 미러, 의존성 고정, 보안 스캔 캐시 같은 운영 습관이 더 중요해짐

---

기술 맥락

• 이번 이슈의 핵심은 패키지 저장소를 다운로드 서버가 아니라 빌드 인프라로 봐야 한다는 점이에요. 거의 모든 서비스가 외부 의존성을 끌어와서 빌드되기 때문에, 저장소 장애는 곧 배포 장애로 이어지거든요.

• 기업들이 같은 패키지를 반복해서 직접 내려받는 이유는 빌드 파이프라인이 빠르고 단순해야 하기 때문이에요. 하지만 캐시 없이 공개 저장소를 계속 치면, 조직 입장에선 편해도 생태계 전체에는 비용을 떠넘기는 구조가 돼요.

• 그래서 내부 패키지 프록시나 미러가 중요해져요. 한 번 받은 의존성을 사내에서 재사용하면 빌드도 안정적이고, 공개 저장소 장애가 났을 때도 완전히 멈출 가능성이 줄어들거든요.

• 보안 측면에서도 저장소 운영자가 더 많은 역할을 맡게 됐어요. 무결성, 출처 검증, 악성 패키지 탐지, 정책 집행까지 요구받는데, 이걸 자원봉사와 기부금만으로 버티라는 건 이제 현실적이지 않아요.