검수는 통과인데 왜 민원이 터질까 — 리뉴얼 검수가 놓치는 자리, 그리고 KRDS로 그 자리를 메우는 법

들어가며 — "통과 도장"을 두 개나 받았는데

월요일엔 "웹 품질을 보는 세 시점"이라는 큰 그림을 깔았습니다. 설계·운영·판단, 이 셋을 다 봐야 전체가 보인다는 이야기였습니다. 그리고 그 위에서 KRDS 846규칙이 시점별로 판정된다는 것까지 봤습니다. 오늘은 그 추상적인 개념을 실제 현장의 장면으로 가져와 보겠습니다. 한 시점만 보다가 실제로 어떻게 새는지, 현장에서 반복해서 벌어지는 패턴을 사례로 따라가 보시죠. 다 익명이고, 특정 기관 이야기가 아닙니다. 어디서나 비슷하게 일어나는 일이라서 오히려 사례로 쓸 수 있는 것이죠.

장면은 이렇게 시작합니다. ㅇㅇ기관이 사이트를 크게 개편했습니다. 예산도 적지 않게 들였고, 절차도 제대로 밟았습니다. 디자인 검수도 받았고, 코드 검사 도구도 돌렸습니다. 둘 다 결과는 "통과"였습니다. 보고서에도 그렇게 올라갔고, 담당자는 "할 일 다 했다"는 안도감으로 오픈을 맞았습니다. 그런데 오픈하고 며칠 지나자 민원이 들어오기 시작했습니다. "버튼이 작아서 자꾸 잘못 눌려요." "모바일에서 글자가 겹쳐 보여요." "신청 화면이 너무 복잡해서 중간에 포기했어요."

여기서 담당자가 가장 먼저 떠올린 생각은 이거였습니다. "분명히 검수 통과했는데, 왜?" 통과 도장을 두 개나 받았는데 현실에선 문제가 터집니다. 이 모순이 오늘의 주제입니다. 결론부터 말씀드리면, 각각의 통과는 정직했지만, 그 통과들의 합이 전체의 통과는 아니었기 때문입니다. 왜 그런지, 그리고 어떻게 하면 이 빈틈을 메울 수 있는지를 차근차근 풀어보겠습니다.

이런 일이 한 기관만의 특별한 불운이라고 생각하시면 오산입니다. 오히려 리뉴얼 사업의 흔한 결말에 가깝습니다. 새로 단장한 사이트를 자랑스럽게 오픈했는데, 몇 주 안에 "예전이 나았다"는 소리가 나오는 경우. 외부에서 보면 "돈 들여 개편했는데 왜 더 불편해졌냐"는 비난이 되고, 내부에서 보면 "분명히 검수까지 다 받았는데 억울하다"는 항변이 됩니다. 양쪽 다 틀린 말이 아니라서 더 답답합니다. 사용자는 진짜로 불편했고, 담당자는 진짜로 절차를 다 밟았습니다. 그렇다면 문제는 사람이 아니라 "점검 방식" 자체에 있다는 뜻입니다. 오늘 글은 그 방식의 빈틈을 들여다보는 이야기입니다.

오늘 사례의 기관이 만약 URL 하나만 넣어 운영 중인 사이트를 자동으로 돌아보는 분석을 한 번만 했어도, 민원이 터지기 전에 같은 문제를 미리 짚었을 것입니다. "검수 통과"와 "실물 점검"은 보는 대상 자체가 다릅니다. 그 차이가 오늘 글 전체를 관통합니다.

본론 1 — 통과의 합은 전체의 통과가 아니다

각자 자기 자리에선 정직했다

먼저 무슨 일이 있었는지 뜯어보겠습니다. 이 기관이 받은 두 개의 통과는 각각 이랬습니다.

디자인 검수. 디자인 팀이 시안을 보고, KRDS 기준에 맞는지 확인했습니다. 색이 표준 색인지, 컴포넌트 규격이 맞는지, 레이아웃이 가이드대로인지. 시안은 잘 만들어졌고, 기준에 맞았습니다. 그래서 "통과". 이건 거짓말이 아닙니다. 시안 자체는 정말로 기준에 맞았으니까요.

코드 검사. 개발이 끝난 뒤, 코드 검사 도구를 돌렸습니다. 이 도구는 코드에서 기계적으로 잡히는 항목을 봅니다. 이미지에 대체텍스트가 있는가, 입력창에 라벨이 붙어 있는가, HTML 구조에 명백한 오류가 없는가. 이런 것들. 결과는 "오류 0건". 이것도 거짓말이 아닙니다. 그 도구가 보는 범위 안에선 정말로 문제가 없었으니까요.

두 통과 모두 정직했습니다. 디자인 검수는 자기가 본 것(시안)에 대해, 코드 검사는 자기가 본 것(코드 일부)에 대해 정직하게 통과를 줬습니다. 문제는 둘 중 누구도 보지 않은 영역에 있었습니다.

비유하면 이렇습니다. 건물을 짓는데 설계도 검토에서 "도면 이상 없음", 골조 검사에서 "철근 배근 이상 없음"을 받았다고 해보겠습니다. 둘 다 맞는 말입니다. 그런데 정작 입주자가 살면서 마주하는 건 마감, 동선, 채광 같은 "실제 생활 품질"입니다. 도면과 골조가 통과했다고 입주 후 생활이 쾌적하다는 보장은 없습니다. 웹도 똑같습니다. 시안(도면)과 코드(골조)가 통과해도, 사용자가 실제로 마주하는 화면(생활 품질)은 별개입니다. 그 별개의 영역을, 오늘 사례에선 아무도 검사 항목에 넣지 않았습니다.

녹색 통과 도장 두 개를 더해도 하나의 완전한 통과가 되지 않고 그 사이에 주황색 틈이 남는 "통과의 합 ≠ 전체의 통과" 개념 도식 (Gemini 1:1)

아무도 "실제 배포된 화면"을 사용자 눈으로 안 봤다

핵심은 이것입니다. 누구도 실제로 배포돼서 돌아가는 화면을, 사용자가 마주하는 그대로 보지 않았습니다. 디자인 검수는 "만들기 전(설계 시점)"의 시안만 봤고, 코드 검사는 "코드 일부"만 봤습니다. 정작 사용자가 진짜로 손가락으로 누르고 눈으로 읽는 "운영 중인 실물 화면(운영 시점)"은 양쪽 다 사각지대였습니다.

