Radicle과 디지털 철학

Posted on October 6, 2024

Awesome Philosophy

요즘 들어, 임의의 기술 스택이나 플랫폼에 대한 “awesome list”를 운영하는 것이 거의 표준처럼 자리 잡고 있다. 그런데 이러한 리스트는 좀더, 말하자면 추상화된 무언가에 대해서도 유지될 수 있다. 철학하기 가 바로 그것이다.

해서, 디지털 철학자 chogye 님이 관리하는 Awesome Philosophy라는 훌륭한 리포지토리를 발견했다. 만약 당신의 인생이 총체적 불합리에 불과할지 모르고, 그렇다고 한들 딱히 나쁠 것 없다는 것을 이제야 자각했으며, 생각하는 사람으로의 전향을 바라고 있다면, 이 리포지토리는 당신으로 하여금 디지털 철학의 첫 걸음을 뗄 수 있게 도와줄 것이다.

디지털 철학

이 용어가 가리키는 명확한 범위를 설정하는 것은 꽤 번거로운 일이다. 디지털 철학이 다루는 것은 본질적으로 우리의 형이상학적 세계관과 크게 다르지 않아야 한다. 디지털로의 전환, 혹은 병치juxtaposition는 역사적 진보의 요구에 따라 이루어지고 있다. 수십 년 전, IETF가 전자 메일의 사양을 정의했다. 이 자기 실현적 예언은 현재 주고 받아지는 편지들 중 대다수의 중요한 것들이 전자 메일로 전환되게끔 하였다 (최소한 한국에서는 그렇다. 당신이 일본에 거주하고 있다면 이야기는 조금 다를 것이다). 디지털 철학의 목적도 이와 비슷하다. 우리 디지털 철학자들이 필연적으로 디지털이 지배적 가치를 띠게 될 것이라고 믿을 필요는 없다. 우리의 존재 자체는 그저 역사적 진보로 인해 철학적 개념들이 재평가되는 현상의 일부다.

따라서 우리의 Awesome Philosophy 리포지토리는 근본적으로 다른 철학적 분야에 대한 가이드를 제공하는 것이 아니다 (적어도 나는 그렇게 생각한다). 그보다 이 가이드는 우리가 현재 동원할 수 있는 도구를 통해 세계를 이해하려는 사람들을 위한 것이다. 나는 그 도구가 디지털적이라는 것에 대해 역사적인 것 외에 큰 의미를 두지는 않으려 한다.

Radicle

이 리포지토리는 현재 Radicle에서 운영되고 있으므로, 이 기술에 대한 적절한 소개가 필요할 것이다. ChatGPT에게 그 소개를 요청했더니 나쁘지 않은 답변이 나왔다.

Radicle은 분산된 코드 협업을 위해 설계된 피어 투 피어 네트워크로, GitHub과 같은 중앙 집중식 플랫폼의 대안입니다. 개발자들이 제3자 서버에 의존하지 않고 Git을 기반으로 한 피어 투 피어 프로토콜을 사용하여 코드 리포지토리를 공유하고, 기여하며, 관리할 수 있게 합니다. Radicle은 사용자 주권과 오픈 소스 개발을 우선시하며, 사용자들이 코드와 협업 과정에 대해 완전한 통제권을 가질 수 있도록 합니다. 또한 이더리움과 같은 도구들과 통합하여 분산된 자금 지원 및 거버넌스 메커니즘을 지원, 분산적이고 자율적인 환경에서 개발자들을 더욱 강력하게 만듭니다.

