타이포 위계 점검 체크리스트

타이포 위계 점검 체크리스트

---

ViewCheck 마케팅 홍보 — 2026년 9월 · W3 타이포(Pretendard GOV) (9/21~9/27)

대주제: 디자인 일관성·토큰 · 홍보 훅: 토큰 채택률 리포트

【 공감·문제제기 】

이번 주는 ‘타이포’를 다뤘다. 월요일엔 공공 사이트에서 글씨가 왜 그렇게 중요한지, 수요일엔 Pretendard GOV라는 글꼴이 왜 표준으로 자리 잡았는지를 이야기했다. 오늘은 그 마무리로, 가장 손에 잡히는 이야기를 해보려 한다. ‘우리 사이트의 글자 위계가 제대로 잡혀 있는가’를 담당자가 직접 점검하는 체크리스트다.

먼저 솔직하게 털어놓자. ‘타이포 위계’라는 말을 들으면 디자이너들이나 신경 쓰는 전문 용어처럼 느껴진다. 나도 처음엔 그랬다. 글씨 크기 좀 다른 게 뭐 그리 대수인가 싶었다. 그런데 공공 사이트를 수백 개 들여다보면서 생각이 완전히 바뀌었다. 사용자가 ‘이 사이트 뭔가 읽기 불편하다’고 느끼는 순간의 절반 이상이, 알고 보면 글자 위계가 무너진 데서 나온다. 제목인지 본문인지 구분이 안 되고, 중요한 안내문이 사소한 각주처럼 작게 박혀 있고, 표 안의 글씨와 바깥 글씨가 따로 노는 — 그런 자잘한 어긋남들이 쌓여 ‘읽기 싫은 사이트’를 만든다.

타이포 위계란 거창한 게 아니다. ‘제목은 크고 진하게, 본문은 적당하게, 부가 설명은 작고 연하게’ — 글의 중요도에 따라 크기·굵기·색을 단계적으로 다르게 주는 것. 그게 전부다. 우리가 종이 문서를 볼 때 큰 제목, 중간 소제목, 본문, 각주를 자연스럽게 구분하듯, 화면에서도 그 ‘단계’가 또렷해야 사용자의 눈이 길을 잃지 않는다. 위계가 무너지면 사용자는 ‘무엇부터 읽어야 하는지’를 매 순간 스스로 판단해야 한다. 그 작은 인지 부담이 모이면, 멀쩡한 내용도 ‘복잡하고 어려운 사이트’로 둔갑한다.

그런데 이게 왜 디자인 담당자만의 일이 아닌가. 공공 사이트엔 매일같이 새 글이 올라간다. 보도자료, 공지, 안내문, 신청 양식 설명 — 그걸 올리는 건 디자이너가 아니라 각 부서의 담당자다. 그리고 글을 올릴 때 ‘이 제목은 제목 스타일로, 이 본문은 본문 스타일로’ 제대로 지정하지 않으면, 아무리 잘 만든 디자인 시스템도 그 페이지에서만큼은 무너진다. 그래서 타이포 위계는 디자이너가 ‘설계’하고, 모든 담당자가 ‘유지’하는 공동의 책임이다. 오늘 체크리스트가 디자인 전공자가 아니어도 따라 할 수 있게 만들어진 이유가 여기 있다.

오늘 글의 성격을 분명히 해두자. 이건 이론 강의가 아니라 ‘자가 점검 매뉴얼’이다. 우리 기관 사이트를 한쪽에 띄워두고, 항목을 하나씩 읽으며 ‘예/아니오’를 적어가면 된다. 준비물은 단출하다. 우리 사이트, 데스크탑 브라우저, 그리고 스마트폰. 글씨는 기기마다 다르게 보이니 데스크탑과 모바일 둘 다 확인하는 게 좋다. 펜과 종이, 혹은 메모 앱에 ‘아니오’가 나온 항목을 적어두면 그게 나중에 개선 작업 지시서가 된다.

한 가지 마음가짐만 당부하자. 이건 시험이 아니라 건강검진이다. ‘아니오’가 많이 나올수록 점검이 잘된 거다. 문제를 많이 찾았다는 건 고칠 거리를 그만큼 확보했다는 뜻이고, 사이트가 좋아질 여지가 그만큼 크다는 뜻이다. 모든 항목에 ‘예’를 적고 있다면, 점검이 잘된 게 아니라 너무 후하게 보고 있는 건 아닌지 의심해야 한다. 자기 사이트에 엄격한 점검자가 좋은 점검자다. 이 글을 읽는 동안만큼은, 우리 사이트를 ‘처음 들어온 까다로운 사용자’의 눈으로 봐주길 바란다. 매일 보던 화면이라 익숙해진 눈으로는, 정작 가장 큰 문제가 안 보인다.

그리고 이 점검의 매력 하나. 돈이 안 든다. 외부 컨설팅을 부르거나 도구를 사기 전에, 지금 당장 10분이면 시작할 수 있다. 결재도, 예산도, 누구의 허락도 필요 없다. 그저 우리 사이트의 글자들을 사용자의 눈으로 천천히 들여다보는 것뿐이다. 그 작은 시작이 ‘우리 사이트를 제대로 보기’의 첫걸음이 된다. 거창한 개편 계획을 세우기 전에, 먼저 ‘지금 글자가 어떤 상태인지’ 아는 것 — 모든 개선은 거기서 출발한다.

한 가지 더 솔직히 고백하자면, 나도 이 일을 시작하기 전엔 ‘글씨 위계’ 같은 말을 거의 안 썼다. 그런데 어느 날 한 지자체 담당자가 보내온 메일이 생각을 바꿨다. ‘우리 사이트에 민원이 들어왔는데, 지원 마감일을 못 봤다는 항의였다’는 내용이었다. 마감일은 분명히 페이지에 적혀 있었다. 다만 그게 본문 한가운데, 다른 평범한 문장들과 똑같은 크기로 박혀 있었을 뿐이다. 만든 사람 눈에는 ‘다 적어놨는데 왜 못 봤지’ 싶었겠지만, 처음 온 사용자 눈에는 그 한 줄이 다른 수십 줄과 구분되지 않았던 것이다. 그때 깨달았다. 위계는 디자인 취향의 문제가 아니라 ‘사용자가 중요한 걸 놓치느냐 마느냐’의 문제구나. 그 메일 한 통이 오늘 이 체크리스트를 만들게 된 계기다.

또 하나, 이 점검은 ‘디자인 외주에게 맡기면 끝’이 아니라는 점도 강조하고 싶다. 외주가 사이트를 멋지게 만들어 납품하고 떠난 뒤에도, 사이트는 매일 살아 움직인다. 새 공지가 올라가고, 새 안내문이 추가되고, 새 신청 양식이 만들어진다. 그 모든 ‘새것’을 올리는 건 기관의 담당자다. 외주가 잡아놓은 위계는 ‘처음 모습’일 뿐, 그걸 유지하는 건 결국 매일 콘텐츠를 다루는 내부 담당자의 몫이다. 그래서 디자인 비전공자인 담당자가 ‘무엇이 좋은 위계인가’를 아는 것이, 비싼 외주 한 번보다 사이트의 장기 건강에 더 큰 영향을 준다. 오늘 체크리스트가 디자이너가 아닌 사람을 위해 쓰인 이유가 거기 있다.

【본론 1 — 왜 타이포 위계가 사이트의 뼈대인가】

■ 글자 위계는 ‘읽는 순서’를 설계하는 일

사람은 화면을 글자 단위로 읽지 않는다. 먼저 ‘훑는다’. 페이지에 들어선 순간 눈은 0.1초 만에 ‘여기서 제일 중요한 게 뭐지’를 찾아 헤맨다. 이때 길잡이가 되는 게 바로 글자의 크기와 굵기다. 큰 글씨에 먼저 눈이 가고, 진한 글씨를 중요하다고 여기고, 작고 연한 글씨는 ‘부가 정보겠거니’ 하고 넘긴다. 우리가 의식하지 못할 뿐, 모든 사용자가 매 순간 이 ‘크기의 문법’으로 화면을 해석한다.

그래서 타이포 위계가 잘 잡힌 사이트는 ‘읽으라고 시키지 않아도 알아서 읽게’ 만든다. 가장 중요한 공지가 가장 크게, 그다음 안내가 중간 크기로, 세부 조건이 작게 — 이 단계가 또렷하면 사용자는 자기도 모르게 중요한 순서대로 정보를 받아들인다. 반대로 위계가 무너진 사이트는 모든 글자가 비슷한 크기로 늘어서 있어, 사용자가 ‘무엇이 중요한지’를 스스로 일일이 판단해야 한다. 이건 마치 강조 표시 하나 없는 계약서를 통째로 들이미는 것과 같다. 다 중요해 보이니, 결국 아무것도 제대로 안 읽힌다.

