작은 아카이브를 위한 정적 웹사이트 활용

 (alexwlchan.net)
4P by GN⁺ | ★ favorite | 댓글 1개
  • 로컬에 쌓인 문서·스크린샷·북마크·미디어를 나중에 다시 찾기 위해, 작은 컬렉션마다 정적 웹사이트를 붙여 탐색함
  • 각 컬렉션은 디스크의 폴더로 남겨 두고, 루트의 HTML 파일을 브라우저에서 열어 Finder보다 풍부한 메타데이터와 정리 방식을 제공함
  • 웹 서버·빌드 시스템·의존성·JavaScript 프레임워크 없이 손으로 작성하며, 각 사이트는 많아도 수백 줄 코드 수준이라 작은 프로젝트에 맞음
  • 기존 폴더 계층, Finder 태그, “everything bucket” 앱, 직접 만든 도구는 각각 계층 강제·구현 한계·앱 사고방식 적응·유지보수 부담이 있었음
  • 수동 정리는 시간이 들지만 저장할 가치가 있는 파일만 고르게 만들고, HTML의 단순성은 장기 보존에 유리함

로컬 아카이브를 미니 웹사이트로 보기

  • 컬렉션별로 정적 웹사이트를 만들어 로컬 아카이브를 탐색함
    • 스캔한 서류
    • 직접 만든 문서
    • 찍어 둔 스크린샷
    • 저장한 웹페이지 북마크
    • 저장한 영상·오디오 파일
  • 파일 성격에 맞춰 컬렉션마다 다른 화면을 둠
    • 스크린샷 컬렉션은 이미지 그리드로 표시함
    • 북마크는 텍스트 링크 목록으로 보여줌
    • 영상은 썸네일과 텍스트가 섞인 목록으로 정리함
  • 목표는 복잡한 시스템이 아니라 macOS Finder보다 조금 더 나은 파일 탐색 인터페이스를 만드는 것임
    • 페이지에 더 많은 메타데이터를 넣을 수 있음
    • 직접 만든 검색·정리 방식을 사용할 수 있음

구성 방식과 기술 선택

  • 각 컬렉션은 로컬 디스크의 한 폴더이고, 웹사이트는 그 폴더 루트에 있는 하나 이상의 HTML 파일임
  • 사용할 때는 HTML 파일을 웹 브라우저에서 직접 엶
  • 의도적으로 낮은 규모와 낮은 기술 수준을 유지함
    • 웹 서버 없음
    • 빌드 시스템 없음
    • 의존성 없음
    • JavaScript 프레임워크 없음
  • 모든 것을 손으로 작성하지만, 작은 프로젝트에서는 관리 가능함
    • 각 웹사이트는 많아도 수백 줄 코드 수준임
  • 디스크의 파일과 HTML만으로 구성돼 오래 지속될 가능성이 높다고 봄
    • 폴더 파일 구조의 단순성과 이식성을 유지함
    • 그 위에 필요한 기능만 조금 더함

이전 방식들이 오래가지 못한 이유

  • 평범한 파일·폴더 방식은 계층 구조를 강제하고, 모든 파일이 정확히 한 곳에 있어야 함
    • 코드처럼 일부 데이터에는 잘 맞음
    • 미디어 파일에는 만족스러운 계층을 설계하기 어려웠음
    • 어느 폴더에 넣을지 망설이다가 데스크톱이 정리되지 않은 상태가 됨
  • 키워드 태깅은 한 파일에 여러 라벨을 붙이고 여러 방식으로 다시 찾을 수 있어 더 선호함
    • macOS Finder도 태그를 지원하지만, 구현이 충분하지 않아 중요한 용도로 쓰고 싶지 않았음
  • DEVONThink, Evernote, Yojimbo 같은 “everything bucket” 앱도 맞지 않았음
    • 앱의 방식에 맞춰 사고를 바꿔야 하는 느낌이 있었음
  • 직접 만든 파일 정리 도구도 최소 12번 정도 시도했고, 마지막 시도 중 하나가 docstore였음
    • 자신의 사고방식에는 더 잘 맞았지만 유지보수 부담이 생김
    • Python 업그레이드나 macOS 업데이트 때마다 무언가 깨져 코드를 고쳐야 했음