그 사각지대에서 무슨 일이 벌어졌을까요. 시안에선 충분히 컸던 버튼이, 개발 과정에서 다른 요소에 밀려 작아졌습니다. 시안엔 없던 모바일 레이아웃 깨짐이, 실제 다양한 화면 크기에서 구현되며 새로 생겼습니다. 디자인 시스템의 간격 값이 코드로 옮겨지면서 미묘하게 달라졌습니다. 이런 것들은 시안을 봐도, 코드 구조를 봐도 안 잡힙니다. 오직 실제 화면을 실제 기기 크기로 띄워 봐야만 잡힙니다.

월요일에 썼던 표현을 다시 쓰면, 이 기관은 "디자인은 통과인데 배포본은 위반"인 전형적인 경우입니다. 의도(디자인)는 맞았는데 결과(배포본)가 어긋났고, 그 간극을 아무도 안 봤습니다. 그래서 통과 도장 두 개가 무색하게, 사용자는 불편을 겪었습니다.

데스크톱·태블릿·모바일 3개 뷰포트를 실제로 띄워 보고, 터치 타겟이 기준 크기(44×44px)보다 작은 곳을 잡아낸 반응형 품질 점검 화면. "버튼이 작아서 자꾸 잘못 눌린다"는 바로 그 민원이, 여기서는 오픈 전에 수치로 잡힙니다 (기관명·도메인 블러)

KRDS 규칙으로 보면 무엇이 걸렸을까

여기서 KRDS 846규칙을 끌어와 보면 이 사례가 더 선명해집니다. 월요일에 봤듯이, 846규칙은 디자인 스타일(DS)·컴포넌트(CP)·기본 패턴(BP)·서비스 패턴(SP) 네 묶음으로 나뉩니다. 이 기관의 문제를 규칙에 비춰보면 이렇게 잡힙니다.

"버튼이 작다"는 건 컴포넌트(CP) 규칙과 디자인 스타일(DS) 규칙에 걸립니다. KRDS는 터치 가능한 요소의 최소 크기를 정해 두는데, 실제 렌더링된 화면에서 그 크기가 미달이면 위반으로 잡힙니다. 중요한 건, 이걸 시안에서 봤을 땐 통과였다는 것입니다. 시안의 버튼은 컸으니까요. 그런데 운영 시점에서 실제 화면의 computed style(브라우저가 최종 계산한 실제 값)을 보면 작아져 있습니다. 같은 규칙인데 시점이 다르면 판정이 갈리는 셈입니다.

"모바일에서 글자가 겹친다"는 것도 마찬가지입니다. 이건 코드 구조만 봐서는 안 잡힙니다. HTML은 멀쩡하니까요. 실제로 모바일 크기로 렌더링해서 화면을 봐야 "어, 여기 두 요소가 겹치네" 하고 잡힙니다. 그래서 이런 위반은 본질적으로 운영 시점, 그것도 시각적으로 화면을 확인하는 영역에 속합니다. 코드 검사 도구가 "0건"을 준 건, 이 영역이 애초에 그 도구의 사정거리 밖이었기 때문입니다.

이게 월요일에 말씀드린 "규칙마다 적합한 시점이 다르다"의 구체적인 모습입니다. 같은 846규칙이라도, 어떤 건 코드를 봐야 잡히고 어떤 건 실제 화면을 봐야 잡힙니다. 그래서 한 시점만 보는 도구는, 그 시점에서 잡히는 규칙만 통과/미통과로 판정하고 나머지는 비워둡니다. 비워둔 자리에서 민원이 났습니다.

"통과"라는 단어가 만드는 착시

여기서 한 가지 더 짚고 싶은 게 있습니다. "통과"라는 단어가 주는 심리적 착시입니다. 사람은 "통과"라는 말을 들으면 자연스럽게 "전체가 괜찮다"로 받아들입니다. 그게 사실은 "내가 본 범위 안에서만 괜찮다"는 뜻인데도 말입니다. 이 착시가 위험한 건, 통과를 받는 순간 점검을 멈추게 만들기 때문입니다. "통과 받았으니 됐다"는 생각이 들면, 더 이상 다른 시점을 보려 하지 않습니다. 오히려 통과를 못 받았으면 "뭐가 문제지?" 하고 더 봤을 텐데, 통과가 점검을 종료시켜 버립니다.

그래서 역설적이지만, 부분적인 통과가 아예 점검을 안 한 것보다 더 위험할 때가 있습니다. 안 했으면 "아직 안 봤으니 봐야지"라는 경계심이라도 남는데, 부분 통과는 "다 봤다"는 거짓 안도감을 주니까요. 오늘 사례의 기관도 정확히 여기에 걸렸습니다. 디자인 통과 + 코드 통과 = "다 됐다"는 착각. 그 착각이 실물 화면을 안 보게 만들었고, 안 본 데서 사고가 났습니다. 통과라는 단어를 들을 때마다 "무엇에 대한, 어느 범위의 통과인가"를 되묻는 습관이, 이 착시를 깨는 유일한 방법입니다.

검사 도구의 "오류 0건"을 어떻게 읽어야 하나

코드 검사 도구가 "오류 0건"을 뱉었을 때, 그걸 어떻게 해석해야 하는지도 정리해 두겠습니다. "오류 0건"은 거짓이 아닙니다. 다만 그 문장에는 생략된 주어가 있습니다. 정확히 풀어 쓰면 "이 도구가 검사할 수 있는 항목 중에서, 오류 0건"입니다. 검사할 수 없는 항목, 즉 그 도구의 사정거리 밖에 있는 것들은 애초에 0건 계산에 들어가지도 않았습니다.

예를 들어 색상 대비가 부족해서 글자가 잘 안 보이는 문제, 화면에서 두 요소가 겹치는 문제, 이미지로 만든 버튼이 접근성 보조기기에 안 잡히는 문제 — 이런 시각·실물 영역은 많은 코드 검사 도구의 범위 밖입니다. 그러니 그 도구의 "0건"은 이 영역에 대해 아무 말도 하지 않은 셈입니다. 침묵을 통과로 읽으면 안 됩니다. ViewCheck식으로 말하면, 운영 시점의 "시각 측면"과 판단 시점이 통째로 빠진 "0건"이었던 셈입니다. 그 빈 영역에서 민원이 났습니다.

리뉴얼 절차는 왜 이렇게 짜여 있을까 — 관행의 관성

그런데 잠깐, 왜 리뉴얼 검수 절차는 애초에 이렇게 짜여 있을까요. 디자인 검수와 코드 검사만 있고, 실물 화면 점검은 왜 절차에 없었을까요. 담당자가 게을러서가 아닙니다. 관행이 만들어진 시절의 한계가 그대로 굳어 있기 때문입니다.