공공 사이트는 특히 이게 치명적이다. 공공 사이트의 글은 대개 ‘읽고 싶어서’가 아니라 ‘읽어야 해서’ 읽는 글이다. 지원금 신청 조건, 제출 서류, 마감일, 제외 대상 — 한 줄만 놓쳐도 신청이 반려되는 정보들이다. 그런데 그 결정적인 한 줄이 다른 평범한 문장과 똑같은 크기로 본문 한가운데 묻혀 있으면, 사용자는 그걸 놓친다. 놓친 책임은 사용자에게 있다고 말할 수도 있다. 하지만 좋은 사이트는 ‘사용자가 놓치지 않도록 설계’한다. 마감일과 제외 대상을 눈에 띄게 키우고 강조하는 것 — 그게 위계 설계의 본질이다.

게다가 공공 사이트의 사용자층은 민간 서비스보다 훨씬 넓다. 20대 대학생부터 80대 어르신까지, 디지털에 익숙한 사람부터 인터넷이 서툰 사람까지 모두가 같은 페이지를 본다. 디지털에 능숙한 사용자는 위계가 좀 어설퍼도 ‘알아서’ 핵심을 찾아낸다. 하지만 인터넷이 서툰 사용자는 화면의 시각적 단서에 훨씬 더 의존한다. 큰 글씨, 진한 글씨를 길잡이 삼아 ‘여기가 중요하구나’를 판단한다. 그래서 위계가 무너진 사이트는 ‘디지털 약자에게 더 가혹하다’. 능숙한 사람은 어떻게든 헤쳐 나가지만, 서툰 사람은 그 자리에서 막혀버린다. 공공 서비스가 위계에 더 엄격해야 하는 이유가 여기 있다. ‘누구나’ 쓸 수 있어야 하는 서비스라면, ‘가장 도움이 필요한 사람’의 눈높이에 맞춰야 한다.

■ 위계는 ‘크기’만의 문제가 아니다

흔히 위계라고 하면 글씨 크기만 떠올린다. 하지만 위계를 만드는 도구는 네 가지다. 크기, 굵기, 색(명도), 그리고 여백이다. 이 넷을 조합해 ‘단계’를 만든다.

크기는 가장 직관적인 도구다. 제목 32, 소제목 24, 본문 16처럼 단계마다 다른 크기를 준다. 하지만 크기만으로 모든 단계를 표현하려 들면 글씨가 너무 커지거나 너무 작아지는 문제가 생긴다. 그래서 굵기를 함께 쓴다. 같은 크기여도 진하면 더 중요하게, 가늘면 덜 중요하게 보인다. 색(명도)도 마찬가지다. 본문은 진한 회색, 부가 설명은 연한 회색으로 두면, 크기를 바꾸지 않고도 ‘이건 곁다리 정보’라는 신호를 줄 수 있다.

여백은 가장 자주 잊히는 도구다. 제목 위아래에 충분한 여백을 주면, 그 제목이 ‘새로운 묶음의 시작’임을 시각적으로 선언한다. 여백이 없으면 제목이 바로 위 문단에 들러붙어, 어디까지가 앞 이야기고 어디부터가 새 이야기인지 흐려진다. 좋은 위계는 글자 자체뿐 아니라 ‘글자 사이의 빈 공간’까지 설계한다. 여백은 비어 있는 게 아니라, ‘여기서 한 묶음이 끝났다’고 말하는 적극적인 신호다.

이 네 도구가 따로 놀면 위계는 어수선해진다. 어떤 제목은 크기로, 어떤 제목은 색으로, 어떤 제목은 여백으로 구분하는 식이면, 사용자는 ‘제목을 알아보는 규칙’을 매번 새로 학습해야 한다. 잘 설계된 사이트는 ‘제목은 항상 이 크기, 이 굵기, 이 여백’이라는 일관된 규칙을 모든 페이지에 똑같이 적용한다. 그 일관성이 쌓이면 사용자는 사이트의 ‘글자 문법’을 한 번만 익히고, 그 뒤로는 어느 페이지에 가도 직관적으로 읽을 수 있게 된다.

여기서 자주 빠지는 함정 하나를 짚고 넘어가자. 도구가 네 개나 되니, 욕심이 나서 한 단계를 표현할 때 네 가지를 다 쓰려는 사람이 있다. 제목을 ‘크게 + 진하게 + 다른 색 + 밑줄 + 넓은 여백’으로 만드는 식이다. 그런데 강조 수단을 너무 많이 겹치면, 오히려 화면이 시끄러워지고 ‘과하다’는 인상을 준다. 좋은 위계는 ‘필요한 만큼만’ 쓴다. 제목과 본문을 구분하는 데 크기 차이 하나로 충분하면 굳이 색까지 바꾸지 않는다. 적게 쓸수록 각 단계의 신호가 또렷해진다. 위계 설계의 고수는 ‘무엇을 더 줄까’보다 ‘무엇을 뺄까’를 더 고민한다.

그리고 이 네 도구에는 ‘우선순위’가 있다. 가장 강력하고 안전한 건 크기와 굵기다. 이 둘은 색을 구분 못 하는 사용자에게도, 흑백으로 출력해도 그대로 전달된다. 반면 색은 보조 수단으로 써야 한다. 색에만 기대 위계를 만들면, 색을 인식하기 어려운 사용자에겐 그 위계가 통째로 사라진다. 그래서 ‘제목은 색으로만 구분’ 같은 설계는 위험하다. 색을 쓰더라도 반드시 크기나 굵기를 함께 줘서, 색이 없어도 단계가 살아 있게 해야 한다. 이건 단순한 디자인 취향이 아니라 접근성의 기본 원칙이다.

■ Pretendard GOV가 위계 설계를 쉽게 만든 이유

수요일 글에서 다뤘듯, 행정안전부가 공공 사이트의 기본 글꼴로 Pretendard GOV 계열을 권장하면서 한 가지 큰 짐이 덜어졌다. 바로 ‘글꼴마다 다른 굵기 체계’를 일일이 신경 쓸 필요가 줄었다는 점이다. 예전엔 사이트마다 제각각인 글꼴을 쓰다 보니, 같은 ‘굵게’를 줘도 글꼴에 따라 두께가 천차만별이었다. 어떤 글꼴은 ‘굵게’가 충분히 진하지 않아 제목과 본문이 구분이 안 됐고, 어떤 글꼴은 너무 진해서 화면이 답답했다.

표준 글꼴 체계가 갖춰지면, 굵기 단계가 정해진다. 보통(Regular), 중간(Medium), 진하게(Bold) 같은 단계가 일관되게 정의돼 있어, ‘본문은 보통, 소제목은 중간, 제목은 진하게’ 같은 규칙을 안심하고 쓸 수 있다. 위계 설계의 절반은 ‘예측 가능한 굵기 체계’에서 나온다. 그게 갖춰지면 담당자는 ‘이 글꼴에서 굵게가 충분히 진할까’를 고민하지 않고, ‘무엇을 강조할까’라는 본질에만 집중하면 된다.

표준 글꼴이 주는 또 하나의 선물은 ‘화면마다 글자가 똑같이 보인다’는 점이다. 예전엔 사이트가 지정한 글꼴이 사용자 컴퓨터에 없으면, 브라우저가 ‘아무 글꼴이나’ 대신 보여줬다. 그래서 만든 사람이 본 화면과 사용자가 보는 화면의 글자가 달랐고, 애써 잡아놓은 위계가 사용자 화면에선 무너지기 일쑤였다. 표준 글꼴 체계는 글꼴 자체를 사이트가 함께 내려주는 방식이라, 어느 사용자가 어떤 기기로 보든 ‘설계한 그대로’의 글자가 표시된다. 위계는 ‘내가 보는 화면’이 아니라 ‘사용자가 보는 화면’에서 지켜져야 의미가 있는데, 표준 글꼴은 그 ‘사용자 화면에서의 일관성’을 보장해준다. 이건 생각보다 큰 진전이다.

