GitHub 이전 시대의 풍경: 우리는 어떻게 코드를 공유했나

향수가 아니라 맥락의 이야기

Flask와 Jinja2의 메인테이너로 유명한 아르민 로나허(Armin Ronacher)가 "Before GitHub"라는 제목의 글을 올렸어요. 단순한 추억담이 아니라, 현대 오픈소스 협업의 표준이 어떻게 만들어졌고, 우리가 그 과정에서 무엇을 잃었는지를 짚어보는 회고예요. 최근 미첼 하시모토의 Ghostty가 GitHub을 떠난다는 발표와 맞물리면서, 이 글은 더 의미심장하게 읽힙니다.

GitHub 이전의 협업 풍경

GitHub이 등장한 건 2008년이에요. 그 이전 오픈소스 세계는 훨씬 파편화돼 있었습니다. Python 프로젝트는 SourceForge나 자체 Trac, 메일링 리스트로 굴러갔고, Linux 커널은 지금도 그렇지만 메일링 리스트와 패치 파일 중심이었어요. 패치(patch)가 뭐냐면 "이 파일의 이 줄을 이렇게 바꿔주세요"라는 변경사항을 텍스트로 정리한 파일인데, 옛날엔 이걸 메일에 첨부해서 보내면 메인테이너가 직접 적용해보고 머지 여부를 결정했어요.

버전 관리 시스템도 다양했습니다. CVS, Subversion(SVN), Mercurial(hg), Bazaar, Darcs… Git은 이 중 하나에 불과했어요. 프로젝트마다 쓰는 도구가 달라서, 새 프로젝트에 기여하려면 우선 그 프로젝트의 도구를 익혀야 했죠. 진입 장벽이 지금과는 비교가 안 될 정도로 높았습니다.

이슈 트래킹도 따로였어요. Bugzilla, Trac, Redmine 같은 툴을 각 프로젝트가 자체 호스팅했고, 계정도 따로 만들어야 했습니다. 어떤 프로젝트에 버그를 신고하려면 그 프로젝트 사이트 가서 가입하고, 인증 메일 받고, 양식 채워넣고… 이걸 매번 해야 했어요.

GitHub이 바꾼 것

GitHub의 천재성은 "하나의 계정으로 모든 곳에 기여할 수 있다"는 통합에 있었어요. Pull Request라는 워크플로우는 "내 포크에서 작업한 것을 원본 메인테이너에게 머지 요청한다"는 패턴을 표준화했고, 이건 이메일 패치보다 훨씬 직관적이었습니다. 이슈, PR, 코드 리뷰, CI까지 한 자리에 모이면서 OSS 기여의 한계비용이 극적으로 낮아졌어요.

이 통합의 결과는 엄청났습니다. 학생, 주니어, 비영어권 개발자처럼 진입 장벽에 막혀 있던 사람들이 대거 OSS 생태계에 합류했어요. 우리가 지금 당연하게 여기는 "GitHub 프로필이 곧 포트폴리오"라는 문화도 이 시기에 자리 잡았습니다.

그런데 잃어버린 것은

로나허가 짚는 부분이 여기예요. 통합과 표준화의 대가로 우리는 다양성과 자율성을 잃었습니다. 옛날엔 프로젝트마다 자기만의 거버넌스, 자기만의 워크플로우, 자기만의 커뮤니티 분위기가 있었어요. 메일링 리스트 시절의 토론은 길고 깊었고, 디자인 결정은 RFC 스타일 문서로 차곡차곡 쌓였습니다.

GitHub의 PR/Issue 모델은 빠르고 효율적이지만, 동시에 짧은 호흡의 상호작용을 강제해요. "LGTM" 댓글 하나로 머지가 끝나는 문화는 가벼운 변경에는 좋지만, 큰 아키텍처 결정에는 부족합니다. 또한 모든 프로젝트가 GitHub의 UI/기능 한계 안에서만 협업하다 보니, 새로운 협업 도구의 실험이 거의 멈춰버린 측면도 있어요.

그리고 가장 큰 문제는 단일 회사에 생태계 전체가 종속됐다는 점입니다. Microsoft가 GitHub을 어떻게 운영하느냐에 따라 전 세계 OSS의 미래가 좌우되는 상황이거든요.

업계 맥락

이런 회고가 나오는 배경은 분명합니다. Codeberg, sr.ht, Forgejo 같은 대안 호스팅이 다시 주목받고 있고, AI 학습 데이터로 OSS 코드가 무단 활용된다는 우려가 커지고 있거든요. 미첼 하시모토의 Ghostty 이전, SQLite의 Fossil 고집, Drew DeVault의 sr.ht 운동까지 모두 같은 흐름의 다른 표현이에요.

흥미로운 건 ActivityPub 기반의 연합 Git 호스팅(Forgejo Federation 같은) 같은 시도들입니다. 이건 "한 곳에 모이지 않고도 서로 PR을 주고받을 수 있게 하자"는 아이디어인데, 성공한다면 GitHub 시대의 다음 챕터가 될 수 있어요.

한국 개발자에게는

실용적인 시사점은 두 가지예요. 첫째, GitHub이 영원하지 않을 수 있다는 가능성을 염두에 두는 거예요. 회사 코드를 다 옮기라는 게 아니라, Git 자체는 분산 시스템이라는 사실을 다시 인식하고, 백업과 미러링 전략을 평소에 점검해두는 거죠.

둘째, 표준화의 편안함에 길들여지면서 잃어버린 협업 방식들을 한 번쯤 경험해보세요. 메일링 리스트 기반 토론, RFC 스타일 디자인 문서, 더 긴 호흡의 코드 리뷰 같은 것들이요. 큰 결정을 내릴 때는 PR 댓글보다 별도의 디자인 문서가 훨씬 효과적이거든요.

마무리

GitHub은 OSS의 진입 장벽을 낮춰준 위대한 발명이지만, 동시에 단일 플랫폼 의존이라는 새로운 문제를 만들어냈어요. 로나허의 회고는 "옛날이 좋았다"가 아니라 "우리가 무엇을 트레이드오프했는지 잊지 말자"는 메시지입니다.

여러분은 GitHub 외의 협업 도구나 워크플로우를 경험해본 적이 있으신가요? 만약 GitHub이 사라진다면 가장 그리워질 기능은 뭘까요?