행안부 7대 품질진단, ViewCheck가 자동으로 돌리는 방법 — 영역마다 측정 방식이 다르다

호환성·접근성·개방성·접속성·편의성·효율성·신뢰성, 같은 '품질'이지만 재는 자가 다 다르다

들어가며 — "품질진단 하셨습니까?"라는 질문의 무게

해마다 공공기관 웹사이트 담당자들을 긴장시키는 행사가 있다. 행정안전부가 주관하는 전자정부 웹사이트 품질진단이다. 진단 대상이 되는 기관은 미리 자체 점검을 거쳐야 하고, 그 결과를 근거로 개선 계획을 세워야 한다. 이 일을 처음 맡아본 담당자라면 누구나 맞닥뜨리는 첫 번째 장벽이 있다.

"7대 영역이 뭐고, 우리 사이트는 어디서부터 보면 되지?"

행안부 고시(제2025-46호)가 규정하는 전자정부 웹사이트 품질은 단순히 '잘 만든 사이트'가 아니다. 호환성·접근성·개방성·접속성·편의성·효율성·신뢰성이라는 7개의 영역이 각각 서로 다른 기준과 측정 방법을 갖는다. HTML 구조를 보면 알 수 있는 게 있고, 서버에 직접 요청을 보내봐야 아는 게 있으며, 화면을 눈으로 확인해야 하는 것도 있다. 단일한 점검 방법으로 7개를 한꺼번에 커버하는 건 사실상 불가능하다.

그래서 자동화가 복잡하다. 그리고 그 복잡함을 무시하면 '한 개의 도구로 다 됩니다'는 말이 나오고, 실제 결과는 쓸모없는 리포트가 된다. 우리는 그 함정을 피하기 위해, 7대 영역을 영역별로 적합한 방식으로 따로따로 잰다는 원칙을 세웠다.

이번 편은 그 원칙이 어떻게 ViewCheck의 설계로 연결되는지, 그리고 자동화를 하면서 아직도 어렵다고 느끼는 부분은 어디인지를 가능한 한 솔직하게 적어본다. '모든 걸 해결했다'는 이야기가 아니라, '이렇게 접근하고 있다, 이건 아직 연구 중이다'는 R&D 노트에 가까운 글이 될 것이다.

공공기관 사무실 대형 화면 앞에서 레이더 형태의 품질 대시보드를 검토하는 품질 담당자의 모습. — 레이더 차트 형태의 품질 대시보드를 들여다보는 공공기관 품질관리 담당자. 7대 영역은 각각 다른 축을 갖는다.

행안부 고시가 말하는 '7대 품질' — 원문부터 짚어보자

본론으로 들어가기 전에, 우리가 기준으로 삼는 법령 문서를 먼저 확인하자. ViewCheck의 품질 자동화 기준은 추측으로 만든 것이 아니라 행정안전부가 공식적으로 고시한 규정에서 출발한다.

행정안전부는 2025년 6월 25일자로 「전자정부 웹사이트 품질관리 지침」을 일부 개정하여 행정안전부고시 제2025-46호로 시행했다. 행안부 공식 안내문은 이렇게 설명한다.

"이번 개정에서는 品質進斷 기준의 세부적·기술적 사항을 고시 본문(별표)에서 삭제하고, 구체적인 항목은 별도의 「품질관리 가이드」로 위임하는 방향을 택했다." (행정안전부 고시 제2025-46호 개정 안내, mois.go.kr)

이 구조 변화는 의미심장하다. 고시 본문은 원칙을 담고, 실제 점검 항목의 세부 기준은 '가이드'라는 별도 문서로 분리됐다. 기준이 고시보다 유연하게 개정될 수 있게 된 것이다. 자동화 도구를 만드는 입장에서는 이 점을 계속 주시해야 한다. 기준이 바뀌면 도구도 따라가야 하기 때문이다.

이 지침이 다루는 7대 품질 영역은 다음과 같이 정의된다.

호환성(Compatibility) — 표준 HTML·CSS를 지키고, 주요 브라우저에서 동일하게 동작하는가. ActiveX 같은 비표준 플러그인이 없는가.
접근성(Accessibility) — 장애가 있는 사용자도 동등하게 이용할 수 있는가. 한국형 웹 콘텐츠 접근성 지침(KWCAG)이 핵심 기준이다.
개방성(Openness) — robots.txt, sitemap.xml, 메타데이터, 크롤링 허용 등 정보가 열려 있는가. 검색엔진이 사이트를 색인할 수 있는가.
접속성(Connectivity) — 서버가 빠르게 응답하는가. 링크가 끊기지 않는가. TTFB(Time to First Byte)처럼 실제 측정 가능한 수치가 기준이다.
편의성(Convenience) — 사용자가 서비스를 편리하게 쓸 수 있는가. UI/UX 관점의 기능 설계.
효율성(Efficiency) — 페이지가 불필요하게 무겁지 않은가. 리소스 크기, 요청 수, 로딩 시간.
신뢰성(Reliability) — SSL, 개인정보처리방침, 보안 헤더처럼 믿고 쓸 수 있는 환경인가.

이 7개를 가만히 보면, 성격이 완전히 다르다는 걸 바로 알 수 있다. 어떤 건 HTML 파일 하나를 분석하면 알 수 있고, 어떤 건 서버에 직접 연결해봐야 하며, 어떤 건 AI가 화면을 보고 판단해야 한다. 이 다름을 무시하고 "우리 도구 하나로 다 됩니다"라고 말하는 순간, 그 도구는 거짓말을 하고 있는 것이다.

7대 영역을 세 종류로 나눠보면 — 측정 방법이 세 가지다

우리가 7대 영역 자동화를 설계할 때 가장 먼저 한 일은, 영역을 '어떤 도구로 재는가'에 따라 묶어보는 것이었다. 그랬더니 크게 세 종류로 나뉘었다.

종류 1: DOM과 CSS를 분석하면 알 수 있는 것

접근성의 상당 부분이 여기에 해당한다. 스크린 리더가 읽어야 하는 alt 속성이 있는가, 폼 요소에 라벨이 붙어 있는가, 헤딩 구조가 논리적인가, ARIA 속성이 올바르게 쓰였는가 — 이런 것들은 페이지의 DOM(Document Object Model, 문서 구조 트리) 과 CSS(스타일 코드)를 파싱하면 자동으로 판정할 수 있다.

KRDS 846개 규칙 중 DS(디자인 스타일, 120개), CP(컴포넌트, 446개), BP(기본 패턴, 108개), SP(서비스 패턴, 172개)의 대부분이 이 방식으로 판정된다. DOM 기반 판정의 장점은 빠르다는 것이다. 수백 페이지를 돌아도 수 초에서 수십 초면 끝난다. 그리고 '있다/없다', '값이 기준 이상/이하'처럼 명확한 이진 판정이 가능하다.

