대화 한 줄로 끝내는 KRDS 진단 — ViewCheck LLM 분석 입문

URL 한 줄이 24개의 분석 카드로 펼쳐지기까지, 우리가 실험하고 있는 것들

들어가며 — "이 사이트, KRDS 기준에 맞나요?"라는 질문 앞에서

공공 웹사이트를 운영해 본 사람이라면, 어느 날 갑자기 책상 위로 떨어지는 이 한 줄짜리 질문을 안다.

"우리 사이트, KRDS 기준에 맞나요?"

질문은 짧지만 그 뒤에 따라오는 일은 길다. KRDS가 뭔지부터, 우리 사이트의 어떤 페이지를, 어떤 항목으로, 어떻게 점검해야 하는지, 점검을 했다면 그 결과가 맞다는 근거는 무엇인지 — 이 모든 게 한 줄짜리 질문 뒤에 숨어 있다. 그리고 대개 그 질문을 던지는 사람은 윗선이고, 답을 만들어야 하는 사람은 실무 담당자다.

우리는 이 한 줄짜리 질문에 대한 답을, 똑같이 한 줄로 시작할 수 없을까를 고민했다. 담당자가 복잡한 점검 도구를 깔고, 항목표를 펼치고, 화면을 하나하나 대조하는 대신, 그냥 채팅창에 사이트 주소 한 줄을 붙여 넣으면 그다음부터는 분석이 알아서 대화처럼 펼쳐지는 경험. 그것이 우리가 'ViewCheck LLM 분석'이라고 부르는 기능이다.

이 글은 그 기능의 첫 소개다. 다만 미리 분명히 해두고 싶은 게 있다. 우리는 "ViewCheck를 쓰면 모든 게 해결됩니다" 같은 이야기를 하려는 게 아니다. 공공 웹 품질이라는 주제는 그렇게 단순하게 끝낼 수 있는 영역이 아니고, 솔직히 우리도 아직 풀어가는 중인 문제가 훨씬 많다. 이 시리즈 전체의 톤은 "정답 제시"가 아니라 **"우리는 이렇게 연구하고 실험하고 있다"**에 가깝다. 이번 입문편에서는 그 실험의 전체 그림을, 가능한 한 솔직하게 그려보려 한다.

공공웹 담당자의 진짜 하루 — '점검'이라는 막막함

조금 더 현실적인 장면으로 들어가 보자. 가상의 담당자 한 명을 떠올려 본다. 어느 기초자치단체의 홈페이지 운영을 맡은 주무관. 그의 업무는 홈페이지 '운영'이지만, 실제로는 민원 응대, 게시판 관리, 외주 개발사 커뮤니케이션, 콘텐츠 업데이트, 그리고 가끔 위에서 내려오는 '점검'까지 전부 그의 몫이다.

어느 날 그에게 "디지털 정부 서비스 품질 점검 결과를 정리해 달라"는 요청이 온다. 그는 막막하다. 우선 무엇을 봐야 하는지부터 모호하다. 접근성? 그건 들어봤다. 그런데 호환성, 개방성, 접속성, 편의성, 효율성, 신뢰성 같은 단어들이 줄줄이 나오면 머리가 복잡해진다. KRDS라는 새로운 디자인 시스템 이야기도 어디선가 들었는데, 그게 우리 사이트랑 무슨 관계인지 감이 안 온다.

설령 점검 항목을 안다고 해도 그다음이 문제다. 우리 사이트에는 메인 페이지 하나만 있는 게 아니다. 검색 페이지, 신청 페이지, 게시판 목록, 상세 페이지, 로그인 화면, 정책 안내 페이지… 수십, 수백 개의 화면이 있다. 이걸 사람이 한 장 한 장 열어서, 항목표를 대조하며, "이 페이지는 통과, 저 페이지는 미통과"를 손으로 적는다? 한 페이지를 꼼꼼히 보는 데만 한참이 걸린다. 100페이지면? 생각만 해도 일주일이 사라진다.

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

그런데 바로 이 지점이 우리가 가장 오래 붙잡고 있는 문제다. 공공 웹의 품질은 메인 페이지 한 장으로 판정할 수 있는 게 아니다. 정작 시민이 불편을 겪는 곳은 신청서를 작성하는 화면, 검색 결과가 나오는 화면, 로그인하는 화면 같은 '깊은 곳'이다. 메인은 예쁘게 잘 만들어 두고 정작 신청 화면에서 접근성이 무너지는 사례를, 우리는 실제 분석 과정에서 셀 수 없이 많이 봤다. 그래서 ViewCheck는 처음부터 '다중 페이지 분석'을 기본값으로 설계했다. 한 장이 아니라 사이트 전체를 본다는 것 — 이게 우리가 양보하지 않는 첫 번째 원칙이다.

하지만 사이트 전체를 본다는 건 곧 '사람이 감당할 수 없는 양'을 본다는 뜻이기도 하다. 그래서 자동화가 필요하고, 그 자동화를 어떻게 신뢰할 수 있게 만들 것인가가 진짜 숙제가 된다. 이 글의 나머지는 그 숙제를 우리가 어떻게 접근하고 있는지에 대한 이야기다.

