GitHub 이전의 오픈소스 세계 — 중심이 흔들릴 때 다시 생각하는 것들

GitHub 이전의 오픈소스 세계 — 중심이 흔들릴 때 다시 생각하는 것들

2008년, GitHub의 첫 번째 사용자가 가입한 지 18년이 지난 지금, 개발자 커뮤니티는 작은 흔들림을 경험하고 있다. Mitchell Hashimoto(Vagrant, Terraform, Vault를 만든 HashiCorp 공동 창업자)가 자신의 프로젝트 Ghostty를 GitHub에서 이전하겠다고 발표한 것은, 단순한 플랫폼 이동이 아니다. "매일 아침 눈을 뜨면 GitHub을 열었다"는 사람이 "더 이상 진지한 작업을 할 수 있는 곳이 아니다"라고 말하는 것 자체가 하나의 시대 문법에금을 내고 있다.

GitHub 이전, 개발자들은 어떻게 살았나

GitHub이 등장하기 전, 오픈소스 프로젝트는 지금과 전혀 다른 모습이었다. 의존 가능한 프로젝트 수가 제한적이었고, 각 프로젝트의 평판과 지속성이 의존성 선택에 직접적으로 연결되었다. 의존성은 단순한 패키지명이 아니라, 프로젝트의 역사, 웹사이트, 유지관리자, 릴리스 과정, 커뮤니티 맥락까지 함께 따라왔다.

큰 프로젝트는 자체 인프라를 직접 운영하는 경우가 대부분이었다. Trac으로 이슈를 관리하고, Subversion으로 버전을 추적하며, 메일링 리스트로 토론을 진행하고, tarball로 배포하는 구조. Pocoo 같은 프로젝트 그룹에서는 여러 프로젝트가 서버 비용과 운영 부담을 함께 나누며 공존했다. Debian 패키징 과정처럼 라이선스와 저작권 헤더까지 검토받는 마찰이 있었지만, 그 마찰 자체가 신뢰 판단의 일부로 작동했다.

작은 프로젝트는 대학 서버나 SourceForge에 올라가는 경우가 있었지만, 개인 도메인 만료나 VPS 종료와 함께 프로젝트가 통째로 사라지는 일도 흔했다. Internet Archive가 없었더라면 우리가 잊었을 코드들이 수없이 많았을 것이다.

분산 버전 관리의 역설

Mercurial과 Git은인인도가 전체 저장소와 브랜치, 히스토리를 가질 수 있는 분산형 시스템이었다. 하지만 기묘하게도, 분산 버전 관리 시스템이 전 세계적으로 승리한 뒤 모든 것이 다시 하나의 거대한 중앙 서비스로 모여들었다. 전 세계가 하나의 GitHub에 표준화된 것이 현대 오픈소스의 가장 큰 아이러니로 남았다.

Subversion은 중앙집중형 저장소라 서버 운영이 자연스럽게 따라왔고, "프로젝트의 집"이 호스트명과 디렉터리, Trac 인스턴스, 메일링 리스트 아카이브처럼 물리적으로 분명했다. 반면 Git은 분산이라는 이름 아래 모든 것을 Decentralize할 수 있었음에도, 결국 개발자들 자신이 다시 하나의 플랫폼에 모여들었다.

GitHub가 바꾼 것

GitHub의 진정한 기여는 기술 자체보다 문화적 설계에 있다. "내 사용자명/저장소이름"이라는 단순한 공식은 SourceForge에서 프로젝트 이름을 정하고 예약한 뒤 CVS나 SVN 저장소와 웹사이트, 메일링 리스트, 이슈 트래커까지 갖추던 무거운 절차를 기억하는 사람이라면 그 해방감이 무엇인지 알 것이다.

"이건 그냥 잠깐 만드는 거야" 라는 정신적 부담을 극적으로 줄였다. 이슈 트래커, 풀 리퀘스트, 릴리스 페이지, 위키, organization 페이지, API, webhook, 그리고후래적 CI까지 — 공개 협업의 모든 요소가 하나의 URL 아래 표준화된 것이다.

한동안 GitHub는 오픈소스를 올리기 위한 매우 합리적인 기본 선택지였고, 미국 제재 대상 국가에서도 접근성을 유지하려는 정책은 중앙화가 단순한 호스팅을 넘어 공용 기반 역할을 수행할 수 있음을 보여줬다.

아카이브로서의 GitHub

GitHub의 덜 주목받았던 기능 중 하나는 아카이브 역할이다. 방치된 프로젝트도 검색 가능하게 남았고, fork, 오래된 이슈, 토론 기록이 계속 남아 있으면서 중앙화가 "발견 가능한 기억"을 만들어냈다.

