1. 라이브러리
  2. HTTP와 웹
  3. HTTP 기본 원리

업데이트됨 1개월 전

당신이 지금까지 클릭한 모든 링크는 URL입니다. 수천 개를 사용해왔을 겁니다. 워낙 잘 작동하다 보니 URL이 실제로 무엇을 약속하는지, 그 약속이 깨지면 어떤 일이 벌어지는지 생각해본 적이 없을 겁니다.

웹사이트가 새 도메인으로 이전합니다. 회사가 파일 구조를 재편합니다. 서버가 폐기됩니다. URL이 끊깁니다. 리소스는 어딘가에 여전히 존재합니다. 다만 더 이상 찾을 수 없을 뿐입니다.

이것이 바로 URN이 해결하려고 설계된 문제입니다.

URI: 상위 개념

**URI(Uniform Resource Identifier)**는 리소스를 고유하게 식별하는 모든 문자열입니다. 그게 전부입니다. 상위 카테고리죠.

URI는 두 가지 종류로 나뉩니다:

  • URL: 위치로 리소스를 식별
  • URN: 이름으로 리소스를 식별

모든 URL은 URI입니다. 모든 URN도 URI입니다. 하지만 둘은 서로 다른 문제를 해결합니다.

URL: 무언가가 있는 곳

**URL(Uniform Resource Locator)**은 무언가를 가져오는 방법을 알려줍니다. 프로토콜, 도메인, 경로가 담겨 있습니다.

https://www.connected.app/support/topics/dns
  │            │                    │
프로토콜      도메인               경로

URL은 일종의 지시문입니다. "HTTPS를 사용하라. 이 서버에 연결하라. 이 리소스를 요청하라." 브라우저는 정확히 무엇을 해야 하는지 압니다.

https://www.example.com/page.html    — 웹 페이지
ftp://files.example.com/doc.pdf      — FTP를 통한 파일
mailto:support@connected.app         — 이메일 주소
tel:+1-555-123-4567                  — 전화번호

이 모두가 위치와 접근 방법을 지정합니다. 그것이 URL을 URL답게 만드는 것입니다.

URN: 무언가가 무엇인지

**URN(Uniform Resource Name)**은 네임스페이스 안에서 이름으로 리소스를 식별합니다. 어디에 있는지가 아니라, 무엇인지를 말합니다.

urn:isbn:978-0-134-68599-1

이것은 ISBN으로 특정 책을 식별합니다. 지구상의 어떤 서점에 가든 이 번호를 건네면 어떤 책인지 정확히 압니다. 이 식별자는 어느 선반에 꽂혀 있든, 어느 창고에 보관되든, 어느 웹사이트에서 판매되든 상관없이 유효합니다.

urn:isbn:978-0-134-68599-1                      — 책
urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66   — 고유 식별자
urn:ietf:rfc:3986                               — RFC 문서

대가는 분명합니다. URN은 무언가를 영구적으로 식별하지만, 어떻게 가져오는지는 알려주지 않습니다. 해당 식별자를 실제로 가져올 수 있는 무언가로 바꾸려면 별도의 시스템이 필요합니다. 도서관 카탈로그, 리졸버 서비스, 검색 엔진 같은 것들이요.

핵심 차이

URL은 어디에 있는지에 대한 약속입니다. URN은 무엇인지에 대한 약속입니다.

어디에 있는지에 대한 약속은 이전하면 깨집니다. 무엇인지에 대한 약속은 깨지지 않습니다.

이런 이유로 시스템 설계 방식이 달라집니다:

  • 학술 논문은 DOI(URN의 일종)를 사용합니다. 논문은 수십 년간 인용되지만 저널 웹사이트는 끊임없이 재편되기 때문입니다.
  • 책은 ISBN을 사용합니다. 같은 책이 수천 개의 서로 다른 소매점에서 판매될 수 있기 때문입니다.
  • 데이터베이스 레코드는 UUID를 사용합니다. 레코드가 시스템 간에 이전되기 때문입니다.

링크를 클릭하는 용도로는 URL로 충분합니다. 이전, 재편, 시간을 견뎌야 하는 참조에는 URN이 필요합니다.

왜 모두가 혼동하는가

웹에서 접하는 거의 모든 URI는 URL입니다. 누군가 "URI"라고 하면 보통 "URL"을 의미합니다. 이것이 틀린 건 아닙니다. 다만 정확하지 않을 뿐입니다.

이 구분은 영구 식별자를 갖는 시스템을 구축하거나, 안정적인 참조를 갖는 API를 설계하거나, 리소스는 이전하지만 그에 대한 참조는 깨지지 않아야 하는 맥락에서 일할 때만 중요합니다.

그 외의 경우에는 두 용어를 혼용해도 됩니다. 그리고 그것으로 충분합니다.

URI, URL, URN에 관해 자주 묻는 질문

모든 URL은 URI인가요?

예. URL은 URI의 특정 종류로, 위치로 리소스를 식별합니다. 모든 URL은 URI이지만, 모든 URI가 URL인 것은 아닙니다(일부는 URN입니다).

URN은 언제 URL 대신 사용해야 하나요?

리소스가 이전될 수 있을 때 사용합니다. 호스팅 제공업체를 바꾸거나, 재편되거나, 여러 채널을 통해 접근될 수 있다면 URN이 이전을 견디는 안정적인 참조를 제공합니다. 알려진 위치의 무언가를 가리키기만 하면 된다면 URL이 더 간단합니다.

리소스가 URL과 URN을 둘 다 가질 수 있나요?

예, 그리고 많은 경우에 그렇습니다. 책은 영구적으로 식별하는 URN(urn:isbn:978-0-134-68599-1)과 현재 소매점을 가리키는 여러 URL을 동시에 갖습니다. URN은 정체성입니다. URL은 현재 위치입니다. Barnes & Noble이 웹사이트를 개편하더라도 ISBN은 여전히 유효합니다.

URN을 "클릭"하면 어떻게 되나요?

기본적으로는 아무것도 일어나지 않습니다. URN에는 접근 지시사항이 없습니다. 이것이 영구성을 위한 트레이드오프입니다. URN으로 식별된 리소스를 가져오려면 리졸버가 필요합니다. URN을 현재 URL로 매핑하는 시스템이요. 학술 논문에 대해서는 DOI 리졸버가 이 역할을 합니다. 도서관 시스템은 ISBN에 대해 이 역할을 합니다.

이 페이지가 도움이 되었나요?

😔
🤨
😃