로그인·검색·신청 — 공공 서비스의 '진짜 관문'을 어떻게 진단할까

KRDS 172개 서비스패턴 규칙과 DOM·OCR·URL 3중 Gate로 실험한 이야기

들어가며 — 민원인은 메인 페이지를 보러 오지 않는다

공공 웹사이트를 처음 방문한 사람이 마주치는 화면이 무엇인지 생각해 보자. 그 사람이 그 사이트에 온 이유는 대부분 분명하다. 무언가를 검색하거나, 신청 서류를 내거나, 본인임을 인증하고 나서야 볼 수 있는 정보를 확인하거나. 그 목적지에 이르기까지, 그는 반드시 서비스 흐름이라는 관문을 통과해야 한다.

그런데 많은 공공 웹 품질 점검은 여전히 메인 페이지에 집중한다. 시각적으로 완성도 있고, 접근하기 쉽고, 로딩이 빠르다. 그러나 로그인 화면에서 본인확인이 세 번 실패하거나, 검색창에 아무것도 입력하지 않은 채 엔터를 눌렀을 때 오류 메시지가 없거나, 신청 양식의 필드가 스크린 리더에게 묵묵부답이라면, 그 사이트는 '잘 만들어진 메인 뒤에 숨어 있는 장벽'을 가진 셈이다.

우리가 서비스 패턴(Service Pattern, SP) 진단에 주목하는 이유가 바로 이것이다. KRDS 846규칙 중 172개가 서비스 패턴 카테고리에 배정된 것은 우연이 아니다. 로그인, 검색, 신청, 정책 정보 확인이라는 네 가지 흐름은, 공공 서비스 이용자가 실제로 '무언가를 이루어야 하는' 장면이고, 그 장면에서 무너지는 품질은 메인 페이지의 어떤 오류보다 훨씬 직접적으로 시민의 경험을 해친다.

이번 편에서는 ViewCheck LLM 분석이 이 서비스 패턴 영역을 어떻게 진단하는지를 이야기한다. 구체적으로는, DOM만 들여다보는 것으로는 왜 부족한지, 그래서 우리가 OCR과 URL을 함께 끌어들여 '3중 Gate'라 부르는 판정 방식을 실험하게 된 이유를 솔직하게 풀어볼 것이다. 아직 완성된 이야기가 아니다. 솔직히 말하면, SP 진단은 우리가 846규칙 중에서 가장 어렵다고 느끼는 영역이다. 그 어려움을 구체적으로 설명하는 것 자체가 이 편의 목적이기도 하다.

따뜻한 조명이 드는 집에서 한국인 시민이 노트북으로 정부 온라인 서비스에 로그인하는 모습. — 로그인 화면은 공공 서비스의 첫 번째 '진짜 관문'이다. 여기서 막히면, 그다음 단계는 존재하지 않는다.

KRDS가 서비스 패턴을 어떻게 정의하는가

KRDS(디지털 정부서비스 UI/UX 가이드라인)의 공식 사이트를 들여다보면, 서비스 패턴이라는 카테고리가 무엇을 담으려는 개념인지 꽤 분명하게 설명되어 있다.

서비스 패턴은 "컴포넌트나 기본 패턴보다 더 큰 단위"다. 버튼 하나, 폼 하나의 이야기가 아니라, 사용자가 특정 목적을 달성하기 위해 거쳐야 하는 일련의 흐름 전체를 다루는 개념이다. KRDS는 이 흐름을 크게 네 가지로 분류한다.

첫째, 검색(Search). 사용자가 필요한 정보나 서비스를 찾는 전체 과정이다. 검색창에 키워드를 입력하는 것에서 시작해, 자동완성 제안, 검색 결과 목록 확인, 상세 검색, 재검색, 결과 없음 처리, 검색 종료에 이르기까지의 흐름이 여기에 포함된다(KRDS 공식, '개요 | 서비스 패턴 - 검색', krds.go.kr).

둘째, 로그인(Login). 사용자의 신원을 확인하는 과정이다. 로그인 안내 화면에서 시작해, 로그인 방식 선택(아이디·비밀번호, 간편인증, 공동인증서 등), 본인확인, 성공/실패 처리, 로그아웃에 이르기까지 여러 단계로 구성된다. KRDS는 이를 "사용자의 신원 확인 및 권한 부여를 위한 필수적인 과업"으로 정의하며, "로그인 링크는 항상 로그인 화면과 연결되어야 한다"는 기본 원칙을 포함한다(KRDS 공식, '개요 | 서비스 패턴 - 로그인', krds.go.kr).

셋째, 신청(Application). 사용자가 서비스 제공 기관에 요구사항을 알리기 위해 서식을 작성하는 과업이다. KRDS는 신청을 "관련 법률에 명시된 종류의 민원 외에, 사용자가 특정한 내용을 요청하는 모든 행동을 포함한다"고 폭넓게 정의한다. 신청 대상 탐색, 서식 작성, 확인, 완료에 이르기까지의 단계를 아우른다(KRDS 공식, '개요 | 서비스 패턴 - 신청', krds.go.kr).

넷째, 정책 정보 확인(Policy Information). 정책과 관련된 각종 자료를 통해 궁금증을 해결하거나 사업·서비스 참여에 도움이 되는 내용을 확인하는 과정이다(KRDS 공식, '개요 | 서비스 패턴 - 정책 정보 확인', krds.go.kr).

이 네 가지 흐름에 대해, KRDS는 각 단계별로 필수·권장·우수 세 수준의 적용 가이드라인을 제시한다. 필수 수준이 가장 기본이고, 이를 우선 충족한 뒤 권장·우수 수준으로 점진적으로 확장한다는 구조다.

ViewCheck의 SP 규칙 172개는 이 네 가지 흐름 전반을 아우른다. 그런데 이 172개를 자동으로 판정한다는 것이 말처럼 쉬운 일이냐 하면, 전혀 그렇지 않다. 그 이유를 하나씩 짚어보자.

왜 서비스 패턴이 가장 진단하기 어려운 영역인가

846개 KRDS 규칙 중에서, 우리가 분석을 통해 체감하기에 DS(디자인 스타일)와 SP(서비스 패턴)는 성격이 정반대다.

DS는 숫자의 세계다. 버튼의 높이가 44px인가, 색상의 대비비가 4.5:1 이상인가, 폰트 사이즈가 14px 이상인가. 이런 것들은 CSS computed value를 읽거나 픽셀을 재면 명확하게 판정된다. "이 요소의 computed background-color가 #FFFFFF이고, foreground가 #777777이므로, 대비비 계산 결과 4.48:1로 기준 미달"이라는 식으로. 판정의 근거가 수치이기 때문에, 자동화 친화적이다.

