한글 깨짐(자모 분리) 완벽 복구 가이드

같은 "한글 깨짐"이라도 원인은 두 가지입니다

맥에서 만든 파일을 윈도우로 옮겼을 때 이름이 이상하게 보이는 현상은 흔하지만, 원인은 서로 완전히 다른 두 가지로 나뉩니다. 어느 쪽인지 먼저 구분해야 복구 방법이 정해집니다.

읽을 수 있는 자음·모음이 순서대로 늘어서 있다면 자모 분리, 알아볼 수 없는 기호가 나오면 인코딩 문제라고 보시면 거의 맞습니다. 이 글은 앞쪽, 즉 자모 분리 현상을 다룹니다.

왜 자모가 분리되나 — NFC와 NFD

유니코드는 한글 한 글자를 표현하는 방법을 두 가지로 인정합니다.

• NFC(완성형 정규화) — "한"을 미리 조합된 한 글자(U+D55C)로 저장합니다. 현대 한글 11,172자가 모두 이 방식으로 코드가 배정돼 있고, UTF-8 기준 3바이트를 차지합니다.
• NFD(조합형 정규화) — "한"을 초성 ㅎ(U+1112) + 중성 ㅏ(U+1161) + 종성 ㄴ(U+11AB) 세 조각으로 저장합니다. UTF-8 기준 9바이트, 즉 세 배입니다.

유니코드 규격상 두 표현은 정준 등가(canonically equivalent), 즉 "같은 글자"입니다. 그래서 제대로 만든 렌더러라면 조합형이어도 "한"으로 합쳐서 그려 줍니다. 문제는 프로그램마다 이 조합 처리를 하지 않는 경우가 있다는 것입니다. 조합을 못 하면 초·중·종성이 각자 자리를 차지해 ㅎㅏㄴ처럼 늘어서 보입니다.

애플은 오래전 HFS+ 시절부터 파일명을 조합형(NFD 계열)으로 저장하는 정책을 썼고, APFS로 넘어온 뒤에도 맥에서 만들어진 이름은 조합형으로 남는 경우가 많습니다. 반대로 윈도우는 한글 IME가 입력한 완성형(NFC)을 그대로 저장합니다. 그래서 맥에서 만든 이름 → 윈도우에서 열람이라는 방향에서만 이 현상이 집중적으로 터집니다.

실제로 언제 터지나

• 맥 기본 압축 → 윈도우에서 풀기: 가장 흔한 경로입니다. 압축 파일 안에 이름이 조합형 그대로 들어가고, 윈도우 압축 해제 도구가 그대로 풀어 놓습니다.
• 클라우드 동기화: 드롭박스·구글 드라이브·원드라이브 같은 서비스는 클라이언트와 버전에 따라 정규화 정책이 다릅니다. 맥에서 업로드하고 윈도우에서 내려받았을 때 이름이 달라지는 일이 생깁니다.
• 웹 업로드/메일 첨부: 브라우저는 파일명을 손대지 않고 보냅니다. 서버가 정규화하지 않으면 조합형 이름이 그대로 저장되고, 다운로드받은 사람 화면에서 깨집니다.
• USB·외장 하드·NAS: exFAT나 SMB 공유를 통해 옮길 때도 이름은 원본 그대로 따라갑니다.
• Git 저장소: 맥 Git에는 core.precomposeunicode 설정이 있어 조합형 경로를 완성형으로 바꿔 다룹니다. 이 값이 꺼져 있으면 같은 파일이 커밋마다 다른 경로로 잡혀 팀원과 충돌합니다.

겉보기 문제로 끝나지 않는다는 점이 중요합니다. 첫째, 검색과 정렬이 깨집니다. 윈도우 탐색기에서 "보고서"로 검색해도 조합형으로 저장된 파일은 잡히지 않습니다. 둘째, 경로 길이가 늘어납니다. 한글 이름이 세 배로 부풀기 때문에 폴더가 깊으면 윈도우의 260자 경로 한계에 훨씬 빨리 걸려 복사나 압축 해제가 실패합니다. 셋째, 프로그램에서 파일명을 문자열로 비교하는 코드가 조용히 어긋납니다.

파일명 복구하기

맥에서 보내기 전에 고치는 방법

