KRDS를 AI로 진단한다는 것 — 36편을 시작하며

"AI로 분석한다"는 말이 흔해진 시대에, 우리는 먼저 그 말의 정의부터 다시 썼다

들어가며 — 36편을 시작하기 전에

이 글은 시리즈의 0편이다. 본편(1~36편)이 "ViewCheck는 KRDS를 AI로 이렇게 분석한다"를 한 주제씩 풀어가는 이야기라면, 이 0편은 그 36편 전체가 딛고 서 있는 바닥에 대한 이야기다. 무슨 문제를 풀려 했고, 우리가 "KRDS의 LLM 분석"을 어떻게 정의했으며, 그 정의가 지키려는 **기준(원칙)**이 무엇인지를 먼저 던져두려 한다.

요즘 "AI로 분석합니다"라는 문장은 너무 흔해졌다. 웹사이트 점검도, 접근성 검사도, 디자인 평가도 죄다 "AI"를 앞에 붙인다. 그런데 그 말이 정확히 무엇을 뜻하는지 — AI가 무엇을 보고, 무엇을 근거로, 무엇을 판정하며, 틀렸을 때 어떻게 책임지는지 — 를 또박또박 설명하는 경우는 드물다. 우리는 그 흔한 문장을 쓰기 전에, 먼저 우리 스스로에게 물었다. "KRDS를 AI로 진단한다는 게, 도대체 뭘 한다는 거지?"

이 0편은 그 질문에 대한 우리의 답이다. 미리 말해두면, 우리는 "ViewCheck가 정답입니다"라고 말하려는 게 아니다. 오히려 이 시리즈 전체의 톤은 "우리는 이렇게 정의하고, 이렇게 연구하고 있다"에 가깝다. 공공 웹 품질이라는 주제는 한 줄로 끝낼 수 있는 게 아니고, 솔직히 우리도 아직 풀어가는 중인 문제가 더 많다. 그래서 정답을 선언하는 대신, 우리가 세운 정의와 기준을 먼저 공개하고, 그것을 36편에 걸쳐 하나씩 증명해 보이는 방식을 택했다.

문제: 공공 웹 KRDS 준수, 누가 다 확인하나

먼저 우리가 풀려던 문제부터 보자. 대한민국에는 공공 웹사이트가 지켜야 할 기준이 분명히 존재한다.

행정안전부는 「전자정부 웹사이트 품질관리 지침」이라는 고시를 운영한다. 이 지침은 2025년 6월 25일자로 행정안전부고시 제2025-46호로 일부개정되어 시행 중이다(국가법령정보센터·행정안전부). 호환성·접근성·개방성·접속성·편의성·효율성·신뢰성이라는 7대 품질 영역으로 공공 웹의 건강 상태를 본다.

여기에 더해, 최근 공공 디지털 서비스의 화면을 하나의 결로 모으려는 시도가 빠르게 자리 잡았다. 바로 **KRDS(범정부 UI/UX 디자인 시스템)**다. KRDS는 행정안전부와 디지털플랫폼정부위원회가 배포한 디자인 시스템으로, 정부상징을 쓰는 기관의 웹·앱에 적용하는 것을 목표로 한다(KRDS 공식, krds.go.kr). KDI 경제정보센터는 KRDS의 의의를 "누구나 쉽게 사용할 수 있는 공공 웹·앱 혁신"의 토대라고 정리한다(KDI 경제교육·정보센터). 원칙·스타일·컴포넌트·기본 패턴·서비스 패턴의 위계로 구성되며, 핵심은 일관성과 접근성이다.

기준은 이렇게 분명하다. 문제는 그 기준을 누가, 어떻게 다 확인하느냐다.

공공 웹사이트는 메인 페이지 하나로 끝나지 않는다. 검색, 신청, 게시판 목록, 상세, 로그인, 정책 안내… 수십에서 수백 개의 화면이 있다. 각 화면이 KRDS의 어떤 규칙을 지켰는지, 7대 품질을 충족하는지를 사람이 한 장 한 장 항목표를 대조하며 손으로 점검한다면? 한 페이지를 꼼꼼히 보는 데만 한참이 걸린다. 100페이지면 일주일이 사라진다.

그래서 현실에서는 대개 타협이 일어난다. "일단 메인 페이지만 보자." 메인 한 장을 점검하고 그 결과를 사이트 전체의 결과처럼 적는다. 이건 담당자의 게으름이 아니라, 사람의 손으로 사이트 전체를 점검하는 게 물리적으로 불가능에 가깝기 때문이다.

