24개 분석을 대화 한 번에 — 담당자의 하루가 어떻게 바뀌나

URL 한 줄로 시작한 대화가, 24개의 카드로 펼쳐질 때 생기는 일

들어가며 — 결과가 한꺼번에 쏟아지면 어떻게 될까

공공 웹사이트 담당자로 일한다는 건, 늘 무언가를 기다리는 시간이 많다는 뜻이기도 하다. 외주 개발사 회신을 기다리고, 위에서 기획이 확정되기를 기다리고, 점검 도구가 돌아가기를 기다리고, 결과 파일이 첨부된 메일을 기다린다. 그 기다림의 사이사이에, 실무는 그냥 흘러간다.

그 중에서도 유독 오래 기다리는 일이 하나 있다. 사이트 품질 점검 결과다. 전체 페이지를 점검하는 건 물리적으로 불가능하니 일부 페이지를 표본으로 잡고, 항목표를 인쇄하거나 스프레드시트를 열고, 화면을 번갈아 보며 하나씩 체크한다. 항목마다 근거를 메모로 달아야 하고, 미통과 항목은 왜 미통과인지 설명까지 붙여야 한다. 하루가 걸리거나, 며칠이 걸리거나, 아예 다음 주로 미뤄진다.

ViewCheck LLM 분석은 그 '기다림의 시작 지점'을 바꾸는 실험이다. 분석을 시작하는 데 드는 진입 비용 — 도구를 설치하고, 항목을 고르고, 옵션을 세팅하는 그 진입 비용 — 을 URL 한 줄로 줄이는 것. 그리고 그 한 줄이 채팅창에 들어가는 순간부터, 24개의 분석 카드가 대화처럼 차례로 펼쳐지는 것.

이 글은 '기능 소개'가 아니다. 이 시리즈의 트랙 G는 활용편이다. 24개가 다 나온 다음, 그 결과를 실제로 받아 든 사람에게 무슨 일이 생기는가를 이야기한다. 대화가 끝난 자리에 남는 것, 다음 날 담당자의 책상 위가 어떻게 달라지는지. 기술의 이면이 아니라 기술의 앞면, 즉 사람의 하루를 이야기하려 한다.

물론 미리 솔직하게 밝혀두고 싶은 것이 있다. 우리가 이야기하는 '하루의 변화'는, 우리가 관찰하고 기록하며 가설로 세운 것이지 통제된 실험으로 검증한 인과관계가 아니다. "ViewCheck를 쓰면 업무 시간이 정확히 몇 시간 줄어든다"는 수치를 단언할 근거가 우리에게는 없다. 다만 "이런 방식으로 사용했을 때, 이런 점이 달랐다"는 장면들은 있다. 그 장면들을 최대한 정직하게 써보려 한다.

30대 한국 여성 공무원이 두 대의 모니터 앞에서 구조화된 디지털 리포트를 집중해서 검토하는 모습. 밝은 자연광의 사무실. — 24개의 분석 카드를 받아 든 담당자. 결과가 이미 정리되어 있다는 것만으로 표정이 달라진다.

24개라는 숫자 — 왜 이렇게 많고, 그런데 왜 많다고 느껴지지 않는가

처음 '24개 분석 카드'라는 말을 들으면, 솔직히 많다는 느낌이 먼저 온다. 분석이 24개나 된다고? 결과가 24개면 그걸 다 봐야 하는 건 아닌가, 결국 더 복잡해지는 거 아닌가. 그 의문은 당연하다.

그런데 실제로 결과 화면을 마주했을 때의 경험은, 예상과 좀 다르다. 24개가 한꺼번에 쏟아지는 게 아니라, 위에서부터 아래로 순서가 있는 대화처럼 흘러내린다. 가장 위에는 큰 그림이, 가장 아래에는 세부 실행 계획이 온다. 처음 두세 개 카드만 읽어도 사이트의 전반적인 상태를 파악할 수 있고, 그게 충분하다면 거기서 멈출 수 있다.

UX 연구의 오랜 원칙 중 하나가 여기에 맞닿아 있다. Nielsen Norman Group의 Jakob Nielsen이 1995년 처음 명명한 점진적 공개(progressive disclosure) 개념이다. 핵심은 간단하다. "처음에는 가장 중요한 정보 몇 가지만 보여주고, 사용자가 더 원할 때 더 많은 것을 공개하라." 모든 정보를 한꺼번에 펼쳐 놓으면 오히려 사용자는 어디서부터 시작해야 할지 몰라 멈추게 된다(Nielsen Norman Group, "Progressive Disclosure", nngroup.com).

NN/g는 이 원칙에서 한 가지를 더 덧붙인다. "두 단계 이상의 공개 레벨을 두면 사용성이 크게 떨어진다. 사용자가 레벨 사이를 오가다 길을 잃기 때문이다. 그러니 자주 필요한 것은 처음부터 보여주고, 나머지만 뒤로 미뤄라." 24개 카드의 배치가 이 원칙을 어느 정도 반영하고 있다. 종합총평·인사이트·임원보고서가 맨 앞에 오고, 세부 오류 리스트·개선 로드맵·비용 추정은 뒤에 오는 구조. 담당자의 역할이나 당면 과제에 따라, 어디까지 읽을지를 스스로 자연스럽게 결정하게 된다.

물론 이게 완벽히 맞아떨어진다고 말하기는 어렵다. 24개의 순서와 그룹이 모든 담당자에게 최적이라는 보장은 없다. 우리가 경험하는 것은, 같은 분석 결과를 보고도 어떤 사람은 디자인 스타일 카드부터 찾고, 어떤 사람은 오류 리스트를 가장 먼저 클릭하고, 어떤 사람은 임원보고서를 바로 복사한다는 것이다. 순서의 최적화는, 솔직히 아직도 조금씩 손보는 영역이다.

24개 카드를 한 줄로 소개한다

24개가 구체적으로 무엇인지, 먼저 한 줄씩 정리해 보자. 이 카드들은 ViewCheck LLM 분석이 URL 한 줄을 받은 뒤 자동으로 생성한다.

큰 그림 묶음

종합총평 — 사이트 전체 상태를 한 단락으로 요약. 가장 먼저 읽게 되는 카드.
인사이트 — 반복적으로 나타나는 패턴, 눈여겨봐야 할 특이점을 뽑아 낸다.
임원보고서 — 비기술 독자(기관장, 팀장 등)에게 바로 보고 가능한 형태로 요약.

KRDS 846규칙 묶음

디자인 스타일(DS) — 색상, 타이포그래피, 간격, 레이아웃의 수치적 준수 여부. DS 120규칙.
컴포넌트(CP) — 버튼, 입력창, 탭, 모달 등 UI 부품의 구조·ARIA 속성 검증. CP 446규칙.
기본 패턴(BP) — 폼 작성, 동의/확인, 오류 처리, 필터·정렬 등 반복 상호작용. BP 108규칙.
서비스 패턴(SP) — 검색, 로그인, 신청, 정책 안내 같은 서비스 흐름 전체. SP 172규칙.
KRDS 846 전체 — DS+CP+BP+SP를 한 화면에서 조망할 수 있는 통합 뷰.

품질 기반 묶음

