부서마다 따로 만든 페이지, 사용자만 헷갈린다

공감·문제제기

월요일에 '공공웹이 왜 이렇게 제각각인가'를 큰 그림으로 그렸다. 한 기관 안에 들어가도 페이지마다 분위기가 달라서, 사용자 입장에선 '같은 사이트 맞나?' 싶은 순간이 자주 온다고. 오늘은 그 이야기를 한 칸 더 안쪽으로 끌고 들어가 보려 한다. 제목 그대로다 — 부서마다 따로 만든 페이지, 그리고 그 결과로 헷갈리는 건 결국 사용자뿐이라는 이야기.

나는 공공 사이트를 점검하는 일을 한다. 하루에도 여러 기관의 화면을 들여다보는데, 신기한 게 있다. 기관 이름을 가리고 화면만 보여줘도, '아, 이 사이트는 부서별로 따로 만들었구나'가 거의 한눈에 보인다. 왜냐하면 흔적이 너무 똑같기 때문이다. 메인은 말끔한데 안쪽 부서 페이지로 들어가는 순간 색이 바뀌고, 글꼴이 바뀌고, 메뉴 위치가 바뀐다. 어떤 부서 페이지는 2년 전 유행하던 스타일이고, 옆 부서 페이지는 작년에 새로 단장한 스타일이다. 둘이 한 지붕 아래 있는데 서로 모르는 사람처럼 군다.

먼저 솔직하게 말해두자. 이건 누가 잘못해서 생긴 일이 아니다. 적어도 '게을러서'나 '실력이 없어서'는 아니다. 오히려 다들 자기 일을 열심히 한 결과다. A부서는 A부서대로 자기 사업을 알리려고 최선을 다해 페이지를 만들었고, B부서는 B부서대로 자기 민원을 잘 받으려고 열심히 만들었다. 문제는 그 '각자의 최선'이 모일 자리, 그러니까 '우리 기관은 이렇게 만든다'는 공유된 약속이 없었다는 거다. 약속이 없으면 각자 최선을 다해도 결과가 제각각이 된다. 이게 오늘 글의 한 줄 요약이다.

이 '부서별로 따로' 현상은 사실 조직의 구조를 그대로 닮는다. 행정 조직은 부서로 나뉘어 있고, 예산도 부서별로 잡히고, 사업도 부서별로 굴러간다. 그러다 보니 웹페이지를 만드는 일도 자연스럽게 부서별로 쪼개진다. A부서가 새 사업을 시작하면 A부서 예산으로 A부서가 외주를 줘서 페이지를 만든다. B부서도 마찬가지다. 각자 다른 시기에, 각자 다른 업체에, 각자 다른 담당자가 발주한다. 그러니 결과물이 같을 수가 없다. 콘웨이의 법칙이라는 말이 있다 — '조직의 소통 구조가 결과물의 구조에 그대로 새겨진다'는. 공공웹이 제각각인 건, 어떤 의미에선 그 조직이 부서별로 나뉘어 일한다는 사실이 화면에 그대로 비친 것뿐이다.

그런데 사용자는 그 조직 구조를 모른다. 알 필요도 없고, 알고 싶지도 않다. 민원을 넣으러 온 사람은 '이게 A부서 소관인지 B부서 소관인지'를 따지러 온 게 아니다. 그냥 '이 기관에서 이 일을 처리하고 싶다'는 마음으로 들어온다. 사용자에게 그 기관은 하나의 덩어리다. 그런데 그 하나여야 할 덩어리가 안에서 부서별로 쪼개져 제각각이면, 사용자는 한 사이트 안에서 여러 사이트를 돌아다니는 듯한 혼란을 겪는다. 메뉴 찾는 법을 부서마다 새로 익혀야 하고, 신청 버튼이 어디 있는지 페이지마다 다시 찾아야 한다. '기관 입장의 자연스러운 분업'이 '사용자 입장의 부자연스러운 미로'가 되는 순간이다.

오늘 다룰 사례들은 특정 기관 이야기가 아니다. 익명으로 풀어내는 '전형적인 붕괴 패턴'들이다. 가상의 ○○시, A광역지자체, 한중앙부처, B공공기관, C기관을 등장시켜 무엇이 어떻게 어긋나는지 구체적으로 보여줄 생각이다. 이름은 가렸지만 패턴은 진짜다. 규모가 크든 작든, 예산이 많든 적든 거의 똑같이 반복된다. 읽으면서 '우리도 저런데' 싶은 게 나와도 자책할 필요 없다. 대부분이 겪는 일이고, 대부분이 같은 방법으로 풀어왔다.

한 가지 미리 일러두고 싶은 게 있다. 이 글의 목적은 '부서 탓'을 하려는 게 아니다. 오히려 정반대다. 부서가 잘못한 게 아니라 '부서들이 공유할 기준이 없었던 것'이 문제라는 걸 보여주려는 거다. 그래서 해법도 '어느 부서를 혼내는 것'이 아니라 '모든 부서가 함께 쓸 약속을 만드는 것'이 된다. 그 약속의 이름이 바로 디자인 시스템이고, 공공 영역에서 그걸 표준으로 만들어 둔 게 KRDS다. 오늘은 '부서별로 따로 만들면 정확히 무엇이 어떻게 망가지는지'를 사례로 보여주고, 그 망가짐을 막는 기준이 왜 필요한지를 피부로 느끼게 하는 게 목표다.

덧붙이자면, 이 글은 '부서'라는 단어를 자주 쓰지만, 꼭 행정 조직의 부서만 가리키는 건 아니다. 외주 업체가 여럿이어도, 한 업체 안에서 디자이너가 바뀌어도, 시스템을 운영하는 팀과 콘텐츠를 올리는 팀이 따로여도 똑같은 일이 생긴다. 핵심은 '여러 손이 공유된 약속 없이 한 사이트를 만진다'는 상황 그 자체다. 손이 여럿일수록, 그 손들을 묶어줄 약속의 가치는 커진다. 그러니 오늘 이야기를 '우리 부서 vs 옆 부서'의 문제로만 좁혀 읽지 말고, '여러 손이 하나의 결과를 만드는 모든 상황'으로 넓혀 읽으면 좋겠다.

그리고 한 가지 더. 이런 붕괴는 대부분 '조용히' 일어난다. 큰 사고처럼 빨간불이 켜지는 게 아니라, 사용자가 '뭔가 좀 불편한데 왜인지는 모르겠네' 하고 그냥 떠나버리는 식으로 손해가 난다. 민원이 들어오지도 않고, 통계에 '부서별 디자인 불일치로 이탈'이라고 찍히지도 않는다. 그래서 담당자 입장에선 문제가 있다는 걸 알아채기조차 어렵다. 오늘 이 글이 하려는 일은 그 '조용한 손해'를 눈에 보이게 만드는 거다. 보이기 시작해야 고칠 마음이 생기니까.

본론

■ 왜 '부서별로 따로'가 되는가 — 구조가 만든 제각각

먼저 원인부터 차분히 짚자. 부서마다 페이지가 따로 노는 건 우연이 아니라 거의 필연이다. 그 필연을 만드는 몇 가지 힘이 있다.

첫째, 예산과 발주가 부서별로 쪼개진다. 한중앙부처를 예로 들어보자. 이 부처는 산하에 여러 실·국이 있고, 각 국은 자기 사업을 굴린다. 어느 국이 새 정책을 시작하면, 그 국의 예산으로 그 국이 외주 업체를 골라 페이지를 만든다. 옆 국은 또 다른 시기에 다른 업체에 발주한다. 발주의 주체가 다르고, 시기가 다르고, 업체가 다르니, 결과물이 같을 도리가 없다. 발주 문서 어디에도 '우리 부처는 이런 색, 이런 글꼴, 이런 버튼을 쓴다'는 한 줄이 없으면, 업체는 '알아서 예쁘게' 만들 수밖에 없다. 그 '알아서'가 부서마다 다르게 쌓여 누더기가 된다.

