웹의 아버지가 1996년에 그렸지만 끝내 묻힌 URL 문법, '매트릭스 URI'
우리가 매일 주소창에 치는 URL, 사실 지금 모습이 되기까지 수많은 갈림길이 있었어요. 그중 하나가 웹을 만든 팀 버너스리(Tim Berners-Lee)가 1996년에 끄적여 둔 '매트릭스 URI(Matrix URI)'라는 아이디어예요. 표준으로 채택되진 못하고 W3C 사이트의 디자인 노트로만 남아 있는데, 30년 가까이 지난 지금 봐도 꽤 흥미로운 발상이라 한번 풀어볼게요.
먼저, 우리가 아는 URL 복습
https://site.com/products/123?color=red&size=L 이런 주소 익숙하죠. 여기서 물음표(?) 뒤에 붙는 color=red&size=L을 쿼리 스트링(query string)이라고 해요. '이 주소에 이런 옵션을 얹어줘'라는 추가 정보인데, 핵심은 이게 URL 전체에 한 덩어리로 붙는다는 거예요. 경로(/products/123)의 어느 조각에 적용되는지 구분이 없죠.
매트릭스 URI는 뭐가 달랐나
버너스리의 발상은 이거였어요. '경로의 각 조각마다 따로따로 좌표를 매달면 어떨까?' 그래서 쿼리처럼 물음표를 쓰는 대신 세미콜론(;)을 써서 경로 세그먼트 하나하나에 파라미터를 붙이자는 거였죠. 예를 들면 이런 식이에요.
/map;lat=37;lon=127/layer;type=satellite/zoom;level=5
map이라는 조각엔 위도·경도를, layer 조각엔 위성지도 타입을, zoom 조각엔 확대 레벨을 각각 붙였죠. 이름이 '매트릭스(행렬)'인 이유가 여기 있어요. 마치 여러 축을 가진 좌표 공간에서 한 점을 콕 집어내듯, URL 안에서 다차원의 위치를 표현하자는 거였거든요. 쿼리 스트링이 'URL 전체에 적용되는 전역 옵션'이라면, 매트릭스 파라미터는 '바로 그 경로 조각에만 적용되는 국소 옵션'이라는 게 결정적 차이예요. 계층 구조 안에서 부분마다 세밀하게 설정을 줄 수 있는 거죠.
왜 세상에 못 나왔을까
아이디어는 깔끔했는데 현실의 벽이 높았어요. 일단 이건 정식 표준 문서(RFC)로 못 박힌 적이 없고 '한번 생각해 본 디자인 이슈' 메모 수준에 머물렀어요. 게다가 대부분의 경우엔 그냥 쿼리 스트링 하나로도 충분했거든요. 굳이 복잡한 새 문법을 배울 이유가 없었던 거죠. 브라우저·서버·각종 프레임워크가 제대로 지원하지 않으니 캐싱이나 인코딩 처리도 제각각이라 혼란만 키웠고요. 결국 '기술적으로 가능하지만 굳이 필요 없는' 자리에 머물렀어요.
그래도 흔적은 남아 있어요
재밌는 건, 완전히 사라진 게 아니라는 점이에요. 자바 진영의 JAX-RS에는 @MatrixParam이라는 기능이 실제로 있어서 세미콜론 파라미터를 받아올 수 있고, 스프링(Spring)에도 @MatrixVariable이 있어요(기본적으로는 꺼져 있어서 켜야 하지만요). URL 표준인 RFC 3986도 경로에 세미콜론을 쓸 수 있게 허용은 해뒀고요. 그러니까 매트릭스 URI는 '죽은 표준'이라기보다 '여기저기 조용히 살아남은 옵션'에 가까워요. 다차원 리소스를 주소로 표현하려던 그 고민 자체는 이후 좌표 기반 지도 타일 URL이나 GraphQL 같은 다른 형태로 모습을 바꿔 이어지고 있고요.
한국 개발자에게 주는 시사점
이 이야기가 주는 교훈은 두 가지예요. 하나는, 우리가 당연하게 여기는 URL 문법조차 수많은 '채택되지 않은 대안들' 위에 서 있다는 거예요. 기술 표준은 가장 똑똑한 안이 아니라 가장 단순하고 생태계가 받아주는 안이 이긴다는 걸 잘 보여주죠. 다른 하나는 실용적인 면이에요. 스프링이나 JAX-RS를 쓴다면 매트릭스 파라미터를 실제로 만져볼 수 있는데, 다만 캐시나 보안 필터가 세미콜론을 예상 못 해 문제를 일으킬 수 있으니 쓸 거면 충분히 테스트하라는 거예요.
한줄 정리
매트릭스 URI는 '더 우아한 설계가 항상 이기는 건 아니다'를 보여주는 웹 역사의 한 장면이에요. 여러분이 보기에 지금의 URL 설계에서 가장 아쉽게 묻힌 아이디어는 뭐가 있을까요?
🔗 출처: Hacker News