"전자정부 웹사이트 품질관리 지침"이라는 큰 그림 — 7대 영역

먼저 우리가 무엇을 기준으로 삼고 있는지부터 정리하자. 막연히 "좋은 사이트"를 만들자는 게 아니라, 대한민국에는 공식적인 기준이 있다.

행정안전부는 「전자정부 웹사이트 품질관리 지침」이라는 고시를 운영한다. 이 지침은 2025년 6월 25일 자로 행정안전부고시 제2025-46호로 일부 개정되어 시행 중이다(국가법령정보센터·행정안전부 고시). 흥미로운 점은, 이번 개정에서 품질진단 기준의 세부적·기술적 사항을 고시 본문(별표)에서 덜어내고, 구체적인 항목은 별도의 「품질관리 가이드」로 위임하는 방향을 택했다는 것이다. 다시 말해 큰 원칙은 고시로 묶되, 실제 점검의 디테일은 더 유연하게 업데이트할 수 있는 가이드로 옮긴 셈이다.

이 지침이 다루는 품질의 축은 크게 7대 영역으로 정리된다.

호환성 — 표준 HTML/CSS를 지키고, 주요 브라우저에서 동일하게 동작하는가
접근성 — 장애가 있는 사용자도 동등하게 이용할 수 있는가 (한국형 웹 콘텐츠 접근성 지침, KWCAG 계열)
개방성 — robots.txt, 메타데이터, 크롤링 허용 등 정보가 열려 있는가
접속성 — 언제든 끊김 없이, 빠른 응답으로 접속되는가
편의성 — 사용자가 편리하게 쓸 수 있는 기능을 제공하는가
효율성 — 페이지가 무겁지 않고 빠르게 로딩되는가
신뢰성 — SSL, 개인정보처리방침, 보안 헤더 등 믿고 쓸 수 있는가

이 7개를 가만히 들여다보면, 성격이 꽤 다르다는 걸 알 수 있다. 어떤 건 페이지의 HTML 구조를 뜯어보면 알 수 있고(호환성, 접근성 일부), 어떤 건 서버에 실제로 HTTP 요청을 보내봐야 알 수 있으며(접속성, 효율성, 신뢰성), 어떤 건 눈으로 화면을 봐야만 판단되는 영역(디자인의 시각적 일관성)이다.

그래서 우리는 이 7대 영역을 하나의 도구가 통째로 처리하려 하지 않았다. 영역마다 '실측이 가능한 방식'이 다르기 때문이다. 예를 들어 접속성·효율성·신뢰성은 브라우저가 직접 사이트에 접속해 응답 시간, SSL 인증서, 리소스 크기를 재야 한다. 이건 DOM(화면의 구조 데이터)만 들여다봐서는 절대 알 수 없다. 반대로 접근성의 상당 부분은 DOM의 구조와 속성을 분석하면 자동으로 판정할 수 있다. 같은 '품질'이라도 측정 도구가 다른 것이다. 이 분업 구조는 뒤에서 '3개의 엔진' 이야기를 할 때 다시 만나게 된다.

여기서 한 가지 더 짚고 싶은 건, 이 지침이 '한 번 만들고 끝'이 아니라 계속 개정된다는 사실이다. 2024년 고시가 있었고, 2025년에 또 개정됐다. 기준이 살아 움직이는 만큼, 그 기준을 따라가는 도구도 살아 움직여야 한다. 고정된 체크리스트를 한 번 박아 넣고 끝내는 방식으로는 결국 뒤처진다. 우리가 분석 로직을 코드와 데이터로 분리해 두고, 규칙을 데이터로 관리하는 이유도 여기에 있다.

KRDS라는 또 하나의 축 — 디자인 시스템의 등장

7대 품질 영역이 '웹사이트의 기술적 건강 상태'를 본다면, 최근 공공 웹에서 빠르게 떠오른 또 하나의 축이 있다. 바로 KRDS다.

KRDS는 'KoRea Design System'의 약자로, 행정안전부와 디지털플랫폼정부위원회가 배포한 범정부 UI/UX 디자인 시스템이다. 정부상징을 사용하는 중앙행정기관, 소속기관, 공공기관, 지방자치단체의 웹사이트와 모바일 웹·앱에 적용하는 것을 목표로 한다(KRDS 공식, krds.go.kr).

KDI 경제정보센터의 정책자료는 KRDS의 의의를 이렇게 정리한다. "누구나 쉽게 사용할 수 있는 공공 웹·앱 혁신"을 위한 토대라는 것이다(KDI 경제교육·정보센터, '범정부 UI/UX 디자인시스템(KRDS)으로부터'). 핵심은 '일관성'과 '접근성'이다. 부처마다, 지자체마다 제각각이던 공공 서비스의 화면을 하나의 결로 모으고, 그 과정에서 접근성을 기본값으로 끌어올리자는 시도다.

