폼 한 칸도 규칙이 있다 — KRDS 108개 기본패턴 자동 검증 이야기

폼·필터·정렬·동의 화면, 그냥 만들면 안 되는 이유를 코드로 배운 기록

들어가며 — "이 폼, 왜 이렇게 만든 거지?"

공공기관 민원 신청 사이트를 써본 사람이라면 아마 한 번쯤 이런 경험이 있을 것이다. 열 개가 넘는 필드를 채우고 '제출' 버튼을 눌렀더니, "주민등록번호 형식이 올바르지 않습니다"라는 메시지가 페이지 맨 위에 조그맣게 떴다. 어느 필드가 문제인지는 알 수 없다. 다시 처음부터 찾아서 고쳐야 한다. 이번엔 됐나 싶어 또 제출 버튼을 눌렀더니, 이번엔 다른 필드에서 에러가 난다. 그걸 고치고 나면 또 다른 에러. 한 번에 모아 알려줬으면 될 것을, 한 개씩 나눠서 알려준다.

이쯤 되면 사용자는 화가 나는 게 아니라 지친다. 지쳐서 포기한다. 민원 신청을 포기하고, 직접 방문 신청을 선택하거나, 아예 포기한다.

이것이 우리가 KRDS의 기본 패턴(Basic Pattern) 영역에 관심을 갖기 시작한 이유다. '폼'이라는 건 UI의 가장 기초적인 요소처럼 보이지만, 실은 사용자가 서비스와 가장 직접적으로 대화하는 접점이다. 특히 공공 서비스에서 폼은 단순한 인터페이스가 아니라 시민이 행정과 교류하는 '창구'다. 그 창구가 어떻게 설계되어 있느냐가 서비스의 실질적 접근성을 결정한다.

KRDS는 이 기본 패턴 영역에 108개의 규칙을 두었다. 폼 구조부터 동의/확인, 오류 처리, 필터/정렬 패턴까지, "이런 상황에서 공공 서비스의 화면은 이렇게 동작해야 한다"는 기준을 담아 놓은 것이다. ViewCheck LLM 분석은 이 108개 규칙을 어떻게 자동으로 판정하는지, 그 과정에서 어떤 어려움이 있는지, 그리고 실제 분석 화면에서 어떻게 보이는지를 이번 편에서 솔직하게 풀어보려 한다.

미리 말해두자면, 108개를 100% 자동으로, 항상 정확하게 판정하는 건 아직 안 된다. 일부는 DOM을 봐야 하고, 일부는 눈으로 봐야 하고, 일부는 사용자가 실제로 상호작용해야만 알 수 있다. 그 한계를 포함해서 이야기하겠다.

소프트한 오피스-카페 조명 아래 노트북 웹 폼을 집중해서 작성하는 한국인의 모습. — 폼을 채우는 사람. 입력 한 칸 한 칸이 서비스와의 대화다. 그 대화가 얼마나 매끄러운지를 KRDS 기본 패턴이 정의한다.

KRDS 기본 패턴이란 무엇인가

KRDS(디지털 정부서비스 UI/UX 가이드라인)는 공공 웹과 앱의 UI/UX를 통일하기 위해 행정안전부·디지털플랫폼정부위원회가 운영하는 범정부 디자인 시스템이다. 이 시스템은 크게 스타일 → 컴포넌트 → 기본 패턴 → 서비스 패턴의 위계로 나뉜다.

여기서 **기본 패턴(Basic Pattern)**은 스타일이나 컴포넌트보다 한 단계 위의 이야기다. "버튼이 이런 색이어야 한다"(스타일)거나 "버튼에 이런 라벨이 있어야 한다"(컴포넌트)가 아니라, "이 버튼들이 모인 폼 화면이 어떤 구조와 동작 방식을 가져야 하는가"를 다루는 층위다.

KRDS 공식 사이트(krds.go.kr)는 기본 패턴 영역에서 대표적으로 다음을 다룬다.

입력 폼(Form): 단일 페이지 폼과 다단계 폼, 라벨 배치, 필수 항목 표시 방법, 도움말 텍스트, 진행 표시기 등
동의/확인: 개인정보 수집·이용 동의, 선택적 동의와 필수 동의의 구분, 전체 동의 구현 방식
오류 처리(Error Handling): 입력 오류 감지 시점, 오류 메시지의 위치와 내용, 복구 방법 안내
필터링·정렬: 데이터 목록에서 필터 컨트롤의 배치 방식, 적용 상태 표시, 정렬 옵션의 위치

이 네 가지가 ViewCheck가 BP(Basic Pattern) 카테고리로 분류하는 규칙들의 핵심 영역이다. 우리 측 실측 기준으로 이 영역에 할당된 규칙은 108개다.

왜 108개인가? KRDS 가이드를 규칙 형태로 쪼개는 과정에서, "이 가이드라인의 이 항목이 준수됐는지 자동으로 검사할 수 있는가"를 기준으로 구체화한 결과다. 가이드라인 원문이 곧 규칙은 아니다. 가이드라인의 항목 중에는 "상황에 맞게 판단하라"처럼 자동화하기 어려운 것도 많고, 반대로 하나의 항목이 여러 세부 검사 규칙으로 나뉘기도 한다. 그 과정 자체가 꽤 어렵고 지금도 계속 정제되고 있다.

왜 기본 패턴이 중요한가 — 폼은 서비스의 관문이다

기본 패턴이 왜 중요한지를 조금 더 구체적으로 따져보자. 공공 서비스에서 '폼'이 무엇을 의미하는지부터 생각해 보면 된다.

시민이 정부24에서 주민등록등본을 발급받으려 한다고 가정하자. 로그인 → 검색 → 발급 신청 폼 작성 → 제출 → 확인 → 수령. 이 흐름에서 사용자가 직접 손가락을 움직여야 하는 지점이 여러 군데 있는데, 그 대부분이 '폼'이거나 '동의/확인'이거나 '필터/정렬'이다. 검색 결과를 걸러보는 것도 필터이고, "제출 전 내 입력값이 맞는지 확인하세요"라는 화면도 패턴이다.

이 지점들이 나쁘게 설계되어 있으면, 서비스가 아무리 기술적으로 훌륭해도 사용자는 사용할 수 없다. 여기서 '사용할 수 없다'는 말은 과장이 아니다. 특히 고령자, 장애인, 디지털 리터러시가 낮은 시민에게 잘못 설계된 폼은 물리적 장벽이 된다. 마우스를 눌러 텍스트를 선택할 수 없는 사람, 화면 확대 도구를 쓰는 사람, 키보드만으로 화면을 탐색하는 사람에게, 폼 오류 메시지가 눈에 잘 띄지 않는 회색 텍스트로 나온다면 그건 그 사람에게 서비스가 '닫혀 있는' 것과 같다.

닐슨 노먼 그룹(Nielsen Norman Group, 이하 NN/g)은 웹 폼의 사용성에 관해 오랫동안 연구해 왔다. NN/g의 대표적 연구 "Website Forms Usability: Top 10 Recommendations"는 이렇게 지적한다. 폼 사용성 가이드라인을 따른 폼과 그렇지 않은 폼을 비교했을 때, 가이드라인을 따른 폼에서 사용자가 첫 시도에 오류 없이 제출하는 비율이 78%인 반면, 위반한 폼에서는 42%에 그쳤다는 것이다(Nielsen Norman Group, "Website Forms Usability: Top 10 Recommendations"). 거의 두 배 차이다. 그리고 이건 UX 전문가의 고급 사이트가 아니라 일반적인 웹 폼 실험에서 나온 수치다.

물론 이 수치를 공공 서비스 폼에 그대로 적용하는 건 무리다. 공공 서비스는 맥락이 다르고, 사용자 프로필도 다르고, 폼의 복잡도도 다르다. 그래도 "폼 설계가 성공률을 좌우한다"는 결론은 충분히 공유 가능하다. 우리가 108개 규칙을 쪼개서 자동으로 검사하려 하는 이유의 출발점도 거기다. 공공 서비스의 폼을 더 잘 설계하려면, 먼저 지금 어떻게 설계되어 있는지를 빠르게 파악할 수 있어야 한다.