소프트웨어 자유와 관련된 아이디어에 관심이 있었다면, 위의 소개만으로도 충분한 흥미를 느꼈으리라 생각한다. Richard Stallman과 자유 소프트웨어 재단은 인간에게 필수적인 소프트웨어 자유에 대해 다음과 같은 일반적인 아이디어를 제공한다.

  • 프로그램을 어떤 목적으로든 원하는 대로 실행할 자유 (자유 0).
  • 프로그램이 어떻게 동작하는지 공부하고 그것을 원하는 대로 수정할 자유 (자유 1). 이를 위해 소스 코드를 사용할 수 있어야 한다.
  • 다른 사람을 돕기 위해 프로그램의 복사본을 재배포할 자유 (자유 2).
  • 수정한 버전의 복사본을 다른 사람에게 배포할 자유 (자유 3). 이를 통해 커뮤니티 전체가 당신의 변경 사항으로부터 혜택을 볼 수 있다. 소스 코드에 접근할 수 있어야 한다.

https://www.gnu.org/philosophy/free-sw.en.html

위의 코드에서 자유 0과 자유 1을 따르는 것은 주로 개발자와 메인테이너에게 달려 있다. 하지만 자유 2와 자유 3은 소프트웨어의 배포 및 재배포에 대한 것이다. 여기서부터 좀 까다로워진다. 프로그램을 배포할 때는 종종 특정 회사의 서버에 의존하게 되는데, 이는 그들의 자본에 의존하는 것과 같다. 이 방식은 공유 경제와 유사하지만, 실제로는 당신과 서버 제공자 사이의 일대일 관계에 가깝다. 이러면 공유경제 운운하는 의미가 별로 없어지게 된다. 한 회사가 사용자에게 매월 컴퓨팅 파워의 일부를 제공하는 것은 공유 경제와 일치할 수 있지만, 기실 그보다는 스탈린주의적 배급 경제와 유사하다 해야 할 것이다. 이런 방식은 단기적인 정보 공유(예: 당신의 대학 조별과제 프로젝트를 팀원들과 공유하는 것. 간편하면 됐지 누가 신경이나 쓰겠는가?) 에는 유용할 수 있지만, 장기적인 프로젝트 유지 관리에는 적합하지 않으며, 특히 프로그램 사용자의 자유를 존중하려 할 때는 더욱 그렇다.

그러므로, 벤처 캐피탈의 반짝거리는 투자와 홍보를 받지 않는 이상 당신 코드베이스의 가치에 딱히 관심이 없을 회사의 서버에 의존하기보다는, 프로젝트에 정말로 관심이 있는 자발적 참여 노드들로 하여금 서버로써 기여할 수 있도록 하는 것이 적절할 것이다.

Microsoft는 2018년에 GitHub을 인수했다. 또한 OpenAI의 49%를 소유하고 있다. 우리의 미래 예언자 중 한 명인 작가 Philip K. Dick은, 기업들이 너무 많은 권력을 가질 때 나타나는 다양한 대안적 디스토피아 현실들을 보여주었다.

– Radicle User Guide

Radicle 시작하기

