Tangled - atproto 기반 Git 협업 플랫폼

 (blog.tangled.org)
3P by GN⁺ | ★ favorite | 댓글 2개
  • Tangled는 AT Protocol 기반의 소셜 기능을 갖춘 Git 협업 플랫폼으로, 개발자가 코드에 대한 완전한 소유권을 유지하면서도 오픈소스 커뮤니티가 자율적으로 운영할 수 있도록 설계됨
  • 기존의 ActivityPub(Forgejo) 중심의 연합형 모델과 Radicle의 완전 P2P 모델의 장점을 결합한 분산형 코드 협업 구조를 채택
  • 핵심 개념인 ‘Knot’ 은 경량의 헤드리스 Git 서버로, 개인의 셀프호스팅 또는 커뮤니티 단위의 멀티테넌트 환경 모두 지원함
  • App View(tangled.sh) 는 네트워크 전역의 리포지터리를 통합 뷰로 제공해, 서로 다른 Knot에 있는 저장소를 원활하게 탐색·복제·기여할 수 있게 함
  • 현재 베타 단계로, 데이터 소유권·낮은 진입장벽·사용자 경험 보존을 핵심 원칙으로 삼으며, 향후 완전 공개형 분산 Git 생태계 구축을 지향

Tangled 개요

  • Tangled는 개발자가 코드와 정체성의 소유권을 유지하면서 사회적 상호작용이 가능한 Git 협업 환경을 제공하는 신규 플랫폼
  • AT Protocol을 기반으로 하여, 탈중앙화된 소셜 앱 아키텍처를 Git 협업에 적용함
  • 목표는 코드 협업을 개방적이고 즐거운 과정으로 되돌리는 것

분산 모델과 AT Protocol

  • 기존 분산형 코드 협업 모델에는 다음과 같은 접근이 있음
    • Forgejo(ActivityPub): 서버 간 연합(federation)을 통한 협업
    • Radicle: 완전한 P2P(peer-to-peer) 구조
  • Tangled는 두 모델의 장점을 결합하여, 중앙 신원 관리가 가능한 atproto를 채택함
  • 이를 통해 사용자는 분산 네트워크 내에서도 일관된 ID와 인증 구조를 유지할 수 있음

Knot 구조

  • Knot은 Tangled의 핵심 구성요소로, 사용자가 직접 Git 리포지터리를 호스팅할 수 있게 하는 경량 서버임
    • 싱글 또는 멀티 테넌트 구성을 모두 지원함
    • Raspberry Pi 등 소형 장비에서도 셀프호스팅 가능함
  • Tangled는 기본적으로 무료 관리형 Knot 서비스를 제공함
  • 이러한 구조 덕분에 사용자 개인 서버와 커뮤니티 서버가 자연스럽게 연결되는 분산 Git 네트워크가 형성됨

App View와 통합 네트워크

  • tangled.sh에서 제공되는 App View는 전체 네트워크의 리포지터리를 하나의 통합 뷰로 보여주는 역할을 함
  • 사용자는 다른 Knot에 위치한 리포지터리라도 복제(clone) 및 기여(contribute) 를 손쉽게 수행 가능함
  • 이러한 설계는 Git의 기존 워크플로를 그대로 유지하면서도 분산형 환경의 장벽을 제거함

개발 원칙

  • Tangled 팀은 개발 방향성을 위해 다음 세 가지 원칙을 설정함
    • 1. 데이터 소유권 — 모든 사용자가 자신이 만든 코드와 메타데이터를 직접 소유
    • 2. 낮은 진입장벽 — 누구나 쉽게 참여 가능하도록 단순한 구조와 인터페이스 제공
    • 3. 사용자 경험의 일관성 — 분산 구조임에도 불구하고 중앙형 서비스 수준의 UX 보장
  • 이 원칙은 Tangled의 기술적 선택과 UI/UX 설계 전반에 반영됨

접근 및 커뮤니티

  • 초기에는 초대 기반 접근(invite-only) 으로 운영되었으며, 개발자들은 #tangled IRC 채널(libera.chat)을 통해 참여할 수 있었음
  • 현재는 공개 로그인 오픈 상태로, 누구나 tangled.sh/login에서 이용 가능함
  • Tangled는 아직 초기 단계이지만, 내부적으로 자체 사용(dogfooding)을 통해 기능을 검증하며 성장 중임

결론

  • Tangled는 Git 협업을 소셜 네트워크처럼 연결된 경험으로 확장하려는 시도임
  • 자율성과 접근성, 그리고 즐거운 개발 문화를 결합한 새로운 분산 Git 플랫폼 생태계로 주목받고 있음

함께 보면 좋은 글 β

lamanus   [-]

공식 컨테이너가 없어서 초기 설정이 좀 번거롭더군요.

