디자인 가이드 없이 만든 공공 사이트, 어떻게 망가지나

[수·실수사례] 디자인 가이드 없이 만든 공공 사이트, 어떻게 망가지나

══════════════════════════════════════════════════

공감·문제제기

월요일 글에서 KRDS가 뭔지, 왜 필요한지를 큰 그림으로 그렸다. 오늘은 좀 더 현장 이야기다. '디자인 가이드 없이 만든 공공 사이트는 실제로 어떻게 망가지는가'를 익명 사례로 풀어보려 한다.

월요일 글이 '왜 디자인 시스템이 필요한가'에 대한 답이었다면, 오늘 글은 그 반대편 — '없으면 어떻게 되는가'를 보여주는 셈이다. 어떤 것의 가치는 그게 없을 때 가장 선명하게 보인다. 평소엔 당연하게 여기던 일관성·정돈됨이 무너진 사이트를 보면, 비로소 '아, 이래서 기준이 필요하구나'가 피부로 와닿는다. 그래서 오늘은 일부러 '망가지는 쪽'을 자세히 들여다본다. 무엇이 어떻게 어긋나는지를 알아야, 그걸 막는 기준의 가치도 제대로 보이기 때문이다.

먼저 솔직한 이야기부터. 공공 사이트가 망가지는 건 대부분 '한 방에 크게'가 아니다. 오히려 '조금씩, 티 안 나게' 망가진다. 처음 만들 때는 그럭저럭 괜찮았는데, 시간이 지나면서 부서별 콘텐츠가 쌓이고, 새 사업 페이지가 붙고, 일부만 개편되면서 — 어느 순간 정신 차려보니 사이트가 누더기가 돼 있다.

이걸 '디자인 부채(design debt)'라고 부르기도 한다. 빚처럼 처음엔 작지만 이자가 붙어 점점 커진다. 그리고 빚이 그렇듯, 한참 쌓인 뒤에 갚으려면 처음보다 훨씬 큰 비용이 든다. 디자인 가이드, 즉 디자인 시스템이 없다는 건 이 부채가 무제한으로 쌓일 수 있는 상태라는 뜻이다.

부채 비유를 조금 더 밀고 가보자. 빚의 무서운 점은 '이자'다. 원금만 갚으면 되는 게 아니라 시간이 갈수록 갚아야 할 총액이 불어난다. 디자인 부채도 똑같다. 색이 제각각인 사이트에 페이지를 하나 더 추가하면, 그 새 페이지도 '제각각인 색 중 하나'를 따라 만들게 되고, 부채가 한 단계 더 쌓인다. 즉 부채가 있는 상태에서 만드는 모든 새 작업이 부채를 더 키운다. 그래서 '나중에 한 번에 정리하자'는 생각은 거의 항상 실패한다. 정리하기로 마음먹은 그 '나중'이 올 때쯤이면 부채가 두세 배로 불어 있기 때문이다. 부채는 '쌓이기 전에 막는' 게 압도적으로 싸다. 이미 쌓였다면 '더 쌓이지 않게 멈추는 것'이 첫 번째 할 일이다.

그리고 디자인 부채에는 '숨은 이자'가 하나 더 있다. 바로 사람의 피로다. 누더기가 된 사이트를 운영하는 담당자는 매번 '이건 또 어떻게 처리하지'를 고민하느라 지친다. 새 페이지 하나 올리는 데도 기준이 없어 헤매고, 윗선에서 '왜 이렇게 들쭉날쭉하냐'는 지적을 받으면 마음이 무겁다. 부채는 사이트만 망가뜨리는 게 아니라 그걸 다루는 사람의 의욕도 함께 갉아먹는다. 잘 정리된 가이드 하나가 담당자에게 주는 가장 큰 선물은, 어쩌면 '매번 고민하지 않아도 되는 편안함'일지 모른다.

오늘 다룰 사례들은 특정 기관 이야기가 아니다. 공공 사이트를 점검하다 보면 기관 종류·규모와 무관하게 반복적으로 나타나는 '전형적인 붕괴 패턴'들이다. 내 사이트에 하나라도 해당되는 게 있는지 체크하면서 읽어보면 좋겠다.

한 가지 미리 말해두고 싶은 게 있다. 이 글은 누구를 탓하려는 글이 아니다. 가이드 없이 만든 사이트가 망가지는 건 담당자가 게을러서도, 외주가 실력이 없어서도 아니다. 그냥 '공유된 규칙이 없는 상태에서 여러 사람이 오랜 시간 손을 대면' 자연스럽게 일어나는 일이다. 규칙이 없으니 각자 최선을 다해도 결과가 제각각이 되는 거다. 그러니 '우리 사이트가 이렇네' 싶은 대목이 나와도 자책할 필요 없다. 원인을 알면 고칠 수 있고, 고치는 출발점이 바로 이런 패턴을 '이름 붙여' 인식하는 거다.

그리고 또 하나. 붕괴 패턴은 대부분 '눈에 잘 안 띈다'는 공통점이 있다. 큰 사고처럼 빨간불이 켜지는 게 아니라, 사용자가 '뭔가 좀 불편한데 왜인지는 모르겠네' 하고 그냥 떠나버리는 식으로 조용히 손해가 난다. 그래서 담당자 입장에서는 문제가 있다는 걸 인지하기조차 어렵다. 민원이 들어오는 것도 아니고, 통계에 '디자인이 일관되지 않아 이탈했습니다'라고 찍히는 것도 아니니까. 오늘 이 글의 목적은 그 '조용한 손해'를 눈에 보이게 만드는 거다. 보이기 시작해야 고칠 마음이 생긴다.

개념·왜 중요한가

■ '가이드가 없다'는 건 정확히 무슨 상태인가

디자인 가이드가 없다는 걸 사람들은 흔히 '디자인이 안 예쁘다' 정도로 오해한다. 그게 아니다. 가이드의 부재는 '결정을 매번 새로 한다'는 뜻이다.

버튼 색을 정해야 한다. 가이드가 있으면 "표준 주 버튼 색을 쓰면 됨"으로 끝난다. 가이드가 없으면 매번 누군가 "이번 페이지 버튼은 무슨 색으로 하지?"를 고민하고 결정한다. 결정하는 사람이 다르고 시기가 다르니, 결과도 다르다. 페이지가 100개면 100번의 제각각인 결정이 쌓인다.

이 '매번 새로 결정하는 비용'은 생각보다 무겁다. 결정에는 시간이 들고, 결정한 걸 다시 설명하는 데 또 시간이 들고, 나중에 '저번에 어떻게 하기로 했더라'를 찾는 데 또 시간이 든다. 가이드가 없는 조직은 같은 결정을 몇 번이고 반복한다. 작년에 누군가 '우리 버튼은 이렇게 하자'고 정했어도, 그게 문서로 남지 않으면 그 사람이 자리를 옮기는 순간 사라진다. 그리고 새 담당자가 와서 또 처음부터 결정한다. 이렇게 '조직의 기억'이 사람에게만 의존하면, 사람이 바뀔 때마다 사이트의 기준도 함께 흔들린다. 가이드는 결국 '조직의 기억을 사람 바깥에 저장하는 장치'다. 담당자가 바뀌어도 기준이 남아 있게 하는 것, 그게 가이드의 본질적 역할이다.

그래서 '가이드가 없다'는 상태를 한 문장으로 정리하면 이렇다 — '공유되고 기록된 약속이 없어서, 매번 사람에 따라 결과가 달라지는 상태'. 이 정의를 기억해 두면 왜 가이드가 미관 문제가 아니라 운영 문제인지가 분명해진다. 예쁘냐 안 예쁘냐의 문제가 아니라, 예측 가능하냐 아니냐의 문제인 거다.

이 '매번 새로 하는 결정'이 누적되면 세 가지가 망가진다.

첫째, 일관성이 망가진다. 같은 기능을 하는 요소가 페이지마다 다르게 생긴다. 사용자는 매번 새로 학습해야 한다. 이 '매번 새로 학습'이 별것 아닌 것 같아도, 쌓이면 사용자를 지치게 한다. 한 페이지에서 익힌 사용법이 다음 페이지에서 안 통하면, 사용자는 매 페이지를 '처음 오는 사이트'처럼 더듬어야 한다. 익숙해질 기회를 주지 않는 사이트인 셈이다. 잘 만든 사이트는 한 번 익히면 어디서나 통하는 '예측 가능함'을 준다. 일관성은 결국 사용자가 '이 사이트를 다룰 줄 알게' 만드는 힘이다.

