▲

Gwtar: 정적이고 효율적인 단일 파일 HTML 형식

 (gwern.net)
1P by GN⁺ 9시간전 | ★ favorite | 댓글 1개
  • 웹 브라우저가 효율적으로 지연 로딩(lazy-loading) 할 수 있는 단일 HTML 아카이브 파일 형식으로, 모든 자산을 포함하면서도 정적·단일·효율성을 동시에 달성함
  • HTML과 JavaScript 헤더 뒤에 tarball 형태의 원본 HTML 및 자산을 결합하고, JS가 HTTP Range 요청을 통해 필요한 부분만 불러오는 구조
  • 기존 SingleFile이나 MHTML 등은 정적성과 단일성은 갖추지만 효율성이 부족했으며, Gwtar는 이를 해결함
  • 서버 측 추가 설정 없이 표준 브라우저 기능만으로 작동하며, Cloudflare 등 일부 환경에서는 MIME 타입 x-gwtar로 대응
  • 대용량 HTML 페이지의 보존성과 접근성을 동시에 확보해, 장기 웹 아카이빙 및 재현 가능한 연구 자료 보관에 유용함

Gwtar 개요

  • Gwtar는 단일 HTML 파일로 구성된 새로운 폴리글랏(Polyglot) 아카이브 형식으로, 브라우저가 HTTP Range 요청을 통해 필요한 부분만 로드함
    • Gwern.net의 대형 HTML 아카이브 제공에 사용
  • HTML 헤더의 JS가 파일 전체 다운로드를 중단하고, 필요한 자산만 부분 요청(range request) 으로 불러옴
  • 결과적으로 서버는 단일 HTML 파일만 제공하지만, 사용자는 필요한 자산만 다운로드함
  • 모든 기능이 표준 브라우저 기능으로 구현되어 미래 호환성 확보

HTML 아카이브의 삼중 딜레마

  • HTML 아카이브는 정적성, 단일 파일성, 효율성 중 두 가지만 만족시키는 기존 한계 존재
    • 예: SingleFile은 정적·단일이지만 비효율적, WARC는 정적·효율적이지만 단일 파일 아님
  • SingleFile로 생성된 스냅샷은 완전한 정적 페이지를 제공하지만, 모든 자산을 Base64로 인라인하여 파일 크기가 수백 MB로 커짐
  • 사용자는 페이지 일부만 보더라도 전체 파일을 다운로드해야 하는 비효율 발생
  • Gwern.net은 이를 해결하기 위해 deconstruct_singlefile.php로 자산을 분리했으나, 단일 파일성 상실

Gwtar의 기술적 접근

  • HTTP Range 요청을 활용해 파일 일부만 선택적으로 다운로드 가능
  • HTML + JS 헤더 뒤에 tarball을 결합한 연속(concatenated) 아카이브 구조 채택
  • JS의 window.stop() 명령으로 헤더 이후 다운로드를 중단하고, 필요한 자산만 요청
  • 브라우저는 일반 HTML처럼 렌더링하며, JS가 자산 요청을 가로채 Range 요청으로 변환

생성 및 구현

  • PHP 스크립트 deconstruct_singlefile.php로 SingleFile HTML을 Gwtar로 변환 가능
    • JPG/PNG/GIF 재압축 및 PAR2 FEC(전방 오류 정정) 데이터 추가 지원
  • 브라우저는 JS 실행 후 필요한 자산만 Range 요청으로 불러오며, JS 비활성 시 전체 파일 다운로드로 대체
  • 표준 기반으로 서버 설정이나 추가 소프트웨어 불필요, 단일 파일에서 다시 다중 파일 HTML로 복원 가능

성능 및 호환성

  • Range 요청 미지원 시 전체 파일을 다운로드하지만, gzip/Brotli 압축으로 속도 보완 가능
  • Cloudflare는 text/html 응답의 Range 헤더를 제거하므로, Gwern.net은 MIME 타입을 x-gwtar로 설정해 우회
  • 로컬에서는 파일 보기 불가능 :
    • 이건 SingleFileZ도 마찬가지로, 브라우저 보안 정책(CORS 등)으로 JS 요청이 차단되기 때문
    • 아쉽지만 허용 가능한 트레이드오프라고 생각하며, 로컬 브라우징은 JS의존적이지 않은 파일로 변환을 통해 해결 가능

확장 기능

  • Gwtar 파일 끝에 추가 바이너리 데이터(예: FEC, 서명, 메타데이터) 부착 가능
  • PAR2를 이용해 파일 일부 손상 시 복구 가능
  • GPG 서명을 HTML 주석 형태로 삽입해 무결성 검증 가능
  • 향후 버전에서는 자산 해시 검증, 자동 프리페치, 압축 내장, 다중 페이지 지원 등이 계획됨

활용 가능성

  • 대형 HTML 페이지나 연구 데이터셋(예: SQLite3) 을 포함한 재현 가능한 과학 연구에 적합
  • 브라우저에서 직접 데이터베이스를 Range 요청으로 불러와 분석 가능
  • 장기 보존성과 접근성을 동시에 확보하는 웹 아카이빙 포맷으로 제안됨

라이선스 및 향후 개발

  • Gwtar 문서와 코드는 CC-0 퍼블릭 도메인으로 공개
  • 향후 버전(v2)에서는 FEC 의무화, 내장 압축, 다중 문서 지원, 중복 제거 개선 등이 검토됨
