TECH 으로 돌아가기
TECH HACKER NEWS 2026.10.31 22:08 7분 읽기 26 READS

GitHub 없이 Git으로 협업할 수 있을까? AT 프로토콜로 만든 연합형 코드 포지 Tangled

GitHub 없이 Git으로 협업할 수 있을까? AT 프로토콜로 만든 연합형 코드 포지 Tangled
SOURCE IMAGE · HACKER NEWS
GitHub 없이 Git으로 협업할 수 있을까? AT 프로토콜로 만든 연합형 코드 포지 Tangled

무슨 일이 있었나요?

Tangled라는 프로젝트가 '연합형 코드 포지(federated code forge)'라는 비전을 담은 글을 공개했어요. 코드 포지는 GitHub나 GitLab처럼 Git 저장소를 호스팅하면서 이슈, 풀 리퀘스트, 코드 리뷰 같은 협업 기능을 제공하는 플랫폼을 통틀어 부르는 말이에요. 대장간(forge)에서 쇠를 두드려 물건을 만들듯 여럿이 코드를 다듬는 곳이라는 뜻이죠.

Tangled가 특이한 건 블루스카이(Bluesky)가 쓰는 AT 프로토콜 위에 만들어졌다는 점이에요. 저장소는 원하는 서버에 두면서도 스타, 팔로우, 이슈, PR 같은 소셜 활동은 하나의 네트워크로 연결하겠다는 거예요.

왜 지금 이런 얘기가 나올까요?

Git은 원래 분산 버전 관리 시스템이에요. 누구나 전체 이력을 복제해서 가질 수 있고, 중앙 서버가 꼭 있어야 하는 것도 아니에요. 그런데 아이러니하게도 협업은 GitHub라는 거대한 중앙 플랫폼으로 몰렸어요. 코드는 분산돼 있는데 이슈와 리뷰 기록, 개발자 평판, CI까지 전부 한 회사 서비스에 묶여 있는 거죠.

최근 몇 년 사이 이 구조가 불편하다는 목소리가 커졌어요. 대형 플랫폼에 장애가 나면 전 세계 개발이 같이 멈추고, AI 학습에 코드가 쓰이는 문제나 정책 변경에 대한 걱정도 계속 나와요. 몇몇 유명 오픈소스 프로젝트는 Codeberg 같은 대안 플랫폼으로 옮겨가기도 했고요. 그렇다고 각자 Gitea나 Forgejo를 따로 띄우면 이번엔 계정이 서버마다 쪼개져요. 다른 서버에 있는 프로젝트에 이슈 하나 남기려 해도 회원가입부터 해야 하죠. 연합형 포지는 이 독립성과 연결성 사이의 딜레마를 풀어보려는 시도예요.

Tangled는 어떻게 동작하나요?

AT 프로토콜부터 간단히 짚고 갈게요. 이 프로토콜에서는 사용자 데이터가 PDS(Personal Data Server)라는 개인 데이터 저장소에 '레코드' 형태로 저장돼요. 내가 쓴 글, 누른 좋아요, 팔로우가 전부 내 PDS에 있는 거죠. 여러 PDS에서 생기는 변경 사항은 파이어호스(firehose)라는 실시간 스트림으로 흘러나오고, 앱뷰(AppView)라는 서비스가 이 스트림을 모아서 우리가 보는 피드와 화면을 만들어줘요. 데이터는 내가 들고 다니고, 서비스는 그 위에 얹히는 구조예요.

Tangled는 이 구조를 코드 협업에 가져왔어요. 이슈, 댓글, 스타, PR 같은 소셜 데이터는 각자의 PDS에 레코드로 쌓이고, 실제 Git 저장소는 노트(knot)라고 부르는 가벼운 Git 서버에 올라가요. 노트는 Tangled가 운영하는 걸 써도 되고 개인이나 회사가 직접 띄워도 돼요. CI를 돌리는 러너(스핀들, spindle)도 따로 떼어서 직접 운영할 수 있게 설계돼 있어요. 저장소 호스팅, 소셜 데이터, CI가 각각 다른 곳에 있어도 사용자에게는 하나의 포지처럼 보이게 만드는 게 핵심이에요.

계정은 DID라는 분산 식별자 하나로 묶여요. 그래서 저장소를 어느 노트에 두든 같은 프로필로 활동할 수 있어요. 블루스카이 계정이 있으면 그걸로 바로 로그인할 수 있다는 것도 진입 장벽을 낮춰주는 부분이에요.

업계 맥락: 다른 시도들과 뭐가 다를까

탈중앙 코드 협업 시도는 전에도 있었어요. ForgeFed는 마스토돈이 쓰는 ActivityPub를 확장해서 포지끼리 연합하려는 표준이에요. Forgejo가 오랫동안 구현을 진행하고 있지만 일상적으로 쓰기엔 아직 갈 길이 남아 있어요. Radicle은 아예 서버 없이 P2P 가십 프로토콜로 저장소와 협업 데이터를 퍼뜨리는 방식을 택했고, SourceHut은 리눅스 커널처럼 이메일로 패치를 주고받는 워크플로를 고수하고 있죠.

ActivityPub 방식은 서버끼리 메시지를 주고받는 이메일 같은 모델이에요. 그래서 서버가 사라지면 그 서버에 있던 데이터와 계정도 같이 묶여 사라지는 한계가 있어요. AT 프로토콜은 데이터가 사용자 단위로 존재하고, 네트워크 전체를 모아 보여주는 앱뷰가 따로 있어요. 덕분에 전체 검색이나 탐색처럼 중앙 플랫폼이 주던 편리함을 비교적 쉽게 따라 할 수 있어요. 대신 앱뷰를 운영하는 쪽에 의존하게 된다는 비판도 있고요. 정리하면 Tangled는 Radicle보다는 덜 급진적이고, ForgeFed보다는 GitHub를 쓸 때의 경험에 더 가까운 위치예요.

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

국내 회사들은 보안 때문에 사내에 GitLab이나 Gitea를 직접 운영하는 경우가 많죠. 그러다 보니 사내 저장소와 외부 오픈소스 활동이 완전히 따로 노는 게 늘 아쉬웠어요. 저장소는 우리 서버에 두고 아이덴티티와 협업 기록만 외부와 이어지는 모델은 길게 보면 이 고민에 대한 하나의 답이 될 수 있어요. 회사 메인 저장소를 옮길 단계는 아직 아니지만, 개인 사이드 프로젝트를 올려보거나 노트를 직접 띄워보면서 구조를 체험해 보기엔 충분해요. 소셜 서비스를 만드는 개발자라면 AT 프로토콜 자체도 꼭 공부해 둘 만한 설계예요.

마무리

한 줄 정리: Tangled는 'Git은 분산돼 있는데 협업은 왜 중앙에 몰려 있지?'라는 질문에, AT 프로토콜로 저장소와 소셜 데이터를 분리해서 답하려는 시도예요.

여러분이 GitHub를 떠나려면 어떤 조건이 갖춰져야 할까요? 네트워크 효과, CI, 검색 중에 가장 포기하기 어려운 건 뭔가요?


🔗 출처: Hacker News

SOURCE · HACKER NEWS
원문 전체 보기 → https://tangled.org/blog/forge/
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기 →
처리 중...