108개 규칙의 구성 — 무엇을 보는가

ViewCheck가 BP 카테고리에서 검사하는 108개 규칙을 전부 나열하는 건 이 글의 목적이 아니다. 대신 "어떤 종류의 것들을 보는가"를 크게 네 묶음으로 정리해 보겠다.

1. 입력 폼 구조

폼의 레이아웃과 구조에 관한 규칙이다. KRDS 공식 가이드는 "콘텐츠는 가능한 한 하나의 열에 수직으로 정렬하라"고 명시한다(KRDS, '입력폼 | 기본 패턴'). 여러 열에 폼 요소를 나란히 배치하면 눈의 이동 경로가 복잡해지고, 화면이 작아졌을 때 레이아웃이 무너지기 쉽기 때문이다.

라벨의 위치도 중요하다. NN/g는 오랜 연구를 통해 필드 위에 라벨이 있는 경우가 옆에 있는 경우보다 가독성과 완성 속도 모두에서 유리하다는 걸 거듭 확인했다(NN/g, "Website Forms Usability"). 특히 화면을 확대해서 쓰는 사용자, 화면 독자(screen reader)를 쓰는 사용자에게 라벨 위치는 콘텐츠의 논리적 순서를 결정하는 핵심 요소가 된다.

필수 입력 항목 표시 방식도 규칙에 들어간다. 별표(*)를 사용하는 경우, 그 별표의 의미를 폼 어딘가에 반드시 설명해야 한다. 이건 WCAG의 성공 기준(SC 3.3.2: 레이블 또는 지시문)과도 맞닿아 있고, KWCAG 2.2에도 동일한 취지의 기준이 있다(W3C, "Understanding SC 3.3.2: Labels or Instructions | WAI | W3C").

다단계 폼의 경우, 진행 표시기(progress indicator)가 얼마나 적절하게 구현되어 있는지도 살핀다. 사용자가 현재 전체 과정 중 어디에 있는지를 알 수 없으면 불안감이 생기고, 예상치 못하게 과정이 길어지면 이탈로 이어진다. KRDS는 다단계 폼에서 진행 상태를 명확히 보여줄 것을 명시하고 있다.

2. 동의/확인 패턴

공공 서비스에서 개인정보 수집·이용 동의는 거의 모든 신청 폼에 등장한다. KRDS는 이 동의 UI에 대한 구체적인 패턴을 제시한다. 필수 항목과 선택 항목을 구분해야 하고, '전체 동의' 기능을 제공하는 경우 선택 항목만 일괄 동의되도록 해야 하며, 각 항목의 상세 내용을 볼 수 있는 방법을 제공해야 한다.

확인(Check Answers) 패턴도 여기에 속한다. 영국 GOV.UK 디자인 시스템은 이 패턴을 'Check answers'로 명확하게 정의한다. 사용자가 모든 입력을 마쳤을 때, 제출 전에 자신의 답변을 한 화면에서 검토하고 수정할 수 있어야 한다는 것이다(GOV.UK Design System, "Check answers"). 그 화면에서 '뒤로 가서 수정'이 가능해야 하고, 수정 후 돌아왔을 때 이미 입력한 값이 그대로 있어야 한다. 이걸 공공 서비스에서 제대로 구현한 사례가 의외로 드물다. ViewCheck는 이런 확인 패턴이 구현되어 있는지를 체크 항목 중 하나로 포함한다.

3. 오류 처리 패턴

여기서부터는 이 시리즈를 쓰면서 우리 팀이 가장 많이 들여다본 영역이다. 오류 처리 패턴은 기술적인 구현의 문제인 동시에, 사용자의 감정 경험과 직결된다. 오류 메시지를 어떻게 보여주느냐는 "사용자가 이 서비스를 포기하느냐, 계속 쓰느냐"에 영향을 미친다.

NN/g의 "10 Design Guidelines for Reporting Errors in Forms"는 오류 처리에 관한 10가지 가이드라인을 제시한다(NN/g, "10 Design Guidelines for Reporting Errors in Forms"). 그 핵심을 정리하면:

명확성: 오류 메시지는 어느 필드가 문제인지 명시적으로 알려야 한다. "형식이 올바르지 않습니다" 같은 모호한 메시지는 사용자에게 도움이 되지 않는다.
가시성: 오류는 눈에 잘 띄어야 한다. 색상 하나로만 표시하는 건 충분하지 않다(색맹 사용자를 위해). 아이콘, 텍스트, 위치가 함께 작동해야 한다.
시점: 오류를 너무 일찍 보여주는 것도 문제다. 사용자가 아직 입력 중인데 "이 필드는 필수입니다"라고 뜨는 건 불필요한 압박을 준다. 반면 너무 늦게, 즉 제출 후에만 알려주는 것도 인터랙션 비용을 높인다.
복구 지원: 오류 메시지는 단순히 "틀렸다"를 알리는 게 아니라, "어떻게 고쳐야 하는지"를 말해야 한다. "이메일 형식으로 입력하세요(예: name@example.com)" 같은 구체적 안내가 그냥 "올바른 이메일을 입력하세요"보다 훨씬 낫다.

WCAG 2.2는 이를 성공 기준으로 명시한다. SC 3.3.1(Error Identification): 입력 오류가 자동으로 감지된 경우, 오류가 발생한 항목을 식별하고 텍스트로 설명해야 한다(Level A). SC 3.3.3(Error Suggestion): 입력 오류가 감지되고 수정 방법을 알 수 있는 경우, 그 제안을 사용자에게 제공해야 한다(Level AA)(W3C, "Understanding SC 3.3.1: Error Identification | WAI | W3C").

ViewCheck는 이 WCAG 기준과 KRDS 오류 처리 패턴을 연결해서 BP 규칙들을 정의했다. 예를 들어 특정 페이지에 폼이 있고, 그 폼에 오류 메시지가 있지만 어느 필드의 오류인지 연결되어 있지 않다면, 관련 규칙이 '미통과'로 판정된다.

4. 필터링·정렬 패턴

필터와 정렬은 데이터 목록 페이지에서 핵심적인 탐색 도구다. 공공 서비스에서는 공지사항 목록, 법령 검색 결과, 민원 현황 목록 같은 곳에서 자주 등장한다. 사용자가 원하는 정보를 빠르게 좁혀 찾을 수 있도록 돕는 UI다.

KRDS는 필터링·정렬에 대해 이렇게 정의한다. "데이터 집합에서 사용자가 원하는 속성과 범주에 속하는 데이터 항목을 선별적으로 표시하거나, 특정 속성/범주를 기준으로 조직화하는 방법으로, 데이터 목록에서 탐색할 범위를 좁혀 원하는 정보를 찾는 시간을 줄일 수 있다"(KRDS, '필터링·정렬 | 기본 패턴'). 필터 컨트롤의 배치 위치(목록 상단, 좌측, 우측), 적용된 필터 조건의 표시 방식, 개별 조건 해제 버튼 등이 구체적으로 가이드된다.

NN/g는 필터와 정렬 UX에 대한 연구도 많이 쌓아왔다. 특히 이커머스 검색에서 패싯 필터링(faceted filtering)을 다룬 연구는 공공 서비스 목록 UI에도 시사점이 크다(NN/g, "Ecommerce Search User Experience" 리포트, 139가지 팁). 필터 상태가 시각적으로 명확히 표시되어야 하고, 현재 어떤 필터가 적용됐는지, 그것을 어떻게 해제하는지 사용자가 즉시 파악할 수 있어야 한다는 것이다.

ViewCheck의 BP 규칙 중 필터링 관련 항목들은 "적용된 필터가 화면에 표시되고 있는가", "개별 필터 해제가 가능한가", "정렬 옵션이 목록 상단에 명확하게 제공되는가" 같은 체크 포인트를 포함한다.

자동으로 판정하기 — 가능한 것과 불가능한 것

이론상 108개를 전부 자동으로 검사할 수 있다면 좋겠지만, 현실은 그렇지 않다. BP 영역에서 자동화가 가능한 부분과 그렇지 않은 부분을 솔직하게 정리해 보자.

