3P by GN⁺ | ★ favorite | 댓글 1개
  • Hardcore IndieWeb는 콘텐츠 원본과 게시 가능한 HTML·웹 자산을 자신의 장치에 보관해, 서비스 사업자에게 정체성과 콘텐츠 통제권을 맡기지 않는 방식임
  • HTML을 브라우저에서 미리 본 뒤 호스트에 올리는 1990년대식 출판 과정을 따르면 CMS·SSG·프레임워크·CLI·월 구독 없이 사이트를 운영할 수 있음
  • 텍스트 편집기와 SFTP 도구, 웹 호스트만 있으면 되며, NearlyFreeSpeech.net에서는 정적 사이트를 하루 $0.01에 운영하고 $0.25부터 충전할 수 있음
  • 랜딩 페이지와 개별 게시물, 아카이브, Atom 피드를 파일로 직접 관리해 페이지마다 구조와 디자인을 바꾸고 변경된 파일만 전송할 수 있음
  • 호스트가 사라져도 완성된 사이트를 다른 곳에 그대로 올릴 수 있지만, 도구를 추가할수록 의존성도 늘어나므로 로컬 원본과 게시본 보유가 독립성을 유지하는 조건임

Hardcore IndieWeb가 요구하는 독립성

  • IndieWeb는 웹상의 정체성과 콘텐츠를 직접 소유하고 기업의 외부 통제에서 벗어나려는 실용적 접근 방식임
  • 구독형 블로그 서비스도 IndieWeb 참여를 도울 수 있지만, 콘텐츠가 타인의 데이터베이스와 서버에 주로 존재한다면 완전히 독립적이지 않음
    • 공개 형식으로 내보낼 수 있더라도 서비스를 이용하는 동안에는 콘텐츠를 완전히 통제하지 못함
    • 기존 서비스에 만족하는 사람보다 콘텐츠에 대한 완전한 독립과 통제를 원하는 사람에게 맞는 방식임
  • Hardcore IndieWeb는 기존 IndieWeb 원칙에 통제권과 이식성이라는 구체적인 기준을 적용함
    • 콘텐츠가 주로 자신의 하드 드라이브에 없다면 완전히 통제한다고 보기 어려움
    • 게시된 HTML과 웹 자산의 사본이 하드 드라이브에 없다면 사이트가 완전히 이식 가능한 상태가 아님
  • 서비스가 폐업해 데이터를 내보낼 수 없게 되면 명목상 콘텐츠 소유권이 있어도 접근하거나 이전할 수 없음
  • 운영자의 행동 때문에 서비스를 떠나려 해도 내보낸 형식을 지원하는 다른 서비스를 찾거나, 콘텐츠를 변환하고 도구와 절차를 바꿔야 할 수 있음
  • 로컬에 콘텐츠 원본과 완성된 게시본이 있으면 이런 상황에서도 통제권과 이식성을 유지할 수 있음

1990년대식 웹 출판 절차

  • Hardcore IndieWeb는 웹 초창기의 단순한 출판 방식을 따름
    1. 하드 드라이브에서 콘텐츠 작성
    2. 웹 브라우저에서 미리 보기
    3. 만족하면 웹 호스트에 업로드하고 필요할 때마다 반복
  • 도메인 외에 필요한 것은 텍스트 편집기, 파일 전송 도구, 웹 호스트뿐임
  • 프로그래밍 환경이나 IDE, 프레임워크, 셸, CLI 도구, 월 구독은 필요하지 않음
  • HTML 지식은 필요하지만 HTML for People 같은 자료로 배울 수 있으며, 소수의 태그와 복사·붙여넣기만으로도 시작 가능함
  • 복잡한 SaaS·CMS·SSG·마크업 언어·템플릿 시스템은 선택 사항이며, 파일을 직접 게시하는 단순한 방식도 여전히 작동함

필요한 도구와 호스팅

  • 텍스트 편집기는 디스크에 파일을 저장할 수 있다면 무엇이든 사용할 수 있음
  • 파일 전송에는 SSH 또는 SFTP를 지원하는 도구가 필요함
    • FileZilla는 여러 운영체제를 지원하는 선택지임
  • 정적 사이트 호스트로 NearlyFreeSpeech.net을 추천하며, 하루 $0.01에 운영할 수 있음
    • Adam Newbold는 2008년부터 이 서비스를 사용해 왔음
    • $0.25부터 계정에 충전하고 static, non-production 사이트를 추가할 수 있음
    • Sites 탭에서 사이트 이름을 선택하면 파일 전송용 로그인 정보를 확인할 수 있음
    • 무료 서브도메인이 제공되며 Domains 탭에서 개인 도메인을 추가할 수 있음
  • NearlyFreeSpeech는 필수가 아니며, 기본적인 정적 파일 호스팅을 제공하는 다른 웹 호스트도 선택 가능함

