URL의 구조

링크를 클릭할 때마다, 당신은 세 가지 서로 다른 시스템에 동시에 명령을 내리고 있습니다.

URL은 주소 체계가 겹겹이 담긴 러시아 마트료시카 인형입니다. 스킴(scheme)은 브라우저에게 어떤 언어로 말해야 할지 알려줍니다. 호스트(host)는 전 세계 DNS 네임스페이스에서 특정 서버를 가리킵니다. 경로(path)는 그 서버가 자체적으로 구성한 내부 네임스페이스에서 무언가를 요청합니다. 세 가지 주소 체계가 구두점 몇 개로 단단히 연결된 것입니다.

각 부분이 실제로 어떤 역할을 하는지 해독해 봅시다.

완전한 URL

가능한 모든 구성 요소를 포함한 URL입니다:

https://user:pass@www.example.com:8080/path/to/resource?key=value&foo=bar#section

각 부분은 하나의 질문에 답합니다:

스킴: 어떻게 연결하나요?

스킴은 맨 앞에 위치하며, 뒤에 ://가 붙습니다. 브라우저가 사용할 프로토콜을 결정합니다:

• https — 암호화된 웹 트래픽 (TLS)
• http — 암호화되지 않은 웹 트래픽
• ftp — 파일 전송
• mailto — 이메일 클라이언트 열기
• file — 컴퓨터의 로컬 파일
• ws/wss — WebSocket 연결

스킴은 기본 포트도 암묵적으로 정합니다. https://example.com을 방문하면, 브라우저는 별도로 지정하지 않아도 포트 443에 연결합니다.

호스트: 서버는 어디에 있나요?

호스트는 어떤 기계에 연결할지를 식별합니다. 다음 형태 중 하나를 취합니다:

• 도메인 이름: www.example.com
• IPv4 주소: 192.168.1.1
• IPv6 주소: [2001:db8::1] (대괄호 필수)

도메인 이름은 대소문자를 구분하지 않습니다—EXAMPLE.COM과 example.com은 같은 서버에 도달합니다. DNS 시스템은 이 이름들을 브라우저가 실제로 연결할 수 있는 IP 주소로 변환해줍니다.

포트: 어느 문을?

서버는 번호가 매겨진 포트에서 연결을 기다립니다. 포트를 지정하지 않으면 기본값이 적용됩니다:

• HTTP → 포트 80
• HTTPS → 포트 443
• FTP → 포트 21

서버가 비표준 포트에서 실행될 때는 콜론 뒤에 포트를 지정합니다: example.com:8080. 포트 번호는 0에서 65,535 사이입니다.

경로: 무엇을 원하나요?

경로는 서버에서 특정 리소스를 가리킵니다:

/blog/2024/url-anatomy
/api/v2/users/123
/images/logo.png

여기서 주소 체계가 흥미로워집니다. 호스트가 당신을 특정 기계로 안내했습니다. 이제 당신은 그 기계만의 네임스페이스 안에 있습니다—그리고 모든 서버는 저마다 자신만의 네임스페이스를 만듭니다. 어떤 서버는 경로를 디스크의 파일에 연결합니다. 다른 서버는 데이터베이스 쿼리로 보냅니다. 또 다른 서버는 코드가 즉석에서 응답을 생성합니다. 경로의 문법은 모두 같지만, 그 의미는 서버마다 완전히 다릅니다.

도메인 이름과 달리, 경로는 대부분의 서버에서 대소문자를 구분합니다. /About과 /about은 서로 다른 리소스입니다. 경로가 비어 있으면 기본값은 /(루트)입니다.

쿼리: 어떤 조건으로?

쿼리 문자열은 ?로 시작하며, &로 구분된 키-값 쌍을 포함합니다:

?search=urls&category=networking&sort=date

서버는 쿼리 매개변수를 다음과 같은 용도로 사용합니다:

• 검색어: ?q=url+anatomy
• 필터링: ?status=published&year=2024
• 페이지 나누기: ?page=2&limit=20
• 추적: ?utm_source=newsletter

매개변수의 순서는 보통 중요하지 않습니다.

프래그먼트: 자신에게 보내는 메모

프래그먼트는 #으로 시작하며, 페이지 내의 특정 섹션을 가리킵니다:

https://example.com/docs#installation

그런데 여기서 정말 신기한 점이 있습니다: 프래그먼트는 브라우저를 절대 벗어나지 않습니다. 이 URL을 요청하면 서버는 https://example.com/docs만 받고, 사용자가 #installation을 보고 있다는 사실을 전혀 모릅니다. 프래그먼트는 자기 자신에게 전달하는 메모인 셈입니다.

이 특성 덕분에 프래그먼트는 다음 용도에 딱 맞습니다:

• 페이지 섹션으로 연결 (특정 제목으로 스크롤)
• 단일 페이지 앱 라우팅 (서버 요청 없이 화면 전환)
• 서버에 전달되지 않아야 할 클라이언트 측 상태 저장

