기업도 정부도 통제할 수 없는 통신망, Nostr가 그리는 탈중앙 소셜의 구조

트위터의 소유권 변동과 정책 논란, 마스토돈과 블루스카이 같은 대안 서비스의 부상 속에서 소셜 프로토콜을 둘러싼 논의가 다시 뜨겁다. 이 흐름의 한 축에 Nostr(노스터)가 있다. Nostr는 완성된 제품이나 특정 회사의 서비스가 아니라, 클라이언트와 서버가 정보를 주고받는 방식을 규정한 하나의 개방형 표준이다. 이메일이나 HTTP처럼 여러 소프트웨어가 같은 언어로 대화할 수 있게 해주는 규약이며, 특정 앱을 반드시 써야만 참여할 수 있는 구조가 아니다. 같은 규약을 지원하는 여러 앱이 존재하고, 각 앱은 동일한 데이터를 저마다의 방식으로 보여준다.

핵심 구조: 스마트 클라이언트와 다중 릴레이

Nostr의 가장 큰 특징은 클라이언트와 서버의 관계에 있다. 기존 중앙집중 플랫폼이나 다른 프로토콜에서는 하나의 클라이언트가 하나의 서버와 통신한다. 반면 Nostr에서 클라이언트는 여러 서버, 즉 '릴레이(relay)'에 동시에 연결한다. 정보의 기본 단위는 암호학적으로 서명된 노트(note)다. 사용자는 자신의 앱에서 노트를 만들어 하나 이상의 릴레이에 발행한다. 여기서 클라이언트는 단순한 뷰어가 아니라 사용자의 대리인 역할을 한다. 어떤 릴레이에 언제 접속할지, 어떤 데이터를 요청할지를 상황과 사용자 설정에 따라 스스로 판단한다.

릴레이의 권한은 의도적으로 제한돼 있다. 릴레이는 노트의 내용을 바꿀 수 없다. 내용을 바꾸면 서명이 무효화되기 때문이다. 대신 릴레이는 무엇을 저장하고 얼마나 오래 보관할지를 스스로 정한다. 모든 사용자는 '키(key)'라 불리는 비밀 숫자로 표현되고, 모든 메시지에는 작성자와 진위를 증명하는 디지털 서명이 붙는다. 어떤 중앙 권위가 신원을 보증할 필요가 없다는 뜻이다. 이 암호학적 토대 덕분에 네트워크 효과가 단일 조직에 묶이지 않고, 한 집단이 다른 집단에게 일방적으로 해를 끼치기 어려운 구조가 만들어진다.

검열 저항의 실제 작동: 아웃박스 모델

Nostr가 강조하는 검열 저항성은 '아웃박스 모델(outbox model)'로 구체화된다. 예를 들어 어떤 사용자가 자신이 글을 발행할 릴레이 목록을 특별한 이벤트로 공지하면, 그를 팔로우하는 사람의 클라이언트는 그 공지를 조회해 해당 릴레이에 직접 접속한다. 만약 현재 쓰던 릴레이가 그를 차단하거나 서비스를 종료하면, 그는 친구가 운영하는 릴레이, 유료 서비스, 혹은 자신의 서버 등으로 옮겨 새 공지를 발행하기만 하면 된다. 팔로워의 클라이언트는 릴레이 목록 변경을 지속적으로 감시하다가 새 위치로 질의를 옮기므로, 네트워크 구성이 바뀌어도 글을 놓치지 않는다. 발행자 쪽에서도 팔로워 쪽에서도 클라이언트가 로컬 상태를 유지하며 능동적으로 반응하는 것이 이 모델의 핵심이다.

스팸·괴롭힘·확장성을 다루는 방식

