URL 한 줄만 넣으면 벌어지는 일 — '분석 중…' 뒤에서 도는 네 단계

---

들어가며 — 심층 편의 첫 타자, URL 분석

지난달 한 달은 ViewCheck가 웹 품질을 보는 세 가지 시점(설계·운영·판단)을 개요로 한 바퀴 훑는 오리엔테이션이었습니다. 만들기 전에 보는 설계 시점, 만든 뒤에 보는 운영 시점, 그 위에서 판단을 얹는 시점. 그리고 한 시점만 보면 절반만 보인다는 이야기를 내내 드렸습니다. 이번 달부터는 드디어 심층 편입니다. 첫 타자는 그 세 시점 중에서도 중심축인 운영 시점, 곧 URL 분석입니다.

지난달 내내 "URL만 넣으면 사이트를 자동으로 보고 결과를 준다"고 말씀드렸습니다. 그런데 그 "자동으로 본다"는 한마디 안에는 사실 꽤 많은 일이 숨어 있습니다. 오늘은 그 뚜껑을 열어보려 합니다. URL 한 줄을 넣고 엔터를 치면, 그 뒤에서 무슨 단계들이 도는지. 화면에는 "분석 중…"이라는 안내만 떠 있지만, 그 몇십 초 동안 안쪽에서 무엇이 벌어지는지를 개념 수준에서 풀어보겠습니다.

이게 왜 중요하냐면, 이 파이프라인이 제대로 돌지 않으면 그 위의 모든 분석이 다 부실해지기 때문입니다. 지난달 매핑에서 시각 요소를 다루는 첫 번째 영역을 "토대"라고 불렀는데, 오늘 다루는 게 바로 그 토대입니다. 화면을 제대로 수집하고 그려내지 못하면, KRDS 846규칙 판정도, 위험 등급도, 비교도 다 모래 위에 짓는 셈입니다. 그래서 심층 편을 화려한 결과 화면이 아니라 이 토대부터 시작하려는 것입니다.

오늘은 그 파이프라인을 크게 네 단계로 나눠 보겠습니다. URL 수집 → 렌더링 → 추출 → 판정. 각 단계가 무엇을 하고, 왜 필요하며, 어디가 까다로운지를 차례로 짚겠습니다. 참고로 이 흐름은 ViewCheck가 출원한 기술(출원 중) 중 하나의 토대이기도 합니다. 그 이야기도 뒤에 곁들이겠습니다.

아래는 그 네 단계가 다 돌고 난 뒤, 정리된 결과가 한 화면에 모이는 모습입니다. 오늘 우리가 다루는 건 이 깔끔한 결과 화면 "뒤에서" 벌어지는 일입니다. 결과는 이렇게 한 장으로 단정해 보이지만, 그 단정함은 뒤의 네 단계가 묵묵히 받쳐주기 때문에 나오는 것입니다.

미리 한 가지 비유를 깔아두면 따라오기 쉽습니다. 이 파이프라인은 사진관에서 단체사진을 찍는 일과 비슷합니다. 먼저 "누구누구를 찍을지" 명단을 잡고(수집), 다들 자리에 제대로 서게 하고 조명까지 맞춰 화면을 만들고(렌더링), 셔터를 눌러 찍어 정리해 앨범으로 만들고(추출), 그 앨범을 기준과 대조해 "잘 나왔나 아닌가"를 가립니다(판정). 어느 한 단계가 엉성하면 — 명단이 빠지거나, 덜 준비됐을 때 찍거나, 흐리게 찍거나, 기준 없이 대충 넘어가거나 — 결과물이 망가집니다. URL 분석도 똑같습니다. 네 단계가 다 제대로 돌아야 쓸 만한 결과가 나옵니다.

한 가지 미리 말씀드리면, 오늘은 파이프라인의 "큰 단계"만 개념으로 봅니다. 각 단계 안에서 더 깊은 이야기 — 렌더링이 실제로 어디서 잘 깨지는지(수요일), 파이프라인을 단계별로 더 자세히 뜯어보며 왜 이 순서인지(금요일) — 는 이번 주에 이어가겠습니다. 오늘은 밑그림을 한 장으로 잡는 게 목표입니다.

---

본론 1 — 1단계: 수집 (어디를 볼지 정하기)

URL 하나가 사이트 하나는 아닙니다

"URL을 넣는다"고 하면 보통 주소 하나를 떠올립니다. 그런데 사이트는 페이지 하나가 아닙니다. 지난달 내내 강조한 게 "메인만 보지 말고 사이트 전체를 보라"였습니다. 그러려면 넣은 URL 하나에서 출발해서, 그 사이트 안의 다른 페이지들을 찾아내야 합니다.

이게 첫 단계, 수집입니다. 시작 주소에서 페이지 안의 링크들을 따라가며 "이 사이트엔 어떤 페이지들이 있나"를 모으는 것입니다. 메인에서 시작해 공지 목록으로, 거기서 상세 페이지로, 신청 페이지로… 사람이 사이트를 돌아다니듯 링크를 타고 들어가며 페이지 목록을 만듭니다. 사람이 마우스로 이 메뉴 저 메뉴를 눌러 들어가던 그 행동을, 기계가 링크를 따라가며 대신하는 셈입니다.

여기에 도움이 되는 게 사이트맵(sitemap)입니다. 많은 사이트가 "우리 사이트엔 이런 페이지들이 있어요"를 정리한 목록을 검색엔진용으로 갖고 있는데, 이게 있으면 링크를 일일이 따라가지 않아도 페이지 목록을 빠르게 잡을 수 있습니다. 그래서 수집은 보통 "사이트맵이 있으면 그걸 참고하고, 없거나 부실하면 링크를 직접 따라간다"는 식으로 두 방법을 섞어서 합니다. 어느 한 방법에만 기대면 놓치는 페이지가 생기니까요.