둘째, 시간이 흩어진다. 부서 페이지는 한날한시에 만들어지지 않는다. A광역지자체를 떠올려 보자. 이 지자체의 어떤 부서 페이지는 5년 전에 만들어졌고, 어떤 페이지는 작년에 개편됐고, 어떤 페이지는 지난달에 급하게 추가됐다. 디자인에는 '그 시절의 유행'이 묻는다. 5년 전엔 둥근 버튼이 유행이었고, 작년엔 각진 버튼이 유행이었다면, 그 흔적이 페이지에 그대로 남는다. 결국 한 사이트 안에서 5년 치 디자인 유행이 지층처럼 쌓인다. 사용자는 한 클릭으로 5년 전 페이지와 올해 페이지를 오가며 '여긴 왜 이렇게 옛날 느낌이지'를 무의식적으로 느낀다.

셋째, 담당자가 바뀐다. 공공 조직은 순환 보직이 많다. 어느 부서의 웹 담당자가 2년 일하다 다른 부서로 가면, 새 담당자가 온다. 새 담당자는 전임자가 어떤 기준으로 페이지를 만들었는지 모른다. 인수인계 문서에 '버튼 색은 이거, 글꼴은 저거'가 적혀 있을 리 없다. 그래서 새 담당자는 또 자기 나름의 기준으로 새 페이지를 만든다. 이렇게 '조직의 기억'이 사람 머릿속에만 있으면, 사람이 바뀔 때마다 기준도 함께 사라진다. 부서별 제각각은 사실 '사람별 제각각'이 누적된 결과이기도 하다.

넷째, '우리 부서 것'이라는 소유 의식이 작동한다. 이건 미묘한데 꽤 강하다. 부서는 자기 페이지에 애착을 갖는다. '우리 사업의 정체성'을 드러내고 싶어 한다. 그래서 '기관 전체 통일안'이 내려와도 '우리 부서는 좀 다르게 하고 싶다'는 마음이 생긴다. 색 하나, 배너 하나라도 우리 부서만의 개성을 넣고 싶어 한다. 이 마음 자체는 자연스럽지만, 모든 부서가 이러면 통일은 영영 불가능해진다. 그래서 디자인 시스템은 '부서의 개성을 어디까지 허용하고 어디부터 통일할지'의 선을 함께 정하는 일이기도 하다.

이 네 가지 힘은 따로 노는 게 아니라 함께 작동한다. 예산이 쪼개지고, 시간이 흩어지고, 사람이 바뀌고, 부서가 제 색을 고집한다. 이 모든 게 '공유된 기준의 부재'라는 빈틈으로 흘러들어 제각각을 만든다. 그러니 '부서별로 따로'를 고치려면 이 네 가지를 한꺼번에 묶어줄 기준이 필요하다. 그 기준이 디자인 시스템이고, 공공 영역의 표준이 KRDS다. KRDS는 행정안전부가 「전자정부 웹사이트 품질관리 지침」의 일환으로, NIA(한국지능정보사회진흥원)의 협력 아래 마련한 공공 디자인 표준이다. 부서가 달라도, 발주 시기가 달라도, 담당자가 바뀌어도 같은 약속을 보고 만들게 하자는 게 핵심 취지다.

■ 사례 1: 메인은 멀끔, 안쪽은 다른 세상 (가상의 ○○시)

가장 흔한 패턴부터 보자. 가상의 ○○시 사이트를 떠올려 보자. 메인 페이지는 꽤 잘 만들어져 있다. 작년에 큰 예산을 들여 메인을 새로 개편했기 때문이다. 색도 통일돼 있고, 메뉴도 깔끔하고, 큼직한 배너에 시정 소식이 잘 정리돼 있다. 여기까지만 보면 '아, 잘 관리되는 시구나' 싶다.

그런데 메인의 메뉴를 눌러 안쪽 부서 페이지로 들어가는 순간, 분위기가 확 바뀐다. 복지 담당 부서 페이지는 메인보다 한참 옛날 스타일이다. 글꼴이 다르고, 버튼 모양이 다르고, 메뉴가 화면 위가 아니라 왼쪽에 세로로 붙어 있다. 환경 담당 부서 페이지는 또 다르다. 여긴 메인과 비슷하게 개편됐는데, 미묘하게 파란색 톤이 다르다. 문화 행사 페이지는 아예 외부 업체가 만든 별도 사이트처럼 생겼다. 한 ○○시 안에서 세 개의 다른 사이트를 돌아다니는 기분이다.

왜 이렇게 됐을까. 메인은 '기관 전체' 예산으로 한 번에 개편됐지만, 안쪽 부서 페이지들은 각 부서가 따로따로 관리하기 때문이다. 개편 예산은 메인에 집중됐고, 부서 페이지까지는 손이 못 갔다. 그래서 메인만 새 옷을 입고, 안쪽은 헌 옷 그대로 남았다. 이건 ○○시만의 문제가 아니다. '메인만 개편하고 안쪽은 방치'는 공공 사이트 개편의 가장 흔한 함정이다. 예산이 한정돼 있으니 가장 눈에 띄는 메인부터 손대는 건 당연한데, 그 결과 '메인과 안쪽의 격차'라는 새로운 부조화가 생긴다.

사용자 입장에서 이게 왜 문제냐면, 사용자가 실제로 '일'을 하는 곳은 메인이 아니라 안쪽이기 때문이다. 메인은 잠깐 거쳐 가는 현관일 뿐이고, 민원을 넣고 신청을 하고 정보를 찾는 진짜 일은 안쪽 부서 페이지에서 일어난다. 그런데 그 안쪽이 제각각이고 낡았다면, 사용자는 가장 중요한 순간에 가장 불편한 화면을 만나는 셈이다. 현관만 번쩍이고 정작 일하는 사무실은 어수선한 건물과 같다.

더 큰 문제는 '신뢰'다. 메인은 멀끔한데 안쪽이 들쭉날쭉하면, 사용자는 무의식적으로 '이 시는 겉만 신경 쓰는구나'라는 인상을 받는다. 의식적으로 그렇게 평가하는 게 아니라, 그냥 막연하게 '여기 정보가 최신일까', '이 신청 제대로 처리될까' 하는 불안이 든다. 공공 서비스는 본질적으로 '믿고 맡기는' 서비스다. 개인정보를 입력하고, 신청을 맡기고, 민원을 넣는다. 그 신뢰의 바탕이 '정돈된 화면'에서 시작되는데, 안쪽이 누더기면 그 신뢰가 흔들린다.

디자인 시스템의 관점에서 이 문제는 명쾌하다. 메인이든 안쪽이든 '같은 부품, 같은 색, 같은 글꼴'을 공유하게 만들면 격차가 사라진다. KRDS는 바로 이 '공유'를 위한 표준이다. 메인 팀이 따로 디자인하고 부서 팀이 따로 디자인하더라도, 둘 다 KRDS라는 같은 약속을 보고 만들면 결과가 어울린다. ○○시가 '메인만 개편'이 아니라 '기관 전체가 같은 표준을 채택'으로 방향을 잡았다면, 안쪽 페이지를 일일이 새로 디자인하지 않아도 점진적으로 통일될 수 있었을 것이다.

■ 사례 2: 같은 일을 시키는데 화면마다 다른 절차 (가상의 한중앙부처)

이번엔 좀 더 깊은 문제다. 가상의 한중앙부처 사이트를 보자. 이 부처는 여러 종류의 '신청' 서비스를 제공한다. 어떤 국은 자격 증명 신청을, 어떤 국은 지원금 신청을, 어떤 국은 민원 접수를 받는다. 셋 다 본질적으로는 '사용자가 정보를 입력하고 제출하는' 같은 종류의 일이다. 그런데 화면을 보면 셋이 완전히 다른 방식으로 굴러간다.

