본문으로 건너뛰기
피드

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

frontend 약 5분

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

번은 좋은데, 이제 앤트로픽 품에 있어서 불안하다는 얘기

글쓴이는 번이 빠르고 실용적인 자바스크립트 런타임이라는 점은 인정하지만, 앤트로픽 인수 이후 장기적인 방향을 신뢰하기 어려워졌다고 말한다. 특히 클로드 코드의 품질 저하, 과금 혼란, 서드파티 하네스 제한 사례를 보며 번도 같은 제품 운영 방식에 휘말릴 수 있다고 우려한다.

frontend

왜 터미널 UI가 다시 뜨고 있나

데스크톱 네이티브 UI 툴킷이 플랫폼마다 흔들리고, Electron 앱은 일관성과 키보드 워크플로를 놓치면서 개발자들이 다시 터미널 사용자 인터페이스(TUI)로 돌아가고 있다는 글이다. 저자는 Claude, Codex 같은 명령줄 도구의 성공을 단순한 복고가 아니라, 운영체제 UI 생태계가 제공하지 못한 빠르고 자동화 가능한 인터페이스에 대한 반응으로 본다.

frontend

애플워치 지도 UI 하나에 6년을 갈아 넣은 이야기

Pedometer++ 개발자가 애플워치용 지도 경험을 6년 동안 다듬어 온 과정을 풀어낸 글이다. 서버 렌더링 지도에서 시작해 SwiftUI 기반 커스텀 렌더링 엔진, 전용 베이스맵, Liquid Glass 대응, 최종 UI 구조까지 실제 제품 설계의 시행착오가 꽤 생생하게 담겨 있다.

frontend

애플, Studio Display XDR에 새 색상 기준 Apple CMF 2026 적용

애플이 새 Studio Display와 Studio Display XDR을 내놓으면서 Apple CMF 2026이라는 새 색상 매칭 함수 기준을 같이 공개했음. 단순히 애플식 독자 표준처럼 보이지만, 실제로는 CIE와 협력하고 측정 장비 업체들과도 통합을 추진하는 쪽에 가까움. 테스트 결과 일반 Studio Display는 준수한 P3·sRGB 정확도를 보였고, XDR은 2304개 로컬 디밍 존과 2000니트 HDR을 앞세웠지만 모드별 정확도 차이가 꽤 컸음.

frontend

Figma의 'Sketch 모멘트'가 온다 — Claude Design이 바꾸는 디자인 도구 지형

디자이너 Sam Henri Gold가 Claude Design을 체험한 뒤 디자인 도구의 source of truth가 다시 코드로 이동할 것이라고 주장했다. Figma의 폐쇄적 포맷은 LLM 학습 데이터에서 사실상 제외됐고, agentic 시대에는 HTML/JS 같은 모델이 잘 아는 매체에서 작업하는 Claude Design류가 우위를 가져간다는 예측이다.