KRDS가 대체 뭐길래

[월·개념] KRDS가 대체 뭐길래? 공공웹 담당자라면 알아야 할 디자인시스템 기본

"KRDS 적용했어요?"

올해 들어 공공기관 웹 담당자들 사이에서 부쩍 자주 오가는 말이다. 회의에서, 사업 발주 검토 자리에서, 심지어 부서 단톡방에서도 이 네 글자가 튀어나온다. 그런데 막상 "KRDS가 정확히 뭐예요?"라고 되물으면, 의외로 명확하게 답하는 사람이 드물다. "디자인 가이드 같은 거 아니에요?" "정부에서 만든 표준이라던데..." 정도에서 대화가 멈춘다.

나도 처음엔 그랬다. 공공 사이트를 몇 개 만들어보고 운영도 해봤지만, KRDS라는 말을 처음 들었을 때 머릿속에 떠오른 건 '또 새로운 규제 하나 생겼구나'였다. 솔직히 말하면 약간 귀찮은 기분도 있었다. 가뜩이나 접근성 점검에, 보안 점검에, 품질관리 지침까지 챙길 게 많은데 여기에 또 디자인 표준까지 맞춰야 한다니.

그런데 실제로 KRDS를 들여다보고 나서 생각이 좀 바뀌었다. 이게 단순히 "버튼은 이 색으로 쓰세요" 수준의 디자인 잔소리가 아니었다. 오히려 공공 웹사이트를 만들고 운영하는 사람 입장에서 '진작 이런 게 있었으면 덜 고생했을 텐데' 싶은 부분이 많았다.

이 글은 KRDS를 처음 접하거나, 이름은 들어봤지만 실체가 흐릿한 공공웹 담당자를 위한 입문 글이다. 전문 용어를 최대한 풀어서, 실무자가 "아, 이거구나" 하고 감을 잡을 수 있게 쓰려고 한다. 디자인 전공자가 아니어도, 개발자가 아니어도 괜찮다. 사이트 하나 운영해본 사람이라면 충분히 이해할 수 있는 이야기다.

먼저 결론부터 말하면 이렇다. KRDS는 대한민국 정부가 공공 웹사이트와 앱을 '일관되게, 사용하기 쉽게, 누구나 접근할 수 있게' 만들기 위해 정리해둔 공식 디자인 시스템이다. 색이나 글꼴 같은 시각 요소부터, 버튼·입력폼·내비게이션 같은 화면 부품, 그리고 검색·로그인·민원신청 같은 서비스 흐름까지 — 공공 사이트를 구성하는 거의 모든 요소에 대해 '이렇게 만들면 된다'는 기준을 제시한다.

그리고 여기서부터가 핵심인데, 이 기준이 막연한 권고가 아니라 꽤 구체적인 규칙의 묶음으로 정리돼 있다. 정확히 846개. 이 숫자가 처음엔 부담스럽게 느껴질 수 있지만, 글을 끝까지 읽고 나면 '생각보다 합리적이네' 하고 받아들이게 될 거라고 본다.

조금 더 솔직하게 이야기를 풀어보자. 공공 웹 담당자라는 자리는 생각보다 외롭다. 디자인 전공자가 그 자리에 앉는 경우는 드물다. 대부분은 기획이나 행정 업무를 하다가, 혹은 전산 담당을 겸하다가, 어느 날 "이번 홈페이지 개편 업무는 자네가 맡아"라는 말과 함께 떠안게 된다. 그러고 나면 외주 업체와 회의를 하고, 산출물을 검수하고, 윗선에 보고하고, 민원에 대응하는 일이 한꺼번에 밀려온다. 그 와중에 '디자인이 일관적인가' '접근성은 챙겼나' '품질 기준은 통과하나' 같은 질문에까지 답을 해야 한다. 정작 그걸 판단할 기준은 아무도 손에 쥐여주지 않은 채로 말이다.

내가 KRDS를 처음 진지하게 들여다본 것도 이런 막막함 때문이었다. '잘 만들어 주세요'라고 업체에 말은 하는데, 정작 '잘 만든 게 뭔지' 내 입으로 설명하지 못하는 상황이 반복됐다. 산출물을 받아 들고도 "이게 잘된 건가?"를 확신하지 못했다. 검수 회의에서 "좀 더 깔끔하게 해주세요" 같은 모호한 피드백만 반복하다 보면, 결국 '느낌'으로 통과시키게 된다. 그 느낌이라는 게 사람마다 다르고, 시간이 지나면 또 달라진다는 게 문제였다.

KRDS는 바로 그 '느낌'을 '기준'으로 바꿔주는 도구다. "좀 더 깔끔하게"가 아니라 "주 버튼과 보조 버튼의 위계를 KRDS 기준에 맞춰 주세요"라고 말할 수 있게 된다. 모호한 요구가 구체적인 요구가 되고, 구체적인 요구는 검수 가능한 요구가 된다. 이게 왜 중요한지는 글을 읽어 가면서 점점 더 분명해질 거다.

한 가지 미리 안심시켜 드리자면, 이 글은 KRDS를 '공부해야 할 또 하나의 숙제'로 만들려는 글이 아니다. 오히려 그 반대다. KRDS를 알면 일이 줄어든다는 걸 보여주려는 글이다. 매번 새로 결정하느라 드는 시간, 검수하면서 헤매는 시간, 민원에 대응하느라 쓰는 시간 — 이 모든 게 '공통 기준'이 있으면 줄어든다. 부담을 더하는 규제가 아니라, 부담을 더는 도구로 KRDS를 바라봐 주면 좋겠다.

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

왜 중요한가

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

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

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

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

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

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

