타입 스케일: 13단계를 선택한 이유와 비율이 중요한 이유

Robert Bringhurst의 The Elements of Typographic Style은 조화로운 타이포그래피 관계가 음악에서 발견되는 것과 동일한 수학적 비율을 따른다는 것을 확립했습니다: 완전 4도(1.333), 완전 5도(1.5), 그리고 황금 비율(1.618). 저는 완전 4도에서 시작했지만 어떤 표준 비율로도 만들어낼 수 없는 커스텀 프로그레션으로 끝났습니다 — 콘텐츠 구조가 본문과 디스플레이 헤드라인 사이에 특정 단계를 요구했기 때문입니다.¹

TL;DR

타입 스케일은 기본 크기와 수학적 비율로부터 폰트 크기의 위계를 생성합니다. blakecrosley.com의 타이포그래피 시스템을 구축한 후 — 시스템 폰트만을 사용하여 0.75rem(12px)에서 5rem(80px)까지 13단계 — 비율보다 본문과 H1 사이의 단계가 더 중요하다는 것을 배웠습니다. 제 스케일은 인접한 단계 사이에 대략 1.18 프로그레션을 사용하지만, 콘텐츠 구조가 시각적 분리를 요구하는 곳에서는 의도적인 점프(3.875rem에서 5rem으로)를 적용합니다. 아래의 인터랙티브 비교는 엄격한 비율과 콘텐츠 기반 조정 사이의 차이를 보여줍니다.

제 타입 스케일: 13단계

다음은 제 사이트의 critical.css에서 가져온 실제 스케일입니다:

:root {
  --font-size-xs:      0.75rem;   /* 12px — metadata, timestamps */
  --font-size-sm:      0.875rem;  /* 14px — captions, fine print */
  --font-size-base:    1rem;      /* 16px — body text, default */
  --font-size-lg:      1.125rem;  /* 18px — lead paragraphs */
  --font-size-xl:      1.3125rem; /* 21px — large body, section intro */
  --font-size-2xl:     1.5625rem; /* 25px — H4, card titles */
  --font-size-3xl:     1.875rem;  /* 30px — H3 */
  --font-size-4xl:     2.25rem;   /* 36px — H2 */
  --font-size-5xl:     2.7rem;    /* 43.2px — H1 */
  --font-size-6xl:     3.25rem;   /* 52px — large H1 */
  --font-size-7xl:     3.875rem;  /* 62px — page title */
  --font-size-display: 5rem;      /* 80px — hero headline */
}

인접한 단계 사이의 프로그레션은 엄격한 수학적 비율이 아닙니다. xs에서 xl까지의 단계는 대략 1.17-1.18배를 따릅니다. 5xl에서 display까지의 단계는 더 공격적으로 점프합니다(1.20-1.29배). 히어로 헤드라인이 페이지 수준의 제목과 시각적으로 분리되어야 하기 때문입니다.²

엄격한 비율을 사용하지 않는 이유

엄격한 장3도(1.25)를 16px 기본 크기에 적용하면 다음과 같은 단계가 생성됩니다: 16, 20, 25, 31.25, 39.06, 48.83, 61.04. 본문(16px)에서 H3(31.25px)까지의 점프가 거의 2배에 달합니다 — H3가 자주 등장하는 콘텐츠 중심 페이지에서는 너무 극적입니다. 제 스케일은 중간 범위(18, 21, 25, 30, 36)를 압축하여 제목이 본문에 비례하도록 유지하면서, 상단 범위(43, 52, 62, 80)는 디스플레이 타이포그래피를 위해 확장합니다.

콘텐츠 구조가 스케일을 결정했지, 수학이 결정한 것이 아닙니다. 모든 단계를 실제 블로그 포스트 콘텐츠에 대해 테스트했고, 눈 흐리게 보기 테스트에서 실패한 곳의 크기를 조정했습니다.³

시스템 폰트를 사용하는 이유

