ZEN of UX. 29 - 폰트 임베드의 장단점과 유의사항

최근 SNS 상에서 가벼운 실랑이가 있었어.

한 UX 디자이너가 항간의 ‘밈’을 따라하며 - ‘UX디자이너입니다. 애플산돌고딕 쓰지 마세요’라고 글을 SNS에 올렸길래 깜짝 놀라 장문의 댓글을 달았지. 여러 번의 대화 끝에 상대의 의도를 파악할 수 있었는데 - 이 글을 올린이는, 윈도우 기반의 환경에서 애플산돌고딕을 사용할 수 없으니, 디자인할 때는 모든 환경에서 사용할 수 있는 (노토 같은) 범용 폰트를 사용하자는 얘기였더라구.

의도는 알겠어. 협업하는 디자이너들 중에서는 윈도우 사용자도 있을 테니, 그들을 위해서 맥 전용 폰트를 사용하지 말자는 얘기잖아. 하지만 오직 그것만을 위해서 맥 전용 폰트를 금지하고 공용 폰트만을 쓰자? (이 경우는 어느 쪽으로든 필연적으로 폰트 임베드가 필요하겠지) 이건 꼬리가 몸통을 흔드는 얘기잖아. 디자이너의 편의를 위해서 유저가 데이터 사용을 감내해야 할 이유는 전혀 없는 건데, 작업자 편하자고 폰트를 임베드한다고?

아무리 뻘소리가 난무하는 SNS라고 하더라도... 수많은 젊은 디자이너들이 모여있는 곳에 이렇게 잘못된 메시지를 보내는 것은 정말 위험하다 생각해서 꼰대처럼 상세하게 대답을 해주었고, SNS 상에서 여러 디자이너들과 상당히 토의한 끝에 - 많은 디자이너들이 생각보다 폰트에 대한 생각을 평면적으로 한다는 사실을 알게 됐어.

그래서 오늘도 꼰대로서, (앱, 웹에서) 커스텀 폰트를 사용하는 것에 대한 이야기를 해보려 해. 항상 하는 얘기지만, 내 얘기는 정답이 아니며, 단지 오래된 디자이너의 경험 정리라고 보는 게 나을 거야.

---

우선, 폰트의 가치와 임베드의 장점에 대해서 얘기하면 ;

텍스트는, 누가 뭐래도 ① 정보 표현의 최상위 포식자야. 아무리 영상이나 아이콘이 정보를 대체하고 있다 하더라도, 텍스트 정보의 위용은 다른 어떤 방법으로도 따라올 수 없지. 영상은 정보라기보단 플랫폼 안에서 소비되는 콘텐츠에 가깝고, 아이콘은 정보 속성보다 인지 속성 -이걸 누르면 좋아요 하나가 전달된다- 에 가깝지. 영상과 아이콘이 텍스트보다 직관적이고 활용도도 높은 건 사실이지만, 정보 전달 기능은 텍스트보다 약할 수밖에 없어. 그래서 서비스에서 폰트를 바라볼 때의 가장 중요한 부분은 가독성이고, 조금 더 나아가면 정보 위계 정의까지야. 

아이콘과 영상으로 이뤄진 틱톡과 유튜브 쇼츠

동시에 폰트는 ② 브랜딩과 UX의 접점이기도 해. 회사의 정체성을 문자 단위까지 정교하게 다듬고 싶은 회사들은 서비스에 쓰이는 폰트까지 모두 통제하려 들지. 대표적인 경우가 현대카드, G마켓, 외국 사례로는 우버 정도가 있을 거야.

좌측부터 배민, 지마켓, 우버

서체에 진심인 배민은 의외로 자신의 서비스에 배민 폰트를 제한적으로 사용해. 배민의 폰트는 가독성보다는 브랜딩에 가까우니까 정보 속성으로 쓰기엔 한계가 있는 거지. 그에 비해서 G마켓은, 폰트를 만들 때부터 브랜딩 속성보다는 정보 속성에 방점을 찍어서 만들어졌어. 그래서 당당히 상품명에 지마켓 산스를 쓸 수 있는 거고.

하지만 실무에서는, 위의 두 경우 말고도 다른 폰트 임베드의 니즈가 있는데, 바로 ③ 폰트 고정 목적이야. 이건 (OS 서체가 고정되어 있지 않은) 안드로이드 기기에서 발생해. 디자이너 관점에서는 이해하기 어려운^^ ‘이런 폰트를 핸드폰에 쓴다고?’ 하는 폰트들을 사람들은 의외로 많이들 사용하는데,

산돌구름 유튜브에서 발췌

이런 폰트로 자신의 앱을 보고 싶은 디자이너는 아마 없을 거야. ^^ 원칙적으로는 'Why not?' 이겠지만, 서비스의 성격과 폰트의 뉘앙스가 너무 다르면 노토나 프리텐다드 등의 일반 고딕 폰트로 고정하곤 하지.

---

