URL 인코딩 — 한글 주소가 %EC처럼 바뀌는 이유

카카오나 네이버 검색 API에 서울 맛집을 그대로 붙였더니 요청이 깨지는 경우가 있습니다. 주소창에서는 한글이 보이지만, 실제 URL 안에서는 안전한 문자로 바뀌어 전달되어야 합니다.

URL 인코더 바로 사용하기 →

URL 인코딩은 한글, 공백, 특수문자를 %EC%84%9C처럼 퍼센트 기호와 16진수로 바꾸는 방식입니다. 퍼센트 인코딩이라고도 부릅니다. 한글 "서"는 컴퓨터 내부에서 3바이트로 저장되는데(UTF-8, 전 세계 문자를 바이트로 저장하는 표준 규칙), 그 바이트 하나하나를 % 뒤에 16진수(0~9와 A~F로 수를 적는 표기법)로 적으면 %EC%84%9C가 됩니다. 그래서 한글 한 글자가 % 코드 세 개로 늘어납니다.

도구에서 직접 변환해 보기

URL 인코더 페이지에서 순서대로 해 보세요.

1. "URL to Encode"라고 적힌 입력칸에 서울 맛집을 입력합니다.
2. 아래 "Encode URL" 버튼을 누릅니다.
3. 초록색 결과 상자에 %EC%84%9C%EC%9A%B8+%EB%A7%9B%EC%A7%91이 나타납니다. 오른쪽 "Copy"를 누르면 복사됩니다.

공백이 %20이 아니라 +로 나온 점이 눈에 띌 겁니다. 오류가 아닙니다. 웹 폼 전송 방식에서는 공백을 +로 적는 것이 규칙이고, 이 도구는 그 방식을 따릅니다. JavaScript의 encodeURIComponent는 같은 입력을 %EC%84%9C%EC%9A%B8%20%EB%A7%9B%EC%A7%91처럼 %20으로 바꿉니다. 쿼리스트링 값에서는 서버가 두 표기를 모두 공백으로 해석하므로 어느 쪽이든 동작합니다.

되돌릴 때는 URL 디코더를 씁니다. "URL to Decode" 칸에 인코딩된 문자열을 넣고 "Decode URL"을 누르면 서울 맛집으로 돌아옵니다.

왜 인코딩이 필요한가

URL에는 역할이 정해진 문자가 있습니다. ?는 쿼리스트링 시작, &는 파라미터 구분, =는 이름과 값을 나누는 기호입니다. 검색어 자체에 &가 들어 있는데 인코딩하지 않으면 서버는 그것을 값이 아니라 구분자로 오해합니다.

예를 들어 검색어가 A&B 할인이라면 그대로 넣으면 문제가 생깁니다.

잘못된 예: /search?q=A&B 할인
올바른 예: /search?q=A%26B%20%ED%95%A0%EC%9D%B8

&를 %26으로 바꿔 두면 서버는 그것을 구분자가 아니라 검색어의 한 글자로 정확히 읽습니다. 반대로 알파벳, 숫자, -, _, . 같은 문자는 원래 안전한 문자라서 인코딩해도 그대로 남습니다.

encodeURI와 encodeURIComponent 차이

JavaScript에서는 두 함수를 많이 씁니다.

API 검색어, 제목, 카테고리처럼 "값"을 넣을 때는 보통 encodeURIComponent가 맞습니다. URL 전체를 이미 만들어 둔 뒤 사람이 보기 좋게 보정할 때는 encodeURI를 씁니다.

const keyword = "서울 맛집 & 카페";
const url = "/search?q=" + encodeURIComponent(keyword);

디코딩은 언제 쓰나

서버 로그나 분석 도구에서 %EC%84%9C%EC%9A%B8 같은 문자열을 보면 사람이 읽기 어렵습니다. 이때 URL 디코더를 쓰면 원래 한글로 되돌릴 수 있습니다.

다만 디코딩한 문자열을 그대로 HTML에 출력하면 보안 문제가 생길 수 있습니다. URL 인코딩은 전송용 규칙이지, XSS 같은 웹 보안을 대신해 주지 않습니다. 화면에 출력할 때는 HTML 이스케이프를 별도로 처리해야 합니다.

초보가 자주 막히는 지점

가장 흔한 실수는 이미 인코딩된 문자열을 또 인코딩하는 것입니다. %EC%84%9C를 다시 인코딩하면 % 기호 자체가 %25로 바뀌어 %25EC%2584%259C처럼 됩니다. 이런 이중 인코딩 값은 디코더에 한 번 넣어도 한글이 아니라 %EC%84%9C 같은 코드가 나옵니다. 당황하지 말고 디코더를 한 번 더 돌리면 원문이 나옵니다. 만들 때는 값을 딱 한 번만 인코딩한다는 원칙을 지키세요.

주소창에서 복사한 URL이 갑자기 % 투성이로 바뀌는 경우도 있습니다. 브라우저 주소창은 사람이 읽기 좋게 한글로 보여줄 뿐, 내부적으로는 이미 인코딩된 상태입니다. 복사하는 순간 그 원형이 드러나는 것이므로 링크 자체는 정상입니다.

한국어 서비스에서 자주 생기는 실수

국내 서비스는 검색어, 주소, 상품명에 한글이 자주 들어갑니다. 네이버 스마트스토어 상품명, 카카오맵 장소명, 블로그 글 제목을 URL 파라미터로 넘길 때 인코딩을 빼먹으면 일부 글자만 깨지거나 파라미터가 잘립니다.

규칙은 단순합니다. URL의 구조는 그대로 두고, 사용자가 입력한 값은 따로 인코딩하세요. 이 한 가지를 지키면 대부분의 한글 URL 오류를 피할 수 있습니다.

자주 묻는 질문

인코딩하면 내용이 암호화되나요

아닙니다. 규칙에 따라 표기만 바꾼 것이라 누구나 디코더로 원문을 볼 수 있습니다. 개인정보나 비밀 값을 URL에 실어 보내면 인코딩 여부와 관계없이 노출됩니다.

한글 도메인 주소도 이 방식으로 바뀌나요

경로와 쿼리스트링의 한글은 퍼센트 인코딩을 쓰지만, 도메인(주소의 앞부분) 자체는 퓨니코드라는 별도 규칙으로 변환됩니다. 이 도구는 경로와 파라미터 값을 다룰 때 쓰는 것이 맞습니다.

+와 %20 중 뭘 써야 하나요

쿼리스트링 값에서는 둘 다 공백으로 해석되므로 어느 쪽이든 됩니다. 다만 경로 부분(도메인 뒤, ? 앞)에서는 +가 공백으로 해석되지 않을 수 있어 %20이 안전합니다.