공공 표준 서체 Pretendard GOV 적용 가이드

공공 사이트를 하루에도 몇 개씩 드나들다 보면, 어느 순간 "글씨가 다 비슷하게 생겼네"라는 느낌을 받을 때가 있습니다. 예전엔 사이트마다 글꼴이 제각각이라 어떤 곳은 둥글둥글하고, 어떤 곳은 딱딱하고, 또 어떤 곳은 본문이 흐릿해서 눈이 아팠는데, 요즘 들어 정부·지자체 사이트들의 글자 인상이 점점 한 식구처럼 닮아 갑니다. 그 닮음의 정체가 바로 오늘 다룰 주인공, 공공 표준 서체 Pretendard GOV입니다.

그런데 솔직히 말하면, 서체는 "가장 중요한데 가장 점검 안 하는" 영역입니다. 버튼이 안 눌리거나 폼이 제출 안 되면 누구나 바로 알아챕니다. 하지만 본문 글꼴이 표준에서 살짝 벗어나 있거나, 같은 사이트인데 페이지마다 글자 두께가 들쭉날쭉하거나, 모바일에서 글씨가 13px로 깨알같이 작아져 있어도 — 마우스 쓰는 비장애인 담당자 눈엔 "별문제 없어 보이는" 경우가 많거든요. 그래서 서체는 조용히 망가지고, 조용히 방치됩니다.

이 글의 각도는 "기준 설명"이 아니라 "자가진단"입니다. 물론 KRDS가 Pretendard GOV에 대해 무엇을 요구하는지부터 짚겠지만, 진짜 목적은 다른 데 있습니다. "그래서 우리 사이트의 서체는 지금 표준을 지키고 있나? 그걸 어떻게 5분 안에 확인하나?" 이 질문에 답하는 게 핵심입니다. 다 읽고 나면, 디자이너든 개발자든 기획자든 자기 자리에서 바로 돌려 볼 수 있는 점검 루틴 하나를 손에 쥐고 가시게 될 겁니다.

미리 한 가지만 약속해 두겠습니다. 이 글에서 "서체를 제대로 쓴다"는 건 "더 예쁜 폰트를 고른다"가 아닙니다. 오히려 "정해진 서체를, 정해진 위계로, 누구나 읽을 수 있는 크기로 일관되게 쓴다"에 가깝습니다. 멋 부리기가 아니라 약속 지키기죠. 그리고 약속을 지켰는지는 사람이 페이지마다 눈으로 확인하기 어렵기 때문에, 자동 점검이 필요합니다.

Pretendard GOV가 대체 뭔가 — 정의부터 정확히

먼저 용어를 정리하겠습니다. "프리텐다드(Pretendard)"라는 이름은 들어 보신 분이 많을 겁니다. 한글과 영문, 숫자를 폭넓게 지원하는 오픈소스 산세리프(고딕) 글꼴로, 지난 몇 년간 한국 웹·앱 디자인에서 사실상 표준처럼 쓰여 왔습니다. 본문에 무난하게 잘 어울리고, 다양한 굵기(weight)를 제공하며, 라이선스가 자유로워서 많은 팀이 애용했죠.

KRDS(대한민국 정부 디자인 시스템)가 채택한 건 이 프리텐다드를 공공 환경에 맞게 정리한 Pretendard GOV입니다. 이름에 'GOV'가 붙은 데에는 이유가 있습니다. 정부 서비스라는 맥락에 맞춰 사용 규칙·굵기 운영·디자인 토큰을 표준화해, "공공 사이트는 이 서체를 이렇게 쓴다"를 하나로 못 박아 둔 것이죠. 그러니까 Pretendard GOV는 단순히 "폰트 파일 하나"가 아니라, 서체 + 사용 규칙 + 디자인 토큰이 한 세트로 묶인 타이포그래피 시스템이라고 보는 게 정확합니다.

여기서 "디자인 토큰"이라는 말이 처음 나왔는데, 이 글 내내 중요하게 등장하니 짚고 가겠습니다. 디자인 토큰은 색상·글자 크기·굵기·간격 같은 디자인 값을 "magic number(매직넘버)"로 코드 여기저기에 흩뿌리는 대신, 이름 붙은 변수로 한 곳에서 관리하는 방식입니다. 예를 들어 "본문 글자 크기는 16px, 굵기는 Regular, 줄 간격은 1.5"를 매번 손으로 적는 대신 font-size-body, font-weight-regular 같은 토큰으로 정의해 두고 가져다 쓰는 거죠. KRDS는 타이포그래피를 토큰으로 제공하기 때문에, 표준 준수란 곧 "이 토큰들을 제대로 채택했는가"의 문제가 됩니다. 이 점이 뒤에서 ViewCheck 점검과 직접 연결됩니다.

왜 하필 정부가 서체를 표준으로 정했나

"폰트 하나 통일하는 게 뭐 그리 대단한 일인가" 싶을 수 있습니다. 그런데 공공 영역에서 서체 통일은 생각보다 큰 의미가 있습니다.

첫째, 신뢰의 일관성입니다. 국민 입장에서 정부 사이트는 "한 정부가 운영하는 하나의 서비스 묶음"입니다. 그런데 부처마다, 지자체마다 글꼴이 다르면 "여기가 진짜 공식 사이트가 맞나?" 하는 미묘한 불신이 생깁니다. 같은 서체를 쓰면 처음 보는 기관의 사이트라도 "아, 공공 서비스구나"라는 신뢰가 자연스럽게 전달됩니다.

둘째, 학습 비용 절감입니다. 셀렉트나 버튼 같은 컴포넌트가 표준화되면 조작법을 다시 안 배워도 되듯, 서체가 표준화되면 "글자 위계"를 다시 안 배워도 됩니다. 어느 사이트를 가든 제목은 같은 방식으로 크고 굵고, 본문은 같은 방식으로 차분합니다. 이 일관성은 특히 디지털이 익숙하지 않은 고령층에게 큰 배려가 됩니다.

셋째, 가독성의 하한선 보장입니다. 표준 서체와 표준 크기를 정해 두면, 적어도 "본문이 너무 작거나 흐려서 못 읽는" 최악의 상황은 막을 수 있습니다. 자유롭게 두면 누군가는 멋을 부린다고 본문을 12px 얇은 글꼴로 깔아 버리거든요. 표준은 그 바닥을 받쳐 줍니다.