자격 증명 신청 페이지는 한 화면에 모든 입력칸을 쭉 펼쳐놓는 방식이다. 이름, 주소, 연락처, 첨부파일이 한 페이지에 다 있다. 지원금 신청 페이지는 반대로 단계를 여러 개로 쪼갰다. '1단계 본인 확인 → 2단계 정보 입력 → 3단계 첨부 → 4단계 확인'으로 화면이 넘어간다. 민원 접수 페이지는 또 다르다. 입력칸 몇 개에 큰 텍스트 박스 하나가 전부인 단출한 형태다.

각각만 보면 다 나름 괜찮다. 문제는 사용자가 이 셋을 한 부처 안에서 오갈 때 생긴다. 자격 증명을 신청해 본 사용자는 '이 부처는 한 화면에 다 입력하는구나'라고 학습한다. 그런데 다음에 지원금을 신청하러 가니 갑자기 단계가 쪼개져 있다. '어, 아까랑 다르네?' 하고 당황한다. 민원을 넣으러 가니 또 다른 방식이다. 같은 부처인데 신청할 때마다 절차를 새로 익혀야 한다. 사용자는 '이 부처는 도대체 어떻게 신청하는 거야'라는 누적된 피로를 느낀다.

여기서 KRDS의 '서비스 패턴(SP)' 개념이 등장한다. KRDS 846개 규칙은 크게 네 묶음으로 나뉜다 — 디자인 스타일(DS) 120개, 컴포넌트(CP) 446개, 본문/콘텐츠 패턴(BP) 108개, 서비스 패턴(SP) 172개. 이 중 SP가 바로 '신청·검색·로그인·정책 안내 같은 서비스 흐름을 어떻게 일관되게 설계할 것인가'를 다룬다. 신청 흐름이라면 '어떤 순서로, 어떤 단계로, 어떤 확인 절차를 거쳐' 진행할지에 대한 표준 흐름이 있다. 한중앙부처의 세 신청이 이 SP 표준을 공유했다면, 셋의 입력 방식이 통일돼 사용자가 한 번 익힌 절차를 어디서나 똑같이 쓸 수 있었을 것이다.

'절차의 일관성'은 단순한 편의 문제가 아니다. 신청은 사용자가 '실수하면 안 되는' 일이다. 지원금 신청을 잘못하면 받을 돈을 못 받고, 자격 신청을 빠뜨리면 자격을 못 얻는다. 이렇게 중요한 일을 할 때, 화면마다 절차가 다르면 사용자는 매번 '내가 제대로 하고 있나'를 불안해한다. 반대로 절차가 일관되면, 한 번 성공해 본 사용자는 다음 신청도 자신 있게 해낸다. 절차의 일관성은 곧 '사용자가 실수 없이 일을 끝낼 수 있는 자신감'을 준다.

그리고 절차가 제각각이면 '도와주는 일'도 어려워진다. 콜센터 직원이 사용자를 전화로 안내한다고 해보자. 절차가 통일돼 있으면 '다음 버튼을 누르세요, 이제 2단계입니다'라고 한 가지 안내로 모든 신청을 도울 수 있다. 그런데 신청마다 절차가 다르면, 직원도 '이 신청은 어떻게 생겼더라'를 매번 확인해야 한다. 절차의 일관성은 사용자뿐 아니라 그 사용자를 돕는 사람들의 일까지 단순하게 만든다.

■ 사례 3: 한 페이지 안에서 두 개의 메뉴 (가상의 B공공기관)

이건 좀 기이한 사례인데, 의외로 자주 본다. 가상의 B공공기관 사이트의 어떤 페이지에 들어갔더니, 메뉴가 두 개다. 화면 위쪽에 기관 전체의 메뉴 바가 하나 있고, 그 아래 본문 영역에 또 다른 메뉴가 따로 있다. 위 메뉴는 '기관 소개 / 사업 안내 / 알림 / 민원' 같은 큰 분류고, 아래 메뉴는 그 부서가 자기 콘텐츠를 정리한 별도 메뉴다.

왜 이렇게 됐을까. 이 부서 페이지가 원래 '별도 사이트'로 만들어졌다가, 나중에 기관 통합 사이트 안으로 흡수됐기 때문이다. 통합하면서 기관 전체 메뉴 바를 위에 얹었는데, 부서가 원래 쓰던 메뉴는 그대로 남겨뒀다. 그래서 한 화면에 '기관의 메뉴'와 '부서의 메뉴'가 동시에 존재하는 이상한 구조가 됐다.

사용자 입장에선 혼란 그 자체다. '민원을 넣으려면 위 메뉴를 봐야 하나, 아래 메뉴를 봐야 하나?' 두 메뉴가 비슷한 항목을 가지고 있으면 더 헷갈린다. 위 메뉴에도 '알림'이 있고 아래 메뉴에도 '공지'가 있으면, 둘이 같은 건지 다른 건지 알 수가 없다. 어떤 항목은 위 메뉴에만 있고, 어떤 항목은 아래 메뉴에만 있어서, 사용자는 두 메뉴를 다 뒤져야 원하는 걸 찾는다. '메뉴가 많아서 좋은 것'이 아니라 '메뉴가 둘이라 길을 잃는 것'이다.

이건 KRDS의 컴포넌트(CP) 영역과 직결된다. CP 446개는 헤더, 내비게이션, 푸터, 버튼, 입력 폼, 탭, 아코디언 같은 '화면을 이루는 부품'의 표준을 다룬다. 그중 내비게이션(메뉴) 관련 표준은 '한 화면의 주된 길찾기 수단은 명확히 하나여야 한다', '메뉴의 위치와 동작이 일관돼야 한다' 같은 원칙을 담는다. B공공기관처럼 부서 흡수 과정에서 메뉴가 이중으로 남는 건, 이 '하나의 명확한 길찾기' 원칙이 무너진 전형적인 사례다.

이 사례가 보여주는 더 큰 교훈은 '통합은 합치는 게 아니라 정리하는 것'이라는 점이다. 별도 사이트를 통합 사이트로 흡수할 때, 그냥 위에 전체 메뉴를 얹고 끝내면 안 된다. 기존 부서 메뉴를 기관 전체 구조에 '녹여 넣는' 작업이 필요하다. 부서 메뉴의 항목들을 기관 메뉴 체계 안에 재배치하고, 중복을 제거하고, 하나의 일관된 길찾기로 정리해야 한다. 이 정리 작업을 안 하면 '물리적으로는 한 사이트인데 경험적으로는 두 사이트'인 어정쩡한 상태가 남는다. 디자인 시스템이 있으면 이 통합·정리가 훨씬 수월하다. '메뉴는 이렇게 하나로 둔다'는 표준이 있으니, 무엇을 남기고 무엇을 합칠지 판단할 기준이 있기 때문이다.

■ 사례 4: 같은 정보가 부서마다 다르게 적혀 있다 (가상의 A광역지자체)

지금까지가 '모양'의 제각각이었다면, 이번엔 '내용'의 제각각이다. 어쩌면 더 위험한 종류다. 가상의 A광역지자체 사이트를 보자. 이 지자체의 여러 부서가 같은 사업을 각자 자기 페이지에서 소개한다. 예를 들어 어떤 지원 사업의 신청 기간이, A부서 페이지엔 '○월 말까지'라고 적혀 있고, 같은 사업을 다루는 B부서 페이지엔 '○월 ○일까지'라고 다른 날짜로 적혀 있다.

이게 왜 생기냐면, 같은 정보가 여러 페이지에 '복사'돼 흩어져 있기 때문이다. 부서마다 자기 페이지에 정보를 직접 적어 넣으니, 한쪽에서 날짜가 바뀌어도 다른 쪽은 안 바뀐다. 정보의 '원본'이 어디인지, 어느 게 최신인지 아무도 모른다. 사용자는 두 페이지에서 다른 날짜를 보고 '대체 언제까지지?' 하고 혼란에 빠진다. 잘못된 날짜를 믿고 신청을 놓치는 사람도 생긴다. 모양의 불일치는 불편함을 주지만, 정보의 불일치는 실제 피해를 준다.

