# 하루 15원으로 완전히 독립적인 웹사이트 운영하기 > Clean Markdown view of GeekNews topic #31625. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31625](https://news.hada.io/topic?id=31625) - GeekNews Markdown: [https://news.hada.io/topic/31625.md](https://news.hada.io/topic/31625.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-21T04:34:48+09:00 - Updated: 2026-07-21T04:34:48+09:00 - Original source: [neatnik.net](https://www.neatnik.net/hardcore-indieweb) - Points: 3 - Comments: 1 ## Topic Body - **Hardcore IndieWeb**는 콘텐츠 원본과 게시 가능한 HTML·웹 자산을 자신의 장치에 보관해, 서비스 사업자에게 정체성과 콘텐츠 통제권을 맡기지 않는 방식임 - HTML을 브라우저에서 미리 본 뒤 호스트에 올리는 **1990년대식 출판 과정**을 따르면 CMS·SSG·프레임워크·CLI·월 구독 없이 사이트를 운영할 수 있음 - 텍스트 편집기와 SFTP 도구, 웹 호스트만 있으면 되며, **NearlyFreeSpeech.net**에서는 정적 사이트를 하루 $0.01에 운영하고 $0.25부터 충전할 수 있음 - 랜딩 페이지와 개별 게시물, 아카이브, Atom 피드를 파일로 직접 관리해 페이지마다 구조와 디자인을 바꾸고 **변경된 파일만 전송**할 수 있음 - 호스트가 사라져도 완성된 사이트를 다른 곳에 그대로 올릴 수 있지만, 도구를 추가할수록 의존성도 늘어나므로 **로컬 원본과 게시본 보유**가 독립성을 유지하는 조건임 --- ### Hardcore IndieWeb가 요구하는 독립성 - [IndieWeb](https://indieweb.org)는 웹상의 **정체성과 콘텐츠를 직접 소유**하고 기업의 외부 통제에서 벗어나려는 실용적 접근 방식임 - 구독형 블로그 서비스도 IndieWeb 참여를 도울 수 있지만, 콘텐츠가 타인의 데이터베이스와 서버에 주로 존재한다면 완전히 독립적이지 않음 - 공개 형식으로 내보낼 수 있더라도 서비스를 이용하는 동안에는 콘텐츠를 완전히 통제하지 못함 - 기존 서비스에 만족하는 사람보다 콘텐츠에 대한 완전한 독립과 통제를 원하는 사람에게 맞는 방식임 - Hardcore IndieWeb는 기존 IndieWeb 원칙에 **통제권과 이식성**이라는 구체적인 기준을 적용함 - 콘텐츠가 주로 자신의 하드 드라이브에 없다면 완전히 통제한다고 보기 어려움 - 게시된 HTML과 웹 자산의 사본이 하드 드라이브에 없다면 사이트가 완전히 이식 가능한 상태가 아님 - 서비스가 폐업해 데이터를 내보낼 수 없게 되면 명목상 콘텐츠 소유권이 있어도 접근하거나 이전할 수 없음 - 운영자의 행동 때문에 서비스를 떠나려 해도 내보낸 형식을 지원하는 다른 서비스를 찾거나, 콘텐츠를 변환하고 도구와 절차를 바꿔야 할 수 있음 - 로컬에 콘텐츠 원본과 완성된 게시본이 있으면 이런 상황에서도 **통제권과 이식성**을 유지할 수 있음 ### 1990년대식 웹 출판 절차 - Hardcore IndieWeb는 웹 초창기의 단순한 출판 방식을 따름 1. 하드 드라이브에서 콘텐츠 작성 2. 웹 브라우저에서 미리 보기 3. 만족하면 웹 호스트에 업로드하고 필요할 때마다 반복 - 도메인 외에 필요한 것은 **텍스트 편집기, 파일 전송 도구, 웹 호스트**뿐임 - 프로그래밍 환경이나 IDE, 프레임워크, 셸, CLI 도구, 월 구독은 필요하지 않음 - HTML 지식은 필요하지만 [HTML for People](https://htmlforpeople.com) 같은 자료로 배울 수 있으며, 소수의 태그와 복사·붙여넣기만으로도 시작 가능함 - 복잡한 SaaS·CMS·SSG·마크업 언어·템플릿 시스템은 선택 사항이며, 파일을 직접 게시하는 단순한 방식도 여전히 작동함 ### 필요한 도구와 호스팅 - 텍스트 편집기는 디스크에 파일을 저장할 수 있다면 무엇이든 사용할 수 있음 - Adam Newbold는 파일 전송까지 지원하는 [Nova](https://usesthis.com/interviews/adam.newbold/)를 사용함 - 다른 선택지는 [텍스트 편집기 목록](https://en.wikipedia.org/wiki/List_of_text_editors)에서 찾아볼 수 있음 - 파일 전송에는 **SSH 또는 SFTP**를 지원하는 도구가 필요함 - [FileZilla](https://filezilla-project.org)는 여러 운영체제를 지원하는 선택지임 - 정적 사이트 호스트로 [NearlyFreeSpeech.net](https://www.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](https://html5up.net) 같은 무료 디자인과 템플릿을 내려받아 편집할 수 있음 ### 블로그를 구성하는 파일 - 일반적인 블로그는 **랜딩 페이지, 게시물, 아카이브 페이지, 피드**로 구성되며 전용 블로그 서비스 없이 직접 관리할 수 있음 - ## 랜딩 페이지 - 최신 게시물 전체나 일부, 여러 게시물 또는 게시물이 아닌 콘텐츠를 자유롭게 배치할 수 있음 - 최신 게시물을 표시하려면 내용을 복사하고 독립 페이지로 연결되는 링크를 추가함 - 최근 게시물 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](https://www.uuidgenerator.net)에서 새 UUID를 받아 사용함 - 완성한 피드는 [W3C Feed Validation Service](https://validator.w3.org/feed/#validate_by_input)에 붙여 넣어 파싱 가능 여부를 검사할 수 있음 - 오류가 발견되면 검증 서비스에서 수정할 항목을 확인할 수 있음 ### 게시와 업데이트 - 최초 게시 때는 파일 전송 프로그램으로 서버에 접속해 사이트 전체를 웹 호스트로 복사함 - 이후에는 **새로 생기거나 변경된 파일만 전송**하면 됨 - 일반적인 업데이트 대상은 랜딩 페이지, 새 게시물, 피드, 아카이브 페이지임 - 게시 과정은 로컬 파일을 원격 서버로 끌어다 놓는 수준으로 처리 가능함 ### 이식성과 추가 도구의 경계 - 완성된 사이트가 자신의 컴퓨터에 있으므로 기존 호스트가 사라져도 다른 호스트에 그대로 업로드할 수 있음 - 블로그 소프트웨어의 중대한 보안 취약점이나 SSG 의존성을 관리할 필요가 없고, 콘텐츠의 모든 측면을 직접 통제할 수 있음 - 이 절차를 그대로 유지하는 것만으로 완전히 독립적인 웹사이트를 계속 운영할 수 있음 - 작업 흐름을 돕는 도구와 절차를 추가할 수 있지만, **도구 하나를 더할 때마다 새로운 의존성**도 생김 - 콘텐츠 원본이 자신의 장치에 있고 게시 가능한 사이트 전체의 사본을 보유한다면 Hardcore IndieWeb의 조건을 충족함 ### 직접 HTML을 다루는 자율성 - 핵심 절차는 **HTML을 직접 작성해 웹 서버에 업로드하는 것**임 - 지난 30년 동안 추가된 기술 계층과 절차, 기대 수준은 웹 작업을 복잡하게 만들고 통제권과 독립성을 다른 사람에게 넘기게 했음 - IndieWeb 서비스를 사용하더라도 웹 존재 전체의 유일한 사본을 서비스 운영자에게 맡긴다면 완전히 독립적이지 않음 - Hardcore IndieWeb는 모든 사람을 위한 방식은 아니지만, 자신의 글을 누가 보유하고 어디에 어떤 형태로 게시할지를 중시하는 사람에게 적합함 - HTML을 직접 다루고 자신의 웹 호스트 공간으로 파일을 복사하는 과정은 초기 웹의 즐거움과 다시 연결되는 **직접적이고 자율적인 경험**을 제공함 ## Comments ### Comment 62112 - Author: neo - Created: 2026-07-21T04:34:49+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48962758) - 정적 사이트를 **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-Location**과 **Alt-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`로 친구의 접속 여부를 확인하고 `talk`나 `ytalk`로 대화하는 개인 간 채팅까지 제공했으며, 옆 단말기에 친구가 앉아 있어도 마법처럼 느껴졌음 - 아이들이 **하드웨어**를 알게 될 때까지 기다려 보길 바람 - 하루 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 clone`과 `push`로 끝남 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자 도구에 의존하는 셈임