URL 한 줄이 진단 결과가 되기까지 — 수집·렌더·추출·판정, 파이프라인 네 단계 분해

---

들어가며 — "URL 한 줄"과 "결과 화면" 사이에는 네 단계가 있습니다

2개월차 첫 주입니다. 지난달엔 URL 분석이 무엇인지, 왜 운영본을 봐야 하는지, 결과를 어떤 순서로 읽는지를 한 바퀴 돌며 큰 지도를 그렸습니다. 이번 달부터는 그 지도의 각 지점을 하나씩 깊게 파고드는데요, 그 첫 순서로 오늘은 URL 분석이 "안에서 어떻게 도는지"를 열어 보겠습니다. 겉으로는 "URL 한 줄 넣으면 결과가 나온다"로 보이지만, 그 한 줄과 결과 화면 사이에는 네 단계가 차례로 이어져 있습니다. 수집, 렌더, 추출, 판정입니다.

왜 이 네 단계를 굳이 열어 보여드리냐면, 이걸 알면 결과를 읽을 때도, 도구를 고를 때도 훨씬 든든해지기 때문입니다. 결과 화면에 준수율이 뜨고 위반 목록이 나오는데, 그 숫자가 어디서 왔는지 감이 안 잡히면 "그냥 도구가 뱉은 값"으로만 보입니다. 그런데 "아, 이건 볼 페이지를 정하고(수집), 화면을 그려서(렌더), 데이터를 뽑고(추출), 규칙으로 가른(판정) 결과구나"라는 흐름을 알면, 숫자가 근거를 가진 결과로 읽힙니다. 오늘 글은 그 흐름을 처음부터 끝까지 따라가 보는 시간입니다.

미리 한 문장으로 요약하면 이렇습니다. 수집이 "무엇을 볼지"를 정하고, 렌더가 그 페이지를 "진짜 화면으로" 그리고, 추출이 그 화면에서 "데이터를 뽑고", 판정이 그 데이터를 "규칙과 품질 기준으로 가른다." 그리고 이 넷은 따로 노는 게 아니라, 앞 단계가 만든 결과를 뒤 단계가 받아 쓰는 사슬입니다. 수집이 부실하면 렌더가 헛돌고, 렌더가 부실하면 추출이 빈약해지고, 추출이 부실하면 판정이 틀립니다. 그래서 이 네 단계는 "순서"이자 "의존 관계"입니다.

이게 왜 실무에 도움이 되냐면, 파이프라인을 이해하면 "이 도구가 제대로 만든 도구인지"를 가늠하는 눈이 생기기 때문입니다. 지난달 마지막 주에 "기능이 아니라 방법을 보라"고 말씀드렸는데, URL 분석에서 그 "방법"의 상당 부분이 바로 이 네 단계를 어떻게 설계했느냐입니다. 겉의 기능 목록엔 "URL 분석 지원"이라고만 적혀 있지만, 그 한 줄 안에서 네 단계가 얼마나 촘촘하게 도느냐가 결과의 품질을 가릅니다. 오늘은 그 안쪽을 열어 보여드리는 셈입니다.

그리고 이 네 단계는 사실 URL 분석만의 특수한 구조가 아닙니다. 무언가를 대량으로, 자동으로 처리하는 시스템은 대체로 비슷한 골격을 가집니다. "무엇을 처리할지 정하고(수집), 그걸 다룰 수 있는 형태로 만들고(렌더), 필요한 정보를 뽑고(추출), 기준에 따라 판단한다(판정)." 공장 라인도, 서류 심사도 큰 틀은 비슷합니다. 다만 그 골격을 "웹이라는 제각각인 환경"에 적용하는 게 까다롭고, 그걸 얼마나 잘 해냈느냐에서 도구의 실력이 갈립니다. 오늘 그 네 칸을 하나씩 열어 보겠습니다.

본론 1 — 첫 단계: 수집 (무엇을 볼지 정하는 자리)

URL 한 줄에서 "볼 페이지 목록"을 만든다

파이프라인의 첫 칸은 수집입니다. 사용자가 넣는 건 대개 URL 한 줄인데요, 사이트의 대문 주소 하나입니다. 그런데 사이트는 그 한 페이지로 끝나지 않습니다. 메인 아래로 소개, 안내, 신청, 검색, 정책 같은 수많은 페이지가 가지처럼 뻗어 있습니다. 수집 단계는 그 대문에서 시작해 링크를 따라가며 "이 사이트에는 어떤 페이지들이 있는지" 목록을 만드는 일입니다.

이게 왜 첫 단계냐면, 무엇을 볼지 정하지 않으면 그다음이 시작될 수 없기 때문입니다. 렌더도, 추출도, 판정도 결국 "어떤 페이지에 대해" 하는 일이니까요. 대상 목록이 없으면 그 뒤가 다 공중에 뜹니다. 그래서 수집은 파이프라인의 출발점이자, 이후 모든 단계의 "일감"을 정해주는 자리입니다. 수집이 페이지 10개를 잡으면 뒤 단계는 10개를 처리하고, 수집이 200개를 잡으면 200개를 처리합니다. 분석의 범위가 여기서 결정됩니다.

지난달에 "URL 분석은 사이트 전체를 본다"고 말씀드렸는데, 그 "전체"가 실현되는 곳이 바로 이 수집입니다. 메인 한 장만 보는 게 아니라, 링크를 타고 들어가 수십에서 수백 페이지에 이르는 목록을 만들어 냅니다. 사람이 사이트의 모든 페이지를 손으로 하나하나 열어 목록을 만든다고 생각해 보시면, 큰 사이트에서는 사실상 불가능한 일입니다. 자동 수집은 그 지루하고 방대한 목록 작업을 대신해 줍니다. 그래서 "규모"라는 자동화의 강점이 처음 발현되는 지점이기도 합니다.

한 가지 덧붙이면, 수집이 "메인만 보느냐, 사이트를 넓게 보느냐"의 차이가 결과의 신뢰도를 크게 가릅니다. 메인 페이지는 대개 가장 공들여 만든 얼굴이라 문제가 적은 편입니다. 정작 접근성이나 반응형 문제는 신청 페이지, 안내 페이지, 목록 페이지처럼 안쪽으로 들어갈수록 자주 나옵니다. 그래서 메인 한 장만 본 분석은 "괜찮아 보이는" 착시를 주기 쉽고, 수집이 안쪽 페이지까지 넓게 잡아야 사이트의 진짜 상태가 드러납니다. 수집의 넓이가 곧 진단의 정직함으로 이어지는 셈입니다.

