지하철에서 내 사이트를 열어본 날을 기억한다. 데스크톱에서는 단정하게 앉아 있던 본문이, 손안에서는 개미 떼처럼 작아져 있었다. 나는 나도 모르게 화면을 두 손가락으로 벌려 확대하고 있었고, 그 순간 깨달았다. 만든 사람인 내가 읽으려고 확대를 하는데 처음 온 사람은 오죽할까. 데스크톱 화면에서 16 픽셀은 넉넉해 보였지만, 팔 길이만큼 떨어뜨린 휴대폰에서 같은 글자는 전혀 다른 크기로 느껴졌다.


이번 편은 그 좁은 화면에서 글을 읽히게 만드는 이야기다. 손끝에 맞는 버튼을 만드는 것과 글을 읽게 만드는 것은 전혀 다른 문제였다. 앞의 것은 조작의 문제였고, 이번 것은 눈과 뇌가 문장을 따라가는 문제다. 나는 글자 크기 하나, 줄 간격 한 줄, 한 줄에 담기는 글자 수 몇 개가 읽는 사람의 피로를 얼마나 크게 좌우하는지를 여러 번 데어 보고 나서야 진지하게 다뤘다.

1. 16 픽셀이라는 마지노선

모바일 본문 글자 크기의 바닥은 16 픽셀이다. 나는 한동안 이 숫자를 미신처럼 여겼다. 화면이 좁으니 글자도 좀 줄여야 더 많이 담기지 않겠냐는 생각에, 본문을 14 픽셀로 낮춘 적이 있다. 데스크톱에서 보면 오히려 밀도가 높아 세련돼 보였다. 그런데 휴대폰에서 그 글을 십 분만 읽어도 눈이 뻑뻑해졌다.


결정적인 사건은 입력창에서 터졌다. 검색창의 글자 크기를 15 픽셀로 뒀는데, 아이폰에서 그 검색창을 탭하는 순간 화면이 제멋대로 확 당겨지며 확대됐다. 사파리는 입력 글자가 16 픽셀 미만이면 사용자가 읽기 편하도록 화면을 강제로 확대하는데, 문제는 확대된 뒤 원래대로 돌아오지 않아 레이아웃이 통째로 어긋나 보인다는 것이다. 나는 이 현상의 원인을 못 찾아 반나절을 스크립트만 뒤졌다. 범인은 자바스크립트가 아니라 font-size: 15px 한 줄이었다. 입력 요소의 글자를 16 픽셀로 올리자 확대는 거짓말처럼 사라졌다.


그 뒤로 나는 본문과 입력창의 바닥선을 16 픽셀로 못 박았다. 부가 설명이나 각주처럼 덜 중요한 글은 14 픽셀까지 내리기도 하지만, 사람이 문장을 죽 따라 읽어야 하는 본문만큼은 절대 그 아래로 내리지 않는다. 좁은 화면에서 밀도를 높이고 싶은 유혹은 늘 있지만, 읽히지 않는 빽빽함은 담을수록 손해다.


한 가지 덧붙이면, 나이가 있는 사용자를 떠올리면 16 픽셀도 넉넉한 값은 아니다. 젊고 시력 좋은 개발자의 눈으로만 화면을 검수하면, 정작 그 서비스를 오래 쓰는 사람의 눈을 놓치기 쉽다. 나는 부모님께 내 화면을 보여드리고 나서 글자를 한 단계 더 키운 적이 여러 번이다. 그분들이 인상을 찌푸리며 화면을 얼굴에서 멀리 떼는 장면 하나가, 어떤 접근성 문서보다 강력한 설득이었다.

2. 한글은 줄 간격을 더 먹는다

글자 크기만큼이나 줄 간격이 가독성을 가른다. 그리고 나는 한글이 영문보다 줄 간격을 더 요구한다는 걸 뒤늦게 체감했다.