자동화가 잘 되는 것들

DOM 구조를 분석해서 파악할 수 있는 것들은 자동화가 상대적으로 잘 된다.

폼 요소의 라벨 연결: <label>과 <input>이 for/id로 연결되어 있는지, 또는 aria-label·aria-labelledby로 연결되어 있는지는 DOM을 보면 바로 알 수 있다.
필수 항목 표시: required 속성 또는 aria-required="true"가 있는지, 그에 대한 설명 텍스트가 폼 근방에 있는지를 확인할 수 있다.
오류 메시지와 입력 필드의 연결: ARIA 속성 aria-describedby를 통해 오류 메시지가 어떤 필드에 연결되어 있는지 확인할 수 있다.
필터 컨트롤의 존재와 구조: 페이지에 필터 패널이 있는지, 체크박스 그룹이나 드롭다운이 어떤 구조로 있는지 DOM에서 파악 가능하다.
다단계 폼의 진행 표시기: 스텝(step) 또는 진행 표시 영역이 있는지, 현재 단계가 시각적으로 표시되는지를 부분적으로 확인할 수 있다.

자동화가 어려운 것들

반면 "사람이 눈으로 보거나 직접 조작해봐야 알 수 있는" 영역은 자동화가 쉽지 않다.

오류 메시지의 품질: "올바르지 않습니다"라는 메시지가 기술적으로는 존재하고 연결도 되어 있지만, 사용자에게 충분한 정보를 주는지 여부는 사람이 내용을 읽어봐야 안다. DOM 분석으로 메시지 텍스트를 읽을 수는 있지만, "이 메시지가 충분히 구체적인가"를 자동으로 판단하기는 어렵다.
오류 표시 시점: 사용자가 입력 중에 오류 메시지가 나타나는지, 아니면 제출 후에 나타나는지는 실제로 사용자가 타이핑하고 포커스를 이동시켜 봐야 알 수 있다. 정적인 DOM 분석으로는 불가능하다.
동의/확인 패턴의 완성도: "제출 전 확인" 페이지가 있는지는 사이트를 실제로 탐색해봐야 알 수 있다. ViewCheck가 크롤링하는 페이지에 그 화면이 포함되어 있지 않으면 확인이 안 된다.
필터 상호작용 후 결과 업데이트: 필터를 선택하면 목록이 적절히 업데이트되고 결과가 표시되는지는 실제로 필터를 클릭해봐야 안다.

이 '할 수 없는 것들'은 ViewCheck가 해당없음(N/A)으로 표시하거나, Playwright를 이용한 동적 상호작용 테스트로 일부 보완하고 있다. 다만 완전한 자동화가 가능한 영역은 아직 아니다. 이것이 BP 카테고리의 판정률이 다른 카테고리보다 상대적으로 낮은 이유 중 하나다.

증적 화면 — 실제 분석에서 BP가 어떻게 보이나

ViewCheck LLM 분석의 실제 화면을 보면 BP 카테고리 결과가 어떻게 표시되는지 알 수 있다.

ViewCheck LLM 분석에서 KRDS 기본 패턴(BP) 108개 규칙의 판정 결과가 카드로 펼쳐진 실제 프로덕션 캡처. — ViewCheck LLM 분석의 기본 패턴(BP) 결과 화면. 108개 규칙의 통과/미통과/해당없음 분포와 주요 위반 항목이 카드 형태로 표시된다. — 실제 분석 화면

분석 카드에는 BP 카테고리의 전체 규칙 수, 통과 수, 미통과 수, 해당없음 수가 요약되어 보이고, 그 아래로 미통과된 규칙들이 우선순위 순으로 나열된다. 규칙 ID(예: BP-012), 규칙 이름, 위반 내용, 적용된 페이지, 그리고 가능하면 "어떻게 고쳐야 하는가"에 해당하는 개선 가이드가 함께 표시된다.

LLM 분석 특성상, 사용자는 이 결과를 보고 바로 채팅으로 "BP-012 규칙이 왜 미통과인지 자세히 설명해줘"라고 질문할 수 있다. 그러면 해당 규칙의 KRDS 원문 내용, 위반된 페이지의 어떤 요소가 문제인지, 그리고 수정 방향이 대화로 이어진다. 오른쪽 참조패널에는 KRDS 관련 조항이 함께 뜬다.

이런 인터랙션이 가능한 것이 LLM 분석의 강점 중 하나라고 생각한다. 단순히 결과 목록을 던져주는 게 아니라, 결과를 이해하고 행동으로 옮기는 데까지 이어지는 대화를 만드는 것. 물론 이게 항상 잘 된다고 말하기는 어렵다. 때로는 LLM이 규칙을 과도하게 해석하거나, 맥락을 잘못 파악하는 경우도 있다. 그래서 참조패널을 항상 함께 보여주고, 사용자가 원문을 직접 확인할 수 있게 하는 것이 중요하다.

폼 구조 자동 검사 — 구체적으로 어떻게 작동하나

DOM을 분석해서 폼 구조를 검사하는 과정을 조금 더 구체적으로 들여다보자.

ViewCheck의 크롤러는 Playwright로 페이지를 렌더링한 다음, DOM 전체를 추출한다. 이 추출 과정에서 폼 관련 요소들(form, input, select, textarea, fieldset, legend, label 등)과 이들의 속성, 그리고 ARIA 속성들을 수집한다.

수집된 데이터를 바탕으로 BP 규칙 체크 함수들이 실행된다. 예를 들어 "모든 입력 필드에 라벨이 연결되어 있는가"를 검사하는 규칙은 대략 이런 흐름으로 작동한다.

페이지의 모든 input/select/textarea 요소를 순회
  → 각 요소에 대해:
    - <label for="...">으로 연결된 라벨이 있는가?
    - aria-label 속성이 있는가?
    - aria-labelledby로 가리키는 요소가 있고, 그 요소에 텍스트가 있는가?
    - 위 세 조건 중 하나라도 충족하면 → 통과
    - 하나도 충족하지 않으면 → 미통과
    - input이 존재하지 않는 페이지라면 → 해당없음

이 로직은 단순해 보이지만, 실제로는 세부 예외가 많다. type="hidden" 인풋은 라벨이 없어도 된다. type="submit" 버튼도 자신의 value가 라벨 역할을 하므로 별도 라벨이 없어도 된다. 같은 필드 그룹 내에서 fieldset/legend가 그룹 전체의 라벨 역할을 하는 경우도 있다. 이런 예외를 얼마나 정확하게 처리하느냐가 규칙의 품질을 결정한다.

오류 처리 검사도 비슷한 흐름이다. "폼이 있는 페이지에서 오류 메시지가 접근 가능한 방식으로 제공되는가"를 검사하는 경우, 먼저 현재 페이지에 폼이 있는지 확인하고, 오류 상태 관련 ARIA 속성(role="alert", aria-invalid, aria-describedby를 통한 오류 메시지 연결 등)이 사용되고 있는지를 확인한다. 그리고 오류 메시지 텍스트가 실제로 존재하는지도 확인한다.

여기서 한계가 분명히 있다. DOM이 '준비된 상태'의 스냅샷이라 실제 오류가 발생한 상태에서의 DOM을 보는 게 아니기 때문이다. 폼에 오류 처리 코드가 있어도, 오류가 발생하지 않은 초기 상태에서는 오류 메시지 요소가 숨겨져 있거나 아예 없을 수 있다. 이 경우 ViewCheck는 "해당없음"으로 처리하거나, 코드 패턴으로 오류 처리 로직이 존재하는지를 추론하는 방식을 쓴다. 완전한 판정이라기보다는 '신호 탐지'에 가깝다.

태블릿 화면의 필터·정렬 인터페이스를 조작하는 손의 클로즈업. 자연광, 얕은 심도. — 태블릿에서 필터와 정렬을 다루는 손. 그 조작이 KRDS 기준에 맞게 설계되어 있는지, 자동으로 들여다보는 것이 BP 검사의 목표다.

GOV.UK와 USWDS에서 배운 것들 — 비교 관점