그리고 중복도 걸러야 합니다. 같은 페이지가 여러 주소로 연결돼 있는 경우가 흔합니다. 끝에 슬래시가 붙거나 안 붙거나, 파라미터가 다르거나, 세션 정보가 주소에 섞이거나. 이걸 다 다른 페이지로 세면, 같은 걸 여러 번 보느라 시간을 낭비합니다. 그래서 "이건 사실 같은 페이지"임을 알아보고 묶는 처리도 수집 단계에서 합니다. 단순히 링크를 긁는 게 아니라, 긁으면서 정리까지 하는 것입니다. 수집이 "모으기"이면서 동시에 "추리기"인 이유입니다.

어디까지, 얼마나 갈지

여기서 판단이 들어갑니다. 무작정 다 따라가면 끝이 없습니다. 사이트가 크면 페이지가 수천, 수만 장이니까요. 그래서 "몇 페이지까지 볼지", "얼마나 깊이 들어갈지"를 정해야 합니다. 너무 적게 보면 메인만 보는 그 함정에 빠지고, 너무 많이 보면 시간이 끝없이 걸립니다. 그 균형을 잡는 게 수집 단계의 핵심입니다. 실제로 이 균형은 상황에 따라 조정됩니다. 빠르게 훑어야 할 때와 꼼꼼히 봐야 할 때가 다르니까요.

그리고 모든 페이지가 다 똑같이 중요한 것도 아닙니다. 자주 쓰는 페이지(메인, 신청, 검색)와 잘 안 쓰는 페이지의 무게가 다릅니다. 한정된 시간에 본다면, 중요한 페이지부터 챙기는 게 낫습니다. 그래서 수집은 단순히 "다 긁어모으기"가 아니라, "어디를 볼지 똑똑하게 고르기"에 가깝습니다. 사람이 사이트를 점검할 때 "그래도 신청 페이지는 꼭 봐야지" 하고 우선순위를 두던 그 감각을, 자동으로 흉내 내야 하는 것이죠.

여기서 한 가지 솔직하게 짚어둘 게 있습니다. "사이트 전체를 본다"는 말이 "수백, 수천 페이지를 통째로 하나도 빠짐없이 본다"는 뜻은 아닙니다. 상황과 설정에 따라 보는 범위가 달라집니다. 다만 확실한 건, "메인 한 장만 보고 끝"과는 근본적으로 다르다는 점입니다. 시작 주소에서 안쪽으로 링크를 따라 들어가 여러 페이지를 모은다는 것 자체가, 사람이 손으로 하던 점검과는 폭이 다릅니다. 이 범위를 어떻게 정하고 어떻게 넓히는지, 그리고 여러 페이지의 결과를 어떻게 하나로 묶는지는 6개월차(다중 페이지 분석)에서 본격적으로 풀겠습니다.

수집이 부실하면

이 단계가 부실하면, 그 뒤가 아무리 정교해도 의미가 없습니다. 메인 한 장만 수집했으면, 분석도 메인 한 장만 하는 것입니다. 깊은 페이지의 문제는 수집 단계에서 이미 빠져버립니다. 그래서 "사이트 전체를 본다"는 약속은, 사실 이 수집 단계에서 지켜지느냐로 갈립니다. 분석 엔진이 아무리 좋아도 볼 페이지를 모아주지 않으면 소용이 없으니까요.

그래서 좋은 분석 도구를 볼 때 결과 화면만이 아니라 "몇 페이지를 수집했나"를 확인하는 게 중요합니다. 화려한 결과가 나와도, 그게 메인 한 장을 본 결과인지 사이트 여러 페이지를 본 결과인지에 따라 값어치가 완전히 다르니까요. 수집은 눈에 잘 안 띄는 단계지만, 사실 분석의 폭 전체를 결정하는 문지기입니다.

조금 더 현장 언어로 풀어보겠습니다. 공공 사이트는 대개 메인이 제일 자주 손보는 화면입니다. 개편할 때도 메인부터 새로 만들고, 예산이 있을 때도 메인부터 다듬습니다. 그래서 메인은 늘 비교적 깔끔합니다. 문제는 정작 사용자가 오래 머무는 곳이 메인이 아니라는 데 있습니다. 사용자는 민원을 넣으러, 서식을 내려받으러, 신청 내역을 조회하러 안쪽 깊은 페이지로 들어갑니다. 그 페이지들이 몇 년째 방치돼 있어도, 메인만 보는 점검에서는 절대 드러나지 않습니다. "메인은 최근에 새로 만들어 깔끔한데, 오래된 신청 페이지는 그대로"인 상황이 실제로 흔합니다. 수집 단계가 링크를 따라 안쪽으로 들어가야 하는 이유가 여기 있습니다. 겉으로 보이는 몇 장이 아니라, 사용자가 실제로 밟는 경로를 따라가야 진짜 상태가 드러나니까요. 수집이 얕으면 이 "방치된 안쪽"이 통째로 분석에서 빠지고, 그러면 결과는 실제보다 후하게 나옵니다. 정직한 진단을 위해서라도 수집은 안쪽까지 닿아야 합니다.

---

본론 2 — 2단계: 렌더링 (화면을 진짜로 그리기)

코드를 받는 게 아니라 화면을 그립니다

페이지 목록이 정해지면, 각 페이지를 실제로 띄웁니다. 여기가 두 번째 단계, 렌더링입니다. 지난달에 강조한 그 포인트입니다. 단순히 HTML 코드를 받아오는 게 아니라, 진짜 브라우저처럼 페이지를 끝까지 그려내는 것.

왜 코드만 받으면 안 되는지는 지난달에 자세히 봤습니다. 요즘 사이트는 처음 받는 HTML이 거의 빈 껍데기이고, 자바스크립트가 돌면서 내용을 채웁니다. 메뉴도, 목록도, 표도 다 나중에 그려집니다. 그래서 코드만 받으면 "내용 없는 사이트"로 보이기도 합니다. 실제로는 화면 가득 콘텐츠가 있는데도 말입니다. 끝까지 그려봐야 사용자가 보는 진짜 화면이 나옵니다.

