Media, Images & Files

현대 웹에서 읽기 쉬운 글자를 만드는 실용 가이드

대부분의 웹사이트는 필요 이상으로 읽기 어렵습니다. 타이포그래피 전문가가 되지 않고도 기본을 바로잡는 방법을 소개합니다.

The Wux Webtools Team The Wux Webtools Team 7 읽기 최소 시간 AI 지원, 인간 검토
Abstract geometric composition of overlapping text blocks demonstrating typography hierarchy and spacing principles
목차
  1. 왜 대부분의 웹사이트는 필요 이상으로 읽기 어려운가
  2. Font size: 생각보다 크게
  3. Line height: 텍스트가 숨 쉴 공간을 주기
  4. Line length: 생각보다 짧게
  5. Contrast: black on white만큼 단순하지 않다
  6. Typeface choice: default fonts는 생각보다 좋다
  7. Responsive typography: fluid type scales
  8. Paragraph spacing과 text alignment
  9. 실제로 가독성 테스트하기
  10. 실제 적용 예시
  11. 규칙을 깨도 되는 때

왜 대부분의 웹사이트는 필요 이상으로 읽기 어려운가

2026년의 평균적인 웹사이트는 맞춤형 font family, 신중하게 고른 브랜드 색상, 픽셀 단위까지 간격을 지정하는 design system을 갖춘 채 배포됩니다. 그런데 정작 대부분의 방문자가 읽으러 온 본문 텍스트는 14px의 낮은 대비 회색으로 놓여 있고, 문단이 아니라 헤드라인에 최적화된 typeface로 설정된 경우가 많습니다.

이 글은 디자이너를 비판하려는 것이 아닙니다. 가독성은 시각 디자인과는 별개의 분야이며, 두 가지가 항상 같은 방향을 향하지는 않는다는 점을 상기시키려는 것입니다. hero section에서 선명해 보이는 typeface도 문단 길이로 이어지면 피로할 수 있습니다. 사진으로 보기 좋은 color palette도 contrast check를 통과하지 못할 수 있습니다. 27-inch monitor에서 잘 작동하는 layout도 mobile에서는 좁은 column으로 무너질 수 있습니다.

다행히 읽기 쉬운 글자를 위해 타이포그래피 학위가 필요한 것은 아닙니다. 큰 영향을 주는 몇 가지 변수에 주의를 기울이면 됩니다.

Font size: 생각보다 크게

웹에서 가장 흔한 가독성 실수는 body text가 너무 작은 것입니다. 디자이너는 desktop scale에서 "깔끔해 보인다"는 이유로 body copy를 14px 또는 15px로 설정하는 경우가 많고, 상당수의 독자가 phone에서, 종종 좋지 않은 조명 환경에서 읽는다는 사실을 잊습니다.

2026년 body text의 실용적인 기준은 다음과 같습니다.

  • Desktop: 최소 18px, 권장 20px
  • Mobile: 최소 16px, 권장 18px

작은 글자에 익숙하다면 이 숫자들이 크게 느껴질 수 있지만, 이는 사람들이 실제로 screen에서 읽는 방식을 반영합니다. 더 큰 텍스트는 눈의 피로를 줄이고, 이해도를 높이며, browser settings를 조정하지 않은 경미한 시력 저하가 있는 독자에게도 콘텐츠를 더 접근 가능하게 만듭니다.

design system이 더 작은 글자를 요구한다면, 햇빛 아래에서 phone으로 테스트해 보세요. 눈을 찡그리게 된다면 너무 작은 것입니다.

Line height: 텍스트가 숨 쉴 공간을 주기

Line height(leading)는 텍스트 줄 사이의 세로 공간입니다. 너무 촘촘하면 줄들이 서로 흐릿하게 뭉쳐 보이고, 너무 느슨하면 시선이 다음 줄로 이어지는 흐름을 잃습니다.

body text에는 대부분의 typeface에서 1.5에서 1.7의 line height가 잘 맞습니다. Headlines는 더 타이트해도 되지만(1.1에서 1.3), body copy에는 숨 쉴 공간이 필요합니다.

CSS는 다음과 같습니다.

body {
  font-size: 18px;
  line-height: 1.6;
}

이는 가장 쉽게 얻을 수 있는 가독성 개선 중 하나입니다. 현재 body text가 line-height: 1.2에 있거나 고정 pixel 값을 사용한다면, 오늘 바로 바꾸세요.

Line length: 생각보다 짧게

body text에 적절한 line length는 한 줄에 45자에서 75자, 대략 8에서 12단어입니다. 90자를 넘는 줄은 시선이 다음 줄의 시작점으로 돌아가 추적하기 어렵게 만듭니다. 40자보다 짧은 줄은 끊기고 파편화된 읽기 경험을 만듭니다.

