조금 과장해서 얘기하면, 문서들이 아래와 같이 쓰는 것처럼 보입니다.

"derivation에 있는 derivation이 derivation을 만들어 저장소에 derivation을 남긴다."

이게 무슨 말인가 싶은데, 의미가 조금 더 명확히 보이게 쓰면, 아래와 같습니다.

"derivation 생성식에 있는 derivation 함수가 derivation 객체를 만들어 derivation 파일 .drv에 저장한다."

아래는 처음 derivation을 보는 분들이 아닌, derivation이 저처럼 약간 모호한 분들과 의견을 나누기 위한 글입니다.

---

닉스의 derivation

"derivation은 패키지 빌드를 위한 모든 정보가 들어 있는 명세서"라는 간단한 설명만으로 넘어 가기엔, 중요한 개념을 담고 있다고 보입니다.

hello/default.nix

{ pkgs ? import <nixpkgs> {} }:
pkgs.hello

hello 패키지에 의존하는 somePackage/default.nix 파일에 아래 줄이 있습니다.

hello = import ../hello { inherit pkgs; };

엄밀히 얘기하면 import하고 있는 hello/default.nix의 pkgs.hello는, 평가가 끝나고 나온 결과물 derivation이 아직 아닙니다.

nixpkgs는 derivation를 생성할 표현식, 즉 derivation이나 .drv가 아니라, derivation 생성식 .nix들의 모음입니다. nixpkgs에 가져온 해당 식을 평가(nix-instantiate)하면, derivation이 만들어집니다. .drv 파일은, 이 걸, 나중에 또 계산(평가)하지 않기 위해 /nix/store에 남기는 derivation 캐싱 파일입니다.

"결과적으로 닉스는 실제 패키지도, derivation도 아닌 필요한 의존성들을 derivation 생성식들의 관계로 표현해 놓고, 최종 겉모양은 하나의 derivation 생성식이 하나의 패키지를 표현하게 된다."

거꾸로 접근해 보면, 보통 그냥 derivation이라 말하는 것은 derivation 객체라고 부를 수 있으며, .drv파일의 내용을 런타임에 메모리에 올린 derivation 데이터 타입 객체를 의미한다고 볼 수 있습니다.

---

대부분의 문서들이 derivation 생성식과 derivation을 구별하지 않고 써서, 초반에 derivation 개념 잡는 걸 방해하는 것 아닌가 싶어요. derivation은 derivation 생성식을 평가해서 나온 데이터 구조체일 뿐이니, 이를 구별하지 않고 쓰는 게 이해는 갑니다만,

지금 위와같이 상상하고 파는 이유는, "닉스는 분명 함수형이고, 선언형이라 했으니, 함수로 패키지를 표현하고, 함수들의 합성으로 최종 패키지(만드는 방법)를 표현할 것이다"로 상상하고 접근하니, derivation을 엮어 놓는 것이 아닌 derivation 생성식 - 함수로 엮어 놓는 게 중요한 차이점으로 보입니다.

사실, 그냥 넘어가도 될 것 같은데, 닉스 코드를 언어로 읽어 머릿속 인터프리팅하는데, 저는 은근 위와 같은 명확함이 필요합니다. 아마도 다른 분들도, 위 내용을 먼저 명확히 하고, 진도를 나간다면, 좀 더 자연스럽게 체계가 잡히지 않을까 생각이 듭니다.

잘못된 방향이 보이면 댓글 부탁드립니다.

※ 처음에 hello.drv 파일이 C 프로젝트의 .o 중간 파일처럼, 기계가 보기 위한 바이너리 파일쯤으로 생각했는데, 실제 모양은 아래와 같습니다.

Derive([("out","/nix/store/n131z2zya6ifx050b8q3biymx2jxfdwi-hello","","")],[("/nix/store/029h9shccppyiw1l7qsk6xp0grxgzzbb-stdenv-linux.drv",["out"]),("/nix/store/20vwa6qpx8w3ar66x1fmrjlwy86c7b71-bash-4.4-p23.drv",["out"])],["/nix/store/9krlzvny65gdc8s7kpb6lkx8cd02c25b-default-builder.sh","/nix/store/m8x2zsc2awjyhwq1fw65czpkikifxq3x-source"],"x86_64-linux","/nix/store/hrpvwkjz04s9i4nmli843hyw9z4pwhww-bash-4.4-p23/bin/bash",["-e","/nix/store/9krlzvny65gdc8s7kpb6lkx8cd02c25b-default-builder.sh"],[("buildInputs",""),("buildPhase","gcc -o hello ./hello.c"),("builder","/nix/store/hrpvwkjz04s9i4nmli843hyw9z4pwhww-bash-4.4-p23/bin/bash"),("configureFlags",""),("depsBuildBuild",""),("depsBuildBuildPropagated",""),("depsBuildTarget",""),("depsBuildTargetPropagated",""),("depsHostHost",""),("depsHostHostPropagated",""),("depsTargetTarget",""),("depsTargetTargetPropagated",""),("doCheck",""),("doInstallCheck",""),("installPhase","mkdir -p $out/bin; install -t $out/bin hello"),("name","hello"),("nativeBuildInputs",""),("out","/nix/store/n131z2zya6ifx050b8q3biymx2jxfdwi-hello"),("outputs","out"),("patches",""),("propagatedBuildInputs",""),("propagatedNativeBuildInputs",""),("src","/nix/store/m8x2zsc2awjyhwq1fw65czpkikifxq3x-source"),("stdenv","/nix/store/sm7kk5n84vaisqvhk1yfsjqls50j8s0m-stdenv-linux"),("strictDeps",""),("system","x86_64-linux")])

