CSS font-family 권장 사항

• 웹에서 특정 폰트 이름을 믿고 디자인하면 플랫폼·네트워크·보안 설정에 따라 깨질 수 있어, 일반 계열 fallback을 전제로 font-family를 짜야 함
• 고정폭 표현이 필요한 코드·아트워크·레이아웃에는 monospace 를 반드시 포함해야 하며, serif와 sans-serif도 원하는 계열을 보장하려면 함께 지정하는 편이 안전함
• 로컬에 있을 법한 폰트를 길게 나열하는 스택은 대개 실익이 작고, 브라우저의 일반 계열 기본값이 더 나은 선택을 할 가능성도 있음
• 웹 폰트는 없는 경우보다 느리고 로딩 실패·font-display 절충을 만들기 때문에, 콘텐츠에는 사용자의 기본 폰트를 그대로 쓰는 선택도 현실적임
• system-ui와 ui-*는 짧은 UI 텍스트 성격이 강해 긴 콘텐츠와 언어 지원에 맞지 않을 수 있으며, 콘텐츠용 기본 폰트 대체 수단으로 쓰기엔 위험함

폰트 이름을 신뢰하지 않기

• 모든 주요 플랫폼에서 공통으로 제공되는 웹 안전 폰트는 없으므로, 특정 폰트 이름이 항상 동작한다고 가정하면 안 됨
• 웹 폰트도 확실한 해법은 아님
  • 인라인되지 않은 하위 리소스는 여러 네트워크 이유로 로드에 실패할 수 있음
  • 폰트 로딩은 보안 우려가 있는 영역이라 일부 환경에서 차단될 수 있음
  • uBlock Origin에는 원격 폰트를 비활성화하는 전용 버튼이 있음
  • 일부 브라우저의 데이터 절약 모드는 폰트 로딩을 막을 수 있으며, 막지 않는 경우도 막아야 한다는 입장임
• 사용자가 웹사이트의 자체 폰트 선택을 허용하지 않으면 일반 계열만 동작함
• JavaScript에서 document.fonts.load("1em my-web-font")를 쓰면 반환되는 Promise가 reject될 수 있음
  • 2020–2025년 6년 동안 이 문제로 깨진 사례를 약 4개 봤고, 그중 2개는 2025년에 발생함

대체 계열은 반드시 명시하기

• 고정폭 텍스트가 필요하면 font-family에 반드시 monospace 를 넣어야 함
  • monospace 누락은 많은 사용자에게 드러나지 않지만, 일부 환경에서는 레이아웃이나 작품의 의도를 망칠 수 있음
  • 예시로 Adel Faure의 ASCII might fly?는 작성 시점에 monospace가 빠져 있어 고정폭이 아닌 형태로 보일 수 있음
• serif나 sans-serif도 원하는 폰트 계열의 fallback이 필요하면 포함하는 편이 좋음
  • 예: font-family: Arial, sans-serif;
  • 예: font-family: Times New Roman, serif;
  • 넣지 않으면 기본 폰트를 쓰게 되며, 기본 폰트는 serif일 수도 있지만 전혀 다른 것일 수도 있음

설치됐을 법한 폰트 나열 줄이기

• Arial, Helvetica, Helvetica Neue, Liberation Sans, Noto Sans처럼 시스템에 있을 법한 폰트를 길게 나열하는 방식은 대체로 도움이 되지 않음
• 특히 Arial은 sans-serif보다 더 나은 선택이 될 일이 없다고 봄
• sans-serif는 명시한 폰트들보다 나쁘지 않은 폰트로 해석될 수 있고, 더 나은 폰트가 선택될 가능성도 있음
• 실제로 본 고정폭 선언 예시는 과도하게 긴 목록임
  • font-family: Menlo, Monaco, Lucida Console, Liberation Mono, DejaVu Sans Mono, Bitstream Vera Sans Mono, Courier New, monospace, serif
  • 이 선언은 font-family: monospace, monospace보다 엄격히 나쁘며, monospace는 이 목록보다 나쁘지 않은 폰트로 해석될 수 있음
• 이름 있는 비웹 폰트를 완전히 금지할 필요는 없지만, 최대 하나 정도가 적절함
  • Georgia)와 Times New Roman은 모두 Microsoft의 Core fonts for the Web에 속한 serif지만 성격이 다름
  • Georgia는 Times New Roman보다 훨씬 넓으므로, 스타일상 그 특성이 필요하면 font-family: Georgia, serif는 허용 가능한 선택임
• modernfontstacks.com과 저장소는 플랫폼별 폰트 선택 아이디어를 담고 있음
  • 다만 명명된 폰트를 지나치게 처방하며, 상당수는 제거하는 편이 낫다는 평가임
  • Courier New 처리는 크게 잘못됐고, 이미지가 macOS Courier로 만들어진 것처럼 보임

