체크리스트 말고 대화로 — 공공웹 점검 패러다임이 달라지는 순간

수십 년을 버텨온 체크리스트 방식과, 대화형 LLM 분석이 처음으로 나란히 놓인 날

들어가며 — 익숙한 표를 앞에 두고 멈칫한 순간

기억이 하나 있다. 공공 웹사이트 담당 실무자가 보내온 엑셀 파일이었다. 열 수십 개, 행 수백 개. 맨 위 행에는 "접근성 점검 체크리스트"라고 적혀 있었고, 각 행에는 점검 항목이, 각 열에는 페이지 이름이 빼곡히 들어차 있었다. 어떤 칸에는 "O", 어떤 칸에는 "X", 어떤 칸에는 그냥 공백. 공백이 의미하는 게 '미검토'인지 '해당 없음'인지는 아무도 알 수 없었다.

담당자는 그 파일을 매 반기마다 업데이트해왔다고 했다. 손으로, 직접. 사이트 화면을 열어두고, 체크리스트를 옆에 펼쳐두고, 하나씩 눈으로 확인하며 칸을 채워가는 방식. 그 과정이 얼마나 걸리느냐고 물었더니, "잘 되면 2~3일, 급하면 반나절에 끝내야 할 때도 있다"고 했다. 반나절에 끝내는 방법은 간단하다 — 일부 항목을 건너뛰거나, 메인 페이지 하나만 확인하고 전체 결과인 것처럼 채운다.

이 이야기가 특이한 경우가 아니다. 오히려 공공 웹 점검 현장의 전형적인 모습에 가깝다. 체크리스트는 오랫동안 품질 점검의 표준 도구였다. 이유는 분명하다 — 단순하고, 명확하고, 누구나 이해할 수 있다. 각 항목을 충족하면 O, 충족 못 하면 X. 보고서 제출도 쉽다. 이 단순함이 체크리스트가 수십 년을 살아남은 힘이다.

그런데 지금, 그 익숙한 방식에 변화가 일고 있다. 점검 도구가 "표를 채우는 것"에서 "대화를 나누는 것"으로 이동하고 있다. ViewCheck LLM 분석이 그 변화의 한 실험적 사례다. 이 글은 두 방식을 나란히 놓고, 사용자 관점에서 무엇이 어떻게 다른지를 솔직하게 들여다보는 시도다.

"체크리스트는 나쁘고 대화형이 좋다"는 단순한 결론을 내리려는 게 아니다. 두 방식은 각자의 강점과 한계가 있고, 아직 대화형 LLM 분석이 체크리스트를 완전히 대체할 수 있다고 주장하기도 이르다. 다만 "점검이란 무엇인가"에 대한 생각이 어떻게 달라질 수 있는지, 그 가능성을 같이 살펴보고 싶다.

30대 한국인 여성 공무원이 인쇄된 체크리스트 용지와 포스트잇으로 가득 찬 책상 앞에 앉아 지쳐 보이는 모습. — 수십 페이지의 체크리스트를 손으로 채워가는 것, 이것이 공공 웹 점검 현장의 오랜 일상이었다.

체크리스트라는 도구 — 그것이 잘하는 것과 못하는 것

체크리스트가 왜 존재하는지부터 이해하는 게 중요하다. 아무 이유 없이 수십 년을 살아남은 도구는 없다.

체크리스트의 강점은 명료함이다. 항목이 고정되어 있어서, 누가 점검하든 비슷한 결과를 기대할 수 있다. "아는 만큼만 본다"는 개인 편차를 어느 정도 통제해 준다. 또 보고서화가 쉽다. O/X로 정리된 표는 그 자체로 이미 보고서 형식에 가깝다. 관리자, 감사자, 발주처 모두 이 형식을 이해한다. 그래서 체크리스트는 지금도 규정 준수(compliance) 영역에서 가장 강력한 도구 중 하나다.

그러나 체크리스트에는 구조적 한계가 있다.

첫 번째 한계: 항목이 고정되어 있다. 세상이 바뀌면 체크리스트도 바뀌어야 한다. 행안부 「전자정부 웹사이트 품질관리 지침」만 해도 2024년에 고시(제2024-25호)가 있었고, 2025년 6월에 또 개정(제2025-46호)됐다. 기준이 바뀌면 체크리스트를 다시 만들어야 하는데, 그 업데이트가 현장까지 내려오는 데는 시간이 걸린다. 담당자가 갖고 있는 체크리스트가 최신 기준을 반영하는지 항상 확신할 수 없다.

두 번째 한계: 맥락을 잃어버린다. 체크리스트는 항목별로 독립적이다. "이미지에 alt 텍스트가 있는가 — O"라고 채웠더라도, 그 alt 텍스트가 의미 있는 내용인지, "이미지"라고만 적혀 있는 건 아닌지는 체크리스트가 알려주지 않는다. 항목을 충족했지만 실제로는 접근성이 나쁜 상황, 즉 '형식적 통과'가 가능한 게 체크리스트의 그림자다. 닐슨 노먼 그룹(Nielsen Norman Group)이 접근성 연구에서 지속적으로 강조해 온 지점이 여기에 있다 — 자동화 체크와 휴리스틱 체크는 모두 "구조적 준수"를 확인하지만, 실제 보조기기 사용자의 경험을 대리하지는 못한다(Nielsen Norman Group, How to Conduct Usability Studies for Accessibility).

세 번째 한계: 스케일 문제다. 공공 웹사이트는 보통 수십에서 수백 개의 페이지로 이루어진다. 메인 페이지, 검색 페이지, 신청 페이지, 게시판, 로그인, 정책 안내 … 이 모든 페이지에 대해 체크리스트를 손으로 채운다는 건 현실적으로 불가능에 가깝다. 웹접근성 인증기관의 점검 일정이 "신청서 접수 후 약 3주"가 걸리는 이유도 이 스케일 문제와 무관하지 않다. 결국 많은 담당자가 "일부 페이지만" 보거나, "메인 페이지 대표 점검"이라는 현실적 타협을 하게 된다.

네 번째 한계: 정보를 소비하는 방식이 다르다. 체크리스트는 O/X를 채우는 사람 기준으로 설계되어 있다. 결과를 읽는 사람—보고서를 받는 팀장, 개선 작업을 해야 하는 개발자, 예산을 짜야 하는 관리자—에게 체크리스트가 건네주는 정보는 단편적이다. "이 항목이 X"라는 사실은 알 수 있지만, "왜 X인지", "고치려면 무엇을 어떻게 해야 하는지", "이게 얼마나 중요한지"는 체크리스트에 없다. 그 해석과 연결은 사람이 따로 해야 한다.

