분석 결과, 어디부터 봐야 하나 — 스무 개가 넘는 분석 영역, 읽는 순서

들어가며 — 결과를 잘 읽는 것도 점검의 절반이다

이번 주 1개월차 두 번째 주의 마지막 글입니다. 월요일엔 URL 분석이 무엇인지(운영 시점, 화면 기준으로 넓게 본다)를 봤고, 수요일엔 왜 운영본을 봐야 하는지(가정이 아니라 현실, 스테이징은 멀쩡한데 운영은 깨지는 이유)를 봤습니다. 오늘은 가장 실용적인 부분입니다. 분석을 한 번 돌리면 결과가 꽤 많이 쏟아지는데, 그걸 어디서부터 어떻게 읽느냐 하는 것입니다.

URL 분석을 처음 돌려보면 결과가 생각보다 많습니다. 점수 카드도 있고, 영역이 여러 개 있고, 위반 목록도 깁니다. "정보는 많은데 무엇부터 봐야 할지 모르겠다"는 게 솔직한 첫 반응이실 겁니다. 지난주에 봤듯, 정보가 많기만 하고 우선순위가 없으면 오히려 막막합니다. 그래서 오늘은 결과를 읽는 순서와, 각 영역이 무엇을 보여주는지를 한 바퀴 돌아보려 합니다.

미리 말씀드리면, 분석 영역이 스무 개가 넘는다고 해서 스무 개를 다 똑같이 정독하실 필요는 없습니다. 읽는 순서와 "이 영역은 이럴 때 본다" 정도만 잡아두면, 필요할 때 필요한 영역으로 바로 가면 됩니다. 오늘 글은 그 지도를 그려드리는 셈입니다.

사실 결과를 읽는 데도 요령이 있습니다. 잘못 읽으면 정보가 많은 게 오히려 독이 됩니다. 다 중요해 보여서 우선순위를 못 정하거나, 숫자 하나에 휘둘리거나, 멀쩡한 걸 문제로 오해하거나. 그래서 오늘은 "어떤 영역이 있다"만이 아니라 "어떤 순서로, 무엇에 주의하며 읽느냐"까지 같이 다룹니다. 결과를 잘 읽는 것도 점검의 절반입니다. 아무리 좋은 분석도, 읽는 사람이 길을 잃으면 행동으로 안 이어지니까요.

여기서 한 가지 역설을 짚고 싶습니다. 분석이 넓고 깊어질수록, 결과를 읽기는 더 어려워집니다. 예전에 도구 하나로 좁게 보던 시절엔 결과도 단순했습니다. "오류 5건"처럼요. 그런데 스무 개가 넘는 영역을 한 번에 보면, 정보의 양 자체가 몇 배가 됩니다. 분석의 품질이 올라간 대가로, 읽는 사람의 부담이 늘어난 것이죠. 그래서 좋은 분석 도구일수록 "결과를 어떻게 읽어야 하는지"의 안내가 함께 있어야 합니다. 안 그러면 사용자는 정보의 바다에서 헤엄치다 지쳐, 결국 아무것도 안 하게 됩니다. 오늘 글이 그리려는 지도가 바로 이 안내입니다. 넓은 분석을 넓은 채로 두되, 그 안에서 길을 잃지 않게요.

참고로 이번 달은 개요 달이라, 각 영역의 깊은 내용(예: 접근성 세부 항목, 성능 지표 하나하나)은 다음 달부터 영역별로 따로 팝니다. 오늘은 "전체 지도"에 집중하겠습니다. 세부는 나중에 얼마든지 파고들 수 있으니, 오늘은 "어디에 무엇이 있고, 어떤 순서로 보면 되는지"라는 큰 틀만 편하게 잡아가시면 됩니다.

URL 하나로 분석한 종합 화면. 제일 위에 요약 점수 카드(전체/디자인스타일/컴포넌트/기본패턴/서비스패턴)가 있고, 그 아래로 영역별 결과를 펼치는 줄과 위반 목록이 이어진다. "요약 먼저, 영역으로 드릴다운"의 출발점이 되는 화면 (기관명·도메인 블러)

본론 1 — 먼저 큰 그림: 점수 카드부터

상단 요약을 먼저 본다

결과를 열면 제일 위에 요약 점수 카드가 있습니다. 여기부터 보는 게 맞습니다. 세부 위반 하나하나로 바로 들어가면 길을 잃습니다. 숲을 먼저 보고 나무로 가는 것입니다.

요약에서 보는 건 크게 두 가지입니다. 하나는 KRDS 4개 카테고리(디자인 스타일 DS, 컴포넌트 CP, 기본 패턴 BP, 서비스 패턴 SP)별 준수율입니다. 다른 하나는 7대 품질 영역(접근성·보안·성능 등) 같은 부가 영역의 상태입니다. 이걸 보면 "우리 사이트가 전반적으로 어느 영역이 약한지"가 한눈에 들어옵니다.

예를 들어 디자인 스타일은 80인데 접근성이 40이라면, 이 사이트는 보기엔 괜찮은데 장애가 있는 사용자한텐 불친절한 것입니다. 어디에 힘을 줘야 할지가 여기서 정해집니다. 세부로 들어가기 전에, 이 큰 그림으로 "오늘 나는 어느 영역을 깊게 볼까"를 정하면 됩니다.

이 요약을 먼저 보는 습관이 왜 중요한지 조금 더 말씀드리겠습니다. 사람은 결과 화면을 열면 본능적으로 눈에 띄는 것, 빨간색으로 표시된 것, 목록 맨 위에 있는 것부터 봅니다. 그런데 그렇게 세부부터 들어가면, 전체 그림 없이 지엽적인 것에 매달리게 됩니다. 하필 맨 위에 뜬 사소한 위반을 한참 들여다보다가, 정작 사이트 전체를 좌우하는 약한 영역은 못 보고 지나칠 수 있습니다. 요약을 먼저 보는 건, 이 "눈에 띄는 것에 끌려가는" 함정을 피하는 방법입니다. 지도를 먼저 펴고 목적지를 정한 다음 길을 나서는 것과, 일단 눈앞의 골목부터 들어가 보는 것의 차이입니다. 급할수록 요약부터. 이 순서 하나만 지켜도 결과 읽기의 절반은 성공입니다.

