KRDS 846규칙, DS·CP·BP·SP가 뭔가요

공감·문제제기

"그래서 846개가 정확히 뭐예요?"

요즘 공공웹 담당자들과 이야기를 나누다 보면 거의 빠지지 않고 나오는 질문이다. KRDS라는 말은 어디선가 들어봤고, '846규칙'이라는 숫자도 어렴풋이 기억하는데, 막상 그 846개가 어떻게 생겨먹은 건지, 무엇을 기준으로 나뉜 건지 물으면 대부분 말끝을 흐린다. "그게... 디자인 규칙 모음 아니에요?" 정도에서 대화가 멈춘다. 나도 처음엔 똑같았으니, 누구를 탓할 생각은 전혀 없다.

솔직히 고백하자면, 나도 처음 '846규칙'이라는 표현을 들었을 때 가장 먼저 든 감정은 한숨이었다. 846. 숫자가 일단 부담스럽다. 100개도 아니고, 200개도 아니고, 846개라니. '이걸 다 봐야 한다고?' 싶었다. 공공 사이트 하나 운영하는 것만으로도 챙길 게 산더미인데, 여기에 846개짜리 체크리스트까지 얹어진다고 생각하니 시작도 하기 전에 진이 빠졌다.

그런데 막상 그 846개의 '안쪽'을 들여다보고 나서 생각이 완전히 바뀌었다. 846개는 무작정 늘어놓은 숙제 목록이 아니었다. 그것은 딱 네 개의 서랍으로 깔끔하게 정리돼 있었다. DS·CP·BP·SP. 이 네 글자만 이해하면 846이라는 숫자는 더 이상 위협적인 벽이 아니라, 오히려 '아, 이런 순서로 정리해놨구나' 하고 안심하게 되는 지도가 된다.

이 글은 바로 그 네 글자, DS·CP·BP·SP가 무엇인지를 처음 접하는 공공웹 담당자에게 쉬운 비유로 풀어주는 입문 글이다. 디자인 전공자도, 개발자도 아니어도 괜찮다. 사이트 하나 운영해본 사람, 혹은 개편 사업을 한 번이라도 검수해본 사람이라면 충분히 따라올 수 있는 이야기로 쓰려고 한다. 전문 용어는 최대한 풀고, 어려운 개념은 일상의 비유로 바꿔서, '아 이거였구나' 하고 무릎을 치게 만드는 게 목표다.

먼저 한 문장으로 결론을 박아두자. KRDS 846규칙은 공공 웹사이트를 구성하는 모든 것을 '기초 → 부품 → 패턴 → 서비스'라는 네 개의 층으로 나눠 정리한 기준집이고, 그 네 층의 이름이 각각 DS(120개)·CP(446개)·BP(108개)·SP(172개)다. 이 네 숫자를 더하면 정확히 846이 된다. 오늘 글을 끝까지 읽고 나면, 이 한 문장이 머릿속에 사진처럼 박힐 것이다. 그게 이 글의 유일하고도 분명한 목표다.

조금 더 솔직한 이야기를 해보자. 공공웹 담당자라는 자리는 생각보다 외롭고, 또 막막하다. 디자인을 전공한 사람이 그 자리에 앉는 경우는 드물다. 대부분은 기획이나 행정을 하다가, 혹은 전산 업무를 겸하다가, 어느 날 "이번 홈페이지 개편은 자네가 맡아"라는 말과 함께 떠안는다. 그러고 나면 외주 업체와 회의하고, 산출물을 검수하고, 윗선에 보고하고, 민원에 대응하는 일이 한꺼번에 밀려온다. 그 와중에 '이 디자인이 KRDS에 맞나' '846규칙 중 뭘 어겼나' 같은 질문에까지 답해야 하는데, 정작 그 846규칙의 뼈대조차 손에 쥐어진 적이 없다.

나는 이 글이 바로 그 '뼈대'를 손에 쥐여주는 역할을 했으면 한다. 846개를 다 외우자는 게 아니다. 846개가 어떤 원리로 네 서랍에 나뉘어 들어 있는지, 그 구조만 이해하면 된다. 구조를 알면 '이 문제는 어느 서랍에서 찾으면 되겠구나'가 감으로 잡히고, 그러면 846개는 더 이상 외울 대상이 아니라 '필요할 때 열어보는 서랍장'이 된다. 이 글의 흐름은 이렇다. 먼저 '디자인 시스템'이라는 말과 '규칙으로 정리한다'는 발상을 레고에 빗대 풀고, 846개가 왜 네 층으로 나뉘는지를 설명한다. 그다음 DS·CP·BP·SP를 하나씩, 비유와 함께 깊게 들여다본다. 이어서 '846개에 겁먹지 않아도 되는 이유'를 짚고, 실무에서 이 구조가 어떻게 쓰이는지를 익명 사례로 보여준 뒤, 마지막으로 '그래서 우리는 무엇부터 시작하면 되는지'를 단계로 정리한다. 편하게 읽어 내려가면 된다.

한 가지 미리 안심시켜 드리자면, 이 글은 KRDS를 '공부해야 할 또 하나의 숙제'로 만들려는 글이 아니다. 오히려 그 반대다. 846규칙의 구조를 알면 일이 줄어든다는 걸 보여주려는 글이다. 매번 새로 결정하느라 드는 시간, 검수하면서 헤매는 시간, 민원에 대응하느라 쓰는 시간 — 이 모든 게 '공통 기준'이 있으면 줄어든다. 부담을 더하는 규제가 아니라, 부담을 더는 도구로 846규칙을 바라봐 주면 좋겠다. 실제로 나는 이 구조를 이해하고 나서, 외주 업체와의 회의 시간이 눈에 띄게 짧아지는 경험을 했다. 막연히 '예쁘게 해주세요'를 반복하던 회의가, '이 부분은 어느 층의 문제이니 이렇게 고쳐주세요'라는 구체적 합의로 바뀌었기 때문이다. 회의가 짧아진다는 건 곧 야근이 줄어든다는 뜻이다. 이게 농담이 아니다.

그리고 솔직히, 나는 이 '846'이라는 숫자가 처음엔 일종의 마케팅 과장이 아닐까 의심했다. '규칙이 많아 보이게 하려고 잘게 쪼갠 거 아냐?' 싶었던 거다. 하지만 네 서랍을 직접 열어보고 나서는 그 의심을 거뒀다. 846개는 억지로 쪼갠 숫자가 아니라, 공공 웹을 구성하는 요소를 '기초 → 부품 → 패턴 → 서비스' 순으로 빠짐없이 적다 보니 자연스럽게 그 정도가 된 것이었다. 오히려 '이만큼 꼼꼼하게 따져야 제대로 된 공공 웹이 나오는구나'를 깨닫게 됐다. 이 깨달음의 과정을 독자도 함께 밟아갔으면 한다.

846을 네 서랍으로 나누는 발상

■ 디자인 시스템과 '규칙으로 정리한다'는 말부터 풀어보자

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