접근성(KWCAG) — 한국형 웹 콘텐츠 접근성 지침 기반의 34개 항목 점검.
보안 — 보안 헤더 13종, SSL/TLS, 쿠키 설정, 혼합 콘텐츠 등 신뢰성 검증.
반응형 — 데스크톱·태블릿·모바일 3개 뷰포트에서의 레이아웃·터치 타겟 실측.
웹 성능 — LCP, CLS, FCP, TTFB, INP 등 핵심 웹 지표(Core Web Vitals) 실측.
SEO — 메타 태그, OG 태그, canonical, 구조화 데이터, 헤딩 계층 분석.

분석·통찰 묶음

성과 대시보드 — 카테고리별 점수를 하나의 대시보드 화면으로 통합.
오류 리스트 — 미통과 규칙을 페이지별, 심각도(P0~P3)별로 정렬한 실행 목록.
KRDS 비교 — 공식 KRDS 기준과의 준수율 비교. 어디서 얼마나 벗어나 있는지.
일관성 — 여러 페이지 사이에서 동일 규칙이 일관되게 지켜지는지 교차 분석.
위반 매트릭스 — 어떤 규칙이 어떤 페이지에서 얼마나 반복되는지 히트맵 형태로.

의사결정 지원 묶음

법적 리스크 — 접근성 미준수, 개인정보 관련 잠재적 리스크 항목 정리.
벤치마킹 — 동종 사이트 또는 기준값 대비 이 사이트의 상대적 위치.
UX 라이팅 — 오류 메시지, 안내문, 라벨 텍스트의 품질 분석.
비용·MM — 미통과 항목을 수정하는 데 드는 예상 공수(Man-Month) 추정.
개선 로드맵 — P0~P3 우선순위별로 무엇을 언제까지 고칠지 순서를 제안.
AI 종합 리포트 — 위 23개 분석을 종합하여 AI가 서술한 사이트 진단 문서.

이 24개가 채팅 화면에 카드로 펼쳐진다. 총 분량이 상당하지만, 보고 싶은 것부터 클릭해 들어갈 수 있고, 필요 없는 건 접어둘 수도 있다. 핵심은 '한 번의 대화'로 이 모든 게 생성된다는 것이다. 항목을 골라 실행할 필요도, 중간에 설정을 바꿀 필요도 없다.

담당자의 하루는 어떻게 생겼나 — 비포(Before) 스케치

변화를 이야기하려면, 변화 전의 장면을 먼저 그려야 한다. 가상의 담당자 한 명을 상상해 보자. 이름 대신 '주무관 A'라고 부르자. 어느 광역자치단체 산하 기관의 정보화 담당 주무관이다.

주무관 A의 어느 평범한 오전 풍경. 메일함에는 어제 퇴근 후 온 것들이 쌓여 있다. 외주 개발사에서 "지난주 수정 요청 건 반영 완료" 회신이 하나, 상급 기관에서 "웹사이트 품질 점검 보고서 이달 말까지 제출 요망" 공문이 하나. 순간 가슴이 철렁 내려앉는 그 느낌. 품질 점검이라는 건 알겠는데, 어디서 어떻게 시작해야 하는지가 막연하다.

일단 작년에 했던 방식을 떠올린다. 항목표를 인쇄하고, 사이트를 열고, 각 페이지를 하나씩 점검하면서 '통과', '미통과'를 체크했다. 접근성은 크롬 확장 도구를 깔아서 실행해 봤고, 성능은 Lighthouse를 돌렸고, 보안은 외부 진단 사이트에서 확인했다. 각 도구마다 결과 포맷이 달라서, 그걸 다시 하나의 보고서로 합치는 데도 한나절이 걸렸다.

Asana가 발표한 연구에 따르면, 지식 근로자들은 하루 업무 시간의 60%를 "일에 대한 일(work about work)" — 회의, 상태 확인, 도구 전환, 정보 검색 같은 메타 작업 — 에 쓴다고 한다. 하루에 평균 9개 앱을 오가고, 앱 간 전환 횟수는 25회를 넘으며, 정보를 찾는 데만 59분이 소요된다는 것이다(Asana, "Anatomy of Work Index"). 주무관 A의 품질 점검 루틴은 이 수치의 전형적인 구현처럼 보인다. 점검 자체보다 도구를 찾고, 결과를 합치고, 형식을 맞추는 데 시간이 더 걸린다.

이건 주무관 A의 능력이나 태도의 문제가 아니다. 도구가 분산되어 있고, 기준과 결과 형식이 통일되어 있지 않고, 그걸 연결하는 작업 자체가 '또 하나의 일'로 쌓이는 구조적인 문제다. Microsoft의 2025 Work Trend Index는 이 문제를 "용량 부족(capacity crunch)"으로 표현한다. 할 일은 늘어나는데, 그 일을 '더 빠르게 잘 할 수 있게 해주는 도구'에 접근하는 비용 자체가 또 하나의 부담으로 작용한다는 것이다(Microsoft Work Trend Index, 2025).

40대 한국 남성 공무원이 인쇄된 체크리스트와 메모지, 여러 탭이 열린 노트북 앞에서 스트레스를 받고 있는 모습. — 도구마다 결과 포맷이 다르고, 그걸 합치는 일이 또 하나의 업무가 된다. 분산된 도구의 풍경.

URL 한 줄을 붙여 넣는 순간부터 — 애프터(After) 스케치

같은 아침, 같은 주무관 A가 이번에는 ViewCheck 채팅창에 사이트 주소를 붙여 넣는다. 딱 한 줄. 그리고 엔터를 친다.

그다음부터 주무관 A가 할 일은 없다. 일단 다른 업무를 한다. 공문 회신을 쓰고, 미결 메모를 정리하고, 잠깐 커피를 마신다. 이 '비는 시간'이 생겼다는 것 자체가 이미 변화다.

분석이 완료되면, 채팅창에 카드들이 나타나기 시작한다. 가장 먼저 나타나는 것은 종합총평. 이 사이트의 전반적인 상태를 한 단락으로 요약해 준다. KRDS 준수율이 어느 정도인지, 어떤 카테고리에서 특히 문제가 많은지, 가장 우선적으로 주목해야 할 영역이 어디인지. 한 단락이지만, 거기에는 모든 페이지를 돌며 수집한 데이터가 응축되어 있다.

그다음은 인사이트. 반복적으로 나타나는 패턴을 짚어 준다. "이 사이트에서는 로그인 화면과 신청 화면에서 오류 안내 텍스트가 일관되게 빠져 있습니다" 같은 것. 이게 중요한 이유는, 사람이 100페이지를 하나씩 보면서 패턴을 찾는 건 거의 불가능에 가깝기 때문이다. 눈앞의 페이지만 보다 보면 전체 흐름을 놓친다. 다중 페이지를 한꺼번에 처리한 뒤에야 "이 규칙이 전체 사이트 70%에서 미통과"라는 사실이 보인다.

세 번째 카드인 임원보고서는 주무관 A가 특히 눈이 갔다고 말할 것 같은 카드다. 기관장에게 보고해야 할 때, "이거 복사해서 거의 그대로 쓸 수 있을까?"라는 질문이 떠오르기 때문이다. 완벽하게 그대로 쓰기엔 조직의 맥락이나 문체를 맞춰야 하겠지만, 보고서의 골격이 이미 있다는 것 — 그것만으로도 맨땅에서 시작하는 것과는 다르다.