반면 SP는 '흐름'과 '맥락'의 세계다. "이 사이트에 검색 기능이 존재하는가"는 DOM을 보면 어느 정도 알 수 있다. 그런데 "그 검색이 결과 없음 상황에서 적절한 안내를 제공하는가", "로그인 실패 시 원인을 구체적으로 안내하는가", "신청 완료 후 처리 현황을 확인할 수 있는 수단이 제공되는가" 같은 것들은, 단순히 DOM 구조를 봐서는 알 수가 없다. 그 기능이 실제로 작동하는지, 특정 상황에서 어떤 화면이 나타나는지를 봐야 하기 때문이다.

게다가 서비스 패턴 규칙은 페이지 유형 의존성이 매우 높다. SP-로그인 규칙은 로그인 페이지가 있는 사이트에서만 의미가 있고, SP-신청 규칙은 신청 양식이 있는 페이지에서만 적용된다. 메인 페이지 하나만 크롤링하면, 172개 SP 규칙 대부분이 "해당없음(N/A)"이 되어 버린다. 그러나 이 N/A가 과연 "이 사이트에 해당 서비스 흐름이 없기 때문에 정당한 N/A"인지, 아니면 "크롤러가 그 페이지를 방문하지 못해서 생긴 분석의 공백"인지를 구분하는 것 자체가 쉽지 않다.

이것이 우리가 SP 진단에 특수한 접근법이 필요하다고 판단한 이유다.

3중 Gate라는 개념 — DOM만으로는 부족하다는 인정에서

ViewCheck가 SP 규칙 판정에 도입한 접근을 우리는 내부적으로 '3중 Gate'라고 부른다. 구체적으로는 DOM → OCR → URL 세 가지 신호를 순서대로, 또는 병렬로 활용해 판정의 신뢰도를 높이는 방식이다.

첫 번째 Gate: DOM

DOM은 가장 직접적인 신호다. 페이지의 HTML 구조를 파싱하면, 어떤 폼 요소가 있고, 어떤 ARIA 속성이 붙어 있으며, 어떤 버튼이 어떤 레이블을 가지는지를 알 수 있다. SP 규칙 중 구조 검증에 해당하는 것들은 이 DOM Gate에서 판정된다.

예를 들어 "로그인 폼에 <label> 요소가 각 입력 필드와 올바르게 연결되어 있는가", "신청 양식에 필수 입력 필드 표시(required 속성 또는 * 텍스트)가 있는가", "검색 입력 필드에 role="searchbox" 또는 type="search" 속성이 있는가" 같은 것들이다. 이런 규칙들은 DOM만 봐도 판정할 수 있다.

그러나 DOM Gate에서 판정 가능한 SP 규칙은 전체 172개 중 일부에 불과하다. 나머지는 DOM만으로는 "해당없음"이나 "판정 불가"로 남는다.

두 번째 Gate: OCR

DOM이 멈추는 지점에서 OCR(광학 문자 인식)이 나선다. 페이지의 스크린샷에서 텍스트를 추출하면, DOM이 잡아내지 못한 시각적 정보를 얻을 수 있다.

예를 들어, 어떤 공공 사이트는 <input type="image"> 버튼을 사용하거나, 이미지로 된 버튼 라벨을 HTML 텍스트 대신 쓰는 경우가 있다. 이런 경우 DOM을 파싱하면 그 버튼의 텍스트가 보이지 않는다. 그런데 스크린샷의 OCR 결과에는 "로그인", "검색", "신청하기" 같은 텍스트가 나타난다. 이 정보를 통해 "이 페이지에 로그인 관련 기능이 존재한다"는 신호를 얻을 수 있고, 그 신호를 SP 규칙 판정에 활용한다.

OCR은 또한 페이지 유형 감지에 핵심적인 역할을 한다. URL이 /login이 아니더라도, 페이지 화면에 "로그인", "아이디", "비밀번호", "본인확인" 같은 키워드가 OCR로 감지되면, 이 페이지를 로그인 페이지로 분류할 수 있다. 그러면 이 페이지에 SP-로그인 규칙이 적용되어야 한다는 것을 알 수 있다.

세 번째 Gate: URL

URL 패턴은 추가적인 맥락 신호다. /login, /member/login, /user/sign-in 같은 패턴이 URL에 나타나면 로그인 페이지일 가능성이 높다. /search, /board/search, /bbs/list 같은 패턴은 검색이나 목록 페이지를 암시한다. /apply, /apply01, /application, /minwon 같은 패턴은 신청 관련 페이지를 암시한다.

물론 URL 하나만 보고 결론을 내리는 것은 위험하다. 기관마다 URL 구조가 제각각이기 때문이다. 어떤 기관은 /contents/0203010000000/2024/01/ 같은 방식으로 페이지를 구분해, URL만 봐서는 이게 신청 페이지인지 공지사항인지 전혀 알 수 없다. 그래서 URL 단독으로 판정하는 게 아니라, DOM과 OCR 신호와 함께 '가중치 투표' 방식으로 결합한다.

이 세 Gate의 조합이 3중 Gate다. 어느 하나만으로 "이 규칙은 해당없음"이라고 결론 내리는 것이 아니라, 세 가지 신호 중 적어도 하나 이상이 "이 서비스 흐름이 이 사이트에 존재한다"고 말할 때야 비로소 해당 규칙을 적용해 판정을 시도한다.

로그인 흐름 진단 — 가장 많이 무너지는 지점

서비스 패턴 중 로그인 흐름은 특히 집중 분석이 필요하다. 로그인이 무너지면 그 이후의 모든 서비스 흐름이 막히기 때문이다.

태블릿으로 공공 서비스 웹사이트의 검색창을 사용하는 사람의 클로즈업 장면. — 공공 웹사이트의 검색은 단순히 키워드를 입력하는 행위가 아니다. 사용자가 원하는 것에 닿을 수 있는가, 닿지 못했을 때 적절히 안내받는가가 핵심이다.

닐슨 노먼 그룹은 모바일 환경에서의 로그인·회원가입 폼 설계에 대해 구체적인 체크리스트를 공개한 바 있다. 해당 연구에서 핵심 발견은 명확하다. "모바일에서 비밀번호를 입력하는 데 데스크톱보다 두 배 이상 시간이 걸린다"는 것, 그리고 이 마찰을 줄이기 위한 12가지 설계 지침이 존재한다는 것이다(Nielsen Norman Group, "A Checklist for Registration and Login Forms on Mobile", nngroup.com). 같은 원칙을 공공 서비스 환경에 적용하면, 로그인의 마찰이 특히 모바일 환경에서 훨씬 심각한 장벽이 된다는 것을 이해할 수 있다.

KRDS의 로그인 서비스 패턴은 이런 맥락을 반영해, 단순히 "로그인 폼이 있는가"가 아니라 전체 흐름을 단계별로 구체적으로 요구한다. 우리가 SP 로그인 규칙에서 특히 주목하는 판정 포인트들은 다음과 같다.

첫째, 로그인 안내의 명확성. 사용자가 로그인이 필요한 서비스에 접근했을 때, 그것이 왜 로그인을 요구하는지, 어떤 방법으로 로그인할 수 있는지가 명확히 안내되는가. 단순히 "로그인 후 이용 가능합니다"라는 문구만 있고, 로그인 방법 안내가 없거나, 어디로 가야 하는지 불분명한 경우가 실제 분석에서 꽤 자주 등장한다.