한 가지 짚어둘 것은, 여기서 쓰는 건 "점수"라기보다 "준수율"이라는 점입니다. 몇 점짜리 시험 성적처럼 받아들이기보다는, "기준 중 얼마나 맞췄는가"의 비율로 보시는 게 정확합니다. 그래야 "왜 이 숫자가 나왔는지"를 규칙 단위까지 거슬러 올라가 확인할 수 있습니다. 근거 없이 뚝 떨어진 점수가 아니라, 규칙 하나하나의 판정이 쌓여서 만들어진 비율이라는 감각이 중요합니다. 이 감각이 있으면 "점수가 낮다고 기죽고 높다고 방심하는" 대신, "이 비율은 어느 규칙들에서 깎였나"를 차분히 들여다보게 됩니다. 숫자를 성적표가 아니라 진단서로 읽는 것이죠.

점수 자체보다 '분포'를 보자

여기서 팁 하나 드리겠습니다. 준수율 숫자 하나에 너무 매이지 마시길 바랍니다. 중요한 건 "어디가 유독 낮은가"라는 분포입니다. 전체 평균이 70이어도, 한 영역이 30이면 거기가 급한 것입니다. 평균은 가려주는 효과가 있어서, 평균만 보면 약한 데를 놓칩니다.

그리고 지난주에 강조했듯, 이 숫자는 같은 기준으로 자동 산출된 것이라 재현됩니다. 다음에 다시 돌려도 같은 방식으로 나옵니다. 그래서 "이번 70"과 "다음번 75"를 비교하는 게 의미가 있습니다. 사람이 매번 다르게 매긴 숫자라면 이 비교가 아예 안 됐을 것입니다. 같은 잣대로 나온 숫자라야 시점 비교가 성립합니다. 수요일에서 본 "동영상처럼 변하는 사이트"를 따라가는 방법이기도 합니다.

하나 더 말씀드리겠습니다. 준수율이 낮다고 해서 그게 곧 "제일 급하다"는 뜻은 아닙니다. 어떤 영역은 준수율이 낮아도 사용자 영향이 작고, 어떤 영역은 준수율이 좀 높아도 거기 하나가 치명적일 수 있습니다. 예를 들어 잘 안 쓰는 페이지의 사소한 디자인 위반보다, 신청 폼의 접근성 결함 하나가 훨씬 급합니다. 그래서 준수율은 "어디를 들여다볼지" 정하는 출발점이지, 그 자체가 우선순위는 아닙니다. 진짜 우선순위는 위반 목록에서 심각도로 가립니다(본론 3). 준수율은 지도, 우선순위는 동선인 셈입니다.

본론 2 — 스무 개가 넘는 분석 영역, 무엇을 어디서 보나

이제 분석 영역들을 돌아보겠습니다. URL 분석 결과는 예전보다 훨씬 넓어져서, 지금은 스무 개가 넘는 영역으로 펼쳐집니다. 규칙 판정만이 아니라, 접근성·반응형·성능·보안·SEO 같은 품질 영역, 그리고 그 위에서 결과를 정리해주는 종합·판단 영역까지 있습니다. 한 번에 다 외우실 필요 없고, "아, 이런 게 어디에 있구나" 정도로 훑으시면 됩니다. 성격이 비슷한 것끼리 묶어서 보겠습니다.

결과 읽는 동선을 4단계로 보여주는 개념 도식. 요약 점수 카드(요약 먼저) → 약한 영역으로 드릴다운 → 위반은 우선순위·빈도·위치 순 → 기록해서 다음과 비교. "스무 개가 넘는 영역을 이 순서로 읽는다"는 지도 (Gemini 1:1)

묶음 ① — 종합·요약 영역 (제일 먼저 보는 곳)

가장 먼저 보면 좋은 건 전체를 요약해주는 영역입니다. 종합 화면, 그리고 임원 보고용 요약이 여기 해당합니다. 전체 준수율, 핵심 위험, 개선 우선순위가 위에서부터 한 장으로 정리됩니다. 바쁜 의사결정자나, 처음 보는 사람이 큰 그림을 잡기 좋습니다. 세부 수백 건을 다 볼 시간이 없으면 여기만 봐도 핵심은 잡힙니다. 점검하고 나서 그 결과를 다시 보고서로 옮겨 적던 "보고 변환" 수고를, 이 영역이 상당히 덜어줍니다. 분석 결과가 흩어진 데이터 더미로 남으면 결국 사람이 밤새 보고서로 옮겨 적어야 하는데, 그 병목을 줄여주는 자리입니다.

묶음 ② — KRDS 규칙 판정 (DS·CP·BP·SP)

분석의 핵심인 846규칙 판정입니다. 네 카테고리로 나뉩니다.

디자인 스타일(DS, 120개) — 색·타이포·간격·정렬·대비 같은 시각 요소를 봅니다. "우리 사이트가 디자인 기준에 맞나"가 궁금하면 여기입니다. 브랜드 색을 제대로 쓰는지, 글자 위계가 잡혀 있는지 같은 게 나옵니다.
컴포넌트(CP, 446개) — 버튼·입력폼·내비게이션·카드·모달·표 같은 UI 요소를 봅니다. 가장 항목이 많은 영역입니다. "버튼이 규격에 맞나", "폼에 라벨이 제대로 있나" 같은 걸 봅니다. 사용자가 직접 만지는 부분이라 실제 불편과 직결됩니다.
기본 패턴(BP, 108개) — 폼 구조, 동의·확인 흐름, 오류 처리 같은 상호작용 패턴을 봅니다. "신청서가 제대로 설계됐나", "오류가 났을 때 잘 안내하나" 같은 영역입니다.
서비스 패턴(SP, 172개) — 검색·로그인·신청·정책 안내 같은 서비스 단위 흐름을 봅니다. "검색이 검색답게 동작하나", "로그인 흐름이 매끄러운가" 같은 큰 흐름입니다.

이 네 카테고리의 성격 차이와 깊은 내용은 5개월차(4대 카테고리 깊이)에서 하나씩 자세히 다룹니다.

묶음 ③ — 웹 접근성 (접근성·KWCAG)