둘째, 효율이 망가진다. 만드는 쪽은 매번 바퀴를 새로 발명한다. 새 페이지 하나 만들 때마다 기본 부품부터 다시 디자인하니 시간과 비용이 계속 든다. 반대로 표준 부품이 있으면 새 페이지는 '부품을 조립하는 일'이 된다. 버튼·입력칸·카드 같은 검증된 부품을 가져다 배치만 하면 되니, 만드는 속도가 빨라지고 실수도 준다. 일하는 사람 입장에서 보면, 가이드는 '일을 더 시키는 규제'가 아니라 '일을 덜어주는 도구'다. 처음 익히는 데 약간의 품이 들 뿐, 한번 익히면 매번 똑같은 고민을 반복하지 않아도 된다.

셋째, 유지보수가 망가진다. 색 하나를 바꾸려 해도 어디에 어떤 색이 쓰였는지 추적이 안 된다. 100군데에 흩어진 색을 일일이 찾아 바꿔야 한다.

이 세 가지는 따로 노는 문제가 아니라 서로 물려 돌아가는 악순환이다. 일관성이 없으니 새로 만들 때 참고할 기준이 없고, 기준이 없으니 또 제각각 만들고, 그렇게 또 일관성이 깨진다. 유지보수가 어려우니 손대기 무서워서 방치하고, 방치하니 부채가 더 쌓인다. 한번 이 사이클에 들어가면 시간이 갈수록 빠져나오기 어려워진다. 그래서 '가이드를 만든다'는 건 단순히 문서 하나 추가하는 게 아니라, 이 악순환의 고리를 끊는 일이다.

여기서 한 가지 오해를 풀고 가자. '우리는 외주를 잘 줘서 매번 깔끔하게 나온다'고 안심하는 경우가 있는데, 외주를 줘도 가이드가 없으면 같은 문제가 생긴다. 아니, 오히려 더 심해질 수 있다. 외주 업체가 매번 다르거나, 같은 업체라도 투입되는 디자이너가 바뀌면, 각자의 '기본값'이 다르기 때문이다. A 업체의 기본 파랑과 B 업체의 기본 파랑이 다르고, 같은 업체라도 작년 담당자와 올해 담당자의 버튼 스타일이 다르다. 발주처에 공유된 디자인 가이드가 없으면, 업체는 '알아서 예쁘게' 만들 수밖에 없고, 그 '알아서'가 쌓여 누더기가 된다. 즉 가이드는 '우리가 직접 만들 때'만 필요한 게 아니라, '남에게 맡길 때' 더 절실하다. 발주 문서에 "KRDS를 준수해 주세요"라는 한 줄을 넣을 수 있느냐 없느냐가, 5년 뒤 사이트의 운명을 가른다.

그리고 이 '한 줄'은 발주처에도 큰 이점이 된다. 가이드가 없으면 결과물을 검수할 기준도 없다. 업체가 "예쁘게 만들었습니다" 하면 '예쁜지 아닌지'를 주관적으로 판단할 수밖에 없고, 마음에 안 들어도 '어디가 왜 잘못됐다'를 명확히 짚기 어렵다. 반면 KRDS 같은 공식 기준이 있으면 검수가 객관적이 된다. '이 버튼은 표준 위계를 안 지켰다', '이 폼은 라벨 규칙을 어겼다'고 근거를 들어 수정을 요청할 수 있다. 발주처와 업체가 같은 기준을 보고 일하니, '말이 다르다'는 소모적 다툼도 줄어든다. 가이드는 결국 발주처와 업체 모두에게 '공통의 언어'를 주는 셈이다. 좋은 기준 하나가 협업의 마찰을 크게 줄인다.

■ 망가짐은 '기초'에서 시작된다

흥미로운 건, 사이트 붕괴가 거의 항상 '기초' 영역(DS)에서 시작된다는 점이다. 색·글꼴·간격이 통일되지 않은 상태에서 그 위에 부품을 쌓고, 흐름을 만들면, 위로 갈수록 균열이 커진다.

여기서 '간격' 이야기를 잠깐 따로 해야겠다. 색과 글꼴은 그래도 눈에 띄는 편인데, 간격은 가장 티 안 나게 사이트를 어수선하게 만드는 주범이다. 요소와 요소 사이의 여백, 문단과 문단 사이의 거리, 카드 안쪽의 패딩 — 이런 간격이 페이지마다, 요소마다 제각각이면 사이트가 '정렬이 안 맞는' 느낌을 준다. 사용자는 '뭔가 비뚤어 보인다'고 느끼지만 정확히 뭐가 문제인지는 짚지 못한다. 잘 만든 사이트가 '깔끔하다'고 느껴지는 이유의 절반은 사실 이 간격의 규칙성이다. KRDS가 간격을 일정한 단위로 정해두는 이유가 여기 있다. 간격에 규칙이 있으면 누가 만들어도 '정렬된' 화면이 나오고, 규칙이 없으면 아무리 색과 글꼴이 통일돼 있어도 어딘가 어수선하다. 기초의 세 요소(색·글꼴·간격) 중 간격이 가장 과소평가되지만, 실은 가장 꾸준히 사이트의 인상을 좌우한다.

비유하자면 건물의 기초 공사다. 기초가 삐뚤면 1층은 약간 기울고, 2층은 더 기울고, 옥상은 위험할 만큼 기운다. 디자인도 똑같다. DS가 흔들리면 CP가 흔들리고, CP가 흔들리면 BP·SP가 무너진다. 그래서 망가진 사이트를 고칠 때도 기초부터 다시 잡는 게 정석이다.

이 '위로 갈수록 균열이 커진다'는 게 왜 그런지 조금 더 풀어보자. 기초(DS)는 색·글꼴·간격 같은 '가장 작은 단위의 약속'이다. 부품(CP)인 버튼은 이 약속을 가져다 쓴다 — 버튼의 색은 DS의 '주 색'을, 버튼 안 글자는 DS의 '본문 글꼴'을, 버튼의 안쪽 여백은 DS의 '간격 단위'를 빌려온다. 그러니 DS가 들쭉날쭉하면 버튼도 자동으로 들쭉날쭉해진다. 그 들쭉날쭉한 버튼들이 모여 폼(BP)을 이루고, 폼이 모여 신청 흐름(SP)을 이룬다. 결국 최상단의 '신청 흐름'이 엉망으로 보이는 진짜 원인이, 알고 보면 맨 아래 '색 약속이 없었다'는 데 있는 경우가 허다하다. 그래서 현장에서 사이트를 점검할 때, 사용자가 "신청이 너무 불편하다"고 호소해도 우리는 가장 먼저 DS부터 들여다본다. 증상은 위에서 터지지만 원인은 아래에 있을 때가 많기 때문이다.

또 하나 기억해 둘 것. 기초가 흔들린 사이트는 '부분 수리'가 잘 안 먹힌다. 눈에 띄는 페이지 하나만 예쁘게 고쳐도, 옆 페이지로 넘어가면 다시 누더기다. 사용자는 사이트를 페이지 단위로 보지 않고 '하나의 경험'으로 본다. 그래서 한 페이지만 잘 만들면 오히려 다른 페이지와의 격차가 도드라져서, '여기는 새로 만들었나 본데 저기는 왜 이래' 하는 인상을 준다. 진짜 해결은 기초 약속을 정해두고 모든 페이지가 그 약속을 공유하게 만드는 거다. 이게 디자인 시스템을 '페이지 디자인'이 아니라 '시스템'이라고 부르는 이유다.

