HardenedBSD가 Radicle로 옮겨갔다 — P2P 기반 Git 협업의 실험

들어가며

보안 강화에 초점을 맞춘 BSD 운영체제인 HardenedBSD가 자기들의 메인 코드 협업 플랫폼을 Radicle로 공식 이전했어요. 들어보신 분도 있고 처음 듣는 분도 계실 텐데, Radicle은 "P2P 기반의 탈중앙화 Git 협업 플랫폼"이에요. GitHub나 GitLab 같은 중앙 서버 없이, 마치 토렌트처럼 노드끼리 직접 코드와 이슈, PR을 주고받는 구조죠.

사실 Radicle 자체는 몇 년 전부터 있었지만, 실제 큰 프로젝트들이 메인 협업 플랫폼으로 이걸 채택한 사례는 많지 않았어요. 그래서 HardenedBSD의 결정은 단순한 도구 이전 이상의 의미를 가져요. "중앙화된 코드 호스팅을 진짜로 벗어날 수 있느냐"는 질문에 대한 실험이거든요.

Radicle이 뭐길래

조금만 풀어서 설명할게요. 우리가 평소 GitHub에 push를 하면, 그 코드는 결국 Microsoft가 운영하는 서버 어딘가에 저장돼요. 모두가 한 곳을 바라보고 있는 거죠. 만약 GitHub가 다운되거나, 어떤 정치적 이유로 특정 저장소를 막아버리면 협업이 막혀요. 실제로 이란 개발자 계정을 일시적으로 막은 사건도 있었고요.

Radicle은 이걸 다르게 풀어요. 각 참여자가 자기 노드를 띄우고, 그 노드들이 서로 직접 연결돼요. 코드는 Git 그대로지만, 이슈와 PR(여기선 "patch"라고 불러요), 코멘트 같은 메타데이터도 모두 Git 객체로 저장돼서 P2P 네트워크로 동기화돼요. 즉, 저장소 전체와 협업 히스토리가 분산되어 복제되는 거죠. 어떤 노드가 사라져도 다른 노드에 사본이 있어요.

인증은 공개키 기반이에요. 각 사용자는 자기 키를 가지고 있고, 서명으로 신원을 증명해요. GitHub 계정 같은 중앙 ID 시스템이 필요 없고, 누가 막아버릴 주체도 없어요.

HardenedBSD가 왜 옮겼을까

HardenedBSD는 보안과 검열 저항성을 중요하게 생각하는 프로젝트예요. ASLR 강화, W^X 메모리 보호, SafeStack 같은 보호 기법을 OS 레벨에서 적용하는 게 본업이거든요. 이런 철학을 가진 팀이라면 "코드 호스팅도 단일 회사에 의존하지 말자"는 결론에 도달하는 게 자연스러워요.

또 BSD 진영은 전통적으로 자체 인프라를 운영하는 문화가 강해요. FreeBSD도 자체 메일링 리스트, 자체 Bugzilla, 자체 Phabricator(현재는 종료) 같은 식으로 GitHub 의존을 최소화해왔거든요. HardenedBSD가 Radicle을 택한 건 이 흐름의 연장선이에요.

실제 쓰면 어떤 느낌일까

Radicle을 쓰려면 rad CLI를 설치하고 노드를 실행해요. 그리고 기존 Git 저장소를 rad init으로 Radicle 네트워크에 등록하면, 고유한 Radicle ID(RID)가 생겨요. 이게 마치 IPFS의 CID처럼 콘텐츠 기반 식별자 역할을 해요.

다른 사람이 내 저장소에 기여하려면 내 RID를 알면 돼요. rad clone <RID>로 받아오고, 패치를 만들어서 rad patch open으로 보내요. 받은 사람은 자기 노드에서 그 패치를 확인하고 머지할 수 있고요. 웹 UI도 있긴 한데, GitHub 같은 매끄러운 경험을 기대하면 아직은 좀 거칠어요.

비슷한 시도들과 비교

탈중앙화 코드 협업 시도는 Radicle만 있는 게 아니에요. Gitea나 Forgejo, Codeberg는 "자체 호스팅 가능한 GitHub 대안"이지만 여전히 클라이언트-서버 구조라 진짜 P2P는 아니에요. SourceHut도 이메일 기반의 옛날 방식 협업을 지향하지만 중앙 서버가 있고요.

반면 Radicle은 정말로 "서버 없는" 모델을 추구해요. 비슷한 철학으로는 과거에 있었던 GitTorrent나 Mango(Ethereum 기반 Git) 같은 시도가 있었는데, 대부분 실험에 그쳤어요. Radicle은 그중에서 가장 성숙한 단계까지 온 프로젝트라고 볼 수 있어요.

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

당장 회사 코드를 Radicle로 옮길 만한 상황은 거의 없을 거예요. 한국 회사들 대부분은 GitHub Enterprise나 GitLab 자체 호스팅으로 충분하고, 검열 저항성 같은 요구가 절박하지 않으니까요. 다만 개인 사이드 프로젝트나 오픈소스 활동에선 한 번쯤 시도해볼 만해요. 특히 Web3, 보안 연구, 프라이버시 도구 같은 영역에서 활동하시는 분들에겐 의미 있는 옵션이 될 수 있고요.

그리고 Radicle을 살펴보는 과정에서 "Git이 정말로 분산 시스템이라는 게 뭘 뜻하는가"를 다시 생각하게 돼요. 우리는 GitHub를 너무 오래 써서 Git의 본질을 잊고 있었거든요. Git은 원래 Linus가 "중앙 서버에 의존하지 않게 만들겠다"고 만든 도구예요. Radicle은 그 본질에 가장 충실한 협업 레이어를 입힌 셈이죠.

마무리

HardenedBSD의 Radicle 이전은 "탈중앙화 코드 협업이 실제로 굴러갈 수 있다"는 작은 증거예요. 모두가 따라갈 길은 아니지만, 선택지가 있다는 것 자체가 건강한 신호고요.

여러분은 GitHub 외의 코드 호스팅을 써본 경험이 있으신가요? 만약 GitHub가 어느 날 갑자기 사용 불가능해진다면, 여러분의 프로젝트는 얼마나 빠르게 다른 곳으로 옮길 수 있을까요?