KRDS 공식 스타일 가이드(타이포그래피 영역)를 열어 보면, Pretendard GOV를 어떻게 굵기별로 운영하고 어떤 위계로 쓰는지가 정리돼 있습니다. 굵기는 보통 Regular(보통)·Medium(중간)·Bold(굵게)를 중심으로 운영하는데, 이 세 굵기를 "아무 데나 마음대로"가 아니라 역할에 따라 쓰도록 권합니다. 본문은 Regular, 강조나 소제목은 Medium, 큰 제목은 Bold 식으로요. 핵심은 "굵기를 장식이 아니라 위계의 도구로 쓴다"는 것입니다.

KRDS는 서체에 무엇을 요구하나 — 기준 완전 해부

이제 본격적으로 기준을 뜯어보겠습니다. KRDS 가이드라인(디지털 정부서비스 UI/UX 가이드라인, 2025.08판)과 공식 스타일 페이지, 그리고 웹 접근성 기준(KWCAG)을 종합하면, 서체와 관련해 충족해야 할 요건은 다음과 같이 정리됩니다.

1) 표준 서체를 실제로 적용했는가

가장 기본입니다. 본문·제목·버튼·라벨 등 화면 텍스트의 기본 글꼴이 Pretendard GOV로 지정돼 있어야 합니다. 여기엔 함정이 두 개 있습니다.

하나는 폰트 파일을 불러오지 않고 이름만 적어 둔 경우입니다. CSS에 font-family: "Pretendard GOV"라고 적었지만 실제 폰트 파일(웹폰트)을 로드하지 않으면, 사용자 브라우저는 그 서체가 없으니 시스템 기본 글꼴(돋보기로 보면 굴림이나 맑은 고딕 같은 것)로 떨어집니다. 코드상으론 "표준 서체 지정"인데 화면엔 엉뚱한 글꼴이 뜨는 거죠.

다른 하나는 fallback(대체 글꼴) 순서가 엉성한 경우입니다. font-family는 여러 글꼴을 콤마로 나열해 "앞엣것이 없으면 뒤엣것을 쓴다"는 우선순위 목록입니다. 표준 서체를 맨 앞에 두고, 그 뒤에 합리적인 한글 대체 글꼴과 마지막에 sans-serif를 두는 게 정석입니다. 이 순서가 뒤죽박죽이면 일부 환경에서 의도치 않은 글꼴이 나옵니다.

2) 글자 위계(typography scale)가 명확한가

타이포그래피의 핵심은 "굵기 종류"가 아니라 "위계"입니다. 제목·소제목·본문·캡션·라벨이 각각 정해진 크기와 굵기를 갖고, 그 차이가 사용자에게 "이게 더 중요하고, 이건 부가 정보다"를 한눈에 전달해야 합니다.

KRDS는 이 위계를 토큰으로 제공합니다. 즉 "큰 제목은 이 크기, 본문은 이 크기"가 변수로 정해져 있어요. 개발자가 매번 임의의 px 값을 박지 말고 정해진 토큰을 쓰면, 사이트 전체의 글자 위계가 자동으로 일관됩니다. 반대로 토큰을 안 쓰고 페이지마다 손으로 크기를 정하면, 같은 "소제목"인데 A 페이지는 20px, B 페이지는 18px이 되는 식의 미세한 어긋남이 쌓입니다.

3) 본문 가독성 — 크기·줄 간격·자간

서체를 표준으로 깔았다고 가독성이 보장되는 건 아닙니다. 세 가지가 더 받쳐 줘야 합니다.

• 글자 크기: 본문은 사용자가 편하게 읽을 수 있는 크기여야 합니다. 데스크톱에서 본문이 너무 작으면(예: 12~13px) 고령층·저시력 사용자에게 부담입니다. 일반적으로 본문은 16px 안팎을 기준으로 잡는 것이 안전합니다(KRDS도 토큰으로 본문 기준 크기를 제공합니다).
• 줄 간격(line-height): 줄과 줄 사이가 너무 좁으면 다음 줄로 시선을 옮기다 헤맵니다. 한글 본문은 보통 1.5 안팎의 줄 간격이 읽기 편합니다.
• 자간/글자 폭: 너무 빽빽하거나 너무 벌어지면 읽기 흐름이 끊깁니다. 표준 토큰을 쓰면 이 값도 검증된 기본값으로 따라옵니다.

4) 확대(zoom·텍스트 리사이즈)에 견디는가

이건 접근성에서 특히 중요한 요건입니다. 사용자가 브라우저에서 글자를 200%까지 키웠을 때, 텍스트가 잘리거나 겹치거나 컨테이너 밖으로 삐져나가지 않고 읽을 수 있어야 합니다. 저시력 사용자는 글자 확대를 일상적으로 씁니다.

여기서 자주 깨지는 게 px 고정 폭과 절대 단위 남용입니다. 글자 크기를 px로만 박고 레이아웃을 픽셀 단위로 빡빡하게 짜 두면, 확대 시 글자가 칸을 넘쳐 버립니다. 상대 단위(rem 등)를 쓰고 레이아웃에 여유를 두면 확대에 훨씬 잘 견딥니다.

5) 반응형 — 모바일에서의 본문 크기와 위계

데스크톱에서 잘 보이던 위계가 모바일에서 무너지는 경우가 많습니다. 좁은 화면에 맞춘다고 본문을 13px로 줄여 버리거나, 제목과 본문의 크기 차이가 사라져 위계가 평평해지거나요. 모바일에서도 본문은 충분히 크고, 제목·본문·캡션의 위계는 유지돼야 합니다. KRDS의 반응형 토큰을 쓰면 화면 크기에 따른 크기 조정이 기준에 맞춰 따라옵니다.

6) 색 대비 — 글자색과 배경색

엄밀히 말하면 색 대비는 색상 토큰의 영역이지만, "읽을 수 있는 텍스트"라는 점에서 서체와 떼어 놓을 수 없습니다. 본문 텍스트와 배경의 명도 대비가 충분해야(일반 텍스트 기준 4.5:1 이상이 널리 쓰이는 기준입니다) 저시력 사용자나 밝은 야외에서도 읽힙니다. 연회색 본문을 흰 배경에 깔아 "세련됐다"고 만족하는 동안, 누군가는 그 글을 읽지 못합니다.

정리하면, KRDS의 서체 기준은 네 축으로 모입니다. ① 표준성(Pretendard GOV를 실제로 적용·로드), ② 위계(토큰 기반의 명확한 제목/본문/캡션 구분), ③ 가독성(충분한 크기·줄 간격·대비), ④ 견고함(확대·반응형에서도 안 무너짐). 이 네 축이 그대로 ViewCheck가 디자인 시스템 영역에서 서체를 점검하는 기준이기도 합니다.

