Chapter 01

웹 디자인의 지도

포스터를 만드는 사람은 먼저 종이 크기를 정한다. A2라면 A2 안에서 모든 것을 짜고, 인쇄된 포스터는 누가 보든 같은 크기다. 웹 페이지는 그렇지 않다. 같은 주소가 손바닥만 한 휴대폰에서도, 책상 위의 넓은 모니터에서도, 글자를 두 배로 키워 둔 할머니의 휴대폰에서도 열린다. 디자이너는 그 화면을 고를 수 없다. 이 장은 크기를 정할 수 없는 캔버스 위에서 디자인한다는 것이 무엇인지 몇 개의 시뮬레이터로 둘러보고, 앞으로 열두 장에서 풀어 갈 질문을 화면·배치·상호작용·쓰임의 네 갈래로 나누어 한 장의 지도 위에 펼친다.

크기를 정할 수 없는 캔버스

책방의 행사 포스터와 책방의 웹사이트를 나란히 놓고 생각해 본다. 포스터는 종이 한 장이다. 디자이너는 종이의 가로세로를 알고, 제목이 어디에 몇 밀리미터로 들어가는지 정할 수 있다. 인쇄가 끝나면 그 배치는 바뀌지 않는다. 웹사이트는 같은 내용이 어떤 크기의 창에 담길지 모르는 채로 만든다. 지하철에서 휴대폰으로 행사 일정을 보는 사람, 회사 모니터에서 창을 반만 열어 둔 사람, 태블릿을 가로로 눕힌 사람이 모두 같은 주소를 연다.

웹 페이지가 놓이는 이 창 안의 영역을 뷰포트(Viewport)라고 한다. 브라우저 창에서 주소창과 도구 막대를 뺀, 페이지가 실제로 그려지는 사각형이다. 뷰포트의 폭은 기기와 창 크기, 화면을 세웠는지 눕혔는지, 사용자가 확대했는지에 따라 달라진다. 웹 디자인의 거의 모든 문제는 이 사실 하나에서 출발한다. 뷰포트를 어떻게 재는지는 2장에서 자세히 다룬다.

포스터: 정해진 종이 420 × 594 mm, 늘 같다 웹: 폭이 정해지지 않은 창 320 … 2,560 CSS px, 사람마다 다르다 휴대폰 넓으면 나란히, 좁으면 위아래로 포스터는 배치를 하나 정하고, 웹은 배치가 바뀌는 규칙을 정한다
그림 1. 정해진 종이와 정해지지 않은 창. 포스터 디자이너는 한 가지 배치를 완성한다. 웹 디자이너는 폭이 좁을 때와 넓을 때 같은 내용이 어떻게 다시 놓일지, 곧 배치가 바뀌는 규칙을 정한다. 색은 내용의 순서(제목, 그림, 본문, 버튼)를 나타낸다.

이 생각은 웹이 생길 때부터 있었다. 웹을 처음 만든 팀 버너스리(Tim Berners-Lee)의 첫 웹 페이지(1991)는 글과 링크뿐이었고, 글줄은 창 폭에 따라 저절로 다시 흘렀다. 그 뒤 디자이너들이 인쇄물처럼 정확한 배치를 원하면서 페이지 폭을 픽셀 수로 못 박는 방식이 퍼졌다. 웹 디자이너 존 올솝(John Allsopp)은 글 「웹 디자인의 도」(A Dao of Web Design, A List Apart, 2000)에서, 웹을 종이처럼 통제하려 하지 말고 통제할 수 없다는 성질을 받아들이자고 주장했다. 10년 뒤 이선 마콧(Ethan Marcotte)이 같은 잡지에 쓴 「반응형 웹 디자인」(Responsive Web Design, 2010)은 흐르는 그리드, 늘었다 줄었다 하는 이미지, 창 폭에 따라 규칙을 바꾸는 미디어 쿼리를 묶어 이름을 붙였고, 이 말은 곧 업계의 기본어가 되었다(5장).

아래 시뮬레이터는 책방 E의 가상 첫 화면을 세 가지 폭에 띄운다. 휴대폰(360), 태블릿(768), 노트북(1280)이다. 숫자는 CSS 픽셀로 잰 뷰포트 폭이다. "흐르는 레이아웃"은 폭마다 배치를 다시 짠 페이지, "1440 시안 그림 그대로"는 넓은 노트북 화면(1440)에서 한 장의 그림으로 완성한 시안을 화면 폭에 맞춰 줄이거나 늘려 넣은 것이다.

SIMULATOR

같은 페이지, 세 화면