이 한계들은 체크리스트를 '나쁜 도구'로 만드는 게 아니다. 오히려 "체크리스트가 잘 작동하는 환경"과 "체크리스트가 구조적으로 부족한 환경"을 분리해서 볼 필요가 있다는 뜻이다. 그리고 현대 공공 웹 점검의 환경은 — 기준이 자주 바뀌고, 페이지 수는 수백 개이고, 결과를 읽는 사람이 여럿이고, 개선으로 이어지는 연결이 필요한 환경은 — 점점 체크리스트만으로 버티기 어려운 방향으로 가고 있다.

자동화는 이미 와 있었다 — 하지만 그것만으로는 충분하지 않다

체크리스트의 스케일 문제를 해결하기 위한 첫 번째 시도는 '자동화'였다. 사람이 손으로 하던 확인을 코드로 대체하는 것이다.

axe-core(Deque Systems), WAVE, Lighthouse 같은 자동화 접근성 검사 도구들이 그 결과물이다. 이 도구들은 실제로 놀랍도록 유용하다. 2021년 Deque Systems가 2,000건 이상의 실제 감사 데이터를 분석한 연구에 따르면, axe 기반 자동화 테스팅은 접근성 문제의 약 57%를 감지할 수 있다고 보고했다. 기존에 업계에서 통용되던 "자동화는 20~30% 수준"이라는 인식을 크게 넘어서는 수치다(Deque Systems, "Automated Testing Identifies 57% of Digital Accessibility Issues", 2021). 이 수치가 가능한 이유 중 하나는 색상 대비, 언어 속성, 이름/역할/값 같은 '실제 빈도가 높은 오류' 유형이 자동화로 잘 잡히기 때문이다.

그런데 GOV.UK Design System 팀은 다른 각도에서 이 문제를 바라봤다. "자동화 도구가 WCAG 성공 기준 중 몇 퍼센트를 커버하는가"를 따지면, 그 비율은 약 30% 수준에 그친다는 것이다(GOV.UK, "Testing for accessibility"). 57%와 30%가 동시에 맞는 말인 이유는 측정 방식이 다르기 때문이다 — 하나는 '실제로 발생하는 오류의 볼륨 기준', 다른 하나는 '성공 기준 항목 수 기준'. 어느 숫자를 보느냐에 따라 자동화의 '충분함'에 대한 결론이 달라진다.

여기서 중요한 건, 자동화가 못 하는 것이 무엇인가를 이해하는 것이다. 자동화 도구는 구조적 문제는 잘 찾는다. HTML 속성이 있는지 없는지, 색상 대비가 수치 기준을 충족하는지, 이미지에 alt가 있는지 없는지. 그런데 그 alt 텍스트가 의미 있는 내용인지, 화면 흐름이 실제 사용자에게 자연스러운지, 버튼을 실제로 눌렀을 때 예상한 대로 동작하는지 — 이런 '맥락과 경험'의 영역은 자동화가 닿지 못한다.

WCAG 2.2 기준으로 보면, 성공 기준의 약 60%는 수동 테스트가 필요한 영역이다(Level Access, "Automated Accessibility Testing: A Practical Guide to WCAG Coverage"). 특히 Operable(조작 가능한)과 Robust(견고한) 원칙의 많은 항목은 실제로 키보드와 스크린 리더로 탐색해보지 않으면 검증할 수 없다. 자동화는 필요하지만, 그것만으로는 절반도 안 된다는 뜻이다.

그렇다면 자동화 이후의 다음 단계는 무엇일까. "자동화 + 수동 체크리스트"의 조합이 현재의 모범 사례(best practice)로 권장되고 있다. 자동화로 빠르게 구조적 오류를 잡고, 수동으로 맥락적 판단이 필요한 영역을 보완하는 방식이다. 그런데 이 조합도 한 가지 근본적인 문제를 해결하지는 못한다 — 결과를 어떻게 이해하고 활용할 것인가의 문제다. 도구가 "이게 문제"라고 알려줘도, 그게 왜 문제인지, 얼마나 심각한지, 어떻게 고치는지는 여전히 사람이 해석해야 한다.

ViewCheck LLM 분석은 바로 이 지점에서 출발했다. 자동화로 데이터를 수집하고, 규칙으로 판정하는 것을 넘어 — 그 결과를 '대화'로 건네는 것. 단순히 "이게 문제"가 아니라 "왜 문제이고, 얼마나 중요하고, 어떻게 고치면 되는지"까지 이어지는 맥락을 함께 전달하는 것.

대화형으로 바뀐다는 것 — 경험이 어떻게 달라지나

이론적인 이야기는 여기까지 하고, 실제 사용 경험으로 들어가 보자. 체크리스트 방식과 대화형 방식은 사용자 입장에서 구체적으로 어떻게 다른가.

체크리스트 방식의 하루를 따라가 보면 이렇다.

아침에 접속 → 점검 도구 실행 → 결과 파일 내려받기 → 결과 파일을 체크리스트 양식에 붙여 넣기 → 해석 → 보고서 작성 → 각 항목별 담당자에게 공유 → 개발팀에 수정 요청 → 수정 후 재점검 → 다시 처음으로.

이 흐름에서 정작 "분석"에 해당하는 단계는 어디인가. "결과 파일을 해석하는 것"인데, 이 부분이 가장 불명확하다. 자동화 도구가 내뱉은 오류 코드가 무슨 의미인지, 어떤 WCAG 기준에 해당하는지, 이 오류가 이 사이트에서 얼마나 중요한지 — 이 해석의 과정이 담당자 개개인의 역량에 달려 있다. 접근성을 깊이 아는 담당자라면 이 해석이 빠르지만, 처음 이 일을 맡은 담당자라면 오류 코드 하나를 이해하는 데만 한 시간이 걸릴 수 있다.

ViewCheck LLM 분석의 하루를 따라가면 이렇게 달라진다.

채팅창에 사이트 주소 한 줄 입력 → 기다리는 동안 다른 일 처리 → 돌아와서 대화 스크롤 → 맨 위 종합총평 카드가 전체 상태를 한 문단으로 설명 → 인사이트 카드가 "이 부분이 반복 문제"를 짚어줌 → 카테고리별 상세 카드 → 오류 리스트 → 개선 로드맵 → 궁금하면 "이 항목은 왜 미통과야?"라고 채팅으로 질문 → 근거가 딸린 답이 옴.

차이를 한 줄로 정리하면 이렇다. 체크리스트는 "무엇이 문제인가"를 나열하고, 대화형 분석은 "무엇이 왜 문제이고, 어떻게 이어지는지"를 설명한다.

이 차이가 실무에서 의미하는 바는 크다. 체크리스트의 결과를 개발팀에 전달할 때, 담당자는 "이 항목이 X입니다"라고 전한다. 개발팀은 그게 무슨 뜻인지 다시 조사해야 할 수 있다. 반면 LLM 분석의 결과는 "이 요소가 이 규칙의 이 조건을 충족하지 못했고, 이렇게 수정하면 됩니다"라는 형태로 전달된다. 개발팀이 추가 조사 없이 바로 작업에 들어갈 수 있다.

