디자인 표준화로 얻는 것 7가지

공감·문제제기

이번 주 월요일엔 "공공웹이 왜 다 제각각으로 보이느냐"는 질문을 던졌고, 수요일엔 그 뿌리에 '디자인시스템의 부재'가 있다는 이야기를 했다. 오늘은 그 흐름의 마지막 매듭이다. 제목 그대로, '디자인을 표준화하면 대체 뭐가 좋아지는가'를, 그것도 막연한 좋은 말이 아니라 담당자가 내일 당장 따라 할 수 있는 7가지 항목으로 풀어보려 한다.

솔직히 고백하면, 나도 처음 이 일을 시작했을 때는 '디자인 표준화'라는 말이 좀 공허하게 들렸다. 표준화? 좋은 말이지. 그런데 그게 우리 기관 사이트에서 실제로 뭘 바꾸는데? 색깔 좀 맞추고 글꼴 통일하면 그게 그렇게 대단한 일인가? 이런 의심이 오래 있었다. 그러다 여러 공공 사이트를 안에서 들여다보고, 담당자들과 이야기를 나누고, 같은 문제가 기관을 가리지 않고 똑같이 반복되는 걸 수십 번 목격하고 나서야 생각이 바뀌었다. 디자인 표준화는 '예쁘게 만드는 일'이 아니다. 그건 '일하는 방식을 바꾸는 일'이고, '새는 비용을 막는 일'이고, 결국 '사용자에게 한 약속을 지키는 일'이다.

그래서 오늘 글은 '표준화하면 예뻐져요' 같은 뻔한 말은 최대한 안 하려고 한다. 대신 표준화가 실무에 가져다주는 구체적인 이득 7가지를 하나씩 짚고, 각 이득을 '우리 사이트는 지금 어디쯤인가' 자가 점검할 수 있는 체크 항목과, '그래서 무엇부터 손대야 하는가' 하는 단계별 실행법을 함께 붙였다. 읽기만 하는 글이 아니라, 노트를 옆에 펴두고 '예/아니오'를 적어가며 따라오는 글이 됐으면 한다.

먼저 한 가지 분명히 해두자. 여기서 말하는 '디자인 표준화'의 가장 구체적인 형태가 바로 행정안전부의 KRDS다. KRDS는 정부 디자인시스템으로, 색·글꼴·간격 같은 기초부터 버튼·입력칸·메뉴 같은 부품, 신청·검색 같은 흐름까지 공공웹이 지켜야 할 규칙을 정리해 둔 묶음이다. 우리가 ViewCheck에서 다루는 846개 규칙이 바로 이걸 잘게 쪼갠 것인데, 크게 보면 기초(DS) 120개, 부품(CP) 446개, 흐름의 두 갈래(BP) 108개와 (SP) 172개로 나뉜다. 오늘 이야기하는 7가지 이득은 전부 이 846개 규칙을 '얼마나 지키느냐'와 직결돼 있다. 다시 말해, 오늘 글은 'KRDS를 지키면 구체적으로 뭐가 좋아지는가'를 7가지 각도에서 보는 셈이다.

왜 '디자인 담당자도 아닌 내가' 이런 걸 알아야 하나 싶을 수 있다. 하지만 공공 사이트의 품질은 디자이너 한 사람의 일이 아니다. 콘텐츠를 올리는 담당자, 신청 양식을 기획하는 담당자, 외주를 관리하는 담당자, 예산을 잡는 담당자 — 사이트에 손을 대는 모든 사람이 조금씩 그 품질을 만든다. 그래서 '표준화가 주는 이득'을 모두가 조금씩이라도 알고 있는 게 중요하다. 그래야 '왜 우리가 시간과 예산을 들여 표준을 지켜야 하는지' 같은 부서, 같은 회의에서 한 방향을 볼 수 있다.

한 가지 미리 당부하자면, 점검할 때는 '만든 사람'의 마음이 아니라 '쓰는 사람'의 마음으로 봐야 한다. 우리는 우리 사이트를 너무 잘 안다. 어느 메뉴가 어디 있는지, 신청 버튼이 어느 구석에 숨어 있는지 다 외우고 있다. 그래서 '이 정도면 알아보겠지' 하고 넘기기 쉽다. 하지만 처음 방문한 사용자는 아무것도 모른다. 그 사람의 눈으로 봐야 진짜 문제가 보인다. 가능하면 사이트를 잘 모르는 동료나 가족에게 '이 페이지에서 OO 신청을 해보라'고 부탁하고 옆에서 지켜보는 것도 좋은 방법이다. 그 사람이 어디서 멈칫하고, 어디서 '이거 어떻게 하는 거예요?'라고 묻는지가 곧 우리 사이트의 약점이다. 매일 그 화면을 들여다보는 담당자보다, 가끔 들어오는 일반 사용자의 눈이 더 정확할 때가 많다.

그리고 이 점검이 '비용이 안 드는 일'이라는 것도 매력이다. 외부 컨설팅을 부르거나 도구를 사기 전에, 지금 당장 시작할 수 있다. 돈도 안 들고, 결재도 필요 없고, 누구의 허락도 필요 없다. 그저 우리 사이트를 사용자의 눈으로 한 바퀴 돌아보는 것뿐이다. 거창한 개편 계획을 세우기 전에, 먼저 '지금 어떤 상태인지' 아는 것 — 모든 개선은 거기서 출발한다.

준비물은 간단하다. 우리 기관 사이트, 스마트폰 하나, 그리고 '예/아니오'를 적을 메모장. 데스크탑과 모바일을 둘 다 봐야 하니 둘 다 켜두면 좋다. 마음가짐은 하나만 챙기자. 이건 시험이 아니라 건강검진이다. '아니오'가 많이 나올수록 점검이 잘된 거다. 문제를 많이 찾았다는 건 고칠 거리를 많이 확보했다는 뜻이고, 그건 곧 사이트가 좋아질 여지가 그만큼 크다는 뜻이니까. 자, 그럼 표준화가 주는 7가지 이득을 하나씩 들여다보자.

본론

■ 이득 1 — 신뢰감: 첫인상 0.1초에서 점수가 갈린다

표준화가 주는 첫 번째 이득은 '신뢰감'이다. 너무 추상적인가? 그렇지 않다. 신뢰감은 의외로 아주 구체적인 것들에서 나온다. 색이 일관되고, 글꼴이 통일돼 있고, 여백이 가지런한 화면. 사용자는 이걸 의식적으로 분석하지 않는다. 그냥 사이트에 들어선 0.1초 만에 '여기 정돈됐네' 혹은 '여기 어수선하네' 하는 인상을 받는다. 그리고 그 인상이 '이 기관이 일을 꼼꼼히 하는가'에 대한 무의식적 판단으로 곧장 이어진다.

생각해보면 당연하다. 우리도 처음 가는 식당의 메뉴판이 들쭉날쭉한 글꼴로 인쇄돼 있고, 가격표가 손으로 덧칠돼 있으면 '여기 괜찮나' 싶어진다. 음식 맛과는 아무 상관 없는데도 말이다. 공공 사이트도 똑같다. 내용이 아무리 정확하고 정성스러워도, 화면이 제각각이면 '이 정보를 믿어도 되나' 하는 미묘한 불안이 깔린다. 표준화는 바로 이 '근거 없는 불안'을 걷어낸다. 색 하나, 글꼴 하나가 통일돼 있다는 사실만으로 '이 기관은 세부에 신경 쓴다'는 메시지가 전달된다.

한 광역지자체 산하 B공공기관의 사이트를 들여다본 적이 있다. 메인 페이지는 꽤 잘 만들어져 있었다. 그런데 두세 단계 들어가 부서별 안내 페이지로 가면, 페이지마다 파란색의 채도가 미묘하게 다르고, 어떤 페이지는 제목이 굵은 고딕인데 옆 페이지는 가는 명조였다. 한 사이트 안에서 '여기는 다른 데 들어온 것 같은데' 하는 느낌이 계속 들었다. 부서마다 따로 만들고, 외주가 바뀔 때마다 다른 기준으로 작업한 흔적이었다. 콘텐츠는 멀쩡한데 '조각보 같은' 인상 때문에 전체 신뢰도가 새고 있었다.