조금 더 구체적으로 들어가 보자. 디자인 시스템은 보통 세 가지 층위로 이루어진다. 첫째는 '원칙'이다. 우리는 왜 이렇게 만드는가, 어떤 가치를 우선하는가 같은 방향성이다. 둘째는 '자산'이다. 색·글꼴 같은 기본 단위와 버튼·폼 같은 부품처럼 실제로 가져다 쓰는 재료들이다. 셋째는 '문서'다. 이 자산을 언제, 어떻게 쓰는지를 설명하는 사용 설명서다. 이 세 가지가 갖춰져야 비로소 '시스템'이라 부를 수 있다. 색 팔레트만 정리해뒀다고 디자인 시스템이 되는 게 아니라는 뜻이다.

여기서 흔한 오해 하나를 짚고 넘어가자. 사람들은 디자인 시스템을 '창의성을 제약하는 틀'로 여기곤 한다. "정해진 부품만 쓰면 다 똑같이 생기는 거 아니냐"는 걱정이다. 하지만 실제로는 그 반대에 가깝다. 기본 부품이 정해져 있으면, 만드는 사람은 '버튼을 무슨 색으로 할까' 같은 사소한 결정에 에너지를 쓰지 않아도 된다. 그렇게 아낀 에너지를 '이 페이지에서 사용자가 정말 원하는 게 뭘까' 같은 본질적인 고민에 쓸 수 있다. 제약이 오히려 창의성을 본질로 돌려보내는 셈이다. 글을 쓸 때 맞춤법과 문법이 정해져 있다고 해서 표현이 획일화되지 않는 것과 같은 이치다.

또 하나, 디자인 시스템은 '한 사람의 천재'에 의존하지 않게 해준다. 가이드가 없는 조직은 '디자인 감각이 좋은 그 담당자'가 있을 때만 결과물이 좋다. 그 사람이 부서를 옮기거나 퇴사하면 품질이 뚝 떨어진다. 디자인 시스템은 그 감각을 '조직의 자산'으로 박제해둔다. 담당자가 바뀌어도, 신입이 와도, 외주가 교체돼도 일정 수준 이상의 결과가 나온다. 공공기관처럼 담당자 교체가 잦은 조직에서 이건 특히 큰 의미가 있다.

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

■ 그럼 KRDS는 왜 필요했나?

민간 기업들은 이미 오래전부터 자체 디자인 시스템을 운영해왔다. 큰 IT 기업일수록 수백 명의 디자이너·개발자가 동시에 일하는데, 디자인 시스템이 없으면 제품이 누더기가 되기 때문이다.

공공 영역은 사정이 더 복잡하다. 대한민국에는 중앙부처, 광역·기초 지자체, 공공기관, 산하기관까지 수천 개의 공공 웹사이트가 있다. 이들이 각자 다른 외주 업체에, 다른 시기에, 다른 기준으로 만들어졌다. 그 결과가 어땠는지는 공공 사이트를 몇 군데만 돌아다녀 봐도 알 수 있다.

어떤 사이트는 메뉴가 상단에 있고, 어떤 사이트는 왼쪽에 있다. 어떤 곳은 검색창이 잘 보이는데, 어떤 곳은 한참 찾아야 한다. 신청서 양식의 '다음' 버튼이 어느 사이트는 오른쪽 아래, 어느 사이트는 왼쪽 위에 있다. 국민 입장에서는 기관이 바뀔 때마다 사이트 사용법을 새로 익혀야 하는 셈이다.

이건 단순히 불편의 문제가 아니다. 공공 서비스는 '누구나' 써야 한다. 디지털에 익숙한 사람만 쓰는 게 아니라, 고령층도, 장애가 있는 분도, 디지털 기기에 서툰 분도 똑같이 써야 하는 게 공공 서비스다. 사이트마다 제멋대로면 이분들이 가장 먼저 벽에 부딪힌다.

KRDS는 바로 이 문제를 풀기 위해 정부 차원에서 정리한 표준이다. '공공 웹사이트는 이렇게 만들면 일관되고, 쓰기 쉽고, 접근성도 챙길 수 있다'는 청사진을 제공한다. 한 번 잘 정리해두면 수천 개 사이트가 같은 언어로 만들어질 수 있다는, 꽤 야심 찬 시도다.

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

그리고 이건 단순히 '편의'의 문제를 넘어선다. 공공 서비스는 선택이 아니라 필수인 경우가 많다. 세금을 내고, 증명서를 떼고, 복지를 신청하고, 민원을 넣는 일은 '다른 사이트로 가면 되는' 일이 아니다. 그 기관 사이트가 유일한 창구다. 민간 쇼핑몰이라면 불편하면 떠나면 그만이지만, 공공 서비스는 불편해도 떠날 수 없다. 떠날 수 없는 사용자를 불편하게 만드는 건, 그 자체로 일종의 책임 방기다. 공공 웹의 일관성과 접근성이 '있으면 좋은 것'이 아니라 '있어야 하는 것'인 이유가 여기에 있다.

또 하나 짚고 싶은 건, 공공 웹의 사용자층이 민간보다 훨씬 넓다는 점이다. 특정 연령, 특정 디지털 숙련도의 사람만 쓰는 게 아니다. 스무 살 대학생도, 여든 살 어르신도, 시각장애가 있는 분도, 한국어가 서툰 외국인 주민도 같은 사이트를 써야 한다. 사용자층이 넓다는 건 '가장 약한 고리'에 맞춰 설계해야 한다는 뜻이다. 가장 디지털에 서툰 사람이 쓸 수 있으면 모두가 쓸 수 있지만, 그 반대는 성립하지 않는다. KRDS가 접근성을 단순한 한 영역이 아니라 시스템 전체에 스며든 원칙으로 다루는 배경이다.

민간과 공공의 또 다른 차이는 '기준의 출처'에 있다. 민간 기업은 자사 브랜드에 맞춰 스스로 디자인 시스템을 만들고, 그 기준을 바꾸는 것도 자유롭다. 반면 공공 영역은 '국민 전체'를 대상으로 하기 때문에, 한 기관이 마음대로 정한 기준보다 '국가 차원에서 합의된 공통 기준'이 훨씬 더 의미가 있다. 수천 개 기관이 제각각 자기만의 디자인 시스템을 만든다면, 그건 또 다른 형태의 난립일 뿐이다. KRDS는 '각 기관이 따로 고민하지 않아도 되도록' 국가가 한 번 잘 정리해 공유하는, 일종의 공공재에 가깝다. 기관 입장에서는 '남이 잘 만들어둔 기준을 가져다 쓰는' 셈이라 오히려 부담이 줄어든다.