이걸 사람 없이 자동으로 하는 환경을 흔히 "헤드리스 브라우저"라고 부릅니다. 화면(모니터)만 없을 뿐, 실제 브라우저와 똑같이 페이지를 띄우고 그려냅니다. 사람이 모니터 앞에서 보던 그 화면을, 사람 없이 기계가 똑같이 만들어내는 것이죠. 그래야 "코드가 아니라 실제 화면"을 기준으로 볼 수 있습니다. 지난달에 강조한 그 포인트 — 코드만 보면 이미지 버튼이나 시각적 문제를 놓친다 — 가 여기서 풀립니다. 실제로 그려진 화면을 보니까요.

실제 사용자 환경처럼

그냥 그리는 것도 아닙니다. 실제 사용자가 보는 것과 최대한 같게 그려야 합니다. 팝업이나 쿠키 동의 배너가 화면을 가리고 있으면 그걸 감안하고, 로딩이 느린 페이지라면 다 뜰 때까지 기다리고, 스크롤을 내려야 나타나는 콘텐츠도 챙깁니다. 사람이 직접 볼 때 무의식적으로 하던 이런 동작들을 자동으로 비슷하게 처리해야, "사용자가 실제로 보는 화면"에 가까워집니다. 대충 받아서 보면 사용자가 보는 것과 다른 걸 보게 되니까요.

그리고 한 화면만 그리는 게 아닙니다. 지난달에 강조한 반응형입니다. 같은 페이지를 데스크톱·태블릿·모바일 크기로 각각 그립니다. ViewCheck는 구체적으로 데스크톱 1920×1080, 태블릿 768×1024, 모바일 390×844, 이 세 개의 뷰포트로 실제로 화면을 띄워 봅니다. PC에선 멀쩡한데 모바일에서 깨지는 걸 잡으려면, 화면 크기를 달리해서 여러 번 그려야 하니까요. 그리고 그 안에서 손가락으로 누르는 버튼·링크의 크기가 기준(44×44px)보다 작은 곳까지 짚어냅니다. "버튼이 작아서 자꾸 잘못 눌린다"는 민원이, 여기서는 오픈 전에 수치로 잡히는 셈입니다.

여기서 "기다림"이 의외로 중요합니다. 페이지를 띄우자마자 캡처하면, 아직 다 안 그려진 상태를 찍게 됩니다. 이미지가 안 떴거나, 자바스크립트가 아직 내용을 안 채웠거나. 그래서 "충분히 다 그려졌나"를 판단하고 기다렸다가 봐야 합니다. 너무 빨리 보면 미완성을 찍고, 너무 오래 기다리면 시간을 낭비합니다. 이 타이밍을 잡는 것도 렌더링의 기술입니다. 사람이 페이지가 뜰 때까지 무심코 기다리던 그 감각을, 자동으로 흉내 내야 하는 것이죠.

또 하나, 실제 사용자 환경을 흉내 낸다는 건 "사람처럼 보이게" 접속한다는 뜻이기도 합니다. 일부 사이트는 기계적인 접속을 막아두는데, 실제 브라우저처럼 접속해야 사용자가 보는 그 화면이 나옵니다. 이런 자잘한 것까지 맞춰야 "진짜 사용자가 보는 화면"에 가까워집니다. 말로는 "화면을 그린다"로 간단해 보여도, 다양한 사이트에서 이걸 안정적으로 해내는 건 만만한 일이 아닙니다.

렌더링이 까다로운 이유

이 단계가 의외로 까다롭습니다. 사이트마다 만든 방식이 제각각이라, 어떤 건 빨리 뜨고 어떤 건 한참 걸리고, 어떤 건 무한스크롤이고 어떤 건 로그인을 요구합니다. 이 다양한 사이트를 다 안정적으로 그려내는 게 쉽지 않습니다. 수요일 글에서 이 "렌더링이 실패하는 경우들"을 자세히 다룰 텐데, 미리 말씀드리면 여기가 파이프라인에서 제일 잘 깨지는 지점입니다. 화면을 못 그리면 그 페이지는 분석 자체가 안 되니까요.

그래서 렌더링에서 중요한 건 "얼마나 많은 사이트를 무너지지 않고 끝까지 그려내느냐"입니다. 화면 하나를 예쁘게 그리는 건 어렵지 않습니다. 어려운 건, 성격이 제각각인 수많은 사이트를 하나의 절차로 다 감당하는 것이죠. 여기서 실패한 페이지를 어떻게 다시 시도하느냐가 분석 커버리지를 좌우합니다. 이 이야기는 이번 주 수요일에 실제 함정 사례들과 함께 풀겠습니다.

한 가지 더 짚어두면, "빨리 대충 캡처했다"와 "사용자가 보는 그대로 끝까지 그려냈다"는 결과물이 완전히 다릅니다. 잘못 그려진 화면을 아무리 정밀하게 재봐야 틀린 결과만 나옵니다. 그래서 렌더링은 뒤의 추출·판정 품질을 미리 결정하는 관문입니다. 어떤 사이트는 보안 장비가 자동 접근을 막고, 어떤 사이트는 무한 스크롤로 콘텐츠가 계속 붙고, 어떤 사이트는 특정 조건에서만 열립니다. 이런 변수들을 하나씩 넘어서 "진짜 화면"에 도달하는 것 자체가 URL 분석의 첫 실전 관문인 셈입니다. 이 관문에서 무너지면 그 뒤의 정교한 분석은 의미가 없어집니다. 그래서 오늘 다루는 네 단계 중에서도 렌더링은 "가장 눈에 안 띄지만 가장 잘 깨지는" 자리라고 미리 표시해 두겠습니다.

---

본론 3 — 3단계: 추출 (화면을 측정값으로 바꾸기)

그린 화면을 두 가지로 읽습니다

화면을 그렸으면, 거기서 정보를 뽑습니다. 세 번째 단계, 추출입니다. 지난달에 본 그 "시각과 구조를 같이 본다"가 여기서 일어납니다.

