코드 검사 한 번 돌리고 안심하셨나요? — 공공 웹 품질을 보는 세 가지 시점, 그리고 KRDS를 제대로 보는 법

들어가며 — "점검했다"는 안도감이 가장 위험할 때

공공 웹사이트 담당자분들께 "우리 사이트 KRDS 점검, 어떻게 하고 계세요?"라고 여쭤보면 대답이 크게 두 갈래로 나뉩니다. 하나는 "담당자가 체크리스트 들고 직접 봅니다"이고, 다른 하나는 "검사 도구 돌려봤는데 별문제 없다고 나왔어요"입니다.

첫 번째 방식의 한계는 분명합니다. KRDS 점검 항목은 846개나 되고, 봐야 할 페이지는 수십에서 수백 장입니다. 인력은 부족하고, 시간은 모자라고, 보는 사람마다 기준이 흔들립니다. 분명히 봤다고 생각한 항목인데 정작 중요한 걸 놓칩니다. 846개나 되는 규칙을, 그것도 수십 수백 페이지에 걸쳐, 매번 같은 기준으로 사람이 일일이 본다는 건 애초에 무리한 요구입니다. 사람의 눈은 세 페이지째부터 무뎌지고, 스무 페이지째부터는 "아까 본 것 같은데"가 됩니다.

그래서 자연스럽게 두 번째 방식으로 넘어갑니다. "그럼 자동화하면 다 되는 거 아닌가요?"

반은 맞고 반은 틀립니다. 자동화는 분명 답입니다. 사람이 못 하는 일을 기계가 대신 해주니까요. 그런데 여기에 또 다른 함정이 숨어 있습니다. 자동화 도구도 "하나만" 보면, 사람이 하나만 보던 것과 똑같이 절반만 봅니다. 도구를 바꿨을 뿐, 사각지대는 그대로 남습니다.

현장에서 정말 자주 보는 장면이 있습니다. 무료 코드 검사 도구를 한 번 쫙 돌려보고 "오, 별문제 없네" 하고 안심하는 모습입니다. 화면에 "오류 0건"이 뜨면 점검을 끝냈다는 안도감까지 생깁니다. 그런데 그 도구가 본 건 사실 전체 그림의 일부입니다. 코드는 멀쩡한데 화면에선 깨져 있을 수 있고, 운영 중인 사이트는 멀쩡한데 애초에 설계가 어긋나 있을 수도 있습니다. 한 군데만 보고 "괜찮다"고 결론 내리면, 안 본 데서 문제가 터집니다. "봤다고 생각했는데 놓친" 그 패턴이, 자동화로 넘어와서도 똑같이 반복되는 셈입니다.

조금 더 구체적으로 말씀드리겠습니다. 자동화 도구는 보통 자기가 잘 보는 한 가지 영역에 특화돼 있습니다. 어떤 건 HTML 코드 구조를 잘 보고, 어떤 건 성능 수치를 잘 재고, 어떤 건 접근성 속성을 잘 잡습니다. 각자 자기 영역에선 정확합니다. 문제는 그 영역 밖입니다. 접근성 도구는 성능을 안 보고, 성능 도구는 디자인 표준을 안 보고, 코드 검사 도구는 실제 화면이 어떻게 보이는지를 안 봅니다. 그러니 도구 하나의 "통과"는 "그 도구가 보는 범위 안에서의 통과"일 뿐입니다. 그 범위가 전체의 몇 퍼센트인지는, 정작 도구를 돌린 사람도 잘 모릅니다. "오류 0건"이라는 초록색 글자가 주는 안도감이 너무 커서, 그 뒤에 안 본 영역이 얼마나 넓은지를 묻지 않게 되는 것이죠.

그리고 공공 웹사이트는 이 함정에 특히 취약합니다. 페이지가 많고, 외주·재개발을 거치며 만든 사람이 계속 바뀌고, 옛날 페이지와 새 페이지가 한 사이트에 뒤섞여 있습니다. 메인 페이지는 최근에 KRDS 기준으로 깔끔하게 다시 만들었는데, 3년 전에 만든 민원 신청 페이지는 그대로 방치돼 있는 식입니다. 코드 검사 도구로 메인만 돌려보고 "통과"라고 하면, 정작 사용자가 실제 업무를 보는 깊은 페이지는 한 번도 점검 안 된 채로 남습니다. 이게 공공 웹에서 "분명히 점검했는데 민원이 들어오는" 전형적인 구조입니다.

오늘은 한 발 물러서서 이야기해 보려 합니다. 웹 품질을 제대로 보려면 "언제, 어디서 보느냐"라는 시점이 세 개 있다는 것. 이 세 시점을 다 봐야 비로소 전체가 보인다는 것. 이게 앞으로 1년간 풀어갈 이 시리즈의 큰 그림이기도 합니다. ViewCheck가 분석 방법을 세 가지(URL·Figma·LLM)나 갖춘 이유도 정확히 여기에 있습니다. 한 가지를 잘하려고 만든 게 아니라, 세 시점을 빠짐없이 덮으려고 그렇게 설계했습니다.

오늘 글에서는 그 세 시점이 각각 무엇을 보고 무엇을 못 보는지, 왜 하나만으론 부족한지, 그리고 그 위에서 KRDS 846규칙이 어떻게 판정되는지를 차분히 짚어보겠습니다. 구체적으로 "우리 상황에선 언제 뭘 쓰면 되는지"는 이번 주 금요일 글에서 상황별 가이드로 정리하겠습니다.

URL 하나로 분석을 돌리면 나오는 ViewCheck 종합 화면. 상단 점수 카드(전체/디자인스타일/컴포넌트/기본패턴/서비스패턴)부터 카테고리별 위반 TOP, 레이더·추이 그래프까지 한 화면에 펼쳐진 모습. 오늘 이야기할 "운영 시점"의 결과물 (기관명·도메인 블러)

본론 1 — 웹 품질을 보는 세 가지 시점

왜 "시점"이 나뉘는가

같은 웹사이트라도, 그걸 보는 타이밍과 관점에 따라 보이는 게 완전히 다릅니다. 설계도 단계에서만 보이는 문제가 있고, 다 지어놓고 실제로 들어가 봐야 보이는 문제가 있고, 사람이 직접 써보면서 "이건 좀 이상한데?" 하고 느끼는 문제가 있습니다.

