{3줄 요약}

웹 타이포그래피는 고정 지면이 아닌 다양한 화면과 로딩 환경에서 글을 다뤄요.
웹폰트와 반응형 환경을 고려하지 않으면 읽기 전부터 흐름과 안정감이 깨져요.
이 특성을 알면 크기와 단위를 유연하게 설계해 웹에서도 읽힘을 지킬 수 있어요.

웹·브라우저 환경에서 폰트와 단위를 정할 때

웹사이트나 웹 앱을 만들 때, 또는 기존 웹 서비스의 폰트·텍스트 스타일을 정비할 때 이 방법을 써요.

모바일 앱(네이티브)은 시스템 폰트 기준이 고정되어 있어 이슈가 상대적으로 적어요.
하지만 웹은 브라우저, 기기, OS, 사용자 설정에 따라 텍스트가 다르게 보여요.
그래서 웹 타이포그래피는 더 많은 변수를 다뤄야 해요.

웹폰트 로딩이 UX에 영향을 주는 방식

웹폰트는 텍스트가 화면에 표시되기 전에 폰트 파일을 먼저 다운로드해야 해요.
이 과정에서 두 가지 현상이 생겨요.

FOIT (Flash of Invisible Text): 폰트가 다운로드되는 동안 텍스트가 아예 안 보여요.
사용자는 텍스트 없는 화면을 보다가 폰트가 뜨면서 갑자기 텍스트가 나타나는 경험을 해요.

FOUT (Flash of Unstyled Text): 폰트 다운로드 전에 시스템 기본 폰트로 텍스트를 먼저 보여주다가, 웹폰트가 로드되면 폰트가 교체되면서 레이아웃이 흔들려요.

둘 다 불편하지만, FOUT이 FOIT보다 낫다고 보통 평가해요.
텍스트가 안 보이는 것보다 잠깐 다른 폰트로 보이다가 교체되는 게 덜 당황스럽기 때문이에요.

해결 방법: CSS font-display: swap으로 FOUT을 선택하거나, font-display: optional로 폰트 로딩 실패 시 시스템 폰트를 그대로 쓰는 방식을 선택해요.

네이버 뉴스, 카카오 브런치 같은 한국 주요 서비스도 웹폰트 최적화에 많은 노력을 기울여요.
특히 한국어는 영어보다 글리프(각 글자의 모양) 수가 훨씬 많아서 폰트 파일이 무거워요.
서브셋 폰트(실제로 쓰는 글자만 포함한 경량 폰트)를 쓰는 게 일반적이에요.

px, em, rem: 어떤 단위를 써야 하나요

px: 고정 크기예요.
화면이 달라져도 크기가 바뀌지 않아요.
브라우저 기본 폰트 크기 설정을 사용자가 바꿔도 px은 따라가지 않아요.
접근성 문제가 생길 수 있어요.

em: 부모 요소의 폰트 크기 대비 비율이에요.
중첩 사용 시 복잡해져요.
(부모 20px에서 자식에 1.5em을 쓰면 30px이 되고, 손자에 또 1.5em을 쓰면 45px이 돼요)

rem: Root em이에요.
항상 html 요소의 폰트 크기 대비예요.
기본값은 16px이에요. 2rem = 32px.
브라우저 기본 폰트 크기 설정을 따라가서 접근성에 좋아요.
본문 텍스트엔 rem을 쓰는 게 권장이에요. clamp(): 최솟값, 선호값, 최댓값을 동시에 정의해요.
예: font-size: clamp(16px, 2.5vw, 22px) - 최소 16px, 뷰포트에 따라 유동, 최대 22px.
반응형 제목이나 디스플레이 텍스트에 유용해요.

화면마다 기준이 달라요

모바일(360~390px)과 데스크탑(1280px+)은 같은 폰트 크기를 쓰면 안 돼요.

모바일에서 44px 제목이 적당했다면, 데스크탑 큰 화면에서는 훨씬 커 보여요.
반대로 데스크탑 기준으로 본문을 18px로 잡았다면, 모바일 작은 화면에서는 여백과 줄 길이를 맞추기 어려워요.

브레이크포인트별로 타이포그래피 스케일을 따로 정의하거나, clamp()로 유동적으로 처리하는 두 가지 방법이 있어요.

실무 팁: 모바일 first로 설계해요.
가장 작은 화면에서 시작해 더 큰 화면으로 점진적으로 확장하면, "이 화면에서 텍스트가 너무 크다"는 문제를 줄일 수 있어요.

전체 너비를 쓰지 마세요

데스크탑에서 컨텐츠 영역이 1200px 가득이면 한 줄에 글자가 150자씩 들어가요.
읽기 너무 어려워요.

max-width로 본문 컨테이너 폭을 제한하는 게 핵심이에요.
한국어 본문 기준으로 700~760px 안팎이면 한 줄에 45~60자 정도가 돼요.
이게 편안한 독서 범위예요.

카카오 브런치, 네이버 포스트가 본문 가운데 정렬에 좁은 컬럼을 쓰는 이유예요.

하지 말아야 할 것

여러 종류의 웹폰트를 과도하게 로드하지 마세요: 폰트 파일 하나에 100kb 이상인 경우도 있어요.
3~4가지 폰트를 로드하면 초기 로딩이 눈에 띄게 느려져요.

전체 화면 너비로 본문 텍스트를 늘리지 마세요: 줄이 너무 길면 다음 줄 찾기가 어려워져요.

중요한 정보를 CSS로 가려두거나 색을 연하게 처리하지 마세요: 검색 엔진은 화면에서 숨겨진 텍스트를 다르게 처리할 수 있고, 접근성 도구도 문제를 일으킬 수 있어요.

실행 후 확인하기

  • 웹폰트에 font-display: swap 또는 optional을 설정했나요?
  • 본문 텍스트에 px 대신 rem을 쓰나요?
  • 본문 컨테이너 최대 너비를 700~760px로 제한했나요?
  • 모바일과 데스크탑에서 타이포그래피 스케일이 따로 있나요?
  • 실제 느린 네트워크 환경에서 폰트 로딩 동작을 확인했나요?

행간·자간 기준은 Line Height와 Letter Spacing에서, UI 텍스트에 시스템을 적용하는 방법은 UI Typography에서 다뤄요.

관련 아티클

참고 문헌

  • Jason Santa Maria, 《Web Typography》(2014) - 웹폰트 로딩, 반응형 타이포그래피, 단위 선택의 실무 기준을 가장 포괄적으로 다뤄요.
  • Robert Bringhurst, 《The Elements of Typographic Style》(1992) - 줄 길이와 행간의 클래식한 이론 기반이에요.