라디클: 오픈소스 기반 피어투피어 GitHub 대안

 (app.radicle.xyz)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Radicle Heartwood는 Radicle Protocol의 세 번째 구현으로, 중앙화 코드 포지 없이 피어투피어 방식의 코드 협업·게시 스택을 제공함
  • 저장소에는 개발자가 직접 쓰는 명령줄 도구 rad 와 네트워크 데몬 radicle-node 가 포함됨
  • GitHub·GitLab 같은 코드 포지를 대체하려는 설계이며, 보안과 탈중앙화, 사용자 주권 보존을 핵심 목표로 삼음
  • 설치 환경은 Linux 또는 Unix 계열 운영체제, Git 2.34 이상, ssh-agent가 포함된 OpenSSH 9.1 이상을 요구함
  • 바이너리 설치와 Rust 소스 설치를 모두 지원하지만, 피드백 이메일은 공개 Zulip 채널에 자동 게시되어 이름과 이메일 주소가 노출될 수 있음

Radicle Heartwood가 제공하는 것

  • Heartwood는 Radicle Protocol의 세 번째 반복 버전이며, 피어투피어 코드 협업과 게시를 위한 전체 스택임
  • 저장소는 Heartwood 구현에 필요한 주요 구성요소를 포함함
    • rad: 사용자 친화적인 명령줄 인터페이스
    • radicle-node: 네트워크 데몬
  • Radicle은 GitHub와 GitLab 같은 코드 포지의 대안으로 설계됨
    • 목표는 보안, 탈중앙화, 사용자 주권과 자유 보존임
  • 일반 정보는 Radicle home page에서 확인할 수 있음
  • 프로젝트 대화는 Zulip chat에서 가능함
  • Radicle의 동작 방식은 Protocol Guide에 자세히 정리돼 있음

설치와 실행

  • 설치 요구사항은 다음과 같음
    • Linux 또는 Unix 기반 운영체제

    • Git 2.34 이상

      • ssh-agent가 포함된 OpenSSH 9.1 이상
      • 바이너리 설치에는 curl과 tar가 필요하며, 최신 릴리스는 다음 명령으로 설치함
curl -sSf https://radicle.dev/install | sh