디자인 검수와 코드 검사는 "사람이 할 수 있는 점검"이었습니다. 시안 몇 장을 넘겨보는 것, 검사 도구 버튼을 누르는 것. 둘 다 반나절이면 됩니다. 반면 "배포된 실물 화면을 사이트 전체에 걸쳐, 여러 기기 크기로, 846개 기준에 비춰 확인하는 것"은 사람 손으로는 몇 주가 걸리는 일이었습니다. 그러니 절차에 못 들어갔습니다. 할 수 없는 일은 절차가 되지 못합니다. 절차는 "해야 하는 일"이 아니라 "할 수 있는 일"로 채워지는 법이니까요.

문제는 기술이 바뀌었는데 절차는 그대로라는 것입니다. 지금은 URL 하나로 실물 전수 점검이 몇 분에서 몇십 분이면 됩니다. "할 수 없는 일"이 "할 수 있는 일"이 됐습니다. 그런데 검수 절차는 여전히 십수 년 전의 가능성 목록에 머물러 있습니다. 오늘 사례의 기관이 특별히 잘못한 게 아니라, 오래된 절차를 그대로 따랐을 뿐인 이유가 여기 있습니다. 그래서 이 문제의 해법도 "담당자가 더 꼼꼼해지자"가 아니라 "절차에 실물 점검 관문을 추가하자"가 되는 것입니다. 사람이 아니라 절차를 고치는 쪽으로요. 이 이야기는 글 뒤에서 다시 정리하겠습니다.

본론 2 — 운영 시점을 봤어도, "메인만" 봤다면

두 번째 함정: 범위를 좁히는 것

자, 이 기관이 실수를 깨닫고 이번엔 운영 중인 화면을 봤다고 해보겠습니다. 그래도 또 다른 함정이 기다립니다. 메인 페이지 한 장만 보는 함정입니다.

사고는 보통 메인에서 안 납니다. 메인은 가장 많이 보고, 가장 공들여 만들고, 가장 자주 점검하는 페이지니까요. 정작 사고는 사람들이 잘 안 들어가 보는 깊은 페이지에서 납니다. 민원 신청 폼, 정책 안내 페이지, 로그인 화면, 몇 년 전에 만들고 방치된 게시판. 이런 곳이 진짜 지뢰밭입니다. 그런데 점검은 늘 메인부터, 그리고 자주 메인에서 끝납니다.

왜 그럴까요. 사람이 손으로 점검하면 페이지 하나 보는 데도 시간이 걸리니까, 자연스럽게 "대표 페이지 몇 개만" 보게 됩니다. 그게 보통 메인입니다. 그리고 메인이 통과하면 "사이트가 통과"라고 생각해 버립니다. 하지만 메인의 통과는 메인의 통과일 뿐입니다. 운영 시점의 진짜 강점은 "사이트 전체를 사용자처럼 빠짐없이 도는 것"인데, 범위를 메인으로 좁히면 그 강점이 통째로 사라집니다.

여기에 또 하나의 함정이 겹칩니다. 메인 페이지는 보통 가장 잘 만들어져 있어서, 메인만 보면 사이트 전체가 실제보다 좋아 보이는 착시가 생깁니다. "우리 사이트 꽤 괜찮네"라는 인상이, 가장 잘 만든 한 장에서 나오는 것입니다. 그런데 그 인상으로 사이트 전체를 판단하면, 정작 사용자 불만이 쏟아지는 깊은 페이지는 인상에 반영되지 않습니다. 평균을 가장 좋은 표본 하나로 대신하는 셈입니다. 통계로 치면 명백한 오류인데, 점검에선 이게 너무 자주 일어납니다. 메인이 좋을수록 이 착시는 더 강해집니다.

다중 페이지로 본다는 것의 의미

ViewCheck가 운영 시점을 다루는 방식의 핵심이 여기 있습니다. URL 하나를 넣으면, 메인 한 장이 아니라 사이트를 자동으로 돌면서 여러 페이지를 수집하고, 각 페이지마다 846규칙을 판정합니다. 그리고 집계할 때 중요한 원칙을 씁니다. 한 페이지라도 위반이 있으면, 그건 사이트 전체의 문제로 봅니다.

왜 이렇게 엄격하게 볼까요. 생각해 보면 당연합니다. 사용자는 "메인은 괜찮으니까 신청 페이지가 불편해도 참아야지" 하고 봐주지 않습니다. 사용자가 실제로 업무를 보는 건 그 신청 페이지입니다. 거기서 막히면 그 사용자에겐 사이트 전체가 실패한 것입니다. 그래서 "메인은 통과인데 신청 페이지에서 무너지는" 경우를, 통과로 흡수해버리지 않고 정확히 사이트의 문제로 드러내는 방식입니다.

이렇게 여러 페이지를 보면, 페이지 사이의 불일치도 잡힙니다. 메인에선 KRDS 표준색을 잘 썼는데 하위 페이지에선 옛날 색이 남아 있다거나, 어떤 페이지엔 접근성 속성이 잘 붙었는데 다른 페이지엔 빠져 있다거나. 한 페이지만 보면 절대 안 보이는, "페이지 간 일관성" 문제입니다. 공공 웹처럼 여러 사람이 오랜 기간에 걸쳐 만든 사이트일수록 이 불일치가 많습니다. 이 다중 페이지 분석은 워낙 중요해서 6개월차에 한 달을 통째로 할애해 다룰 예정입니다.

조금 더 현실적인 그림을 그려보겠습니다. 공공 사이트 하나에 페이지가 수백 개씩 되는 건 드문 일이 아닙니다. 부서마다 안내 페이지가 있고, 사업마다 신청 폼이 있고, 공지·게시판·자료실이 켜켜이 쌓여 있습니다. 이걸 사람이 손으로 다 점검한다는 건 사실상 불가능에 가깝습니다. 그래서 "대표 페이지 몇 개만"으로 타협하고, 그 타협이 깊은 페이지를 사각지대로 만듭니다. 자동 분석이 진짜 위력을 발휘하는 지점이 바로 여기입니다. 사람은 열 페이지만 봐도 지치지만, 자동 분석은 수십, 수백 페이지를 같은 기준으로 지치지 않고 봅니다. "전수로 본다"는 게 말로는 쉬워도 손으로는 불가능한데, 자동화는 그걸 현실로 만듭니다.