---

뉴스 보면서 글 작성하다, 결론이 나고 올립니다.

※ 2025-04-08추가 모든 정보가 확정된 derivation과 구별하기 위해 derivation 생성식이란 말을 썼는데, 유명한 글인 Nix pills 에서 package expression 이란 말을 접했습니다. 이 말과 같은 뜻으로 사용했습니다. (derivation함수만을 가리키는 말이 아니라, 이 함수를 부르기까지의 모든 절차를 포함한 표현식을 의미하기 위해 사용했습니다.)

명령줄 인터페이스(CLI)는 컴퓨터와 상호작용하는 가장 오래된 방식 중 하나다. 그리고 이 인터페이스를 지배하는 것은 셸 언어다. 그런데 흥미로운 점은 셸 언어가 일반적인 프로그래밍 언어들과는 상당히 다른 설계 철학을 따른다는 것이다. 한 마디로 요약하자면, 셸 언어는 때로 “추함”을 받아들여야 한다.

간결함의 미학

Bash나 zsh와 같은 전통적인 셸을 보자. grep -r "error" /var/log | wc -l와 같은 명령은 암호처럼 보일 수 있지만, 타이핑하는 데 몇 초밖에 걸리지 않는다. 이러한 간결함은 우연히 생긴 것이 아니다. 셸 환경에서는 사용자가 빠르게 입력하고, 결과를 확인하고, 다시 명령을 수정하는 반복적인 워크플로우가 일반적이다. 여기서 핵심은 “대화형” 경험이다.

PowerShell의 딜레마

PowerShell은 마이크로소프트가 셸의 개념을 재정의하려 한 야심찬 시도였다. 객체 지향적 파이프라인, 일관된 동사–명사 구문, 그리고 자세한 매개변수 이름 등은 모두 코드의 가독성과 유지보수성을 높이기 위한 설계였다.

그러나 다음 명령을 비교해보자:

Bash:

find . -name "*.log" -mtime -7 \
  | xargs grep "error" \
  | sort \
  | uniq -c

PowerShell:

