요약
Tangled가 AT Protocol 기반 코드 포지를 전면 개편해 자체 호스팅과 협업을 함께 내세웠습니다.
Tangled 블로그의 출시 글입니다. 글쓴이 아니루드는 GitHub 같은 중앙집중형 코드 포지(코드 저장소와 협업 도구를 묶은 서비스)가 가동률과 기능, 운영 면에서 믿기 어려워졌다고 말합니다. 대안으로 AT Protocol(계정과 데이터를 서비스 간에 옮길 수 있는 개방형 프로토콜)과 깃을 묶은 구조를 제시합니다.
왜 중요한가
- 깃 서버나 CI 실행기만 직접 운영해도 다른 이용자와의 협업이 끊기지 않는다는 점이 새롭습니다.
- 이슈와 PR까지 저장소에 함께 저장하므로 협업 기록도 코드처럼 옮겨 갈 수 있습니다.
핵심 내용
- 이슈, PR, 댓글, 권한 정보 등을 깃 객체의 사슬로 저장소에 넣고, 서명된 기록을 AT Protocol로 동기화합니다.
- 기록을 만들면 작성자의 개인 데이터 서버에도 증명 기록을 남겨, 서버가 내용을 꾸며 내지 않았는지 확인합니다.
- 스웨덴 서버 한 대의 SQLite 구조를 버리고, Rust로 만든 읽기 전용 인덱서를 11개 이상 지역에 배치했습니다.
- 깃 서버인 knot도 Rust로 다시 작성했으며, 자체 호스팅 운영자는 v1.20.0으로 올려야 합니다.
- 조직 계정과 스택형 PR(서로 이어지는 변경을 쌓아 올리는 방식)을 추가했고, 비공개 저장소와 CLI는 곧 내놓습니다.
HN 반응
- 낯선 사람도 계정 하나로 기여할 수 있다는 점을 반기는 쪽과, knot 장애로 플러그인 설치가 막혔다는 경험담이 함께 나왔습니다.
- 일부 이용자는 380만 유로 투자 소식을 들며 GitHub와 경쟁할 사업 모델이 무엇인지 물었습니다.
Tangled가 어떻게 발전하는지 정말 기대하고 있습니다! 제가 진행하는 사이드 프로젝트는 메인 저장소와 CI를 셀프 호스팅 Gitea에서 돌리고, 코드와 릴리스는 GitHub에 미러링해 두었습니다. Gitea에서 빼내 코드, 릴리스, 어쩌면 CI까지 Tangled로 옮기고, GitHub는 발견성, 백업, 네임스페이스 "선점" 용도로만 남겨 둘 생각입니다. Issue를 계속 동기화하려면 git-bug에 Tangled 브리지가 추가되어야 하고, 가능하면 클라이언트를 직접 호스팅하는 방법도 안내되어 있으면 좋겠습니다. 모든 기능을 갖춘 클라이언트일 필요는 없지만, 메인 Tangled appview가 내려갔을 때 웹에서 볼 방법이 아예 없는 상황은 피하고 싶습니다.
한 가지 덧붙이면, 며칠 전 새 컴퓨터에 Neovim을 설정하다가 연합형 Git 호스팅의 첫 "문제"를 겪었습니다. 제가 쓰는 플러그인 하나가 Tangled에 호스팅되어 있는데, 그 뒤의 Knot이 내려가 있었던 모양입니다. 곤란했던 이유는 두 가지입니다.
Tangled 웹사이트만 봐서는 원인이 뒤쪽 knot이라는 걸 알기 어려웠습니다(한동안은 제 쪽 문제인 줄 알았습니다).
Neovim 플러그인의 소스 포지가 내려가는 상황에 대비한 백업 계획이 저한테는 전혀 없었고, 보아하니 Neovim 패키지 매니저도 마찬가지였습니다. 세션을 시작할 때마다 오류만 계속 띄우고 손쓸 방법이 없더라고요 :)
길게 보면 코드 저장소가 항상 거기 있거나 어딘가에 쉽게 캐시되어 있을 거라고 가정하면 안 되겠지만, 그때까지는 어느 정도 성장통이 있을 것 같습니다. ATProto에는 ActivityPub 같은 이점이 없는 듯합니다. ActivityPub에서는 보려던 인스턴스가 내려가도 메시지를 받아 둔 다른 인스턴스를 대개 찾을 수 있으니까요.
맞는 말씀입니다. 저희는 자기 git remote를 직접 운영하는 일을 최대한 쉽게 만들고 싶습니다. 그러면 규모도 알아서 키울 수 있고요.
대신 ATProto는 이 데이터를 누구든 독립적으로 인덱싱할 수 있고 메시지를 놓치지도 않습니다. AP는 그게 안 되죠. 장단점이 서로 다릅니다!
이론상으로는 누군가(혹은 어떤 그룹이) 데이터 저장소를 완전히 콘텐츠 주소 방식으로 만들어서 해시로 콘텐츠를 제공할 수도 있을 겁니다. 그러면 기존 구조 위에 그 빠진 이점을 얹는 셈이죠. 아마 누가 몇 시간이면 바이브 코딩으로 뚝딱 만들 수 있을걸요 :)
radicle 같은 거요? https://radicle.dev/
연합형 git 호스팅의 이상적인 지점은 tangled의 기능과 radicle의 기능을 합친 시스템일 수 있다는 데 동의합니다.
다만 설계상의 트레이드오프가 정말 많이 다르다는 점은 인정해야겠네요.
저는 의존하는 핵심 git 저장소를 가능한 한 많이 NAS에 미러링하기 시작했습니다. systemd 타이머로 원격에서 주기적으로 업데이트하고, 제가 관리하는 저장소는 post-receive 훅으로 외부에도 미러링합니다. 이 글을 보니 그 작업을 더 넓혀야겠다는 생각이 드네요.
이 문제는 어떤 패키지 매니저에서든 생길 수 있습니다. 예를 들어 Go 패키지 매니저는 어떤 git URL에서든 패키지를 지정할 수 있게 해 주죠. 저희는 모든 git 저장소의 미러를 저희 인프라에 두고 있고, 원래 knot이 내려가 있으면 그 미러로 서비스합니다. 그 미러를 신뢰하기로 하고 거기서 받아 올 수도 있습니다(tarball이 알려진 올바른 해시와 일치하는지 확인하면서요). Go 패키지 매니저가 proxy.golang.org에서 받아 오는 방식과 같습니다.
아, Tangled 사이트의 tarball이 캐시된다는 건 몰랐습니다. 또 그러면 그걸 써 보겠습니다 :)
어떤 패키지 매니저든 겪는 문제라는 건 저도 압니다. 직접 전부 미러링하는 수고를 들이지 않는 한, 로컬 편집기 같은 것조차 이제 원격 포지에 의존한다는 사실을 잠시 잊었던 것 같습니다.
모든 패키지 매니저의 문제일까요? 이론상으로는 그렇지만 실제로는 아닙니다. Debian이나 Arch 등은 미러가 워낙 많아서 문제가 되지 않습니다.
안녕하세요! Tangled 공동 창업자입니다. 이번 출시가 정말 기쁩니다. AT Protocol lexicon을 안정화했고, 아키텍처와 UI를 완전히 갈아엎었으며, 전체 스택(또는 일부만!)을 셀프 호스팅하기가 놀랄 만큼 쉬워졌습니다. 조직(organization) 기능도 내놓았고, 비공개 저장소는 앞으로 몇 주 안에 순차적으로 열립니다.
궁금한 점은 무엇이든 기꺼이 답해 드리겠습니다.
이 방향이 반갑습니다. 제 프로젝트는 대부분 직접 운영하는 Forgejo로 옮겼는데, 외부 사람이 제 시스템에 가입하지 않고도 쉽게 PR 같은 걸 열 수 있으면 좋겠다는 아쉬움이 있어요. 저는 가입을 허용할 마음이 전혀 없거든요.
그래서 지금 Tangled는 어느 단계인가요? 제가 Tangled 서버(인스턴스? 호스트?)를 띄워 저장소를 올려 놨다고 해 보죠. 어떤 낯선 사람이 기여하고 싶어 해요. 이슈를 열거나 PR을 보내려면 그 사람이 먼저 무엇을 해야 하나요?
바로 그게 저희가 풀고 싶은 문제입니다. 물론 어떤 형태로든 신원은 필요합니다. 이 경우 AT Protocol 계정이 있어야 하죠. Personal Data Server0를 직접 호스팅하거나, Tangled나 Bluesky/Blacksky 같은 제공자에 가입하면 됩니다. 이 계정이 그 사람이 만들 마지막 계정입니다(본인 소유이고 이동도 가능합니다!). 그 뒤로는 바로 기여를 시작할 수 있고, Tangled와 다른 AT Protocol 서비스 전체에서 같은 계정을 씁니다.
운영하시려는 Tangled git 서버는 'knot'1입니다. 헤드리스라서 Forgejo와 정확히 같은 개념은 아니지만, 그만큼 운영에 드는 자원이 아주 적습니다.
알겠습니다. 아직 완전히 이해하지는 못했는데, Mastodon 인스턴스를 10년 가까이 운영했어도 그걸 이해하는 데 한참 걸렸으니 이번에도 그러려니 합니다.
정말 좋네요. 제 knot이 제 프로젝트를 호스팅하고, 친구의 knot과 이야기하고, 글로벌 프로젝트의 knot에서 협업하는 모습이 기대됩니다. 누구도 하나의 중앙 집중식 단일 장애점(제 것이라도)에 가둬 두지 않고요. 놀랍습니다. 정말 마음에 듭니다!
atproto 계정만 있으면 됩니다. Tangled에서 직접 만들 수도 있고, 이미 있는 계정을 가져와도 됩니다. 그러면 당신 저장소에 이슈를 열 수 있습니다.
곧 저장소마다 기여 정책을 선언할 수 있게 됩니다. 지금은 누구에게나 열려 있어서(누구든 이슈를 열 수 있어서), 예를 들어 소유자가 기여자로만 제한하는 선택을 할 수 있게 되는 것입니다.
그게 얼마나 곧일까요? 제 프로젝트 대부분에는 걸림돌이 아니지만, 공개 clone은 허용하면서 좀 더 닫아 두고 싶은 프로젝트가 몇 개 있어요. 그렇다고 공개 저장소에 지금 Tangled를 못 쓰는 건 아닙니다. 다만 한동안은 Tangled와 Forgejo, 이렇게 공유 환경을 최소 두 개는 동시에 돌려야 한다는 뜻이죠.
그리고 특정 사람에게만 보이거나 가져갈 수 있는 비공개 저장소도 Tangled가 지원하나요? 애초에 그 모델에서 그게 말이 되나요?
협업 정책은 이미 프로토콜에 들어 있고, 대표 클라이언트에 반영하는 일만 남았습니다!
비공개 저장소도 곧 나옵니다. 동작하는 데모는 이미 있습니다.
좋네요. 감사합니다!
https://forgefed.org/ 에 대해서는 어떻게 생각하시나요?
Tangled 멋져 보이고, knot을 직접 호스팅해 볼까 생각도 하고 있습니다. 다만 그런 결정을 할 때 제가 따져 보는 것, 그리고 궁금한 것은 비즈니스 모델입니다. 지금은 웹사이트만으로는 분명하지 않아서, 여기서 조금이라도 공유해 주실 수 있으면 좋겠습니다.
이걸 실행해 봤습니다.
그런데 실패했습니다.
제일 먼저 해 보고 싶은 일이 이 모양이면 인상이 좋을 수가 없습니다.
이제 저 다른 도메인이 의도된 것인지 침해된 것인지부터 알아봐야 합니다.
제가 보기엔 tangled의 git 구현이 아니라 당신 운영체제의 문제예요. 이름에 콜론이 들어간 파일을 체크아웃하려는 건데, Windows는 DOS 시절의 잔재 때문에 그걸 처리하지 못하거든요. 그걸 GitHub 같은 데 미러링한 다음 clone해 봐도 아마 똑같은 오류가 날 거예요.
WSL에서, 그것도 VM의 파일시스템 안에서 clone해 보고 어떻게 되는지 다 같이 알려 주세요.
고맙습니다. 원인은 정확히 짚으셨는데, 제 설정이 아닌 이상 "제" OS의 문제라고 부르고 싶지는 않습니다.
저는 그냥 소스를 로컬에서 읽고 싶었을 뿐입니다. 다른 개발자들이 Windows 지원에 점점 신경을 안 써서 Windows 개발자에게는 달마다 사정이 나빠지는 걸 알지만, clone조차 안 되는 저장소는 이상합니다.
빌드가 안 되는 건 흔하고, 빌드는 되는데 테스트가 안 통과하는 것도 아주 흔합니다. 하지만 clone부터 안 되는 건 처음 보네요.
결국 포기하고 리눅스로 갈아타겠지만, 저는 아직 Windows에서 일하는 대가로 월급을 받고 있습니다. 이런 일에는 이제 제대로 된 dev container 환경을 알아볼 때가 된 것 같고, 그러면 보안도 조금 더 챙길 수 있겠죠.
Windows 지원은 앞으로도 한동안 필요하다고 봅니다. 저는 접근성이 모든 운영체제 중 (여전히) 가장 좋아서 Windows에서 벗어나지 못하고 있습니다(Wine은 그 대안이 되지 못합니다). 안타깝지만, 앞으로 달라지길 바라고 있습니다.
의외네요. 저는 Mac에서는 접근성 옵션을 잘 안 쓰고 iOS에서만 몇 가지 쓰는데, iOS에 옵션이 워낙 많아서 당연히 Apple이 접근성이 제일 좋다고 생각했거든요. 거의 너무 많다 싶을 정도지만, 그게 또 핵심이라는 건 이해합니다.
시각장애인과 저시력자 대부분은 Windows를 씁니다. 거기도 여러모로 형편없습니다(자원을 잡아먹고, 앱이 죽고, 전반적으로 버그와 버벅임이 있죠). 그래도 (대개 서드파티인) 접근성 소프트웨어가 지원하는 최종 사용자 애플리케이션 목록이 더 완전합니다.
저는 시각 장애가 있는데, 지금은 macOS로 충분합니다. 확대 기능만 있으면 되고, 터미널이나 IDE처럼 제가 다루는 게 거의 다 자유롭게 흐르는 텍스트라서 그것도 많이 안 써도 되거든요. 하지만 화면 낭독기에 더 의존해야 하게 되면 갈아타는 걸 고려해야 할 것 같습니다. 리눅스가 아닌 다른 쪽으로 가야 한다면 가슴이 찢어질 겁니다.
제가 본 전형적인 파일시스템 오류 두 가지는 MacOS의 대소문자 비구분 때문에 서로 다른 두 파일이 하나로 합쳐지는 경우와 Windows의 예약 문자입니다. 대부분 리눅스로 빌드하고 배포하니 저장소는 보통 그 OS 기준으로 멀쩡하죠. 어쩔 수 없는 일이지만, 입장이 바뀐 걸 보니 웃기긴 하네요.
설정 때문이라면 OS의 문제가 아니라 설정의 문제입니다. 당신의 문제는 정확히 말하면 OS가 파일 이름에 쓸 수 있는 문자를 일부 지원하지 않기로 했는데, 당신은 그 문자가 들어간 파일을 쓰고 싶다는 겁니다.
그건 설정이 아닙니다. Windows가 이름에 콜론이 든 파일을 받아들이게 설정할 방법은 없어요. 그렇게 따지면 소프트웨어가 파일시스템이 대소문자를 구분하지 않는다고 하드코딩해 놨을 때도 설정 문제라고 하겠네요.
잘되면 좋겠습니다!
피드백을 드리면:-
홈페이지/타임라인의 UI가 좀 복잡해 보였습니다. 정신이 없어요. 알림, 최근 항목, 공지가 굳이 이 페이지에 있어야 하나 싶습니다.
사용자 프로필 페이지의 활동 차트는 제가 보기엔 좀 과합니다. 단순하게 바꾸거나, GitHub/GitLab이 쓰는 네모 격자 활동 차트를 그대로 쓰길 권합니다. 사용자들에게 가장 익숙하니까요. 최근 몇 년간 LLM/챗 애플리케이션이 전부 같은 UI로 수렴한 것과 비슷합니다. 그게 통하니까 그렇게 된 거고, 사용자가 이미 아는 패턴이 있는데 바퀴를 다시 발명할 필요는 없죠. 게다가 마케팅에도 낫습니다:- 사람들은 GitHub/GitLab에서 자기 활동을 공유하길 좋아하는데, 한 해 동안 얼마나 일했는지 한눈에 보여 주기 때문입니다. 지금 페이지는 그게 안 됩니다.
핀란드 스타트업 Tangled, 코드 협업을 재발명하기 위해 380만 유로 투자 유치 https://www.vestbee.com/insights/articles/tangled-raises-3-8-m
비즈니스 모델이 뭐고, 투자금은 어떻게 회수할 계획인가요? GitHub와 경쟁하기는 쉽지 않을 텐데요...