물론 이것이 항상 완벽하게 작동한다고 말하기는 어렵다. 우리는 솔직하게 인정하는데 — LLM이 제공하는 설명이 항상 맞다는 보장은 없다. 그래서 ViewCheck는 각 판정에 근거가 되는 KRDS 규칙 원문과 공식 문서를 참조패널로 함께 제공한다. 담당자가 "이 설명이 맞나?" 싶을 때 직접 원문을 확인할 수 있도록. 결국 사람이 최종 판단을 하는 구도는 변하지 않고, 도구는 그 판단에 필요한 근거를 더 빠르고 풍부하게 제공하는 역할을 하는 것이다.

ViewCheck LLM 분석 결과 화면에서 종합총평 기능 카드가 펼쳐진 실제 프로덕션 캡처. — ViewCheck LLM 분석의 종합총평 카드. 체크리스트가 O/X를 나열하는 대신, 사이트 전체 상태를 맥락과 함께 설명한다. — 실제 분석 화면

"KRDS 846규칙"이라는 기준 — 체크리스트와 어떻게 다른가

ViewCheck LLM 분석의 핵심 판정 기준은 KRDS 846개 규칙이다. 이 규칙들이 기존 체크리스트와 어떻게 다른지를 짚고 가는 게 이해에 도움이 된다.

기존 공공 웹 품질 체크리스트는 대개 항목의 '종류'를 나열하는 방식이다. "이미지에 대체 텍스트를 제공하라", "색상만으로 정보를 구분하지 마라" 같은 가이드라인 수준의 서술이 항목이 된다. 점검자는 이 항목을 사이트에 비춰보며 O/X를 판단한다.

KRDS 846규칙은 그보다 구체적이다. 상위 위계로 보면 네 개의 카테고리로 나뉜다.

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

이 846개 규칙의 특징은 각 규칙이 단순히 "해라/하지 마라"가 아니라, 판정 가능한 형태로 정의되어 있다는 점이다. "버튼에 적절한 라벨이 있어야 한다"는 가이드라인이 아니라, "이 요소에 aria-label 또는 aria-labelledby 속성이 있거나, 텍스트 콘텐츠가 포함되어야 한다"는 식으로 조건이 명확하다. 덕분에 코드(DOM 데이터)로 자동 판정이 가능하고, 판정 결과에는 "어떤 조건이 왜 충족되지 않았는지"가 따라온다.

이 방식이 기존 체크리스트와 비교해 달라지는 것이 몇 가지 있다.

달라지는 것 1: 판정 근거가 따라온다. 기존 체크리스트에서 "X"는 그 자체로 끝이다. KRDS 규칙 판정에서 "미통과"는 어떤 조건이 어떻게 충족되지 않았는지 설명이 따라온다. 개발자가 "왜?"를 따로 조사하지 않아도 된다.

달라지는 것 2: 전체를 본다. 기존 체크리스트는 점검자가 방문한 페이지에 대해서만 결과가 있다. KRDS 846규칙 판정은 크롤러가 방문한 모든 페이지에 대해 결과가 있다. 메인뿐 아니라 검색, 신청, 로그인, 목록, 상세까지. 이 차이가 결과의 대표성에서 얼마나 큰 차이를 만드는지는 실제로 경험해봐야 체감된다.

달라지는 것 3: 해당없음(N/A)의 의미가 다르다. 기존 체크리스트에서 "해당없음"은 "이 페이지에는 이 요소가 없어서 확인 불필요"다. KRDS 규칙에서 "해당없음(N/A)"은 여러 원인이 있을 수 있다 — 진짜로 그 컴포넌트가 없어서 N/A인 경우도 있지만, 시각적 판단이 필요해서 자동 판정이 안 되는 경우, 런타임 상호작용이 있어야 알 수 있는 경우도 있다. 이 '정직한 N/A 분류'가 결과의 신뢰도를 높인다.

달라지는 것 4: 기준이 업데이트를 따라간다. KRDS는 공식 사이트(krds.go.kr)에서 지속적으로 업데이트된다. 규칙을 데이터로 관리하면 기준이 바뀔 때 체크리스트를 새로 만들지 않아도 된다. 코드가 아닌 데이터를 바꾸는 것으로 판정 기준을 갱신할 수 있다.

물론 846개 규칙이 모든 것을 커버하지는 않는다. KRDS 공식 사이트도 명시하듯, "KRDS를 적용하는 것만으로 웹 접근성을 완벽하게 충족한다고 판단하기는 어렵다"(KRDS 공식, krds.go.kr). 기준 자체의 한계이기도 하고, 자동 판정의 한계이기도 하다. 그래서 ViewCheck의 접근도 "846규칙으로 완벽히 판정한다"가 아니라 "846규칙으로 최대한 자동 판정하고, 그 한계를 투명하게 보여준다"다.

다중 페이지의 벽 — 가장 결정적인 차이

체크리스트와 대화형 LLM 분석의 차이 중에서 가장 결정적인 것은, 어쩌면 기능이나 경험이 아니라 스케일의 차이일 수 있다.

공공 웹사이트의 현실은 이렇다. 메인 페이지 하나가 아니라, 수십~수백 개의 세부 페이지가 있다. 대민 신청 서비스가 있는 기관이라면 특히 그렇다. 신청서를 작성하는 페이지, 첨부 파일을 올리는 페이지, 처리 현황을 보는 페이지, 결과를 통보받는 페이지 — 이 흐름 하나만도 여러 화면으로 이루어진다.

시민이 실제로 불편함을 겪는 곳은 대개 메인 페이지가 아니라, 이 '깊은 곳'의 화면들이다. 메인은 예산을 들여 잘 만들었지만, 신청서를 작성하는 화면이 접근성 기준에 맞지 않는 사례를 우리는 실제 분석 과정에서 반복적으로 마주쳤다. 스크린 리더 사용자가 폼 필드를 이해하지 못하는 구조, 오류 메시지가 텍스트로 제공되지 않는 구조, 필수 입력 항목이 색깔로만 표시된 구조 — 이런 문제들은 메인 페이지를 아무리 들여다봐도 보이지 않는다.

체크리스트 점검의 현실적 타협 — "메인만 보고 전체인 척하기" — 은 이 구조적 한계에서 비롯된다. 사람이 100페이지를 손으로 점검하는 건 물리적으로 불가능하기 때문이다.

ViewCheck는 처음부터 다중 페이지 분석을 기본으로 설계했다. URL 한 줄을 넣으면, 크롤러가 메인뿐 아니라 검색, 신청, 목록, 상세, 로그인 등 여러 페이지를 순회하며 데이터를 수집한다. 각 페이지에서 KRDS 846규칙이 판정되고, 그 결과가 사이트 단위로 집계된다. 단 하나의 페이지라도 특정 규칙을 위반하면, 그것이 사이트 전체의 결과로 반영된다.