거르개: 중복과 불필요를 먼저 뺀다

수집이 그냥 링크를 무작정 다 모으기만 하면 문제가 생깁니다. 웹에는 사실상 같은 내용인데 주소만 조금 다른 페이지가 많습니다. 예를 들어 목록의 1페이지, 2페이지, 3페이지처럼 구조는 똑같고 안의 항목만 바뀌는 경우, 이걸 다 별개로 보면 같은 구조를 수십 번 반복해서 분석하게 됩니다. 낭비이고, 결과도 어수선해집니다. 그래서 수집 단계에는 "거르개"가 필요합니다. 중복되거나 분석 가치가 낮은 페이지를 걸러, 볼 만한 페이지들로 목록을 다듬는 것입니다.

이 거르개가 하는 일은 두 가지입니다. 하나는 정확도입니다. 비슷한 페이지를 걸러 대표적인 유형들을 남기면, 결과가 "이 사이트에는 이런 유형의 페이지들이 있고 각각 이렇더라"로 깔끔하게 정리됩니다. 다른 하나는 효율입니다. 뒤에 오는 렌더 단계는 무거운 작업인데요, 수집에서 불필요한 페이지를 미리 빼면 렌더가 그만큼 덜 돌아도 됩니다. 중복 페이지 수십 개를 앞에서 걸러 내면, 뒤의 무거운 작업 수십 번을 아끼는 셈입니다. 거르개 하나가 정확도와 속도를 동시에 챙기는 것이죠.

다만 이 거르개에도 균형이 필요합니다. 너무 느슨하게 걸러 불필요한 페이지까지 다 통과시키면 뒤가 느려지고, 너무 깐깐하게 걸러 정작 봐야 할 페이지까지 빼 버리면 분석에 구멍이 생깁니다. "불필요한 건 거르되 필요한 건 통과시키는" 그 선을 잘 잡는 게 수집 설계의 핵심입니다. 그래서 좋은 수집은 단순히 "많이 모으는" 게 아니라 "잘 골라 모으는" 것입니다. 양이 아니라 구성이 중요합니다. 사이트의 다양한 페이지 유형이 골고루 목록에 담겨야, 그 사이트의 실제 상태를 대표하는 분석이 됩니다.

수집이 정하는 "분석의 밑그림"

정리하면 수집은 "이 사이트의 어디를 볼 것인가"라는 분석의 밑그림을 그리는 단계입니다. 여기서 잡힌 페이지 목록이 곧 분석의 범위가 되고, 뒤 단계는 그 범위 안에서만 움직입니다. 그래서 수집이 좁으면 아무리 뒤 단계가 정교해도 "메인만 본 얕은 분석"이 되고, 수집이 넓고 균형 잡히면 "사이트 전체를 대표하는 분석"이 됩니다. 결과의 넓이가 여기서 결정되는 셈입니다.

그리고 수집은 비교적 가벼운 단계입니다. 링크를 따라가며 주소를 모으는 일이라, 뒤의 렌더처럼 화면을 통째로 그리는 것에 비하면 부담이 작습니다. 파이프라인이 이 가벼운 수집을 맨 앞에 둔 데는 이유가 있습니다. 가벼운 단계로 먼저 "볼 페이지"를 추린 다음, 무거운 단계를 그 추려진 페이지에만 돌리는 게 효율적이기 때문입니다. 이 "싸고 빠른 것 먼저"라는 순서의 지혜는 본론 5에서 다시 짚겠습니다. 지금은 "수집이 범위를 정하고, 그 범위 위에서 나머지가 돈다" 정도만 잡아 두시면 됩니다.

본론 2 — 둘째 단계: 렌더 (코드가 아니라 화면을 그리는 자리)

실제 브라우저로 페이지를 끝까지 그린다

수집이 볼 페이지를 정했으면, 이제 그 페이지들을 하나씩 "화면으로" 만들어야 합니다. 그게 렌더 단계입니다. 여기서 중요한 개념이 하나 있는데요, ViewCheck는 페이지의 코드(HTML 소스)만 읽는 게 아니라, 실제 브라우저로 그 페이지를 끝까지 그려서 "사용자가 실제로 보는 화면"을 만들어 냅니다. 사람 눈에 화면은 안 띄지만, 내부적으로는 진짜 브라우저가 그 페이지를 여는 것과 같습니다. 이런 방식을 헤드리스 브라우저라고 부릅니다. 화면 없이 도는 진짜 브라우저라는 뜻입니다.

왜 코드만 읽지 않고 굳이 화면까지 그리냐면, 요즘 웹은 코드와 실제 화면이 많이 다르기 때문입니다. 페이지를 처음 받았을 때의 코드에는 뼈대만 있고, 실제 내용은 그 뒤에 여러 스크립트가 돌면서 채워지는 경우가 흔합니다. 코드만 봐서는 "빈 뼈대"만 보이고, 실제로 사용자에게 보이는 완성된 화면은 못 봅니다. 그래서 페이지를 진짜로 끝까지 그려야, 사용자가 보는 그 화면을 기준으로 분석할 수 있습니다. "코드가 아니라 화면을 본다"는 게 렌더 단계의 핵심 태도입니다.

이 차이는 생각보다 큽니다. 코드만 읽는 방식은 빠르지만, 실제로 화면에 무엇이 어떻게 그려지는지는 놓칩니다. 버튼이 화면 어디에 얼마나 큰 크기로 놓이는지, 색이 실제로 어떻게 계산되어 보이는지, 요소들이 겹치지는 않는지 같은 건 화면을 그려 봐야 알 수 있습니다. 사용자는 코드를 읽는 게 아니라 화면을 보고 사이트를 씁니다. 그러니 사용자가 겪는 경험을 정확히 진단하려면, 분석도 그 화면을 기준으로 해야 맞습니다. 렌더는 바로 그 "사용자가 보는 화면"을 재현하는 단계입니다.