KRDS가 특별히 주목받은 이유 중 하나는, 과거의 '문서로 된 가이드라인'과 달리 웹사이트와 Figma 파일로 살아 있는 형태로 공개됐다는 점이다. 각 컴포넌트와 패턴 페이지 아래에 WCAG 적합성을 명시하는 등, 해외나 민간의 잘 만든 디자인 시스템에 견줘도 손색없는 수준으로 공개되어 업계에서도 회자됐다.

KRDS는 크게 원칙 → 스타일 → 컴포넌트 → 기본 패턴 → 서비스 패턴의 위계로 구성된다.

스타일(Style): 색상, 타이포그래피, 간격, 그리드 같은 시각의 기본 언어. 디자인 토큰으로 관리된다.
컴포넌트(Component): 버튼, 입력창, 탭, 모달, 카드처럼 화면을 이루는 부품.
기본 패턴(Basic Pattern): 폼 작성, 동의/확인, 오류 처리, 필터/정렬처럼 자주 반복되는 상호작용의 묶음.
서비스 패턴(Service Pattern): 검색, 로그인, 신청, 정책 안내처럼 서비스 단위의 흐름.

ViewCheck가 KRDS를 다룰 때, 우리는 이 위계를 그대로 점검 카테고리로 가져왔다. 디자인 스타일(DS), 컴포넌트(CP), 기본 패턴(BP), 서비스 패턴(SP). 이 네 글자는 이 시리즈 내내 계속 등장할 테니 지금 눈에 익혀두면 좋다.

참고로, 우리가 분석 과정에서 실측한 KRDS의 디자인 토큰 규모는 색상 토큰 약 586개, 전체 토큰 약 768개 수준이다. (인터넷에 떠도는 '1,082개' 같은 숫자와는 다르니, 이런 디테일도 실제 데이터로 확인하는 습관이 중요하다는 걸 우리 스스로 자주 되새긴다.) 숫자 하나를 정확히 맞추는 일이 사소해 보여도, 그게 결국 '추측이 아니라 실측'이라는 우리 작업 방식의 출발점이다.

그래서 ViewCheck는 "대화 한 줄"을 택했다

자, 점검해야 할 기준(7대 품질 + KRDS 846규칙)은 방대하고, 점검 대상(사이트 전체 페이지)은 사람이 감당할 수 없는 양이다. 그렇다면 이 일을 사용자에게 어떻게 '쉽게' 건넬 것인가?

전통적인 점검 도구의 모습을 떠올려 보자. 설치하고, 설정하고, 대상 URL을 등록하고, 점검 항목에 체크하고, 옵션을 고르고, 실행 버튼을 누르고, 한참 기다린 뒤, 표 형태의 결과를 받아 다시 해석한다. 이 과정 하나하나가 비전문가에게는 작은 장벽이다. 그리고 공공 웹 담당자의 다수는 개발자가 아니라 행정 실무자다.

우리가 택한 답은 대화형 인터페이스였다. 사용자는 채팅창에 사이트 주소 한 줄을 넣는다. 그게 전부다. 그다음부터는 크롤링이 돌고, 846규칙이 판정되고, 24개의 분석 결과가 마치 누군가 옆에서 설명해 주듯 카드 형태로 대화에 차곡차곡 펼쳐진다. 궁금한 게 있으면 다시 물어볼 수도 있다. "이 항목은 왜 미통과야?"라고 채팅으로 물으면, 근거를 들어 답한다.

물론 '대화 한 줄'이라는 표현은 사용자 경험의 표면이다. 그 한 줄 뒤에서 벌어지는 일은 결코 한 줄이 아니다. 오히려 그 복잡함을 전부 무대 뒤로 숨기고, 사용자 앞에는 가장 단순한 입력 하나만 남기는 것 — 그게 이 설계의 핵심이다. 복잡함을 없앤 게 아니라, 복잡함을 사용자가 보지 않아도 되는 곳으로 옮긴 것이다.

그런데 여기서 우리 스스로도 경계하는 지점이 있다. '대화형'이 만능은 아니라는 점이다. 다음 장에서 그 이야기를 해보자.

왜 하필 '대화형'인가 — 그리고 대화형의 함정

대화형 인터페이스가 무조건 좋다는 식의 이야기는 하고 싶지 않다. 사용성 연구의 고전적 기관인 닐슨 노먼 그룹(Nielsen Norman Group, 이하 NN/g)은 오히려 대화형 인터페이스의 한계를 꽤 냉정하게 지적해 왔다.

NN/g는 음성·화면 기반의 지능형 어시스턴트에 대해 이렇게 정리한 바 있다. 요지는 "이런 어시스턴트들은 답이 비교적 단순하고 짧은, 매우 제한된 질의에서만 잘 작동한다"는 것이다(Nielsen Norman Group, 챗봇·대화형 인터페이스 UX 연구). 사용자가 자기가 무엇을 원하는지 정확히 알고, 그걸 어떻게 물어야 하는지도 알 때 대화형은 효율적이지만, 그렇지 않으면 오히려 길을 잃기 쉽다는 것이다.