일반 계열만 쓰는 선택

• 로컬 설치 폰트 나열을 줄였다면, 웹 폰트도 꼭 필요한지 다시 볼 수 있음
• 웹 폰트는 웹 폰트가 없는 경우보다 느리고, 로딩 문제를 만들 수 있음
  • 이 때문에 font-display가 있음
  • 하지만 block·swap 기간, 다시 그리기, 리플로우 사이의 절충을 다루는 대신 사용자가 가진 폰트를 그대로 쓰는 선택도 가능함
• monospace도 일반 계열만 쓰는 선택이 가능함
  • 과거 monospace 기본값은 좋지 않았고, 특히 Microsoft의 Courier New#Courier_New)는 잘못 디지털화되어 400이 아니라 사실상 200–250 weight처럼 보였음
  • 이후 Apple이 Menlo)를 도입했고, 브라우저 기본 monospace가 갱신되지 않던 시기에 사람들이 폰트 스택에 Menlo를 넣기 시작함
  • 현재 브라우저 기본값은 모두 나아졌고, 모든 경우에 훌륭하지는 않아도 더 이상 나쁘지는 않음
• Menlo, Monaco, Consolas, Bitstream Vera Sans Mono, Courier, Courier New 같은 목록을 버리고 monospace만 남겨보는 선택이 가능함
• Courier New를 의도적으로 폰트 스택에 넣는 것은 강하게 부정적으로 평가됨

monospace, monospace와 브라우저 동작

• font-family: monospace;를 명시적 또는 암묵적으로 쓰면 font-size가 100%가 아니라 아마 81.25% 로 기본 설정될 수 있음
  • 사용자는 일반 계열 폰트, 기본 글자 크기, 기본 고정폭 글자 크기를 바꿀 수 있음
• 목록에 두 번째 family가 있으면 이 동작이 발생하지 않음
  • font-family: my-web-font, monospace;는 괜찮음
  • font-family: monospace, monospace;도 괜찮음
  • 직접 font-size를 지정하는 방법도 가능함
• Lightning CSS는 monospace, monospace를 망가뜨리는 문제가 있음
  • 관련 이슈: parcel-bundler/lightningcss#1221
  • 임시로 monospace, m을 쓰고 있음
• 이 문제는 monospace에만 영향을 줌
• 브라우저가 monospace 크기 동작을 버리고, 아마 13px인 값을 아마 16px로 올리도록 설득하고 싶다는 입장임
  • 제안 장소는 CSSWG가 될 수 있음

콘텐츠에 system-ui와 ui-* 쓰지 않기

• UI 폰트는 짧은 UI 텍스트용이지 긴 콘텐츠용이 아님
• UI 폰트는 콘텐츠 언어를 잘 지원하지 않을 수 있음
  • macOS는 이 부분이 괜찮지만 Windows는 그렇지 않다고 봄
  • 결과적으로 CJK 사용자가 좋지 않은 고정폭 폰트를 보게 되는 사례가 생길 수 있음
• 일부 사용자는 의도적으로 우스꽝스러운 시스템 UI 폰트를 골라두기도 하며, Android 일부 커뮤니티에서 꽤 흔하다고 함
  • system-ui를 쓰면 콘텐츠도 그렇게 보일 수 있다는 우려가 있음
• w3c/csswg-drafts issue #3658은 system-ui의 여러 문제를 논의했고, system-ui가 광범위하게 남용됐다는 결론을 담고 있음
• mdn/content issue #41244는 MDN에 과도한 사용을 경고하는 note를 추가함
• system-ui와 ui-*는 더 나은 기본 폰트를 얻기 위한 proxy처럼 쓰여왔지만, 이런 용도는 좋지 않음
• system-ui는 실수였다는 입장임
  • -apple-system만 남기고 BlinkMacSystemFont가 그것으로 바뀌게 했어야 한다는 견해임
  • 표준화 당시 다른 플랫폼에는 유용한 동등 개념이 없었고, 지금은 일부 플랫폼에 생겼다고 봄
  • 기존 일반 계열의 낡은 기본값을 브라우저가 갱신하지 않은 문제를 우회하려는 용도로 대부분 남용됐다고 봄
• ui-serif, ui-sans-serif, ui-monospace, 특히 ui-rounded는 제거돼야 할 명백한 실수라는 입장임
  • 비 Apple 환경에서는 어떤 폰트로도 매핑될 것으로 기대되지 않음
  • 개념 자체가 Apple 플랫폼에만 있으므로 표준에 포함되지 말았어야 함
  • Apple이 제공했다면 -apple-system처럼 -apple 접두 형태였어야 한다고 봄
• 웹 앱에는 system-ui의 정당한 사용 사례가 있지만, 실제로는 거의 전적으로 남용됐다는 인상이며 제거 개입도 나쁘지 않을 수 있음