1998년 팀 버너스리는 W3C 사이트에 '멋진 URI는 변하지 않는다(Cool URIs Don't Change)'라는 글을 올렸다. 웹이 대중화되던 초기, 링크를 누르면 'Not Found'가 뜨는 이른바 깨진 링크(dangling link)가 급속도로 늘어나던 시기였다. 그의 진단은 단순하면서도 도발적이다. 이론적으로는 URI를 바꿔야 할 이유가 하나도 없는데, 현실에서는 수백만 가지 이유로 URI가 사라진다는 것이다. 도메인 소유자가 파산하거나 서버 유지 비용을 감당하지 못하는 경우를 제외하면, 문서가 웹에서 사라져야 할 정당한 이유는 사실상 없다는 게 그의 주장이다.
흥미로운 점은 이 글의 상당 부분이 웹마스터들이 흔히 대는 '변명'을 하나씩 반박하는 형식으로 되어 있다는 것이다. "파일 관리자가 존과 제인으로 바뀌었다", "스크립트로 생성되는 페이지라 cgi-bin에 둘 수밖에 없다" 같은 이유들이다. 버너스리는 이런 변명 대부분이 서버의 내부 구현 방식을 URI에 그대로 노출한 결과라고 지적한다. URI에 담당자 이름이 들어가거나 '.pl' 확장자, 'cgi-bin' 경로가 드러나 있다면, 담당자가 바뀌거나 실행 방식만 바꿔도 링크가 통째로 깨진다.
구현 방식과 URI를 분리하라
그가 제시하는 해법의 핵심은 URI 공간을 완벽하게 정리된 추상 공간으로 먼저 설계하고, 그것을 실제 파일 시스템에 매핑한 뒤 서버에 알려주라는 것이다. 아파치 같은 서버는 URI와 실제 파일 위치 사이의 관계를 유연하게 제어할 수 있는 기능을 이미 갖추고 있다. 그는 미국 국립과학재단(NSF)을 실제 사례로 든다. 문서 검색 진입점인 'cgi-bin/pubsys/browser/odbrowse.pl'은 '지금 우리가 일하는 방식'을 그대로 드러내 몇 년 뒤 살아남기 어렵지만, 실제 HTML 문서의 주소인 'pubs/1998/nsf9814/nsf9814.htm'은 훨씬 견고하다. 'pubs/1998'이라는 앞머리가 미래의 아카이브 서비스에 '1998년 분류 체계'라는 단서를 주기 때문이다.
버너스리는 당시 한창이던 URN(영구 식별자) 논의에 대해서도 냉정하다. 일부 사람들이 "어차피 URN이 다 해결해줄 테니 깨진 링크에 신경 쓸 필요 없다"고 여기는데, 이는 URN 논의가 낳은 최악의 부작용이라는 것이다. 대부분의 URN 설계가 기관 식별자에 날짜와 문자열을 붙이는 형태로, HTTP URI와 구조적으로 다르지 않다는 점을 그는 지적한다. 즉 지속되는 URN을 만들 역량이 있다면 지금 당장 그 방식대로 HTTP URI를 만들어 증명하면 된다는 것이다. HTTP에는 URI를 불안정하게 만드는 요소가 없으며, 불안정한 것은 조직 그 자체라는 문장이 이 글의 핵심을 압축한다.
설계란 정보를 덜어내는 일
URI가 바뀌는 이유는 그 안에 변할 수 있는 정보가 담겨 있기 때문이다. 따라서 URI 설계란 대부분 정보를 빼는 작업이라고 그는 정의한다. 변하지 않는 정보의 대표적인 예가 문서의 생성 날짜이며, 날짜를 URI 왼쪽에 두면 조직 구조나 주제 분류처럼 언젠가 바뀔 정보도 '1998년 당시의 의미'로 고정할 수 있다. 반대로 주제나 분류명을 URI에 넣는 것은 위험하다. W3C 스스로도 'MarkUp'을 'Markup'으로, 다시 'HTML'로 바꾸고 싶어 했고, 'History'나 'Stylesheets' 같은 이름을 재사용하고 싶어 했다는 자기 고백이 그 근거다. 계층적 분류는 중기적으로는 편리하지만, 사람마다 같은 웹을 다른 트리로 표현하기 때문에 장기적으로는 링크를 깨뜨린다.
이 원칙은 경로뿐 아니라 서버 이름에도 똑같이 적용된다. 'cgi.pathfinder.com', 'secure', 'lists.w3.org'처럼 운영 편의나 조직 구분을 위해 별도 도메인을 쓰면 그 구분을 나중에 바꿀 수 없게 된다. 그는 리다이렉션과 프록시를 이용하면 여러 웹 서버를 하나의 서버처럼 감출 수 있다는 점을 상기시킨다. 도메인 이름 자체도 마찬가지여서, 제품군이 바뀌어도 계속 그 이름으로 불리고 싶은지 미리 따져봐야 한다.
한국의 실무자 입장에서 이 글이 여전히 아프게 읽히는 이유는, 지금도 프레임워크나 CMS를 교체할 때마다 URL 구조가 통째로 갈아엎이는 일이 흔하기 때문이다. 라우팅 규칙, 리다이렉트 매핑, 콘텐츠 협상 같은 도구는 그때보다 훨씬 풍부해졌지만, '눈앞의 사이트를 가장 멋지게 보여주는 것'만 목표로 삼고 링크의 미래를 아무도 평가하지 않는다는 지적은 그대로 유효하다. 검색 순위, 외부 인용, 북마크, API 연동 등 오늘날 URL이 지는 책임은 오히려 더 무거워졌다.
다만 이 글이 만능 해법을 제시하는 것은 아니라는 점도 짚어둘 필요가 있다. 버너스리 스스로 '지속되는 URI'를 완벽히 구현하려면 문서에 URI를 심어 검증하고, 버전과 번역 관계를 추적하며, 체크섬으로 무결성을 지키는 소프트웨어가 필요한데 서버가 기본으로 그런 기능을 제공하지 않는다고 인정한다. 소유권이나 접근 권한, 보안 등급을 URI를 바꾸지 않고 조정할 수 있어야 한다는 요구 역시 당시로선 미완의 과제였다. 결국 이 글의 메시지는 기술이 아니라 태도에 있다. 2년, 20년, 200년 뒤에도 책임질 수 있는 URI를 배정하는 것은 웹마스터의 의무이며, 그것은 오직 URI를 어떻게 설계할지 미리 고민할 때만 가능하다는 것이다.