영문 알파벳은 위로 솟은 획과 아래로 처진 획이 뒤섞여 있어 글자마다 높이의 리듬이 있다. 그에 비해 한글은 네모틀 안에 꽉 찬 사각형에 가깝다. 받침이 있는 글자와 없는 글자가 섞이긴 해도 전체적으로 위아래로 빽빽하다. 그래서 같은 줄 간격이라도 한글은 훨씬 답답하게 느껴진다. 나는 영문 위주 디자인 시안을 그대로 한글에 얹었다가 문단이 숨 막히게 눌려 보이는 걸 여러 번 겪었다.


내가 쓰는 값은 줄 간격 1.6에서 1.7 사이다. 글자 크기 1.5 같은 촘촘한 값은 영문 캡션에나 어울리지, 한글 본문에는 답답하다. 줄 간격을 단위 없는 숫자로 적는 습관도 이때 들였다. line-height: 24px처럼 절대 크기로 박아두면 글자 크기가 바뀔 때 간격이 따라오지 않아 어긋나는데, line-height: 1.6처럼 배수로 적으면 글자가 커지든 작아지든 비율이 유지된다. 이 사소한 차이가 나중에 유동 폰트를 도입할 때 큰 도움이 됐다.


모바일에서는 여기서 한 뼘 더 여유를 준다. 화면이 좁으면 한 줄이 짧아지고, 짧은 줄이 여러 개 쌓이면 시선이 왼쪽 끝으로 되돌아오는 횟수가 늘어난다. 그 되돌아오는 동작이 잦을수록 줄을 헷갈려 같은 줄을 두 번 읽거나 한 줄을 건너뛰기 쉽다. 나는 좁은 화면일수록 줄 사이를 조금 더 벌려, 시선이 다음 줄을 확실히 붙잡게 한다.

3. 한 줄에 몇 글자가 들어가야 하나

읽기 편한 글의 비밀은 의외로 한 줄의 길이에 있다. 한 줄이 너무 길면 시선이 줄 끝에서 다음 줄 첫머리를 못 찾고 헤매고, 너무 짧으면 시선이 쉴 새 없이 왼쪽으로 튕겨 리듬이 끊긴다.


영문 기준으로 흔히 한 줄에 45자에서 75자가 적당하다고들 한다. 나는 이 폭을 글자 수를 재는 단위인 ch로 잡는데, max-width: 65ch처럼 적으면 폰트 크기가 바뀌어도 한 줄에 담기는 글자 수가 대략 유지된다. 문제는 이 숫자가 한글에는 그대로 맞지 않는다는 점이다. 한글 한 글자는 영문 알파벳보다 폭이 넓고 정보 밀도도 높아서, 나는 한글 본문이라면 한 줄에 얼추 서른다섯에서 마흔 글자쯤 들어올 때가 가장 편하다고 느낀다.


데스크톱에서 이걸 신경 쓰지 않으면 본문이 브라우저 폭을 꽉 채워 한 줄에 백 글자 가까이 늘어난다. 큰 모니터에서 그런 문단을 읽으면 눈이 축구장을 가로지르는 기분이 든다. 나는 본문을 감싸는 영역에 최대 폭을 걸어, 화면이 아무리 넓어도 한 줄이 어느 선 이상 길어지지 않게 막는다.


한 줄 길이는 글의 성격에 따라서도 달라진다. 죽 읽어 내려가는 서술형 본문은 조금 긴 줄이 흐름을 살리지만, 항목을 하나씩 훑는 목록이나 표 형태의 글은 짧은 줄이 오히려 눈에 잘 들어온다. 나는 한 사이트 안에서도 글의 종류마다 본문 폭을 다르게 잡는데, 이걸 신경 쓰기 시작하면서 읽는 흐름이 한결 매끄러워졌다는 소리를 들었다.


모바일에서는 반대 함정이 있다. 좁은 화면에 좌우 여백까지 넉넉히 주면 한 줄에 스무 글자밖에 안 들어가는 지경이 된다. 나는 좁은 화면에서 좌우 여백을 욕심내다가 문단이 세로로 길쭉한 국수 가락처럼 늘어지는 걸 겪고, 모바일에서는 여백을 적당히 줄여 한 줄에 담기는 글자 수를 확보하는 쪽으로 바꿨다. 여백은 미덕이지만 과하면 읽기를 방해한다.