자, 그런데 여기서 한 발 더 들어가 보자. 레고를 '잘 정리해둔다'는 건 어떤 의미일까? 단순히 블록을 박스에 다 쏟아붓는 게 아니다. 기본 블록은 기본 블록끼리, 바퀴는 바퀴끼리, 특수 부품은 특수 부품끼리 칸을 나눠 정리해둬야 '잘 정리했다'고 말할 수 있다. 그래야 조립할 때 필요한 부품을 바로 꺼낼 수 있다. KRDS가 846개의 규칙을 DS·CP·BP·SP 네 칸으로 나눈 것이 바로 이 '칸 나누기'다. 846개를 한 박스에 다 쏟아부으면 그건 그냥 혼돈이지만, 네 칸으로 나눠 정리하면 '쓸 수 있는 도구'가 된다.

그러니 오늘 우리가 진짜로 배워야 할 건 846개 각각이 아니다. '이 네 칸이 각각 무엇을 담는 칸인가'다. 이것만 이해하면, 새로운 규칙을 만났을 때 '아, 이건 부품 얘기니까 CP 칸이겠네' '이건 흐름 얘기니까 BP 칸이겠네' 하고 자동으로 분류가 된다. 분류가 되면 두려움이 사라진다. 모르는 게 846개가 아니라, '이 규칙이 어느 칸인지'만 알면 되는 문제로 줄어들기 때문이다.

왜 이렇게 칸을 나눠야 하는지, 반대로 생각해보면 더 분명해진다. 만약 846개가 아무 순서 없이 1번부터 846번까지 죽 나열돼 있다고 상상해보자. '우리 사이트 신청 페이지의 오류 안내가 이상한데' 하는 문제가 생겼을 때, 그 846개 목록을 처음부터 끝까지 훑어야 관련 규칙을 찾을 수 있다. 끔찍하다. 하지만 '오류 안내'가 '흐름'의 문제이고 흐름은 BP 칸에 있다는 걸 알면, 108개짜리 BP 서랍만 열면 된다. 네 칸으로 나눈다는 건 이렇게 '찾는 비용'을 극적으로 줄이는 일이다.

여기서 흔한 오해 하나를 짚자. 사람들은 규칙이 많으면 무조건 부담이라고 여긴다. 하지만 잘 분류된 846개는 분류 안 된 100개보다 다루기 쉽다. 분류가 곧 이해이기 때문이다. 도서관에 책이 수만 권 있어도 우리가 원하는 책을 5분 만에 찾는 건, 책이 적어서가 아니라 분류 체계(서가·청구기호)가 잘 잡혀 있어서다. KRDS의 DS·CP·BP·SP는 846개 규칙의 청구기호인 셈이다. 숫자가 846개라는 사실보다, 그 846개가 '찾을 수 있게' 정리돼 있다는 사실이 훨씬 더 중요하다.

조금 더 풀어보자. 디자인 시스템은 보통 세 가지 층위로 이루어진다고들 한다. 첫째는 '원칙'이다. 우리는 왜 이렇게 만드는가, 어떤 가치를 우선하는가 같은 방향성이다. 둘째는 '자산'이다. 색·글꼴 같은 기본 단위와 버튼·폼 같은 부품처럼 실제로 가져다 쓰는 재료들이다. 셋째는 '문서'다. 이 자산을 언제, 어떻게 쓰는지 설명하는 사용 설명서다. 이 세 가지가 갖춰져야 비로소 '시스템'이라 부를 수 있다. 색 팔레트만 정리해뒀다고 디자인 시스템이 되는 게 아니라는 뜻이다. KRDS의 846규칙은 이 세 층위 중에서도 특히 '자산'과 '문서'를 아주 구체적인 규칙의 형태로 못 박아둔 것이라고 보면 된다. '이렇게 하는 게 좋다'는 막연한 권고가 아니라, '이 버튼은 이런 상태를 가져야 하고, 이 입력칸은 이런 안내를 달아야 한다'는 식으로 검증 가능한 문장으로 적혀 있다는 게 핵심이다.

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

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

■ 그런데 왜 굳이 '국가 차원'의 규칙이 필요했나

여기서 잠깐, '846규칙을 왜 정부가 정리했나'를 짚고 가자. 민간 기업들은 이미 오래전부터 자체 디자인 시스템을 운영해왔다. 큰 IT 기업일수록 수백 명의 디자이너·개발자가 동시에 일하는데, 공통 기준이 없으면 제품이 누더기가 되기 때문이다. 공공 영역은 사정이 훨씬 더 복잡하다. 대한민국에는 중앙부처, 광역·기초 지자체, 공공기관, 산하기관까지 수천 개의 공공 웹사이트가 있다. 이들이 각자 다른 외주 업체에, 다른 시기에, 다른 기준으로 만들어졌다. 그 결과가 어땠는지는 공공 사이트 몇 군데만 돌아다녀 봐도 안다.

어떤 사이트는 메뉴가 상단에 있고, 어떤 사이트는 왼쪽에 있다. 어떤 곳은 검색창이 잘 보이는데, 어떤 곳은 한참 찾아야 한다. 신청서의 '다음' 버튼이 어느 사이트는 오른쪽 아래, 어느 사이트는 왼쪽 위에 있다. 국민 입장에서는 기관이 바뀔 때마다 사이트 사용법을 새로 익혀야 하는 셈이다. 이건 단순한 불편을 넘어선다. 공공 서비스는 '누구나' 써야 한다. 디지털에 익숙한 사람만 쓰는 게 아니라, 고령층도, 장애가 있는 분도, 디지털에 서툰 분도 똑같이 써야 한다. 사이트마다 제멋대로면 이분들이 가장 먼저 벽에 부딪힌다.

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

게다가 공공 서비스는 '선택'이 아니라 '필수'인 경우가 많다. 세금을 내고, 증명서를 떼고, 복지를 신청하고, 민원을 넣는 일은 '다른 사이트로 가면 되는' 일이 아니다. 그 기관 사이트가 유일한 창구다. 민간 쇼핑몰이라면 불편하면 떠나면 그만이지만, 공공 서비스는 불편해도 떠날 수 없다. 떠날 수 없는 사용자를 불편하게 만드는 건 그 자체로 일종의 책임 방기다. 한 기관이 마음대로 정한 기준보다 '국가 차원에서 합의된 공통 기준'이 훨씬 더 의미 있는 이유가 여기에 있다. 수천 개 기관이 제각각 자기만의 디자인 시스템을 만든다면 그건 또 다른 난립일 뿐이다. 846규칙은 '각 기관이 따로 고민하지 않아도 되도록' 국가가 한 번 잘 정리해 공유하는, 일종의 공공재에 가깝다. 기관 입장에서는 '남이 잘 만들어둔 기준을 가져다 쓰는' 셈이라 오히려 부담이 줄어든다.

■ 846을 네 층으로 쌓는 구조 — 기초에서 서비스까지

이제 본격적으로 네 서랍을 펼쳐보자. 가장 먼저 이해해야 할 건, 이 네 영역이 '따로 노는 네 묶음'이 아니라 '아래에서 위로 쌓인 네 층'이라는 점이다. 1층 위에 2층이 올라가고, 2층 위에 3층이, 3층 위에 4층이 올라간다. 건물처럼 말이다.