그래서 '기초부터'라는 말이 처음엔 답답하게 들릴 수 있다. 눈에 보이는 신청 페이지가 불편하니 그것부터 고치고 싶은데, '색과 간격 약속부터 정하자'고 하면 '그게 지금 급한가' 싶은 거다. 하지만 기초를 건너뛰고 신청 페이지만 고치면, 그 페이지는 또 '혼자만 다른 페이지'가 되어 새로운 부조화를 만든다. 반면 기초를 먼저 정하면, 그 약속으로 신청 페이지를 고치는 순간 그 작업물이 '다른 모든 페이지와 어울리는' 결과가 된다. 즉 기초 작업은 '지금 당장 안 보이는 투자'지만, 그 위에 올리는 모든 작업의 효율을 끌어올리는 토대다. 급할수록 기초를 챙기는 게, 멀리 보면 가장 빠른 길이다.

흔한 실수·사례 (익명)

이제 구체적인 붕괴 패턴들을 보자. 점검 현장에서 거의 매번 만나는 단골 사례들이다. 다섯 가지 패턴은 따로 떨어진 게 아니라 대개 함께 나타난다. 색이 통제 불능인 사이트는 십중팔구 글꼴도 뒤섞여 있고, 버튼 위계도 없고, 폼 라벨도 부실하다. 왜냐하면 이 모든 게 '공유된 가이드가 없다'는 하나의 원인에서 비롯되기 때문이다. 그래서 패턴 하나가 보이면 '나머지도 있겠구나' 하고 함께 점검하는 게 효율적이다. 반대로 말하면, 가이드 하나를 제대로 도입하면 이 다섯 가지가 동시에 좋아진다. 원인이 하나니까 처방도 하나로 통한다.

읽기 전에 한 가지만 미리 일러둔다. 아래 사례들은 전부 익명 처리한 것이다. 특정 기관을 흉보려는 게 아니라, 어디서나 반복되는 '전형'을 보여주려는 거다. 실제로 이 패턴들은 규모가 크든 작든, 예산이 많든 적든 거의 똑같이 나타난다. 잘 만든 사이트라고 안 나오는 게 아니라 '덜 나오는' 정도의 차이일 뿐이다. 그러니 읽으면서 '우리도 저런데' 싶은 게 나와도 자책할 필요는 없다. 대부분이 겪는 일이고, 대부분이 같은 방법으로 풀어왔다. 중요한 건 그 패턴을 알아보는 눈을 갖추는 것이다. 패턴을 알면, 우리 사이트에서 그게 보일 때 '아, 이게 그거구나' 하고 바로 이름을 붙일 수 있다. 이름을 붙일 수 있으면 고칠 수도 있다.

■ 붕괴 패턴 1: 색이 통제 불능 상태

한 기관 사이트를 분석했더니, 사이트 전체에서 비슷비슷한 파란색이 수십 종 발견되는 경우가 있다. 사람 눈에는 다 '파란색'인데, 코드를 들여다보면 미세하게 다른 파랑이 제각각 하드코딩돼 있다. 어떤 건 진하고, 어떤 건 약간 연하고, 어떤 건 보라 끼가 돈다.

왜 이렇게 됐을까. 페이지를 만들 때마다 담당자나 외주가 '대충 비슷한 파랑'을 골라 직접 코드에 박았기 때문이다. 정해진 '브랜드 파랑' 하나를 공유해 쓴 게 아니라, 각자 눈대중으로 골랐다. 그 결과 사이트의 색이 통제 불능이 됐다.

여기서 흥미로운 건, 이걸 만든 사람들 중 누구도 '색을 망치자'고 생각하지 않았다는 점이다. 다들 그 순간엔 '이 정도 파랑이면 우리 사이트랑 어울리겠지'라고 최선을 다해 골랐다. 문제는 '기준이 머릿속에만 있었다'는 거다. 머릿속의 파랑은 사람마다 다르고, 같은 사람도 모니터가 바뀌면 다르게 본다. 어제 본 파랑과 오늘 고른 파랑이 미묘하게 다른데 본인은 같다고 믿는다. 이렇게 '각자의 머릿속 기준'으로 만든 결과물이 모이면, 개별로는 다 그럴듯한데 전체로는 제각각인 사이트가 된다. 그래서 색은 '잘 고르는 능력'의 문제가 아니라 '하나의 기준을 공유하느냐'의 문제다.

이게 왜 문제냐면, 나중에 브랜드 색을 바꾸려 할 때 지옥이 펼쳐진다. '우리 기관 파랑을 조금 더 밝게 바꾸자'는 단순한 요청이, 수십 종의 파랑이 흩어진 상태에서는 '어디에 어떤 파랑이 쓰였는지 전수조사'부터 해야 하는 대공사가 된다.

이런 상황은 생각보다 자주 온다. 기관 통합, 브랜드 개편, 상위 기관의 가이드 변경 — 색을 한 번에 바꿔야 할 일은 주기적으로 생긴다. 그때마다 '색 하나 바꾸는 데 왜 이렇게 오래 걸리고 돈이 드냐'는 질문을 받게 되는데, 답은 '색이 한 곳에 모여 있지 않아서'다. 정돈된 사이트라면 변수 하나 수정으로 끝날 일이, 통제 불능 상태에서는 수백 군데를 일일이 찾아 고치고, 빠뜨린 곳이 없는지 다시 검수하는 큰 작업이 된다. 그 비용 차이가 바로 '디자인 부채의 이자'다. 평소엔 안 보이다가 변경이 필요한 순간 청구서로 날아온다.

이걸 막는 게 바로 디자인 토큰이다. 색을 '브랜드-기본-파랑'처럼 이름 붙은 변수로 한 곳에서 관리하면, 바꿀 때 그 변수 하나만 고치면 사이트 전체에 반영된다. (디자인 토큰은 다음 달 주제로 깊게 다룬다.)

토큰의 또 다른 힘은 '색에 의미를 붙일 수 있다'는 거다. 단순히 '파랑 한 종'이 아니라 '주요 행동 색', '경고 색', '배경 색'처럼 역할 이름을 붙여 관리하면, 디자인할 때 '무슨 색을 쓸까'가 아니라 '이건 무슨 역할인가'로 생각하게 된다. 신청 버튼에는 '주요 행동 색'을, 삭제 버튼에는 '경고 색'을 쓰는 식이다. 이렇게 역할로 관리하면, 나중에 '우리 주요 행동 색을 바꾸자'는 결정이 사이트 전체의 모든 신청 버튼에 일관되게 반영된다. 색이 그냥 숫자가 아니라 '의미를 가진 약속'이 되는 거다. 이게 토큰이 단순한 '색 모음'을 넘어 '디자인 언어'로 불리는 이유다.

색 난립의 더 무서운 점은 '의미'까지 흐트러진다는 거다. 잘 설계된 사이트에서 색은 단순한 장식이 아니라 신호다. 빨강은 경고나 삭제, 초록은 성공이나 완료, 파랑은 주요 행동 — 이런 식으로 색마다 역할이 있다. 그런데 색이 통제 불능이 되면 이 신호 체계가 무너진다. 어떤 페이지에선 빨강이 '중요 공지'인데, 다른 페이지에선 빨강이 그냥 '제목 강조'다. 사용자는 색이 주는 신호를 더 이상 믿지 못하게 되고, 결국 색을 정보로 읽지 않고 무시하게 된다. 정작 진짜 경고를 빨강으로 띄워도 '또 그냥 강조겠지' 하고 넘겨버리는 거다. 색의 일관성은 미관 문제가 아니라 '정보 전달의 신뢰' 문제다.

그리고 색은 접근성과도 바로 연결된다. 색만으로 정보를 구분하면 색을 구분하기 어려운 사용자는 그 정보를 놓친다. 또 배경과 글자의 색 대비가 충분하지 않으면 저시력 사용자나 밝은 야외에서 보는 사용자가 글을 읽지 못한다. 색을 눈대중으로 박는 사이트는 이 대비 기준을 지키기가 거의 불가능하다. 매번 다른 파랑을 쓰니 어떤 조합은 우연히 대비가 충분하고 어떤 조합은 미달인데, 그걸 일일이 검사할 방법이 없기 때문이다. 표준 색 팔레트를 정해두면 '이 조합은 대비 통과'라는 걸 미리 검증해 둘 수 있다. 색을 통제한다는 건 결국 '누구나 읽을 수 있는 사이트'로 가는 첫걸음이기도 하다.

■ 붕괴 패턴 2: 글꼴 5종 잔치