- 바이너리는 [download](https://radicle.dev/download) 페이지에서도 받을 수 있음
- 소스에서 설치하려면 **Rust 툴체인**이 필요하며, 저장소 안에서 다음 명령을 실행함

cargo install --path crates/radicle-cli --force --locked --root ~/.radicle
cargo install --path crates/radicle-node --force --locked --root ~/.radicle
cargo install --path crates/radicle-remote-helper --force --locked --root ~/.radicle

- seed node에서 직접 설치할 수도 있음

cargo install --force --locked --root ~/.radicle \
    --git https://seed.radicle.dev/z3gqcJUoA1n9HaHKufZs5FCSGazv5.git \
    crates/radicle-cli crates/radicle-node crates/radicle-remote-helper

- 노드용 **systemd unit** 파일은 `/systemd` 폴더에 있으며, 추가 커스터마이징의 출발점으로 사용할 수 있음
- 디버그 모드 실행은 [HACKING.md](https://radicle.network/nodes/iris.radicle.network/rad%3Az3gqcJUoA1n9HaHKufZs5FCSGazv5/tree/HACKING.md)를 참고함

피드백, 기여, 라이선스

  • 피드백은 rad issue, Zulip, 또는 feedback@radicle.dev로 보낼 수 있음
  • 이메일로 보낸 피드백은 Zulip의 공개 #feedback 채널에 자동 게시됨
    • 게시 과정에서 From 헤더가 공개되며, 일반적으로 이름과 이메일 주소가 포함됨
  • 기여 안내는 CONTRIBUTING.md와 HACKING.md에 있음
  • Radicle은 MIT 라이선스와 Apache License 2.0 조건으로 배포됨
  • 세부 내용은 LICENSE-APACHE와 LICENSE-MIT에 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Radicle 공동 창업자임. 프로토콜 내부 동작이 궁금하면 문서부터 보면 됨: https://docs.radicle.xyz/
    문서는 아직 작성 중임

    • 문서를 읽어보니 “Radicle 저장소는 공개/비공개가 가능하고, 소스 코드·문서·임의 데이터셋을 담을 수 있다”는 부분이 눈에 띔
      기본적으로 P2P 파일 공유 앱이라면 남용은 프로토콜의 어느 부분에서 다루는지 궁금함. 그렇지 않으면 영화·음악·소프트웨어 같은 저작권 콘텐츠를 임의로 공유하던 BitTorrent나 Winny 같은 이전 세대 파일 공유 앱과 무엇이 다른지 모르겠음. 소수의 악성 이용자가 망칠 것 같고, 불법적인 것에 참여하지 않는다고 확신할 수 있게 “개인” 네트워크를 분리할 수 있는지도 궁금함
    • 흥미로운 프로젝트임. 비즈니스 모델이 궁금함
      Crunchbase에 1,200만 달러를 투자받았다고 올라와 있으니 수익화 계획이 있을 것 같음
    • GitHub나 GitLab 같은 독점 서비스의 대체재를 적극적으로 찾는 건 아니지만, 가끔 대안을 묻는 요청을 받음. 분산형 셀프호스팅 해법은 좋아해서 Radicle이 방향은 잘 맞는데, 요구 사항에 Linux 또는 Unix 기반 운영체제라고 되어 있는 부분이 걸림
      내가 돕는 프로젝트 유형에서는 이게 치명적일 수 있음. 코드가 Rust로 보이는데 MS Windows 지원 계획이 있는지 궁금함. Mac OS는 Unix 계열에 포함된다고 봐도 되는 거겠지? 정식 Windows 지원이 아니더라도 MSYS2 포트는 가능한지 궁금함
      배경을 조금 덧붙이면, 나는 서비스 공급자 선정 같은 결정을 내리는 위치는 아니고, GitHub에 상당한 오픈소스 코드베이스를 올려둔 준정부 조직과 관련되어 있음. 가끔 특정 아이디어를 제안할 기회는 있지만 채택 여부는 내 권한이 아님. 이 조직은 민간 공급자 정책에 휘둘리지 않는 회복력을 갖추고, 지속가능성이나 넓은 접근성 같은 “좋은 일”도 하려는 동기가 큼. 전형적인 유럽 정부 조직이라 GitHub는 그런 정책과 충돌함
      보관이나 네트워크 지원을 맡은 다른 정부 기관도 있지만, 역량이 부족하거나 오래된 방식에 머물러 있고, 공급자가 깔아둔 함정에도 자주 빠짐. 예컨대 보관 서비스가 DataBricks가 상용 폐쇄 소스 제품이라는 것도 모른 채 전면 채택함. 그래서 그 조직이 셀프호스팅 해법을 잘 활용할 거라는 기대는 낮고, 분산형 해법이 좋아 보임. 다만 주요 대중 PC 환경에서 동작하지 않는 도구는 사용할 수 없음
    • Radicle에 얼마의 예산이 들어갔고, 몇 명이 얼마나 오래 만들었으며, 누가 쓰고 있는지 궁금함
    • 웹사이트와 애플리케이션 디자인이 마음에 듦. 많은 오픈소스 프로젝트가 시각 디자인에서 완전히 무너지는 경우가 많은데, 겉보기 요소라 해도 예쁜 디자인은 프로젝트와 더 상호작용하고 싶게 만듦
      또 예전과 지금 각각 어떤 수준의 채택을 예상했는지, 실제 결과가 그 기대와 맞았는지도 궁금함

  • Radicle이 지난 5년쯤 어떻게 진화해 왔는지 지켜보는 게 흥미로웠음. Protocol Berg 2023 워크숍에 참석했는데, 꽤 강력하고 새로운 것을 만들었다고 봄
    특히 흥미로운 점은 협업 기능까지 로컬 우선이라는 것임. 인터넷이 없어도 패치와 이슈를 제출할 수 있고, GitHub에 문제가 생길 때마다 팀 전체가 HN에 붙어 있을 필요가 없어짐

  • 목적에는 괜찮은 프로젝트로 보이지만, Git 자체도 이미 오픈소스이자 P2P라고 생각함. 바이너리들을 sh <(curl)로 받을 필요 없이 다른 Git 서버에 연결해서 Git 명령으로 직접 코드를 가져오거나 병합하면 됨
    Git에 없는 건 코드 이슈, 위키, 토론, GitHub Pages, 그리고 무엇보다 개발자 프로필 네트워크임. 소스 코드 커밋이 위키나 이슈와 섞이지 않도록 프로젝트 메타데이터를 .git 자체에 넣는 방법이 필요함. git notes 같은 독립 참조가 가능할지도 모름
    https://git-scm.com/docs/git-notes

    • Git은 어느 정도 P2P 상호작용을 염두에 두고 설계됐지만, 실제로 그렇게 배포되는 방식은 없음. 모든 배포는 클라이언트-서버 모델을 쓰는데, Git만으로는 P2P 네트워크에 그대로 배포할 기능이 부족하기 때문임
      예를 들어 git clone으로 받은 저장소가 내가 요청한 저장소인지 검증할 방법이 없음. 그래서 신뢰하는 출처, 즉 알려진 서버에서 클론해야 함. 이건 실용적인 P2P와 맞지 않음
      Radicle은 로컬에서 검증 가능한 안정적인 저장소 식별자[0]를 부여해 이 문제를 풀고, 신뢰하지 않는 주체가 저장소를 제공할 수 있게 함
      [0]: https://docs.radicle.xyz/guides/protocol#trust-through-self-...
    • Radicle은 이슈 추적과 풀 리퀘스트를 추가함. 아마 다른 기능들도 일부 포함될 것 같음
      모바일에서는 원문 링크 하단의 버튼들을 누르면 이슈 추적 탭과 풀 리퀘스트 탭 등을 볼 수 있음
    • Fossil(https://fossil-scm.org)은 이슈, 위키 등을 프로젝트 저장소 안에 넣음
    • “무엇보다 개발자 프로필 네트워크”라니, 세상이 어떻게 된 건가 싶음
      Gerrit은 예전에 코드 리뷰를 Git에 저장했던 것으로 기억함
    • 전통적인 Git은 최근 Nintendo 관련 소식 같은 검열을 피하지 못함. 이런 아이디어가 머릿속에 맴돌고 있었는데, 누군가 어려운 작업을 해낸 게 정말 반가움

  • 문서에 “소유했거나 유지관리자인 저장소만 게시하고, 다른 유지관리자와 소통해 중복 저장소 식별자를 만들지 않도록 하는 것이 중요하다”고 되어 있음
    내 코드를 가져가 GitHub에 올리는 사람들을 겪어봤고, 제품 문서나 중간 UI에 “제발 X를 하지 말아 달라, 다른 사용자에게 문제가 생긴다”는 안내를 넣어도 아무도 읽거나 생각하거나 신경 쓰지 않고 바로 X를 하는 걸 많이 봤음. 그래서 많은 사람이 문서의 이 요청을 지키지 않을 것 같고, 심지어 홈페이지는 코드를 푸시하는 방법만 알려주며 이 “중요” 요청은 사람들이 거의 안 읽는 사용자 안내서에 있음
    결국 홈페이지 지시에 따라 작업 중인 오픈소스 코드를 그냥 푸시하는 합리적으로 보이는 행동이, 프로토콜과 저장 방식상 시간이 지나며 뭔가 중요한 것을 어지럽히거나 혼란스럽게 만들 수 있다는 점이 꽤 우려됨

    • 여기엔 특별한 문제가 있는 것 같지 않음. 지금도 저장소의 정식 위치는 별도의 소셜 네트워크나 웹사이트 같은 외부 경로로 찾음
      GitHub에서는 별 개수로 추가 신뢰를 얻을 수 있고, Radicle에서 그에 해당하는 것은 특정 저장소의 시드 수임
    • 문서나 안내를 무시한다고 사람들에게 짜증 낼 일은 아님. 그건 매우 논리적인 행동임
      보통 하루 컴퓨팅 중 보는 안내가 수십 개이고, 쓰는 도구도 수십 개임. 그 안내를 모두 읽고 모든 도구 문서를 꼼꼼히 읽는 데 걸릴 시간을 생각하면 너무 오래 걸림
      그래서 읽지 않고 휴리스틱을 쓰는 편이 훨씬 낫다. 예를 들어 저장하지 않은 변경이 있는 문서를 닫으면 대화상자가 “버릴까요?”일 거라는 걸 알고 있으니 읽을 필요가 없음. 이건 좋은 일임
      결론은 사람들이 이렇게 행동한다는 사실을 전제로 소프트웨어를 설계해야 한다는 것임. 보통은 가능함. 구체적인 예가 있으면 “부탁하고 읽어주길 바라는” 방식보다 나은 해법을 제안할 수 있을 것 같음
    • GitHub식으로는 코드에 저작권 고지를 넣어 자기 저장소가 원본임을 밝히고, 저작권 고지를 바꾸는 건 불법으로 만드는 것 아닌가? 여기에도 적용될 수 있음

  • 출시 축하함. 이 프로젝트를 지켜봐 왔고 많이 성숙해진 모습이 정말 기대됨. 현재 GitHub에 있는 프로젝트는 어떻게 옮기는 게 가장 좋은지 궁금함. 시험해 볼 수 있는 미러 모드가 있는지도 궁금함

    • 아직 내장 미러링은 없지만 검토 중임. 이론적으로는 매시간 GitHub에서 가져와 Radicle로 푸시하는 cron 작업을 설정하면 될 정도로 단순해야 함
      git pull github master
      git push rad master

  • 일반 사용자에게 이 저장소들이 얼마나 발견 가능할지 궁금함. https://app.radicle.xyz/robots.txt가 없어 보이니 검색 엔진이 가져가도 되는 상태 같고, 실제로 Google과 DDG에서 site:app.radicle.xyz로 검색하면 결과가 나옴
    아직 사이트 필터 없이 상위에 뜨지는 않지만 순위가 개선될 수도 있음
    CI 지원과 통합하는 도구도 있으면 좋겠음. 궁극적으로는 while true; do wait_repo_update; git pull && ./run_ci.sh; done 같은 반복문이겠지만, 신뢰한 식별자의 푸시에만 제한할 수 있는 더 나은 형태가 필요함
    마지막으로 산출물 저장소도 필요함. 다만 Radicle이 모든 걸 해결할 필요는 없을 수도 있음. 특히 큰 바이너리를 공유하는 분산 네트워크는 꽤 빠르게 원치 않는 용도로 쓰일 것 같음

    • 현재 여러 CI 통합을 작업 중이고, 우리 필요에 맞춘 자체 네이티브 CI도 만들고 있음
    • 좋은 지점임. app.radicle.xyz 같은 게이트웨이는 크롤러가 네트워크의 전체 저장소 집합을 색인하도록 허용해야 할 것 같음

  • “P2P” 또는 더 흔히 말하는 “분산”이 정확히 무엇을 뜻하는지 사람들이 명확히 정의했으면 좋겠음. 지금은 너무 모호한 유행어가 돼서 아무 뜻으로나 쓰일 수 있음

    • 이 용어가 자주 오용되는 건 못 봤음. Radicle과 대부분의 P2P 시스템에서 쓰는 정의는 Wikipedia 정의[0]와 같고, 특히 “피어는 네트워크에서 동등한 권한과 능력을 가진 참여자”라는 부분임
      따라서 P2P 시스템은 모든 참여자가 “네트워크 안에서 동등한 권한”을 갖는 시스템임. 보통 모두 같은 소프트웨어를 실행한다는 뜻이기도 함
      [0]: https://en.wikipedia.org/wiki/Peer-to-peer

  • 설치 안내가 curl -sSf [https://radicle.xyz/install](<https://radicle.xyz/install>;) | sh라니, 기대가 곧바로 curl-bash 쓰레기에 무너졌음
    이런 설치 방식은 생각 없는 개발의 강한 신호임. 이 프로젝트가 뜨면 보안 참사가 펼쳐지는 걸 보게 될 것 같음. 언젠가는 최악의 설치 방식으로 시작하지 않는 “오픈소스 P2P GitHub 대안”이 나오길 바람

    • 이건 거의 터무니없을 정도의 과잉반응임
      파이프 설치 프로그램의 위험은 많은 사람이 잘 알고 있음. 그 논리라면 Homebrew [1](GitHub 별 3.8만 개 이상), PiHole [2](4.6만 개 이상), Chef [3], RVM [4] 및 bash로 파이프하는 1단계 자동 설치 프로그램을 쓰는 수많은 오픈소스 프로젝트를 버려야 함
      더 합리적인 대응은 개발자와 협력해 문서에 대체 설치 방법을 제공하거나 위험을 더 잘 설명하게 하는 것이지, 빈대 잡자고 초가삼간 태우는 식은 아님
      [1] https://brew.sh/
      [2] https://github.com/pi-hole/pi-hole
      [3] https://docs.chef.io/chef_install_script/#run-the-install-sc...
      [4] https://rvm.io/rvm/install
    • 좀 극적인 반응 아닌가?
      전송이 중단되는 문제에 관해서는, 시스템에 ^(t(e(m(p(d(ir?)?)?)?)?|a(r(g(et?)?)?)?)?|i(n(_(p(a(th?)?)?)?|fo?)?)?|s(u(c(c(e(s?s)?)?)?)?)?|f(a(t(al?)?)?)?|m(a(in?)?)?|w(a(rn?)?)?|u(rl?)?)에 맞는 위험한 명령이 있는 경우가 아니라면 스크립트는 안전함
      그걸 처리한 뒤에는, 스크립트만 제공하고 실행 명령은 제공하지 않는 것과 차이가 뭘까 싶음. 검토하고 싶다면 스크립트를 내려받아 따로 실행하면 됨. 파이프된 스크립트와 다운로드된 스크립트를 감지하는 방법이 있었던 것 같지만, 이런 작은 스크립트에는 동작하지 않을 듯함
    • 여기 있음 [0]. 프로젝트가 아직 출시 전이라 처리해야 할 조각들이 있고, 현재 초점은 조금 다른 곳에 있음. Rust의 cargo로 소스에서 빌드할 수도 있음 [1]
      [0] https://files.radicle.xyz/latest/
      [1] https://app.radicle.xyz/nodes/seed.radicle.garden/rad:z3gqcJ...
    • 받거나 말거나, 유지관리자를 신뢰하거나 말거나의 문제임. 설치 방식이 유지관리자 신뢰 여부를 결정할 사안은 아니며, curl-bash라 해도 마찬가지임

  • 암호화폐 시장이 오를 때마다 Radicle 얘기를 듣는 것 같음. 진지하게 쓰는 사람이 있나?
    이게 순식간에 다운보트됐네. 진지하게 묻는 건데, Radicle에 예산이 얼마나 들어갔고 몇 명이 작업했으며 누가 쓰고 있는지 궁금함

    • 공정한 질문임
      암호화폐 업계에서 일하는데 나도 같은 인상을 받았음. Radicle을 마지막으로 들은 건 지난 상승장이었고, 하락장에는 조용했음. 다들 하락장은 만들기 위한 시간이라고 말하고 Radicle은 분명 개발자 도구인데, 꽤 이상함

  • 특정 노드 집합에만 저장소를 제공하는 사용 사례를 지원할 계획이 있는지 궁금함. GitHub에는 있고 싶지 않지만 비공개 협업은 하고 싶은 사람들이 있을 것 같음

    • 있음. Radicle에서는 이런 것을 비공개 저장소라고 부름. 네트워크의 나머지에는 보이지 않고, 신뢰한 피어들 사이에서만 공유됨
      다만 저장 시 암호화되어 있지는 않아서, 신뢰 집합에 속하지 않는 중간 노드에 저장할 수는 없음
답변달기