건물에 비유하면 이해가 쉽습니다. 도면에서 잡는 하자, 준공 후 현장에서 잡는 하자, 입주민이 살아보고 발견하는 하자. 셋은 종류가 다르고, 잡는 방법도 다르고, 잡을 수 있는 사람도 다릅니다. 도면 하자는 설계자가 도면을 보고 잡고, 준공 하자는 감리가 현장에서 잡고, 생활 하자는 입주민이 살면서 잡습니다. 어느 하나만으로는 건물 전체가 안전하다고 말할 수 없습니다.

웹도 똑같습니다. 크게 세 시점으로 나뉩니다.

만들기 전 — 설계 시점. 디자인 단계에서 기준에 맞는지 봅니다.
만든 후 — 운영 시점. 실제로 돌아가는 사이트를 사용자 눈높이에서 봅니다.
그 위에서 — 판단·보강 시점. 기계적 규칙으로 딱 떨어지지 않는 부분을, 사람처럼 읽고 맥락으로 판단합니다.

이 셋을 ViewCheck의 언어로 바꾸면 각각 **Figma 분석(설계), URL 분석(운영), LLM 분석(판단)**이 됩니다. 용어는 다음 주부터 하나씩 깊게 풀 예정이니, 오늘은 "시점이 셋"이라는 큰 틀만 잡고 가시면 됩니다.

설계(도면)·운영(브라우저)·판단(AI 돋보기) 세 렌즈가 하나의 사이트로 수렴하는 개념 도식 (Gemini 1:1)

시점 ① 만들기 전 — 설계 단계에서 보기

첫 번째 시점은 사이트를 만들기 전, 디자인 단계입니다. 요즘은 대부분 Figma 같은 디자인 도구로 화면을 먼저 그립니다. 이 단계에서 기준을 맞춰보는 것이죠. 색이 KRDS 표준 색인지, 글자·간격이 규격에 맞는지, 버튼 같은 컴포넌트가 정해진 규격대로 그려졌는지를요.

왜 이 시점이 중요할까요. 고치는 비용이 가장 싸기 때문입니다. 디자인 단계에서 색 하나 바꾸는 건 클릭 몇 번입니다. 그런데 그게 개발까지 다 끝나고 배포된 다음에 발견되면 어떻게 될까요. 디자인을 고치고, 코드를 고치고, 다시 테스트하고, 다시 배포해야 합니다. 같은 문제인데 단계가 뒤로 갈수록 비용이 몇 배씩 뜁니다. 소프트웨어 업계에서 "결함은 늦게 발견될수록 비싸진다"는 건 거의 법칙에 가깝습니다.

실제로 이런 경우가 있었습니다. ㅇㅇ기관의 한 사업에서 버튼의 최소 크기가 KRDS 기준보다 작게 디자인돼 있었는데, 아무도 그걸 디자인 단계에서 못 잡았습니다. 그대로 개발됐고, 배포됐고, 모바일 사용자들이 "버튼이 작아서 자꾸 잘못 눌린다"고 했습니다. 그제야 발견했는데, 이미 수십 개 페이지에 같은 버튼이 깔린 뒤였습니다. 디자인 컴포넌트 하나 고쳤으면 끝났을 일이, 페이지마다 다시 손대는 일이 돼버렸습니다. 설계 단계에서 봤다면 정말 싸게 끝났을 문제입니다.

비용 이야기를 조금만 더 해보겠습니다. 흔히 "1:10:100 법칙"이라고 부르는 게 있습니다. 설계 단계에서 잡으면 1의 비용, 개발 단계에서 잡으면 10의 비용, 배포 후에 잡으면 100의 비용이 든다는 경험칙입니다. 정확한 숫자가 중요한 게 아니라 방향이 중요합니다. 같은 결함이라도 늦게 발견될수록 손대야 할 게 기하급수로 늘어납니다. 설계 단계에서는 디자인 파일의 컴포넌트 하나만 고치면 그걸 쓰는 모든 화면이 한꺼번에 고쳐집니다. 그런데 배포 후라면요? 각 페이지에 개별적으로 박혀버린 결과물을 하나하나 찾아 고쳐야 하고, 고친 뒤엔 다시 테스트하고, 다시 배포 검수를 받아야 합니다. 게다가 공공 사업은 검수·계약 절차가 끼어 있어서, "오픈 후 수정"은 단순한 코드 작업이 아니라 행정 절차까지 다시 도는 일이 됩니다. 그래서 설계 시점은 "가장 싼 보험"입니다. 가장 적은 노력으로 가장 큰 사고를 막습니다.

문제는, 이 설계 시점을 제대로 보려면 디자인 파일을 KRDS 기준에 비춰 일일이 대조해야 한다는 것입니다. 색상 토큰이 맞는지, 글자 크기 단계가 맞는지, 컴포넌트 규격이 맞는지. 이걸 사람이 눈으로 하면 앞서 말씀드린 그 한계 — 누락과 편차 — 에 다시 부딪힙니다. 그래서 설계 시점도 자동화가 필요합니다. ViewCheck의 Figma 분석이 바로 이 역할입니다. 디자인 파일을 읽어서 KRDS 기준과 자동으로 대조하고, 어긋난 곳을 짚어줍니다.

다만 이 시점만으로는 한계가 분명합니다. 디자인은 어디까지나 "의도"입니다. 그 의도가 실제 코드로 옮겨질 때 그대로 구현된다는 보장이 없습니다. 디자인에선 버튼이 충분히 컸는데 개발하면서 작아질 수도 있고, 디자인엔 없던 문제가 구현 과정에서 새로 생길 수도 있습니다. 그래서 설계 시점만 봐서는 "실제로 어떻게 돌아가는지"는 모릅니다. "우리 디자인은 기준에 맞다"를 막연한 자신감이 아니라 수치로 확인하고, 그다음엔 반드시 실물을 다시 확인해야 합니다.

시점 ② 만든 후 — 운영 중인 실물 보기

두 번째 시점은 다 만들어서 돌아가고 있는 사이트를 보는 일입니다. 사용자가 실제로 마주하는 화면이지요. 이게 가장 직관적인 시점입니다. 어차피 사용자는 디자인 파일을 보는 게 아니라 실제 사이트를 쓰니까요.

이 시점의 강점은 "진짜"를 본다는 것입니다. 실제로 렌더링된 화면, 실제 색, 실제 간격, 실제로 눌리는 버튼. 설계 의도가 아니라 결과물을 봅니다. 그래서 "디자인은 통과였는데 배포본은 위반"인 경우를 여기서 잡습니다. 이미지로 만든 버튼이나 모바일 화면 깨짐 같은 것도, 실제 화면을 봐야 잡히는 것들입니다. 코드만 봐서는 "버튼이 있다"는 사실은 알아도 "그 버튼이 실제 화면에서 어떻게 보이는지"는 모릅니다.

