Show HN: Kage – Shadow any website to a single binary for offline viewing

2026-06-15 · 2026-06-15_kage-shadow-website-to-binary.md

#web-archiving #offline-viewing #go #headless-browser #static-site #zim-archive

원문 출처

Show HN: Kage – Shadow any website to a single binary for offline viewing

한 줄 요약

Go로 작성된 Kage는 헤드리스 크롬을 이용해 웹사이트를 렌더링한 후 JavaScript를 완전히 제거하고, CSS·이미지·폰트 등 자산을 로컬화하여 오프라인에서 볼 수 있는 정적 미러를 만든다. ZIM 아카이브나 단일 실행 파일로 패키징할 수도 있다.

1. 원문 핵심 내용

Kage(影)가 무엇인가

Kage는 웹사이트를 "그림자"처럼 복사해서 오프라인에서 볼 수 있게 하는 도구다. Go 언어로 작성되었으며, MIT 라이선스를 사용한다.

핵심 동작 흐름:

  1. 렌더링 — 헤드리스 크롬(Chrome without GUI)이 웹사이트를 실제로 로드하고 렌더링한다. JavaScript가 실행된 결과 상태를 포착한다는 점이 일반 "페이지 저장"과 차별된다.
  2. 스냅샷 — 렌더링이 완료된 최종 DOM(문서 객체 모델)을 캡처한다.
  3. 제거 — <script> 태그, on* 이벤트 핸들러, javascript: URL을 모두 제거한다.
  4. 로컬화 — CSS, 이미지, 폰트를 다운로드하고 URL을 로컬 경로로 재작성한다.
  5. 저장 — 결정론적(같은 입력이면 같은 출력) 디렉토리 구조로 저장한다.

주요 명령어

  • kage clone <url> — 웹사이트 크롤링 및 정적 미러 생성
  • kage serve [dir] — 생성된 폴더를 로컬 HTTP 서버로 제공
  • kage pack <dir> — ZIM 아카이브 또는 단일 실행 파일로 패키징
  • kage open <file> — 패키징된 파일 오프라인에서 열기

패키징 옵션

ZIM 아카이브 — Kiwix(오프라인 위키백과 앱)에서 사용하는 오픈 표준 포맷. 압축률이 높고 결정론적이며 Kiwix 데스크탑/모바일 앱과 호환된다. 단, 전체 텍스트 색인이 없어서 검색이 제한적이다.

단일 실행 파일 — 웹사이트 아카이브가 첨부된 실행 파일. 수신자가 아무런 의존성 없이 실행할 수 있지만, 기본 크기가 약 13MB + 사이트 용량이다. 크로스 플랫폼 빌드도 지원한다.

기술 아키텍처

  • 언어: Go (95.6%)
  • 모듈: clone/(크롤링 오케스트레이션), browser/(DevTools 프로토콜을 통한 헤드리스 크롬 제어), sanitize/(DOM 정화), asset/(자산 다운로드 및 재작성), zim/(순수 Go ZIM 리더/라이터), viewer/(네이티브 창 또는 브라우저 오픈)

저자의 더 큰 비전

저자 tamnd는 Kage가 더 큰 프로젝트의 일부라고 밝혔다. "누구나 호스팅할 수 있는 Google을 처음부터 다시 만드는 것" — 크롤러, 인덱서, 스토리지, 서빙 레이어 모두 오픈소스로. 관련 프로젝트로 ccrawl-cli(Common Crawl WARC를 Markdown으로 변환)도 있다.

2. 커뮤니티 반응 (HN 댓글 83개 분석)

A. README 품질에 대한 강한 비판 (AI slop 논란)

가장 많은 반응을 끈 주제다.

  • sneak: "README은 LLM slop(AI가 생성한 저품질 콘텐츠)다. 코드도 같은 수준일 것이라 가정하게 만든다."
  • chinnyys: "README이 AI slop이고 읽는 것 자체가 불쾌하다. 프로젝트 자체를 시도할 마음이 거의 사라질 정도였다. 코드도 AI slop인가?"

이 비판은 단순히 "README이 AI로 썼다"는 수준을 넘어, "AI가 쓴 README을 보면 코드 품질도 의심된다"는 연쇄 불신으로 이어졌다. HN 커뮤니티에서 AI 생성 README에 대한 반감은 점점 커지는 추세다.

B. "기존 도구와 무엇이 다른가?" — 비교 질문

여러 사용자가 기존 도구들과의 차이를 물었다:

  • chfritz: "puppeteer로 페이지를 로드해서 DOM을 HTML로 저장하는 것과 어떻게 다른가?"
  • HelloUsername: "브라우저의 파일 → 저장하기와 뭐가 다른가?"
  • shinryuu: gwern.net의 gwtar와 비교했을 때 Kage가 더 잘하는 것이 무엇인가?
  • maxloh: 설명이 "단일 페이지 저장"처럼 오해하게 쓴다. 실제로는 전체 웹사이트를 다운로드하는 도구라는 점을 명확히 해야 한다.

저자 tamnd는 답변에서 "단일 페이지가 아니라 전체 웹사이트를 미러링한다"고 명확히 했다.

C. 보안 우려 — 단일 바이너리 포맷

  • cynicalsecurity: "바이너리 앱은 데이터를 저장하는 정말 나쁜 방식이다. 온라인에서 찾거나 누군가 공유한 바이너리를 실행하려는 사람은 아무도 없을 것이다."

이 지적은 타당하다. 실행 파일로 웹사이트를 배포하는 것은 보안 관점에서 위험할 수 있다 — 사용자가 바이너리 내용을 검증할 수 없기 때문이다.