하나는 그려진 화면을 이미지로 캡처해서 시각적으로 분석하는 것입니다. 색이 무엇인지, 대비가 충분한지, 요소 간 간격이 어떤지, 버튼이 얼마나 큰지를 픽셀 단위로 잽니다. 사람이 "느낌상" 보던 걸 기계는 정확한 수치로 재는 것이죠. 다른 하나는 화면 뒤의 구조를 같이 읽는 것입니다. 화면에 보이는 버튼이 코드상 어떻게 돼 있는지, 적절한 라벨이 붙어 있는지, 제목 구조가 논리적인지를 봅니다. 시각만도, 구조만도 아니라 둘을 같이 봅니다. 아래는 그렇게 한 컴포넌트를 픽셀·구조 양쪽으로 뜯어본 결과인데, "버튼 하나"가 색·간격·크기·라벨이라는 측정값 묶음으로 바뀌어 있는 걸 볼 수 있습니다.

픽셀 단위로 잰다는 것

여기서 ViewCheck의 출원 기술(출원 중, 시각 요소 분석 방법)이 들어옵니다. 화면 이미지에서 시각 요소를 픽셀 단위로 정확히 재는 방법입니다. 예를 들어 "이 두 요소 사이 간격이 정확히 몇 픽셀인가", "이 글자색과 배경색의 대비 비율이 얼마인가", "이 버튼의 크기가 가로세로 몇 픽셀인가"를 잽니다.

이게 왜 중요하냐면, 지난달에 봤듯 사람 눈은 이걸 못 하기 때문입니다. 6픽셀과 8픽셀을 구분하지 못하고, 대비가 충분한지를 "읽을 만한가"로 대충 판단합니다. 그런데 화면을 픽셀로 재면 "이 간격은 8의 배수가 아님", "이 대비는 기준 미달"이 딱 떨어집니다. 화면을 단순히 보여주는 게 아니라 "재는" 것이죠. 그래서 같은 화면을 누가 봐도, 몇 번을 재도 같은 수치가 나옵니다. 재현되는 측정입니다.

대비를 예로 들면 더 와닿습니다. 글자색과 배경색의 대비는 사실 정해진 계산식이 있습니다. 두 색의 밝기 차이를 수식으로 계산해서 비율로 내는 것이죠. 사람은 이걸 눈으로 못 하지만(모니터·시력·밝기에 따라 다르게 보이니까요), 화면에서 두 색의 정확한 값을 읽으면 계산식에 넣어 딱 떨어지는 비율이 나옵니다. "이 회색 글씨는 대비 2.8, 기준 4.5 미달"처럼요. 지난달에 본 "회색 글씨가 안 보인다"는 민원이, 이렇게 수치로 미리 잡힙니다. "흐린 것 같다"가 "대비 비율 기준 미달"이 되는 것입니다.

간격도 마찬가지입니다. 요소들 사이의 거리를 픽셀로 재서, 그게 디자인 규칙(예를 들어 8의 배수)을 따르는지 봅니다. 정렬도 그렇습니다. 여러 요소의 위치를 재서 "이것들이 같은 선에 맞춰져 있나"를 판단합니다. 사람이 눈으로 "대충 정렬됐네" 하던 걸, 좌표로 정확히 확인하는 것이죠. 버튼 크기도 "작아 보인다"가 아니라 "38×38px, 터치 기준 44×44px 미달"로 딱 떨어집니다. 이렇게 화면을 좌표·색·크기의 숫자로 바꿔놓으면, 디자인이 "느낌"이 아니라 "측정값"이 됩니다. 그게 지난달에 말씀드린 편차·재현 문제를 푸는 핵심입니다. 느낌은 사람마다 다르고 다시 보면 또 달라지지만, 측정값은 누가 재도 같고 몇 번을 재도 같으니까요.

여기서 잠깐, "왜 굳이 이렇게까지 정확히 재야 하나" 싶으실 수 있습니다. 이유는 증빙 때문입니다. 공공기관의 웹 담당자분이 "우리 사이트 이 부분이 기준 미달입니다"라고 윗선이나 개발사에 이야기하려면, "제 눈에 좀 흐려 보여요"로는 근거가 안 됩니다. "이 글자는 대비 비율이 기준선 아래이고, 이 버튼은 터치 기준보다 작습니다"처럼 수치로 말할 수 있어야 상대가 납득하고 고칩니다. 느낌은 반박당하지만 측정값은 반박이 어렵습니다. 그리고 그 측정값이 다시 돌려도 같게 나오니까(재현되니까), 그게 곧 증빙이 됩니다. 픽셀 단위 측정이 단순한 정밀함의 문제가 아니라 "말이 되는 근거"를 만드는 일인 이유입니다. 감으로 보던 점검이 근거로 보는 점검으로 바뀌는 지점이 바로 여기입니다.

글자도 읽어냅니다

화면엔 글자도 있습니다. 그런데 이미지로 된 글자(이미지 안에 박힌 텍스트)는 코드로 못 읽습니다. 이런 건 화면 이미지에서 글자를 인식해서 읽어냅니다. 흔히 OCR이라고 부르는 방식인데, 여기서 한 가지는 정확히 짚어두겠습니다. 이 글자 읽기는 URL 분석에서 "항상 도는 필수 단계"가 아니라, 필요할 때 쓰는 보완 수단입니다. 이미지로 박힌 텍스트를 확인해야 하거나, 페이지의 성격을 판단해야 할 때처럼 코드만으로 부족한 지점에서 보태는 도구인 것이죠. 모든 화면에서 항상 글자를 새로 읽어내는 것처럼 부풀려 말하면 그건 과장입니다.

그래도 이 보완 수단이 왜 필요하냐면, 공공 사이트엔 의외로 이미지로 된 글자가 많아서입니다. 행사 배너, 안내 포스터, 인포그래픽 같은 게 통째로 이미지인 경우가 흔합니다. 코드로만 보면 이건 "그림 한 장"일 뿐이라, 거기 적힌 중요한 안내문이 분석에서 빠집니다. 필요할 때 화면에서 글자를 읽어내면, 그 안내문도 "텍스트"로 잡혀서 접근성 점검(스크린리더가 못 읽는 이미지 텍스트 문제 등)에 들어갑니다. 사용자가 눈으로 읽는 글자는 놓치지 않으려는 보완 장치라고 이해하시면 됩니다.

분석 엔진이 쓸 수 있게 정리합니다

