왜 공공 사이트마다 버튼·색·메뉴가 다 다를까

문제제기

공공 사이트 여러 곳을 하루에 몇 군데씩 돌아다녀 본 적 있는 분이라면, 아마 한 번쯤 이런 생각을 했을 거다. "왜 다 다르게 생겼지?"

A기관에 들어가면 메뉴가 화면 맨 위에 가로로 쭉 펼쳐져 있다. B기관에 들어가면 메뉴가 왼쪽에 세로로 붙어 있다. 어떤 곳은 검색창이 큼직하게 첫 화면에 떡 하니 있는데, 어떤 곳은 돋보기 아이콘 하나가 구석에 숨어 있어서 한참을 찾아야 한다. 신청서를 작성하다 '다음' 버튼을 누르려고 보면, 어느 사이트는 오른쪽 아래에 있고 어느 사이트는 왼쪽 위에 있다. 분명 같은 '공공 사이트'인데, 들어갈 때마다 사용법을 새로 배워야 하는 기분이다.

나도 공공웹 업무를 처음 맡았을 때 이게 참 이상했다. 민간 쇼핑몰이나 포털은 어딜 가도 대충 비슷한 자리에 비슷한 게 있는데, 공공 사이트는 왜 이렇게 제각각일까. 처음엔 막연히 '예산이 부족해서 그런가' '만든 업체가 달라서 그런가' 정도로 생각하고 넘어갔다. 그런데 직접 사이트를 개편하고 운영하는 자리에 앉아 보니, 그게 단순히 돈이나 업체의 문제가 아니라는 걸 알게 됐다. 더 근본적인 이유가 있었다.

그 이유를 한마디로 정리하면 이렇다. '공통된 기준이 없었기 때문'이다. 각 기관이, 각 부서가, 각 사업이, 각 시기에, 각자 알아서 '예쁘게' 만들었기 때문이다. 누구도 일을 대충 한 게 아닌데, 합의된 기준 없이 각자의 최선을 모으니 전체로 보면 누더기가 됐다. 이건 누구 한 사람의 잘못이 아니라 시스템의 부재가 만든 결과다.

이 글은 바로 그 질문, "왜 공공 사이트마다 버튼·색·메뉴가 다 다를까"에 답하는 글이다. 그리고 그 답의 한가운데에는 '디자인 시스템'이라는 개념과, 대한민국 정부가 그걸 공공 영역에 적용하기 위해 정리한 KRDS라는 표준이 있다. 이번 주 우리 블로그의 큰 주제가 'KRDS 입문 — 디자인 시스템이 뭔가요'인 이유도 여기에 있다.

미리 안심시켜 드리자면, 이 글은 디자인 전공자나 개발자를 위한 글이 아니다. 사이트 하나 운영해본 경험이 있는 공공웹 담당자, 혹은 이제 막 그 업무를 떠안게 된 분을 위한 글이다. 그래서 전문 용어는 최대한 풀어 쓰고, 어려운 개념은 레고나 도로 표지판 같은 일상적인 비유로 바꿔서 설명하려고 한다. 끝까지 읽고 나면 '아, 공공 사이트가 제각각이었던 게 이런 이유였구나' '그래서 KRDS라는 게 필요했구나' 하고 감을 잡을 수 있을 거다.

조금 더 솔직하게 말하면, 이 글을 쓰는 나도 처음엔 '제각각인 게 뭐가 그렇게 문제인가' 싶었다. 페이지마다 색이 좀 다르고 버튼 모양이 좀 다른 게 그렇게 큰일인가. 그런데 공공 서비스의 특성을 알고 나니 생각이 완전히 바뀌었다. 공공 서비스는 '떠날 수 없는 사용자'를 상대한다. 마음에 안 들어도 다른 데로 갈 수 없는 사용자, 디지털에 서툴러도 어떻게든 써야만 하는 사용자. 그런 사용자에게 '제각각'은 단순한 불편이 아니라 벽이다. 그 벽을 허무는 일이 바로 일관성이고, 그 일관성을 만드는 도구가 디자인 시스템이다.

이 글의 흐름을 미리 일러두면 이렇다. 먼저 '공공 사이트가 왜 제각각이 됐는지' 그 구조적 배경을 짚는다. 그다음 '디자인 시스템'이라는 말 자체를 레고에 빗대어 쉽게 풀고, KRDS가 왜 필요했는지를 공공 웹의 현실에서 설명한다. 이어서 KRDS가 다루는 네 영역(DS·CP·BP·SP)과 846이라는 숫자의 정체, 그리고 '왜 846개에 겁먹지 않아도 되는지'를 이야기한다. 그다음 실제로 어떤 문제들이 반복되는지 익명 사례로 보여주고, 마지막으로 '그래서 우리는 무엇부터 시작하면 되는지' 실무 단계로 정리한다. 처음부터 끝까지 '어려운 걸 쉬운 비유로 바꾸는 것'을 원칙으로 삼았으니, 커피 한 잔 들고 편하게 읽어 내려가면 된다.

왜 제각각이 됐나: 구조의 문제

■ '제각각'은 게으름이 아니라 구조의 결과다

공공 사이트가 제각각인 이유를 이야기하면, 사람들은 흔히 '담당자가 신경을 안 써서' '업체가 대충 만들어서'라고 짐작한다. 하지만 실제로 현장을 들여다보면 거의 정반대다. 대부분의 담당자는 자기 페이지를 정성껏 만들었고, 업체도 그 나름의 최선을 다했다. 그런데도 전체로 보면 제각각이 됐다. 왜일까.

답은 '각자' 만들었기 때문이다. 대한민국에는 중앙부처, 광역·기초 지자체, 공공기관, 산하기관까지 수천 개의 공공 웹사이트가 있다. 그리고 이 사이트들은 각자 다른 시기에, 다른 예산으로, 다른 업체에 맡겨, 다른 담당자의 검수를 받아 만들어졌다. 심지어 한 기관 안에서도 부서별로, 사업별로 따로 발주하는 일이 흔하다. 민원 부서가 만든 페이지와 문화 행사 부서가 만든 페이지가 서로 상의 한 번 없이 별개로 제작되는 식이다.

이 상황을 비유하자면 이렇다. 백 명의 요리사에게 각자 '맛있는 한 끼'를 만들어 오라고 시키면, 백 개의 훌륭한 요리가 나올 수는 있다. 하지만 그걸 한 식탁에 차린다고 한 상의 코스 요리가 되지는 않는다. 누구는 한식, 누구는 양식, 누구는 디저트만 잔뜩. 각각은 맛있지만 함께 놓으면 정신이 없다. 공공 사이트가 딱 이 꼴이다. 페이지 하나하나는 그럴듯한데, 사이트 전체로 보면 통일감이 없다. 문제는 '맛없게 만든 것'이 아니라 '공통 메뉴 기획 없이 각자 만든 것'이다.

여기서 핵심은, 이게 개인의 역량 문제가 아니라 시스템의 부재 문제라는 점이다. 합의된 기준 없이 각자의 최선을 모으면, 그 합은 최선이 되지 않는다. 오히려 따로 노는 조각들의 모음이 된다. 그래서 해법도 '담당자를 다그치는 것'이 아니라 '공통 기준을 세우는 것'이어야 한다. 이 통찰이 디자인 시스템과 KRDS를 이해하는 출발점이다.

■ 담당자가 바뀌면 사이트도 바뀐다

공공기관의 또 다른 특징은 담당자 교체가 잦다는 점이다. 순환 보직, 인사이동, 계약직 만료 등으로 웹 담당자가 자주 바뀐다. 그런데 기준이 문서로 정리돼 있지 않으면, 사이트의 디자인 방향은 그때그때 담당자의 '감각'에 의존하게 된다.