바로 이 지점에서 "자동화"가, 그리고 "AI"가 등장한다. 사람이 다 못 보니 기계가 대신 본다는 것. 좋다. 그런데 여기서 두 번째 함정이 기다린다.

"AI로 진단한다"는 말의 함정

자동화와 AI는 분명 답의 일부다. 하지만 "AI를 붙였으니 됐다"는 식의 접근은 위험하다. 왜냐하면 품질 진단이라는 영역에서 AI가 가장 잘 하는 실수가 바로 그럴듯하게 틀리는 것이기 때문이다.

AI에게 웹페이지를 던져주고 "이 사이트 KRDS 잘 지켰어?"라고 물으면, 그럴듯한 답이 나온다. 점수도 매겨준다. 문제는 그 답의 근거를 물었을 때다. 근거를 얼버무리거나, 심지어 존재하지 않는 규칙을 지어내거나(이른바 환각, hallucination), 페이지마다 다른 잣대로 판정하기도 한다. 공공 영역에서 이런 진단을 그대로 믿고 보고서에 옮기면, 그 부정확함은 고스란히 책임 문제로 돌아온다.

사용성 연구의 고전적 기관인 닐슨 노먼 그룹(Nielsen Norman Group, NN/g)도 대화형·지능형 시스템의 한계를 냉정하게 지적해 왔다. 요지는 이런 시스템이 "답이 비교적 단순하고 짧은, 매우 제한된 질의에서만 잘 작동한다"는 것이다(NN/g 챗봇·대화형 인터페이스 UX 연구). NN/g가 2023년 ChatGPT·Bard·Bing Chat 사용 425건을 분석한 연구에서도, 생성형 AI와의 대화가 6가지 유형으로 나뉘며 유형마다 서로 다른 인터페이스와 접근이 필요하다고 결론지었다(Nielsen Norman Group, "The 6 Types of Conversations with Generative AI", 2025). "AI 하나면 다 된다"는 환상과는 거리가 멀다.

그래서 우리는 깨달았다. "AI로 분석한다"는 말은, 그 자체로는 아무것도 보장하지 않는다는 것. 중요한 건 AI를 어떻게 길들이느냐, 즉 무엇을 보게 하고, 무엇을 근거로 삼게 하며, 어디까지는 절대 AI에게 맡기지 않느냐다. 이 "어떻게"가 빠진 AI 진단은 장난감에 가깝다.

그렇다면 우리의 "어떻게"는 무엇인가. 그것을 말하기 전에, 우리는 한 단계를 더 거슬러 올라갔다. **정의(definition)**다.

그래서 우리는 먼저 '정의'부터 했다

대부분의 도구는 기능부터 만든다. "버튼 감지 기능", "색상 대비 측정 기능"… 기능을 쌓다 보면 어느새 제품이 된다. 그런데 우리는 기능을 쌓기 전에, 의외로 오래 붙잡은 질문이 있었다.

"우리가 만들려는 'KRDS의 LLM 분석'은, 한 문장으로 말하면 무엇인가?"

이 질문이 중요했던 이유가 있다. 정의가 흐릿하면, 기능은 방향 없이 늘어난다. "이것도 되고 저것도 되는데, 정작 핵심이 뭔지 모르겠는" 도구가 된다. 반대로 정의가 또렷하면, 모든 기능은 그 정의를 향한 수단이 되고, 어떤 기능을 넣고 뺄지도 정의가 결정해 준다.

그래서 우리는 기능 목록이 아니라 한 문단짜리 정의를 먼저 썼다. 그리고 그 정의가 지켜야 할 **기준(원칙)**을 뽑았다. 이 시리즈 36편은, 솔직히 말하면 그 정의와 원칙을 하나씩 풀어 보이는 긴 각주에 가깝다.

다음 장에서, 우리가 내린 정의를 그대로 공개한다.

ViewCheck의 정의 — "KRDS LLM 분석"이란 무엇인가

우리가 못 박은 정의는 이것이다.

ViewCheck의 KRDS LLM 분석이란 — URL 한 줄로 공공 웹을 사이트 전체(다중 페이지) 훑어, KRDS 846규칙과 7대 품질을 DOM·Vision·HTTP로 실제 측정하고, 그 판정 하나하나에 **규칙 원문·공식 문서 근거(RAG)**를 붙여 대화로 설명하는 것. AI가 '정답'을 선언하는 게 아니라, 근거를 갖춘 진단 동료로서 사람의 최종 판단을 돕는 것.

이 한 문단에는 의도적으로 넣은 단어들이 있다. 하나씩 짚어보자.