1층은 DS(Design System, 디자인 시스템 기반 요소)다. 색·글꼴·간격·그림자·모서리 둥글기 같은 '시각의 기본 단위'다. 건물로 치면 콘크리트·철근·벽돌 같은 기초 자재다. 약 120개의 규칙이 여기 있다. 2층은 CP(Component, 컴포넌트)다. 그 기본 자재로 만든 '부품'이다. 버튼, 입력칸, 카드, 모달처럼 화면에 보이는 조립 단위. 가장 규칙이 많아 약 446개다. 3층은 BP(Basic Pattern, 기본 패턴)다. 부품들이 모여 만드는 '작은 흐름'이다. 폼을 채우고 검증받기, 동의하고 확인하기 같은 시나리오. 약 108개. 4층은 SP(Service Pattern, 서비스 패턴)다. 사용자가 목적을 이루기 위해 거치는 '전체 여정'이다. 검색·로그인·신청·정책 안내 같은 큰 흐름. 약 172개다.

120 + 446 + 108 + 172 = 846. 이 덧셈이 바로 '846규칙'이라는 이름의 정체다. 외워야 할 건 딱 이 네 숫자뿐이다. 그리고 이 네 숫자에는 나름의 논리가 있다. 왜 CP가 446개로 압도적으로 많을까? 화면에 보이는 부품의 종류가 가장 많고, 부품 하나마다 따질 게 많기 때문이다. 왜 BP가 108개로 가장 적을까? 패턴은 부품보다 추상적이라 종류가 적기 때문이다. 숫자의 크기 자체에 '무엇이 가장 다양한가'가 담겨 있는 셈이다.

이 '쌓이는 구조'가 왜 중요하냐면, 아래층이 흔들리면 위층이 다 무너지기 때문이다. 색(DS)이 엉망이면 버튼(CP)도 엉망이고, 버튼이 엉망이면 폼 흐름(BP)도 엉망이고, 흐름이 엉망이면 민원신청 서비스(SP) 전체가 엉망이 된다. 거꾸로 1층 DS만 단단히 잡아도 위층이 자동으로 한 단계 좋아진다. 그래서 '무엇부터 손대야 하나'를 물으면, 많은 경우 답은 '아래층부터'다. 이 층위 감각은 글 뒷부분 실무 단계에서 다시 등장하니 기억해두자.

이 네 층 구조를 한 번 더 일상의 비유로 굳혀두자. 집을 짓는다고 생각하면 쉽다. DS는 '벽돌·시멘트·목재 같은 자재'다. CP는 그 자재로 만든 '문·창문·계단 같은 부품'이다. BP는 '현관에서 신발 벗고 들어와 거실로 가는 동선' 같은 작은 흐름이다. SP는 '아침에 일어나 씻고 밥 먹고 출근하기까지의 하루 동선' 같은 전체 여정이다. 자재가 부실하면 부품이 부실하고, 부품이 부실하면 동선이 막히고, 동선이 막히면 하루가 엉킨다. 집을 잘 짓는다는 건 이 네 층이 위아래로 잘 맞물린다는 뜻이다. 공공 웹을 잘 만든다는 것도 정확히 같은 의미다. 846규칙은 이 네 층 각각에 '이렇게 하면 잘 맞물린다'는 기준을 빼곡히 채워둔 설계 지침서인 셈이다.

네 서랍을 하나씩 열어본다

■ DS(약 120개) — 눈에 안 띄지만 모든 걸 떠받치는 뼈대

DS는 '디자인 시스템 기반 요소'의 약자다. 가장 아래층, 즉 모든 것의 기초를 다루는 칸이다. 여기 들어가는 건 색·글꼴·간격·그림자·모서리 둥글기 같은 '시각의 원자재'다. 약 120개의 규칙이 있다.

색 하나만 봐도 DS가 다루는 깊이를 알 수 있다. DS에서 색은 그냥 '파랑'이 아니다. 주 색·보조 색·강조 색·경고 색·성공 색·배경 색·테두리 색·비활성 색처럼 '역할별'로 나뉜다. 왜 이렇게까지 나눌까? 색에 역할이 정해져 있어야 '이 빨강은 오류를 뜻한다' '이 파랑은 주된 행동을 뜻한다'는 약속이 사이트 전체에서 일관되게 작동하기 때문이다. 어떤 페이지에선 빨강이 경고인데 다른 페이지에선 빨강이 그냥 장식이면, 사용자는 색이 주는 신호를 믿지 못하게 된다.

글꼴도 마찬가지다. DS는 제목용 큰 글자, 본문용 보통 글자, 캡션용 작은 글자가 위계를 이루도록 크기를 정해둔다. 간격은 보통 8을 기준으로 한 배수 체계(8·16·24·32...)로 정돈한다. 이렇게 기본 단위를 변수처럼 묶어 관리하는 걸 '토큰'이라 부르는데, 이 토큰 이야기는 워낙 중요해서 따로 깊게 다룰 가치가 있다. 오늘은 'DS = 사이트의 톤을 결정하는 보이지 않는 뼈대' 정도로만 기억해도 충분하다.

DS의 핵심은 '일관성의 근원'이라는 데 있다. DS가 잘 잡힌 사이트는 어느 페이지를 가도 같은 색, 같은 글꼴, 같은 간격감을 준다. 그래서 사용자는 '여기는 같은 기관 사이트구나'를 무의식적으로 안다. 반대로 DS가 무너진 사이트는 페이지마다 색이 다르고 글자 크기가 들쭉날쭉해서, 같은 기관인데도 '여러 사이트를 떠도는' 느낌을 준다. DS는 눈에 잘 띄지 않지만, 무너지면 가장 먼저 티가 나는 영역이다. 건물 기초처럼, 평소엔 안 보이다가 금이 가면 온 건물이 흔들리는 그런 영역이다.

조금 더 실무적인 이야기를 보태자. DS에서 자주 문제가 되는 건 '색 대비'다. 옅은 회색 글씨를 흰 배경에 올리면 디자인적으로는 세련돼 보일 수 있지만, 시력이 약한 사용자나 햇빛 아래 화면을 보는 사용자에게는 글자가 거의 안 보인다. DS 규칙은 본문 글자와 배경 사이에 일정 수준 이상의 대비를 요구한다. '예뻐 보이는 옅은 색'과 '읽을 수 있는 색' 사이의 줄타기를 기준선으로 정리해주는 것이다. 또 하나 흔한 건 '간격의 무질서'다. 어떤 요소는 위아래 여백이 12, 어떤 건 13, 어떤 건 17처럼 제멋대로면 화면이 미묘하게 어수선해 보인다. DS의 8배수 간격 체계는 이 무질서를 정돈해, 사용자가 의식하지 못하는 사이에 '깔끔하다'는 인상을 만든다. 사람은 정돈된 간격을 보면 그 이유를 설명하진 못해도 '편안하다'고 느낀다. DS는 바로 그 '설명되지 않는 편안함'을 설계하는 영역이다.

그래서 DS는 '티 안 나게 가장 큰 영향을 주는' 묘한 영역이다. 사용자는 "이 사이트는 색 토큰이 잘 정리됐네"라고 칭찬하지 않는다. 하지만 DS가 잘된 사이트를 쓰면 '왠지 믿음이 가고 편하다'고 느끼고, 안 된 사이트를 쓰면 '뭔가 조잡하고 어수선하다'고 느낀다. 그 느낌의 정체가 바로 DS다. 120개라는 비교적 적은 규칙 수에 비해, DS가 사이트 전체 인상을 좌우하는 힘은 결코 작지 않다.