전임자가 '파란색은 이 톤, 버튼은 이 모양'으로 정해놨다 해도, 그게 머릿속에만 있고 어디에도 적혀 있지 않으면 후임자는 알 길이 없다. 후임자는 후임자대로 '내 감각'으로 새로 정한다. 그렇게 한 사이트 안에서도 시기마다 다른 디자인이 켜켜이 쌓인다. 2년 전에 만든 페이지, 작년에 개편한 페이지, 올해 추가한 페이지가 서로 다른 시대의 옷을 입고 한 사이트 안에 공존하게 되는 거다.

디자인 시스템은 바로 이 '담당자 의존성'을 끊어준다. 기준이 사람의 머릿속이 아니라 문서와 부품으로 박제돼 있으면, 담당자가 바뀌어도 일정 수준 이상의 결과가 유지된다. 신입이 와도, 외주가 교체돼도, '이 기준대로 하세요' 한마디면 된다. 공공기관처럼 담당자 교체가 잦은 조직에서 이건 특히 큰 의미가 있다. 기준은 인력의 빈자리를 메워주는 안전망이다.

■ 떠날 수 없는 사용자, 그래서 더 중요한 일관성

민간과 공공의 결정적 차이는 '사용자가 떠날 수 있느냐'에 있다. 민간 쇼핑몰은 불편하면 다른 곳으로 가면 그만이다. 그래서 민간 기업은 사용자가 떠나지 않게 하려고 알아서 사용성을 챙긴다. 안 챙기면 망하니까.

공공 서비스는 다르다. 세금을 내고, 증명서를 떼고, 복지를 신청하고, 민원을 넣는 일은 '다른 사이트로 가면 되는' 일이 아니다. 그 기관 사이트가 유일한 창구다. 떠날 수 없는 사용자를 불편하게 만드는 건, 그 자체로 일종의 책임 방기다. 민간이라면 '선택의 문제'지만 공공에서는 '의무의 문제'가 되는 이유다.

게다가 공공 서비스의 사용자층은 민간보다 훨씬 넓다. 특정 연령, 특정 디지털 숙련도의 사람만 쓰는 게 아니다. 스무 살 대학생도, 여든 살 어르신도, 시각장애가 있는 분도, 한국어가 서툰 외국인 주민도 같은 사이트를 써야 한다. 사용자층이 넓다는 건 '가장 약한 고리'에 맞춰 설계해야 한다는 뜻이다. 가장 디지털에 서툰 사람이 쓸 수 있으면 모두가 쓸 수 있지만, 그 반대는 성립하지 않는다.

그런데 사이트마다 제각각이면, 이 '가장 약한 고리'의 사용자가 가장 먼저 벽에 부딪힌다. 디지털에 익숙한 사람은 새 사이트의 낯선 구조도 금방 파악한다. 하지만 디지털에 서툰 어르신은, A기관에서 겨우 익힌 사용법이 B기관에서 통하지 않으면 그대로 막혀버린다. 일관성이 무너진다는 건 가장 도움이 필요한 사람을 가장 먼저 배제한다는 뜻이기도 하다. 공공 웹의 일관성이 '있으면 좋은 것'이 아니라 '있어야 하는 것'인 이유가 여기에 있다.

디자인 시스템이라는 말부터 풀어보자

■ 레고 블록으로 이해하는 디자인 시스템

'디자인 시스템'이라는 단어가 거창하게 들릴 수 있다. 하지만 개념 자체는 의외로 단순하다. 레고 블록을 떠올리면 쉽다.

레고는 정해진 규격의 블록들이 있다. 2×4 블록, 1×2 블록, 경첩 부품, 바퀴 부품... 이 블록들은 서로 호환되도록 만들어져 있어서, 누가 조립하든 어떤 세트를 사든 끼워 맞출 수 있다. 디자인 시스템도 마찬가지다. 웹사이트를 만들 때 매번 버튼을 처음부터 새로 디자인하는 게 아니라, 미리 정해둔 '표준 버튼' '표준 입력칸' '표준 메뉴'를 가져다 조립하는 방식이다.

왜 이렇게 할까? 매번 새로 만들면 어떤 일이 벌어지는지 생각해보면 답이 나온다. 앞에서 본 그대로다. A 담당자가 만든 버튼은 파란색 둥근 모양인데, B 담당자가 만든 버튼은 회색 각진 모양이 된다. 같은 기관 사이트인데도 페이지마다 버튼이 다르게 생긴다. 사용자는 "이게 누를 수 있는 버튼인가?"를 매번 헷갈린다. 부서가 바뀔 때마다 디자인이 새로 만들어지니 유지보수 비용도 계속 늘어난다.

디자인 시스템은 이 혼란을 끝내려는 시도다. '우리 조직은 버튼을 이렇게 만든다'는 합의를 한 번 정해두면, 누가 만들든 일관된 결과물이 나온다. 사용자는 학습 비용 없이 익숙하게 쓰고, 만드는 쪽은 매번 바퀴를 새로 발명하지 않아도 된다. 이 '바퀴를 새로 발명하지 않는다'는 말이 핵심이다.

디자인 시스템이 없으면, 새 페이지를 만들 때마다 '버튼을 어떻게 생기게 할까, 입력칸 간격은 얼마로 할까, 오류는 어떤 색으로 보여줄까'를 처음부터 다시 정해야 한다. 이 결정 하나하나는 사소해 보이지만, 모이면 엄청난 시간이고 또 매번 조금씩 달라지는 불일치의 원천이다. 디자인 시스템은 이 반복 결정을 '한 번 정해두고 계속 가져다 쓰는' 방식으로 바꾼다. 결정의 횟수가 줄면 일이 빨라지고, 결정이 통일되면 결과가 일관된다. 속도와 품질을 동시에 잡는 셈이다.

■ 디자인 시스템의 세 층위 — 원칙·자산·문서

조금 더 구체적으로 들어가 보자. 제대로 된 디자인 시스템은 보통 세 가지 층위로 이루어진다.

첫째는 '원칙'이다. 우리는 왜 이렇게 만드는가, 어떤 가치를 우선하는가 같은 방향성이다. 예를 들어 '누구나 쉽게 접근할 수 있어야 한다' '일관성을 신뢰의 근거로 삼는다' 같은 큰 약속이다. 원칙이 없으면 자산을 만들 때도, 예외 상황을 판단할 때도 기준이 흔들린다.

둘째는 '자산'이다. 색·글꼴 같은 기본 단위와 버튼·폼 같은 부품처럼 실제로 가져다 쓰는 재료들이다. 레고로 치면 블록 그 자체다. 자산이 잘 정리돼 있으면 만드는 사람은 재료를 고민할 필요 없이 조립에만 집중할 수 있다.

셋째는 '문서'다. 이 자산을 언제, 어떻게 쓰는지를 설명하는 사용 설명서다. '주 버튼은 한 화면에 하나만' '오류 메시지는 빨강이 아니라 충분한 대비를 가진 색으로' 같은 사용 규칙이 여기 담긴다. 자산만 있고 문서가 없으면, 같은 부품을 사람마다 다르게 써서 또 제각각이 된다.

이 세 가지가 갖춰져야 비로소 '시스템'이라 부를 수 있다. 색 팔레트만 정리해뒀다고 디자인 시스템이 되는 게 아니라는 뜻이다. 그리고 뒤에서 보겠지만, KRDS는 바로 이 세 층위를 공공 웹의 맥락에서 빠짐없이 갖춘 '국가 표준 디자인 시스템'이다.