장애가 있는 사용자도 쓸 수 있는지를 봅니다. 대체텍스트·키보드·색 대비·스크린리더 대응을 봅니다. 공공 사이트엔 법적 의무에 가까운 영역이라 특히 중요합니다. "회색 글씨가 안 보인다" 류의 민원이 여기서 미리 잡힙니다. ViewCheck는 이 영역을 여러 검사 엔진으로 교차해서 보고, 한국 웹 접근성 지침(KWCAG) 항목도 별도로 정리해줍니다. 한 엔진이 놓친 걸 다른 엔진이 잡도록요. 접근성 영역을 볼 때는 "몇 퍼센트"보다 "어떤 사용자가 무엇에서 막히는가"를 함께 보시는 게 좋습니다. 예를 들어 대체텍스트가 없으면 화면을 못 보는 사용자가 그 이미지의 내용을 전혀 알 수 없고, 색 대비가 낮으면 저시력 사용자가 글씨를 못 읽습니다. 각 위반이 "누구를, 어떻게 배제하는가"로 읽으면, 왜 이걸 고쳐야 하는지가 분명해집니다.

묶음 ④ — 반응형·성능 (화면 크기와 속도)

같은 사이트를 데스크톱·태블릿·모바일에서 어떻게 보이는지 보는 반응형 영역, 그리고 페이지가 얼마나 빨리·안정적으로 뜨는지 보는 성능(웹 바이탈) 영역입니다. 반응형은 수요일에 강조한 그 부분입니다. 모바일에서만 깨지는 걸 여기서 확인합니다. 성능은 느리면 사용자가 떠나니까, 이탈률과 직결됩니다. 로딩 속도만이 아니라 화면이 갑자기 밀리는 정도(레이아웃 안정성)까지 봅니다. 반응형 영역을 볼 때는 세 화면 크기를 나란히 놓고 "어느 크기에서 깨지는가"를 보시면 됩니다. 대개 모바일에서 문제가 몰립니다. 성능 영역은 숫자가 낯설 수 있는데, 핵심만 보면 됩니다. "얼마나 빨리 첫 화면이 뜨나", "화면이 안정적으로 자리 잡나", "누르면 얼마나 빨리 반응하나". 이 세 가지가 사용자 체감과 직결됩니다. 세부 지표 하나하나는 다음 달 성능 편에서 풀 테니, 오늘은 "이 영역이 속도와 안정성을 본다" 정도만 잡으시면 됩니다.

묶음 ⑤ — 보안·신뢰성·SEO·개방성

보안 설정이 되어 있는지, SSL 인증서는 제대로인지 같은 신뢰성 영역, 그리고 검색엔진이 잘 읽을 수 있는지(SEO), 정보가 잘 개방돼 있는지(개방성)를 봅니다. 브라우저에서 "주의 요함"이 뜨는 사이트가 안 되려면 보안 영역을 봐야 하고, 좋은 정보인데 검색에 안 나오는 문제는 SEO 영역에서 보입니다. 이 영역들은 실제로 사이트에 접속해서 응답을 받아봐야 판정되는 것이라, 운영 시점의 고유 영역입니다.

이 묶음은 평소엔 잘 안 보다가 사고가 나야 찾게 되는 영역이기도 합니다. 예를 들어 SSL 인증서는 만료일이 있는데, 이게 지나면 사용자 브라우저에 큰 경고가 뜨면서 "안전하지 않은 사이트"로 표시됩니다. 공공 사이트가 이렇게 뜨면 신뢰에 큰 타격입니다. 그런데 인증서 만료는 조용히 다가옵니다. 아무도 신경 안 쓰다가 만료 당일에야 터집니다. 이 영역을 주기적으로 보면, 만료가 다가오는 걸 미리 알 수 있습니다. SEO·개방성도 마찬가지입니다. 검색엔진이 페이지를 못 읽게 막아두는 설정이 실수로 들어가 있으면, 아무리 좋은 정보를 올려도 검색에 안 나옵니다. "우리 사이트가 검색이 안 된다"는 문제의 원인이 대개 여기 있습니다. 눈에 잘 안 띄는 영역이라 놓치기 쉬운데, 놓치면 크게 아픈 곳들입니다.

묶음 ⑥ — 위반 목록과 판단·심화 영역

발견된 위반들을 모아놓은 위반 목록, 그리고 그 위에서 결과를 해석해주는 여러 심화 영역이 있습니다. 위반을 위험도로 등급화해 우선순위를 매기고, KRDS 기준과 비교해주고, 비슷한 기관들과의 벤치마킹을 보여주고, 시점별 변화를 성과 대시보드로 정리하고, 위반이 초래할 수 있는 위험을 짚어주고, 개선에 드는 비용과 작업량을 추정해주는 영역들입니다. 여기가 지난주에 말씀드린 세 번째 시점(판단)이 결과에 얹히는 자리입니다. "그래서 결론적으로 무엇부터, 어떻게, 얼마의 노력으로"를 잡을 때 봅니다. 이 심화 영역들은 앞으로 여러 달에 걸쳐 하나씩 깊게 다룹니다. 예를 들어 위험도 등급화는 4개월차, 개선 실행은 9개월차, 벤치마킹은 10개월차, 정기 성과는 11개월차입니다.

이 심화 영역들이 하는 일을 한마디로 하면 "데이터를 결정으로 바꾸는 것"입니다. 앞의 규칙·품질 영역들이 "무엇이 어떻게 됐다"는 사실을 보여준다면, 이 심화 영역들은 "그래서 무엇을 할 것인가"를 잡게 해줍니다. 위반이 몇백 건이라는 사실만으로는 아무 결정도 못 합니다. 그런데 그 위반을 위험도로 줄 세우고, 비슷한 기관들과 비교해 우리 위치를 보여주고, 고치는 데 얼마가 드는지 추정해주면, "이번 예산으로 이 다섯 개를 이 순서로 고친다"는 결정이 나옵니다. 사실을 결정으로 번역하는 층이 바로 이 심화 영역입니다. 그래서 실무자가 아니라 의사결정자에게 가장 유용한 부분이기도 합니다.

왜 이렇게 영역이 많아졌나

