[HTTP] URI, URL, URN의 차이와 웹의 요청 메커니즘

1. 도입부

인터넷이라는 거대한 정보의 바다에서 특정 리소스를 정확히 찾아내기 위해서는 정교한 '주소 체계'가 필요하다. 우리가 매일 사용하는 브라우저 주소창의 텍스트는 단순한 문자열이 아니라, 전 세계에 흩어진 자원을 식별하기 위한 통일된 약속인 URI(Uniform Resource Identifier)다.

웹 개발을 하다 보면 URI와 URL을 혼용해서 사용하는 경우가 많지만, 엄밀히 말하면 이들 사이에는 명확한 계층 구조와 목적의 차이가 존재한다.오늘은 URI의 구성 요소부터 시작하여, 사용자가 엔터 키를 누르는 순간 브라우저 내부에서 어떤 일이 벌어지는지 그 기술적 흐름을 정리해 본다.

[Infra] 인터넷 네트워크의 핵심: IP부터 DNS까지

 

---

 

2. URI의 정의와 분류 (URI, URL, URN)

URI는 '리소스를 식별하는 통일된 방식'을 의미하며, 크게 로케이터(URL)와 이름(URN)으로 분류된다.

• Uniform: 리소스를 식별하는 통일된 방식.
• Resource: 자원, 즉 URI로 식별할 수 있는 모든 것(HTML, 이미지, 동영상, 심지어 실존하지 않는 개념까지 포함).
• Identifier: 다른 항목과 구분하는 데 필요한 정보.

URL vs URN

구분	URL (Locator)	URN (Name)
의미	리소스가 있는 위치를 지정	리소스에 이름을 부여
특징	서버의 IP나 경로가 바뀌면 주소도 변함	리소스의 위치가 변해도 이름은 변하지 않음
예시	https://www.google.com/search	urn:isbn:8960777331 (책의 ISBN)

Note: URN은 리소스의 이름을 부여하지만, 해당 이름만으로 실제 리소스를 찾는 인프라가 보편화되지 않아 현재 우리가 사용하는 대부분의 주소는 URL 방식이다.

---

 

 

3. URL 전체 문법 분석 (Syntax)

현대 웹의 표준인 URL은 아래와 같은 엄격한 문법 구조를 가진다.

scheme://[userinfo@]host[:port][/path][?query][#fragment]

각 구성 요소의 역할

1. Scheme: 어떤 방식으로 자원에 접근할 것인가에 대한 프로토콜 규칙이다. (예: http, https, ftp)
   • http는 80, https는 443 포트를 주로 사용하며 관례상 생략 가능하다.
2. Userinfo: URL에 사용자 정보를 포함해 인증할 때 쓰이지만, 보안상 거의 사용되지 않는다.
3. Host: 리소스가 위치한 서버의 도메인명 또는 IP 주소다.
4. Port: 접속 포트로, 일반적인 웹 서비스에서는 생략 시 프로토콜 기본 포트(80/443)로 연결된다.
5. Path: 리소스의 계층적 경로다. 파일 시스템의 디렉토리 구조와 유사한 형태를 띈다.
6. Query: 웹 서버에 제공하는 파라미터다. ?로 시작하며 key=value 형태를 유지한다. 문자열 형태로 전달되므로 'Query String'이라고도 부른다.
7. Fragment: 문서 내부의 특정 위치(북마크)를 가리킬 때 사용한다. 중요한 점은 서버로 전송되지 않는 정보라는 것이며, 오직 브라우저 내부 제어용으로만 쓰인다.

---

 

 

4. 웹 브라우저 요청 흐름 (Request Workflow)

사용자가 URL을 입력하고 페이지가 렌더링되기까지의 과정은 마치 편지를 써서 우체국을 통해 전달하고 답장을 받는 과정과 흡사하다.

1. URL 입력 및 DNS 조회: 사용자가 URL을 입력하면, 브라우저는 가장 먼저 DNS(Domain Name System) 서버를 찾아가 해당 도메인에 연결된 실제 IP 주소를 알아낸다.
2. HTTP 요청 메시지 생성: 브라우저는 서버에 보낼 메시지를 작성한다. 여기에는 요청 메서드(GET/POST), 경로, 쿼리 파라미터, 헤더 정보가 포함된다.
3. 전송 계층 처리 (Socket): 브라우저는 OS의 Socket 라이브러리를 호출하여 서버와 연결을 시도한다. 이때 3-way handshake를 통해 TCP/IP 연결이 수립된다.
4. 패킷 전송: 생성된 HTTP 메시지는 네트워크 전송을 위해 TCP/IP 패킷으로 캡슐화된다. 여기에는 출발지/목적지의 IP와 포트 정보가 실린다.
5. 서버 수신 및 응답: 서버는 도착한 패킷의 캡슐을 벗겨 HTTP 요청을 해석하고, 그에 맞는 결과(HTML 데이터 등)를 HTTP 응답 메시지에 담아 다시 보낸다.
6. 브라우저 렌더링: 도착한 응답 메시지를 받은 브라우저는 내용을 파싱하여 우리가 보는 화면(HTML)을 렌더링한다.

---

 

 

5. 실무 팁 및 주의사항

• 포트 생략의 원리: 실무에서 포트 번호를 적지 않아도 접속되는 이유는 브라우저가 프로토콜(Scheme)을 보고 http=80, https=443이라는 약속된 포트를 자동으로 할당하기 때문이다.
• 쿼리 파라미터의 타입: 쿼리 파라미터는 모두 문자열로 전달된다. 서버 측에서 숫자 타입이 필요하다면 반드시 별도의 형변환 처리가 필요함을 인지해야 한다.
• 프래그먼트(#) 활용: SPA(Single Page Application)나 긴 기술 문서에서 특정 섹션으로 바로 이동시키고 싶을 때 Fragment를 활용하면 서버 부하 없이 클라이언트 단에서 사용자 경험을 높일 수 있다.

---

 

 

6. 마무리

"URI는 단순한 주소가 아니라, 클라이언트와 서버가 서로를 알아보기 위해 교환하는 가장 정교한 명함이다."

단순히 주소창에 글자를 치는 행위 뒤에는 DNS 조회, 패킷 캡슐화, 네트워크 라우팅이라는 거대한 공학적 흐름이 숨어 있다. 이 구조를 정확히 이해하는 것이 네트워크 장애 디버깅과 효율적인 API 설계의 시작점이다.