이 대목에서 한 가지 비유를 더 보태고 싶다. 디자인 시스템은 '주방'과 닮았다. 잘 정돈된 주방을 떠올려 보자. 칼은 칼대로, 도마는 도마대로, 양념은 양념대로 자리가 정해져 있고, 자주 쓰는 도구는 손이 닿기 쉬운 곳에 있다. 이런 주방에서는 요리사가 '소금이 어디 있더라'를 고민하지 않는다. 재료와 도구를 찾는 데 쓰는 시간이 없으니, 온전히 '맛'에만 집중할 수 있다. 반대로 도구가 여기저기 흩어진 주방에서는 같은 요리를 만들어도 두 배의 시간이 걸리고, 사람마다 결과가 들쭉날쭉하다. 디자인 시스템은 웹을 만드는 사람에게 '잘 정돈된 주방'을 마련해 주는 일이다. 만드는 사람이 부품을 찾고 결정하는 데 쓰던 에너지를, 사용자를 위한 고민으로 돌려주는 것이다. 이 비유가 와닿는다면, 디자인 시스템이 '제약'이 아니라 '해방'에 가깝다는 걸 이미 절반은 이해한 셈이다.

■ KRDS는 '디자인'만의 이야기가 아니다 — 품질 진단의 한 축

여기서 한 가지 오해를 미리 풀어두고 싶다. KRDS를 '디자인 표준'이라고만 생각하면, 이게 미적인 문제, 즉 '예쁘게 만드는 일'로만 보일 수 있다. 하지만 KRDS가 추구하는 일관성과 사용성은, 사실 '공공 웹의 품질'이라는 더 큰 틀의 한 부분이다.

행정안전부의 「전자정부 웹사이트 품질관리 지침」은 공공 웹의 품질을 일곱 개의 큰 영역으로 나눠 본다. 호환성·접근성·개방성·접속성·편의성·효율성·신뢰성이 그것이다. 이름만 봐도 짐작되듯, 이건 단순히 '예쁜가'를 묻는 게 아니라 '제대로 작동하고, 누구나 쓸 수 있고, 믿을 만한가'를 종합적으로 묻는 틀이다.

이 일곱 영역을 아주 거칠게 풀어보면 이렇다. 호환성은 여러 브라우저와 기기에서 똑같이 잘 보이는가, 접근성은 장애가 있는 분도 쓸 수 있는가, 개방성은 정보가 잘 열려 있고 검색이 되는가, 접속성은 끊김 없이 안정적으로 접속되는가, 편의성은 사용자가 편하게 쓸 수 있는가, 효율성은 페이지가 빠르게 뜨는가, 신뢰성은 보안과 개인정보가 안전한가를 본다. 우리가 이 글에서 줄곧 이야기한 '일관성'과 '사용성'은 이 중 접근성·편의성과 깊이 맞닿아 있고, KRDS는 그 영역을 구체적인 규칙으로 떠받친다.

특히 접근성은 '권장'이 아니라 '의무'라는 점을 다시 강조하고 싶다. 웹 접근성의 한국 기준인 KWCAG는 33개 항목으로 정리돼 있는데, 이건 '잘하면 좋은 것'이 아니라 '지켜야 하는 것'이다. 시각장애가 있는 분이 화면 낭독기로 사이트를 읽을 수 있는가, 색을 구분하기 어려운 분도 정보를 파악할 수 있는가, 키보드만으로 모든 기능을 쓸 수 있는가 같은 것들이다. 앞서 사례에서 '이미지로 만든 버튼은 키보드 접근이 안 된다'고 한 게 바로 이 접근성 문제와 직결된다. KRDS의 부품 규칙들이 '키보드 조작' '충분한 색 대비' '명확한 라벨'을 따지는 건, 이 접근성 의무를 디자인 차원에서 미리 챙기기 위함이다.

그래서 KRDS를 '디자인 잔소리'로 받아들이면 절반만 이해한 거다. KRDS를 잘 지키면 디자인이 일관돼질 뿐 아니라, 접근성·편의성 같은 품질 영역까지 함께 좋아진다. 버튼을 버튼답게 만드는 일, 오류를 명확히 안내하는 일, 흐름을 끊지 않는 일은 곧 '누구나 쓸 수 있고 믿을 만한 사이트'를 만드는 일이다. 디자인과 품질은 별개가 아니라 한 몸이다.

■ 흔한 오해 — 디자인 시스템은 창의성을 죽인다?

여기서 흔한 오해 하나를 짚고 넘어가자. 사람들은 디자인 시스템을 '창의성을 제약하는 틀'로 여기곤 한다. "정해진 부품만 쓰면 다 똑같이 생기는 거 아니냐"는 걱정이다. 하지만 실제로는 그 반대에 가깝다.

기본 부품이 정해져 있으면, 만드는 사람은 '버튼을 무슨 색으로 할까' 같은 사소한 결정에 에너지를 쓰지 않아도 된다. 그렇게 아낀 에너지를 '이 페이지에서 사용자가 정말 원하는 게 뭘까' 같은 본질적인 고민에 쓸 수 있다. 제약이 오히려 창의성을 본질로 돌려보내는 셈이다. 글을 쓸 때 맞춤법과 문법이 정해져 있다고 해서 표현이 획일화되지 않는 것과 같은 이치다. 오히려 공통 문법이 있어야 더 자유롭게, 더 멀리 표현할 수 있다.

또 하나, 디자인 시스템은 '한 사람의 천재'에 의존하지 않게 해준다. 가이드가 없는 조직은 '디자인 감각이 좋은 그 담당자'가 있을 때만 결과물이 좋다. 그 사람이 부서를 옮기거나 퇴사하면 품질이 뚝 떨어진다. 디자인 시스템은 그 감각을 '조직의 자산'으로 박제해둔다. 앞에서 말한 '담당자 의존성 끊기'가 바로 이 대목과 연결된다.

레고 비유를 한 번 더 밀고 가보자. 레고가 강력한 건 단지 블록이 호환되기 때문만은 아니다. 블록의 '종류'가 잘 정리돼 있고, 각 블록이 '어떤 역할'을 하는지 명확하기 때문이다. 기본 블록, 연결 블록, 장식 블록, 특수 부품... 역할이 분명하니 조립하는 사람이 헷갈리지 않는다. 디자인 시스템도 마찬가지다. '이건 정보를 보여주는 부품' '이건 행동을 유도하는 부품' '이건 상태를 알리는 부품'처럼 역할이 정리돼 있어야, 만드는 사람이 상황에 맞는 부품을 골라 쓸 수 있다. KRDS가 단순한 색·글꼴 모음이 아니라 부품의 '역할과 상태'까지 규정하는 이유가 여기에 있다.

그래서 KRDS는 왜 필요했나

■ 민간은 이미 하고 있었다

민간 기업들은 이미 오래전부터 자체 디자인 시스템을 운영해왔다. 큰 IT 기업일수록 수백 명의 디자이너·개발자가 동시에 일하는데, 디자인 시스템이 없으면 제품이 누더기가 되기 때문이다. 그들은 '우리 회사 버튼은 이렇게 생긴다' '우리 회사 색은 이 팔레트 안에서만 쓴다'를 문서로 정리하고, 그걸 코드로 만들어 모두가 가져다 쓰게 했다. 그 결과 화면 수백 개가 한 사람이 만든 것처럼 일관됐다.

그렇다면 공공은 왜 이걸 진작 못 했을까. 공공 영역은 사정이 더 복잡하기 때문이다. 민간 기업은 '한 회사'가 '한 브랜드'를 위해 디자인 시스템을 만든다. 의사결정권자가 명확하고, 적용 범위도 자기 회사 제품으로 한정된다. 반면 공공은 수천 개의 독립된 기관이 각자 사이트를 운영한다. 어느 기관도 다른 기관에 '이렇게 만드세요'라고 강제할 권한이 없다. 그러니 각자 만들 수밖에 없었고, 그게 제각각의 근본 원인이었다.

■ KRDS — 국가가 한 번 잘 정리해 모두에게 나눠주다

KRDS는 바로 이 문제를 풀기 위해 정부 차원에서 정리한 표준이다. '공공 웹사이트는 이렇게 만들면 일관되고, 쓰기 쉽고, 접근성도 챙길 수 있다'는 청사진을 국가가 한 번 잘 만들어, 모든 기관이 가져다 쓸 수 있게 공유한 것이다.

