URL 한 줄만 넣으면 된다 — '운영 중인 진짜 사이트'를 보는 법

들어가며 — 첫 타자는 가장 직관적인 시점, 운영

지난주에 웹 품질을 보는 세 가지 시점 이야기를 드렸습니다. 만들기 전(설계), 만든 후(운영), 그 위에서(판단). 그리고 한 시점만 보면 절반만 보인다는 말씀도 드렸습니다. 이번 주부터는 그 세 시점을 하나씩 깊게 파볼 텐데, 첫 타자가 가장 직관적인 시점, 바로 운영 시점입니다. ViewCheck 용어로는 URL 분석이라고 부릅니다.

운영 시점이 왜 첫 타자냐면, 어차피 사용자가 마주하는 건 디자인 파일도 코드도 아니라 "지금 돌아가고 있는 실제 사이트"이기 때문입니다. 거기서 불편하면 그걸로 끝입니다. 아무리 설계가 훌륭했어도, 아무리 코드가 깔끔했어도, 지금 이 순간 사용자 화면에서 버튼이 안 눌리면 그 사이트는 사용자에게 "안 되는 사이트"입니다. 그래서 "진짜"를 보는 이 시점이 출발점으로 제일 자연스럽습니다.

그런데 막상 "운영 중인 사이트를 본다"는 게 말처럼 간단하지가 않습니다. 사람이 직접 보려면 지난주에 길게 짚었던 그 한계에 다 부딪힙니다. 페이지가 너무 많고, 화면 크기마다 다르게 보이고, 보는 사람마다 기준이 흔들립니다. 그래서 이걸 자동으로, 그것도 "URL 한 줄"만으로 해내는 게 핵심인데, 오늘은 그게 어떻게 가능한지, 그리고 그 안에서 실제로 무엇을 보는지를 개념 수준에서 풀어보려 합니다.

기술적으로 너무 깊이 들어가지는 않겠습니다. 세부 작동 원리는 이번 주 금요일, 그리고 다음 달부터 더 자세히 다룹니다. 오늘은 "URL을 넣으면 그 뒤에서 무슨 일이 벌어지는지"의 큰 그림을 잡는 게 목표입니다. 이게 잡히면, 왜 이 방식이 사람이 손으로 보던 것과 근본적으로 다른지가 보입니다.

참고로 이번 달은 세 가지 방법을 "개요"로 한 바퀴 도는 달입니다. URL 분석을 본격적으로 깊게 파는 건 다음 달(2개월차)부터입니다. 그러니 오늘 글은 "URL 분석이 대략 무엇을 하는 것인지" 감을 잡는 정도로 가볍게 읽으셔도 됩니다. 세부 작동 원리나 기술은 뒤에서 차고 넘치게 다룰 예정입니다.

URL 하나만 넣고 분석을 돌리면 나오는 ViewCheck 종합 결과 화면. 상단 점수 카드(전체/디자인스타일/컴포넌트/기본패턴/서비스패턴)와 그 아래로 영역별 결과를 펼치는 탭 줄, 위반 목록까지 한 화면에 모인 모습. 입력은 주소 하나, 출력은 이 한 장 (기관명·도메인 블러)

본론 1 — "URL만 넣는다"가 왜 중요한가

입력이 단순할수록 자동화가 쉬워진다

URL 분석의 첫 번째 특징은 입력이 URL 하나라는 것입니다. 별것 아닌 것 같지만 이게 꽤 중요합니다.

한번 생각해 보겠습니다. 사람이 점검하려면 무엇이 필요했나요. 지난주에 봤듯 페이지를 일일이 띄우고, 로그인하고, 개발자 도구를 열고, 가이드 문서를 옆에 띄워놓고 대조하고… 준비물이 많았습니다. 그런데 URL 분석은 그냥 주소 하나면 됩니다. "https://..."를 넣으면, 그 뒤는 시스템이 알아서 합니다.

입력이 단순하다는 건 곧 "누구나 시작할 수 있다"는 뜻입니다. 디자인을 몰라도, 코드를 몰라도, KRDS 846규칙을 외우지 않았어도, 주소만 알면 분석이 시작됩니다. 지난주에 "점검할 줄 아는 사람이 한두 명뿐"이라던 전문가 의존 문제가, 입구에서부터 낮아지는 것입니다. 진입 장벽이 URL 입력창 하나로 줄어듭니다.

이게 실무에서 왜 의미가 있는지 조금 더 풀어보겠습니다. 공공기관의 웹 담당자분들은 대부분 웹 전문가가 아닙니다. 행정 업무를 보다가 홈페이지 관리까지 겸하는 경우가 많습니다. 그런 분들께 "개발자 도구를 열고, 요소를 검사하고, computed style을 확인하세요"라고 하면 시작조차 막막합니다. 그런데 "주소 한 줄만 넣어보세요"라면 이야기가 달라집니다. 전문성이 없어도 첫걸음을 뗄 수 있고, 결과를 받아 든 다음에야 "아, 우리 사이트에 이런 문제가 있었구나"를 알게 됩니다. 점검의 문턱을 낮춘다는 건, 점검을 안 하던 조직이 점검을 시작하게 만든다는 뜻입니다. 이게 생각보다 큰 변화입니다.

그리고 입력이 단순하다는 건 자동화하는 쪽에서도 큰 이점입니다. 입력이 복잡하면 — 예를 들어 여러 파일을 올리고, 여러 옵션을 고르고, 인증 정보를 넣어야 한다면 — 그 입력을 준비하는 것 자체가 일이 되고, 준비 과정에서 실수가 생기고, 사람마다 다르게 넣어서 결과도 달라집니다. 그런데 입력이 "주소 하나"로 고정되면, 그 뒤의 처리 과정을 표준화하기가 쉽습니다. 누가 넣든 같은 주소면 같은 과정을 거치니까요. 단순한 입구가 곧 일관된 결과의 출발점이 되는 것입니다. 사람이 개입할 여지가 적을수록 흔들릴 여지도 줄어듭니다.

사람이 보던 환경을 똑같이 재현한다