그리고 화면을 진짜로 그린다는 건, 페이지가 "다 뜰 때까지 기다린다"는 뜻이기도 합니다. 요즘 페이지는 열자마자 완성되는 게 아니라, 여러 요소가 순차로 로딩되며 화면이 채워집니다. 성급하게 아직 덜 뜬 화면을 붙잡아 분석하면, 실제로는 있는 내용을 "없다"고 잘못 볼 수 있습니다. 그래서 렌더는 페이지가 충분히 그려질 때까지 기다렸다가 화면을 확정합니다. 이 "언제까지 기다렸다가 화면으로 볼 것인가"의 판단이 렌더의 품질을 좌우하는 부분인데요, 잘못 판단하면 빈 화면을 분석하는 사고가 납니다. 이 지점이 어디서 깨지는지는 다음 순서 글에서 더 자세히 다룰 예정입니다.

세 가지 화면 크기로 그린다

렌더는 한 가지 크기로만 그리지 않습니다. 요즘은 같은 페이지라도 데스크톱, 태블릿, 모바일에서 다르게 보이니까요. 그래서 ViewCheck는 세 가지 대표 화면 크기로 페이지를 각각 그려 봅니다. 데스크톱은 1920×1080, 태블릿은 768×1024, 모바일은 390×844 크기입니다. 같은 페이지를 세 화면으로 그려 보면, "데스크톱에서는 멀쩡한데 모바일에서만 깨지는" 문제가 드러납니다.

이게 왜 중요하냐면, 요즘 공공 사이트를 방문하는 사용자의 상당수가 모바일로 들어오기 때문입니다. 그런데 사이트를 만들 때는 대개 큰 화면(데스크톱)을 기준으로 확인하는 경우가 많아서, 작은 화면에서만 생기는 문제가 검수를 빠져나가기 쉽습니다. 요소가 서로 겹치거나, 가로로 스크롤이 생기거나, 글자가 너무 작아지거나 하는 문제들이요. 세 화면 크기로 각각 그려 보면 이런 걸 미리 잡을 수 있습니다. 렌더가 세 벌로 도는 이유가 여기 있습니다.

그리고 렌더 단계에서 함께 챙기는 것 중 하나가 "손으로 누르는 요소의 크기"입니다. 특히 모바일에서는 손가락으로 버튼이나 링크를 누르는데, 이게 너무 작으면 옆의 다른 것을 잘못 누르게 됩니다. 그래서 누를 수 있는 요소는 최소 44×44px 정도의 크기를 갖추는 게 기준으로 통용됩니다. 화면을 실제로 그려서 각 요소의 실제 크기를 재 봐야 이 기준을 확인할 수 있습니다. 코드만 봐서는 "화면에 그려진 실제 크기"를 알 수 없으니까요. 이것도 렌더가 화면을 진짜로 그리기 때문에 가능한 점검입니다.

렌더가 무거운 이유, 그래서 순서상 뒤에 두는 이유

렌더는 파이프라인에서 가장 무거운 단계입니다. 페이지를 진짜로 그리는 일은 시간도, 자원도 꽤 듭니다. 수집이 주소를 모으는 가벼운 일이었다면, 렌더는 그 주소 하나하나를 실제 브라우저로 열어 세 화면 크기로 끝까지 그려야 하니까요. 페이지 하나에도 여러 요소가 로딩되고 스크립트가 돌아야 완성됩니다. 그래서 렌더는 "비싼" 단계입니다.

바로 이 점 때문에 파이프라인이 수집을 앞에, 렌더를 뒤에 둡니다. 만약 순서를 거꾸로 해서 아무 페이지나 다 렌더부터 하면, 나중에 걸러 낼 불필요한 페이지까지 무겁게 그리느라 낭비가 큽니다. 반대로 가벼운 수집으로 볼 페이지를 먼저 추린 다음, 그 추려진 페이지에만 무거운 렌더를 돌리면 낭비가 없습니다. 식당 주방에 비유하면, 주문을 받고(수집) 필요한 재료만 손질해서 불에 올리는(렌더) 것과 같습니다. 손질도 안 하고 아무거나 다 불부터 올리면 주방이 엉키듯, 렌더도 걸러진 페이지에만 집중해야 효율적입니다.

또 렌더는 파이프라인의 "병목"이기도 합니다. 가장 무거운 단계라 여기서 시간이 제일 많이 걸립니다. 그래서 전체 분석 속도를 좌우하는 게 이 렌더 단계인데요, 앞의 수집에서 페이지를 잘 걸러 렌더에 들어가는 양을 줄여 주면 전체가 빨라집니다. 병목 앞에서 양을 줄이는 게 요령입니다. 그리고 렌더 자체도, 까다로운 페이지(끝없이 이어지는 목록, 늦게 뜨는 요소 등)에서 어떻게 버티느냐가 도구의 실력을 가릅니다. 이 "어디서 깨지고 어떻게 버티나"는 렌더만으로도 큰 주제라, 다음 순서 글에서 더 깊게 다룰 예정입니다. 오늘은 "렌더가 화면을 진짜로 그리는, 가장 무거운 단계"라는 정도로 잡아 두시면 됩니다.

본론 3 — 셋째 단계: 추출 (그려진 화면에서 데이터를 뽑는 자리)

구조(DOM)와 실제 계산값(computed style)

렌더가 화면을 그렸으면, 이제 그 화면에서 분석에 쓸 데이터를 뽑아야 합니다. 그게 추출 단계입니다. 여기서 뽑는 데이터는 크게 몇 갈래인데요, 먼저 화면의 "구조"입니다. 페이지가 어떤 요소들로 이루어져 있는지, 버튼이 몇 개고 입력창이 어디 있고 제목의 위계가 어떻게 짜여 있는지 같은 뼈대 정보입니다. 이 구조 정보를 흔히 DOM이라고 부르는데요, 화면을 이루는 요소들의 짜임새라고 이해하시면 됩니다.

그런데 구조만으로는 부족합니다. "이 버튼이 실제로 어떤 색으로, 얼마나 큰 크기로, 얼마의 간격을 두고 그려졌는가"라는 실제 계산값이 필요합니다. 이걸 computed style, 즉 "계산된 실제 값"이라고 합니다. 코드에 적힌 값이 아니라, 브라우저가 그 페이지를 그리면서 최종적으로 계산해 낸 실제 값입니다. 예를 들어 색은 여러 설정이 겹쳐 최종적으로 결정되는데요, 이 최종값을 봐야 "실제로 화면에 이 색으로 보인다"를 정확히 알 수 있습니다. 렌더가 화면을 진짜로 그렸기 때문에, 추출이 이 실제 계산값을 가져올 수 있는 것입니다.