여기서 디자인 토큰 이야기가 등장한다. KRDS는 글자의 크기·굵기·줄간격·색을 일일이 손으로 정하는 대신, ‘토큰’이라는 이름표로 정리해 둔다. 이를테면 ‘제목용 큰 글자’, ‘본문용 보통 글자’, ‘설명용 작은 글자’ 각각에 정해진 크기·굵기·줄간격 값을 한 묶음으로 정의해두고, 화면에서는 그 이름표만 가져다 쓴다. 그러면 담당자가 매번 ‘몇 픽셀로 할까, 얼마나 굵게 할까’를 눈대중으로 고를 필요가 없다. 이미 정해진 단계 중에서 ‘이건 제목, 이건 본문’만 고르면 된다. 위계가 무너지는 가장 흔한 원인이 ‘각자 눈대중으로 크기를 정하는 것’이었으니, 토큰은 바로 그 균열을 막는 둑이다.

토큰이라는 개념을 처음 들으면 어렵게 느껴지지만, 사실 우리는 일상에서 비슷한 걸 이미 쓰고 있다. 문서 작성 프로그램의 ‘스타일’ 기능을 떠올려보자. ‘제목 1’, ‘제목 2’, ‘본문’ 같은 스타일을 한 번 정해두면, 글을 쓸 때 ‘이 줄은 제목 1’이라고 지정만 하면 된다. 크기를 직접 손으로 키울 필요가 없다. 나중에 ‘제목 1을 좀 더 키우자’고 마음먹으면, 스타일 정의 하나만 고쳐서 문서 전체의 모든 제목 1을 한꺼번에 바꿀 수 있다. 디자인 토큰은 이 ‘스타일’ 개념을 사이트 전체로 확장한 것이다. 우리가 워드에서 자연스럽게 쓰던 그 편리함을, 웹사이트의 모든 페이지에 똑같이 적용하는 약속인 셈이다.

토큰을 안 쓰는 사이트가 어떻게 무너지는지 익명 사례로 그려보자. 어느 A광역지자체의 사이트는 처음 개편할 땐 본문 크기가 16으로 깔끔하게 통일돼 있었다. 그런데 몇 년이 지나며 부서마다 새 페이지를 추가했고, 그때마다 담당자가 ‘대충 적당한 크기’로 본문을 박았다. 어떤 페이지는 15, 어떤 페이지는 17, 또 어떤 페이지는 14. 개별로 보면 다 그럴듯한데, 사이트를 쭉 돌아보면 페이지를 넘길 때마다 글씨 크기가 미묘하게 출렁였다. 사용자는 그 출렁임을 명확히 의식하진 못해도 ‘뭔가 정돈이 안 된 느낌’을 받는다. 토큰이 있었다면 모든 담당자가 ‘본문’이라는 같은 이름표를 가져다 썼을 테니, 애초에 출렁일 일이 없었다. 이게 토큰의 힘이다.

【본론 2 — 타이포 위계 점검, 어떻게 시작하나】

■ 점검 전 마음가짐과 준비

본격적으로 항목을 보기 전에, 점검을 ‘제대로’ 하기 위한 준비를 짚자. 첫째, ‘만든 사람’이 아니라 ‘쓰는 사람’의 눈으로 봐야 한다. 우리는 우리 사이트를 너무 잘 안다. 어느 글이 제목이고 어느 게 본문인지, 그 의도를 다 알고 있다. 그래서 ‘이 정도면 구분되겠지’ 하고 넘긴다. 하지만 처음 온 사용자는 우리의 의도를 모른다. 화면에 보이는 글자 크기와 굵기, 그것만으로 판단한다. 그러니 점검할 땐 ‘내가 의도한 위계’가 아니라 ‘화면에 실제로 드러난 위계’를 봐야 한다.

둘째, 한 페이지만 보지 말고 여러 페이지를 나란히 띄워라. 위계의 균열은 ‘페이지를 넘나들 때’ 가장 잘 드러난다. 메인의 제목 크기와 안내 페이지의 제목 크기가 다른지, 목록 페이지의 본문과 상세 페이지의 본문이 다른지는 한 화면만 봐서는 안 보인다. 메인·목록·상세·신청 페이지를 동시에 띄워놓고 눈을 옮겨가며 비교해야 ‘아, 제목인데 페이지마다 크기가 다르네’가 눈에 들어온다. 모니터가 넓다면 창을 두세 개 나란히 띄워두고, 좁다면 탭을 빠르게 넘겨가며 봐도 된다. 핵심은 ‘같은 종류의 글자(제목은 제목끼리, 본문은 본문끼리)를 페이지를 넘나들며 비교하는 것’이다. 한 화면 안에서만 보면 ‘이 정도면 괜찮은데’ 싶던 것도, 여러 화면을 겹쳐 보면 ‘아, 제각각이구나’가 한눈에 들어온다.

셋째, ‘예/아니오’가 애매하면 ‘아니오’로 적어라. 점검의 목적은 좋은 점수가 아니라 고칠 곳을 찾는 것이다. 후하게 채점하면 정작 손봐야 할 곳을 놓친다. 의심스러우면 사용자 편에 서서 더 엄격하게 보는 게 결국 모두에게 이득이다.

넷째, 점검은 ‘여러 페이지’를 보되 ‘대표 페이지’부터 보라. 사이트의 모든 페이지를 다 볼 수는 없으니, 사용자가 가장 많이 들르는 페이지부터 점검하는 게 효율적이다. 메인 페이지, 자주 찾는 안내 페이지, 핵심 신청 페이지 — 이 ‘대표 선수’ 몇 개의 위계가 또렷하면 사용자 대다수가 좋은 경험을 한다. 깊숙이 숨은 페이지의 위계까지 완벽할 필요는 없다(물론 좋으면 좋다). 한정된 시간에 가장 큰 효과를 내려면, 트래픽이 몰리는 페이지에 점검의 무게를 싣는 게 맞다.

오늘 체크리스트는 다섯 묶음으로 구성했다. A는 ‘위계가 존재하는가’, B는 ‘본문이 읽히는가’, C는 ‘강조가 의미를 갖는가’, D는 ‘기기를 가리지 않는가’, E는 ‘토큰으로 유지되는가’다. 위에서 아래로 ‘큰 뼈대 → 세부 → 유지 관리’ 순서로 짜여 있으니, 순서대로 진행하길 권한다. 마음 가는 대로 건너뛰면 분명 어떤 영역은 통째로 빼먹게 된다. 특히 마지막 E(토큰·운영)는 눈에 잘 안 띄어 자꾸 뒤로 밀리는데, 사실 사이트의 ‘앞으로’를 결정하는 가장 중요한 영역이다.

각 항목을 점검할 때는 ‘예/아니오’ 옆에 ‘체감 정도’를 한 단계 더 적어두면 좋다. 같은 ‘아니오’여도 ‘좀 아쉬운 수준’과 ‘사용자가 분명히 막힐 수준’은 다르기 때문이다. 별 하나(가벼운 아쉬움), 별 둘(개선 필요), 별 셋(시급)처럼 간단한 표시를 붙여두면, 나중에 우선순위를 정할 때 훨씬 수월하다. 점검은 ‘예/아니오’만 가르는 데서 끝나지 않고, ‘얼마나 심한가’까지 가늠해야 비로소 실행으로 이어진다.

■ A. 위계의 존재 — 제목과 본문이 구분되는가

A-1. 한 페이지 안에서 제목·소제목·본문이 ‘크기만 봐도’ 구분되는가?

→ 자주 보이는 문제: 제목과 본문 크기 차이가 너무 작아, 어디까지가 제목이고 어디부터가 본문인지 흐릿하다. 색만 살짝 다를 뿐 크기는 거의 같은 경우가 흔하다.

A-2. 제목의 단계(대제목·중제목·소제목)가 일관된 규칙을 따르는가?

→ 자주 보이는 문제: 같은 ‘소제목’인데 어떤 곳은 크고 어떤 곳은 작다. 글을 올린 담당자마다 임의로 크기를 정한 흔적이다.

A-3. 제목 위아래에 충분한 여백이 있어, 새로운 묶음의 시작임이 보이는가?

→ 자주 보이는 문제: 제목이 바로 위 문단에 들러붙어, 앞 이야기의 마지막 줄인지 새 묶음의 제목인지 헷갈린다.

이 세 항목에서 ‘아니오’가 나오면, 사이트의 ‘읽는 순서’ 자체가 설계되지 않았다는 뜻이다. A 영역을 점검하는 가장 쉬운 방법은 ‘눈을 가늘게 뜨고 화면을 보는 것’이다. 농담 같지만 진짜 효과가 있다. 눈을 가늘게 뜨면 글자 내용은 안 읽히고 ‘덩어리’만 보인다. 그 흐릿한 상태에서도 ‘여기가 제목이구나, 여기가 본문이구나’가 구분되면 위계가 잡힌 거다. 다 비슷한 회색 덩어리로만 보이면 위계가 없는 거다. 사용자가 화면을 처음 훑을 때 보는 게 딱 그 흐릿한 덩어리 단계이기 때문에, 이 방법은 의외로 정확하다.