이 지점이 중요하다. 만약 수천 개 기관이 제각각 자기만의 디자인 시스템을 만든다면, 그건 또 다른 형태의 난립일 뿐이다. KRDS는 '각 기관이 따로 고민하지 않아도 되도록' 국가가 한 번 잘 정리해 공유하는, 일종의 공공재에 가깝다. 기관 입장에서는 '남이 잘 만들어둔 기준을 가져다 쓰는' 셈이라 오히려 부담이 줄어든다. 직접 디자인 시스템을 구축하려면 몇 달이 걸리고 전문 인력도 필요한데, 그 큰 일을 국가가 대신 해준 셈이다.

여기서 '같은 언어'라는 표현을 음미해볼 만하다. 사람들이 처음 가는 도시에서도 길을 찾을 수 있는 건, 도로 표지판·신호등·횡단보도 같은 약속이 도시마다 비슷하기 때문이다. 빨간불이 어느 도시에선 '멈춤'이고 어느 도시에선 '출발'이라면 사회가 굴러가지 않는다. 공공 웹도 마찬가지다. 메뉴는 보통 위쪽이나 왼쪽에, 검색은 잘 보이는 곳에, 신청 버튼은 흐름의 끝에 — 이런 '약속'이 기관마다 비슷해야 국민이 새 사이트에서도 헤매지 않는다. KRDS는 이 사회적 약속을 웹의 언어로 옮겨 적은 표지판 규칙집인 셈이다.

■ 표준이 '있는 것'과 '지켜지는 것'은 다르다

여기서 한 가지 더 짚고 싶다. '표준이 있다'는 것과 '표준이 지켜진다'는 것은 전혀 다른 문제다. 아무리 좋은 기준이 있어도, 그것이 실제 사이트에 적용됐는지 확인하지 않으면 기준은 문서로만 남는다.

그래서 KRDS의 가치는 '기준을 아는 것'에서 끝나지 않고 '기준과 현실의 거리를 측정하는 것'으로 완성된다. 우리 사이트가 KRDS 기준에서 얼마나 벗어나 있는지, 어느 부분이 잘 맞고 어느 부분이 어긋나는지를 알아야 비로소 고칠 수 있다. 진단 없는 처방은 없다. 현황을 모르면 무엇을 어떤 순서로 고쳐야 할지도 알 수 없다.

문제는 이 측정을 사람이 일일이 하기엔 양이 너무 많다는 점이다. 사이트 하나가 수백, 수천 페이지에 이르고, 각 페이지마다 따져야 할 규칙이 수십 개씩이다. 이걸 사람이 손으로 점검하면, 한 사이트를 다 보기도 전에 지친다. 그래서 자동화된 진단이 표준의 실효성을 떠받치는 또 하나의 축이 된다. 표준을 만드는 일과 표준을 지키는지 확인하는 일은 한 쌍으로 굴러가야 한다. 이 '자동 진단' 이야기는 글 뒷부분에서 다시 다루겠다.

KRDS가 다루는 범위와 846이라는 숫자

■ 생각보다 넓은 KRDS의 범위 — 네 개의 서랍

KRDS가 '색이랑 글꼴 정하는 거 아니야?'라고 생각했다면, 범위를 보고 놀랄 수 있다. KRDS는 크게 네 개의 영역으로 구성된다. 이 네 영역을 '네 개의 서랍'이라고 부르겠다. 각 서랍의 영문 약자를 기억해두면 앞으로 KRDS 관련 자료를 읽을 때 훨씬 수월하다.

첫째, DS(Design System, 디자인 시스템 기반 요소)다. 색상, 글꼴, 간격, 그림자, 모서리 둥글기 같은 '시각의 기본 단위'를 다룬다. 쉽게 말해 사이트 전체의 '톤앤매너'를 결정하는 부분이다. 이 영역에 속한 규칙이 약 120개다.

둘째, CP(Component, 컴포넌트)다. 버튼, 입력폼, 체크박스, 드롭다운, 카드, 모달창, 탭, 내비게이션, 표, 페이지네이션... 화면을 구성하는 '부품' 하나하나에 대한 규칙이다. 가장 규칙 수가 많은 영역으로, 약 446개에 달한다. 화면에 보이는 거의 모든 요소가 여기 포함된다고 보면 된다.

셋째, BP(Basic Pattern, 기본 패턴)다. 부품 하나가 아니라 부품들이 모여 만드는 '작은 흐름'을 다룬다. 예를 들어 폼을 채우고 검증받는 과정, 동의하고 확인하는 절차, 오류가 났을 때 안내하는 방식, 목록을 필터링하고 정렬하는 방식 같은 것들이다. 약 108개의 규칙이 있다.

넷째, SP(Service Pattern, 서비스 패턴)다. 가장 큰 단위로, 사용자가 목적을 이루기 위해 거치는 '전체 여정'을 다룬다. 검색해서 정보를 찾는 흐름, 로그인하고 회원가입하는 흐름, 무언가를 신청하거나 예약하는 흐름, 정책·안내 정보를 읽는 흐름 등이다. 약 172개의 규칙이 있다.

이 네 영역을 합치면 120 + 446 + 108 + 172 = 846개다. KRDS가 846규칙으로 불리는 이유가 바로 이것이다.

■ 네 서랍은 위에서 아래로 쌓인다

여기서 한 가지 짚고 넘어가자. 이 네 영역은 따로 노는 게 아니라 위에서 아래로 쌓이는 구조다. DS라는 기초 위에 CP라는 부품이 만들어지고, 그 부품들이 모여 BP라는 패턴이 되고, 패턴들이 이어져 SP라는 서비스가 된다.

색(DS)이 정해져야 버튼(CP)을 만들 수 있고, 버튼이 있어야 폼 입력 흐름(BP)이 굴러가고, 그 흐름들이 모여야 민원신청 서비스(SP)가 완성된다. 그래서 KRDS를 '레이어가 쌓인 시스템'이라고 표현하기도 한다. 이 구조를 이해하면, 어떤 문제가 생겼을 때 '이건 어느 층위의 문제인가'를 짚을 수 있게 된다. 같은 증상이라도 색이 문제인지(DS), 부품이 문제인지(CP), 흐름이 문제인지(BP), 전체 여정이 문제인지(SP)를 구분하면 해법이 명확해진다.

각 영역을 조금 더 풀어서, 실무에서 어떤 식으로 만나게 되는지 보자.

DS(약 120개)는 '눈에는 잘 안 띄지만 모든 걸 떠받치는' 영역이다. 색 하나만 해도 단순히 '파랑'이 아니라, 주 색·보조 색·강조 색·경고 색·배경 색·테두리 색처럼 역할별로 나뉜다. 글꼴도 제목용 크기, 본문용 크기, 캡션용 크기가 위계를 이룬다. 간격은 8을 기준으로 한 배수 체계(8, 16, 24, 32...)로 정돈된다. 이런 기본 단위를 '토큰'이라는 이름의 변수로 관리하는 게 DS의 핵심인데, 이건 워낙 중요해서 다음에 따로 자세히 다룰 예정이다. 지금은 'DS = 사이트의 톤을 결정하는 보이지 않는 뼈대' 정도로 기억하면 충분하다.

CP(약 446개)는 네 영역 중 가장 규칙이 많고, 담당자가 가장 자주 마주치는 영역이다. 버튼, 입력칸, 체크박스, 라디오 버튼, 드롭다운, 날짜 선택기, 파일 첨부, 토글, 슬라이더, 탭, 아코디언, 카드, 모달, 툴팁, 배지, 알림, 페이지네이션, 표, 목록, 브레드크럼, 페이지 헤더, 푸터... 화면에 보이는 거의 모든 것이 여기 들어간다. 규칙이 많은 이유는, 부품 하나마다 따질 게 많기 때문이다. 버튼 하나만 해도 기본·마우스 올림·눌림·비활성·로딩 같은 여러 상태가 있고, 각 상태가 시각적으로 구분돼야 하며, 라벨은 명확해야 하고, 크기는 누르기 충분해야 하고, 키보드로도 조작돼야 한다. 이 '따질 게 많음'이 446이라는 숫자로 나타난 것이다.