이 두 가지, 구조와 실제 계산값을 함께 뽑는 게 추출의 기본입니다. 구조는 "무엇이 있는가"를, 실제 계산값은 "그게 실제로 어떻게 그려졌는가"를 알려 줍니다. 뒤의 판정 단계에서 "이 색이 표준 색과 맞나", "이 버튼이 규격 크기를 지켰나", "이 간격이 기준에 맞나" 같은 걸 가리려면 이 실제 값이 반드시 필요합니다. 그래서 추출은 판정을 위한 "재료 손질" 단계라고 볼 수 있습니다. 재료(데이터)가 정확하고 충분해야, 뒤의 판정이 정확해집니다.

화면을 눈으로 보는 시각 AI

구조와 실제 계산값만으로 못 잡는 것도 있습니다. 예를 들어 어떤 사이트는 버튼이나 아이콘을 표준적인 방식이 아니라 이미지나 그림으로 만들어 둡니다. 이런 건 구조 정보만 봐서는 "여기 버튼이 있다"는 걸 알기 어렵습니다. 사람 눈으로 화면을 보면 "아, 저건 버튼이네" 싶은데, 구조 데이터에는 그게 안 드러나는 경우죠. 이런 빈틈을 메우려고 추출 단계에서 "화면을 눈으로 보는" 방식도 함께 씁니다. 화면 이미지를 보고 "여기 버튼, 여기 입력창, 여기 카드"처럼 컴포넌트를 감지하는 시각 AI입니다.

이 시각 AI가 하는 일은, 구조 데이터가 놓친 시각적 요소를 화면 자체에서 찾아 주는 것입니다. 그래서 구조로 못 본 것을 화면으로 보완하는 셈입니다. 다만 여기엔 중요한 원칙이 있는데요, 시각 AI는 "빈칸을 채우는" 역할만 합니다. 구조와 실제 계산값으로 이미 명확히 판정된 것은 시각 AI가 뒤집지 않고, 판정이 안 된 빈칸(해당 없음으로 남은 자리)만 화면을 보고 채웁니다. 그리고 확신이 있을 때만 채웁니다. 화면에서 확실히 감지되지 않으면 억지로 "있다"고 우기지 않고 빈칸을 그대로 둡니다. 없는 걸 있다고 지어내지 않는다는 뜻입니다. 이 원칙이 있어야 시각 AI가 오히려 결과를 어지럽히지 않고 정확하게 보완합니다.

이렇게 "구조 + 실제 계산값 + 시각 AI"를 함께 쓰는 이유는, 어느 하나만으로는 화면을 완전히 읽을 수 없기 때문입니다. 구조는 짜임새를 정확히 알려 주지만 시각적으로 표현된 것은 놓치고, 시각 AI는 화면에 보이는 걸 잡지만 구조의 세밀한 속성까지는 못 봅니다. 둘을 겹쳐 보면 서로의 빈틈을 메웁니다. 사람으로 치면, 페이지의 뼈대 설명서(구조)를 읽으면서 동시에 실제 화면(시각)을 눈으로 확인하는 것과 같습니다. 한쪽만 보는 것보다 훨씬 정확하게 화면을 파악하게 됩니다.

여기서 "확신이 있을 때만 채운다"는 원칙을 다시 강조하고 싶습니다. 시각 AI가 화면을 보다 보면, 애매하게 보이는 것들이 있습니다. 이럴 때 억지로 "버튼이 있다"고 단정하면, 실제로는 없는 걸 있다고 만드는 셈이 됩니다. 이런 지어냄이 쌓이면 결과 전체를 못 믿게 됩니다. 그래서 확실히 감지될 때만 빈칸을 채우고, 애매하면 빈칸을 그대로 두는 게 원칙입니다. 결과가 조금 덜 채워지더라도, 채워진 것은 믿을 수 있게 하는 쪽을 택하는 것입니다. "많이 채우는" 것보다 "정확히 채우는" 게 진단에서는 훨씬 값집니다.

이미지 속 글자는 필요할 때만 읽는다

추출에서 한 가지 오해하기 쉬운 부분을 짚고 가겠습니다. 화면에는 그림처럼 이미지 안에 글자가 박혀 있는 경우가 있습니다. 예를 들어 배너 이미지 안에 안내 문구가 글자가 아니라 그림으로 들어가 있는 식입니다. 이런 이미지 속 글자를 읽어 내는 기술을 OCR이라고 하는데요, ViewCheck도 이 기능을 갖추고 있습니다. 다만 이걸 "항상 도는 필수 단계"로 오해하시면 안 됩니다.

OCR은 상시로 돌리는 게 아니라, 필요할 때만 쓰는 보완 수단입니다. 이미지로 박힌 텍스트를 확인해야 하거나, 페이지가 어떤 유형인지 판단하는 데 화면의 글자가 도움이 될 때처럼요. 대부분의 추출은 구조와 실제 계산값, 그리고 시각 AI로 이루어지고, OCR은 그중에서도 "이미지 안의 글자"라는 특정 상황을 위한 보조 도구입니다. 그래서 OCR을 URL 분석의 항상 필수인 핵심 단계처럼 부풀려 이해하실 필요는 없습니다. "필요할 때 꺼내 쓰는 보완 수단" 정도가 정확한 위치입니다.

정리하면, 추출은 렌더가 그린 화면에서 "구조(DOM), 실제 계산값(computed style), 시각적 감지"를 뽑아내고, 필요하면 이미지 속 글자(OCR)까지 보완하는 단계입니다. 여기서 뽑힌 데이터가 다음 판정 단계의 재료가 됩니다. 재료가 정확하고 풍부할수록 판정이 정확해지니, 추출은 "판정의 품질을 미리 결정하는" 자리이기도 합니다. 좋은 추출이 좋은 판정을 만듭니다.

본론 4 — 넷째 단계: 판정 (규칙과 품질 기준으로 가르는 자리)

846규칙, 네 카테고리로 가른다

