📑 목차
프로크리에이트 텍스트 도구에서 한글이 네모(□)로 깨지는 ToFu 현상은 단순 버그가 아니라, 폰트 파일(. ttf/. otf)의 문자 테이블(글리프) 누락, 인코딩/유니코드 매핑 문제, iPadOS의 폰트 등록(캐시) 충돌로 발생하는 경우가 많습니다. 이 글은 한글 폰트 깨짐이 왜 생기는지 구조적으로 설명하고, 외부 폰트 설치 과정에서 자주 발생하는 서체 충돌을 디버깅 관점에서 정리합니다.
한글이 네모로 뜨는 순간, 텍스트가 사라진 게 아니라 글리프가 없는 상태
저는 프로크리에이트에서 텍스트를 넣으려다 한글이 네모(□)로 표시되는 경험을 했습니다. 처음에는 앱 오류라고 생각했고, 폰트를 바꾸면 해결될 거라고 가볍게 판단했습니다. 그런데 문제는 더 복잡했습니다. 같은 폰트가 어떤 앱에서는 한글이 정상 출력되는데, 프로크리에이트에서는 네모로 보이기도 했고, 어떤 폰트는 한글 일부만 나오다가 특정 글자에서만 깨지기도 했습니다.
이런 현상이 반복되면서 저는 한글 폰트 깨짐(ToFu)이 텍스트 기능이 고장 난 상태가 아니라, 해당 폰트가 그 글자를 그릴 수 있는 데이터(글리프)를 제공하지 못하는 상태라는 점을 이해하게 됐습니다. 즉, 화면에 네모가 뜨는 건 ‘문자 자체가 손상’된 것이 아니라 폰트 내부에서 한글을 매핑하는 테이블이 비어 있거나 iPadOS가 그 폰트를 올바르게 등록하지 못한 결과였습니다.
이 글은 프로크리에이트 텍스트 도구에서 발생하는 한글 깨짐을 ToFu 구조, TTF/OTF 포맷 차이, 유니코드 매핑과 인코딩 호환성, iPadOS 폰트 캐시/등록 충돌 관점에서 정리한 디버깅 기록입니다. 단순히 '이렇게 하세요'가 아니라, 왜 이런 문제가 생기고 어떤 지점에서 충돌이 발생하는지까지 설명합니다.
ToFu(□)는 글리프 미존재 신호
한글이 네모(□)로 나오는 현상을 흔히 폰트가 깨졌다고 표현하지만, 구조적으로는 조금 다릅니다. ToFu는 폰트 렌더러가 해당 문자를 그릴 글리프를 찾지 못했을 때 표시하는 대체 표기입니다. 즉, 시스템은 글자를 읽었지만 그 글자를 그릴 수 있는 도형 데이터가 없어서 네모로 보여주는 것입니다.
여기서 중요한 포인트는 다음 3가지입니다.
1) 폰트 파일에 한글 글리프가 없는 경우
일부 폰트는 라틴 문자(영문/숫자)만 포함하고, 한글 글리프를 포함하지 않습니다. 이 경우 한글은 통째로 ToFu로 보입니다. “한글 폰트처럼 보였는데 왜?”라는 상황도 생기는데, 폰트 이름이 한국어로 등록되어 있거나, 미리 보기 이미지에는 한글이 들어가 있어도 실제 글리프 테이블이 없는 경우가 있습니다.
2) 한글 글리프는 있는데 일부만 누락
한글은 조합형 구조라 글자 수가 매우 많습니다. 폰트 제작 과정에서 완성형 테이블을 모두 포함하지 않고 일부 범위만 제공하는 폰트도 존재합니다. 이 경우 대부분은 되는데 특정 글자에서만 네모 현상이 나타납니다.
3) 글리프는 있는데 유니코드 매핑이 올바르지 않을 때
폰트는 글리프 자체(도형)와 그 글리프가 어떤 유니코드 문자에 해당하는지 연결하는 매핑 테이블(cmap)을 함께 가집니다. 글리프가 있어도 cmap이 잘못되어 있으면 시스템이 글리프를 찾지 못해 ToFu가 발생합니다. 이 지점이 '인코딩/호환성 충돌'로 분류되는 핵심 원인입니다.
프로크리에이트에서의 ToFu는 텍스트 기능의 불량이 아니라 폰트 파일의 문자 커버리지와 매핑 구조 문제가 표면으로 드러난 상황이라고 보는 것이 정확합니다.
TTF/OTF 차이보다 유니코드 매핑(cmap)과 폰트 테이블 품질
사용자 입장에서는 폰트가. ttf냐. otf냐가 가장 먼저 보입니다. 하지만 실제 충돌의 대부분은 확장자보다 내부 테이블 품질에서 발생했습니다. 저는 여러 폰트를 설치해 보면서 같은 TTF라도 정상/비정상이 갈리고, OTF라고 다 안정적인 것도 아니라는 점을 체감했습니다.
1) TTF와 OTF는 내부 곡선 방식 차이
- TTF(TrueType): 글리프 곡선을 TrueType 방식으로 저장
- OTF(OpenType): 내부에 CFF(포스트스크립트 계열) 또는 TrueType 글리프를 담을 수 있음
즉, OTF는 컨테이너에 가깝고 내부에 어떤 글리프 포맷이 들어갔느냐에 따라 렌더링 호환성이 달라집니다. iPadOS는 OpenType을 잘 지원하지만 제작 퀄리티가 낮거나 테이블이 불완전한 폰트는 앱마다 다르게 반응할 수 있습니다.
2) 한글에서 중요한 테이블은 cmap + GSUB/GPOS
한글은 단순히 글리프만 있으면 끝이 아닙니다. 글자 조합과 문맥에 따라 치환/커닝/자간 처리가 필요할 수 있고 이때 OpenType 기능 테이블이 제대로 작성되어 있어야 합니다.
- cmap: 유니코드 → 글리프 매핑
- GSUB: 글자 치환(예: 조합/대체 형태)
- GPOS: 위치 조정(자간/커닝 등)
프로크리에이트 텍스트는 시스템 폰트 엔진을 활용하지만, 폰트 내부 테이블이 애매하면 “앱 A에서는 되고 앱 B에서는 깨짐” 같은 상황이 생깁니다. 저는 이 현상이 특히 무료 배포 폰트, 변환된 폰트, 웹폰트 추출 폰트에서 더 자주 나타난다고 느꼈습니다(반드시 그렇다는 뜻은 아니고 체감상 빈도가 높았습니다).
3) ToFu 현상의 대표 케이스는 폰트 변환/부분 서브셋
웹용 폰트를 최적화하려고 글자 수를 줄인 서브셋 폰트는, 필요한 글자만 포함하고 나머지는 제거합니다. 이런 폰트를 iPad에 설치하면, 특정 문장에서는 정상처럼 보이다가 한 글자만 ToFu로 바뀌기도 합니다.
저는 이 케이스가 가장 헷갈렸습니다. 폰트 이름도 한글이고, 일부 글자는 잘 나오는데 특정 글자만 깨지니, 앱 문제로 오해하기 쉬웠습니다. 실제로는 폰트가 제공하지 않는 글자를 입력한 순간 ToFu가 나온 것입니다.
iPadOS 외부 폰트 설치에서 발생하는 서체 충돌
한글 폰트 깨짐을 경험한 뒤 저는 폰트를 설치하면 끝으로 보지 않게 됐습니다. iPadOS에서 외부 폰트는 단순히 파일이 저장되는 것이 아니라, 시스템이 해당 폰트를 등록(Register)하고, 앱들이 접근할 수 있도록 폰트 목록을 재구성합니다. 이 과정에서 충돌이 발생하면 파일은 설치되어 있는데 앱에서 안 보이거나 보이는데 깨지는 현상이 나옵니다.
1) 동일한 폰트 패밀리 이름 충돌
외부 폰트는 내부적으로 폰트 패밀리 이름과 포스트스크립트 이름 등을 기준으로 관리됩니다. 그런데 다른 제작자의 폰트가 같은 패밀리 이름을 쓰거나, 변환 과정에서 이름 정보가 꼬이면 iPadOS가 폰트를 중복으로 인식할 수 있습니다.
이 경우 어떤 앱은 A 폰트를, 다른 앱은 B 폰트를 참조해 버리는 식의 혼선이 생길 수 있습니다. 사용자는 같은 이름을 선택했는데 결과가 다르게 출력되는 것처럼 느끼게 됩니다.
2) 설치 경로(파일앱/서드파티 앱)와 폰트 등록 방식 차이
iPadOS에서 폰트를 설치하는 방법은 여러 가지입니다. 예를 들어
- 프로파일 기반 설치(폰트 관리 앱)
- 파일앱에서 폰트 파일을 열어 설치
- 서드파티 폰트 관리자 앱을 통한 등록
이때 등록이 불완전하면 설치는 됐는데 프로크리에이트에서 목록에 안 뜨거나 목록에는 뜨는데 한글만 깨지는 현상이 발생할 수 있습니다.
제가 느낀 실무 기준은 설치 방법을 자주 바꾸면 충돌 가능성이 올라간다는 것이었습니다. 특히 동일 폰트를 여러 경로로 반복 설치하면 중복/충돌이 생길 확률이 체감상 높았습니다.
3) 폰트는 설치/삭제가 즉시 반영되지 않는 경우
폰트는 설치/삭제가 즉시 반영되지 않는 경우가 있습니다. 폰트 목록이 갱신되기 전까지 프로크리에이트가 이전 캐시를 보고 있을 수 있고, iPadOS 자체도 폰트 목록을 재빌드하는 시간이 필요할 수 있습니다.
이때 사용자는 삭제했는데도 동일 증상이 반복되는 것으로 느끼게 됩니다. 실제로는 삭제가 안 됐거나 삭제는 됐지만 캐시가 갱신되지 않은 상태일 수 있습니다.
저는 이 문제를 겪고 나서, 외부 폰트는 단순한 디자인 리소스가 아니라 시스템 레벨 리소스라는 인식을 갖게 됐습니다. 시스템 레벨 리소스는 충돌이 생기면 앱 하나가 아니라 여러 앱에 영향을 줄 수 있고, 결과적으로 텍스트 출력의 신뢰도가 흔들립니다. 수익화를 목표로 한다면 이 신뢰도는 매우 중요한 기준입니다.
Q&A
Q. 프로크리에이트에서만 한글이 네모로 나오면 앱 버그인가요?
A. 가능성은 있지만, 저는 먼저 폰트의 글리프 누락/유니코드 매핑 문제를 의심했습니다. 같은 폰트를 다른 앱에서 테스트했을 때 일부 글자만 깨지는 경우가 특히 많았습니다.
Q. TTF보다 OTF가 더 안전한가요?
A. 확장자만으로는 판단하기 어렵다고 느꼈습니다. 중요한 건 폰트 내부 테이블(cmap, GSUB/GPOS)의 완성도와 한글 커버리지였습니다.
Q. 폰트 설치했는데 목록에 안 보이는 이유는 뭔가요?
A. 설치 경로나 등록 방식 차이, 중복 설치로 인한 충돌, 폰트 캐시 갱신 지연 같은 요인이 겹칠 수 있습니다.
Q. 특정 글자만 네모가 되면 무엇을 의심해야 하나요?
A. 서브셋 폰트(글자 일부만 포함) 가능성이 높습니다. 폰트가 제공하지 않는 문자를 입력하면 ToFu가 발생합니다.
나의 생각｜텍스트 품질은 폰트 데이터 신뢰성
프로크리에이트 텍스트 도구에서 한글 폰트가 깨지는 경험은 제가 작업을 시각적 결과가 아니라 데이터 신뢰성으로 바라보게 만든 계기였습니다. 수익화 작업에서 텍스트는 장식이 아니라 정보이자 브랜드 요소입니다. 이모티콘, 굿즈, 스티커, 썸네일 요소처럼 플랫폼을 통과해야 하는 작업에서는 텍스트의 안정성이 곧 결과물의 신뢰도를 좌우합니다.
ToFu 현상은 사용자의 감각으로 해결되는 문제가 아니었습니다. 폰트가 어떤 글리프를 포함하고 있는지, 유니코드 매핑이 정상인지, iPadOS에 어떻게 등록되는지 같은 구조적 조건이 맞아야 안정적으로 출력됩니다. 이 구조를 이해하지 못하면, 같은 폰트를 선택하고도 앱마다 출력이 다르거나, 특정 글자만 깨져 수정이 반복되는 상황이 생깁니다.
결국 외부 폰트는 예쁜 글꼴 파일이 아니라, 시스템과 앱이 공유하는 문자 데이터베이스에 가깝습니다. 저는 이제 폰트를 고를 때 디자인보다 먼저 신뢰성을 판단 기준으로 둡니다. 이 기준이 생기면 텍스트 작업은 더 빨라지고, 수정 요청에도 흔들리지 않습니다. 수익화를 목표로 한다면, 폰트 선택은 취향의 문제가 아니라 데이터 안정성의 문제라고 판단합니다.