기본 패턴을 어떻게 검사할지를 설계하면서, 우리는 해외 공공 디자인 시스템의 패턴 정의도 많이 들여다봤다. 특히 영국의 GOV.UK 디자인 시스템과 미국의 USWDS(U.S. Web Design System)는 오랜 시간 실제 서비스에 적용되며 다듬어진 사례라 참고 가치가 높다.

GOV.UK의 오류 처리 원칙은 명확하다. "에러 메시지는 질문이나 필드셋 라벨의 언어를 직접 포함해야 한다"는 것(GOV.UK Design System, "Error message"). 이렇게 하면 사용자가 에러 메시지를 읽었을 때 어느 필드의 이야기인지 바로 연결된다는 것이다. 메시지는 평이한 영어(plain English)로 쓰고, 무슨 일이 생겼는지를 설명하며 어떻게 고치면 되는지 알려주어야 한다. 그리고 중요한 규칙: 검증은 사용자가 '계속'이나 '제출' 버튼을 누를 때까지 기다려야 한다 — 사용자가 필드 안에서 타이핑하는 도중에 에러를 표시하지 말 것(GOV.UK Design System, "Recover from validation errors").

GOV.UK의 'Check Answers' 패턴 정의는 더 구체적이다. 트랜잭션이 제출 버튼을 누르기 전까지 완료되지 않는다는 것을 명확히 해야 하고, 제출 버튼에는 그 액션이 무엇인지 명확하게 써야 한다. 선택적 질문에서 답을 안 했을 경우 'Not provided'라고 표시해야 하며, 사용자가 수정하러 돌아간 뒤 다시 확인 페이지로 돌아왔을 때는 나머지 과정을 다시 거치지 않아도 된다(GOV.UK Design System, "Check answers").

미국 USWDS의 폼 검증 패턴은 또 다른 시각을 제공한다. USWDS는 "사용자가 특정 필드와 상호작용을 마친 후에만 오류 검증 메시지나 스타일을 표시하라"고 명시한다(USWDS, "Validation"). 즉, 초기 페이지 로드 시 모든 필드가 에러 상태로 표시되는 것을 피하라는 것이다. 또한 검증 메시지는 인풋 필드와 시각적으로 정렬되어야 한다 — 화면 확대 도구를 쓰는 사용자가 빠르게 읽을 수 있도록. 그리고 검증 요구사항을 미리 제시하면 사용자가 추측할 필요가 없다.

이런 사례들을 보면서 우리가 느낀 건, KRDS가 이 흐름과 꽤 정합적이라는 점이었다. KRDS도 GOV.UK나 USWDS와 비슷한 철학을 갖고 있다. 다만 구체화 수준이나 검증 가이드라인의 밀도에서 차이가 있고, 그 차이를 어떻게 채울지가 KRDS를 검사 도구로 만드는 과정에서 판단해야 하는 지점이었다.

예를 들어 GOV.UK는 에러 메시지에 대해 매우 구체적인 작성 지침을 제공한다. KRDS는 오류 메시지가 있어야 한다는 패턴 수준의 가이드를 제시하지만, 그 메시지의 내용 품질에 대한 가이드는 GOV.UK보다 덜 구체적이다. ViewCheck의 자동 검사는 KRDS 기준을 먼저 따르되, WCAG·KWCAG의 관련 성공 기준을 보조 기준으로 사용한다.

사용성 연구가 말하는 것 — NN/g의 오류 메시지 연구

NN/g의 오류 메시지 관련 연구는 UI 개발자와 디자이너 모두에게 실용적인 기준을 제공한다. NN/g는 10 가지 사용성 휴리스틱 중 5번째 휴리스틱(H5: 오류 예방, Error Prevention)에서 이렇게 설명한다. 오류 예방에는 두 가지 유형이 있다. 하나는 무의식적 실수(slip, 부주의로 발생하는 오류)이고, 다른 하나는 의도적 실수(mistake, 사용자의 멘탈 모델과 시스템 사이의 불일치). 이 두 유형을 방지하기 위해서는, 전자는 "도움이 되는 제약과 좋은 기본값"을 제공하고, 후자는 "기억 부담을 줄이고 되돌리기(undo)를 지원하고 경고를 제공"하는 방향으로 설계해야 한다(NN/g, "10 Usability Heuristics for User Interface Design").

NN/g가 오류 메시지 관련 아티클들에서 반복해서 강조하는 원칙 중 하나는 **"적대적 패턴(hostile patterns)을 피하라"**는 것이다(NN/g, "Hostile Patterns in Error Messages"). 사용자가 아직 입력 중인데 즉시 오류를 표시하거나, 사용자를 비난하는 어투를 쓰거나, 에러 코드를 그대로 노출하거나, 오류를 눈에 띄지 않는 방식으로 표시하는 것이 모두 '적대적 패턴'에 해당한다. 이런 패턴들은 사용자에게 "이 서비스는 나를 도와주는 게 아니라 시험하는 것"이라는 인상을 준다. 공공 서비스에서는 특히 문제다. 민원인이 서비스 앞에서 느끼는 심리적 위압감이 이미 있는데, UI까지 불친절하면 이탈과 포기로 이어진다.

NN/g의 연구는 또 "오류 메시지는 여러 단서(cues)를 조합해 눈에 띄게 해야 한다"고 강조한다. 색상만으로는 부족하다. 색맹 사용자에게는 색상이 정보를 전달하지 못한다. 아이콘, 테두리, 텍스트 강조, 위치 이동 같은 복수의 시각적 단서를 함께 써야 한다. 이것은 KWCAG 2.2의 '색에 무관한 정보 인식' 원칙과도 연결된다.

우리가 BP 규칙 중 오류 처리 관련 항목을 정의할 때 이 연구들을 많이 참고했다. 특히 "오류 메시지가 ARIA 속성으로 필드와 연결되어 있는가"는 접근성 기준이기도 하지만, 동시에 NN/g가 강조하는 '명확성(어느 필드의 오류인지 알 수 있어야 한다)'과도 완전히 일치한다. 기술적 접근성 기준과 사용성 연구가 같은 방향을 가리킬 때, 그 규칙은 비교적 설득력 있게 정의될 수 있다.

다중 페이지에서 BP 검사 — 한 페이지만 봐서는 안 되는 이유

BP 카테고리 검사에서 가장 중요한 것 중 하나는, 어떤 페이지를 검사하느냐가 결과를 결정한다는 점이다.

폼은 보통 메인 페이지에 없다. 신청 페이지, 회원가입 페이지, 이의신청 페이지, 예약 페이지에 있다. 필터와 정렬은 목록 페이지에 있다. 동의/확인은 신청 과정의 중간 단계에 있다. 메인 페이지만 분석하면 BP 규칙의 상당 부분이 "해당없음"으로 처리될 수밖에 없다.

이게 ViewCheck가 다중 페이지 분석을 기본값으로 설계한 이유 중 하나다. 메인 외에 다양한 유형의 페이지 — 검색, 목록, 상세, 신청, 로그인 — 를 골고루 크롤링해야, BP 규칙이 의미 있게 판정될 기회가 생긴다.

물론 사이트에 신청 폼이 있어도 ViewCheck가 그 폼에 도달하지 못하는 경우가 있다. 로그인이 필요한 페이지, 세션 기반으로만 접근 가능한 페이지, 특정 상호작용 후에만 나타나는 다이얼로그 같은 것들이 그렇다. 이런 '깊은 곳'의 폼은 자동 크롤링으로 접근하는 데 한계가 있다. 솔직히 말하면, 이 부분은 아직 연구 중인 영역이다. 완전한 자동화가 어려운 이유 중 하나이기도 하다.

그래서 ViewCheck의 BP 분석 결과를 볼 때는 "해당없음이 많으면 해당 폼 페이지가 크롤링에 포함됐는지 확인해야 한다"는 맥락을 함께 이해하는 게 중요하다. 해당없음이 많다고 해서 사이트의 폼이 잘 만들어진 것이 아니라, 단순히 그 페이지를 보지 못한 것일 수 있다. 이 한계를 명확히 알려주는 게, 우리가 결과 화면에서 '해당없음'의 의미를 풀어서 설명하려 하는 이유다.