왜 이렇게까지 따지나 — 원리와 배경

여기까지 읽고 "글꼴 하나에 뭘 이리 까다롭나" 싶으실 수 있습니다. 그런데 서체 요건들은 누가 괜히 만든 규칙이 아니라, 실제로 사람이 글을 못 읽는 지점에서 역으로 도출된 것들입니다.

공공 텍스트는 "안 읽을 자유"가 없다

상업 콘텐츠는 읽기 불편하면 안 읽으면 그만입니다. 그런데 공공 서비스의 텍스트는 다릅니다. 지원금 신청 자격 요건, 민원 처리 안내, 개인정보 동의 내용 — 이런 건 안 읽고 넘어가면 불이익이 사용자에게 돌아옵니다. 그래서 공공 사이트의 본문이 작거나 흐리거나 위계가 엉망이면, 그건 단순한 "디자인이 아쉬움"이 아니라 정보 접근권의 문제가 됩니다.

본문이 13px 연회색으로 깔린 화면에서, 고령의 신청자는 자격 요건을 끝까지 못 읽고 포기할 수 있습니다. 글자를 200% 키웠더니 문장이 겹쳐 버리는 페이지에서, 저시력 사용자는 안내문을 읽지 못합니다. 이게 KRDS가 서체의 크기·대비·확대 대응을 "있으면 좋은 것"이 아니라 "기본 요건"으로 두는 이유입니다.

위계가 무너지면 길을 잃는다

타이포그래피의 위계는 단순히 "예쁘게 보이려는 장식"이 아니라 정보의 지도입니다. 사람은 페이지를 읽기 전에 먼저 훑습니다. 큰 글자를 보고 "여기가 중요한 부분", 작은 글자를 보고 "부가 정보"라고 무의식적으로 분류하죠. 이 위계가 명확하면 사용자는 원하는 정보로 빠르게 점프합니다.

그런데 제목과 본문의 크기 차이가 흐릿하거나, 페이지마다 위계 규칙이 다르면 이 지도가 작동하지 않습니다. 사용자는 모든 글자를 똑같은 비중으로 읽어 내려가야 하고, 그만큼 피로해지고 길을 잃습니다. 스크린리더 사용자에게는 위계가 코드(제목 태그 h1~h6)로도 표현돼 있어야 하는데, 시각적 크기만 키우고 코드 위계를 안 맞추면 음성으로는 그 구조가 전달되지 않습니다. 보이는 위계와 읽히는 위계의 일치 — 셀렉트나 아이콘에서 봤던 원리가 서체에서도 똑같이 적용됩니다.

일관성은 신뢰이고, 신뢰는 토큰에서 나온다

앞서 말한 "정부 사이트의 신뢰감"은 추상적인 분위기가 아니라 구체적인 값의 일관성에서 나옵니다. 모든 페이지가 같은 서체, 같은 위계 토큰을 쓰면 자동으로 일관됩니다. 반대로 토큰 없이 페이지마다 손으로 값을 박으면, 아무리 디자인 가이드 문서를 잘 써 둬도 시간이 지나며 조금씩 어긋납니다. 새 페이지를 만든 담당자가 가이드를 안 보고 임의의 크기를 쓰는 순간 일관성에 금이 가거든요.

그래서 KRDS가 서체를 "문서로 권고"하는 데 그치지 않고 "토큰으로 제공"하는 게 핵심입니다. 토큰을 가져다 쓰면 일관성이 기본값이 되고, 어긋남이 예외가 됩니다. 이 구조 덕분에 "표준 준수율"을 기계가 측정할 수도 있게 됩니다. 토큰을 썼는지 안 썼는지는 코드에서 확인 가능하니까요.

작아 보이는 게 가장 넓게 퍼진다

서체는 화면의 거의 모든 곳에 깔립니다. 버튼 안에도, 라벨에도, 본문에도, 캡션에도 글자가 있죠. 그래서 서체 하나가 틀어지면 그 영향이 사이트 전체에 균일하게 퍼집니다. 버튼 하나가 잘못된 건 그 버튼만의 문제지만, 본문 글꼴이 표준에서 벗어난 건 모든 페이지의 모든 문장의 문제입니다. 가장 작아 보이는 디자인 요소가 사실은 가장 넓은 면적을 차지하고, 가장 많은 사용자에게 영향을 줍니다. 서체를 가볍게 보면 안 되는 이유입니다.

한 장면 — 같은 안내문, 두 사람

추상적인 요건을 길게 늘어놓는 것보다, 한 장면을 그려 보는 게 빠를 것 같습니다. 어느 공공 서비스의 "주거 지원금 신청 자격 안내" 페이지가 있다고 합시다. 본문에 자격 요건이 여섯 줄쯤 깔려 있고, 디자인팀이 "세련돼 보이려고" 본문을 13px 옅은 회색으로, 줄 간격은 빡빡하게 잡아 두었습니다.

먼저 30대 직장인 김 씨. 눈이 좋고 모니터도 큽니다. 회색 13px 본문도 무리 없이 읽고, "소득 기준 중위소득 60% 이하" 같은 핵심을 빠르게 캐치합니다. 김 씨에게 이 페이지는 아무 문제가 없습니다. 그래서 이 화면을 만든 팀도 "잘 나온다"고 믿습니다. 자기들이 검수할 때도 다 김 씨 같은 눈으로 봤으니까요.

이번엔 일흔이 넘으신 박 어르신. 자녀가 "엄마, 지원금 나온대요. 자격 한번 보세요" 하고 링크를 보내 줬습니다. 어르신이 화면을 켜는 순간, 작고 흐릿한 회색 글씨가 빽빽하게 깔려 있습니다. 어디가 제목이고 어디가 본문인지 위계도 흐릿합니다(굵기를 위계로 안 썼으니까요). 글자를 키워 보려고 브라우저 확대를 했더니, 이번엔 문장이 옆 칸과 겹쳐 버립니다(px 고정 레이아웃이라 확대에 안 견딥니다). 어르신은 결국 "잘 모르겠다, 나중에 자녀한테 물어봐야지" 하고 창을 닫습니다. 자격이 되는데도, 안내문을 못 읽어서 신청을 미룬 겁니다.