추출이 데이터를 뽑았으면, 마지막으로 그 데이터를 기준에 비추어 "맞나 틀리나"를 가려야 합니다. 그게 판정 단계입니다. 판정의 중심에는 KRDS 규칙 846개가 있습니다. 이 846개는 성격에 따라 네 갈래로 나뉩니다. 디자인 스타일(DS) 120개, 컴포넌트(CP) 446개, 기본 패턴(BP) 108개, 서비스 패턴(SP) 172개입니다. 더하면 정확히 846개가 됩니다.

각 카테고리가 보는 게 다른데요, 간단히 짚으면 이렇습니다. 디자인 스타일(DS)은 색·글자·간격·정렬 같은 시각 요소가 기준에 맞는지를 봅니다. 컴포넌트(CP)는 버튼·입력창·내비게이션·카드·표 같은 UI 요소가 규격에 맞는지를 보는데, 네 카테고리 중 항목이 가장 많습니다. 기본 패턴(BP)은 폼 구조, 동의·확인 흐름, 오류 처리 같은 상호작용 패턴을 봅니다. 서비스 패턴(SP)은 검색·로그인·신청·정책 안내 같은 서비스 단위 흐름을 봅니다. 이 네 카테고리의 성격 차이와 깊은 내용은 5개월차에서 하나씩 자세히 다룰 예정이라, 오늘은 "846개가 이렇게 네 갈래로 판정된다" 정도만 잡으시면 됩니다.

판정은 각 규칙에 대해 대개 세 가지 중 하나로 결론을 냅니다. 통과, 미통과, 그리고 해당 없음입니다. 통과와 미통과는 말 그대로 기준을 맞췄는지 여부이고, 해당 없음은 그 페이지에 해당 요소가 아예 없어서 판정 대상이 아닌 경우입니다. 예를 들어 표가 없는 페이지에서는 표 관련 규칙이 해당 없음이 됩니다. 이 세 갈래를 정확히 나누는 게 판정의 기본인데요, 특히 "해당 없음"을 "미통과"와 헷갈리지 않게 구분하는 게 중요합니다. 이 부분은 뒤에서 다시 짚겠습니다.

규칙만이 아니라 품질 영역까지

판정 단계는 846규칙만 가리는 게 아닙니다. 행정안전부의 「전자정부 웹사이트 품질관리 지침」이 정한 일곱 가지 품질 영역도 함께 봅니다. 호환성, 접근성, 개방성, 접속성, 편의성, 효율성, 신뢰성 이렇게 일곱입니다. 이 영역들은 디자인 규격 준수와는 또 다른 각도에서 사이트의 품질을 봅니다. 장애가 있는 사용자도 쓸 수 있는지(접근성), 보안이 제대로 되어 있는지(신뢰성), 페이지가 빠르고 안정적으로 뜨는지(효율성) 같은 것들이죠.

특히 이 일곱 영역 중 일부는 실제로 사이트에 접속해 응답을 받아 봐야 판정할 수 있습니다. 예를 들어 보안 설정이나 인증서 상태, 응답 속도 같은 건 페이지를 열어 서버와 실제로 주고받아 봐야 알 수 있는 정보입니다. 렌더 단계에서 실제 브라우저로 페이지를 진짜로 열기 때문에, 이런 접속 기반의 정보도 함께 확인할 수 있습니다. 그래서 판정 단계에서는 846규칙 준수와 이 일곱 품질 영역을 아울러, 사이트를 여러 각도에서 종합적으로 가릅니다. 지난달에 "URL 분석은 스무 개가 넘는 영역을 본다"고 말씀드렸는데, 그 넓은 판정이 실현되는 곳이 바로 이 단계입니다.

그리고 판정 결과는 그냥 "맞다 틀리다"로 끝나지 않고, 위반의 심각도까지 함께 매겨집니다. 위반이 다 같은 무게가 아니어서, 사용자에게 치명적인 것과 사소한 것을 구분해야 하니까요. 흔히 P0부터 P3까지의 등급으로 나누는데, 신청 버튼을 아예 못 누르게 만드는 위반은 최상위 등급이고, 잘 안 쓰는 페이지의 사소한 간격 어긋남은 아래 등급입니다. 이 위험도 등급화의 원리는 4개월차에서 자세히 다룹니다. 오늘은 "판정이 통과·미통과·해당 없음을 가르면서, 위반에는 심각도까지 붙인다" 정도로 이해하시면 됩니다.

두 엔진의 분업

판정을 누가 하느냐도 중요한 이야기입니다. ViewCheck의 판정에는 성격이 다른 두 엔진이 함께 일합니다. 하나는 규칙 엔진입니다. 추출한 구조와 실제 계산값 같은 데이터를 읽어, 규칙 하나하나에 대해 통과·미통과·해당 없음을 빠르게 가려냅니다. 코드와 데이터를 기준으로 판정하는 엔진이라 빠르고 명확합니다. 다른 하나는 앞서 추출에서 소개한 시각 AI 엔진입니다. 화면을 눈으로 보고 컴포넌트를 감지해, 규칙 엔진이 데이터만으로는 못 채운 빈칸을 보완합니다.

이 둘의 분업에는 분명한 규칙이 있습니다. 규칙 엔진이 데이터로 이미 통과나 미통과로 "확정한" 판정은, 시각 AI가 함부로 뒤집지 않습니다. 시각 AI는 어디까지나 "해당 없음"으로 남은 빈칸만 화면을 보고 채우는 역할입니다. 그것도 확신이 있을 때만 채웁니다. 화면에서 확실히 감지되면 그 빈칸을 통과나 미통과로 바꾸고, 확실치 않으면 빈칸을 그대로 둡니다. 없는 걸 지어내지 않는 것이죠. 그리고 시각 AI가 빈칸을 채울 때는 "무엇을 보고 그렇게 판단했는지" 근거를 남깁니다. 그래야 나중에 그 판정을 확인할 수 있습니다.

왜 이렇게 역할을 나누냐면, 두 방식의 강점이 다르기 때문입니다. 규칙 엔진은 데이터로 명확히 가릴 수 있는 것을 빠르고 정확하게 처리하고, 시각 AI는 데이터로는 안 잡히는 시각적 요소를 화면에서 잡습니다. 규칙 엔진이 판정한 걸 시각 AI가 뒤집게 두면 오히려 결과가 흔들리니, "확정된 건 유지하고, 빈칸만 신중하게 채운다"는 원칙으로 둘의 강점을 안전하게 합칩니다. 이렇게 하면 빠른 데이터 판정과 시각적 보완을 모두 얻으면서도, 결과가 어지러워지지 않습니다.