추출의 마지막 일은, 이렇게 뽑은 시각·구조 정보를 분석 엔진이 쓸 수 있는 정리된 데이터로 만드는 것입니다. "이 페이지엔 버튼이 몇 개, 각 버튼의 크기·색·라벨은 이렇고, 표가 몇 개, 입력창이 몇 개…" 식으로요. 이 정리된 데이터가 그다음 단계(판정)의 입력이 됩니다. 지난달 매핑에서 시각 요소 분석이 그 위 영역들의 토대라고 한 게 이것입니다. 추출이 깔끔해야 그 위의 판정이 정확합니다.

그리고 이게 한 페이지가 아니라 수집한 모든 페이지에 대해, 각 화면 크기별로 일어납니다. 그래서 추출 결과는 "사이트 여러 페이지 × 여러 해상도"의 데이터가 됩니다. 이걸 잘 정리해둬야 나중에 "사이트 전체 준수율", "페이지별 위반", "모바일에서만 깨진 것" 같은 걸 뽑을 수 있습니다. 여기서 한 가지가 더 정리됩니다. 같은 종류의 요소를 묶는 것입니다. 여러 페이지에 다 들어가는 공통 헤더의 버튼이 있으면, 그걸 "여러 군데의 다른 버튼"이 아니라 "한 종류의 버튼이 여러 군데"로 묶어서 정리합니다. 그래야 나중에 "공통 요소 하나를 고치면 여러 건이 한 번에" 해결되는 게 가능합니다. 데이터를 단순히 쌓는 게 아니라, 나중에 쓰기 좋게 구조를 잡아두는 것이죠.

---

본론 4 — 4단계: 판정 (기준과 대조해 가르기)

정리된 데이터를 기준에 대봅니다

마지막 단계는 판정입니다. 추출로 정리한 시각·구조 데이터를 KRDS 기준에 대조해, 항목마다 "맞다/어긋났다/해당 없음"을 가리는 단계입니다. 앞의 세 단계가 "화면을 데이터로 바꾸는" 준비였다면, 판정은 그 데이터를 실제 기준에 대보고 결론을 내는 자리입니다.

여기서 중심이 되는 게 KRDS 846규칙입니다. 색·타이포·간격 같은 디자인 스타일(DS, 120개), 버튼·폼·표 같은 컴포넌트(CP, 446개), 폼 구조·오류 처리 같은 기본 패턴(BP, 108개), 검색·로그인·신청 같은 서비스 패턴(SP, 172개). 이 네 묶음을 합쳐 846개입니다. 지난달에 "846개를 사람이 손으로?"라고 했던 그 846개를, 추출된 데이터를 기준으로 자동 판정합니다.

판정이라는 게 단순히 "있다/없다"만은 아닙니다. 항목별로 "기준에 맞다(통과)", "어긋났다(미통과)", "이 페이지엔 해당 없음(N/A)"으로 나뉩니다. 예를 들어 그 페이지에 표가 없으면 표 관련 규칙은 N/A가 됩니다. 그래서 모든 페이지가 846개를 다 받는 게 아니라, 그 페이지에 있는 요소에 해당하는 규칙들이 판정되는 식입니다. 이 N/A를 어떻게 줄이고 채우느냐가 사실 분석 품질의 핵심 중 하나인데, 그 이야기는 8개월차(LLM·N/A 심화)에서 자세히 풀겠습니다.

두 엔진이 나눠 봅니다

판정에는 성격이 다른 두 엔진이 함께 일합니다. 하나는 코드와 구조를 읽어 통과·미통과를 확정하는 규칙 엔진입니다. 데이터를 기준에 대보고 빠르게 판정하는 쪽이죠. 다른 하나는 화면 스크린샷을 보고 컴포넌트를 감지하는 시각 AI 엔진입니다. 코드만으로는 잘 안 잡히는, 이미지나 비표준 방식으로 만든 요소를 화면에서 눈으로 찾아내는 쪽입니다.

이 둘 사이에는 분명한 규칙이 있습니다. 코드가 통과·미통과로 확정한 건 시각 AI가 뒤집지 않습니다. 시각 AI는 규칙 엔진이 "해당 없음(N/A)"으로 비워둔 빈칸만 채우는 역할입니다. 그것도 확신이 있을 때만 채웁니다. 화면에서 못 찾으면 억지로 있다고 하지 않고, N/A를 그대로 둡니다. 없는 걸 있다고 지어내지 않는다는 뜻이죠. 그리고 채우든 비우든 "왜 그렇게 판정했는지" 근거를 남깁니다. 이렇게 역할을 나눠두면, 빠르고 정확한 코드 판정 위에 시각적 확인을 얹으면서도, 서로 부딪혀 판정이 흔들리는 일을 막을 수 있습니다.

왜 이렇게 나눠 볼까요. 코드로 확실히 판단되는 건 코드가 제일 정확하고 빠르기 때문입니다. 반대로 이미지로 박힌 버튼이나 비표준으로 만든 요소는 코드로는 "그림"으로만 보여서 판단이 안 되는데, 이건 화면을 눈으로 보는 쪽이 강합니다. 각자 잘하는 영역이 다르니, 잘하는 쪽에 맡기고 못 하는 쪽은 상대가 메우는 구조입니다. 그리고 그 경계에서 "확신 없으면 비워둔다"는 원칙이 있어야, 결과가 부풀지 않습니다. 이 두 엔진의 협업은 URL 분석 신뢰성의 뼈대라, 앞으로도 여러 번 다시 나올 이야기입니다.

디자인만이 아닙니다

판정 단계에서 대조하는 게 846규칙만은 아닙니다. 화면을 한 번 제대로 그려서 보는 김에, 여러 면을 같이 잽니다. 장애가 있는 사용자도 쓸 수 있는지(웹 접근성), 페이지가 얼마나 빨리 뜨는지(성능), 보안 설정이 되어 있는지(보안), 검색엔진이 잘 읽을 수 있는지(SEO) 같은 것들입니다. 행정안전부의 7대 품질 영역 — 호환성·접근성·개방성·접속성·편의성·효율성·신뢰성 — 이 대체로 이 안에 들어옵니다. 그래서 URL 하나를 넣으면 스무 개가 넘는 분석 영역이 한 번에 훑어집니다.

