IndieWeb에 참여해 배운 것

• IndieWeb는 개인 도메인에 콘텐츠·정체성·대화를 보존하면서 필요에 따라 소셜 네트워크와 연결하는, 기업 중심 웹의 사람 중심 대안이자 커뮤니티임
• 자체 도메인을 기반으로 microformats2, rel="me", Webmention, IndieAuth, Micropub 같은 작은 표준을 조합해 HTML을 기계가 읽게 하고 사이트 간 인증·발행·대화를 지원함
• GeoCities의 2,300만 페이지와 MySpace의 5,000만 곡 이상이 사라졌으며, 2024년 Pew Research 조사에서도 2013년에 존재하던 웹페이지의 38%가 10년 뒤 접근 불가 상태였음
• POSSE는 원본을 자신의 사이트에 먼저 발행한 뒤 외부 플랫폼에 배포하며, Backfeed는 외부의 좋아요·답글·재게시를 Webmention으로 원본에 돌려보내 전체 대화를 개인 도메인에 보존함
• 실제 사이트에는 Webmention, h-entry, h-card, rel="me"를 적용했지만 기존 Git·Markdown 작업 방식이나 24시간 발행 지연과 맞지 않는 Micropub, IndieAuth, WebSub는 제외했으며, 모든 규격보다 필요한 기술부터 점진적으로 적용하는 편이 적합함

IndieWeb가 지향하는 웹

• IndieWeb는 자신을 “기업 웹에 대한 사람 중심의 대안”으로 정의하며, 특정 소프트웨어나 프레임워크보다 여러 접근법과 프로젝트를 수용하는 이념적 기반에 가까움
• 2010년 Aaron Parecki와 Tantek Çelik은 Portland의 Federated Social Web Summit에 참석한 뒤 프로토콜보다 창작자 중심의 접근이 필요하다고 판단함
  • 2011년 Portland에서 첫 IndieWebCamp가 열렸고, 이후 세계 각지에서 매년 개최됨
  • Homebrew Website Club에서는 참가자들이 모여 자신의 개인 웹사이트를 개선함
• IndieWeb를 이루는 세 기둥은 다음과 같음
  • 콘텐츠 소유권: 웹에 올린 콘텐츠는 기업이 아니라 게시자에게 속해야 함
  • 더 나은 연결성: 글을 여러 플랫폼에 배포하고 외부의 답글과 좋아요를 자신의 사이트로 다시 가져올 수 있어야 함
  • 통제권: 원하는 형식으로 게시하고 읽을 수 있으며, 영속적인 URL을 유지해야 함
• 소셜 네트워크 사용 자체를 금지하지 않지만, 콘텐츠와 상호작용을 가두는 폐쇄형 생태계에는 반대함

사일로와 웹 콘텐츠 소멸

• 사일로(silo)는 일반적으로 영리 기업이 운영하면서 사용자가 기여한 콘텐츠에 권리를 요구하거나 접근을 제한하는 중앙화된 웹사이트임
  • 참여하려면 서비스별 계정이 필요함
  • 같은 서비스의 계정끼리만 상호작용할 수 있음
  • 제한적인 이용 약관, 콘텐츠 라이선스 요구, 검색 색인 차단, 가져오기·내보내기 장벽이 추가되기도 함
• 사일로가 종료되면 사용자의 콘텐츠도 함께 사라질 수 있음
  • GeoCities는 Yahoo가 2009년 10월 26일 종료하면서 2,300만 페이지가 사라짐
  • MySpace는 2019년 서버 이전 과정에서 첫 12년 동안 1,400만 아티스트가 올린 5,000만 곡 이상을 잃음
  • Google+ 는 2019년 4월 종료됨
  • Posterous, FriendFeed, Vine, Yahoo Groups, TinyLetter, Cohost 등도 종료 목록에 포함됨
• 사일로가 폐쇄되지 않더라도 웹 콘텐츠는 사라질 수 있음
  • 2024년 Pew Research 조사에 따르면 2013년에 존재한 웹페이지 중 38%가 10년 뒤 접근 불가 상태였음
• 대응 원칙은 소셜 네트워크를 쓰지 않는 것이 아니라 콘텐츠의 정본(canonical copy) 을 자신이 통제하는 도메인에 두는 것임

커뮤니티의 11가지 원칙