휴대폰 360: 본문 17px이 보이는 크기—
태블릿 768—
노트북 1280—
해볼 것: ① 처음 모습(흐르는 레이아웃)에서 세 화면을 비교한다. 휴대폰에서는 메뉴가 로고 아래로 내려가고 신간 표지가 두 단으로, 노트북에서는 메뉴가 한 줄에 서고 사진이 글 옆에 나란히 선다. 본문 글자는 세 화면 모두 17px이다. ② "1440 시안 그림 그대로"로 바꾼다. 휴대폰에서는 모든 것이 4분의 1로 줄어 본문이 4px 남짓이 된다. 손가락으로 벌려 확대하지 않으면 읽을 수 없다. ③ "실제 비율대로"를 끈다. 세 화면을 같은 폭으로 늘어놓으면, 흐르는 레이아웃의 휴대폰 화면은 길고 좁은 두루마리이고 노트북 화면은 가로로 넓은 한 장이라는 것이 더 잘 보인다. (가상의 책방 E 페이지다. 기기의 보이는 높이는 휴대폰 640, 태블릿 1024, 노트북 800 CSS px로 가정했다.)

흐르는 레이아웃의 세 화면은 서로 다르게 생겼지만 같은 페이지다. 내용과 순서(다음 모임 → 소개 → 행사 일정 → 신간)는 같고, 놓이는 방식만 폭에 맞춰 바뀐다. 반대로 한 장의 그림으로 완성한 시안은 어느 한 폭에서만 맞는다. 줄여 넣으면 글자가 깨알이 되고, 늘리면 흐려진다. 웹 디자이너가 만드는 것은 한 장의 그림이 아니라 폭이 바뀔 때 무엇이 함께 바뀌어야 하는지에 대한 약속이다. 이 책은 그 약속을 하나씩 만들어 간다.

고정과 흐름

2010년대 초까지 많은 웹사이트는 페이지 폭을 960픽셀 같은 값으로 못 박았다. 그 무렵 사무실 모니터의 흔한 폭(1024)에 여백을 조금 남기면 960 안팎이 되었고, 960은 2, 3, 4, 5, 6, 8, 10, 12로 나누어떨어져 단을 나누기도 편했다. 이런 페이지를 고정폭 레이아웃(Fixed-width layout)이라고 한다. 창이 넓으면 페이지는 가운데 서고 양옆이 빈다. 창이 좁으면 페이지가 잘려 옆으로 밀어야 하거나, 휴대폰 브라우저가 페이지 전체를 작게 줄여 보여 준다.

그 반대가 흐르는 레이아웃(Fluid layout)이다. 폭을 픽셀 수가 아니라 창에 대한 비율이나 남는 공간으로 정해서, 창이 바뀌면 내용이 그 안을 채우며 다시 흐른다. 흐르는 레이아웃에도 약점이 있다. 아주 넓은 창에서는 글줄이 끝없이 길어진다. 그래서 흔히 흐르게 하되 최대 폭을 두어 일정 폭 이상에서는 더 넓어지지 않게 한다.

아래 시뮬레이터의 오른쪽 손잡이를 끌어 창 폭을 320에서 1600까지 바꿔 본다. 위의 눈금은 CSS 픽셀이다. 세 가지 방식을 바꿔 가며 좁은 쪽과 넓은 쪽에서 각각 무엇이 무너지는지 본다.

SIMULATOR

창 폭을 끌어 보기: 고정 960과 흐름

끌어서 창 폭을 바꾼다
창 폭—
본문 글자가 보이는 크기—
옆으로 밀어야 하는 양—
창에서 빈 여백의 몫—
해볼 것: ① 처음 모습(고정 960)에서 손잡이를 왼쪽 끝 360 근처로 끈다. 페이지가 통째로 줄어 본문 14px이 5px 남짓으로 보인다. 서윤이 말한 "휴대폰에서 글자가 깨알 같은" 옛 사이트다. ② "줄여 맞추기"를 끈다. 이번에는 글자 크기는 그대로지만 페이지 오른쪽이 잘려, 600픽셀쯤을 옆으로 밀어야 한다. ③ 손잡이를 오른쪽 끝 1600으로 끈다. 고정 960은 창의 40%가 빈 여백이고, "흐름"은 소개 글 한 줄이 아주 길어진다. "흐름 + 최대 폭"이 두 문제를 함께 누그러뜨린다. (가상의 페이지다. 옛 사이트의 본문은 14px, 새 페이지는 17px로 두었다. 최대 폭은 흐름 방식의 한 예이며 값은 나중 장에서 정한다.)

좁은 창에서 고정폭 페이지가 보이는 두 가지 모습, 곧 통째로 줄어드는 것과 옆이 잘리는 것은 둘 다 실패다. 줄어든 페이지는 손가락으로 벌려 확대한 뒤 글줄마다 좌우로 끌며 읽어야 하고, 잘린 페이지는 중요한 버튼이 화면 밖에 있다는 것조차 모를 수 있다. 넓은 창의 빈 여백은 그보다 덜 해롭지만, 넓은 모니터를 가진 사람에게 페이지가 손바닥만 하게 보이는 것도 좋은 경험은 아니다. 흐르는 레이아웃은 이 두 끝을 모두 다루려는 방식이고, 최대 폭과 중단점(창 폭에 따라 배치 규칙을 바꾸는 지점)이 그 세부다. 단과 거터는 4장, 중단점은 5장에서 다룬다.