호환성도 이 범주에 들어온다. html-validate 같은 도구로 HTML 문법을 검증하고, css-tree로 CSS 파싱 오류를 잡고, axe-core 같은 접근성 엔진으로 WCAG 규칙 위반을 탐지하는 방식이다. axe-core의 경우 Deque Systems가 2015년에 오픈소스로 공개한 접근성 테스트 엔진으로, 전 세계에서 40억 회 이상 다운로드됐고 1,300만 개 이상의 GitHub 프로젝트에 사용될 만큼 사실상 접근성 자동화의 표준이 됐다(GitHub, axe-core). axe-core는 WCAG 2.0, 2.1, 2.2의 A·AA·AAA 레벨 규칙을 커버하며, 평균적으로 전체 WCAG 이슈의 약 57%를 자동으로 잡아낼 수 있다고 알려져 있다(Deque, axe-core 공식).

편의성의 일부(예: 폼 구조, 오류 처리 패턴, 동의/확인 흐름)도 DOM에서 패턴을 탐지하는 방식으로 어느 정도 자동화된다.

종류 2: HTTP 요청을 직접 해봐야 아는 것

이 범주가 처음에 과소평가됐다가 가장 공을 들이게 된 영역이다. 접속성, 효율성, 신뢰성, 그리고 개방성의 일부가 여기에 해당한다.

단적인 예를 들면, HTTPS 인증서가 유효한지, 만료일이 얼마나 남았는지, 자체 서명 인증서인지 발급기관 체인이 정상인지 — 이런 건 브라우저가 그 사이트에 실제로 연결해봐야 안다. HTML 코드를 아무리 분석해봐야 SSL 상태는 알 수 없다.

응답 속도(TTFB, Time to First Byte)도 마찬가지다. "이 서버가 빠른가"는 실제로 요청을 보내고 응답이 오는 시간을 재야 한다. ViewCheck는 Playwright(마이크로소프트가 만든 브라우저 자동화 라이브러리)를 이용해 실제 브라우저로 사이트를 방문하면서 이 수치들을 수집한다. DNS 조회 시간, TCP 연결 시간, TLS 핸드셰이크 시간, TTFB를 각각 분리해서 측정하는 것이 목표다.

개방성의 robots.txt와 sitemap.xml도 HTTP로 직접 요청해야 한다. "robots.txt 파일이 있는가"뿐 아니라, "그 안에 Disallow 지시어가 어떻게 쓰여 있는가", "Sitemap 지시어로 사이트맵을 지정했는가", "사이트맵에 URL이 몇 개 있고 마지막 수정일(lastmod)이 얼마나 오래됐는가" — 이런 내용 분석이 진짜 개방성 점검이다.

보안 헤더 13종(HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy 등)도 HTTP 응답 헤더를 직접 받아야 확인할 수 있다. 그냥 페이지 소스에는 안 나온다.

종류 3: 눈으로 봐야 하는 것 — Vision AI의 영역

세 번째 종류는 가장 어려운 영역이다. DOM이나 HTTP만으로는 알 수 없고, 화면을 실제로 보아야만 판단할 수 있는 것들이다.

KRDS 디자인 토큰 준수 여부가 대표적이다. "이 버튼의 배경색이 KRDS 기본 색상 토큰과 맞는가"는 CSS computed style로 어느 정도 잡히지만, 이미지로 만든 버튼, 캔버스(canvas), SVG로 그린 UI 요소는 DOM만으로는 감지 자체가 안 된다. 이런 것들은 스크린샷을 찍어서 Vision AI가 '보고' 판단해야 한다.

접근성도 일부는 시각적 판단이 필요하다. "색상 대비가 실제로 충분한가"는 CSS 값에서 계산할 수 있지만, 텍스트가 이미지 위에 얹혀 있거나 그라디언트 배경 위에 있다면 픽셀 단위의 시각 분석이 필요하다. "버튼이 충분히 큰가"도 마찬가지다. CSS 값으로 크기를 계산할 수는 있지만, 실제로 화면에서 어떻게 렌더링되는지가 중요하기 때문이다.

이 세 번째 종류는 아직 자동화의 신뢰도가 가장 낮고, 가장 활발하게 연구 중인 영역이기도 하다. Vision AI가 그럴듯하게 틀릴 수 있기 때문에, DOM이 명확히 판정한 내용을 Vision AI가 함부로 뒤집지 않도록 아키텍처를 설계했다. 이 충돌 방지 원칙에 대해서는 뒤에서 다시 다룬다.

호환성 — HTML·CSS 표준과 브라우저 호환의 자동화

7대 영역 중 자동화 친화성이 가장 높은 영역이 호환성이다. "이 사이트가 표준을 지키고 있는가"라는 질문은, 기준이 명확하고 측정 방법이 확립되어 있기 때문이다.

ViewCheck의 호환성 점검은 크게 세 층으로 이루어진다.

첫 번째 층 — HTML 문법 검증. html-validate 라이브러리를 활용해 페이지의 HTML5 문법을 W3C 기준으로 검증한다. 닫히지 않은 태그, 잘못된 중첩, 더 이상 권장되지 않는(deprecated) 속성 같은 것들이 여기서 잡힌다. 이건 오래된 기준이지만 아직도 공공 사이트에서 흔하게 발견되는 유형이다.

두 번째 층 — CSS 검증. css-tree로 스타일시트를 파싱해 문법 오류와 비표준 속성을 찾는다. 특정 브라우저에서만 동작하는 벤더 프리픽스(-webkit-, -moz- 등)를 범용 속성 없이 단독으로 쓰거나, 지원 종료된 CSS 속성을 계속 사용하는 경우가 여기에 걸린다.

세 번째 층 — 크로스 브라우저 검증. 행안부 지침은 주요 브라우저(크롬, 엣지, 파이어폭스, 사파리 등)에서의 동일한 동작을 요구한다. 완전한 크로스 브라우저 테스트는 각 브라우저에서 직접 실행해야 하기 때문에 자동화 비용이 높다. ViewCheck는 현재 Chromium 기반 Playwright로 주로 테스트하며, 완전한 멀티 브라우저 검증은 향후 과제로 남아 있다. 이 부분은 솔직히 "아직 부족하다"고 인정하는 영역이다.

접근성 — KWCAG와 WCAG, 그리고 자동화의 한계

접근성은 7대 영역 중 가장 많은 규칙이 쌓여 있는 영역이기도 하고, 자동화와 수동 점검의 경계선이 가장 복잡한 영역이기도 하다.