운영 시점이 강한 또 하나의 이유는, 사이트 전체를 사용자처럼 돌아다니며 볼 수 있다는 것입니다. 설계 파일은 보통 주요 화면 몇 개만 그려져 있습니다. 메인, 목록, 상세 정도. 그런데 실제 사이트엔 깊숙이 들어간 신청 페이지, 로그인 페이지, 옛날 안내 페이지까지 다 살아 있습니다. "본 적도 없는 페이지에서 사고가 난다"는 그 영역은, 운영 시점에서만 닿습니다. 그리고 이 영역이야말로 민원과 사고가 가장 많이 터지는 곳입니다.

여기서 ViewCheck가 운영 시점을 어떻게 다루는지 살짝 미리 보겠습니다. URL 하나를 넣으면, 메인 한 장만 보는 게 아니라 사이트를 자동으로 돌면서 여러 페이지를 수집합니다. 수십 페이지, 필요하면 백 페이지 넘게도 수집합니다. 그리고 각 페이지마다 KRDS 846규칙을 판정합니다. 한 페이지라도 위반이 있으면 그건 사이트 전체의 문제로 집계됩니다. "메인은 통과인데 신청 페이지에서 무너지는" 경우를 놓치지 않으려는 설계입니다.

이 운영 시점에서 ViewCheck가 실제로 들여다보는 영역은 생각보다 넓습니다. 단순히 "규칙 위반"만 보는 게 아닙니다. 같은 화면을 데스크톱·태블릿·모바일 세 개 크기로 띄워 보면서 레이아웃이 깨지지 않는지(반응형 품질), 페이지가 얼마나 빨리 뜨는지와 화면이 갑자기 밀리지 않는지(성능, Core Web Vitals), 검색엔진과 접근성 보조기기가 페이지 구조를 제대로 읽을 수 있는지(SEO·시맨틱 구조), 보안 헤더와 인증서가 제대로 설정됐는지(보안·신뢰성)까지 한 번에 봅니다. 분석이 끝나면 이 결과들이 스무 개가 넘는 영역별 화면으로 정리됩니다. 규칙 검증, 접근성, 반응형, 성능, 보안, 인사이트, 임원 보고서, 비용 산출까지. 사용자가 실제로 마주하는 화면에서 일어나는 거의 모든 일을, 운영 시점 한 번의 분석으로 훑는 셈입니다. 이 각각의 영역이 앞으로 1년간 차례로 다룰 주제들입니다.

왜 이렇게 넓게 보느냐면, 행정안전부의 「전자정부 웹사이트 품질관리 지침」이 요구하는 품질 영역 자체가 넓기 때문입니다. 호환성, 접근성, 개방성, 접속성, 편의성, 효율성, 신뢰성. 이 일곱 가지 영역은 어느 하나도 코드 한 줄만 봐서는 판정이 안 됩니다. 접속성(응답 시간)이나 효율성(로딩 성능), 신뢰성(SSL 인증서·보안 헤더) 같은 건 실제로 브라우저로 사이트에 접속해서 요청을 보내봐야 측정됩니다. 그래서 이 영역들은 본질적으로 운영 시점의 일입니다. 실물에 직접 들어가 봐야만 보이는 것들이라서요.

예를 들어 ViewCheck는 같은 화면을 데스크톱·태블릿·모바일 세 뷰포트로 실제로 띄워 보고, 터치 타겟이 기준(44×44px)보다 작은 곳을 잡아냅니다. 앞서 말씀드린 "버튼이 작아 잘못 눌린다"는 민원이, 여기서는 오픈 전에 수치로 잡히는 것입니다.

그런데 이 시점도 단독으로는 약점이 있습니다. 이미 다 만들어진 다음이라는 것입니다. 여기서 문제를 발견하면 고치는 비용이 이미 커져 있습니다. 그리고 화면을 기계적으로 보는 것만으로는 "이게 사용자한테 얼마나 치명적인지", "맥락상 이게 진짜 문제인지"까지는 판단하기 어렵습니다. 규칙은 어겼는데 의도된 예외일 수도 있으니까요. 위반 200건을 찾아내는 것과, 그 200건 중 뭐가 진짜 급한지를 가려내는 건 다른 일입니다.

시점 ③ 그 위에서 — 사람처럼 읽고 판단하기

세 번째 시점은 좀 다릅니다. 앞의 두 시점이 "기준에 맞나 안 맞나"를 본다면, 세 번째는 그 위에서 "그래서 이게 무슨 의미인가"를 봅니다. 기계적인 규칙으로 딱 떨어지지 않는 영역을 사람처럼 읽고 판단하는 단계입니다.

예를 들어 규칙상으로는 N/A(해당 없음)로 빠지는 항목이 있습니다. 코드만 봐서는 판단이 안 되는 것들이지요. 이미지로 만든 버튼이 대표적입니다. 코드에는 그냥 이미지 태그로만 보이니까 규칙 엔진은 "버튼이 없다"고 보고 N/A로 넘깁니다. 그런데 사람이 화면을 보면 "아, 이건 명백히 버튼으로 쓰이고 있으니 버튼 규칙을 적용해야지" 하고 채울 수 있습니다. 또 위반이 여러 개 나왔을 때 "뭐부터 고쳐야 하는지" 우선순위를 매기는 것, "이건 이렇게 고치면 된다"고 구체적인 방법을 제시하는 것도 이 시점의 일입니다.

ViewCheck의 LLM 분석이 바로 이 시점을 맡습니다. 그리고 이 판단 시점은 일방적인 보고서가 아니라 대화로도 작동합니다. 분석 결과를 펼쳐놓고 "이 위반이 왜 문제죠?", "우리 사이트에서 제일 급한 것부터 알려주세요"라고 물으면, 분석 데이터를 근거로 답을 줍니다. 중요한 건 그 답이 허공에서 나오는 게 아니라는 점입니다. 답변 옆에 어떤 규칙, 어떤 판정 결과를 근거로 했는지가 함께 붙습니다. 궁금한 부분은 그 자리에서 다시 분석을 돌려 확인할 수도 있습니다. "AI가 그럴듯하게 말하는 것"과 "분석 데이터를 근거로 말하는 것"의 차이가 여기서 갈립니다.