"예전엔 열두 개쯤이라더니 왜 이렇게 늘었나" 싶으실 수 있습니다. 이유는 단순합니다. 분석이 깊어지면서, 하나의 큰 영역이 여러 세부 영역으로 나뉘었기 때문입니다. 예를 들어 "보안"이라고 뭉뚱그리던 게 지금은 보안 헤더, 인증서·신뢰성, 웹 취약점처럼 세분화됐고, "성과·개선"이라고 하던 것도 위험도, 법적 리스크, 성과 대시보드, 비용·작업량 추정처럼 나뉘었습니다. 뭉뚱그려 보던 걸 쪼개서 보니, 각 영역을 더 정확히 짚을 수 있게 됐습니다. 그래서 영역이 늘어난 건 복잡해진 게 아니라 정밀해진 것입니다.

물론 사용자 입장에선 영역이 많으면 부담스러울 수 있습니다. 그래서 앞서 묶어서 소개한 것처럼, 비슷한 성격끼리 묶어서 이해하면 됩니다. 규칙을 보는 곳(DS·CP·BP·SP), 품질을 보는 곳(접근성·반응형·성능·보안·SEO), 결과를 해석해주는 곳(종합·위험도·비용·벤치마킹·성과). 이 세 덩어리로만 기억해도 충분합니다. 세부 영역은 필요할 때 그 덩어리 안에서 찾아 들어가면 됩니다. 스무 개가 넘는 영역을 낱낱이 외우려 하면 부담이지만, 세 덩어리로 묶어 이해하면 머릿속에 지도가 그려집니다.

다 볼 필요는 없다

스무 개가 넘는 영역을 묶어서 소개했지만, 실제론 상황에 맞는 몇 개만 깊게 보시면 됩니다. 접근성이 걱정이면 접근성 영역을, 모바일 민원이 있으면 반응형 영역을, 리뉴얼 검수면 디자인 스타일과 컴포넌트를. 요약(본론 1)에서 약한 영역을 확인하고, 그 영역으로 바로 가는 식입니다. 영역이 많다는 건 "넓게 본다"는 뜻이지 "다 정독해야 한다"는 뜻이 아닙니다.

참고로 영역별로 "자주 걸리는 것"이 대략 정해져 있습니다. 디자인 스타일에선 표준 밖 색·간격이, 컴포넌트에선 라벨 없는 버튼·작은 터치 타겟이, 접근성에선 대체텍스트 누락·낮은 대비가, 반응형에선 모바일 겹침·가로 스크롤이, 성능에선 큰 이미지로 인한 지연이 단골입니다. 처음 보는 사이트라도 이 단골들부터 확인하면, 어느 영역이 약한지 금방 감이 옵니다. 공공 사이트는 특히 접근성과 반응형에서 자주 걸리는 편이라, 시간이 없으면 이 둘부터 보셔도 됩니다. 단골 위반을 알고 있으면, 처음 보는 사이트라도 어디를 먼저 열어봐야 할지 감이 서니 훨씬 빠릅니다.

본론 3 — 위반 목록, 막막하지 않게 읽는 법

우선순위부터 본다

영역 중에 제일 부담스러운 게 위반 목록입니다. 길면 수백 건이니까요. 지난주에 본 그 "목록은 긴데 손 못 대는" 상태가 여기서 생깁니다. 그래서 읽는 순서가 중요합니다.

먼저 우선순위(심각도)부터 봅니다. 위반이 다 같은 무게가 아닙니다. 사용자한테 치명적인 것과, 사소한 것이 섞여 있습니다. 보통 P0부터 P3 같은 등급으로 나뉘는데(이건 4개월차 위험도 편에서 자세히), 제일 급한 것부터 보면 "다 고쳐야 한다"는 압박 대신 "이것부터"라는 출발점이 생깁니다.

심각도를 가르는 기준은 대략 "사용자가 얼마나, 어떻게 막히느냐"입니다. 예를 들어 신청 버튼을 아예 누를 수 없게 만드는 위반은 최상위 등급입니다. 그게 막히면 서비스 자체를 못 쓰니까요. 반면 잘 안 쓰는 안내 페이지의 글자 간격이 살짝 안 맞는 건 한참 아래입니다. 불편하긴 해도 일을 못 하게 막진 않으니까요. 이렇게 "치명도" 순으로 보면, 같은 한 시간을 써도 사용자한테 가장 큰 차이를 만드는 것부터 손대게 됩니다. 한정된 시간과 예산을 어디에 쓸지가 여기서 정해집니다.

이 우선순위가 왜 그렇게 중요한지, 반대 상황을 상상해보면 분명해집니다. 우선순위 없이 위반 200건을 받았다고 해봅시다. 담당자는 어디부터 손대야 할지 모릅니다. 그래서 대개 "목록 맨 위부터" 혹은 "고치기 쉬운 것부터" 손댑니다. 그런데 목록 순서나 난이도는 사용자 영향과 아무 상관이 없습니다. 고치기 쉬운 사소한 것 열 개를 고치는 동안, 정작 치명적인 위반 하나는 그대로 남아 있을 수 있습니다. 노력은 노력대로 들었는데, 사용자가 겪는 진짜 문제는 안 풀린 것이죠. 우선순위는 이 "노력과 효과의 어긋남"을 막아줍니다. 가장 아픈 곳부터 짚어주니, 적은 노력으로 큰 개선을 만듭니다.

그리고 심각도 등급은 단순히 "빨강·노랑·초록"으로 색만 칠하는 게 아닙니다. 그 등급이 준수율 점수에도 다르게 반영됩니다. 치명적인 위반은 점수를 무겁게 깎고, 사소한 위반은 가볍게 깎습니다. 그래야 점수가 현실을 담습니다. 화면을 못 보는 사용자가 아예 버튼을 못 누르게 되는 위반과, 간격이 2px 어긋난 위반을 똑같은 무게로 세면, 점수가 사이트의 실제 상태를 못 보여주니까요. 이 가중치 산출의 원리는 3개월차(846규칙과 점수의 원리)에서 자세히 다룹니다. 오늘은 "위반마다 무게가 다르고, 그 무게 순으로 읽는다" 정도만 잡으시면 됩니다.

빈도와 위치를 같이 본다