폰트 임베드는 정보를 서비스에 가장 적합한 형태로 출력하면서도 서비스 성격을 강화하는 탁월한 장치야. 나 역시도 정말 많이 폰트를 임베드해서 사용했었어. 그런데 임베드를 하기 전에 반드시 확인해야 할 사항이 있어. 제법 많아.

1. 폰트 파일의 무게. 또는 로딩 속도의 문제

여전히 한글 폰트파일은 무게가 무거워. 극단적으로 용량을 줄인 폰트들도 종종 보이지만, 대부분 5~9mb 정도라고 생각하면 무난할 거야. 앱의 경우, 폰트를 원활하게 출력하려면 앱 내에 폰트를 담아 두어야 하는데, 앱의 무게는 꽤 민감한 문제라서 ‘폰트 때문에’ 앱 무게를 올리는 건 조금 고민할 필요가 있어. 요즘은 앱 자체의 무게 상한선도 많이 올라간 상태라서 한글 폰트 한두 개 임베드하는 건 큰 일이 아니지만, 유려한 표현을 위해서 light, regular, bold까지 넣으면 폰트 만으로 20~30mb가 더 생기는 일도 발생할지 몰라. 폰트 운용계획을 잘 설계해서 용량을 효율적으로 운용해야 해.

앱에 폰트를 임베드하지 않고 웹폰트를 사용하는 방법도 있는데, 웹에서는 거의 유일한 방법이지만, 로딩 완료 전에 출력되는 경우 폰트가 일시적으로 바뀌어 보이는 현상이 있어서 로딩 타이밍을 잘 조절하거나 프리로딩을 받도록 만들어야 해. 대신 (이론상) 무제한으로 폰트를 적용할 수 있다는 장점이 있지.

2. 없는 글자를 출력하는 경우

폰트 용량 때문에 작은 크기의 폰트를 찾다가 생기는 문제 중 하나가 바로 fallback 폰트를 출력하는 경우야. 맞는 글자형이 없어서 OS 폰트로 대체되는 현상을 말해. 대체되면 다행인데 tofu (네모박스에 x자가 그어진, 글자가 없다는 표시)가 나오는 경우는 좀 위험하지. 용량을 지나치게 압축한 한글 폰트의 경우, 일반적으로 많이 쓰이는 글자도 fallback 하는 경우가 있어.

여러가지 tofu의 형태

이건 숙련된 디자이너들도 점검하기 쉽지 않아서, 디자인 다 해놓고 상용화 한 뒤에 발견되는 경우도 허다해. 또한 꽤 많은 한글 폰트가 악센트 표기를 누락하곤 해. 글씨를 읽을 수야 있지만, 다른 폰트가 단어 사이에서 툭 튀어나오는 것은 그다지 유쾌한 경험은 아니지.

깨진 폰트의 예 - '정형돈의 제목없음TV (유튜브)'에서 발췌

그래서 서체를 임베드하기에 앞서 서비스의 언어적인 환경도 점검해야 해. 외국어 악센트가 많이 나오는 서비스인지, 한국어만 지원할 건지 다국어를 염두에 둔 서비스인지, 유저가 임베드된 폰트를 사용해서 글을 쓰는 기능이 있는지, 한글 고어가 나오는지 등등… 고려할 건 무지 많아. 글리프 수가 많은 폰트가 유리하겠지만, 대개의 상용 폰트들은 애초에 임베드를 목적으로 만들어지는 것이 아니기 때문에 함정은 곳곳에 있어.

지마켓 산스. 이런 글자들을 못쓰는 폰트 제법 많아.

3. 폰트 자체의 에러

3~4년 전만 해도 노토 폰트는 정말 최악이었어. 글씨 유닛의 높이 자체가 잘못 잡혀 있어서, 간격을 설정하거나 테이블을 재는 데 심각한 에러를 일으켰어. 지금이야 개선되었지만, 노토 말고도 많은 서체들이 나름의 에러를 갖고 있어. 특정 글자의 벡터가 깨져 있다던지, 특정 툴에서 에러를 일으키는 폰트도 제법 있어. 요즘에는 배리어블 폰트를 적용하는 방법에 대한 고민들이 여러 채널에서 이슈가 되고 있는데, 가까운 과거에는 토스 이모지 폰트가 실사용에 너무 불편하여 원성을 사기도 했었지.

예전의 노토 에러

---

간단한 정리;

당연하게도, 폰트 임베드는 대부분 심미성을 위한 결정이야. 그리고 필연적으로 OS 폰트보다 확장성이 부족할 수밖에 없어. 그래서 사실, 이론적으로는 폰트를 임베드하지 않는 게 가장 좋은 디자인이라 생각해. 그게 디자이너의 참 능력이기도 하고. 당신이 OS를 디자인하는 사람이 아니라면 말이지. 하지만, 임베드를 하고 싶다면 - 보다 상세하게 조건을 살핀 후에 적용하길 바라. 첫 결정이 잘못되면 엄청난 롤백을 경험하게 될 거야. ^^