BP(약 108개)는 부품들이 모여 만드는 '작은 시나리오'를 다룬다. 예를 들어 '폼을 채우다가 틀리면 어떻게 알려줄 것인가' '동의 항목을 어떻게 배치하고 확인받을 것인가' '긴 목록을 어떻게 필터링하고 정렬하게 할 것인가' 같은 것들이다. 부품 자체는 멀쩡해도 이 시나리오가 어색하면 사용자는 답답함을 느낀다. BP는 '부품과 서비스 사이를 잇는 다리' 같은 영역이라고 보면 된다.

SP(약 172개)는 가장 큰 그림이다. 사용자가 사이트에 온 '목적' 단위로 흐름을 본다. 정보를 검색해서 찾는 여정, 회원으로 가입하고 로그인하는 여정, 무언가를 신청하거나 예약하거나 민원을 넣는 여정, 정책과 안내를 읽고 이해하는 여정. 이 여정들은 여러 페이지와 여러 단계에 걸쳐 있어서, 중간 어디 하나만 끊겨도 전체가 실패한다. SP가 좋은 사이트는 '쓰다 보면 어느새 끝나 있는' 느낌을 주고, SP가 나쁜 사이트는 '하다가 포기하게 되는' 느낌을 준다.

이렇게 보면 846이라는 숫자가 조금 다르게 다가올 거다. 무작정 많은 게 아니라, 공공 웹을 구성하는 요소를 '기초 → 부품 → 패턴 → 서비스' 순으로 빠짐없이 정리하다 보니 자연스럽게 나온 숫자다. 오히려 '이만큼 꼼꼼하게 정리해뒀구나'라고 받아들이는 편이 정확하다.

■ 846이라는 숫자에 겁먹지 않아도 되는 이유

846개라고 하면 "이걸 다 외워야 해?" 싶어 막막할 거다. 결론부터 말하면 외울 필요 없고, 다 동시에 챙길 필요도 없다.

이유는 두 가지다. 첫째, 846개 규칙이 모든 페이지에 동시에 적용되는 게 아니다. 예를 들어 모달창 관련 규칙은 그 페이지에 모달창이 있을 때만 따진다. 표 관련 규칙은 표가 있는 페이지에서만 본다. 그러니 실제로 한 페이지에서 '판정 대상'이 되는 규칙은 전체의 일부다. 컴포넌트가 없으면 그 규칙은 '해당 없음'으로 빠진다. 단순한 안내 페이지라면 따지는 규칙 수가 확 줄고, 복잡한 신청 페이지라면 늘어난다. 즉 '페이지의 복잡도만큼만' 규칙이 적용된다.

둘째, 846개가 다 같은 비중인 것도 아니다. 자주 걸리고 영향이 큰 규칙이 있고, 특수한 상황에서만 따지는 규칙이 있다. 실무에서 중요한 건 '자주 걸리는 핵심 규칙부터 잡는 것'이다. 모든 규칙을 100점 맞으려 애쓰기보다, 영향 큰 것부터 순서대로 잡아가는 게 현실적이다.

그래서 KRDS를 대하는 올바른 태도는 '846개 암기'가 아니라 '구조 이해 + 우선순위 잡기'다. DS·CP·BP·SP라는 네 개의 큰 서랍이 있다는 것, 각 서랍에 어떤 종류의 규칙이 들어있는지를 알면, 나머지는 필요할 때 찾아보면 된다.

이걸 운전에 비유하면 이렇다. 도로교통법 조항을 다 외우는 운전자는 없다. 하지만 좋은 운전자는 '신호를 지킨다, 안전거리를 둔다, 보행자를 보호한다' 같은 핵심 원칙을 몸에 익히고 있다. 세부 조항은 필요할 때 찾아보면 된다. KRDS도 똑같다. '일관성을 지킨다, 누구나 쓸 수 있게 한다, 흐름을 끊지 않는다' 같은 큰 원칙을 이해하고, 네 서랍의 구조를 알아두면, 846개 세부 규칙은 자동 진단 도구가 대신 챙겨준다. 사람은 방향을 잡고, 도구는 디테일을 챙긴다. 이게 가장 현실적이고 지속 가능한 역할 분담이다.

■ 처음 만나는 사람들이 자주 던지는 질문

KRDS를 처음 접하는 분들이 가장 자주 던지는 질문 몇 개를 미리 정리해두자.

"KRDS를 안 지키면 처벌받나요?"라는 질문이 많다. KRDS 자체보다 더 직접적으로 작동하는 건 접근성 관련 법적 의무다. 웹 접근성은 권장이 아니라 법으로 규정된 의무이고, KRDS는 그 법적 의무를 포함해 '잘 만든 공공 웹'의 기준 전반을 아우르는 더 넓은 틀이라고 이해하면 된다.

"기존 사이트도 다 바꿔야 하나요?"라는 질문에는 '한 번에 다 바꿀 필요는 없다'가 답이다. 현황을 진단하고, 영향 큰 것부터, 개편 시점에 맞춰 점진적으로 적용하는 게 정석이다. 이 점진적 적용 전략은 글 뒷부분에서 더 구체적으로 다룬다.

"디자인은 외주 업체가 알아서 하는 거 아닌가요?"라는 생각도 흔하다. 물론 실제 제작은 업체가 한다. 하지만 '무엇을 기준으로 만들지'를 정하고 '제대로 만들어졌는지'를 확인하는 건 결국 발주처, 즉 담당자의 몫이다. 기준을 모르면 업체가 하는 말을 검증할 수 없고, 검증할 수 없으면 끌려다니게 된다. KRDS를 알아두는 건 디자인을 직접 하기 위해서가 아니라, '제대로 된 디자인을 요구하고 확인하기 위해서'다. 이건 디자인 능력이 아니라 발주·검수 능력의 문제다.

"우리 기관은 규모가 작아서 그렇게까지 안 해도 되지 않나요?"라는 질문도 있다. 규모가 작다고 사용자가 덜 까다로운 건 아니다. 오히려 작은 기관일수록 전담 인력이 없어서, 한 번 잘못 만들면 고칠 여력이 없는 채로 오래 방치된다. 그래서 작은 기관일수록 '처음부터 기준에 맞게' 만드는 게 더 중요하다. KRDS 같은 공식 기준을 따르면, 적은 인력으로도 일정 수준 이상을 보장받을 수 있다.

"KRDS를 지키면 우리 사이트만의 개성이 사라지지 않나요?"라는 걱정도 자주 듣는다. KRDS는 '구조와 사용성'의 기준이지 '브랜드 정체성'을 금지하는 게 아니다. 기관의 상징색, 로고, 고유한 콘텐츠는 얼마든지 살릴 수 있다. KRDS가 통일하라는 건 '버튼이 버튼처럼 작동하는 방식' '오류를 안내하는 방식' 같은 사용성의 문법이지, 기관의 얼굴을 지우라는 게 아니다. 표준어를 쓴다고 모든 사람의 말투가 똑같아지지 않는 것과 같다.

흔한 문제들 (익명 사례)

개념만 들으면 '그래서 실제로 뭐가 문제인데?' 싶을 수 있다. 그래서 실무에서 자주 마주치는 상황을 익명으로 풀어보겠다. 아래 사례들은 특정 기관 이야기가 아니라, 공공 사이트를 점검하다 보면 패턴처럼 반복되는 전형적인 문제들이다.

