GitHub의 문제점

AI 요약

GNU 프로젝트의 Jacob Bachmeyer와 Richard Stallman은 개발자들에게 GitHub에 저장소를 두지 말라고 권합니다. 이 글은 GitHub의 문제를 라이선스 안내, 비자유 JavaScript, SaaSS(Service as a Software Substitute), 분산 버전 관리 시스템 Git의 중앙화라는 네 갈래로 나눠 설명합니다. 저자들은 GitHub가 Git 자체를 소유하지는 않지만, 편리한 기능을 앞세워 사용자가 GitHub에 의존하는 작업 방식을 택하도록 유도한다고 봅니다.

라이선스 안내와 브라우저 JavaScript

GitHub는 2008년 저장소 호스팅을 시작할 때 자유 소프트웨어 라이선스 안내를 제공하지 않았고, 그 결과 라이선스를 선언하지 않은 공개 저장소가 늘었다고 글은 지적합니다. 2013년 시작한 Choose a License 사이트도 GPL 적용 안내가 부정확하다고 비판합니다. 라이선스 전문을 저장소 파일 하나에 복사하는 것만으로 충분하다고 설명하지만, FSF 법률가들은 GPL을 적용할 때 실질적인 각 파일에 라이선스 고지를 넣으라고 권한다는 내용입니다. 파일별 고지가 없으면 GPL의 특정 버전만 적용되는지, 이후 버전도 선택할 수 있는지 불분명해질 수 있다고 설명합니다.

GitHub 웹사이트는 많은 JavaScript를 브라우저로 보내며, 저자들은 그중 상당수가 비자유 소프트웨어라고 주장합니다. JavaScript 없이도 사이트가 정상적으로 작동하도록 설계하지 않아, 저장소를 보는 것 외의 상호작용이 막히고 일부 파일 보기 링크도 작동하지 않는다고 지적합니다. Git 명령줄 도구로 저장소를 복제하거나 REST API와 명령줄 도구를 이용하는 우회 방법도 소개합니다. 다만 GitHub의 API 명령줄 도구에는 사용 정보를 수집하는 telemetry가 들어 있어 권할 수 없다고 덧붙입니다.

Copilot과 SaaSS

글은 GitHub Copilot을 SaaSS 사례로 분류합니다. Copilot의 초기 코드 완성 모델은 여러 라이선스로 공개된 코드로 학습했고, GNU GPL 전문이나 Zen of Python 같은 문구를 길게 그대로 출력한 사례가 있었다고 설명합니다. 그 때문에 제안 코드의 법적 지위를 둘러싼 의문이 생겼으며, GitHub가 일부 고급 구독자에게 제공하는 면책이 GPL 준수를 요구받는 상황에서는 어떻게 작동할지도 불분명하다고 지적합니다.

Copilot이 버그 보고서 초안을 작성해 이슈로 제출하는 기능도 비판합니다. 사용자가 결과를 검토하지 않으면 오류가 담긴 이슈가 프로젝트 관리자에게 쌓일 수 있지만, 관리자는 Copilot이 생성한 이슈 제출을 차단할 수 없다고 글은 주장합니다. 저자들은 이런 문제와 별개로, Copilot이 원격 서버에서 실행되고 사용자가 모델을 통제하지 못하는 점 자체가 SaaSS의 문제라고 봅니다. 서비스 제공자가 사용자가 원하지 않는 모델 변경이나 가격 인상을 단행할 수 있다는 설명입니다. 2026년 초 GitHub가 구독을 사용량에 따른 토큰 기반 요금제로 바꾸겠다고 발표한 사례도 듭니다. 실제 계산 자원 사용량은 사용자가 통제하기 어렵고, 이런 변경이 가능한 까닭은 Copilot이 SaaSS이기 때문이라고 주장합니다.

Git의 분산 구조와 GitHub 중심 작업 흐름

Git은 중앙 장애 지점 없이 작동하는 분산 버전 관리 시스템으로 설계됐습니다. 그러나 저자들은 GitHub가 사용자를 자기 서비스 안에 묶는 기능과 관행을 쌓아 이 구조를 다시 중앙화한다고 비판합니다. 예를 들어 GitHub의 원클릭 병합은 pull request에서만 작동하고, pull request는 GitHub에 호스팅된 fork에서 만들어야 합니다. 기본 연속 통합도 GitHub 서버에서 실행됩니다. Git 자체는 인터넷 어디에 있는 저장소에서든 변경 사항을 가져올 수 있지만, GitHub의 pull request는 GitHub 저장소를 기준으로 작동한다고 지적합니다.

GitHub의 fork는 Git에서 저장소를 복제하는 일반적인 방식과 구별되는 기능입니다. 저자들은 단순한 패치 작업에도 fork가 생기면서 방치된 저장소가 늘고, GitHub가 fork의 파일을 부모 저장소 주소로도 가져올 수 있게 해 저장소의 신뢰성이 흐려진다고 주장합니다. 사용자 계정과 조직 계정이 같은 이름 공간을 공유하는 점도 혼란을 더한다고 설명합니다. 사이트 활동으로 배지를 얻는 Achievements 역시 GitHub에 대한 의존을 키우는 게임화 사례로 꼽습니다.

GitHub Actions는 커밋이나 pull request에 따라 임의의 스크립트를 실행하는 자동화 기능입니다. 작업은 기본적으로 GitHub의 가상 서버에서 실행되지만, 사용자가 자체 서버를 지정할 수도 있습니다. 저자들은 자체 실행기(runner)가 자유 소프트웨어여도 자동 업데이트 기능을 포함하고, 실행할 작업을 지시하는 GitHub의 SaaSS 인프라에 의존한다고 비판합니다. 다만 Actions에 연결하는 작업 자체는 저장소 소유자가 선택하므로 SaaSS는 아니며, 로컬에서 워크플로를 실행하는 자유 소프트웨어 act도 대안으로 소개합니다.