여기서 한 가지 더. '표준이 있다'는 것과 '표준이 지켜진다'는 것은 다른 문제다. 아무리 좋은 기준이 있어도, 그것이 실제 사이트에 적용됐는지 확인하지 않으면 기준은 문서로만 남는다. 그래서 KRDS의 가치는 '기준을 아는 것'에서 끝나지 않고 '기준과 현실의 거리를 측정하는 것'으로 완성된다. 이 측정을 사람이 수천 페이지에서 일일이 하는 건 불가능에 가깝기 때문에, 자동화된 진단이 표준의 실효성을 떠받치는 또 하나의 축이 된다. 표준을 만드는 일과 표준을 지키는지 확인하는 일은 한 쌍으로 굴러가야 한다.

■ 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(약 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라는 네 개의 큰 서랍이 있다는 것, 각 서랍에 어떤 종류의 규칙이 들어있는지를 알면, 나머지는 필요할 때 찾아보면 된다.

여기서 한 가지 더 안심해도 되는 점. 846개 규칙은 '다 같은 난이도'가 아니다. 상당수는 '이 요소가 있는가/없는가' '이 속성이 붙어 있는가'처럼 비교적 단순하게 판정되는 항목이다. 정말로 까다로운 시각적·맥락적 판단이 필요한 건 그중 일부다. 그래서 '846개를 모두 같은 무게로 짊어진다'는 상상은 과장된 두려움이다. 게다가 한 페이지에 실제로 등장하는 컴포넌트가 그 페이지에서 판정되는 규칙을 결정하기 때문에, 단순한 안내 페이지라면 따지는 규칙 수가 확 줄고, 복잡한 신청 페이지라면 늘어난다. 즉 '페이지의 복잡도만큼만' 규칙이 적용된다. 사이트의 모든 페이지가 846개를 전부 짊어지는 게 아니라는 뜻이다.

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

마지막으로, KRDS를 처음 접하는 분들이 가장 자주 던지는 질문 몇 개를 미리 정리해두자. "KRDS를 안 지키면 처벌받나요?"라는 질문이 많은데, KRDS 자체보다 더 직접적으로 작동하는 건 접근성 관련 법적 의무다. 웹 접근성은 권장이 아니라 법으로 규정된 의무이고, 이건 다음 달 첫 글에서 따로 다룬다. KRDS는 그 법적 의무를 포함해 '잘 만든 공공 웹'의 기준 전반을 아우르는 더 넓은 틀이라고 이해하면 된다. "기존 사이트도 다 바꿔야 하나요?"라는 질문에는 '한 번에 다 바꿀 필요는 없다'가 답이다. 현황을 진단하고, 영향 큰 것부터, 개편 시점에 맞춰 점진적으로 적용하는 게 정석이다. 이 점진적 적용 전략은 글 뒷부분에서 더 구체적으로 다룬다.

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

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

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

흔한 실수·사례

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

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

또 하나 미리 말해두면, 이 사례들은 '잘못'을 지적하기 위한 게 아니라 '구조'를 보여주기 위한 것이다. 같은 증상이라도 원인은 DS·CP·BP·SP 어느 층위에 있느냐에 따라 다르고, 해법도 달라진다. 그래서 사례를 읽을 때 '이건 어느 서랍의 문제일까'를 함께 생각하면, 앞에서 배운 네 영역 구조가 머릿속에서 살아 움직이기 시작한다. 사례는 개념을 현실에 붙여보는 연습이라고 여기면 좋겠다.

■ 사례 하나: 부서마다 다른 '우리 사이트'

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

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

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

이게 바로 DS(디자인 기반 요소) 차원의 문제다. 색·글꼴·간격 같은 기본 단위를 토큰으로 통일하지 않으면, 부서가 늘어날수록 사이트는 누더기가 된다. 디자인 토큰이라는 개념(다음 달에 자세히 다룬다)이 필요한 이유가 여기에 있다.

이 사례에서 정작 중요한 건, 담당자 누구도 일을 '대충' 한 게 아니라는 점이다. 민원 부서 담당자는 자기 페이지를 정성껏 만들었고, 문화 행사 부서 담당자도 마찬가지였다. 각자의 결과물만 보면 다 그럴듯했다. 문제는 '각자' 만들었다는 사실 자체에 있었다. 합의된 기준 없이 각자의 최선을 모으면, 그 합은 최선이 되지 않는다. 오히려 따로 노는 조각들의 모음이 된다. 이건 개인의 역량 문제가 아니라 시스템의 부재 문제다. 그래서 해법도 '담당자를 다그치는 것'이 아니라 '공통 기준을 세우는 것'이어야 한다.

이런 색의 난립은 '리뉴얼할 때' 가장 뼈아프게 드러난다. 기관 상징색을 약간 손보자는 단순한 결정이, 수십 종으로 흩어진 파랑을 일일이 찾아 바꾸는 대공사가 된다. 어디에 어떤 색이 쓰였는지 아무도 모르기 때문이다. 결국 '일단 보이는 것만 바꾸자'가 되고, 미처 못 바꾼 색이 구석구석 남아 또 다른 불일치를 만든다. 부채 위에 부채가 쌓이는 전형적인 악순환이다.

■ 사례 둘: 어디가 버튼인지 모르겠는 화면

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

특히 곤란한 건 '주 버튼'과 '보조 버튼'의 구분이 없을 때다. 신청 페이지에서 '제출'과 '취소' 버튼이 똑같이 생기면, 급한 마음에 취소를 눌러 작성하던 내용이 날아가는 일이 생긴다. 이건 디자인의 문제가 아니라 사고로 이어지는 문제다.

이게 CP(컴포넌트) 차원의 문제다. KRDS는 버튼이라는 부품 하나에 대해서도 크기, 상태(기본·호버·눌림·비활성), 주/보조 위계, 라벨 작성법까지 기준을 제시한다. '버튼 하나에 무슨 규칙씩이나' 싶겠지만, 버튼은 사용자가 가장 자주 누르는 부품이라 작은 일관성이 큰 차이를 만든다.

조금 더 들어가 보자. '버튼이 버튼처럼 안 보인다'는 건 단순히 미관의 문제가 아니다. 사람은 화면을 볼 때 글자를 하나하나 읽기 전에 '덩어리'로 먼저 인식한다. 색이 채워진 네모, 테두리가 있는 영역, 또렷한 라벨 — 이런 시각적 신호가 '여기를 누르면 뭔가 일어난다'는 약속을 만든다. 이 약속이 페이지마다 달라지면, 사용자는 매번 화면을 처음 보는 사람처럼 더듬더듬 탐색해야 한다. 익숙해질 틈이 없다. 공공 사이트는 특히 '가끔 한 번' 들어오는 사용자가 많아서, 이 학습 비용이 더 크게 작용한다.

라벨 표현이 들쭉날쭉한 것도 같은 뿌리의 문제다. 어떤 화면에서는 '확인', 어떤 화면에서는 '완료', 또 어떤 화면에서는 '다음'이라고 적혀 있는데, 정작 하는 일은 같다. 반대로 '신청'과 '제출'이 다른 의미로 쓰이기도 한다. 사용자는 버튼의 글자를 보고 '이걸 누르면 무슨 일이 일어날지'를 예측하는데, 그 예측이 자꾸 빗나가면 점점 클릭을 망설이게 된다. KRDS가 라벨 작성법까지 기준에 포함한 이유가 이것이다. 부품의 모양뿐 아니라 '부품에 적히는 말'까지 일관돼야 사용자가 안심하고 누른다.

비활성 상태 처리도 의외로 자주 놓치는 부분이다. 아직 누르면 안 되는 버튼(예: 필수 항목을 다 채우기 전의 '제출')을 멀쩡한 버튼과 똑같이 보여주면, 사용자는 눌렀는데 아무 반응이 없는 경험을 한다. '고장 났나?' 싶어 몇 번을 더 누르고, 결국 짜증이 쌓인다. 비활성 버튼은 '지금은 누를 수 없다'는 걸 시각적으로 분명히 보여줘야 하고, 가능하면 '무엇을 채워야 활성화되는지'까지 안내해야 한다. 이런 디테일이 쌓여 '쓰기 편한 사이트'와 '답답한 사이트'가 갈린다.

■ 사례 셋: 마지막에 무너지는 신청 흐름

가장 답답한 사례는 '끝까지 갔는데 마지막에 무너지는' 경우다. 어떤 공공 서비스 신청 페이지에서, 사용자가 5단계에 걸쳐 정보를 입력했다. 이름, 주소, 첨부파일, 동의 항목까지 다 채우고 마지막 '제출'을 눌렀다. 그런데 화면 맨 위에 빨간 글씨 한 줄. "필수 항목이 누락되었습니다." 어떤 항목인지, 어디로 가야 하는지는 알려주지 않는다. 처음부터 다시 훑어야 한다.

이쯤 되면 사용자는 그냥 창을 닫는다. 신청을 포기한다. 기관 입장에서는 서비스를 제공할 준비가 다 돼 있었는데, 마지막 한 줄의 불친절한 오류 안내 때문에 민원이 들어오고 이탈이 발생한 거다. 공들여 만든 서비스가 가장 마지막 한 칸에서 무너지는, 가장 아깝고 안타까운 실패다.

이건 BP(기본 패턴)와 SP(서비스 패턴) 차원의 문제다. 오류를 '어떤 항목이, 왜, 어떻게 고쳐야 하는지' 알려주는 방식, 신청이라는 전체 여정을 끊김 없이 이어가는 방식 — KRDS는 이런 흐름에 대해서도 기준을 갖고 있다. 화면 부품 하나하나는 멀쩡해도, 흐름이 끊기면 서비스는 실패한다.

이 사례가 특히 뼈아픈 건, '거의 다 왔는데' 무너진다는 점이다. 사용자는 이미 이름, 주소, 연락처, 첨부파일까지 다 넣느라 시간과 노력을 들였다. 그 매몰비용 위에서 마지막에 막히면, 처음 막힌 것보다 훨씬 큰 좌절을 느낀다. 그리고 이 좌절은 단순히 '한 사람이 신청을 포기했다'로 끝나지 않는다. 그 사람은 전화로 민원실에 문의하거나, 직접 기관을 방문한다. 온라인으로 처리되도록 만든 서비스가, 오류 한 줄 때문에 오프라인 업무 부담으로 되돌아오는 것이다. 담당자가 줄이고 싶었던 바로 그 업무량이 늘어난다.

좋은 오류 안내는 세 가지를 갖춰야 한다. 첫째, '무엇이' 잘못됐는지 — 어떤 항목이 문제인지 콕 집어준다. 둘째, '왜' 잘못됐는지 — 형식이 틀렸는지, 빠졌는지, 중복인지 이유를 알려준다. 셋째, '어떻게' 고치는지 — 올바른 입력 예시나 다음 행동을 제시한다. 그리고 가능하면 문제가 있는 입력칸 '바로 옆에' 안내를 띄워, 사용자가 화면을 위아래로 헤매지 않게 한다. 이 세 가지는 거창한 기술이 아니라 '배려의 순서'다. KRDS는 이 배려를 개인의 센스에 맡기지 않고 패턴으로 못 박아둔다. 누가 만들어도 같은 수준의 친절이 보장되도록 '기준'으로 만들어 둔 것이다.

여기서 중요한 통찰 하나. 사례 하나(DS), 둘(CP)은 '보기에 불편한' 문제였지만, 사례 셋(BP·SP)은 '서비스 자체가 실패하는' 문제다. 색이 조금 안 맞아도 민원은 처리된다. 하지만 신청 흐름이 끊기면 민원 자체가 처리되지 않는다. 그래서 KRDS의 네 영역은 우열이 아니라 '다른 종류의 위험'을 다룬다고 보는 게 맞다. DS·CP가 일상의 불편을 줄인다면, BP·SP는 결정적 순간의 실패를 막는다.

■ 왜 이런 일이 반복될까

이런 문제들이 특정 담당자가 일을 못해서 생기는 게 아니라는 점이 중요하다. 오히려 대부분은 성실하게 일한 결과다. 다만 '공통 기준'이 없었을 뿐이다.

여기엔 공공 조직 특유의 구조적 사정도 한몫 한다. 담당자가 2~3년 주기로 바뀌고, 사업은 단년도 예산으로 쪼개져 발주되며, 외주 업체도 그때그때 달라진다. 이런 환경에서는 '조직 차원의 누적된 디자인 지식'이 쌓이기 어렵다. 앞 담당자가 어떤 기준으로 무엇을 만들었는지가 제대로 인계되지 않으면, 다음 담당자는 또 처음부터 시작한다. 그렇게 '각자의 임기 안에서 각자 최선'을 다한 결과물이 층층이 쌓이면, 사이트는 시간의 지층처럼 서로 다른 양식이 뒤섞인 모습이 된다. 누구의 잘못도 아닌데 결과는 누더기가 되는, 전형적인 '구조의 문제'다. 그래서 해법도 개인이 아니라 구조에서 찾아야 한다. 사람이 바뀌어도 유지되는 '기준'과 '기록', 그리고 그 기준을 자동으로 확인해주는 '도구' — 이 세 가지가 갖춰질 때 비로소 악순환이 끊긴다.

기준이 없으면 각자 최선을 다해도 결과가 제각각이 된다. 발주처도 "KRDS에 맞춰 주세요"라고 명확히 요구하지 못하고, 수주한 업체도 "어떤 기준에 맞춰야 하죠?"라고 되묻는다. 검수하는 쪽도 '무엇을 기준으로 통과/탈락을 판단할지' 애매하다. 결국 '느낌상 괜찮으면 통과'가 되고, 그 느낌은 사람마다 다르다.

KRDS가 의미 있는 건 바로 이 '공통 언어'를 만들어준다는 점이다. 발주할 때 "KRDS 846규칙을 준수해 주세요"라고 적을 수 있고, 만드는 쪽도 그 기준을 보고 작업할 수 있고, 검수하는 쪽도 같은 기준으로 확인할 수 있다. 모두가 같은 자를 들고 재는 셈이다.

조금 더 솔직하게 들여다보면, 이 '기준 없음'의 비용은 눈에 잘 안 보이는 곳에 숨어 있다. 발주 단계에서 기준이 모호하면, 입찰에 참여한 업체마다 견적 기준이 달라진다. 어떤 업체는 '일관성까지 책임지는' 가격을, 어떤 업체는 '일단 화면만 그려주는' 가격을 부른다. 발주처는 둘을 같은 선상에서 비교하게 되고, 대개 싼 쪽이 선택된다. 그렇게 만들어진 사이트는 개별 페이지는 멀쩡해도 전체 일관성이 없고, 그 뒤처리는 다음 담당자의 몫이 된다. 기준의 부재가 '지금 당장은 싸 보이지만 나중에 비싸지는' 선택을 구조적으로 유도하는 것이다.

검수 단계에서도 마찬가지다. '느낌상 괜찮으면 통과'는 검수자에게도 부담이다. 명확한 기준이 없으면, 나중에 문제가 생겼을 때 '왜 통과시켰냐'는 책임이 검수자 개인에게 돌아온다. 반대로 KRDS 같은 공식 기준이 있으면, 검수자는 '이 규칙에 따라 점검했고 이 항목이 미준수였다'고 객관적으로 말할 수 있다. 기준은 만드는 사람을 옥죄는 족쇄가 아니라, 오히려 일하는 모든 사람을 '판단의 책임'에서 해방시켜 주는 받침대에 가깝다.

그래서 KRDS를 '또 하나의 숙제'로 받아들이면 지친다. 대신 '협상과 검수의 공용어'로 받아들이면 일이 한결 가벼워진다. 외주를 줄 때, 결과물을 받을 때, 다음 담당자에게 인수인계할 때 — 모두가 같은 단어로 같은 것을 가리킬 수 있다는 것. 그게 846개 규칙이 주는 진짜 가치다.

실무 적용·체크리스트

그럼 공공 웹 담당자로서 KRDS를 어떻게 받아들이고 시작하면 좋을까. 처음부터 846개를 다 보겠다고 덤비면 지친다. 현실적인 출발점을 정리해본다. 핵심은 '완벽한 준수'가 아니라 '지속 가능한 개선 루틴'을 만드는 것이다. 한 번 크게 손보고 끝내는 게 아니라, 작게라도 계속 나아지는 구조를 만드는 게 공공 조직에서는 훨씬 현실적이고 오래간다.

■ 1단계: 우리 사이트의 '현재 상태'부터 파악한다

가장 먼저 할 일은 새 규칙을 공부하는 게 아니라, 지금 우리 사이트가 어디쯤 와 있는지 아는 것이다. 건강검진을 받아야 어디가 문제인지 알 수 있는 것과 같다. 현황을 모르고 개선부터 하면, 멀쩡한 곳을 손대고 정작 문제인 곳은 놓친다.

이 '현황 파악'이 중요한 또 다른 이유는, 윗선 보고와 예산 확보의 근거가 되기 때문이다. '우리 사이트가 좀 안 좋은 것 같다'는 느낌만으로는 예산을 받기 어렵다. 하지만 '현재 KRDS 준수율이 이 정도이고, 특히 신청 흐름(SP) 영역이 취약하며, 이 부분이 민원 증가와 직결된다'는 구체적 진단이 있으면 이야기가 달라진다. 객관적 수치는 개선의 필요성을 설득하는 가장 강력한 언어다. 진단은 '일을 시작하기 위한 절차'이자 '일을 인정받기 위한 근거' 두 가지 역할을 한다.

이 단계에서 던질 질문들:

· 우리 사이트의 색·글꼴이 페이지마다 일관적인가, 아니면 부서마다 다른가?

· 버튼은 한눈에 '누를 수 있는 것'으로 보이는가? 주/보조 구분이 있는가?

· 입력폼에 라벨과 도움말이 제대로 붙어 있는가?

· 검색·신청 같은 핵심 흐름이 끊김 없이 끝까지 이어지는가?

· 오류가 났을 때 '무엇을 어떻게 고치라'고 알려주는가?

이 질문에 자신 있게 '예'라고 답하기 어렵다면, 그게 바로 개선의 출발점이다.

여기서 흔히 빠지는 함정이 있다. '우리 사이트는 작년에 개편했으니 괜찮을 것'이라는 막연한 안심이다. 그런데 개편을 했다는 사실과 KRDS 기준에 맞다는 사실은 별개다. 개편 시점에 KRDS를 명시적 기준으로 삼지 않았다면, 새로 만든 화면도 '예쁘지만 기준에서 벗어난' 상태일 수 있다. 오히려 최신 화면일수록 '트렌디한 디자인'을 좇다가 접근성이나 일관성을 놓치는 경우가 있다. 그래서 '언제 만들었나'가 아니라 '지금 기준에 맞나'를 봐야 한다.

■ 2단계: 네 개의 서랍으로 나눠서 본다

현황을 파악할 때 DS·CP·BP·SP라는 네 서랍을 활용하면 정리가 쉽다.

· DS(기반): 색·글꼴·간격이 통일돼 있는가? → 통일 안 됐다면 토큰화부터

· CP(부품): 버튼·폼·메뉴 같은 부품이 일관적이고 명확한가? → 표준 부품으로 교체

· BP(패턴): 폼 입력·오류 처리 같은 작은 흐름이 매끄러운가? → 흐름 다듬기

· SP(서비스): 검색·신청·로그인 같은 전체 여정이 완결되는가? → 끊긴 지점 보수

이렇게 나눠 보면 '우리 사이트는 부품(CP)은 괜찮은데 흐름(SP)이 약하다' 같은 식으로 약점이 또렷해진다. 막연한 '좀 별로다'가 'CP는 80점인데 SP는 50점' 같은 구체적 진단으로 바뀐다.

이 '네 서랍' 사고법이 실무에서 강력한 이유는, 개선 작업을 '담당 가능한 단위'로 쪼개주기 때문이다. '사이트 전체를 개선하자'는 막막하지만, '이번 분기엔 DS 토큰부터 통일하자'는 손에 잡힌다. 예산을 나눌 때도, 인력을 배치할 때도, 외주 범위를 정할 때도 이 네 서랍이 기준선이 된다. 한꺼번에 다 하려다 아무것도 못 하는 것보다, 한 서랍씩 확실히 채워가는 편이 결국 빠르다.

또 하나, 네 서랍은 '우리가 잘하고 있는 것'도 보여준다. 개선이라고 하면 문제만 찾게 되는데, 진단을 해보면 의외로 '이 영역은 이미 잘 돼 있다'는 부분도 드러난다. 잘하는 걸 알면 자신감이 생기고, 그 강점을 다른 영역으로 확장하는 전략도 세울 수 있다. 진단은 결함 색출이 아니라 '현재 위치 확인'이라는 점을 기억하면, 작업이 한결 덜 무겁다.

네 서랍을 나눠 보는 또 다른 이점은 '대화가 쉬워진다'는 것이다. 윗선에 보고할 때도, 외주 업체와 협의할 때도, '사이트가 좀 별로다' 같은 두루뭉술한 말 대신 'CP는 양호한데 SP가 취약해서 신청 흐름 개선이 시급하다'처럼 또렷하게 말할 수 있다. 같은 네 서랍의 언어를 쓰면, 비전문가인 상급자도 '아, 부품은 괜찮은데 흐름이 문제구나' 하고 직관적으로 이해한다. 전문 용어의 장벽 없이 누구나 같은 그림을 공유하게 되는 것이다. 결국 이 분류 체계는 '진단의 틀'이자 '소통의 틀' 두 역할을 동시에 한다.

■ 3단계: 영향 큰 것부터 우선순위를 정한다

모든 걸 한 번에 고칠 수는 없다. 우선순위 기준은 간단하다. '사용자가 자주 마주치는 곳' + '틀렸을 때 피해가 큰 곳'부터다.

예를 들어 메인 페이지의 주요 버튼, 가장 많이 쓰는 민원신청 흐름, 검색 결과 화면 — 이런 곳은 매일 수많은 사용자가 거쳐 간다. 여기서의 작은 개선이 큰 효과를 낸다. 반면 일 년에 몇 번 안 들어가는 깊숙한 안내 페이지는 우선순위를 뒤로 미뤄도 된다.

이 우선순위 사고법은 한정된 예산과 인력을 가진 공공 조직에 특히 잘 맞는다. '완벽하게 다 고치기'는 어차피 불가능하다. 그렇다면 '같은 예산으로 가장 많은 사용자에게, 가장 큰 차이를' 만드는 곳에 자원을 쓰는 게 합리적이다. 트래픽이 몰리는 핵심 흐름 하나를 제대로 다듬는 게, 잘 안 쓰는 페이지 열 개를 손보는 것보다 체감 효과가 크다. '넓게 얇게'가 아니라 '좁고 깊게' 시작해, 효과를 확인하고, 그 성공을 발판 삼아 범위를 넓혀가는 전략이 오래간다.

접근성 관련 규칙은 우선순위를 항상 위에 둔다. 색 대비, 대체텍스트, 키보드 사용 같은 건 일부 사용자에게는 '불편'이 아니라 '사용 가능/불가능'의 문제이기 때문이다. 공공 서비스는 '모두를 위한 서비스'라는 점에서, 일부 사용자가 아예 쓸 수 없는 상태를 방치하는 건 다른 어떤 불편보다 무겁게 다뤄야 한다. 이건 다음 달에 따로 깊게 다룰 주제다.

우선순위를 정할 때 또 하나 유용한 관점은 '반복 노출'이다. 사이트 전체에 공통으로 들어가는 요소 — 상단 메뉴, 검색창, 푸터, 공통 버튼 스타일 — 는 한 번 고치면 모든 페이지에 효과가 퍼진다. 반대로 특정 한 페이지에만 있는 요소는 아무리 고쳐도 그 페이지에서만 효과가 난다. 그래서 '여러 페이지에 공통으로 쓰이는 것'부터 손대면, 같은 노력으로 훨씬 넓은 개선 효과를 얻는다. 이건 디자인 토큰과 공통 컴포넌트를 먼저 정비하라는 말과도 통한다.

■ 4단계: 한 번 점검하고 끝내지 않는다

KRDS 준수는 '한 번 맞추고 끝'이 아니다. 사이트는 계속 바뀐다. 새 페이지가 추가되고, 부서가 콘텐츠를 올리고, 외주로 일부를 개편한다. 그때마다 다시 기준에서 멀어질 수 있다.

그래서 정기적으로 '지금 우리 사이트가 KRDS 기준에서 얼마나 떨어져 있는지'를 확인하는 습관이 필요하다. 분기에 한 번이든, 개편 직후든, 정기 점검 루틴을 두는 것이다. 이걸 사람이 846개 규칙으로 일일이 확인하긴 현실적으로 어렵다. 그래서 자동 진단 도구의 도움을 받는 게 합리적이다.

특히 '개편 직후 점검'은 강력히 권한다. 많은 조직이 개편에 큰돈을 들이고도, 정작 '기준대로 잘 만들어졌는지'는 확인하지 않은 채 오픈한다. 그러다 오픈 후에 문제가 발견되면, 이미 납품이 끝난 뒤라 수정이 까다로워진다. 개편 산출물을 받는 시점에 진단을 돌려, '계약한 기준대로 만들어졌는가'를 객관적으로 확인하면, 검수의 근거가 명확해지고 추가 비용 없이 보완을 요구할 수 있다. 진단을 '검수의 마지막 관문'으로 두는 것이다.

그리고 점검 결과는 반드시 '기록'해두는 게 좋다. 1분기엔 준수율이 어땠고, 2분기엔 어떻게 바뀌었는지를 남겨두면, 개선의 흐름이 눈에 보인다. 점수가 오르는 추세면 그 자체가 성과 보고 자료가 되고, 떨어지는 추세면 어디서 새는지 빨리 알아챌 수 있다. 일회성 점검은 사진 한 장이지만, 기록된 점검은 동영상이다. 사이트가 어느 방향으로 가고 있는지는 동영상으로만 보인다.

정리하면, 실무 출발점은 거창한 결심이 아니라 '현황 파악 → 네 서랍 분류 → 우선순위 → 정기 점검'이라는 단순한 루틴이다. 이 네 단계를 한 바퀴 돌리고 나면, 다음 바퀴는 훨씬 가볍다. 완벽을 목표로 두면 시작조차 못 하지만, '이번 분기엔 한 바퀴 돌려본다'를 목표로 두면 누구나 시작할 수 있다.

여기까지 읽었다면 한 가지 현실적인 고민이 생길 거다. "취지는 알겠는데, 846개를 사람이 어떻게 다 확인하지?"

맞는 고민이다. 규칙 하나하나를 사람이 눈으로 확인하려면 페이지마다 며칠이 걸린다. 색 대비 값을 일일이 재고, 버튼 크기를 측정하고, 폼마다 라벨을 확인하는 건 비현실적이다. 게다가 사람이 하면 빠뜨리는 게 생기고, 점검하는 사람마다 기준이 흔들린다.

이건 능력의 문제가 아니라 '양과 일관성'의 문제다. 아무리 꼼꼼한 사람도 수백 페이지를 똑같은 집중력으로 끝까지 점검할 수는 없다. 처음 몇 페이지는 빠짐없이 보다가, 뒤로 갈수록 피로해져 놓치는 게 생긴다. 또 어제의 나와 오늘의 나는 같은 화면을 보고도 다른 판단을 내릴 수 있다. '이 정도면 통과'의 기준이 그날의 컨디션에 따라 흔들리는 것이다. 기계는 첫 페이지든 오백 번째 페이지든 똑같은 잣대로, 똑같은 집중력으로 본다. 이 '지치지 않는 일관성'이야말로 자동 진단이 사람을 돕는 핵심 지점이다.

그래서 우리는 이 과정을 자동화하는 ViewCheck을 만들었다. 사이트 주소(URL)를 넣으면, 페이지를 자동으로 열어 화면 구조를 분석하고 KRDS 846규칙을 기준으로 '무엇이 통과했고, 무엇이 미준수이고, 무엇이 해당 없음인지'를 판정해준다. DS·CP·BP·SP 네 영역별로 점수가 나오기 때문에, 앞에서 말한 '네 서랍으로 나눠 보기'가 한 화면에서 바로 된다.

특히 공공 담당자에게 유용한 건, 행안부 전자정부 웹사이트 품질관리 7대 영역(호환성·접근성·개방성·접속성·편의성·효율성·신뢰성)과 KWCAG 접근성 33항목까지 함께 본다는 점이다. KRDS 디자인 준수와 품질·접근성 점검을 따로따로 돌릴 필요 없이, 한 번의 진단으로 전체 그림을 볼 수 있다.

여기서 오해를 막기 위해 분명히 해둘 게 있다. 자동 진단은 '사람의 판단을 대체'하는 게 아니라 '사람의 판단을 돕는' 도구다. 도구가 하는 일은 846개 규칙을 페이지마다 빠짐없이 기계적으로 훑어서, '여기는 통과, 여기는 미준수, 여기는 해당 없음'이라는 1차 분류를 빠르게 해주는 것이다. 사람이 며칠 걸려 할 일을 몇 분으로 줄여준다. 그렇게 정리된 결과를 보고 '무엇을 먼저 고칠지, 어떻게 고칠지'를 결정하는 건 여전히 사람의 몫이다. 도구는 '어디가 아픈지'를 빠르게 짚어주는 건강검진이고, 처방과 치료의 방향은 담당자가 잡는다.

또 하나 실무적으로 중요한 건 '다중 페이지' 진단이다. 사이트는 메인 한 장으로 끝나지 않는다. 메인은 멀쩡한데 깊숙한 신청 페이지가 무너져 있는 경우가 허다하다. 그래서 한 페이지만 보고 '우리 사이트는 괜찮다'고 판단하면 큰 오산이다. 여러 페이지를 한꺼번에 분석해, 사이트 전체의 일관성과 약한 고리를 함께 봐야 진짜 현황이 나온다. 앞서 사례 하나에서 본 '부서마다 다른 사이트' 문제는, 바로 이 다중 페이지 진단에서 또렷하게 드러난다.

말로만 설명하면 와닿지 않으니, 실제 진단 결과 화면을 보자. 아래는 분석을 마치면 가장 먼저 보이는 상단 점수 카드다. 네 카테고리 점수와 전체 준수율이 한눈에 들어온다. (캡쳐는 URL·도메인·기관명을 가린 것이다.)

마무리

정리해보자. KRDS는 공공 웹사이트를 '일관되게, 쓰기 쉽게, 누구나 접근할 수 있게' 만들기 위한 정부 공식 디자인 시스템이고, DS(120)·CP(446)·BP(108)·SP(172) 네 영역, 총 846개 규칙으로 구성된다. 846이라는 숫자에 겁먹을 필요는 없다. 구조를 이해하고, 현황을 파악하고, 영향 큰 것부터 우선순위를 잡아 개선해 나가면 된다.

오늘 글의 핵심을 한 줄로 줄이면 이렇다. "KRDS는 새로운 규제가 아니라, 모두가 같은 자로 재게 해주는 공통 언어다."

조금 더 길게 정리해보자면 이렇다. 첫째, KRDS는 '기초(DS) → 부품(CP) → 패턴(BP) → 서비스(SP)'로 쌓이는 레이어 구조다. 이 구조만 머리에 넣어두면, 앞으로 어떤 규칙을 만나도 '아, 이건 부품 차원이구나' '이건 흐름 차원이구나' 하고 자리를 잡을 수 있다. 둘째, 846이라는 숫자는 암기 대상이 아니라 '꼼꼼함의 증거'다. 사람은 구조와 우선순위를 잡고, 세부 디테일은 도구에 맡기면 된다. 셋째, KRDS는 일을 늘리는 규제가 아니라 발주·검수·인수인계의 공용어로서 일을 줄여주는 도구다. 이 세 가지만 가져가도 오늘 글의 절반은 챙긴 셈이다.

그리고 마지막으로 강조하고 싶은 건, 시작의 문턱이 생각보다 낮다는 점이다. KRDS를 '완벽히 공부한 다음에 시작하자'고 미루면 영영 시작 못 한다. 오히려 '일단 우리 사이트가 지금 어디쯤인지 한번 재보자'에서 출발하는 게 맞다. 현황을 알면 막연한 불안이 구체적인 할 일 목록으로 바뀌고, 할 일이 보이면 우선순위를 잡을 수 있고, 우선순위가 잡히면 한 걸음씩 나아갈 수 있다. 완벽한 이해가 아니라 첫 측정이 출발점이다.

다음 글(이번 주 수요일)에서는 '디자인 가이드 없이 만든 공공 사이트가 실제로 어떻게 망가지는지'를 익명 사례로 더 구체적으로 풀어보겠다. 오늘 개념으로 잡은 그림이 실전에서 어떻게 어긋나는지 보면 KRDS의 필요성이 훨씬 더 피부로 와닿을 거다.

그 전에, 우리 사이트가 지금 어디쯤 와 있는지 궁금하다면 직접 한번 확인해보길 권한다. ViewCheck(krds.viewcheck.co.kr)에서 URL만 넣으면 KRDS 846규칙 기준 자가 진단을 무료로 체험할 수 있다. 막연한 '괜찮겠지'를 구체적인 점수로 바꿔보는 것, 그게 모든 개선의 첫걸음이다.

부담 갖지 않아도 된다. 진단을 한번 돌려본다고 해서 당장 무언가를 고쳐야 하는 건 아니다. '우리 사이트의 현재 점수가 몇 점이고, 어느 영역이 강하고 어느 영역이 약한지'를 아는 것만으로도 충분한 출발이다. 그 결과를 보고 '아, 우리는 부품(CP)은 괜찮은데 흐름(SP)이 약하구나' 하고 감을 잡으면, 다음에 무엇을 공부하고 무엇을 먼저 손볼지가 자연스럽게 보인다. 이번 한 달 동안 KRDS 입문을 함께 따라오면, 그 점수표가 점점 더 또렷하게 읽히기 시작할 거다.

이번 주는 '개념'으로 시작했지만, 한 해 동안 우리는 디자인 토큰, 컴포넌트, 서비스 패턴, 웹 접근성, 성능, 보안까지 공공 웹을 둘러싼 거의 모든 주제를 차근차근 짚어갈 예정이다. 매주 월·수·금, 한 번에 다 소화하려 하지 말고 한 편씩 편하게 읽어주면 된다. 오늘 'KRDS가 뭔지' 큰 그림을 잡았다는 것만으로도, 당신은 이미 막막함에서 한 걸음 빠져나온 셈이다. 처음부터 모든 걸 다 알 필요는 없다. 오늘 잡은 그 큰 그림 위에, 앞으로 한 조각씩 지식을 얹어가면 된다. 다음 글에서 또 만나자.