이 '사이트 전체 기준'이 기존 체크리스트 방식과 가장 크게 달라지는 지점이다. 체크리스트는 점검한 페이지의 결과이고, LLM 분석은 사이트 전체의 결과다. 보고서 한 장에 적히는 숫자가 무엇을 대표하는지가 근본적으로 달라진다.

물론 다중 페이지 분석에도 한계는 있다. 어느 페이지를 몇 개나 방문할 것인지, 동적으로만 접근 가능한 페이지는 어떻게 처리할 것인지, 인증이 필요한 내부 페이지는 어떻게 할 것인지 — 이 문제들은 아직 모두 해결된 것이 아니다. 우리가 "연구 중"이라고 말하는 영역들이다.

한국인 디자이너가 수십 개의 웹페이지 목업이 핀으로 붙어 있는 넓은 벽 앞에 서서 전체를 살피는 모습. — 수십 페이지를 한눈에 보는 것 — 사람의 손으로는 불가능한 일이 자동화를 통해 가능해지고 있다.

24개 결과 카드가 가져다주는 것 — 맥락과 연결

ViewCheck LLM 분석에서 KRDS 846규칙 판정이 끝나면, 결과는 24개의 분석 카드로 재구성된다. 이 재구성 과정이 단순히 "표를 카드로 바꾸는 것"이 아님을 강조하고 싶다. 여기서 일어나는 변환이 체크리스트와의 가장 본질적인 차이 중 하나다.

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

종합총평 — 사이트 전체의 상태를 한 문단으로 요약. 점수와 함께 주요 특징을 설명한다.

인사이트 — 반복되는 문제 패턴을 짚어준다. 단일 오류가 아니라 "이 유형의 문제가 여러 페이지에 걸쳐 반복된다"는 패턴 인식.

임원보고서 — 기술적 전문 지식이 없는 관리자나 의사결정자를 위한 요약. 체크리스트 결과를 이런 형태로 번역하는 데 보통 별도의 시간이 필요했다.

디자인 스타일 / 컴포넌트 / 기본 패턴 / 서비스 패턴 — KRDS 카테고리별 상세 판정.

접근성(KWCAG) — 한국형 웹 콘텐츠 접근성 지침 기준 분석.

보안 / 반응형 / 웹 성능 / SEO — 7대 품질 영역 중 HTTP 측정이 필요한 영역들.

성과 대시보드 / 오류 리스트 / KRDS 비교 / 일관성 / 위반 매트릭스 — 집계와 시각화.

법적 리스크 / 벤치마킹 / UX 라이팅 / 비용·MM / 개선 로드맵 / AI 종합 리포트 — 판정 결과를 실무 의사결정으로 연결하는 카드들.

이 24개를 나열하면서 강조하고 싶은 것은 마지막 묶음 — "판정 결과를 실무 의사결정으로 연결하는 카드들"이다. 체크리스트는 보통 여기서 끝난다. "어디에 문제가 있는지"를 알려주지만, "그래서 어떻게 할 것인지"는 담당자가 따로 짜야 한다. 개선 로드맵을 세우고, 비용을 추산하고, 우선순위를 정하는 작업이 체크리스트와 별도로 필요하다.

LLM 분석의 결과는 이 "그래서 어떻게"까지 이어지려 한다. 비용·MM 카드는 발견된 문제들을 수정하는 데 대략 얼마나 걸릴지를 추산해 준다. 개선 로드맵 카드는 P0(즉시 대응)부터 P3(장기 개선)까지 우선순위를 제시한다. 벤치마킹 카드는 유사 기관과 비교해 현재 수준이 어디에 있는지 맥락을 준다.

이 카드들이 항상 완벽한 답을 준다고 말하기는 어렵다. 개선 비용 추산은 사이트와 팀 상황에 따라 달라질 수 있고, 우선순위도 기관의 사정에 따라 조정이 필요할 수 있다. 하지만 체크리스트 결과를 받아들고 "이걸 어떻게 실무에 연결하지?"로 시작하는 것과, 이미 어느 정도 정리된 맥락에서 시작하는 것 — 이 출발점의 차이가 실무 담당자에게는 꽤 크게 느껴진다.

결과를 "누가 읽는가" — 독자 중심 설계의 변화

체크리스트와 대화형 분석의 차이를 설명할 때 놓치기 쉬운 관점이 하나 있다. 결과물을 '누가 만드는가'와 '누가 읽는가'의 문제다.

체크리스트는 채우는 사람 중심으로 설계된다. 항목을 아는 사람이, 화면을 보며, O/X를 판단하는 일. 이 작업은 점검 역량을 가진 한 사람이 담당한다. 결과 파일은 그 한 사람의 작업물이다.

그러나 그 결과를 읽는 사람은 보통 여럿이다. 팀장은 "전체 상황이 어떤가"를 보고 싶고, 개발자는 "정확히 어디를 어떻게 고치면 되는가"를 보고 싶고, 예산 담당자는 "얼마나 큰 일인가"를 알고 싶다. 그런데 체크리스트 결과는 이 세 가지 질문 중 어느 하나에도 깔끔하게 맞는 형태가 아니다. 각 독자가 동일한 체크리스트 결과를 자기 관점에서 다시 해석해야 한다.

ViewCheck의 24개 카드는, 적어도 의식적으로는, 이 독자의 다양성을 염두에 두고 설계되어 있다. 임원보고서 카드는 기술 전문성이 없는 관리자를 위해 쓰여졌다. 오류 리스트 카드는 개발자가 바로 작업에 들어갈 수 있도록 항목별 수정 방향이 딸려 있다. 법적 리스크 카드는 준수 의무를 관리하는 담당자를 위한 것이다. 같은 분석 결과가, 읽는 사람에 따라 다른 '입구'로 제공되는 것이다.

닐슨 노먼 그룹의 대화형 AI 연구에서 확인된 통찰과 연결되는 지점이 있다. 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", 2023). 이 연구가 주는 교훈 중 하나는 — 사용자가 원하는 것이 각자 다르다는 전제에서 출발해야 한다는 것이다.

체크리스트는 이 전제를 무시한다. 모든 독자에게 동일한 형식의 결과를 건넨다. 대화형 분석은 적어도 "다양한 독자가 있다"는 출발점을 받아들이고, 그에 맞는 다양한 형태의 결과를 제공하려 한다. 물론 현재의 24개 카드가 모든 독자의 모든 필요를 충족한다고는 말할 수 없다. 이건 여전히 진행 중인 실험이다.

생산성의 재배분 — 사람이 할 일이 달라진다

체크리스트에서 대화형 분석으로의 전환이 가져오는 변화 중 가장 현실적인 것은 생산성의 '재배분'이다. 전통적인 점검 방식에서는 생산성의 상당 부분이 '수집과 정리'에 투입된다. 화면을 보고, O/X를 채우고, 표를 만들고, 보고서 형식에 맞게 옮기는 작업. 이 과정이 전체 점검 시간의 많은 부분을 차지한다.