유리 벽에 포스트잇이 붙어 있고, UX 연구자가 사용자가 폼을 작성하는 것을 관찰하는 사무실 장면. — 유저 리서처가 사용자의 폼 작성을 관찰하는 장면. 자동화 검사가 잡지 못하는 것들을 사람이 봐야 하는 순간이 있다.

BP 검사 결과가 실제로 의미하는 것 — 숫자 뒤의 맥락

분석 결과에서 "BP: 통과 55 / 미통과 16 / 해당없음 37"이라는 숫자를 봤다고 가정하자(이건 실제 서울시 메인 페이지 분석 예시다). 이 숫자를 어떻게 읽어야 할까.

미통과 16개: 이건 "BP 규칙 중 16개가 명확하게 위반을 감지했다"는 뜻이다. 이 16개는 실제로 수정이 필요한 항목으로 봐도 된다. 다만 16개 모두가 같은 중요도인 건 아니다. 접근성에 직접 영향을 미치는 것(폼 라벨 누락, 오류 메시지 연결 누락)이 있고, 레이아웃이나 정렬 방식처럼 UX 개선 수준의 것도 있다. ViewCheck는 이를 우선순위(P0~P3)로 구분해 표시한다.

해당없음 37개: 이 수가 크다면, 그 페이지에 검사 대상 UI 요소(폼, 필터, 동의 화면 등)가 많지 않다는 뜻일 수 있다. 메인 페이지는 원래 폼이 드물기 때문에 해당없음이 많은 게 정상이다. 하지만 신청 페이지임에도 해당없음이 많다면, 크롤러가 폼 요소를 제대로 감지하지 못했을 가능성이 있다.

통과 55개: 통과한 규칙들이 어떤 것들인지는 결과 카드를 열어서 확인할 수 있다. 단순히 "통과"로만 표시하는 것보다는, "이 항목이 통과된 이유" — 즉 어떤 조건을 충족했기 때문에 통과인지 — 를 볼 수 있어야 담당자가 참고할 수 있다. 우리는 통과 근거도 가능한 한 제공하려 하지만, 미통과 근거보다는 덜 상세한 경우가 많다. 이것도 개선해야 할 영역이다.

전체적으로, BP 결과 숫자를 볼 때는 "미통과가 몇 개다"보다 "미통과된 것들이 어떤 유형이고, 어느 페이지에서 발생했는가"를 보는 것이 더 유용하다. 같은 유형의 오류가 여러 페이지에서 반복된다면, 그건 사이트 전체의 패턴 문제이고 우선적으로 고쳐야 한다. 한 페이지에서만 발생하는 오류라면 해당 페이지 담당자에게 직접 전달하면 된다. LLM 분석의 '일관성' 카드가 이런 사이트 전체의 패턴을 보여주는 역할을 한다.

어려운 지점 — 필터 검사의 함정

BP 카테고리 중에서도 우리가 특히 어렵게 여기는 부분이 필터링·정렬 검사다. 이유를 솔직하게 적어두겠다.

필터와 정렬은 상호작용이 있어야 의미가 있다. 필터 UI가 화면에 있더라도, 그것이 실제로 "선택하면 목록이 업데이트된다"는 방식으로 동작하는지 여부는 직접 클릭해봐야 알 수 있다. DOM만 봐서는 "필터처럼 생긴 요소가 있다"까지만 알 수 있고, 그게 실제로 필터로 동작하는지는 별개의 문제다.

더 복잡한 건, 필터의 구현 방식이 사이트마다 다양하다는 것이다. 어떤 사이트는 순수 HTML 폼으로 필터를 구현한다. 어떤 사이트는 JavaScript 기반 동적 필터를 쓴다. 어떤 사이트는 React나 Vue 같은 프레임워크로 만들어진 SPA(Single Page Application) 방식이다. DOM 구조와 동작 방식이 다 달라서, "이게 필터다"를 인식하는 것부터가 쉽지 않다.

ViewCheck는 이를 패턴 매칭으로 접근한다. 특정 CSS 클래스명, 역할(role) 속성, 구조적 패턴(체크박스 그룹 + 레이블 + 결과 목록이 인접해 있는 패턴 등)을 기반으로 "이건 아마 필터 UI"라고 추론한다. 하지만 이 추론이 항상 맞는 건 아니다. 공공 사이트 중에는 표준 패턴에서 벗어난 독자적 구현이 많다. 오래된 사이트일수록 더 그렇다.

이 문제는 KRDScan 엔진(Vision AI)으로 일부 보완하려 하고 있다. 스크린샷을 보고 "이 영역에 필터처럼 보이는 UI가 있는지"를 시각적으로 감지하는 것이다. 하지만 Visual AI가 "이게 필터다"라고 판단하는 것도 틀릴 수 있고, 그 판단을 어떤 BP 규칙에 연결할지도 복잡하다. 이 영역은 솔직히 아직 연구 중이라고 표현하는 게 맞다.

KWCAG와의 연결 — 기본 패턴과 접근성 지침

BP 규칙들은 단독으로 서 있지 않다. 많은 경우 KWCAG(한국형 웹 콘텐츠 접근성 지침) 2.2와 직접적으로 연결된다.

예를 들어 폼의 라벨 연결 문제는 KWCAG 2.2의 "입력 항목에 적절한 레이블을 제공해야 한다" 기준에 해당한다. 오류 처리 문제는 KWCAG의 "사용자 오류를 예방하고 수정할 수 있어야 한다" 기준과 연결된다. 색상만으로 정보를 전달하는 문제는 "색에 무관하게 콘텐츠를 인식할 수 있어야 한다" 기준에 해당한다.

이런 연결을 명시하는 것이 중요한 이유가 있다. 담당자에게 "BP-xxx가 미통과됐습니다"라고 말하면, 그게 KRDS의 내부 코드일 뿐이고 실무에서 어떤 의미인지 바로 연결되지 않는다. 하지만 "이 항목은 KWCAG 2.2의 X 기준에 해당하며, 행안부 지침의 접근성 영역과 직접 연결됩니다"라고 설명하면 담당자가 외주 개발사에 "이 기준을 왜 맞춰야 하는지"를 설명하는 근거가 생긴다.

ViewCheck는 BP 미통과 항목에 대해 가능한 경우 KWCAG 항목 번호와 행안부 지침의 어떤 영역에 해당하는지를 함께 표시하려 한다. 아직 모든 규칙에 대해 이 연결이 완성된 건 아니지만, 방향은 그쪽이다. "규칙 번호 하나"가 아니라 "기준들 사이의 연결"을 보여주는 것이 실무에서 더 유용하기 때문이다.

담당자 입장에서 BP 결과 활용하기

BP 분석 결과를 실제로 어떻게 써야 하는지, 담당자 입장에서 생각해 보자.

가장 먼저 해야 할 일은 미통과 항목의 우선순위 확인이다. P0(서비스 운영 자체에 영향)이나 P1(접근성 직결)에 해당하는 항목이 있다면, 그것부터다. 폼 라벨이 없거나 오류 메시지가 전혀 제공되지 않는 경우가 여기에 해당한다. 이런 항목은 KWCAG와 WCAG 2.2 기준으로 봤을 때 사실상 '장애인 배제'에 해당하며, 법적 의무와도 연결된다.

다음으로는 반복 패턴 확인이다. 같은 유형의 미통과 규칙이 여러 페이지에서 나타난다면, 그건 템플릿 또는 공통 컴포넌트의 문제다. 한 페이지씩 수정하는 게 아니라, 공통 컴포넌트를 한 번 고치는 것으로 다수 페이지를 한꺼번에 개선할 수 있다. ViewCheck의 '일관성' 카드와 '위반 매트릭스' 카드가 이런 반복 패턴을 파악하는 데 도움을 준다.

그다음은 개선 로드맵과 연결이다. BP 미통과 항목들을 P0~P3 우선순위로 정렬하고, 각 항목의 예상 수정 공수(MM)와 함께 보면 어디서부터 시작해야 하는지 보인다. ViewCheck의 '비용·MM' 카드와 '개선 로드맵' 카드가 이 단계를 지원한다.