이게 가능한 이유는, 어차피 사이트를 실제로 띄워서 보는 김에 여러 면을 같이 잴 수 있어서입니다. 페이지를 그려내는 과정에서 "얼마나 걸렸나"를 재면 성능이 나오고, 받아오는 응답을 보면 보안 설정이 보이고, 페이지 정보를 읽으면 SEO가 보입니다. 사람이라면 성능 도구 따로, 보안 점검 따로 돌려야 할 것을, 한 번 띄우는 김에 같이 보는 것이죠. 그리고 이 성능·보안·접속성 같은 영역은 본질적으로 운영 시점에서만 잴 수 있습니다. 실제로 브라우저로 접속해 요청을 보내봐야 응답 시간이 나오고, 응답을 받아봐야 보안 설정이 보이니까요. 디자인 파일이나 코드 조각만 봐서는 "이 사이트가 얼마나 빨리 뜨는지"를 알 수 없습니다. 실물에 직접 들어가 봐야만 보이는 것들입니다.

특히 접근성은 공공 사이트에서 유독 중요합니다. 민간 사이트는 불편하면 사용자가 다른 사이트로 갑니다. 그런데 공공 사이트는 대체재가 없습니다. 세금을 내거나, 민원을 넣거나, 복지 혜택을 신청하는 창구가 그 사이트 하나뿐입니다. 그러니 그 사이트가 특정 사용자를 배제하면, 그 사용자는 서비스 자체에서 배제되는 것입니다. 고령자, 저시력자, 화면을 못 보는 분들이 실제로 그 창구를 써야 하는데 못 쓰게 되는 것이죠. 그래서 접근성은 공공 웹에서 "있으면 좋은 것"이 아니라 "없으면 안 되는 것"입니다. 판정 단계는 이 영역을 여러 자동 검사 방식으로 교차해서 봅니다. 한 방식이 놓친 걸 다른 방식이 잡도록요. 그리고 색 대비 같은 건 사람 눈으로 판단하면 편차가 큰데, 앞의 추출 단계에서 수치로 재둔 덕분에 그 편차 없이 "기준 이상인가 미달인가"로 딱 떨어집니다.

다만 "넓게 본다"가 "다 똑같이 깊게 본다"는 뜻은 아닙니다. 영역마다 자동으로 잡을 수 있는 깊이가 다르고, 어떤 건 사람의 최종 판단이 필요합니다. 그 경계가 어디인지는 앞으로 영역별로 풀면서 솔직하게 짚겠습니다. 잘하는 걸 잘한다고 하고, 못 하는 건 다른 시점이 메운다고 하는 게 지난달 내내 드린 이야기이고, URL 분석도 그 틀 안에 있습니다.

---

본론 5 — 네 단계가 한 흐름으로, 그리고 어디가 막히면

사람 손 없이 쭉 이어집니다

정리하면 URL 한 줄을 넣으면 이 네 단계가 자동으로 돕니다. 수집(어디를 볼지) → 렌더링(화면 그리기) → 추출(측정값으로 바꾸기) → 판정(기준과 대조). 사람이 중간에 손댈 필요 없이 쭉 이어집니다. 화면엔 "분석 중…"만 떠 있지만, 안에선 이 네 단계가 페이지마다, 화면 크기마다 돌고 있는 것입니다.

그리고 이 전체가 "URL만 입력하면"으로 시작된다는 게 핵심입니다. 지난달에 본 그 사람 손의 준비물들 — 페이지를 일일이 띄우고, 로그인하고, 개발자 도구를 열고, 가이드 문서를 옆에 띄워 대조하고 — 이 다 자동화된 것입니다. 입력은 주소 하나, 그 뒤는 전부 기계가 합니다. 담당자분이 개발자 도구를 열 줄 몰라도, 846규칙을 외우지 않았어도, 주소만 알면 자기 사이트의 상태를 수치로 받아 볼 수 있습니다. 입력이 단순하다는 건 자동화하는 쪽에서도 큰 이점입니다. 누가 넣든 같은 주소면 같은 네 단계를 거치니, 그 뒤의 처리를 표준화하기가 쉽습니다. 단순한 입구가 곧 일관된 결과의 출발점이 되는 셈입니다.

네 단계는 사슬입니다

이 네 단계는 사슬처럼 이어져 있습니다. 그래서 한 단계가 막히면 그 뒤가 다 영향을 받습니다. 단계별로 막혔을 때 무슨 일이 생기는지 보면, 왜 각 단계가 다 중요한지가 분명해집니다.

수집이 막히면 — 못 본 페이지가 생깁니다. 수집 단계에서 일부 페이지를 못 찾으면, 그 페이지는 아예 분석 대상에서 빠집니다. 분석 엔진이 아무리 좋아도, 볼 페이지를 안 주면 못 봅니다. 그래서 "분석했다"가 사실은 "수집된 페이지만 분석했다"가 됩니다. 지난달에 본 "본 적도 없는 페이지에서 사고가 난다"가, 사실 이 수집 단계의 빈틈에서 시작됩니다. 그래서 결과에서 "몇 페이지를 수집했나"를 확인하는 게 중요합니다.

렌더링이 막히면 — 그 페이지는 통째로 빠집니다. 페이지를 못 그리면, 그 페이지는 분석이 안 됩니다. 화면이 없으니 뽑을 게 없으니까요. 수요일에 자세히 다룰 텐데, 무한스크롤·지연 로딩·접근 차단 같은 이유로 렌더링이 실패하면 그 페이지가 통째로 빠집니다. 그래서 렌더링이 파이프라인에서 제일 잘 깨지는 지점이고, 여기서 실패한 페이지를 어떻게 다시 시도하느냐가 분석 커버리지를 좌우합니다.

추출이 부실하면 — 잘못 재거나 못 잽니다. 화면은 그렸는데 추출이 부실하면, 시각 요소를 잘못 재거나 못 잽니다. 간격을 틀리게 재거나, 글자를 잘못 읽거나. 그러면 그 위의 판정도 틀어집니다. 그래서 픽셀을 정확히 재고 글자를 제대로 읽는 게 중요한 것입니다. 측정이 틀리면 판정이 틀리니까요. "이게 버튼인지 그냥 박스인지" 같은 게 애매하게 넘어가면, 판정 엔진도 애매하게 판정합니다.