4. 한글이 줄바꿈되는 자리

한글 문단을 좁은 화면에 넣으면 뜻밖의 곳에서 말썽이 난다. 영문 위주로 짜인 줄바꿈 규칙이 한글의 특성과 어긋나기 때문이다.


기본적으로 브라우저는 띄어쓰기가 있는 자리에서 줄을 바꾼다. 한글은 어절 사이에 공백이 있으니 대개는 자연스럽게 넘어간다. 문제는 긴 영문 주소나 코드 문자열이 본문에 섞일 때다. 공백 없이 이어진 긴 문자열은 줄바꿈할 자리를 못 찾아 화면 밖으로 삐져나가고, 그 한 줄 때문에 문단 전체가 가로로 밀린다. 나는 이걸 overflow-wrap: break-word로 다스린다. 이 속성은 정상적인 단어 경계를 우선 지키다가, 도저히 안 되는 긴 문자열만 잘라 넘긴다.


더 골치 아픈 건 한글 어절이 어색하게 쪼개지는 현상이었다. 특정 설정에서는 브라우저가 한글을 글자 단위로 아무 데서나 잘라 줄을 바꾼다. 회사라는 단어가 회와 사로 갈라져 서로 다른 줄에 앉아 있는 걸 보면 눈에 확 거슬린다. 나는 한글 본문에 word-break: keep-all을 걸어 이걸 막는다. 이 값은 어절을 통째로 지켜, 단어 도중이 아니라 띄어쓰기 자리에서만 줄을 바꾸게 한다. 좁은 화면에서 한글이 훨씬 단정하게 흐른다.


한글에서 keep-all을 쓸 때 주의할 점도 있다. 어절을 통째로 지키다 보니, 아주 좁은 화면에서 유난히 긴 단어가 나오면 그 단어 하나가 줄을 밀어내 오른쪽에 빈 공간이 크게 남을 때가 있다. 나는 이럴 때 어절을 쪼개는 대신, 그 요소의 최소 폭을 손봐서 컨테이너가 먼저 줄어들도록 조정한다. 단어를 억지로 자르는 것보다 담는 그릇을 손보는 편이 결과가 깔끔하다.


제목처럼 짧고 굵은 글에는 최신 줄바꿈 기능도 요긴하다. text-wrap: balance를 걸면 여러 줄로 나뉘는 제목의 각 줄 길이가 고르게 맞춰져, 마지막 줄에 한 단어만 외롭게 남는 꼴을 막는다. 본문에는 text-wrap: pretty를 써서 문단 끄트머리에 홀로 떨어지는 외톨이 글자를 줄인다. 나는 이 두 가지를 알기 전에는 제목이 어색하게 끊길 때마다 억지로 줄바꿈을 손으로 넣었는데, 그렇게 넣은 줄바꿈은 화면 폭이 바뀌면 죄다 엉망이 됐다. 브라우저에게 맡기는 편이 백 배 낫다.

5. 크기가 부드럽게 자라게

브레이크포인트마다 글자 크기를 계단처럼 바꾸던 시절이 있었다. 좁은 화면에서 제목은 24 픽셀, 어느 폭을 넘으면 32 픽셀, 더 넓어지면 40 픽셀. 이렇게 못 박아두면 경계를 넘는 순간 글자가 툭 하고 뛴다. 화면을 천천히 넓히다 그 순간을 보면 제목이 갑자기 커지는 게 어색했다.


이걸 매끄럽게 풀어준 것이 clamp다. 최솟값, 선호값, 최댓값을 한 줄에 담으면, 화면이 넓어질수록 글자가 두 극단 사이에서 부드럽게 자란다. clamp(1.75rem, 1rem + 4vw, 3.5rem) 같은 식으로 적으면 아주 좁은 화면에서는 1.75rem을 지키고, 넓어질수록 뷰포트에 비례해 커지다가, 3.5rem에서 멈춘다. 브레이크포인트를 여러 개 두고 관리하던 수고가 한 줄로 사라졌다.