또 흔한 게 글꼴이 뒤섞인 페이지다. 본문은 이 글꼴, 제목은 저 글꼴, 어디선가 복사해온 표는 또 다른 글꼴, 외부에서 가져온 위젯은 시스템 기본 글꼴... 한 페이지에서 글꼴이 네다섯 종 섞이는 경우가 의외로 많다.

글꼴이 섞이면 가독성과 신뢰감이 함께 떨어진다. 사용자는 '왜인지 모르게 어수선하다'고 느낀다. 정보를 읽는 데 미세한 피로가 쌓인다. 공공 정보는 정확하게 '읽히는' 게 생명인데, 글꼴 난립은 그 읽힘을 방해한다.

특히 '신뢰감'이 떨어진다는 점은 공공 사이트에서 결코 가볍지 않다. 사용자는 글꼴의 일관성을 의식적으로 평가하지 않지만, 무의식적으로는 '이 사이트가 잘 관리되고 있는가'의 단서로 받아들인다. 글꼴이 들쭉날쭉한 페이지를 보면 '여기 정보가 최신일까', '이 신청 제대로 처리될까' 같은 막연한 불안이 생긴다. 반대로 글꼴이 정돈된 페이지는 '제대로 관리되는 곳'이라는 인상을 준다. 같은 내용이라도 어떻게 보이느냐에 따라 신뢰가 달라지는 거다. 공공 서비스는 본질적으로 '믿고 맡기는' 서비스다. 민원을 넣고, 개인정보를 입력하고, 신청을 맡긴다. 그 신뢰의 바탕이 '정돈된 화면'에서 시작된다는 걸 생각하면, 글꼴 통일은 단순한 미관 작업이 아니라 신뢰 관리 작업이다.

KRDS가 공공 표준 서체와 타이포 위계를 제시하는 이유가 여기 있다. 제목·본문·캡션의 크기와 굵기를 체계적으로 정해두면, 누가 만들어도 정돈된 위계가 나온다.

글꼴 난립이 생기는 경로도 알아두면 예방에 도움이 된다. 가장 흔한 건 '외부 콘텐츠 붙여넣기'다. 보도자료를 워드에서 복사해 붙이면 그 워드의 글꼴이 따라 들어온다. 다른 사이트의 표를 그대로 가져오면 그 사이트의 스타일이 묻어온다. 외부 위젯이나 지도, 결제창 같은 걸 끼워 넣으면 그 서비스의 기본 글꼴이 그대로 노출된다. 이렇게 '바깥에서 온 글꼴'이 하나둘 쌓여 한 페이지에 다섯 종이 공존하게 된다. 그래서 글꼴 통제는 '처음 디자인'보다 '운영 중 관리'의 문제인 경우가 많다. 콘텐츠를 올릴 때 글꼴을 표준으로 정리하는 작은 습관, 외부 요소를 넣을 때 스타일을 우리 기준으로 덮어쓰는 처리 — 이런 운영 규칙이 있어야 글꼴이 흐트러지지 않는다.

글꼴 표준은 '어떤 서체를 쓰느냐'만이 아니라 '얼마나 크게, 얼마나 넉넉한 줄 간격으로 보여주느냐'까지 포함한다. 의외로 많은 공공 사이트가 본문 글자가 너무 작다. 만든 사람은 큰 모니터에서 보니 괜찮아 보이지만, 정작 그 정보가 가장 필요한 어르신이나 시력이 약한 분들에게는 깨알 같은 글씨가 된다. 공공 정보는 '누구나' 읽을 수 있어야 한다는 게 대전제인데, 본문이 작으면 그 대전제부터 무너진다. KRDS가 본문 최소 크기와 줄 간격까지 기준으로 두는 건, 멋을 내려는 게 아니라 '읽을 사람을 빠뜨리지 않으려는' 배려다. 글꼴 통일이 신뢰의 문제라면, 글자 크기는 곧 '읽을 권리'의 문제다. 화면을 키우지 않아도, 안경을 고쳐 쓰지 않아도 편히 읽히는 크기 — 그게 공공 서비스가 지켜야 할 최소선이다.

여기서 타이포 '위계'라는 말도 짚어두자. 위계는 단순히 글꼴 종류를 통일하는 것 이상이다. 제목은 크고 굵게, 소제목은 그보다 작게, 본문은 읽기 편한 크기로, 부가 설명은 더 작고 연하게 — 이렇게 크기와 굵기로 '정보의 중요도'를 시각적으로 표현하는 게 위계다. 위계가 잘 잡힌 페이지는 사용자가 글을 '읽기 전에' 구조를 파악한다. 어디가 제목이고 어디가 본문인지 한눈에 보이니, 필요한 정보를 빠르게 찾는다. 반대로 위계가 없으면 — 모든 글자가 비슷한 크기로 나열되면 — 사용자는 처음부터 끝까지 다 읽어야 원하는 정보를 찾을 수 있다. 공공 정보는 '찾으러 오는' 정보가 많다. 민원 방법, 신청 자격, 처리 기간 같은 걸 빠르게 찾아야 하는데, 위계 없는 페이지는 그 찾기를 방해한다. 글꼴 표준이 가독성을 지킨다면, 타이포 위계는 '찾기 쉬움'을 지킨다.

■ 붕괴 패턴 3: 정체불명의 버튼들

월요일 글에서도 언급했지만, 버튼 문제는 워낙 흔해서 다시 짚는다. 가이드 없는 사이트의 버튼은 정체가 불분명하다.

· 링크인지 버튼인지 모를 요소

· 주 버튼과 보조 버튼이 똑같이 생겨 위계가 없는 화면

· 비활성 상태인데 멀쩡해 보여 눌리는 버튼

· 호버(마우스 올림)·포커스(키보드 선택) 시 아무 반응이 없는 버튼

특히 마지막 '반응 없는 버튼'은 접근성과도 직결된다. 키보드로만 사이트를 쓰는 사용자는 지금 어디에 초점이 가 있는지 시각적 신호로 알아야 하는데, 그 신호가 없으면 길을 잃는다. 이건 다음 달 접근성 편에서 자세히 다룰 내용과 맞닿아 있다.

'정체불명의 버튼'이 생기는 근본 원인은 '버튼에도 종류가 있다'는 걸 정해두지 않았기 때문이다. 잘 설계된 사이트는 버튼을 역할별로 나눈다. 가장 중요한 행동(신청하기, 제출하기)을 하는 주 버튼은 가장 눈에 띄게, 그 다음 행동(취소, 이전)을 하는 보조 버튼은 한 단계 차분하게, 위험한 행동(삭제)은 경고색으로, 단순 이동은 링크 형태로 — 이렇게 '이건 어떤 버튼이다'가 모양에서 드러나야 한다. 이 구분이 없으면 모든 버튼이 똑같이 생겨서, 사용자는 '어느 걸 눌러야 하지?'를 매번 고민하게 된다. 화면에 버튼이 다섯 개 있는데 다 똑같이 생겼다면, 그건 '선택지가 다섯 개'가 아니라 '혼란이 다섯 개'다. 버튼의 위계는 사용자가 '무엇을 해야 하는지'를 망설임 없이 알게 해주는 안내판이다.

그리고 버튼 문제는 모바일에서 한 번 더 터진다. 손가락으로 누르는 환경에서는 버튼이 충분히 커야 정확히 눌린다. 가이드 없는 사이트의 버튼은 PC 화면 기준으로만 만들어져서, 모바일에서 너무 작거나 서로 너무 붙어 있는 경우가 많다. 누르려던 버튼 옆의 다른 버튼이 눌려서 엉뚱한 페이지로 가거나, 잘못 신청 버튼을 눌러 당황하는 일이 생긴다. 공공 사이트는 어르신을 비롯해 디지털에 익숙하지 않은 사용자도 많이 쓴다. 버튼 하나가 작아서 못 누르면, 그 사용자에게 그 서비스는 '없는 서비스'나 마찬가지다. 표준은 누구나 정확히 누를 수 있는 최소 크기를 정해두어 이 문제를 막는다.

