자원, URI, URL, URN 이란?

지금까지는 클라이언트가 메시지를 주고받고자 하는 대상을 식별하는 방법을 알아봤다. 이번에는 송수신하고자 하는 정보를 식별하기 위한 방식인 URI, URI를 식별 기준으로 분류한 개념인 URL, URN을 알아보자. 

 

이 개념들을 이해하려면 먼저 자원(resource)이 무엇인지부터 이해해야한다. 자원이란 네트워크상의 메시지를 통해 주고받는 대상을 뜻한다. 이는 HTML 문서가 될수도 있고, 이미지나 동영상이 될 수도 있으며, 텍스트 파일이 될 수도 있다. 즉, 두 호스트가 네트워크를 통해 서로 정보를 주고 받을 때, 송수신하는 대상이 바로 자원인것이다.

 

오늘날 인터넷 환경을 이루는 대부분의 통신은 HTTP를 기반으로 이루어지므로, 자원이라는 용어는 'HTTP 요청 메시지의 대상'이라고도 표현한다. 

RFC9110
The target of an HTTP request is called a "resource".
HTTP가 요청하는 대상을 "자원"이라고 부른다. 

 

네트워크상에서 자원을 주고 받으려면 자원을 식별할 수 있어야한다. 대화 상대와 이야기를 나눈다해도 그 이야기를 이해하지 못한다면 의미가 없는것 처럼 말이다.. 이때 자원을 식별할 수 있는 정보를 URI(Uniform Resource Identifier)라고 부른다. 이름 그대로 자원을 식별하는 통일된 방식이 URI다. 

 

그렇다면 URI는 어떤 정보를 바탕으로 자원을 식별할까? 위치를 이용해 자원을 식별할 수도 있고, 이름을 이용해 자원을 식별할 수도 있다. 전자를 URL(Uniform Resource Locator), 후자를 URN(Uniform Resource Name)이라 한다. 

 

URL

 

오늘날 인터넷 환경에서 자원 식별에 더 많이 사용되는 방법은 URL과 URN 중 위치 기반의 식별자인 URL이다. URL이 띄고 있는 형식은 바로 다음과 같다. 

 

해당 URL 형태는 인터넷 표준 문서(RFC 3986)에서 소개하는 일반적인 URL 표기다. 이와 같은 형식이 HTTP(S)에서 어떻게 표기되고 사용되는지를 기준으로 알아보자. 

 

① scheme

URL의 첫 부분은 scheme이다. scheme은 '자원에 접근하는 방법'을 의미한다. 일반적으로 사용할 프로토콜이 명시된다. HTTP를 사용하여 자원에 접근할 때는 http://를 사용하고 HTTPS를 사용하여 접근할 때는 https://를 사용한다. scheme의 종류는 아래 링크에서 확인이 가능하다. 

https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

Uniform Resource Identifier (URI) Schemes

 

② authority

authority에는 '호스트를 특정할 수 있는 정보'. 예를 들어 IP 주소 혹은 도메인 네임이 명시된다. 콜론(:) 뒤에 포트 번호를 덧붙일 수도 있다. 

 

③ path

path에는 '자원이 위치한 경로'가 명시된다. 자원의 위치는 슬래시(/)를 기준으로 계층적으로 표현되고, 최상위 경로 또한 슬래시로 표현된다. 예를 들어 내가 원하는 자원이 'a.png'이고, 해당하는 데이터가 아래 그림과 같은 경로에 위치해 있다고 가정했을 때. 최상위 경로 아래(/), home 아래(/home), images 아래(/home/images) 에 있다. 따라서 a.png를 요청할 때의 path는 '/home/images/a.png' 가 된다. 

 

URL에서의 경로도 이와 같다. 'http 프로토콜로 접근 가능한 도메인 네임 example.com에서, /home/images에 있는 a.png를 요청'한다면 다음과 같은 URL로 요청할 수 있다. 

'http://example.com/home/images/a.png'

 

④ query