이건 디자인 시스템의 직접 영역은 아니지만, 깊이 연결돼 있다. 디자인 시스템이 '부품을 한 곳에서 관리해 모든 페이지가 공유하게' 만드는 사고방식이라면, 같은 사고방식을 '정보'에도 적용할 수 있다. 자주 바뀌는 핵심 정보(신청 기간, 담당 부서, 연락처 등)는 한 곳에 '원본'을 두고, 여러 페이지가 그 원본을 불러다 쓰게 만들면, 원본 한 번 고치면 모든 페이지가 함께 바뀐다. 색을 디자인 토큰으로 한 곳에서 관리하는 것과 똑같은 원리다. 디자인 시스템적 사고는 '모양'만이 아니라 '정보 관리'에도 확장되는 셈이다.

A광역지자체의 이 문제가 무서운 건, 평소엔 안 보인다는 점이다. 두 페이지의 날짜가 우연히 같을 때는 아무 문제가 없다가, 정보가 바뀌는 순간 어긋나기 시작한다. 그리고 그 어긋남을 발견하는 건 대개 '피해를 본 사용자'다. 신청을 놓친 사람이 민원을 넣고 나서야 '아, 우리 페이지 두 군데 날짜가 다르네'를 알아챈다. 사후약방문이다. 정보의 단일 원본을 정해두는 운영 습관은, 이런 사후약방문을 사전 예방으로 바꾼다.

여기서 한 발 더 나가면 '누가 정보의 주인인가'를 정하는 거버넌스 문제가 된다. 부서가 따로 정보를 관리하면 '이 정보는 누가 책임지고 최신으로 유지하는가'가 흐려진다. 디자인 시스템을 도입하는 기관들은 보통 이 질문도 함께 푼다 — 화면 부품의 주인을 정하듯, 핵심 정보의 주인도 정한다. '부서별로 따로'를 '하나의 기관으로' 바꾸는 일은, 결국 모양과 정보와 책임을 모두 '하나의 약속' 아래로 모으는 일이다.

■ 사례 5: 모바일에서 부서별 격차가 더 벌어진다 (가상의 C기관)

마지막 사례는 모바일이다. 가상의 C기관 사이트를 PC로 보면 부서별 격차가 그럭저럭 견딜 만하다. 그런데 같은 사이트를 휴대폰으로 열면 격차가 폭발한다. 어떤 부서 페이지는 모바일에 맞게 잘 줄어들어 손가락으로 누르기 편한데, 어떤 부서 페이지는 PC 화면을 그냥 축소만 해서 글자가 깨알 같고 버튼이 너무 작아 누를 수가 없다. 또 어떤 페이지는 가로로 스크롤을 해야 내용이 다 보인다.

왜 모바일에서 격차가 더 벌어질까. 부서 페이지를 만든 시기가 다르기 때문이다. 모바일 대응이 당연해진 건 비교적 최근이다. 오래전에 만든 부서 페이지는 애초에 PC만 생각하고 만들어졌다. 반면 최근에 만든 부서 페이지는 모바일을 우선으로 만들어졌다. 이 '시기의 격차'가 모바일에서 적나라하게 드러난다. PC에서는 화면이 넓어 어지간한 문제가 가려지지만, 모바일의 좁은 화면은 모든 부실함을 확대경처럼 키운다.

이게 특히 심각한 건, 공공 사이트 사용자의 상당수가 모바일로 접속하기 때문이다. 어르신, 디지털에 익숙하지 않은 사용자, 급한 일로 길에서 접속하는 사용자 — 이들에게 모바일은 기본 환경이다. 그런데 부서 페이지가 모바일에서 깨지면, 그 부서의 서비스는 그 사용자에게 '없는 서비스'나 마찬가지가 된다. 버튼이 작아 못 누르고, 글자가 작아 못 읽으면, 아무리 좋은 정책이라도 닿지 못한다. 공공 서비스의 핵심은 '누구도 빠뜨리지 않는 것'인데, 모바일 격차는 가장 도움이 필요한 사람부터 빠뜨린다.

KRDS는 이 지점을 명확히 다룬다. 디자인 스타일(DS)과 컴포넌트(CP) 표준은 '여러 화면 크기에서 일관되게 동작할 것', '손가락으로 누르는 환경에서 충분한 크기를 확보할 것' 같은 반응형 원칙을 담는다. 모든 부서가 이 표준을 공유하면, 어느 부서 페이지든 PC에서나 모바일에서나 비슷한 품질을 유지한다. C기관의 모바일 격차는 '반응형 표준을 모든 부서가 공유하지 않았다'는 사실의 결과다.

그리고 모바일 격차는 '부분 수리가 안 먹힌다'는 디자인 부채의 특징을 가장 잘 보여준다. 눈에 띄는 한두 페이지만 모바일에 맞게 고쳐도, 옆 부서 페이지로 넘어가면 다시 깨진다. 사용자는 사이트를 부서 단위로 보지 않고 하나의 경험으로 본다. 한 페이지만 잘 고치면 오히려 다른 페이지와의 격차가 도드라져 '여긴 새로 했나 본데 저긴 왜 이래' 하는 인상을 준다. 진짜 해결은 반응형 표준을 정해두고 모든 부서가 그걸 공유하게 만드는 거다.

■ 다섯 사례를 관통하는 한 줄 — 원인은 하나, 처방도 하나

여기까지 다섯 가지 사례를 봤다. ○○시의 메인-안쪽 격차, 한중앙부처의 절차 불일치, B공공기관의 이중 메뉴, A광역지자체의 정보 불일치, C기관의 모바일 격차. 얼핏 보면 다 다른 문제 같다. 하지만 깊이 들여다보면 원인은 하나다 — '부서들이 공유하는 약속이 없었다'는 것.

이게 왜 중요하냐면, 원인이 하나면 처방도 하나로 통하기 때문이다. 다섯 가지 문제를 각각 따로 고치려 들면 끝이 없다. 메인-안쪽 격차를 고치는 팀, 절차를 통일하는 팀, 메뉴를 정리하는 팀, 정보를 단일화하는 팀, 모바일을 손보는 팀이 따로 움직이면 비용도 다섯 배고 서로 충돌하기도 한다. 그런데 '공유된 디자인 시스템 도입'이라는 하나의 처방을 쓰면, 이 다섯 가지가 동시에 좋아지기 시작한다. 같은 색·글꼴·간격(DS)을 공유하면 모양 격차가 줄고, 같은 컴포넌트(CP)를 공유하면 메뉴·버튼이 통일되고, 같은 서비스 패턴(SP)을 공유하면 절차가 일관되고, 같은 반응형 원칙을 공유하면 모바일 격차가 좁혀진다. 정보 단일화 같은 운영 습관도 '한 곳에서 관리한다'는 같은 사고방식의 연장이다.

이게 디자인 시스템을 '페이지 디자인'이 아니라 '시스템'이라고 부르는 이유다. 시스템은 '한 페이지를 예쁘게 만드는 기술'이 아니라 '여러 페이지, 여러 부서, 여러 시기에 걸쳐 일관성을 유지하는 구조'다. 부서가 달라도, 시기가 달라도, 사람이 바뀌어도 같은 약속을 보고 만들게 하는 것 — 그게 시스템이 하는 일이다. 공공 영역에서 그 시스템을 표준으로 만들어 둔 게 KRDS이고, KRDS 846개 규칙(DS 120 + CP 446 + BP 108 + SP 172)은 '부서별 제각각'을 막는 구체적인 약속들의 모음인 셈이다.

여기서 한 가지 오해를 풀고 가자. '표준을 도입하면 모든 부서 페이지가 똑같아져서 개성이 사라지는 거 아니냐'는 걱정이다. 그렇지 않다. 디자인 시스템은 '기초 약속'을 통일하는 거지 '모든 걸 똑같게' 만드는 게 아니다. 색·글꼴·버튼·메뉴 같은 기초가 통일되면, 오히려 그 위에서 각 부서의 콘텐츠가 더 돋보인다. 통일된 틀이 있어야 그 안의 개성이 '무질서'가 아니라 '변주'로 읽힌다. 음악으로 치면, 같은 박자와 조성 위에서 각 악기가 자기 선율을 연주하는 것과 같다. 박자가 제각각이면 합주가 소음이 되지만, 박자를 맞추면 각 악기의 개성이 화음으로 살아난다. 표준은 개성을 죽이는 게 아니라 개성이 어우러질 무대를 만든다.

