지난 20년간 코드 포지(forge)는 프로젝트가 살아가는 터전이었다. 코드가 호스팅되고, 변경이 리뷰되며, 기여자들이 서로를 만나는 곳. 다만 이 편리함은 중앙화라는 대가를 전제로 했다. 가동 시간, 기능 제공, 그리고 코드의 관리 책임을 모두 특정 사업자에게 맡기는 구조다. 반면 오랜 세월 살아남은 방식은 이메일이었다. 코드는 Git으로 옮기고, 그에 관한 논의는 개방형 프로토콜인 이메일로 주고받는 조합이다. 다만 이쪽은 사용성을 희생한다. 탱글드(Tangled)는 개방형 프로토콜의 지속성과 제대로 된 포지의 편의성을 동시에 취하겠다는 목표를 내걸고, 이번 릴리스에서 아키텍처 전반을 다시 짰다.
탱글드는 스스로를 '최초의 진정한 연합형 코드 포지'로 규정한다. 자신의 서버에 코드를 호스팅하면서도 다른 사람들과 매끄럽게 협업할 수 있다는 것이 핵심이다. 접근 방식은 실용적이다. Git 호스팅이나 CI 러너처럼 원하는 부분만 자체 호스팅할 수도 있고, API 서버와 UI까지 전부 직접 운영할 수도 있다. 어느 쪽을 택하든 다른 참여자들과는 계속 소통할 수 있다. AT 프로토콜 위에 구축된 덕분에 자체 확장 기능을 만들거나 파이어호스(firehose)를 구독하는 일도 가능하다. 실제로 클라우드플레어 워커스에서 돌아가며 Artifacts를 Git 저장소로 쓰는 커스텀 knot나, mitchellh.com/tack 같은 커스텀 spindle 사례가 소개된다.
모놀리스에서 엣지 분산 구조로
이전까지 탱글드의 웹 UI와 백엔드는 appview라 불리는 하나의 Go 모놀리스였다. 이 서비스가 AT 프로토콜 인덱싱, 캐싱, 프로토콜 외부 데이터, 그리고 html/template과 htmx를 쓴 UI 렌더링까지 도맡았고, 스웨덴에 있는 중간급 서버 한 대의 단일 SQLite 데이터베이스 위에서 돌아갔다. 스웨덴에서 50~100ms 거리에 있는 사용자에게는 쾌적했지만, 대다수 사용자는 그렇지 않았다. 재설계의 결과물은 두 갈래다. 하나는 엣지에 배포된 Svelte 기반의 독립 프런트엔드 앱이고, 다른 하나는 이를 채워주는 신규 인덱서 'bobbin'이다. Rust로 작성된 bobbin은 디스크를 쓰지 않는 완전 인메모리 서비스로, 11개 이상 지역에 전 세계적으로 배포됐다. 다만 bobbin은 읽기 전용이며 AT 프로토콜 데이터만 다룬다는 점이 중요한 제약이다.
이슈와 PR이 코드 곁으로 옮겨간 이유
읽기와 AT 프로토콜 데이터 외의 나머지 기능은 별도의 지원 서비스로 분리됐다. 데이터 모델부터 새 렉시콘(lexicon) 체계로 바뀌어, 기존 sh.tangled. 레코드가 org.tangled. 아래로 옮겨갔다. 두 번째 knot 서버 구현인 knot2 역시 Rust로 다시 작성됐는데, 완전 커스텀 Git 서버와 SSH 서버를 하나의 바이너리에 함께 담았다. 더 눈에 띄는 변화는 데이터의 위치다. 이슈, 풀 리퀘스트, 댓글, 반응, 레이블이 이제 코드 바로 옆, 즉 knot에 '협업 객체(COB)' 형태로 저장된다. COB는 저장소 안의 Git 객체들이 사슬처럼 이어진 것이며, 기여자 목록과 knot 멤버, 차단 목록도 같은 방식으로 보관된다. 이로써 knot은 전체 이력을 포함한 서명 레코드를 보유하고 표준 AT 프로토콜 파이어호스로 동기화한다는 점에서 PDS와 상당히 비슷하게 동작한다. 프로젝트의 이슈와 PR도 코드만큼이나 그 프로젝트의 일부이니, 어디에 호스팅하든 코드와 함께 머물러야 이식성이 극대화된다는 논리다.
여기서 자연스럽게 떠오르는 의문이 있다. knot이 내 이슈와 댓글을 대신 기록한다면, 내 이름으로 없는 말을 적어 넣는 것을 무엇이 막는가. 답은 어테스테이션(attestation)이다. knot에서 레코드를 만들거나 수정할 때마다 웹 앱이 사용자 본인의 PDS에 org.tangled.graph.attestation 레코드를 함께 기록하고, 이 레코드가 해당 버전과 그 뒤의 COB 변경을 정확히 가리킨다. 양방향 검증인 셈이다. 다만 이 변경의 대가로 자체 호스팅 운영자는 업그레이드 가이드를 따라 knot을 v1.20.0으로 올려야 한다.
조직 계정과 PR 흐름의 변화
이번 릴리스에는 조직(Organization) 계정도 추가됐다. 탱글드의 조직은 자체 DID와 핸들을 가진 실제 AT 프로토콜 계정으로, Tranquil PDS 인스턴스에 호스팅된다. 비밀번호가 없는 위임 계정이며, New Organization 페이지에서 생성하면 본인이 소유자인 .tngl.sh 핸들을 받는다. 소유자는 멤버를 초대할 수 있고, 조직에 속한 누구나 저장소를 만들거나 포크할 때 조직 명의로 행동할 수 있다. 다른 계정처럼 핸들을 자신이 소유한 도메인으로 교체하는 것도 가능하다. PR 흐름도 전면 개편됐다. Jujutsu를 쓰든 순수 Git을 쓰든 스택형 PR을 제출하고 리뷰할 수 있게 됐고, Git 사용자는 버전 간(이전 명칭 '라운드') 인터디프를, JJ 사용자는 개별 변경 단위의 인터디프까지 볼 수 있다.
실무자 입장에서 탱글드의 베팅은 분명하다. 개방형 프로토콜과 개발자 주권에 걸고, 인프라를 소유하면 포지를 원하는 대로 뜯어고치고 확장할 수 있다는 것이다. 설계 단계부터 해킹 가능성을 염두에 둔 덕에 에이전트 친화적이라는 점도 강조된다. 다만 현 시점에서는 가늠해둘 한계도 있다. 이번 공개는 몇 주에 걸쳐 단계적으로 진행되며, 비공개 저장소, CLI, 여러 언어용 SDK, 에이전트용 스킬은 아직 예고 단계다. 자체 호스팅 환경에서는 knot 업그레이드가 선행돼야 하고, 기존에 일반 계정을 조직처럼 써온 경우의 이전 수단도 준비 중이라고만 안내돼 있다. 연합형 포지라는 방향성과 실제 도구 성숙도 사이의 간극을 지켜보며 도입을 판단할 필요가 있다.