■ CP(약 446개) — 화면에 보이는 거의 모든 부품

CP는 '컴포넌트', 즉 화면을 구성하는 부품 하나하나를 다루는 칸이다. 446개로 네 영역 중 가장 규칙이 많고, 담당자가 실무에서 가장 자주 마주치는 영역이다. 버튼, 입력칸, 체크박스, 라디오 버튼, 드롭다운, 날짜 선택기, 파일 첨부, 토글, 슬라이더, 탭, 아코디언, 카드, 모달, 툴팁, 배지, 알림, 페이지네이션, 표, 목록, 브레드크럼, 페이지 헤더, 푸터. 화면에 보이는 거의 모든 것이 여기 들어간다.

왜 446개나 될까? 부품 하나마다 따질 게 너무 많기 때문이다. 버튼 하나만 예로 들어보자. 버튼에는 기본 상태, 마우스를 올린 상태, 누른 상태, 비활성 상태, 로딩 상태 같은 여러 모습이 있다. 각 상태가 시각적으로 구분돼야 하고, 라벨 문구는 '무엇을 하는 버튼인지' 명확해야 하며, 크기는 손가락이나 마우스로 누르기 충분해야 하고, 키보드만으로도 조작돼야 하고, 화면 낭독기가 '이건 버튼이다'라고 읽어줄 수 있어야 한다. 버튼 하나에 따질 항목이 이렇게 줄줄이 나온다. 이게 모든 부품마다 반복되니 446이라는 숫자가 된다.

CP를 레고에 다시 빗대면, '레고 부품 카탈로그'다. 어떤 부품이 있고, 각 부품이 어떤 규격이며, 어떤 상태를 가지는지를 빠짐없이 적어둔 목록이다. 446개라고 겁먹을 필요는 없다. 한 페이지에 446개 부품이 다 들어 있는 사이트는 세상에 없다. 단순한 안내 페이지라면 버튼·링크·표 정도만 있을 테니, 실제로 따지는 CP 규칙은 그 부품에 해당하는 것뿐이다. 페이지에 모달창이 없으면 모달 규칙은 통째로 '해당 없음'으로 빠진다. 즉 CP 446개 중 실제로 판정되는 건 '그 페이지에 실제 존재하는 부품'만큼이다. 이 점이 뒤에서 다룰 '846개에 겁먹지 않아도 되는 이유'의 핵심 근거가 된다.

CP가 중요한 또 다른 이유는, 부품의 '작동 방식'이 사용성을 직접 결정하기 때문이다. 디자인이 아무리 예뻐도 버튼이 버튼처럼 눌리지 않거나, 입력칸이 무엇을 넣어야 하는지 안내하지 않으면 사용자는 막힌다. CP는 '예쁨'이 아니라 '제대로 작동함'을 따지는 영역이라고 보면 정확하다.

CP 영역에서 특히 자주 간과되는 게 '키보드와 화면 낭독기'다. 마우스를 못 쓰는 사용자, 시각장애로 화면 낭독기를 쓰는 사용자는 부품이 '보이는지'가 아니라 '읽히고 조작되는지'가 중요하다. 예컨대 이미지로만 만든 버튼은 눈에는 멀쩡히 보여도 화면 낭독기에는 '이게 버튼인지' 전달되지 않는다. CP 규칙의 상당수는 이처럼 '눈에 보이는 것 너머'의 작동을 챙긴다. 부품에 적절한 역할 정보를 달았는지, 포커스가 순서대로 이동하는지, 비활성 상태가 코드 수준에서도 비활성으로 표시되는지 같은 것들이다. 이런 항목은 평소엔 '되는지 안 되는지'조차 모르고 지나치기 쉬운데, 막상 그 부품에 의존하는 사용자에게는 '되느냐 마느냐'의 절대적 차이가 된다.

또 하나, CP는 '상태'를 유난히 깐깐하게 따진다. 버튼만 해도 기본·올림·눌림·비활성·로딩의 다섯 상태가 시각적으로 구분돼야 한다고 앞서 말했는데, 입력칸도 마찬가지다. 빈 상태, 입력 중 상태, 정상 입력 완료 상태, 오류 상태가 다 다르게 보여야 한다. 사용자는 이 상태 변화를 통해 '내가 지금 뭘 하고 있는지'를 끊임없이 확인한다. 상태 구분이 없으면 사용자는 자기 행동의 결과를 못 읽고 불안해진다. CP가 446개로 가장 많은 건, 바로 이 '부품 × 상태 × 접근성'의 조합이 만들어내는 자연스러운 부피다. 억지로 늘린 게 아니라, 제대로 따지면 그만큼 나온다는 뜻이다.

■ BP(약 108개) — 부품들이 모여 만드는 작은 흐름

BP는 '기본 패턴'이다. 부품 하나가 아니라, 부품들이 모여 만드는 '작은 시나리오'를 다루는 칸이다. 약 108개로 네 영역 중 규칙 수는 가장 적지만, 사용자가 느끼는 답답함의 상당 부분이 바로 이 BP에서 나온다.

예를 들어보자. '폼을 채우다가 틀린 항목이 있으면 어떻게 알려줄 것인가.' 부품 자체(입력칸)는 멀쩡해도, 틀렸을 때 어디가 틀렸는지 안 알려주거나, 빨간 글씨 한 줄만 화면 맨 위에 띄우고 끝내면 사용자는 '대체 뭐가 문제야' 하며 헤맨다. 이게 BP의 영역이다. '동의 항목을 어떻게 배치하고 확인받을 것인가' '긴 목록을 어떻게 필터링하고 정렬하게 할 것인가' '여러 단계로 된 입력을 어떻게 나눠 보여줄 것인가' 같은 것들이 다 BP다.

BP를 비유하자면 '요리의 레시피 순서'다. 좋은 재료(DS)와 좋은 조리도구(CP)가 있어도, 순서가 엉망이면 요리가 망한다. 소금을 언제 넣느냐, 불을 언제 줄이느냐 하는 '순서와 흐름'이 BP다. 부품은 다 멀쩡한데 이상하게 쓰기 불편한 사이트가 있다면, 십중팔구 BP에 문제가 있는 것이다.

BP가 다루는 흐름은 작지만, 이 작은 흐름들이 모여 큰 서비스(SP)를 이룬다. 그래서 BP는 '부품(CP)과 서비스(SP) 사이를 잇는 다리' 같은 영역이다. 다리가 부실하면 양쪽이 멀쩡해도 건너갈 수가 없다. 108개라는 비교적 적은 숫자에 비해 BP가 체감 영향력이 큰 이유가 여기 있다.

BP가 다루는 패턴 중에 '오류 처리'를 조금 더 들여다보자. 사용자가 무언가를 잘못 입력했을 때, 나쁜 BP는 세 가지를 한꺼번에 어긴다. 첫째, 어디가 틀렸는지 안 짚어준다. 둘째, 왜 틀렸는지 설명을 안 한다. 셋째, 어떻게 고치면 되는지 안 알려준다. 그러면 사용자는 '틀렸다'는 사실만 알 뿐, 다음에 뭘 해야 할지 막막해진다. 반대로 좋은 BP는 틀린 칸을 바로 표시하고, '생년월일은 8자리 숫자로 입력하세요'처럼 구체적으로 안내하며, 화면을 그 칸으로 데려다준다. 같은 입력칸(CP)을 쓰더라도, 이 오류 처리 패턴(BP)이 있느냐 없느냐에 따라 사용자의 경험은 천지 차이가 난다.

