결정을 먼저 정하고 도구를 선택하세요
무엇을 실행하기 전에 위험에 처한 페이지, 사용자 집단, 그리고 중요한 작업을 이름으로 정하세요: 모바일 상품 페이지, 결제, 리드 폼 등. 그런 다음 증거 유형을 선택하세요. 랩 데이터(lab data)는 반복 가능한 디버깅을 위한 통제된 테스트입니다. 필드 데이터(field data)는 우선순위 결정을 위한 실제 사용자 경험의 집계입니다. 브라우저 트레이스는 로컬 런타임 작업을 설명하는 데 도움이 됩니다. 이들은 상호 보완적이며 서로 대체 불가능합니다.
점수에 도달하는 방법이 아니라 방문자가 한 가지 중요한 작업을 완료하지 못하게 하는 것이 무엇인지 물어보세요.
하나의 감사, 사용 가능한 필드 데이터, 하나의 진단 도구를 먼저 사용한 다음 추가 제품을 고려하세요.
결과는 테스트한 URL, 조건 또는 표본에 적용되며 모든 방문자에 대한 최종 판결이 아닙니다.
반복 가능한 페이지 로드 감사에는 Lighthouse와 PageSpeed Insights를 사용하세요
Lighthouse는 Chrome DevTools, 커맨드라인 또는 지속적 통합에서 실행되는 오픈소스 자동 감사 도구입니다. 성능, 접근성, SEO 등 여러 항목을 감사합니다. PageSpeed Insights는 URL에 대해 Lighthouse 진단을 실행하고 가능한 경우 실제 사용자 데이터를 제시합니다. 대표 페이지의 기준선을 잡고, 실패한 감사를 조사하고, 정의된 변경 후 통제된 재테스트를 비교하는 데 둘 중 하나를 사용하세요.
테스트 설정에서 감사된 페이지가 어떻게 동작했는지와 조사할 가치가 있는 감사 항목을 알 수 있습니다.
좋은 Lighthouse 점수가 실제 사용자의 경험이 좋다는 것을 반드시 의미하지는 않습니다. Google은 랩 데이터와 필드 데이터가 다를 수 있다고 문서화하고 있습니다.
변경 후 동일한 페이지와 설정으로 재테스트하세요; 일회성 관문으로 사용하지 마십시오.
사용자가 실제로 겪은 경험을 우선순위로 두려면 필드 데이터를 사용하세요
PageSpeed Insights의 필드 데이터는 Chrome User Experience Report에서 가져오며 직전 28일 기간을 커버합니다. Largest Contentful Paint(LCP), Interaction to Next Paint(INP), Cumulative Layout Shift(CLS) 등을 포함한 측정값을 보고합니다. Search Console의 Core Web Vitals 보고서는 하나의 URL이 아니라 페이지 그룹이 필요할 때 유용합니다. 필드 데이터를 사용해 어떤 템플릿, 기기 그룹, 또는 이슈에 먼저 노력을 들일지 결정하세요.
결과가 페이지 수준인지 도메인(origin) 수준인지, 해당 URL에 충분한 데이터가 있었는지 확인하세요.
필드 데이터는 과거 데이터이고 개인정보 보호를 위해 집계되므로 릴리스의 효과를 즉시 확인할 수는 없습니다.
Google은 LCP를 2.5초 이내, INP를 200밀리초 미만, CLS를 0.1 미만으로 권장합니다.
감사 결과에 설명이 필요하면 Chrome DevTools를 사용하세요
감사나 필드 패턴이 느린 로딩, 지연된 상호작용, 또는 시각적 이동을 가리킬 때 Chrome DevTools의 Performance 탭에서 여정을 녹화하세요. 이 도구는 CPU 프로파일을 기록하고 로컬 LCP, CLS 및 상호작용 후 INP를 보여줄 수 있습니다. 타임라인은 개발자가 권장 목록에서 추측하는 대신 브라우저 작업을 조사하도록 도와줍니다.
영향을 받는 대상과 합리적으로 유사한 뷰포트, CPU, 네트워크 조건을 사용하세요.
트레이스는 기록된 기기, 연결, 캐시 상태 및 여정을 반영합니다. 일반화하기 전에 관련 여정을 재현하세요.
의심되는 원인, 변경사항, 예상 방문자 효과를 기록하세요.
자동화된 접근성 검사와 숙련된 사람의 평가를 병행하세요
자동화된 접근성 평가 도구를 사용해 기계로 검사 가능한 문제를 조기에 반복적으로 찾아내세요. W3C WAI는 도구 목록과 선택 가이드를 유지하지만 단일 도구만으로는 사이트가 접근성 표준을 충족하는지 판단할 수 없다고 명시합니다. 자동화 결과를 검토 대기열로 만들고 대표 페이지, 키보드 작동, 포커스 동작, 오류 처리, 콘텐츠를 자격을 갖춘 평가자가 검사하도록 하세요.
반복 가능한 결함을 빠르게 발견하고 예방하는 데 유리합니다.
전체 접근성 적합성을 판정하거나 인간 평가를 대체할 수 없습니다.
자동화 결과를 법적 준수로 홍보하지 마세요. 중요할 경우 자격 있는 접근성 및 법률 검토를 받으세요.
승인 내에서 집중된 보안 도구를 신중하게 사용하세요
Mozilla의 HTTP Observatory는 HTTP 헤더 및 기타 핵심 보안 구성 항목을 검사해 공개-facing 헤더 위생(public-facing header hygiene)에 대한 출발점을 제공합니다. 제안된 헤더 변경은 스크립트, 임베디드 서비스, 사용자 흐름에 영향을 줄 수 있으므로 운영 환경 외부에서 검증하세요. HTTP Observatory는 보안의 한 조각을 평가할 뿐 모든 애플리케이션 리스크를 다루지 않습니다.
OWASP ZAP은 트래픽을 수동으로 스캔하고 애플리케이션을 적극적으로 테스트할 수 있지만, 권한이 있는 시스템만 테스트하세요.
ZAP은 적극적 스캔이 실제 공격이며 대상에 위험을 초래할 수 있다고 경고합니다. 수동 스캔은 인증되었거나 방문되지 않은 영역을 놓칠 수 있습니다.
결제, 인증, 민감한 데이터 또는 중요한 발견사항이 있을 경우 자격 있는 보안 전문가를 참여시키세요.
도구 출력을 점수 쫓기가 아닌 SIU 복구(SIU remediation)로 전환하세요
지속 가능한 루프를 사용하세요: 기준선을 캡처하고, 하나의 그럴듯한 원인을 식별하며, 가장 작은 안전한 변경을 수행하고, 동일한 경로를 재테스트한 다음 충분한 시간 후 필드 추세를 관찰하세요. 방문자 과업을 중심에 두세요. 차단 자원을 줄이는 것은 구매, 로그인, 접근성, 동의, 분석 동작을 깨뜨리지 않고 유용한 경험을 개선할 때만 가치가 있습니다.
필드 영향, 재현 가능한 트레이스, 또는 명확한 사용자 영향 결함으로 뒷받침되는 변경을 선호하세요.
스테이징, 소유자, 수용 기준, 롤백 계획을 사용하세요. SIU는 피할 수 있는 경험 저하를 방지합니다.
변경 기록에는 점수뿐 아니라 측정항목, 테스트 조건, 완료된 방문자 과업을 포함하세요.