Radicle는 이미 자체적인 사용자 가이드(https://radicle.xyz/guides/user)를 제공하지만, 아직 초기 단계인 프로젝트이기 때문에 일부 영역에서는 부족함을 느낄 수 있다. 예를 들어, 비공개 리포지토리를 유지 관리하는 방법에 대한 지침은 가이드만 따라해서는 혼란을 겪기 쉽다. 또한 여러 Radicle ID를 다루는 방법도 명확하지 않아서 혼란스러울 수 있다. 이러한 격차를 메우고 특정 상황에서 더 명확한 해결책을 제공하기 위해, 나는 공식 사용자 가이드의 보완재로써 간단한 쿡북을 제공하려 한다.

먼저, 자동화된 스크립트를 사용하여 시스템에 Radicle을 설치한다. 반드시 Radicle 사이트에서 제공하는 인증된 스크립트를 사용할 것. 이 글만 보지 말고, 공식 가이드를 함께 보는 것이 타당하다.

$ curl -sSf https://radicle.xyz/install | sh

프로젝트마다 지정된 Identity와 그 Node를 사용하기

Radicle의 인증 방식(Account <=> Identity <=> SSH KeyPair)은 한 시스템 내에서 여러 ID를 관리할 수 있는 구조화된 방법이 필요함을 암시한다. 단일 Radicle ID로 모든 리포지토리를 관리하는 것은 보안상 좋은 관행이 아니리라.

Radicle의 가이드는 설치 후 단순히 rad auth 를 실행하라고 안내하는데, 이는 기본적으로 $HOME/.radicle 디렉토리 아래에 기본 설정과 키를 생성한다. 하지만, Radicle은 기본 위치에 ID가 없으면 $RAD_HOME 환경 변수를 사용한다. 따라서 여러 프로젝트와 ID를 안정적으로 관리하기 위해, direnv 를 사용하여 프로젝트별로 이 환경 변수를 설정할 것을 권장한다. 이렇게 하면 각 프로젝트에 맞는 올바른 노드와 ID로 작업하고 있음을 항상 확인할 수 있으며, 더 깔끔하고 체계적인 워크플로를 제공한다.

따라서, 가이드처럼 바로 rad auth 를 실행하는 대신, 아래와 같이 git/radicle 프로젝트를 초기화하자.

# 먼저 direnv를 https://direnv.net/에서 설치하고 설정할 것.
cd your_project_dir
git init

echo "export RAD_HOME=$HOME/.radicle/identities/YOUR_PREFERRED_ID" > .envrc
direnv allow

rad auth  # 선택한 ID로 $RAD_HOME에 ID가 생성된다
rad node start  # 여기서 시작된 노드는 해당 ID에만 연결된다

git add .envrc
git commit -m "Radicle ID 설정 완료"

rad init  # 비공개 리포지토리를 원하면 --private 옵션 추가
git push rad master

커밋에 서명하기

Radicle 사용자 가이드에서는 SSH 키를 Git 커밋에 서명하는 데 사용할 수 있다고 권장하지만 (“By the way since your Radicle key is a valid SSH key, it can be used to sign Git commits since version Git 2.34.0…”), 이 부분은 사실상 필수적으로 강조될 필요가 있다. 프로젝트의 루트 디렉토리 안에서 direnv 로 설정한 $RAD_HOME 환경 변수가 유효하다는 전제 하에, 다음 명령어들을 입력하면 git 은 rad self --ssh-key 의 값을 참조하여, 프로젝트에서 사용되고 있는 radicle identity의 SSH 키로 모든 커밋을 서명하도록 설정될 것이다.

git config user.signingKey "$(rad self --ssh-key)"
git config gpg.format ssh
git config gpg.ssh.program ssh-keygen
git config gpg.ssh.allowedSignersFile .gitsigners
git config commit.gpgsign true

리포지토리 클론하기

Push를 했다면 당연히 리포지토리를 네트워크에서 클론할 수 있어야 한다. 절차는 간단하다. 우선 프로젝트의 리포지토리 식별자(RID)를 출력한다:

rad .
# 이 명령은 rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5 같은 값을 반환하며, 이 값이 당신의 RID다.

그런 다음, 다른 시스템에서 이 RID를 사용해 프로젝트를 클론한다:

rad clone <RID>
# 예: rad clone rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5

공개 리포지토리의 경우, 이토록 간단하다. 하지만 당신이 비공개 리포지토리를 운영하고 싶다면, 즉 한정된 참가자들만 프로젝트에 참여시키고 싶다면 조금 더 알아야 할 것이 있다.

Seeding

이미 언급했듯이 Radicle 네트워크는 자발적인 기여자 노드들로 구성되며, 네트워크와 상호작용하려면 무조건 노드를 시작해야 한다. 예를 들어, 위에서 실행한 리포지토리 클론 또한 노드를 통해서 이루어진다. rad clone 이 실행될 때, 커튼 뒤에서는 rad seed 가 먼저 실행된다. 그렇다면 seeding은 무엇인가? 당신 또한 해당 프로젝트의 호스팅에 간단히 참여하게 된다는 뜻이다. 공식 가이드는 다음과 같은 도덕률을 선언했다.

To seed is to give back. By seeding repositories on the Radicle network, you offer bandwidth, storage, and data availability to Radicle users.

이것이 의미하는 바는 꽤 깊다. 일반적인 Git 호스팅 기업의 경우, 다른 사용자들이 당신의 프로젝트에 붙여주는 Star 혹은 Upvote는, SNS의 좋아요 버튼과 차이가 없다. 그 좋아요 버튼이 당신의 코드베이스에 직접적으로 줄 수 있는 도움은, 제의적 가치를 완전히 배제한, 순수한 전시적 가치의 상승이다. 최종적으로 알고리즘의 선택을 받은 프로젝트는, 아주 많은 사람들에게 “보여질” 것이다. 그게 전부이며 궁극적 목표이다.

Radicle의 경우, Seeding이 Star를 대신한다. 참여자들은 맹목적으로 프로젝트의 전시적 가치를 인정하는 대신, 자신의 대역폭 일부를 그 프로젝트를 위해 내어줌으로써 데이터의 보존에 기여한다. 물론 보존은 전시적 가치 상승에도 도움을 준다. 하지만 그것이 최종 목표가 아니라는 것이 중요하다. 굳이 이름을 붙여 말하자면 아카이브적, 문헌학적 가치 상승이라 할 수 있겠다.

간단히 말해, Radicle에서 어떤 리포지토리 rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5 에 찬사를 보내기 위해서는 다음 명령을 실행하면 된다.

rad seed rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5

협업

기여자

GitHub과 같은 Git 호스팅 서비스를 사용하는 것은 편리하다. Pull Request를 보내고, 서로 팔로우하고, 다양한 기능을 제공받을 수 있다. 그러나 순수 Git 워크플로는 약간 다르다. Linux 커널 개발자들은 여전히 메일링 리스트를 통해 협업하는데, 이들은 Git 자체에 포함된 간단한 기능들만으로도 잘만 모든 것을 관리한다 (다음 StackOverflow 논의를 보면 Pull Request의 기원을 알 수 있을 것이다 – https://stackoverflow.com/a/20289778).

어찌 되었건 우리가 여기서 얻을 수 있는 결론은, Radicle의 경우 딱히 웹 인터페이스에 로그인해서 PR을 검토할 필요가 없다는 것이다. Git만을 사용하여 관리자에게 패치를 보내고 검토받으려면, Awesome Philosophy의 CONTRIBUTE를 참고하자.

# 새로운 anomalous-data-897af 브랜치 생성
git checkout -b anomalous-data-897af

# 변경 사항 추가
git add test.md

# 커밋 생성
git commit -m "add test markdown file"

# 패치 브랜치로 푸시
git push rad HEAD:refs/patches

여기서, 변경 사항들, 그러니까 커밋은 원격 rad 로 보내진다. HEAD 는 현재 작업 중인 브랜치의 가장 최신 커밋을 나타낸다. 마지막 push 명령은 이 커밋을 리모트 rad 의 refs/patches 이름공간에 푸시한다. 이후 리포지토리 관리자가 이 패치를 확인하고, 필요에 따라 병합할 수 있다.

관리자

리포지토리 기여자들이 제출한 모든 패치를 나열하려면 다음 명령을 실행한다:

git ls-remote rad refs/patches/*

관심 있는 패치를 찾았다면 git fetch 명령을 실행한다:

git fetch rad refs/patches/<patch-name>

그런 다음, git checkout FETCH_HEAD 명령을 통해 해당 패치 브랜치로 체크아웃할 수 있다. 여기서 FETCH_HEAD 는 마지막으로 fetch한 커밋을 가리킨다.

git diff FETCH_HEAD
# 여기서 FETCH_HEAD == refs/remotes/rad/patches/<patch-name>
git merge FETCH_HEAD

# 먼저 브랜치를 테스트해보고 싶다면, git checkout refs/remotes/rad/patches/<patch-name>

git push

Magit(https://magit.vc/)과 같은 편리한 Git 시각화 도구를 사용하면, 유명한 Git 호스팅 웹사이트에서처럼 패치 차이를 쉽게 확인할 수 있다.