두 번째로 볼 건 "이 위반이 얼마나 많이, 어디서 나오나"입니다. 같은 위반이 한 페이지에만 있는 것과, 100페이지에 다 퍼져 있는 것은 무게가 다릅니다. 여러 페이지에 반복되는 위반은, 보통 공통 요소(예를 들어 모든 페이지에 들어가는 헤더나 버튼)에서 나온 것이라 하나만 고치면 한꺼번에 해결되기도 합니다. 효율이 좋은 것이죠.

위치도 중요합니다. 메인에 있는 위반과 깊은 페이지에 있는 위반은 영향 범위가 다릅니다. URL 분석이 사이트 전체를 보니까(수요일), 메인만이 아니라 깊은 페이지 위반까지 위치가 같이 나옵니다. 어디가 문제인지 화면 위치까지 짚어주면, 고치러 갈 때 헤매지 않습니다.

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

그래서 실무에서 위반 목록을 볼 때는, "심각도"와 "빈도"를 겹쳐서 보는 게 요령입니다. 심각도가 높으면서 빈도도 높은 위반 — 즉 치명적인데 여러 페이지에 퍼져 있는 것 — 이 최우선입니다. 하나 고치면 여러 페이지에서 치명적 문제가 한꺼번에 사라지니까요. 가성비가 가장 좋은 개선 지점입니다. 반대로 심각도도 낮고 한 페이지에만 있는 위반은 한참 뒤로 미뤄도 됩니다. 이 두 축(얼마나 아픈가 × 얼마나 퍼져 있는가)으로 위반을 보면, 긴 목록이 자연스럽게 "먼저 손댈 것"과 "나중에 볼 것"으로 갈립니다. 목록 순서대로 위에서 아래로 훑는 것과는 완전히 다른 접근입니다.

"어떻게 고치나"까지 있으면 본다

마지막으로, 위반마다 "어떻게 고치면 되는지"가 붙어 있으면 그걸 봅니다. 위반 이름만 있으면 또 찾아봐야 하지만, 개선 방법이나 예시가 같이 있으면 바로 행동으로 갑니다. 지난주에 말씀드린 판단 시점(LLM 분석)이 이걸 거듭니다. 발견에서 끝내지 않고 개선까지 잇는 것입니다. 이 개선안 생성의 원리는 8개월차(LLM 분석)와 9개월차(개선 실행)에서 다룹니다.

이 "개선 방법까지 함께"가 왜 중요하냐면, 위반을 찾는 것과 고치는 것 사이에는 생각보다 큰 간극이 있기 때문입니다. "이 버튼에 라벨이 없습니다"라는 지적을 받아도, 웹 전문가가 아닌 담당자는 "그래서 어떻게 하라는 거지?" 싶습니다. 개발사에 다시 물어봐야 하고, 그 과정에서 시간이 흐릅니다. 그런데 "이 버튼에 이런 식으로 라벨을 붙이면 됩니다"라는 구체적인 방법이나 예시가 함께 있으면, 그 간극이 확 줄어듭니다. 발견에서 개선까지의 거리가 짧아지는 것이죠. 결과를 읽을 때 개선 방법 칸이 있으면 꼭 함께 보시고, 그걸 그대로 개발사에 전달하면 소통이 훨씬 수월해집니다.

정리하면 위반 목록은 이 순서로 읽습니다. 우선순위 → 빈도·위치 → 개선 방법. 위에서부터 보면, 긴 목록도 "오늘 고칠 다섯 개"로 좁혀집니다.

발견된 위반을 모아 위험도(P0~P3)와 빈도·위치·개선 방법과 함께 정렬해 보여주는 위반 목록 화면. 긴 목록을 우선순위 순으로 좁혀 읽는 자리 (기관명·도메인 블러)

한 번에 다 고치려 하지 말 것

여기서 마음가짐도 중요합니다. 위반 목록을 보면 죄책감 비슷한 게 생깁니다. "이렇게 많이 잘못돼 있었나." 그런데 그 목록은 "그동안 쌓인 전부"라서 많아 보이는 게 당연합니다. 한 번에 다 고치겠다고 덤비면 지쳐서 아무것도 못 합니다. 차라리 이번 분기엔 최상위 다섯 개, 다음 분기엔 그다음. 그렇게 깎아나가는 게 현실적입니다. 위반 목록은 "오늘의 숙제"가 아니라 "앞으로의 개선 백로그"로 보는 게 맞습니다. 그리고 자동 분석이 있으면 이 백로그가 줄어드는 걸 다음 점검에서 숫자로 확인할 수 있으니, 깎는 재미도 생깁니다.

"다 고쳐야 한다"는 생각은 사실 "아무것도 안 고친다"와 이어지기 쉽습니다. 완벽하게 다 고칠 수 없다는 걸 아는 순간, 시작할 엄두가 안 나서 미루게 되니까요. 그래서 목록을 잘게 쪼개 "이번엔 이만큼만"으로 정하는 게 오히려 실제 개선으로 이어집니다. 완벽을 목표로 멈춰 서느니, 우선순위 높은 것부터 한 걸음씩 나아가는 게 훨씬 낫습니다. 분석 결과가 우선순위를 매겨주는 이유도 바로 이것입니다. "전부"라는 막막함을 "이것부터"라는 첫걸음으로 바꿔주려는 것이죠.

본론 4 — 결과를 '한 번 보고 끝'으로 두지 않기

기록으로 남긴다

결과를 잘 읽었으면, 그걸 기록으로 남기는 게 좋습니다. 수요일에서 봤듯 사이트는 계속 변하니까, 이번 결과는 "이 시점의 상태"입니다. 다음에 다시 보고 비교하려면, 이번 걸 남겨둬야 합니다.

자동 분석의 장점이 여기서도 나옵니다. 같은 기준으로 나온 결과라, 다음번 결과와 그대로 비교가 됩니다. "지난번 위반 200건 → 이번 150건", "접근성 40 → 55" 같은 변화가 보입니다. 지난주에 본 "작년보다 나아졌냐에 답 못 한다"가, 이렇게 풀립니다.