다만 이 시점도 혼자서는 안 됩니다. 앞의 두 시점이 정확한 데이터를 깔아줘야, 그 위에서 판단이 의미가 있습니다. 토대가 부실하면 그 위의 판단도 부실해집니다. AI가 아무리 그럴듯해도, 잘못 수집된 화면을 보고 판단하면 결론도 틀립니다.

코드만으로 판단하지 못해 N/A로 빠졌던 항목을 AI 분석이 pass/fail로 채워 넣은 화면. 규칙 엔진(운영 시점)이 깐 토대 위에 판단 시점이 얹히는 구조 (기관명·도메인 블러)

세 시점은 경쟁이 아니라 분업

여기서 오해하지 말아야 할 게 있습니다. 이 셋은 "어느 게 제일 좋냐"를 따지는 경쟁 관계가 아닙니다. 각자 보는 게 다른 분업 관계입니다. 설계 시점은 싸게 미리 잡고, 운영 시점은 진짜 결과물을 잡고, 판단 시점은 그 위에서 의미를 더합니다. 셋이 합쳐져야 비로소 "전체"가 보입니다.

코드 검사 도구 하나만 돌리고 안심하는 게 왜 위험한지, 이제 좀 보이실 겁니다. 그건 세 시점 중 운영 시점의, 그것도 일부만 본 것입니다. 나머지는 안 본 채로 "괜찮다"고 결론 내린 셈이지요. "검사 통과"가 "전체 통과"가 아닌 이유가 여기 있습니다.

본론 2 — 세 시점 위에서 KRDS 846규칙은 어떻게 판정되나

여기서 잠깐, 시점 이야기와 KRDS를 연결해 보겠습니다. 세 시점은 "언제 보느냐"의 틀이고, KRDS 846규칙은 "무엇을 기준으로 보느냐"의 내용입니다. 둘은 따로 노는 게 아니라 겹쳐서 작동합니다.

KRDS 846규칙이란 무엇인가

KRDS(Korea Government Design System)는 행정안전부가 만든 대한민국 정부 디자인 시스템입니다. 공공 웹사이트가 일관된 모양과 사용 경험을 갖도록 색, 글꼴, 간격, 컴포넌트, 화면 패턴 같은 걸 표준으로 정해놓은 것입니다. ViewCheck는 이 KRDS를 846개의 판정 가능한 규칙으로 정리해서 자동으로 검사합니다. 846개는 크게 네 묶음으로 나뉩니다.

디자인 스타일(DS, 120개) — 색·타이포·간격·레이아웃 같은 시각 기초입니다. "이 색이 표준 토큰 색인가", "글자 크기가 규격 안에 드나", "간격이 정해진 그리드를 따르나"를 봅니다. KRDS는 수백 개의 색상 토큰과 정부 전용 서체, 간격 체계를 정의해 두었는데, DS 규칙은 실제 화면이 이 토큰들을 얼마나 충실히 따르는지를 봅니다. 눈으로 보면 "비슷한 파란색"이지만, 토큰 기준으로 보면 표준색이 아닐 수 있습니다. 이런 미세한 차이를 사람 눈으로 잡는 건 거의 불가능합니다.
컴포넌트(CP, 446개) — 버튼·입력창·헤더·푸터·모달·카드 같은 UI 부품입니다. 846개 중 가장 큰 묶음입니다. "이 버튼에 접근성 속성(ARIA)이 제대로 붙었나", "입력창에 라벨이 연결돼 있나", "구조가 규격대로인가"를 봅니다. 공공 웹은 화면을 못 보는 사용자도 보조기기로 쓸 수 있어야 하는데, 그걸 가능하게 하는 게 바로 이 ARIA 같은 코드 속성입니다. 그런데 이건 화면만 봐서는 절대 안 보입니다. 버튼이 멀쩡히 보여도, 코드 속에 라벨이 없으면 시각장애인 사용자에겐 "이름 없는 버튼"이 됩니다.
기본 패턴(BP, 108개) — 폼 구조, 동의·확인, 오류 처리, 필터·정렬 같은 기본 동작 패턴입니다. 예를 들어 "필수 입력란을 빈칸으로 두고 제출하면 어디가 틀렸는지 친절하게 알려주는가", "동의 체크박스가 규격대로 배치돼 있는가" 같은 걸 봅니다. 화면 한 장이 아니라 "흐름"을 보는 규칙들입니다.
서비스 패턴(SP, 172개) — 로그인·검색·신청·정책 같은 서비스 흐름 패턴입니다. 공공 웹의 핵심 업무(민원 신청, 정보 검색, 로그인)가 KRDS가 권장하는 흐름대로 설계됐는지를 봅니다. 이건 페이지 한 장이 아니라 여러 단계를 거치는 시나리오라서, 판정도 가장 까다롭습니다.

이 네 묶음이 합쳐져 846개입니다. 이 숫자가 중요한 이유는, "막연히 KRDS를 본다"가 아니라 "846개를 빠짐없이, 같은 기준으로 본다"는 약속이기 때문입니다. 사람이 손으로 할 때 가장 무너지던 부분, 즉 누락과 편차를 숫자로 못 박아 둔 셈이죠. 점검자가 누구든, 몇 번째 페이지든, 같은 846개의 잣대가 똑같이 적용됩니다. 이게 "감으로 보는 점검"과 "기준으로 보는 점검"의 결정적 차이입니다.

846규칙이 DS·CP·BP·SP 네 묶음으로 나뉘어 하나의 준수율 게이지로 모이고, 규칙 엔진(기어)과 시각 AI(눈) 두 엔진이 각 칸에 pass/fail을 찍는 개념 도식 (Gemini 1:1)

실제 화면에서도 이 846규칙 검증 결과는 목록으로 펼쳐집니다. 어떤 규칙이 통과(pass)고, 미통과(fail)고, 해당 없음(N/A)인지 한눈에 보입니다. "감으로 A등급"이 아니라, 규칙 하나하나의 판정으로 점수가 쌓이는 구조입니다.

846규칙 검증 결과 목록 화면. 규칙별로 통과/미통과/해당없음 판정이 카테고리별로 정리된 모습 (기관명·도메인 블러)

규칙마다 "보는 시점"이 다르다

여기가 핵심입니다. 846개 규칙이 다 같은 방식으로 판정되는 게 아닙니다. 어떤 규칙은 코드(DOM)만 봐도 판정되고, 어떤 규칙은 실제 화면을 봐야 판정되고, 어떤 규칙은 사람처럼 맥락을 읽어야 판정됩니다. 즉, 규칙마다 적합한 "시점"이 다릅니다.

