GitHub 이전의 오픈 소스 세계, 자체 인프라, 의존성 폭발, 그리고 앞으로 필요한 아카이브에 대한 글.
2026년 4월 28일 작성
GitHub는 내 오픈 소스 소프트웨어의 첫 번째 보금자리가 아니었다. SourceForge가 그곳이었다.
GitHub 이전에는 내 own Trac 설치가 있었다. Subversion 저장소, 티켓, tarball, 그리고 내가 통제하는 인프라 위의 문서가 있었다. 나중에는 프로젝트들을 Bitbucket으로 옮겼는데, 그때의 Bitbucket은 특히 아직 Git에 완전히 올인하지 않은 사람들에게 오픈 소스 프로젝트를 위한 진지한 대안처럼 느껴지던 시절이었다.
그리고 결국 GitHub가 그 장소가 되었고, 나는 그 모든 것을 그곳으로 옮겼다.
GitHub가 내 삶에서 얼마나 중요해졌는지 아무리 말해도 과장이 되기 어렵다. 내 오픈 소스 정체성의 큰 부분이 그곳에서 형성되었다. 내가 작업한 프로젝트들은 그곳에서 사용자를 찾았다. 사람들이 그곳에서 나를 발견했고, 나도 그곳에서 다른 사람들을 발견했다. 수많은 직업적 관계와 수많은 우정이 어떤 저장소, 이슈, pull request, 또는 댓글 스레드 때문에 두 사람이 서로를 알게 되면서 시작되었다.
그래서 오늘날 GitHub에 일어나고 있는 일을 나는 이렇게 슬프고 또 실망스럽게 느낀다. 나는 이것을 단지 Microsoft의 사람들이 내가 싫어하는 제품 결정을 내리는 일로 보지 않는다. GitHub는 아주 오랫동안 오픈 소스의 사회적 인프라의 일부였다. 우리 중 많은 이들에게 그것은 단지 코드가 사는 곳이 아니라, 공동체의 큰 부분이 살아 있는 곳이었다.
그래서 GitHub의 쇠퇴를 생각할 때면, 나는 또한 그 이전에 무엇이 있었는지, 그리고 그 이후에 무엇이 올 수 있을지도 생각하게 된다. 나는 수년 동안 의존성에 대해 몇 번 글을 썼고, 특히 마이크로 의존성 문제에 대해 이야기했다. 내 생각에 GitHub는 그 현상에 생명을 불어넣었다. 그것은 내가 분명 완전히 지지했던 것은 아니지만, 동시에 오픈 소스를 더 포용적으로 만들었다. GitHub는 오픈 소스가 느껴지는 방식을 바꾸었고, 이후 npm과 다른 시스템들은 의존성이 느껴지는 방식을 바꾸었다. 이 둘을 합치면 코드 게시가 거의 마찰 없이 가능하고, 코드 소비도 거의 마찰 없이 가능하며, 세상의 프로젝트 수가 폭발하는 세계가 된다.
여기에는 많은 장점이 있다. 하지만 오픈 소스가 항상 이런 식으로 작동했던 것은 아니라는 점은 기억할 가치가 있다.
GitHub 이전의 오픈 소스는 훨씬 더 작은 세계였다. 반드시 그것에 관심을 가진 사람의 수가 적었다는 뜻은 아니지만, 우리 대부분이 현실적으로 의존할 수 있었던 프로젝트의 수는 적었다.
잘 알려진 프로젝트들이 있었고, 비교적 적은 수의 사람들이 오랜 시간 동안 유지 관리했다. 당신은 그 이름들을 알고 있었다. 메일링 리스트도 알고 있었다. 누가 수년째 그 자리에 있었는지, 누가 신뢰를 얻었는지도 알고 있었다. 그 신뢰가 완벽했던 것은 아니고, 옛 세계에는 충분한 gatekeeping도 있었지만, 평판은 매우 직접적인 방식으로 중요했다. Debian 사람들이 와서 우리의 라이선스 관련 일이 불명확하다거나 저작권 헤더가 기준에 못 미친다고 말할 때 우리는 자부심을 느끼기도 했고(그리고 짜증을 내기도 했는데), 왜냐하면 그들이 그것들을 패키징했기 때문이다.
의존성은 단지 패키지 이름이 아니었다. 그것은 역사와 웹사이트, 유지 관리자, 릴리스 과정, 많은 마찰, 그리고 종종 더 큰 공동체 안에서의 자리를 가진 하나의 프로젝트였다. 우리는 의존성을 가볍게 추가하지 않았다. 무언가에 의존한다는 행위는 대개 그것이 어디서 왔는지를 이해해야 한다는 뜻이었기 때문이다.
이 모든 것이 반드시 의도적이었던 것은 아니지만, 이런 프로젝트들은 비교적 규모가 컸기 때문에 자체 인프라도 함께 가져와야 했다. 작은 프로젝트는 대학 서버에서 돌아가기도 했고, 많은 프로젝트가 SourceForge에 있었지만, 더 큰 프로젝트들은 자기 무대를 직접 운영했다. 그리고 그것이 가능하도록 더 큰 집단으로 뭉쳤다.
내 첫 오픈 소스 프로젝트들은 내가 직접 운영한 인프라 위에 있었다. Trac 설치가 있었고, Subversion 저장소와 tarball, 문서, 그리고 릴리스 파일들이 내 기계나 내 통제 아래 있는 서버에서 제공되었다. 그것은 정상적인 일이었다. 소프트웨어를 공개하고 싶다면, 종종 소규모 시스템 관리자도 되어야 했다. Georg와 나는 우리 오픈 소스 프로젝트들을 위해 우리만의 집단인 Pocoo를 운영했다. 우리는 서버 비용과 Subversion, Trac, 메일링 리스트 등을 유지하는 부담을 함께 나눴다.
특히 Subversion은 이런 “자기 forge 운영”을 자연스럽게 만들었다. 그것은 중앙집중식이었다. 서버가 필요했고, 누군가는 그것을 운영해야 했다. 프로젝트에는 집이 있었고, 그 집은 대개 꽤 문자 그대로였다. 호스트명, 디렉터리, Trac 인스턴스, 메일링 리스트 아카이브가 있었다.
Mercurial과 Git이 등장했을 때, 그들은 철학적으로 정반대였다. 둘 다 분산형이었다. 누구나 전체 저장소를 가질 수 있었다. 누구나 자기 사본, 자기 브랜치, 자기 히스토리를 가질 수 있었다. 원칙적으로 그런 분산 버전 관리 시스템은 단일 중심의 필요를 줄였어야 했다. 하지만 이 모든 것에도 불구하고 GitHub가 중심이 되었다.
이것은 현대 오픈 소스의 큰 아이러니 중 하나다. 분산 버전 관리 시스템이 승리했고, 그러고 나서 세상은 그것을 호스팅하기 위해 거대한 중앙집중식 서비스 하나를 표준으로 삼았다.
지금은 GitHub의 실패만 이야기하기 쉽고, 실제로 현재 그 실패는 많지만, 그렇게만 하는 것은 불공정하다. GitHub는 오픈 소스에 거대한 선물이었고, 지금도 계속 그렇다.
프로젝트를 만드는 일을 쉽게 만들었고, 프로젝트를 발견하는 일도 쉽게 만들었다. 평생 개발 메일링 리스트를 구독해 본 적 없는 사람들에게도 기여라는 일을 이해할 수 있게 만들었다. 프로젝트들에 이슈 트래커, pull request, 릴리스 페이지, 위키, 조직 페이지, API 접근, webhook, 그리고 나중에는 CI까지 제공했다. 눈에 보이는 히스토리와 눈에 보이는 협업과 함께 오픈 소스가 공개적으로 이루어진다는 생각을 정상화했다. 그리고 10년 동안 훌륭하고 합리적인 기본 선택지였다.
하지만 어쩌면 GitHub가 한 일 중 가장 과소평가된 것은 아카이브 작업이었다. GitHub는 도서관이 되었다. 버려진 프로젝트들조차 계속 찾을 수 있었기 때문에, 소프트웨어 공유지의 거대한 일부에 대한 색인이 되었다. 포크를 찾을 수 있었고, 오래된 이슈와 토론도 계속 온라인에 남아 있었다. 중앙집중화에 대해 제기할 수 있는 불만이 많더라도, 그 중앙집중화는 동시에 발견 가능한 기억을 만들어냈다. 그곳의 리더들은 한때 미국의 제재를 받은 국가들에서도 GitHub를 계속 이용 가능하게 유지하는 일에 큰 관심을 가졌다.
나는 대안이 어떤 모습인지 안다. 왜냐하면 내가 그 안에서 살고 있었기 때문이다. 내 가장 초기 오픈 소스 프로젝트들 중 일부는 기술적으로는 아직 PyPI에 남아 있지만, 실제 패키지들은 사라졌다. 메타데이터는 내 옛 서버를 가리키고 있지만, 그 서버는 오래전에 그 파일들을 더 이상 제공하지 않게 되었다.
대형 플랫폼 이전에는 그것이 정상적이었다. 개인 도메인이 만료되고, VPS가 종료되고, 개발자가 세상을 떠나면, 그와 함께 그들이 비용을 지불하던 서비스들도 사라졌다. 웹은 한때 작은 소프트웨어 집들로 가득했고, 그중 많은 곳이 사라졌다 1.
마이크로 의존성 문제는 단지 사람들이 아주 작은 패키지를 공개했다는 것만이 아니었다. GitHub와 npm의 호스팅 인프라는 그것들을 만들고, 공개하고, 발견하고, 설치하고, 의존하는 데 비용이 전혀 없는 것처럼 느끼게 만들었다.
GitHub 이전 세계에서는 평판과 지속성이 거의 필연적으로 의존성 선택 과정의 일부였고, 종종 vendoring이 필요했다. 우리의 초기 의존성들 중 상당수는 기본적으로 그냥 우리 자신의 Subversion 트리에 vendored되어 있었는데, 부분적으로는 필요할 때 다른 서비스가 살아 있으리라고조차 믿을 수 없었고, API 이전 시대에는 그것들을 가져오는 스크립트를 유지하는 일이 고통스러웠기 때문이다. 그런 암묵적인 마찰은 어느 정도의 성찰을 강제했고, 그 결과 개발자 행동도 달라졌다. npm 스타일 생태계에서는 패키지 그래프가 누구의 추론 능력보다도 더 빠르게 성장할 수 있다.
이런 사고방식이 만든 문제는 또한 그 과정에서 해결책도 찾아야 한다는 뜻이었다. GitHub는 책임성 문제를 보완하는 데 도움을 주었고 라이선스 문제에도 도움을 주었다. 한때 새롭게 유입된 개발자들과 병합된 pull request의 물결은 실제 라이선스 상태가 무엇인지에 대해 많은 열린 질문을 남겼다. GitHub는 심지어 이용 약관으로 이 문제를 바로잡으려 시도하기도 했다.
수년 동안의 사고방식은 이랬다. 내가 어떤 작은 패키지에 의존하려 한다면, 최소한 그 저장소는 보고 싶다. 유지 관리자가 실제로 존재하는지, 이슈가 있는지, 최근 변경이 있었는지, 다른 프로젝트들이 그것을 사용하는지, 코드가 패키지가 주장하는 그것이 맞는지를 보고 싶다. GitHub는 신뢰를 제공하는 시스템의 일부가 되었고, 더 최근에는 신뢰된 게시를 통해 npm과 다른 레지스트리에 패키지를 게시할 수 있는 몇 안 되는 시스템 중 하나가 되기까지 했다.
이는 GitHub에 대한 신뢰가 침식될 때, 문제가 단지 소스 호스팅에만 고립되지 않는다는 뜻이다. 그것은 그 주변에 형성된 전체 공급망 문화에 영향을 미친다.
GitHub는 지금 현재 그것을 필연적으로 느끼게 만들었던 것의 일부를 잃고 있다. 어쩌면 그것은 거대한 중앙집중식 플랫폼의 삶과 죽음일 뿐일지도 모른다. 그런 플랫폼은 결국 언제나 실망을 안기기 때문이다. 지금 사람들은 불안정성, 끊임없는 제품 변화, Copilot AI 소음, 불명확한 리더십, 그리고 이 플랫폼이 더 이상 그것을 가치 있게 만든 공동체를 위해 주로 설계되지 않는다는 느낌에 지쳐 있다.
분명히 GitHub 역시 agentic coding 혁명의 한복판에 있고, 그것은 그곳 사람들에게 엄청난 압박을 준다. 하지만 이 사이트에는 리더십이 없다! 그럼에도 상황이 이 정도로 잘 굴러가고 있다는 것은 기적이다.
한동안 GitHub를 떠나는 일은 주로 작은 프로젝트들이나 소프트웨어 자유에 대한 강한 견해를 가진 사람들이 하는 상징적 움직임처럼 느껴졌다. Zig가 Codeberg로 옮겼을 때 나는 분명 움찔했다! 하지만 이제는 실제 무게감과 신호를 가진 사람들이 GitHub를 떠나는 이야기를 하는 것을 본다. 가장 분명한 사례는 Mitchell Hashimoto인데, 그는 Ghostty가 옮겨갈 것이라고 발표했다. 어디로 옮길지는 분명하지 않지만, 강한 신호다. 하지만 다른 사례들도 있다. Strudel은 Codeberg로 옮겼고, Tenacity도 그랬다. 이것들이 충분한 변화를 만들어낼까? 아마 아닐 것이다. 하지만 불과 1년 전과 비교해도 나는 다시 비-GitHub 영역에 더 자주 가고 있음을 느낀다.
누군가는 이것이 좋은 일이라고 주장할 수 있다. 하나의 회사가 모든 것의 기본 보금자리가 되어야 한다고 오픈 소스가 가장하는 일을 그만두는 것은 건강한 일이다. Git 자체도 많은 집이 있는 세상을 위해 설계되었다.
다시 많은 forge, 많은 서버, 많은 작은 집, 그리고 많은 독립 공동체로 돌아가면 탈중앙화는 더 커질 것이고, 여러 면에서 시스템이 적응하도록 강제할 것이다. 이는 자율성을 회복시키고 프로젝트들이 Microsoft 리더십의 변덕에 덜 의존하게 만들 수 있다. 또한 서로 다른 공동체가 서로 다른 워크플로를 선택할 수 있게 한다. 현재 Pi의 이슈 트래커에서 벌어지는 일은 대체로 GitHub의 제품 선택이 오늘날의 오픈 소스 세계에서는 작동하지 않은 결과다. 그것은 유지 관리자들의 정신 건강이 아니라 참여를 위해 만들어졌다.
그리고 이것은 웹이 다시 잊게 만들 수도 있다. 나는 잊는 소프트웨어를 꽤 좋아한다. 거기에는 정화하는 요소가 있기 때문이다. 어쩌면 실제 상실의 위험은 우리가 분산 버전 관리 시스템을 실제로 활용하는 일에 대해 더 많이 성찰하게 만들지도 모른다.
하지만 프로젝트들이 좀 더 자체 호스팅 forge에 가까운 곳으로, 자신들의 자체 호스팅 Mercurial이나 cgit 서버로 옮겨 간다면, 우리는 잃고 싶지 않은 것들을 잃을 위험을 감수하게 된다. 코드는 이론적으로 분산되어 있을지 몰라도, 사회적 맥락은 대개 그렇지 않다. 이슈, 리뷰, 설계 토론, 릴리스 노트, 보안 권고, 오래된 tarball은 취약하다. 그것들은 우리가 인정하고 싶어 하는 것보다 훨씬 쉽게 사라진다. 예전에는 이런 많은 것을 메일링 리스트가 전달했지만, 그것은 오늘날의 필요를 따라가지 못했고, 사용자 경험 면에서는 대체로 재앙이다.
사물들이 존재에서 희미해지는 발상을 내가 좋아하긴 하지만, 우리는 분명 도서관과 아카이브를 필요로 한다.
GitHub가 계속 남든 프로젝트들이 새 보금자리를 찾든 상관없이, 내가 보고 싶은 것은 오픈 소스 소프트웨어를 위한 공개적이고, 지루할 정도로 안정적이며, 충분한 자금을 갖춘 아카이브다. 기금(endowment)이나 공적 자금의 힘으로 계속 떠 있을 수 있는 무언가. 개발자 생산성 시장에서 이기는 것이 아니라, 우리가 만드는 가장 중요한 것들이 사라지지 않도록 하는 것이 그 일인 무언가 말이다.
화려한 기능들은 다른 누군가의 문제가 되어도 좋지만, 소스 아카이브, 릴리스 산출물, 메타데이터, 그리고 무슨 일이 있었는지 이해할 수 있을 만큼의 프로젝트 맥락은 한 회사의 사업 모델이나 리더십 기분에 묶여 있지 않은 어딘가에 보존되어야 한다.
GitHub는 오픈 소스 활동의 중심이 되었기 때문에 우연히 그런 아카이브가 되었다. 그것이 더 이상 성립하지 않는다면, 어떤 마법 같은 아카이브 기능이 저절로 생겨날 것이라고, 혹은 GitHub가 계속 그런 역할을 할 것이라고 가정해서는 안 된다. 우리는 이미 프로젝트의 집이 단지 개인 서버와 선의뿐일 때 어떤 일이 일어나는지 보았고, Google Code와 Bitbucket에 무슨 일이 일어났는지도 보았다.
나는 GitHub가 회복되기를 바란다. 정말로 그렇다. 부분적으로는 많은 역사가 그곳에 살아 있고, 아직 그 일을 하고 있는 사람들이 진정으로 중요한 무언가를 물려받았기 때문이다. 하지만 나는 더 이상 오픈 소스의 계속되는 기억을 GitHub가 건강한 제품으로 남아 있는 데 의존하게 두는 것이 책임 있는 일이라고 생각하지 않는다.
GitHub 이전의 세계에는 더 많은 자율성과 더 많은 상실이 있었고, 어떤 면에서는 우리는 아마 다시 그곳으로 돌아가게 될 것이다. 적어도 한동안은. 사람들이 다음에 무엇을 만들기 시작하든, 그것은 기억은 지키고 의존성은 버리려 해야 한다. 프로젝트를 옮기기 더 쉬워야 하고, 그 사회적 맥락을 미러링하기 더 쉬워야 하며, 릴리스를 보존하기 더 쉬워야 하고, 한 회사의 표류가 다른 모두에게 문화적 위기가 되기 더 어려워야 한다.
나는 깨진 tarball 링크와 버려진 Trac 인스턴스의 옛 웹으로 돌아가고 싶지 않다. 또한 오픈 소스가 지난 20년이 정상적이었거나 영구적이었다고 가장하는 것도 원하지 않는다. GitHub는 오픈 소스의 놀라운 한 장을 썼고, 그 장이 끝나고 있다면, 다음 장은 그것으로부터 그리고 그 이전에 있던 것으로부터도 배워야 한다.
이 글에는 github, open-source 및 thoughts 태그가 달려 있다.