Nostr는 스팸이나 괴롭힘 같은 난제에 완벽한 해법을 주장하지 않는다. 대신 접촉 면을 좁히는 전략을 쓴다. 기본 피드에서는 내가 팔로우한 사람의 글만 가져오므로 누군가 스팸을 밀어 넣을 수 없다. 다만 내 글에 달린 답글처럼 불특정 다수의 콘텐츠를 봐야 할 때가 까다롭다. 이 경우 '내가 팔로우하는 사람이 팔로우하는 사람'의 답글만 표시하거나, 결제를 요구하거나 사람 여부를 심사하는 등 '안전한' 릴레이의 글만 읽는 식으로 대응한다. 괴롭힘도 유사한 기법으로 다루되, 영속적 신원을 가진 특정 개인이라면 차단이 더 효과적이며, 공유 차단 목록 같은 방식으로 확장할 수 있다. 저자는 중앙집중 플랫폼도 스팸투성이라는 점을 지적하며, Nostr가 적어도 처음부터 회복력을 설계에 넣으려 한다는 점을 강조한다.

확장성 측면에서 Nostr는 그저 기본적인 클라이언트-서버 구조일 뿐이지만, 사용자가 수백 개 릴레이에 자연스럽게 분산되고 클라이언트가 여러 릴레이에 동시에 질의하는 구조 자체가 일종의 부하 분산 역할을 한다. 릴레이 운영 비용이 낮다는 점도 근거로 제시된다. 월 5달러짜리 서버로도 최소 수천 명을 수용할 수 있고, 네이티브 앱은 수백 개의 웹소켓 연결을 동시에 여는 것이 어렵지 않다는 것이다. 팔로우 피드를 제대로 구현하려면 어차피 로컬 데이터베이스에 이벤트를 저장하게 되는데, 이를 통해 요청을 일괄 처리하면 연결 부담도 완화된다.

마스토돈·블루스카이와의 차이, 그리고 남은 한계

저자는 경쟁 프로토콜과의 차이를 분명히 한다. 마스토돈은 암호화에 기반하지 않아 신원이 서버에 '소유'되고, 서버 운영자가 종료하거나 오작동하면 사용자가 무력해진다. 차단이나 다이렉트 메시지 같은 기능조차 다른 서버 운영자를 신뢰해야 한다. 블루스카이의 경우 클라이언트가 AppView를 신뢰하는 '멍청한' 존재로 가정되고 단일 릴레이에서 데이터를 받는 구조가 문제로 지목되는데, 저자는 블루스카이가 이를 해결하려 다중화하기 시작하면 결국 '단계만 더 많은 Nostr'가 된다고 본다. 검색에 대해서도 현실적 태도를 취한다. 세상 모든 것을 실시간으로 볼 수 있는 것은 애초에 자연스러운 일이 아니며, 전역 검색은 구글이 웹을 선별해 색인하듯 크롤러가 일부를 골라 색인해야 가능하다. 다만 팔로우한 사람의 글이나 내가 본 글은 텍스트라 용량이 작아 클라이언트가 로컬에 저장해 검색을 제공하기 쉽고, 이는 대부분의 검색 수요를 충족한다.

실무자가 유념할 지점은 Nostr가 아직 '스트레스 없이 구매할 수 있는 완성품'이 아니라는 저자 자신의 인정이다. 폐쇄형 그룹을 위한 NIP-29, 검열 저항 클라이언트의 표준으로 자리 잡은 아웃박스 모델처럼 규격은 계속 다듬어지는 중이며, 마켓플레이스·위키·git 기반 코드 협업·파일 호스팅 등 다양한 하위 프로토콜 실험이 진행되고 있다. 여전히 새로운 개발자와 얼리어답터가 프로토콜 흐름과 사용자 경험을 개선해야 하는 단계라는 뜻이다. 탈중앙 소셜을 검토하는 조직이라면 Nostr를 당장 도입 가능한 제품이 아니라, 릴레이 운영·클라이언트 설계·스팸 정책 같은 책임을 스스로 나눠 지는 아키텍처적 선택지로 이해하는 편이 정확하다.