그리고 전수로 보면 보고의 성격도 달라집니다. "메인은 A등급"이 아니라 "사이트 전체에서 이 페이지군이 가장 약하다"는 식의 진단이 가능해집니다. 어느 부서의 어느 페이지가 유독 위반이 많은지, 어떤 유형의 페이지(신청 폼, 게시판 등)가 공통적으로 약한지가 데이터로 드러납니다. 이건 개선 작업을 배분할 때 결정적인 정보입니다. "다 고쳐라"가 아니라 "이 페이지군부터 고쳐라"가 되니까요. 한 페이지만 보는 점검으론 절대 못 주는 그림입니다.

녹색으로 통과된 메인 페이지 한 장 옆에, 사이트맵의 여러 깊은 페이지에서 주황색 위반 표시가 드러나는 다중 페이지 집계 개념 도식 (Gemini 1:1)

깊은 페이지일수록 까다로운 이유

깊은 페이지가 점검에서 빠지는 데는 또 다른 이유가 있습니다. 신청 폼이나 로그인 같은 페이지는 로그인을 해야 들어가지거나, 여러 단계를 거쳐야 도달하거나, 특정 조건에서만 나타납니다. 그래서 자동 점검 도구로도 닿기가 쉽지 않습니다. 단순히 첫 화면만 긁고 끝나는 도구는, 이런 페이지를 아예 못 봅니다.

그리고 이런 페이지일수록 KRDS의 서비스 패턴(SP, 172개) 규칙이 집중적으로 걸립니다. 로그인 흐름이 권장 방식대로인지, 신청 절차가 사용자를 헷갈리게 하지 않는지, 검색 결과가 제대로 정리돼 나오는지. 이런 건 페이지 한 장이 아니라 "흐름"을 봐야 판정되니까, 점검 난이도가 가장 높습니다. 역설적으로, 가장 점검하기 어려운 페이지가 가장 민원이 많은 페이지인 것입니다. 그래서 운영 시점을 제대로 쓰려면, "메인만"이 아니라 이 깊고 까다로운 페이지까지 닿아야 합니다.

ViewCheck는 로그인·검색·신청 같은 서비스 흐름이 KRDS 권장 패턴을 따르는지 항목별로 봅니다. "신청 화면이 복잡해서 포기했다"는 민원의 뿌리가, 이런 서비스 패턴(SP) 위반에서 시작되는 경우가 많습니다. 메인 화면만 봐서는 절대 닿지 않는 영역인데, 이 서비스 패턴의 세계는 5개월차에서 본격적으로 다룹니다.

본론 3 — 데이터는 많았는데, 손도 못 댄 경우

세 번째 함정: 판단이 빠지면 데이터는 숙제가 된다

세 시점 중 두 개를 챙겨도, 나머지 하나가 비면 또 거기서 샙니다. 이번엔 다른 ㅇㅇ기관 이야기입니다. 이 기관은 앞의 실수를 안 했습니다. 설계도 잘 봤고, 운영 화면도 자동으로 사이트 전체를 잘 훑었습니다. 데이터는 충분했습니다. 위반이 몇백 건이나 나왔으니까요. 점검 자체는 훌륭했습니다.

그런데 결과물이 그냥 "위반 몇백 건"이라는 긴 목록으로만 남았습니다. 뭐부터 손대야 할지, 그 몇백 건 중에 뭐가 사용자에게 진짜 치명적인지, 뭐가 맥락상 봐줄 만한지, 각각을 어떻게 고쳐야 하는지 — 이런 "판단"이 빠져 있었습니다. 데이터는 많은데 길잡이가 없었던 것입니다.

결과는 예상대로였습니다. 그 목록을 받은 담당자가 결국 손도 못 댔습니다. 너무 많고, 우선순위가 없으니까요. 어디서부터 시작해야 할지 막막하니까요. "다 고쳐야 한다"는 사실상 "아무것도 안 고친다"와 비슷한 상태가 됩니다. 데이터가 부족해서가 아니라, 데이터를 행동으로 옮길 판단이 없어서 멈춘 겁니다. 이게 월요일에 말씀드린 "판단 시점이 빠지면 발견이 개선으로 안 이어진다"의 실제 모습입니다.

이건 사실 첫 번째 기관보다 더 안타까운 경우입니다. 첫 번째 기관은 애초에 실물을 안 봐서 데이터가 없었지만, 이 기관은 데이터를 다 갖고도 못 썼으니까요. 점검에 들인 노력이 결과로 이어지지 못하고 증발한 셈입니다. 그리고 이런 일이 반복되면, 조직 안에서 점검 자체에 대한 회의가 생깁니다. "어차피 분석해봤자 목록만 잔뜩 나오고 못 고치는데, 굳이 왜?" 점검 무용론입니다. 이게 무서운 건, 다음번엔 아예 점검을 안 하게 만들기 때문입니다. 데이터를 행동으로 못 바꾼 한 번의 경험이, 점검 자체를 포기하게 만들거든요. 그래서 판단 시점은 "있으면 좋은" 게 아니라, 점검이 헛수고가 되지 않게 막는 필수 단계입니다.

위험도 등급이 막막함을 순서로 바꾼다

이 막막함을 푸는 게 판단 시점의 역할입니다. 핵심은 위반에 등급을 매기는 것입니다. 똑같은 위반이 아닙니다. 화면을 못 보는 사용자가 아예 신청을 못 하게 만드는 치명적 위반이 있고, 간격이 몇 픽셀 어긋난 경미한 위반이 있습니다. 이걸 한 덩어리로 "몇백 건"이라고 뭉뚱그리면 막막하지만, P0(치명적)·P1(높음)·P2(중간)·P3(경미)로 나누면 순서가 보입니다.

"몇백 건"이 "P0 몇 건, P1 몇십 건, 나머지는 천천히"로 바뀌는 순간, 담당자는 움직일 수 있습니다. "이번 주엔 P0부터 잡자"가 되니까요. 데이터가 행동 계획으로 번역되는 것입니다. 그리고 각 위반에 "이렇게 고치면 된다"는 구체적인 방법과 예상 작업량까지 붙으면, 담당자는 그걸 그대로 업무 지시로 쓸 수 있습니다. 위반 목록이 숙제 더미에서 실행 계획으로 바뀝니다.

위반을 위험도(P0~P3)로 등급화한 법적 리스크 위험도평가 화면. "다 고쳐야 한다"는 막막함 대신 "이것부터"라는 순서가 나오는 판단 시점의 실제 모습 (기관명·도메인 블러)

AI가 채우는 빈칸, 그리고 우선순위

판단 시점에서 또 하나 중요한 게 있습니다. 코드만으로는 판정이 안 돼 비어 있던 칸을 메우는 일입니다. 월요일에 봤듯이, 규칙 엔진이 코드를 보고 판정하다 보면 "이미지로 만든 버튼"처럼 코드상으론 안 잡히는 게 N/A(해당 없음)로 빠집니다. 시각 AI가 화면을 보고 "이건 명백히 버튼이다"라고 감지해서 그 빈칸을 pass/fail로 채웁니다. 점검에 생기는 구멍을 메우는 역할이죠.

