처리중입니다. 잠시만 기다려주세요.
TTJ 코딩클래스
정규반 단과 자료실 테크 뉴스 코딩 퀴즈
테크 뉴스
Hacker News 2026.06.02 36

GitHub이 오픈소스를 망치고 있다는 도발적 주장, 어디까지 진실일까

Hacker News 원문 보기

"GitHub은 소프트웨어에 대한 범죄다"

제목부터 좀 세죠? 한 개발자가 블로그에 올린 글인데, 요약하면 이래요. "우리가 당연하게 쓰는 GitHub이 사실은 오픈소스 생태계와 소프트웨어 개발 문화를 망치고 있다"는 도발적인 주장이에요. 처음 들으면 "무슨 소리야, GitHub 없으면 어떻게 개발하라고?"라고 반박하고 싶지만, 글을 끝까지 읽어보면 생각보다 짚을 만한 지점들이 있어요.

글쓴이의 핵심 불만은 GitHub이 너무 커지면서 "중앙집중화된 단일 플랫폼"이 돼버렸다는 거예요. 원래 Git이라는 도구 자체는 분산형(distributed) 버전 관리 시스템이거든요. 리누스 토발즈가 만든 이유 자체가 "누구의 서버에도 의존하지 않고, 각자 로컬에서 완전한 저장소를 가질 수 있게"였어요. 그런데 현실은 어떤가요? 사실상 거의 모든 오픈소스 프로젝트가 GitHub이라는 한 회사의 서버에 모여 있고, GitHub이 다운되면 전 세계 개발자가 일을 못 합니다.

구체적으로 뭐가 문제라는 걸까

글에서 지적하는 첫 번째 문제는 이슈와 PR이 GitHub에 종속돼 있다는 점이에요. 이게 무슨 소리냐면, 코드 자체는 Git에 들어 있으니까 다른 곳으로 옮길 수 있는데, 프로젝트의 진짜 역사인 이슈 토론, PR 리뷰 코멘트, 디스커션 같은 건 GitHub의 데이터베이스 안에만 있다는 거죠. GitHub이 내일 사라지거나 정책을 바꾸면, 수십 년치 토론 기록이 통째로 날아갈 수 있어요. 코드는 살아남아도 "왜 이 결정을 내렸는지"에 대한 맥락이 사라지는 거예요.

두 번째는 Pull Request라는 워크플로우 자체가 Git의 철학에서 벗어났다는 비판이에요. 원래 Git은 이메일로 패치를 주고받는 방식으로 설계됐어요. 지금도 리눅스 커널 개발은 메일링 리스트로 이뤄지죠. 이 방식의 장점은 누구의 플랫폼에도 묶이지 않는다는 거예요. 그런데 PR은 GitHub만의 개념이고, GitLab이나 Gitea의 머지 리퀘스트와도 완전히 호환되지 않습니다. 사실상 우리는 "Git을 쓴다"기보다 "GitHub의 PR 워크플로우를 쓴다"고 봐야 한다는 거죠.

세 번째 비판이 좀 더 묵직한데, 마이크로소프트 인수 이후 GitHub이 점점 "개발자 락인" 전략으로 가고 있다는 점이에요. GitHub Actions, Codespaces, Copilot, Advanced Security 같은 부가 서비스들이 점점 깊숙이 통합되면서, 한번 발 담그면 빠져나오기 힘들게 만들고 있다는 거죠. 처음엔 무료고 편하지만, 어느 순간부터 다른 플랫폼으로 옮기는 비용이 너무 커져버린다는 거예요. 특히 Copilot 같은 AI 도구는 모든 사용자의 코드를 학습 데이터로 쓸 수 있다는 점에서 윤리적 논란도 있고요.

그럼 대안은 뭔데

글쓴이가 제시하는 대안 중 하나는 이메일 기반의 패치 워크플로우로 돌아가자는 거예요. sourcehut(sr.ht) 같은 플랫폼이 이런 철학으로 만들어져 있어요. 코드 호스팅은 하지만 이슈와 패치는 메일링 리스트로 처리하는 방식이죠. 처음엔 좀 어색하지만, 익숙해지면 플랫폼 종속에서 자유로워진다는 장점이 있어요.