또 BP는 '동의와 확인'의 흐름도 다룬다. 약관 동의를 받을 때 전체 동의 하나로 뭉뚱그리는지, 필수와 선택을 구분하는지, 동의 내용을 실제로 읽을 수 있게 펼쳐 보여주는지 같은 것들이다. 이건 단순한 편의를 넘어 '사용자의 권리'와 직결되는 흐름이라, BP에서 꽤 비중 있게 다뤄진다. 긴 목록을 다루는 필터·정렬 패턴도 BP다. 수백 건의 공고나 자료를 그냥 쭉 나열하면 사용자는 원하는 걸 못 찾는다. 좋은 필터·정렬 패턴은 '많은 정보'를 '찾을 수 있는 정보'로 바꿔준다. 이렇게 BP는 '부품은 멀쩡한데 왜 쓰기 불편하지?'라는 질문의 답이 숨어 있는 영역이다. 사이트가 이상하게 답답한데 딱히 어디가 잘못됐는지 짚기 어렵다면, 십중팔구 BP를 의심해볼 만하다.

■ SP(약 172개) — 사용자가 목적을 이루는 전체 여정

SP는 '서비스 패턴', 가장 큰 그림을 다루는 칸이다. 사용자가 사이트에 온 '목적' 단위로 흐름 전체를 본다. 약 172개의 규칙이 있다. 정보를 검색해서 찾는 여정, 회원으로 가입하고 로그인하는 여정, 무언가를 신청하거나 예약하거나 민원을 넣는 여정, 정책과 안내를 읽고 이해하는 여정. 이런 큰 흐름이 SP다.

SP의 특징은 '여러 페이지와 여러 단계에 걸쳐 있다'는 점이다. 그래서 중간 어디 한 곳만 끊겨도 전체가 실패한다. 신청 서비스를 예로 들면, 입력은 잘 받아놓고 마지막 '완료' 화면에서 '무엇이 접수됐는지'를 안 알려주면, 사용자는 '이게 된 거야 안 된 거야' 하며 불안에 빠진다. 한 단계만 부실해도 여정 전체에 대한 신뢰가 깨진다. SP가 좋은 사이트는 '쓰다 보면 어느새 끝나 있는' 느낌을 주고, SP가 나쁜 사이트는 '하다가 포기하게 되는' 느낌을 준다.

SP를 비유하면 '여행 일정 전체'다. 각 도시(페이지)가 아무리 멋져도, 도시 사이를 잇는 교통편이 끊기거나 환승이 엉망이면 여행 자체가 고생길이 된다. SP는 그 '전체 동선'이 매끄러운지를 본다. 공공 서비스는 대개 '선택이 아니라 필수'다. 세금 납부, 증명서 발급, 복지 신청, 민원 접수는 다른 사이트로 갈아탈 수 없는 일이다. 그래서 SP가 무너지면 사용자는 그냥 불편한 정도가 아니라, 꼭 해야 할 일을 못 하게 된다. SP가 172개나 되는 규칙으로 흐름을 촘촘히 챙기는 이유다.

SP가 어려운 건, 한 페이지만 잘 만든다고 해결되지 않기 때문이다. 검색 흐름을 예로 들면, 검색창이 잘 보이는 것(시작)도 중요하지만, 검색 결과가 이해하기 쉽게 정리되는 것(중간)도, 결과가 없을 때 '다른 검색어를 시도해보라'고 안내하는 것(예외)도, 원하는 정보를 클릭해 들어갔을 때 길을 잃지 않는 것(도착)도 다 중요하다. 이 모든 단계가 하나의 '검색 서비스 패턴'으로 묶인다. 그래서 SP를 점검할 때는 페이지 하나가 아니라 '여정 전체'를 따라가 봐야 한다. 시작은 좋은데 중간에서 끊기거나, 다 좋은데 결과 없음 화면이 텅 비어 있으면 SP는 실패로 본다.

또 SP는 '되돌아가기'와 '진행 상황 알리기'를 중요하게 본다. 여러 단계로 된 신청에서 사용자는 종종 앞 단계로 돌아가 입력을 고치고 싶어 한다. 그런데 뒤로 가면 입력한 게 다 날아가버리는 사이트가 의외로 많다. 또 '지금 5단계 중 3단계'라는 진행 표시가 없으면 사용자는 '대체 얼마나 더 남았나' 막막해한다. SP 규칙은 이런 '여정의 친절함'을 챙긴다. 사용자가 길을 잃지 않게, 중간에 포기하지 않게 손을 잡아주는 장치들이다. 공공 서비스가 '떠날 수 없는 사용자'를 상대한다는 점을 떠올리면, 이 친절함은 선택이 아니라 의무에 가깝다.

여기까지가 네 서랍의 정체다. 정리하면 이렇다. DS는 '기본 자재'(120), CP는 '부품'(446), BP는 '작은 흐름'(108), SP는 '전체 여정'(172). 자재로 부품을 만들고, 부품으로 흐름을 만들고, 흐름으로 여정을 완성한다. 846이라는 숫자가 처음과 달리 보이기 시작했다면, 오늘 글의 절반은 성공한 셈이다. 한 가지만 더 강조하자. 이 네 층은 결코 동떨어진 칸이 아니라 서로를 떠받친다. 그래서 어느 한 층의 문제는 종종 다른 층으로 번진다. 색(DS)이 흐릿하면 버튼(CP)이 안 보이고, 버튼이 안 보이면 신청 흐름(BP)이 막히고, 흐름이 막히면 민원 서비스(SP) 전체가 무너진다. 거꾸로, 아래층 하나를 제대로 잡으면 위층이 줄줄이 좋아진다. 이 '연결된 구조'를 머릿속에 그려두는 것이, 오늘 글에서 가져갈 가장 값진 한 가지다.

846개에 겁먹지 않아도 되는 진짜 이유

■ 한 페이지가 846개를 다 짊어지지 않는다

846개라고 하면 "이걸 다 봐야 한다고?" 싶어 막막할 거다. 결론부터 말하면, 한 페이지가 846개를 동시에 짊어지는 일은 절대 없다. 이게 첫 번째 안심 포인트다.

앞에서 CP 이야기를 할 때 잠깐 짚었듯, 규칙은 '그 페이지에 해당 요소가 있을 때만' 따진다. 모달창 규칙은 모달이 있는 페이지에서만, 표 규칙은 표가 있는 페이지에서만, 신청 흐름 규칙은 신청 기능이 있는 페이지에서만 적용된다. 단순한 안내 페이지라면 따지는 규칙이 확 줄고, 복잡한 신청 페이지라면 늘어난다. 즉 '페이지의 복잡도만큼만' 규칙이 적용된다. 해당 요소가 없으면 그 규칙은 '해당 없음'으로 깔끔하게 빠진다. 그래서 실제로 한 페이지에서 판정 대상이 되는 규칙은 846개의 일부일 뿐이다.