둘째, 로그인 방식의 다양성과 선택 안내. KRDS는 아이디·비밀번호 방식 외에도 간편인증, 공동인증서, 생체인증 등 다양한 방식을 지원할 것을 권고한다. 각 방식이 명확하게 구분되고, 사용자가 자신에게 맞는 방식을 선택할 수 있도록 설계되어 있는가. DOM에서 <button> 요소의 텍스트나 ARIA 레이블을 확인하면 어느 정도 알 수 있지만, 실제로 그 버튼이 올바른 로그인 흐름으로 연결되는지는 DOM 판정만으로는 알기 어렵다.

셋째, 로그인 실패 시 오류 안내. 이것이 가장 많이 무너지는 지점이다. 아이디나 비밀번호를 잘못 입력했을 때, "아이디 또는 비밀번호가 맞지 않습니다"라는 전형적인 메시지는 사용자에게 무엇이 틀렸는지 가르쳐 주지 않는다. 스크린 리더 사용자에게는 이 오류 메시지조차 전달되지 않는 경우가 있다. KRDS는 오류 메시지가 포커스를 받아야 하며, role="alert" 또는 aria-live="polite" 속성을 통해 보조기술에 전달되어야 한다고 요구한다.

그런데 이 "오류 메시지가 제대로 동작하는가"를 자동으로 진단하려면, 실제로 로그인을 시도해서 실패 상태를 만들어야 한다. 이건 현재 우리가 자동화하지 않고 있는 영역이다. 크롤러가 실제 계정으로 로그인 시도를 하는 것은 너무 위험하고, 의도치 않은 부작용(계정 잠금 등)을 낳을 수 있기 때문이다. 그래서 이 영역은 아직 "크롤링 없이 DOM 구조 검사만으로 가능한 것"을 판정하고, 런타임 동작은 N/A 또는 수동 검토 대상으로 남긴다. 솔직한 한계다.

검색 흐름 진단 — 가장 복잡한 상태 전이

검색 서비스 패턴은 여러 단계의 상태 전이를 포함한다. KRDS가 정의하는 검색 흐름의 단계를 따라가 보면, 검색 기능 찾기 → 검색어 입력 → 자동완성/추천 검색어 → 검색 결과 확인 → 상세 검색 → 재검색 → 결과 없음 처리 → 검색 종료라는 여러 국면이 있다(KRDS 공식, '개요 | 서비스 패턴 - 검색', krds.go.kr).

2024년 12월, GOV.UK의 검색 개선 작업 사례는 이 영역의 복잡성을 잘 보여준다. GOV.UK 블로그에 따르면, 그들은 검색 인터페이스에 자동완성 기능을 도입하면서 구체적인 설계 결정을 내려야 했다. 자동완성 제안이 나타날 때 기존 콘텐츠 위에 레이어를 덮는 대신 콘텐츠를 아래로 밀어내도록 했고, 제안 수를 5개로 제한해 사용자를 압도하지 않도록 했으며, 3글자 이상 입력했을 때만 제안이 나타나도록 했고, 일치 키워드를 굵게 강조했다(Inside GOV.UK, "Making it quicker and easier to search on GOV.UK", 2024. 12.). 이 결정 하나하나는 "어떻게 하면 검색 흐름이 사용자에게 더 편하게 작동할까"라는 고민의 결과다.

KRDS 역시 검색어 입력 단계에서 유사한 요구사항을 둔다. 예를 들어 자동완성 또는 추천 검색어 제공 시, WAI-ARIA 표준을 사용해 보조기술 사용자에게 실시간으로 정보가 전달되어야 하며, 스크린 리더 사용자가 키보드로 추천 검색어 영역에 접근할 수 있어야 한다(KRDS 공식, '검색어 입력 | 서비스 패턴 - 검색', krds.go.kr).

ViewCheck의 검색 패턴 진단에서 우리가 실제로 자동 판정을 시도하는 것들을 구체적으로 정리하면 이렇다.

DOM으로 판정 가능한 것들:

검색 입력 필드의 존재와 type="search" 또는 role="searchbox" 속성
검색 버튼의 레이블(텍스트 또는 aria-label)
검색 필드의 <label> 연결 여부 또는 placeholder 사용 여부(placeholder만 있으면 접근성 미흡)
검색 결과 영역의 role="region" 및 aria-label 속성
자동완성 combobox·listbox ARIA 역할의 사용 여부

DOM으로 판정이 어려운 것들:

실제로 검색했을 때 결과가 나타나는지
결과 없음 상황에서의 안내 메시지가 보조기술에 전달되는지
자동완성이 실제로 동작하는지

후자는 DOM 정적 분석만으로는 알 수 없다. 그래서 이 부분은 OCR Gate를 보조적으로 활용한다. 스크린샷에서 검색 관련 UI 요소가 시각적으로 확인되면, 그 존재를 보강 증거로 삼아 DOM 판정의 신뢰도를 높이는 방식이다.

신청 흐름 진단 — 폼의 접근성이 곧 서비스 접근성

공공 서비스에서 신청 흐름은 단순한 폼 입력 이상의 의미를 가진다. 복지 급여를 신청하거나, 증명서를 발급받거나, 각종 민원을 제출하는 것은 시민의 법적 권리와 직결되는 행위다. 그 폼에 접근하지 못하거나, 폼 자체가 사용 불가능하다면, 그 시민은 권리를 행사하지 못한다.

깔끔한 책상 위 노트북으로 온라인 신청 양식을 작성하는 신청자의 모습. — 신청 폼에 접근하지 못하는 것은 단순한 불편이 아니다. 시민이 마땅히 행사해야 할 권리를 막는 장벽이다.

NN/g의 폼 설계 연구는 이 문제를 수치로 보여준다. 기본적인 사용성 지침을 따른 폼은 그렇지 않은 폼에 비해, 사용자가 오류 없이 첫 번째 시도에서 제출을 완료하는 비율이 42%에서 78%로 높아진다는 연구 결과가 있다(Nielsen Norman Group, "Less Effort, More Completion: The EAS Framework for Simplifying Forms", nngroup.com). 공공 서비스의 신청 폼이 이 기본 지침을 따르지 않으면, 절반에 가까운 신청자가 첫 시도에서 실패한다는 뜻이다.

KRDS의 신청 서비스 패턴은 이 흐름 전체에 걸친 요구사항을 상세히 기술한다. 신청 대상 탐색, 필요 서류 안내, 서식 작성, 확인, 완료, 처리 현황 확인이라는 단계별 설계 원칙이 있다(KRDS 공식, '신청 대상 탐색 | 서비스 패턴 - 신청', krds.go.kr).

ViewCheck의 신청 패턴 진단에서 특히 집중하는 포인트들이 있다.

