1. 결과와 적용 범위 정의
감사 도구를 켜기 전에 담당자 한 명을 지명하고 결과를 문서화하세요. 대상 사용자, 여정, 페이지 또는 라우트, 시간 창, 그리고 작업이 지원해야 하는 의사결정을 명시합니다. 유용한 목표는 사이트를 ‘더 빠르게’ 만드는 모호한 바람이 아니라 모바일 제품→장바구니 흐름 완료 같은 과업을 서술합니다.
비협상 항목을 나열하세요: 작동하는 구매 또는 문의 흐름, 계정 접근, 동의(consent) 동작, 접근성, 검색 크롤러 노출, 승인된 콘텐츠. 합성 점수 상승은 폼이 실패하거나 콘텐츠가 검색에서 숨겨지거나 키보드 사용이 더 어려워지면 승리로 볼 수 없습니다.
시작 페이지, 사용자 행동, 성공적인 종료 상태를 한 문장으로 작성하세요.
성공적인 제출 유지나 새로운 접근성 차단 요소가 생기지 않도록 하는 것처럼, 악화되어서는 안 될 결과를 선택하세요.
2. 비교 가능한 기준선 캡처
코드, 콘텐츠, 구성 또는 태그를 변경하기 전에 URL 목록, 날짜, 테스트 조건, 릴리스 버전, 리포트나 트레이스, 수동 작업 결과를 저장하세요. web.dev는 변경 전 사이트 상태를 기록하고 여러 페이지 유형을 테스트할 것을 권합니다; 싱글 페이지 애플리케이션(SPA)의 경우 첫 로드만이 아니라 라우트, 컴포넌트, 흐름을 포함하세요.
한 가지 렌즈만 사용하지 마세요. Lighthouse는 자동 성능, 접근성, 검색(SEO) 및 기타 감사를 제공합니다. 저장소를 비우거나 깨끗한 프로필로 첫 로드를 테스트한 다음 목표 작업을 완료하세요. 실사용(필드) 데이터가 충분하면 중요한 페이지 그룹과 기기 클래스를 비교하세요. Core Web Vitals는 필드 측정치입니다: LCP는 로딩, INP는 상호작용성, CLS는 시각적 안정성을 다룹니다.
필드 데이터는 실제 방문을 반영하고 랩 테스트는 문제 재현을 쉽게 만듭니다. 가능하면 둘 다 사용하세요.
시뮬레이션된 로드는 사용자 입력이 없어 INP를 측정할 수 없습니다; 랩의 Total Blocking Time은 대체 지표일 뿐입니다.
3. 여정을 끝에서 끝까지 감사
발견 사항을 여정과 메커니즘별로 그룹화하세요. 페이지 자산과 써드파티의 요청 크기, 타이밍, 의존성을 검토합니다. 모바일 뷰포트, 키보드 경로, 가시적 포커스, 레이블, 오류, 제목 구조, 링크 목적, 확대/축소, 이미지·스크립트·동의 기반 서비스가 느리거나 사용할 수 없을 때의 동작을 점검하세요.
자동 접근성 출력은 분류(triage)용으로 취급하세요. W3C는 단일 도구만으로는 사이트가 접근성 표준을 준수하는지 판단할 수 없다고 말하며, 숙련된 사람의 평가가 필요합니다. 검색의 경우 중요한 렌더된 리소스가 사용자뿐 아니라 크롤러에도 남아 있는지 확인하세요. 변경이 영향을 주는 경우 리다이렉트, canonical, 내부 링크, robots 지시자, 사이트맵, 구조화된 데이터 등을 포함하세요.
태그 관리자, 분석, 채팅, 결제, 폰트, CDN, API, 동의 도구 등 작업이 의존하는 항목을 나열하세요.
결제, 인증, 사용자 데이터, 헤더 또는 보안 제어 관련 변경은 자격 있는 보안 및 결제 검토를 받으세요.
4. 우선순위 백로그 작성
각 항목에 대해 간단한 가설을 작성하세요. 즉, 이 페이지나 흐름에서 이 메커니즘을 변경해야 하는 이유와 증거가 이 문제의 발생을 뒷받침한다는 점을 밝히고, 기대 결과를 측정하며, 명시된 가드레일을 보호하세요. 관찰과 진단은 구분하세요. 저장된 트레이스는 큰 이미지가 콘텐츠를 지연시킨다는 사실을 보여 줄 수 있지만, 해결책에는 여전히 디자인과 콘텐츠 검토가 필요할 수 있습니다.
항목을 영향(Impact), 신뢰도(Confidence), 노력(Effort), 위험(Risk)으로 순위화하세요. 영향은 영향을 받는 우선 여정입니다. 신뢰도는 랩, 필드, 수동 증거가 일치하는지 여부입니다. 노력에는 코드뿐 아니라 조정 비용도 포함됩니다. 위험에는 의존성, 보안, 릴리스 복잡성, 되돌릴 수 있는지 여부가 포함됩니다. 중요한 기능적·보안 노출은 이 모델보다 우선할 수 있으며 전문적 분류가 필요합니다.
소유자, 증거 링크, 가설, 페이지, 측정치, 가드레일, 의존성, 릴리스 방법, 롤백 트리거를 유지하세요.
안전이 요구하지 않는 한 관련 없는 리팩터를 측정된 변경에 묶지 마세요.
5. 안전하게 릴리스하고 돌아갈 방법 확보
배포 전에 변경 사항, 승인자, 릴리스 창, 검증자, 성공 조건, 롤백 트리거 및 복구 방법을 기록하세요. 가능하면 콘텐츠, 권한, 통합, 리다이렉트, 동의 선택 및 흔한 실패 경로를 포함한 대표적인 비프로덕션 환경에서 테스트하세요. 프로덕션은 데이터, 캐시, 구성 및 써드파티 때문에 여전히 다를 수 있습니다.
플랫폼이 지원하면 소규모 점진 배포, 기능 플래그, 버전된 자산 또는 되돌릴 수 있는 구성 방식을 사용하세요. 비교 결과를 내기 전에 캐시와 CDN 동작을 확인하세요. OWASP는 구성 및 배포 관리를 보안 테스트 영역으로 다루므로 헤더, 권한, 파일 노출, 도메인 또는 클라우드 설정은 가벼운 최적화 변경으로 취급해서는 안 됩니다.
실패한 체크아웃, 깨진 내비게이션, 예상치 못한 클라이언트 오류 또는 접근성 회귀 같은 관찰 가능한 트리거를 정의하세요.
롤백 계획은 복구 시간을 줄일 수 있지만 모든 위험을 제거하지는 못합니다; 복구 방법을 신뢰하기 전에 복원을 테스트하세요.
6. 검증, 결정, 반복
릴리스 후 기준선의 기능 검사와 비교 가능한 랩 테스트를 반복하세요. 관련 기기, 브라우저, 상태 및 통합을 다시 확인합니다. 동일 조건으로 비교하세요: URL, 캐시 상태, 기기 클래스, 가능한 경우 지역 및 측정 창. 대상 지표뿐 아니라 가드레일도 확인하세요.
증거가 성숙할 시간을 주세요. Google은 검색 변경이 반영되는 데 몇 시간에서 몇 달이 걸릴 수 있으며, 도움 여부를 판단하려면 몇 주를 기다릴 것을 권합니다. 실사용 성능 데이터는 즉각적인 릴리스 판정이 아니라 집계된 증거입니다. 유지, 수정, 조사, 롤백 여부를 기록한 다음 템플릿, 플랫폼, 태그, 콘텐츠 또는 의존성에 의미 있는 변경이 있은 뒤 기준선을 다시 설정하세요.
예상된 여정 결과가 개선되고 합의된 가드레일이 유지될 때.
필드나 작업 증거가 랩 결과와 충돌하거나 중요한 가드레일이 악화될 때 조치하세요.