같은 페이지, 같은 안내문. 한 사람에겐 1분짜리 가벼운 읽기이고, 다른 한 사람에겐 닫힌 문입니다. 그리고 이 차이는 "예산이 부족해서"나 "기술이 어려워서" 생긴 게 아닙니다. 그냥 만들 때 김 씨 같은 눈만 떠올렸기 때문에 생긴 차이입니다. 본문을 16px 또렷한 색으로, 위계를 토큰으로, 레이아웃을 확대에 견디게만 했어도 박 어르신은 자녀 도움 없이 자격을 확인했을 겁니다. 차이를 만드는 건 거창한 기술이 아니라, "표준 서체와 토큰을 제대로 쓰느냐"라는 작은 선택입니다. 그리고 그 선택이 지켜졌는지는 사람이 매번 어르신 입장에서 확인하기 어렵기 때문에, 자동 점검이 필요한 겁니다.

공공 사이트가 자주 틀리는 지점 — 그리고 올바른 예

이제 현업에서 실제로 반복되는 서체 실수들을 보겠습니다. 모두 익명화한 일반적 사례입니다(특정 기관을 지목하지 않습니다).

실수 1) 이름만 적고 폰트는 안 불러온 "유령 서체"

가장 흔하고 가장 허무한 실수입니다. CSS에 font-family: "Pretendard GOV", sans-serif라고 적어 두고는, 정작 웹폰트 파일을 로드하는 코드(@font-face 또는 CDN 링크)를 빠뜨립니다.

• 나쁜 예: 글꼴 이름만 선언. 사용자 PC에 그 폰트가 없으니 브라우저가 시스템 기본 글꼴로 대체. 담당자 PC엔 우연히 폰트가 깔려 있어 "잘 나오는데?" 하고 넘어감. 정작 일반 사용자 화면엔 굴림체가 뜸.
• 올바른 예: CDN(krds.min.css)을 불러오거나 @font-face로 폰트 파일을 명시적으로 로드. 담당자 PC가 아니라 "폰트가 안 깔린 깨끗한 환경"에서 확인.

이 실수가 무서운 건, 만든 사람 눈엔 절대 안 보인다는 점입니다. 개발·디자인 PC에는 작업하면서 폰트가 깔려 있는 경우가 많아, 본인 화면엔 멀쩡히 표준 서체가 뜨거든요. 그래서 이건 사람 눈보다 자동 점검이 훨씬 잘 잡습니다.

실수 2) 본문이 너무 작거나 너무 흐리다

"세련돼 보이려고" 본문을 13px 연회색으로 까는 경우입니다.

• 나쁜 예: 본문 13px, 글자색 옅은 회색(#999 류). 데스크톱에서도 읽기 부담. 고령·저시력 사용자에겐 거의 못 읽는 수준.
• 올바른 예: 본문은 16px 안팎, 글자색은 배경과 충분한 대비(일반 텍스트 4.5:1 이상). KRDS 본문 토큰을 쓰면 검증된 기본값이 따라옴.

실수 3) 굵기를 위계가 아니라 기분으로 쓴다

Regular·Medium·Bold를 역할 없이 아무 데나 섞어 씁니다.

• 나쁜 예: 어떤 소제목은 Bold, 어떤 소제목은 Regular. 본문 중간에 갑자기 굵은 글자가 강조도 아닌데 등장. 위계가 읽히지 않음.
• 올바른 예: 굵기를 역할로 고정 — 큰 제목 Bold, 소제목·강조 Medium, 본문 Regular. 같은 종류의 텍스트는 항상 같은 굵기.

실수 4) 시각적 위계만 있고 코드 위계가 없다

글자를 크게 만들어 "제목처럼" 보이게 했지만, 코드로는 그냥 <div>나 <p>에 큰 글씨를 입힌 경우입니다.

• 나쁜 예: 눈엔 제목으로 보이는데 코드엔 제목 태그(h1~h6)가 없음. 스크린리더가 페이지 구조를 파악 못 함. 제목으로 건너뛰기 탐색이 안 됨.
• 올바른 예: 시각적 제목은 의미에 맞는 제목 태그로 마크업하고, 크기·굵기는 토큰으로 입힘. 보이는 위계와 코드 위계 일치.

실수 5) 확대하면 글자가 깨진다

레이아웃을 px로 빡빡하게 짜서, 글자를 200% 키우면 문장이 겹치거나 버튼 밖으로 삐져나갑니다.

• 나쁜 예: 고정 높이 버튼에 px 글자. 확대 시 글자가 버튼 위아래로 잘림. 좁은 칸의 라벨이 겹침.
• 올바른 예: 상대 단위(rem)와 여유 있는 레이아웃. 확대해도 글자가 흐름에 따라 늘어나며 읽힘.

실수 6) 모바일에서 위계가 평평해진다

좁은 화면에 맞춘다고 제목과 본문을 비슷한 크기로 줄여 위계가 사라집니다.

• 나쁜 예: 모바일에서 제목 16px, 본문 14px. 차이가 미미해 무엇이 제목인지 안 보임. 본문도 작아 읽기 불편.
• 올바른 예: 반응형 토큰으로 모바일에서도 제목/본문의 위계 유지, 본문은 충분한 크기 확보.

실수 7) 외부 글꼴을 섞어 쓰며 일관성이 깨진다

이미지로 박은 텍스트, 외부 위젯, 첨부 배너 등에 다른 글꼴이 섞여 사이트 안에서 서체가 따로 놉니다.

• 나쁜 예: 본문은 Pretendard GOV인데 배너·이미지 텍스트는 제각각. 사이트가 누더기처럼 보임. 이미지 텍스트는 확대·스크린리더 대응도 안 됨.
• 올바른 예: 가능한 한 실제 텍스트로 구현하고 표준 서체로 통일. 이미지 텍스트 사용 최소화(불가피하면 대체 텍스트 제공).

실수 8) 폰트 로딩 처리를 안 해 화면이 깜빡인다

웹폰트가 늦게 로드돼, 처음엔 기본 글꼴로 떴다가 폰트가 로드되면서 글자가 확 바뀌는(레이아웃이 흔들리는) 현상을 방치합니다.

• 나쁜 예: 페이지가 뜨고 1~2초 뒤 글꼴이 바뀌며 화면이 출렁임(FOUT/FOIT). 체감 성능과 안정성에 악영향.
• 올바른 예: font-display 설정, 폰트 preload, 합리적 fallback으로 전환을 매끄럽게. KRDS 제공 방식을 따르면 이 부분도 어느 정도 정리됨.

직접 적용하기 — 개발자·디자이너·기획자 가이드