제 폰트 스택입니다:

:root {
  --font-family: -apple-system, BlinkMacSystemFont, "SF Pro Text",
                 "SF Pro Display", "Helvetica Neue", Arial, sans-serif;
}

성능 측면의 근거

시스템 폰트는 0밀리초 만에 로드됩니다. 네트워크 요청도, FOIT(보이지 않는 텍스트 깜빡임)도, FOUT(스타일 없는 텍스트 깜빡임)도 없습니다. 이 선택은 제 Lighthouse 성능 점수 100/100에 기여합니다.

커스텀 웹 폰트는 폰트 파일 다운로드와 브라우저 렌더링 결정으로 인해 일반적으로 First Contentful Paint에 100-300ms를 추가합니다. Google Fonts는 CDN에서 로드됩니다(최소 DNS 조회 1회 + HTTP 요청 1회). 자체 호스팅 폰트는 DNS 조회를 제거하지만 여전히 다운로드가 필요합니다. 시스템 폰트는 폰트 로딩 지연 시간의 모든 구성 요소를 제거합니다.⁴

디자인 측면의 근거

시스템 폰트는 플랫폼과 일치합니다. macOS에서 제 사이트는 SF Pro로 렌더링됩니다 — macOS 시스템 UI, Apple Mail, Safari 크롬에서 사용되는 것과 동일한 서체입니다. 운영 체제와 웹사이트 사이의 시각적 연속성은 브랜드화된 느낌이 아닌 네이티브한 느낌을 줍니다.

Linear, Vercel, Raycast도 같은 접근 방식을 사용합니다. 이 패턴은 제 16개 프로덕트 디자인 스터디에서 발견한 것입니다: 브랜드 표현보다 콘텐츠 가독성을 우선시하는 프로덕트는 시스템 폰트를 사용하는 경향이 있습니다.

커스텀 폰트가 가치 있는 경우

커스텀 폰트는 마케팅 페이지, 브랜드 아이덴티티, 그리고 서체 자체가 디자인인 디스플레이 타이포그래피에 적합합니다. 제 사이트는 콘텐츠 중심(블로그 포스트, 프로젝트 설명)이므로, 타이포그래피는 투명해야 합니다 — 독자는 콘텐츠를 처리해야지, 폰트를 인식해서는 안 됩니다.

굵기 시스템

네 가지 굵기로 모든 위계 요구 사항을 처리합니다:

:root {
  --font-weight-normal:   400;  /* Body text */
  --font-weight-medium:   500;  /* Navigation, labels */
  --font-weight-semibold: 600;  /* Subheadings, emphasis */
  --font-weight-bold:     700;  /* Headlines, primary actions */
}

13개의 크기 단계와 4개의 불투명도 티어를 결합하면, 208가지 잠재적 조합(13개 크기 × 4개 굵기 × 4개 불투명도)이 가능합니다. 실제로는 약 15가지 조합을 일관되게 사용합니다. 이 시스템은 모든 텍스트 인스턴스에서 결정을 요구하지 않으면서도 유연성을 제공합니다 — 대부분의 텍스트는 base 크기, normal 굵기, primary 불투명도를 사용합니다.⁵

반응형 타이포그래피

단일 비율의 문제점

데스크톱용으로 설계된 타입 스케일은 모바일에서 과도하게 큰 제목을 만들어냅니다. 80px의 display 크기는 1440px 뷰포트에서는 아름답게 채워지지만 375px 휴대폰 화면에서는 압도적입니다. 전체 시스템을 뷰포트 단위로 스케일링하는 대신, 특정 브레이크포인트를 오버라이드합니다:

@media (max-width: 1024px) {
  .hero__title { font-size: var(--font-size-6xl); }  /* 52px */
}

@media (max-width: 768px) {
  .hero__title { font-size: var(--font-size-3xl); }  /* 30px */
}

