[CS] URI, URL, URN 완벽정리

웹 개발자, 특히 백엔드 개발자에게 '리소스(Resource)'를 다루는 것은 굉장히 중요합니다. 우리는 매일 클라이언트의 요청을 받아 특정 리소스를 조회하거나 생성하고, 그 결과를 응답으로 반환해줍니다. 이 과정에서 우리는 브라우저 주소창에 입력된 주소를 흔히 URL(Uniform Resource Locator)이라고 부릅니다.

하지만 RFC 표준 문서나 Java의 java.net 패키지, 혹은 Spring Framework의 내부 코드를 들여다보면 URL 대신 URI(Uniform Resource Identifier)라는 용어가 더 포괄적으로 사용되는 것을 발견할 수 있습니다. 많은 개발자가 이 두 용어를 혼용하지만, 엄밀한 기술적 문맥에서 URI와 URL은 분명한 포함 관계와 의미적 차이를 가집니다.

정확한 기술 용어의 사용은 개발자 간의 커뮤니케이션 비용을 줄이고, RESTful API 설계 시 리소스 식별에 대한 모호함을 없애는 첫걸음입니다. 이번 글에서는 웹 표준을 정의하는 RFC 3986 스펙을 기반으로 URI의 명확한 정의와 구조, 그리고 하위 개념인 URL, URN과의 차이점을 확실하게 정리해 보겠습니다.

이 글은 다음의 순서로 진행됩니다.

1. URI (Uniform Resource Identifier): 리소스를 식별하는 통합된 방식
2. URL (Uniform Resource Locator): 리소스의 위치를 통한 식별
3. URN (Uniform Resource Name): 리소스의 이름을 통한 식별

1. URI (Uniform Resource Identifier)

URI는 Uniform Resource Identifier의 약자로, 우리말로 번역하면 '통합 자원 식별자'입니다. 인터넷에 있는 자원(Resource)을 식별(Identify)하기 위한 문자열의 표준 규약을 의미합니다.

여기서 가장 중요한 핵심 단어는 '식별(Identify)'입니다. URI는 리소스를 "찾는 방법(Locate)"이나 "이름(Name)"을 포함할 수 있는 가장 상위의 개념이며, 이 리소스가 무엇인지 가리키는 역할을 합니다.

1-1. 정의

URI라는 단어를 구성하는 세 가지 단어의 기술적 의미를 살펴보면 그 본질을 더 정확히 이해할 수 있습니다.

• Uniform (통합된/일관된): 리소스를 식별하는 방식이 통일되어 있음을 의미합니다. 웹상의 리소스는 텍스트, 이미지, 영상 등 다양한 형태를 띠지만, 이를 식별하는 문법(Syntax)은 프로토콜이나 리소스 타입에 상관없이 일관된 규칙을 따릅니다. 이는 상호운용성(Interoperability)을 보장하는 핵심입니다.
• Resource (자원): URI로 식별할 수 있는 모든 것을 지칭합니다. 이는 단순한 HTML 문서나 이미지 파일 같은 정적 파일뿐만 아니라, RESTful API의 엔드포인트, 서비스, 혹은 추상적인 개념까지도 포함합니다.
• Identifier (식별자): 다른 항목과 구분하여 대상을 유일하게 식별할 수 있는 정보를 뜻합니다.

1-2. URI의 일반적 문법

백엔드 개발자가 URI를 다룰 때 가장 눈여겨봐야 할 것은 URI의 구조입니다. RFC 3986은 URI의 문법을 다음과 같이 정의합니다.