대화형 분석이 이 수집·정리의 상당 부분을 자동화하면, 사람이 집중해야 할 시간이 달라진다. 수집과 정리보다 해석과 판단에, 보고서 작성보다 개선 계획 수립에, 기술적 확인보다 이해관계자 커뮤니케이션에 더 많은 시간을 쓸 수 있게 된다.

Microsoft Research의 2025년 New Future of Work 보고서는 이 방향의 일반적 패턴을 잘 포착하고 있다. "AI를 활용하는 기업 사용자들은 하루 40~60분을 절감하고 있다고 보고하며, 기술과 경험이 낮은 작업자일수록 AI의 혜택을 더 크게 경험하는 경향이 있다"(Microsoft Research, New Future of Work Report 2025). 또 소프트웨어 개발자의 역할이 "코드를 처음부터 끝까지 작성하는 것"에서 "AI가 생성한 제안을 검토하고 다듬는 것"으로 이동하고 있음을 주목했다.

공공 웹 점검의 맥락에서 이 패턴을 적용해보면 이렇다. 접근성 체크리스트를 손으로 채우던 시간이 자동화로 대체되면, 담당자의 역할은 "직접 확인하는 사람"에서 "자동화 결과를 검토하고 판단을 더하는 사람"으로 이동한다. 이건 담당자의 역할이 줄어드는 게 아니라, 역할의 성격이 달라지는 것이다. 반복적인 작업 대신, 더 높은 수준의 판단과 의사소통이 담당자의 핵심 기여가 된다.

이 전환이 아직 완전히 실현된 것은 아니다. 자동화 결과를 믿을 수 있는지 검증하는 역량, 결과 중 무엇이 중요한지 판단하는 역량, 이해관계자에게 전달하는 역량 — 이런 것들이 담당자에게 새롭게 요구된다. 도구가 바뀌면 사람에게 요구되는 역량도 바뀐다.

밝은 회의실에서 두 명의 한국인 전문가가 웹 분석 대시보드가 표시된 노트북을 보며 토론하는 모습. — 자동화가 수집·정리를 맡으면, 사람은 해석·판단·소통에 집중할 수 있다. 역할이 없어지는 게 아니라 달라지는 것.

대화형의 함정 — 우리가 경계하는 것들

대화형 분석이 체크리스트보다 모든 면에서 낫다고 말하는 건 솔직하지 않다. 대화형 인터페이스에는 체크리스트와는 다른 종류의 함정이 있다.

첫 번째 함정: 신뢰 과잉. 대화형 AI는 말을 잘한다. 유창하고, 친절하고, 자신감 있게 설명한다. 그런데 NN/g의 음성·화면 기반 지능형 어시스턴트 UX 연구에서 지속적으로 지적되어 온 것처럼, 챗봇 유형의 시스템은 "답이 비교적 단순하고 짧은, 제한된 질의에서만 잘 작동"하며, 복잡한 맥락에서는 그럴듯하게 틀리는 경우가 있다(Nielsen Norman Group, Chatbots & Conversational Interface UX). 결과를 받은 담당자가 근거를 확인하지 않고 그대로 보고서에 옮기면, LLM의 오류가 공식 문서에 들어갈 수 있다. 이게 체크리스트의 "형식적 통과"와 다른 종류의 위험이다.

그래서 ViewCheck는 각 판정에 근거를 요구한다. AI가 "이게 문제"라고 말할 때, 그 말이 어떤 규칙, 어떤 공식 문서에 기반한 것인지를 참조패널로 함께 보여준다. 담당자가 결과를 그대로 수용하는 게 아니라 근거를 확인하는 습관이 이 방식에서는 더 중요해진다.

두 번째 함정: 맥락의 소실. 대화는 맥락이 쌓이지만, 그 맥락이 정리되지 않으면 길을 잃는다. 채팅 히스토리가 길어지면 앞의 내용을 찾기 어렵고, 결과를 한눈에 비교하기 어렵다. 체크리스트의 O/X 표가 갖는 "한눈에 전체를 보는" 가독성은 대화 형식에서 오히려 약해질 수 있다. ViewCheck의 카드 방식은 이 문제를 카드 단위로 쪼개 관리함으로써 완화하려는 시도이지만, 완전히 해결됐다고 말하기는 어렵다.

세 번째 함정: 확인 불가능한 N/A. 자동 판정이 "해당없음(N/A)"으로 분류한 규칙이 정말 해당 없는 건지, 자동화가 못 본 건지를 구분하는 것이 현실적으로 쉽지 않다. 체크리스트에서는 점검자가 직접 눈으로 보고 "이 페이지에는 이 요소가 없다"를 확인하지만, 자동 판정에서는 그 확인이 코드에 달려 있다. 코드가 놓친 것을 담당자가 알아챌 수 없다면, 결과의 신뢰도는 그 한계 안에 있다.

이 함정들을 솔직히 적는 이유는, 대화형 LLM 분석을 쓰는 담당자가 이 점을 알고 쓰는 것이 모르고 쓰는 것보다 훨씬 낫기 때문이다. 도구를 맹신하지 않는 것, 근거를 확인하는 것, 결과를 최종 판단의 보조 자료로 쓰는 것 — 이 태도가 어떤 도구를 쓰든 필요한 것이지만, 대화형 AI 도구에서 특히 더 중요하다.

점검의 패러다임이 바뀐다 — 사용 경험의 재설계

"패러다임의 전환"이라는 표현은 과장처럼 들릴 수 있다. 하지만 체크리스트에서 대화형 분석으로의 이동이 단순히 도구의 교체가 아니라는 점을 강조하고 싶다.

체크리스트 방식에서 점검은 **사건(event)**이었다. 일 년에 한두 번, 집중적으로 점검 기간을 두고, 담당자가 몰아서 작업하고, 결과를 제출하고 끝난다. 그 이후 사이트가 어떻게 변했는지, 어떤 부분이 개선됐는지, 새로 추가된 기능이 기준에 맞는지는 다음 점검 기간이 되어야 알 수 있다.

대화형 분석이 가져올 수 있는 가능성은 점검을 **지속적인 과정(process)**으로 바꾸는 것이다. URL을 언제든 넣을 수 있다면, 점검이 특정 기간에만 하는 이벤트가 아니라 필요할 때 수시로 확인하는 습관이 될 수 있다. 새로운 기능이 배포되기 전, 리뉴얼이 예정된 페이지를 확인할 때, 민원이 들어온 영역을 즉시 점검할 때 — 점검의 진입 장벽이 낮아지면 점검의 빈도가 늘어날 수 있다.

이 방향은 GOV.UK가 접근성 전략에서 추구하는 방향과 맞닿아 있다. "정기적인 외부 감사에 의존하는 것에서, 지속적인 테스트와 팀 역량 내재화로"의 이동이다(GOV.UK, "A new accessibility strategy for the GOV.UK Design System", 2023). 접근성을 사이클 끝에 붙이는 검사가 아니라, 개발 과정의 자연스러운 부분으로 만드는 것.