▷ 자가 점검 — 메인에서 출발해 부서 페이지, 신청 페이지, 안내 페이지를 차례로 열어 죽 스크롤해 보라. 색조와 분위기가 '같은 사이트 안에 있다'는 느낌으로 이어지면 ○, 페이지마다 '여기 좀 다른데' 싶으면 ✕다. 글꼴도 한 화면 안에서 제목·본문·표·버튼의 글자 모양이 제각각이면 ✕.

▷ 단계별 실행 — (1) 메인·목록·상세·신청 페이지를 '동시에 띄워 비교'한다. 한 페이지씩 보면 잘 안 보이던 차이가 나란히 놓으면 도드라진다. (2) '아니오'가 나왔다면 당장 모든 페이지를 다 고치려 들지 말고, '앞으로 만드는 것부터 같은 기준을 지키게' 한다. (3) 기존 페이지는 방문자가 가장 많이 보는 것부터 천천히 정리한다. 기초는 한 번에 다 잡는 게 아니라 기준을 세워두고 점진적으로 수렴시키는 영역이다.

신뢰감이라는 이득이 좋은 점은, 비용 대비 효과가 가장 크다는 거다. 기능을 새로 만드는 것도 아니고, 그저 '이미 있는 색과 글꼴을 통일'하는 것만으로 사이트 전체의 인상이 올라간다. 표준화의 7가지 이득 중에서 가장 적은 노력으로 가장 빨리 체감되는 게 바로 이 첫 번째다.

■ 이득 2 — 학습 비용 절감: 한 번 익히면 어디서나 통한다

두 번째 이득은 사용자의 '학습 비용'을 줄여준다는 점이다. 표준화된 사이트에서는 버튼이 어디에 있는지, 메뉴가 어떻게 펼쳐지는지, 신청이 몇 단계로 진행되는지가 페이지마다 '같은 방식'으로 동작한다. 그래서 사용자는 한 페이지에서 익힌 사용법을 다른 페이지에서도 그대로 쓸 수 있다. 반대로 표준이 없으면, 페이지를 옮길 때마다 사용법을 새로 배워야 한다. 마치 매장마다 출입문 여는 방식이 다른 건물에 들어선 기분이다.

이게 왜 중요하냐면, 공공 사이트의 사용자는 '전문가'가 아니기 때문이다. 민간 서비스는 매일 쓰는 사용자가 많아 '익숙함'으로 불편을 메운다. 하지만 공공 사이트는 1년에 한두 번, 필요할 때만 들어오는 사람이 대부분이다. 그들에게는 '저번에 어떻게 했더라' 하는 기억이 없다. 매번 처음 온 사람처럼 헤맨다. 그래서 '직관적으로, 배우지 않고도 쓸 수 있는' 일관성이 민간보다 훨씬 더 절실하다. 게다가 공공 서비스는 '안 쓰면 그만'인 게 아니라 '꼭 해야 하는 일'인 경우가 많다. 민원 신청, 증명서 발급, 보조금 접수 — 불편하다고 안 쓸 수 없는 일이라, 학습 비용이 높으면 그 부담을 사용자가 고스란히 떠안는다.

특히 부품(CP)의 일관성이 학습 비용을 좌우한다. KRDS 846규칙 중 부품이 446개로 가장 많은 건 우연이 아니다. 버튼·입력칸·메뉴·표·알림창처럼 사용자가 '직접 손으로 만지는' 접점이기 때문이다. 이 손잡이들이 페이지마다 다른 모양, 다른 자리에 있으면 사용자는 매번 '이번엔 어디 있지'부터 찾아야 한다. 통일돼 있으면 눈이 자동으로 그 자리로 간다.

▷ 자가 점검 — 같은 동작을 하는 버튼인데 페이지마다 다른 글자('신청' '접수' '제출하기')를 쓰고 있지 않은가? 메뉴가 펼쳐지는 방식, 검색창의 위치가 페이지마다 제각각이지 않은가? 한 페이지에서 익힌 사용법이 다른 페이지에서 그대로 통하면 ○, '여긴 또 다르네' 싶으면 ✕.

▷ 단계별 실행 — (1) 가장 자주 쓰이는 부품부터 목록을 만든다. 주 버튼, 보조 버튼, 입력칸, 검색창, 페이지 이동 정도면 충분하다. (2) 각 부품의 '표준 모양과 표준 위치, 표준 명칭'을 하나로 정한다. '제출하기'로 통일했으면 모든 페이지가 '제출하기'를 쓴다. (3) 새 페이지부터 이 표준을 적용하고, 기존 페이지는 손볼 때마다 함께 맞춘다.

학습 비용이 줄면 콜센터 문의도 줄어든다. '이거 어디서 신청해요' '버튼이 안 보여요' 같은 전화의 상당수가 사실은 '일관성 부족'에서 나온다. 표준화는 사용자만 편하게 하는 게 아니라, 그 문의를 받던 직원의 일도 줄여준다. 사용자 편의가 곧 기관의 업무 경감으로 돌아오는 셈이다.

■ 이득 3 — 접근성: '모두가 쓸 수 있는가'의 기본기

세 번째 이득은 접근성이다. 사실 이건 '이득'이라기보다 '의무'에 가깝다. 공공 사이트는 누구도 배제하지 않아야 한다. 눈이 잘 안 보이는 사람, 손이 불편해 마우스 대신 키보드를 쓰는 사람, 화면을 소리로 읽어주는 보조기기를 쓰는 사람 — 이들 모두가 같은 서비스를 받을 수 있어야 한다. 그런데 흥미로운 건, 디자인을 표준화하면 접근성이 '저절로' 상당 부분 따라온다는 점이다.

왜 그럴까. KRDS 같은 표준은 처음부터 접근성을 염두에 두고 만들어졌기 때문이다. 색 대비 기준, 초점 표시(키보드로 이동할 때 지금 어디 있는지 보여주는 테두리), 입력칸 바깥의 라벨, 이미지의 대체텍스트 — 이런 게 표준 안에 이미 녹아 있다. 표준을 따르기만 하면 별도로 '접근성 작업'을 따로 하지 않아도 기본은 챙겨진다. 반대로 표준 없이 '예쁘게만' 만들면, 화면상으론 멀쩡해 보여도 키보드로는 작동하지 않거나, 보조기기로는 읽히지 않는 '보이기만 하는' 사이트가 되기 쉽다.

우리나라에는 KWCAG라는 웹접근성 지침이 있고, 핵심 점검 항목이 33개다. 이 33항목은 표준화와 깊이 맞물려 있다. 이를테면 '대체텍스트' 항목은 표준이 '이미지에는 alt를 넣는다'는 규칙을 강제하면 자연히 지켜진다. '초점 이동' 항목은 표준 버튼·링크를 쓰면 기본으로 초점 테두리가 따라온다. 표준화와 접근성은 따로 노는 두 일이 아니라, 한 일의 양면이다.

▷ 자가 점검 — 마우스를 손에서 떼고 키보드 Tab 키만으로 페이지를 처음부터 끝까지 돌아다녀 보라. Tab을 누를 때마다 초점이 어디로 가는지 눈에 보이는가? 그 순서가 위에서 아래로, 왼쪽에서 오른쪽으로 자연스러운가? 버튼이 엔터로 눌리는가? 의미 있는 이미지에 대체텍스트가 들어 있는가('이미지' '사진' 같은 무의미한 값 말고)? 입력칸마다 바깥에 라벨이 붙어 있는가(칸 안 흐린 글씨 말고)?