필수 입력 표시의 일관성. 신청 폼에서 어떤 필드가 필수이고 어떤 필드가 선택인지를, 시각적으로(예: 빨간 별표)만 구분하지 않고, 텍스트로도 명시해야 하며, required 속성이나 aria-required="true"로 보조기술에도 전달해야 한다. DOM 분석으로 이 속성들의 존재를 확인하는 것은 가능하다. 하지만 "시각적 표시만 있고 속성은 누락"인 경우를 감지하는 것은, DOM과 스크린샷을 함께 봐야 한다.

오류 메시지의 구체성과 접근성. 필수 입력을 빠뜨리거나 잘못된 형식으로 입력했을 때, 어떤 필드에서 어떤 문제가 생겼는지를 구체적으로 알려야 한다. 그리고 이 오류 메시지가 role="alert" 또는 aria-live 영역으로 보조기술에 전달되어야 한다. DOM에서 이런 속성의 존재를 확인하는 것은 가능하지만, 실제로 오류 상황에서 이 속성이 올바르게 발화하는지를 확인하는 것은 런타임 검증이 필요하다.

단계적 진행 안내. 여러 단계로 구성된 신청 과정에서, 사용자가 현재 몇 단계 중 어디에 있는지, 이전 단계로 돌아갈 수 있는지가 명확히 제공되어야 한다. DOM에서 진행 단계 표시(스텝바, 브레드크럼 등) 요소의 존재와 ARIA 속성을 확인하는 것은 가능하다.

이 중 상당 부분은 DOM 분석으로 판정 가능하다. 그러나 "결과적으로 이 신청 흐름이 원활하게 작동하는가"를 완전히 자동으로 검증하는 것은, 현재 우리가 달성하지 못한 영역이다. 이걸 겸손하게 인정하는 것이, 정직한 이 도구의 한계 고백이다.

고령자와 서비스 패턴 — 디지털 격차의 집중점

서비스 패턴 진단이 중요한 또 다른 이유가 있다. 공공 서비스의 주요 이용자 중 상당수가 디지털 기기에 익숙하지 않은 고령층이라는 현실이다.

국가인권위원회는 노인의 디지털 권리 침해 문제를 공식적으로 다루며, 국가기관·지방자치단체·공공기관이 제공하는 디지털 서비스에 노인이 접근·이용할 수 있는 편의 제공이 의무화되어야 한다고 지적했다(국가인권위원회, "디지털 격차로 인해 노인의 권리가 침해되지 않아야", humanrights.go.kr). 코로나19 이후 모바일 앱이나 키오스크를 이용해야 하는 상황이 늘면서 디지털 기기에 익숙하지 않은 노인이 불편을 겪는 경우가 크게 증가했다는 실태도 함께 지적했다.

주민센터에서 공공 온라인 서비스 로그인을 도움받고 있는 노년층 시민의 모습. — 로그인 한 번이 그렇게 어렵지 않아야 한다. 그러나 많은 공공 서비스에서, 그것이 현실이 아니다.

한국소비자원의 고령 소비자 디지털 정보격차 연구는, 고령층이 디지털 서비스 이용에서 겪는 어려움이 특히 로그인과 본인인증, 복잡한 신청 절차 단계에 집중된다는 점을 보여준다(한국소비자원, '고령소비자의 디지털 정보격차 문제와 디지털 역량 강화 방안', kca.go.kr). 이런 어려움이 발생하는 이유는 다양하지만, 설계 문제가 핵심이다. 로그인 방식이 지나치게 복잡하거나, 오류 안내가 불명확하거나, 신청 절차가 너무 많은 단계를 요구하거나.

KRDS의 서비스 패턴 가이드라인은 이런 맥락을 인식하고 있다. 2024년 개정된 가이드라인은 특히 고령층을 포함한 다양한 사용자를 위한 폰트 확대(기존 13~15px에서 17px 수준으로 권고 강화), 간편인증 확대, 복잡한 절차의 단순화 방향을 강조한다(KRDS 공식 가이드라인, GitHub KRDS 자료, 2024년 2월 업데이트본).

이것은 서비스 패턴 규칙이 단순히 "이 속성이 있는가 없는가"를 넘어서, 서비스 흐름의 설계 방향 자체를 담고 있음을 뜻한다. 자동화가 쉽지 않은 이유도 여기에 있다. "이 폼의 절차가 너무 복잡한가"를 자동으로 판정하는 것은, 현재의 정적 분석으로는 가능하지 않다. 그래서 우리는 판정 가능한 것(구조·속성·레이블)을 정확하게 판정하고, 나머지는 솔직하게 수동 검토가 필요하다고 표시하는 방향을 택한다.

해외 사례: GOV.UK는 서비스 패턴을 어떻게 다루는가

글로벌 공공 디자인 시스템 중 서비스 패턴 분야에서 가장 체계적이라는 평가를 받는 것은 GOV.UK Design System이다. KRDS와 직접 비교하면 흥미로운 점들이 보인다.

GOV.UK Design System의 패턴 섹션에는 "다양한 사용자 중심 과업과 페이지 유형에 대한 모범 사례 디자인 솔루션"이 공개되어 있다. 각 패턴에는 사용자 연구를 통해 검증된 방식인지 여부가 명시되어 있다는 것이 특징이다. 즉, "이 패턴은 어떤 사용자 연구를 통해 어떻게 검증됐는지"가 함께 제시된다(GOV.UK Design System, 'Patterns', design-system.service.gov.uk/patterns/).

특히 로그인 분야에서 GOV.UK는 2024~2025년 사이 큰 변화를 이뤄냈다. GOV.UK One Login이라는 통합 인증 서비스가 50개 이상의 정부 서비스에 적용되면서, 영국 시민은 하나의 이메일·비밀번호로 여러 정부 서비스에 접근할 수 있게 됐다. HMRC, 운전 면허청(DVSA), 신원조회 서비스(DBS) 등이 이미 이 통합 로그인을 쓰고 있다(GOV.UK One Login, 'About', sign-in.service.gov.uk/about). GDS는 이 서비스에 대해 "사용자 중심 설계(UCD)가 핵심에 있으며, 복잡한 포용성·접근성 과제를 해결한다"고 설명한다(GDS Blog, "Creating interactive design documentation for GOV.UK One Login", 2025. 4.).

GOV.UK One Login의 설계 권고사항 문서에는 서비스가 이 통합 로그인을 도입할 때 준수해야 할 UX 패턴이 상세히 기술되어 있다. 로그인한 사용자가 계정 설정에 쉽게 이동할 수 있도록 하는 '서비스 헤더 패턴', 기존 사용자를 새 로그인 방식으로 이전하는 '마이그레이션 패턴' 등이 포함된다(GOV.UK One Login, 'Design recommendations', sign-in.service.gov.uk/documentation/design-recommendations).

이메일 주소 확인(confirm an email address) 패턴도 잘 정리되어 있다. 사용자에게 확인 링크를 보내는 방식과 인증 코드를 보내는 방식 중 무엇을 선택할지, 블로킹 방식(확인 전 서비스 이용 불가)과 비블로킹 방식 중 어느 것이 적합한지 등의 설계 판단 기준이 명시되어 있다(GOV.UK Design System, 'Confirm an email address', design-system.service.gov.uk/patterns/confirm-an-email-address/).