이렇게 빈칸이 메워지고, 메워진 결과에 위험도가 매겨지고, 위험도순으로 정렬되면, 비로소 "그래서 뭐부터"라는 질문에 답이 나옵니다. 두 번째 기관이 멈췄던 그 지점을, 판단 시점이 통과시키는 것입니다. 발견(운영 시점)에서 이해(판단 시점)로, 이해에서 개선으로 이어지는 흐름이 완성됩니다. 이 AI 보강과 판단의 세계는 8개월차(LLM 분석)에서 한 달을 통째로 다룹니다.

위험도를 무엇으로 가르는가

여기서 자연스럽게 드는 의문이 있습니다. "위험도는 무슨 기준으로 매기는데?" 막연히 "중요해 보이는 순서"라면 그것도 결국 감입니다. 그래서 등급의 기준이 명확해야 합니다. ViewCheck는 위반이 사용자에게 미치는 영향과, 그 위반이 어긴 규칙의 성격을 함께 봅니다. 화면을 못 보는 사용자가 핵심 기능을 아예 못 쓰게 만드는 위반, 신청·결제 같은 필수 흐름을 막는 위반은 가장 높은 등급으로 올라갑니다. 반대로 미관에 가까운, 사용자가 업무를 보는 데 지장이 거의 없는 위반은 낮은 등급으로 내려갑니다.

이렇게 등급을 나누면, "몇백 건"이라는 숫자가 의미 있는 층으로 갈라집니다. 위에서 본 두 번째 기관의 막막함은, 사실 "다 똑같이 중요해 보여서" 생긴 문제였습니다. 다 중요하면 아무것도 우선이 아니게 되니까요. 등급이 들어오는 순간, 진짜 급한 소수가 분리돼 나옵니다. 그 소수만 먼저 잡아도 사용자가 체감하는 개선은 큽니다. 이게 "적게 고치고 크게 개선하는" 길이고, 자원이 늘 부족한 공공기관에 특히 잘 맞는 접근입니다.

"어떻게 고치냐"까지 와야 행동이 된다

위험도순으로 정렬됐다고 끝이 아닙니다. "이게 1순위입니다"까지만 주면, 담당자는 "그래서 이걸 어떻게 고치죠?"에서 또 멈춥니다. 위반을 발견하는 것과 고치는 방법을 아는 건 다른 능력입니다. 그래서 판단 시점은 한 걸음 더 나아가, 각 위반을 어떻게 고치면 되는지 구체적인 방법과 예상 작업량까지 붙입니다. "이 입력창에 이런 라벨을 연결하세요", "이 버튼 크기를 이만큼 키우세요" 같은 식으로요.

여기까지 와야 비로소 분석이 행동으로 바뀝니다. 발견 → 우선순위 → 수정 방법, 이 세 단계가 다 갖춰져야 담당자가 자리에서 일어나 실제로 손을 댑니다. 두 번째 기관이 받았던 "위반 목록"은 첫 단계에서 멈춰 있었습니다. 발견은 했는데 우선순위도, 방법도 없었으니 행동으로 못 갔습니다. 판단 시점은 이 세 단계를 끝까지 이어서, 멈춰 있던 데이터를 다시 굴러가게 만듭니다.

고친 다음엔 — 같은 자로 다시 재야 사이클이 닫힌다

판단 시점이 우선순위와 수정 방법까지 내놓고, 담당자가 실제로 고쳤다고 해보겠습니다. 그럼 끝일까요. 아직 한 단계가 남았습니다. 정말 해소됐는지, 같은 기준으로 다시 재는 것.

"고쳤다"와 "해소됐다"는 다릅니다. 개발자가 수정했다고 보고했는데 실제로는 절반만 고쳐졌거나, 그 페이지는 고쳐졌는데 같은 문제가 있는 다른 페이지는 그대로거나, 고치는 과정에서 새 위반이 생기는 일이 현장에선 흔합니다. 이걸 확인하는 방법은 하나뿐입니다. 처음 쟀던 그 846규칙, 그 기준으로 다시 분석을 돌려서 위반 목록에서 사라졌는지 보는 것. 기준이 같아야 "전 386건 → 후 214건"이라는 비교가 성립합니다.

이 재확인까지 돌아야 개선 사이클이 닫힙니다. 발견 → 우선순위 → 수정 → 재확인. 앞의 세 단계만 하고 재확인을 생략하면, "고쳤다고 믿는 상태"와 "실제 상태"가 또 벌어집니다. 오늘 글의 주제였던 "통과 도장과 실물의 간극"이, 이번엔 개선 단계에서 반복되는 것입니다. 다행히 재확인의 비용은 낮습니다. 같은 URL로 분석을 한 번 더 돌리면 되니까요. 이 개선 사이클 전체는 9개월차(개선 실행)에서 자세히 다룹니다.

본론 4 — 세 사례를 관통하는 하나의 규칙

한 시점의 약점은 다른 시점의 강점이다

세 사례를 쭉 늘어놓고 보면, 같은 규칙이 반복됩니다. 한 시점의 약점은 정확히 다른 시점의 강점입니다.

첫 번째 기관: 설계와 코드만 봐서 "실물 화면"을 놓쳤습니다 → 운영 시점이 메웠어야 했습니다.
두 번째 함정: 운영 화면을 봐도 메인만 봐서 깊은 페이지를 놓쳤습니다 → 다중 페이지(전수 운영 점검)가 메웠어야 했습니다.
세 번째 기관: 데이터는 충분했는데 판단이 없어서 멈췄습니다 → 판단 시점이 메웠어야 했습니다.

각 사례에서 빠진 자리가 다 다르지만, 공통점은 하나입니다. 빠진 그 자리는 늘 "내가 잘 보는 시점"의 바깥에 있었습니다. 디자인 팀은 설계를 잘 보고, 개발 팀은 코드를 잘 보고, 데이터에 능한 팀은 수집을 잘합니다. 각자 자기가 잘하는 걸 했습니다. 그런데 자기가 안 보는 시점은, 그게 비어 있다는 사실조차 인식하기 어렵습니다. 그래서 빈자리가 생기는 줄도 모르고 "통과"를 줬던 거죠.

"어느 도구가 좋냐"가 아니라 "다 덮고 있냐"

