# 포지의 연합이 필요하다 > Clean Markdown view of GeekNews topic #29030. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29030](https://news.hada.io/topic?id=29030) - GeekNews Markdown: [https://news.hada.io/topic/29030.md](https://news.hada.io/topic/29030.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-30T10:15:57+09:00 - Updated: 2026-04-30T10:15:57+09:00 - Original source: [blog.tangled.org](https://blog.tangled.org/federation/) - Points: 1 - Comments: 1 ## Topic Body - **오픈소스 협업**은 단일 제공자에 크게 의존하는 구조보다, 코드 전송과 커뮤니케이션을 나눠 맡는 **분산형 프로토콜** 조합이 더 바람직하다는 문제의식 위에 놓여 있음 - 코드 협업은 원래 **git과 이메일** 조합으로 이뤄졌고, 이후 **git과 GitHub 웹사이트** 조합으로 옮겨갔으며, ForgeFed는 git과 ActivityPub, Tangled는 git과 AT protocol 조합으로 이어짐 - Tangled는 git 서버 사이 이벤트를 연합하는 구조로, 각 서버를 **knot**이라 부르며 서버가 달라도 저장소 협업, **서버 간 fork**, 다른 서버에 있는 저장소로의 pull request를 지원함 - 코드 주변의 **Authenticated Transfer**에는 AT를 쓰고, issues, pull requests, 이벤트 타임라인, follows, stars를 함께 다루며 협업자 초대와 **SSH 공개키** 공유에도 활용함 - 직접 cgit 인스턴스를 운영하고 이메일로 패치를 보내는 흐름과 닮아 있으면서도, **GitHub 모노컬처**에서 벗어나 협업의 사회성과 재미를 유지하려는 방향이 드러남 --- ### 포지 연합 필요성 - **오픈소스 협업**의 상당 부분을 단일 제공자에 의존하는 구조는 바람직하지 않으며, 중앙집중형 시스템보다 **분산형 프로토콜**이 더 오래 버틴다는 관점을 바탕에 둠 - 코드 협업은 항상 두 가지 프로토콜을 함께 써 왔고, 하나는 **코드 전송**, 다른 하나는 **커뮤니케이션**을 맡아 왔음 - 초기 흐름은 git과 이메일 조합이었음 - 이후에는 git과 GitHub 웹사이트 조합으로 바뀜 - ForgeFed는 git과 [ActivityPub](https://forgefed.org/blog/actor-programming/) 조합 가능성을 두고 있음 - Tangled는 git과 [AT protocol](https://atproto.com/) 조합으로 구축 중임 - Tangled는 git 서버들 사이의 이벤트를 연합하며, 각 서버를 **knot**이라고 부름 - 어느 서버에 있든 저장소 협업 가능함 - 서버를 넘는 fork 지원함 - 자기 서버의 저장소에 push한 뒤, 완전히 다른 서버에 호스팅된 저장소로 pull request를 열 수 있음 - 이 방식은 직접 **cgit 인스턴스**를 운영하면서 이메일로 패치를 보내는 흐름과 여러 면에서 닮아 있음 ### Tangled가 맡는 역할 - Tangled는 코드 주변 이벤트의 **Authenticated Transfer**에 AT를 사용함 - issues와 pull requests 같은 이벤트 전달에 쓰임 - 이벤트 타임라인, follows, stars 같은 소셜 기능도 함께 다룸 - vouches도 곧 추가될 예정임 - AT는 협업자 초대와 **SSH 공개키** 공유에도 쓰이며, 그 밖의 부분은 기존 git을 그대로 사용함 - 오픈소스는 GitHub 같은 **모노컬처**에서 벗어날 필요가 있으며, 동시에 코드 협업의 사회성과 재미도 유지해야 함 - [tangled alpha](https://tangled.org/) - [docs](https://docs.tangled.org/) - [source](https://tangled.org/tangled.org/core) - [discord](https://chat.tangled.org/) - [bluesky](https://bsky.app/profile/tangled.org) - [twitter (x)](https://x.com/tangled_org) - [feed](https://blog.tangled.org/feed.xml) ## Comments ### Comment 56589 - Author: neo - Created: 2026-04-30T10:15:59+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47948603) - 이게 **Mastodon**보다 얼마나 더 나아질지 잘 모르겠음 - **ATproto**는 여러 서버가 서로 메시지 주고받는 구조가 아니라, 오히려 **RSS**에 가까움 앱과 무관한 호스팅 계층이 있고 누구나 자기 데이터를 호스팅할 수 있으며, 그 위에서 앱들이 모든 호스트의 데이터를 모아 보여줌 그래서 Mastodon식 **defederation** 개념 자체가 없음 더 궁금하면 [https://overreacted.io/open-social/]()와 [https://overreacted.io/a-social-filesystem/]()를 보면 됨 - **ATproto**는 Mastodon과 연합 방식이 꽤 다르고, 여기엔 **instance**라는 개념이 없음 계정은 PDS에 호스팅되고 기록도 거기로 가지만, 앱에서 보이는 내용은 여러 PDS의 데이터를 모은 **AppView**가 제공함 그래서 어느 PDS에 있든 앱 경험은 중앙집중형 서비스처럼 느껴지고, AppView도 여러 개 둘 수 있으며 직접 호스팅도 가능함 - **AppView**는 fediverse와 꽤 다르고, 명시적 federation보다 **shared relay**에 의존함 지금처럼 사실상 전역 발견성이 생기는 비용은 좀 고민되지만, 그렇다고 이걸 그냥 또 다른 Mastodon이라고 보긴 어려움 - 왜 꼭 한쪽 편을 들거나 **정답인 편**을 골라야 하는지 모르겠음 그냥 입장을 안 정하거나, 스스로 맞다고 생각하는 쪽으로 가면 되는 것 아닌가 싶음 - 좀 과장하긴 했지만, 설령 그렇다 해도 지금처럼 **GitHub**와 **GitLab**에 의존해야만 존재감이 생기는 구조보다는 훨씬 나아 보임 - **atprotocol** 쪽에서 꽤 활발히 쓰는 편이라 편향됐을 수는 있지만, **Tangled**는 정말 만족스럽게 쓰고 있음 GitHub 대체제로 내가 원하던 모습에 제일 가깝고, 기능은 더 단순하지만 지난 1년 동안 개인 오픈소스 프로젝트의 주력 social/git 서비스였음 내 계정은 [https://tangled.org/did:plc:rnpkyqnmsw4ipey6eotbdnnf]()임 **Bluesky**에서 알던 소셜 그래프가 이어져서 커밋, PR, 이슈 뒤에 있는 사람을 감각적으로 연결해 볼 수 있는 점이 좋고, 로그인도 다른 atproto 서비스와 같아서 편함 최근엔 정적 사이트 내장 지원도 들어가서 클라이언트 사이드 웹사이트나 간단한 index.html을 repo에서 바로 호스팅하기 좋음 **Spindles**가 빌드 시스템/액션 역할을 하는데, 내가 Nix 팬은 아니어도 필요한 용도엔 꽤 잘 맞았음 **open API**도 좋아서 atproto 기반 표준을 활용해 쉽게 정보 렌더링을 만들 수 있었고, 봇도 만들고 npmx.dev 기능도 몇 개 붙였음 직접 **knot**(git 서버)와 runner(Spindles)를 운영할 수도 있고 호스팅된 걸 써도 되는데, 핵심은 소셜 기능이 분리돼 있어서 git 서버가 따로 있어도 이슈나 PR 대화는 공용 소셜 레이어에서 이어진다는 점임 완벽하진 않고 네브바에 붙은 **alpha** 표시가 괜히 있는 건 아니지만, 오픈소스 작업용으로는 계속 쓰게 될 가능성이 큼 - **atproto**가 **Bluesky**의 존재감 부족에 끌려갈까 봐 좀 걱정됨 그게 타당한 불안인지는 아직 잘 모르겠음 - 댓글 분위기는 꽤 부정적이지만, 나도 **VC 자금**을 경계하는 편이면서도 이 영역의 경쟁은 장려해야 한다고 봄 지금 시점에 이런 걸 **bootstrap**으로 시작하는 건 매우 어렵거나 사실상 불가능해 보이고, 어제 HN 상단에 있던 GitHub 비판 글들과 타이밍을 잘 맞춘 것도 맞지만 그래도 이런 시도 자체는 응원하고 싶음 의미 있는 규모로 자리 잡았으면 좋겠음 - 내가 보기에 이건 단순한 부정론이 아니라 **실제 우려**임 제목만 봤을 땐 기대했지만 VC 자금이 들어갔다는 걸 아는 순간 바로 고려 대상에서 빠졌음 돈도 못 버는 내 애정 프로젝트를 플랫폼에 올릴 거라면, 5년쯤 뒤에 **rug pull**이 나올 가능성이 낮은 곳을 고르고 싶음 VC 프로젝트는 투자금 회수를 해야 하니 결국 어떤 식으로든 rug pull이 올 거라고 봄 그래서 지금은 돈을 내는 고객으로 쓰거나, 조합원처럼 회비를 내고 의사결정에 투표권이 있는 서비스 쪽을 선호함 - **VC**가 들어간 프로젝트는 결국 rug pull, 광고, 프라이버시 침해, 혹은 억지스러운 유료 기능 강화로 가기 쉬움 그래서 사용자 입장에선 그 가능성을 미리 알아야 함 곧 다가올 현실이 그런데도 지나치게 이상주의를 내세우는 서비스는 별로 좋아하지 않음 차라리 서비스 요금을 받거나, 정말 이상을 추구한다면 **non-profit**으로 시작하거나, 최소한 수익화 계획은 분명히 밝혀야 함 - **bootstrap**이 왜 불가능하다고 보는지 잘 모르겠음 어렵다는 건 당연하지만, 특히 federation을 지향한다면 같은 비용이나 더 큰 비용이 아니라 오히려 더 저렴한 인프라로도 만들 수 있어야 하는 것 아닌가 싶음 - **atproto 데이터 모델**이 궁금하면 [https://overreacted.io/a-social-filesystem/]()에 입문용 글을 써뒀음 좀 길긴 하지만 전체 그림을 꽤 선명하게 잡아줌 - 과소평가에 가까움 지금까지 본 **ATProto** 입문 글 중에 제일 좋았음 혹시 이 글들을 한곳에 모아둔 태그나 목록이 따로 있는지 궁금함 - 내가 보기에 필요한 건 **forge federation**이 아니라 더 풍부한 **git repo** 자체임 **Fossil**은 티켓, 포럼, 위키를 저장소 일부로 통합해서 거의 90%쯤 와 있고, clone하면 그것들까지 같이 내려받아 오프라인에서도 볼 수 있음 비행기 안에서도 답글을 써둘 수 있고, 권한만 맞으면 바로 혹은 나중에 연결이 복구됐을 때 동기화할 수 있음 다만 특정 아티팩트 종류를 VCS에 하드코딩하는 대신, repo 안에 앱을 담고 그 앱이 어떤 아티팩트를 허용할지, 어떤 규칙을 따를지, 누가 언제 업로드/다운로드할 수 있을지 정하게 하는 방향이 더 좋아 보임 forge는 그 정책을 실행하고 웹 사용자에게 원하는 방식으로 렌더링만 해주면 됨 이렇게 되면 다른 forge로 옮기는 일도 결국 repo를 push하는 정도로 끝남 - 이거 정말 고마움 요즘 티켓 시스템이나 에이전트 같은 걸 git repo 안의 **flat files**로 만들고 있었는데, 이제 그걸 repo 관리 자체까지 확장해야겠다는 생각이 듦 엄청 좋아질 듯함 - 내가 느끼는 **federated solution**의 핵심 문제는 결국 **cold start**임 기존 대형 서버에 들어가면 벗어나려던 바로 그 중앙집중 문제를 다시 껴안게 되지만, 대신 처음부터 큰 네트워크는 얻음 반대로 직접 서버를 열면 네트워크는 0, 발견성도 0, 피드는 비어 있고, 다른 사이트들이 연합해주거나 1인 서버라는 이유로 막지 않게 설득해야 함 나만 이렇게 느끼는 건지, 아니면 federation을 잘못 이해한 건지 모르겠음 어쩌면 이건 그냥 **Mastodon** 특유의 문제일 수도 있음 - 그래서 Tangled는 **ActivityPub** 대신 **ATproto**를 택한 것 같음 개별 서버들을 중앙 **AppView**들이 한데 모아서, 중앙집중형 네트워크처럼 일관된 단일 뷰를 주도록 설계됐기 때문임 AppView는 누구나 호스팅할 수 있음 - 이건 **Mastodon** 쪽 성격이 더 강함 **atproto**는 각 서버가 반쯤 고립된 구역처럼 동작하지 않음 분산 시스템 관점 설명은 [https://atproto.com/articles/atproto-for-distsys-engineers]()가 잘 풀어줌 - 이득은 중간 지점에 있다고 봄 대형 서버가 moderation, 정책, 콘텐츠, 기술 문제로 수상해지면 비교적 쉽게 빠져나와 다른 꽤 큰 서버를 키우거나 옮길 수 있음 처음부터 어느 정도 평판과 규모가 있는 피난처를 만들 수 있다는 뜻임 이미 **GitLab**, **Codeberg**, freedesktop, Fedora, Debian 같은 대안 forge들이 있으니, 프로젝트의 가시성과 발견성만 유지된다면 충분히 안전한 대피처가 될 수 있음 - 나도 지금까지는 딱 그렇게 느껴서 federated 서비스들을 멀리했음 그런데 며칠 전 이 프로젝트를 보고는 이건 진짜 될 수도 있겠다고 생각했음 대상 사용자가 **self-hosting**에 익숙한 층과 꽤 많이 겹치기 때문임 내 전체 네트워크가 다 올 필요는 없고, 실제로 여기 올 가능성이 높은 그 하위 집단만 있어도 충분히 유용함 - 여기서 매력적인 건 **self-host**도 가능하고, 큰 제공자들 사이를 **migration**하는 것도 가능하다는 점임 프런트엔드 서버 비용은 아주 낮을 테니 거의 영구 운영도 가능해 보이고, 실제 데이터는 다른 호스트들이 공급함 - **Tangled**가 VC 지원을 받는다는 점은 안정감보다 **무조건 성장해야 한다**는 압박으로 들림 매력을 잘 모르겠음 설령 federated라 해도 개발이 멈추면 버그를 고치고 유지보수할 사람이 누군가 싶음 - Tangled는 전부 공개적으로 개발 중이고 [https://tangled.org/tangled.org/core](), 목표도 **permanent software**임 즉, 완전히 재현 가능하고 최소 비용으로 전부 self-host 가능하게 만들려는 것임 VC 자금은 목적이 아니라 수단일 뿐이고, 유럽에 있는 인도인 창업자 둘 입장에선 보조금은 실제로 나오기까지 4~12개월 이상 걸려 거의 비현실적이었다고 함 팀을 꾸리고 인프라를 세우고 개발을 가속하는 가장 빠른 길이 VC였고, 투자자와 목표 정렬도 강하게 맞췄으며 그 파트너를 찾는 데 6개월 넘게 썼다고 함 - 그걸 쓰는 사람들이 유지보수하면 됨 **Tangled**는 구조적으로 흥미로운 선택이 많지만 코드 자체는 비교적 단순하고, 직접 들여다본 바로도 유지보수 난이도는 높지 않아 보였음 대부분은 느슨하게 연결된 **Go modules**이고, 거기에 정적 HTML+CSS, 그리고 약간의 TypeScript와 오케스트레이션용 Nix가 얹힌 정도임 기억이 맞다면 하드웨어 요구량도 아주 작아서 지금 규모라면 개인 한 명이 직접 호스팅할 수 있음 실제 인프라 부담의 큰 부분은 사용자들의 **knots**, **spindles**, **PDS**와 atproto 전체가 맡음 - 지금 이 댓글도 **VC 자금**을 받은 뉴스 집계 사이트에 쓰고 있는데, 그걸 생각하면 꼭 그렇게 단정할 일인가 싶음 - VC는 괜찮아도 **YC** 자금만 아니면 된다고 봄 - 이런 VC가 들어오면 두 가지를 묻게 됨 왜 꼭 **VC**가 필요한가, 왜 Ladybird처럼 기업 후원을 받지 않는가 그리고 투자자들이 **10배 수익**을 기대하는데, 결국 나중에 enshittification될 개발자 도구에 왜 시간을 써야 하는가 - 표준이 4개나 있어서 하나로 통일하자며 새 표준을 만들면 결국 **표준이 5개**가 되는 농담이 떠오름 농담은 그렇다 쳐도, 왜 **ActivityPub**으로는 부족한지 더 강한 근거가 필요하다고 봄 탈중앙 커뮤니케이션 문제를 또 다른 방식으로 다시 풀려 하기 전에 말임 - **ActivityPub**과 **atproto**는 모양 자체가 다름 이걸 맞붙이는 건 이메일이 있는데 왜 웹이 필요하냐고 묻는 것과 비슷함 ActivityPub은 이메일처럼 서버가 받은편지함 역할을 하며 서로 메시지를 주고받는 구조임 반면 atproto는 웹처럼 사용자 저장소가 데이터를 호스팅하고, 앱이 그 저장소들에서 데이터를 모아 보여줌 이런 topology 차이 때문에 성질도 달라져서, atproto에선 사용자 호스팅을 바꿔도 앱 경험이 끊기지 않고, 기존 데이터를 바탕으로 새로운 앱을 누구나 만들 수 있음 ActivityPub은 그런 걸 허용하지 못하고, 결국 호스팅과 앱이 결합된 작은 중앙집중 서비스들이 서로 메시지를 주고받는 형태에 가까움 - 왜 **Tangled**는 자금 조달 전에도 **ATProto** 위에서 제품을 내놓을 수 있었는데, **ForgeFed**는 몇 년째 진척이 더딘지 그 차이도 봐야 한다고 생각함 - 원문에도 링크돼 있지만, 왜 **ActivityPub**이 이 문제에 잘 맞지 않는지는 ForgeFed 작성자들이 직접 [https://forgefed.org/blog/actor-programming/]()에서 설명해 둠 - **Nostr** 위에서 돌아가는 비교적 성숙한 GitHub 대안으로 [https://gitworkshop.dev/]()도 있음 핵심 아이디어는 저장소를 여러 **GRASP** 호환 nostr relay에 올릴 수 있다는 점이고, 서버 하나가 내려가도 다른 곳을 통해 투명하게 동기화 가능함 그래서 신뢰할 만한 서버를 고르면 사실상 100% 가동에 가깝고, 저장소와 활동, 이슈 등도 암호학적으로 서명됨 - 그렇게 성숙하진 않아 보임 이름부터 **git**의 상표 정책을 위반하는 듯함 [https://git-scm.com/about/trademark]() - 내가 틀렸으면 좋겠지만, 그 프로젝트는 **closed source**처럼 보임 - 그 사이트에서 어떤 저장소도 제대로 열 수 없었음 어떤 건 브라우저가 ssh나 https URL을 지원하지 않는다고 하고, 어떤 건 `Failed to load file tree`만 뜨며 무한 로딩됨 그래서 **fairly mature**하다는 평가는 잘 납득되지 않음 - 나는 federation을 강하게 지지하지만, **federation of forges**의 용도는 늘 잘 이해되지 않았음 forge들끼리 대체 무슨 데이터를 교환해야 하는가 Blender용 forge가 왜 Ubuntu용 forge와 연결돼야 하는가 싶음 내가 GitHub에서 얻는 가장 큰 가치는 프로젝트를 옮겨 다닐 수 있는 **단일 로그인**인데, 독립 forge들도 복잡한 forge federation 없이 **social login**만 지원하면 그 가치는 상당 부분 줄 수 있다고 봄 - 사람들이 소프트웨어를 찾을 때는 결국 **GitHub 검색**부터 함 직접 forge를 호스팅하면 Blender 같은 이미 큰 이름이 아닌 이상 아무도 소프트웨어를 못 찾음 그래서 코드가 공허 속으로 사라지지 않게 하려면 최소한 GitHub 미러링은 거의 강제됨 이걸 피하고 더 작은 forge들이 하나의 집합으로 경쟁력을 가지려면, 어느 호스트에 있든 소프트웨어를 찾게 해주는 단일 네트워크가 필요하고 **ForgeFed**가 바로 그걸 노림 초보 기여자에게 매번 전용 forge 로그인을 요구하는 마찰도 줄어드는데, 그건 부차적이지만 연결된 문제이기도 함 - **Git**은 설계상 탈중앙적임 GitHub가 UI, 이슈, PR을 잘 풀어서 초보자도 화면에서 작업하게 만들었을 뿐이고, 그 과정에서 중앙집중화됐음 federation은 Git 철학에 더 가깝지만, 어느 노드가 꺼지면 upstream이 사라지거나 찾을 수조차 없는 수준의 극단적 분산까지 갈 필요는 없음 **Git**은 가용성을 해결하지 못하고, federation은 탈중앙 철학을 유지하면서 그 가용성을 보완할 수 있다고 봄 - 가장 큰 문제는 결국 **discoverability**임 흩어진 서버들 위의 오픈소스 프로젝트를 쉽게 찾을 방법이 필요함 GitHub 프로젝트 검색은 GitHub 안에서만 통함 - 상호운용 가능한 **identity provider**는 분명 유용함 거기에 더해 프로젝트 호스트가 사라지거나 정책을 바꾸거나 정부에 의해 차단될 때도 더 **resilient**해질 수 있음 - 여기서 이점은 데이터가 한곳, 즉 **PDS**에 살고 원하면 self-host할 수 있다는 데 있음 그리고 **AppView**가 여러 PDS의 데이터를 한 화면으로 모아 보여줌 만약 tangled.org가 enshittify되더라도 다른 어떤 AppView에서든 똑같이 이어서 쓸 수 있고, tangled.org 자체가 특권적 위치를 가지지 않음 독립 forge들의 social login도 도움은 되지만, 개인적으로는 관리할 계정이 하나인 편이 더 낫고, **AT protocol** 덕분에 개별 forge가 사라져도 데이터는 다른 AppView를 통해 계속 접근 가능함