문득 이 차이가 헷갈렸다. URI가 더 큰 집합이라는 것은 알고 있었으나 정확하게 모르는 듯하다. 정리해두자.
들어가기에 앞서
먼저 URI와 같은 친구들이 필요한 이유부터 생각해보자. 결국 웹 기술은 어렵게 생각할 필요없이, 원하는 문서를 가져다 주기만 하면 된다. 이게 가장 중요하다. 그렇다면, 원하는 것이라는 것을 어떻게 정의할 것인가?
예를 들어, A친구 집에, 안방(...)에 들어가서 TV 밑에 있는 애플 홈팟을 가져다줘. 이런식으로 말을 하던가, A친구 집에 있는 애플 홈팟을 가져다줘. 이런식으로 말할 것이다. 전자의 경우는 내가 원하는 물건에 대한 정확한 "주소"를 말했고, 후자의 경우에는 "물건"에 집중해서 말했다. 이 과정에서 서로 상호간에 소통만 된다면, 이 요구를 받아들이는데는 전혀 문제가 없다.
Network는 이렇게 상식에 기반하는 경우가 많다. 전자를 대표하는 것이 URL이다. 그리고 후자를 대변하는 것이 URN이다. 그리고 상호간의 소통 방법이 Protocol이다. 그리고 이렇게 특정 "자원"을 요청하는 방식(URL, URN)을 일컫는 말이 URI이다.
대략적인 밑그림은 그렸으니, 세부적으로 알아보자.
URI
Uniform Resource Identifier
아무래도 두개념의 상위 개념이다보니, 추상적인 의미를 더 많이 가진다고 생각하면 된다. 즉, 특정 정보를 식별할 수 있는 문자열이라면 URI라 생각할 수 있다. 물론 다음과 같은 형식을 만족할 경우에 한해서다.
scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]어떤 protocol을 사용할 것인지 scheme에 적고, author의 정보를 적은 뒤, host 위치, port 정보, path 정보, query 등을 적는 양식을 가지고 있다. 이렇게 보면 익히 알고 있는 URL과 뭐가 다르냐고 물어볼 수 있겠지만 조금만 참자. 기억해야 할 것은 상위 개념이라는 것이다.
URL
Uniform Resource Locator
우리가 잘 아는 녀석들이다. 보통 http, https protocol을 많이 사용한다. URI와의 차이점은, 정확한 위치를 기술해야 한다는 것이다. 다음의 두 URI의 차이점을 생각해보자.
이해가 가는가? 별 것 없다!
URN
Uniform Resource Name
그럼 이녀석은 왜 나왔는가? URL의 단점때문에 등장했다. URL은 "정확한 위치"를 가리켜야 한다는 제약을 가지고 있다. 하지만, index.html 파일이 특정 directory로 변경된다면 어떻게 될까? 기존에 사용하던 https://velog.io@wansook0316/index.html은 무용지물이다. 쓸모가 없다.
문제는 이 URL이 다른 곳에서 많이 사용되고 있다는 것이다. 대표적인 예로 검색 엔진. 이녀석은 해당 주소를 현재로서는 맞는 주소라고 알고 있을 확률이 높다. (물론 주기적으로 돌면서 다시 인덱싱한다.) 그렇게 되면, 이전에 해당 주소로 검색해서 들어오던 사용자들은 갑자기 없는 resource다 라는 에러를 받을 수 밖에 없다.
이렇게 특정 자원에 대한 위치와 존재 여부를 엮어서 생각하다보니, 해당 링크가 깨져버리는 순간에 관리가 어려워진다는 문제가 발생했다. 이에 대한 해결법은 무엇이 있을까?
특정 자원에 대한 이름을 기반으로 고유하게 만드는 것이다. 그렇게 되면 객체의 위치와 상관없이 객체를 찾을 수 있게 된다. 하지만 이러한 원리에 의해서 모든 자원의 URN은 고유해야 한다.
지금은?
그럼 지금은 어떻게 사용하고 있을까? 위치의 변화에도 문제가 없으면서 URL기반을 사용하고 싶을 것이다. URN은 아직 상용화되지는 않았다. 그래서 URI가 많이 사용되고 있는 것이다. URN이 지적한 문제는, 사실 서버측에서 한번의 추가 계산이 있을 경우 해결된다. 그래서 URL과 비슷한 규칙을 가지면서, 정확한 위치가 아닌 문자열로 끝내는 URI를 통해 많은 사이트가 제작되어 있다. 그래서 URL과 URI가 헷갈리는 것 아닐까?
마무리
이렇게 URI, URL, URN에 대해서 알아보았다. 끝!
Reference
