1P by GN⁺ | ★ favorite | 댓글 1개
  • 공개 이벤트 스트림 덕분에 Twitter에서는 만들기 어려운 전체 소셜 그래프 지도를 블루스카이에서는 1,300만 사용자 규모로 구성할 수 있었음
  • 수집 파이프라인은 bsky.networkWebSocket firehose에서 팔로우·언팔로우만 걸러 SQLite에 저장하며, 당시 follows 테이블은 5억 행 이상·약 30GB였음
  • 1,300만 노드와 5억 엣지를 배치하려고 Zig 기반 멀티스레드 force-directed layout 엔진 Andromeda를 만들었지만, 대형 소셜 그래프에서는 지역 구조가 뭉개지는 한계가 드러남
  • GGVec 임베딩과 UMAP을 조합해 더 많은 중간 구조를 얻고, UMAP의 점 겹침은 Andromeda로 몇 틱 더 시뮬레이션해 조밀한 클러스터를 다듬음
  • 최종 지도는 2024년 11월 7일 기준 필터링 후 770만 노드를 표시하며, 봇 링·국가별 클러스터·고팔로워 미디어/정책 계정 군집을 탐색할 수 있음

블루스카이 전체 네트워크 지도가 가능했던 이유

  • Twitter는 전체 데이터를 이용할 수 없고 스크래핑도 어렵고 불법적일 수 있어 전체 지도를 만들기 어려움
  • BlueSky는 필요한 데이터를 얻을 수 있으며, 2024년 몇 달 동안 크게 성장함
    • 성장 배경에는 Twitter와 사용자 기반의 지속적 충돌, 2024년 10월 브라질의 Twitter 차단이 있음
  • 결과물은 aurora.ndimensional.xyz에서 인터랙티브 지도로 탐색할 수 있음
    • WebGPU를 사용하므로 데스크톱 Chrome/Chromium이 필요함

팔로우 그래프 수집 방식

  • 전체 활동 대신 팔로우 그래프만 사용해 작업 범위를 줄임
    • 각 팔로우는 무방향 엣지 하나로 취급됨
    • 서로 맞팔이면 두 개의 엣지가 생겨 사실상 가중치가 두 배가 됨
  • BlueSky는 AT Protocol 기반이며, 사용자가 자신의 PDS(personal data server)를 직접 호스팅할 수 있도록 설계됨
  • 실제 수집은 BlueSky 팀이 운영하는 bsky.network relay의 WebSocket firehose를 사용함
    • 메인 *.bsky.social PDS와 인덱싱을 요청한 독립 PDS의 이벤트를 집계함
    • 전체 네트워크 이벤트가 실시간으로 스트리밍되며, 현재 약 초당 500개 이벤트 수준임
    • 이 중 팔로우와 언팔로우만 필터링해 로컬 SQLite 데이터베이스에 저장함
  • 초기에는 인덱서를 fly.io에 배포하고 litestream으로 AWS S3에 데이터베이스를 실시간 복제했지만, 월 40달러 비용 때문에 홈 서버 운영으로 바꿈
    • 이후 systemd 서비스, logrotate, tmux 모니터, TailScale을 조합해 집의 System76 데스크톱에서 운영함
  • 작성 시점에 BlueSky는 1,300만 사용자를 넘었고, follows 테이블은 5억 행 이상, 디스크 사용량은 약 30GB였음

