왜 한글이나 공백을 반드시 인코딩해야 하나요?

인터넷 표준 규약(RFC 3986)에 따르면 URL 주소에는 기본적으로 영문 알파벳, 숫자, 그리고 일부 제한된 기호(ASCII 문자셋)만 사용할 수 있도록 정의되어 있습니다. 한글, 이모지, 공백 등은 이 규칙에 포함되지 않기 때문에, 웹 브라우저와 서버가 이 문자들을 올바르게 인식하고 통신하기 위해서는 허용된 문자열의 조합(퍼센트 기호와 16진수 숫자)으로 변환하는 과정이 필수적입니다.

인코딩 결과에 보이는 % 기호와 숫자들은 무엇을 의미하나요?

이를 '퍼센트 인코딩(Percent-encoding)'이라고 부릅니다. % 기호 뒤에 붙는 두 자리 문자는 해당 원본 문자의 유니코드(UTF-8) 값을 16진수로 표현한 것입니다. 예를 들어 공백은 16진수로 20이기 때문에 '%20'으로 변환되며, 웹 서버는 이 '%20'을 전달받으면 다시 공백으로 해석하여 처리합니다.

공백이 %20이 아니라 + 기호로 변환되는 경우도 있던데 차이가 무엇인가요?

기본적인 웹 표준 URL 인코딩 규칙에서는 공백을 '%20'으로 변환하는 것이 맞습니다. 하지만 HTML 폼(Form) 데이터를 'application/x-www-form-urlencoded' 방식으로 서버에 제출할 때, 역사적인 이유로 공백이 덧셈 기호('+')로 변환되기도 합니다. 최신 웹 개발 환경과 API 통신에서는 혼란을 방지하기 위해 공백을 '%20'으로 통일하여 사용하는 것을 더욱 권장합니다.

URL 인코더/디코더

1. 한글 파라미터는 왜 사라질까?

구글이나 네이버 검색창에 검색을 해보고 검색 결과 페이지의 URL을 복사하여 다른 곳에 붙여넣어 보면, 분명 한글이었던 검색어가 없어지고 %EB%B6%80%EB%8F%99%EC%82%B0과 같은 알 수 없는 문자열로 바뀌는 것을 보실 수 있습니다. 이는 URL이 기본적으로 영어 알파벳, 숫자, 일부 특수문자(ASCII)만 허용하도록 설계된 특징을 가지고 있기 때문입니다. 그 외의 문자(한글, 공백, 이모지 등)는 인터넷망을 타고 전송될 때 웹 표준에 맞게 특수한 형태로 변환(퍼센트 인코딩)되어야만 안전하게 도달할 수 있습니다.

개발하는 입장에서도 이는 꽤 번거로운 문제입니다. 유저가 입력한 검색어나 데이터가 서버로 들어올 때, 사람이 직관적으로 해독하기 어려운 문자열로 변환되어 들어오기 때문에 에러 로그를 확인하거나 디버깅을 할 때 진행이 더뎌집니다.

대충 넘어가기엔 매번 마주치는 문제라 빠른 디버깅과 업무 효율을 위해 손쉽게 문자열을 변환하고 복원할 수 있는 도구를 직접 개발하게 되었습니다. 저 역시 실무에서 서버 로그를 분석하거나 API 요청을 테스트할 때 매일같이 유용하게 사용하고 있습니다.

2. 도구 사용법 및 가이드

간단한 텍스트 입력과 버튼 클릭만으로 안전한 웹 주소 형태를 얻거나, 반대로 읽을 수 없는 주소를 원본 텍스트로 복원할 수 있습니다.

url encode 사용법

a. 인코딩 혹은 디코딩 선택하기

인코딩(Encoding)은 이럴 때 씁니다: 한글, 공백, 특수문자가 포함된 문장을 인터넷 주소창이나 API 요청 파라미터 등에 안전하게 전송하기 위해 규격에 맞는 웹 주소 형태로 바꿀 때 사용합니다.
디코딩(Decoding)은 이럴 때 씁니다: 서버 로그에 찍힌 %EC%95%88 같은 암호화된 문자열이나, 지인에게 전달받은 매우 긴 링크의 실제 내용(원본 한글 등)이 무엇인지 해독하여 읽고 싶을 때 사용합니다.

b. 입력 및 데이터 변환하기

화면 좌측의 텍스트 입력창에 변환하고자 하는 웹 도메인 주소, API 쿼리 스트링(Query String), 혹은 한글 및 특수문자가 포함된 일반 문장을 복사하여 붙여넣습니다. 줄바꿈이나 띄어쓰기가 포함된 긴 텍스트 문서라도 시스템이 자동으로 문맥을 파악하여 변환 처리를 준비합니다. 샘플 버튼을 누르면 인코딩/디코딩이 필요한 예시 텍스트가 자동으로 입력됩니다.

c. 변환 결과 확인 후 데이터 활용하기

