타이포그래피 선정 기록
이 문서는 SLUR 문서 사이트의 본문 폰트를 Pretendard에서 Noto Sans KR로 전환한 근거를 기록합니다. “느낌”이 아니라 같은 조건에서 두 폰트를 나란히 비교해 내린 결정임을 남기기 위한 참고 자료입니다.
배경 — 무엇이 문제였나
섹션 제목: “배경 — 무엇이 문제였나”기존 본문 폰트는 Pretendard였습니다. 색 대비 자체는 충분했지만(본문 기준 라이트 약 10:1, 다크 약 12:1로 WCAG AAA), 특정 크기 구간에서 글자가 얇게·흐릿하게 렌더링되는 점이 반복적으로 거슬렸습니다.
원인은 색이 아니라 소형 크기에서의 힌팅(hinting)과 획 렌더링이었습니다. 장문(prose) 위주의 문서 사이트에서는 작은 본문·주석 크기의 또렷함이 읽는 피로도를 좌우합니다.
테스트 방법 — 같은 조건으로 비교
섹션 제목: “테스트 방법 — 같은 조건으로 비교”한 폰트만 켜 두고 판단하면 인상에 휘둘리기 쉽습니다. 그래서 두 폰트를 완전히 동일한 조건에 두고 비교했습니다.
- 같은 텍스트 — 실제 홈페이지 문구와 접두사·숫자·받침 테스트 문장
- 같은 타이포 스케일 — 사이트 토큰 그대로(제목 30 / 24 / 18px, 본문 16px, 주석 14px, 행간 1.7)
- 같은 렌더링 변수 — 테마(다크·라이트),
-webkit-font-smoothing(antialiased on/off), 크기 배율을 토글하며 확인
아래 위젯이 그 비교 도구입니다. 상단 컨트롤을 바꿔가며 두 열을 직접 비교해 보세요. (위젯의 테마·스무딩·배율은 이 위젯 안에서만 작동하며 사이트 테마와 무관합니다.)
구조부터 사용자 경험까지, 한 번 구조화한 UI를 오래 유지하도록 설계하는 프론트엔드 UX/UI 시스템입니다. 클래스 이름만 봐도 구조와 역할이 읽히며, 특정 프레임워크에 종속되지 않습니다.16px
구조 설계에서 끝나지 않고, 상태·접근성·성능·경험까지 하나의 기준으로 이어집니다. 정상 상태만이 아니라 로딩·에러 상태, 접근성, 성능까지 처음부터 설계합니다.
구조는 HTML, 표현은 CSS, 동작은 JavaScript, 상태는 data-state가 담당합니다. 누가 작성해도 같은 구조로 읽히며, 일관성이 생산성을 만듭니다.
접두사: layout_ · page_ · modal_ · i_ · m_ · mo_ · pc_ · 숫자 0123456789 · 1,234,567 · 2026-07-29 · v1.4.114px
작은 글자 테스트 — 받침(밟·읊·긁·닭)이 뭉개지지 않는지, 획이 가늘게 번지지 않는지, 대비가 또렷한지 살펴보세요.
12px — 허용되는 최소 크기. 여기까지는 받침(밟·읊·긁)이 버팁니다.12px
10px — SLUR에서 지양하는 크기. 획과 받침이 먼저 뭉개집니다.10px
구조부터 사용자 경험까지, 한 번 구조화한 UI를 오래 유지하도록 설계하는 프론트엔드 UX/UI 시스템입니다. 클래스 이름만 봐도 구조와 역할이 읽히며, 특정 프레임워크에 종속되지 않습니다.16px
구조 설계에서 끝나지 않고, 상태·접근성·성능·경험까지 하나의 기준으로 이어집니다. 정상 상태만이 아니라 로딩·에러 상태, 접근성, 성능까지 처음부터 설계합니다.
구조는 HTML, 표현은 CSS, 동작은 JavaScript, 상태는 data-state가 담당합니다. 누가 작성해도 같은 구조로 읽히며, 일관성이 생산성을 만듭니다.
접두사: layout_ · page_ · modal_ · i_ · m_ · mo_ · pc_ · 숫자 0123456789 · 1,234,567 · 2026-07-29 · v1.4.114px
작은 글자 테스트 — 받침(밟·읊·긁·닭)이 뭉개지지 않는지, 획이 가늘게 번지지 않는지, 대비가 또렷한지 살펴보세요.
12px — 허용되는 최소 크기. 여기까지는 받침(밟·읊·긁)이 버팁니다.12px
10px — SLUR에서 지양하는 크기. 획과 받침이 먼저 뭉개집니다.10px
결론 — Noto Sans KR
섹션 제목: “결론 — Noto Sans KR”동일 조건 비교에서 Noto Sans KR이 특히 작은 크기와 스무딩 off 상태에서 획이 더 또렷했고, 받침이 많은 한글(밟·읊·긁·닭)에서 뭉갬이 적었습니다. 장문 가독성 기준으로 우위가 분명해 전환을 결정했습니다.
- Pretendard는 UI·화면용으로 여전히 훌륭하지만, 이 사이트의 장문 읽기라는 목적에는 Noto Sans KR이 더 맞았습니다.
- 선택 폰트는 모두 무료(OFL)이며 CDN으로 로드합니다.
적용 내역
섹션 제목: “적용 내역”폰트는 디자인 토큰 한 곳에서 관리되므로, 스택 선두만 바꾸면 사이트 전체에 반영됩니다.
| 위치 | 변경 |
|---|---|
system/tokens/typography.css |
--font-sans 스택 선두를 "Noto Sans KR"로 |
astro.config.mjs |
웹폰트 로드를 Noto Sans KR(Google Fonts, 400/500/600/700)로 교체 + preconnect |
system/demo.html |
디자인시스템 데모의 폰트 링크도 동일하게 정렬 |
성능을 위해 preconnect로 폰트 호스트 연결을 미리 열고, 사이트가 실제로 쓰는 굵기(400·500·600·700)만 내려받습니다.
최소 폰트 크기 — 12px 미만은 지양한다
섹션 제목: “최소 폰트 크기 — 12px 미만은 지양한다”간혹 본문·라벨을 11px·10px처럼 아주 작게 쓰는 경우가 있습니다. 실제로 11px를 쓰는 사이트도 있습니다. SLUR은 하한을 12px로 두고, 그 미만은 지양합니다.
SLUR의 크기 하한
- 본문 16px — 브라우저 기본값이자 대부분의 사용자에게 가장 편안한 크기입니다.
- 보조·주석 14px — 부차적 정보에 쓰는 작은 크기입니다.
- 최소 12px — SLUR 타이포 토큰의 최소값이
--text-xs = 0.75rem = 12px이고, 그보다 작은 토큰은 두지 않았습니다. 12px가 의도된 하한입니다. - 12px 미만(11px·10px 등)은 지양합니다. 12px 자체는 허용되는 최소값이고, 그 아래로는 내려가지 않습니다.
객관적 기준점 — 주요 시스템은 어디까지 내려가나
섹션 제목: “객관적 기준점 — 주요 시스템은 어디까지 내려가나”“작으면 안 된다”는 취향이 아니라, 실제 디자인 시스템들이 정의해 둔 최소 크기로 뒷받침됩니다.
| 출처 | 본문(읽는 텍스트) | 정의된 최소 크기 | 그 최소가 쓰이는 곳 |
|---|---|---|---|
| 브라우저 기본값 | 16px | — | — |
| Material Design 3 | Body 14–16sp | Label Small 11sp | 작은 라벨·캡션 (읽는 글 아님) |
| Apple HIG (iOS) | Body 17pt | Caption 2 11pt | 이미지 캡션·부가 정보 |
| WCAG 2.x | (절대 크기 규정 없음) | — | 1.4.4 — 200% 확대 지원 요구 |
여기서 객관적으로 읽히는 것:
- 어떤 표준 스케일도 10px 아래를 정의하지 않습니다. 10px 이하는 대개 법적 고지·미세 문구(fine print) 에서만 등장하고, 이는 사용자에게 “안 읽히게 하려는” 신호로 인식됩니다.
- 11px는 “읽는 본문”이 아니라 한눈에 스치는 미세 라벨(타임스탬프, 배지 숫자, 캡션, 오버라인)에만 쓰입니다. Material·Apple 모두 그렇습니다.
그래서 SLUR의 규칙은:
- 읽는 텍스트(본문·설명)는 절대 12px 미만으로 내려가지 않습니다.
- 매번 “이건 본문인가 미세 라벨인가”를 따지는 애매함을 없애려고, SLUR은 미세 라벨 역할조차 두지 않고 하한을 12px 하나로 단일화합니다.
- 밀도 높은 데이터 표처럼 미세 라벨이 정말 불가피한 예외라면 마지노선은 업계 최소값과 같은 11px이며, 10px 이하는 어떤 경우에도 지양합니다.
왜 중요한가 — 결국 신뢰와 매출의 문제
섹션 제목: “왜 중요한가 — 결국 신뢰와 매출의 문제”작은 글씨는 “가독성이 조금 아쉽다”에서 끝나지 않습니다. 사용자 입장에서 다음 사슬로 이어집니다.
작아서 읽기 힘들다 → 읽기를 포기하고 이탈한다 → “이 서비스는 불편하다·불친절하다”고 느낀다 → 브랜드에 대한 신뢰가 깎인다 → 재방문·구매를 안 한다 → 고객 이탈과 매출 저하.
- 읽는 데 드는 힘은 곧 이탈률입니다. 화면에서 눈을 찡그리게 만드는 순간, 사용자는 내용을 읽기 전에 떠납니다. 특히 결제·약관·가격처럼 작게 넣기 쉬운 곳일수록 이탈이 매출에 직접 닿습니다.
- 글씨 크기는 “친절함”의 신호입니다. 잘 읽히는 화면은 “우리는 당신이 편하게 읽길 바란다”는 배려로, 깨알 같은 글씨는 “대충 넣었다” 또는 “숨기고 싶다”는 인상으로 읽힙니다. 이 인상이 쌓여 브랜드 이미지가 됩니다.
- 신뢰는 디테일에서 무너집니다. 사용자는 “폰트 10px”라고 인지하지 않습니다. 그냥 “뭔가 불편하고 못 믿겠다” 고 느낄 뿐입니다. 그 막연한 불신이 이탈·환불·낮은 재구매로 나타납니다.
한마디로, 작은 글씨를 줄이는 건 디자인 취향이 아니라 이탈을 막고 신뢰를 쌓는 투자입니다. “작게 넣으면 정돈돼 보인다”는 건 디자이너에게만 그렇고, 비용은 읽는 고객과 회사 매출이 치릅니다.
근거 (기술적으로도 뒷받침됩니다)
섹션 제목: “근거 (기술적으로도 뒷받침됩니다)”- 판독성 — 10px 이하에서는 저시력·고령 사용자의 판독 정확도가 급격히 떨어집니다. 한글은 라틴 문자보다 획과 받침 구조가 복잡해(밟·읊·긁), 같은 px에서도 라틴보다 더 작게 느껴지고 작은 크기에서 먼저 뭉갭니다.
- 접근성(WCAG) — WCAG는 특정 최소 px를 강제하진 않지만, 2.0 AA 1.4.4(텍스트 크기 조정) 는 텍스트를 200%까지 확대해도 내용·기능이 깨지지 않을 것을 요구합니다. 크기를
px로 고정해 잘게 박아두면 사용자의 기본 글꼴 크기 설정과 확대를 무시하게 됩니다 → SLUR가rem을 쓰고 루트를 100%로 유지하는 이유와 직결됩니다.rem기반이면 사용자가 브라우저 기본 글꼴을 키웠을 때 전체가 함께 커집니다. - 모바일 입력 자동 확대 — iOS Safari는 폰트 크기 16px 미만의 입력 요소에 포커스하면 화면을 강제로 확대(zoom)합니다. 폼 입력은 이 부작용을 피하려면 16px 이상이 안전합니다.
- 실무 관례 — 주요 디자인 가이드(Material·HIG 등)도 본문은 16px 안팎, 캡션류도 12px 선을 실질적 하한으로 둡니다.
위 비교 위젯에서 크기 배율을 낮춰 12px 아래로 내려보면, 같은 문장이라도 획이 얼마나 빨리 흐려지는지 눈으로 확인할 수 있습니다.