필요한 카드만, 필요한 깊이만

24개가 모두 주무관 A에게 필요한 건 아니다. 그건 처음부터 기대하지 않는 게 맞다.

가령 보안을 담당하는 부서가 별도로 있고, 접근성 점검을 외부 기관에 위탁하는 계획이 잡혀 있다면, 주무관 A는 그 카드들을 굳이 깊이 파고들지 않아도 된다. 그 부분은 해당 담당자에게 링크를 공유하거나, 결과를 export해서 넘기면 된다. 하나의 분석 결과가 여러 사람의 각기 다른 입구가 될 수 있다.

반대로 어떤 담당자는 오류 리스트 하나만 집중적으로 본다. 이미 전체 점수는 파악하고 있고, 지금 필요한 건 개발사에 전달할 수 있는 '구체적인 수정 목록'이기 때문이다. 오류 리스트 카드는 어떤 페이지의 어떤 요소가 어떤 규칙을 위반했는지를, 심각도(P0~P3) 순서로 정렬해 보여 준다. 그걸 그대로 복사해 개발사에 넘기면, "이거 봐주세요"라는 한 줄 대신 "P0 항목 몇 건, P1 항목 몇 건, 각각 이 페이지의 이 요소" 라는 구체적인 커뮤니케이션이 가능하다.

또 다른 담당자는 개선 로드맵부터 본다. 점검 결과를 받았을 때 가장 먼저 드는 질문이 "그래서 뭐부터 고쳐야 하죠?"이기 때문이다. 개선 로드맵은 P0(즉시 수정 필요)부터 P3(중장기 개선)까지의 우선순위를 제안한다. 전부 다 고칠 자원이 없을 때, 가장 적은 비용으로 가장 큰 효과를 낼 수 있는 지점을 먼저 잡는 것 — 그게 로드맵 카드가 있는 이유다.

이 '선택적 활용'은 설계의 의도이기도 하다. 정보는 한꺼번에 있지만, 진입점은 사람마다 다르다. NN/g가 말하는 점진적 공개의 핵심이 바로 이것이다. "처음에는 가장 중요한 것을 보여주고, 더 깊이 들어가고 싶을 때 들어갈 수 있게 하라." 24개 카드는 각자가 '첫 번째로 열어야 할 카드'를 스스로 고르는 구조다.

가장 오래 멈추는 카드들 — 실제 반응

'어떤 카드에서 가장 오래 머무는가'를 관찰하면, 사람들이 실제로 무엇을 갈망하는지가 보인다. 우리가 관찰한 장면들을 있는 그대로 적는다. 통계가 아니라 사례들이다.

종합총평에서 멈추는 사람들. 많다. 종합총평을 보고 "이게 맞아?"라는 반응이 나오면, 그다음부터 세부를 파고들기 시작한다. "이게 맞아?" 라는 의심이 생긴다는 건, 이미 사이트를 어느 정도 알고 있다는 뜻이기도 하다. 알고 있는 것과 분석 결과가 일치하면 신뢰가 생기고, 어긋나면 질문이 생긴다. 그 질문이 다음 대화로 이어진다.

오류 리스트에서 오래 있는 사람들. 특히 개발사와 소통해야 하는 담당자들이다. 리스트를 보면서 "이건 우리가 알고 있었던 건데", "이건 이미 수정 요청을 넣었는데", "이건 처음 보는 거네" 같은 혼잣말이 나온다. 리스트가 자신이 아는 것과 모르는 것을 구분해 주는 거울 역할을 한다.

비용·MM 카드에서 멈추는 사람들. 예산을 짜야 하거나, 올해 사업 범위를 정해야 하는 사람들. 미통과 항목을 수정하는 데 몇 명이 얼마나 걸리는지 — 이 숫자를 내부에서 누군가에게 설명해야 할 때, 근거가 없으면 아무도 수긍하지 않는다. "저는 이 정도 걸릴 것 같습니다"가 아니라 "이 규칙 범주의 평균 수정 공수는 이 정도입니다"라는 틀이 있으면, 회의 테이블에서 이야기가 달라진다.

법적 리스크 카드에서 길게 읽는 사람들. 접근성 미준수가 법적 문제와 연결될 수 있다는 걸 처음 보는 담당자들. WCAG 2.2는 2023년 10월 W3C 정식 권고안으로 채택되었고(W3C, WCAG 2.2 Recommendation, 2023. 10. 5.), 2025년에는 ISO/IEC 국제 표준으로도 승인되었다(W3C, WCAG 2.2 approved as ISO/IEC international standard, 2025). 접근성 기준이 단순히 '좋은 것'이 아니라 '지켜야 하는 것'의 영역으로 옮겨가고 있다. 법적 리스크 카드는 그 맥락을 담는다.

ViewCheck LLM 분석이 완료되어 24개의 분석 카드가 대화 형태로 화면에 순서대로 나타난 실제 프로덕션 캡처. — 실제 ViewCheck LLM 분석 완료 화면. URL 한 줄로 시작한 분석이 끝나면 24개 카드가 대화로 펼쳐진다. 종합총평부터 AI 종합 리포트까지, 사이트 전체를 한 번의 대화로 받아 보는 장면이다. — 실제 분석 화면

"왜?"를 물을 수 있는 자리

24개 카드가 다 나온 뒤에도 대화는 끝나지 않는다. 오히려 거기서부터 진짜 대화가 시작되는 경우가 많다.

어떤 항목이 '미통과'로 표시되어 있다면, 담당자는 채팅창에 그냥 물으면 된다. "이 항목은 왜 미통과야?" 그러면 ViewCheck는 근거를 댄다. 어떤 규칙의 어떤 조건이 충족되지 않았는지, 그 규칙이 KRDS 공식 가이드의 어느 항목에서 왔는지, 참조패널에서 원문을 직접 볼 수 있게 열어 준다.

이 '근거를 댄다'는 것이 왜 중요한가. 결과만 있고 근거가 없으면, 담당자는 그 결과를 누구에게도 전달할 수 없다. "도구가 그렇게 나왔어요"는 설명이 아니다. 반면 "KRDS 컴포넌트 규칙 CP-037에 따르면, 이 버튼 요소는 ARIA label이 없어 스크린 리더 사용자가 버튼의 기능을 알 수 없습니다"는 설명이다. 외주 개발사에 넘길 수 있고, 내부 보고에 쓸 수 있고, 감사 지적 사항에 대응하는 근거가 된다.

RAG(Retrieval-Augmented Generation, 검색 증강 생성) 구조가 여기에 역할을 한다. 단순히 AI가 '알아서 판단'하는 게 아니라, KRDS 규칙 원문과 공식 문서를 검색해 판단의 근거로 삼은 뒤, 그 근거를 함께 제시하도록 강제하는 방식이다. AI가 그럴듯하게 틀릴 위험 — 이른바 환각(hallucination) — 을 줄이는 방어 장치이기도 하다. 완벽히 막는다는 뜻이 아니다. 근거가 제시되기 때문에, 사용자가 그 근거를 직접 확인하고 잘못된 판정을 발견할 수 있다는 뜻이다.