기존 사이트와 HTML 준비

  • 기존 사이트나 블로그가 HTML 형식이라면 바로 시작하기 쉬움
  • 다른 형식으로 운영 중이라면 서비스에 따라 HTML로 내보내거나 변환할 수 있음
    • 규모가 큰 블로그에는 변환 도구를 사용하는 편이 적합함
    • 규모가 작다면 게시물을 다시 살펴보면서 HTML 파일을 직접 만들 수 있음
  • Markdown을 선호할 수 있지만 HTML은 웹의 언어이며, Markdown 파서와 씨름하는 것보다 순수 HTML로 처리하는 편이 간단한 경우도 있음
  • 처음부터 디자인하기 어렵다면 HTML5 UP 같은 무료 디자인과 템플릿을 내려받아 편집할 수 있음

블로그를 구성하는 파일

  • 일반적인 블로그는 랜딩 페이지, 게시물, 아카이브 페이지, 피드로 구성되며 전용 블로그 서비스 없이 직접 관리할 수 있음
  • 랜딩 페이지

    • 최신 게시물 전체나 일부, 여러 게시물 또는 게시물이 아닌 콘텐츠를 자유롭게 배치할 수 있음
    • 최신 게시물을 표시하려면 내용을 복사하고 독립 페이지로 연결되는 링크를 추가함
    • 최근 게시물 5개를 유지하려면 새 글을 위에 붙이고 가장 오래된 글을 아래에서 삭제함
    • CMS·SSG·템플릿 엔진의 제약이 없어 페이지마다 구조와 표현을 변경할 수 있음
    • 랜딩 페이지 파일명은 index.html이어야 하며 웹 루트에 둠
    • NearlyFreeSpeech의 웹 루트는 /home/public
  • 블로그 게시물

    • 게시물 하나를 웹페이지 하나로 만들며, 이전 게시물 파일을 복사하고 고유한 파일명과 새 내용을 넣는 방식으로 작성할 수 있음
    • 디스크의 파일 구조가 URL에 반영되므로 원하는 주소 체계에 맞춰 폴더를 구성함
    • /blog/ 경로를 사용하려면 웹 루트에 blog 폴더를 만듦
    • the-best-lunch-i-ever-had.html처럼 슬러그 기반 파일명을 사용할 수 있음
    • 게시물별 폴더 안에 index.html을 두면 URL에서 .html 확장자를 숨길 수 있음
    • 게시물을 Markdown이나 데이터베이스 항목이 아닌 독립 HTML 파일로 관리하면 글마다 서로 다른 스타일과 외형, 레이아웃, 개성을 부여할 수 있음
    • 모든 게시물이 같은 모양이어야 한다는 관습은 현대적인 출판 도구에서 비롯됐으며, 직접 만든 HTML에서는 따를 필요가 없음
  • 아카이브 페이지

    • archive 같은 이름의 폴더를 만들고 그 안에 index.html을 둔 뒤 게시물 목록을 작성함
    • 정렬 방식과 구성은 자유로우며, 좋아하는 게시물을 페이지 상단에 따로 강조할 수도 있음

Atom 피드 직접 관리하기

  • RSS 피드는 특별한 시스템이 아니라 디스크에 저장하는 파일이므로 텍스트 편집기로 직접 수정할 수 있음
  • Wikipedia의 Atom 페이지)에 있는 예제 피드를 복사해 feed.xml 파일로 시작할 수 있음
    • Atom은 RSS와 호환되며 보편적으로 지원됨
    • example.com, <title>, <subtitle> 등의 값을 자신의 도메인과 정보로 변경함
    • 피드에 넣을 게시물마다 <entry>를 만들고 날짜·시간·제목·요약 등을 입력함
    • <id>에는 UUID Generator에서 새 UUID를 받아 사용함
  • 완성한 피드는 W3C Feed Validation Service에 붙여 넣어 파싱 가능 여부를 검사할 수 있음
    • 오류가 발견되면 검증 서비스에서 수정할 항목을 확인할 수 있음