입력창에 텍스트를 입력하는 즉시 선택된 모드에 맞춰 우측 결과창에 변환이 완료된 텍스트가 출력됩니다. 한글과 공백이 % 기호와 16진수 영문 숫자의 조합으로 안전하게 변경되었거나, 반대로 원본 텍스트로 깔끔하게 복원된 것을 확인할 수 있습니다.

결과창 우측 상단에 위치한 '복사' 버튼을 클릭합니다. 클릭 즉시 클립보드에 안전하게 저장되므로 바로 원하는 곳에 붙여넣기(Ctrl+V) 하여 활용하시면 됩니다.

3. URL 인코딩에 대해서

a. URL 인코딩의 등장 배경

URL 인코딩이 필요했던 이유는 인터넷의 태생적 한계 때문입니다. 인터넷이 처음 등장하고 URL 표준이 만들어지던 1990년대 초반의 네트워크 장비들은 7비트 영어 알파벳(ASCII)만을 안전하게 전송할 수 있었습니다.

하지만 인터넷이 전 세계로 퍼져나가며 한글, 한자, 아랍어 등 다양한 국가의 언어와 띄어쓰기 등을 URL에 담아야 하는 상황이 왔습니다. 기존의 낡은 네트워크 장비들을 전부 교체하지 않고도 이 문제를 해결하기 위해, 모든 문자를 기존에 호환되던 ASCII 문자(% 기호와 숫자, 알파벳의 조합)로 치환하여 전달하는 '퍼센트 인코딩(Percent-encoding)' 방식이 등장하게 되었습니다.

b. URL에서 허용되는 문자와 예약 문자

인터넷 표준(RFC 3986)은 URL에 사용할 수 있는 문자를 명확하게 구분합니다.

분류	문자	설명
비예약 문자 (Unreserved)	`A-Z` `a-z` `0-9` `-` `.` `_` `~`	인코딩 없이 URL에 그대로 안전하게 사용 가능
예약 문자 (Reserved)	`:` `/` `?` `#` `[` `]` `@` `!` `$` `&` `'` `(` `)` `*` `+` `,` `;` `=`	URL 구조에서 길잡이 역할을 하는 특별한 문자. 단순 데이터 값으로 쓸 때는 인코딩 필수
기타 문자	한글, 공백, `<` `>` `{` `}` 등	URL에 직접 사용 불가. 전송 전 반드시 인코딩 필요

c. 주요 특수문자 퍼센트 인코딩 변환표

실무에서 자주 마주치는 문자들의 인코딩 결과입니다.

원본 문자	인코딩 결과	주요 용도 및 설명
공백 ( )	`%20`	단어 사이 띄어쓰기. 상황에 따라 `+`로 대체되기도 함
`#` (해시)	`%23`	페이지 내 특정 위치(앵커) 이동 시 충돌 방지
`&` (앰퍼샌드)	`%26`	데이터를 묶어주는 구분자와의 충돌 방지
`=` (등호)	`%3D`	키(Key)와 값(Value) 구분자와의 충돌 방지
`?` (물음표)	`%3F`	데이터 전달 시작을 알리는 기호와의 충돌 방지
`/` (슬래시)	`%2F`	폴더 경로 구분자와의 충돌 방지
`+` (더하기)	`%2B`	공백을 대체하는 `+` 기호 자체를 표현할 때 사용
`%` (퍼센트)	`%25`	인코딩 기호인 퍼센트 자체를 문자로 표현할 때
`@` (골뱅이)	`%40`	이메일 주소를 파라미터로 넘길 때 주로 사용
한글 (예: `안`)	`%EC%95%88`	UTF-8 기준 한글 1글자는 보통 3개의 덩어리(바이트)로 변환됨

d. UTF-8 인코딩 과정 — 한글은 왜 길어질까?

한글 한 글자(안)가 왜 %EC%95%88처럼 길게 변환되는지 그 과정을 간단히 살펴보겠습니다.

고유 번호(유니코드) 확인: "안"이라는 글자의 전 세계 공통 번호는 U+C548 입니다.
컴퓨터 언어(UTF-8)로 변환: 이 번호를 컴퓨터가 이해하는 이진수로 쪼개어 담으면 EC, 95, 88 이라는 3개의 조각(바이트)이 나옵니다.
퍼센트 인코딩: 각 조각 앞에 %를 붙여 안전하게 포장합니다 → %EC%95%88

Note

영문 알파벳은 1바이트, 대부분의 유럽 문자는 2바이트, 한글·한자·일본어는 3바이트로 인코딩됩니다. 최근 많이 쓰는 스마트폰 이모지는 4바이트(%F0%9F%98%80 등)로 변환되어 더욱 길어집니다.

4. 실무에서 URL 인코딩/디코딩이 필요한 상황들

코드를 작성할 때뿐만 아니라, IT 실무 전반에서 URL 인코딩/디코딩은 빈번하게 사용됩니다. 구체적으로 어떤 상황에서 필요한지 알아보겠습니다.