URL을 넣으면 시스템이 제일 먼저 하는 일은, 그 사이트를 "실제 사용자가 보는 것과 똑같이" 띄우는 것입니다. 여기서 중요한 단어가 "똑같이"입니다.

단순히 HTML 코드를 받아오는 게 아닙니다. 요즘 웹사이트는 코드만 받아와서는 화면이 그려지지 않습니다. 자바스크립트가 돌아가야 메뉴가 나오고, 이미지가 로딩돼야 배너가 보이고, 스타일이 적용돼야 색과 간격이 잡힙니다. 그래서 진짜 브라우저처럼 페이지를 끝까지 그려내야(렌더링) 사용자가 보는 그 화면이 나옵니다.

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

왜 코드만 받아오면 안 되는지 조금 더 풀어보겠습니다. 옛날 웹사이트는 HTML 안에 내용이 다 들어 있어서, 코드만 봐도 화면을 짐작할 수 있었습니다. 그런데 요즘 사이트는 다릅니다. 처음 받아오는 HTML은 거의 빈 껍데기에 가깝고, 자바스크립트가 돌면서 그 안을 채웁니다. 메뉴도, 목록도, 표도 다 그렇게 나중에 그려집니다. 그래서 코드만 받아서 보면 "내용이 없는 사이트"로 보이기도 합니다. 실제로는 화면 가득 콘텐츠가 있는데도 말입니다. 끝까지 그려봐야 진짜 화면이 나온다는 게 이래서 중요합니다.

게다가 실제 환경을 재현한다는 건 자잘한 것도 챙긴다는 뜻입니다. 팝업이나 쿠키 동의 배너가 화면을 가리고 있으면 그걸 감안해야 하고, 로딩이 느린 페이지라면 다 뜰 때까지 기다려야 하고, 스크롤을 내려야 나타나는 콘텐츠도 있습니다. 사람이 직접 볼 때 무의식적으로 하던 이런 동작들을, 자동 분석도 비슷하게 처리해야 "사용자가 실제로 보는 화면"에 가까워집니다. 대충 받아서 보면 사용자가 보는 것과 다른 걸 보게 되니까요. "빨리 대충 캡처했다"와 "사용자가 보는 그대로 끝까지 그려냈다"는 결과물이 완전히 다릅니다. 후자를 안정적으로 해내는 게 실은 만만한 일이 아닙니다. 어떤 사이트는 보안 장비(WAF)가 자동 접근을 막고, 어떤 사이트는 무한 스크롤로 콘텐츠가 계속 붙고, 어떤 사이트는 특정 지역에서만 열립니다. 이런 변수들을 하나씩 넘어서 "진짜 화면"에 도달하는 것 자체가 URL 분석의 첫 관문입니다. 이 관문에서 무너지면 그 뒤의 정교한 분석은 의미가 없어집니다. 잘못 그려진 화면을 아무리 정밀하게 재봐야 틀린 결과만 나오니까요.

화면을 '본다'는 것의 의미

여기가 URL 분석의 진짜 핵심입니다. 화면을 그려낸 다음, 그걸 그냥 보여주는 게 아니라 "분석"합니다. 사람이 눈으로 보던 걸 기계가 대신 보는 것인데, 기계가 화면을 본다는 게 무슨 뜻일까요.

크게 두 가지를 합니다. 하나는 그려진 화면을 이미지로 캡처해서 시각적으로 분석하는 것입니다. 색이 무엇인지, 대비가 충분한지, 요소 간 간격이 어떤지, 버튼이 얼마나 큰지 같은 걸 픽셀 단위로 잽니다. 사람이 "느낌상" 보던 걸 기계는 정확한 수치로 잽니다. 지난주에 "눈으로는 6픽셀과 8픽셀을 구분하기 어렵다"고 했던 그 문제가 없어집니다. 6픽셀은 6픽셀로, 8픽셀은 8픽셀로 딱 떨어지게 나옵니다. 사람의 눈은 "비슷하다"고 넘기는 차이를, 기계는 "다르다"고 정확히 집어냅니다.

다른 하나는 화면 뒤의 구조를 같이 읽는 것입니다. 화면에 보이는 버튼이 코드상으로 어떻게 되어 있는지, 적절한 라벨이 붙어 있는지, 제목 구조가 논리적인지를 봅니다. 시각만 보는 것도, 구조만 보는 것도 아니라 둘을 같이 봅니다. 지난주 사례에서 "시각만 봐서 놓치고, 코드만 봐서 놓치고" 하던 걸, 한 번에 같이 보는 것입니다.

URL 한 줄이 헤드리스 브라우저로 흘러 들어가 페이지를 끝까지 그려낸 뒤, 시각을 재는 눈과 코드 구조를 읽는 눈이 그 화면을 동시에 판독하는 개념 도식. "먼저 그리고, 시각과 구조를 함께 읽는다"는 구조 (Gemini 1:1)

이 "시각 + 구조를 동시에, 화면 기준으로 본다"가 URL 분석의 정체성입니다. 사람이 한 번에 한쪽만 보던 한계를, 기계는 양쪽을 같이 봐서 넘습니다. 왜 이게 중요하냐면, 웹 품질 문제의 상당수가 정확히 이 "시각과 구조의 경계"에서 생기기 때문입니다. 예를 들어 화면상으로는 멀쩡한 버튼인데 코드에 라벨이 없어서 시각장애인 사용자에게는 "이름 없는 버튼"이 되는 경우가 있습니다. 이건 화면만 봐서는 절대 안 잡히고, 코드만 봐서는 "그 버튼이 실제로 화면에서 어떻게 쓰이는지"를 모릅니다. 두 정보를 겹쳐봐야 "화면엔 있는데 코드엔 이름이 없다"는 결론이 나옵니다. 사람이 이걸 하려면 화면 보는 눈과 코드 읽는 눈을 동시에 굴려야 하는데, 그게 한 사람 안에서 잘 안 됩니다. 기계는 두 정보를 나란히 놓고 대조하니까 이 경계의 문제를 놓치지 않습니다.