NN/g는 2023년 5~6월, 18명의 참가자가 ChatGPT 4.0·Bard·Bing Chat을 2주간 사용하며 기록한 총 425건의 대화를 분석한 일기 연구도 발표했다. 그 결과 생성형 AI와의 대화가 막연한 프롬프트부터 정밀한 질문까지 6가지 유형으로 나뉘며, 각 유형이 서로 다른 정보 요구를 가지므로 그에 맞는 서로 다른 인터페이스가 필요하다고 결론지었다(Nielsen Norman Group, "The 6 Types of Conversations with Generative AI", 2025).

이 연구가 우리에게 준 교훈은 분명하다. "채팅창 하나 던져두고 알아서 잘 물어보라"는 식의 설계는 위험하다는 것. 사용자가 무엇을 어떻게 물어야 할지 모르는 상태로 빈 채팅창 앞에 앉으면, 대화형은 오히려 막막함을 키운다.

그래서 ViewCheck의 '대화'는 자유 채팅을 표방하지만 실제로는 **강하게 안내된 대화(guided conversation)**에 가깝다. 사용자가 URL 한 줄만 넣어도, 시스템이 알아서 "이 사이트에서 어떤 페이지들을 볼지", "어떤 24가지 관점으로 분석할지"를 정해 카드로 펼쳐낸다. 즉, 사용자가 '무엇을 물어야 하는지'를 몰라도 되도록, 질문의 뼈대를 시스템이 먼저 깔아준다. 그 위에서 사용자는 자유롭게 추가 질문을 얹는다.

이건 NN/g가 말한 "대화 유형마다 다른 인터페이스가 필요하다"는 통찰을, 우리 방식으로 소화한 결과다. 막연한 첫 진입은 구조화된 카드로 받고, 정밀한 후속 질문은 자유 대화로 받는다. 한 화면 안에서 두 가지 대화 모드를 섞는 셈이다. 완성됐다고는 말 못 한다. 오히려 이 균형을 어떻게 잡을지가 우리가 지금도 계속 실험하는 영역이다. 다만 방향은 분명하다 — '대화형이라서 멋지다'가 아니라, '대화형의 함정을 알기에 안내를 설계한다'는 쪽이다.

URL 한 줄 → 무슨 일이 벌어지나 (전체 파이프라인 한눈에)

이제 그 '대화 한 줄' 뒤에서 실제로 무슨 일이 벌어지는지, 전체 흐름을 한눈에 그려보자. 크게 보면 세 단계다.

[1] URL 한 줄 입력
      ↓  크롤링 (Playwright)
      ·  사이트의 여러 페이지를 실제 브라우저로 방문
      ·  DOM(구조 데이터) + CSS + 스크린샷 + 성능/보안 신호 수집
      ↓
[2] KRDS 846규칙 판정
      ·  DS 120 · CP 446 · BP 108 · SP 172
      ·  통과 / 미통과 / 해당없음 판정 + 근거
      ↓
[3] 24개 분석 결과 카드가 '대화로' 펼쳐짐
      ·  종합총평 → 인사이트 → 카테고리별 상세 → … → AI 종합 리포트
      ·  궁금하면 다시 질문 (Q&A + RAG 근거 + KRDS 참조패널)

말로 풀면 이렇다. 사용자가 주소를 넣으면, 시스템은 진짜 브라우저(Playwright)를 띄워 그 사이트를 사람처럼 방문한다. 메인만 보는 게 아니라 여러 페이지를 돌며, 각 페이지의 DOM 구조, CSS, 스크린샷, 그리고 응답 시간·보안 헤더 같은 신호까지 함께 수집한다. 수집된 데이터는 846개의 KRDS 규칙으로 판정되고, 그 결과가 24개의 분석 관점으로 재구성되어 대화에 카드로 흘러나온다.

이 세 단계를 하나씩 조금 더 들여다보자. 각 단계마다, 우리가 어떤 점을 어렵게 여기고 어떻게 풀어가는지를 같이 적어보겠다. 입문편이니 깊이 파고들진 않되, 이 시리즈가 앞으로 어떤 주제들을 다룰지에 대한 예고편처럼 읽어도 좋다.

1단계: 크롤링 — 화면을 '있는 그대로' 수집한다

분석의 품질은 결국 수집의 품질에서 출발한다. 아무리 똑똑한 판정 로직이 있어도, 들어오는 데이터가 부실하면 결과도 부실하다. 그래서 우리는 수집 단계에 생각보다 많은 공을 들인다.

ViewCheck는 단순히 HTML 소스를 내려받는 게 아니라, 실제 브라우저(Playwright)로 페이지를 렌더링한다. 요즘 웹사이트는 자바스크립트로 화면을 그리는 경우가 많아서, 소스만 받아서는 사용자가 실제로 보는 화면과 전혀 다른 걸 보게 된다. 진짜 브라우저로 띄워야 "사용자가 마주하는 그 화면"의 구조를 얻을 수 있다.

수집하는 데이터는 대략 이렇다.

