AI가 읽고 고친다 — N/A 해소와 개선안

---

들어가며 — 이번 주의 마지막 조각, 판단

이번 주는 1개월차의 마지막 주입니다. 월요일엔 ViewCheck가 어떻게 두 엔진으로 일을 나누는지(코드를 보는 규칙 엔진과, 화면을 보는 시각 AI 엔진)를 봤고, 수요일엔 그 위에 얹히는 LLM 분석이란 무엇인지(판단 시점, 결과를 사람처럼 해석하는 층)를 봤습니다. 오늘 금요일은 그 둘을 하나로 잇는 실용적인 이야기입니다. "AI가 읽고 고친다" — 규칙으로 딱 떨어지지 않아 빈칸으로 남은 것을 AI가 어떻게 읽어서 채우고, 나아가 "그래서 어떻게 고치면 되는지"까지 어떻게 이어주는가 하는 것입니다.

먼저 솔직한 이야기부터 드리겠습니다. 지난 몇 주 동안 "846규칙을 자동으로 판정한다"고 말씀드렸지만, 사실 규칙만으로 깔끔하게 떨어지지 않는 게 꽤 많습니다. 코드만 봐서는 판단이 안 되는 것, 그 페이지엔 해당 요소가 없어서 "해당 없음(N/A)"으로 빠지는 것, 규칙은 어겼는데 맥락상 의도된 예외처럼 보이는 것. 이런 빈칸들이 남습니다. 지난주 결과 읽기 편에서 "N/A가 너무 많으면 실제로 판정된 게 적다는 뜻"이라고 잠깐 짚었는데, 오늘은 바로 그 빈칸을 어떻게 다루는지가 주제입니다.

여기가 AI가 들어오는 자리입니다. 사람이 "이건 이미지로 만든 버튼이니까 버튼 규칙을 적용해야지" 하고 빈칸을 채우는 것처럼, AI가 화면을 사람처럼 읽고 그 빈칸을 채웁니다. 그리고 채우는 데 그치지 않고, "이걸 어떻게 고치면 되는지"까지 글로 정리해줍니다. 발견에서 끝나지 않고 개선까지 잇는 것이죠.

오늘 글은 크게 두 덩어리로 갑니다. 앞부분은 "N/A 착시" — 위반이 적어 보이는 게 왜 좋은 신호가 아닐 수 있는지, 그 빈칸을 방치하면 어떤 일이 벌어지는지입니다. 뒷부분은 "빈칸을 채우고 고치는 법" — 시각 AI가 어떻게 빈칸을 채우고, 그 위에서 개선안이 어떻게 붙는지입니다. 두 이야기는 사실 하나입니다. 빈칸이 왜 위험한지를 알아야, 그걸 채우는 일이 왜 중요한지가 보이니까요.

미리 한 가지 정리하면, 이 판단 시점은 앞의 두 시점(운영·설계)과 성격이 조금 다릅니다. 운영 시점(URL 분석)과 설계 시점(Figma 분석)이 "기준에 맞는지 대조"하는 쪽이라면, 판단 시점은 "그 결과를 사람처럼 해석"하는 쪽입니다. 앞 둘이 재판의 증거 수집이라면, 이건 그 증거를 보고 "그래서 무엇이 제일 문제이고 어떻게 할까"를 정리하는 것입니다. 그래서 AI가 들어오는 것이고요. 대조는 규칙으로 되지만, 해석은 사람이나 사람 같은 AI가 필요하니까요.

---

본론 1 — "위반이 별로 없는데요?"라는 안심의 정체

먼저 실무에서 자주 나오는 한 문장으로 시작하겠습니다.

"분석을 돌렸는데 위반이 별로 없네요? 우리 사이트, 괜찮은가 봐요."

이 말은 반은 맞고 반은 위험합니다. 위반이 적게 나온 게 "진짜 양호해서"일 수도 있지만, "절반을 판정 못 해서(N/A)"일 수도 있기 때문입니다. 후자라면, 위반이 적어 보이는 건 좋은 게 아니라 안 본 게 많다는 신호입니다. 그런데 결과만 슥 훑으면 이 둘이 구분이 안 됩니다. 둘 다 "위반 적음"으로 보이니까요.

같은 결과, 다른 의미

분석 결과에 "위반 30건"이 떴다고 해보겠습니다. 이게 좋은 걸까요? 답은 "그것만으로는 모른다"입니다. 두 가지 경우가 있습니다.

하나는 진짜 양호한 경우입니다. 846규칙 중 800개를 제대로 판정했는데 그중 위반이 30건이라면, 이건 정말 괜찮은 것입니다. 대부분 통과이고 위반이 적으니까요.

다른 하나는 절반을 못 본 경우입니다. 846규칙 중 400개를 "해당 없음(N/A)"으로 빼고, 나머지 446개 중 위반이 30건이라면 어떨까요? 위반이 적어 보이는 건 안 본 400개 안에 위반이 숨어 있을 수 있어서입니다. 판정한 것 중엔 30건이지만, 안 판정한 게 절반입니다.

이 둘은 결과 화면에서 똑같이 "위반 30건"으로 보입니다. 그래서 위반 숫자만 보면 속습니다. 진짜 봐야 할 건 "위반 몇 건이냐"가 아니라 "846개 중 몇 개를 실제로 판정했느냐", 즉 N/A가 몇 개냐입니다.

숫자로 다시 보면 더 분명합니다. 첫 경우는 800개를 판정해서 위반 30, 그러니 판정한 것의 약 4%만 위반입니다. 정말 양호합니다. 둘째 경우는 446개를 판정해서 위반 30, 나머지 400개는 아예 안 봤습니다. 판정 비율로 치면 절반을 조금 넘습니다. 안 본 400개에 위반이 첫 경우와 같은 비율로 섞여 있다면, 실제 위반은 30이 아니라 훨씬 많을 수 있습니다. 같은 "위반 30"인데, 하나는 거의 다 본 30이고 하나는 절반만 본 30입니다. 무게가 완전히 다릅니다.

