Chapter 02

브라우저라는 캔버스

화가는 캔버스를 사러 가서 크기를 고른다. 웹 디자이너는 캔버스를 고르지 못한다. 손님이 저마다 자기 캔버스를 들고 온다. 폭이 360인 휴대폰, 1440인 노트북, 글자를 키운 휴대폰, 창을 반만 연 모니터. 같은 "1픽셀"도 어떤 화면에서는 빛의 점 하나이고 어떤 화면에서는 아홉 개다. 이 장은 웹 페이지의 캔버스인 뷰포트를 재는 법을 익힌다. 무엇으로 재는지(CSS 픽셀), 실제로는 무엇으로 그려지는지(기기 픽셀), 손님들의 캔버스는 얼마나 제각각인지, 그리고 손님이 그 캔버스를 어떻게 바꾸는지 본다.

뷰포트: 창 안의 캔버스

1장에서 웹 페이지가 그려지는 창 안의 사각형을 뷰포트(Viewport)라고 불렀다. 조금 더 정확히 나누면 세 겹이 있다. 가장 바깥은 기기의 화면이다. 그 안에 브라우저의 창이 있고, 창에서 주소창·탭·도구 막대를 뺀 부분이 페이지가 실제로 그려지는 뷰포트다. 컴퓨터에서는 창을 화면보다 작게 쓸 수 있으므로 뷰포트 폭이 화면 폭보다 좁은 일이 흔하다. 휴대폰에서는 대개 창이 화면 전체를 쓰지만, 주소창이 스크롤에 따라 나타났다 사라지며 뷰포트의 높이가 바뀐다.

뷰포트의 크기는 CSS 픽셀(CSS pixel)로 잰다. CSS 픽셀은 웹 페이지의 모든 길이를 재는 기본 단위(px)로, 화면의 실제 빛 점 하나와 같지 않다. 둘의 관계는 이 장의 셋째 절에서 다룬다. 지금은 "뷰포트 폭 390"이라는 말이 "그 화면에 CSS 픽셀 390개만큼의 폭이 있다"는 뜻이라는 것만 기억한다.

컴퓨터 화면 1920 창(탭·주소창) 뷰포트 뷰포트 폭 1100 < 화면 폭 휴대폰 주소창 뷰포트 스크롤하면 막대가 숨어 뷰포트가 길어진다 폭과 높이는 모두 CSS 픽셀로 잰다
그림 1. 화면, 창, 뷰포트. 컴퓨터에서는 창 크기를 사용자가 정하므로 뷰포트 폭이 화면 폭과 다르다. 휴대폰에서는 창이 화면을 다 쓰지만, 주소창과 도구 막대가 스크롤에 따라 나타났다 숨으며 뷰포트의 높이(실선)가 화면 높이(점선) 안에서 바뀐다.

디자이너가 신경 쓸 것은 화면의 크기가 아니라 뷰포트의 크기다. "이 휴대폰은 화면이 6.1인치"라는 말은 웹 디자인에 거의 쓸모가 없다. 쓸모 있는 것은 "그 휴대폰의 뷰포트 폭은 CSS 픽셀로 얼마인가"이고, 그 값조차 사용자가 화면을 눕히거나 확대하면 바뀐다.

작은 화면이 큰 페이지를 흉내 낼 때

휴대폰 브라우저가 처음 나왔을 때 웹의 거의 모든 페이지는 넓은 모니터를 위한 고정폭 페이지였다. 그 페이지를 좁은 휴대폰 폭에 그대로 배치하면 모두 깨진다. 그래서 휴대폰 브라우저는 꾀를 썼다. 페이지를 휴대폰 폭이 아니라 넓은 가상의 폭(흔히 980 CSS px)에 배치한 다음, 그 결과를 휴대폰 화면 폭에 맞게 통째로 줄여 보여 준 것이다. 페이지를 배치하는 데 쓰는 이 가상의 폭을 레이아웃 뷰포트(Layout viewport)라 하고, 사용자가 실제로 보고 있는 부분을 시각 뷰포트(Visual viewport)라고 한다. 손가락으로 벌려 확대하면 레이아웃 뷰포트는 그대로이고 시각 뷰포트만 작아진다.

이 꾀는 옛 페이지를 깨지지 않게 보여 주었지만, 처음부터 휴대폰을 위해 만든 페이지까지 980 폭에 배치하고 줄여 버린다. 그래서 페이지가 브라우저에게 "레이아웃 뷰포트를 기기의 폭과 같게 해 달라"고 알리는 방법이 생겼다. HTML의 <head>에 넣는 한 줄, 뷰포트 메타 태그(Viewport meta tag)다.

<meta name="viewport" content="width=device-width, initial-scale=1">

width=device-width는 레이아웃 뷰포트 폭을 기기의 폭(CSS 픽셀)과 같게 하라는 뜻이고, initial-scale=1은 처음에 줄이거나 키우지 말고 1배로 보여 주라는 뜻이다. 아래 시뮬레이터에서 오른쪽 손잡이로 기기의 폭을 바꾸고, 메타 태그가 있을 때와 없을 때를 비교한다.

SIMULATOR

메타 태그 한 줄의 차이