DOM 전체 구조: 어떤 요소가, 어떤 속성(특히 접근성에 중요한 ARIA 속성)을 갖고, 어떻게 배치되어 있는지.
CSS와 디자인 토큰: 실제 적용된 색상·폰트·간격 값. KRDS 토큰과 비교하기 위해 필요하다.
스크린샷: 눈으로 봐야만 판단되는 시각적 영역을 위한 이미지.
성능·보안 신호: 응답 시간(TTFB), 핵심 웹 지표(LCP·CLS 등), SSL 인증서, 보안 헤더처럼 HTTP 요청을 직접 해봐야 알 수 있는 값들.

그리고 앞서 강조한 대로, 이걸 한 페이지가 아니라 여러 페이지에 걸쳐 한다. 검색 페이지, 신청 페이지, 목록, 상세, 로그인… 페이지 유형마다 KRDS의 어떤 규칙이 적용되는지가 다르기 때문에, 다양한 유형의 페이지를 골고루 수집하는 것이 중요하다. 로그인 화면에서만 의미 있는 규칙을, 메인 페이지만 보고 "해당없음"으로 처리해 버리면 그건 점검을 안 한 것이나 마찬가지다.

물론 크롤링은 만만한 작업이 아니다. 사이트마다 구조가 다르고, 어떤 페이지는 느리고, 어떤 페이지는 봇을 막고, 메모리는 한정되어 있다. 수백 페이지를 안정적으로 도는 일은 그 자체로 하나의 엔지니어링 과제다. 이 시리즈의 뒤쪽 트랙(플랫폼·R&D)에서, 크롤링 인프라를 어떻게 안정화하는지를 따로 다룰 예정이다. 지금은 "수집은 생각보다 어렵고, 그래서 중요하다" 정도만 기억해 두자.

2단계: KRDS 846규칙 판정 — DS·CP·BP·SP

수집이 끝나면, 본격적인 판정이 시작된다. ViewCheck의 심장부라고 할 수 있는 부분이다.

KRDS의 위계(스타일·컴포넌트·기본 패턴·서비스 패턴)를 점검 가능한 형태로 풀어내면, 우리 기준으로 846개의 규칙이 된다. 분포는 이렇다.

카테고리	약자	규칙 수	주로 보는 것
디자인 스타일	DS	120	색상·타이포·간격·레이아웃의 수치적 준수
컴포넌트	CP	446	요소의 존재 + ARIA 속성 + 구조 검증
기본 패턴	BP	108	폼 구조, 동의/확인, 오류 처리, 필터/정렬
서비스 패턴	SP	172	검색·로그인·신청·정책 같은 서비스 흐름
합계		846

각 규칙은 페이지 데이터를 받아 통과 / 미통과 / 해당없음 중 하나로 판정된다. 예를 들어 "버튼에 적절한 라벨이 있는가", "색상 대비가 기준을 충족하는가", "폼에 오류 안내가 제공되는가" 같은 식이다. 그리고 각 판정에는 가능한 한 '근거'를 붙이려 한다. 단순히 "미통과"가 아니라 "이 요소가, 이 규칙의 이 조건을 충족하지 못해서 미통과"라고 말할 수 있어야, 담당자가 실제로 고칠 수 있기 때문이다.

ViewCheck LLM 분석이 완료되어 KRDS 846규칙 판정 결과가 화면에 정리되어 표시된 실제 프로덕션 캡처. — 실제 ViewCheck LLM 분석 완료 화면. URL 한 줄로 시작한 분석이 끝나면, 846규칙 판정 결과가 카테고리별로 정리되어 나타난다. (서울시 메인 페이지 분석 예시) — 실제 분석 화면

여기서 솔직하게 짚을 게 하나 있다. 846개 규칙을 전부 자동으로, 모든 페이지에서, 항상 명확하게 판정할 수 있느냐 하면 — 아니다. 어떤 규칙은 DOM 구조만으로 명확히 판정되지만, 어떤 규칙은 "이건 사람이 눈으로 봐야 알 수 있는데?" 싶은 시각적 영역이고, 또 어떤 규칙은 사용자가 실제로 버튼을 눌러봐야(런타임 상호작용) 알 수 있다.

그래서 '해당없음(N/A)'으로 빠지는 규칙을 어떻게 줄일 것인가가 우리의 큰 숙제 중 하나다. 컴포넌트가 그 페이지에 없어서 정당하게 N/A인 경우도 있지만, 분석이 그 컴포넌트를 '못 본' 것뿐인데 N/A로 처리되면 그건 결함이다. 이 'N/A를 줄이는 연구'는 이 시리즈의 트랙 A에서 한 편을 통째로 할애해 다룰 만큼 중요한 주제다. 지금은, "846규칙 판정은 ViewCheck의 핵심이지만, 그 판정을 더 정확하게 만드는 일 자체가 끝없는 연구 대상"이라는 점을 기억해 두자.

3단계: 24개의 결과 카드가 '대화로' 펼쳐진다

판정이 끝나면, 결과를 어떻게 사용자에게 보여줄 것인가의 문제가 남는다. 846개의 통과/미통과 목록을 그대로 던져주면 누구도 읽지 않는다. 그래서 우리는 이 방대한 결과를 **24개의 분석 관점(기능)**으로 재구성한다.

24개 카드는 대략 이런 것들이다.

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

