▲

GitHub 이전의 오픈소스 세계

 (lucumr.pocoo.org)
1P by GN⁺ 4시간전 | ★ favorite | 댓글 1개
  • GitHub가 오픈소스의 사회적 인프라로 자리 잡기 이전, 개발자들은 자체 Trac, Subversion 저장소, 메일링 리스트 등 직접 운영하는 인프라 위에서 프로젝트를 관리했으며, 의존성 추가에도 상당한 마찰과 신중함이 수반되었음
  • GitHub는 프로젝트 생성·발견·기여를 획기적으로 쉽게 만들었고, 이슈 트래커·풀 리퀘스트·CI 등을 표준화하며 오픈소스의 아카이브 역할까지 수행
  • npm 등 패키지 생태계와 결합하면서 마이크로 의존성 폭발이 발생했고, GitHub는 신뢰 체계의 핵심 축이 되었으나, 현재 불안정성·제품 방향성 혼란·AI 노이즈 등으로 신뢰가 침식 중
  • Ghostty도 떠나고, Strudel, Tenacity 등이 Codeberg로 이전하는 움직임이 나타나고 있으며, 분산화는 자율성을 높이지만 이슈·리뷰·보안 권고 등 사회적 맥락의 소실 위험도 존재
  • 최근 GitHub의 중심성이 약해지는 조짐 속에서, 기억은 보존하고 의존은 줄이는 공적 아카이브가 더 중요해짐. 다음 시대의 오픈소스는 기억은 유지하되 의존성은 줄이는 방향이어야 함

GitHub 이전의 오픈소스 환경

  • GitHub 이전에는 의존 가능한 프로젝트 수가 제한적이었고, 각 프로젝트의 평판과 지속성이 의존성 선택에 직접 연결됨
  • 의존성은 단순한 패키지명이 아니라 프로젝트의 역사, 웹사이트, 유지관리자, 릴리스 과정, 커뮤니티 맥락까지 함께 따라왔음
  • 큰 프로젝트는 자체 인프라를 운영하는 경우가 많았고, 작은 프로젝트는 대학 서버나 SourceForge에 올라가는 경우가 있었음
  • Debian 패키징 과정처럼 라이선스와 저작권 헤더까지 검토받는 마찰이 있었고, 이런 마찰도 신뢰 판단의 일부로 작동함

자체 인프라 운영과 분산 버전 관리의 역설

  • 초기 오픈소스 프로젝트는 Trac, Subversion, tarball, 문서를 직접 운영하는 서버 위에서 굴러가는 경우가 흔했음
  • Pocoo처럼 여러 프로젝트가 서버 비용과 Subversion, Trac, 메일링 리스트 운영 부담을 함께 나누는 구조도 있었음
  • Subversion은 중앙집중형 저장소라 서버 운영이 자연스럽게 따라왔고, 프로젝트의 집은 호스트명과 디렉터리, Trac 인스턴스, 메일링 리스트 아카이브처럼 물리적으로 분명했음
  • Mercurial과 Git은 누구나 전체 저장소와 브랜치, 히스토리를 가질 수 있는 분산형 시스템이었지만, 실제 중심은 다시 GitHub로 모임
  • 분산 버전 관리 시스템이 승리한 뒤 전 세계가 하나의 거대한 중앙 서비스에 표준화된 점이 현대 오픈소스의 큰 아이러니로 남음

GitHub가 만든 변화

  • GitHub는 프로젝트 생성과 발견을 쉽게 만들고, 개발 메일링 리스트 경험이 없는 사람도 기여 흐름을 이해하기 쉽게 만듦
  • 이슈 트래커, pull request, 릴리스 페이지, 위키, organization 페이지, API, webhook, 이후의 CI까지 제공하면서 공개 협업의 기본값을 바꿔 놓음
  • 오픈소스 협업은 보이는 히스토리와 보이는 토론 위에서 진행하는 방식으로 보편화됨
  • 한동안 GitHub는 오픈소스 프로젝트를 올리기 위한 매우 합리적인 기본 선택지로 기능함
  • 미국 제재 대상 국가에서도 GitHub 접근성을 유지하려 했던 정책처럼, 중앙화는 단순한 호스팅을 넘어 접근 가능한 공용 기반 역할도 했음

