온라인 폰트 서비스 (Cloud & Web) 분석
산돌구름과 typesquare을 중심으로…
산돌구름과 Typesquare 두 개의 서비스는 성향이 다릅니다. (산돌구름은 클라우드 방식의 폰트 서비스, Typesquare은 웹 폰트 서비스) 성향은 다르지만 둘 다 폰트를 암호화해서 제공한다는 점이 공통되었고 두 서비스를 분석해 보았습니다.
산돌구름
기존 폰트는 ttf 혹은 otf형식의 파일로 제공되나 별도의 DRM이 걸려있지 않기 때문에 파일이 유출되면 폰트제작사의 손실이 커집니다. 따라서 몇몇 대안으로 운영체제에 프로그램을 설치하고 인증받아 폰트를 인식시키는 방식이 쓰였으나 잦은 프로그램 꼬임과 폰트의 업데이트가 있을 시 반영하기 어렵다는 문제가 있습니다.
그래서 이를 보완해서 나온 것이 클라우드 방식의 폰트 서비스입니다. 매니저 프로그램을 설치하고 로그인을 하면 자신이 구매한 폰트리스트가 뜨며 선택적으로 적용 및 이용하면 됩니다. 클라우드 방식의 장점으로는 폰트의 업데이트가 있을 시에 신속하게 반영이 가능하고 저렴하고 합리적인 요금제로 다양한 폰트들을 사용할 수 있다는 점이 있습니다.
산돌구름은 폰트를 어떻게 제공할까?
여기서 산돌에서는 산돌구름을 통해 폰트를 어떻게 제공하는지 궁금했습니다. 클라우드라지만 폰트를 클라이언트에 다운로드하여야 하는데 이 과정이 어떻게 이루어지는지요.
폰트를 선택하고 적용 버튼을 누르면 먼저 산돌 구름의 CDN 서버에서 클라이언트로 폰트가 담긴 ZIP을 다운로드하고 압축을 풉니다.
압축을 풀면 otf건 ttf건 뒤에 s자가 붙은 확장자의 폰트 파일이 나옵니다. 확장자를 ttf 혹은 otf로 변경해도 정상적인 글꼴이 아니라며 설치가 되지 않습니다. 암호화가 된 것을 확인할 수 있습니다.
신기하게도 해당 암호화된 파일을 온라인 폰트 변환 사이트를 통해 변환을 시키면 변환이 됩니다.
변환된 폰트를 열어보면 정상적으로 나오지 않습니다. 하지만 Windows에서 제공하는 기본 폰트 뷰어에서는 별 오류 없이 나타나긴 합니다. (예시가 대체 글꼴로 나타나기는 하지만요)
암호화가 되어서 파일이 깨지거나 손상되었다면 올바르지 않은 글꼴이라는 오류가 나타나야 정상일 것 같은데 말이죠.
Fontlab으로 열어보았더니 그 이유를 알 수 있었습니다.
바로 폰트에 해당하는 방 번호(유니코드)가 지정되지 않았던 것입니다. 길 잃은 글리프들에 올바른 방 번호를 지정하면 정상적인 폰트로 사용할 수 있습니다. (물론 불법입니다. 합법적인 방법으로 구매하셔서 이용하시는 게 좋겠지요?)
결론
산돌구름의 암호화 방식은 글리프는 그대로 두고 글리프에 해당하는 방 번호들을 없애거나 특정 로직을 이용하여 치환해서 적용시키는 것 같다는 유추를 해봅니다.
Typesquare
Typesquare는 모리사와의 웹 폰트 호스팅 서비스입니다. 보통 웹 폰트는 용량이 큰 otf와 ttf를 베이스로 압축된 woff, woff2, eof(IE 전용)를 제공합니다.
하지만이 방식은 용량이 아무리 적어도 DRM이 적용되지 않는 RAW 포맷이기 때문에 보호할 수 없는 단점이 있습니다.
웹 폰트에 관한 기본 개념과 문제점은 «새로운 웹폰트서비스 - ag 타이포그라피연구소»를 참고해 보세요.
Google Webfont에서 기본으로 제공하는 방식은 위에서 알려드린 ttf, otf, woff, woff2 등을 사용합니다. Typesquare에서는 별도의 API를 통해 웹 폰트를 제공하고 있었고 분석해 보았습니다.
모든 폰트를 임베드하지 않고, 필요한 글자만 선택적으로 임베딩
Typesquare에서는 선택한 폰트의 폰트 파일 자체를 가져오는 것이 아닌, Javascript를 이용하여 해당 웹 문서에 들어있는 글자 수를 인식하고 그 글자 수에 해당하는 폰트만 Base64 형식으로 가져옵니다.
물론 아무 곳에서나 폰트를 적용할 수 없게 API를 이용해 도메인을 인식하여 서버에 등록된 URL인지를 확인하여 제공합니다.
API에 넘길 수 있는 글자 수 제한도 있습니다. 혹시나 해서 한글 2,350자만을 추려서 임의로 넣었지만 가져오지 못했습니다. 글자 수를 줄이면 정상적으로 가져왔고요…
결론
어떻게 보면, 필요한 글자만 가져와서 선택적으로 적용하는 데 있어 네트워크의 자원을 아낄 수 있다는 점 (방문자 수가 많은 사이트라면 트래픽도 고려해야겠지요.), ttf나 otf와 달리 어느 정도 보호할 수 있다는 장점이 있습니다.
하지만 Javascript에 의존한다는 점과 Base64로 가져오는 만큼 아무리 선택적으로 폰트를 가져온다 한들 원래의 포맷보다 용량이 크다는 단점이 있겠습니다.
마무리
개인적으로 Typesquare의 방식이 끌리는데요, 모바일 웹에선 속도가 생명이라 폰트 하나만 넣어도 그 차이가 큽니다. 현재까지 통용되는 방식이라곤 폰트 파일에서 가장 사용 빈도가 높은 일부 글리프만 남겨두고 삭제하는 식으로 용량을 줄이지만 그래도 한계가 존재합니다.
차라리 Typesquare처럼 문서에 존재하는 글리프만 추려서 선택적으로 가져온다면 트래픽 절감에 큰 도움이 되지 않을까 생각해 봅니다.