무슨 일이 있었냐면
미국 시사 매체 마더존스(Mother Jones)가 미국 환경보호청(EPA)이 자기 웹 아카이브를 조용히 정리하고 있다고 보도했어요. EPA는 수십 년 동안 정책 문서, 연구 보고서, 오염 사고 기록을 웹에 공개해왔어요. 정권이 바뀌거나 사이트를 개편할 때는 예전 페이지를 별도 아카이브로 옮겨 보관해왔고요. 그런데 이 아카이브가 점점 사라지고 있다는 거예요.
보도에는 노스캐롤라이나 해병대 기지 캠프 르준(Camp Lejeune)의 식수 오염 관련 자료, 오바마 정부 때의 청정전력계획(Clean Power Plan) 관련 자료 같은 것들이 나와요. 둘 다 끝난 옛날 얘기가 아니에요. 캠프 르준은 1950년대부터 80년대까지 기지 식수가 산업용 용제로 오염돼 군인과 가족들이 피해를 입은 사건이에요. 2022년에 피해자들이 소송을 낼 수 있게 하는 법이 통과돼서 지금도 관련 소송이 진행 중이고요. 청정전력계획은 발전소 탄소 배출 규제를 둘러싼 법적 논쟁의 핵심 사례예요. 누군가에게는 지금 당장 필요한 증거 자료라는 뜻이죠.
“정부 사이트에서 옛날 페이지 좀 지우는 게 그렇게 큰일이야?” 싶을 수 있어요. 그런데 개발자 관점에서 보면 생각보다 훨씬 무거운 문제예요.
웹 아카이브는 ‘옛날 페이지 모음’ 그 이상이에요
논문이나 기사, 판결문에 출처를 달 때 제일 많이 쓰는 게 뭘까요? 바로 URL이에요. 그런데 URL은 주소 주인이 계속 유지해줄 때만 의미가 있어요. 페이지가 지워지면 그걸 인용한 문서들이 한꺼번에 ‘죽은 링크’를 품게 되는데, 이걸 링크 부식(link rot)이라고 불러요. 학술 논문이나 판결문에 인용된 링크 중 상당수가 몇 년 안에 깨진다는 연구도 꾸준히 나와요.
정부 기관의 웹 아카이브는 이 문제에 대한 ‘공식 보증서’ 역할을 해요. “그 시점에 정부가 실제로 이렇게 발표했다”는 걸 기관이 직접 증명해주는 거거든요. 제3자가 만든 사본은 “조작된 거 아니냐”는 반박을 받을 수 있지만, 기관 공식 아카이브는 그런 논란에서 훨씬 자유로워요. EPA가 2017년, 2021년 정권 교체 때 웹사이트 전체 스냅샷을 만들어 공개해온 이유도 여기에 있어요.
다른 곳에 백업이 있지 않나요?
있긴 있어요. 대표적으로 인터넷 아카이브의 웨이백 머신(Wayback Machine)이 있고, 2008년부터 정권 교체 때마다 미국 연방 사이트를 통째로 수집해온 End of Term 웹 아카이브 프로젝트도 있어요. 2016년 말에는 연구자들이 EDGI(환경 데이터 거버넌스 이니셔티브)라는 단체를 만들어 EPA 같은 기관의 웹사이트 변경을 추적하기 시작했어요. 2025년 초 연방 사이트에서 데이터가 대거 내려갔을 때는 대학 도서관과 시민 개발자들이 공공 데이터셋을 긴급 백업하기도 했죠.
그런데 외부 백업에는 분명한 한계가 있어요.
- 크롤러가 못 가는 곳이 많아요. 웹 크롤러는 링크를 따라가며 페이지를 모으는데, 검색창에 뭘 입력해야 나오는 문서, 자바스크립트로 그리는 화면, API로만 제공하는 데이터셋은 잘 못 가져와요. 정작 중요한 원자료일수록 이런 곳에 숨어 있는 경우가 많고요.
- 한 곳에 몰려 있으면 위험해요. 인터넷 아카이브는 2024년에 대규모 해킹으로 서비스가 며칠간 멈췄고, 굵직한 저작권 소송에도 시달려왔어요. 비영리 단체 하나가 웹 기록을 사실상 혼자 짊어지고 있어서, 거기가 흔들리면 기록도 같이 흔들려요.
- 증거로서 힘이 약해요. 공식 출처가 사라지면 남은 사본이 믿을 만한지를 두고 다툼이 생길 수 있어요.
한국 개발자에게 주는 시사점
이건 미국만의 이야기가 아니에요. 한국도 국립중앙도서관이 2004년부터 OASIS라는 웹 아카이빙 사업을 해오고 있고, 대통령기록관은 정권이 바뀔 때마다 대통령 홈페이지를 기록으로 보존해요. 이런 제도가 있다는 걸 알아두면 출처를 찾을 때 꽤 쓸모 있어요.
실무에서는 이런 걸 챙겨볼 만해요.
1. 공공 데이터에 기대는 서비스라면 원본을 따로 보관하세요. 공공데이터포털 API나 정부 사이트 크롤링으로 서비스를 만들었다면, 원본 API가 어느 날 사라질 수 있다고 보고 설계하는 게 좋아요. 받아온 데이터를 날짜별 스냅샷으로 저장하고 해시값(파일 내용으로 만드는 고유 지문 같은 값)도 함께 남겨두세요. 나중에 “이 데이터는 그날 이 상태였다”는 걸 증명하기가 훨씬 쉬워져요.
2. 직접 아카이빙하는 법을 알아두세요. wget --mirror --warc-file=backup 같은 명령으로 사이트를 국제 표준 아카이브 포맷인 WARC 파일로 저장할 수 있어요. 자바스크립트가 많은 사이트라면 실제 브라우저로 페이지를 기록하는 Webrecorder 계열 도구(ArchiveWeb.page, Browsertrix)가 더 잘 맞고요. 중요한 레퍼런스를 웨이백 머신의 ‘Save Page Now’로 그때그때 저장해두는 습관도 좋아요.
3. 우리 서비스의 URL도 함부로 바꾸지 마세요. 팀 버너스리가 1998년에 쓴 “Cool URIs don't change”라는 글이 있어요. 좋은 URL은 바뀌지 않는다는 거죠. 사이트를 개편할 때 옛 주소를 404로 날리지 말고 리다이렉트만 걸어둬도, 누군가의 문서 속 링크를 살릴 수 있어요.
마무리
웹 아카이브는 화려하진 않지만, 사회가 “그때 무슨 일이 있었는지”를 기억하는 인프라예요. 그리고 그 인프라를 실제로 만들고 유지하는 건 결국 우리 같은 개발자들이고요.
여러분은 서비스를 개편할 때 옛 URL과 데이터를 어떻게 처리하고 계신가요? 공공 기록 보존을 정부에만 맡겨도 괜찮을까요, 아니면 시민 개발자들이 더 적극적으로 나서야 할까요?
🔗 출처: Hacker News