"AI가 그렇다고 하더라"가 아니라 "이 규칙의 이 항목이 이렇게 되어 있어서 그렇다"로 대화할 수 있게 되는 것. 이게 24개 카드 뒤에 붙어 있는 Q&A와 참조패널의 가치다.

다중 페이지 분석이 만드는 차이 — 한 장만 봤을 때와 무엇이 다른가

24개 카드가 한꺼번에 나온다는 것 못지않게 중요한 것이 있다. 그 카드들이 한 페이지가 아니라 사이트 전체를 기반으로 생성된다는 사실이다.

공공 웹사이트에는 메인 페이지 하나만 있지 않다. 검색 페이지, 신청 페이지, 게시판 목록, 게시판 상세, 로그인 화면, 마이페이지, 정책 안내 페이지, FAQ 페이지 — 크지 않은 사이트에도 보통 수십 개의 화면이 있다. 그리고 KRDS의 규칙 중 상당수는 특정 페이지 유형에서만 의미가 있다. 로그인 화면에만 나타나는 규칙, 신청 폼이 있는 페이지에서만 적용되는 규칙, 목록 화면에서만 확인되는 규칙이 따로 있다.

메인 페이지 하나만 보고 점검을 끝내면, 그 규칙들은 "해당 없음"으로 처리된다. 공식적으로는 점검을 했지만, 실제로는 점검하지 않은 셈이다. 그리고 실제로 시민이 불편을 겪는 지점은 대개 메인이 아니라, 신청서를 작성하는 화면이나 오류가 나는 화면 같은 '깊은 곳'이다.

ViewCheck는 다중 페이지 분석을 기본값으로 한다. 주소 한 줄을 넣으면, 그 사이트의 여러 페이지를 실제 브라우저로 돌며 수집한 뒤 결과를 집계한다. 그래서 일관성 카드와 위반 매트릭스 카드가 의미를 갖는다. "이 규칙은 100개 중 73개 페이지에서 미통과입니다"라는 정보는, 한 페이지만 봐서는 절대 나올 수 없다.

행정안전부 「전자정부 웹사이트 품질관리 지침」(고시 제2025-46호, 2025. 6. 25.) 역시 사이트 전반의 품질을 기준으로 한다. 메인 페이지만 좋다고 통과인 기준이 아니다. 그렇다면 점검도 사이트 전체를 기준으로 해야 의미가 있다. 다중 페이지 분석이 출발점인 이유다.

24개 카드와 다섯 가지 역할의 담당자

같은 분석 결과를 받아도, 각자의 역할이 다르면 필요한 카드가 다르다. 아래는 우리가 상상하거나 관찰한 다섯 가지 역할의 활용 모습이다.

역할 1: 보고서 작성자

팀장 또는 기관장에게 현황을 보고해야 하는 담당자. 이 역할에서 가장 먼저 열어야 할 카드는 임원보고서와 성과 대시보드다. 임원보고서는 수치와 해설이 함께 있고, 비기술 독자도 읽을 수 있는 언어로 써져 있다. 성과 대시보드는 카테고리별 점수를 시각적으로 요약해 줘서 발표 자료에 넣기 좋다. 이 두 카드를 기반으로 보고서를 만들면, 내용 채우기에 드는 시간이 크게 줄어든다.

역할 2: 개발사 PM

외주 개발사와 수정 커뮤니케이션을 담당하는 담당자. 이 역할에서는 오류 리스트가 핵심이다. P0(즉시 수정 필요) 항목 목록을 출력하거나 링크를 공유하는 것만으로, "이번 스프린트에서 다음 항목들을 수정해 주세요"라는 구체적인 요청이 된다. 미통과 항목마다 규칙 번호와 근거가 붙어 있으니, "왜 이게 문제인가요?"라는 개발사의 질문에도 다시 대화를 열어 근거를 보여주면 된다.

역할 3: 접근성 점검 담당자

KWCAG나 WCAG 기반의 접근성 준수를 담당하는 역할. 접근성(KWCAG) 카드와 법적 리스크 카드를 함께 본다. 접근성 카드는 34개 항목의 점검 결과를 정리해 주고, 법적 리스크 카드는 미준수가 어떤 잠재적 위험과 연결되는지를 맥락으로 더해 준다. WCAG 2.2가 2025년 ISO/IEC 국제 표준으로 승인된 시점에서, 이 맥락은 더욱 중요해지고 있다.

역할 4: 예산·사업 기획자

올해 사업 범위와 예산을 짜야 하는 담당자. 비용·MM 카드와 개선 로드맵 카드가 주된 참조 자료다. 비용·MM 카드는 미통과 규칙들의 수정 예상 공수를 범주별로 제시한다. 개선 로드맵은 그걸 우선순위별로 배열해 준다. 올해 예산으로 무엇까지 할 수 있는지, 내년으로 미뤄야 할 것은 무엇인지를 근거 있게 이야기할 수 있게 된다.

역할 5: 디자이너 또는 기획자

UI/UX 개선을 담당하는 역할. 디자인 스타일, 컴포넌트, UX 라이팅, KRDS 비교 카드가 주된 관심사다. KRDS 공식 기준과 현재 사이트 사이의 거리를 시각적으로 보여주는 KRDS 비교 카드는, "지금 우리 사이트가 KRDS로부터 어디에 서 있는가"를 판단하는 기준이 된다. UX 라이팅 카드는 오류 메시지, 안내 텍스트, 버튼 라벨 같은 텍스트 품질을 짚어 줘서, 디자이너나 카피라이터가 참고하기 좋다.

24개가 한 번에 오면 오히려 정보 과부하 아닐까

정직하게 짚어야 할 부분이 있다. 24개가 한꺼번에 나온다는 게 장점이라고 말했지만, 반대 방향의 걱정도 있다. 24개가 많으면, 오히려 어디서부터 시작해야 할지 몰라 멈추지 않을까?

정보 과부하(information overload) 연구는 오래된 주제다. 허버트 사이먼(Herbert Simon)이 1970년대에 이미 "정보의 풍요는 주의의 빈곤을 낳는다"고 말했다. 디지털 시대에 들어서 이 문제는 훨씬 더 구체적인 형태로 나타난다. 너무 많은 정보를 동시에 받으면, 사람은 처리를 포기하거나, 가장 쉬운 선택(또는 가장 처음 보이는 선택)만 하고 멈춘다.

24개 카드는 이 문제를 어떻게 다루는가? 두 가지 구조적 선택을 했다고 말할 수 있다.

첫째, 순서가 있다. 종합총평이 가장 먼저 오고, 세부가 뒤에 온다. 처음 두세 개 카드만 읽어도 전체 맥락이 생긴다. 더 깊이 들어가고 싶은 사람은 내려가면 되고, 거기서 충분하다면 멈춰도 된다.

둘째, 탐색이 선택적이다. 24개를 순서대로 전부 읽어야 하는 게 아니다. 필요한 카드를 클릭하면 바로 그 내용으로 들어갈 수 있고, 관심 없는 카드는 지나쳐도 된다. NN/g의 점진적 공개 원칙이 말하는 바이기도 하다 — 두 단계 이상의 레벨을 두면 사용성이 떨어진다고 경고하면서, 그 대안으로 제시하는 것이 "자주 필요한 건 처음부터 보여주고, 나머지는 요청 시에만 보여주는" 구조다.