본문 텍스트는 모든 뷰포트에서 16px를 유지합니다 — 본문 텍스트는 16px가 모든 현대 화면에서 가독성이 유지되므로 스케일링이 필요하지 않습니다. 디스플레이와 제목 크기만 작은 뷰포트에서 축소됩니다. 이 접근 방식은 유동적 타이포그래피(clamp())보다 단순하며, 알려진 브레이크포인트에서 예측 가능한 결과를 생성합니다.⁶

디스플레이 크기에서의 자간

큰 텍스트에는 더 좁은 트래킹이 필요합니다. 80px에서 기본 자간은 글자 사이에 눈에 띄는 간격을 만들어냅니다:

.hero__title {
  font-size: var(--font-size-display);
  font-weight: var(--font-weight-bold);
  letter-spacing: -0.03em;
  line-height: 1.05;
}

-0.03em 자간과 1.05 행간은 촘촘하고 임팩트 있는 헤드라인을 만들어냅니다. 16px의 본문 텍스트는 가독성을 위해 기본 자간과 넉넉한 1.7 행간을 사용합니다. 촘촘한 헤드라인과 여유로운 본문 텍스트 사이의 대비가 장식 없이도 시각적 리듬을 만들어냅니다.⁷

타이포그래피 테스트

눈 흐리게 보기 테스트

눈을 흐리게 하거나 화면에서 한 발 뒤로 물러서세요. 제목 위계는 모든 레벨에서 시각적으로 구별되어야 합니다. H3와 H4가 섞여 보인다면, 선택한 폰트에 비해 비율이 너무 작은 것입니다.

제 스케일에 눈 흐리게 보기 테스트를 적용했을 때, --font-size-xl(21px)과 --font-size-2xl(25px)이 처음에는 구별되지 않는 것을 확인했습니다. 굵기 차이를 추가하여(xl은 normal 400, 2xl은 semibold 600) 크기를 변경하지 않고도 구별을 해결했습니다. 굵기는 크기와 독립적으로 위계를 제공합니다.⁸

콘텐츠 테스트

모든 제목 레벨에 실제 콘텐츠를 적용하세요. 플레이스홀더 텍스트는 위계 문제를 가립니다. “Lorem Ipsum”은 실제 언어의 시각적 굵기 변화가 없기 때문입니다. 저는 모든 스케일 조정을 가장 긴 블로그 포스트(해밍 오류 정정, H2, H3, H4, 코드 블록, 표, 각주를 포함한 2000단어 이상)에 대해 테스트합니다. 스케일이 가장 복잡한 콘텐츠에서 작동한다면, 모든 콘텐츠에서 작동합니다.

핵심 요약

디자이너를 위한 조언: - 기본 크기 16px에서 시작하여 실제 콘텐츠에 대해 1.15에서 1.25 사이의 비율을 테스트하세요. 엄격한 수학적 비율은 극단에서 콘텐츠 기반 조정이 필요한 경우가 많습니다 - 확정하기 전에 눈 흐리게 보기 테스트와 콘텐츠 테스트를 사용하세요. 모든 제목 레벨에서의 시각적 구별이 수학적 순수성보다 중요합니다

개발자를 위한 조언: - 타입 스케일을 :root 레벨의 CSS 커스텀 프로퍼티로 정의하세요. 코드베이스 전체에서 var(--font-size-*)를 참조하면 임의의 폰트 크기가 쌓이는 것을 방지할 수 있습니다 - 커스텀 웹 폰트 전에 시스템 폰트를 고려하세요. 100-300ms의 폰트 로딩 절감은 모든 페이지 로드에 걸쳐 복리로 쌓이며, 시스템 폰트는 플랫폼 네이티브 가독성을 제공합니다 - 알려진 너비에서의 예측 가능한 결과가 부드러운 보간보다 중요하다면, 유동적 타이포그래피 대신 디스플레이 크기에 브레이크포인트 오버라이드를 사용하세요

참고 문헌