본문으로 건너뛰기
피드

내 사이트에 먼저 올리고 SNS는 그냥 배포 채널로 써라 - POSSE 전략

frontend 약 5분
vote
0
댓글
북마크

POSSE(Publish on your Own Site, Syndicate Elsewhere)는 콘텐츠를 내 사이트에 먼저 올리고, 트위터/인스타/페북 같은 SNS에는 복사본만 뿌리는 방식임. 데이터 소유권도 챙기고 SNS 팔로워도 놓치지 않는 ㄹㅇ 실용적인 전략. IndieWeb 운동의 핵심 철학이기도 함.

  • 1

    내 도메인에 원본 발행 후 SNS는 배포 채널로만 활용 → 플랫폼 종속 탈피

  • 2

    Bridgy, SiloRider, IFTTT 등으로 자동화 가능 (개발자 아니어도 OK)

  • 3

    PESOS와 달리 원본 소유권이 명확하고 SEO에도 유리

  • 내 도메인에 원본 올리고 → SNS엔 링크+요약본만 배포하는 POSSE 전략
  • SNS가 망하거나 계정 짤려도 내 콘텐츠는 내 서버에 그대로 남음 ㄷㄷ
  • Backfeed 기능으로 SNS 댓글/좋아요를 내 사이트로 역수입도 가능
  • Bridgy, SiloRider, IFTTT 등 자동화 도구들이 이미 존재함 (개발자 아니어도 됨)
  • PESOS(SNS 먼저 → 내 사이트로 복사)랑 반대 개념, POSSE가 소유권 측면에서 훨씬 유리

POSSE가 뭔데?

POSSEPublish on your Own Site, Syndicate Elsewhere의 약자임. 번역하면 "내 사이트에 먼저 발행하고, 다른 곳엔 퍼뜨려라" 정도.

트위터에 직접 올리는 게 아니라, 내 블로그에 먼저 올리고 → 그 링크+요약을 트위터에 뿌리는 방식. 원본은 항상 내 도메인에 있음.

왜 씀?

  • 플랫폼 종속 탈출: 트위터가 API 막거나 서비스 망해도 내 콘텐츠는 멀쩡함. 실제로 2022년에 트위터가 POSSE/Backfeed 앱들 API 새로 안 줬던 사례 있음.
  • 소유권 명확: 내 사이트에 먼저 올렸으니 원본 증명 가능. PESOS는 뭐가 원본인지 구분이 안 됨.
  • 검색 최적화: 복사본들이 원본 링크를 달고 돌아다니니까 내 사이트 SEO에 유리함. 스패머가 내 글 퍼가도 원본 링크까지 같이 퍼감 ㅋㅋ (인터넷 합기도)
  • 친구들 어디 있든 커버: 인스타 쓰는 친구, 트위터 쓰는 친구, RSS 쓰는 친구 전부 챙길 수 있음.

구현 방법

크게 두 가지 플로우가 있음:

1. 클라이언트 → 내 서버 → SNS (풀 자동화)

  • 글 쓰면 서버가 알아서 각 SNS에 복사본 뿌림
  • 사용자는 내 사이트 하나만 신경 쓰면 됨
  • 개발자한테는 제일 깔끔한 방식

2. 클라이언트 → 내 서버 + 직접 SNS 포스팅 (반수동)

  • 서버에 올린 다음, 클라이언트가 SNS별로 UI 보여줌
  • 각 SNS에 맞게 내용 수정 가능
  • 타이밍이나 문구를 직접 컨트롤하고 싶을 때 좋음

어떤 도구들이 있냐

  • Bridgy Publish: POSSE-as-a-service. 트위터, Flickr, GitHub, Mastodon 지원. 웹멘션으로 연동 가능.
  • SiloRider (Python): 커맨드라인 툴, 트위터/Mastodon 지원
  • Feed2Toot (Python): RSS 파싱해서 ActivityPub 기반 서비스에 자동 포스팅
  • IFTTT: RSS/Atom 피드로 트위터, 텀블러, 페북에 자동 재포스팅
  • WordPress Medium Plugin: 워드프레스에서 미디엄으로 자동 POSSE
  • POSSE Party: 셀프호스팅 가능한 올인원 소프트웨어

실제 사용자들