"URL 한 줄로" — 사용자의 진입 장벽을 최대한 낮춘다. 공공 웹 담당자의 다수는 개발자가 아니라 행정 실무자다. 복잡한 설정 대신, 채팅창에 주소 한 줄이면 시작된다.
"사이트 전체(다중 페이지)" — 메인 한 장이 아니다. 정작 시민이 불편을 겪는 곳은 신청·검색·로그인 같은 깊은 화면이다. 사이트 전체를 보는 게 우리가 양보하지 않는 출발점이다.
"DOM·Vision·HTTP로 실제 측정" — '품질'은 측정 방식이 영역마다 다르다. 구조(DOM)로 알 수 있는 것, 눈(Vision)으로만 보이는 것, 서버에 요청(HTTP)해야 재는 것을 각각 알맞은 방법으로 측정한다.
"근거(RAG)를 붙여" — 모든 판정에는 근거가 따라붙는다. "AI가 그렇대"가 아니라 "이 규칙 원문·이 공식 문서에 따라 그렇다"를 보여준다.
"대화로" — 방대한 결과를 표로 던지는 대신, 누군가 옆에서 설명하듯 카드로 풀어낸다.
"근거를 갖춘 진단 동료" — 가장 중요한 단어다. AI는 정답기가 아니라 동료다. 최종 판단과 책임은 사람에게 남긴다.

정의는 방향을 준다. 하지만 방향만으로는 부족하다. "근거를 갖춘 진단 동료"라는 말이 실제로 무엇을 의미하는지, 어떤 조건을 지켜야 그 말이 거짓이 아닌지 — 그것을 검증 가능한 기준으로 풀어야 한다. 그래서 우리는 6개의 원칙을 세웠다.

정의만으론 부족하다 — 6개의 기준(원칙)이 필요했다

정의가 "무엇을 만드는가"라면, 원칙은 "그것이 갖춰야 할 조건은 무엇인가"다. 우리는 'AI 진단이 신뢰받으려면 반드시 지켜야 할 것들'을 6가지로 정리했다. 그리고 이 6원칙은 우연히도 — 사실은 의도적으로 — 이 시리즈의 6개 트랙과 하나씩 맞물린다.

원칙	한 줄 정의	맞물리는 트랙
① 근거주의	추측 0, 모든 판정에 근거(RAG)를 댄다	A. 대화형 AI 진단 방법론
② 기준 충실	KRDS 846규칙 + 7대 품질을 코드로 충실히	B. KRDS 디자인 시스템
③ 사람 중심	접근성·약자를 진단의 중심에 둔다	C. 웹 접근성
④ 실측 측정	DOM·Vision·HTTP로 '실제로' 잰다	D. 7대 품질·성능
⑤ 전체를 본다	메인 1장이 아니라 사이트 전체를 데이터로	E. 데이터·벤치마킹
⑥ 정직한 AI	환각 억제·프로덕션 실측·사람이 최종 판단	F. 플랫폼·R&D

이제 이 6개를 하나씩, 왜 원칙으로 삼았는지와 함께 풀어보자. 각 원칙이 바로 그 트랙 편들의 주제를 미리 던지는 예고편이기도 하다.

원칙 ① 근거주의 — "AI가 그렇대"를 금지한다

첫 번째 원칙이자 가장 중요한 원칙이다. 우리는 판정에 근거가 없으면 그것을 판정으로 인정하지 않는다.

앞서 말했듯 AI의 가장 큰 위험은 그럴듯하게 틀리는 것이다. 그래서 우리는 처음부터 "AI가 똑똑하다"는 가정을 버렸다. 대신 AI가 근거를 댈 수밖에 없게 설계했다. 판단에 필요한 근거 문서 — 846규칙 원문, KRDS 공식 가이드, 공식 컴포넌트 스펙 — 를 먼저 찾아서 AI 앞에 펼쳐주고, "이 근거를 보고 판단하고, 그 근거를 함께 제시하라"고 요구한다. 이것이 RAG(Retrieval-Augmented Generation, 검색 증강 생성)라는 접근이다.

그 결과, 사용자는 결과 옆 참조패널에서 "이 판정이 어떤 규칙·어떤 문서에 기반했는지"를 직접 확인할 수 있다. "이 버튼은 미통과"가 아니라 "이 버튼이, 이 규칙의 이 조건을 충족하지 못해서 미통과 — 근거는 여기"라고 말할 수 있어야, 담당자가 실제로 고칠 수 있다.

