GitHub 없는 깃, Radicle에 무슨 일이 생겼나
깃허브 없이 깃 저장소를 개발자들끼리 직접 주고받는 P2P 코드 협업 도구 Radicle이 자체 네트워크 프로토콜에서 발견된 취약점을 공개했어요. 이 글을 읽는 분 중에 Radicle 노드를 직접 돌리고 계신 분은 많지 않겠지만, 이번 공지는 '중앙 서버가 없는 시스템에서 보안 패치가 어떻게 굴러가는지'를 보여주는 꽤 좋은 사례거든요. 그래서 취약점 자체보다 그 배경과 구조를 중심으로 풀어보려고 해요.
먼저 Radicle이 뭐냐면, 한마디로 '서버 없는 깃허브'예요. 깃허브나 깃랩은 결국 회사가 운영하는 중앙 서버에 코드를 올리고, 이슈나 PR도 그 서버의 데이터베이스에 저장되잖아요. Radicle은 그 중앙 서버를 없애고, 참여자 각자의 컴퓨터에서 도는 노드들이 서로 직접 연결해서 저장소를 주고받게 만든 프로젝트예요. 이슈나 패치(PR에 해당) 같은 협업 데이터까지 전부 깃 객체로 저장해서, 코드와 함께 P2P로 복제돼요. 2024년에 Heartwood라는 이름의 프로토콜 기반으로 1.0 정식 버전이 나왔고, 러스트로 작성돼 있어요.
어떤 구조이길래 '네트워크 프로토콜' 취약점이 문제가 될까
Radicle에서 각 노드는 ed25519 키 쌍을 하나 갖고, 그 공개키가 곧 노드의 신분증(Node ID)이에요. 저장소도 고유한 ID(RID)를 갖고요. 노드들은 서로 연결되면 '나는 이런 저장소를 갖고 있어'라고 소문내듯 알리고(이걸 가십 프로토콜이라고 해요), 관심 있는 저장소가 있으면 그 노드에서 가져와서 자기도 씨앗(seed)처럼 보관하며 다시 퍼뜨려요. 노드 간 연결은 Noise 프로토콜 프레임워크 기반으로 암호화되고, 각 사용자의 브랜치 정보는 본인 키로 서명돼서 위변조를 막아요.
그런데 이런 구조에서는 '인터넷 반대편의 모르는 노드가 보내는 메시지'를 우리 노드가 받아서 해석해야 한다는 게 핵심이에요. 중앙 서버 방식이면 서버 운영자가 방화벽 뒤에서 통제할 수 있지만, P2P에서는 모든 노드가 곧 공개된 공격 표면이 되거든요. 프로토콜 메시지를 해석하는 파서, 연결 수나 메모리 같은 자원 제한, 상대 노드의 신원 검증, 가십으로 퍼지는 정보의 신뢰성 같은 것들이 모두 잠재적인 약점이 돼요. 이번 공지가 이 중 정확히 어떤 유형인지, 영향받는 버전과 수정된 버전이 무엇인지는 Radicle 공식 공지를 직접 확인하시는 게 정확해요. 여기서는 세부 사항을 추측하기보다 왜 이런 공지가 중요한지에 집중할게요.
P2P에서는 패치 배포 자체가 어렵다
중앙 서버 서비스는 운영사가 서버를 고치면 그 순간 모든 사용자가 안전해져요. 반면 Radicle 같은 P2P 네트워크는 노드를 돌리는 사람 각자가 자기 노드를 업그레이드해야 해요. 오래된 버전의 노드가 남아 있으면 그 노드 자체가 위험할 뿐 아니라, 취약점 종류에 따라서는 네트워크 전체에 잘못된 정보를 퍼뜨리는 통로가 될 수도 있고요. 그래서 이런 프로젝트들은 보통 '수정 버전을 먼저 조용히 배포하고, 사용자들이 업데이트할 시간을 준 다음에 취약점 내용을 공개'하는 조율된 공개(coordinated disclosure) 절차를 따라요. 이번 공지 역시 그 마지막 단계라고 보시면 돼요.
Radicle 노드를 돌리고 계시다면 rad --version으로 현재 버전을 확인하고, 공지에 적힌 수정 버전 이상으로 올린 뒤 rad node stop과 rad node start로 재시작하시면 돼요. 정확한 설치 및 업그레이드 절차는 공식 문서에 맞춰 진행하세요.
업계 맥락: 탈중앙 코드 호스팅의 현재 위치
코드 호스팅은 여전히 깃허브가 압도적이고, 셀프 호스팅 쪽에서는 GitLab, Gitea, 그리고 Gitea에서 갈라져 나온 Forgejo가 인기예요. Forgejo는 ForgeFed라는 연합 프로토콜로 서로 다른 인스턴스끼리 이슈나 PR을 주고받는 방향을 실험 중이고요. Radicle은 이보다 한발 더 나아가 서버 자체를 없앤 완전 P2P 접근이라 가장 급진적인 쪽에 있어요. 최근에는 Nostr 프로토콜 위에서 깃 협업을 하려는 시도도 나오고 있어서, '깃허브 의존을 줄이자'는 흐름이 소수지만 꾸준히 이어지고 있어요.
다만 P2P라고 해서 더 안전한 건 아니에요. BitTorrent, IPFS의 libp2p, Matrix 같은 탈중앙 프로토콜들도 프로토콜 계층에서 취약점이 반복해서 발견돼 왔거든요. 중앙 서버를 없애면 '한 곳이 뚫리면 전부 뚫리는' 위험은 줄지만, 대신 '모든 참여자가 각자 방어해야 하는' 부담이 생겨요. 보안이 사라지는 게 아니라 옮겨가는 거죠.
한국 개발자에게 주는 시사점
당장 Radicle을 도입할 팀은 많지 않을 거예요. 그래도 이번 사례에서 가져갈 만한 교훈은 분명해요. 첫째, 여러분이 직접 네트워크 프로토콜을 설계할 일이 있다면(사내 메시징, 게임 서버, IoT 기기 통신 같은 것들), '인증 안 된 상대가 보내는 바이트를 어디까지 믿을 것인가'를 설계 초기에 정해야 해요. 파서에 퍼징(무작위 입력을 마구 넣어 깨지는지 보는 테스트)을 돌리고, 연결 수와 메모리에 상한을 두는 게 기본이에요. 둘째, 오픈소스 인프라를 셀프 호스팅한다면 보안 공지 채널을 구독하고 업그레이드 경로를 미리 마련해 두세요. 중앙 서비스에 익숙해지면 '누가 대신 패치해주는' 편안함에 무뎌지기 쉽거든요. 셋째, 깃허브 종속을 줄이고 싶다면 Forgejo 같은 셀프 호스팅부터 시작해 보고, Radicle은 실험용으로 노드 하나 띄워 보는 정도가 현실적이에요.
마무리
한 줄로 정리하면, '중앙 서버를 없애면 공격 표면이 사라지는 게 아니라 모든 노드로 흩어진다'는 걸 Radicle의 이번 공지가 다시 보여줬어요. 여러분은 깃허브 의존도를 줄일 필요를 느끼시나요? 느낀다면 P2P 도구의 운영 부담까지 감수할 만한 가치가 있다고 보시나요?
🔗 출처: Hacker News