• 11가지 원칙은 우선순위가 아니며, 모두 충족해야 하는 의무도 아님
  1. 데이터 소유: 콘텐츠·메타데이터·정체성을 자신의 도메인에 두고 장기적으로 접근권을 유지함
  2. 보이는 데이터 사용과 발행: 사람을 우선하고 기계를 그다음에 고려하며, HTML에 데이터를 담을 수 있다면 별도 API를 만들지 않음
  3. 자신에게 필요한 것 제작: 존재 여부가 불분명한 가상 사용자가 아니라 실제 자신을 위한 도구를 만듦
  4. 직접 사용: 만든 것을 매일 사용하며 의존할 가치가 있는지 검증함
  5. 문서화: 과정·아이디어·코드를 자신의 사이트에 기록해 다른 사람과 미래의 자신을 도움
  6. 오픈소스화: 의무는 아니지만 다른 사람이 독립 웹에 더 빨리 참여하도록 도움
  7. 프로토콜보다 UX: 사용자 경험을 먼저 정하고 이를 지원하는 가장 단순하고 작은 프로토콜만 사용함
  8. 모듈성: 특정 기기·언어·플랫폼에 종속되지 않도록 작고 느슨하게 결합된 구성요소를 만듦
  9. 장기 존속성: 발전을 이유로 몇 년마다 기존 작업을 폐기하지 않아도 되는 웹 기술을 구축함
  10. 다원성: 여러 접근법을 의도적으로 장려해 단일한 기술 문화보다 회복력 있는 커뮤니티를 만듦
  11. 즐거움: 1990년대 웹처럼 이상하고 흥미로운 개인적 표현을 유지함

개인 도메인에서 시작하는 기술 구조

• 자체 도메인을 온라인의 주 정체성으로 사용하는 것이 모든 구성의 전제임
  • 호스팅이나 CMS를 바꾸더라도 도메인을 유지하면 링크·독자·검색 순위를 이어갈 수 있음
  • 커뮤니티가 IndieWeb 참여로 인정하는 최소 조건이기도 함
• IndieWeb는 단일 플랫폼 대신 서로 조합할 수 있는 작은 규격들을 사용하며, 공식 규격 색인은 구현 연혁과 보급 범위에 따라 정리되어 있음

microformats2: HTML을 API로 사용하기

• microformats2는 별도 파일이나 API 없이 기존 HTML에 CSS 클래스를 추가해 콘텐츠를 기계 판독 가능하게 만듦
  • h-*: 루트 객체
  • p-*: 일반 텍스트
  • u-*: URL
  • dt-*: 날짜
  • e-*: 포함된 HTML
• h-card는 이름·URL·사진 등 개인 정체성을 나타내며, 애플리케이션이 게시물 옆에 프로필을 표시하고 사용자를 인식하도록 함
  • 이메일 기반 Gravatar와 달리 도메인을 기반으로 작동함
• h-entry는 게시물의 제목, 작성자, 발행일, 본문 등을 표시하는 IndieWeb 콘텐츠의 핵심 구성요소임
• h-feed는 여러 h-entry를 묶어 HTML 목록 페이지 자체를 구독 가능한 피드로 만듦
• 읽기에는 microformats를, 쓰기에는 Micropub을 사용해 “웹사이트가 곧 API”인 구조를 형성함

rel="me"와 분산 신원 확인

• rel="me"는 링크 대상이 현재 페이지와 같은 사람을 나타낸다는 사실을 선언함
• 웹사이트와 외부 프로필이 서로를 rel="me"로 연결하면 중앙 기관 없이 상호 신원 확인이 가능함
  • Mastodon은 이 구조로 도메인에 녹색 인증 표시를 제공함
  • Threads, PixelFed, GitHub, Keybase, Wikipedia도 지원함
• RelMeAuth는 홈페이지에서 연결한 GitHub 같은 OAuth 제공자에게 신원 증명을 위임해 개인 URL로 서비스에 인증함
  • IndieLogin 같은 서비스의 기반임

Webmention: 웹사이트 사이의 대화

• Webmention은 2017년 1월 12일부터 W3C Recommendation이며, Pingback을 계승해 플랫폼 없이 사이트 간 댓글·좋아요·답글·재게시를 전달함
• 전송 절차는 다음과 같음
  1. 발신 게시물이 상대 글의 링크를 포함함
  2. 발신 서버가 상대 글의 HTTP Link 헤더나 HTML의 <link rel="webmention">에서 수신 엔드포인트를 찾음
  3. 발신 글인 source와 대상 글인 target만 담은 POST 요청을 보냄
  4. 수신 서버가 source를 내려받아 실제로 target 링크가 있는지 검증함
  5. source의 h-entry를 분석해 답글·좋아요·재게시를 구분하고, h-card로 작성자의 이름과 사진을 표시함