a. 마케팅 캠페인 성과 추적 (UTM 파라미터 설정)

광고를 집행하거나 이벤트를 진행할 때, 고객이 어디서 접속했는지 추적하기 위해 링크 뒤에 ?utm_source=네이버&utm_campaign=봄맞이_할인 처럼 데이터를 붙입니다. 이때 한글 캠페인명을 그대로 붙여서 배포하면, 접속하는 브라우저나 앱 환경에 따라 링크가 중간에 끊어지거나 에러 페이지로 연결될 수 있습니다. 캠페인명을 반드시 인코딩하여 배포해야 추적 데이터가 누락되지 않습니다.

b. 로그인 후 원래 페이지로 되돌려 보내기 (리다이렉트 처리)

사용자가 쇼핑몰에서 상품을 구경하다가 결제를 위해 로그인 페이지로 이동하는 상황을 떠올려 보세요. 로그인이 끝나면 다시 보던 상품 페이지로 돌려보내야 합니다. 이때 ?return_url=https://shop.com/item?id=123 형태로 주소를 넘기게 되는데, URL 안에 또 다른 URL이 들어가면 구조가 깨져버립니다. 내부로 전달할 목적지 URL 전체를 안전하게 인코딩해서 넘겨야 충돌이 발생하지 않습니다.

c. 외부 API 연동 및 데이터 전송

지도 서비스 API나 날씨 API에 "제주특별자치도"라는 검색어를 넘겨 데이터를 받아와야 할 때, 원본 한글 텍스트를 통신망에 그대로 던지면 상대방 서버가 글자를 깨진 상태로 받아 에러를 뱉어냅니다. 외부 시스템과 통신할 때는 항상 약속된 표준 규격(인코딩된 문자열)으로 데이터를 정제해서 요청을 보내야 합니다.

d. 백엔드 서버 로그 분석 및 고객 CS 처리

서버 관리자나 데이터 분석가는 매일 수많은 방문자 로그를 확인합니다. 사용자가 검색창에 '강남 맛집'을 검색하고 에러가 발생했다면, 서버 로그에는 q=%EA%B0%95%EB%82%A8+%EB%A7%9B%EC%A7%91 이라고 남습니다. CS 직원이 사용자 불만을 접수하고 개발자에게 로그를 전달했을 때, 이 암호 같은 글자만 보고는 어떤 검색어에서 문제가 터졌는지 알 수 없습니다. 디코더를 활용해 원래 텍스트로 복원해야만 정확한 상황 파악과 조치가 가능해집니다.

5. 생각해볼 거리

URL은 왜 처음부터 모든 언어(유니코드)를 지원하도록 설계되지 않았을까요?

URL 표준이 처음 정의된 1994년에는 인터넷이 철저히 영어권 중심이었고, 전 세계 언어를 통합하는 '유니코드' 자체도 아직 걸음마 단계였습니다. 이후 글로벌 시대에 맞춰 유니코드를 직접 쓸 수 있는 새로운 식별자 체계(IRI)가 제안되긴 했으나, 전 세계에 이미 깔려버린 수많은 구형 네트워크 장비와 서버들과의 호환성 문제 때문에 현실적으로는 여전히 퍼센트 인코딩에 의존할 수밖에 없는 상황입니다.

개발 언어(JS 등)에서 인코딩 함수가 여러 개로 나뉘어 있는 이유는 무엇인가요?

URL에는 http://나 ?처럼 '구조를 나타내는 문자'와 실제 '데이터(검색어 등)'가 공존합니다. 주소 전체를 통째로 인코딩할 때 구조를 나타내는 기호까지 변환해버리면 웹 브라우저가 주소를 인식하지 못합니다. 반대로 데이터 부분만 인코딩할 때는 구조 기호와 헷갈리지 않게 모든 특수기호를 변환해야 합니다. 즉, '주소 전체를 다룰 때'와 '특정 데이터 값만 다룰 때'의 목적이 완전히 다르기 때문에 용도에 맞게 함수가 분리되어 있는 것입니다.

URL을 인코딩하면 길이가 크게 늘어나는데 문제는 없나요?

표준 원칙상 제한은 없지만, 현실의 브라우저와 서버들은 한계가 있습니다. 크롬(Chrome)은 넉넉하지만 구형 브라우저나 특정 서버(Apache, Nginx 등)는 기본 설정이 수천 바이트 정도로 제한되어 있기도 합니다. 한글 한 글자가 인코딩을 거치면 무려 9자(%XX%XX%XX)로 늘어나기 때문에, 수백 자가 넘는 긴 한글 텍스트나 본문 데이터를 URL 파라미터로 넘기면 서버에서 잘리거나 거부될 수 있습니다. 이렇게 긴 데이터는 URL에 노출되는 GET 방식 대신, 본문에 숨겨 보내는 POST 방식을 사용하는 것이 안전합니다.