ViewCheck가 아직 거기까지 완전히 도달했다고 말하기는 어렵다. 점검을 진정한 의미의 '지속적 과정'으로 만들기 위해서는, 도구만의 변화가 아니라 조직 문화와 프로세스의 변화도 필요하다. 도구가 아무리 편해져도, 담당자가 수시로 사이트 품질을 확인하는 습관이 생기지 않으면 여전히 '연간 이벤트'에 머무른다.

하지만 진입 장벽의 차이는 분명하다. "엑셀 열고, 체크리스트 펼치고, 화면 하나씩 대조하는 것"과 "채팅창에 주소 한 줄 넣는 것" — 이 두 행위의 심리적 무게는 다르다. 전자는 "큰 일을 시작한다"는 느낌이고, 후자는 "잠깐 확인한다"는 느낌이다. 심리적 진입 장벽의 차이가 행동 변화를 만들 수 있다.

7대 품질 영역과 24개 카드 — 빈 공간을 어떻게 채우는가

ViewCheck LLM 분석의 24개 카드는 KRDS 846규칙뿐 아니라, 행안부 「전자정부 웹사이트 품질관리 지침」이 정의한 7대 품질 영역을 함께 다룬다. 이 두 축의 관계를 이해하면 결과를 보는 눈이 달라진다.

7대 품질 영역을 다시 정리하면 이렇다.

호환성 — 표준 HTML/CSS, 브라우저 호환
접근성 — KWCAG 기반 접근성
개방성 — robots.txt, 메타데이터, 크롤링 허용
접속성 — 응답시간, SSL, 가용성
편의성 — 사용자 편의 기능
효율성 — 페이지 로딩 성능
신뢰성 — 보안 헤더, 개인정보처리방침

이 7개를 체크리스트로 점검하려면, 영역마다 다른 도구와 다른 방법이 필요하다. 접근성은 접근성 전용 도구, 성능은 Lighthouse 같은 성능 측정 도구, 보안은 보안 스캐너. 담당자는 이 여러 도구를 각각 배우고, 결과를 따로 수집하고, 다시 하나의 보고서로 합쳐야 한다.

ViewCheck는 이 7개 영역을 하나의 분석 흐름에서 처리하려 한다. Playwright로 브라우저를 띄워 사이트에 접속하면, HTTP 응답 데이터(접속성, 신뢰성)가 자연스럽게 수집된다. 동시에 DOM 구조(접근성, 호환성), 성능 메트릭(효율성), SEO 신호(개방성)도 함께 수집된다. 이걸 7대 영역에 매핑하면, 단일 분석 요청에서 7개 영역의 결과가 나온다.

체크리스트 방식이라면 이 7개 영역에 대해 7개의 별도 도구, 7번의 별도 점검, 7개의 별도 결과 파일이 필요할 것이다. 이를 하나의 흐름으로 통합하는 것 — 여기서도 대화형 분석이 주는 생산성의 재배분 효과가 나타난다.

다만, 통합의 편리함이 개별 전문 도구의 깊이를 완전히 대체하지는 않는다. 보안 전문 스캐너만큼 정밀한 보안 분석을 ViewCheck가 제공하지는 않고, 접근성 전문 감사인의 수동 검토를 자동화가 대체하지도 않는다. 이 한계를 인정하면서, ViewCheck의 위치는 "포괄적인 첫 번째 진단"에 가깝다. 세부 영역에서 전문 도구나 전문가의 심층 분석이 필요하다면, ViewCheck의 결과가 어디를 깊이 볼지에 대한 안내가 된다.

점검 결과를 '증거'로 — 문서화와 추적 가능성

점검의 목적 중 하나는 '기록'이다. 어느 시점에 어떤 상태였는지, 어떤 문제가 있었는지, 어떻게 개선됐는지를 남기는 것. 이 기록이 감사 대응의 근거가 되기도 하고, 개선 과정을 추적하는 자료가 되기도 한다.

체크리스트는 기록에 강하다. O/X 표는 그 자체로 이미 정형화된 기록 형식이다. 감사자나 발주처가 원하는 형식과 일치한다. 그래서 보고서 제출이 목적인 상황에서는 체크리스트가 여전히 편하다.

대화형 분석의 결과를 '공식 기록'으로 만들기 위해서는 추가 단계가 필요할 수 있다. LLM이 생성한 대화 형식의 결과를 정형화된 보고서 형식으로 변환하는 것이다. ViewCheck는 이 단계를 PDF 리포트와 Excel 보고서 형태로 제공하고 있다. 28개 섹션의 PDF와 7개 시트의 Excel이 분석 결과를 문서화된 형태로 만들어준다. 체크리스트 형식에 익숙한 감사자나 발주처에게도 전달 가능한 형태로 변환되는 것이다.

하지만 이 변환이 완전히 매끄럽지는 않다. 대화형 분석이 가진 맥락과 설명의 풍부함이 표 형식으로 줄어들 수 있고, 기관마다 다른 보고 형식 요구에 항상 맞추기도 어렵다. "감사 제출용 보고서를 자동으로 생성한다"는 게 쉬워 보이지만, 실제로는 다양한 발주처가 요구하는 형식이 달라서 이 부분은 아직 개선 여지가 많다.

추적 가능성도 중요한 과제다. "지난 분기 대비 이번 분기에 어떤 지표가 개선됐는가"를 보여주기 위해서는 동일한 기준으로 시점별 결과를 비교할 수 있어야 한다. 체크리스트는 이 비교가 비교적 쉽다 — 같은 표 양식으로 시점별 결과가 있으면 된다. 대화형 분석에서 이 시계열 비교를 어떻게 구현할 것인가는 우리가 계속 고민하는 과제 중 하나다.

한국인 프로젝트 매니저가 책상 위 인쇄된 분석 보고서와 노트북 화면을 나란히 놓고 과거와 현재 문서를 비교하는 모습. — 점검 결과를 기록하고 비교하는 것 — 도구가 바뀌어도 이 필요는 변하지 않는다.

"왜?"라고 물을 수 있다는 것 — Q&A의 가치

체크리스트를 들고 있는 담당자는 "왜 이게 문제인지"를 체크리스트에게 물을 수 없다. 체크리스트는 답하지 않는다. 항목을 알고 있거나, 모르면 찾아봐야 한다.

ViewCheck LLM 분석에서 담당자는 결과를 받은 자리에서 바로 "이게 왜 문제야?"라고 채팅으로 물을 수 있다. 그러면 해당 규칙의 내용, 왜 이 페이지의 이 요소가 그 규칙을 위반했는지, 어떻게 고칠 수 있는지가 답으로 온다. 참조패널에는 그 답의 근거가 된 KRDS 규칙 원문이나 공식 문서가 함께 표시된다.