KRDS의 좋은 점은, 위 요건들을 "알아서 잘 하세요"로 끝내지 않고 바로 쓸 수 있는 자산으로 제공한다는 것입니다.

개발자라면 — KRDS 컴포넌트 킷을 npm install krds-uiux로 설치하거나 CDN(krds.min.css / krds.min.js)으로 불러올 수 있습니다. 여기에 Pretendard GOV 폰트와 타이포그래피 토큰(글자 크기·굵기·줄 간격 변수)이 함께 들어 있어, 폰트 로드와 위계 토큰을 직접 만들 필요가 없습니다. 핵심은 두 가지입니다. 첫째, 폰트를 실제로 로드했는지 빈 환경에서 확인할 것. 둘째, 글자 크기·굵기를 px 매직넘버로 박지 말고 토큰을 쓸 것. 이 둘만 지켜도 서체 위반의 대부분이 사라집니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 타이포그래피 스타일(제목/본문/캡션 등)을 스타일로 가져다 쓸 수 있습니다. 직접 크기를 정하지 말고 정의된 텍스트 스타일을 적용하면, 시안 단계에서부터 위계가 기준에 맞춰집니다. 시안과 구현 사이의 간극(디자이너는 18px로 그렸는데 개발은 16px로 구현)도 줄어듭니다. 특히 "강조하고 싶다"는 이유로 임의 굵기를 남발하지 말고, 정의된 위계 안에서 표현하는 습관이 중요합니다.

기획자라면 — 화면 정의서에 "본문 텍스트"라고만 적지 말고, "제목(H2)·본문·주의 문구(에러 색)"처럼 위계와 역할을 함께 명시하세요. 특히 법적 고지·동의 내용처럼 반드시 읽혀야 하는 텍스트는 "충분한 크기·대비 필수"라고 못 박아 두면, 디자인·개발 단계에서 작은 회색 글씨로 묻히는 사고를 막을 수 있습니다.

이렇게 세 팀이 같은 토큰을 기준으로 일하면 "서체는 디자인팀 일", "로딩은 개발팀 일" 식의 책임 떠넘기기가 줄어듭니다. KRDS가 디자인(Figma)·코드(GitHub 킷)·문서(가이드라인)를 한 세트로 제공하는 이유가 바로 이겁니다.

그래서 우리 사이트는? — ViewCheck로 5분 자가진단

여기까지가 KRDS의 서체 기준입니다. 그런데 이 글의 진짜 목적은 "기준을 외우는 것"이 아니라 "우리 사이트가 이걸 지키는지 확인하는 것"입니다. 그리고 솔직히, 서체 점검을 사람이 손으로 하는 건 거의 불가능에 가깝습니다.

생각해 보세요. 페이지마다 본문 글꼴이 정말 Pretendard GOV로 렌더링되는지, 본문 크기가 16px 안팎인지, 굵기가 위계에 맞는지, 모바일에서 위계가 유지되는지, 200% 확대에서 안 깨지는지를 사람이 일일이 확인하려면 — 한 페이지에만 한참이 걸리고, 수십·수백 페이지 사이트는 엄두도 안 납니다. 게다가 "유령 서체"처럼 담당자 PC에선 멀쩡히 보이는 문제는 눈으로는 절대 못 잡습니다.

ViewCheck(krds.viewcheck.co.kr)는 이 점검을 자동화합니다. URL만 넣으면 페이지를 실제로 크롤링해서, 서체를 포함한 디자인 시스템 요소들이 KRDS 기준을 지키는지 판정합니다. Pretendard GOV 서체는 KRDS 846규칙 중 디자인 시스템(DS) 규칙군 120개에 속하고, 분석 결과의 디자인 시스템(Design System) 탭에서 확인할 수 있습니다. 이 탭의 핵심 산출물이 바로 디자인 토큰 채택률 리포트입니다.

ViewCheck가 서체에 대해 자동으로 보는 것들:

• 실제 적용 서체 판별: 코드에 적힌 글꼴 이름이 아니라, 페이지가 실제로 렌더링할 때 쓰는 computed style(계산된 스타일)을 읽어 Pretendard GOV가 진짜 적용됐는지 확인. "이름만 적고 안 불러온 유령 서체"를 잡아냄.
• 타이포그래피 토큰 채택률: 글자 크기·굵기·줄 간격이 KRDS 토큰 체계에 맞춰 쓰였는지, 아니면 임의 px 매직넘버로 박혔는지를 비교해 채택률로 보여 줌(1,082개 디자인 토큰 비교의 일부).
• 본문 크기·대비: 본문 텍스트의 크기와 글자색/배경색 대비가 가독성 기준을 충족하는지(색 대비는 색상 분석과 연계).
• 위계 일관성: 제목·본문·캡션의 위계가 명확한지, 시각적 제목이 코드(제목 태그)로도 표현됐는지(SEO/접근성 헤딩 구조 분석과 연계).
• 반응형 위계: 데스크톱·태블릿·모바일 3개 뷰포트를 실제로 테스트해 모바일에서 본문 크기·위계가 무너지지 않는지(반응형 품질 분석과 연계).

DOM과 computed style만으로 판단하기 어려운 시각적 부분(예: 이미지로 박은 텍스트, 비표준 렌더링)은 KRDScan Vision AI가 스크린샷을 보고 보강 판정합니다. 그래서 "코드상으론 표준인데 화면엔 다른 글꼴이 보이는" 경우도 놓치지 않습니다. 사람이 눈으로 보듯 화면을 함께 보기 때문에, 코드 검사만으로는 빠지는 시각적 불일치까지 잡아냅니다.

리포트를 어떻게 읽나

분석이 끝나면 디자인 시스템 탭에서 서체 관련 규칙의 통과/미통과 수와, 토큰 채택률(%)이 함께 나옵니다. 예를 들어 "타이포그래피 토큰 채택률 62%"처럼요. 숫자가 낮다면, 그만큼 임의 px 값으로 글자를 박아 둔 곳이 많다는 뜻입니다. 미통과 항목에는 위치(어느 페이지)·이유·개선 방법(howToFix)이 함께 붙습니다. "메인 페이지 본문이 표준 서체로 렌더링되지 않음(폰트 미로드 의심)"처럼 구체적으로요.