scheme:[//authority]path[?query][#fragment]

각 구성 요소는 다음과 같은 역할을 수행합니다.

1. Scheme (스킴): 사용할 프로토콜을 정의합니다. (예: http, https, ftp, mailto). 자원에 접근하는 방법을 명시합니다.
2. Authority (권한): 리소스를 호스팅하는 주체를 나타냅니다. 일반적으로 userinfo@host:port 형태를 띠지만, 웹에서는 주로 도메인명(Host)과 포트(Port)가 사용됩니다.
3. Path (경로): 리소스의 계층적(Hierarchical) 위치를 나타냅니다. (예: /users/123/profile). REST API 설계 시 리소스의 구조를 표현하는 핵심 부분입니다.
4. Query (쿼리): Path만으로 식별하기 어려운 추가적인 식별 정보나 필터링 조건을 키-값(Key-Value) 쌍으로 전달합니다. (예: ?page=1&sort=desc). ?로 시작하며 비계층적인 데이터입니다.
5. Fragment (프래그먼트): 리소스 내부의 특정 부분(북마크, 섹션 등)을 가리킵니다. #으로 시작하며, 중요한 점은 Fragment는 서버로 전송되지 않고 클라이언트(브라우저)에서만 처리된다는 점입니다.

1-3. URI의 포함 관계

가장 많이 혼동하는 개념인 URI, URL, URN의 관계는 포함 관계로 이해해야 합니다.

• URI는 가장 상위 개념입니다.
• URL(Locator)과 URN(Name)은 URI의 하위 개념입니다.

즉, 우리가 흔히 사용하는 웹 주소는 리소스의 '위치'를 나타내므로 URL이면서 동시에 URI입니다.

2. URL (Uniform Resource Locator)

우리가 웹 브라우저 주소창에 입력하는 주소, 즉 https://www.google.com과 같은 문자열이 바로 URL입니다. URL은 Uniform Resource Locator의 약자로, 흔히 '웹 주소'라고 불리지만 기술적으로는 '리소스가 네트워크상 어디에 위치하는지(Location)' 알려주는 규약입니다.

앞서 설명했듯 URL은 URI의 하위 개념입니다. 모든 URL은 URI이지만, URL은 리소스를 식별하는 방식에 있어 '위치'라는 구체적인 수단을 사용한다는 점에서 차이가 있습니다.

2-1. 위치와 접근 방법

URL의 가장 핵심적인 특징은 리소스가 있는 구체적인 위치뿐만 아니라, 그 리소스에 도달하기 위한 수단까지 포함한다는 점입니다.

RFC 1738(URL 규격)에 따르면 URL은 크게 두 가지 정보로 구성됩니다.

1. Access Mechanism (접근 메커니즘): 리소스를 가져오기 위해 어떤 프로토콜을 사용해야 하는지 정의합니다. (예: http, ftp)
2. Network Location (네트워크 위치): 리소스가 존재하는 서버의 IP 주소(혹은 도메인)와 리소스 경로입니다.

예를 들어 https://www.example.com/index.html이라는 URL은 다음과 같이 해석됩니다.

• 어디에 있는가? www.example.com 서버의 /index.html 경로에 있다.
• 어떻게 가져오는가? HTTPS 프로토콜을 사용하여 가져와라.

2-2. URL의 구조적 분석

• Scheme (Protocol): URL의 시작 부분으로 리소스에 접근하는 프로토콜을 명시합니다. 웹 개발에서는 주로 http나 https를 사용하지만, 파일 전송을 위한 ftp, 이메일을 위한 mailto, 데이터베이스 연결을 위한 jdbc 등 다양한 스킴이 존재합니다.
• Authority (Domain & Port): 리소스를 보유하고 있는 서버의 주소입니다. 도메인 이름은 DNS를 통해 IP 주소로 변환되며, 포트 번호는 생략 시 해당 프로토콜의 기본 포트(HTTP 80, HTTPS 443)가 사용됩니다.
• Path (File Path): 서버 내부에서 리소스가 위치한 계층적 경로입니다. 과거 정적 웹 시절에는 실제 파일 시스템의 디렉토리 구조와 일치했으나, 현대의 MVC 패턴이나 REST API 환경에서는 논리적인 라우팅 경로(Endpoint)를 의미하는 경우가 많습니다.

2-3. URL의 한계

URL은 가장 널리 쓰이는 식별자이지만, 단점이 있습니다. 바로 리소스의 위치가 변하면 식별자로서의 기능을 상실한다는 점입니다.

만약 example.com 서버의 /data/report.pdf 파일이 /archive/report.pdf로 이동된다면, 기존 URL(.../data/report.pdf)로 접근하는 사용자는 404 Not Found 에러를 만나게 됩니다. 리소스 자체는 여전히 존재하지만, 그 리소스를 가리키던 '위치'가 바뀌었기 때문에 식별이 불가능해지는 현상, 이를 흔히 링크 부패(Link Rot)라고 합니다.

이러한 위치 의존적인 한계를 극복하기 위해 등장한 개념이 바로 다음에 다룰 URN(Uniform Resource Name)입니다.

3. URN (Uniform Resource Name)

URL이 리소스의 '위치'를 가리킨다면, URN은 Uniform Resource Name, 즉 리소스의 '고유한 이름' 그 자체를 의미합니다.

URN의 핵심 목적은 "위치 독립적(Location-independent)"인 식별자를 제공하는 것입니다. 리소스가 서버 내에서 다른 경로로 이동하거나, 아예 다른 도메인의 서버로 이관되더라도, URN이라는 이름은 변하지 않고 영구적으로 해당 리소스를 가리켜야 합니다.

3.1 URN의 구조

RFC 2141에 정의된 URN의 문법은 URL과는 다소 다른 형태를 띱니다. 스킴이 urn으로 고정되며, 다음과 같은 구조를 가집니다.

urn:<NID>:<NSS>

• urn: 스킴 식별자입니다. 대소문자를 구분하지 않습니다.
• NID (Namespace Identifier): 네임스페이스 식별자입니다. 어떤 종류의 이름을 사용할 것인지 정의합니다. (예: isbn, ietf, uuid)
• NSS (Namespace Specific String): 네임스페이스 내에서 리소스를 구분하는 구체적인 식별 문자열입니다.

3.2 대표적인 URN 예시

우리가 개발하면서 알게 모르게 접했던 식별 코드들이 사실 URN 표준을 따르는 경우가 많습니다.

1. ISBN (국제표준도서번호): 전 세계의 도서를 식별하는 번호입니다.
   • urn:isbn:978-0-123-45678-9
   • 책이 어느 서점에 있든, 책의 고유 번호는 변하지 않습니다.
2. UUID (범용 고유 식별자): 백엔드 개발 시 DB의 Primary Key나 세션 ID 등으로 자주 사용하는 UUID도 URN으로 표현 가능합니다.
   • urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66

3.3 URN의 한계와 URN Resolution

"URN이 리소스 이동 문제를 해결할 수 있다면, 왜 우리는 브라우저에서 URL만 사용할까?"라는 의문이 생길 수 있습니다.

가장 큰 이유는 URN 해석기(Resolver)의 부재입니다.

URL은 DNS와 IP 라우팅을 통해 리소스의 위치를 즉시 찾아갈 수 있습니다. 하지만 URN은 이름만 있을 뿐, "실제로 그 리소스가 어디에 있는지"에 대한 정보는 없습니다. 따라서 URN을 실제 리소스의 위치(URL)로 변환해 주는 URN Resolution Service가 필요한데, 현재의 웹 인프라는 이를 보편적으로 지원하지 않습니다.

따라서 현대 웹에서는 순수한 URN보다는, 식별성과 위치 정보를 모두 포함할 수 있는 URL(URI) 형태를 주로 사용하게 되었습니다.