같은 글자인데 코드가 두 가지입니다
'한'이라는 글자는 유니코드에 두 가지 방식으로 표현할 수 있습니다. 완성형(NFC)은 한 글자를 코드 하나(U+D55C)로 저장하고, 조합형(NFD)은 초성·중성·종성 자모 세 개(U+1112 U+1161 U+11AB)를 이어 붙여 저장합니다. 화면에서는 글꼴이 자모를 합쳐 그리기 때문에 둘이 똑같아 보이지만, 문자열로는 서로 다른 값입니다. 파일 이름이나 복사한 텍스트가 조합형이면 일부 프로그램은 합쳐 그리지 못하고 "ㅎㅏㄴ"처럼 풀어 보여 주며, 검색·비교·정렬에서도 어긋납니다. 이 도구의 NFC 변환은 브라우저에 내장된 유니코드 정규화(String.normalize)를 호출하며, 한글은 표준에 정의된 계산식으로 자모 열을 음절 하나로 합칩니다.
| 글자 | NFC 코드 | NFD 코드 | NFD 개수 | UTF-8 바이트 (NFC/NFD) |
|---|---|---|---|---|
| 가 | U+AC00 | U+1100 U+1161 | 2 | 3 / 6 |
| 한 | U+D55C | U+1112 U+1161 U+11AB | 3 | 3 / 9 |
| 닭 | U+B2ED | U+1103 U+1161 U+11B0 | 3 | 3 / 9 |
| 똠 | U+B620 | U+1104 U+1169 U+11B7 | 3 | 3 / 9 |
| 의 | U+C758 | U+110B U+1174 | 2 | 3 / 6 |
| A | U+0041 | U+0041 | 1 | 1 / 1 |
표는 페이지를 만들 때 normalize로 직접 계산한 값입니다. 받침 없는 글자는 NFD에서 2개, 받침 있는 글자는 3개로 풀리고, '닭'의 ㄺ이나 '똠'의 ㄸ처럼 겹받침·쌍자음도 조합용 자모 한 개씩으로 분해됩니다. 영문 'A'처럼 한글이 아닌 문자는 그대로입니다.
자모 열이 한 글자로 합쳐지는 계산
한글 합성은 사전이 필요 없는 산술입니다. 초성 번호 L은 초성 코드에서 U+1100를 뺀 값, 중성 번호 V는 중성 코드에서U+1161를 뺀 값, 종성 번호 T는 종성 코드에서 U+11A7를 뺀 값(받침이 없으면 0)이고, 완성형 코드는U+AC00 + (L × 21 + V) × 28 + T 입니다. '한'은 L=18, V=0, T=4이므로 U+AC00 + (18×21+0)×28 + 4 = U+D55C이며, 실제 '한'의 코드와 일치합니다. '닭'은 L=3, V=0, T=9로 U+B2ED이 되어 역시 일치합니다. 종성 없이 ㄱ+ㅏ(조합용)만 있으면 T=0이라 '가' 한 글자가 됩니다. 이렇게 규칙이 고정되어 있으므로 정규화 결과는 어느 환경에서나 같습니다. 같은 식을 거꾸로 푼 것이 자모 분리기의 분리 계산입니다.
왜 맥에서 온 파일이 깨져 보이나요
조합형으로 저장하는 쪽은 주로 macOS 계열의 파일 시스템과 일부 앱입니다. 어떤 앱이 어떤 방식으로 저장하는지는 운영체제와 파일 시스템 버전, 압축 프로그램에 따라 달라서 단정하기 어렵지만, 맥에서 만든 압축 파일을 윈도우에서 풀거나 메신저로 받은 파일 이름이 풀려 보인다면 거의 이 현상입니다. 윈도우와 대부분의 웹 서비스는 완성형을 기본으로 가정합니다. 완성형을 기대하는 쪽에서는 조합형 문자열이 "다른 글자"로 취급되어 파일 이름 검색이 안 되거나, 같은 이름이 두 개로 나타나기도 합니다.
검산한 예시
- 예시 1: 파일명. '안녕하세요 홍길동 최종보고서.hwp'은(는) 완성형 19자(UTF-8 45바이트)인데 조합형으로 풀면 38자(102바이트)가 됩니다. 두 문자열을 === 로 비교하면 다르다는 결과가 나오고, 조합형을 NFC로 되돌리면 원래 문자열과 정확히 일치합니다.
- 예시 2: 링크. 주소에 '한'이 들어 있으면 완성형은 %ED%95%9C로, 조합형은 %E1%84%92%E1%85%A1%E1%86%AB로 인코딩됩니다. 겉보기에 같은 한글 주소인데 서버가 완성형만 처리하면 조합형 링크는 "페이지 없음"이 될 수 있습니다.
- 예시 3: 글자 수 제한. 글자 수를 코드 포인트로 세는 시스템에 조합형 텍스트를 넣으면 같은 문장이 2~3배로 계산됩니다. 변환 후 결과 아래에 코드포인트 수 변화를 표시하니 입력 전후로 확인해 보세요.
NFC만 알면 될까: 네 가지 정규화 형식 비교
유니코드 정규화에는 NFC, NFD 외에 호환 분해를 쓰는 NFKC, NFKD가 있습니다. 앞의 둘은 "같은 글자의 다른 표현"을 통일하고, 뒤의 둘은 여기에 더해 모양이 비슷한 "호환 문자"(전각 영숫자, 합자, 호환 자모 등)까지 일반 문자로 바꿉니다. 이 도구의 버튼은 NFC와 NFD만 쓰는데, 호환 정규화는 원문 의미를 바꿀 수 있어 파일명 복구에는 적합하지 않기 때문입니다. 아래 표는 같은 입력을 네 가지 방식으로 처리했을 때 코드 포인트 수가 어떻게 달라지는지 빌드 시 계산한 것입니다.
| 입력 | 원래 개수 | NFC | NFD | NFKC | NFKC 결과 코드 |
|---|---|---|---|---|---|
| 완성형 한 | 1 | 1 | 3 | 1 | U+D55C |
| 조합형 한(NFD) | 3 | 1 | 3 | 1 | U+D55C |
| 호환 자모 ㅎㅏㄴ(키보드 낱자) | 3 | 3 | 3 | 2 | U+D558 U+1102 |
| 전각 영숫자 Ａ１ | 2 | 2 | 2 | 2 | U+0041 U+0031 |
| 합자 fi | 1 | 1 | 1 | 2 | U+0066 U+0069 |
| e + 결합 악센트 | 2 | 1 | 2 | 1 | U+00E9 |
키보드 낱자 'ㅎㅏㄴ'은 NFC에서는 변하지 않지만 NFKC에서는 조합용 자모로 바뀝니다. 그런데 호환 자모 'ㄴ'은 초성 자리의 자모로만 변환되기 때문에 받침 위치까지는 알 수 없습니다. 실제로 'ㅎㅏㄴ'을 NFKC로 처리하면 '한'과 같지 않은 값이 나오고, 'ㄱㅏㄴㅏ'는 '가나'로 합쳐집니다. 받침이 없는 낱자 열은 합쳐지지만 받침이 낀 열은 정확하지 않으므로, 이런 입력은 NFKC에 맡기지 말고 자모 결합 도구로 직접 확인하세요. 이 도구가 NFKC를 제공하지 않는 이유이기도 합니다.
상황별 활용 예시
사무직: 맥 사용자가 보낸 압축 파일 정리
거래처에서 받은 압축 파일을 풀었더니 폴더 안 파일명이 'ㅂㅗㄱㅗㅅㅓ'처럼 풀려 보이는 경우입니다. 파일 탐색기의 이름을 복사해 이 도구에 붙여 넣고 NFC로 변환한 뒤, 결과를 이름 변경 칸에 붙여 넣으면 됩니다. 파일이 100개라면 하나씩 하기보다 일괄 이름 변경 기능이 있는 도구에서 정규화 옵션을 찾거나, 몇 개를 변환해 본 뒤 규칙을 정해 처리하는 편이 효율적입니다. 참고로 위 예시 파일명 길이로 100개를 합치면 이름 바이트는 완성형 4500바이트, 조합형 10200바이트로 차이가 나지만, 일반적인 문서 작업에서는 용량이 문제 되는 수준이 아닙니다.
개발자: 업로드 파일명과 검색어 통일
사용자가 올린 파일 이름을 그대로 저장하면 같은 이름이 완성형과 조합형 두 가지로 쌓여 중복 검사와 검색이 어긋납니다. 저장 직전에 NFC로 바꾸고, 비교할 때도 양쪽을 NFC로 맞추면 대부분 해결됩니다. 다만 파일 시스템에 이미 존재하는 이름을 그대로 읽어야 하는 코드는 정규화한 값과 원본 값을 구분해 다뤄야 합니다. 원본 이름으로 파일을 열 때는 원본 문자열이 필요하기 때문입니다.
기획·운영자: 글자 수 제한이 이상하게 걸릴 때
입력란 글자 수 제한에 걸렸는데 화면에는 짧아 보인다면 붙여 넣은 텍스트가 조합형일 가능성이 있습니다. 이 도구로 코드포인트 수가 변환 전후에 얼마나 달라지는지 확인하면 원인을 구분할 수 있습니다. 자바스크립트의 length는 UTF-16 코드 단위 수를 세므로 조합형에서는 훨씬 커집니다. 예를 들어 '한글'은 완성형으로 2개, 조합형으로는 6개입니다.
재발을 줄이는 방법
- 압축 전달 방식을 바꿉니다. 맥에서 보낼 때는 이름이 한글인 파일을 폴더 째 압축하기보다, 받는 쪽이 윈도우라면 영문·숫자 이름으로 바꿔 전달하는 것이 확실합니다. 압축 프로그램에 따라 이름 정규화 옵션이 있는 경우도 있으니 설정을 확인하세요.
- 개발에서는 입력 경계에서 통일합니다. 사용자 입력, 파일 업로드 이름, 검색어를 저장·비교하기 전에 NFC로 바꾸면 "같은 이름 두 개" 문제가 대부분 사라집니다. 자바스크립트는 normalize('NFC'), 파이썬은 unicodedata.normalize('NFC', s)를 씁니다.
- 길이 제한은 용도를 구분합니다. 화면에 보이는 글자 수가 목적이면 NFC로 바꾼 뒤 세고, 저장 용량이 목적이면 바이트 수를 따로 확인하세요(예시 1의 45바이트와 102바이트처럼 차이가 큽니다).
- 변환 후에도 확인합니다. 일괄 이름 변경 전에는 몇 개만 먼저 변환해 파일이 열리는지, 링크나 바로가기가 끊기지 않는지 점검하세요.
이 도구로 해결되지 않는 경우
- 인코딩 자체가 어긋난 모지바케. EUC-KR 파일을 UTF-8로 잘못 열어 생긴 "占쏙옙" 같은 글자는 정규화 문제가 아닙니다. 문서나 파일을 올바른 문자셋으로 다시 열어야 합니다.
- 키보드로 친 낱자 자모. 'ㅎㅏㄴ'(호환 자모, 사용자가 직접 입력)은 NFC를 거쳐도 그대로입니다(검산 결과: 변하지 않음). 호환 자모와 조합용 자모는 코드가 다른 별개의 문자이기 때문이며, 낱자를 음절로 합치려면 한글 자모 분리·결합기를 쓰세요.
- 한글 외 문자도 함께 정규화됩니다. NFC는 'e'와 결합 악센트(U+0301)처럼 두 코드로 쓴 서양 문자도 한 글자로 합칩니다(검산: 2코드 → 1코드). 일반적으로 문제는 없지만, 문서에 섞인 다른 언어의 코드가 달라질 수 있습니다.
- 실제 파일 이름은 바꾸지 않습니다. 이 페이지는 텍스트 변환만 하며 파일을 수정하지 않습니다.
결과 활용법
변환한 이름을 복사해 파일 이름 변경이나 목록 정리에 쓰세요. 변환 전후가 같은지 확인하려면 텍스트 비교 도구가 코드 차이를 보여 줍니다. 웹 개발자라면 저장·검색 전에 입력을 NFC로 통일해 두는 것이 안전합니다. 한글 철자 자체가 궁금하면맞춤법 총정리를, 자모별 구조는 초성 변환기를 참고하세요. 특정 문자의 코드와 이름을 하나씩 확인하려면유니코드 문자 정보 도구를, 한글 제목으로 주소를 만들 때는한글 URL 슬러그 생성기를 함께 쓰면 좋습니다.
자주 묻는 질문
이 도구가 실제 파일 이름을 바꿔주나요?
아니요. 텍스트 변환만 지원하며 파일을 수정하지 않습니다. 파일 탐색기에 표시된 이름을 복사해 변환하고, 결과를 참고해 직접 이름을 바꾸거나 배치 스크립트에 사용하세요.
파일 탐색기에서 이름을 다시 입력해서 저장하면 안 되나요?
파일이 몇 개 안 되면 직접 다시 입력해 저장하는 것만으로 해결되는 경우가 많습니다. 파일이 많거나 목록 텍스트를 미리 확인하고 싶을 때 이 도구가 편리합니다.
NFC와 NFD 중 무엇을 써야 하나요?
웹, 데이터베이스, 윈도우 환경과의 호환을 위해서는 NFC가 일반적인 선택입니다. NFD는 자모 단위로 처리해야 하는 특수한 경우에만 의도적으로 사용합니다.
변환 후에도 글자가 깨져 보이면 어떻게 하나요?
결과 아래 안내에 "이미 완성형"이라고 나온다면 정규화 문제가 아닙니다. 폰트 문제이거나 인코딩이 잘못 해석된 경우이므로 문서를 올바른 문자셋으로 다시 열어 보세요.
변환하면 글자 모양이 바뀌나요?
화면에 보이는 한글 모양은 바뀌지 않습니다. 달라지는 것은 내부 코드 구성입니다. 그래서 변환 전후 문자열을 눈으로 비교해서는 차이를 알 수 없고, 아래 안내 문구와 코드포인트 수로 확인해야 합니다.
NFD로 바꾸는 버튼은 언제 쓰나요?
일반 사용자가 쓸 일은 드뭅니다. 개발자가 NFD 입력 처리를 테스트하거나, 자모 단위로 분해된 상태를 눈으로 확인하고 싶을 때, 또는 조합형을 기대하는 환경에 맞춰 줘야 할 때 사용합니다.
이모지나 영어, 숫자가 섞여 있어도 안전한가요?
대부분의 영문·숫자·기호·이모지는 NFC와 NFD에서 그대로입니다. 다만 악센트가 붙은 서양 문자는 NFC에서 합쳐지고 NFD에서 분리되므로, 글자 수가 달라질 수 있습니다.
복사 버튼이 동작하지 않으면 어떻게 하나요?
브라우저의 클립보드 권한이 막혀 있으면 복사에 실패하며, 이때 화면에 안내가 표시됩니다. 결과 상자의 텍스트를 직접 선택해 복사하면 됩니다.
입력한 텍스트가 서버로 전송되나요?
변환 스크립트는 입력창의 문자열을 브라우저 안에서 normalize로 처리할 뿐이며, 외부로 전송하는 코드가 없습니다.