마지막으로, 외주 개발사와의 소통에 BP 결과를 활용할 수 있다. "이 규칙이 미통과입니다. KRDS XX 기준, WCAG SC 3.3.1 기준에 해당합니다. 어떤 요소가 어떤 조건을 충족하지 못했습니다. 수정 방향은 이렇습니다." 이런 구체적인 내용이 있으면, 개발사에 "사이트 접근성 좀 봐주세요"라는 막연한 요청보다 훨씬 명확한 지시가 된다. 그리고 수정 후 재검사로 "이게 고쳐졌는지" 확인할 수 있다.

필터·정렬 패턴을 잘 만든다는 것

이번에는 좀 다른 각도에서 필터·정렬을 이야기해 보자. "어떻게 검사하느냐"보다 "왜 잘 만드는 게 중요한가"를 먼저 이해하면 검사의 의미가 더 잘 들어온다.

사용자가 공공 기관 홈페이지에서 지원 사업을 찾는다고 가정해 보자. 수백 개의 사업이 목록으로 나온다. 필터가 없으면? 스크롤을 내리며 하나씩 읽어야 한다. 지역별, 대상별, 신청 기간별로 필터를 제공하면? 지원 가능한 사업 목록이 수십 개로 좁혀진다. 이 차이가 사용자의 서비스 이용 경험 전체를 바꾼다.

KRDS는 이 필터링·정렬 패턴에서 몇 가지 명확한 기준을 제시한다. 적용된 필터 조건이 화면에 표시되어야 하고, 각 조건을 개별적으로 해제할 수 있어야 한다. 조건에 해당하는 데이터 항목의 수를 보여줘야 한다. 정렬 옵션은 목록 상단에 명확하게 위치해야 한다. 이 기준들이 얼마나 당연해 보이느냐와 무관하게, 실제 공공 사이트를 분석해 보면 이 당연한 것들이 지켜지지 않는 경우가 생각보다 많다.

NN/g의 이커머스 검색 UX 연구는 필터·정렬의 핵심을 이렇게 요약한다. 사용자는 검색 결과에서 원하는 것을 '발견'하기 위해 필터를 쓰는데, 이 발견 경험이 성공적이려면 필터의 상태가 항상 투명하게 보여야 한다는 것이다(NN/g, "Ecommerce Search User Experience"). "내가 지금 어떤 조건으로 보고 있는가"가 명확해야 사용자가 탐색에 집중할 수 있다. 이 원칙은 이커머스뿐 아니라 공공 서비스 목록에도 동일하게 적용된다.

ViewCheck가 필터 관련 BP 규칙을 검사할 때 가장 기본으로 확인하는 것이 바로 이 '상태의 가시성'이다. 적용된 필터가 시각적으로 표시되는가, 그것을 해제하는 방법이 명확한가. 이 두 가지만 해도 많은 공공 사이트가 미통과한다. 기술적으로 어려운 게 아니라, 신경을 쓰지 않았기 때문이다.

동의/확인 패턴 — 공공 서비스의 특수성

기본 패턴 중에서 공공 서비스에 특히 중요한 영역이 '동의/확인'이다. 개인정보 수집·이용 동의 화면은 거의 모든 공공 온라인 신청에 등장하는데, 이것이 얼마나 명확하고 접근 가능하게 만들어져 있느냐는 법적 의미를 가진다.

「개인정보 보호법」은 정보주체(시민)가 개인정보 수집·이용에 자유롭게, 구체적으로, 명확하게 동의해야 한다는 원칙을 명시한다. 필수 항목과 선택 항목을 구분하지 않거나, '전체 동의' 버튼 하나로 모든 것을 묶어버리는 구현은 법적으로도 문제가 될 수 있다.

KRDS는 이런 법적 요구와 UX 기준을 통합한 패턴을 제시한다. 필수 항목과 선택 항목을 시각적으로 명확히 구분하고, 각 항목의 내용을 펼쳐 볼 수 있는 UI를 제공하며, 전체 동의를 클릭했을 때 선택 항목도 포함되는지 아니면 필수만 포함되는지를 명확히 표시해야 한다는 것이다.

ViewCheck는 동의 UI가 있는 페이지를 분석할 때 이 구분이 DOM 구조에서 확인 가능한지를 체크한다. 예를 들어 각 동의 항목이 required와 그렇지 않은 것으로 표시되어 있는지, 전체 동의 체크박스가 다른 항목들과 어떤 구조적 관계인지 등이다. 단, 이 분석도 동의 화면이 크롤링된 페이지에 포함되어야 한다는 전제가 있다. 로그인 후에만 접근 가능한 동의 화면은 외부 자동 크롤러로는 접근하기 어렵다.

사용성 테스트와 자동화의 관계

이쯤 되면 한 가지 질문이 자연스럽게 생긴다. "자동화 검사로 폼 문제를 발견할 수 있다면, 사용성 테스트는 왜 해야 하는가?"

이 질문에 대한 우리의 솔직한 답은 이렇다. 자동화 검사와 사용성 테스트는 서로 보완하는 것이지, 하나가 다른 하나를 대체하는 게 아니다. 자동화 검사는 빠르고, 반복 가능하고, 많은 규칙을 한꺼번에 확인할 수 있다. 하지만 "사용자가 실제로 폼을 쓸 때 어디서 막히는가"는 자동화로 파악하기 어렵다.

NN/g의 사용성 테스트 연구들은 반복해서 이 점을 보여준다. 전문가 검사(expert review)로 발견할 수 있는 문제의 유형과, 실제 사용자 테스트(usability testing)로 발견하는 문제의 유형이 다르다는 것이다(NN/g, "A Usability Test With a Participant Filling Out a Form"). 전문가 검사는 표준 위반, 구조적 문제, ARIA 누락 같은 것을 잘 잡는다. 사용자 테스트는 "예상 밖의 인식 오류", "언어의 불명확함", "맥락의 혼란"처럼 직접 관찰해야 알 수 있는 것들을 잡는다.

ViewCheck의 BP 자동 검사는 전자에 해당한다. KRDS 기준의 구조적 준수 여부를 빠르게 확인하고 우선순위를 잡는 데 유용하다. 그 위에 실제 사용자 테스트를 더하면 더 완전한 그림이 나온다. 우리는 ViewCheck가 사용성 테스트를 대체한다고 생각하지 않는다. 다만 "어디를 테스트해야 하는가"를 좁혀주는 도구로는 충분히 역할을 한다고 생각한다.

참가자가 폼을 작성하고 관찰자가 메모를 취하는 사용성 테스트 장면. 자연광. — 사용자가 폼을 작성하는 동안 관찰자가 메모를 취하는 사용성 테스트. 자동화 검사가 잡지 못하는 것을 사람이 보는 시간.

다단계 폼과 진행 표시기 — 복잡한 신청 경험

공공 서비스의 온라인 신청은 대개 다단계다. "개인정보 입력 → 신청 내용 입력 → 첨부파일 → 동의 → 확인 → 제출 → 완료" 같은 흐름이 일반적이다. 이 흐름이 길수록, 사용자가 현재 전체 중 어디에 있는지를 아는 것이 중요해진다.

KRDS는 다단계 폼에서 진행 표시기(progress indicator 또는 step indicator)를 제공할 것을 명시한다. 진행 표시기는 단순히 "몇 단계 중 몇 단계"를 표시하는 것을 넘어, 사용자가 이미 완료한 단계로 쉽게 돌아갈 수 있는 기능도 포함한다. 이게 잘 구현되어 있을 때, 사용자는 예상치 못한 곳에서 "앗, 빠뜨린 게 있다"고 해도 다시 처음부터 하지 않아도 된다.