▷ 단계별 실행 — (1) '키보드만으로 핵심 흐름 하나 완주하기'를 해본다. 가장 많이 쓰이는 신청이나 검색을 마우스 없이 끝까지 가본다. 중간에 막히는 지점이 곧 고칠 곳이다. (2) 의미 있는 이미지의 대체텍스트를 '무엇을 전달하는 이미지인지'로 채운다. 장식용 이미지는 비워두는 게 맞다. (3) 입력칸의 안내문이 '칸 안 흐린 글씨'로만 돼 있다면, 입력을 시작해도 사라지지 않는 '바깥 라벨'을 추가한다.

접근성을 '별도의 부담'으로 여기는 담당자가 많은데, 표준화의 관점에서 보면 그렇지 않다. 표준을 지키는 과정에서 접근성의 7~8할은 함께 해결된다. 나머지 2~3할만 별도로 챙기면 된다. 그러니 '접근성 작업을 따로 또 해야 하나' 부담 갖지 말고, '표준화하면 접근성도 같이 좋아진다'고 생각하는 게 맞다.

■ 이득 4 — 유지보수 비용: 한 곳만 고치면 전체가 바뀐다

네 번째 이득은 아주 현실적이다. 바로 '돈' 이야기, 유지보수 비용이다. 표준화되지 않은 사이트는 색 하나를 바꾸려 해도 페이지마다 일일이 찾아 고쳐야 한다. '브랜드 파랑을 살짝 진하게 바꾸자'는 간단한 결정 하나가, 수백 페이지에 흩어진 파란색을 하나하나 손보는 대공사가 된다. 어디 한 군데 빠뜨리면 또 '조각보'가 된다.

표준화된 사이트는 다르다. 색·글꼴·간격이 '토큰'이라는 한 곳에 정의돼 있고, 모든 페이지가 그 토큰을 '참조'해서 쓴다. 그래서 토큰 한 곳만 바꾸면 그걸 참조하는 모든 페이지가 한꺼번에 바뀐다. 빠뜨릴 곳도 없고, 며칠 걸릴 일이 몇 분으로 끝난다. 이게 디자인 토큰의 핵심 가치다. '기준을 화면 밖으로 꺼내, 모두가 같은 걸 보고 쓰게 하는 것' 말이다.

기초가 흐트러지는 근본 원인은 거의 항상 같다. '기준이 머릿속에만 있고, 화면 어디에도 적혀 있지 않다'는 것이다. 페이지를 만들 때마다 담당자나 외주가 '대충 비슷한 파랑'을 눈대중으로 골라 코드에 직접 박는다. 그런데 머릿속의 파랑은 사람마다 다르고, 같은 사람도 모니터가 바뀌면 다르게 본다. 이렇게 '각자의 기억'으로 만든 결과물이 모이면, 개별로는 그럴듯한데 전체로는 제각각인 사이트가 된다. 유지보수가 지옥이 되는 이유도 여기 있다. 기준이 흩어져 있으니, 바꾸려면 흩어진 모든 곳을 다 찾아다녀야 한다.

한 중앙부처 산하기관에서 사이트 색상 톤을 바꾸기로 했는데, 표준 없이 만들어진 탓에 외주 업체가 '전수 조사'부터 해야 했다는 이야기를 들은 적이 있다. 어디에 어떤 파랑이 박혀 있는지 목록을 만드는 데만 며칠이 걸렸고, 그걸 고치는 데 또 며칠, 빠뜨린 곳을 잡는 데 또 며칠이었다. 토큰으로 정리돼 있었다면 반나절이면 끝났을 일이다. 표준화는 '지금 당장의 편의'가 아니라 '앞으로 들어갈 모든 유지보수 비용'을 줄여주는 장기 투자다.

▷ 자가 점검 — '우리 사이트 색을 한 톤 바꾸려면 얼마나 걸릴까'를 상상해보라. '토큰 한 곳 바꾸면 됩니다'라고 자신 있게 말할 수 있으면 ○, '페이지마다 다 찾아 고쳐야 해서...' 하고 한숨이 나오면 ✕. 외주 업체에 물어봐도 좋다. '색 하나 바꾸는 데 견적이 얼마냐'는 질문의 답이 표준화 수준을 그대로 보여준다.

▷ 단계별 실행 — (1) 색·글꼴·간격의 '표준 값'을 문서로 정리한다. 브랜드 파랑은 정확히 어떤 값인지, 제목 글꼴은 무엇인지, 기본 간격 단위는 얼마인지를 한 장에 적는다. (2) 새로 만드는 페이지는 반드시 이 표준 값을 참조하게 한다. 눈대중으로 색을 고르는 관행을 끊는다. (3) 외주 계약서에 '디자인 토큰을 참조해 구현한다'는 조건을 명시한다. 이게 빠지면 또 '각자의 파랑'이 들어온다.

유지보수 비용 절감은 당장 눈에 안 보여서 과소평가되기 쉽다. 하지만 사이트는 5년, 10년 운영된다. 그 긴 시간 동안 수없이 손볼 일이 생기는데, 그때마다 들어가는 비용의 차이는 어마어마하다. 표준화는 '오늘 조금 수고해서 앞으로 수십 번 수고를 더는 일'이다.

■ 이득 5 — 협업 속도: 외주가 바뀌어도 흔들리지 않는다

다섯 번째 이득은 '협업'이다. 공공 사이트는 보통 한 사람이 만들지 않는다. 여러 담당자, 여러 외주 업체, 여러 부서가 시기를 달리해 손을 댄다. 그리고 외주 업체는 계약 단위로 바뀐다. 작년에 만든 업체와 올해 만든 업체가 다르고, 그 둘이 서로 어떻게 만들었는지 모른다. 표준이 없으면, 새 업체가 들어올 때마다 '이 기관은 어떻게 만들어왔지'를 처음부터 파악해야 하고, 결국 자기 방식대로 새로 만든다. 그래서 손댈 때마다 사이트가 '또 다른 조각'이 된다.

표준이 있으면 이야기가 완전히 달라진다. 새 업체에게 '이 표준을 따르세요'라고 KRDS 기준 하나만 건네면 된다. 업체는 그 기준을 보고 작업하고, 결과물은 기존 페이지와 자연스럽게 어우러진다. 누가 만들었는지 티가 안 난다. 이게 표준의 힘이다. '사람'에 의존하던 품질을 '기준'에 의존하게 바꿔, 사람이 바뀌어도 품질이 유지된다.

내부 협업도 마찬가지다. 기획자가 '여기에 주 버튼을 놓자'고 하면, 디자이너와 개발자가 '주 버튼이 뭔데?'라고 되묻지 않는다. 표준에 '주 버튼은 이렇게 생겼고 여기 쓴다'가 정의돼 있으니, 같은 단어로 같은 걸 가리킨다. 표준은 일종의 '공통 언어'다. 공통 언어가 있으면 회의가 짧아지고, 오해가 줄고, 다시 만드는 일이 사라진다.

▷ 자가 점검 — 새 외주 업체에게 '우리 사이트 표준 문서를 드릴 테니 이걸 따라주세요'라고 건넬 수 있는가? 그런 문서가 있으면 ○, '음... 기존 페이지 보면서 비슷하게 만들어주세요'라고밖에 말할 수 없으면 ✕. 후자라면 매 계약마다 품질이 새 업체의 역량에 좌우된다는 뜻이다.

▷ 단계별 실행 — (1) '우리 기관 디자인 기준' 문서를 만든다. 거창할 필요 없다. KRDS를 기반으로 '우리는 이 부분을 이렇게 적용한다'를 정리하는 것으로 시작한다. (2) 모든 외주 계약에 이 문서를 첨부하고 '준수'를 명시한다. (3) 납품 검수 단계에 '표준 준수 여부' 항목을 넣는다. 검수 기준이 있어야 업체도 지킨다.

