깃허브 독점에서 벗어나려면 '연합형 포지'가 필요하다는 주장

• 탱글드가 던지는 문제의식은 단순함. 전 세계 오픈소스의 대부분이 깃허브 한 곳에 기대는 건 별로 건강하지 않다는 얘기임

  • 글에서는 '중앙화된 시스템은 결국 무너진다'고 보고, 오래 버틴 건 이메일, 깃, 아이알시 같은 프로토콜 기반 시스템이었다고 말함
  • 깃 자체는 분산형인데, 협업과 커뮤니케이션은 깃허브 웹사이트에 강하게 묶여 있다는 게 핵심 문제임

• 코드 협업은 원래 두 가지가 같이 움직였다는 설명이 깔려 있음. 하나는 코드 전송, 하나는 대화와 리뷰임

  • 예전 방식은 git으로 코드를 주고받고 이메일로 패치를 논의하는 구조였음
  • 깃허브 시대에는 코드 전송은 여전히 git이지만, 이슈와 풀 리퀘스트, 리뷰, 소셜 기능은 깃허브 웹사이트가 담당함
  • 포지페드 쪽은 git과 액티비티펍 조합을 고민하고, 탱글드는 git과 에이티 프로토콜 조합을 밀고 있음

• 탱글드의 핵심 아이디어는 여러 깃 서버가 협업 이벤트를 서로 연합해서 주고받는 것임

  • 탱글드에서는 깃 서버를 knots라고 부름
  • 어떤 서버에 있는 저장소든 협업할 수 있고, 서버를 건너 포크하는 것도 가능하다고 함
  • 내 서버에 저장소를 푸시한 뒤, 완전히 다른 서버에 있는 프로젝트에 풀 리퀘스트를 여는 흐름도 목표로 함

sequenceDiagram
    participant 개발자
    participant 내_깃_서버
    participant 다른_깃_서버
    participant 에이티_프로토콜
    개발자->>내_깃_서버: 코드 푸시
    개발자->>다른_깃_서버: 풀 리퀘스트 생성
    다른_깃_서버->>에이티_프로토콜: 협업 이벤트 발행
    에이티_프로토콜->>내_깃_서버: 이벤트 전달
    내_깃_서버->>개발자: 리뷰와 상태 동기화

• 여기서 에이티 프로토콜은 코드를 옮기는 역할이 아니라, 코드 주변 이벤트를 인증된 방식으로 전달하는 역할에 가까움
  • 이슈, 풀 리퀘스트 같은 협업 이벤트를 공유함
  • 팔로우, 별표, 곧 추가될 보증 같은 소셜 요소도 다룸
  • 협업자 초대와 에스에스에이치 공개 키 공유에도 쓰인다고 함

• 글의 결론은 오픈소스가 깃허브 같은 단일 문화권에서 벗어나야 하지만, 협업이 다시 불편하고 재미없는 방식으로 돌아가면 안 된다는 것임
  • 이메일 패치 흐름처럼 분산되어 있으면서도, 깃허브처럼 소셜하고 쓰기 쉬운 경험을 만들자는 주장임
  • 그래서 이 글은 단순한 깃허브 비판보다 '분산형 협업 UX를 어떻게 만들 것인가'에 더 가까움

기술 맥락

• 깃은 원래 분산 버전 관리 시스템이라 저장소 복제와 히스토리 이동은 잘해요. 그런데 이슈, 리뷰, 풀 리퀘스트, 권한 초대 같은 협업 데이터는 깃 안에 자연스럽게 들어가지 않거든요. 그래서 깃허브 같은 포지가 그 빈자리를 웹 서비스로 채웠어요.

• 탱글드가 고른 방식은 코드는 계속 깃에 맡기고, 협업 이벤트만 에이티 프로토콜로 흘려보내는 거예요. 이렇게 하면 기존 깃 생태계를 버리지 않으면서도 서버 간 풀 리퀘스트나 포크 같은 동작을 만들 수 있어요.

• 포인트는 '저장소를 어디에 두느냐'와 '협업을 어디서 하느냐'를 분리하는 데 있어요. 내 서버에 코드를 올리고도 다른 서버의 프로젝트에 변경을 제안할 수 있다면, 깃허브 계정과 깃허브 저장소에 모든 관계가 묶이는 구조가 약해져요.

• 물론 이런 모델은 프로토콜만 있다고 끝나지 않아요. 권한, 공개 키, 리뷰 상태, 알림, 소셜 신뢰를 여러 서버가 일관되게 다뤄야 하니까요. 탱글드가 에이티 프로토콜을 쓰겠다는 건 이 복잡한 이벤트 동기화 문제를 기존 분산 소셜 인프라 위에 얹어보겠다는 선택이에요.