DS의 색·간격은 실제로 렌더링된 화면의 computed style(브라우저가 최종 계산한 실제 값)을 봐야 정확합니다 → 운영 시점.
CP의 ARIA 속성 같은 건 코드 구조를 봐야 잡힙니다. 사람 눈으로는 화면만 봐서는 ARIA가 붙었는지 알 수 없습니다 → 운영 시점(코드 측면).
이미지로 만든 비표준 버튼, 시각적으로만 구분되는 요소는 코드로 안 잡힙니다 → 판단 시점(AI 보강).
설계 단계에서 미리 거를 수 있는 컴포넌트 규격은 → 설계 시점(Figma).

그래서 ViewCheck는 두 개의 엔진을 함께 씁니다. 하나는 규칙 엔진입니다. 코드(DOM) 데이터를 받아 846규칙 중 무엇을 위반했는지 정해진 논리로 판정합니다. 빠르고(수 초 안에) 일관됩니다. 다른 하나는 시각 AI 엔진입니다. 스크린샷을 보고, 코드로는 못 잡는 시각적 컴포넌트를 감지하고, 규칙 엔진이 N/A로 넘긴 항목을 pass/fail로 채웁니다.

이 둘은 보조 관계가 아니라 분업 관계입니다. 규칙 엔진은 코드로 판정 가능한 영역(ARIA, CSS 속성, 구조)을 전담하고, 시각 AI는 코드로 절대 못 하는 영역(시각적 디자인, 비표준 UI)을 전담합니다. 그리고 충돌을 막는 원칙이 하나 있습니다. 코드가 pass/fail로 확정한 건 AI가 뒤집지 않습니다. AI는 N/A와 보류 항목만 채웁니다. 이래야 결과가 요동치지 않습니다. 이 두 엔진 이야기는 이번 달 마지막 주에 본격적으로 풀겠습니다.

왜 이런 역할 분담이 필요한지 한 번 더 짚어 보겠습니다. 만약 규칙 엔진 하나만 쓴다면, 코드로 잡히지 않는 위반은 전부 "해당 없음(N/A)"으로 빠집니다. 실제로 한 페이지를 분석해 보면 846개 중 적지 않은 규칙이 N/A로 떨어집니다. 그 페이지에 해당 컴포넌트가 아예 없어서 정당하게 N/A인 것도 있지만, "코드로는 판단이 안 돼서" N/A인 것도 섞여 있습니다. 후자를 그대로 두면 점검에 구멍이 생깁니다. 분명히 화면엔 버튼이 있는데, 코드상으론 이미지라서 "버튼 규칙 해당 없음"으로 처리돼 버리는 식입니다. 시각 AI는 바로 이 "코드로는 못 봐서 비워둔 칸"을 채우러 들어옵니다. 스크린샷을 보고 "이건 명백히 버튼이다"라고 감지해서, 비어 있던 판정을 pass나 fail로 메웁니다.

반대로, 만약 시각 AI 하나만 쓴다면 어떨까요. 이번엔 정확도와 속도가 문제입니다. AI가 화면을 보고 판단하는 건 강력하지만, 코드 속 ARIA 속성처럼 "보이지 않는 정보"는 화면만 봐서는 알 수 없습니다. 그리고 매 규칙을 AI로 판정하면 시간과 비용이 많이 듭니다. 그래서 빠르고 확실한 건 규칙 엔진이 코드로 처리하고, 그것만으로 안 되는 영역만 AI가 맡는 게 합리적입니다. "확실한 건 규칙으로, 애매한 건 AI로." 이 분업이 정확도와 효율을 동시에 잡는 구조입니다.

준수율이라는 숫자로 묶이는 과정

846개 규칙의 pass/fail/N/A가 모이면 준수율이라는 하나의 숫자가 나옵니다. 그런데 그냥 산술 평균이 아닙니다. 위반의 심각도에 따라 가중치가 다르게 들어갑니다. 접근성을 심각하게 해치는 위반과, 사소한 스타일 어긋남을 같은 무게로 셀 수는 없으니까요. 화면을 못 보는 사용자가 아예 버튼을 못 누르게 되는 치명적 위반과, 간격이 2px 어긋난 위반을 1:1로 세면, 점수가 현실을 못 담습니다. 그래서 ViewCheck는 위반을 위험도(P0~P3)로 등급화하고, 그 등급에 따라 점수에 다르게 반영합니다. P0(치명적)는 무겁게, P3(경미)는 가볍게. 이 가중치 산출 로직은 3개월차에서 자세히 다룹니다. 오늘은 "846규칙 → 시점별 판정 → 가중치 → 준수율"이라는 흐름만 기억해 두시면 됩니다.

여기서 한 가지 더 말씀드리겠습니다. 이 준수율이라는 숫자가 신뢰를 가지려면, 상단에 크게 뜨는 점수와 그 아래 세부 항목별 점수가 정확히 맞아떨어져야 합니다. 상단엔 "디자인 85%"라고 떠 있는데 세부 항목을 더해보니 48%가 나오면, 그 보고서는 한순간에 신뢰를 잃습니다. 그래서 ViewCheck는 점수가 한 곳에서만 계산되어 모든 화면으로 흐르도록 설계돼 있습니다. 보이는 모든 숫자가 같은 출처에서 나온다는 뜻입니다. 사소해 보이지만, 보고서를 받아 드는 사람 입장에선 이 일관성이 "이 도구를 믿어도 되나"를 가르는 지점입니다.

정리하면 이렇습니다. 세 시점은 "언제 보느냐"의 틀이고, 846규칙은 "무엇을 보느냐"의 내용이며, 두 엔진은 "어떻게 판정하느냐"의 방법입니다. 이 셋이 맞물려야 "감으로 A등급"이 아니라 "근거 있는 준수율"이 나옵니다. 그리고 그 준수율은 "왜 이 점수가 나왔는지"를 규칙 하나하나까지 거슬러 올라가 설명할 수 있어야 합니다. 설명되지 않는 점수는 숫자일 뿐, 근거가 아닙니다.

본론 3 — 세 시점이 하나의 보고서로 합쳐지는 곳

지금까지 시점과 규칙, 엔진을 따로따로 설명드렸는데, 실무자 입장에서 진짜 궁금한 건 이것일 겁니다. "그래서 이게 다 합쳐지면 뭐가 나오는데요?" 분석 결과가 흩어진 데이터 더미로 남으면, 결국 사람이 밤새 보고서로 옮겨 적는 "보고 변환" 병목이 또 생깁니다. 그래서 마지막 시점인 판단 시점의 가장 중요한 역할 중 하나가, 이 모든 걸 사람이 읽을 수 있는 한 장의 결론으로 묶는 것입니다.

