웹은 기억을 잃고 있다: 디지털 부패와의 싸움
웹은 매년 수백만 페이지를 잃습니다. 링크 로트가 역사 기록을 위협하는 방식과 개발자가 디지털 부패에 맞설 방법을 알아봅니다.
Elena Vasquez
2014년, 기후 연구원 마리아 첸 박사는 북극 해빙 감소에 관한 획기적인 데이터셋을 공개했습니다. 대학 서버에 올려 두고, 동료 심사를 거친 논문 세 편에 링크를 걸고, 학술 메일링 리스트 십여 곳에 공유했죠. 그런데 2019년 대학이 웹 인프라를 옮기면서 URL이 깨졌습니다. 데이터셋은 사라졌고, 공개 아카이브에도 백업이 남아 있지 않았습니다. 5년간의 현장 연구가 404 오류 한 줄로 줄어든 셈입니다.
첸의 이야기는 특별한 사례가 아닙니다. 오히려 흔한 일이죠. 웹은 무서운 속도로 기억을 잃고 있지만, 이미 사라진 무언가가 필요해지기 전까지는 대부분 눈치채지 못합니다.
링크 로트와 웹 역사의 조용한 침식
연구자들은 이를 링크 로트라고 부릅니다. URL이 서서히, 그러나 끈질기게 동작을 멈추는 현상이죠. 퓨 리서치 센터의 한 연구에 따르면 2013년에 만들어진 웹페이지의 약 38퍼센트가 10년 안에 접근할 수 없게 되었습니다. 반올림 오차 수준이 아닙니다. 단 한 해에 기록된 웹 지식의 3분의 1이 넘게 통째로 사라진 것입니다.
원인은 평범합니다. 회사가 합병되고 브랜드를 바꿉니다. 호스팅 요금이 밀리고, 콘텐츠 관리 시스템이 교체됩니다. 선거 이후 정부 웹사이트가 개편되기도 하고, 블로그 운영자가 세상을 떠났는데 아무도 도메인을 갱신하지 않기도 하죠. 하나하나는 대단한 사건처럼 보이지 않습니다. 하지만 이런 일들이 쌓입니다. 해마다 웹은 죽은 피부처럼 자기 과거를 떨쳐내고 있습니다.
결과도 추상적이지 않습니다. 법원이 판결문에서 인용한 URL이 몇 달 뒤 죽은 링크가 된 적이 있습니다. 기자들은 취재 원본 자료를 잃었습니다. 플랫폼이 방향을 바꾸거나 문을 닫는 순간, 대화와 내부 농담, 창작물, 공동으로 쌓은 지식으로 이루어진 온라인 커뮤니티 전체가 하룻밤 사이에 지워지기도 했습니다. 바인, 구글 플러스, 원조 지오시티즈를 기억하시나요? 서비스가 종료될 때마다 다시는 온전히 복원할 수 없는 문화사의 한 조각이 사라졌습니다.
웹 아카이빙은 왜 쉬워지기는커녕 더 어려워지고 있는가
이쯤 되면 상황이 나아지고 있으리라 생각할 법합니다. 저장 공간은 저렴하고, 대역폭은 넉넉하죠. 성숙한 아카이빙 도구도 있고, 보존만을 위해 존재하는 기관도 많습니다. 그런데 왜 문제는 점점 심각해지고 있을까요?
두 가지 힘이 동시에 작용하고 있습니다. 첫 번째는 기술적인 문제입니다. 현대 웹은 초기 인터넷의 정적인 HTML 페이지보다 아카이빙이 훨씬 어렵습니다. 싱글 페이지 애플리케이션은 콘텐츠를 전부 JavaScript로 렌더링하고, API 기반 사이트에는 캡처할 만한 고정 URL이 없습니다. 페이월, 인증 게이트, 사용자 맞춤 콘텐츠 피드 때문에 방문자마다 다르게 보이는 페이지도 많은데, 여기에는 아카이빙 크롤러도 포함됩니다.
두 번째는 정치적인 문제입니다. 대형 언어 모델이 폭발적으로 늘어나면서 웹 크롤링에 대한 반발이 커졌습니다. 자신의 콘텐츠가 허락 없이 AI 학습에 쓰이는 것을 걱정한 퍼블리셔와 사이트 운영자들은 공격적인 차단 조치를 도입했습니다. robots.txt를 고치고, 봇 탐지를 붙이고, 데이터 수집과 연관된 IP 대역 전체를 막고 있습니다.
문제는 이런 차단 조치가 상업용 AI 크롤러와 아카이빙 크롤러를 거의 구분하지 않는다는 점입니다. 인터넷 아카이브의 웨이백 머신은 robots.txt를 존중합니다. 그러니 사이트가 모든 봇을 일괄 차단하면 아카이빙 크롤러도 함께 쫓겨나죠. 운영자는 AI 학습을 막고 싶었을 뿐이지만, 실제로 일어나는 일은 자기 콘텐츠의 역사 기록이 단 하나도 남지 않게 되는 것입니다.
AI 스크래핑을 막겠다고 아카이빙 크롤러를 차단하는 것은, 누군가 책을 복사하지 못하게 도서관을 불태우는 것과 같습니다. 의도는 이해할 수 있습니다. 하지만 역사 기록이 입는 피해는 엄청납니다.
인터넷 아카이브: 압박 속에서도 여전히 필수적인 존재
인터넷 아카이브는 웹에서 공공 도서관에 가장 가까운 존재입니다. 웨이백 머신은 1996년 이후 8,000억 개가 넘는 웹페이지를 저장해 왔습니다. 숫자만 보면 놀랍지만, 온라인에 올라온 전체 콘텐츠에 비하면 여전히 일부에 불과합니다.
이 단체는 심각한 역풍을 맞아 왔습니다. 오픈 라이브러리 대출 프로그램을 둘러싼 법정 다툼으로 자원과 관심이 크게 소모되었습니다. 그 소송을 지켜본 다른 기관들이 무엇을 아카이빙할지 더 조심스러워지면서, 디지털 보존 작업 전반에 실질적인 위축 효과가 나타났습니다.
하지만 가장 큰 문제는 결국 규모입니다. 웹은 어떤 단일 기관이 따라잡을 수 있는 속도보다 빠르게 자랍니다. 게다가 동적이고 JavaScript 의존도가 높은 애플리케이션이 늘면서, 전통적인 크롤링이 사용자가 실제로 보는 것을 담아내는 비중은 점점 줄고 있습니다. React 앱의 원시 HTML을 내려받는 크롤러는 빈 div와 JavaScript 번들만 얻습니다. 기사도, 이미지도, 인터랙티브 요소도 없습니다.
- 의미 있는 스냅샷을 얻으려면 클라이언트 측 렌더링 앱은 헤드리스 브라우저가 필요하다
- API 기반 콘텐츠는 대개 고정되고 크롤링 가능한 URL이 없다
- 영상, 팟캐스트, 인터랙티브 시각화 같은 멀티미디어 콘텐츠는 전문적인 보존 방식이 필요하다
- 웹 콘텐츠의 증가 속도는 어떤 단일 기관의 크롤링 능력을 훨씬 앞지른다
- 법적 불확실성 때문에 기관들은 공격적으로 아카이빙하기를 꺼린다
그렇다고 중앙 집중형 아카이브를 포기할 이유는 되지 않습니다. 그저 그것에만 의존하는 것을 멈춰야 한다는 신호일 뿐입니다.
모든 개발자가 알아야 할 셀프 호스팅 웹 아카이빙 도구
좋은 소식은 웹을 아카이빙하는 데 기관이 될 필요는 없다는 것입니다. 오픈소스 도구 생태계가 자라면서 개인이나 소규모 팀도 자체 아카이빙 인프라를 현실적으로 운영할 수 있게 되었습니다. 이 중 일부는 놀랄 만큼 강력합니다.
개인 용도로 가장 돋보이는 것은 ArchiveBox입니다. 셀프 호스팅 도구로, URL을 받아 HTML, PDF, 스크린샷, WARC 등 여러 형식으로 저장합니다. 브라우저 북마크, RSS 피드, 평문 URL 목록을 넣으면 탐색 가능한 로컬 아카이브를 만들어 줍니다. 설치도 몇 분이면 끝납니다:
# Set up ArchiveBox with Docker
docker pull archivebox/archivebox
mkdir -p ~/web-archive && cd ~/web-archive
docker run -v $PWD:/data -it archivebox/archivebox init --setup
# Archive some URLs
docker run -v $PWD:/data -it archivebox/archivebox add \
'https://example.com/important-report' \
'https://example.org/research-dataset'
# Launch the web UI to browse your archive
docker run -v $PWD:/data -p 8000:8000 archivebox/archivebox server 0.0.0.0:8000JavaScript 의존도가 높은 사이트를 캡처할 때는 Webrecorder가 다른 접근을 택합니다. 크롤링하는 대신 실제 브라우저 세션을 녹화합니다. 모든 네트워크 요청, 동적으로 로드되는 요소, 사용자 상호작용을 전부 기록하죠. 결과물은 WARC나 WACZ 형식으로 저장되고, ReplayWeb.page로 브라우저에서 다시 재생할 수 있습니다. 건물을 사진으로 찍는 것과 3D 워크스루를 만드는 것의 차이라고 보면 됩니다.
같은 Webrecorder 프로젝트의 Browsertrix는 이 방식을 대규모로 확장합니다. 실제 브라우저 인스턴스를 사용해 페이지를 렌더링하고 캡처하는 클라우드 네이티브 크롤링 시스템입니다. 대학, 도서관, 정부 기관이 이를 활용해 기관 단위 아카이빙 프로그램을 운영합니다. JavaScript 렌더링까지 포함해 수천 페이지를 보존해야 한다면 Browsertrix가 답입니다.
개발 워크플로에 보존을 녹여 넣는 법
의미 있는 차이를 만들기 위해 전체 아카이빙 시스템을 직접 돌릴 필요는 없습니다. 웹사이트를 만들고 배포하는 방식의 작은 결정들이 콘텐츠가 보존될 수 있는지에 큰 영향을 미칩니다. 실제로 중요한 것들을 정리해 보겠습니다.
첫째, 아카이빙 가능성을 고려해 설계하세요. 안정적이고 사람이 읽을 수 있는 URL을 쓰세요. URL 구조를 데이터베이스 ID나 세션 토큰에 묶지 마세요. 핵심 콘텐츠는 페이지 로드 후 클라이언트 측 JavaScript로 불러오는 것이 아니라 최초 HTML 응답에 반드시 포함되어야 합니다. 싱글 페이지 앱을 만든다면 대체 수단으로 서버 사이드 렌더링이나 정적 생성을 제공하세요. 이런 것들은 아카이빙에만 좋은 관행이 아닙니다. SEO, 접근성, 성능에도 좋은 관행입니다.
둘째, robots.txt는 정밀하게 다루세요. AI 학습용 크롤러를 막고 싶다면 이름을 지정해서 차단하세요. 사이트를 방문하는 모든 봇을 한꺼번에 덮어씌우지 마세요.
# robots.txt — block AI crawlers, welcome archival bots
# Explicitly allow archival crawlers
User-agent: ia_archiver
Allow: /
User-agent: archive.org_bot
Allow: /
# Block specific AI training crawlers
User-agent: GPTBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: anthropic-ai
Disallow: /
User-agent: ClaudeBot
Disallow: /
# Default: allow everything else
User-agent: *
Allow: /완벽한 시스템은 아닙니다. 사용자 에이전트 문자열은 위조될 수 있으니까요. 하지만 원하지 않는 학습은 막으면서 정당한 보존의 문은 열어 두는 선의의 노력이라고 할 수 있습니다.
셋째, 아카이브 제출을 자동화하세요. 무언가를 발행할 때마다 웨이백 머신에 보내세요. 몇 줄의 코드면 충분하고, 어떤 CI/CD 파이프라인이나 발행 후 훅에든 연결할 수 있습니다:
import requests
import time
def archive_url(url: str, retries: int = 3) -> str:
"""Submit a URL to the Wayback Machine's Save Page Now endpoint."""
save_url = f"https://web.archive.org/save/{url}"
for attempt in range(retries):
try:
resp = requests.get(save_url, timeout=30)
if resp.status_code == 200:
location = resp.headers.get("Content-Location", resp.url)
return f"Archived: https://web.archive.org{location}"
except requests.RequestException:
if attempt < retries - 1:
time.sleep(2 ** attempt)
return f"Failed to archive {url} after {retries} attempts"
# Wire this into your publish script
new_post = "https://yourblog.com/posts/new-article"
print(archive_url(new_post))재시도 로직이 중요합니다. 웨이백 머신의 저장 엔드포인트는 자주 과부하가 걸리고, 일시적인 실패도 흔하기 때문입니다. 약간의 회복력만 더해도 효과가 큽니다.
WARC 이해하기: 웹 아카이브 뒤에 있는 파일 형식
웹 아카이브를 다루려면 WARC를 이해해야 합니다. 인터넷 아카이브, Webrecorder, 그리고 본격적인 아카이빙 도구 대부분이 사용하는 ISO 표준 파일 형식입니다. WARC 파일은 페이지를 불러올 때 오간 모든 HTTP 요청과 응답을 완전히 기록한 것이라고 생각하면 됩니다. HTML, 스타일시트, 스크립트, 이미지, API 호출까지 전부요. 모든 것을 담습니다.
이 완전성이 재생을 가능하게 합니다. WARC 파일은 원시 HTML만 저장하지 않습니다. 캡처 시점의 페이지를 그대로 재구성하는 데 필요한 전체 맥락을 저장합니다. 프로그래밍 방식으로 읽는 방법은 다음과 같습니다:
from warcio.archiveiterator import ArchiveIterator
def inspect_warc(filepath: str):
"""List all HTTP responses captured in a WARC file."""
with open(filepath, "rb") as stream:
for record in ArchiveIterator(stream):
if record.rec_type == "response":
url = record.rec_headers.get_header("WARC-Target-URI")
status = record.http_headers.get_statuscode()
content_type = record.http_headers.get_header("Content-Type")
print(f"[{status}] {url} ({content_type})")
inspect_warc("my-archive.warc.gz")새로운 WACZ 형식은 WARC를 기반으로 하며, ZIP 컨테이너 안에 인덱스와 메타데이터 계층을 추가합니다. 실용적인 장점이 큽니다. WACZ 파일은 서버 인프라 없이 ReplayWeb.page를 통해 브라우저에서 바로 열 수 있습니다. 누군가에게 WACZ 파일을 이메일로 보내면, 그 사람은 곧바로 아카이브된 사이트를 둘러볼 수 있습니다. 기술적으로만 가능한 보존이 아니라 실제로 쓸모 있게 만드는, 마찰이 적은 접근 방식입니다.
커뮤니티 아카이빙과 자원봉사자들의 안전망
가장 극적인 보존 작업 중 일부는 위기 상황에서 이루어집니다. 플랫폼이 서비스 종료를 발표하면 ArchiveTeam이라는 자원봉사 단체가 움직입니다. 지오시티즈, 바인, 구글 플러스, 그리고 수십 개의 소규모 서비스에서 콘텐츠를 구해 냈습니다. 그들의 방식은 단순합니다. 서버가 꺼지기 전에 죽어가는 플랫폼에 아카이빙 요청을 쏟아붓고, 모든 것을 WARC 형식으로 저장한 뒤, 공개 접근을 위해 인터넷 아카이브에 업로드합니다.
누구나 참여할 수 있습니다. ArchiveTeam의 Warrior는 자신의 하드웨어에서 실행하는 가상 어플라이언스입니다. 조정 서버에 연결해 아카이빙 작업을 받아 오고, 진행 중인 구조 작업에 내 대역폭과 연산 자원을 보탭니다. 가장 풀뿌리에 가까운 형태의 분산 아카이빙이라 할 만합니다.
하지만 긴급 구조는 최후의 수단입니다. 진짜 목표는 보존을 일상화하는 것입니다. 분야별 커뮤니티가 점점 나서고 있습니다. 오픈소스 프로젝트는 메일링 리스트와 이슈 트래커를 아카이빙하고, 문화유산 단체는 소수 언어 자료를 보존하며, 언론 단체는 탐사 보도 기록을 보관합니다. 도구는 이미 있습니다. 더 어려운 부분은 이런 노력을 해마다 계속 이어 갈 인적 조율과 자금을 확보하는 일입니다.
실무용 디지털 보존 툴킷
여기까지 읽고 직접 실천해 보고 싶다면, 시작용 도구 목록을 준비했습니다. 모든 규모에서 웹 아카이빙에 쓸 수 있는 가장 성숙하고 잘 관리되는 도구들입니다.
- ArchiveBox — 셀프 호스팅 개인 아카이빙. HTML, PDF, WARC, 스크린샷 형식으로 저장합니다. 나만의 연구 자료와 참고 자료를 보존하기에 딱 좋습니다.
- Browsertrix — 브라우저 기반의 기관 규모 크롤링. 실제 브라우저 인스턴스로 JavaScript를 완전히 렌더링합니다.
- Webrecorder — 브라우저 세션을 녹화해 상호작용까지 살리는 고충실도 캡처. WARC/WACZ 파일로 출력합니다.
- ReplayWeb.page — WARC/WACZ 파일을 브라우저에서 바로 재생합니다. 서버가 필요 없습니다.
- SingleFile — 웹 페이지 전체를 하나의 독립적인 HTML 파일로 저장하는 브라우저 확장 프로그램. 아주 간단합니다.
- warcio — WARC 파일을 프로그래밍 방식으로 읽고, 쓰고, 처리하는 Python 라이브러리.
- Heritrix — 인터넷 아카이브의 오픈소스 크롤러. 산업 수준의 도구지만 학습 곡선이 가파릅니다.
- ArchiveTeam Warrior — 분산 자원봉사 아카이빙 프로젝트에 참여하기 위한 가상 어플라이언스.
- Wayback Machine APIs — 아카이브 페이지를 프로그래밍 방식으로 제출하고 조회하는 API.
- Conifer — 직접 호스팅하고 싶지 않은 개인과 소규모 팀을 위한 관리형 웹 아카이빙 서비스.
웹은 저절로 보존되지 않습니다
인터넷은 절대 잊지 않는다는 말이 끈질기게 떠돕니다. 하지만 사실 인터넷은 끊임없이 잊습니다. 웹은 도서관보다 강에 가깝습니다. 콘텐츠는 그 안을 흘러가고, 누군가 의도적으로 스냅샷을 찍지 않는 한 원천이 마르는 순간 사라집니다.
여기서 개발자는 이례적으로 큰 영향력을 가집니다. robots.txt를 작성하는 것도 우리고, URL 체계를 설계하는 것도 우리입니다. 서버 렌더링을 할지 클라이언트 렌더링을 할지 고르는 것도 우리죠. 몇 줄만 더하면 새 페이지를 모두 공개 아카이브에 제출할 수 있는 배포 파이프라인을 만드는 것도 우리입니다. 영웅적인 행동이 아닙니다. 웹의 역사가 살아남을지를 결정하는 작고 기술적인 선택들입니다.
첸 박사의 데이터셋은 여전히 사라진 상태입니다. URL이 깨지기 전에 그것을 캡처한 아카이브는 없었습니다. 하지만 매일 누군가는 중요한 무언가를 발행합니다. 탐사 보도, 과학 데이터셋, 몇 년씩 인용될 커뮤니티 포럼 글 같은 것들이요. 문제는 그 콘텐츠가 언젠가 사라질지가 아닙니다. 사라질 것입니다. 문제는 누군가 먼저 사본을 저장해 두었느냐입니다.
