▲

자신의 사이트에 게시하고 다른 곳으로 배포하기(POSSE)

 (indieweb.org)
3P by GN⁺ 12시간전 | ★ favorite | 댓글 1개
  • 개인이 콘텐츠를 자신의 웹사이트에 먼저 게시하고, 그 복사본이나 링크를 소셜 미디어 등 외부 플랫폼에 배포하는 방식
  • 원본 게시물에는 정규 URL과 permashortlink를 포함해, 복사본에서도 원본으로 직접 접근 가능
  • 이 구조는 콘텐츠 소유권 확보와 검색엔진 최적화, 외부 서비스 장애로부터의 독립성을 동시에 달성함
  • Twitter, Facebook, Medium, Mastodon 등 다양한 플랫폼에서 자동 또는 반자동 POSSE 구현 사례가 존재
  • IndieWeb 운동의 핵심 개념으로, 분산적 게시와 인간 중심의 연결성을 실현하는 중요한 접근 방식

POSSE 개요

  • POSSE(Publish on your Own Site, Syndicate Elsewhere) 는 개인이 자신의 사이트에 콘텐츠를 먼저 게시하고, 그 복사본이나 링크를 소셜 미디어 등 제3자 플랫폼에 배포하는 방식
    • 각 복사본에는 원본 게시물 링크(original post link) 를 포함해 사용자가 직접 원본과 상호작용할 수 있도록 함
    • IndieWeb 운동의 핵심 개념으로, 개인이 콘텐츠의 소유권과 접근 경로를 통제할 수 있게 함

POSSE의 목적

  • 친구들이 자신이 선호하는 플랫폼에서 글을 읽을 수 있도록 지원하며, Instagram, Tumblr, Twitter, Neocities 등 다양한 소셜 미디어 사일로(silo) 를 통해 접근 가능
  • 현재의 관계 유지를 우선시하며, 기술적 연합보다 인간 중심의 연결성을 중시함
  • 단일 문화(monoculture) 적 접근과 달리, 블로깅이나 특정 플랫폼 중심이 아닌 분산적 게시 구조를 지향함

일반적 이유

  • 제3자 의존도 감소: 자신의 사이트에서 직접 게시하므로 외부 서비스 장애에 영향을 받지 않음
  • 콘텐츠 소유권 확보: 자신의 도메인에 원본이 존재해 서비스 약관(TOS) 에 구속되지 않음
  • 정규 URL(canonical URL) 을 유지하고, 복사본이 원본을 인용함으로써 검색 효율 향상
  • 백피드(backfeed) 를 통해 외부 서비스의 반응을 역으로 가져올 수 있으며, 소셜 네트워크 효과를 활용하면서도 원본은 자신의 사이트에 저장

원본 링크 포함의 중요성

  • 원본 콘텐츠 발견성 향상: 복사본에서 permashortlink를 통해 원본으로 접근 가능
  • 스팸 복제 방지: 복사본이 재게시되어도 원본 링크가 함께 복제되어 원본 노출 증가
  • 검색엔진 랭킹 향상: 복사본이 원본을 링크함으로써 검색엔진이 이를 인식해 원본의 순위 상승

구현 방법

  • 게시 소프트웨어는 콘텐츠를 자신의 사이트에 게시한 후, 선택한 사일로(silo) 에도 복사본을 게시해야 함
    • 복사본에는 원본 게시물 링크(permashortlink 또는 permashortcitation) 를 포함
  • 원본 게시물에는 posts-elsewhere 섹션을 추가해 각 사일로 복사본으로의 링크를 제공

  • 사용자 인터페이스

    • 이상적인 UI는 자동적이고 예측 가능하며 눈에 띄지 않는 형태
    • 게시 전 미리보기(Preview) 기능을 제공해 각 플랫폼에 어떻게 게시될지 확인 가능

주요 플랫폼별 구현 예시

  • Twitter

    • 가장 일반적인 POSSE 대상 플랫폼으로, 자신의 사이트에서 작성한 노트를 Twitter에 POSSE하면 데이터 소유권 확보 가능
    • API를 통한 게시가 가능하지만, 2022년 11월 이후 새 API 접근이 제한됨
    • 웹 액션 엔드포인트를 지원해 반자동 게시 구현이 용이

  • Facebook

    • 수동 크로스포스트 또는 Bridgy 브라우저 확장을 통한 반자동 POSSE 가능

  • Medium

    • Posts API 또는 Import Post 기능을 통해 원본 URL의 rel-canonical 링크 유지
    • WordPress용 Medium 플러그인, Jekyll용 crosspost 플러그인 등 다양한 도구 존재
    • 대량 이전(mass POSSE) 기능으로 기존 게시물도 이전 가능

  • WordPress

    • WordPress Crosspost 플러그인을 사용해 자가 호스팅 WordPress에서 WordPress.com으로 POSSE 가능

  • Ghost

    • GitHub 오픈소스 도구를 통해 Ghost 웹훅으로 새 게시물을 JSON 형식으로 받아 Mastodon, Bluesky에 동기화

  • Plain Text Notes

    • SMS나 푸시 알림 등 순수 텍스트 기반 목적지를 위한 변환 필요
    • h-entry_to_text 방식으로 HTML을 텍스트로 변환

