거대한 스캔보다 핵심 여정부터 시작하세요
우선 5~10개의 URL을 선택하고 각 URL에 대한 기대 결과를 정의하세요: 확인 페이지, 영수증, CRM 레코드 또는 외부 제공자 핸드오프 등. 수익 창출, 신뢰 형성, 지원 수요 생성 또는 법적 의무를 만드는 공개 페이지와 동작을 포함하세요. 로그인되지 않은 창과 휴대폰에서 방문자 관점으로 테스트합니다.
중요 단계가 제3자 소유라면 핸드오프와 지원 연락처를 도식화하세요. 전환 자체는 테스트할 수 있지만 해당 제공자를 인증할 수는 없습니다. 발견사항을 차단(blocker), 실질적 열화(material degradation), 개선(improvement)으로 분류해 외형적 작업이 깨진 여정을 가리지 않도록 하세요.
수익, 신뢰, 지원 수요 또는 법적 의무를 생성하는 경로를 포함하세요.
중대한 발견사항에는 이름이 지정된 담당자와 목표 기한이 필요합니다.
겉모습뿐 아니라 접근성(사용 가능성)도 확인하세요
접근성은 다양한 입력 방식과 보조 기술을 사용하는 사람이 사이트를 인지하고 조작할 수 있음을 의미합니다. 선택한 페이지에서 Tab 키로 내비게이션, 메뉴, 컨트롤, 폼을 순회하세요. 시각적 키보드 포커스, 필수 컨트롤의 마우스 없이 조작 가능성, 주요 콘텐츠로 가는 경로를 확인하세요. W3C의 Easy Checks는 키보드 포커스와 스킵링크(skip link)를 첫 단계로 유용하다고 제안합니다.
의미 있는 이미지 텍스트(대체텍스트), 페이지 타이틀, 제목 구조, 명암 대비, 확대(줌) 동작, 필요 시 미디어 대체물, 폼 레이블, 필수 필드, 이해 가능한 오류를 확인하세요. 민감하지 않은 테스트 제출을 하나 실행하세요. 이 검토는 준수 감사가 아니며 W3C는 빠른 검사가 통과되어도 여전히 중요한 접근성 장벽이 남아 있을 수 있다고 경고합니다. 위험이 크거나 재설계 또는 알려진 문제에는 자격을 갖춘 평가를 사용하세요.
레이블, 지침, 오류 처리 및 실제 확인 경로를 테스트하세요.
대체 텍스트는 이미지의 목적을 전달해야 하고, 제목은 페이지를 조직해야 합니다.
검색 순위를 약속하지 말고 찾기 쉬움을 검토하세요
SEO는 검색엔진이 콘텐츠를 이해하도록 돕고, 검색 결과에서 방문 여부를 결정하는 데 사람을 돕습니다. 우선순위 페이지마다 제목, 주요 제목(H1), 도입 문구, URL, 내부 링크를 처음 보는 사람의 관점으로 읽어보세요. 그 요소들은 목적을 분명히 나타내고 유용한 다음 단계를 안내해야 합니다. Google은 설명적인 URL, 유용한 콘텐츠, 설명적인 링크 텍스트를 권장합니다.
Google Search Console을 사용한다면, 중대한 릴리스 후 주요 URL을 검사하세요. Google은 URL Inspection이 크롤러가 페이지를 어떻게 보는지와 중요한 리소스에 접근할 수 있는지 확인하는 데 도움을 줄 수 있다고 말합니다. 우발적인 차단, 깨진 내부 링크, 불분명한 경로를 바로잡고 재크롤 시간을 허용하세요. Google은 색인화나 순위를 보장하지 않습니다.
로그아웃 상태에서 내부 링크를 열어 404 페이지, 루프, 관련 없는 대상지를 기록하세요.
방문자가 체감하는 전달 성능을 관찰하세요
전달은 서버 응답, 이미지, 폰트, 스크립트, 캐시, 서드파티 등을 포함합니다. 우선순위 페이지에서 브라우저 성능 검사를 실행한 다음 실제 휴대폰에서 핵심 작업을 반복하세요. 주요 콘텐츠가 늦게 나타나거나 컨트롤이 느리게 반응하거나 레이아웃이 흔들리거나 실패한 리소스, 작업을 막는 배너가 있는지 기록하세요. 핵심 웹 필수 지표(Core Web Vitals)는 웹.dev의 사용자 경험 프레임워크입니다; 측정은 조사를 집중하는 데 사용하고 여정 테스트를 대체해서는 안 됩니다.
새 태그, 위젯, 임베드, 폰트, 이미지 변경사항은 구현자와 함께 검토하세요. HTTP 캐시는 이전 응답을 재사용합니다. MDN은 Cache-Control이 캐싱 지시를 전달하며 캐시된 응답은 fresh 또는 stale일 수 있다고 설명합니다. 릴리스 후 일반 세션과 새로 고친 세션을 비교한 다음 기술 담당자가 헤더와 CDN 규칙을 검사하게 하세요. 프라이버시와 릴리스 영향 이해 없이 무작정 캐시를 변경하지 마세요.
주요 콘텐츠가 나타나는지, 페이지가 안정적으로 유지되는지, 필수 컨트롤이 반응하는지 기록하세요.
MDN은 쿠키만으로 응답이 자동으로 ‘프라이빗’이 되지는 않는다고 지적합니다; 개인화 캐싱은 기술 담당자에게 검토를 요청하세요.
보안 기본선을 확인하고 결제 변경을 보호하세요
소유자 점검으로 눈에 띄는 격차를 찾을 수 있지만 침투 테스트는 아닙니다. 공개 사이트를 HTTPS로 열고 HTTP를 시도해 보세요. OWASP는 모든 페이지에 대한 TLS 사용을 권장하며 공개 HTTP 트래픽을 HTTPS로 리디렉트하는 것이 일반적인 접근법이라고 설명합니다. 인증서나 혼합 콘텐츠 경고, 예상치 못한 도메인, 콘텐츠를 제공하는 HTTP 페이지(안전한 리디렉트 대신)를 발견하면 에스컬레이션하세요.
게시, 도메인, DNS, 결제, 플러그인, 백업 접근 권한의 현재 소유자를 확인하세요. TLS 구성, 패치, 인증, 서버 구성 및 로그는 자격을 갖춘 보안 전문가나 제공자가 검토해야 합니다. 결제는 제공자가 승인한 테스트 방식이나 안전한 비프로덕션 환경만 사용하세요. 비공식 테스트에 실제 카드 데이터나 자격증명을 사용하지 말고, 화면상 검토로 PCI 준수를 증명할 수 없음을 명심하세요.
인증서 경고, 보안 경고, 예기치 않은 리디렉트는 조사될 때까지 릴리스를 중단시킬 사안으로 처리하세요.
의심스러운 침해, 보안 요구사항, 결제 규정 준수 질문은 자격 있는 검토자에게 전달하세요.
복구를 증명하고 절차를 완료하세요
우선순위 여정을 재구성하는 항목을 나열하세요: 애플리케이션 버전, 데이터베이스, 업로드된 미디어, 구성 위치, DNS·도메인 접근, 통합 설정, 벤더 연락처 등. CISA는 중요 데이터 식별, 웹사이트·운영 데이터베이스 보호, 백업 보안, 전체 및 부분 복구 테스트를 권고합니다. 언제 복원을 테스트했는지, 무엇을 복원했는지, 걸린 시간, 누구에게 권한이 있는지 물어보세요. 가능한 경우 안전한 방식으로 복구 연습을 리허설하세요.
릴리스 전에는 이전 버전, 롤백(역전) 트리거, 승인자, DNS·캐시·데이터베이스 스키마·서드파티 변경 처리 방법을 식별하세요. 백업은 즉각적인 해결책이 아니며 롤백은 외부 데이터나 결제 이벤트를 되돌리지 못할 수 있습니다. 발견사항, 증거, 담당자, 날짜, 재검증 결과의 등록부를 유지하세요.
“백업이 실행된다”는 말보다 범위·날짜·결과·갭을 기록한 증거가 더 강력합니다.
수정 후 관련 환경에서 원래 실패한 경로를 확인하세요.