IndieWeb 커뮤니티에서 2010년대 초부터 꾸준히 실천해온 사람들 많음:

  • Tantek Çelik: 2010년부터 자기 사이트 → 트위터 → 페북 자동 연동
  • Aaron Parecki: permashortlink 포함해서 트위터에 POSSE
  • Jeremy Keith: 노트, 사진까지 트위터/Flickr에 POSSE
  • behindtheviewfinder.com (2026년 최신): Ghost 블로그 → Mastodon, Bluesky 자동 배포

POSSE vs 유사 개념들

개념 설명
POSSE 내 사이트 먼저 → SNS 복사 (갓)
PESOS SNS 먼저 → 내 사이트 복사 (원본 증명 어려움)
COPE Create Once, Publish Everywhere (원본 개념 없이 여러 곳에 복제)
PESETAS SNS끼리만 크로스포스팅 (내 사이트 없음)

검색엔진 중복 콘텐츠 걱정?

복사본들이 원본 링크를 달고 있으면 검색엔진이 알아서 원본을 파악함. 이상적으로는 rel-canonical 태그 달아주면 더 명확하고, 그냥 링크만 있어도 웬만큼 인식함.

트위터가 개박살나고 인스타가 알고리즘 갈아엎는 거 보면서도 SNS에 직접 올리는 사람들 많은데, POSSE는 ㄹㅇ 10년 넘은 개념인데도 지금이 제일 필요한 시점 아닌가 싶음. 내 콘텐츠는 내가 소유해야지.

댓글

댓글

댓글을 불러오는 중...

frontend

개인 웹사이트에 JSON-LD 넣는 법, 검색엔진과 크롤러가 내 사이트를 제대로 읽게 만들기

개인 웹사이트에 JSON-LD 구조화 데이터를 추가해 검색엔진과 크롤러가 사이트, 사람, 글, 프로젝트를 더 정확히 이해하게 만드는 실전 가이드야. WebSite, Person, ProfilePage, BlogPosting 같은 노드를 어떻게 연결하고 어느 페이지에 넣어야 하는지 예시 중심으로 설명해.

frontend

Deno, 웹 프로젝트를 데스크톱 앱으로 묶는 `deno desktop` 공개

Deno가 TypeScript 파일 하나부터 Next.js 앱까지 데스크톱 앱으로 패키징하는 `deno desktop`을 공개했다. 아직 안정 릴리스는 아니고 Deno v2.9.0 canary에서만 쓸 수 있지만, 운영체제 WebView 기반의 작은 바이너리, 프레임워크 자동 감지, 내장 자동 업데이트까지 한 번에 노린다.

frontend

파비콘 안에 웹사이트를 숨겨 넣은 개발자, 진짜 됨

한 개발자가 웹사이트의 파비콘 이미지를 작은 저장소처럼 사용해 HTML을 픽셀 RGB 값 안에 넣고, 브라우저에서 다시 읽어 렌더링하는 실험을 했다. 208바이트짜리 HTML payload에 4바이트 길이 헤더를 붙여 총 212바이트를 만들었고, 이를 9x9 픽셀 PNG 안에 87% 사용률로 저장했다.

frontend

스크린이 절대 못 보여주는 색은 어디에 있을까

이 글은 우리가 화면에서 보는 색이 인간이 볼 수 있는 색 전체가 아니라, sRGB와 Display-P3 같은 색역 안에 갇힌 일부라는 점을 파고든다. 특히 숲, 바닷속, 새와 나비의 구조색, 생물발광, 교통신호 LED 같은 실제 세계에는 모니터와 카메라가 제대로 담지 못하는 청록색과 녹색 계열이 꽤 많다는 얘기다. 디스플레이, 카메라, 조명, 렌더링을 다루는 개발자라면 “색상값 하나”가 생각보다 물리와 표준의 타협이라는 걸 체감하게 된다.

frontend

크롬, 매니페스트 버전 2 우회로까지 닫는다

구글 크롬이 매니페스트 버전 2 확장 지원을 사실상 최종 종료 단계로 밀어넣고 있다. 기존에는 플래그나 레지스트리 설정으로 유블록 오리진 같은 확장을 살리는 우회가 있었지만, 크로미움 150과 151을 거치며 그 우회 코드까지 제거되는 흐름이다.