시안은 한 장이 아니라 세 장으로 개발자와 오래 일한 웹 디자이너들은 시안을 처음부터 여러 폭으로 그린다. 흔히 휴대폰, 태블릿, 넓은 화면의 세 폭을 고르고, 같은 내용을 세 번 배치해 보며 "어디서부터 메뉴가 한 줄에 서는가", "신간 표지는 몇 단인가"를 함께 정한다. 세 장 사이의 폭에서 어떻게 될지는 그림으로 다 그릴 수 없으니 글로 적어 둔다. "카드는 최소 140픽셀, 남는 폭은 나눠 갖는다"처럼. 개발자에게 넘기는 것은 그림 세 장과 이 문장들이다. 그림은 예시이고, 문장이 규칙이다.

화면을 정하는 것은 사람이다

창 폭만이 아니다. 웹 페이지를 보는 사람은 디자이너가 모르는 사이에 화면을 바꾼다. 휴대폰의 글자 크기 설정을 키우고, 브라우저에서 페이지를 확대하고, 운영체제를 어두운 화면 모드로 쓰고, 움직임을 줄이는 설정을 켜 둔다. 화면 낭독기로 페이지를 귀로 듣는 사람도 있고, 마우스 없이 키보드만 쓰는 사람도 있다. 이런 설정은 대개 그 사람에게 꼭 필요해서 켠 것이다. 웹 페이지가 존중해야 하는 것은 디자이너의 시안이 아니라 이 설정들이다.

특히 글자 크기 설정은 레이아웃을 가장 자주 무너뜨린다. 시안을 기본 글자 크기로만 그리면, 글자가 커졌을 때 넘칠 자리가 없다. 아래 시뮬레이터는 휴대폰(360) 또는 태블릿(768) 폭의 첫 화면을 두 개 나란히 놓는다. 왼쪽은 기본 글자 크기, 오른쪽은 슬라이더로 키운 글자 크기다. "헤더 높이 고정"은 시안에서 잰 머리 부분의 높이를 그대로 못 박은 경우다.

SIMULATOR

글자를 키우면 메뉴는 어디로 가나

메뉴 줄 수—
헤더 밖으로 넘친 높이—
"신청하기"가 첫 화면에—
해볼 것: ① 처음 모습(160%, 헤더 고정)에서 오른쪽 화면을 본다. 메뉴가 두 줄로 꺾였는데 헤더 높이는 그대로라서, 둘째 줄이 "다음 모임" 카드 위로 넘쳐 제목과 겹친다. ② "헤더 높이 고정"을 끈다. 헤더가 내용에 맞춰 늘어나고 겹침이 사라진다. 대신 카드와 버튼이 아래로 밀린다. 글자가 커지면 한 화면에 들어가는 내용이 줄어드는 것은 자연스러운 일이다. ③ 글자 크기를 200%로 올리고 태블릿 768로 바꾼다. 넓은 화면에서도 메뉴가 로고 옆 한 줄에 서지 못하고 아래로 내려간다. (가상의 페이지다. 글자 크기 설정은 모든 글자를 같은 배율로 키우는 것으로 단순화했다. 실제로 이 설정이 웹 페이지에 어떻게 반영되는지는 기기와 브라우저마다 다르다. 2장.)

겹친 메뉴는 버그처럼 보이지만, 원인은 코드보다 시안에 있다. 시안은 "메뉴는 한 줄"이라는 가정을 그림으로 굳혔고, 개발자는 그 그림의 높이를 숫자로 옮겼다. 글자 크기를 키운 사람에게는 그 가정이 맞지 않는다. 흐르는 레이아웃이 폭을 정하지 않는 것처럼, 높이도 될 수 있으면 정하지 않고 내용에 맞춰 늘어나게 두는 것이 웹의 기본이다. 상자의 크기를 어떻게 정하는지는 3장, 글자 크기를 사용자 설정에 맞춰 늘어나는 단위(rem)로 정하는 법은 6장에서 다룬다.

내 휴대폰의 글자를 가장 크게 휴대폰의 화면 설정에서 글자 크기를 가장 크게 바꾼다(어디에 있는지는 기기마다 다르다). 그 상태로 자주 쓰는 웹사이트 세 곳(은행, 동네 가게, 뉴스 등)을 브라우저로 열어 본다. 각 사이트에서 ① 메뉴가 두 줄로 꺾이거나 글자가 잘리는 곳, ② 글자는 커졌는데 버튼이나 칸이 그대로라 넘치는 곳, ③ 글자가 전혀 커지지 않은 곳을 찾아 화면을 캡처하고 종이에 한 줄씩 적는다. 다 보면 설정을 원래대로 돌린다. 이 목록은 11장에서 다시 쓴다.

손가락, 커서, 키보드

