윈도우-맥 오피스 한글 폰트 깨짐, 10년 전과 지금의 차이
🖥️ 맥(Mac)에서 윈도우 사용자가 보낸 오피스 문서를 열었을 때, 한글이 온통 네모(□□□)로 깨지던 시절을 기억하시나요?
과거 2012년 맥용 MS 오피스 2011 시절에는 윈도우의 기본 폰트인 '맑은 고딕'조차 맥에서 제대로 인식되지 않아, 개발자 도구로 폰트 내부 코드를 직접 뜯어고쳐야 하는 고통이 있었습니다. 과연 10여 년이 지난 지금은 어떻게 바뀌었을까요? 완전히 해결된 부분과 2026년 현재에도 여전히 실무자를 괴롭히는 진짜 호환성 문제 2가지(자소 분리 & 폰트 밀림)의 해결책을 총정리해 드립니다.
📊 맥-윈도우 한글 오피스 호환성: 2012년 vs 2026년 비교
| 비교 항목 | 과거 (2012년 / Office 2011) | 현재 (2026년 / Microsoft 365) |
|---|---|---|
| 맑은 고딕 렌더링 | ❌ 미지원 (전부 네모 □□ 로 깨짐) | ✔ 완벽 지원 (클라우드 폰트 자동 렌더링) |
| 한글 서체명 인식 | ❌ 'Malgun Gothic'만 인식, '맑은 고딕' 인식 실패 | ✔ 맥OS 서체 관리자 다국어 매핑 완료 |
| 자간 및 글자 겹침 | ❌ 글자가 반씩 겹쳐 나오는 자간 버그 빈번 | ✔ OpenType 규격 일치로 글자 겹침 소멸 |
| 오피스 기본 글꼴 | 맑은 고딕 / 굴림 (OS 종속적) | Aptos (크로스 플랫폼 표준 서체 도입) |
| 남아있는 과제 | 기본 한글 폰트 자체가 안 나오는 치명적 결함 | 파일명 자소 분리(NFC/NFD) & 유료 서체 미설치 |
📜 라떼는 말이야: 2012년의 눈물겨운 폰트 XML 수정기
2012년 당시 블로그 포스트를 보면, 윈도우 비스타/7에 포함된 malgun.ttf를 맥에 복사해도 한글 이름(맑은 고딕)으로는 인식을 못 하고 영문명(Malgun Gothic)으로만 인식되는 기현상이 있었습니다.
결국 긱(Geek) 개발자들은 애플 개발자 도구인 Apple Font Tools를 다운받아 폰트 바이너리에서 nameTable XML을 추출한 뒤, 아래와 같이 플랫폼 한글 식별 코드(LanguageID 23)를 직접 코딩해 집어넣고 다시 바이너리로 컴파일해서 설치해야만 했습니다:
<localizedName platformID="1" platformName="Macintosh" scriptID="3" scriptName="Korean" languageID="23">
맑은 고딕
</localizedName>
</nameTableEntry>
다행히 지금은 이런 무시무시한 수작업을 전혀 할 필요가 없습니다!
🚀 2026년 현재: 어떻게 원천 해결되었는가?
⚠️ 2026년에도 여전히 실무자를 괴롭히는 진짜 호환성 문제 2가지
원인: 맥OS는 한글을 초성·중성·종성으로 분리 저장하는 NFD (정규화 분해) 방식을 쓰고, 윈도우는 완성형 글자로 저장하는 NFC (정규화 결합) 방식을 쓰기 때문입니다.
• 맥에서 압축할 때 기본 압축 대신 Keka(케카) 같은 무료 압축 프로그램을 사용해 '맥 전용 리소스 제외' 옵션을 켜고 압축하세요.
• 이미 자소가 분리된 파일명은 웹 변환 사이트나 윈도우용 파이썬 스크립트(
unicodedata.normalize('NFC', text))로 1초 만에 복구 가능합니다.
원인: 기본 폰트는 클라우드로 연동되지만, 기업 전용 폰트나 유료 서체는 맥에 설치되어 있지 않으면 기본 고딕체로 대체되면서 글자 폭 차이로 표가 깨집니다.
• 윈도우 파워포인트/워드에서 저장할 때 [파일] ➡️ [옵션] ➡️ [저장] ➡️ [파일의 글꼴 포함] 옵션을 반드시 체크하고 저장하세요.
• 상대방이 수정할 필요가 없는 보고서나 제안서라면 무조건 [PDF로 내보내기]하여 전달하는 것이 가장 안전합니다.
10년 전과 비교하면 맥과 윈도우의 오피스 호환성은 눈부시게 발전했습니다. 이제 폰트 파일 때문에 머리 싸맬 필요 없이, '글꼴 포함 저장'과 'Keka 압축' 두 가지만 기억하시면 완벽하고 쾌적한 크로스 플랫폼 문서 작업을 즐기실 수 있습니다!