여러 페이지를 한꺼번에 분석하면 페이지별 편차도 드러납니다. "메인은 표준 서체인데 신청 페이지만 시스템 글꼴로 떨어진다" 같은 국부적 문제는, 한 페이지만 봐선 절대 안 보입니다. ViewCheck의 다중 페이지 분석은 이런 "한 군데만 새는 곳"을 찾아내는 데 특히 강합니다. 그리고 어디부터 고쳐야 하는지 우선순위(P0~P3)도 함께 매겨지니, 한정된 시간에 가장 중요한 것부터 손볼 수 있습니다.

무료 진단으로 우리 사이트 메인부터 한 번 돌려 보면, 손으로는 며칠 걸릴 점검이 몇 분 만에 끝납니다. 그리고 그 결과는 막연한 "서체 잘 쓰자"가 아니라, "이 페이지의 폰트 로드를 고치고, 본문 크기를 토큰으로 바꾸자"는 구체적 작업 목록이 됩니다.

5분 자가진단 루틴 — 따라 하기

각도가 "점검"인 만큼, 지금 당장 따라 할 수 있는 순서를 정리하겠습니다. 도구가 없어도 일부는 손으로 확인할 수 있고, ViewCheck를 함께 쓰면 훨씬 빠릅니다.

1단계 — 폰트가 실제로 로드되는지(2분)

브라우저 개발자 도구를 열고(F12), 본문 텍스트를 선택해 적용된 font-family의 "계산된 값(Computed)"을 봅니다. 거기에 Pretendard GOV가 떠 있는지, 아니면 시스템 글꼴(예: 굴림, 맑은 고딕)로 떨어졌는지 확인합니다. 더 확실하게는, 폰트가 안 깔린 다른 사람의 PC나 시크릿 모드의 깨끗한 환경에서 사이트를 열어 봅니다. 이게 "유령 서체"를 잡는 가장 빠른 방법입니다.

2단계 — 본문 크기·대비(1분)

같은 개발자 도구에서 본문의 font-size를 봅니다. 13px 이하라면 위험 신호입니다. 글자색과 배경색의 대비도 점검 대상입니다(대비 측정은 ViewCheck나 별도 대비 검사기로 정확히 확인 가능).

3단계 — 확대 테스트(1분)

브라우저에서 Ctrl(맥은 Cmd) + '+'를 눌러 글자를 200%까지 키워 봅니다. 문장이 겹치거나, 버튼 밖으로 삐져나가거나, 가로 스크롤이 생기지 않는지 봅니다.

4단계 — 모바일 위계(1분)

개발자 도구의 모바일 뷰(반응형 모드)로 전환해, 제목과 본문의 크기 차이가 유지되는지, 본문이 너무 작아지지 않았는지 봅니다.

5단계 — ViewCheck로 전 페이지 자동 점검

손으로 하는 1~4단계는 "내가 지금 보는 한 페이지"만 검사합니다. 사이트 전체를 한 번에 보려면 ViewCheck에 URL을 넣고 돌리세요. 디자인 시스템 탭에서 토큰 채택률과 페이지별 서체 판정을 한눈에 받을 수 있습니다. 손 점검은 "감을 잡는 용도", ViewCheck는 "전수 검사 용도"로 나눠 쓰면 효율적입니다.

자주 묻는 질문

현장에서 서체를 다룰 때 반복해서 나오는 질문들을 모았습니다.

Q. 그냥 일반 Pretendard를 쓰면 안 되나요? 굳이 Pretendard GOV여야 하나요?

일반 프리텐다드도 좋은 글꼴이지만, 공공 서비스라면 Pretendard GOV를 쓰는 게 맞습니다. 단순히 폰트 파일의 문제가 아니라, 공공 환경에 맞춰 정리된 사용 규칙과 타이포그래피 토큰이 함께 따라오기 때문입니다. 같은 기반이라도 "정부 표준으로 운영되는 세트"를 쓰는 것과 "그냥 좋은 폰트 하나를 가져다 쓰는 것"은 일관성·검증 측면에서 차이가 납니다. 표준을 따르면 다른 공공 사이트들과 자연스럽게 한 식구가 되고, 자동 점검에서도 명확히 "표준 준수"로 잡힙니다.

Q. 우리 브랜드 컬러나 디자인 정체성을 살리고 싶은데, 서체까지 표준이면 너무 획일적이지 않나요?

서체 표준화가 곧 "모든 사이트가 똑같아진다"는 뜻은 아닙니다. 타이포그래피가 통일돼도 레이아웃, 색상 운용(브랜드 컬러), 이미지, 콘텐츠 구성으로 충분히 개성을 낼 수 있습니다. 오히려 서체와 위계가 안정적으로 깔려 있을수록, 그 위에서 다른 디자인 요소가 더 돋보입니다. 공공 서비스에서 "글자 위계의 일관성"은 개성을 깎는 비용이 아니라, 신뢰와 가독성을 받쳐 주는 토대라고 보는 게 맞습니다.

Q. 이미 운영 중인 사이트인데, 서체를 전부 다시 작업해야 하나요?

전부 갈아엎을 필요는 없습니다. 보통 가장 효과 큰 한 방은 "폰트 로드를 제대로 거는 것"입니다. 이름만 적혀 있고 안 불러오던 폰트를 CDN/@font-face로 제대로 로드하면, 한 번에 사이트 전체 글꼴이 표준으로 바뀝니다. 그다음 본문 크기·대비처럼 가독성에 직접 영향을 주는 항목을 손보고, 토큰화는 점진적으로 진행하면 됩니다. 먼저 ViewCheck로 현황을 찍어 "지금 어느 페이지의 무엇이 문제인지" 목록을 만든 뒤, 우선순위대로 고치는 게 현실적입니다.

Q. px로 폰트 크기를 박으면 정말 문제가 되나요? 대부분 px 쓰던데요.

px가 무조건 "틀린" 건 아니지만, 두 가지 약점이 있습니다. 첫째, 사용자가 브라우저 기본 글자 크기를 키워 둬도 px는 그걸 무시하는 경향이 있어 접근성에 불리합니다. 둘째, 매직넘버로 흩어지면 일관성과 유지보수가 어렵습니다. 상대 단위(rem)와 토큰을 쓰면 사용자 설정 존중·일관성·확대 대응이 한꺼번에 좋아집니다. KRDS 토큰을 채택하는 게 가장 간단한 해법입니다.

Q. 폰트 때문에 페이지가 느려지진 않나요?

