@hongminhee洪 民憙 (Hong Minhee) 그래주시면 감사합니다. 😂 참고차 말씀드리면 스레드는 글 공개후 15분이내에만 수정할 수 있습니다.
洪 民憙 (Hong Minhee)
@hongminhee@hackers.pub · 345 following · 230 followers
Hi, I'm who's behind Fedify, Hollo, BotKit, and this website, Hackers' Pub!
Fedify, Hollo, BotKit, 그리고 보고 계신 이 사이트 Hackers' Pub을 만들고 있습니다.
Website- hongminhee.org
GitHub- @dahlia
Hollo- @hongminhee@hollo.social
DEV- @hongminhee
velog- @hongminhee
Qiita- @hongminhee
Zenn- @hongminhee
Matrix- @hongminhee:matrix.org
X- @hongminhee
@arkjunJuntai Park 아마 시간 제한은 안 둘 것 같긴 합니다. ㅎㅎㅎ
@hongminhee洪 民憙 (Hong Minhee) 그렇군요. 아무튼 블루스카이는 (다이렉트 메시지처럼) 비밀스러운 이야기는 무조건 중앙 서버를 거쳐서 가고, 탈중앙화 흉내를 내다 만 것에는 비밀스러울 수가 없다는 현재 모습이 여러모로 아이러니하게 느껴져요.
@fox여우 네, 저도 같은 감상입니다. 😔
가끔 해커즈펍에 단문 글 올렸다가, 나중에 오타 보일 때마다 부끄럽다. 스레드하던 습관때문에(?) 일단 올리고 다시 교정하는 편인데 수정을 못해서 그냥 놔두는 편. 부끄러움은 나의 몫😂 나의 오타 글을 보는 모든 분들에게 죄송스럽습니다.
다음부턴 미리보기로 오타도 확인하고 올려야지. (혼잣말) 😆
@arkjunJuntai Park 조만간 수정 기능도 추가하겠습니다…
@hongminhee洪 民憙 (Hong Minhee) 스레드는 페디버스 활성화 기능을 통해서 조금이나마 연합우주에 친화적인 방식으로 나아가는 듯 하네요. 반쪽 자리 느낌도 들기는 하지만요. (사실은 저도 스레드의 페디버스 활성화 기능을 통해 처음 입문하기는 했습니다. 😅)
@arkjunJuntai Park 사실 연합우주가 전반적으로 반기업 반자본 정서가 큰데, 그래서 Threads가 연합우주에 들어온다고 했을 때 말이 많았어요. (실제로 Threads를 미리 차단한 인스턴스들도 많습니다.) 그런데 뭐 어떻게든 조화되어 가는 것 같기도 합니다.
@hongminhee洪 民憙 (Hong Minhee) 트위터에서 블루스카이로 이동하는 것에 있어 (저의 주변 지인들 기준으로) 가장 큰 문턱으로 작동하는 것이 ’승인을 받은 팔로워에게만 게시글을 보여주는 기능‘이 없다는 점이라, ‘플텍계를 만들 수 있으면 블스로 넘어갈 거야‘라고 말씀하시는 분들도 있는데요. 이런 구조로 보건데 ‘블루스카이는 그 구조를 뜯어고치지 않는 이상 앞으로도 프로텍트 계정은 만들 수 없을 것이다’고 짐작해도 되는 걸까요?
@fox여우 제가 이해하기로는 아예 불가능하진 않더라도 단기간에 되지는 않을 것 같습니다. 근데 꽤 어려울 것 같아요.
@hongminhee洪 民憙 (Hong Minhee) 
@z9mb1wwj 저는 셸에서만 vi 를 사용하는 라이트 유저에 가깝긴 합니다만, 그래도 개발자들이 vi 에 대한 최소한의 사용방법은 숙지했으면 하는 바램은 있습니다. 😅 환경파일등 서버에서 즉시 수정할 일들이 그래도 종종 있다보니까요. 덤으로 브라우저에서의 vimmium 은 잘 쓰고 있습니다. 😆 https://github.com/philc/vimium
@arkjunJuntai Park @z9mb1wwj 저도 Vimium은 잘 쓰고 있습니다. ㅎㅎㅎ
@hongminhee洪 民憙 (Hong Minhee) 마스토돈 클라이언트 팬피(Phanpy)를 처음 써봤습니다. 인스턴스로 접속해서 보는 게 아니라 클라이언트로 연합우주를 이용하는 게 처음인데 좀 더 유려한 사용자 경험을 제공하네요! 그런데 해커스펍은 팬피와 연동이 안 되나요?
@curry박준규 네, Phanpy는 Mastodon API를 사용하는데 Hackers' Pub은 Mastodon API를 구현 안 해서 못 씁니다. Hollo는 Mastodon API도 구현해서 Phanpy랑 함께 쓸 수 있어요.
https://www.frontend.moe/posts/naver-2025-coding-test/ 팀네이버 코딩 테스트 후기를 개인 블로그에 올려두었습니다. 꾸준히 일할 수 있는 지속 가능한 소프트웨어 엔지니어로서의 삶을 지켜내고자 반성글을 쓰게 되었습니다(...)
@hongminhee洪 民憙 (Hong Minhee) 오 어떤 점에서 그렇게 보시나요? 저는 서비스와는 독립된 DID 사용할 수 있고, PDS를 개인이 관리할 수도 있다는 점에서 탈중앙화된 접근같다고 생각했어요. 제가 이제 막 ATProto를 보고 있어서 잘못 이해했을 수도 있어요😅
@parksbSimon Park 댓글을 쓰다가 지웠다 쓰다가 지웠다, 하다가 그냥 아예 글로 제대로 써보자 싶어서 써 보았습니다!
Bluesky는 X의 훌륭한 대안일 수 있지만, 연합우주의 대안은 아닙니다
최근 X(구 Twitter)를 떠나는 사람들이 늘면서 Bluesky에 대한 관심이 뜨겁습니다. Bluesky는 깔끔한 인터페이스와 과거 Twitter와 유사한 사용자 경험을 제공하며, 신뢰할 수 있는 이탈(credible exit)이라는 매력적인 개념을 내세워 X의 유력한 대안으로 떠오르고 있습니다. 하지만 Bluesky와 그 기반 프로토콜인 AT Protocol을 연합우주(fediverse)의 대안으로 보기에는 근본적인 차이가 존재합니다. 이 글에서는 Christine Lemmer-Webber 씨(@cwebber)의 날카로운 분석(〈Bluesky는 실제로 얼마나 탈중중앙화 되어 있나〉 및 〈답장: 답장: Bluesky와 탈중앙화〉)을 바탕으로, Bryan Newbold 씨(@bnewbold)의 반론(〈Bluesky와 탈중앙화에 대한 답변〉)을 충분히 고려하면서 Bluesky가 어째서 X의 대안은 될 수 있어도 연합우주의 대안은 될 수 없는지 이야기를 풀어볼까 합니다.메시지 전달 對 공유 힙: 근본적인 설계 차이 Bluesky와 연합우주의 가장 큰 차이점 중 하나는 설계입니다. 연합우주는 이메일이나 XMPP와 유사한 메시지 전달(message passing) 방식을 채택하고 있습니다. 이는 특정 수신자에게 메시지를 직접 전달하는 방식으로, 효율성이 높습니다. 예를 들어, 수많은 서버 중 단 몇 곳의 사용자만 특정 메시지에 관심을 있다면 해당 서버에만 메시지를 전달하면 됩니다. 비유하자면, 철수가 영희에게 편지를 보내려면 직접 영희의 집으로 편지를 보내고, 영희가 회신하고 싶으면 직접 철수에게 회신하는 것과 같은 방식입니다. 반면, Bluesky는 공유 힙(shared heap) 방식을 사용합니다. 이는 메시지를 특정 수신자에게 직접 보내는 대신, 모든 메시지를 중앙의 “릴레이”라는 곳에 저장하고, 관심 있는 사용자가 릴레이에서 자신에게 필요한 정보를 필터링하는 방식입니다. 이는 마치 모든 편지가 하나의 거대한 우체국(릴레이)에 쌓이고, 각자가 이 우체국에 방문하여 자신에게 관련된 편지를 직접 찾아야 하는 것과 같습니다. 이런 방식에서는 메시지가 직접 전달되지 않기 때문에, 답글이 어떤 메시지에 대한 것인지 파악하려면 모든 가능한 메시지를 알고 있어야 합니다. 이 설계는 데이터와 색인을 분리하여 유연성을 제공한다는 주장도 있지만, 필연적으로 대규모 중앙 집권화된 릴레이에 의존하게 되어 탈중앙화의 이상과는 거리가 멀어진다는 한계가 있습니다. 결국 Bluesky가 공유 힙 방식을 채택하고 중앙 집권화된 릴레이에 의존하게 되는 데에는 운영 비용이라는 현실적인 이유가 크게 작용합니다. Christine Lemmer-Webber 씨의 분석에 따르면, Bluesky에서 전체 네트워크 기록을 저장하는 릴레이를 운영하는 데에는 상당한 스토리지를 요구하며, 이는 빠르게 증가하고 있습니다. 2024년 7월에는 약 1TB의 저장 공간이 필요했지만, 불과 4개월 후인 11월에는 약 5TB로 증가했습니다. 상업용 호스팅 서비스 기준으로 이는 연간 수만 달러(약 $55,000)에 달하는 비용이 발생할 수 있습니다. 반면, 연합우주에서는 개인이나 소규모 단체가 Raspberry Pi와 같은 저렴한 장비로도 GoToSocial과 같은 소프트웨어를 실행하여 독립적인 노드를 운영할 수 있습니다. 물론 대규모 연합우주 인스턴스는 더 많은 비용이 들겠지만, Bluesky의 전체 릴레이 운영 비용과는 비교하기 어려울 정도로 저렴합니다. 이처럼 운영 비용의 현격한 차이는 Bluesky가 분산된 구조를 채택하기 어렵게 만들고, 결국 중앙 집권화된 릴레이에 의존하게 만드는 주요 원인이라고 볼 수 있습니다.전역 뷰에 대한 집착과 중앙 집권화의 심화 Bluesky는 댓글 누락과 같은 문제를 피하기 위해 네트워크 전체의 일관된 전역 뷰를 유지하는 데 집중하는 것으로 보입니다. 이러한 목표는 사용자 경험 측면에서 긍정적일 수 있지만, 필연적으로 중앙 집권화를 야기합니다. 대표적인 예가 차단 목록의 전체 공개입니다. 네트워크 전체의 일관성을 유지하기 위해 누가 누구를 차단했는지 모든 앱뷰가 알아야 하므로, 차단 정보가 공개되는 것입니다. 이는 개인 정보 보호 측면에서 심각한 우려를 낳을 수 있습니다. 단순히 누군가의 게시물을 보고 차단된 사람을 추측하는 것과, 네트워크에 “J.K. 롤링을 차단한 모든 사람”을 직접 질의할 수 있는 것 사이에는 큰 차이가 있습니다. 실제로 ActivityPub 개발 과정에서는 이런 문제를 고려하여 서버 간에 차단 활동을 전달하지 않도록 명시적으로 설계했습니다. 이는 차단한 사람이 차단당한 사람의 보복을 받을 위험을 줄이기 위함입니다. 반면 연합우주에서는 각 서버가 독립적으로 차단 정책을 시행하며, 사용자에게 더 많은 자율성을 제공합니다.AT Protocol과 개방형 표준으로서의 ActivityPub 연합우주의 핵심 프로토콜인 ActivityPub은 W3C의 채택 권고안으로, 개방형 표준입니다. 이는 누구나 자유롭게 구현하고 사용할 수 있으며, 다양한 소프트웨어 간의 상호 운용성을 보장합니다. 현재 페디버스 커뮤니티는 FEP를 중심으로 활발하게 프로토콜을 개선하고 발전시켜 나가고 있습니다. 반면, Bluesky의 AT Protocol은 아직 특정 사기업에 의해 주도되고 있으며, 개방형 표준으로서의 지위는 아직 확립되지 않았습니다. 이는 페디버스가 가진 확장성과 지속 가능성 측면에서 중요한 차이점이라고 할 수 있습니다.DM의 중앙화 Bluesky는 콘텐츠 주소 지정이나 이동 가능한 아이덴티티와 같은 탈중앙화 요소를 도입했지만, DM은 완전히 중앙화되어 있습니다. 사용자가 어떤 PDS를 사용하든, 어떤 릴레이를 사용하든 상관없이 모든 DM은 Bluesky 회사를 통해 전송됩니다. 이는 Bluesky가 아직 기능적으로 완전한 Twitter 대체품이 되기 위해 속도를 우선시했다는 증거입니다. Bluesky는 이 DM 시스템이 장기적인 솔루션이 아니라고 밝혔지만, 대부분의 사용자들은 이 사실을 인지하지 못하고 있으며 DM도 AT Protocol의 다른 기능처럼 작동한다고 가정합니다. 이러한 중앙화된 DM 구현은 “신뢰할 수 있는 이탈”이라는 Bluesky의 핵심 가치와도 모순됩니다. 만약 Bluesky社가 적대적인 인수나 정책 변경을 겪게 된다면, 사용자들의 개인 대화는 완전히 회사의 통제 하에 남게 됩니다.이동 가능한 아이덴티티와 DID: Bluesky 방식의 한계 Bluesky는 이동 가능한 아이덴티티(portable identity)를 핵심적인 장점 중 하나로 내세우며, 이를 위해 DIDs, 즉 분산 식별자를 활용합니다. 이는 사용자가 자신의 계정과 데이터를 다른 플랫폼으로 쉽게 이동할 수 있도록 하는 중요한 기능입니다. 하지만 Christine Lemmer-Webber는 AT Protocol이 채택한 did:web과 did:plc 방식이 여전히 DNS와 Bluesky社가 관리하는 중앙 집권화된 PLC 레지스트리에 의존하고 있어 완전한 사용자 통제하의 독립적인 아이덴티티를 제공하는지 의문을 제기합니다. 더 놀라운 점은 Bluesky社가 초기에 모든 계정에 대해 동일한 rotationKeys를 사용했다는 사실입니다. 이는 클라우드 HSM 제품이 키별로 비용을 청구해서 각 사용자에게 고유한 키를 제공하는 것이 금전적으로 비용이 많이 들었기 때문이라고 합니다. 이러한 접근 방식은 DIDs 시스템을 구축하는 근본적인 목표와 모순되는 것으로 보입니다. 중요한 점은 DIDs 기술 자체가 탈중앙화된 아이덴티티를 위한 잠재력을 가지고 있음에도, Bluesky와 AT Protocol이 채택한 특정 방식이 중앙 집권화된 요소에 의존한다는 것입니다. 블록체인 기반의 DIDs와 같은 진정으로 탈중앙화된 방식도 존재하지만, AT Protocol은 비교적 구현이 쉬운 did:web과 did:plc를 선택했습니다. 따라서 사용자가 Bluesky 생태계를 벗어나 자신의 아이덴티티를 완전히 독립적으로 관리하고자 할 때 제약이 발생할 수 있습니다. 또한 현재 시스템에서는 Bluesky社가 사용자의 키를 대신 관리하고 있어, 사용자가 현재는 Bluesky社를 신뢰하더라도 미래에 신뢰하지 않게 된 경우에도 여전히 회사에 의존해야 합니다. Bluesky社가 사용자를 대신하여 이동을 수행하도록 신뢰해야 하며, 심지어 Bluesky社가 사용자에게 향후 신원 정보를 제어할 권한을 위임하더라도 Bluesky社는 항상 해당 사용자의 키를 통제할 것입니다. 한편, 연합우주에서는 이미 노마딕 아이덴티티(nomadic identity)라는 개념을 통해 이동 가능한 아이덴티티에 대한 논의와 연구가 활발하게 진행되어 왔습니다. 이는 단순히 계정을 이전하는 것을 넘어, 사용자의 데이터와 관계, 심지어 평판까지도 자유롭게 이동할 수 있도록 하는 더 포괄적인 개념입니다. 《We Distribute》에 실린 기사 〈오, Zot! ActivityPub에 노마딕 아이덴티티가 도입된다〉에 소개된 Zot 프로토콜과 같은 기술은 이미 연합우주 안에서 이러한 노마딕 아이덴티티를 구현하기 위한 메커니즘을 제공하고 있습니다. 또한, FEP-ef61와 같은 제안을 통해 ActivityPub 자체를 개선하여 더 나은 이동 가능한 아이덴티티 기능을 추가하려는 노력도 진행 중입니다.그래서, 결론은? 결론적으로, Bluesky는 사용자 친화적인 인터페이스와 신뢰할 수 있는 이탈 기능을 통해 X의 훌륭한 대안이 될 수 있습니다. Bluesky는 콘텐츠 주소 지정 방식을 통해 노드가 다운되더라도 콘텐츠가 살아남을 수 있게 하는 등 연합우주가 아직 충분히 활용하지 못하는 몇 가지 강점도 가지고 있습니다. 하지만 중앙 집권화된 설계, 전역 뷰에 대한 집착으로 인한 부작용, 개방형 표준으로서의 한계, DM의 중앙화, 그리고 이동 가능한 아이덴티티 구현의 제한점 등 여러 측면에서 연합우주의 대안으로 보기는 어렵습니다. 연합우주는 메시지 전달 방식의 분산된 아키텍처, 낮은 참여 장벽, 개방형 표준 기반의 활발한 커뮤니티 개발, 그리고 사용자에게 더 많은 자율성과 통제권을 제공하는 철학을 바탕으로 구축된, 근본적으로 다른 종류의 탈중앙화 소셜 네트워크입니다. 또한, Bluesky社가 벤처 캐피털 자금을 확보함에 따라 “조직은 미래의 적이다”라는 그들의 자체 인식에도 불구하고, 투자자 수익과 플랫폼 성장이라는 상업적 압력이 진정한 탈중앙화 추구보다 우선시될 위험이 있습니다. 특히 유료 계정과 광고가 도입되면서 이러한 우려는 더욱 커질 수 있습니다. 따라서 Bluesky는 X를 대체할 수 있을지 모르지만, 연합우주가 제공하는 탈중앙화된 가치와 경험을 대체하기는 어려울 것이라고 생각합니다. 두 시스템은 근본적으로 다른 목표와 설계 철학을 가지고 있으며, 이상적으로는 서로를 보완하는 방향으로 발전해 나갈 수 있을 것입니다.
hackers.pub · Hackers' Pub
Link author: 洪 民憙 (Hong Minhee)@hongminhee@hackers.pub
Bluesky는 X의 훌륭한 대안일 수 있지만, 연합우주의 대안은 아닙니다
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
최근 X(구 Twitter)를 떠나는 사람들이 늘면서 Bluesky에 대한 관심이 뜨겁습니다. Bluesky는 깔끔한 인터페이스와 과거 Twitter와 유사한 사용자 경험을 제공하며, 신뢰할 수 있는 이탈(credible exit)이라는 매력적인 개념을 내세워 X의 유력한 대안으로 떠오르고 있습니다. 하지만 Bluesky와 그 기반 프로토콜인 AT Protocol을 연합우주(fediverse)의 대안으로 보기에는 근본적인 차이가 존재합니다. 이 글에서는 Christine Lemmer-Webber 씨(@cwebber)의 날카로운 분석(〈Bluesky는 실제로 얼마나 탈중앙화 되어 있나〉 및 〈답장: 답장: Bluesky와 탈중앙화〉)을 바탕으로, Bryan Newbold 씨(@bnewbold)의 반론(〈Bluesky와 탈중앙화에 대한 답변〉)을 충분히 고려하면서 Bluesky가 어째서 X의 대안은 될 수 있어도 연합우주의 대안은 될 수 없는지 이야기를 풀어볼까 합니다.
메시지 전달 對 공유 힙: 근본적인 설계 차이
Bluesky와 연합우주의 가장 큰 차이점 중 하나는 설계입니다. 연합우주는 이메일이나 XMPP와 유사한 메시지 전달(message passing) 방식을 채택하고 있습니다. 이는 특정 수신자에게 메시지를 직접 전달하는 방식으로, 효율성이 높습니다. 예를 들어, 수많은 서버 중 단 몇 곳의 사용자만 특정 메시지에 관심을 있다면 해당 서버에만 메시지를 전달하면 됩니다. 비유하자면, 철수가 영희에게 편지를 보내려면 직접 영희의 집으로 편지를 보내고, 영희가 회신하고 싶으면 직접 철수에게 회신하는 것과 같은 방식입니다.
반면, Bluesky는 공유 힙(shared heap) 방식을 사용합니다. 이는 메시지를 특정 수신자에게 직접 보내는 대신, 모든 메시지를 중앙의 “릴레이”라는 곳에 저장하고, 관심 있는 사용자가 릴레이에서 자신에게 필요한 정보를 필터링하는 방식입니다. 이는 마치 모든 편지가 하나의 거대한 우체국(릴레이)에 쌓이고, 각자가 이 우체국에 방문하여 자신에게 관련된 편지를 직접 찾아야 하는 것과 같습니다. 이런 방식에서는 메시지가 직접 전달되지 않기 때문에, 답글이 어떤 메시지에 대한 것인지 파악하려면 모든 가능한 메시지를 알고 있어야 합니다.
이 설계는 데이터와 색인을 분리하여 유연성을 제공한다는 주장도 있지만, 필연적으로 대규모 중앙 집권화된 릴레이에 의존하게 되어 탈중앙화의 이상과는 거리가 멀어진다는 한계가 있습니다.
결국 Bluesky가 공유 힙 방식을 채택하고 중앙 집권화된 릴레이에 의존하게 되는 데에는 운영 비용이라는 현실적인 이유가 크게 작용합니다. Christine Lemmer-Webber 씨의 분석에 따르면, Bluesky에서 전체 네트워크 기록을 저장하는 릴레이를 운영하는 데에는 상당한 스토리지를 요구하며, 이는 빠르게 증가하고 있습니다. 2024년 7월에는 약 1TB의 저장 공간이 필요했지만, 불과 4개월 후인 11월에는 약 5TB로 증가했습니다. 상업용 호스팅 서비스 기준으로 이는 연간 수만 달러(약 $55,000)에 달하는 비용이 발생할 수 있습니다.
반면, 연합우주에서는 개인이나 소규모 단체가 Raspberry Pi와 같은 저렴한 장비로도 GoToSocial과 같은 소프트웨어를 실행하여 독립적인 노드를 운영할 수 있습니다. 물론 대규모 연합우주 인스턴스는 더 많은 비용이 들겠지만, Bluesky의 전체 릴레이 운영 비용과는 비교하기 어려울 정도로 저렴합니다. 이처럼 운영 비용의 현격한 차이는 Bluesky가 분산된 구조를 채택하기 어렵게 만들고, 결국 중앙 집권화된 릴레이에 의존하게 만드는 주요 원인이라고 볼 수 있습니다.
전역 뷰에 대한 집착과 중앙 집권화의 심화
Bluesky는 댓글 누락과 같은 문제를 피하기 위해 네트워크 전체의 일관된 전역 뷰를 유지하는 데 집중하는 것으로 보입니다. 이러한 목표는 사용자 경험 측면에서 긍정적일 수 있지만, 필연적으로 중앙 집권화를 야기합니다. 대표적인 예가 차단 목록의 전체 공개입니다. 네트워크 전체의 일관성을 유지하기 위해 누가 누구를 차단했는지 모든 앱뷰가 알아야 하므로, 차단 정보가 공개되는 것입니다.
이는 개인 정보 보호 측면에서 심각한 우려를 낳을 수 있습니다. 단순히 누군가의 게시물을 보고 차단된 사람을 추측하는 것과, 네트워크에 “J. K. Rowling[1]을 차단한 모든 사람”을 직접 질의할 수 있는 것 사이에는 큰 차이가 있습니다. 실제로 ActivityPub 개발 과정에서는 이런 문제를 고려하여 서버 간에 차단 활동을 전달하지 않도록 명시적으로 설계했습니다. 이는 차단한 사람이 차단당한 사람의 보복을 받을 위험을 줄이기 위함입니다.
반면 연합우주에서는 각 서버가 독립적으로 차단 정책을 시행하며, 사용자에게 더 많은 자율성을 제공합니다.
AT Protocol과 개방형 표준으로서의 ActivityPub
연합우주의 핵심 프로토콜인 ActivityPub은 W3C의 채택 권고안으로, 개방형 표준입니다. 이는 누구나 자유롭게 구현하고 사용할 수 있으며, 다양한 소프트웨어 간의 상호 운용성을 보장합니다. 현재 페디버스 커뮤니티는 FEP를 중심으로 활발하게 프로토콜을 개선하고 발전시켜 나가고 있습니다. 반면, Bluesky의 AT Protocol은 아직 특정 사기업에 의해 주도되고 있으며, 개방형 표준으로서의 지위는 아직 확립되지 않았습니다. 이는 페디버스가 가진 확장성과 지속 가능성 측면에서 중요한 차이점이라고 할 수 있습니다.
DM의 중앙화
Bluesky는 콘텐츠 주소 지정이나 이동 가능한 아이덴티티와 같은 탈중앙화 요소를 도입했지만, DM은 완전히 중앙화되어 있습니다. 사용자가 어떤 PDS를 사용하든, 어떤 릴레이를 사용하든 상관없이 모든 DM은 Bluesky 회사를 통해 전송됩니다.
이는 Bluesky가 아직 기능적으로 완전한 Twitter 대체품이 되기 위해 속도를 우선시했다는 증거입니다. Bluesky는 이 DM 시스템이 장기적인 솔루션이 아니라고 밝혔지만, 대부분의 사용자들은 이 사실을 인지하지 못하고 있으며 DM도 AT Protocol의 다른 기능처럼 작동한다고 가정합니다.
이러한 중앙화된 DM 구현은 “신뢰할 수 있는 이탈”이라는 Bluesky의 핵심 가치와도 모순됩니다. 만약 Bluesky社가 적대적인 인수나 정책 변경을 겪게 된다면, 사용자들의 개인 대화는 완전히 회사의 통제 하에 남게 됩니다.
이동 가능한 아이덴티티와 DID: Bluesky 방식의 한계
Bluesky는 이동 가능한 아이덴티티(portable identity)를 핵심적인 장점 중 하나로 내세우며, 이를 위해 DIDs, 즉 분산 식별자를 활용합니다. 이는 사용자가 자신의 계정과 데이터를 다른 플랫폼으로 쉽게 이동할 수 있도록 하는 중요한 기능입니다. 하지만 Christine Lemmer-Webber는 AT Protocol이 채택한 did:web과 did:plc 방식이 여전히 DNS와 Bluesky社가 관리하는 중앙 집권화된 PLC 레지스트리에 의존하고 있어 완전한 사용자 통제하의 독립적인 아이덴티티를 제공하는지 의문을 제기합니다.
더 놀라운 점은 Bluesky社가 초기에 모든 계정에 대해 동일한 rotationKeys를 사용했다는 사실입니다. 이는 클라우드 HSM 제품이 키별로 비용을 청구해서 각 사용자에게 고유한 키를 제공하는 것이 금전적으로 비용이 많이 들었기 때문이라고 합니다. 이러한 접근 방식은 DIDs 시스템을 구축하는 근본적인 목표와 모순되는 것으로 보입니다.
중요한 점은 DIDs 기술 자체가 탈중앙화된 아이덴티티를 위한 잠재력을 가지고 있음에도, Bluesky와 AT Protocol이 채택한 특정 방식이 중앙 집권화된 요소에 의존한다는 것입니다. 블록체인 기반의 DIDs와 같은 진정으로 탈중앙화된 방식도 존재하지만, AT Protocol은 비교적 구현이 쉬운 did:web과 did:plc를 선택했습니다. 따라서 사용자가 Bluesky 생태계를 벗어나 자신의 아이덴티티를 완전히 독립적으로 관리하고자 할 때 제약이 발생할 수 있습니다.
또한 현재 시스템에서는 Bluesky社가 사용자의 키를 대신 관리하고 있어, 사용자가 현재는 Bluesky社를 신뢰하더라도 미래에 신뢰하지 않게 된 경우에도 여전히 회사에 의존해야 합니다. Bluesky社가 사용자를 대신하여 이동을 수행하도록 신뢰해야 하며, 심지어 Bluesky社가 사용자에게 향후 신원 정보를 제어할 권한을 위임하더라도 Bluesky社는 항상 해당 사용자의 키를 통제할 것입니다.
한편, 연합우주에서는 이미 노마딕 아이덴티티(nomadic identity)라는 개념을 통해 이동 가능한 아이덴티티에 대한 논의와 연구가 활발하게 진행되어 왔습니다. 이는 단순히 계정을 이전하는 것을 넘어, 사용자의 데이터와 관계, 심지어 평판까지도 자유롭게 이동할 수 있도록 하는 더 포괄적인 개념입니다. 《We Distribute》에 실린 기사 〈오, Zot! ActivityPub에 노마딕 아이덴티티가 도입된다〉에 소개된 Zot 프로토콜과 같은 기술은 이미 연합우주 안에서 이러한 노마딕 아이덴티티를 구현하기 위한 메커니즘을 제공하고 있습니다. 또한, FEP-ef61와 같은 제안을 통해 ActivityPub 자체를 개선하여 더 나은 이동 가능한 아이덴티티 기능을 추가하려는 노력도 진행 중입니다.
그래서, 결론은?
결론적으로, Bluesky는 사용자 친화적인 인터페이스와 신뢰할 수 있는 이탈 기능을 통해 X의 훌륭한 대안이 될 수 있습니다. Bluesky는 콘텐츠 주소 지정 방식을 통해 노드가 다운되더라도 콘텐츠가 살아남을 수 있게 하는 등 연합우주가 아직 충분히 활용하지 못하는 몇 가지 강점도 가지고 있습니다.
하지만 중앙 집권화된 설계, 전역 뷰에 대한 집착으로 인한 부작용, 개방형 표준으로서의 한계, DM의 중앙화, 그리고 이동 가능한 아이덴티티 구현의 제한점 등 여러 측면에서 연합우주의 대안으로 보기는 어렵습니다. 연합우주는 메시지 전달 방식의 분산된 아키텍처, 낮은 참여 장벽, 개방형 표준 기반의 활발한 커뮤니티 개발, 그리고 사용자에게 더 많은 자율성과 통제권을 제공하는 철학을 바탕으로 구축된, 근본적으로 다른 종류의 탈중앙화 소셜 네트워크입니다.
또한, Bluesky社가 벤처 캐피털 자금을 확보함에 따라 “조직은 미래의 적이다”라는 그들의 자체 인식에도 불구하고, 투자자 수익과 플랫폼 성장이라는 상업적 압력이 진정한 탈중앙화 추구보다 우선시될 위험이 있습니다. 특히 유료 계정과 광고가 도입되면서 이러한 우려는 더욱 커질 수 있습니다.
따라서 Bluesky는 X를 대체할 수 있을지 모르지만, 연합우주가 제공하는 탈중앙화된 가치와 경험을 대체하기는 어려울 것이라고 생각합니다. 두 시스템은 근본적으로 다른 목표와 설계 철학을 가지고 있으며, 이상적으로는 서로를 보완하는 방향으로 발전해 나갈 수 있을 것입니다.
판타지 소설 시리즈 《해리 포터》의 작가. ↩︎
AT Protocol이 이 지점에서 ActivityPub과 차별화되는 걸까? ATProto를 사용하면 DID를 통해 A서비스에 있는 계정과 B서비스에 있는 계정이 둘 다 내 계정임을 증명할 수 있고, 나에 대한 데이터는 서비스와 상관없이 모두 PDS에 저장해두는...? 이 방식이 ActivityPub보다 더 탈중앙화된 것처럼 보이기도 하네.
@parksbSimon Park 저는 오히려 그러한 “전역 뷰”에 대한 집착이 실질적인 중앙집권화를 불러오는 게 아닌가 싶은 생각이 들더라고요. 🤔
모바일에서 사진 올리기가 조금 어렵다.
@bin_bash_shell이수호 아… 그렇죠. 고쳐보도록 하겠습니다!
모바일에서 사진 올리기가 조금 어렵다.
높은 목표를 가진 개발자라도 결국엔 아주 사소한 동기로 움직이는거 같다.
나같은 경우엔, 완벽한 프로그래밍 언어를 만드는 것이 목표인데(가능한지는 차치하고), 완벽하다는건 나말고 다른 누군가가 같은 문제 의식을 가진다면 똑같이 그곳에 다다를 거란걸 의미한다. 그 프로그래밍 언어의 설계에서 내 마음대로 결정할수 있는 부분은 없을 것이다. 설계에서 최적의 선택지만을 택해야 완벽할테니까 말이다. 그때가선 그 선택들이 너무 자명해서, 내겐 처음부터 선택의 여지가 없었다고 느낄것이다.
그럼에도 내가 결정할 수 있을 부분이 있기는한데, 그 언어의 이름에 뜬금없이 우리집 강아지 이름을 붙인다던가 하는 것이다. 이게 그 사소한 동기다.
安寧하세요, 저는 서울에 살고 있는 30代 後半 오픈 소스 소프트웨어 엔지니어이며, 自由·오픈 소스 소프트웨어와 聯合宇宙(fediverse)의 熱烈한 支持者입니다.
저는 TypeScript用 ActivityPub 서버 프레임워크인 
@botkitBotKit by Fedify 
프로젝트의 製作者이기도 합니다.
저는 東아시아 言語(이른바 #CJK)와 유니코드에도 關心이 많습니다. 聯合宇宙에서는 國漢文混用體를 쓰고 있어요! 제게 韓國語나 英語, 日本語로 말을 걸어주세요. (아니면, 漢文으로도!)
こんにちは、私はソウルに住んでいる30代後半のオープンソースソフトウェアエンジニアで、自由・オープンソースソフトウェアとフェディバースの熱烈な支持者です。名前は洪 民憙です。
私はTypeScript用のActivityPubサーバーフレームワークである「@botkitBotKit by Fedify 」の作者でもあります。
私は東アジア言語（いわゆるCJK）とUnicodeにも興味が多いです。日本語、英語、韓国語で話しかけてください。（または、漢文でも！）
Hello, I'm an open source software engineer in my late 30s living in #Seoul, #Korea, and an avid advocate of #FLOSS and the #fediverse.
I'm the creator of @botkitBotKit by Fedify , a simple ActivityPub bot framework.
I'm also very interested in East Asian languages (so-called #CJK) and #Unicode. Feel free to talk to me in #English, #Korean (#한국어), or #Japanese (#日本語), or even in Literary Chinese (#文言文, #漢文)!
安寧하세요, 저는 서울에 살고 있는 30代 後半 오픈 소스 소프트웨어 엔지니어이며, 自由·오픈 소스 소프트웨어와 聯合宇宙(fediverse)의 熱烈한 支持者입니다.
저는 TypeScript用 ActivityPub 서버 프레임워크인 @botkitBotKit by Fedify 프로젝트의 製作者이기도 합니다.
저는 東아시아 言語(이른바 #CJK)와 유니코드에도 關心이 많습니다. 聯合宇宙에서는 國漢文混用體를 쓰고 있어요! 제게 韓國語나 英語, 日本語로 말을 걸어주세요. (아니면, 漢文으로도!)
Hello, I'm an open source software engineer in my late 30s living in #Seoul, #Korea, and an avid advocate of #FLOSS and the #fediverse.
I'm the creator of @botkitBotKit by Fedify , a simple ActivityPub bot framework.
I'm also very interested in East Asian languages (so-called #CJK) and #Unicode. Feel free to talk to me in #English, #Korean (#한국어), or #Japanese (#日本語), or even in Literary Chinese (#文言文, #漢文)!
디지털 가드닝에 관심이 많은 개발자입니다.
- 특히 위키 형식의 문서 관리, knowledge graph 구조의 시각화에 관심이 있어요.
- kodingwarrior.github.io/wiki
Neovim 이라는 텍스트 에디터에 굉장히 꽂혀있습니다.
- 과몰입한 나머지 플러그인까지 개발해본 경험이 있어요.
- 한국어권 개발자를 위한 Vim 디스코드를 운영중입니다 (vim.kr)
프로그래밍을 하는 행위 자체를 좋아합니다.
- 프로그래밍으로 퍼즐을 푸는 행위를 좋아했고, 비슷한 흔적을 가진 사람들에게 친밀감을 느낍니다.
Misskeyで投稿を引用すると、自動的に「RE: URL」がコンテンツに追加されますが、他のActivityPub実装（AkkomaやFedibird）とは異なり、この部分にCSSクラスがないため、カスタムCSSで非表示にできません。
この問題を解決するために、Misskeyの引用テキストに.quote-inlineクラスを追加する提案をしました。もし賛同していただけるなら、以下のイシューにスターやコメントをお願いします。
When quoting posts in Misskey, “RE: URL” is automatically added to content, but unlike other ActivityPub implementations (Akkoma, Fedibird), this section lacks a CSS class, making it impossible to hide with custom CSS.
I've created an issue proposing to add a .quote-inline class to quoted text in Misskey. If you agree with this improvement, please consider starring or commenting on the issue:
일단 Misskey 쪽에 이슈로 만들었다.
Misskeyで投稿を引用すると、自動的に「RE: URL」がコンテンツに追加されますが、他のActivityPub実装（AkkomaやFedibird）とは異なり、この部分にCSSクラスがないため、カスタムCSSで非表示にできません。
この問題を解決するために、Misskeyの引用テキストに.quote-inlineクラスを追加する提案をしました。もし賛同していただけるなら、以下のイシューにスターやコメントをお願いします。
ActivityPub 구현들에서 인용을 하면 content 값에 자동으로 “RE: 인용된 글 링크” 또는 “QT: 인용된 글 링크 [参照]” 같은 식으로 덧붙이는 동작들을 하는데, 다행히 Akkoma나 Fedibird 등에서는 이를 .quote-inline이나 .reference-link-inline 같은 클래스로 묶어줘서 CSS로 그것들을 가리는 게 가능하다. 그런데, 오직 Misskey만 그런 처리를 안 해줘서 CSS만으로 가릴 방법이 없다…
일단 Misskey 쪽에 이슈로 만들었다.
ActivityPub 구현들에서 인용을 하면 content 값에 자동으로 “RE: 인용된 글 링크” 또는 “QT: 인용된 글 링크 [参照]” 같은 식으로 덧붙이는 동작들을 하는데, 다행히 Akkoma나 Fedibird 등에서는 이를 .quote-inline이나 .reference-link-inline 같은 클래스로 묶어줘서 CSS로 그것들을 가리는 게 가능하다. 그런데, 오직 Misskey만 그런 처리를 안 해줘서 CSS만으로 가릴 방법이 없다…
나두 해커스펍
@hongminhee洪 民憙 (Hong Minhee) 안그래도 설정하다가 그냥 vsc 쓰고 있어요 :( 말리시는 이유가 있을까요?
2025년에 누가 Vim/Neovim 입문한다고 하면 도시락 싸들고 다니며 말리고 싶은 마음. 나야 이미 너무 익숙해져서 벗어나기 힘들게 됐지만… 그만큼 벗어나기 힘든 습관을 가지면서까지 얻는 이득이 요즘 시대엔 크지 않다고 느낀다.
vimの操作、完全に理解した
Hello, World!
@bin_bash_shell이수호 Hackers' Pub에 어서 오세요!
여기 자바스크립트맥주 한병 주세요
GN⁺: 스크립트에서는 긴 옵션을 사용합시다
------------------------------
- 많은 명령줄 유틸리티는 짧은 형식 옵션(-f)과 긴 형식 옵션(--force)을 지원함
- 짧은 형식은 대화형 사용을 위한 것임, 스크립트에서는 긴 형식을 사용할 것을 권장함
- 예를 들어, 터미널에서는 $ git switch -c my-new-branch라고 입력함.
- 릴리스 스크립트에서는 다음과 같이 작성함:
- `try …
------------------------------
https://news.hada.io/topic?id=19905&utm_source=googlechat&utm_medium=bot&utm_campaign=1834
@saschanazKAGAMI🏳️🌈🏳️⚧️ 어라, 확인해
볼게요!
@saschanazKAGAMI🏳️🌈🏳️⚧️ 이제 고쳐졌어요! 👍
아무래도 Hackers' Pub 가입 직후에 팔로 추천 탭을 보여주는 게 나을 것 같기도… 🤔
백준 관련해서 보다가 이런저런 프로젝트들이 많길래 모아놓는 저장소를 하나 팠다.
Hello, World!
@hongminhee@hackers.pub洪 民憙 (Hong Minhee) AP 데이터에서도 <math> 다음에 <span class="katex-html" aria-hidden="true">라는 붙지 말아야 할 것이 따라붙네요 🤔
@saschanazKAGAMI🏳️🌈🏳️⚧️ 어라, 확인해
볼게요!
여기 자바스크립트맥주 한병 주세요
@gaeulbyul가을별 님, Hackers' Pub에 오신 것을 환영합니다!!
나도 어디서 초대받아서 해커스펍 계정을 하나 만들까... 🤔
나도 어디서 초대받아서 해커스펍 계정을 하나 만들까... 🤔
@gaeulbyul가을별 DM으로 이메일 주소 알려주시면 제가 초대해 드릴게요!
@hongminhee洪 民憙 (Hong Minhee) @arkjunJuntai Park 점점 펍에 사람이 늘어나고 있어요 🍻
@z9mb1wwj @arkjunJuntai Park 초대장 시스템을 만들길 잘했네요!
나도 해커주점 계정만들고싶다
해커주점에 가입했습니다. 한잔해~
@fox여우 어서오세요～～!!
해커주점에 가입했습니다. 한잔해~
드디어 가입됐다
@catamorphicCata 안녕하세요, 어서 오세요!
드디어 가입됐다
액티비티펍 contentMap으로 여러 언어 넣으면 알아듣는 구현체가 있나
@hongminhee洪 民憙 (Hong Minhee) 오오 환영입니다. 프로필이나 박스, 이미지 등의 라운딩 처리도 요청하고 싶으나, 개인 취향의 영역에 가까워 강력하게 요청하기는 어렵군요. 😂
@arkjunJuntai Park 요즘 모든 웹사이트가 테두리가 다 둥글길래 일부러 네모지게 만들고 있긴 합니다… ㅋㅋㅋ
洪 民憙 (Hong Minhee) replied to the below article:
Hello World!
Liaizon Wakest @wakest@hackers.pub
Hello Hackers' Pub! I guess this is my hello world to this new world. Thanks for the invite @hongminhee!
Hello World!
Liaizon Wakest @wakest@hackers.pub
Hello Hackers' Pub! I guess this is my hello world to this new world. Thanks for the invite @hongminhee!
洪 民憙 (Hong Minhee) shared the below article:
Hello World!
Liaizon Wakest @wakest@hackers.pub
Hello Hackers' Pub! I guess this is my hello world to this new world. Thanks for the invite @hongminhee!