버튼과 관련해 한 가지 더 흔한 문제는 '버튼 글자'다. 같은 기능을 하는 버튼인데 어떤 페이지에선 '신청', 어떤 페이지에선 '접수', 또 어떤 페이지에선 '제출하기'라고 적혀 있으면, 사용자는 '이게 같은 건가 다른 건가' 헷갈린다. 버튼 글자는 짧지만 사용자가 행동을 결정하는 핵심 단서다. 그래서 잘 만든 사이트는 '무슨 행동을 하는 버튼은 무슨 단어로 쓴다'는 것까지 약속해 둔다. 이건 디자인을 넘어 '말투의 일관성' 문제이기도 한데, 이 '공공 사이트의 글쓰기(UX 라이팅)'는 따로 한 달을 잡아 다룰 만큼 중요한 주제다. 일단 오늘은 '버튼은 모양만이 아니라 글자도 통일돼야 한다'는 것만 기억해 두자.

■ 붕괴 패턴 4: 라벨 없는 입력칸

신청·문의 폼에서 자주 보이는 문제다. 입력칸은 있는데 그 칸이 '무엇을 적는 칸인지' 명확한 라벨이 없다. 칸 안에 흐릿한 안내문(placeholder)만 있다가, 입력을 시작하면 그 안내문이 사라져서 '내가 지금 뭘 적고 있는 칸이었지?' 헷갈리게 된다.

라벨이 제대로 안 붙은 폼은 두 가지를 동시에 망친다. 일반 사용자는 실수로 엉뚱한 칸에 잘못 입력하고, 스크린리더를 쓰는 사용자는 그 칸이 뭘 위한 칸인지 아예 알 수 없다. 작은 라벨 하나가 '쓸 수 있느냐 없느냐'를 가른다.

라벨 문제는 '안내문(placeholder)으로 라벨을 대신하면 된다'는 흔한 착각에서 시작된다. 칸 안에 흐릿한 글씨로 '이름을 입력하세요'라고 적어두면 깔끔해 보이고 공간도 절약되니, 라벨을 따로 안 붙이고 싶은 유혹이 든다. 하지만 안내문은 입력을 시작하는 순간 사라진다. 긴 폼을 작성하다 중간에 '이 칸이 뭐였더라' 하고 위를 봐도 라벨이 없으니 확인할 길이 없다. 특히 어르신이나 천천히 입력하는 사용자일수록 이 '사라진 안내' 때문에 더 헤맨다. 그래서 표준은 '라벨은 항상 보이게, 안내문은 보조로만'을 원칙으로 둔다.

라벨에는 '무엇을 적는 칸인가'뿐 아니라 '어떻게 적어야 하는가'도 담겨야 한다. 전화번호를 하이픈 넣고 적어야 하는지, 날짜를 어떤 형식으로 적어야 하는지, 필수 항목인지 선택 항목인지 — 이런 정보가 입력 '전에' 보여야 사용자가 한 번에 제대로 적는다. 이게 없으면 사용자는 일단 적고, 제출하고, 오류를 만나고, 다시 고치는 과정을 반복한다. 좋은 폼은 '틀린 다음에 알려주는' 게 아니라 '틀리기 전에 알려주는' 폼이다. 라벨 하나를 제대로 붙이는 작은 일이, 신청 완료율을 눈에 띄게 끌어올리는 이유가 여기 있다.

'필수'와 '선택'의 구분도 라벨이 책임져야 할 몫이다. 어떤 칸은 꼭 적어야 하고 어떤 칸은 비워도 되는데, 그 구분이 화면에 안 보이면 사용자는 '다 적어야 하나' 싶어 불필요한 정보까지 입력하거나, 반대로 '필수인 줄 모르고' 비워뒀다가 제출 단계에서 막힌다. 잘 만든 폼은 필수 항목을 분명히 표시하고, 가능하면 '왜 이 정보가 필요한지'까지 짧게 덧붙인다. 공공 폼은 특히 개인정보를 다루는 경우가 많아, '이 정보를 왜 받는가'가 보이면 사용자의 거부감이 줄고 신뢰가 올라간다. 라벨은 단순한 칸 이름표가 아니라, 사용자가 '안심하고 정확하게' 적도록 돕는 안내자인 셈이다. 그래서 폼 하나를 잘 만든다는 건, 입력칸을 예쁘게 배치하는 게 아니라 '사용자가 헤매지 않고 한 번에 끝내게' 만드는 일이다.

폼에서 또 자주 무너지는 게 '필수와 선택의 구분'이다. 어떤 칸이 꼭 채워야 하는 칸이고 어떤 칸이 비워도 되는 칸인지가 분명하지 않으면, 사용자는 안전하게 '다 채우려' 하거나 반대로 '대충 비우고' 제출했다가 막힌다. 별표 하나, '(선택)'이라는 한 단어가 이 혼란을 없앤다. 사소해 보이지만 긴 폼일수록 이 표시 하나가 작성 속도와 정확도를 크게 바꾼다. 공공 폼은 본래 묻는 항목이 많다. 그 많은 항목 중 무엇이 정말 필요한지를 명확히 안내하는 것, 그게 사용자에 대한 배려다.

■ 붕괴 패턴 5: 끝에서 무너지는 흐름

가장 뼈아픈 붕괴는 흐름의 끝에서 일어난다. 월요일 글의 '마지막에 무너지는 신청' 사례가 대표적이다. 단계마다 입력은 받는데, 오류가 나면 어디가 틀렸는지 짚어주지 않는다. 진행 단계가 몇 개인지, 지금 어디쯤인지도 안 보인다. 사용자는 '끝이 안 보이는 터널'을 걷는 기분이 된다.

이건 부품(CP) 하나의 문제가 아니라 흐름(BP·SP)의 문제라 더 까다롭다. 버튼 하나 고친다고 해결되지 않는다. 신청이라는 여정 전체를 다시 설계해야 한다. 그래서 흐름 붕괴는 발견이 늦을수록 고치는 비용이 커진다.

흐름이 끝에서 무너지는 게 특히 뼈아픈 이유는, 그 지점까지 사용자가 이미 많은 걸 투자했기 때문이다. 정보를 찾고, 자격을 확인하고, 여러 칸을 채우고, 첨부파일까지 올린 사용자가 마지막 제출 단계에서 정체불명의 오류를 만나면, 그동안의 노력이 한순간에 무너진다. 더 안타까운 건 이렇게 끝에서 이탈한 사용자가 '재방문'을 잘 안 한다는 점이다. 한 번 '이 사이트는 신청이 안 되는 사이트'라는 인상이 박히면, 다음에 같은 민원이 필요해도 '또 그 고생을 하느니 직접 방문하자'가 된다. 온라인으로 처리하면 끝날 일이 창구 방문으로 돌아오고, 결국 기관의 행정 부담으로 되돌아온다. 사용자 한 명의 신청 실패가 기관의 업무량으로 부메랑처럼 돌아오는 거다.

그래서 흐름을 설계할 때 가장 중요한 세 가지는 '지금 어디쯤인지 보이기'(진행 표시), '무엇이 틀렸는지 그 자리에서 알려주기'(인라인 오류 안내), '되돌아가도 입력이 날아가지 않기'(상태 유지)다. 이 세 가지는 화려한 기능이 아니라 '기본 예의'에 가깝다. 사용자에게 '당신이 지금 무엇을 하고 있고, 무엇이 남았고, 무엇을 잘못했는지'를 정직하게 알려주는 것. 가이드가 있는 사이트는 이 세 가지를 표준 패턴으로 갖추고 있어서, 어떤 신청 페이지를 만들어도 사용자가 길을 잃지 않는다. 흐름의 표준화는 '끝까지 완주하게 돕는 안전장치'인 셈이다.

오류 안내에 대해 한마디 더 보태자. 가장 나쁜 오류 메시지는 '오류가 발생했습니다' 한 줄이다. 무엇이, 어디서, 왜 틀렸는지가 없으니 사용자는 그저 막막하다. 좋은 오류 안내는 세 가지를 담는다 — 어느 칸이 문제인지(위치), 무엇이 잘못됐는지(원인), 어떻게 고치면 되는지(해결). '전화번호 형식이 올바르지 않습니다. 숫자만 입력해 주세요'처럼 구체적이어야 사용자가 바로 고친다. 그리고 그 안내는 문제가 난 칸 '바로 옆'에 떠야 한다. 페이지 맨 위에 빨간 박스로 '입력값을 확인하세요'만 띄우면, 사용자는 어느 칸이 문제인지 찾느라 다시 헤맨다. 오류 안내의 질이 곧 그 사이트의 친절함이다. 흐름이 끝에서 무너지는 사이트의 십중팔구는 이 오류 안내가 부실하다.