근거주의는 단순한 기능이 아니라 태도다. 그것은 제품을 만드는 우리 자신에게도 적용된다. 코드 경로만 보고 "문제없다"고 결론 내리지 않고, 실제로 돌려보고 결과를 눈으로 확인한 뒤에야 "된다"고 말한다. 제품이 사용자에게 약속하는 것을, 만드는 사람부터 지키려는 것이다.

이 원칙은 트랙 A(방법론)에서 'LLM을 평가자로 쓰는 실험', 'RAG로 근거를 대는 컴플라이언스', '환각 없는 규칙 판정' 같은 편으로 깊이 다룬다.

원칙 ② 기준 충실 — 846규칙과 7대 품질을 코드로

두 번째 원칙은 단순하지만 노동집약적이다. AI가 '느낌'으로 판단하게 두지 않고, 명시된 기준을 코드로 충실히 옮긴다.

KRDS의 위계(스타일·컴포넌트·기본 패턴·서비스 패턴)를 점검 가능한 형태로 풀면, 우리 기준으로 846개의 규칙이 된다. 분포는 디자인 스타일(DS) 120, 컴포넌트(CP) 446, 기본 패턴(BP) 108, 서비스 패턴(SP) 172이다. 여기에 행안부 7대 품질 영역이 더해진다.

여기서 한 가지 솔직히 짚을 게 있다. "846규칙"은 KRDS 공식 문서가 그 숫자를 박아둔 게 아니다. KRDS는 원칙·스타일·컴포넌트·기본 패턴·서비스 패턴이라는 구성으로 제시되고, 우리는 그것을 점검 가능한 규칙 단위로 풀어내며 846개로 구현했다. 즉 846은 'KRDS의 공식 숫자'가 아니라 'ViewCheck가 KRDS를 코드로 옮긴 결과의 규모'다. 이런 구분을 분명히 하는 것 자체가 원칙 ①(근거주의)의 실천이기도 하다.

기준 충실의 또 다른 얼굴은 디자인 토큰이다. KRDS는 색상·타이포·간격 같은 시각의 기본 언어를 토큰으로 관리한다. 우리가 실측한 규모는 색상 토큰 약 586개, 전체 약 768개 수준이다. 사이트가 이 토큰을 얼마나 채택했는지를 정량으로 재는 일은, '대충 비슷해 보인다'가 아니라 '실제 값이 기준과 같은가'를 따지는 작업이다.

이 원칙은 트랙 B(디자인)에서 디자인 토큰 채택률, 컴포넌트 자동 감지, 기본·서비스 패턴 진단, 그리고 KRDS와 해외 디자인 시스템(GOV.UK·USWDS) 비교로 이어진다.

원칙 ③ 사람 중심 — 접근성을 진단의 변두리에 두지 않는다

세 번째 원칙은 '무엇을 위해 진단하는가'에 대한 답이다. 공공 웹의 품질은 결국 사람이 쓸 수 있느냐의 문제고, 그 중심에는 약자가 있다.

접근성은 종종 점검 항목의 한 칸으로 취급된다. 하지만 우리는 그것을 변두리에 두지 않으려 했다. 고령자, 저시력 사용자, 색각 이상이 있는 사용자, 키보드만으로 조작하는 사용자, 키오스크 앞에 선 사용자 — 이들이 실제로 막히는 지점을 진단의 중심으로 끌어온다.

한국에는 한국형 웹 콘텐츠 접근성 지침(KWCAG 2.2)이 있고, 국제 표준으로는 W3C의 WCAG 2.2가 있다. GOV.UK Design System이 모든 컴포넌트를 보조기술로 검증하고 WCAG 기준을 충족하도록 만든 것처럼(GOV.UK Design System 공식), 접근성을 시스템의 기본값으로 끌어올리는 일은 수백 개 서비스의 '기본 접근성'을 한꺼번에 올리는 일과 같다.

다만 솔직해야 할 것이 있다. 접근성의 상당 부분은 자동으로 판정되지만, 대체 텍스트가 '적절한가', 키보드 흐름이 '자연스러운가' 같은 판단은 기계만으로는 어렵다. 이 한계를 인정하고, 어디까지 자동이고 어디부터 사람의 눈이 필요한지를 분명히 하는 것 — 그것도 사람 중심 원칙의 일부다.

이 원칙은 트랙 C(접근성)에서 KWCAG 2.2 자동 진단, 엔진 교차검증, 색상 대비 측정, 자동화의 한계, 그리고 고령·모바일·저시력·키오스크 맥락으로 펼쳐진다.