조금 더 구체적인 장면으로 그려보겠습니다. 디자인 담당자는 화면을 봅니다. "버튼 색 예쁘고, 배치 깔끔하고, 통과." 개발 담당자는 코드를 봅니다. "태그 구조 맞고, 스크립트 오류 없고, 통과." 두 사람 다 자기 자리에서 성실하게 봤고, 둘 다 "이상 없음"입니다. 그런데 그 버튼은 실은 이미지 위에 얹힌 장식일 뿐, 키보드로는 선택되지 않고 스크린리더는 아무것도 읽어주지 못합니다. 화면만 본 디자이너도, 코드 조각만 본 개발자도 이 사실에 도달하지 못했습니다. 두 정보가 만나는 지점을 아무도 안 봤기 때문입니다. URL 분석은 이 지점을 봅니다. 실제 렌더링된 화면에서 "여기 버튼처럼 생긴 게 있다"를 확인하고, 동시에 그 자리의 코드를 읽어 "그런데 이건 눌리는 버튼이 아니다"를 잡아냅니다. 사람 조직에서는 부서 사이의 틈으로 새던 문제가, 한 번의 분석 안에서 메워지는 것입니다.

여기서 "픽셀 단위로 잰다"는 게 실제로 무슨 뜻인지도 한 번 짚겠습니다. 사람이 화면을 볼 때는 "이 회색 글씨가 좀 흐린데?" 정도로 느낍니다. 느낌입니다. 그런데 브라우저는 그 글씨의 색과 배경색을 정확한 값으로 알고 있고, 두 색의 대비 비율을 계산할 수 있습니다. 그 비율이 기준선(예를 들어 일반 텍스트는 4.5 대 1) 아래면 "미달", 위면 "충족"으로 딱 떨어집니다. "흐린 것 같다"가 "대비 3.1 대 1, 기준 미달"이 되는 것입니다. 간격도 마찬가지입니다. "좀 좁아 보이는데"가 아니라 "요소 사이 간격 6px, 규격은 8px"로 나옵니다. 버튼 크기도 "작아 보인다"가 아니라 "38×38px, 터치 기준 44×44px 미달"입니다. 느낌을 수치로 바꾸는 이 과정이, 바로 "감으로 보는 점검"과 "근거로 보는 점검"을 가르는 지점입니다. 그리고 수치로 나오니까 재현되고, 재현되니까 증빙이 됩니다.

본론 2 — URL 분석이 한 번에 보는 것들

URL 하나를 넣으면 사실 꽤 많은 걸 한꺼번에 봅니다. 사람이 따로따로 며칠에 걸쳐 보던 영역들을, 한 번의 분석으로 같이 훑습니다. 어떤 것들인지 큰 갈래로 보겠습니다. 각각의 자세한 이야기는 앞으로 한 영역씩 풀 예정이니, 오늘은 "이렇게 넓게 본다" 정도만 잡고 가시면 됩니다.

하나의 URL이 한 번의 렌더링 위에서 846규칙(디자인 기준)·접근성·반응형·성능·보안·SEO 여러 갈래로 동시에 측정되는 개념 도식. 사람이 도구를 갈아끼우며 따로 돌리던 걸 한 번 띄우는 김에 같이 보는 구조 (Gemini 1:1)

디자인 기준 — KRDS 846규칙

가장 핵심은 KRDS 846규칙 판정입니다. 색·타이포·간격 같은 디자인 스타일(DS, 120개), 버튼·폼·표 같은 컴포넌트(CP, 446개), 폼 구조·오류 처리 같은 기본 패턴(BP, 108개), 검색·로그인 같은 서비스 패턴(SP, 172개). 지난주에 "846개를 사람이 손으로?"라고 했던 그 846개를, 화면을 기준으로 자동 판정합니다.

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

여기서 한 가지 미리 짚어둘 것은, 이 네 묶음이 그냥 편의상 나눈 게 아니라 각각 성격이 다르다는 점입니다. 디자인 스타일은 "눈에 보이는 시각 기초"를 수치로 재는 영역이고, 컴포넌트는 "부품 하나하나가 규격과 접근성 속성을 갖췄나"를 보는 가장 큰 영역이며, 기본 패턴은 "화면 한 장이 아니라 흐름"을 보고, 서비스 패턴은 "여러 단계를 거치는 업무 시나리오"를 봅니다. 그래서 판정 난이도도, 필요한 정보도 다 다릅니다. 이 네 묶음의 성격 차이는 5개월차(4대 카테고리 깊이)에서 하나씩 깊게 다룹니다. 오늘은 "846규칙이 네 갈래로 나뉘어 한 번에 판정된다"는 큰 틀만 잡으시면 됩니다.

웹 접근성

장애가 있는 사용자도 쓸 수 있는지를 봅니다. 대체텍스트가 있는지, 키보드로 조작되는지, 색 대비가 충분한지, 스크린리더가 읽을 수 있는지를 봅니다. 이건 권장이 아니라 법적 의무에 가까운 영역이라, 공공 사이트엔 특히 중요합니다. 그리고 지난주에 봤듯 색 대비 같은 건 사람 눈으로 판단하면 편차가 큰데, 화면을 기준으로 수치로 재면 그 편차가 사라집니다. "읽을 만한가"가 아니라 "대비 비율이 기준 이상인가"로 딱 떨어지니까요.

접근성이 왜 공공 사이트에서 유독 중요한지 조금 더 말씀드리겠습니다. 민간 사이트는 불편하면 사용자가 다른 사이트로 갑니다. 그런데 공공 사이트는 대체재가 없습니다. 세금을 내거나, 민원을 넣거나, 복지 혜택을 신청하는 창구가 그 사이트 하나뿐입니다. 그러니 그 사이트가 특정 사용자를 배제하면, 그 사용자는 서비스 자체에서 배제되는 것입니다. 고령자, 저시력자, 화면을 못 보는 분들이 실제로 그 창구를 써야 하는데 못 쓰게 되는 것이죠. 그래서 접근성은 공공 웹에서 "있으면 좋은 것"이 아니라 "없으면 안 되는 것"입니다. URL 분석은 이 영역을 여러 자동 검사 엔진으로 교차해서 봅니다. 한 엔진이 놓친 걸 다른 엔진이 잡도록요.

