시스템 폰트 쓰면 정말 촌스러울까

"웹폰트 안 쓰면 촌스러워 보인다." 디자인 커뮤니티에서 꽤 오래된 통념이다. 그런데 이 말을 철석같이 믿는 사람 앞에 Apple.com 소스를 열어 보여주면 대화가 멈춘다. 세계에서 가장 까다롭게 디자인한다는 회사가 시스템 폰트를 쓰고 있으니까. GitHub도 마찬가지다. 이 통념, 어디서부터 어떻게 틀렸는지 짚어보자.

이 통념은 2000년대 기억에서 왔다

틀린 통념에는 대부분 맞았던 시절이 있다. "시스템 폰트 = 촌스럽다"는 인식도 그렇다.

2000년대 초반 웹에서 쓸 수 있는 폰트라고는 굴림, 돋움, Arial, Times New Roman 정도가 전부였다. 굴림은 작은 크기에서 픽셀이 뭉개졌고, Arial은 아무 개성이 없었다. 그 시대에 웹폰트는 말 그대로 구원이었다.

하지만 2010년대 이후 상황이 조용히 달라졌다. Apple은 macOS와 iOS에 San Francisco를 내장했고, Microsoft는 Segoe UI를, Google은 Roboto를 각 OS에 탑재했다. 각 회사가 수년과 막대한 투자를 들여 개발한 폰트들이 운영체제 안에 이미 들어가 있다. "시스템 폰트 = 굴림" 시대는 오래전에 끝났는데, 통념은 그 시절에 멈춰 있는 경우가 많다.

Apple과 GitHub는 왜 웹폰트를 안 쓰나

WebKit 팀의 공식 블로그에 따르면, -apple-system은 macOS와 iOS에서 San Francisco가 렌더링되도록 하는 CSS 값이다. Apple.com 자체도 이 값을 쓴다.

GitHub의 body 폰트 선언을 꺼내보면 이렇다.

font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif;

Mac에서는 San Francisco, Windows에서는 Segoe UI, Android에서는 Roboto가 뜨도록 짜인 폴백 체인이다. 이게 "개성 없는 기본값"이 아니라 의도된 설계다.

그 이유는 성능에 있다. 웹폰트는 파일을 받아야 쓸 수 있는데, 한국어 폰트는 영문 폰트보다 구조적으로 훨씬 무겁다. 최적화 후에도 100KB를 가뿐히 넘는 경우가 많다. 시스템 폰트는 이미 기기 안에 있으니 네트워크 요청 자체가 없다. 로딩 비용이 0이라는 얘기다.

FOUT와 FOIT 문제도 없다. FOUT(Flash of Unstyled Text)는 웹폰트가 로드되기 전에 대체 폰트가 먼저 보이다 갑자기 바뀌는 현상이고, FOIT(Flash of Invisible Text)는 폰트를 기다리는 동안 텍스트가 아예 안 보이는 현상이다. 시스템 폰트는 페이지가 뜨는 순간 텍스트가 완성된 상태로 나타난다.

San Francisco는 Apple이 Retina 디스플레이에 맞게 힌팅과 렌더링을 직접 다듬은 폰트다. 서드파티 웹폰트가 그 완성도를 재현하는 건 생각보다 쉽지 않다. OS 수준의 렌더링 최적화까지 딸려온다는 게 시스템 폰트의 숨겨진 강점이다.

한국어 환경에서 이 통념이 특히 위험한 이유

현대 한국어 글자 수는 자음·모음·받침 조합 기준으로 11,172자에 달한다. 영문 알파벳 26자와는 규모 자체가 다르다. 그래서 한국어 웹폰트 파일은 구조적으로 무거울 수밖에 없다. 서브셋(subset)을 만들어 자주 쓰는 글자만 추려도 수십 KB에서 수백 KB가 나온다.

모바일 환경이나 네트워크가 불안정한 상황에서는 이 무게가 체감으로 느껴진다. 폰트가 내려받히는 동안 텍스트가 안 보이거나 순간 다른 폰트로 깜빡이다 바뀌는 경험 — 독자 이탈로 이어지기 딱 좋다.

반면 macOS의 Apple SD 산돌 고딕 Neo, Windows의 맑은 고딕은 과거 굴림·돋움과 비교 자체가 안 된다. 맑은 고딕은 Microsoft와 산돌이 협업해 만든 폰트로, ClearType 렌더링 환경에서 가독성이 뛰어나다. "시스템 폰트가 어색하다"는 인상은 대부분 오래된 기억에서 온다.

성능이 민감한 한국어 사이트라면, 시스템 폰트 스택만으로 충분한 경우가 생각보다 많다.

시스템 폰트를 제대로 쓰려면 선언이 맞아야 한다

시스템 폰트를 쓴다고 자동으로 예뻐지지는 않는다. 선언과 세팅이 제대로 맞아야 한다.

font-family 선언부터 순서를 챙겨야 한다. system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif 순서로 적으면 각 플랫폼에서 그 OS의 기본 UI 폰트가 선택된다. 폴백 체인 하나라도 빠지면 의도치 않은 폰트가 튀어나오거나 브라우저 기본값이 그냥 올라온다.

line-height와 letter-spacing 조정도 빠지면 안 된다. 시스템 폰트마다 자간과 행간 기본값이 다르다. macOS에서 예쁘게 보이던 레이아웃이 Windows에서 뭉쳐 보이는 건 대개 line-height를 고정값으로 써서 생기는 문제다. 배율 기반(line-height: 1.6~1.7)으로 지정하면 플랫폼 간 편차가 줄어든다.

font-weight도 한 번 확인할 만하다. San Francisco는 OS 수준에서 weight별 최적 폰트를 자동으로 고르지만, 일부 구형 Android 환경에서는 700 이상의 bold가 제대로 표현되지 않는 경우가 있다.

그래도 웹폰트가 맞는 경우는 따로 있다

통념이 틀렸다고 해서 웹폰트가 쓸모없다는 얘기는 아니다. 시스템 폰트가 못 하는 게 분명히 있다.

폰트 자체가 브랜드 아이덴티티의 일부일 때다. 특유의 둥글둥글한 전용 폰트, 세리프로 고급감을 잡아야 하는 경우처럼 폰트가 브랜드를 구성한다면 San Francisco나 Segoe UI 같은 투명한 폰트는 그 역할을 못 한다.

마케팅 랜딩 페이지처럼 픽셀 단위 일관성이 요구될 때도 있다. 시스템 폰트는 Mac과 Windows에서 서로 다른 폰트가 렌더링되기 때문에, 모든 기기에서 완전히 동일한 타이포그래피를 원한다면 웹폰트를 써야 한다. 인쇄물·영상과 타이포그래피를 통일해야 할 때도 마찬가지다.

이런 이유 없이 그냥 "웹폰트 안 쓰면 촌스럽다"는 느낌으로 쓰고 있다면, 한 번쯤 다시 생각해볼 만하다.

웹폰트를 써야 하는 상황이라면, 폰트비에서 사용 범위와 라이선스를 먼저 살펴보는 걸 권한다. 상업용·웹사이트 사용이 가능한지 모르고 쓰다가 나중에 문제가 생기는 경우가 적지 않다. 폰트를 고르는 것만큼, 쓸 수 있는지 확인하는 과정도 중요하다.