대부분의 웹사이트는 특히 desktop에서 텍스트가 viewport 전체 너비로 펼쳐지게 두면서 이 부분을 잘못 처리합니다. 1920px-wide monitor는 한 줄에 150자 이상을 넣을 수 있고, 이는 읽기에 매우 피로합니다.

해결책은 text container에 max-width를 주는 것입니다.

.prose {
  max-width: 65ch; /* 65 characters */
  margin-inline: auto;
}

ch unit은 덜 사용되지만 이 용도에는 완벽합니다. font size에 맞춰 확장되고 대략 character width에 대응합니다.

Contrast: black on white만큼 단순하지 않다

WCAG 2.1은 body text에 최소 contrast ratio 4.5:1(AA level), 향상된 접근성에는 7:1(AAA level)을 지정합니다. 대부분의 웹사이트는 문서상으로는 이를 충족하지만, white backgrounds 위에 light gray text를 사용하기 때문에 실제로는 실패합니다.

흔한 문제 사례는 다음과 같습니다.

  • #666666 on #FFFFFF (4.54:1, 간신히 통과)
  • #777777 on #FFFFFF (4.47:1, 실패)
  • white 위의 #767676보다 밝은 모든 shade (실패)

design system이 "text-secondary"를 light gray로 지정한다면 테스트하세요. WebAIM contrast checker가 확인하는 가장 빠른 방법입니다.

Dark mode에서는 문제가 더 복잡해집니다. pure black 위의 pure white text는 halation(빛 번짐 효과)을 만들어, dark gray 위의 약간 off-white보다 읽기 어렵습니다. 더 나은 접근은 다음과 같습니다.

@media (prefers-color-scheme: dark) {
  body {
    background: #1a1a1a;
    color: #e4e4e4;
  }
}

Typeface choice: default fonts는 생각보다 좋다

Custom web fonts는 널리 쓰이지만 trade-off가 있습니다. latency를 더하고, page weight를 늘리며, 주의 깊게 로드하지 않으면 rendering을 막을 수 있습니다. body text에는 system fonts가 더 나은 선택인 경우가 많습니다.

2026년에 견고한 system font stack은 다음과 같습니다.

body {
  font-family: system-ui, -apple-system, 'Segoe UI', 
               Roboto, Helvetica, Arial, sans-serif;
}

이 설정은 macOS/iOS에서는 San Francisco, Windows에서는 Segoe UI, Android에서는 Roboto를 제공합니다. 모두 즉시 로드되는, 가독성이 높고 전문적으로 설계된 typefaces입니다.

body text에 custom font를 사용한다면 display용이 아니라 long-form reading을 위해 설계된 것을 선택하세요. 피해야 할 것은 다음과 같습니다.

  • body copy에 ultra-light 또는 ultra-bold weights 사용
  • Condensed 또는 extended variants
  • x-height(소문자 높이)가 낮은 fonts

확정하기 전에 선택한 typeface를 문단 길이로 테스트하세요.

Responsive typography: fluid type scales

고정 font size는 devices 전반에서 잘 확장되지 않습니다. desktop에서는 편안한 20px body font가 mobile에서는 과하게 크게 느껴질 수 있습니다.

Fluid typography는 clamp()를 사용해 최소값과 최대값 사이에서 font size를 부드럽게 조정합니다.

body {
  font-size: clamp(1rem, 0.9rem + 0.5vw, 1.25rem);
}

이는 작은 screen의 16px에서 큰 screen의 20px까지, 그 사이를 부드럽게 보간하며 확장합니다. media query breakpoints보다 정교하고 어떤 viewport width에도 적응합니다.

전체 type scale(headings, body, small text)이 필요하다면 Utopia 같은 도구가 제약 조건을 바탕으로 fluid scales를 생성해 줍니다.

Paragraph spacing과 text alignment

중요한 두 가지 작은 세부 사항이 있습니다.

  1. Paragraph spacing: 문단 사이에 공간을 추가하거나(margin-block-end: 1em) first-line indent(text-indent: 1.5em)를 사용하세요. 단, 둘 다 사용하지는 마세요. 대부분의 web content는 spacing을 사용합니다.
  1. Text alignment: Left-aligned(RTL languages에서는 right-aligned)는 거의 항상 justified text보다 읽기 쉽습니다. justified text는 hyphenation이 활성화되어 있지 않으면 uneven word spacing을 만듭니다. Center-aligned body text는 읽기 어렵고 짧은 구절에만 사용하는 것이 좋습니다.

실제로 가독성 테스트하기