가장 깔끔한 건 원본 쪽에서 정리하는 것입니다. 맥 터미널의 iconv는 애플의 조합형 인코딩을 UTF-8-MAC이라는 이름으로 다루기 때문에, iconv -f UTF-8-MAC -t UTF-8 로 넘기면 완성형 문자열이 나옵니다. 파일명을 통째로 바꾸려면 Homebrew로 설치하는 convmv가 편합니다. convmv -f utf-8 -t utf-8 --nfc -r --notest 폴더명 형태로 실행하면 하위 폴더까지 한 번에 정규화됩니다. --notest를 빼고 먼저 돌리면 실제 변경 없이 바뀔 목록만 보여 주니, 확인 후 실행하는 습관을 권합니다.

이미 윈도우로 넘어온 파일을 고치는 방법

윈도우에서는 파워셸이 바로 답이 됩니다. .NET 문자열에 정규화 메서드가 들어 있어서, 각 파일 이름에 대해 $_.Name.Normalize([Text.NormalizationForm]::FormC) 결과로 Rename-Item 을 걸어 주면 됩니다. 폴더는 안쪽부터 바꾸도록 역순으로 처리해야 경로가 어긋나지 않습니다. 파이썬을 쓸 수 있다면 unicodedata.normalize('NFC', 이름) 한 줄에 os.rename 을 붙이는 편이 더 짧습니다.

몇 개 안 될 때

파일이 몇 개뿐이라면 이름을 직접 다시 타이핑하는 게 제일 빠릅니다. 윈도우 IME로 새로 입력하면 자동으로 완성형이 됩니다. 문자열만 붙여넣어 정규화된 결과를 받고 싶을 때는 한글 정규화 도구처럼 브라우저에서 NFC/NFD를 오가는 유틸리티를 써도 됩니다. 어느 방법이든 결과는 같습니다. 정준 등가 변환이라 내용이 바뀌지 않습니다.

파일 "내용" 안의 자모 분리

파일명만 문제가 되는 게 아닙니다. 맥에서 만든 CSV, 맥용 PDF에서 복사한 텍스트, 맥 앱이 뱉은 로그에는 본문 자체가 조합형으로 들어 있는 경우가 있습니다. 화면에는 멀쩡히 "서울시"로 보이는데 실무에서는 이렇게 드러납니다.

• 엑셀에서 VLOOKUP·XLOOKUP이 눈으로는 똑같은 값인데 #N/A를 냅니다.
• 데이터베이스에 넣고 WHERE 이름 = '서울시' 로 조회하면 0건이 나옵니다.
• Ctrl+F 검색이 안 잡히고, 편집기에서 백스페이스를 누르면 한 글자가 자모 단위로 하나씩 지워집니다.
• 글자 수를 세면 "서울시"가 3이 아니라 7로 나옵니다(ㅅ+ㅓ+ㅇ+ㅜ+ㄹ+ㅅ+ㅣ).

해결 원칙은 데이터가 시스템에 들어오는 첫 지점에서 NFC로 정규화하는 것입니다. 자바스크립트는 문자열의 normalize('NFC'), 파이썬은 unicodedata.normalize, 자바는 Normalizer.normalize 가 표준 함수로 있습니다. 엑셀에는 정규화 함수가 없으므로, 파일을 텍스트 편집기나 변환 도구로 한 번 통과시킨 뒤 다시 불러오는 편이 확실합니다.

예방: 보내기 전 30초

• 압축 앱을 바꿉니다. 맥 기본 압축 대신 파일명 인코딩 옵션을 제공하는 압축 앱을 쓰고, 설정에서 완성형/윈도우 호환 이름 옵션을 켭니다. 맥 리소스 포크(__MACOSX, .DS_Store) 제외 옵션도 함께 켜 두면 받는 쪽이 훨씬 깔끔합니다.
• 외부로 나갈 파일은 이름 규칙을 단순화합니다. 최종 산출물 파일명을 영문+숫자+하이픈으로 정하면 정규화 문제뿐 아니라 URL 인코딩, 경로 길이 문제까지 함께 사라집니다.
• 서버·업로드 단계에서 강제 정규화합니다. 파일을 받는 백엔드에서 저장 직전에 파일명을 NFC로 바꾸면 사용자가 무엇을 올리든 일관됩니다.
• 맥에서 Git을 쓴다면 git config --global core.precomposeunicode true 를 한 번 확인해 둡니다.
• 받은 압축 파일은 먼저 목록만 열어 봅니다. 이름이 깨져 있으면 풀기 전에 되돌려 보내는 편이 나중에 수백 개를 일괄 변경하는 것보다 빠릅니다.

이럴 땐 변환하지 마세요

정규화가 만능은 아닙니다. 세 가지 예외를 알아 두면 사고를 막을 수 있습니다.

NFKC는 파일명에 쓰지 않습니다