반응형 — 여러 화면 크기

같은 사이트를 데스크톱·태블릿·모바일에서 각각 봅니다. 지난주에 "모바일을 통째로 빠뜨려서 사고가 난" 사례가 있었는데, URL 분석은 여러 화면 크기를 같이 보니까 그 함정을 피합니다. 데스크톱에선 멀쩡한데 모바일에서 겹치는 것들이 여기서 잡힙니다. 사람이 하려면 화면 크기마다 다시 띄워서 또 봐야 하는 일이라 시간이 배로 드는데(그래서 보통 생략됐습니다), 기계는 같은 페이지를 여러 크기로 그려서 한 번에 비교하니 부담이 다릅니다.

ViewCheck는 구체적으로 데스크톱·태블릿·모바일 세 개의 뷰포트로 실제로 화면을 띄워 보고, 그 안에서 터치 타겟(손가락으로 누르는 버튼·링크의 크기)이 기준(44×44px)보다 작은 곳까지 짚어냅니다. "버튼이 작아서 자꾸 잘못 눌린다"는 민원이, 여기서는 오픈 전에 수치로 잡히는 것입니다. 눈으로는 "좀 작나?" 싶던 게, "이 버튼은 38×38px이라 기준 미달"로 딱 떨어집니다.

반응형이 특히 중요한 이유는, 화면 크기에 따라 문제가 아예 다르게 나타나기 때문입니다. 데스크톱에서는 가로로 넉넉하니 요소들이 여유롭게 배치되지만, 모바일에서는 그 요소들이 세로로 쌓이면서 서로 겹치거나, 화면 밖으로 밀리거나, 가로 스크롤이 생깁니다. 같은 페이지인데 화면 크기 하나 바꿨다고 완전히 다른 문제가 튀어나오는 것이죠. 그래서 "데스크톱에서 통과했으니 모바일도 괜찮겠지"라는 짐작이 위험합니다. 실제로는 반대인 경우가 흔합니다. 데스크톱은 멀쩡한데 모바일만 깨지거나, 태블릿 크기에서만 애매하게 어긋나거나. 세 크기를 다 실제로 띄워봐야 이 차이가 드러납니다. 이 반응형 품질을 어떤 기준으로, 어떻게 재는지는 다음 달 URL 분석 편에서 화면 크기별 사례와 함께 자세히 풀겠습니다.

성능·보안·SEO 같은 영역들

이 외에도 페이지가 얼마나 빨리 뜨는지(성능), 보안 설정이 되어 있는지(보안), 검색엔진이 잘 읽을 수 있는지(SEO) 같은 것도 같이 봅니다. 행정안전부의 7대 품질 영역(지난주에 잠깐 언급한 호환성·접근성·개방성·접속성·편의성·효율성·신뢰성)이 대체로 이 안에 들어옵니다. 디자인만이 아니라 사이트의 여러 면을 한 번에 보는 것입니다.

이게 가능한 이유는, 어차피 사이트를 실제로 띄워서 보는 김에 여러 면을 같이 잴 수 있어서입니다. 페이지를 그려내는 과정에서 "얼마나 걸렸나"를 재면 성능이 나오고, 받아오는 응답을 보면 보안 설정이 보이고, 페이지 정보를 읽으면 SEO가 보입니다. 사람이 하면 성능 도구 따로, 보안 점검 따로 돌려야 할 것을, 한 번 띄우는 김에 같이 보는 것입니다. "한 번 제대로 그려서 본다"는 토대가 있으니까 그 위에서 여러 측정이 얹히는 식입니다.

그리고 이 성능·보안·접속성 같은 영역은 본질적으로 운영 시점에서만 잴 수 있습니다. 왜냐하면 실제로 브라우저로 사이트에 접속해서 요청을 보내봐야 응답 시간이 나오고, 응답 헤더를 받아봐야 보안 설정이 보이고, 인증서를 확인해봐야 신뢰성이 판정되기 때문입니다. 디자인 파일이나 코드 조각만 봐서는 "이 사이트가 얼마나 빨리 뜨는지", "SSL 인증서가 곧 만료되는지"를 알 수 없습니다. 실물에 직접 들어가 봐야만 보이는 것들입니다. 그래서 이 영역들이야말로 URL 분석, 즉 운영 시점의 고유 영역입니다.

한 번에 본다는 게 핵심

여기서 중요한 건 "한 번에"입니다. 사람이 하면 디자인 보는 사람 따로, 접근성 보는 사람 따로, 성능 보는 사람 따로였습니다. 그리고 그걸 합치는 게 또 일이었습니다. URL 분석은 한 번의 분석으로 이걸 다 보고, 한곳에 모아줍니다. 따로 돌리고 합치는 수고가 사라지는 것입니다.

또 하나 짚을 것은, 이 영역들이 사실 한 페이지에만 적용되는 게 아니라는 점입니다. URL 분석은 보통 시작 주소에서 출발해 사이트 안의 여러 페이지를 따라 들어가며 봅니다. 그래서 위 영역들이 "메인 한 장"이 아니라 "사이트 여러 페이지"에 걸쳐 점검됩니다. 지난주에 "깊은 페이지를 못 봐서 거기서 사고가 난다"던 그 문제를, 사람 대신 기계가 페이지를 따라다니며 메웁니다. 물론 수백, 수천 페이지짜리 사이트를 통째로 다 보느냐는 설정과 상황에 따라 다르지만, 적어도 "메인만 보고 끝"은 아니라는 게 사람 점검과의 큰 차이입니다. 이 다중 페이지 분석의 원리와 집계 방식은 6개월차(다중 페이지 분석)에서 깊게 다룹니다.

물론 "넓게 본다"가 "다 똑같이 깊게 본다"는 뜻은 아닙니다. 영역마다 자동으로 잡을 수 있는 깊이가 다르고, 어떤 건 사람의 최종 판단이 필요합니다. 그 경계가 어디인지는 앞으로 영역별로 풀면서 솔직하게 짚을 생각입니다. 과장 없이 말씀드리겠습니다.