아카이브로서의 GitHub

  • GitHub의 덜 주목받은 기능은 아카이브 역할이었고, 방치된 프로젝트도 검색 가능하게 남아 소프트웨어 공용 자산의 인덱스처럼 작동함
  • fork, 오래된 이슈, 토론 기록이 계속 남아 있으면서 중앙화가 발견 가능한 기억을 만들어 줌
  • 반대로 대형 플랫폼 이전에는 개인 도메인 만료, VPS 종료, 개발자 부재와 함께 프로젝트 파일과 서비스가 사라지는 일이 흔했음
  • PyPI에 메타데이터만 남고 실제 패키지는 사라진 초기 프로젝트처럼, 저장소 주소가 오래된 개인 서버를 가리키다 끊기는 상황도 있었음
  • 과거의 많은 프로젝트는 결국 Internet Archive 같은 외부 보존 수단에 크게 의존하게 됨

npm과 의존성 폭증

  • micro dependency 문제는 작은 패키지가 많아진 데서 끝나지 않았고, GitHub와 npm이 생성, 배포, 검색, 설치, 의존 비용을 거의 없애 보이게 만든 데서 더 커짐
  • GitHub 이전에는 신뢰와 지속성이 의존성 선택의 필수 요소였고, 다른 서비스 가용성을 믿기 어려워서 코드를 직접 저장소에 포함하는 vendoring도 흔했음
  • API 이전 시기에는 외부 코드를 가져오는 스크립트 유지도 번거로웠고, 이런 마찰이 의존성 추가 전에 한 번 더 생각하게 만듦
  • npm식 생태계에서는 패키지 그래프가 사람이 추론할 수 있는 속도보다 더 빠르게 커질 수 있음
  • 라이선스 상태가 불명확해지는 문제에 대응하려고 GitHub는 약관 개정도 시도함
  • 작은 패키지에 의존하더라도 저장소, 유지관리자 존재 여부, 이슈, 최근 변경, 다른 프로젝트 사용 여부, 코드와 패키지 설명의 일치 여부를 GitHub에서 확인하는 문화가 자리잡음
  • GitHub는 npm 같은 레지스트리에 대한 trusted publishing까지 맡는 몇 안 되는 시스템 중 하나가 되었고, GitHub 신뢰 약화는 소스 호스팅을 넘어 공급망 문화 전체에도 영향을 줌

GitHub의 약화와 이동 조짐

  • GitHub는 최근 불안정성, 제품 변화 반복, Copilot AI 소음, 불명확한 리더십 때문에 예전의 필연성 일부를 잃는 중임
  • agentic coding 흐름 한가운데 놓이면서 내부 압박도 커졌지만, 현재는 리더십 부재가 크게 느껴지는 상태로 묘사됨
  • 한동안 GitHub 이탈은 상징적 움직임에 가까웠지만, 이제는 영향력이 큰 프로젝트들도 이동을 공개적으로 검토하거나 실행 중임
  • Ghostty의 GitHub 이탈 발표는 목적지가 아직 뚜렷하지 않아도 강한 신호로 다뤄짐
  • Strudel moved to Codeberg
  • Tenacity moved to Codeberg
  • 아직 대세 전환을 만들 수준은 아닐 수 있어도, GitHub 바깥의 호스팅 공간을 다시 더 자주 보게 되는 흐름이 나타남
  • Git 자체가 원래 여러 개의 집을 전제로 설계된 만큼, 한 회사가 모든 것의 기본 집이 되는 상태를 끝내는 일은 오픈소스에 건강할 수 있음

분산 회귀의 비용

  • 여러 forge, 여러 서버, 여러 작은 커뮤니티로 돌아가면 탈중앙화와 자율성은 커지고 Microsoft 리더십 변화에 대한 의존은 줄어들 수 있음
  • 각 커뮤니티가 각자 다른 워크플로를 고를 수 있다는 장점도 있음
  • Pi의 현재 이슈 트래커 문제는 GitHub의 제품 선택이 오늘날 오픈소스 유지관리 현실과 맞지 않는 결과로 이어짐
  • GitHub는 유지관리자 정신 건강보다 engagement 중심으로 설계된 면이 드러남
  • 반면 self-hosted forge, 자체 Mercurial 서버, cgit 서버로 이동하면 코드 자체는 분산돼도 사회적 맥락은 쉽게 흩어질 수 있음
  • 이슈, 리뷰, 설계 토론, 릴리스 노트, 보안 공지, 오래된 tarball은 생각보다 훨씬 쉽게 사라짐
  • 과거에 이런 맥락을 담던 메일링 리스트는 오늘날 요구를 따라가지 못했고, 사용자 경험도 좋지 않음
  • 소프트웨어가 잊히는 성격에는 정화 효과가 있을 수 있지만, 손실 위험이 커지면 분산 버전 관리 시스템을 실제로 활용하는 방식도 다시 고민해야 함