그래서 위반 숫자는 "판정 비율"이라는 분모와 함께 봐야 의미가 삽니다. 분모를 안 보고 분자만 보면, 분자가 작은 게 좋은 건지 안 본 게 많은 건지 알 수가 없습니다. 시험으로 치면, 100점 만점에 안 틀린 게 자랑인지 안 푼 문제가 많은 건지를 함께 봐야 하는 것과 같습니다.

나쁜 의도 없이도 생기는 착시

흥미로운 건, 이 착시가 "나쁜 의도" 없이도 생긴다는 점입니다. 분석을 돌린 담당자도 속고, 보고를 받은 윗선도 속습니다. 누가 거짓말을 한 게 아니라, 결과 화면이 위반 숫자를 크게 보여주고 N/A를 작게(혹은 아예 안) 보여주면 자연스럽게 그렇게 읽힙니다. 사람은 큰 숫자에 눈이 가고, "해당 없음"은 "신경 안 써도 되는 것"으로 흘려보내니까요. 그래서 이건 개인의 부주의라기보다, 결과를 어떻게 보여주느냐의 문제이기도 합니다. 판정 비율을 위반 숫자만큼 눈에 띄게 보여주는 분석이라면, 이 착시가 애초에 덜 생깁니다.

이게 자동 분석 시대의 새로운 함정이라 한 번 더 짚고 갈 만합니다. 사람이 손으로 점검하던 시절엔 "안 본 페이지"는 적어도 안 봤다는 걸 알았습니다. 시간이 없어서 못 봤으니까요. 그런데 자동 분석은 "다 돌렸다"는 느낌을 주면서 정작 절반은 N/A로 비워둘 수 있습니다. "돌리긴 다 돌렸는데 판정은 절반만"인 상태인 것이죠. 사람은 안 본 걸 알지만, 자동 분석은 안 본 걸 "해당 없음"이라는 깔끔한 라벨로 덮어버립니다. 그래서 오히려 더 속기 쉽습니다. 도구가 좋아질수록, 그 도구가 "무엇을 안 봤는지"를 읽는 눈도 함께 필요해지는 셈입니다.

위 화면이 오늘 이야기의 출발점입니다. 어떤 페이지를 규칙 엔진으로만 돌리면 "통과 100, 미통과 80, 해당 없음 660" 같은 식으로 나올 수 있습니다. 얼핏 보면 "위반이 80건이네" 싶은데, 사실 660건은 판정을 못 한 것입니다. 그중엔 정말 그 페이지에 없는 요소도 있지만, "코드로 못 봐서" 빠진 것도 섞여 있습니다. 이 660을 그냥 두면, 분석 결과가 실제보다 깨끗해 보이는 착시가 생깁니다. 위반이 적은 게 아니라 안 본 게 많은 것인데도요.

이게 왜 신뢰와 직결되냐면, N/A가 많은 결과로 "우리 사이트 양호합니다"라고 보고하면 그건 과장이 되기 때문입니다. 본 것 중에 양호한 것이지, 안 본 게 절반이니까요. 그래서 좋은 분석은 N/A를 최대한 줄여서 "실제로 판정한 비율"을 높이고, 못 채운 N/A는 솔직히 "이건 판정 못 했다"고 남깁니다. 빈칸을 채우는 것도 중요하지만, 못 채운 빈칸을 숨기지 않는 것도 그만큼 중요합니다.

착시가 번지는 세 방향

N/A를 잘못 읽으면 "위반이 적어 보임" 하나로 끝나지 않고, 여러 곳으로 문제가 번집니다. 세 방향으로 짚어보겠습니다.

첫째는 잘못된 안심입니다. "양호하다"고 믿고 손을 놓습니다. 그 사이 안 본 영역의 문제는 그대로 쌓이거나 민원으로 터집니다. 차라리 "절반은 판정 못 했습니다"라고 솔직히 나왔으면 더 봤을 텐데, "위반 적음"이라는 결과가 그 동기를 없애버립니다. 이게 윗선 보고로 가면 더 커집니다. "분석해보니 위반 적고 양호합니다"라고 보고했는데 나중에 문제가 터지면, 보고한 사람이 곤란해집니다. 사실은 "절반밖에 못 봤다"였는데 그걸 모르고 양호하다고 한 것이니까요. 그래서 보고 전에 판정 비율을 확인하는 게, 자기 자신을 지키는 일이기도 합니다. "판정한 것 중엔 양호하나, 자동 판정이 안 된 영역이 이만큼 있다"고 단서를 달면, 나중에 문제가 나와도 "그 부분은 추가 확인이 필요하다고 했다"가 됩니다. 정직한 분석이 보고하는 사람도 보호합니다.

둘째는 잘못된 비교입니다. 지난주에 "위반 개수로 사이트를 비교하지 말라"고 했는데, N/A가 끼면 비교가 더 망가집니다. A사이트는 N/A가 적어서 위반이 50건 잡혔고, B사이트는 N/A가 많아서 위반이 20건 잡혔다고 해봅시다. 숫자만 보면 B가 나아 보입니다. 그런데 실제로는 B가 절반을 못 본 것이라, 더 나쁠 수도 있습니다. N/A 비율이 다르면 위반 숫자 비교 자체가 의미가 없어집니다. 두 사이트를 나란히 놓기 전에, 각각의 판정 비율이 비슷한지부터 봐야 하는 것이죠.

셋째는 잘못된 추세입니다. 정기적으로 분석할 때 문제가 됩니다. 이번엔 N/A가 적게 나오고 다음엔 많이 나오면, 위반 숫자가 출렁입니다. 실제로 사이트가 바뀌어서가 아니라, 판정 비율이 달라져서요. 그러면 "나아졌나 나빠졌나"를 잘못 읽습니다. 추세를 볼 땐 위반 숫자만이 아니라 판정 비율도 함께 봐야 하는 이유입니다. 이 셋의 뿌리는 같습니다. 위반 숫자를 액면 그대로 믿어서입니다. 그 숫자 뒤의 "얼마나 봤나(N/A)"를 안 보면, 안심도 비교도 추세도 다 틀어집니다.

---

본론 2 — N/A는 왜 그렇게 많이 생기나