웹폰트는 분명 추가 리소스라 로딩 비용이 있습니다. 그래서 무작정 모든 굵기를 다 불러오기보다, 실제 쓰는 굵기만 로드하고, font-display로 전환을 매끄럽게 하고, 핵심 폰트는 preload하는 식으로 관리하는 게 좋습니다. KRDS 제공 방식과 CDN을 쓰면 이 부분이 어느 정도 정리돼 있습니다. ViewCheck의 Web Vitals(효율성) 분석에서 폰트를 포함한 리소스 로딩 영향도 함께 볼 수 있으니, 가독성(서체)과 성능(로딩)을 같이 점검하면 균형을 맞추기 쉽습니다.

Q. 손으로 개발자 도구 보는 것과 ViewCheck, 뭐가 다른가요?

손 점검은 "지금 내가 보는 한 페이지"의 감을 잡는 데 좋습니다. 빠르고 직관적이죠. 하지만 사이트가 수십·수백 페이지면 전수 검사가 불가능하고, "담당자 PC에선 멀쩡한 유령 서체" 같은 함정은 사람 눈으론 놓치기 쉽습니다. ViewCheck는 페이지를 실제 크롤링해 computed style 기준으로 전수 판정하고, 토큰 채택률·페이지별 편차·우선순위까지 자동으로 정리합니다. 손 점검은 정찰, ViewCheck는 전면 스캔 — 둘을 함께 쓰는 걸 권합니다.

Q. 디자인팀과 개발팀이 서로 "그건 너희 일"이라고 합니다.

서체 품질은 어느 한 팀의 일이 아닙니다. 디자이너는 위계(텍스트 스타일)를 시안에 정의하고, 개발자는 폰트를 실제로 로드하고 토큰으로 구현하고, 기획자는 어떤 텍스트가 반드시 읽혀야 하는지(크기·대비 필수)를 명시해야 합니다. KRDS가 Figma·GitHub 킷·가이드라인을 한 세트로 제공하는 것도 세 팀이 같은 기준을 보게 하려는 의도입니다. ViewCheck 리포트를 공통 채점표로 쓰면, "네 일/내 일" 논쟁 대신 "이 항목을 누가 언제 고칠지"로 대화가 바뀝니다.

Q. 토큰 채택률이 100%가 아니면 무조건 잘못된 건가요?

꼭 그렇진 않습니다. 채택률은 "표준 토큰으로 관리되는 비율"을 보여 주는 지표이지, 100%가 아니면 무조건 실패라는 뜻은 아닙니다. 다만 채택률이 낮다는 건 그만큼 글자 크기·굵기·간격이 코드 여기저기에 매직넘버로 흩어져 있다는 신호이고, 그건 곧 "일관성이 깨지기 쉽고 유지보수가 어렵다"는 뜻입니다. 현실적으로는 100%를 목표로 삼기보다, 채택률을 점진적으로 끌어올리면서 특히 본문·제목처럼 영향이 큰 텍스트부터 토큰화하는 게 좋습니다. ViewCheck로 채택률 추세를 주기적으로 찍어 두면, 리뉴얼이나 신규 페이지 추가 때 일관성이 다시 무너지지 않는지 모니터링할 수 있습니다.

Q. 다크 모드나 고대비 모드도 신경 써야 하나요?

사용자 환경은 생각보다 다양합니다. 운영체제 고대비 모드, 브라우저 글자 확대, 다크 모드 등을 쓰는 사용자가 있고, 특히 고대비·확대는 저시력 사용자에게 중요합니다. 서체 관점에서 핵심은 두 가지입니다. 첫째, 글자 크기를 상대 단위로 두어 사용자 설정을 존중할 것. 둘째, 글자색을 고정 회색으로 박아 배경이 바뀌면 대비가 무너지는 일이 없도록, 색도 토큰으로 관리할 것. 이렇게 해 두면 다양한 환경에서도 가독성의 하한선이 지켜집니다.

Q. 디자인팀과 개발팀이 서로 "그건 너희 일"이라고 합니다.

서체 품질은 어느 한 팀의 일이 아닙니다. 디자이너는 위계(텍스트 스타일)를 시안에 정의하고, 개발자는 폰트를 실제로 로드하고 토큰으로 구현하고, 기획자는 어떤 텍스트가 반드시 읽혀야 하는지(크기·대비 필수)를 명시해야 합니다. KRDS가 Figma·GitHub 킷·가이드라인을 한 세트로 제공하는 것도 세 팀이 같은 기준을 보게 하려는 의도입니다. ViewCheck 리포트를 공통 채점표로 쓰면, "네 일/내 일" 논쟁 대신 "이 항목을 누가 언제 고칠지"로 대화가 바뀝니다.

Q. 첨부 문서(PDF·한글파일)의 서체도 점검 대상인가요?

이 글의 초점은 웹 화면의 서체이지만, 공공 서비스에서 첨부 문서도 무시할 수 없는 영역입니다. 본문 정보를 PDF·한글파일로만 제공하고 웹 본문에는 요약조차 없으면, 그 첨부를 열기 어려운 사용자(모바일·보조기술 사용자 등)는 정보에서 배제됩니다. 원칙은 "핵심 정보는 웹 본문에 실제 텍스트로 제공하고, 첨부는 보조 수단으로 둔다"입니다. 첨부 자체의 접근성(문서 내 제목 구조·대체 텍스트 등)도 별도 점검이 필요하지만, 적어도 웹 본문이 표준 서체로 또렷하게 핵심을 담고 있어야 첨부를 못 여는 사용자도 최소한의 정보를 얻습니다.

점검했다면, 무엇부터 고칠까 — 우선순위

ViewCheck로 돌려 보면 서체 관련 문제가 한두 개로 끝나지 않는 경우가 많습니다. 그래서 우선순위가 중요합니다. 서체 문제를 심각도 순으로 정리하면 대략 이렇습니다.

가장 먼저(치명적) — 폰트가 아예 로드되지 않아 표준 서체가 전혀 적용되지 않는 경우, 그리고 본문이 너무 작거나 대비가 부족해 읽기 자체가 어려운 경우. 이건 사이트 전체에 균일하게 영향을 주고, 특히 고령·저시력 사용자에게 직접적인 장벽이라 1순위입니다. 폰트 로드 한 줄을 고치는 것만으로 사이트 전체가 한 번에 표준으로 바뀌는, 가성비 최고의 수정이기도 합니다.

그다음(높음) — 시각적 제목이 코드 위계(제목 태그)로 표현되지 않은 경우, 확대(200%)에서 글자가 깨지는 경우. 작동은 하지만 스크린리더 사용자와 저시력 사용자에게 실질적 장벽입니다.