이 분업을 흔한 오해와 구분해 두는 게 좋겠습니다. "AI가 분석한다"고 하면 흔히 "AI가 화면을 보고 알아서 다 판정한다"고 상상하기 쉽습니다. 그런데 그런 방식은 그럴듯해 보여도 근거가 흔들리기 쉽습니다. AI가 "그렇게 보인다"고 말하는 것과, 데이터로 "이 값이 기준을 벗어났다"고 가리는 것은 신뢰의 무게가 다릅니다. ViewCheck는 판정의 중심을 데이터 기반 규칙 엔진에 두고, 시각 AI는 그것을 보완하는 자리에 둡니다. AI를 안 쓰는 게 아니라, AI를 "데이터가 못 보는 빈칸"이라는 제자리에 신중하게 쓰는 것입니다. 이 균형이 "그럴듯한 분석"과 "근거 있는 분석"의 차이를 만듭니다.

못 채운 건 "해당 없음"으로 정직하게

판정 단계에서 가장 중요한 태도 하나가 정직함입니다. 앞서 말한 "해당 없음"이 바로 그 정직함이 드러나는 자리인데요, 그 페이지에 해당 요소가 없어서 판정이 안 된 것은, 억지로 통과나 미통과로 밀어 넣지 않고 "해당 없음"으로 솔직하게 남깁니다. 이걸 미통과로 처리하면 멀쩡한 걸 문제로 세는 셈이 되고, 통과로 처리하면 안 본 걸 봤다고 우기는 셈이 됩니다. 둘 다 결과를 왜곡합니다. 그래서 판정은 "본 것은 본 대로, 못 본 것은 못 봤다고" 구분해서 남깁니다.

이 정직함이 왜 중요한지는, 결과를 읽는 사람 입장에서 생각하면 분명해집니다. 만약 "해당 없음"을 다 통과로 섞어 버리면, 준수율이 실제보다 높아 보이는 착시가 생깁니다. 반대로 다 미통과로 섞으면 실제보다 나빠 보입니다. 어느 쪽이든 사이트의 진짜 상태를 왜곡합니다. "해당 없음"을 따로 구분해 남겨야, 사용자가 "실제로 판정된 건 몇 개이고, 그중 통과가 몇이고 미통과가 몇인지"를 정확히 읽을 수 있습니다. 지난달에 "N/A를 미통과로 오해하지 말라"고 말씀드린 게 바로 이 이야기입니다. 이 "해당 없음"을 어떻게 줄이고 채우는지는 8개월차에서 깊게 다룹니다.

그리고 이 정직함은 커버리지, 즉 "얼마나 봤나"로도 이어집니다. 판정 결과는 "846규칙 중 몇 개를 실제로 판정했고, 수집한 페이지 중 몇 개를 분석했는지"를 함께 보여 줍니다. 이게 있어야 사용자가 결과를 제대로 읽습니다. 판정 비율이 높으면 촘촘히 본 것이고, 낮으면 그만큼 판정 못 한 부분이 많다는 뜻이니까요. 다 봤다고 우기지 않고 "여기까지 봤고 이건 못 봤다"를 정직하게 보여 주는 게, 역설적으로 더 믿을 만한 결과입니다. 이 커버리지를 드러내는 태도가 파이프라인 전체에 깔린 원칙이기도 합니다.

본론 5 — 네 단계가 이어지는 흐름

앞 단계의 산출물이 다음 단계의 재료

지금까지 네 단계를 하나씩 봤는데요, 이제 이 넷이 어떻게 이어지는지 흐름으로 다시 정리하겠습니다. 핵심은 "앞 단계가 만든 결과가 다음 단계의 입력이 된다"는 점입니다. 수집이 만든 페이지 목록이 렌더의 일감이 되고, 렌더가 그린 화면이 추출의 재료가 되고, 추출이 뽑은 데이터가 판정의 근거가 됩니다. 각 단계는 앞에서 받은 것을 처리해 다음으로 넘깁니다. 그래서 이 파이프라인은 낱개의 기능들이 아니라, 하나로 이어진 사슬입니다.

이 사슬 구조가 왜 중요하냐면, 한 단계의 품질이 그다음 모든 단계에 영향을 주기 때문입니다. 수집이 페이지를 잘 골라 넘기면 렌더가 볼 만한 것만 그리고, 렌더가 화면을 제대로 그리면 추출이 정확한 데이터를 뽑고, 추출이 풍부한 데이터를 넘기면 판정이 촘촘해집니다. 반대로 앞 단계가 부실하면 그 부실함이 뒤로 그대로 전해집니다. 그래서 각 단계는 "다음 단계에 깨끗한 입력을 넘긴다"는 책임을 집니다. 단계 사이마다 거르개를 두는 것도 이 때문입니다. 앞에서 걸러 다음에 깨끗한 재료를 넘겨야, 뒤가 헛돌지 않습니다.

이걸 요리에 비유하면 이해가 쉽습니다. 장을 보고(수집), 재료를 손질해 불에 올리고(렌더), 익은 재료에서 먹을 부분을 발라내고(추출), 접시에 담아 맛을 내는(판정) 과정과 같습니다. 장을 잘못 보면 손질할 재료가 없고, 손질을 대충 하면 발라낼 게 부실하고, 발라낸 게 부실하면 아무리 좋은 접시에 담아도 요리가 초라합니다. 각 단계가 다음 단계에 좋은 재료를 넘겨야 마지막 요리가 좋습니다. 파이프라인도 똑같습니다.

그래서 결과 화면에 뜬 준수율 하나를 보더라도, 그 숫자 뒤에는 이 네 단계가 다 담겨 있다고 이해하시면 됩니다. 그 준수율은 "수집이 이만큼의 페이지를 잡았고, 렌더가 그 화면을 그렸고, 추출이 이런 데이터를 뽑았고, 판정이 이렇게 갈랐다"는 사슬의 최종 요약입니다. 그러니 숫자가 낮게 나왔을 때 "왜 낮지"를 따지려면, 판정만이 아니라 그 앞 단계까지 거슬러 올라가 볼 수 있습니다. 어느 페이지를 봤는지(수집), 화면이 제대로 그려졌는지(렌더), 데이터가 충분했는지(추출)를요. 파이프라인을 알면 결과를 이렇게 근거까지 되짚어 읽게 됩니다. 숫자를 그냥 받아들이는 게 아니라, 그 숫자가 어느 단계에서 만들어졌는지 따라갈 수 있게 되는 것입니다.