ViewCheck는 다단계 폼이 있는 페이지에서 진행 표시기의 존재 여부와 현재 단계 표시 여부를 확인하는 BP 규칙을 포함한다. 다만 다단계 폼의 각 단계를 크롤러가 모두 방문하는 건 어렵다. 보통 세션 기반으로 진행되기 때문이다. 첫 단계 페이지는 볼 수 있어도, 그다음 단계로 넘어가려면 첫 단계를 완료해야 하는 경우가 많다. 그래서 다단계 폼 관련 BP 규칙 중 일부는 "해당없음" 처리되거나 불완전한 판정이 나오는 경우가 있다. 이 한계는 명시적으로 인정한다.

인라인 검증(Inline Validation) — 적시에 피드백 주기

오류 처리 패턴 중에서 특히 많이 논의되는 것이 인라인 검증(inline validation)이다. 사용자가 필드 입력을 마치는 순간, 그 필드의 오류나 성공 여부를 즉시 표시하는 방식이다.

NN/g는 이상적으로는 "모든 검증이 인라인으로 이루어져야 한다"고 강조한다. 인라인 검증이 되면 사용자가 이미 잊고 있던 필드로 돌아가서 고치는 인터랙션 비용이 줄어든다(NN/g, "10 Design Guidelines for Reporting Errors in Forms"). 서버로 데이터를 보낸 후 에러를 받아야 하는 경우에도, 에러 메시지는 명확하고 찾기 쉬워야 한다.

하지만 인라인 검증도 잘못 구현하면 오히려 해가 된다. 사용자가 입력 중일 때 오류를 표시하면 — 예를 들어 이메일 주소를 입력하는 도중 "@" 기호가 아직 안 입력됐다고 즉각 오류를 표시하면 — 이건 적대적 패턴(hostile pattern)이 된다. 타이핑 중에 오류를 표시하는 것과, 필드를 떠난 후 오류를 표시하는 것은 사용자 경험이 완전히 다르다. USWDS도 이 점을 명확히 한다. "사용자가 특정 필드와 상호작용을 마친 후에만" 검증 메시지를 표시하라는 것이다(USWDS, "Validation").

ViewCheck의 BP 규칙 중 인라인 검증 관련 항목은 정적 DOM 분석으로는 완전히 판정하기 어려운 영역이다. 인라인 검증이 구현되어 있는지를 코드 패턴으로 추론할 수는 있어도, 그것이 '적절한 시점에' 작동하는지는 실제로 상호작용해봐야 알 수 있다. 이 영역은 현재 Playwright를 이용한 동적 테스트로 부분적으로 보완하고 있다.

공공 서비스 폼의 현실 — 왜 이렇게 된 걸까

분석을 하다 보면 "왜 이 폼은 이렇게 만들어진 걸까" 하는 의문이 든다. 접근성 기준도 있고, KRDS 가이드도 있고, 사용성 연구도 있는데, 실제 공공 사이트의 폼이 이런 기준을 충족하지 못하는 경우가 많은 이유가 뭘까.

여러 원인이 복합적으로 작용하는 것 같다. 하나는 외주 개발 구조의 문제다. 공공 사이트는 대부분 외주 개발로 만들어진다. 기능적으로 동작하면 납품 완료로 처리되는 경우가 많고, 접근성이나 UX 패턴 준수 여부는 별도로 검수되지 않는 경우도 있다. 명세서에 "KRDS 기본 패턴 준수"가 명시되어 있지 않으면, 개발사가 이를 자발적으로 챙기기는 어렵다.

또 하나는 업데이트의 어려움이다. 처음 사이트를 만들 때는 어느 정도 신경을 썼더라도, 이후 유지보수 과정에서 폼이 추가되거나 변경되면서 일관성이 무너지는 경우가 많다. KRDS가 도입된 이후에도, 이전에 만들어진 폼 컴포넌트들이 그대로 남아 있는 사례가 많다.

세 번째는 담당자의 전문성 갭이다. 공공기관의 웹사이트 운영 담당자는 대부분 IT 전문가가 아니다. "폼 라벨이 있어야 한다"는 기준을 알아도, 그것이 어떻게 구현되어야 하는지를 개발사에 명확히 요구하는 건 다른 역량이다. 여기서 ViewCheck 같은 도구가 "어떤 규칙이, 어떤 이유로, 어떻게 고쳐져야 하는지"를 구체적으로 제시해 줄 수 있다면, 담당자와 개발사 사이의 소통에 다리 역할을 할 수 있다.

BP 영역에서 우리가 잘 모르는 것들

이 시리즈 전체의 톤이 "우리가 연구하고 있다"이고, 이 편도 그 원칙을 따른다. BP 영역에서 우리가 아직 잘 모르거나 해결 중인 것들을 솔직하게 정리해 보자.

첫째, "충분한 오류 메시지"의 기준을 어떻게 자동화할 것인가. 메시지가 있는지 없는지는 자동으로 확인할 수 있다. 하지만 그 메시지가 사용자에게 충분한 정보를 주는지 여부는 현재 사람이 판단해야 한다. LLM이 오류 메시지 텍스트를 읽고 "이게 충분한가"를 판단하게 하는 실험을 하고 있지만, 이 판단의 신뢰도를 어떻게 확보할지는 아직 연구 중이다.

둘째, 동적 상호작용 패턴을 어느 수준까지 자동 테스트할 것인가. Playwright로 폼을 실제로 채우고 제출해 보는 테스트는 가능하다. 하지만 어떤 값을 채워야 하는지, 그 결과를 어떻게 판정할지가 복잡하다. 각 사이트마다 폼의 내용이 다르기 때문에 범용적인 자동 테스트 케이스를 만들기가 어렵다.

셋째, 필터 UI를 얼마나 정확하게 인식하는가. 앞서 말했듯 패턴 매칭으로 필터 UI를 추론하는데, 이 추론의 정확도가 얼마나 되는지 정확히 실측하기가 어렵다. 우리가 "필터 있음"이라고 판정한 것이 실제로 필터인지, "해당없음"이라고 처리한 것에 사실 필터가 있는 건 아닌지를 검증하려면 수작업이 필요하다.

넷째, 다단계 폼의 각 단계를 자동으로 탐색하는 방법. 세션 기반 폼 탐색은 일반적인 웹 크롤링 방식으로는 어렵다. 이걸 어떻게 해결할지는 아직 명확한 답이 없다.

이런 한계들이 BP 카테고리의 N/A 비율을 높이는 원인이다. 그리고 이것들을 줄여가는 것이 앞으로의 과제다. 여기서 중요한 건, N/A가 많다고 해서 그냥 넘어가는 게 아니라, 그 N/A가 어떤 이유로 발생했는지를 명확히 표시하고 사용자가 이해할 수 있도록 하는 것이다.

LLM이 BP 분석에서 하는 역할

이 시리즈가 'LLM 분석' 홍보 블로그라는 점에서, LLM이 BP 분석에서 어떤 역할을 하는지를 짚어야 한다.

BP 규칙의 판정 자체는 LLM이 하지 않는다. KRDS 기준을 if/else 로직으로 구현한 규칙 엔진(KRDSrule)이 DOM 데이터를 받아 판정한다. LLM이 "이 폼은 오류 처리가 부실하다"고 독자적으로 판단하는 게 아니라, 규칙 엔진이 "BP-xxx 규칙의 조건 A가 충족되지 않았다"고 판정한 결과를 받아서 정리하고 대화로 전달한다.

LLM이 주로 하는 역할은 두 가지다.

첫째, 결과를 자연어로 설명한다. 규칙 엔진이 "BP-027: 오류 메시지와 입력 필드 연결 없음"이라고 판정하면, LLM은 이것을 "이 페이지의 로그인 폼에서 비밀번호 입력 필드가 오류 상태일 때 표시되는 오류 메시지가 해당 필드와 ARIA 속성으로 연결되어 있지 않습니다. 이 경우 화면 독자(screen reader)를 사용하는 사용자에게 오류가 어디서 발생했는지 전달되지 않을 수 있습니다. aria-describedby 속성으로 오류 메시지와 필드를 연결하거나, role='alert'를 사용하는 것을 고려하세요"와 같이 풀어준다.

둘째, 후속 질문에 답한다. 사용자가 "이 오류 메시지 문제를 왜 고쳐야 하는지 개발사에 설명할 자료가 필요해"라고 하면, WCAG 기준과 KRDS 패턴을 참조해 근거를 정리해 준다. RAG(Retrieval-Augmented Generation)를 통해 관련 공식 문서가 참조패널에 함께 표시된다.