그 후(보통) — 굵기를 위계 없이 쓰는 것, 모바일에서 위계가 평평해지는 것, 토큰 대신 매직넘버를 쓰는 것. 사용은 가능하지만 일관성과 유지보수, 특정 상황의 가독성에 영향을 줍니다.

여력이 되면(낮음) — 폰트 로딩 깜빡임(FOUT) 최적화, 자간 미세 조정 같은 마감 품질. 접근성을 막는 건 아니지만 경험과 성능을 한 단계 끌어올리는 항목입니다.

ViewCheck 리포트는 이 우선순위(P0~P3)를 자동으로 매겨 주기 때문에, "눈에 거슬리는 것부터"가 아니라 "사용자를 가장 많이 막는 것부터" 순서대로 처리할 수 있습니다. 한정된 인력과 일정 안에서 가장 효과 큰 개선에 집중하는 게 핵심입니다.

더 깊이 확인하려면 — 공식 자료 안내

이 글은 KRDS의 서체 기준을 실무·점검 관점에서 풀어 쓴 것입니다. 정확한 원문 기준과 코드·디자인 자산은 아래 공식 자료에서 직접 확인하실 수 있습니다.

• KRDS 공식 스타일 페이지(타이포그래피) — Pretendard GOV의 굵기 운영과 위계 예시를 화면으로 확인.
• KRDS 가이드라인 PDF(디지털 정부서비스 UI/UX 가이드라인, 2025.08판) — 타이포그래피 정의와 사용 원칙의 1차 원천.
• KRDS 컴포넌트 킷(GitHub) — 폰트와 타이포그래피 토큰을 코드로 제공(npm install krds-uiux 또는 CDN krds.min.css/krds.min.js).
• KRDS 공식 Figma(@krds) — 디자이너용 텍스트 스타일(제목/본문/캡션 등).

공식 자료는 "정답지"이고, ViewCheck는 "내 답안을 채점해 주는 도구"라고 생각하시면 됩니다. 둘을 함께 쓰면, 기준을 이해하고(가이드라인) → 내 사이트가 그 기준에 맞는지 확인하고(ViewCheck) → 검증된 토큰·폰트로 고치는(킷) 한 바퀴가 완성됩니다.

오늘의 체크리스트 — 서체, 이것만은

마지막으로, 디자이너·개발자·기획자가 서체를 만들거나 검수할 때 바로 쓸 수 있는 체크리스트로 정리합니다.

• ☐ 본문·제목·버튼·라벨의 기본 글꼴이 Pretendard GOV로 지정돼 있다.
• ☐ 그 폰트가 실제로 로드된다(이름만 적고 안 불러온 "유령 서체"가 아니다 — 폰트 안 깔린 깨끗한 환경에서 확인).
• ☐ font-family의 fallback 순서가 합리적이다(표준 → 한글 대체 → sans-serif).
• ☐ 제목·소제목·본문·캡션의 위계가 명확하고, 가능하면 토큰으로 관리한다(매직넘버 남발 아님).
• ☐ 굵기(Regular/Medium/Bold)를 역할로 쓴다(같은 종류 텍스트는 같은 굵기).
• ☐ 본문 글자 크기가 충분하다(16px 안팎, 13px 이하 본문 없음).
• ☐ 본문 글자색과 배경의 대비가 충분하다(일반 텍스트 4.5:1 이상).
• ☐ 시각적 제목이 코드 위계(h1~h6)로도 표현돼 있다(보이는 위계 = 읽히는 위계).
• ☐ 글자를 200% 확대해도 잘리거나 겹치지 않는다(상대 단위·여유 레이아웃).
• ☐ 모바일에서도 본문이 충분히 크고 제목/본문 위계가 유지된다(3개 뷰포트 확인).
• ☐ 이미지로 박은 텍스트를 최소화하고, 사이트 내 서체가 일관된다.
• ☐ 폰트 로딩 전환(FOUT/FOIT)이 매끄럽다(font-display·preload·fallback 처리).

KRDS 컴포넌트 킷(npm install krds-uiux 또는 CDN)을 쓰면 위 항목 대부분이 이미 구현된 상태로 시작할 수 있습니다. 폰트 로드와 타이포그래피 토큰이 함께 들어 있어, 직접 만들다 빠뜨릴 위험을 크게 줄일 수 있죠. 공식 Figma 라이브러리(@krds)에서는 디자이너가 텍스트 스타일을 그대로 가져다 쓸 수 있습니다.

서체는 화면에서 가장 작아 보이지만, 가장 넓은 면적을 차지하고 가장 많은 사용자에게 닿습니다. 본문 글꼴 하나가 표준에서 벗어나면 그 어긋남이 사이트의 모든 문장에 퍼지고, 본문이 조금만 작거나 흐려도 누군가는 그 안내문을 끝까지 못 읽습니다. 우리가 무심코 넘긴 폰트 설정 한 줄이, 누군가에게는 자격 요건을 읽고 신청을 마칠 수 있느냐 없느냐를 가릅니다.

오늘 정리한 기준이 많아 보일 수 있지만, 핵심은 단순합니다. 표준 서체를 실제로 깔고, 본문을 충분히 크고 또렷하게 하고, 위계를 토큰으로 일관되게 쓰고, 확대·모바일에서도 안 무너지게 하는 것. 이 네 가지만 챙겨도 서체 위반의 대부분은 사라집니다. 그리고 그게 잘 됐는지는 ViewCheck로 5분이면 확인할 수 있습니다. 완벽을 한 번에 만들 필요는 없습니다. 가장 효과 큰 "폰트 로드 한 줄"부터 손보면, 우리 사이트는 분명히 조금씩 더 많은 사람에게 읽힙니다. 다음 글에서는 서체와 짝을 이루는 또 다른 디자인 시스템 요소를 같은 방식으로 뜯어보겠습니다.

우리 사이트의 서체는 지금 표준을 지키고 있을까요? krds.viewcheck.co.kr에서 URL만 넣으면 무료로 확인할 수 있습니다. 디자인 시스템 탭의 토큰 채택률 한 줄만 봐도, 위 체크리스트가 실제로 지켜지고 있는지 바로 드러납니다.

#KRDS #공공웹 #디자인시스템 #PretendardGOV서체 #웹접근성 #ViewCheck #정부웹사이트 #UIUX #타이포그래피 #디자인토큰 #가독성 #공공디자인 #서체 #자가진단 #체크리스트 #점검항목 #디자인스타일 #전자정부 #디지털정부 #행정안전부