끌어서 기기 폭을 바꾼다
레이아웃 뷰포트 폭—
화면에 맞춘 배율—
본문 17px이 보이는 크기—
"신청하기" 버튼 높이—
해볼 것: ① 처음 모습(메타 태그 없음)에서 페이지를 본다. 휴대폰을 위해 흐르게 만든 페이지인데도 980 폭에 배치되어 넓은 화면의 모습(사진이 글 옆, 메뉴가 로고 옆)으로 나타나고, 전체가 40% 남짓으로 줄어 본문이 7px쯤이 된다. ② "width=device-width"로 바꾼다. 레이아웃 뷰포트가 기기 폭과 같아져 휴대폰용 배치(메뉴가 로고 아래, 사진 없는 카드)가 나타나고 본문은 17px 그대로다. ③ 손잡이를 끌어 기기 폭을 320에서 430까지 바꾼다. 메타 태그가 있으면 폭에 따라 줄바꿈만 달라지고, 없으면 페이지 전체의 배율이 달라진다. (가상의 책방 E 페이지다. 메타 태그가 없을 때의 레이아웃 뷰포트는 흔한 기본값 980으로 두었다. 실제 기본값은 브라우저마다 다를 수 있다.)

메타 태그가 없는 페이지는 휴대폰에서 "넓은 화면용 페이지를 멀리서 본 모습"이 된다. 1장에서 본 옛 책방 사이트의 깨알 같은 글자가 바로 이것이다. 거꾸로 말하면, 메타 태그를 넣는 순간 브라우저는 더 이상 줄여 주지 않으므로 페이지가 좁은 폭에서도 스스로 흐를 수 있어야 한다. 고정폭 960 페이지에 메타 태그만 넣으면 오른쪽이 잘려 옆으로 밀어야 하는 페이지가 된다. 메타 태그와 흐르는 레이아웃은 한 벌이다.

확대를 막지 않는다 뷰포트 메타 태그에 user-scalable=no나 maximum-scale=1을 덧붙이면 손가락으로 벌려 확대하는 것을 막을 수 있다. 화면이 "앱처럼" 단단해 보인다는 이유로 이렇게 하는 사이트가 있지만, 작은 글자나 사진을 크게 봐야 하는 사람에게서 가장 손쉬운 도구를 빼앗는다. W3C WCAG 2.2의 성공 기준 1.4.4(글자 크기 조정, AA)는 보조 기술 없이 글자를 200%까지 키울 수 있어야 한다고 정한다. 확대를 막으면 이 기준을 지키기 어렵다. 일부 브라우저는 접근성을 이유로 이 설정을 무시하기도 하지만, 그것을 믿고 넣어서는 안 된다.

CSS 픽셀과 기기 픽셀

휴대폰 화면을 돋보기로 들여다보면 빨강·초록·파랑의 작은 빛 점이 촘촘히 늘어서 있다. 이 물리적인 점(세 색이 모인 한 칸)을 기기 픽셀(Device pixel)이라고 한다. 요즘 휴대폰은 기기 픽셀이 아주 작아서, 웹 페이지의 1 CSS 픽셀을 기기 픽셀 2×2개나 3×3개로 그린다. 1 CSS 픽셀의 한 변에 기기 픽셀이 몇 개 들어가는지를 기기 픽셀 비율(Device pixel ratio, DPR)이라고 한다.

$$\text{기기 픽셀 수} = \text{CSS 픽셀 수} \times \text{DPR}$$
폭과 높이에 각각 곱한다. 폭 390 CSS px, DPR 3인 휴대폰의 화면은 가로 1,170 기기 픽셀이다. 넓이로는 DPR의 제곱(9배)만큼 기기 픽셀이 들어간다.

DPR은 화면마다 다르다. 오래된 사무실 모니터는 1, 노트북은 1.25·1.5·2, 휴대폰은 2에서 3 남짓이 흔하다. 운영체제의 배율 설정(예: 125%)과 브라우저의 확대도 DPR을 바꾼다. 페이지 안에서는 자바스크립트의 window.devicePixelRatio로 읽을 수 있다.

그러면 1 CSS 픽셀은 실제로 얼마나 큰가. CSS 명세는 1 CSS 픽셀을 길이가 아니라 보이는 각도로 정의한다. 기준은 해상도 96 dpi인 화면을 팔 길이(약 28인치, 71 cm)에서 볼 때 픽셀 하나가 차지하는 시각, 약 0.0213°다(CSS Values and Units). 기기 제조사는 사람이 그 기기를 보는 보통 거리를 생각해 CSS 픽셀의 크기를 이 각도 근처로 맞춘다. 그래서 눈에서 30 cm쯤 떨어진 휴대폰의 1 CSS 픽셀은 모니터의 것보다 물리적으로 작고, 멀리서 보는 텔레비전의 것은 더 크다.

휴대폰 약 30 cm 모니터 약 71 cm θ 같은 각도 θ ≈ 0.0213° 안에 든 길이가 "1 CSS px" 가까우면 작게, 멀면 크게
그림 2. 각도로 정한 픽셀. CSS의 기준 픽셀은 96 dpi 화면을 팔 길이에서 볼 때 한 픽셀이 차지하는 시각이다. 그래서 가까이 보는 휴대폰의 1 CSS px은 물리적으로 작고, 멀리 보는 모니터의 1 CSS px은 크다. 같은 16px 글자가 기기마다 비슷한 크기로 "보이는" 이유다. 그림의 각도는 알아보기 쉽게 크게 그렸다.

디자이너에게 DPR이 중요한 첫째 이유는 가는 선이다. 시안에서 1px로 그린 구분선은 DPR 1 화면에서는 기기 픽셀 한 줄이지만 DPR 3 화면에서는 세 줄이다. 시안 도구에서 0.5px처럼 1보다 가는 선을 그리면, DPR 2 화면에서는 또렷한 한 줄이 되지만 DPR 1 화면에서는 반만 칠할 수 없어 흐린 회색 한 줄이 되거나 아예 사라진다. 아래 시뮬레이터는 CSS 픽셀 6×4칸을 크게 확대하고, 그 안에 가로선 하나를 그린다. 굵은 격자가 CSS 픽셀, 가는 격자가 기기 픽셀이다.

