한글 도메인과 퓨니코드란? 가짜 주소를 구별하는 방법

한글 주소를 복사했는데 xn--로 시작하는 낯선 문자열이 나왔다면, 주소가 바뀌었다고 생각하기 쉽습니다. 주소나와도 주소나와.com과 xn--910bm53aiqd67c.com이라는 두 표기를 씁니다. 둘은 같은 도메인입니다. 퓨니코드 확인에서 중요한 것은 낯선 영문을 찾아내는 일이 아니라, 내가 받은 주소와 공식 주소가 실제로 같은 이름인지 대조하는 일입니다.

한글 도메인은 국제화 도메인의 한 종류입니다

도메인은 사이트를 찾을 때 쓰는 이름입니다. 영문 알파벳과 숫자로만 이름을 지어야 한다면 한글 상호나 지역 이름을 그대로 쓰기 어렵습니다. 이 불편을 줄이기 위해 한글·중국어·아랍 문자 등도 도메인 이름에 쓸 수 있도록 만든 체계가 국제화 도메인(IDN, Internationalized Domain Name)입니다.

사람에게는 읽기 쉬운 문자를 보여주고, 이름을 조회하는 과정에서는 기존 체계와 호환되는 ASCII 표기로 처리합니다. 한글 이름을 영문으로 번역하거나 발음대로 바꾸는 것은 아닙니다. 주소나와가 jusonawa가 되는 방식이 아니라, 정해진 규칙으로 별도의 문자열이 만들어집니다.

다만 모든 유니코드 문자를 마음대로 등록할 수 있는 것은 아닙니다. 국제화 도메인 처리 규칙과 각 도메인 등록 정책에 따라 허용되는 문자가 다릅니다. 화면에서 그럴듯한 이름을 만들었다고 실제 등록 가능한 주소가 되는 것도 아닙니다.

퓨니코드는 암호가 아니며, xn--는 위험 표시가 아닙니다

퓨니코드(Punycode)는 유니코드 문자열을 ASCII 문자로 표현하는 인코딩 방식입니다. 국제화 도메인에서는 문자 처리와 유효성 확인 규칙인 IDNA와 함께 사용됩니다. 세부 계산법을 외울 필요는 없습니다. 한글 같은 문자를 인터넷 주소 체계에서 다룰 수 있는 형태로 바꾼다는 점만 이해하면 됩니다.

도메인은 점으로 나눈 각 부분을 따로 처리합니다. 이런 한 부분을 레이블이라고 하며, 국제화 도메인의 ASCII 레이블에는 xn--가 붙습니다. 주소나와.com에서는 한글 부분이 변환되고 .com은 그대로 남습니다. 주소 전체나 본문의 한글까지 한꺼번에 바꾸는 기능이 아닙니다.

퓨니코드는 비밀을 숨기는 암호화가 아닙니다. 규칙에 맞는 값은 다시 문자로 풀어볼 수 있습니다. 반대로 xn-- 뒤에 아무 글자나 붙인다고 유효한 도메인이 되지는 않습니다. 변환 오류가 난 값을 억지로 읽어내기보다 공식 주소를 다시 확보하는 편이 낫습니다.

주소나와의 한글 주소와 영문 표기는 같은 이름입니다

주소나와 링크를 메신저로 보냈을 때 상대방 화면에 긴 영문이 나타났다고 가정해 보겠습니다. 먼저 아래 표와 비교하면 됩니다. 한글 표기를 ASCII로 바꾼 값이 정확히 같다면, 이름이 변조된 것이 아니라 표시 방식만 달라진 것입니다.

브라우저 주소창에서는 한글이 보이고, 복사한 링크나 일부 관리 도구에서는 아래쪽 문자열이 보일 수 있습니다. 이 표기 차이 자체는 리디렉션이 아닙니다. 다른 도메인으로 이동했는지는 변환한 호스트명을 비교해야 판단할 수 있습니다.

여기서 같다고 확인한 범위는 도메인 이름까지입니다. /address/와 /sites/는 같은 도메인 안의 서로 다른 경로이고, http와 https는 접속 방식이 다릅니다. 주소 전체가 낯설다면 우선 이름과 경로를 나눠보세요. URL 구조를 읽는 방법에서 각 부분의 위치를 확인할 수 있습니다.

비슷한 주소는 세 가지 방식으로 눈을 속입니다

1. 다른 문자를 같은 글자처럼 보이게 하기

라틴 문자 a와 키릴 문자 а는 글꼴에 따라 거의 같아 보입니다. 하지만 앞의 문자는 U+0061, 뒤의 문자는 U+0430으로 서로 다릅니다. 이런 시각적 유사성을 이용하는 방식을 유사문자 공격 또는 호모그래프 공격이라고 부릅니다.