여기엔 내가 크게 데인 함정이 하나 있다. 처음엔 가운데 선호값을 5vw처럼 뷰포트 단위만으로 적었다. 화면 폭에는 잘 반응했다. 그런데 시력이 약한 사용자가 브라우저 글자 크기를 두 배로 키웠을 때, 이 제목만 안 커졌다. 뷰포트 단위는 사용자의 확대 설정을 무시하기 때문이다. 접근성 검사에서 이게 걸려서야 원인을 알았다. 그 뒤로 나는 선호값에 반드시 rem을 섞는다. 1rem + 4vw처럼 적으면 화면 폭에도 반응하면서 사용자가 글자를 키웠을 때도 함께 커진다.


유동 폰트를 모든 글자에 다 걸 필요는 없다. 나는 크기 차이가 큰 제목이나 대표 문구에만 이걸 쓰고, 본문은 얌전한 고정 크기에 미디어 쿼리로 한두 번만 손본다. 본문까지 유동으로 만들면 화면 폭을 조금 바꿀 때마다 글자가 미세하게 들썩여 오히려 산만하다. 화면을 읽는 사람은 제목이 부드럽게 자라는 건 좋아해도, 본문이 계속 꿈틀대는 건 견디지 못한다. 나는 이 선을 지킨 뒤로 유동 폰트를 훨씬 마음 편히 쓴다.

6. 밝은 화면 아래서 흐려지는 글자

여기까지가 글자의 모양과 배치라면, 마지막 한 조각은 글자와 배경의 대비다. 그리고 이건 실내 책상에서는 좀처럼 드러나지 않는 함정이다.


나는 연한 회색 배경에 조금 더 연한 회색 글자를 얹은 디자인을 좋아했다. 화면 안에서 톤이 잔잔하게 정돈돼 보였고, 흰 배경에 검은 글자보다 눈이 편하다고 믿었다. 그 믿음은 어느 여름 낮, 밖에서 휴대폰을 꺼냈을 때 산산조각 났다. 햇빛 아래에서 그 연한 회색 글자는 배경에 거의 녹아들어 아예 보이지 않았다. 실내에서 세련돼 보이던 저채도 배색이, 야외에서는 읽을 수 없는 글자가 된 것이다.


대비에는 지켜야 할 최소선이 있다. 본문 글자와 배경 사이의 명암비는 4.5 대 1 이상, 큰 글자라면 3 대 1 이상은 되어야 한다는 기준이 있고, 나는 이걸 감이 아니라 도구로 확인한다. 색을 고를 때마다 대비 검사기에 두 색을 넣어보면, 눈으로는 충분해 보이던 조합이 기준에 한참 못 미치는 경우가 허다하다. 특히 모바일은 밝은 야외에서 쓰이는 일이 많아, 나는 데스크톱 기준보다 대비를 조금 더 넉넉히 잡는다.


글자 굵기도 대비의 일부다. 아주 얇은 획의 폰트는 화면이 작아지면 획이 뭉개지거나 흐려져, 색이 충분해도 읽기 힘들어진다. 나는 모바일 본문에는 지나치게 가는 굵기를 피하고, 보통 굵기 이상을 유지한다. 얇고 우아한 글씨는 큰 화면의 사치이지, 손안의 작은 화면에서 오래 읽을 글에는 어울리지 않는다. 화면이 작아질수록 글자는 조금 더 또렷하고 조금 더 든든해야 한다.


모바일 타이포는 얼마나 많이 담느냐가 아니라, 지친 눈이 문장을 끝까지 따라오게 만드느냐의 싸움이다. 나는 좁은 화면을 마주할 때마다 밀도를 높이려는 손을 스스로 붙잡는다. 다음 편에서는 이 좁은 화면을 가로로 밀어버리는 골칫거리, 가로 스크롤을 잡는 이야기를 한다.