• 각 사이트가 노드가 되고 사이트 사이 링크가 소셜 그래프를 구성하지만, 스팸과 중재 문제는 남아 있음
  • Vouch는 수신자가 이미 알고 있으며 발신 도메인에 링크한 보증 사이트를 세 번째 매개변수로 전달해 필터링 비용을 발신자에게 옮김
  • Salmention은 댓글에 답글이 달렸을 때 원 게시물이 참여자들에게 갱신 Webmention을 다시 보내 대화 스레드를 전파함
• 백엔드가 없는 정적 사이트는 webmention.io가 Webmention을 대신 수신하고 조회 API를 제공함
  • Hugo, Jekyll, Eleventy 같은 정적 사이트 생성기에 사용할 수 있음

도메인 기반 로그인과 발행

• IndieAuth는 Google이나 Facebook 계정 대신 개인 URL을 로그인 정체성으로 사용함
  • OAuth 2.0을 기반으로 사용자와 애플리케이션을 URL로 식별함
  • DNS가 사전 클라이언트 등록을 대신하며, 액세스 토큰 탈취를 방지하는 PKCE가 필수임
  • 서비스는 사용자 페이지의 rel="indieauth-metadata"에서 인증 서버를 찾고, 인증 완료 후 해당 URL에 대한 통제권을 확인함
  • 인증 방식으로 비밀번호, 이메일, RelMeAuth 등을 사용할 수 있음
• Micropub은 2017년 5월부터 W3C Recommendation이며, 사이트 소프트웨어와 발행 인터페이스를 분리함
  • 웹·iOS·Android 클라이언트가 개인 도메인의 게시물을 생성·수정·삭제할 수 있음
  • 비밀번호를 공유하던 MetaWeblog와 AtomPub 대신 IndieAuth로 받은 OAuth 토큰을 사용함
  • 별도 어휘를 만들지 않고 h=entry, content 등 h-entry 속성을 직렬화해 전송함

실시간 피드와 분리된 리더

• WebSub은 이전에 PubSubHubbub로 불렸으며, 2018년 1월부터 W3C Recommendation임
  • 구독자가 서버를 주기적으로 조회하는 대신 게시자가 허브에 새 글을 알리고, 허브가 웹훅으로 구독자에게 즉시 전달함
  • 서버 부하를 줄이고 갱신 지연을 없애며 Feedly와 NewsBlur 등이 지원함
• Microsub은 가장 새로운 규격으로 아직 초안 상태이며, 소셜 읽기 애플리케이션을 두 계층으로 분리함
  • 서버는 구독 관리, 피드 수집·분석, 데이터 정규화를 담당함
  • 클라이언트는 읽기 인터페이스만 표시해 UX로 경쟁할 수 있고, 구독 정보는 클라이언트 사이에서 이동 가능함
  • Micropub의 답글 발행과 Webmention의 알림을 결합하면 IndieWeb 소셜 리더 구조가 완성됨

POSSE, PESOS와 Backfeed

• POSSE는 자신의 사이트에 먼저 발행하고 외부에 배포하는 권장 전략임
  • 외부 복사본은 원본 링크를 포함하므로 독자는 기존 플랫폼에서 계속 읽고, 게시자는 정본을 유지함
  • 플랫폼이 종료되거나 계정을 차단해도 원본은 남음
  • Tantek Çelik이 2012년 용어를 만들었고 Cory Doctorow와 Molly White 등이 사용함
  • 스팸 사이트가 글을 복사해도 원본 링크까지 함께 복사하게 되는 효과를 “인터넷 합기도”라고 부름
• PESOS는 사일로에 먼저 게시한 뒤 자신의 사이트에 복사해 보관하는 반대 방식임
  • 완성도 높은 사일로 앱을 쓸 수 있고 개인 사이트가 중단돼도 게시할 수 있음
  • 처음부터 사일로 약관의 적용을 받고, 개인 사이트의 복사본이 정본이 아니며, 글자 수 제한이나 t.co 링크 같은 제약까지 물려받음
• Backfeed는 외부 복사본에 달린 좋아요·답글·재게시를 Webmention으로 원본에 돌려보냄
  • Bridgy는 Mastodon, GitHub, Flickr, Reddit, Bluesky의 복사본을 관찰하고 상호작용마다 Webmention을 전송함
  • 결과적으로 외부 플랫폼에서 발생한 전체 대화를 개인 도메인에 보관할 수 있음

Fediverse 및 RSS와의 관계

• Webmention, Micropub, WebSub와 ActivityPub은 모두 W3C Social Web Working Group에서 나왔지만 서로 다른 철학을 따름
• Fediverse는 서버를 연합하고 정체성을 @user@instance로 나타내므로, 자체 인스턴스를 운영하지 않으면 다른 운영자에게 의존함
  • 인스턴스 운영에는 중재와 유지보수의 높은 비용인 admintax가 따름
