URL에 왜 %20 같은 이상한 문자가 붙을까? (URL 인코딩의 비밀)

인터넷 주소창을 복사해서 메신저로 보낼 때, 한글이 깨져서 %EA%B0%80... 처럼 알 수 없는 문자열로 변환된 경험, 다들 있으시죠?

특히 띄어쓰기는 %20으로 변합니다. 도대체 왜 URL은 있는 그대로의 문자를 쓰지 않고 이렇게 복잡하게 변환하는 걸까요?

이 현상의 정식 명칭은 URL 인코딩 또는 **퍼센트 인코딩(Percent-encoding)**입니다.

1. 인터넷의 초기 규칙: ASCII

인터넷이 처음 만들어지던 시절, 컴퓨터 통신의 표준은 아스키(ASCII) 코드였습니다. 아스키 코드는 영문 대소문자, 숫자, 그리고 일부 특수문자만을 포함하는 7비트 문자 체계입니다.

URL 표준(RFC 3986)은 URL에 사용할 수 있는 문자를 매우 엄격하게 제한했습니다.

Unreserved Characters (비예약 문자): A-Z, a-z, 0-9, -, _, ., ~
Reserved Characters (예약 문자): :, /, ?, #, & 등 (URL의 구조를 나타내는 특수 기능 수행)

이 목록에 없는 문자(한글, 공백, 기타 특수문자 등)를 URL에 포함하려면, 시스템이 이해할 수 있는 아스키 문자 형태로 변환해야만 했습니다.

변환 규칙은 간단합니다.

아스키 코드에서 공백(Space)의 값은 10진수로 32, 16진수로는 20입니다.
따라서 공백은 %20이 됩니다.

한글 '가'는 UTF-8 인코딩에서 3바이트(0xEA, 0xB0, 0x80)를 차지합니다.
따라서 '가'는 %EA%B0%80으로 변환됩니다.

URL 인코딩은 단순히 문자를 표현하는 것을 넘어, 보안과 안정성 측면에서도 중요합니다.

예를 들어, URL 파라미터 값에 &나 = 같은 문자가 포함되어 있다면 어떻게 될까요?
search?query=A&B

시스템은 이것을 query=A와 B(새로운 파라미터)로 오해할 수 있습니다.
이때 &를 %26으로 인코딩하여 search?query=A%26B로 보내면, 시스템은 이를 문자 그대로의 '&'로 올바르게 해석할 수 있습니다.

우리가 보는 %20과 같은 외계어들은 사실 인터넷의 역사와 호환성을 지키기 위한 노력의 산물입니다.

브라우저 주소창은 사용자 편의를 위해 디코딩된 한글을 보여주지만, 실제 네트워크 상으로는 여전히 퍼센트 기호들이 부지런히 오가고 있다는 사실, 기억해 주세요.