이 24개가 채팅에 '카드'로 하나씩 흘러나온다. 위에서부터 큰 그림(종합총평, 인사이트)을 먼저 보여주고, 아래로 내려갈수록 세부(카테고리별 상세, 오류 리스트, 개선 로드맵)로 들어간다. 사용자는 스크롤만 내려도 "내 사이트가 전체적으로 어떤 상태이고, 구체적으로 무엇이 문제이며, 무엇부터 고치면 되는지"를 한 줄기의 대화처럼 따라 읽게 된다.

왜 하필 '카드'이고 '대화'일까. 표 하나에 모든 걸 욱여넣는 대신, 관점별로 카드를 쪼개면 사용자가 자기에게 필요한 것에 집중할 수 있다. 디자이너는 디자인 스타일 카드를, 개발자는 오류 리스트와 접근성 카드를, 보고서를 써야 하는 담당자는 임원보고서와 종합총평 카드를 먼저 본다. 같은 분석 결과라도 보는 사람에 따라 필요한 '입구'가 다르기 때문이다.

그리고 카드는 끝이 아니라 시작이기도 하다. 어떤 카드가 "이 부분이 미통과"라고 말하면, 사용자는 바로 그 자리에서 "왜?"라고 되물을 수 있다. 그러면 다음 이야기, RAG와 근거의 영역으로 넘어간다.

"정답"이 아니라 "근거" — RAG와 참조패널

AI가 무언가를 판정할 때 가장 위험한 건 그럴듯하게 틀리는 것이다. "이 사이트는 이 규칙을 위반했습니다"라고 자신 있게 말했는데, 그 근거를 물으면 얼버무리거나, 심지어 존재하지 않는 규칙을 지어낸다면(이른바 환각, hallucination), 그 도구는 신뢰할 수 없다. 공공 영역에서는 더더욱 그렇다.

그래서 우리는 처음부터 "AI가 그렇대"가 아니라 **"846규칙 원문과 KRDS 공식 문서에 근거해서 그렇다"**를 보여주는 방향으로 갔다. 이걸 가능하게 하는 게 RAG(Retrieval-Augmented Generation, 검색 증강 생성)라는 접근이다.

쉽게 말하면 이렇다. AI에게 "알아서 판단해"라고 맡기는 대신, 판단에 필요한 근거 문서(규칙 원문, KRDS 공식 가이드, 공식 컴포넌트 스펙 등)를 먼저 '찾아서' AI 앞에 펼쳐주고, "이 근거를 보고 판단하고, 그 근거를 함께 제시해"라고 요구하는 것이다. 그러면 AI의 답에는 출처가 따라붙는다. 사용자는 결과 옆의 참조패널에서 "이 판정이 어떤 규칙·어떤 문서에 기반한 것인지"를 직접 확인할 수 있다.

이 'LLM을 판정에 쓰되, 환각을 어떻게 억제할 것인가'는 사실 이 시리즈 전체를 관통하는 가장 큰 주제다. 트랙 A의 다음 편들에서 'LLM을 평가자(judge)로 쓴다는 실험', 'RAG로 근거를 대는 컴플라이언스', '환각 방지' 같은 제목으로 더 깊이 다룰 예정이다. 입문편에서 강조하고 싶은 한 가지는 이것이다 — 우리는 AI가 똑똑하다고 믿지 않는다. 다만 근거를 댈 수 있게 강제할 뿐이다. 그 차이가, 장난감과 도구를 가른다고 생각한다.

이 대목에서 우리 팀이 스스로에게 거는 규칙이 하나 있다. "추측으로 결론 내지 말고, 실제 데이터로 검증하라." 이건 제품의 동작 원리이기도 하지만, 그걸 만드는 우리 자신의 작업 원칙이기도 하다. 코드 경로만 보고 "문제없다"고 결론 내리지 않고, 실제 프로덕션에서 돌려보고 응답을 눈으로 확인한 뒤에야 "된다"고 말한다. 제품이 사용자에게 약속하는 것을, 만드는 사람부터 지키려는 것이다.

무대 뒤의 3개 엔진 — 분업으로 푸는 문제

지금까지의 이야기를 하나의 구조로 정리하면, ViewCheck는 사실 3개의 엔진이 분업하는 시스템이다. 입문편이니 아주 가볍게만 소개한다.

ViewCheck (수집·통합 엔진): 사용자 접점. URL을 받아 크롤링하고, 여러 분석 결과를 모아 24개 카드로 통합해 대화로 펼친다. 7대 품질 중 HTTP 요청이 필요한 영역(개방성·접속성·효율성·신뢰성)도 여기서 직접 측정한다.
KRDSrule 엔진 (DOM 기반 846규칙 판정): 수집된 DOM 데이터를 받아, 846개 규칙을 if/else 로직으로 판정한다. ARIA 속성, CSS 값, 구조처럼 'DOM만 봐도 알 수 있는' 영역을 빠르고 정확하게 담당한다. 보통 수 초 안에 끝난다.
KRDScan 엔진 (Vision AI·RAG): DOM으로는 절대 알 수 없는 영역을 맡는다. 이미지나 비표준 방식으로 구현된 UI를 시각적으로 감지하고(Vision AI), 규칙 원문·공식 문서를 검색해 판정의 근거를 대는 RAG 지식베이스를 운영한다.