다만 솔직히 말하면, 이 균형이 지금 완벽하게 맞아 있다고 말하기는 어렵다. 24개가 적절한 숫자인지, 순서가 최적인지, 어떤 카드를 '기본 보기'로 할지 — 이건 여전히 조정 중인 영역이다. 사용자마다 첫 번째로 가장 필요한 카드가 다르기 때문에, 어떻게 '진입의 개인화'를 설계할 수 있을지도 관심사다. 아직 답을 찾는 중이다.

"다음에 어떻게 할지"가 보이는 카드 — 개선 로드맵의 쓸모

24개 카드 중에서 특별히 이야기하고 싶은 하나를 고르라면, 개선 로드맵을 고른다.

점검 결과를 받았을 때 담당자가 가장 먼저 하는 생각은 보통 "그래서 뭐부터 고쳐야 하죠?"다. 미통과 항목이 수십, 수백 개라도 모든 걸 다 고칠 자원은 없다. 이번 분기에 할 것, 다음 분기로 넘길 것, 장기 과제로 분류할 것을 나눠야 한다. 그 구분 기준은 보통 '심각도(이게 얼마나 나쁜가)'와 '비용(이걸 고치는 데 얼마나 걸리는가)'이다.

ViewCheck의 개선 로드맵 카드는 이 두 기준을 함께 담으려 한다. P0 항목(즉각적인 사용자 피해나 접근 불가 수준의 문제)부터 P3 항목(장기적으로 개선이 바람직한 수준)까지 분류하고, 각 단계에서 수정해야 할 대표 항목들을 제안한다. 거기에 비용·MM 카드의 공수 추정이 더해지면, "이 분기 예산으로는 P0와 P1의 상위 20개 항목까지 가능하다"는 이야기를 할 수 있게 된다.

이게 완벽한 계획을 만들어 주냐고 하면 — 아니다. 개선 로드맵은 시작점이지, 완성된 계획이 아니다. 각 기관의 예산 주기, 개발사 계약 일정, 내부 우선순위에 따라 실제 로드맵은 달라져야 한다. 다만 아무것도 없는 맨땅에서 시작하는 것과, 우선순위의 골격이 잡혀 있는 상태에서 살을 붙이는 것 — 그 차이는 크다.

밝은 회의실에서 한국인 직원들이 큰 모니터에 표시된 우선순위 작업 목록을 함께 검토하며 한 명이 화면을 가리키고 있는 모습. — 우선순위가 정해진 목록이 있을 때, 팀 회의의 시작 지점이 달라진다. "뭐부터 할까요?"가 아니라 "이 중에서 이번에 어디까지 할 수 있을까요?"로.

대화가 끝난 뒤 — 결과를 어떻게 쓰는가

24개 카드가 다 나온 뒤, 그 결과를 어떻게 쓰는가. 몇 가지 활용 패턴을 정리해 본다.

패턴 1: 보고서에 넣기

임원보고서 카드를 기반으로 기관 내부 보고 자료를 만든다. 성과 대시보드의 카테고리별 점수를 차트로 삽입한다. 종합총평의 핵심 문장을 요약 항목으로 쓴다. 분석 결과 전체를 PDF로 출력하면, 첨부 자료로도 쓸 수 있다.

패턴 2: 개발사 이슈 전달

오류 리스트 카드의 P0, P1 항목을 개발사 이슈 트래커(Jira, GitHub Issues 등)에 옮긴다. 각 항목에는 미통과 규칙 번호와 근거가 붙어 있으니, 개발사가 무엇을 어떻게 고쳐야 하는지 파악하기 쉽다. "이 부분 봐주세요"라는 모호한 요청 대신, 번호와 기준이 있는 구체적인 이슈가 생긴다.

패턴 3: 사업 기획 근거로 쓰기

비용·MM 카드의 수정 공수 추정을 근거로 사업 예산안 작성에 활용한다. 개선 로드맵을 차년도 정보화 사업 계획의 골격으로 삼는다. "이 사이트가 왜 개선이 필요한가"에 대한 근거가 이미 24개 카드 안에 있다.

패턴 4: 재분석으로 진전 확인

수정을 마친 뒤, 같은 URL로 다시 분석을 돌린다. 이전 결과와 비교해 어떤 항목이 통과로 바뀌었는지 확인한다. 점수가 얼마나 올랐는지도 본다. 개선의 효과를 수치로 보여줄 수 있다는 것, 이게 담당자 입장에서는 꽤 중요한 장면이다. "우리가 이만큼 나아졌다"를 근거로 말할 수 있게 된다.

다중 페이지가 만드는 세 가지 카드 — 일관성·위반 매트릭스·벤치마킹

다중 페이지 분석이 가능하기 때문에 의미가 생기는 카드들이 있다. 한 페이지만 봐서는 절대 나올 수 없는 인사이트를 담는 카드들이다.

일관성 카드는 같은 규칙이 여러 페이지에서 일관되게 적용되는지를 본다. 예를 들어, 버튼 컴포넌트의 ARIA 라벨이 메인 페이지에서는 제대로 있지만, 신청 페이지에서는 빠져 있다면 — 이건 규칙 자체를 모르는 게 아니라, 개발 과정에서 일관되게 반영되지 않은 것이다. 이 구분이 수정 방식을 달리하게 만든다. 하나씩 고치는 게 아니라, 템플릿 수준에서 한 번에 고칠 수 있기 때문이다.

위반 매트릭스 카드는 어떤 규칙이 어떤 페이지에서 얼마나 반복적으로 미통과인지를 히트맵 형태로 보여준다. 어떤 규칙이 사이트 전체에 걸쳐 광범위하게 위반되는지, 어떤 규칙이 특정 페이지 유형에만 집중되는지가 한눈에 들어온다. 이 히트맵을 보면, 어디에 에너지를 집중해야 할지가 보인다. 사이트 전체에 걸쳐 반복되는 위반 한 건을 고치는 것이, 특정 페이지에만 있는 여러 건을 고치는 것보다 임팩트가 크다.

벤치마킹 카드는 분석 대상 사이트를 기준값 또는 다른 사이트들과 비교한다. "우리 사이트가 어느 수준인가"는, 절대 점수만 봐서는 판단하기 어렵다. 60점이라는 숫자가 좋은 건지 나쁜 건지, 맥락이 없으면 모른다. 비교 대상이 있을 때 비로소 "우리는 이 정도 수준"이라는 감이 온다. 벤치마킹 카드는 그 맥락을 제공한다.

이 세 카드는, 다중 페이지 분석이 단순히 "더 많은 페이지를 본다"가 아니라 "전체 사이트를 하나의 시스템으로 본다"는 것을 가장 잘 보여주는 카드들이다.

UX 라이팅 카드 — 텍스트도 품질이다

24개 카드 중 예상외로 반응이 큰 카드 중 하나가 UX 라이팅 카드다.

접근성이나 보안 같은 항목은 담당자들이 어느 정도 예상하고 있다. 그런데 오류 메시지 문구, 버튼 라벨, 안내 텍스트의 품질을 별도로 분석해 준다는 건 처음 보는 경우가 많다.