그러니 진짜 질문은 "어느 도구가 제일 좋냐"가 아닙니다. 아무리 좋은 도구라도 한 시점만 본다면, 나머지 두 시점은 여전히 비어 있습니다. 진짜 질문은 **"세 시점을 다 덮고 있냐"**입니다. 그리고 그 위에서 "846규칙이 시점별로 빠짐없이 판정되고 있냐"입니다.

이 질문을 던지면, 점검의 성격이 바뀝니다. "우리 코드 검사 통과했어"가 아니라 "우리는 설계·운영·판단 중 어디를 보고 있고, 어디가 비어 있지?"를 묻게 됩니다. 그 빈자리를 인식하는 것만으로도 사고의 절반은 막힙니다. 오늘 사례의 기관들이 멈췄던 그 지점이, 사실은 "안 보고 있는 시점이 뭔지" 한 번도 안 물어봤기 때문에 생긴 것이니까요.

빈자리를 인식하기 어려운 진짜 이유

그런데 왜 이 빈자리를 인식하기가 그렇게 어려울까요. 단순히 게을러서가 아닙니다. 구조적인 이유가 있습니다. 사람은 자기가 보는 시점의 언어로만 생각합니다. 디자이너는 "이 화면 예쁘게 잘 나왔나"의 언어로, 개발자는 "코드 깨끗하게 잘 짰나"의 언어로, 기획자는 "사용자 흐름 매끄럽나"의 언어로 봅니다. 각자 자기 언어 안에선 빈틈없이 꼼꼼합니다. 문제는 그 언어 밖입니다. 디자이너에겐 ARIA 속성이라는 개념 자체가 잘 안 떠오르고, 개발자에겐 색상 토큰의 미묘한 차이가 잘 안 보입니다.

그래서 한 사람, 한 팀에게 "세 시점을 다 보세요"라고 요구하는 건 사실 무리한 주문입니다. 자기가 안 쓰는 언어로 된 영역은, 빠뜨려도 빠뜨린 줄을 모릅니다. 이걸 사람의 의지로 메우려 하면 늘 한계에 부딪힙니다. 그래서 필요한 게 "세 시점을 한 기준으로 묶어주는 도구"입니다. 사람이 일일이 시점을 갈아끼우지 않아도, 도구가 세 시점을 같은 846규칙으로 한 번에 훑어주는 것. 그러면 "내 언어 밖이라 못 본 영역"이 자동으로 채워집니다. 빈자리를 인식하는 부담 자체를, 사람에서 도구로 넘기는 발상입니다.

통과 도장이 아니라 추적 가능한 근거로

오늘 사례의 기관들이 받은 건 "통과"라는 결론뿐이었습니다. 그 결론이 어떤 근거 위에 서 있는지는 도장 어디에도 없었습니다. 그래서 통과 뒤에 뭐가 가려졌는지 알 길이 없었고, 가려진 데서 사고가 났습니다. 반대로 추적 가능한 근거가 남는 점검은 다릅니다. "이 사이트는 846규칙 중 무엇을 통과하고 무엇을 어겼으며, 각 판정이 어느 시점에서 어떻게 내려졌는지"가 다 기록으로 남습니다. 통과조차도 "왜 통과인지"가 보입니다.

이 차이는 나중에 진짜 크게 작용합니다. 문제가 생겼을 때 "왜 점검에서 안 걸렸지?"를 되짚을 수 있고, 다음 점검 때 "지난번보다 나아졌나"를 비교할 수 있고, 외부에 "우리는 이런 기준으로 이렇게 점검했다"고 설명할 수 있습니다. 도장 하나만 달랑 있는 점검은 이 중 아무것도 못 합니다. 근거가 남는 점검이라야, 점검이 일회성 행사가 아니라 쌓이는 자산이 됩니다.

846개라는 숫자가 "같은 잣대"를 보장한다

여기서 한 가지를 분명히 짚고 가겠습니다. 세 시점을 한 도구로 묶는다고 해서 자동으로 빈자리가 메워지는 건 아닙니다. 묶는 것보다 더 중요한 건 "세 시점이 같은 기준으로 판정되느냐"입니다. 디자인 검수의 통과 기준과 코드 검사의 통과 기준이 서로 다르면, 둘을 한 화면에 모아 놔도 여전히 사과와 오렌지를 비교하는 꼴입니다. 그래서 필요한 게 시점을 가로지르는 단일 기준이고, KRDS 846규칙이 바로 그 역할을 합니다.

846규칙은 그냥 막연한 권고 모음이 아니라, 디자인 스타일(DS) 120개, 컴포넌트(CP) 446개, 기본 패턴(BP) 108개, 서비스 패턴(SP) 172개로 영역이 또렷하게 나뉜 검증 항목입니다. 오늘 첫 번째 기관이 놓친 "설계와 배포본의 차이"는 DS·CP 규칙으로 잡히고, 두 번째 기관이 메인만 봐서 놓친 "깊은 페이지의 깨진 흐름"은 사이트 전체에 같은 BP·SP 규칙을 적용해 잡힙니다. 세 번째 기관이 판단을 못 한 "그래서 뭐가 제일 급한가"는 같은 846규칙에 위험 등급을 매겨 답이 나옵니다. 세 사례가 전부 하나의 규칙 체계 위에서 설명되는 것입니다.

이게 왜 중요하냐면, 사람마다 "통과"의 기준이 달라지는 순간 점검은 신뢰를 잃기 때문입니다. 어제 A가 본 통과와 오늘 B가 본 통과가 다른 잣대라면, 그 통과는 비교도, 추적도, 설명도 안 됩니다. 846규칙으로 통일하면 누가 언제 어느 페이지를 보든 같은 항목, 같은 기준으로 판정됩니다. 규칙 위반이라는 결과는 보는 사람에 따라 달라지지 않습니다. 오늘 사례의 기관들이 받은 통과 도장들이 서로 말이 안 통했던 건, 도장마다 잣대가 달랐기 때문입니다. 846규칙은 그 잣대를 하나로 묶습니다.

본론 5 — 그래서 세 시점이 한 보고서로 합쳐지면

흩어진 통과가 아니라 하나의 결론

오늘 사례들이 공통으로 겪은 또 하나의 문제가 있습니다. 통과든 위반이든, 결과가 흩어져 있었다는 것입니다. 디자인 검수 결과 따로, 코드 검사 결과 따로, (봤다면) 운영 점검 결과 따로. 이걸 모아서 "그래서 우리 사이트 상태가 종합적으로 어떻다"로 만드는 건 또 사람 몫이었습니다. 결과를 보고서로 옮겨 적느라 밤새는 "보고 변환" 병목입니다.