1,300만 노드 그래프의 계산 병목

  • 그래프 레이아웃에는 여러 방법이 있지만, 여기서는 물리 시뮬레이션처럼 동작하는 force-directed layout이 출발점임
    • 모든 노드는 서로 밀어내는 힘을 가짐
    • 엣지는 소스와 타깃 사이를 당기는 힘을 만듦
    • 각 시뮬레이션 틱에서 노드별 순힘을 계산하고 온도 파라미터로 스케일해 이동시킴
  • 병목은 그래프 크기 자체보다 n-body problem의 계산 복잡도에 있음
    • 단순 알고리듬은 한 틱에 O(n^2) + O(e)가 필요함
    • 수백만 노드 규모에서는 GPU로도 현실적이지 않음
  • 일반적인 force-directed 엔진처럼 Barnes-Hut 최적화를 쓰면 O(n log(n)) + O(e)로 줄어듦
    • 먼 노드의 효과를 근사하는 대가가 있음
    • quadtree 구축과 질의는 계층적이라 GPU에서 노드 힘을 쉽게 계산하기 어려움
  • 병렬화를 위해 quadtree를 4개 또는 16개로 나눠 각 틱 시작 시 병렬 재구축하고, 스레드별로 노드 범위를 나눠 힘을 계산함
    • 각 노드의 순힘은 각 quadtree가 주는 힘과 들어오고 나가는 엣지가 주는 힘의 합임
    • 사용 가능한 CPU를 거의 오버헤드 없이 활용할 수 있음

Andromeda와 force-directed 방식의 한계

  • Zig로 멀티스레드 force-directed graph layout 엔진 Andromeda를 만들고, GTK4와 OpenGL로 GUI를 구성함
  • Andromeda는 Gephi와 ForceAtlas2 논문의 영향을 크게 받음
    • 대규모 그래프 시각화에서는 그래프가 변하는 모습을 보며 시뮬레이션 파라미터를 동적으로 조절하는 상호작용성이 중요함
    • 불투명하고 반복 시간이 긴 도구로는 좋은 결과를 얻기 어려움
  • Andromeda에는 “natural slider”라는 UI 위젯도 있음
    • 새 그래프, 새 엔진 버전, 새 파라미터를 다룰 때 적절한 값 범위를 미리 알기 어려운 문제를 줄이기 위한 장치임
    • 값 범위를 e의 거듭제곱 단위로 동적으로 조정함
    • 2의 거듭제곱은 너무 작고 10의 거듭제곱은 너무 크다고 판단함
  • 2024년 9월의 500만 BlueSky 사용자 스냅샷에 ForceAtlas2 레이아웃을 적용하자 큰 클러스터의 질량과 밀도는 보였지만, 전반적으로 덩어리진 형태가 강했음
    • 대부분의 노드는 슈퍼클러스터 주변의 넓고 구분 어려운 영역에 흩어짐
    • 몇십 개의 작은 커뮤니티, 주로 국가 단위 커뮤니티만 뚜렷하게 분리됨
  • 2024년 2월 200만 계정 버전을 공개했을 때도 전역 뷰에는 흥미가 있었지만 로컬 뷰에는 실망이 있었음
    • 사용자가 자신의 계정을 찾아도 주변 계정을 알아보지 못하는 경우가 있었음
    • 2D 평면 배치만으로 전체 네트워크 연결 구조를 완전히 포착하기는 어려움