한글 사이트 이름 옆에 익숙한 영문 서비스명이 붙어 있을 때도 같은 문제가 생깁니다. 한글 부분만 읽고 나머지를 훑어보면 다른 문자로 만든 영문 모양을 놓치기 쉽습니다. 공격의 요점은 반드시 여러 언어를 섞는 데 있지 않습니다. 한 문자 체계 안의 글자들만으로도 다른 이름처럼 보이게 할 수 있습니다.

2. 철자나 끝부분을 조금 바꾸기

한 글자를 빼거나 순서를 바꾸고, 숫자 0을 영문 o처럼 보이게 만드는 방식은 별개입니다. 모두 ASCII 문자만으로 구성된 주소라면 퓨니코드로 바꿔도 눈에 띄는 변화가 없습니다. xn--가 없으니 안전하다는 결론이 틀리는 이유입니다.

한글 이름이 정확해도 .com 대신 다른 끝부분이 붙었다면 별도 도메인입니다. 업체가 여러 도메인을 함께 쓰기도 하므로, 이 경우에는 대표 홈페이지에서 추가 주소를 안내하는지 확인하면 됩니다. 이름이 닮았다는 이유만으로 같은 업체라고 넘기지 마세요.

3. 익숙한 이름을 주소 앞이나 경로에 끼워 넣기

주소나와.com.example.org에는 주소나와라는 이름이 들어 있지만, 예시의 등록 도메인은 example.org입니다. example.org/주소나와.com에서는 익숙한 이름이 아예 경로에 있습니다. 어느 쪽도 앞부분의 이름을 공식 사이트라는 근거로 삼을 수 없습니다.

이 두 주소는 구조 설명용이며 접속 링크로 제공하지 않습니다. 실제 주소에서도 ‘공식 이름이 포함됐는가’보다 ‘그 이름이 호스트명의 어느 위치에 있는가’를 봐야 합니다. .co.kr처럼 여러 부분으로 된 공용 접미사도 있으므로 무조건 마지막 두 덩어리만 읽는 방식은 피하세요.

브라우저가 한글로 보여준다고 안전 판정을 받은 것은 아닙니다

브라우저는 국제화 도메인을 읽기 쉽게 보여주면서 유사문자 혼동도 줄여야 합니다. Chromium의 공개 문서는 레이블별로 문자 구성과 혼동 가능성 등을 검사해 유니코드 또는 퓨니코드로 표시하는 정책을 설명합니다. 모든 국제화 도메인을 항상 한글로 표시하거나 항상 영문으로 표시하는 단순한 방식이 아닙니다.

브라우저 종류와 버전, 앱 안의 웹뷰, 표시 위치에 따라 결과가 다를 수 있습니다. 검색 결과 제목은 한글인데 주소창에는 xn--가 보이는 상황도 이상하다고 단정할 수 없습니다. 제목·링크 문구·실제 목적지 주소는 서로 다른 정보입니다.

브라우저가 한글을 그대로 보여주는 것은 그 표기를 허용했다는 뜻이지 운영자를 보증했다는 뜻은 아닙니다. 반대로 퓨니코드를 보여줬다고 악성으로 확정한 것도 아닙니다. 표시 정책은 보조 장치로 두고, 로그인이나 결제 전에는 알고 있던 공식 주소와 대조하세요.

퓨니코드 확인 5단계: 기준 주소부터 대조 결과까지

1단계: 의심스러운 화면 밖에서 기준 주소를 찾습니다

비교할 기준부터 있어야 합니다. 평소 사용하던 공식 앱, 이전에 확인해 저장한 북마크, 독립적으로 확인한 기관 안내에서 대표 주소를 확보하세요. 의심스러운 문자에 함께 적힌 ‘공식 홈페이지’나 그 페이지의 고객센터 안내는 같은 출처이므로 기준으로 쓰기 어렵습니다.

예를 들어 회원정보를 다시 확인하라는 메일을 받았다면, 메일 하단의 홈페이지 링크를 기준으로 삼지 않습니다. 평소 쓰던 앱의 서비스 안내나 미리 저장해 둔 주소를 꺼냅니다. 기준 주소까지 같은 메일에서 가져오면 잘못된 두 값을 서로 비교하는 셈입니다.

2단계: 보이는 글자가 아니라 링크 주소를 복사합니다