화면의 크기만큼 다른 것이 화면을 다루는 손이다. 마우스 커서는 한 점을 정확히 가리키고, 누르기 전에 위에 올려 둘 수 있다(호버). 손가락은 커서보다 훨씬 뭉툭하고, 누르기 전에 올려 둘 수 없으며, 누르는 동안 자기 손가락이 목표를 가린다. 키보드만 쓰는 사람은 Tab 키로 링크와 버튼을 하나씩 옮겨 다니므로, 지금 어디에 있는지 보여 주는 표시(포커스 표시)가 없으면 길을 잃는다.

아래 시뮬레이터는 행사 일정 페이지에서 날짜를 고르는 칩 다섯 개를 확대해 보여 준다. 칩을 누르면 그 칩을 노리고 누른 손길 80번이 어디에 떨어지는지 점으로 찍힌다. 마우스와 손가락을 바꾸고, 칩 크기를 바꿔 본다.

SIMULATOR

커서는 점, 손가락은 얼룩

칩을 눌러 목표를 고른다
노린 칩을 누름—
옆 칩을 누름—
칩 높이(휴대폰 실제 크기)—
해볼 것: ① 처음 모습(손가락, 칩 크기 24)에서 가운데 칩을 누른다. 점의 얼룩이 칩보다 넓게 퍼져, 노린 칩을 누르는 것은 절반쯤이고 열에 한 번꼴로 옆 날짜를 누른다. 나머지는 빈 곳에 떨어진다. ② 마우스 커서로 바꾼다. 같은 칩인데 거의 모든 점이 칩 안에 모인다. 시안을 마우스로 확인하는 디자이너가 이 문제를 놓치기 쉬운 이유다. ③ 다시 손가락으로 돌아가 칩 크기를 44 이상으로 키운다. 칩이 커질수록 노린 칩을 누르는 비율이 올라가지만, 한 줄에 들어가는 칩 수는 줄어든다. (교육용 가정: 누른 점은 노린 곳을 중심으로 정규분포로 흩어지고, 표준편차는 손가락 약 2 mm, 마우스 약 0.2 mm로 두었다. 휴대폰의 1 CSS px은 약 0.16 mm로 가정했다. 실제 흩어짐은 사람, 손의 떨림, 자세, 한 손 사용 여부에 따라 크게 다르다.)

손가락의 흩어짐은 칩의 크기와 간격 둘 다로 줄일 수 있다. 칩이 크면 노린 칩 안에 떨어지는 점이 늘고, 칩 사이가 벌어지면 빗나간 점이 옆 칩 대신 빈 곳에 떨어진다. 빈 곳을 누르면 아무 일도 일어나지 않으니 다시 누르면 되지만, 옆 날짜를 누르면 엉뚱한 행사 페이지가 열린다. 웹 접근성 표준 WCAG 2.2는 누를 대상의 최소 크기를 하나의 성공 기준(2.5.8)으로 두었고, 휴대폰 플랫폼의 디자인 지침들은 그보다 큰 값을 권한다. 그 수치와 출처, 그리고 크기와 거리로 누르는 시간을 설명하는 피츠의 법칙은 7장에서 다룬다.

호버가 없는 기기라는 것도 기억해 둔다. 마우스를 올려야만 나타나는 설명이나 메뉴는 손가락으로는 볼 수 없다. 키보드로 쓰는 사람에게는 포커스가 지금 어디 있는지가 마우스 커서와 같은 구실을 한다. 상태를 어떻게 보여 줄지는 7장, 메뉴를 어떻게 펼치고 숨길지는 8장, 손가락으로 칸을 채우는 폼은 9장의 주제다.

모두에게, 빨리

웹 페이지는 내려받아야 보인다. 포스터는 붙이는 순간 다 보이지만, 웹 페이지는 글과 그림, 글꼴 파일이 통신망을 타고 도착하는 만큼만 보인다. 사진 한 장이 몇 메가바이트이면 빠른 와이파이에서는 눈치채지 못해도, 붐비는 지하철의 휴대폰 데이터에서는 몇 초씩 빈 화면을 보게 된다. 페이지의 무게는 개발자의 일처럼 보이지만, 무거운 사진과 글꼴을 고르는 것은 대개 디자이너다.

아래 시뮬레이터는 첫 화면을 띄우는 데 필요한 파일들이 도착하는 순서를 시간 막대로 그린다. 첫 화면 사진의 용량과 통신 환경을 바꾸고, 한글 웹폰트 전체 파일을 쓰는지 켜고 끈다.

SIMULATOR

첫 화면이 뜨기까지