이 "왜?"를 물을 수 있는 것이 체크리스트와 가장 크게 다른 경험이다. 체크리스트는 "무엇이 문제인지"를 알려주지만 "왜"를 설명하지 않는다. 대화형 분석은 "무엇이 왜 문제인지"를 함께 보여주고, 추가로 "그래서 어떻게 하면 되는지"까지 이어진다.

이 Q&A 기능은 특히 접근성이나 KRDS에 익숙하지 않은 담당자에게 더 큰 가치를 가진다. "ARIA-labelledby가 없어서 미통과"라는 결과를 받았을 때, "ARIA-labelledby가 뭔지" 검색하고, "왜 필요한지"를 공부하고, "이 경우에 어떻게 적용하는지"를 찾는 과정이 Q&A를 통해 하나의 대화로 이어진다. 학습 곡선이 낮아지는 것이다.

물론 이 Q&A가 항상 정확한 답을 준다는 보장은 없다. LLM은 그럴듯하게 틀릴 수 있고, 규칙 원문과 다른 설명을 할 수 있다. 그래서 근거가 되는 참조패널을 함께 보여주는 것이 중요하고, 담당자가 그 근거를 확인하는 습관을 갖는 것이 중요하다. 하지만 "전혀 설명이 없는" 체크리스트 결과와 "설명이 있지만 검토가 필요한" 대화형 결과를 비교하면, 후자가 더 나은 출발점인 것은 분명하다.

공공 웹 담당자의 역할이 달라진다는 것

이 모든 이야기를 결국 한 지점으로 모으면 — 점검 도구가 달라지면 담당자의 역할도 달라진다는 것이다.

체크리스트 시대의 담당자 역할은 주로 수행자였다. 항목을 알고, 화면을 보고, O/X를 채우는 사람. 기술적인 지식이 있을수록 유리했지만, 핵심은 결국 '얼마나 꼼꼼하게 체크리스트를 채우느냐'였다.

대화형 분석 시대의 담당자 역할은 판단자와 연결자에 가까워진다. 자동화된 결과를 받고, 그 결과가 맞는지 검토하고, 기관의 맥락에서 무엇이 더 중요한지 판단하고, 그 결과를 개발팀·관리자·감사자에게 연결하는 역할. 기술적 꼼꼼함보다 맥락적 판단력과 커뮤니케이션 역량이 더 중요해진다.

이 변화가 공공 부문의 현실에서 얼마나 빠르게 일어날지는 솔직히 모르겠다. 체크리스트와 정형화된 보고서 형식에 대한 관성은 강하고, 새로운 도구의 결과를 공식 보고에 사용할 수 있는지에 대한 기준도 아직 명확하지 않다. 무엇보다 새로운 도구를 쓰는 데 드는 학습과 전환 비용이 있다.

하지만 방향은 분명히 보인다. 점검이 수동에서 자동화로, 이벤트에서 과정으로, 결과 나열에서 맥락 제공으로 이동하는 흐름. 이 흐름 안에서 담당자의 역할이 어떻게 달라지고, 어떤 새로운 역량이 필요해지는지를 미리 생각해 두는 것 — 그게 이 글을 통해 나누고 싶었던 것의 핵심이다.

두 방식의 나란한 비교 — 정리해보자면

이제까지 나눈 이야기를 표 하나로 정리해 보자. 단, 이 표는 "체크리스트는 나쁘고 대화형은 좋다"는 결론을 내리기 위한 게 아니라, 각 방식이 어떤 상황에서 강점을 가지는지를 볼 수 있게 하기 위한 것임을 다시 한번 강조한다.

비교 항목	체크리스트 방식	대화형 LLM 분석
진입 방식	양식 작성, 점검 도구 설치	URL 한 줄 입력
결과 형식	O/X 표, 항목별 나열	24개 카드, 대화 형식
판정 근거	점검자 판단, 별도 확인 필요	규칙 원문·공식문서 참조패널
스케일	점검자가 방문한 페이지만	크롤러가 방문한 전체 페이지
추가 질문	불가능	채팅 Q&A
독자 다양성	동일 형식, 각자 해석	역할별 카드(임원보고서·오류리스트 등)
업데이트	체크리스트 재작성 필요	규칙 데이터 업데이트
신뢰도	점검자 역량에 의존	자동화+근거, 단 LLM 오류 가능
공식 보고 호환	강함 (표 형식 친숙)	PDF/Excel 변환 필요
반복 주기	정기 이벤트	수시 확인 가능
전문 지식 요구	높음 (점검자 역량)	낮음 (진입), 단 결과 검토 역량 필요
비용	인력 중심 비용	자동화 중심 비용

이 표를 보면, 두 방식이 경쟁 관계라기보다 서로 다른 상황과 목적에 맞는 도구임을 알 수 있다. 감사 제출이나 공식 인증이 목적이라면 체크리스트와 정형 보고서가 여전히 중요하다. 일상적인 모니터링과 개선 과정에서는 대화형 분석이 더 자연스럽다. 이 두 가지를 함께 쓰는 것이 현실적인 답일 수도 있다.

아직 어려운 것들 — 연구 중인 영역

이 글을 읽으며 "그럼 체크리스트를 버리고 ViewCheck로 다 해결되네"라고 생각했다면, 그건 우리가 원하는 메시지가 아니다. 대화형 LLM 분석에는 아직 많은 어려운 문제가 남아 있고, 그 중 일부를 솔직히 적어두는 게 책임 있는 소개라고 생각한다.

어려운 문제 1: N/A를 줄이는 일. KRDS 846규칙 중 자동 판정이 "해당없음(N/A)"으로 분류되는 규칙들이 있다. 그 페이지에 해당 컴포넌트가 없어서 N/A인 경우도 있지만, 시각적 판단이 필요해서, 또는 런타임 상호작용이 있어야 알 수 있어서 N/A인 경우도 있다. 후자를 줄이는 것이 커버리지를 높이는 핵심인데, 이건 단순한 코드 수정으로 해결되지 않는다.

어려운 문제 2: 시각적 영역. DOM 분석이 못 보는 것이 있다. 이미지나 비표준 방식으로 구현된 UI, 색상만으로 구분된 정보, 시각적 레이아웃의 일관성 — 이런 것들은 스크린샷과 Vision AI가 보완하려 하지만, 아직 완전하지 않다.

어려운 문제 3: 인증이 필요한 페이지. 로그인이 필요한 내부 페이지, 복잡한 폼 작성 과정 — 크롤러가 접근할 수 없는 영역은 분석할 수 없다. 이 문제는 기술적으로 풀기 어려운 영역이다.

어려운 문제 4: 맥락적 판단. "이 alt 텍스트가 의미 있는 내용인가"처럼 사람의 판단이 필요한 영역은 자동화로 대체할 수 없다. 구조는 자동화가 볼 수 있지만, 의미는 자동화가 판단하기 어렵다.