링크에 적힌 서비스명을 드래그해 복사하는 것과 ‘링크 주소 복사’는 다릅니다. 전자는 표시 문구만 가져올 수 있습니다. 접속 전이라면 링크 메뉴에서 목적지 주소를 복사해 로컬 메모장에 붙여 넣으세요. 브라우저 주소창에 붙인 뒤 엔터를 누르는 방식으로 검사하지 않습니다.

이미 열었다면 입력을 멈추고 주소창의 전체 주소를 확인합니다. 처음 받은 링크와 이동 후 주소가 다를 수도 있습니다. 중간 경로를 구분해야 하는 상황은 링크의 실제 목적지 확인법을 참고하세요. 확인을 위해 의심 사이트를 새로 방문할 필요는 없습니다.

3단계: 비교할 호스트명만 분리합니다

일반적인 https://호스트명/경로 형태라면 호스트명을 따로 적습니다. 예를 들어 https://주소나와.com/address/에서는 주소나와.com이 대상입니다. @나 포트, 낯선 구문이 섞여 경계가 불분명하면 앞부분을 임의로 도메인이라고 가정하지 말고 공식 경로로 돌아가세요.

단축 링크에서 복사한 호스트명은 단축 서비스의 이름일 뿐 최종 사이트 이름이 아닙니다. 그 값을 변환해도 숨은 목적지가 드러나지는 않습니다. 이때 필요한 작업은 단축 URL의 목적지 확인입니다.

4단계: 두 호스트명을 같은 ASCII 표기로 맞춥니다

국제화 도메인을 지원하는 신뢰할 수 있는 IDNA 변환 도구에서 공식 호스트명과 확인 대상 호스트명을 각각 ASCII로 변환합니다. 한쪽이 한글이고 다른 쪽이 xn--인 상태로 눈대중 비교하지 않는 것이 핵심입니다. 같은 도구와 같은 처리 기준을 사용하고 결과 전체를 대조하세요.

결과는 메모장에 두 줄로 놓고 비교하면 편합니다. 첫 줄에는 공식 호스트명의 ASCII 값, 둘째 줄에는 받은 호스트명의 ASCII 값을 적으세요. 긴 문자열의 앞부분만 맞춰보지 말고 점과 하이픈, 끝부분까지 확인합니다.

ASCII 도메인의 영문 대소문자는 구별하지 않습니다. 다만 하이픈을 지우거나 익숙한 철자로 고쳐 적으면 비교할 원본을 잃습니다. 복사한 값은 그대로 남겨두세요. 변환값이 다르면 차이가 생긴 위치를 확인하고, 이유를 알기 전에는 같은 호스트명으로 취급하지 않습니다.

5단계: 중요한 작업은 확인된 공식 경로에서 다시 시작합니다

이름이 일치하면 ‘도메인 철자가 다른가’라는 질문 하나를 해결한 것입니다. 페이지 내용, 계정 상태, 다운로드 파일의 안전성까지 검사한 것은 아닙니다. 비밀번호 재설정이나 결제 요청이었다면 확인된 앱이나 대표 주소로 직접 들어가 같은 요청이 실제로 있는지 살펴보세요.

PC와 모바일에서는 복사한 값부터 확인하세요

PC에서는 링크를 오른쪽 클릭해 주소 복사 메뉴를 찾을 수 있습니다. 현재 페이지라면 주소창을 선택해 전체 주소를 복사합니다. 메뉴 이름은 브라우저마다 조금 다릅니다. 메모장에 붙여 넣은 값이 서비스명 한 줄뿐이라면 주소가 아니라 표시 문구를 복사했을 가능성을 먼저 보세요.

모바일에서는 링크를 길게 눌러 주소 복사 메뉴를 찾는 경우가 많지만, 일부 앱은 미리보기를 불러오거나 자체 공유 링크로 바꿉니다. ‘공유’로 얻은 값이 원래 목적지와 같다고 가정하지 마세요. 복사 기능이 없거나 전체 주소가 잘려 보이면 억지로 열어 확인하지 않고 공식 앱에서 해당 알림을 찾으면 됩니다.

붙여 넣어도 한글이 그대로 남을 수 있습니다. 복사하면 반드시 퓨니코드가 드러난다는 설명은 정확하지 않습니다. 글자 확대는 위치와 철자를 보는 데 도움이 되지만, 서로 다른 문자 코드를 판별하는 방법을 대신하지는 못합니다.

같은 주소와 닮은 주소를 표로 대조해 보세요

표에서는 익숙한 이름이 아니라 호스트명 전체와 점의 위치를 따라 읽어보세요. example.org는 설명용 예약 도메인입니다. 다른 끝부분을 붙인 주소도 비교 예시이며 실제 운영 여부와는 무관합니다.