협업 속도의 이득은 '조직의 기억'을 만든다는 데 있다. 담당자는 바뀌고 외주는 교체되지만, 표준 문서는 남는다. 그 문서가 '우리 사이트는 이렇게 만든다'는 기관의 기억이 되어, 사람이 떠나도 품질이 떠나지 않게 잡아준다.

■ 이득 6 — 흐름 완성도: 사용자가 '목적을 이루게' 한다

여섯 번째 이득은 '흐름(BP·SP)'의 완성도다. 흐름이란 신청·예약·검색·로그인처럼 여러 단계로 이어지는 사용자의 여정이다. 표준화는 이 흐름에도 일관된 규칙을 부여한다. 신청은 항상 '지금 몇 단계 중 어디인지'를 보여주고, 폼을 잘못 채우면 항상 '어느 칸이, 왜 틀렸고, 어떻게 고치라'를 그 칸 옆에서 알려주고, 검색 결과가 0건이면 항상 '다음에 뭘 하라'를 안내하는 식이다.

흐름은 사용자가 '목적을 이루느냐 마느냐'를 가르는 영역이라, 여기서의 '아니오'는 곧 서비스 실패로 이어진다. 더 뼈아픈 건, 흐름의 결함이 사용자가 '많은 걸 투자한 뒤에' 드러난다는 점이다. 정보를 찾고, 자격을 확인하고, 여러 칸을 채우고, 첨부파일까지 올린 사용자가 마지막 제출 단계에서 정체불명의 오류를 만나면, 그동안의 노력이 한순간에 무너진다. 그리고 이렇게 끝에서 이탈한 사용자는 재방문을 잘 안 한다. '이 사이트는 신청이 안 되는 곳'이라는 인상이 한 번 박히면, 다음엔 '또 그 고생을 하느니 직접 방문하자'가 된다. 온라인으로 끝날 일이 창구 방문으로 돌아오고, 결국 기관의 행정 부담으로 되돌아온다.

표준화된 흐름은 이 '마지막 좌절'을 막는다. 진행 표시가 '끝이 보이는 길'을 만들어주고, 인라인 오류 안내가 '어디서 틀렸는지' 즉시 알려주고, 상태 유지가 '뒤로 가도 입력이 안 날아가게' 지켜준다. 이 세 가지는 화려한 기능이 아니라 '기본 예의'에 가깝다. 사용자에게 '지금 무엇을 하고 있고, 무엇이 남았고, 무엇을 잘못했는지'를 정직하게 알려주는 것 — 그게 끝까지 완주하게 돕는 안전장치다.

▷ 자가 점검 — 흐름 점검엔 '일부러 틀려보기'가 가장 효과적이다. 필수 칸을 비워두고 제출 버튼을 눌러보고, 형식에 안 맞는 값(전화번호 칸에 한글)을 넣어보고, 신청 중간에 뒤로 가기를 눌러본다. 친절한 사이트는 '무엇이 왜 틀렸고 어떻게 고치라'를 그 칸 바로 옆에서 알려주고, 뒤로 가도 적던 내용을 지켜준다. 불친절한 사이트는 '오류가 발생했습니다' 한 줄만 띄우거나, 처음부터 다시 적게 만든다.

▷ 단계별 실행 — (1) '우리 사이트에서 사람들이 가장 많이 하는 일' 한두 개를 고른다. 모든 흐름을 다 볼 시간은 없으니 대표 흐름에 집중한다. (2) 그 흐름을 '진짜 사용자처럼' 처음부터 끝까지 밟아보며, 진행 표시·인라인 오류·상태 유지 세 가지를 확인한다. (3) 막히는 지점이 곧 '가장 먼저 고쳐야 할 곳'이다. 가장 많이 쓰는 흐름 하나가 매끄러우면 사용자 대다수가 만족하고, 그 하나가 막히면 가장 많은 사람이 좌절한다.

흐름 점검은 '넓게 조금씩'보다 '핵심을 깊게'가 원칙이다. 그리고 C 영역만큼은 반드시 '우리 흐름을 한 번도 안 써본 사람'에게 부탁해 옆에서 지켜보는 게 가장 정확하다. 만든 사람은 그 흐름을 수십 번 따라가 봤으니 막힘없이 통과하지만, 처음 온 사용자는 우리가 당연하게 여긴 모든 단계에서 멈칫하기 때문이다.

■ 이득 7 — 측정 가능성: '감'이 아니라 '숫자'로 관리한다

마지막 일곱 번째 이득은 어쩌면 가장 중요하다. 표준화는 사이트 품질을 '측정 가능'하게 만든다. 표준이 없으면 품질은 '느낌'의 영역에 머문다. '좀 별로인 것 같아요' '예전보다 나아진 것 같은데요' 같은 막연한 말로는 누구도 움직이지 않고, 개선의 효과도 증명할 수 없다. 표준이 있으면 '846개 규칙 중 몇 개를 지키고 몇 개를 어겼는가'를 셀 수 있다. 셀 수 있으면 관리할 수 있고, 관리할 수 있으면 좋아진다.

이게 ViewCheck가 하는 일이기도 하다. 사람이 846개 규칙을 일일이 손으로 따지는 건 불가능하다. 그래서 우리는 URL만 입력하면 그 사이트가 846개 규칙 — 기초(DS) 120개, 부품(CP) 446개, 흐름(BP) 108개와 (SP) 172개 — 을 각각 얼마나 지키는지를 자동으로 진단해 점수로 보여준다. 행정안전부의 「전자정부 웹사이트 품질관리 지침」이 정한 7대 영역(호환성·접근성·개방성·접속성·편의성·효율성·신뢰성)과 웹접근성 KWCAG 33항목까지 함께 본다. '감'으로 '좀 별로'라고 말하던 걸, '이 영역이 몇 점이고 어떤 규칙을 어겼다'는 구체적인 안건으로 바꿔준다.

측정의 진짜 가치는 '대화의 출발점'이 생긴다는 데 있다. 사이트 개선은 혼자 하는 일이 아니다. 담당 부서, 윗선, 외주 업체가 함께 움직여야 한다. 그런데 '우리 사이트 좀 별로인 것 같아요'라는 막연한 말로는 누구도 움직이지 않는다. 반면 '진단해보니 부품 영역에서 점수가 낮고, 특히 초점 표시 관련 규칙을 다수 어기고 있습니다'라고 하면, 이야기가 구체적인 안건이 된다. 손에 쥔 진단 결과 하나가, 미뤄지던 개선 논의를 시작하게 만드는 방아쇠가 된다.

▷ 자가 점검 — 우리 사이트의 품질을 '숫자'로 말할 수 있는가? '지난 분기 대비 이 영역이 몇 점 올랐다'를 보여줄 수 있으면 ○, '그냥 느낌상...'이면 ✕. 측정 기준이 없으면 개선의 방향도, 개선의 증거도 만들 수 없다.

▷ 단계별 실행 — (1) '기준점'을 한 번 찍는다. 지금 우리 사이트가 몇 점인지를 측정해 기록해둔다. 이게 모든 개선의 출발선이다. (2) 점수가 낮은 영역부터 우선순위를 정한다. 한꺼번에 다 고치려 하지 말고, 가장 많이 어긴 규칙군부터 손댄다. (3) 분기마다 다시 측정해 추세를 본다. 사이트는 살아 있는 생물 같아서, 콘텐츠가 늘면서 계속 변한다. 오늘 '예'였던 항목이 반년 뒤 '아니오'가 될 수 있으니, 정기 측정이 곧 품질 관리다.

측정 가능성이 7가지 이득의 마지막에 온 데는 이유가 있다. 앞의 여섯 가지 이득(신뢰감·학습비용·접근성·유지보수·협업·흐름)이 '좋아진 것'이라면, 측정은 '좋아졌음을 증명하고 계속 좋아지게 만드는 것'이다. 측정이 없으면 나머지 여섯도 '했는지 안 했는지' 모르는 채 흐지부지된다. 표준화의 효과를 조직 안에서 인정받고, 다음 예산을 따내고, 개선을 멈추지 않게 만드는 동력이 바로 이 '숫자'다.

