Radicle - GitHub 없이 Git을 굴리는 P2P 코드 포지의 정체

GitHub가 멈추면 우리 개발은 어떻게 되죠?

GitHub가 다운된 날을 떠올려보세요. CI는 안 돌고, PR은 못 올리고, 이슈도 못 다는 그 답답함. 우리가 매일 쓰는 "Git"은 분산 버전 관리 시스템이라고 배웠는데, 정작 협업의 중심은 GitHub라는 하나의 회사 서버 에 다 몰려있다는 모순이 있잖아요. 이 모순을 정면으로 깨려는 프로젝트가 바로 Radicle(라디클) 입니다.

Radicle은 "주권 있는(sovereign) 코드 포지(code forge)" 를 표방해요. 코드 포지가 뭐냐면, 코드를 호스팅하고 협업하는 플랫폼을 뜻하는 옛날 용어인데, GitHub·GitLab·Bitbucket 같은 걸 통칭하는 말이에요. Radicle은 이걸 P2P 방식으로, 즉 중앙 서버 없이 동료(peer) 컴퓨터들끼리 직접 주고받는 방식으로 구현하겠다는 거죠.

Radicle이 동작하는 방식

원리를 풀어볼게요. Radicle은 Git 위에서 작동합니다. 기존 Git 저장소를 그대로 쓰면서, 그 위에 P2P 게시·동기화 계층 을 얹은 구조예요. 핵심 컴포넌트는 세 가지인데요.

첫째는 Radicle 노드(radicle-node) 예요. 여러분 컴퓨터에서 데몬으로 돌아가면서 다른 노드들과 연결을 유지합니다. TCP 기반의 자체 프로토콜로 통신하고, 노드끼리 저장소 데이터를 교환해요. 마치 BitTorrent처럼 같은 프로젝트를 가진 여러 노드가 함께 그 저장소를 "퍼뜨려주는" 식이죠.

둘째는 암호학적 정체성(Cryptographic Identity) 입니다. GitHub에서는 "이 PR은 OOO이 보낸 거야"를 GitHub 계정 시스템이 보증하잖아요. Radicle엔 중앙 서버가 없으니, 대신 각 사용자가 Ed25519 키 쌍 을 생성해요. 모든 커밋, 코멘트, 이슈, 패치는 이 키로 서명되고, 누구나 서명을 검증할 수 있어요. 즉 "이 변경은 진짜 그 사람이 만들었다"를 수학적으로 증명하는 거죠.

셋째는 COB(Collaborative Objects) 라는 협업 객체입니다. 이슈, PR(여기선 patch라고 불러요), 댓글 같은 협업 데이터를 모두 Git 객체로 저장합니다. 그러니까 이슈도, 댓글도 전부 커밋이에요. 이 덕분에 GitHub처럼 "DB에 데이터가 갇혀 있어서 백업이 어렵다"는 문제가 사라지고, 저장소를 클론하면 코드뿐 아니라 협업 히스토리까지 통째로 따라옵니다.

실제 사용 경험은 어떨까

설치는 단순해요. curl 한 줄로 바이너리를 받고 rad auth 명령으로 신원을 만든 다음, 기존 Git 저장소에 들어가 rad init 하면 P2P 네트워크에 게시됩니다. 협업할 동료에게는 Radicle ID 라는 식별자(rad:로 시작하는 문자열)를 알려주면 되고요. 동료는 rad clone rad:xxx 로 코드를 받아갈 수 있어요.

패치(우리가 아는 PR) 제출도 비슷합니다. 브랜치 만들고, 커밋하고, git push rad HEAD:refs/patches 같은 명령으로 패치를 네트워크에 올려요. 리뷰어는 자기 노드에서 그 패치를 보고 코멘트를 달고 머지 여부를 결정해요. 이 모든 데이터는 Git 객체로 노드 사이에 동기화됩니다.

UI도 있어요. Radicle Explorer 라는 웹 인터페이스가 노드에 내장돼서, 로컬에서 GitHub 같은 화면을 띄울 수 있고, 누구나 자기 노드를 공개 게이트웨이로 운영할 수 있어요. 공식적으로 app.radicle.xyz 같은 호스팅 인스턴스도 있습니다.

비슷한 시도들과 무엇이 다른가

P2P Git 시도는 사실 처음이 아니에요. 옛날에 Gitorious, 최근의 Forgejo, Gitea, sourcehut 같은 셀프호스팅 대안들이 있었죠. 하지만 이건 어디까지나 "내가 직접 서버를 굴리는" 방식이라 운영 부담이 컸어요.

Radicle은 한 발 더 나아가 서버 자체를 없애는 것 이 목표입니다. 비슷한 철학으로는 Git SSB(Secure Scuttlebutt 기반), git-bug(이슈를 Git에 저장), Gitopia(블록체인 기반 코드 호스팅) 같은 프로젝트가 있는데, Radicle은 블록체인 의존성을 최소화하면서(과거엔 이더리움 연동이 있었지만 현재는 선택사항) 순수 P2P + 암호 서명에 집중한다는 점에서 가장 "Git스러운" 접근이라고 평가받아요.

그래서 우리가 써야 하나

현실적으로 말씀드릴게요. Radicle은 아직 얼리어답터 단계 예요. GitHub의 풍부한 생태계(Actions, Marketplace, Copilot, 수많은 통합 도구)를 대체하기엔 부족하고, 발견 가능성(discoverability)도 떨어져요. GitHub처럼 "트렌딩" 같은 글로벌 인덱스가 없으니까 좋은 프로젝트를 우연히 만나기 어렵죠.

그래도 의미는 큽니다. 첫째, 검열 저항성 이에요. 특정 국가나 회사가 저장소를 내릴 수 없습니다. 오픈소스 활동가, 정치적으로 민감한 도구를 만드는 개발자에겐 매력적이죠. 둘째, 데이터 주권. 회사가 갑자기 정책을 바꾸거나 가격을 올려도 영향받지 않아요. 셋째, 장기 보존. GitHub가 어떤 이유로든 사라져도, 노드들이 살아있는 한 코드는 살아남습니다.

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

당장 회사 메인 저장소를 Radicle로 옮기진 않더라도, 백업 채널 로 쓰는 건 충분히 검토해볼 만해요. 오픈소스 프로젝트를 운영한다면 GitHub와 함께 Radicle에 미러를 두는 것만으로 회복탄력성이 올라가거든요. 또 P2P 동기화, 암호학적 서명, Git 객체 기반 협업 모델은 그 자체로 공부할 만한 시스템 디자인 사례예요. CRDT나 분산 시스템에 관심 있는 분이라면 코드(Rust로 작성됨)를 뜯어보는 것만으로 배울 게 많습니다.

마무리

GitHub는 너무 편해서, 우리는 Git이 분산이라는 사실을 잊고 살았어요. Radicle은 그 분산성을 다시 끝까지 밀어붙이는 실험입니다. 여러분은 "내 코드의 주인"이 누구라고 생각하세요? 만약 GitHub가 갑자기 사라진다면, 우리 프로젝트는 어떻게 살아남을 수 있을까요?