필요한 것은 공공 아카이브

  • GitHub가 남든 프로젝트가 다른 곳으로 가든, 오픈소스에는 공적이고 지루하지만 안정적인 아카이브가 필요함
  • 개발자 생산성 시장에서 이기기 위한 서비스가 아니라, 중요한 소프트웨어가 사라지지 않게 하는 구조가 필요함
  • endowment나 공공 자금처럼 장기적으로 유지 가능한 기반 위에서 돌아가야 함
  • 소스 아카이브, 릴리스 산출물, 메타데이터, 프로젝트 맥락은 한 회사의 사업 모델이나 리더십 기분에 묶이지 않은 곳에 보존돼야 함
  • GitHub는 오픈소스 활동의 중심이 되면서 우연히 그 아카이브 역할까지 맡았지만, 중심성이 약해지면 그 기능이 자동으로 유지된다고 가정할 수 없음
  • 개인 서버와 선의만으로는 보존이 충분하지 않았고, Google Code와 Bitbucket에서도 플랫폼 종료 이후의 공백이 이미 드러남
  • 앞으로의 시스템은 기억은 보존하고 의존은 줄이는 방향으로 가야 하며, 프로젝트 이동, 사회적 맥락 미러링, 릴리스 보존이 쉬워지고 한 회사의 표류가 모두의 문화적 위기로 번지기 어려워져야 함
  • 깨진 tarball 링크와 버려진 Trac 인스턴스로 돌아가고 싶지도 않고, 지난 20년의 GitHub 중심 구조를 영구적인 정상 상태로 받아들일 수도 없다는 긴장이 함께 남아 있음

함께 보면 좋은 글 β