국제 기준은 W3C(월드 와이드 웹 컨소시엄)가 제정한 WCAG(Web Content Accessibility Guidelines)다. 2023년 10월 5일 WCAG 2.2가 W3C 공식 권고안(Recommendation)으로 확정됐다(W3C, WCAG 2.2, 2023). WCAG 2.2는 저시력·인지 장애·운동 장애를 가진 사람들을 위한 접근성을 더 강화한 버전으로, WCAG 2.0과 2.1을 모두 포함한다. 영국 정부(GOV.UK Design System)는 2024년부터 WCAG 2.2 AA를 공공 서비스의 최소 기준으로 채택했고, 미국 USWDS(U.S. Web Design System)도 WCAG 2.1 AA 이상을 지향하며 점진적으로 2.2 기준으로 이동하고 있다(USWDS 공식, designsystem.digital.gov).

한국의 경우 WCAG와 별도로 한국형 웹 콘텐츠 접근성 지침(KWCAG) 을 운영한다. KWCAG는 WCAG를 기반으로 하되, 한국의 공공 서비스 환경에 맞게 재정립된 기준이다. ViewCheck는 KWCAG의 34개 항목을 별도 로직으로 검증한다. KRDS 846규칙과 KWCAG 34항목이 겹치는 부분도 있고, 독립적인 부분도 있어서 교차 검증이 필요하다.

접근성 자동화의 핵심 도구로는 axe-core를 사용한다. axe-core는 DOM을 분석해 WCAG 규칙 위반을 자동으로 탐지하는 엔진이다. 여기서 중요한 수치가 하나 있다. axe-core로 잡을 수 있는 접근성 이슈는 전체의 약 57% 정도다. 나머지 43%는 자동화 도구가 판정할 수 없어서 사람이 직접 확인해야 한다(Deque, axe-core 공식 문서). 이걸 "57%를 자동으로 잡는다"로 읽을 것인지, "43%는 자동화가 안 된다"로 읽을 것인지는 관점의 문제다. 우리는 두 번째로 읽는다. 자동화가 안 되는 43%를 어떻게 처리할 것인가가 진짜 문제다.

ViewCheck LLM 분석의 7대 품질진단 결과 대시보드 — 영역별 점수와 미통과 항목이 시각화된 실제 화면 캡처. — ViewCheck 12번째 품질진단 기능 실제 화면. 접근성·호환성·개방성 등 영역별 점수가 한눈에 표시되는 대시보드 형태다. — 실제 분석 화면

axe-core가 못 잡는 영역 중 일부는 KRDS 846규칙의 나머지 판정(CP 컴포넌트 규칙, BP 패턴 규칙)으로 보완한다. 그래도 남는 부분 — 색상 대비가 이미지나 그라디언트 위에서 실제로 어떻게 보이는지, 커스텀 컴포넌트의 시각적 접근성 — 은 Vision AI가 스크린샷을 보고 판단하는 방식으로 접근하고 있다. 아직 이 부분의 신뢰도는 충분하지 않다고 솔직하게 인정한다.

개방성 — robots.txt와 sitemap.xml의 진짜 내용을 파싱한다

개방성은 "이 사이트의 정보가 얼마나 열려 있는가"를 보는 영역이다. 단순히 공개 사이트라는 것 이상으로, 검색엔진 크롤러가 사이트를 제대로 색인할 수 있는가, 메타데이터가 충분히 제공되는가가 핵심이다.

개방성 점검에서 가장 자주 놓치는 것이 robots.txt와 sitemap.xml의 '내용 분석'이다. 많은 점검 도구가 "robots.txt 파일이 존재하는가(HTTP 200 응답)"만 확인하고 끝낸다. 하지만 진짜 중요한 건 그 안에 뭐가 쓰여 있는가다.

예를 들어 robots.txt에 이런 내용이 있다면 어떨까.

User-agent: *
Disallow: /

파일은 존재하지만, 사실상 모든 크롤러의 접근을 차단하고 있다. "개방성: 통과(파일 존재)"는 사실과 다른 판정이다. 반대로 robots.txt에 Sitemap: https://example.go.kr/sitemap.xml 같은 지시어로 사이트맵을 명시하면 검색엔진 색인 품질이 올라가는데, 이걸 확인하지 않으면 개선 포인트를 놓친다.

ViewCheck의 개방성 점검은 이런 내용까지 파싱한다. 구체적으로는 다음을 본다.

robots.txt: 파일 존재 여부 + User-agent 지시어 종류 + Disallow 패턴의 개방도 + Sitemap 지시어 여부
sitemap.xml: 파일 존재 + URL 수 + lastmod 날짜의 신선도 + sitemapindex(다중 사이트맵) 여부
Open Graph 태그(og:title, og:description, og:image): SNS 공유 시 미리보기 품질
메타 태그 6종: title, description, viewport, lang, canonical, robots
구조화 데이터(JSON-LD, microdata): 검색 결과 풍부한 표현(Rich Snippet) 지원 여부

이 중 robots.txt와 sitemap.xml은 사이트당 한 번씩만 요청해서 결과를 캐싱한다. 100페이지를 분석하면서 100번씩 요청하는 건 비효율적이기도 하고 서버에 부담을 주기도 하므로, 사이트 단위로 한 번만 확인하고 그 결과를 모든 페이지 판정에 활용한다.

공공기관 IT팀 회의실에서 대형 모니터에 표시된 사이트 품질 개요를 함께 검토하는 장면. — 사이트 품질 개요를 들여다보는 IT팀 회의 장면. 개방성·접속성 같은 영역은 서버에 직접 연결해봐야 알 수 있다.

접속성 — 서버가 얼마나 빠른가, 직접 재야 안다

접속성은 "사이트에 접속했을 때 얼마나 빠르게 응답하는가"를 보는 영역이다. 이 영역의 핵심은 직접 측정이다. HTML 코드 안에 "우리 서버 응답 시간은 300ms입니다"라고 적혀 있는 사이트는 없다. 실제로 연결해봐야 안다.

ViewCheck는 Playwright가 페이지를 로드하는 과정에서 다음 수치들을 수집한다.

DNS 조회 시간: 도메인 이름을 IP 주소로 변환하는 데 걸리는 시간
TCP 연결 시간: 서버와 TCP 연결을 맺는 데 걸리는 시간
TLS 핸드셰이크 시간: HTTPS의 경우 보안 연결을 협상하는 시간
TTFB(Time to First Byte): 요청 후 첫 번째 바이트가 도착하기까지의 시간
리다이렉트 시간: HTTP → HTTPS 같은 리다이렉트에 걸리는 시간

이 수치들은 '실제 사용자 경험'에 직접 영향을 미친다. 특히 TTFB는 서버 응답 성능의 핵심 지표로, 200ms 이하가 양호, 500ms 이상은 개선 필요로 분류하는 것이 일반적이다.

행안부 지침에서 접속성은 단순히 "빠른가"만이 아니라 링크 연결, 가용성(404 오류 없는가), 응답 안정성까지 포함한다. 자동화로 커버할 수 있는 부분은 응답 시간과 링크 유효성이고, 장기적인 가용성은 모니터링 성격의 별도 인프라가 필요하다. 후자는 ViewCheck의 현재 범위 밖이라는 점을 솔직히 밝혀둔다.