그럼 N/A가 왜 절반씩이나 생길까요. 크게 두 종류가 섞여 있습니다. 이 둘을 가려내는 게 오늘의 핵심 숙제입니다.

① 진짜 해당 없음 (정당한 N/A)

이건 정상입니다. 그 페이지에 표가 없으면 표 규칙은 N/A입니다. 검색 기능이 없는 페이지에 검색 규칙은 N/A입니다. 846규칙은 모든 종류의 컴포넌트·패턴을 다 담고 있으니, 한 페이지에 그게 전부 있을 리 없습니다. 그래서 어떤 페이지든 상당수는 정당하게 N/A가 됩니다. 이건 채울 게 아니라 그대로 두는 게 맞습니다. N/A를 0으로 만드는 게 목표가 아닌 이유가 여기 있습니다.

조금 더 풀어보면, 846규칙은 공공 웹에서 나타날 수 있는 온갖 상황을 폭넓게 담아둔 목록입니다. 디자인 스타일(DS) 120개, 컴포넌트(CP) 446개, 기본 패턴(BP) 108개, 서비스 패턴(SP) 172개. 이렇게 넓게 준비해 두어야 어떤 페이지가 들어와도 빠짐없이 대조할 수 있습니다. 대신 그 대가로, 특정 한 페이지에는 해당하지 않는 규칙이 자연히 많아집니다. 로그인 화면 하나를 넣으면 게시판 규칙은 해당이 없고, 게시판 하나를 넣으면 지도·달력 컴포넌트 규칙은 해당이 없습니다. 이런 정당한 N/A는 "이 페이지엔 그게 없다"는 사실을 정확히 알려주는 정보이지, 결코 흠이 아닙니다.

② 코드로 못 봐서 N/A (가짜 N/A)

문제는 이쪽입니다. 화면엔 분명히 있는데, 코드로 못 잡아서 N/A로 빠진 것들입니다. 대표적인 게 이미지로 만든 버튼입니다. 화면엔 버튼이 있는데 코드로는 그냥 이미지라, "버튼 규칙: 해당 없음"이 됩니다. 사실은 버튼이 있으니 판정했어야 하는데도요. 이건 "진짜 해당 없음"이 아니라 "못 봐서 빠진" 것입니다.

이런 가짜 N/A가 생기는 경우는 생각보다 다양합니다. 이미지로 만든 버튼·메뉴·배너, 표준을 벗어난 방식으로 구현한 컴포넌트, 외부 모듈로 끼워 넣은 위젯 같은 것들입니다. 코드 구조가 일반적이지 않으면 규칙 엔진이 "이게 무엇인지" 못 알아보고 N/A로 넘깁니다. 특히 오래된 사이트나 여러 업체가 손댄 사이트일수록 이런 비표준 구현이 많아서, 가짜 N/A도 늘어납니다.

여기서 좀 얄궂은 역설이 생깁니다. "우리 사이트는 위반이 적네"가, 사실은 "우리 사이트는 비표준 구현이 많아서 판정을 많이 못 했네"일 수도 있는 것입니다. 엉성하게 만든 사이트일수록 코드로 판정이 안 돼서, 오히려 위반이 적어 보일 수 있으니까요. 정석대로 잘 만든 사이트는 규칙 엔진이 구조를 또박또박 읽어내서 위반도 정직하게 잡히는데, 제멋대로 만든 사이트는 그 구조가 규칙 엔진의 눈을 피해 가면서 위반도 함께 숨어버립니다. 품질이 낮은 사이트가 점검에서는 되레 깨끗해 보이는, 앞뒤가 뒤집힌 상황인 것이죠. 이게 가짜 N/A가 위험한 진짜 이유입니다.

둘을 구분해야 한다

핵심은 이 둘을 구분하는 것입니다. 정당한 N/A는 그대로 두고, 가짜 N/A는 채워야 합니다. 그런데 결과만 보면 둘 다 똑같이 "N/A"로 표시됩니다. 그래서 "N/A 400개" 중에 진짜 해당 없음이 몇이고 못 봐서 빠진 게 몇인지를 가려내는 게, 분석 품질의 진짜 숙제입니다.

이걸 사람이 손으로 가려내려면 어떻게 해야 할까요? 400개를 하나씩 화면 보면서 "이건 진짜 없네, 이건 있는데 못 봤네" 해야 합니다. 지난 편들에서 계속 이야기한 그 규모·피로 문제에 또 빠집니다. 400개를 사람이 눈으로 대조하는 건, 몇 페이지짜리 사이트라면 몰라도 수십·수백 페이지를 보는 순간 현실성이 없어집니다. 그래서 여기를 자동으로, 화면을 보는 엔진으로 가려내는 게 필요한 것입니다. 화면에 그 요소가 보이면 "가짜 N/A(채워야 함)", 안 보이면 "정당한 N/A(그대로 둠)". 화면이 이 둘을 가르는 기준이 됩니다. 코드만으로는 못 가르던 걸, 화면을 보면 가를 수 있습니다.

---

본론 3 — 시각 AI가 빈칸을 채운다

그래서 두 번째 엔진이 등장합니다. 월요일에 소개한 그 시각 AI 엔진입니다. 이름은 외울 필요 없고, "코드 보는 쪽 / 화면 보는 쪽"으로 기억하시면 됩니다.

규칙 엔진이 뼈대를 세운다

먼저 규칙 엔진이 무엇을 잘하는지부터 짚겠습니다. 이 엔진은 화면 뒤의 구조(코드)를 보고 "if 이렇다 then 통과/미통과"로 딱딱 판정합니다. 예를 들어 "버튼에 라벨이 있나?", "제목 구조가 논리적인가?", "이 색 대비가 기준 이상인가?" 같은 건 코드와 값으로 명확히 답이 나옵니다. 빠르고, 정확하고, 일관됩니다. 846규칙을 1~3초면 판정합니다. 대부분의 KRDS 규칙이 이렇게 코드·값으로 판정되므로, 규칙 엔진이 분석의 1차 뼈대가 됩니다. 빠르고 믿을 만하니까요.

그런데 이 엔진은 본론 2에서 본 그 빈칸들 — 이미지 버튼, 비표준 컴포넌트 — 은 못 채웁니다. 코드만 보니까요.