이 '해당 없음'이라는 개념이 처음엔 낯설 수 있는데, 사실 굉장히 합리적인 장치다. 우리 사이트에 결제 기능이 없는데 결제 관련 규칙을 들이대며 '이거 위반'이라고 하면 억울하지 않겠나. 없는 기능을 두고 점수를 깎는 건 부당하다. 그래서 KRDS 기반 진단은 '있는 것만 따지고, 없는 건 해당 없음으로 비킨다'는 상식적인 원칙을 따른다. 846개라는 총량이 곧 '우리가 매번 통과해야 할 시험 범위'가 아니라는 뜻이다.

■ 846개가 다 같은 무게도, 같은 난이도도 아니다

두 번째 안심 포인트. 846개는 다 같은 비중이 아니다. 자주 걸리고 영향이 큰 '핵심 규칙'이 있고, 특수한 상황에서만 따지는 '변두리 규칙'이 있다. 실무에서 중요한 건 모든 규칙을 100점 맞으려 애쓰는 게 아니라, 영향 큰 것부터 순서대로 잡는 것이다. 마치 시험 공부할 때 출제 빈도 높은 단원부터 보는 것과 같다.

게다가 846개는 난이도도 제각각이다. 상당수는 '이 요소가 있는가/없는가' '이 속성이 제대로 붙어 있는가'처럼 비교적 단순하게 판정되는 항목이다. 정말로 까다로운, 사람의 시각적·맥락적 판단이 필요한 규칙은 그중 일부다. 그러니 '846개를 모두 같은 무게로 짊어진다'는 상상은 과장된 두려움이다.

이걸 운전에 비유하면 명확해진다. 도로교통법 조항을 통째로 외우는 운전자는 없다. 하지만 좋은 운전자는 '신호를 지킨다, 안전거리를 둔다, 보행자를 보호한다' 같은 핵심 원칙을 몸에 익히고 있다. 세부 조항은 필요할 때 찾아본다. KRDS도 똑같다. '일관성을 지킨다(DS), 부품이 제대로 작동한다(CP), 흐름을 끊지 않는다(BP), 여정을 완주시킨다(SP)' 같은 네 층의 큰 원칙을 이해하고, 네 서랍의 구조를 알면, 846개 세부 항목은 자동 진단 도구가 대신 챙겨준다. 사람은 방향을 잡고, 도구는 디테일을 챙긴다. 이게 가장 현실적이고 지속 가능한 역할 분담이다.

■ 자주 나오는 질문 몇 가지

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

"기존 사이트도 846개에 다 맞춰 바꿔야 하나요?"라는 질문에는 '한 번에 다 바꿀 필요는 없다'가 답이다. 현황을 진단하고, 영향 큰 것부터, 개편 시점에 맞춰 점진적으로 적용하는 게 정석이다. "디자인은 외주가 알아서 하는 거 아닌가요?"라는 생각도 흔한데, 실제 제작은 업체가 해도 '무엇을 기준으로 만들지'를 정하고 '제대로 만들어졌는지' 확인하는 건 발주처, 즉 담당자의 몫이다. 846규칙의 네 서랍 구조를 알아두는 건 디자인을 직접 하기 위해서가 아니라, '제대로 된 디자인을 요구하고 확인하기 위해서'다.

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

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

"그럼 KRDS는 어디서 보나요?"라는 질문도 빼놓을 수 없다. KRDS의 공식 가이드는 정부 차원에서 공개돼 있고, 누구나 열람할 수 있다. 다만 846개 규칙 원문을 처음부터 끝까지 읽는 건 입문자에게 버겁다. 그래서 오늘 글처럼 '네 서랍 구조'를 먼저 잡고, 자기 사이트에서 자주 걸리는 영역부터 원문을 찾아 읽는 방식이 훨씬 효율적이다. 구조라는 지도를 손에 쥐고 원문이라는 지형을 탐험하는 셈이다. 지도 없이 지형부터 뛰어들면 길을 잃기 십상이다.

네 서랍 구조로 본 익명 사례

개념만 들으면 '그래서 실제로 뭐가 문제인데?' 싶을 수 있다. 그래서 실무에서 반복되는 상황을 익명으로 풀어보겠다. 미리 양해를 구하자면, 아래 사례에는 어떤 실제 기관명도, 도메인도, 식별 가능한 정보도 없다. 여러 사이트에서 공통으로 관찰되는 '유형'을 익명으로 재구성한 것이다. 핵심은 '이 증상이 DS·CP·BP·SP 어느 서랍의 문제인가'를 함께 짚어보는 데 있다. 그래야 앞에서 배운 네 층 구조가 머릿속에서 살아 움직인다.

읽기 전에 한 가지 연습을 권한다. 각 사례를 보면서 '나라면 이 문제를 어느 서랍에서 찾을까'를 먼저 스스로 맞혀보는 것이다. 그런 다음 내가 짚는 답과 비교해보면, 네 층을 구분하는 감각이 훨씬 빠르게 손에 붙는다. 처음엔 헷갈려도 괜찮다. '색·글꼴 같은 시각 기본은 DS, 화면 부품은 CP, 작은 흐름은 BP, 전체 여정은 SP'라는 한 줄짜리 기준만 떠올리면 대부분 맞힐 수 있다. 이 짧은 연습 하나가 개념을 '아는 것'에서 '쓰는 것'으로 바꿔준다.

■ 사례 하나 — 페이지마다 색이 다른 사이트 (DS 문제)

A광역지자체 사이트를 점검한다고 치자. 메인은 깔끔했는데, 메뉴를 타고 들어가니 분위기가 확 달라졌다. 민원 부서 페이지는 파란 계열, 문화 행사 부서 페이지는 초록 계열. 같은 기관인데 서너 개의 '다른 사이트'를 떠도는 느낌이었다. 원인은 뻔하다. 부서별·사업별·시기별로 따로 발주했고, 그때마다 색·글꼴 기준이 없어 각자 알아서 만든 것이다.

이건 명백히 1층, DS의 문제다. 색이라는 기본 자재가 역할별로 정리돼 있지 않으니, 페이지마다 색의 의미가 흔들린다. 그리고 이 흔들림은 곧 '신뢰의 흔들림'으로 이어진다. 페이지마다 분위기가 제각각이면 '여기가 진짜 그 기관 사이트가 맞나, 혹시 사칭은 아닌가' 하는 막연한 불안이 생긴다. 특히 개인정보를 입력하거나 결제·신청을 해야 하는 화면에서 이 불안은 치명적이다. 일관된 디자인은 단순히 '예뻐 보이기 위함'이 아니라, '이곳은 믿을 수 있는 공식 창구다'라는 신뢰의 시각적 증거다. 통일감이 무너진다는 건 그 증거가 약해진다는 뜻이기도 하다. DS가 무너지면 가장 먼저, 가장 넓게 티가 난다는 걸 보여주는 전형적인 사례다. 해법도 명확하다. 색·글꼴·간격의 토큰을 역할별로 한 번 정리해두고, 모든 부서가 그 토큰을 가져다 쓰게 하면 된다. 1층을 단단히 다지는 것이 이 사례의 답이다.

■ 사례 둘 — 누를 수 없을 것 같은 버튼 (CP 문제)