■ 7가지를 한 장으로 — 자가 점검 종합표

여기까지 읽었다면, 이제 우리 사이트가 7가지 이득 중 어디서 강하고 어디서 약한지 대략 감이 올 거다. 마지막으로 한 장에 모아 '예/아니오'를 적어보자. 의심스러운 항목은 망설이지 말고 '아니오'로 적는 걸 권한다. 점검의 목적은 좋은 점수가 아니라 '고칠 곳을 찾는 것'이니까.

· 이득1 신뢰감 — 메인부터 하위까지 색·글꼴·여백이 일관적인가?

· 이득2 학습비용 — 한 페이지에서 익힌 사용법이 다른 페이지에서도 통하는가?

· 이득3 접근성 — 마우스 없이 키보드만으로 핵심 흐름을 완주할 수 있는가?

· 이득4 유지보수 — 색 하나 바꾸는 데 '토큰 한 곳'만 고치면 되는가?

· 이득5 협업 — 새 외주에게 건넬 '표준 문서'가 있는가?

· 이득6 흐름 — 일부러 틀렸을 때 그 칸 옆에서 친절히 안내하는가?

· 이득7 측정 — 우리 품질을 '숫자'로 말할 수 있는가?

'아니오'가 셋 이상이면, 표준화로 얻을 게 아주 많은 사이트라는 뜻이다. 낙담할 일이 아니다. 오히려 '개선 여지가 그만큼 크다'는 좋은 신호다. '예'가 다섯 이상이면 이미 기초 체력이 탄탄한 편이니, 나머지 약한 영역만 보강하면 된다. 어느 쪽이든, 이 한 장이 '우리 사이트를 처음으로 객관적으로 본' 첫 기록이 된다.

한 가지 더 당부하자면, 이 점검은 '한 번 하고 끝'이 아니라 '정기적으로 반복'할 때 진가가 드러난다. 분기에 한 번쯤 같은 표로 다시 점검하면, 사이트가 좋아지고 있는지 나빠지고 있는지 추세가 보인다. 오늘의 점검은 그 첫 번째 기준점을 찍는 일이다. 그리고 '아니오' 옆에는 꼭 한 줄짜리 메모를 남기자. '이득6 아니오 — 신청 폼 오류가 맨 위에 한 줄로만 뜸'처럼. 이 한 줄이 나중에 '무엇을 고쳐야 하는지'를 정확히 짚어주는 작업 지시서가 된다. 점검의 가치는 '발견'이 아니라 '기록'에서 완성된다.

■ '다 못 한다' 싶을 때 — 우선순위 정하는 법

7가지를 다 보고 나면 '고칠 게 너무 많은데 뭘 먼저 하지' 하는 막막함이 올 수 있다. 자연스러운 반응이다. 여기서 길을 잃지 않으려면 우선순위 원칙 두 개만 기억하면 된다.

첫째, '아래층부터' 본다. KRDS는 사이트를 층으로 본다. 가장 아래에 색·글꼴·간격의 기초(DS)가 있고, 그 위에 버튼·입력칸의 부품(CP)이 올라가고, 다시 그 위에 신청·검색의 흐름(BP·SP)이 얹힌다. 기초가 흔들리면 그 위도 함께 흔들린다. 그래서 버튼이 잘 안 보이는 문제(부품)가 사실은 색 대비 기준이 없는 기초의 문제에서 비롯된 경우가 많다. 아래층부터 보면 '진짜 원인'과 '그 원인이 만든 증상'을 구분할 수 있어, 증상만 쫓다 같은 문제가 또 터지는 일을 막는다.

둘째, '가장 많이 쓰는 것부터' 본다. 사이트엔 페이지가 수백 개지만, 사용자가 실제로 많이 거치는 흐름은 몇 개로 정해져 있다. 그 핵심 흐름이 막히면 피해는 사용자 한두 명이 아니라 대다수에게 미친다. 그러니 '방문이 많은 페이지, 자주 쓰는 흐름'부터 손대는 게 같은 노력으로 가장 많은 사용자를 돕는 길이다. 잘 안 쓰는 구석 페이지의 완벽함보다, 모두가 거치는 메인 흐름의 매끄러움이 훨씬 값지다.

이 두 원칙을 합치면 '많이 쓰는 흐름의, 아래층 기초부터'가 된다. 거기서 시작해 한 겹씩 위로 올라가며 정리하면, 한정된 시간과 예산으로 가장 큰 효과를 낸다. 표준화는 한 번에 완성하는 게 아니라 '우선순위를 정해 한 겹씩 쌓아가는' 과정이라는 걸 잊지 말자.

■ 흔한 오해 다섯 가지 — '표준화는 ○○다'의 함정

표준화를 권할 때마다 거의 똑같은 반론을 듣는다. 그 반론들은 대부분 '오해'에서 나온다. 오해를 풀어두지 않으면 아무리 이득을 설명해도 '우리한텐 안 맞아요'로 끝나버린다. 그래서 가장 자주 듣는 다섯 가지 오해를 하나씩 짚어보려 한다.

첫 번째 오해, '표준화하면 우리 기관만의 개성이 사라진다.' 이건 표준을 '획일화'로 오해한 데서 온다. 표준은 '색·글꼴·간격을 어떤 방식으로 다룰지'의 규칙이지, '모든 기관이 똑같은 색을 써라'가 아니다. 오히려 표준 위에서야 개성이 또렷해진다. 기초가 흔들리는 사이트는 '개성 있는' 게 아니라 그냥 '정돈이 안 된' 거다. 잘 정돈된 토대 위에 우리 기관의 정체성 색과 톤을 일관되게 입힐 때, 비로소 '이 기관답다'는 개성이 산다. 명함 한 장도 글꼴이 들쭉날쭉하면 개성이 아니라 '급조한 느낌'이 나는 것과 같은 이치다.

두 번째 오해, '표준화는 큰 개편 프로젝트라 예산이 많이 든다.' 큰돈을 들여 사이트를 통째로 갈아엎어야 한다는 생각이다. 하지만 표준화는 '대공사'로 시작할 필요가 없다. 오늘 글에서 본 것처럼, 색·글꼴 기준 한 장을 정리하고, 새로 만드는 페이지부터 그 기준을 지키게 하는 것만으로 시작된다. 기존 페이지는 손볼 일이 생길 때마다 하나씩 맞춰가면 된다. 표준화는 '한 번에 끝내는 사업'이 아니라 '일하는 습관을 바꾸는 일'이라, 큰 예산 없이도 오늘 당장 시작할 수 있다.

세 번째 오해, '표준화는 디자이너나 개발자가 할 일이지 나랑은 상관없다.' 앞에서도 말했지만, 사이트 품질은 사이트에 손대는 모든 사람이 함께 만든다. 콘텐츠를 올리는 담당자가 표준 글꼴을 무시하고 외부에서 복사한 텍스트를 그대로 붙이면, 그 페이지만 어수선해진다. 신청 양식을 기획하는 담당자가 '이번엔 단계를 좀 줄여보자'고 결정하면, 그게 곧 흐름의 품질을 바꾼다. 표준화는 특정 직군의 일이 아니라 '조직 전체의 약속'이다. 그래서 비전문가도 '무엇이 좋은 사이트인가'의 감각을 조금씩 갖추는 게 중요하다.

네 번째 오해, '우리 사이트는 작아서 표준화까지 필요 없다.' 규모가 작으면 '각자 알아서' 만들어도 문제가 안 보이는 것 같다. 하지만 작은 사이트일수록 담당자가 적어, 한 사람이 떠나면 '어떻게 만들었는지'의 기억도 함께 떠난다. 표준 문서가 없으면, 다음 담당자는 백지에서 시작해 또 자기 방식대로 만든다. 그렇게 사람이 바뀔 때마다 사이트가 한 조각씩 어긋난다. 작은 조직일수록 '사람에 의존하지 않는 기준'이 더 절실하다. 표준은 작은 조직의 빈약한 기억력을 보완해주는 안전장치다.