효율성 — Core Web Vitals가 기준이 되는 이유

효율성은 페이지 로딩의 실제 사용자 체감 성능을 본다. 이 영역에서는 Google이 정의한 Core Web Vitals가 사실상 업계 표준 측정 지표가 됐다.

Core Web Vitals는 세 가지 핵심 지표로 구성된다.

LCP(Largest Contentful Paint): 화면의 메인 콘텐츠가 로드되는 시간. 2.5초 이하가 양호.
INP(Interaction to Next Paint): 사용자 인터랙션에 얼마나 빠르게 반응하는가. 200ms 이하가 양호. 2024년 3월부터 기존 FID를 대체해 Core Web Vitals 기준 지표가 됐다(Google Search Central, 2023).
CLS(Cumulative Layout Shift): 페이지 로딩 중 콘텐츠가 예고 없이 이동하는 정도. 0.1 이하가 양호.

이 세 가지 외에 FCP(First Contentful Paint, 첫 콘텐츠가 나타나는 시간)와 TTFB도 함께 측정한다.

ViewCheck는 이 수치들을 Playwright로 페이지를 열 때 PerformanceObserver API를 통해 브라우저 내부에서 직접 수집한다. 외부 도구(Lighthouse 등)의 에뮬레이션 수치가 아니라, 실제 브라우저가 해당 페이지를 렌더링하면서 측정한 값이다.

효율성의 또 다른 중요한 측면은 리소스 부하다. 페이지가 로드할 때 불러오는 JS 파일의 총 크기, CSS 파일 수, 이미지 최적화 여부, 폰트 로딩 방식이 모두 효율성에 영향을 미친다. ViewCheck는 page.on('response') 리스너로 페이지 로드 중 모든 네트워크 요청을 수집해서 리소스를 JS·CSS·이미지·폰트 등 유형별로 분류하고 크기를 집계한다. 이 데이터를 보면 "왜 이 페이지가 느린가"의 원인을 어느 정도 짐작할 수 있다.

다만 Core Web Vitals는 네트워크 속도, 기기 성능, 지리적 위치에 따라 수치가 달라진다. ViewCheck가 측정하는 건 분석 서버의 네트워크 환경에서 측정한 '실험실 환경(lab)' 수치다. 실제 사용자가 경험하는 '필드 데이터(field)'와 다를 수 있다는 점을 항상 주의사항으로 함께 제시하는 이유다.

편의성 — KRDS 846규칙이 주인공

편의성은 "사용자가 서비스를 쉽고 편리하게 쓸 수 있는가"를 보는 영역으로, ViewCheck에서는 주로 KRDS 846규칙이 이 영역을 담당한다. 특히 BP(기본 패턴, 108개)와 SP(서비스 패턴, 172개)가 핵심이다.

기본 패턴(BP) 은 공공 서비스에서 반복적으로 등장하는 상호작용 흐름을 규정한다.

폼 입력 시 오류 메시지는 어디에, 어떤 방식으로 표시되는가
동의 화면에서 필수/선택 항목이 구분되어 있는가
테이블에 정렬 기능이 있을 때 현재 정렬 상태가 표시되는가
파일 업로드 시 허용 형식과 크기 제한이 명시되어 있는가

서비스 패턴(SP) 은 페이지 유형별(검색·로그인·신청·정책 안내 등) 흐름 전체를 규정한다. 예를 들어 로그인 화면이라면 아이디/비밀번호 찾기 링크 존재 여부, 캡차 처리 방식, 인증 실패 시 피드백 같은 것들이 SP 규칙의 판정 대상이다.

편의성 자동화에서 까다로운 건 '페이지 유형 감지'다. "이 페이지가 로그인 페이지인지, 검색 결과 페이지인지, 신청 페이지인지"를 먼저 파악해야 그에 맞는 SP 규칙을 적용할 수 있다. ViewCheck는 URL 패턴 + DOM 구조 + 텍스트 패턴의 세 가지 신호를 조합해서 15종의 페이지 유형을 자동으로 감지한다. 이 감지가 틀리면 엉뚱한 SP 규칙이 적용되는 오류가 생기기 때문에, 페이지 유형 분류의 정확도는 편의성 점검 전체의 신뢰도를 좌우한다.

신뢰성 — 보안 헤더 13종과 SSL의 자동 점검

신뢰성은 "이 사이트를 믿고 써도 되는가"를 묻는 영역이다. 기술적으로는 보안 설정, SSL 인증서, 개인정보 처리 방침의 존재 여부 등이 핵심이다.

ViewCheck의 신뢰성 점검은 크게 세 층으로 구성된다.

첫 번째 층 — 보안 헤더. HTTP 응답 헤더에서 보안 관련 13종을 확인한다.

헤더	역할
Strict-Transport-Security (HSTS)	HTTPS 강제 사용
Content-Security-Policy (CSP)	악성 스크립트 삽입 방지
X-Frame-Options	클릭재킹 공격 방지
X-Content-Type-Options	MIME 타입 스니핑 방지
Referrer-Policy	리퍼러 정보 제어
Permissions-Policy	기기 권한 제어
Cross-Origin-Opener-Policy	탭 분리 보안
Cross-Origin-Resource-Policy	리소스 교차 출처 제어
Cross-Origin-Embedder-Policy	임베딩 보안
Cache-Control	민감 정보 캐싱 방지
X-XSS-Protection	XSS 보호(레거시)
Feature-Policy	기능 접근 제어
Expect-CT	인증서 투명성

이 헤더들은 페이지 코드 안에서 볼 수 없고, HTTP 응답을 직접 받아야 확인할 수 있다. ViewCheck는 Playwright로 사이트에 접속할 때 이 헤더들을 자동으로 수집하고 존재 여부 및 설정값을 평가한다.

두 번째 층 — SSL 인증서. 단순히 HTTPS를 쓰는지만이 아니라, 인증서의 만료일이 얼마나 남았는지, 자체 서명 인증서인지, TLS 프로토콜 버전이 최신(TLS 1.2 이상)인지를 확인한다. 만료가 30일 이내라면 경고, 7일 이내라면 심각 단계로 구분해서 알린다.

세 번째 층 — 개인정보처리방침 링크. 공공 사이트라면 개인정보처리방침과 이용약관, 가능하면 접근성 정책 페이지로 연결되는 링크가 있어야 한다. 이는 법적 의무이기도 하다. ViewCheck는 페이지의 footer 영역에서 해당 링크 텍스트를 탐지해서 존재 여부를 확인한다.

세 엔진의 분업 — 영역마다 다른 도구를 쓴다

여기까지 읽었다면 7대 영역이 왜 하나의 도구로 통째로 처리하기 어려운지 자연스럽게 이해됐을 것이다. 이 다양성을 수용하기 위해 ViewCheck는 세 개의 분리된 엔진을 운용한다.