또 다른 흐름은 자체 호스팅(self-hosted) Git 서버예요. Gitea나 Forgejo 같은 오픈소스 솔루션이 점점 성숙해지고 있어요. Codeberg.org 같은 비영리 호스팅 서비스도 있고요. EU에서는 "디지털 주권" 차원에서 정부 기관들이 GitHub 대신 자체 호스팅으로 옮기는 움직임이 있어요. 프랑스 정부의 code.gouv.fr이 대표적인 예시죠.

분산형 접근으로는 Radicle이라는 P2P Git 호스팅 프로젝트도 있어요. 블록체인 같은 분산 네트워크 위에 코드 저장소를 올려서, 아예 중앙 서버 자체를 없애버리는 시도예요. 아직 실험적이지만 철학적으로는 가장 "Git의 원래 정신"에 가까운 방향이라고 볼 수 있죠.

현실적으로 어떻게 봐야 할까

솔직히 말하면 이 주장은 절반은 맞고 절반은 좀 과장이에요. 맞는 부분은 GitHub 의존도가 너무 높다는 거예요. 2018년 GitHub이 몇 시간 다운됐을 때 전 세계 개발자들이 패닉에 빠진 거, 기억하시는 분 많을 거예요. 또 일부 국가의 개발자들이 미국 제재로 GitHub에서 차단당하는 사건들도 실제로 일어났고요. 단일 플랫폼 의존의 리스크는 분명히 존재합니다.

반면 과장된 부분도 있어요. GitHub의 압도적인 편의성과 네트워크 효과는 단점이라기보다 그냥 시장이 자연스럽게 선택한 결과거든요. 분산형 시스템은 이론적으로 우아하지만, 처음 기여하는 사람 입장에서는 메일링 리스트보다 "Fork → Edit → Pull Request" 버튼이 훨씬 친절하잖아요. 오픈소스 진입 장벽을 낮춘 공로는 부정하기 어려워요.

한국 개발자에게 주는 시사점

한국에서 일하다 보면 이런 "플랫폼 종속" 논의가 좀 멀게 느껴질 수 있어요. 그런데 실무에서 의외로 영향을 받는 지점들이 있어요. 예를 들어 회사 내부 정책으로 "GitHub에 코드 못 올린다"는 곳들이 꽤 많아요. 이럴 때 Gitea나 GitLab 자체 호스팅 경험이 있으면 큰 도움이 됩니다. 또 본인의 사이드 프로젝트라면 Codeberg 같은 곳에 미러를 두는 것도 좋은 보험이에요.

그리고 좀 더 근본적으로, Git 자체를 제대로 이해하는 것의 가치를 다시 생각해볼 수 있어요. 많은 분들이 사실 "GitHub 사용법"은 알지만 Git의 분산형 철학은 잘 모르거든요. git format-patchgit am 같은 명령어를 한 번도 안 써보신 분들이 많을 거예요. 이런 도구들을 익혀두면 GitHub 없이도 협업할 수 있다는 자신감이 생깁니다.

마무리

결국 이 글은 "GitHub을 당장 떠나라"보다는 "우리가 너무 무비판적으로 한 플랫폼에 의존하고 있는 건 아닌지 한 번쯤 돌아보자"는 메시지로 읽히는 게 맞을 것 같아요. 편리함과 자율성 사이의 균형은 영원한 과제니까요.

여러분은 어떠세요? 만약 내일 GitHub이 사라진다면, 어떻게 협업하실 건가요? 혹시 GitLab이나 자체 호스팅으로 옮겨본 경험이 있으시다면 그 경험도 궁금합니다.


🔗 출처: Hacker News

이 뉴스가 유용했나요?

이 기술을 직접 배워보세요

AI 도구, 직접 활용해보세요

AI 시대, 코딩으로 수익을 만드는 방법을 배울 수 있습니다.

AI 활용 강의 보기

"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"

실제 수강생 후기
  • 비전공자도 6개월이면 첫 수익
  • 20년 경력 개발자 직강
  • 자동화 프로그램 + 소스코드 제공

매일 AI·개발 뉴스를 받아보세요

주요 테크 뉴스를 매일 아침 이메일로 전해드립니다.

스팸 없이, 언제든 구독 취소 가능합니다.