위계가 없는 사이트의 근본 원인은 거의 항상 같다. ‘제목 스타일’과 ‘본문 스타일’이 따로 정의돼 있지 않고, 글을 올리는 사람이 그때그때 글씨를 키우고 굵게 만들어 ‘제목처럼’ 보이게 흉내 낸 것이다. 이렇게 ‘흉내 낸 제목’은 페이지마다, 담당자마다 다르게 나온다. 누구는 18로, 누구는 20으로, 누구는 그냥 굵게만. 그래서 사이트 전체로 모아 놓으면 제목의 크기가 제각각이 된다. 해법은 ‘제목은 이 스타일, 본문은 이 스타일’을 미리 정해두고, 글을 올릴 때 크기를 직접 정하는 게 아니라 ‘정해진 스타일을 고르게’ 하는 것이다. 그게 바로 토큰의 역할이고, E 영역에서 다시 다룬다.

A-2 항목을 점검할 땐 ‘제목의 단계가 몇 개인지’도 함께 세어보길 권한다. 좋은 위계는 제목 단계가 보통 세 단계 정도(대제목·중제목·소제목)로 정리돼 있다. 그런데 어떤 사이트는 제목 단계가 대여섯 개로 너무 많아, 각 단계의 크기 차이가 너무 미세해진다. 이렇게 되면 ‘이게 중제목인가 소제목인가’가 사용자에게 구분이 안 된다. 단계가 너무 적어도(제목과 본문 딱 둘뿐) 긴 글을 구조화하기 어렵고, 너무 많아도 혼란스럽다. 우리 사이트의 제목이 몇 단계로 쓰이는지, 그리고 각 단계가 또렷이 구분되는지를 세어보는 것만으로도 A-2의 절반은 점검된다.

A-3, 여백 항목은 가장 무시되기 쉽지만 효과가 즉각적인 항목이다. 제목 위에 충분한 빈 공간이 없으면, 그 제목은 ‘앞 문단의 마지막 줄’처럼 보인다. 반대로 제목과 그 아래 본문 사이의 간격이 제목 위 간격보다 좁아야, 제목이 ‘아래 내용에 속한다’는 묶임이 생긴다. 즉 제목 ‘위쪽 여백 > 아래쪽 여백’이라는 단순한 규칙 하나만 지켜도, 글의 구조가 눈에 확 들어온다. 우리 사이트의 제목들을 보며 ‘이 제목이 위 문단에 붙어 보이나, 아래 내용을 거느려 보이나’를 따져보라. 위에 붙어 보인다면 여백 규칙이 거꾸로 돼 있을 가능성이 높다.

■ B. 본문 가독성 — 읽기 편한 크기와 줄간격인가

B-1. 본문 글씨가 ‘작아서 눈을 찌푸리게’ 만들지 않는가?

→ 자주 보이는 문제: 한 화면에 많은 정보를 욱여넣으려다 본문을 너무 작게 만든다. 정보 밀도는 높아 보이지만 아무도 안 읽는다.

B-2. 줄간격이 너무 좁아 글줄이 들러붙어 있지 않은가?

→ 자주 보이는 문제: 줄과 줄이 답답하게 붙어 있어, 한 줄을 읽고 다음 줄로 눈을 옮길 때 자꾸 같은 줄을 다시 읽거나 한 줄을 건너뛴다.

B-3. 한 줄의 길이가 적당한가? (너무 길어 눈이 끝까지 못 따라가거나, 너무 짧아 토막 나지 않게)

→ 자주 보이는 문제: 넓은 화면에서 본문이 끝에서 끝까지 꽉 차, 한 줄이 너무 길어 다음 줄 첫 글자를 찾기 힘들다.

본문은 사이트에서 ‘가장 많이, 가장 오래’ 읽히는 글자다. 그래서 본문의 가독성은 위계의 화려함보다 훨씬 중요할 때가 많다. 제목이 아무리 멋져도 본문이 안 읽히면 사이트의 본분을 못 하는 거다. B 영역을 점검하는 가장 정직한 방법은 ‘긴 안내문 한 페이지를 처음부터 끝까지 실제로 읽어보는 것’이다. 훑지 말고, 진짜 사용자처럼 한 글자씩. 중간에 눈이 피로해지거나, 어디까지 읽었는지 자꾸 놓치거나, 한 줄을 두 번 읽게 되면 — 그게 가독성 문제의 신호다.

특히 줄간격은 의외로 많이 놓치는 항목이다. 글씨 크기는 신경 써도 줄간격은 기본값 그대로 두는 경우가 많은데, 한글은 받침이 있어 영문보다 줄간격을 넉넉히 줘야 편하게 읽힌다. 줄간격이 좁으면 윗줄의 받침과 아랫줄의 글자가 시각적으로 엉켜, 읽는 사람이 자기도 모르게 피로해진다. 좋은 본문은 글줄 사이에 ‘숨 쉴 공간’이 있다. 그 공간이 한 줄을 다 읽고 다음 줄로 눈을 안전하게 옮기는 길을 만들어준다.

B-3, 한 줄의 길이도 가독성의 숨은 변수다. 사람의 눈은 한 줄을 다 읽은 뒤 다음 줄의 첫 글자를 찾아 시선을 되돌리는데, 한 줄이 너무 길면 그 ‘되돌아오기’가 힘들어진다. 줄 끝까지 갔다가 다음 줄 첫머리를 못 찾고 헤매거나, 같은 줄을 또 읽게 된다. 넓은 데스크탑 화면에서 본문이 화면 끝에서 끝까지 꽉 차게 흐르면 이 문제가 생긴다. 그래서 본문 영역은 일정 폭 이상 넓어지지 않게 ‘읽기 좋은 너비’로 제한하는 게 좋다. 반대로 모바일에선 한 줄이 너무 짧아 단어가 토막토막 끊기는 문제가 생기니, 기기마다 적정 너비가 다르다는 점을 염두에 두자.

B 영역에서 또 하나 봐야 할 건 ‘글자와 배경의 대비’다. 본문 글씨가 충분히 진한 색이어서 배경과 또렷이 구분되는지, 아니면 연한 회색이라 흐릿하게 묻히는지를 본다. 요즘 ‘세련돼 보이려고’ 본문을 연한 회색으로 두는 사이트가 많은데, 이건 가독성을 크게 해친다. 특히 햇빛 아래 모바일 화면이나, 시력이 약한 사용자에겐 연한 회색 본문이 거의 안 보인다. 멋보다 읽힘이 우선이다. 본문은 ‘충분히 진한 색’이 정답이고, 연한 색은 부가 설명 같은 ‘덜 중요한 정보’에만 아껴 써야 한다. 이 대비 역시 행정안전부 품질관리 지침의 접근성 영역에서 명시적으로 다루는 항목이다.

■ C. 강조의 절제 — 강조가 의미를 갖는가

C-1. 강조(굵게·색)가 ‘정말 중요한 것’에만 쓰이는가?

→ 자주 보이는 문제: 너무 많은 곳에 굵게·빨강·밑줄이 붙어 있어, 강조가 강조의 기능을 잃었다. 다 강조하면 아무것도 강조 안 한 것과 같다.

C-2. 색만으로 정보를 구분하지 않는가? (예: 빨간 글씨로만 ‘필수’를 표시)

→ 자주 보이는 문제: 색각 이상이 있는 사용자나 흑백 출력 시 ‘빨간 글씨’가 그냥 검은 글씨로 보여, 무엇이 필수인지 구분이 안 된다.

C-3. 같은 종류의 강조가 사이트 전체에서 같은 의미로 쓰이는가?

→ 자주 보이는 문제: 어떤 페이지에선 빨강이 ‘경고’인데, 다른 페이지에선 빨강이 그냥 ‘제목 색’이라 사용자가 색의 의미를 신뢰하지 못한다.

강조는 양념과 같다. 적당히 치면 음식이 살지만, 너무 많이 치면 다 짜서 못 먹는다. 공공 사이트에서 유독 강조가 남발되는 이유는, 모든 부서가 ‘우리 안내가 제일 중요하다’고 여겨 저마다 자기 글에 강조를 듬뿍 넣기 때문이다. 그렇게 모인 페이지는 온통 굵은 글씨와 빨간 글씨로 뒤덮여, 정작 진짜 중요한 마감일은 그 속에 묻혀버린다. C 영역의 점검 요령은 ‘이 페이지에서 강조된 것들만 뽑아 봤을 때, 그게 정말 가장 중요한 것들인가’를 따져보는 것이다. 강조된 것만 읽어도 핵심이 전달되면 좋은 강조고, 강조가 너무 많아 ‘그래서 뭐가 제일 중요한데?’ 싶으면 강조를 줄여야 한다.