ViewCheck (수집·통합 엔진, :3001)
  ├── Playwright로 크롤링 (실제 브라우저)
  ├── HTTP 요청으로 접속성·효율성·신뢰성·개방성 측정
  ├── 보안 헤더·SSL·Core Web Vitals 수집
  └── 모든 결과 통합 → 24개 분석 카드로 대화에 표시
       ↕
KRDSrule 엔진 (DOM 기반 846규칙, :3002)
  ├── DOM 데이터 → 846개 규칙 if/else 판정 (수 초)
  ├── 접근성·편의성의 DOM 감지 가능 영역 담당
  └── 통과·미통과·해당없음 + 근거 반환
       ↕
KRDScan 엔진 (Vision AI·RAG, :8000)
  ├── 스크린샷 → Vision AI로 비표준 UI 감지
  ├── DOM이 '해당없음'으로 남긴 규칙에 AI 판정 제공
  └── RAG(검색 증강 생성)로 판정 근거 문서 연결

다양한 품질 지표 디스플레이로 가득한 벽 앞에 클립보드를 들고 서 있는 검수 담당자의 모습. — 여러 종류의 품질 지표 화면 앞에 선 검수 담당자. 영역마다 다른 도구로 측정하고, 결과를 한 화면에 모아야 한다.

세 엔진의 역할은 의도적으로 겹치지 않게 설계됐다. ViewCheck는 HTTP로만 알 수 있는 것을 담당하고, KRDSrule 엔진은 DOM으로 알 수 있는 것을 담당하며, KRDScan 엔진은 눈으로 봐야 하는 것을 담당한다.

여기서 중요한 원칙이 하나 있다. DOM이 명확히 판정한 내용을 Vision AI가 뒤집지 않는다. 예를 들어 KRDSrule 엔진이 "이 버튼에 라벨이 없어서 CP-001 규칙 미통과"로 판정했다면, KRDScan의 Vision AI는 그 결과를 번복하지 않는다. AI는 DOM이 '해당없음'으로 남겨둔 빈칸(N/A 규칙)과, DOM이 아예 볼 수 없는 이미지·캔버스 기반 UI만 독자적으로 판단한다. 이 분업 원칙이 결과의 일관성을 유지하는 핵심이다. AI가 자유롭게 DOM의 결론을 뒤집게 되면, 같은 사이트를 분석할 때마다 결과가 달라지는 혼란이 생긴다.

다중 페이지가 기본값인 이유 — 메인 하나로는 부족하다

7대 영역 자동화를 설계하면서 우리가 양보하지 않은 원칙이 하나 있다. 다중 페이지 분석이 기본값이어야 한다는 것.

공공 사이트는 메인 페이지 하나가 아니다. 검색 결과 페이지, 신청서 작성 화면, 로그인 화면, 게시판 목록, 상세 내용 페이지, 각종 안내 페이지까지 수십에서 수백 개의 화면이 있다. 그리고 영역별 품질 문제는 메인이 아닌 곳에서 더 자주 발견된다.

접근성을 예로 들면, 메인 페이지는 보통 가장 공을 들여 만든다. 접근성 문제가 비교적 적다. 하지만 신청 화면은 어떨까. 폼 요소에 라벨이 없거나, 필수 항목 표시가 텍스트가 아닌 색으로만 구분돼 있거나, 오류 메시지가 스크린 리더에 전달되지 않는 경우가 훨씬 많다. 메인만 보고 "접근성 통과"를 적으면, 실제로 장애인 사용자가 가장 어려움을 겪는 화면은 완전히 놓치는 셈이다.

효율성도 마찬가지다. 메인 페이지는 최적화가 잘 됐는데, 특정 게시판 상세 페이지에서 무거운 이미지가 최적화 없이 올라와 있다면? Core Web Vitals 수치가 크게 나빠지는 건 그 화면에서다.

ViewCheck는 이 문제를 '다중 페이지 집계'로 접근한다. 100개 페이지를 분석한 경우, 각 페이지의 결과를 독립적으로 저장하고, 그것을 OR 로직으로 집계한다. 즉, 1개 페이지라도 특정 규칙에서 미통과가 있다면 그 규칙은 사이트 전체 결과에서도 미통과로 표시된다. 메인 한 장만 보면 "통과"인데 사이트 전체 기준으로는 "미통과"가 되는 것이다. 이 집계 방식은 공공 웹 품질의 실제를 더 정직하게 반영하기 위한 선택이다.

다만 100페이지를 분석하는 건 1페이지와는 전혀 다른 자원 소모를 요구한다. 브라우저 메모리, 분석 시간, 결과 저장 공간이 모두 달라진다. 이 규모 확장성(scalability) 문제는 여전히 풀어가고 있는 엔지니어링 과제다.

레이더 형태 대시보드 화면을 가운데 두고 품질 검토 회의를 진행하는 공공기관 팀. — 레이더 형태 대시보드를 둘러싼 품질 검토 회의. 7대 영역을 모두 한눈에 보면서 어디에 집중할지 판단하는 과정.

KRDS와 7대 영역의 교집합 — 어디서 만나는가

KRDS(범정부 UI/UX 디자인 시스템)와 행안부 7대 품질 영역은 서로 다른 기준처럼 보이지만, 실제로는 깊게 연결되어 있다.

KRDS 846규칙의 DS(디자인 스타일)와 CP(컴포넌트) 카테고리는 7대 영역의 편의성 과 직접 연결된다. KRDS가 정의한 색상 토큰, 타이포그래피, 간격 시스템, 컴포넌트 스펙을 사이트가 준수하고 있는지가 편의성의 시각적·인터랙션적 측면을 이룬다.

KRDS의 BP(기본 패턴)와 SP(서비스 패턴)는 편의성의 기능적 측면과 맞닿아 있다. 폼이 제대로 동작하는가, 검색이 올바르게 안내되는가, 신청 흐름이 사용자에게 명확한가 — 이것들이 KRDS 규칙으로 구체화된다.

접근성 영역은 KRDS와 WCAG/KWCAG가 직접 교차한다. KRDS 공식 문서는 각 컴포넌트와 패턴 아래에 WCAG 적합성을 명시한다(krds.go.kr). 2025년 1월 KRDS가 정식 서비스로 개편되면서, 이 접근성 정보가 더 체계적으로 정리됐다(대한민국 정부 UI/UX 디자인 시스템, 정식 개시, 2025.1). 공공기관이 KRDS를 따르면 접근성도 함께 높아지는 구조가 설계 의도다.

GOV.UK Design System과 비교하면 이 구조의 의미가 더 선명해진다. GOV.UK Design System 팀은 2024년 초 "GOV.UK Design System을 쓰면 WCAG 2.2 달성이 더 빨라진다"는 블로그 포스트를 게시했다(GOV.UK Accessibility Blog, 2024). 디자인 시스템 자체에 접근성 기준을 내장해서, 시스템을 따르는 서비스들이 자동으로 기준을 충족하도록 하는 접근이다. KRDS의 방향도 이와 같다. 컴포넌트를 KRDS대로 쓰면 WCAG 기준이 자연스럽게 충족된다는 것.