판정이 흔들리면 — 결과를 못 믿습니다. 마지막으로 판정 단계에서 없는 걸 있다고 지어내거나, 코드가 확정한 걸 뒤집으면, 결과 자체를 믿을 수 없게 됩니다. 그래서 앞서 본 두 엔진의 규칙 — 확정한 건 안 뒤집고, 확신 없으면 비워두고, 근거를 남긴다 — 이 판정 단계의 신뢰를 받칩니다. 부풀린 결과보다, 정직하게 "여긴 확인 못 함"이라고 두는 게 오히려 신뢰를 지킵니다.

그래서 토대가 중요합니다

이걸 쭉 보면, 왜 "시각 요소 분석이 토대"인지가 분명해집니다. 이 네 단계(수집·렌더·추출·판정)가 다 잘 돌아야, 그 위의 위험 등급·비용·비교가 의미가 있습니다. 화려한 분석 결과도 결국 이 토대 위에 서 있습니다. 그래서 좋은 분석 도구를 볼 때는 결과 화면만이 아니라 "이 토대가 탄탄한가"도 봐야 합니다. 수집은 충분히 하는가, 화면을 제대로 그리는가, 정확히 재는가, 정직하게 판정하는가. 이게 지난달에 본 "방법을 보라"의 URL 분석 버전입니다.

---

본론 6 — 이 흐름이 사람 점검과 근본적으로 다른 점

이 네 단계 자동 흐름이 단지 "빠른 점검"에 그치는 게 아니라는 걸 짚고 싶습니다. 속도만 빠른 게 아니라, 보는 방식 자체가 사람과 다릅니다.

규모 — 지치지 않습니다

사람은 여러 페이지를 보다 보면 지칩니다. 뒤로 갈수록 대충 봅니다. 몇 페이지째부터 눈이 무뎌지고, 스무 페이지째부터는 "아까 본 것 같은데"가 됩니다. 기계는 지치지 않습니다. 수십 페이지든 수백 페이지든 첫 페이지와 마지막 페이지를 똑같은 집중도로 봅니다. 규모가 커질수록 사람과 기계의 격차가 벌어집니다. 공공 사이트는 페이지가 수백에서 수천 장에 이르는 경우가 많으니, 이 규모의 차이가 특히 크게 작동합니다.

일관성 — 기준이 흔들리지 않습니다

사람은 오전과 오후가 다르고, 담당자 A와 B가 다릅니다. 컨디션에 따라, 경험에 따라 기준이 미묘하게 달라집니다. 기계는 같은 기준으로 봅니다. 어떤 페이지를 보든, 몇 번째로 보든, 같은 잣대입니다. 그래서 결과가 재현됩니다. 다시 돌려도 같은 결과가 나옵니다. 앞의 추출 단계에서 화면을 "느낌"이 아니라 "측정값"으로 바꿔둔 게, 여기서 이 재현성으로 이어집니다. 두 번 돌렸더니 결과가 다르게 나오는 도구는, 그 숫자를 근거로 쓸 수 없습니다. 같은 입력에 같은 출력이 나와야 비로소 "이 결과를 믿고 보고할 수 있다"가 됩니다.

시각 + 구조 — 한쪽에 쏠리지 않습니다

사람은 한 번에 한쪽만 깊게 봅니다. 시각이면 시각, 코드면 코드. 기계는 화면을 그려서 시각을 보면서, 동시에 그 뒤 구조도 읽습니다. 앞서 추출·판정에서 본 그 "두 가지를 같이 본다"입니다. 양쪽을 같이 보니까, 한쪽만 봐서 생기는 사각지대가 줄어듭니다. 화면상으로는 멀쩡한 버튼인데 코드에 라벨이 없어서 시각장애인 사용자에게는 "이름 없는 버튼"이 되는 경우가 있습니다. 이건 화면만 봐서는 절대 안 잡히고, 코드만 봐서는 "그 버튼이 실제로 화면에서 어떻게 쓰이는지"를 모릅니다. 두 정보를 겹쳐봐야 "화면엔 있는데 코드엔 이름이 없다"는 결론이 나옵니다. 사람 조직에서는 디자인 담당과 개발 담당 사이의 틈으로 새던 문제가, 한 번의 분석 안에서 메워지는 것입니다.

추적 — 같은 방식으로 다시 봅니다

사람은 매번 일회성이라 지난번과 비교가 안 됩니다. 이번에 본 기준과 지난번에 본 기준이 다르니, 나아졌는지 나빠졌는지 답을 못 합니다. 기계는 같은 방식으로 언제든 다시 볼 수 있습니다. 그래서 시점을 달리해 비교가 됩니다. "지난번 대비 어떻게 변했나"가 답이 됩니다. 콘텐츠가 자주 바뀌는 공공 사이트일수록 이게 중요합니다. 공지·보도자료·민원 안내가 매일 올라오는데, 그 과정에서 누군가 형식을 잘못 붙여넣거나 큰 이미지를 그대로 올리면 그 페이지가 조용히 깨집니다. 같은 주소를 주기적으로 다시 넣어보면 이런 게 쌓이기 전에 잡힙니다. 이 시점 비교와 추세 읽기는 11개월차(정기진단과 성과 증명)에서 본격적으로 다룹니다.

정리 — 결과를 한곳에 모아줍니다

사람이 점검하면 디자인·접근성·성능을 따로 보고, 그걸 다시 보고서로 합치는 게 일이었습니다. 도구가 세 개면 결과 형식도 세 가지이고, 기준도 제각각이라 단순히 더할 수도 없습니다. 이 네 단계 흐름은 처음부터 하나의 기준 위에서 여러 영역을 재기 때문에, 그 합치는 수고와 그 과정의 자의성이 함께 사라집니다. 판정도 준수율도 같은 출처에서 나오니, 보이는 모든 숫자가 서로 맞아떨어집니다. 상단에 뜬 준수율과 그 아래 세부 항목의 합이 어긋나지 않는다는 것 — 사소해 보이지만, 보고서를 받아 드는 사람에게는 "이 결과를 믿어도 되나"를 가르는 지점입니다.