강조 남발이 생기는 또 다른 이유는 ‘강조를 더하기만 하고 빼지는 않기’ 때문이다. 페이지를 만들 땐 ‘이것도 중요하니 굵게, 저것도 중요하니 빨강’ 하며 강조를 계속 더한다. 하지만 그렇게 더한 뒤에 ‘이 중에서 정말 강조가 필요한 건 몇 개일까’를 다시 빼는 과정은 거의 거치지 않는다. 좋은 강조는 ‘더하기’가 아니라 ‘빼기’에서 완성된다. 한 페이지에서 진짜 강조가 필요한 건 보통 한두 개다. 그 한두 개에만 강조를 남기고 나머지는 평범한 본문으로 되돌리면, 남은 강조가 비로소 또렷이 빛난다. C 영역을 점검할 때, 강조가 너무 많다 싶으면 ‘이 중 딱 하나만 남긴다면 무엇을 남길까’를 자문해보라. 그 하나가 진짜 강조해야 할 것이고, 나머지는 욕심이었을 가능성이 높다.

C-2는 접근성과 직결되는 중요한 항목이다. 색만으로 정보를 전달하면, 색을 구분하기 어려운 사용자에겐 그 정보가 통째로 사라진다. ‘필수 항목은 빨강’이라는 규칙은, 빨강을 인식 못 하는 사람에겐 아무 규칙도 아니다. 그래서 색으로 강조할 땐 반드시 ‘색 말고 다른 단서’를 함께 줘야 한다. 별표(*)를 붙이거나, ‘필수’라는 글자를 적거나, 굵게 처리하거나. 색은 ‘덤’이어야지 ‘유일한 단서’여서는 안 된다. 이건 행정안전부의 웹 품질관리 지침 중 접근성 영역, 그리고 웹접근성 KWCAG 33항목에서도 핵심으로 다루는 원칙이다.

C-2를 직접 점검하는 아주 간단한 방법이 있다. 화면을 ‘흑백으로’ 상상하거나, 실제로 페이지를 흑백으로 출력해보는 것이다. 색이 사라진 흑백 화면에서도 ‘무엇이 필수이고 무엇이 경고인지’가 구분되면 통과다. 흑백으로 바꾸는 순간 모든 게 똑같은 검은 글씨로 보여 ‘뭐가 뭔지 모르겠다’ 싶으면, 그 페이지는 색에만 의존하고 있는 거다. 색각 이상이 있는 사용자가 보는 화면이 딱 그 흑백에 가깝다는 점을 떠올리면, 이 점검이 왜 중요한지 실감이 난다. 우리 눈엔 빨강과 검정이 또렷이 다르지만, 적록색약이 있는 사용자에겐 그 둘이 거의 같은 색으로 보인다.

C-3, 강조의 ‘의미 일관성’도 놓치기 쉬운 항목이다. 사용자는 사이트를 쓰면서 무의식중에 ‘이 사이트에서 빨강은 경고를 뜻하는구나’ 같은 규칙을 학습한다. 그런데 어떤 페이지에선 빨강이 경고인데 다른 페이지에선 빨강이 그냥 제목 색이면, 그 학습된 규칙이 무너진다. 사용자는 ‘빨강’을 봐도 그게 경고인지 단순 장식인지 신뢰하지 못하게 된다. 그러면 정작 진짜 경고를 빨강으로 띄워도 무시당한다. ‘양치기 소년’과 같은 이치다. 강조의 의미는 사이트 전체에서 한결같이 지켜질 때만 힘을 갖는다. C-3을 점검할 땐 ‘우리 사이트에서 빨강·굵게·밑줄이 각각 어떤 의미로 쓰이는지’를 적어보고, 그 의미가 페이지마다 흔들리지 않는지 확인하라.

■ D. 반응형 위계 — 기기를 가리지 않는가

D-1. 모바일에서 제목이 화면 폭에 맞게 적당히 줄어드는가? (잘리거나 너무 작아지지 않게)

→ 자주 보이는 문제: 데스크탑 기준 큰 제목이 모바일에서 두세 줄로 끊겨 어색하거나, 반대로 너무 작아져 본문과 구분이 안 된다.

D-2. 모바일에서도 제목·본문의 ‘단계’가 유지되는가?

→ 자주 보이는 문제: 데스크탑에선 위계가 멀쩡한데, 모바일에선 모든 글자가 비슷한 크기로 뭉개져 위계가 사라진다.

D-3. 글씨를 키워서 봐도(브라우저 확대) 레이아웃이 깨지지 않고 읽히는가?

→ 자주 보이는 문제: 사용자가 글씨를 키우면 글자가 서로 겹치거나, 버튼 밖으로 글자가 삐져나간다.

요즘 공공 사이트 방문의 절반 이상이 모바일에서 일어난다. 그런데 위계 점검은 데스크탑에서만 하고 끝내는 경우가 많다. 그래서 D 영역이 따로 필요하다. 모바일은 화면이 좁아 글자 크기의 단계 차이가 압축되기 쉽다. 데스크탑에서 제목 32, 본문 16으로 두 배 차이가 났던 게, 모바일에선 제목 22, 본문 16으로 좁혀져 위계가 흐려지곤 한다. 그래서 모바일에서도 ‘제목과 본문이 한눈에 구분되는가’를 따로 확인해야 한다.

D-3은 특히 고령 사용자와 저시력 사용자를 위한 중요한 점검이다. 글씨를 키워서 보는 사용자는 생각보다 많다. 그런데 위계를 ‘딱 그 크기’에만 맞춰 설계하면, 사용자가 글씨를 키우는 순간 모든 게 어긋난다. 좋은 위계는 ‘절대 크기’가 아니라 ‘비율’로 설계돼, 사용자가 글씨를 키워도 제목과 본문의 단계 관계가 그대로 유지된다. D 영역을 점검할 땐 브라우저에서 글씨를 150%, 200%로 키워보고, 그래도 위계와 레이아웃이 살아 있는지 확인하라.

공공 사이트는 특히 D 영역에 민감해야 한다. 공공 서비스는 ‘모두를 위한 서비스’이기 때문이다. 젊고 시력 좋은 사용자만 쓰는 게 아니라, 노안이 온 어르신도, 저시력 사용자도, 작은 화면의 보급형 스마트폰만 가진 사용자도 똑같이 쓴다. 민간 쇼핑몰이라면 ‘주 고객층’에 맞춰 설계할 수 있지만, 공공 사이트는 ‘가장 불리한 조건의 사용자’도 쓸 수 있어야 한다는 책무가 있다. 그래서 D 영역의 ‘아니오’는 단순한 편의 문제가 아니라, ‘일부 국민이 서비스에서 배제되고 있다’는 신호로 봐야 한다. 글씨를 키웠더니 버튼 글자가 잘리고 레이아웃이 무너진다면, 그건 시력이 약한 국민에게 ‘당신은 이 서비스를 제대로 쓸 수 없다’고 말하는 것과 다름없다.

D 영역을 점검할 땐 한 가지 요령이 있다. ‘진짜 스마트폰으로’ 봐야 한다는 것이다. 데스크탑 브라우저의 창 크기를 줄여서 ‘모바일처럼’ 보는 건 참고는 되지만 완전하진 않다. 실제 스마트폰은 화면도 작고, 손가락으로 만지고, 야외에서 햇빛 아래 보기도 한다. 그 실제 환경에서 봐야 ‘제목이 두 줄로 끊기는’ 문제나 ‘본문이 너무 작아 눈을 찌푸리게 되는’ 문제가 진짜로 보인다. 가능하면 최신 기종 말고 ‘보급형 구형 스마트폰’으로도 한번 봐보길 권한다. 우리 사이트를 쓰는 사용자 모두가 최신 폰을 가진 건 아니기 때문이다.

■ E. 토큰과 유지 — 위계가 ‘앞으로도’ 지켜지는가

E-1. 제목·본문·설명 스타일이 ‘이름표(스타일/토큰)’로 정의돼 있는가?

→ 자주 보이는 문제: 정의된 스타일이 없어, 글을 올릴 때마다 담당자가 크기를 직접 정한다. 그래서 페이지마다 위계가 다르다.