www가 붙은 경우는 어떨까요? www.주소나와.com은 주소나와.com과 호스트명이 다르지만 같은 등록 도메인 아래에 있습니다. 두 주소를 같은 페이지로 연결할지는 운영 설정에 달려 있습니다. 단순히 www를 지워서 일치시킬 것이 아니라, 공식 안내에서 어느 호스트명을 쓰는지 확인하세요.

메일·검색·로그인에서는 무엇을 비교해야 할까요?

원리는 이해했어도 화면이 바뀌면 확인할 위치가 헷갈립니다. 다음은 실제 피해 사례를 인용한 것이 아니라, 주소를 확인하는 과정을 설명하기 위해 구성한 상황입니다.

메일의 한글 상호와 링크 목적지가 다를 때

예약 확인 메일에 익숙한 한글 상호가 적혀 있고, 버튼에는 ‘예약 내역 보기’라고 표시되어 있습니다. 여기서 상호를 복사해 변환하면 메일 작성자가 적은 문구만 확인하게 됩니다. 비교 대상은 버튼에 연결된 주소의 호스트명입니다.

버튼 주소가 예약 대행사의 도메인이라면 상호와 다르다는 사실만으로 가짜라고 확정하지 않습니다. 원래 예약한 앱에 같은 내역이 있는지 확인하면 대행 관계를 추측하느라 시간을 쓰지 않아도 됩니다. 링크를 꼭 열어야만 예약을 확인할 수 있는 것은 아닙니다.

검색 결과는 한글인데 복사한 값이 길어졌을 때

검색 결과의 사이트명과 주소는 따로 봅니다. 사이트명이 정확하더라도 링크가 검색 서비스의 이동용 주소로 복사됐다면 그 호스트명을 변환해 봐야 검색 서비스 이름만 나옵니다. 목적지를 아직 확인하지 못한 상태입니다.

반면 호스트명이 xn--로 시작하는 값으로 복사됐다면 기준 주소를 같은 표기로 맞춰 대조할 수 있습니다. ‘길어졌다’는 현상은 같아도, 중간 이동 링크와 국제화 도메인 표기는 원인이 다릅니다. 문자열 길이보다 무엇이 호스트명인지부터 구분하세요.

로그인 화면에서 한글 이름은 맞는데 끝부분이 다를 때

로그인 화면에 익숙한 로고가 보이고 도메인의 한글 부분도 같습니다. 그런데 평소 주소와 달리 끝부분이 바뀌어 있습니다. 퓨니코드를 한글로 풀어 이름이 잘 읽히는지 확인하는 것만으로는 이 차이를 해결하지 못합니다. 접미사까지 포함한 별개의 등록 도메인이기 때문입니다.

새 로그인 주소를 도입했을 가능성은 공식 서비스의 공지에서 확인합니다. 그 화면에 적힌 ‘주소가 변경되었습니다’라는 설명 자체를 근거로 삼지는 않습니다. 기존 앱에서 로그인할 수 있다면 그쪽으로 진행하는 것이 간단합니다.

변환 도구에 넣을 값과 결과가 다른 이유

개인 링크 전체가 아닌 호스트명만 사용합니다

공개 변환기에 비밀번호 재설정 링크나 초대 링크 전체를 넣을 필요는 없습니다. 경로와 물음표 뒤에는 개인 문서 식별자나 일회용 토큰이 들어갈 수 있습니다. 도메인 표기를 비교하는 목적이라면 호스트명만 사용하고, 비공개 업무 시스템의 호스트명도 외부 공유가 허용되는지 먼저 확인하세요.

‘Punycode 변환’이라는 이름의 도구가 모두 같은 처리를 하는 것도 아닙니다. 문자열의 인코딩만 수행하는 도구와 IDNA 유효성 검사·문자 처리를 함께 하는 도구는 역할이 다릅니다. 특수한 문자에서 결과가 엇갈리거나 오류가 발생하면 편한 결과를 골라 믿지 말고, 공식 호스트명을 다시 확인하세요.

변환기는 이름의 표기를 바꾸는 도구입니다. 도메인 등록 여부나 소유자, 페이지의 악성코드 유무는 별도 확인 대상입니다. 결과 화면의 한글을 읽고 끝내기보다, 처음 준비한 기준 주소와 대조하는 데 사용하세요.

한글의 조합 방식과 문자 정규화도 영향을 줍니다

한글 음절 하나가 내부적으로 항상 문자 코드 하나로만 표현되는 것은 아닙니다. 예를 들어 ‘가’는 완성된 음절 U+AC00으로도, 조합용 자모 U+1100과 U+1161의 연속으로도 표현할 수 있습니다. 이런 정규적으로 동등한 표현은 적절한 정규화 과정에서 같은 형태로 맞춰집니다.