답변달기
GN⁺   [-]
Hacker News 의견
  • Tangled의 공동 창업자로서 최근 OAuth 라이브러리를 교체하면서 신규 사용자가 기본 knot 및 spindle(내부 git 호스팅 서버와 CI 러너)에 추가되지 않는 문제가 있었음, 방금 수정 패치를 적용했으니 로그아웃 후 재로그인하면 정상적으로 레포지토리 생성 가능함, 질문 있으면 언제든 답변 가능함
    • 첫 번째 질문은 tngl.sh PDS에서 핸들을 변경하거나 계정을 삭제할 수 있는지에 대한 것임, 두 번째는 AppView를 새로 만들고 운영할 때 필요한 리소스가 궁금함, 예를 들어 Cloudflare Pages처럼 static 웹사이트 폴더를 올리고 그대로 서비스하는 PDS 기반 AppView를 만들면 AppView 운영자가 대량 트래픽 비용을 다 부담해야 하는지 궁금함, 이런 구조에서 운영 부담이 어떻게 되는지 알고 싶음
    • Tangled이 “social-enabled”라는 표현을 썼는데, AT 프로토콜과 관련된 것 같음, Tangled에서 앞으로 더 다양한 소셜 기능들을 계획하고 있는지, 아니면 단순히 AT 프로토콜 지원이라는 의미인지 궁금함
  • 이 프로젝트는 정말 멋지다고 생각함, 기존 코드 포지 서비스의 독점 구조를 해체하려는 시도가 마음에 듦, 내가 이 분야에 관심을 갖는 이유는 코드 포지가 여러 문제를 한 번에 해결하려다 보니 오히려 비효율적이라고 느끼기 때문임, 대부분의 포지는 git 저장소, 웹 뷰어, 협업 도구, CI/CD 파이프라인, 업무 관리 등 다양한 기능을 한 데 묶고 있음, 하지만 이런 기능은 굳이 하나로 묶을 필요가 없다고 생각함, 예를 들어 git 저장소에 직접 접근이 필요 없다면 완전히 정적인 웹 뷰어를 https://pgit.pico.sh처럼 제공하거나, 협업은 patch를 나누어 로컬에서 리뷰하고 관리하는 서버(https://pr.pico.sh)가 따로 있을 수 있음, VPS에 직접 bare git 저장소만 올려도 충분하고 이는 매우 쉬운 일임, Git이 이미 분산 시스템인데 다른 부가 서비스 때문에 중앙 집중화되는 건 안티패턴이라고 생각함
    • “Git이 이미 분산되어 있다”는 말을 사람들이 자주 하지만, 실제로 분산이라는 개념은 애매한 부분이 있음, Git 자체가 분산에 집중하기보다는 보통 마스터-슬레이브 프로토콜 기반(HTTP 등)이라 결국 중앙화가 반복되는 경향이 생김
    • 서비스가 여러 개인 경우 신뢰의 문제가 발생함, 80% 요구를 만족하는 하나의 서비스를 검사하느냐, 각각 별개로 10개의 서비스를 검증하느냐 고민이 필요함, 또한 인프라 규모의 경제, 여러 기능 통합으로 얻는 장점도 무시할 수 없음, 그래서 아직까지도 모놀리식을 선호하는 사람들이 많음, 그만큼 개발자 경험에 대한 트레이드오프를 고민하게 됨
    • VPS에 git 원격 저장소를 세팅하는 건 정말 쉬움, ssh로 접근만 하면 바로 동작함, 사실 핵심 이슈는 'lock-in'(서비스 종속)이라고 생각함, 왜 Github 등은 서비스 제공보다는 lock-in에 집중할까? 그 이면에는 자금 조달과 비즈니스 모델이 있음, 중앙화→lock-in→수익이라는 고리가 여러 서비스에서 계속 등장함, 만약 서비스 자체로 수익을 내는 구조가 없다면 이런 현상이 피할 수 없음을 느꼈음
    • 기술적으로 기능 분리가 불가능한 것은 아니지만, 경제성(각 기능이 별도로 유지될 만큼의 수익 구조가 되지 않음)과, 사용성(사람들이 '배터리 포함'된 편리함을 원함) 문제도 있음, 오픈소스도 마찬가지로 경제성을 무시하는 사례가 많지만 결국 대부분은 한 명의 유지보수가 끝나서 소멸함, 가장 성공적인 오픈소스 프로젝트도 대부분 코퍼레이트 스폰서나 엔지니어들이 후원하는 구조임
    • 분리할 필요는 없지만, 역시 통합되어 있는 게 훨씬 더 편리함
  • 최근 Jujutsu 지원 소식을 JJ Con에서 알게 됨, 관련 내용은 https://blog.tangled.org/stacking에서 확인 가능함
    • 이 서비스는 실제로 stacked PR을 지원함, Github은 수십 년 동안 이걸 못하고 있었음, 만약 사내에서 프라이빗하게 써야 한다면 Tangled 인스턴스가 외부 네트워크와 연결되지 않도록 하는 설정 방법이 불분명해 아쉬움
  • Github은 더는 신뢰할 수 없다고 생각함, oss 스택만이라도 AT 프로토콜이나 다른 오픈 네트워크로 옮기는 것이 대기업, 검열 등의 리스크에서 지키는 좋은 방법이라 생각함, 이런 시도가 반가움
    • 하지만 대부분의 사람들은 직접 서버를 운영하지 않으려 함, 대형 OSS 단체 정도만 감당할 수 있을 것임, 심지어 이메일 외에는 PR도 제공하기 어려운 상황임
  • tangled에 가입한 첫 100명 중 한 명임, stacked patch 방식의 PR 리뷰 로드맵과 기능 개선 속도가 인상적이었고, 커뮤니티의 열기에도 긍정적 에너지를 느낌, 향후 어떻게 발전할지 매우 기대 중임, 이런 방식으로 꾸준히 나아간다면 훨씬 더 좋은 경험과 근본적인 제어, 장기적 지속성도 실현 가능하다고 생각함
  • 보다 분산된 git 협업 방식에 큰 관심을 가지고 있음, 이러한 방식이 퍼지는 데 가장 큰 장애물이 무엇이라고 보는지 궁금함, 서버 운영이나 사설 키 관리, 아니면 결국 네트워크 효과 때문인지 의견이 궁금함
    • 가장 큰 장벽은 스팸, 불법 콘텐츠, 전반적 모더레이션 문제임, PDS가 아무 도메인이나 될 수 있고, 하나의 PDS가 무제한 사용자를 수용할 수 있다는 점에서 신뢰가 무너지는 경험이 많음, 사람들이 git 리포에 ebook이나 TV쇼를 잔뜩 올리면 어떻게 할지, 혹은 프로젝트가 정치적 이슈로 인해 스팸 공격을 받아도 해결책을 고민하게 됨, AppView 개념이 좋은 점은 BlueSky처럼 중앙 모더레이션팀이 일관된 정책을 적용할 수 있다는 것임, 각자 무엇이든 올릴 수는 있겠지만, 결국 프론트엔드에서는 선택적으로 큐레이션이 가능함, 하지만 중앙 모더레이션 decisions도 항상 논란임, 완전히 분산된 네트워크의 부담과 책임을 감수하고 싶지 않은 이유임, AT 프로토콜의 개방성은 Twitter 같은 서비스와 비교해 장점이지만, 그 대신 일상적 관리와 권한 부여가 집중된 체계도 필요함, 개인적으로 지금은 “관대한” radicle seed node(익명 git 업로드 허용) 운영자를 자원하는 사람이 있을지 궁금함
    • Github은 무료이고, 분산화는 비용이 듬
    • Tangled는 직접 서버 운영 없이도 git을 독립적으로 쓸 수 있어서 매우 만족스러움, 가장 큰 단점은 아직 너무 새로운 서비스라는 것임, 아직 대중적인 인지도가 없고, Bsky와 PDS가 무엇을 제공하는지 모르는 사람도 많음, 좀 더 많은 기능과 alternate client들이 있으면 좋겠음, 그럼에도 초기 사용자는 이미 충분히 좋은 경험을 누리고 있다고 생각함, 더 많은 개발자가 이 경험을 만나게 될 날을 기다리는 중임
  • CI 파이프라인 지원이 있어서 반가웠지만, 모양이 GitHub Actions와 비슷한 것 같아 아쉬움, 굳이 단순 순차 실행을 YAML로 할 필요가 없다고 생각함, bash script로도 충분함, 파이프라인 YAML은 프로그램의 흐름이 아니라 의존성(DAG)을 표현할 때 의미 있다고 봄, Buildkite가 이런 점에서 훨씬 뛰어남
  • 내일은 “Spaghetti”라는 이름의 노코드 비즈니스 플랫폼과, “Lock-in”이라는 중요한 데이터 보관 금고 서비스가 나올 예정임
  • 회사에서 부득이하게 GitHub 퍼블릭 org을 써야 하는 상황임, 코드리뷰(CR)는 tangled에서 하고 이후 Github와 동기화해도 될지, jj 툴 리뷰 경험을 그대로 살릴 수 있을지 궁금함
  • 엔터프라이즈/프라이빗 용도로 Tangled를 도입할 수 있는지 궁금함, stacked diff 리뷰 플로우가 기업 업무에 매우 잘 맞아 보임
    • 가능성은 있음, 완전히 airgapped되며 AT와 분리된 Tangled 버전을 논의 중임, 꽤 큰 작업이라 당장 진행하기는 어려움
    • 현재는 별도의 기업용 솔루션이 명확히 존재하는 상태는 아님, 관련 이슈 논의는 https://tangled.org/@tangled.org/core/issues/60에서 볼 수 있음
답변달기