한 곳이 부실하면 뒤가 다 흔들린다

이 사슬 구조의 뒷면은, "한 단계라도 부실하면 전체 결과가 흔들린다"는 것입니다. 수집이 메인 한 장만 잡으면, 뒤 단계가 아무리 정교해도 "메인만 본 얕은 분석"이 됩니다. 렌더가 화면을 제대로 못 그리면(예를 들어 내용이 뜨기 전에 성급하게 그림을 멈추면), 추출이 빈 화면에서 데이터를 뽑아 결과가 휑해집니다. 추출이 데이터를 놓치면, 판정이 있어야 할 규칙을 "해당 없음"으로 잘못 남깁니다. 각 단계의 약점이 다음으로 번지는 것이죠.

그래서 좋은 URL 분석이란 "네 단계가 모두 탄탄한" 것입니다. 어느 하나가 특별히 화려한 게 아니라, 넷이 고르게 촘촘하고 서로에게 좋은 입력을 넘기는 것입니다. 그리고 이건 겉으로는 잘 안 드러납니다. 쉬운 사이트 한두 개만 돌려 보면 어느 도구든 결과가 그럴듯하게 나오니까요. 차이는 까다로운 사이트, 큰 사이트에서 드러납니다. 페이지가 수백 개인 사이트, 내용이 늦게 뜨는 사이트, 표준을 벗어난 방식으로 만든 사이트를 만나면, 어느 단계가 약한지가 결과에 그대로 나타납니다.

이 점이 지난달부터 말씀드린 "겉으로 안 보이는 방법"의 실체입니다. 기능 목록에는 "URL 분석"이라고만 적혀 있지, 이 네 단계가 얼마나 탄탄한지는 안 적혀 있습니다. 그러니 도구를 평가하려면 결과 화면만 보지 말고, 까다로운 사이트로 직접 돌려서 네 단계가 다 버티는지를 봐야 합니다. 그게 파이프라인을 이해하는 실용적인 이유입니다.

왜 이 순서인가 — 싸고 빠른 것 먼저

마지막으로 순서 이야기를 정리하겠습니다. 파이프라인은 수집 → 렌더 → 추출 → 판정 순인데요, 이 순서에는 이유가 있습니다. 싸고 빠른 단계를 먼저, 무겁고 비싼 단계를 뒤에 두는 것입니다. 수집은 가볍고, 렌더는 무겁고, 추출과 판정은 그 사이입니다. 가벼운 수집으로 "볼 페이지"를 먼저 정한 다음, 무거운 렌더를 그 페이지들에만 돌려야 자원을 아낍니다.

만약 순서를 거꾸로 하면 어떻게 될까요. 아무 페이지나 다 렌더부터 하고 나서 거른다면, 나중에 버릴 페이지까지 무겁게 그리느라 시간과 자원을 낭비합니다. 그래서 "무거운 작업 앞에서 양을 줄이는" 게 순서의 핵심입니다. 파이프라인에서 제일 무거운 렌더가 병목인데, 그 병목에 들어가는 페이지 수를 앞의 수집에서 줄여 주면 전체가 빨라집니다. 순서는 그냥 차례가 아니라, "비싼 자원을 어디에 아껴 쓰느냐"라는 전략입니다.

이 "싸고 빠른 것 먼저"의 지혜는 파이프라인 안 여러 곳에서 반복됩니다. 판정에서도 두 엔진이 "데이터로 빠르게 먼저 가르고, 화면으로 빈칸만 보완"하는 순서를 따릅니다. 데이터 판정이 빠르니 먼저 하고, 화면을 보는 무거운 일은 남은 빈칸에만 하는 것입니다. 결국 전체 파이프라인의 순서 원리와 같습니다. 가벼운 것으로 최대한 처리하고, 무거운 것은 꼭 필요한 데만. 이 원리가 "빠르면서 정확한" 분석을 만듭니다.

본론 6 — 도구를 볼 때 이 네 단계를 보면 됩니다

파이프라인을 이해했으니, 이걸 실용적으로 어떻게 쓰는지 정리하겠습니다. 앞으로 URL 분석 도구를 보게 되면, 이 네 단계로 뜯어 보면 됩니다. "볼 페이지를 넓고 균형 있게 잡나(수집)", "코드가 아니라 실제 화면을 그리나(렌더)", "구조와 실제 값과 시각을 아울러 뽑나(추출)", "규칙과 품질을 정직하게 가르나(판정)". 이 네 가지를 확인하면 그 도구의 뼈대가 튼튼한지 감이 옵니다.

구체적으로 이렇게 시험해 보시면 됩니다. 페이지가 많은 큰 사이트를 넣어 보고 "메인만 보는지, 여러 페이지를 넓게 잡는지"를 봅니다(수집). 데스크톱과 모바일에서 다르게 보이는 사이트를 넣어 보고 "화면 크기별 차이를 잡아내는지"를 봅니다(렌더). 표준을 좀 벗어난 방식으로 만든 요소가 있는 페이지를 넣어 보고 "그것도 감지하는지"를 봅니다(추출). 그리고 결과에서 "통과·미통과·해당 없음이 구분돼 있고, 몇 개를 실제로 판정했는지 커버리지가 보이는지"를 봅니다(판정). 이 네 가지만 확인해도 그 도구의 파이프라인이 탄탄한지 약한지 드러납니다.

쉬운 사이트로만 데모하면 어느 도구든 비슷해 보입니다. 그런데 이렇게 네 단계를 부러 까다롭게 시험하면 차이가 확 납니다. 그리고 이 네 단계는 앞으로 이 시리즈에서 하나씩 더 깊게 파고들 예정입니다. 렌더가 어디서 깨지는지, 추출한 데이터로 어떻게 846규칙을 판정하는지, 준수율이라는 숫자가 어떻게 만들어지는지 같은 걸 이어서 다루겠습니다. 오늘은 그 전체 골격을 먼저 열어 본 셈입니다. 골격을 알면 세부가 훨씬 잘 들어옵니다.