원칙 ④ 실측 측정 — '추정'이 아니라 '측정'

네 번째 원칙은 방법에 대한 고집이다. 품질은 추정하는 게 아니라 측정하는 것이다.

7대 품질 영역을 보면 성격이 제각각이다. 어떤 건 DOM 구조를 뜯어보면 알 수 있고(호환성·접근성 일부), 어떤 건 실제 브라우저로 화면을 띄워 눈으로 봐야 하며(디자인의 시각적 일관성), 어떤 건 서버에 직접 HTTP 요청을 보내봐야 한다(접속성·효율성·신뢰성). 응답 시간, SSL 인증서, 보안 헤더, 핵심 웹 지표(LCP·INP·CLS) 같은 값은 DOM만 들여다봐서는 절대 알 수 없다. 브라우저가 실제로 접속해 재야 한다.

그래서 우리는 하나의 만능 방법으로 전부 처리하려 하지 않았다. 각 영역을 '실측이 가능한 방식'으로 측정한다. 이것이 다음 원칙(분업)과도 이어진다.

ViewCheck LLM 분석의 종합총평 결과가 카드 형태로 정리되어 표시된 실제 프로덕션 캡처. — 실제 ViewCheck LLM 분석의 종합총평 화면. 추정이 아니라 측정된 결과가 카드로 정리된다. — 실제 분석 화면

이 원칙은 트랙 D(7대 품질·성능)에서 7대 품질 자동화 개요, Core Web Vitals 실측, 보안 헤더, 개방성(robots.txt·sitemap.xml), 반응형 품질로 구체화된다.

원칙 ⑤ 전체를 본다 — 메인 한 장의 함정

다섯 번째 원칙은 앞에서 이미 한 번 강조했지만, 원칙으로 다시 못 박을 만큼 중요하다. 사이트의 품질은 메인 페이지 한 장으로 판정할 수 없다.

메인은 보통 가장 공들여 만든 화면이다. 예쁘고, 정돈돼 있고, 규칙도 잘 지켜져 있다. 그런데 정작 시민이 불편을 겪는 곳은 신청서를 작성하는 화면, 검색 결과가 나오는 화면, 로그인하는 화면 같은 '깊은 곳'이다. 메인만 보고 사이트 전체를 평가하면, 가장 중요한 곳을 놓친다.

그래서 우리는 처음부터 다중 페이지 분석을 기본값으로 설계했다. 한 페이지가 아니라 사이트 전체를 보고, 그 결과를 데이터로 집계한다. 어떤 규칙 위반이 어느 페이지에 퍼져 있는지(위반 매트릭스), 동종 기관과 비교하면 어디쯤인지(벤치마킹), 무엇부터 고치면 좋은지(개선 로드맵) — 이런 건 '사이트 전체를 데이터로 본다'는 전제 위에서만 가능하다.

물론 사이트 전체를 본다는 건 사람이 감당할 수 없는 양을 본다는 뜻이고, 그래서 크롤링 인프라를 안정적으로 운영하는 일 자체가 또 하나의 과제가 된다. 이 원칙은 트랙 E(데이터·벤치마킹)에서 벤치마킹, 위반 매트릭스, SEO 실태, UX 라이팅, 비용·MM 추정, 개선 로드맵으로 다뤄진다.

원칙 ⑥ 정직한 AI — 환각을 억제하고, 사람에게 결정을 남긴다

마지막 원칙은 다시 첫 원칙과 손을 맞잡는다. AI는 똑똑한 척하지 않는다. 틀릴 수 있음을 인정하고, 그래서 근거를 보이고, 최종 결정은 사람에게 남긴다.

이를 위해 우리는 시스템을 셋으로 나눴다. 수집·통합을 맡는 ViewCheck, DOM으로 846규칙을 판정하는 KRDSrule 엔진, 그리고 DOM으로 못 보는 시각적 영역과 근거(RAG)를 맡는 KRDScan 엔진이다. 중요한 건 이 셋 사이의 '충돌 방지' 원칙이다. DOM이 명확히 통과/미통과로 판정한 건 AI가 함부로 뒤집지 않는다. AI는 DOM이 '해당없음'으로 남긴 빈칸과, DOM이 못 보는 시각적 영역만 독자적으로 채운다. 누가 무엇을 책임지는지가 분명해야 결과가 흔들리지 않는다.

정직함은 검증 방식에도 적용된다. 합성 테스트만 통과했다고 "완성"이라 말하지 않고, 실제 프로덕션에서 돌려 결과를 확인한 뒤에야 배포한다. 그리고 무엇보다, 진단 결과를 맹신하게 만들지 않는다. AI는 빠르게 훑어주고 근거를 대주는 동료일 뿐, 최종 판단과 책임은 사람의 몫으로 남긴다.