검색 분야에서는 2024년 말 검색 UX 대폭 개선 사례가 공개됐다. 자동완성, 필터 단순화, 검색 결과 가독성 향상이 핵심이었는데, 특히 자동완성이 기존 콘텐츠를 가리지 않도록 레이아웃을 설계한 결정이 눈에 띈다. 이것은 인지 부하와 접근성을 동시에 고려한 선택이다(Inside GOV.UK, "Making it quicker and easier to search on GOV.UK", 2024. 12.).

미국의 USWDS(U.S. Web Design System) 역시 비슷한 방향이다. USWDS의 컴포넌트와 설계 요소는 섹션 508 규정(미국 연방 접근성 기준)을 기본값으로 준수한다. 2025년 3월에 발행된 접근성 적합성 리포트는 USWDS 3.11.0의 44개 컴포넌트를 평가한 결과를 담고 있다(USWDS, 'Accessibility', designsystem.digital.gov/documentation/accessibility/). 2024년 4월에는 미국 장애인법(ADA)에 주·지방 정부의 웹 콘텐츠와 모바일 앱이 WCAG 2.1 기준을 충족해야 한다는 최종 규정이 추가됐다.

이 해외 사례들에서 우리가 얻는 교훈은 하나다. 서비스 패턴은 "컴포넌트를 올바르게 쓰는가"보다 한 수 위의 문제라는 것이다. 서비스 흐름이 사용자를 어떻게 안내하고, 어디서 막히게 하며, 어떻게 오류에서 회복하게 하는가 — 이것이 서비스 패턴 설계의 진짜 질문이고, 그 대답은 컴포넌트 하나하나의 속성을 보는 것만으로는 나오지 않는다.

ViewCheck의 실제 SP 분석 화면 — 무엇을 보여주나

실제 ViewCheck LLM 분석에서 SP 카드가 어떤 모습인지를 구체적으로 설명해 보자.

분석 결과 카드 중 '서비스 패턴' 카드가 열리면, 172개 SP 규칙의 판정 결과가 카테고리(로그인·검색·신청·정책)별로 구분되어 나타난다. 각 규칙에 대해 '통과', '미통과', '해당없음' 중 하나의 판정과 함께, 가능하면 왜 그런 판정이 내려졌는지의 근거가 함께 표시된다.

📸 [이미지 — 증적]

파일: 01. 증적자료/case_features/raw/013_07_servicePatterns.png 캡션: ViewCheck LLM 분석의 서비스패턴 결과 카드 실제 화면. KRDS SP 172개 규칙에 대한 판정이 로그인·검색·신청·정책 카테고리로 구분되어 표시된다. ALT: ViewCheck LLM 분석 서비스패턴 카드 실제 캡처. 172개 SP 규칙의 통과/미통과/해당없음 판정 결과가 카테고리별로 정리된 화면.

주목할 것은 '해당없음' 비율이다. 우리가 분석에서 경험한 바로는, SP 규칙은 다른 카테고리(DS·CP·BP)보다 N/A 비율이 상대적으로 높게 나타나는 경향이 있다. 이것이 전적으로 "이 사이트에 해당 서비스 흐름이 없어서"인 경우도 있고, "분석기가 해당 페이지를 방문하지 못해서"인 경우도 있고, "판정이 어려워서 보수적으로 N/A로 남긴 것"인 경우도 있다.

이 세 가지를 구분하는 것이 중요하다. 그래서 SP 카드에서는 가능하면 N/A의 이유를 함께 표시하려 한다. "이 사이트에서 로그인 관련 페이지가 감지되지 않았습니다(URL/OCR 기반 판단)"라거나, "신청 양식이 감지되었으나 동적 상호작용 검증이 필요한 규칙입니다" 같은 형태로. 단순히 N/A 숫자를 던져주는 게 아니라, 그 N/A의 성격을 함께 전달하는 것이 더 유용하다고 생각하기 때문이다.

그리고 SP 카드에서 미통과 규칙이 발견되면, 그 규칙이 어떤 페이지에서, 어떤 이유로 미통과인지를 함께 보여주고, 가능하면 "어떻게 고칠 수 있는가"에 대한 방향도 제시하려 한다. 이때 제시하는 방향은 KRDS 공식 가이드라인의 해당 서비스 패턴 페이지와 연결되어, "기준에서 뭐라고 말하는지"를 직접 볼 수 있도록 참조패널에 표시된다.

정책 정보 확인 — 가장 과소평가된 서비스 흐름

서비스 패턴의 네 가지 흐름 중 상대적으로 덜 주목받는 것이 정책 정보 확인 패턴이다. 로그인·검색·신청에 비해 인터랙션이 적고, 대부분 정보를 읽고 이해하는 과업이기 때문이다.

그러나 이 흐름을 쉽게 봐서는 안 된다. 정책 정보 확인은 "이 사업에 내가 지원 자격이 되는가", "이 민원을 신청하려면 어떤 서류가 필요한가"를 파악하는 과정이다. 이 정보를 제대로 이해하지 못하면, 신청 자체를 시도하지 못하거나 잘못된 신청을 하게 된다.

KRDS는 정책 정보 확인 패턴에 대해 "정책과 관련된 각종 자료를 통해 궁금증을 해결하거나 사업·서비스 참여에 도움이 되는 내용을 확인하는 과정"으로 정의하며, 단순히 정보를 나열하는 것이 아니라 사용자가 필요한 정보를 쉽게 찾고 이해할 수 있도록 구조화하는 것을 요구한다(KRDS 공식, '개요 | 서비스 패턴 - 정책 정보 확인', krds.go.kr).

자동 진단 관점에서 정책 정보 확인 패턴은 검색·로그인보다 판정이 더 어렵다. "이 페이지의 정보가 사용자에게 이해하기 쉬운가"는 사실 자동화가 매우 어려운 질문이다. 구조적 접근성(제목 계층, 목록 구조, 링크 텍스트의 명확성)은 DOM으로 어느 정도 판정할 수 있지만, "읽기 쉬운가"를 자동으로 판정하는 것은 UX 라이팅 분석의 영역이 된다. ViewCheck의 다른 기능(UX 라이팅 분석 카드)과 연동되는 지점이기도 하다.

다중 페이지 분석이 SP에서 왜 특히 중요한가

앞서 여러 편에 걸쳐 강조했지만, SP 영역에서는 다중 페이지 분석이 특히 결정적이다.

메인 페이지만 보면, SP 규칙의 대부분이 N/A가 된다. 대형 공공 포털의 메인에는 검색창이 있지만, 로그인 기능이나 신청 흐름은 대개 서브 페이지에 있다. 검색 결과 페이지, 로그인 페이지, 신청서 작성 페이지, 완료 확인 페이지 — 이것들을 직접 방문해야만 해당 서비스 패턴 규칙을 의미 있게 판정할 수 있다.

