did:plc 대신 did:web으로 Bluesky/ATProto 계정을 설정하려다 계정이 ‘burn’ 처리되어 AppView에서 차단된 경험과, 그 설계가 드러내는 문서화·중앙화 문제에 대한 비판.
I Was Right About ATProto Key Managementhome | main website
참고: 이 글은 “무슨 일이 있었는지”에 대한 설명과, “내 분석” 두 섹션으로 나뉘도록 수정되었다. 나는 전반적으로 ATProto를 좋아하지 않지만, 특정 설계 결정과 그 결과에 대해 성실한(좋은 의도의) 비판을 하려고 한다는 점을 분명히 하고 싶다. 그리고 이 글이 HackerNews에서 업보트(추천)를 받은 덕분에 팀의 관심을 끈 것 같으니, 목적 달성이다. ref, ref 이후 내 계정은 수동으로 복구되었다. 내가 알기로는 같은 문제를 겪은 다른 사용자들은 아직 누구도 이런 식의 복구를 받지 못했다.
오늘, did:plc 대신 did:web을 사용해 Bluesky에서 쓸 ATProto 계정을 설정하려고 했다. 과정을 따라가 보자:
내가 제어하는 서버에 PDS 소프트웨어를 설치했다. NixOS를 쓰기 때문에 아주 쉬웠다.
did:web을 만들었다. 즉 공개-비공개 키쌍을 만드는 것이다. 처음에는 Mai Lapyst의 이 튜토리얼을 따라 하려 했지만, 너무 오래되어서 중요 단계가 하나 빠져 있었다.
그 did:web으로 did.json 문서를 내 웹서버에 올리고 적절한 DNS 레코드를 설정했다. 충분히 쉬웠다. 다만 did.json에 CORS 헤더도 설정해야 했다.
새 PDS에 계정을 만들었다. 인바이트를 받아 계정 생성은 했지만 상태가 “비활성화(deactivated)”였고 활성화할 수 없었다. 서버의 PDS 로그에서 에러를 읽어가며 curl로 수동 요청을 만들어 처리해야 했다.
ATProto Touchers 디스코드 서버에서 도움을 구했고, 조언에 따라 계정을 삭제했다.
처음부터 다시 시작해 전부 새로 만들었고, DID에 있는 공개 키를 getRecommendedDidCredentials에서 나온 공개 키로 올바르게 교체했다.
Bluesky(bsky.app)에 로그인하자 “Profile does not exist(프로필이 존재하지 않음)” 에러가 떴다.
이 시점에 이 GitHub 이슈를 찾았는데, 내가 (완전히 비어 있고 쓰지 않은) 계정을 삭제했기 때문에 내 did:web이 시스템의 남아 있는 ‘대부분 중앙화된’ 부분, 즉 AppView에서 블랙리스트 처리된 것으로 보인다. 이를 “burned(번 처리됨)”라고 부르며, 나중에 더 경험 많은 사용자들로부터 이것이 Bluesky AppView의 알려져 있지만 문서화되지 않은 동작임이 확인되었다.
Bluesky를 쓰는 친구 한 명에게 확인을 부탁했는데, 실패 양상이 흥미롭다. Bluesky에서는 내가 아예 존재하지 않았다. (그 친구는 내 좋아요도, 내가 그 친구를 팔로우한 것도 볼 수 없었다.) Blacksky 프로덕션에서는 내 표시 이름과 바이오는 보였지만 글(post)은 보이지 않았다. 반대로 Blacksky 자체 AppView에서는 “invalid(유효하지 않음)” 프로필 아래에 내 글이 나타났다. 나는 수동 절차로 “un-burn(번 해제)”되었지만, 내 지원 요청 때문은 아니었다. 이 글이 Hacker News 1면에 올라갔고, Bryan Newbold가 거기서 이 글을 봤기 때문이다.
이건 나쁘다.
예전에 나는 “Key Management, ATProto, and Decentralization”라는 글에서 ATProto의 탈중앙화 접근을 비판했다. 그 뒤로 Blacksky가 AppView를 띄웠고, 이론상 Bluesky에서 실제로 탈중앙화된 경험을 할 수 있게 되었다. 이게 내가 여러 번 말해온 ‘선 긋기’였다. 즉, Bluesky라는 회사 하드웨어에서 돌아가는 무엇도 쓰지 않고 계정을 만들 수 있을 때에만 계정을 만들겠다고. 이제 그 시점이 온 것 같아서 시도해 보기로 했다.
나는 Signal, Matrix, Mastodon처럼 마음에 들지 않는 시스템도 많이 쓴다. 내가 아끼는 사람들과 사회적 상호작용을 할 수 있기 때문이다. ATProto, 특히 Bluesky도 마찬가지다. 다른 데에는 전혀 글을 올리지 않는 친구들이 있다. 오늘 나는 RSS로 그들을 팔로우하지만, 그들의 글에 상호작용할 수는 없다. 네트워크를 쓰려는 동기는 여기에서 오고, 더불어 새로 탈중앙화된 AppView 레이어가 어떻게, 그리고 얼마나 잘 작동하는지 이해하고 싶기도 하다.
이 과정은 문서화가 거의 되어 있지 않다. 개별 엔드포인트는 — 어느 정도 — 문서가 있지만, 전체 과정을 한 곳에 모아둔 건 이 GitHub 이슈의 댓글뿐이다… 그런데 그 이슈는 WONTFIX로 닫혀 있다. 내가 놓친 getRecommendedDidCredentials 엔드포인트의 문서도 전문이 다음 한 줄이다:
이 서비스로 마이그레이션하는 계정의 DID 문서에 포함되어야 하는 자격 증명(credential)을 설명한다.
여기서 나는 마이그레이션 중이 아니다. 이 계정은 새로 만든 것이다. 게다가 그 엔드포인트가 반환하는 JSON 키는 DID 문서의 키들과 거의 같지만 미묘하게 다르고, 반환되는 키는 실제로 사용 가능하게 만들려면 손으로 편집해야 한다.
이건 좋지 않다! did:web은 did:plc에 비해 “덜 중앙화된” 혹은 “신뢰를 직접 가져오는(bring your own trust)” 옵션으로 내세워져 왔는데, 사용 가능하게 만들려는 노력이 거의 없었던 것처럼 보인다. 특히 “일반” 사용자를 위해서는 더더욱 그렇다.
하지만 다른 문제가 있다. 더 큰 문제다. 중앙화된 “burn”이 왜 내가 Bluesky를 쓰는 사람들과 상호작용하는 것을 완전히 막을 수 있는가?
Mastodon에도 비슷한 시스템이 있다는 걸 알 수도 있다. Mastodon 서버를 세팅한 뒤 데이터베이스를 지워버리면, 이미 연합(federation)했던 상대들은 다시는 너와 연합하지 않으려 한다. 같은 인스턴스라는 걸 증명할 수 없기 때문이다. 실제 문제이긴 하다 — 하지만 내 경우처럼 되지는 않았을 것이다. 왜냐하면 나는 이제 번 처리된 did:web 아이덴티티로 글을 한 번도 올린 적이 없고, 누구도 팔로우하지도 않았기 때문이다.
설령 그랬더라도, 그건 모든 연결이 아니라 어떤 연결 하나를 태운(burn) 것이었을 것이다. 경험이 나빠지긴 해도 망가지진 않았을 것이고, 영향을 받은 서버들의 관리자들과 함께 복구(개선)할 수도 있었을 것이다. 물론 여기서도 비슷하게 말할 수는 있다. 내 계정을 되찾은 건 Bryan Newbold가 우연히 Hacker News에서 이 글을 봤기 때문이었다. 결국 중요한 연결은 사실상 하나뿐이다. Blacksky를 포함하면 둘일지도 모르지만, 그들의 AppView는 아직 일반적으로 사용 가능하지 않다. 그게 중앙화다. 나는 이걸 다른 무엇이라고 불러야 하는지 모르겠다.
나는 Bluesky도 ATProto도 좋아하지 않는다. 커뮤니티 주도 프로젝트들이 거액의 자금을 받고 우리 모두가 각자 커뮤니티를 위한 작은 소셜 미디어 서버를 셀프 호스팅하는 세상에 살고 있으면 좋겠다. 하지만 우리는 그런 세상에 살지 않는다. 그래서 VC가 투자한 기업형 소셜 미디어와 상호운용해야 한다. 그런 플랫폼들이 스스로를 “탈중앙화”라고 부른다면, 나는 그에 걸맞게 실제로 해내야 한다고 생각한다.