SIMULATOR

1px 선은 기기 픽셀 몇 줄인가

선 두께(기기 픽셀)—
칠해진 기기 픽셀 줄—
가장 옅은 줄의 진하기—
해볼 것: ① 처음 모습(DPR 3, 1px)에서 선이 기기 픽셀 세 줄로 또렷하게 칠해진 것을 본다. 서윤의 휴대폰에서 1px 구분선이 노트북보다 가늘고 깨끗해 보이는 이유다. 선의 물리적 두께는 1 CSS px이지만 그 안을 더 잘게 그린다. ② 선 두께를 0.5로 줄이고 DPR을 1로 바꾼다. 기기 픽셀 반 줄은 칠할 수 없으므로 한 줄을 50% 회색으로 칠한다. 또렷한 선이 아니라 흐린 선이다. 0.25면 더 옅어져 거의 보이지 않는다. ③ 선 두께를 1로 되돌리고 DPR 1.5를 고른다. 1px 선이 기기 픽셀 1.5줄이 되어 한 줄은 진하게, 한 줄은 반만 칠해진다. "어긋난 자리"를 켜면 이번에는 두 줄이 모두 75%로 번진다. 같은 선이 놓인 자리에 따라 달라 보이는 것이다. 노트북의 125%·150% 배율에서 가는 선이 들쭉날쭉해 보이는 까닭이다. (모형은 덮인 넓이만큼 진하게 칠하는 가장 단순한 방식이다. 실제 브라우저는 테두리 두께를 기기 픽셀에 맞춰 반올림하기도 해서 결과가 다를 수 있다.)

정리하면, 가는 선은 DPR이 높은 화면에서 좋아 보이고 DPR 1 화면에서 가장 먼저 무너진다. 시안을 촘촘한 노트북이나 휴대폰에서만 보면 1px보다 가는 선이 예뻐 보이지만, 회사나 도서관의 공용 모니터에서는 흐려지거나 사라진다. 구분선과 입력 칸의 테두리는 적어도 1 CSS px로 두고, 선이 아니라 간격과 면의 색으로 나누는 방법도 함께 생각한다(3장). 같은 원리가 작은 글자에도 적용된다. 픽셀 격자 위의 글자는 TypeBook의 화면의 글자에서 자세히 다뤘다.

DPR이 정수가 아닐 때 DPR 2나 3처럼 정수이면 CSS 픽셀의 경계가 늘 기기 픽셀의 경계와 맞는다. 1.25, 1.5, 2.625처럼 정수가 아니면 CSS 픽셀 경계의 일부가 기기 픽셀 한가운데를 지난다. 그러면 같은 1px 선이라도 놓인 자리에 따라 기기 픽셀 한 줄이 되기도, 두 줄에 걸쳐 번지기도 한다. 브라우저는 테두리 같은 선을 가장 가까운 기기 픽셀 경계에 붙여 그리는 식으로 이를 누그러뜨리지만, 그 방식은 브라우저와 그리는 대상(테두리, 그림자, 변형된 요소)마다 다르다. 표 안의 구분선 두께가 줄마다 미세하게 달라 보이는 일이 그래서 생긴다.

촘촘한 화면과 이미지

DPR이 중요한 둘째 이유는 이미지다. 사진은 처음부터 픽셀의 격자로 되어 있다. 폭 300 CSS px 칸에 사진을 넣으면, DPR 1 화면은 그 칸을 기기 픽셀 300개로 그리고 DPR 2 화면은 600개, DPR 3 화면은 900개로 그린다. 사진의 폭이 300픽셀뿐이라면 DPR 2 화면은 사진 픽셀 하나를 기기 픽셀 2×2개로 늘려 그려야 하고, 늘린 만큼 흐려진다.

$$\text{선명하게 필요한 이미지 폭} = \text{칸의 폭(CSS px)} \times \text{DPR}$$
필요한 폭보다 작은 이미지는 늘어나 흐려지고, 훨씬 큰 이미지는 선명함은 더하지 못한 채 내려받을 무게만 늘린다.

아래 시뮬레이터는 행사 카드의 사진 칸(폭 300 CSS px)을 놓고, 화면의 DPR과 사진 파일의 폭을 바꾼다. 왼쪽은 칸 전체를, 오른쪽은 간판 글자 부분의 CSS 픽셀 24×16칸을 기기 픽셀 단위로 확대한 모습이다.

SIMULATOR

사진은 몇 픽셀이어야 하나

선명하게 필요한 폭—
사진 픽셀 1개가 덮는 기기 픽셀—
파일 무게(교육용 대표값)—
해볼 것: ① 처음 모습(DPR 2, 사진 폭 300)에서 오른쪽 확대 그림을 본다. 사진 픽셀 하나가 기기 픽셀 2×2개로 늘어나 간판 글자 "E"의 가장자리가 뭉개진다. ② 사진 폭을 600으로 바꾼다. 사진 픽셀과 기기 픽셀이 하나씩 맞아 가장자리가 또렷해진다. 무게는 네 배다(폭이 두 배면 넓이가 네 배). ③ 사진 폭을 1800으로 바꾼다. DPR 2 화면에서는 600과 거의 차이가 없는데 무게는 아홉 배가 된다. DPR 3으로 바꿔 900과 1800을 비교해 본다. (사진은 이 장에서 그린 가상의 쇼윈도 그림이다. 무게는 사진 한 픽셀에 0.2바이트로 잡은 교육용 대표값이며, 실제 무게는 형식, 압축 품질, 사진의 내용에 따라 크게 다르다.)