왜 이렇게 넓게 봐야 하나

"디자인 기준만 보면 되지, 왜 성능이며 보안까지 다 보느냐"고 하실 수 있습니다. 이유는 행정안전부의 「전자정부 웹사이트 품질관리 지침」이 요구하는 품질 영역 자체가 넓기 때문입니다. 앞서 말씀드린 7대 영역 — 호환성, 접근성, 개방성, 접속성, 편의성, 효율성, 신뢰성 — 이 어느 하나도 코드 한 줄이나 화면 한 장만 봐서는 판정이 안 됩니다.

호환성은 여러 브라우저에서 똑같이 보이는지의 문제이고, 접근성은 장애 사용자가 쓸 수 있는지의 문제이며, 개방성은 검색엔진이나 다른 시스템이 정보를 잘 읽어갈 수 있는지의 문제입니다. 접속성은 사이트가 얼마나 빨리 응답하는지, 효율성은 페이지가 얼마나 가볍게 뜨는지, 신뢰성은 보안과 인증서가 제대로 갖춰졌는지를 봅니다. 이 일곱 가지는 서로 다른 성격의 질문이고, 어느 하나만 잘한다고 "품질 좋은 사이트"가 되지 않습니다. 디자인은 예쁜데 느려서 사용자가 떠나면 소용없고, 빠른데 장애인이 못 쓰면 공공 사이트로서 실격입니다.

그래서 URL 분석은 이 넓은 영역을 한 번의 렌더링 위에서 같이 잽니다. 사람이라면 영역마다 다른 도구를 쓰고 다른 전문가를 불러야 할 것을, 한 번 띄워서 함께 보는 것이죠. 이 7대 영역이 결과 화면과 리포트에 어떻게 담기는지는 앞으로 달을 나눠 하나씩 다룹니다. 오늘은 "URL 분석이 디자인만이 아니라 사이트 품질 전반을 본다"는 폭만 기억해 주시면 됩니다.

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

본론 3 — 사람이 보던 방식과 무엇이 근본적으로 다른가

URL 분석이 "빠른 점검 도구"에 그치는 게 아니라는 걸 짚고 싶습니다. 속도만 빠른 게 아니라, 보는 방식 자체가 사람과 다릅니다. 지난주에 정리한 사람 점검의 한계에 하나씩 대보면 분명해집니다.

규모 — 지치지 않는다

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

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

사람은 오전과 오후가 다르고, 담당자 A와 B가 다릅니다. 컨디션에 따라, 경험에 따라 기준이 미묘하게 달라집니다. 기계는 같은 기준으로 봅니다. 어떤 페이지를 보든, 몇 번째로 보든, 같은 잣대입니다. 그래서 결과가 재현됩니다. 다시 돌려도 같은 결과가 나옵니다. 지난주에 "증빙하려면 재현 가능한 수치여야 한다"고 했던 그 토대가 여기서 생깁니다. 두 번 돌렸더니 점수가 다르게 나오는 도구는, 그 숫자를 근거로 쓸 수 없습니다. 같은 입력에 같은 출력이 나와야 비로소 "이 숫자를 믿고 보고할 수 있다"가 됩니다.

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

사람은 한 번에 한쪽만 깊게 봅니다. 시각이면 시각, 코드면 코드. 기계는 화면을 그려서 시각을 보면서, 동시에 그 뒤 구조도 읽습니다. 양쪽을 같이 보니까, 한쪽만 봐서 생기는 사각지대가 줄어듭니다. 앞서 말씀드린 "화면엔 있는데 코드엔 이름이 없는 버튼" 같은 경계의 문제를, 두 정보를 겹쳐봐서 잡아냅니다.

추적 — 같은 방식으로 다시 본다

사람은 매번 일회성이라 작년과 비교가 안 됩니다. 이번에 본 기준과 작년에 본 기준이 다르니, 나아졌는지 나빠졌는지 답을 못 합니다. 기계는 같은 방식으로 언제든 다시 볼 수 있습니다. 그래서 시점을 달리해서 비교가 됩니다. "지난번 대비 어떻게 변했나"가 답이 됩니다. 이 시점 비교와 추세 읽기는 11개월차(정기진단과 성과 증명)에서 본격적으로 다룹니다.

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

사람이 점검하면 디자인·접근성·성능을 따로 보고, 그걸 다시 보고서로 합치는 게 일이었습니다. URL 분석은 한 번 돌리면 그 결과가 한곳에 정리되어 나옵니다. 영역별로 흩어진 엑셀 여러 개가 아니라, 한 화면에 모인 결과입니다. 물론 이걸 의사결정자 언어로 다듬는 마지막 손질은 남지만, "따로 돌리고 따로 합치는" 그 큰 덩어리가 사라집니다. 시작점이 한곳이라 끝점도 한곳인 셈입니다.

이 "한곳에 모인다"는 게 실무에서 얼마나 큰지는, 흩어진 결과를 합쳐본 분이라면 아실 겁니다. 도구가 세 개면 결과 형식도 세 가지이고, 점수 기준도 제각각이라 단순히 더할 수도 없습니다. A 도구는 100점 만점, B 도구는 등급제, C 도구는 통과/실패로만 나오면, 이걸 하나의 "우리 사이트 상태"로 묶는 데만 며칠이 걸립니다. 그 과정에서 사람이 임의로 가중치를 매기니 결과의 객관성도 흔들립니다. URL 분석은 처음부터 하나의 기준 위에서 여러 영역을 재기 때문에, 그 합치는 수고와 그 과정의 자의성이 함께 사라집니다. 판정도 점수도 같은 출처에서 나오니, 보이는 모든 숫자가 서로 맞아떨어집니다. 상단에 뜬 점수와 그 아래 세부 항목의 합이 어긋나지 않는다는 것 — 사소해 보이지만, 보고서를 받아 드는 사람에게는 "이 결과를 믿어도 되나"를 가르는 지점입니다.

