웹 개발을 하다 보면 한번쯤은 URL에 한글이나 특수문자를 넣었다가 이상한 문자열로 바뀌는 걸 경험하게 됩니다. 처음에는 당황스럽지만, 이건 URL 인코딩이라는 아주 중요한 메커니즘이 작동한 결과입니다. 오늘은 이 URL 인코딩이 왜 필요한지, 어떤 원리로 작동하는지 하나씩 풀어보겠습니다.
URL 인코딩이란?
URL(Uniform Resource Locator)은 웹에서 자원의 위치를 나타내는 주소입니다. 그런데 URL에는 사용할 수 있는 문자가 제한되어 있습니다. ASCII 문자 중에서도 일부만 허용되고, 한글이나 중국어 같은 비ASCII 문자는 그대로 쓸 수 없습니다. URL 인코딩은 이런 문자들을 URL에서 안전하게 전송할 수 있는 형태로 바꿔주는 과정입니다.
공식적으로는 퍼센트 인코딩(Percent-encoding)이라고 부릅니다. 이름에서 알 수 있듯이 퍼센트 기호(%)를 사용해서 문자를 표현하기 때문입니다.
왜 URL 인코딩이 필요할까?
URL에는 구조적으로 특별한 의미를 가진 문자들이 있습니다. 예를 들어 /는 경로 구분자이고, ?는 쿼리 문자열의 시작을 알리며, &는 파라미터 사이의 구분자입니다. 만약 검색어에 &가 포함되어 있다면? 브라우저는 이걸 파라미터 구분자로 해석해버리겠죠. 이런 혼동을 방지하기 위해 인코딩이 필요합니다.
또 하나의 이유는 국제화입니다. URL 표준은 원래 영어 알파벳 기반으로 설계되었기 때문에, 한글이나 일본어 같은 문자를 직접 넣으면 서버가 제대로 인식하지 못할 수 있습니다. 인코딩을 통해 모든 문자를 안전한 ASCII 형태로 변환하면 이 문제가 해결됩니다.
퍼센트 인코딩의 원리
퍼센트 인코딩 방식은 단순합니다. 인코딩이 필요한 문자를 UTF-8로 변환한 뒤, 각 바이트를 %XX 형식으로 표현합니다. XX는 해당 바이트의 16진수 값입니다.
공백 → %20
"안녕" → %EC%95%88%EB%85%95
"hello world" → hello%20world
한글 "안"은 UTF-8에서 3바이트(EC, 95, 88)로 표현되므로, %EC%95%88이 됩니다. 영어 알파벳이나 숫자처럼 안전한 문자는 인코딩하지 않고 그대로 둡니다.
예약 문자와 비예약 문자
URL에서 사용되는 문자는 크게 두 종류로 나뉩니다.
- 비예약 문자(Unreserved): 인코딩 없이 쓸 수 있는 문자들입니다. A-Z, a-z, 0-9, 그리고
- _ . ~네 가지 특수문자가 여기에 해당합니다. - 예약 문자(Reserved): URL 구조에서 특별한 의미를 가진 문자들입니다.
: / ? # [ ] @ ! $ & ' ( ) * + , ; =등이 있습니다. 이 문자들은 본래의 의미로 쓸 때는 그대로 두지만, 데이터의 일부로 쓸 때는 반드시 인코딩해야 합니다.
JavaScript에서의 URL 인코딩
JavaScript에는 URL 인코딩을 위한 함수가 두 개 있는데, 용도가 다릅니다. 이 차이를 모르면 버그가 생기기 쉽습니다.
encodeURI()는 전체 URL을 인코딩할 때 사용합니다. URL 구조를 유지해야 하므로 : / ? # & 같은 예약 문자는 인코딩하지 않습니다. 반면 encodeURIComponent()는 URL의 개별 파라미터 값을 인코딩할 때 사용하며, 예약 문자까지 전부 인코딩합니다.
encodeURI("https://example.com/검색?q=안녕")
→ https://example.com/%EA%B2%80%EC%83%89?q=%EC%95%88%EB%85%95
encodeURIComponent("key=value&name=test")
→ key%3Dvalue%26name%3Dtest
흔히 하는 실수들
1. 이중 인코딩
이미 인코딩된 문자열을 다시 인코딩하는 실수입니다. %20이 %2520으로 바뀌는 거죠. %의 16진수 코드가 25이기 때문입니다. API를 여러 번 거치는 구조에서 특히 자주 발생합니다. 디버깅할 때 URL을 직접 확인해보면 쉽게 찾을 수 있습니다.
2. encodeURI와 encodeURIComponent 혼동
파라미터 값에 URL이 들어가는 경우가 대표적입니다. redirect URL을 쿼리 파라미터로 전달할 때, encodeURI를 쓰면 내부 URL의 구조가 그대로 남아서 파싱 오류가 발생합니다. 이럴 때는 반드시 encodeURIComponent를 써야 합니다.
3. 서버와 클라이언트의 인코딩 불일치
클라이언트에서 UTF-8로 인코딩했는데 서버가 EUC-KR로 디코딩하면 한글이 깨집니다. 요즘은 대부분 UTF-8을 사용하지만, 레거시 시스템을 다룰 때는 여전히 주의가 필요합니다.
실전 활용 사례
URL 인코딩은 생각보다 많은 곳에서 쓰입니다. API 호출 시 쿼리 파라미터에 사용자 입력을 넣을 때, HTML 폼 데이터를 전송할 때(application/x-www-form-urlencoded), OAuth 인증에서 콜백 URL을 전달할 때, 그리고 파일명에 특수문자가 포함된 다운로드 링크를 만들 때 등 다양합니다.
특히 검색 기능을 구현할 때 주의해야 합니다. 사용자가 검색창에 입력한 한글이나 특수문자가 URL 파라미터로 전달되는 과정에서 제대로 인코딩되지 않으면, 검색 결과가 엉뚱하게 나오거나 아예 서버 오류가 발생할 수 있습니다.
정리
URL 인코딩은 웹의 기본 중에서도 기본입니다. 한번 제대로 이해해두면 API 연동, 폼 처리, 리다이렉트 등 수많은 상황에서 버그를 예방할 수 있습니다. 핵심만 기억하면 됩니다: 비예약 문자는 그대로, 나머지는 퍼센트 인코딩. 파라미터 값에는 encodeURIComponent, 전체 URL에는 encodeURI.