Get-ChildItem -Path . -Filter *.log `
  | Where-Object {$_.LastWriteTime -gt (Get-Date).AddDays(-7)} `
  | ForEach-Object {Select-String -Path $_.FullName -Pattern "error"} `
  | Sort-Object `
  | Group-Object `
  | Select-Object Name,Count

PowerShell의 명령은 더 명확하고 자기 설명적이지만, 대화형 셸에서 빠르게 실험하고 반복하기에는 너무 장황하다. PowerShell 설계자들은 “추함”을 견디지 못하고 너무 많은 “다림질”을 해버린 것이다.

균형점 찾기

흥미롭게도 최근의 Nushell 같은 현대적인 셸은 이 교훈을 받아들이고 있다. 구조화된 데이터 처리와 같은 PowerShell의 장점을 가져오면서도, 대화형 사용에 필요한 간결함을 유지하려 노력한다.

셸 언어의 진정한 성공은 “아름다운 코드”와 “효율적인 상호작용” 사이의 균형에 달려 있다. 이는 때로 완벽한 문법이나 일관성보다는 실용적인 “추함”을 수용해야 함을 의미한다.

결론

프로그래밍 언어의 세계에서는 우아함과 일관성이 미덕이다. 그러나 셸의 세계에서는 타이핑 효율성, 속도, 그리고 대화형 적합성이 우선시된다. 이것이 바로 셸 언어가 때로 “추함”을 요구받는 이유다. PowerShell의 제한적인 성공은 이 기본적인 진실을 간과한 데서 비롯된 것일지도 모른다.

그리고 어쩌면 이것은 소프트웨어 설계 전반에 걸친 더 깊은 교훈을 담고 있다: 모든 도구는 그 사용 맥락에 맞게 설계되어야 한다는 것이다. 셸 언어에서는 그 맥락이 바로 키보드와 사용자 사이의 빠른 대화다.

닉스의 derivation은 코드 모양으로만 보면, 단순히 빌드에 필요한 속성의 집합이다. 별 거 아닌 것 같지만, 이 개념이 닉스의 핵심 아이디어다. 패키지를 빌드할 때 개입하는 널리고 널린 이펙트들을 깡그리 무시하고, 순수한 척 하는 derivation만으로 의존 관계를 표현한다. 만일, 패키지A가 패키지B에 의존한다면, A의 derivation이 B의 derivation에 의존한다고 표시해 둔다. 이렇게 derivation만 엮어서 패키지 빌드 명세서를 완성해 두고, 진짜 패키지가 필요한 순간이 오면, 그때서야 realize란 동작으로, 미뤄 놨던 이펙트들의 영향을 받게 된다. 모나드들의 runner처럼 말이다.

진짜 귀찮게 굴러야 하는 이펙트들은 나몰라라 하고, 고귀한 척 동작의 선언적인 명세서derivation만 조합해서 최종 결과 패키지를 위한 명세서를 작성하니 선언형 패키지 매니저라 부른다.

어떤 이펙트가 방해할지는 나중 문제고, 최종 패키지 명세서 자체는 순수한 derivation 조합으로만 구성해 놓고, 이들 이름에, 내용을 기반으로 계산한 해시까지 붙여 놓으니 절대 같은 이름, 다른 내용의 derivation이 생기지 않는다. 그래서 이들을 캐싱하기에도 좋고, 재현성도 올라간다고 한다.

다만, derivation에서 해시 베이스가 되는 필드의 점하나만 달라져도 해시값이 달라지니 다른 패키지가 되어버려, 디스크 용량이 좀 과하게 필요하고, 빌드 시간이 좀 과하게 걸리는 단점이 있다. 덕분에 쉴 시간이 자주 생긴다!

※ Nixpkgs를 보면 derivation이 아닌, derivation을 생성하는 표현식 .nix들의 모음으로 되어 있다.

(닉스 공부한지 몇 달 안된 사람의 노트입니다. 생각이 틀렸다면 알려주세요. 저는 혼자 공부한 내용들을 요약해서 블로그 혹은 닉스 NixOS.kr 디코에 올리고 제대로 길을 가고 있는지 검증 받곤 합니다.)

안녕하세요! 오늘은 제가 개발한 deno-task-hooks 패키지를 소개해 드리려고 합니다. 이 도구는 Deno 태스크를 Git 훅으로 사용할 수 있게 해주는 간단하면서도 유용한 패키지입니다.

어떤 문제를 해결하나요?

Git을 사용하는 개발 팀에서는 코드 품질 유지를 위해 커밋이나 푸시 전에 린트, 테스트 등의 검증 작업을 실행하는 것이 일반적입니다. 이러한 작업은 Git 훅을 통해 자동화할 수 있지만, 기존 방식에는 몇 가지 문제가 있었습니다:

• Git 훅 스크립트를 팀원들과 공유하기 어려움 (.git 디렉토리는 보통 버전 관리에서 제외됨)
• 각 개발자가 로컬에서 훅을 직접 설정해야 하는 번거로움
• 훅 스크립트의 일관성 유지가 어려움

deno-task-hooks는 이러한 문제를 해결하기 위해 Deno의 태스크 러너를 활용합니다. Deno 태스크는 deno.json 파일에 정의되어 버전 관리가 가능하므로, 팀 전체가 동일한 Git 훅을 쉽게 공유할 수 있습니다.

어떻게 작동하나요?

deno-task-hooks의 작동 방식은 간단합니다:

1. deno.json 파일에 Git 훅으로 사용할 Deno 태스크를 정의합니다.
2. hooks:install 태스크를 실행하면, 정의된 태스크들이 자동으로 .git/hooks/ 디렉토리에 설치됩니다.
3. 이후 Git 작업 시 해당 훅이 트리거되면 연결된 Deno 태스크가 실행됩니다.

설치 및 사용 방법

1. hooks:install 태스크 추가하기

먼저 deno.json 파일에 hooks:install 태스크를 추가합니다:

{
  "tasks": {
    "hooks:install": "deno run --allow-read=deno.json,.git/hooks/ --allow-write=.git/hooks/ jsr:@hongminhee/deno-task-hooks"
  }
}

2. Git 훅 정의하기

Git 훅은 hooks: 접두사 다음에 훅 이름(케밥 케이스)을 붙여 정의합니다. 예를 들어, pre-commit 훅을 정의하려면:

{
  "tasks": {
    "hooks:pre-commit": "deno check *.ts && deno lint"
  }
}

3. 훅 설치하기

다음 명령어를 실행하여 정의된 훅을 설치합니다:

deno task hooks:install

이제 Git 커밋을 실행할 때마다 pre-commit 훅이 자동으로 실행되어 TypeScript 파일을 검사하고 린트 검사를 수행합니다.

지원되는 Git 훅 종류

deno-task-hooks는 다음과 같은 모든 Git 훅 타입을 지원합니다:

• applypatch-msg
• commit-msg
• fsmonitor-watchman
• post-update
• pre-applypatch
• pre-commit
• pre-merge-commit
• pre-push
• pre-rebase
• pre-receive
• prepare-commit-msg
• push-to-checkout
• sendemail-validate
• update

이점

deno-task-hooks를 사용하면 다음과 같은 이점이 있습니다:

1. 간편한 공유: Git 훅을 deno.json 파일에 정의하여 팀 전체가 동일한 훅을 사용할 수 있습니다.
2. 설정 용이성: 새 팀원은 저장소를 클론한 후 한 번의 명령어로 모든 훅을 설치할 수 있습니다.
3. 유지 관리 용이성: 훅 스크립트를 중앙에서 관리하므로 변경 사항을 쉽게 추적하고 적용할 수 있습니다.
4. Deno의 안전성: Deno의 권한 모델을 활용하여 훅 스크립트의 보안을 강화할 수 있습니다.

마치며

deno-task-hooks는 작은 패키지이지만, Git과 Deno를 함께 사용하는 팀의 개발 경험을 크게 향상시킬 수 있습니다. 코드 품질 유지와 개발 워크플로우 자동화를 위해 한번 사용해 보세요!

패키지는 JSR에서 다운로드할 수 있으며, GitHub에서 소스 코드를 확인할 수 있습니다.

피드백과 기여는 언제나 환영합니다! 😊

인용: https://hackers.pub/@bgl/0195f0eb-88dd-77e3-a864-f0371e85b270

스태키지(Stackage)는 하스켈이 (의외로) 성공하여 해키지(Hackage)가 거대해지자, 그 거대함 때문에 발생하는 불편을 해소하는 한 방책으로 고안되었습니다. 그런데 당시에 해키지만큼 거대한 생태계를 갖추고 있으면서 동시에 "컴파일이 성공한다면 실행도 아마 성공할 것"이라는 훌륭한 속성을 갖는 언어는 달리 없었죠. 러스트가 있지 않으냐? 스태키지가 처음 나온 게 2012년입니다. 러스트는 아직 crates.io 도 자리잡기 전이었죠. (사실 이 시점의 러스트는 지금과는 언어 자체가 많이 다른 언어였고요.)

하스켈의 패키지 버저닝 정책에 따르면, 후방호환성 깨지는 변경은 반드시 메이저 버전을 올려야 하고, 마이너 버전만 올리는 변경은 후방호환성 유지될 때에만 가능합니다. 이런 정책 당연히 좋지만, 사람이 내용을 잘 숙지하고 지켜야 의미가 있습니다. 후방호환성을 깨면서 마이너 버전만 올리는 실수는 어떤 개발자든 할 수 있죠.

그런데 하스켈의 경우, 인간이 실수해도 기계가 잡아 줄 여지가 처음부터 매우 큰 언어이고, 예를 들어 어떤 함수가 핵미사일을 발사할 수 있는지 아닌지를 함수 실행 없이도 식별할 수 있는 언어라고들 하죠. 하스켈의 마지막 표준이 2010년에 나왔으니 2010년을 기준으로 하면, 당시 하스켈이 제공하는 "컴파일 시간 보장"의 범위는 그야말로 독보적이었습니다. (하스켈보다 더 강한 보장을 제공하는 언어들은 있었지만, 그만한 라이브러리 에코시스템이 없었고요.)

그래서 스태키지라는 모형이 의미가 있었습니다. A라는 패키지의 새 마이너 버전이 해키지에 올라오면, 스태키지에서 자동으로 가져갑니다. 스태키지는 같은 큐레이션에 포함된 다른 패키지들 중 A에 의존하는 패키지들을 추리고, 얘네한테 A의 새 버전을 먹여도 빌드가 잘 되는지 검사합니다. 이들 중 하나라도 깨지면? A 패키지는 해키지에서는 버전이 올랐으나, 스태키지에서는 버전이 오르지 않게 됩니다. 그리고 A 패키지의 제공자에게 자동으로 깃허브 멘션 알림이 갑니다!

("패키지 저자"와 "패키지를 스태키지에 제공하는 제공자"가 같은 사람이 아니어도 된다는 점도, 노동력의 효과적 분담에 한몫했습니다.)

이 모든 과정이 자동화되어 있는데, 이것만으로도 99.99%의 호환성 문제가 사라지고, 그러면서도 웬만한 라이브러리들은 충분히 최신 버전으로 쓸 수 있습니다. LTS와 나이틀리가 구분되어 있는 것도, LTS가 GHC 버전에 대응하여 여러 버전이 유지되는 것도, 실제 개발에서 아주 편리하고요.

스태키지가 개쩌는 부분은 "버저닝 정책에 완벽하게 부합하는데도 현실적으로 후방호환성 파괴를 일으키는" 변경점들도 잡아낸다는 것입니다. 아주 단순한 예시로 "많이 쓰이는 이름"이 있습니다. 예를 들어 어떤 라이브러리가 아주 널리 쓰이는데, 제공하는 네임 바인딩은 몇 개 안 되고, 그래서 대부분의 사용자가 그걸 그냥 전역 네임스페이스에 다 반입해서 쓴다고 칩시다. 어느 날 이 라이브러리가 process 라든지 f 같은 새 네임을 추가 제공하기 시작하면? 정책 규범에 따르면, 이것도 마이너 버전만 올려도 되는 변경점이 맞습니다. 하지만 현실에서는 많은 패키지들을 박살내겠죠. 언어를 막론하고 있을 수 있는 일인데, 이런 것들까지 스태키지에서 아주 높은 확률로 다 잡힙니다.

그리고... 이런 게 잘 된다는 것은 언어 그 자체의 특성도 있지만, 생태계 전체의 문화적인 특성도 있는데요. 하스켈도 라이브러리 제작자가 충분히 악독하다면, 컴파일러에게 안 잡히면서 인류문명멸망시키는 코드 변경을 얼마든지 슬쩍 끼워넣을 수 있습니다. 악의가 아니더라도 부주의로 후방호환성을 깰 수 있고요. 그런데 하스켈은 대부분의 라이브러리 설계자들이 "되도록 많은 것을 컴파일 시간에 잡고 싶다"라는 명확한 욕망으로 설계를 하는 경향이 뚜렷합니다. 그래서 호환성 문제는 웬만하면 스태키지 선에서 잡히고, 스태키지 큐레이션은 지난 10년 동안 실무상 아주 유용한 도구로 기능해 온 것이죠.

어지간하면 큐레이션만 잘 고르고 잘 갱신하면 되고, 종속성 목록에는 mypkg >= 2.1.1 && < 2.1.2 이런 거 하나도 관리 안 하고 그냥 mypkg 라고만 써도 된다는 것이, 솔직히 개짱편합니다. 다행히 지난 10년 동안 "문제의 소지는 컴파일 시간에 검출하는 게 좋다"라는 생각이 더 널리 받아들여져서, 다른 언어들도 이런 접근을 더 시도할 여지가 생긴 것 같군요.

올해 초부터 개발을 시작해 조금씩 개선해나가고 있는 기술 블로그의 1.1.1 버전이 공개됐습니다. 이번에는 게임 패치노트를 작성하는 느낌으로 글을 작성해 봤어요 😆

https://hoonieblog.xyz/blog/retro-hoonie-blog-v1.1.1

연합우주란 무엇일까?

X(구 Twitter)나 Instagram 같은 중앙화된 소셜 미디어에 지치셨나요? 데이터 프라이버시, 알고리즘 추천, 그리고 끊임없는 광고가 걱정되시나요? 여기 대안이 있습니다. 바로 연합우주(fediverse)입니다.

페디버스(fediverse)는 “federated”(연합된)와 “universe”(우주)를 합친 말로, 한국어권에서는 주로 “연합우주”라고 불립니다. 연합우주는 하나의 거대한 플랫폼이 아닌, 서로 대화할 수 있는 독립적인 서버(인스턴스)들의 네트워크입니다.

이게 어떻게 가능할까요? 바로 ActivityPub이라는 프로토콜 덕분입니다. 이 프로토콜은 서로 다른 소셜 미디어 플랫폼이 정보를 교환할 수 있게 해주는 공통 언어 같은 것입니다.

연합우주는 어떻게 작동하나요?

연합우주를 이해하는 가장 쉬운 방법은 이메일 시스템과 비교하는 것입니다.

Gmail 사용자가 네이버 메일 사용자에게 이메일을 보낼 수 있는 것처럼, Mastodon 사용자는 Misskey나 PeerTube 사용자와 소통할 수 있습니다. (Mastodon, Misskey, PeerTube가 무엇인지는 아래에서 설명하겠습니다. Gmail과 네이버처럼 서로 다른 서비스라고 보시면 됩니다.) 이것이 가능한 이유는 이 서비스들이 모두 같은 언어인 ActivityPub 프로토콜로 대화하기 때문입니다.

연합우주에서 사용자 ID는 @사용자명@인스턴스.도메인 형식으로 되어 있습니다. 이메일 주소와 매우 비슷하죠? 예를 들면:

• @honggildong@mastodon.social: mastodon.social 인스턴스 사용자
• @kimcheolsu@pixelfed.social: pixelfed.social 인스턴스 사용자
• @leeyeonghui@misskey.io: misskey.io 인스턴스 사용자

연합우주의 다양한 플랫폼 둘러보기

연합우주는 마치 여러 행성으로 이루어진 태양계 같습니다. 각 행성(플랫폼)은 고유한 특성을 가지고 있지만, 모두 같은 우주(연합우주)에 속해 있죠. 아래 표에서 주요 플랫폼들을 살펴봅시다:

플랫폼	설명	주요 인스턴스	특징
Mastodon	X(구 Twitter)와 유사한 마이크로블로깅 플랫폼	• mastodon.social (공식 인스턴스) • 우리.인생 (한국 중심)	500자 제한의 짧은 게시물, 해시태그, 컨텐츠 경고 기능
Misskey	일본에서 개발된 고도로 커스터마이징 가능한 마이크로블로깅 플랫폼	• misskey.io (가장 인기 있는 일본 인스턴스) • 스텔라 (한국 중심)	리액션, 게임, 채팅 등 다양한 기능, 높은 커스터마이징 가능성
Pixelfed	Instagram과 유사한 이미지 공유 플랫폼	• pixelfed.social (공식 인스턴스) • 추억:사진 (한국 중심)	스토리, 필터, 발견 기능
PeerTube	YouTube와 유사한 비디오 호스팅 플랫폼	• PeerTube.TV	P2P 기술로 비디오 스트리밍, 채널, 재생목록
WriteFreely	미니멀한 블로그 플랫폼	• write.as	Markdown 지원, 심플한 디자인
Lemmy	Reddit과 유사한 링크 애그리게이터 및 토론 플랫폼	• lemmy.ml • YuruLemmy (한국 중심)	커뮤니티(서브레딧과 유사), 투표, 토론

플랫폼 vs 인스턴스: 무슨 차이가 있을까?

연합우주를 이해할 때 흔히 혼동되는 개념이 있습니다. 바로 플랫폼(소프트웨어)과 인스턴스(서버)의 차이인데요.

플랫폼은 Mastodon, Misskey, Pixelfed와 같은 소프트웨어 자체를 의미합니다. 이들은 오픈 소스 소프트웨어로, 누구나 다운로드받아 설치할 수 있습니다.

인스턴스는 그 소프트웨어를 실행하는 개별 서버를 말합니다. mastodon.social과 우리.인생은 모두 Mastodon 플랫폼을 실행하는 별도의 인스턴스입니다.

Meta의 Threads 같은 일부 서비스는 플랫폼과 인스턴스가 동일합니다. 하지만 대부분의 연합우주 서비스는 여러 인스턴스로 구성되어 있습니다.

연합우주의 매력 포인트

연합우주가 갖는 몇 가지 매력적인 특징이 있습니다:

1. 탈중앙화: 특정 기업이 모든 데이터와 규칙을 통제하지 않습니다. 각 인스턴스는 자체 규칙을 가질 수 있습니다.
2. 데이터 주권: 자신의 데이터에 대한 더 많은 통제권을 가질 수 있습니다.
3. 검열 저항성: 한 인스턴스가 차단되더라도 다른 인스턴스로 쉽게 이동할 수 있습니다.
4. 커뮤니티 중심: 각 인스턴스는 특정 관심사나 지역 커뮤니티를 중심으로 형성됩니다.
5. 다양성: 다양한 플랫폼과 인스턴스가 존재하여 선택의 폭이 넓습니다.

연합우주 시작하기

연합우주에 참여하는 것은 생각보다 쉽습니다:

1. 자신의 관심사나 지역과 관련된 인스턴스를 선택합니다.
2. 해당 인스턴스에 계정을 만듭니다.
3. 다른 인스턴스의 사용자들을 팔로우하고 소통을 시작합니다!

한국 사용자라면 Mastodon 인스턴스인 우리.인생, Misskey 인스턴스인 스텔라 같은 한국어 중심 인스턴스를 추천합니다. 한국어 환경을 지원하고 한국 사용자들이 활발하게 활동하고 있어 시작하기 좋습니다.

아니면 이 글이 올라온 Hackers' Pub도 괜찮습니다. 소프트웨어 엔지니어들을 위한 소셜 미디어랍니다. 아직 개발중이라 공개적으로 가입을 받고 있지는 않습니다만, 홍민희에게 연락 주시면 계정을 생성해 드릴 수 있습니다.

ActivityPub: 연합우주의 심장

이제 개발자 관점에서 ActivityPub이 어떻게 작동하는지 자세히 살펴보겠습니다.

ActivityPub은 W3C에서 권장하는 표준 프로토콜로, 분산 소셜 네트워킹의 기반이 됩니다. ActivityStreams 2.0 데이터 형식을 기반으로 하며, 서로 다른 서버 간에 정보를 교환하는 방법을 정의합니다.

ActivityPub의 핵심 개념

ActivityPub은 몇 가지 핵심 개념으로 구성됩니다:

1. 액터(actor): 사용자, 그룹 등 행동을 수행할 수 있는 주체입니다. 각 액터는 고유한 URL을 가지며, 수신함(inbox)과 발신함(outbox)을 가집니다.
2. 액티비티(activity): 액터가 수행하는 행동으로, 게시물 작성, 댓글 좋아요, 다른 사용자 팔로우 등이 있습니다.
3. 객체(object): 텍스트 게시물, 이미지, 비디오와 같이 생성되고 공유되는 콘텐츠입니다.

실제 작동 방식

홍길동(@honggildong@mastodon.social)이 게시물을 작성하고, 이영희(@leeyeonghui@misskey.io)가 이에 반응하는 과정을 살펴봅시다:

1. 게시물 작성: 홍길동이 Mastodon에서 게시물을 작성합니다. Mastodon 서버는 이 게시물을 ActivityStreams 2.0 형식의 Create(Note) 액티비티로 변환합니다. 이 액티비티는 홍길동의 팔로워(이영희 포함)에게 전달됩니다.

2. 게시물 수신: 이영희의 Misskey 서버는 이 액티비티를 받고 처리하여 이영희의 타임라인에 홍길동의 게시물을 표시합니다.

3. 상호작용: 이영희가 게시물에 좋아요를 누르면, Misskey 서버는 Like(Note) 액티비티를 생성하여 홍길동의 Mastodon 서버로 보냅니다. 홍길동은 이영희가 자신의 게시물을 좋아했다는 알림을 받게 됩니다.

마치 다른 언어를 사용하는 사람들이 통역사를 통해 대화하는 것과 비슷하죠? ActivityPub이 바로 그 통역사 역할을 합니다.

ActivityPub의 실제 메시지 들여다보기

개발자로서 실제 ActivityPub 메시지가 어떻게 생겼는지 궁금하실 텐데요. 몇 가지 예시를 살펴봅시다:

1. 사용자 프로필(액터) 정보

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://w3id.org/security/v1"
  ],
  "id": "https://mastodon.social/users/honggildong",
  "type": "Person",
  "preferredUsername": "honggildong",
  "name": "홍길동",
  "summary": "연합우주의 개척자",
  "inbox": "https://mastodon.social/users/honggildong/inbox",
  "outbox": "https://mastodon.social/users/honggildong/outbox",
  "followers": "https://mastodon.social/users/honggildong/followers",
  "following": "https://mastodon.social/users/honggildong/following",
  "publicKey": {
    "id": "https://mastodon.social/users/honggildong#main-key",
    "owner": "https://mastodon.social/users/honggildong",
    "publicKeyPem": "-----BEGIN PUBLIC KEY-----\n...\n-----END PUBLIC KEY-----"
  },
  "icon": {
    "type": "Image",
    "mediaType": "image/jpeg",
    "url": "https://mastodon.social/system/accounts/avatars/000/000/001/original/avatar.jpg"
  }
}

이 JSON 데이터는 홍길동의 프로필 정보를 담고 있습니다. 사용자 이름, 소개, 프로필 사진 URL, 그리고 중요한 inbox와 outbox URL이 포함되어 있죠.

2. 게시물 작성 액티비티

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://mastodon.social/users/honggildong/statuses/123456/activity",
  "type": "Create",
  "actor": "https://mastodon.social/users/honggildong",
  "published": "2025-02-21T14:30:00Z",
  "to": [
    "https://www.w3.org/ns/activitystreams#Public"
  ],
  "cc": [
    "https://mastodon.social/users/honggildong/followers"
  ],
  "object": {
    "id": "https://mastodon.social/users/honggildong/statuses/123456",
    "type": "Note",
    "content": "<p>연합우주에 오신 것을 환영합니다! #fediverse #연합우주</p>",
    "published": "2025-02-21T14:30:00Z",
    "attributedTo": "https://mastodon.social/users/honggildong",
    "to": [
      "https://www.w3.org/ns/activitystreams#Public"
    ],
    "cc": [
      "https://mastodon.social/users/honggildong/followers"
    ],
    "tag": [
      {
        "type": "Hashtag",
        "href": "https://mastodon.social/tags/fediverse",
        "name": "#fediverse"
      },
      {
        "type": "Hashtag",
        "href": "https://mastodon.social/tags/연합우주",
        "name": "#연합우주"
      }
    ]
  }
}

이것은 홍길동이 게시물을 작성했을 때 생성되는 Create(Note) 액티비티입니다. 게시물 내용, 해시태그, 공개 범위 등이 포함되어 있습니다.

3. 팔로우 액티비티

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://misskey.io/users/leeyeonghui/follow/1234",
  "type": "Follow",
  "actor": "https://misskey.io/users/leeyeonghui",
  "object": "https://mastodon.social/users/honggildong"
}

이영희가 홍길동을 팔로우할 때 생성되는 Follow 액티비티입니다. 단순하죠?

ActivityPub 서버 구현하기: 개발자를 위한 팁

직접 ActivityPub 서버를 구현하고 싶다면 다음 단계를 따라야 합니다:

1. 액터 구현: 사용자 프로필 정보를 ActivityStreams 형식으로 제공합니다.
2. 수신함과 발신함 설정: HTTP 엔드포인트를 만들어 액티비티를 받고 전송합니다.
3. 서명 및 인증: HTTP Signatures를 사용하여 요청을 서명하고 검증합니다.
4. 액티비티 처리: 다양한 액티비티 유형(Create, Follow, Like 등)을 처리하는 로직을 구현합니다.
5. 데이터 저장: 사용자, 게시물, 액티비티 등의 정보를 데이터베이스에 저장합니다.
6. 연합 정책 구현: 어떤 인스턴스와 연합할지, 어떤 컨텐츠를 허용할지 등을 설정합니다.

개발을 시작하기 전에 Mastodon, Misskey 같은 기존 구현체의 코드를 살펴보는 것이 도움이 됩니다. 처음부터 모든 것을 구현하는 것보다 Fedify 같은 프레임워크를 활용하는 것도 좋은 방법입니다.

WebFinger: 사용자를 찾는 방법

연합우주에서 @leeyeonghui@misskey.io 같은 사용자 ID를 어떻게 실제 ActivityPub 액터 URL로 변환할까요? 그 비밀은 WebFinger 프로토콜에 있습니다:

GET https://misskey.io/.well-known/webfinger?resource=acct:leeyeonghui@misskey.io

이 요청을 보내면 서버는 다음과 같은 응답을 반환합니다:

{
  "subject": "acct:leeyeonghui@misskey.io",
  "links": [
    {
      "rel": "self",
      "type": "application/activity+json",
      "href": "https://misskey.io/users/leeyeonghui"
    }
  ]
}

이제 https://misskey.io/users/leeyeonghui URL을 통해 사용자의 전체 프로필 정보를 얻을 수 있습니다. 마치 전화번호부에서 이름으로 전화번호를 찾는 것과 비슷하죠!

연합우주의 도전 과제와 미래

연합우주는 계속 성장하고 있지만, 몇 가지 도전 과제도 있습니다:

1. 확장성: 수많은 서버 간의 통신을 효율적으로 처리하는 것은 쉽지 않습니다.
2. 모더레이션: 각 인스턴스가 자체 규칙을 가지므로 콘텐츠 조정에 일관성이 부족할 수 있습니다.
3. 발견성: 중앙화된 플랫폼에 비해 새로운 사용자나 콘텐츠를 찾기 어려울 수 있습니다.
4. 사용자 경험: 일부 플랫폼은 아직 UI/UX 측면에서 개선이 필요합니다.

그러나 Threads와 같은 주요 서비스들이 ActivityPub을 채택하기 시작하면서, 연합우주의 미래는 밝아 보입니다. 개발자로서, 이런 성장하는 생태계에 참여할 수 있는 기회가 많이 있습니다.

마무리

연합우주와 ActivityPub은 중앙화된 소셜 미디어의 대안으로서 점점 더 주목받고 있습니다. 사용자에게 더 많은 통제권을 부여하고, 다양하고 풍부한 온라인 경험을 제공하는 연합우주의 세계는 계속해서 확장되고 있습니다.

개발자로서, 여러분은 이 새로운 탈중앙화된 웹의 생태계에 기여할 수 있습니다. 기존 애플리케이션에 ActivityPub 지원을 추가하거나, 완전히 새로운 서비스를 만들거나, 현재의 도전 과제를 해결하는 솔루션을 개발할 수 있습니다.

한국 개발자들의 참여가 늘어나면 한국 사용자들을 위한 더 다양하고 풍부한 서비스가 생길 것이고, 이는 더 건강하고 다양한 인터넷 문화를 만드는 데 기여할 것입니다.

그럼, 연합우주로의 여행을 시작해 보시는 건 어떨까요?

Hackers' Pub을 포함하여 페디버스에 입문한 여러분 중 누군가는 막막한 생각이 들 수도 있습니다. 특히 지인의 Pool이 없는 상황이거나 혹은 Fediverse라는 개념 자체가 낯설 수록이요.

먼저 인스턴스라는 개념도 낯설게 느껴지거니와, 어떤 사람을 팔로할 지도 아예 생태계에 쌩으로 입문하는 입장에서는 시작을 하는 것 자체가 난해합니다.

Hackers' Pub을 포함한 ActivityPub 프로토콜을 사용하는 서비스들의 장점은 Bluesky, Mastodon, Misskey 어디에든 걸쳐있는 사람들과 하나로 연결되는 경험을 누릴 수 있다고 언급한 적은 있었습니다만, 이러한 장점을 어떻게 누릴 수 있는지도 알기는 어려울 겁니다.

보통은 트위터나 혹은 다른 알고리즘 기반의 추천을 해주는 여러 서비스들은 좋아하는지 취향에 맞는지와는 상관없이 일단 추천하긴 하지만, 페디버스는 국내 생태계 한정으로는 추천을 하기가 쉽지 않은 것 또한 사실이긴 합니다. 하지만, 해외개발자 Pool은 굉장히 넓은 것이 자명합니다. 물론, 이것도 역시 추천을 하기가 쉽지 않습니다. 여러분이 혹시 단골로 찾아보는 개발자 블로그가 있다면 Mastodon 계정이 보이는 경우를 최소 두 자릿수는 준하게 보실 수 있을 것이긴 합니다.

아무튼, 페디버스 생태계에도 소프트웨어 종사자인 여러분이 읽을만한 피드는 준비되어 있습니다. 팔로해볼 수 있는 여러 계정들을 예시로 들어서 소개해볼까 합니다.

개발자들이 모여있는 인스턴스

어떤 마스토돈 인스턴스를 이용할 수 있는지는 **여기**에도 잘 설명되어 있습니다. 개인적으로 추천하는 마스토돈 인스턴스는 아래와 같습니다.

국내

• silicon.moe -- 이공계열에 종사하는 사람들을 위한 한국어권 마스토돈 인스턴스입니다.
• Hackers' Pub -- 개발자를 위한 블로깅 서비스입니다. ActivityPub 프로토콜을 지원하여서 ActivityPub 프로토콜을 지원하는 페디버스에서 구독이 가능합니다.

해외

• hachyderm.io -- IT 업계 종사자를 위한 마스토돈 인스턴스입니다. 대부분의 유명한 개발자들이 여기에 몰려있다고 봐도 됩니다.
• emacs.ch -- Emacs 에디터를 사용하는 사람들을 위한 마스토돈 인스턴스입니다.
• functional.cafe -- 함수형 개발자를 위한 마스토돈 인스턴스입니다.
• genserver.social -- Erlang/Elixir 개발자를 위한 Akkoma 인스턴스입니다.
• ruby.social -- Ruby 개발자를 위한 마스토돈 인스턴스입니다.
• mtd.pythonasia.org -- 아시아권의 Python 개발자를 위한 마스토돈 인스턴스입니다.
• fosstodon.org -- 오픈소스 개발자를 위한 마스토돈 인스턴스입니다. Python Software Foundation, Libre Office 등 오픈소스 프로젝트의 공식계정들이 많이 있습니다.
• hci.social -- HCI 연구자들을 위한 마스토돈 인스턴스입니다. Princeton HCI에서 운영하고 있습니다.
• vt.social -- 개발 분야 버츄얼 유튜버를 위한 마스토돈 인스턴스입니다. Asahi Lina, Luna가 공동 운영하고 있습니다.

Who to follow

Twitter/Threads에서는 자체적인 추천 알고리즘을 통해 어떤 계정을 팔로하면 괜찮을지 제안을 하기도 합니다. 하지만, 마스토돈은 그런 기능 쪽으로는 미비하다시피합니다.

개발 관련 정보를 구독하고 싶은 분들의 입장에서는 굉장히 치명적일 수도 있습니다. 아래에서는 어떤 개발자에게든 팔로할 것을 권장하는 계정들을 소개합니다.

개발 관련 뉴스

• Geeknews Bot -- GeekNews의 피드를 실시간으로 받아볼 수 있습니다.
• Hackernews
  • Hacker News 500 -- Hacker News 에서 500 포인트 받은 글들을 볼 수 있습니다.
  • Hacker News 100 -- Hacker News 에서 100 포인트 받은 글들을 볼 수 있습니다.
  • Hacker News 50 -- Hacker News 에서 50 포인트 받은 글들을 볼 수 있습니다.
• Lobsters -- Lobsters는 Hacker News 보다는 좀 더 소프트웨어 개발/컴퓨터 사이언스에 초점이 맞춰진 글들이 올라옵니다.
  • Twitter 공식 계정도 있었지만, 트위터의 Bot 관련 정책 변경으로 인해 2023년 5월 3일부로 운영이 중단되었습니다.
• discu.eu Weekly newsletter - 각종 분야별로 newsletter를 받아볼 수 있습니다.
  • Python weekly, Haskell weekly 등등의 마스토돈 공식 계정이 있습니다.

오픈소스 컨트리뷰터

• Hong minhee -- Hackers' Pub, Hollo, Fedify 등 v페디버스 생태계에서 다양하고 재밌는 것들을 개발하고 계시는 분입니다.
• Eugen Rochko -- Mastodon 코어 컨트리뷰터입니다.
• Rob Pike -- Golang을 개발하신 그 분 맞습니다.
• Asahi Lina -- Asahi Linux에 기여하는 모습을 생중계하는 버츄얼 유튜버입니다.
• b0rks -- 개발자를 위한 N컷 만화를 연재하는 분입니다. Make Hard Things Easy라는 강연도 유명하니 한번씩은 보시는걸 권장합니다.

그 외에는...?

그 외에도, 관심이 가는 분야가 있으시다면 해당 분야 쪽 사람들이 모여있는 인스턴스를 눈여겨보시는 것을 권장합니다. 팔로우할 계정을 추천해주는 서비스를 찾으신다면 이것도 고려해보세요! (추천해주신 @rghw님 감사합니다.)

그 외에도 팔로할만한 계정이나 눈여겨볼만한 인스턴스가 있다면 댓글로 알려주세요! 여러분들의 댓글이 처음 입문하는 분들에게 도움이 될 수 있습니다!