칸 하나에 맞는 사진 크기는 화면마다 다르다. DPR 1 노트북에는 300, DPR 2 휴대폰에는 600, DPR 3 휴대폰에는 900이 필요하다. 가장 큰 900을 모두에게 보내면 DPR 1 화면을 쓰는 사람은 필요 없는 무게를 아홉 배나 내려받는다. 그래서 HTML에는 같은 사진의 여러 크기를 적어 두고 브라우저가 화면에 맞는 것을 고르게 하는 방법(srcset과 sizes)이 있다. 그 쓰는 법은 5장, 사진의 형식과 압축은 12장과 ImageBook의 압축에서 다룬다. 로고나 아이콘처럼 선과 면으로 된 그림은 처음부터 픽셀이 아닌 벡터 형식(SVG)으로 두면 어떤 DPR에서도 또렷하다.

시안은 1배로, 내보내기는 여러 배로 화면 디자인 도구에서 시안을 그릴 때는 대개 CSS 픽셀과 같은 단위(1배)로 그린다. 폭 390의 휴대폰 화면이면 대지 폭도 390이다. 사진과 아이콘을 개발자에게 넘길 때는 같은 그림을 1배, 2배, 3배로 따로 내보낸다. 실무에서는 이 셋을 흔히 @1x, @2x, @3x라는 꼬리표로 구별한다. 서윤은 대지 폭을 기기 픽셀(1,170)로 잡았다가 모든 숫자가 세 배로 나와 지후를 헷갈리게 한 적이 있다. 시안의 숫자는 CSS 픽셀로 말하기로 약속해 두면 디자이너와 개발자가 같은 자를 쓰게 된다.

화면 크기의 다양성

"휴대폰은 360, 태블릿은 768, 컴퓨터는 1280"처럼 화면을 몇 개의 크기로 나누어 생각하기 쉽다. 1장에서 서윤이 시안을 세 폭으로 그리기로 한 것도 그런 견본이다. 하지만 실제 방문자의 화면은 몇 개의 크기로 깔끔하게 모이지 않는다. 휴대폰만 해도 제조사와 모델마다 뷰포트 폭이 조금씩 다르고, 컴퓨터는 창을 얼마나 열었는지에 따라 아무 값이나 될 수 있다. 접는 휴대폰, 화면을 나눠 두 앱을 함께 쓰는 사람, 확대해 둔 사람은 흔한 값보다 좁은 뷰포트를 만든다.

아래 그래프는 책방 E 옛 사이트의 한 달 방문 기록에서 뷰포트 폭만 뽑았다고 가정한 가상 자료다(2027년 12월, 1,320회 방문, 가까운 대표 폭으로 묶음). 가로축은 폭(CSS px)이고 넓은 화면 쪽을 압축한 로그 눈금이다. 그래프 위를 끌어 세로선을 옮기면 그보다 좁은 화면으로 들어온 방문이 몇인지 읽는다.

SIMULATOR

한 달 방문자의 화면 폭(가상 자료)

끌어서 기준선을 옮긴다
기준선—
기준선보다 좁은 방문—
기준선과 같은 폭의 방문—
해볼 것: ① 처음 모습에서 막대 무리를 본다. 360~430 사이에 키가 다른 막대가 여럿 서 있다. 가장 높은 막대(390)도 전체의 6분의 1이 안 된다. 휴대폰은 "360 하나"가 아니라 한 무리의 폭이다. ② 기준선을 600 근처로 끈다. 그보다 좁은 화면, 곧 휴대폰 폭의 방문이 셋 중 둘이다. "기기 종류로 묶기"로 바꿔 같은 것을 세 막대로 본다. ③ 기준선을 1440에 맞춘다. 서윤이 시안을 그린 노트북과 같은 폭으로 들어온 방문은 4%쯤이다. 기준선을 360으로 옮겨 그보다 좁은 방문(320, 344)도 확인한다. 적지만 0이 아니다. (기기 종류는 폭으로만 나눴다: 600 미만 휴대폰, 600~1099 태블릿, 1100 이상 컴퓨터. 모든 수치는 이 책이 지어낸 가상 자료다. 실제 분포는 사이트, 손님, 시기에 따라 크게 다르므로 자기 사이트의 기록으로 확인한다.)

이 가상 자료에서 읽을 것은 숫자 자체가 아니라 모양이다. 방문자의 화면 폭은 몇 개의 값에 모이지 않고 넓게 흩어져 있으며, 휴대폰 폭 안에서도 서로 다르다. 그러니 "우리 사이트의 기준 폭"을 하나 정하고 그 폭에서만 완벽하게 맞추는 것은 의미가 적다. 오히려 물어야 할 것은 두 가지다. 가장 좁은 쪽으로 어디까지 깨지지 않을 것인가, 그리고 가장 넓은 쪽에서 어디부터 더 넓어지지 않을 것인가. 그 사이의 모든 폭에서 페이지가 자연스럽게 흐르게 하는 것이 반응형의 일이다(5장).