E-2. 새 페이지를 만들 때, 그 정해진 스타일을 ‘골라서’ 쓰도록 돼 있는가?

→ 자주 보이는 문제: 스타일은 정의돼 있는데 강제력이 없어, 외주나 담당자가 무시하고 또 눈대중으로 만든다.

E-3. 색·크기 값을 코드에 직접 박지 않고, 정해진 토큰을 참조하는가?

→ 자주 보이는 문제: 같은 ‘본문 색’인데 페이지마다 미묘하게 다른 회색 값이 직접 박혀 있어, 나중에 한꺼번에 바꿀 수가 없다.

E 영역은 ‘오늘의 위계’가 아니라 ‘내일의 위계’를 지키는 영역이다. A~D에서 아무리 위계를 잘 잡아놔도, 그걸 유지하는 장치가 없으면 반년 뒤 새 페이지들이 다시 제각각이 된다. 사이트는 살아 있는 생물 같아서, 콘텐츠가 추가되고 페이지가 늘어나며 계속 변한다. 오늘 ‘예’였던 위계가 새 담당자가 올린 글 때문에 다시 ‘아니오’가 되는 건 순식간이다.

그 유지의 핵심이 디자인 토큰이다. 토큰은 ‘제목용 큰 글자’, ‘본문용 보통 글자’, ‘설명용 작은 글자’ 같은 단계를 이름표로 정의해두고, 모든 페이지가 그 이름표를 가져다 쓰게 만드는 약속이다. 이렇게 하면 두 가지가 해결된다. 첫째, 글을 올리는 사람이 크기를 ‘직접 정하지’ 않고 ‘골라서’ 쓰니 페이지마다 달라질 일이 없다. 둘째, 나중에 ‘본문을 한 단계 키우자’ 같은 결정을 내렸을 때, 이름표 하나만 고치면 그 이름표를 쓰는 모든 페이지가 한꺼번에 바뀐다. 토큰은 위계를 ‘한 번 잡고 끝’이 아니라 ‘계속 유지되는 시스템’으로 만든다.

KRDS가 글자의 크기·굵기·줄간격·색을 토큰으로 정리해 둔 이유가 바로 이것이다. 각 기관이 매번 ‘우리 본문은 몇으로 할까’를 고민하는 대신, 이미 검증된 단계 체계를 가져다 쓰면 위계 설계의 가장 어려운 절반이 해결된다. E-3은 그중에서도 가장 기술적인 항목인데, 색이나 크기 값을 코드 곳곳에 직접 박아두면 ‘같은 본문 색’이 페이지마다 미묘하게 어긋나기 쉽다. 토큰을 참조하면 그 균열이 원천적으로 막힌다. 담당자가 이 항목을 직접 확인하긴 어려우니, 개발 담당이나 외주에게 ‘색·글자 크기를 토큰으로 관리하고 있느냐’고 물어보는 것으로 갈음하면 된다.

E-2, ‘강제력’ 항목을 조금 더 풀어보자. 토큰이나 스타일이 정의돼 있는데도 위계가 무너지는 경우가 의외로 많다. 정의는 해놨지만 ‘쓰지 않아도 막지 않는’ 구조이기 때문이다. 외주 업체가 납품 일정에 쫓겨 ‘일단 보기에 맞게’ 값을 직접 박아 넣어도 아무도 제지하지 않으면, 토큰은 장식품이 된다. 그래서 좋은 운영은 토큰을 ‘권장’이 아니라 ‘기본’으로 만든다. 새 페이지를 만들 때 토큰을 쓰는 게 가장 쉬운 길이 되도록, 토큰을 안 쓰는 게 오히려 번거롭도록 환경을 짜는 것이다. 사람의 의지에 기대면 언젠가 무너진다. 구조로 막아야 오래간다. E-2를 점검할 땐 ‘우리는 새 페이지를 만들 때 정해진 스타일을 안 쓰면 안 되게 돼 있나, 아니면 안 써도 그만인가’를 개발·외주 담당에게 물어보라.

E 영역은 담당자 혼자 완결할 수 없는 영역이라는 점도 솔직히 말해두자. A~D는 콘텐츠 담당자가 눈으로 점검하고 어느 정도 직접 고칠 수 있지만, E는 사이트의 ‘구조’에 관한 문제라 개발자나 외주의 손이 필요하다. 그래서 E 영역의 ‘아니오’는 ‘내가 당장 고칠 것’이 아니라 ‘개선 회의 안건으로 올릴 것’으로 분류하면 된다. 다만 담당자가 E의 의미를 이해하고 있으면, 외주에게 사이트를 맡길 때 ‘토큰 기반으로 만들어달라’, ‘색·글자 값을 직접 박지 말아달라’는 요구를 계약 단계에서부터 명확히 할 수 있다. 그 한마디 요구가 몇 년 뒤 사이트의 위계 건강을 좌우한다. E를 아는 담당자와 모르는 담당자가 발주한 사이트는, 3년 뒤 전혀 다른 모습이 된다.

【본론 3 — 점검 결과를 어떻게 활용하나】

■ ‘아니오’ 목록을 우선순위로 정리하기

다섯 묶음을 다 돌고 나면 ‘아니오’가 적힌 목록이 손에 남는다. 이제 이걸 ‘무엇부터 고칠까’의 순서로 정리할 차례다. 모든 ‘아니오’가 똑같이 급한 건 아니다. 우선순위를 정하는 기준은 두 가지다. ‘얼마나 많은 사용자가 영향을 받나’와 ‘고치는 데 얼마나 드나’다.

가장 먼저 손봐야 할 건 ‘많은 사용자에게 영향을 주면서, 고치기는 비교적 쉬운’ 항목이다. 예를 들어 본문 줄간격이 너무 좁은 문제(B-2)는 사이트 전체에 영향을 주지만, 토큰으로 관리되고 있다면 값 하나만 바꾸면 모든 페이지가 한꺼번에 개선된다. 이런 ‘적은 노력으로 큰 효과’를 내는 항목부터 처리하면, 빠르게 눈에 보이는 개선을 만들 수 있고 그게 다음 작업의 동력이 된다.

반대로 ‘색만으로 정보를 구분하는 문제’(C-2)처럼 사용자 일부에게만 영향을 주는 것 같아 보이는 항목도, 사실은 우선순위를 높여야 한다. 영향받는 사용자 수는 적어 보여도, 그들에겐 정보가 ‘통째로 사라지는’ 치명적인 문제이기 때문이다. 접근성 관련 ‘아니오’는 ‘소수의 문제’가 아니라 ‘공공 서비스의 기본 책무’라는 관점에서 봐야 한다.

우선순위를 정할 때 흔히 빠지는 실수가 ‘눈에 띄는 것부터 고치려는’ 것이다. 제목 색이 마음에 안 든다든지, 폰트가 좀 촌스러워 보인다든지 하는 ‘취향의 문제’에 먼저 손이 간다. 하지만 그런 건 대개 영향이 작다. 정작 사용자를 괴롭히는 건 ‘본문이 너무 작다’, ‘마감일이 묻혀 있다’ 같은 ‘기능의 문제’다. 취향은 나중에 고쳐도 되지만, 기능은 지금 고쳐야 한다. 그래서 우선순위 회의에서는 ‘이게 보기 싫은 문제인가, 사용자가 정보를 놓치는 문제인가’를 구분하는 게 핵심이다. 보기 싫은 건 미뤄도 되고, 정보를 놓치게 만드는 건 미루면 안 된다.

또 하나의 현실적 기준은 ‘토큰으로 관리되느냐’다. 토큰으로 관리되는 항목(본문 크기, 줄간격, 본문 색 등)은 값 하나만 바꾸면 사이트 전체가 한꺼번에 개선되니, 비용 대비 효과가 압도적으로 크다. 반면 페이지마다 값이 직접 박혀 있는 항목은 일일이 손봐야 하니 시간이 많이 든다. 그래서 ‘토큰으로 관리되는 영역의 아니오’를 먼저 처리하면, 적은 노력으로 가장 넓은 개선을 만들 수 있다. 만약 우리 사이트가 토큰을 거의 안 쓰는 상태라면, ‘개별 페이지를 다 고치기’보다 ‘앞으로 만드는 것부터 토큰을 쓰게 하기’를 1순위 안건으로 올리는 게 현실적이다. 과거를 다 고치는 건 끝이 없지만, 미래를 바꾸는 건 한 번의 결정으로 가능하기 때문이다.

■ ‘아니오’ 옆에 한 줄 메모를 남겨라