한 가지만 더 당부드리면, 이 네 단계를 시험할 때는 "우리 기관과 비슷한 규모, 비슷한 성격의 사이트"로 해 보시는 게 좋습니다. 남의 잘 만든 사이트로 돌리면 어느 도구든 무난한 결과가 나오니 변별이 안 됩니다. 우리가 실제로 관리하는, 페이지 많고 손이 여기저기 닿은 사이트로 돌려 봐야 네 단계의 실력이 진짜로 드러납니다.

그래서 ViewCheck는

ViewCheck의 URL 분석도 이 네 단계로 돕니다. 사용자가 URL 한 줄을 넣으면, 가벼운 수집으로 볼 페이지를 넓게 정하고, 실제 브라우저로 그 페이지들을 세 화면 크기로 끝까지 그리고, 그려진 화면에서 구조와 실제 계산값과 시각적 요소를 뽑고, 그 데이터를 846규칙과 일곱 품질 영역으로 가릅니다. 그리고 못 판정한 부분은 "해당 없음"으로, 못 본 페이지는 커버리지로 정직하게 남깁니다. 지난달에 본 그 "넓고 재현 가능한 진단"이, 이 네 단계 위에서 만들어집니다.

이게 화려한 기능은 아닙니다. 사용자 눈에는 "URL 넣으니 결과가 잘 나오네" 정도로만 보입니다. 그런데 그 매끄러운 결과 뒤에 이 네 단계가 촘촘히 돌고 있습니다. 지난달부터 계속 말씀드린 "겉으로 안 보이는 방법"의 가장 밑바닥이 바로 이 파이프라인입니다. 화면에 뜨는 준수율, 위반 목록, 위험 등급, 비교 같은 결과는 전부 이 네 단계라는 토대 위에 섭니다. 토대가 흔들리면 그 위가 다 부실해지니, 사실 이 파이프라인이 가장 안 보이지만 가장 중요한 부분입니다.

솔직히 이 네 단계라는 골격 자체는 ViewCheck만의 비밀이 아닙니다. 대량 자동화를 제대로 해 본 곳이면 대체로 비슷한 구조로 갑니다. 차이는 "그 골격을 웹이라는 제각각인 환경에 얼마나 끈질기게 적용했나"에서 납니다. 수많은 까다로운 사이트를 만나며 "이건 왜 안 됐지"를 하나씩 고쳐 온 누적이, 같은 네 단계라도 결과를 가릅니다. 원칙은 알려져 있어도, 그걸 현실에 적용한 깊이는 쉽게 따라 하기 어렵습니다. 그래서 겉의 기능 목록이 아니라, 까다로운 사이트로 직접 돌려 그 깊이를 확인해 보시길 권합니다.

🔐 특허로 지키는 부분

오늘 본 네 단계 중 "실제 화면을 그려서, 그 화면에서 시각 요소를 재현 가능하게 뽑아내고 측정하는 방법"은 ViewCheck가 출원한 다섯 건의 특허 중 시각 요소 분석(스크린샷 기반 측정) 주제와 맞닿아 있습니다. 다만 솔직히 짚으면, 수집 → 렌더 → 추출 → 판정이라는 네 단계 골격 자체는 대량 자동화의 일반적인 구조에 가깝습니다. 특허로 지킨 건 그 골격 위에서 "화면을 어떻게 재현 가능하게 측정하고, 흩어진 판정을 어떻게 한 기준으로 정리하느냐"의 방법입니다. 골격은 공유된 상식, 그 위의 측정과 정리 방법이 차별점 — 이 구분을 정확히 해 두는 게 정직한 표현입니다.

그리고 특허는 "방법을 지키는 장치"이지 "품질 보증서"가 아닙니다. 파이프라인이 실제로 잘 도느냐는 오늘 본 네 단계가 현실에서 얼마나 촘촘하게 적용됐느냐로 결정되는 것이고, 특허는 그 위의 측정 방법을 보호하는 것입니다. 그래서 "특허가 있으니 믿으세요"가 아니라 "이 방법을 직접 만들고 지켜 두었다" 정도로 받아들여 주시면 됩니다. 참고로 현재는 다섯 건 모두 등록이 아니라 출원 상태입니다. "등록특허"가 아니라 "출원 기술"로 정확히 표기합니다. (특허 출원 기술 / 자체 개발)

마무리

오늘로 2개월차 첫 주, URL 분석 심층의 문을 열었습니다. URL 한 줄이 결과 화면이 되기까지 안에서 도는 네 단계 — 수집(볼 페이지를 정하고), 렌더(실제 화면을 그리고), 추출(그 화면에서 데이터를 뽑고), 판정(규칙과 품질로 가른다) — 을 처음부터 끝까지 따라가 봤습니다. 이 넷은 따로 노는 기능이 아니라, 앞의 결과가 뒤의 재료가 되는 하나의 사슬입니다. 한 단계가 부실하면 뒤가 다 흔들리고, 넷이 고르게 탄탄해야 까다로운 사이트도 안정적으로 봅니다.

한 줄로 줄이면 이렇습니다. 수집이 무엇을 볼지 정하고, 렌더가 그걸 진짜 화면으로 그리고, 추출이 그 화면에서 데이터를 뽑고, 판정이 그 데이터를 규칙과 품질로 가른다. 이 네 단계가 안 보이는 토대를 이루고, 그 위에 우리가 화면에서 보는 모든 분석 결과가 섭니다. 다음에 URL 분석 도구를 볼 일이 있으면, 결과 화면만 보지 마시고 까다로운 사이트로 한번 돌려서 이 네 단계가 다 버티는지 시험해 보시길 바랍니다.

다음 순서부터는 이 네 단계를 하나씩 더 깊게 파고듭니다. 렌더가 어디서 깨지고 어떻게 버티는지, 추출한 데이터로 어떻게 846규칙 판정과 준수율이 만들어지는지를 이어서 풀겠습니다. 오늘은 전체 골격을 열어 봤으니, 이제 그 안으로 한 칸씩 들어갈 차례입니다. 이번 주도 끝까지 읽어 주셔서 고맙습니다. 다음 글에서 다시 뵙겠습니다.

krds.viewcheck.co.kr