POSSE 관련 소프트웨어

  • PHP: php-helpers의 POSSE 네임스페이스에 HTML→plaintext 변환 및 신디케이션 함수 포함
  • Python:
    • SiloRider: 명령줄 도구로 Twitter, Mastodon 등 POSSE 지원
    • Feed2Toot: RSS 피드를 ActivityPub 기반 서비스(Mastodon, Pleroma 등)에 게시
  • Docker: POSSE Party는 셀프호스팅 가능한 POSSE 소프트웨어

POSSE 서비스

  • Bridgy Publish: POSSE-as-a-service 형태로 Twitter, Flickr, GitHub, Mastodon 지원
    • 웹 인터페이스 또는 webmention API로 사용 가능
  • Mugged Tweets: 노트를 머그컵에 POSSE하는 실험적 서비스
  • IFTTT: RSS/Atom 피드를 기반으로 Twitter, Tumblr, Facebook 등으로 자동 재게시
  • EchoFeed: 추가적인 신디케이션 서비스

게시 흐름

  • Client → Site → Silo

    • 사용자가 클라이언트에서 콘텐츠 작성 → 서버로 게시 → 서버가 각 사일로에 복사본 게시
    • 장점: 사용자는 자신의 사이트만 다루면 되며, 서버가 자동으로 신디케이션 수행

  • Client → Site & Silo

    • 사용자가 콘텐츠 작성 후 서버에 게시 → 클라이언트가 서버에서 URL 조회 → 사용자가 게시할 플랫폼 선택
    • 장점: 복사본의 내용과 시점을 사용자가 직접 제어 가능
    • 단점: 매번 수동 단계 필요, 클라이언트가 각 사일로에 직접 연결되어야 함

IndieWeb 구현 사례

  • Tantek.com (2010)

    • Falcon 기반으로 POSSE 구현, PuSH v0.4 + h-feed로 실시간 신디케이션
    • Twitter, Facebook으로 자동 복사 및 permashortlink 인용 링크 포함
    • Bridgy를 통해 Facebook RSVP 및 좋아요(like) 반영

  • Waterpigs.co.uk (2012)

    • Client → Server → 3rd Party 흐름 사용
    • Twitter, Facebook으로 신디케이션
    • Taproot 시스템으로 업데이트 시 추가 POSSE 트윗 생성
    • Bridgy로 업데이트 트윗의 반응도 역신디케이션

  • BrennanNovak.com (2012)

    • Twitter, Facebook으로 복사본 게시

  • AaronParecki.com (2012)

    • Twitter에 permashortlink 포함 트윗 게시
    • 모든 컬렉션이 PuSH 구독 가능

  • Sandeep.io (2012)

    • Facebook, Twitter, Google+의 공유 링크를 수동 클릭하는 방식으로 POSSE
    • API 통합의 불안정성을 피하기 위해 단순한 수동 접근 유지

  • Werd.io (2013)

    • idno 플랫폼의 플러그인 구조로 POSSE 구현
    • Twitter, Facebook, Flickr, Foursquare 등으로 콘텐츠 유형별 신디케이션

  • Veganstraightedge.com (2013)

    • Dark Matter 기반 수동 POSSE
    • Medium, WordPress, Twitter, Vine 등으로 rel-syndication 마크업 포함

  • GlennJones.net (2014)

    • transmat.io 시스템을 이용해 POSSE 구현
    • 현재는 노트(note) 게시물만 Twitter로 신디케이션

