RSS

웹사이트 공개 전 무료 점검 도구: 속도·보안·접근성·SEO 한 번에 확인하기

웹사이트는 화면과 기능이 완성됐다고 바로 공개할 수 있는 상태가 되는 것은 아닙니다. 실제 사용자가 느끼는 속도, HTTP 보안 헤더, HTTPS 설정, 키보드 접근성, 구조화 데이터, DNS 설정은 서로 다른 문제입니다.

한 서비스의 점수만으로 이 영역을 모두 판단하기는 어렵습니다. 이 글에서는 무료로 시작할 수 있는 공개 검사 도구를 목적별로 나누고, 결과를 어떤 순서로 확인하면 좋은지 정리합니다. 일부 도구의 고급 기능이나 추가 검사 위치는 계정 또는 유료 요금제가 필요할 수 있습니다.

1. 속도와 사용자 경험

PageSpeed Insights

PageSpeed Insights는 모바일과 데스크톱 환경의 성능을 확인할 때 가장 먼저 쓰기 좋은 도구입니다. 실험실 데이터와 실제 사용자 데이터가 함께 표시될 수 있으며, LCP, CLS, INP 같은 핵심 웹 지표를 살펴볼 수 있습니다.

새로 공개한 사이트나 방문자가 적은 사이트는 실제 사용자 데이터가 충분하지 않을 수 있습니다. 이때 표시되는 실험실 결과는 문제를 찾는 단서로 사용하고, 실제 방문자의 체감 속도와 같다고 단정하지 않는 편이 좋습니다.

자세한 기준은 Google의 PageSpeed Insights 안내에서 확인할 수 있습니다.

WebPageTest

WebPageTest는 요청별 워터폴, 화면 변화 과정, 반복 방문 결과를 자세히 확인할 때 유용합니다. 특정 이미지, 글꼴, 외부 스크립트가 초기 화면을 늦추는지처럼 원인을 좁혀야 할 때 PageSpeed Insights보다 세밀한 자료를 제공합니다.

검사 위치, 브라우저, 네트워크 조건이 달라지면 결과도 달라집니다. 주요 방문자와 가까운 조건을 선택하고 같은 조건에서 여러 번 측정해야 비교가 의미 있습니다.

GTmetrix

GTmetrix는 Lighthouse 지표, 워터폴, 화면 변화 과정 등을 요약된 보고서로 확인하기 좋습니다. 문제를 팀이나 고객과 공유할 때는 편리하지만, 무료 계정에서 선택할 수 있는 검사 위치와 기능에는 제한이 있을 수 있습니다.

세 도구의 역할은 조금씩 다릅니다. 전체 상태를 빠르게 볼 때는 PageSpeed Insights, 느린 요청의 원인을 찾을 때는 WebPageTest, 정리된 보고서가 필요할 때는 GTmetrix가 잘 맞습니다.

2. HTTP 보안 헤더

Security Headers와 HTTP Observatory

Security HeadersMozilla HTTP Observatory는 웹사이트가 보내는 HTTP 응답 헤더를 점검합니다.

주로 다음 항목을 확인합니다.

  • Content-Security-Policy(CSP): 허용할 스크립트, 이미지, 프레임 출처 제한
  • Strict-Transport-Security(HSTS): 브라우저가 HTTPS 연결을 유지하도록 안내
  • X-Content-Type-Options: 잘못된 콘텐츠 형식 추측 방지
  • Referrer-Policy: 다른 사이트로 전달되는 참조 정보 범위 제한
  • Permissions-Policy: 카메라, 마이크, 위치 같은 브라우저 기능 사용 범위 제한

CSP나 HSTS는 높은 점수를 받기 위해 그대로 복사해서 적용할 설정이 아닙니다. 현재 사용하는 외부 스크립트와 모든 하위 도메인의 HTTPS 지원 여부를 확인한 뒤 단계적으로 적용해야 합니다.

검사 결과가 A 또는 A+여도 애플리케이션 전체가 안전하다는 뜻은 아닙니다. Mozilla도 HTTP Observatory가 오래된 소프트웨어, SQL 삽입, 취약한 플러그인, 잘못된 비밀번호 저장 같은 문제를 검사하지 않는다고 설명합니다. 범위와 한계는 HTTP Observatory FAQ에서 확인할 수 있습니다.

3. HTTPS, TLS, 인증서

Qualys SSL Labs Server Test는 공개 서버의 TLS 프로토콜, 인증서 체인, 암호화 설정과 알려진 구성 문제를 확인할 때 사용합니다.

HTTP 보안 헤더와 TLS 검사는 서로 대체하지 않습니다. Security Headers에서 높은 등급을 받아도 인증서 체인이나 TLS 설정에 문제가 있을 수 있고, SSL Labs 결과가 좋아도 CSP 같은 응답 헤더가 빠져 있을 수 있습니다.

4. 웹 접근성

WAVE는 대체 텍스트, 폼 레이블, 제목 구조, 대비처럼 자동으로 발견할 수 있는 접근성 문제를 화면 위에 표시합니다. WAVE 자체도 자동 검사가 사람의 판단을 돕는 도구라고 안내합니다.

