혹시 즐겨찾기 해뒀던 기술 문서를 몇 년 만에 열었는데 404가 뜬 경험 있으신가요? 분명히 존재했던 좋은 글이 회사 홈페이지 개편과 함께 증발해 버린 경험은요? 1998년에 웹의 창시자 팀 버너스리가 쓴 'Cool URIs don't change(멋진 URI는 변하지 않는다)'라는 문서가 있는데요, 28년 전 글인데 마치 요즘 웹에 대고 쓴 것처럼 읽혀요. 오래된 문서지만 지금 다시 읽어볼 가치가 충분해서 소개해 드릴게요.
핵심 주장: URI는 저절로 변하지 않는다
문서의 첫 부분이 모든 걸 말해요. 'URI는 변하지 않는다. 사람이 바꾸는 것이다.' URI가 뭐냐면 웹에서 자원을 가리키는 주소예요. 우리가 흔히 URL이라고 부르는 것의 상위 개념이라고 생각하시면 돼요. 이론적으로는 도메인 아래의 주소 공간이 전적으로 소유자의 통제 아래에 있으니 얼마든지 안정적으로 유지할 수 있고, 문서가 사라져야 할 정당한 이유는 사실상 회사가 망해서 서버를 못 돌리는 경우뿐이에요. 그런데 현실에서는 수백만 가지 이유로 주소가 바뀌죠. 조직이 개편돼서, 사이트를 리뉴얼해서, CMS를 갈아타서, 담당 부서가 바뀌어서요.
버너스리의 처방은 뿌리부터 달라요. 깨진 링크를 고치라는 게 아니라, 애초에 '변할 이유가 있는 정보를 URI에 넣지 말라'는 거예요. 구체적으로 뭘 빼야 하냐면요. 첫째, 기술 스택이에요. .cgi, .php 같은 확장자는 그 순간의 구현 기술일 뿐이고, 기술을 바꾸는 순간 주소가 깨져요. 둘째, 조직 구조예요. 주소에 들어간 부서명이나 팀명은 다음 조직 개편 때 같이 사라져요. 셋째, 상태나 분류예요. '최신', '인기' 같은 오늘의 상태는 내일의 거짓말이 되죠. 반대로 넣어도 되는 건 날짜예요. 발행 시점의 날짜는 시간이 지나도 거짓이 되지 않는 몇 안 되는 속성이거든요. 재미있는 게, 이 문서의 주소 자체가 w3.org/Provider/Style/URI 인데 실제로 28년째 같은 주소에서 열려요. 주장을 몸으로 증명하고 있는 셈이죠.
28년이 지난 지금은
그동안 상황이 나아졌을까요? 오히려 '링크 부패(link rot)'는 측정 가능한 현상이 됐어요. 링크 부패가 뭐냐면, 시간이 지나면서 웹의 링크들이 하나둘 죽어가는 현상을 말해요. 판례나 학술 논문이 인용한 URL조차 상당수가 죽는다는 연구가 꾸준히 나왔죠. 그래서 인터넷 아카이브의 웨이백 머신 같은 보존 프로젝트나, 학술 세계의 DOI(문서에 영구 식별자를 부여하고 실제 위치로 리다이렉트해 주는 체계) 같은 우회로가 생겼어요. 역설적이게도 이런 인프라가 필요하다는 사실 자체가, 우리가 버너스리의 조언을 지키지 못했다는 증거예요. 한편 기술적으로는 조언을 따르기가 훨씬 쉬워졌어요. 1998년에는 파일 확장자를 URL에서 숨기려면 서버 설정을 직접 만져야 했지만, 지금의 웹 프레임워크는 라우팅 계층이 기본이라 URL 설계가 애초에 구현과 분리돼 있으니까요. 도구는 좋아졌는데 규율은 그만큼 좋아지지 않은 거죠.
실무에 적용하면
당장 챙길 수 있는 것들이 있어요. 블로그나 문서 사이트를 이전할 때는 반드시 301 리다이렉트(이 주소가 영구히 저쪽으로 옮겨갔다고 알려주는 응답)를 걸어주세요. 검색 엔진 순위와 외부에서 걸어준 링크의 가치가 전부 여기에 달려 있어요. API를 설계할 때 URL 버저닝(/v1/, /v2/)을 쓴다면, 구버전 주소를 언제까지 살려둘지가 곧 여러분의 'Cool URI' 정책이에요. 클라이언트 입장에서 API 주소는 문서 링크보다 훨씬 깨지면 안 되는 약속이니까요. 사내 위키나 기술 블로그의 슬러그에 팀명이나 프로젝트 코드명을 넣고 있다면 한번 다시 생각해 보시고요. 조직 개편은 생각보다 자주 오거든요. 핵심은 URL을 '지금 편한 경로'가 아니라 '10년 뒤에도 지킬 약속'으로 설계하는 관점이에요.
한 줄 정리: 주소는 인터페이스이고, 인터페이스는 약속이며, 약속은 조직 개편보다 오래가야 한다. 여러분이 운영하는 서비스의 URL 중에 10년 뒤에도 살아 있을 자신이 있는 건 몇 개나 되나요? 사라진 좋은 문서 때문에 고생했던 경험도 한 번씩 나눠봐요.
🔗 출처: Hacker News