이 원칙은 트랙 F(플랫폼·R&D)에서 3엔진 아키텍처, 24기능 통합 설계, 프로덕션 검증, 멀티 에이전트 하네스, 비용 최적화, 그리고 정답셋·파인튜닝 로드맵으로 이어진다.

6원칙을 어떻게 증명할 것인가 — 36편의 지도

정의와 6원칙을 던졌으니, 이제 그것을 증명할 차례다. 36편은 6개 트랙으로 나뉘고, 각 트랙이 하나의 원칙을 깊이 판다. 전체 지도를 한눈에 펼치면 이렇다.

트랙 A — 대화형 AI 진단 방법론 (1~7편) · 원칙 ① 근거주의 대화 한 줄로 24기능을 어떻게 구현·실험하는가. 입문 / LLM을 평가자로 / RAG 근거 / DOM vs Vision / N/A 감소 / 환각 방지 / 사람 vs AI 일치도.

트랙 B — KRDS 디자인 시스템 (8~13편) · 원칙 ② 기준 충실 토큰 채택률 / 컴포넌트 자동 감지 / 기본 패턴 / 서비스 패턴 / KRDS vs GOV.UK·USWDS / 일관성 정량화.

트랙 C — 웹 접근성 (14~19편) · 원칙 ③ 사람 중심 KWCAG 2.2 / 엔진 교차검증 / 색상 대비 / 법적 리스크 / 자동화의 한계 / 고령·모바일·저시력·키오스크.

트랙 D — 7대 품질·성능 (20~24편) · 원칙 ④ 실측 측정 7대 품질 개요 / Core Web Vitals / 보안 헤더 / 개방성 / 반응형 품질.

트랙 E — 데이터·벤치마킹 (25~30편) · 원칙 ⑤ 전체를 본다 벤치마킹 / 위반 매트릭스 / SEO / UX 라이팅 / 비용·MM / 개선 로드맵.

트랙 F — 플랫폼·R&D (31~36편) · 원칙 ⑥ 정직한 AI 3엔진 아키텍처 / 24기능 통합 설계 / 프로덕션 검증 / 멀티 에이전트 하네스 / 비용 최적화 / 정답셋·파인튜닝.

24기능 — 정의가 만들어낸 결과물

정의와 원칙이 추상적으로 들렸다면, 그것이 실제로 무엇을 만들어내는지 보자. ViewCheck LLM 분석은 846규칙 판정 결과를 24개의 분석 관점(기능)으로 재구성해 대화에 카드로 펼친다.

종합총평 · 인사이트 · 임원보고서 · 디자인 스타일 · 컴포넌트 · 기본 패턴 · 서비스 패턴 · KRDS 846 · 접근성(KWCAG) · 보안 · 반응형 · 웹 성능 · SEO · 성과 대시보드 · 오류 리스트 · KRDS 비교 · 일관성 · 위반 매트릭스 · 법적 리스크 · 벤치마킹 · UX 라이팅 · 비용·MM · 개선 로드맵 · AI 종합 리포트.

24개가 많아 보이지만, 그 뿌리는 하나다. 위에서부터 큰 그림(종합총평·인사이트)을 먼저 보여주고, 아래로 내려갈수록 세부(카테고리별 상세·오류 리스트·개선 로드맵)로 들어간다. 디자이너는 디자인 스타일 카드를, 개발자는 오류 리스트와 접근성 카드를, 보고서를 써야 하는 담당자는 임원보고서 카드를 먼저 본다. 같은 분석 결과라도 보는 사람마다 필요한 '입구'가 다르기 때문이다.

그리고 카드는 끝이 아니라 시작이다. 어떤 카드가 "이 부분이 미통과"라고 말하면, 사용자는 바로 그 자리에서 "왜?"라고 되물을 수 있고, 그러면 근거(원칙 ①)가 따라 나온다. 정의의 모든 단어가 이 흐름 안에서 작동한다.

이 정의가 담당자에게 무엇을 바꾸나 — 하나의 장면

원칙이 추상적으로 느껴질 수 있으니, 가상의 장면 하나로 옮겨보자. 어느 기초자치단체 홈페이지를 맡은 주무관을 떠올린다. 그의 업무는 '홈페이지 운영'이지만 실제로는 민원 응대, 게시판 관리, 외주사 커뮤니케이션, 콘텐츠 업데이트, 그리고 가끔 위에서 내려오는 '품질 점검'까지 전부 그의 몫이다.

