웹폰트는 어떻게 당연한 것이 됐을까 — W3C가 돌아본 WOFF 1.0의 여정

웹사이트에 원하는 폰트를 자유롭게 쓰는 것, 지금은 너무 당연한 일이죠. Google Fonts에서 골라서 링크 한 줄 넣으면 끝이니까요. 그런데 W3C가 최근 블로그에서 이 당연함을 만들어낸 표준, WOFF 1.0의 여정을 돌아보는 글을 올렸어요. 사실 웹에서 폰트를 마음껏 쓸 수 있게 되기까지는 10년 넘게 이어진 포맷 전쟁과 폰트 회사들의 저항이 있었거든요. 오늘은 이 이야기를 한번 풀어볼게요.

웹폰트가 없던 시절, 무슨 일이 있었냐면요

1990년대 후반, CSS2 명세에는 이미 @font-face라는 문법이 들어 있었어요. 이게 뭐냐면, '이 웹페이지는 서버에 있는 이 폰트 파일을 내려받아서 써라'라고 브라우저에게 알려주는 규칙이에요. 그러니까 기술 자체는 거의 30년 전에 준비돼 있었던 셈이죠. 그런데 왜 안 쓰였을까요? 두 가지 문제가 있었어요.

첫째는 포맷 전쟁이었어요. 마이크로소프트는 EOT라는 자기들만의 포맷을 밀었고, 넷스케이프 진영은 TrueDoc이라는 다른 기술을 썼어요. 브라우저마다 지원하는 포맷이 달라서 개발자 입장에서는 쓸 방법이 없었죠. 둘째는 폰트 회사들의 반발이었어요. 폰트는 만드는 데 수년이 걸리는 지식재산인데, TTF 파일을 서버에 그냥 올려두면 누구나 다운받아서 무단으로 쓸 수 있잖아요. 그래서 폰트 회사들은 웹용 라이선스를 내주지 않았고, 웹은 Arial, Georgia 같은 몇 개의 '웹 안전 폰트'에 갇혀 있었어요. 디자이너들이 예쁜 제목을 쓰려고 텍스트를 통째로 이미지로 만들어 올리던 시절이 바로 이때예요.

WOFF는 이 문제를 어떻게 풀었을까요

2009년, Mozilla의 Jonathan Kew와 폰트 디자이너 Tal Leming, Erik van Blokland가 WOFF(Web Open Font Format)를 제안해요. 아이디어가 꽤 실용적인데요, 새로운 폰트 기술을 만든 게 아니라 기존 TTF/OTF 폰트를 감싸는 '포장지'를 만든 거예요.

기술적으로 보면 이래요. TTF나 OTF 폰트 파일은 내부적으로 sfnt라는 구조로 돼 있는데, 글자 모양 데이터, 자간 정보, 힌팅 정보 같은 것들이 여러 개의 테이블로 나뉘어 담겨 있어요. WOFF는 이 테이블들을 각각 zlib으로 압축해서 다시 묶은 포맷이에요. 파일 전체를 통째로 압축하는 것과 뭐가 다르냐면, 테이블 단위로 다루니까 구조를 그대로 유지하면서 전송 크기를 줄일 수 있고, 여기에 라이선스 정보와 제작자 정보를 담는 메타데이터 블록을 추가할 수 있다는 점이 달라요.

재미있는 건 WOFF가 DRM, 그러니까 복제 방지 기술이 아니라는 점이에요. 마음만 먹으면 WOFF를 다시 TTF로 되돌릴 수 있거든요. 대신 '데스크톱용 폰트 파일을 그대로 올린 건 아니다'라는 최소한의 구분을 만들어서 폰트 회사들에게 명분을 준 거예요. 이 절묘한 타협 덕분에 폰트 회사들이 드디어 웹 라이선스를 팔기 시작했고, 브라우저 벤더 전부가 합의한 첫 웹폰트 포맷이 탄생했어요. WOFF 1.0은 2012년 12월에 W3C 정식 권고안이 됐고요.

그 다음 이야기, WOFF2

WOFF 1.0이 길을 닦은 뒤에는 구글이 Brotli라는 더 강력한 압축 알고리즘을 들고 나오면서 WOFF2가 만들어졌어요. WOFF1 대비 평균 30% 정도 파일이 더 작아졌고, 지금은 사실상 WOFF2가 표준이에요. 요즘 여러분이 Google Fonts에서 받는 폰트가 전부 WOFF2죠. 모든 모던 브라우저가 지원하니까, 이제는 WOFF2 하나만 서빙해도 충분한 시대가 됐어요. 표준 하나가 자리를 잡으니 그 위에서 가변 폰트(하나의 파일로 굵기와 너비를 자유롭게 조절하는 기술) 같은 다음 혁신이 이어진 것도 눈여겨볼 부분이에요.

한국 개발자에게는 더 각별한 이야기예요

사실 웹폰트 최적화는 한글을 쓰는 우리에게 훨씬 절실한 주제인데요. 영문 폰트는 글자 200~300자면 충분하지만, 한글은 완성형 기준으로 11,172자나 되거든요. 그래서 한글 폰트는 원본이 수 MB씩 나가요. Pretendard 같은 인기 폰트가 유니코드 범위별로 파일을 잘게 쪼개서 제공하는 서브셋 방식, CSS의 unicode-range로 화면에 필요한 조각만 내려받게 하는 기법이 전부 이 문제를 풀기 위한 거예요. WOFF2 압축과 서브셋을 조합하면 무거운 한글 웹폰트도 첫 화면 기준 수십 KB 수준으로 줄일 수 있어요. 내 서비스의 폰트 로딩이 느리다면, 오늘 이야기한 포맷의 원리를 아는 것만으로도 최적화 포인트가 보일 거예요.

정리하면요

WOFF는 화려한 신기술이 아니라, 기술 문제와 이해관계의 충돌을 '적당한 포장지 하나'로 풀어낸 표준화의 모범 사례예요. 좋은 표준은 모두가 조금씩 양보할 수 있는 지점을 찾는 데서 나온다는 걸 보여주죠. 여러분의 프로젝트에서는 한글 웹폰트 최적화를 어떻게 하고 계신가요? 서브셋, unicode-range, 가변 폰트까지 써보신 경험이 있다면 댓글로 공유해주세요.