Hacker News 2026.06.22 41

내 블루스카이 계정, 정말 '내 것'일까? — ATProto 신원의 불편한 진실

탈중앙 SNS라는데, 신원은 누가 쥐고 있을까

요즘 트위터(X) 대안으로 블루스카이(Bluesky)가 많이 거론되죠. 블루스카이는 ATProto(AT Protocol)라는 프로토콜 위에서 돌아가는데, 핵심 약속이 '탈중앙화'예요. 즉, 특정 회사가 내 계정과 데이터를 마음대로 가두지 못하고, 사용자가 자기 신원과 글을 들고 다른 서버로 옮길 수 있다는 거죠. 그런데 한 블로그 글이 '정말 그럴까? 네 ATProto 신원은 사실 네 것이 아닐 수도 있다'고 짚으면서 이 약속의 허점을 파고들었어요.

핸들과 DID, 그리고 PLC 디렉터리

ATProto에서 사용자 신원은 두 겹으로 되어 있어요. 하나는 핸들(handle)이에요. @someone.bsky.social 같은 거죠. 이건 사실 도메인 이름(DNS)을 이용한 거라 사람이 읽기 좋은 별명 같은 거예요. 다른 하나는 DID(분산 식별자, Decentralized Identifier)인데, 이게 진짜 변하지 않는 고유 ID예요. 핸들은 바뀌어도 DID는 유지돼서, 시스템 내부에선 DID로 '이 사람이 그 사람'임을 추적하죠.

문제는 이 DID를 만드는 방식이에요. ATProto에서 가장 많이 쓰이는 건 did:plc라는 방식인데, 이게 'PLC 디렉터리'라는 곳에 등록돼요. 그런데 이 PLC 디렉터리를 운영하는 곳이… 바로 블루스카이를 만든 회사거든요. 즉, '네 DID가 어떤 키와 어떤 서버에 연결돼 있는지'를 기록하는 장부를 사실상 한 회사가 중앙에서 관리하고 있다는 거예요. 이름은 '분산' 식별자인데, 실제 장부는 한 곳에 있는 셈이죠.

이게 왜 중요하냐면, 그 디렉터리가 멈추거나, 정책을 바꾸거나, 특정 계정을 막기로 결정하면, 사용자는 자기 신원에 대한 통제권을 잃을 수 있어요. '내가 내 신원을 소유한다'는 탈중앙의 핵심 전제가 흔들리는 거죠.

그럼 did:web은 답일까

대안으로 did:web이라는 방식도 있어요. 이건 내가 가진 도메인(예: did:web:myname.com)에 직접 신원 정보를 올려두는 방식이라, 회사 디렉터리에 의존하지 않아요. 통제권이 나한테 더 오죠. 하지만 여기도 함정이 있어요. 도메인은 매년 갱신비를 내야 하고, 깜빡하고 갱신을 놓치거나 등록기관(레지스트라)이 도메인을 회수하면, 그 순간 신원 자체가 날아가버려요. 게다가 도메인은 DNS라는 또 다른 중앙 시스템(그리고 국가·기관)에 묶여 있죠. 즉 '한 회사 대신 도메인 체계에 의존'하게 되는 거라, 완전한 자기 소유라고 보긴 어려워요.

결국 글의 요지는 이거예요. 대부분의 사용자는 기본값인 did:plc를 그대로 쓰고, 그러면 신원 계층의 실질적 통제권은 운영 회사에 남는다. '탈중앙'이라는 단어가 주는 안심과 실제 구조 사이에 간극이 있다는 거죠.

다른 방식들과 비교하면

비슷한 탈중앙 SNS인 마스토돈(Mastodon)이 쓰는 ActivityPub은, 신원이 '내가 속한 서버(인스턴스)'에 묶여요. 서버가 사라지면 계정도 사라지죠. 그래서 ATProto는 '서버를 옮겨도 신원 유지'를 강점으로 내세운 건데, 그 신원 유지의 뿌리에 중앙 디렉터리가 있다는 게 이번 비판의 핵심이에요. 반대로 'Nostr'라는 프로토콜은 아예 공개키 자체가 신원이라, 디렉터리도 도메인도 필요 없어요. 대신 키를 잃어버리면 끝이고, 사람이 읽기 좋은 이름도 따로 챙겨야 하는 불편함이 있죠. 결국 '편의성 vs 진짜 자기 소유' 사이의 트레이드오프인 셈이에요.

한국 개발자에게 주는 시사점

요즘 '탈중앙 신원(DID)'은 SNS뿐 아니라 인증, 핀테크, 자격증명 분야에서도 많이 거론돼요. 이번 사례는 '탈중앙이라고 적혀 있다고 다 탈중앙은 아니다'라는 점을 분명히 알려줍니다. 어떤 시스템을 평가할 때는 '기본값(default)으로 무엇을 쓰는가', '최종 신뢰의 뿌리(root of trust)가 어디인가'를 꼭 따져봐야 해요. 블루스카이 위에서 앱이나 서비스를 만들 계획이 있다면, did:plc와 did:web의 차이, 키 회전(rotation key)과 복구 구조를 이해해두는 게 좋고요.