글자가 처음 보임—
사진까지 다 보임—
페이지 무게—
해볼 것: ① 처음 모습(휴대폰 데이터, 사진 4 MB, 웹폰트 켬)에서 사진까지 다 보이는 데 걸리는 시간을 본다. 막대 대부분이 사진과 글꼴이다. ② "붐비는 지하철"로 바꾼다. 글자는 1.5초쯤에 보이지만, 사진이 다 오기까지 30초 넘게 걸린다. ③ 사진을 0.3 MB로 줄이고 웹폰트를 끈다. 같은 망에서 기다리는 시간이 몇 분의 일로 준다. 사진을 얼마나 줄일 수 있는지, 웹폰트를 버리지 않고 가볍게 하는 법은 12장에서 다룬다. (교육용 단순 모형: 망의 속도와 왕복 시간은 대표값으로 정했고, 연결 준비를 왕복 3번, HTML 30 KB와 CSS 20 KB를 차례로 받은 뒤 사진과 글꼴이 대역을 나눠 쓴다고 가정했다. 실제 페이지는 압축, 캐시, 동시 요청, 우선순위에 따라 크게 다르다. 글자는 웹폰트가 오기 전에도 기기의 글꼴로 먼저 보인다고 가정했다.)

페이지가 빨리 뜨는 것과 모두가 쓸 수 있는 것은 같은 질문의 두 얼굴이다. 느린 망을 쓰는 사람, 오래된 휴대폰을 쓰는 사람, 화면을 귀로 듣는 사람, 손이 떨리는 사람, 글자를 크게 키운 사람에게 페이지가 닿는가. 웹에는 이 질문을 점검하는 공개 기준이 있다. 웹 접근성은 W3C의 WCAG(Web Content Accessibility Guidelines) 2.2와 이를 바탕으로 한 한국형 웹 콘텐츠 접근성 지침(KWCAG 2.2)이 기준이 되고(11장), 속도는 구글의 web.dev가 제안한 핵심 웹 지표(Core Web Vitals)가 널리 쓰인다(12장). 이 책은 이런 기준의 수치를 출처와 함께 쓰고, 기준이 없는 것은 그렇다고 밝힌다.

내 화면은 대표가 아니다 디자이너와 개발자의 장비는 대개 평균보다 좋다. 넓고 촘촘한 화면, 빠른 회사 와이파이, 최신 휴대폰, 기본 글자 크기, 마우스. 그 장비에서 완벽해 보이는 페이지가 손님의 화면에서는 전혀 다르게 보일 수 있다. 시안을 확인할 때는 적어도 한 번은 오래된 휴대폰, 휴대폰 데이터, 가장 큰 글자 크기, 키보드만으로 열어 본다. 이 책의 시뮬레이터들이 그 대신이 될 수는 없다. 시뮬레이터는 원리를 보여 주는 단순 모형이고, 마지막 확인은 실제 기기에서 한다.

통설과 근거

웹 디자인에도 규칙처럼 도는 말이 많다. 일부는 특정 시기의 기술이나 특정 사이트의 관찰에서 나와 조건을 잃은 채 퍼졌고, 일부는 근거가 확인된 표준이다. 이 책은 둘을 구별해 쓴다. 표준은 출처와 수치를 밝히고, 통설은 근거의 수준을 밝힌다.

흔히 듣는 말근거의 수준(이 책의 판단)다루는 장
첫 화면(접힘선) 아래는 아무도 보지 않는다통설. 사람들은 내용이 이어진다는 단서가 있으면 스크롤한다는 관찰이 많다. 다만 시선과 주의가 위쪽에 더 몰린다는 보고도 있다. "아무도"는 틀렸고 "위쪽이 더 많이 보인다"는 대체로 맞다.2장
무엇이든 세 번 클릭 안에 닿아야 한다통설. 클릭 수 자체보다 단계마다 다음에 무엇을 누를지 분명한지가 중요하다는 관찰이 있다. 수치 규칙으로 쓰지 않는다.8장
햄버거 메뉴(≡)는 이제 누구나 안다근거가 엇갈린다. 익숙한 사람이 늘었지만, 숨긴 메뉴는 펼쳐 둔 메뉴보다 덜 쓰인다는 사용성 관찰이 꾸준히 보고된다. 누가 쓰는 사이트인지로 판단한다.8장
누를 대상은 최소 24×24 CSS px표준. W3C WCAG 2.2 성공 기준 2.5.8 대상 크기(최소), AA 등급. 예외 조건이 있다. 플랫폼 지침의 더 큰 값은 출처와 함께 따로 다룬다.7장
글자는 200%까지 키워도 깨지지 않아야 한다표준. WCAG 2.2 성공 기준 1.4.4 글자 크기 조정, AA 등급.2장, 11장
표준, 지침, 통설 이 책에서 표준은 W3C 권고안(WCAG, CSS 명세)처럼 공개 절차를 거쳐 정해진 문서를 말한다. 수치가 분명하고 출처를 댈 수 있다. 지침은 운영체제를 만드는 회사나 디자인 시스템이 자기 플랫폼을 위해 낸 권고다. 근거가 있지만 그 플랫폼의 사정에 맞춘 값이다. 통설은 출처가 분명하지 않거나, 한 연구의 결과가 조건을 잃고 퍼진 말이다. 같은 "44"라도 어디서 온 숫자인지에 따라 무게가 다르다. 숫자를 들으면 먼저 "누가, 무엇을 위해 정한 값인가"를 묻는다.

이 책의 지도

