URL 인코딩 원리 완벽 가이드: 퍼센트 인코딩 계산 방식과 UTF-8 변환 이해하기

핵심 요약

웹 브라우저는 주소창이나 요청 파라미터에 한글, 공백, 특수문자가 포함될 경우 네트워크 전송 오류를 막기 위해 일정한 규칙으로 문자를 변환한다. 이 과정이 URL 인코딩이며, 퍼센트 기호와 16진수 바이트 조합을 사용하는 퍼센트 인코딩(Percent-Encoding) 표준을 따른다. 본 가이드에서는 문자가 어떤 단계를 거쳐 변환되는지 수학적 구조와 표준 규격을 바탕으로 설명한다.

퍼센트 인코딩 계산 공식과 RFC 3986 표준

초기 웹 디자인 규격인 US-ASCII는 영문자와 일부 기호만을 지원하도록 설계되었다. 따라서 멀티바이트 문자나 제어 문자가 포함되면 서버가 이를 올바르게 해석하지 못한다. 이를 해결하기 위해 IETF는 RFC 3986 표준을 제정하여 아스키 외의 문자와 예약된 특수문자를 안전한 형식으로 변환하는 규칙을 정의했다.

퍼센트 인코딩의 기본 계산 공식은 다음과 같다.

1. 문자를 선택한다.
2. 해당 문자를 특정 문자셋(주로 UTF-8) 바이트 배열로 변환한다.
3. 각 바이트 값을 2자리 16진수(Hexadecimal) 값으로 표현한다.
4. 각 16진수 값 앞에 퍼센트 기호(%)를 붙여 연결한다.

이 과정에서 예약어(Reserved Characters)와 비예약어(Unreserved Characters)를 구분하는 것이 중요하다. 알파벳(A-Z, a-z), 숫자(0-9), 하이픈(-), 마침표(.), 언더바(_), 물결표(~)는 비예약어로 분류되어 인코딩 없이 그대로 유지된다. 그 외의 모든 문자나 공백은 변환 대상이 된다.

실제 문자 변환 예시: 한글 '가'의 바이트 계산 과정

추상적인 설명 대신, 한글 한 글자가 어떤 단계를 거쳐 변환되는지 구체적인 숫자를 대입하여 살펴본다.

• 1단계 (문자 입력): 유니코드 문자 '가'를 준비한다. '가'의 유니코드 코드포인트는 U+AC00이다.
• 2단계 (UTF-8 바이트 변환): UTF-8 인코딩 규칙에 따라 U+AC00은 3개의 바이트로 분할된다. 이진수로 표현하면 11101010 10110000 10000000이 된다.
• 3단계 (16진수 치환): 각 바이트를 16진수로 변환한다. 첫 번째 바이트는 0xEA, 두 번째 바이트는 0xB0, 세 번째 바이트는 0x80이다.
• 4단계 (퍼센트 결합): 각 바이트 앞에 퍼센트 기호를 붙여 %EA%B0%88 형태의 최종 결과물을 완성한다.

이처럼 URL 인코더 / 디코더 같은 도구를 사용할 때 내부적으로는 이런 바이트 연산이 순식간에 수행된다.

결과 해석 및 인코딩 모드 활용 기준

인코딩된 결과물은 웹 서버와 클라이언트 간의 통신 무결성을 보장한다. 다만 어떤 모드를 선택하느냐에 따라 결과가 달라지므로 상황에 맞게 해석해야 한다.

전체 URL 주소를 그대로 보존해야 할 때는 encodeURI 방식을 적용한다. 이 방식은 슬래시나 물음표 같은 구조적 예약어를 유지하므로 브라우저 주소창에 넣어도 경로가 깨지지 않는다. 다만 쿼리스트링 내부의 파라미터 값으로 전달할 때는 encodeURIComponent 방식을 사용하여 모든 특수문자를 엄격하게 변환해야 데이터 유실을 막을 수 있다.

자주 헷갈리는 부분과 실무 주의사항

개발 과정에서 흔히 하는 실수는 쿼리 파라미터 전체를 하나의 URI로 간주해 인코딩하는 것이다. =이나 & 같은 구분자까지 모두 퍼센트 인코딩으로 변환하면 서버가 파라미터를 파싱하지 못한다. 값(Value) 영역과 키(Key) 영역을 분리해 개별적으로 인코딩하는 습관을 들여야 한다.

공백 문자를 처리할 때 RFC 3986 표준인 %20 대신 HTML 폼 규격인 플러스(+) 기호가 섞여 들어오면 디코딩 과정에서 의도치 않은 공백 누락이나 형태 변형이 일어날 수 있으므로 통신 규격을 통일해야 한다.