ViewCheck의 다중 페이지 분석은 이 점에서 설계 의도가 분명하다. 크롤러가 사이트를 방문할 때, 단순히 링크를 따라가는 것이 아니라, 페이지 유형 분류를 함께 수행한다. URL 패턴, DOM 구조, OCR 텍스트를 종합해 "이 페이지는 로그인 페이지이므로 SP-로그인 규칙을 적용한다", "이 페이지는 검색 결과 페이지이므로 SP-검색 규칙을 적용한다"라는 방식으로 페이지 유형에 맞는 규칙을 선택적으로 적용한다.

이 페이지 유형 감지는 현재 15종을 인식할 수 있다. 메인, 로그인, 검색, 목록, 상세, 신청, 완료, 게시판, 공지사항 등이 포함된다. 분류가 완벽하지는 않다. 특히 독특한 URL 구조를 가진 기관이나, 복수의 서비스가 한 페이지에 결합된 경우에는 분류가 어려울 수 있다. 이것도 계속 개선하는 영역이다.

다중 페이지 분석이 SP 규칙 판정에 미치는 차이는 꽤 극적이다. 메인 페이지만 분석했을 때 SP 규칙의 90% 이상이 N/A로 나오던 것이, 로그인·검색·신청 페이지까지 포함해 분석하면 N/A 비율이 대폭 줄고 실제 판정(통과/미통과)이 늘어난다. 이것이 "의미 있는 분석"과 "숫자만 채운 분석"의 차이다.

SP 판정에서 우리가 맞닥뜨린 현실적 한계들

솔직하게 한계를 정리해 보자. ViewCheck의 SP 판정이 현재 아직 해결하지 못한 영역들이 있다.

런타임 상호작용 검증 불가. 로그인 실패 시 오류 메시지, 신청 폼 제출 시 유효성 검사, 검색 결과 없음 화면 — 이런 것들은 실제로 그 상황을 만들어야(클릭하거나, 데이터를 입력하거나, 의도적으로 오류를 유발해야) 알 수 있다. 현재 크롤러는 페이지를 방문하고 데이터를 수집하지만, 이런 상태 전이를 자동으로 유발하고 결과를 측정하는 것은 아직 구현되어 있지 않다. 일부 규칙은 이 한계 때문에 명시적으로 "수동 검토 필요"로 표시된다.

동적 콘텐츠의 지연 로딩. 어떤 사이트는 검색 결과, 로그인 폼의 특정 요소, 신청 단계의 동적 콘텐츠가 자바스크립트로 나중에 로드된다. Playwright는 기본적으로 페이지 로드 완료 후 DOM을 수집하지만, 특정 상호작용 후에만 나타나는 콘텐츠는 수집되지 않을 수 있다.

인증이 필요한 페이지. 로그인 후에만 접근할 수 있는 페이지의 경우, 크롤러가 그 페이지에 접근하지 못한다. "마이페이지" 같은 로그인 후 서비스, 민원 신청 완료 이후의 처리 현황 확인 화면 등이 여기에 해당한다. 이런 페이지에서만 발생하는 SP 규칙 위반은 현재 감지하기 어렵다.

사이트별 비표준 구현. 한국 공공 웹사이트 중 일부는 표준 HTML 요소 대신 자체적인 비표준 구현을 사용한다. Flash 기반 인터페이스가 줄었지만, 여전히 <div>로 만든 커스텀 로그인 폼이나, 이미지 버튼으로만 구성된 내비게이션 등을 쓰는 경우가 있다. 이런 경우 DOM만 봐서는 해당 요소의 역할을 파악하기 어렵다. OCR Gate가 이 공백을 어느 정도 메워주지만, 완전히 해결되지는 않는다.

이 한계들을 나열하는 이유는 "그러니까 못 합니다"가 아니다. 오히려 "지금 이 도구가 무엇을 할 수 있고 무엇을 못 하는지를 명확히 알고, 그 안에서 가장 정확하게 하자"는 방향이다. 한계를 모르면 결과를 과신하게 된다. 한계를 알면 결과를 올바르게 해석하고, 수동 검토가 필요한 곳을 판단할 수 있다.

SP 진단 결과가 실제 업무에서 어떻게 쓰이는가

분석 결과를 실제 업무에 연결하는 흐름을 구체적으로 상상해 보자.

어느 공공기관 홈페이지 담당자가 ViewCheck LLM 분석을 돌렸다. SP 카드가 열리자, 로그인 카테고리에서 미통과 규칙이 7개 나타났다. 그 중 하나가 "로그인 폼의 아이디 입력 필드에 시각적 레이블이 없고, placeholder 텍스트만 있음"이라는 판정이다. 근거로는 해당 필드의 HTML 구조와 KRDS 로그인 서비스패턴 가이드 링크가 함께 제시된다.

담당자는 이것을 외주 개발사에 전달한다. "이 페이지의 아이디 입력 필드에 <label> 요소를 추가하거나, aria-label 속성을 추가해 주세요. 근거는 이 KRDS 가이드입니다." 모호한 요청이 아니라, 명확한 지적과 출처가 있는 요청이다. 개발사 입장에서도 무엇을 어디서 왜 고쳐야 하는지가 분명하다.

이 흐름에서 ViewCheck가 한 일은 "모든 페이지의 모든 SP 규칙을 사람이 직접 확인하지 않아도 되도록 걸러준 것"이다. 7개의 미통과 규칙이 진짜 문제라고 100% 보장할 수는 없다(판정이 틀릴 수도 있다). 그러나 "이 7개를 우선 확인해 보세요"라는 출발점을 제공함으로써, 담당자가 어디서 시작해야 할지 모르는 상황보다 훨씬 효율적인 작업이 가능해진다.

중요한 것은 담당자가 최종 판단을 한다는 것이다. ViewCheck의 판정이 맞는지, 실제로 그 문제가 현재 서비스에 영향을 미치는지, 우선순위를 어떻게 정할지는 담당자와 개발사가 판단한다. 도구는 그 판단을 위한 데이터와 근거를 제공할 뿐이다.

개선 로드맵 카드와 SP 규칙의 연결

ViewCheck 24개 분석 카드 중 '개선 로드맵' 카드는, 발견된 미통과 규칙들을 우선순위에 따라 정렬하고 어떤 순서로 고치면 좋은지를 제안한다.

SP 규칙과 관련해서, 개선 로드맵 카드가 자주 높은 우선순위로 부각하는 항목들이 있다.

첫째, 로그인 접근성 관련 규칙. 로그인 폼의 레이블 누락, 오류 메시지의 보조기술 미전달 같은 것들은 단순히 KRDS 기준 미충족이 아니라 접근성 법령 위반으로 이어질 수 있다. 그래서 심각도(severity)를 높게 부여한다.

둘째, 검색 결과 없음 안내 관련 규칙. 검색 결과가 없을 때 "검색 결과가 없습니다"라는 단순 메시지 대신, 검색어 오타 확인, 다른 키워드 제안, 연락처 안내 등 대안을 제공하는 것이 KRDS 권고사항이다. 이것이 없으면 사용자가 검색에 막혀 원하는 서비스를 포기하는 이탈이 발생할 수 있다.