지금까지 만난 질문은 네 갈래로 모인다. 화면은 크기를 정할 수 없는 캔버스와 그 위의 상자다(뷰포트와 픽셀, 박스와 간격). 배치는 그 캔버스 위에 내용을 놓고 늘이는 규칙이다(레이아웃 그리드, 반응형, 색과 글자의 체계). 상호작용은 사람이 화면과 주고받는 방식이다(컴포넌트와 상태, 내비게이션, 폼, 모션). 쓰임은 그 결과가 모두에게, 빨리 닿는지다(접근성, 속도). 이 책의 네 부가 이 네 갈래다.

① 화면 ② 배치 ③ 상호작용 ④ 쓰임 뷰포트 · 박스 그리드 · 반응형 상태 · 폼 · 모션 접근성 · 속도 2·3장 4·5·6장 7·8·9·10장 11·12장 쓰임에서 찾은 문제는 화면과 배치로 돌아가 고친다 13장 웹 실험실에서 네 갈래를 한꺼번에 점검한다
그림 2. 웹 디자인의 네 갈래. 화면의 성질(①)을 알면 그 위에 배치의 규칙을 세우고(②), 사람이 누르고 고르고 적는 방식을 설계한다(③). 그 결과가 모두에게 빨리 닿는지 점검하고(④), 문제가 보이면 다시 앞 갈래로 돌아간다. 아래 숫자는 각 갈래를 다루는 장이다.
01 지도 13 실험실 14 용어집 화면 배치 상호작용 쓰임
그림 3. WebBook의 지도. 1장을 가운데 두고 2~12장이 둘레를 돈다. 칸의 색은 부를 나타낸다. 화면에서 시작해 배치, 상호작용, 쓰임으로 갈수록 다루는 범위가 한 픽셀에서 한 페이지, 한 사람의 하루로 넓어진다. 둘레를 다 돌면 13장 실험실에서 모든 도구를 한꺼번에 쓴다. 칸을 누르면 그 장으로 간다.

마지막 시뮬레이터는 이 지도를 한 페이지 위에 겹쳐 본다. 책방 E의 가상 페이지 하나를 놓고, 창 폭(오른쪽 손잡이), 글자 크기, 레이아웃 방식, 첫 화면 사진을 바꾼다. 아래 읽기 판의 네 칸이 네 갈래의 질문에 하나씩 답한다.

SIMULATOR

한 페이지, 네 가지 질문

끌어서 창 폭을 바꾼다
① 화면: 본문이 보이는 크기—
② 배치: 신간 단 수 · 소개 글 한 줄—
③ 상호작용: 메뉴—
④ 쓰임: 휴대폰 데이터로 사진까지—
해볼 것: ① 손잡이를 끌어 창 폭을 360 근처로 줄인다. 흐르는 페이지는 메뉴가 로고 아래로 내려가고 신간이 두 단이 된다. 읽기 판 ①과 ②가 바뀌는 것을 본다. ② "고정 960"으로 바꾼다. 같은 폭에서 본문이 5px 안팎으로 줄고(①), 신간은 좁은 화면에서도 네 단 그대로다(②). ③ 다시 "흐름"으로 돌아와 "헤더 높이 고정"을 켜고 글자 크기를 170% 이상으로 올린다. 메뉴가 넘쳐 카드와 겹친다(③). ④ 첫 화면 사진을 원본 그대로 두었을 때와 끄고(약 0.3 MB로 줄였을 때) 읽기 판 ④를 비교한다. 네 칸이 모두 괜찮은 조합을 찾는 것이 이 책 전체의 일이다. (가상의 페이지와 단순 모형이다. ④는 앞 시뮬레이터의 "휴대폰 데이터" 모형으로 계산했고 웹폰트는 뺐다.)

네 칸은 서로 맞물려 있다. 창 폭을 줄이면 단 수가 바뀌고, 글자를 키우면 메뉴가 꺾이며, 메뉴가 꺾이면 첫 화면에 들어가는 내용이 준다. 첫 화면에 사진을 크게 넣으면 인상은 강해지지만 무게가 늘어난다. 그래서 웹 디자인에는 하나만 고쳐서 끝나는 일이 드물다. 이 책은 손잡이를 하나씩 따로 익힌 다음, 마지막 실험실(13장)에서 다시 한꺼번에 맞춘다. 어느 조합이 정답이라고 말하지 않는다. 동네 책방의 사이트와 은행의 사이트, 매일 쓰는 도구와 한 번 보는 행사 페이지에는 서로 다른 조합이 맞는다.

