ViewCheck 기술 블로그

047편 : 함께 사용이 되는 비슷한 크기의 구성 요소는 래디어스 값을 동일하게 적용하고 있다.

ViewCheck — Tue, 29 Sep 2026 14:00:57 +0900

047편 : 함께 사용이 되는 비슷한 크기의 구성 요소는 래디어스 값을 동일하게 적용하고 있다.

KRDS 체크리스트 항목 DS-047 · 디자인 스타일 > 형태 〈846 규칙 완전 분해 시리즈 ㊼〉 — "나란히 있는 것들은 둥글기를 맞춰라": 형태의 일관성

0. 들어가며 — 함께 있는 것들의 조화

레디어스의 단계·범위·천장·단위를 봤습니다. 이번 47편은 레디어스의 일관성 — 특히 '함께 있는 비슷한 요소끼리 둥글기를 맞추라'는 규칙입니다.

화면에는 비슷한 요소들이 나란히 놓이는 경우가 많습니다. 버튼 여러 개가 한 줄에, 카드 여러 개가 그리드에, 입력칸 여러 개가 폼에. 그런데 이 나란한 요소들의 둥글기가 제각각이면 — 한 버튼은 4px, 옆 버튼은 8px이면 — 미묘하게 어긋나 보입니다. DS-047은 이런 경우 둥글기를 동일하게 맞추라고 규정합니다. 이번 편은 왜 함께 있는 요소들의 둥글기를 맞춰야 하는지를 풀어냅니다.

1. 규칙 원문 — 동일 적용

DS-047 (디자인 스타일 > 형태) "함께 사용이 되는 비슷한 크기의 구성 요소는 래디어스 값을 동일하게 적용하고 있다."

"함께 사용되는 비슷한 크기의 구성 요소"

한 화면·영역에 나란히 놓이는, 크기가 비슷한 요소들입니다. 한 줄의 버튼들, 그리드의 카드들 등이죠.

"래디어스 값을 동일하게"

그 요소들의 둥글기를 같게 맞추라는 뜻입니다.

정리: 나란히 있는 비슷한 크기 요소들은 둥글기를 동일하게 맞춰라. 이게 DS-047입니다.

2. 왜 동일하게 — 미세한 불일치가 주는 불편

함께 있는 요소의 둥글기가 다르면 왜 문제일까요? 사람 눈은 나란히 놓인 것들의 미세한 차이를 민감하게 감지하기 때문입니다.

버튼 두 개가 나란히 있는데 하나는 모서리가 더 둥글고 하나는 덜 둥글면, 명확히 '뭔가 안 맞는다'는 느낌이 듭니다. 무엇이 다른지 정확히 짚지 못해도, 정돈되지 않은 인상을 받죠. 이는 줄을 맞춰 선 사람들 중 한 명만 삐딱하게 서 있으면 즉시 눈에 띄는 것과 같습니다. 비교 대상이 바로 옆에 있으면 작은 차이도 크게 보입니다.

반대로 나란한 요소들의 둥글기가 같으면, 그들이 '한 세트'로 보이고 정돈된 느낌을 줍니다. 같은 종류의 요소라는 시각적 신호이기도 하죠. 둥글기의 일관성은 요소들을 '하나의 그룹'으로 묶어, 화면에 질서를 부여 합니다. 이는 43편(5단계 체계화)의 구체적 적용입니다 — 단계가 정의돼 있어도, 같은 종류 요소에 같은 단계를 일관되게 써야 비로소 일관성이 완성됩니다.

3. '비슷한 크기'라는 조건의 의미

DS-047은 '비슷한 크기'의 요소끼리 맞추라고 합니다. 이 조건이 중요합니다.

크기가 비슷한 요소(같은 줄의 버튼들)는 같은 둥글기여야 합니다. 하지만 크기가 크게 다른 요소(작은 태그 vs 큰 카드)는 둥글기가 달라도 됩니다 — 오히려 크기에 맞는 다른 단계를 써야 자연스럽죠(43편). 즉 '무조건 다 같게'가 아니라, '비슷한 크기끼리 같게' 입니다.

이는 43편에서 본 '컴포넌트 크기 기준 단계'와 일관됩니다. 작은 요소는 작은 단계, 큰 요소는 큰 단계를 쓰되, 같은 크기 그룹 안에서는 동일 단계로 통일하는 것이죠. 작은 버튼들끼리는 같은 둥글기, 큰 카드들끼리는 같은 둥글기. 크기 그룹별로 일관성을 유지하는 것입니다. 그래서 DS-047은 '크기를 무시하고 다 같게'가 아니라 '크기 그룹 안에서 일관되게'라는 정교한 규칙입니다.

4. 흔한 위반 패턴 / 점검 / 개선

흔한 위반 패턴

함정 ① 나란한 요소 불일치. 한 줄 버튼들의 둥글기가 다름 → 어긋나 보임. → 동일 적용. 함정 ② 같은 카드 다른 둥글기. 그리드 카드들이 제각각 → 부조화. → 통일. 함정 ③ 단계 오적용. 같은 크기인데 다른 단계 → 일관성 붕괴. → 같은 단계.

무엇을 점검하나

나란한 요소 — 함께 놓인 비슷한 요소가 같은 둥글기인가.
그룹 일관성 — 같은 종류·크기 그룹이 통일됐는가.
크기별 구분 — 크기가 다른 그룹은 적절히 다른 단계인가.

Before / After

/* ❌ Before: 나란한 버튼들의 둥글기 불일치 */
.btn-submit { border-radius: 8px; }
.btn-cancel { border-radius: 4px; }   /* 옆 버튼인데 다름 */

/* ✅ After: 동일 적용 */
.btn { border-radius: var(--radius-3); }  /* 모든 버튼 동일 */
.card { border-radius: var(--radius-4); } /* 모든 카드 동일(버튼과는 다른 단계) */

5. 누가 담당하나 / 우리 사이트에 해당될까?

역할	책임
디자이너	같은 종류·크기 요소에 동일 레디어스 설계
퍼블리셔/개발	요소 종류별 레디어스 토큰 일관 적용

기관 유형	DS-047 적용
중앙행정기관(대표·운영) / 공공기관 / 지자체	✅ 필수

비슷한 요소가 나란히 놓이는 모든 사이트 = 해당.

6. 30초 자가진단 + FAQ

✅ 30초 자가진단

□ 나란한 버튼들의 둥글기가 같은가요?
□ 그리드의 카드들이 같은 둥글기인가요?
□ 같은 종류 요소에 같은 레디어스 단계를 쓰나요?
□ 크기가 다른 그룹은 적절히 다른 단계인가요?

❓ FAQ

Q1. 모든 요소의 둥글기를 다 같게 하라는 건가요? 아닙니다. '비슷한 크기'끼리 같게 하라는 것입니다. 작은 태그와 큰 카드는 크기가 다르니 다른 단계를 써도 됩니다(43편). 같은 크기 그룹 안에서 통일하는 것이 핵심입니다.

Q2. 강조 버튼과 일반 버튼의 둥글기도 같아야 하나요? 크기가 비슷하면 같은 둥글기가 좋습니다. 강조는 색·두께로 하고, 형태(둥글기)는 통일하는 것이 정돈된 인상을 줍니다.

Q3. 토큰을 쓰면 자동으로 되나요? 요소 종류별로 레디어스 토큰을 정해 쓰면(.btn=radius-3 등) 자동으로 일관됩니다. 화면마다 값을 하드코딩하면 불일치가 생깁니다. 토큰 사용이 일관성의 핵심입니다.

Q4. KRDS를 채택하면 자동인가요? KRDS 컴포넌트는 종류별로 일관된 레디어스가 적용돼 있습니다. 채택하면 DS-047이 충족됩니다.

7. 마무리 — 나란한 것들의 조화

DS-047의 메시지는 일관성의 가치를 담습니다.

함께 있는 비슷한 요소들은 둥글기를 맞춰야 한다 — 나란히 놓인 것들의 미세한 불일치가 정돈을 깬다.

사람 눈은 나란히 놓인 것들의 작은 차이를 민감하게 감지합니다. 함께 있는 비슷한 요소의 둥글기가 다르면 어긋나 보이고, 같으면 '한 세트'로 정돈되어 보입니다. 이는 43편의 5단계 체계가 실제 화면에서 일관성으로 완성되는 지점이죠. 크기 그룹 안에서 둥글기를 통일하는 것 — 그 작은 일관성이 정돈된 화면을 만듭니다.

다음 편은 컨테이너 크기와 레디어스의 관계를 다룹니다. DS-048 — "컨테이너 사이즈가 커지면 래디어스 값도 비율에 맞게 적용한다." 요소가 커질 때 둥글기를 어떻게 조정하는지를 살펴봅니다.

다음 편 예고 ▶ 「048. 컨테이너 사이즈가 커지면 래디어스 값도 비율에 맞게 적용하고 있다.」

우리 사이트의 레디어스가 일관된지 확인하려면? ViewCheck는 함께 놓인 비슷한 요소들이 동일한 레디어스를 갖는지, 같은 종류 요소가 일관되게 적용됐는지를 진단합니다.

참고 출처

KRDS 형태(Shape)·디자인 토큰 가이드 — https://www.krds.go.kr/html/site/style/style_07.html

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

운영기관 식별자(Identifier) 완전 해부 - KRDS 공식 기준

ViewCheck — Tue, 29 Sep 2026 10:00:58 +0900

운영기관 식별자(Identifier) 완전 해부 - KRDS 공식 기준

공공 사이트에 처음 들어갔을 때, 우리는 무의식중에 화면 맨 위 왼쪽 구석을 봅니다. 거기 무엇이 있는지 정확히 의식하지는 않지만, 눈은 자동으로 그쪽을 훑죠. 거기에 기관의 이름과 마크가 있으면 "아, 여기가 ○○부 사이트구나" 하고 안심하고 본론으로 들어갑니다. 그런데 가끔, 그 자리에 아무것도 없거나, 마크는 있는데 무슨 기관인지 도무지 알 수 없거나, 클릭해도 아무 일도 일어나지 않는 경우를 만납니다. 그 순간 우리는 미세하게 불안해집니다. "여기 진짜 정부 사이트 맞아? 혹시 사칭 사이트 아니야?"

운영기관 식별자(Identifier)는 바로 그 자리에 있는 컴포넌트입니다. 화면 맨 위, 보통 왼쪽에 자리 잡은 "이 사이트를 누가 운영하는지"를 알리는 영역. 기관 마크(심볼·로고), 기관명, 그리고 대개 홈으로 돌아가는 링크가 한 덩어리로 묶인 것. 우리는 이걸 그냥 "로고 자리"라고 부르며 대수롭지 않게 여기지만, 사실 이 작은 영역은 공공 서비스의 신뢰가 시작되는 출발점입니다. 사용자가 화면에서 가장 먼저 보고, 가장 먼저 판단하는 곳이거든요.

현업에서 보면, 운영기관 식별자는 "디자인 다 끝나고 마지막에 로고 이미지 하나 얹는 자리" 취급을 받는 경우가 많습니다. 기획서에는 "헤더 좌측에 기관 로고"라고 한 줄 적히고, 디자인에서는 가져온 로고 이미지를 적당한 크기로 배치하고, 개발에서는 <img> 태그 하나로 끝냅니다. 이 과정 어디에서도 "이 마크가 스크린리더로 어떻게 읽히나", "키보드로 홈에 갈 수 있나", "어두운 배경에서도 보이나", "기관명이 텍스트로 존재하나"를 따지지 않습니다. 그 결과가 우리가 종종 마주치는, 정체불명의 헤더 로고들입니다.

이 글에서는 KRDS(대한민국 정부 디자인 시스템)가 운영기관 식별자를 어떻게 정의하고 무엇을 요구하는지를, 공식 가이드라인과 컴포넌트 킷을 기준으로 하나하나 뜯어보겠습니다. "이렇게 하면 멋지다"가 아니라 "정부 표준은 이걸 요구한다"는 사실 기준으로요. 그리고 그 기준을 우리 사이트가 실제로 지키고 있는지 어떻게 확인하는지까지 이어가겠습니다. 다 읽고 나면, 앞으로 어떤 공공 사이트에 들어가든 맨 위 왼쪽 구석을 보며 "이 기관은 자기를 제대로 밝히고 있군" 혹은 "여기는 위험하게 만들었네"가 눈에 들어오실 겁니다.

운영기관 식별자가 대체 뭘까 — 정의부터 정확히

먼저 용어부터 맞추겠습니다. "식별자(Identifier)"라는 말이 개발자에게는 변수 이름이나 데이터베이스 키처럼 들릴 수 있지만, KRDS에서 말하는 식별자는 그게 아닙니다. 여기서의 식별자는 **"이 디지털 서비스를 어느 기관이 운영하는지 사용자에게 분명히 알리는 시각적·구조적 영역"**을 뜻합니다. 영어 원문도 그냥 Identifier이고, 미국·영국 등 다른 나라의 정부 디자인 시스템에도 비슷한 개념이 있습니다. 공공 서비스라면 "누가 책임지고 운영하는가"를 명확히 밝혀야 한다는 보편적 원칙에서 나온 컴포넌트입니다.

운영기관 식별자를 구성하는 요소를 풀어 보면 대략 이렇습니다.

기관 마크(심볼/로고): 기관을 시각적으로 대표하는 그래픽. 부처 상징, 지자체 엠블럼, 공공기관 로고 등.
기관명(텍스트): 마크 옆이나 아래에 따라붙는 기관의 정식 명칭. "○○부", "○○시", "○○공단" 같은 글자.
홈 링크: 식별자 전체(또는 마크)를 누르면 그 사이트의 메인 화면으로 돌아가는 링크. 사용자가 길을 잃었을 때 "원점으로" 돌아오는 가장 보편적인 출구입니다.

이 세 가지가 한 덩어리로 묶여, 보통 화면 최상단의 헤더 왼쪽에 자리합니다. 모양은 단순해 보이지만, 이 안에는 "신뢰", "탐색", "접근성"이라는 세 가지 무거운 책임이 동시에 담겨 있습니다.

여기서 흔히 헷갈리는 게 "그럼 푸터(맨 아래)에 있는 기관 정보랑 뭐가 다르지?"입니다. 다릅니다. 푸터의 기관 정보는 주소·전화번호·사업자등록번호·저작권 표시처럼 "법적·행정적 식별 정보"에 가깝습니다. 반면 헤더의 운영기관 식별자는 사용자가 화면에 들어서자마자 가장 먼저 마주하는 "시각적 정체성"입니다. 둘 다 "이 사이트는 누구 것인가"를 알리지만, 하나는 화면의 얼굴이고 하나는 화면의 명함입니다. 이 글에서 다루는 건 주로 헤더의 얼굴 쪽입니다. 다만 두 영역의 기관명이 서로 다르거나, 한쪽에만 있고 다른 쪽엔 없으면 사용자는 혼란스러워하니, 둘의 일관성도 함께 챙겨야 합니다.

왜 KRDS가 이걸 별도 컴포넌트로 떼어냈나

KRDS는 헤더 안의 수많은 요소 중에서도 운영기관 식별자를 별도 컴포넌트로 분리해 정의합니다. 그냥 "헤더 디자인 알아서 하세요"가 아니라 "운영기관을 밝히는 이 부분만큼은 표준을 따르세요"라고 떼어 둔 거죠. 이게 메시지입니다. 헤더에는 검색창도 있고 메뉴도 있고 로그인 버튼도 있지만, 그중에서 "기관 정체성"은 별도로 관리할 만큼 중요하다는 뜻입니다.

KRDS 공식 가이드 화면

생각해 보면 당연합니다. 정부 서비스를 사칭하는 피싱 사이트가 끊이지 않는 시대에, "이 사이트가 진짜 그 기관 것이 맞는가"를 사용자가 빠르고 확실하게 판단할 수 있어야 합니다. 운영기관 식별자가 일관된 위치에, 일관된 방식으로, 명확하게 표시되면 사용자는 "정부 사이트는 다 이렇게 생겼지"라는 학습된 기대를 갖게 됩니다. 그 기대에 맞으면 신뢰하고, 어긋나면 경계합니다. 표준화된 식별자는 그래서 단순한 디자인 통일이 아니라, 사회 전체의 보안 인프라이기도 합니다.

KRDS는 운영기관 식별자에 무엇을 요구하나 — 기준 완전 해부

이제 본론입니다. KRDS 가이드라인(디지털 정부서비스 UI/UX 가이드라인, 2025.08판)과 컴포넌트 문서를 기준으로, 운영기관 식별자가 충족해야 하는 요건을 영역별로 정리하겠습니다. 작은 영역이지만 따져야 할 게 생각보다 많습니다.

1) 위치 — 정해진 자리에 있어야 한다

운영기관 식별자의 첫 번째 요건은 위치입니다. 사용자는 "기관 로고는 화면 맨 위 왼쪽에 있다"는 강한 학습된 기대를 가지고 있습니다. 이건 한국 사이트만의 관습이 아니라 전 세계 웹의 보편적 패턴입니다. 그래서 식별자를 헤더 좌측이라는 예측 가능한 자리에 두는 것 자체가 사용성의 일부입니다.

이 자리를 임의로 가운데나 오른쪽으로 옮기거나, 다른 요소(거대한 검색창, 배너 등)에 밀려 잘 보이지 않게 만들면 사용자는 "여기가 어디지?"부터 헤매게 됩니다. 위치는 사소해 보이지만, 첫 화면에서 사용자의 시선이 가장 먼저 닿는 곳이라 영향이 큽니다. KRDS가 헤더 구조를 표준화하는 이유 중 하나가 바로 이 "예측 가능성"입니다.

2) 기관 마크 — 이미지가 아니라 "의미"로 다뤄라

운영기관 식별자의 핵심은 기관 마크입니다. 그런데 여기서 가장 많이 실수하는 게, 이 마크를 그저 "이미지 파일 하나"로 다루는 것입니다.

웹 표준으로 말하면, 기관 마크가 이미지(<img>)일 때는 반드시 대체 텍스트(alt)가 있어야 합니다. 그것도 의미 있는 대체 텍스트여야 하죠. alt="logo"나 alt="이미지"처럼 무의미하게 적거나, 아예 비워 두면 안 됩니다. 스크린리더 사용자에게는 이 마크가 "어느 기관 사이트인지"를 알리는 유일한 단서이기 때문입니다. 올바른 대체 텍스트는 alt="○○부"처럼 기관명 그 자체입니다.

만약 마크가 SVG로 들어가 있다면, role="img"과 aria-label 또는 <title> 요소로 이름을 부여해야 합니다. 어떤 방식이든 핵심은 같습니다 — 눈으로 보면 알 수 있는 정보(어느 기관)가 코드로도 전달돼야 한다는 것. 마크가 아무리 멋지게 디자인돼 있어도, 코드가 그 의미를 담고 있지 않으면 화면을 못 보는 사용자에게는 존재하지 않는 것과 같습니다.

3) 기관명 텍스트 — 마크에만 의존하지 마라

마크에 대체 텍스트를 넣는 것과 별개로, 기관명이 실제 텍스트로 화면에 존재하는 것이 더 안전합니다. 마크 이미지 안에 기관명이 그림으로 박혀 있고 화면에 따로 텍스트가 없으면, 몇 가지 문제가 생깁니다.

첫째, 검색엔진이 기관명을 텍스트로 인식하기 어려워 검색 노출에 불리합니다. 둘째, 사용자가 화면을 확대했을 때 그림 속 글자는 흐려지지만 실제 텍스트는 또렷하게 커집니다. 셋째, 이미지 로딩이 실패하면 그림 속 기관명은 사라지지만, 텍스트는 남아 있습니다. 그래서 KRDS는 마크와 함께 기관명을 텍스트로 병기하는 구조를 권장합니다. 마크는 시각적 인상을, 텍스트는 명확한 정보를 담당하는 역할 분담인 셈입니다.

이때 마크와 기관명 텍스트가 둘 다 스크린리더에 읽히면 중복이 되니, 처리에 주의해야 합니다. 보통은 마크 이미지를 alt=""(빈 대체 텍스트)나 aria-hidden으로 장식 처리하고 옆의 텍스트로 이름을 전달하거나, 반대로 텍스트를 시각적으로만 두고 이미지에 대체 텍스트를 주는 식으로 한 번만 읽히게 정리합니다. 핵심은 "기관명이 코드로 한 번은 명확히 전달되되, 두 번 중복해서 읽히지는 않게"입니다.

4) 홈 링크 — 클릭하면 메인으로

운영기관 식별자는 거의 항상 홈으로 가는 링크 역할을 겸합니다. 이건 웹의 오래된 관습이라, 사용자는 "로고를 누르면 첫 화면으로 돌아간다"를 자연스럽게 기대합니다. 그래서 식별자를 누르면 그 사이트의 메인 페이지로 이동해야 합니다.

여기서 챙길 점이 몇 가지 있습니다. 우선 링크가 진짜 링크(<a>)여야 합니다. <div>에 클릭 이벤트만 붙여 만들면 키보드로 도달할 수 없고 스크린리더가 링크로 인식하지 못합니다. 그리고 이 링크에는 "○○부 홈" 또는 "메인으로"처럼 어디로 가는지 알 수 있는 접근 가능한 이름이 있어야 합니다. 단순히 마크 이미지의 대체 텍스트가 기관명이면, 스크린리더는 "○○부, 링크"라고 읽어 주고 사용자는 "아 누르면 홈에 가겠구나" 하고 짐작할 수 있습니다.

또 하나, 메인 페이지에서는 이 홈 링크가 "현재 페이지를 가리키는 링크"가 됩니다. 이미 홈에 있는데 홈 링크가 평범하게 활성화돼 있으면 약간 어색하죠. 그래서 현재 위치를 알리는 처리(aria-current="page" 등)를 더하면 더 친절합니다. 다만 이건 권장 사항이고, 최소한 "로고 누르면 홈으로 간다"는 동작은 반드시 작동해야 합니다.

5) 키보드 접근 — 마우스 없이도 홈으로

홈 링크가 진짜 링크라면 키보드 접근은 대체로 따라옵니다. Tab으로 식별자에 초점이 가고, Enter로 홈으로 이동할 수 있어야 합니다. 그리고 초점이 왔을 때 시각적으로 또렷하게 표시(포커스 링)돼야 합니다. 헤더 맨 앞의 로고는 보통 Tab 순서상 가장 먼저 만나는 요소 중 하나라, 키보드 사용자가 페이지를 탐색하기 시작하는 출발점이기도 합니다. 그런데 디자인이 깔끔해 보인다고 outline: none으로 포커스 표시를 지워 버리면, 키보드 사용자는 자기가 로고에 와 있는지 알 수 없습니다. 작은 영역이라고 포커스 표시를 생략하는 실수가 여기서도 반복됩니다.

6) 색상과 대비 — 어떤 배경에서도 보여야

기관 마크와 기관명은 배경과 충분한 명도 대비를 가져야 합니다. 특히 헤더 배경색을 진하게(예: 짙은 남색, 검정) 쓰는 경우, 어두운 색의 로고를 그대로 얹으면 거의 안 보입니다. 그래서 어두운 배경용 흰색(반전) 버전 로고를 별도로 준비하는 게 보통입니다. 저시력·고령 사용자에게는 이 대비가 "기관을 인지할 수 있느냐"를 가르는 문제입니다.

또 스크롤에 따라 헤더 배경이 투명→불투명으로 바뀌는 디자인이라면, 모든 상태에서 로고가 명확히 보이는지 확인해야 합니다. 배너 이미지 위에 헤더가 겹쳐지는 경우, 배경 이미지에 따라 로고가 묻히지 않도록 그림자나 반투명 박스를 받쳐 주는 처리가 필요할 때도 있습니다.

7) 크기와 터치 영역 — 작아도 누를 수 있어야

로고가 작게 디자인되더라도, 그것이 누를 수 있는 링크라면 터치/클릭 영역은 충분해야 합니다. 한국형 웹 접근성 지침(KWCAG)과 국제 표준 모두 터치 대상의 최소 크기를 권장하는데, 일반적으로 한 변 44px 이상을 기준으로 봅니다. 작은 마크 그림 자체는 작아도, 그것을 감싸는 링크 영역은 손가락으로 정확히 누를 수 있을 만큼 여유가 있어야 합니다. 특히 모바일에서 로고가 너무 작으면 홈으로 돌아가려다 옆의 메뉴 버튼을 잘못 누르기 쉽습니다.

8) 반응형 — 화면 크기에 따라 적절히

데스크톱에서는 마크+기관명을 나란히 다 보여 주다가, 좁은 모바일 화면에서는 공간이 부족해 마크만 남기거나 기관명을 줄이는 경우가 많습니다. 이 자체는 자연스러운 반응형 처리입니다. 다만 모바일에서 기관명 텍스트를 숨기더라도, 접근 가능한 이름(대체 텍스트나 aria-label)은 그대로 남아 있어야 합니다. 시각적으로 글자를 안 보이게 한 것과, 코드에서 정보를 지워 버린 것은 전혀 다릅니다. 화면에서 기관명이 사라졌다고 스크린리더에서도 "어느 기관인지 모름" 상태가 되면 안 됩니다.

9) 일관성 — 사이트 전체에서 같은 모습

운영기관 식별자는 사이트의 모든 페이지에서 같은 위치, 같은 모습, 같은 동작을 유지해야 합니다. 메인 페이지의 로고와 하위 신청 페이지의 로고가 다르게 생겼거나, 어떤 페이지는 홈 링크가 되는데 어떤 페이지는 안 되거나 하면 사용자는 혼란스럽습니다. 이 일관성이 깨지는 대표적인 경우가, 별도 시스템으로 만든 하위 서비스(예: 외부 위탁 개발한 민원 신청 시스템)가 본 사이트와 헤더를 다르게 쓰는 상황입니다. 사용자 입장에서는 같은 기관 서비스인데 갑자기 다른 곳에 온 듯한 단절을 느끼게 됩니다.

정리하면, KRDS의 운영기관 식별자 기준은 크게 세 축으로 모입니다. ① 신뢰성(정해진 위치에 명확한 기관 마크와 이름), ② 접근성(마크의 대체 텍스트, 진짜 링크, 키보드 접근, 충분한 대비·크기), ③ 일관성(사이트 전체에서 같은 모습·동작, 헤더-푸터 정보 일치). 이 세 축은 그대로 ViewCheck가 식별자를 점검하는 기준이기도 합니다.

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

여기까지 읽고 "로고 자리 하나에 뭐 이리 까다롭나" 싶으실 수 있습니다. 그런데 이 요건들은 누가 괜히 만들어 낸 규칙이 아니라, 실제 사용자가 막히거나 위험에 빠지는 지점에서 역으로 도출된 것들입니다.

신뢰는 첫 화면의 왼쪽 위에서 시작된다

사용자가 어떤 사이트를 신뢰할지 말지는 놀랄 만큼 빠르게 결정됩니다. 화면이 뜨고 몇 초 안에, 무의식적으로요. 그 짧은 순간에 가장 강력하게 작동하는 신호 중 하나가 "이 사이트가 누구 것인지 명확히 밝히고 있는가"입니다. 맨 위 왼쪽에 또렷한 기관 마크와 이름이 있으면 사용자는 "공식 사이트구나" 하고 마음을 놓습니다. 반대로 그 자리가 비어 있거나 모호하면, 사용자는 의식하지 못한 채 경계 태세에 들어갑니다.

이건 단순한 심리가 아니라 보안과 직결됩니다. 정부·공공기관을 사칭한 피싱 사이트는 대체로 디테일에서 어설픕니다. 로고가 흐릿하거나, 기관명이 어색하거나, 홈 링크가 작동하지 않거나 합니다. 진짜 공공 사이트가 운영기관 식별자를 표준에 맞게 또렷하고 일관되게 표시할수록, 사용자는 "진짜와 가짜의 차이"를 직관적으로 느끼게 됩니다. 그래서 식별자를 제대로 만드는 일은 그 기관 하나의 문제가 아니라, 공공 서비스 전체의 신뢰 자산을 지키는 일이기도 합니다.

공공 서비스는 "안 쓸 자유"가 없다

상업 사이트는 신뢰가 안 가면 사용자가 떠나면 그만입니다. 경쟁사로 가면 되니까요. 그런데 공공 서비스는 다릅니다. 주민등록 등본을 떼거나, 건강보험을 신청하거나, 세금을 내는 일은 그 사이트가 아니면 할 수 없습니다. 사용자가 "안 쓸 자유"가 없어요. 그래서 공공 웹의 식별자가 누군가에게 작동하지 않거나 모호하면, 그건 단순한 불편이 아니라 행정 서비스 접근권의 문제가 됩니다.

기관 마크에 대체 텍스트가 없으면, 시각장애인은 자기가 어느 기관 사이트에 들어왔는지조차 알 수 없습니다. 여러 탭을 열어 두고 작업하는 상황이라면, 지금 어느 사이트에 있는지 확인할 길이 막막해지죠. 홈 링크가 키보드로 작동하지 않으면, 마우스를 못 쓰는 사용자는 길을 잃었을 때 원점으로 돌아오는 가장 기본적인 출구를 잃습니다. 이게 KRDS가 식별자의 접근성을 "있으면 좋은 것"이 아니라 "기본 요건"으로 두는 이유입니다.

보이는 것과 읽히는 것의 분리

비장애인은 화면을 "본다"고 생각하지만, 사실 우리는 화면을 보고 머릿속에서 의미로 번역합니다. 헤더 왼쪽의 그래픽을 보고 "아, ○○부 로고구나" 하고 알아채죠. 스크린리더 사용자에게는 이 짐작 과정이 없습니다. 코드가 알려 주는 정보가 곧 전부입니다.

그래서 기관 마크는 "보기에 로고 같은 것"으로는 부족하고, "코드 수준에서 어느 기관인지 선언된 것"이어야 합니다. 멋진 로고 이미지를 얹어도, 코드가 그걸 "○○부"라고 말해 주지 않으면 스크린리더에겐 그냥 의미 없는 그림 파일입니다. 이 "보이는 것 ≠ 읽히는 것" 문제가 식별자 위반의 근본 원인 대부분을 차지합니다. KRDS의 모든 컴포넌트 요건이 결국 "시각과 코드의 일치"라는 한 가지 원리로 수렴하는 셈입니다.

일관성이 곧 신뢰와 학습 비용 절감

KRDS가 식별자의 위치와 모습을 표준화하는 또 다른 이유는 일관성입니다. 정부 사이트마다 로고 위치와 동작이 제각각이면, 사용자는 사이트를 옮길 때마다 "여기선 어디가 홈이지?"를 다시 찾아야 합니다. 모든 공공 서비스의 식별자가 같은 자리에서 같은 방식으로 작동하면, 한 번 익힌 사용법이 모든 사이트에서 통합니다. 그리고 그 일관성 자체가 "이건 진짜 정부 사이트"라는 신뢰의 근거가 됩니다. 표준화는 디자이너의 자유를 뺏는 게 아니라, 사용자의 인지 부담을 덜고 신뢰를 쌓아 주는 일입니다.

한 장면 — 같은 헤더, 두 사람

추상적인 요건을 길게 늘어놓는 것보다, 한 장면을 그려 보는 게 빠를 것 같습니다. 어느 공공 서비스의 화면, 헤더 왼쪽에 기관 로고가 하나 있다고 합시다. 디자인이 깔끔하고, 마크도 세련됐습니다.

먼저 마우스를 쓰는 김 주무관. 화면에 들어서자마자 왼쪽 위 로고를 보고 "아, ○○공단이구나" 하고 안심합니다. 한참 하위 페이지를 헤매다 길을 잃자, 자연스럽게 로고를 클릭해 메인으로 돌아옵니다. 10초도 안 걸렸습니다. 김 주무관에게 이 식별자는 아무 문제가 없습니다. 그래서 이 화면을 만든 팀도 "잘 작동한다"고 믿습니다. 자기들이 테스트할 때 늘 마우스를 썼으니까요.

이번엔 시각장애가 있는 박 선생님. 여러 민원을 처리하느라 탭을 대여섯 개 열어 둔 상태입니다. 스크린리더로 한 탭에 들어가 헤더부터 훑는데, 로고 자리에서 "이미지"라고만 들립니다. 어느 기관 사이트인지 알 수 없습니다(대체 텍스트 누락). 일단 홈으로 돌아가 처음부터 보려고 그 자리에서 Enter를 눌렀는데, 아무 반응이 없습니다. 이 로고는 <div>에 클릭 이벤트만 붙인 가짜 링크라, 마우스 클릭에만 반응하거든요(키보드 미지원). 박 선생님은 지금 자기가 어느 사이트의 어디에 있는지조차 가늠하지 못한 채, 결국 브라우저 뒤로 가기로 헤매다 작업을 포기합니다.

같은 헤더, 같은 로고. 한 사람에겐 10초짜리 안심이고, 다른 한 사람에겐 정체불명의 미로 입구입니다. 그리고 이 차이는 "예산이 부족해서"나 "기술이 어려워서" 생긴 게 아닙니다. 그냥 만들 때 마우스로 보는 사용자만 떠올렸기 때문에 생긴 차이입니다. KRDS의 운영기관 식별자 요건은, 이 두 사람의 경험을 같게 만들기 위한 최소한의 약속입니다.

만약 이 팀이 KRDS 킷의 식별자 구조를 가져다 썼다면 어땠을까요. 박 선생님의 스크린리더는 "○○공단 홈, 링크"라고 읽었을 거고, Enter를 누르면 메인으로 돌아갔을 겁니다. 어느 사이트에 있는지 한 번에 알고, 길을 잃어도 원점으로 돌아오는 출구가 분명히 있었겠죠. 김 주무관과 똑같이 10초면 됐을 겁니다. 차이를 만드는 건 거창한 기술이 아니라, "검증된 구조를 쓰느냐"라는 작은 선택입니다.

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

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

실수 1) 대체 텍스트 없는(또는 무의미한) 기관 마크

가장 흔하고 가장 치명적인 실수입니다. 기관 로고 이미지에 alt가 비어 있거나, alt="logo", alt="이미지"처럼 무의미하게 적혀 있습니다.

나쁜 예: <img src="logo.png"> 또는 <img src="logo.png" alt="logo">. 스크린리더는 "이미지" 또는 "로고"라고만 읽음. 어느 기관인지 알 수 없음.
올바른 예: <img src="logo.png" alt="○○부">처럼 기관명을 대체 텍스트로. SVG라면 role="img" + aria-label="○○부" 또는 <title>○○부</title>.

실수 2) 가짜 홈 링크

로고를 누르면 홈으로 가긴 하는데, 그게 진짜 링크가 아니라 <div>에 자바스크립트 클릭 이벤트를 붙인 것입니다.

나쁜 예: <div onclick="location.href='/'">. 키보드 Tab으로 도달 불가, 스크린리더가 링크로 인식 못 함. 마우스로만 작동.
올바른 예: <a href="/" aria-label="○○부 홈">...</a>. 진짜 링크라 키보드·스크린리더 모두 지원되고, 어디로 가는지 이름도 명확.

실수 3) 기관명이 그림 속에만 있고 텍스트가 없음

마크 이미지 안에 기관명이 그림으로 박혀 있고, 화면에 실제 텍스트 기관명이 따로 없습니다.

나쁜 예: 기관명이 통째로 PNG 이미지. 확대하면 흐려지고, 검색엔진은 기관명을 텍스트로 못 읽고, 이미지 로딩 실패 시 기관명이 사라짐.
올바른 예: 마크는 마크대로 두고, 기관명을 실제 텍스트로 병기. 중복 낭독은 한쪽을 장식 처리해 막음.

실수 4) 어두운 배경에서 안 보이는 로고

헤더 배경을 진하게 깔아 두고, 어두운 색 로고를 그대로 얹습니다.

나쁜 예: 짙은 남색 헤더에 검정 계열 로고. 저시력 사용자는 거의 인지 못 하고, 일반 사용자도 흐릿하게 봄.
올바른 예: 배경에 맞는 반전(흰색) 로고를 준비하거나, 배경 대비를 충분히 확보. 스크롤·배너 위 겹침 상태에서도 보이는지 확인.

실수 5) 포커스 표시 제거

디자인 통일성을 위해 헤더 로고 링크의 포커스 링을 outline: none으로 지웁니다.

나쁜 예: 키보드로 페이지를 탐색하기 시작할 때 로고에 초점이 와도 표시가 안 보임. 어디서 시작했는지 알 수 없음.
올바른 예: 포커스 시 또렷한 테두리·외곽선 유지. 작은 영역이라도 텍스트 링크와 동일한 기준 적용.

실수 6) 모바일에서 너무 작은 터치 영역

데스크톱 기준으로 만들고 모바일을 확인하지 않아, 로고 링크가 손가락에 비해 작습니다.

나쁜 예: 모바일에서 로고가 너무 작아, 홈으로 가려다 옆 메뉴 버튼을 잘못 누름.
올바른 예: 로고를 감싸는 링크 영역을 충분히(약 44px 이상) 확보하고, 옆 요소와 간격도 여유 있게.

실수 7) 모바일에서 접근 가능한 이름까지 사라짐

좁은 화면에서 기관명 텍스트를 시각적으로 숨기는 것까지는 좋은데, 코드에서도 정보를 통째로 지워 버립니다.

나쁜 예: 모바일에서 기관명 텍스트를 DOM에서 제거하고 마크만 남겼는데, 그 마크엔 대체 텍스트도 없음. 스크린리더에 "어느 기관인지" 정보가 완전히 사라짐.
올바른 예: 화면에서는 기관명을 숨기더라도, 마크의 대체 텍스트나 링크의 aria-label로 기관명을 코드에 남겨 둠.

실수 8) 하위 시스템에서 식별자 단절

본 사이트와 외부 위탁 개발한 하위 시스템(민원 신청, 예약 등)의 헤더가 달라, 사용자가 같은 기관인데 다른 곳에 온 듯 느낍니다.

나쁜 예: 메인은 ○○시 식별자, 신청 시스템은 정체불명의 다른 헤더. 사용자가 "여기 맞나?" 불안.
올바른 예: 하위 시스템에도 동일한 운영기관 식별자를 일관되게 적용. 사용자가 끊김 없이 같은 기관 서비스임을 인지.

실수 9) 헤더와 푸터의 기관 정보 불일치

헤더의 기관명과 푸터의 기관명·운영주체가 서로 다릅니다(리뉴얼·조직 개편 후 한쪽만 갱신된 경우).

나쁜 예: 헤더는 새 기관명, 푸터는 옛 기관명. 사용자가 어느 게 맞는지 혼란.
올바른 예: 헤더·푸터의 운영기관 정보를 일치시키고, 변경 시 양쪽을 함께 갱신.

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

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

개발자라면 — KRDS 컴포넌트 킷을 npm install krds-uiux로 설치하거나 CDN(krds.min.css / krds.min.js)으로 불러올 수 있습니다. 저장소의 html/code 폴더에 헤더·운영기관 식별자 관련 마크업 구조가 들어 있어, 표준 구조로 시작할 수 있습니다. 핵심 습관은 단순합니다. 식별자를 **진짜 링크(<a href="/">)**로 감싸고, 그 링크나 마크 이미지에 기관명을 접근 가능한 이름으로 부여하고(alt="○○부" 또는 aria-label="○○부 홈"), 포커스 표시를 지우지 않는 것. 이 세 가지만 지켜도 식별자 접근성의 대부분이 해결됩니다. 한 번 공통 헤더 컴포넌트로 잡아 두면 모든 페이지에 자동으로 따라옵니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 헤더와 운영기관 식별자 영역을 컴포넌트로 가져다 쓸 수 있습니다. 직접 그리기보다 표준 컴포넌트를 배치하면, 위치·크기·여백·상태가 기준에 맞춰집니다. 그리고 어두운 배경용 반전 로고를 함께 준비하고, 로고의 최소 크기와 보호 여백(로고 주변에 다른 요소가 침범하지 않는 빈 공간)을 규정해 두세요. 시안과 실제 구현 사이의 간극도 줄어듭니다.

기획자라면 — 화면 정의서에 "헤더 좌측 로고"라고만 적지 말고, "운영기관 식별자(기관 마크 + 기관명 텍스트 + 홈 링크, 대체 텍스트=기관명, 모바일 시 마크만 노출하되 접근 가능한 이름 유지)"처럼 구성 요소와 동작·접근성 요건을 함께 명시하세요. 이 한 줄이 디자인·개발 단계의 누락을 막습니다. 그리고 헤더와 푸터의 운영기관 정보가 일치하는지, 하위 시스템에도 동일하게 적용되는지를 검수 항목에 넣어 두세요.

그래서 우리 사이트는? — ViewCheck로 점검

여기까지가 KRDS의 운영기관 식별자 기준입니다. 그런데 정작 어려운 건 "그래서 우리 사이트 식별자는 이걸 지키고 있나?"를 확인하는 일입니다. 로고에 제대로 된 대체 텍스트가 있는지, 홈 링크가 진짜 링크인지, 키보드로 작동하는지, 모바일에서 접근 가능한 이름이 유지되는지를 사람이 일일이 손으로 점검하려면 끝이 없습니다. 페이지가 수십·수백 개인 공공 사이트라면 더더욱요.

ViewCheck 분석 화면

ViewCheck(krds.viewcheck.co.kr)는 이 점검을 자동화합니다. URL만 넣으면 페이지를 실제로 크롤링해서, 운영기관 식별자를 포함한 컴포넌트들이 KRDS 기준을 지키는지 판정합니다. 운영기관 식별자는 KRDS 846규칙 중 컴포넌트(CP) 규칙군 446개에 속하고, 분석 결과의 컴포넌트(Components) 탭에서 확인할 수 있습니다.

ViewCheck가 운영기관 식별자에 대해 자동으로 보는 것들:

기관 마크의 대체 텍스트: 로고 이미지에 의미 있는 대체 텍스트(기관명)가 있는지, logo·이미지 같은 무의미한 값이 아닌지
홈 링크 여부: 식별자가 진짜 링크(<a>)로 감싸여 홈으로 연결되는지, <div> 클릭 같은 가짜 링크는 아닌지
접근 가능한 이름: 마크/링크에 어디로 가는지 알 수 있는 이름이 부여돼 있는지
위치·구조: 식별자가 헤더 영역에 표준 구조로 배치돼 있는지
터치 영역·대비: 모바일 뷰포트에서 로고 링크가 최소 권장 크기를 충족하는지, 색 대비가 기준에 맞는지(반응형·대비 분석과 연계)

DOM만으로 판단하기 어려운 시각적 부분(예: 기관명이 그림 속에만 있는 경우, 어두운 배경에서 로고가 묻히는 경우)은 KRDScan Vision AI가 스크린샷을 보고 보강 판정합니다. 그래서 "코드엔 텍스트 기관명이 없는데 화면엔 분명히 로고가 보이는" 비표준 구현도 놓치지 않습니다. 이 점이 단순 코드 검사 도구와 다른 부분입니다 — 사람이 눈으로 보듯 화면을 함께 보기 때문에, 표준을 우회해 만든 UI도 잡아냅니다.

리포트를 어떻게 읽나

분석이 끝나면 컴포넌트 탭에서 운영기관 식별자 관련 규칙의 통과/미통과 수와, 미통과한 항목의 **위치(어느 페이지)·이유·개선 방법(howToFix)**이 함께 나옵니다. 예를 들어 "메인 페이지 헤더 로고의 대체 텍스트가 비어 있음"처럼 구체적으로요. 여러 페이지를 한꺼번에 분석하면, "메인은 멀쩡한데 신청 시스템 페이지의 로고만 가짜 링크" 같은 페이지별 편차도 한눈에 드러납니다. 앞서 말한 "하위 시스템 식별자 단절"을 잡아내기 좋은 대목입니다. 어디부터 고쳐야 하는지 우선순위(P0~P3)도 함께 매겨지니, 한정된 시간에 가장 중요한 것부터 손볼 수 있습니다.

무료 진단으로 우리 사이트 메인부터 한 번 돌려 보면, 손으로는 몇 시간 걸릴 점검이 몇 분 만에 끝납니다. 그리고 그 결과는 막연한 "신뢰감 있게 만들자"가 아니라, "이 페이지의 로고에 이 대체 텍스트를 넣자"는 구체적인 작업 목록이 됩니다.

자주 묻는 질문

현장에서 운영기관 식별자를 다룰 때 반복해서 나오는 질문들을 모았습니다.

Q. 로고 이미지의 대체 텍스트(alt)에 정확히 뭐라고 적어야 하나요? 가장 단순하고 안전한 답은 "기관의 정식 명칭"입니다. alt="○○부"처럼요. 만약 그 로고가 홈으로 가는 링크를 겸한다면, 링크의 목적까지 담아 alt="○○부 홈"이나 aria-label="○○부 홈"으로 해도 좋습니다. 반대로 alt="logo", alt="심볼마크", alt="이미지" 같은 건 정보 가치가 없으니 피하세요. 핵심은 "눈으로 보면 알 수 있는 정보(어느 기관)를 글자로 옮기는 것"입니다.

Q. 기관 마크가 SVG인데, 대체 텍스트는 어떻게 넣나요? SVG는 <img>처럼 alt를 쓸 수 없으니 방식이 조금 다릅니다. 가장 무난한 건 SVG를 감싼 링크나 요소에 aria-label="○○부"를 주는 것, 또는 SVG 안에 <title>○○부</title>를 넣고 SVG에 role="img"을 부여하는 것입니다. 어떤 방식이든 "이 그래픽이 어느 기관을 뜻하는지"가 코드로 전달되기만 하면 됩니다. 반대로 그 SVG가 옆에 기관명 텍스트가 이미 있는 순수 장식이라면 aria-hidden="true"로 숨겨 중복 낭독을 막는 게 맞습니다.

Q. 로고를 누르면 홈으로 가는 건 너무 당연한데, 굳이 신경 써야 하나요? "당연히 그렇게 동작할 것"이라는 기대 때문에 오히려 더 중요합니다. 사용자는 길을 잃으면 무의식적으로 로고를 누릅니다. 그게 작동하지 않으면 "어? 왜 안 가지?" 하고 당황하죠. 그리고 이 동작이 진짜 링크(<a>)로 구현돼 있어야 키보드·스크린리더 사용자도 같은 출구를 쓸 수 있습니다. 자바스크립트로 흉내 낸 가짜 링크는 마우스 사용자에게만 작동하니, "당연한 동작"이 누군가에겐 막힌 문이 됩니다.

Q. 메인 페이지에서도 로고가 홈 링크인 게 맞나요? 이미 홈인데요. 대체로 그대로 두어도 괜찮습니다(눌러도 같은 페이지를 다시 불러올 뿐이니까요). 다만 더 친절하게 하려면, 메인 페이지에서는 이 링크에 aria-current="page"를 부여해 "지금 보고 있는 페이지가 바로 여기"임을 알려 줄 수 있습니다. 필수는 아니지만, 스크린리더 사용자에게 현재 위치를 분명히 해 주는 작은 배려입니다.

Q. 모바일에서 공간이 좁아 기관명 텍스트를 숨기고 마크만 남기고 싶은데, 괜찮나요? 시각적으로 기관명을 숨기는 것 자체는 문제없습니다. 다만 "코드에서까지 정보를 지우지 말 것"이 핵심입니다. 기관명 텍스트를 화면에서만 안 보이게 처리(visually hidden)하거나, 마크 이미지의 대체 텍스트·링크의 aria-label로 기관명을 코드에 남겨 두세요. 화면에서 글자가 사라졌다고 스크린리더에서도 "어느 기관인지 모름"이 되면, 가장 도움이 필요한 사용자를 배제하는 셈입니다.

Q. 헤더에 기관 로고가 있으면, 푸터에는 또 안 넣어도 되나요? 헤더와 푸터는 역할이 다릅니다. 헤더의 식별자는 "화면의 얼굴"(첫인상·신뢰), 푸터의 기관 정보는 "법적·행정적 명함"(주소·연락처·운영주체 등)에 가깝습니다. 둘 다 두는 게 일반적이고, 중요한 건 두 곳의 기관명·운영주체가 서로 일치하는 것입니다. 리뉴얼이나 조직 개편 후 한쪽만 갱신돼 어긋나는 경우가 흔하니, 변경 시 양쪽을 함께 확인하세요.

Q. 우리 기관은 브랜드 로고가 화려한데, 그대로 써도 되나요? 브랜드 정체성을 살리는 건 좋습니다. 다만 어떤 배경에서도 명확히 보이도록 반전(밝은/어두운) 버전을 준비하고, 너무 복잡한 디테일이 작은 크기·모바일에서 뭉개지지 않는지 확인하세요. 그리고 아무리 화려해도 접근성 요건(대체 텍스트, 진짜 링크, 포커스 표시)은 동일하게 적용됩니다. "예쁘게"와 "누구나 알아볼 수 있게"는 충돌하는 목표가 아닙니다.

Q. 외부 업체가 만든 하위 신청 시스템은 헤더가 다른데, 꼭 통일해야 하나요? 사용자 입장에서는 본 사이트든 하위 시스템이든 "같은 기관 서비스"입니다. 그런데 헤더가 갑자기 달라지면 "여기 맞나?" 하는 불안과 단절을 느낍니다. 피싱을 의심하게 되는 지점이기도 하죠. 그래서 하위 시스템에도 동일한 운영기관 식별자를 적용해, 사용자가 끊김 없이 같은 기관임을 인지하게 하는 게 맞습니다. 위탁 개발 발주 단계에서 "KRDS 식별자 적용"을 요건으로 명시하면 나중의 단절을 막을 수 있습니다.

Q. 이미 운영 중인 사이트인데, 헤더를 전부 다시 만들어야 하나요? 전부 갈아엎을 필요는 없습니다. 먼저 ViewCheck로 현황을 확인해 "지금 로고에 대체 텍스트가 있는지, 홈 링크가 진짜 링크인지, 어느 페이지의 식별자가 문제인지"를 목록으로 만든 다음, 치명적인 것(대체 텍스트 누락, 가짜 링크)부터 차례로 고치면 됩니다. 식별자는 보통 공통 헤더 하나로 관리되므로, 그 한 곳만 제대로 고치면 전 페이지가 동시에 개선되는 경우가 많습니다. 적은 작업으로 가장 큰 효과를 보는 대표적인 영역입니다.

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

ViewCheck로 돌려 보면 운영기관 식별자 문제가 한두 개로 끝나지 않을 수 있습니다. 특히 하위 시스템이 여럿인 큰 사이트라면요. 그래서 우선순위가 중요합니다. 식별자 문제를 심각도 순으로 정리하면 대략 이렇습니다.

가장 먼저(치명적) — 기관 마크에 대체 텍스트가 없거나 무의미한 경우, 그리고 홈 링크가 키보드로 작동하지 않는 가짜 링크인 경우. 이건 시각장애인이 "어느 기관에 있는지"조차 알 수 없게 만들거나, 키보드 사용자에게서 가장 기본적인 출구를 빼앗는 문제라 1순위입니다. 신뢰와 직결되는 첫 화면 요소라 더더욱 먼저 손봐야 합니다.

그다음(높음) — 어두운 배경에서 로고가 거의 안 보이는 대비 문제, 모바일에서 접근 가능한 이름까지 사라지는 문제, 그리고 하위 시스템에서 식별자가 단절되는 문제. 작동은 하지만 특정 사용자·특정 환경에서 정보가 닿지 않거나 신뢰가 흔들리는 경우입니다.

그 후(보통) — 기관명이 그림 속에만 있고 텍스트가 없는 문제, 포커스 표시 제거, 모바일 터치 영역 부족, 헤더-푸터 정보 불일치. 사용은 가능하지만 검색·확대·일관성 측면에서 손해를 보는 항목입니다.

여력이 되면(낮음) — 메인 페이지에서 현재 위치 표시(aria-current) 추가, 로고 보호 여백 규정화, 반전 로고 정비 같은 다듬기. 접근성을 막는 건 아니지만 완성도를 한 단계 끌어올리는 항목입니다.

ViewCheck 리포트는 이 우선순위(P0~P3)를 자동으로 매겨 주기 때문에, "일단 눈에 띄는 것부터"가 아니라 "사용자 신뢰와 접근을 가장 많이 좌우하는 것부터" 순서대로 처리할 수 있습니다.

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

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

KRDS 가이드라인 PDF(디지털 정부서비스 UI/UX 가이드라인, 2025.08판) — 컴포넌트별 정의와 사용 원칙의 1차 원천.
KRDS 컴포넌트 문서(웹) — 운영기관 식별자의 구조와 예시를 화면으로 확인.
KRDS 컴포넌트 킷(GitHub) — 헤더·식별자 관련 HTML 구조를 그대로 가져다 사용(npm install krds-uiux 또는 CDN).
KRDS 공식 Figma(@krds) — 디자이너용 헤더·식별자 컴포넌트와 상태.

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

오늘의 체크리스트 — 운영기관 식별자, 이것만은

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

식별자가 화면 헤더 좌측의 예측 가능한 자리에 있다.
기관 마크 이미지에 **의미 있는 대체 텍스트(기관명)**가 있다(logo·이미지 같은 무의미한 값이 아니다).
기관 마크가 SVG라면 role="img" + aria-label/<title>로 기관명이 코드에 담겨 있다.
기관명이 실제 텍스트로 존재한다(그림 속 글자에만 의존하지 않는다).
식별자가 **진짜 링크(<a href="/">)**로 홈에 연결된다(<div> 클릭 같은 가짜 링크가 아니다).
홈 링크에 어디로 가는지 알 수 있는 접근 가능한 이름이 있다.
키보드만으로 식별자에 초점이 가고 Enter로 홈에 갈 수 있다.
초점이 왔을 때 포커스 표시가 또렷하다(outline: none으로 지우지 않았다).
헤더 배경(밝음/어두움/스크롤 변화)과 로고의 명도 대비가 충분하다.
모바일에서 로고 링크의 터치 영역이 충분하다(약 44px 이상).
모바일에서 기관명을 숨겨도 접근 가능한 이름은 코드에 남아 있다.
사이트 전체(하위 시스템 포함)에서 식별자가 일관되고, 헤더-푸터 기관 정보가 일치한다.

KRDS 컴포넌트 킷(npm install krds-uiux 또는 CDN)을 쓰면 위 항목 대부분이 이미 표준 구조로 준비된 상태에서 시작할 수 있습니다. 직접 만들다 빠뜨릴 위험을 줄이는 가장 확실한 방법이죠. 공식 Figma 라이브러리(@krds)에서는 디자이너가 헤더·식별자 컴포넌트를 그대로 가져다 쓸 수 있습니다.

운영기관 식별자는 작아 보이지만, 사용자가 공공 서비스에 들어서서 가장 먼저 보고, 가장 먼저 신뢰 여부를 판단하는 첫 관문입니다. 그 작은 로고 자리 하나가 누군가에겐 "여기는 믿을 수 있는 곳"이라는 안심이고, 또 누군가에겐 "여기가 어딘지 모르겠다"는 미로의 입구입니다. 우리가 무심코 얹은 로고 이미지 하나가, 누군가에게는 그 민원을 안심하고 끝낼 수 있느냐 없느냐를 가릅니다.

오늘 정리한 기준이 거창해 보일 수 있지만, 핵심은 결국 단순합니다. 기관명을 코드에도 담고, 로고를 진짜 홈 링크로 만들고, 키보드로 쓸 수 있게 하고, 어떤 배경에서도 보이게 하는 것. 이 네 가지만 챙겨도 식별자 위반의 대부분은 사라집니다. 그리고 그게 잘 됐는지는 ViewCheck로 몇 분이면 확인할 수 있습니다. 완벽을 한 번에 만들 필요는 없습니다. 공통 헤더의 식별자 하나부터 제대로 고치면, 우리 사이트의 모든 페이지가 동시에 더 믿음직하고 더 많은 사람에게 열립니다. 다음 글에서는 이 식별자가 자리 잡은 헤더 영역의 또 다른 핵심 요소를 같은 방식으로 뜯어보겠습니다.

우리 사이트의 운영기관 식별자는 지금 제 역할을 하고 있을까요? krds.viewcheck.co.kr에서 URL만 넣으면 무료로 확인할 수 있습니다. 메인 페이지 하나만 돌려 봐도, 로고에 대체 텍스트가 있는지, 홈 링크가 제대로 작동하는지 바로 보입니다.

#KRDS #공공웹 #디자인시스템 #운영기관식별자Identifier #웹접근성 #ViewCheck #정부웹사이트 #UIUX #헤더 #브랜드아이덴티티 #공공서비스신뢰

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

25편 : 동종 기관끼리 KRDS 점수를 비교하면 무슨 일이 벌어지나 — ViewCheck 벤치마킹 데이터 연구

ViewCheck — Mon, 28 Sep 2026 23:18:01 +0900

25편 : 동종 기관끼리 KRDS 점수를 비교하면 무슨 일이 벌어지나 — ViewCheck 벤치마킹 데이터 연구

"우리 기관 점수가 몇 점인지는 알겠는데, 그게 잘한 건지 못한 건지를 어떻게 알죠?"

들어가며 — 점수 하나가 말해주는 것과 말해주지 않는 것

분석을 마치고 점수가 나왔다. KRDS 846규칙 기준으로 이 기관의 준수율은 62%다. 이 숫자를 보는 담당자의 첫 반응은 보통 두 가지로 갈린다. "생각보다 높네"라고 느끼거나, "이렇게나 낮다고?"라고 충격받거나. 그런데 흥미롭게도, 두 반응 모두 거의 같은 후속 질문으로 이어진다.

"다른 기관들은 얼마나 되는 거죠?"

그 질문이 바로 벤치마킹의 출발점이다. 62%라는 숫자는 절대값이다. 그것만으로는 "잘한 것인지 못한 것인지"를 말해주지 않는다. 같은 분류 기관들이 평균적으로 45%라면 62%는 상위권이다. 반대로 평균이 78%라면 62%는 꽤 처진 편이다. 숫자의 의미는 맥락 안에서 살아난다. 그 맥락을 만드는 것이 동종 기관 비교, 즉 피어 벤치마킹(peer benchmarking)이다.

이 글은 ViewCheck가 왜 벤치마킹 기능을 24개 분석 카드 중 하나로 포함시켰는지, 그 과정에서 어떤 방법론적 문제를 마주했는지, 그리고 KRDS 준수율 데이터로 기관들을 비교했을 때 어떤 패턴이 드러나는지에 대한 연구 노트다. 미리 말해두면, 이건 "ViewCheck가 이미 완벽한 벤치마킹 시스템을 갖췄다"는 광고가 아니다. 오히려 "벤치마킹이 생각보다 훨씬 어렵다"는 이야기를 먼저 하고, 그 어려움을 우리가 어떻게 접근하고 있는지를 솔직하게 적으려 한다.

공공기관 웹사이트 품질 비교는 단순히 점수를 줄 세우는 작업이 아니다. 무엇을 기준으로, 어떤 기관끼리, 어떤 방법으로 비교할 것인가 — 이 세 가지 질문에 어떻게 답하느냐에 따라, 결과가 완전히 달라진다. 그리고 이 세 가지 질문이 모두 쉽지 않다.

점수 하나만으로는 "잘한 것"인지 알 수 없다. 같은 선에 선 경쟁자들을 봐야 비로소 순위가 의미를 가진다.

벤치마킹이 왜 필요한가 — "기준선"의 역할

점수 비교의 필요성을 이야기하기 전에, 왜 공공기관들이 벤치마킹에 관심을 갖게 됐는지를 먼저 짚어보자. 배경 없이 방법만 이야기하면 반쪽짜리가 된다.

공공기관 웹사이트 품질 평가의 역사에서 벤치마킹은 꽤 늦게 등장한 개념이다. 초기의 공공웹 점검은 대부분 "기준을 충족하는가 아닌가"라는 이분법적 판정이었다. 접근성 지침을 통과했느냐, HTML 표준을 지켰느냐 — 이런 질문은 기관들을 서로 비교하지 않는다. 각자가 기준선을 넘었는지만 본다.

그런데 이 접근 방식에는 한계가 있다. 기준선이 낮으면, 모든 기관이 통과하더라도 전체적인 수준은 나쁠 수 있다. 반대로 기준선이 너무 높으면, 거의 모든 기관이 탈락해 점검 자체가 동력을 잃는다. 그리고 가장 중요한 문제가 있다 — 기준선 통과 여부만으로는 "어떤 기관을 따라 하면 좋을까"라는 개선의 방향이 생기지 않는다.

벤치마킹이 개선의 동력이 되는 이유는 심리학적으로도 설명된다. 사람은 절대적 기준("100점 만점에 60점")보다 상대적 위치("하위 30%")에 더 민감하게 반응하는 경향이 있다. 비슷한 조건의 다른 기관이 더 좋은 성과를 낸다는 것을 알게 됐을 때 — "저 기관도 우리랑 예산이 비슷한데 훨씬 높네" — 개선 의지가 더 강하게 발동된다.

공공부문 벤치마킹에 대한 학술 연구도 이 효과를 꾸준히 지적해 왔다. 와일리가 발행하는 학술지 Financial Accountability & Management에 2022년 게재된 연구는 스웨덴 지방자치단체 데이터베이스(Kolada)를 분석하면서, 디지털화된 벤치마킹 시스템에서 기관들이 동종 피어 그룹 선택을 둘러싸고 어떤 행동 패턴을 보이는지를 추적했다. 흥미로운 점은, 기관 내 실무자와 의사결정자가 각기 다른 방식으로 피어 그룹을 선택한다는 것이었다. 실무 담당자는 성과 격차를 찾아내기 위해 알고리즘이 선택한 그룹을 선호하는 반면, 정치인과 고위 관리자는 지리적으로 인접한 이웃 기관을 더 선호했다는 것이다(Chua et al., "Mapping and contesting peer selection in digitalized public sector benchmarking", Financial Accountability & Management, 2022).

이 연구가 시사하는 것은 단순하다. 피어 그룹을 '어떻게 정의하느냐'가 벤치마킹 결과에 결정적 영향을 미친다는 것. 그리고 그 정의에는 기술적 판단뿐 아니라 사용 목적에 따른 의도적 선택이 필요하다는 것이다.

대한민국 공공웹 품질 진단의 공식 프레임 — 행안부 수준진단

ViewCheck가 벤치마킹 기능을 설계하기 전에 가장 먼저 들여다본 것은 행정안전부가 공식적으로 운영하는 공공웹 품질 수준진단 체계다.

행정안전부는 「전자정부 웹사이트 품질관리 지침」(행안부 고시 제2025-46호, 2025. 6. 25. 개정)에 근거해 공공 웹사이트의 품질을 관리한다. 이 지침에 따르면, 행정기관의 장은 운영 중인 웹사이트에 대해 7대 영역(호환성·접근성·개방성·접속성·편의성·효율성·신뢰성)을 기준으로 품질진단을 시행해야 한다(행정안전부 고시 제2025-46호, law.go.kr).

그런데 이 지침은 "진단을 시행해야 한다"는 의무를 부과하지만, "다른 기관과 비교해야 한다"는 의무는 없다. 비교는 공식 체계에서 선택 사항이다. 행안부는 매년 공공 웹사이트 품질관리 수준진단을 실시하고 그 자료를 공개하는데(행안부, 「2023년도 공공 웹사이트 품질관리 수준진단 자료」, 2023 / 「2025년 공공 웹앱 품질관리 수준진단 및 UI/UX 국민평가 설명회 자료」, 2025), 이 자료에는 기관 유형별 집계 등이 포함된다. 그러나 개별 기관의 점수를 서로 직접 비교해 순위를 공개하는 방식은 아니다.

이 간극 — 공식 체계가 비교를 하지 않는 지점 — 이 민간 분석 도구가 채울 수 있는 영역이다. ViewCheck의 벤치마킹 기능은 바로 이 간극을 겨냥한다. 행안부 공식 수준진단이 "이 사이트는 기준을 충족하는가"를 묻는다면, ViewCheck의 벤치마킹은 "이 사이트는 같은 유형 기관들에 비해 어느 위치에 있는가"를 묻는다.

NIA 웹 접근성 실태조사가 보여준 것 — 기관 유형별 격차의 실재

피어 비교의 필요성을 실증적으로 보여주는 데이터로, 우리는 NIA(한국지능정보사회진흥원)의 웹 접근성 실태조사를 자주 참조한다. NIA는 매년 공공기관과 민간기관의 웹 접근성 수준을 조사하고, 기관 유형별로 결과를 집계해 발표한다(NIA 웹 접근성 실태조사, nia.or.kr).

NIA가 공개한 실태조사 결과는 중요한 사실을 보여준다. 공공기관 내에서도 기관 유형에 따라 접근성 수준이 상당한 폭으로 차이를 보인다는 것이다. 중앙행정기관, 광역자치단체, 기초자치단체, 공공기관(공기업·준정부 등)이 서로 다른 평균 점수를 갖는 경향이 나타났다. 가장 최근의 공개 결과 기준으로 2023년 장애인·고령자 등의 웹사이트 접근성 수준은 65.8점으로 전년 대비 4.9점 상승한 것으로 집계됐다(NIA, 웹 접근성 실태조사, nia.or.kr).

이 수치를 볼 때 주의할 점이 있다. 65.8점이라는 국가 평균값만 보고 "우리 기관은 70점이니까 평균 이상"이라고 결론 내리면 안 된다는 것이다. 왜냐하면 70점짜리 기초자치단체와 70점짜리 중앙행정기관은 서로 다른 맥락에 있기 때문이다. 중앙행정기관의 평균이 75점이라면 70점짜리 중앙행정기관은 그 유형 안에서 하위권이다. 반면 기초자치단체 평균이 58점이라면 70점은 상위권이다.

이것이 동종 기관 비교, 즉 기관 유형 안에서의 피어 비교가 필요한 이유다. NIA 실태조사가 유형별 집계를 제공하는 것도 같은 이유다 — 전체 평균만으로는 개별 기관이 어느 위치에 있는지 파악하기 어렵기 때문이다.

ViewCheck의 벤치마킹 기능이 노리는 것이 바로 이 지점이다. KRDS 846규칙 준수율이라는 더 세밀한 기준으로, 같은 유형 기관끼리의 상대적 위치를 보여주자는 것.

"동종 기관"을 어떻게 정의할 것인가 — 분류 체계의 문제

벤치마킹에서 가장 먼저 부딪히는 기술적 문제는 "동종 기관을 어떻게 분류할 것인가"다. 이게 생각보다 훨씬 까다롭다.

공공기관을 분류하는 방법은 여러 가지가 있다.

첫 번째는 법적 기관 유형에 따른 분류다. 중앙행정기관, 광역자치단체, 기초자치단체, 공기업, 준정부기관, 기타 공공기관 — KRDS 공식 가이드라인도 이 기준을 사용해 "중앙행정기관 / 공공기관 / 지방자치단체"로 나누고 기관 유형별로 가이드라인 적용 수준을 다르게 설정한다(KRDS 공식, krds.go.kr). 이 분류는 명확하고 공식적이라는 장점이 있다. 다만, 같은 '기초자치단체'라도 서울 구청과 군 단위 자치단체는 규모와 IT 인프라에서 엄청난 차이가 있다.

두 번째는 기관 규모에 따른 분류다. 웹사이트 방문자 수, 직원 수, 예산 규모 등으로 소형/중형/대형으로 나누는 방식이다. 규모가 비슷한 기관끼리 비교하는 것이 더 공정하다는 논리는 직관적으로 납득된다. 그러나 공공기관의 예산이나 방문자 수는 공개 데이터로 취합하기 어려운 경우가 많다.

세 번째는 서비스 유형에 따른 분류다. 민원 신청 중심 기관, 정보 제공 중심 기관, 복합 서비스 기관 — 같은 '중앙행정기관'이라도 어떤 서비스를 주로 제공하는지에 따라 KRDS 규칙의 어느 부분이 더 중요한지가 달라진다. 검색과 신청 기능이 핵심인 기관은 SP(서비스 패턴) 규칙에서 취약점이 나타날 가능성이 높고, 콘텐츠 중심 기관은 DS(디자인 스타일) 규칙의 문제가 더 두드러질 수 있다.

ViewCheck는 현재 이 세 가지 분류를 복합적으로 고려하는 방향으로 실험 중이다. 다만, 솔직히 말하면 이 부분은 아직 완전히 정립되지 않았다. 어떤 분류 기준을 쓰느냐에 따라 같은 기관이 "상위 30%"도 되고 "하위 30%"도 될 수 있다. 그 불확실성을 숨기지 않는 것이 우리의 원칙이다.

점수 막대를 나란히 놓는 것만으로는 충분하지 않다. 어떤 기관끼리 비교하느냐가 결과의 의미를 결정한다.

해외의 동종 비교 선례 — eGovernment Benchmark와 OECD 디지털정부지수

동종 기관 비교를 이야기할 때, 해외의 선행 사례를 빼고 가면 절반만 이야기하는 것이다.

유럽연합 집행위원회가 매년 발간하는 eGovernment Benchmark는 EU 회원국들의 전자정부 서비스 품질을 비교하는 대표적인 공공부문 벤치마킹 사례다. 2024년판 eGovernment Benchmark 보고서에 따르면, 말타와 에스토니아가 각각 97점, 92점으로 1~2위를 차지했고, 핀란드(88), 리투아니아(86), 덴마크(85) 등이 뒤를 따랐다(Capgemini / European Commission, "eGovernment Benchmark 2024", digital-strategy.ec.europa.eu). 이 벤치마크의 2024년판에서 특히 주목할 점은 접근성이 처음으로 파일럿 지표로 포함됐다는 것이다. WCAG 2.2 기준 자동 테스트(Deque axe extension)를 사용해 EU 각국 정부 웹사이트의 접근성을 비교 측정했다.

그 결과가 시사적이다. EU 27개국 중 65%의 정부 웹사이트가 WCAG 기준을 충족하지 못한 것으로 나타났다(Bogdan Cerovac, "Comparison of accessibility of e-government websites in Europe in 2024", cerovac.com/a11y, 2024). 65%가 미달이라는 수치는 "유럽의 전자정부가 많이 발전했다"는 이미지와는 다소 충돌한다. 물론 자동 테스트가 발견하지 못하는 접근성 문제도 많으므로, 이 수치가 전부를 말해주지는 않는다. 하지만 자동화된 도구로 측정한 비교 데이터가 "우리가 생각하는 것보다 현실이 좋지 않을 수 있다"는 것을 드러내 준다는 점에서 의미 있다.

더 높은 차원에서, OECD가 운영하는 **디지털정부지수(Digital Government Index, DGI)**는 국가 단위의 동종 비교 사례다. 2023년 OECD DGI 결과에서 대한민국은 33개 회원국과 5개 비회원국을 대상으로 한 평가에서 0.935점으로 2회 연속 종합 1위를 기록했다. 6개 평가 부문(데이터기반 정부, 플랫폼 정부, 개방형 정부, 선제적 정부, 국민 주도형 정부, 디지털 우선 정부) 중 4개에서 1위, 나머지 2개에서 2위를 차지했다(OECD, "2023 OECD Digital Government Index", oecd.org; 대한민국 정책브리핑, "한국, OECD 디지털정부 평가 2회 연속 종합 1위", korea.kr, 2024).

이 결과는 국가 차원의 디지털정부 성숙도에서 한국이 상위에 위치함을 보여준다. 그런데 여기서 중요한 점이 있다. 국가 순위가 높다고 해서, 개별 기관의 웹사이트 품질이 모두 높은 것은 아니다. OECD DGI는 중앙정부 차원의 거버넌스와 정책 성숙도를 평가하지, 각 기관 웹사이트의 KRDS 준수율을 측정하지 않는다. "한국 전자정부 1위"와 "개별 공공기관 웹사이트의 KRDS 준수율"은 다른 이야기다. 이 구분을 명확히 하는 것이 우리가 벤치마킹 결과를 해석할 때 늘 강조하는 부분이다.

ViewCheck 벤치마킹이 실제로 하는 것 — KRDS 준수율의 동종 비교

해외 선례와 국내 공식 체계를 배경으로, ViewCheck 벤치마킹 기능이 실제로 무엇을 하는지 구체적으로 들어가 보자.

ViewCheck의 벤치마킹 카드는 분석 완료 후 생성되는 24개 기능 카드 중 하나로, LLM 분석 대화에 자동으로 등장한다. 이 카드가 담는 핵심 질문은 하나다.

"이 기관의 KRDS 846규칙 준수율은, 같은 유형 기관들의 분포 중 어디에 위치하는가?"

구체적으로는 다음과 같은 정보를 제시한다.

준수율 분포 위치: ViewCheck가 분석한 동종 유형 기관들의 KRDS 준수율 분포(최솟값·하위 25%·중앙값·상위 25%·최댓값 등) 위에 해당 기관의 점수가 어디에 있는지를 표시한다.

카테고리별 상대 위치: 전체 준수율뿐 아니라 DS(디자인 스타일)·CP(컴포넌트)·BP(기본 패턴)·SP(서비스 패턴) 4개 카테고리 각각에서 동종 기관 대비 상대 위치를 보여준다. 전체 점수는 비슷하지만 특정 카테고리에서 유독 낮은 경우가 있기 때문이다.

강점과 취약 영역 대조: 동종 기관 평균 대비 이 기관이 상대적으로 강한 영역과 약한 영역을 함께 제시한다. 이것이 단순 순위보다 더 가치 있는 정보다 — 어디가 약한지를 알아야 무엇을 고칠지가 나온다.

참고 사례 제시 (가능한 경우): 같은 유형 기관 중 특정 카테고리에서 높은 점수를 받은 사례가 있다면, 그 기관의 어떤 점이 달랐는지를 가능한 범위에서 제시한다. 이것이 벤치마킹을 "순위표"가 아닌 "개선 지도"로 만드는 핵심이다.

ViewCheck LLM 분석의 벤치마킹 카드 실제 화면. KRDS 준수율의 동종 기관 분포 안에서 해당 기관의 위치를 보여준다. — 실제 분석 화면

벤치마킹 데이터로 드러나는 패턴 — 실제로 보이는 것들

이론 이야기를 잠깐 내려놓고, ViewCheck로 여러 공공기관을 분석하면서 벤치마킹 데이터에서 반복적으로 나타나는 패턴을 이야기해 보자. 이건 우리가 실측한 것에서 관찰한 경향이지, 통계적으로 검증된 결론은 아니다. 그 구분을 분명히 해두고 시작한다.

패턴 1: 전체 점수와 카테고리 점수의 불일치

전체 KRDS 준수율이 비슷해 보이는 두 기관을 카테고리별로 쪼개면 완전히 다른 그림이 나오는 경우가 많다. 예를 들어, A 기관과 B 기관 모두 전체 준수율이 65% 안팎이라고 하자. 그런데 A 기관은 DS(디자인 스타일)에서 80%를 찍지만 SP(서비스 패턴)에서 40%대로 떨어지고, B 기관은 반대로 DS가 55%이지만 SP가 75%다. 이 두 기관은 "65%"라는 전체 점수가 같아 보이지만, 실제로는 완전히 다른 종류의 문제를 갖고 있다.

이 현상이 생기는 이유 중 하나는 기관마다 웹사이트의 주된 기능이 다르기 때문이다. 정보 제공이 주된 기관은 디자인 일관성(DS)에 투자하지만 민원 신청 흐름(SP)은 덜 신경 쓰는 경향이 있다. 반대로 실시간 민원 처리가 많은 기관은 서비스 패턴을 잘 갖추는 대신 디자인 토큰 준수에는 소홀한 경우가 있다. 이런 패턴을 인식하고 나면, "전체 점수가 몇 점이냐"보다 "어느 카테고리가 어떠냐"가 훨씬 중요한 정보임을 알게 된다.

패턴 2: 메인 페이지와 서브 페이지의 준수율 격차

벤치마킹 데이터에서 반복적으로 나타나는 또 다른 패턴은, 메인 페이지와 서브 페이지 사이의 준수율 격차다. 대부분의 기관에서 메인 페이지의 KRDS 준수율이 서브 페이지보다 유의미하게 높다. 이건 어느 정도 예상 가능한 결과다 — 메인 페이지는 가장 눈에 띄고 외주 개발사가 공을 많이 들이는 페이지이기 때문이다.

그런데 문제는, 시민이 실제로 불편을 겪는 곳은 대부분 메인 페이지가 아니라는 것이다. 민원 신청 화면, 로그인 화면, 검색 결과 화면 — 이런 페이지들의 준수율이 낮아도 메인 페이지 기준으로만 점검하면 전혀 드러나지 않는다. ViewCheck가 처음부터 다중 페이지 분석을 기본값으로 설계한 이유도 여기에 있다. 벤치마킹 데이터에서 "메인 준수율"과 "전체 준수율"을 별도로 보여주는 이유도 마찬가지다.

이 격차가 큰 기관일수록, 겉으로는 괜찮아 보이지만 실제 사용자 경험이 나쁜 사이트일 가능성이 높다. 벤치마킹에서 이 격차 지표 자체가 하나의 의미 있는 신호가 된다.

패턴 3: 기관 유형보다 "관심도"가 더 큰 영향

이게 가장 흥미로운 패턴이다. 기관 유형(중앙부처냐 기초자치단체냐)이나 규모보다, 해당 기관이 웹 품질에 얼마나 관심을 기울이는지가 준수율 차이를 더 크게 설명하는 것처럼 보이는 경우가 있다.

예산이 크고 인력이 많은 대형 기관이라도, 웹사이트를 "외주 맡기고 잊어버리는" 방식으로 운영하면 KRDS 준수율이 낮게 나온다. 반면 비교적 작은 기관이라도 담당자가 품질에 관심을 갖고 지속적으로 개선해 온 경우, 전체 분포에서 상위에 위치하는 경우를 봤다.

물론 이 "관심도"는 직접 측정할 수 없는 변수다. 우리가 데이터에서 추론하는 것이지, 실증적으로 확인한 인과관계가 아니다. 다만, 이 패턴이 시사하는 것은 벤치마킹 결과를 볼 때 "왜 이 기관이 이 위치에 있는가"를 단순히 "예산이 얼마니까"로 설명하는 것을 경계해야 한다는 점이다.

비교의 함정 — 무엇을 주의해야 하는가

벤치마킹이 유용한 만큼, 잘못 사용하면 오히려 독이 된다. 이 섹션에서는 우리가 벤치마킹 기능을 설계하면서 특히 주의한 점들을 이야기한다.

함정 1: "낮은 평균"이 면죄부가 되는 경우

"동종 기관 평균이 45%인데 우리는 55%니까 양호하다"는 결론은 위험하다. 평균이 낮다는 건 "모두가 기준 미달"이라는 뜻이지, 55%가 충분하다는 뜻이 아니다. 미달 상태의 집단 안에서 상위에 있어도, 그것이 "기준을 충족한다"는 뜻은 아니다.

이건 단순해 보이지만 실제 현장에서 많이 발생하는 해석 오류다. 벤치마킹 결과를 볼 때 상대적 위치와 절대적 기준을 항상 함께 제시해야 하는 이유가 여기에 있다. ViewCheck의 벤치마킹 카드가 "동종 기관 대비 상위 30%"라는 정보와 함께 "그럼에도 KRDS 기준 절대값으로는 X%이며, 이 정도면 어떤 수준인지"를 병기하는 것은 이 함정을 피하기 위해서다.

함정 2: 같은 점수지만 다른 조건

분류가 충분히 세밀하지 않으면, "같은 유형"이라고 묶인 기관들 사이에 사실은 비교하기 어려운 조건 차이가 있을 수 있다. 앞서 언급한 대로, 같은 "기초자치단체"라도 서울의 구청과 강원도 산간의 군청은 IT 인프라, 예산, 인력 측면에서 비교하기 어려운 차이가 있다.

이 문제를 어떻게 다루느냐에 따라 벤치마킹의 공정성이 달라진다. 우리는 현재 이 문제에 완전한 해답을 갖고 있지 않다. 가능한 범위에서 기관 규모와 유형을 복합적으로 고려하되, "이 비교가 완벽하게 공정하지 않을 수 있다"는 한계를 사용자에게 명시하는 것이 지금 단계에서 우리가 할 수 있는 솔직한 접근이다.

함정 3: 순위 그 자체를 목표로 삼는 것

"다음번 분석에서는 상위 10% 안에 들자"라는 목표 설정은 언뜻 합리적으로 보인다. 그런데 이 목표가 잘못 설정되면, 기관들이 "KRDS 준수율을 실제로 올리는 것"보다 "측정에서 잘 나오는 방향으로 최적화하는 것"을 택하는 게임에 빠질 수 있다.

공공부문 벤치마킹 연구는 이 문제를 꾸준히 경고해 왔다. 굿하트의 법칙(Goodhart's Law)으로 알려진 이 현상 — 측정이 목표가 되면, 그것은 더 이상 좋은 측정 지표가 아니게 된다 — 은 공공부문 성과 지표에서 반복적으로 관찰된다.

ViewCheck의 벤치마킹이 순위보다 카테고리별 격차와 개선 방향을 강조하는 이유도 여기에 있다. 순위를 올리는 게 목표가 아니라, 실제 사용자 경험을 개선하는 게 목표여야 한다. 벤치마킹은 그 방향을 찾는 나침반이지, 목적지 자체가 아니다.

숫자를 읽는 것과 숫자를 제대로 해석하는 것은 다른 일이다. 벤치마킹 보고서를 함께 들여다보는 분석가들.

KRDS 규칙 카테고리별 벤치마킹 — DS·CP·BP·SP가 각각 말하는 것

전체 준수율 비교에서 카테고리별 비교로 한 단계 들어가면, 기관의 특성이 훨씬 선명하게 보인다. 각 카테고리가 어떤 것을 측정하는지, 그리고 카테고리별 동종 비교에서 어떤 양상이 나타나는지를 이야기해 보자.

DS(디자인 스타일) — 색상·타이포·간격의 일관성

DS 규칙은 KRDS가 정의한 색상 토큰, 타이포그래피 규격, 8pt 기반 간격 시스템 등 시각적 디자인 언어를 기관의 웹사이트가 얼마나 준수하는지를 측정한다. 120개 규칙으로 구성된다.

동종 기관 비교에서 DS 점수가 흥미로운 이유는, 이 점수가 "디자인 전문성"보다 "KRDS 준수 의도"를 더 많이 반영하는 경향이 있기 때문이다. 좋은 디자인을 가진 기관이라도 KRDS 토큰을 따르지 않으면 DS 점수가 낮고, 반대로 KRDS를 기반으로 구축된 사이트는 시각적으로 다소 평범해 보여도 DS 점수는 높게 나온다.

최근 KRDS 기반으로 리뉴얼을 진행한 기관들이 DS 점수에서 상위권을 차지하는 패턴이 관찰된다. 이는 KRDS의 공식 배포(krds.go.kr)가 실제 기관들의 준수율 향상에 효과가 있다는 간접적 신호로 읽을 수 있다. 다만 이 인과관계를 확정적으로 말하기는 어렵다 — KRDS 도입과 DS 점수 향상 사이에 다른 요인이 있을 수 있기 때문이다.

CP(컴포넌트) — 버튼·입력창·모달의 구현 품질

CP 규칙은 446개로 가장 규칙 수가 많다. 버튼, 입력창, 탭, 모달, 카드 같은 UI 컴포넌트가 KRDS 스펙에 따라 구현됐는지, ARIA 속성은 적절한지, 키보드 접근성은 갖춰졌는지를 DOM 기반으로 판정한다.

동종 비교에서 CP 점수의 특징은 분산이 크다는 것이다. 즉, 같은 유형 기관이라도 CP 점수 격차가 DS나 BP보다 큰 경향이 있다. 이유는 CP 규칙이 외주 개발사의 구현 역량에 크게 의존하기 때문이다. 비용을 들여 잘 만든 컴포넌트는 CP 규칙을 대부분 충족하지만, 빠르게 납품하고 끝낸 사이트는 ARIA 속성이 누락되거나 키보드 포커스가 엉키는 등의 문제가 많이 나타난다. 동종 기관들이 같은 외주 업체를 쓴 경우 CP 점수가 군집을 형성하는 경우도 관찰된다.

BP(기본 패턴) — 폼·동의·오류 처리의 설계

BP 규칙(108개)은 폼 작성, 동의/확인 플로우, 오류 처리, 필터/정렬 같은 상호작용 패턴의 구현 수준을 측정한다. 컴포넌트 하나하나가 아니라, 여러 컴포넌트가 합쳐져 만드는 "경험의 흐름"을 본다는 점에서 CP와 차별된다.

BP에서 동종 비교가 흥미로운 이유는, 기관의 주된 서비스 유형에 따라 BP 규칙의 적용 여부가 크게 달라지기 때문이다. 민원 신청이나 회원 가입이 없는 정보 제공 전용 사이트는 폼 관련 BP 규칙이 "해당없음(N/A)"으로 처리되어, 비교 자체가 어렵다. 그래서 BP 비교를 할 때는 "이 기관들이 공통적으로 갖춘 서비스 유형이 무엇인가"를 먼저 확인해야 한다. 단순히 점수만 나란히 놓으면, 적용 가능한 규칙 수 자체가 다른 기관들을 비교하는 왜곡이 생길 수 있다.

SP(서비스 패턴) — 검색·로그인·신청 흐름의 완성도

SP 규칙(172개)은 공공 서비스에서 가장 핵심적인 흐름 — 검색, 로그인, 신청, 정책 안내 — 이 제대로 갖춰졌는지를 3중 게이트(DOM → OCR → URL 분류)로 판정한다.

SP 점수의 동종 비교에서 나타나는 흥미로운 패턴은, 서비스 다양성이 높은 기관일수록 SP 점수 분산이 크다는 것이다. 로그인·신청·검색을 모두 갖춘 종합 민원 포털은 SP 규칙의 대부분이 적용되어 미통과 수도 많이 나오지만, 단순 정보 안내 사이트는 SP 규칙 상당수가 "해당없음"으로 빠진다. 그래서 SP 점수 비교는 "이 기관들이 제공하는 서비스 유형이 비슷한가"를 전제로 해야 의미가 있다.

이 네 카테고리를 종합적으로 보면서 동종 비교를 할 때, ViewCheck가 특히 중점을 두는 것은 "전체 합산 점수"가 아니라 "카테고리별 상대적 프로파일"이다. 동종 기관 대비 DS는 강하고 CP는 약한 기관과, DS가 약하고 SP는 강한 기관은 완전히 다른 개선 전략이 필요하다. 그 차이를 보여주는 것이 벤치마킹의 핵심 가치다.

벤치마킹 데이터를 쌓는 일 — 인프라와 어려움

벤치마킹 기능이 가치 있으려면, 비교 대상이 되는 기관들의 데이터가 충분히 쌓여 있어야 한다. 이 데이터 인프라 구축이 실제로 가장 어려운 부분 중 하나다.

ViewCheck의 크롤링 파이프라인(Playwright 기반)은 공공기관 사이트들을 주기적으로 방문하며 KRDS 846규칙 분석 결과를 축적한다. 그 결과가 쌓일수록 벤치마킹 비교의 기반이 되는 모집단(동종 기관들의 점수 분포)이 풍부해진다. 현재 수집 중인 공공 웹사이트 데이터는 수천 개 도메인 수준에 걸쳐 있으며, 이 데이터를 기관 유형별로 분류하고 주기적으로 재분석하는 파이프라인을 운영 중이다.

하지만 이 과정에서 실무적으로 부딪히는 어려움이 몇 가지 있다.

사이트 접근성 문제: 공공 웹사이트 중 일부는 크롤링을 막거나, 로그인 없이는 주요 페이지에 접근하기 어렵다. 이 경우 비교 가능한 데이터를 얻기 어렵다.

업데이트 시점의 불일치: A 기관 데이터는 3개월 전 수집, B 기관 데이터는 어제 수집했다면 비교가 왜곡될 수 있다. 최대한 유사한 시점의 데이터를 비교하도록 파이프라인을 관리하지만, 모든 기관을 동시에 재분석하는 건 현실적으로 어렵다.

기관 정보 매핑: 특정 도메인이 어느 기관 유형에 속하는지를 정확히 매핑하는 것도 생각보다 어렵다. 산하기관 사이트, 위탁 운영 사이트, 지원 기관 등 공공기관의 웹 생태계는 단순하지 않다.

이 어려움들을 솔직하게 밝히는 이유는, "ViewCheck 벤치마킹 데이터가 완벽하다"는 인상을 주고 싶지 않기 때문이다. 현재 상태는 "유용한 방향의 비교를 제공하는 수준"이지, "통계적으로 엄격하게 검증된 국가 공식 통계"와 같은 수준은 아니다. 그 차이를 이해하고 데이터를 사용하는 것이 중요하다.

순위를 시각화하는 것은 쉽다. 하지만 그 순위가 의미 있으려면, 뒤에 쌓인 데이터가 탄탄해야 한다.

GOV.UK 성과 프레임워크가 준 교훈 — "좋음"의 기준을 먼저 정의하라

벤치마킹 설계에서 우리가 참조한 해외 사례 중 하나가 영국 정부디지털서비스(GDS)의 성과 프레임워크(Performance Framework)다.

GDS는 오랫동안 공공 디지털 서비스를 벤치마킹하는 방식을 발전시켜 왔다. 그들이 직면한 핵심 문제 중 하나가 "다양한 서비스 유형을 동일한 기준으로 비교하는 것의 어려움"이었다. 여권 발급 서비스와 복지 신청 서비스를 같은 완료율로 비교하는 건 공정하지 않다 — 서비스의 성격이 다르기 때문이다.

GDS의 접근은 이 문제를 해결하기 위해 서비스 유형별로 다른 벤치마크를 적용하는 것이었다. GDS는 정부 서비스를 6가지 유형으로 나누고, 각 유형에 대해 "우수(Great)·양호(Good)·개선 필요(Requires Improvement)"의 기준을 다르게 설정했다(GDS Blog, "What makes a service 'Great'?", cddo.blog.gov.uk, 2023). 단순히 모든 서비스를 하나의 점수 체계로 비교하는 것이 아니라, 서비스 유형을 먼저 정의하고 그 안에서 "좋음"의 기준을 명확히 한 것이다.

또한 GDS는 부처 간 성과를 비교하고 개선을 지원하는 디지털 비즈니스 리뷰(Digital Business Review) 프로세스를 운영했는데, 각 부처에 커스텀 성과 대시보드를 제공하고, 부처들이 서로의 데이터를 공유할 수 있게 했다(GDS, "Creating a consistent approach to measuring how digital services perform", roadmap-for-modern-digital-government.campaign.gov.uk). 이 공유를 통해 "내 서비스가 비슷한 서비스 대비 어느 위치인가"를 파악하게 한 것이다.

이 접근에서 우리가 배운 것은 두 가지다. 첫째, 비교 전에 "이 서비스는 어떤 유형인가"를 먼저 정의해야 한다는 것. 둘째, 비교는 목적을 위한 수단이지 목적 자체가 아니라는 것 — GDS 프레임워크의 궁극적 목표는 "부처들이 서로에게서 배워 개선하는 것"이었지 "순위를 매기는 것"이 아니었다.

벤치마킹과 개선 로드맵을 어떻게 연결하는가

벤치마킹 데이터가 "현재 어디 있는가"를 보여준다면, 그것만으로는 절반이다. 나머지 절반은 "어디로, 어떻게 가면 되는가"이다. ViewCheck의 벤치마킹 카드가 24개 분석 카드 중 하나로 존재하는 이유 중 하나는, 다른 카드들과 연결되기 때문이다.

구체적으로는 이런 흐름이다.

벤치마킹 카드가 "동종 기관 대비 CP 점수가 특히 낮다"고 보여준다 → 컴포넌트(CP) 카드에서 구체적으로 어떤 규칙들이 미통과인지 확인 → 오류 리스트 카드에서 페이지별 문제 위치 확인 → 개선 로드맵 카드에서 우선순위별 개선 항목 확인.

이 연결이 없으면 벤치마킹은 그냥 "우리가 하위권이네"라는 상심으로 끝날 수 있다. 하지만 벤치마킹의 진짜 가치는 "왜 하위권인지"와 "무엇부터 고쳐야 동종 기관 평균을 따라잡을 수 있는지"를 짚어주는 데 있다.

이 연결을 설계할 때 우리가 특히 참고한 것은 벤치마킹 방법론 연구에서 반복되는 한 가지 원칙이었다. "좋은 벤치마킹 시스템은 단순 비교(comparison)를 넘어 학습(learning)을 가능하게 해야 한다"는 것. 스코어를 아는 것이 아니라, 왜 그 스코어인지, 어떤 기관의 무엇을 따라 하면 나아질 수 있는지를 알게 해야 한다는 뜻이다(Alderman, "Benchmarking: Seeking Best Practice", New Directions for Evaluation, Wiley, 2025).

ViewCheck 벤치마킹이 "동종 기관 중 CP 상위권 기관들의 공통적 특성"을 제시하려는 것도 이 맥락에서다. 단순히 "이 기관들이 높다"가 아니라, "이 기관들이 공통적으로 잘 갖춘 컴포넌트 구현 패턴은 무엇인가"까지 닿으려는 시도다. 이건 현재 완전히 구현된 기능은 아니다. 데이터가 충분히 쌓이고, 분석 방법론이 더 정교해져야 가능한 부분이다.

다중 페이지 분석이 벤치마킹 데이터의 질을 결정하는 이유

벤치마킹에서 데이터의 질을 결정하는 가장 근본적인 요소 중 하나로 다중 페이지 분석의 중요성을 다시 짚어야 한다.

메인 페이지 한 장의 KRDS 준수율만으로 기관을 비교한다면, 그 비교는 본질적으로 왜곡된다. 앞서 언급했듯, 대부분의 기관에서 메인 페이지 준수율이 가장 높다. 메인만 보면 모든 기관이 비교적 잘 갖춰져 있어, 동종 기관 간 격차가 실제보다 작게 보인다.

반대로, 다중 페이지(민원 신청 화면, 검색 화면, 로그인 화면, 게시판 목록, 상세 페이지 등)를 종합해서 보면 기관마다 취약한 페이지 유형이 달라 격차가 훨씬 선명하게 드러난다. 그리고 그 격차가 바로 실제 사용자 경험의 차이를 반영할 가능성이 높다.

ViewCheck가 기본적으로 다중 페이지 분석을 수행하는 이유, 그리고 벤치마킹 데이터를 수집할 때도 다중 페이지 기준 점수를 사용하는 이유가 여기에 있다. "메인 1장의 점수"가 아닌 "사이트 전체의 KRDS 준수 프로파일"로 기관들을 비교해야 진짜 의미 있는 벤치마킹이 된다.

이 원칙은 기술적 도전을 수반한다. 같은 기관을 다중 페이지로 분석하려면 더 많은 크롤링 시간이 필요하고, 더 많은 컴퓨팅 자원이 필요하다. 수백, 수천 개 기관을 동시에 다중 페이지로 분석하는 것은 상당한 인프라를 요구한다. 우리가 현재 크롤링 인프라를 어떻게 확장하고 있는지는 이 시리즈의 다른 편(플랫폼·R&D 트랙)에서 별도로 다룰 예정이다.

KRDS 준수율 벤치마킹의 한계 — 우리가 모르는 것

솔직한 연구 노트라면 한계도 명확히 적어야 한다.

한계 1: 자동 분석이 포착하지 못하는 것

KRDS 846규칙 중 상당수는 DOM 기반 자동 분석으로 판정 가능하지만, 일부는 사람이 직접 보고 판단해야만 하는 시각적 요소나 런타임 상호작용을 포함한다. 자동 분석이 "해당없음(N/A)"으로 처리하는 규칙들이 이 범주다. 이 N/A 비율을 줄이기 위해 Vision AI와 OCR을 활용하는 연구를 진행 중이지만, 현재 상태에서 자동 분석만으로는 100% 커버리지를 달성할 수 없다. 따라서 KRDS 준수율 벤치마킹 데이터는 "자동으로 판정 가능한 규칙들의 준수율" 기준임을 이해하고 봐야 한다.

한계 2: 스냅샷의 한계

분석 시점의 사이트 상태를 측정한 것이 벤치마킹 데이터다. 웹사이트는 계속 업데이트되기 때문에, 3개월 전 분석 결과가 지금도 그대로라는 보장이 없다. 주기적 재분석이 중요한 이유다.

한계 3: 준수율이 "좋은 사이트"를 의미하지 않을 수 있다

KRDS 준수율이 높다고 해서 반드시 사용하기 좋은 사이트는 아닐 수 있다. KRDS는 정부 디자인 시스템의 표준을 정의하지만, 모든 사용성 측면을 포괄하지는 않는다. 높은 준수율을 가진 사이트가 UX 측면에서 여전히 불편할 수 있고, 반대로 준수율이 다소 낮더라도 실제 사용자들이 쾌적하게 이용하는 사이트도 있을 수 있다. 따라서 KRDS 준수율은 웹 품질의 중요한 지표이지, 유일한 지표가 아니다.

"좋은 비교"를 위한 조건 — 비교 가능성(Comparability)

비교에는 조건이 있다. 아무 숫자나 나란히 놓는다고 유효한 비교가 되는 것이 아니다. 학술적으로 이것을 "비교 가능성(comparability)"이라고 부른다.

공공부문 벤치마킹 연구(Groningen 대학교 연구팀)는 좋은 벤치마킹 시스템의 핵심 요소 중 하나로 비교 가능성을 꼽으며, 이를 위해 "표준화된 정의와 방법론, 올바른 피어 그룹 선택"이 필요하다고 강조한다(University of Groningen, "Public sector benchmarking and performance improvement: what is the link and can it be improved?"). 단순히 "둘 다 점수를 냈다"가 아니라, "같은 기준으로, 같은 방법으로, 같은 유형 대상을 측정했다"는 것이 비교의 전제조건이라는 뜻이다.

ViewCheck가 KRDS 846규칙이라는 일관된 단일 기준을 사용하고, 동일한 크롤링·분석 파이프라인으로 모든 기관을 처리하는 것은 이 비교 가능성을 최대한 확보하기 위한 설계다. 기관마다 다른 분석 도구나 다른 기준으로 측정한 점수를 비교하면, 그것은 비교가 아니라 혼란이다.

물론 "같은 KRDS 규칙으로 측정했으니 비교 가능하다"는 것도 단순화다. 앞서 말한 것처럼 기관 유형, 서비스 범위, N/A 비율 등에서 기관마다 차이가 있어, 같은 점수가 항상 같은 의미를 갖지는 않는다. 이 복잡함을 인식하면서 비교를 해야 한다.

스코어카드를 나란히 놓는 것이 비교의 끝이 아니다. 측정 조건이 같아야 비로소 비교가 의미를 갖는다.

국제 벤치마킹의 시사점 — 한국이 OECD 1위인데 왜 개별 기관은 다를까

앞서 2023년 OECD 디지털정부지수(DGI)에서 한국이 33개 회원국 중 1위(0.935점)를 차지했다는 사실을 언급했다. 6개 부문 중 4개에서 1위, 나머지 2개에서 2위를 기록했다. 이 결과는 행정안전부와 디지털플랫폼정부위원회가 추진해 온 디지털 정부 전략의 성과를 국제적으로 인정받은 것이다(정부혁신1번가, "한국, OECD 디지털정부 평가 2회 연속 종합 1위", innogov.go.kr; OECD, "2023 OECD Digital Government Index").

그런데 OECD DGI 1위라는 국가 수준의 성과가 개별 공공기관 웹사이트의 KRDS 준수율과 단순히 일치하지는 않는다. OECD DGI는 중앙정부의 디지털 거버넌스·전략·데이터 정책·AI 활용 등을 평가하는 거시적 지수다. 반면 KRDS 준수율은 개별 웹사이트의 UI/UX 구현 세부 사항을 측정하는 미시적 지표다. 두 지표는 다른 것을 보고 있다.

이 간극을 이해하는 것이 중요하다. 한국이 OECD 디지털 정부 1위라는 것은 "국가 전략과 거버넌스 수준이 높다"는 의미이지, "모든 공공기관의 개별 웹사이트가 KRDS를 완벽하게 준수한다"는 의미가 아니다. 오히려 국가 전략이 앞서 있을수록, "전략이 실제 현장까지 얼마나 침투했는가"를 확인하는 현장 수준의 측정이 더 중요해진다. 그 현장 수준의 측정이 바로 ViewCheck가 하려는 일이다.

EU eGovernment Benchmark 2024에서도 비슷한 시사점이 있다. 전자정부 서비스의 전반적 수준이 높은 나라들에서도, 웹 접근성 기준 충족 비율이 생각보다 낮다는 것이 드러났다. 65%의 유럽 정부 웹사이트가 WCAG 기준을 충족하지 못한다는 데이터가 이를 보여준다. 전자정부 전략과 개별 사이트 구현 품질 사이에는 항상 간극이 있고, 그 간극을 측정하는 것이 현장 수준 벤치마킹의 역할이다.

벤치마킹 결과를 어떻게 활용해야 하는가 — 담당자를 위한 가이드

이론과 데이터를 넘어, 실제로 벤치마킹 결과를 받아든 담당자가 어떻게 활용해야 하는지를 마지막으로 이야기해 보자.

첫 번째 질문: "우리의 상대적 위치는 어디인가?"

벤치마킹 카드를 처음 봤을 때 확인해야 할 것은 전체 준수율의 동종 기관 대비 위치다. 상위 25%인지, 중간인지, 하위 25%인지. 이 위치 자체가 "우리가 얼마나 시급하게 개선이 필요한가"의 우선순위를 결정하는 데 도움이 된다.

두 번째 질문: "어느 카테고리가 특히 격차가 큰가?"

전체 위치를 확인했다면, 다음은 카테고리별로 들어간다. DS·CP·BP·SP 중 동종 기관 대비 특히 낮은 카테고리가 우선 개선 대상이다. 그 카테고리의 세부 규칙들을 오류 리스트나 컴포넌트 분석 카드에서 확인한다.

세 번째 질문: "메인 페이지와 전체 사이트의 격차가 얼마나 큰가?"

벤치마킹 데이터에서 메인 준수율과 사이트 전체 준수율 사이에 큰 격차가 있다면, 서브 페이지 개선이 시급하다는 신호다. 서브 페이지 중 어떤 유형(신청 화면, 로그인 화면, 검색 결과 등)에서 미통과가 집중되는지를 오류 리스트 카드에서 확인한다.

네 번째 질문: "동종 상위 기관은 어떤 면에서 다른가?"

가능한 경우, 같은 유형 기관 중 특정 카테고리에서 높은 점수를 받은 기관들의 공통점을 찾아본다. "그 기관들이 공통적으로 잘 구현된 컴포넌트는 무엇인가", "그 기관들의 디자인 토큰 적용 방식은 어떠한가" — 이런 질문이 개선의 방향을 구체화한다.

다섯 번째, 그러나 가장 중요한 질문: "순위보다 실제 사용자 경험이 나아지고 있는가?"

벤치마킹은 방향을 찾는 도구다. 하지만 최종 목표는 "동종 기관보다 높은 점수"가 아니라 "시민이 우리 사이트를 더 쉽고 편하게 쓸 수 있게 되는 것"이다. 이 목표를 잃지 않는 것이 벤치마킹을 올바르게 활용하는 핵심이다.

앞으로 연구할 것들 — 미완으로 남은 질문들

이 글을 마무리하면서, 우리가 아직 답을 찾고 있는 질문들을 솔직하게 적어두려 한다.

질문 1: 기관 유형 분류를 얼마나 세분화해야 하는가?

현재 사용하는 분류(중앙행정기관·광역자치단체·기초자치단체·공공기관 등)가 충분히 세밀한지 확신하기 어렵다. 더 세분화하면 비교 집단이 작아져 통계적 의미가 줄어들고, 덜 세분화하면 불공정한 비교가 된다. 이 균형을 어디에 잡을지는 데이터를 보면서 지속적으로 조정해야 할 문제다.

질문 2: N/A 비율이 다른 기관들을 어떻게 비교하는가?

서비스 범위가 다른 기관들은 N/A(해당없음)로 처리되는 규칙 수가 다르다. N/A를 제외한 실질 판정 규칙 기준으로 준수율을 계산하는 것이 더 공정할 수 있지만, 그러면 "더 많은 서비스를 갖춘 기관"과 "단순 정보 제공 기관"이 분모가 달라 여전히 비교 왜곡이 생긴다. 이 문제에 대한 표준적 해결책을 아직 찾지 못했다.

질문 3: 시간에 따른 변화를 어떻게 벤치마킹에 반영하는가?

현재 벤치마킹은 특정 시점의 스냅샷 비교다. "우리 기관은 6개월 전보다 얼마나 나아졌는가", "동종 기관들의 평균은 어떻게 변하고 있는가" — 이 시계열 비교가 가능해지려면 지속적인 데이터 축적과 추세 분석이 필요하다. 현재 진행 중인 연구 방향 중 하나다.

마무리 — 벤치마킹은 끝이 아니라 시작

점수 하나에서 출발한 이야기가 꽤 멀리 왔다. 동종 기관 비교라는 아이디어가 실제로 구현되기까지는 피어 그룹 정의, 데이터 수집 인프라, 비교 가능성 확보, 해석의 함정 피하기라는 여러 단계가 있다. 그 단계들이 각각 쉽지 않다는 것을 솔직하게 이야기했다.

ViewCheck 벤치마킹 기능은 "완성된 시스템"이 아니라 "계속 발전시켜 나가는 과정"에 있다. 더 많은 기관 데이터가 쌓일수록 비교의 기반이 탄탄해지고, 분석 방법론이 정교해질수록 비교의 공정성이 높아진다. 지금 단계에서 이 기능이 제공하는 것은 "유용한 방향의 비교"이지, "통계적으로 완벽한 순위"가 아니다.

그리고 가장 중요한 것은 — 벤치마킹은 시작이지 끝이 아니라는 점이다. "우리가 동종 기관 하위 30%다"라는 정보가 가치 있는 건, 그게 "어디를 고쳐야 하는가"로 이어질 때다. 순위 확인에서 개선 계획으로, 개선 계획에서 실제 변화로 — 그 연결이 이루어질 때 비로소 벤치마킹이 의미를 갖는다.

공공기관 웹사이트의 KRDS 준수율 데이터를 어떻게 의미 있게 비교하고, 그 비교에서 실제 개선의 방향을 끌어낼 수 있는지 — 이 질문을 계속 들고 가겠다. 다음 편에서 이어진다.

참고문헌

본문에 인용한 출처는 작성 시점에 실재 여부를 검증했다. 국내 공식 자료와 해외 연구·기관 자료를 함께 실었다.

국내 — 공식 기준 / 정책자료

행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025. 6. 25. 일부개정). 국가법령정보센터. https://www.law.go.kr/admRulLsInfoP.do?admRulId=37565
행정안전부, 「전자정부 웹사이트 품질관리 지침」 일부개정 및 「전자정부 웹사이트 품질관리 가이드」 수정본 안내(고시 제2025-46호). https://www.mois.go.kr/frt/bbs/type001/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000016&nttId=118636
행정안전부, 「2023년도 공공 웹사이트 품질관리 수준진단 자료」. https://www.mois.go.kr/frt/bbs/type013/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000006&nttId=102145
행정안전부, 「2025년 공공 웹앱 품질관리 수준진단 및 UI/UX 국민평가 설명회 자료 공유」. https://www.mois.go.kr/frt/bbs/type001/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000045&nttId=120503
한국지능정보사회진흥원(NIA), 「웹 접근성 실태조사」 목록 페이지(연도별). https://www.nia.or.kr/site/nia_kor/ex/bbs/List.do?cbIdx=99873
KRDS(범정부 UI/UX 디자인시스템) 공식 사이트 — 가이드라인 구성 및 기관 유형별 적용 기준. https://www.krds.go.kr/
대한민국 정책브리핑, "한국, OECD 디지털정부 평가 2회 연속 종합 1위". 2024. https://www.korea.kr/news/policyNewsView.do?newsId=148925394
KDI 경제교육·정보센터, "경제협력개발기구(OECD)가 시행한 국제 디지털정부 평가에서 2회 연속 종합 1위". https://eiec.kdi.re.kr/policy/materialView.do?num=247654

해외 — 벤치마킹 방법론 / 전자정부 연구

OECD, "2023 OECD Digital Government Index". 2024. https://www.oecd.org/en/publications/2023-oecd-digital-government-index_1a89ed5e-en.html
Capgemini / European Commission, "Digital Decade 2024: eGovernment Benchmark". https://digital-strategy.ec.europa.eu/en/library/digital-decade-2024-egovernment-benchmark
Capgemini, "eGovernment Benchmark Report 2024: Steady growth in digital government maturity". https://www.capgemini.com/us-en/insights/research-library/egovernment-benchmark-report-towards-digital-government/
Bogdan Cerovac, "Comparison of accessibility of e-government websites in Europe in 2024". cerovac.com/a11y. 2024. https://cerovac.com/a11y/2024/07/comparison-of-accessibility-of-e-government-websites-in-europe-in-2024/
Chua, Y. P. L., et al., "Mapping and contesting peer selection in digitalized public sector benchmarking". Financial Accountability & Management, Wiley, 2022. https://onlinelibrary.wiley.com/doi/10.1111/faam.12306
Alderman, "Benchmarking: Seeking Best Practice". New Directions for Evaluation, Wiley, 2025. https://onlinelibrary.wiley.com/doi/10.1002/ev.20634
University of Groningen, "Public sector benchmarking and performance improvement: what is the link and can it be improved?". https://research.rug.nl/en/publications/public-sector-benchmarking-and-performance-improvement-what-is-th/
GDS(UK Government Digital Service), "What makes a service 'Great'?". CDDO Blog. 2023. https://cddo.blog.gov.uk/2023/09/01/what-makes-a-service-great/
GDS, "Creating a consistent approach to measuring how digital services perform". Roadmap for Modern Digital Government. https://roadmap-for-modern-digital-government.campaign.gov.uk/transparency/measuring-how-digital-services-perform/

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

046편 : 래디어스 값을 px 또는 % 단위로 설정하고 있다.

ViewCheck — Mon, 28 Sep 2026 23:17:43 +0900

046편 : 래디어스 값을 px 또는 % 단위로 설정하고 있다.

KRDS 체크리스트 항목 DS-046 · 디자인 스타일 > 형태 〈846 규칙 완전 분해 시리즈 ㊻〉 — "고정 둥글기는 px, 원형은 %": 레디어스 단위의 선택

0. 들어가며 — 둥글기를 표현하는 두 단위

레디어스의 단계(43편)·범위(44편)·천장(45편)을 봤습니다. 이번엔 그 값을 어떤 단위로 표현할지입니다.

레디어스를 표현하는 단위는 주로 두 가지 — px(픽셀) 와 %(백분율) 입니다. DS-046은 이 둘을 쓰라고 규정합니다. 흥미로운 건, 글자 크기에서는 px 대신 rem을 권했는데(35편), 레디어스에서는 px를 허용한다는 것입니다. 왜 다를까요? 그리고 px와 %는 각각 언제 쓸까요? 이번 편은 레디어스 단위의 선택 기준을 풀어냅니다.

1. 규칙 원문 — 두 단위

DS-046 (디자인 스타일 > 형태) "래디어스 값을 px 또는 % 단위로 설정하고 있다."

레디어스를 px(고정 픽셀) 또는 %(백분율) 단위로 쓰라는 뜻입니다.

정리: 레디어스는 px 또는 % 단위로 설정하라. 이게 DS-046입니다.

2. px와 %의 차이 — 고정 둥글기 vs 원형

두 단위는 다른 종류의 둥글기를 만듭니다.

px — 고정된 둥글기

border-radius: 8px은 '모서리를 반지름 8픽셀로 둥글게'입니다. 컴포넌트 크기와 무관하게 둥글기가 8px로 고정되죠. 버튼·카드·입력칸처럼 '모서리만 살짝 둥근' 일반 요소에 씁니다. 레디어스 5단계(43편)와 2~12px 범위(44편)가 바로 이 px 값입니다.

% — 비율 기반 둥글기 (원형)

border-radius: 50%은 '모서리를 요소 크기의 50%로 둥글게'입니다. 정사각형에 50%를 주면 완전한 원이 됩니다. 그래서 %는 주로 원형 요소(프로필 사진, 원형 아이콘 버튼 등)에 씁니다. 요소 크기에 비례해 둥글기가 정해지므로, 크기가 바뀌어도 원형이 유지됩니다.

즉 px는 '모서리 둥글기', %는 '원형 만들기' 에 주로 쓰입니다. 살짝 둥근 모서리는 px로, 완전한 원은 %로요. 둘 다 정당한 단위이고, 만들려는 형태에 따라 선택합니다.

3. 왜 글자는 rem인데 레디어스는 px인가

35편에서 글자 크기는 px 대신 rem을 쓰라고 했는데, 레디어스는 px를 허용합니다. 이 차이가 헷갈릴 수 있어 짚어둡니다.

글자 크기에 rem을 쓰는 이유는 사용자가 글자를 키울 때 함께 커지게 하기 위해서였습니다(접근성). 글자는 '읽는 것'이라 사용자 확대 대응이 중요하죠.

반면 레디어스는 '읽는 것'이 아니라 '형태'입니다. 모서리 둥글기가 사용자 설정에 따라 커질 필요는 없습니다. 오히려 둥글기는 컴포넌트와 일관되게 고정되는 것이 자연스럽죠. 그래서 레디어스는 px로 고정해도 접근성 문제가 없습니다. 단위 선택은 '그 속성이 사용자 확대에 반응해야 하는가'에 따라 갈립니다 — 글자(읽기)는 반응해야 하니 rem, 둥글기(형태)는 고정이 자연스러우니 px. 각 속성의 성격에 맞는 단위를 쓰는 것입니다.

다만 원형처럼 '요소 크기에 비례'해야 하는 경우엔 %를 씁니다. 즉 px(고정)와 %(비례)를 형태의 필요에 따라 선택하는 것이죠.

4. 흔한 위반 패턴 / 점검 / 개선

흔한 위반 패턴

함정 ① 부적절한 단위. 일반 모서리에 % 사용 → 크기 따라 둥글기 변동, 예측 불가. → 고정 둥글기는 px. 함정 ② 작은 요소 50%. 작은 버튼에 50% → 원형화·일그러짐(DS-050). → px 단위 적정값. 함정 ③ 단위 혼란. px/% 외 모호한 단위 → px 또는 %로 통일.

무엇을 점검하나

단위 — 레디어스가 px 또는 % 단위인가.
용도 적합성 — 고정 둥글기는 px, 원형은 %로 적절히 쓰였는가.
작은 요소 — 작은 컴포넌트에 50%가 오용되지 않았는가(DS-050).

Before / After

/* ✅ 고정 둥근 모서리는 px */
.btn { border-radius: 8px; }
.card { border-radius: 12px; }

/* ✅ 완전 원형은 % */
.avatar { border-radius: 50%; }   /* 프로필 원형 */

5. 누가 담당하나 / 우리 사이트에 해당될까?

역할	책임
퍼블리셔/개발	레디어스를 px(고정)·%(원형) 단위로 적절히 구현
디자이너	형태(모서리 vs 원형)에 맞는 단위 지정

기관 유형	DS-046 적용
중앙행정기관(대표·운영) / 공공기관 / 지자체	✅ 필수

둥근 요소가 있는 모든 사이트 = 해당.

6. 30초 자가진단 + FAQ

✅ 30초 자가진단

□ 레디어스를 px 또는 % 단위로 쓰나요?
□ 고정 둥근 모서리에 px를 쓰나요?
□ 완전 원형에만 %(50%) 를 쓰나요?
□ 작은 요소에 50%를 오용하지 않나요(DS-050)?

❓ FAQ

Q1. 왜 글자는 rem인데 레디어스는 px인가요? 글자는 '읽는 것'이라 사용자 확대에 반응해야 해서 rem을 씁니다(35편). 레디어스는 '형태'라 사용자 확대에 반응할 필요가 없어 px로 고정해도 됩니다. 속성의 성격에 맞는 단위를 쓰는 것입니다.

Q2. % 단위는 언제 쓰나요? 주로 완전 원형(프로필 사진, 원형 아이콘 등)에 50%로 씁니다. 요소 크기에 비례해 둥글기가 정해져, 크기가 바뀌어도 원형이 유지됩니다.

Q3. 일반 버튼에 50%를 주면 안 되나요? 작은 컴포넌트에 50%는 권장하지 않습니다(DS-050). 알약이나 원형으로 일그러질 수 있습니다. 일반 모서리는 px 단위의 적정값(2~12px)을 쓰세요.

Q4. rem으로 레디어스를 줘도 되나요? DS-046은 px·%를 명시합니다. 레디어스는 형태라 px 고정이 자연스럽습니다. 굳이 rem을 쓸 필요는 없습니다.

7. 마무리 — 단위는 형태의 필요에 따라

DS-046의 메시지는 단위 선택의 원리를 담습니다.

고정된 둥근 모서리는 px, 비율 기반 원형은 % — 만들려는 형태에 맞는 단위를 쓴다.

px는 컴포넌트 크기와 무관한 고정 둥글기를, %는 크기에 비례하는 원형을 만듭니다. 글자(읽기)는 사용자 확대에 반응해야 해서 rem을 썼지만, 레디어스(형태)는 고정이 자연스러워 px를 씁니다. 각 속성의 성격에 맞는 단위를 쓰는 것 — 이것이 단위 선택의 원리입니다.

다음 편은 레디어스의 '일관성'을 다룹니다. DS-047 — "함께 사용되는 비슷한 크기의 구성 요소는 래디어스 값을 동일하게 적용한다." 비슷한 요소끼리 둥글기를 맞춰야 하는 이유를 살펴봅니다.

다음 편 예고 ▶ 「047. 함께 사용이 되는 비슷한 크기의 구성 요소는 래디어스 값을 동일하게 적용하고 있다.」

우리 사이트의 레디어스 단위가 적절한지 확인하려면? ViewCheck는 레디어스가 px·% 단위로 쓰였는지, 고정 둥글기와 원형이 적절히 구분됐는지를 진단합니다.

참고 출처

KRDS 형태(Shape)·디자인 토큰 가이드 — https://www.krds.go.kr/html/site/style/style_07.html

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

기능은 베껴도 방법론은 못 베낀다 — 겉보기 기능 뒤에 숨은 '방법'을 알아보는 법

ViewCheck — Mon, 28 Sep 2026 23:17:37 +0900

기능은 베껴도 방법론은 못 베낀다 — 겉보기 기능 뒤에 숨은 '방법'을 알아보는 법

들어가며 — "기능 목록은 다 똑같던데요"의 함정

이번 주 월요일에는 "왜 하필 특허가 다섯 건이나 필요했나"를 말씀드렸습니다. 겉으로 드러나는 화면이나 버튼 같은 기능은 누구나 흉내 낼 수 있지만, 그 기능을 실제로 굴러가게 만드는 방법(방법론)은 쉽게 베낄 수 없다는 이야기였습니다. 오늘은 그 이야기를 한 발 더 밀어보려 합니다. "기능은 베껴도 방법론은 못 베낀다"는 말이, 실제 현장에서 어떻게 드러나는지를요.

도구를 고르는 입장에서 가장 흔히 빠지는 함정이 하나 있습니다. 바로 "기능 목록 비교"입니다. A 도구도 접근성 검사가 된다고 하고, B 도구도 된다고 합니다. A도 AI 분석을 준다 하고, B도 준다 합니다. 그래서 표를 만들어 항목마다 동그라미를 치다 보면, "둘 다 다 있네, 그럼 싼 걸로" 하는 결론에 도달합니다. 아주 자연스러운 판단입니다. 기능 목록만 놓고 보면 실제로 거의 똑같아 보이니까요.

그런데 막상 그 둘을 같은 사이트에 나란히 돌려보면, 결과가 딴판인 경우가 많습니다. 어느 쪽은 위반을 한 무더기 뱉어놓고 끝나는데, 어느 쪽은 그 위반에 우선순위를 붙이고 어디를 어떻게 고칠지까지 정리해 줍니다. 어느 쪽은 돌릴 때마다 결과가 조금씩 흔들리는데, 어느 쪽은 어제와 오늘이 같게 나옵니다. 기능 이름은 분명 같은데 왜 이런 차이가 날까요. 답은 하나입니다. 기능 이름은 같아도, "그 기능을 어떻게 만들었느냐"가 다르기 때문입니다.

오늘은 그 "같은 기능, 다른 결과"가 갈리는 지점을 짚고, 겉보기 기능 뒤에 숨은 방법을 알아보는 법을 정리하려 합니다. 미리 말씀드리면, ViewCheck가 그 방법의 핵심으로 삼은 것은 세 가지입니다. 세 시점을 하나의 자로 교차 판정하는 것, 두 엔진을 질서 있게 합치는 것, 그리고 그 결과를 위험도로 정리하는 것. 이 세 가지가 오늘의 뼈대입니다.

한 가지 먼저 짚어두겠습니다. 오늘 이야기는 특정 제품을 깎아내리려는 게 아닙니다. "다른 도구는 못 한다" 같은 단정도 하지 않겠습니다. 그저 "겉보기 기능과 그 뒤의 방법은 다른 층위의 이야기"라는 것, 그리고 "그 방법을 알아보는 눈이 있으면 도구를 훨씬 잘 고를 수 있다"는 것을 보여드리려는 겁니다. 사례는 전부 익명으로, 어디서나 비슷하게 반복되는 전형을 하나로 묶어서 봅니다.

비유를 하나 들어보겠습니다. 식당을 고를 때 메뉴판만 보고 고르는 경우를 떠올려 보십시오. A 식당도 파스타를 팔고, B 식당도 파스타를 팝니다. 메뉴판에 적힌 이름은 똑같이 "토마토 파스타"입니다. 그런데 실제로 나온 접시는 전혀 다를 수 있습니다. 한쪽은 좋은 재료를 제대로 손질해서 냈고, 한쪽은 대충 데워서 냈으니까요. 메뉴판의 이름이 같다고 접시가 같은 게 아닙니다. 접시를 가르는 건 이름이 아니라 레시피, 즉 그 요리를 어떻게 만드느냐입니다. 점검 도구도 정확히 이렇습니다. 기능 목록은 메뉴판이고, 그 기능을 만드는 방법은 레시피입니다. 오늘 글은 "메뉴판 말고 레시피를 보는 법"에 관한 이야기라고 생각하시면 됩니다.

본론 1 — 같은 기능 이름 아래 결과가 갈리는 세 자리

먼저, 같은 기능 이름 아래에서 결과가 실제로 갈리는 대표적인 자리 세 곳을 보겠습니다. 접근성 검사, AI 분석, 그리고 리포트. 이 셋은 어느 점검 도구나 "됩니다"라고 말하는 기능인데, 그 "됩니다" 안의 깊이가 천차만별입니다.

이 세 자리를 하나씩 보기 전에, 한 가지를 미리 붙잡아 두면 좋겠습니다. 아래에서 볼 차이들은 전부 "기능이 있느냐 없느냐"의 문제가 아니라 "그 기능이 얼마나 깊으냐"의 문제라는 점입니다. 세 자리 모두, 두 도구가 다 "됩니다"라고 답할 수 있습니다. 그런데 그 "됩니다"의 속을 열어 보면 깊이가 다릅니다. 그 깊이를 만드는 게 방법이고요.

접근성 검사 — "검사한다"는 같지만 깊이가 다르다

"접근성 검사"는 어느 도구나 한다고 합니다. 그런데 어떻게 검사하느냐가 갈립니다. 누구는 자동 검사 도구 하나만 돌려서 그 결과를 그대로 뱉습니다. 누구는 여러 검사 엔진을 교차로 돌려서, 한쪽이 놓친 것을 다른 쪽으로 잡습니다. 누구는 코드만 훑어서 "이미지에 대체 텍스트가 없다" 정도만 잡는데, 누구는 화면까지 봐서 "이 이미지로 만든 버튼은 라벨이 없어서 화면 낭독기가 못 읽는다"까지 잡습니다. 검사 이름은 똑같이 "접근성 검사"인데, 파고드는 깊이가 다릅니다.

이 차이가 왜 중요하냐면, 얕게 검사한 결과와 깊게 검사한 결과가 겉으로는 구분이 안 되기 때문입니다. 둘 다 "접근성 검사 완료"라는 라벨을 답니다. 둘 다 그럴싸한 목록을 보여줍니다. 그런데 얕은 검사는 정작 중요한 문제를 통째로 놓치고 있을 수 있습니다. 겉보기로는 둘 다 "검사가 됐다"이지만, 실제로 잡아낸 것은 다릅니다.

더 곤란한 건, 얕은 검사가 오히려 안심을 준다는 점입니다. 문제를 적게 잡으니 "우리 사이트는 괜찮네"라는 느낌을 줍니다. 그런데 그건 문제가 없어서가 아니라, 못 봐서 안 보이는 것일 수 있습니다. 깊게 검사하는 도구는 오히려 문제를 더 많이 꺼내 놓아 처음엔 불편하게 느껴질 수 있지만, 그게 실제 사용자가 겪는 현실에 더 가깝습니다. "적게 나와서 좋은 도구"가 아니라 "실제를 정확히 비추는 도구"가 좋은 도구입니다. 이 구분은 검사 결과의 개수만 봐서는 알 수 없고, 그 검사가 어떤 방법 위에 서 있는지를 봐야 알 수 있습니다.

AI 분석 — "AI를 쓴다"는 같지만 쓰는 법이 다르다

"AI 분석 제공"도 흔한 문구입니다. 그런데 AI를 어떻게 쓰느냐가 천지 차이를 만듭니다. 누구는 AI에게 화면을 통째로 던지고 "알아서 판단해"라고 맡깁니다. 그러면 결과가 들쑥날쑥합니다. 어제는 통과였던 게 오늘은 미통과로 나오고, 같은 화면을 봐도 판정이 흔들립니다. 누구는 규칙 엔진으로 정확한 뼈대를 먼저 만들어 두고, AI는 그 뼈대 위의 빈칸만 채우게 씁니다. 그러면 결과가 일관됩니다.

"AI를 쓴다"는 같은 말인데, 토대 위에서 쓰느냐 통째로 맡기느냐가 결과의 신뢰를 가릅니다. 통째로 맡긴 AI는 그럴듯한 문장을 잘 만들지만, 같은 질문에 매번 다르게 답할 수 있습니다. 토대 위에서 빈칸만 채우는 AI는, 뼈대가 이미 정해져 있으니 흔들릴 여지가 적습니다. 이 차이는 기능 목록에는 절대 안 적힙니다. 둘 다 그냥 "AI 분석"이라고 적히니까요.

리포트 — "보고서를 준다"는 같지만 쓸모가 다르다

"리포트 제공"도 마찬가지입니다. 누구는 위반 목록을 길게 뽑아서 끝냅니다. 화면 가득 빨간 표시가 뜨고, 항목이 수백 개 나열됩니다. 그런데 그 목록을 받아 든 담당자는 막막합니다. 어느 게 급한지, 뭘 먼저 고쳐야 하는지, 어떻게 고치는지가 없기 때문입니다. 위반을 "찾는" 데서 멈춘 리포트입니다.

누구는 그 위반에 우선순위를 매기고, "어디를, 어떻게 고치라"는 개선 방향까지 붙입니다. 같은 "리포트 제공"인데, 하나는 목록만 주고 하나는 실제 업무로 이어지는 지도를 줍니다. 아래는 ViewCheck가 위반 항목 하나하나에 우선순위와 개선 방향을 붙여 정리한 종합 결론 화면인데, "보고서를 준다"가 같은 문구라도 그 안의 쓸모가 이렇게 달라질 수 있다는 걸 보여줍니다.

이 세 자리에서 보듯, 기능 이름은 표면입니다. "접근성 검사", "AI 분석", "리포트 제공" — 이 라벨들은 누구나 붙일 수 있습니다. 그 라벨 밑의 "어떻게"가 결과를 만듭니다. 그리고 그 "어떻게"가 바로 오늘 이야기할 방법론입니다.

본론 2 — 겉보기 기능은 베껴도, '방법'은 왜 못 베끼나

그럼 ViewCheck가 말하는 그 "방법"이란 구체적으로 무엇일까요. 화면과 버튼 같은 겉모습이 아니라, 결과의 깊이를 만드는 그 뒷단의 절차 말입니다. 세 가지로 나눠 보겠습니다. 이 셋이 오늘 글의 심장입니다.

방법 ① — 세 시점을 하나의 자로 교차 판정한다

첫 번째 방법은, 하나의 사이트를 서로 다른 세 시점에서 보고 그 결과를 같은 잣대로 합치는 것입니다. 세 시점이란 설계 시점, 운영 시점, 맥락 시점을 말합니다.

설계 시점은 사이트가 만들어지기 전, 디자인 단계를 봅니다. 디자인 파일에서 색·글자·간격 같은 값을 뽑아 표준과 대조합니다. 아직 만들기 전이라, 여기서 잡으면 가장 싸게 고칠 수 있습니다. 운영 시점은 지금 실제로 돌아가는 진짜 사이트를 봅니다. 사용자가 실제로 마주하는 그 화면을, 그 데이터가 들어찬 상태 그대로 봅니다. 맥락 시점은 그 위에서 "이 화면이 실제 상황에서 말이 되는가"를 판단합니다. 규칙만으로는 딱 잘라 말하기 어려운, 판단이 필요한 자리를 봅니다.

여기서 중요한 건, 이 세 시점을 그냥 따로따로 보는 게 아니라는 점입니다. 세 시점 모두를 하나의 규칙 체계로 교차 판정한다는 게 핵심입니다. ViewCheck의 규칙 체계는 846개 규칙으로 이루어져 있습니다. 디자인 스타일 120개, 컴포넌트 446개, 기본 패턴 108개, 서비스 패턴 172개. 이 846개가 세 시점 모두에 같은 자로 적용됩니다. 설계 단계에서 잡은 문제와 운영 단계에서 잡은 문제가 같은 규칙 언어로 표현되니, 서로 비교하고 합칠 수 있습니다.

이게 왜 따라 하기 어렵냐면, 시점 하나만 보는 도구를 만드는 건 어렵지 않지만, 세 시점을 하나의 자로 묶어서 서로 충돌 없이 합치는 건 시간과 시행착오가 들기 때문입니다. 설계에서 본 "이 색이 표준과 어긋난다"와 운영에서 본 "이 화면에 색이 잘못 쓰였다"를 같은 규칙 아래 놓으려면, 규칙 체계 자체가 세 시점을 다 감당하도록 설계돼 있어야 합니다. 화면 이름 하나 따라 적는 것과는 차원이 다른 일입니다.

조금 더 풀어보겠습니다. 왜 하필 세 시점을 하나로 묶는 게 그렇게 중요할까요. 세 시점은 각자 잘 보는 게 다르기 때문입니다. 설계 시점은 아직 만들기 전이라 값을 정확히 대조할 수 있지만, 실제로 어떻게 굴러갈지는 모릅니다. 운영 시점은 진짜로 굴러가는 것을 보지만, 만들기 전에 미리 잡을 수는 없습니다. 맥락 시점은 규칙만으로 딱 잘라 말하기 어려운 자리를 판단하지만, 그 판단이 흔들리지 않으려면 밑에 단단한 규칙 뼈대가 있어야 합니다. 이 셋은 서로의 약점을 메워 줍니다. 그런데 셋이 각자 다른 언어로 결과를 내면 서로 메워 줄 수가 없습니다. 세 시점을 846개 규칙이라는 공통 언어로 묶는 이유가 바로 이겁니다. 같은 언어를 써야 설계에서 놓친 것을 운영에서 잡고, 운영에서 애매한 것을 맥락에서 판단하는 협업이 성립합니다.

846이라는 숫자도 그냥 나온 게 아닙니다. 디자인 스타일 120개는 색·글자·간격 같은 값을 수치로 대조하는 규칙이고, 컴포넌트 446개는 버튼·입력창·표 같은 요소가 제대로 갖춰졌는지 보는 규칙이고, 기본 패턴 108개는 폼 구조나 오류 처리 같은 화면 짜임새를 보는 규칙이고, 서비스 패턴 172개는 검색·로그인·신청 같은 실제 서비스 흐름을 보는 규칙입니다. 이 네 갈래가 합쳐져 하나의 자를 이룹니다. 이 자가 있으니 "어느 항목이 어긋났는지"를 세 시점 모두에서 같은 방식으로 말할 수 있습니다. 자가 없으면 시점마다 제각기 다른 말을 하게 되고, 그 결과는 합쳐지지 않습니다.

방법 ② — 두 엔진을 질서 있게 합친다

두 번째 방법은, 성격이 다른 두 개의 분석 엔진을 질서 있게 합치는 것입니다.

하나는 코드의 구조를 읽어서 규칙으로 판정하는 엔진입니다. 화면 뒤의 구조를 뜯어보고, "이 버튼에 라벨이 있나", "이 표에 제목 행이 있나", "이 색과 배경의 대비가 기준을 넘나" 같은 것을 값으로 따집니다. 구조로 판단할 수 있는 것은 이 엔진이 빠르고 정확하게 잡습니다. 다른 하나는 화면을 눈으로 보듯 시각적으로 분석하는 엔진입니다. 코드만으로는 알 수 없는 것 — 이미지로 만든 버튼, 그림 안에 들어간 글자, 비표준 방식으로 그려진 컴포넌트 — 을 화면을 봐서 감지합니다.

이 둘을 그냥 붙여 놓으면 오히려 결과가 엉킵니다. 한쪽이 "통과"라 했는데 다른 쪽이 "미통과"라 하면, 어느 쪽을 믿어야 할지 혼란스러워집니다. 그래서 순서와 규칙이 필요합니다. ViewCheck의 방법은 이렇습니다. 구조로 판정할 수 있는 것은 규칙 엔진이 먼저 확정합니다. 규칙 엔진이 확정한 판정은 시각 엔진이 뒤집지 않습니다. 시각 엔진은 규칙 엔진이 "해당 없음"으로 남긴 자리, 즉 구조만으로는 판단이 안 되는 빈칸을 채우는 역할을 맡습니다. 이렇게 역할을 나누면 두 엔진이 서로 충돌하지 않고, 각자 잘하는 영역을 맡아 결과를 더 깊게 만듭니다.

이 "질서 있게 합치기"가 방법의 핵심입니다. 두 엔진을 각각 만드는 것보다, 둘을 충돌 없이 협업시키는 절차를 세우는 게 훨씬 어렵습니다. 어느 쪽이 먼저 판정하고, 어느 쪽이 어디를 채우고, 둘의 결과가 어긋날 때 무엇을 우선하는지 — 이 순서를 잘못 잡으면 결과가 오히려 나빠집니다. 그 순서를 시행착오 끝에 잡아 두었다는 게 겉보기 기능에는 안 보이는 방법입니다.

여기서 한 가지 오해를 풀어두고 싶습니다. "두 엔진을 쓴다"고 하면, 흔히 시각 엔진이 규칙 엔진의 부족한 부분을 도와주는 보조 역할이라고 생각하기 쉽습니다. 그런데 그렇지 않습니다. 둘은 각자 잘하는 영역이 완전히 다른, 대등한 분업 관계입니다. 구조로 판단할 수 있는 것 — 라벨이 붙었는지, 대비가 기준을 넘는지 — 은 규칙 엔진이 훨씬 빠르고 정확합니다. 화면을 봐야만 알 수 있는 것 — 이미지 안에 글자가 들어갔는지, 표준을 벗어난 방식으로 그려진 버튼인지 — 은 시각 엔진만 잡을 수 있습니다. 어느 쪽도 다른 쪽을 대신할 수 없습니다. 그래서 둘 중 하나만 있는 도구는, 나머지 절반을 통째로 못 보는 셈입니다. 코드만 보는 도구는 화면에만 드러나는 문제를 놓치고, 화면만 보는 도구는 구조로 정밀하게 따져야 하는 것을 놓칩니다.

그리고 이 협업에는 한 가지 분명한 원칙이 있습니다. 규칙 엔진이 구조로 "통과" 또는 "미통과"를 확정한 것은, 시각 엔진이 뒤집지 않는다는 겁니다. 만약 이 원칙이 없으면, 규칙 엔진은 "통과"라 하고 시각 엔진은 "미통과"라 하는 충돌이 여기저기서 생깁니다. 그러면 어느 쪽을 믿어야 할지 알 수 없어지고, 결과 전체의 신뢰가 무너집니다. 그래서 확정된 판정은 건드리지 않고, 시각 엔진은 오직 규칙 엔진이 "구조만으로는 판단 못 하겠다"며 남긴 빈칸만 채웁니다. 이렇게 역할과 우선순위를 못 박아 두었기 때문에, 두 엔진의 결과가 하나로 깔끔하게 모입니다. 이 원칙 하나를 세우는 데도 적지 않은 시행착오가 있었습니다.

아래는 규칙 엔진이 화면 속 컴포넌트를 인식해 그 상세 판정을 펼쳐 보여주는 화면입니다. 코드 뒤가 아니라 화면에 보이는 컴포넌트 단위로 점검한 결과가 이렇게 생겼습니다.

방법 ③ — 결과를 위험도로 정리한다

세 번째 방법은, 그렇게 나온 판정을 위험도로 정리하는 것입니다.

846개 규칙을 돌리면 위반이 여럿 나옵니다. 그런데 위반이 다 똑같이 급한 건 아닙니다. 어떤 위반은 당장 사용자가 서비스를 못 쓰게 만드는 심각한 것이고, 어떤 위반은 불편하지만 서비스는 돌아가는 것이고, 어떤 위반은 다듬으면 좋은 정도입니다. 이걸 구분하지 않고 한 무더기로 던지면, 받아 든 사람은 "다 고쳐야 하나" 싶어 손을 못 댑니다.

그래서 ViewCheck는 위반마다 위험도 등급을 매깁니다. 가장 급한 것부터 나중에 다듬을 것까지 층을 나눠서, "이것부터 고치세요"를 분명히 합니다. 그리고 각 위반에 "어디를 어떻게 고치라"는 개선 방향을 붙입니다. 그러면 위반 목록이 "찾은 것"에서 "할 일"로 바뀝니다. 앞서 본 종합 결론 화면이 바로 이 정리의 결과입니다.

이 위험도 정리도 겉보기로는 단순해 보입니다. "그냥 급한 순서로 줄 세운 거 아니냐" 싶으실 수 있습니다. 그런데 무엇을 급하다고 볼지, 어떤 기준으로 층을 나눌지, 페이지가 여러 개일 때 한 페이지의 심각한 위반과 여러 페이지에 흩어진 가벼운 위반 중 무엇을 위로 올릴지 — 이런 판단이 쌓여야 위험도 정리가 실제로 쓸모 있어집니다. 이 역시 하루아침에 나오는 게 아니라, 규칙 하나하나에 무게를 매기고 다듬은 결과입니다.

특히 페이지가 많은 사이트에서 이 위험도 정리의 값어치가 드러납니다. 한 페이지만 보면 위반이 몇 개 안 되니 그냥 눈으로 훑어도 됩니다. 그런데 수십, 수백 페이지를 보면 위반이 수천 건씩 쌓입니다. 이걸 그냥 한 줄로 나열하면 아무도 못 봅니다. 여기서 "같은 위반이 여러 페이지에 반복되는가", "이 위반이 사용자의 핵심 흐름을 막는가" 같은 걸 따져 위로 끌어올려야, 담당자가 "그래, 이것부터"라고 손을 댈 수 있습니다. 위반을 찾는 것과, 그 위반을 우선순위 있는 할 일로 바꾸는 것은 전혀 다른 일입니다. 앞의 것은 기능이고, 뒤의 것은 방법입니다.

세 방법을 합치면 이렇습니다. 세 시점을 846개 규칙 하나의 자로 교차 판정하고, 두 엔진을 질서 있게 합쳐 결과를 깊게 만들고, 그 결과를 위험도로 정리해 할 일로 바꿉니다. 화면과 버튼은 이 위에 얹힌 겉모습일 뿐이고, 결과의 깊이를 만드는 건 이 세 방법입니다.

그리고 이 세 방법은 따로 노는 게 아니라 서로 맞물려 돌아갑니다. 세 시점을 하나의 자로 묶는 방법이 없으면 여러 시점의 결과를 합칠 수 없고, 두 엔진을 질서 있게 합치는 방법이 없으면 각 항목의 판정이 흔들리고, 위험도로 정리하는 방법이 없으면 아무리 정확히 판정해도 할 일로 이어지지 않습니다. 셋 중 하나만 빠져도 나머지의 값어치가 절반으로 줄어듭니다. 그래서 이 세 방법은 하나의 묶음으로 봐야 하고, 그 묶음 전체를 그대로 옮겨 붙이는 게 어렵기 때문에 "방법은 못 베낀다"는 말이 성립합니다. 화면 하나, 버튼 하나는 흉내 낼 수 있어도, 이렇게 맞물린 절차 전체를 똑같이 재현하는 건 다른 차원의 일입니다.

본론 3 — KRDS 표준 대비, 방법이 만든 결과의 얼굴

방금 본 세 방법이 실제로 어떤 결과를 만드는지, 화면 하나로 짚어보겠습니다. 아래는 분석한 사이트가 표준 대비 어느 항목에서 얼마나 어긋났는지를 항목별로 비교해 보여주는 화면입니다.

AI 종합보고서의 KRDS 비교분석(표준 대비) 화면. 분석 사이트가 표준 대비 각 항목에서 얼마나 떨어져 있는지 항목별로 비교되어, 어디를 얼마나 손봐야 하는지가 한눈에 읽히는 모습 (게재 시 기관명·도메인 블러)

이 화면이 방법론의 얼굴입니다. 왜냐하면 이런 "표준 대비 항목별 비교"는, 앞서 말한 세 방법이 다 갖춰져야 나오기 때문입니다. 우선 846개 규칙이라는 하나의 자가 있어야 "어느 항목"을 정의할 수 있습니다. 자가 없으면 비교할 기준 자체가 없습니다. 그다음, 코드로 판정할 것과 화면으로 감지할 것을 나눠 처리하는 두 엔진이 있어야 각 항목의 값이 채워집니다. 마지막으로, 그 값들이 위험도로 정리돼야 "어디부터 손봐야 하는지"가 읽힙니다.

기능 목록에 "표준 비교 제공"이라고 한 줄 적는 건 누구나 할 수 있습니다. 그런데 그 한 줄이 실제로 이런 화면으로 이어지려면, 그 뒤에 세 방법이 다 돌아가고 있어야 합니다. 겉보기 기능은 "표준 비교"라는 라벨이고, 방법은 그 라벨을 이 화면으로 만들어 내는 뒷단의 절차입니다. 라벨은 베낄 수 있어도, 라벨을 이 화면으로 바꾸는 절차는 그대로 옮겨 붙일 수 없습니다.

본론 4 — 공공 사이트에서 방법 차이가 더 크게 벌어지는 이유

같은 방법 차이라도, 어떤 사이트에서 보느냐에 따라 그 차이가 더 크게 벌어지기도 합니다. 공공 사이트가 바로 그런 곳입니다. 이유가 몇 가지 있습니다.

첫째, 공공 사이트는 페이지가 아주 많습니다. 안내·공고·민원·정책·통계가 부서마다 쌓여, 페이지 수가 수백에서 수천에 이르기도 합니다. 메인 한 장만 보는 도구와 사이트 전체를 보는 도구의 차이가, 여기서는 결정적으로 벌어집니다. 메인은 대개 가장 공들여 관리하는 얼굴이라 깔끔합니다. 그런데 사용자가 실제로 업무를 보는 곳은 신청·조회·안내 페이지입니다. 메인만 본 결과와 전체를 본 결과는, 같은 사이트를 본 것이라고 믿기 어려울 만큼 다를 수 있습니다. 페이지를 함께 보고 일관성까지 따지는 방법이 있느냐가, 여기서 큰 갈림이 됩니다.

둘째, 공공 사이트는 사용자 층이 아주 넓습니다. 젊은 사용자만 오는 게 아니라, 고령의 사용자도 오고, 오래된 기기를 쓰는 분도 오고, 화면 낭독기에 의존하는 분도 옵니다. 그래서 접근성이 특히 중요한데, 앞서 봤듯 접근성 검사는 얕게 하느냐 깊게 하느냐의 차이가 큽니다. 코드만 훑는 얕은 검사는 "이미지로 만든 버튼"이나 "그림 안에 든 글자" 같은, 실제로 취약 계층이 가장 많이 걸려 넘어지는 문제를 통째로 놓칩니다. 화면까지 보는 방법이 있어야 이런 게 잡힙니다. 사용자 층이 넓을수록, 놓친 문제 하나가 더 많은 사람에게 영향을 줍니다.

셋째, 공공 사이트는 여러 부서가 각자 콘텐츠를 올립니다. 형식이 통일되지 않은 채 온갖 게시물이 쌓이고, 그 과정에서 화면이 크고 작게 깨집니다. 이런 문제는 한 페이지를 정밀하게 보는 것만으로는 안 잡힙니다. 여러 페이지에 걸쳐 같은 자로 훑어야, "이 형식의 게시물이 여기저기서 화면을 뚫고 나간다" 같은 게 드러납니다. 세 시점을 하나의 자로 묶고, 그 자를 여러 페이지에 일관되게 적용하는 방법이 있어야 가능한 일입니다.

넷째, 공공 사이트는 품질을 "증명"해야 하는 자리가 많습니다. 내부 보고든 외부 점검이든, "우리 사이트가 표준을 얼마나 지키는지"를 근거와 함께 설명해야 할 때가 옵니다. 이때 위반을 한 무더기 던지는 목록으로는 설명이 안 됩니다. 어느 항목이 표준 대비 얼마나 어긋났는지, 무엇이 급한지, 어떻게 개선할지가 정리돼 있어야 보고가 됩니다. 위험도로 정리하는 방법이 있느냐가, 여기서 실무의 부담을 크게 가릅니다.

정리하면, 공공 사이트는 페이지가 많고, 사용자 층이 넓고, 콘텐츠가 제각각이고, 품질을 증명해야 하는 곳입니다. 이 네 가지 조건이 겹치는 곳일수록, 겉보기 기능이 같아도 방법의 차이가 결과의 차이로 크게 벌어집니다. 그래서 공공 사이트를 점검하는 도구를 고를 때는, 기능 목록보다 방법을 더 꼼꼼히 봐야 합니다.

본론 5 — 그래서, 도구를 고를 때 방법을 드러내는 질문들

그럼 도구를 고르는 입장에서, 기능 목록 너머의 이 방법을 어떻게 알아볼 수 있을까요. 몇 가지 질문을 던지면 꽤 갈립니다. 이 질문들은 전부 "그 기능이 있느냐"가 아니라 "그 기능을 어떻게 만들었느냐"를 묻습니다.

질문 ① — 코드만 보나, 화면까지 보나

"이미지로 만든 버튼"을 잡느냐로 갈립니다. 코드만 보는 도구는 이걸 놓치거나 "해당 없음"으로 흘립니다. 화면까지 보는 도구는 잡습니다. 앞서 두 엔진 이야기에서 본 그 차이입니다. 물어볼 한 마디는 이겁니다. "이미지로 만든 버튼도 잡나요?" 이 질문 하나에, 코드만 보는지 화면까지 보는지가 드러납니다.

질문 ② — 한 페이지만 보나, 사이트 전체를 보나

메인 한 장만 보는 것과, 여러 페이지를 보고 일관성과 추세까지 비교하는 것은 다릅니다. 공공 사이트처럼 페이지가 많은 곳일수록 이 차이가 큽니다. 메인은 대개 가장 잘 관리되는 페이지라, 메인만 보면 사이트가 실제보다 좋아 보입니다. 물어볼 한 마디는 이겁니다. "몇 페이지까지 한 번에 보나요, 페이지 사이 비교도 되나요?"

질문 ③ — AI를 어떻게 쓰나

통째로 맡기나, 토대 위에서 빈칸만 채우나. 후자가 결과가 일관됩니다. 앞서 본 두 방식의 차이입니다. 물어볼 한 마디는 이겁니다. "AI 판정이 매번 같게 나오나요, 판단에 근거가 붙나요?" 통째로 맡긴 도구는 이 질문 앞에서 흔들립니다.

질문 ④ — 위반에 우선순위와 개선안을 주나

위반 목록만 주나, 위험도와 "어떻게 고치라"까지 주나. 세 번째 방법에서 본 그 자리입니다. 물어볼 한 마디는 이겁니다. "위반에 급한 순서와 고치는 방법이 붙나요?" 목록만 뽑는 도구는 여기서 "그건 알아서 판단하셔야 한다"고 답하게 됩니다.

질문 ⑤ — 같은 결과가 또 나오나 (재현되나)

같은 사이트를 다시 돌리면 같은 결과가 나오나. 규칙 엔진으로 뼈대를 잡은 도구라면 재현이 됩니다. AI에 통째로 맡긴 도구라면 흔들립니다. 물어볼 한 마디는 이겁니다. "어제 돌린 것과 오늘 돌린 게 같게 나오나요?"

이 다섯 질문의 공통점은, 전부 기능 목록에는 안 보이는 것을 묻는다는 점입니다. 기능 목록에는 "접근성 검사 ○, AI 분석 ○, 리포트 ○"만 적혀 있습니다. 그 동그라미들이 어떤 방법 위에 서 있는지는 안 적혀 있습니다. 이 질문들은 바로 그 방법을 끄집어냅니다. 그리고 방법이 탄탄한 도구일수록, 이 질문들에 막힘없이 답합니다.

다섯 질문을 오늘의 세 방법과 이어 보면 관계가 더 또렷해집니다. 질문 ①(코드냐 화면이냐)과 질문 ⑤(재현되나)는 두 엔진을 질서 있게 합치는 방법과 맞닿아 있습니다. 화면까지 보려면 시각 엔진이 있어야 하고, 재현되려면 규칙 엔진이 뼈대를 잡아 줘야 하니까요. 질문 ②(한 페이지냐 전체냐)는 세 시점을 하나의 자로 묶어 여러 페이지에 일관되게 적용하는 방법과 이어집니다. 질문 ④(우선순위와 개선안)는 위험도로 정리하는 방법 그 자체입니다. 질문 ③(AI를 어떻게 쓰나)은 세 방법을 관통하는 원칙 — 규칙 뼈대 위에서 AI를 쓴다 — 을 묻습니다. 그러니 이 다섯 질문에 답한다는 건, 곧 세 방법을 갖췄다는 뜻이기도 합니다. 질문은 방법을 비추는 거울인 셈입니다.

그리고 이 질문들은 파는 쪽을 곤란하게 하려는 게 아닙니다. 오히려 서로에게 좋습니다. 방법이 탄탄한 도구라면 이 질문들에 답하면서 자기 강점을 보여줄 기회가 되고, 고르는 쪽은 겉모습에 휩쓸리지 않고 실속을 확인할 수 있습니다. 방법이 부실한 도구만 이 질문 앞에서 말을 흐리게 됩니다. 그러니 도구를 파는 사람을 만나면, 부담 없이 이 다섯 질문을 던져 보시길 권합니다.

본론 6 — 기능 목록만 보고 골랐다가 생긴 일 (익명 사례 2건)

실제로 기능 목록만 보고 골랐다가 생긴 일을 두 가지, 익명으로 옮겨 보겠습니다.

사례 ① — "기능은 다 있던데요"

한 조직이 점검 도구를 골랐습니다. 후보 도구들의 기능 목록을 나란히 놓고 비교해 보니, 다들 "접근성·성능·검색 노출·보안 점검" 항목을 갖추고 있었습니다. 항목마다 동그라미가 고르게 찍혔습니다. 그래서 가장 저렴한 것을 골랐습니다. 합리적인 선택처럼 보였습니다.

막상 돌려보니 문제가 드러났습니다. 위반은 한 무더기 쏟아지는데, 어느 게 급한지 알 수가 없었습니다. 우선순위가 없으니 "다 고쳐야 하나" 싶어 손을 못 대고, 개선 방법도 안 적혀 있어 위반 이름마다 따로 검색해 봐야 했습니다. 기능은 분명 "다 있었"지만, 그 기능이 실제 업무로 이어지지 않았습니다. "검사는 됐는데, 그래서 뭘 해야 하지"에서 멈춘 겁니다. 기능 목록의 동그라미는 맞았지만, 그 동그라미 뒤에 위험도 정리라는 방법이 없었던 거죠.

사례 ② — "AI 준다더니 결과가 흔들려요"

다른 조직은 "AI 분석"이라는 문구를 보고 골랐습니다. AI가 알아서 판단해 준다니 든든해 보였습니다. 그런데 돌려볼 때마다 결과가 조금씩 달랐습니다. 어제는 통과였던 항목이 오늘은 미통과로 나오고, 같은 페이지를 다시 봐도 판정이 흔들렸습니다. AI에 통째로 맡긴 방식이라, 같은 화면을 봐도 판정이 매번 조금씩 달라진 겁니다.

"AI를 준다"는 맞았습니다. 다만 그 AI를 "어떻게 쓰는지"가 빠져 있었습니다. 결과를 못 믿으니 결국 사람이 다시 확인해야 했고, 자동화의 의미가 반쯤 사라졌습니다. 규칙 엔진으로 뼈대를 잡고 AI는 빈칸만 채우는 방법이었다면 겪지 않았을 일입니다.

두 사례의 공통점은 분명합니다. 기능 목록(메뉴판)은 맞았는데, 그 기능을 만드는 방법(레시피)을 안 봤다는 겁니다. 메뉴판에 적힌 "AI 분석"이라는 이름은 같아도, 그 요리를 어떻게 만드는지가 다르면 접시에 나온 결과가 달라집니다. 그래서 두 조직 다 "기능은 다 있는데 쓸모가 없는" 상황에 빠졌습니다.

그리고 이런 일이 생기면, 손해는 생각보다 큽니다. 도구를 도입하는 데 든 예산과 시간은 이미 나갔고, 막상 써 보니 업무로 이어지지 않으니 다시 다른 도구를 알아봐야 합니다. 그 사이 사이트의 문제는 그대로 남아 있습니다. "싼 걸 골랐다"고 생각했는데, 결과적으로는 두 번 사는 셈이 되기도 합니다. 처음 고를 때 기능 목록 너머의 방법을 한 번 더 들여다봤다면 피할 수 있었던 비용입니다. 그래서 도구 선택에서 "방법을 보는 눈"은 단순히 좋은 습관이 아니라, 실제 예산을 아끼는 일이기도 합니다.

한 가지 덧붙이면, 두 사례 다 "속았다"고 말하기도 애매합니다. 후보 도구들이 거짓말을 한 건 아니니까요. 그 도구들도 실제로 "접근성 검사"를 하고, 실제로 "AI 분석"을 줍니다. 기능 목록에 적힌 건 다 사실입니다. 문제는 그 사실이 말해 주지 않는 부분 — 얼마나 깊게 검사하는지, AI를 어떻게 쓰는지 — 이 결과를 갈랐다는 겁니다. 그러니 "거짓 기능을 걸러내라"가 아니라 "참인 기능 뒤의 방법을 확인하라"가 오늘의 교훈입니다.

본론 7 — 방법이 특허로 지켜지면 왜 따라 하기 어렵나

여기서 월요일 이야기와 이어집니다. 위 다섯 질문에 잘 답하는 도구, 즉 방법이 탄탄한 도구는 그 방법을 만드는 데 시간과 시행착오가 들었습니다. 세 시점을 하나의 자로 묶는 것, 두 엔진을 충돌 없이 합치는 것, 위반을 위험도로 정리하는 것 — 이런 건 하루아침에 나오지 않습니다.

그래서 그 방법을 권리(특허)로 정리해 두면, 옆에서 똑같이 따라 만들기가 더 어려워집니다. 기능 이름이야 얼마든지 따라 적을 수 있습니다. "우리도 접근성 검사 됩니다", "우리도 AI 분석 줍니다"라고요. 그런데 그 이름 뒤의 방법까지 그대로 베끼면 권리 문제가 생기고, 베끼지 않으면 같은 깊이의 결과가 안 나옵니다. 이게 월요일에 말씀드린 "레시피를 지킨다"의 실제 의미입니다. ViewCheck가 다섯 건을 특허로 출원해 둔 것도 이 지점입니다.

다섯 건이 다루는 방법을 오늘의 질문과 이어 보면 이렇습니다. 코드 뒤가 아니라 화면에 보이는 요소를 시각적으로 분석하고 감지·검증하는 방법(질문 ①·⑤), 여러 페이지를 함께 보고 비교하는 방법(질문 ②), 위반을 위험도로 등급화하는 방법(질문 ④) 등이 그 방법들입니다. "기능 이름"이 아니라 "그 기능을 만드는 방법"을 권리로 정리해 둔 데 차별점이 있습니다.

왜 방법을 권리로 지켜야 하느냐고 물으실 수 있습니다. 기능 이름은 원래 누구나 쓸 수 있는 말입니다. "접근성 검사"라는 이름을 특정 회사가 독차지할 수는 없습니다. 그건 당연합니다. 그런데 그 이름을 결과로 바꾸는 구체적인 방법 — 세 시점을 어떻게 하나로 묶는지, 두 엔진을 어떤 순서로 합치는지, 위반에 어떻게 무게를 매기는지 — 은 직접 만들어 낸 고유한 절차입니다. 이걸 아무나 그대로 가져다 쓰게 두면, 시간과 시행착오를 들여 만든 쪽만 손해입니다. 그래서 그 방법을 권리로 정리해, 이름은 공용으로 두되 방법은 지키는 겁니다. 이게 겉보기 기능과 방법론을 구분해서 다루는 이유이기도 합니다.

다만 여기서 솔직하게 짚어둘 게 있습니다. 특허가 있다고 결과가 자동으로 좋아지는 건 아닙니다. 특허는 방법을 보호하는 장치이지, 품질 보증서가 아닙니다. 다섯 질문에 잘 답하느냐는 그 방법이 실제로 잘 작동하느냐로 결정되는 것이고, 특허는 그 방법을 남이 함부로 가져가지 못하게 지키는 것입니다. 그리고 지금은 등록이 아니라 출원 단계입니다. "등록특허"가 아니라 "출원 기술"로 정확히 표기하는 게 맞습니다. 그래서 "특허가 있으니 믿으세요"가 아니라, "이 방법들을 직접 만들고 지켜두었으니, 직접 돌려보고 판단하시라" 정도로 받아들여 주시면 됩니다.

본론 8 — 그래도 기능 목록은 쓸모가 있다 (1차 거르개)

오해는 말아 주십시오. "기능 목록 비교가 다 쓸모없다"는 게 아닙니다. 기능 목록은 1차 거르개로는 아주 유용합니다. 아예 그 기능 자체가 없는 도구를 걸러내는 데는 좋습니다. "접근성 점검 기능이 애초에 없다"면 후보에서 빼면 되니까요. 이 1차 거르개 없이 처음부터 다섯 질문을 던지는 건 비효율적입니다.

다만 기능 목록은 딱 거기까지입니다. 후보를 몇 개로 추린 다음에는, 앞서의 다섯 질문으로 "방법"을 들여다봐야 합니다. 그리고 제일 확실한 건, 직접 돌려보는 겁니다. 우리 사이트나 비슷한 공공 사이트를 후보 도구에 넣어보고, 결과가 쓸 만한지·우선순위가 납득되는지·개선안이 실용적인지를 눈으로 보는 것. 기능 목록 표 백 개보다 데모 한 번이 낫습니다.

ViewCheck도 마찬가지입니다. "기능 있어요"를 믿어 달라고 하기보다, 직접 돌려보고 위 다섯 질문으로 따져보시길 권합니다. 그게 월요일부터 말씀드린 "방법으로 판단하라"는 겁니다. 방법이 탄탄하면 데모에서 드러나고, 겉만 그럴듯하면 데모에서 무너집니다. 데모는 기능 목록이 숨기는 것을 보여주는 가장 정직한 자리입니다.

한 가지 덧붙이면, 데모를 볼 때도 오늘의 다섯 질문을 손에 쥐고 보시면 좋습니다. 그냥 "오, 결과가 많이 나오네"에서 끝내지 마시고, "이 결과가 급한 순서로 정리돼 있나", "이미지로 만든 요소도 잡았나", "다시 돌리면 같게 나오나"를 하나씩 확인하시는 겁니다. 그러면 겉보기 화면의 화려함에 휩쓸리지 않고, 그 밑의 방법을 볼 수 있습니다.

그리고 데모를 볼 때 한 가지만 더 챙기시길 권합니다. 메인 페이지만 넣지 마시라는 겁니다. 메인은 대개 가장 잘 관리되는 얼굴이라, 어떤 도구에 넣어도 그럭저럭 나옵니다. 진짜 차이는 사용자가 실제로 업무를 보는 안쪽 페이지 — 신청·조회·안내 — 에서 드러납니다. 그런 페이지를 여러 개 넣어 보면, 얕은 방법과 깊은 방법의 차이가 확 벌어집니다. 결과가 많은 페이지에서도 흔들리지 않고 위험도 있게 정리되는지, 페이지 사이의 일관성까지 보는지를 눈으로 확인하시는 겁니다. 이 한 가지만 챙겨도 데모의 정직함이 크게 올라갑니다.

그래서 ViewCheck는

ViewCheck는 위 다섯 질문에 답하도록 만들어졌습니다. 코드만이 아니라 화면까지 보고, 한 페이지가 아니라 사이트 전체를 보고, AI를 토대 위에서 빈칸만 채우게 쓰고, 위반에 위험도와 개선안을 붙이고, 같은 결과가 재현되게 합니다. 그 뒷단에서 돌아가는 게 오늘 말씀드린 세 방법입니다. 세 시점을 846개 규칙 하나의 자로 교차 판정하고, 두 엔진을 질서 있게 합치고, 결과를 위험도로 정리하는 것.

거창하게 들릴 수 있는데, 결국 "기능이 있다"가 아니라 "기능을 이렇게 만들었다"를 보여드리려는 겁니다. URL 분석 하나만 돌려도 결과가 스무 개가 넘는 영역으로 펼쳐지는데, 그 스무 개가 넘는 영역이 다 이 세 방법 위에 서 있습니다. 접근성도, 성능도, 검색 노출도, 보안도, 반응형도 — 저마다 다른 화면으로 보이지만, 그 밑을 받치는 방법은 하나로 이어져 있습니다.

이 스무 개가 넘는 영역을 어떤 순서로 읽고, 그 결과를 어떻게 카테고리로 묶어 보는지는 다음 달들에서 하나씩 깊게 다룰 예정입니다. 예를 들어 위반을 위험도로 나누는 방법은 4개월차에서 본격적으로 파고, 결과를 몇 개의 카테고리로 정리해 읽는 법은 5개월차에서 다룹니다. 오늘은 그 모든 영역의 밑을 받치는 "세 방법"이 무엇인지, 그리고 그것이 왜 겉보기 기능과 다른 층위의 이야기인지까지만 짚었습니다. 밑을 받치는 방법을 먼저 이해하고 나면, 각 영역의 화면을 읽을 때 "이 결과가 어떤 방법에서 나온 것인가"가 보이기 시작합니다.

세 시점(설계·운영·맥락)이 하나의 846규칙 자로 모이고, 그 아래 두 엔진(구조 판정·시각 감지)이 질서 있게 결합되어, 마지막에 위험도 등급으로 정리되는 흐름을 한 장에 담은 개념 도식 (Gemini 1:1)

그 방법의 핵심을 다섯 건의 특허로 지켜둔 것도 그래서입니다. 겉으로 드러나는 기능 이름은 누구나 따라 적을 수 있지만, 그 이름을 결과로 바꾸는 방법은 직접 만들어 지켜두었습니다. 다시 말씀드리지만, 이건 "특허가 있으니 최고"라는 자랑이 아닙니다. "이 방법들을 직접 만들었고, 그래서 다섯 질문에 답할 토대가 있다"는 한 가지 신호일 뿐입니다. 판단은 직접 돌려보시고 하시면 됩니다.

특허로 지키는 부분

오늘 본 세 방법 — 세 시점을 하나의 자로 교차 판정하는 것, 두 엔진을 질서 있게 합치는 것, 결과를 위험도로 정리하는 것 — 은 ViewCheck가 출원한 다섯 건의 특허와 직접 맞닿아 있습니다. 코드 뒤가 아니라 화면에 보이는 요소를 시각적으로 분석·감지·검증하는 방법, 여러 페이지를 함께 보고 비교하는 방법, 위반을 위험도로 등급화하는 방법 등이 그 방법들입니다. 기능 이름 하나 따라 적는 것과, 그 이름을 이런 결과로 바꾸는 방법을 만드는 것은 전혀 다른 층위의 일입니다. 후자를 권리로 정리해 둔 데 차별점이 있습니다.

다만 솔직히 짚어둘 게 있습니다. 특허는 "방법을 지키는 장치"이지 "품질 보증서"가 아닙니다. 다섯 질문에 잘 답하느냐는 그 방법이 실제로 잘 작동하느냐로 결정되는 것이고, 특허는 그 방법을 보호하는 것입니다. 그래서 "특허가 있으니 믿으세요"가 아니라 "이 방법들을 직접 만들고 지켜두었다, 그러니 직접 돌려보고 판단하시라" 정도로 받아들여 주시면 됩니다. 그리고 현재는 출원 단계입니다. "등록특허"가 아니라 "출원 기술"로 정확히 표기합니다. (특허 출원 기술 / 자체 개발)

마무리

오늘은 "기능은 베껴도 방법론은 못 베낀다"는 말이 실제로 어떻게 드러나는지를 봤습니다. 접근성 검사도, AI 분석도, 리포트도, 이름은 같은데 그 밑의 방법이 다르면 결과가 갈립니다. 기능 목록(메뉴판)이 같아도, 그 기능을 만드는 방법(레시피)이 다르면 접시에 나온 결과가 달라집니다.

ViewCheck가 방법의 핵심으로 삼은 것은 세 가지였습니다. 세 시점을 846개 규칙 하나의 자로 교차 판정하고, 두 엔진을 질서 있게 합치고, 결과를 위험도로 정리하는 것. 이 세 방법이 결과의 깊이를 만들고, 그 방법의 핵심을 다섯 건의 특허로 지켜두었습니다. 화면과 버튼 같은 겉보기 기능은 이 위에 얹힌 표면일 뿐입니다.

오늘 딱 하나만 가져가신다면 이 문장이면 좋겠습니다. "기능 목록이 같다고 결과가 같은 게 아니다." 메뉴판의 이름은 같아도 레시피가 다르면 접시가 다릅니다. 도구를 고를 때 메뉴판만 보고 고르면, 접시에 무엇이 나올지는 돌려보기 전까지 모릅니다. 그러니 메뉴판 너머의 레시피 — 코드냐 화면이냐, 한 페이지냐 전체냐, AI를 어떻게 쓰느냐, 우선순위가 붙느냐, 재현되느냐 — 를 확인하시고, 가장 확실하게는 직접 접시를 받아 보시는 겁니다.

그러니 도구를 고르실 때는 기능 목록 너머를 봐 주십시오. 다섯 질문 — 코드냐 화면이냐, 한 페이지냐 전체냐, AI를 어떻게 쓰느냐, 우선순위와 개선안이 붙느냐, 재현되느냐 — 으로 방법을 들여다보고, 가장 확실하게는 직접 돌려보는 것. 그 방법의 핵심을 직접 만들고 지켜둔(출원 중) 도구라면, 그 다섯 질문에 답할 토대가 있을 겁니다.

이번 주 금요일에는 이 방법 이야기를 마무리하면서, "다섯 건의 특허가 세 시점(설계·운영·맥락)에 어떻게 걸치는지"를 한 장의 지도로 정리하겠습니다. 세 시점과 다섯 특허가 어떻게 맞물리는지 한눈에 보고, 다음 달부터는 각 영역을 하나씩 깊게 파 들어가겠습니다. 오늘도 끝까지 읽어주셔서 고맙습니다. 금요일에 지도로 이어가겠습니다.

krds.viewcheck.co.kr

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

8pt 그리드가 만드는 정돈된 레이아웃

ViewCheck — Mon, 28 Sep 2026 23:15:54 +0900

8pt 그리드가 만드는 정돈된 레이아웃

ViewCheck 마케팅 홍보 — 2026년 9월 · W4 간격·8pt 그리드 (9/28~10/4)

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

【 공감·문제제기 】

“이 페이지, 뭔가 어수선한데 정확히 뭐가 문제인지 모르겠어요.”

공공 사이트 개편 검수 회의에서 가장 자주 나오는 말이다. 화면을 띄워놓고 다 같이 들여다보는데, 분명 색도 맞췄고 글꼴도 통일했는데 뭔가 ‘정돈이 안 된’ 느낌이 든다. 누군가는 “여백이 좀 답답해요”라 하고, 또 누군가는 “버튼이 붕 떠 보여요”라 한다. 다들 불편함은 느끼는데, 그 불편함의 정체를 짚어내지 못한다. 그래서 결국 “좀 더 깔끔하게 정리해 주세요”라는 두루뭉술한 피드백으로 회의가 끝난다. 그리고 업체는 ‘깔끔하게’가 뭔지 자기 나름대로 해석해서 또 조금 다른 결과물을 가져온다. 이 무한 반복을 겪어본 담당자라면 지금 무슨 얘긴지 바로 알 거다.

나도 이런 회의를 수도 없이 겪었다. 처음엔 ‘내 디자인 감각이 부족해서 그런가’ 자책도 했다. 그런데 여러 사이트를 점검하다 보니, 이 ‘어수선함’의 정체가 의외로 단순한 데 있다는 걸 알게 됐다. 색이나 글꼴 같은, 눈에 확 띄는 요소의 문제가 아니었다. 진짜 범인은 ‘간격’이었다. 요소와 요소 사이의 빈 공간, 그러니까 여백이 제멋대로일 때 화면 전체가 어수선해 보이는 거였다.

여백이라니, 너무 사소한 얘기 같은가? 그런데 한번 이렇게 생각해보자. 책을 펼쳤는데 어떤 문단은 줄 간격이 빽빽하고 어떤 문단은 휑하게 떨어져 있다면, 글자 자체는 멀쩡해도 읽기 불편할 거다. 방을 정리할 때도 마찬가지다. 물건 자체는 좋은 물건인데, 간격 없이 아무렇게나 쌓여 있으면 어수선해 보인다. 화면도 똑같다. 요소 하나하나는 멀쩡한데, 그 사이의 간격이 들쭉날쭉하면 전체가 불안정해 보인다. 16픽셀이었다가 14픽셀이었다가 19픽셀이었다가… 이렇게 미세하게 어긋난 간격들이 모이면, 사람 눈은 그걸 ‘정렬이 안 맞는다’고 느낀다. 정확히 몇 픽셀이 틀렸는지는 몰라도, ‘뭔가 불편하다’는 감각만은 또렷하게 전달된다.

이 글은 바로 그 ‘간격’ 이야기다. 더 정확히는, 공공 디자인 표준인 KRDS가 권하는 ‘8pt 그리드’라는 규칙에 관한 이야기다. 이름만 들으면 뭔가 어려운 개발 용어 같지만, 막상 알고 나면 ‘이렇게 단순한 거였어?’ 싶을 만큼 쉽다. 그리고 이 단순한 규칙 하나가 화면의 인상을 얼마나 크게 바꾸는지 알게 되면, 앞으로 어떤 화면을 보든 ‘아, 이래서 정돈돼 보이는구나’ 혹은 ‘아, 이래서 어수선했구나’가 보이기 시작할 거다.

이 글은 이번 주 주제를 처음 접하는 공공웹 담당자를 위한 입문 글이다. 디자인 전공자가 아니어도, 픽셀이니 그리드니 하는 말이 낯설어도 괜찮다. 사이트 하나 운영해본 사람, 검수 회의에 한 번이라도 들어가 본 사람이라면 충분히 따라올 수 있도록, 어려운 용어는 전부 일상의 비유로 풀어 쓰려고 한다. 먼저 ‘그리드’와 ‘8pt’가 각각 무슨 뜻인지를 떼어서 설명하고, 왜 하필 8이라는 숫자인지, 이 규칙을 지키면 화면이 어떻게 달라지는지를 차근차근 짚는다. 그다음 실무에서 간격이 어긋나는 전형적인 상황들을 익명 사례로 보여주고, 마지막으로 ‘그래서 우리는 무엇부터 점검하면 되는지’를 단계별로 정리한다.

한 가지 더 솔직한 이야기를 보태자면, 나는 ‘간격’이라는 주제가 이렇게 한 편의 글이 될 만큼 깊은 줄 처음엔 몰랐다. 색이나 글꼴은 ‘디자인의 꽃’ 같아서 자연스레 신경을 쓰지만, 간격은 ‘그냥 비워둔 공간’ 정도로만 여겼다. 그런데 여러 사이트를 들여다보고, 잘 만든 화면과 어수선한 화면을 비교하다 보니, 둘을 가르는 결정적 차이가 바로 이 ‘비워둔 공간을 어떻게 비웠는가’에 있다는 걸 깨달았다. 잘 만든 화면은 여백조차 계획돼 있었다. 어수선한 화면은 여백이 그냥 ‘남은 자리’였다. 이 차이를 한번 알아채고 나면, 다시는 간격을 ‘그냥 빈 공간’으로 볼 수 없게 된다. 이 글이 여러분에게 그런 ‘눈이 트이는 경험’을 주면 좋겠다.

미리 한 가지 약속하자면, 이 글은 ‘또 하나의 숙제’를 안기려는 글이 아니다. 오히려 반대다. 8pt 그리드를 알면 ‘간격을 매번 새로 고민하는 일’이 사라진다. 결정의 횟수가 줄고, 검수의 기준이 생기고, 업체와의 대화가 구체적으로 바뀐다. 부담을 더하는 규칙이 아니라, 부담을 더는 도구로 8pt 그리드를 바라봐 주면 좋겠다. 자, 그럼 ‘간격’이라는 작지만 강력한 세계로 들어가 보자.

【본론 1 — 개념·왜 중요한가】

■ 먼저 ‘그리드’라는 말부터 풀어보자

‘그리드(grid)’를 우리말로 옮기면 ‘격자’ 혹은 ‘눈금판’이다. 모눈종이를 떠올리면 가장 쉽다. 어릴 때 그래프 그리던 그 모눈종이 말이다. 가로세로로 일정한 간격의 선이 그어져 있어서, 그 선을 기준으로 그림을 그리거나 글씨를 쓰면 삐뚤어지지 않고 가지런해진다. 자유롭게 백지에 그릴 때보다 모눈종이 위에 그릴 때 결과물이 훨씬 정돈돼 보이는 경험, 다들 있을 거다.

디자인에서 말하는 그리드도 똑같은 원리다. 화면 위에 눈에 보이지 않는 격자를 깔아두고, 모든 요소를 그 격자에 맞춰 배치하는 것이다. 버튼도, 글자도, 카드도, 이미지도 전부 이 보이지 않는 눈금에 맞춰 정렬한다. 그러면 요소들이 제각기 떠 있는 게 아니라, ‘하나의 질서’ 안에서 정렬된 것처럼 보인다. 사람 눈은 이 숨은 질서를 무의식적으로 알아챈다. 격자에 맞아떨어진 화면을 보면 ‘정돈됐다’고 느끼고, 격자에서 벗어난 화면을 보면 ‘어수선하다’고 느낀다. 정작 그 자리에 격자가 그어져 있다는 건 의식하지 못하면서 말이다.

여기서 중요한 점. 이 격자는 ‘출력되는 선’이 아니다. 디자인 단계에서만 참고하는 ‘기준선’이고, 실제 사용자에게 보이는 화면에는 그 선이 나타나지 않는다. 모눈종이 위에 그림을 그린 다음 그림만 오려내면, 모눈은 사라지고 가지런한 그림만 남는 것과 같다. 그리드는 어디까지나 ‘만드는 사람을 위한 보조선’이다. 그래서 사용자는 그리드의 존재를 모르지만, 그리드 덕분에 정돈된 화면의 혜택은 고스란히 누린다.

조금 더 비유를 밀어보자. 도시의 도로망을 떠올려도 좋다. 계획 없이 자연발생적으로 생긴 골목길의 도시는 길이 구불구불하고 어디가 어딘지 헷갈린다. 반면 바둑판처럼 도로를 계획한 신도시는 처음 가도 길 찾기가 수월하다. ‘몇 블록 가서 오른쪽’ 식으로 위치를 직관적으로 파악할 수 있기 때문이다. 그리드는 화면에 이 바둑판 도로망을 까는 일이다. 사용자가 화면 위에서 길을 잃지 않게, 시선이 자연스럽게 흐르도록 도로를 깔아주는 셈이다.

그런데 그리드라고 하면 보통 ‘가로 칸 나누기’, 즉 화면을 12칸이나 16칸으로 나누는 레이아웃 그리드를 떠올린다. 물론 그것도 중요하다. 하지만 오늘 이야기의 주인공은 조금 다르다. 가로 배치보다 더 근본적이고, 모든 화면에 빠짐없이 작동하는 ‘간격의 그리드’, 바로 8pt 그리드다.

두 그리드의 차이를 잠깐 정리하고 가자. 가로 그리드(레이아웃 그리드)는 ‘화면을 좌우로 어떻게 나눌까’를 다룬다. 본문 영역과 사이드 영역의 비율, 카드를 한 줄에 몇 개 놓을지 같은 ‘큰 골격’의 문제다. 반면 8pt 그리드는 ‘요소와 요소 사이를 얼마나 띄울까’, 즉 ‘여백의 단위’를 다룬다. 둘은 충돌하는 개념이 아니라 함께 쓰는 개념이다. 가로 그리드가 ‘방의 구획’을 나눈다면, 8pt 그리드는 ‘그 방 안 가구 사이의 간격’을 정한다. 큰 골격은 가로 그리드로, 그 안의 미세한 호흡은 8pt 그리드로 잡는 식이다. 오늘 우리가 집중하는 건 후자, 즉 ‘모든 화면에서 빠짐없이 작동하는 여백의 단위’ 쪽이다. 왜냐하면 어떤 화면이든, 가로를 몇 칸으로 나누든, 요소 사이에는 반드시 ‘간격’이 존재하기 때문이다. 간격이 없는 화면은 없다. 그래서 8pt 그리드는 가장 보편적으로, 가장 빠짐없이 적용되는 규칙이다.

■ ‘8pt’의 정체 — 왜 하필 8인가

8pt에서 pt는 ‘포인트(point)’의 약자로, 화면에서 길이를 재는 단위 중 하나다. 너무 정밀하게 따질 필요 없이, 일단은 ‘픽셀과 비슷한, 화면상의 길이 단위’ 정도로 이해하면 충분하다. 8pt는 그 길이가 8만큼이라는 뜻이다.

8pt 그리드의 규칙은 한 문장으로 요약된다. “화면의 모든 간격과 크기를 8의 배수로 맞춘다.” 요소와 요소 사이의 여백도 8, 16, 24, 32, 40, 48… 이렇게 8씩 늘려가며 정한다. 버튼의 높이도, 카드 안쪽의 안여백도, 글자와 글자 사이의 줄 간격도 가능한 한 8의 배수로 맞춘다. 이게 전부다. 규칙 자체는 이렇게 단순하다.

자, 그럼 핵심 질문. 왜 하필 8일까? 7도 아니고 10도 아니고 왜 8인가? 여기엔 꽤 합리적인 이유가 몇 가지 있다.

첫째, 8은 ‘나누기 좋은 숫자’다. 8은 2로도, 4로도 깔끔하게 나뉜다. 디자인을 하다 보면 ‘이 간격의 절반’ ‘이 간격의 절반의 절반’이 필요한 경우가 많은데, 8을 기준으로 하면 8의 절반은 4, 그 절반은 2로 떨어진다. 만약 기준을 5나 7로 잡으면 절반이 2.5나 3.5처럼 소수가 되어 어중간해진다. 8은 쪼개도 정수가 유지되니 다루기 편하다.

둘째, 다양한 화면 크기에 잘 들어맞는다. 요즘 사람들이 쓰는 기기의 화면 해상도는 대부분 8로 나누어떨어지는 값들로 설계돼 있다. 그래서 간격을 8의 배수로 맞추면 여러 기기에서 요소가 흐릿하거나 어긋나 보일 가능성이 줄어든다. 어중간한 숫자를 쓰면 화면을 확대·축소하는 과정에서 경계선이 뭉개지거나 0.5픽셀처럼 애매한 위치에 걸리는 일이 생기는데, 8의 배수는 이런 문제에서 비교적 자유롭다.

셋째, 그리고 이게 실무에서 가장 체감되는 이유인데, ‘선택지를 줄여준다’는 점이다. 간격을 정할 때 ‘1부터 100까지 아무 숫자나 가능’하다면, 누구는 14를 쓰고 누구는 15를 쓰고 또 누구는 17을 쓴다. 사람마다, 페이지마다 제각각이 된다. 그런데 ‘8의 배수만 쓴다’고 약속하면 선택지가 8, 16, 24, 32 정도로 확 줄어든다. 고민할 거리가 줄고, 누가 만들어도 비슷한 결과가 나온다. 앞서 말한 ‘결정의 횟수를 줄이는’ 디자인 시스템의 철학이, 간격이라는 가장 작은 단위에서 그대로 작동하는 것이다.

정리하면 8이라는 숫자는 ‘수학적으로 다루기 좋고, 기술적으로 안정적이며, 실무적으로 선택지를 줄여주는’ 삼박자가 맞아떨어진 결과다. 어디서 누가 그냥 정한 임의의 숫자가 아니라, 오랜 디자인 실무의 경험이 수렴한 합리적인 약속인 셈이다. 그래서 KRDS뿐 아니라 세계의 수많은 디자인 시스템이 8을 간격의 기준 단위로 채택하고 있다.

여기서 한 가지 흔한 오해를 풀고 가자. “그럼 8의 배수가 아닌 값은 절대 쓰면 안 되는 거냐”고 묻는 분들이 있다. 그렇지 않다. 8pt 그리드는 ‘철칙’이라기보다 ‘기본값’에 가깝다. 대부분의 간격은 8의 배수로 잡되, 정말 필요한 경우에는 그 절반인 4를 ‘반 칸’처럼 쓰기도 한다. 예를 들어 아이콘과 글자처럼 아주 가까이 붙여야 하는 요소 사이에는 8이 너무 넓을 수 있는데, 그럴 때 4를 쓴다. 핵심은 ‘아무 숫자나 마구 쓰지 않고, 8을 중심으로 한 정해진 단계 안에서 고른다’는 데 있다. 8, 16, 24, 32라는 큰 단계에 4라는 보조 단계까지 더하면, 거의 모든 상황을 정돈된 체계 안에서 처리할 수 있다. ‘예외 없는 규칙’이 아니라 ‘예외도 규칙 안에 있는’ 체계인 셈이다.

또 하나 자주 나오는 질문. “간격뿐 아니라 요소의 크기도 8의 배수로 해야 하나?” 그렇게 하면 더 좋다. 8pt 그리드의 진가는 ‘간격’과 ‘크기’가 같은 박자로 움직일 때 나온다. 버튼 높이가 40(8의 배수)이고, 그 위아래 간격이 16(8의 배수)이고, 안쪽 여백이 8이라면, 화면 전체가 하나의 일관된 격자 위에서 숨 쉬게 된다. 반대로 간격만 8의 배수로 맞추고 요소 크기는 제멋대로면, 절반의 효과밖에 못 낸다. 그래서 8pt 그리드는 ‘간격 규칙’이라기보다 ‘화면 전체를 8의 박자로 통일하는 규칙’이라고 이해하는 게 더 정확하다.

마지막으로, ‘왜 굳이 숫자로 약속까지 해야 하나, 디자이너 감각에 맡기면 안 되나’라는 생각도 있을 수 있다. 한 사람이 처음부터 끝까지 만든다면 감각만으로도 어느 정도 통일감이 나올 수 있다. 문제는 공공 웹 현장에서 그런 경우가 거의 없다는 것이다. 여러 부서, 여러 업체, 여러 시기에 걸쳐 화면이 만들어진다. 각자의 감각은 조금씩 다르고, 시간이 지나면 같은 사람의 감각조차 미묘하게 달라진다. ‘감각’은 사람마다 다르고 시간에 따라 변하지만, ‘8의 배수’라는 숫자 약속은 누가 언제 적용해도 똑같다. 일관성을 ‘운’에 맡기지 않고 ‘규칙’으로 보장하는 것 — 이게 숫자로 약속하는 진짜 이유다.

■ 간격이 만드는 ‘리듬’ — 음악으로 이해하기

8pt 그리드를 좀 더 깊이 이해하려면 ‘리듬’이라는 개념을 가져오면 좋다. 음악에서 박자가 일정해야 듣기 편한 것처럼, 화면에서도 간격이 일정한 ‘박자’를 이뤄야 보기 편하다.

생각해보자. 노래를 부르는데 박자가 들쭉날쭉하면, 노래 자체가 좋아도 듣는 사람이 불편하다. 어디서 박자를 끊어야 할지 예측이 안 되니까 긴장하게 된다. 반대로 박자가 규칙적이면, 듣는 사람은 다음 박자를 자연스럽게 예측하면서 편안하게 흐름을 탄다. 화면의 간격도 똑같다. 8, 16, 24처럼 일정한 배수로 간격이 반복되면, 사용자의 눈은 그 ‘시각적 박자’를 따라 자연스럽게 화면을 읽어 내려간다. 어디서 한 덩어리가 끝나고 어디서 새 덩어리가 시작되는지를 무의식적으로 예측하게 되는 것이다.

이걸 ‘수직 리듬’이라고도 부른다. 위에서 아래로 콘텐츠를 읽어 내려갈 때, 제목과 본문 사이, 문단과 문단 사이, 섹션과 섹션 사이의 간격이 일정한 규칙을 따르면, 마치 잘 짜인 악보처럼 시선이 막힘없이 흐른다. 반대로 이 간격이 제멋대로면, 눈은 매번 ‘여기서 끊어야 하나, 이어야 하나’를 새로 판단하느라 미세하게 피로해진다. 사용자는 자기가 왜 피곤한지 모른 채 그냥 ‘이 사이트는 보기 불편하다’고 느낀다.

이 피로는 생각보다 무섭다. 한 번의 미세한 피로는 사소하지만, 페이지를 스크롤하며 수십 번 반복되면 쌓인다. 그리고 그 누적된 피로는 ‘이 사이트는 쓰기 힘들다’는 인상으로 굳어진다. 더 나아가, 민원 신청처럼 여러 단계를 거쳐야 하는 흐름에서는 이 피로가 ‘중도 포기’로 이어지기도 한다. 사용자는 ‘왜 그만뒀는지’ 논리적으로 설명하지 못하지만, 몸은 이미 ‘이 과정이 불편하다’를 느끼고 멈춘다. 공공 서비스에서 사용자가 신청을 끝까지 마치지 못하는 건 단순한 불편을 넘어 ‘필요한 혜택을 못 받는’ 실질적 손해다. 일정한 간격 리듬이 이탈을 줄이고 완수율을 높이는, 보이지 않지만 분명한 역할을 한다.

악보 비유를 한 발 더 밀어보자. 좋은 음악에는 ‘일정한 박자’만 있는 게 아니라 ‘강약의 위계’도 있다. 4박자 안에서 첫 박이 강하고 나머지가 약한 식이다. 간격도 마찬가지다. 모든 간격이 똑같으면 오히려 단조롭고 어디가 중요한지 알 수 없다. 작은 단위(8)는 ‘긴밀히 붙은 것’을, 중간 단위(16, 24)는 ‘느슨히 묶인 것’을, 큰 단위(48)는 ‘완전히 다른 덩어리’를 나타낸다. 이렇게 간격에 강약의 위계를 두면, 사용자는 간격만 보고도 화면의 구조를 읽는다. 8pt 그리드는 이 강약을 ‘제멋대로의 강약’이 아니라 ‘배수로 정돈된 강약’으로 만들어준다. 박자도 일정하고 강약도 체계적인, 잘 작곡된 음악 같은 화면이 그렇게 만들어진다.

또 하나 중요한 개념이 ‘근접성’이다. 사람은 가까이 붙어 있는 것들을 ‘한 무리’로, 멀리 떨어진 것들을 ‘다른 무리’로 인식한다. 이건 우리 뇌가 정보를 처리하는 기본 방식이다. 그래서 서로 관련 있는 요소들(예를 들어 제목과 그 설명문)은 간격을 좁게 두고, 관련 없는 요소들(예를 들어 한 섹션과 다음 섹션)은 간격을 넓게 둬야 한다. 그래야 사용자가 ‘이건 한 덩어리, 저건 다른 덩어리’를 직관적으로 구분한다.

문제는, 간격에 기준이 없으면 이 ‘무리 짓기’가 엉망이 된다는 거다. 관련 있는 것끼리 멀고 관련 없는 것끼리 가까우면, 사용자는 정보의 묶음을 잘못 읽는다. 제목이 위 섹션에 붙은 건지 아래 본문에 붙은 건지 헷갈리고, 어디까지가 한 항목인지 모호해진다. 8pt 그리드는 이 ‘무리 짓기’를 체계적으로 만들어준다. ‘같은 무리 안은 8, 무리와 무리 사이는 24’ 같은 규칙을 정해두면, 화면 어디서나 일관된 간격 위계가 작동하고, 사용자는 정보의 구조를 한눈에 파악하게 된다.

이쯤 되면 ‘간격’이라는 게 단순한 미적 취향의 문제가 아니라는 게 보일 거다. 간격은 ‘정보의 구조를 시각적으로 전달하는 언어’다. 어떤 것이 한 묶음이고 어떤 것이 별개인지, 어떤 것이 더 중요하고 어떤 것이 부차적인지를 간격으로 말한다. 8pt 그리드는 이 언어를 ‘아무나 알아들을 수 있는 표준 문법’으로 정리한 것이다.

조금 더 풀어보자. 우리가 책을 읽을 때 문단 사이에 한 줄을 비우는 건 ‘여기서 한 생각이 끝나고 새 생각이 시작된다’는 신호다. 만약 모든 문단이 똑같은 간격으로 다닥다닥 붙어 있으면, 어디서 생각이 끊기는지 알 수 없어 읽기가 힘들다. 화면도 똑같다. 간격은 ‘여기서 끊어 읽으세요’ ‘이건 한 호흡으로 보세요’라고 말없이 알려주는 안내판이다. 그런데 이 안내판이 페이지마다 제멋대로면, 사용자는 매번 새로운 규칙을 익혀야 한다. 8pt 그리드로 간격의 안내판을 통일하면, 사용자는 한 번 익힌 규칙으로 사이트 전체를 편하게 읽어 내려간다. 학습 비용이 ‘페이지마다’에서 ‘사이트당 한 번’으로 줄어드는 셈이다.

그리고 이 ‘무리 짓기’는 단순히 보기 편한 차원을 넘어, 정보를 제대로 ‘이해’하게 만드는 문제이기도 하다. 예를 들어 신청 화면에서 ‘이름’이라는 라벨과 그 입력칸이 멀리 떨어져 있고, 오히려 아래의 ‘전화번호’ 입력칸과 가까이 붙어 있다면, 사용자는 이름 라벨이 어느 입력칸에 붙는지 헷갈린다. 이건 미관의 문제가 아니라 ‘정보를 잘못 입력하게 만드는’ 실질적 오류의 원인이다. 간격의 위계가 무너지면, 사용자는 엉뚱한 칸에 엉뚱한 값을 넣는다. 특히 고령층이나 디지털에 서툰 사용자일수록 이런 ‘간격이 주는 단서’에 더 많이 의존한다. 간격을 정돈하는 일이 곧 접근성을 챙기는 일과 이어지는 이유다.

■ KRDS가 8pt 그리드를 권하는 맥락

여기서 잠깐, 이 8pt 그리드가 KRDS 안에서 어디쯤 위치하는지 짚고 가자. KRDS는 크게 네 영역, 즉 DS·CP·BP·SP로 이루어진다. 디자인 기반 요소를 다루는 DS가 약 120개, 화면 부품을 다루는 CP가 약 446개, 작은 흐름을 다루는 BP가 약 108개, 전체 서비스 여정을 다루는 SP가 약 172개. 다 합치면 120 더하기 446 더하기 108 더하기 172, 정확히 846개다. KRDS를 ‘846규칙’이라 부르는 이유다.

8pt 그리드와 간격 체계는 이 중 가장 기초가 되는 DS 영역에 속한다. DS는 색·글꼴·간격·그림자·모서리 둥글기처럼 ‘시각의 기본 단위’를 다루는 영역인데, 간격 체계는 그중에서도 화면 전체의 짜임새를 떠받치는 뼈대다. DS는 눈에 잘 안 띄지만 모든 걸 떠받치는 영역이라고들 하는데, 간격이야말로 그 표현에 딱 맞는다. 사용자는 ‘간격’을 의식하지 않지만, 간격이 무너지면 화면 전체가 무너진다.

흥미로운 건, DS 영역의 규칙 수가 약 120개로 네 영역 중 가장 적다는 점이다. 가장 적은데도 가장 중요하다. 왜냐하면 DS는 ‘적은 수의 기본 규칙이 나머지 모든 화면에 영향을 미치는’ 구조이기 때문이다. CP의 446개 부품 규칙도, BP의 108개 패턴 규칙도, SP의 172개 서비스 규칙도, 결국 DS가 정한 색과 간격이라는 기본 단위 위에서 작동한다. 그러니 DS의 간격 하나가 어긋나면, 그 위에 올라간 수백 개 규칙이 한꺼번에 미세하게 흔들린다. 적은 규칙이 큰 파급을 가지는 구조 — 이게 DS 영역을, 그리고 그 안의 간격 체계를 ‘가장 먼저 잡아야 할 기초’로 만드는 이유다. 집을 지을 때 기초 콘크리트가 전체 면적에서 차지하는 비중은 작지만, 그게 흔들리면 건물 전체가 흔들리는 것과 똑같은 이치다.

그리고 여기서 KRDS의 영리한 점이 드러난다. KRDS는 간격을 ‘그때그때 정하는 수치’가 아니라 ‘토큰’이라는 정해진 변수로 관리하도록 권한다. 토큰이란 쉽게 말해 ‘이름이 붙은 약속된 값’이다. 예를 들어 ‘간격-작게는 8, 간격-보통은 16, 간격-크게는 24’처럼 이름과 값을 한 번 정해두고, 디자인할 때마다 그 이름을 가져다 쓰는 방식이다. 이렇게 하면 ‘이 여백 얼마로 하지?’를 매번 새로 고민할 필요가 없다. ‘여기는 보통 간격’이라고만 정하면, 그게 자동으로 16이 된다.

토큰의 진짜 위력은 ‘한 번 바꾸면 전체가 바뀐다’는 데 있다. 만약 나중에 ‘보통 간격을 16에서 20으로 늘리자’고 결정하면, 토큰의 값 하나만 바꾸면 그 토큰을 쓴 모든 화면의 간격이 일제히 바뀐다. 토큰 없이 일일이 숫자를 박아넣었다면, 수백 개 화면을 하나하나 찾아 고쳐야 한다. 토큰은 간격의 일관성을 ‘유지’하는 동시에 ‘수정’도 쉽게 만들어주는, 일석이조의 장치다. 8pt 그리드와 토큰은 그래서 짝꿍처럼 함께 다닌다. 8pt 그리드가 ‘어떤 값을 쓸지’의 규칙이라면, 토큰은 ‘그 값을 어떻게 관리할지’의 방법이다.

토큰을 ‘이름’으로 관리한다는 점도 곱씹어볼 만하다. ‘16’이라는 숫자에는 의미가 없다. 하지만 ‘보통 간격’이라는 이름에는 의미가 있다. 디자인할 때 ‘여기 16을 넣어주세요’가 아니라 ‘여기 보통 간격을 써주세요’라고 말하면, 그 자리가 ‘어떤 성격의 자리인지’가 함께 전달된다. 숫자는 ‘얼마’만 말하지만, 이름은 ‘왜’까지 말한다. 그래서 토큰으로 관리된 화면은 단순히 일관될 뿐 아니라 ‘의도가 읽히는’ 화면이 된다. 나중에 다른 사람이 봐도 ‘아, 여기는 보통 간격을 쓴 자리구나’를 알 수 있으니, 함부로 다른 값으로 바꾸지 않게 된다. 이름이 곧 약속이고, 그 약속이 화면을 지킨다.

그리고 이 토큰 개념은 간격에만 머물지 않는다. 색도 토큰으로, 글꼴 크기도 토큰으로, 모서리 둥글기도 토큰으로 관리하는 게 KRDS의 방식이다. 다음 달에는 이 ‘토큰’ 자체를 한 달 내내 깊이 다룰 예정인데, 오늘 간격을 통해 토큰의 맛을 미리 본 셈이다. 간격이라는 가장 단순하고 직관적인 예로 토큰을 이해해두면, 다른 영역의 토큰도 훨씬 쉽게 받아들여진다. 간격은 토큰을 처음 배우기에 가장 좋은 입구다.

마지막으로, 8pt 그리드는 앞서 말한 KRDS의 ‘레이어 구조’에서 가장 아래층을 단단하게 만드는 일이기도 하다. DS라는 기초 위에 CP라는 부품이 올라가고, 부품이 모여 BP라는 패턴이 되고, 패턴이 이어져 SP라는 서비스가 된다. 가장 아래의 간격 체계가 흔들리면, 그 위에 올라가는 모든 것이 미세하게 어긋난다. 버튼(CP)의 안여백이 제각각이면 버튼들이 들쭉날쭉해 보이고, 폼 흐름(BP)의 단계 간격이 제각각이면 흐름이 끊겨 보이고, 신청 서비스(SP) 전체가 어수선해 보인다. 그러니 8pt 그리드를 잡는 일은 ‘작은 디테일’을 챙기는 게 아니라 ‘건물의 기초’를 다지는 일에 가깝다.

【본론 2 — 흔한 실수·사례 (익명)】

개념을 들으면 ‘그래서 실제로 뭐가 문제인데?’ 싶을 수 있다. 그래서 실무에서 간격 때문에 자주 벌어지는 상황을 익명으로 풀어보겠다. 미리 양해를 구하자면, 아래 사례에는 어떤 실제 기관명도, 도메인도, 식별 가능한 정보도 들어 있지 않다. 모두 여러 사이트를 점검하다 보면 패턴처럼 반복되는 ‘유형’을 익명으로 재구성한 것이다. 읽다가 ‘어, 우리 사이트 얘긴가?’ 싶은 대목이 있다면, 그건 그만큼 흔한 문제라는 뜻이지 특정 기관만의 문제가 아니다.

그리고 이 사례들을 읽을 때 한 가지를 염두에 두면 좋겠다. 모든 사례의 ‘증상’은 달라 보여도, ‘원인’은 결국 하나로 모인다는 점이다. 바로 ‘간격을 정하는 공통 기준이 없었다’는 것이다. 부서마다 따로 만들었든, 사람이 손으로 밀어 맞췄든, 모바일을 놓쳤든, 그 밑바닥에는 ‘기준의 부재’가 공통으로 깔려 있다. 그래서 해법도 결국 하나로 모인다. ‘공통 기준을 세우고, 그 기준이 지켜졌는지 측정하는 것.’ 증상은 다양하지만 처방은 같다는 것 — 이게 8pt 그리드가 이렇게 강력한 이유다. 하나의 단순한 약속이 이토록 많은 문제를 한꺼번에 예방한다.

■ 사례 하나: 다 맞췄는데 왜 어수선할까

한 광역지자체, 편의상 A광역지자체라 하자. A광역지자체의 새 홈페이지 시안을 검수하는 자리였다. 색은 KRDS 권장 팔레트에 맞췄고, 글꼴도 통일했고, 버튼 모양도 가지런했다. 그런데 다들 ‘뭔가 정돈이 덜 됐다’고 입을 모았다. 정확히 짚지는 못하면서 말이다.

화면을 자로 재듯 뜯어보니 원인이 드러났다. 카드와 카드 사이 간격이 어떤 데는 18, 어떤 데는 22, 어떤 데는 15였다. 제목과 본문 사이 여백도 페이지마다 조금씩 달랐다. 한두 픽셀 차이라 한눈에 ‘틀렸다’고 보이진 않지만, 그 미세한 어긋남이 누적되니 화면 전체가 ‘느슨하게 흔들리는’ 인상을 줬다. 색과 글꼴이라는 ‘큰 요소’는 맞췄는데, 간격이라는 ‘작은 요소’가 제멋대로였던 것이다.

이 사례가 보여주는 건, 간격의 문제가 ‘티는 안 나는데 분위기는 망치는’ 종류라는 점이다. 색이 틀리면 누구나 바로 안다. “여기 색 왜 달라요?” 한마디면 끝난다. 그런데 간격은 ‘틀렸다’고 콕 집기 어렵다. 그저 ‘어수선하다’는 막연한 느낌으로만 다가온다. 그래서 더 위험하다. 원인을 못 찾으니 “좀 더 깔끔하게”라는 헛도는 피드백만 반복되고, 정작 진짜 범인인 간격은 끝까지 손대지 못한 채 넘어간다. 8pt 그리드라는 ‘기준’이 있으면, 이 막연한 느낌이 “카드 간격이 8의 배수에서 벗어났습니다”라는 구체적인 지적으로 바뀐다.

이 사례에서 한 가지 더 짚고 싶은 게 있다. A광역지자체의 디자이너는 결코 일을 못한 사람이 아니었다는 점이다. 오히려 색과 글꼴을 꼼꼼히 맞출 만큼 성실했다. 그런데도 간격이 어긋난 건, ‘간격을 어디에 맞춰야 하는지’에 대한 기준 자체가 그에게 주어지지 않았기 때문이다. 매 화면을 만들 때마다 ‘이 정도면 보기 좋겠지’라는 그날그날의 눈대중으로 간격을 잡으니, 같은 사람이 만들어도 화면마다 미세하게 달라졌다. 이건 개인의 실력 문제가 아니라 ‘기준의 부재’ 문제다. 아무리 성실한 사람도 기준 없이 눈대중으로만 작업하면 일관성을 유지할 수 없다. 반대로 말하면, 기준만 주어지면 누구나 일관성을 지킬 수 있다는 뜻이기도 하다. 8pt 그리드가 하는 일이 바로 그 ‘기준 제공’이다.

■ 사례 둘: 한 페이지 안에서 따로 노는 영역들

이번엔 한 공공기관, B공공기관의 사례라 치자. B공공기관 메인 페이지는 여러 부서에서 보내온 콘텐츠 블록이 한데 모여 있었다. 공지사항 영역, 행사 안내 영역, 자료실 영역, 민원 안내 영역… 그런데 각 영역의 ‘안쪽 여백’이 제각각이었다. 어떤 영역은 안쪽이 넉넉하게 비어 있어 여유로워 보이는데, 바로 옆 영역은 빽빽하게 들어차 답답해 보였다.

이유는 단순했다. 영역마다 만든 시점이 다르고, 손댄 사람이 달랐기 때문이다. 각자 자기 기준대로 여백을 잡으니, 한 페이지 안에서도 ‘리듬’이 깨졌다. 사용자 입장에서는 한 화면을 위에서 아래로 훑는데 어떤 구간은 빠르게 어떤 구간은 답답하게 읽히니, 흐름이 자꾸 끊겼다. 음악으로 치면 한 곡 안에서 박자가 계속 바뀌는 셈이다.

이 사례의 핵심은 ‘부분 최적화의 함정’이다. 각 영역만 따로 보면 다들 그럴듯하다. 그런데 합쳐놓으면 충돌한다. 간격에 ‘조직 공통의 기준’이 없으면, 아무리 각 부서가 열심히 만들어도 전체로는 어긋난다. 8pt 그리드와 토큰이 빛을 발하는 지점이 바로 여기다. ‘우리 조직은 영역 안여백을 24, 영역 사이는 48’처럼 공통 토큰을 정해두면, 누가 어느 시점에 만들든 같은 리듬이 유지된다. 개인의 감각에 기대지 않고, 조직의 약속으로 일관성을 보장하는 것이다.

■ 사례 셋: 모바일에서 무너지는 간격

C기관 사이트는 PC 화면에서는 그럭저럭 정돈돼 보였다. 그런데 휴대폰으로 열어보니 인상이 확 달라졌다. 요소들이 화면 가장자리에 너무 바짝 붙어 답답했고, 어떤 곳은 두 요소가 거의 붙다시피 해서 무엇이 무엇인지 구분이 안 됐다. 손가락으로 누르려는데 버튼끼리 너무 가까워 잘못 누르기 십상이었다.

원인은 ‘PC 기준으로만 간격을 잡고 모바일을 따로 챙기지 않은’ 데 있었다. PC의 넓은 화면에서는 적당해 보이던 간격이, 좁은 모바일 화면에서는 비율이 무너졌다. 특히 손가락으로 조작하는 모바일에서는 간격이 단순한 미관 문제가 아니라 ‘제대로 누를 수 있느냐’의 문제가 된다. 버튼과 버튼 사이가 충분히 떨어져 있지 않으면, 사용자는 옆 버튼을 잘못 누르고 엉뚱한 페이지로 가게 된다.

8pt 그리드는 이 모바일 문제에도 답을 준다. 일관된 배수 체계로 간격을 관리하면, 화면이 좁아질 때 ‘간격을 한 단계씩 줄이는’ 식의 규칙적인 대응이 가능하다. ‘PC에서 24였던 간격을 모바일에서는 16으로’처럼 배수 체계 안에서 단계적으로 조절하면, 좁은 화면에서도 리듬이 깨지지 않는다. 어중간한 숫자로 잡아둔 간격은 화면이 줄어들 때 같이 어중간하게 무너지지만, 8의 배수로 잡힌 간격은 줄어들어도 여전히 8의 배수 안에서 정돈을 유지한다.

이 세 사례를 관통하는 교훈은 하나다. 간격은 ‘있어도 그만 없어도 그만인 디테일’이 아니라, ‘있어야 화면이 서는 뼈대’라는 것이다. 그리고 그 뼈대를 일관되게 세우는 가장 쉬운 방법이 바로 8의 배수라는 단순한 약속, 8pt 그리드다.

■ 사례 넷: ‘1픽셀씩 손으로 밀어 맞춘’ 화면

조금 다른 종류의 사례도 있다. 어떤 사이트는 겉보기엔 간격이 그럭저럭 맞아 보였다. 그런데 화면을 만든 과정을 들여다보니, 디자이너가 ‘눈으로 보기 좋을 때까지’ 요소를 1픽셀씩 손으로 밀어가며 맞춘 결과였다. 그래서 어떤 간격은 17, 어떤 건 19, 어떤 건 21처럼 ‘보기엔 좋지만 아무 규칙도 없는’ 값들로 채워져 있었다.

이게 왜 문제일까? 한 화면만 보면 문제가 없다. 디자이너가 공들여 맞췄으니 그 화면은 예쁘다. 문제는 ‘다음’이다. 다른 담당자가 이 화면에 새 요소를 추가하려 할 때, 기준이 없으니 어떤 간격을 써야 할지 알 수가 없다. ‘17이었나 19였나’를 일일이 재봐야 하고, 결국 또 자기 눈대중으로 새 값을 만들어낸다. 화면이 수정될 때마다 규칙 없는 값이 하나씩 늘어나고, 시간이 지날수록 간격은 점점 더 누더기가 된다. 처음엔 예뻤던 화면이 ‘유지보수를 거치며 망가지는’ 전형적인 경로다.

8pt 그리드는 바로 이 ‘유지보수의 함정’을 막는다. 모든 간격이 8의 배수라는 명확한 규칙을 따르면, 나중에 누가 손대더라도 ‘여기는 16, 저기는 24’를 규칙으로 알 수 있다. 재느라 시간 쓸 필요도, 새 값을 만들 필요도 없다. 화면은 ‘공들여 한 번 만들고 끝’이 아니라 ‘여러 사람이 오래 함께 가꾸는’ 것이다. 그 긴 수명을 견디게 해주는 게 바로 ‘규칙으로 정돈된 간격’이다. 예쁜 화면보다 ‘오래 예쁠 수 있는 화면’이 진짜 잘 만든 화면이고, 8pt 그리드는 그 지속 가능성을 떠받친다.

■ 사례 다섯: 간격이 깨지니 접근성까지 흔들렸다

마지막 사례는 간격과 접근성이 맞물리는 지점을 보여준다. 한 기관의 신청 화면에서, 입력 항목들 사이의 간격이 들쭉날쭉했다. 어떤 항목 묶음은 너무 가까이 붙어 있고, 어떤 묶음은 너무 멀리 떨어져 있었다. 일반 사용자에게도 헷갈렸지만, 화면 낭독기를 쓰는 시각장애 사용자나, 한 번에 한 영역에 집중하는 게 중요한 사용자에게는 더 큰 장벽이 됐다.

간격은 ‘이것들이 한 묶음’이라는 시각적 신호인데, 그 신호가 무너지면 ‘무엇과 무엇이 한 세트인지’를 파악하기 어려워진다. 비장애인은 다른 단서로 어찌어찌 추측하지만, 정보 단서가 적은 사용자일수록 간격이라는 단서에 더 많이 기댄다. 그래서 간격이 깨진 화면은 ‘가장 약한 고리’의 사용자에게 가장 먼저, 가장 크게 불편을 준다.

앞서 ‘공공 서비스는 가장 약한 고리에 맞춰 설계해야 한다’고 했다. 간격은 그 원칙이 가장 미세한 단위에서 작동하는 지점이다. 8의 배수로 간격의 위계를 또렷하게 세우면, 정보의 묶음이 분명해지고, 그 분명함은 결국 모든 사용자, 특히 가장 도움이 필요한 사용자에게 가닿는다. 간격을 정돈하는 일이 단순한 ‘보기 좋게’를 넘어 ‘누구나 쓸 수 있게’로 이어지는 이유다. 작은 규칙 하나가 미관과 사용성과 접근성을 동시에 끌어올리는 셈이다.

【본론 3 — 그래서 무엇부터 시작할까】

이제 가장 실용적인 질문으로 넘어가자. “좋아, 8pt 그리드가 중요한 건 알겠어. 그래서 우리는 뭘 어떻게 시작하면 돼?” 입문자가 당장 적용해볼 수 있는 단계로 정리해보겠다.

■ 1단계: 현황부터 ‘재본다’

뭔가를 고치려면 먼저 지금 상태를 알아야 한다. 의외로 많은 담당자가 자기 사이트의 간격이 어떤 상태인지 모른다. ‘대충 괜찮아 보이는데’ 정도로만 안다. 첫걸음은 현황을 객관적으로 ‘재보는’ 것이다.

직접 자로 재라는 얘기가 아니다. 주요 페이지 몇 개를 띄워놓고, 카드 사이 간격이 균일한지, 제목과 본문 사이 여백이 페이지마다 일관된지, 모바일에서 요소가 가장자리에 붙지는 않는지를 ‘의식적으로’ 살펴보는 것만으로도 출발이 된다. 평소엔 그냥 지나치던 ‘간격’에 눈을 두는 연습이다. 한번 이 눈이 트이면, 어느 화면을 보든 어긋난 간격이 보이기 시작한다. 일종의 직업병이지만, 담당자에겐 유용한 직업병이다.

■ 2단계: ‘간격 토큰’ 목록을 정한다

다음은 우리 조직이 쓸 간격의 ‘메뉴판’을 만드는 일이다. 8의 배수 중에서 실제로 자주 쓸 값들을 추려 이름을 붙인다. 예를 들면 이렇다. 아주 좁게 8, 좁게 16, 보통 24, 넓게 32, 아주 넓게 48. 이렇게 대여섯 개 정도면 대부분의 상황을 커버한다. 더 많이 만들 필요 없다. 오히려 선택지가 너무 많으면 또 제각각이 되니, ‘적게, 명확하게’가 원칙이다.

이 목록이 곧 앞에서 말한 ‘토큰’이다. 한 번 정해두면, 이후 모든 화면은 이 메뉴판 안에서만 간격을 고른다. ‘여기는 보통 간격’이라고만 말하면 자동으로 24가 된다. ‘이 여백 얼마로 할까’를 매번 고민하던 일이, ‘이 자리는 어느 단계 간격이 어울릴까’를 메뉴판에서 고르는 일로 바뀐다. 고민의 성격이 완전히 달라진다.

■ 3단계: 업체와의 대화에 기준을 끼워 넣는다

실제 제작은 외주 업체가 하는 경우가 많다. 그렇다면 이 간격 기준을 ‘요구사항’과 ‘검수 기준’에 명시적으로 넣어야 한다. “간격은 8pt 그리드를 따르고, 사전 합의한 간격 토큰 목록만 사용한다”는 문장을 산출물 기준에 박아두는 것이다. 이렇게 하면 검수 회의의 풍경이 바뀐다. “좀 더 깔끔하게”가 아니라 “이 카드 간격이 토큰 목록에 없는 값인데 확인 부탁드린다”라고 구체적으로 말할 수 있다. 모호한 요구가 검증 가능한 요구로 바뀌는 순간이다.

업체 입장에서도 이게 더 편하다. ‘깔끔하게’라는 막연한 주문보다, ‘8의 배수, 정해진 토큰 안에서’라는 명확한 규칙이 작업을 수월하게 한다. 재작업도 줄어든다. 기준이 분명하면, 통과 여부도 분명해지기 때문이다.

■ 4단계: 한꺼번에 다 바꾸려 하지 않는다

마지막으로 가장 중요한 마음가짐. 기존 사이트의 모든 간격을 하루아침에 다 바꿀 필요는 없다. 그건 현실적이지도 않고 무리한 욕심이다. 가장 많이 보는 페이지, 가장 자주 쓰는 화면부터 손대는 게 정석이다. 메인 페이지, 자주 가는 민원 신청 화면, 검색 결과 화면처럼 사용자 트래픽이 몰리는 곳부터 간격을 정돈하면, 적은 노력으로 가장 큰 인상 개선을 얻는다. 그리고 다음 개편이나 부분 수정 시점마다 점진적으로 토큰을 적용해 나가면 된다. 완벽을 한 번에 노리지 말고, 방향을 정해 꾸준히 가는 게 답이다.

■ 5단계: 한 번 정한 기준을 ‘기록’으로 남긴다

네 단계까지 했다면 한 가지를 더 챙기자. 정한 기준을 ‘사람 머릿속’이 아니라 ‘문서’에 남기는 일이다. 흔히 일어나는 일이 있다. 어렵게 간격 토큰을 합의해놓고, 그걸 담당자 한 사람의 기억에만 의존하는 것이다. 그 담당자가 자리를 옮기거나 휴직하면, 다음 사람은 ‘왜 여기는 16이고 저기는 24였는지’ 이유를 모른 채 또 자기 식대로 바꾸기 시작한다. 그렇게 어렵게 세운 일관성이 인사이동 한 번에 무너진다.

그래서 간격 토큰 목록과 ‘이걸 왜 이렇게 정했는지’를 짧게라도 문서로 남겨야 한다. 거창한 가이드북일 필요 없다. ‘우리 조직 간격 규칙: 8/16/24/32/48, 아이콘 옆은 4 허용, 영역 사이는 48’ 같은 한 장짜리 메모라도 충분하다. 핵심은 ‘기준이 사람에게 묶이지 않고 조직에 박혀 있게’ 하는 것이다. 공공기관처럼 담당자 교체가 잦은 곳에서는 이 ‘기록’이 일관성을 지키는 마지막 안전장치다. 디자인 시스템의 세 층위(원칙·자산·문서) 중 ‘문서’가 빠지면 시스템이 아니라고 했던 것을 떠올려보자. 간격 기준도 문서로 남아야 비로소 ‘시스템’이 된다.

덧붙이자면, 이 다섯 단계는 순서대로 한 번에 다 해치워야 하는 ‘프로젝트’가 아니다. 1단계인 ‘현황 보기’만 해도 당장 오늘 해볼 수 있고, 그것만으로도 보는 눈이 달라진다. 그다음 단계들은 다음 개편이나 부분 수정 시점마다 하나씩 얹어 가면 된다. 중요한 건 ‘완벽한 계획’이 아니라 ‘첫걸음을 떼는 것’이다. 간격이라는 가장 작은 단위부터 정돈하기 시작하면, 그 정돈됨이 부품으로, 패턴으로, 서비스 전체로 차근차근 번져 나간다. 작은 곳에서 시작한 질서가 큰 그림을 바꾸는 것 — 그게 8pt 그리드가 가진 조용하지만 확실한 힘이다.

이 다섯 단계를 관통하는 정신은 ‘거창하게 시작하지 말고, 작게 그러나 일관되게 시작하라’는 것이다. 8pt 그리드는 그 자체로 ‘작게, 일관되게’의 화신 같은 규칙이다. 8이라는 작은 단위를, 모든 화면에서 일관되게. 그게 전부고, 그게 정돈된 레이아웃의 비밀이다. 그리고 그 일관성을 기억이 아니라 기록과 도구에 맡길 때, 비로소 사람이 바뀌어도 흔들리지 않는 진짜 정돈됨이 완성된다.

【본론 4 — 간격을 ‘측정’한다는 것】

여기까지 읽고 나면 한 가지 현실적인 벽에 부딪힐 거다. “좋아, 우리가 간격 기준을 정했다 치자. 그런데 그게 실제로 수백 개 페이지에 제대로 지켜졌는지 어떻게 확인하지?”

이게 핵심이다. 앞에서도 잠깐 짚었지만, ‘기준이 있다’는 것과 ‘기준이 지켜진다’는 건 전혀 다른 문제다. 아무리 멋진 간격 토큰 목록을 만들어도, 실제 사이트 화면 하나하나가 그 기준을 따르고 있는지 확인하지 않으면, 그 기준은 그냥 문서함에 잠든 문서일 뿐이다. 그리고 이 확인 작업이야말로, 사람 손으로는 도저히 감당이 안 되는 일이다.

생각해보자. 공공 사이트 하나가 페이지 수백 개로 이루어져 있는 경우가 흔하다. 각 페이지에는 수십 개의 요소가 있고, 요소마다 위아래 간격, 안쪽 여백, 요소 사이 거리가 있다. 이걸 사람이 하나하나 자로 재서 ‘8의 배수가 맞는지’ 확인한다? 한 페이지만 해도 반나절이 걸릴 거고, 수백 페이지면 평생 해도 못 끝낸다. 게다가 사람 눈은 18과 16의 2픽셀 차이를 정확히 잡아내지 못한다. ‘대충 비슷하네’ 하고 넘어간다. 정밀한 측정은 애초에 사람의 영역이 아니다.

그래서 등장하는 게 ‘자동 진단’이다. 화면을 컴퓨터가 읽어 들여서, 각 요소의 실제 간격과 크기를 픽셀 단위로 정밀하게 재고, 그 값이 8의 배수 체계와 정해진 토큰을 따르는지 기계적으로 대조하는 것이다. 사람이 ‘어수선하다’고 막연히 느끼던 것을, 기계는 ‘이 카드 간격은 18픽셀로, 8의 배수에서 2만큼 벗어났습니다’라고 정확한 숫자로 짚어준다. 막연한 느낌이 구체적인 데이터로 바뀌는 순간이다.

이 자동 진단이 가능해지면, 8pt 그리드 준수 여부가 ‘느낌’이 아니라 ‘점수’가 된다. 우리 사이트의 간격 일관성이 몇 퍼센트나 기준을 따르고 있는지, 어느 페이지의 어느 요소가 기준에서 벗어났는지를 목록으로 받아볼 수 있다. 그러면 검수도, 개선도, 보고도 전부 객관적인 근거 위에서 이뤄진다. 윗선에 “정돈해 놓았습니다”라고 말하는 대신 “간격 기준 준수율을 몇 퍼센트에서 몇 퍼센트로 끌어올렸습니다”라고 숫자로 보고할 수 있게 된다. 공공기관 보고 문화에서 ‘숫자로 말할 수 있다’는 건 엄청난 무기다.

여기서 ‘측정’이 가지는 또 다른 가치를 짚고 싶다. 측정은 ‘개선의 방향’을 알려줄 뿐 아니라 ‘개선의 진척’도 보여준다. 한 번 진단해서 현재 상태를 숫자로 잡아두면, 몇 달 뒤 다시 진단했을 때 ‘우리가 정말 나아졌는지’를 같은 잣대로 비교할 수 있다. 막연히 ‘예전보다 깔끔해진 것 같다’가 아니라 ‘준수율이 분명히 올랐다’고 확인하는 것이다. 이 ‘전후 비교’는 담당자 자신에게도 큰 동기부여가 된다. 눈에 안 보이던 노력이 숫자로 증명되니, 더 챙기게 된다. 그리고 이 숫자는 다음 사업 예산을 따낼 때, 개편의 필요성을 설득할 때도 객관적 근거가 된다. ‘느낌’으로는 예산을 못 따지만, ‘숫자’로는 딸 수 있다.

또 하나, 측정의 자동화는 ‘공정함’을 만든다. 사람이 검수하면 그날의 컨디션, 검수자의 취향, 업체와의 관계 같은 변수가 끼어든다. 같은 화면도 누가 보느냐에 따라 통과되기도 하고 반려되기도 한다. 그런데 기계가 ‘8의 배수인가 아닌가’를 따지면, 그 판정에는 사심도 기분도 없다. 통과 기준이 명확하고 일관되니, 업체와의 분쟁도 줄고 검수의 신뢰도 올라간다. ‘객관적 기준에 따른 판정’이라는 한마디가, 검수 회의의 불필요한 감정 소모를 크게 덜어준다.

한 가지 더, 측정의 자동화는 ‘반복 가능성’을 준다. 사람이 하는 검수는 매번 처음부터 다시 해야 하고, 검수자가 바뀌면 기준도 미묘하게 바뀐다. 반면 자동 진단은 ‘버튼 한 번’으로 언제든 똑같은 잣대로 다시 잴 수 있다. 사이트를 수정한 직후 바로 다시 진단해, 내 수정이 정말 기준에 맞게 됐는지 즉시 확인할 수 있다. 이 ‘즉각적인 피드백 고리’가 있으면, 담당자는 ‘고치고 → 재고 → 확인하고 → 또 고치는’ 빠른 개선 사이클을 돌릴 수 있다. 한 달에 한 번 외부 점검을 기다리는 게 아니라, 작업하는 그 자리에서 바로바로 품질을 챙기는 것이다. 측정이 빠르고 쉬워지면, 품질 관리는 ‘특별한 행사’가 아니라 ‘일상의 습관’이 된다. 이게 자동 진단이 가져오는 진짜 변화다.

그리고 바로 이 지점이, 우리가 만드는 ViewCheck가 일하는 방식과 정확히 맞닿아 있다.

【ViewCheck — 간격까지 숫자로 보여주는 진단】

ViewCheck는 공공 웹사이트가 KRDS 기준을 얼마나 지키고 있는지를 자동으로 진단하는 서비스다. 앞에서 설명한 KRDS 846규칙, 즉 DS 120개·CP 446개·BP 108개·SP 172개 전체를 기준으로, 입력한 사이트의 화면을 분석해 ‘무엇을 지켰고 무엇이 어긋났는지’를 보여준다.

오늘 주제인 간격과 8pt 그리드는 이 중 DS 영역의 핵심이다. ViewCheck는 화면의 각 요소가 실제로 어떤 간격과 크기로 그려졌는지를 픽셀 단위로 읽어 들이고, 그 값들이 8의 배수 체계와 KRDS가 권하는 간격 토큰에 부합하는지를 기계적으로 대조한다. 사람이 자로 재느라 평생 걸릴 일을, 화면을 읽어 들여 순식간에 처리한다. 그리고 그 결과를 ‘디자인 토큰 채택률’이라는 형태로 정리해 보여준다. 우리 사이트가 KRDS가 권하는 표준 토큰을 얼마나 따르고 있는지, 반대로 기준에 없는 제멋대로의 값을 얼마나 쓰고 있는지를 한눈에 보여주는 지표다.

이 ‘토큰 채택률’이 왜 중요한가. 앞에서 본 다섯 가지 사례를 떠올려 보자. ‘다 맞췄는데 어수선한’ 화면, ‘한 페이지 안에서 따로 노는’ 영역들, ‘모바일에서 무너지는’ 간격, ‘손으로 1픽셀씩 밀어 맞춰 규칙이 없는’ 화면, ‘간격이 깨져 접근성까지 흔들린’ 화면 — 이 모든 문제의 뿌리가 ‘기준에 없는 값을 제각각 쓴 것’이다. 토큰 채택률은 바로 이 ‘제각각 정도’를 숫자로 보여준다. 채택률이 낮다는 건 곧 ‘간격이 제멋대로’라는 뜻이고, 그게 바로 어수선함의 원인이다. ViewCheck는 그 막연한 어수선함을 ‘채택률 몇 퍼센트’라는 진단으로 바꿔, 어디서부터 손대야 할지를 명확히 알려준다.

채택률을 본다는 건 단순히 한 숫자를 받는 게 아니다. ‘우리 사이트가 KRDS가 정한 간격 단계 안에서 노는 비율’과 ‘기준 밖의 제멋대로 값을 쓰는 비율’을 함께 보는 것이다. 채택률이 높으면, 비록 디자인이 화려하지 않더라도 ‘정돈된 기본기를 갖춘 사이트’라는 뜻이다. 반대로 채택률이 낮으면, 겉이 아무리 그럴듯해도 ‘기초가 흔들리는 사이트’다. 그리고 그 흔들림은 시간이 지나며, 화면이 수정되며 점점 더 커진다. 채택률은 ‘지금의 상태’만이 아니라 ‘앞으로 무너질 위험’까지 가늠하게 해주는 지표인 셈이다. 건물로 치면 외장이 아니라 ‘기초 공사가 제대로 됐는지’를 보는 검사에 가깝다.

진단 결과는 분석 화면 상단의 점수 카드로 가장 먼저 요약된다. 카테고리별 준수 수준이 한눈에 들어오고, 그 아래로 내려가면 디자인 시스템 탭에서 토큰 채택률을 비롯한 세부 항목을 확인할 수 있다. 어느 항목이 기준을 따랐고 어느 항목이 벗어났는지, 벗어났다면 무엇을 어떻게 고쳐야 하는지까지 함께 제시된다. 담당자는 이 결과를 그대로 검수 기준으로, 개선 계획으로, 보고 자료로 활용할 수 있다.

물론 ViewCheck가 간격만 보는 건 아니다. KRDS 846규칙 전반은 물론이고, 행정안전부 「전자정부 웹사이트 품질관리 지침」이 정한 7대 영역(호환성·접근성·개방성·접속성·편의성·효율성·신뢰성)과 웹접근성 KWCAG 33항목까지 폭넓게 진단한다. 다만 오늘은 ‘간격’이라는 주제에 집중했으니, 8pt 그리드와 토큰 채택률이 ViewCheck 안에서 어떻게 측정되고 보여지는지에 초점을 맞춘 것이다. 간격이라는 가장 작은 단위조차 숫자로 짚어내는 도구라면, 그보다 큰 요소들은 말할 것도 없다.

한 가지 강조하고 싶은 건, ViewCheck의 목적이 ‘점수로 줄 세우기’가 아니라는 점이다. 진단의 진짜 가치는 ‘다음에 뭘 하면 되는지’를 알려주는 데 있다. 어수선한 화면 앞에서 막막했던 담당자가, 진단 결과를 받아 들고 ‘아, 이 페이지의 이 간격부터 8의 배수로 맞추면 되겠구나’ 하고 구체적인 다음 걸음을 떼는 것 — 그게 우리가 ViewCheck로 만들고 싶은 장면이다. 도구는 디테일을 측정하고, 사람은 그 측정을 바탕으로 더 나은 결정을 내린다. 앞에서 운전 비유로 말한 ‘사람은 방향을 잡고 도구는 디테일을 챙긴다’는 역할 분담이, ViewCheck 안에서 실제로 작동한다.

【 마무리 】

긴 이야기를 했지만, 핵심은 단 한 문장으로 줄어든다. “화면의 모든 간격을 8의 배수로 맞추면, 화면이 정돈된다.” 8pt 그리드는 이 단순한 약속이고, 그 단순함이 곧 힘이다.

오늘 우리는 ‘그리드’가 화면에 깔리는 보이지 않는 모눈종이라는 것, ‘8’이라는 숫자가 나누기 좋고 기술적으로 안정적이며 선택지를 줄여주는 합리적 약속이라는 것, 그리고 일정한 간격이 음악의 박자처럼 ‘시각적 리듬’을 만들어 화면을 읽기 편하게 한다는 것을 보았다. 또 간격이 무너질 때 실무에서 어떤 어수선함이 벌어지는지를 다섯 가지 익명 사례로 짚었고, 현황 측정부터 토큰 목록 정하기, 업체와의 기준 합의, 점진적 적용, 기준의 기록까지 시작하는 다섯 단계를 정리했다. 마지막으로, 그 모든 기준이 실제로 지켜졌는지를 ‘느낌’이 아니라 ‘숫자’로 확인하는 일이 왜 중요한지, 그리고 그 측정을 자동화하는 것이 표준의 실효성을 떠받치는 또 하나의 축임을 이야기했다.

간격은 사소해 보인다. 그래서 가장 자주 방치된다. 하지만 사소한 것들이 일관되게 쌓일 때 비로소 ‘정돈됨’이라는 인상이 완성된다. 반대로 사소한 것들이 제각각이면, 아무리 큰 요소를 잘 맞춰도 화면은 어딘가 흔들려 보인다. 8pt 그리드는 그 사소한 것들에 질서를 주는 가장 쉬운 약속이다. 어렵지 않다. 8씩 늘려가며 간격을 정하고, 그걸 토큰으로 관리하고, 모든 화면에서 일관되게 지키면 된다.

만약 지금 ‘우리 사이트는 간격이 어떤 상태일까’가 궁금해졌다면, 직접 확인해보는 것이 가장 빠르다. krds.viewcheck.co.kr에서 사이트 주소만 넣으면, KRDS 846규칙을 기준으로 한 자동 진단을 확인 할 수 있다. 디자인 시스템 탭의 토큰 채택률을 보면, 오늘 이야기한 간격과 토큰이 우리 사이트에서 얼마나 지켜지고 있는지 ‘숫자’로 만나게 된다. 막연히 ‘어수선한 것 같은데’ 하고 넘기던 그 느낌의 정체가, 구체적인 데이터로 손에 잡힐 거다. 거기서부터 시작하면 된다. 작게, 그러나 일관되게. 8pt 그리드가 만드는 정돈된 레이아웃은, 바로 그 한 걸음에서 시작된다.

키워드/태그: #KRDS #공공웹 #8pt그리드 #디자인토큰 #디자인시스템 #간격 #레이아웃 #웹접근성 #전자정부 #UI일관성 #공공디자인 #ViewCheck

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

24편 : 반응형 품질 — 데스크톱·태블릿·모바일 3환경 실측과 터치타겟 44px 연구

ViewCheck — Sun, 27 Sep 2026 21:04:56 +0900

24편 : 반응형 품질 — 데스크톱·태블릿·모바일 3환경 실측과 터치타겟 44px 연구

한 사이트를 세 화면에서 본다, ViewCheck가 뷰포트마다 무엇을 보는지

들어가며 — "PC에서는 잘 되는데 폰으로 들어오면 이상해요"

공공기관 홈페이지 담당자라면 한 번쯤 이런 민원을 받아봤을 것이다.

"PC로 들어오면 잘 나오는데, 폰으로 들어가면 글씨가 너무 작아요." "버튼을 누르려고 했는데 옆에 다른 버튼이 같이 눌려요." "화면이 가로로 잘려서 스크롤을 옆으로 해야 해요."

민원의 언어는 다양하지만, 진단의 언어로 옮기면 결국 같은 곳으로 수렴한다. 반응형 품질 문제다.

반응형(Responsive)이라는 단어는 이제 워낙 자주 쓰여서 오히려 당연한 것처럼 느껴진다. "요즘 사이트는 다 반응형이잖아요."라는 말도 종종 듣는다. 그런데 실제 공공 웹사이트를 분석해 보면, "반응형을 구현했다"와 "반응형 품질이 충분하다"는 전혀 다른 이야기라는 걸 계속 확인하게 된다. 반응형 CSS를 입혔다고 해서 모든 뷰포트에서 사용자 경험이 동등하게 보장되진 않는다. 터치 기반 환경에서의 상호작용, 작은 화면에서의 콘텐츠 가독성, 뷰포트 전환 시의 레이아웃 일관성 — 이 모두가 별개의 점검 항목이다.

ViewCheck는 반응형 품질을 분석할 때 세 개의 뷰포트에서 실제로 페이지를 열어 각각의 결과를 측정한다. 데스크톱(1920px), 태블릿(768px), 모바일(390px). 그리고 터치 인터랙션이 가능한 환경에서 유독 중요해지는 터치타겟 크기 — 최소 44×44 CSS 픽셀이 지켜지고 있는지 — 도 함께 들여다본다.

이 편에서 우리가 다루고 싶은 건 세 가지다. 첫째, "왜 세 뷰포트인가" — 각 뷰포트가 어떤 사용 맥락을 대표하고, 어떤 문제가 그 맥락에서 특히 불거지는지. 둘째, "터치타겟 44px가 왜 중요한가" — WCAG 2.5.8과 2.5.5가 말하는 최소 크기의 근거, 그리고 Apple HIG와 Material Design이 이 숫자를 어떻게 다루는지. 셋째, "ViewCheck는 이걸 어떻게 실측하는가" — 자동 분석의 가능성과 한계를 솔직하게.

미리 말해두고 싶은 건, 이 분야도 쉬운 정답이 없다는 점이다. "모든 버튼을 44×44px로 만들면 됩니까?"라는 질문에 "예, 그렇습니다"라고 단순 답하기 어려운 이유가 있고, 세 뷰포트를 테스트했다고 해서 모든 사용자 환경을 커버했다고 볼 수 없는 이유도 있다. 그 복잡함을 최대한 솔직하게, 그러면서도 실제 분석에서 얻은 데이터를 바탕으로 풀어보려 한다.

같은 URL, 세 화면. 한 사이트가 데스크톱·태블릿·모바일에서 어떻게 다르게 보이는지는, 세 화면을 직접 열어봐야 알 수 있다.

반응형이라는 말의 무게 — 구현과 품질 사이

반응형 웹 디자인(Responsive Web Design)이라는 개념을 처음 제안한 것은 에단 마르코트(Ethan Marcotte)가 2010년 A List Apart에 발표한 글이다. 핵심 아이디어는 단순했다. 하나의 HTML, 하나의 CSS 코드베이스로, 다양한 화면 크기에서 콘텐츠가 유연하게 반응하게 만들자는 것. 당시만 해도 모바일 전용 사이트를 따로 만드는(m.도메인) 방식이 주류였다. 반응형은 그 비효율을 걷어내는 접근이었다.

그로부터 15년이 지난 지금, 반응형은 거의 표준처럼 자리 잡았다. 하지만 동시에 "반응형을 구현했다"는 말이 점점 가벼워지는 경향도 보인다. 실제로 공공 웹사이트 중에는 반응형 CSS를 입혔지만, 모바일에서 콘텐츠가 세로로 스택되면서 핵심 기능이 아래로 밀려나는 경우가 있다. 태블릿 뷰포트에서 모바일처럼도, 데스크톱처럼도 최적화되지 않은 어중간한 레이아웃이 나오는 경우도 있다. 폼 요소가 작은 화면에서 너무 촘촘하게 배치되어 터치가 어려운 경우도 있다.

행정안전부 「전자정부 웹사이트 품질관리 지침」(행안부고시 제2025-46호, 2025.6.25. 개정)은 7대 품질 영역 중 호환성 항목에서 "모바일 운영체제(Android, iOS) 기본 설치 브라우저에서 PC 기능과의 차이, 화면 표시 차이를 검사"하도록 규정하고 있다(행정안전부, mois.go.kr). 즉, 공공 웹사이트가 모바일과 PC에서 동등하게 동작해야 한다는 것은 권고 수준이 아니라 공식 지침의 요구사항이다.

그렇다면 그 "동등하게 동작"의 기준을 어떻게 측정하는가? 사람이 모바일 기기를 손에 들고 직접 확인하는 방법이 가장 정확하겠지만, 수십 수백 개의 페이지를 세 가지 뷰포트로 전부 사람이 확인하는 건 불가능에 가깝다. 그래서 자동화 측정이 필요하고, 그 자동화가 어디까지 신뢰할 수 있는지가 중요해진다.

MDN Web Docs는 반응형 디자인을 이렇게 정의한다. "반응형 디자인은 CSS와 HTML을 사용해 콘텐츠를 조정·숨기거나, 크기를 변경하거나, 요소를 이동시켜 모든 화면에서 보기 좋게 만드는 접근 방식"이라고(MDN Web Docs, 'Responsive Design', developer.mozilla.org). 이 정의에서 핵심은 "조정·숨기거나·이동"이라는 적극적인 변환이다. 단순히 화면이 줄어드는 게 아니라, 화면 크기에 따라 경험이 재설계되어야 한다는 것이다.

세 뷰포트의 의미 — 1920, 768, 390

ViewCheck가 반응형 분석에 사용하는 세 뷰포트는 임의로 정한 게 아니다. 각각이 서로 다른 사용 맥락과 물리적 제약을 대표한다.

데스크톱 1920px — 공공 웹사이트의 주요 콘텐츠 레이아웃이 설계되는 기준 화면이다. 행정 업무 처리, 긴 문서 열람, 양식 작성 같은 '무거운' 작업은 여전히 데스크톱 환경에서 많이 이루어진다. 공공기관 담당자나 기업 사용자가 업무용으로 접근할 때는 대개 이 뷰포트다. 이 환경에서의 기준을 확인하는 것은 사이트가 "원래 의도한 대로" 동작하는지를 보는 것과 같다.

태블릿 768px — 흔히 간과되는 뷰포트다. "모바일 대응만 되면 되지 않나요?"라는 생각을 종종 만나는데, 768px 구간은 스마트폰보다 큰 화면을 가진 태블릿 기기, 또는 창 크기를 조절한 노트북 화면에 해당한다. 특히 공공 민원 서비스에서는 노인이나 시각 약자 분들이 태블릿을 편하게 사용하는 경우가 있다. 이 뷰포트에서는 데스크톱 레이아웃이 그대로 유지되기엔 좁고, 모바일 레이아웃이 적용되기엔 넓은 어중간한 구간이 생기기 쉽다. 이 '어중간한 구간'의 처리가 잘 됐는지를 확인하는 게 태블릿 뷰포트 테스트의 핵심이다.

모바일 390px — 2024년 기준 국내 사용자 비중이 높은 스마트폰 화면 크기다(아이폰 14·15 시리즈 기준 390×844px). 공공 민원 서비스를 이용하는 시민 중 상당수는 이 뷰포트에서 접근한다. 좁은 화면에서 터치 인터랙션이 주가 되고, 한 화면에 표시 가능한 콘텐츠 양이 대폭 줄어들며, 폼 요소와 버튼의 배치가 UX에 직접적인 영향을 미친다.

KRDS 공식 가이드(krds.go.kr)의 레이아웃 스타일 가이드는 xsmall(<360px)을 최적화 대상에서 제외하고 small부터 xlarge까지 4단계 브레이크포인트를 적용한다고 명시한다. 모바일 기본 그리드는 4 column이며, 화면 마진은 모바일 최소 16px, PC 최소 24px 이상을 사용하도록 규정한다(KRDS 공식, krds.go.kr/html/site/style/style_05.html). 그리고 간격 체계의 기본은 8-Point Grid — 8px의 배수, 상황에 따라 4px 배수 사용 가능이다.

이 세 수치(1920 / 768 / 390)는 "이 세 가지만 보면 충분하다"는 의미가 아니다. 실제 사용 환경은 이보다 훨씬 다양하다. 다만 세 개의 대표 구간을 체계적으로 확인하는 것이 현실적인 자동화의 출발점이다. 세 개도 충분히 많은 정보를 준다 — 그리고 동시에 세 개로 알 수 없는 것도 있다는 걸 늘 함께 기억해야 한다.

터치타겟 44px — 숫자 하나에 담긴 인간공학

이 편의 핵심 숫자 중 하나가 44다. 터치타겟 최소 크기로 44×44 CSS 픽셀(또는 포인트, dp)이 국제 표준들에서 반복적으로 등장한다.

왜 하필 44인가? 인간공학적 연구에서 출발한다. 성인의 손가락 끝(지문이 닿는 부분)의 평균 너비는 약 8~~10mm라는 연구 결과가 있다. 엄지손가락은 더 넓어서 10~~14mm에 달한다. 이를 화면 해상도로 환산하면, 약 9mm에 해당하는 물리적 크기가 나오고, 이것이 72dpi(Apple의 오리지널 포인트 기준) 기준으로 대략 44pt에 해당한다. Material Design이 제안하는 48dp도 비슷한 인간공학 근거에서 나온 것이다(Material Design, m3.material.io).

중요한 건 이 크기가 시각적 요소의 크기가 아니라는 점이다. 아이콘이 24×24px로 보여도, 그 주위에 패딩이 붙어 터치에 반응하는 영역이 44×44px 이상이면 기준을 충족할 수 있다. 반대로 버튼이 시각적으로 크더라도, 실제 클릭/탭에 반응하는 영역이 작으면 기준을 위반한다. 이 '시각 크기 vs. 터치 반응 영역'의 구분이 실제 점검에서 중요하게 다뤄지는 이유다.

WCAG 2.5.8과 2.5.5 — 국제 표준이 말하는 최소 크기

W3C가 2023년 10월에 확정한 WCAG 2.2에는 터치타겟 크기와 직접 관련된 두 개의 성공 기준이 있다.

성공 기준 2.5.8 — Target Size (Minimum), 레벨 AA

WCAG 2.2에서 새롭게 추가된 이 기준은 "클릭 또는 탭 가능한 타겟의 크기는 최소 24×24 CSS 픽셀 이상이어야 한다"는 것이다. AA 수준, 즉 실질적인 의무 적합 수준의 기준이다.

W3C WAI의 공식 이해 문서는 이 기준의 목적을 이렇게 설명한다. "많은 사람들이 마우스 사용이 어렵고, 특히 운동장애가 있는 경우나 모바일 기기에서 터치로 사용하는 경우에 타겟이 작으면 활성화하기 어렵다"라고(W3C WAI, "Understanding Success Criterion 2.5.8: Target Size (Minimum)", w3.org/WAI/WCAG22). 다만 24×24px에는 예외 조건이 있다. 타겟이 24px 미만이더라도, 24px 지름의 원을 그 타겟 중심에 그렸을 때 인접한 다른 타겟과 겹치지 않는다면 허용된다. 문장 안에 포함된 링크도 적용 예외다.

성공 기준 2.5.5 — Target Size (Enhanced), 레벨 AAA

더 엄격한 기준이다. "타겟의 크기가 최소 44×44 CSS 픽셀 이상"이어야 한다(W3C WAI, "Understanding Success Criterion 2.5.5: Target Size (Enhanced)", w3.org/WAI/WCAG22). AAA 수준이므로 모든 사이트에 강제되지는 않지만, Apple HIG와 Material Design이 44pt / 48dp를 권장하는 근거와 같은 맥락에 있다.

이 두 기준 사이 — 24px (AA 최소) vs. 44px (AAA 권장) — 에는 실질적인 간격이 있다. 법적 의무로는 24px면 충족되지만, 실제 사용성 관점에서는 44px를 기준으로 보는 것이 훨씬 현실적이다. 이건 AAArdvark의 2.5.5 설명에서도 확인할 수 있다. "링크, 버튼, 폼 컨트롤 같은 인터랙티브 요소가 44×44px 이상이어야 하며, 이는 운동 능력이 제한된 사용자, 임시 장애가 있는 사용자(한 손 사용 등), 그리고 터치스크린 사용자를 위한 핵심 기준"이라고(AAArdvark, 'WCAG 2.5.5 Target Size Enhanced').

한국형 웹 콘텐츠 접근성 지침(KWCAG 2.2)도 이 기준을 반영한다. UXKM 등 국내 접근성 커뮤니티에서 정리된 KWCAG 2.2 해설에 따르면, 포인터 입력 타겟 크기는 최소 44×44 CSS 픽셀 이상이어야 한다는 기준을 포함하고 있다(UXKM, 'KWCAG 2.2 가이드'). 이웃한 콘텐츠 간에 간격을 두어 터치스크린에서 조작성을 확보하도록 명시하고 있다.

ViewCheck LLM 분석의 반응형 품질 카드 화면. 데스크톱·태블릿·모바일 3뷰포트에서 측정된 결과와 터치타겟 점검 결과가 함께 표시된다. (실제 공공 웹사이트 분석 예시) — 실제 분석 화면

Apple HIG와 Material Design — 플랫폼 가이드라인의 시각

WCAG가 "최소한 이것만큼은"이라는 바닥을 제시한다면, 플랫폼 가이드라인들은 "이 정도는 해야 제대로"라는 실용적 기준을 제시한다.

Apple Human Interface Guidelines(HIG)

Apple은 오래전부터 44pt를 최소 터치 타겟 크기로 권장해 왔다. pt(포인트)는 픽셀 독립적인 단위로, 일반 해상도(72dpi)에서는 1pt = 1px이지만, 레티나 디스플레이에서는 1pt = 2px 또는 3px에 해당한다. 물리적으로는 약 9mm 크기다.

Zac Dickerson의 Medium 기사 "Size matters! Accessibility and Touch Targets"(2018)은 이 맥락을 잘 정리한다. "Apple이 자신들의 인터페이스 가이드라인에서 44×44pt를 명시했다"는 점을 지적하며, 터치 타겟이 너무 작을 때 발생하는 오터치(접근하지 않으려 했던 요소를 누르는 것)와 미스터치(목표 요소를 누르지 못하는 것)가 실제 사용성에 미치는 영향을 다루고 있다(Medium/@zacdicko).

흥미로운 점은 Apple HIG의 44pt가 시각적 요소 크기를 의미하는 게 아니라는 것이다. 작은 아이콘 주위에 보이지 않는 터치 영역을 확장하는 방식으로도 충족할 수 있다. 이 원칙은 UI에서 "작아 보이지만 누르기 쉬운" 디자인을 가능하게 하는 근거다.

Material Design 3

Google의 Material Design 3은 터치 타겟 최소 크기로 48×48dp를 권장한다(Material Design, m3.material.io/foundations/designing/structure). dp(density-independent pixel)는 160dpi 화면을 기준으로 정의된 단위다. 48dp는 물리적으로 약 9mm에 해당한다.

Material Design은 이 크기의 근거를 명확히 설명한다. "사람의 손가락 패드는 어린이 기준 8~~10mm, 성인 기준 10~~14mm이며, 평균은 약 11mm"라는 인간공학 데이터를 들어 48dp가 "대부분의 사용자가 편안하게 탭할 수 있는 최소 크기"라고 명시한다. 또한 "터치 타겟은 시각적 요소를 넘어 확장된다. 예를 들어 아이콘이 24×24dp로 보여도, 그 주위의 패딩이 합쳐져 48×48dp 터치 영역을 구성한다"고 설명한다.

Material Design이 48dp를 권장하고 Apple이 44pt를 권장하는 차이는, 운영체제와 화면 밀도 기준의 차이에서 비롯된다. 물리적 크기로 환산하면 둘 다 약 9mm 수준으로 수렴한다. 숫자가 달라 보이지만 실질적 목표는 같다.

터치타겟은 "눌렸나?"가 아니라 "편하게 눌렸나?"가 기준이다. 44px라는 숫자는 그 편안함의 인간공학적 최소값이다.

WCAG 1.3.4 방향과 1.4.10 리플로우 — 반응형의 두 가지 또 다른 기준

터치타겟만이 모바일 반응형 품질의 전부가 아니다. WCAG 2.1부터 2.2에 걸쳐 반응형 맥락에서 특히 중요한 두 가지 성공 기준이 있다.

WCAG 1.3.4 — Orientation (레벨 AA)

"콘텐츠는 세로 방향 또는 가로 방향으로 제한되어서는 안 된다. 단, 특정 방향이 필수적인 경우는 제외한다"는 기준이다(W3C WCAG 2.1/2.2). 사용자들은 기기를 가로로 눕혀서 사용하기도 하고, 세로로 세워서 사용하기도 한다. 이 전환이 자유로워야 하며, 특정 방향으로 고정하는 것은 많은 사용자에게 심각한 불편이 된다. 특히 모니터 스탠드를 세로로 회전해 사용하는 공공기관 직원이나, 가로 방향이 편한 특정 장애 사용자를 위해 이 기준은 중요하다.

WCAG 1.4.10 — Reflow (레벨 AA)

이 기준은 반응형 품질 전반과 가장 직접적으로 연결된다. "320 CSS 픽셀 너비에서 콘텐츠를 2차원 스크롤(가로+세로 동시 스크롤) 없이 이용할 수 있어야 한다"는 것이다(W3C WAI, w3.org/WAI/WCAG21/Understanding/reflow.html). 320px는 1280px 화면에서 400% 줌인했을 때의 유효 뷰포트 너비다.

이 기준이 왜 중요한가? 저시력 사용자들은 화면을 크게 확대해서 사용하는 경우가 많다. 400%로 확대했을 때 콘텐츠가 수평으로 잘려서 가로 스크롤 없이는 읽을 수 없다면, 그 사이트는 이 그룹의 사용자에게 실질적으로 접근 불가능하다. Silktide의 1.4.10 설명에 따르면 "반응형 디자인의 원칙을 따라 만들어진 웹페이지는 리플로우가 자동으로 이루어지지만, 그렇지 않은 경우 400% 확대 시 수평 스크롤이 발생한다"(Silktide, 'WCAG 1.4.10: Reflow'). 이건 반응형 구현 여부와 별개로, 구체적인 수치를 가지고 검증할 수 있는 기준이다.

ViewCheck의 반응형 분석에서 390px 뷰포트 테스트는 이 리플로우 기준을 실측하는 데 일부 기여한다. 물론 400% 줌인을 직접 시뮬레이션하는 것과 390px 뷰포트를 여는 것은 완전히 동일하지 않다. 그러나 좁은 뷰포트에서 레이아웃이 정상적으로 유지되는지는 리플로우 기준의 중요한 신호가 된다.

ViewCheck가 세 뷰포트에서 보는 것들

ViewCheck는 반응형 품질 분석을 위해 Playwright(실제 브라우저 엔진)를 세 가지 뷰포트 설정으로 각각 실행한다. 데스크톱(1920×1080), 태블릿(768×1024), 모바일(390×844). 각 환경에서 페이지를 로드하고 DOM 구조와 CSS 계산값을 수집한다.

각 뷰포트에서 확인하는 주요 항목들은 대략 이런 것들이다.

뷰포트 전환 레이아웃 일관성

같은 페이지가 세 뷰포트에서 각각 어떤 레이아웃으로 렌더링되는지를 확인한다. 데스크톱에서 가로로 나란히 있던 메뉴 항목들이 모바일에서 햄버거 메뉴로 적절히 전환되는지, 탭 UI가 작은 화면에서 선택 가능하게 남아 있는지, 이미지나 미디어 요소가 뷰포트를 초과해서 가로 스크롤을 유발하지 않는지 등이다.

터치타겟 크기 검증

각 인터랙티브 요소(버튼, 링크, 폼 컨트롤, 선택 가능한 아이콘 등)의 클릭/탭 영역 크기를 측정한다. DOM 요소의 getBoundingClientRect()를 통해 요소의 실제 렌더링 크기를 가져오고, 44×44 CSS 픽셀 기준과 비교한다. 이 기준을 충족하지 못하는 요소의 목록과 위치를 기록한다.

다만 여기서 한계를 솔직히 말해야 한다. getBoundingClientRect()로 요소의 시각적 크기는 알 수 있지만, 실제 터치 반응 영역(padding이나 pseudo-element로 확장된 영역)을 완전히 포착하기 어려운 경우가 있다. 요소가 작더라도 CSS로 ::before / ::after를 이용해 터치 영역을 확장하는 패턴이 있는데, 이런 경우는 DOM 분석만으로 완벽하게 탐지하기 어렵다. "이 버튼이 44px 미만입니다"라고 보고하더라도, 실제로는 터치 영역이 충분할 수도 있다는 뜻이다. 결과를 볼 때 이 점을 감안해야 한다.

텍스트 가독성과 콘텐츠 계층

좁은 화면에서 텍스트 크기가 과도하게 작아지거나, 중요한 CTA(행동 유도 버튼)가 스크롤 없이는 보이지 않는 위치로 밀리는 경우를 확인한다. 또한 meta viewport 태그가 올바르게 설정되어 있는지도 본다. user-scalable=no나 지나치게 제한적인 maximum-scale 설정은 사용자가 필요에 의해 화면을 확대하는 것을 막아 접근성을 저해한다.

뷰포트 오버플로

모바일 뷰포트에서 콘텐츠가 뷰포트를 가로로 초과하는 경우를 탐지한다. 이 경우 페이지에 의도하지 않은 수평 스크롤이 생기고, 이는 WCAG 1.4.10 리플로우 기준과 직접 연관된다.

세 화면을 동시에 열어두고 레이아웃을 비교하는 것은, 반응형 문제를 발견하는 가장 직접적인 방법이다.

공공웹에서 자주 보이는 반응형 문제 패턴

ViewCheck를 통해 다수의 공공 웹사이트를 분석하는 과정에서 반복적으로 등장하는 패턴들이 있다. 특정 사이트를 지목하는 게 아니라, 공공 웹 일반에서 자주 관찰되는 유형으로 정리한다.

패턴 1: 태블릿 구간의 방치

모바일과 데스크톱 두 개의 브레이크포인트만 설정하고, 태블릿 구간을 별도로 처리하지 않는 경우다. 결과적으로 768px에서 데스크톱 레이아웃이 그대로 적용되어 콘텐츠가 작게 표시되거나, 모바일 레이아웃이 너무 일찍 적용되어 화면 공간이 낭비된다. KRDS 가이드가 4단계 브레이크포인트를 제안하는 이유가 여기에 있다.

패턴 2: 터치 영역이 너무 작은 아이콘 버튼

상단 우측의 검색 아이콘, SNS 공유 아이콘, 즐겨찾기 버튼처럼 작은 아이콘 형태의 버튼들이 터치 영역 없이 배치되는 경우다. 아이콘 자체가 24×24px라면, 주변에 최소 10px 이상의 클릭 가능 영역이 추가되어야 44×44px 기준에 근접할 수 있다. 이 패딩 없이 그냥 배치하면, 터치 정밀도가 낮은 사용자(노인, 운동 장애 사용자, 이동 중 사용자)에게 실질적인 장벽이 된다.

패턴 3: 모바일에서 터치 요소가 너무 촘촘하게 배치

목록형 UI, 게시판, 필터 메뉴 등에서 항목들이 좁은 간격으로 나열되어 의도하지 않은 탭이 자주 일어나는 경우다. 특히 공지사항 목록이나 법령·고시 목록처럼 행 높이가 낮게 설정된 페이지에서 빈번하다. WCAG 2.5.8의 예외 조건(24px 원이 겹치지 않으면 허용)을 어기는 배치다.

패턴 4: 고정 너비 테이블이나 이미지의 가로 오버플로

데스크톱 기준으로 고정 너비(예: width: 900px)가 지정된 테이블이나 이미지가 모바일에서 그대로 렌더링되어 페이지 전체에 가로 스크롤이 생기는 경우다. 이는 WCAG 1.4.10 리플로우를 직접 위반한다. 공공 웹사이트에서는 데이터 테이블을 많이 사용하는 특성상 이 패턴이 특히 많이 발생한다.

패턴 5: 모바일에서 메뉴를 찾기 어려운 구조

데스크톱에서 상단 GNB(Global Navigation Bar)로 잘 보이던 메뉴가 모바일에서 햄버거 아이콘 안으로 들어가는 건 일반적이다. 그런데 그 햄버거 아이콘 자체가 너무 작거나, 열었을 때 닫기 버튼이 손가락으로 누르기 어려운 위치에 있거나, 모달처럼 화면 전체를 덮는데 배경 탭으로는 닫히지 않는 경우가 있다. 이런 패턴은 자동 분석보다 실제 인터랙션 테스트에서 더 잘 드러난다.

태블릿 뷰포트의 독특함 — 가로 모드와 세로 모드

태블릿 분석에서 빠뜨리기 쉬운 요소가 가로/세로 방향 전환이다. 태블릿 사용자는 기기를 세로로 들기도 하고, 가로로 눕혀서 사용하기도 한다.

WCAG 1.3.4 Orientation 기준이 바로 이 맥락에서 나온다. "콘텐츠를 특정 화면 방향(세로 또는 가로)으로만 동작하게 제한해서는 안 된다"는 것이다. 특정 서비스가 "세로 방향으로 사용하세요"라는 안내를 내보내고 가로로 기울이면 제대로 동작하지 않는다면, 이는 기준을 위반하는 것이다.

테스트 관점에서 보면, 태블릿의 768px 세로 방향과 1024px 가로 방향은 완전히 다른 레이아웃 경험을 줄 수 있다. 768px를 기준으로 적용된 CSS가 가로로 돌렸을 때의 1024px에서는 의도치 않게 데스크톱 레이아웃이 나올 수 있다. 또는 반대로, 1024px 뷰포트에서 두 열짜리 레이아웃이 뜨지 않고 단열 레이아웃이 그대로 유지되는 경우도 있다.

Rite (Technology.org, 2026)의 분석에 따르면 "사용자들은 눕거나 걸으면서 또는 멀티태스킹을 하며 기기를 가로와 세로 사이에서 자주 전환한다. 그 전환이 부드럽게 이루어지지 않으면 구조나 의미가 손상된다"(Technology.org, 'WCAG for Modern Web'). 이 관찰은 ViewCheck에서 방향 전환을 별도로 테스트하는 이유가 되고 있다.

NN/g의 모바일 사용성 연구가 주는 시사점

닐슨 노먼 그룹(Nielsen Norman Group)은 모바일 사용성 연구를 오랜 기간 축적해온 기관이다. Jakob Nielsen과 Raluca Budiu가 공저한 "Mobile Usability"는 터치스크린 기반 인터페이스의 사용성에 관한 주요 연구를 담고 있다(NN/g, 'Mobile Usability').

NN/g의 연구에서 반복적으로 나오는 발견 중 하나는 터치 타겟 크기와 직결된다. "작은 타겟이 진짜 문제"라는 것이다. 손가락이 크다는 게 문제가 아니라, 타겟이 너무 작아 어디를 눌러야 할지 모르게 만드는 설계가 문제라는 것. NN/g의 모바일/태블릿 연구 보고서는 터치스크린 스마트폰의 UI 개선을 위한 374가지 팁을 포함하고 있으며, 모바일 최적화 인트라넷과 모바일 웹 앱 설계의 사례 연구도 담고 있다(NN/g, 'Mobile & Tablet Usability Research Reports').

또한 NN/g는 반응형 설계의 사용성 관점에서 중요한 원칙을 제시한다. 작은 화면에서의 설계는 단순히 콘텐츠를 줄이는 것이 아니라, 우선순위를 재설계하는 것이라는 점이다. 어떤 정보가 먼저 보여야 하는지, 어떤 기능이 모바일에서 더 자주 쓰이는지를 다시 생각해야 한다. 이 사고방식은 "반응형 CSS를 입히면 끝"이라는 단순한 접근과는 다른 결을 요구한다.

GOV.UK Design System의 레이아웃 접근 — 비교 관점에서

KRDS와 자주 비교되는 GOV.UK Design System은 반응형 레이아웃을 어떻게 다루는가?

GOV.UK Design System의 레이아웃 문서에 따르면, 핵심 브레이크포인트는 **640px(태블릿 브레이크포인트)**이다. 640px를 경계로 "large screen" 스타일이 적용된다. 대부분의 GOV.UK 페이지는 "2/3과 1/3" 레이아웃 — 왼쪽 2/3에 본문, 오른쪽 1/3에 보조 콘텐츠 — 을 따르며, 이 그리드가 좁은 화면에서는 단열(single column)로 전환된다(GOV.UK Design System, design-system.service.gov.uk/styles/layout/).

GOV.UK의 특이점은 "단순하게, 글자 위주로"라는 철학이 반응형에도 그대로 적용된다는 점이다. 화려한 레이아웃 전환보다, 어떤 화면에서도 콘텐츠가 읽히고 기능이 작동하는 것을 우선시한다. 터치 타겟에 관해서도 GDS Blog의 초기 글 "Designing for different devices"(2012)에서 "큰 터치 타겟이 중요하다"는 원칙이 이미 언급되었다(GDS Blog, gds.blog.gov.uk).

KRDS와 비교했을 때 GOV.UK는 브레이크포인트 수가 더 적고 단순하다. KRDS가 4단계(xsmall, small, medium, large, xlarge)를 정의하는 것과 달리, GOV.UK는 mobile/tablet/desktop의 단순한 구분에 가깝다. 어느 쪽이 나은가라는 질문보다는, 다루는 콘텐츠 유형과 서비스 복잡도에 따라 적합한 접근이 다를 수 있다는 게 우리의 관찰이다.

세로와 가로 전환 — WCAG 1.3.4는 이 전환이 자유로워야 한다고 말한다. 실제로 확인하는 방법은 직접 기울여보는 것이다.

자동 분석의 가능성과 한계 — ViewCheck가 할 수 있는 것과 없는 것

이 편에서 솔직하게 가장 많이 이야기하고 싶었던 부분이다. 반응형 품질 분석에서 자동화가 어디까지 갈 수 있는지, 그리고 어디서부터 반드시 사람의 손이 필요한지.

자동화가 잘 되는 영역

터치타겟 크기를 DOM 요소의 렌더링 크기로 측정하는 것
뷰포트를 초과하는 요소(가로 오버플로)를 탐지하는 것
meta viewport 설정(user-scalable, maximum-scale)을 확인하는 것
세 뷰포트에서 각각 DOM을 수집해 구조 변화를 비교하는 것
특정 CSS 패턴(고정 너비 설정, overflow: hidden 남용 등)을 탐지하는 것

자동화가 어렵거나 불완전한 영역

실제 터치 인터랙션을 통한 오탭/미스탭 경험. 손가락 크기와 압력, 사용 자세에 따른 변수를 시뮬레이션하는 건 현실적으로 어렵다.
레이아웃의 시각적 어색함. "이 화면에서 이 배치가 이상하다"는 것은 사람의 눈으로 봐야 알 수 있는 경우가 많다.
CSS pseudo-element나 JavaScript로 확장된 터치 영역. DOM 요소 자체의 크기 외에 실제 반응 영역을 완전히 포착하기 어렵다.
사용자 맥락에 따른 우선순위 평가. 모바일에서 가장 중요한 정보가 스크롤 없이 보이는지는 콘텐츠 의미를 이해해야 판단할 수 있다.

이 한계는 ViewCheck만의 한계가 아니라, DOM 기반 자동 분석 전반의 한계다. 우리는 이 한계를 숨기기보다 명시하는 쪽을 택한다. 왜냐하면 담당자가 "ViewCheck에서 통과했으니 반응형은 문제없겠다"는 식으로 결론 내리는 게 가장 위험한 상황이기 때문이다. 자동 분석은 문제 가능성을 빠르게 탐지해 주는 도구이지, 사람의 판단을 대체하는 도구가 아니다.

TestParty가 정리한 "WCAG 1.4.10 리플로우 2025 가이드"도 비슷한 결론에 도달한다. "자동화된 도구는 기본적인 리플로우 문제를 탐지하는 데 도움이 되지만, 완전한 준수 여부는 실제 테스팅이 필요하다"(TestParty.ai, 'The 2025 TestParty Guide to WCAG 1.4.10'). 이 솔직함이 반응형 분석 도구를 바라보는 적절한 기준이라고 생각한다.

다중 페이지에서 반응형 품질이 더 중요한 이유

반응형 문제는 모든 페이지에서 동일하게 나타나지 않는다. 오히려 특정 페이지 유형에서 훨씬 심각하게 나타나는 경향이 있다.

공공 웹사이트에서 반응형 문제가 집중되는 페이지 유형은 대략 이렇다.

신청 · 접수 페이지 — 폼 요소가 많고, 항목마다 라벨·입력 필드·도움말이 붙어 있어 레이아웃이 복잡하다. 데스크톱 기준으로 가로 배치된 라벨-입력 구조가 모바일에서 세로로 스택되면서 페이지가 매우 길어지고, 터치 타겟이 촘촘해지는 경우가 많다.

데이터 테이블 · 통계 페이지 — 고정 너비 테이블이 모바일에서 가로 오버플로를 유발하는 것이 가장 전형적인 패턴이다. 통계청, 각 부처 통계 자료, 예산 현황 같은 표 형태의 데이터는 좁은 화면에서 다루기 까다롭다.

검색 결과 · 목록 페이지 — 페이지네이션 숫자 버튼이 작게 배치되어 터치가 어렵거나, 필터 UI가 모바일에서 접힌 상태로 진입 방법이 불명확한 경우가 있다.

이미지 · 미디어 heavy 페이지 — 고해상도 이미지나 인포그래픽이 모바일에서 그대로 축소되어 가독성이 없는 상태가 되거나, 반대로 이미지가 뷰포트를 초과하는 경우가 있다.

ViewCheck가 다중 페이지 분석을 기본으로 설계한 이유 중 하나가 바로 여기에 있다. 메인 페이지의 반응형이 잘 되어 있더라도, 신청 페이지에서 터치 타겟 문제가 있다면 그게 시민들이 실제로 불편함을 겪는 지점이다. 메인만 보고 "반응형 이상 없음"이라고 보고하는 건 현실과 거리가 있다. 그래서 우리는 다양한 페이지 유형을 포함한 분석을 기본으로 한다.

실제 분석에서 발견한 것들 — 숫자로 말하기 어려운 부분

이 대목을 쓰면서 가장 조심스러웠다. 구체적인 수치를 제시하면 그것이 "ViewCheck가 분석한 공공웹의 NN%가 반응형 문제를 가지고 있다"는 식으로 읽힐 수 있는데, 우리는 그런 방식의 수치 제시를 매우 신중하게 생각하기 때문이다.

실측에서 확인한 것들 중 공개적으로 말할 수 있는 패턴을 몇 가지 적는다.

터치타겟 크기 미달은 생각보다 흔하다. 특히 상단 GNB 아이콘 버튼들(검색, 메뉴, SNS 공유 등)과 하단 페이지네이션 숫자 버튼에서 자주 발견된다. 이 요소들은 데스크톱에서는 마우스로 쉽게 클릭되기 때문에 크기 문제가 눈에 잘 안 띄지만, 모바일에서 손가락으로 누르면 바로 체감된다.

태블릿 구간에서 의도하지 않은 레이아웃 전환이 발생하는 경우도 많다. 769px 이상에서 데스크톱 스타일이 적용되도록 설정되어 있는데, 768px(가장 일반적인 태블릿 뷰포트)에서는 모바일 스타일이 적용되어 어색한 레이아웃이 나오는 케이스가 있다. 1px 차이지만 실제 경험에서는 큰 차이가 난다.

meta viewport의 user-scalable=no 설정은 생각보다 여전히 발견된다. 이 설정은 사용자가 화면을 핀치 줌으로 확대하지 못하게 막아, 저시력 사용자에게 심각한 접근성 장벽이 된다. WCAG 1.4.4 (Resize Text, AA)의 취지에도 반하는 설정이다.

이런 발견들을 "이 사이트가 나쁘다"는 식으로 해석하기보다, "반응형 구현 이후에도 점검이 필요한 항목들이 있다"는 신호로 읽기를 권한다. 많은 경우 이 문제들은 개발자가 모바일 뷰포트에서 실제로 테스트하지 않고 데스크톱 기준으로만 검수한 결과이거나, CSS를 오래전에 작성한 뒤 업데이트하지 않은 경우에서 비롯된다.

KRDS의 반응형 지침 — 8pt 그리드와 마진

KRDS 공식 레이아웃 스타일 가이드에서 반응형과 직접 관련된 지침을 살펴보면 몇 가지 중요한 원칙이 있다.

8-Point Grid 원칙

KRDS는 8px(8-Point Grid)의 배수를 기본 간격 단위로 사용한다. 상황에 따라 4px 배수도 허용한다. 이 그리드 원칙은 일관된 간격 체계를 만들어 반응형 전환 시에도 비례감을 유지하게 해준다. 뷰포트가 달라져도 요소 간 비례가 깨지지 않으려면, 처음부터 배수 관계를 가진 간격 체계를 써야 한다.

4단계 브레이크포인트

KRDS는 small(360px~), medium(768px~), large(1024px~), xlarge(1280px~) 4단계를 정의한다. 360px 미만의 xsmall 구간은 최적화 대상에서 제외한다. 이 구간 설정은 실제 국내 사용자들이 많이 쓰는 기기 화면 크기를 반영한 것으로, 360px 이상의 안드로이드 기기와 390px의 아이폰을 모두 커버한다.

마진 기준

화면 마진은 모바일 최소 16px, PC 최소 24px 이상이다. 좁은 화면에서 콘텐츠가 화면 끝에 너무 붙지 않게 하는 최소 여백이다. 이 마진이 지켜지지 않으면 터치가 어려운 영역이 생기거나, 텍스트가 화면 끝에 붙어 가독성이 떨어진다.

모바일 4 column 그리드

모바일에서는 4 column을 기본으로, 최대 6 column까지 사용할 수 있다. 이 column 체계는 좁은 화면에서 콘텐츠를 정렬하는 기준을 제공한다. column 수가 많을수록 세밀한 레이아웃 제어가 가능하지만, 좁은 화면에서 지나치게 많은 column을 쓰면 각 column이 너무 좁아진다.

이 가이드라인들이 실제 공공 웹사이트에 얼마나 반영되어 있는지는, 정직하게 말하면 "확인 중"이다. KRDS 가이드를 공표한 이후 이를 충실히 적용하는 사이트가 늘고 있지만, 오래된 사이트나 외주 개발 과정에서 이 가이드를 잘 모르고 작업한 경우도 있다. KRDS 준수율을 측정한다는 것의 의미는, 이 가이드라인이 실제로 지켜지고 있는지 숫자로 확인하는 작업이기도 하다.

같은 URL을 세 화면에서 동시에 보면서 검토하는 일. 자동화 분석이 속도를 내고, 사람의 눈이 의미를 판단한다.

반응형 점수를 어떻게 산출하는가

ViewCheck LLM 분석의 24개 기능 카드 중 하나인 '반응형 품질' 카드는 세 뷰포트의 측정 결과를 종합한 점수를 제시한다. 이 점수를 어떻게 산출하는지, 그 원리를 간략하게 설명한다.

기본 구조는 이렇다. 세 뷰포트(데스크톱·태블릿·모바일)에서 각각 복수의 항목을 측정하고, 항목별로 통과/미통과를 판정한다. 판정 결과를 뷰포트별로 집계한 뒤, 세 뷰포트의 점수를 합산해 전체 반응형 점수로 만든다.

항목별 가중치는 사용 빈도와 영향도를 고려해 설정한다. 예를 들어 터치타겟 미달은 모바일 사용성에 직접적인 영향을 미치므로 가중치가 높다. 반면 meta viewport 설정 같은 항목은 접근성에 중요하지만, 터치타겟만큼 많은 사용자가 직접 체감하는 항목은 아니다.

다만 이 점수도 맹신해서는 안 된다. 자동 분석이 놓치는 항목이 있고, 측정 방식의 한계로 실제보다 높게 또는 낮게 나올 수 있다. 이 점수는 "이 정도 수준"을 파악하는 시작점이지, "이 점수가 곧 품질"은 아니다. 점수보다 함께 제공되는 미통과 항목 목록과 근거가 더 실질적으로 유용한 경우가 많다.

접근성과 반응형의 교차점 — 뷰포트와 인지 부하

반응형과 접근성은 별개의 주제처럼 느껴질 수 있지만, 실제로는 많은 부분이 교차한다.

저시력 사용자는 화면을 확대해서 사용한다. 400%로 확대한다는 것은 실질적으로 1280px 화면이 320px 뷰포트처럼 동작하는 것과 같다. 이 상태에서 콘텐츠가 수평 스크롤 없이 읽힌다는 것은, 그 사이트가 아주 좁은 뷰포트에서도 올바른 리플로우를 한다는 의미다. 즉, 반응형이 잘 되어 있으면 저시력 접근성도 함께 확보된다.

청각 장애 사용자는 반응형과 직접 관련이 없다고 생각할 수 있다. 하지만 모바일에서 자동 재생되는 동영상이나 오디오가 있다면, 그 제어 버튼이 충분히 커야 한다는 점에서 터치타겟 기준과 연결된다.

운동 장애 사용자, 파킨슨이나 수전증이 있는 사용자에게는 터치 타겟 크기가 특히 중요하다. 이 그룹에게는 44px가 아니라 더 큰 타겟이 필요한 경우도 있다. WCAG 기준이 "최소"인 이유가 여기에 있다 — 기준을 충족한다고 해서 모든 사용자에게 충분하다는 보장은 없다.

인지 장애 사용자에게는 반응형 전환 시의 레이아웃 변화가 혼란을 줄 수 있다. 데스크톱에서는 메뉴가 상단에 가로로 있고, 모바일에서는 햄버거 안에 있다면, 일관된 정신 모델을 유지하기 어렵다. 이 관점에서 반응형 설계는 "다른 뷰포트에서도 사용자가 혼란 없이 원하는 것을 찾을 수 있는가"라는 더 넓은 질문과 연결된다.

이런 교차점들이, ViewCheck에서 반응형 품질을 단순한 레이아웃 점검이 아니라 접근성과 연계된 관점으로 바라보는 이유다.

W3C WCAG 2.2 모바일 가이드 — 새로운 흐름

W3C의 모바일 접근성 태스크포스(MATF)는 2024년 1월 재결성되어 WCAG 2.2의 모바일 애플리케이션 적용 지침을 작업 중이다. "Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile)"이라는 별도 문서가 작업 중이며, 이는 WCAG가 모바일 맥락에서 어떻게 해석되어야 하는지를 보다 명확히 정리하려는 시도다(W3C, 'Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile)', w3.org/TR/wcag2mobile-22/).

이 문서가 완성되면, 모바일 앱과 모바일 웹에 대한 WCAG 적용이 더 구체화될 것이다. 현재로서는 모바일 맥락에 대한 WCAG 해석이 다소 불명확한 부분이 있는데, 이 지침이 그 공백을 채울 것으로 기대된다.

ViewCheck 입장에서 이 흐름은 중요하다. WCAG2Mobile이 완성되면 모바일/반응형 관련 점검 항목이 더 명확해지고, 자동화 가능한 항목과 사람이 직접 확인해야 할 항목의 구분도 더 명확해질 것이다. 이 변화에 맞춰 분석 로직을 업데이트하는 것은 우리가 지속적으로 해야 할 작업이다.

반응형 점검을 어떻게 활용할 것인가 — 담당자 관점

이 편을 읽는 독자 중 상당수는 실제 공공 웹사이트를 관리하거나 발주하는 담당자일 것이다. 반응형 분석 결과를 어떻게 활용할지에 대해 실용적인 관점을 몇 가지 정리한다.

먼저, 어떤 페이지 유형을 분석했는지 확인하라

반응형 분석은 메인 페이지보다 신청·접수·검색 결과·통계 페이지에서 문제가 더 많이 나온다. ViewCheck가 다중 페이지 분석을 기본으로 하는 이유가 여기에 있지만, 분석 결과를 볼 때 어떤 페이지가 포함됐는지를 함께 확인하는 것이 중요하다.

터치타겟 미달 목록을 외주 개발사에 전달하라

자동 분석에서 터치타겟 미달로 탐지된 요소 목록은 외주 개발사에 구체적인 수정 요청의 근거로 쓸 수 있다. "WCAG 2.5.5 Enhanced 기준(44×44px)에 미달하는 요소 N개"라는 수치와 함께 요소 목록을 전달하면, 모호한 "좀 더 크게 해주세요" 요청보다 훨씬 명확한 커뮤니케이션이 된다.

meta viewport 설정은 즉시 수정 가능하다

user-scalable=no나 maximum-scale=1.0 같은 설정은 코드 한 줄을 바꾸는 수준으로 수정 가능하다. 개선 난이도가 낮으면서 접근성 영향이 큰 항목이므로 우선순위를 높여서 처리하는 게 좋다.

모바일에서 직접 확인하는 과정을 건너뛰지 마라

자동 분석 이후, 실제 스마트폰으로 핵심 서비스 페이지(신청서 작성, 검색, 로그인)를 직접 사용해 보는 과정은 건너뛸 수 없다. 자동화가 찾아준 것들을 확인하고, 자동화가 놓친 것들을 발견하는 과정이다. 이 두 과정이 함께 갈 때, 반응형 품질 점검이 실질적인 의미를 갖는다.

아직 풀지 못한 것들 — 솔직하게

이 편에서 다룬 내용을 돌아보면, 우리가 "이렇게 하면 됩니다"라고 말할 수 있는 것보다, "이건 아직 어렵습니다"라고 말해야 하는 것들이 더 많다는 걸 발견한다.

아직 풀지 못한 것들을 솔직하게 나열한다.

실제 터치 인터랙션 시뮬레이션 — DOM 기반으로는 터치 반응 영역을 완전히 포착하지 못한다. 실제 사용자가 손가락으로 누르는 경험을 완전히 시뮬레이션하는 것은 여전히 어렵다. Playwright에서 pointer event를 시뮬레이션할 수 있지만, 실제 물리적 손가락과 화면 간의 상호작용 전체를 재현하지는 못한다.

레이아웃의 시각적 어색함 판정 — "이 화면에서 이 배치가 어색하다"는 판단은 사람의 시각적 평가가 필요하다. CSS Pixel Inspector나 screenshot 비교로 일부 탐지할 수 있지만, "어색하다"의 기준을 자동화하기는 어렵다.

모든 기기 뷰포트 커버리지 — 1920, 768, 390이라는 세 가지 뷰포트는 대표적이지만 전체가 아니다. 240px대의 작은 기기, 다양한 노트북 해상도, 4K 디스플레이 등 실제 사용 환경은 훨씬 다양하다. 세 개의 대표 구간이 주는 인사이트는 충분히 가치 있지만, "세 개를 봤으니 다 됐다"는 결론으로 가면 안 된다.

콘텐츠 우선순위의 모바일 최적화 — 어떤 정보가 작은 화면에서 먼저 보여야 하는지는 콘텐츠의 맥락과 사용자 의도를 이해해야 판단된다. 이건 기술적 자동화보다 서비스 기획의 영역에 더 가깝다.

이 한계들이 우리가 반응형 분석을 "완성된 기능"이 아니라 "진행 중인 연구"로 부르는 이유다. 24편의 분석 기능 중 반응형 품질은 비교적 탐지 정확도가 높은 편이지만, 그래도 여전히 발전의 여지가 크다.

마무리 — 세 화면을 보는 것의 의미

긴 이야기를 마무리하면서, 처음으로 돌아간다.

"PC에서는 잘 되는데 폰으로 들어오면 이상해요."

이 민원이 왜 계속 들어오는가. 개발자나 담당자가 게으른 게 아니다. 사이트를 만들고 검수하는 대부분의 과정이 데스크톱 화면 앞에서 이루어지기 때문이다. 모바일에서 어떻게 보이는지, 태블릿에서 어떻게 동작하는지를 매번 꼼꼼히 확인하는 것은 — 특히 수십 개의 페이지를 가진 사이트에서는 — 현실적으로 매우 어렵다.

자동화 분석이 그 간극을 채울 수 있다. 세 뷰포트를 동시에 측정하고, 터치타겟 미달을 자동으로 탐지하고, 뷰포트 오버플로를 찾아내는 것. 이 작업을 100개 페이지에 대해 자동으로 돌리는 것이 ViewCheck의 역할이다. 빠르게, 반복적으로, 근거와 함께.

다만 이것이 "이제 사람이 확인 안 해도 된다"는 의미는 아니다. 자동화가 탐지한 문제를 사람이 보고 "이게 실제로 문제인가, 어떻게 고쳐야 하는가"를 판단하는 과정은 여전히 필요하다. 그리고 자동화가 아직 탐지하지 못하는 영역 — 시각적 어색함, 실제 터치 인터랙션, 콘텐츠 우선순위 — 에 대한 사람의 검토도 빠질 수 없다.

WCAG 2.5.8이 말하는 24px, 2.5.5가 말하는 44px, Apple HIG가 말하는 44pt, Material Design이 말하는 48dp — 이 숫자들은 수십 년의 인간공학 연구와 실제 사용자 관찰에서 나온 것들이다. 그 숫자 하나가 어떤 의미인지를 이해하고, 실제 사이트에서 지켜지고 있는지를 확인하는 것. 그것이 반응형 품질 연구의 첫 걸음이다.

우리는 그 걸음을 매일 조금씩 내딛고 있다. 다음 편에서 또 다른 측면을 이어가겠다.

참고문헌

본문에 인용한 출처는 작성 시점에 모두 실재 여부를 검증했다. 국내 공식 기준 및 정책 자료와 국제 표준·연구를 함께 실었다.

국내 — 공식 기준 / 정책 자료

행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025. 6. 25. 일부개정). 행정안전부. https://www.mois.go.kr/frt/bbs/type001/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000016&nttId=118636
행정안전부, 「전자정부 웹사이트 품질관리 지침」. 국가법령정보센터. https://www.law.go.kr/admRulLsInfoP.do?admRulId=37565
KRDS(범정부 UI/UX 디자인시스템) 공식 사이트 — 레이아웃 스타일 가이드. 행정안전부·디지털플랫폼정부위원회. https://www.krds.go.kr/html/site/style/style_05.html
KRDS 공식. https://www.krds.go.kr/
UXKM, '한국형 웹 콘텐츠 접근성 가이드라인(KWCAG) 2.2 해설'. https://uxkm.io/accessibility/a11y/04-a11yCag/02-kwcag
한국형 웹 콘텐츠 접근성 지침(KWCAG) 2.2. https://a11ykr.github.io/kwcag22/

해외 — 국제 표준 / 플랫폼 가이드라인 / UX 연구

W3C WAI, "Understanding Success Criterion 2.5.8: Target Size (Minimum)", WCAG 2.2. https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html
W3C WAI, "Understanding Success Criterion 2.5.5: Target Size (Enhanced)", WCAG 2.2. https://www.w3.org/WAI/WCAG22/Understanding/target-size-enhanced.html
W3C WAI, "Understanding Success Criterion 1.4.10: Reflow", WCAG 2.1. https://www.w3.org/WAI/WCAG21/Understanding/reflow.html
W3C, "Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile)". https://www.w3.org/TR/wcag2mobile-22/
W3C, "Web Content Accessibility Guidelines (WCAG) 2.2". https://www.w3.org/TR/WCAG22/
Material Design 3, "Accessibility Designing — Touch Target". Google. https://m3.material.io/foundations/designing/structure
Material Design (M2), "Touch Target Support". Google. https://m2.material.io/develop/web/supporting/touch-target
GOV.UK Design System, "Layout". Government Digital Service. https://design-system.service.gov.uk/styles/layout/
GOV.UK Design System. https://design-system.service.gov.uk/
GDS Blog, "Designing for different devices", 2012. Government Digital Service. https://gds.blog.gov.uk/2012/11/02/designing-for-different-devices/
Nielsen Norman Group, "Mobile & Tablet Usability Research Reports". https://www.nngroup.com/reports/topic/mobile-and-tablet-design/
Nielsen Norman Group, "Mobile Usability 2nd Research Study". https://www.nngroup.com/articles/mobile-usability-2nd-study/
AAArdvark, "WCAG 2.5.5 Target Size (Enhanced) — Plain English". https://aaardvarkaccessibility.com/wcag-plain-english/2-5-5-target-size-enhanced/
AllAccessible, "WCAG 2.5.8 Target Size (Minimum): Complete Implementation Guide". https://www.allaccessible.org/blog/wcag-258-target-size-minimum-implementation-guide
Silktide, "WCAG 1.4.10: Reflow". https://silktide.com/accessibility-guide/the-wcag-standard/1-4/distinguishable/1-4-10-reflow/
TestParty.ai, "The 2025 TestParty Guide to WCAG 1.4.10 – Reflow (Level AA)". https://testparty.ai/blog/wcag-1-4-10-reflow-2025-guide
TestParty.ai, "Mobile Accessibility Testing: WCAG 2.2 Requirements for Responsive Design". https://testparty.ai/blog/mobile-accessibility-testing
Technology.org, "WCAG for Modern Web: Accessibility in Mobile-First, Touch Interfaces, and Responsive Design", 2026. https://www.technology.org/2026/01/29/wcag-for-modern-web-accessibility-in-mobile-first-touch-interfaces-and-responsive-design/
Zac Dickerson, "Size matters! Accessibility and Touch Targets", Medium, 2018. https://medium.com/@zacdicko/size-matters-accessibility-and-touch-targets-56e942adc0cc
MDN Web Docs, "Responsive Design". https://developer.mozilla.org/ko/docs/Learn_web_development/Core/CSS_layout/Responsive_Design
LogRocket Blog, "All accessible touch target sizes". https://blog.logrocket.com/ux-design/all-accessible-touch-target-sizes/

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

045편 : 래디어스 최댓값을 12px로 설정하고 있다.

ViewCheck — Sun, 27 Sep 2026 14:00:57 +0900

045편 : 래디어스 최댓값을 12px로 설정하고 있다.

KRDS 체크리스트 항목 DS-045 · 디자인 스타일 > 형태 〈846 규칙 완전 분해 시리즈 ㊺〉 — "둥글기의 천장": 12px이라는 분명한 상한

0. 들어가며 — 상한을 못 박는 이유

지난 44편에서 레디어스 범위를 '2px~12px'로 봤습니다. 이번 45편은 그중 상한(12px) 을 다시 한 번 명시적 으로 못 박는 규칙입니다.

44편에서 이미 12px이 상한이라 했는데, 왜 별도 규칙으로 또 강조할까요? 30·31편(두께 둘/넷)에서 봤듯, KRDS는 중요한 한계를 명시적 항목으로 분리해 빠짐없이 지켜지게 합니다. '범위가 2~12px'(044)이라는 규칙과 '최댓값은 12px'(045)이라는 규칙을 함께 두어, 상한이 흐려지지 않게 하는 것이죠. 이번 편은 이 12px 천장이 왜 그렇게 중요한지를 집중해서 풀어냅니다.

1. 규칙 원문 — 분명한 천장

DS-045 (디자인 스타일 > 형태) "래디어스 최댓값을 12px로 설정하고 있다."

레디어스가 어떤 경우에도 12px을 넘지 말아야 한다는 뜻입니다. 큰 컴포넌트라도, 특수한 경우라도 둥글기의 천장은 12px입니다.

정리: 레디어스는 어떤 경우에도 12px을 넘지 마라. 이게 DS-045입니다.

2. 왜 12px 천장이 필요한가

레디어스에 천장이 없으면 어떤 일이 벌어질까요? 둥글기가 슬금슬금 커집니다.

디자인을 하다 보면 "이 카드를 좀 더 부드럽게", "이 버튼을 더 둥글게" 같은 요구가 계속 쌓입니다. 천장이 없으면 이 요구가 누적되어 어느새 레디어스가 16px, 20px, 24px로 커집니다. 그러면 화면이 점점 가볍고 캐주얼해지고, 정부 서비스의 신뢰감 있는 인상에서 멀어집니다. 또 큰 둥글기는 작은 컴포넌트의 형태를 일그러뜨리고(알약·원형화, DS-050), 모서리가 콘텐츠를 가리는 문제(DS-049)도 키웁니다.

12px이라는 분명한 천장은 이 '둥글기 인플레이션'을 막습니다. "더 둥글게 하려면 12px까지만"이라는 한계가 있으면, 둥글기가 무한정 커지지 않습니다. 이는 강조색 5% 상한(DS-012), 디스플레이 과대 금지(DS-038)와 같은 '과함을 막는 천장'의 원리입니다. 한계가 분명해야 절제가 유지됩니다.

특히 이 천장은 범정부 일관성을 위한 것이기도 합니다. 모든 정부 서비스가 12px을 넘지 않으면, 둥글기의 '최대 정도'가 통일되어 어느 사이트를 가도 비슷한 형태 톤을 유지합니다. 한 곳만 매우 둥글면 통일성이 깨지지만, 모두가 같은 천장을 지키면 일관됩니다.

3. 큰 컴포넌트에서도 12px — 비례의 함정 피하기

"큰 카드나 모달은 더 둥글어도 되지 않나?"라는 생각이 들 수 있습니다. 큰 요소는 12px이 상대적으로 작아 보이니까요. 하지만 KRDS는 큰 컴포넌트에서도 12px을 넘지 말라고 합니다.

이유는 '둥글기가 무한정 커지는 것'을 막기 위해서입니다. 큰 요소라고 레디어스를 키우기 시작하면, '얼마나 커야 적당한가'에 끝이 없습니다. 그래서 절대 상한(12px)을 둬, 컴포넌트가 아무리 커져도 둥글기는 그 안에서 멈추게 합니다. 큰 카드도 12px이면 충분히 부드럽고, 그 이상은 과합니다.

다만 컨테이너 크기에 따라 레디어스를 '비율에 맞게' 조정하는 별도 규칙(DS-048)이 있습니다. 이는 작은 요소는 더 작은 레디어스를, 큰 요소는 (12px 이내에서) 더 큰 레디어스를 쓰라는 것이지, 12px을 넘으라는 뜻이 아닙니다. 천장(12px)은 유지하되, 그 안에서 크기에 비례하는 것이죠. 천장과 비례가 함께 작동합니다.

4. 흔한 위반 패턴 / 점검 / 개선

흔한 위반 패턴

함정 ① 천장 초과. 16px·20px 등 12px 초과 → 과한 둥글기. → 12px 이하로. 함정 ② 큰 요소 과둥글. 큰 카드에 큰 레디어스 → 천장 초과. → 큰 요소도 12px 이내. 함정 ③ 둥글기 누적. "더 둥글게" 요구 누적으로 천장 넘음. → 12px에서 멈춤.

무엇을 점검하나

최댓값 — 모든 레디어스가 12px 이하인가.
큰 컴포넌트 — 큰 요소도 천장(12px)을 지키는가.
일관성 — 둥글기의 최대 정도가 통일됐는가.

Before / After

/* ❌ Before: 천장 초과 */
.modal { border-radius: 20px; }   /* 12px 초과 */

/* ✅ After: 12px 천장 준수 */
.modal { border-radius: 12px; }   /* 큰 요소도 상한 유지 */

5. 누가 담당하나 / 우리 사이트에 해당될까?

역할	책임
디자이너	레디어스 최댓값을 12px로 설계
퍼블리셔/개발	레디어스 토큰 상한을 12px로 강제

기관 유형	DS-045 적용
중앙행정기관(대표·운영) / 공공기관 / 지자체	✅ 필수

둥근 모서리 컴포넌트가 있는 모든 사이트 = 해당.

6. 30초 자가진단 + FAQ

✅ 30초 자가진단

□ 모든 레디어스가 12px 이하인가요?
□ 큰 카드·모달도 12px을 넘지 않나요?
□ "더 둥글게" 요구로 천장을 넘기지 않았나요?

❓ FAQ

Q1. 44편(2~12px)과 45편(최댓값 12px), 뭐가 다른가요? 44편은 '범위(2~12px)' 전체를, 45편은 그중 '상한(12px)'을 명시적으로 강조합니다. 상한이 흐려지지 않도록 별도 항목으로 못 박은 것입니다(두께 둘/넷처럼 권장과 한계를 함께 두는 방식).

Q2. 큰 요소는 12px이 작아 보이는데요? 큰 요소도 12px이면 충분히 부드럽습니다. 둥글기를 키우기 시작하면 끝이 없으므로, 절대 상한을 둬 절제합니다. 크기 비례는 12px 이내에서 조정합니다(DS-048).

Q3. 원형(50%)은 천장과 별개인가요? 원형 처리는 별도 사항입니다. 작은 컴포넌트의 50% 원형화는 권장하지 않습니다(DS-050). 12px 천장은 일반 모서리 둥글기에 적용됩니다.

Q4. KRDS를 채택하면 자동인가요? KRDS 레디어스 토큰의 최댓값이 12px로 정의돼 있습니다. 채택하면 DS-045가 충족됩니다.

7. 마무리 — 천장이 절제를 지킨다

DS-045의 메시지는 한계의 가치를 담습니다.

둥글기에 분명한 천장(12px)이 있어야, 둥글기 인플레이션을 막고 일관성을 지킨다.

천장이 없으면 둥글기는 슬금슬금 커져 화면이 가벼워지고 형태가 일그러집니다. 12px이라는 분명한 상한은 이 인플레이션을 막고, 모든 정부 서비스의 둥글기를 통일합니다. 큰 요소라도 천장을 지켜야 절제가 유지되죠. 이는 강조색·디스플레이 크기의 상한과 같은, '과함을 막는 천장'의 일관된 원리입니다.

다음 편은 레디어스의 '단위'를 다룹니다. DS-046 — "래디어스 값을 px 또는 % 단위로 설정한다." 둥글기를 어떤 단위로 표현해야 하는지를 살펴봅니다.

다음 편 예고 ▶ 「046. 래디어스 값을 px 또는 % 단위로 설정하고 있다.」

우리 사이트의 레디어스가 천장을 지키는지 확인하려면? ViewCheck는 모든 레디어스 값이 12px 이하인지, 큰 컴포넌트도 상한을 지키는지를 진단합니다.

참고 출처

KRDS 형태(Shape)·디자인 토큰 가이드 — https://www.krds.go.kr/html/site/style/style_07.html

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

026편 : [접근성연구·모바일] 메뉴를 못 찾는 순간

ViewCheck — Sat, 26 Sep 2026 16:00:07 +0900

026편 : [접근성연구·모바일] 메뉴를 못 찾는 순간

모바일 탐색 점검 관점

〈디지털 접근성 연구 026〉 — 이 글은 규정이 아니라 하나의 연구 관점입니다. 인용 수치·기준은 출처와 함께, 미확정 영역은 그렇다고 밝혀 작성합니다.

들어가며

앞 편(025)에서 모바일 내비게이션의 기준, 즉 메뉴를 접어도 길이 보존되어야 한다는 관점을 다뤘다. 이번 편은 그 시선을 '실패의 순간'으로 좁힌다. 사용자가 모바일에서 메뉴를, 길을, 원하는 페이지를 '못 찾는' 구체적 순간들을 모아, 점검에서 그 막힘을 어떻게 재현하고 찾아낼지에 관한 점검 관점이다.

길을 못 찾는 일은 흔히 사용자의 탓으로 돌려진다. '익숙하지 않아서', '잘 못 봐서'. 그러나 점검의 관점에서는 그 반대다. 익숙하지 않은 사용자도, 잘 못 보는 사용자도 길을 찾을 수 있어야 잘 설계된 것이다. 누군가 길을 못 찾았다면, 그 순간은 사용자의 실수가 아니라 점검이 잡아내야 할 신호다.

이 글은 메뉴를 못 찾는 순간을 유형별로 모으고, 각 순간을 점검에서 어떻게 재현해 드러낼지를 정리한다. 특정 사이트를 지목하지 않고, '왜 못 찾는가'와 '어떻게 찾아낼 수 있게 점검하는가'에 초점을 둔다.

1. 못 찾는 순간의 유형 — 무엇이 길을 가리나

사용자가 모바일에서 길을 못 찾는 순간은 몇 가지 유형으로 정리된다.

메뉴 입구를 못 찾는 순간. 메뉴를 여는 아이콘 자체를 발견하지 못한다. 아이콘이 작거나, 구석에 있거나, 무슨 기능인지 알 수 없는 모양이면, 사용자는 '메뉴가 어디 있지?'에서 멈춘다. 메뉴는 거기 있지만, 입구를 못 찾으면 없는 것과 같다.

열고도 못 찾는 순간. 메뉴를 열었는데 항목이 너무 많거나 분류가 모호해, 원하는 항목이 어디 있는지 모른다. 메뉴 안에서 다시 길을 잃는다.

돌아가는 길을 못 찾는 순간. 한 페이지로 들어갔는데, 이전 화면이나 홈으로 돌아가는 길이 분명하지 않다. 사용자는 막다른 골목에 갇힌 느낌을 받는다.

현재 위치를 모르는 순간. 여러 단계를 거쳐 들어왔는데, 지금 사이트의 어디쯤에 있는지 알 수 없다. 위치를 모르면 다음 행동을 정하기 어렵다.

네 유형을 '어디서 멈추나'와 함께 정리하면 다음과 같다.

못 찾는 유형	멈추는 지점	사용자의 속마음	점검에서 보는 신호
입구를 못 찾음	시작 화면	"메뉴가 어디 있지?"	작은·이름 없는 아이콘
열고도 못 찾음	펼친 메뉴 안	"어느 분류 아래지?"	항목 과다·모호한 분류
돌아갈 길 없음	들어간 페이지	"어떻게 돌아가지?"	페이지 내 복귀 단서 부재
현재 위치 모름	여러 단계 진입 후	"내가 지금 어디지?"	현재 항목·경로 표시 부재

(관점) 네 유형은 모두 '메뉴가 없어서'가 아니라 '있는데 닿는 길이 흐려서' 생긴다. 점검은 메뉴의 유무가 아니라 길의 선명함을 본다.

1-1. 못 찾음은 '점진적 포기'로 이어진다

길을 못 찾는 순간은 한 번에 포기로 이어지지 않는다. 사용자는 보통 몇 번 더 시도한다. 화면 여기저기를 눌러보고, 스크롤을 오르내리고, 뒤로 가기를 누른다. 그러다 일정 횟수 시도해도 길이 안 보이면 그때 포기한다. 이 '점진적 포기'의 과정은 운영 측에 잘 드러나지 않는다. 사용자가 떠났다는 결과만 남고, 그가 몇 번을 시도하다 포기했는지는 보이지 않는다. 점검이 이 순간을 미리 재현해야 하는 이유다.

2. 점검의 기본 자세 — '처음 쓰는 사람'을 빌려오기

메뉴를 못 찾는 순간을 점검으로 잡아내려면, 점검자의 자세부터 바꿔야 한다. 익숙한 점검자는 메뉴가 어디 있는지 이미 안다. 그 손으로는 막힘이 드러나지 않는다.

그래서 점검의 핵심은 '처음 쓰는 사람의 손'을 빌려오는 것이다. 이 사이트를 처음 여는 사람이라면, 메뉴 아이콘을 한눈에 알아볼까. 가로줄 세 개를 보고 그것이 메뉴라고 짐작할까. 원하는 기능으로 가는 항목 이름을 메뉴에서 바로 찾을까. 한 페이지로 들어간 뒤 돌아오는 길을 헤매지 않을까. 이 질문들을 '익숙한 나'가 아니라 '처음인 사람'의 입장에서 물어야 한다.

가능하다면 실제로 그 사이트를 처음 쓰는 사람에게 특정 과제(예: '○○ 안내를 찾아보세요')를 주고, 어디서 멈추는지 지켜보는 것이 가장 정확하다. 점검자 혼자서는 자기 익숙함을 완전히 떼어내기 어렵기 때문이다.

2-1. '과제 기반 점검'의 힘

길 찾기 점검에서 효과적인 방법은 '과제'를 정해두고 그 과제를 끝까지 수행해 보는 것이다. '메뉴가 보이는가'라는 막연한 점검보다, '○○ 신청 페이지까지 가보라'는 구체적 과제가 막힘을 잘 드러낸다. 과제를 수행하다 멈추는 지점이 곧 사용자가 길을 못 찾는 지점이다. 막연히 둘러보면 '대충 있는 것 같다'로 끝나지만, 목적지를 정해 끝까지 가보면 도중의 막힘이 또렷이 보인다.

3. 각 순간을 점검에서 재현하는 법

못 찾는 순간의 유형별로, 점검에서 어떻게 재현해 드러낼지를 정리한다.

메뉴 입구 점검. 화면 상단을 보고, 메뉴를 여는 입구가 한눈에 보이는지 확인한다. 아이콘만 있고 '메뉴' 글자가 없다면, 그 아이콘이 메뉴임을 처음 쓰는 사람이 알 수 있을지 의심한다. 화면 낭독기를 켜고, 그 아이콘이 '메뉴'로 읽히는지도 확인한다.

열고 난 뒤 점검. 메뉴를 열어, 원하는 항목을 몇 초 안에 찾을 수 있는지 본다. 항목이 너무 많아 스크롤해야 하거나, 분류가 모호해 어디를 눌러야 할지 망설여진다면, 그 자리가 막힘이다.

돌아가는 길 점검. 한 페이지로 들어간 뒤, 이전 화면과 홈으로 돌아가는 길이 분명한지 본다. 브라우저 뒤로 가기 말고, 페이지 안에서 돌아갈 수 있는 단서(상단 링크, 경로 표시 등)가 있는지 확인한다.

현재 위치 점검. 여러 단계를 거쳐 들어간 뒤, 지금 사이트의 어디에 있는지 알 수 있는 단서가 있는지 본다. 현재 메뉴 항목 강조나 경로 표시가 그런 단서다.

각 점검을 '재현 동작'과 '막힘 판정 기준'으로 표에 모으면 다음과 같다.

점검	재현 동작	막힘으로 보는 기준
메뉴 입구	상단을 보고 입구를 찾음 + 낭독기로 읽힘 확인	처음 쓰는 사람이 입구를 못 짚음
열고 난 뒤	메뉴 열어 목표 항목을 몇 초 안에 찾음	스크롤·분류 모호로 망설임 발생
돌아가는 길	페이지 안에서 복귀 단서로 돌아감	브라우저 뒤로 가기에만 의존
현재 위치	진입 후 현재 위치 단서 확인	현재 항목·경로 표시 없음

(관점) 점검의 결론은 '됐다/안 됐다'가 아니라 '어디서 멈췄나'다. 멈춘 지점이 곧 사용자의 포기 지점이므로, 재현은 그 지점을 또렷이 만드는 작업이다.

3-1. 키보드·낭독기로도 같은 과제를

이 점검들을 손가락 터치로만 하면 절반만 본 것이다. 같은 과제를 키보드만으로, 그리고 화면 낭독기로 들으며 수행해 본다. 키보드로 메뉴를 열고 항목을 이동해 목적지에 닿을 수 있는가. 낭독기가 메뉴와 항목을 읽어주어, 보지 않고도 길을 찾을 수 있는가. 시각적으로는 멀쩡한 길이 키보드·낭독기 사용자에게는 막혀 있을 수 있으므로, 같은 과제를 다른 입력 방식으로 반복하는 것이 점검의 완성이다.

4. 관찰 — 길을 잃은 장면들

공공 영역의 여러 화면에서 길 찾기 과제를 수행하며 모은 막힘의 장면을, 익명으로 정리한다.

한 장면에서는 특정 안내를 찾으라는 과제를 두고 시작했는데, 메뉴 입구인 아이콘이 화면 구석에 작게 있어 발견까지 시간이 걸렸다. 처음 쓰는 사람이라면 더 오래 헤맸을 것이다. 다른 장면에서는 메뉴를 열었으나 항목이 많고 분류가 겹쳐, 찾던 안내가 어느 분류 아래 있는지 두 번 잘못 들어간 뒤에야 닿았다. 또 다른 장면에서는 한 안내 페이지로 들어간 뒤, 같은 메뉴의 다른 안내로 가려는데 돌아가는 길이 분명하지 않아 브라우저 뒤로 가기에 의존해야 했다.

이 장면들의 공통점은 '결국 닿기는 했다'는 것이다. 점검자는 끈기 있게 시도해 목적지에 도달했다. 그러나 그 과정의 막힘과 헤맴은, 덜 익숙하거나 덜 끈기 있는 사용자에게는 포기 지점이 되었을 것이다. 점검은 '닿았는가'에서 멈추지 않고 '얼마나 헤맸는가'까지 기록해야 한다.

관찰한 장면을 익명으로 묶으면 다음과 같다.

관찰된 장면	막힌 지점	점검자는	덜 끈기 있는 사용자는
입구 발견 지연	작은·구석 아이콘	시간 들여 발견	시작 화면에서 이탈
분류 혼동	겹친 분류 체계	두 번 잘못 든 뒤 도달	첫 오진입에서 포기
복귀 막힘	페이지 내 복귀 단서 부재	브라우저 뒤로 가기 의존	막다른 골목으로 느낌

(관찰) 위 장면은 특정 기관을 지목하지 않은 익명 관찰이며, 점검 시점·기기에 따라 다르게 나타날 수 있다. 공통점은 '점검자는 닿았지만, 그 도달이 사용자 경험을 보장하지 않는다'는 것이다.

4-1. '닿았다'와 '쉽게 닿았다'는 다르다

길 찾기 점검에서 흔한 함정은 '결국 찾았으니 됐다'고 판단하는 것이다. 점검자는 끈기와 익숙함을 가지고 있어 대개 결국은 찾아낸다. 그러나 사용자에게 중요한 것은 '찾을 수 있는가'가 아니라 '헤매지 않고 찾는가'다. 두 번 잘못 들어간 뒤 찾았다면, 그것은 두 번의 포기 기회를 지난 것이다. 점검은 도달 여부만이 아니라, 도달까지의 헤맴(잘못 든 횟수, 멈춘 지점)을 함께 봐야 실제 사용자 경험에 가까워진다.

5. 점검의 기록과 우선순위

길 찾기 점검의 발견은 '과제 / 막힌 지점 / 헤맨 정도 / 입력 방식'으로 기록하면 재현과 개선이 쉬워진다. 예를 들어 '○○ 안내 찾기 / 메뉴 입구 발견 지연 / 처음 쓰는 사람 기준 / 터치·키보드 모두'처럼 적는다.

우선순위는 '닿지 못함'을 기준으로 가른다. 길이 아예 끊겨 닿을 수 없는 경우(항목 누락, 키보드로 메뉴 못 엶)가 가장 무겁다. 그다음은 닿기는 하지만 크게 헤매는 경우(입구를 못 찾음, 분류가 모호함)다. 그다음은 닿되 약간 불편한 경우(돌아가는 길이 다소 불분명함)다. 미관상 아쉽지만 길 찾기에 지장이 없는 것은 가장 나중이다.

우선순위를 표로 정리하면 다음과 같다.

등급	상태	예	사용자에게
가장 무거움	길이 끊김(닿지 못함)	항목 누락, 키보드로 메뉴 못 엶	그 기능이 아예 없는 것과 같음
무거움	크게 헤맴	입구 못 찾음, 분류 모호	다수가 도중 포기
보통	약간 불편	복귀 길 다소 불분명	끈기 있으면 도달
가벼움	미관상 아쉬움	길 찾기엔 지장 없음	경험에 큰 영향 없음

(관점) 우선순위의 축은 '보기 좋은가'가 아니라 '닿는가'다. 가장 위 두 등급은 디자인 개선이 아니라 길 복구의 문제다.

5-1. 반복되는 막힘은 구조의 문제다

여러 과제에서 같은 유형의 막힘이 반복된다면, 그것은 특정 페이지의 문제가 아니라 사이트 전체의 내비게이션 구조 문제일 가능성이 크다. 메뉴 입구가 모든 페이지에서 발견하기 어렵다거나, 분류 체계가 전반적으로 모호하다면, 페이지 하나를 고쳐서 해결되지 않는다. 점검 기록을 모아 패턴을 보면, 개별 증상 뒤의 구조적 원인이 드러난다.

5-2. 반론과 한계

이 점검 관점에도 반론과 한계가 있다.

반론·한계	내용	이 글의 입장
"결국 다 찾는다"	끈기 있으면 도달함	도달 여부가 아니라 헤맴의 양이 경험을 좌우
점검자 주관	'쉬움'의 기준이 사람마다 다름	그래서 과제·헤맨 횟수를 수치로 기록
처음 사용자 섭외 어려움	매번 신규 사용자를 부르기 어려움	점검자가 '처음의 손'을 의식적으로 빌려옴
자동화 한계	헤맴·망설임은 동작 점검이 필요	입구 존재·레이블은 자동, 헤맴은 사람

(관점) 한계를 적는 것은 이 점검이 '완벽한 측정'이 아니라 '막힘을 드러내는 관점'임을 밝히기 위해서다. 못 찾음을 사용자 탓으로 돌리지 않는 자세가 핵심이다.

5-3. ViewCheck의 관점 — 사람과 도구의 분담

길 찾기 점검은 자동 도구가 빠르게 훑는 영역과 사람이 직접 수행해야 하는 영역이 갈린다.

점검 항목	자동 점검이 보는 것	사람이 봐야 하는 것
메뉴 입구	아이콘 레이블·역할 존재	처음 쓰는 사람이 입구를 짚는지
메뉴 항목	항목 수·구조 신호	분류가 직관적인지, 망설임 발생 여부
돌아가는 길	복귀 링크·경로 표시 유무	실제로 헤매지 않고 돌아오는지
키보드·낭독기	포커스·읽힘 가능 신호	같은 과제를 끝까지 수행하는 흐름
반복 막힘	페이지 전반의 동일 증상 집계	구조적 원인인지의 판단

(관점) 자동 점검은 '신호의 유무'를 사이트 전체에서 빠르게 모으고, 사람은 '그 신호가 길로 이어지는가'를 과제로 검증한다. ViewCheck는 둘을 합쳐, 못 찾는 순간을 사용자 탓이 아닌 점검의 신호로 본다.

6. 한 장 요약

구분	핵심
못 찾는 유형	입구 못 찾음·열고도 못 찾음·돌아갈 길 없음·현재 위치 모름
막힘의 결과	점진적 포기 — 운영 측에 잘 안 드러남
점검 자세	'처음 쓰는 사람의 손'을 빌려오기
효과적 방법	과제 기반 점검(목적지 정해 끝까지 가보기)
다른 입력	같은 과제를 키보드·화면 낭독기로 반복
기록 기준	과제/막힌 지점/헤맨 정도/입력 방식
우선순위	'닿지 못함' 기준, 반복 막힘은 구조 문제 의심

맺으며

메뉴를 못 찾는 순간은 사용자의 실수가 아니라 점검이 잡아내야 할 신호다. 입구를 못 찾고, 열고도 헤매고, 돌아갈 길을 잃고, 현재 위치를 모르는 순간들은 모두 '길이 충분히 분명하지 않다'는 증거다. 그리고 이 막힘은 익숙한 점검자의 손으로는 잘 드러나지 않으므로, '처음 쓰는 사람'의 관점을 빌려 구체적 과제를 끝까지 수행해 봐야 비로소 드러난다.

우리는 길 찾기를 '닿았는가'가 아니라 '헤매지 않고 닿는가'로 본다. 결국 찾았다는 것은 점검자의 끈기를 증명할 뿐, 사용자의 경험을 보장하지 않는다. 다음 편에서는 모바일의 또 다른 영역, 화면을 가로로 돌리거나 확대했을 때의 대응, 즉 '방향·확대 대응'으로 넘어간다.

다음 편 예고 (027): 〈가로로 돌리면 확대하면 / 방향·확대 대응 연구〉 — 화면을 가로로 돌리거나 확대했을 때 레이아웃과 기능이 어떻게 견뎌야 하는지, 방향·확대 대응의 기준을 연구 관점으로 정리한다.

참고한 공개 자료(출처):

W3C, Web Content Accessibility Guidelines (WCAG) 2.1 — Consistent Navigation(3.2.3), Multiple Ways(2.4.5), Keyboard(2.1.1), Name/Role/Value(4.1.2) 등 (정확한 항목·등급은 원문 확인 권장)
한국지능정보사회진흥원(NIA), 한국형 웹 콘텐츠 접근성 지침(KWCAG) 2.x — 탐색·일관성 관련 항목
행정안전부·디지털플랫폼정부, KRDS(공공 디자인 시스템) 내비게이션·탐색 관련 공개 문서
MDN Web Docs — Navigation patterns, Usability testing 개요

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

044편 : 2px~12px의 래디어스 값을 사용하고 있다.

ViewCheck — Sat, 26 Sep 2026 14:00:56 +0900

044편 : 2px~12px의 래디어스 값을 사용하고 있다.

KRDS 체크리스트 항목 DS-044 · 디자인 스타일 > 형태 〈846 규칙 완전 분해 시리즈 ㊹〉 — "둥글기에도 적정 범위가 있다": 2px에서 12px 사이

0. 들어가며 — 단계에 '실제 값'을 부여하다

지난 43편에서 레디어스를 '5단계로 구성'하라는 원칙을 봤습니다. 이번 44편은 그 단계의 실제 값 범위를 못 박습니다 — 2px에서 12px 사이.

레디어스 5단계가 '구조'라면, 2~~12px은 그 구조의 '눈금'입니다. 둥글기를 0px(완전 각짐)부터 무한히 둥글게 할 수 있지만, KRDS는 그 범위를 2~~12px로 한정합니다. 너무 각지지도(2px 미만), 너무 둥글지도(12px 초과) 않은 적정 범위죠. 이번 편은 왜 이 범위인지, 둥글기의 적정선이 어디인지를 풀어냅니다.

1. 규칙 원문 — 값의 범위

DS-044 (디자인 스타일 > 형태) "2px~12px의 래디어스 값을 사용하고 있다."

레디어스 값을 최소 2px, 최대 12px 범위 안에서 쓰라는 뜻입니다. 5단계(43편)가 이 범위 안에 분포하는 것이죠.

정리: 레디어스 값은 2px~12px 범위 안에서 쓰라. 이게 DS-044입니다.

2. 왜 2px이 최소인가 — 둥글기가 보이려면

하한이 2px인 이유부터 봅시다. 1px이나 0.5px처럼 너무 작은 레디어스는 둥글기가 거의 안 보입니다. 화면에서 사실상 각진 모서리와 구분이 안 되죠. 둥글기를 줄 거라면, 그 둥글기가 인지될 만큼은 되어야 의미가 있습니다. 2px은 '둥글기가 최소한 보이는' 하한선입니다.

물론 의도적으로 각진(레디어스 0) 스타일을 선택할 수도 있습니다. 하지만 '살짝 둥글게' 하려다 1px 같은 어중간한 값을 쓰면, 둥근 것도 각진 것도 아닌 모호한 형태가 됩니다. 그래서 둥글게 할 거면 최소 2px 이상으로 확실히, 각지게 할 거면 0으로 — 어중간한 둥글기를 피하는 것이 깔끔합니다. 2px 하한은 이 '모호한 둥글기'를 막습니다.

3. 왜 12px이 최대인가 — 적정 인상의 상한

상한이 12px인 이유는 더 중요합니다. 너무 둥글면 인상이 달라지고 형태가 일그러지기 때문입니다.

레디어스가 과하게 크면(예: 20px, 30px), 모서리가 지나치게 둥글어져 화면이 너무 캐주얼하거나 가벼워 보입니다. 정부 서비스의 신뢰감 있는 인상과 안 맞죠. 또 큰 레디어스는 작은 컴포넌트에서 형태를 일그러뜨립니다 — 작은 버튼에 큰 레디어스를 주면 거의 알약(pill)이나 원형이 되어버립니다(이건 DS-050에서 다룸). 그리고 모서리가 너무 둥글면 내부 콘텐츠가 모서리에 가려지는 문제도 생깁니다(DS-049).

12px은 '충분히 둥글되, 과하지 않은' 상한입니다. 이 범위 안에서는 부드럽고 친근하면서도 신뢰감 있는 인상이 유지되고, 형태도 안정적입니다. 정부 서비스에 어울리는 '절제된 둥글기'의 천장인 것이죠. 이는 디스플레이 크기의 상한(DS-038), 강조색의 상한(DS-012)과 같은 '과함을 막는 천장'의 원리입니다.

4. 2~12px 범위가 주는 일관성

이 범위는 단순히 '예쁜 둥글기'를 넘어, 범정부 서비스의 형태 일관성을 위한 것이기도 합니다.

모든 정부 서비스가 2~12px 범위의 레디어스를 쓰면, 어느 정부 사이트를 가도 비슷한 '형태 톤'을 갖습니다. 한 곳은 각지고 한 곳은 매우 둥글면 통일성이 깨지지만, 모두가 같은 범위 안에 있으면 일관된 인상을 줍니다. 색을 같은 팔레트로 통일한 것(DS-001)처럼, 둥글기도 같은 범위로 통일하는 것이죠.

이 범위 안에서 5단계(43편)가 분포합니다 — 예를 들어 2px, 4px, 8px, 12px 같은 식으로요(정확한 값은 KRDS 토큰 기준). 작은 요소는 2~~4px, 중간은 8px, 큰 요소는 12px처럼 크기에 맞춰 단계를 골라 쓰면, 범위 안에서 체계적인 둥글기가 적용됩니다. 범위(2~~12px)와 단계(5단계)가 함께 작동해 일관되고 적정한 형태를 만드는 것입니다.

5. 흔한 위반 패턴 / 점검 / 개선

흔한 위반 패턴

함정 ① 과한 둥글기. 20px 이상 레디어스 → 가벼운 인상, 형태 일그러짐. → 12px 이하로. 함정 ② 어중간한 둥글기. 1px 등 거의 안 보이는 레디어스 → 모호. → 2px 이상 또는 0. 함정 ③ 범위 밖 혼재. 일부는 2~12px, 일부는 범위 밖 → 부조화. → 범위 통일. 함정 ④ 단계 무시. 범위 안이지만 제각각 값 → 일관성 부족. → 5단계로(43편).

무엇을 점검하나

값 범위 — 레디어스가 2~12px 범위 안인가.
하한 — 둥글기가 너무 작아(1px 등) 모호하지 않은가.
상한 — 둥글기가 12px을 넘어 과하지 않은가.
단계 분포 — 범위 안에서 5단계로 체계화됐는가.

Before / After

/* ❌ Before: 범위 밖 + 어중간 */
.card { border-radius: 24px; }   /* 과함 */
.tag { border-radius: 1px; }     /* 거의 안 보임 */

/* ✅ After: 2~12px 범위 */
.tag { border-radius: 2px; }     /* 작은 요소 */
.btn { border-radius: 8px; }     /* 중간 */
.card { border-radius: 12px; }   /* 큰 요소(상한) */

6. 누가 담당하나 / 우리 사이트에 해당될까?

역할	책임
디자이너	레디어스를 2~12px 범위로 설계
퍼블리셔/개발	레디어스 토큰을 범위 안에서 적용

기관 유형	DS-044 적용
중앙행정기관(대표·운영) / 공공기관 / 지자체	✅ 필수

모서리가 둥근 컴포넌트가 있는 모든 사이트 = 해당.

7. 30초 자가진단 + FAQ

✅ 30초 자가진단

□ 레디어스가 2~12px 범위 안인가요?
□ 너무 둥근(12px 초과) 모서리가 없나요?
□ 1px 등 거의 안 보이는 어중간한 둥글기가 없나요?
□ 범위 안에서 크기별로 단계가 적용됐나요?

❓ FAQ

Q1. 왜 12px이 상한인가요? 12px을 넘으면 너무 둥글어 가벼운 인상을 주고, 작은 컴포넌트에서 형태가 일그러지며, 콘텐츠가 모서리에 가려질 수 있습니다. 12px은 '충분히 둥글되 과하지 않은' 적정 상한입니다(DS-045에서 더 다룸).

Q2. 각진 모서리(0px)는 안 되나요? 의도적으로 각진 스타일을 일관되게 쓸 수는 있습니다. 다만 '살짝 둥글게' 하려면 2px 이상으로 확실히 하세요. 1px 같은 어중간한 값이 가장 모호합니다.

Q3. 원형 버튼(50%)은요? 원형은 별도 고려 사항입니다. 작은 컴포넌트에 50% 레디어스(완전 원형)는 권장하지 않습니다(DS-050). 2~12px은 일반 모서리 둥글기의 범위입니다.

Q4. 큰 카드도 12px이 최대인가요? 네, 컨테이너가 커져도 레디어스는 12px이 상한입니다. 다만 비율 고려는 있습니다(DS-048). 무작정 키우지 않고 범위 안에서 조정합니다.

Q5. KRDS를 채택하면 자동인가요? KRDS 레디어스 토큰은 2~12px 범위로 정의돼 있습니다. 채택하면 DS-044가 충족됩니다.

8. 마무리 — 적정 범위의 미학

DS-044의 메시지는 절제된 범위의 가치를 담습니다.

둥글기에도 적정 범위가 있다 — 너무 각지지도, 너무 둥글지도 않은 2px~12px.

2px 하한은 둥글기가 보이게 하고, 12px 상한은 둥글기가 과하지 않게 합니다. 이 범위 안에서 둥근 모서리는 부드럽고 친근하면서도 신뢰감 있는 인상을 만들죠. 그리고 모든 정부 서비스가 이 범위를 공유하면 형태의 통일성이 생깁니다. 적정 범위로 절제하는 것 — 색·크기·강조에서 본 원리가 둥글기에도 그대로 적용됩니다.

다음 편은 이 범위의 상한을 다시 짚습니다. DS-045 — "래디어스 최댓값을 12px로 설정한다." 12px이라는 천장의 의미를 더 깊이 살펴봅니다.

다음 편 예고 ▶ 「045. 래디어스 최댓값을 12px로 설정하고 있다.」

우리 사이트의 레디어스 값이 적정 범위인지 확인하려면? ViewCheck는 사이트의 레디어스 값이 2~12px 범위 안인지, 과하거나 어중간한 둥글기가 없는지를 진단합니다.

참고 출처

KRDS 형태(Shape)·디자인 토큰 가이드 — https://www.krds.go.kr/html/site/style/style_07.html

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

공식 배너(Masthead) 자가진단 - ViewCheck 5분 점검

ViewCheck — Sat, 26 Sep 2026 10:01:09 +0900

공식 배너(Masthead) 자가진단 - ViewCheck 5분 점검

정부 사이트에 들어가면 화면 맨 위, 헤더보다도 더 위에 가느다란 띠가 하나 있습니다. "이 누리집은 대한민국 공식 전자정부 누리집입니다" 같은 한 줄과, 그 왼쪽에 작은 태극 문양 비슷한 마크. 대부분의 사람은 이걸 거의 의식하지 못하고 지나갑니다. 너무 위에 있고, 너무 작고, 매번 똑같으니까요. 그런데 이 작은 띠가 바로 KRDS가 말하는 **공식 배너(Masthead)**입니다. 그리고 이건 "장식"이 아니라 "신뢰의 표식"입니다.

왜 신뢰의 표식이냐면, 요즘 진짜 정부 사이트를 사칭하는 가짜 사이트가 너무 많기 때문입니다. 환급금을 미끼로 한 피싱, 과태료를 빙자한 사기, 정부 지원금을 가장한 개인정보 탈취. 이런 가짜들이 노리는 건 "이게 진짜 정부 사이트처럼 보이는가"입니다. 그래서 진짜 정부 사이트가 "나는 진짜다"라고 일관된 방식으로 알려 주는 장치가 필요해졌습니다. 그게 공식 배너입니다. 모든 진짜 전자정부 누리집이 똑같은 자리에 똑같은 문구와 마크로 "공식 누리집"임을 선언하면, 사용자는 그 띠가 없거나 이상한 사이트를 보고 "어, 이건 좀 수상한데"라고 의심할 수 있게 됩니다.

이 글은 "KRDS 완전해부" 시리즈 중에서도 조금 특별한 편입니다. 다른 컴포넌트들은 "어떻게 잘 만드느냐"가 주제라면, 공식 배너는 "있는가, 제대로 박혀 있는가"가 핵심이거든요. 그래서 이번 글은 자가진단 체크리스트 중심으로 갑니다. 거창한 디자인 이론보다, "우리 사이트 맨 위에 그 띠가 있나?", "있다면 KRDS 기준대로 박혀 있나?"를 5분 안에 스스로 확인하는 방법을 정리하겠습니다. 그리고 그 점검을 사람이 일일이 페이지마다 눈으로 보는 대신 ViewCheck로 한 번에 돌리는 법까지요.

미리 한 가지만 짚으면, 공식 배너는 "한 번 넣으면 끝"인 컴포넌트처럼 보이지만 실제로는 그렇지 않습니다. 사이트가 수십·수백 페이지로 늘어나는 동안 어떤 페이지에는 들어가고 어떤 페이지에는 빠지고, 리뉴얼하면서 통째로 사라지고, 모바일에서만 안 보이고, 코드상으로만 있고 화면엔 안 뜨는 등 의외로 잘 깨집니다. 그래서 "넣었다"가 아니라 "지금도 모든 페이지에 제대로 떠 있다"를 주기적으로 확인해야 하는, 생각보다 손이 가는 항목입니다.

공식 배너(Masthead)가 대체 뭔가 — 정의부터 정확히

먼저 용어부터 맞추겠습니다. "Masthead"라는 영어 단어는 원래 신문 1면 맨 위, 신문 이름과 발행 정보가 박힌 영역을 가리키는 말이었습니다. 웹으로 넘어오면서 "페이지 최상단의 식별 영역"을 뜻하게 됐고, KRDS는 이걸 전자정부 공식 누리집임을 알리는 최상단 띠로 정의합니다.

여기서 헷갈리기 쉬운 세 가지를 명확히 구분하겠습니다.

공식 배너(Masthead): 화면 맨 꼭대기, 헤더(GNB)보다 위에 위치하는 가느다란 띠. "공식 전자정부 누리집"임을 알리는 문구 + 식별 마크. 페이지 전체에서 가장 먼저, 가장 위에 옵니다.
헤더(Header): 그 아래에 오는 기관 로고 + 주 메뉴(GNB) + 검색 영역. 사이트의 "얼굴"이지만 공식 배너와는 별개 컴포넌트입니다.
히어로/메인 비주얼: 본문 상단의 큰 이미지나 슬로건 영역. 이건 또 다른 것입니다.

이 셋이 위에서부터 차례로 "공식 배너 → 헤더 → 본문"으로 쌓입니다. 공식 배너는 이 중 가장 위, 가장 작고, 가장 변하지 않는 요소입니다. 변하지 않아야 한다는 게 핵심입니다 — 사용자가 어느 정부 사이트에 가든 똑같은 자리에서 똑같은 띠를 봐야, "아 여기도 진짜 공식 누리집이구나"를 무의식적으로 확인할 수 있으니까요.

공식 배너가 담는 정보

KRDS의 공식 배너 패턴이 전달하는 핵심 메시지는 보통 두 갈래입니다.

"이 누리집은 공식 전자정부 누리집입니다" — 진위 식별. 이 사이트가 사칭이 아니라 진짜 정부가 운영하는 곳임을 선언.
"공식 누리집을 식별하는 방법 안내" — 사용자가 진짜와 가짜를 구분하는 법을 펼쳐 볼 수 있는 안내. 보통 띠를 클릭하거나 펼치면 "주소가 go.kr로 끝나는지 확인하세요" 같은 식별 가이드가 나옵니다.

즉 공식 배너는 단순히 "정부 사이트입니다"라고 적힌 라벨이 아니라, 사용자에게 진위 판별 능력을 쥐여 주는 작은 교육 장치이기도 합니다. 그래서 펼침/접힘 동작이 들어가는 경우가 많고, 그 동작이 키보드와 스크린리더로도 작동해야 한다는 접근성 요건이 따라붙습니다.

KRDS는 공식 배너에 무엇을 요구하나 — 기준 해부

이제 본론입니다. KRDS 가이드라인(디지털 정부서비스 UI/UX 가이드라인, 2025.08판)과 컴포넌트 문서, 그리고 웹 접근성 기준(KWCAG)을 종합해 공식 배너가 충족해야 할 요건을 영역별로 정리하겠습니다. 구체적인 수치나 정확한 문구는 공식 자료가 최종 기준이므로, 여기서는 "무엇을 봐야 하는가"의 관점으로 풉니다.

KRDS 공식 가이드 화면

1) 위치 — 페이지 최상단, 헤더보다 위

공식 배너의 첫 번째 요건은 위치입니다. 화면에서 가장 먼저 나오는 요소여야 합니다. 헤더(로고·메뉴)보다 위, 본문보다는 당연히 위. 코드 순서로도 보통 가장 앞에 옵니다. 이게 중요한 이유는, 사용자가 페이지를 위에서 아래로 훑을 때 "진짜인가?"라는 신뢰 확인을 가장 먼저 끝내게 하기 위해서입니다. 한참 스크롤한 다음에 푸터 근처에서 "공식 누리집입니다"가 나오면 의미가 없습니다.

스크린리더 사용자에게도 이 순서가 중요합니다. 코드 순서가 곧 읽히는 순서이기 때문에, 공식 배너가 코드상 맨 앞에 있으면 음성으로 듣는 사람도 페이지에 진입하자마자 "공식 전자정부 누리집입니다"를 먼저 듣게 됩니다.

2) 일관성 — 모든 페이지에 동일하게

공식 배너는 메인 페이지에만 있어선 안 됩니다. 사이트의 모든 페이지 최상단에 동일하게 있어야 합니다. 사용자가 외부 검색을 통해 메인이 아닌 깊숙한 내부 페이지(예: 특정 민원 신청 페이지)로 바로 들어오는 경우가 매우 많기 때문입니다. 그 사람도 진입한 페이지에서 "여기가 진짜 공식 누리집인가"를 확인할 수 있어야 합니다.

이게 실무에서 가장 자주 깨지는 지점입니다. 메인은 새 디자인 시스템으로 만들었는데 일부 하위 페이지는 옛날 템플릿을 그대로 쓰거나, 별도 시스템(예: 예약 시스템, 외부 위탁 페이지)으로 빠지면서 공식 배너가 사라집니다. 그래서 공식 배너 점검은 "메인만 보면 안 되고 사이트 전체를 봐야 한다"는 게 핵심입니다 — 바로 ViewCheck의 다중 페이지 분석이 빛을 발하는 지점이죠.

3) 식별 마크와 문구 — 표준을 따를 것

공식 배너에는 공식 누리집임을 나타내는 마크(엠블럼)와 문구가 들어갑니다. 이 마크와 문구는 사이트마다 제멋대로 바꾸는 게 아니라 정해진 표준을 따라야 합니다. 그래야 사용자가 사이트를 옮겨 다녀도 같은 표식을 인지할 수 있습니다. 기관 로고와는 별개입니다 — 기관 로고는 헤더에 들어가고, 공식 배너의 마크는 "전자정부 공식"이라는 공통 표식입니다.

문구 역시 "공식 전자정부 누리집"임을 분명히 전달하는 표준 문안을 따릅니다. 임의로 "우리 기관 홈페이지에 오신 것을 환영합니다" 같은 인사말로 바꿔 버리면 공식 배너의 기능을 잃습니다. 정확한 표준 마크 이미지와 문안은 KRDS 공식 자료(가이드라인 PDF, 컴포넌트 킷)에서 확인해야 합니다.

4) 펼침/접힘 동작 — 접근성 완비

많은 공식 배너는 평소엔 한 줄로 접혀 있다가, 클릭하면 "공식 누리집 식별 방법" 안내가 펼쳐지는 구조입니다. 이 펼침/접힘은 단순한 시각 효과가 아니라 접근성 요건이 따라붙는 인터랙션입니다.

펼침 버튼이 키보드로 조작 가능해야 합니다(Tab으로 초점 이동, Enter/Space로 펼치고 접기).
현재 펼쳐졌는지 접혔는지를 코드로 알려야 합니다(aria-expanded="true/false"). 그래야 스크린리더가 "확장됨/축소됨"을 읽어 줍니다.
펼침 버튼과 펼쳐지는 내용 영역이 연결(aria-controls)돼 있어야 합니다.
펼침/접힘 상태가 시각적으로도 구분돼야 합니다(화살표 방향 등). 그리고 그 시각 정보가 색에만 의존하지 않아야 합니다.

이건 셀렉트나 아코디언 같은 다른 펼침형 컴포넌트와 똑같은 원리입니다. "보이는 것과 읽히는 것의 일치"가 여기서도 핵심입니다.

5) 초점 표시(Focus)

공식 배너 안의 펼침 버튼이나 링크에 키보드로 초점이 왔을 때, 지금 거기에 초점이 있다는 게 또렷하게 보여야 합니다. 공식 배너는 화면 맨 위에 작게 있다 보니, 디자인 통일성을 이유로 포커스 표시를 outline: none으로 지워 버리는 경우가 흔합니다. 그러면 키보드 사용자는 페이지 진입 직후 첫 초점이 어디에 있는지 알 수 없게 됩니다.

6) 대비와 가독성

공식 배너는 작고 위에 있다 보니 연한 회색 배경에 연한 회색 글씨로 흐릿하게 처리되는 경우가 있습니다. 작다고 흐려도 된다는 뜻은 아닙니다. 문구와 배경의 명도 대비가 충분해야 저시력 사용자도 읽을 수 있습니다. "어차피 아무도 안 보는 띠"라는 생각이 이 흐릿함을 만드는데, 그 생각 자체가 공식 배너의 목적(신뢰 확인)을 부정하는 셈입니다.

7) 반응형 — 모바일에서도 유지

공식 배너는 데스크톱뿐 아니라 모바일에서도 떠 있어야 합니다. 화면이 좁다고 모바일에서만 공식 배너를 숨기는 경우가 의외로 많은데, 모바일 사용자야말로 피싱 링크를 문자나 메신저로 받아 들어오는 비중이 높습니다. 즉 진위 확인이 가장 필요한 사용자가 모바일 사용자인데, 거기서 배너를 빼는 건 본말이 전도된 겁니다. 좁은 화면에 맞게 문구를 줄이거나 레이아웃을 바꿀 순 있어도, 통째로 없애선 안 됩니다.

정리하면, KRDS의 공식 배너 기준은 세 축으로 요약됩니다. ① 존재와 일관성(모든 페이지 최상단에 표준 마크·문구로), ② 조작 가능성(펼침/접힘이 키보드·스크린리더로 작동), ③ 가독성과 신뢰성(충분한 대비, 표준 준수로 진위 식별 기능 유지). 이 세 축이 그대로 ViewCheck가 공식 배너를 점검하는 기준이 됩니다.

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

여기까지 읽고 "고작 한 줄짜리 띠에 뭐 이렇게 요건이 많나" 싶으실 수 있습니다. 그런데 이 작은 띠가 짊어진 무게를 알면 생각이 달라집니다.

신뢰는 "있을 때"가 아니라 "없을 때" 작동한다

공식 배너의 진짜 힘은 역설적이게도 그게 없을 때 드러납니다. 모든 진짜 정부 사이트에 공식 배너가 일관되게 있어야, 그게 없는 가짜 사이트가 "어색하게" 느껴지거든요. 이건 마치 지폐의 위조 방지 장치와 같습니다. 진짜 지폐에 홀로그램과 숨은 그림이 일관되게 있어야, 그게 없는 위조지폐를 사람들이 의심할 수 있습니다.

문제는 진짜 정부 사이트 중 일부라도 공식 배너를 빠뜨리면, 이 신뢰 체계 전체가 흔들린다는 점입니다. "진짜인데 배너가 없는 사이트"가 존재하면, 사용자는 "배너 없음 = 가짜"라는 판단을 더 이상 믿을 수 없게 됩니다. 그래서 공식 배너는 한 기관만의 문제가 아니라, 전체 전자정부 신뢰 시스템의 구성 요소입니다. 우리 사이트의 배너 누락이 다른 모든 정부 사이트의 신뢰까지 약하게 만드는 셈입니다.

가장 취약한 사용자가 가장 많이 노출된다

피싱과 사칭의 표적이 되는 사람들은 대개 디지털에 덜 익숙한 고령층, 그리고 정보 접근이 제한된 사용자입니다. 이들은 URL을 일일이 확인하거나 사이트 인증서를 검증할 여력이 없습니다. 그들이 기댈 수 있는 건 "익숙한 표식"입니다. 늘 보던 그 공식 배너가 있으면 안심하고, 없으면 멈칫하는 거죠.

그런데 만약 공식 배너가 스크린리더로 안 읽히면, 시각장애 사용자는 이 신뢰 확인을 아예 할 수 없습니다. 비장애인은 "공식 누리집입니다" 띠를 눈으로 보고 안심하는데, 음성으로만 쓰는 사용자는 그 안심의 근거를 못 받는 겁니다. 진위 확인이라는 가장 중요한 기능에서조차 차별이 생기는 거죠. KRDS가 공식 배너의 접근성을 까다롭게 요구하는 이유가 이겁니다.

"안 보이는 곳"이라 더 방치된다

공식 배너는 화면 맨 위 가장자리에 있어서, 디자인 검수나 QA에서 가장 늦게 보거나 아예 안 보는 영역입니다. 모두가 본문 콘텐츠와 핵심 기능에 집중하느라, 맨 위 띠는 "원래 있던 거"로 치고 넘어갑니다. 그러다 리뉴얼이나 템플릿 교체 과정에서 슬그머니 사라져도 아무도 눈치채지 못합니다. 가장 중요한 신뢰 장치가 가장 주목받지 못하는 자리에 있다는 게 공식 배너의 딜레마입니다. 그래서 사람의 눈이 아니라 자동 점검 도구가 "맨 위에 그 띠가 있는가"를 기계적으로 확인해 주는 게 효과적입니다.

일관성이 곧 학습이다

사용자가 정부 사이트 A에서 공식 배너를 한 번 인지하면, 사이트 B·C·D에서도 같은 표식을 찾습니다. 이 "한 번 배우면 어디서나 통함"이 표준화의 핵심 가치입니다. 만약 사이트마다 배너 위치·모양·문구가 제각각이면, 사용자는 매번 새로 학습해야 하고 결국 아무것도 신뢰하지 못하게 됩니다. KRDS가 공식 배너를 표준 컴포넌트로 묶어 둔 건, 디자이너의 창의성을 막으려는 게 아니라 국민의 인지 자산을 지키려는 일입니다.

왜 "공식 배너"라는 별도 컴포넌트가 따로 있나

여기서 한 발 더 들어가 보겠습니다. 생각해 보면 "공식 누리집입니다"라는 한 줄은 그냥 헤더 어딘가에 텍스트로 넣어도 됩니다. 그런데 KRDS는 이걸 굳이 별도의 컴포넌트로 정의해 두었습니다. 왜일까요.

첫째, 위치를 고정하기 위해서입니다. 그냥 텍스트면 디자이너마다 헤더 왼쪽에, 오른쪽에, 푸터에 제각각 둡니다. 별도 컴포넌트로 "최상단 띠"라고 못박아 두면, 모든 사이트에서 같은 자리에 옵니다. 사용자가 진위를 확인할 때 "어디를 봐야 하는지"가 통일되는 거죠. 신뢰 표식은 항상 같은 자리에 있어야 표식으로서 기능합니다.

둘째, 상호작용을 표준화하기 위해서입니다. 공식 배너는 단순 텍스트가 아니라 펼침/접힘이 들어가는 인터랙션 컴포넌트입니다. 펼치면 식별 안내가 나오는 그 동작을, 컴포넌트로 묶어 두면 키보드·스크린리더 지원까지 한 묶음으로 표준화됩니다. 텍스트 한 줄로 두면 이런 접근성 요건이 따라붙지 않아 누락되기 쉽습니다.

셋째, 재사용과 일괄 적용을 위해서입니다. 별도 컴포넌트라 공통 레이아웃에 한 번 꽂으면 전 페이지에 자동 적용됩니다. "모든 페이지에 일관되게"라는 요건을 기술적으로 보장하는 가장 쉬운 방법이 바로 컴포넌트화입니다. 이게 공식 배너가 독립 컴포넌트로 존재하는 실용적 이유입니다.

전자정부 신뢰 인프라의 한 조각

조금 더 큰 그림에서 보면, 공식 배너는 단독으로 존재하지 않습니다. 보안 연결(HTTPS), 공식 도메인 체계(go.kr 등), 개인정보처리방침, 인증서 — 이런 여러 신뢰 장치가 함께 작동해 "이 사이트는 믿을 만하다"를 만듭니다. 공식 배너는 그중에서 사용자 눈에 가장 먼저, 가장 직관적으로 보이는 조각입니다. 보안 인증서는 사용자가 일부러 확인하지 않으면 안 보이지만, 공식 배너는 페이지를 열자마자 눈에 들어옵니다. 그래서 디지털에 덜 익숙한 사용자에게는 이 시각적 표식이 다른 어떤 기술적 장치보다 강력한 신뢰 신호로 작동합니다. 가장 단순하지만 가장 직접적인 방어선인 셈입니다.

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

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

실수 1) 일부 페이지에서 배너가 사라진다

가장 흔한 실수입니다. 메인 페이지에는 공식 배너가 멀쩡히 있는데, 외부 시스템으로 연결되는 페이지나 옛 템플릿을 쓰는 하위 페이지에서는 배너가 빠집니다.

나쁜 예: 메인은 공식 배너 있음. 그런데 "온라인 예약" 페이지는 외부 위탁 시스템이라 배너 없음. 검색으로 예약 페이지에 바로 들어온 사용자는 진위 확인을 못 함.
올바른 예: 외부 위탁·별도 시스템 페이지에도 동일한 공식 배너를 적용. 공통 레이아웃(헤더 템플릿)에 배너를 포함시켜, 새 페이지를 만들어도 자동으로 들어가게 설계.

실수 2) 모바일에서만 배너를 숨긴다

데스크톱 디자인엔 배너를 넣었는데, 화면이 좁다는 이유로 모바일 CSS에서 display: none으로 숨깁니다.

나쁜 예: 반응형 분기에서 모바일일 때 공식 배너를 통째로 숨김. 정작 피싱에 가장 취약한 모바일 사용자가 진위 확인 수단을 잃음.
올바른 예: 모바일에서도 배너 유지. 공간이 부족하면 문구를 축약하거나 줄바꿈으로 대응하되, 존재 자체는 보존.

실수 3) 펼침 버튼에 접근성 속성이 없다

공식 배너를 클릭하면 식별 안내가 펼쳐지는데, 그 펼침 버튼이 <div>에 클릭 이벤트만 붙은 "가짜 버튼"입니다.

나쁜 예: 펼침 영역이 <div onclick="...">. role도 aria-expanded도 없음. 키보드로 펼칠 수 없고, 스크린리더는 펼쳐졌는지 접혔는지 모름.
올바른 예: <button> 요소를 쓰거나, 최소한 role="button"·aria-expanded·aria-controls를 갖춤. 키보드(Enter/Space)로 펼치고 접을 수 있고, 상태가 음성으로 전달됨. 가능하면 KRDS 컴포넌트 킷 코드를 그대로 사용.

실수 4) 문구·마크를 임의로 바꾼다

표준 공식 배너 문구 대신 기관 자체 인사말이나 다른 디자인의 마크를 넣습니다.

나쁜 예: "○○기관 홈페이지입니다" 같은 인사말로 대체. 공식 누리집 식별 기능 상실. 다른 정부 사이트와 표식이 달라 사용자 혼란.
올바른 예: KRDS 표준 마크와 표준 문안을 그대로 사용. 진위 식별의 일관성 유지.

실수 5) 대비가 너무 낮아 안 보인다

배너를 "있긴 있되 거슬리지 않게" 한다고 연한 회색 배경에 연한 회색 글씨로 처리합니다.

나쁜 예: 흐릿한 회색 글씨. 저시력 사용자에게는 거의 보이지 않음. 사실상 없는 것과 마찬가지.
올바른 예: 문구와 배경의 명도 대비를 충분히 확보. 작아도 또렷하게.

실수 6) 포커스 표시를 지웠다

디자인 통일성을 위해 배너 내 버튼·링크의 포커스 링을 outline: none으로 제거합니다.

나쁜 예: 키보드로 페이지에 진입했을 때 첫 초점이 어디 있는지 안 보임.
올바른 예: 포커스 시 또렷한 외곽선 유지. 작은 영역이라도 포커스 표시는 살림.

실수 7) 코드엔 있는데 화면엔 안 뜬다

배너 마크업은 들어가 있는데, CSS 충돌이나 z-index 문제, 혹은 조건부 렌더링 오류로 실제 화면엔 안 보입니다.

나쁜 예: HTML 소스엔 공식 배너 코드가 있지만, 다른 요소에 가려지거나 height: 0으로 눌려 화면엔 안 보임. "코드엔 있으니 됐다"고 착각.
올바른 예: 실제 렌더링된 화면(스크린샷)에서 배너가 보이는지 확인. 코드 존재 ≠ 화면 표시임을 인식.

실수 8) 배너를 헤더와 뒤섞어 위치가 모호하다

공식 배너를 헤더 안에 끼워 넣거나 로고 옆에 붙여서, 어디까지가 공식 배너이고 어디부터가 헤더인지 모호해집니다.

나쁜 예: 공식 배너 문구가 헤더 메뉴 사이에 작게 섞여 들어가 식별이 안 됨.
올바른 예: 공식 배너는 헤더보다 위, 독립된 띠로 분리. 위치만 봐도 "이건 공식 식별 영역"임이 드러나게.

실수 9) 펼침 안내 내용이 비어 있거나 형식적이다

공식 배너를 펼쳤더니 정작 "공식 누리집 식별 방법" 안내가 없거나, 있어도 한 줄짜리 형식적 문구뿐인 경우입니다.

나쁜 예: 띠를 클릭하면 펼쳐지긴 하는데, "공식 누리집입니다"라는 같은 말만 반복. 정작 "주소가 go.kr로 끝나는지 확인하세요" 같은 실질적 식별 팁이 없음. 사용자가 진짜·가짜를 구분하는 데 아무 도움이 안 됨.
올바른 예: 펼침 영역에 사용자가 실제로 진위를 판별할 수 있는 구체적 안내를 담음. 공식 도메인 확인 방법, 보안 연결(자물쇠) 확인 방법 등. 공식 배너는 "선언"에서 끝나는 게 아니라 사용자에게 "판별법"을 쥐여 주는 교육 장치라는 점을 기억.

실수 10) 리뉴얼 과정에서 슬그머니 사라진다

가장 조용하고 가장 흔한 사고입니다. 사이트를 새 디자인으로 개편하면서, 새 템플릿에 공식 배너를 옮기는 걸 깜빡합니다. 아무도 맨 위 띠를 의식하지 않으니 출시 후에도 한참 모릅니다.

나쁜 예: 개편 전엔 있던 공식 배너가 새 템플릿엔 누락. QA에서 본문 기능만 확인하느라 발견 못 함. 몇 달간 배너 없이 운영.
올바른 예: 개편 체크리스트에 "공식 배너 전 페이지 적용 확인"을 못박고, 출시 직후 ViewCheck로 사이트 전체를 한 번 돌려 누락 여부를 기계적으로 검증. "사람이 안 보는 곳은 도구가 본다"는 원칙 적용.

한 장면 — 같은 링크, 두 사람

추상적인 요건보다 한 장면이 빠를 것 같습니다. 어느 날 두 사람이 같은 문자 메시지를 받습니다. "환급금 신청 마감 임박, 아래 링크에서 확인하세요." 링크를 누르니 정부 사이트처럼 생긴 화면이 뜹니다.

먼저 김 어르신. 화면이 그럴듯하니 의심 없이 주민번호를 입력하려다, 문득 평소 보던 그 띠가 없다는 걸 알아챕니다. "어, 진짜 정부 사이트면 맨 위에 '공식 누리집입니다'가 있어야 하는데?" 이 작은 위화감 덕분에 입력을 멈추고, 직접 검색해 진짜 사이트로 들어갑니다. 공식 배너가 일관되게 있었기에, 그게 없는 가짜를 의심할 수 있었던 겁니다.

이번엔 시각장애가 있는 박 선생님. 같은 가짜 사이트를 스크린리더로 듣습니다. 진짜 정부 사이트라면 진입 직후 "공식 전자정부 누리집입니다"가 가장 먼저 읽혔을 텐데, 이 가짜 사이트에선 아무 식별 안내 없이 바로 입력 폼이 읽힙니다. 박 선생님도 "어라, 공식 안내가 없네?" 하고 멈칫합니다. 단, 이게 가능하려면 진짜 사이트들이 공식 배너를 스크린리더로 읽히게 만들어 뒀어야 합니다. 만약 진짜 사이트들조차 배너를 이미지로만 박아 두고 대체 텍스트를 안 넣었다면, 박 선생님에겐 진짜든 가짜든 똑같이 "안내 없음"으로 들렸을 겁니다. 그러면 의심의 근거 자체가 사라지죠.

같은 가짜 링크, 두 사람. 둘 다 위기를 피할 수 있었던 건, 진짜 정부 사이트들이 공식 배너를 일관되게, 그리고 접근 가능하게 박아 뒀기 때문입니다. 우리 사이트의 공식 배너 하나가 누군가의 피싱 피해를 막는 마지막 방어선이 될 수 있다는 얘기입니다. 그리고 그게 제대로 박혀 있는지는, 사람이 매번 모든 페이지를 확인하기 어렵기 때문에 자동 점검이 필요합니다.

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

여기까지가 KRDS의 공식 배너 기준입니다. 그런데 정작 어려운 건 "그래서 우리 사이트엔 공식 배너가 모든 페이지에 제대로 박혀 있나?"를 확인하는 일입니다. 메인만 보면 안 되고, 하위 페이지·외부 연동 페이지·모바일 뷰까지 다 봐야 하는데, 페이지가 수십·수백 개인 공공 사이트에서 이걸 사람이 손으로 점검하면 하루가 모자랍니다.

ViewCheck 분석 화면

ViewCheck(krds.viewcheck.co.kr)는 이 점검을 자동화합니다. URL만 넣으면 페이지를 실제로 크롤링해서, 공식 배너를 포함한 컴포넌트들이 KRDS 기준을 지키는지 판정합니다. 공식 배너는 KRDS 846규칙 중 컴포넌트(CP) 규칙군 446개에 속하고, 분석 결과의 컴포넌트(Components) 탭에서 확인할 수 있습니다.

ViewCheck가 공식 배너에 대해 자동으로 보는 것들

존재 여부: 페이지 최상단에 공식 배너 영역이 있는지. 단순히 코드에 있는지가 아니라, 실제로 렌더링되는지까지.
위치: 헤더보다 위에 있는지, 코드 순서상 앞에 오는지.
다중 페이지 일관성: 메인뿐 아니라 분석한 모든 페이지에 동일하게 있는지. "메인엔 있는데 신청 페이지엔 없다" 같은 편차를 페이지별로 짚어 줍니다.
펼침/접힘 접근성: 펼침 버튼이 키보드로 조작 가능한지, aria-expanded 같은 상태 속성이 있는지.
접근 가능한 이름: 배너의 마크·버튼에 스크린리더가 읽을 이름이 있는지.
반응형: 모바일 뷰포트에서 배너가 유지되는지(반응형 품질 분석과 연계).

여기서 ViewCheck의 두 가지 강점이 공식 배너 점검에 딱 맞습니다.

첫째, 다중 페이지 분석입니다. 공식 배너는 "모든 페이지에 일관되게"가 핵심 요건이라, 단일 페이지만 보는 도구로는 가장 중요한 검증(일관성)을 할 수 없습니다. ViewCheck는 여러 페이지를 한꺼번에 분석해서 "어느 페이지에서 배너가 빠졌는지"를 목록으로 보여 줍니다.

둘째, KRDScan Vision AI 보강입니다. 공식 배너는 코드엔 있는데 화면엔 안 뜨거나, 반대로 이미지로만 박혀 코드 검사로는 놓치기 쉬운 경우가 있습니다. ViewCheck는 DOM 검사만으로 끝내지 않고, 스크린샷을 실제로 "보고" 화면에 배너가 표시되는지 시각적으로 보강 판정합니다. 사람이 눈으로 확인하듯 화면을 함께 보기 때문에, "코드 존재 ≠ 화면 표시"의 함정에 빠지지 않습니다.

리포트를 어떻게 읽나

분석이 끝나면 컴포넌트 탭에서 공식 배너 관련 규칙의 통과/미통과 수와, 미통과한 항목의 **위치(어느 페이지)·이유·개선 방법(howToFix)**이 함께 나옵니다. 예를 들어 "분석한 12개 페이지 중 9개에는 공식 배너가 있으나, 예약 페이지·문의 페이지·외부 연동 페이지 3개에는 없음"처럼 구체적으로요. 어디부터 고쳐야 하는지 우선순위(P0~P3)도 함께 매겨지니, 한정된 시간에 가장 중요한 것부터 손볼 수 있습니다.

무료 진단으로 우리 사이트 메인부터 한 번 돌려 보면, 손으로는 몇 시간 걸릴 점검이 몇 분 만에 끝납니다. 그리고 그 결과는 막연한 "배너 잘 챙기자"가 아니라, "이 3개 페이지에 공식 배너를 추가하자"는 구체적인 작업 목록이 됩니다.

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

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

개발자라면 — KRDS 컴포넌트 킷을 npm install krds-uiux로 설치하거나 CDN(krds.min.css / krds.min.js)으로 불러올 수 있습니다. 저장소(KRDS-uiux/krds-uiux)의 html/code 폴더에 공식 배너 마크업이 키보드 동작·ARIA 속성이 구현된 상태로 들어 있습니다. 핵심은 이 배너를 공통 레이아웃(전역 헤더 템플릿이나 레이아웃 컴포넌트)에 한 번만 넣어, 모든 페이지에 자동으로 적용되게 하는 것입니다. 페이지마다 따로 복붙하면 반드시 어딘가에서 빠집니다. "공통 레이아웃에 한 번"이 일관성을 지키는 가장 확실한 방법입니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 공식 배너 컴포넌트를 가져다 쓸 수 있습니다. 직접 그리지 말고 표준 컴포넌트를 배치하면, 표준 마크·문구·간격이 기준에 맞춰집니다. 특히 디자이너가 시안 단계에서 모든 화면 템플릿(메인/리스트/상세/폼) 상단에 공식 배너를 똑같이 배치해 두면, 개발 단계에서 빠질 위험이 줄어듭니다.

기획자라면 — 화면 정의서에서 "공통 헤더" 항목에 "공식 배너(KRDS Masthead) 포함, 전 페이지 적용"을 명시하세요. 그리고 외부 위탁 시스템이나 별도 예약·결제 페이지를 연동할 때 "해당 페이지에도 공식 배너 적용" 조건을 계약·요구사항에 넣어야 합니다. 이 한 줄이 "외부 페이지에서 배너 누락"이라는 가장 흔한 사고를 막습니다.

자주 묻는 질문

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

Q. 공식 배너랑 헤더(로고·메뉴)는 뭐가 다른가요? 위치와 역할이 다릅니다. 공식 배너는 화면 가장 꼭대기에 있는 "이건 진짜 공식 누리집입니다"라는 신뢰 표식이고, 헤더는 그 아래에 오는 기관 로고·주 메뉴·검색 영역입니다. 공식 배너의 마크는 모든 정부 사이트가 공유하는 공통 표식이고, 헤더의 로고는 각 기관 고유의 것입니다. 둘은 별개 컴포넌트라 따로따로 챙겨야 합니다. 공식 배너가 있다고 헤더가 면제되는 것도, 그 반대도 아닙니다.

Q. 메인 페이지에만 넣으면 안 되나요? 어차피 다들 메인으로 들어오잖아요. 이게 가장 위험한 착각입니다. 실제로는 검색엔진이나 외부 링크, 문자 메시지를 통해 메인이 아닌 깊숙한 내부 페이지로 바로 진입하는 사용자가 매우 많습니다. 특히 피싱 링크는 메인을 거치지 않고 곧장 입력 폼이 있는 페이지로 유도합니다. 그래서 공식 배너는 반드시 모든 페이지에 있어야 의미가 있습니다. 메인에만 있으면 정작 진위 확인이 가장 필요한 순간(내부 폼 페이지 진입)에 작동하지 않습니다.

Q. 디자인이 답답해 보여서 배너를 좀 작게, 흐리게 처리하고 싶은데요? 작게 만드는 것까지는 괜찮습니다. 하지만 "흐리게"는 곤란합니다. 공식 배너의 목적은 사용자가 진위를 확인하는 것인데, 흐려서 안 보이면 그 목적 자체가 무너집니다. 또 명도 대비가 낮으면 저시력 사용자는 아예 못 읽습니다. 작더라도 또렷하게, 라는 게 원칙입니다. "거슬리지 않게"와 "안 보이게"는 다릅니다.

Q. 우리 사이트는 외부 업체가 만든 예약 시스템을 쓰는데, 거기엔 공식 배너가 없어요. 그 외부 시스템 페이지도 사용자 눈에는 "우리 기관 서비스"입니다. 그래서 거기에도 공식 배너가 있어야 합니다. 위탁 계약 시 "공식 배너(KRDS Masthead) 적용"을 요구사항에 명시하는 게 가장 확실합니다. 이미 운영 중이라면, 외부 시스템 상단에 공통 헤더를 삽입하는 방식으로 적용할 수 있는지 업체와 협의하세요. ViewCheck로 사이트 전체를 분석하면 바로 이런 "외부 연동 페이지 배너 누락"이 목록으로 잡힙니다.

Q. 모바일에선 화면이 좁아서 배너를 숨겼는데, 문제가 되나요? 문제가 됩니다. 오히려 모바일이 더 중요합니다. 피싱·사칭 링크는 대부분 문자·메신저로 전달되고, 그걸 누르는 건 모바일입니다. 즉 진위 확인이 가장 필요한 환경이 모바일인데 거기서 배너를 빼면 본말이 전도됩니다. 공간이 부족하면 문구를 줄이거나 두 줄로 접는 식으로 대응하되, 존재 자체는 유지하세요.

Q. 코드에는 공식 배너가 분명히 있는데, ViewCheck에서 미통과로 나왔어요. 왜죠? "코드에 있다"와 "화면에 보인다"는 다릅니다. CSS 충돌, z-index 문제, 조건부 렌더링 오류, 다른 요소에 가려짐 등으로 코드는 있지만 실제 화면엔 안 뜨는 경우가 있습니다. ViewCheck는 코드만 보는 게 아니라 KRDScan Vision AI로 실제 렌더링된 스크린샷을 함께 확인하기 때문에, "코드엔 있는데 화면엔 없는" 상태를 잡아냅니다. 미통과로 나왔다면 실제 브라우저에서 그 페이지 맨 위에 배너가 보이는지 직접 확인해 보세요. 십중팔구 안 보일 겁니다.

Q. 공식 배너의 정확한 마크 이미지와 문구는 어디서 받나요? KRDS 공식 자료가 최종 기준입니다. 가이드라인 PDF(디지털 정부서비스 UI/UX 가이드라인, 2025.08판)와 컴포넌트 킷(GitHub KRDS-uiux/krds-uiux), 공식 Figma(@krds)에서 표준 마크와 문안, 코드를 확인할 수 있습니다. 임의로 비슷하게 만들지 말고 공식 자산을 그대로 가져다 쓰는 게 일관성과 진위 식별 기능을 지키는 길입니다.

Q. 이미 운영 중인 사이트인데, 전부 다시 손봐야 하나요? 전부 갈아엎을 필요는 없습니다. 먼저 ViewCheck로 사이트 전체를 분석해 "어느 페이지에 공식 배너가 빠졌는지"를 목록으로 만든 다음, 빠진 페이지부터 채우면 됩니다. 공식 배너는 보통 공통 레이아웃에 한 번 넣으면 대부분의 페이지에 일괄 적용되므로, 의외로 적은 작업으로 큰 효과를 볼 수 있습니다. 외부 연동 페이지처럼 공통 레이아웃이 안 닿는 곳만 개별 처리하면 됩니다.

Q. 공식 배너를 펼침 없이 그냥 한 줄 텍스트로만 둬도 되나요? "공식 누리집입니다"라는 선언만 한 줄 두는 것도 안 두는 것보다는 낫습니다. 다만 KRDS 패턴이 펼침/접힘으로 식별 안내까지 담는 데에는 이유가 있습니다 — 사용자에게 "진짜·가짜를 직접 구분하는 법"을 알려 주기 위해서죠. 단순 선언은 "내가 진짜다"라고 말하는 것뿐이고(가짜도 똑같이 말할 수 있죠), 식별 안내는 "이렇게 확인해 보라"고 판별법을 주는 것입니다. 후자가 훨씬 강력합니다. 가능하면 표준 패턴대로 펼침 안내를 갖추되, 그게 어렵다면 최소한 표준 마크와 문구라도 정확히 두세요.

Q. 단일 페이지짜리 간단한 안내 사이트인데도 공식 배너가 필요한가요? 페이지가 하나든 백 개든, 그게 전자정부 누리집이라면 공식 배너는 있어야 합니다. 오히려 단순한 안내 사이트일수록 사칭 사기에 악용되기 쉽습니다(만들기 쉬우니까요). 한 페이지짜리라도 사용자는 "이게 진짜 정부 사이트인가"를 확인하고 싶어 하고, 공식 배너가 그 확인을 가능하게 합니다. 규모와 무관하게 적용하세요.

Q. ViewCheck 컴포넌트 탭에서 공식 배너만 따로 보고 싶은데요? 컴포넌트(Components) 탭은 KRDS 846규칙 중 컴포넌트(CP) 규칙군 446개의 판정 결과를 보여 줍니다. 그 안에서 공식 배너 관련 규칙을 찾아, 통과/미통과 수와 페이지별 위치를 확인할 수 있습니다. 여러 페이지를 분석했다면 "어느 페이지에서 통과하고 어느 페이지에서 미통과인지"가 함께 표시되므로, 일관성 점검이 특히 쉽습니다. 미통과 항목에는 이유와 개선 방법(howToFix), 우선순위(P0~P3)가 같이 붙어 나옵니다.

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

ViewCheck로 돌려 보면 공식 배너 관련 문제가 한 가지로 끝나지 않는 경우가 많습니다. 페이지가 많을수록 "어디부터 손대야 하나" 고민이 됩니다. 공식 배너 문제를 심각도 순으로 정리하면 대략 이렇습니다.

가장 먼저(치명적) — 입력·신청·로그인처럼 개인정보를 다루는 핵심 경로 페이지에서 공식 배너가 아예 없는 경우. 진위 확인이 가장 필요한 곳에 신뢰 표식이 없는 것이라 1순위입니다. 외부 연동 예약·결제·민원 페이지가 여기 해당하는 경우가 많습니다.

그다음(높음) — 공식 배너는 있으나 스크린리더로 안 읽히거나 펼침 버튼이 키보드로 작동하지 않는 경우. 작동은 하는 것처럼 보여도 음성·키보드 사용자에게는 진위 확인 기능이 차단된 상태입니다. 모바일에서만 배너가 숨겨진 경우도 여기 포함됩니다(피싱 노출이 큰 환경이므로).

그 후(보통) — 배너는 있고 읽히기도 하지만, 대비가 낮아 흐릿하거나 포커스 표시가 없는 경우. 사용은 가능하지만 저시력·키보드 사용자에게 불편을 주는 문제입니다.

여력이 되면(낮음) — 위치가 헤더와 섞여 모호하거나, 펼침 안내 문구가 빈약한 경우. 신뢰 기능을 막는 건 아니지만 경험을 한 단계 끌어올리는 항목입니다.

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

5분 자가진단 실전 순서 — 지금 바로 해 보기

이 글의 앵글이 "점검"인 만큼, 도구 없이 손으로 5분 안에 끝내는 실전 순서를 정리해 둡니다. 그다음 ViewCheck로 사이트 전체를 자동 확인하면 됩니다.

1단계(30초) — 메인 페이지 맨 위 확인. 우리 사이트 메인을 열고 화면 가장 꼭대기를 봅니다. "공식 전자정부 누리집입니다" 같은 띠가 헤더(로고·메뉴)보다 위에 있나요? 없으면 여기서 이미 1순위 문제입니다.

2단계(1분) — 내부 페이지 3~4개 확인. 메인에서 신청·로그인·검색·문의 페이지로 각각 들어가 봅니다. 그리고 외부에서 들어오는 시뮬레이션으로, 그 내부 페이지 URL을 새 탭에 직접 붙여 넣어 메인을 거치지 않고 진입해 봅니다. 각 페이지 맨 위에도 공식 배너가 똑같이 있나요? 한 곳이라도 없으면 일관성 위반입니다.

3단계(1분) — 키보드 점검. 마우스를 치우고 Tab 키만으로 페이지에 진입해 봅니다. 첫 초점이 어디에 가는지 보이나요(포커스 표시)? 공식 배너에 펼침 버튼이 있다면 Enter나 Space로 펼쳐지고 접히나요? 마우스로만 되고 키보드로 안 되면 접근성 위반입니다.

4단계(1분) — 모바일 확인. 브라우저 개발자 도구의 모바일 보기로 전환하거나 실제 폰으로 같은 페이지를 엽니다. 모바일에서도 공식 배너가 보이나요? 데스크톱엔 있는데 모바일에서 사라졌다면 위반입니다.

5단계(30초) — 대비 확인. 공식 배너 문구가 또렷하게 읽히나요, 아니면 배경에 묻혀 흐릿한가요? 한 발 떨어져서 봐도 글씨가 보여야 합니다.

이 다섯 단계를 손으로 해 보면 "우리 사이트가 대략 어떤 상태인지" 감이 옵니다. 다만 손 점검의 한계는 분명합니다 — 페이지가 수십·수백 개면 전부 못 봅니다. 그래서 손으로 메인만 빠르게 확인한 뒤, 사이트 전체의 일관성은 ViewCheck로 한 번에 돌리는 게 정답입니다. 손 점검은 "감 잡기", 자동 점검은 "전수 검사"라고 생각하시면 됩니다.

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

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

KRDS 가이드라인 PDF(디지털 정부서비스 UI/UX 가이드라인, 2025.08판) — 공식 배너의 정의와 사용 원칙의 1차 원천.
KRDS 컴포넌트 문서(웹) — 공식 배너(Masthead)의 예시와 설명을 화면으로 확인.
KRDS 컴포넌트 킷(GitHub KRDS-uiux/krds-uiux) — html/code 폴더의 공식 배너 마크업을 그대로 가져다 사용(npm install krds-uiux 또는 CDN).
KRDS 공식 Figma(@krds) — 디자이너용 공식 배너 컴포넌트.

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

오늘의 체크리스트 — 공식 배너, 이것만은

마지막으로, 디자이너·개발자·기획자가 공식 배너를 만들거나 검수할 때 바로 쓸 수 있는 체크리스트로 정리합니다. 이걸 그대로 들고 우리 사이트를 5분만 훑어보세요.

화면 맨 위, 헤더보다 위에 공식 배너가 있다.
메인뿐 아니라 모든 페이지(리스트/상세/신청/로그인/외부 연동)에 동일하게 있다.
KRDS 표준 마크와 문구를 쓴다(기관 인사말로 대체하지 않았다).
펼침/접힘 버튼이 키보드만으로 작동한다(Enter/Space).
펼침 상태가 코드로 전달된다(aria-expanded), 펼침 내용과 연결(aria-controls)돼 있다.
배너의 마크·버튼에 스크린리더가 읽을 이름이 있다.
포커스 표시가 또렷하다(outline: none으로 지우지 않았다).
문구와 배경의 명도 대비가 충분하다(흐릿하지 않다).
모바일에서도 배너가 유지된다(좁다고 숨기지 않았다).
코드뿐 아니라 실제 화면에 배너가 보인다(렌더링 확인).
외부 위탁·별도 시스템 페이지에도 배너가 적용돼 있다.

KRDS 컴포넌트 킷(npm install krds-uiux 또는 CDN)을 공통 레이아웃에 한 번 넣으면 위 항목 대부분이 이미 구현된 상태로, 그리고 모든 페이지에 일괄 적용된 상태로 시작할 수 있습니다. 직접 페이지마다 넣다가 빠뜨릴 위험을 줄이는 가장 확실한 방법이죠. 공식 Figma 라이브러리(@krds)에서는 디자이너가 표준 공식 배너 컴포넌트를 그대로 가져다 쓸 수 있습니다.

공식 배너는 작아 보이지만, 공공 서비스에서 사용자가 처음 마주치는 "이건 진짜다"라는 약속입니다. 그 약속이 어떤 페이지에선 지켜지고 어떤 페이지에선 깨지면, 사용자는 더 이상 그 약속을 믿지 못하게 됩니다. 우리가 무심코 넘긴 맨 위의 띠 하나가, 누군가에게는 피싱 사기를 멈춰 세우는 마지막 신호일 수 있습니다.

오늘 정리한 기준이 많아 보일 수 있지만, 핵심은 결국 단순합니다. 모든 페이지 맨 위에, 표준 마크와 문구로, 키보드·스크린리더로도 읽히게, 모바일에서도 또렷하게 — 이 네 가지만 챙기면 공식 배너의 위반 대부분은 사라집니다. 그리고 그게 모든 페이지에서 잘 지켜지고 있는지는, 사람 눈으로는 몇 시간 걸릴 일을 ViewCheck로 5분이면 확인할 수 있습니다. 완벽을 한 번에 만들 필요는 없습니다. 배너가 빠진 페이지 하나부터 채워 나가면, 우리 사이트는 분명히 조금씩 더 믿을 수 있는 곳이 됩니다. 다음 글에서는 공식 배너 바로 아래에 오는 또 다른 핵심 영역을 같은 방식으로 뜯어보겠습니다.

우리 사이트의 공식 배너는 모든 페이지에 제대로 박혀 있을까요? krds.viewcheck.co.kr에서 URL만 넣으면 무료로 확인할 수 있습니다. 메인뿐 아니라 여러 페이지를 한꺼번에 돌려 보면, 위 체크리스트가 실제로 지켜지고 있는지, 어느 페이지에서 배너가 빠졌는지 한눈에 보입니다.

#KRDS #공식배너Masthead #공공웹 #디자인시스템 #웹접근성 #피싱방지 #전자정부 #정부웹사이트 #ViewCheck #UIUX #신뢰성

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

043편 : 레디어스를 컴포넌트의 사이즈 기준 5단계로 구성하고 있다.

ViewCheck — Fri, 25 Sep 2026 14:00:08 +0900

043편 : 레디어스를 컴포넌트의 사이즈 기준 5단계로 구성하고 있다.

KRDS 체크리스트 항목 DS-043 · 디자인 스타일 > 형태 〈846 규칙 완전 분해 시리즈 ㊸〉 — "모서리의 둥글기에도 체계가 있다": 레디어스 5단계

0. 들어가며 — 디자인 스타일의 세 번째 축, '형태'

색상(26편)과 타이포그래피(16편)를 마치고, 이번엔 디자인 스타일의 세 번째 분류 — 형태(Shape) 입니다. 그 첫 주제는 레디어스(radius), 즉 모서리의 둥글기입니다.

버튼, 카드, 입력칸… 화면의 거의 모든 요소에는 모서리가 있고, 그 모서리는 각지거나 둥글게 처리됩니다. 이 둥글기를 레디어스(border-radius) 라 부르죠. 사소해 보이지만, 레디어스는 화면의 인상을 크게 좌우 합니다. 각진 모서리는 단단하고 격식 있는 느낌을, 둥근 모서리는 부드럽고 친근한 느낌을 줍니다.

DS-043은 이 레디어스를 컴포넌트 크기 기준 5단계로 구성하라고 규정합니다. 색을 팔레트 단계로(4편), 투명도를 5단계로(10편) 관리했듯, 둥글기도 단계로 체계화하라는 것이죠. 이번 편은 레디어스를 왜 단계로 관리해야 하는지, 그 체계가 어떻게 일관된 화면을 만드는지를 풀어냅니다.

1. 규칙 원문 — 5단계 체계

DS-043 (디자인 스타일 > 형태) "레디어스를 컴포넌트의 사이즈 기준 5단계로 구성하고 있다."

"레디어스"

모서리의 둥글기입니다. CSS의 border-radius에 해당하죠. 값이 클수록 더 둥글어집니다.

"컴포넌트의 사이즈 기준 5단계"

레디어스를 컴포넌트 크기에 따라 5단계로 정의한다는 뜻입니다. 작은 컴포넌트는 작은 레디어스, 큰 컴포넌트는 큰 레디어스처럼, 크기에 맞는 둥글기를 5개 단계로 체계화하는 것이죠.

정리: 모서리 둥글기(레디어스)를 컴포넌트 크기 기준 5단계로 체계화하라. 이게 DS-043입니다.

2. 왜 레디어스를 단계로 관리하나

레디어스를 그때그때 감각으로 정하면 어떻게 될까요? 색·투명도에서 본 것과 같은 문제가 생깁니다.

요소마다 둥글기가 제각각이면(이 버튼은 4px, 저 버튼은 6px, 이 카드는 10px, 저 카드는 8px) 화면이 미묘하게 산만해집니다. 사람 눈은 이런 미세한 불일치를 무의식적으로 감지하죠. 같은 종류의 요소인데 둥글기가 다르면 '정돈되지 않은' 인상을 줍니다. 반대로 레디어스가 단계로 정리되면, 같은 종류 요소는 같은 둥글기를 갖고, 화면 전체가 일관된 형태감을 갖습니다.

또한 단계로 관리하면 유지보수가 쉽습니다. "버튼을 좀 더 둥글게"라는 결정도, 단계 정의를 바꾸면 모든 버튼에 일관되게 적용되죠. 레디어스 값이 화면 곳곳에 흩어져 있으면 이런 일괄 조정이 불가능합니다. 이는 색을 팔레트로(DS-001), 투명도를 5단계로(DS-010) 관리하는 것과 정확히 같은 '체계화'의 이점입니다.

KRDS가 디자인의 거의 모든 속성(색·명도·투명도·크기·둥글기)을 '단계로 관리'하는 데는 일관된 철학이 있습니다 — 감각으로 무한한 값을 쓰지 말고, 정해진 유한한 단계에서 골라 쓰라. 그래야 일관되고, 예측 가능하고, 관리할 수 있습니다. 레디어스 5단계도 이 철학의 한 적용입니다.

3. '컴포넌트 크기 기준'이라는 핵심

DS-043의 묘미는 단계를 '컴포넌트 크기 기준' 으로 나눈다는 데 있습니다. 왜 크기를 기준으로 할까요?

레디어스는 컴포넌트 크기에 비례해야 자연스럽기 때문입니다. 작은 버튼에 큰 레디어스를 주면 모서리가 과하게 둥글어 형태가 일그러지고, 큰 카드에 작은 레디어스를 주면 둥글기가 거의 안 보여 효과가 없습니다. 즉 같은 레디어스 값이라도 컴포넌트 크기에 따라 다르게 느껴집니다.

그래서 KRDS는 레디어스를 컴포넌트 크기에 맞춰 5단계로 정의합니다 — 작은 요소(태그·배지 등)는 작은 단계, 중간 요소(버튼·입력칸)는 중간 단계, 큰 요소(카드·모달)는 큰 단계. 이렇게 하면 모든 컴포넌트가 자기 크기에 어울리는 둥글기를 갖고, 화면 전체의 둥글기 비례가 조화로워집니다. 큰 것은 적당히 더 둥글고, 작은 것은 적당히 덜 둥글게요.

이는 18편(고도)에서 본 '요소에 맞는 단계 선택'과 통합니다. 단계는 그냥 다섯 개가 아니라, '어느 크기의 컴포넌트에 어느 단계'라는 매핑까지 포함합니다. 그래야 단계가 실무에서 '골라 쓰는 도구'로 작동하죠.

4. 레디어스가 만드는 인상 — 형태의 언어

레디어스는 단순한 장식이 아니라 화면의 인상과 성격을 만듭니다.

각진 모서리(레디어스 0)는 단단하고, 격식 있고, 전통적인 느낌을 줍니다. 반면 둥근 모서리는 부드럽고, 친근하고, 현대적인 느낌을 주죠. 둥글기의 정도에 따라 화면의 성격이 달라집니다. 살짝 둥근 모서리는 정돈된 안정감을, 많이 둥근 모서리는 캐주얼하고 친근한 느낌을 줍니다.

정부 서비스는 신뢰감과 친근함의 균형이 필요합니다. 너무 각지면 딱딱하고 권위적으로, 너무 둥글면 가볍게 보일 수 있죠. 그래서 적정한 레디어스(다음 편들에서 2~12px 범위로 다룸)로 '신뢰감 있되 친근한' 인상을 만드는 것이 중요합니다. 그리고 그 둥글기가 5단계로 일관되게 적용되어야, 화면 전체가 통일된 성격을 갖습니다. 레디어스의 일관성은 곧 '형태의 목소리'를 하나로 만드는 일입니다.

5. 흔한 위반 패턴 / 점검 / 개선

흔한 위반 패턴

함정 ① 제각각 레디어스. 요소마다 둥글기가 다름 → 산만, 부조화. → 5단계로 체계화. 함정 ② 크기 무시. 작은 버튼에 큰 레디어스, 큰 카드에 작은 레디어스 → 비례 부자연. → 크기 기준 단계. 함정 ③ 단계 미정의. 레디어스를 감각으로 → 일관성 붕괴. → 토큰으로 5단계 정의. 함정 ④ 혼재. 같은 종류 요소가 다른 둥글기 → 정돈 안 됨. → 동일 종류 동일 단계(DS-047).

무엇을 점검하나

단계 구성 — 레디어스가 5단계로 정의됐는가.
크기 매핑 — 컴포넌트 크기에 맞는 단계가 적용됐는가.
일관성 — 같은 종류 요소가 같은 레디어스인가.
토큰화 — 레디어스가 토큰으로 관리되는가.

Before / After

/* ❌ Before: 제각각 레디어스 */
.btn-a { border-radius: 4px; }
.btn-b { border-radius: 6px; }   /* 같은 버튼인데 다름 */
.card { border-radius: 10px; }

/* ✅ After: 크기 기준 5단계 토큰 */
:root {
  --radius-1: 2px;   /* 아주 작은 요소 */
  --radius-2: 4px;   /* 작은 요소(태그 등) */
  --radius-3: 8px;   /* 중간(버튼·입력칸) */
  --radius-4: 12px;  /* 큰 요소(카드) */
  --radius-5: 16px;  /* 가장 큰 요소 (값은 KRDS 토큰 기준) */
}
.btn { border-radius: var(--radius-3); }
.card { border-radius: var(--radius-4); }

6. 누가 담당하나 / 우리 사이트에 해당될까?

역할	책임
디자인 시스템 담당 / 디자이너	레디어스 5단계와 크기별 매핑 설계
퍼블리셔/개발	레디어스를 토큰으로 구현

기관 유형	DS-043 적용
중앙행정기관(대표·운영) / 공공기관 / 지자체	✅ 필수

모서리가 있는 컴포넌트(버튼·카드·입력칸 등)가 있는 모든 사이트 = 해당. KRDS 토큰을 채택하면 레디어스 단계가 이미 정의돼 있습니다.

7. 30초 자가진단 + FAQ

✅ 30초 자가진단

□ 레디어스가 5단계로 정의돼 있나요?
□ 컴포넌트 크기에 맞는 둥글기가 적용됐나요?
□ 같은 종류 요소가 같은 레디어스인가요?
□ 레디어스가 토큰으로 관리되나요?
□ 요소마다 둥글기가 제각각이지 않나요?

❓ FAQ

Q1. 왜 5단계인가요? 컴포넌트 크기 범위(아주 작은 것~큰 것)를 적절히 커버하는 단계 수입니다. 너무 적으면 크기별 대응이 부족하고, 너무 많으면 관리가 복잡합니다. 5단계가 실용적 균형점입니다(투명도 5단계와 유사한 발상).

Q2. 정확한 단계 값은 어디서 받나요? KRDS 디자인 토큰에 레디어스 단계 값이 정의돼 있습니다. 다음 편들에서 그 범위(2~12px)와 규칙을 다룹니다.

Q3. 모서리를 다 각지게(레디어스 0) 하면 안 되나요? 완전히 각지면 딱딱한 인상을 줍니다. KRDS는 적정 레디어스로 친근함과 신뢰감의 균형을 권합니다. 다만 일부러 각진 스타일을 의도한다면 일관되게 적용해야 합니다.

Q4. 컴포넌트마다 다른 단계를 써도 되나요? 크기가 다르면 다른 단계가 맞습니다. 단, 같은 종류·비슷한 크기 요소는 같은 단계여야 합니다(DS-047). '크기에 맞는 단계'가 핵심입니다.

Q5. KRDS를 채택하면 자동인가요? KRDS는 레디어스 5단계를 토큰으로 정의하고 컴포넌트별로 적용해 둡니다. 채택하면 DS-043이 충족됩니다.

8. 마무리 — 둥글기에도 질서를

DS-043의 메시지는 체계화의 원리를 형태에 적용합니다.

모서리의 둥글기도 감각이 아니라 체계다 — 컴포넌트 크기에 맞는 5단계로 일관되게.

레디어스를 단계로 관리하면, 같은 종류 요소가 같은 둥글기를 갖고, 컴포넌트 크기에 어울리는 둥글기가 적용되어 화면 전체가 일관된 형태감을 갖습니다. 이는 색·명도·투명도를 단계로 관리한 것과 같은, '감각을 체계로 대체 한다'는 디자인 시스템의 일관된 철학입니다. 사소해 보이는 둥글기에도 질서를 부여하는 것 — 그 질서가 정돈된 화면의 인상을 만듭니다.

다음 편은 이 레디어스의 구체적 값 범위를 다룹니다. DS-044 — "2px~12px의 래디어스 값을 사용한다." 둥글기의 적정 범위와, 왜 그 범위인지를 살펴봅니다.

다음 편 예고 ▶ 「044. 2px~12px의 래디어스 값을 사용하고 있다.」

우리 사이트의 레디어스가 체계적인지 확인하려면? ViewCheck는 레디어스가 5단계로 정의됐는지, 컴포넌트 크기에 맞게 적용됐는지, 같은 종류 요소가 일관된 둥글기인지를 진단합니다.

참고 출처

KRDS 형태(Shape)·스타일 가이드 — https://www.krds.go.kr/html/site/style/style_03.html
KRDS 디자인 토큰 가이드 — https://www.krds.go.kr/html/site/style/style_07.html

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

다섯 특허 ↔ 세 방법, 한 장으로 보는 지도 — 1개월차 마무리

ViewCheck — Fri, 25 Sep 2026 12:01:01 +0900

다섯 특허 ↔ 세 방법, 한 장으로 보는 지도 — 1개월차 마무리

들어가며 — 오리엔테이션의 마지막, 한 장 지도

오늘이 1개월차, 그러니까 오리엔테이션의 마지막 글입니다. 한 달 동안 꽤 많은 것을 깔아두었습니다. 처음엔 "왜 사람 손만으로는 웹 품질 점검이 버거운지"를 이야기했고, 그다음엔 "웹 품질을 보는 세 시점 — 설계·운영·판단"이라는 큰 틀을 세웠습니다. 이어서 그 세 시점을 하나씩, 운영 시점의 URL 분석과 설계 시점의 Figma 분석, 그리고 판단 시점의 LLM 분석으로 풀어드렸지요. 이번 주 월요일과 수요일에는 "그 방법들을 받치는 다섯 건의 특허"가 왜 필요했고, 기능은 베껴도 방법은 왜 못 베끼는지를 짚었습니다.

오늘은 이 모든 것을 한 장으로 묶습니다. "다섯 개의 특허가 세 개의 방법에 어떻게 걸치는지"를 그린 매핑 지도입니다. 이 지도가 왜 중요하냐면, 앞으로 다음 달부터 펼칠 심층편들의 목차이기 때문입니다. "아, 이 특허가 이 방법을 받치는 것이었구나" 하고 전체 그림이 한 번 잡히면, 다음 달부터 이어질 영역별 깊은 이야기를 따라가기가 훨씬 수월해집니다. 오리엔테이션이라는 한 달의 목적이 바로 여기에 있습니다. 깊이 파고들기 전에, 전체 지도를 먼저 손에 쥐어드리는 것이지요.

사실 지도라는 것이 원래 그렇습니다. 낯선 도시를 걸을 때, 골목 하나하나를 다 외우고 나서야 길을 나서는 사람은 없습니다. 전체 지형을 한 번 훑어 "여기가 중심이고, 저쪽이 강이며, 이 길이 저 광장으로 이어지는구나" 정도만 잡아두면, 막상 걸을 때 헤매지 않습니다. 오늘 그리는 지도도 그런 쓰임입니다. 다섯 특허와 세 방법의 세부를 지금 다 이해하실 필요는 없습니다. "무엇이 어디에 걸치는지"라는 큰 지형만 눈에 담으시면, 다음 달부터 각 골목을 걸을 때 길을 잃지 않습니다. 그래서 오늘 글은 정보를 빽빽이 채우기보다, 이미 본 것들의 관계를 느슨하게 이어드리는 데 목적이 있습니다.

미리 말씀드리면, 오늘 글은 새로운 사실을 소개하는 자리가 아닙니다. 한 달 동안 나눠서 본 조각들 — 세 시점, 세 방법, 다섯 특허 — 을 한 표 위에 나란히 놓고, 서로 어떻게 맞물리는지 잇는 자리입니다. 그래서 오늘은 편하게 읽으셔도 됩니다. 외울 것도 없습니다. "이 특허가 저 방법에 걸치는구나" 하는 큰 그림만 눈에 익히시면, 다음 달부터의 글들이 "아, 이게 그 표의 이 칸 이야기였구나" 하고 저절로 자리를 잡습니다.

아래는 그 세 방법이 결국 모여 한 화면의 846규칙 결과로 집계된 모습입니다. 오늘 그릴 지도의 "종착점"이라고 보시면 됩니다. 다섯 특허와 세 방법이 결국 이 한 화면의 결과로 모입니다. 화면 상단엔 전체 준수율과 네 카테고리(디자인 스타일·컴포넌트·기본 패턴·서비스 패턴)의 요약이 있고, 그 아래로 규칙 하나하나의 판정이 이어집니다. 오늘 이야기가 어디로 향하는지, 이 그림을 먼저 마음에 담아두고 시작하겠습니다.

URL 하나로 분석한 846규칙 전체 집계 종합 화면. 상단 요약 점수 카드와 그 아래 규칙별 판정이 이어지는, 다섯 특허와 세 방법이 결국 모이는 종착점 (기관명·도메인 블러)

본론 1 — 다섯 특허, 한 줄씩 다시 보기

먼저 이번 주에 본 다섯 건을 한 줄씩 다시 짚겠습니다. 다섯 건 모두 현재 출원 중인 기술입니다. 등록특허가 아니라 출원 기술이라는 점을 먼저 정확히 해두겠습니다. 오늘 이야기는 "이미 확정된 권리를 자랑하는" 자리가 아니라, "이런 방법들을 직접 만들어 권리로 정리해 두려 한다"는 이야기에 가깝습니다.

① 시점 비교(설계·운영 교차 검증) — 만들기 전의 설계 도면과 운영 중인 실제 화면을, 같은 기준으로 견주어 보는 방법입니다. 설계 시점(Figma)과 운영 시점(URL)이라는 두 시점을 하나의 잣대 위에 올려 교차로 확인합니다. "도면에선 맞았는데 운영에선 어긋난 곳"이 이 비교에서 드러납니다.
② 기준 자동 판정(846규칙) — 화면이나 도면의 요소가 KRDS 기준에 맞는지, 846개 규칙으로 자동 대조하는 방법입니다. 846규칙은 디자인 스타일(DS) 120개, 컴포넌트(CP) 446개, 기본 패턴(BP) 108개, 서비스 패턴(SP) 172개로 나뉩니다. 준수율이라는 숫자가 결국 이 판정에서 나옵니다.
③ 렌더링 기반 화면 수집·측정 — 운영 중인 사이트를 실제로 브라우저에 띄워, 화면을 그대로 수집하고 측정하는 방법입니다. 스크린샷을 뜨고, 화면에 계산된 색·간격·크기를 실제로 재는 것이지요. 정적인 코드만 훑는 것이 아니라, "실제로 그려진 그 화면"을 다룹니다.
④ 위반 위험도 등급화 및 개선 우선순위 산정 — 발견된 위반 수백 건에 위험도를 매겨 P0부터 P3까지 등급을 나누고, "무엇부터 고칠지"의 순서를 만드는 방법입니다. 긴 목록을 "오늘 고칠 다섯 개"로 좁혀주는 자리이기도 합니다.
⑤ 코드·화면 결합 판정(DOM·Vision 융합) — 코드로 읽는 판정과 화면으로 보는 판정을 결합하는 방법입니다. 코드(DOM)로 확인 가능한 부분은 코드로 보고, 코드만으로는 판단이 어려운 시각적 영역은 화면(Vision)으로 봅니다. 두 방식이 서로의 빈칸을 메웁니다.

이 다섯을 관통하는 감각이 하나 있습니다. 전부 "사람이 눈으로 하나하나 따지던 일을, 같은 잣대로 자동화한 방법"이라는 점입니다. 색이 규정에 맞는지, 버튼에 라벨이 있는지, 이 위반이 저 위반보다 급한지 — 원래는 숙련된 사람이 오래 들여다봐야 겨우 판단하던 것들입니다. 그것을 매번 같은 기준으로, 재현 가능하게 자동으로 내주는 절차, 그 절차가 다섯 특허의 공통 뿌리입니다.

그리고 한 가지 더 짚어둘 것이 있습니다. 위반을 찾는 데서 끝내지 않고 "어떻게 고치라"는 개선안까지 글로 정리해 주는 기능이 있는데(지난 판단 시점 편에서 본 그 개선안입니다), 이것은 위 다섯 방법 중 판단 영역이 실제로 내주는 산출물에 해당합니다. 오늘은 개선안을 별도의 여섯 번째 방법으로 세지 않고, 다섯 방법이 만들어낸 결과 위에 얹히는 실용적 출력으로만 다루겠습니다. 방법은 다섯, 개선안은 그 다섯이 협력해 내주는 결과물, 이렇게 정리하는 편이 정확합니다.

본론 2 — 세 방법, 세 시점을 다시 세워두기

다섯 특허를 어디에 걸칠지 이야기하려면, 걸칠 자리인 "세 방법"을 먼저 다시 세워두어야 합니다. 이 세 방법은 한 달 내내 이야기한 세 시점과 그대로 짝을 이룹니다.

URL 분석 = 운영 시점 — 실제로 서비스 중인 사이트에 주소를 넣고, 사람들이 지금 쓰고 있는 그 화면을 통째로 점검하는 방법입니다. "지금 이 순간의 사이트"를 보는 자리입니다.
Figma 분석 = 설계 시점 — 아직 코드로 만들기 전, 디자인 도면 단계에서 미리 점검하는 방법입니다. "만들기 전에 잡는다"는 자리이지요.
LLM 분석 = 판단 시점 — 규칙만으로 다 채우지 못한 빈칸을 메우고, 흩어진 위반을 해석해 우선순위와 개선안으로 잇는 방법입니다. "그래서 무엇부터 어떻게"를 잡아주는 자리입니다.

이 세 방법의 관계를 한 문장으로 줄이면 이렇습니다. 설계 시점에서 미리 잡고, 운영 시점에서 현실을 확인하고, 판단 시점에서 결론을 내립니다. 시간 순서로 보면 설계 → 운영이고, 그 둘 위에 판단이 얹히는 구조입니다. 세 시점이 서로 다른 순간의 사이트를 보기 때문에, 셋을 합쳐야 비로소 사이트의 전 생애가 한눈에 들어옵니다. 하나만 보면 반쪽입니다. 설계만 보면 "도면은 좋았는데 실제로 어떻게 나왔는지"를 모르고, 운영만 보면 "왜 그렇게 만들어졌는지"의 원류를 놓칩니다.

그래서 오늘 지도의 핵심은 단순합니다. 다섯 개의 특허가 이 세 방법 위에 어떻게 배치되는가. 어떤 특허는 한 방법에만 깊게 걸리고, 어떤 특허는 두세 방법에 두루 걸칩니다. 한 특허가 여러 방법을 받치기도 하고, 한 방법이 여러 특허로 받쳐지기도 합니다. 이 유연한 배치가 바로 "다섯 개로 나눠 낸" 이유와도 이어집니다. 독립된 기술 단위로 정리해 두었기 때문에, 여러 자리에 자유롭게 걸칠 수 있는 것입니다. 하나의 큰 덩어리로 뭉쳐두었다면 이런 유연한 배치는 나오지 않았을 것입니다.

다섯 특허 자물쇠가 URL·Figma·LLM 세 방법 기둥에 선으로 이어지고, 일부 특허는 여러 기둥에 동시에 걸치는 한 장의 연결 지도. 한 특허가 여러 방법을 받치고 한 방법이 여러 특허로 받쳐지는 구조를 담은 개념 도식 (Gemini 1:1)

이 지도를 읽는 방법을 미리 귀띔해 드리면 두 가지 방향이 있습니다. 세로로 읽으면 "각 방법에 무슨 특허가 걸치나"가 보이고, 가로로 읽으면 "각 특허가 어느 방법을 받치나"가 보입니다. 세로 방향은 "URL 분석 하나를 돌릴 때 어떤 방법들이 함께 작동하는가"를 알려주고, 가로 방향은 "이 특허 하나가 여러 시점에서 어떻게 쓰이는가"를 알려줍니다. 아래에서 방법별로 하나씩 훑은 뒤, 마지막에 이 둘을 한 표로 겹쳐 보겠습니다.

본론 3 — URL 분석(운영 시점)에 걸치는 특허

먼저 운영 시점, URL 분석입니다. 실제로 서비스 중인 사이트에 주소를 넣고 통째로 점검하는 방법이지요. 세 방법 중 가장 종합적인 자리이고, 그만큼 다섯 특허 중 가장 많은 넷이 여기에 걸칩니다.

③ 렌더링 기반 화면 수집·측정이 URL 분석의 토대입니다. 운영 사이트를 실제 브라우저에 띄워 화면을 그대로 수집하고, 화면에 계산된 색·간격·크기를 실제로 재는 것에서 모든 것이 시작됩니다. 정적인 파일만 훑는 것과, 실제로 그려진 화면을 재는 것은 전혀 다릅니다. 운영 시점 편에서 강조했듯, 스테이징에선 멀쩡한데 운영에선 깨지는 일이 흔한데, 그런 어긋남은 오직 "실제로 그려진 화면"을 재야 잡힙니다. 그래서 이 렌더링 기반 수집·측정이 URL 분석의 출발점이자 뼈대입니다.

**② 기준 자동 판정(846규칙)**이 그 위에서 판정을 내립니다. 수집한 화면의 요소가 KRDS 846규칙에 맞는지 자동으로 대조하는 것이지요. 디자인 스타일 120개, 컴포넌트 446개, 기본 패턴 108개, 서비스 패턴 172개, 도합 846개의 규칙이 한 번의 분석에서 순차로 돌아갑니다. 준수율이라는 숫자가 여기서 나오고, 어느 규칙에서 왜 깎였는지까지 규칙 단위로 거슬러 올라갈 수 있습니다. 근거 없이 뚝 떨어진 점수가 아니라, 846개의 개별 판정이 쌓여 만들어진 비율이라는 감각이 중요합니다.

④ 위반 위험도 등급화 및 개선 우선순위 산정이 그 결과를 정리합니다. 운영 사이트는 페이지가 많아 위반이 수백 건씩 쏟아지는데, 이걸 그냥 나열하면 담당자는 어디부터 손대야 할지 막막합니다. 그래서 각 위반에 위험도를 매겨 P0부터 P3까지 줄을 세웁니다. 사용자를 아예 막아버리는 치명적 위반은 위로, 잘 안 쓰는 페이지의 사소한 위반은 아래로. 이 등급화가 있어야 긴 목록이 "이것부터"라는 행동 가능한 형태로 바뀝니다. 이 위험도 등급화의 원리는 다음 달이 아니라 **4개월차(위험도)**에서 본격적으로 파고듭니다.

**① 시점 비교(설계·운영 교차 검증)**도 URL 분석에 걸칩니다. 운영 시점은 이 비교의 "운영 쪽 절반"을 담당합니다. 설계 도면과 운영 화면을 같은 잣대로 견줄 때, 운영 화면 쪽 데이터가 바로 URL 분석에서 나옵니다. 또한 운영 사이트는 페이지가 많으니, 같은 사이트를 여러 시점에 걸쳐 다시 점검하며 "지난번보다 나아졌나"를 비교하는 일도 이 시점 비교의 몫입니다. 한 장의 사진이 아니라 연속된 기록으로 사이트를 따라가는 방식이지요. 여러 페이지를 한꺼번에 집계해 일관성을 보는 다중 페이지 이야기는 **6개월차(다중 페이지)**에서 자세히 다룹니다.

한 가지 더, URL 분석에는 앞서 다섯 특허를 관통한다고 말씀드린 "실제로 그려진 화면을 본다"는 성격이 가장 짙게 배어 있습니다. 정적인 코드만 보는 도구는 "코드상으로는 이렇게 되어 있다"까지밖에 못 갑니다. 그런데 요즘 웹은 코드가 브라우저에서 실제로 실행되어야 비로소 최종 화면이 완성됩니다. 같은 코드라도 화면 크기나 실행 순서에 따라 다르게 그려지기도 하지요. 렌더링 기반 수집(③)이 이 "실제 실행 결과"를 다루기 때문에, URL 분석은 코드 검사만으로는 잡히지 않는 어긋남까지 짚어낼 수 있습니다. 운영 시점 편에서 "가정이 아니라 현실을 본다"고 했던 그 말이, 특허의 언어로는 바로 이 렌더링 기반 수집·측정입니다.

또한 위험도 등급화(④)가 URL 분석에서 특히 값진 이유도 짚어두겠습니다. 운영 사이트는 페이지가 많아 위반이 수백 건씩 나오는데, 그 목록을 그냥 던져주면 담당자는 압도됩니다. "이렇게 많이 잘못돼 있었나" 하는 부담에 아예 손을 못 대기도 하지요. 그런데 같은 목록이라도 위험도로 줄이 세워지고 "이 다섯 개부터"라는 출발점이 생기면, 막막함이 실행으로 바뀝니다. 목록을 만드는 것과 그 목록을 행동으로 번역하는 것은 다른 일이고, 그 번역을 맡는 것이 ④입니다. 그래서 화면을 수집하고(③) 규칙으로 판정한(②) 뒤에, ④가 그 결과를 "행동 가능한 순서"로 바꿔주는 흐름이 URL 분석 안에 담겨 있습니다.

URL 분석에 가장 많은 특허가 걸치는 이유는 분명합니다. 실제 운영 화면이 "화면 수집·기준 판정·우선순위·시점 비교"를 한꺼번에 요구하기 때문입니다. 살아 움직이는 사이트를 통째로 본다는 것은, 그만큼 여러 방법을 동시에 동원해야 한다는 뜻입니다. 그래서 URL 분석은 세 방법 중 가장 종합적이고, 다음 달 심층편의 첫 타자로 삼기에도 가장 알맞습니다. 이 자리에서 네 특허가 실제로 어떻게 맞물려 돌아가는지를 하나씩 뜯어보는 것이, 바로 다음 달의 이야기입니다.

본론 4 — Figma 분석(설계 시점)에 걸치는 특허

다음은 설계 시점, Figma 분석입니다. 아직 코드로 만들기 전, 디자인 도면 단계에서 미리 점검하는 방법이지요. 여기엔 **② 기준 자동 판정(846규칙)**이 중심을 잡습니다.

Figma 분석의 핵심은, 도면의 색·간격·크기·구조가 KRDS 기준에 맞는지를 점검하는 것입니다. 디자인 파일에서 색 토큰과 글자·간격 값을 뽑아 표준 팔레트와 대조하고, 버튼이나 입력창 같은 컴포넌트가 규격대로 설계되었는지, 비활성·오류 같은 상태 설계가 빠지지 않았는지를 봅니다. 이 "기준에 맞나"를 자동으로 대조하는 일이 정확히 ② 기준 자동 판정입니다. 설계 시점에서 이 점검이 값진 이유는 단순합니다. 도면에서 잡으면 싸고, 운영에서 잡으면 비싸기 때문입니다. 만들기 전에 어긋남을 발견하면 도면 한 곳만 고치면 되지만, 다 만든 뒤에 발견하면 코드를 뜯어야 합니다.

그렇다면 나머지 특허들은 어떨까요. 여기서 솔직하게 짚어야 할 부분이 있습니다. 설계 시점에는 ③ 렌더링 기반 화면 수집·측정의 비중이 작습니다. 도면 단계에는 아직 "실제로 브라우저에 그려진 운영 화면"이 없기 때문입니다. 도면은 도면이지, 렌더링된 결과물이 아닙니다. 마찬가지로 운영 데이터가 없으니 다중 페이지의 시점 추세 같은 것도 아직 이르고, 위반 위험도 등급화(④)는 도면에서 나온 표준 이탈 항목에 한해 보조적으로 얹히는 정도입니다. "이 도면의 이 부분이 위험도가 높으니 개발에 넘기기 전에 먼저 처리하세요" 하는 식으로요.

대신 **① 시점 비교(설계·운영 교차 검증)**에서 설계 시점은 아주 중요한 한 축을 맡습니다. 시점 비교는 설계와 운영, 두 시점을 같은 잣대로 견주는 방법인데, 그 "설계 쪽 절반"이 바로 Figma 분석입니다. 도면을 846규칙으로 판정해 둔 결과가 있어야, 나중에 운영 화면과 나란히 놓고 "도면에선 맞았는데 실제로 어디서 어긋났나"를 짚을 수 있습니다. 설계 시점 점검이 없으면 이 교차 검증은 반쪽만 남습니다. 그래서 Figma 분석은 그 자체로도 값지지만, 시점 비교의 절반을 채운다는 점에서 더 값집니다.

여기서 설계 시점만의 값어치를 한 번 더 강조하고 싶습니다. Figma 분석에 걸치는 특허가 URL보다 적다고 해서, 설계 시점이 덜 중요하다는 뜻은 결코 아닙니다. 오히려 반대에 가깝습니다. 같은 어긋남이라도 발견 시점이 빠를수록 고치는 비용이 작아지기 때문입니다. 도면에서 색 토큰 하나가 표준을 벗어난 것을 발견하면 도면에서 값 하나만 바꾸면 되지만, 그 도면이 그대로 코드로 옮겨져 수십 개 화면에 퍼진 뒤에 발견하면 수십 곳을 뜯어고쳐야 합니다. 그래서 걸치는 특허의 수가 아니라 "언제 잡느냐"로 보면, 설계 시점 점검은 가장 값이 큰 자리 중 하나입니다. 표에 표시가 적다고 비중이 작은 것이 아니라, 이 시점의 성격이 "판정 중심"이라 그런 것뿐입니다.

그리고 설계 시점의 판정(②)은 운영 시점의 판정(②)과 같은 846규칙을 쓴다는 점도 짚어둘 만합니다. 도면을 볼 때든 운영 화면을 볼 때든 같은 잣대로 재기 때문에, 나중에 시점 비교(①)에서 두 결과를 나란히 놓고 견줄 수 있습니다. 만약 설계 점검과 운영 점검이 서로 다른 기준을 썼다면, 둘을 비교하는 일 자체가 성립하지 않았을 것입니다. 같은 자를 대야 두 시점의 길이를 견줄 수 있는 법이지요. 그래서 ②라는 하나의 잣대가 설계와 운영 양쪽에 공통으로 걸치는 배치가, 시점 비교(①)를 가능하게 하는 바탕이 됩니다.

정리하면 Figma 분석은 ②를 중심에 두고, ①의 절반을 채우며, ④가 보조로 얹히는 자리입니다. 화면 수집(③)이나 다중 페이지 운영 데이터가 필요한 특허의 비중은 작습니다. 설계 시점이라는 자리의 성격이 그렇습니다. 아직 "실물"이 없는 단계이니, "기준에 맞게 그려졌나"를 보는 판정이 중심일 수밖에 없습니다. 이 설계 시점을 도면 하나하나까지 깊게 파는 이야기는 **7개월차(Figma 분석)**에서 따로 다룹니다. 오늘은 "설계 시점엔 ②가 중심이고, ①의 절반을 여기서 채운다"는 큰 배치만 잡아두시면 됩니다.

전체 준수율·핵심 위험·개선 우선순위가 위에서부터 한 장으로 정리된 종합·임원 보고 요약 화면. 여러 시점과 여러 특허가 만들어낸 결과가 "현황 → 우선 과제 → 기대 효과"의 뼈대로 압축되는 자리 (기관명·도메인 블러)

본론 5 — LLM 분석(판단 시점)에 걸치는 특허

세 번째는 판단 시점, LLM 분석입니다. 규칙으로 다 채우지 못한 빈칸을 메우고, 흩어진 위반을 해석해 우선순위와 개선안으로 잇는 방법이지요. 여기엔 **⑤ 코드·화면 결합 판정(DOM·Vision 융합)**과 ④ 위반 위험도 등급화가 중심으로 걸치고, 개선안이 그 위에 얹힙니다.

**⑤ 코드·화면 결합 판정(DOM·Vision 융합)**이 판단 시점의 핵심 엔진입니다. 이 대목은 지난 판단 시점 편에서 본 "두 엔진" 이야기와 그대로 이어집니다. ViewCheck는 코드로 판정하는 규칙 엔진과, 화면으로 판정하는 화면 엔진, 두 엔진을 함께 씁니다. 규칙 엔진은 코드(DOM)를 읽어 846규칙을 빠르게 판정하지만, 코드만으로는 판단이 어려운 시각적 영역이 남습니다. 이를테면 이미지나 캔버스로 그려진 UI, 표준을 벗어난 방식으로 구현된 컴포넌트 같은 것들이지요. 그 코드로 못 본 빈칸을, 화면 엔진이 실제 화면을 학습된 방식으로 살펴 채웁니다. 코드가 "해당 없음(N/A)"으로 남긴 자리를, 화면 판정이 "있다/없다, 맞다/틀리다"로 메우는 것입니다. 이 "코드와 화면을 결합해 서로의 빈칸을 메우는" 절차가 정확히 ⑤입니다.

여기서 한 가지 원칙을 짚어두겠습니다. 두 엔진은 서로를 뒤집지 않습니다. 코드가 이미 "통과" 또는 "미통과"로 판정한 것을 화면 판정이 함부로 번복하지 않고, 화면 판정은 주로 코드가 비워둔 빈칸(N/A)과 코드가 보지 못하는 시각적 영역을 독자적으로 채웁니다. 이렇게 역할을 나눠두면 두 판정이 충돌하지 않으면서도 서로의 사각지대를 메웁니다. 한 엔진이 놓친 것을 다른 엔진이 잡되, 확실히 판정된 것은 건드리지 않는 것. 이 분업의 규칙이 ⑤ 특허가 지키려는 방법의 핵심입니다.

④ 위반 위험도 등급화도 판단 시점에 걸칩니다. 빈칸을 채워 판정을 마쳤다 해도, 그것만으로는 아직 "무엇이 급한가"를 모릅니다. 채워진 결과 위에서 "그래서 뭐가 제일 급한가"를 가려 줄을 세우는 일, 그것이 판단 시점의 몫입니다. 앞서 URL 분석에서도 ④가 걸친다고 했는데, 그것과 어긋나지 않습니다. URL 분석이 위반을 쏟아내는 자리라면, LLM 분석은 그 위반을 해석해 우선순위로 번역하는 자리입니다. 같은 위험도 등급화가 "결과를 만드는 쪽(URL)"과 "결과를 해석하는 쪽(LLM)" 양쪽에 걸치는 셈이지요.

그리고 그 위에 개선안이 얹힙니다. "이 위반을 이렇게 고치면 됩니다" 하는 개선 방법과 예시 코드를 글로 정리해 주는 것인데, 이것이 판단 시점의 가장 실용적인 산출물입니다. 위반을 찾는 것과 고치는 것 사이에는 생각보다 큰 간극이 있습니다. "이 버튼에 라벨이 없습니다"라는 지적만 받으면 담당자는 "그래서 어떻게 하라는 거지?" 싶지만, "이렇게 라벨을 붙이면 됩니다"라는 구체적 방법이 함께 있으면 그 간극이 확 줄어듭니다. 다만 앞서 말씀드렸듯 이 개선안은 별도의 여섯 번째 특허가 아니라, 다섯 방법이 만들어낸 결과 위에 얹히는 출력으로 다룹니다. 개선안의 원리와 실제 개선 실행 이야기는 **8개월차(LLM 분석)**에서 본격적으로 풀겠습니다.

판단 시점이 왜 필요한지, 조금 더 근본에서 말씀드리겠습니다. 규칙 판정만으로는 "해당 없음(N/A)"이 적지 않게 남습니다. 그 페이지에 그 요소가 아예 없거나, 코드만으로는 있다 없다를 가리기 어려운 경우이지요. 이 빈칸을 그대로 두면 "분석은 돌렸는데 실제로 판정된 것은 얼마 안 되는" 반쪽짜리 결과가 됩니다. 판단 시점이 하는 일이 바로 이 빈칸을 메우는 것입니다. 화면 엔진이 실제 화면을 살펴 "여기 이 컴포넌트가 있고, 이건 기준에 맞다/틀리다"를 채워 넣으면, N/A였던 자리가 실제 판정으로 바뀝니다. 코드로 못 본 것을 화면으로 보는 이 결합(⑤)이 있어야, 분석이 비로소 "충분히 본" 상태에 가까워집니다. 이 N/A를 어떻게 줄이고 채우는지가 **8개월차(LLM 분석)**의 핵심 주제이기도 합니다.

또 하나, 판단 시점은 "사실을 결정으로 번역하는" 자리입니다. 앞의 렌더링 수집과 규칙 판정이 "무엇이 어떻게 됐다"는 사실을 만들어낸다면, 판단 시점은 그 사실을 "그래서 무엇을 할 것인가"로 옮깁니다. 위반이 몇백 건이라는 사실만으로는 아무 결정도 내리기 어렵습니다. 그런데 그 위반을 위험도로 줄 세우고(④), 코드와 화면을 결합해 빈칸까지 메운(⑤) 결과 위에서 "이번 분기엔 이 다섯 개를 이 순서로"라는 결정이 나옵니다. 그래서 판단 시점은 실무자보다 오히려 의사결정자에게 더 요긴한 자리이기도 합니다. 데이터 더미를 결정 가능한 형태로 정리해 주니까요.

아래는 그 판단 시점의 한 결과입니다. 분석 결과를 KRDS 표준과 대조해 "기준 대비 어디가 부족한지"를 정리한 비교 화면이지요. 다섯 특허가 채우고 줄 세운 결과가, 이렇게 "표준 대비"라는 형태로 정리되어 나옵니다. 코드와 화면이 결합해 판정하고(⑤), 위험도로 줄을 세우고(④), 그 위에 개선안이 얹힌 결과가 한 장으로 압축된 모습입니다.

AI 종합보고서의 KRDS 비교분석 화면. 분석 결과를 KRDS 표준과 대조해 "기준 대비 어디가 부족한지"를 정리한, 다섯 특허가 채우고 줄 세운 결과의 종착 화면 (기관명·도메인 블러)

본론 6 — 한 장 매트릭스: 특허 × 방법

지금까지 방법별로 훑은 것을 한 표로 묶으면 이렇습니다. ◎는 핵심으로 걸침, ○는 보조로 걸침, —는 이 시점에선 비중이 작음을 뜻합니다.

특허 방법 영역(출원 중)	URL 분석(운영)	Figma 분석(설계)	LLM 분석(판단)
① 시점 비교(설계·운영 교차)	◎ 운영 쪽 절반	◎ 설계 쪽 절반	○ 결과 대조
② 기준 자동 판정(846규칙)	◎ 준수율 산출	◎ 도면 점검 핵심	○ 판정 근거
③ 렌더링 기반 화면 수집·측정	◎ 화면 수집 토대	—	○ 화면 근거
④ 위반 위험도 등급화·우선순위	◎ 위반 줄세움	○ 도면 위험 표시	◎ 판단·해석
⑤ 코드·화면 결합 판정(DOM·Vision)	◎ 두 판정 결합	—	◎ 빈칸 채움 엔진

이 표를 세로로 읽어보겠습니다. URL 분석 열을 위에서 아래로 훑으면 다섯 중 다섯에 표시가 있습니다. 운영 시점이 가장 종합적인 자리라는 것이 한눈에 드러나지요. 실제 화면을 수집하고(③), 846규칙으로 판정하고(②), 위반을 줄 세우고(④), 코드와 화면을 결합하고(⑤), 나아가 시점 비교의 한 축까지 맡으니(①), 다섯 방법이 이 한 자리에 다 모입니다. Figma 열은 ②를 중심으로 ①·④가 얹히는 좁고 단정한 배치이고, LLM 열은 ⑤·④가 중심을 잡는 판단 특화 배치입니다.

이번엔 가로로 읽어보겠습니다. ① 시점 비교는 URL과 Figma 양쪽에 핵심으로 걸치고 LLM에도 보조로 걸칩니다. 세 방법 모두에 손을 뻗는 셈인데, 당연합니다. "여러 시점을 견준다"는 것이 이 특허의 본질이니 여러 시점에 걸칠 수밖에 없습니다. ② 기준 자동 판정 역시 세 방법 모두에 걸칩니다. 846규칙이라는 잣대는 운영 화면이든 설계 도면이든 판단 근거로든 어디서나 쓰이기 때문입니다. 반면 ③ 렌더링 수집은 URL에 핵심으로 걸리되 Figma엔 걸리지 않습니다. 도면 단계엔 아직 렌더링된 실물이 없으니까요. ⑤ 코드·화면 결합도 URL과 LLM에 걸치되 Figma엔 걸리지 않습니다. 역시 운영 실물이 있어야 성립하는 방법이기 때문입니다.

다섯 행의 특허 자물쇠와 세 열의 방법 기둥이 만나는 격자 매트릭스. 꽉 찬 원과 빈 원 표식으로 핵심 연결과 보조 연결을 구분해 "5 × 3 특허-방법 매핑"을 담은 개념 도식 (Gemini 1:1)

이 매트릭스가 알려주는 것을 한 문장으로 줄이면 이렇습니다. 한 특허가 여러 방법을 받치고, 한 방법이 여러 특허로 받쳐집니다. 그리고 그 겹침에는 규칙이 있습니다. "실물(운영 화면)이 있어야 성립하는 특허(③⑤)"는 운영·판단 시점에 몰리고, "기준과 시점 자체를 다루는 특허(①②)"는 세 방법에 두루 퍼집니다. 이 규칙을 알아두면, 다음 달부터 어떤 방법 이야기를 읽든 "아, 이 방법엔 이런 성격의 특허가 걸리겠구나" 하고 미리 짐작이 됩니다.

이 매트릭스를 다르게 읽는 방법도 하나 있습니다. "실물이 있어야 성립하는 특허"와 "실물 없이도 성립하는 특허"로 나눠 보는 것입니다. 렌더링 수집(③)과 코드·화면 결합(⑤)은 실제로 그려진 운영 화면이 있어야 작동합니다. 그래서 운영·판단 시점에 몰리고, 아직 실물이 없는 설계 시점엔 걸리지 않습니다. 반대로 시점 비교(①)와 기준 판정(②)은 실물이 없어도 성립합니다. 도면이든 화면이든 같은 잣대로 견주고 판정하는 방법이니, 설계·운영·판단 어디에나 퍼질 수 있지요. 위험도 등급화(④)는 그 중간쯤입니다. 위반이 있는 곳이면 어디서든 줄을 세울 수 있으니, 세 시점에 두루 걸치되 위반이 가장 많이 쏟아지는 운영·판단 시점에서 특히 짙게 작동합니다. 이렇게 "실물 의존도"라는 한 축으로 다시 보면, 표의 ◎와 — 가 왜 그 자리에 놓였는지가 한결 또렷해집니다.

한 가지 더 강조하고 싶은 점이 있습니다. 표의 —(비중 작음) 칸을 억지로 채우지 않았다는 것입니다. Figma 열의 ③·⑤ 자리를 "이것도 됩니다" 하고 채워 넣을 수도 있었겠지만, 설계 시점엔 실물이 없어 그 방법의 비중이 실제로 작습니다. 그래서 정직하게 —로 두었습니다. 지도는 있는 그대로 그려야 쓸모가 있습니다. 모든 칸을 ◎로 칠한 화려한 표는 보기엔 그럴듯해도, 정작 "어느 방법에 무엇이 진짜 핵심인가"를 가려주지 못합니다. 빈 칸이 있는 지도가, 꽉 찬 지도보다 정확합니다.

본론 7 — 이 지도가 앞으로의 목차입니다

이 한 장 지도가 왜 중요하냐면, 다음 달부터 펼칠 심층편의 목차이기 때문입니다. 2개월차부터는 이 표의 칸을 하나씩 깊게 팝니다. 오늘은 "어느 특허가 어느 방법에 걸치나"라는 배치도만 그렸다면, 다음 달부터는 그 각 칸이 "실제로 어떻게 작동하나"를 뜯어봅니다.

첫 타자는 URL 분석입니다. 다음 달(2개월차)은 운영 시점의 URL 분석을 깊게 파는 달입니다. 표의 URL 열에 걸친 네 특허 — 렌더링 수집(③), 기준 판정(②), 위험도 등급화(④), 시점 비교(①) — 가 한 번의 분석에서 실제로 어떻게 맞물려 돌아가는지를 단계별로 풀어드립니다. 오늘 "URL 분석이 가장 종합적인 자리"라고만 말씀드린 그 안을, 다음 달에 열어 보여드리는 셈이지요.

그 뒤로는 표의 칸들이 달마다 하나씩 열립니다. 위반 위험도 등급화(④)를 정면으로 다루는 것은 **4개월차(위험도)**입니다. P0부터 P3까지 등급을 어떻게 가르고, 그 등급이 준수율에 어떻게 다르게 반영되는지를 파고듭니다. 846규칙의 네 카테고리(DS·CP·BP·SP) 각각의 성격과 깊은 내용은 **5개월차(4대 카테고리)**에서 하나씩 다룹니다. 여러 페이지를 한꺼번에 집계해 일관성과 추세를 보는 다중 페이지 이야기는 **6개월차(다중 페이지)**입니다. 설계 시점의 Figma 분석은 **7개월차(Figma)**에서, 판단 시점의 LLM 분석과 개선안·빈칸 채움은 **8개월차(LLM)**에서 본격적으로 열립니다.

그러니 오늘 이 지도를 머릿속에 한 장 넣어두면, 앞으로의 글들이 저마다 자리를 잡습니다. 4개월차 글을 읽을 땐 "아, 이게 표의 ④ 이야기구나", 5개월차 글을 읽을 땐 "이게 ② 안쪽 이야기구나", 8개월차 글을 읽을 땐 "이게 ⑤와 ④가 판단 시점에서 하는 일이구나" 하고요. 한 달짜리 오리엔테이션의 목적이 바로 이것이었습니다. 깊이 파기 전에 전체 지도를 먼저 그려, 앞으로 읽을 글들이 길을 잃지 않게 하는 것.

여기서 한 가지 안심하셔도 될 부분을 말씀드리겠습니다. 오늘 지도를 완벽히 외우실 필요는 전혀 없습니다. 지도는 필요할 때 다시 펴 보면 되는 것이지, 통째로 암기하는 것이 아닙니다. 다음 달부터 각 칸을 열 때마다 "이 칸이 지도의 어디에 있었지" 하고 오늘 글을 다시 펼치면 됩니다. 그렇게 심층편을 하나씩 따라가다 보면, 표를 억지로 외우지 않아도 각 칸의 위치가 저절로 몸에 익습니다. 오늘은 "이런 지도가 있다"는 것만 편하게 담아두시면 충분합니다.

본론 8 — 특허를 겸손하게 읽는 법

여기서 한 박자 쉬고, 오늘 그린 지도를 어떻게 받아들이면 좋을지 솔직하게 말씀드리겠습니다. "특허 다섯 개가 세 방법을 다 받친다니 대단하다"는 인상만 남는다면, 그건 오늘 글을 절반만 읽으신 것입니다.

먼저 정확한 표기부터 다시 하겠습니다. 다섯 건은 모두 출원 중입니다. 등록특허가 아니라 출원 기술입니다. 출원과 등록은 다릅니다. 출원은 "이런 방법으로 권리를 정리하겠다고 접수한 단계"이고, 등록은 심사를 거쳐 권리가 확정된 단계입니다. ViewCheck는 현재 출원 단계이므로, "등록특허"라고 부풀리지 않고 "출원 기술"이라고 정확히 적습니다. 마케팅에서 이런 표기 하나가 별것 아닌 듯 보여도, 정확하지 않으면 그 순간부터 나머지 이야기 전체의 신뢰가 흔들립니다. 그래서 이 부분은 매번 정확하게 적어두려 합니다.

다음으로, 더 중요한 이야기입니다. 특허는 "방법을 지키는 장치"이지 "품질 보증서"가 아닙니다. 오늘 그린 지도가 아무리 그럴듯해 보여도, 결과의 품질은 각 칸의 방법이 실제로 얼마나 잘 작동하느냐로 결정되는 것이지, 특허가 있다는 사실 자체로 보장되는 것이 아닙니다. 렌더링 수집이 실제로 운영 화면을 정확히 재는가, 846규칙 판정이 실제로 맞게 판정하는가, 위험도 등급이 실제로 현실적인 우선순위를 내는가, 두 엔진이 실제로 서로의 빈칸을 잘 메우는가 — 이 "실제로"들이 품질을 만듭니다. 그리고 그 "실제로"는 다음 달부터의 심층편에서 하나씩 보여드릴 몫입니다.

그래서 오늘 지도를 받아들이는 올바른 자세는 "특허 다섯으로 다 받친다니 믿을 만하다"가 아니라, "이 방법들을 직접 만들어 권리로 지켜두었고, 이제 하나씩 그 작동을 보여주겠다" 정도입니다. 특허는 우리가 이 방법을 남보다 먼저, 직접 설계해 정리했다는 증거일 뿐입니다. 그 방법이 실전에서 얼마나 잘 도는지는, 직접 넣어보시고 결과를 확인하시는 것이 가장 빠릅니다. 특허를 근거로 "믿어 달라"고 말하는 대신, 방법의 작동을 결과로 보여드리겠다는 것 — 이것이 이 시리즈 내내 지키려는 태도입니다.

이 태도가 왜 중요한지, 반대 경우를 상상해 보면 분명해집니다. 만약 "특허가 다섯 개나 있으니 결과는 무조건 정확합니다"라고 말한다면, 그건 특허의 성격을 오해하게 만드는 과장입니다. 특허는 방법이 새롭고 구분된다는 것을 인정받으려는 절차이지, 그 방법이 매번 옳은 답을 낸다는 보증이 아닙니다. 세상의 어떤 자동 분석도 100% 완벽하지 않고, ViewCheck도 예외가 아닙니다. 그래서 저희는 결과에 확신의 등급을 두고, 코드로 확실히 판정된 것과 화면으로 보조 판정한 것을 구분하며, 판단이 어려운 자리는 "해당 없음"으로 정직하게 비워둡니다. 완벽하다고 우기는 대신, 어디까지 확실하고 어디부터 불확실한지를 함께 보여드리는 것 — 그것이 특허보다 오히려 더 신뢰를 만드는 태도라고 믿습니다. 다음 달부터의 심층편도 그 정직함의 연장선에서, 각 방법이 어디까지 해내고 어디서 한계가 있는지를 숨기지 않고 보여드리겠습니다.

한 가지 덧붙이면, 특허를 다섯 개로 나눠 낸 것 자체에도 이런 정직함이 배어 있습니다. 하나의 거대한 "만능 특허"로 뭉뚱그리지 않고, 시점 비교·기준 판정·화면 수집·위험도 등급화·코드화면 결합이라는 다섯 개의 독립된 방법 단위로 나눈 것은, 각 방법이 실제로 구분되는 기술이기 때문입니다. 그리고 그렇게 나눠두었기에 오늘처럼 "어느 방법이 어느 시점에 걸치나"를 한 장 지도로 그릴 수 있었습니다. 뭉뚱그린 하나였다면 이런 지도는 애초에 그려지지 않았을 것입니다. 나눠 낸 것이 곧 정직하게 지도를 그릴 수 있는 바탕이 된 셈입니다.

그래서 ViewCheck는

ViewCheck는 세 방법(URL·Figma·LLM)을 한 도구에 모았고, 그 방법을 다섯 건의 특허(출원 중)로 받칩니다. 운영 시점의 URL 분석엔 렌더링 수집(③)·기준 판정(②)·위험도 등급화(④)·시점 비교(①)가, 설계 시점의 Figma 분석엔 기준 판정(②)이 중심으로 걸치며 시점 비교(①)의 절반을 채웁니다. 판단 시점의 LLM 분석엔 코드·화면 결합(⑤)과 위험도 등급화(④)가 걸치고, 그 위에 개선안이 얹힙니다. 이 매핑이 이 도구의 뼈대 지도입니다.

거창하게 들릴 수 있지만, 결국 한 달 동안 본 모든 것이 이 한 장으로 모입니다. 세 시점(설계·운영·판단), 세 방법(URL·Figma·LLM), 다섯 특허(시점 비교·기준 판정·화면 수집·위험도 등급화·코드화면 결합), 그리고 846규칙이 집계된 하나의 결과 화면. 흩어져 보였던 조각들이 서로 어떻게 맞물리는지, 오늘 지도로 한 번 이어드렸습니다. krds.viewcheck.co.kr에서 분석을 한 번 돌려보시면, 오늘 지도의 각 칸이 실제 결과 화면의 어디에 대응하는지가 눈에 들어오실 겁니다.

그리고 솔직히, 오늘 이야기한 지도는 어떤 특정 도구의 자랑이라기보다, "웹 품질을 제대로 보려면 이 방법들이 필요하다"는 일반적인 뼈대에 가깝습니다. 설계에서 미리 잡고, 운영에서 현실을 확인하고, 판단에서 결론을 내리는 것. 그 각 단계를 같은 기준으로 자동화하는 것. 이 골격은 도구가 달라도 통합니다. ViewCheck는 그 골격을 하나의 도구에 모아 담고, 각 방법을 직접 만들어 권리로 지켜둔 것뿐입니다. 그게 실제로 맞는지는, 다음 달부터의 심층편과 직접 넣어보시는 경험이 답해 드릴 것입니다.

특허로 지키는 부분

오늘 그린 지도 자체가 다섯 특허의 배치도입니다. ① 시점 비교(설계·운영 교차 검증) ② 기준 자동 판정(846규칙) ③ 렌더링 기반 화면 수집·측정 ④ 위반 위험도 등급화 및 개선 우선순위 산정 ⑤ 코드·화면 결합 판정(DOM·Vision 융합) — 이 다섯 방법이 세 방법(URL·Figma·LLM)에 걸쳐 작동합니다. 한 특허가 여러 방법을 받치고, 한 방법이 여러 특허로 받쳐지는 이 유연한 배치가, "기능"이 아니라 "방법"을 권리로 정리한 결과입니다. 다섯으로 나눠 낸 덕분에 각 방법을 여러 시점에 자유롭게 걸칠 수 있었고, 그 덕에 오늘 같은 한 장 지도를 정직하게 그릴 수 있었습니다.

다만 솔직히 짚어둘 것이 있습니다. 특허는 "방법을 지키는 장치"이지 "품질 보증서"가 아닙니다. 이 지도가 그럴듯해 보여도, 결과의 품질은 각 칸의 방법이 실제로 잘 작동하느냐로 결정되는 것이고, 그건 다음 달부터의 심층편에서 하나씩 보여드릴 몫입니다. 그래서 "특허 다섯 개로 다 받친다니 대단하다"가 아니라 "이 방법들을 직접 만들고 지켜두었으니, 이제 하나씩 그 작동을 보여드리겠다" 정도로 받아들여 주시면 됩니다. 그리고 현재는 출원 중입니다. 등록특허가 아니라 출원 기술로 정확히 표기합니다. (특허 출원 기술 / 자체 개발)

마무리

오늘로 1개월차 오리엔테이션을 마칩니다. 한 달 동안 세 시점(설계·운영·판단), 세 방법(URL·Figma·LLM), 다섯 특허(시점 비교·기준 판정·화면 수집·위험도 등급화·코드화면 결합)를 봤고, 오늘 그것을 한 장 매트릭스로 묶었습니다. 다섯 특허가 세 방법에 걸치고, 세 방법이 846규칙의 하나의 결과로 모입니다. 이 지도가 앞으로의 목차입니다.

돌아보면 한 달이라는 시간이, 흩어진 개념들을 하나씩 놓고 마지막에 이어 붙이기에 꼭 알맞았습니다. 첫 주에 큰 틀을 세우지 않고 곧장 세부로 들어갔다면, 아마 지금쯤 "그래서 이게 다 무슨 관계였지" 하고 길을 잃으셨을지도 모릅니다. 세 시점을 세우고, 세 방법을 하나씩 보고, 다섯 특허를 짚은 뒤에야 오늘의 지도가 의미를 갖는 것처럼, 이해에는 순서가 있습니다. 그 순서를 지켜 한 달을 걸어온 셈입니다.

한 달을 한 줄로 줄이면 이렇습니다. 사람 손만으로는 웹 품질을 다 따라잡기 어렵다는 데서 출발해, 웹을 보는 세 시점을 세우고, 그 시점을 URL·Figma·LLM 세 방법으로 풀었으며, 그 방법을 다섯 특허로 받친다는 것을 확인하고, 오늘 그 전부를 한 장 지도로 이었습니다. 조각으로 흩어져 보였던 것들이, 실은 하나의 그림이었다는 것을 마지막에 보여드린 셈입니다.

다음 달(2개월차)부터는 이 지도의 칸을 하나씩 깊게 팝니다. 첫 타자는 URL 분석입니다. 실제 운영 사이트를 주소만으로 통째로 점검하는 그 방법을, 표의 렌더링 수집·기준 판정·위험도 등급화·시점 비교가 한 번의 분석에서 어떻게 맞물려 돌아가는지로 풀어가겠습니다. 오늘 스무 개가 넘는 분석 영역과 846규칙, 다섯 특허를 한 장에 모아 두었으니, 다음 달엔 그중 URL이라는 칸 하나를 열어 안을 들여다보는 셈입니다. 숲을 봤으니, 이제 나무 하나하나로 들어갑니다.

혹시 이번 달 글을 중간부터 읽으셨더라도 괜찮습니다. 오늘 지도 한 장이면 그동안의 조각들이 어디에 놓이는지 대강 잡히실 테고, 궁금한 칸이 있으면 해당 달의 심층편에서 다시 만나면 되니까요. 오리엔테이션은 시작을 위한 준비이지, 끝이 아닙니다. 오히려 오늘부터가 본론의 문 앞입니다.

오리엔테이션을 끝까지 함께 읽어 주셔서 고맙습니다. 오늘 딱 하나만 가져가신다면, "다섯 특허가 세 방법에 걸치고, 세 방법이 하나의 결과로 모인다"는 이 한 문장이면 좋겠습니다. 이 문장만 손에 쥐고 계시면, 다음 달부터의 심층편이 저마다 제자리를 찾아 들어옵니다. 나머지 세부는 그때그때 필요한 만큼만 열어 보시면 충분합니다. 지도를 한 번 그려두었으니, 이제 함께 그 길을 하나씩 걸어가면 됩니다. 다음 달, 심층편에서 다시 뵙겠습니다.

krds.viewcheck.co.kr

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

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

ViewCheck — Fri, 25 Sep 2026 08:01:24 +0900

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

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

23편 : 개방성 자동 진단의 속사정 — robots.txt·sitemap.xml, 공공사이트의 문은 얼마나 열려 있는가

ViewCheck — Thu, 24 Sep 2026 18:00:21 +0900

23편 : 개방성 자동 진단의 속사정 — robots.txt·sitemap.xml, 공공사이트의 문은 얼마나 열려 있는가

검색엔진·크롤러에게 정보를 얼마나 여는가. 두 파일의 내용을 파싱해야 비로소 보이는 것들

들어가며 — '개방성'이라는 단어가 감추는 기술적 현실

행안부 「전자정부 웹사이트 품질관리 지침」(고시 제2025-46호, 2025년 6월 25일 시행)은 공공 웹사이트가 갖춰야 할 7대 품질 영역 중 하나로 개방성을 명시한다. 개방성이라는 단어는 직관적으로 들린다. "우리 사이트는 열려 있습니다"라고 말하면 뭔가 다 된 것처럼 느껴지기도 한다.

그런데 막상 기술적으로 들어가면 이야기가 달라진다. 검색엔진과 크롤러에게 "어디까지 와도 되고, 어디는 오지 마시오"를 알려주는 파일이 실제로 존재한다. robots.txt라는 평범한 텍스트 파일이다. 그리고 "우리 사이트에 이런 페이지들이 있으니 인덱스해 가세요"를 말해주는 sitemap.xml도 있다. 이 두 파일이 없거나, 있어도 잘못 작성되어 있거나, 형식만 갖추고 내용이 비어 있거나 — 이런 상황이 공공 사이트에서 얼마나 자주 벌어지는지를 우리는 분석 과정에서 꽤 많이 목격했다.

더 흥미로운 건 2025년 고시 개정 내용이다. 이번 개정에서 개방성 기준의 일부가 완화됐다. 이전에는 크롤링 완전 허용이 기본 전제였다면, 이제는 부분 차단(Disallow)도 허용하는 방향으로 바뀌었다. "완전히 열어야 한다"에서 "합리적 범위에서 통제할 수 있다"로의 변화다. 이 변화가 무엇을 의미하는지, 그리고 그 '합리적 범위'를 자동으로 판단하려면 무엇을 파싱해야 하는지 — 이것이 이 글의 핵심 주제다.

ViewCheck LLM 분석은 URL을 입력받으면 24가지 관점으로 분석 결과를 대화로 펼쳐준다. 그 24가지 중에 SEO(검색최적화) 항목이 있고, 그 안에 개방성 진단이 포함된다. 이 편에서는 그 개방성 진단이 어떻게 작동하는지, 어떤 기술적 배경이 깔려 있는지, 그리고 "파일이 있느냐 없느냐"만 보는 것과 "내용을 파싱하는 것" 사이에 어떤 차이가 있는지를 R&D 여정의 관점에서 풀어보려 한다.

사이트맵 다이어그램을 들여다보는 사람. 공공사이트의 '개방성'은 몇 줄짜리 텍스트 파일에서 시작한다.

robots.txt — 28년의 관습이 2022년에야 정식 표준이 된 사연

이야기를 시작하기 전에 한 가지 역사적 사실부터. robots.txt는 1994년 네덜란드 컴퓨터 과학자 마르테인 코스터(Martijn Koster)가 처음 제안한 파일이다. 웹이 아직 걸음마 단계이던 시절, 검색 엔진 크롤러들이 무작위로 사이트를 긁어가는 것을 막기 위해 "이 파일을 읽고 지시에 따라 달라"는 약속을 만든 것이다.

그로부터 약 28년이 지난 2022년 9월, IETF(Internet Engineering Task Force)는 이 오랜 관습을 RFC 9309 — Robots Exclusion Protocol이라는 공식 표준으로 등재했다. RFC Editor에 따르면 이 문서는 수십 년간 사실상(de facto) 표준으로 작동해 온 robots.txt 프로토콜을 처음으로 공식 인터넷 표준(Internet Standard)으로 끌어올린 것이다(RFC 9309, IETF/RFC Editor, 2022). 표준화 작업이 이렇게 오래 걸린 데는 이유가 있다. robots.txt는 워낙 단순하고, 각 검색엔진이 조금씩 다르게 해석해 왔으며, 강제력이 없는 '신사 협정'이었기 때문이다.

RFC 9309가 확정한 핵심 내용은 이렇다.

User-agent: 규칙을 적용할 크롤러를 지정한다. *는 모든 크롤러에 해당.
Disallow: 접근을 막을 경로를 지정한다. /admin/이라고 쓰면 /admin/으로 시작하는 모든 URL이 차단된다.
Allow: 특정 경로를 명시적으로 허용한다. Disallow와 중복될 때는 더 구체적(긴) 경로가 우선한다.
Sitemap: robots.txt 파일에 sitemap.xml의 위치를 명시한다.
Crawl-delay: 크롤러가 요청 사이에 기다려야 하는 시간. 단, Google은 이 지시어를 지원하지 않는다.
캐싱: 크롤러는 robots.txt를 캐시해 두되, 24시간을 넘겨 사용하지 않아야 한다.

"파일이 있다"는 것과 "파일의 내용이 타당하다"는 것은 전혀 다른 이야기다. robots.txt를 단순히 HTTP 200 응답이 오는지만 확인하는 것은, "현관문이 있다"는 것만 확인하고 "그 문이 제대로 달려 있는지"는 보지 않는 것과 같다. ViewCheck가 내용 파싱 기능을 개발한 출발점이 바로 이 지점이다.

sitemap.xml — "우리 집에 뭐가 있는지 목록을 드릴게요"

robots.txt가 "어디는 들어오지 마세요"를 말한다면, sitemap.xml은 "들어와서 이걸 봐 주세요"를 말한다. 사이트에 있는 URL들을 XML 형식으로 나열한 파일로, 검색엔진이 놓칠 수 있는 페이지를 확실히 인덱싱하도록 돕는다.

sitemap.xml의 공식 프로토콜은 sitemaps.org에서 정의된다. 구글, 야후, 마이크로소프트(빙) 세 회사가 2006년에 공동으로 마련한 이 사양은 오늘날 사실상의 표준으로 자리 잡았다(sitemaps.org 공식). 주요 내용은 이렇다.

XML 형식, UTF-8 인코딩 필수
단일 파일에 최대 50,000개 URL, 50MB(비압축) 제한
<loc>: URL (필수)
<lastmod>: 콘텐츠 마지막 수정일 (선택, 그러나 Google이 실제로 활용하는 유일한 메타데이터)
<changefreq>: 변경 빈도 (선택, Google은 무시함)
<priority>: 중요도 (선택, Google은 무시함)

여기서 실무적으로 중요한 포인트가 하나 있다. Google은 <priority>와 <changefreq> 값을 무시한다(Google Search Central 공식). 이 두 값을 설정하는 데 시간을 쓰는 것은, 구글 기준으로는 아무 효과가 없는 작업이다. 대신 <lastmod> 값을 정확하게 관리하는 것이 실질적으로 의미 있다. Google은 이 값이 신뢰할 수 있을 때만 실제 크롤링 신호로 활용한다.

50,000개를 초과하는 대형 사이트라면 sitemap index 파일을 사용한다. 여러 개의 sitemap.xml을 묶는 상위 파일이다. 대형 공공기관 포털이라면 이 구조를 써야 할 수도 있다.

크롤러의 눈으로 사이트맵을 검사한다. 형식이 맞아도 내용이 잘못되면 검색엔진의 눈에 보이지 않는다.

"있느냐 없느냐"에서 "뭐라고 적혀 있느냐"로 — 내용 파싱의 의미

ViewCheck 이전에도 개방성을 체크하는 도구들이 있었다. 그러나 많은 경우 "robots.txt가 HTTP 200을 반환하는가", "sitemap.xml이 존재하는가"만 확인했다. 파일이 존재하면 '개방성 통과', 없으면 '미통과'. 이 정도로 처리했다.

그런데 현장에서 보면, 파일은 있는데 내용이 문제인 경우가 훨씬 많다. 우리가 실제 분석 과정에서 마주친 사례들을 유형별로 정리하면 이렇다.

유형 1: 전체 차단 (사고)

User-agent: *
Disallow: /

위 두 줄은 모든 크롤러에게 사이트 전체를 차단한다. 사이트가 검색엔진에 아예 잡히지 않는다. 개발 단계에서 설정해 두고 배포 때 수정하지 않은 채 그대로 올라가는 경우가 대표적이다. 파일은 분명히 있지만, 그 내용이 사이트의 가시성을 완전히 막아버린다. 이를 "개방성 통과"로 판정하면 오진이다.

유형 2: 텅 빈 파일

파일은 존재하고 200 응답을 반환하지만 내용이 없거나, User-agent: *만 있고 Disallow/Allow가 없는 경우. 기술적으로는 "모든 크롤러에게 모두 허용"이지만, 의도인지 실수인지 알 수 없다. 이 경우 최소한 sitemap.xml 위치라도 적어두면 크롤러가 훨씬 효율적으로 동작하는데, 그 기회를 날리고 있는 것이다.

유형 3: sitemap.xml 경로 오입력

robots.txt에 Sitemap: https://example.go.kr/sitemap.xml이라고 적혀 있지만, 실제 sitemap.xml은 /sitemap/sitemap.xml에 있거나 존재 자체가 없는 경우. 크롤러가 robots.txt에 명시된 경로로 요청을 보내면 404가 떨어진다.

유형 4: sitemap.xml의 URL 불일치

sitemap.xml 안에 나열된 URL이 실제로 200 응답을 반환하지 않는 경우. 리다이렉트가 걸려 있거나, 이전에 삭제된 페이지가 목록에 남아 있거나. 검색엔진은 이런 URL을 크롤링하다가 쓸데없이 크롤 버짓(crawl budget)을 소진한다.

유형 5: lastmod 미갱신

sitemap.xml에 모든 URL의 <lastmod>가 2019-01-01로 고정되어 있거나, 아예 날짜 표기가 없는 경우. 구글은 정확한 lastmod만 크롤링 신호로 활용하므로, 이 값이 엉터리면 "최신 콘텐츠인데도 재크롤링이 느린" 문제가 생긴다.

이 다섯 가지 유형 모두, 파일의 존재 여부만 확인해서는 포착할 수 없다. 내용을 파싱해야 비로소 보인다. 이것이 ViewCheck가 "파일 있음/없음" 체크를 넘어서 robots.txt 내용 파싱과 sitemap.xml 구조 분석으로 나아간 이유다.

2025년 고시 개정 — "완전 개방"에서 "합리적 통제"로

앞서 간략히 언급했지만, 이 부분은 좀 더 자세히 살펴볼 필요가 있다.

행안부고시 제2025-46호(2025년 6월 25일 시행) 개정 내용 중 개방성 관련 변화가 있다. 이전 지침에서는 공공 웹사이트의 크롤링 허용이 원칙적으로 전면 개방을 전제로 했다면, 이번 개정에서는 "크롤링의 부분 차단"을 허용하는 방향으로 완화됐다. 서울시 정보소통광장에 공개된 결재 문서에서도 이 변화를 확인할 수 있다(서울특별시 정보소통광장, 전자정부 웹사이트 품질관리 지침 일부 개정 관련 결재문서).

이 변화를 어떻게 읽어야 할까. 우리가 보기엔, 이건 "개방성을 포기하자"가 아니라 "현실을 인정하자"에 가깝다.

공공 사이트에는 민감한 정보가 있다. 개인정보가 담긴 행정 처리 화면, 보안이 필요한 관리자 경로, 시스템 내부 API 엔드포인트. 이런 경로까지 전면 개방하면 오히려 보안 문제가 생긴다. robots.txt의 Disallow는 이런 경로를 합리적으로 제외할 수 있는 표준 수단이다.

더 나아가, 2025~2026년 현재는 GPTBot(OpenAI), ClaudeBot(Anthropic), Google-Extended, PerplexityBot, Bytespider(TikTok) 같은 AI 학습 목적의 크롤러가 급증했다. 기존의 검색 인덱싱 목적과는 다른 맥락이다. Cloudflare의 분석에 따르면, 2024년 이후 주요 웹사이트의 robots.txt에 AI 봇 차단 지시어가 폭발적으로 늘어났다(technologychecker.io, 2024). 검색 크롤러는 허용하되 AI 학습 크롤러는 차단하는 세분화된 정책이 현실적으로 필요해진 것이다.

이런 맥락에서 2025년 고시 개정은, "크롤링 차단 = 나쁜 것"이라는 이진법적 판단에서 벗어나 "어떤 크롤러에게, 어떤 경로를, 왜 차단하거나 허용했는가"를 다층적으로 보도록 기준을 진화시킨 것으로 이해할 수 있다.

ViewCheck의 개방성 진단도 이 방향을 따른다. 단순히 "Disallow가 있는가"를 체크하는 게 아니라, 어떤 경로가 차단되었고, 그것이 사이트의 주요 콘텐츠 노출에 영향을 미치는가를 살핀다. 관리자 경로를 막은 것과 검색 결과 페이지를 막은 것은 전혀 다른 판정을 받아야 한다.

ViewCheck가 파싱하는 것들 — robots.txt 편

ViewCheck가 robots.txt에서 실제로 뽑아내는 정보를 정리하면 이렇다.

1. 파일 존재 + HTTP 상태

가장 기본이다. https://{domain}/robots.txt에 GET 요청을 보내 HTTP 응답 코드를 확인한다. 200이면 존재, 404면 없음, 403은 있지만 접근 거부(이 경우도 따로 표기).

2. User-agent 그룹 수집

파일 내에 몇 개의 User-agent 그룹이 정의되어 있는지, 특정 크롤러(Googlebot, Bingbot, Yandexbot, GPTBot 등)가 별도로 명시되어 있는지를 파악한다. 특정 크롤러에 대한 개별 정책이 있다는 것 자체가 해당 사이트가 크롤링 정책을 얼마나 세심하게 관리하는지를 보여준다.

3. Disallow 경로 수와 패턴

차단된 경로가 몇 개인지, 어떤 패턴인지를 본다. /admin/, /private/처럼 명백히 관리 목적인 경로는 합리적 차단으로 분류한다. 반면 /, /*, /board/, /notice/ 같은 핵심 콘텐츠 경로가 막혀 있다면 다른 판정을 한다.

4. Sitemap 지시어 유무

robots.txt 파일 내에 Sitemap: 지시어가 있는지, 있다면 어떤 URL을 가리키는지를 추출한다. 이 URL이 실제로 접근 가능한지도 확인한다.

5. 파일 크기(처음 2KB 범위 내 원문 보존)

지나치게 큰 robots.txt(수십 KB 이상)는 그 자체로 이상 신호일 수 있다. 수천 개의 Disallow 규칙이 한 파일에 쌓여 있는 경우, 관리 없이 계속 덧붙인 흔적인 경우가 많다.

이 정보들을 종합해 ViewCheck는 robots.txt 상태를 크게 세 범주로 분류한다.

정상적 개방: 파일 있음, 핵심 콘텐츠 경로 접근 가능, Sitemap 지시어 있음
부분 차단 (합리적 범위): 관리자/내부 경로만 차단, 주요 콘텐츠는 열려 있음
문제적 차단: 주요 콘텐츠 경로 차단, 또는 전체 차단 (Disallow: /)

ViewCheck가 파싱하는 것들 — sitemap.xml 편

sitemap.xml 분석은 robots.txt보다 더 복잡하다. 파일이 있어도 내용의 품질이 천차만별이기 때문이다.

1. 파일 위치 탐색

먼저 robots.txt에 명시된 Sitemap 경로를 확인한다. 없다면 관례적인 경로들(/sitemap.xml, /sitemap_index.xml, /sitemap/sitemap.xml)을 순서대로 시도한다.

2. sitemap index vs 단일 sitemap 구분

최상위 태그가 <sitemapindex>인지 <urlset>인지를 확인해 구조를 파악한다. sitemap index라면 하위 sitemap 파일들의 URL을 수집한다.

3. URL 수 집계

<loc> 태그로 묶인 URL이 몇 개인지 센다. URL 수가 너무 적으면 (사이트 규모에 비해) 중요 페이지가 누락되어 있을 가능성이 있다. 반대로 50,000개에 근접하면 sitemap index 분리가 필요한 상태일 수 있다.

4. lastmod 유효성 검증

<lastmod> 값이 ISO 8601 형식(YYYY-MM-DD 또는 YYYY-MM-DDTHH:MM:SS+09:00)에 맞는지, 미래 날짜가 아닌지, 너무 오래된 날짜(5년 이상)가 아닌지를 확인한다. Google Search Central이 명시하듯, lastmod가 일관성 있게 정확할 때만 크롤링 신호로 활용된다(Google Search Central 공식 문서). 이 값이 엉터리인 파일은 있어도 없는 것이나 마찬가지다.

5. sourceUrl (실제 출처 URL) 기록

어떤 경로에서 sitemap.xml을 찾았는지를 기록한다. robots.txt에 명시된 경로와 실제 파일 위치가 다를 경우 이를 지적한다.

ViewCheck LLM 분석의 실제 SEO 상세 화면. robots.txt 파싱 결과, sitemap.xml 구조 분석, 개방성 진단 결과가 한 화면에 정리된 모습. 단순 존재 여부가 아니라 내용의 타당성까지 표시된다. — 실제 분석 화면

기술적 구현의 어려움 — "간단해 보이는 것"의 함정

robots.txt와 sitemap.xml 파싱이 "간단한 작업"처럼 보일 수 있다. 텍스트 파일을 다운로드해서 읽으면 되는 것 아닌가. 실제로 해보면 그렇지 않다.

문제 1: 인코딩 문제

RFC 9309는 robots.txt 파일이 UTF-8을 기본으로 할 것을 명시한다. 그러나 오래된 공공 사이트 중에는 EUC-KR 또는 CP949로 인코딩된 robots.txt가 존재한다. 한국어 주석(# 관리자 경로 차단)이 들어간 경우 특히 그렇다. 인코딩을 잘못 해석하면 내용 전체가 깨진다.

문제 2: 대소문자 혼용

RFC 9309는 필드 이름(User-agent, Disallow 등)이 대소문자를 구분하지 않는다고 규정한다. 하지만 경로 매칭은 대소문자를 구분한다. Disallow: /Admin/과 Disallow: /admin/은 다른 경로다. 그런데 실제 파일에서는 user-agent, DISALLOW, User-Agent 등 다양한 표기가 섞여 있다. 이를 정규화하지 않으면 파싱 오류가 발생한다.

문제 3: 주석과 빈 줄 처리

# 이후는 주석이다. 그런데 인라인 주석(Disallow: /private/ # 개인정보 경로)과 독립 주석(# 모든 봇 차단)을 구분하는 로직이 필요하다. 또 User-agent 그룹은 빈 줄로 구분되는데, 파일 끝에 줄바꿈이 없거나 연속 빈 줄이 있으면 파싱이 엉킬 수 있다.

문제 4: sitemap.xml의 크기와 타임아웃

대형 포털 사이트의 sitemap.xml은 수 MB에 달하기도 한다. 전체를 내려받아 파싱하면 메모리와 시간이 많이 든다. 스트리밍 파싱(SAX 방식)과 최대 URL 수 제한(예: 처음 1,000개만 파싱)이 필요하다.

문제 5: 타임아웃과 리다이렉트

공공 사이트 중 robots.txt에 5초 이상 응답하는 경우가 있다. 또는 /robots.txt가 사이트 메인 페이지로 리다이렉트되는 경우도 있다(보통 파일이 없을 때). 이런 케이스를 구분해 타임아웃과 리다이렉트 횟수에 제한을 두고 처리해야 한다.

ViewCheck는 이런 엣지 케이스들을 하나씩 처리하는 코드를 openness-checker.js라는 모듈에 모아서 관리한다. 페이지 분석마다 반복 호출하는 게 아니라, 사이트 분석 시작 시 1회만 호출하고 결과를 재사용한다. robots.txt와 sitemap.xml은 사이트 전체에 하나씩 있는 파일이기 때문이다.

"크롤링 예산"이라는 개념과 공공 사이트

Google은 모든 사이트에 '크롤링 예산(crawl budget)'을 할당한다. 특정 시간 내에 Googlebot이 한 사이트에서 크롤링할 수 있는 URL 수의 상한이다. 이 예산은 무한하지 않다.

sitemap.xml이 없거나 불량하면, 크롤러는 내부 링크를 따라가면서 페이지를 발견해야 한다. 이 과정에서 정작 중요한 페이지가 발견되기 전에 예산이 소진될 수 있다. 특히 공공 사이트는 민원 처리 시스템, 검색 결과 페이지, 게시판 필터 조합 등 인덱싱이 필요 없는 동적 URL이 많다. 이런 URL들이 robots.txt에서 차단되지 않고 sitemap.xml에서도 걸러지지 않으면, 크롤러는 쓸모없는 URL에 예산을 낭비하게 된다.

Straightnorth의 분석에 따르면 "XML 사이트맵은 중요 URL의 목록을 명확하게 제공함으로써 검색엔진이 주요 콘텐츠를 발견하고 색인하도록 안내하며, robots.txt는 크롤러가 접근해서는 안 될 영역을 지정함으로써 크롤링 예산을 보호한다"고 정리한다(Straightnorth, "XML Sitemaps & Robots.txt: How to Guide Search Engines Effectively"). 두 파일이 서로 보완 관계를 이루는 것이다.

공공 사이트의 경우, 이 두 파일의 관계가 어긋나는 경우가 많다. sitemap.xml에는 URL이 올라가 있지만 robots.txt에서 그 경로가 막혀 있거나, 반대로 robots.txt에서 허용했지만 sitemap.xml에 해당 URL이 없는 경우. Google Search Central도 이런 불일치를 명시적으로 경고한다. "sitemap.xml에 있는 URL이 robots.txt에서 차단되어서는 안 된다"는 것이다(Google Search Central, "Build and Submit a Sitemap").

ViewCheck의 개방성 분석은 이 교차 검증을 자동으로 수행한다. robots.txt의 Disallow 경로와 sitemap.xml의 URL 목록을 대조해, "사이트맵에 올라가 있지만 차단된 URL"이 있는지를 발견한다. 이런 불일치를 손으로 찾는 건 수십~수백 개의 URL을 눈으로 대조해야 하는 작업이다. 자동화가 빛을 발하는 지점이다.

여러 크롤러, 다른 규칙 — AI 봇 시대의 복잡성

robots.txt가 단순했던 시절은 지났다. 2010년대 초만 해도 User-agent: *에 전체 규칙을 적어두면 대부분의 검색엔진이 따랐다. 지금은 상황이 전혀 다르다.

Google Crawling Infrastructure 공식 문서에 따르면, Googlebot은 RFC 9309를 따르되 crawl-delay는 지원하지 않는다(Google Crawling Infrastructure, "How Google Interprets the robots.txt Specification"). Bing과 Yandex는 crawl-delay를 지원한다. Yandex는 crawl-delay를 "해당 시간 안에 1회만 접속"으로 해석하는데, 이 해석이 다른 엔진과 다르다(Yandex Webmaster 공식).

그리고 20232025년 사이에 급부상한 AI 학습 봇들. GPTBot(OpenAI), ClaudeBot(Anthropic), Google-Extended, PerplexityBot, Bytespider(TikTok) 등이 각자의 User-agent 이름으로 크롤링을 시작했다. 현재 major 뉴스 사이트와 대형 웹사이트의 3554%가 이런 AI 봇들을 robots.txt에서 차단하고 있다는 조사 결과도 있다(technologychecker.io, Cloudflare Network 분석, 2024; BuzzStream, 2025).

공공 사이트 입장에서 이 상황은 새로운 판단이 필요함을 의미한다. 검색 인덱싱 목적의 크롤링(Googlebot, Bingbot)은 허용하되, AI 학습 목적의 크롤링(GPTBot 등)에 대해서는 기관 정책에 따라 결정할 수 있다. 2025년 고시 개정에서 "합리적 범위의 부분 차단"을 허용한 것은, 이런 복잡한 현실을 반영한 것이기도 하다.

ViewCheck는 현재 주요 크롤러별 정책을 파악하는 수준까지 분석을 시도한다. Googlebot, Bingbot, GPTBot, Yandexbot, CCBot, Google-Extended 등 주요 User-agent를 인식하고, 각 크롤러에 대해 어떤 규칙이 적용되는지를 요약한다. 이 기능은 아직 개선 중이다. User-agent 이름의 변형(예: gpt-bot, GPTBot, OpenAI)을 모두 잡아내는 것, 새로 등장하는 봇들을 빠르게 목록에 추가하는 것이 계속되는 과제다.

크롤러마다 규칙이 다르다. 사이트 구조와 정책을 정확히 시각화하는 것이 개방성 진단의 첫걸음이다.

분석 결과가 대화로 펼쳐질 때 — SEO 카드 안의 개방성

ViewCheck LLM 분석에서 개방성 관련 결과는 주로 SEO 분석 카드에 담긴다. URL을 입력하면 24개의 분석 카드가 대화로 펼쳐지는데, 그중 SEO 카드는 다음 항목들을 포함한다.

메타 태그 (title, description, viewport, lang, canonical, robots meta)
Open Graph 태그 (og:title, og:description, og:image 등)
구조화 데이터 (JSON-LD, microdata)
헤딩 계층 (H1~H6)
이미지 alt 커버리지
robots.txt 분석 (개방성)
sitemap.xml 분석 (개방성)

robots.txt와 sitemap.xml 항목은 단순히 "있음/없음"이 아니라, 위에서 설명한 파싱 결과를 요약해 보여준다. 어떤 경로가 차단되어 있는지, sitemap.xml에 URL이 몇 개 있는지, lastmod 값의 신뢰도가 어떤지 같은 정보다.

채팅에서 이 항목에 대해 추가 질문을 할 수도 있다. "왜 개방성이 부분 차단으로 분류됐어?", "차단된 경로가 문제가 되는 건가?"라고 물으면, 분석 근거와 함께 KRDS 공식 문서나 Google Search Central 가이드를 참조패널에 띄워 답한다. 단순한 Yes/No 판정이 아니라, 판정 근거를 대화로 설명할 수 있는 구조다.

이 '근거 있는 대화'라는 방향성은, 우리가 이 시리즈에서 계속 강조해 온 원칙과 이어진다. AI가 판단한다고 해서, 그 판단을 맹신하면 안 된다. 판단 옆에 근거가 있어야 사용자가 직접 확인하고 판단할 수 있다.

실제 공공 사이트에서 발견한 패턴들

우리가 실제로 분석한 공공 사이트들에서 공통적으로 발견한 패턴을 몇 가지 정리한다. (구체적 기관명은 생략한다. 특정 기관을 지적하려는 게 아니라, 일반적 경향을 공유하려는 것이다.)

패턴 A: sitemap.xml이 아예 없는 경우

소규모 지방 기관 사이트에서 자주 보인다. 외주 개발사가 기본 구성을 하고 나서 sitemap.xml 생성을 별도로 다루지 않은 경우다. 없어도 사이트는 작동하지만, 검색엔진이 페이지를 발견하는 데 더 많은 시간이 걸린다. 특히 링크 구조가 복잡한 사이트나, 신규 개설 사이트에서 영향이 크다.

패턴 B: sitemap.xml은 있지만 lastmod가 무의미한 경우

sitemap.xml의 모든 URL에 동일한 <lastmod> 날짜가 박혀 있거나, CMS에서 자동 생성되었지만 lastmod가 "사이트맵 파일이 생성된 날짜"로 고정된 경우. 이 경우 Google은 lastmod 신호를 무시하고 직접 크롤링으로 판단한다. 사실상 lastmod가 없는 것과 같다.

패턴 C: robots.txt에 과도한 Disallow

리뉴얼 이전 경로(/old/, /2019/)와 현재 경로가 혼재해 있고, 리뉴얼 이전 차단 정책이 그대로 남아 있는 경우. 불필요하게 많은 경로가 차단되어 있지만, 실제로 그 경로로 접근을 시도하면 404가 뜬다. 즉, 없는 경로를 막고 있는 것이다. 관리가 안 된 흔적이다.

패턴 D: Sitemap 지시어 경로와 실제 파일 위치 불일치

robots.txt에는 /sitemap.xml이라고 적혀 있지만, 실제 파일은 /sitemap/index.xml에 있거나 존재하지 않는다. 이런 경우 크롤러가 robots.txt를 참조해 sitemap을 찾으려 했다가 실패한다. 수동으로 발견한다면 시간이 걸린다. ViewCheck는 몇 가지 관례적 경로를 순차 탐색해 파일을 찾고, robots.txt에 명시된 경로와 다를 경우 이를 표시한다.

패턴 E: AI 봇 정책이 없는 경우

2024년 이후 GPTBot 등 AI 봇에 대한 정책을 명시적으로 robots.txt에 적어두는 것이 현실적으로 의미 있는 시점이 됐다. 그러나 많은 공공 사이트의 robots.txt는 2020년 이전에 작성된 그대로고, AI 봇에 대한 언급이 없다. 허용인지 차단인지 의도가 불명확한 상태다. 고시 개정이 "합리적 부분 차단"을 허용하는 방향으로 간 만큼, 기관별로 AI 봇 정책을 의식적으로 수립하고 robots.txt에 반영하는 것이 앞으로 필요해질 것으로 보인다.

이런 패턴들은 모두 자동화된 파싱 없이는 일일이 손으로 확인해야 하는 것들이다. 사이트 하나에 담당자가 15~30분을 쓸 수 있다. 수십 개 사이트라면? 그 부담이 쌓이면 점검 자체가 형식적으로 흐른다. ViewCheck가 이 작업을 수 초 안에 처리하고 결과를 카드로 보여주는 것이, 실무에서의 실질적 가치라고 생각한다.

멀티 페이지 맥락에서의 개방성 진단

ViewCheck의 기본 철학은 "단일 페이지가 아니라 사이트 전체를 본다"는 것이다. robots.txt와 sitemap.xml은 사이트 전체에 하나씩 존재하는 파일이므로, 이 항목은 멀티 페이지 분석에서 사이트 단위로 1회만 진단하고 그 결과를 전체 분석에 반영한다.

중요한 건 이 결과가 다른 분석 결과와 교차 검증된다는 점이다. 예를 들어, 접근성 분석에서 특정 페이지 유형(신청 페이지, 검색 결과 페이지)의 규칙 위반이 많이 발견됐는데, 동시에 그 페이지 유형의 URL 패턴이 robots.txt에서 차단되어 있다면 — 이 두 정보는 함께 볼 때 더 의미 있다. 크롤러가 그 페이지를 못 보는 것이 의도된 것인지, 아니면 관리 소홀인지를 판단하는 데 도움이 된다.

또한 sitemap.xml에 등재된 URL과 실제 크롤링에서 발견된 URL을 비교하면, 사이트맵에 누락된 중요 페이지를 찾아낼 수 있다. 특히 동적으로 생성되는 신청 페이지나 게시물 상세 페이지는 sitemap.xml에 빠져 있는 경우가 많다. 이런 누락이 검색 노출에 영향을 준다.

이 교차 분석은 현재 ViewCheck에서 부분적으로 구현되어 있고, 더 정밀하게 다듬는 작업이 계속 진행 중이다. "개방성은 robots.txt와 sitemap.xml 파일 두 개만 보면 된다"는 단순한 접근에서, "개방성은 사이트의 전체 크롤링 가능성을 보는 것"이라는 더 넓은 시각으로 가는 여정이다.

행안부 지침의 개방성 기준 — 무엇을 보는가

행안부 「전자정부 웹사이트 품질관리 지침」에서 개방성 영역이 다루는 항목들을 정리해 두면 유용하다. 고시 본문과 함께 배포된 「전자정부 웹사이트 품질관리 가이드」에서 개방성은 크게 다음 항목들로 구성된다.

robots.txt 파일 제공 여부 — 파일의 존재와 접근 가능성
크롤링 정책의 타당성 — 차단 범위가 합리적 범위 내인지 (2025년 개정으로 부분 차단 허용)
sitemap.xml 파일 제공 여부 — 사이트맵의 존재와 접근 가능성
메타데이터 개방 — Open Graph, 구조화 데이터, 메타 description 등
RSS/Atom 피드 — 콘텐츠 개방성의 또 다른 측면

이 중 robots.txt와 sitemap.xml은 기술적 구현이 명확하고, 자동화된 확인이 가능한 항목이다. 나머지 메타데이터 항목도 ViewCheck SEO 카드에서 같이 다룬다. 이 글에서는 robots.txt와 sitemap.xml에 집중했지만, 실제 개방성 진단은 더 넓은 SEO 분석의 일부로 이루어진다.

2025년 고시 개정이 가져온 실질적 변화 중 하나는, 개방성 진단이 단순한 "있다/없다"의 이진법에서 "어떻게 열어놨는가"의 맥락 분석으로 진화해야 한다는 방향을 제시했다는 점이다. ViewCheck는 그 방향을 따라 개방성 진단 로직을 설계하고 있다.

개방성과 보안의 긴장 — "열려야 한다"와 "막아야 한다" 사이

개방성 영역에서 빠지지 않는 딜레마가 있다. "공공 사이트는 열려야 한다"는 원칙과, "공공 사이트는 보안이 중요하다"는 원칙이 충돌하는 지점이다.

robots.txt는 보안 수단이 아니다. 이 점을 Google도, RFC 9309도 명확히 한다. robots.txt는 "크롤러에게 요청하는 것"이지, "기술적으로 접근을 차단하는 것"이 아니다. 악의적인 봇은 robots.txt를 무시한다. 민감한 경로를 robots.txt로 차단했다고 해서 그 경로가 안전해지는 것은 아니다. 오히려 robots.txt에 민감 경로를 명시적으로 Disallow하면, 그 경로 자체를 공개하는 셈이 된다.

반면, sitemap.xml은 "크롤러에게 인덱싱을 요청하는 것"이다. 공개되어 있어야 할 페이지만 담아야 한다. 회원 전용 페이지, 임시 페이지, 개인정보가 포함된 결과 페이지 같은 것이 sitemap.xml에 들어가 있으면 곤란하다.

이 두 파일의 역할을 정확히 이해하고, 각각의 적절한 사용 방법을 따르는 것이 개방성과 보안을 동시에 챙기는 길이다. ViewCheck의 진단은 이 원칙을 기준으로 "개방성 차원에서 문제인 것"과 "보안 차원에서 문제인 것"을 구분하려 한다. 예를 들어, /admin/ 경로가 차단된 것을 개방성 위반으로 보지 않는다. 그러나 /board/notice/ 같은 공지사항 경로가 차단된 것은 다른 판정을 내린다.

이 구분이 항상 명확하지 않다는 것이 솔직한 고백이다. 경계선이 모호한 경로들이 있고, 기관마다 사정이 다르다. 완벽한 자동 판정보다는, "이 경로가 차단되어 있습니다, 의도된 것인지 확인하세요"라는 플래그를 세우고 판단을 담당자에게 넘기는 것이 현재 우리의 접근이다.

"개방성이 좋은 사이트"는 어떻게 생겼나 — 이상적인 설정의 예

말만 하면 와닿지 않으니, 이상적인 설정의 형태를 예시로 보여주겠다. 물론 모든 사이트에 똑같이 적용되는 "정답"은 없다. 하나의 참고 예시다.

이상적인 robots.txt (공공 사이트 예시)

# 검색엔진 크롤러 — 허용
User-agent: Googlebot
Allow: /

User-agent: Bingbot
Allow: /

# AI 학습 크롤러 — 기관 정책에 따라 결정
User-agent: GPTBot
Disallow: /

User-agent: CCBot
Disallow: /

# 모든 크롤러 — 관리 경로 차단
User-agent: *
Disallow: /admin/
Disallow: /wp-admin/
Disallow: /private/
Disallow: /temp/
Allow: /

# 사이트맵 위치 안내
Sitemap: https://www.example.go.kr/sitemap.xml

이 예시가 보여주는 것들:

주요 검색엔진을 개별 지정해 명시적으로 허용
AI 봇에 대해 기관 정책을 명확히 표현
모든 봇에 대해 관리 경로만 차단하고 나머지는 허용
Sitemap 지시어로 사이트맵 위치 안내

이상적인 sitemap.xml (간략한 구조)

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.go.kr/</loc>
    <lastmod>2025-06-01</lastmod>
  </url>
  <url>
    <loc>https://www.example.go.kr/board/notice/</loc>
    <lastmod>2025-06-15</lastmod>
  </url>
  <!-- 중요 페이지들... -->
</urlset>

실제로는 수십~수천 개의 URL이 담기고, 대형 사이트는 sitemap index 구조를 쓴다. 그러나 원칙은 단순하다. 중요하고 공개되어야 할 URL만 담고, lastmod는 실제 수정일을 정확하게 반영한다.

벽에 붙은 사이트 트리를 검토하는 전문가. 이상적인 개방성 설정은 사이트 구조를 명확히 파악한 다음에야 가능하다.

진단 결과를 보는 방법 — 어떤 항목에 주목할 것인가

ViewCheck의 SEO/개방성 카드를 처음 받아보는 담당자라면, 어디에 먼저 눈을 돌려야 할지 정리해 본다.

우선 확인 항목

robots.txt HTTP 상태: 200이 아닌 경우(404, 403, 타임아웃) 먼저 파악.
전체 차단 여부: Disallow: / 또는 이에 준하는 설정이 있는지.
sitemap.xml 존재 여부: 파일이 있고 접근 가능한지.
sitemap.xml URL 수: 사이트 규모에 비해 현저히 적으면 누락 의심.

다음 확인 항목

Sitemap 지시어: robots.txt에 Sitemap 경로가 명시되어 있는지, 그 경로가 실제와 일치하는지.
lastmod 유효성: 날짜 형식과 신뢰도.
robots.txt와 sitemap.xml의 URL 교차 불일치: 사이트맵에 있는데 차단된 URL.

선택적 확인 항목

AI 봇 정책: GPTBot 등에 대한 명시적 정책 유무. 기관 정책이 수립되어 있는 경우.
Crawl-delay 설정: 서버 부하 이슈가 있을 때만 설정, Google에는 효과 없음을 감안.

모든 항목이 완벽한 사이트는 거의 없다. 중요한 건 어떤 항목이 실제 영향을 미치는지를 파악하고 우선순위를 잡는 것이다. 전체 차단 설정은 즉시 수정해야 하고, lastmod 날짜 형식 문제는 여유 있게 다뤄도 된다.

자동 진단의 한계와 우리가 아직 못 하는 것

솔직하게 이야기하자. 지금 ViewCheck의 개방성 진단이 완벽하지 않다.

아직 잘 못 하는 것들:

robots.txt가 서버사이드에서 동적 생성되는 경우: 어떤 사이트는 사용자 에이전트에 따라 다른 robots.txt를 반환한다. ViewCheck가 보내는 요청과 Googlebot이 보내는 요청에 다른 내용이 올 수 있다. 이런 차이를 탐지하기가 쉽지 않다.
sitemap.xml URL의 실제 상태 확인: sitemap.xml에 담긴 URL들이 실제로 200을 반환하는지 전수 확인하는 것은 URL이 수천 개일 때 시간과 비용이 많이 든다. 현재는 샘플링 방식으로 일부만 확인한다.
다국어 sitemap: hreflang 태그를 사용한 다국어 사이트의 sitemap.xml 구조는 더 복잡하다. 아직 이 부분의 파싱이 완전하지 않다.
동적 sitemap 생성 확인: CMS가 sitemap을 실시간 생성하는 경우, 요청 시마다 다른 내용이 올 수 있다. 캐시된 결과를 보는 것인지, 실시간 결과인지 구분이 어렵다.
sitemap.xml과 실제 사이트 구조의 완전한 비교: ViewCheck가 크롤링하면서 발견한 URL과 sitemap.xml의 URL을 1:1로 매핑해 누락을 찾는 것은, 크롤링 깊이와 범위가 항상 달라서 완전한 비교가 어렵다.

이런 한계를 솔직하게 적는 이유는, 진단 결과를 읽을 때 "이걸로 다 알 수 있다"가 아니라 "이 결과를 출발점으로 삼아 담당자가 추가로 확인한다"는 태도가 맞기 때문이다. 도구가 모든 것을 해결해 주는 게 아니라, 도구가 빠르게 훑어보고 주목할 곳을 짚어주면 사람이 거기서부터 깊이 파고드는 것이 건강한 사용법이다.

다른 크롤러와 AI 봇의 공존 — 2025~2026년의 새로운 과제

마지막으로 조금 더 큰 맥락 이야기를 해보자.

robots.txt는 "신사 협정"이다. 따르는 것은 각 크롤러의 선택이다. 제대로 된 크롤러들(Googlebot, Bingbot 등 주요 검색엔진)은 이 파일을 잘 따른다. 하지만 RFC 9309는 명확히 말한다 — "Crawlers SHOULD follow the instructions, but are not legally required to." (크롤러는 지시를 따르는 것이 좋지만, 법적 의무는 아니다.)

이 말이 의미하는 바는, robots.txt가 악의적 스크래퍼나 규정을 무시하는 AI 학습 봇을 막는 기술적 수단은 아니라는 것이다. 그럼에도 robots.txt에 명시적 의사를 표현해 두는 것은 의미 있다. 법적 근거를 마련하는 데 도움이 되고(명시적 거부 의사가 있었음을 증명), 선의의 크롤러들이 그 의사를 존중하도록 안내할 수 있다.

공공 사이트 운영자들이 앞으로 robots.txt에서 신경 써야 할 것들이 늘었다. 검색 인덱싱, AI 학습, 공공 데이터 활용 크롤링 등 목적이 다양해졌고, 이에 따라 크롤러 종류도 급증했다. 이 복잡성을 손으로 관리하기 어려워진 만큼, 현황을 빠르게 파악하고 정책 검토가 필요한 항목을 짚어주는 자동 진단의 가치가 더 커졌다.

ViewCheck가 이 분야에서 완성된 솔루션을 갖고 있다고 말하기는 어렵다. 솔직히 말하면, 크롤러 생태계는 지금도 빠르게 변화하고 있고 우리도 따라가는 중이다. 다만 방향은 분명하다 — 단순한 "있음/없음" 체크에서 "내용과 맥락을 파악하는 진단"으로, 그리고 "새로운 크롤러 환경 변화를 반영하는 지속적 업데이트"로.

마무리 — "열려 있다"는 말의 기술적 무게

'개방성'이라는 단어는 쉽게 쓰인다. "우리 사이트는 열려 있습니다"라고 말하는 기관은 많다. 그러나 검색엔진과 크롤러에게 실제로 열려 있는지는, robots.txt 몇 줄과 sitemap.xml 하나가 결정한다.

그 파일들이 없거나, 있어도 잘못 작성되어 있거나, 형식만 갖추고 내용이 엉터리라면 — 아무리 훌륭한 콘텐츠도 검색엔진의 눈에 보이지 않는다. 시민이 검색으로 서비스를 찾지 못한다. '열려 있다'는 말이 기술적으로는 닫혀 있는 상태를 감추는 것이다.

2025년 고시 개정은 그 "열려야 한다"는 원칙을 더 현실적으로 다듬었다. 합리적 범위에서의 부분 차단을 허용하고, AI 봇이라는 새로운 변수를 반영할 공간을 만들었다. 이제 문제는 "얼마나 열어야 하는가"가 아니라 "무엇을, 누구에게, 왜 열고 막는지를 명확하게 표현하는가"다.

ViewCheck의 개방성 진단은 그 "명확한 표현"이 현재 어떤 상태인지를 빠르게 읽어주려는 시도다. 여기서 다룬 것들 — robots.txt 내용 파싱, sitemap.xml 구조 분석, 두 파일의 교차 검증 — 은 그 시도의 현재 모습이다. 아직 부족한 점이 있고, 계속 다듬는 중이다. 이 글이 그 여정을 조금 더 구체적으로 보여줬기를 바란다.

다음 편에서는 접속성 — 응답 시간, TTFB, SSL 인증서 상태, 네트워크 지연 분해 — 을 다룰 예정이다. 개방성이 "크롤러에게 열려 있는가"였다면, 접속성은 "사용자와 시스템에게 안정적으로 연결되는가"다. 또 다른 측정의 세계로 들어가 보자.

크롤러의 시선은 디렉토리 목록 하나하나를 검사한다. 자동 진단은 그 시선을 흉내 내고, 문제 있는 곳에 표시를 남긴다.

참고문헌

본문에 인용한 출처는 작성 시점에 모두 실재 여부를 직접 검색·검증했다. 국내 공식 기준과 해외 기술 표준 및 연구를 함께 실었다.

국내 — 공식 기준 / 정책자료

행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025년 6월 25일 일부개정 시행). 국가법령정보센터. https://www.law.go.kr/행정규칙/전자정부웹사이트품질관리지침
행정안전부, 「전자정부 웹사이트 품질관리 지침」 일부 개정 및 「전자정부 웹사이트 품질관리 가이드」 수정본 안내 (고시 제2025-46호). 행정안전부 법령정보. https://www.mois.go.kr/frt/bbs/type001/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000016&nttId=118636
서울특별시 정보소통광장, 「전자정부 웹사이트 품질관리 지침」 일부 개정 관련 결재문서 (개방성 기준 완화 확인). https://opengov.seoul.go.kr/sanction/33892320
어센트 코리아, "Robots.txt와 Sitemap.xml 제대로 설정하기". https://www.ascentkorea.com/what-is-robots-txt-sitemap-xml/

해외 — 기술 표준 / 공식 문서

IETF (Internet Engineering Task Force), RFC 9309 — Robots Exclusion Protocol, September 2022. RFC Editor. https://www.rfc-editor.org/info/rfc9309/
sitemaps.org, Sitemap Protocol Specification (공식 사양, Google·Yahoo·Microsoft 공동). https://www.sitemaps.org/PROTOCOL.HTML
Google Search Central, "Robots.txt Introduction and Guide". Google for Developers. https://developers.google.com/search/docs/crawling-indexing/robots/intro
Google Search Central, "Build and Submit a Sitemap". Google for Developers. https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap
Google Crawling Infrastructure, "How Google Interprets the robots.txt Specification". Google for Developers. https://developers.google.com/crawling/docs/robots-txt/robots-txt-spec
Yandex Webmaster, "Using robots.txt". https://yandex.com/support/webmaster/en/controlling-robot/robots-txt
technologychecker.io, "We Analyzed robots.txt Across Cloudflare's Network" (AI 봇 차단 현황 분석, 2024). https://technologychecker.io/blog/robots-txt-ai-crawlers-blocking-report
BuzzStream, "Which News Sites Block AI Crawlers in 2025?" (뉴스 사이트 AI 봇 차단 현황, 2025). https://www.buzzstream.com/blog/publishers-block-ai-study/
Straightnorth, "XML Sitemaps & Robots.txt: How to Guide Search Engines Effectively". https://www.straightnorth.com/blog/xml-sitemaps-and-robots-txt-how-to-guide-search-engines-effectively/
Yoast, "The ultimate guide to robots.txt". https://yoast.com/ultimate-guide-robots-txt/

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

025편 : [접근성연구·모바일] 햄버거 뒤에 숨은 길

ViewCheck — Thu, 24 Sep 2026 16:27:44 +0900

025편 : [접근성연구·모바일] 햄버거 뒤에 숨은 길

모바일 내비게이션 연구

〈디지털 접근성 연구 025〉 — 이 글은 규정이 아니라 하나의 연구 관점입니다. 인용 수치·기준은 출처와 함께, 미확정 영역은 그렇다고 밝혀 작성합니다.

들어가며

데스크탑에서 웹사이트의 메뉴는 보통 상단에 펼쳐져 있다. 어디로 갈 수 있는지가 한눈에 보인다. 그런데 같은 사이트를 휴대폰으로 열면, 그 메뉴가 사라진다. 대신 상단 모서리에 가로줄 세 개가 쌓인 작은 아이콘 하나가 놓인다. 흔히 '햄버거 메뉴'라 불리는 이 아이콘을 눌러야, 접혀 있던 메뉴가 옆에서 미끄러져 나온다.

이것은 좁은 화면에 많은 메뉴를 담기 위한 합리적 타협이다. 화면이 좁으니 메뉴를 평소엔 숨겨두고, 필요할 때 펼치게 한 것이다. 그런데 이 타협에는 대가가 따른다. 메뉴가 '보이는 것'에서 '찾아서 열어야 하는 것'으로 바뀌면서, 길을 찾는 일이 한 단계 더 복잡해진다. 어디로 갈 수 있는지가 더 이상 한눈에 보이지 않는다.

이번 편은 '모바일 내비게이션', 그중에서도 햄버거 메뉴로 대표되는 '접힌 메뉴'를 기준 연구의 관점에서 다룬다. 메뉴를 숨기는 것이 어떤 문제를 낳는지, 무엇이 보존되어야 하는지, 표준은 무엇을 말하는지를 정리한다.

1. 메뉴를 숨긴다는 것의 의미

내비게이션은 사용자가 '어디에 무엇이 있는지'를 알고 그곳으로 이동하게 돕는 길잡이다. 데스크탑의 펼쳐진 메뉴는 이 길잡이를 늘 보이게 둔다. 사용자는 메뉴 항목들을 훑어보며 사이트의 전체 구조를 짐작하고, 가고 싶은 곳을 고른다. 메뉴 자체가 사이트의 '지도' 역할을 한다.

햄버거 메뉴는 이 지도를 접어 서랍 안에 넣는다. 서랍을 열기 전까지 사용자는 어디로 갈 수 있는지 알 수 없다. 이 변화에는 두 가지 비용이 따른다. 첫째는 '발견 비용'이다. 사용자가 메뉴가 거기 숨어 있다는 것을 알아채고, 아이콘을 찾아 눌러야 한다. 둘째는 '조망 비용'이다. 서랍을 열어도 한 번에 보이는 항목 수가 제한되어, 데스크탑처럼 전체 구조를 한눈에 조망하기 어렵다.

이 비용들은 익숙한 사용자에게는 거의 0에 가깝다. 햄버거 아이콘이 메뉴라는 것을 이미 알기 때문이다. 그러나 모든 사용자가 익숙한 것은 아니다. 디지털에 덜 익숙한 사람, 처음 그 사이트를 쓰는 사람에게는 이 비용이 실제 장벽이 된다.

두 비용을 데스크탑의 펼친 메뉴와 견주면 차이가 선명해진다.

단계	데스크탑(펼친 메뉴)	모바일(접은 메뉴)	익숙한 사용자	관습 바깥 사용자
메뉴 존재 인지	항상 보임 — 비용 0	아이콘을 메뉴로 알아채야 함	거의 0	높음(아이콘 의미 모름)
발견(열기)	불필요	아이콘을 찾아 눌러야 함	낮음	높음(위치·정체 불확실)
조망(전체 구조)	한눈에 훑음	서랍 안에서 다시 스크롤	낮음	높음(구조 파악 지연)
목표 항목 도달	바로 클릭	열기→스크롤→선택	낮음	높음(중간 이탈 가능)

(관점) 표의 오른쪽 두 열은 '같은 메뉴'가 사용자에 따라 다른 비용으로 다가옴을 보여준다. 점검에서 보는 것은 왼쪽 두 칸의 합이 아니라, 가장 비용이 큰 칸이 누구에게 어디서 생기는가다.

1-1. '관습'에 기댄 약속의 한계

햄버거 아이콘이 메뉴를 뜻한다는 것은 명문화된 규칙이 아니라 널리 퍼진 관습이다. 관습은 익숙한 사람에게는 효율적이지만, 그 관습을 모르는 사람에게는 아무 단서가 되지 못한다. 가로줄 세 개가 왜 메뉴인지는 직관적으로 자명하지 않다. 그래서 아이콘 옆에 '메뉴'라는 글자를 함께 두거나, 아이콘이 메뉴임을 보조 기술(화면 낭독기 등)이 읽을 수 있게 이름을 붙이는 것이 권장된다. 관습에만 기대면, 관습 바깥의 사용자를 배제하게 된다.

2. 무엇이 보존되어야 하나 — 접어도 잃지 말아야 할 것

메뉴를 접는 것 자체는 문제가 아니다. 좁은 화면에서는 합리적 선택이다. 핵심은 '접으면서 무엇을 잃지 않는가'다. 기준 연구의 관점에서 보존되어야 할 것들을 정리하면 다음과 같다.

항목의 완전성. 데스크탑 메뉴에 있던 항목이 모바일 메뉴(햄버거 서랍 안)에도 모두 있어야 한다. 접는 과정에서 일부 항목이 빠지면, 모바일 사용자는 데스크탑 사용자가 갈 수 있는 곳에 갈 수 없게 된다. 같은 사이트인데 화면에 따라 갈 수 있는 곳이 달라진다.

열고 닫음의 명확성. 사용자가 메뉴를 열 수 있고, 또 닫을 수 있어야 한다. 열린 메뉴를 닫는 방법(닫기 버튼, 바깥 영역 누르기 등)이 분명해야, 사용자가 메뉴에 갇히지 않는다.

조작 가능성. 메뉴를 마우스뿐 아니라 키보드로도 열고, 항목 사이를 이동하고, 선택할 수 있어야 한다. 보조 기술 사용자에게도 메뉴가 '메뉴'로 인식되고 조작 가능해야 한다.

현재 위치의 단서. 가능하다면 사용자가 지금 어느 항목에 있는지(현재 페이지 표시)가 메뉴에 드러나면, 길을 잃을 가능성이 줄어든다.

이 네 가지를 '접으면서 잃기 쉬운 것'과 짝지으면, 무엇을 점검해야 할지가 분명해진다.

보존할 것	잃었을 때의 증상	누가 먼저 막히나	점검 단서
항목의 완전성	데스크탑에 있던 메뉴가 모바일 서랍에 없음	모든 모바일 사용자	양쪽 메뉴 항목 수 대조
열고 닫음의 명확성	메뉴를 닫지 못해 화면이 갇힘	처음 쓰는 사용자	닫기 버튼·바깥 누름 작동
조작 가능성	키보드·보조 기술로 못 열거나 못 넘어감	키보드·낭독기 사용자	키보드만으로 열기→이동→닫기
현재 위치 단서	지금 어디인지 알 수 없어 반복 이동	길 찾기 약한 사용자	현재 항목 강조 표시 유무

(관점) '메뉴를 접었는가'는 점검 항목이 아니다. 점검 항목은 '접은 뒤에도 이 네 가지가 살아 있는가'다. 네 줄 중 하나라도 무너지면, 접힘은 타협이 아니라 손실이 된다.

2-1. '보이지 않음'과 '없음'의 경계

햄버거 메뉴의 근본 긴장은 '보이지 않는 것'과 '없는 것'이 사용자에게 비슷하게 느껴진다는 데 있다. 메뉴가 서랍 안에 있어도, 그것을 찾지 못한 사용자에게는 메뉴가 없는 것과 같다. 그래서 메뉴를 접을 때는 '여기에 메뉴가 있다'는 신호를 충분히 주는 것이 중요하다. 아이콘의 위치, 크기, 레이블이 그 신호다. 신호가 약하면 보이지 않는 메뉴는 없는 메뉴가 된다.

3. 표준은 무엇을 말하나 — 인식·조작·일관성

모바일 내비게이션과 맞닿는 접근성 기준은 여러 항목에 걸쳐 있다. 웹 콘텐츠 접근성 지침(WCAG)과 한국형 웹 콘텐츠 접근성 지침(KWCAG)이 가리키는 방향을 모으면 대략 세 갈래다.

첫째, 메뉴를 여는 아이콘 같은 컨트롤은 그것이 무엇인지 인식될 수 있어야 한다. 아이콘만 있고 이름이 없으면, 화면 낭독기를 쓰는 사용자는 그것이 메뉴 버튼인지 알 수 없다. 이름(레이블)을 부여하는 것이 권장되는 이유다. 둘째, 메뉴는 마우스뿐 아니라 키보드로도 조작 가능해야 한다. 열고, 이동하고, 선택하고, 닫는 모든 동작이 키보드로 가능해야 한다. 셋째, 같은 사이트 안에서 내비게이션의 위치와 방식이 일관되어야, 사용자가 페이지마다 길 찾는 법을 새로 배우지 않아도 된다.

이 항목들의 정확한 번호·등급은 지침 원문과 공공 디자인 기준(KRDS)의 내비게이션 관련 문서에서 확인하는 것이 안전하다. 이 글은 특정 항목의 충족 여부를 단정하기보다, 표준이 공통으로 가리키는 '인식·조작·일관성'의 방향을 정리하는 데 목적이 있다.

세 갈래를 표준 항목과 느슨하게 잇고, 햄버거 메뉴에 적용하면 다음과 같다.

방향	표준이 가리키는 항목(참고)	햄버거 메뉴에서의 의미	어긋날 때
인식	Name, Role, Value(4.1.2)	아이콘에 '메뉴'라는 이름이 붙어 있음	낭독기가 "버튼"으로만 읽어 정체 불명
조작	Keyboard(2.1.1)	키보드로 열기·이동·선택·닫기 가능	키보드 사용자가 서랍에 진입 불가
일관성	Consistent Navigation(3.2.3)	모든 페이지에서 같은 위치·방식	페이지마다 메뉴 위치가 달라 재학습

(인용) 위 항목 번호는 WCAG 2.1 기준의 참고 표기이며, 정확한 등급·충족 조건은 원문과 KWCAG·KRDS 문서에서 확인해야 한다. 이 표는 '단정'이 아니라 '방향의 지도'다.

3-1. 키보드와 보조 기술 관점의 중요성

햄버거 메뉴는 시각적으로만 보면 '아이콘을 누르면 서랍이 열리는' 단순한 구조다. 그러나 키보드만 쓰는 사용자나 화면 낭독기를 쓰는 사용자의 관점에서는 그렇지 않다. 아이콘에 이름이 없으면 무엇인지 알 수 없고, 키보드로 열 수 없으면 메뉴에 들어갈 수 없으며, 열린 메뉴의 항목 사이를 키보드로 이동할 수 없으면 그 안에서 길을 잃는다. 모바일 내비게이션 연구에서 이 관점을 빠뜨리면, 시각적으로만 '괜찮은' 메뉴가 실제로는 일부 사용자에게 닫혀 있을 수 있다.

4. 관찰 — 접힌 메뉴의 장면들

공공 영역의 여러 화면을 모바일에서 열어 내비게이션을 살펴본 관찰을, 익명으로 정리한다.

한 장면에서는 데스크탑 상단에 펼쳐져 있던 여러 안내 메뉴가 모바일에서 햄버거 서랍 안으로 들어갔는데, 데스크탑에 있던 일부 항목이 서랍 안에서 보이지 않았다. 접는 과정에서 누락된 것으로 보였고, 그 항목으로 가는 길이 모바일에서는 막혀 있었다. 다른 장면에서는 서랍을 열었더니 항목이 매우 많아 한 화면에 다 들어오지 않았고, 그 안을 다시 스크롤해야 원하는 항목에 닿았다. 메뉴를 열고도 길 찾기가 끝나지 않았다.

또 다른 장면에서는 메뉴를 여는 아이콘이 화면 구석에 작게 놓여, 처음 쓰는 사용자가 그것이 메뉴라는 것을 알아채기 어려워 보였다. 아이콘 옆에 '메뉴'라는 글자가 함께 있었다면 발견이 쉬웠을 것이다. 이 장면들의 공통점은 '메뉴가 있긴 있다'는 것이다. 다만 그 메뉴에 닿는 길이 누락되었거나, 길어졌거나, 잘 보이지 않았다.

관찰한 장면들을 익명으로 묶으면 다음과 같다.

관찰된 장면	데스크탑	모바일	닿지 못한 결과
항목 누락	상단에 안내 메뉴 여러 개	서랍 안에 일부 항목 없음	그 페이지로 가는 길 차단
과다 항목	한눈에 훑던 메뉴	서랍이 길어 다시 스크롤	열고도 길 찾기 미완
약한 신호	메뉴가 늘 보임	작은 아이콘만, 레이블 없음	처음 쓰는 사용자가 못 찾음

(관찰) 위 장면들은 특정 기관을 지목하지 않은 익명 관찰이며, 같은 사이트라도 점검 시점·기기·해상도에 따라 다르게 나타날 수 있다. 공통점은 '메뉴가 없지 않은데, 그 메뉴에 닿는 길이 가늘어졌다'는 것이다.

4-1. 길을 못 찾으면 '없는 기능'이 된다

내비게이션의 문제는 결국 '닿지 못함'으로 귀결된다. 어떤 페이지에 좋은 기능이 있어도, 그곳으로 가는 메뉴 항목을 사용자가 찾지 못하면 그 기능은 없는 것과 같다. 데스크탑에서는 메뉴가 펼쳐져 있어 쉽게 찾던 항목이, 모바일에서 서랍 안 깊숙이 들어가거나 아예 누락되면, 모바일 사용자에게 그 길은 사라진다. 모바일 내비게이션 연구가 '메뉴의 모양'이 아니라 '길의 보존'에 초점을 두는 이유다.

5. 점검의 관점 — 길이 보존되었는가

모바일 내비게이션을 점검 관점으로 옮기면 다음 질문들로 정리된다.

데스크탑 메뉴에 있던 항목이 모바일 메뉴에도 모두 있는가. 메뉴를 여는 아이콘을 처음 쓰는 사용자도 쉽게 찾을 수 있는가(레이블·위치·크기). 메뉴를 마우스뿐 아니라 키보드로도 열고, 이동하고, 선택하고, 닫을 수 있는가. 열린 메뉴를 닫는 방법이 분명한가. 같은 사이트 안에서 내비게이션 방식이 페이지마다 일관되는가. 화면 낭독기가 그 아이콘을 '메뉴'로 읽고, 메뉴의 항목들을 읽어주는가.

이 질문들은 모두 '데스크탑에서 닿던 길이 모바일에서도 보존되는가'라는 하나의 기준에서 갈라져 나온다. 메뉴가 접혔다는 사실 자체가 아니라, 접힌 뒤에도 길이 끝까지 살아 있는가를 본다.

질문들을 점검 항목으로 정리하면 다음과 같다.

점검 질문	보는 것	막혔을 때 신호
항목이 모두 옮겨졌는가	데스크탑↔모바일 메뉴 항목 대조	모바일에서만 사라진 항목
아이콘을 쉽게 찾는가	레이블·위치·크기	작고 이름 없는 아이콘
키보드로 전 과정 가능한가	열기→이동→선택→닫기	서랍 진입·이탈 불가
닫는 법이 분명한가	닫기 버튼·바깥 누름	메뉴에 갇힘
페이지마다 일관되는가	위치·방식 동일성	페이지별 재학습 강요
낭독기가 '메뉴'로 읽는가	역할·이름 노출	"버튼"으로만 읽힘

(관점) 표의 어느 행도 '햄버거를 쓰지 말라'고 말하지 않는다. 모두 '접은 뒤의 길'을 본다. 점검은 디자인 취향이 아니라 길의 생존을 검사한다.

5-1. '익숙한 나'를 넘어선 점검

점검할 때 익숙한 사용자의 손으로만 하면, 햄버거 메뉴의 문제는 거의 드러나지 않는다. 이미 아이콘이 메뉴인 줄 알고, 어디를 눌러 닫는지 알기 때문이다. 그래서 '이 아이콘이 메뉴인 줄 모르는 사람', '키보드만 쓰는 사람', '화면 낭독기로 듣는 사람'의 관점을 의식적으로 빌려와야 한다. 모바일 내비게이션의 장벽은 가장 익숙한 사용자가 아니라, 그 관습과 도구 바깥의 사용자에게서 드러난다.

5-2. 반론과 한계

이 관점에는 반론과 스스로 인정할 한계가 있다.

반론·한계	내용	이 글의 입장
"햄버거는 이미 보편 관습"	대다수가 아이콘=메뉴를 안다	다수가 안다고 소수의 막힘이 사라지진 않음 — 레이블은 비용이 낮다
"좁은 화면엔 접기 외 대안이 없다"	공간 제약은 현실	접기는 인정. 다만 접은 뒤 길 보존이 조건
정적 점검의 한계	열고 닫는 동작은 실제 조작해야 보임	키보드·낭독기 실사용 점검을 자동 점검이 대체 못 함
항목 누락 판정의 어려움	'의도된 생략'과 '실수 누락'의 구분	양쪽 메뉴 대조는 가능하나 의도 판단은 사람 몫

(관점) 한계를 적는 이유는 이 연구가 '정답표'가 아니라 '관점'임을 분명히 하기 위해서다. 햄버거 메뉴 자체를 단죄하지 않는다. 보는 것은 접힌 뒤의 길이다.

5-3. ViewCheck의 관점 — 사람과 도구의 분담

내비게이션 점검은 자동 도구가 보는 영역과 사람이 보는 영역이 갈린다.

점검 항목	자동 점검이 보는 것	사람이 봐야 하는 것
아이콘 레이블	이름(접근 가능한 이름) 존재 여부	그 이름이 '메뉴'로 자연스럽게 읽히는지
키보드 조작	포커스 이동 가능 여부 신호	실제 열기→이동→닫기 흐름의 매끄러움
항목 완전성	데스크탑·모바일 메뉴 항목 수 대조	빠진 항목이 의도인지 누락인지
일관성	페이지 간 메뉴 구조 동일성	사용자가 길을 재학습하지 않는지
현재 위치 단서	현재 항목 표시 속성 유무	그 표시가 사용자에게 실제로 읽히는지

(관점) 자동 점검은 '신호의 유무'를 빠르게 훑고, 사람은 '그 신호가 길로 이어지는가'를 본다. ViewCheck는 둘을 합쳐, 접힌 메뉴 뒤에 길이 끝까지 살아 있는지를 확인하는 관점에 선다.

6. 한 장 요약

구분	핵심
햄버거 메뉴	좁은 화면을 위해 메뉴를 접은 합리적 타협
따르는 비용	발견 비용(찾아 눌러야)·조망 비용(전체 구조 안 보임)
관습의 한계	가로줄 세 개=메뉴는 관습일 뿐, 모르는 사람에겐 단서 없음
보존할 것	항목 완전성·열고 닫음·키보드 조작·현재 위치 단서
표준 방향	인식(레이블)·조작(키보드)·일관성 (항목·등급은 원문 확인)
핵심 위험	'보이지 않음'이 '없음'이 되는 것
점검 핵심	데스크탑의 길이 모바일에 보존되는가, 관습 바깥 사용자 관점

맺으며

햄버거 메뉴는 좁은 화면을 위한 합리적 선택이지만, 메뉴를 '보이는 것'에서 '찾아 열어야 하는 것'으로 바꾸면서 길 찾기에 비용을 더한다. 그 비용은 익숙한 사용자에게는 거의 없지만, 관습 바깥의 사용자, 키보드·보조 기술 사용자에게는 실제 장벽이 된다. 그래서 핵심은 메뉴를 접는가가 아니라, 접은 뒤에도 데스크탑에서 닿던 길이 끝까지 보존되는가다.

우리는 모바일 내비게이션을 '메뉴의 디자인'이 아니라 '길의 보존'으로 본다. 항목이 빠지지 않고, 누구나 메뉴를 찾아 열 수 있고, 키보드와 보조 기술로도 조작되며, 사이트 전체에서 일관될 때, 접힌 메뉴는 길을 숨기는 것이 아니라 효율적으로 담아두는 것이 된다. 다음 편에서는 이 길 찾기가 실패하는 순간, 즉 '메뉴를 못 찾는 순간'을 점검의 시선으로 더 좁혀 다룬다.

다음 편 예고 (026): 〈메뉴를 못 찾는 순간 / 모바일 탐색 점검 관점〉 — 사용자가 모바일에서 길을 잃는 구체적 순간들을 모아, 점검에서 그 막힘을 어떻게 재현하고 찾아낼지 다룬다.

참고한 공개 자료(출처):

W3C, Web Content Accessibility Guidelines (WCAG) 2.1 — Name, Role, Value(4.1.2), Keyboard(2.1.1), Consistent Navigation(3.2.3) 등 (정확한 항목·등급은 원문 확인 권장)
한국지능정보사회진흥원(NIA), 한국형 웹 콘텐츠 접근성 지침(KWCAG) 2.x — 키보드 접근·일관성 관련 항목
행정안전부·디지털플랫폼정부, KRDS(공공 디자인 시스템) 내비게이션·헤더 관련 공개 문서
MDN Web Docs — Navigation, ARIA menu/button patterns, Keyboard navigation 개요

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

042편 : 글자 밑줄을 텍스트 링크에만 사용하고, 강조하는 부분에서 사용하지 않고 있다.

ViewCheck — Thu, 24 Sep 2026 14:00:56 +0900

042편 : 글자 밑줄을 텍스트 링크에만 사용하고, 강조하는 부분에서 사용하지 않고 있다.

KRDS 체크리스트 항목 DS-042 · 디자인 스타일 > 타이포그래피 〈846 규칙 완전 분해 시리즈 ㊷〉 — "밑줄은 '누를 수 있다'는 약속이다": 신호를 지키는 절제

0. 들어가며 — 타이포그래피의 마침표

타이포그래피 16개 규칙(027~042)의 마지막입니다. 그리고 이 마지막 규칙은 작지만 중요한 약속에 관한 것입니다 — 밑줄(underline)의 용도.

DS-042는 밑줄을 텍스트 링크에만 쓰고, 강조에는 쓰지 말라고 규정합니다. 무언가를 강조하고 싶을 때 밑줄을 긋는 건 흔한 습관인데, 왜 하지 말라고 할까요? 답은 하나 — 밑줄은 '여기를 누를 수 있다'는 약속 이기 때문입니다. 그 약속을 강조용으로 남용하면, 사용자가 누를 수 없는 것을 링크로 착각합니다. 이번 편은 밑줄이라는 작은 신호를 지키는 절제의 의미를 풀어내며, 타이포그래피를 마무리합니다.

1. 규칙 원문 — 밑줄의 전용 용도

DS-042 (디자인 스타일 > 타이포그래피) "글자 밑줄을 ① 텍스트 링크에만 사용하고, ② 강조하는 부분에서 사용하지 않고 있다."

① "텍스트 링크에만 사용"

밑줄은 링크를 표시하는 데만 쓰라는 뜻입니다. 본문 속 클릭 가능한 텍스트 링크에 밑줄을 긋는 것이죠.

② "강조하는 부분에서 사용하지 않고"

강조하고 싶은 단어·문구에는 밑줄을 쓰지 말라는 뜻입니다. 강조는 두께(Bold)나 색으로 하되, 밑줄로는 하지 말라는 것이죠.

정리: 밑줄은 링크 전용 — 강조에는 쓰지 말라. 이게 DS-042입니다.

2. 왜 밑줄은 링크 전용인가 — 신호의 일관성

밑줄을 링크에만 써야 하는 이유는 '신호의 일관성' 입니다.

웹에서 밑줄은 오랫동안 '링크'를 뜻하는 관습적 신호였습니다. 사용자는 밑줄 친 텍스트를 보면 '아, 누를 수 있구나'라고 학습되어 있죠. 이 학습된 약속이 일관되게 지켜지면, 사용자는 밑줄만 보고도 링크를 즉시 알아 봅니다. 별도 설명 없이도요.

그런데 강조하려고 밑줄을 쓰면 이 약속이 깨집니다. 누를 수 없는 강조 단어에 밑줄이 있으면, 사용자는 그걸 링크로 착각해 누르려 합니다. 눌러도 아무 일이 없으면 "왜 안 되지?" 하고 혼란스러워하죠. 반대로 정말 링크인데 밑줄이 강조용처럼 보이면, 링크인지 강조인지 헷갈립니다. 밑줄이 '링크'와 '강조' 두 의미로 쓰이면, 어느 쪽도 명확하지 않게 됩니다.

그래서 밑줄은 한 가지 의미('링크')만 갖게 해야 합니다. 이는 색상에서 본 원리와 같습니다 — System 색을 그 의미에만 쓰라고 했듯(빨강=위험만), 밑줄도 그 의미(링크)에만 써야 신호가 명확합니다. 신호는 한 가지 의미를 일관되게 가질 때 강력합니다.

3. 그럼 강조는 어떻게 — 밑줄 말고 다른 도구로

"밑줄로 강조하지 말라면, 강조는 어떻게?" 강조 도구는 밑줄 말고도 많습니다(이 시리즈 내내 본 것처럼).

두께(Bold) — 강조의 가장 기본 도구(30편). 굵게 하면 강조됩니다.
색 — 강조색(point 등)으로(41편). 단, 색만으로는 색약자 못 봄(6편).
크기 — 더 크게(37편).
배경 강조 — 형광펜처럼 배경색을 입히기(highlight).

강조에는 이런 도구를 쓰고, 밑줄은 링크에 남겨두면 됩니다. 특히 Bold가 강조의 표준 도구입니다 — 밑줄 없이 굵게만 해도 충분히 강조되고, 링크와 혼동되지 않죠. 밑줄을 빼앗긴다고 강조를 못 하는 게 아니라, 더 적절한 도구로 강조하게 되는 것입니다.

이는 6편(색약)·8편(강조)에서 본 "여러 강조 도구가 있다"는 원리의 연장입니다. 강조 수단은 다양하므로, 밑줄이라는 한 도구를 링크 전용으로 비워둬도 강조에는 전혀 지장이 없습니다. 오히려 각 신호가 한 가지 의미를 가져 화면이 더 명확해집니다.

4. 링크에는 밑줄이 '필요'하다 — 6편과의 연결

DS-042의 또 다른 면은, 밑줄을 강조에서 빼는 것만이 아니라 링크에는 밑줄을 주는 것이기도 합니다.

6편(색약)에서 봤듯, 본문 속 링크를 색만으로 표시하면 색약자·흑백 환경에서 링크를 못 알아봅니다. 그래서 링크에는 색 + 밑줄을 함께 줘야 하죠. DS-042가 '밑줄을 링크에만'이라고 한 것은, 역으로 '링크에는 밑줄을' 이라는 의미도 담습니다. 밑줄이 링크 전용이 되면, 링크는 밑줄로 확실히 식별되고, 사용자는 색을 못 봐도 밑줄로 링크를 압니다.

즉 DS-042는 밑줄을 '링크의 전용 식별 신호'로 확립합니다. 강조에서 빼고 링크에 집중함으로써, 밑줄이 링크를 가리키는 명확하고 일관된 신호가 되는 것이죠. 이는 색약 대응(6편)과 신호 일관성을 동시에 달성하는 영리한 절제입니다. 작은 밑줄 하나의 용도를 명확히 하는 것이, 링크 식별과 접근성을 함께 챙깁니다.

5. 흔한 위반 패턴 / 점검 / 개선

흔한 위반 패턴

함정 ① 강조에 밑줄. 강조 단어에 밑줄 → 링크로 오인. → Bold·색으로 강조. 함정 ② 링크에 밑줄 없음. 링크를 색만으로 → 색약자 못 알아봄. → 링크에 밑줄. 함정 ③ 밑줄 혼용. 밑줄이 링크·강조 둘 다 → 신호 모호. → 링크 전용으로. 함정 ④ 제목에 밑줄 장식. 제목을 밑줄로 꾸밈 → 링크 오인. → 밑줄 제거.

무엇을 점검하나

밑줄 용도 — 밑줄이 링크에만 쓰였는가.
강조 도구 — 강조에 밑줄 대신 Bold·색이 쓰였는가.
링크 밑줄 — 본문 링크에 밑줄이 있는가(6편).
신호 일관성 — 밑줄이 '링크'라는 한 의미만 갖는가.

Before / After

/* ❌ Before: 강조에 밑줄, 링크엔 색만 */
.emphasis { text-decoration: underline; }   /* 강조 — 링크 오인 */
a { color: blue; text-decoration: none; }   /* 링크 — 색약자 못 봄 */

/* ✅ After: 강조는 Bold, 밑줄은 링크 전용 */
.emphasis { font-weight: 700; }              /* 강조는 Bold */
a {
  color: var(--primary-60);
  text-decoration: underline;                /* 링크에 밑줄 */
}

6. 누가 담당하나 / 우리 사이트에 해당될까?

역할	책임
디자이너	밑줄은 링크에만, 강조는 다른 도구로 설계
퍼블리셔/개발	링크에 밑줄, 강조에 Bold·색 구현

기관 유형	DS-042 적용
중앙행정기관(대표·운영) / 공공기관 / 지자체	✅ 필수

링크·강조가 있는 모든 사이트 = 해당.

7. 30초 자가진단 + FAQ

✅ 30초 자가진단

□ 밑줄을 링크에만 쓰나요?
□ 강조를 밑줄이 아니라 Bold·색으로 하나요?
□ 본문 링크에 밑줄이 있나요(색약 대응)?
□ 누를 수 없는 텍스트에 밑줄이 없나요?
□ 밑줄이 '링크'라는 한 의미만 갖나요?

❓ FAQ

Q1. 강조하려고 밑줄을 긋는 게 습관인데요? 밑줄은 '링크'를 뜻하는 신호라, 강조에 쓰면 사용자가 링크로 착각합니다. 강조는 Bold나 색으로 하세요. 밑줄을 강조에서 빼면 화면 신호가 명확해집니다.

Q2. 링크에 밑줄이 답답해 보이는데 빼도 되나요? 본문 속 링크는 밑줄을 권장합니다(6편). 색만으로는 색약자·흑백에서 못 알아봅니다. 메뉴·버튼처럼 위치·형태로 명백한 링크는 밑줄이 없어도 되지만, 문장 안 링크는 밑줄이 안전합니다.

Q3. 밑줄 말고 다른 장식(점선 등)은요? 점선 밑줄 등도 링크나 특정 의미와 혼동될 수 있으니 신중해야 합니다. 강조는 Bold·색처럼 명확한 도구를 쓰고, 밑줄류 장식은 절제하세요.

Q4. 제목에 밑줄 장식을 넣고 싶어요. 제목에 밑줄을 넣으면 링크로 오인될 수 있습니다. 제목 강조는 크기·두께로, 구분이 필요하면 밑줄 대신 여백이나 구분선(별도 요소)을 쓰세요.

Q5. hover 시 밑줄을 추가하는 건요? 링크에 hover 시 밑줄을 강화하는 것은 좋은 방식입니다(상태 표현, 26편). 핵심은 밑줄이 '링크'와 연결되는 것이지, 강조에 쓰지 않는 것입니다.

8. 마무리 — 타이포그래피 16편을 마치며

DS-042의 메시지로 타이포그래피를 닫습니다.

밑줄은 '누를 수 있다'는 약속이다 — 그 약속을 강조용으로 흩뜨리지 말고, 링크 전용으로 지켜라.

작은 밑줄 하나도 일관된 신호로 지킬 때 가장 강력합니다. 밑줄을 링크에만 쓰면, 사용자는 밑줄로 링크를 즉시 알아보고, 색약자도 링크를 식별합니다. 강조는 Bold·색이라는 더 적절한 도구가 담당하죠. 신호를 한 가지 의미로 지키는 절제 — 이는 System 색을 그 의미에만 쓴 것(13편)과 같은 원리입니다.

여기까지 타이포그래피 16개 규칙(027~042) 을 모두 마쳤습니다. 글꼴(Pretendard GOV·고딕)에서 시작해 두께·줄간격·크기·계층·색·밑줄까지, 글자를 '읽히게' 만드는 모든 요소를 다뤘습니다. 색상(26편)에 이어 타이포그래피(16편)까지, 디자인 스타일의 '기본 재료' 두 축이 정리됐습니다.

다음 편부터는 디자인 스타일의 세 번째 분류, 형태(8개 규칙) 로 넘어갑니다. DS-043 — "레디어스를 컴포넌트의 사이즈 기준 5단계로 구성한다." 모서리의 둥글기(border-radius)를 체계화하는 이야기입니다.

다음 편 예고 ▶ 「043. 레디어스를 컴포넌트의 사이즈 기준 5단계로 구성하고 있다.」

우리 사이트의 밑줄 사용이 올바른지 확인하려면? ViewCheck는 밑줄이 링크에만 쓰였는지, 강조에 밑줄이 오용되지 않았는지, 링크에 밑줄이 있어 색약자도 식별 가능한지를 진단합니다.

참고 출처

KRDS 서체(Typography) 스타일 가이드 — https://www.krds.go.kr/html/site/style/style_03.html
WCAG 2.1 Understanding 1.4.1 Use of Color — https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html

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

공식 배너(Masthead) 완전 해부 - KRDS 공식 기준

ViewCheck — Thu, 24 Sep 2026 10:00:59 +0900

공식 배너(Masthead) 완전 해부 - KRDS 공식 기준

공공 사이트에 처음 들어갔을 때, 우리가 가장 먼저(그러나 가장 무의식적으로) 확인하는 게 하나 있습니다. "여기가 진짜 정부 사이트가 맞나?" 하는 의심을 0.5초 만에 가라앉히는 무언가요. 화면 맨 위, 콘텐츠가 시작되기도 전에 가느다란 띠 하나가 "이 누리집은 대한민국 공식 전자정부 누리집입니다" 같은 문장과 함께 떠 있는 걸 본 적 있으실 겁니다. 대개는 그냥 스쳐 지나갑니다. 그런데 그 한 줄이 없는 사이트에서 주민등록 정보를 입력하거나 본인인증을 하려고 하면, 어딘가 마음 한구석이 찜찜해집니다. "이거 혹시 가짜 사이트 아니야?" 하는 의심이 스멀스멀 올라오죠.

그 가느다란 띠가 바로 오늘 이야기할 **공식 배너(Masthead)**입니다. 영어로는 Masthead. KRDS(대한민국 정부 디자인 시스템)가 정의하는 컴포넌트 중에서, 가장 작고 가장 위에 있고, 그래서 가장 많이 무시당하는 요소이기도 합니다. 디자이너 입장에선 "그냥 정부 안내 문구 한 줄"이고, 개발자 입장에선 "위에 div 하나 더 붙이는 일"이고, 기획자 입장에선 "어차피 다 들어가는 거니까 신경 안 써도 되는 것"입니다. 그렇게 다들 가볍게 여기다 보니, 공공 사이트를 수백 개 들여다보면 이 공식 배너에서 똑같은 실수가 끝없이 반복됩니다. 아예 없거나, 모양만 흉내 냈거나, 화면엔 떠 있는데 스크린리더로는 읽히지도 않거나.

현업에서 보면, 공식 배너는 "프로젝트 막판에 끼워 넣는 것" 취급을 받는 경우가 많습니다. 디자인 시안 어디에도 잘 안 그려져 있고, 퍼블리싱 단계에서 "아, 그거 위에 띠 하나 붙이면 되죠" 하고 급하게 추가되죠. 그 과정에서 "이게 무슨 의미를 가지는 영역인지", "스크린리더가 이걸 뭐라고 읽어야 하는지", "여러 페이지에 다 일관되게 들어가는지"를 따지는 사람은 거의 없습니다. 그 결과가 우리가 매일 마주치는, 있는 듯 없는 듯한 공식 배너들입니다.

솔직히 말하면, 공식 배너는 "잘 만들어도 티가 안 나는" 컴포넌트입니다. 제대로 만들어도 대부분의 사용자는 알아채지도 못하고 지나갑니다. 칭찬받기는 어렵고, 빠지면 욕먹기 딱 좋은 자리죠. 하지만 티가 안 난다는 건 잘 작동할 때 얘기입니다. 이게 빠지거나 잘못되면, 신뢰가 가장 필요한 순간에 사용자는 "여기 정말 믿어도 되나?" 하고 멈칫합니다. 그 멈칫거림이 본인인증 화면에서 일어나면, 그건 단순한 불편이 아니라 서비스에 대한 불신으로 번집니다.

이 글에서는 KRDS가 공식 배너를 어떻게 정의하고 무엇을 요구하는지를, 공식 가이드라인과 컴포넌트 킷을 기준으로 하나하나 뜯어보겠습니다. "이렇게 하면 멋있다"가 아니라 "정부 표준은 이걸 요구한다"는 사실 기준으로요. 그리고 그 기준을 우리 사이트가 실제로 지키고 있는지 어떻게 확인하는지까지 이어가겠습니다. 다 읽고 나면, 앞으로 어떤 공공 사이트를 보든 화면 맨 윗줄을 먼저 보게 되실 겁니다. "이건 제대로 된 공식 배너, 저건 흉내만 낸 배너"가 눈에 들어오기 시작하거든요.

공식 배너가 대체 뭐길래 — 정의부터 정확히

먼저 용어부터 맞추겠습니다. 우리가 "정부 사이트 맨 위 띠"라고 뭉뚱그려 부르는 것들은 사실 하나가 아닙니다. KRDS는 화면 최상단 영역을 목적에 따라 구분합니다.

공식 배너(Masthead): 화면 가장 위, 헤더보다도 위에 위치하는 가느다란 띠. "이 사이트가 공식 정부 기관의 것임"을 알리는 신뢰 표식. 대개 접혀 있다가 "확인하는 방법" 같은 안내를 펼쳐 볼 수 있는 형태로 제공됩니다.
헤더(Header): 기관 로고, 주메뉴(GNB), 검색, 로그인 등이 들어가는 본격적인 상단 영역. 공식 배너 바로 아래에 옵니다.
운영기관 식별자(Identifier): 사이트를 운영하는 기관이 누구인지를 밝히는 영역. 주로 푸터(맨 아래)에 들어가며, 공식 배너와는 위치도 역할도 다릅니다.

이 구분이 왜 중요하냐면, 셋을 헷갈려 섞어 버리면 각자의 역할이 흐려지기 때문입니다. 공식 배너는 "여긴 진짜 정부 사이트야"를 말하고, 헤더는 "여기서 무엇을 할 수 있어"를 보여 주고, 식별자는 "여기 운영 책임은 누구야"를 밝힙니다. KRDS가 이걸 굳이 나눠서 정의해 둔 이유가 바로 이겁니다 — 비슷한 자리에 있어도 의미가 다르면 다른 컴포넌트로 다뤄야 한다는 것.

공식 배너의 핵심 역할은 한마디로 **신뢰 표식(trust mark)**입니다. 은행 사이트에 자물쇠 아이콘이 있으면 "안전한 연결이구나" 하고 안심하듯, 정부 사이트 맨 위에 공식 배너가 있으면 "여긴 진짜 공공기관이 운영하는 곳이구나" 하고 안심합니다. 그리고 이 안심은 디지털 시대에 점점 더 중요해지고 있습니다. 정부 사이트를 사칭한 피싱 사이트가 워낙 많아졌거든요. 진짜 사이트와 가짜 사이트를 구분하는 시각적 약속, 그게 공식 배너의 존재 이유입니다.

공식 배너는 보통 어떻게 구성되나

KRDS 컴포넌트 킷(GitHub KRDS-uiux/krds-uiux)을 열어 보면 공식 배너가 일정한 구조로 제공됩니다. 일반적으로 다음 요소들이 들어갑니다.

공식 안내 문구: "이 누리집은 대한민국 공식 전자정부 누리집입니다" 같은, 사이트의 공식성을 밝히는 문장.
국가 상징 또는 식별 마크: 문구 옆에 붙는 작은 시각 표식(태극 문양 등). 한눈에 "정부"임을 알리는 보조 신호.
펼침/접힘 토글: "확인하는 방법" 또는 "자세히 보기" 같은 버튼. 누르면 "공식 정부 사이트를 구별하는 방법"에 대한 추가 안내가 펼쳐집니다.
추가 안내 콘텐츠: 펼쳤을 때 나오는, 도메인 확인법·보안 접속 확인법 같은 설명.

KRDS 공식 가이드 화면

이 구조 자체가 메시지입니다. 공식 배너는 그냥 "한 줄 띄워 놓고 끝"이 아니라, "왜 이게 공식 사이트인지 확인하는 방법까지 안내하는" 인터랙티브한 컴포넌트라는 것. 특히 펼침/접힘 토글이 들어 있다는 건, 공식 배너가 단순 장식 텍스트가 아니라 키보드·스크린리더 접근성까지 챙겨야 하는 "동작하는 컴포넌트"라는 뜻입니다. 뒤에서 자세히 보겠지만, 공공 웹에서 가장 많이 빠뜨리는 게 바로 이 "토글의 접근성"입니다.

KRDS는 공식 배너에 무엇을 요구하나 — 기준 완전 해부

이제 본론입니다. KRDS 가이드라인(디지털 정부서비스 UI/UX 가이드라인, 2025.08판)과 컴포넌트 문서, 그리고 확립된 웹 접근성 기준(KWCAG)을 종합해, 공식 배너가 충족해야 하는 요건을 영역별로 정리하겠습니다.

1) 위치 — 화면 가장 위, 헤더보다도 위

공식 배너의 첫 번째 요건은 위치입니다. 이건 헤더의 일부가 아니라, 헤더보다 위, 페이지 최상단에 와야 합니다. 사용자가 화면을 보자마자 가장 먼저 마주치는 영역이 공식 배너여야 한다는 뜻이죠. 신뢰 표식이라는 역할상 당연한 위치입니다. 만약 공식 배너를 화면 중간이나 푸터에 박아 두면, 정작 신뢰가 필요한 첫 순간에는 보이지 않게 됩니다.

코드 구조로 보면, 보통 <body> 바로 안쪽 최상단에 공식 배너 영역이 오고, 그다음에 헤더가 옵니다. 이 순서는 시각적 순서일 뿐 아니라 DOM 순서이기도 해야 합니다. 스크린리더는 DOM 순서대로 읽기 때문에, 화면엔 위에 있는데 코드상으로는 한참 아래에 있으면 음성 사용자에겐 순서가 뒤죽박죽으로 전달됩니다. "보이는 순서 = 읽히는 순서"가 여기서도 핵심입니다.

2) 공식성을 밝히는 명확한 문구

두 번째 요건은 공식 배너가 전달하는 메시지의 명확성입니다. "이 누리집은 대한민국 공식 전자정부 누리집입니다" 같은 문구는, 사용자가 한 번 읽고 바로 "아, 공식 사이트구나" 하고 이해할 수 있어야 합니다. 모호하거나 장식적인 문구로는 신뢰 표식의 역할을 못 합니다.

여기서 중요한 건, 이 문구가 단순한 이미지가 아니라 실제 텍스트여야 한다는 점입니다. 공식 배너를 통째로 이미지(PNG)로 만들어 박아 두면, 화면엔 글씨가 보이지만 스크린리더는 아무것도 못 읽습니다. 이미지 안의 글자는 컴퓨터에겐 그냥 그림이거든요. 신뢰 표식이 정작 시각장애인 사용자에겐 "빈 그림"으로 다가가는 아이러니가 생깁니다. 그래서 공식 배너의 문구는 반드시 선택·복사 가능한 진짜 텍스트로 구현되어야 합니다.

3) 펼침/접힘 토글의 키보드 조작

공식 배너에 "확인하는 방법" 같은 펼침 버튼이 있다면, 이건 타협 없는 요건입니다. 그 토글은 키보드만으로 다음이 전부 가능해야 합니다.

Tab으로 토글 버튼에 초점(focus) 이동
Enter / Space로 펼치기·접기
펼쳐진 안내 콘텐츠로 초점이 자연스럽게 이어지기
다시 토글을 눌러 접기

그리고 이 토글은 단순히 클릭만 되는 게 아니라, 상태가 코드로 표현되어야 합니다. 표준적으로는 aria-expanded="false"(접힘) / aria-expanded="true"(펼침)로 현재 상태를 알립니다. 그래야 스크린리더가 "확인하는 방법, 버튼, 접힘"처럼 현재 상태까지 읽어 줍니다. 펼쳤는데 펼쳐졌다는 사실이 음성으로 전달되지 않으면, 시각장애인 사용자는 "내가 누른 게 작동한 건가?"를 알 수 없습니다.

현실에서 이게 어떻게 깨지냐면, 대부분 <div>에 클릭 이벤트만 붙여서 토글을 만들기 때문입니다. 마우스로는 잘 펼쳐지는데, 키보드 Tab으로는 아예 닿지도 않고, 스크린리더는 그게 버튼인 줄도 모릅니다. KRDS 컴포넌트 킷이 공식 배너 코드를 제공하는 이유가 정확히 이겁니다 — 토글의 키보드 동작과 ARIA 상태가 이미 구현된 검증된 코드를 가져다 쓰라는 것.

4) 초점 표시(Focus) — 토글에 초점이 왔을 때 보여야 한다

키보드로 공식 배너의 토글에 이동했을 때, 지금 초점이 거기 와 있다는 걸 시각적으로 알 수 있어야 합니다. 테두리가 강조되거나 외곽선(focus ring)이 또렷하게 나타나야 하죠. 공식 배너가 화면 맨 위라 가장 먼저 Tab이 닿는 영역인 만큼, 여기서 초점 표시가 없으면 키보드 사용자는 시작부터 "내가 지금 어디 있지?"를 잃어버립니다.

이 표시를 디자인이 지저분해 보인다는 이유로 CSS에서 outline: none으로 지워 버리는 경우가 정말 많습니다. 특히 공식 배너처럼 "가늘고 깔끔하게" 만들고 싶은 영역에서 더 그렇죠. 그러면 키보드 사용자는 자기가 화면 어디에 있는지 알 수 없게 됩니다. 포커스 표시는 지우는 게 아니라, 디자인과 어울리게 다듬는 것이 정답입니다.

5) 의미 구조(랜드마크와 제목)

공식 배너는 페이지 안에서 하나의 독립된 "영역"입니다. 그래서 그냥 <div>로 던져 놓는 것보다, 의미를 가진 구조로 표시해 주는 게 좋습니다. 적절한 영역 역할(role 또는 시맨틱 태그)을 부여하면, 스크린리더 사용자가 "여기서부터 공식 배너 영역"임을 인지하고 필요하면 건너뛸 수도 있습니다.

특히 펼쳤을 때 나오는 안내 콘텐츠에 소제목이 있다면, 그걸 적절한 제목 단계(<h2> 등)로 표시해 두면 스크린리더 사용자가 제목만 훑어 구조를 파악할 수 있습니다. "보이는 굵은 글씨"가 아니라 "코드 수준의 제목"이어야 한다는 게 핵심입니다.

6) 색에만 의존하지 않기 + 충분한 대비

공식 배너는 보통 진한 배경에 밝은 글씨, 또는 그 반대로 만들어집니다. 어느 쪽이든 글씨와 배경의 명도 대비가 충분해야 합니다. 신뢰 표식인데 정작 글씨가 흐릿해서 잘 안 보이면 의미가 없죠. 한국형 웹 접근성 지침(KWCAG)과 국제 표준은 텍스트의 최소 명도 대비 기준을 권장합니다 — 일반적으로 본문 텍스트는 4.5:1 이상을 기준으로 삼습니다.

또 공식 배너 안에 상태나 의미를 색으로만 표현하지 않아야 합니다. 예를 들어 "안전한 접속" 표시를 초록색만으로 알린다면, 색 구분이 어려운 사용자는 그 의미를 놓칩니다. 색은 보조 신호일 뿐, 텍스트나 모양이 의미를 받쳐 줘야 합니다.

7) 모바일·반응형 대응

공식 배너는 모든 화면 크기에서 제 역할을 해야 합니다. 데스크톱에선 한 줄로 깔끔하게 들어가던 문구가, 모바일에선 두세 줄로 접히거나 잘려서 의미가 깨지는 경우가 있습니다. 좁은 화면에서도 공식성을 밝히는 핵심 문구는 온전히 전달되어야 하고, 펼침 토글 같은 버튼은 손가락으로 누를 수 있을 만큼 충분한 터치 영역(일반적으로 한 변 44px 이상)을 가져야 합니다.

모바일에서 공간이 부족하다고 공식 배너를 아예 빼 버리는 경우도 있는데, 이건 좋지 않습니다. 모바일 사용자야말로 피싱 사이트에 더 취약하기 때문에(작은 화면에선 주소창 확인이 어렵죠), 신뢰 표식이 더 필요합니다.

8) 사이트 전체 일관성

공식 배너는 한 페이지에만 있어선 안 됩니다. 사용자는 메인에서만 사이트에 들어오는 게 아니라, 검색 결과나 외부 링크를 통해 내부 페이지로 바로 들어오기도 합니다. 그 사람에게 신뢰 표식을 보여 주려면, 공식 배너가 모든 페이지에 일관되게 들어가 있어야 합니다. 메인엔 있는데 신청 페이지엔 없는 식이면, 정작 민감한 정보를 입력하는 화면에서 신뢰 표식이 사라지는 셈입니다.

정리하면, KRDS의 공식 배너 기준은 크게 세 축입니다. ① 신뢰성(명확한 공식 문구, 일관된 위치, 모든 페이지 적용), ② 접근성(토글 키보드 지원, 초점 표시, 텍스트 기반 구현), ③ 전달성(시각 정보가 코드로도 전달돼 스크린리더가 읽을 수 있을 것). 이 세 축은 그대로 ViewCheck가 공식 배너를 판정하는 기준이기도 합니다.

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

여기까지 읽고 "정부 안내 띠 하나에 뭐 이리 까다롭나" 싶으실 수 있습니다. 그런데 이 요건들은 누가 괜히 만들어 낸 규칙이 아니라, 실제 사용자가 막히거나 피해를 보는 지점에서 역으로 도출된 것들입니다.

신뢰는 0.5초 안에 결정된다

사용자가 사이트에 들어와 "여기 믿어도 되나?"를 판단하는 데 걸리는 시간은 생각보다 짧습니다. 거의 무의식적으로, 화면이 뜨자마자 결정됩니다. 이 첫인상에서 "공식 정부 사이트"라는 신호를 주는 가장 빠른 방법이 화면 맨 위의 공식 배너입니다. 이게 없으면 사용자는 그 신호를 다른 데서 찾아야 하는데(도메인 주소를 확인한다든가), 대부분은 그렇게까지 하지 않습니다. 그냥 막연한 불안을 안은 채 작업을 진행하거나, 불안해서 이탈합니다.

특히 공공 서비스는 "안 쓸 자유"가 없는 영역이 많습니다. 세금을 내거나, 민원을 신청하거나, 본인인증을 하는 일은 그 사이트가 아니면 할 수 없죠. 그래서 신뢰 표식이 빠지면, 사용자는 불안하지만 어쩔 수 없이 진행하게 됩니다. 그 불안을 덜어 주는 게 공식 배너의 존재 이유입니다.

피싱과 사칭으로부터의 방어선

공식 배너가 단순 장식이 아니라 "확인하는 방법"까지 안내하는 인터랙티브 컴포넌트인 이유가 여기 있습니다. 정부 사이트를 사칭한 피싱 사이트는 디자인을 거의 똑같이 베낍니다. 로고도, 색깔도, 레이아웃도 흉내 내죠. 하지만 공식 배너의 "공식 사이트 확인 방법"(올바른 도메인 확인, 보안 접속 확인 등)을 안내하면, 사용자가 스스로 진짜와 가짜를 구분할 단서를 갖게 됩니다. 공식 배너는 단순히 "우리는 진짜야"라고 주장하는 데서 그치지 않고, "이렇게 확인해 보세요"라며 사용자에게 판별 능력을 쥐여 주는 겁니다.

그렇기 때문에 공식 배너를 모양만 흉내 내선 안 됩니다. 펼쳤더니 안내가 없거나, 토글이 작동하지 않거나, 문구가 모호하면, 신뢰 표식이 오히려 "허울뿐인 띠"가 되어 버립니다.

보이는 것과 읽히는 것의 분리

비장애인은 화면을 "본다"고 생각하지만, 사실 우리는 화면을 보고 머릿속에서 의미로 번역합니다. 공식 배너의 진한 띠와 문구를 보고 "아, 공식 사이트구나" 하고 짐작하죠. 스크린리더 사용자에게는 이 짐작 과정이 없습니다. 코드가 알려 주는 정보가 곧 전부입니다.

그래서 공식 배너는 "보기에 공식 배너 같은 것"으로는 부족하고, "코드 수준에서 읽히는 텍스트로 된 것"이어야 합니다. 통째로 이미지로 박아 두면, 음성 사용자에겐 신뢰 표식이 통째로 사라집니다. 토글에 aria-expanded가 없으면, 펼쳤다는 사실이 전달되지 않습니다. 이 "보이는 것 ≠ 읽히는 것" 문제가 공식 배너 위반의 근본 원인 대부분을 차지합니다. KRDS의 모든 컴포넌트 요건이 결국 "시각과 코드의 일치"라는 한 가지 원리로 수렴하는 셈입니다.

작은 컴포넌트일수록 방치되기 쉽다

역설적이지만, 공식 배너처럼 "작고 늘 똑같은" 컴포넌트일수록 품질 관리에서 밀려납니다. 메인 비주얼이나 핵심 기능에는 모두가 눈을 부릅뜨지만, 화면 맨 위 가느다란 띠에는 아무도 깐깐하게 굴지 않거든요. "어차피 모든 정부 사이트에 다 있는 거니까 대충 복사하면 되겠지" 하고 넘어갑니다. 그런데 그 "대충 복사"가 접근성 빠진 코드를 그대로 베끼는 일이 되기도 합니다. 가장 표준화하기 쉬워 보이는 곳에서 오히려 검증 없이 베낀 코드가 퍼져 나가는 거죠. KRDS가 공식 배너 같은 기본 컴포넌트까지 검증된 코드로 제공하는 건, 바로 이 "방치되기 쉬운 곳"에서 품질이 무너지는 걸 막기 위해서입니다.

일관성이 곧 신뢰의 누적

KRDS가 공식 배너의 모습과 문구를 표준화하는 또 다른 이유는 일관성입니다. 모든 정부 사이트의 공식 배너가 같은 위치에서 같은 방식으로 같은 문구를 보여 주면, 사용자는 한 번 익힌 "공식 사이트의 신호"를 모든 정부 사이트에서 똑같이 인식합니다. 반대로 사이트마다 공식 배너가 제각각이면, "이게 진짜 공식 표식인지" 매번 다시 판단해야 합니다. 표준화된 신뢰 표식은 정부 서비스 전체에 대한 신뢰를 한 칸씩 쌓아 올리는 일입니다. 한 사이트의 잘 만든 공식 배너가 "정부 사이트는 믿을 만하다"는 인상을 만들고, 그 인상이 다음 사이트로 이어집니다.

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

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

실수 1) 공식 배너 자체가 없다

가장 기본적이지만 의외로 흔한 실수입니다. 신뢰 표식이 가장 필요한 신청·인증 페이지에 공식 배너가 아예 없습니다. 특히 외주로 따로 만든 하위 시스템(예: 별도 도메인의 신청 시스템)에서 자주 빠집니다.

나쁜 예: 메인 포털엔 공식 배너가 있는데, 링크를 타고 넘어간 신청 시스템엔 없음. 사용자는 "여기 진짜 정부 사이트 맞나?" 하고 불안한 채로 본인인증을 진행.
올바른 예: 메인이든 하위 시스템이든, 사용자가 들어올 수 있는 모든 진입점에 일관된 공식 배너 적용. 외주 발주 시 "공식 배너 KRDS 표준 적용"을 명시.

실수 2) 공식 배너를 통째로 이미지로 박아 둠

문구와 마크를 한 장의 이미지(PNG/JPG)로 만들어 화면 맨 위에 붙입니다. 보기엔 깔끔합니다. 그런데 그 안의 글자는 컴퓨터에겐 그림일 뿐입니다.

나쁜 예: 공식 안내 문구가 통째로 이미지. 스크린리더는 아무것도 못 읽거나, 잘해야 빈약한 대체 텍스트(alt) 하나만 읽음. 화면 확대 시 글자가 깨짐.
올바른 예: 문구는 실제 텍스트로, 마크(태극 문양 등)만 이미지/SVG로. 마크에는 의미가 중복되지 않게 적절히 처리(장식이면 aria-hidden, 의미가 있으면 대체 텍스트). 확대해도 글자가 또렷.

실수 3) 펼침 토글이 키보드로 작동하지 않음

"확인하는 방법" 버튼을 <div>에 클릭 이벤트만 붙여 만듭니다. 마우스로는 펼쳐지는데, 키보드로는 닿지도 않습니다.

나쁜 예: <div onclick="...">로 만든 토글. Tab으로 초점이 가지 않고, Enter/Space에 반응하지 않으며, role도 aria-expanded도 없음. 키보드 사용자에겐 존재하지 않는 버튼.
올바른 예: <button> 요소로 만들고 aria-expanded로 펼침/접힘 상태를 표현. 펼쳐지는 콘텐츠는 aria-controls로 연결. KRDS 킷의 공식 배너 코드를 그대로 사용하면 이 부분이 이미 구현돼 있음.

실수 4) 펼친 상태가 코드로 전달되지 않음

토글이 키보드로 작동은 하는데, 펼쳐졌는지 접혔는지를 알리는 aria-expanded가 빠져 있습니다.

나쁜 예: 펼침 버튼을 눌러도 스크린리더는 "확인하는 방법, 버튼"이라고만 읽고, 그게 지금 펼쳐진 건지 접힌 건지 알려 주지 않음. 사용자는 "내가 누른 게 작동한 건가?"를 알 수 없음.
올바른 예: aria-expanded 값이 클릭에 따라 true/false로 바뀌어, 스크린리더가 "확인하는 방법, 버튼, 펼침"처럼 상태를 읽어 줌.

실수 5) 초점 표시 제거

화면 맨 위라 가장 먼저 Tab이 닿는 곳인데, 디자인 통일성을 위해 outline: none으로 포커스 링을 지웁니다.

나쁜 예: 키보드로 사이트에 들어와 첫 Tab을 눌렀는데, 초점이 어디 갔는지 안 보임. 시작부터 길을 잃음.
올바른 예: 토글에 초점이 오면 또렷한 테두리·외곽선 유지. 공식 배너가 키보드 탐색의 출발점인 만큼 더욱 신경 써야 함.

실수 6) 문구가 모호하거나 장식적

공식성을 밝혀야 하는데, 문구가 추상적이거나 멋만 부려서 무슨 사이트인지 명확히 안 와닿습니다.

나쁜 예: "함께 만드는 행복한 ○○" 같은 슬로건만 있고, 정작 "공식 정부 누리집"임을 밝히는 문구는 없음. 신뢰 표식의 역할 실패.
올바른 예: "이 누리집은 대한민국 공식 전자정부 누리집입니다"처럼, 한 번 읽고 바로 이해되는 명확한 공식 문구. 슬로건은 슬로건대로 다른 영역에.

실수 7) 모바일에서 깨지거나 사라짐

데스크톱 기준으로만 만들고 모바일을 확인하지 않아, 좁은 화면에서 문구가 잘리거나 토글이 너무 작아집니다.

나쁜 예: 모바일에서 공식 문구가 두 줄로 어색하게 잘리거나, 공간 부족을 이유로 공식 배너를 통째로 숨김. 정작 모바일 사용자가 신뢰 표식이 더 필요한데도.
올바른 예: 좁은 화면에서도 핵심 문구는 온전히 보이고, 토글 버튼은 손가락에 맞는 터치 영역(약 44px 이상) 확보. 반응형으로 자연스럽게 재배치.

실수 8) 의미 구조 없이 div만 나열

공식 배너 영역을 의미 없는 <div> 덩어리로만 만들어, 스크린리더가 "여기가 공식 배너 영역"임을 인지하지 못합니다.

나쁜 예: 영역 구분 없는 <div> 나열. 음성 사용자는 어디서부터 어디까지가 공식 배너인지 알 수 없고, 건너뛸 수도 없음.
올바른 예: 적절한 영역 역할과 제목 구조를 부여해, 스크린리더 사용자가 영역을 인지하고 필요 시 건너뛸 수 있게.

한 장면 — 같은 사이트, 두 사람

추상적인 요건을 길게 늘어놓는 것보다, 한 장면을 그려 보는 게 빠를 것 같습니다. 어느 공공 서비스의 "본인인증" 화면, 화면 맨 위에 공식 배너가 하나 있다고 합시다.

먼저 마우스를 쓰는 김 주무관. 화면이 뜨자 맨 위 진한 띠에 "이 누리집은 대한민국 공식 전자정부 누리집입니다"라는 문구가 눈에 들어옵니다. 0.5초 만에 "아, 공식 사이트구나" 하고 안심하고, 곧장 인증 절차로 넘어갑니다. 궁금해서 "확인하는 방법"을 한 번 눌러 보니 도메인 확인법이 펼쳐집니다. 김 주무관에게 이 공식 배너는 아무 문제가 없습니다. 그래서 이 화면을 만든 팀도 "잘 작동한다"고 믿습니다. 자기들이 테스트할 때 늘 마우스를 썼으니까요.

이번엔 시각장애가 있는 박 선생님. 스크린리더를 켜고 사이트에 들어와 화면 맨 위부터 읽어 내려갑니다. 그런데 공식 배너 자리에서 스크린리더가 침묵합니다. 알고 보니 공식 안내 문구가 통째로 이미지로 박혀 있고, 대체 텍스트도 없었던 겁니다(이미지 구현). 박 선생님은 "여기가 진짜 정부 사이트인지" 확인할 신호를 받지 못한 채, 불안한 마음으로 본인인증 정보를 입력해야 할지 망설입니다. "확인하는 방법" 토글도 <div>로 만들어져 Tab으로 닿지 않아, 스스로 진짜 여부를 확인할 길도 없습니다(토글 미지원).

같은 화면, 같은 공식 배너. 한 사람에겐 0.5초 만에 안심을 주는 신뢰 표식이고, 다른 한 사람에겐 "있는지조차 모르는 빈자리"입니다. 그리고 이 차이는 "예산이 부족해서"나 "기술이 어려워서" 생긴 게 아닙니다. 그냥 만들 때 마우스 쓰는 비장애인만 떠올렸기 때문에 생긴 차이입니다. KRDS의 공식 배너 요건은, 이 두 사람이 똑같이 "여긴 믿을 만한 공식 사이트"라는 신호를 받게 하기 위한 최소한의 약속입니다. 그리고 그 약속을 지켰는지는 사람이 매번 스크린리더로 확인하기 어렵기 때문에, 자동 점검이 필요한 겁니다.

만약 이 팀이 KRDS 킷의 공식 배너 코드를 가져다 썼다면 어땠을까요. 박 선생님의 스크린리더는 "이 누리집은 대한민국 공식 전자정부 누리집입니다"라는 문구를 또박또박 읽었을 거고, "확인하는 방법, 버튼, 접힘"이라는 토글을 Enter로 펼쳐 도메인 확인법까지 들었을 겁니다. 김 주무관과 똑같이 안심하고 인증을 진행했겠죠. 차이를 만드는 건 거창한 기술이 아니라, "검증된 컴포넌트를 쓰느냐"라는 작은 선택입니다.

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

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

개발자라면 — KRDS 컴포넌트 킷을 npm install krds-uiux로 설치하거나 CDN(krds.min.css / krds.min.js)으로 불러올 수 있습니다. 저장소(KRDS-uiux/krds-uiux)의 html/code 폴더에 공식 배너 컴포넌트 코드가 들어 있어, 펼침 토글의 키보드 동작과 aria-expanded 같은 ARIA 상태가 이미 구현된 상태로 시작할 수 있습니다. "접근성은 어렵다"는 말의 절반은 "직접 만들어서 어렵다"는 뜻인데, 검증된 코드를 가져다 쓰면 그 절반이 사라집니다. 특히 공식 배너처럼 모든 페이지에 들어가는 공통 영역은, 한 번 제대로 만들어 공통 레이아웃으로 빼 두면 사이트 전체에 일관되게 적용됩니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 공식 배너 컴포넌트를 그대로 가져다 쓸 수 있습니다. 직접 그리지 말고 표준 컴포넌트를 배치하면, 디자인 단계에서부터 위치·문구·색 대비·펼침 구조가 기준에 맞춰집니다. 시안과 실제 구현 사이의 간극도 줄어들죠. 특히 모바일 시안에서도 공식 배너를 빼지 말고, 좁은 화면에서 어떻게 보일지 함께 설계하세요.

기획자라면 — 화면 정의서에 공식 배너를 "당연히 들어가는 것"으로 묻어 두지 말고, "공식 배너(KRDS 표준, 모든 페이지 적용, 펼침 안내 포함)"처럼 명시하세요. 특히 별도 시스템(신청·인증 시스템 등)을 외주로 발주할 때, "공식 배너 KRDS 표준 적용"을 요구사항에 못 박는 한 줄이 나중의 누락을 막습니다. 이 한 줄이 디자인·개발 단계의 "어, 그거 빠졌네"를 예방합니다.

그래서 우리 사이트는? — ViewCheck로 점검

여기까지가 KRDS의 공식 배너 기준입니다. 그런데 정작 어려운 건 "그래서 우리 사이트 공식 배너는 이걸 지키고 있나?"를 확인하는 일입니다. 공식 배너가 모든 페이지에 일관되게 들어가 있는지, 문구가 이미지가 아니라 진짜 텍스트인지, 펼침 토글이 키보드로 작동하고 상태가 코드로 표현되는지를 사람이 일일이 손으로 점검하려면 끝이 없습니다. 페이지가 수십·수백 개인 공공 사이트라면 더더욱요.

ViewCheck 분석 화면

ViewCheck가 공식 배너에 대해 자동으로 보는 것들:

존재 여부와 위치: 화면 최상단에 공식 배너 영역이 있는지, DOM 순서상으로도 헤더보다 위에 오는지
텍스트 기반 구현 여부: 공식 문구가 실제 텍스트인지, 통째로 이미지로 박혀 있는지
펼침 토글의 접근성: 토글이 버튼으로 구현됐는지, aria-expanded로 상태가 표현되는지, 키보드로 접근 가능한지
사이트 전체 일관성: 여러 페이지를 분석하면, 공식 배너가 메인엔 있는데 내부 페이지엔 없는 식의 누락이 페이지별로 드러남
색 대비·반응형: 문구의 명도 대비, 모바일 뷰포트에서의 표시 상태(반응형 품질 분석과 연계)

DOM만으로 판단하기 어려운 시각적 부분(예: 공식 배너가 실제로 화면 맨 위에 또렷이 보이는지, 펼침 안내가 시각적으로 잘 펼쳐지는지)은 KRDScan Vision AI가 스크린샷을 보고 보강 판정합니다. 그래서 "코드 구조는 애매한데 화면엔 분명히 공식 배너처럼 보이는" 비표준 구현도 놓치지 않습니다. 이 점이 단순 코드 검사 도구와 다른 부분입니다 — 사람이 눈으로 보듯 화면을 함께 보기 때문에, 표준을 우회해 만든 UI도 잡아냅니다.

리포트를 어떻게 읽나

분석이 끝나면 컴포넌트 탭에서 공식 배너 관련 규칙의 통과/미통과 수와, 미통과한 항목의 **위치(어느 페이지)·이유·개선 방법(howToFix)**이 함께 나옵니다. 예를 들어 "신청 페이지에 공식 배너 없음" 또는 "공식 배너 펼침 토글에 aria-expanded 누락"처럼 구체적으로요. 여러 페이지를 한꺼번에 분석하면, "메인엔 공식 배너가 있는데 신청·인증 페이지엔 없다" 같은 페이지별 편차가 한눈에 드러납니다. 어디부터 고쳐야 하는지 우선순위(P0~P3)도 함께 매겨지니, 한정된 시간에 가장 중요한 것부터 손볼 수 있습니다.

무료 진단으로 우리 사이트 메인부터 한 번 돌려 보면, 손으로는 몇 시간 걸릴 점검이 몇 분 만에 끝납니다. 그리고 그 결과는 막연한 "잘하자"가 아니라, "이 페이지에 공식 배너를 추가하자", "이 토글에 aria-expanded를 넣자"는 구체적인 작업 목록이 됩니다.

자주 묻는 질문

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

Q. 공식 배너랑 헤더, 운영기관 식별자가 자꾸 헷갈립니다. 한 줄로 구분해 주세요. 위치와 역할로 외우면 쉽습니다. 공식 배너는 화면 맨 위, "여긴 진짜 정부 사이트야"를 알리는 신뢰 표식입니다. 헤더는 그 바로 아래, 로고·메뉴·검색·로그인이 들어가는 본격 상단 영역으로 "여기서 뭘 할 수 있어"를 보여 줍니다. 운영기관 식별자는 주로 푸터(맨 아래), "이 사이트 운영 책임은 누구야"를 밝힙니다. 셋 다 "기관을 드러내는" 공통점이 있지만, 공식 배너는 신뢰, 헤더는 탐색, 식별자는 책임 소재라는 점이 다릅니다.

Q. 공식 배너를 통째로 이미지로 만들면 정말 안 되나요? 그게 디자인 통일성에 좋은데요. 권장하지 않습니다. 이미지 안의 글자는 스크린리더가 못 읽고, 화면 확대 시 깨지며, 다국어 전환이나 문구 수정도 번거롭습니다. 신뢰 표식이 정작 시각장애인에겐 "빈 그림"으로 다가가는 건 본말전도죠. 디자인 통일성은 텍스트와 CSS로도 충분히 맞출 수 있습니다. 마크(문양)만 이미지/SVG로 두고, 문구는 진짜 텍스트로 구현하는 게 원칙입니다.

Q. 우리 사이트는 한 페이지(메인)에만 공식 배너가 있어도 괜찮나요? 괜찮지 않습니다. 사용자는 메인으로만 들어오지 않습니다. 검색 결과나 외부 링크를 통해 내부 페이지로 바로 들어오는 경우가 매우 많습니다. 그 사람에게 신뢰 표식을 보여 주려면 모든 페이지에 공식 배너가 있어야 합니다. 특히 본인인증·결제·신청처럼 민감한 정보를 다루는 페이지일수록 더 중요합니다. 공통 레이아웃(헤더 컴포넌트)에 한 번 넣어 두면 전 페이지에 자동 적용되니, 구현 부담도 크지 않습니다.

Q. 펼침 토글의 aria-expanded, 꼭 있어야 하나요? 네, 토글이 있다면 필수입니다. aria-expanded가 없으면 스크린리더 사용자는 그 버튼이 지금 펼쳐진 상태인지 접힌 상태인지 알 수 없습니다. "내가 누른 게 작동한 건가?"를 알 수 없는 거죠. 마우스 사용자는 화면 변화로 알지만, 음성 사용자에겐 코드가 알려 주는 상태가 전부입니다. 버튼은 <div>가 아니라 <button>으로 만들고, 펼침/접힘에 따라 aria-expanded 값을 바꿔 주는 게 기본입니다.

Q. 모바일에서 공간이 부족한데 공식 배너를 숨겨도 되나요? 가급적 숨기지 마세요. 오히려 모바일 사용자가 신뢰 표식이 더 필요합니다. 작은 화면에선 주소창 확인이 어려워 피싱에 더 취약하거든요. 공간이 부족하면 공식 배너를 압축해서 보여 주거나(핵심 문구만, 상세는 펼침으로), 폰트·여백을 조정해 한 줄로 들어가게 하는 방법을 먼저 검토하세요. 핵심 공식 문구는 어떤 화면 크기에서도 온전히 전달되어야 합니다.

Q. 이미 운영 중인 사이트인데, 공식 배너를 전부 다시 만들어야 하나요? 전부 갈아엎을 필요는 없습니다. 먼저 ViewCheck로 현황을 확인해 "공식 배너가 어느 페이지에 있고 없는지, 어떤 페이지의 토글이 접근성을 빠뜨렸는지"를 목록으로 만든 다음, 우선순위대로 치명적인 것부터 차례로 고치면 됩니다. 보통 가장 큰 효과는 "누락된 페이지에 공식 배너를 추가"하는 것과 "토글의 키보드 접근성을 보강"하는 것에서 나옵니다. 리뉴얼 예산을 한 번에 들이지 않고도, 공통 레이아웃 한 곳만 고쳐 전 페이지에 반영하는 식으로 점진적으로 개선할 수 있습니다.

Q. KRDS 킷의 공식 배너 코드를 쓰면 디자인을 우리 기관에 맞게 바꿔도 되나요? 색이나 세부 스타일은 기관 정체성에 맞게 조정할 수 있습니다. 다만 그 과정에서 접근성 요건은 건드리지 마세요. 색을 바꿀 땐 명도 대비를 다시 확인하고, 마크업 구조(버튼/aria 속성)는 그대로 유지하는 게 원칙입니다. "보이는 것"은 바꾸되 "읽히는 구조"는 보존한다고 생각하시면 됩니다. 스타일만 입히고 구조는 검증된 그대로 두는 게, 디자인 자유와 접근성을 동시에 챙기는 길입니다.

Q. 공식 배너 디자인이 너무 정부스럽고 답답한데, 좀 더 우리 기관답게 못 하나요? 공식 배너는 "개성을 드러내는 자리"가 아니라 "신뢰를 주는 자리"라는 점을 먼저 떠올리시면 좋겠습니다. 모든 정부 사이트가 비슷한 공식 배너를 쓰는 게 단점이 아니라, 바로 그 "같음"이 신뢰의 핵심입니다. 사용자는 익숙한 신호를 만났을 때 안심하거든요. 기관의 개성은 헤더의 로고, 메인 비주얼, 색상 시스템에서 충분히 드러낼 수 있습니다. 공식 배너만큼은 표준을 따르는 게, 결과적으로 우리 사이트의 신뢰도를 높이는 길입니다.

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

ViewCheck로 돌려 보면 공식 배너 관련 문제가 한두 개로 끝나지 않을 수 있습니다. 페이지가 많을수록 "고칠 게 많다"는 압박감이 듭니다. 그래서 우선순위가 중요합니다. 공식 배너 문제를 심각도 순으로 정리하면 대략 이렇습니다.

가장 먼저(치명적) — 본인인증·결제·신청처럼 민감한 핵심 경로 페이지에 공식 배너가 아예 없는 경우, 그리고 펼침 토글이 키보드로 전혀 작동하지 않는 경우. 전자는 신뢰가 가장 필요한 순간에 표식이 없는 것이고, 후자는 특정 사용자에게 기능을 완전히 차단하는 문제라 1순위입니다.

그다음(높음) — 공식 배너가 일반 페이지엔 빠져 있거나, 문구가 통째로 이미지라 스크린리더로 안 읽히는 경우, 그리고 토글에 aria-expanded가 없어 상태가 전달되지 않는 경우. 작동은 하지만 음성 사용자에게 신뢰 표식이 닿지 않으니 실질적 장벽입니다.

그 후(보통) — 초점 표시 제거, 모바일에서 문구 잘림·터치 영역 부족, 색 대비 부족. 사용은 가능하지만 특정 상황·특정 사용자에게 불편을 주는 문제입니다.

여력이 되면(낮음) — 펼침 안내 콘텐츠의 내용 보강(도메인 확인법·보안 접속 확인법을 더 친절하게), 의미 구조(랜드마크·제목) 정교화 같은 개선. 신뢰를 막는 건 아니지만 경험을 한 단계 끌어올리는 항목입니다.

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

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

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

KRDS 가이드라인 PDF(디지털 정부서비스 UI/UX 가이드라인, 2025.08판) — 컴포넌트별 정의와 사용 원칙의 1차 원천.
KRDS 컴포넌트 문서(웹) — 공식 배너(Masthead)의 구조와 예시를 화면으로 확인.
KRDS 컴포넌트 킷(GitHub KRDS-uiux/krds-uiux) — 공식 배너 코드를 그대로 가져다 사용(npm install krds-uiux 또는 CDN krds.min.css / krds.min.js).
KRDS 공식 Figma(@krds) — 디자이너용 공식 배너 컴포넌트와 상태.

오늘의 체크리스트 — 공식 배너, 이것만은

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

공식 배너가 화면 가장 위(헤더보다 위)에 있고, DOM 순서도 그렇다.
공식 문구가 실제 텍스트다(통째로 이미지로 박지 않았다).
문구가 "공식 정부 누리집임"을 명확히 밝힌다(모호한 슬로건으로 대체하지 않았다).
펼침 토글이 있다면 <button>으로 만들고 키보드로 펼침·접힘이 된다.
토글에 aria-expanded로 펼침/접힘 상태가 코드로 표현된다.
토글에 초점 표시가 또렷하다(outline: none으로 지우지 않았다).
공식 배너가 모든 페이지에 일관되게 들어간다(특히 신청·인증 페이지).
문구와 배경의 명도 대비가 충분하다(약 4.5:1 이상).
모바일에서도 핵심 문구가 온전히 보이고, 토글 터치 영역이 충분하다(약 44px 이상).
공식 배너 영역이 의미 구조(영역 역할·제목)를 갖춰 스크린리더가 인지·건너뛰기 가능하다.

KRDS 컴포넌트 킷(npm install krds-uiux 또는 CDN)을 쓰면 위 항목 대부분이 이미 구현된 상태로 시작할 수 있습니다. 직접 만들다 빠뜨릴 위험을 줄이는 가장 확실한 방법이죠. 공식 Figma 라이브러리(@krds)에서는 디자이너가 공식 배너 컴포넌트를 그대로 가져다 쓸 수 있습니다.

공식 배너는 작아 보이지만, 공공 서비스를 향한 신뢰가 시작되는 첫 줄입니다. 그 가느다란 띠 하나가 누군가에겐 "여기 믿어도 되겠다"는 안심이고, 그게 빠진 누군가에겐 "혹시 가짜 아닐까" 하는 불안입니다. 우리가 무심코 막판에 끼워 넣은 그 한 줄이, 사실은 사용자가 본인인증 정보를 입력할지 말지를 가르는 신뢰의 출발점인 셈입니다.

오늘 정리한 기준이 거창해 보일 수 있지만, 핵심은 결국 단순합니다. 화면 맨 위에 공식 문구를 진짜 텍스트로 두고, 모든 페이지에 일관되게 넣고, 펼침 토글을 키보드로 쓸 수 있게 하고, 검증된 코드를 쓰는 것. 이 네 가지만 챙겨도 공식 배너의 위반 대부분은 사라집니다. 그리고 그게 잘 됐는지는 ViewCheck로 몇 분이면 확인할 수 있습니다. 완벽을 한 번에 만들 필요는 없습니다. 공식 배너가 빠진 페이지 하나, 접근성을 놓친 토글 하나부터 고쳐 나가면, 우리 사이트는 분명히 조금씩 더 믿을 만한 곳이 됩니다. 다음 글에서는 공식 배너 바로 아래 자리하는 또 다른 상단 컴포넌트를 같은 방식으로 뜯어보겠습니다.

우리 사이트의 공식 배너는 모든 페이지에 제대로 들어가 있을까요? krds.viewcheck.co.kr에서 URL만 넣으면 무료로 확인할 수 있습니다. 메인 페이지 하나만 돌려 봐도, 위 체크리스트가 실제로 지켜지고 있는지 바로 보입니다.

#KRDS #공식배너Masthead #공공웹 #디자인시스템 #웹접근성 #ViewCheck #정부웹사이트 #UIUX #신뢰표식 #전자정부

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

041편 : 본문 글자의 색상을 주로 그레이 계열로 유지하고, 주요 동작에는 primary, secondary, point, system 색상을 적용하고 있다.

ViewCheck — Wed, 23 Sep 2026 21:09:53 +0900

041편 : 본문 글자의 색상을 주로 그레이 계열로 유지하고, 주요 동작에는 primary, secondary, point, system 색상을 적용하고 있다.

KRDS 체크리스트 항목 DS-041 · 디자인 스타일 > 타이포그래피 〈846 규칙 완전 분해 시리즈 ㊶〉 — "글자 색에도 역할이 있다": 타이포그래피와 색상이 만나는 자리

0. 들어가며 — 두 영역이 만나다

타이포그래피의 거의 마지막 편입니다. 그리고 이 편은 타이포그래피와 색상(앞의 26편)이 만나는 자리 입니다.

DS-041은 글자의 색을 규정합니다. 핵심은 두 가지 — 본문 글자는 주로 그레이(Gray) 계열로 유지하고, 주요 동작(버튼·링크 등)에는 primary, secondary, point, system 색상을 적용하라는 것이죠. 글자 색에도 '역할'을 부여하는 것입니다.

이건 색상 규칙들의 연장입니다. 7편(역할 색)에서 색을 Primary·Secondary·Gray로 나눴고, DS-041은 그 역할을 '글자 색'에 적용합니다 — 읽는 본문은 차분한 Gray로, 행동을 유도하는 곳은 강조색으로. 이번 편은 글자 색이 왜 이렇게 나뉘어야 하는지, 색상 규칙과 어떻게 이어지는지를 풀어냅니다.

1. 규칙 원문 — 글자 색의 두 역할

DS-041 (디자인 스타일 > 타이포그래피) "본문 글자의 색상을 ① 주로 그레이 계열로 유지하고, ② 주요 동작에는 primary, secondary, point, system 색상을 적용하고 있다."

① "본문 글자는 주로 그레이 계열"

읽는 본문 텍스트는 회색(Gray) 계열로 유지하라는 뜻입니다. 진한 회색 본문, 연한 회색 보조 텍스트처럼요.

② "주요 동작에는 primary, secondary, point, system"

버튼·링크 등 행동을 유도하거나 상태를 알리는 텍스트에는 강조색(primary·secondary·point·system)을 쓰라는 뜻입니다. point는 강조 포인트 색, system은 상태 색(빨강·노랑·초록·파랑, 13~17편)입니다.

정리: 읽는 본문은 차분한 Gray로, 행동·상태를 알리는 글자는 역할에 맞는 색으로 적용하라. 이게 DS-041입니다.

2. 왜 본문은 그레이인가 — 차분함과 가독성

본문 글자를 회색 계열로 유지하라는 데는 이유가 있습니다.

본문은 '읽는' 텍스트입니다. 길게 이어지는 본문에 강한 색(빨강·파랑 등)을 쓰면, 눈이 피로하고 산만해집니다. 또 본문이 컬러면 '강조'로 오인될 수 있죠 — 색이 있는 글자는 '특별한 의미가 있나?' 하고 주목하게 만드니까요. 본문은 차분한 무채색(Gray)이라야 편안하게 오래 읽힙니다. 진한 회색(거의 검정)이 가독성과 안정감을 동시에 줍니다.

이는 색상 규칙들과 정확히 맞닿습니다. 7편에서 Gray는 '배경·텍스트·구분선'의 색이라 했고(DS-007), 60:30:10 에서 본문은 차분한 60% 영역이라 했죠(DS-009). DS-041은 그 원리를 글자 색에 적용한 것입니다 — 화면의 대부분을 차지하는 본문은 차분한 Gray로 두어, 강조색이 빛날 무대를 마련하는 것이죠.

또한 본문을 Gray 단계로 관리하면 명도 대비(20편)도 챙길 수 있습니다. Gray 단계에서 배경과 매직넘버 50 이상 차이 나는 단계를 본문에 쓰면, 가독성(4.5:1)이 자동 보장됩니다. 본문 Gray는 가독성·차분함·체계성을 한 번에 확보하는 선택입니다.

3. 주요 동작에는 왜 색을 — 행동 유도

반대로 '주요 동작'에는 색을 씁니다. 왜일까요?

버튼·링크처럼 사용자가 행동해야 할 곳, 또는 상태를 알려야 할 곳은 주목받아야 합니다. 차분한 Gray 본문 사이에서 색이 있는 글자(링크의 파랑, 버튼의 강조색)는 도드라져 "여기를 누르세요", "이건 특별합니다"를 전달하죠. 이게 색의 강조 기능입니다(8편).

쓰이는 색은 역할에 따라 다릅니다.

primary — 핵심 행동(주요 버튼·링크). 정부 청색 등(DS-007·008).
secondary — 보조 행동·강조.
point — 포인트 강조색.
system — 상태 알림(오류 빨강·성공 초록 등, 13~17편).

즉 글자 색이 그 글자의 '역할'을 말합니다. 차분한 Gray는 '읽는 정보', 강조색은 '행동·상태'. 사용자는 글자 색만 보고도 "이건 읽는 것, 이건 누르는 것, 이건 경고"를 직관적으로 구분합니다. 색이 글자의 기능을 안내 하는 것이죠.

4. 글자 색도 '색에만 의존하지 말라'

DS-041을 적용할 때 잊지 말아야 할 것이 있습니다 — 글자 색에도 6편(색약)·13편(상태색)의 원리가 적용 됩니다.

링크를 파랑(primary)으로 표시하더라도, 색만으로 링크를 구분하면 색약자나 흑백 환경에서 못 알아봅니다. 그래서 본문 속 링크는 색 + 밑줄을 함께 줘야 하죠(6편, 다음 편 DS-042). 마찬가지로 상태를 system 색으로 표시하더라도, 색 + 아이콘 + 텍스트를 함께 줘야 합니다(13편).

즉 DS-041의 '주요 동작에 색 적용'은 '색만으로'가 아니라 '색을 포함해'입니다. 색은 행동·상태를 직관적으로 알리는 강력한 신호이되, 그 색을 못 보는 사용자를 위해 형태·밑줄·아이콘 등 다른 단서를 함께 제공해야 합니다. 글자 색은 거들 뿐, 의미는 여러 채널로 전달되어야 한다는 원리는 여기서도 그대로입니다.

5. 흔한 위반 패턴 / 점검 / 개선

흔한 위반 패턴

함정 ① 본문에 컬러. 본문을 파랑·빨강 등 컬러로 → 피로, 강조 오인. → 본문은 Gray. 함정 ② 동작에 Gray. 링크·버튼을 회색으로 → 행동 유도 약함. → 강조색 적용. 함정 ③ 색 남용. 본문 곳곳에 컬러 강조 남발 → 산만, 강조 희석. → 절제(8편). 함정 ④ 색만으로 링크. 링크를 색만으로 → 색약자 못 알아봄. → 밑줄 함께(42편).

무엇을 점검하나

본문 색 — 본문이 주로 Gray 계열인가.
동작 색 — 버튼·링크·상태에 적절한 역할색이 적용됐는가.
절제 — 본문에 컬러 강조가 남발되지 않았는가.
다중 채널 — 링크·상태가 색만이 아니라 밑줄·아이콘과 함께인가.

Before / After

/* ❌ Before: 본문 컬러 + 링크 회색 */
body { color: #2266cc; }     /* 본문이 파랑 — 피로·오인 */
a { color: #888; }            /* 링크가 회색 — 행동 유도 약함 */

/* ✅ After: 본문 Gray + 동작 색 */
body { color: var(--gray-80); }        /* 차분한 본문 */
a { color: var(--primary-60); text-decoration: underline; }  /* 링크 강조색+밑줄 */
.text-danger { color: var(--system-danger); }  /* 상태색 */

6. 누가 담당하나 / 우리 사이트에 해당될까?

역할	책임
디자이너	본문은 Gray, 동작은 역할색으로 설계
퍼블리셔/개발	글자 색을 역할 토큰으로 적용

기관 유형	DS-041 적용
중앙행정기관(대표·운영) / 공공기관 / 지자체	✅ 필수

글자가 있는 모든 사이트 = 해당.

7. 30초 자가진단 + FAQ

✅ 30초 자가진단

□ 본문 글자가 차분한 Gray 계열인가요?
□ 버튼·링크에 적절한 강조색이 쓰였나요?
□ 본문에 컬러 강조를 남발하지 않나요?
□ 링크가 색 + 밑줄로 표시되나요(42편)?
□ 상태 글자가 색 + 아이콘·텍스트와 함께인가요(13편)?

❓ FAQ

Q1. 본문에 브랜드색을 쓰면 안 되나요? 본문은 Gray가 원칙입니다. 브랜드색은 버튼·링크 등 동작 영역에 쓰세요. 본문을 브랜드색으로 하면 피로하고, 강조로 오인되며, 정작 강조해야 할 곳이 묻힙니다.

Q2. point 색이 뭔가요? 포인트 강조색으로, 특별히 주목시킬 요소에 쓰는 색입니다. primary·secondary 외에 추가 강조가 필요할 때 사용하되, 역시 절제해야 합니다(강조색 5% 상한, DS-012).

Q3. 보조 텍스트는 연한 Gray로 해도 되나요? 네, 보조 텍스트는 연한 Gray로 위계를 줄 수 있습니다. 단, 명도 대비(20편)는 지켜야 합니다 — 너무 연하면 가독성이 떨어집니다(연회색 본문 함정).

Q4. 링크는 무조건 색을 써야 하나요? 링크는 강조색(primary 등)으로 표시하되, 색만이 아니라 밑줄도 함께 줘야 합니다(6편·42편). 색약자·흑백 환경에서도 링크를 구분할 수 있게요.

Q5. KRDS를 채택하면 자동인가요? KRDS는 본문 Gray, 동작 강조색을 역할 토큰으로 정의합니다. 채택하고 역할에 맞는 토큰을 쓰면 DS-041이 충족됩니다.

8. 마무리 — 색이 글자의 역할을 말한다

DS-041의 메시지는 타이포와 색상을 잇습니다.

글자 색에도 역할이 있다 — 읽는 본문은 차분한 Gray로, 행동·상태는 역할에 맞는 색으로.

본문을 차분한 Gray로 유지하면 편안하게 읽히고, 강조색이 빛날 무대가 마련됩니다. 행동·상태를 알리는 글자에 역할색을 쓰면, 사용자는 글자 색만 보고도 '읽는 것·누르는 것·경고'를 구분합니다. 이는 색에 역할을 부여한 것(7편), 강조를 절제한 것(8편)이 글자에 적용된 모습이죠. 색상과 타이포그래피는 따로가 아니라, '글자 색의 역할'에서 하나로 만납니다.

다음 편은 타이포그래피의 마지막, 밑줄을 다룹니다. DS-042 — "글자 밑줄을 텍스트 링크에만 사용하고, 강조하는 부분에서 사용하지 않는다." 밑줄을 링크 전용으로 남겨야 하는 이유를 살펴봅니다.

다음 편 예고 ▶ 「042. 글자 밑줄을 텍스트 링크에만 사용하고, 강조하는 부분에서 사용하지 않고 있다.」

우리 사이트의 글자 색이 역할에 맞는지 확인하려면? ViewCheck는 본문이 Gray 계열인지, 동작·상태에 적절한 역할색이 쓰였는지, 색이 다른 단서(밑줄·아이콘)와 함께 쓰였는지를 진단합니다.

참고 출처

KRDS 서체(Typography)·색상(Color) 스타일 가이드 — https://www.krds.go.kr/html/site/style/style_03.html

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

두 엔진의 분업과 협업 — 코드 보는 엔진, 화면 보는 엔진

ViewCheck — Wed, 23 Sep 2026 21:09:48 +0900

두 엔진의 분업과 협업 — 코드 보는 엔진, 화면 보는 엔진

들어가며 — 판단 시점의 문을 여는 이야기

지난주까지 웹 품질을 보는 세 가지 시점을 한 바퀴 돌았습니다. 만들기 전에 보는 설계 시점, 만든 뒤에 보는 운영 시점, 그리고 그 위에서 무엇부터 손댈지를 정하는 판단 시점. 그중 설계 시점(Figma 분석)을 지난주에 다뤘고, 그 앞선 주에는 운영 시점(URL 분석)을 봤습니다. 이번 주는 마지막 남은 시점, 바로 판단 시점의 문을 엽니다.

그런데 판단 시점 이야기를 제대로 하려면, 그 밑에 깔린 구조부터 짚고 가야 합니다. ViewCheck가 사이트 하나를 분석할 때, 실제로는 성격이 다른 두 개의 엔진이 함께 일합니다. 하나는 화면 뒤의 코드를 읽어 판정하는 규칙 엔진이고, 다른 하나는 실제로 그려진 화면(스크린샷)을 보고 무엇이 있는지 감지하는 시각 AI 엔진입니다. 오늘은 이 두 엔진이 어떻게 나눠 일하고, 어떻게 협업해서 하나의 결과로 합쳐지는지를 정리하겠습니다.

핵심 질문은 이것입니다. "왜 엔진이 둘이나 필요할까요? 하나로 다 하면 안 될까요?" 답은 지난 몇 주에 이미 깔려 있습니다. 코드만 보면 화면을 놓치고(이미지로 만든 버튼 같은 것들), 화면만 보면 구조를 놓칩니다(코드 속 라벨 같은 것들). 두 엔진은 애초에 보는 대상이 달라서, 하나로는 절반밖에 못 봅니다. 그래서 둘이 나눠 보고 합치는 것입니다. 사람으로 치면, 코드를 잘 읽는 사람과 화면을 잘 보는 사람이 같은 사이트를 같이 점검하는 셈입니다.

오늘 글은 이 둘이 각각 무엇을 잘하는지, 어떤 순서로 일하는지, 그리고 합칠 때 어떤 규칙을 지키는지를 차근차근 풉니다. 조금 구조적인 이야기라 천천히 가겠습니다. 이번 달은 세 가지 방법을 개요로 훑는 달이니, 깊은 기술은 다음 달 이후로 미루고 "둘이 왜, 어떻게 나눠 일하는가"의 큰 틀에 집중합니다. 이 틀이 잡히면, 왜 ViewCheck가 엔진을 둘로 나눴는지, 그리고 왜 그 편이 "하나짜리"보다 나은지가 보입니다.

한 가지 미리 말씀드릴 것이 있습니다. 오늘 이야기는 지난 몇 주 동안 깔아온 큰 그림의 한 조각입니다. 첫 주에 "한 관점으로는 절반만 보인다"고 했고, 그다음 주들에서 운영과 설계 시점을 봤습니다. 오늘은 그 세 번째 시점(판단) 안에서 "코드와 화면을 어떻게 같이 보는가"를 푸는 것입니다. 돌이켜보면 여태 드린 이야기는 결국 하나였습니다. 한 관점으로는 절반만 보이니, 여러 관점을 나눠 보고 합치자는 것. 두 엔진 이야기는 그 원리를 분석 엔진 수준에서 그대로 구현한 사례입니다.

미리 한 가지 오해를 풀고 가겠습니다. "엔진이 둘"이라고 하면 흔히 "같은 일을 두 번 해서 서로 대조하는 이중 점검"을 떠올리십니다. 그런데 여기서 말하는 두 엔진은 그런 이중 점검이 아닙니다. 같은 일을 두 번 하는 것이 아니라, 아예 다른 일을 나눠서 하는 것입니다. 코드 엔진은 코드로만 볼 수 있는 것을 보고, 화면 엔진은 화면으로만 볼 수 있는 것을 봅니다. 겹치는 영역이 아니라 보완하는 영역인 것이지요. 그래서 둘의 결과를 합쳐도 "누가 맞나"를 두고 다투는 구조가 아니라, "네가 못 본 걸 내가 봤다"고 서로 채워주는 구조입니다. 이 차이를 먼저 잡아두면 오늘 이야기가 훨씬 선명하게 들어옵니다.

본론 1 — 두 엔진은 보는 게 다르다

먼저 두 엔진이 각각 무엇을 보는지부터 정리하겠습니다. 이름은 편의상 "코드 보는 엔진"과 "화면 보는 엔진"으로 부르겠습니다.

코드 보는 엔진 (규칙 엔진)

첫 번째 엔진은 화면 뒤의 구조, 즉 코드를 봅니다. 웹페이지는 우리가 보는 화면 뒤에 그 화면을 만들어내는 코드(HTML 구조)가 있습니다. 규칙 엔진은 그 코드를 읽어서 판정합니다. "이 버튼에 이름(라벨)이 붙어 있는가", "제목 구조(h1부터 h6까지)가 논리적으로 짜여 있는가", "이 입력창에 설명이 제대로 연결돼 있는가" 같은 것들을 봅니다.

이 엔진이 잘하는 것은 명확하고 빠른 판정입니다. 코드는 기계가 읽기 좋은 형태라서, "있다/없다", "맞다/틀리다"가 딱 떨어집니다. 그래서 1초에서 3초 남짓이면 846개 규칙을 한 번 훑습니다. 빠르고, 일관되고, 몇 번을 돌려도 같은 결과가 나옵니다. 사람이 손으로는 도저히 감당 못 하던 규모와 일관성을, 이 엔진이 해결합니다. 분석의 뼈대를 빠르게 세우는 역할입니다.

여기서 846개 규칙이라는 게 무엇인지 잠깐 짚겠습니다. KRDS(정부 디지털 서비스의 디자인 기준)를 자동 판정 항목으로 풀어놓은 것이 846개인데, 성격에 따라 네 묶음으로 나뉩니다. 색·타이포·간격 같은 디자인 스타일(DS)이 120개, 버튼·폼·표 같은 컴포넌트(CP)가 446개, 폼 구조나 오류 처리 같은 기본 패턴(BP)이 108개, 검색·로그인·신청 같은 서비스 패턴(SP)이 172개입니다. 이 네 묶음을 더하면 정확히 846개입니다. 규칙 엔진은 이 846개를 코드 기준으로 한 항목씩 판정합니다. 아래 화면이 그 코드 기반 판정이 카테고리별로 어떻게 정리되는지를 보여주는데, 규칙 하나하나가 통과·미통과로 떨어지는 것이 코드 엔진의 1차 결과물입니다.

KRDS 규칙 검증 결과에서 컴포넌트 규칙들이 통과·미통과·해당없음으로 상세하게 판정된 목록 화면. 코드 엔진이 만든 1차 판정 뼈대가 규칙별로 딱딱 떨어지는 모습 (기관명·도메인 블러)

다만 이 엔진에게도 못 보는 영역이 있습니다. "코드에 드러나지 않는 것"입니다. 이미지로 만든 버튼, 시각적으로만 구분되는 위계, 색 대비가 실제 화면에서 주는 느낌 같은 것들이지요. 코드만 읽으니, 코드에 안 적힌 것은 알 도리가 없습니다. 이것이 규칙 엔진 단독의 한계이고, 바로 여기서 두 번째 엔진이 필요해집니다.

이 한계를 조금 더 구체적으로 그려보겠습니다. 예를 들어 어떤 버튼을 개발자가 정식 버튼 태그가 아니라 이미지 한 장으로 만들어 얹어두었다고 하겠습니다. 화면에서는 누가 봐도 버튼이지만, 코드로 읽으면 그냥 그림 파일 하나입니다. 규칙 엔진은 그 자리에서 "버튼이 없다"가 아니라 "버튼에 대해 판정할 것이 없다", 즉 해당없음(N/A)으로 처리합니다. 코드에 버튼이 안 적혀 있으니 버튼 규칙을 적용할 대상 자체가 없다고 보는 것이지요. 문제는 여기서 생깁니다. 그 자리에 실제로는 버튼이 있고, 게다가 이름도 없어서 화면을 못 보는 사용자에게는 아무것도 아닌 요소인데, 코드만 보는 엔진은 이 위반을 "해당없음"이라는 빈칸으로 남겨버립니다. 위반이 없어서 통과가 아니라, 못 봐서 빈칸인 것입니다. 이 빈칸이 뒤에서 계속 이야기할 "가짜 N/A"이고, 두 번째 엔진이 존재하는 가장 큰 이유입니다.

화면 보는 엔진 (시각 AI 엔진)

두 번째 엔진은 실제로 그려진 화면, 즉 스크린샷을 봅니다. 사람이 눈으로 화면을 훑듯, 이미지를 보고 "여기 버튼이 있네", "이건 카드 모양이네", "이 영역은 표처럼 보이네" 하고 인식합니다. 코드가 아니라 생김새로 판단하는 것입니다.

이 엔진이 잘하는 것은 코드에 드러나지 않는 시각적인 요소입니다. 이미지로 만든 버튼도 화면에서는 버튼처럼 보이니까 감지하고, 요소들이 화면상에서 어떻게 배치돼 있는지, 어떤 것이 어떤 것과 시각적으로 묶여 있는지를 봅니다. 사용자가 실제로 마주하는 것은 코드가 아니라 화면이므로, 화면을 보는 이 엔진이 "사용자 관점"에 가장 가깝습니다.

화면 엔진의 강점을 조금 더 풀면 이렇습니다. 코드가 어떻게 짜여 있든, 사용자는 화면에 그려진 것을 봅니다. 그러니 화면을 보는 엔진은 "사용자 경험"을 가장 직접적으로 봅니다. 코드로는 완벽한데 화면에서는 두 요소가 겹쳐 보인다면, 사용자에게는 겹쳐 보이는 것이 현실입니다. 화면 엔진은 그 현실을 잡습니다. 그래서 코드 엔진이 "기준대로 만들어졌는가"를 본다면, 화면 엔진은 "실제로 그렇게 보이는가"를 봅니다. 미묘하지만 중요한 차이입니다. 만들어진 것과 보이는 것이 언제나 같지는 않으니까요. 이것은 설계 시점에서 봤던 "도면과 결과물은 다를 수 있다"는 이야기의 엔진 버전이기도 합니다.

다만 화면 엔진은 코드 엔진만큼 빠르거나 명확하지는 않습니다. 화면을 인식하는 일은 코드를 읽는 일보다 무겁고, "이게 정말 버튼이 맞는가"에는 확신도가 따라붙습니다. 그래서 모든 판정을 이 엔진에게만 맡기면 느려지고 결과가 들쑥날쑥할 수 있습니다. 화면 인식이라는 무거운 작업을, 꼭 필요한 곳에만 써야 하는 이유입니다. 이 점은 뒤에서 순서 이야기를 할 때 다시 짚겠습니다.

둘은 상호 보완이다

정리하면 이렇습니다. 코드 엔진은 빠르고 명확하지만 시각을 못 봅니다. 화면 엔진은 시각을 보지만 무겁고 덜 명확합니다. 공교롭게도 서로의 약점이 정확히 상대의 강점입니다. 그래서 둘을 하나로 뭉치기보다, 나눠서 각자 잘하는 일을 시키고 결과를 합치는 편이 낫습니다. 첫 주에 "세 시점은 경쟁이 아니라 분업"이라고 말씀드렸는데, 두 엔진도 똑같이 분업입니다.

비유하자면 건물 점검에 두 전문가가 붙는 것과 비슷합니다. 한 명은 설계도면과 자재 명세서(코드)를 꼼꼼히 봅니다. 다른 한 명은 실제로 지어진 건물을 눈으로 둘러봅니다(화면). 도면만 보면 "실제로 어떻게 보이는지"를 알 수 없고, 눈으로만 보면 "벽 안에 무엇이 들었는지"를 알 수 없습니다. 둘이 같이 봐야 안과 밖이 다 잡힙니다. 웹도 똑같습니다. 코드(안)와 화면(밖)을 둘 다 봐야 합니다. 한 명에게 둘 다 시키는 것보다, 각 분야 전문가가 나눠 보고 결과를 합치는 편이 빠르고 정확합니다.

왼쪽에서 코드 구조 트리를 빠르고 정확하게 읽는 엔진과, 오른쪽에서 그려진 화면 이미지를 보며 이미지로 된 버튼을 잡아내는 엔진, 두 출력이 화살표로 하나의 결과 시트로 합쳐지는 개념 도식 (Gemini 1:1)

한 가지 덧붙이면, 이 분업은 "정확도"만을 위한 것이 아닙니다. 뒤에서 자세히 보겠지만, 화면 인식은 코드 읽기보다 시간도 자원도 더 듭니다. 그래서 두 엔진을 나눠 쓰면 정확도와 효율을 동시에 챙길 수 있습니다. 값싸고 빠른 코드 판정으로 대부분을 처리하고, 무겁고 정밀한 화면 인식은 꼭 필요한 곳에만 쓰는 것이지요. 이 "정확도와 효율을 함께 잡는다"는 것이 두 엔진 구조의 진짜 이득인데, 그 얼개가 다음에 볼 "순서"에 담겨 있습니다.

본론 2 — 어떤 순서로 일하나

두 엔진이 동시에 마구잡이로 일하는 것은 아닙니다. 효율을 위해 순서가 있습니다. 이 순서를 이해하면, 왜 이 구조가 빠르면서도 촘촘한지가 보입니다.

1단계: 규칙 엔진이 뼈대를 빠르게 세운다

가장 먼저 규칙 엔진이 846개 규칙을 빠르게 훑습니다. 코드로 명확히 답이 나오는 항목은 여기서 거의 다 처리됩니다. 통과·미통과가 확정되고, 코드로는 도저히 볼 수 없는 것은 해당없음(N/A)으로 남습니다. 이것이 1차 뼈대입니다. 빠르니까(1초에서 3초) 먼저 돌려서 큰 틀을 잡는 것입니다.

이 단계가 끝나면 상당수의 N/A가 남습니다. 그중에는 정당한 N/A(그 페이지에 정말 해당 요소가 없어서 판정할 것이 없는 경우)도 있고, 이른바 "가짜 N/A"(화면에는 있는데 코드로 못 봐서 빠진 경우)도 섞여 있습니다. 이 둘을 갈라내는 것이 다음 단계의 몫입니다.

이 두 종류의 N/A를 구별하는 것이 왜 중요한지 짚고 넘어가겠습니다. 정당한 N/A는 문제가 아닙니다. 예를 들어 로그인 화면에 표가 없으면 표 관련 규칙은 당연히 해당없음이고, 이건 정직한 판정입니다. 그 페이지에 없는 것을 억지로 있다고 할 수는 없으니까요. 반면 가짜 N/A는 문제입니다. 화면에는 분명히 있는데 코드로 못 봐서 빠진 것이라, 실제로는 위반일 수 있는 것이 조용히 "해당없음"으로 묻혀버립니다. 만약 이 둘을 구별하지 않고 N/A를 전부 "괜찮은 것"으로 뭉뚱그리면, 사이트가 실제보다 좋아 보이는 착시가 생깁니다. 위반이 될 뻔한 것들이 빈칸 뒤에 가려지니까요. 그래서 규칙 엔진이 세운 뼈대에는 이 착시의 위험이 남아 있고, 그 위험을 걷어내는 것이 바로 화면 엔진이 다음에 할 일입니다.

2단계: 화면 엔진이 빈칸을 본다

그다음 화면 엔진이 들어옵니다. 그런데 여기가 똑똑한 부분인데, 화면 엔진이 모든 것을 다 보는 것이 아닙니다. 규칙 엔진이 이미 확정한 항목은 건드리지 않고, N/A로 남은 빈칸 위주로 화면을 봅니다. "코드로는 버튼 없음(N/A)이었는데, 화면에는 정말 버튼이 있는가?"를 확인하는 것이지요.

이렇게 하면 효율적입니다. 화면 인식은 무거운 작업이라, 모든 규칙을 다 화면으로 보면 분석 한 번이 너무 오래 걸립니다. 대신 코드로 이미 끝난 항목은 빼고 빈칸만 화면으로 보면, 빠르면서도 빈칸이 채워집니다. 규칙 엔진이 큰 그물로 먼저 거르고, 화면 엔진이 그 그물을 빠져나간 것만 촘촘히 줍는 식입니다.

왼쪽에서 오른쪽으로 흐르는 컨베이어 벨트 같은 3단계 파이프라인. 1단계 코드 엔진이 빈칸이 있는 뼈대 격자를 빠르게 세우고, 2단계 화면 엔진이 그 빈칸을 채우고, 3단계에서 판단 기능이 그 위에 우선순위와 개선 메모를 얹는 개념 도식 (Gemini 1:1)

생각해보면 이것은 사람이 일하는 방식과도 닮았습니다. 점검을 두 명이 한다면, 한 명이 빠르게 명확한 것부터 쫙 처리하고, 다른 한 명은 "이건 애매하니 자세히 봐 달라"고 넘겨받은 것만 집중해서 봅니다. 둘 다 모든 것을 처음부터 다 보면 시간 낭비니까요. 빠른 1차 거르기와 남은 것의 정밀 확인. 이 분업이 사람 팀에서도, 두 엔진 사이에서도 똑같이 효율적입니다. 무거운 작업(화면 인식)을 꼭 필요한 데만 쓰는 것이 핵심입니다.

3단계: 합치고, 그 위에 판단을 얹는다

두 엔진의 결과를 합치면, 코드로 본 것과 화면으로 채운 것이 더해져 더 촘촘한 판정이 됩니다. 규칙 엔진 혼자였을 때보다 판정된 항목의 비율이 올라가고, N/A는 줄어듭니다. 그리고 그 위에 판단 기능이 우선순위를 매기고 개선안을 더합니다. 코드로 뼈대, 화면으로 빈칸, 그 위에 판단. 이 세 단계가 이어지는 것입니다. 각 단계가 앞 단계의 결과를 받아서 다음으로 넘기는, 일종의 컨베이어 벨트처럼 흐릅니다. 그래서 사람이 중간중간 손으로 결과를 옮기거나 합칠 필요 없이, 한 번 돌리면 끝까지 이어집니다.

이 "판단을 얹는다"는 대목이 바로 이번 주가 여는 판단 시점의 이야기입니다. 두 엔진이 촘촘한 판정을 만들어내면, 그 위에서 "이 위반이 우리 기관 상황에서 얼마나 급한가", "무엇부터 손대야 하는가"를 정리하는 단계가 얹힙니다. 그 판단 단계 자체가 무엇인지는 이번 주 수요일 글에서 본격적으로 풀고, 그 판단이 실제로 어떻게 결과를 읽고 개선안까지 내놓는지는 금요일 글에서 이어가겠습니다. 오늘은 그 판단이 딛고 서는 토대, 즉 두 엔진의 협업 구조를 잡는 자리입니다.

왜 이 순서가 중요한가

순서를 거꾸로 하면 비효율적입니다. 화면 엔진으로 전부 다 본 다음에 코드로 확인한다면, 무거운 작업을 다 해놓고 나서 거르는 셈이라 느립니다. 코드로 먼저 빠르게 거르고, 남은 빈칸만 화면으로 보는 편이 빠르면서도 빠짐이 없습니다. "값싸고 빠른 것을 먼저, 무겁고 정밀한 것은 필요한 데만." 이것이 두 엔진을 효율적으로 쓰는 핵심 원칙입니다.

이 원칙이 실무에서 왜 중요한지는 규모를 떠올리면 분명해집니다. 공공 사이트는 페이지가 수십에서 수백 장에 이르는 경우가 많습니다. 한 페이지당 846개 규칙을 판정하는데, 만약 그 전부를 무거운 화면 인식으로 처리한다면 사이트 한 곳을 보는 데만 엄청난 시간과 비용이 듭니다. 그런데 대부분을 값싼 코드 판정으로 처리하고 화면은 빈칸만 본다면, 같은 규모라도 훨씬 가볍게 끝납니다. 페이지가 많아질수록 이 순서의 이득이 커집니다. 다중 페이지 분석의 구체적인 원리와 집계 방식은 6개월차(다중 페이지 분석)에서 깊게 다루는데, 오늘은 "코드로 먼저 거르는 순서가 규모에 강하다" 정도만 잡고 가시면 됩니다.

본론 3 — 합칠 때 지키는 규칙

두 엔진의 결과를 합치는 일은 단순히 더하는 것이 아닙니다. 잘못하면 충돌이 나서 오히려 결과가 흔들립니다. 그래서 합칠 때 지키는 규칙이 필요합니다. 네 가지로 정리하겠습니다.

규칙 ① 코드가 확정한 건 뒤집지 않는다

규칙 엔진이 "이 버튼에는 라벨이 없으니 미통과"라고 명확히 판정한 항목은, 화면 엔진이나 판단 기능이 "그래도 괜찮아 보이는데" 하고 바꾸지 않습니다. 코드로 확실한 것은 확실한 것이니까요. 화면 엔진은 어디까지나 "코드가 못 본 빈칸"을 채우는 역할이지, 코드의 판정을 검열하는 역할이 아닙니다.

왜 이것이 중요한가 하면, 이 규칙을 안 지키면 결과가 들쑥날쑥해지기 때문입니다. 같은 사이트를 돌렸는데 어제는 통과, 오늘은 미통과가 되면, 사람 점검에서 봤던 그 기준 흔들림이 이번에는 자동 분석에서 재현됩니다. 자동화의 가장 큰 장점이 일관성인데, 그 장점이 무너지는 것이지요. 그래서 "확정된 것은 고정"이라는 울타리가 일관성을 지킵니다. 두 번 돌리면 같은 답이 나와야 그 결과를 근거로 쓸 수 있습니다.

규칙 ② 화면 엔진은 빈칸만 채운다

화면 엔진이 채우는 것은 N/A로 남은 빈칸입니다. 코드로는 "버튼 없음"이었는데 화면에는 버튼이 있으면, 그 빈칸을 "버튼 있음, 그리고 이러이러하니 판정"으로 채웁니다. 빈칸을 채우는 것이지, 이미 채워진 칸을 다시 쓰는 것이 아닙니다. 이렇게 역할을 명확히 나누면 두 엔진이 같은 항목을 두고 부딪히지 않습니다. 규칙 ①과 ②는 사실 한 몸입니다. "코드가 채운 칸은 코드 것, 빈칸만 화면 것"이라는 담당 구역이 분명하니, 서로의 영역을 넘보지 않습니다.

규칙 ③ 확신도를 같이 단다

화면 인식에는 확신도가 따라붙습니다. "이것이 버튼일 확률이 높다"와 "버튼인지 애매하다"는 다릅니다. 확신이 높은 것은 판정에 반영하고, 애매한 것은 함부로 단정하지 않습니다. 확신 없는 것을 억지로 채워 넣으면 오히려 부정확해지니까요. 그래서 확신도로 걸러서 믿을 만한 것만 채우고, 애매한 것은 솔직하게 N/A로 남깁니다.

이 대목이 특히 중요합니다. "빈칸을 채운다"는 말이 "빈칸을 무조건 다 메운다"는 뜻이 아니기 때문입니다. 화면에 뭔가 있긴 한데 그것이 버튼인지 장식인지 확신이 서지 않으면, 우겨서 "버튼 있음"으로 채우지 않습니다. 확신이 없으면 없다고 두는 것이지요. 이렇게 하는 이유는 단순합니다. 없는 것을 지어내지 않기 위해서입니다. 화면 엔진이 애매한 것까지 다 채워버리면, 실제로는 없는 위반을 만들어내거나 실제로는 없는 컴포넌트를 있다고 우기게 됩니다. 그것은 분석이 아니라 창작입니다. 그래서 "증거가 확실할 때만 채우고, 애매하면 N/A로 남긴다"는 원칙이 결과의 신뢰를 지킵니다. 감지 못 한 것을 억지로 지어내지 않으니, 화면 엔진이 채운 빈칸은 그만큼 믿을 만합니다.

여기서 짚고 싶은 것은, 이 절제가 겉으로는 손해처럼 보인다는 점입니다. 애매한 것을 다 채우면 판정된 항목 수가 늘어나 보이고, 빈칸이 줄어드니 겉보기엔 더 촘촘한 분석처럼 느껴집니다. 그런데 그 늘어난 판정 중에 틀린 것이 섞여 있으면, 결과 전체를 못 믿게 됩니다. 담당자가 그 결과를 보고 멀쩡한 요소를 고치느라 시간을 쓰거나, 반대로 잘못된 "통과" 판정을 믿고 진짜 문제를 방치하게 되니까요. 그래서 화면 엔진은 "많이 채우는 것"보다 "확실한 것만 채우는 것"을 택합니다. 숫자를 예쁘게 만드는 대신, 채운 것 하나하나를 믿을 수 있게 만드는 쪽을 고른 것이지요. 증거에 근거해서만 판정하고, 증거가 없으면 솔직히 못 봤다고 남기는 이 태도가, 결국 결과를 오래 신뢰받게 만듭니다.

규칙 ④ 근거를 남긴다

합친 결과의 각 판정에는 "왜 이렇게 판정했는가"가 따라붙어야 합니다. "코드에 라벨이 없어서 미통과", "화면에서 버튼이 감지돼서 판정", "KRDS 몇 번 규칙 위반" 같은 근거 말입니다. 근거가 있어야 사람이 검토하고 믿을 수 있습니다. 근거 없는 판정은 결국 추측일 뿐입니다.

근거가 어느 엔진에서 나왔는지까지 함께 있으면 더 좋습니다. "이 판정은 코드 기반", "이것은 화면 인식 기반(확신도 높음)"처럼요. 그러면 사람이 검토할 때 판단이 쉬워집니다. "코드 기반이면 거의 확실하겠구나", "화면 기반이면 한 번 더 눈으로 볼까" 하고 나눠서 대할 수 있습니다. 어느 엔진이 어떤 근거로 판정했는지가 투명하면, 결과를 더 잘 믿거나 적절히 의심할 수 있습니다. 블랙박스처럼 "그냥 위반이래"가 아니라 "코드에 라벨이 없어서, 라는 이유로 위반"이면 검토도 빠르고 고치기도 쉽습니다.

이 네 규칙을 지키면 두 엔진의 결과가 충돌 없이 일관되게 합쳐집니다. 그냥 두 결과를 섞는 것이 아니라, "코드 우선, 화면은 빈칸만 보강, 확신도로 거르고, 근거를 단다"는 질서가 있는 것입니다. 아래는 그 두 엔진 결과가 합쳐진 뒤, KRDS 표준 대비 어디가 얼마나 차이 나는지를 비교해 보여주는 화면입니다. 코드로 본 것과 화면으로 채운 것이 하나의 비교표로 정리됩니다.

AI 종합보고서의 KRDS 비교분석 표준대비 화면. 두 엔진의 판정이 합쳐진 결과를 KRDS 표준과 나란히 비교해 어디가 얼마나 차이 나는지 보여주는 표준대비 탭 (기관명·도메인 블러)

왜 "섞기"가 아니라 "질서"가 필요한가

두 엔진의 결과를 아무 규칙 없이 그냥 합치면 오히려 더 혼란스러워집니다. 같은 버튼을 두고 코드 엔진은 "통과", 화면 엔진은 "애매함"이라고 하면, 둘 중 무엇을 따라야 할까요? 질서가 없으면 그때그때 다르게 처리돼서 결과를 믿을 수 없게 됩니다. 그래서 "코드가 확정한 것은 코드를 따른다, 화면은 코드가 비운 데만 본다"는 우선순위가 미리 정해져 있어야 합니다. 이 우선순위 덕분에 두 엔진이 같은 것을 두고 다투지 않습니다. 각자 담당 구역이 명확하니까요. 협업이 잘 되는 팀이 "누가 무엇을 맡는지" 분명한 것처럼, 두 엔진도 담당이 명확해야 결과가 깔끔합니다.

이 질서가 없으면 어떤 일이 벌어지는지 상상해보면 이해가 빠릅니다. 규칙 없이 두 엔진의 목소리를 섞으면, 확신 높은 코드 판정을 애매한 화면 인식이 흔들어버리는 일이 생깁니다. 명확하게 미통과였던 것이 "화면으로는 괜찮아 보인다"는 이유로 통과로 바뀌고, 다음번엔 또 다르게 나오고요. 그렇게 되면 자동 분석의 존재 이유였던 "일관되고 재현 가능한 결과"가 사라집니다. 결국 두 엔진을 두는 것보다, 규칙 엔진 하나만 쓰는 것보다도 못한 결과가 될 수 있습니다. 그래서 "무엇을 우선하고, 누가 어디를 채우고, 어디까지 믿을지"의 질서가 두 엔진 구조의 진짜 핵심입니다. 엔진이 둘이라는 사실보다, 둘을 질서 있게 합친다는 사실이 더 중요합니다.

본론 4 — 하나짜리보다 나은 이유

이제 처음의 질문으로 돌아가겠습니다. "그냥 하나로 다 하면 안 될까요?" 왜 굳이 둘로 나눴을까요. 두 가지 "하나짜리"를 각각 상상해보면 답이 나옵니다.

하나로 코드만 보면

코드만 보는 엔진 하나로 하면, 빠르고 일관되지만 앞서 말한 가짜 N/A를 못 채웁니다. 이미지로 만든 버튼, 비표준 방식으로 구현된 요소가 다 N/A로 빠져서 "절반만 본 분석"이 됩니다. 그러면 위반이 실제보다 적어 보이는 착시가 생깁니다. 판정된 항목만 놓고 보면 점수가 그럴듯한데, 사실은 코드로 못 본 영역이 통째로 빠져 있는 것이지요. 이 착시는 위험합니다. "우리 사이트 괜찮네" 하고 넘겼는데, 실은 화면으로만 보이는 문제들이 그대로 남아 있는 상태니까요.

하나로 화면만 보면

반대로 화면만 보는 엔진 하나로 하면, 시각은 잡지만 느리고 덜 명확합니다. 코드로 1초면 끝날 명확한 판정까지 무겁게 화면으로 처리하니 비효율적이고, 확신도 문제로 결과가 들쑥날쑥할 수 있습니다. 빠르고 확실한 영역까지 굳이 화면으로 보는 것은 낭비입니다. 게다가 화면 인식만으로는 코드 속에 숨은 구조 정보(라벨이 있는지, 제목 위계가 논리적인지 같은 것)를 정확히 읽기 어렵습니다. 화면에는 안 드러나지만 코드에는 적혀 있는 정보를 놓치게 되는 것이지요. 결국 화면만 보는 엔진도 절반만 보는 것은 마찬가지입니다. 놓치는 절반이 반대쪽일 뿐입니다.

둘로 나누면

둘로 나누면 각자 잘하는 것을 합니다. 코드로 빠르고 확실한 것은 코드가 처리하고, 화면으로만 보이는 것은 화면이 채웁니다. 그래서 빠르면서(코드가 대부분 처리) 빠짐이 없고(화면이 빈칸 보강), 일관되면서(코드 우선 규칙) 시각까지 봅니다(화면 엔진). 하나짜리 각각의 약점을 둘이 서로 메우는 구조입니다.

비용 측면에서도 그렇습니다. 화면 인식은 코드 읽기보다 무겁습니다. 시간도 자원도 더 듭니다. 모든 규칙을 다 화면으로 보면 분석 한 번이 너무 오래 걸리고 비싸집니다. 그런데 코드로 대부분을 처리하고 화면은 빈칸만 보면, 무거운 작업을 최소한만 쓰니까 빠르고 경제적입니다. "정확도"와 "효율"을 동시에 잡는 것이지요. 둘 중 하나만 쓰면 정확도(코드만)나 효율(화면으로 다 보기) 중 하나를 포기해야 하는데, 나눠 쓰면 둘 다 챙깁니다. 이것이 분업의 진짜 이득입니다.

이 이득이 실무에서 어떻게 체감되는지 잠깐 그려보겠습니다. 만약 화면만 보는 엔진 하나로 수백 페이지짜리 사이트를 분석한다면, 담당자는 결과를 받기까지 오래 기다려야 합니다. 그렇다고 코드만 보는 엔진 하나로 빠르게 끝내면, 결과는 금방 나오지만 이미지 버튼 같은 문제가 통째로 빠진 "절반짜리 보고서"를 손에 쥐게 됩니다. 두 경우 모두 담당자에게는 반쪽짜리 선택입니다. 두 엔진 구조는 이 딜레마를 없앱니다. 코드로 빠르게 대부분을 끝내니 결과가 지나치게 오래 걸리지 않고, 화면으로 빈칸을 메우니 절반이 빠지지도 않습니다. "빨리 받되 빠짐없이 받는다"가 가능해지는 것이지요. 속도와 완성도 중 하나를 포기하라는 요구를 받지 않는다는 것, 이것이 사용하는 입장에서 느끼는 두 엔진의 가장 실질적인 값어치입니다.

이것이 여태 계속 나온 그 원리입니다. 한 관점만으로는 절반만 봅니다. 코드 관점과 화면 관점을 나눠 보고 합쳐야 전체가 보입니다. 두 엔진은 그 원리를 분석 엔진 수준에서 구현한 것입니다. 사람이 부서를 나눠 협업하듯, 엔진도 관점을 나눠 협업합니다. 그리고 사람 협업과 마찬가지로, 나눈다는 사실보다 잘 합친다는 사실이 성패를 가릅니다.

한 걸음 더 들어가 보면, "둘로 나눈다"는 선택에는 또 다른 장점이 숨어 있습니다. 각 엔진을 따로 발전시킬 수 있다는 점입니다. 하나의 엔진이 코드와 화면을 뭉뚱그려 처리한다면, 어느 한쪽을 개선하려 할 때 다른 쪽까지 건드리게 되어 조심스러워집니다. 그런데 둘이 분리돼 있으면, 코드 판정 로직은 코드 판정대로 정교하게 다듬고, 화면 인식은 화면 인식대로 따로 발전시킬 수 있습니다. 담당이 나뉘어 있으니 개선도 나뉘어 이뤄지는 것이지요. 서로의 영역을 침범하지 않으면서 각자 깊어질 수 있다는 것은, 오래 유지하고 발전시켜야 하는 분석 도구에서 무시할 수 없는 이점입니다. 지금 잘 나눠둔 구조가, 앞으로 두 엔진을 각각 더 정확하게 만들 수 있는 여지를 남겨두는 셈입니다.

본론 5 — 버튼 하나가 두 엔진을 거치는 과정

말로만 하면 다소 추상적이니, "버튼 하나"가 두 엔진을 어떻게 거치는지 따라가 보겠습니다. 세 가지 버튼 사례로 풀겠습니다. 이 세 장면을 보면 두 엔진의 협업이 한눈에 들어옵니다.

사례 ① 코드에 멀쩡하게 있는 버튼

표준 방식으로 만든 버튼이 있다고 하겠습니다. 코드에 버튼 태그로 제대로 되어 있고, 이름(라벨)도 붙어 있습니다.

규칙 엔진: "버튼 있음, 라벨 있음, 크기 충분 → 통과." 끝. 명확하게 처리됩니다.
화면 엔진: 이미 확정됐으니 보지 않습니다(규칙 ①②에 따라 빈칸이 아니므로 건드리지 않습니다).
결과: 통과. 규칙 엔진이 순식간에 마무리합니다.

이런 경우가 대부분입니다. 그래서 규칙 엔진이 빠르게 뼈대를 세울 수 있는 것입니다. 잘 만든 사이트일수록 이 사례의 비율이 높고, 그만큼 분석이 가볍게 끝납니다.

KRDS 규칙 검증에서 버튼·입력창·표 등 컴포넌트가 규격·구조·상태 기준으로 통과·미통과 판정된 컴포넌트 상세보기 목록. 부품 하나하나가 어떤 근거로 판정됐는지 규칙별로 펼쳐진 뷰 (기관명·도메인 블러)

사례 ② 이미지로 만든 버튼

화면에서는 분명 버튼인데, 코드로는 그냥 이미지인 경우입니다.

규칙 엔진: "여기는 이미지네. 버튼 규칙은 해당없음(N/A)." 빈칸으로 남깁니다.
화면 엔진: 빈칸을 살펴보다가 "어라, 화면에는 여기 버튼처럼 생긴 것이 있네. 확신도 높음." → 그 빈칸을 "버튼 있음"으로 채우고 판정합니다. "그런데 이 버튼, 이름이 없어서 화면을 못 보는 사용자가 쓰는 스크린리더로는 안 읽히겠는데? → 미통과."
결과: 미통과(화면 엔진이 빈칸을 채워 발견). 규칙 엔진만 있었다면 N/A로 묻혔을 위반이 드러납니다.

이것이 바로 앞서 말한 "가짜 N/A를 채우는" 실제 모습입니다. 코드만 봐서는 "해당 없음"으로 조용히 넘어갔을 문제가, 화면을 보는 엔진 덕분에 수면 위로 올라옵니다. 이런 이미지 버튼은 겉보기엔 멀쩡해서 담당자도 눈치채기 어려운데, 정작 화면을 못 보는 사용자에게는 아무 이름도 없는 버튼이 됩니다. 두 엔진 구조가 실제로 값어치를 하는 대목이 여기입니다.

사례 ③ 애매한 것

화면에 뭔가 있긴 한데, 버튼인지 그냥 장식인지 애매한 경우입니다.

규칙 엔진: 코드로도 불분명함 → N/A.
화면 엔진: "버튼 같기도 하고 아닌 것 같기도… 확신도 낮음." → 억지로 단정하지 않고 N/A로 남깁니다(규칙 ③).
결과: N/A로 솔직하게 남김. 확신 없는 것을 우겨넣어 부정확하게 만드느니, 못 봤다고 두는 편이 낫습니다.

이 세 사례를 나란히 보면 두 엔진이 어떻게 협업하는지가 한눈에 보입니다. 명확한 것은 코드가 빠르게, 코드가 못 본 빈칸은 화면이, 화면으로도 애매한 것은 솔직히 N/A로. 각 단계가 자기 역할을 하고, 넘길 것은 넘기고, 못 하는 것은 인정합니다. 이 흐름이 "질서 있는 협업"의 실제 모습입니다. 특히 사례 ③이 중요합니다. 애매한 것을 솔직하게 N/A로 남기는 이 절제가, 결과 전체의 신뢰를 지탱합니다. 억지로 채운 하나가 나머지 전부의 신뢰를 갉아먹으니까요.

본론 6 — 이 분업이 공공 사이트에서 특히 유효한 이유

지금까지는 두 엔진이 "어떻게" 나눠 일하는지를 봤습니다. 이번에는 "왜 하필 공공 사이트에서 이 구조가 유독 잘 맞는가"를 짚겠습니다. 몇 가지 이유가 있습니다.

첫째, 공공 사이트는 규모가 큽니다. 페이지가 수십에서 수백 장에 이르고, 그 각각을 846개 규칙으로 봐야 합니다. 이 규모에서는 "값싼 코드 판정으로 대부분 처리하고 무거운 화면 인식은 빈칸만"이라는 순서가 결정적입니다. 만약 모든 페이지의 모든 규칙을 무거운 방식으로 처리해야 한다면 분석이 현실적으로 끝나지 않습니다. 두 엔진의 순서 덕분에 큰 사이트도 감당할 수 있는 것입니다.

둘째, 공공 사이트는 오래된 경우가 많습니다. 몇 년 전에 만들어져 조금씩 손봐온 사이트일수록 비표준 방식으로 구현된 부분이 섞여 있습니다. 이미지로 대충 만든 버튼, 정식 컴포넌트가 아니라 손으로 흉내 낸 요소 같은 것들이지요. 이런 것들은 코드만 봐서는 놓치기 쉬운데, 바로 화면 엔진이 채우는 빈칸입니다. 오래된 사이트일수록 "가짜 N/A"가 많고, 그만큼 화면 엔진의 값어치가 커집니다.

셋째, 공공 사이트는 결과를 근거로 써야 합니다. 담당자가 상급자에게 보고하거나, 개선 예산을 요청하거나, 개발사에 수정을 요구할 때, 그 근거가 되는 것이 분석 결과입니다. 그러니 결과는 일관되고 재현 가능해야 하고, 각 판정에는 근거가 붙어 있어야 합니다. 앞서 본 규칙 ①(코드 확정은 안 뒤집기)과 규칙 ④(근거 남기기)가 정확히 이 필요를 받쳐줍니다. 두 번 돌려도 같은 결과가 나오고, "왜 위반인지"가 명확하니 보고서로 쓸 수 있습니다.

넷째, 공공 사이트는 접근성이 특히 중요합니다. 민간 사이트는 불편하면 사용자가 다른 곳으로 가지만, 공공 사이트는 대체재가 없습니다. 세금을 내거나 민원을 넣거나 복지 혜택을 신청하는 창구가 그 사이트 하나뿐입니다. 그런데 접근성 문제의 상당수가 "화면에는 멀쩡한데 코드에 이름이 없는" 형태, 즉 두 엔진이 겹쳐봐야 잡히는 경계의 문제입니다. 사례 ②의 이미지 버튼이 대표적이지요. 화면만 봐서도, 코드만 봐서도 안 잡히고, 둘을 겹쳐봐야 "화면엔 있는데 코드엔 이름이 없다"는 결론이 나옵니다. 두 엔진 구조가 이 경계의 문제를 놓치지 않습니다.

다섯째, 공공 사이트는 행정안전부가 정한 넓은 품질 기준을 따라야 합니다. 「전자정부 웹사이트 품질관리 지침」은 호환성·접근성·개방성·접속성·편의성·효율성·신뢰성이라는 7대 영역을 요구하는데, 이 일곱 가지는 코드 한 줄이나 화면 한 장만 봐서는 판정되지 않습니다. 접근성처럼 코드와 화면을 겹쳐봐야 잡히는 것이 있는가 하면, 신뢰성이나 효율성처럼 실제로 사이트에 접속해봐야 재는 것도 있습니다. 이렇게 성격이 제각각인 넓은 영역을 한 번에 감당하려면, 단일 관점의 엔진 하나로는 부족합니다. 코드를 읽는 눈과 화면을 보는 눈이 함께 있어야 이 폭을 감당할 수 있습니다. 두 엔진 구조가 이 넓은 요구에 대응하는 토대가 되는 것이지요.

이 다섯 가지를 종합하면, 두 엔진 구조는 공공 사이트라는 대상에 상당히 잘 맞는 설계입니다. 규모에 강하고, 오래된 사이트의 숨은 문제를 드러내고, 근거를 남겨 보고에 쓸 수 있고, 경계의 접근성 문제를 잡으며, 넓은 품질 요구를 감당합니다. 물론 이 구조가 만능은 아닙니다. 로그인 안쪽 페이지나, 눌러봐야 나오는 동적인 상호작용처럼 화면을 가만히 그려보는 것만으로는 완전히 다 잡기 어려운 영역도 있습니다. 그런 한계는 앞으로 영역별 글에서 솔직하게 짚겠습니다. 다만 "공개된 화면을 넓고 일관되게, 코드와 시각을 함께 본다"는 영역에서는, 두 엔진의 분업이 분명한 강점을 냅니다.

그래서 ViewCheck는

ViewCheck가 코드를 보는 엔진과 화면을 보는 엔진, 두 엔진을 함께 두는 이유가 바로 이것입니다. 코드 엔진이 846개 규칙을 빠르게 판정해 뼈대를 세우고, 화면 엔진이 N/A로 남은 빈칸 중 "화면에는 있는데 코드로 못 본 것"을 채우고, 합칠 때는 "코드 우선, 빈칸만 보강, 확신도로 거름, 근거 표시"라는 규칙을 지킵니다. 그 위에 판단 단계가 우선순위와 개선안을 얹습니다. 위에서 본 실화면들이 그 결과물의 일부입니다.

거창한 것이 아니라, 지난 몇 주에 본 문제들을 실제로 푸는 구조입니다. 코드만 봐서 생기는 가짜 N/A를 화면 엔진이 메우고, 화면 인식이 함부로 뒤집어 생길 수 있는 편차를 "코드 우선" 규칙이 막습니다. 두 엔진을 따로 두는 것이 목적이 아니라, 둘을 질서 있게 합쳐서 "빠르고, 촘촘하고, 일관된" 판정을 만드는 것이 목적입니다. 엔진이 둘이라는 사실은 수단일 뿐이고, 진짜 결과물은 그 둘이 합쳐 만들어내는 한 장의 신뢰할 만한 판정입니다.

그리고 이 모든 과정이 사용자 입장에서는 여전히 "주소 한 줄 넣고 결과를 받는다"로 요약됩니다. 뒤에서 두 엔진이 나눠 일하고, 순서를 지켜 흐르고, 네 가지 규칙으로 결과를 합치는 복잡한 일이 벌어지지만, 앞에서 담당자가 마주하는 것은 깔끔하게 정리된 결과 한 장입니다. 복잡함은 시스템이 감당하고, 사용자에게는 판정과 근거만 건네는 것이지요. 담당자가 코드를 읽을 줄 몰라도, 화면 인식이 어떻게 작동하는지 몰라도, 두 엔진이 협업해 만들어낸 결과를 그대로 받아 볼 수 있습니다. 좋은 도구의 조건이 바로 이것이라고 생각합니다. 안에서는 정교하게 나눠 일하되, 밖에서는 단순하게 한 장으로 건네는 것 말입니다.

이 두 엔진이 각각 내부에서 어떻게 작동하는지 — 코드 엔진의 규칙 판정 로직, 화면 엔진의 인식 방식, 판단 단계가 근거를 대는 방식 같은 것들 — 는 다음 달 이후 영역별 글에서 깊게 다룹니다. 판단 시점을 깊이 파는 것은 8개월차(LLM 분석)이고, 네 카테고리(DS·CP·BP·SP)의 성격 차이는 5개월차, 다중 페이지 분석은 6개월차, 위반의 위험도를 P0부터 P3까지 어떻게 나누는지는 4개월차에서 각각 자세히 풀 예정입니다. 오늘은 "코드 엔진이 뼈대, 화면 엔진이 빈칸, 규칙대로 합침" 정도의 큰 틀만 잡으시면 충분합니다.

특허로 지키는 부분

오늘 본 "코드 기반 판정과 화면 기반 분석을 충돌 없이 결합하는 방법", 그리고 "화면을 보고 컴포넌트를 인식하는 방식"은 ViewCheck가 출원한 기술 주제와 맞닿아 있습니다. 말로는 "코드도 보고 화면도 본다"가 간단해 보여도, 두 엔진을 "코드 확정은 안 뒤집고, 화면은 빈칸만, 확신도로 거르고, 근거를 단다"는 질서로 안정적으로 합치는 절차 자체가 결코 쉬운 일이 아닙니다. 그 방법을 권리로 정리해 둔 데 차별점이 있습니다.

다만 솔직히 짚어둘 것이 있습니다. 특허는 "방법을 지키는 장치"이지 "품질 보증서"가 아닙니다. 두 엔진을 합친 결과가 실제로 정확한가는, 오늘 본 빈칸 채우기와 확신도 거르기가 제대로 작동하느냐로 결정되는 것이고, 특허는 그 방법을 보호하는 것입니다. 그래서 "특허가 있으니 믿으세요"가 아니라 "이 방법을 직접 만들어 지켜두었다" 정도로 받아들여 주시면 됩니다. 그리고 현재는 출원 단계입니다. "등록특허"가 아니라 "출원 기술"로 정확히 표기합니다. 이 특허들을 한눈에 정리해 소개하는 자리는 다음 주에 따로 마련하겠습니다. (특허 출원 기술 / 자체 개발)

마무리

오늘은 ViewCheck 분석의 밑바탕이 되는 두 엔진 구조를 봤습니다. 두 엔진은 보는 대상이 다릅니다. 하나는 코드를, 하나는 화면을 봅니다. 코드 엔진이 빠르게 뼈대를 세우고, 화면 엔진이 남은 빈칸을 채우고, 합칠 때는 "코드 우선, 빈칸만 보강, 확신도로 거름, 근거 표시"를 지킵니다. 하나로는 절반만 보지만, 둘이 나눠 보고 합치면 빠르면서도 촘촘하고 일관된 판정이 됩니다.

돌이켜보면, 여태 드린 이야기 전부가 하나의 원리로 모입니다. 한 관점으로는 절반만 보이니, 여러 관점을 나눠 보고 질서 있게 합치자는 것. 세 시점(운영·설계·판단)이 그랬고, 오늘 본 두 엔진(코드·화면)이 그렇습니다. 시점을 나누든 엔진을 나누든, 나눈다는 사실보다 잘 합친다는 사실이 더 중요합니다. 나누기만 하고 못 합치면 오히려 혼란이 되고, 잘 합치면 각자의 강점만 남고 약점은 서로 메워집니다.

이번 주는 그 판단 시점을 여는 주입니다. 오늘 두 엔진이라는 토대를 잡았으니, 수요일에는 그 위에 얹히는 판단 단계, 즉 "LLM 분석이란 무엇인가"를 풀겠습니다. 그리고 금요일에는 그 판단이 실제로 결과를 어떻게 읽고, 어떻게 개선안까지 내놓는지를 이어가겠습니다. 오늘이 "누가 무엇을 보는가"였다면, 수요일은 "그 위에서 무엇을 판단하는가", 금요일은 "그래서 어떻게 고치는가"인 셈입니다. 세 편을 다 읽고 나면 판단 시점의 밑그림이 한 장으로 잡히실 것입니다.

두 엔진 이야기를 한 문장으로 줄이면 이렇습니다. "코드로 빠르게 거르고, 화면으로 빈칸을 채우고, 질서 있게 합친다." 하나로는 빠르거나 정확하거나 둘 중 하나만 되는데, 나눠 쓰면 빠르면서 정확해집니다. 그것이 엔진을 둘 둔 이유의 전부입니다.

오늘 딱 하나만 가져가신다면 이 문장이면 좋겠습니다. 코드를 보는 눈과 화면을 보는 눈은 서로 다른 절반을 보고, 그 둘을 질서 있게 합쳐야 비로소 사이트의 전체가 보입니다. 어느 한쪽만으로는 절반의 진실만 손에 쥐게 됩니다. 두 엔진이 각자의 절반을 정직하게 보고, 겹치지 않게 나누고, 확신 있는 것만 채워 하나로 합치는 것 — 그 위에서 비로소 "그래서 무엇부터 고칠까"라는 판단이 의미를 갖습니다. 오늘도 긴 이야기를 끝까지 읽어주셔서 진심으로 고맙습니다. 이번 주 수요일, 두 엔진 위에 얹히는 그 판단 단계 이야기로 다시 찾아뵙겠습니다.

krds.viewcheck.co.kr

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