기기 목록 대신 폭의 범위 웹 팀이 "지원 기기 목록"을 만들던 시절이 있었다. 특정 휴대폰 몇 종과 특정 모니터 해상도 몇 가지. 기기가 해마다 바뀌면서 그 목록은 늘 낡았다. 지금은 많은 팀이 기기 이름 대신 폭의 범위로 약속한다. "320부터 넓은 화면까지 어디서도 깨지지 않는다, 내용은 일정 폭 이상 넓어지지 않는다." 그리고 확인할 때는 그 범위의 양 끝과 중간 몇 곳에서 창을 천천히 끌어 본다. 시안의 세 폭(1장)은 이 범위 안의 견본일 뿐이고, 견본 사이의 폭이 더 자주 쓰인다.

확대와 글자 크기

방문자는 뷰포트를 바꾸기도 한다. 방법은 크게 둘이다. 하나는 페이지 확대다. 컴퓨터 브라우저에서 Ctrl(맥에서는 Cmd) 키와 + 키를 누르면 페이지 전체가 커진다. 이때 브라우저는 CSS 픽셀 하나를 더 크게 그린다. 그러면 같은 창에 들어가는 CSS 픽셀의 수가 줄어든다. 폭 1280의 창을 200%로 확대하면 뷰포트 폭은 CSS 픽셀로 640이 되고, 400%면 320이 된다. 넓은 화면이 휴대폰만큼 좁아지는 셈이다.

다른 하나는 글자 크기 설정이다. 운영체제나 브라우저의 설정에서 기본 글자 크기를 키우면, 그 설정을 따르도록 만든 글자만 커지고 뷰포트 폭은 그대로다. 이 설정이 웹 페이지에 어떻게 반영되는지는 기기와 브라우저마다 다르다. 휴대폰 운영체제의 글자 크기를 그대로 따르는 브라우저도 있고, 따로 글자 크기 메뉴를 둔 브라우저도 있다. 어느 쪽이든 페이지가 글자 크기를 픽셀로 못 박아 두었다면 설정이 무시되거나, 글자만 커지고 글자를 담은 상자가 그대로여서 넘친다.

아래 시뮬레이터는 폭 1280, 높이 720의 컴퓨터 창을 놓고 두 가지 방법을 비교한다. "옛 사이트"는 고정폭 960에 헤더 높이를 못 박은 페이지, "새 시안"은 흐르는 레이아웃에 높이를 정하지 않은 페이지다.

SIMULATOR

페이지 확대와 글자 크기 설정

뷰포트 폭(CSS px)—
본문이 화면에서 차지하는 크기—
옆으로 밀어야 하는 양—
메뉴—
해볼 것: ① 처음 모습(새 시안, 페이지 확대 200%)에서 창 안을 본다. 뷰포트가 640으로 좁아져 태블릿 폭의 배치가 나타난다. 확대한 사람에게 페이지는 좁은 화면처럼 보인다. ② 배율을 400%로 올린다. 뷰포트가 320이 되고 휴대폰 배치가 나타난다. 옆으로 밀 필요는 없다. ③ "옛 사이트"로 바꾼다. 고정폭 960 페이지는 뷰포트가 960보다 좁아지는 순간부터 오른쪽이 잘리고, 400%에서는 640픽셀을 옆으로 밀어야 한다. 글줄마다 좌우로 밀며 읽어야 한다. ④ "글자 크기만"으로 바꾼다. 뷰포트는 1280 그대로이고 글자만 커진다. 옛 사이트는 헤더 높이가 못 박혀 있어 커진 메뉴가 아래 내용 위로 넘친다. (가상의 페이지다. 글자 크기 설정은 페이지의 모든 글자가 그 설정을 따르도록 만들었다고 가정했다. 400%의 글자 크기 설정은 실제 브라우저에서 고를 수 없는 경우가 많지만 비교를 위해 열어 두었다.)

확대한 사람에게 넓은 화면은 좁은 화면이 된다. 그래서 "휴대폰에서 잘 보이는 페이지"는 "확대해서 보는 사람에게도 잘 보이는 페이지"와 거의 같은 말이다. WCAG 2.2는 이것을 두 성공 기준으로 정해 두었다. 1.4.4 글자 크기 조정(AA)은 보조 기술 없이 글자를 200%까지 키워도 내용과 기능을 잃지 않아야 한다고 정하고, 1.4.10 리플로(Reflow)(AA)는 세로로 스크롤하는 내용이라면 폭 320 CSS px에서 두 방향 스크롤 없이 볼 수 있어야 한다고 정한다. 320은 폭 1280의 창을 400%로 확대했을 때의 뷰포트 폭이다. 표처럼 두 방향으로 펼쳐져야 의미가 있는 내용은 예외로 둔다. 접근성 점검표 전체는 11장에서 다룬다.

400% 확대 시험 컴퓨터의 브라우저 창을 화면 가득 펴고, 자주 쓰는 웹사이트 두 곳에서 Ctrl(맥은 Cmd)과 + 키를 눌러 배율을 200%, 300%, 400%로 올려 본다(브라우저마다 단계가 조금 다르다). 단계마다 ① 메뉴가 어떻게 바뀌는지, ② 옆으로 밀어야 읽을 수 있는 곳이 생기는지, ③ 글자가 겹치거나 잘리는 곳이 있는지를 종이에 표로 적는다. 다 보면 Ctrl과 0으로 원래 배율로 돌린다. 휴대폰 배치로 바뀌는 사이트와 그냥 커지기만 하는 사이트가 갈린다.

접힘선은 한 줄이 아니다

