제 글이 재미없어서 독자가 안 읽는다고 생각했습니다. 통계가 나빠도 그냥 글을 더 잘 써야겠다는 방향으로만 생각했고, 설정 자체를 의심해본 적이 없었습니다. 그러다 어느 날 직접 스마트폰으로 제 블로그를 열어봤는데, 두 문단도 채 읽기 전에 눈이 불편해졌습니다. 내용이 문제가 아니었습니다. 화면이 문제였습니다. 티스토리 기본 스킨의 글자 크기가 14픽셀로 설정되어 있다는 걸 그때 처음 알았습니다.
사소해 보이는 숫자 하나가 독자를 머물게도 하고 떠나게도 한다는 걸, 그 경험으로 처음 실감했습니다. 이 글은 그 이후 제가 직접 바꿔보고, 틀리기도 하고, 다시 조정하면서 정착한 CSS 설정들에 대한 기록입니다. 완벽한 답이 아니라 제가 부딪힌 과정을 솔직하게 담았습니다.
독자 이탈의 원인을 콘텐츠로만 돌리는 함정이 있습니다. 글을 더 잘 쓰려고 애쓰기 전에, 그 글이 읽히는 환경이 제대로 갖춰져 있는지를 먼저 점검해야 합니다. 폰트 설정은 눈에 보이지 않는 형태로 독자 경험에 영향을 줍니다. 독자가 "이 글이 별로야"라고 생각하는 게 아니라, "왠지 읽기 불편한데"라는 느낌을 받고 그냥 나가버리는 겁니다.
font-size와 line-height — 숫자 하나가 읽히는 경험을 바꾼다
font-size란 화면에 렌더링되는 글자의 기본 크기를 픽셀 단위로 지정하는 속성입니다. 14픽셀은 데스크톱에서는 그럭저럭 읽히지만 모바일에서는 이야기가 달라집니다. 스마트폰으로 14픽셀 텍스트를 읽을 때는 글에 집중하는 게 아니라 글자를 해독하는 데 에너지가 먼저 쓰이는 느낌이 납니다. 저는 직접 그 느낌을 겪고 나서야 16픽셀로 올렸는데, 그것만으로도 피로감이 눈에 띄게 줄었습니다. 이후로 저는 16픽셀을 절대 하한선으로 생각합니다. 모바일로 읽어보기 전까지는 이 차이가 이렇게 클 줄 몰랐습니다.
다음으로 손댄 것이 line-height였습니다. 줄 간격을 조정하는 속성입니다. 기본값인 1.4는 줄과 줄 사이가 좁아 텍스트 전체가 빽빽하게 느껴집니다. 1.8로 올렸더니 똑같은 글이 다르게 읽혔습니다. 중간에 포기하고 싶은 느낌이 확연히 줄었습니다. MDN Web Docs에서는 본문 텍스트에 1.5 이상, 이상적으로는 1.5~2.0 사이를 권장합니다. 저는 1.8을 기준으로 삼고 있는데, 이 수치가 정답이라기보다 모바일에서 직접 읽어보며 찾아낸 값이라는 표현이 더 정확합니다. 같은 1.8이라도 폰트가 다르면 체감이 다르기 때문에, 수치보다 눈으로 확인하는 과정이 먼저입니다.
letter-spacing을 건드릴 때는 실수를 했습니다. 글자 사이의 간격을 조정하는 속성인데, 처음에 0.08em으로 설정했더니 글자들이 낱낱이 떨어져 보여서 오히려 읽기 어려워졌습니다. "자간을 넓히면 가독성이 좋아진다"는 말을 영문 텍스트 기준으로 받아들인 탓이었습니다. 실제로 써보니 한글은 영문보다 자간 변화에 훨씬 민감하게 반응했습니다. 0.02em으로 줄이고 나서야 자연스러운 흐름이 생겼습니다. 이때부터 수치를 조금씩 바꿔가며 눈으로 확인하는 습관이 생겼습니다. 권장 수치라는 게 결국 평균값이고, 내 폰트와 내 글에 맞는 값은 직접 써봐야 압니다.
한 가지 꼭 짚고 싶은 것이 있습니다. 이 세 가지 속성은 서로 독립적으로 작용하지 않습니다. font-size를 키우면 같은 line-height 값이라도 체감 간격이 달라집니다. letter-spacing도 폰트의 자형에 따라 반응이 다릅니다. 하나씩 따로 바꾸고 매번 모바일에서 확인하는 방식이 번거롭지만, 결국 이 방법이 가장 정확한 길이었습니다. 세 가지를 한꺼번에 바꾸면 무엇이 효과를 냈는지 알 수가 없습니다.
font-family와 word-break — 눈에 안 보이는 것들이 만드는 차이
font-family는 웹에서 사용할 글꼴 우선순위를 지정하는 속성입니다. 저는 처음에 Noto Sans KR을 쓰고 있었는데, 모바일에서 첫 화면이 뜨는 속도가 유독 느리다는 걸 체감했습니다. 구글 폰트처럼 외부 서버에서 불러오는 웹 폰트는 네트워크 요청이 추가로 발생하기 때문에 초기 렌더링 속도에 영향을 줍니다. 이를 줄이기 위해 시스템 폰트 스택으로 전환했습니다. 운영체제에 기본 설치된 폰트들을 우선순위 순으로 나열해서, 별도 다운로드 없이 사용자 기기에 이미 있는 폰트를 바로 쓰는 방식입니다. 첫 화면 로딩 속도가 확실히 빨라졌고, 이후로는 웹 폰트를 꼭 써야 하는 상황이 아니라면 시스템 폰트를 먼저 고려합니다.
Noto Sans KR이 나쁜 폰트가 아닙니다. 오히려 좋은 폰트입니다. 하지만 로딩 속도와 가독성을 동시에 챙겨야 하는 상황에서 폰트 선택은 단순히 예쁨의 문제가 아닙니다. 폰트가 늦게 로딩되면 FOUT, 즉 폰트가 바뀌는 순간이 발생하는데, 그 자체가 독자의 집중을 깨는 경험이 됩니다. 예쁜 폰트보다 빠른 폰트가 독자 경험에 더 직접적인 영향을 줄 수 있다는 것을 그때 배웠습니다.
word-break는 처음엔 건드릴 생각도 없던 속성입니다. 긴 URL을 본문에 포함시킨 뒤 가로 스크롤이 생기는 문제를 겪고 나서야 처음 알게 됐습니다. word-break: keep-all은 한글 단어를 음절 단위로 쪼개지 않고 단어 단위로 줄 바꿈을 처리하는 설정입니다. 여기에 overflow-wrap: break-word를 함께 적용하면, 영문 URL처럼 띄어쓰기 없이 길게 이어지는 문자열은 강제로 줄 바꿈이 되어 레이아웃이 깨지지 않습니다. 두 속성을 함께 적용하고 나서 가로 스크롤 문제가 완전히 해결됐습니다. 몰랐을 때는 그 존재조차 몰랐던 속성인데, 지금은 기본값처럼 항상 넣고 있습니다.
font-weight 이야기도 빠뜨릴 수 없습니다. 글자의 굵기를 지정하는 속성인데, 같은 16픽셀이라도 font-weight가 300이면 모바일 화면에서 글자가 얇게 번져 보이는 경우가 있습니다. 저는 본문에 400을 기본으로 두고 있습니다. Nielsen Norman Group의 가독성 연구에서도 글자 크기, 간격, 명도 대비가 복합적으로 작용할 때 독해 속도가 유의미하게 달라진다고 지적합니다. font-size와 line-height를 다 잡아놓고 font-weight를 놓치면 아쉬운 결과가 나옵니다. 이 속성들은 하나하나가 독립적으로 작용하는 게 아니라 함께 작용한다는 점을 계속 잊지 말아야 합니다.
CSS 설정은 한 번 맞추면 끝나는 게 아닙니다. 글을 올릴 때마다 실제 화면에서 읽어보며 조정하는 작업입니다. 제 경험상 가장 좋은 기준은 제가 직접 모바일로 읽어보는 것이었습니다. 설정값이 얼마나 논리적으로 올바른지보다 실제로 읽히는지가 먼저입니다. 숫자 하나의 차이가 독자가 글을 끝까지 읽느냐 아니냐를 가를 수 있고, 그 숫자는 결국 직접 써봐야만 찾을 수 있습니다.
참고: MDN Web Docs — line-height / MDN Web Docs — letter-spacing / web.dev — Font best practices