왜 굳이 셋으로 나눴을까. 앞서 7대 품질을 이야기할 때 짚었듯, '품질'은 측정 방식이 제각각이기 때문이다. DOM으로 알 수 있는 건 DOM 엔진이 빠르게, 눈으로 봐야 아는 건 Vision 엔진이, HTTP로 재야 하는 건 수집 엔진이 맡는다. 하나의 거대한 만능 모델로 전부 처리하려는 시도는 대개 '모든 걸 어설프게 하는' 결과로 끝난다. 우리는 그 반대로, 각 영역에서 가장 적합한 방법을 쓰는 분업을 택했다.

중요한 건 이 셋 사이의 '충돌 방지' 원칙이다. DOM이 명확히 통과/미통과로 판정한 건, Vision AI가 함부로 뒤집지 않는다. AI는 DOM이 '해당없음'으로 남겨둔 빈칸과, DOM이 못 보는 시각적 영역만 독자적으로 채운다. 누가 무엇을 책임지는지를 분명히 해야, 결과가 흔들리지 않는다. 이 아키텍처의 자세한 이야기 역시 트랙 F에서 따로 풀 예정이다.

해외 디자인 시스템과의 대화 — GOV.UK·USWDS

KRDS가 갑자기 하늘에서 떨어진 건 아니다. 공공 디지털 서비스의 디자인 시스템이라는 흐름에는 앞서간 사례들이 있다. 영국의 GOV.UK Design System이 대표적이다.

영국 정부디지털서비스(GDS)는 2018년 GOV.UK Design System을 공식 도입하며, 흩어져 있던 정부 서비스의 화면을 재사용 가능한 컴포넌트와 패턴으로 통합했다(GDS Blog, "Introducing the GOV.UK Design System", 2018). 이 시스템의 핵심 가치는 KRDS와 똑같다 — 일관성과 접근성이다. GOV.UK Design System은 "정부 서비스를 GOV.UK와 일관되게 만들기 위한" 토대로 설명되며, 모든 컴포넌트와 패턴이 가장 널리 쓰이는 보조기술로 검증되고 WCAG의 AA 수준을 충족하도록 만들어졌다(GOV.UK Design System 공식). 수백 개의 서비스가 이 시스템을 따르며, 중앙 디자인 시스템에 접근성을 내장함으로써 그 수백 개 서비스의 '기본 접근성'을 한꺼번에 끌어올린다는 점을 GDS는 강조한다.

미국에도 USWDS(U.S. Web Design System)라는 유사한 시스템이 있다. 이렇게 보면 KRDS는 '한국판 정부 디자인 시스템'으로, 글로벌한 공공 디자인 시스템 흐름의 한 줄기에 서 있는 셈이다.

ViewCheck를 만들며 우리는 이런 해외 사례를 자주 들여다본다. KRDS를 점검하는 도구가 KRDS만 알아서는 안 되기 때문이다. "GOV.UK는 이 컴포넌트를 어떻게 정의했나", "USWDS는 접근성을 어떤 수준으로 요구하나" 같은 비교는, 우리가 KRDS 규칙을 더 깊이 이해하는 데 도움을 준다. 이 시리즈의 트랙 B에서는 'KRDS vs GOV.UK·USWDS'를 직접 비교하는 편을 따로 마련해 두었다. 남의 것을 베끼자는 게 아니라, 잘 만든 기준끼리 대화시켜 보면 우리 기준의 강점과 빈틈이 더 잘 보인다는 믿음 때문이다.

우리가 "연구 중"이라고 말하는 이유 — R&D 톤에 대하여

여기까지 읽었다면 눈치챘겠지만, 이 글은 "ViewCheck가 다 해결했습니다"라고 말하지 않는다. 오히려 곳곳에서 "이건 아직 어렵다", "이건 계속 연구 중이다"라고 적었다. 이게 의도된 톤이다.

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

그래서 우리는 ViewCheck를 '완성된 정답기'가 아니라 **'점점 더 정확해지는 진단 동료'**로 포지셔닝한다. 담당자가 사이트 전체를 혼자 다 볼 수 없을 때, 옆에서 빠르게 훑어주고, 근거를 대주고, 무엇부터 보면 좋을지 짚어주는 동료. 그 동료가 가끔 틀릴 수 있다는 걸 인정하고, 그래서 근거를 항상 함께 보여주며, 사용자가 최종 판단을 할 수 있게 돕는 것 — 그게 우리가 생각하는 건강한 AI 진단의 모습이다.

이 시리즈가 '홍보'이면서도 'R&D 노트'의 형식을 띠는 이유가 여기에 있다. 우리는 우리가 무엇을 잘하는지뿐 아니라, 무엇을 어렵게 여기고 어떻게 풀어가는지를 함께 공개하려 한다. 그게 더 정직하고, 길게 보면 더 신뢰받는 길이라고 믿기 때문이다. 매 편마다 "이건 이렇게 접근하고 있다"까지만 말하고, "그러니 당장 사세요" 같은 말은 하지 않으려는 것도 같은 맥락이다.