점검하면서 ‘아니오’만 체크하지 말고, 그 옆에 한 줄짜리 메모를 남기길 강력히 권한다. 이를테면 ‘A-1 아니오 — 안내 페이지에서 제목과 본문 크기 차이가 거의 없음’처럼. 이 한 줄이 나중에 개선 작업을 지시할 때 정확한 작업 명세서가 된다. 점검만 하고 무엇이 문제였는지 적어두지 않으면, 며칠만 지나도 ‘분명 아니오가 많았는데 뭐였더라’가 된다. 점검의 가치는 ‘발견’이 아니라 ‘기록’에서 완성된다.

그리고 이 메모는 ‘대화의 출발점’이 된다. 사이트 개선은 혼자 하는 일이 아니다. 디자인 담당, 개발 담당, 윗선, 외주 업체가 함께 움직여야 한다. 그런데 ‘우리 사이트 글씨가 좀 별로인 것 같아요’라는 막연한 말로는 누구도 움직이지 않는다. 반면 ‘자가 점검을 해봤더니 14개 항목 중 위계와 강조 영역에서 아니오가 6개 나왔고, 특히 제목 크기가 페이지마다 제각각입니다’라고 하면 이야기가 구체적인 안건이 된다. 손에 쥔 점검 결과 하나가, 미뤄지던 개선 논의를 시작하게 만드는 방아쇠가 된다.

■ 자가 점검의 한계, 그리고 정밀 진단

오늘 체크리스트는 ‘사람의 눈으로 빠르게 훑는’ 점검이다. 솔직히 말하면, 이걸로 KRDS 846개 규칙을 다 따질 수는 없다. 846규칙은 디자인 시스템(DS 120개), 컴포넌트(CP 446개), 기본 패턴(BP 108개), 서비스 패턴(SP 172개)으로 나뉘는데, 그중 글자와 직접 관련된 것만 추려도 사람이 눈으로 일일이 확인하기엔 너무 많다. 오늘 다룬 건 그중 ‘가장 자주 걸리고 영향이 큰’ 핵심만 추린 것이다.

그래서 자가 점검은 정밀 진단을 ‘대체’하는 게 아니라 ‘선행’하는 단계다. 건강에 빗대면 자가 점검은 ‘요즘 글씨가 좀 안 읽히는데 어디가 문제지’ 하고 스스로 살펴보는 것이고, 정밀 진단은 도구로 모든 항목을 빠짐없이 측정하는 것이다. 자가 점검으로 ‘대충 어디가 안 좋은지’ 감을 잡고, 그다음 정밀 진단으로 ‘정확히 무엇이 몇 개나 어긋났는지’를 확정하는 순서가 가장 효율적이다. 자가 점검 없이 정밀 진단부터 받으면 ‘숫자는 나왔는데 뭘 봐야 할지 모르는’ 상태가 되고, 정밀 진단 없이 자가 점검만 믿으면 ‘눈에 안 보이는 깊은 어긋남’을 놓친다.

자가 점검의 또 다른 한계는 ‘일관성을 사람이 다 추적할 수 없다’는 점이다. 우리가 눈으로 점검할 수 있는 건 기껏해야 몇 개 페이지다. 메인, 목록, 상세, 신청 페이지 정도를 비교하는 게 사람이 할 수 있는 최대치다. 그런데 공공 사이트는 수백, 많게는 수천 페이지에 이른다. 그 모든 페이지의 제목 크기가 일관된지, 본문 색이 같은 값인지를 사람이 일일이 확인하는 건 불가능하다. 우리가 점검한 몇 페이지가 멀쩡해도, 우리가 안 본 깊숙한 페이지에서 위계가 무너져 있을 수 있다. 바로 이 ‘전수 확인’이 자동 도구가 사람을 압도하는 지점이다. 도구는 사이트의 모든 페이지를 빠짐없이 훑어 ‘어디서 위계가 깨졌는지’를 한꺼번에 잡아낸다. 사람의 눈은 ‘감’을 잡는 데 강하고, 도구는 ‘전수’를 훑는 데 강하다. 둘은 경쟁 관계가 아니라 짝꿍이다.

【본론 4 — 토큰 채택률, 위계 건강의 숫자 지표】

■ ‘느낌’을 ‘숫자’로 바꾸는 토큰 채택률

지금까지의 점검은 대부분 ‘느낌’에 기댄다. ‘위계가 흐릿한 것 같다’, ‘본문이 좀 작은 것 같다’ — 이 ‘같다’를 ‘숫자’로 바꿔주는 지표가 하나 있다. 바로 ‘토큰 채택률’이다.

토큰 채택률이란, 사이트의 글자·색·간격이 ‘정해진 토큰을 얼마나 잘 따르고 있는가’를 백분율로 나타낸 값이다. 모든 글자가 정해진 스타일 토큰을 쓰고 있으면 채택률이 높고, 곳곳에 눈대중으로 박은 ‘제멋대로 값’이 많으면 채택률이 낮다. 이 숫자가 의미 있는 이유는, 앞서 본 위계 문제의 ‘근본 원인’을 한 번에 보여주기 때문이다. 위계가 무너지는 건 거의 항상 ‘토큰을 안 쓰고 각자 값을 박았기’ 때문인데, 토큰 채택률은 그 ‘각자 박은 정도’를 그대로 수치화한다.

채택률이 낮다는 건 ‘앞으로도 위계가 계속 무너질 구조’라는 뜻이다. 지금 당장은 어찌어찌 보기 좋게 맞춰놨더라도, 토큰을 안 쓰고 매번 값을 직접 박는 방식이라면 새 페이지가 늘어날 때마다 다시 어긋난다. 반대로 채택률이 높으면, 새 페이지도 자동으로 같은 스타일을 따라가니 위계가 저절로 유지된다. 그래서 토큰 채택률은 ‘오늘의 미관’이 아니라 ‘내일의 일관성’을 예측하는 지표다.

■ 채택률을 사람이 직접 세는 건 불가능하다

문제는, 토큰 채택률을 사람이 손으로 셀 수 없다는 점이다. 사이트의 모든 페이지, 모든 글자 요소가 ‘정해진 토큰을 쓰고 있는지, 아니면 제멋대로 값을 박았는지’를 일일이 확인하는 건 수백 페이지짜리 공공 사이트에선 현실적으로 불가능하다. 그래서 이 지표는 자동 분석 도구의 영역이다. 도구가 사이트의 모든 글자·색·간격 값을 긁어모아, 그게 KRDS의 디자인 토큰과 얼마나 일치하는지를 자동으로 계산해준다.

여기서 ViewCheck 이야기를 잠깐 하겠다. ViewCheck는 공공 사이트를 KRDS 846규칙으로 자동 진단하는 서비스인데, 그 안에 ‘디자인 시스템’ 분석 탭이 있다. 이 탭에서 ‘디자인 토큰 채택률’을 보여준다. 사이트의 색·글자·간격이 KRDS가 정의한 1,000여 개 토큰과 얼마나 일치하는지를 백분율로 환산해 한눈에 보여주는 것이다. 오늘 우리가 자가 점검으로 ‘느낌’으로 확인한 위계의 건강 상태를, 이 숫자가 객관적인 지표로 확정해준다.

이 ViewCheck의 분석은 KRDS 846규칙(DS 120 + CP 446 + BP 108 + SP 172) 전체를 자동으로 돌리는 것의 일부다. 오늘 우리가 자가 점검으로 다룬 ‘타이포 위계’는 그중 디자인 시스템(DS) 영역과 가장 깊이 닿아 있지만, 글자가 들어가는 버튼·입력칸·표 같은 컴포넌트(CP)의 위계까지 함께 보면 사이트의 ‘읽힘’을 더 입체적으로 진단할 수 있다. 사람이 눈으로 다섯 묶음을 훑는 동안, 도구는 846개 항목을 빠짐없이 훑어 ‘우리가 놓친 깊은 페이지’의 어긋남까지 잡아낸다. 앞서 말한 ‘사람은 감, 도구는 전수’라는 짝꿍 관계가 여기서 실제로 작동하는 셈이다. 그러니 오늘의 자가 점검이 끝났다면, 그 결과를 손에 쥔 채 도구의 숫자와 맞춰보는 것을 다음 단계로 삼길 권한다.

■ 채택률을 ‘추세’로 관리하기