'진행 표시'와 '상태 유지'도 흐름의 완주율을 좌우하는 결정적 요소다. 다섯 단계짜리 신청을 하는데 지금이 몇 단계인지, 앞으로 얼마나 남았는지 안 보이면, 사용자는 '이게 언제 끝나나' 싶어 중간에 그만둔다. 끝이 보이는 길은 걸을 수 있지만, 끝이 안 보이는 길은 포기하게 된다. 그래서 '1/5, 2/5...' 같은 진행 표시 하나가 완주율을 눈에 띄게 끌어올린다. 상태 유지도 마찬가지다. 길게 적던 신청서에서 뒤로 가기 한 번에 입력이 모두 날아가 버리면, 그 좌절감은 그대로 이탈로 이어진다. 잘 만든 흐름은 사용자가 실수로 뒤로 가도, 새로고침을 해도 적던 내용을 지켜준다. 이런 배려가 쌓여야 사용자가 '이 사이트는 끝까지 갈 만하다'고 믿고 완주한다. 결국 흐름의 표준화란, 사용자가 어느 단계에서도 길을 잃지 않고 '안심하고 끝까지 갈 수 있게' 만드는 일이다.

실무 적용·체크리스트

붕괴 패턴을 알았으니, 내 사이트가 이미 망가지고 있는지 점검하는 법을 정리한다. 아래 항목 중 '그렇다'가 많을수록 디자인 부채가 쌓여 있다는 신호다.

점검에 들어가기 전에 마음가짐 하나만. 점검의 목적은 '점수 매기기'가 아니라 '다음에 뭘 할지 정하기'다. '그렇다'가 많다고 좌절할 필요 없고, 적다고 안심할 필요도 없다. 중요한 건 '어느 영역에 문제가 몰려 있는가'를 파악해서 손볼 순서를 정하는 거다. 기초에 문제가 많으면 기초부터, 흐름에 문제가 많으면 핵심 흐름부터 — 점검 결과는 그 우선순위를 정하는 지도다. 그러니 솔직하게 체크하는 게 가장 이득이다. 좋게 보려고 후하게 채점하면 정작 고쳐야 할 곳을 놓친다.

그리고 점검은 '대표 페이지 몇 개'가 아니라 '사용자가 실제로 많이 쓰는 페이지'를 대상으로 해야 한다. 메인 페이지는 보통 가장 공들여 만들기 때문에 멀쩡한 경우가 많다. 정작 문제는 사용자가 진짜 일을 보러 가는 신청·민원·검색·예약 페이지에 숨어 있다. 그래서 점검 대상을 고를 때 '우리 사이트에서 사용자가 가장 자주, 가장 중요하게 쓰는 흐름이 무엇인가'를 먼저 떠올리고, 그 흐름을 처음부터 끝까지 따라가며 점검하는 게 가장 효과적이다. 보여주기용 페이지가 아니라 일하는 페이지를 봐야 진짜 상태가 보인다.

■ 기초(DS) 점검

· 같은 '파랑'인데 페이지마다 미묘하게 다른 색이 보이는가?

· 한 페이지에서 글꼴이 세 종 이상 섞여 있는가?

· 요소 간 간격이 들쭉날쭉해 정렬이 안 맞아 보이는가?

· 모서리 둥글기, 그림자 같은 디테일이 페이지마다 다른가?

기초 점검은 '한 화면씩' 보지 말고 '여러 화면을 나란히 놓고' 보는 게 요령이다. 메인, 목록, 상세, 신청 페이지를 동시에 띄워 비교하면 같은 요소가 페이지마다 어떻게 달라졌는지 한눈에 보인다. 혼자 보면 '이 정도면 괜찮은데' 싶던 것도, 나란히 놓으면 균열이 도드라진다. 특히 색과 간격은 한 화면 안에서는 잘 안 보이고 화면을 옮길 때 비로소 차이가 드러난다. 그래서 기초 점검은 '비교'가 핵심이다.

■ 부품(CP) 점검

· 무엇이 버튼이고 무엇이 링크인지 한눈에 구분되는가?

· 주 버튼과 보조 버튼의 위계가 분명한가?

· 버튼에 마우스를 올리거나 키보드로 선택했을 때 반응이 보이는가?

· 입력칸마다 '무엇을 적는 칸인지' 라벨이 붙어 있는가?

부품 점검은 '마우스를 떼고' 해보면 숨은 문제가 잘 드러난다. 키보드의 탭 키만으로 페이지를 돌아다녀 보는 거다. 탭을 누를 때마다 초점이 어디로 가는지 시각적으로 보이는지, 순서가 자연스러운지, 버튼이 엔터로 눌리는지를 확인하면, 마우스로는 멀쩡해 보이던 사이트의 허점이 줄줄이 나온다. 이건 접근성 점검의 기본이기도 하고, 동시에 '부품이 제대로 만들어졌는지'를 가장 빠르게 검증하는 방법이기도 하다. 잘 만든 버튼·입력칸은 마우스 없이도 다 작동한다. 그렇지 않다면 그 부품은 '보이기만 하는 부품'이다.

■ 흐름(BP·SP) 점검

· 여러 단계 흐름에서 '지금 몇 단계인지'가 보이는가?

· 오류가 났을 때 '어디가, 왜 틀렸고, 어떻게 고치라'고 알려주는가?

· 검색 결과가 0건일 때 다음에 뭘 하라고 안내하는가?

· 신청·예약 같은 핵심 흐름이 중간에 끊기지 않고 끝까지 이어지는가?

흐름 점검은 '일부러 틀려보기'가 가장 확실하다. 필수 칸을 비워두고 제출해 보고, 형식에 안 맞는 값을 넣어보고, 중간에 뒤로 가기를 눌러본다. 이렇게 일부러 어긋나게 행동했을 때 사이트가 어떻게 대응하는지를 보면 흐름의 완성도가 그대로 드러난다. 친절한 사이트는 '무엇이 왜 틀렸고 어떻게 고치라'를 그 자리에서 알려주고, 뒤로 가도 입력을 지켜준다. 불친절한 사이트는 '오류가 발생했습니다' 한 줄만 띄우거나, 처음부터 다시 적게 만든다. 핵심 흐름 한두 개만 이렇게 '일부러 틀려보며' 끝까지 가보면, 사용자가 실제로 어디서 좌절하는지 금방 알 수 있다.

흐름 점검이 중요한 데는 현실적인 이유도 있다. 기초나 부품의 결함은 '조금 불편한' 수준에 그치는 경우가 많지만, 흐름의 결함은 곧바로 '일을 못 끝내는' 결과로 이어진다. 색이 조금 어긋나도 신청은 할 수 있다. 하지만 신청 흐름이 중간에 끊기면, 사용자는 그날 처리하려던 일을 끝내지 못한다. 그러면 다시 전화로 묻거나, 직접 방문하거나, 아예 포기한다. 그 부담은 결국 다시 행정으로 돌아온다. 그래서 점검에서 '그렇다(문제 있다)'가 흐름 영역에 몰려 있다면, 그건 다른 어떤 영역보다 먼저 손봐야 한다는 신호다. 사용자가 일을 끝낼 수 있느냐 없느냐가 걸린 문제이기 때문이다. 점검을 마쳤을 때 '색이 세 군데 어긋났다'와 '신청이 한 군데서 끊긴다'가 같이 나왔다면, 망설일 것 없이 신청 끊김부터 고치는 게 맞다.

■ 운영 관점 점검

· 색이나 글꼴을 '한 곳에서' 바꿀 수 있는 구조인가, 아니면 수십 군데를 찾아 고쳐야 하는가?

· 새 페이지를 만들 때 가져다 쓸 '표준 부품'이 있는가, 매번 새로 만드는가?

· 부서가 콘텐츠를 추가해도 사이트 통일감이 유지되는가?