신문은 가판대에서 반으로 접혀 진열된다. 접힌 윗단, 곧 지나가는 사람에게 보이는 부분에 가장 중요한 기사를 싣는다는 오래된 관행에서 접힘선 위(Above the fold)라는 말이 나왔다. 웹에서는 스크롤하지 않고 처음 보이는 부분을 같은 말로 부른다. 그리고 "접힘선 아래는 아무도 보지 않으니 중요한 것은 모두 첫 화면에 넣어야 한다"는 말이 오래 따라다녔다.

이 말은 두 가지 점에서 조심해서 써야 한다. 첫째, 사람들은 스크롤한다. 사용성 연구 기관 닐슨 노먼 그룹(Nielsen Norman Group)의 시선 추적 보고(2010년, 2018년에 다시 조사)를 비롯한 여러 관찰은, 사람들이 페이지를 아래로 내려 보지만 보는 시간은 위쪽에 더 많이 몰린다고 보고한다. 그러니 "아무도 보지 않는다"는 틀렸고, "위쪽이 더 많이 보인다"는 대체로 맞다. 둘째, 접힘선의 위치가 사람마다 다르다. 첫 화면의 높이는 기기의 화면 높이, 주소창과 도구 막대, 화면을 눕혔는지, 글자 크기에 따라 달라진다. 접힘선은 한 줄이 아니라 넓은 띠다.

아래 시뮬레이터의 왼쪽은 폭 390 휴대폰으로 본 책방 E 첫 화면이다. 화면 안을 위아래로 끌어 스크롤한다. 오른쪽은 페이지 전체를 줄인 지도이고, 가로 줄들은 가상 방문 기록에서 휴대폰 방문자들의 첫 화면 높이(가상 자료)를 진하기로 나타낸 접힘선의 띠다.

SIMULATOR

첫 화면의 높이는 사람마다 다르다

화면 안을 끌어 스크롤한다
"신청하기"가 첫 화면에 보이는 방문—
다음 내용이 걸쳐 보이는 방문—
본문 글자—
지금 내린 거리—
해볼 것: ① 처음 모습(다음 모임 먼저)에서 오른쪽 지도를 본다. 접힘선의 띠는 위에서 540 근처부터 820 근처까지 퍼져 있다. 다음 모임 카드와 "신청하기"는 띠보다 위에 있어 모든 방문자의 첫 화면에 들고, 그 아래 행사 일정의 첫머리도 첫 화면 아래쪽에 걸린다. 내용이 이어진다는 단서다. ② "큰 사진 먼저"로 바꾼다. 사진이 첫 화면을 크게 차지해 "신청하기"가 띠 한가운데로 내려간다. 작은 화면의 방문자는 버튼을 보지 못한다. 화면 크기를 560으로 바꿔 확인한다. ③ "모두 첫 화면에"를 고른다. 주인의 바람대로 행사 일정까지 첫 화면에 넣으려고 글자를 70%로 줄였더니 본문이 12px 아래로 내려간다. 첫 화면은 꽉 찼지만 읽기 어렵다. (첫 화면 높이 분포와 비율은 모두 가상 자료다. 주소창과 도구 막대를 뺀 높이로 가정했다.)

첫 화면에 모든 것을 넣으려 하면 글자와 사진이 작아지고, 결국 첫 화면조차 제대로 읽히지 않는다. 반대로 첫 화면을 큰 사진 한 장으로 꽉 채우면 페이지가 거기서 끝난 것처럼 보이기 쉽다. 아래 내용이 이어진다는 단서가 없는 화면을 디자이너들은 흔히 가짜 바닥(False floor)이라고 부른다. 첫 화면에서 할 일은 가장 중요한 것 하나를 분명히 보여 주고, 다음 내용의 끝자락을 살짝 걸쳐 두어 아래로 내려가게 하는 것이다. 무엇을 "가장 중요한 하나"로 고를지는 CompositionBook의 내용의 순위표가 도움이 된다.

100vh가 화면보다 길 때 CSS에는 뷰포트 높이의 1%를 뜻하는 vh 단위가 있어서, 첫 화면을 꽉 채우는 상자를 height: 100vh로 만들곤 했다. 그런데 휴대폰에서는 주소창이 나타났다 숨으며 뷰포트 높이가 바뀌기 때문에, 많은 브라우저가 100vh를 "막대가 숨었을 때의 큰 높이"로 계산했다. 그 결과 첫 화면을 꽉 채운다던 상자의 아래쪽(대개 버튼이 놓이는 자리)이 막대에 가려졌다. CSS Values and Units Level 4는 이 문제를 위해 작은 뷰포트(svh), 큰 뷰포트(lvh), 지금의 뷰포트(dvh)를 따로 정의했다. 첫 화면의 높이를 정해야 한다면 어떤 높이를 기준으로 할지 먼저 정하고, 무엇보다 높이를 고정하지 않아도 되는 설계를 먼저 찾는다.

가상 방문자 100명의 화면

이 장에서 본 것을 한꺼번에 모아 본다. 아래 시뮬레이터는 앞의 가상 방문 기록에서 방문 100회를 무작위로 뽑아, 각 방문자의 뷰포트 폭과 높이, 글자 크기 설정으로 책방 E 페이지를 작게 그린다. 사이트를 바꾸면 100개의 화면이 한꺼번에 바뀐다. 화면을 누르면 그 방문자의 첫 화면을 아래에 크게 보여 준다.

SIMULATOR

가상 방문자 100명의 첫 화면