▲
GN⁺ 9시간전  [-]
Hacker News 의견들

  • 오늘 처음으로 window.stop() 을 알게 되었음
    이 함수는 브라우저가 더 이상 리소스를 로드하지 않게 멈추는 기능을 함
    주요 브라우저들이 이미 10년 넘게 지원 중임 (MDN 문서, Can I Use)
    사용 예시는 이 스크린샷에서 볼 수 있음
    더 자세한 내용은 내 블로그 글에 정리했음

    • SPA 개발자라면 이게 document.write나 window.open 같은 API보다 낫다고 보긴 어려움
      다만 서버 중심 로직에서 다운로드나 lazy-loading을 직접 구현하려는 경우엔 흥미로운 접근일 수 있음
      초기화나 리디렉션 스크립트처럼 특수한 상황이 아니라면 권장하긴 어려움
    • 혹시 이게 Claude Artifacts와 호환될지 궁금함
      나는 직접 만든 번들러를 통해 파일을 압축된 base64 청크 형태로 게시하는데, 이 방식과 비슷함
      만약 이런 단일 파일 공유 환경에서 작동한다면, 플랫폼이 이를 막을지도 모르겠다는 생각이 듦
    • 나도 이 기능은 처음 알았음
      PHP에도 비슷한 __halt_compiler() 기능이 있어서, 파일 끝에 문서나 데이터를 주석 없이 넣을 때 써봤음

  • 처음엔 흥미로웠는데, 이 형식이 로컬 파일에서 바로 열리지 않는다는 걸 보고 망설여졌음
    보관용 포맷이라면 로컬 접근이 핵심 사용 사례 중 하나일 텐데 말임

    • 나도 그렇게 생각함. 마치 asm.js처럼 브라우저에 기본 탑재된 기능을 활용해 새로운 가능성을 열 수 있을 거라 기대했음
      하지만 로컬에서 바로 열 수 없다면 그 장점이 많이 줄어듦 (backdoor pilot 개념 참고)
    • 뷰어 프로그램이나 간단한 정적 HTML 서버로 해결할 수 있지 않을까 생각함
    • 사실 HTML 자체가 이미 훌륭한 단일 파일 포맷임
      이미지, CSS, JS 모두 data-uri로 인라인 가능하고, 폰트도 마찬가지임
      오히려 워드프로세서 문서 포맷이 HTML을 썼다면 더 유연했을 것 같음
    • python -m http.server 같은 명령으로 로컬 서버를 띄우면 간단히 해결 가능함
      Claude 명령으로도 가능함

  • 작성자가 이 글을 본다면, 아카이브 포맷에 BASE64 스크린샷 필드와 설명 필드, 그리고 ISO 타임스탬프를 추가해줬으면 함
    나아가 동일 URL의 여러 버전을 저장하고 중복 자산 제거 기능이 있다면 이상적일 것 같음

  • 글쓴이가 WARC를 부정적으로 본 이유를 모르겠음
    오히려 Gwtar가 더 복잡하고 덜 유연해 보임

    • 하지만 WARC는 브라우저에서 바로 클릭해 내용을 볼 수 있는 URL을 제공하지 못함
    • 또 다른 댓글에서 언급된 이유는, WARC/WACZ는 정적이고 효율적이지만 단일 파일로 직접 표시할 수 없고, 별도의 WebRecorder 같은 복잡한 설치가 필요하다는 점임

  • SingleFile의 ZIP/HTML polyglot 포맷이 “정적이고 단일이지만 비효율적”이라 한 이유가 궁금함
    Gwtar와 비교해 어떤 점이 비효율적인지 알고 싶음

    • 여기서 말하는 효율성은 필요한 자산만 부분적으로 다운로드할 수 있는 능력을 뜻함
      브라우저가 요청할 때 전체 파일을 받지 않고 range request로 필요한 부분만 가져올 수 있는지가 핵심임

  • 정말 멋진 아이디어임
    나는 단일 파일 HTML 웹앱이 가장 오래 지속 가능한 소프트웨어 형태라고 생각함
    내가 만든 예시로는 FuzzyGraph와 HyperVault가 있음

  • 나도 비슷한 걸 Service Worker 레벨에서 구현해볼까 생각했음
    페이지는 그대로 두고, 모든 HTTP 요청을 가로채는 방식임
    window.stop() 처럼 HTML 일부만 받고 나머지는 자산 블롭으로 처리하는 구조임
    Service Worker 자체를 dataURI로 넣으면 완전한 단일 파일이 될 수 있음

  • 흥미롭지만, 로컬 파일에서 lazy load가 왜 필요한지 잘 모르겠음
    파일이 그렇게 클 예정인가? 아니면 이미 구현된 기능을 그대로 유지하려는 건가?

    • 실제로는 로컬이 아니라 HTTP 서버에 있는 대용량 파일을 대상으로 함
      네트워크에서 전체를 받지 않고 필요한 부분만 요청하기 위해 range request가 필요함
      물론 여러 파일로 나누는 게 더 일반적이지만, 단일 파일 관리가 더 편할 때도 있음
      아마 Gwern의 MediaWiki 기반 사이트 구조와 관련 있을 수도 있음

  • 예전에 나도 비슷한 걸 만들어봤음 — Zundler라는 프로젝트인데, 꽤 해킹스러운 접근이었음
    로컬에서도 작동하지만, 처음에 전체 압축을 풀어야 함

    • 이건 SingleFileZ처럼 단일 정적 HTML 아카이브지만 로컬에서도 쉽게 볼 수 있는 형태로 보임
      다만 보안 제한을 어떻게 우회했는지 궁금함
      설명에선 단일 출처(single-origin) 관련 언급만 있어서 완전히 이해하긴 어려움
답변달기