미리 양해를 구하자면, 여기서 드는 사례에는 어떤 실제 기관명도, 도메인도, 식별 가능한 정보도 들어 있지 않다. 모두 여러 사이트에서 공통적으로 관찰되는 '유형'을 익명으로 재구성한 것이다. 특정 기관을 비판하려는 게 아니라, '기준이 없으면 누구에게나 일어나는 일'임을 보여주려는 의도다. 읽다가 '어, 우리 사이트 얘긴가?' 싶은 대목이 있다면, 그건 그만큼 흔한 문제라는 뜻이지 당신 기관만의 문제가 아니다.

■ 사례 하나: 부서마다 다른 '우리 사이트' (DS의 문제)

A광역지자체 사이트를 점검한 적이 있다고 치자. 메인 페이지는 깔끔했다. 그런데 메뉴를 타고 들어가니 분위기가 확 달라졌다. 민원 부서가 관리하는 페이지는 파란 계열인데, 문화 행사 부서가 만든 페이지는 초록 계열이었다. 같은 기관 사이트인데 서너 개의 '다른 사이트'를 돌아다니는 느낌이었다.

원인은 뻔하다. 부서별로, 사업별로, 시기별로 따로 발주해서 만들었기 때문이다. 만들 때마다 디자인 기준이 없으니 각자 알아서 예쁘게 만든 거다. 개별 페이지만 보면 다들 그럴듯한데, 사이트 전체로 보면 통일감이 무너진다. 사용자는 '내가 지금 같은 기관 사이트에 있는 게 맞나' 의심하게 된다.

그리고 이 의심은 곧 '신뢰의 흔들림'으로 이어진다. 공공 사이트는 국민에게 '공식 창구'라는 신뢰를 줘야 하는데, 페이지마다 분위기가 제각각이면 '여기가 진짜 그 기관 사이트가 맞나, 혹시 사칭은 아닌가' 하는 막연한 불안이 생긴다. 특히 개인정보를 입력하거나 신청을 해야 하는 화면에서 이런 불안은 치명적이다. 일관된 디자인은 단순히 '예뻐 보이기 위함'이 아니라, '이곳은 믿을 수 있는 공식 창구다'라는 신뢰의 시각적 증거다.

이게 바로 DS(디자인 기반 요소) 차원의 문제다. 색·글꼴·간격 같은 기본 단위를 토큰으로 통일하지 않으면, 부서가 늘어날수록 사이트는 누더기가 된다. 이런 색의 난립은 '리뉴얼할 때' 가장 뼈아프게 드러난다. 기관 상징색을 약간 손보자는 단순한 결정이, 수십 종으로 흩어진 파랑을 일일이 찾아 바꾸는 대공사가 된다. 어디에 어떤 색이 쓰였는지 아무도 모르기 때문이다.

■ 사례 둘: 어디가 버튼인지 모르겠는 화면 (CP의 문제)

또 다른 흔한 문제는 '버튼처럼 안 생긴 버튼'이다. 어떤 페이지에서는 밑줄 친 파란 글씨가 버튼이고, 어떤 페이지에서는 회색 네모 박스가 버튼이다. 또 어떤 곳에서는 그냥 텍스트인 줄 알았는데 눌러보니 링크였다. 사용자는 화면에서 '뭘 누를 수 있는지'를 매번 추측해야 한다.

이건 CP(컴포넌트) 차원의 문제다. 버튼이라는 부품이 '버튼처럼 보이고, 버튼처럼 동작해야' 한다는 기본이 지켜지지 않은 거다. 더 나아가 '주 버튼'과 '보조 버튼'의 위계가 없는 경우도 흔하다. 신청서 화면에 '제출'과 '취소' 버튼이 똑같은 크기, 똑같은 색으로 나란히 있으면, 사용자는 어느 게 진짜 눌러야 할 버튼인지 헷갈린다. 가장 중요한 행동(제출)이 시각적으로 도드라져야 하는데, 둘이 똑같으면 사용자의 시선이 길을 잃는다.

버튼의 '상태'가 빠진 경우도 많다. 마우스를 올렸을 때 아무 반응이 없고, 눌렀을 때도 변화가 없으면, 사용자는 '이게 눌린 건가?' 불안해한다. 특히 신청·결제처럼 중요한 행동에서, 눌렀는데 아무 반응이 없으면 사람들은 두 번, 세 번 누르게 된다. 그러다 중복 신청이 발생하기도 한다. 버튼의 상태 표현은 단순한 '디테일'이 아니라 사용자의 행동을 안내하는 신호다. KRDS의 CP 영역이 버튼 하나에도 여러 상태를 따지는 이유가 여기에 있다.

키보드 접근성도 빼놓을 수 없다. 마우스 없이 키보드만으로 사이트를 쓰는 사용자가 분명히 존재한다. 그런데 이미지로 만든 버튼, 비표준 방식으로 만든 메뉴는 키보드로 접근이 안 되는 경우가 많다. 마우스로는 멀쩡히 동작하니 만든 사람은 문제를 모른다. 이런 '보이지 않는 장벽'이야말로 기준과 진단이 필요한 대표적 영역이다.

■ 사례 셋: 신청하다 포기하게 되는 흐름 (BP·SP의 문제)

가장 뼈아픈 건 '서비스 흐름' 자체가 끊기는 경우다. B공공기관의 어떤 신청 서비스를 예로 들어보자. 사용자가 신청서를 열심히 작성했다. 그런데 마지막 '제출' 단계에서 '필수 항목이 누락되었습니다'라는 메시지가 떴다. 문제는, 어느 항목이 빠졌는지 알려주지 않는다는 거다. 사용자는 처음부터 끝까지 다시 훑으며 빠진 곳을 찾아야 한다. 운 나쁘면 그 과정에서 작성한 내용이 다 날아가기도 한다.

이건 BP(기본 패턴) 차원의 문제다. '오류를 어떻게 안내할 것인가'라는 패턴이 잘못 설계된 거다. 좋은 오류 안내는 '무엇이, 어디서, 왜' 잘못됐는지를 그 자리에서 알려준다. '이메일 형식이 올바르지 않습니다'를 해당 입력칸 바로 옆에 보여주는 식이다. 반면 나쁜 오류 안내는 '뭔가 잘못됐다'만 알려주고 사용자를 미궁에 빠뜨린다.

여기서 더 나아가면 SP(서비스 패턴)의 문제로 이어진다. 신청이라는 '여정' 전체가 매끄러운가. 단계가 몇 개인지 한눈에 보이는가. 지금 내가 어느 단계에 있는지 알 수 있는가. 중간에 저장하고 나중에 이어서 할 수 있는가. 이런 여정 설계가 잘 된 사이트는 사용자가 '어느새 끝났네' 하고 빠져나오고, 잘못된 사이트는 '이거 언제 끝나' 하다가 포기한다.

공공 서비스에서 '포기'는 단순한 이탈이 아니다. 그 신청이 복지 혜택이었다면 받아야 할 사람이 못 받은 것이고, 민원이었다면 해결돼야 할 일이 안 된 것이다. 흐름 하나가 끊겨서 국민이 권리를 누리지 못하게 되는 거다. SP 영역이 KRDS에서 172개나 되는 규칙으로 꼼꼼히 다뤄지는 이유가 여기에 있다.

■ 사례 넷: 찾고 싶은 걸 못 찾는 사이트 (SP의 문제)

마지막으로 하나만 더 보자. C기관 사이트에 '어떤 서류를 어디서 떼는지'를 알아보러 들어갔다고 치자. 첫 화면은 행사 배너와 보도자료로 가득하다. 정작 내가 찾는 '서류 발급' 메뉴는 어디 있는지 보이지 않는다. 검색창을 찾아 단어를 넣어보지만, 엉뚱한 결과만 잔뜩 나오고 정작 원하는 페이지는 한참 아래에 있다. 결국 메뉴를 하나씩 눌러보며 '이 안에 있으려나' 하고 탐색하다 지친다.