■ 그래서 '우리 사이트는 괜찮은가' — 자가 점검 체크리스트

여기까지 읽었으면 이제 '우리 사이트는 어떨까'가 궁금할 거다. 거창한 도구 없이도 부서별 제각각을 스스로 점검해 볼 수 있는 간단한 체크리스트를 정리해 본다. 휴대폰 하나 들고 우리 기관 사이트를 직접 돌아다니며 확인하면 된다.

첫째, 메인에서 안쪽 부서 페이지로 세 번 정도 들어가 보자. 들어갈 때마다 색·글꼴·메뉴 위치가 '확 바뀌는' 느낌이 드는가? 바뀐다면 ○○시 사례처럼 '메인만 개편, 안쪽은 방치' 상태일 가능성이 높다.

둘째, 우리 기관의 '신청' 서비스를 두 종류 이상 찾아 절차를 비교해 보자. 입력 방식이 같은가, 다른가? 한쪽은 한 화면, 한쪽은 단계별로 다르다면 한중앙부처 사례처럼 서비스 패턴이 통일되지 않은 거다.

셋째, 부서 페이지 안에 메뉴가 몇 개인지 세어 보자. 화면 위 메뉴 말고 본문 안에 또 다른 메뉴가 있는가? 있다면 B공공기관처럼 이중 메뉴의 혼란이 있을 수 있다.

넷째, 같은 사업이나 같은 정보가 두 페이지 이상에 나오는지 찾아, 날짜·연락처 같은 핵심 정보가 일치하는지 비교해 보자. 다르다면 A광역지자체 사례처럼 정보의 단일 원본이 없는 상태다.

다섯째, 똑같은 페이지들을 이번엔 휴대폰으로 열어 보자. 부서마다 모바일 품질이 들쭉날쭉한가? 어떤 페이지는 잘 줄어들고 어떤 페이지는 글자가 깨알 같다면, C기관처럼 모바일 격차가 있는 거다.

이 다섯 가지 중 하나라도 '우리도 그런데' 싶은 게 있다면, 그건 우리 기관에도 부서별 제각각이 자리 잡았다는 신호다. 다시 말하지만 자책할 일이 아니다. 거의 모든 공공 사이트가 정도의 차이일 뿐 이 패턴을 가지고 있다. 중요한 건 '있다는 걸 인식하는 것'이고, 인식하면 고칠 수 있다.

그런데 이 자가 점검에는 한계가 있다. 눈으로 보고 손으로 눌러서 알 수 있는 건 '큰 격차'뿐이다. 색이 미세하게 수십 종으로 흩어진 것, 버튼이 표준 위계를 어긴 것, 폼 라벨이 빠진 것, 키보드 포커스 신호가 없는 것 같은 '작지만 누적되는 문제'는 사람 눈으로 일일이 잡기 어렵다. 846개나 되는 규칙을 한 페이지 한 페이지 손으로 점검하는 건 현실적으로 불가능하다. 그래서 필요한 게 '자동 점검 도구'다.

■ 손으로 못 잡는 걸 자동으로 — ViewCheck가 하는 일

여기서 우리가 만드는 ViewCheck 이야기를 잠깐 하려 한다. 광고처럼 들리지 않게 최대한 솔직하게 적겠다. ViewCheck는 '공공 사이트가 KRDS와 행정안전부 품질관리 지침을 얼마나 지키고 있는지'를 자동으로 진단해 주는 도구다. 사람이 눈으로 며칠 걸려 점검할 일을, URL 하나 넣으면 자동으로 훑어준다.

앞서 다섯 가지 사례에서 본 문제들이 바로 ViewCheck가 잡아내는 것들이다. 색이 수십 종으로 흩어졌는지(DS 영역), 버튼·메뉴 같은 부품이 표준을 지켰는지(CP 영역), 본문·콘텐츠 패턴이 일관된지(BP 영역), 신청·검색 같은 서비스 흐름이 표준을 따르는지(SP 영역) — KRDS 846개 규칙을 기준으로 페이지를 분석해 '어디가 어떻게 어긋났는지'를 짚어준다. 사람 눈으로는 '대충 비슷한 파랑'으로 보이는 것도, 도구는 코드를 들여다보고 '여기 미세하게 다른 파랑이 몇 종 섞여 있다'를 정확히 잡아낸다.

특히 '부서별 제각각' 문제에는 다중 페이지 분석이 잘 맞는다. 메인 한 장만 보는 게 아니라 여러 부서 페이지를 함께 훑어서, '이 부서 페이지는 표준을 잘 지키는데 저 부서 페이지는 많이 어긋난다'는 걸 비교해 보여준다. 그래서 '우리 기관 안에서 어느 부서 페이지가 가장 손이 필요한지'를 한눈에 파악할 수 있다. 막연히 '우리 사이트가 좀 제각각인 것 같아'가 아니라, '어느 페이지의 무슨 규칙이 몇 개 어긋났다'는 구체적인 숫자로 보이니, 개선의 우선순위를 정하기가 쉬워진다.

분석이 끝나면 결과 화면 맨 위에 점수 카드가 뜬다. 디자인·컴포넌트·패턴·서비스 같은 영역별로 우리 사이트가 지금 몇 점인지, 행정안전부 7대 품질 영역(호환성·접근성·개방성·접속성·편의성·효율성·신뢰성)을 얼마나 충족하는지, 웹접근성 KWCAG 33항목은 어떤지가 카드로 정리된다. 복잡한 846개 규칙 결과를 한눈에 들어오는 점수로 요약해 주는 셈이다. 담당자가 윗선에 보고할 때, '우리 사이트 지금 이 상태입니다'를 이 점수 카드 한 장으로 설명할 수 있다.

■ 점검은 끝이 아니라 시작 — 그다음에 할 일

여기서 오해하면 안 되는 게 있다. 점검 도구가 점수를 매겨준다고 해서, 점수가 곧 해결은 아니다. ViewCheck 같은 도구의 진짜 가치는 '무엇을 먼저 고쳐야 하는지'를 알려주는 데 있다. 부서별 제각각이 심한 사이트는 고칠 게 너무 많아서 어디서부터 손대야 할지 막막하다. 그때 '이 규칙들이 가장 많이 어긋났고, 이게 사용자에게 가장 큰 영향을 준다'는 우선순위를 보면, 한정된 예산과 시간을 어디에 써야 할지 판단할 수 있다.

그리고 앞서 누누이 말했듯, 진짜 해결은 '기초부터, 그리고 모든 부서가 공유하는 약속을 만드는 것'이다. 점검으로 문제를 파악한 다음에는, 색·글꼴·간격 같은 기초 약속(DS)을 정하고, 버튼·메뉴 같은 부품(CP)을 표준화하고, 신청 같은 서비스 흐름(SP)을 통일하는 작업이 이어져야 한다. 이걸 한 부서가 아니라 기관 전체가 함께 채택해야 한다. KRDS는 그 '함께 채택할 약속'을 이미 만들어 둔 표준이니, 기관은 처음부터 약속을 새로 만들 필요 없이 'KRDS를 우리 기관 표준으로 삼는다'는 결정만 하면 된다.

점검을 정기적으로 하는 것도 중요하다. 부서별 제각각은 한 번 정리한다고 영영 안 생기는 게 아니다. 새 부서 페이지가 생기고, 담당자가 바뀌고, 외주가 새로 들어오면 또 슬금슬금 어긋나기 시작한다. 그래서 '정리 → 점검 → 또 정리'의 순환이 필요하다. 자동 점검 도구가 있으면 이 순환이 가볍다. 분기마다 한 번씩 사이트를 돌려보고, 새로 어긋난 게 없는지 확인하는 식으로 '부채가 다시 쌓이는 걸 막는' 관리가 가능해진다. 부채는 '쌓이기 전에 막는' 게 압도적으로 싸다는 걸 기억하자.