URL 한 번의 분석으로 함께 나오는 웹 접근성 결과 화면. 대체텍스트·색 대비·키보드·스크린리더 대응 등이 항목별로 판정된 모습. 디자인만이 아니라 여러 영역을 한 번에 본다는 걸 보여주는 자리 (기관명·도메인 블러)

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

여기까지 보면 "그럼 사람은 필요 없겠네" 싶으실 수 있는데, 그건 아닙니다. URL 분석이 잘하는 건 "넓고 일관되게, 빠르게, 반복해서 보는 것"입니다. 그런데 "이 위반이 우리 기관 맥락에서 얼마나 급한지", "이건 규칙은 어겼지만 의도된 예외 아닌지", "한정된 예산에서 무엇을 먼저 할지" 같은 판단은 여전히 사람의 몫입니다. 그게 지난주에 말씀드린 세 번째 시점(판단)이고, 그래서 세 시점이 다 필요한 것입니다.

URL 분석은 사람의 판단을 없애는 게 아니라, 판단할 거리를 깔끔하게 정리해서 갖다주는 쪽에 가깝습니다. 단순 확인 작업에 묻혀 있던 판단력을 제자리로 돌려놓는 것이죠. 사람은 "이 846개 규칙 중 뭐가 통과인지"를 일일이 세느라 진을 빼는 대신, "이 결과를 보니 우리 기관은 이걸 먼저 해야겠다"는 판단에 에너지를 쓰면 됩니다. 기계가 넓고 일관되게 깔아준 데이터 위에서, 사람이 맥락과 우선순위를 얹는 구조입니다.

본론 4 — 사람이 자주 빠뜨리던 곳을 어떻게 메우나

앞의 다섯 가지 차이(규모·일관성·시각+구조·추적·정리)를 조금 더 현장 언어로 풀어보겠습니다. 사람이 손으로 점검할 때 "자주 빠뜨리던 자리"가 대체로 정해져 있는데, URL 분석은 바로 그 자리들을 메우도록 되어 있습니다.

빠뜨리던 곳 ① — 깊은 페이지

사람은 보통 메인, 그리고 눈에 잘 띄는 몇 개 페이지를 봅니다. 그런데 정작 사용자가 오래 머무는 곳은 신청 페이지, 조회 페이지, 안내 페이지처럼 깊숙이 들어간 화면들입니다. 그 페이지들이 몇 년째 방치돼 있어도, 메인만 보는 점검에서는 안 드러납니다. URL 분석은 시작 주소에서 링크를 따라 안쪽으로 들어가며 여러 페이지를 수집합니다. 그래서 "메인은 최근에 새로 만들어 깔끔한데, 3년 전 신청 페이지는 그대로"인 상황이 있는 그대로 드러납니다.

빠뜨리던 곳 ② — 모바일

사람이 PC로 점검하면 모바일 화면은 통째로 빠지기 쉽습니다. "나중에 폰으로도 봐야지" 하다가 잊습니다. 그런데 요즘 공공 사이트 방문자의 상당수가 모바일입니다. PC에선 멀쩡한데 모바일에서 메뉴가 겹치거나 버튼이 화면 밖으로 밀리는 문제는, 모바일 화면을 실제로 띄워봐야 잡힙니다. URL 분석은 데스크톱·태블릿·모바일을 같이 그려서 보니까, 이 "빠뜨리기 쉬운 절반"을 기본으로 챙깁니다.

빠뜨리던 곳 ③ — 안 보이는 정보

색 대비, 코드 속 라벨, 보안 헤더, 응답 시간 같은 건 화면을 슥 봐서는 안 보입니다. 문제가 있어도 "겉보기엔 멀쩡"하니까 그냥 넘어갑니다. 그런데 이 안 보이는 정보들이 실은 접근성과 신뢰성의 핵심입니다. URL 분석은 화면 뒤의 값을 직접 읽어 수치로 내놓으니까, "겉보기엔 멀쩡한데 속은 미달"인 지점을 드러냅니다.

빠뜨리던 곳 ④ — 어제와 오늘의 차이

사람은 한 번 점검하고 나면 한동안 다시 안 봅니다. 그 사이 사이트는 계속 바뀝니다. 그래서 "점검 땐 괜찮았는데 지금은 깨진" 상태를 아무도 모릅니다. URL 분석은 같은 주소를 같은 기준으로 언제든 다시 넣을 수 있으니, "지금 이 순간"을 반복해서 확인할 수 있습니다. 이 이야기는 수요일 글에서 본격적으로 다룹니다.

이 네 자리는 공교롭게도 민원과 사고가 가장 많이 나는 곳과 겹칩니다. 사람이 빠뜨리기 쉬운 곳이 곧 문제가 숨기 좋은 곳이니까요. URL 분석의 값어치는, 화려한 기능이 아니라 바로 이 "빠뜨리기 쉬운 곳을 기본으로 챙긴다"는 데 있습니다.

본론 5 — 그럼 URL만 있으면 다 되나 (솔직한 한계)

여기까지 읽으면 URL 분석이 만능처럼 들릴 수 있는데, 솔직하게 한계도 짚고 가는 게 맞습니다. 과장하면 지난주에 비판한 "검사 통과의 함정"을 똑같이 만드는 것이니까요. 운영 시점도 운영 시점일 뿐, 못 보는 게 있습니다.

로그인 안쪽은 별도다

URL만 넣어서 보는 건 기본적으로 "누구나 접근 가능한 페이지"입니다. 로그인을 해야 들어가지는 페이지, 본인인증 뒤에 나오는 신청 내역 같은 건 주소만으로는 못 봅니다. 이건 별도 설정이나 다른 방식이 필요합니다. 공공 사이트는 민원·신청처럼 로그인 뒤가 중요한 경우가 많으니, "URL 분석으로 다 봤다"가 아니라 "공개 영역은 봤다"가 정확한 표현입니다. 이 경계를 흐리면 안 됩니다.

눌러봐야 나오는 건 또 다른 영역