이건 정보를 '찾는 여정' 전체, 즉 SP(서비스 패턴) 차원의 문제다. 사용자가 사이트에 오는 건 '구경'하러가 아니라 '목적'을 이루러다. 그 목적으로 가는 길이 잘 닦여 있어야 한다. 메뉴 구조가 사용자의 생각 순서와 맞는가, 검색이 원하는 결과를 위로 올려주는가, 자주 찾는 서비스가 눈에 잘 띄는 자리에 있는가. 이런 게 갖춰진 사이트는 '바로 찾아진다'는 느낌을 주고, 그렇지 않은 사이트는 '여긴 뭘 어디서 하는지 모르겠다'는 인상을 남긴다.

흥미로운 건, 이 문제의 원인이 '콘텐츠가 없어서'가 아닌 경우가 많다는 점이다. 오히려 정보는 다 있는데, 너무 많은 걸 첫 화면에 욱여넣어서, 혹은 만드는 사람의 조직도 순서대로 메뉴를 짜서 사용자가 길을 잃는 경우가 흔하다. 사이트를 만드는 사람의 머릿속 구조와, 사이트를 쓰는 사용자의 머릿속 구조는 다르다. KRDS의 서비스 패턴 규칙들이 '사용자 관점의 흐름'을 강조하는 건, 바로 이 간극을 좁히기 위함이다. 좋은 정보 구조는 만드는 사람이 아니라 쓰는 사람의 머릿속을 기준으로 짜인다.

■ 사례들이 말해주는 것 — 증상은 달라도 뿌리는 같다

이 세 가지 사례는 증상이 다 다르다. 하나는 색이 제각각이고, 하나는 버튼이 안 보이고, 하나는 흐름이 끊긴다. 하지만 뿌리를 따라가 보면 결국 한 곳에서 만난다. '공통 기준이 없었다'는 것, 그리고 '기준과 현실의 거리를 측정하지 않았다'는 것이다.

그리고 이 사례들에서 정작 중요한 건, 담당자 누구도 일을 '대충' 한 게 아니라는 점이다. 각자 자기 페이지를 정성껏 만들었다. 문제는 '각자' 만들었다는 사실 자체에 있었다. 합의된 기준 없이 각자의 최선을 모으면 그 합은 최선이 되지 않는다. 이건 개인의 역량 문제가 아니라 시스템의 부재 문제다. 그래서 해법도 사람을 다그치는 게 아니라 기준을 세우고, 그 기준이 지켜지는지 측정하는 것이어야 한다.

사례를 읽으며 '이건 어느 서랍의 문제일까'를 함께 생각했다면, 앞에서 배운 네 영역 구조가 이미 머릿속에서 살아 움직이기 시작한 거다. 색의 문제는 DS, 부품의 문제는 CP, 흐름의 문제는 BP, 여정의 문제는 SP. 이 분류만 익혀도 문제를 보는 눈이 달라진다.

기준과 현실의 거리를 측정하기

■ 진단 없는 처방은 없다

앞에서 '표준이 있는 것'과 '표준이 지켜지는 것'은 다르다고 했다. 그리고 사례들을 보며 '기준과 현실의 거리를 측정하지 않은 게 문제의 뿌리'라고 정리했다. 그렇다면 이제 자연스럽게 이런 질문이 나온다. '그럼 그 거리를 어떻게 측정하지?'

가장 원시적인 방법은 사람이 직접 보는 거다. 담당자나 외주 업체가 페이지를 하나하나 열어보며 '버튼 색이 맞나, 메뉴 위치가 맞나, 오류 안내가 제대로 되나'를 체크리스트로 확인하는 식이다. 이 방법은 정확할 수 있지만, 치명적인 약점이 있다. 너무 느리고, 너무 지치고, 사람마다 판단이 다르다는 점이다.

생각해보자. 사이트 하나에 페이지가 수백, 수천 개다. 각 페이지마다 따져야 할 규칙이 수십 개씩이다. 이걸 사람이 손으로 다 보려면 몇 주, 몇 달이 걸린다. 그러는 사이 사이트는 또 바뀐다. 게다가 사람이 보면 '이 색이 KRDS 기준 안에 드는 색인가'를 눈대중으로 판단하게 되는데, 이건 부정확하다. 미묘한 색 차이, 미묘한 간격 차이는 눈으로 잡아내기 어렵다.

■ 그래서 '자동 진단'이 필요하다

이 지점에서 자동 진단의 가치가 빛난다. 사람이 눈으로 하던 일을 도구가 대신 하는 거다. 사이트 주소만 넣으면, 도구가 페이지를 자동으로 돌아다니며 화면의 색·글꼴·간격을 수치로 읽고, 버튼·입력칸·메뉴 같은 부품이 제대로 만들어졌는지 확인하고, 흐름이 끊기는 곳은 없는지 점검한다. 그리고 그 결과를 '우리 사이트가 KRDS 846규칙 중 무엇을 지켰고 무엇을 어겼는지'로 정리해 보여준다.

이게 바로 우리가 만들고 있는 ViewCheck의 역할이다. ViewCheck는 공공 웹사이트의 주소를 입력하면, KRDS 846규칙(DS 120 + CP 446 + BP 108 + SP 172)을 기준으로 사이트를 자동 진단하는 서비스다. 사람이 수천 페이지를 일일이 보던 일을, 도구가 빠르게 대신 해준다. 앞에서 말한 '사람은 방향을 잡고, 도구는 디테일을 챙긴다'는 역할 분담을 실제로 구현한 셈이다.

조금 더 구체적으로 말하면 이렇다. ViewCheck로 사이트를 분석하면, 분석 결과 화면 맨 위에 '점수 카드'가 나온다. DS·CP·BP·SP 네 영역별로 우리 사이트가 몇 점인지, 어느 영역이 강하고 어느 영역이 약한지를 한눈에 보여준다. 앞에서 배운 '네 개의 서랍'이 그대로 점수로 환산돼 나오는 거다. '우리 사이트는 DS는 괜찮은데 SP가 약하구나' '버튼 관련 CP에서 많이 걸리는구나' 하는 식으로, 막연했던 '제각각 느낌'이 구체적인 숫자와 항목으로 바뀐다.

■ 측정이 주는 진짜 가치 — 모호함을 구체로 바꾼다

자동 진단의 진짜 가치는 단순히 '빠르다'에 있지 않다. 모호한 느낌을 구체적인 항목으로 바꿔준다는 데 있다.

앞에서 '느낌으로 검수하는 것의 한계'를 이야기했다. "좀 더 깔끔하게 해주세요" 같은 모호한 피드백은 사람마다 다르게 해석되고, 검증할 수도 없다. 그런데 진단 결과가 있으면 이야기가 달라진다. "주 버튼과 보조 버튼의 위계가 없는 페이지가 12개 있습니다" "오류 안내가 입력칸과 떨어져 있는 화면이 5개 있습니다"처럼, 구체적인 항목과 위치로 말할 수 있게 된다.

이건 발주와 검수의 판도를 바꾼다. 업체에 '잘 만들어 주세요'가 아니라 '이 항목들을 이렇게 고쳐 주세요'라고 말할 수 있고, 산출물을 받았을 때도 '느낌'이 아니라 '점수와 항목'으로 검증할 수 있다. 모호한 요구가 구체적인 요구가 되고, 구체적인 요구는 검수 가능한 요구가 된다. 담당자가 끌려다니지 않고 주도권을 쥐게 되는 거다.

또 하나, 측정은 '우선순위'를 알려준다. 846개를 다 한꺼번에 고칠 수는 없다. 진단 결과를 보면 어느 영역이 가장 약한지, 어떤 문제가 가장 자주 반복되는지가 보인다. 그러면 '영향 큰 것부터 순서대로' 고쳐갈 수 있다. 앞에서 '846개에 겁먹지 말고 우선순위를 잡으라'고 했는데, 그 우선순위를 잡아주는 게 바로 진단이다.

■ 한 번이 아니라 계속 — 측정은 습관이어야 한다