시각 AI 엔진이 화면을 눈으로 본다

그래서 두 번째 엔진이 화면을 봅니다. 스크린샷을 받아서, 거기에 무엇이 있는지를 이미지로 인식합니다. "여기 버튼이 있네", "이건 카드네", "이 영역은 표네" 하고요. 코드엔 안 보이는 이미지 버튼도, 화면을 보니까 잡아냅니다. 이게 사람이 화면을 보는 것과 비슷합니다. 코드를 안 봐도 화면만 보면 "저거 버튼이다"를 알듯이, 시각 AI 엔진도 화면의 생김새로 컴포넌트를 인식합니다. 그래서 규칙 엔진이 코드로 못 본 걸, 이 엔진이 화면으로 메웁니다.

순서로 보면 이렇습니다. 먼저 규칙 엔진이 코드로 846규칙을 빠르게 판정해 뼈대를 만듭니다. 그 결과에 N/A(빈칸)가 남습니다. 그러면 시각 AI 엔진이 화면을 봐서, 그 빈칸 중 "화면엔 있는데 코드로 못 잡은 것"을 채웁니다. 코드로는 "버튼 없음(N/A)"이었는데, 화면을 보니 버튼이 있으면 → 그 규칙을 다시 판정하는 것입니다.

여기서 본론 2의 얄궂은 역설이 풀립니다. "비표준으로 엉성하게 만든 사이트일수록 가짜 N/A가 많아 위반이 적어 보인다"고 했는데, 화면으로 가짜 N/A를 채우면 그 착시가 깨집니다. 비표준으로 만든 컴포넌트도 화면엔 보이니까, 시각 AI 엔진이 잡아서 판정합니다. 그러면 "위반이 적던" 그 사이트의 진짜 위반이 드러납니다. 코드로만 보면 비표준 구현이 판정을 피해 가는데, 화면으로 보면 못 피합니다. 사용자 눈엔 보이는 것이니, 화면 보는 엔진의 눈에도 보이는 것이죠.

위 화면이 규칙 1차 판정 위에 AI 품질분석을 얹어 빈칸을 보강한 결과입니다. 앞의 전체 규칙 화면(본론 1)과 견주어 보면, "해당 없음"으로 비어 있던 자리 일부가 실제 판정으로 바뀌어 있습니다. 화면엔 있는데 코드로 못 잡았던 것들이, 여기서 제자리를 찾은 것입니다.

확신 있을 때만 채운다 — 환각을 만들지 않는다

여기서 아주 중요한 원칙이 하나 있습니다. 시각 AI는 "확신 있을 때만" 빈칸을 채웁니다. 화면을 봐서 "여기 버튼이 확실히 있다"고 인식되면 채우지만, 애매하거나 잘 안 보이면 억지로 채우지 않고 N/A로 그대로 둡니다. 없는 걸 있다고 지어내지 않는다는 뜻입니다.

이게 왜 중요하냐면, AI가 확신 없이 아무거나 찍어서 채우면 그건 채우는 게 아니라 없는 판정을 만들어내는 것이기 때문입니다. "화면에 뭔가 있는 것 같으니 일단 위반이라고 해두자" 식으로 채우면, 판정 비율은 올라가 보여도 그 판정 자체를 믿을 수 없게 됩니다. 그래서 "미감지는 곧 N/A 유지"라는 규칙이 있습니다. 못 봤으면 못 봤다고 남기지, 봤다고 우기지 않습니다. 정직한 N/A 하나가, 지어낸 판정 열 개보다 낫습니다.

바꿔 말하면, 판정 비율을 억지로 끌어올리는 게 목표가 아니라는 뜻입니다. "N/A를 몇 개 채웠다"는 숫자 자체는 자랑거리가 아닙니다. 그 채운 판정이 실제와 맞아야 값이 있습니다. 화면에 정말 버튼이 있어서 채운 것이라야 의미가 있지, 애매한 그림자를 버튼으로 오인해 채운 것이라면 오히려 없느니만 못한 오답이 됩니다. 그래서 시각 AI는 "이건 확실히 버튼이다" 싶은 것만 손을 대고, "버튼인지 배너인지 헷갈린다" 싶은 건 그대로 비워 둡니다. 채운 것은 믿을 수 있고, 못 채운 것은 못 채웠다고 정직하게 남는 — 이 두 가지가 함께 지켜질 때라야 "판정 비율이 올라갔다"는 말이 진짜 신뢰로 이어집니다. 숫자를 부풀리는 것과, 실제로 더 많이 보는 것은 전혀 다른 일입니다.

코드가 확정한 건 뒤집지 않는다

또 하나의 경계가 있습니다. 규칙 엔진이 코드로 명확히 판정한 건, AI가 함부로 뒤집지 않는다는 것입니다. 코드로 "이 버튼 라벨 없음, 미통과"가 확실하면, AI가 "그래도 괜찮아 보이는데?" 하고 통과로 바꾸면 안 됩니다. AI는 어디까지나 "규칙이 못 본 빈칸"을 채우는 역할입니다.

예를 들어 보겠습니다. 어떤 메인 화면에 큼지막한 배너 버튼이 있는데, 코드로는 그냥 이미지입니다. 규칙 엔진은 그 자리에 "버튼 규칙: 해당 없음"이라고 적습니다. 버튼으로 안 보이니까요. 그런데 시각 AI 엔진이 화면을 보면 "여기 누가 봐도 버튼이 있다"고 인식합니다. 그러면 그 "해당 없음"이 "버튼 있음 → 라벨 있나? 크기 충분한가?"로 다시 판정됩니다. 코드로는 빈칸이던 게 화면을 통해 채워지는 것이죠. 반대로, 코드에 멀쩡히 라벨까지 붙은 버튼을 규칙 엔진이 "통과"로 확정했으면, 시각 AI 엔진은 그 자리를 건드리지 않습니다. 이미 확실하니까요.