자동 검사 후에는 다음 항목을 직접 확인하는 것이 좋습니다.

  • 마우스 없이 Tab과 Shift+Tab으로 주요 기능에 도달할 수 있는가
  • 현재 키보드 포커스가 눈에 보이는가
  • 모달을 닫은 뒤 포커스가 자연스러운 위치로 돌아오는가
  • 입력 오류를 색상만으로 알리지 않는가
  • 버튼과 링크의 이름을 문맥 없이도 이해할 수 있는가
  • 화면을 확대해도 내용이나 조작 요소가 가려지지 않는가

접근성은 자동 검사에서 오류가 0건이라고 끝나는 작업이 아닙니다. 키보드와 화면 읽기 도구를 사용한 점검이 함께 필요합니다.

5. 검색 노출과 구조화 데이터

Google Rich Results Test는 공개 페이지의 구조화 데이터가 Google의 확장 검색 결과에 사용될 수 있는지 확인합니다. URL뿐 아니라 코드도 입력할 수 있어 공개 전 마크업을 검토할 때도 쓸 수 있습니다.

이 도구가 통과했다고 검색 노출이 보장되는 것은 아닙니다. 다음 항목은 별도로 확인해야 합니다.

  • 페이지별 title과 description
  • canonical URL
  • robots.txt와 sitemap.xml
  • Open Graph 이미지와 공유 미리보기
  • 검색엔진이 접근할 수 없는 로그인 또는 차단 설정
  • Google Search Console의 색인 상태

6. DNS와 DNSSEC

DNSViz는 DNSSEC 인증 체인과 DNS 조회 경로를 시각화하고 구성 오류를 찾는 데 초점이 맞춰져 있습니다. DNSSEC를 설정했는데 검증이 실패하거나 위임 관계를 확인해야 할 때 특히 유용합니다.

DNSViz 결과만으로 DNS 속도나 전체 가용성을 판단할 수는 없습니다. 네임서버 응답과 레코드 값, 전파 상태는 별도 조회와 함께 확인해야 합니다.

7. 여러 항목을 한 번에 보는 Internet.nl

Internet.nl은 IPv6, DNSSEC, HTTPS, HTTP 보안 설정, RPKI 같은 현대 인터넷 표준 지원 여부를 한 보고서에서 확인합니다. 개별 도구를 돌리기 전에 빠진 영역을 찾거나, 점검을 마친 뒤 전체 상태를 다시 보는 용도로 알맞습니다.

종합 점수도 해석에는 주의가 필요합니다. 서비스가 사용하지 않는 기능, 호스팅 제공자가 관리하는 항목, 단계적으로 적용해야 하는 정책이 섞여 있을 수 있으므로 세부 검사 결과를 함께 봐야 합니다.

공개 전 권장 점검 순서

  1. 대표 URL을 고릅니다. 홈, 주요 랜딩 페이지, 문의 폼, 콘텐츠 페이지처럼 구조가 다른 화면을 포함합니다.
  2. PageSpeed Insights로 전체 상태를 보고 WebPageTest 또는 GTmetrix로 느린 요청의 원인을 좁힙니다.
  3. Security Headers와 HTTP Observatory로 응답 헤더를 확인하고 SSL Labs로 TLS와 인증서를 따로 점검합니다.
  4. WAVE 결과를 수정한 뒤 키보드만으로 주요 흐름을 직접 사용해 봅니다.
  5. Rich Results Test, robots.txt, sitemap.xml, canonical URL을 확인합니다.
  6. DNSViz와 Internet.nl로 DNSSEC와 인터넷 표준 지원 상태를 살펴봅니다.
  7. 수정 후 같은 조건으로 다시 검사하고 검사 날짜, URL, 주요 결과를 기록합니다.

속도 결과는 실행할 때마다 달라질 수 있으므로 한 번의 숫자보다 반복해서 나타나는 문제를 우선해야 합니다. 홈 화면 한 곳만 통과해도 다른 페이지의 이미지, 스크립트, 구조화 데이터 문제는 남을 수 있습니다.

외부 검사 도구를 사용할 때 주의할 점

공개 검사 도구에는 외부에 공개해도 되는 URL만 입력해야 합니다. 관리자 화면, 비공개 검증 주소, 고객 전용 페이지, 인증 정보나 토큰이 쿼리에 포함된 URL은 입력하지 않는 편이 안전합니다. 검사 기록이나 도메인이 공개될 수 있다는 전제로 사용해야 합니다.

또한 점수 자체를 목표로 삼으면 서비스에 필요한 기능을 잘못 제거하거나 과도한 정책을 적용하기 쉽습니다. 결과를 재현하고 실제 사용자 흐름에 미치는 영향을 확인한 뒤 수정 범위를 정해야 합니다.

듀오랩스가 보는 관점

웹사이트 공개 전 점검은 하나의 만점 보고서를 만드는 일이 아닙니다. 속도, 보안, 접근성, 검색 노출, DNS를 서로 다른 도구로 확인하고 자동 검사가 놓치는 부분을 사람이 보완하는 과정입니다.

무료 도구만 잘 조합해도 공개 직전에 놓치기 쉬운 문제를 상당수 발견할 수 있습니다. 중요한 것은 점수보다 검사 범위를 이해하고, 수정 후 같은 조건에서 다시 확인하는 습관입니다.