[해결] 윈도-맥OS 한글 파일명 자소 분리 현상

피처 이미지
[출처=pixabay]
협업과 소통의 시대다. 한국 사회도 밥먹듯이 이 두가지를 부르짖는 풍토가 정착됐다. 그러나 전산에 기반한 현대 사무의 최전선에선 윈도와 맥 사용자의 협업과 소통이 만만찮은 숙제다. 여기에 짤막한 사례 하나 소개한다.

윈도와 맥 OS가 한글 문자를 다르게 처리해서 생기는 고질적인 문제가 있다. 예를 들어 맥에서 어떤 파일명을 ‘임민철’이라고 정하고 이걸 윈도로 가져오면 ‘ㅇㅣㅁㅁㅣㄴㅊㅓㄹ’로 표기된다. 이게 페이스북에선 재현이 안되기도 하기때문에 이미지를 첨부한다.

한글 파일명 정규화 문제 예시
맥OS에서 작성된 한글 파일명이 위와 같이 초중종성 모아쓰기로 표현되더라도 윈도 OS에서는 풀어쓰기 상태로 표현된다.

이 그림처럼 맥→윈도로 갈 때 모아쓰기 방식이었던 한글의 첫가끝소리(초중종성)가 전부 풀어쓴 모양으로 바뀌어버린다. 띄어쓰기나 대시(-), 따옴표나 마침표같은 범용 부호는 유지되는 것 같다. 숫자와 로마자 대소문자도 그대로다. 딱 한글이 문제다.

파일명만 이런 식이라면 과거엔 무시할만한 일이었을 터. 지금은 협업과 소통의 시대라는 게 비극을 낳는다. 메일에 첨부한 파일, 슬라이드셰어에 게시한 프리젠테이션, 깃허브에서 진행하는 프로젝트를 다룰 때, 다 말썽이다.

여기서 가장 큰 문제는 뭔가를 배포하는 당사자가 이런 현상을 알아차리지 못할 경우가 많다는 점이다. 자신의 PC에서는 이런 자료를 다룰 때 전혀 이상한 점이 없고 오로지 타인의 이기종 시스템에서만 발생이 되기 때문이다.

뭔가를 받은 사람이, 상대로부터 건네받은 뭔가가 이상하다고 지적하기도 마땅찮다. 기술적인 지식이 없는 한 그게 어떤 원인으로 발생했는지 판단하기 어렵고, 의심만으로 누군가에게 뭔갈 바로잡자 요구할 수는 없기 때문이다.

원인은 대강 파악했는데 설명하려면 별도의 글을 써야할 지경이다. 간단히 요약하면 앞서 언급했듯 윈도와 맥 OS가 한글을 처리하는 방식, 기술적으로 표현하면 ‘인코딩’하는 방식이 상이한 탓이다. 어느 한 쪽의 잘못은 아니다.

좀 더 구체적으로 말하면 두 환경이 서로 다른 유니코드 정규화(unicode normalization) 방식을 쓰는 탓이다. 윈도는 C형 정규화(NFC, Normalization Form C)라는 규칙을, 맥OS는 D형 정규화(NFD)라는 규칙을 채택했다고.