셋째, 신청 폼의 필수 입력 안내. 필수 입력 표시가 시각적으로만 있고 보조기술에 전달되지 않으면, 스크린 리더 사용자가 어떤 필드를 반드시 채워야 하는지 알 수 없다. 이것은 접근성 관점에서 심각한 문제이면서, 동시에 신청 오류율을 높이는 사용성 문제이기도 하다.

개선 로드맵에서 이런 항목들이 상위에 오면, 담당자는 "이것부터 고쳐야 하는 이유"를 직관적으로 이해할 수 있다. 단순히 "이 규칙이 미통과"라는 정보보다, "이것이 왜 중요하고, 어느 정도 우선순위인지"가 함께 담기는 것이다.

SP와 BP의 차이 — 패턴 계층을 이해해야 진단이 의미 있다

이 편을 읽는 독자 중에는 "그런데 기본 패턴(BP)과 서비스 패턴(SP)은 어떻게 다른가요?"라는 질문을 가진 분이 있을 것이다. 이 차이를 이해하면 SP 진단의 의미가 더 분명해진다.

KRDS의 기본 패턴(BP, 108개)은 반복적으로 등장하는 상호작용의 '단위 패턴'이다. 폼 작성 방법, 동의 및 확인 절차, 오류 처리 방식, 필터·정렬 인터랙션 같은 것들이 여기에 해당한다. BP는 로그인에도, 검색에도, 신청에도 등장한다. 어떤 서비스 흐름이든 공통적으로 쓰이는 기본 단위다.

반면 서비스 패턴(SP)은 BP를 조합해 완성되는 '서비스 단위 흐름'이다. 로그인 서비스패턴은 "로그인 안내 → 방식 선택 → 인증 → 성공/실패 처리 → 로그아웃"이라는 흐름 전체를 다룬다. 그 흐름 안의 각 단계에서 폼 작성이 필요하다면 BP의 폼 패턴이 쓰이고, 오류 처리가 필요하다면 BP의 오류 처리 패턴이 쓰인다. SP는 그 모든 것을 하나의 서비스 흐름으로 묶어 전체적인 경험을 설계하는 개념이다.

이 계층 관계를 이해하면, SP 판정이 왜 어려운지도 이해된다. BP는 단위 요소를 보면 되지만, SP는 그 단위들이 '흐름으로 얼마나 잘 연결되는가'를 봐야 하기 때문이다. "버튼 하나의 레이블이 올바른가"는 DOM으로 답할 수 있지만, "로그인 흐름이 전반적으로 사용자를 자연스럽게 안내하는가"는 그보다 훨씬 큰 질문이다.

실제 공공 사이트 분석에서 SP 규칙이 자주 발견하는 문제 유형

우리가 여러 공공 사이트를 분석한 경험에서, SP 규칙이 자주 미통과를 내는 패턴들이 있다. 일반화는 위험하지만, 반복적으로 나타나는 유형들을 정리해 보면 이렇다.

로그인 관련:

로그인 필드 레이블이 placeholder 텍스트로만 제공되고 <label> 요소 없음
비밀번호 필드에 '비밀번호 표시/숨기기' 토글이 없어 입력 확인 불가
로그인 실패 메시지가 시각적으로만 표시되고 role="alert" 누락
로그인 방식 선택 버튼에 명확한 텍스트 레이블 없음

검색 관련:

검색 입력 필드에 <label> 없이 placeholder만 사용
자동완성 제안 영역에 role="listbox", role="option" 같은 ARIA 역할 미적용
검색 결과 없음 상황에서 안내 메시지나 대안 제시 없음
검색 결과 영역이 시각적으로만 업데이트되고 보조기술에 변경 알림 없음

신청 관련:

필수 입력 표시가 시각적 별표(*)만 있고 required 속성 또는 aria-required 누락
다단계 신청에서 현재 단계 표시(step indicator)가 보조기술에 미전달
파일 업로드 필드의 허용 파일 유형/크기 안내가 레이블에 포함되지 않음
신청 완료 후 처리 번호 또는 처리 현황 확인 방법 안내 없음

이런 유형들은 개별적으로 보면 "별것 아닌 기술적 누락"처럼 보일 수 있다. 그러나 스크린 리더를 사용하는 시각장애인 사용자, 키보드만으로 인터넷을 탐색하는 운동 장애인 사용자, 또는 인지 부하가 높은 상황의 고령 사용자에게는, 이 누락 하나하나가 서비스를 포기하게 만드는 결정적인 장벽이 된다.

KRDS 필수·권장·우수 3수준이 SP 판정에서 의미하는 것

앞서 KRDS 서비스 패턴 가이드라인이 필수·권장·우수 세 수준으로 구분된다고 언급했다. 이 구분이 ViewCheck 판정에서 어떤 의미를 갖는지 짚어보자.

필수 수준은 말 그대로 기본 중의 기본이다. 이것이 충족되지 않으면, 일부 사용자는 서비스 자체를 이용할 수 없게 된다. 접근성 요구사항, 기본 레이블 제공, 오류 안내 등이 여기에 해당한다. KRDS는 이것을 "핵심 서비스에 대한 사용자 경험 향상을 위해 우선 충족해야 하는 가이드라인"으로 정의한다.

권장 수준은 필수 이상의 편의성과 품질을 위한 가이드라인이다. 자동완성 UX 개선, 다단계 신청의 중간 저장 기능, 상세 오류 안내 등이 여기에 해당한다.

우수 수준은 최적의 사용자 경험을 위한 가이드라인이다. 검색어 추천의 개인화, 단계 건너뛰기 허용, 오류 자동 수정 제안 같은 것들이다.

ViewCheck 판정에서 우리는 이 수준 구분을 심각도(severity) 가중치에 반영한다. 필수 수준 미충족은 높은 심각도로, 권장 수준 미충족은 중간, 우수 수준 미충족은 낮은 심각도로 표시된다. 그러면 담당자가 개선 로드맵을 볼 때, "우선 필수부터, 그 다음 권장, 여력이 되면 우수"라는 자연스러운 우선순위가 보인다.

SP 진단의 미래 — 우리가 풀고 싶은 문제들

이 편을 마무리하면서, 앞으로 SP 진단과 관련해 우리가 풀고 싶은 문제들을 솔직하게 나열해 보자.

첫 번째는 런타임 상호작용 검증의 자동화다. 지금 할 수 없는 것 — 로그인 실패 시 오류 화면, 검색 결과 없음 화면, 신청 폼 유효성 검사 — 을 어떻게 안전하게 자동화할 것인가. 이것이 풀리면 SP 판정의 정확도가 지금보다 훨씬 높아질 수 있다.

두 번째는 페이지 유형 분류의 정확도 향상이다. 현재 15종을 인식하지만, 공공 웹사이트의 다양한 URL 구조와 페이지 형태를 더 정확하게 분류할수록 SP 규칙의 적용 범위가 넓어진다. 잘못된 분류가 잘못된 규칙 적용으로 이어질 수 있기 때문에, 분류 정확도는 판정 신뢰도와 직결된다.