토큰 채택률의 진짜 가치는 ‘한 번 재는 것’이 아니라 ‘주기적으로 재며 추세를 보는 것’에 있다. 분기마다 같은 도구로 채택률을 측정하면, 사이트가 좋아지고 있는지 나빠지고 있는지가 한눈에 보인다. 새 페이지를 토큰으로 잘 만들고 있으면 채택률이 서서히 오르고, 외주가 토큰을 무시하고 마구 만들면 채택률이 떨어진다. 이 추세선 하나가 ‘우리 사이트의 디자인 건강이 어디로 가고 있는가’를 말해준다.

이건 보고에도 유용하다. ‘사이트를 개선했습니다’라는 말보다 ‘토큰 채택률이 지난 분기 62%에서 이번 분기 78%로 올랐습니다’라는 숫자가 훨씬 설득력 있다. 위계 같은 디자인 품질은 원래 ‘말로 설명하기 어려운’ 영역인데, 채택률이라는 숫자가 그 어려움을 덜어준다. 디자인을 모르는 윗선에게도, 예산을 쥔 결재권자에게도, 숫자는 통한다.

한 가지 주의할 점도 있다. 토큰 채택률 숫자에만 매달려 ‘무조건 100%’를 목표로 삼는 건 오히려 위험할 수 있다. 채택률은 ‘위계 건강의 한 지표’일 뿐, 그 자체가 목적은 아니다. 채택률이 높아도 애초에 토큰 설계가 잘못돼 있으면 사이트는 여전히 읽기 불편할 수 있다. 반대로 채택률이 조금 낮아도 핵심 페이지의 위계가 또렷하면 사용자 경험은 괜찮을 수 있다. 그러니 숫자는 ‘방향을 알려주는 나침반’으로 쓰되, 최종 판단은 ‘사용자가 실제로 읽기 편한가’라는 본질로 내려야 한다. 좋은 담당자는 숫자를 활용하되 숫자에 끌려다니지 않는다.

■ 점검을 ‘습관’으로 만드는 법

오늘 체크리스트의 진짜 가치는 ‘한 번 하고 끝’이 아니라 ‘정기적으로 반복’할 때 드러난다. 앞서 말했듯 사이트는 살아 있는 생물 같아서, 콘텐츠가 쌓이고 페이지가 늘며 끊임없이 변한다. 그래서 분기에 한 번쯤, 혹은 큰 개편이나 대규모 콘텐츠 추가가 있을 때마다 같은 체크리스트로 다시 점검하는 습관을 들이는 게 좋다.

습관으로 만드는 가장 쉬운 방법은 ‘달력에 못 박는 것’이다. 분기 첫 달 첫째 주에 ‘타이포 위계 점검’이라는 일정을 미리 넣어두자. 그리고 점검할 때마다 결과를 한 장짜리 표로 남겨두면, 분기마다 ‘아니오 개수’가 줄어드는지 늘어나는지 추세가 보인다. 이 추세표 하나가 ‘우리가 정말 나아지고 있는가’를 정직하게 비춰주는 거울이 된다. 개선했다고 믿었는데 아니오가 오히려 늘었다면, 어디선가 새 페이지들이 위계를 깨고 있다는 신호다.

또 하나, 점검을 ‘혼자만의 일’로 두지 말자. 가능하면 콘텐츠를 올리는 동료 몇 명과 함께 점검 기준을 공유하면 좋다. 모두가 ‘제목은 정해진 스타일로, 본문은 정해진 스타일로’라는 감각을 갖추면, 애초에 위계가 깨질 일이 줄어든다. 점검은 ‘이미 망가진 걸 찾는 일’이지만, 그 기준을 공유하는 건 ‘망가지지 않게 예방하는 일’이다. 사후 점검과 사전 예방이 함께 굴러갈 때 사이트의 위계는 비로소 안정된다.

이쯤에서 한 번 정리하자. 자가 점검(A~E)으로 ‘느낌’을 잡고, 토큰 채택률로 그 느낌을 ‘숫자’로 확정하고, 정기 반복으로 그 숫자의 ‘추세’를 관리한다. 이 세 단계가 맞물리면, 위계 관리는 ‘가끔 생각나면 하는 일’에서 ‘체계적으로 굴러가는 일’로 바뀐다. 거창한 도구나 큰 예산이 없어도, 이 흐름 하나만 자리 잡으면 사이트는 분기마다 조금씩 또렷해진다.

【 마무리 】

오늘은 ‘타이포 위계 점검 체크리스트’를 다섯 묶음으로 정리했다. A는 위계가 존재하는가, B는 본문이 읽히는가, C는 강조가 의미를 갖는가, D는 기기를 가리지 않는가, E는 토큰으로 유지되는가. 이 다섯을 순서대로 짚으면, 우리 사이트의 글자가 ‘읽는 사람의 길잡이’ 역할을 제대로 하고 있는지 한 바퀴 빠짐없이 점검하게 된다.

다시 한번 강조하자. 이건 시험이 아니라 건강검진이다. ‘아니오’가 많이 나왔다면 부끄러워할 일이 아니라 다행으로 여길 일이다. 문제를 많이 찾았다는 건 사이트가 좋아질 여지를 그만큼 확보했다는 뜻이니까. 그리고 그 ‘아니오’ 옆에 남긴 한 줄 메모가, 막연하던 개선 논의를 구체적인 작업으로 바꿔주는 방아쇠가 된다.

타이포 위계는 화려한 디자인의 영역이 아니다. ‘읽어야 하는 글을 읽히게 만드는’ 가장 기본적인 예의의 영역이다. 공공 사이트의 글은 누군가의 신청을, 누군가의 권리를, 누군가의 안전을 좌우한다. 그 결정적인 정보가 사소한 각주처럼 묻히지 않고 또렷이 드러나게 하는 것 — 그게 위계 설계의 본질이고, 공공 서비스가 사용자에게 갖춰야 할 최소한의 배려다.

오늘 자가 점검으로 ‘느낌’을 잡았다면, 그다음은 ‘숫자’로 확인할 차례다. 우리 사이트의 타이포 토큰 채택률이 실제로 몇 퍼센트인지, 846규칙 중 글자 관련 항목에서 무엇이 어긋나 있는지가 궁금하다면, krds.viewcheck.co.kr 에서 우리 기관 사이트 주소만 넣어 무료로 진단을 체험해볼 수 있다. 오늘 손으로 짚은 다섯 묶음의 결과가, 디자인 시스템 탭의 ‘토큰 채택률’ 숫자로 어떻게 확정되는지 직접 확인해보길 권한다. 자가 점검의 ‘느낌’과 도구의 ‘숫자’가 만나는 그 지점에서, 진짜 개선이 시작된다.

마지막으로, 오늘 다룬 다섯 묶음을 한 문장씩으로 다시 새겨두자. A — 제목과 본문이 한눈에 구분되는가. B — 본문이 충분히 크고 줄간격이 넉넉해 편히 읽히는가. C — 강조가 정말 중요한 것에만, 색 아닌 단서와 함께 쓰이는가. D — 모바일과 확대 화면에서도 위계가 살아 있는가. E — 이 모든 게 토큰으로 정의돼 앞으로도 유지되는가. 이 다섯 문장만 기억해도, 우리 사이트의 글자가 어디서 새고 있는지 절반은 짚을 수 있다.

그리고 잊지 말자. 오늘 ‘아니오’가 나온 항목은 ‘우리 사이트가 못났다’는 증거가 아니라 ‘여기를 고치면 더 좋아진다’는 지도다. 모든 공공 사이트가 같은 길을 지나왔다. 처음부터 완벽한 위계를 갖춘 사이트는 없다. 다만 ‘문제를 알아보는 눈’을 가진 담당자가 있는 사이트는, 시간이 지날수록 또렷해진다. 오늘 이 글을 끝까지 읽은 당신이 바로 그 눈을 갖춘 담당자다. 그 눈 하나가, 매일 그 사이트를 쓰는 수많은 사용자의 하루를 조금씩 편하게 만든다.

다음 주에는 또 다른 주제로 찾아온다. 오늘 체크리스트는 출력해두고, 분기에 한 번씩 같은 항목으로 다시 점검해보길 바란다. 그 반복이 쌓이면, 우리 사이트의 글자는 어느새 ‘읽기 싫은 화면’에서 ‘읽기 편한 안내자’로 바뀌어 있을 것이다. 오늘의 점검이 그 긴 여정의 첫 기준점이 되길.

키워드/태그: #KRDS #공공웹 #타이포그래피 #Pretendard #디자인토큰 #디자인시스템 #웹접근성 #KWCAG #전자정부 #UIUX #토큰채택률 #ViewCheck

ViewCheck — KRDS 자동 준수 검증 서비스
krds.viewcheck.co.kr