종이 세 장으로 그리는 시안 A4 종이 세 장을 준비해 휴대폰, 태블릿, 넓은 화면의 비율로 틀을 그린다. 폭을 9 cm, 19 cm, 그리고 종이를 가로로 눕혀 27 cm쯤으로 잡으면 360·768·1280의 비율과 비슷하다(높이는 자유롭게). 자주 가는 동네 가게나 단체의 첫 화면을 하나 골라, 그 안의 내용(이름, 메뉴, 가장 중요한 소식, 버튼, 사진)을 세 틀에 연필로 각각 배치한다. 그린 뒤 세 장을 나란히 놓고 ① 세 장에서 순서가 같은가, ② 좁은 틀에서 무엇을 아래로 내렸는가, ③ 넓은 틀에서 빈 곳을 무엇으로 채웠는가를 적는다. 그 답이 반응형의 규칙이 된다.
창 폭 일지 컴퓨터의 브라우저에서 아무 웹사이트나 열고, 창의 오른쪽 끝을 마우스로 잡아 천천히 좁혀 본다(개발자 도구의 "반응형 디자인 모드"를 쓰면 폭이 숫자로 보인다). 메뉴가 바뀌는 순간, 사진이 위아래로 쌓이는 순간, 글자가 잘리거나 옆으로 밀어야 하는 순간마다 멈추고 그 폭을 적는다. 세 사이트를 해 보면 사이트마다 바뀌는 폭이 다르다는 것을 알게 된다. 그 숫자들이 왜 거기에 있는지는 5장에서 다시 묻는다.

서윤의 웹 개편 노트

CASE 서윤웹 개편 노트 · 1장

이건 그림이지 웹이 아니에요

책방 E의 색을 정하고(2026년 가을), 진열과 포스터를 짜고, 안내 책자의 드로잉을 그리고, 간판과 소식 글을 조판하고, 그림 읽기 모임을 꾸리고, 겨울 내내 사진을 찍은 윤서윤에게 2028년 1월 첫 주, 주인이 다시 부탁을 했다. "모임 신청을 전화로 받느라 하루가 다 가요." 책방의 웹사이트는 2019년쯤 산 템플릿 그대로였다. 페이지 폭이 960픽셀로 고정되어 있어서 휴대폰으로 열면 페이지가 통째로 줄어 글자가 깨알 같았다. 모임 신청은 아예 받을 수 없어 "전화 주세요"라는 문장만 있었다. 서윤은 사이트를 처음부터 다시 만들기로 했다. 목표는 3월 첫 주 공개다.

서윤은 주말 이틀 동안 노트북(창 폭 1440)에서 디자인 도구를 열고 첫 화면을 공들여 그렸다. 왼쪽에 다음 모임의 제목과 날짜, 오른쪽에 겨울에 찍은 쇼윈도 사진, 아래에 행사 일정과 신간 표지 네 권. 회사 동료인 프런트엔드 개발자 오지후가 퇴근 뒤 코드를 맡아 주기로 했다. 지후는 서윤이 보낸 시안 그림을 자기 휴대폰(창 폭 360)에서 열었다. 그림은 화면 폭에 맞춰 4분의 1로 줄었고, 서윤이 17px로 정한 본문은 4px 남짓이 되었다. 회사의 넓은 모니터(창 폭 1920)에서는 그림이 가운데에 떠서 양옆이 비었다. 지후가 말했다. "이건 그림이지 웹이 아니에요. 화면 크기는 우리가 정할 수 없어요."

지후는 그 자리에서 시안의 첫 화면만 대충 코드로 옮겨, 서윤의 멘토인 화가 한도경에게 링크를 보냈다. 도경은 휴대폰의 글자 크기를 가장 크게 해 두고 쓴다. 답장으로 온 화면 캡처에서는 메뉴 다섯 개가 두 줄로 꺾여, 둘째 줄의 "소개"와 "오시는 길"이 "1월 그림책 낭독 모임" 제목 위에 겹쳐 있었다. 지후가 시안에서 잰 헤더 높이를 그대로 못 박았기 때문이다. 도경은 "글자가 큰 건 좋은데 메뉴가 제목을 가렸다"고 적었다. 서윤은 이 장의 시뮬레이터로 같은 일을 다시 해 보고, 그림 한 장을 완성하는 방식으로는 이 문제를 미리 볼 수 없다는 것을 받아들였다.

서윤의 선택은 시안을 다시 그리기 전에 두 가지를 먼저 정하는 것이었다. 하나는 새 사이트에 들어갈 페이지 목록이다. 주인과 이야기해 꼭 필요한 다섯 페이지만 남겼다. 다른 하나는 시안을 그리는 방식이다. 한 폭의 완성 그림 대신, 처음부터 세 폭에 같은 내용을 나란히 그리고, 그 사이의 폭에서 일어날 일은 문장으로 적기로 했다. 지후는 세 폭이 "기기 이름"이 아니라 폭의 견본일 뿐이라는 조건을 달았다.