이 경계가 왜 중요한지는 사람 점검 시절을 떠올리면 됩니다. 사람이 점검하면 보는 사람마다 판정이 갈려서 결과를 못 믿었습니다(편차). AI도 마음대로 판정을 뒤집게 두면 똑같아집니다. "어제 돌렸을 땐 통과였는데 오늘은 미통과네?" 같은 일이 생기죠. 그래서 AI에게 자유를 주되, "코드가 확정한 건 못 건드린다"는 울타리를 쳐두는 것입니다. 자유와 일관성의 균형이라고 할까요. "확실한 건 그대로, 빈칸만 보강, 그것도 확신 있을 때만." 이 세 가지가 지켜져야 두 엔진을 합친 결과가 일관되게 유지됩니다.

---

본론 4 — 채우는 데 그치지 않고, 고칠 길을 제시한다

판단 시점이 하는 일은 빈칸 채우기만이 아닙니다. 크게 세 가지입니다.

① 빈칸 채우기 (N/A 해소)

방금 본 그것입니다. 규칙으로 N/A인 것 중, 화면을 보거나 맥락을 읽어서 pass/fail로 바꿀 수 있는 걸 채웁니다. 이걸로 "실제 판정 비율"이 올라갑니다. 846 중 절반만 보던 게, 빈칸을 채우면 더 많이 보게 됩니다. 분석이 더 촘촘해지는 것이죠.

② 우선순위 매기기

지난주 결과 읽기 편에서 강조한 그것입니다. 위반이 수백 건 나왔을 때, 무엇이 더 급한지 줄을 세웁니다. 사용자에게 치명적인 것과 사소한 것을 구분해서요. 이건 단순 규칙만으로 하기 어렵습니다. "이 위반이 이 기관 맥락에서 얼마나 급한가"는 판단이 필요하니까요.

여기엔 여러 신호가 함께 들어갑니다. 이 위반이 사용자를 얼마나 막는지(치명도), 몇 페이지에 퍼져 있는지(빈도), 어느 화면에 있는지(위치). 이런 걸 종합해서 "이건 P0다, 저건 한참 아래다"를 정합니다. 보통 P0부터 P3까지 등급으로 나뉘는데, 사람이 수백 건을 일일이 이 기준으로 줄 세우려면 또 규모·피로 문제에 빠집니다. AI가 일관된 기준으로 한 번에 정리해주면, 담당자는 "다 고쳐야 한다"는 막막함 대신 "이 다섯 개부터"라는 출발점을 받습니다.

이 중 "빈도"는 실무에서 의외로 쓸모가 큽니다. 위반이 200건이라고 해서 고칠 곳이 200군데인 건 아니기 때문입니다. 그중 상당수가 "모든 페이지에 똑같이 들어가는 헤더·푸터·공통 버튼"에서 나온 것이라면, 그 공통 요소 하나만 고치면 100건이 한 번에 사라지기도 합니다. 그래서 위반을 "어떤 요소에서 반복되나"로 묶어서 보면, 적은 수정으로 큰 효과를 내는 지점이 보입니다. 200건 목록에 압도되는 대신 "아, 이 공통 버튼 하나가 50건이네, 이것부터" 하고 효율적으로 접근하게 되는 것이죠. 이건 사람이 일일이 세서 묶기 어려운데, 자동 분석은 같은 위반을 묶어 빈도로 보여주니 가능합니다. 그래서 실무에서 위반 목록을 볼 때는 "치명도가 높으면서 빈도도 높은 것" — 즉 사용자를 크게 막으면서 여러 페이지에 퍼져 있는 위반 — 을 최우선으로 봅니다. 하나 고치면 여러 페이지에서 큰 문제가 한꺼번에 사라지니, 가장 값어치 있는 개선 지점이니까요. 이 다중 페이지 집계의 원리는 6개월차에서 자세히 다룹니다.

③ 개선안·수정 예시 제시하기

가장 실용적인 부분입니다. 위반을 찾는 데 그치지 않고, "이렇게 고치면 됩니다"를 글로 정리해줍니다. 필요하면 수정 예시(어디를 어떻게 바꾸면 되는지)까지 붙여줍니다. 지난주에 이야기한 "위반 목록만 길고 손 못 대는" 그 문제를, 이게 풉니다. "무엇을 고쳐야 하나"에서 "어떻게 고치나"까지 이어주는 것이죠.

이게 왜 큰 차이일까요? 위반 이름만 있으면 담당자가 또 공부를 해야 합니다. "이 규칙이 무엇이고, 어떻게 고치는 거지" 하고 찾아보는 게 또 일입니다. 그런데 "이 버튼은 터치 영역이 작으니 최소 크기(가로세로 44×44px 이상)를 확보하세요"처럼 구체적인 방법이 붙어 있으면, 바로 개발자에게 넘기거나 직접 고칠 수 있습니다. 발견과 수정 사이의 거리가 확 줄어드는 것이죠. 특히 전문 인력이 부족한 조직일수록 이게 결정적입니다. "어떻게 고치는지"까지 나오면, 깊은 전문성 없이도 개선을 시작할 수 있으니까요.

이 "발견과 수정 사이의 간극"은 생각보다 넓습니다. "이 버튼에 라벨이 없습니다"라는 지적을 받아도, 웹 전문가가 아닌 담당자는 "그래서 어떻게 하라는 거지?" 싶습니다. 개발사에 다시 물어봐야 하고, 그 과정에서 며칠이 흐릅니다. 개발사는 개발사대로 "정확히 어느 화면 어느 버튼이냐"를 되묻고, 그 캐치볼이 몇 번 오가는 사이 개선은 뒤로 밀립니다. 그런데 "이 버튼에 이런 식으로 라벨을 붙이면 됩니다"라는 구체적 예시가, 그것도 "어느 페이지 어느 위치"라는 좌표와 함께 붙어 있으면, 그 캐치볼이 크게 줄어듭니다. 담당자는 그 개선안을 그대로 개발사에 전달하면 되고, 개발사는 다시 물을 것 없이 바로 손을 댈 수 있습니다. 소통 비용이 줄어드는 만큼, 개선의 속도가 붙습니다. 위반을 "찾는" 데서 멈추지 않고 "넘길 수 있는 형태"로 만들어주는 것 — 이게 판단 시점이 실무에서 값을 하는 지점입니다.