B공공기관 사이트의 신청 페이지. 디자인은 멀쩡했는데, 한 사용자가 '다음'으로 넘어가질 못하고 한참 헤맸다. 알고 보니 '다음' 버튼이 회색 글씨에 테두리도 흐릿해서, 누를 수 있는 버튼인지 그냥 안내 문구인지 구분이 안 됐던 것이다. 게다가 마우스를 올려도 아무 반응이 없으니 '죽은 버튼'처럼 보였다.

이건 2층, CP의 문제다. 버튼이라는 부품이 '버튼처럼 보이고 버튼처럼 반응한다'는 기본을 못 지킨 것이다. 버튼은 기본·올림·눌림·비활성 상태가 시각적으로 구분돼야 하는데, 그 구분이 없으니 사용자가 '이걸 눌러도 되나' 망설인다. 부품 하나의 작동 방식이 흔들리면, 그 부품을 거쳐야 하는 모든 사용자가 멈칫한다. CP가 '예쁨'이 아니라 '제대로 작동함'을 따지는 영역이라는 말의 의미가 여기서 드러난다.

■ 사례 셋 — 어디가 틀렸는지 안 알려주는 폼 (BP 문제)

C기관의 회원가입 폼. 열 개 남짓한 항목을 다 채우고 '가입'을 눌렀더니, 화면 맨 위에 빨간 글씨로 '입력값을 확인하세요' 한 줄만 떴다. 어느 칸이 문제인지는 안 알려준다. 사용자는 열 개 칸을 처음부터 하나씩 다시 점검해야 했다. 결국 짜증이 나서 가입을 포기했다.

이건 3층, BP의 문제다. 입력칸(CP) 자체는 멀쩡했다. 문제는 '오류가 났을 때 어떻게 알려주는가'라는 흐름, 즉 패턴이었다. 좋은 BP라면 틀린 칸 바로 옆에 '무엇이 왜 틀렸는지'를 구체적으로 보여주고, 화면이 그 칸으로 안내해준다. 부품은 멀쩡한데 흐름이 부실해서 사용자가 떠나는, 전형적인 BP 결함이다. 작은 흐름 하나가 가입이라는 큰 목적을 통째로 무산시킨 셈이다. 흥미로운 건, 이런 BP 문제는 사이트를 만든 쪽에서는 잘 안 보인다는 점이다. 만든 사람은 어느 칸에 뭘 넣어야 하는지 이미 다 알고 있으니, 한 번에 통과해버려서 오류 화면을 볼 일이 없다. 정작 처음 방문한 사용자만 그 벽에 부딪힌다. 그래서 BP 결함은 '내부 점검'만으로는 좀처럼 안 잡히고, 처음 쓰는 사람의 눈 — 혹은 객관적인 자동 진단의 눈 — 으로 봐야 비로소 드러난다.

■ 사례 넷 — 완료됐는지 알 수 없는 신청 (SP 문제)

같은 C기관, 이번엔 민원신청 여정 전체. 입력 단계는 그럭저럭 굴러갔는데, 마지막 '신청 완료' 화면이 텅 비어 있었다. 접수번호도, 처리 예정 안내도, '무엇이 접수됐다'는 요약도 없이 그냥 '완료되었습니다' 한 줄. 사용자는 '이게 진짜 접수된 거 맞아?' 하며 같은 신청을 두 번 세 번 반복했다.

이건 4층, SP의 문제다. 개별 부품과 흐름은 어느 정도 작동했지만, '여정 전체'의 마무리가 부실했다. 신청이라는 서비스 패턴은 '접수 확인'으로 닫혀야 완성된다. 그 마지막 한 단계가 비어 있으면, 앞의 모든 단계에 대한 신뢰가 한꺼번에 흔들린다. SP가 여러 페이지에 걸쳐 있고, 중간 한 곳만 끊겨도 전체가 실패한다는 말의 실제 모습이다. 해법은 접수번호·처리 예정·신청 요약을 완료 화면에 명확히 보여주고, 가능하면 같은 내용을 문자나 메일로도 한 번 더 확인시켜 주는 것이다. 여정의 끝을 분명히 닫아주는 것 — 그게 SP의 친절이다.

이 네 사례를 나란히 놓으면, 같은 '불편함'이라도 원인이 어느 층에 있느냐에 따라 해법이 완전히 다르다는 게 보인다. 색 문제는 DS에서, 버튼 문제는 CP에서, 오류 안내 문제는 BP에서, 완료 확인 문제는 SP에서 손봐야 한다. '증상'을 '층위'로 번역하는 이 능력이 바로 846규칙 구조를 이해한 사람의 무기다.

한 가지 더 중요한 점. 이 네 사례 중 어느 것도 '디자이너의 실력 부족' 때문이 아니다. 모두 '공통 기준의 부재' 때문이다. 색이 제각각인 건 색 토큰 기준이 없어서고, 버튼이 죽어 보이는 건 버튼 상태 기준이 없어서고, 오류 안내가 부실한 건 오류 처리 패턴 기준이 없어서다. 즉 사람을 탓할 문제가 아니라 '기준을 갖추면 사라질' 문제들이다. 그래서 '어, 우리 사이트 얘긴가?' 싶은 대목이 있어도 자책할 필요 없다. 그건 그만큼 흔한 일이고, 기준만 세우면 충분히 고쳐지는 일이다. 846규칙은 바로 그 '기준'을 통째로 제공한다. 사례를 통해 봤듯, 문제를 층위로 분류하는 순간 해법의 방향이 따라 나온다 — 이게 네 서랍 구조를 이해한 사람이 누리는 가장 실용적인 이점이다.

그래서 무엇부터 시작하면 되나

■ 1단계: 현황 진단 — 우리 사이트의 네 층 점수를 본다

KRDS의 가치는 '기준을 아는 것'에서 끝나지 않는다. '기준과 현실의 거리를 측정하는 것'으로 완성된다. 아무리 좋은 846규칙이 있어도, 우리 사이트가 그중 무엇을 지키고 무엇을 어겼는지 모르면 그 기준은 문서로만 남는다. 그래서 가장 먼저 할 일은 '진단'이다. 우리 사이트가 DS·CP·BP·SP 네 층에서 각각 어느 정도인지를 숫자로 확인하는 일이다.

문제는 이 측정을 사람이 직접 하기가 사실상 불가능하다는 점이다. 846개 규칙을, 사이트의 수십·수백 페이지에 대해, 사람이 일일이 눈으로 따지는 건 며칠 밤을 새워도 끝나지 않는다. 더구나 사람마다 판정 기준이 달라서 일관성도 떨어진다. 오늘 점검한 사람과 내일 점검한 사람의 결과가 다르면, 그 진단은 신뢰하기 어렵다. 그래서 '자동 진단'이 표준의 실효성을 떠받치는 또 하나의 축이 된다. 사람은 '방향과 우선순위'를 정하고, 도구는 '846개 디테일을 일관된 기준으로 빠르게 따지는' 역할을 맡는 분담이 가장 현실적이다. 표준을 만드는 일과 표준이 지켜지는지 확인하는 일은 한 쌍으로 굴러가야 한다.