어느 날 "디지털 품질 점검 결과를 정리해 달라"는 요청이 온다. 예전 같으면 막막했을 일이다. 어디서부터, 무엇을, 어떤 항목으로 봐야 하는지조차 모호하고, 사이트엔 화면이 수백 개다. 메인 한 장만 보고 적당히 보고서를 쓰는 타협이 여기서 일어난다.

이때 우리의 6원칙이 그의 일상에서 무엇을 바꾸는지 보자.

⑤ 전체를 본다 — 그는 메인이 아니라 신청·검색·로그인까지 사이트 전체를 한 번에 돌린다. "메인만 봤다"는 찜찜함이 사라진다.
④ 실측 측정 — 응답 시간, 보안 헤더, 색상 대비가 '느낌'이 아니라 실제 측정값으로 나온다. 보고서에 숫자를 자신 있게 적을 수 있다.
① 근거주의 — "이 항목은 왜 미통과지?"라고 물으면, 근거가 된 규칙 원문과 공식 문서가 함께 뜬다. 그는 그 근거를 외주사에 그대로 전달한다. "이 규칙, 이 페이지에서 이렇게 고쳐주세요." 모호한 지시가 출처 붙은 요청으로 바뀐다.
③ 사람 중심 — 고령·저시력 사용자가 실제로 막히는 지점이 우선순위로 짚인다. '점검을 위한 점검'이 아니라 '쓸 수 있게 만드는 점검'이 된다.
⑥ 정직한 AI — 진단이 틀릴 수 있음을 알기에, 그는 AI 결과를 맹신하지 않고 근거를 확인한 뒤 자기 이름으로 보고한다. 최종 판단은 그의 몫으로 남는다.

여기서 ViewCheck가 한 일은 '담당자를 대체한 것'이 아니다. 담당자가 물리적으로 할 수 없던 일(사이트 전체를 빠짐없이 훑기)을 대신하고, 판단할 수 있도록 근거를 정리해 건넨 것이다. 정의의 마지막 문장 — "사람의 최종 판단을 돕는다" — 이 바로 이 장면이다. 우리는 이 구도를 바꾸려 하지 않는다. 다만 그 사람이 더 빠르고, 더 근거 있게 판단하도록 돕고 싶을 뿐이다.

6원칙은 서로 부딪힌다 — '균형'이라는 숙제

마지막으로, 정직하게 한 가지를 더 털어놓아야 한다. 이 6개의 원칙은 사이좋게 한 방향을 가리키지 않는다. 서로 부딪힌다. 그리고 그 충돌을 어떻게 조율하느냐가, 사실 우리가 지금도 가장 많이 고민하는 부분이다.

몇 가지 긴장을 짚어보자.

① 근거주의 vs 속도 — 모든 판정에 근거 문서를 찾아 붙이는 일(RAG)은 시간이 든다. 근거를 더 깊이 댈수록 분석은 느려진다. "얼마나 근거를 대고, 얼마나 빨리 답할 것인가"는 늘 저울질의 대상이다.
⑤ 전체를 본다 vs 비용 — 사이트 전체 수백 페이지를 돌면 가장 정확하지만, 크롤링과 AI 분석 비용이 페이지 수에 비례해 늘어난다. "어디까지 보고, 어디서 멈출 것인가"에 정답은 없다.
④ 실측 측정 vs ⑥ 정직한 AI — DOM·HTTP로 잰 값은 정확하지만, 눈으로만 보이는 시각적 품질은 AI(Vision)가 판단해야 한다. 그런데 AI는 틀릴 수 있다. 측정의 범위를 넓히려 할수록 AI에 의존하게 되고, 그만큼 환각의 위험도 커진다.
③ 사람 중심 vs 자동화의 한계 — 접근성을 중심에 두고 싶지만, 대체 텍스트의 '적절성'처럼 사람만 판단할 수 있는 영역이 분명히 있다. 자동화로 다 잡으려 하면 거짓 판정이 생기고, 사람에게 다 넘기면 사이트 전체를 못 본다.

이런 긴장 앞에서 우리가 택한 태도는 단순하다. 충돌을 숨기지 않는다. 어떤 원칙을 위해 다른 원칙을 어디까지 양보했는지를, 결과 안에서 가능한 한 드러낸다. 예를 들어 빠른 분석 모드에서는 근거 깊이를 줄였다는 사실을, 페이지 수를 제한했다면 무엇을 못 봤는지를 함께 알린다. 조용히 잘라내고 "다 봤다"고 말하지 않는 것 — 그것이 정직한 AI(원칙 ⑥)의 또 다른 얼굴이다.