이 비교가 되면 일하는 맛이 달라집니다. 개선이 숫자로 보이니까요. "이번 분기에 최상위 다섯 개를 고쳤더니 접근성이 15점 올랐다" 같은 게 눈에 보이면, 다음 분기 개선도 동기가 생깁니다. 반대로 어딘가 슬쩍 나빠졌으면 그것도 바로 잡힙니다. 콘텐츠를 잘못 올려서 깨진 페이지 같은 건, 시점 비교에서 "갑자기 위반이 늘었네"로 드러납니다. 이게 수요일에서 말씀드린 "동영상처럼 변하는 사이트"를 따라가는 방식입니다. 사진 한 장이 아니라 연속된 기록으로요.

이 "개선을 증명하는" 기능은 공공기관에서 특히 값집니다. 담당자가 열심히 사이트를 개선했어도, 그걸 윗선에 보여줄 방법이 없으면 노력이 인정받지 못합니다. "작년보다 나아졌습니다"라고 말로만 하면 설득력이 약합니다. 그런데 "작년 이맘때 준수율 62%, 지금 78%, 위반은 210건에서 130건으로"라고 같은 기준의 숫자로 보여주면, 개선이 명확한 성과로 남습니다. 노력이 숫자로 증명되는 것이죠. 이건 다음 해 예산을 확보하거나, 개선 사업의 필요성을 설득할 때 강력한 근거가 됩니다. 점검이 "문제를 지적하는 도구"에서 "성과를 증명하는 도구"로 바뀌는 지점입니다. 이 성과 증명의 원리는 11개월차(정기진단과 성과 증명)에서 본격적으로 다룹니다.

전체 준수율, 핵심 위험, 개선 우선순위가 위에서부터 한 장으로 정리된 종합·임원 보고 요약 화면. 세부 수백 건을 다 보고할 필요 없이 "현황 → 우선 과제 → 기대 효과"의 뼈대가 잡히는 자리 (기관명·도메인 블러)

보고로 옮길 때

결과를 윗선에 보고할 땐, 본론 1의 요약과 본론 3의 우선순위를 가져가면 됩니다. "전반적으로 이렇고(요약), 제일 급한 건 이것들이다(우선순위), 이렇게 고칠 것이다(개선 방법)." 세부 수백 건을 다 보고할 필요 없습니다. 종합·임원 보고 요약이 이 작업을 상당히 덜어줍니다.

보고할 때 한 가지 더 말씀드리겠습니다. 의사결정자는 보통 "그래서 무엇을 해야 하고, 그게 무슨 효과가 있냐"를 알고 싶어 합니다. 위반 목록 자체보다, "이 다섯 개를 고치면 접근성이 이만큼 올라가고, 민원이 줄어든다"는 식의 연결이 통합니다. 그래서 보고는 위반 나열이 아니라 "현황 → 우선 과제 → 기대 효과" 순으로 짜는 게 좋습니다. 분석 결과의 요약·우선순위·개선안이 이 뼈대를 거의 그대로 채워주니까, 거기에 우리 기관 맥락만 한 줄씩 얹으면 보고서가 됩니다. 점검하고 또 보고서 만드느라 야근하던 그 장면이, 여기서 한결 가벼워집니다.

그리고 보고 자리에서 "이 점수 근거가 뭐냐"는 질문이 나왔을 때, 근거가 규칙 단위까지 추적되면 그 자리에서 답이 됩니다. "846개 규칙 중 이 항목들이 이 페이지에서 이렇게 걸렸고, 근거 화면이 여기 있습니다"라고요. "도구가 그렇게 뱉었습니다"로 막히는 것과, 근거를 펼쳐 보이며 다음 논의(언제까지 무엇을 고칠까)로 넘어가는 것은 완전히 다릅니다. 근거가 추적되는 보고서는 회의 시간을 줄이고, 담당자의 방어 부담도 줄입니다. 결과를 읽을 때 "이 숫자가 어디서 왔는지 끝까지 따라갈 수 있는가"를 확인해두면, 보고 자리에서 훨씬 든든합니다.

다음 점검 주기를 정한다

마지막으로, "다음엔 언제 다시 볼까"를 정해두면 좋습니다. 콘텐츠가 자주 바뀌면 자주, 안정적이면 분기에 한 번. 한 번 보고 잊어버리는 게 아니라 주기로 만들면, 점검이 "사건"이 아니라 "습관"이 됩니다. 그게 수요일에서 강조한 "지금의 사이트를 계속 따라가기"입니다. 주기를 정할 때는 "완벽한 주기"를 고민하기보다 일단 아무 주기라도 정해두는 게 낫습니다. 분기에 한 번이든 반기에 한 번이든, 정해두면 최소한 그 간격으로는 사이트를 보게 되니까요. 정해두지 않으면 "언젠가 봐야지"가 결국 안 보는 걸로 끝납니다. 캘린더에 한 줄 적어두는 것만으로도 점검이 습관의 궤도에 오릅니다.

긴 위반 목록을 우선순위·빈도로 좁혀 "오늘의 다섯 개"로 만들고, 다음 점검에서 줄어드는 추이를 보여주는 결과 활용 흐름 도식. 결과를 한 번 보고 끝내지 않고 기록·비교로 이어가는 구조 (Gemini 1:1)

본론 5 — 결과 읽을 때 흔한 실수 세 가지

마지막으로, 결과를 읽다가 자주 하는 실수 세 개를 짚고 가겠습니다. 이거 알아두면 헛다리를 덜 짚습니다.

실수 ① 숫자 하나에 일희일비

준수율 숫자가 떴다고 그것만 보고 안심하거나 좌절하는 것입니다. 앞에서 말씀드렸듯 평균은 약한 데를 가립니다. "전체 75네, 괜찮네" 하고 덮으면, 그 안에 숨은 접근성 40을 못 봅니다. 숫자는 들여다볼 곳을 정하는 신호이지, 결론이 아닙니다. 항상 분포와 약한 영역을 같이 봐야 합니다.

실수 ② 위반 '개수'로 사이트를 평가

"A 사이트는 위반 50건, B 사이트는 200건이니 A가 낫다"는 식의 비교입니다. 그런데 위반 개수는 페이지 수, 사이트 규모, 기능 복잡도에 따라 달라집니다. 페이지가 10배 많으면 위반도 많이 나오는 게 당연합니다. 개수의 절대값보다, 심각도 분포(최상위 등급이 몇 개냐)와 같은 사이트의 시점 비교(지난번 대비)가 훨씬 의미 있습니다. 개수는 겁주기 좋은 숫자일 뿐, 그 자체로 좋고 나쁨을 가르진 않습니다.