공공 웹사이트의 오류 메시지를 한 번 떠올려 보자. "오류가 발생했습니다. 잠시 후 다시 시도하세요." 무엇이 오류인지, 어떤 행동을 해야 하는지, 그 행동이 효과가 있을지 — 아무것도 모른다. 사용자는 그 메시지 앞에서 멈춘다.

KRDS의 기본 패턴(BP) 규칙들은 폼 오류 안내, 동의/확인 안내, 처리 결과 안내 같은 텍스트 패턴을 포함한다. 어떤 상황에서 어떤 수준의 안내가 필요한지를 규정한다. UX 라이팅 카드는 이 규칙들을 기반으로, 사이트의 텍스트 품질을 분석한다. "이 버튼 라벨은 행동이 명확하지 않습니다", "이 오류 메시지는 사용자가 해야 할 행동을 안내하지 않습니다" 같은 식으로.

텍스트는 눈에 보이는 것 중에서 가장 직접적인 소통 수단이다. 아무리 구조가 잘 잡혀 있어도, 텍스트가 사용자를 혼란스럽게 하면 경험은 나빠진다. UX 라이팅 카드는 그 부분을 독립적으로 꺼내 보여준다. 디자이너나 기획자에게는 물론, 콘텐츠 담당자에게도 직접적인 피드백이 된다.

보안 카드와 반응형 카드 — 잊기 쉬운 두 영역

보안과 반응형은 점검 리스트에는 늘 있지만, 실제로 깊이 들여다보기가 어려운 영역이다. 전문 지식이 필요하기 때문이다.

보안 카드는 보안 헤더 13종(HSTS, CSP, X-Frame-Options, X-Content-Type-Options 등), SSL/TLS 인증서, 쿠키의 HttpOnly·Secure·SameSite 설정, CORS, 혼합 콘텐츠(HTTP 리소스가 HTTPS 페이지에 섞인 경우) 같은 신뢰성 영역을 점검한다. 이 항목들은 보통 개발자 없이는 확인하기 어렵다. 하지만 설정이 잘못되어 있으면, 사용자의 정보가 위험에 노출되거나 브라우저 경고가 뜨거나 서비스 자체가 차단될 수 있다.

보안 카드는 이 영역을 담당자가 전문 지식 없이도 "지금 상태가 어떤가"를 파악할 수 있도록 정리해 준다. 세부 수정은 결국 개발자가 해야 하지만, "어떤 항목이 문제고, 어떤 게 그나마 괜찮은가"를 알 수 있다. 개발자와 대화할 때의 시작점이 생긴다.

반응형 카드는 데스크톱(1920px), 태블릿(768px), 모바일(390px) 세 가지 화면 크기에서 실제로 어떻게 보이는지를 측정한다. 터치 타겟의 최소 크기(44×44px, WCAG 권고)를 충족하는지도 포함된다. 스마트폰에서 공공 웹사이트를 이용하는 비율이 늘고 있는 만큼, 모바일에서의 경험이 데스크톱과 얼마나 차이가 나는지가 중요해지고 있다.

이 두 카드는 '깊이 보려면 어렵지만, 개요를 잡는 건 도움이 된다'는 성격의 카드들이다. 전문가를 대체하는 게 아니라, 전문가와 이야기를 시작할 수 있는 맥락을 만들어 주는 역할이다.

AI 종합 리포트 — 24개를 한 편의 문서로

24번째 카드인 AI 종합 리포트는 앞선 23개 분석을 종합하여, AI가 하나의 서술 문서로 정리한 것이다.

점수표, 그래프, 리스트가 아니라 '문장'으로 쓴 리포트. "이 사이트는 KRDS 컴포넌트 준수 영역에서 특히 취약하며, 그 중에서도 입력 요소의 접근성 속성 미비가 반복적으로 나타납니다. 보안 헤더 설정은 일부 항목이 누락되어 있으나 SSL 인증서는 정상 적용되어 있습니다…" 같은 형태다.

이 리포트가 가장 쓸모 있는 순간은, 아직 기술적 맥락이 없는 독자와 소통해야 할 때다. 기관의 예산을 결재하는 결재권자, 업무를 막 인수받은 신임 담당자, 외부에서 자문을 요청받은 컨설턴트. 이런 독자들에게는 숫자보다 문장이 더 직관적이다.

AI가 쓴 리포트라는 것이 오히려 불안하게 느껴질 수 있다. 그래서 이 리포트에는 항상 참조패널이 함께 온다. 리포트의 어떤 서술이 어떤 분석 결과에서 왔는지, 근거가 추적 가능하다. "AI가 그렇게 썼으니까"가 아니라, "이 분석 카드의 이 결과를 서술하면 이렇게 된다"는 구조다.

물론 AI 리포트가 완벽하진 않다. 문장이 어색하거나, 강조점이 우리가 기대한 것과 달라질 수 있다. 담당자가 맥락에 맞게 수정하고 살을 붙여야 하는 부분이 남는다. 그럼에도 '맨땅'이 아니라 '초안'이 있다는 차이는 크다.

30대 후반 한국 여성 직원이 따뜻한 오후 빛이 드는 조용한 공간에서 인쇄된 분석 리포트를 사려 깊은 표정으로 읽고 있는 모습. 옆에는 채팅 화면이 열린 노트북이 있다. — 24개 분석이 하나의 리포트로 정리됐을 때. 숫자가 아니라 문장으로 읽을 수 있는 초안이 생긴다.

담당자의 하루가 어떻게 달라지는가 — 다시 주무관 A로

처음에 등장한 주무관 A로 돌아오자. 품질 점검 공문을 받고 막막했던 그 아침으로.

ViewCheck LLM 분석을 쓰기 전과 후의 차이를 '시간'으로 말하는 건 조심스럽다. "몇 시간을 아낀다"는 수치는 우리가 통제된 실험으로 확인한 것이 아니기 때문이다. 다만 '어떤 종류의 일이 달라지는가'는 이야기할 수 있다.

달라지는 것 1: 시작하는 데 드는 비용

전에는 어디서 시작해야 하는지 몰라 멈췄다. 도구를 찾고, 설치하고, 항목을 고르는 과정이 시작 전 장벽이었다. URL 한 줄로 시작이 된다는 것은, 그 장벽이 낮아진다는 것이다. 결과 구성에 대한 불확실성도 줄어든다. '이 분석을 돌리면 무엇이 나오는가'를 미리 알 수 있기 때문이다.

달라지는 것 2: '기다리는 동안'이 생긴다

분석이 자동으로 돌아가는 동안, 담당자는 다른 일을 할 수 있다. 이건 단순히 시간 배분의 문제가 아니다. 분석을 '내가 하나씩 해야 하는 일'이 아니라 '보내 놓고 기다리는 일'로 전환한다는 점에서 다르다. 멀티태스킹이 아니라 비동기적 처리가 가능해진다.

달라지는 것 3: 대화로 물을 수 있다

모르는 항목이 있을 때, 다시 도구를 찾아 확인하는 게 아니라 그 자리에서 물어볼 수 있다. "이 항목은 왜 미통과야?"라는 질문에, 근거를 담은 답이 온다. 이 '대화로 확인하는 루프'가, 혼자 답을 찾아 헤매는 시간을 줄인다.