어려운 문제 5: LLM의 오류. AI가 생성한 설명이 틀릴 수 있다. 근거를 함께 제공하는 것이 이 위험을 완화하지만, 제거하지는 않는다.

이 문제들 각각이 독립적인 연구 주제다. 우리가 "연구 중"이라고 말하는 이유가 여기에 있다. 이 시리즈는 이 문제들을 한 편씩 더 깊이 들어가는 기록이기도 하다.

담당자와의 대화에서 배운 것들

이 글을 쓰기 위해 실제 공공 웹사이트를 운영하는 담당자들과 이야기를 나눈 기억을 더듬었다. 직접 인터뷰를 정식으로 진행한 것이 아니라, 제품을 테스트하는 과정에서 자연스럽게 들은 이야기들이다.

한 담당자는 이렇게 말했다. "체크리스트가 불편한 게 아니에요. 그냥 양이 너무 많아요. 다 보려면 진짜 하루 종일 걸려요." 다른 담당자는 이렇게 말했다. "결과가 나와도 개발팀에 전달하기가 제일 어려워요. '이게 뭐예요?'라고 물어보면 설명을 또 해야 하고, 그러다 보면 우선순위도 뒤죽박죽이 돼요." 또 다른 담당자는 이런 말을 했다. "사실 점검하고 나면 다음 해 같은 시기까지 다시 안 봐요. 결과도 이미 옛날 것이 되고, 고쳤는지 안 고쳤는지도 잘 모르고."

이 이야기들에서 공통된 것은 세 가지다. 분량, 전달, 연속성. 너무 많아서 다 못 본다. 결과를 다른 사람에게 설명하기 어렵다. 점검 후 개선 과정이 추적되지 않는다.

ViewCheck LLM 분석이 이 세 가지 문제를 얼마나 해결하는지는, 솔직히 담당자마다 다를 것이다. 분량 문제는 자동화로 상당 부분 해결된다. 전달 문제는 카드별 설명과 역할별 뷰가 도움이 된다. 연속성 문제는 아직 완전히 해결됐다고 말하기 어렵다. 시계열 비교, 개선 추적, 재점검 흐름 — 이 부분이 더 발전해야 "점검을 과정으로 만든다"는 목표에 가까워진다.

마무리 — 점검이 일상이 될 수 있을까

체크리스트와 대화형 LLM 분석을 나란히 놓고 비교해 왔다. 이 글의 처음에 "체크리스트는 나쁘고 대화형이 좋다"는 결론을 내리려는 게 아니라고 했다. 마지막에도 그 입장은 변하지 않는다.

두 방식은 각자 강점이 있다. 체크리스트는 명료하고, 공식 보고와 친숙하고, 오래 검증된 방식이다. 대화형 분석은 스케일을 다루고, 맥락을 제공하고, 진입 장벽이 낮다. 둘 중 하나를 선택해야 하는 게 아니라, 어떤 목적에 무엇을 쓸지를 아는 것이 더 중요하다.

우리가 LLM 분석으로 실험하고 싶은 것은 결국 이 질문이다. 점검이 일상이 될 수 있을까. 연간 이벤트가 아니라, 사이트가 바뀔 때마다, 새 기능이 추가될 때마다, 담당자가 궁금할 때마다 자연스럽게 확인하는 습관. 이 습관을 만드는 데 진입 장벽이 결정적 역할을 한다. "큰 일을 시작해야 한다"는 느낌이 드는 도구는 잘 쓰이지 않는다. "잠깐 확인해 보자"는 느낌이 드는 도구가 일상이 된다.

체크리스트는 여전히 필요하고, 앞으로도 한동안은 공식 점검의 핵심 형식으로 남을 것이다. 하지만 그 체크리스트를 채우기 전에, 채운 후에, 그리고 그 사이사이에 — 사이트가 어떤 상태인지를 빠르고 쉽게 확인하는 도구가 있다면, 점검의 질이 달라진다. 그게 대화형 분석이 채우려는 공간이다.

우리는 아직 그 공간을 완전히 채우지 못했다. 하지만 그 방향으로 계속 실험하고 있다. 다음 편에서는 이 실험의 또 다른 각도를 들고 오겠다.

밝은 현대적 사무실에서 커피를 마시는 쉬는 시간에 한국인 공무원이 편안하고 궁금한 표정으로 노트북을 여는 모습. — "잠깐 확인해 보자"는 느낌이 드는 도구가 일상이 된다. 그 진입 장벽의 차이가 습관을 만든다.

참고문헌

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

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

행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025. 6. 25. 일부개정). 국가법령정보센터. https://www.law.go.kr/행정규칙/전자정부웹사이트품질관리지침
행정안전부, 「전자정부 웹사이트 품질관리 지침」 일부개정 및 「품질관리 가이드」 수정본 안내(고시 제2025-46호), 2025. 6. 30. 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/
행정안전부, 「24년 전자정부 웹사이트 품질관리 가이드라인」 개정본 배포 안내(고시 제2024-25호, 2024. 4. 12.). https://www.mois.go.kr/frt/bbs/type013/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000006&nttId=110836

해외 — 연구 / 공식 자료

Deque Systems, "Automated Testing Identifies 57% of Digital Accessibility Issues, Surpassing Accepted Industry Benchmarks", 2021. BusinessWire 보도 포함. https://www.deque.com/blog/automated-testing-study-identifies-57-percent-of-digital-accessibility-issues/
Deque Systems, The Automated Accessibility Coverage Report. https://www.deque.com/automated-accessibility-coverage-report/
Level Access, "Automated Accessibility Testing: A Practical Guide to WCAG Coverage". https://www.levelaccess.com/blog/automated-accessibility-testing-a-practical-guide-to-wcag-coverage/
Nielsen Norman Group, "The 6 Types of Conversations with Generative AI" (18명 참가자, ChatGPT 4.0·Bard·Bing Chat, 2023. 5~6월 일기 연구, 425건 대화 분석). https://www.nngroup.com/articles/AI-conversation-types/
Nielsen Norman Group, How to Conduct Usability Studies for Accessibility. https://www.nngroup.com/reports/how-to-conduct-usability-studies-accessibility/
GOV.UK Government Digital Service, "Testing for accessibility". https://www.gov.uk/service-manual/helping-people-to-use-your-service/testing-for-accessibility
GOV.UK Design System team, "A new accessibility strategy for the GOV.UK Design System", Accessibility in government blog, 2023. 1. https://accessibility.blog.gov.uk/2023/01/06/a-new-accessibility-strategy-for-the-gov-uk-design-system/
Microsoft Research, New Future of Work Report 2025. https://www.microsoft.com/en-us/research/publication/new-future-of-work-report-2025/
W3C, Web Content Accessibility Guidelines (WCAG) 2.2, 2023. https://www.w3.org/TR/WCAG22/