UMAP, 색상, 최종 지도

  • 그래프 레이아웃은 차원 축소로도 볼 수 있어, 1,300만 × 1,300만 인접 행렬을 2차원 평면에 투영하는 문제로 다룰 수 있음
  • t-SNE와 UMAP은 2차원 시각화에 강한 비선형 차원 축소 기법임
    • UMAP에 BlueSky 행렬을 직접 넣기에는 홈 서버 규모에서 너무 큼
    • 대신 사용자별 32차원 정도의 임베딩을 만들고 그 결과를 UMAP에 넣음
  • 오픈소스 노드 임베딩 도구로 nodevectors를 선택했고, 미공개 GGVec 알고리듬이 대규모 그래프에서 병렬 성능이 가장 좋아 보였음
    • 2024년 9월 500만 노드 스냅샷의 임베딩은 5분 만에 생성됨
    • 첫 UMAP 이미지는 추가로 10분 만에 얻음
    • Andromeda의 덩어리진 결과보다 더 많은 중간 구조가 나타남
  • UMAP은 일부 클러스터를 너무 조밀하게 만들어 점이 겹치는 문제가 있었음
    • 원본 차원에서 동일한 점을 목표 차원에서도 같은 위치에 두는 순수 차원 축소 목적에는 자연스러운 동작임
    • 하지만 계정별 프로필 사진을 가까운 줌에서 보여주는 지도에는 적합하지 않았음
  • UMAP 내부도 마지막 단계에서 가중 k-최근접 이웃 그래프에 대한 force-directed layout을 사용함
    • UMAP은 계산 제약 때문에 샘플링을 사용하므로 모든 노드가 Barnes-Hut 방식처럼 근사적으로라도 서로 반발하지 않음
    • min_dist 파라미터가 대규모 그래프에서 점 간 분리를 일관되게 제어하지 못한다고 판단함
  • 겹침 문제는 UMAP 출력을 Andromeda에 넣고 반발력 방정식을 조정해 몇 틱 더 실행하는 방식으로 완화함
    • 조밀한 클러스터에서도 노드가 층처럼 겹치지 않고 채워짐
    • 다음 버전에서는 UMAP이 만든 그래프의 원시 가중치에 접근해 Andromeda의 병렬 quadtree와 UMAP 논문의 힘 방정식을 직접 결합해 보려 함
  • 색상은 UMAP 결과에 HDBScan을 적용하는 대신, 임베딩 공간에서 k-means 클러스터링을 수행해 부여함
    • 각 클러스터에 hue를 할당함
    • 각 점은 가장 가까운 세 클러스터 중심을 이용해 hue를 보간함
    • PCA 기반 색상보다 로컬 구조를 더 잘 드러내고, 가까이서 보면 얼룩진 스테인드글라스 같은 질감을 줌
  • hue는 0에서 1 사이의 단일 float이며, hsluv 색공간으로 RGB에 매핑함
    • 모든 노드의 채도는 일정하게 유지함
    • 밝기는 사용자 팔로워 수의 log10으로 스케일해 큰 계정은 밝은 별처럼, 팔로워가 적은 계정은 흐리게 보이게 함
    • 큰 계정을 실제로 더 크게 렌더링하는 방식은 대형 그래프에서 지나치게 복잡해져 제외함
  • 2024년 11월 7일 기준 전체 네트워크 지도는 팔로우 5만 초과 계정, 팔로우 5개 미만이면서 팔로워 5명 미만인 계정을 제외해 770만 노드로 구성됨
    • 고팔로워 미디어·정책·논평 계정의 뚜렷한 줄무늬가 배경의 관련 낮은 그룹과 구분됨
    • 아이슬란드 클러스터도 원거리와 근거리, 프로필 사진 수준에서 확인됨
    • 봇 링도 명확히 드러남
  • 다음 기능으로는 현재 화면에 보이는 계정들의 게시물 타임라인을 접을 수 있는 사이드바로 추가하려 함
    • 새로운 종류의 소셜·밈 탐색 도구로 발전시키는 것이 목표임

댓글과 토론