달라지는 것 4: 전달 가능한 형태로 이미 나온다

24개 카드는 담당자 혼자 읽는 용도로만 만들어지지 않았다. 임원보고서는 윗선에 올릴 수 있게, 오류 리스트는 개발사에 넘길 수 있게, AI 종합 리포트는 외부 소통용 초안으로 쓸 수 있게 만들어진다. 결과를 다시 한 번 '번역'하는 작업이 줄어든다.

이 네 가지가 다 합쳐질 때, 담당자의 하루가 달라진다고 우리는 생각한다. 극적으로 달라지거나, 품질 점검이 갑자기 쉽고 즐거운 일이 된다는 뜻이 아니다. '막막한 시작' 대신 '어디서 시작할지가 있는 시작'이 되고, '결과를 만드는 일' 대신 '결과를 다듬는 일'이 되는 것. 그게 하루 단위에서 쌓이면 조금 다른 무게감이 생긴다.

달라지지 않는 것 — 우리가 대체하지 못하는 것

좋은 점만 이야기하면 정직하지 못한 글이 된다. 24개 카드가 나오고, 다중 페이지가 분석되어도, 담당자의 하루에서 달라지지 않는 것들이 있다.

최종 판단은 사람의 것이다. ViewCheck가 "이 항목 미통과"라고 해도, 그게 우리 사이트 맥락에서 얼마나 심각한 문제인지, 지금 당장 고쳐야 하는지 아니면 더 큰 개편 때 같이 다루어도 될지 — 이건 담당자가 판단해야 한다. AI가 제안하는 로드맵이 우리 조직의 일정, 예산, 우선순위와 맞지 않을 수도 있다. 맥락은 사람만이 안다.

근거는 확인해야 한다. RAG 구조로 근거를 제시하지만, 그 근거가 항상 완벽히 맞는다는 보장은 없다. 분석 결과를 중요한 보고서에 쓸 때는, 핵심 항목의 근거를 직접 확인하는 과정이 필요하다. "도구가 그렇다고 했으니까"만으로는 부족하다. 근거를 직접 읽고 판단하는 것, 그게 담당자의 역할로 남는다.

사람이 봐야만 알 수 있는 것은 여전히 남는다. 시각적으로 어색한 레이아웃, 맥락에 맞지 않는 이미지 사용, 언어적 뉘앙스의 문제 — 이런 건 자동 분석이 잡기 어렵다. 화면을 직접 보고 "이 느낌이 이상하다"라는 판단은 사람만이 할 수 있다. 자동화가 커버하지 못하는 영역이 있다는 걸 알고 활용하는 것이, 이 도구를 올바르게 쓰는 방법이다.

공공 웹의 품질 개선은 도구 하나로 끝나는 일이 아니다. 조직의 의지, 예산, 개발 역량, 지속적인 관리 — 이 모든 것이 맞물려야 한다. ViewCheck는 그 중에서 '진단'의 일부를 더 쉽게, 더 근거 있게 할 수 있게 돕는 도구다. 전부를 해결해 준다는 게 아니라, 더 나은 시작점을 만든다는 것이다.

KRDS 비교 카드 — 우리 사이트가 기준에서 얼마나 떨어져 있는가

KRDS 비교 카드는 공식 KRDS 기준과 현재 사이트 사이의 거리를 보여준다. 거리를 측정한다는 게 어떤 의미인가.

KRDS는 단순히 "이런 컴포넌트를 써라"는 가이드라인이 아니다. 각 컴포넌트와 패턴에 구체적인 스펙이 있다. 버튼의 최소 크기, 색상 토큰의 사용 방식, 폼 오류 안내의 위치와 형식 — 이런 것들이 규정되어 있다. KRDS 비교 카드는 "지금 사이트가 이 스펙들을 얼마나 따르고 있는가"를 보여준다.

행안부는 2025년 2월과 9월, 두 차례에 걸쳐 KRDS 설명회를 진행했다(행정안전부, 2025년 범정부 UI/UX 디자인시스템(KRDS) 설명회 자료 공지, 2025). 이 설명회에서 강조된 것 중 하나가 KRDS의 실제 적용 확산이었다. 가이드라인이 있는 것과 그게 실제로 적용되는 것 사이의 거리를 줄이는 것 — 그게 설명회의 목적 중 하나였다.

KRDS 비교 카드는 그 '거리'를 수치로 보여주는 시도다. 지금 이 사이트가 공식 KRDS 스펙에서 얼마나 벗어나 있는지. 어느 영역에서 가장 많이 벗어나 있는지. 이 수치를 기반으로 "우리 사이트를 KRDS 기준에 맞게 개선하는 데 어디서부터 시작하면 좋은가"라는 질문에 답하는 실마리가 생긴다.

완벽한 측정이라고는 말할 수 없다. KRDS의 일부 스펙은 시각적 판단이 필요한 영역이어서, 자동 분석으로는 확인하기 어렵다. 다만 판정 가능한 영역에서, 기준과의 거리를 객관적으로 보여주는 것 — 그 자체가 이 카드의 역할이다.

GOV.UK 디자인 시스템과의 비교로 보는 KRDS의 위치

KRDS를 이야기할 때, 해외 디자인 시스템과 비교해 보는 것이 맥락을 이해하는 데 도움이 된다.

영국의 GOV.UK 디자인 시스템은 정부 서비스의 일관성과 접근성을 끌어올리기 위해 2018년 공식 도입되었다(GDS, "Introducing the GOV.UK Design System", GDS Blog, 2018). GOV.UK 디자인 시스템은 현재 WCAG 2.2 AA 기준을 완벽하게 준수하며(GOV.UK Design System, Accessibility, 2024 감사 기준), 모든 컴포넌트와 패턴이 보조 기술 사용자를 포함한 다양한 사용자와 함께 테스트된다고 명시한다.

KRDS도 같은 방향을 지향한다. WCAG 적합성을 각 컴포넌트 페이지에 명시하고, 접근성을 기본값으로 설계에 내장한다. 2025년 6월 기준으로 GOV.UK 디자인 시스템 웹사이트 자체가 브랜드 리프레시를 거치면서 WCAG 2.2 AA 준수를 유지하고 있다는 점(GOV.UK Design System, 2025 brand refresh)은, 기준이 계속 살아 움직인다는 것을 보여준다.

ViewCheck의 KRDS 비교 카드는 이 국제적인 맥락 안에서 우리 사이트를 바라볼 수 있게 해준다. 단순히 "규칙을 통과했는가"가 아니라, "공공 디지털 서비스의 글로벌 기준에서 어떤 위치인가"를 함께 보는 것. 이 시각은, 점검을 내부 기준 충족의 문제가 아니라 사용자 경험의 문제로 연결하는 데 도움이 된다.

24번째 카드 이후 — 대화는 계속된다

24개 카드가 모두 나왔다고 분석이 끝나는 건 아니다. 오히려 24개가 나온 뒤부터, 더 구체적인 대화가 시작된다.

