▲

블루스카이 댓글 기능을 내 블로그에 구축하기

 (natalie.sh)
1P by GN⁺ 13시간전 | ★ favorite | 댓글 1개
  • 기존 댓글 시스템(Disqus, 자체 호스팅, GitHub Issues 등)은 속도, 추적, 유지보수 부담, 사용자 제한 등의 문제로 사용하지 않음
  • Bluesky는 인프라 유지 필요 없음, 리치 콘텐츠 지원, 실명 기반 계정, 크로스 플랫폼 대화가 가능해 블로그 댓글에 적합
  • 구현 방식은 블로그 글을 게시 → Bluesky에 공유 → AT URI를 블로그 포스트 메타데이터에 추가 → 해당 포스트의 댓글 스레드를 불러와 표시하는 구조
  • 컴포넌트는 댓글 전체 표시, 개별 댓글+대댓글 표시, 이미지·링크 등 임베드 처리의 3개로 분리
  • 재귀 방식으로 최대 5단계 대댓글 표시, 이미지 그리드·모달, 링크 카드, 미지원 임베드는 대체 문구로 처리
  • Astro + React 통합, client:load로 클라이언트에서 로드, frontmatter에 DID와 postCid 추가로 활성화
  • 타입 안정성을 위해 @atcute/client TypeScript 타입 활용, 자바스크립트 비활성화 시에도 본문은 정상 표시되는 프로그레시브 인핸스먼트 구조
  • 서버·DB 없이 Bluesky API와 CDN을 활용해 성능 확보
  • 이 접근법은 소셜 기능을 사이트별로 재구현하는 대신, 사용자가 이미 쓰는 플랫폼과 연결하는 방식으로 확장성과 독립성을 확보함

Bluesky를 댓글 시스템으로 선택한 이유

  • 인프라 유지 필요 없음
  • 이미지·링크·인용 포스트 등 풍부한 콘텐츠 지원
  • Bluesky 계정 기반의 신뢰성과 책임성
  • 블로그와 소셜미디어 간 트래픽 교차 가능
  • 콘텐츠 소유권 분리(블로그 글은 본인, 댓글은 작성자 소유)

AT 프로토콜 이해

  • DID: 탈중앙화 사용자 식별자
  • CID: 콘텐츠 식별자
  • AT URI: at://did:.../app.bsky.feed.post/... 형태 주소
  • getPostThread API 호출로 댓글 스레드 가져오기 가능, 인증 불필요

컴포넌트 구조

  • 메인 댓글 컴포넌트
  • 개별 댓글+대댓글 렌더링 컴포넌트
  • 이미지·링크 등 임베드 처리 컴포넌트

중첩 댓글 처리

  • 재귀 렌더링, 최대 깊이 5단계 제한
  • 시각적 들여쓰기로 계층 표현

리치 콘텐츠 처리

  • 이미지: CDN 제공, 다중 이미지 그리드·모달 뷰
  • 외부 링크: 썸네일·설명 포함 카드 렌더링
  • 기타 임베드: 대체 문구 표시

Astro 통합

  • React 컴포넌트 + client:load 사용
  • frontmatter에 Bluesky DID, postCid 추가로 댓글 활성화

개발 경험

  • TypeScript 타입 지원으로 안정성 확보
  • Progressive Enhancement로 API 장애 시에도 본문 영향 없음
  • 서버·DB 부하 없이 Bluesky 인프라 활용

결론

  • 기존 댓글 시스템의 문제를 피하고, 사용자가 이미 있는 플랫폼과 연결
  • Bluesky 성장과 함께 참여자 증가 가능
  • ATProto 기반이라 다른 AppView나 자체 구현으로 전환도 용이