지난주에 잠깐 본 "동작을 해봐야 나오는 것들" — 폼을 비우고 제출했을 때의 오류 메시지, 모달을 열고 닫는 흐름 같은 건 화면을 가만히 그려보는 것만으로는 완전히 다 잡기 어렵습니다. 일부는 자동으로 흉내 낼 수 있지만, 복잡한 상호작용일수록 한계가 있습니다. 이런 동적 영역은 솔직히 자동화가 더 까다로운 부분입니다. 어디까지 자동으로 잡히고 어디부터 사람 손이 필요한지, 그 경계도 앞으로 영역별로 짚겠습니다.

맥락 판단은 결국 사람(혹은 그 위의 AI)

가장 중요한 한계입니다. URL 분석은 "규칙에 맞나 안 맞나"를 잘 보지만, "이게 우리 기관 상황에서 진짜 문제인지", "이 위반은 의도된 예외인지"까지는 단독으로 판단하기 어렵습니다. 그건 지난주에 말씀드린 세 번째 시점(판단)의 일이고, 그래서 URL 분석 위에 LLM 분석이 얹히는 것입니다. URL 분석 혼자서 모든 걸 끝낸다고 하면, 그것도 또 하나의 "한 시점만 보기"가 됩니다.

이 한계들을 굳이 적는 이유가 있습니다. URL 분석이 강한 영역(넓고·일관되고·반복 가능한 운영 점검)은 분명한데, 그게 전부인 척하면 오히려 신뢰가 깨지니까요. 잘하는 걸 잘한다고 하고, 못 하는 건 다른 시점이 메운다고 하는 게 지난주 내내 드린 이야기입니다. URL 분석도 그 틀 안에 있습니다. 강점을 자랑하되 한계를 숨기지 않는 것, 그게 오히려 오래 신뢰받는 길입니다.

본론 6 — 실무에서 URL 분석은 언제, 어떻게 시작하나

개념은 그렇고, 실무에선 어떻게 첫걸음을 뗄까요. 몇 가지 현실적인 상황으로 나눠 보겠습니다.

이미 운영 중인 사이트가 있는 경우

가장 흔한 경우입니다. 이미 몇 년째 돌아가고 있는 사이트가 있고, "우리 사이트가 KRDS 기준에 얼마나 맞는지 궁금하다"는 상황입니다. 이럴 땐 그냥 그 운영 주소를 넣어보는 게 시작입니다. 디자인 파일이 없어도 됩니다. 오래된 사이트는 애초에 디자인 파일이 남아있지 않거나, 있어도 실제 화면과 달라진 지 오래인 경우가 많습니다. 그래서 이런 상황에서는 운영 시점(URL 분석)이 주력이 됩니다. 지금 실제로 돌아가는 그 화면을, 있는 그대로 보는 것이죠.

처음 넣어보면 대개 놀라십니다. "우리 사이트가 이렇게 문제가 많았나" 싶으신 거죠. 그런데 그 목록이 곧 개선의 출발점입니다. 그동안 안 보여서 없다고 여겼던 문제가, 실은 쌓여 있었을 뿐입니다. 보이기 시작하면 고칠 수 있습니다.

새로 만들거나 크게 개편하는 경우

새 사이트를 만드는 중이거나 대대적으로 개편하는 중이라면, 이야기가 조금 다릅니다. 이때는 설계 단계(Figma)에서 미리 잡는 게 가장 싸고, 개발·배포가 끝난 뒤에 운영 시점(URL)으로 실물을 확인하는 흐름이 이상적입니다. "디자인은 통과였는데 배포본은 위반"인 그 간극을, 배포 직후 URL 분석으로 잡는 것이죠. 설계 시점과 운영 시점을 어떻게 나눠 쓰는지는 7개월차(Figma 분석)에서 자세히 다룹니다.

이 경우 URL 분석은 "검수의 마지막 관문" 역할을 합니다. 개발사가 "다 됐습니다"라고 넘겨줬을 때, 그 말을 그대로 믿는 대신 운영 주소를 넣어 실제 결과물을 수치로 확인하는 것입니다. 발주처가 검수 근거를 손에 쥐게 되는 셈입니다.

정기적으로 관리해야 하는 경우

한 번 보고 끝이 아니라 계속 관리해야 한다면, 운영 시점을 주기적으로 돌리는 게 핵심입니다. 같은 주소를 같은 기준으로 정기적으로 넣어보면서 변화를 추적합니다. 콘텐츠가 자주 바뀌는 공공 사이트일수록 이게 중요합니다. 공지·보도자료·민원 안내가 매일 올라오는데, 그 과정에서 누군가 형식을 잘못 붙여넣거나 큰 이미지를 그대로 올리면 그 페이지가 조용히 깨집니다. 주기적으로 운영본을 보면 이런 게 쌓이기 전에 잡힙니다. 이 부분은 이번 주 수요일 글에서 "왜 운영본을, 그것도 계속 봐야 하는지"로 더 풀겠습니다.

공통점 — 시작은 언제나 주소 한 줄

세 경우 모두 시작은 같습니다. 운영 주소 한 줄을 넣는 것. 상황에 따라 그 뒤에 설계 시점을 앞세우느냐, 판단 시점을 두텁게 얹느냐가 달라질 뿐, 운영 중인 진짜 화면을 보는 이 첫걸음은 어느 경우에도 빠지지 않습니다. 그래서 URL 분석이 세 방법 중 가장 기본이자 출발점입니다.

한 가지 덧붙이면, "완벽하게 준비된 다음에 넣어보자"고 미루실 필요가 없습니다. 오히려 지금 상태 그대로 한 번 넣어보는 게 첫 진단으로서는 가장 정확합니다. 화장하지 않은 맨 얼굴을 봐야 어디를 고쳐야 할지가 정직하게 나오니까요. 준비를 마치고 넣으면 이미 손본 상태라, 원래 있던 문제가 가려집니다. 처음 넣어볼 때는 "부끄러운 현재 상태"를 그대로 넣으시는 게 좋습니다. 그 결과가 앞으로의 개선을 재는 기준선(출발점)이 되고, 다음에 다시 넣었을 때 "얼마나 나아졌는지"를 비교할 기준이 됩니다.