ViewCheck가 세 시점을 한 도구에 묶은 이유 중 하나가 바로 이것입니다. 흩어진 통과/위반을 하나의 보고서로 합쳐, 사람이 읽을 수 있는 결론으로 내놓습니다. 운영 시점에서 모은 실제 화면의 규칙 판정, 다중 페이지 일관성, 그리고 판단 시점에서 정리한 위험 등급과 개선 권고가 한 문서에 층층이 담깁니다. 임원이 30초 만에 핵심을 잡는 요약부터, 실무자가 그대로 작업에 착수할 상세 항목까지요.

모든 숫자가 근거로 거슬러 올라간다

중요한 건, 이 보고서의 모든 숫자가 "왜 그런지"로 추적된다는 것입니다. 준수율 숫자를 클릭하면 어떤 규칙이 통과고 미통과인지 나오고, 미통과 항목을 클릭하면 어느 페이지의 어떤 요소가 왜 걸렸는지, 어떻게 고치면 되는지가 나옵니다. 결론에서 근거로, 끝까지 내려갑니다.

오늘 사례의 기관들이 받았던 "통과"는 이 추적이 안 됐습니다. "통과"라는 결론만 있고, "왜 통과인지", "무엇을 안 본 통과인지"가 없었습니다. 그러니 통과 도장 뒤에 뭐가 가려졌는지 알 수 없었고, 가려진 데서 민원이 났습니다. 추적되는 보고서는 이 가림막을 걷어냅니다. 통과면 왜 통과인지, 위반이면 어디가 왜 위반인지가 다 보이니까, "안 본 영역"이 숨을 곳이 없습니다.

보고서가 두 부류의 독자를 동시에 만족시키려면

종합 보고서를 잘 만든다는 건 생각보다 까다롭습니다. 보고서를 읽는 사람이 한 부류가 아니기 때문입니다. 한쪽엔 의사결정을 하는 임원·관리자가 있습니다. 이분들은 시간이 없고, "그래서 우리 사이트 상태가 괜찮은가, 뭐가 제일 급한가"라는 결론을 빠르게 원합니다. 다른 한쪽엔 실제로 손을 댈 실무자·개발자가 있습니다. 이분들은 "어느 페이지의 어떤 요소를 어떻게 고치라는 건지" 구체적인 지시를 원합니다. 같은 보고서가 이 두 부류를 동시에 만족시켜야 합니다.

그래서 좋은 보고서는 층으로 쌓입니다. 맨 위엔 임원이 30초에 핵심을 잡는 요약, 그 아래엔 영역별 진단, 가장 아래엔 실무자가 그대로 작업에 쓰는 위반 상세와 수정 방법. 위에서 아래로 내려갈수록 추상에서 구체로 좁혀집니다. 임원은 위만 봐도 되고, 실무자는 아래까지 파고들면 됩니다. 한 문서 안에서 두 독자가 각자 필요한 깊이만큼만 읽을 수 있습니다. 오늘 사례의 기관들이 받은 흩어진 통과 도장들은, 이 중 어느 독자도 제대로 만족시키지 못했습니다. 임원에겐 결론이 흩어져 있었고, 실무자에겐 "그래서 뭘 어떻게"가 없었으니까요.

한 번 보고 끝이 아니라 쌓이는 점검으로

마지막으로, 추적 가능한 보고서의 또 다른 가치는 "비교"에 있습니다. 같은 기준으로 점검한 기록이 쌓이면, "지난번보다 나아졌나"를 숫자로 답할 수 있습니다. 리뉴얼 직후엔 준수율이 몇이었고, 1차 개선 후엔 몇으로 올랐고, 어떤 영역이 좋아지고 어떤 영역이 제자리인지가 추이로 보입니다. 점검이 일회성 행사가 아니라, 사이트 품질을 관리하는 연속적인 활동이 되는 것입니다.

오늘 사례의 기관들에게 가장 아쉬웠던 게 이 부분입니다. 그들의 "통과"는 그 순간의 도장일 뿐, 다음과 비교할 기준점이 되지 못했습니다. 만약 추적 가능한 점검 기록이 있었다면, 민원이 터졌을 때 "어디서부터 어긋났는지"를 되짚고, 고친 뒤 "정말 나아졌는지"를 확인하고, 다음 개편 땐 "지난 실수를 반복하지 않았는지"를 검증할 수 있었을 것입니다. 이 추이 관리는 11개월차의 정기진단·성과 증명 주제에서 깊게 다룰 예정입니다.

오픈 전 마지막 관문에 "실물 점검"을 넣자

오늘 사례에서 배울 수 있는 가장 실용적인 교훈 하나로 이 절을 마무리하겠습니다. 리뉴얼 절차에 관문 하나를 추가하는 것입니다. 오픈 전, 실제 배포 환경의 화면을 사이트 전체에 걸쳐 자동 분석하는 관문. 디자인 검수와 코드 검사 사이 어딘가가 아니라, 모든 작업이 끝나고 "이제 열기만 하면 되는" 그 시점에 넣는 게 핵심입니다. 그래야 시안과 실물의 간극, 개발 중 새로 생긴 문제까지 다 잡힙니다.

이 관문은 비용도 거의 안 듭니다. URL 하나 넣고 결과를 확인하는 일이니까요. 반면 이 관문이 없어서 치르는 비용은 큽니다. 오픈 후 민원 대응, 긴급 수정, "돈 들여 개편했는데 더 불편해졌다"는 신뢰 손실. 오늘 사례의 기관이 치른 그 비용입니다. 검수 절차에 한 줄 추가하는 것으로 그 비용을 막을 수 있다면, 하지 않을 이유가 없습니다.

이 관문에서 확인할 것을 오늘 사례에 비춰 정리하면 세 가지입니다. 첫째, 실물 확인 — 시안이 아니라 배포 환경의 실제 화면이 기준에 맞는가. 데스크톱만이 아니라 태블릿·모바일 크기까지. 둘째, 전수 확인 — 메인만이 아니라 신청·로그인·안내 등 사용자가 실제 업무를 보는 깊은 페이지까지. 셋째, 판정 확인 — "통과했다"가 아니라 "846개 중 무엇이 통과이고 무엇이 위반이며, 위반 중 P0가 몇 건인가"라는 근거 있는 숫자로. 이 세 가지가 다 확인됐을 때만 오픈 버튼을 누르는 걸 규칙으로 삼으면, 오늘 글에서 본 세 가지 함정이 절차 수준에서 봉쇄됩니다. 외주 사업이라면 이 세 가지를 검수 조건으로 계약서에 명시하는 것도 방법입니다. "KRDS 846규칙 기준 P0 위반 0건 상태로 인도"처럼 검수 기준이 숫자로 적혀 있으면, 발주처와 수행사 사이의 "통과" 다툼 자체가 사라집니다.