게시와 업데이트

  • 최초 게시 때는 파일 전송 프로그램으로 서버에 접속해 사이트 전체를 웹 호스트로 복사함
  • 이후에는 새로 생기거나 변경된 파일만 전송하면 됨
    • 일반적인 업데이트 대상은 랜딩 페이지, 새 게시물, 피드, 아카이브 페이지임
  • 게시 과정은 로컬 파일을 원격 서버로 끌어다 놓는 수준으로 처리 가능함

이식성과 추가 도구의 경계

  • 완성된 사이트가 자신의 컴퓨터에 있으므로 기존 호스트가 사라져도 다른 호스트에 그대로 업로드할 수 있음
  • 블로그 소프트웨어의 중대한 보안 취약점이나 SSG 의존성을 관리할 필요가 없고, 콘텐츠의 모든 측면을 직접 통제할 수 있음
  • 이 절차를 그대로 유지하는 것만으로 완전히 독립적인 웹사이트를 계속 운영할 수 있음
  • 작업 흐름을 돕는 도구와 절차를 추가할 수 있지만, 도구 하나를 더할 때마다 새로운 의존성도 생김
  • 콘텐츠 원본이 자신의 장치에 있고 게시 가능한 사이트 전체의 사본을 보유한다면 Hardcore IndieWeb의 조건을 충족함

직접 HTML을 다루는 자율성

  • 핵심 절차는 HTML을 직접 작성해 웹 서버에 업로드하는 것
  • 지난 30년 동안 추가된 기술 계층과 절차, 기대 수준은 웹 작업을 복잡하게 만들고 통제권과 독립성을 다른 사람에게 넘기게 했음
  • IndieWeb 서비스를 사용하더라도 웹 존재 전체의 유일한 사본을 서비스 운영자에게 맡긴다면 완전히 독립적이지 않음
  • Hardcore IndieWeb는 모든 사람을 위한 방식은 아니지만, 자신의 글을 누가 보유하고 어디에 어떤 형태로 게시할지를 중시하는 사람에게 적합함
  • HTML을 직접 다루고 자신의 웹 호스트 공간으로 파일을 복사하는 과정은 초기 웹의 즐거움과 다시 연결되는 직접적이고 자율적인 경험을 제공함

댓글과 토론