다만, "제시"이지 "자동 수정·배포"가 아닙니다

여기서 아주 솔직하게 선을 그어두겠습니다. AI가 개선 방법과 예시를 제시한다고 해서, "AI가 알아서 코드를 고쳐 사이트에 배포한다"는 뜻은 아닙니다. AI가 하는 일은 어디까지나 "이렇게 고치면 됩니다"라는 개선 방법·권고·예시를 정리해서 보여주는 것입니다. 실제로 코드를 수정하고, 검토하고, 반영하는 건 사람과 개발 조직의 몫입니다.

자동 생성된 개선안이나 예시를 그대로 100% 믿고 적용하시라는 것도 아닙니다. 사람이 한 번 검토하고 우리 상황에 맞게 다듬는 게 맞습니다. 다만 "백지에서 시작"하느냐, "초안을 받아 다듬느냐"는 큰 차이입니다. AI가 초안을 주면, 사람은 검토·조정에 집중하면 됩니다. 이것도 결국 "단순 정리는 기계, 판단은 사람"의 한 형태입니다.

정리하면, 앞의 두 시점(운영·설계)이 "기준에 맞나 안 맞나"를 본다면, 이 세 번째 시점은 그 위에서 "그래서 이게 무슨 의미이고, 무엇을 먼저, 어떻게 할까"를 봅니다. 발견을 행동으로 잇는 다리입니다. 그래서 판단 시점이라고 부르는 것이고요. 사람이 마지막에 하던 그 판단을, AI가 상당 부분 거들어주는 셈입니다.

---

본론 5 — 그럼 AI에게 다 맡기면 되나

여기서 균형을 잡아야 합니다. AI가 빈칸도 채우고 개선안도 정리해주면, "그럼 AI에게 다 맡기면 되지" 싶을 수 있습니다. 그런데 그건 또 다른 함정입니다.

AI는 토대가 있어야 의미가 있다

AI 혼자 화면만 보고 다 판단하라고 하면, 부정확하거나 들쑥날쑥할 수 있습니다. AI는 규칙 엔진이 깔아준 정확한 뼈대 위에서 빈칸을 채울 때 가장 잘합니다. 토대가 부실하면 그 위의 판단도 부실합니다. 그래서 "규칙으로 확실한 건 규칙으로, 규칙이 못 보는 빈칸만 AI로"가 맞습니다. AI가 뼈대까지 다 만들게 하면 오히려 신뢰가 떨어집니다.

근거가 있어야 믿는다

AI가 "이건 위반입니다"라고 해도, 근거가 없으면 못 믿습니다. "왜?"에 답을 못 하면 그냥 그럴듯한 추측일 뿐입니다. 그래서 AI 판정엔 근거가 붙어야 합니다. "KRDS 몇 번 규칙에 따르면 이래서 위반"처럼요. 이 근거를 대주는 장치가 따로 있는데, 규칙 원문이나 가이드를 찾아서 판정 근거로 다는 방식입니다. 그 구체적인 원리는 8개월차(LLM 분석과 N/A 해소 심화) 편에서 따로 풀겠습니다. 오늘은 "AI 판정엔 근거가 따라붙어야 신뢰가 생긴다" 정도만 잡아두시면 됩니다.

사람의 최종 판단은 남는다

그리고 AI가 우선순위와 개선안을 줘도, 최종 결정은 사람이 합니다. "이 우선순위가 우리 기관 사정에 맞나", "이 개선안을 우리 예산에서 할 수 있나", "이건 의도된 예외이니 그냥 두자". 이런 최종 판단은 사람 몫입니다. AI는 사람이 판단하기 좋게 정리해서 갖다주는 것이지, 사람을 대체하는 게 아닙니다. 이 시리즈 내내 이야기한 그 구조 — 단순 정리는 기계, 판단은 사람 — 가 여기서도 그대로입니다. 다만 AI가 그 "판단을 돕는" 범위를 꽤 넓혀준 것이죠.

그래서 N/A는 0이 되지 않는다 (현실적 기대치)

"AI가 빈칸을 채운다"고 하면 "그럼 N/A가 0이 되나?" 싶을 수 있는데, 솔직히 그건 아닙니다. 과장하면 앞에서 비판한 그 "통과의 함정"을 또 만드는 것이니까요. 현실적인 기대치를 짚고 가겠습니다.

먼저, 정당한 N/A는 남습니다. 그 페이지에 표가 없으면 표 규칙은 N/A가 맞습니다. 이건 채울 게 아니라 그대로 두는 게 맞는 것입니다. 진짜 해당 없는 건 N/A로 남는 게 정상입니다.

그리고 AI로 채우기 좋은 건 주로 "코드로는 안 보이는데 화면엔 있는 것"입니다. 이미지 버튼, 시각적으로만 구분되는 요소 같은 것들이죠. 이런 건 시각 AI 엔진이 화면을 보면 꽤 잡아냅니다. 반면 "동작을 해봐야 나오는 것"(폼 오류, 복잡한 상호작용, 로그인 안쪽)은 화면을 가만히 보는 것만으로는 한계가 있습니다. 그래서 모든 빈칸이 다 채워지지는 않습니다. 채우기 쉬운 것부터 채워지고, 어려운 건 남습니다.

그래서 좋은 분석의 기준은 "N/A가 0이냐"가 아니라 "N/A를 정직하게 다루느냐"입니다. 채울 수 있는 건 채우고, 못 채운 건 "이건 자동으로는 판정 못 했다"고 솔직히 남기는 것. N/A를 억지로 통과나 미통과로 우겨넣으면 오히려 결과가 부정확해집니다. 확신 없이 찍은 판정은, 안 하느니만 못할 수 있습니다.

그럼에도 이게 큰 의미가 있는 건, 사람이 손으로는 이 빈칸 채우기를 아예 못 하기 때문입니다. 수백 개 빈칸을 화면 보고 하나씩 채우는 건 사람에겐 비현실적입니다. AI가 그중 상당수를 일관된 기준으로 채워주면, 분석이 "절반만 본 것"에서 "꽤 많이 본 것"으로 올라갑니다. 완벽하지는 않아도, 사람이 도달 못 하던 수준에 도달하는 것이죠. 0이 목표가 아니라, "사람보다 훨씬 많이, 일관되게"가 목표입니다.