HTTP는 요청-응답 기반의 프로토콜이다. 클라이언트는 서버에게 URI(URL)가 포함된 HTTP 메시지를 보내고, HTTP 서버는 이에 대해 HTTP 응답 메시지를 보낸다. 그림으로 나타내면 다음과 같다. 

 

여태까지 알아본 URL 구문만으로도 문제없이 자원의 위치를 식별할 수 있는 경우도 있지만, 때로는 더 많은 정보가 필요할 수 있다. 예를 들어, '특정 단어를 검색한 결과'에 해당하는 자원이나 수많은 상품 중에서 '특정 상품을 검색한 뒤 그 결과를 내림차순으로 정렬한 결과'에 해당하는 자원을 scheme, authority, path만으로 모두 표현하기란 어렵다.

식별하는 기준이 많아질수록 3가지 구문만으로는 정보를 얻어내기가 어렵다.

 

이럴 때 사용할 수 있는 것이 쿼리 문자열(query string)이다. 쿼리 파라미터(query parameter)라고도 부른다. 쿼리 문자열은 물음표(?)로 시작되는 <키=값> 형태의 데이터로, 앰퍼샌드(&)를 사용하여 여러 쿼리 문자열을 연결할 수 있다. 다음은 <query=value>, <query2=value2>라는 쿼리 문자열이 포함된 URL 예시다. 

'http://example.com/random/path?query=value&query2=value2'

 

참고로, 쿼리 문자열은 서버를 개발하는 개발자가 설계하기 나름이다. 예를 들어 다음 그림처럼 부동산 검색 웹 사이트 URL이나 도서 판매 웹 사이트 URL을 설계할 수도 있다. 쿼리 문자열을 이용하면 서버와 더 다양하게 상호 작용이 가능해진다. 

 

⑤ fragment

fregment는 '자원의 한 조각을 가르키기 위한 정보'이다. 흔히 HTML 파일과 같은 자원에서 특정 부분을 가리키기 위해 사용된다. 예를 들어 다음과 같이 특정 HTML 파일 자원의 위치를 나타내는 URL이 있다고 가정해보자. 

'http://datatracker.ietf.org/doc/html/rfc3986'

 

이번에는 아래의 URL을 보자. 아래의 URL은 위의 HTML 파일 자원 내의 특정 부분을 나타낸다. 브라우저로 위의 URL과 아래의 URL에 각각 접속해보면 차이를 알 수 있다. 위의 URL은 HTML 파일 그 자체를 가르키기에 브라우저로 접속하면 HTML의 첫 부분이 보이지만, 아래의 URL은 HTML 자원의 특정 부분을 가르키기에 브라우저로 접속하면 HTML 파일의 특정 부분으로 이동하게 된다. 

'http://datatracker.ietf.org/doc/html/rfc3986#section-1.1.2'

 

 

URN

 

앞서 설명한 대로 URL은 위치 기반 자원 식별 체계라 볼 수 있다. 그런데 자원의 위치는 언제든 변할 수 있다. 자원의 위치가 변한다면 URL은 유효하지 않을 수 있다. 이것은 URL의 고질적인 문제 중 하나다. 

 

반면 URN은 자원에 고유한 이름을 붙이는 이름 기반 식별자이기에 자원의 위치와 무관하게 자원을 식별할 수 있다는 장점이 있다. 다음과 같은 URN 예시를 보자. 다음 URN은 ISBN이 0451450523인 도서를 나타내는 URN이다.

urn:isbn:0451450523

 

또한 다음 URN은 인터넷 기술의 표준을 만드는 단체인 국제 인터넷 표준화 기구 IETF(Internet Engineering Task Force)의 공식 문서 중 RFC 2648을 나타내는 URN 예시다. 

urn:ietf:rfc:2648

 

이와 같이 URN을 이용하면 위치나 프로토콜과 무관하게 자원을 식별할 수 있다. 다만 URN은 URL만큼 널리 채택된 방식은 아니기에 자원을 식별할 URI로는 URN보다는 URL이 더 많이 사용된다. 

 

정리

 

자원을 식별하는 방법 

1. 자원 (Resource) 