이 장에서 정한 것새 사이트의 페이지 다섯: ① 첫 화면 ② 행사 일정 ③ 모임 신청 폼 ④ 신간 목록 ⑤ 서점 소개·오시는 길. 시안은 처음부터 세 폭 360 · 768 · 1280(CSS px)으로 같은 내용을 나란히 그리고, 세 폭 사이에서 일어날 일은 문장(규칙)으로 적는다. 세 폭은 기기의 이름이 아니라 폭의 견본이다. 공개 목표는 2028년 3월 첫 주. 책방 E의 색(책방 초록 #2f7d5b, 크림 #ffe2d7, 차분한 초록 #567666, 강조 #d24f39, 짙은 색 #22342a)과 TypeBook에서 정한 본문 글자(Pretendard 계열 고딕, 본문 17px 안팎)를 이어 쓴다.
아직 남은 문제책방 E의 손님들은 실제로 어떤 화면으로 사이트를 여는가. 서윤의 휴대폰에서는 1픽셀 선이 왜 노트북에서보다 가늘고 또렷해 보이는가. 주인은 "첫 화면에 다 보여야 한다"고 한다.
다음 단계2장: 지후가 옛 사이트의 지난달 방문 기록을 꺼내 화면 폭의 분포를 본다.

핵심 정리

  1. 웹 페이지는 크기를 정할 수 없는 캔버스 위에 놓인다. 페이지가 그려지는 창 안의 영역(뷰포트)은 기기, 창 크기, 방향, 확대에 따라 사람마다 다르다.
  2. 웹 디자이너가 만드는 것은 한 장의 완성 그림이 아니라 폭이 바뀔 때 배치가 어떻게 바뀔지에 대한 규칙이다. 한 폭에서 완성한 그림은 다른 폭에서 줄어들어 읽을 수 없거나 비어 보인다.
  3. 고정폭 레이아웃은 좁은 창에서 줄어들거나 잘리고 넓은 창에서 빈다. 흐르는 레이아웃은 창을 채우며 다시 흐르고, 최대 폭을 두어 넓은 창의 긴 글줄을 막는다.
  4. 화면을 정하는 것은 사람이다. 글자 크기 설정, 확대, 어두운 화면, 움직임 줄이기, 키보드와 화면 낭독기. 높이와 폭을 못 박지 않고 내용에 맞춰 늘어나게 두면 이 설정들을 견딘다.
  5. 손가락은 커서보다 뭉툭하고 호버가 없다. 누를 대상의 크기와 간격이 잘못 누르는 비율을 바꾼다.
  6. 페이지의 무게는 첫 화면이 뜨는 시간을 정하고, 무거운 사진과 글꼴은 대개 디자이너가 고른다. 접근성과 속도에는 공개 기준(WCAG 2.2, KWCAG 2.2, 핵심 웹 지표)이 있고, "접힘선 아래는 아무도 안 본다" 같은 통설은 근거의 수준을 밝혀 다룬다.

확인 퀴즈

1. 창 폭 1440의 노트북에서 한 장의 그림으로 완성한 시안을 창 폭 360의 휴대폰에서 화면 폭에 맞춰 줄여 보면 무슨 일이 생기는가?

그림은 배치의 규칙을 담고 있지 않으므로, 좁은 화면에 넣으려면 통째로 줄이는 수밖에 없다. 17 × 360 ÷ 1440 ≈ 4.3px이다. 메뉴를 내리고 사진을 쌓는 일은 흐르는 레이아웃이 규칙에 따라 해 주는 일이지 그림이 저절로 하지 않는다. 화면이 촘촘해도 글자가 4분의 1로 작아진 것은 바뀌지 않는다.

2. 도경의 휴대폰(글자 크기 최대)에서 메뉴의 둘째 줄이 "다음 모임" 제목 위에 겹쳐 보였다. 가장 알맞은 원인과 고칠 방향은?

글자가 커지면 메뉴가 꺾이는 것은 자연스럽다. 문제는 꺾인 메뉴가 들어갈 자리를 막은 고정 높이다. 높이를 내용에 맞춰 늘어나게 두면 헤더가 커지고 겹침이 사라진다. 사용자 설정을 무시하는 것은 그 설정이 꼭 필요한 사람을 내쫓는 일이고, 메뉴를 줄여도 글자가 더 커지면 같은 일이 생긴다.

3. 페이지 폭이 960픽셀로 고정된 옛 사이트를 창 폭 1600의 넓은 모니터와 창 폭 360의 휴대폰에서 연다. 옳은 설명은?

고정폭 페이지는 창 폭과 상관없이 960으로 그려진다. 1600 창에서는 (1600 − 960) ÷ 1600 = 40%가 비고, 360 창에서는 휴대폰 브라우저가 페이지를 줄여 맞추거나(글자가 깨알) 잘린 오른쪽을 옆으로 밀어 봐야 한다. 창에 맞춰 다시 흐르는 것은 흐르는 레이아웃이다.

4. "첫 화면(접힘선) 아래는 아무도 보지 않는다"는 말에 대해 이 책이 취하는 태도는?

접힘선에 관한 규칙은 어떤 표준에도 없다. 스크롤을 하지 않는다는 믿음은 여러 관찰로 반박되었지만, 주의가 위쪽에 더 몰린다는 보고도 있어 "아무도 안 본다"도 "상관없다"도 맞지 않는다. 게다가 첫 화면의 높이는 기기마다 달라 접힘선은 한 줄이 아니다. 자세한 것은 2장에서 다룬다.

출처