■ 사용자는 '하나의 기관'을 기대한다 — 멘탈 모델 이야기

조금 더 근본적인 이야기를 해보자. 왜 부서별 제각각이 그토록 사용자를 괴롭히는지를, '멘탈 모델'이라는 개념으로 풀어볼 수 있다. 멘탈 모델이란 사람이 어떤 것을 '이건 이렇게 돌아가겠지'라고 머릿속에 그려두는 예상도다. 우리는 처음 보는 물건도 이전 경험을 바탕으로 '대충 이렇게 쓰는 거겠지'를 짐작하며 쓴다. 문 손잡이를 보면 돌리거나 당길 줄 알고, 빨간 버튼을 보면 '위험하거나 중요한 거겠지' 짐작한다. 이 짐작이 맞으면 편하고, 어긋나면 당황한다.

웹사이트를 쓸 때도 똑같다. 사용자는 한 기관 사이트에 들어오면서 '이 기관은 이런 식으로 돌아가겠지'라는 멘탈 모델을 만든다. 메인에서 메뉴가 위에 있으면 '아, 이 기관은 메뉴가 위에 있구나' 하고 익힌다. 신청 버튼이 파란색이면 '파란 게 신청이구나' 하고 익힌다. 이렇게 한 번 익힌 모델을 가지고 안쪽 페이지로 들어간다. 그런데 안쪽 부서 페이지에서 메뉴가 옆으로 가 있고, 신청 버튼이 초록색이면, 사용자의 멘탈 모델이 깨진다. '어, 내가 익힌 거랑 다르네?' 하고 다시 처음부터 화면을 더듬어야 한다.

부서별 제각각의 본질적 해악이 바로 이거다. 사용자가 '하나의 기관'이라는 멘탈 모델로 들어왔는데, 안에서 부서마다 모델이 다르니 매 페이지에서 모델을 새로 만들어야 하는 거다. 이건 마치 한 건물에 들어갔는데 층마다 엘리베이터 버튼 위치가 다르고, 화장실 표시가 다르고, 비상구 방향이 다른 것과 같다. 한 건물인 줄 알았는데 들어가 보니 층마다 다른 규칙이 적용되면, 사람은 매 층에서 길을 잃는다.

잘 만든 사이트는 사용자의 멘탈 모델을 '배신하지 않는다'. 한 번 익힌 사용법이 어디서나 통한다. 그래서 사용자는 사이트를 '다룰 줄 알게' 되고, 익숙함과 자신감이 쌓인다. 이게 일관성의 진짜 가치다. 단지 보기 좋은 게 아니라, 사용자가 '이 사이트를 안다'는 느낌을 갖게 하는 것. 디자인 시스템은 결국 '사용자의 멘탈 모델을 한 기관 안에서 하나로 유지해 주는 약속'이다. 부서가 달라도 같은 모델로 동작하니, 사용자는 한 번 익히면 어디서나 편하다.

여기서 한 가지 더. 멘탈 모델은 '한 기관 안'에서만 작동하는 게 아니다. 사용자는 여러 공공 사이트를 오가며 '공공 사이트는 대체로 이렇게 돌아가지'라는 더 큰 모델도 만든다. 그래서 공공 영역 전체가 KRDS라는 공통 표준을 공유하면, 사용자는 A기관에서 익힌 사용법을 B기관에서도 그대로 쓸 수 있다. 처음 가는 공공 사이트인데도 '아, 여기도 비슷하네' 하고 금방 적응한다. KRDS가 한 기관의 통일을 넘어 '공공 영역 전체의 일관성'을 노리는 이유가 이것이다. 표준은 한 기관 안의 부서들을 묶을 뿐 아니라, 여러 기관을 사용자의 같은 멘탈 모델 아래로 묶는다. 이게 국가 차원에서 공공 디자인 표준을 만드는 진짜 큰 그림이다.

■ '제각각'이 만드는 진짜 비용 — 보이지 않는 청구서

지금까지 다섯 사례를 보면서 '불편하다', '헷갈린다'는 말을 자주 했다. 그런데 이 불편과 혼란이 단지 '기분 나쁨'으로 끝나는 게 아니다. 부서별 제각각은 실제로 돈과 시간과 신뢰를 갉아먹는다. 다만 그 청구서가 한눈에 안 보일 뿐이다. 이 '보이지 않는 청구서'를 항목별로 펼쳐 보자.

첫 번째 항목은 '사용자의 시간'이다. 사용자가 부서별로 다른 메뉴를 익히고, 다른 절차를 헤매고, 어긋난 정보 사이에서 진짜를 가려내는 데 쓰는 시간. 이건 사용자 한 명당으로 보면 몇 분 안 되지만, 하루에 수천, 수만 명이 들어오는 공공 사이트에서는 어마어마한 사회적 비용으로 불어난다. 한 사람이 신청 페이지에서 절차를 헤매느라 3분을 더 쓴다면, 만 명이면 3만 분, 즉 500시간이다. 공공 서비스가 '효율'을 말할 때, 이 사용자 시간의 총합을 빼놓으면 안 된다. 정돈된 사이트는 사용자 한 명 한 명의 몇 분을 아껴주고, 그 몇 분이 모이면 사회 전체의 큰 시간이 된다.

두 번째 항목은 '민원 응대 비용'이다. 사이트가 제각각이면 '이거 어디서 신청해요?', '날짜가 두 군데 다른데 뭐가 맞아요?' 같은 문의가 콜센터와 민원실로 쏟아진다. 사이트가 잘 안내했으면 사용자가 스스로 해결했을 일을, 사람이 일일이 전화로 받아 처리하는 거다. 이건 명백한 인건비다. 잘 정돈된 사이트는 '사람이 안 거들어도 사용자가 스스로 해내게' 만들어 이 비용을 줄인다. 디자인 시스템 도입의 효과를 측정할 때, 민원 문의 건수의 변화를 보는 기관들이 있는 이유가 이것이다. 화면이 명확해지면 '물어볼 일' 자체가 줄어든다.

세 번째 항목은 '제작·유지보수 비용'이다. 부서마다 바퀴를 새로 발명하니, 새 페이지 하나 만들 때마다 기본 부품부터 다시 디자인한다. 표준 부품이 있으면 '조립'으로 끝날 일을, 매번 '처음부터 제작'으로 하는 거다. 게다가 색 하나, 글꼴 하나 바꾸려 해도 흩어진 곳을 일일이 찾아 고쳐야 하니 유지보수가 대공사가 된다. 이 비용은 사이트가 오래될수록 눈덩이처럼 커진다. 디자인 부채의 이자가 바로 이 대목에서 청구된다.

네 번째 항목은 '기회의 손실'이다. 이게 가장 안 보이지만 어쩌면 가장 크다. 사이트가 불편해서 사용자가 신청을 포기하면, 그 사용자는 받았어야 할 혜택을 못 받는다. 좋은 정책을 만들어 놓고도, 그 정책으로 가는 길(사이트)이 불편해서 정작 필요한 사람에게 닿지 못하는 거다. 정책의 효과가 '설계'가 아니라 '전달'에서 새는 셈이다. 공공 서비스의 존재 이유가 '필요한 사람에게 닿는 것'이라면, 부서별 제각각은 그 존재 이유 자체를 갉아먹는다.

다섯 번째 항목은 '신뢰의 마모'다. 앞서도 말했지만 사용자는 정돈된 화면을 '잘 관리되는 곳'의 신호로, 누더기 화면을 '방치된 곳'의 신호로 읽는다. 부서별 제각각이 누적되면 기관 전체의 신뢰가 조금씩 마모된다. 신뢰는 한번 떨어지면 회복이 더디다. 이 마모는 당장 숫자로 안 잡히지만, '이 기관 사이트는 영 못 미덥다'는 평판으로 천천히 쌓여 결국 기관의 자산을 깎는다.

