느린 연결에서 내 사이트를 열어본 날, 개발자 도구의 네트워크 목록에 이상한 줄 하나가 눈에 띄었다. 폰트 파일 하나가 이 메가바이트 넘게 내려오고 있었다. 이미지도 아니고 글씨체 하나가, 웬만한 사진 여러 장을 합친 것보다 무거웠다. 그리고 그 파일이 다 내려올 때까지, 화면의 글자는 텅 빈 채로 몇 초를 버텼다. 예쁜 글씨체를 얹었다는 뿌듯함이 그 몇 초 앞에서 와르르 무너졌다.
폰트는 반응형 이야기에서 자주 빠지는 주제다. 레이아웃이 잘 접히고 이미지가 잘 줄어들어도, 그 안에 담기는 글자가 제때 안 뜨거나 화면을 들썩이게 만들면 경험은 망가진다. 특히 한글은 다루는 글자 수가 워낙 많아 폰트 파일이 태생적으로 무겁다. 이번 편은 그 무거운 글씨체를 언제 불러오고, 언제 시스템에 이미 깔린 폰트에 기대야 하는지에 대한 이야기다.
1. 한글 폰트가 무거운 이유
영문 폰트와 한글 폰트는 체급이 다르다. 영문은 대문자, 소문자, 숫자, 기호를 다 합쳐도 글자 종류가 백 몇십 개면 충분하다. 그래서 영문 폰트 파일은 수십 킬로바이트로도 만들어진다. 한글은 사정이 전혀 다르다.
한글은 자음과 모음을 조합해 만드는 글자라, 실제로 쓰이는 완성형 글자만 헤아려도 만 자가 훌쩍 넘는다. 이 많은 글자를 하나하나 그려 담다 보니, 제대로 된 한글 폰트 하나가 굵기별로 수백 킬로바이트에서 메가바이트 단위로 커진다. 굵기를 여럿 쓰면 그만큼 파일이 배로 늘어난다. 나는 본문용, 제목용, 굵은 강조용으로 굵기를 세 개 얹었다가, 폰트만으로 몇 메가바이트를 내려받게 만든 적이 있다.
문제는 이 무게가 첫 화면 속도를 직접 갉아먹는다는 데 있다. 폰트가 다 안 내려오면 글자를 못 그리니, 사용자는 무거운 폰트가 도착할 때까지 텅 빈 화면이나 엉뚱한 임시 글씨를 본다. 데스크톱 광랜에서는 눈 깜짝할 새라 못 느끼지만, 지하철에서 느린 연결로 접속한 사람에게는 이 몇 초가 고스란히 기다림이 된다. 나는 폰트를 고를 때 이제 생김새만큼이나 무게를 따진다.
여기에 요즘은 한 파일에 여러 굵기를 담는 방식도 있어서, 이걸 잘 쓰면 무게를 아낄 수 있다. 얇은 굵기부터 굵은 굵기까지를 각각 별도 파일로 받는 대신, 하나의 파일 안에서 굵기를 연속적으로 조절하는 것이다. 굵기를 두세 개 이상 쓴다면 이 방식이 여러 파일을 따로 받는 것보다 대체로 가볍다. 다만 이런 파일도 한글은 기본 무게가 있어서, 만능은 아니다. 나는 굵기가 정말 두세 개 넘게 필요한지부터 되묻고, 그렇지 않으면 굵기 하나로 버틴다.
2. 글자가 떴다 사라지는 순간
폰트를 내려받는 동안 브라우저가 글자를 어떻게 처리할지에는 몇 가지 갈래가 있고, 이 선택이 사용자 경험을 크게 가른다.
기본 동작 중 하나는 웹폰트가 도착할 때까지 글자를 아예 안 보여주는 것이다. 폰트가 늦으면 그동안 본문이 통째로 비어 보인다. 나는 이걸 모르고 두었다가, 느린 연결에서 사이트가 몇 초간 백지처럼 보이는 걸 겪었다. 글이 분명 있는데 글씨체를 못 구해서 안 보여주는, 어이없는 상황이었다.
다른 갈래는 폰트가 도착하기 전까지 시스템에 이미 있는 폰트로 글자를 우선 보여주고, 웹폰트가 도착하면 그때 갈아 끼우는 방식이다. 글자가 늦게라도 읽히니 백지보다는 훨씬 낫다. 다만 이 경우 폰트가 바뀌는 순간 글자가 살짝 출렁이는 게 보인다. 나는 이 출렁임을 감수하더라도, 글이 일단 읽히게 하는 쪽을 택한다. 안 보이는 완벽한 글씨보다, 보이는 임시 글씨가 낫다.
이 동작은 폰트마다 지정할 수 있다. 나는 본문처럼 반드시 빨리 읽혀야 하는 글에는 임시 폰트로 앞서 보여주는 쪽을 걸고, 아주 잠깐만 기다렸다가 그래도 안 오면 웹폰트를 포기하고 시스템 폰트로 눌러앉는 선택을 쓰기도 한다. 로고나 특정 제목처럼 그 글씨체가 꼭 필요한 곳에만 기다림을 허락하고, 나머지는 속도를 우선한다. 어디에 기다림을 허락할지를 정하는 게 이 설정의 핵심이다.
기본 동작을 그대로 두면 짧은 백지 시간 뒤에 웹폰트가 오면 쓰고, 너무 늦으면 임시 폰트로 넘어가는 절충이 걸리기도 한다. 문제는 이 짧은 백지 시간조차 느린 연결에서는 꽤 길게 느껴진다는 점이다. 나는 이 애매한 백지를 별로 좋아하지 않아서, 본문만큼은 아예 처음부터 임시 폰트로 보여주는 쪽을 명시적으로 걸어둔다. 사용자가 글을 읽기 시작하는 순간을 몇 밀리초라도 앞당기는 게, 글씨체가 곧바로 완벽하게 뜨는 것보다 중요하다고 보기 때문이다.
3. 시스템 폰트라는 든든한 선택
몇 번을 데고 나서 내가 도달한 결론 하나는, 웹폰트가 늘 정답은 아니라는 것이다. 사용자의 기기에는 이미 잘 만들어진 폰트가 깔려 있다. 그걸 그냥 쓰면 내려받을 파일이 아예 없다.
운영체제마다 기본으로 예쁜 폰트를 품고 있다. 이 기기 기본 폰트를 부르는 이름을 폰트 목록 맨 앞에 두면, 브라우저가 그 기기에 맞는 폰트를 알아서 골라 쓴다. 내려받기가 없으니 폰트 때문에 화면이 비는 일도, 무거운 파일로 속도가 처지는 일도 없다. 글자는 사이트를 여는 즉시 뜬다. 나는 이 즉시성이 주는 쾌적함을 한 번 맛보고 나서 시스템 폰트를 훨씬 자주 쓰게 됐다.
물론 대가가 있다. 기기마다 깔린 폰트가 다르니, 같은 화면이 아이폰과 안드로이드와 윈도우에서 조금씩 다른 글씨체로 보인다. 브랜드의 통일된 인상을 목숨처럼 여긴다면 이 차이가 거슬릴 수 있다. 하지만 나는 대부분의 서비스에서 이 차이가 사용자에게 별문제가 안 된다는 걸 경험으로 안다. 사용자는 자기 기기에 익숙한 글씨체로 글을 읽을 뿐, 이게 원래 무슨 폰트였는지는 궁금해하지 않는다.
시스템 폰트를 부를 때 한 가지 요령이 있다. 기기마다 기본 폰트를 가리키는 이름이 조금씩 다르기 때문에, 여러 기기의 이름을 순서대로 죽 나열해두는 것이다. 그러면 각 기기는 그 목록에서 자기가 아는 첫 이름을 집어 쓴다. 나는 이 목록을 한번 잘 짜두고 여러 프로젝트에서 재사용하는데, 데스크톱과 모바일에서 각기 가장 나은 기본 폰트가 자동으로 잡혀 손이 편하다.
한글에서는 여기에 한 가지를 더 챙긴다. 영문 이름만 나열하면 어떤 기기에서는 한글이 엉뚱한 폰트로 떨어질 수 있어서, 나는 한글이 잘 나오는 기기 기본 폰트 이름도 목록에 함께 넣는다. 영문은 세련된 폰트로, 한글은 또 다른 폰트로 각각 가장 나은 걸 물려받게 하는 것이다. 이 배합을 한번 잡아두면 기기가 달라져도 글자가 깨지거나 못나게 떨어지는 일이 준다.
그래서 나는 기본을 시스템 폰트로 깔고, 정말 브랜드를 드러내야 하는 소수의 요소에만 웹폰트를 아껴 쓴다. 본문 전체를 무거운 웹폰트로 도배하는 대신, 로고나 대표 제목 정도에만 특별한 글씨체를 허락하는 것이다. 이렇게 하면 무게는 최소로 줄이면서 개성은 필요한 곳에만 준다. 폰트는 전부 아니면 전무의 문제가 아니라, 어디에 얼마나 쓸지 배분하는 문제다.
4. 그래도 웹폰트를 써야 한다면
웹폰트를 포기할 수 없는 경우도 많다. 그럴 때 무게를 줄이는 방법들이 있다.
가장 효과가 큰 건 안 쓰는 글자를 덜어내는 것이다. 완성형 한글 만여 자를 다 담을 필요가 없는 경우가 대부분이다. 실제로 널리 쓰이는 몇천 자만 추려 담으면 파일이 눈에 띄게 가벼워진다. 특정 제목처럼 들어갈 글자가 정해져 있다면, 딱 그 글자들만 담아 파일을 극단적으로 줄일 수도 있다. 나는 이 덜어내기 하나로 폰트 파일을 몇 분의 일로 줄인 적이 있다. 안 쓰는 글자를 이고 지고 다닐 이유가 없다.
다만 덜어낼 때는 조심할 게 있다. 사용자가 만드는 글에는 내가 예상 못 한 희귀한 글자가 들어올 수 있다. 옛말이나 특수한 이름에 쓰이는 글자를 폰트에서 빼버리면, 그 글자만 다른 폰트로 뚝 떨어져 나와 어색해진다. 나는 내가 통제하는 고정된 문구에는 과감하게 글자를 추리되, 사용자가 무엇을 쓸지 모르는 본문 영역에는 넉넉한 범위를 남긴다. 어디까지 잘라도 되는지는 그 글자를 누가 채우느냐에 달렸다.
글자 영역을 쪼개 필요할 때만 내려받게 하는 방법도 있다. 폰트를 글자 범위별로 여러 조각으로 나눠두면, 브라우저는 실제로 화면에 나타난 글자가 든 조각만 골라 내려받는다. 한글이 안 나오는 페이지에서는 한글 조각을 아예 안 받는 식이다. 페이지마다 쓰는 글자가 다른 사이트에서 이 방식이 특히 요긴하다.
꼭 필요한 폰트는 일찍 내려받게 미리 알려두는 것도 좋다. 브라우저가 스타일을 다 해석한 뒤에야 폰트 주소를 발견하면 그만큼 시작이 늦는데, 이 폰트가 곧 필요하다고 문서 앞머리에서 귀띔해두면 다운로드가 앞당겨진다. 다만 이건 정말 첫 화면에 바로 쓰이는 핵심 폰트에만 쓴다. 아무 폰트나 다 미리 받으라고 하면 정작 중요한 자원과 경쟁해 오히려 느려진다.
폰트 형식도 챙긴다. 같은 글씨체라도 압축이 잘 되는 최신 형식으로 내보내면 파일이 더 작아진다. 요즘 브라우저는 웹용으로 압축된 형식을 잘 읽으니, 나는 무겁고 오래된 형식 대신 압축률 좋은 형식을 기본으로 쓰고, 아주 낡은 환경을 위한 폴백만 얇게 얹는다. 형식 하나 바꾸는 것만으로 같은 글씨체가 눈에 띄게 가벼워지는 경우가 많다.
폰트를 어디서 받아오느냐도 따져본다. 외부 서비스의 폰트를 링크로 불러오면 편하지만, 그만큼 남의 서버에 속도를 의존하게 된다. 나는 중요한 폰트는 내 서버에 직접 두고 내려받게 해서, 연결 지점을 하나로 줄이고 속도를 내 통제 아래 둔다. 편한 링크 한 줄이 때로는 첫 화면을 남의 손에 맡기는 일이 되기도 한다. 남의 서버가 느린 날, 그 느림은 고스란히 내 사이트의 흠으로 돌아온다.
5. 폰트가 바뀔 때의 들썩임
임시 폰트로 먼저 보여주고 웹폰트로 갈아 끼우는 방식에는 성가신 부작용이 하나 있다. 두 폰트의 글자 크기와 자간이 다르면, 폰트가 바뀌는 순간 글자들이 자리를 다시 잡으며 화면이 출렁인다. 읽던 줄이 갑자기 아래로 밀리거나 문단 높이가 바뀌는 이 들썩임은, 보는 사람에게 은근히 거슬린다.
나는 이 출렁임을 오래 어쩔 수 없는 것으로 여겼다. 그런데 임시 폰트와 웹폰트의 크기 감각을 맞추는 방법이 자리 잡으면서 사정이 나아졌다. 임시로 쓰는 시스템 폰트의 글자 높이나 폭을 웹폰트에 가깝게 미세 조정해두면, 나중에 폰트가 바뀌어도 글자가 차지하는 자리가 거의 안 변한다. 폰트는 바뀌되 레이아웃은 그대로인, 조용한 교체가 되는 것이다.
이 조정을 하려면 두 폰트가 실제로 얼마나 다른지를 봐야 한다. 나는 임시 폰트 상태와 웹폰트 적용 상태를 나란히 두고, 같은 문단의 높이가 얼마나 차이 나는지 눈과 숫자로 확인한 다음 그 간극을 메운다. 이 작업이 번거롭긴 해도, 첫 화면이 로딩 중에 덜컹이지 않는 값어치는 그 수고를 넘는다. 화면이 조용히 자리 잡는 그 안정감은 사용자가 의식하지 못하는 곳에서 신뢰를 쌓는다.
폰트를 다루면서 내가 얻은 태도는, 글씨체의 아름다움과 화면의 속도를 저울의 양쪽에 늘 함께 올려두는 것이다. 예전의 나는 예쁜 글씨체를 찾으면 무게는 보지 않고 덥석 얹었다. 지금은 이 글씨체가 정말 이 무게를 치를 값어치가 있는지, 시스템 폰트로 대신할 수는 없는지를 먼저 묻는다. 사용자는 내 폰트 취향을 감상하러 온 게 아니라 글을 읽으러 온 것이다. 글이 빨리 뜨고 편히 읽히면, 그 글씨체가 시스템 폰트인지 값비싼 웹폰트인지는 아무도 따지지 않는다. 다음 편에서는 그 글자와 그림이 놓이는 화면 자체가 제각각인 문제, 곧 세상의 다양한 화면비와 노치를 다룬다.