---

본론 6 — 내 분석이 착시인지 확인하는 다섯 가지

여기까지 왔으면, 실용적인 자가 점검법으로 마무리하는 게 좋겠습니다. 내가 받은 분석 결과가 "진짜 양호"인지 "절반만 본 것"인지, 어떻게 확인할까요. 다섯 가지만 짚어보겠습니다. 이건 ViewCheck를 쓰든 안 쓰든 통하는 습관입니다.

① 판정 비율부터 찾는다

결과 어딘가에 "846개 중 몇 개를 통과/미통과로 판정했나" 또는 "N/A가 몇 개냐"가 있을 것입니다. 그걸 먼저 찾습니다. 없으면, 그 분석은 N/A를 숨기고 있는 것이라 의심해봐야 합니다. 위반 숫자만 크게 보여주고 판정 비율을 안 보여주면, 착시가 생기기 딱 좋습니다. 판정 비율이 보이는 분석이 일단 정직한 분석입니다.

② 카테고리별로 쪼개 본다

전체 판정 비율이 70%여도, 카테고리별로 보면 다를 수 있습니다. 디자인 스타일(DS)은 95% 판정했는데 컴포넌트(CP)는 40%만 판정했다면, 컴포넌트 쪽이 많이 비어 있는 것입니다. 그 비어 있는 카테고리에 가짜 N/A가 몰려 있을 가능성이 높습니다. 그래서 전체 숫자만 보지 말고 카테고리별 판정 비율을 보면, 어디가 안 봐졌는지가 드러납니다. 특히 컴포넌트(CP)는 446개로 항목이 가장 많은 카테고리라, 비표준 구현이 많은 사이트일수록 여기에 가짜 N/A가 몰리기 쉽습니다.

③ "위반 0"인 카테고리를 의심한다

어떤 카테고리가 "위반 0건"이면, 둘 중 하나입니다. 정말 완벽하거나, 아예 판정을 안 했거나(전부 N/A). 보통 후자일 때가 많습니다. 그러니 "위반 0"은 칭찬이 아니라 의심 신호로 보는 게 안전합니다. 그 카테고리의 판정 비율을 확인해보면, 0이 "완벽"인지 "안 봄"인지 갈립니다.

④ 화면과 대조해본다

가장 확실한 건, 분석이 "해당 없음"이라고 한 항목 몇 개를 실제 화면과 대조해보는 것입니다. "버튼 규칙 N/A"인데 화면엔 버튼이 있으면, 그건 가짜 N/A입니다. 몇 개만 찍어서 확인해봐도, 그 분석이 화면을 제대로 보는지 코드만 보는지 감이 옵니다. 코드만 보는 분석이면 가짜 N/A가 많을 것이고, 그러면 위반 숫자를 더 조심해서 읽어야 합니다.

⑤ 같은 사이트를 다시 돌려본다

판정 비율이 매번 출렁이면, 시점 비교가 안 됩니다. 지난 분기엔 위반 50건, 이번 분기엔 30건이 나왔다고 해봅시다. 얼핏 "20건 개선됐네" 싶습니다. 그런데 지난번 판정 비율이 80%였고 이번이 55%였다면? 줄어든 20건은 개선이 아니라 "이번에 덜 봐서" 안 잡힌 걸 수도 있습니다. 그래서 추세를 볼 땐 "위반 50 → 30"만 보면 안 되고, "판정 비율 80% → 55%"를 함께 봐야 합니다. 판정 비율이 비슷하게 유지될 때라야 위반 숫자 변화가 진짜 변화입니다. 분모가 흔들리면 분자 비교는 무의미합니다. 같은 사이트를 두 번 돌려서 판정 비율이 비슷하게 나오는지 보면, 그 분석이 일관된지 알 수 있습니다.

이 다섯 가지만 확인해도, "위반이 적어서 좋아했는데 알고 보니" 같은 일은 크게 줍니다. 핵심은 하나입니다. 위반 숫자를 보기 전에, "이 분석이 얼마나 봤나"부터 확인하는 것.

여기서 한 가지 헷갈리기 쉬운 점을 정리하고 넘어가겠습니다. 지난주 결과 읽기 편에서는 "N/A를 미통과(문제)로 오해하지 말라"고 했습니다. 오늘은 반대로 "N/A를 무시(다 봤다고 착각)하지도 말라"고 하고 있습니다. 얼핏 모순처럼 들리지만 사실 한 이야기입니다. N/A는 "문제"도 아니고 "괜찮음"도 아닙니다. "판정 안 됨"이라는 제3의 상태입니다. 그러니 문제로 세지도, 괜찮은 걸로 세지도 말고, "이만큼은 아직 못 봤다"는 별도 정보로 읽어야 합니다. 통과·미통과라는 두 칸만 보면 N/A는 자꾸 둘 중 하나로 끌려가는데, N/A를 온전히 제3의 칸으로 대접해야 결과가 제대로 읽힙니다. 오해해서도 안 되지만, 무시해서도 안 되는 것 — 이 균형이 N/A를 정직하게 다루는 첫걸음입니다.

---

그래서 ViewCheck는

ViewCheck의 LLM 분석이 이 판단 시점을 담당합니다. 규칙 엔진이 코드로 846규칙을 빠르게 판정해 뼈대를 만들고, 시각 AI 엔진이 화면을 봐서 코드로 못 잡은 가짜 N/A를 채우고, 그 위에서 LLM이 우선순위를 매기고 개선안을 정리해줍니다. 세 단계가 이어지는 것이죠. 단, 규칙이 확정한 건 뒤집지 않고, AI는 확신 있는 빈칸만 채우며, 판정엔 근거가 붙고, 최종 판단은 사람이 합니다.