폴더를 미니 웹사이트로 바꾸는 방식

  • 최상위 폴더에 인덱스 역할의 HTML 파일을 두면, 모든 파일을 원하는 메타데이터와 태그로 보여줄 수 있음
  • 이 방식은 폴더 구조를 단순화하고 완벽한 계층을 찾아야 하는 부담을 줄임
    • 파일은 보통 연도별 또는 파일명 첫 글자별로만 묶음
    • 폴더는 새 파일을 추가할 때만 보고, 탐색에는 사용하지 않음
    • 파일을 찾을 때는 항상 웹사이트를 사용함
  • 웹사이트는 키워드 태그로 파일을 여러 방식으로 찾게 하고, 실제 폴더 구조의 세부사항을 감춤
  • HTML은 유지보수가 적고 유연하며 사라질 가능성이 낮은 기술로 선택됨
    • 웹의 기반 기술임
    • 거의 모든 현대 컴퓨터에는 HTML 페이지를 렌더링할 수 있는 브라우저가 있음
    • 2006년에 만든 학교 수업용 첫 웹사이트도 현대 브라우저에서 문제없이 렌더링됨

“작은” 아카이브에 맞는 이유

  • 파일 정리, 메타데이터 작성, 뷰어 제작을 상당 부분 손으로 하기 때문에 큰 컬렉션에는 잘 확장되지 않음
  • 수백 개 항목을 저장하는 데도 적지 않은 시간이 들지만, 이 마찰이 저장할 대상을 고르는 데 도움이 됨
    • 제대로 정리할 가치가 있는지 판단하게 됨
    • 1분도 들여 저장하고 싶지 않은 파일을 다시 볼 가능성이 있는지 묻게 됨
    • 저장하기로 한 파일에는 나중에 찾기 쉽도록 메타데이터를 더 신경 써서 작성하게 됨
  • 이전에는 수천 개의 파일이 크고 모호한 폴더에 쌓였고, 제대로 정리되지 않아 다시 보지 않게 됨
  • 지금은 몇백 개 항목을 담은 작은 웹사이트들이 있고, 항목은 더 신중하게 선택되고 유용하게 설명됨
  • 자동화를 좋아하더라도, 더 수동적인 과정이 주는 제약을 긍정적으로 받아들이고 있음

보존 도구로서의 정적 웹사이트

  • 이 방식의 영감은 Twitter 계정 내보내기에서 왔음
    • Twitter 계정 내보내기는 로컬에서 탐색할 수 있는 미니 웹사이트를 제공함
    • 여러 소셜 미디어 플랫폼도 데이터를 사람이 보기 쉽게 탐색하는 웹사이트 형태로 제공함
  • 정적 웹사이트는 born-digital 아카이브를 다루는 디지털 보존 방식으로도 유용할 수 있음
    • 단순성, 장기성, 낮은 유지보수성은 수십 년이나 수백 년 보존을 목표로 하는 기억 기관에서 더 가치 있음
    • 기본 메모장이나 텍스트 편집기만으로도 기본 HTML 웹사이트를 만들 수 있음
  • Data Lifeboat project에서는 Flickr의 아카이브 일부를 패키징하는 방식으로 더 큰 정적 웹사이트를 만들고 있음
    • 로컬 아카이브는 보통 목록 뷰에 가깝지만, Data Lifeboat 안의 웹사이트는 더 많은 페이지와 기능을 가짐
  • Ed Summers의 Historypin 보존을 위한 정적 사이트 관련 글도 같은 방향의 사례임