화면을 눌러 크게 본다
본문이 12px보다 작게 보임—
글자 크기 설정이 깨뜨리거나 무시됨—
"신청하기"가 첫 화면에—
고른 방문—
해볼 것: ① "옛 사이트"를 고른다. 휴대폰과 태블릿 폭의 방문이 거의 모두 빨간 테두리다. 페이지가 980 폭으로 배치된 뒤 줄어 본문이 12px보다 작게 보이고, 글자를 키운 방문자의 화면에서는 고정된 헤더 밖으로 메뉴가 넘친다. ② "1440 시안 그림"을 고른다. 그림을 폭에 맞춰 넣으면 1,016보다 좁은 화면에서 본문이 12px 아래로 줄고, 그림 속 글자는 글자 크기 설정을 따르지 않는다. ③ "새 시안"을 고른다. 빨간 테두리가 사라진다. 읽기 판의 "신청하기가 첫 화면에"도 확인한다. ④ 가장 좁은 화면(폭 320, 344)과 글자를 키운 화면을 눌러 크게 본다. (가상 자료와 가상의 페이지다. 12px은 이 책이 고른 점검선이며 표준이 아니다. 글자 크기 설정은 가상의 방문자 중 일부가 130~200%로 쓴다고 가정했다.)

100개의 작은 화면을 한꺼번에 보면 "기준 폭"이라는 생각이 왜 위험한지 분명해진다. 옛 사이트는 1280 이상의 넓은 화면에서는 멀쩡하지만, 방문의 셋 중 둘인 휴대폰에서 모두 무너진다. 한 폭에서 완성한 그림은 그 폭 근처에서만 맞는다. 흐르는 레이아웃은 어느 한 화면에서 가장 아름답지는 않을 수 있지만, 100개의 화면 어디에서도 깨지지 않는 쪽을 고른다. 이 책의 나머지 장은 "깨지지 않는다"에서 "어디서나 좋다"로 가는 방법을 하나씩 다룬다.

내 휴대폰의 뷰포트 재기 휴대폰의 브라우저에서 뷰포트 크기와 DPR을 보여 주는 웹 페이지를 찾아 연다(검색창에 "viewport size"나 "뷰포트 크기 확인"을 넣으면 여럿 나온다). 세로로 들었을 때, 가로로 눕혔을 때, 글자 크기를 키웠을 때의 폭과 높이, DPR을 종이에 적는다. 가족이나 친구의 휴대폰도 두세 대 재어 본다. 같은 "휴대폰"의 숫자가 얼마나 다른지가 이 장의 결론이다.

서윤의 웹 개편 노트

CASE 서윤웹 개편 노트 · 2장

기준 폭은 정하지 않는다

1월 둘째 주, 오지후가 옛 사이트의 방문 기록에서 지난달(2027년 12월) 방문의 뷰포트 폭을 뽑아 왔다(이 책의 가상 자료). 방문은 모두 1,320회. 폭이 600보다 좁은 휴대폰 화면이 888회(67%)로 셋 중 둘이었다. 휴대폰 폭은 하나가 아니었다. 360, 375, 390, 393, 412, 430…, 가까운 값으로 묶었는데도 폭 값이 29가지였고, 가장 많은 390도 204회(15.5%)뿐이었다. 서윤이 시안을 그린 노트북과 같은 폭 1440은 56회(4.2%)였다. 360보다 좁은 방문도 22회(1.7%) 있었다. 접는 휴대폰을 접은 채로 본 화면(344)과, 지후의 추측으로는 화면을 나눠 쓰거나 확대한 화면(320)이었다.

서윤은 자기 휴대폰(뷰포트 폭 390, DPR 3)에서 시안을 열어 보고 1px 구분선이 노트북에서보다 훨씬 가늘고 또렷하다는 것을 알아챘다. 1 CSS 픽셀이 기기 픽셀 3줄로 그려지기 때문이다. 시안의 몇몇 선은 0.5px로 그려져 있었는데, 지후가 회사의 오래된 모니터(DPR 1)로 보여 주자 그 선들은 흐린 회색이 되거나 거의 보이지 않았다. 서윤은 시안의 선을 모두 1px 이상으로 바꾸고, 시안의 숫자는 CSS 픽셀로 말하기로 지후와 약속했다.

주인은 다른 걱정을 했다. "첫 화면에 다 보여야 해요. 사람들은 아래로 안 내려요." 행사 일정과 신간까지 첫 화면에 넣어 달라는 것이다. 서윤은 이 장의 시뮬레이터에서 주인의 바람대로 모두 첫 화면에 넣어 보았다. 글자가 70%로 줄어 본문이 12px 아래가 되었다. 큰 사진을 먼저 둔 안은 작은 휴대폰(첫 화면 높이 560)에서 "신청하기"가 화면 밖으로 밀렸다. 서윤은 주인에게 한도경의 휴대폰으로 두 안을 직접 보여 주었다. 도경은 글자를 줄인 안을 보더니 휴대폰을 주인에게 건네며 "이 글자를 읽어 보라"고 했다. 주인은 첫 화면에 한 가지만 두는 안에 동의했다. 단, 그 한 가지는 "다음 모임"이어야 한다고 했다.

서윤의 선택은 "기준 폭"을 정하지 않는 것이었다. 1장의 세 폭(360·768·1280)은 그리는 견본으로 남기고, 약속은 폭의 범위로 했다. 가장 좁은 쪽은 320이다. 지난달 방문에 320이 실제로 있었고, WCAG 2.2의 리플로 기준(1.4.10)도 폭 320 CSS px에서 두 방향 스크롤 없이 볼 수 있기를 요구한다. 지후는 웹 페이지의 첫 줄에 뷰포트 메타 태그를 넣고, 확대를 막는 설정은 넣지 않기로 했다.

