탈중앙화 소셜 네트워크인 Bluesky는 어떻게 작동할까?
글쓴이:Steve Klabnik
번역: Kurt Pan
저는 BlueSky가 어떻게 작동하는지에 대해 매우 흥미를 느끼고 있습니다. 이 글에서는 그 설계와 제가 이해하는 설계의 핵심 원칙들에 대해 설명할 것입니다. 저는 BlueSky 팀의 일원이 아니기 때문에 여기서 말하는 내용은 오직 제 개인적인 견해일 뿐입니다.
시작하겠습니다.
BlueSky는 왜 존재하는가?
현재 BlueSky 웹사이트는 다음과 같이 말하고 있습니다.
소셜 미디어는 너무나 중요해서 소수 기업들이 독점적으로 통제해서는 안 됩니다. 우리는 모두가 인터넷의 미래를 함께 만들어갈 수 있도록 개방된 소셜 인터넷 기반을 구축하고 있습니다.
매우 큰 방향성입니다.
좋습니다, 멋진 아이디어죠. 하지만 정확히 무엇을 의미할까요? 현재로서 BlueSky는 트위터와 마스토돈(Mastodon)과 유사한 마이크로블로깅 앱입니다. 그렇다면 이것이 과연 저 방향성과 어떻게 연결될까요? 사실 BlueSky가 마이크로블로그 앱인 것은 맞지만, 이야기의 전부는 아닙니다. BlueSky는 '인증 전송 프로토콜'(AT, ATP 또는 'atproto'라고도 부름)의 실현 가능성을 증명하기 위한 최초의 애플리케이션입니다. 즉, BlueSky는 '건축물'이고 atproto는 '개방된 소셜 인터넷 기반'인 셈입니다.
중요한 점은, BlueSky 또한 하나의 회사라는 사실입니다. 어떤 사람들은 "자, 우리가 회사가 통제할 수 없을 만큼 거대한 무언가를 만들고 있다!"라고 말하는 회사를 보며 의심을 품을 수도 있습니다. 저는 이러한 태도가 건강하다고 생각하지만, 제 답은 바로 atproto입니다.
이 두 요소 사이의 상호작용이 중요한데, 먼저 atproto부터 살펴보고, 그 위에 BlueSky가 어떻게 구축되었는지를 논의하겠습니다.
이건 암호화폐인가요?
우리가 반드시 먼저 제거해야 할 오해는 이것입니다. 만약 당신이 "오, 이름이 '어떤 프로토콜'인 분산 네트워크구나"라고 듣게 된다면, 머릿속에서 "이게 암호화폐야?"라는 경고음이 울릴지도 모릅니다.
걱정하지 마세요. 이건 암호화폐가 아닙니다. 다만 암호화폐 분야에서 유래한 일부 기술을 사용하긴 하지만, 블록체인, DAO, NFT 혹은 그런 종류의 다른 아무것도 아닙니다. 단지 암호학이나 메르클 트리 같은 것들 정도입니다.
atproto 개요
AT 프로토콜(AT Protocol)은 이렇게 설명합니다.
인증 전송 프로토콜(atproto)은 대규모 분산형 소셜 애플리케이션을 위한 연합 프로토콜이다.
하나씩 분석해보겠습니다.
연합 프로토콜
atproto는 연합(federated) 구조입니다. 이는 시스템의 각 구성 요소들이 여러 사람이 운영할 수 있으며 서로 소통할 수 있음을 의미합니다.
연합 구조 선택은 atproto가 "어느 한 조직의 통제를 받을 수 없다"는 약속을 지키는 데 핵심적인 부분입니다. 다른 요소들도 있지만, 이 점은 문제 해결을 위한 중요한 접근 방식입니다.
대규모를 위한
확장하려면 확장을 염두에 두고 설계되어야 합니다. atproto는 시스템의 부하를 처리 능력이 있는 참여자에게 더 많이, 그렇지 않은 참여자에게는 덜 분산시키는 몇 가지 흥미로운 선택을 했습니다. 이를 통해 atproto 위에서 동작하는 애플리케이션은 대규모 사용자 집단에도 문제없이 확장될 수 있습니다.
적어도 그렇게 되기를 바랍니다. 최근 BlueSky 사용자가 500만 명에 도달했으며, 트위터 초기보다 훨씬 안정적으로 운영되고 있습니다. 많은 소셜 앱만큼 크지는 않지만, 결코 무시할 수 없는 규모입니다. 실제 운영 결과는 지켜봐야겠습니다.
분산형 소셜 애플리케이션
atproto는 사람들과 연결되기 위한 것이므로 소셜 애플리케이션에 초점을 맞추고 있습니다. 현재는 100% 공개이며, DM(다이렉트 메시지)이나 메시징 기능은 없습니다. 이유는 연합 시스템에서 비공개 기능을 구현하는 것이 매우 까다롭기 때문이며, 문제가 심각한 상태로 출시하기보다는 차라리 완벽하게 준비된 후에 제공하는 것을 선호합니다. 따라서 지금은 공개하고 싶은 것만 사용하는 것이 좋습니다.
이러한 애플리케이션은 '분산(distributed)'되어 있는데, 이는 앱 자체가 네트워크 상에서 직접 실행된다는 의미입니다. 'BlueSky 서버'라는 개념은 없으며, atproto를 실행하는 서버들이 서로 메시지를 주고받고 있으며, 여기에는 BlueSky의 메시지뿐 아니라 사용자가 만든 다른 애플리케이션의 메시지도 포함됩니다.
이게 전부라면 심각한 확장성 문제가 발생할 수 있습니다. 예를 들어, 제가 BlueSky에 새 게시물을 올릴 때마다 제 모든 팔로워의 저장소(repository)에 게시물을 보내야 한다면, 매우 비효율적이며 인기 있는 저장소를 운영하는 비용이 극도로 커질 것입니다. 이를 해결하기 위해 '릴레이(relay)'라는 추가 서비스가 있습니다. 릴레이는 네트워크 내 정보를 집계하여 다른 릴레이에 대량으로 빠르게 전달합니다. 실제로 앱 뷰(app view)는 저장소를 직접 조회하지 않고 릴레이를 조회합니다. 제가 게시물을 올리면, 제 저장소는 팔로워들의 저장소에 개별적으로 알리지 않습니다. 대신 제 저장소가 릴레이에 알리고, 팔로워들은 앱 뷰를 사용해 릴레이 출력을 필터링하여 자신이 팔로우하는 사람들의 게시물만 표시합니다. 이는 일반적으로 릴레이가 매우 크고 운영 비용이 많이 들 수 있음을 의미하지만, 소규모 사용자 하위 집합의 게시물만 전파하는 작은 릴레이를 운영할 수도 있습니다. 릴레이는 네트워크 전체 콘텐츠를 보여줄 필요는 없으며, 물론 규모가 큰 릴레이는 그렇게 할 것입니다.
아스키 형식의 다이어그램은 다음과 같습니다.
이것이 atproto의 핵심을 이해하는 데 필요한 전부입니다. 사람들이 데이터를 생성하고, 데이터는 네트워크에서 공유되며, 애플리케이션은 데이터와 상호작용할 수 있습니다.
다른 유형의 서비스도 도입되고 있으며 앞으로 더 추가될 수 있습니다. 그러나 그 전에 현재 형태가 된 배경을 이해하기 위해 몇 가지 이념적 원칙을 설명해야 합니다.
'표현의 자유와 도달'이란 무엇인가?
atproto는 소셜 애플리케이션을 위한 것이므로, 사람들을 연결할 뿐 아니라 연결을 끊는 것도 고려해야 합니다. 검열(censorship)은 모든 소셜 애플리케이션의 핵심 요소입니다. '무검열'이라는 것도 여전히 하나의 검열 전략입니다. BlueSky는 이 문제를 다룰 때, 사람들이 검열에 대해 다양한 선호를 가지고 있다는 점과, 대규모에서 검열을 관리하는 것이 어렵다는 점을 인정합니다.
따라서 이 프로토콜은 '표현의 자유와 도달(free speech and reach)' 방식의 검열 정책을 채택합니다. 지금까지 설명한 내용은 '표현(speech)' 계층에 속합니다. 이 계층은 순전히 네트워크상에서 복제되는 콘텐츠에만 관심 있으며, 그 콘텐츠의 의미론(semantics)은 신경 쓰지 않습니다. 검열 도구는 '도달(reach)' 계층에 속합니다. 즉, 모든 표현은 수용하지만, 자신이 보기 싫은 콘텐츠의 도달을 제한하는 방법을 제공합니다.
때때로 사람들은 BlueSky가 "완전한 표현의 자유"를 추구하거나 "검열을 하지 않는다"고 말합니다. 이것은 정확하지 않습니다. 검열 도구는 프로토콜 자체에 이미 코딩되어 있어서 네트워크의 모든 콘텐츠, 심지어 BlueSky 외부의 애플리케이션에서도 사용할 수 있습니다. 또한, 자신의 검열자를 선택할 수 있기 때문에 다른 사람이 선택한 검열이나 검열 부재의 영향을 받지 않을 수 있습니다. 하지만 앞서 나간 감이 있으니, 이제 피드 생성기(feed generator)와 라벨러(labeler)에 대해 이야기하겠습니다.
피드 생성기란 무엇인가?
대부분의 소셜 애플리케이션은 콘텐츠 '피드'라는 개념을 가지고 있습니다. atproto에서는 이를 자체적인 서비스 유형으로 분리한 것으로, '피드 생성기(feed generator)'라고 부릅니다. 피드의 전형적인 예는 "컴퓨터야, 내가 팔로우하는 사람들의 게시물을 시간 역순으로 보여줘"입니다. 최근 알고리즘 기반 피드가 소셜 네트워크에서 인기를 끌면서, 일부 비기술 사용자는 이를 그냥 '알고리즘'이라고 부르기도 합니다.
피드 생성기는 릴레이로부터 나오는 방대한 데이터를 받아, 생성기의 기준에 따라 필터링하고 정렬된 콘텐츠 목록을 표시합니다. 그리고 이 피드를 다른 사용자들과 공유할 수도 있습니다.
실제 예로, 제가 가장 좋아하는 피드 중 하나는 Quiet Posters입니다. 이 피드는 자주 게시물을 올리지 않는 사람들의 글을 보여줍니다. 이를 통해 주요 피드에 묻혀버리는 사람들의 활동을 쉽게 파악할 수 있습니다. 또 'the ‘Gram'은 사진이 첨부된 게시물만 보여주는 피드이며, 'My Bangers'는 당신의 가장 인기 있는 게시물을 보여줍니다.
저에게 있어 이는 BlueSky가 다른 마이크로블로깅 도구들과 차별화되는 핵심 기능 중 하나입니다. 완전한 사용자 선택권이죠. 원한다면 나만의 알고리즘을 만들 수 있고, 쉽게 다른 사람과 공유할 수 있습니다. BlueSky를 사용하면 이러한 피드를 모두 이용할 수 있고 팔로우할 수 있습니다.
피드 생성기는 최근 atproto에 추가된 기능이므로 아직 완벽하지 않을 수 있으며, 앞으로 변경될 가능성도 있습니다. 지켜보겠습니다. 제 경험상 잘 작동하고 있지만, 아직 낮은 수준의 기술 세부 사항까지는 파고들지 않았습니다.
라벨러란 무엇인가?
라벨러는 콘텐츠나 계정에 라벨(태그)을 붙이는 서비스입니다. 사용자는 특정 라벨러를 구독한 후, 게시물에 붙은 라벨에 따라 경험을 조정할 수 있습니다.
라벨러는 자신이 원하는 어떤 방식이라도 사용할 수 있습니다. 게시물에 특정 알고리즘을 적용해 자동으로 라벨을 붙이거나, 누군가가 좋아요/싫어요를 눌러 수동으로 처리하거나, 라벨 서비스 운영자가 원하는 임의의 방법을 사용할 수 있습니다.
라벨러의 예로는 블랙리스트가 있습니다. 보고 싶지 않은 사용자가 작성한 게시물에 라벨을 붙이는 방식이죠. 또 다른 예는 '직장 부적합 콘텐츠 필터'인데, 게시물의 이미지에 특정 알고리즘을 적용해 직장에서 부적절한 콘텐츠라고 판단되면 라벨을 붙입니다.
라벨러는 이미 존재하지만, 현재는 누구나 직접 운영할 수는 없습니다. BlueSky가 자체 라벨러를 운영하고 있지만, 외부 버전은 아직 없다고 알고 있습니다. 그러나 언젠가 가능해진다면, 커뮤니티가 자신들이 원하는 유형의 라벨을 붙이는 서비스를 운영할 수 있을 것입니다.
atproto에서 검열은 어떻게 작동하는가?
이 모든 것을 종합하면, 검열이 어떻게 작동하는지 알 수 있습니다. 피드 생성기는 라벨에 따라 피드를 변환할 수 있으며, 앱 뷰는 라벨러에게 문의해 피드를 가져온 후 변환을 적용할 수 있습니다. 이러한 방식은 취향에 따라 혼합하고 매칭할 수 있습니다.
이것은 당신이 애플리케이션 간에만 검열 경험을 선택할 수 있는 것이 아니라, 애플리케이션 내부에서도 선택할 수 있음을 의미합니다. 직장용 피드는 적절한 콘텐츠만 보고 싶지만, 다른 피드에서는 부적절한 콘텐츠도 포함하고 싶습니까? 가능합니다. 누군가를 블랙리스트에 올려 전 세계와 공유하고 싶으십니까? 가능합니다.
이러한 검열 도구는 애플리케이션 수준이 아닌 네트워크 수준에서 작동하기 때문에, 실제로 다른 시스템보다 훨씬 더 나아갑니다. 누군가 atproto 위에 인스타그램 클론을 만든다면, 당신의 블랙리스트 라벨러도 그곳에서 사용할 수 있습니다. 왜냐하면 당신의 블랙리스트 라벨러는 프로토콜 수준에서 작동하기 때문입니다. 한 곳에서 누군가를 차단하면, 원한다면 모든 곳에서 차단할 수 있습니다. 아마도 다른 애플리케이션마다 다른 검열 결정을 구독할 수도 있겠죠. 이것은 전적으로 당신의 선택입니다.
이 모델은 Mastodon처럼 특정 '인스턴스(instance)'에 '계정(account)'을 두는 다른 연합 시스템과 크게 다릅니다. 그래서 많은 사람들이 "내 인스턴스가 연합 해제(de-federated)되면 어떻게 되는가?" 같은 질문을 하는데, 이런 질문은 atproto 맥락에서는 완전히 의미가 맞지 않습니다. 특정 기준에 따라 일련의 사용자를 차단함으로써 같은 목적을 달성할 수 있습니다. 어쩌면 특정 PDS를 마음에 들지 않아서 해당 PDS의 게시물을 무시하고 싶을 수도 있지만, 이는 오직 당신의 선택이며, 당신 계정이 위치한 '서버 소유자'가 결정하는 것이 아닙니다.
그렇다면 가정 서버가 없을 경우 정체성(identity)은 어떻게 작동할까요?
정체성과 계정 이식성은 어떻게 작동하는가?
정체성이 어떻게 작동하는지에 대한 세부사항이 너무 많아서, 제가 중요하다고 생각하는 부분에만 집중하겠습니다. 논란의 여지가 있는 부분에도 초점을 맞출 것입니다.
핵심은, 사용자가 '비중앙화 식별자(DID)'라 불리는 정체성 번호를 갖는다는 것입니다. 제 DID는 다음과 같습니다. did:plc:3danwc67lo7obz2fmdg6jxcr . 팔로우 환영합니다! 물론 대부분의 경우 이 인터페이스를 보게 되지는 않습니다. 정체성은 또한 핸들(handle), 즉 도메인 이름도 포함합니다. 예상대로 제 핸들은 steveklabnik.com 입니다. 저는 BlueSky에서 @steveklabnik.com 으로 게시물을 올리는 것을 보게 될 것입니다. 도메인이 없는 사람도 이 시스템을 사용할 수 있습니다. BlueSky에 가입하면 이름을 선택할 수 있고, 핸들은 @username.bsky.social 가 됩니다. 저는 처음에 @steveklabnik.bsky.social 로 시작했다가 @steveklabnik.com 으로 전환했습니다. 하지만 DID는 안정적이기 때문에 제 팔로워들에게는 전혀 방해되지 않았습니다. 사용자 인터페이스에서 핸들이 업데이트된 것만 보였을 뿐입니다.
도메인을 핸들로 사용하려면, PDS가 생성한 DID를 가져와 해당 도메인의 DNS에 TXT 레코드를 추가하면 됩니다. 만약 당신이 DNS란 무엇인지 모르는 사람이라면, 정말 부럽습니다. 하지만 BlueSky가 NameCheap과 제휴한 덕분에 기술 지식 없이도 도메인을 등록하고 핸들로 사용하도록 설정할 수 있습니다. 그러면 도메인을 핸들로 사용해 앱에 로그인할 수 있고 모든 것이 잘 작동합니다.
또한 이것이 BlueSky가 진정한 '계정 이식성(account portability)'을 제공하는 방식입니다. 사실 '계정'이라는 개념 자체가 거의 존재하지 않기 때문입니다. 주어진 DID를 사용하는 사람은 자신이 생성한 콘텐츠에 암호학적으로 서명하며, 이 콘텐츠는 네트워크 상에서 복제됩니다. '당신의 계정'은 실제로 차단될 수 없습니다. 왜냐하면 누군가 당신이 접근할 수 없는 키를 강제로 막아야 하기 때문입니다. 만약 당신의 PDS가 실패하고 새로운 PDS로 이전하고 싶다면, 네트워크 자체에서 PDS 콘텐츠를 다시 채워넣고, 네트워크에 PDS가 이동했음을 알리는 방법이 있습니다. 이것은 오늘날 운영되는 어느 유사 서비스와도 극명하게 대비되는 진정한 의미의 계정 이식성입니다.
하지만.
세부 사항이 모든 것을 결정짓고, 저는 이것이 BlueSky와 atproto에 대한 더욱 의미 있는 비판 중 하나라고 생각합니다.
DID를 생성하는 '방법(method)'에는 여러 종류가 있습니다. BlueSky는 도메인 기반의 did:web 방법을 지원합니다. 이 방법에는 몇 가지 단점이 있으며, 저는 아직 완전히 이해하지 못해 설명할 수 없습니다. 아마도 나중에 DID에 대해 깊이 있게 글을 쓰게 될 것입니다.
이러한 약점들 때문에 BlueSky는 did:plc라는 자체 DID 방법을 구현했습니다. plc는 'placeholder(임시 저장소)'를 의미하며, 무기한 지원할 계획이 있다고 해도 여전히 약점이 있습니다. 그 약점은 올바른 정보를 해석하기 위해 BlueSky가 운영하는 서비스에 질의해야 한다는 점입니다. 예를 들어, 제 DID 조회는 이렇습니다. 이는 BlueSky가 네트워크 설계상 불가능한 수준으로 더 심각하게 당신을 차단할 수 있다는 의미이며, 일부 사람들은 이를 매우 심각한 문제라고 생각합니다.
그렇다면 이 결함은 치명적인가요? 저는 그렇지 않다고 생각합니다. 첫째, 정말로 그것에 참여하고 싶지 않다면 did:web을 사용할 수 있습니다. 물론 다른 이유로 인해 이것이 완벽하지는 않지만, did:plc를 만든 이유가 바로 그 때문입니다. 하지만 이 문제는 해결할 수 있습니다.
또 다른 점은, 제 개인적인 견해로는 BlueSky 팀이 이 통제에 대한 불편함을 충분히 이해하고 있으며, 다른 더 나은 시스템이 개발된다면 전환할 수 있도록 설계했다는 것입니다. 또한 미래에 did:plc의 거버넌스를 어떤 합의 모델로 이전하는 것도 가능하다고 밝혔습니다. 선택지는 존재합니다. 게다가 다른 사람들도 did:plc 서비스를 운영하고 사용할 수 있습니다(원한다면).
저는 이를 현실적으로 사안을 처리한 사례라고 생각하지만, 다른 사람들은 이를 악랄한 음모라고 볼 수도 있습니다. 여러분 스스로 판단하셔야 합니다.
BlueSky는 어떻게 atproto 위에 구축되었는가?
이제 atproto를 이해했으니 BlueSky를 이해할 수 있습니다. BlueSky는 atproto 네트워크 위에 구축된 애플리케이션입니다. 그들은 앱 뷰를 운영하며, 이 앱 뷰를 사용하는 웹 애플리케이션도 운영합니다. 또한 웹 앱을 통해 등록한 사용자를 위해 PDS를 운영하고, 이러한 PDS와 통신하는 릴레이도 운영합니다.
그들은 두 개의 렉시콘(lexicon)을 공개했습니다. 하나는 com.atproto.* 용이고, 다른 하나는 app.bsky.* 용입니다. 전자는 네트워크 상의 모든 애플리케이션이 필요로 하는 저수준 작업을 위한 것이고, 후자는 BlueSky 고유의 작업을 위한 것입니다.
하지만 BlueSky의 훌륭한 점 중 하나는, 아무도 이런 딱딱한 기술 세부사항을 알지 못해도 BlueSky를 사용할 수 있어야 한다는 제품 목표입니다. 인스턴스가 없기 때문에 '계정을 만들려면 인스턴스를 선택해야 한다'는 과정이 존재하지 않으며, 이식성 덕분에 호스팅 업체가 망가져도 이전할 수 있고, 팔로워들은 아무런 피해도 입지 않습니다.
다른 사람들은 어떻게 atproto 위에 애플리케이션을 만들 수 있는가?
atproto 애플리케이션을 만들려면 렉시콘을 생성하면 됩니다. 그런 다음 앱 뷰를 운영하여 렉시콘 관련 네트워크 데이터를 처리하고, 사용자가 자신의 렉시콘을 사용하는 PDS에 데이터를 쓸 수 있도록 해야 합니다.
저도 직접 해보는 것을 고려하고 있습니다. 지켜보겠습니다.
마치며
좋습니다, 기술적인 측면에서 본 atproto와 BlueSky의 작동 방식에 대한 개요는 여기까지입니다. 저는 이 설계가 매우 교묘하다고 생각합니다. 또한 atproto와 BlueSky를 분리해서 바라보는 것이 매우 의미 있다고 생각합니다. 네트워크가 '킬러 앱(killer app)'을 갖는다는 것은 그것을 사용할 이유를 제공하는 동시에, atproto가 실제 애플리케이션을 만들기에 충분히 좋은지 확인하는 테스트이기도 하니까요.
앞으로 이 모든 것에 대해 더 말할 기회가 있을 것이라 믿습니다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