추가 구현 사례

  • Jeremy Keith

    • 2014년 커스텀 CMS를 이용해 POSSE 구현, 노트는 자신의 사이트에 먼저 게시 후 외부로 복제
    • 사진은 Twitter와 Flickr로 동시 게시됨

  • Shane Hudson

    • 2014년 Craft CMS를 이용해 Twitter로 POSSE 구현
    • 답글 컨텍스트 기능을 수동으로 처리하며, 사진 POSSE 자동화를 계획 중

  • Ravi Sagar

    • 2018년 Drupal 기반 블로그에서 POSSE 구현
    • “Share” 태그가 붙은 게시물을 RSS 피드 + Rebrandly + Zapier로 Twitter, LinkedIn에 자동 공유

  • Ludovic Chabant

    • 2018년 PieCrust CMS와 SiloRider를 이용해 Twitter, Mastodon으로 POSSE 구현
    • Microformats 마크업 기반으로 작동하며, 사진 게시물도 지원

  • Adam Dawkins

    • 2019년 커스텀 CMS로 POSSE 구현, 첫 노트를 자신의 사이트에 게시 후 Twitter로 복제

  • Shaun Ewing

    • 2020년 Jekyll과 커스텀 API로 POSSE 구현, 현재는 수동 동기화 상태

  • capjamesg

    • 자신의 사이트 노트를 Twitter(brid.gy), micro.blog(feed polling), Fediverse(fed.brid.gy) 로 자동 동기화

  • Wojtek Powiertowski

    • 2026년 Ghost 블로그에서 작성한 게시물을 Mastodon, Bluesky로 자동 동기화
    • 자체 호스팅한 posse 클라이언트를 이용해 새 게시물 작성 시 자동 동기화

부분 POSSE 사이트

  • Hupili.net

    • 일부 콘텐츠만 POSSE하는 부분 POSSE 모델을 구현
    • SNSAPI로 여러 SNS의 데이터 구조를 통합하고, SNSRouter로 타임라인을 통합 조회
    • 현재는 원본과 복제본 구분이 어렵지만, 향후 각 상태 업데이트마다 고유 퍼머링크 페이지를 생성할 계획

다른 접근 방식

  • COPE (Create Once, Publish Everywhere)

    • 한 번 작성해 여러 곳에 게시하지만 자신의 사이트에 먼저 게시하지 않음
    • 원본 퍼머링크 부재로 독자가 여러 플랫폼에 분산됨

  • POSE (Publish Once Syndicate Everywhere)

    • POSSE의 전신으로, 특정 소셜 플랫폼(silo) 에 한 번 게시한 뒤 다른 플랫폼으로 복제

  • PESOS (Post Elsewhere, Syndicate to Own Site)

    • POSSE의 반대 접근으로, 외부 서비스에 먼저 게시한 뒤 개인 사이트로 복제
    • 복제본에 원본 링크(permalink) 를 포함해야 POSSE와 구분 가능

  • PESETAS

    • PESOS와 유사하지만, 모든 콘텐츠를 특정 플랫폼으로 복제
    • Tumblr는 다양한 콘텐츠 형식을 지원해 PESETAS 목적지로 적합

POSSE 확장 아이디어 (CRUD 모델)

  • Create

    • 자신의 사이트에서 콘텐츠를 작성하고 외부로 배포

  • Read

    • u-syndication 링크로 복제본 위치를 저장하고, 역방향 동기화(backfeed) 를 가능하게 함

  • Update

    • 외부 플랫폼이 수정 기능을 지원할 경우 원본 수정 시 복제본도 갱신
    • 수정 불가한 경우 삭제 후 재게시(delete/repost) 방식 사용

  • Delete

    • 원본 삭제 시 복제본도 함께 삭제 가능
    • 댓글이나 리트윗이 존재할 경우 삭제 재확인 UI 필요
    • Grant Richmond는 2018년부터 Twitter에서 POSSE 삭제 기능 지원

FAQ

  • 검색엔진 중복 방지를 위해 복제본은 반드시 원본 링크를 포함하고, 가능하면 rel-canonical 사용
  • 백링크 없는 POSSE는 최후의 수단이며, posse-post-discovery 기능으로 보완 가능
  • POSSE와 Webmention 순서는 POSSE 먼저, Webmention 나중

배경

  • 2010년 Tantek Çelik이 “자신의 사이트에 게시하고, 다른 사이트로 배포하라”는 개념으로 POSSE 제시
  • 2011년 IndieWebCamp에서 개념 확장, 2012년 6월 POSSE 용어 공식 정의
  • POSE가 POSSE보다 먼저 존재했으나, POSSE는 “자신의 사이트” 중심 구조를 명시

관련 기사 및 인용

  • 2013~2024년 사이 다양한 매체에서 POSSE 개념이 소개됨
    • Ars Technica는 POSSE를 “하나의 원본에서 모든 플랫폼으로 배포하는 방식”으로 설명
    • Molly White, Cory Doctorow 등은 POSSE를 콘텐츠 소유권 회복 전략으로 강조
    • 2024년 이후 POSSE는 Bluesky, Mastodon, Fediverse 등 분산형 네트워크와 연계되어 재조명됨

