--- title: "깃허브 독점에서 벗어나려면 '연합형 포지'가 필요하다는 주장" published: 2026-04-29T14:00:59.000Z canonical: https://jeff.news/article/1963 --- # 깃허브 독점에서 벗어나려면 '연합형 포지'가 필요하다는 주장 탱글드 쪽 글은 오픈소스 협업이 깃허브 같은 단일 플랫폼에 너무 의존하고 있다며, 깃 저장소와 협업 이벤트를 여러 서버가 나눠 갖는 연합형 포지가 필요하다고 주장해. 탱글드는 코드 전송은 기존 깃을 쓰고, 이슈와 풀 리퀘스트 같은 협업 이벤트는 에이티 프로토콜로 주고받는 방식을 제안함. - 탱글드가 던지는 문제의식은 단순함. 전 세계 오픈소스의 대부분이 깃허브 한 곳에 기대는 건 별로 건강하지 않다는 얘기임 - 글에서는 '중앙화된 시스템은 결국 무너진다'고 보고, 오래 버틴 건 이메일, 깃, 아이알시 같은 프로토콜 기반 시스템이었다고 말함 - 깃 자체는 분산형인데, 협업과 커뮤니케이션은 깃허브 웹사이트에 강하게 묶여 있다는 게 핵심 문제임 - 코드 협업은 원래 두 가지가 같이 움직였다는 설명이 깔려 있음. 하나는 코드 전송, 하나는 대화와 리뷰임 - 예전 방식은 `git`으로 코드를 주고받고 이메일로 패치를 논의하는 구조였음 - 깃허브 시대에는 코드 전송은 여전히 `git`이지만, 이슈와 풀 리퀘스트, 리뷰, 소셜 기능은 깃허브 웹사이트가 담당함 - 포지페드 쪽은 `git`과 액티비티펍 조합을 고민하고, 탱글드는 `git`과 에이티 프로토콜 조합을 밀고 있음 - 탱글드의 핵심 아이디어는 여러 깃 서버가 협업 이벤트를 서로 연합해서 주고받는 것임 - 탱글드에서는 깃 서버를 `knots`라고 부름 - 어떤 서버에 있는 저장소든 협업할 수 있고, 서버를 건너 포크하는 것도 가능하다고 함 - 내 서버에 저장소를 푸시한 뒤, 완전히 다른 서버에 있는 프로젝트에 풀 리퀘스트를 여는 흐름도 목표로 함 ```mermaid sequenceDiagram participant 개발자 participant 내_깃_서버 participant 다른_깃_서버 participant 에이티_프로토콜 개발자->>내_깃_서버: 코드 푸시 개발자->>다른_깃_서버: 풀 리퀘스트 생성 다른_깃_서버->>에이티_프로토콜: 협업 이벤트 발행 에이티_프로토콜->>내_깃_서버: 이벤트 전달 내_깃_서버->>개발자: 리뷰와 상태 동기화 ``` - 여기서 에이티 프로토콜은 코드를 옮기는 역할이 아니라, 코드 주변 이벤트를 인증된 방식으로 전달하는 역할에 가까움 - 이슈, 풀 리퀘스트 같은 협업 이벤트를 공유함 - 팔로우, 별표, 곧 추가될 보증 같은 소셜 요소도 다룸 - 협업자 초대와 에스에스에이치 공개 키 공유에도 쓰인다고 함 > [!NOTE] > 탱글드가 깃을 대체하려는 건 아님. 코드 전송은 '그냥 깃'을 쓰고, 깃허브가 독점해온 커뮤니케이션 레이어를 프로토콜로 풀자는 쪽에 가까움. - 글의 결론은 오픈소스가 깃허브 같은 단일 문화권에서 벗어나야 하지만, 협업이 다시 불편하고 재미없는 방식으로 돌아가면 안 된다는 것임 - 이메일 패치 흐름처럼 분산되어 있으면서도, 깃허브처럼 소셜하고 쓰기 쉬운 경험을 만들자는 주장임 - 그래서 이 글은 단순한 깃허브 비판보다 '분산형 협업 UX를 어떻게 만들 것인가'에 더 가까움 --- ## 기술 맥락 - 깃은 원래 분산 버전 관리 시스템이라 저장소 복제와 히스토리 이동은 잘해요. 그런데 이슈, 리뷰, 풀 리퀘스트, 권한 초대 같은 협업 데이터는 깃 안에 자연스럽게 들어가지 않거든요. 그래서 깃허브 같은 포지가 그 빈자리를 웹 서비스로 채웠어요. - 탱글드가 고른 방식은 코드는 계속 깃에 맡기고, 협업 이벤트만 에이티 프로토콜로 흘려보내는 거예요. 이렇게 하면 기존 깃 생태계를 버리지 않으면서도 서버 간 풀 리퀘스트나 포크 같은 동작을 만들 수 있어요. - 포인트는 '저장소를 어디에 두느냐'와 '협업을 어디서 하느냐'를 분리하는 데 있어요. 내 서버에 코드를 올리고도 다른 서버의 프로젝트에 변경을 제안할 수 있다면, 깃허브 계정과 깃허브 저장소에 모든 관계가 묶이는 구조가 약해져요. - 물론 이런 모델은 프로토콜만 있다고 끝나지 않아요. 권한, 공개 키, 리뷰 상태, 알림, 소셜 신뢰를 여러 서버가 일관되게 다뤄야 하니까요. 탱글드가 에이티 프로토콜을 쓰겠다는 건 이 복잡한 이벤트 동기화 문제를 기존 분산 소셜 인프라 위에 얹어보겠다는 선택이에요. ## 핵심 포인트 - 오픈소스 생태계가 깃허브 한 곳에 지나치게 의존하는 구조를 문제로 봄 - 탱글드는 깃 서버를 노트라고 부르고 서버 간 저장소 협업과 포크를 지원하려 함 - 코드 자체는 기존 깃으로 전송하고 이슈, 풀 리퀘스트, 초대, 공개 키 같은 이벤트는 에이티 프로토콜로 처리함 - 과거 이메일 기반 패치 흐름과 깃허브식 소셜 협업의 중간 지점을 노림 ## 인사이트 깃은 이미 분산형인데 협업 UI와 사회적 그래프는 사실상 중앙화됐다는 게 이 글의 포인트야. 깃허브 장애나 정책 변화가 생길 때마다 반복되는 얘기지만, 이번엔 에이티 프로토콜을 붙여 '재미있는 협업'까지 가져가려는 설계라 볼 만함.