두부(Tofu)와 점선 원, 들어보셨나요?
웹페이지에서 글자가 있어야 할 자리에 네모 박스(□)가 뜨는 걸 본 적 있으시죠? 이걸 업계에서는 '두부(tofu)'라고 불러요. 하얗고 네모난 모양이 두부를 닮아서 붙은 별명이에요. 구글이 주도하는 폰트 패밀리 Noto의 이름이 바로 여기서 왔어요. 'No Tofu', 즉 세상의 모든 문자를 지원해서 네모 박스를 없애겠다는 목표를 담은 거죠.
그런데 두부를 없앴다고 끝이 아니에요. DatoCMS 팀이 미얀마어 텍스트를 다루면서 마주친 건 조금 다른 문제였거든요. 글자는 분명히 표시되는데, 군데군데 점선 원(◌)이 끼어서 나오는 현상이었어요. 폰트도 있는데 왜 이런 일이 생기는 걸까요?
두부와 점선 원은 원인이 달라요
- 두부(□): 폰트에 그 글자 모양(글리프)이 아예 없을 때 생겨요. '이 글자는 그릴 줄 몰라요'라는 신호죠.
- 점선 원(◌): 글리프는 있는데 글자들의 조합 순서가 규칙에 맞지 않을 때 셰이핑 엔진이 일부러 넣는 표시예요.
- 사용자 입력을 저장하기 전에 유니코드 정규화(NFC)를 적용하고 있나요?
- 서버 사이드 이미지·PDF 생성 도구가 HarfBuzz 같은 셰이핑 엔진을 쓰나요?
- 대상 언어별로 검증된 폰트를 폴백으로 지정했나요?
- QA 단계에서 실제 현지 텍스트 샘플로 렌더링을 확인하나요?
여기서 셰이핑(shaping)이 뭐냐면, 문자 코드의 나열을 실제로 화면에 그릴 글리프 배치로 바꿔주는 과정이에요. 영어는 a, b, c를 옆으로 늘어놓기만 하면 되니까 신경 쓸 일이 거의 없어요. 하지만 아랍어, 태국어, 힌디어, 미얀마어 같은 복합 문자(complex script)는 앞뒤 글자에 따라 모양이 바뀌고, 위아래로 쌓이고, 심지어 입력 순서와 화면 표시 순서가 다르기도 해요. 크롬, 파이어폭스, 안드로이드 등에서 이 일을 맡는 대표적인 오픈소스 엔진이 HarfBuzz예요.
모음 부호 같은 결합 기호는 반드시 앞에 기준이 되는 자음이 있어야 하는데, 기준 글자 없이 결합 기호만 덩그러니 남으면 HarfBuzz는 '여기 뭔가 빠졌어요'라는 뜻으로 점선 원을 붙여 보여줘요. 렌더링 버그라기보다는 일종의 경고 메시지인 셈이죠.
미얀마어에서 점선 원이 생기는 흔한 이유
원인은 상황마다 다르지만, 보통 이 세 가지 중 하나로 좁혀져요.
1. Zawgyi 인코딩 텍스트 미얀마에서는 오랫동안 유니코드 표준이 아닌 Zawgyi라는 비표준 폰트 인코딩이 사실상 표준처럼 쓰였어요. Zawgyi는 '눈에 보이는 순서대로' 글자를 저장해요. 예를 들어 모음 ေ는 유니코드에서는 자음 뒤에 저장하고 화면에는 자음 앞에 그리는데, Zawgyi 텍스트는 화면 순서대로 앞에 저장해 버려요. 유니코드 셰이핑 엔진 입장에서는 '자음도 없는데 모음 부호가 먼저 나왔네?'가 되는 거죠. 미얀마는 2019년에 정부 차원에서 유니코드 전환을 추진했지만, 그전에 쌓인 콘텐츠는 여전히 많아요.
2. 글자 단위 폰트 폴백 기본 폰트에 없는 글자를 다른 폰트로 대신 그리는 걸 폴백(fallback)이라고 하는데요. 렌더링 도구가 이걸 글자 하나하나 단위로 처리하면, 자음은 A 폰트로, 거기 붙는 모음 부호는 B 폰트로 쪼개질 수 있어요. 그러면 결합 기호가 기준 글자와 떨어져 홀로 남고, 점선 원이 나타나요.
3. 셰이핑을 제대로 지원하지 않는 렌더링 경로 브라우저에서는 멀쩡한데, 서버에서 OG 이미지나 PDF를 만드는 라이브러리가 복합 문자 셰이핑을 충분히 지원하지 않는 경우도 많아요.
해결도 이 순서를 따라가면 돼요. 구글이 공개한 myanmar-tools 같은 라이브러리로 Zawgyi 여부를 감지해 유니코드로 변환하고, 폴백은 글자가 아니라 문자 클러스터(함께 그려져야 하는 글자 묶음) 단위로 처리하고, 미얀마어 전용 폰트(예: Noto Sans Myanmar)를 명시적으로 지정하는 거죠. DatoCMS가 실제로 어떤 원인을 찾아 어떻게 고쳤는지는 원문에 자세히 나와 있어요.
남 얘기가 아니에요: 한글도 비슷한 문제를 겪어요
미얀마어만의 일 같지만, 한국 개발자들도 비슷한 일을 자주 겪어요. 대표적인 게 맥에서 올린 파일 이름의 자소 분리예요. macOS에서 만들어진 파일명은 자모를 쪼개서 저장하는 NFD 방식인 경우가 많아서, 윈도우나 웹에서 보면 'ㅎㅏㄴㄱㅡㄹ'처럼 풀어져 보이죠. 눈으로는 같은 글자인데 저장 방식이 달라서 검색이나 비교가 실패하기도 하고요. 옛한글처럼 첫가끝 자모를 조합해야 하는 경우엔 폰트와 셰이핑 엔진이 받쳐주지 않으면 제대로 안 보여요.
결국 교훈은 같아요. 텍스트는 단순한 바이트 나열이 아니라 규칙이 있는 구조예요. 화면에 보이는 모양과 저장된 순서가 다를 수 있다는 걸 늘 염두에 둬야 해요.
실무 체크리스트
동남아 시장에 진출하는 서비스가 늘면서 태국어, 크메르어, 미얀마어 지원이 필요한 경우도 많아지고 있어요. 이럴 때 이런 것들을 점검해 보세요.
마무리
한 줄 정리: 네모 박스는 '폰트가 없다'는 신호, 점선 원은 '글자 순서나 묶음이 틀렸다'는 신호예요.
여러분은 다국어 서비스를 만들면서 겪은 가장 황당한 텍스트 깨짐 경험이 있으신가요? 맥 파일명 자소 분리 문제는 어떻게 해결하고 계신지도 궁금해요!
🔗 출처: Hacker News