▲
GN⁺ 4시간전  [-]
Hacker News 의견들
  • GitHub가 준 가장 큰 변화 중 하나는 프로젝트 중심이 아니라 사람 중심 구조였다고 봄
    내 이름에 바로 저장소를 붙여서 빠르게 만들 수 있다는 점이, SourceForge에서 프로젝트 이름 정하고 예약해서 CVS나 SVN 저장소와 웹사이트, 메일링 리스트, 이슈 트래커까지 갖추던 무거운 절차보다 훨씬 해방감 있었음
    "이건 그냥 잠깐 만드는 것"이라는 정신적 부담을 크게 줄여줬음
    GitHub가 이슈 트래커, PR, 릴리스 페이지, 위키, 조직 페이지, API, 웹훅, CI를 한꺼번에 준 건 아니기도 했음
    예전엔 조직 기능이 없어서 새 사용자 계정을 만들어 조직 흉내를 내기도 했고, "GitHub가 몇 달 안에 내놓겠지" 하며 별도 버그 트래커 도입을 미루다가 결국 저장소에 텍스트 파일로 관리한 적도 있었음
  • 보통 프로젝트에서 Git이 Fossil보다 이긴 게 아직도 아쉬움
    Linux 커널 같은 초대형 코드베이스에서는 Git의 성능 이점이 있겠지만, 대다수 프로젝트는 VCS 성능 한계에 닿을 일이 거의 없음
    Fossil은 위키, 포럼, 티켓 같은 내부 도구가 코드와 함께 한 파일에 버전 관리되는 점이 정말 유용함
    프리랜서 작업에서는 Fossil 덕분에 프로젝트 맥락, 세부 사항, 클라이언트와의 합의를 다시 파악하기가 매우 쉬움
    코드베이스를 지저분하게 만들거나, 이메일과 메모 도구를 여기저기 뒤져서 문맥을 복구할 필요가 없음
    Git이 문화적으로 너무 깊게 박혔다고 해서 못 바꾼다고 생각하는 것도 싫음
    Fossil은 전환도 쉽고, Git에서 넘어와도 워크플로가 오히려 더 단순함
    • Git 프로토콜과 저장소를 기반으로도 비슷한 도구는 만들 수 있었고, 실제로 분산 코드 리뷰 같은 것도 있었음
      다만 다수는 그런 걸 원하지 않았고, 그래서 힘을 못 받았음
      이슈를 프로젝트와 함께 저장하면 곤란한 경우도 꽤 있음
      클라이언트가 버그 재현용 스크린샷이나 영상 파일을 많이 보내면 저장소가 금방 불어나고, 코드와 함께 묶어 두면 로컬에서 티켓 보려고 모두가 비대한 저장소를 받아야 해서 매우 번거로워짐
      결국 "이건 쓰지 말자, 너무 복잡하고 저장소만 부풀린다"로 흐르기 쉬움
      Fossil 기능 대부분은 Git 백엔드 위에도 구현 가능해 보이고, 위키나 이슈는 별도 병렬 브랜치 계층으로 두면 될 듯함
    • 타이밍 영향도 있었던 듯함
      기억으론 Git이 이미 안정적이고 일상적으로 쓸 만한 시점에도 Fossil은 버전 업데이트 때 저장소를 통째로 다시 만들어야 하는 경우가 있었음
      Git은 UX가 더 나빴고 지금도 그럴 수 있지만, 어쨌든 돌아갔고 실전 투입 가능한 느낌이 강했음
      게다가 세계 최대급 오픈소스 프로젝트 중 하나가 쓰고 있었으니, 인식 면에서 그 차이가 결정적이었음
    • 지금이야말로 누가 fossilhub.com을 사서 새 커뮤니티를 만들기 좋은 때라고 봄
    • 대형 저장소에서 Git이 왜 더 빠른지 궁금하긴 함
      다만 한동안은 큰 blob 처리에서는 그 장점이 잘 안 드러났던 걸로 기억함
  • GitHub가 아카이브 역할을 한 건 오히려 나쁘다고 봄
    99%의 시간엔 유용한 중앙집중형 서비스가 있으면, 공동체 전체의 보존 능력이 퇴화함
    무언가를 살아 있게 하려면 누군가가 직접 시드해야 하는 구조였다면, 사람들은 정말 중요하게 여기는 것의 사본을 더 잘 붙들고 있었을 것임
    "나중에 다시 체크아웃하면 되지"라고 쉽게 가정할 수 있게 된 게 오히려 문제임
    뭔가를 내릴 수 있는 단일 장소가 있어선 안 됨
    GitHub 프로젝트가 DMCA를 맞으면 포크까지 함께 사라짐
    Nintendo가 2024년에 인기 있던 Switch 에뮬레이터를 내렸을 때도, 누가 최신 리비전을 체크아웃해뒀는지 찾아서 돌려보는 식으로만 보존과 후속 작업이 가능했음
    그마저도 워낙 인기 프로젝트였기 때문에 가능했던 일임: https://news.ycombinator.com/item?id=40254602
    덧붙이면 이 사이트의 Splatoon 느낌 헤더/푸터 애니메이션은 정말 좋음
    거슬리지 않고 분위기를 살리면서도 스크롤하면 바로 비켜줘서, 나도 이거 그대로 훔쳐 쓰고 싶어짐
    • 그러다 보니 GitHub에 없으면 존재하지 않는 것처럼 느껴지는 분위기도 생김
      코드가 다른 곳에도 저장될 수 있다는 사실 자체를 모르는 개발자가 너무 많은 듯함
    • 아카이빙 자체는 쉬운데 저작권과 지식재산권 법이 발목을 잡음
      정보를 접근 가능하게 만드는 장애물을 줄이면 권력 집중도 덜해질 것임
    • 여기에 동의하지 않음
      GitHub가 수년간 신뢰를 얻은 이유 중 하나는 아직까지 그 아카이브 역할을 직접 수익화하지 않았기 때문임
      물론 Copilot 관련 새 기능들을 보면 앞으로는 모르겠음
      대안이 사이트 여러 개로 쪼개지는 것이라면, 각자 다른 DMCA 규칙을 갖게 될 뿐임
      그보다 나은 대안이 정확히 무엇인지 되묻게 됨
  • 이런 글을 읽으면 내가 참여했던 프로젝트들의 여정을 돌아보게 됨
    내 오픈소스 작업 대부분은 self-hosted 인프라 위에서 이뤄졌고, 대표 사례는 Xfce임
    2004년에 처음 참여했을 때는 SVN 서버와, 아마 CVSweb의 새 SVN 지원 웹 인터페이스 정도가 있었던 걸로 기억함
    내가 코어 팀에 들어간 뒤 Bugzilla를 세팅했던 것 같기도 한데, 그건 다른 사람이었을 수도 있음
    Git이 대세가 되기 시작했을 때는 큰 SVN 저장소를 여러 Git 저장소로 옮기는 작업을 주도했고, cgit 웹 인터페이스도 붙였음
    그때까지도 Bugzilla를 썼음
    2009~2010년쯤 작은 스타트업에 들어가면서 OSS에 쓸 시간이 줄어 프로젝트를 떠났다가 2022년에 돌아왔는데, 그 사이 GitLab 인스턴스와 CI 러너를 세우고 Bugzilla도 GitLab 이슈로 옮겨놨더라
    여전히 활동 인원은 한 줌이고 인프라 관리도 거의 한 사람이 맡지만, 작은 팀이어도 충분히 굴릴 만함
    인프라가 후원으로 제공되는 건 큰 행운이고, 정기 후원만으로도 필요하면 직접 비용을 낼 수 있을 듯함
    무엇보다 GitHub/Microsoft에 의존하지 않는다는 점이 정말 좋음
    20년 전에 누가 Microsoft가 세계 최대 OSS 코드 포지를 소유하게 된다고 말했다면 토할 뻔했을 것이고, 지금도 그건 영 불편함
  • 종종 간과되지만 공유 로그인도 정말 중요했음
    Rust는 crater라는 도구로 알려진 Rust 프로젝트 전체 테스트를 돌리는데, Cargo 내부 구현에 의존하는 프로젝트를 찾아 수백 개 이슈를 수작업으로 올릴 때 마찰이 적은 흐름이 큰 도움이 됐음
    사이트 자격 증명을 이미 갖고 있고 빈 템플릿도 허용되면 200개 이슈를 올리는 일이 훨씬 수월함
    반대로 self-hosted 인스턴스를 만나면 대개 거기서 포기하게 됨
  • SourceForge가 생기기 전부터 Planet Source Code에 글을 올렸었음
  • 나는 Trac을 정말 좋아했음
    새 오픈소스 프로젝트를 시작하면서 첫 단계로 Trac을 세팅하는 건 믿기 어려울 정도의 마찰이 있었지만, 그래도 좋았음
    Django는 지금도 20년 넘게 Trac 위에서 돌아가고 있음: https://code.djangoproject.com/timeline
    그걸 내가 세팅한 건 아니지만, 그보다 앞선 비공개 Trac을 띄우는 데는 도왔을 수도 있음
    • Trac은 정말 좋았음
      다만 내 첫 이슈 트래커는 Bugzilla였고, 세팅이 꽤 고통스러웠으며 다른 도구와 통합도 잘 안 됐음
      그래도 Zarro Boogs를 보는 재미는 꽤 각별했음
    • Trac은 여러 면에서 내가 배포용 앱을 PHP 대신 Python으로 만들게 한 계기였음
      플러그인 시스템이 정말 훌륭했음
    • 나는 Bitbucket을 좋아했음
      자기 역할을 잘했고, 내겐 딱히 깨지는 일도 없었고, Mercurial 쪽이 더 취향이었음
      회사들이 GitHub를 쓰니까 나도 옮겼지만, 지금도 GitHub는 그냥 둔한 Git 엔드포인트처럼만 쓰고 빌드/배포는 Docker와 셸 스크립트로 처리해서 갈아타는 비용이 매우 낮음
      업무에선 내가 결정권이 없으면 SVN 시절처럼 돈 받고 쓰는 도구를 그냥 쓰면 된다고 생각함
    • 이상하게도 당시엔 Trac을 엄청 싫어했으면서도 지금은 좋은 기억으로 남아 있음
      이것저것 너무 많이 하려다 어느 하나 탁월하지 못하다고 느꼈었음
      지금 그 상은 아마 GitLab이 가져갔고, 나중엔 그것도 좋게 기억할 듯함
  • 코드 아카이브 서비스를 궁금해서 찾아보니 몇 가지가 보였음
    GitHub 자체 프로그램도 있고: https://archiveprogram.github.com/
    UNESCO 지원 비영리인 Software Heritage도 있음: https://www.softwareheritage.org/2019/08/05/saving-and-referencing-research-software-in-software-heritage/
    다만 이쪽은 주로 코드와 커밋 히스토리 보존에 가깝고, 이슈나 PR, 토론, 위키 같은 주변 메타데이터까지는 잘 다루지 않음
  • Flask를 거의 초기에 써본 사람 중 하나였던 것 같음
    무료이면서 쉬운 현대적 호스팅이던 AppEngine을 활용하려고 Python을 배웠고, 그 덕분에 Flask가 나왔을 때 딱 좋은 자리에 있었음
    Armin을 오래 존경해왔고, 링크를 누르기 전부터 도메인을 보고 바로 알아봤음
    그 시절엔 기본 선택지가 GitHub가 아니었다는 그의 말에도 공감함
    이 글이 몇 시간 전 Mitchell 글에 대한 응답이라는 점도 인상적이고, 이렇게 빨리 길고 잘 짜인 고품질 글을 썼다는 게 놀라움
  • code.google.com 생각이 나게 됨
    Google이 그렇게까지 크게 공을 놓쳤다는 게 아직도 믿기지 않음
    • 정말 추억 돋음
      그 서비스가 닫히기 전에 내가 그 팀에 있었음
답변달기