따라서 원문 코드가 다르다는 사실만으로 한글 위장 공격이라고 단정해서는 안 됩니다. 이것은 앞서 본 라틴 a와 키릴 а처럼 단지 모양이 닮은 별개 문자와 구분할 문제입니다. 한글 자모를 손으로 합치거나 고치기보다 IDNA 처리를 지원하는 같은 도구로 양쪽을 비교해야 하는 이유입니다.

대조가 끝나면 결과에 따라 행동을 나누세요

대조 결과를 메모할 때는 ‘비슷함’ 대신 차이가 난 위치를 적어보세요. 기준 주소, 받은 호스트명, 각각의 ASCII 변환값을 나누어 놓으면 무엇을 확인했는지 다시 짚기 쉽습니다. 이름 한 글자가 다른지, 끝부분이 다른지, 앞에 하위 도메인이 붙었는지에 따라 확인할 내용도 달라집니다. 비교용 메모에는 계정 이름이나 인증번호를 함께 적을 필요가 없습니다.

고객센터에 문의한다면 ‘이 사이트 안전한가요?’라고만 묻기보다 ‘공식 앱에서 안내한 주소와 받은 링크의 호스트명이 다른데, 이 연결을 제공하나요?’처럼 차이를 설명하는 편이 좋습니다. 연락처는 의심스러운 페이지가 아니라 기존에 확인한 앱이나 계약 안내에서 찾으세요. 답변을 기다리는 동안 해당 화면에서 결제를 진행하거나 인증번호를 입력하지 않습니다.

같은 등록 도메인 아래에 있다는 답을 얻어도 작업의 목적은 한 번 더 살펴볼 만합니다. 문서 조회를 하려던 중인데 갑자기 프로그램 설치를 요구한다면, 도메인 철자와는 다른 문제입니다. 반대로 예상한 외부 결제사로 넘어간 경우에는 주소가 다르다는 이유만으로 오류라고 볼 필요가 없습니다. 서비스가 그 연결을 안내하고 있는지와 요청한 업무가 이어지는지를 함께 봅니다.

확인한 대표 주소를 북마크로 저장해 두면 다음에는 긴 문자열을 처음부터 비교하는 수고를 줄일 수 있습니다. 이때도 받은 링크를 바로 저장하기보다는 검증한 대표 홈페이지를 저장하세요. 특정 예약이나 일회용 로그인 링크는 시간이 지나면 만료될 수 있어 기준 주소로 쓰기 어렵습니다. 다음 방문의 출발점을 정리하는 것까지가 이번 확인을 일회성으로 끝내지 않는 방법입니다.

• 같은 ASCII 호스트명으로 확인됐다면: 표기 차이는 해소된 것입니다. 민감한 작업은 확인된 공식 앱이나 대표 주소에서 이어갑니다.
• 글자·접미사·등록 도메인이 다르다면: 입력을 멈춥니다. 외부 로그인·결제 서비스라면 해당 연결을 공식 서비스가 안내하는지 독립적으로 확인합니다.
• 변환 오류가 나거나 기준 주소를 모르겠다면: 안전하다고 판정할 근거가 부족합니다. 받은 링크에서 작업을 계속하지 않습니다.
• 이미 비밀번호나 결제 정보를 입력했다면: 문자 분석보다 계정 보호와 피해 대응이 먼저입니다. 공식 경로에서 비밀번호를 변경하고, 결제 피해가 의심되면 금융회사에 신속히 연락합니다.

로그인 유도, 긴급 문구, 개인정보 요구까지 함께 점검하려면 피싱 사이트 구별법 7가지를 이어서 읽으세요. 퓨니코드는 그중 ‘이 주소가 내가 알고 있는 이름인가’를 확인하는 도구입니다. 주소 구조부터 차례로 살펴보고 싶다면 주소모음 가이드에서 필요한 주제를 골라볼 수 있습니다.

공식 참고 자료

• IETF RFC 3492 — Punycode 인코딩 규격
• Chromium — 국제화 도메인 처리와 표시 정책
• Unicode UTS #39 — 유사문자 등 유니코드 보안 메커니즘
• Unicode UAX #15 — 문자 정규화와 한글 조합

최종 내용 검토일: 2026년 9월 7일
브라우저의 메뉴와 주소 표시 방식은 업데이트에 따라 달라질 수 있습니다. 설명과 다른 사례는 개인 식별 정보가 포함된 경로·매개변수를 제외하고 문의·권리침해 안내로 알려주세요.