다섯 번째 오해, '표준만 지키면 자동으로 좋은 사이트가 된다.' 이건 반대 방향의 오해다. 표준은 '기본기'를 보장할 뿐, '훌륭함'까지 보장하진 않는다. 표준을 다 지켜도 콘텐츠가 부실하거나, 정작 사용자가 원하는 정보가 없으면 좋은 사이트가 아니다. 표준화는 '바닥을 받쳐주는 일'이지 '천장을 올리는 일'이 아니다. 다만 바닥이 단단해야 그 위에 좋은 콘텐츠와 서비스를 안심하고 쌓을 수 있다. 표준은 '충분조건'이 아니라 '필요조건'이라고 생각하면 딱 맞다.

이 다섯 오해를 풀고 나면, 표준화를 바라보는 시선이 달라진다. '개성을 죽이는 큰 사업이고, 전문가의 일이며, 큰 기관에나 필요하고, 그것만 하면 끝나는 일'이 아니라 — '개성을 살리는 토대이고, 작게 시작할 수 있으며, 모두의 일이고, 작은 조직에 더 필요하고, 좋은 사이트의 출발점'이라는 제대로 된 그림이 그려진다.

■ 사례로 보는 표준화 전과 후 — 익명 셋

말로만 들으면 와닿지 않으니, 익명으로 처리한 세 장면을 곁들인다. 특정 기관을 흉보려는 게 아니라, 어디서나 반복되는 '전형'을 보여주려는 거다. 읽으면서 '우리도 저런데' 싶은 게 나와도 자책할 필요는 없다. 대부분이 겪는 일이고, 대부분이 같은 방법으로 풀어왔다.

첫 번째 장면. A광역지자체의 한 부서 사이트는 메인은 산뜻한데 안으로 들어갈수록 무너졌다. 부서별로 외주 시기가 달라, 어떤 페이지는 둥근 버튼을 쓰고 옆 페이지는 각진 버튼을 썼다. 같은 '신청' 동작인데 한 곳은 '신청하기', 다른 곳은 '접수'라고 적혀 있었다. 사용자 입장에선 '이게 같은 기능인가' 매번 헷갈렸다. 표준화 이후엔 버튼 모양과 글자를 하나로 통일했고, 사용자가 한 번 익힌 사용법이 모든 페이지에서 그대로 통하게 됐다. 콜센터에 들어오던 '이거 어디서 해요' 류의 문의가 눈에 띄게 줄었다는 후일담이 따라왔다.

두 번째 장면. C기관의 신청 폼은 '마지막에 좌절시키는' 전형이었다. 열 칸 넘게 채우고 첨부파일까지 올린 뒤 제출을 누르면, 화면 맨 위에 빨간 한 줄 '입력을 확인하세요'만 떴다. 어느 칸이 문제인지 안 알려주니, 사용자는 처음부터 다시 모든 칸을 살펴야 했다. 게다가 뒤로 가기를 누르면 적던 내용이 다 날아갔다. 끝에서 포기하는 사람이 많을 수밖에 없었다. 표준화된 흐름 규칙을 적용한 뒤엔, 틀린 칸 바로 옆에 '무엇이 왜 틀렸고 어떻게 고치라'가 떴고, 뒤로 가도 입력이 유지됐다. 같은 폼인데 완주율이 달라졌다.

세 번째 장면. B공공기관은 색을 한 톤 바꾸려다 '표준 없음'의 대가를 톡톡히 치렀다. 브랜드 파랑이 페이지마다 코드에 직접 박혀 있어, 외주 업체가 '어디에 어떤 파랑이 있는지' 전수 조사부터 해야 했다. 목록 만드는 데 며칠, 고치는 데 며칠, 빠뜨린 곳 잡는 데 또 며칠이었다. 이 일을 겪고 나서야 디자인 토큰을 도입했고, 다음 번 색 변경은 토큰 한 곳을 고쳐 반나절 만에 끝냈다. '유지보수 비용 절감'이라는 이득이 추상적인 말이 아님을, 한 번의 고생으로 절감했다.

이 세 장면의 공통점은 '문제의 뿌리가 같다'는 거다. 기준이 머릿속에만 있고 화면 밖으로 나오지 않았다는 것. 그리고 해법도 같다. 기준을 문서로 꺼내, 모두가 같은 걸 보고 쓰게 한 것. 규모가 크든 작든, 예산이 많든 적든, 이 패턴은 거의 똑같이 나타나고 거의 똑같은 방법으로 풀린다. 그러니 우리 사이트에서 비슷한 장면을 찾았다면, 부끄러워할 일이 전혀 아니다. 못 찾는 게, 다시 말해 '안 보이는 게' 더 위험하다.

■ 표준화를 '조직에 정착'시키는 법 — 한 번의 개선으로 끝내지 않으려면

표준화에서 가장 어려운 건 '시작'이 아니라 '지속'이다. 의욕적으로 기준을 만들고 몇 페이지를 정리해도, 담당자가 바뀌고 바쁜 일이 밀려들면 어느새 '각자의 파랑'이 다시 스며든다. 그래서 표준화는 '한 번의 프로젝트'가 아니라 '조직의 습관'으로 자리 잡아야 오래간다. 그 정착을 돕는 현실적인 방법 몇 가지를 짚어보자.

첫째, 표준을 '찾기 쉬운 곳'에 둔다. 아무리 잘 만든 표준 문서도 어딘가 깊은 폴더 속에 묻혀 있으면 아무도 안 본다. 누구나 '우리 색이 뭐였지' 싶을 때 1분 안에 찾을 수 있어야 한다. 기준이 멀면 사람들은 결국 눈대중으로 돌아간다. 표준의 생명은 '접근성'이다. 사람을 위한 접근성만 중요한 게 아니라, 기준 그 자체도 접근하기 쉬워야 한다.

둘째, 표준을 '검수 단계'에 박아 넣는다. 새 페이지나 외주 납품물을 받을 때 '표준을 지켰는가'를 확인하는 절차가 없으면, 표준은 '있으나 마나'가 된다. 검수 체크리스트에 '색·글꼴이 표준 값인가' '주/보조 버튼이 구분되는가' '초점 표시가 보이는가' 같은 항목을 넣어두면, 표준이 '권고'에서 '기준'으로 격상된다. 사람은 '권고'는 잊어도 '검수에 걸리는 것'은 챙긴다.

셋째, 표준을 '계약서'에 명시한다. 외주에 맡길 때 계약 조건에 '기관 디자인 표준을 준수해 구현한다'를 넣고, 납품 검수 기준에 '표준 준수'를 포함한다. 이게 빠지면 업체는 자기에게 익숙한 방식으로 만들고, 그 결과물이 또 다른 조각이 된다. 계약서 한 줄이 '다음 외주가 또 제각각으로 만드는' 사고를 막는다.

넷째, 표준을 '정기적으로 갱신'한다. 사이트는 계속 변하고, 새로운 부품과 흐름이 생긴다. 처음 만든 표준이 6개월 뒤엔 현실과 어긋날 수 있다. 그래서 분기나 반기에 한 번씩 '표준이 지금도 맞는가'를 점검하고, 새로 생긴 부품을 표준에 추가하는 게 좋다. 살아 있는 표준만이 살아 있는 사이트를 따라잡는다. 박제된 표준은 금세 무시당한다.