이 두 역할에서 LLM이 '환각(hallucination)'을 일으킬 위험이 항상 있다. 없는 기준을 지어내거나, 판정 근거를 잘못 연결하거나, 수정 방법이 실제로는 잘못된 것일 수 있다. 그래서 RAG로 공식 문서를 검색해 근거를 붙이고, 참조패널을 통해 원문을 확인할 수 있게 하는 것이 필수적이다. LLM이 말하는 것을 무조건 믿지 말고, 옆에 뜨는 참조 문서를 함께 확인하는 습관이 필요하다. 이건 우리가 제품을 통해 전달하려는 메시지이기도 하다.

자연광 아래 노트북 화면에 깔끔한 다단계 폼 진행 표시기가 클로즈업으로 보이는 모습. — 다단계 폼의 진행 표시기. 사용자가 전체 과정 중 어디에 있는지 알게 해주는 이 작은 UI가 KRDS 기본 패턴의 핵심 항목 중 하나다.

공공 서비스에서 '패턴'이 왜 중요한가 — 표준화의 가치

마지막으로, 조금 더 큰 그림으로 이야기해 보자. KRDS 기본 패턴이 왜 존재하는가, 그리고 그것을 자동으로 검사하는 것이 왜 의미가 있는가.

패턴(pattern)이라는 개념 자체가 "이 상황에서 이렇게 하면 잘 된다는 것이 반복적으로 확인된 해법"을 뜻한다. 모든 서비스가 폼 오류 처리를 각자 다르게 구현하면, 사용자는 서비스를 쓸 때마다 "이 서비스에서는 오류가 어떻게 표시되지?"를 새로 배워야 한다. 반면 모든 공공 서비스가 KRDS 패턴을 따른다면, 한 서비스에서 배운 것이 다른 서비스에서도 통한다. 이것이 디자인 시스템이 추구하는 일관성의 가치다.

GOV.UK 디자인 시스템이 잘 된 이유 중 하나로 꼽히는 것도 이 일관성이다. 영국 정부의 수백 개 서비스가 같은 패턴을 쓰기 때문에, 한 서비스를 익힌 사용자가 다른 서비스를 쓸 때도 낮은 학습 비용으로 이용할 수 있다(GOV.UK Design System 공식). 접근성을 중앙 디자인 시스템에서 한 번 제대로 해결하면, 그것을 따르는 모든 서비스에서 접근성이 보장된다는 것도 같은 맥락이다.

KRDS가 국내 공공 서비스에서 그 역할을 하려면, 먼저 그 기준이 실제로 지켜지고 있는지를 확인할 수 있어야 한다. ViewCheck의 BP 자동 검사는 그 확인 과정을 빠르고 반복 가능하게 만들려는 시도다. 완벽하지 않고 아직 많은 한계가 있지만, "실측 없이는 개선도 없다"는 원칙 위에서 계속 정제해 나가고 있다.

마무리 — 폼 한 칸, 그냥 만들면 안 되는 이유

폼은 가장 작아 보이는 UI지만, 사용자가 서비스와 실제로 '거래'하는 창구다. 이름을 입력하고, 날짜를 선택하고, 동의하고, 제출하는 그 과정이 매끄러우면 서비스는 신뢰를 얻는다. 어디서 오류가 나는지 알 수 없고, 수정해도 다시 오류가 나고, 결국 포기해야 한다면 그 사이트는 '민원 창구'가 아니라 '장벽'이 된다.

KRDS 기본 패턴 108개 규칙은 이 창구를 최소한 이 정도는 되어야 한다는 공공 서비스의 기준선이다. ViewCheck LLM 분석은 그 기준선을 URL 한 줄을 채팅에 넣는 것만으로 빠르게 확인할 수 있게 하려는 시도다. 아직 부족한 점이 많고, 자동화로 잡지 못하는 영역도 많다. 그래도 "수백 페이지를 사람이 일일이 들여다보지 않고도 패턴 위반을 빠르게 파악한다"는 목표 자체는 유효하다고 생각한다.

다음 편에서는 KRDS 서비스 패턴(SP) 영역으로 넘어간다. 검색, 로그인, 신청, 정책 안내처럼 서비스 단위의 흐름이 어떻게 검증되는지, 그리고 그 검증이 왜 '게이트(Gate) 3중 체크' 방식으로 구현됐는지를 이야기할 예정이다. 기본 패턴이 'UI 요소의 동작 방식'이라면, 서비스 패턴은 '사용자가 목표를 달성하는 전체 흐름'을 다룬다. 다음 편에서 이어가겠다.

참고문헌

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

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

행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025. 6. 25. 일부개정). 국가법령정보센터. https://www.law.go.kr/%ED%96%89%EC%A0%95%EA%B7%9C%EC%B9%99/%EC%A0%84%EC%9E%90%EC%A0%95%EB%B6%80%20%EC%9B%B9%EC%82%AC%EC%9D%B4%ED%8A%B8%20%ED%92%88%EC%A7%88%EA%B4%80%EB%A6%AC%20%EC%A7%80%EC%B9%A8
KRDS(디지털 정부서비스 UI/UX 가이드라인) 공식 — 입력폼 | 기본 패턴. 행정안전부·디지털플랫폼정부위원회. https://www.krds.go.kr/html/site/global/global_08.html
KRDS(디지털 정부서비스 UI/UX 가이드라인) 공식 — 필터링·정렬 | 기본 패턴. https://www.krds.go.kr/html/site/global/global_10.html
행정안전부, 「전자정부 웹사이트 품질관리 가이드」 수정본 안내(2025). https://www.mois.go.kr/frt/bbs/type013/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000006&nttId=118639
한국형 웹 콘텐츠 접근성 지침(KWCAG) 2.2. https://a11ykr.github.io/kwcag22/

해외 — 디자인 시스템 / UX 연구 / 접근성 기준

Nielsen Norman Group, "Website Forms Usability: Top 10 Recommendations". https://www.nngroup.com/articles/web-form-design/
Nielsen Norman Group, "10 Design Guidelines for Reporting Errors in Forms". https://www.nngroup.com/articles/errors-forms-design-guidelines/
Nielsen Norman Group, "10 Usability Heuristics for User Interface Design" (H5: Error Prevention, H9: Help Users Recognize, Diagnose, and Recover from Errors). https://www.nngroup.com/articles/ten-usability-heuristics/
Nielsen Norman Group, "Hostile Patterns in Error Messages". https://www.nngroup.com/articles/hostile-error-messages/
Nielsen Norman Group, "Error-Message Guidelines". https://www.nngroup.com/articles/error-message-guidelines/
GOV.UK Design System, "Error message" — 에러 메시지 작성 원칙 및 접근성 기준. Government Digital Service. https://design-system.service.gov.uk/components/error-message/
GOV.UK Design System, "Recover from validation errors" — 검증 오류 처리 패턴. https://design-system.service.gov.uk/patterns/validation/
GOV.UK Design System, "Check answers" — 제출 전 확인 패턴. https://design-system.service.gov.uk/patterns/check-answers/
GOV.UK Design System, "Patterns" — 패턴 목록 전체. https://design-system.service.gov.uk/patterns/
U.S. Web Design System (USWDS), "Validation" — 폼 검증 패턴. https://designsystem.digital.gov/components/validation/
W3C WAI, "Understanding Success Criterion 3.3.1: Error Identification" (WCAG 2.2, Level A). https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html
W3C WAI, "Understanding Success Criterion 3.3.2: Labels or Instructions" (WCAG 2.2, Level A). https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions.html
W3C WAI, "Understanding Success Criterion 3.3.3: Error Suggestion" (WCAG 2.2, Level AA). https://www.w3.org/WAI/WCAG21/Understanding/error-suggestion
Nielsen Norman Group, "Ecommerce Search User Experience" (필터·정렬 UX, 139가지 팁 포함 리포트). https://www.nngroup.com/reports/ecommerce-ux-search-including-faceted-search/