Hacker News 의견들
  • BSKY 피드가 완전히 죽은 공간처럼 느껴짐. 글도 올리고, 답글도 달고, 좋아요도 누르며 적극적으로 참여하려 했지만 아무것도 자리 잡지 않는 느낌임
    “나 자신을 위해” 올리는 글도 한계가 있어서 곧 흥미가 떨어짐. 초기 Twitter는 모두가 새 사람을 팔로우하려고 들뜬 분위기였는데, 새 소셜 네트워크라면 원래 새로운 관계망을 만들려는 사람들로 가득해야 하는 것 아닌가 싶음

    • 해당 핸들의 계정은 팔로우하는 사람이 아주 적고, 대화에 참여하기보다는 방송하듯 콘텐츠를 내보내는 방식에 가까워 보임. 반대로 해보는 게 좋겠음
    • 지금 BSKY에는 스타터 팩 때문에 부익부 빈익빈 문제가 큼. 영향력 있는 사람이 만든 스타터 팩에 들어가면 공짜로 팔로워가 무한히 늘지만, 처음부터 직접 존재감을 키우려면 거의 발견되지 않음
    • Mastodon도 시도해봤는지 궁금함. 거기서 더 나은 경험을 하는 사람이 많음
  • Bluesky와 atproto는 해킹 가능하게 만들기를 염두에 둔 것처럼 보임
    커뮤니티에서 최근 Bluesky “Starter Packs”를 검색할 수 있는 디렉터리를 만들었음. Starter Packs는 사용자가 팔로우할 만한 사람과 피드 묶음을 공개해, 신규 사용자가 초기 경험을 빠르게 구성하도록 돕는 기능임
    https://blueskydirectory.com/starter-packs/all
    Dan Abramov도 오늘 이걸 좋게 봤고, “이런 게 생태계 안에서 가능하다는 사실이 멋지다. 생태계가 요리하게 두자”고 했음 [1]
    더 날카롭게는 “atproto 생태계에서 임의의 프로젝트들이 튀어나오는 걸 보면, 소셜 회사들이 API를 닫아버리면서 공공 웹의 공용지가 얼마나 억눌렸는지 새삼 느낀다. 도구의 한 풍경 전체가 포기되고 버려졌다”고도 했음 [2]
    [1] https://bsky.app/profile/danabra.mov/post/3lar3sdna222d
    [2] https://bsky.app/profile/danabra.mov/post/3lar3xpuu4c2d

    • 넘어갈까 고민 중이었는데, 이 댓글이 가장 설득력 있게 다가옴
      기술 회사들이 저지른 치명적 실수 중 하나가 모든 걸 가둬두는 것이라고 봄. 컴퓨터와 스마트폰을 훌륭하게 만든 건 해킹 가능성이었고, 환경과 생태계를 만드는 일이었음. 잠금은 속도를 늦출 뿐임. 앱이 없었다면 스마트폰에 손전등이나 스톱워치가 들어가기까지 얼마나 걸렸을까 싶음. 운영체제에 내장되기 전에 이런 기능들은 앱이었음
    • Twitter도 원래 이런 특징이 어느 정도 있지 않았나 싶음. 기억으로는 리트윗 같은 지금의 인기 기능들도 처음에는 사용자가 임시로 만들어낸 관습이었음
    • 맞음, 의도적으로 해킹 가능하게 만들었음. 사람들이 그 위에 만들고, 바꾸고, 포크하고, 리믹스할 자유가 있을 때 소셜 미디어가 더 좋아진다고 믿음. Bluesky와 atproto 생태계는 사용자와 개발자가 원하는 속도만큼 빠르게 진화할 수 있음
    • Starter Packs는 훌륭함. 지금 상호작용이 가장 많은 계정을 보는 건 어떨까 싶음: https://www.graphtracks.com
    • 반대로 Twitter보다 10배 심한 봇 문제로 이어질 수도 있음
  • Bluesky가 지난주 특정 분야들에서 크게 폭발한 것 같음. 토요일 이후 팔로워가 5~6배 늘었음
    지난 1년 동안 어느 정도 활동했는데, 내가 일하는 에너지 분야의 Twitter 대화가 너무 망가져서 거의 쓸모없어졌기 때문임. 여러 의미로 공격적이고 스팸도 말도 안 되게 많았음. 반면 Bluesky는 여유롭지만 반응은 크지 않았는데, 이제는 분위기가 달아오르고 있음. 이 유입이 진짜였으면 좋겠고, 덕분에 훨씬 더 활발히 쓰게 됨

    • 내 X는 크게 망가지지 않았음. 일본어 X를 많이 쓰는데 그쪽은 다른 생태계일 수도 있음. 그래도 지난 1년간 Bluesky도 써왔고, 한동안은 재미있지만 꽤 조용한 네트워크였음. 한 시간쯤 새 글이 없을 때도 있었음
      최근 3주 동안 Bluesky가 훨씬 활발해졌고, 이제는 피드를 다 따라잡을 수 없다는 점에서 X와 비슷하게 느껴짐. 큰 커뮤니티가 더 다양한 관점을 만든다고 믿어서 매우 기대됨. 직접 Bluesky 라벨러와 Firehose 수집기도 운영 중인데, 지난 3~4개월 동안 이벤트 처리량이 대략 두 배가 되는 걸 지켜봤음
    • 스패머와 트롤도 곧 올 것임. 인기 있는 곳은 오래 방치되지 않음
    • 내게는 모든 게 자리를 잡아가는 중임
      Threads는 창작, 여행, 소셜 쪽 콘텐츠에 강한 반 Twitter·반 Instagram 혼합체이고, Bluesky는 뉴스, 정치, 과학에 강한 초기 Twitter에 가까움. 요즘은 모든 걸 한 앱에서 다 하는 게 가능할지 잘 모르겠음. 그러면 X는 새로운 4chan으로 남게 됨
    • 내 경험도 모든 면에서 그랬음. 갑작스러운 유입, 팔로우할 만한 흥미롭고 의미 있는 사람들이 많이 생김, 전체 경험이 빠르게 더 몰입감 있게 변함
    • 아직 Bluesky에서 유틸리티 계정을 찾지 못했음. Twitter에서는 게임, 게임 스튜디오와 퍼블리셔, 뉴스 사이트, 밴드, NASA 같은 소식을 보려고 팔로우함. Bluesky에는 아직 그런 게 없고, 모르는 개인들에는 관심이 없음. Twitter에서도 마찬가지임
      가끔 확인하지만 사실상 0/50에 가까움
  • 지난주 Bluesky로 옮겨간 사용자 물결의 일부임. 지금까지는 정말 마음에 들고, 예전에 Mastodon에는 실망했어서 조금 놀랐음. 이미 Twitter보다 Bluesky에서 더 많은 시간을 보내고 있음
    Bluesky가 뭔지 모르는 사람에게 설명하자면, 거의 2015년 무렵 Twitter의 복제품이고 UI도 거의 같음. 다만 수익화, 광고, 성장 해킹이 없어서 주요 기능들이 사용자를 위해 존재함. 마음에 드는 예는 단순한 Expo/React Native 기반 모바일 앱인데, 쓸모없는 앱 내 브라우저 대신 Safari에서 링크를 열 수 있게 해줌

    • Bluesky가 VC 투자를 받은 만큼 수익화, 광고, 성장 해킹이 시작되는 건 시간문제일 것 같음. 그 전까지 즐기면 될 듯함
    • 써봤는데 기술은 멋져 보이지만 더 다양한 내용이 있었으면 함. Twitter가 대부분 가상자산 사기와 미국 극우 정치 헛소리가 된 지금, 미국 극좌 정치 헛소리보다 조금 더 흥미로운 무언가를 원함
      세상은 미국이나 서구권 인터넷 드라마보다 훨씬 큼. 유럽인으로서 BlueSky를 포함한 주류 소셜 미디어를 읽다 보면 눈이 돌아갈 지경임. 정치, 성 정체성, 키보드 행동주의에는 관심이 없음. 메뉴에 다른 걸 좀 올릴 수 없나 싶음. 정말 뭐든 좋음. 미국 정치나 사생활에서 누가 어떤 성별에 끌리는지 말고 새로운 것에 노출되려면 러시아어나 중국어를 배워야 하나 고민될 정도임. 누가 신경 쓰나 싶음
      Nostr는 기술적으로는 즐거웠지만, 끝내 크립토 브로 단계를 벗어나지 못해서 아쉬움
    • “2015년 무렵 Twitter의 복제품이고, 수익화·광고·성장 해킹이 없어서 기능이 사용자를 위해 있다”면, 그건 Mastodon과 똑같음
    • Threads와는 어떻게 비교되는지 궁금함
  • 꽤 멋짐. BlueSky API가 잘 만들어져 있음. 동료가 Firehose 기반으로 이런 시각화를 만들었음: https://bigmood.blue/
    출처: https://bsky.app/profile/even.westvang.com/post/3laob7tefxk2...

  • 이걸 얼마나 좋아하는지 과장하기 어려움. 최종 결과가 여러 차원의 정보를 전달할 뿐 아니라 시각적으로도 매우 매력적임
    엄청난 수의 노드를 렌더링하면서 생기는 입자감이 특히 좋은 느낌을 더해줌. 다른 그래프 시각화에서는 자주 보기 어려운 요소임

  • Bluesky의 가장 좋은 점은 도메인을 사용자명으로 쓸 수 있다는 것임. 나는 거기서 @bradgessler.com을 쓰고 있고, 사람들이 나를 “검증”하고 싶으면 파란 체크표시보다 훨씬 의미 있는 내 웹사이트를 보게 됨
    차단되거나, 금지되거나, 플랫폼에서 쫓겨나더라도 사람들은 내 도메인을 보고 거기로 가서 무슨 일이 생겼는지 확인할 수 있음. 어떤 의미에서는 검열이 드러나는 구조임. 기업에도 좋을 것 같음. @example.com으로 기업을 부르고 응답을 받는 게 훨씬 덜 모호함. Rails 기반 SaaS 중 이미 이렇게 하고 있는 곳들을 모아 스타터 팩도 만들었음: https://go.bsky.app/JQyXa2u
    BlueSky가 하고 있는 일이 정말 마음에 들고, 앞으로 저질화되지 않았으면 함. 설령 그렇게 되더라도 지금은 분위기가 아주 좋은 골디락스 시점처럼 보임. 계정을 만들고 자기 도메인으로 연결하는 데 5분이면 되니 강력 추천함

    • Mastodon의 신원 확인도 모두에게 열려 있고 오픈 웹 표준에 기반함
      https://joinmastodon.org/verification
    • 가입할 때 받는 기본 핸들인 .bsky.social 주소도 기본적으로 bsky.app의 프로필로 리다이렉트됨. Bluesky가 뭔지 전혀 모르는 사람도 그 URL을 열면, @가 붙어 있어도 바로 소셜 프로필을 볼 수 있음
  • “BlueSky 행렬을 UMAP에 넣으면 어떻게 될까? 적어도 직접은 못 한다. UMAP이 기술적으로 희소 행렬을 받긴 하지만, 이 규모는 내 홈 서버에 너무 큼. 대신 다른 기법으로 모든 사용자의 임베딩을 32 같은 중간 크기 차원으로 뽑고, 그걸 UMAP에 넣으면 된다. 쉽다!”라고 되어 있는데, 정확히 임베딩은 어떻게 도출한 건지 궁금함

  • “사분 트리 생성과 질의는 본질적으로 계층적이다”라는 문장을 보고, hierarchy에서 헷갈리는 게 나만은 아니라는 생각이 들어 반가웠음
    여러 층위에서 흥미로운 작업임. 말장난은 아님. Bluesky 데이터 가용성부터 처리, 시각화 알고리즘까지 볼거리가 있음. 다만 이런 시각화를 데이터 과학 스펙트럼의 어디에 놓아야 할지는 조금 불분명함. 전통적인 수치 그래픽은 시간이 지나며 꽤 정교한 문법을 발전시켜서, 비교적 정확한 추론과 해석을 가능하게 함. 그래서 과학 논문이나 금융권 등에서 실제 정보 전달용으로 많이 쓰이고, 사람들은 그래프를 역공학해 데이터를 복원하기도 함
    네트워크와 그래프는 위상, 연결성, 군집에 대한 전반적 감각 외에는 전달되는 정보가 무엇인지 특정하기가 꽤 어려움. 이런 대규모 그래프를 다루는 유용한 문법이 아직 발명되지 않은 건지, 아니면 원래 그런 성격인지 잘 모르겠음

  • 이 데이터를 자연어 처리 관점에서 더 보고 싶음. Google Trends처럼 어떤 담론 주제가 정기적으로 나타나는지, 특정 기간에 무엇이 급증하는지 볼 수 있으면 좋겠음
    경제학자들이 무엇을 논의하는지 요약할 수 있을까? 서로의 네트워크에는 없지만 같은 것에 대해 말하는 사람들을 찾을 수 있을까 궁금함