다섯째, 작은 성공을 '보여준다'. 표준화의 효과를 조직 안에서 인정받으려면, '했더니 이게 좋아졌다'를 숫자로 보여줘야 한다. 앞서 말한 측정이 여기서 빛을 발한다. '표준을 적용한 페이지의 점수가 적용 전보다 올랐다'를 한 장으로 정리해 공유하면, 회의적이던 동료도 '아, 효과가 있구나' 하고 돌아선다. 작은 성공의 증거가 다음 개선의 동력이 되고, 그 선순환이 표준화를 조직에 뿌리내리게 한다.

이 다섯 가지를 갖추면, 표준화는 한 사람의 의욕에 기대지 않고 '조직의 시스템'으로 굴러간다. 담당자가 바뀌어도, 외주가 교체돼도, 시간이 흘러도 품질이 유지된다. 그게 표준화가 궁극적으로 노리는 그림이다 — '사람'에 의존하던 품질을 '기준과 절차'에 의존하게 바꾸는 것.

■ 7가지 이득을 7대 품질 영역과 잇기 — 행안부 지침의 큰 그림

오늘 본 7가지 이득은 우연히 일곱 개로 떨어진 게 아니다. 행정안전부의 「전자정부 웹사이트 품질관리 지침」은 공공웹의 품질을 일곱 영역 — 호환성·접근성·개방성·접속성·편의성·효율성·신뢰성 — 으로 본다. 표준화가 주는 이득들은 이 일곱 영역과 촘촘히 맞물려 있다. 둘을 나란히 놓고 보면, 오늘의 7가지가 '기관 개인의 취향'이 아니라 '공식 지침이 가리키는 방향'과 같다는 게 또렷해진다.

신뢰감(이득1)은 지침의 '신뢰성'과 직접 닿는다. 일관된 화면이 주는 '이 기관은 꼼꼼하다'는 인상이, 보안이나 정보의 정확성만큼이나 사용자의 신뢰를 좌우한다. 학습 비용 절감(이득2)과 흐름 완성도(이득6)는 '편의성'의 핵심이다. 한 번 익히면 어디서나 통하고, 신청을 끝까지 완주하게 돕는 것 — 그게 곧 사용자 편의다. 접근성(이득3)은 지침의 '접근성' 영역 그 자체이며, 우리나라 웹접근성 지침 KWCAG 33항목과도 맞물린다. 누구도 배제하지 않는 사이트라는 약속을, 표준화가 상당 부분 자동으로 거든다.

유지보수 비용 절감(이득4)과 협업 속도(이득5)는 '효율성'과 '호환성'에 닿는다. 토큰 한 곳으로 전체를 바꾸는 구조는 운영 효율을 높이고, 표준에 맞춘 구현은 다양한 브라우저·기기에서 고르게 동작하는 호환성으로 이어진다. 측정 가능성(이득7)은 이 모든 영역을 '숫자로 관리'하게 만드는 메타적 이득이다. 호환성이 몇 점인지, 접근성이 몇 점인지, 효율성이 몇 점인지를 셀 수 있어야 일곱 영역 전체를 균형 있게 끌어올릴 수 있다. 측정이 없으면 어느 영역이 처지는지조차 모른 채 '느낌'으로 운영하게 된다.

이렇게 7가지 이득과 7대 영역을 잇고 나면, 표준화가 '디자인 미화'가 아니라 '공공웹 품질의 근간'임이 분명해진다. 색을 맞추고 글꼴을 통일하는 작은 일이, 결국 행안부가 정한 품질 기준 전반을 받치는 토대가 되는 셈이다. 그래서 '우리 사이트는 표준화가 좀 약한데'라는 자각은, 곧 '7대 품질 영역 여러 곳에서 점수가 새고 있을 수 있다'는 신호로 읽어야 한다. 디자인의 일관성 하나가 이렇게 멀리까지 영향을 미친다.

■ 표준화가 '안 보이게' 작동하는 순간들 — 좋은 표준의 역설

좋은 표준화의 가장 큰 역설은, 잘될수록 '티가 안 난다'는 점이다. 사용자는 표준이 잘 지켜진 사이트에서 '아, 이거 표준화 잘했네'라고 감탄하지 않는다. 그냥 아무 불편 없이 목적을 이루고 나갈 뿐이다. 반대로 표준이 무너진 사이트에서는 '여기 왜 이렇게 불편하지'가 또렷이 의식된다. 즉 표준화는 '잘하면 안 보이고, 못하면 보인다.' 그래서 표준화를 잘한 담당자는 칭찬받기 어렵고, 못한 담당자는 욕먹기 쉽다. 좀 억울한 구조다. 하지만 바로 그래서 '측정'이 필요하다. 눈에 안 보이는 좋은 일을 숫자로 드러내, '이만큼 잘하고 있다'를 증명할 수 있어야 한다.

이 역설은 일상의 여러 장면에서 확인된다. 사용자가 신청을 '한 번에' 끝냈을 때, 그건 우연이 아니라 진행 표시·인라인 오류 안내·상태 유지가 묵묵히 제 일을 한 결과다. 사용자가 모바일에서 메뉴를 '헤매지 않고' 찾았을 때, 그건 부품의 위치와 모양이 데스크탑과 일관됐기 때문이다. 사용자가 화면을 보자마자 '믿음이 갔을' 때, 그건 색과 글꼴이 가지런했기 때문이다. 이 모든 '아무 일도 없었음'이 사실은 표준화가 부지런히 일한 증거다.

그래서 표준화를 추진하는 담당자에게 당부하고 싶다. '티가 안 난다'고 효과가 없는 게 아니다. 오히려 티가 안 날수록 잘하고 있는 거다. 다만 그 보이지 않는 성과를 조직 안에서 인정받으려면, 진단 점수 같은 '객관적 증거'를 손에 쥐고 있어야 한다. '사용자 불만이 줄었다' '콜센터 문의가 줄었다' '진단 점수가 올랐다' — 이런 숫자들이 보이지 않는 일을 보이게 만든다. 좋은 표준화는 사용자에겐 안 보이게, 조직에는 숫자로 보이게 하는 게 정답이다.

■ 오늘 당장 30분이면 하는 '최소 실행' — 미루지 않는 법

7가지 이득과 점검법을 다 읽고도 '바빠서 나중에' 하고 미루기 쉽다. 그래서 마지막으로, '오늘 30분이면 끝낼 수 있는 최소 실행' 한 묶음을 제안한다. 완벽하게 하려다 영영 못 하느니, 작게라도 오늘 시작하는 게 백 배 낫다.

처음 10분은 '보기'다. 우리 사이트 메인을 열고, 가장 많이 쓰이는 흐름(민원 신청이든 정보 검색이든) 하나를 골라 두세 단계 들어간다. 들어가면서 '색·글꼴이 일관적인가' '버튼이 한눈에 보이는가'만 눈으로 확인하며 '예/아니오'를 적는다. 분석하려 들지 말고 그냥 '사용자처럼' 한 바퀴 돈다. 이 10분만으로도 '우리 사이트가 대충 어느 수준인지' 감이 온다.

다음 10분은 '일부러 틀려보기'다. 골라둔 흐름에서 필수 칸을 비우고 제출을 눌러보고, 형식에 안 맞는 값을 넣어보고, 중간에 뒤로 가기를 눌러본다. 사이트가 '무엇이 왜 틀렸는지' 그 칸 옆에서 알려주는지, 뒤로 가도 입력이 유지되는지를 본다. 이 10분이 흐름의 완성도를 가장 빠르게 드러낸다. '아니오'가 나온 지점이 곧 가장 먼저 고칠 곳이다.

마지막 10분은 '숫자 찍기'다. krds.viewcheck.co.kr에 우리 사이트 주소를 넣어 진단 점수 카드를 받아본다. 앞의 20분 동안 내 눈으로 본 '예/아니오'와, 도구가 매긴 점수를 나란히 놓는다. 직감과 진단이 어디서 맞고 어디서 어긋나는지를 비교해보면, '내가 놓친 약점'과 '내가 과대평가한 강점'이 한눈에 보인다. 이 한 장이 '우리 사이트를 처음으로 객관적으로 본' 기준점이 된다.