Hacker News 의견들
  • 정적 사이트를 GitHub Pages와 Cloudflare Pages에 무료로 호스팅해 왔고 매우 만족함. NearlyFreeSpeech에 비용을 내더라도 결국 제3자 호스팅에 의존한다는 점은 같아서, 직접 호스팅은 기술적 만족감 외에 큰 가치가 없어 보임
    중요한 것은 HTML과 이미지 같은 자산을 디스크의 단순한 파일로 직접 관리한다는 점임. Git 연동 덕분에 외부 백업도 생기고, VS Code에서 master로 푸시하면 30초 안에 게시되어 예전 FTP/SFTP보다 훨씬 편리함

    • GitHub Pages와 Cloudflare Pages는 사이트가 운영자보다 오래 살아남을 가능성이 크다는 장점이 있음. 직접 호스팅하면 승계 계획이 없는 한 도메인 만료나 카드 해지로 언젠가 반드시 중단되지만, 무료 서비스는 사라질 수도 있다는 가능성에 그침
    • 비용을 내면 상품이 아니라 고객이 된다는 차이는 상당히 큼
    • 내 블로그도 같은 방식으로 운영함: https://gigatexal.blog
  • NearlyFreeSpeech도 좋은 서비스지만 완전히 독립적이지는 않음. 자체 인터넷 인프라 없이 독립성에 가장 가까워지려면 집에서 포트 포워딩하거나 Tor 숨김 서비스로 사이트를 운영할 수 있음
    torrc에서 포트를 설정하면 어렵지 않지만 방문자도 Tor Browser가 필요하고, 사이트가 ‘다크 웹’에 있다고 설명하기 까다로움. 소유한 하드웨어로 집에서 운영하고 서버 IP도 숨길 수 있는데 독립 웹 진영에서 더 널리 쓰이지 않는 점이 의외임. 일반 도메인을 .onion 주소로 리디렉션할 수도 있음
    브라우저에서 직접 사이트를 만들고 호스팅하던 Beaker Browser는 종료됐지만, Tor용 사이트 제작 플러그인 같은 도구가 나오면 보급에 도움이 될 듯함

    • .onion 서비스는 간단히 띄울 수 있고 일반 웹보다 안전하며, 휴대전화에서도 실행 가능함
      Nanogram: https://gitlab.com/here_forawhile/nanogram
      Spreadsheet Server: https://gitlab.com/here_forawhile/spreadsheet
      Library Server: https://gitlab.com/here_forawhile/libraryserver
      Torum: https://gitlab.com/here_forawhile/torum
    • Tor Browser는 일반 인터넷에서 .onion 주소를 발견하도록 Onion-LocationAlt-Svc를 지원함. Onion-Location은 일반 HTTPS 사이트가 Onion 서비스를 알리며, Alt-Svc는 별도 사용자 조작 없이 자동으로 발견하고 전환함
      향후 DNS나 DNSSEC 기반 Onion 연결도 가능성이 있음: https://onionservices.torproject.org/research/proposals/usab...
    • 완벽은 최선의 적임. 통신사와 장비 제조사에도 의존하는 현실에서 NearlyFreeSpeech는 위험이 작은 타협안이며, 사용자 신뢰를 악용한 전력도 없고 비용도 사실상 미미함
    • Tor는 브라우저가 아니라 서비스임. Tor Browser는 개인정보 보호형 브라우저와 Tor 서비스를 묶은 편의 패키지일 뿐이라, 헤드리스 서버에서 브라우저 없이도 Tor 사이트를 운영할 수 있음
    • 숨김 서비스가 드문 이유는 방문자에게 너무 많은 수고를 요구하기 때문임. myfirstnamelastname.com을 알려주는 것과 56자의 무작위 .onion 주소를 전달하고 휴대전화에 Tor Browser까지 설치해 주는 것의 접근성 차이는 큼
  • 이 흐름에서 가장 큰 장벽은 콘텐츠 소유에 필요한 도메인 이름이며, 저렴해도 연간 약 6달러가 듦. 정적 사이트는 수많은 곳에서 무료로 호스팅할 수 있고 개인에게는 CDN 무료 등급으로 충분함
    서버 자체 호스팅보다 중요한 것은 도메인이라는 고유 식별자를 소유하는 것이며, 그 도메인이 어디를 가리키는지는 훨씬 덜 중요함

    • 소프트웨어 공학은 필요해서가 아니라 호기심 때문에 무언가 해보는 똑똑한 이들이 이끌어 왔음. 채용할 때도 학위보다 호기심과 추진력을 가장 중시했음
    • 연간 6달러는 하루 약 0.016달러로, 더 비싸긴 해도 여전히 저렴함
    • 정작 글의 어느 부분에서 직접 서버를 호스팅하자고 했는지 모르겠음
  • 웹 서버에 자기 파일을 올리는 일이 마치 새로운 개념처럼 취급되는 게 우스움

    • 파일이 무엇인지조차 모르는 사람이 많은 시대라 그 정신을 이어가는 일은 중요함
    • 인터넷 전체가 소수 거대 기업이 호스팅하고 통제하는 괴물로 변해 IndieWeb이라는 새 개념까지 필요해진 점이 안타까움. 파일 호스팅은 특권이 아니라 애초부터 인간의 권리에 가까워야 했음
      직접 호스팅할 기술은 여전히 있지만 사고방식이 클라우드 전용으로 바뀌었음
    • 예전에는 public_html 폴더에 파일을 넣기만 하면 곧바로 개인 웹사이트가 생겼음. HTML을 계속 손으로 작성해야 한다는 뜻은 아니지만, 당시에는 빠르고 자연스럽게 웹에 참여하는 방법이었음
      Unix 계정은 finger로 친구의 접속 여부를 확인하고 talkytalk로 대화하는 개인 간 채팅까지 제공했으며, 옆 단말기에 친구가 앉아 있어도 마법처럼 느껴졌음
    • 아이들이 하드웨어를 알게 될 때까지 기다려 보길 바람
  • 하루 0.01달러를 내는 NearlyFreeSpeech가 ‘100% 독립적 운영’이라면 Vercel, Netlify, GitHub, Cloudflare의 정적 호스팅과 큰 차이가 없어 보임
    데이터베이스, 피드백 양식, 소셜 미디어 미리보기, 검색 엔진 최적화가 필요할 때는 어떻게 하는지 글에 없는데, 아마 이런 부재가 ‘독립 웹’의 조건인지도 모르겠음

    • NearlyFreeSpeech에서는 PHP와 데이터베이스를 사용할 수 있음
    • NFS와 Vercel에 큰 차이가 없다면 이용자가 반반이어야 할 텐데 대부분 Vercel을 선택하는 이유가 궁금함
    • NFS는 여러 프로그래밍 언어가 설치된 전체 Linux 환경을 제공해 동적 웹사이트도 지원하지만 비용이 더 듦
    • 무료 요금제에서 10만 달러짜리 Netlify 청구서를 받은 사람도 있었음
  • 행사 웹사이트에 도메인이 필요했는데, Infomaniak이 도메인과 함께 10MB 저장 공간도 제공했음. 연간 약 5유로로 도메인과 사이트를 모두 마련할 수 있어 나쁘지 않음

  • Git 저장소 안에 모든 데이터를 보관하는 댓글용 JavaScript 플러그인 https://github.com/est/req4cmt를 만들었음. Git 서비스가 HTTP를 지원하면 사용할 수 있고 무료 Cloudflare Worker에서 실행되며, 백업과 이전은 git clonepush로 끝남
    Git 기반 Twitter 대체 프로젝트도 있음: https://github.com/est/gitweets
    데모는 https://f.est.im/이며 Git notes를 이용한 댓글도 지원함. Cloudflare Workers와 GitHub Pages 덕분에 모두 완전 무료임

  • sdf.org는 Unix 시스템을 직접 익히려는 개발자에게 유용함. NetBSD Unix의 무료 셸 계정을 제공하고, 소액의 일회성 기부로 웹 공간과 추가 기능을 이용할 수 있었던 것으로 기억함
    로그인 이름이 웹 공간의 하위 도메인이 되므로 신중히 골라야 함

  • 이런 주장을 하는 사이트가 Cloudflare나 GitHub Pages에 올라가 있지 않아 반가움

    • GitHub Pages는 도메인과 SSL을 제공하는 무료 호스팅이고 비용 청구가 없으며 장기 전망도 좋음. 정적 사이트를 신경 쓰고 싶지 않다면 GitHub와 Cloudflare 같은 대형 사업자가 가장 적합해 보임
    • GitHub Pages를 자주 권하지만 침실의 Raspberry Pi로 호스팅하는 방법도 작성했음: https://joeldare.com/private-analytics-and-my-raspberry-pi-4...
    • Cloudflare가 해적판 사이트들을 계속 살려두는 점은 고마움
    • Vercel이나 Netlify도 마찬가지임
  • 특정 도구보다 과정을 배우고 소유하는 편을 선호함. Markdown 같은 읽고 쓰기 쉬운 형식에서 Pandoc 등의 도구로 HTML을 만들고, HTML·CSS·JavaScript를 호스팅 서비스에 업로드하거나 동기화하는 법을 익히며, 도메인을 소유하고 DNS를 GitHub Pages나 Cloudflare Pages로 연결하는 법을 배우면 됨
    특정 도구·서비스·플랫폼·회사에 종속되지 않으므로 언제든 콘텐츠 파일을 다른 곳으로 옮길 수 있음. 원본 Markdown을 HTML로 변환하는 과정은 정적 사이트 생성기로 자동화할 수 있음
    HTML을 아는 것은 유용하고 재미있지만 ‘100% 독립적으로 사이트 운영’의 필수 조건일 필요는 없음. GitHub와 Cloudflare에서 월 0달러로 운영하다 서비스가 종료되거나 유료화되면 다른 곳으로 옮기면 됨

    • 글의 핵심은 게시물을 Markdown이나 데이터베이스 항목이 아니라 개별 HTML 파일로 두면 각 페이지마다 고유한 스타일, 외관, 배치와 개성을 부여할 수 있다는 것임. 현대 게시 도구가 만든 획일적인 블로그 틀에서 벗어나 모든 게시물을 다르게 만들 수 있음
    • HTML은 사람이 읽고 작성하기 좋은 형식임. 적절한 도구가 등장하기 전에도 컴퓨터공학 전공자가 아닌 이들까지 HTML, JavaScript, CSS를 텍스트 편집기에서 직접 다뤘으며 단순한 사이트라면 어렵지 않음
      과정의 소유와 완전한 독립성을 원한다면 웹 언어를 직접 이해하고 다룰 수 있어야 함. Nikola 같은 정적 사이트 생성기는 편리하지만, 출력물을 이해하거나 직접 수정할 수 없다면 여전히 제3자 도구에 의존하는 셈임