POSSE의 확장 적용

  • Git 저장소 POSSE: 개인 Git 리포지터리를 GitHub, GitLab 등으로 복제하는 방식으로 확장 가능
  • POSSE 세션 기록: 2011년부터 2024년까지 IndieWeb 커뮤니티에서 POSSE 관련 세션 지속 개최

각주 및 라이선스 정보

  • 문서 출처는 IndieWeb 위키 페이지(https://indieweb.org/wiki/index.php?title=POSSE&oldid=107734)
  • 페이지는 building-blocks 및 syndication 카테고리에 포함
  • 마지막 수정일은 2026년 1월 16일 17:04
  • 콘텐츠는 CC0 퍼블릭 도메인 헌정(CC0 public domain dedication) 하에 제공됨
  • 추가 링크로 Privacy policy, About IndieWeb, Code of Conduct 등이 포함됨
  • 하단에는 Creative Commons 퍼블릭 도메인 및 MediaWiki 관련 링크 표시
▲
GN⁺ 12시간전  [-]
Hacker News 의견들

  • 나는 이 방식을 꾸준히 따르고 있음. 게시 과정은 수동이지만, 의도가 좋고 여러 포럼에 스팸성 블로그 홍보만 하지 않으면 꽤 잘 작동함
    내 블로그(rednafi.com)에는 댓글 섹션을 일부러 넣지 않았음. 글을 쓰는 건 유료 일이 아니고, 댓글을 관리하는 데 너무 많은 에너지가 들기 때문임
    예전에 Hugo 사이트에 Disqus를 붙였는데, 실제 토론이 길어지자 확장성 문제가 심각했음
    글이 유용하다면 보통 HN이나 Reddit에 자연스럽게 올라오고, 나는 그 토론 링크를 글에 다시 연결함. 그 정도면 충분하다고 생각함

    • 나도 같은 방식으로 운영 중임. 예를 들어 이 글처럼 여러 플랫폼의 링크백을 관리함
      소셜 URL들은 YAML frontmatter에 키로 넣고, standard.site를 통해 ATProto 생태계에도 등록함
      긴 글은 rogue-scholar.org에서 DOI를 받아 메타데이터를 추가함
      언젠가 이 모든 걸 하나의 정적 댓글 스레드로 모으는 게 목표지만, 네트워크 간 대화가 거의 없어서 지금처럼 링크만 두는 게 현실적임
    • 나는 HN을 댓글 플랫폼으로 사용함. Hugo shortcode로 HN 댓글을 캐시해두고, 7일 이내의 글만 새로 불러오게 함
      포맷도 꽤 깔끔하게 나오며, 이 글 하단에서 확인 가능함
    • Mastodon 계정이 있다면, 해당 포스트의 모든 응답 스레드를 사이트에 임베드할 수 있음
      구현 예시는 이 글 참고
    • 블로그 잘 봤음. 특히 Splintered Failure Modes 글이 인상 깊었음. 한 번 읽고 바로 기억에 남았음

  • 나는 이 접근법을 따름. 이유는 내가 만든 공간을 직접 소유하고 싶기 때문임
    잘 작동하지만 자동화가 어렵고, 결국 수동으로 크로스포스팅해야 함. 커뮤니티마다 반응이 달라서 트래픽은 적지만, 공개 작업 방식으로는 훌륭함

    • 자동화가 어려운 이유는 소셜미디어들이 의도적으로 자동 포스팅을 어렵게 만들어놨기 때문임
      Facebook은 외부 링크가 포함된 게시물을 노출 우선순위에서 낮추기도 함. 그래서 “링크는 댓글에” 같은 꼼수가 생긴 것임
    • 나는 동의하지 않음. micro.blog 같은 서비스는 여러 소셜에 손쉽게 자동 크로스포스팅을 지원함
      트래픽보다는 다양한 커뮤니티에서 활동하는 게 목적이라면 충분히 가치 있음
    • 각 플랫폼의 문화와 청중이 달라서 토론의 결이 다름. 모든 곳에 똑같이 올리는 건 약간 스팸처럼 느껴질 수도 있음
      그래서 크로스포스팅의 효용이 사람마다 다름
    • 혹시 Buffer.co 같은 포스팅 서비스를 써본 적 있는지 궁금함

  • 나는 여러 플랫폼에서 POSSE를 자주 접하는 입장인데, 이 방식이 비인격적이고 스팸성으로 느껴질 때가 있음
    이유는 이해하지만, 대화보다는 “출시 중심(ship it)” 접근처럼 보임. 나이 탓일 수도 있음

    • standard.site 같은 atproto 기반 퍼블리싱은 여러 채널에 올리지 않아도 콘텐츠를 쉽게 발견할 수 있게 해주는 방향으로 발전 중임
    • 무엇이 비인격적으로 느껴지는지 궁금함. 오히려 독자에게 특정 플랫폼을 강요하지 않는 점이 장점이라고 생각함

  • 작은 웹을 위한 멋진 기능을 상상해봄

    1. 내가 좋아하는 블로그를 RSS로 구독
    2. 새 글이 올라오면 RSS 리더에서 HN, Reddit, Twitter 등 토론 링크를 함께 확인
    3. 클릭해서 그곳에서 대화 참여
      단순 버전은 글 하단에 관련 토론 링크를 두는 것임
    • 나도 동의함. RSS 리더에서 글을 보고 싶지, 소셜 피드에 무작정 던져지는 건 원치 않음
      단순히 “새 글 올렸어요” 식의 포스트는 스팸처럼 느껴짐.
      외부 토론을 찾는 건 복잡하지만, 진짜 관심 있다면 URL 검색으로 충분함. permashortlink는 오히려 방해됨
    • 이걸 가능하게 하려면 WebMentions가 원래 그 역할을 하도록 설계된 것으로 알고 있음

  • 이런 글이 가끔 올라올 때마다 정말 반가움. 모두가 자신의 콘텐츠를 직접 소유해야 함
    indieweb 커뮤니티의 철학은 기념할 만함.
    가능하다면 Homebrew Website Club에 가서 자신만의 웹 공간을 만드는 이야기를 나눠보길 권함. 기술에 대한 애정을 다시 느낄 수 있음

    • 나도 그런 마음으로 tildeweb.nl을 만들었음

  • 처음엔 이 글이 빅테크의 홍보글처럼 느껴졌음. “결국 대기업이 이길 테니 모든 곳에 퍼뜨려라” 같은 뉘앙스였음
    하지만 왜 굳이 Facebook만 쓰는 친구에게 내 블로그를 보여줘야 하는지 모르겠음.
    나는 내 원칙에 공감하는 사람들과만 나누고 싶음

    • 흥미로운 시각임. 어떤 사람은 가능한 한 많은 사람에게 글을 보여주고 싶어하고, 어떤 사람은 조용히 공유하고 싶어함
      나이 들수록 온라인에 글을 올리는 게 조심스러워짐. 자기 인식과 성숙함의 표현일 수도 있음 — 모두가 내 글을 보고 싶어하는 건 아니니까

  • 나는 글을 읽을 때 HN이나 Reddit의 주요 토론 링크가 함께 있는 걸 좋아함
    블로그 댓글은 보통 조용하고, 며칠 늦게 읽더라도 다른 사람의 생각을 따라가기 좋음

    • “주요 토론”이라는 개념 자체가 슬픔. 인터넷이 앱화(appification) 되면서 우리는 폐쇄된 정원 속 사고방식에 익숙해졌음
      브라우저가 스스로 관련 링크를 찾아 보여주는 구조가 되어야 함.
      ActivityPub과 Linked Data를 다루다 보면, 많은 프로젝트가 여전히 폐쇄형 SNS를 모방하려는 점이 답답함

  • RSS는 단순하고 신뢰할 수 있는 방식으로, 알고리즘 큐레이션에 휘둘리지 않고 내가 보고 싶은 걸 직접 제어하게 해줌

  • 나도 이 방식을 따름. 내 사이트는 프로필에 있음
    permashortlink는 생략하고, 짧고 의미 있는 원본 링크를 유지함.
    링크만 봐도 어떤 콘텐츠인지 짐작할 수 있고, POSSE 덕분에 이런 개인적 선호를 쉽게 반영할 수 있음

    • 나도 permashortlink는 불필요한 개념이라고 생각함.
      indieweb.org/permashortlink에 이유가 나열되어 있지만, 대부분 설득력이 없음
      이메일에서 더 안정적이라거나, 짧아서 입력이 편하다는 주장은 의미가 약함
      오히려 관리 비용과 도메인 분산 문제만 생김. 그냥 기존 URL 구조를 개선하는 게 낫다고 봄

  • 나는 반대로 PESOS(Publish Elsewhere, Syndicate to Own Site) 방식을 씀
    자동화 시스템 덕분에 웹 전반의 활동을 내 사이트에 모아두고, 필요할 때 쉽게 참고함. 매우 추천함

    • vale.rocks 사이트를 봤는데 정말 영감을 받았음. 좋은 하루 되길 바람
답변달기