프래그먼트는 엄밀히 말하면 주소의 일부가 아닙니다. 목적지에 도착한 후 무엇을 할지에 대한 안내입니다.

URL 인코딩

URL에는 특정 ASCII 문자만 사용할 수 있습니다. 그 외의 문자는 퍼센트 인코딩됩니다—문자의 바이트 값을 16진수로 나타내고 앞에 %를 붙이는 방식입니다.

자주 쓰이는 인코딩:

따라서 "URL encoding & special characters"는 다음과 같이 표현됩니다:

?q=URL%20encoding%20%26%20special%20characters

예약 문자인 : / ? # & =는 URL에서 특별한 의미를 가집니다. 각각의 지정된 역할로만 그대로 사용하세요. 데이터로 사용해야 할 때는 반드시 인코딩해야 합니다.

비예약 문자는 인코딩이 필요 없습니다: A-Z a-z 0-9 - _ . ~

절대 URL과 상대 URL

절대 URL은 리소스를 찾는 데 필요한 모든 정보를 포함합니다:

https://www.example.com/path/to/page

상대 URL은 현재 페이지를 기준으로 해석됩니다:

상대 URL 덕분에 사이트는 도메인이 바뀌어도 모든 링크를 다시 작성할 필요가 없습니다.

URL의 인증 정보

URL 명세는 인증 정보 삽입을 지원합니다:

https://user:password@example.com

하지만 이렇게 하지 마세요. 이런 인증 정보는 브라우저 방문 기록, 서버 로그, 리퍼러 헤더에 그대로 노출됩니다. 최신 브라우저도 이에 대해 경고를 표시합니다. 적절한 인증 방식을 사용하세요.

보안 고려사항

프래그먼트를 제외한 모든 것은 서버로 전송되며 로그에 기록될 수 있습니다:

• 브라우저 방문 기록은 전체 URL을 저장합니다
• 서버 로그는 경로와 쿼리 문자열을 기록합니다
• 리퍼러 헤더는 제3자에게 URL을 노출할 수 있습니다

쿼리 매개변수에는 민감한 데이터(토큰, 비밀번호, 개인 정보)를 절대 넣지 마세요. 대신 POST 본문이나 적절한 인증 헤더를 사용하세요.

URL에 관한 자주 묻는 질문

왜 어떤 URL에는 www가 있고 어떤 것은 없나요?

www는 초기 웹에서 생겨난 서브도메인 관례일 뿐, 필수가 아닙니다. example.com과 www.example.com은 같은 서버를 가리킬 수도 있고 서로 다른 서버를 가리킬 수도 있습니다. 대부분의 사이트는 일관성을 위해 하나에서 다른 하나로 리디렉션되도록 설정해 두어 어느 쪽으로 접속해도 됩니다.

URL의 최대 길이는 얼마인가요?

URL 명세 자체는 길이 제한을 두지 않지만, 브라우저와 서버는 제한을 둡니다. Chrome, Firefox 같은 최신 브라우저는 32,000자를 훨씬 넘는 URL도 잘 처리합니다¹. 실제 제한은 보통 서버 측에서 정해집니다—Apache의 기본값은 약 4,000자입니다. 제한에 부딪힌다면 URL에 너무 많은 데이터를 담고 있는 것입니다—POST 요청 사용을 검토하세요.

이메일이나 문서에서 URL을 복사하면 왜 깨지나요?

긴 URL이 줄 바꿈으로 나뉘면서 끊어지는 경우가 많습니다. 공백이 삽입되거나 인코딩이 깨질 수도 있습니다. URL 단축 서비스가 존재하는 이유 중 하나가 바로 이 문제 때문입니다. 특수 문자가 포함된 URL을 공유할 때는 단축기를 이용하거나 URL을 올바르게 인코딩하는 것을 권장합니다.

URL은 대소문자를 구분하나요?

부분적으로 그렇습니다. 스킴과 호스트는 대소문자를 구분하지 않습니다(HTTPS://EXAMPLE.COM도 정상 작동합니다)². 경로, 쿼리, 프래그먼트는 Unix 서버에서 일반적으로 대소문자를 구분합니다. Windows 서버는 구분하지 않을 수 있습니다. 확실하지 않다면 원래 대소문자를 그대로 유지하는 것이 안전합니다.

URL과 URI의 차이는 무엇인가요?

URI(Uniform Resource Identifier)가 더 넓은 개념입니다. URL(Uniform Resource Locator)은 리소스에 어떻게 접근할지를 알려주는 URI로, 스킴과 호스트를 포함합니다. URN(Uniform Resource Name)은 리소스의 위치는 알려주지 않고 이름만 부여하는 URI입니다. 실제로 대부분의 사람은 웹 주소를 그냥 "URL"이라고 부르는데, 충분히 맞는 표현입니다.

출처