URL, URI, URN 딱 한글자씩만 다른 요 녀석들, 정리를 해두지 않으니 들을 때마다 뭐가 뭔지 모르겠더라구요.. 더 이상 헷갈리지 않도록 확실하게 정리를 해보겠습니다.
🌐 URI (Uniform Resource Identifier)
URL, URI, URN 중 가장 먼저 정리할 아이는 URI 입니다. URL과 URN이 URI에 속하는 개념이기 때문이죠. 이를 벤 다이어그램으로 나타내보면 아래와 같습니다.
위의 그림에서도 볼 수 있듯이 URL과 URN은 URI의 한 종류라고 할 수 있습니다. 그렇기 때문에 이 녀석들을 알기 위해서는 URI를 먼저 알아야 합니다!
📚 단어 뜻으로 알아보는 URI
먼저 간단하게 단어 뜻으로 접근을 해보겠습니다.
- Uniform Resource : 통합 자원
- Identifier : 식별자
먼저 통합 자원이라는 뜻은 웹 상에 있는 Resource의 type에 관계없는 모든 자원을 의미합니다. 인터넷 상에서 접근할 수 있는 것들에는 수많은 것들이 있습니다. 문서, 이미지, 영상, 책, 게임, 상품 등등 그 종류를 전부 말할 수도 없죠.
그러면 Identifier(식별자)는 뭘까요? 상황을 하나 가정해보겠습니다.
A : 얘들아 오늘 내가 책을 하나 봤어!
(책을 좋아하는) B : 책 제목이 뭐야?
(A와 특정 게임을 같이하는) C : 어떤거 강화할 때 쓰는건데?
(유튜브를 즐겨보는) D : 어떤 유튜버꺼 봤어?
이처럼 '책'이라는 단어에도 쓰인 상황과 어떻게 이용되는지에 따라 지칭하는 대상이 달라질 수도 있습니다. 이 상황에서 A는 다양한 사람들에게 자신이 원하는 대상을 콕 집어서 골라낼 수 있는 고유한 식별자 (unique identifier) 를 쓰지 못한 것입니다.
따라서 위에 대한 내용을 기반으로 URI를 정의해본다면 다음과 같습니다.
웹에 존재하는 모든 자원에 대한 UID(unique identifier)
📚 URI Scheme
URI를 표현할 때는 다음과 같은 정해진 구조를 사용해야 합니다.
scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]
여기서 맨 처음 보이는 Scheme을 보겠습니다. 앞에서 URI에 대해 웹 상 특정 자원을 가리키는 식별자라고 했는데, 그렇다면 해당 자원을 가리키는 URI는 단 하나만 존재할까요? 아닙니다. URI를 만들 수 있는 정말 많은 체계가 있고 각각의 체계 내에서 하나의 자원에 대한 여러 URI를 만들 수 있죠! Scheme 은 이 체계를 명시해줍니다. 따라서 Scheme에 따라서 : 뒤의 구문에 대한 해석방식이 조금씩 차이가 날 수 있죠!
Scheme의 대표적인 예로는 우리에게 익숙한 'http', 'https'가 있습니다.
어? 이건 프로토콜 아니에요?
네, 맞습니다. HTTP와 HTTPS 는 프로토콜의 종류이지요. URI의 Scheme에는 프로토콜도 들어갈 수 있습니다. (눈치채신 분도 있겠지만 프로토콜이 아닌 것도 들어갈 수 있구요)
위에서 말씀드렸듯이 Scheme은 URI의 체계에 대해 명시하고 있기 때문에 프로토콜 또한 URI의 하나의 체계가 될 수 있는 것입니다.
공식적으로 URI에서 쓸 수 있는 모든 Scheme은 IANA(Internet Assigned Numbers Authority)에서 관리를 하고 있습니다. 여기에 들어가시면 그 목록을 확인하실 수 있습니다.
🌐 URL (Uniform Resource Locater)
이제 우리에게 가장 익숙한 URL에 대해 알아보겠습니다.
✅ Identifier로써의 URL
위에서 URL은 URI의 일종이다 라는 말씀을 드렸었죠? 즉 URL 또한 Identifier(식별자) 입니다! URL은 자원이 존재하는 경로 로써 식별자의 기능을 수행합니다.
📘 URL의 Scheme은 프로토콜
URL을 통해 웹 상의 자원에 접근을 할 수 있다는 점으로 인해 URL의 사용에는 항상 프로토콜이 Scheme으로 포함이 되죠. 가장 많이 접하게 되는 URL은 HTTPS URL 이겠죠? (이외에도 http, ftp, file 등을 쓸 수 있습니다.)
📙 URL의 단점
URL은 경로로써 Identifier의 역할을 수행하고 접근 또한 가능합니다. 하지만 만약에 해당 자원의 경로가 바뀐다면 어떻게 될까요? 원래부터 경로로 식별을 했는데 해당 경로에 자원이 없다? 그렇다면 그 URL은 아무 쓸모가 없게 됩니다. 따라서 사용자 입장에서는 해당 자원에 대한 URL을 다시 찾아야 하구요.
🌐 URN (Uniform Resource Name)
사실 URN은 좀 생소한데요. 실제로 주변에 URN을 쓰는 곳은 도서관 정도 입니다.
✅ Identifier로써의 URN
URN은 단어에서도 확인할 수 있듯이 Name, 즉 해당 자원의 이름으로 Identifier의 기능을 수행합니다.
📘 URN의 Scheme은 urn
URN의 Scheme은 URL과 다르게 항상 urn으로 정해져 있습니다. 그리고 이 Scheme은 프로토콜이 아닙니다.(이게 무엇을 의미할까요? hint. 단점과 연결이 됩니다.) 이렇게 Scheme이 urn으로 설정될 경우 아래와 같은 구문으로 해석되게 됩니다.
urn:NID:NSS
- NID : Namespace Identifier
- NSS : namespace-specific string
URN은 이름만으로 식별을 하기 때문에 위의 구조가 살짝 카테고리에 따른 분류와 비슷한 형식을 띄고 있습니다. 이에 대한 예시는 Wikipedia의 Example에서 보실 수 있습니다.
📘 URN의 장점
URL과 다르게 고유 이름으로 식별하기 때문에 해당 자원의 Time과 Location에 independent합니다. 심지어는 해당 자원이 더 이상 없을 때도 URN은 없어지는 것이 아니라 그대로 유지가 됩니다. 따라서 URL과 같이 해당 자원의 위치가 바뀌었을 때도 같은 URN을 쓸 수 있습니다.
📙 URN의 단점
URN의 Scheme 이야기를 할 때 눈치채신 분도 있겠지만 URN은 경로가 아니기 때문에 식별자로서의 역할은 수행하지만 웹 상에서 해당 자원에 직접적으로 접근할 수 없습니다. 사실상 인터넷에서는 어떤 자원이 있다라고 아는 것만이 아니라 접근을 하고 이용을 하기 때문에 이는 정말 치명적인 단점이죠. 그렇기 때문에 특정 부분을 제외하면 잘 쓰지는 않습니다.
📝 참고사항
URN으로 웹에서 자원에 접근할 수 없는 특징을 영어로는 아래와 같이 표현합니다.URN is not resolvable on the WEB.
📝 Resolvable Identifier (on a system)
Resolvable Identifier는 어떠한 system 안에서 식별자가 가리키는 자원에 접근할 수 있다는 것을 의미합니다.
🏆 마치며...
사실 이 글을 쓰기 전에는 uri, url, urn 이 간단한 주제겠다라고 생각하고 있었는데 찾아보며 공부를 해보니 역시나 아니었네요.. 이번 포스트에서는 uri, url, urn에 대해 알아보고 각각이 어떤 특징들을 가지는지 알아보았습니다. 하지만 중요한 부분이 하나 더 남았죠. 바로 url의 구조입니다. 그 부분은 다음 포스트에서 다루어보도록 하겠습니다.
🔗 Reference