세 번째는 서비스 흐름 전체를 추적하는 크롤링이다. 로그인 페이지에서 시작해, 로그인 성공 후 페이지, 서비스 이용, 로그아웃까지를 하나의 흐름으로 추적하면서 각 단계의 규칙을 판정할 수 있다면, 현재보다 훨씬 입체적인 SP 진단이 가능해진다. 그러나 이것은 크롤링 인프라 관점에서 상당히 복잡한 과제다.

네 번째는 다국어·다양한 사용자 시나리오 지원이다. 공공 서비스를 이용하는 외국인, 고령자, 장애인 등 다양한 사용자 그룹의 시나리오에서 SP 흐름이 올바르게 작동하는지를 테스트하는 것. 이것은 단순한 자동화 문제가 아니라 "어떤 사용자 시나리오를 정의할 것인가"라는 설계 문제이기도 하다.

이 중 어느 것도 당장 내일 해결할 수 있는 문제가 아니다. 그러나 방향은 분명하다. 서비스 패턴은 "시민이 공공 서비스에서 무언가를 이루어야 하는 순간"의 집합이고, 그 순간들이 잘 설계되어 있는지를 자동화된 근거 기반으로 진단하는 것이 우리가 가고 싶은 곳이다.

마무리 — 관문을 진단하는 일의 의미

이번 편에서는 KRDS 서비스 패턴(SP) 172개 규칙을 ViewCheck가 어떻게 진단하는지, 그 접근법과 한계를 솔직하게 이야기했다.

요약하면 이렇다. SP 진단은 846규칙 중에서 자동화가 가장 어렵다. 왜냐하면 서비스 패턴은 단순한 요소나 속성의 문제가 아니라, 사용자가 목적을 달성하기 위해 거치는 '흐름'의 문제이기 때문이다. 그 흐름의 각 단계를 DOM만으로 완전히 파악하기는 어렵다. 그래서 우리는 DOM에 OCR과 URL을 더한 3중 Gate 방식을 실험하고 있다.

공공 서비스 웹사이트의 검색 결과 화면과 상호작용하는 장면 클로즈업. — 검색 결과 화면 하나에도, 사용자가 원하는 곳에 닿을 수 있는지가 담겨 있다. 서비스 흐름의 품질은 이런 순간들의 총합이다.

이 접근이 완전하지 않다는 것을 안다. 런타임 상호작용 검증, 인증이 필요한 페이지, 비표준 구현 — 아직 해결하지 못한 한계들이 있다. 그래서 우리는 현재 SP 판정 결과를 사용자에게 전달할 때, 어느 규칙이 어떤 이유로 N/A인지, 어떤 규칙이 수동 검토를 권고하는지를 함께 전달하려 한다.

궁극적으로, 서비스 패턴 진단이 추구하는 것은 이것이다. 로그인하려는 시민이 막히지 않도록, 검색하는 시민이 원하는 것에 닿을 수 있도록, 신청하는 시민이 절차를 이해하고 완료할 수 있도록 — 그 '관문들'이 잘 설계되어 있는지를, 자동화된 방식으로, 근거와 함께, 확인하는 것.

완벽한 자동 진단은 아직 멀다. 그러나 "어디가 막혀 있는지"를 빠르게 파악하는 것만으로도, 공공 서비스 담당자가 무한히 긴 체크리스트 앞에서 막막해하는 것보다는 훨씬 나은 출발점이 된다. 그 출발점을 더 정확하고, 더 신뢰할 수 있게 만드는 것이 우리의 계속되는 작업이다.

다음 편에서는 또 다른 주제로 이어가겠다.

참고문헌

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

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

행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025. 6. 25. 일부개정). 국가법령정보센터. https://www.law.go.kr/admRulLsInfoP.do?admRulId=37565
행정안전부, 「전자정부 웹사이트 품질관리 지침」 일부개정 및 「품질관리 가이드」 수정본 안내(고시 제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/html/site/service/service_02_01.html
KRDS 공식, '개요 | 서비스 패턴 - 로그인'. https://www.krds.go.kr/html/site/service/service_03_01.html
KRDS 공식, '개요 | 서비스 패턴 - 신청'. https://www.krds.go.kr/html/site/service/service_04_01.html
KRDS 공식, '개요 | 서비스 패턴 - 정책 정보 확인'. https://www.krds.go.kr/html/site/service/service_05_01.html
KRDS 공식, '검색어 입력 | 서비스 패턴 - 검색'. https://www.krds.go.kr/html/site/service/service_02_03.html
디지털 정부서비스 UI/UX 가이드라인 (2024년 2월 업데이트본). GitHub, KRDS-uiux. https://raw.githubusercontent.com/KRDS-uiux/upload-files/main/%EB%94%94%EC%A7%80%ED%84%B8%20%EC%A0%95%EB%B6%80%EC%84%9C%EB%B9%84%EC%8A%A4%20UIUX%20%EA%B0%80%EC%9D%B4%EB%93%9C%EB%9D%BC%EC%9D%B8(24%EB%85%84%202%EC%9B%94).pdf
국가인권위원회, "디지털 격차로 인해 노인의 권리가 침해되지 않아야". 보도자료. https://www.humanrights.go.kr/base/board/read?boardManagementNo=24&boardNo=7609872
한국소비자원, '고령소비자의 디지털 정보격차 문제와 디지털 역량 강화 방안'. https://www.kca.go.kr/home/board/download.do?menukey=6102&fno=10037209&bid=00000160&did=1003436954

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

GOV.UK Design System, 'Patterns'. Government Digital Service. https://design-system.service.gov.uk/patterns/
GOV.UK Design System, 'Confirm an email address'. https://design-system.service.gov.uk/patterns/confirm-an-email-address/
GOV.UK One Login, 'About'. https://www.sign-in.service.gov.uk/about
GOV.UK One Login, 'Design recommendations'. https://www.sign-in.service.gov.uk/documentation/design-recommendations
GDS Blog, "Creating interactive design documentation for GOV.UK One Login", 2025. 4. 1. https://gds.blog.gov.uk/2025/04/01/creating-interactive-design-documentation-for-gov-uk-one-login/
Inside GOV.UK, "Making it quicker and easier to search on GOV.UK", 2024. 12. 12. https://insidegovuk.blog.gov.uk/2024/12/12/making-it-quicker-and-easier-to-search-on-gov-uk/
Nielsen Norman Group, "A Checklist for Registration and Login Forms on Mobile". https://www.nngroup.com/articles/checklist-registration-login/
Nielsen Norman Group, "Less Effort, More Completion: The EAS Framework for Simplifying Forms". https://www.nngroup.com/articles/eas-framework-simplify-forms/
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/
USWDS, 'Accessibility'. U.S. Web Design System. https://designsystem.digital.gov/documentation/accessibility/
USWDS, 'How to use USWDS'. https://designsystem.digital.gov/how-to-use-uswds/