운영 관점 점검이 사실 가장 중요하다. 앞의 세 점검이 '지금 상태'를 본다면, 운영 점검은 '앞으로 망가질지'를 본다. 지금 사이트가 깔끔해도 운영 구조가 없으면 시간이 지나며 다시 누더기가 된다. 반대로 지금 좀 어수선해도 표준 부품과 한 곳 관리 구조가 있으면 점점 좋아진다. 그래서 '이번에 예쁘게 만들었다'보다 '앞으로도 유지될 구조를 만들었다'가 진짜 성과다. 디자인 시스템의 본질은 일회성 디자인이 아니라 '지속 가능한 운영 체계'라는 걸, 이 운영 점검이 일깨워준다.

운영 구조가 있고 없고의 차이는 시간이 갈수록 벌어진다. 표준 부품과 한 곳 관리가 있는 사이트는 새 페이지를 만들 때마다 '이미 검증된 부품'을 가져다 조립하니, 만들수록 빨라지고 통일감도 자동으로 유지된다. 반대로 그게 없는 사이트는 새 페이지마다 색·글꼴·버튼을 새로 결정하니, 만들수록 제각각이 되고 손볼 곳도 늘어난다. 같은 1년을 보내도 한쪽은 점점 정돈되고 한쪽은 점점 어수선해진다. 그래서 운영 점검에서 '아니다(구조가 없다)'가 많이 나왔다면, 그건 지금 당장의 문제라기보다 '앞으로 계속 새는 구멍'이라는 뜻이다. 이 구멍을 막는 게 어떤 개별 페이지를 예쁘게 고치는 것보다 장기적으로 훨씬 큰 효과를 낸다. 부품 하나를 표준으로 만들어두면 그 부품을 쓰는 모든 페이지가 한 번에 개선되기 때문이다.

이 점검을 사람이 모든 페이지에 대해 손으로 하긴 어렵다. 특히 색이 몇 종 쓰였는지, 글꼴이 몇 종 섞였는지 같은 건 눈으로 세기 거의 불가능하다. 페이지가 수십, 수백 개인 공공 사이트라면 더더욱 그렇다. 한 사람이 모든 페이지를 일일이 열어 색을 세고 버튼을 누르고 폼을 채워보는 건 현실적으로 불가능하다. 그래서 대부분의 기관은 '대충 몇 페이지만 보고' 사이트 전체를 판단하는데, 이게 위험하다. 메인 페이지는 공들여 만들어서 멀쩡한데 정작 사용자가 많이 쓰는 신청·민원 페이지는 방치돼 있는 경우가 흔하기 때문이다. 표본 몇 개로 본 '괜찮음'이 사이트 전체의 '괜찮음'은 아니다. 이럴 때 자동 분석이 진가를 발휘한다.

위 점검 항목 중 상당수는 ViewCheck이 자동으로 잡아내는 것들이다. URL을 넣으면 페이지를 열어 화면 구조를 분석하고, 색·글꼴 같은 기초(DS)부터 버튼·폼 같은 부품(CP), 그리고 흐름(BP·SP)까지 KRDS 846규칙 기준으로 통과/미준수/해당없음을 판정한다.

특히 사람 눈으로 세기 힘든 부분 — 한 사이트에서 색이 몇 종 쓰였는지, 디자인 토큰을 얼마나 채택했는지 같은 '정량 지표'를 뽑아준다. '우리 사이트 색이 좀 제각각인 것 같은데'라는 막연한 느낌이 '토큰 채택률 몇 %' 같은 숫자로 바뀐다. 숫자가 되면 개선 목표를 세우기도, 개선 전후를 비교하기도 쉬워진다.

오늘 본 다섯 가지 붕괴 패턴은 각각 KRDS의 어느 영역에 해당하는지도 분명하다. 색·글꼴·간격(패턴 1·2)은 기초(DS), 정체불명의 버튼과 라벨 없는 입력칸(패턴 3·4)은 부품(CP), 끝에서 무너지는 흐름(패턴 5)은 흐름(BP·SP)이다. 자동 분석은 이 네 영역을 각각 따로 점수 매겨주기 때문에, '우리 사이트는 기초는 괜찮은데 흐름이 약하다' 같은 진단이 한눈에 나온다. 막연히 '좀 별로다'가 아니라 '어느 층이 약한지'를 알면, 보강 작업도 정확히 그 층을 겨눌 수 있다. 오늘 글에서 패턴마다 '이건 DS, 저건 CP'라고 영역을 짚어둔 것도, 점검 결과를 읽을 때 바로 연결해 보라는 뜻이다.

오늘 다룬 붕괴 패턴들이 내 사이트에서 실제로 얼마나 나타나는지, 상단 점수 카드 한 화면에서 네 영역(DS·CP·BP·SP)별로 바로 확인할 수 있다. (아래 캡쳐는 기관 식별 정보를 가린 것이다.)

그리고 앞서 운영 점검에서 짚은 '표본 몇 개로 판단하는 위험' — 이걸 자동 분석은 여러 페이지를 한꺼번에 돌려서 해소한다. 메인만 보는 게 아니라 목록·상세·신청 같은 여러 유형의 페이지를 함께 분석해, 사이트 전체의 평균과 페이지별 편차를 같이 보여준다. '메인은 90점인데 신청 페이지는 50점' 같은 격차가 드러나면, 어디부터 손봐야 할지가 분명해진다. 사람이 표본으로 놓치기 쉬운 '방치된 안쪽 페이지'를 자동 분석은 빠짐없이 짚어준다.

그리고 자동 분석은 '개선 전후 비교'에서 특히 빛을 발한다. 오늘 진단해서 기초 통과율이 60%라고 나왔다면, 몇 달 뒤 개선 작업을 하고 다시 분석해 보면 그 숫자가 얼마나 올랐는지 바로 확인된다. 이 '전후 숫자'는 개선이 실제로 효과가 있었는지를 증명하는 객관적 기록이 되고, 다음 예산을 확보하거나 성과를 보고할 때 강력한 자료가 된다. 노력은 했는데 그게 숫자로 안 남으면 '열심히 한 것 같긴 한데'로 흐지부지되기 쉽다. 반대로 '작년 60%에서 올해 85%로 올렸다'는 한 줄은 누구도 부정할 수 없는 성과다. 자동 진단을 한 번 하고 끝내지 말고, 개선의 출발점이자 종착점으로 두 번 이상 쓰는 걸 권하는 이유가 여기 있다.

또 하나, 자동 분석의 결과는 '느낌'이 아니라 '근거'라는 점이 실무에서 크게 도움이 된다. 윗선에 개선을 건의하거나 외주 발주를 정당화할 때, '제가 보기엔 좀 어수선해서요'보다 '기초 영역 통과율 몇 %, 미준수 규칙 몇 건'이라는 숫자가 훨씬 설득력 있다. 게다가 그 숫자는 KRDS라는 공식 기준에 근거하니, 누가 봐도 객관적이다. 막연한 문제의식을 '움직일 수 있는 근거'로 바꿔주는 것 — 이게 자동 진단의 가장 실용적인 가치다. 물론 자동 분석이 모든 걸 판단하진 않는다. 시각적 완성도나 콘텐츠의 적절함 같은 건 결국 사람이 봐야 한다. 자동 분석은 '사람이 일일이 세기 힘든 것'을 대신 세어주고, 사람은 그 결과 위에서 '무엇을 먼저 고칠지'를 판단한다. 이 분업이 점검을 빠르고 정확하게 만든다.

오늘 다룬 다섯 가지 붕괴 패턴이 오늘만의 이야기가 아니라는 점도 기억해 두면 좋다. 이건 점검 현장에서 거의 매번 반복되는 '단골 패턴'이고, 그래서 한 번 알아두면 어느 사이트를 보든 같은 눈으로 진단할 수 있다. 우리 사이트, 협업 부서의 사이트, 외주가 새로 만들어온 시안 — 어디에 갖다 대도 '색은 통제되나, 부품 위계는 있나, 흐름은 끝까지 가나'를 빠르게 짚어낼 수 있다. 패턴을 아는 눈은 한 번 갖추면 계속 쓰는 자산이다. 그리고 그 눈으로 본 막연한 인상을 '숫자'로 확정해 주는 게 자동 진단이라, 둘은 함께 쓸 때 가장 강하다. 사람의 눈이 '어디가 이상한지'를 짚고, 자동 진단이 '얼마나 이상한지'를 숫자로 받쳐주는 식이다.