정규화 형식에는 NFC·NFD 말고 NFKC·NFKD도 있습니다. 뒤의 두 가지는 "호환 분해"라서 ㈜가 (주)로, ①이 1로, 전각 문자가 반각으로 바뀝니다. 글자 모양이 실제로 달라지는 비가역 변환이므로, 파일명과 원본 데이터에는 반드시 NFC만 사용하고 NFKC는 검색 색인 같은 별도 용도에만 씁니다.

옛한글은 조합형이 정상입니다

훈민정음식 옛한글(ㅿ, ㆍ, 병서 등이 포함된 글자)은 현대 한글 11,172자 표에 없어서 완성형 코드가 아예 존재하지 않습니다. 이런 글자는 조합형으로만 표현되며, 자모가 나뉘어 있는 게 정상입니다. 고문헌·국어학 자료를 일괄 변환할 때는 현대 한글 음절만 골라 처리해야 합니다.

인코딩이 깨진 파일은 정규화로 못 고칩니다

앞에서 구분한 두 번째 유형, 즉 º¸°í¼­ 같은 상태는 UTF-8 바이트를 CP949로 읽었거나 그 반대인 경우입니다. 이건 압축 해제 도구에서 원본 인코딩을 CP949 또는 UTF-8로 지정해 다시 푸는 것으로 해결해야 합니다. 물음표(?)로 바뀌어 버린 이름은 이미 정보가 사라진 상태라 어떤 도구로도 되살릴 수 없고, 보낸 사람에게 다시 받는 수밖에 없습니다.

자주 묻는 질문

자모가 분리된 파일을 NFC로 바꾸면 파일 내용이 손상되지 않나요?

손상되지 않습니다. NFC와 NFD는 유니코드 표준에서 정준 등가로 규정된 같은 글자의 두 표현 방식이며, 서로 오갈 때 정보가 사라지지 않습니다. 파일명을 바꾸는 것이므로 파일의 실제 데이터(사진, 문서 본문)에는 손도 대지 않습니다. 다만 NFKC나 NFKD는 ㈜를 (주)로 바꾸는 식의 비가역 변환이므로 파일명에는 쓰지 마세요.

맥에서 압축해 보낼 때마다 상대방 윈도우에서 깨집니다. 어떻게 보내야 하나요?

맥 기본 압축(파인더의 압축 메뉴) 대신 파일명 인코딩·정규화 옵션을 제공하는 압축 앱을 사용하시고, 완성형 또는 윈도우 호환 이름 옵션을 켠 상태로 압축하세요. 함께 __MACOSX 폴더와 .DS_Store 제외 옵션도 켜 두면 받는 쪽 화면이 훨씬 깔끔합니다. 대외 제출용 최종 파일은 아예 영문과 숫자, 하이픈만으로 이름을 지으면 정규화, URL 인코딩, 경로 길이 문제가 한 번에 사라집니다.

화면에는 글자가 멀쩡한데 엑셀 조회나 프로그램 검색만 실패합니다. 왜 그런가요?

본문 텍스트가 조합형(NFD)으로 저장돼 있을 가능성이 큽니다. 렌더러가 자모를 잘 합쳐서 그려 주기 때문에 눈으로는 완성형과 구분이 되지 않지만, 컴퓨터 입장에서는 코드 포인트 구성이 달라 문자열 비교가 실패합니다. 확인하려면 해당 글자의 개수를 세어 보세요. 세 글자짜리 단어가 6~9로 나오면 조합형입니다. 데이터를 시스템에 넣는 첫 단계에서 NFC로 정규화하는 것이 근본 대책입니다.

이름이 º¸°í¼­나 물음표로 보이는 파일도 같은 방법으로 고칠 수 있나요?

아닙니다. 그건 자모 분리가 아니라 문자 인코딩을 잘못 해석한 경우로, UTF-8 바이트를 CP949로 읽었거나 그 반대인 상태입니다. 압축 해제 도구에서 원본 인코딩을 CP949 또는 UTF-8로 직접 지정해 다시 푸는 방식으로 해결해야 합니다. 다만 이름이 이미 물음표로 치환된 경우는 원래 바이트가 사라진 것이라 복구가 불가능하며, 보낸 사람에게 다시 받아야 합니다.

관련 도구

이 글에서 설명한 작업은 한글 정규화 (NFC/NFD 변환)에서 설치 없이 바로 처리할 수 있습니다. 파일이 서버로 올라가지 않고 브라우저 안에서 변환됩니다.

• 전체 가이드 목록 보기
• QR 코드 만들기: 한 번에 스캔되는 코드의 조건
• 사진 EXIF·위치정보 제거하는 법