# IndieWeb에 참여해 배운 것 > Clean Markdown view of GeekNews topic #31629. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31629](https://news.hada.io/topic?id=31629) - GeekNews Markdown: [https://news.hada.io/topic/31629.md](https://news.hada.io/topic/31629.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-21T08:37:26+09:00 - Updated: 2026-07-21T08:37:26+09:00 - Original source: [en.andros.dev](https://en.andros.dev/blog/0b8e451e/i-joined-the-indieweb-heres-what-i-learned/) - Points: 2 - Comments: 1 ## Topic Body - **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](https://indieweb.org/)는 자신을 “**기업 웹에 대한 사람 중심의 대안**”으로 정의하며, 특정 소프트웨어나 프레임워크보다 여러 접근법과 프로젝트를 수용하는 이념적 기반에 가까움 - 2010년 Aaron Parecki와 Tantek Çelik은 Portland의 Federated Social Web Summit에 참석한 뒤 프로토콜보다 **창작자 중심의 접근**이 필요하다고 판단함 - 2011년 Portland에서 첫 IndieWebCamp가 열렸고, 이후 세계 각지에서 매년 개최됨 - Homebrew Website Club에서는 참가자들이 모여 자신의 개인 웹사이트를 개선함 - IndieWeb를 이루는 세 기둥은 다음과 같음 - **콘텐츠 소유권**: 웹에 올린 콘텐츠는 기업이 아니라 게시자에게 속해야 함 - **더 나은 연결성**: 글을 여러 플랫폼에 배포하고 외부의 답글과 좋아요를 자신의 사이트로 다시 가져올 수 있어야 함 - **통제권**: 원하는 형식으로 게시하고 읽을 수 있으며, 영속적인 URL을 유지해야 함 - 소셜 네트워크 사용 자체를 금지하지 않지만, 콘텐츠와 상호작용을 가두는 **폐쇄형 생태계**에는 반대함 ### 사일로와 웹 콘텐츠 소멸 - [사일로(silo)](https://indieweb.org/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 조사](https://www.pewresearch.org/data-labs/2024/05/17/when-online-content-disappears/)에 따르면 2013년에 존재한 웹페이지 중 **38%가 10년 뒤 접근 불가** 상태였음 - 대응 원칙은 소셜 네트워크를 쓰지 않는 것이 아니라 콘텐츠의 **정본(canonical copy)** 을 자신이 통제하는 도메인에 두는 것임 ### 커뮤니티의 11가지 원칙 - [11가지 원칙](https://indieweb.org/principles)은 우선순위가 아니며, 모두 충족해야 하는 의무도 아님 1. **데이터 소유**: 콘텐츠·메타데이터·정체성을 자신의 도메인에 두고 장기적으로 접근권을 유지함 2. **보이는 데이터 사용과 발행**: 사람을 우선하고 기계를 그다음에 고려하며, HTML에 데이터를 담을 수 있다면 별도 API를 만들지 않음 3. **자신에게 필요한 것 제작**: 존재 여부가 불분명한 가상 사용자가 아니라 실제 자신을 위한 도구를 만듦 4. **직접 사용**: 만든 것을 매일 사용하며 의존할 가치가 있는지 검증함 5. **문서화**: 과정·아이디어·코드를 자신의 사이트에 기록해 다른 사람과 미래의 자신을 도움 6. **오픈소스화**: 의무는 아니지만 다른 사람이 독립 웹에 더 빨리 참여하도록 도움 7. **프로토콜보다 UX**: 사용자 경험을 먼저 정하고 이를 지원하는 가장 단순하고 작은 프로토콜만 사용함 8. **모듈성**: 특정 기기·언어·플랫폼에 종속되지 않도록 작고 느슨하게 결합된 구성요소를 만듦 9. **장기 존속성**: 발전을 이유로 몇 년마다 기존 작업을 폐기하지 않아도 되는 웹 기술을 구축함 10. **다원성**: 여러 접근법을 의도적으로 장려해 단일한 기술 문화보다 회복력 있는 커뮤니티를 만듦 11. **즐거움**: 1990년대 웹처럼 이상하고 흥미로운 개인적 표현을 유지함 ### 개인 도메인에서 시작하는 기술 구조 - **자체 도메인**을 온라인의 주 정체성으로 사용하는 것이 모든 구성의 전제임 - 호스팅이나 CMS를 바꾸더라도 도메인을 유지하면 링크·독자·검색 순위를 이어갈 수 있음 - 커뮤니티가 IndieWeb 참여로 인정하는 최소 조건이기도 함 - IndieWeb는 단일 플랫폼 대신 서로 조합할 수 있는 작은 규격들을 사용하며, [공식 규격 색인](https://spec.indieweb.org/)은 구현 연혁과 보급 범위에 따라 정리되어 있음 ### microformats2: HTML을 API로 사용하기 - [microformats2](https://microformats.org/wiki/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"`](https://indieweb.org/rel-me)는 링크 대상이 현재 페이지와 같은 사람을 나타낸다는 사실을 선언함 - 웹사이트와 외부 프로필이 서로를 `rel="me"`로 연결하면 중앙 기관 없이 **상호 신원 확인**이 가능함 - Mastodon은 이 구조로 도메인에 녹색 인증 표시를 제공함 - Threads, PixelFed, GitHub, Keybase, Wikipedia도 지원함 - **RelMeAuth**는 홈페이지에서 연결한 GitHub 같은 OAuth 제공자에게 신원 증명을 위임해 개인 URL로 서비스에 인증함 - [IndieLogin](https://indielogin.com/) 같은 서비스의 기반임 ### Webmention: 웹사이트 사이의 대화 - [Webmention](https://indieweb.org/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](https://indieweb.org/Vouch)는 수신자가 이미 알고 있으며 발신 도메인에 링크한 보증 사이트를 세 번째 매개변수로 전달해 필터링 비용을 발신자에게 옮김 - [Salmention](https://indieweb.org/Salmention)은 댓글에 답글이 달렸을 때 원 게시물이 참여자들에게 갱신 Webmention을 다시 보내 대화 스레드를 전파함 - 백엔드가 없는 정적 사이트는 [webmention.io](https://webmention.io/)가 Webmention을 대신 수신하고 조회 API를 제공함 - Hugo, Jekyll, Eleventy 같은 정적 사이트 생성기에 사용할 수 있음 ### 도메인 기반 로그인과 발행 - [IndieAuth](https://indieauth.spec.indieweb.org/)는 Google이나 Facebook 계정 대신 **개인 URL을 로그인 정체성**으로 사용함 - OAuth 2.0을 기반으로 사용자와 애플리케이션을 URL로 식별함 - DNS가 사전 클라이언트 등록을 대신하며, 액세스 토큰 탈취를 방지하는 PKCE가 필수임 - 서비스는 사용자 페이지의 `rel="indieauth-metadata"`에서 인증 서버를 찾고, 인증 완료 후 해당 URL에 대한 통제권을 확인함 - 인증 방식으로 비밀번호, 이메일, RelMeAuth 등을 사용할 수 있음 - [Micropub](https://indieweb.org/Micropub)은 2017년 5월부터 **W3C Recommendation**이며, 사이트 소프트웨어와 발행 인터페이스를 분리함 - 웹·iOS·Android 클라이언트가 개인 도메인의 게시물을 생성·수정·삭제할 수 있음 - 비밀번호를 공유하던 MetaWeblog와 AtomPub 대신 IndieAuth로 받은 OAuth 토큰을 사용함 - 별도 어휘를 만들지 않고 `h=entry`, `content` 등 h-entry 속성을 직렬화해 전송함 ### 실시간 피드와 분리된 리더 - [WebSub](https://indieweb.org/WebSub)은 이전에 PubSubHubbub로 불렸으며, 2018년 1월부터 **W3C Recommendation**임 - 구독자가 서버를 주기적으로 조회하는 대신 게시자가 허브에 새 글을 알리고, 허브가 웹훅으로 구독자에게 즉시 전달함 - 서버 부하를 줄이고 갱신 지연을 없애며 Feedly와 NewsBlur 등이 지원함 - [Microsub](https://indieweb.org/Microsub)은 가장 새로운 규격으로 아직 초안 상태이며, 소셜 읽기 애플리케이션을 두 계층으로 분리함 - 서버는 구독 관리, 피드 수집·분석, 데이터 정규화를 담당함 - 클라이언트는 읽기 인터페이스만 표시해 UX로 경쟁할 수 있고, 구독 정보는 클라이언트 사이에서 이동 가능함 - Micropub의 답글 발행과 Webmention의 알림을 결합하면 IndieWeb **소셜 리더** 구조가 완성됨 ### POSSE, PESOS와 Backfeed - [POSSE](https://indieweb.org/POSSE)는 **자신의 사이트에 먼저 발행하고 외부에 배포**하는 권장 전략임 - 외부 복사본은 원본 링크를 포함하므로 독자는 기존 플랫폼에서 계속 읽고, 게시자는 정본을 유지함 - 플랫폼이 종료되거나 계정을 차단해도 원본은 남음 - Tantek Çelik이 2012년 용어를 만들었고 Cory Doctorow와 Molly White 등이 사용함 - 스팸 사이트가 글을 복사해도 원본 링크까지 함께 복사하게 되는 효과를 “인터넷 합기도”라고 부름 - [PESOS](https://indieweb.org/PESOS)는 사일로에 먼저 게시한 뒤 자신의 사이트에 복사해 보관하는 반대 방식임 - 완성도 높은 사일로 앱을 쓸 수 있고 개인 사이트가 중단돼도 게시할 수 있음 - 처음부터 사일로 약관의 적용을 받고, 개인 사이트의 복사본이 정본이 아니며, 글자 수 제한이나 `t.co` 링크 같은 제약까지 물려받음 - [Backfeed](https://indieweb.org/backfeed)는 외부 복사본에 달린 좋아요·답글·재게시를 Webmention으로 원본에 돌려보냄 - [Bridgy](https://brid.gy/)는 Mastodon, GitHub, Flickr, Reddit, Bluesky의 복사본을 관찰하고 상호작용마다 Webmention을 전송함 - 결과적으로 외부 플랫폼에서 발생한 전체 대화를 개인 도메인에 보관할 수 있음 ### Fediverse 및 RSS와의 관계 - Webmention, Micropub, WebSub와 ActivityPub은 모두 **W3C Social Web Working Group**에서 나왔지만 서로 다른 철학을 따름 - Fediverse는 서버를 연합하고 정체성을 `@user@instance`로 나타내므로, 자체 인스턴스를 운영하지 않으면 다른 운영자에게 의존함 - 인스턴스 운영에는 중재와 유지보수의 높은 비용인 **admintax**가 따름 - IndieWeb는 웹사이트를 연합하고 개인 도메인을 정체성으로 사용하며, 연합은 여러 배포 채널 중 하나로 취급함 - [Bridgy Fed](https://fed.brid.gy/)는 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](https://indieweb.org/Getting_Started)는 다음 순서를 권장함 1. **도메인 확보**: 온라인의 주 정체성으로 사용하고, WHOIS 개인정보 보호는 제공자를 완전히 신뢰할 때만 선택함 2. **호스팅 구성**: 초보자는 GitHub Pages, Netlify, Neocities 같은 관리형 서비스를 사용하고 경험이 있다면 직접 호스팅함 3. **페이지 생성**: 정적 사이트 생성기, 직접 작성한 HTML, CMS 중 무엇을 써도 되며 공식 기술은 없음 4. **POSSE 적용**: 원본 링크와 함께 다른 플랫폼에 배포함 5. **microformats 추가**: 홈페이지에 `rel="me"`, 게시물에 h-entry를 넣음 6. **검증**: [IndieWebify.me](https://indiewebify.me/)로 rel-me, h-card, h-entry를 단계별로 확인함 7. **커뮤니티 참여**: 한 페이지뿐이어도 만든 것을 공유하고 다음 사용자를 위해 위키에 문서화함 - [IndieMark](https://indieweb.org/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의 원칙에 부합함 ## Comments ### Comment 62113 - Author: neo - Created: 2026-07-21T08:37:28+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48966984) - IndieWeb가 콘텐츠를 원한다면 **복잡한 기술 더미** 아래에 묻어버리는 방식은 정반대임 이 프로토콜 묶음은 사용자 90%에게 사실상 쓸 수 없으며, 콘텐츠 사용자 경험을 우선하려면 즉시 시작할 수 있는 원클릭 해법이 필요함 명령줄·Docker·HTML/CSS 직접 편집을 요구하는 순간 대부분이 넘지 못할 장벽을 만드는 것이며, 지금 모습은 IndieWeb보다 NerdNet에 가까워 보임 - IndieWeb 커뮤니티와 위키를 살펴보면 **사용자 경험 우선**에 공감하는 이들이 많음 대표적인 원클릭 진입점인 micro.blog는 최신 IndieWeb 기능이 포함된 개인 사이트를 월 5달러에 제공함 현재 관심층 대부분이 직접 구축하려는 개발자라 관련 글이 기술투성이처럼 보이지만, 비개발자의 유입도 커뮤니티가 바라는 변화임. David Shanske는 지난 10년간 IndieWeb 도구를 기본 제공하는 WordPress 플러그인을 만들어 왔음: [https://profiles.wordpress.org/dshanske/#content-plugins]() 모든 기술을 써야 IndieWeb인 것도 아님. **자체 도메인**에서 시작해 HTML·Markdown·Django 등으로 페이지를 만들고, 마이크로포맷과 Webmention을 차례로 추가하면 되며 어느 단계에서든 IndieWeb 사이트로 볼 수 있음 - 오히려 모두에게 개방하면 좋은 것이 망가짐. 끝없는 9월처럼 저급 매체와 클릭 미끼가 넘쳐나므로 **진입 장벽과 참여 제한**은 유익함 인터넷은 세계적인 Walmart가 되기 전, 흥미로운 사람들이 스스로 모이던 공간이었을 때 더 나았음 - 이제 막 접한 입장이지만 IndieWeb를 탓하긴 어려움. 소셜 플랫폼의 폐쇄적 울타리에서 벗어나려는 이들은 주로 엔지니어나 웹에 익숙한 사람들이고, 자신이 아는 도구로 문제를 푸는 건 자연스러움 인터넷도 늘 **괴짜들이 만든 어렵지만 재미있는 것**에서 출발해 점차 일반인이 쓰기 쉬워지는 방식으로 발전했음. IndieWeb도 초기 단계이며 살아남는다면 대중화는 자연스럽게 따라올 테니 지금은 더 만들어 보게 두면 됨 - 2014년에 IndieWeb 운동의 일부로 이 목표를 구현한 스타트업 **Known**을 시작했고, 오픈 소스 코드도 아직 남아 있음 문제는 경제성임. 원클릭 해법은 좋지만 IndieWeb는 이념적 문제를 해결할 뿐 사용자의 절박한 문제를 해결하지 못해, 투자나 서비스 운영비를 감당할 고객을 확보하기 어려움 micro.blog가 가장 가까우나 자체 인프라에서 운영할 수 없는 중앙화 서비스라 프로토콜 호환성은 있어도 완전한 IndieWeb 도구는 아님 에이전트 활동 기록이나 센서·서버의 게시 도구 같은 가능성은 있지만, **실질적인 사용자 수요**가 없다면 완제품 서비스로 성립하기 어려워 보임 - 사용자 90%에게 어렵다는 사실을 알지만 신경 쓰지 않는 것임. 자유 소프트웨어처럼 IndieWeb도 보수 없이 **자신의 필요를 직접 해결하는 철학**이며, 시장 장악이 목적이 아님 인기 있는 것에 굴복하기보다 원하는 것을 만들도록 장려해야 함. 실질적인 가치를 만들기보다 지대 추구 전략과 로비에 몰두하는 마케팅 직군은 사회를 더 나쁘게 만들므로 줄어들 필요가 있음 - **Nostr의 사고방식**은 Mastodon이나 AT Protocol보다 POSSE에 더 가까워 보여 선호함 - Nostr보다 Org Social을 훨씬 선호함: [https://en.andros.dev/blog/8c640241/why-org-social-when-you-...]() - Nostr가 이제는 **브로코인 중심 문화**를 벗어났는지 궁금함 - 정기적으로 블로그를 운영하고 도메인과 게시물도 소유하지만 WordPress를 사용했다는 이유로 IndieWeb가 아니라면 결국 기업에 의존하는 셈임. 예전에 Blogger로 만든 블로그들도 거의 10년째 그대로 남아 있음 **서버를 직접 소유하는 것**은 현실적이지 않음. 가상 서버라면 Amazon이나 Microsoft 클라우드에 있고, 물리 서버라도 기업의 데이터센터에 두어야 하며 UPS와 상시 인터넷 연결까지 직접 관리하기는 어려움 - 기존 대안들은 대개 1990년대 향수를 좇는 데 그쳐 잠깐의 향수 외에는 쓸모를 찾기 어려웠지만, 이 방식은 달라 보임 **현대 웹을 수용**하면서도 창작자가 자신의 공간을 완전히 통제하도록 해줌. 시간이 생기면 myzopotamia.dev 블로그를 IndieWeb에 참여시키고 싶음 - indiekit은 사실상 **IndieWeb 기능 일체**를 기본 제공함. [https://rmendes.net]()에서 사용 중이며 [https://textcaster.app]()에도 구현하려고 작업 중임 - RSS 피드의 **중복 배제 원칙(DRY)** 문제가 과장된 듯함. 어떤 오픈 소스 프레임워크로 작성하든 RSS 피드를 자동 생성하는 데 문제가 생긴 때가 기억나지 않음 - 그래도 RSS의 중복은 명백함. 웹사이트 목록 페이지를 그대로 복제하며, `h-entry`가 있는데 같은 콘텐츠의 두 버전과 XML을 관리해야 해서 자주 답답했음 RSS는 표 기반 레이아웃이 끝나던 **시맨틱 마크업 혁명 직전**에 발명되어 시기가 좋지 않았음 - RSS 피드를 만들거나 읽는 일을 좋아하는 사람은 드물어 보임. 대안은 많지만 **RSS의 대중성**을 넘어선 것은 없음 - IndieWeb를 내세운 사이트에서 저자의 이력서, 전문 촬영한 얼굴 사진, 명문 기관 경력을 강조한 소개와 세련된 블로그를 보면 불편함 고급 쇼핑몰의 환한 옷가게에서 모든 상품에 무정부주의 상징을 붙여놓고, 가까이 보니 가격표가 거의 네 자리인 모습과 비슷함 - 블로그 운영의 즐거움을 다루는 소박한 블로그를 더 자주 보며, Substack 성장을 공략하는 주변 산업보다는 훨씬 나음 개인 사이트는 원하는 무엇이든 될 수 있음. 내 사이트도 구직할 필요가 없어지면서 해마다 더 개인적이고 취미 중심으로 변하고 있지만, 사이트는 결국 그 사람이 사는 사회의 산물이며 **생계도 유지해야 함** - 내 사이트도 IndieWeb라고 내세우지는 않지만 컨설팅 사이트 링크와 얼굴 사진이 있음 직업 생활 역시 나를 구성하는 일부이며, 자영업자라는 의미에서 **독립 노동자**라고 부를 수도 있는데 이것이 왜 나쁜지 모르겠음 - 개인 도메인에 이력서를 두는 것은 가장 IndieWeb다운 행동임. 전문적 정체성을 LinkedIn이 아니라 **자신의 통제 아래** 두기 때문임 IndieWeb는 전문성을 거부하지 않고 콘텐츠가 자신에게 속하며 플랫폼보다 오래 살아남아야 한다고 봄. 얼굴 사진·이력서·세련된 블로그는 괜찮으며, 폐쇄되거나 데이터를 팔거나 사라질 수 있는 플랫폼 안에 가두는 것이 비판 대상임 - 콘텐츠를 병렬 파일이나 API 없이 기계가 읽게 만드는 일은 애초에 해결할 필요가 거의 없던 문제임 이전의 온톨로지들과 마찬가지로 **인간 방문자에게는 쓸모없고 적대적인 주체**에게 데이터만 먹여주는 셈임 - 좋아하는 다른 블로그를 꾸준히 공유하면 좋음. IndieWeb는 **입소문과 사람의 큐레이션**에 의존하므로 ‘이번 달에 즐긴 것’ 같은 글이 유용함 아낌없이 칭찬하고 이메일로 감사를 전하며 대화를 시작할 필요도 있음. 사용자 추적이 없는 정적 사이트는 혼잣말처럼 느껴질 수 있어 독자 메일이 큰 힘이 됨 개인 사이트답게 불완전하고 엉뚱해도 괜찮으며, 모든 콘텐츠가 시간순 피드일 필요는 없음. **디지털 정원**처럼 원하는 방식으로 공간을 구성하면 됨 - `.dev` 도메인이 **Google 소유**라는 사실을 알고 있었는지 궁금함 - 알고 있었으며 개인 최상위 도메인을 얻고 싶었지만 절차가 복잡해 보였음