이 장에서 정한 것기준 폭은 정하지 않는다. 최소 폭 320 CSS px까지 어떤 폭에서도 깨지지 않고 옆으로 밀 필요가 없게 한다(WCAG 2.2 1.4.10과 같은 값). 뷰포트 메타 태그 width=device-width, initial-scale=1을 넣고 확대는 막지 않는다. 시안의 길이는 CSS 픽셀로 말하고, 선은 1px 이상. 첫 화면에는 "다음 모임" 하나만 둔다(모임 이름, 날짜·시간·장소, "신청하기" 버튼). 그 아래 행사 일정의 첫머리가 첫 화면 끝에 걸쳐 보이게 해 아래로 이어진다는 단서를 남긴다. 근거 자료: 2027년 12월 방문 1,320회(가상) 중 휴대폰 폭 67%, 폭 값 29가지, 1440은 4.2%, 360 미만 1.7%.
아직 남은 문제지후가 시안을 코드로 옮기다가 멈췄다. 카드 안쪽 여백이 13px, 제목 아래가 17px, 카드 사이가 22px처럼 곳곳의 간격이 제각각이라 규칙을 찾을 수 없다고 한다.
다음 단계3장: 시안의 모든 요소를 상자로 다시 보고 간격 체계를 만든다.

핵심 정리

  1. 뷰포트는 브라우저 창에서 페이지가 그려지는 부분이고, 크기는 CSS 픽셀로 잰다. 컴퓨터에서는 창 크기에 따라, 휴대폰에서는 방향과 주소창에 따라 바뀐다.
  2. 휴대폰 브라우저는 메타 태그가 없는 페이지를 넓은 레이아웃 뷰포트(흔히 980)에 배치해 줄여 보여 준다. width=device-width, initial-scale=1은 레이아웃 뷰포트를 기기 폭과 같게 한다. 메타 태그와 흐르는 레이아웃은 한 벌이고, 확대를 막지 않는다.
  3. 기기 픽셀 = CSS 픽셀 × DPR. CSS 픽셀은 보이는 각도로 정의된다. DPR이 높은 화면에서 1px 선은 여러 기기 픽셀로 또렷하게, 1px보다 가는 선은 DPR 1 화면에서 흐리게 그려진다.
  4. 이미지는 칸의 폭 × DPR 픽셀이 있어야 선명하다. 그보다 작으면 흐려지고, 훨씬 크면 무게만 늘어난다.
  5. 방문자의 화면 폭은 몇 개의 크기로 모이지 않고 넓게 흩어진다. 기준 폭 하나보다 지킬 폭의 범위(가장 좁은 쪽과 가장 넓은 쪽)를 정한다.
  6. 페이지 확대는 뷰포트를 좁히고(1280의 400% = 320), 글자 크기 설정은 글자만 키운다. WCAG 2.2 1.4.4(글자 200%)와 1.4.10(폭 320에서 리플로)이 그 기준이다. 접힘선은 한 줄이 아니라 기기마다 다른 띠이며, "아무도 아래를 안 본다"는 통설이다.

확인 퀴즈

1. 뷰포트 폭 390, DPR 3인 휴대폰에서 CSS로 1px 두께의 가로선을 그렸다. 이 선은 기기 픽셀로 몇 줄인가?

길이는 DPR을 곱한다. 1 CSS px × 3 = 기기 픽셀 3줄이다. DPR의 제곱(9)은 CSS 픽셀 하나의 넓이에 들어가는 기기 픽셀 수(3×3)이지 선의 줄 수가 아니다. 선의 물리적 두께는 1 CSS px 그대로이고, 그 안을 더 잘게 그려 또렷해질 뿐이다.

2. 흐르는 레이아웃으로 만든 페이지가 휴대폰에서 넓은 화면의 모습 그대로 작게 줄어 보인다. 가장 먼저 의심할 것은?

메타 태그가 없으면 휴대폰 브라우저는 옛 고정폭 페이지를 위해 넓은 가상의 폭에 배치하고 결과를 줄여 보여 준다. 흐르는 페이지라도 그 넓은 폭의 배치가 나타난다. DPR은 CSS 픽셀을 그리는 촘촘함일 뿐 배치를 바꾸지 않고, 글자 크기 설정은 배치 전체를 줄이지 않는다.

3. 폭 1280의 컴퓨터 창에서 페이지를 400%로 확대했다. 이때 뷰포트 폭과 관련 기준으로 옳은 것은?

페이지 확대는 CSS 픽셀 하나를 크게 그리므로 같은 창에 들어가는 CSS 픽셀이 준다. 1280 ÷ 4 = 320이다. WCAG 2.2의 1.4.10은 세로로 스크롤하는 내용을 폭 320 CSS px에서 가로 스크롤 없이 볼 수 있게 하라고 정한다. 뷰포트를 그대로 두고 글자만 키우는 것은 글자 크기 설정이다.

4. 행사 카드의 사진 칸이 폭 300 CSS px이다. DPR 2 휴대폰에서 사진이 선명하면서 불필요하게 무겁지 않으려면 사진 파일의 폭은 얼마쯤이 알맞은가?

DPR 2 화면은 폭 300 CSS px 칸을 기기 픽셀 600개로 그린다. 사진이 600픽셀이면 사진 픽셀과 기기 픽셀이 하나씩 맞는다. 300픽셀이면 늘어나 흐려지고, 3,000픽셀은 더 선명해지지 않은 채 무게만 100배 가까이 늘어난다(넓이 기준).

출처