마무리

오늘의 핵심. 공공 사이트는 한 방에 망가지지 않는다. 가이드가 없는 상태에서 매번 새로 내리는 결정들이 디자인 부채로 쌓이고, 그 부채가 일관성·효율·유지보수를 조금씩 갉아먹는다. 그리고 붕괴는 거의 항상 기초(색·글꼴·간격)에서 시작해 부품과 흐름으로 번진다.

좋은 소식은, 이 붕괴가 '예방과 회복이 가능한' 종류라는 점이다. 디자인 시스템(KRDS)이라는 공통 기준을 도입하고, 현황을 정기적으로 점검하면 부채가 무한정 쌓이는 걸 막을 수 있다. 이미 쌓인 부채도 기초부터 차근차근 잡아가면 회복된다.

그리고 한 가지 분명한 사실이 있다. 부채는 일찍 발견할수록 싸게 갚는다. 색 규칙이 막 흔들리기 시작했을 때 잡으면 토큰 몇 개 정리로 끝나지만, 그 상태로 몇 년을 방치해 수백 페이지가 제각각이 되고 나면 같은 문제를 고치는 데 몇 배의 시간과 돈이 든다. 신청 흐름의 작은 끊김도 마찬가지다. 만들 때 잡으면 한 줄 안내를 추가하는 일이지만, 운영에 들어간 뒤 사용자 민원이 쌓이고 나서야 손대면 이미 신뢰가 깎인 뒤다. 그래서 '지금은 그럭저럭 돌아가니까 나중에'라는 미룸이 사실 가장 비싼 선택이다. 작게 보일 때, 고치기 쉬울 때 손대는 게 결국 가장 적은 비용으로 가장 큰 효과를 보는 길이다. 정기 점검이 중요한 이유가 여기 있다. 점검은 부채를 '작을 때' 발견하게 해주는 조기 경보다.

회복 과정에서 가장 흔한 실수는 '한 번에 다 바꾸려는' 것이다. 누더기가 된 사이트를 보면 전면 개편의 유혹이 크지만, 큰 개편은 비용도 크고 기간도 길고, 무엇보다 개편이 끝나는 순간부터 다시 부채가 쌓이기 시작한다. 운영 구조 없이 외형만 바꾸면 몇 년 뒤 똑같은 자리로 돌아온다. 더 현명한 길은 '기준을 먼저 세우고, 그 기준대로 조금씩 바꿔가며, 새로 만드는 건 무조건 기준을 따르게' 하는 거다. 오래된 페이지는 천천히 개선하더라도, 적어도 '앞으로 만드는 모든 것'이 기준을 지키면 부채는 더 쌓이지 않는다. 멈춤이 곧 회복의 시작이다.

한 가지 더. 오늘 '망가지는 사이트' 이야기를 길게 했지만, 이건 비관하라는 뜻이 아니다. 오히려 그 반대다. 붕괴 패턴이 '전형적'이라는 건, 해법도 전형적이라는 뜻이다. 세상에 없던 문제가 아니라 수많은 사이트가 겪고 또 해결해 온 문제이고, 그래서 KRDS라는 정리된 답이 이미 나와 있다. 우리 사이트만 유난히 엉망인 게 아니라, 대부분의 사이트가 비슷한 길을 걸었고 비슷한 방법으로 회복했다. 그러니 '우리도 늦지 않았다'는 게 오늘 글의 진짜 메시지다.

회복의 출발점은 거창한 전면 개편이 아니다. '지금 어디가 어떻게 망가졌는지 아는 것'이다. 진단이 먼저고 처방은 그다음이다. 아픈 데를 모르고 약부터 먹지 않듯, 사이트도 어디가 문제인지 확인부터 하는 게 순서다. 오늘 정리한 점검 항목과 자동 분석은 바로 그 '진단'을 위한 도구다. 진단 결과를 손에 쥐면, 그다음 무엇을 할지는 의외로 명확해진다.

오늘 글을 읽으며 '우리 사이트도 저런데' 싶은 대목이 한두 개쯤 떠올랐다면, 그것만으로도 절반은 온 거다. 문제를 '이름 붙여 인식한' 순간부터 개선이 시작되기 때문이다. 이제 막연한 '좀 별로다'가 '색이 통제 불능이구나', '흐름이 끝에서 무너지는구나' 같은 구체적인 진단으로 바뀌었다. 구체적인 진단은 구체적인 행동으로 이어진다. 다음 단계는 그 진단을 '우리 사이트의 실제 숫자'로 확인하는 거다. 추측은 사람을 망설이게 만들지만, 숫자는 사람을 움직이게 만든다.

금요일 글에서는 '우리 사이트 KRDS 적용 여부를 5분 만에 자가 점검하는 체크리스트'를 정리해 드린다. 오늘 본 붕괴 패턴들을 실제로 빠르게 확인할 수 있는 실전 도구다. 오늘 글이 '무엇이 망가지는가'였다면, 금요일은 '우리 것을 직접 확인하는 법'이다. 이어서 보면 진단의 그림이 완성된다.

덧붙여, 오늘 이야기가 다소 길고 무거웠을 수 있다. 하지만 핵심만 추리면 의외로 간단하다. '기준을 하나 정해서 모두가 공유하라', 그게 전부다. 색도, 글꼴도, 버튼도, 흐름도 — 결국은 '각자 알아서'가 아니라 '하나의 약속대로'일 때 사이트가 정돈된다. KRDS는 그 약속을 이미 정리해 둔 공식 답안이고, 우리는 그걸 가져다 쓰면 된다. 처음부터 완벽할 필요도 없다. 오늘 발견한 가장 큰 균열 하나만 골라 손대도, 사이트는 어제보다 나아진다. 그 한 걸음이 회복의 시작이다. 그리고 오늘 다섯 가지 붕괴 패턴을 '이름 붙여 알아본' 것만으로도 절반은 온 셈이다. 막연히 '우리 사이트 좀 어수선한데'였던 인식이, 이제는 '색이 제각각이구나' '버튼에 위계가 없구나' '오류 안내가 부실하구나' 같은 구체적인 진단으로 바뀌었다. 문제를 정확히 부를 수 있게 되면, 그 문제를 고치는 일도 한결 수월해진다. 다음 글의 자가 체크리스트는 바로 그 '이름 붙이기'를 우리 사이트에 직접 해보는 도구가 될 것이다.

자동 진단을 직접 해보고 싶다면 krds.viewcheck.co.kr에서 사이트 주소만 넣으면 된다. 오늘 이야기한 네 영역(DS·CP·BP·SP)의 현재 상태를 한 화면에서 확인할 수 있다. '우리 사이트는 어느 패턴에 해당될까'가 궁금하다면, 막연히 추측하지 말고 한번 돌려보는 걸 권한다. 추측을 숫자로 바꾸는 데 몇 분이면 충분하다. 오늘 본 다섯 패턴 중 우리에게 해당하는 게 무엇인지, 그리고 그게 얼마나 심한지를 숫자로 마주하는 순간, 개선은 더 이상 '언젠가 할 일'이 아니라 '지금 시작할 수 있는 일'이 된다.

그 전에, 막연한 느낌을 숫자로 바꿔보고 싶다면 ViewCheck(krds.viewcheck.co.kr)에서 진단을 받아보길 권한다. 우리 사이트에 디자인 부채가 얼마나 쌓였는지, 어디서부터 손대야 하는지가 점수로 보일 거다. 오늘 다섯 가지 붕괴 패턴을 함께 짚어봤지만, 정작 우리 사이트가 그중 몇 개에 걸려 있는지는 직접 돌려보기 전엔 알 수 없다. 느낌으로는 '괜찮은 편' 같아도 막상 진단해 보면 생각보다 많은 항목이 빨갛게 표시되는 경우가 흔하다. 반대로, 늘 불안했던 부분이 의외로 멀쩡한 경우도 있다. 어느 쪽이든, 추측을 사실로 바꾸는 일은 개선의 출발점이다.