이 교집합을 자동화로 연결하는 것이 ViewCheck의 핵심 도전이다. KRDS 846규칙 판정 결과를 7대 영역에 매핑해서, "우리 사이트의 편의성 점수가 낮은 건 KRDS BP-035 규칙(폼 오류 처리 패턴)을 반복적으로 위반하기 때문"처럼 구체적인 원인으로 연결하는 것이다.

해외 디자인 시스템과의 비교 — USWDS가 품질을 다루는 방식

한국의 공공 웹 품질 기준이 독특한 것처럼 느껴지지만, 이 방향은 사실 글로벌한 흐름이다. 미국 USWDS(U.S. Web Design System)가 비슷한 구조를 가지고 있다.

USWDS는 미국 연방 정부 웹사이트를 위한 무료 오픈소스 디자인 시스템으로, 접근성·모바일 친화성·일관성을 내장한 40개 이상의 컴포넌트를 제공한다(USWDS 공식, designsystem.digital.gov). 미국에서는 21st Century Integrated Digital Experience Act(21세기 통합 디지털 경험법, IDEA Act)가 공개 서비스 웹사이트에 일관된 외관, 모바일 지원, 접근성 기준 충족을 요구하고 있어 법적 의무와 디자인 시스템이 맞물려 있다.

USWDS의 접근성 기준은 WCAG 2.1 AA를 기본으로, 가능한 한 WCAG 2.2까지 달성하는 것을 목표로 한다. 한국 KRDS가 KWCAG와 WCAG를 함께 다루는 것과 유사한 구조다.

미국 연방 정부가 공공 웹의 품질을 법적 의무와 디자인 시스템으로 강제하는 방식은 우리에게도 시사하는 바가 있다. 단순히 "좋은 사이트를 만들자"는 권고가 아니라, 기준을 코드(디자인 시스템)로 내장하고 준수 여부를 자동으로 검증하는 흐름 — ViewCheck가 추구하는 방향과 크게 다르지 않다.

다만 미국과 한국의 차이도 있다. 한국 공공 사이트는 한국어라는 언어 특성, ActiveX 유산, 특정 산업 분야의 인증서 기반 레거시 시스템 같은 독특한 도전과제를 안고 있다. 이런 한국 특화 이슈를 글로벌 오픈소스 도구만으로 전부 커버하기는 어렵다. 그래서 KRDS에 맞춰 설계된 별도의 규칙 엔진(KRDSrule)이 필요한 이유다.

자동화가 아직 어려운 부분 — 솔직한 한계 목록

7대 영역 자동화를 이야기하면서, 아직 제대로 안 된다고 솔직하게 인정해야 할 부분들을 목록으로 정리한다. "다 됩니다"라고 쓰는 게 홍보로서는 더 편하겠지만, 그게 더 큰 문제를 만든다.

아직 어려운 것들:

크로스 브라우저 완전 테스트: 크롬·엣지·파이어폭스·사파리를 모두 실제로 열어서 렌더링 차이를 비교하는 건 현재 Chromium 기반 단일 브라우저로 주로 테스트한다. 멀티 브라우저 병렬 실행은 인프라 비용이 크다.
접근성의 시각적 판단 영역: 이미지·SVG 위의 텍스트 색상 대비, 비표준 방식으로 구현된 커스텀 드롭다운의 키보드 접근성처럼 눈으로 실제로 써봐야 아는 영역은 자동화 신뢰도가 낮다.
동적 인터랙션 검증: 버튼을 클릭했을 때 모달이 올바르게 열리는지, 드롭다운이 키보드로 탐색되는지 같은 런타임 상호작용은 시나리오 기반 Playwright 스크립트가 필요한데, 사이트마다 구조가 달라 일반화가 어렵다.
장기 접속성 모니터링: 특정 시점의 응답 속도가 아니라 일정 기간 동안의 가용성·안정성은 ViewCheck의 일회성 분석으로는 측정할 수 없다. 별도 모니터링 인프라가 필요한 영역이다.
Vision AI의 신뢰도: KRDScan의 Vision AI가 스크린샷을 보고 컴포넌트를 감지하고 KRDS 규칙 준수 여부를 판정하는 기능은, 현재 정확도가 DOM 기반 판정보다 낮다. 이 부분은 학습 데이터를 계속 늘려가는 방향으로 개선 중이다.
개방성의 시맨틱 분석: robots.txt의 Disallow 패턴이 실제로 얼마나 많은 콘텐츠를 막는지 의미론적으로 해석하는 건 아직 단순 파싱 수준에 머물러 있다.

이 한계 목록이 길다고 해서 자동화가 쓸모없다는 뜻은 아니다. 반대로, 자동화로 빠르게 커버할 수 있는 영역(HTML 문법, 보안 헤더, Core Web Vitals, DOM 기반 접근성)에서 드는 노력을 자동화로 줄이고, 그 여력으로 자동화가 어려운 부분에 사람의 판단을 집중하는 것이 현실적인 전략이다.

"7대 영역 점수"를 어떻게 읽어야 하는가 — 숫자의 의미

ViewCheck가 7대 영역별로 점수를 보여줄 때, 그 숫자를 어떻게 읽어야 하는지에 대해 한 가지 짚고 싶은 게 있다.

점수는 상대적 우선순위를 보는 도구이지, 절대적 품질 인증이 아니다.

예를 들어 신뢰성 점수가 40점이고 접근성 점수가 75점이라면, "신뢰성 보안 설정을 먼저 개선하는 게 좋겠다"는 판단의 근거로 쓰는 것이 바람직한 활용이다. "우리 사이트 접근성이 75점이니 양호하다"는 식으로 절대적 기준으로 쓰면 곤란하다. 점검 방법의 한계(자동화로 못 잡는 43%), 측정 환경의 차이(서버 성능·네트워크 조건), 페이지 표본의 대표성 문제가 모두 점수에 영향을 미친다.

그래서 ViewCheck의 7대 품질 대시보드는 숫자 자체보다 "왜 이 점수가 나왔는가" — 구체적인 미통과 항목과 근거 — 를 함께 보여주는 것을 더 중요하게 여긴다. 점수는 대화의 시작이지 결론이 아니라는 뜻이다.

사무실에서 태블릿의 품질 체크리스트를 확인하며 체크하는 감사 담당자의 모습. — 태블릿으로 품질 체크리스트를 확인하는 감사 담당자. 점수는 시작점일 뿐 — 근거가 담긴 상세 체크리스트가 진짜 가치다.

24개 분석 카드와 7대 영역의 연결 — 어떤 카드가 어떤 영역을 다루는가