그래서 ViewCheck는

ViewCheck의 URL 분석이 바로 이 운영 시점을 담당합니다. krds.viewcheck.co.kr에서 주소 하나 넣으면, 방금 설명드린 일들이 그 뒤에서 벌어집니다. 사이트를 실제 사용자처럼 그려내고, 화면을 기준으로 시각과 구조를 같이 보고, 846규칙·접근성·반응형·성능 같은 걸 한 번에 훑어서 한곳에 모아줍니다. 위에서 본 실화면 한 장이 그 결과물입니다.

거창하게 들릴 수 있는데, 결국 지난주에 짚은 문제들을 운영 시점에서 푸는 것뿐입니다. 사람이 며칠 걸려 일관성 없이 보던 걸, 기계가 같은 기준으로 한 번에. 그리고 그 위에 판단(LLM 분석)을 얹어서 "그래서 무엇부터"까지 잇습니다.

그리고 이 모든 게 사용자 입장에서는 "주소 한 줄 넣고 기다린다"로 요약됩니다. 뒤에서 얼마나 복잡한 일이 벌어지든, 앞에서는 단순해야 합니다. 복잡함은 시스템이 감당하고, 사용자에게는 결과만 깔끔하게 건네는 것 — 좋은 도구의 조건이 바로 이것이라고 생각합니다. 담당자분이 개발자 도구를 열 줄 몰라도, KRDS 846규칙을 외우지 않았어도, 주소만 알면 자기 사이트의 상태를 수치로 받아 볼 수 있습니다. 그 문턱을 낮춘 게 URL 분석의 시작이자 핵심입니다.

오늘은 큰 그림만 봤습니다. "URL을 넣으면 실제 화면을 기준으로 넓게, 일관되게 본다" 정도입니다. 이 안에서 화면을 어떻게 읽어내는지(픽셀 단위로 재고, 글자를 읽어내고) 같은 더 구체적인 작동 방식은 다음 달 URL 분석 편에서 본격적으로 풀겠습니다.

한 가지만 더 강조하고 싶습니다. URL 분석의 가치는 "빠르다"에 있지 않습니다. 빠른 건 부수적인 이득이고, 진짜 가치는 "사람이 하던 방식으로는 애초에 불가능했던 걸 한다"는 데 있습니다. 수백 페이지를 같은 집중도로, 같은 기준으로, 시각과 구조를 함께, 반복 가능하게 보는 것. 이건 사람을 아무리 갈아 넣어도 안 되던 일입니다. 손이 느려서가 아니라, 사람의 눈과 기억이 그렇게 설계되어 있지 않아서입니다. 그러니 URL 분석을 "사람 대신 빨리 봐주는 도구"로만 이해하면 절반만 이해한 것입니다. "사람이 못 보던 방식으로 보는 도구"로 이해해야 이 시점의 진짜 값어치가 보입니다.

🔐 특허로 지키는 부분

오늘 본 "URL만으로 사이트를 실제 사용자처럼 그려내고, 픽셀 단위로 시각 요소를 재고, 코드 구조를 함께 읽으며, 여러 해상도로 보는 그 과정"은 ViewCheck가 출원한 특허 중 렌더링 기반 화면 수집·측정 주제와 맞닿아 있습니다. 말로는 "화면을 캡처해서 본다"로 간단해 보여도, 자바스크립트가 다 돌고 외부 모듈이 다 붙은 진짜 화면을 안정적으로 그려내고, 그 위에서 시각과 구조를 동시에 재는 절차를 권리로 정리해 둔 것이 차별점입니다.

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

마무리

오늘은 운영 시점, URL 분석의 큰 그림을 잡았습니다. URL 하나만 넣으면 시스템이 사이트를 실제 사용자처럼 그려내고, 코드가 아니라 그려진 화면을 기준으로 시각과 구조를 같이 봅니다. 846규칙·접근성·반응형·성능 같은 걸 한 번에, 일관된 기준으로, 지치지 않고, 반복 가능하게 봅니다. 사람이 손으로 보던 방식과 근본적으로 다른 지점들입니다.

정리하면 URL 분석은 "운영 중인 진짜 화면을, 코드가 아니라 보이는 그대로, 시각과 구조를 같이, 사이트 전체에 걸쳐, 일관된 기준으로, 반복해서" 보는 것입니다. 이 한 문장이 운영 시점의 전부입니다. 사람이 손으로 하던 일을 그대로 옮긴 게 아니라, 사람이 못 하던 방식으로 본다는 점이 핵심입니다. 그리고 이 방식이 있어야 비로소 그다음 이야기 — 왜 하필 운영본을 봐야 하고, 그 결과를 어떻게 읽어야 하는지 — 가 의미를 갖습니다.

이번 주 나머지 글에서 이걸 더 구체화하겠습니다. 수요일엔 "스테이징(테스트 서버)에선 멀쩡한데 운영에선 깨지는" 사례로, 왜 하필 실제 운영 사이트를 봐야 하는지를(익명으로) 풀고, 금요일엔 URL 분석이 내놓는 결과를 어떻게 읽는지 — 스무 개가 넘는 분석 영역을 어디서부터 어떻게 보는지 — 정리하겠습니다. 오늘이 "URL 분석이 무엇이냐"였다면, 수요일은 "왜 운영본이어야 하느냐", 금요일은 "그래서 결과를 어떻게 읽느냐"인 셈입니다. 세 편을 다 읽고 나면 운영 시점의 밑그림이 한 장으로 잡히실 것입니다.

오늘 딱 하나만 가져가신다면 이 문장이면 좋겠습니다. "우리 사이트가 KRDS 기준에 맞나?"라는 질문의 첫 대답은, 그 사이트의 운영 주소를 있는 그대로 넣어보는 데서 시작됩니다. 디자인 파일을 뒤지거나 코드를 열 필요 없이, 사용자가 지금 마주하는 그 화면을 그대로 보는 것. 그게 운영 시점이고, URL 분석입니다.

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

krds.viewcheck.co.kr