진단을 받을 때 가장 좋은 건 '한 페이지'가 아니라 '사이트 여러 페이지'를 함께 보는 것이다. 앞에서 본 사례들이 그랬듯, 공공 사이트의 문제는 부서별·페이지별로 흩어져 있기 마련이다. 메인 한 장만 보고 '우리 사이트 괜찮네'라고 판단하면, 정작 사용자가 가장 많이 쓰는 신청·검색 페이지의 문제를 놓친다. 그래서 좋은 진단은 여러 페이지를 훑어 '한 곳이라도 어긋나면 그 영역의 위험으로 잡는' 보수적인 시각으로 본다. 그래야 '평균은 괜찮은데 특정 페이지가 치명적인' 상황을 놓치지 않는다. 진단 결과를 받을 때 '몇 개 페이지를 봤는지'를 함께 확인하는 습관이 중요한 이유다.

■ 2단계: 아래층부터, 영향 큰 것부터

진단으로 네 층 점수를 봤다면, 다음은 '무엇부터 고칠까'다. 앞에서 말한 '건물 구조'를 떠올리자. 아래층이 흔들리면 위층이 다 흔들린다. 그래서 많은 경우 DS(1층)부터 잡는 게 효율적이다. 색·글꼴·간격 같은 기본 토큰을 정리하면, 그 위에 얹힌 부품과 흐름이 자동으로 한 단계씩 좋아진다. 같은 노력으로 더 넓은 면적을 개선하는 셈이다.

그다음은 '영향이 큰 것' 순서다. 사용자가 가장 많이 거치는 페이지(메인·검색·신청)의 핵심 부품과 흐름을 우선 잡는다. 방문이 거의 없는 구석 페이지의 변두리 규칙은 나중에 봐도 된다. 모든 규칙을 동시에 100점 맞으려 하면 시작도 못 하고 지친다. '아래층부터, 영향 큰 것부터' — 이 두 원칙만 지켜도 개선의 우선순위가 저절로 잡힌다.

여기에 한 가지 현실적인 팁을 보태자. 개선 항목을 정렬할 때 '영향 크기'와 '고치는 비용'을 함께 보면 좋다. 영향이 크면서 고치기 쉬운 것이 1순위다. 색 토큰 정리나 버튼 상태 보강처럼, 한 번 손보면 사이트 전체에 적용되는 항목이 대개 여기 속한다. 영향이 크지만 고치기 어려운 것(예: 신청 여정 전체 재설계)은 개편 사업의 큰 과제로 잡아두고, 영향이 작은 것은 여유 있을 때 처리한다. 이렇게 '영향 × 비용'의 사분면으로 나눠 보면, 한정된 예산과 인력으로 최대 효과를 내는 길이 보인다. 846개를 다 손대려 하지 말고, 이 사분면에서 '오른쪽 위(영향 크고 쉬움)'부터 차근차근 비워가는 것이 핵심이다.

■ 3단계: 개편 시점에 맞춘 점진 적용

기존 사이트를 한 번에 다 뜯어고치는 건 비현실적이고, 그럴 필요도 없다. 정석은 '점진적 적용'이다. 정기 개편이나 부분 리뉴얼 시점에, 진단에서 드러난 우선순위대로 KRDS 기준을 하나씩 반영하는 것이다. 이때 진단 결과는 외주 업체와의 소통 언어가 되어준다. "좀 더 깔끔하게 해주세요" 같은 모호한 요구 대신, "DS 색 토큰을 역할별로 통일해주세요" "이 신청 흐름의 완료 확인 단계를 SP 기준에 맞춰 보강해주세요"처럼 검수 가능한 요구로 바뀐다. 모호한 요구가 구체적인 요구가 되고, 구체적인 요구는 검증 가능한 요구가 된다. 이게 담당자가 끌려다니지 않고 주도권을 쥐는 길이다.

정리하면, '진단 → 우선순위 → 점진 적용'이라는 세 박자가 KRDS를 실무에 안착시키는 가장 현실적인 경로다. 그리고 이 세 박자의 출발점은 언제나 '우리 사이트가 지금 어디쯤인지'를 아는 것, 즉 진단이다. 진단 없이 우선순위를 정하면 그건 짐작일 뿐이고, 짐작으로 예산을 쓰면 엉뚱한 데 돈이 샌다. 먼저 재고, 그다음에 고친다 — 이 순서를 지키는 것이 KRDS를 '문서'에서 '현실'로 끌어내리는 첫걸음이다.

마무리

오늘 이야기를 한 문장으로 다시 묶어보자. KRDS 846규칙은 공공 웹을 구성하는 모든 것을 DS(120, 기본 자재)·CP(446, 부품)·BP(108, 작은 흐름)·SP(172, 전체 여정)라는 네 층으로 쌓아 정리한 기준집이다. 846이라는 숫자는 위협이 아니라 '이만큼 꼼꼼하게 정리해뒀다'는 안심의 증거다. 우리가 외워야 할 건 846개가 아니라, 네 서랍이 각각 무엇을 담는지 그 구조뿐이다.

그리고 이 구조를 손에 쥐면, 사이트에서 마주치는 거의 모든 문제를 '이건 어느 층의 문제일까'로 번역할 수 있게 된다. 색이 제각각이면 DS, 버튼이 이상하면 CP, 오류 안내가 부실하면 BP, 신청이 끝까지 안 매끄러우면 SP. 증상을 층위로 옮기는 그 순간, 막막했던 846규칙은 '찾아 쓸 수 있는 지도'로 바뀐다.

처음에 나는 846이라는 숫자 앞에서 한숨부터 쉬었다고 했다. 지금은 그 숫자를 보면 오히려 안심이 된다. 누군가가 공공 웹을 만들고 운영하는 데 필요한 거의 모든 고민을, '기초 → 부품 → 패턴 → 서비스' 네 층으로 빠짐없이 정리해 미리 해뒀다는 뜻이니까. 담당자가 매번 처음부터 고민하지 않아도 되도록, 먼저 길을 닦아둔 셈이다. 그 길을 따라 걷기만 하면 된다는 게, 솔직히 든든하다. 그리고 그 든든함은 '구조를 이해한 사람'만 누릴 수 있다. 오늘 이 글을 끝까지 읽은 당신은, 이제 그 든든함의 입구에 서 있는 셈이다.

마지막으로, 이 모든 이야기의 출발점은 결국 '우리 사이트가 지금 네 층에서 각각 어디쯤인가'를 아는 것이다. 머릿속으로 짐작하는 것과 숫자로 확인하는 것은 천지 차이다. 행정안전부 「전자정부 웹사이트 품질관리 지침」의 7대 영역(호환성·접근성·개방성·접속성·편의성·효율성·신뢰성)과 KRDS 846규칙을 한꺼번에 자동으로 점검해보고 싶다면, ViewCheck(krds.viewcheck.co.kr)에서 무료로 진단을 체험해볼 수 있다. URL 하나만 넣으면 DS·CP·BP·SP 네 영역의 점수가 상단 점수 카드(OverviewCards)에 한눈에 펼쳐진다. 부담 없이, 우리 사이트의 '네 층 성적표'부터 한번 받아보길 권한다. 오늘 배운 네 서랍 구조가, 그 성적표를 읽는 순간 비로소 살아 움직이기 시작할 것이다.