▲
GN⁺ 13시간전  [-]
Hacker News 의견

  • Bluesky가 앞으로 어떻게 수익화를 할지에 관한 전체적인 아이디어를 공개해줬으면 하는 바람임, 복잡한 기술 구조로 포장되어 있지만 결국엔 뭔가 유료화가 된다면 어떤 방식일지 궁금함

  • 흥미로운 글이라는 생각임, 개인적으로 남들이 독립적으로 홈페이지를 구축하고 운영하는 과정을 읽는 걸 즐김, 글에서는 댓글 시스템 문제와 네 가지 대안이 언급되는데, 본인은 다섯 번째 방법도 효과가 있었다는 얘기를 하고 싶음
    여러 서드파티 댓글 시스템을 써보고 결국 직접 간단한 댓글 시스템(form.lisp)을 만들어 사용 중임, 각 댓글은 텍스트 파일로 저장되어 스팸이나 XSS, 무의미한 댓글을 걱정하지 않아도 됨, 주말마다 수동으로 확인해 블로그에 추가하는 방식임
    댓글들은 일반 HTML 파일로 저장되고, 정적 사이트 생성기(site.lisp)가 본문과 함께 댓글 페이지(댓글 예시)도 만들어줌, 즉 본질적으로 정적 댓글 생성기로 동작함
    글에서 언급된 다섯 가지 속성(별도 인프라 불필요, 리치 콘텐츠, 실명 등)에는 부합하지 않지만, 자신에게는 잘 맞았고 최소 4년 이상 만족스럽게 운영 중임

    • 이메일 폼 등으로 댓글을 받았다가 관리자 입장에서 직접 글 하단에 추가하는 방식도 나름 괜찮음

    • 본인의 방법도 저트래픽 블로그에는 매우 적합하다는 생각임, 하지만 개인적으로는 내 사이트에 타인의 목소리가 들어가는 게 어색해서 댓글 자체를 빼고 블로그를 내 개성 표현의 공간으로만 사용 중임, 대신 영감을 준 다른 블로거에게는 이메일 피드백을 남기는 걸 선호함

    • 신문에서 ‘독자투고’ 받는 것과 비슷하다는 느낌임

  • 나의 추천은 cactus.chat임, Matrix 기반이고 게스트도 지원하므로 따로 Matrix 계정이 없어도 댓글을 쓸 수 있음, 본인 계정을 쓰면 각 포스트마다 Matrix 방에 참여하는 형태가 됨

  • Bluesky는 기존 사용자 계정 기반으로 정보 저장에 매우 유용함, 현재 오픈소스 웹 지도 cartes.app에서 Bluesky 기반 리뷰 시스템을 개발 중임
    쉽지는 않아서 lexicon을 만들고 Bluesky 스트림에 따라 DB도 계속 관리해야 함

    • 사실 DB 없이도 어느 정도까지는 갈 수 있음, 만들어왔던 scrapboard.org에서도 getRecord API(문서)만으로 클라이언트 데이터 조회가 꽤 많이 가능했음

    • mangrove.reviews를 대신 쓰라는 제안임, 해당 서비스는 명확한 CC-BY-SA 라이선스가 적용되어 있고 MapComplete.org도 사용 중임, Bluesky도 언젠가는 문제 발생 가능성 있음

  • 나는 Bluesky의 수익 모델 지속성에 회의적임, 현재 무료로 쓸 수 있는 것도 사실상 VC(벤처캐피탈) 투자 덕분임
    그래서 도입에 조심스럽고, 아마도 가까운 미래에 API가 폐쇄되거나 댓글 시스템이 망가질 것 같은 불안감이 있음

    • Bluesky는 아키텍처적으로 사용자의 Personal Data Server(PDS) 아래에서 동작함, 누구나 PDS를 바꿀 수 있고, 공식 Bluesky 앱 서버는 단지 집계 역할임
      타사가 직접 만든 app server, app view 등으로도 동일 데이터에 접근 가능함, 굳이 공식 API에 종속적일 필요도 없음, 여러 모로 개방성이 높음

    • 나는 POSSE라는 개념을 매우 믿는 편임, ‘enshittification cycle’에서의 긍정적인 측면은 한동안 쾌적한 온라인 커뮤니티 경험을 하다가 또 새로운 곳으로 옮길 수 있다는 점임, 예전 좋은 클럽들이 사라졌듯이 너무 미련 가질 필요 없다고 생각함, 나의 생각을 정리한 Mastodon 링크도 있음 이론 설명

    • Bluesky가 수익화로 전환하는 시점이 오겠지만, AI나 다른 서비스도 결국엔 비슷하게 VC 자금으로 움직이는 구조임, 트위터, Uber, Doordash 등과 마찬가지로 결국 분위기가 변질되긴 해도, VC들이 새로운 부유함을 꿈꾸면서 돈을 쏟을 때까진 그 ‘풍요’를 마음껏 즐기는 것도 한편으론 재밌는 현상임

  • Bluesky 생태계는 정말 멋지다는 생각임, 일전에 이 방식(Bluesky 기반 댓글 시스템)에 대한 사례를 본 적 있음
    조금 아쉬운 점이 있다면, 웹페이지마다 Bluesky에 별도의 포스팅을 올려야 댓글 시스템이 동작함, webcomponent 같은 것도 있으면 더 좋을 것 같음

  • 글에서 “수년간 블로그에 제대로 된 댓글 시스템을 못 달고 있다”고 하셨는데, 블로그 전체에 2025년 글만 두 개가 보임(그 중 하나가 본 포스트임)

    • 과거에는 다른 블로그가 있었던 걸로 archive.org에서 확인한 적 있음

  • 소셜미디어 피드를 굳이 마주하지 않아도 소셜과 상호작용할 수 있는 방식이라 흥미로움
    내 블로그에 이 기능을 붙여서 사람들이 직접 댓글을 남기고, 나는 이런 식의 인터페이스를 통해서만 Bluesky나 기타 소셜과 상호작용해도 좋겠음
    피드를 열면 결국 ‘둠스크롤링’이나 시간 낭비로 이어지는 경우가 많았음, 이 방식을 통해 그런 악순환을 피하면서도 조금은 소셜미디어와 연결될 수 있는 새로운 가능성을 느꼈음

    • “피드를 열면 꼭 의미 없는 정보만 계속 보게 됨”에 공감하는데, 그게 원래 설계 목적 아니었겠냐는 의구심이 들기도 함

  • Bluesky가 혼자서 인터넷에 다시 한번 신선한 아이디어가 자유롭게 나오는 환경을 만들어준다는 느낌이 있음

    • 실제로는 Threads에 더 열려 있는 통합 옵션을 더한 정도로 볼 수 있음, 아마 ‘열린 혁신’ 얘기는 ATProto에 더 적합한 표현일 것 같음

    • 기업이나 단일 집단에 너무 많은 공을 돌리고 싶진 않지만, 당장은 Bluesky 커뮤니티가 재밌음, 예전 트위터의 팬이었고, 지금 Bluesky의 메인 유저층도 그런 분들이 많은 듯함, 앞으로 어떻게 될지는 두고 볼 얘기임

    • “플랫폼이 아닌 프로토콜”이라는 슬로건을 신봉함, “build mode”라는 말도 있지만, 결국 소유당하거나 오용되기 힘든 무언가를 만들자는 것임

    • 만약 Bluesky 운영진이나 일부 유저 집단을 자극하거나 혹은 특정 집단에 의해 신고당하면 계정이 바로 밴당할 수 있음, 또는 사전 공유된 블랙리스트에 실리면 말도 꺼내기 전에 이미 보이지 않게 될 수도 있음
      근본적으로는 예전 트위터보다 더 독한 환경을 다시 만들려는 시도처럼 느껴짐, 마치 고등학교 급식실 같은 유치한 권력 싸움 요소도 있음

  • 블로그에 자체적으로 호스팅하지 않고 Bluesky에 기대고 있으니 결국 Bluesky에서 관리하고 있는 셈임
    플랫폼 락인이 없다고 하지만, 만약 내일 Bluesky에서 내 계정을 차단하거나 회사가 망하면 어쩔 계획인지 궁금함
    AT 호환 제품으로 전환할 수는 있겠지만 많은 데이터가 사라지진 않을지 걱정임

    • 이 주제에 관심 있다면 https://whtwnd.com/bnewbold.net에서 Bluesky 및 AT Proto를 기반으로 직접 릴레이 네트워크 구축, 데이터 마이그레이션 등 실질적인 정보, 도구가 정리되어 있음, 데이터 마이그레이션, 포터블리티, 대체 릴레이 네트워크 지원 등 다양한 진전이 있음, 관련 링크도 참고 가능함
      (참고로 해당 블로그 저자는 Bluesky 직원임, 나는 별개임)

    • 자신의 개인 데이터를 IPFS에서 쓰는 CAR 파일(타르볼 형태)로 백업할 수 있음, 이후에는 계정의 did:plc 문서나 DNS 레코드를 통해 어느 PDS든 복원 가능함
      만약 현재 PDS가 망하거나 차단돼도 바로 다른 서버로 이동할 수 있음
      릴레이(가십 노드), PDS, 클라이언트, 앱뷰(Bluesky 웹앱 백엔드) 등 각종 오픈소스 구현체와 호스팅 제공사들이 존재함
      Bluesky가 내일 망해도 쉽게 셀프호스팅하거나 다른 업체(예: zeppelin.social)를 이용해서 기존 App을 이어갈 수 있음
      PLC 디렉토리는 아직 Bluesky가 관리 중이지만 독립 재단으로 이전 중이고, 필요하면 복제도 쉬움, did:web 방식 쓰면 DNS 체계에만 의존하기에 독립성이 높음

    • 그 외에도 Bluesky는 명백히 리버테리언(자유주의) 혹은 우파 성향 유저를 적극 퇴출시키고 있음, 좌파나 정치적 무관심층은 괜찮은 분위기임

답변달기