• IndieWeb는 웹사이트를 연합하고 개인 도메인을 정체성으로 사용하며, 연합은 여러 배포 채널 중 하나로 취급함
• Bridgy Fed는 h-card, h-entry, Webmention을 ActivityPub 및 Bluesky의 AT Protocol과 상호 변환함
  • 개인 도메인이 @example.com@example.com 형태의 Fediverse 계정이 됨
  • Mastodon에서 해당 계정을 검색·팔로우할 수 있고, 답글은 Backfeed로 원 게시물에 돌아옴
• IndieWeb는 RSS·Atom이 HTML과 별도 XML 복사본을 유지해야 해 유지보수 비용과 불일치 가능성을 만든다고 봄
  • 일부 Atom 파일은 같은 내용의 HTML보다 최대 4.5배 큼
  • 사람이 피드 링크를 직접 열었을 때의 경험도 좋지 않음
• 대안인 h-feed는 HTML 자체를 피드로 사용하지만 지원하는 리더가 매우 적음
  • 따라서 IndieWeb 환경에는 h-feed를, 일반 독자에게는 RSS·Atom을 함께 제공하도록 권장함

시작 순서

• Getting Started는 다음 순서를 권장함
  1. 도메인 확보: 온라인의 주 정체성으로 사용하고, WHOIS 개인정보 보호는 제공자를 완전히 신뢰할 때만 선택함
  2. 호스팅 구성: 초보자는 GitHub Pages, Netlify, Neocities 같은 관리형 서비스를 사용하고 경험이 있다면 직접 호스팅함
  3. 페이지 생성: 정적 사이트 생성기, 직접 작성한 HTML, CMS 중 무엇을 써도 되며 공식 기술은 없음
  4. POSSE 적용: 원본 링크와 함께 다른 플랫폼에 배포함
  5. microformats 추가: 홈페이지에 rel="me", 게시물에 h-entry를 넣음
  6. 검증: IndieWebify.me로 rel-me, h-card, h-entry를 단계별로 확인함
  7. 커뮤니티 참여: 한 페이지뿐이어도 만든 것을 공유하고 다음 사용자를 위해 위키에 문서화함
• IndieMark는 점진적으로 적용하려는 개발자를 위한 단계별 안내 척도임

실제 적용과 제외한 기능

• 실제 사이트에는 다음 요소를 적용함
  • Webmention 송수신: 새 글의 외부 링크에 알리는 일일 작업을 자동화하되, 오타를 수정할 수 있도록 24시간의 여유를 둠
  • 수신한 Webmention은 각 글 끝의 참고 목록에 사용하며, 이메일로 관리하는 댓글과 분리함
  • 모든 글에 h-entry, 홈페이지에 h-card를 적용하고 mf2py로 검증함
  • 바닥글에서 Mastodon, GitHub, Org Social을 rel="me"로 연결해 인증 표시를 받음
• 필요와 기존 작업 방식이 맞지 않는 요소는 제외함
  • Micropub·IndieAuth: 편집기와 Git이 발행 인터페이스이고 글을 버전 관리되는 Markdown으로 작성하므로 별도 발행 엔드포인트가 필요하지 않음
  • WebSub: 의도적으로 발행을 24시간 늦추기 때문에 실시간 전달이 복잡성을 정당화하지 못함
  • h-feed: 글 카드 템플릿이 본문 안의 추천 영역 등에도 재사용돼 파서가 모호한 h-entry로 인식할 수 있으며, RSS가 해당 역할을 충분히 수행함

기술보다 오래 남는 실천 원칙

• 일반 HTML은 JavaScript 없이도 전체 콘텐츠를 읽을 수 있는 가장 오래가는 형식임
• “Cool URIs don't change” 원칙에 따라 영구히 유지할 수 있는 URL을 설계해야 함
  • 실제 사이트에서는 글의 슬러그를 바꿔도 기존 URL이 계속 작동함
• 사일로를 한 번에 떠날 필요 없이 콘텐츠 종류별로 자신의 사이트에 먼저 발행하는 점진적 전환이 가능함
• 극단적인 장기 존속성까지 고려해야 함
  • 사망 후 신뢰하는 사람에게 사이트 열쇠를 넘기는 “dead man's switch”를 검토할 수 있음
  • 운영자가 사라진 뒤 누가 도메인 비용을 낼지도 해결해야 함
• 완벽하지만 유지하기 지루한 템플릿보다 불완전하고 독특한 개인 웹사이트를 즐겁게 운영하는 편이 IndieWeb의 원칙에 부합함