이 6원칙은 완성된 계명이 아니라, 우리가 매일 다시 저울질하는 살아 있는 기준이다. 36편을 읽다 보면, 어느 편에서는 이 원칙이 저 원칙에 자리를 양보하는 장면도 보게 될 것이다. 그 양보의 이유까지 솔직하게 적는 것이, 이 시리즈가 '홍보'이면서도 'R&D 노트'이고자 하는 이유다.

우리가 "연구 중"이라고 말하는 이유

이 시리즈를 읽다 보면 곳곳에서 "이건 아직 어렵다", "이건 계속 연구 중이다"라는 문장을 만나게 될 것이다. 이건 겸손을 가장한 수사가 아니라 사실의 진술이다.

공공 웹 품질 진단은 정답이 깔끔하게 떨어지는 분야가 아니다. 기준(고시·KRDS)은 계속 개정되고 — 실제로 2024년에 이어 2025년에도 지침이 개정됐다 — 측정 방법(DOM·Vision·HTTP)은 영역마다 다르며, AI는 똑똑한 만큼 그럴듯하게 틀리기도 한다. 이런 영역에서 "우리 제품이 완벽한 정답"이라고 말하는 건 솔직하지 않을뿐더러 위험하다. 진단 결과를 맹신하게 만들기 때문이다.

그래서 우리는 ViewCheck를 '완성된 정답기'가 아니라 '점점 더 정확해지는 진단 동료'로 포지셔닝한다. N/A를 줄이는 일, 환각을 억제하는 일, 크롤링을 안정화하는 일, 정답셋을 쌓아 정확도를 올리는 일 — 전부 지금도 실험하고 있는 영역이다. 이 시리즈는 그 실험들을 한 편씩 풀어가는 기록이다.

그리고 솔직히, 우리가 이걸 만든 이유는 단순하다. 공공 웹의 품질을 더 정확하고 더 빠르게 진단할 방법이 분명히 있을 거라 믿었고, 말로만 그렇다고 하기보다 직접 연구해 만들어 보고 싶었다. 그 과정에서 쌓인 것을, 정답인 척하지 않고 있는 그대로 공개하는 것 — 그게 이 시리즈다.

마무리 — 그럼, 1편에서 만나요

정리하자. 0편에서 우리는 세 가지를 했다. 문제를 던졌고(사람이 사이트 전체를 다 점검할 수 없다), 정의를 못 박았으며(KRDS LLM 분석이란 근거를 갖춘 진단 동료다), 6개의 원칙을 세웠다(근거주의·기준 충실·사람 중심·실측 측정·전체를 본다·정직한 AI).

이 6원칙은 36편 내내 다시 등장할 것이다. 어떤 편을 읽든, "아, 이건 원칙 ①의 실천이구나", "이건 원칙 ⑤를 증명하려는 거구나" 하고 연결된다면, 이 시리즈는 제 역할을 한 셈이다.

다음 1편(입문편)에서는 이 정의가 실제로 어떻게 작동하는지를 본다. URL 한 줄을 채팅에 넣으면, 크롤링 → KRDS 846규칙 판정 → 24기능 결과 카드가 대화로 펼쳐지는 전체 흐름을 처음부터 끝까지 따라가 볼 것이다.

정답을 다 안다고 말하려는 게 아니다. 우리가 연구한 만큼을, 정직하게 펼쳐 보이려 한다. 그럼, 1편에서 만나요.

참고문헌

본문에 인용한 출처는 작성 시점에 모두 실재 여부를 검증했다.

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

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

해외 — 디자인 시스템 / UX 연구 / 표준

Nielsen Norman Group, "The 6 Types of Conversations with Generative AI", 2025. https://www.nngroup.com/articles/AI-conversation-types/
Nielsen Norman Group, 챗봇·대화형 인터페이스 UX 연구(conversational interfaces). https://www.nngroup.com/topic/conversational-interfaces/
GOV.UK Design System(공식). Government Digital Service. https://design-system.service.gov.uk/
W3C, "Web Content Accessibility Guidelines (WCAG) 2.2". https://www.w3.org/TR/WCAG22/

※ 본문 중 "846규칙"·디자인 토큰 수(색상 586/전체 768)는 KRDS 공식 문서가 명시한 숫자가 아니라 ViewCheck가 KRDS를 점검 가능한 규칙·토큰 단위로 구현·실측한 결과임을 밝힌다.