담당자 관점에서 다시 보기 — 하나의 시나리오

추상적인 이야기를 마지막으로 한 번 더 구체화해 보자. 앞서 등장한 가상의 주무관에게 다시 돌아간다.

그는 "사이트 품질 점검 결과를 정리해 달라"는 요청을 받았다. 예전 같으면 막막했을 일이다. 그런데 이번에는 ViewCheck의 채팅창에 사이트 주소 한 줄을 붙여 넣는다. 그리고 잠시 다른 일을 한다. 그사이 시스템은 메인뿐 아니라 검색·신청·목록·상세 같은 여러 페이지를 돌며 데이터를 모으고, 846규칙으로 판정하고, 24개 카드를 준비한다.

돌아온 그는 채팅을 스크롤한다. 맨 위 종합총평 카드가 사이트의 전반적 상태를 한 문단으로 요약해 준다. 그 아래 인사이트 카드는 "특히 이 부분이 반복적으로 문제"라고 짚어준다. 더 내려가면 접근성 카드가 KWCAG 관점의 미통과 항목을, 오류 리스트 카드가 페이지별 구체적 문제를, 개선 로드맵 카드가 "무엇부터 고치면 좋은지"를 우선순위로 보여준다. 보고서에 바로 옮길 수 있는 임원보고서 카드도 있다.

궁금한 게 생긴다. "이 항목은 왜 미통과지?" 그는 채팅으로 그냥 묻는다. 답이 온다 — 근거가 된 규칙과 공식 문서가 참조패널에 함께 뜬다. 그는 그 근거를 외주 개발사에 그대로 전달한다. "이 규칙, 이 페이지에서 이렇게 고쳐주세요." 모호한 지시가 아니라, 출처가 붙은 구체적 요청이 된다.

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

마무리 — 입문에서 다음 편으로

정리하자. ViewCheck LLM 분석은 "URL 한 줄을 채팅에 넣으면, 크롤링 → KRDS 846규칙 판정 → 24개 분석 카드가 대화로 펼쳐지는" 흐름이다. 그 표면은 '대화 한 줄'처럼 단순하지만, 그 뒤에는 다중 페이지 수집, 846규칙 판정, RAG 근거 제시, 3개 엔진의 분업이라는 꽤 복잡한 구조가 숨어 있다.

그리고 우리는 이 구조의 어느 부분도 "완성됐다"고 말하지 않았다. 대화형의 함정, N/A를 줄이는 일, 환각을 억제하는 일, 크롤링을 안정화하는 일 — 전부 지금도 실험하고 있는 영역이다. 이 시리즈는 그 실험들을 한 편씩 풀어가는 기록이 될 것이다.

다음 편(2편)에서는 그중에서도 가장 흥미롭고 논쟁적인 주제로 들어간다. "LLM을 평가자(judge)로 쓴다는 실험" — 사람 대신 AI가 품질을 판정하게 한다는 것이 무슨 의미이고, 그게 왜 위험하며, ViewCheck는 DOM 규칙으로 그 위험을 어떻게 억제하는지를 다룰 예정이다.

공공 웹의 품질을 한 줄의 대화로 묻고, 근거 있는 답을 받는 일. 우리는 그게 가능하다고 믿고, 그 가능성을 매일 조금씩 실측으로 늘려가고 있다. 다음 편에서 이어가겠다.

참고문헌

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

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

행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제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
KRDS(범정부 UI/UX 디자인시스템) 공식 사이트 — 디지털 정부서비스 UI/UX 가이드라인. 행정안전부·디지털플랫폼정부위원회. https://www.krds.go.kr/
KDI 경제교육·정보센터, "누구나 쉽게 사용할 수 있는 공공 웹·앱 혁신, '범정부 UI/UX 디자인시스템(KRDS)'으로부터". https://eiec.kdi.re.kr/policy/materialView.do?num=262364

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

Government Digital Service(GDS), "Introducing the GOV.UK Design System", GDS Blog, 2018. https://gds.blog.gov.uk/2018/06/22/introducing-the-gov-uk-design-system/
GOV.UK Design System(공식). Government Digital Service. https://design-system.service.gov.uk/
Nielsen Norman Group, "The 6 Types of Conversations with Generative AI", 2025. (18명 참가자가 ChatGPT 4.0·Bard·Bing Chat을 2주간 사용한 일기 연구, 총 425건 대화 분석.) https://www.nngroup.com/articles/AI-conversation-types/
Nielsen Norman Group, "Prompt Structure in Conversations with Generative AI". https://www.nngroup.com/articles/ai-prompt-structure/

※ 본문 중 닐슨 노먼 그룹의 "지능형 어시스턴트는 답이 단순하고 짧은 제한된 질의에서만 잘 작동한다"는 취지의 서술은 NN/g의 챗봇·대화형 인터페이스 UX 연구 일반에 근거한 요약이다. 정확한 원문 표현은 위 NN/g 자료 및 관련 아티클(nngroup.com)에서 확인할 수 있다.