다만, 사람을 대체하는 건 아닙니다

여기까지 보면 "그럼 사람은 필요 없겠네" 싶으실 수 있는데, 그건 아닙니다. 이 네 단계가 잘하는 건 "넓고 일관되게, 반복해서, 정직하게 재는 것"입니다. 그런데 "이 위반이 우리 기관 맥락에서 얼마나 급한지", "이건 규칙은 어겼지만 의도된 예외 아닌지", "한정된 예산에서 무엇을 먼저 할지" 같은 판단은 여전히 사람의 몫입니다. 그게 세 번째 시점(판단)이고, 그래서 세 시점이 다 필요한 것입니다. 이 네 단계 흐름은 사람의 판단을 없애는 게 아니라, 판단할 거리를 깔끔하게 정리해서 갖다주는 쪽에 가깝습니다. 기계가 넓고 일관되게 깔아준 데이터 위에서, 사람이 맥락과 우선순위를 얹는 구조입니다.

---

그래서 ViewCheck는

ViewCheck의 URL 분석이 바로 이 네 단계로 돌아갑니다. URL을 넣으면 사이트 안 페이지들을 수집하고, 각 페이지를 실제 사용자처럼 여러 화면 크기로 렌더링하고, 화면을 픽셀 단위로 재고 필요할 때 글자까지 읽어 측정값으로 추출하고, 그 데이터를 846규칙과 여러 품질 영역의 기준에 대조해 판정합니다. 지난달 매핑의 시각 요소 분석(출원 중)이 이 토대를 받칩니다. 위에서 본 종합 결과 한 장이 이 네 단계가 다 돌고 난 뒤의 결과물입니다.

거창한 게 아니라, 지난달에 본 "사람 손으로는 안 되던" 그 일을 자동화한 것입니다. 사람이 페이지마다 며칠 걸려 하던 수집·확인을, 기계가 일관되게. 그리고 이 토대가 탄탄해야 그 위의 모든 분석(준수율·위험 등급·비교)이 의미가 있습니다. 그래서 심층 편을 이 토대부터 시작한 것이고요. 사용자 입장에서는 이 모든 게 "주소 한 줄 넣고 기다린다"로 요약됩니다. 뒤에서 얼마나 복잡한 일이 벌어지든, 앞에서는 단순해야 합니다. 복잡함은 시스템이 감당하고, 사용자에게는 결과만 깔끔하게 건네는 것 — 좋은 도구의 조건이 바로 이것이라고 생각합니다.

오늘은 파이프라인의 큰 단계만 봤습니다. 각 단계 안에서 더 깊은 이야기 — 렌더링이 실패하는 경우(수요일), 파이프라인을 단계별로 뜯어보며 왜 이 순서인지(금요일) — 는 이번 주에 이어갑니다.

🔐 특허로 지키는 부분

오늘 본 "화면 이미지에서 시각 요소(색·간격·크기·정렬)를 픽셀 단위로 정확히 재서, 디자인을 느낌이 아니라 측정값으로 바꾸는 방법"은 ViewCheck가 출원한 5건의 특허 중 시각 요소 분석(스크린샷 기반 픽셀 측정) 주제와 맞닿아 있습니다. "화면을 잰다"는 말은 간단하지만, 같은 화면을 누가 봐도·몇 번을 재도 같은 수치가 나오게 만드는 절차 — 어떤 기준으로 요소를 잡고, 어떻게 좌표·색·크기를 뽑고, 어떻게 재현 가능하게 정리하는지 — 자체를 권리로 정리해 둔 데 차별점이 있습니다. 오늘 이 네 단계 중 렌더링과 추출이 그 방법의 무대입니다.

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

마무리

오늘은 "URL 한 줄만 넣으면 그 뒤에서 벌어지는 일"을 네 단계로 봤습니다. 수집(어디를 볼지 정하기) → 렌더링(코드가 아니라 화면을 진짜로 그리기) → 추출(픽셀 단위로 재고 필요할 때 글자를 읽어 측정값으로 바꾸기) → 판정(846규칙과 여러 기준에 대조해 통과·미통과·해당없음으로 가르기). 이 네 단계가 자동으로 이어져서, 사람 손의 준비물 없이 사이트를 봅니다. 그리고 이게 모든 분석의 토대라, 여기가 부실하면 그 위가 다 부실해집니다.

한 문장으로 줄이면, "URL 한 줄"이라는 단순한 입력 뒤에는 수집·렌더·추출·판정이라는 네 단계가 자동으로 돌고 있고, 그게 모든 분석의 토대입니다. 결과 화면은 깔끔해 보여도, 그 깔끔함은 이 네 단계가 묵묵히 받쳐주기 때문입니다. 그리고 각 단계에는 정직의 원칙이 하나씩 박혀 있습니다. 수집은 "몇 페이지를 봤는지" 밝히고, 렌더링은 "사용자가 보는 그대로" 그리고, 추출은 "느낌이 아니라 측정값"으로 바꾸고, 판정은 "확신 없으면 비워두고 근거를 남긴다". 이 정직이 결과를 믿을 수 있게 만듭니다.

이번 주 나머지 글에서 더 들어갑니다. 수요일엔 "이 파이프라인이 실제로 어디서 잘 깨지는지" — 무한스크롤, 지연 로딩, 캡처 실패 같은 함정들을 익명 사례로 풀고, 금요일엔 파이프라인을 단계별로 더 자세히 뜯어보며 "왜 이 순서인지"를 정리하겠습니다. 오늘이 "URL 분석이 무엇을 하는지"의 큰 그림이었다면, 수요일은 "실제로 어디서 깨지는지", 금요일은 "왜 하필 이 순서인지"인 셈입니다. 심층 편 첫 주, 끝까지 따라와 주셔서 진심으로 고맙습니다. 수요일에 "캡처가 실패하는 사이트들"로 이어가겠습니다.

krds.viewcheck.co.kr