이메일과 커뮤니티 참여

Git은 개발자 신원을 인터넷 전반에서 식별하는 수단으로 이메일 주소를 사용하며, 커널 Linux 개발은 메일링 리스트와 이메일 패치 교환을 중심으로 진행돼 왔다고 글은 설명합니다. 반면 GitHub는 메인 웹 화면에서 이메일 주소를 숨기고, 계정과 연결된 주소 대신 GitHub 프로필 링크를 보여줍니다. 토론 참여에도 GitHub 계정이 필요합니다. 저자들은 이런 설계가 기존 개발자와 사용자의 접점을 줄이고, 아직 자신을 개발자로 여기지 않는 사람에게 사회적 장벽을 만든다고 봅니다.

저자들이 제시하는 근본적인 대응은 문제를 피할 수 있는 호스팅 서비스로 저장소를 옮기는 것입니다. 당장 이전하기 어렵다면 README에 이메일 주소를 공개하고, 프로그램 사용 안내를 비자유 소프트웨어 없이 읽을 수 있는 별도 웹사이트에 올려 그 주소를 안내하라고 권합니다.

Lobsters 반응

• @pyfisch — GNU 프로젝트는 윤리적 저장소 기준을 공개하고 여러 forge를 평가했습니다. 자체 Savannah 외에 추천할 만큼 충분한 점수를 받은 곳은 Sourcehut뿐입니다. Codeberg.org가 궁금한 분들을 위해 덧붙이면, GitHub와 마찬가지로 F를 받을 겁니다. 한 가지 이유는 JavaScript가 필요하고, Codeberg의 JavaScript는 자유 소프트웨어지만 GNU가 승인한 방식으로 표시되어 있지 않기 때문입니다. GNU 프로젝트가 모두에게 무엇이 잘못됐는지 말하면서도 자신의 가치와 비전에 맞는 새 소프트웨어를 만들지 못하는 것 같아 실망스럽습니다.
• @ryan-duve — 비자유 소프트웨어를 피하는 일은 코딩 바깥의 생활에서도 점점 어려워집니다. 비자유 소프트웨어가 더 많은 곳에 나타나니 그게 잘못됐다고 느끼기도 점점 어렵습니다. 예를 들어 우리 마을은 공원과 동네 곳곳에 무료 지하 퇴비통을 설치했습니다. 그런데 잠그지 않으면 사람들이 쓰레기통으로 쓰곤 했습니다. 그래서 마을에 온라인으로 등록한 뒤 Bluetooth와 스마트폰 앱으로 통을 여는 제도를 만들었습니다. 하지만 스마트폰 앱만 쓸 수 있습니다. 참여하려면 독점 비자유 앱을 써야 합니다. 이 글에서 JavaScript 함정을 거부하는 사용자는 저장소를 보는 일 외에는 아무것도 할 수 없다는 대목을 읽으면서, 일반적인 해결책이 뭔지 궁금해집니다. “GitHub를 피하라”는 친구와 동료가 그곳에 있어도 쓰지 말라는 뜻입니다. “스마트폰 앱을 피하라”는 우리 공동체의 환경 활동에 참여하지 말라는 뜻입니다. 자유 소프트웨어가 옳다고 생각하지만, 둘 다 옳은 선택처럼 보이지는 않습니다. 소프트웨어가 현실 생활 곳곳에 들어오면서 비자유 소프트웨어를 피하라는 주장이 점점 효과를 잃은 것 같습니다. 이런 글에 대안을 함께 제시한다면 더 도움이 될 겁니다. Sourcehut이나 Codeberg를 쓰라는 말만이 아니라, 소프트웨어 자유를 생각하지 않는 사회가 퇴비통을 잠그는 상황에서 다른 방식으로 참여하는 대안 말입니다.
  • @thombles — 이 경우 GitHub의 클라이언트 JavaScript가 압축되지 않은 GPL 코드라고 상상해 보면 도움이 됩니다. 물론 답은 “전혀 아니다”입니다. 그러니 그 점만을 근거로 한 2차 효과를 너무 걱정하지 않아도 됩니다.
  • @carlomonte — 아마 “피하라”는 말은 자신이 무언가를 공개할 때 현명하게 선택하라는 뜻일 겁니다. 저장소를 가져오거나 pull request를 보내는 일은 선택의 여지가 많지 않습니다. 그들의 목록은 너무 오래됐다는 점이 아쉽습니다. 자기 홍보로 Git과 Savannah를 넣고 Sourcehut도 언급하지만 Codeberg나 Heptapod는 빠졌습니다. Git만 언급하고 Mercurial, Fossil 같은 다른 도구도 잊었습니다. 그래도 선택지는 있습니다.
  • @nobe4 — 좋은 지적입니다. 나쁜 현 상태를 거부하기가 얼마나 어려운지 잘 보여준다고 생각합니다. 삶은 기술과 점점 더 얽혀 있고, 기술 사용을 거부하기가 날마다 더 어려워진다고 볼 수도 있습니다. 권력이 소수에게 집중되면 어려움은 더 커집니다. 최근에는 EU App ID가 Google Play Integrity를 요구한 사례가 있었지만, 적어도 논의는 이어지는 것 같습니다.
• @xnacly — 전반적으로 그냥 Microsoft라고 하겠습니다.

원문: GNU / 번역·요약: Trawling