GitHub에서 10억 번째 저장소 생성 축하

 (github.com/AasishPokhrel)
2P by GN⁺ | ★ favorite | 댓글 1개
  • GitHub 사용자 jonmagic이 Issue #1에서 GitHub의 10억 번째 저장소 생성을 축하하며, 저장소 shit이 해당 ID를 가진다고 알림
  • 근거로 제시된 curl -s 응답에는 **id 1000000000**, node_id R_kgDOOO5rKAA, name shit, full_name AasishPokhrel/shit`이 포함됨
  • 댓글 흐름은 저장소 이름과 💩 이모지를 활용한 축하·농담 중심으로 이어졌고, 초기 글에는 수천 개의 👍·😄·🎉 반응이 달림
  • jonmagic은 저장소 소유자가 필요할 경우 대화 잠금이나 구독 해제를 사용할 수 있다며 GitHub 문서 링크를 남김
  • 2025년 6월 28일 저장소 소유자가 대화를 collaborator로 제한하고 잠갔으며, 같은 날 댓글 하나가 삭제됨

10억 번째 저장소로 지목된 shit

  • Issue 제목은 Congratulations on creating the one billionth repository on GitHub!이며, GitHub에서 10억 번째 저장소 생성을 축하하는 내용임
  • jonmagic은 저장소 생성자를 축하하면서 다음 API 호출 결과 일부를 근거로 제시함
  • 축하 메시지는 “멋진 💩를 만들 기회가 있기를 바란다”는 식으로 저장소 이름을 활용한 농담을 포함함

댓글 반응과 농담 흐름

  • 초기 댓글들은 대부분 축하와 말장난으로 구성됨
    • “어떤 멋진 💩를 만들지 기대된다”
    • “이 💩가 뜨기를 기다릴 수 없다”
    • “이걸 fork하겠다”
    • “이 이슈가 잠기기 전에 댓글을 남긴다”
  • MangoCubes는 jonmagic이 GitHub 직원이라 안심했다는 반응을 남김
  • jordigh는 “수정 예상 일정이나 우회 방법이 있느냐”는 식으로 일반적인 이슈 댓글 형식을 패러디함
  • 이후에도 💩, sssssssshit, “peak shit” 같은 짧은 댓글이 이어짐

알림 폭주에 대한 안내

참여 규모와 반응

  • 원문 이슈 본문에는 수천 개의 반응이 표시됨
    • 👍 4524개
    • 😄 2116개
    • 🎉 2638개
    • ❤️ 945개
    • 🚀 1201개
    • 👀 611개
  • 댓글 목록 중간에는 1136개 항목이 더 남아 있음으로 표시되어, 일부 댓글만 노출된 상태임
  • 메타데이터에는 참가자 일부와 +1092가 표시됨

잠금과 이후 상태

  • 2025년 6월 28일 저장소 소유자가 대화를 잠그고 collaborator로 제한함
  • 같은 날 luckydonald의 댓글 하나가 삭제됨
  • 이슈 하단에는 GitHub 대화에 참여하려면 가입하거나 로그인해야 한다는 안내가 표시됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • OpenStreetMap의 1억 번째 변경셋이 떠오름
    몇몇 사람이 나 포함해서 가볍게 노렸지만, 결국엔 노리던 사람이 아니라 아프리카 지도를 열심히 그리던 사람에게 돌아갔음
    지나고 보니 훨씬 훈훈한 결말이고, 그 사람은 이전에 OSM 상 후보로도 추천된 적이 있었음
    OpenStreetMap은 모든 게 실제 운영 데이터라 대충 쓰레기 데이터를 만들기 어렵고, 그래서 N번째 커밋이 누군가의 즉흥 작업일 가능성이 더 큰 듯함
    GitHub에도 재미있는 업적임 :)
    OSM 이정표에 대해 더 읽고 싶다면 공식 블로그 글: https://blog.openstreetmap.org/2021/02/25/100-million-edits-...
    당시 변경셋 활동에 대한 내 정리: https://www.openstreetmap.org/user/LucGommans/diary/395954

    • 예전에 친구가 우리 헬프데스크 100만 번째 티켓을 만들려고 근무일 하루를 통째로 썼음
      결국 어떻게 해냈는지는 모르지만, 그 업적을 기념하려고 팀에서 작은 파티도 했음
      아마 15년쯤 전인데, 그때는 기술 업계 일이 더 재미있었던 느낌임

  • 멋지다! GitHub의 자체 OpenAPI Spec도 저장소에서 int32가 넘치기까지 이제 10억 개 조금 넘게만 남았음
    워크플로 실행 ID에서는 이미 그런 일이 벌어지고 있음
    https://github.com/github/rest-api-description/issues/4511

    • CTO로 잠깐 일했던 회사에 가 보니, 핵심 테이블 하나가 이미 13억 행인데 기본 키로 32비트 정수를 쓰고 있었음
      당시 증가 속도대로면 몇 달 안에 기본 키 값이 넘칠 상황이라, 대참사를 피하려고 ID를 64비트로 올리는 프로젝트를 꽤 급하게 진행했음
    • 몇 주 전에 LuaRocks가 65,535개 패키지를 넘으면서 Lua 커뮤니티에 약간의 문제가 있었음
      이 숫자와 LuaJIT에서의 LuaRocks 구현이 충돌했고 [1] [2], 일부 사용자들의 CI/CD 파이프라인과 개인 작업 흐름이 실패하면서 고통을 줬음
      꽤 빨리 해결됐지만 흥미로운 일이었음
      [1] https://github.com/luarocks/luarocks/issues/1797
      [2] https://github.com/openresty/docker-openresty/issues/276

  • 아직 Apple에 있었다면 좋았을 텐데
    여기 대부분은 Apple이 오래전부터 Radar라는 내부 도구를 쓴다는 걸 알 것 같음
    각 Radar에는 ID, 즉 버그 번호가 붙어 있음
    버그 #1,000,000 같은 Radar는 꽤 특별했음
    누군가 실수해서 팀 전체를 실망시키지 않는 한, 보통은 내부 농담이 잔뜩 들어간 가짜 Radar였음
    하나만 열어봐도 충분했는데 Radar가 다른 Radar를 참조할 수 있어서, 대체로 거기서부터 rabbit hole로 빠져들며 즐기게 됐음
    기회가 있었을 때 몇 개라도 캡처하거나 인쇄해두지 않은 건 정말 멍청한 일이었음

    • Google의 모노레포 버전 관리 시스템에도 변경마다 이런 단조 증가 ID가 붙음
      안타깝게도 몇 년 전 어떤 둥근 숫자에 가까워졌을 때, 그 ID를 잡으려는 사람들이 스크립트를 돌리면서 시스템이 서비스 거부 상태가 됐음
      그래서 지금은 큰 둥근 숫자 근처의 ID를 건너뜀 :(
      여기에는 아마 스키마 설계에 대한 교훈이 있을 듯함
    • 반대로 Apple이 기밀 데이터를 다루는 방식을 생각하면, 아무리 무해해 보여도 내부 문서를 빼내다 걸리고 싶진 않았을 것 같음

  • GitHub 저장소 ID 얘기를 하는 김에, 첫 번째 저장소는 여기 있음
    https://api.github.com/repositories/1
    https://github.com/mojombo/grit

  • 아마 스크립트로 https://api.github.com/repositories/999999999를 반복 확인하다가 나타나는 순간 새 저장소를 만든 듯함
    저장소는 수정할 수 있으니, 여유를 두고 여러 개 만든 뒤 맞는 번호가 아닌 것들을 지웠을 수도 있음
    작성자가 어제 만든 다른 저장소를 보면 “yep”이 마법의 숫자였고, “shit”은 빗나갔다는 인정이었을 것 같음
    Facebook의 D666666을 기억하는 사람이 있나?
    거대한 코드 변환이었고, 작성자가 특정 번호를 얻으려고 이와 비슷한 기법을 썼음

    • 아니면 아닐 수도 있음
      왜 이 사람이 일부러 그 저장소를 잡았다고 가정하는지 모르겠음
    • 빈 저장소라서, 맞는 듯함

  • 진지하게 말하면, GitHub가 새 저장소 생성 속도를 계산하기 이렇게 쉽게 해둔 게 조금 놀라움
    이런 정보는 보통 기업 비밀 아닌가?

    • 해자가 10억 개 폭이면, 속옷 차림으로 좀 돌아다니게 되는 것 같음
    • GitHub가 이 정보를 숨겨야 할 이유가 있나?
      이걸 어떻게 GitHub에 불리하게 쓸 수 있을지 모르겠음
      많은 회사가 강제되지 않는 한 아무 정보도 공개하지 않는 쪽을 기본값으로 삼는 건 이해함
    • 이진 검색을 쓰면 최신 ID도 엄청 빨리 찾을 수 있음
      예전에 여러 웹사이트의 성장을 이런 식으로 추적했음
    • 새 사용자 생성 속도도 볼 수 있음
      어떻게 보면 그쪽이 더 흥미로움

  • AasishPokhrel이 10억 번째 저장소가 되려고 이 저장소를 만들었는지 궁금함

    • AasishPokhrel은 어제 저장소 2개, “shit”과 “yep”을 만들었음
      5월 17일부터 6월 10일 사이에는 활동이 없었음
      저장소 생성 속도를 계산해서 원하는 번호에 맞춰 저장소를 만들 수 있는지는 모르겠음
    • 이건 꽤 쉽게 조작할 수 있음
      10억 번째가 나올 때까지 저장소를 계속 만들고, 이전 것들을 지우면 됨
      GitHub API로는 아주 간단함
      문제는 속도 제한과 동시에 저장소를 만드는 다른 사람들뿐이라 결국 운의 문제임
    • 그가 네팔에서 소프트웨어 개발을 공부하는 대학생인 것 같은데, 이런 이정표가 세계 깊숙한 곳까지 닿을 수 있다는 게 정말 뭉클함
      이걸 이력서에 크게 넣고 개발 분야에서 좋은 커리어를 찾으면 좋겠음
    • 매우 의심스럽지만, 가능하긴 해 보임

  • 그 저장소가 이름이 바뀌었고 이제 https://github.com/AasishPokhrel/repository/로 리다이렉트되는 듯함
    별로임 :-(

    • 다시 원래 이름으로 바뀌었음! :-D

  • 로컬 Forgejo와 GitLab 서버까지 다 합치면 전체 저장소가 얼마나 될지 궁금함
    Subversion, Mercurial, git의 다른 친구들, 그리고 적들까지 포함해서 말임
    이런 것들을 위한 검색 엔진을 누가 이미 만들었을까?
    “a” 같은 단어를 검색해서 대략적인 규모를 추정할 수 있으면 좋겠음
    중앙화된 GitHub의 큰 장점은 항상 사람들이 실제로 내 코드를 찾을 수 있다는 점처럼 보였음
    Microsoft가 GitHub를 인수한 뒤로 검색을 만들어볼까 생각했지만, 마케팅 쪽을 감당 못 해서 헛수고가 될 것 같아 결국 안 했음
    최근에는 Codeberg에 여러 프로젝트를 올리면서 다시 해볼 가치가 있을지 생각했는데, 누군가 이미 선수를 쳤을지도 모르겠음

    • 형제 댓글들에서 나온 API 열거 방식을 보면, 굳이 추정할 필요는 없을 것 같음
      https://docs.gitlab.com/api/projects/#list-all-projects — 이상한 이유로 GitLab은 저장소가 아니라 프로젝트라고 부르는 듯함
      https://codeberg.org/api/swagger#/repository/repoGetByID — Forgejo.org 사이트에서 연결된 것이니 아마 Forgejo와 Codeberg 모두 동일할 것임
      그리고 그 친구 https://gitea.com/api/swagger#/repository/repoGetByID
      Heptapod는 GitLab CE의 “친화적 포크”라 API도 동일하게 동작함: https://heptapod.net/pages/faq#api-hgrc
      그다음엔 프로젝트별 GitLab 인스턴스들을 색인해야 할 듯함: Gnome, GNU(언젠가 다시 열어준다면), Savannah 쪽 상황, 아마 Sourceforge, 어쩌면 sourcehut까지
      복권에 당첨된다면, Apache 라이선스였던 시절의 sourcegraph 인스턴스를 최대한 많은 곳에 걸쳐 운영할 자금을 대고, 그 스냅샷을 Internet Archive에 기부하고 싶음
    • Software Heritage에서는 공개 저장소 3억 8천만 개를 목록화했고, 그중 2억 8천만 개가 GitHub에 있음: https://archive.softwareheritage.org/
      저장소 검색은 아직 꽤 제한적이라 URL 전체 텍스트 검색이나 package.json 같은 소수의 메타데이터 파일 검색 정도만 가능함

  • https://ohshitgit.com

답변달기