• 의미 : IP 주소나 도메인 네임으로 특정된 통신 대상과 주고받는 메시지의 본체. 
• 핵심 : 통신을 통해 얻고자 하는 목적물 그 자체임. 

2. URI (Uniform Resource Identifier) 

• 의미 : 네트워크상에서 자원을 식별하기 위한 통일된 식별 방법. 
• 역할 : 통신 상대(호스트)를 찾아가는 것 뿐만 아니라, 그 안에서 "무엇을 요청하고 전달할지"를 명확히 구분해줌.
• 분류 : 식별 방식에 따라 URL과 URN으로 나뉨.

2.1 URL (Uniform Resource Locator)

• 의미 : 자원의 위치(Location)를 기반으로 식별하는 방식. (현재 인터넷의 표준)
• 설명 : 서버 내 폴더와 파일의 경로를 기반으로 자원을 특정함. 
• 단점 : 자원의 물리적 위치가 옮겨지면 기존 URL로는 더 이상 자원을 찾을 수 없음.

[URL의 구조]

ex) 'https://example.com/home/userinfo?query=value#kim

1. Scheme : 자원에 접근하는 방법(프로토콜). (예: http://, https://)
2. Authority : 호스트 정보, IP 주소나 도메인 네임, 그리고 포트 번호(예 : ':8080')가 포함됨.
3. Path : 자원의 상세 경로, 슬래시(/)로 구분하며 최종적으로 자윈의 이름이 위치.
   • ex) 'http://example.com/home/images/a.png'
4. Query : 추가적인 조건이나 상세 식별이 필요할 때 사용. ?로 시작하며 <키=값> 쌍으로 표기, &를 통해 여러 쿼리 문을 연결 가능.
5. Fragment : 자원의 특정 부분을 가르킬 때 사용. # 을 사용. 

2.2 URN (Uniform Resource Name) 

• 의미 : 자원의 위치와 상관없이 고유한 이름으로 식별하는 방식. 
• 특징 : 자원의 위치가 바뀌어도 식별자가 변하지 않음. 실무에서는 URL만큼 대중적으로 쓰이지 않음. 

3. 추가로 알면 좋은 점

• 포트 번호의 생략 : URL의 Authority 부분에서 HTTP는 80번, HTTPS는 443번 포트를 기본으로 사용함. 따라서 포트 번호가 생략되면 브라우저가 Scheme을 보고 알맞는 포트번호로 알아서 찾아감. 만약 다른 포트를 쓴다면 콜론으로 포트를 덧붙여줘야 브라우저가 정상적으로 요청을 날릴 수 있음.
• URI와 URL의 관계 : "URI는 식별자라는 개념이고, URL은 그 구현체 중 하나"라고 이해하면 됨. 요즘은 URL이 URI의 역할을 다하고 있어 혼용되기도 하지만 이론적으로는 URI가 URL를 포함하는 개념임.
• Fragment의 처리 : 요청한 자원의 특정 위치로 이동할 때 쓰이는데, 이건 서버로 전달되지 않고 브라우저 내부에서만 처리됨. 
• "식별"과 "위치"의 미묘한 차이 : 현대적인 웹 아키텍쳐(REST API 등)에서는 URL이 단순히 "파일의 위치"가 아니라 "추상적인 자원"을 가르키는 경우가 많음.
  • 과거 : 'http://server.com/images/user.jpg' (user.jpg 라는 이미지 파일을 식별)
  • 현재 : 'http://server.com/users/123' (ID가 123인 사용자라는 '자원'을 식별)
  • 이런 경우 위치 정보를 포함하고 있으니 URL이면서 URI임.
• HSTS(HTTP Strict Transport Security) : 최근 브라우저들은 보안 때문에 http 보단 https를 선호함. 따라서 http 접속 시 https(443 번 포트)로 바꿔서 요청하기도 함. 이걸 HSTS라고 함. 
• Scheme에 따른 동작 : Scheme은 포트만 결정하는 것이 아니라, 데이터를 주고 받는 방식도 결정함.
  • ftp:// 면 파일 전송 규칙을 따름. 
  • mailto: 면 이메일 클라이언트를 실행시킴.