실수 ③ N/A를 '미통과'로 오해

결과를 보면 "해당 없음(N/A)"이 꽤 나옵니다. 그 페이지에 그 요소가 없어서 판정 대상이 아닌 것들입니다. 이걸 "미통과"나 "문제"로 오해하면, 멀쩡한 걸 문제로 세는 셈이 됩니다. N/A는 잘못이 아니라 "해당 사항 없음"입니다. 다만 주의할 게, N/A가 너무 많으면 "실제로 판정된 게 적다"는 뜻이라, 분석이 그 페이지를 충분히 못 봤을 수도 있습니다. 그래서 N/A는 "문제"는 아니지만 "얼마나 실제로 봤나"의 참고 지표는 됩니다. 이 N/A를 어떻게 줄이고 채우는지가 8개월차(LLM 분석)의 핵심 주제입니다.

실수 ④ 상단 점수와 세부 항목이 다르면 그냥 넘어가기

하나만 더 보태겠습니다. 결과를 보다가 "상단엔 디자인 85%라고 떠 있는데, 세부 항목을 더해보니 왠지 그것보다 낮은 것 같다" 싶은 경우가 있습니다. 이럴 때 "그러려니" 하고 넘어가지 마시길 바랍니다. 상단에 크게 뜨는 점수와 그 아래 세부 항목의 점수는 반드시 맞아떨어져야 합니다. 상단과 하단이 어긋나면, 그 보고서는 신뢰를 잃습니다. 기관장이 "이 점수 근거가 뭐냐"고 물었을 때 세부와 안 맞으면 설명이 막히니까요. 좋은 분석 도구라면 모든 숫자가 한 곳에서 계산돼 모든 화면으로 흐르도록 설계돼 있어야 합니다. 보이는 모든 숫자가 같은 출처에서 나온다는 뜻입니다. 이 상단·하단 일치는 사소해 보이지만, "이 결과를 믿어도 되나"를 가르는 지점입니다. 만약 어긋나는 도구라면, 그 점수 자체를 의심해야 합니다.

이 네 가지만 피해도 결과를 훨씬 차분하게 읽게 됩니다. 숫자에 휘둘리지 말고, 개수에 겁먹지 말고, N/A를 오해하지 말고, 상단·하단이 맞는지 한 번 확인할 것.

이 네 가지 실수에는 공통점이 있습니다. 전부 "숫자를 액면 그대로 받아들여서" 생기는 실수라는 점입니다. 준수율 70을 그냥 "70점"으로, 위반 200건을 그냥 "200개 잘못"으로, N/A를 그냥 "미통과"로 받아들이면 다 헛다리를 짚습니다. 숫자는 늘 맥락과 함께 읽어야 합니다. 이 준수율이 어떤 분포에서 나왔는지, 이 위반 개수가 몇 페이지에서 나온 건지, 이 N/A가 왜 N/A인지. 맥락을 함께 보면 같은 숫자도 완전히 다르게 읽힙니다. 좋은 분석 결과는 이 맥락을 함께 제공하고, 좋은 독자는 그 맥락을 함께 봅니다. 숫자만 떼어 보는 습관이 결과 읽기의 가장 흔한 함정입니다.

본론 6 — 영역이 많은데, 다 봐야 하나

스무 개가 넘는 영역을 앞에서 쭉 소개하니 "이걸 다 봐야 하나" 싶어 부담스러우실 수 있습니다. 그래서 이 질문에 정면으로 답하고 넘어가겠습니다. 결론부터 말씀드리면, 다 보실 필요 없습니다. 오히려 상황에 따라 골라 보는 게 맞습니다.

처음 보는 사이트라면

한 번도 점검 안 한 사이트를 처음 넣어봤다면, 먼저 요약(본론 1)에서 전체 그림을 잡고, 준수율이 유독 낮은 두세 영역만 깊게 보세요. 나머지는 나중에 봐도 됩니다. 처음부터 스무 개를 다 정독하면 지쳐서 아무것도 못 합니다. "제일 약한 데부터"가 원칙입니다.

특정 민원·문제가 있다면

"모바일에서 안 보인다"는 민원이 있으면 반응형 영역을, "글씨가 안 읽힌다"는 지적이 있으면 접근성 영역을, "검색에 안 나온다"는 문제가 있으면 SEO 영역을 바로 펼치면 됩니다. 문제가 명확하면 관련 영역으로 직행하는 게 가장 빠릅니다. 스무 개가 넘는 영역은 이럴 때 "필요한 곳으로 바로 갈 수 있는 목차" 역할을 합니다. 민원이 들어왔을 때 "우리 사이트 어디가 문제지?" 하고 막막해하는 대신, 민원 내용에 맞는 영역을 딱 펼쳐서 "여기, 이 위반이 원인이네요"라고 근거까지 짚어낼 수 있습니다. 민원 대응이 추측이 아니라 근거 기반이 되는 것이죠. 이렇게 필요할 때 필요한 영역으로 바로 갈 수 있으니, 영역이 많은 게 오히려 강점이 됩니다.

검수·발주 상황이라면

새로 만든 사이트를 검수하는 상황이라면, 디자인 스타일·컴포넌트·기본 패턴처럼 "규격을 지켰나"를 보는 영역과, 접근성·반응형처럼 "사용자가 실제로 쓸 수 있나"를 보는 영역을 함께 챙기는 게 좋습니다. 그리고 종합·임원 요약을 검수 근거 문서로 삼으면, 개발사와의 소통이 수월해집니다. "이 항목들이 기준 미달이니 보완해주세요"라고 근거를 손에 쥐고 말할 수 있으니까요.

보고·의사결정 상황이라면

윗선에 보고하거나 예산을 정해야 하는 상황이라면, 세부 규칙 판정보다 종합·요약 영역과 위험도·비용 관련 심화 영역을 보는 게 맞습니다. "현황이 이렇고, 이걸 고치는 데 이만큼 들고, 안 고치면 이런 위험이 있다"를 잡을 때 필요한 영역들입니다.