가독성은 완전히 객관적인 것은 아니지만 테스트할 수 있습니다.

  • 자신의 콘텐츠를 phone에서 읽어보세요 다양한 조명 조건에서
  • Lighthouse accessibility audit를 실행하세요 contrast와 font size 문제를 잡기 위해(Lighthouse report를 당황하지 않고 읽는 법 참고)
  • 50세 이상인 사람에게 한 페이지를 읽어 달라고 요청하세요 settings를 조정하지 않은 상태로
  • 텍스트가 많은 페이지의 bounce rate를 analytics에서 확인하세요—사람들이 빨리 떠난다면 가독성이 한 요인일 수 있습니다

콘텐츠가 읽기 어렵다면 사람들은 읽지 않습니다. 그만큼 단순합니다.

실제 적용 예시

2026년의 읽기 쉬운 body text style은 다음과 같을 수 있습니다.

.prose {
  font-family: system-ui, sans-serif;
  font-size: clamp(1.125rem, 1rem + 0.5vw, 1.25rem);
  line-height: 1.6;
  color: #1a1a1a;
  max-width: 65ch;
  margin-inline: auto;
}

.prose p {
  margin-block-end: 1.25em;
}

@media (prefers-color-scheme: dark) {
  .prose {
    background: #1a1a1a;
    color: #e4e4e4;
  }
}

이는 약 열두 줄의 CSS로 font size, line height, line length, contrast, responsive scaling을 다룹니다. 흥미롭지는 않지만 효과가 있습니다.

규칙을 깨도 되는 때

이 가이드라인은 body text, 즉 사람들이 정보를 얻기 위해 읽는 문단에 적용됩니다. Headlines, captions, UI labels, marketing copy는 제약 조건이 다르며 이 규칙을 유연하게 적용할 수 있습니다.

하지만 누군가 article, documentation page, product description을 읽기 위해 사이트에 왔다면 읽기 쉬운 글자는 선택 사항이 아닙니다. 기본 기대치입니다.

Quick-reference infographic showing recommended body text settings: 18 to 20px desktop, 16 to 18px mobile, line height 1.5 to 1.7, line length 45 to 75 characters, contrast targets and dark mode colors
InfographicReadable body text at a glance — A compact reference for the body text settings that matter most
Comparison diagram of text columns showing too short under 40 characters, ideal 45 to 75 characters with 65ch example, and too long over 90 characters or 150 plus on a 1920px monitor
InfographicGood line length vs bad line length — Why narrower text columns are easier for the eye to track
Checklist infographic listing readability tests: read on phone in different lighting, run Lighthouse accessibility audit, ask someone over 50 to read the page, and check bounce rate on text-heavy pages
InfographicHow to test readability in practice — A simple four-step checklist to catch readability problems before readers do

자주 묻는 질문

body text에 custom web font를 사용해야 하나요?
long-form reading을 위해 특별히 설계되었고 loading 최적화(font-display: swap, preloading, subsetting)를 할 의향이 있을 때만 사용하세요. System fonts는 더 빠르고, 무료이며, 종종 더 읽기 쉽습니다. Custom fonts는 영향력이 더 큰 headings와 branding에 남겨두는 것이 좋습니다.
내 텍스트가 읽기 쉬운지 확인하는 가장 빠른 방법은 무엇인가요?
밝은 햇빛 아래에서 phone으로 사이트를 열어 보세요. 눈을 찡그리거나 확대해야 한다면 font size 또는 contrast가 부족한 것입니다. contrast만 확인하려면 WebAIM contrast checker를 사용하세요. 전체적인 가독성은 Lighthouse accessibility audit를 실행해 확인하세요.
읽기 쉬운 글자가 디자인 미감을 해치나요?
읽기 쉬운 글자는 mobile responsiveness나 load time처럼 design constraint입니다. 일부 선택지를 제한하지만 좋은 디자인을 배제하지는 않습니다. 시각적으로 가장 인상적인 사이트들(Stripe, Linear, GitHub's docs) 중 다수는 미감을 해치지 않으면서 가독성을 우선합니다.
더 큰 텍스트가 더 낫다는 것을 stakeholders에게 어떻게 설득하나요?
현실적인 조건에서 phone으로 사이트를 보여주거나, 현재 사이트에서 full article을 읽어 보라고 요청하세요. 그래도 통하지 않는다면 더 크고 읽기 쉬운 글자를 적용한 버전으로 A/B test를 하고 time-on-page 또는 scroll depth를 측정하세요. 읽기 쉬운 콘텐츠가 더 좋은 성과를 냅니다.

출처 및 추가 읽기

  1. Web Content Accessibility Guidelines (WCAG) 2.1
  2. WebAIM Contrast Checker
  3. Butterick's Practical Typography
  4. Utopia Fluid Type Scale Calculator
저자에 대하여
The Wux Webtools Team

마지막 업데이트:

계속 읽기