데이터가 아니라 결론을 준다

세 시점에서 나온 결과를 그냥 나열하면 이렇습니다. "DS 위반 수십 건, CP 위반 수십 건, 반응형 터치타겟 미달 수십 곳, 로딩 성능 미달, 보안 헤더 누락…" 숫자는 정확합니다. 그런데 이걸 받은 담당자는 막막합니다. 뭐부터 봐야 하지? 이 중에 뭐가 진짜 급하지? 기관장님께는 뭐라고 보고하지?

판단 시점은 이걸 결론으로 바꿉니다. "이 사이트의 가장 큰 문제는 A이고, 그다음이 B다. A는 이런 사용자에게 이런 영향을 주며, 이렇게 고치면 된다. 예상 작업량은 이 정도다." 데이터를 행동 가능한 언어로 번역하는 것입니다. 위반 목록을 위험도순으로 정렬하고, 임원 보고용 요약을 만들고, 개선 우선순위를 매기고, 구체적인 수정 방법까지 붙입니다. 같은 데이터라도 "숙제 더미"가 아니라 "실행 계획"이 됩니다.

보고서 한 장에 세 시점이 다 들어간다

ViewCheck가 내놓는 종합 보고서를 펼치면, 사실상 세 시점이 다 담겨 있습니다. 운영 시점에서 모은 실제 화면의 규칙 판정, 설계 단계라면 디자인 대비 결과, 그리고 판단 시점에서 정리한 위험도와 개선 권고. 임원이 30초 만에 핵심을 잡을 수 있는 요약부터, 실무자가 그대로 작업에 착수할 수 있는 상세 항목까지 층층이 들어갑니다. 이걸 PDF로 뽑으면 그대로 보고 문서가 되고, 화면에서는 영역별 탭으로 나눠 깊게 팔 수 있습니다.

중요한 건, 이 보고서의 모든 숫자가 "왜 그런지"로 거슬러 올라간다는 점입니다. 준수율 숫자를 클릭하면 어떤 규칙이 통과고 어떤 게 미통과인지 나오고, 미통과 항목을 클릭하면 어느 페이지의 어떤 요소가 왜 걸렸는지, 어떻게 고치면 되는지가 나옵니다. 위에서 아래로, 결론에서 근거로, 끝까지 추적됩니다. 이게 "감으로 쓴 보고서"와 "근거로 쌓은 보고서"의 차이입니다.

보고를 받는 쪽 입장에서 이 차이는 생각보다 큽니다. 기관장이나 상급자가 "이 점수 근거가 뭐냐"고 물었을 때, "도구가 그렇게 뱉었습니다"라고 답하는 것과 "846개 규칙 중 이 항목들이 이 페이지에서 이렇게 걸렸고, 각 항목의 근거 화면이 여기 있습니다"라고 답하는 것. 앞의 답은 보고가 거기서 막히고, 뒤의 답은 바로 다음 논의(그래서 언제까지 뭘 고칠 것인가)로 넘어갑니다. 근거가 추적되는 보고서는 회의 시간을 줄이고, 담당자의 방어 부담도 줄입니다.

본론 4 — "하나만" 봤을 때 실제로 새는 것들

말로만 하면 와닿지 않으니, 한 시점만 봤을 때 실제로 뭐가 새는지 사례로 보겠습니다. 전부 기관을 특정하지 않은 익명 사례이고, 어디서나 비슷하게 일어나는 패턴입니다.

코드만 봤을 때 — "검사 통과"의 함정

ㅇㅇ기관이 접근성 자동 검사 도구를 돌려서 "오류 0건"을 받았습니다. 보고서에도 그렇게 올라갔습니다. 그런데 실제 사용자한테서는 불편하다는 얘기가 계속 나왔습니다.

뜯어보니, 그 도구는 코드에서 잡히는 항목 위주로 봤던 것입니다. 대체텍스트가 있나 없나, 라벨이 붙어 있나 같은 것들. 그건 통과였습니다. 그런데 화면에서 글자 대비가 부족한 것, 이미지로 박아넣은 버튼, 모바일에서 요소가 겹치는 것 — 이런 시각·실물 영역은 그 도구의 범위 밖이었습니다. 코드 검사는 자기가 보는 범위 안에선 "0건"이 맞습니다. 문제는 그 범위가 전체의 일부라는 것입니다.

"검사 통과"라는 말이 주는 안도감이 오히려 독이 됐습니다. 통과 도장을 받았으니 더 안 봤고, 안 본 데서 문제가 계속 터졌습니다. ViewCheck식으로 말하면, 이 기관은 운영 시점의 "코드 측면"만 보고 "시각 측면"과 "판단 측면"을 비워둔 것입니다. 그 빈자리에서 민원이 났습니다.

설계만 봤을 때 — 의도와 결과의 간극

반대 경우도 있습니다. ㅇㅇ기관의 한 사업에서 디자인 단계에서 KRDS 기준을 꼼꼼히 맞췄습니다. 시안상으로는 거의 완벽했습니다. 그래서 "디자인 검수 통과"로 넘어갔습니다.

그런데 개발이 끝나고 실제 사이트를 보니 시안이랑 미묘하게 달랐습니다. 간격이 시안보다 좁아졌고, 버튼 색이 살짝 달랐고, 모바일에서는 시안에 없던 레이아웃 깨짐이 생겼습니다. 디자인은 "이렇게 만들어라"는 의도일 뿐, 그게 코드로 옮겨지는 과정에서 어긋난 것입니다. 설계 시점만 보고 운영 시점을 안 보면, 이 간극을 영영 모릅니다. "우리 디자인은 기준에 맞아"와 "우리 사이트는 기준에 맞아"는 다른 말입니다. 토큰(디자인 변수)을 바꿨는데 코드에는 반영이 안 되는 경우도 흔합니다.

운영만 봤을 때 — 너무 늦게, 맥락 없이

운영 중인 사이트만 보는 것도 단독으로는 아쉽습니다. 일단 이미 다 만들어진 다음이라 발견해도 고치는 비용이 큽니다. 설계 단계에서 잡았으면 쌌을 걸, 오픈 후에 잡으니 비싸집니다.

그리고 기계적으로 "위반 200건"이라고 뱉어내기만 하면, 받는 사람은 막막합니다. 200건 중에 뭐가 진짜 급한 건지, 뭐가 맥락상 봐줄 만한지, 어떻게 고쳐야 하는지가 없으면 그 목록은 그냥 숙제 더미일 뿐입니다. 여기서 "판단 시점"이 빠지면, 데이터는 많은데 행동으로 안 이어집니다.