진단의 가치는 한 번 측정하고 끝나는 게 아니라, 주기적으로 반복할 때 더 커진다. 사이트는 살아 있는 생물 같아서, 콘텐츠가 추가되고 페이지가 늘어나면서 계속 변한다. 오늘 깔끔하게 정리한 사이트도, 새 부서가 새 페이지를 추가하면서 다시 제각각이 되기 시작한다.

그래서 '한 번 고쳤다'로 끝내면 안 된다. 정기적으로 진단해서 '다시 어긋나기 시작한 곳'을 빨리 잡아내는 게 중요하다. 건강검진을 한 번 받았다고 평생 건강이 보장되지 않는 것과 같다. 주기적으로 측정하고, 어긋난 곳을 그때그때 바로잡는 습관. 이게 일관된 공공 웹을 '유지'하는 진짜 비결이다. 자동 진단 도구는 이 '주기적 측정'을 부담 없이 가능하게 만들어준다. 사람이 매번 수천 페이지를 보는 건 불가능하지만, 도구는 몇 번의 클릭으로 해낸다.

그래서 무엇부터 시작할까

■ 1단계: 우리 사이트의 현재 위치를 안다

KRDS 이야기를 듣고 '좋은 건 알겠는데 뭐부터 해야 하지' 싶을 거다. 가장 먼저 할 일은 의외로 단순하다. '우리 사이트가 지금 어디쯤 있는지'를 아는 것이다.

지도 없이 길을 찾을 수 없듯, 현재 위치를 모르면 목표까지의 경로도 그릴 수 없다. 그래서 첫걸음은 진단이다. 우리 사이트가 KRDS 846규칙 중 무엇을 지키고 무엇을 어기고 있는지, 네 영역 중 어디가 강하고 어디가 약한지를 객관적인 수치로 파악하는 것. 이게 모든 개선의 출발점이다. 막연히 '우리 사이트 좀 별로인 것 같아'가 아니라, 'DS 점수는 괜찮은데 CP·SP가 약하다'처럼 구체적으로 알아야 다음 단계가 보인다.

■ 2단계: 영향 큰 것부터 우선순위를 잡는다

현재 위치를 알았다면, 다음은 우선순위다. 앞서 강조했듯 846개를 한 번에 다 잡을 필요도 없고, 그래서도 안 된다. 자주 걸리고 사용자 영향이 큰 문제부터 손대는 게 정석이다.

예를 들어 '버튼이 어디 있는지 모르겠는 화면'은 거의 모든 사용자에게 매번 영향을 준다. 이런 건 우선순위가 높다. 반면 특정 페이지에만 있는, 잘 안 쓰이는 특수 부품의 미세한 문제는 우선순위가 낮다. 진단 결과를 보면 어떤 문제가 몇 개의 페이지에서 얼마나 자주 발생하는지가 보이니, 그걸 근거로 '이번 분기엔 이것부터' 하고 정할 수 있다.

■ 3단계: 개편 시점에 맞춰 점진적으로 적용한다

'기존 사이트도 다 바꿔야 하나요'라는 질문에 '한 번에 다 바꿀 필요 없다'고 답했던 걸 기억할 거다. 가장 현실적인 전략은 '점진적 적용'이다.

지금 당장 멀쩡히 돌아가는 사이트를 통째로 뒤엎는 건 비용도, 위험도 크다. 대신 자연스러운 개편·신규 제작 시점에 KRDS 기준을 녹여 넣는 게 좋다. 새 페이지를 만들 땐 처음부터 기준에 맞게, 기존 페이지는 개편 차례가 올 때 기준에 맞춰서. 이렇게 하면 큰 충격 없이, 사이트가 시간이 지날수록 점점 더 KRDS에 가까워진다. 중요한 건 '방향'이다. 한 번에 100점이 아니라, 매번 조금씩 나아지는 방향으로 굴러가게 만드는 것.

■ 4단계: 기준을 발주·검수에 녹인다

마지막으로, KRDS를 '우리 일하는 방식' 자체에 녹여 넣는 단계다. 새 사업을 발주할 때 'KRDS 기준을 준수할 것'을 요구사항에 명시하고, 산출물을 검수할 때 그 기준으로 확인한다. 그러면 외주 업체도 처음부터 기준에 맞게 만들게 되고, 담당자도 '느낌'이 아니라 '기준'으로 검수할 수 있다.

이 단계까지 오면, KRDS는 더 이상 '외워야 할 숙제'가 아니라 '일을 줄여주는 도구'가 된다. 매번 새로 결정하느라 드는 시간, 검수하면서 헤매는 시간, 민원에 대응하느라 쓰는 시간이 '공통 기준' 덕분에 줄어든다. 도입의 첫머리에서 'KRDS를 알면 일이 줄어든다'고 했던 말의 의미가 여기서 완성된다.

마무리

긴 글을 따라와 줘서 고맙다. 처음의 질문으로 돌아가 보자. "왜 공공 사이트마다 버튼·색·메뉴가 다 다를까."

답은 이제 분명하다. 각 기관이, 각 부서가, 각 사업이, 공통된 기준 없이 각자 알아서 만들었기 때문이다. 누구도 일을 대충 한 게 아니지만, 합의된 기준 없이 각자의 최선을 모으니 전체로 보면 누더기가 됐다. 이건 개인의 잘못이 아니라 시스템의 부재가 만든 결과다.

그리고 그 시스템의 부재를 메우는 게 바로 디자인 시스템이고, 대한민국 공공 영역에서 그 디자인 시스템을 국가 차원으로 정리한 게 KRDS다. KRDS는 색·글꼴 같은 기본(DS), 버튼·폼 같은 부품(CP), 입력·검증 같은 패턴(BP), 검색·신청 같은 여정(SP)까지, 공공 웹을 구성하는 거의 모든 요소에 '이렇게 만들면 된다'는 기준을 제시한다. 그게 846개의 규칙으로 정리돼 있다. 846이라는 숫자에 겁먹을 필요는 없다. 외우는 게 아니라 구조를 이해하고 우선순위를 잡는 것, 그리고 디테일은 도구에 맡기는 것이 정답이다.

마지막으로 한 번 더 강조하고 싶다. KRDS는 '부담을 더하는 규제'가 아니라 '부담을 더는 도구'다. 기준이 있으면 매번 새로 결정하지 않아도 되고, 담당자가 바뀌어도 품질이 유지되고, 발주와 검수에서 끌려다니지 않게 된다. 무엇보다, 떠날 수 없는 사용자에게 더 나은 공공 서비스를 줄 수 있다. 일관성은 친절이고, 친절은 공공의 의무다.

그 첫걸음은 '우리 사이트가 지금 어디쯤 있는지'를 아는 것이다. 막연한 느낌이 아니라 구체적인 숫자로. 혹시 '우리 사이트는 KRDS 기준에서 얼마나 떨어져 있을까' 궁금하다면, 한번 직접 확인해보는 걸 권한다. krds.viewcheck.co.kr 에서 사이트 주소만 넣으면 KRDS 846규칙 기준으로 무료 진단을 체험할 수 있다. DS·CP·BP·SP 네 영역 점수가 상단 점수 카드로 한눈에 정리돼 나오니, 이 글에서 이야기한 '네 개의 서랍'이 실제 우리 사이트에서 어떻게 채워져 있는지 눈으로 확인할 수 있을 거다.

거창하게 마음먹을 필요 없다. 그냥 우리 사이트 주소 하나 넣어보는 것, 거기서부터 시작하면 된다. 현재 위치를 알면 길이 보이고, 길이 보이면 한 걸음씩 나아갈 수 있다. 이번 주는 '공공웹이 제각각인 이유'를 함께 들여다봤으니, 다음엔 그 제각각을 어떻게 '하나의 언어'로 다듬어 가는지 더 구체적인 이야기로 이어가 보겠다. 다음 글에서 또 만나자.