해커뉴스 588점 글, 좋아하는 사이트는 직접 백업하라
2004년부터 열려 있던 애니메이션 팬 사이트가 어느 날 사라졌고, 그 도메인에는 온라인 도박 광고가 걸려 있었다는 이야기로 글이 시작합니다. 2005년 이후로 거의 바뀐 적 없는 사이트였지만, 글쓴이는 가끔 들어가 옛 친구가 잘 있는지 보듯 그 페이지를 열어 보곤 했다고 적었습니다.
반전은 글쓴이의 직업입니다. 웹 아카이빙 일을 하는 사람이라 언젠가 사이트가 내려갈 것도, 그걸 막을 도구가 있다는 것도 알고 있었는데 정작 그 사이트는 떠 두지 않았다고 털어놓습니다. 10월 29일 개인 블로그에 올라온 이 글은 11월 3일 밤 해커뉴스에서 588점, 댓글 135개를 기록하며 첫 페이지에 올라 있었습니다.
요지는 단순합니다. 웹 아카이빙을 인터넷 아카이브 같은 큰 기관만 하는 일로 보지 말고, 아끼는 페이지가 있으면 본인이 직접 백업하라는 것입니다. 글은 개인이 바로 쓸 수 있는 도구 세 가지와, 백업한 파일을 다시 열어 보고 다른 사람과 나누는 방법까지 이어서 설명합니다.
다만 글쓴이는 소개한 도구가 자기 회사인 Webrecorder 제품이라고 미리 밝혀 두었습니다. 대부분 무료이고 소스도 공개돼 있지만 그 점은 감안하고 읽는 편이 좋습니다. 그래서 여기서는 글이 추천한 도구를 정리하면서, 회사와 상관없는 GNU Wget으로 같은 형식의 파일을 직접 만들어 다시 열어 본 결과를 함께 놓았습니다.
웹 아카이브 파일 WARC와 WACZ의 차이
글에 나오는 도구는 모두 WARC라는 표준 형식으로 저장합니다. 브라우저 메뉴의 다른 이름으로 저장이 지금 보이는 페이지 하나를 HTML과 파일 폴더로 바꿔 두는 방식이라면, WARC는 브라우저와 서버가 주고받은 요청과 응답을 헤더까지 그대로 기록합니다. 글쓴이는 이 차이 덕분에 자바스크립트가 요청을 잔뜩 보내는 복잡한 사이트도 담을 수 있다고 설명합니다.
WARC 파일 자체는 응답을 차례로 이어 붙인 긴 기록입니다. 그대로는 어느 페이지가 어디 있는지 찾기 번거롭기 때문에, Webrecorder 도구들은 WACZ라는 형식을 함께 씁니다. WACZ는 WARC 원본에 주소별 색인, 페이지 목록, 파일 정보를 더해 ZIP 하나로 묶은 것이고, 형식은 Webrecorder가 공개한 WACZ 1.1.1 규격 문서에 정의돼 있습니다.
WACZ의 쓸모는 다시 열 때 드러납니다. ReplayWeb.page 문서에 따르면 다른 형식은 파일 전체를 내려받아야 재생할 수 있지만, WACZ는 서버가 HTTP 범위 요청을 지원하면 지금 보는 페이지에 필요한 부분만 꺼내 옵니다. 수 GB짜리 아카이브를 웹에 올려 두고 필요한 페이지만 열게 할 수 있다는 뜻입니다.
호환성도 이 형식을 따라갑니다. Browsertrix는 업로드를 WACZ로만 받고, 이미 가진 WARC는 py-wacz라는 명령줄 도구로 바꾸라고 안내합니다. 변환은 손실 없이 이뤄지고, WACZ를 ZIP 도구로 풀면 원래 WARC가 그대로 들어 있습니다. 아래에서 직접 만든 파일도 풀어 보면 archive 폴더에 WARC 원본이, indexes와 pages 폴더에 색인과 페이지 목록이 들어 있었습니다.
ArchiveWeb.page와 Browsertrix, 원글이 추천한 도구
가장 쉬운 방법으로 꼽힌 것은 크롬 확장 프로그램 ArchiveWeb.page입니다. 확장을 설치하고, 저장할 첫 페이지를 연 뒤 도구 막대의 아이콘에서 Start Archiving을 누릅니다. 펼침 메뉴나 탭처럼 눌러야 내용이 나오는 부분은 직접 눌러 데이터를 불러오고, 같은 묶음에 넣을 다른 페이지도 차례로 열어 둔 다음 Stop Archiving을 누르면 끝입니다.
눈으로 보면서 누른 것만 저장되니 사람이 직접 둘러볼 수 있는 몇 페이지나 SNS 글 하나, 프로필 하나를 남기기에 맞습니다. 저장한 묶음은 확장의 대시보드에서 바로 열어 제대로 담겼는지 볼 수 있고, 크롬을 쓰지 않는다면 브라우저가 들어 있는 데스크톱 앱 버전도 있습니다.
페이지가 많아 하나씩 열기 번거로운 사이트는 크롤러가 맞습니다. Browsertrix는 시작 주소와 범위를 정해 주면 진짜 브라우저로 페이지를 하나씩 열며 링크를 따라갑니다. 공식 안내에 따르면 자바스크립트로 나중에 불러오는 부분까지 담기고, 로그인이 필요한 페이지는 브라우저 프로필로 접근하되 수집용 계정을 따로 쓰라고 권합니다. 원글처럼 도메인 전체를 받거나 특정 경로 아래만 받도록 좁힐 수도 있습니다.
Browsertrix는 원글에서 유일하게 유료인 도구입니다. 7일 무료 체험 뒤 Starter 요금제가 월 30달러로, 실행 시간 180분, 저장 공간 100GB, 한 번에 최대 2,000페이지까지 받을 수 있습니다. 월 60달러 Standard는 360분과 5,000페이지, 월 120달러 Plus는 720분과 1만 페이지입니다. 요금은 수집에 걸린 시간에 브라우저 창 수를 곱해 계산되고, 소스가 공개돼 있어 직접 서버에 설치해 쓸 수도 있습니다.
| 도구 | 쓰는 곳 | 비용 | 맞는 경우 |
|---|---|---|---|
| ArchiveWeb.page 확장 | 크롬 확장 프로그램 | 무료 | 직접 둘러보는 몇 페이지, SNS 글과 프로필 |
| ArchiveWeb.page 앱 | 데스크톱 앱 | 무료 | 크롬 없이 저장하거나 저장한 아카이브를 볼 때 |
| Browsertrix | 웹 서비스, 직접 설치 가능 | 7일 무료 뒤 월 30달러부터 | 페이지가 많은 사이트 전체, 정기 수집 |
| GNU Wget | 리눅스, 맥, 윈도우 WSL 터미널 | 무료 | 자바스크립트 없이 열리는 블로그와 문서 |
원글이 소개한 도구 세 가지와 아래에서 직접 써 본 wget. Browsertrix 요금은 개인 요금제 기준.
wget으로 블로그 한 곳을 WARC로 떠 본 결과
원글에는 나오지 않지만, 리눅스에 흔히 깔려 있는 GNU Wget에도 WARC로 저장하는 옵션이 들어 있습니다. 윈도우 WSL의 우분투 24.04에 기본으로 있는 wget 1.21.4의 도움말을 보면 --warc-file부터 --warc-cdx, --warc-dedup까지 WARC 관련 옵션이 9개 있습니다. 대상은 남의 서버에 부담을 주지 않도록 이 블로그 bluebworks.com으로 잡았습니다.
명령은 아래와 같습니다. --recursive --level=1은 홈과 홈에서 바로 링크된 페이지까지만 따라가라는 뜻이고, --page-requisites는 각 페이지에 필요한 이미지와 스타일, 스크립트까지 받게 합니다. --domains로 다른 사이트로 새어 나가지 않게 막고, --wait=0.3으로 요청 사이에 0.3초씩 쉬게 했습니다. --warc-file을 주면 평소처럼 폴더에 파일을 저장하면서 같은 내용을 WARC로도 남깁니다.
결과는 파일 185개, 19MB였습니다. 실제로 데이터를 받는 데 걸린 시간은 2.3초인데 전체로는 2분 31초가 걸렸습니다. 요청마다 쉬는 시간과 연결을 맺는 시간이 대부분을 차지한 셈입니다. 남의 사이트를 받을 때 --wait를 빼면 훨씬 빨라지지만, 그만큼 상대 서버에는 짧은 시간에 요청이 몰립니다.
만들어진 WARC 파일은 18,585,729바이트였고, 함께 생긴 CDX 색인 파일에는 받은 주소마다 시각, 형식, 응답 코드가 한 줄씩 적혀 있습니다. 형식별로 세어 보면 PNG 78개, SVG 31개, WebP 21개로 이미지가 대부분이고 HTML이 48개였습니다. 글 위주의 블로그라도 백업 용량은 결국 이미지가 정한다는 걸 숫자로 볼 수 있습니다.
# 리눅스, 맥, 윈도우 WSL 터미널
wget --recursive --level=1 --page-requisites --no-parent \
--domains=bluebworks.com --wait=0.3 -e robots=on \
--warc-file=bluebworks-home --warc-cdx --no-verbose \
https://bluebworks.com/
# WARC를 WACZ로 묶기 (py-wacz)
# 가상환경에 설치 (우분투에서 venv가 없다고 나오면 먼저 sudo apt install -y python3-venv)
python3 -m venv ~/wacz-env
~/wacz-env/bin/pip install wacz
~/wacz-env/bin/wacz create -o bluebworks-home.wacz bluebworks-home.warc.gz --detect-pages
# 가상환경 없이 시스템 파이썬에 바로 설치하려면 (pip3가 없으면 sudo apt install -y python3-pip 먼저)
# pip3 install --user --break-system-packages wacz
# export PATH="$HOME/.local/bin:$PATH"WACZ로 묶고 ReplayWeb.page로 다시 열어 보기
받은 WARC는 Webrecorder의 py-wacz로 WACZ 하나로 묶었습니다. pip로 wacz 0.6.0을 설치하고 --detect-pages 옵션을 붙여 실행하니 3.7초 만에 끝났고, 페이지 37개가 목록에 잡혔습니다. 결과 파일은 18,609,470바이트로 원래 WARC보다 2만 4천 바이트쯤 늘었는데, 그 차이가 색인과 페이지 목록입니다.
다시 열 때 쓰는 도구는 ReplayWeb.page입니다. 브라우저 안에서 아카이브 파일을 읽어 그대로 재생하는 뷰어인데, 사이트에 WARC나 WACZ 파일을 고르면 내용이 어디에도 올라가지 않고 내 브라우저 안에서만 열린다고 밝혀 두었습니다. 원글이 블로그 본문에 사이트 하나를 통째로 넣어 보여 준 것도 이 뷰어를 웹페이지에 끼워 넣는 임베드 방식입니다.
임베드 방식도 그대로 따라 해 봤습니다. ReplayWeb.page 2.5.4의 ui.js와 sw.js를 받아 replay 폴더에 두고, WACZ 파일 옆에 HTML 몇 줄짜리 index.html을 만든 뒤 범위 요청을 지원하는 Node 로컬 서버로 열었습니다. 화면 위쪽 주소창 옆에 2026년 11월 3일 오후 9시 24분 58초라는 저장 시각이 붙은 채로 블로그 홈이 떴고, 기사 제목을 누르니 실제 사이트가 아니라 아카이브 안의 기사 페이지로 넘어갔습니다. 왼쪽 목록에는 페이지 37개가 저장 시각 순으로 나옵니다.
막힌 곳도 두 군데 있었습니다. 처음에는 replayweb.page 사이트에 로컬 서버 주소를 넣어 열려고 했는데 TypeError: Failed to fetch가 나왔습니다. 문서가 짚는 대로 다른 출처에서 파일을 불러올 때 생기는 CORS 문제라서, 뷰어와 WACZ를 같은 서버에 두는 자체 호스팅으로 바꾸니 해결됐습니다. 또 sw.js를 replay 폴더가 아니라 사이트 맨 위에 두었더니 서비스 워커가 사이트 전체를 가로채 빈 화면이 됐습니다. 문서에 적힌 대로 실제 서버에는 없는 경로인 replay 아래에 두는 게 맞습니다.
# 1) WACZ 파일이 있는 폴더에서 ReplayWeb.page 2.5.4 파일 받기
mkdir -p replay
curl -L -o replay/ui.js https://cdn.jsdelivr.net/npm/replaywebpage@2.5.4/ui.js
curl -L -o replay/sw.js https://cdn.jsdelivr.net/npm/replaywebpage@2.5.4/sw.js
# 2) 뷰어 페이지 만들기 (WACZ는 index.html 옆, ui.js와 sw.js는 replay 폴더)
cat > index.html <<'EOF'
<script src="./replay/ui.js"></script>
<replay-web-page source="/bluebworks-home.wacz"
url="https://bluebworks.com/" style="display:block;height:90vh"></replay-web-page>
EOF
# 3) 범위 요청을 지원하는 로컬 서버로 열기 (Node 필요)
npx http-server -p 8765
# 브라우저에서 http://127.0.0.1:8765/ 열기wget으로 안 되는 페이지와 도구 고르는 기준
wget이 모든 사이트에 똑같이 통하지는 않습니다. 같은 방식으로 X의 OpenAI 프로필 페이지를 --page-requisites까지 붙여 받아 보니 파일은 HTML과 robots.txt 두 개뿐이었습니다. HTML 안에는 소개 글과 최근 글 몇 개의 본문이 들어 있었지만, 그 페이지가 부르는 사진은 pbs.twimg.com, 동영상은 video.twimg.com, 스크립트는 abs.twimg.com이라는 다른 주소에 있어서 하나도 따라오지 않았습니다. wget은 따로 지정하지 않으면 처음 주소와 같은 호스트의 파일만 받기 때문입니다.
다른 호스트까지 받게 하는 --span-hosts 옵션이 있긴 합니다. 그래도 스크롤을 내릴 때 자바스크립트가 이어서 불러오는 글까지는 담지 못합니다. wget은 파일을 받기만 하고 페이지 안의 자바스크립트를 실행하지 않기 때문에, 브라우저에서 보던 화면과 아카이브가 점점 달라집니다.
이런 페이지는 브라우저가 실제로 불러온 것을 그대로 기록하는 도구가 맞습니다. 직접 둘러보며 저장할 분량이면 ArchiveWeb.page 확장, 프로필 전체나 많은 페이지를 정기적으로 받아야 하면 Browsertrix입니다. Browsertrix 안내에는 페이스북, 인스타그램, X 같은 SNS를 받기 쉽게 하는 설정이 자동으로 들어간다고 적혀 있지만, SNS 재생은 늘 쫓아가야 하는 대상이라는 단서도 함께 붙어 있습니다.
반대로 개인 블로그, 오래된 팬 사이트, 프로젝트 문서처럼 서버가 완성된 HTML을 바로 보내 주는 사이트는 wget 한 줄로 충분합니다. 무료이고 명령으로 돌아가니 크론에 걸어 매주 한 번씩 새로 떠 두기도 쉽습니다. 원글의 팬 사이트처럼 몇 년째 바뀌지 않는 사이트라면 한 번만 떠 둬도 됩니다.
백업한 파일은 여러 곳에 나눠 두는 게 원글이 마지막으로 권하는 방법입니다. WACZ는 파일 하나라 외장 디스크나 클라우드 드라이브에 그대로 올리기 쉽고, 같은 사이트를 아끼는 사람과 나눠 갖기도 좋습니다. 남의 사이트를 개인 보관용으로 떠 두는 것과 그 아카이브를 공개 웹에 다시 올리는 것은 저작권 면에서 다른 문제이니, 공개 공유는 원래 운영자와 이용 조건을 먼저 보고 정하는 편이 안전합니다.