정기 점검이라면

이미 한 번 봤고 주기적으로 관리하는 상황이라면, 매번 스무 개를 다 정독할 필요가 더욱 없습니다. 이번엔 지난번과 무엇이 달라졌는지, 그 변화만 따라가면 됩니다. 준수율이 오른 영역, 내린 영역, 위반이 새로 생긴 곳. 성과 대시보드 같은 변화 추적 영역이 이 비교를 대신 해주니, 담당자는 "달라진 부분"에만 집중하면 됩니다. 매번 처음부터 다 보는 게 아니라, 흐름에서 튀는 지점만 보는 것이죠. 정기 점검의 효율은 여기서 나옵니다.

정리하면, 영역이 많다는 건 부담이 아니라 선택지입니다. 넓게 보되, 지금 내 상황에 필요한 곳만 깊게. 그 판단의 출발점이 늘 요약(본론 1)이라는 것만 기억하시면 됩니다. 요약에서 약한 데를 확인하고, 그 영역으로 가는 것. 이 동선만 몸에 익으면, 스무 개가 넘는 영역도 막막하지 않습니다. 지도를 손에 쥔 여행자는 낯선 도시도 헤매지 않는 것과 같습니다. 영역이 많아도, 읽는 순서라는 지도만 있으면 길을 잃지 않습니다.

그래서 ViewCheck는

지금까지 설명드린 흐름 — 요약 먼저, 약한 영역으로, 위반은 우선순위 순으로, 그리고 기록·비교 — 이게 그대로 ViewCheck URL 분석 결과를 읽는 순서입니다. krds.viewcheck.co.kr에서 분석을 돌리면 상단에 요약, 그 아래 영역별 결과, 위반 목록엔 우선순위와 위치, 그리고 종합·판단 영역에서 "그래서 무엇부터"까지 이어집니다.

오늘 이야기한 게 특별한 비법은 아닙니다. 그냥 "큰 것부터, 약한 것부터, 급한 것부터" 보는 것입니다. 어찌 보면 상식에 가깝습니다. 다만 결과가 많으면 그 상식조차 흔들리기 쉬워서, 순서를 미리 정해두는 게 도움이 됩니다. 다만 그렇게 볼 수 있으려면 결과가 한곳에 정리돼 있고, 같은 기준으로 나오고, 우선순위가 매겨져 있어야 합니다. URL 분석이 그렇게 결과를 내주니까, 사람은 읽고 판단하는 데 집중하면 됩니다. 단순 정리를 기계에 넘기고 판단을 사람이 하는, 이 시리즈 내내 말씀드린 그 구조입니다.

그리고 솔직히, 이 "읽는 법"은 어떤 도구를 쓰든 통합니다. 결과 화면 구성이 좀 달라도, "요약 먼저 → 약한 영역 → 위반은 심각도·빈도·위치·개선 순 → 기록해서 비교"라는 골격은 똑같습니다. 그러니 오늘 글도 ViewCheck 사용설명서라기보다, 웹 진단 결과를 읽는 일반적인 요령으로 가져가시면 됩니다. ViewCheck는 그 요령대로 읽기 좋게 결과를 정리해둔 것뿐이고, 그게 맞는지 한번 직접 넣어보시면 제일 빠릅니다.

🔐 특허로 지키는 부분

오늘 본 "긴 분석 결과를 같은 기준으로 정리하고, 위반을 위험도·빈도로 묶어 우선순위와 개선 동선으로 바꾸는 방법"은 ViewCheck가 출원한 특허 중 위반 위험도 등급화 및 개선 우선순위 산정, 그리고 시점 비교(정기 추적) 주제와 맞닿아 있습니다. 결과를 단순히 나열하는 건 누구나 합니다. 차별점은, 흩어진 판정을 한 기준으로 묶어 "오늘 고칠 다섯 개"와 "지난번 대비 변화"라는 행동 가능한 형태로 정리하는 절차를 권리로 정리해 둔 데 있습니다.

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

마무리

오늘로 1개월차 두 번째 주가 끝났습니다. URL 분석이 무엇인지(월), 왜 운영본을 봐야 하는지(수), 결과를 어떻게 읽는지(금)를 한 바퀴 돌았습니다. 결과 읽는 순서를 한 줄로 줄이면 이렇습니다. 요약으로 약한 데를 찾고, 그 영역을 보고, 위반은 우선순위·빈도·위치·개선 순으로, 그리고 기록해서 다음과 비교합니다.

다음 주부터는 두 번째 시점, Figma 분석으로 넘어갑니다. "만들기 전에 잡는다"는 게 무슨 뜻인지, 운영 시점과 어떻게 다른지를 풀겠습니다. 오늘까지 세 편으로 운영 시점(URL 분석)의 밑그림 — 무엇을 보는지, 왜 운영본이어야 하는지, 결과를 어떻게 읽는지 — 을 한 바퀴 돌았으니, 이제 시점을 바꿔 "만들기 전"으로 거슬러 올라가는 셈입니다. 그리고 다음 달부터는 오늘 지도만 그린 URL 분석의 각 영역을 하나씩 깊게 팝니다. 접근성은 접근성대로, 성능은 성능대로, 디자인 스타일은 디자인 스타일대로. 오늘은 숲을 봤으니, 다음 달엔 나무 하나하나로 들어가는 셈입니다.

오늘 딱 하나만 가져가신다면 이 순서면 좋겠습니다. 요약으로 약한 데를 찾고 → 그 영역을 펼쳐 보고 → 위반은 우선순위·빈도·위치·개선 순으로 → 기록해서 다음과 비교합니다. 스무 개가 넘는 영역이 쏟아져도, 이 한 줄만 손에 쥐고 있으면 길을 잃지 않습니다.

결과를 잘 읽는 건 생각보다 큰 차이를 만듭니다. 같은 분석 결과를 받아도, 길을 잃는 사람은 목록을 덮고, 순서를 아는 사람은 "이번엔 이 다섯 개"를 들고 나갑니다. 오늘 그린 지도가 그 차이를 줄여드리면 좋겠습니다. 이번 주도 끝까지 읽어주셔서 고맙습니다. 다음 주, Figma 분석으로 만나뵙겠습니다.

krds.viewcheck.co.kr