이 다섯 항목을 합치면, 부서별 제각각의 진짜 비용은 '페이지 몇 개 못생긴 것'과는 비교가 안 된다. 사용자의 시간, 민원 인건비, 제작·유지보수비, 기회 손실, 신뢰 마모 — 이 모든 게 청구서에 적혀 있는데, 그 청구서가 한 장으로 날아오지 않고 여기저기 흩어져 있어서 안 보일 뿐이다. 디자인 시스템 도입을 '비용'으로만 보면 망설여지지만, 이 보이지 않는 청구서를 합산해 보면 '안 하는 게 더 비싼' 경우가 대부분이다. 표준화는 지출이 아니라 절감인 경우가 많다.

■ 작은 불일치가 쌓이는 방식 — '티끌'이 '태산'이 되는 과정

부서별 격차처럼 '큰 제각각'만 문제가 아니다. 더 무서운 건 '작은 불일치'다. 한두 군데의 작은 어긋남은 누구도 신경 쓰지 않는다. 버튼 모서리가 살짝 더 둥글든, 여백이 몇 픽셀 더 넓든, 그게 무슨 대수냐 싶다. 그런데 이 작은 불일치들이 페이지마다, 요소마다 쌓이면, 어느새 사이트 전체가 '어딘가 어수선한' 인상을 풍긴다. 사용자는 정확히 뭐가 문제인지 짚지 못하면서도 '뭔가 정돈이 안 된 느낌'을 받는다.

이 '작은 불일치의 누적'은 사람 눈으로 잡기가 거의 불가능하다. 한 페이지를 볼 때는 '이 정도면 괜찮네' 싶다. 두 페이지를 나란히 놓고 봐야 '어? 여기 버튼이 좀 다르네'가 보이는데, 수십, 수백 페이지를 일일이 비교하는 건 현실적으로 안 된다. 게다가 색의 미세한 차이, 간격의 몇 픽셀 차이 같은 건 나란히 놓고 봐도 사람 눈으론 구분이 어렵다. 분명히 다른데 '비슷해 보여서' 그냥 넘어간다. 이렇게 '사람 눈에 안 잡히는 작은 불일치'가 쌓이는 게, 사이트가 '조용히 누더기가 되는' 진짜 메커니즘이다.

그래서 작은 불일치는 '기계의 눈'이 필요하다. 코드를 직접 읽어서 '이 페이지엔 파랑이 7종, 저 페이지엔 5종 쓰였고, 이 버튼의 모서리 둥글기는 표준과 다르다'를 정확히 짚어내는 건 사람보다 도구가 압도적으로 잘한다. 사람은 '비슷해 보이는 것'을 같다고 뭉뚱그리지만, 도구는 코드 값이 다르면 다르다고 정확히 구분한다. 이 '정확함'이 작은 불일치를 잡는 데 결정적이다. 큰 격차는 사람이 잡고, 작은 불일치는 도구가 잡는다 — 이 둘을 합쳐야 사이트의 일관성을 제대로 관리할 수 있다.

여기서 한 가지 위안이 되는 사실. 작은 불일치는 '잡기만 하면' 고치기는 의외로 쉽다. 색을 표준 토큰으로 통일하고, 간격을 표준 단위에 맞추고, 버튼 모서리를 표준 값으로 바꾸는 건 큰 재설계가 아니라 '값을 맞추는' 작업이다. 어려운 건 '어디가 어긋났는지 찾는 것'이지, 찾고 나면 고치는 건 비교적 단순하다. 그래서 '작은 불일치 찾기'를 도구에 맡기면, 담당자는 찾는 데 쓸 시간을 고치는 데 쓸 수 있다. 도구의 역할은 사람을 대신해 화면을 고치는 게 아니라, 사람이 '무엇을 고쳐야 하는지'를 한눈에 보게 해주는 것이다.

■ 어디서부터 손대야 하나 — 현실적인 우선순위

문제를 알았으니 이제 '어떻게 고치나'를 이야기할 차례다. 부서별 제각각이 심한 사이트를 보면 '이걸 다 언제 고치나' 싶어 막막하다. 그래서 현실적인 우선순위를 정하는 게 중요하다. 한 번에 다 못 고친다는 걸 인정하고, 가장 효과 큰 것부터 순서대로 가는 거다.

첫 번째 우선순위는 '기초(DS)'다. 앞서 건물 비유로 말했듯, 망가짐은 기초에서 시작되고 위로 갈수록 균열이 커진다. 그러니 고칠 때도 기초부터다. 색·글꼴·간격이라는 가장 작은 약속을 먼저 정하면, 그 위에 올리는 모든 작업이 자동으로 정돈된다. 신청 페이지가 불편하다고 신청 페이지부터 고치고 싶은 마음은 이해하지만, 기초를 건너뛰고 신청 페이지만 고치면 그 페이지는 또 '혼자만 다른 페이지'가 되어 새 부조화를 만든다. 급할수록 기초를 챙기는 게 멀리 보면 가장 빠르다.

두 번째 우선순위는 '사용자가 가장 많이 쓰는 흐름'이다. 모든 페이지를 똑같이 중요하게 대할 수는 없다. 방문자가 가장 많이 거치는 길, 가장 중요한 일이 일어나는 길부터 손봐야 한다. 대개는 신청·민원·검색 같은 핵심 서비스 흐름(SP)이다. 하루에 수천 명이 거치는 신청 흐름을 정돈하면, 적은 작업으로 가장 많은 사용자에게 가장 큰 개선을 줄 수 있다. 반대로 한 달에 몇 명 안 들어오는 구석 페이지를 먼저 손보는 건 효율이 낮다. '얼마나 많은 사람이, 얼마나 중요한 일을 하는 곳인가'를 기준으로 순서를 정하자.

세 번째 우선순위는 '새로 만드는 것부터 표준 적용'이다. 기존 페이지를 다 고치는 건 시간이 걸리지만, '앞으로 만드는 것'만큼은 오늘부터 표준을 지키게 할 수 있다. 새 부서 페이지를 만들 때, 새 사업을 발주할 때 'KRDS를 준수해 달라'는 한 줄을 넣는 것. 이렇게 하면 적어도 '부채가 더 쌓이는 건' 멈춘다. 이미 쌓인 부채를 갚는 건 천천히 하더라도, 새 부채가 안 생기게 막는 건 당장 할 수 있고 비용도 거의 안 든다. 부채 관리의 첫걸음은 '더 쌓이지 않게 멈추는 것'이라는 말을 여기서 다시 떠올리자.

네 번째 우선순위는 '접근성과 모바일'이다. 색·간격 같은 미관 문제보다, '아예 못 쓰는 사람이 생기는' 문제를 먼저 봐야 한다. 버튼이 작아 못 누르고, 글자가 작아 못 읽고, 키보드로 길을 잃는 사용자는 그 서비스를 '쓸 수 없는' 상태다. 미관 문제는 불편함이지만 접근성 문제는 배제다. 공공 서비스의 핵심이 '누구도 빠뜨리지 않는 것'이라면, 빠지는 사람부터 구하는 게 우선이다. 다음 달 접근성 편에서 이 이야기를 더 깊게 풀 예정인데, 우선순위를 정할 때 '배제되는 사용자가 있는 문제'를 맨 앞에 두는 원칙만은 기억해 두자.

이 네 가지 우선순위를 따라가다 보면, '한 번에 다 못 고친다'는 막막함이 '이것부터 하면 되는구나'라는 구체적 계획으로 바뀐다. 그리고 이 순서를 정하는 데 '지금 우리가 어디가 얼마나 어긋났는지'를 보여주는 점검 결과가 큰 도움이 된다. 막연한 느낌이 아니라 숫자로 우선순위를 정할 수 있기 때문이다.

■ 표준이 '있다'와 '쓴다'는 다르다 — 정착의 문제