그래서 ViewCheck는

세 사례를 쭉 보면 결론이 같습니다. 어느 도구가 좋냐가 아니라, 세 시점을 다 덮고 있냐가 진짜 질문입니다. ViewCheck가 URL·Figma·LLM 세 방법을 한 도구에 묶은 건, 한 시점만 보다 새는 그 빈틈을 안 만들려는 것입니다.

구체적으로 사례에서 새던 자리를 ViewCheck가 어떻게 메우는지 정리하면 이렇습니다. 첫 번째 기관이 놓친 "실물 화면"은 URL 분석(운영 시점)이 실제 화면을 띄워 보며 메웁니다. 두 번째 함정인 "메인만 보기"는 다중 페이지 분석이 사이트 전체를 돌며 메웁니다. 세 번째 기관이 멈췄던 "판단 없음"은 LLM 분석(판단 시점)이 위험 등급과 개선안으로 메웁니다. 그리고 이 모든 판정의 기준은 KRDS 846규칙으로 통일돼 있어서, 누가 보든 어느 페이지든 같은 잣대가 적용됩니다. 사례에서 새던 자리를 정확히 하나씩 메우는 구조입니다.

이게 거창한 기술 자랑이 아니라는 건 분명히 해두고 싶습니다. 그냥 한 시점만 보면 반드시 다른 데서 새니까, 그 빈 곳을 안 만들려는 것뿐입니다. 사례들이 보여준 건, 빈 곳은 늘 "내가 안 보는 시점"에 생긴다는 사실입니다.

한 가지 덧붙이면, 세 시점을 한 도구에서 본다는 건 단순히 "편하다"의 문제가 아닙니다. 도구를 따로 쓰면 결과를 합치는 과정에서 또 누락과 편차가 생깁니다. 디자인 검수 결과의 "통과"와 코드 검사의 "통과"가 같은 기준의 통과인지 아닌지조차 불분명합니다. 도구마다 잣대가 다르니까요. 그런데 세 시점을 한 도구가 같은 846규칙으로 보면, 모든 판정이 하나의 기준 위에 섭니다. "이 시점에선 통과인데 저 시점에선 위반"이라는 간극이, 같은 화면 안에서 한눈에 드러납니다. 오늘 사례의 핵심이었던 "시점 간 간극"이, 합치는 수고 없이 저절로 보이는 것입니다. 이게 시점을 묶는 진짜 이유입니다.

🔐 특허로 지키는 부분

오늘 본 "설계는 통과인데 배포본은 위반"을 잡아내고, 흩어진 통과를 시점별로 교차 비교하는 방법은 ViewCheck가 출원한 특허 중 시점 비교(설계·운영 교차 검증) 및 위험 등급화(P0~P3) 주제와 닿아 있습니다. 통과/미통과를 도구별로 따로 받는 건 누구나 하지만, 시점 간 간극을 교차로 잡아내고 위반에 등급을 매겨 행동 순서로 바꾸는 절차를 하나의 권리로 정리해 둔 것이 차별점입니다.

다만 월요일에 짚었던 것과 같은 단서를 오늘도 답니다. 특허는 "방법을 지키는 장치"지 "품질 보증서"가 아닙니다. 오늘 사례에서 빈틈을 메운 건 특허 그 자체가 아니라, 세 시점을 실제로 다 보는 분석 방식입니다. 특허는 그 방식을 보호할 뿐입니다. 그래서 "특허 있으니 믿으세요"가 아니라 "이 방법을 직접 만들고 지켜두었다"로 받아들여 주시면 됩니다. (특허 출원 기술 / 자체 개발)

마무리

"검수 통과했는데 왜 민원이 들어오죠?"의 답은 대개 같습니다. 통과를 준 사람들은 각자 자기 시점에선 정직했는데, 그 통과들의 합이 전체의 통과는 아니었던 거죠. 디자인은 설계를 봤고, 코드 검사는 코드 일부를 봤지만, 정작 사용자가 마주하는 실물 화면은 아무도 안 봤습니다. 봤더라도 메인만 봤거나, 데이터만 쌓고 판단을 안 했습니다. 빈자리는 늘 "안 보는 시점"에 생겼습니다.

그러니 통과 도장을 받았을수록 오히려 한 번 더 물어야 합니다. "그럼 우리가 안 본 시점은 누가 봤지?" 이 질문 하나가 오픈 후 터질 민원 하나를 막습니다. 그리고 그 질문에 "세 시점을 다, 846규칙으로, 사이트 전체에 걸쳐 봤다"고 답할 수 있을 때, 비로소 통과는 진짜 통과가 됩니다.

한 가지만 더 당부드리고 싶습니다. 오늘 사례를 읽고 "그럼 우리도 큰일 났겠네" 하고 불안해하실 필요는 없습니다. 중요한 건 지금 우리 점검이 세 시점 중 어디를 보고 있는지를 한 번 솔직하게 점검해 보는 것입니다. 세 개 다 완벽하게 보라는 게 아닙니다. 우리 상황에 맞는 무게중심을 잡되, "안 보는 시점이 비어 있다는 사실"만큼은 인식하고 가자는 것입니다. 그 인식 하나가, 오늘 사례의 기관들과 우리를 가르는 지점입니다. 그들은 빈자리가 있는 줄도 몰랐고, 우리는 알고 있으면 됩니다.

금요일엔 한 발 더 나아가서, "그래서 우리 상황에선 언제 무엇을 보면 되는지"를 상황별 선택 가이드로 정리하겠습니다. 새로 만들 때, 운영 중인 걸 점검할 때, 정기적으로 관리할 때 — 세 시점의 무게중심이 어떻게 달라지는지를 한 장으로 묶어 보겠습니다. 오늘이 "왜 한 시점만 보면 안 되는가"였다면, 금요일은 "그래서 우리는 구체적으로 뭘 하면 되는가"의 실무 결론입니다.

그리고 지금 당장 궁금하시다면 — 우리 사이트의 현재 상태를 확인하는 데는 URL 한 줄이면 됩니다. 리뉴얼을 앞두고 있다면 개편 전 기준선을 재는 용도로, 리뉴얼을 막 마쳤다면 오늘 글에서 말씀드린 "오픈 전 마지막 관문"의 용도로, 지금 바로 써보실 수 있습니다.

오늘도 끝까지 읽어주셔서 고맙습니다. 금요일에 이번 주를 정리하며 만나요.

krds.viewcheck.co.kr