30분이면 '보기 → 틀려보기 → 숫자 찍기'가 다 끝난다. 거창한 개편 계획도, 예산 결재도 필요 없다. 이 작은 한 바퀴가 '우리 사이트를 제대로 보기'의 시작이고, 모든 개선은 거기서 출발한다. 오늘 30분만 내보자. 그 30분이 1년의 방향을 바꾼다.

■ 자주 묻는 질문 — 담당자들이 실제로 던지는 것들

마지막으로, 표준화 이야기를 할 때마다 담당자들이 실제로 던지는 질문 몇 개에 짧게 답하며 본론을 정리한다.

'우리는 외주에 다 맡기는데, 그래도 우리가 표준을 알아야 하나요?' 그렇다. 오히려 외주에 맡길수록 발주자가 표준을 알아야 한다. 표준을 모르면 '예쁘게 잘 만들어주세요'라는 막연한 주문밖에 못 하고, 결과물이 좋은지 나쁜지 판단할 기준도 없다. 발주자가 '이 표준을 따라주세요, 검수는 이 기준으로 합니다'라고 말할 수 있어야, 외주의 결과물을 우리 사이트답게 통제할 수 있다.

'846개 규칙을 다 외워야 하나요?' 전혀 아니다. 846개는 도구가 따지는 거다. 담당자는 '기초·부품·흐름·접근성'이라는 큰 틀과, 오늘 본 7가지 이득의 감각만 갖추면 충분하다. 세부 규칙은 진단 도구가 짚어주고, 우리는 그 결과를 읽고 우선순위를 정하면 된다. 사람이 할 일과 도구가 할 일은 다르다.

'점수가 너무 낮게 나오면 윗선에 보고하기 곤란하지 않나요?' 이해되는 걱정이다. 하지만 관점을 바꿔보자. 낮은 점수는 '우리가 못한다'는 증거가 아니라 '개선 여지가 크다'는 기회의 지표다. '현재 이 점수이고, 이 영역부터 손대면 이만큼 오를 수 있습니다'라는 개선 계획과 함께 보고하면, 낮은 점수는 오히려 '일을 제대로 시작하는 근거'가 된다. 측정의 가치는 '지금을 깎아내리는 것'이 아니라 '나아갈 방향을 가리키는 것'이다.

'표준화하면 사용자가 정말 알아챌까요?' 사용자는 '표준화됐다'를 의식적으로 알아채진 못한다. 하지만 '편하다' '믿음이 간다' '헤매지 않았다'는 느낌으로 분명히 체감한다. 좋은 표준화는 '보이지 않게' 작동한다. 사용자가 아무 불편 없이 목적을 이루고 나갔다면, 그게 표준화가 잘 작동한 증거다. 눈에 띄지 않는 매끄러움 — 그게 표준화가 사용자에게 주는 가장 큰 선물이다.

'다른 기관은 얼마나 하고 있나요, 우리만 뒤처진 건 아닐까요?' 결론부터 말하면, 거의 모든 기관이 비슷한 고민을 한다. 오늘 본 익명 사례들이 규모와 예산을 가리지 않고 똑같이 반복된다는 게 그 증거다. 표준화가 잘된 곳과 안 된 곳의 차이는 '완벽함'이 아니라 '시작했느냐'에 있다. 기준 한 장을 정해 새 페이지부터 지키기 시작한 기관은 시간이 갈수록 저절로 정돈되고, 미룬 기관은 손댈 때마다 한 조각씩 더 어긋난다. 그러니 '우리만 뒤처졌나' 걱정할 시간에, 오늘 작은 기준 하나를 정해 시작하는 게 훨씬 이롭다. 비교 대상은 '다른 기관'이 아니라 '어제의 우리 사이트'여야 한다.

'표준화 효과가 나타나기까지 얼마나 걸리나요?' 영역마다 다르다. 신뢰감(이득1)처럼 색·글꼴만 통일해도 바로 체감되는 것도 있고, 유지보수 비용 절감(이득4)처럼 다음 번 사이트 개편 때야 '아, 토큰으로 해두길 잘했다' 싶은 것도 있다. 중요한 건 '효과가 느린 이득'일수록 미리 씨를 뿌려둬야 한다는 점이다. 토큰 구조를 지금 갖춰두지 않으면, 1년 뒤 색을 바꿀 때 또 전수 조사의 고생을 반복한다. 빠른 이득으로 동력을 얻고, 느린 이득을 위해 토대를 깔아두는 — 두 박자를 함께 가져가는 게 표준화의 요령이다.

이 질문들의 답을 관통하는 건 결국 하나다. 표준화는 거창한 무엇이 아니라, '사용자에게 일관되고 예의 바른 경험을 약속하고 지키는 일'이라는 것. 그 약속을 지키는 데 필요한 첫걸음이 '지금 우리가 어디쯤인지 아는 것'이고, 그래서 자가 점검과 진단이 모든 개선의 출발점이 된다.

마무리

오늘 우리는 '디자인을 표준화하면 뭐가 좋아지는가'를 7가지로 풀어봤다. 신뢰감, 학습 비용 절감, 접근성, 유지보수 비용 절감, 협업 속도, 흐름 완성도, 그리고 측정 가능성. 일곱 가지를 관통하는 하나의 메시지가 있다면 이거다 — 표준화는 '예쁘게 만드는 일'이 아니라 '일하는 방식을 바꾸고, 새는 비용을 막고, 사용자에게 한 약속을 지키는 일'이라는 것.

이번 주 세 편의 글을 돌아보면, 월요일엔 공공웹이 왜 제각각인지를 물었고, 수요일엔 그 뿌리가 디자인시스템의 부재라는 걸 봤고, 오늘은 그걸 갖췄을 때 얻는 것들을 짚었다. 이 흐름의 끝에서 자연스럽게 떠오르는 질문은 하나다. '그래서 우리 사이트는 지금 몇 점인가?' 7가지 자가 점검으로 '대충 어디가 약한지' 감은 잡았겠지만, 846개 규칙 전체를 사람 손으로 따지는 건 불가능하다. 거기서부터는 도구의 몫이다.

그래서 권한다. 무거운 결심도, 결재도, 예산도 필요 없다. krds.viewcheck.co.kr에 우리 기관 사이트 주소만 넣어보면, 846개 규칙 기준으로 어느 영역이 강하고 어디가 약한지를 점수 카드로 보여준다. 오늘 적은 '예/아니오' 종합표와 그 점수 카드를 나란히 놓아보면, 내 직감과 실제 진단이 어디서 맞고 어디서 어긋나는지가 한눈에 들어올 거다. 무료 진단이니 부담 없이 한 번 돌려보길 바란다. 그게 '우리 사이트를 제대로 보기'의 가장 빠른 첫걸음이다.

마지막으로, 점수가 낮게 나와도 너무 낙담하지 말자. 앞서 말했듯 '아니오'가 많다는 건 '좋아질 여지가 크다'는 뜻이다. 오늘 진단으로 기준점을 한 번 찍고, 아래층부터 한 겹씩 정리하고, 분기마다 다시 측정하며 추세를 보는 것 — 그 단순한 반복이 1년 뒤 우리 사이트를 몰라보게 바꿔놓을 거다. 모든 개선은 '지금 어떤 상태인지'를 아는 데서 시작한다. 오늘 그 첫 숫자를 찍어보자. 그리고 다음 주, 다음 분기에 같은 진단을 다시 돌려 추세를 보자. 한 번의 점검은 사진 한 장이지만, 반복된 점검은 우리 사이트가 좋아지고 있는지 나빠지고 있는지를 보여주는 영상이 된다. 표준화는 거기서 비로소 '이벤트'가 아니라 '습관'이 되고, 습관이 된 표준화만이 오래도록 사이트를 지킨다. 오늘의 30분이, 그 긴 습관의 첫날이 되길 진심으로 바란다.