ViewCheck의 24개 LLM 분석 기능이 7대 영역과 어떻게 대응하는지 정리하면 이렇다.

7대 영역	관련 분석 카드
호환성	오류 리스트, KRDS 846, KRDS 비교
접근성	접근성(KWCAG), KRDS 846, 오류 리스트
개방성	SEO, 오류 리스트
접속성	웹 성능, 성과 대시보드
편의성	컴포넌트, 기본 패턴, 서비스 패턴, UX 라이팅
효율성	웹 성능, 성과 대시보드
신뢰성	보안, 법적 리스크
KRDS 전반	종합총평, 인사이트, 임원보고서, 디자인 스타일, KRDS 846, KRDS 비교, 위반 매트릭스, 일관성, 벤치마킹, 비용·MM, 개선 로드맵, AI 종합 리포트

이 표에서 보이듯, 호환성·접근성·개방성·접속성·편의성·효율성·신뢰성이라는 7대 영역은 24개 카드 전체에 분산되어 있다. 하나의 카드가 하나의 영역만 다루는 게 아니라, 여러 영역이 여러 카드에 걸쳐 다양한 관점으로 표현된다. 임원보고서 카드는 7대 영역 전체의 핵심 이슈를 요약하고, 위반 매트릭스 카드는 어떤 규칙이 어떤 페이지에서 반복적으로 문제가 되는지를 보여주며, 개선 로드맵 카드는 7대 영역 전반에 걸친 개선 우선순위를 제안한다.

이 구조의 장점은 사용자의 역할에 따라 다른 '입구'를 제공한다는 것이다. 보안 담당자는 보안 카드와 법적 리스크 카드부터 보고, 웹마스터는 웹 성능과 SEO 카드를 먼저 보며, 보고서를 써야 하는 기획 담당자는 임원보고서와 종합총평 카드를 먼저 연다.

행안부 지침의 개정 흐름 — 기준은 계속 움직인다

자동화 도구를 만드는 입장에서 가장 골치 아픈 것 중 하나는 기준이 고정돼 있지 않다는 점이다. 행안부 품질 지침은 몇 년 주기로 개정된다.

2020년 고시(제2020-38호)에서 '전자정부서비스 호환성 준수지침'이 '전자정부 웹사이트 품질관리 지침'으로 명칭이 바뀌고 영역이 7개로 확장됐다. 2024년 고시(제2024-25호)에서 또 개정됐고, 2025년 고시(제2025-46호)에서 세부 점검 항목을 가이드로 분리하는 구조 변화가 이루어졌다. 앞으로도 디지털 환경의 변화에 따라 계속 개정될 것이다.

이 흐름은 WCAG도 마찬가지다. WCAG 2.2가 2023년 10월 공식 권고안으로 확정됐고, W3C는 WCAG 3.0 작업도 진행 중이다. 국제 기준이 바뀌면 그것을 참조하는 KWCAG도 개정되고, 그에 맞춰 ViewCheck의 접근성 판정 로직도 업데이트해야 한다.

이 연속성 때문에, ViewCheck의 규칙 관리는 코드에 하드코딩하지 않고 데이터로 분리한다. 규칙 정의는 krds-rules-846.json 같은 데이터 파일에 있고, 판정 로직은 이를 읽어 처리하는 엔진 코드로 분리되어 있다. 기준이 바뀌면 데이터를 업데이트하는 것으로 대부분의 변경을 흡수할 수 있도록 하기 위해서다. 물론 아직 이 구조가 완전하지는 않고, 특정 규칙의 로직이 코드 안에 묻혀 있는 경우도 있다. 이를 더 깔끔하게 분리하는 것도 진행 중인 리팩터링 과제다.

공공 사이트의 실제 품질 현황 — 관찰한 패턴들

ViewCheck를 개발하면서 실제 공공 사이트를 수없이 분석했다. 개별 사이트를 특정하지 않겠지만, 반복적으로 관찰되는 패턴들을 공유할 수 있다.

호환성 측면에서: ActiveX 관련 안내 문구는 많이 줄었다. 그러나 IE 시대의 유산인 비표준 HTML 구조(예: <div> 기반의 레이아웃, <table>로 만든 폼)가 아직 많이 남아 있다. 이런 구조는 스크린 리더 같은 보조기술에도 좋지 않아서 접근성 문제로도 이어진다.

접근성 측면에서: 이미지에 alt 속성이 없거나, 빈 alt=""로 처리된 경우가 의외로 많다. 배너나 홍보 이미지가 alt가 없어서 스크린 리더 사용자에게 아무 정보도 전달되지 않는 사례. 폼의 입력 필드에 라벨(<label>)이 없이 placeholder만 있는 경우도 흔하다. placeholder는 입력을 시작하면 사라져서 접근성 측면에서 라벨의 대체물이 될 수 없다.

효율성 측면에서: 고해상도 스크린샷을 최적화 없이 올리는 사례가 적지 않다. 3~4MB짜리 이미지가 메인 페이지 배너로 올라와 있으면, 아무리 서버 응답이 빨라도 페이지 로드 시간이 길어진다. WebP나 AVIF 같은 현대적 이미지 포맷 활용은 아직 드물다.

신뢰성 측면에서: SSL 인증서 자체는 대부분 있다. 그러나 보안 헤더는 많은 사이트에서 누락이 있다. 특히 CSP(Content Security Policy)는 설정이 복잡해서 많이 건너뛰어진다. 반면 X-Content-Type-Options 같이 비교적 설정이 단순한 헤더도 누락된 사이트가 꽤 있다.

이런 패턴을 발견하는 것 자체가 자동화의 가치다. 수백 개 사이트를 한 명이 손으로 점검하면서 이 패턴을 통계로 쌓는 건 불가능하다. 자동화로 대규모 분석을 해야 이런 '공공 웹의 공통 취약 지점'이 드러난다.

다음 단계: 7대 영역 자동화의 남은 숙제들

지금까지 7대 영역 자동화의 현재 상태를 솔직하게 적었다. 이제 앞으로 해결해야 할 숙제들을 정리한다.

단기 과제:

개방성 점검에서 robots.txt Disallow 범위의 의미론적 분석 고도화
접속성 측정에서 HTTP 리다이렉트 체인 횟수와 최종 URL까지의 경로 추적
신뢰성 측면에서 개인정보처리방침 페이지의 존재 확인을 넘어 마지막 업데이트일 확인
효율성에서 JS 번들 분석 — 어떤 라이브러리가 번들 크기를 키우는지

중기 과제:

접근성의 동적 인터랙션 검증(키보드 탐색 시나리오 자동화)
크로스 브라우저 테스트 인프라 구축(Firefox, Safari 브라우저 추가)
Vision AI의 컴포넌트 감지 정확도 향상(현재 YOLOv8 기반 mAP50 0.456에서 더 높이기)
Core Web Vitals 실험실 수치와 필드 데이터 간 보정 방법 연구

장기 과제:

접속성 모니터링(시점 분석이 아닌 장기 가용성 추적)
행안부 지침 개정 사이클에 맞춘 규칙 자동 업데이트 파이프라인
기관별 벤치마킹 대비 자동 생성

이 숙제 목록을 공개하는 이유는 두 가지다. 하나는 지금 어디까지 됐고 어디서부터는 아직 안 됐는지를 사용자에게 솔직하게 알리기 위해서다. 다른 하나는 이 숙제들이 이 시리즈의 다음 편들에서 다룰 주제이기도 하기 때문이다. "이런 게 어렵다"고 쓴 것들이 그대로 다음 R&D 편의 제목이 된다.

ViewCheck LLM 분석에서 7대 품질이 보이는 방법

LLM 분석 기능에서 7대 품질진단을 실제로 보려면 어떻게 하면 될까. 채팅창에 공공 사이트 URL 한 줄을 넣고 기다리면, 분석이 완료된 뒤 24개 카드가 대화에 쌓인다.

7대 영역을 한눈에 보고 싶다면 성과 대시보드 카드를 먼저 펼치면 된다. 여기서 7대 영역별 점수가 레이더 차트나 게이지 형태로 시각화된다. "왜 이 점수가 나왔는가"가 궁금하면, 해당 영역의 세부 카드(예: 보안 카드, 웹 성능 카드)를 보거나, 직접 채팅으로 물어볼 수 있다. "신뢰성 점수가 낮은 이유가 뭐야?"라고 물으면, 미통과된 보안 헤더 목록과 각 헤더의 의미, 개선 방법이 돌아온다.

오류 리스트 카드는 7대 영역 전체에 걸친 미통과 항목을 하나로 모아서, 우선순위(P0~P3)에 따라 정렬해 보여준다. 어디서부터 고쳐야 하는지 감을 잡는 데 유용하다. 개선 로드맵 카드는 우선순위별로 "이 기간 안에 이것부터, 그다음에 이것"으로 단계별 계획을 제안한다.

이 대화 흐름은 정형화된 보고서를 일방적으로 전달하는 것이 아니라, 담당자가 궁금한 방향으로 파고들 수 있는 구조다. "이 기관이 우리 사이트보다 어떤 영역이 나은가"를 벤치마킹 카드로 보거나, "이 미통과 항목을 고치는 데 비용이 얼마나 드는가"를 비용·MM 카드로 확인하는 것도 같은 대화 흐름 안에서 이루어진다.

마무리 — 7대 영역은 '하나의 도구'로 끝나지 않는다

행안부가 규정하는 7대 품질 영역 — 호환성·접근성·개방성·접속성·편의성·효율성·신뢰성 — 은 같은 '품질'이라는 이름 아래 있지만 측정 방법이 전혀 다르다. DOM과 CSS로 판정하는 것, HTTP 요청으로 재는 것, 눈으로 봐야 판단하는 것이 뒤섞여 있다.

이 다양성을 존중하는 것이 ViewCheck 설계의 출발점이었다. 하나의 만능 도구가 아니라, 영역별로 가장 적합한 방법을 쓰는 세 엔진의 분업. DOM은 DOM 엔진이, HTTP는 수집 엔진이, 시각적 판단은 Vision AI가 맡는다. 그리고 그 결과를 다중 페이지 기준으로 집계해서, 메인 한 장이 아닌 사이트 전체의 품질을 24개 분석 카드로 대화처럼 제시한다.

완성됐다는 말은 못 한다. 앞에서 나열한 한계들이 여전하고, 자동화가 닿지 못하는 43%의 접근성 이슈처럼 사람의 판단이 여전히 필요한 영역도 있다. 하지만 자동화로 커버할 수 있는 영역에서 담당자의 손을 덜어주고, 그 여력을 자동화가 못 하는 판단에 쓸 수 있게 하는 것 — 그게 우리가 7대 품질 자동화에서 현실적으로 추구하는 목표다.

다음 편에서는 이 자동화 결과를 어떻게 성능 측면에서 더 정확하고 빠르게 만들 것인지를 다룬다. 자동화의 속도와 신뢰도를 함께 높이는 일, 그게 다음 R&D 노트의 주제다.

참고문헌

본문에 인용한 출처는 작성 시점에 모두 실재 여부를 검증했다. 국내 공식 규정·정책자료와 해외 공식 문서·기술 자료를 함께 실었다.

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

행정안전부, 「전자정부 웹사이트 품질관리 지침」 일부개정 및 「품질관리 가이드」 수정본 안내 (행정안전부고시 제2025-46호, 2025. 6. 25.). 행정안전부 공식. https://www.mois.go.kr/frt/bbs/type001/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000016&nttId=118636
행정안전부, 「전자정부 웹사이트 품질관리 지침」 전문 (국가법령정보센터). https://law.go.kr/LSW/admRulInfoP.do?admRulSeq=2100000260906&chrClsCd=010201
행정안전부, 「전자정부 웹사이트 품질관리 가이드」 수정본 안내 (2025. 6. 30.). 행정안전부 새소식. https://www.mois.go.kr/frt/bbs/type013/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000006&nttId=118639
행정안전부·디지털플랫폼정부위원회, KRDS(디지털 정부서비스 UI/UX 가이드라인) 공식 사이트. https://www.krds.go.kr/
KDI 경제교육·정보센터, "누구나 쉽게 사용할 수 있는 공공 웹·앱 혁신, '범정부 UI/UX 디자인시스템(KRDS)'으로부터". https://eiec.kdi.re.kr/policy/materialView.do?num=262364&pg=&pp=&topic=O

해외 — 기술 표준 / 디자인 시스템 / 연구자료

W3C, "Web Content Accessibility Guidelines (WCAG) 2.2" (W3C Recommendation, 2023. 10. 5.). https://www.w3.org/TR/WCAG22/
W3C, "WCAG 2.2 is a W3C Recommendation" (공식 발표, 2023). https://www.w3.org/news/2023/web-content-accessibility-guidelines-wcag-2-2-is-a-w3c-recommendation/
Government Digital Service, GOV.UK Design System 공식. "Accessibility — GOV.UK Design System". https://design-system.service.gov.uk/accessibility/
GOV.UK Accessibility Blog, "Get to WCAG 2.2 faster with the GOV.UK Design System" (2024. 1. 11.). https://accessibility.blog.gov.uk/2024/01/11/get-to-wcag-2-2-faster-with-the-gov-uk-design-system/
U.S. Web Design System (USWDS), "Accessibility" 공식. https://designsystem.digital.gov/documentation/accessibility/
Deque Systems, axe-core 공식 ("axe-core by Deque | open source accessibility engine for automated testing"). https://www.deque.com/axe/axe-core/
Google, "Introducing INP to Core Web Vitals" (Google Search Central Blog, 2023. 5.). https://developers.google.com/search/blog/2023/05/introducing-inp