오늘 이야기에 대입하면, "위반이 적어서 양호하다"던 그 착시는, N/A를 채워서 판정 비율을 높이면 깨집니다. 안 보이던 위반들이 빈칸에서 드러나니까요. 거창한 게 아니라, "안 본 절반을 최대한 보이게 만들고", "발견을 행동으로 잇는" 작업입니다. 코드가 못 보는 건 화면으로, 화면도 애매한 건 솔직히 N/A로. 그리고 위반 목록을 "그래서 무엇부터 어떻게"까지 정리해서요. 완벽이 목표가 아니라, 사람이 손으로는 닿지 못하는 판정 비율에 도달하되 못 한 건 숨기지 않는 것 — 정직과 최대치, 그 둘을 함께 잡는 게 이 판단 시점의 목표입니다.

솔직히 이 글도 "ViewCheck를 쓰세요"라는 이야기라기보다, "분석 결과를 읽을 때 판정 비율부터 보라"는 습관에 관한 이야기에 가깝습니다. 어떤 도구를 쓰든, 위반 숫자 옆에 판정 비율이 있는지 확인하고, 없으면 의심하고, 카테고리별로 쪼개 보는 것. 그 습관만 있으면 N/A 착시엔 안 속습니다. ViewCheck는 그 습관대로 읽기 좋게 결과를 정리해둔 것이고, 맞는지 한번 직접 넣어보시면 제일 빠릅니다.

---

🔐 특허로 지키는 부분

오늘 본 "N/A를 '진짜 해당 없음'과 '코드로 못 봐서 빠진 가짜 N/A'로 가려내고, 가짜 N/A를 화면 인식으로 채워 판정 비율을 끌어올리며, 코드 기반 판정과 화면 기반 판정을 충돌 없이 결합하는 방법"은 ViewCheck가 출원한 다섯 건의 특허 중 N/A 분류·해소(코드·화면 교차 보강), 코드·화면 결합 판정, 그리고 판정 커버리지 정량화 주제와 맞닿아 있습니다. "위반이 몇 건"을 세는 건 누구나 합니다. 차별점은, 그 숫자 뒤의 "얼마나 판정했나"를 분모로 함께 산정하고, 비어 있는 분모를 화면으로 메우되 "코드가 확정한 건 뒤집지 않고, 확신 있는 것만 채운다"는 질서를 지키며 안정적으로 결합하는 절차 자체를 권리로 정리해 둔 데 있습니다.

다만 솔직히 짚어둘 게 있습니다. 특허는 "방법을 지키는 장치"이지 "품질 보증서"가 아닙니다. 판정 비율이 실제로 정확하냐는 오늘 본 N/A 가려내기·채우기·확신도 거르기가 제대로 작동하느냐로 결정되는 것이고, 특허는 그 방법을 보호하는 것입니다. 그래서 "특허가 있으니 믿으세요"가 아니라 "이 방법을 직접 만들고 지켜두었다" 정도로 받아들여 주시면 됩니다. 그리고 현재는 출원 중이며, "등록특허"가 아니라 "출원 기술"로 정확히 표기합니다. (특허 출원 기술 / 자체 개발)

---

마무리

오늘은 이번 주의 마지막 조각으로, "AI가 읽고 고친다"를 봤습니다. 규칙만으로는 빈칸(코드로 안 보이는 것·N/A·맥락)이 남는데, 그 빈칸을 잘못 읽으면 "위반이 적어 보이는" 착시에 빠집니다. "위반 적음"은 "양호함"일 수도 있고 "절반 못 봄"일 수도 있으니까요. 그래서 두 엔진이 이 빈칸을 메웁니다. 코드 보는 규칙 엔진이 뼈대를 빠르게 만들고, 화면 보는 시각 AI 엔진이 가짜 N/A를 채우고, 그 위에서 LLM이 우선순위와 개선안을 더합니다. 단, 규칙이 확정한 건 뒤집지 않고, 확신 있는 것만 채우며, AI 판정엔 근거가 붙고, 개선안은 "제시"까지이며 실제 수정·배포는 사람이 하고, 최종 판단도 사람이 합니다.

한 가지만 덧붙이면, 이 "판정 비율을 본다"는 습관은 비단 KRDS 분석만이 아니라 어떤 자동 점검에도 통합니다. 보안 스캔이든 성능 측정이든, "몇 건 발견" 옆엔 늘 "몇 개를 실제로 검사했나"가 있어야 합니다. 발견 건수만 큰 글씨로 보여주고 검사 범위를 안 보여주는 리포트는, 그게 무슨 분야든 한 번쯤 의심해보는 게 좋습니다. 숫자는 분모가 있어야 말이 됩니다.

기억할 한 문장은 이것입니다. "위반이 적다"를 보면 좋아하기 전에 "그래서 몇 개를 봤는데?"를 물어보는 것. 그리고 빈칸이 남았을 때 그걸 화면으로 채우고, 못 채운 건 솔직히 남기고, 채운 위반엔 "어떻게 고칠지"까지 붙이는 것. 이 흐름이 지켜질 때 AI가 신뢰할 만한 도구가 됩니다. "AI니까 다 알아서"도, "규칙만 믿고 빈칸은 방치"도 아닌, 그 사이의 분업이 핵심입니다.

이것으로 1개월차의 마지막에서 두 번째 편을 마칩니다. 이번 주에 세 시점(운영·설계·판단)을 받쳐주는 두 엔진과 AI의 역할을 한 바퀴 돌았으니, 다음 주(W5·1개월차 마지막 주)엔 이 모든 걸 뒤에서 지켜주는 다섯 건의 특허를 한눈에 정리해 소개하겠습니다. 그리고 다음 달부터는 오늘 큰 그림만 그린 각 영역을 하나씩 깊게 팝니다. 카테고리별 깊이(DS·CP·BP·SP)는 5개월차, 다중 페이지 집계의 원리는 6개월차, LLM 분석과 N/A 해소 심화는 8개월차, 개선 실행은 9개월차입니다. 오늘은 "코드 엔진이 뼈대, 화면 엔진이 빈칸, AI가 판단과 개선안" 정도의 큰 그림만 잡아가시면 충분합니다. 이번 주도 끝까지 읽어주셔서 고맙습니다. 다음 주, 특허 이야기로 만나뵙겠습니다.

krds.viewcheck.co.kr

---