반면대형 플랫폼 이전에는 개인 도메인 만료, VPS 종료, 개발자 부재와 함께 프로젝트 파일과 서비스가 통째로 사라지는 일이 흔했다. PyPI에 메타데이터만 남고 실제 패키지는 사라진 초기 프로젝트처럼, 저장소 주소가 오래된 개인 서버를 가리키다 끊기는 상황도 있었다.

과거의 많은 프로젝트가 결국 Internet Archive 같은 외부 보존 수단에 크게 의존해야 했다는 사실은, 중앙화된 플랫폼이 우연히담당시적 아카이브 역할까지 맡게 되었음을 보여준다.

npm과 의존성 폭발

GitHub 이전에는 신뢰와 지속성이 의존성 선택의 필수 요소였다. 다른 서비스 가용성을 믿기 어려워서 코드를 직접 저장소에 포함하는 Vendoring도 흔했으며, 외부 코드를 가져오는 스크립트 유지도 번거로웠다. 이런 마찰이 오히려 의존성 추가 전에 한 번 더 생각하게 만드는 안전장치 역할을 했다.

하지만 GitHub와 npm이 생성, 배포, 검색, 설치, 의존 비용을 거의 없애놓으면서, 패키지 그래프가 사람이 추론할 수 있는 속도보다 더 빠르게 자라기 시작했다. 라이선스 상태가 불명확해지는 문제에 대응하려고 GitHub가 약관을 개정할 정도로 상황은 복잡해졌다.

작은 패키지에 의존하더라도 저장소, 유지관리자 존재 여부, 이슈, 최근 변경, 다른 프로젝트 사용 여부, 코드와 패키지 설명의 일치 여부를 GitHub에서 확인하는 문화가 자리잡았다. GitHub가 npm 같은 레지스트리에 대한 Trusted Publishing까지 맡게 된 것은, 신뢰 체계의 핵심 축으로서의 위치를 확인해준다.

지금 무슨 일이 일어나고 있나

2026년, GitHub는 예전의 필연성을 잃어가고 있다. 불안정성, 제품 변화의 반복, Copilot AI 소음, 불명확한 리더십이 그 이유다. 2018년 Microsoft 인수 이후 조직 문화의 변질, Copilot 개발에 대한 자원 편중, AI 생성 코드의 품질 문제 등이 복합적으로 작용시테이루토이우 분석이 지배적이다.

Ghostty의 이동 발표는 상징적 움직임에 그치지 않는다. Strudel, Tenacity 등 영향력 있는 프로젝트들이 Codeberg로 이전하고 있으며, Radicle, git-bug 같은 분산형 대안도 거론되고 있다. Fossil처럼 처음부터 이슈 추적을 코드 저장소와 함께 관리하도록 설계된 VCS도 다시 주목받고 있다.

하지만 중요한 것은, "Git은 분산형이잖아요"라는 반론에 대한 실질적 답을 마련하는 것이다. 코드는 분산되어도, 이슈, 리뷰, 설계 토론, 보안 권고 같은 사회적 맥락은 생각보다 훨씬 쉽게 사라진다.

필요한 것은 공공 아카이브다

GitHub가 중심이든 그렇지 않든, 오픈소스에는 공적이고 안정적인 아카이브가 필요하다. 개발자 생산성 시장에서 이기기 위한 서비스가 아니라, 중요한 소프트웨어가 사라지지 않게 하는 구조. Endowment나 공공 자금처럼 장기적으로 유지 가능한 기반 위에서 돌아가야 한다.

소스 아카이브, 릴리스 산출물, 메타데이터, 프로젝트 맥락은 한 회사의 사업 모델이나 리더십 기분에 묶이지 않은 곳에 보존되어야 한다. 기억은 보존하고, 의존은 줄이는 방향. 프로젝트 이동이 쉬워지고, 한 회사의 표류가 모두의 문화적 위기로 번지기 어려운 시스템이 필요하다.

오래된 tarball 링크와 버려진 Trac 인스턴스로 돌아가고 싶지도 않고, 지난 20년의 GitHub 중심 구조를 영구적인 정상 상태로 받아들일 수도 없다는 긴장이 함께 남아 있다. 그 긴장 속에서 다음 시대의 오픈소스가십머양으로재정의될지, 지금 이 순간이 하나의 전환점이 되고 있다.

---

함께 보면 좋은 글

• GitHub 이전의 오픈소스 세계 — Pocoo Blog

• Ghostty, 18년간 사랑한 GitHub을 떠나다 — 박재홍의 실리콘밸리

• What to expect for open source in 2026 — GitHub Blog