담당자는 카드를 읽다가 궁금한 게 생긴다. "이 규칙은 어떤 공식 문서에서 온 건가요?" 채팅창에 그냥 묻는다. 답이 온다. "우리 사이트 메인 페이지는 어떤 규칙에서 가장 많이 미통과인가요?" 또 묻는다. 특정 카드를 더 깊이 파고들어도 된다. "접근성 카드에서 나온 미통과 항목들 중 가장 시급한 것만 뽑아줘" 같은 요청을 할 수 있다.

이 후속 대화의 깊이와 정확도는, 솔직히 아직 매번 일정하지 않다. 어떤 질문은 기대했던 수준의 답이 나오고, 어떤 질문은 "좀 더 구체적으로 물어봐야겠다"라는 느낌이 드는 답이 온다. LLM의 일관성 문제는 우리도 잘 아는 과제이고, 그걸 어떻게 개선할지가 계속 연구 중인 주제다.

그럼에도, '후속 대화가 가능하다'는 것 자체는 이전의 도구들과 다른 경험이다. 결과를 받고 "이게 뭔지 모르겠는데 누구한테 물어보지"라는 막막함 대신, 그 자리에서 바로 물어볼 수 있는 창구가 있다는 것. 그 차이가, 담당자 입장에서 '혼자 해결하는 느낌'과 '같이 해결하는 느낌'을 만든다.

30대 한국 남성 공공기관 직원이 미니멀한 책상에서 노트북을 타이핑하며 커피잔 옆에 앉아 있는 평온하고 생산적인 늦은 오후 장면. — 24개가 다 나온 뒤에도, 대화는 계속된다. "왜?" "이건 어디서?" 그 질문들이 이어지는 자리.

트랙 G를 시작하며 — 활용편이 방법론편과 다른 이유

이 시리즈에서 트랙 G는 '활용'을 다룬다. 방법론을 다루는 트랙 A, 비교 분석을 다루는 트랙 B, 기능을 다루는 다른 트랙들과 성격이 다르다.

방법론편이 "우리는 이렇게 만들었고, 이렇게 설계했다"를 이야기한다면, 활용편은 "그 결과로 어떤 일이 생기는가"를 이야기한다. 기술이 아니라 기술이 닿는 사람의 자리를 본다.

그 관점에서 40편을 쓰면서 가장 많이 생각한 것은, 24개 카드가 담당자의 하루를 바꾸는 가장 큰 이유가 '많아서'가 아니라는 것이다. 24개가 한 번의 대화로 온다는 것, 그 순서와 구조가 진입점을 낮춘다는 것, 각 카드가 사람마다 다른 쓸모로 연결된다는 것. 그리고 카드가 끝이 아니라 시작이라는 것 — 뒤에 대화가 이어진다는 것.

이 시리즈를 쓰면서 우리도 많이 배운다. 실제로 어떤 카드에서 사람들이 오래 머무는지, 어떤 질문이 뒤에 이어지는지, 어떤 순간에 "이게 맞나?"라는 의심이 생기는지. 이 관찰들이 24개 카드를 조금씩 다듬는 근거가 된다.

완성됐다고 말할 수 없다. 다만 방향은 분명하다 — 담당자의 하루를 조금이라도 덜 막막하게, 조금이라도 더 근거 있게.

마무리 — 한 번의 대화가 남기는 것

URL 한 줄, 대화 한 번. 그리고 24개의 카드.

이게 끝나고 담당자의 책상 위에 남는 건 무엇인가. 점수표, 리스트, 리포트 초안 — 이런 것들이 물론 있다. 하지만 그것만이 아니다. "이 사이트가 지금 어느 상태인가"에 대한 공유된 이해, 개발사와 나눌 수 있는 공통 언어, 다음 예산안을 짤 때 쓸 수 있는 근거의 조각들 — 이것들이 남는다.

우리는 이 경험이 모든 담당자에게, 항상, 기대한 대로 작동한다고 말하지 않는다. 맥락이 다르고, 사이트가 다르고, 담당자가 찾는 것이 다르다. 어떤 경우에는 24개 중 한두 카드만 의미 있고, 어떤 경우에는 처음 세 카드면 충분하다. 어떤 경우에는 결과가 기대와 달라 다시 들여다봐야 한다.

그래도 우리가 여전히 이 실험을 계속하는 이유는, "담당자가 혼자 사이트 전체를 손으로 점검하는 것"이 갖는 한계가 분명하기 때문이다. 사람의 시간과 주의는 한정되어 있고, 공공 웹사이트는 하나씩 다루기에 복잡하고, 기준은 계속 바뀐다. 그 상황에서 "대화 한 번으로 24개를 받는" 경험이 줄 수 있는 것은 — 시간의 절약만이 아니라 '시작할 수 있음'의 여지다.

트랙 G 활용편은 계속된다. 다음 편에서는 실제 분석 결과를 보고서로 만드는 흐름, 개발사 커뮤니케이션에 쓰는 방법 같은 더 구체적인 장면들로 들어갈 예정이다. 이번 편이 '24개 카드를 받으면 어떤 일이 생기는가'의 큰 그림이었다면, 다음 편은 그 그림 안의 특정 장면을 확대하는 방식으로.

공공 웹의 품질을 대화로 묻고, 근거 있는 답을 받는 일. 우리는 아직 그 길을 가고 있는 중이다.

참고문헌

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

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

행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제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 디자인시스템) 공식 사이트. 행정안전부·디지털플랫폼정부위원회. https://www.krds.go.kr/
행정안전부, 「2025년 범정부 UI/UX 디자인시스템(KRDS) 설명회(2.20.) 자료 공지」. https://www.mois.go.kr/frt/bbs/type013/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000006&nttId=115763
행정안전부, 「2025년 하반기 범정부 UI/UX 디자인시스템(KRDS) 설명회(9.25.) 자료 공지」. https://www.mois.go.kr/frt/bbs/type013/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000006&nttId=120868

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

Nielsen Norman Group, "Progressive Disclosure", nngroup.com. (Jakob Nielsen, 1995년 최초 명명, NN/g 아티클). https://www.nngroup.com/articles/progressive-disclosure/
Nielsen Norman Group, "Few Guesses, More Success: 4 Principles to Reduce Cognitive Load in Forms". https://www.nngroup.com/articles/4-principles-reduce-cognitive-load/
Asana, "Anatomy of Work Index" — Context switching statistics and work about work data. https://asana.com/resources/anatomy-of-work-hub
Asana, "Context Switching Explained: Costs + 9 Fixes at Work" (2025). https://asana.com/resources/context-switching
Microsoft, "2025 Work Trend Index Annual Report" — AI productivity, 31,000 workers, 31 countries. https://www.microsoft.com/en-us/worklab/work-trend-index
W3C, "Web Content Accessibility Guidelines (WCAG) 2.2 is a W3C Recommendation" (2023. 10. 5.). https://www.w3.org/news/2023/web-content-accessibility-guidelines-wcag-2-2-is-a-w3c-recommendation/
W3C, "W3C Web Content Accessibility Guidelines 2.2 approved as ISO/IEC international standard" (2025). https://www.w3.org/press-releases/2025/wcag22-iso-pas/
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 — Accessibility (WCAG 2.2 AA, 2024년 7월 외부 감사). https://design-system.service.gov.uk/accessibility/