점진적 이전과 HTML의 개인적 용도

  • 이미 디스크 전반에 흩어진 파일이 많기 때문에 모든 것을 한 번에 옮기기는 작업량이 큼
  • 새 파일은 정적 웹사이트에 저장하고, 오래된 파일은 찾을 때마다 기존 저장 위치에서 꺼내 적절한 정적 사이트 폴더로 옮김
  • 초기 사이트 구조를 만든 뒤에는 작동을 유지하기 위한 유지보수 부담이 거의 없었음
  • 웹사이트를 처음 만들어 보고 싶은 사람에게는 Blake Watson의 HTML for People이 추천됨
    • “원한다면 누구나 HTML로 웹사이트를 만들 수 있어야 한다”는 철학을 담고 있음
  • HTML은 오랫동안 다른 사람이 보는 웹사이트를 게시하는 도구로 생각했지만, 로컬 개인 아카이브에도 사용할 수 있음
  • 2025년 2월 19일 업데이트로, 코드 세부사항을 설명하는 후속 글 How I create static websites for tiny archives가 추가됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 클립보드의 이미지를 복사해 HTML 파일에 저장해서 단일 파일 갤러리로 씀
    https://gist.github.com/egeozcan/b27e11a7e776972d18603222fa5...
    라이브 예시: https://gistpreview.github.io/?b27e11a7e776972d18603222fa523...
    파일 선택기로 고르는 것도 동작하지만 드래그는 보통 잘 안 됨. 제대로 동작하면 이미지는 blob으로 문서 안에 인라인 삽입됨
    이미지를 추가한 뒤 페이지를 그대로 저장하면, 즉 file->save를 누르면 blob도 함께 저장됨. 저장 전에 일부를 빼고 싶으면, 예를 들어 이미지를 지우고 싶으면 요소 검사를 열어 제거한 뒤 페이지를 저장하면 됨
    이 파일은 서버에 올려도 되고 컴퓨터나 모바일에서 더블클릭해 열어도 됨

  • 댓글에서 Markdown을 많이 이야기하는데, 거기에 한 표 더함. 일반 텍스트가 최고임. 내 데이터 수집과 보관을 많이 생각하는데, 일반 텍스트는 그 핵심이고 미래 호환성이 매우 좋음
    WordPerfect 이후로는 더 결정적이고 가볍게 서식이 들어가며, 서식 문자를 직접 볼 수 있는 문서를 선호해 왔음. Markdown은 훌륭하고, 사실상 HTML을 위한 도메인 특화 언어에 가까움
    일반 텍스트의 핵심은 도구임. HN에 나온 적은 있지만 여기서는 아직 못 본 Markdown 도구 몇 가지가 있음
    https://addons.mozilla.org/en-US/firefox/addon/markdown-view... - 브라우저에서 Markdown을 보기 좋게 렌더링함
    https://casual-effects.com/markdeep/ - 기능이 많은 독립형 웹 친화 Markdown 포매터

    • Markdown 파일을 직접 호스팅할 수 있는 작은 JS를 만들었음. 사전 변환이나 플러그인 없이 브라우저에서 HTML로 렌더링됨
      이런 로컬 웹사이트에서 쓰면 그냥 일반 Markdown만 작성하는 편의성을 얻을 수 있음
      => https://www.tducret.com/pure-markdown/
      소스 코드: https://github.com/tducret/pure-markdown
    • GitHub로 내 Markdown 파일을 호스팅함. 관련 내용을 쓴 글에 조금 더 정리해 둠. 비슷한 생각을 담은 글이 실제로 4~5개쯤 있고, 더 단순하게 만드는 방법을 찾는 중임
      기술적이지 않은 사용자도 쓸 수 있게 하고 싶지만 아직 거기까지는 못 감
      https://joeldare.com/using-neat-css-on-github-pages
    • 나도 점점 더 Plain Text를 많이 쓰고 있음. 내 아카이브에 대한 생각을 https://brajeshwar.com/2022/plain-text/에 적어 둠
      Google/Search에서 일반 텍스트로 노트하는 방법을 찾는 사람들이 꽤 많이 들어오고, 그 단순한 글이 도움이 된 듯함

  • 콘텐츠를 Markdown과 관련 이미지로 변환한 뒤 Obsidian vault에 저장함. 동기화는 Syncthing으로 직접 처리함. 노트북과 휴대폰에서 꽤 효과적인 제텔카스텐식 기억 보조 장치가 되어 감
    Google/Facebook Takeout도 가져와 결과를 다시 포맷하고, 사람에게 보이는 모든 서신을 거기에 저장하고 색인함. 텍스트는 저렴해서 이미지는 대부분 피함. 그래도 아직 200MB 미만이고, 좋은 UI로 즉시 검색 가능하며 Markdown 파일 묶음이라 쉽게 옮길 수 있음

    • “제텔카스텐식 기억 보조 장치”라는 세 단어를 아무 맥락 없이 던지고 가는 건가?
    • 휴대폰에서 Obsidian 동기화는 뭘로 함? 그것도 Syncthing인가?

  • 개인적으로는 비슷한 방식으로 Obsidian에 의존함. 나중에 공유할 수도 있는 FB 게시물처럼 보관하고 싶은 것이 있으면 원본 링크와 함께 저장함. 외부 서비스는 언제든 사라질 수 있으니, 로컬 데이터는 우리가 소유하고 검색하기 쉽다는 두 가지 장점이 있음
    Kindle 하이라이트를 Markdown 파일로 변환하는 스크립트도 만들었음. 관심 있는 사람이 있으면 조금 다듬어서 공유할 수 있음
    공개용 콘텐츠는 정적 사이트 생성기 생태계가 계속 좋아지고 있음. GitHub 기본값이라 Jekyll로 시작했고, Gridsome을 거쳐 결국 Nuxt 3 Content에 정착했는데 지금은 그게 나에게 최적점처럼 느껴짐. 지금 시작한다면 Astro를 골랐을 수도 있음
    어쨌든 진입 장벽은 그 어느 때보다 낮음. GitHub에 무료로 사이트를 호스팅할 수 있고, 커스텀 스타일이 필요하면 AI 모델이 CSS 작업에 엄청 도움이 됨
    Markdown은 텍스트 서식을 위한 JavaScript 같음. 이상한 부분이 있어도 결국 잘 동작함

    • Android 앱 [1]을 포크해서 글을 앱으로 공유하면 Markdown으로 변환한 뒤 Obsidian으로 보내게 만들었음. Firefox 확장도 쓰는데, Obsidian 확장인 Advanced URI를 이용해 글의 Markdown 버전을 앞부분 메타데이터까지 포함해서 Obsidian으로 보냄[2]
      [1] https://github.com/IAmStoxe/obsidian-markdownr
      [2] https://addons.mozilla.org/en-US/firefox/addon/markdownload/ - Chrome 확장도 있음
    • Kindle 스크립트에 관심 있음. FB 게시물을 저장할 때는 콘텐츠를 그냥 복사해 붙여 넣고 Markdown으로 변환한 뒤 Obsidian에 넣는 건지 궁금함. 실제 흐름을 더 듣고 싶음

  • 15년 전부터 비슷하게 해 왔음. 이미지를 내장한 휴대용 HTML, mp3 등을 만들어서 보기 위해 별도 소프트웨어가 필요 없게 함. 요즘은 클라우드나 휴대폰에 넣고 다니면 어떤 기기와 운영체제에서도 브라우저만 있으면 됨
    HTML에 mp3를 내장하면 크기는 커질 수 있지만, 별도 음악 재생기나 앱 없이 브라우저만 있으면 됨
    요즘은 HTML과 함께 수동 내장 대신 MHTML 형식으로 보관하려고 함
    간단한 HTTP 서버를 띄우고 아카이브를 둘러보면 됨
    이미지에는 이런 식으로 함: 모든 이미지를 폴더에 저장 → localhost 서버 열기 → 브라우저에서 폴더 열기 → JavaScript로 링크를 src=link인 태그로 변환 → 브라우저가 모든 이미지를 가져와 표시하면 “다른 이름으로 저장”해서 내장된 MHTML 아카이브를 얻음
    또는 간단한 Bash 스크립트로 img 태그와 폴더 링크가 있는 HTML을 만들 수도 있고, MHTML을 수동 템플릿으로 만들 수도 있음
    하지만 브라우저가 힘든 일을 하게 두면 되지 굳이 수동으로 할 필요가 없음
    또한 Base64 내장보다 MHTML에 바이너리 이미지를 직접 내장하는 편이 훨씬 효율적이고 메모리도 덜 먹음. 예를 들어 이미지 15개 기준 MHTML 바이너리 인코딩은 4MB, MHTML Base64 인코딩은 5MB였음
    또 다른 방법으로는 아무 폴더에서 python -m http.server를 실행하거나, Linux에서는 tree -H http://localhost:8000로 재귀 깊이를 설정함
    그런 다음 서버의 폴더 링크나 tree가 만든 HTML을 브라우저에서 열고, 명령줄에서 wget -rkpN -e robots=off http://localhost:8000를 실행하면 탐색 가능한 index.html이 있는 폴더를 다시 만들어 줌. 이후에는 보기 위해 서버가 필요 없음
    Google, Twitter, YouTube 내보내기와 같은 방식임

  • 비슷한 생각을 하다가 작은 프레임워크를 직접 만들었음: https://www.smallweb.run
    기존 직접 구성과 비교해 추가되는 핵심 기능은 하위 폴더를 하위 도메인에 매핑하는 것임. 동적 웹사이트도 가능하지만, 그쪽에는 관심 없어 보임
    예: ~/smallweb/example => https://example.localhost
    관심 있으면 작은 Discord 커뮤니티도 있음: https://discord.smallweb.run

    • 그냥 CGI/PHP를 다시 만든 것처럼 보임

  • 개인적으로 업무 중 노트 작성에는 VimWiki를 선호함. 아이디어, 짧은 문서, 웹에서 찾은 코드 조각을 섞어 두는 장소로 씀
    주로 글, 튜토리얼, 유용한 팁을 저장하고 싶어서 웹사이트 전체를 보관하는 편임. 이 작업에는 SingleFile[1]이 제일 마음에 듦
    SingleFile로는 이미지를 내장한 웹사이트를 저장할 수 있고, 주석을 추가하거나 거슬리는 광고 등을 잘라낼 수도 있음. 방해 요소 없는 웹사이트 복사본도 지원함. 꼭 살펴보길 추천함
    [1]https://github.com/gildas-lormeau/SingleFile

    • SingleFile은 훌륭함. uBlock, Tree Style Tab과 함께 내 표준 브라우저 설치 목록에 들어감

  • 이런 글은 항상 흥미로움. 저기술이고 유지 가능한 방향은 좋지만, 예전 작업을 찾아보는 데 의미 있는 시간을 쓴 적은 한 번도 없음
    사진은 예외지만, 날짜순으로 정렬된 개인 사진 타임라인을 그냥 스크롤하는 것으로 충분했음. 어릴 때는 이런 것에 시간을 더 썼지만 어느 순간 실제로는 전혀 들여다보지 않는다는 걸 깨달음
    사람들이 몇 년 전 작업을 자주 다시 보는 이유가 무엇인지 궁금함

    • 스크린샷을 다시 보는 일은 드물지만, 볼 때마다 영감을 얻고 갑자기 프로젝트를 시작한 적도 있음. 하루에 하나씩 무작위로 꺼내 보여 주는 아카이브가 필요할 듯함
    • 되돌아본 삶은 두 번 산 삶임

  • 적어도 내 경우에는 컬렉션에 항목을 추가할 때마다 HTML 파일을 손으로 편집해야 한다면, 아무리 빠르고 단순해도 장기적으로는 절대 유지하지 못할 것 같음
    아주 단순한 DIY 정적 사이트 생성기를 쓰기에 이상적인 사례로 보임. Bash나 Perl로 작성하면 영원히 미래 호환적일 것임

  • 정적 웹사이트를 이런 식으로 쓰는 건 새롭지 않음. 영감은 Twitter 계정 내보내기에서 왔는데, 로컬에서 탐색할 수 있는 작은 웹사이트를 제공함. 다른 여러 소셜 미디어 플랫폼도 사람이 읽기 좋게 데이터를 탐색할 수 있는 웹사이트를 제공하는 걸 봤음
    어디선가 Telegram 내보내기도 이런 방식이라고 읽었음. 원본 파일들이 디렉터리로 어느 정도 정리되어 있고, 그 자체로도 탐색 가능하며, 더 편하게 둘러볼 수 있는 작은 로컬 정적 웹사이트가 함께 온다고 함
    마지막으로 써 본 대량 내보내기인 Google Takeout과는 너무 다름. Google Takeout은 사용자가 보기에는 의미 없는 이름 체계의 원본 파일과 알 수 없는 XML을 멍청하게 덤프해 줌
    지금도 클라우드 쪽에서 삭제하기 전에 요청한 데이터를 전부 받았는지 확신이 안 듦

    • Facebook도 몇 년 전 떠날 때는 이렇게 했음. 데이터와 사진을 크게 덤프해 주고, 더 잘 탐색할 수 있도록 HTML 파일을 함께 제공했음
답변달기