두 개는 봤는데 하나를 놓쳤을 때

세 시점 중 두 개를 챙겨도, 나머지 하나가 비면 거기서 샙니다. ㅇㅇ기관은 설계도 잘 봤고 운영 중인 화면도 자동으로 잘 훑었습니다. 데이터는 충분했습니다. 위반이 몇백 건 나왔으니까요. 그런데 그게 그냥 긴 목록으로만 남았습니다. 뭐부터 손대야 할지, 어떤 게 사용자한테 진짜 치명적인지를 정리해주는 "판단 시점"이 없었던 것입니다.

결과가 어땠느냐면, 그 목록을 받은 담당자가 결국 손도 못 댔습니다. 너무 많고, 우선순위가 없으니까요. "다 고쳐야 한다"는 사실상 "아무것도 안 고친다"와 비슷한 상태가 됩니다. 데이터가 부족해서가 아니라, 데이터를 행동으로 옮길 판단이 빠져서 멈춘 것입니다. 세 시점은 셋 다 있어야 비로소 "발견 → 이해 → 개선"으로 이어집니다.

ViewCheck는 이렇게 쌓인 위반을 위험도(P0~P3)로 등급화해서, "다 고쳐야 한다"는 막막함 대신 "이것부터"라는 순서를 내놓습니다. 판단 시점이 데이터를 행동으로 바꾸는 지점입니다.

결국, 한 시점의 맹점은 다른 시점이 메운다

사례들을 쭉 보면 규칙이 보입니다. 한 시점의 약점은 정확히 다른 시점의 강점입니다.

코드만 보면 시각·실물을 놓칩니다 → **운영 시점(실제 화면)**이 메웁니다.
설계만 보면 구현 결과를 모릅니다 → 운영 시점이 메웁니다.
운영만 보면 너무 늦고 맥락이 없습니다 → **설계 시점(미리)**과 **판단 시점(의미)**이 메웁니다.

그러니까 "어떤 도구가 제일 좋냐"가 아니라, "세 시점을 다 덮고 있냐"가 진짜 질문입니다. 도구 하나가 한 시점만 본다면, 나머지 두 시점은 누가 보고 있는지를 따져봐야 합니다.

본론 5 — 그럼 왜 여태 한 시점만 봐왔을까

이쯤 되면 이런 생각이 드실 겁니다. "세 시점이 다 필요한 거 당연해 보이는데, 왜 다들 하나만 보고 있었지?" 이유가 있습니다.

도구가 따로따로 놀아서

가장 큰 이유는 도구가 파편화돼 있어서입니다. 디자인 검수는 디자인 도구에서, 코드 검사는 또 다른 검사 도구에서, 성능은 성능 도구에서, 접근성은 접근성 도구에서… 각자 자기 시점만 봅니다. 이걸 한 사람이 다 돌리고, 결과를 모아서, 머릿속에서 합쳐야 합니다. 그런데 그게 보통 일이 아닙니다.

그래서 현실에선 "제일 손에 익은 것 하나"만 돌리게 됩니다. 코드 검사 도구가 익숙하면 그것만, 디자인 검수가 익숙하면 그것만. 나머지 시점은 "나중에" 혹은 "여력 되면"으로 밀립니다. 도구가 따로 노니까, 시점도 따로 놀고, 결국 하나만 챙기게 되는 것입니다.

합치는 일이 또 사람 몫이라서

설령 세 도구를 다 돌렸다고 해보겠습니다. 그럼 결과가 세 뭉치로 나옵니다. 디자인 검수 결과, 코드 검사 결과, 성능 결과. 이걸 합쳐서 "그래서 우리 사이트 상태가 종합적으로 어떻다"로 만드는 건 또 사람 일입니다. 세 개를 돌리는 것도 일인데, 합치는 건 더 일입니다. 게다가 도구마다 점수 기준이 달라서, 단순히 합산할 수도 없습니다.

이러니 "어차피 합치기도 힘든데 하나만 제대로 보자"가 됩니다. 합치는 비용이 크면, 사람은 자연스럽게 적게 보는 쪽을 택합니다.

시점을 넘나드는 게 원래 어려워서

마지막 이유는 좀 더 근본적입니다. 세 시점은 보는 방식 자체가 다릅니다. 설계 시점은 디자인 파일을 읽어야 하고, 운영 시점은 실제 화면을 렌더링해서 봐야 하고, 판단 시점은 맥락을 이해해야 합니다. 한 사람이 이 셋을 다 잘하기가 어렵습니다. 디자이너는 설계를 잘 보고, 개발자는 코드를 잘 보고, 기획자는 맥락을 잘 봅니다. 그런데 셋을 한 명이, 그것도 일관된 기준으로 보라면 어떨까요.

그래서 시점이 나뉜 채로 굳어졌습니다. 각자 자기가 잘 보는 시점만 보고, 그 사이의 빈틈은 아무도 안 보는 채로요. 이 빈틈을 메우려면, 세 시점을 한 흐름으로 묶어주는 무언가가 필요합니다. 사람이 일일이 도구를 옮겨다니지 않아도 되게 말입니다.

본론 6 — 그래서 실무에선 언제 무엇을 보나

개념은 그렇고, 실무에선 어떻게 적용할까요. 프로젝트 단계별로 자연스럽게 매칭됩니다.

새로 만들거나 개편할 때

새 사이트를 만들거나 크게 개편하는 중이라면, 세 시점을 시간 순서대로 다 태우는 게 이상적입니다.

디자인 단계 → 설계 시점으로 미리 잡습니다. 여기서 잡으면 제일 쌉니다.
개발·배포 후 → 운영 시점으로 실물을 확인합니다. 의도가 제대로 구현됐는지를요.
그 위에서 → 판단 시점으로 우선순위를 매기고 개선안을 정리합니다.

이렇게 하면 "디자인은 통과인데 배포본은 위반" 같은 간극이 안 생깁니다. 설계에서 거르고, 운영에서 확인하고, 판단에서 정리하니까요.

이미 운영 중인 사이트를 점검할 때

이미 한참 돌아가고 있는 사이트라면, 디자인 파일이 없거나 옛날 것이라 의미가 없는 경우가 많습니다. 이럴 땐 운영 시점이 주력입니다. 실제 돌아가는 사이트를 실물로 보는 것. 거기에 판단 시점을 얹어서 "그래서 뭐부터"를 정리합니다. 설계 시점은 다음 개편 때 다시 챙기면 됩니다.