(231101 내용추가) 마이크로소프트 기술 문서(https://learn.microsoft.com/ko-kr/windows/win32/intl/using-unicode-normalization-to-represent-strings) 설명에 따르면 NFC와 NFD는 유니코드로 동일한 문자열을 나타내기 위한 여러 표현 방법의 갈래다.

윈도에 채택된 NFC는 한글 음절 하나를 단일 코드의 글자로 처리한다. 초중종성이 모여 있으면 이것을 하나의 글자로, 초중종성이 따로 있으면 각각 별개인 여러 글자로 표현하는 것이다. 윈도는 과거부터 초중종성 낱자와 이를 합친 글자에 별개의 코드를 부여한 완성형 한글 코드를 지원했기 때문에, 유니코드 지원 환경으로 바뀔 때 하위 호환성을 위해 완성형 한글 코드를 그대로 표현할 수 있는 NFC를 채택했을 것으로 짐작한다.

맥OS는 조합형 한글 코드를 사용하는 OS다. 그래서 초중종성에 코드를 할당하고 이를 풀어서 쓸 때 사용하는 코드를 음절 하나로 모아서 쓸 때 재사용한다. 이러한 규칙으로 표현하는 방식이 NFD다. 맥OS는 과거부터 한글을 조합형으로 처리해 왔다. 조합형 한글 코드로 저장된 파일명을 맥OS에서 NFD 규칙으로 표현해 온전한 음절 형태로 나타내게 된다. 하지만 같은 파일명의 한글 코드를 변환하지 않고 윈도 환경으로 가져오면 그 파일명은 NFC 규칙에 따라 음절이 완성되지 않은 채로 표현된다.

그래서, 결과만 말하면, 맥OS에서 한글로 저장한 파일명이 윈도에서 다 풀어제낀 형태로 나오는 건 윈도가 NFD를 안 쓰고 NFC를 쓰기 때문이다. 이 영향으로 윈도에서 파일명을 한글로 저장한 결과가 맥OS에서도 이상하게 보일 지는 알 수 없지만, 그런 사례를 경험해 보진 못했다.

(231101 내용추가) 8년 전 이 글을 처음 썼을 땐 딱히 이 현상을 정의한 용어를 찾지는 못했는데 이기종간 유니코드 표준화 비호환 문제 정도 되지 않을까 싶다.  2023년 현재는 보통 ‘(한글) 자소 분리 문제’로 불리는 것 같다. 유니코드 표준 관련 문서(http://unicode.org/reports/tr15/)를 보면 유럽권의 라틴 문자 같은 다른 문자 체계에서도 비슷한 문제가 있을 수 있다.

업무상, 직책상, 맥에서 윈도로 뭔갈 넘겨받는 일이 빈번하다. 최근 자주 겪는 일이라 정리해 봤다. 주 사용 환경은 맥OS가 아니라 윈도라서, 아직 윈도→맥으로 뭔가 넘길 땐 무슨 일이 벌어지는지 확인하지 못했다.

아시는 분은 제보해 주시길…

(231101 내용추가) GPT-4 기반 챗봇 ‘마이크로소프트 코파일럿 위드 빙챗’은 이 질문에 이렇게 답했다.

따라서, macOS에서 작성한 한글 파일명은 조합형으로 저장되기 때문에 윈도우에서 열면 깨진 것처럼 보일 수 있습니다. 반대로 윈도우에서 작성된 한글 파일명은 맥에서 잘 보입니다.

하루 지나 글을 다시 본 뒤 맥→윈도 이상현상을 예시한 이미지를 첨부. 핵심인 텍스트 이상현상이 샘플로 제시한 문자열에 재현이 안 돼 있어서. 그리고 왕수용 민트기술 대표님 개인 블로그 글(https://wangsy.com/2011/09/26/ubuntu-osx-hangul-filename/)에 따르면, 맥→리눅스(우분투)에서도 같은 문제가 있는 모양.

(231101 내용추가) 맥OS 사용자는 자신의 파일을 다른 OS 환경이나 사용자에게 전달할 때 한글 자소 분리 현상을 예방할 수 있다. Contact 라는 맥용 한글 자소 합치기 프로그램을 쓰면 된다. Contact는 2020년 10월초 개발자 블로그(https://namocom.tistory.com/901)를 통해 공개됐고 2.1버전(https://namocom.tistory.com/907)까지 나왔다.

150225 페이스북노트에 게재한 글을 160626 개인 블로그 파서 옮긴 뒤 160805 재편집. 170402 재편집. 231101 유니코드 정규화 규칙 설명, 코파일럿 답변 추가 등  본문 내용 보완.