마지막으로 한 가지 짚고 싶은 게 있다. KRDS 같은 표준이 '있다'는 것과 그게 우리 기관에 '쓰인다'는 건 전혀 다른 이야기라는 점이다. 표준은 만들어 둔다고 저절로 적용되지 않는다. 좋은 가이드 문서를 받아 서랍에 넣어두기만 하면 아무 일도 안 일어난다. 표준이 실제로 화면에 반영되려면, 그게 부서의 일상 업무에 녹아들어야 한다.

이게 왜 어렵냐면, 부서들은 이미 각자의 방식에 익숙하기 때문이다. '우리 부서는 원래 이렇게 해왔는데'라는 관성이 강하다. 새 표준을 적용하려면 익숙한 방식을 바꿔야 하고, 사람은 익숙한 걸 바꾸기 싫어한다. 그래서 '표준을 도입한다'는 결정만으로는 부족하다. 부서들이 그 표준을 '귀찮은 규제'가 아니라 '일을 덜어주는 도구'로 받아들이게 만드는 과정이 필요하다.

여기서 핵심은 '표준이 일을 덜어준다'는 걸 체감하게 하는 거다. 표준을 처음 익힐 때는 약간의 품이 든다. 하지만 한번 익히면 매번 '버튼 무슨 색으로 하지', '이 폼 어떻게 만들지'를 새로 고민하지 않아도 된다. 검증된 부품을 가져다 조립만 하면 되니까. 이 '편안함'을 부서가 직접 느끼는 순간, 표준은 강요가 아니라 선택이 된다. 그러니 표준을 정착시키려는 기관은 '지켜라'라고 압박하기보다, '이게 너희 일을 얼마나 편하게 해주는지'를 보여주는 데 공을 들여야 한다.

또 하나 중요한 건 '되돌아보는 장치'다. 표준을 도입해도 시간이 지나면 또 슬금슬금 어긋나기 시작한다. 새 담당자가 모르고, 새 외주가 안 지키고, 급한 일정에 쫓겨 예외를 만든다. 그래서 '정기적으로 점검해서 어긋난 걸 잡아내는' 장치가 있어야 표준이 살아 있는다. 점검이 없으면 표준은 '처음 한 번' 지켜지고 점점 흐려진다. 자동 점검 도구가 이 '되돌아보는 장치' 역할을 한다. 분기마다 사이트를 돌려 '이번엔 어디가 새로 어긋났나'를 확인하면, 표준이 종이 위 약속이 아니라 화면 위 현실로 유지된다.

정리하면, 부서별 제각각을 진짜로 끝내려면 세 가지가 함께 가야 한다. ① 모든 부서가 공유할 표준(KRDS)을 정하고, ② 그 표준이 부서의 일을 덜어주는 도구임을 체감하게 해 정착시키고, ③ 정기 점검으로 어긋남을 계속 잡아내는 것. 이 셋 중 하나만 빠져도 제각각은 다시 돌아온다. 표준만 있고 정착이 없으면 서랍 속 문서로 남고, 정착은 했는데 점검이 없으면 시간이 지나며 흐려진다. 셋이 함께 돌아갈 때 비로소 '한 번 정리하고 끝'이 아니라 '계속 정돈된 상태로 유지'가 가능해진다.

마무리

오늘 이야기를 한 줄로 줄이면 이렇다 — '부서마다 따로 만들면, 그 제각각의 비용은 결국 사용자가 치른다.'

기관은 부서로 나뉘어 일하는 게 자연스럽다. 예산도 부서별, 발주도 부서별, 담당자도 부서별이다. 그런데 사용자는 그 조직 구조를 모른다. 사용자에게 기관은 하나의 덩어리고, 그 덩어리가 안에서 제각각이면 사용자는 한 사이트 안에서 길을 잃는다. 메인과 안쪽의 격차, 신청 절차의 불일치, 이중 메뉴의 혼란, 정보의 어긋남, 모바일의 격차 — 오늘 본 다섯 가지 사례는 모두 '공유된 약속이 없었다'는 하나의 원인에서 나왔다.

다시 한번 강조하지만, 이 다섯 사례는 특정 기관을 흉보려는 게 아니다. 규모가 크든 작든, 예산이 많든 적든 거의 똑같이 반복되는 '전형'일 뿐이다. 그러니 '우리도 저런데' 싶은 대목이 나왔다면, 그건 부끄러워할 일이 아니라 '이제 보이기 시작했다'는 좋은 신호다. 보여야 고칠 수 있고, 고치는 출발점은 언제나 '이름을 붙여 인식하는 것'이다.

원인이 하나이니 처방도 하나다. 모든 부서가 같은 약속을 보고 만들게 하는 것, 그게 디자인 시스템이고 공공 영역의 표준이 KRDS다. KRDS 846개 규칙(DS 120 + CP 446 + BP 108 + SP 172)은 부서가 달라도, 시기가 달라도, 사람이 바뀌어도 같은 결과가 나오게 하는 구체적인 약속들이다. 표준은 부서의 개성을 죽이는 게 아니라, 그 개성이 무질서가 아니라 화음으로 어우러질 무대를 깔아준다.

그리고 그 시작은 '지금 우리 사이트가 어떤 상태인지'를 정확히 아는 것에서 출발한다. 막연히 '좀 제각각인 것 같아'가 아니라, 어느 페이지의 무슨 규칙이 몇 개 어긋났는지 숫자로 보면, 비로소 고칠 마음과 고칠 길이 함께 생긴다.

혹시 '우리 기관 사이트는 부서별로 얼마나 제각각일까'가 궁금하다면, 한 번 직접 확인해 보길 권한다. krds.viewcheck.co.kr 에 들어가 우리 사이트 주소를 넣으면 무료로 진단을 체험할 수 있다. 앞서 본 다섯 가지 사례 — 색의 난립, 절차의 불일치, 메뉴의 혼란, 정보의 어긋남, 모바일 격차 — 가운데 우리 사이트엔 어떤 게 있는지, KRDS 846개 규칙 기준으로 어디가 어떻게 어긋났는지를 점수 카드로 받아볼 수 있다. 큰맘 먹고 개편을 결정하기 전에, 가벼운 마음으로 '우리 현 위치'부터 확인해 보는 것 — 그게 부서별 제각각을 하나로 모으는 첫걸음이다.

끝으로 한 가지 당부를 남기고 싶다. 부서별 제각각을 발견했다고 해서 '우리 사이트는 엉망이다'라고 낙담하지 말자. 오늘 글 내내 강조했듯, 이건 거의 모든 공공 사이트가 겪는 일이고 누구의 잘못도 아니다. 조직이 부서로 나뉘어 일하는 한 자연스럽게 생기는 현상이고, 그래서 자연스럽게 풀 방법도 이미 마련돼 있다. 중요한 건 '있다는 걸 인식하는 것'과 '작은 것부터 시작하는 것'이다. 한 번에 다 고치려 들면 지쳐서 포기하지만, 기초부터 한 걸음씩, 새로 만드는 것부터 표준을 지키며 가면, 1년 뒤 2년 뒤 사이트는 분명히 달라져 있다. 부채가 이자를 붙여 쌓이듯, 정돈된 약속도 시간이 갈수록 복리로 효과를 낸다. 오늘 정한 작은 표준 하나가, 앞으로 만들 수백 개 페이지의 품질을 끌어올린다.

다음 글에서는 오늘 자주 등장한 '디자인 토큰' 이야기, 그러니까 색·글꼴·간격 같은 기초 약속을 어떻게 한 곳에서 관리하는지를 좀 더 깊게 풀어보려 한다. 오늘은 여기까지. 우리 기관 사이트를 사용자의 눈으로 한 번 천천히 돌아다녀 보는 것만으로도, 오늘 글의 절반은 이미 얻은 셈이다. 부서의 경계를 넘어, 사용자가 기대하는 '하나의 기관'으로 가는 길은 생각보다 가까이에 있다.