여기서 흔히 하는 실수가, 운영 시점을 "메인 한 페이지"로 좁히는 것입니다. 이미 만들어진 사이트는 페이지가 많으니 운영 시점이야말로 전수로 봐야 의미가 있습니다. 메인만 보면 정작 문제 있는 깊은 페이지를 또 놓치게 됩니다. 운영 시점의 강점은 "사이트 전체를 사용자처럼"인데, 거기서 범위를 좁히면 강점이 사라집니다.

정기적으로 관리할 때

한 번 보고 끝이 아니라 계속 관리해야 한다면, 운영 시점을 주기적으로 돌리는 게 핵심입니다. 같은 기준으로 정기적으로 보면서 시점별 변화를 추적합니다. "작년보다 나아졌냐"는 질문에 답을 못 하던 문제가, 여기서 풀립니다.

한 장으로 정리하면

상황	설계(Figma)	운영(URL)	판단(LLM)	무게중심
새로 만들기·개편	◎ 미리	◎ 배포 후	○ 정리	설계→운영→판단 순서대로
운영 중 점검	△ 다음 개편 때	◎ 전수	◎ 우선순위	운영 + 판단
정기 관리	△	◎ 주기적	○	운영 반복

◎ 필수 · ○ 권장 · △ 상황 따라

이번 주 금요일 글에서 이걸 "상황별로 언제 무엇을 쓰면 되는지" 선택 가이드로 더 자세히 정리할 예정입니다. 오늘은 "세 시점이 있고, 상황에 따라 무게중심이 다르다" 정도만 잡고 가시면 됩니다. 중요한 건, 어떤 상황이든 하나의 시점만으로는 전체가 안 보인다는 점입니다.

무게중심만 다를 뿐, 셋을 다 의식하는 게 핵심입니다. 어느 경우든 "지금 내가 안 보고 있는 시점은 누가 보고 있지?"를 한 번씩 자문하면, 빈틈이 줄어듭니다. 그 자문 한 번이 나중에 터질 사고 하나를 막습니다.

그래서 ViewCheck는

ViewCheck가 분석 방법을 세 가지나 가진 이유가 여기 있습니다. URL 분석(운영 시점), Figma 분석(설계 시점), LLM 분석(판단·보강 시점). 한 가지만 잘하는 게 아니라, 세 시점을 다 덮으려고 그렇게 설계했습니다.

거창한 얘기는 아닙니다. 앞에서 본 것처럼 한 시점만 보면 반드시 다른 데서 새니까, 그 빈 곳을 안 만들려는 것뿐입니다. 코드 검사 하나로 안심하다 놓치던 시각·실물 문제는 URL 분석이, 배포 후에야 발견하던 문제는 Figma 분석이 미리, 위반 목록만 잔뜩 받고 막막하던 부분은 LLM 분석이 우선순위와 개선안으로 메웁니다. 셋이 각자 보던 걸 한 흐름으로 합치는 구조입니다. 그리고 그 위에서 KRDS 846규칙이 시점별로 판정되고, 두 엔진이 분업해서 정확도를 끌어올립니다.

각각이 구체적으로 어떻게 돌아가는지는 다음 주부터 차례로, 시점별로 깊게 풀겠습니다. URL 분석부터 시작해서, Figma, LLM 순으로요. 오늘은 "왜 셋이 다 필요한가"라는 큰 그림까지만 담았습니다.

🔐 특허로 지키는 부분

오늘 본 "세 시점을 한 기준으로 묶어 교차 비교하고, 그 위에서 846규칙을 시점별로 판정하는 방법"은 ViewCheck가 출원한 특허 중 시점 비교(설계·운영 교차 검증) 및 기준 자동 판정(846규칙) 주제와 맞닿아 있습니다. 분석 도구 자체는 누구나 비슷하게 만들 수 있지만, 설계·운영·판단을 하나의 기준으로 엮고 규칙별로 적합한 시점을 골라 판정하는 절차를 권리로 정리해 둔 것이 차별점입니다.

다만 솔직히 짚어둘 게 있습니다. 특허는 "방법을 지키는 장치"지 "품질 보증서"가 아닙니다. 분석 품질은 오늘 본 세 시점·두 엔진이 실제로 잘 작동하느냐로 결정되는 것이고, 특허는 그 방법을 보호하는 것입니다. 그래서 "특허 있으니 믿으세요"가 아니라 "이 방법을 직접 만들고 지켜두었다" 정도로 받아들여 주시면 됩니다. (특허 출원 기술 / 자체 개발)

마무리

오늘 핵심은 하나입니다. 웹 품질을 보는 데는 세 가지 시점이 있습니다. 만들기 전(설계), 만든 후(운영), 그 위에서(판단). 사람이 하나만 보면 절반만 보이듯, 자동화 도구도 하나만 보면 똑같이 절반만 봅니다. "검사 통과"라는 안도감이 오히려 안 본 영역을 가립니다.

그리고 그 세 시점 위에서 KRDS 846규칙이 판정됩니다. 규칙마다 적합한 시점이 다르고, 그래서 ViewCheck는 두 엔진(규칙 엔진 + 시각 AI)을 분업시킵니다. "감으로 A등급"이 아니라 "846개 규칙의 시점별 판정 → 가중치 → 준수율"이라는 근거 있는 숫자가 나오는 이유입니다.

한 가지만 기억해 주세요. "검사 통과"는 "그 도구가 보는 범위 안에서 통과"라는 뜻이지, "전체가 괜찮다"는 뜻이 아닙니다. 통과 도장을 받았을수록 오히려 "그럼 나머지 두 시점은 누가 봤지?"를 물어야 합니다. 그 질문이 빠지면, 안심이 곧 사각지대가 됩니다.

이번 주 나머지 글에서 이걸 더 구체화하겠습니다. 수요일엔 도구 하나만 믿다가 결국 놓쳤던 리뉴얼 검수 실패 사례를(물론 익명으로), 금요일엔 "우리 상황에선 언제 무엇을 보면 되는지" 상황별 선택 가이드를 정리하겠습니다.

다음 주부터는 본격적으로 첫 번째 시점, URL 분석으로 들어갑니다. 운영 중인 사이트를 어떻게 실물 그대로 읽어내는지, 그 안에 어떤 기술이 들어 있는지 하나씩 풀어보겠습니다.

오늘도 끝까지 읽어주셔서 고맙습니다. 수요일에 사례로 이어가겠습니다.

krds.viewcheck.co.kr