D. 대안 제안 — 단일 HTML 페이지

  • ninalanyon: "결과가 정적이라면 왜 서버가 필요한가? 모든 페이지를 하나의 HTML 파일에 번들링하면 서버 없이도 작동한다."
  • 이 아이디어에 대해 저자가 "좋은 아이디어다, 구현을 고려하겠다"고 답변했다.

E. 저자의 적극적 참여

저자 tamnd가 댓글에 매우 적극적으로 답했다:

  • Apple Docs, paywall 우회, WARC 포맷 등 다양한 질문에 답변
  • "이미 1시인데도 감사하다"는 반응까지
  • 더 큰 비전(오픈소스 Google)을 공개하며 관심을 유도

F. ZIM/Kiwix 호환성에 대한 긍정

  • sanqui: "기존 포맷과 호환되는 것을 좋아한다! WARC 포맷은 HTTP2 시대에 다소 underspecified(규격이 불충분한) 상태다. Kage의 크롤러와 mitmproxy 캡처를 결합하면 새로운 아카이브 포맷이 될 수도 있다."
  • Marginalia Search(대안 웹 검색 엔진)와의 시너지 가능성도 언급

G. 데모 GIF 생성 도구 발견

  • simonw: README의 데모 GIF가 저자의 또 다른 프로젝트 ascii-gif를 통해 생성되었음을 발견하고, charmbracelet/vhs(터미널 녹화 도구)를 래핑하는 것임을 분석했다.

3. 새로운 시각

(1) "JavaScript 제거"가 오히려 아카이빙의 핵심 강점

대부분의 웹사이트 아카이빙 도구(Wayback Machine, HTTrack 등)는 원본을 가능한 한 완벽하게 보존하려는 경향이 있다. 하지만 Kage는 의도적으로 JavaScript를 제거한다. 이는 단점이 아니라 오히려 장점이 될 수 있다 — JavaScript는 시간이 지나면 깨진다. 외부 API가 사라지고, CDN 링크가 만료되고, 프레임워크 버전이 호환되지 않는다. JavaScript를 제거한 정적 HTML은 10년 뒤에도 더 잘 살아남을 가능성이 높다. HN 댓글에서 coffeecoders가 "예쁜 아카이브보다 추한 HTML 덤프가 더 유용했다"고 말한 것은 이 관점을 뒷받침한다.

(2) 아카이빙과 검색의 교차점 — 저자의 "오픈소스 Google" 비전이 현실적일 수 있다

저자가 단순히 "웹사이트 저장 도구"를 넘어 "누구나 호스팅할 수 있는 Google"을 만든다고 밝혔다. ZIM 포맷(Kiwix) + Markdown 변환 + Git 저장소라는 조합은 실제로 의미 있는 방향이다. Kiwix는 이미 오프라인 위키백과를 전 세계에 배포하는 검증된 생태계이고, Markdown은 텍스트 검색에 최적화된 포맷이며, Git은 버전 관리와 분산 저장소를 제공한다. 이 세 가지가 결합되면 "개인용 오프라인 검색 엔진"이라는 새로운 카테고리가 탄생할 수 있다.

(3) AI slop README 논란이 오히려 프로젝트에 집중시킨 역설

README이 AI slo프라는 비판이 가장 많은 반응을 끌었지만, 이 논란 덕분에 사람들이 프로젝트 자체를 더 깊이 들여다보게 되었다. simonw가 데모 GIF 생성 파이프라인을 분석했고, sanqui가 ZIM 포맷의 한계를 논의했으며, shinryuu가 gwtar와 비교했다. 만약 README이 "완벽해" 보였으면 이런 깊은 분석은 일어나지 않았을 것이다. 오히려 AI slop 논란이 커뮤니티의 관심을 끌고, 저자의 적극적 답변이 프로젝트의 실제 가치를 드러내는 계기가 되었다.

4. 자녀/미래 영향

아인(장녀)

웹사이트 아카이빙은 디지털 시민으로서 중요한 리터러시다. 인터넷의 콘텐츠는 언제 사라질 수 있다 — 링크가 죽거나, 서비스가 종료되거나, 계정이 삭제된다. 아인이 관심 있는 글을 읽을 때, 단순히 북마크하는 것보다 Kage 같은 도구로 오프라인에 저장하는 습관을 들이면 디지털 자료를 더 잘 보존할 수 있다. 특히 ZIM 포맷은 Kiwix 앱을 통해 모바일에서도 오프라인 읽기가 가능하므로, 여행 중이나 인터넷이 안 되는 상황에서도 지식을 접근할 수 있다.

석현(차남)

Go 언어로 작성된 실제 오픈소스 프로젝트라는 점에서 코딩 학습 자료로 유용하다. 특히 browser/ 모듈이 Chrome DevTools 프로토콜을 어떻게 사용하는지, sanitize/ 모듈이 DOM을 어떻게 조작하는지 보면 웹 기술의 실제 적용 사례를 배울 수 있다. 또한 "headless browser"라는 개념은 자동화 테스트, 웹 스크래핑, CI/CD 파이프라인 등 다양한 분야에서 사용되는 핵심 기술이다.

은한(삼남)

"단일 실행 파일로 웹사이트를 패키징한다"는 아이디어 자체가 창의적이다. 미래에는 웹사이트를 "파일"처럼 주고받는 것이 더 일반화될 수 있다. 은한이 자랄 때쯤이면, 웹 페이지를 링크로 공유하는 대신 아카이브 파일을 공유하는 것이 보편화되어 있을 수도 있다. 특히 인터넷 접근이 제한된 지역이나 상황에서는 이러한 오프라인 아카이빙 기술이 지식 평등을 이끄는 도구가 될 수 있다.

관련 노트