휴대폰에서 웹사이트 사용성 확인하기

웹사이트가 모바일에서 잘 작동하는지 확인하려면 성능 보고서와 실제 사용자 과제 테스트를 함께 해야 합니다. 로딩이 빨라도 제출 버튼을 누를 수 없는 페이지가 있습니다. 반응형 레이아웃에서도 양식 입력이 사라질 수 있습니다.

Google은 2023년 12월 모바일 친화성 테스트와 API를 종료했습니다. PageSpeed Insights, Lighthouse, 브라우저 기기 에뮬레이션, 실제 휴대폰 점검은 서로 다른 부분을 다룹니다. 어느 하나만으로 사용성, 접근성 또는 좋은 검색 순위를 보장할 수는 없습니다.

중요한 페이지와 행동부터 고르세요

홈페이지, 주요 제품 또는 서비스 페이지, 글 하나를 선택하세요. 다른 도메인으로 이동하더라도 실제 문의, 예약, 구매 과정을 포함합니다. 관련 언어와 여러 상태도 테스트하세요. 동의 배너가 뜨는 첫 방문, 재방문, 메뉴를 연 상태, 양식 오류가 발생한 상태가 해당합니다.

무료 모바일 점검 도구는 예비 검사에 사용할 수 있습니다. 가져온 HTML과 응답 정보에서 viewport 태그 누락, 인라인 고정 너비, 인라인으로 지정된 너무 작은 글자 등의 단서를 찾습니다. 페이지 렌더링, JavaScript 실행, 외부 스타일시트를 통한 레이아웃 계산은 하지 않습니다. HTML 크기는 전체 다운로드 용량이 아니며, 가져오는 데 걸린 시간도 실제 휴대폰의 로딩 시간이 아닙니다. 지적한 문제는 브라우저에서 확인하세요.

PageSpeed의 두 결과를 구분하세요

PageSpeed Insights에 공개 URL을 넣고 모바일을 선택하세요.

필드 데이터는 Chrome UX Report에서 가져온 지난 28일간의 측정입니다. 제목이 ‘이 URL’인지 ‘출처’인지 확인하세요. URL 데이터가 충분하지 않으면 PageSpeed는 프로토콜, 호스트 이름, 포트가 같은 페이지를 묶은 출처 단위 결과를 표시할 수 있습니다. 출처가 통과했다고 특정 페이지가 통과한 것은 아닙니다. 두 수준 모두 데이터가 부족하다면 평가가 없는 것이지 불합격은 아닙니다.

실험실 영역은 모의 조건에서 새로 실행한 Lighthouse 테스트입니다. 느린 리소스나 작업을 막는 스크립트를 조사하는 데 쓰세요. 성능 점수는 필드 평가와 별개입니다. 한 번의 탐색 테스트로 방문자의 INP를 측정할 수는 없습니다. Google 문서에서 차이를 설명합니다.

저장된 2026년 8월 4일 모바일 보고서를 원본 크기로 열기(출처 선택, Core Web Vitals 통과)

저장된 이 예시는 출처 단위 필드 결과입니다. LCP는 2.4초, INP는 112밀리초, CLS는 0이며 Lighthouse 성능 점수는 없습니다. 보고서 범위를 읽는 법을 보여 주는 자료로, 현재 홈페이지를 다시 측정한 결과가 아닙니다.

Core Web Vitals 기준의 의미

아래 분류는 해당 필드 측정의 평균이 아닌 75번째 백분위수를 사용합니다.

세 지표를 모두 포함한 평가를 통과하려면 모두 좋아야 합니다. 다만 INP 데이터가 부족해도 LCP와 CLS가 좋으면 PageSpeed는 통과로 평가할 수 있습니다. LCP 또는 CLS 데이터가 부족하면 평가할 수 없습니다. 이 PageSpeed 평가 규칙이 실제 상호작용 테스트를 대신하지는 않습니다.

Search Console은 범위를 맞춰 비교하세요

Search Console에서 Core Web Vitals의 모바일 보고서를 여세요. 영향을 받은 그룹, 가장 나쁜 지표, 예시 URL을 확인합니다. Google은 경험이 비슷한 페이지를 묶지만, 그 그룹이 사이트 템플릿과 반드시 일치하지는 않습니다. 공용 구성 요소가 원인이라고 판단하기 전에 문제를 재현하세요.

필드 데이터끼리 비교해도 PageSpeed와 Search Console은 다를 수 있습니다. URL, 출처 또는 그룹, 기기, 수집 기간, URL 처리 방식을 확인하세요. Search Console은 URL 매개변수를 구분하지만 PageSpeed 필드 데이터는 매개변수 없이 집계합니다. 모든 차이를 ‘실험실 대 실제 사용자’로 설명하면 부정확합니다. 보고서 문서에 구분이 설명되어 있습니다.

수정 사항을 배포하면 같은 브라우저 단계와 실험실 설정으로 즉시 다시 확인하세요. 필드 결과는 최근 28일 집계에 새로운 방문이 포함되면서 바뀝니다. ‘추적 시작’은 28일 검증을 시작하며, 크롤링이나 재색인을 강제하지 않습니다. 표시된 데이터는 28일이 되기 전에도 바뀔 수 있지만, 검증에는 여전히 관찰 기간과 충분한 데이터가 필요합니다.

Lighthouse 측정 조건을 기록하세요

Chrome에서 페이지와 DevTools를 열고 Lighthouse에서 모바일을 선택한 뒤 테스트하세요. 로컬 Lighthouse는 공개 PageSpeed 요청이 접근하지 못하는 로그인 페이지도 확인할 수 있습니다. Lighthouse 문서에서 실행 방법을 볼 수 있습니다.

보고서, 날짜, URL, Lighthouse 버전, 기기 프로필, 속도 제한 설정, 테스트한 페이지 버전을 저장하세요. 변경 전후에는 조건을 맞추고, 예상 밖의 결과는 반복 측정합니다. 컴퓨터, 브라우저, 동의 상태, 설정이 달라지면 측정도 달라질 수 있습니다. DevTools에서 CPU를 수동으로 느리게 해도 PageSpeed의 시뮬레이션과 같아지는 것은 아닙니다.

PageSpeed API로 실험실 테스트 자동화하기

아래 Bash 명령은 모바일 성능, 접근성, SEO 진단을 요청합니다. 예시 URL을 공개 페이지로 바꾸세요.

curl --get \
  'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
  --data-urlencode 'url=https://example.com/' \
  --data-urlencode 'strategy=mobile' \
  --data-urlencode 'category=performance' \
  --data-urlencode 'category=accessibility' \
  --data-urlencode 'category=seo'

Windows에서는 이 여러 줄 구문을 Bash 터미널에서 사용하세요. 시작 가이드는 접근 방법을 설명하고, 잦은 자동 요청에는 키를 권장합니다. 일괄 테스트를 예약하기 전에 프로젝트 할당량을 확인하세요. 할당량 문제를 포함한 HTTP 오류는 페이지 감사 불합격이 아닙니다.

lighthouseResult 안의 categories와 audits를 읽으세요. 카테고리 점수 0.92는 100점 만점에 92점입니다. fetchTime, lighthouseVersion, requestedUrl, finalUrl, configSettings를 저장하고 결과를 받아들이기 전에 runtimeError를 처리합니다. 응답 참조에 필드가 설명되어 있습니다. Google은 PageSpeed API에서 CrUX 데이터를 제외할 계획이므로 지속적인 필드 모니터링에는 CrUX API 또는 CrUX History API를 권장합니다.

브라우저와 휴대폰에서 실제 과제를 수행하세요

DevTools 기기 툴바를 켜고 360 × 800과 390 × 844 CSS 픽셀부터 시작하세요. 너비를 조금씩 바꾸고 가로 방향도 테스트합니다. 기기 모드는 근사치입니다. 마지막에는 방문자에게 중요한 실제 기기와 브라우저에서 확인하고, 필요하면 iPhone의 Safari도 포함하세요.

• 메뉴, 동의 설정, 대화상자를 열고 닫으세요. 고정 헤더와 배너가 글자나 조작부를 가리지 않아야 합니다.
• 긴 제목, 표, 번역문을 읽으세요. 확대와 좁은 화면도 테스트합니다. 웹 콘텐츠 접근성 지침(WCAG)의 리플로 기준은 세로로 스크롤하는 콘텐츠에 320 CSS 픽셀 너비를 적용합니다. 이는 1280픽셀 화면을 400%로 확대한 상태와 같습니다. 실제로 2차원 구조가 필요한 표는 예외가 있습니다. 넘치는 부분을 숨기지 말고 읽을 수 있는 내용과 사용할 수 있는 스크롤을 유지하세요.
• 인접한 버튼을 누르고 지원되는 경우 키보드도 사용하세요. WCAG 2.2 AA의 대상 크기 기준은 24 × 24 CSS 픽셀이며 간격 등 예외가 있습니다. 48 × 48처럼 큰 영역은 더 편한 설계 선택이 될 수 있습니다. 어느 크기도 단독으로 접근성 준수를 입증하지는 않습니다.
• 화면 키보드를 연 채 양식을 채우세요. 레이블, 포커스, 오류, 입력 보존, 제출, 확인 상태를 점검합니다. 구매나 예약은 허용된 테스트 환경에서 진행하고 해당 영수증이나 기록도 확인하세요.
• 대표적인 모바일 연결에서 반복하세요. 로딩이 늦거나 요청이 실패해도 다시 진행할 방법이 분명해야 합니다.

유용한 문제 보고는 구체적입니다. 가상의 예: “예약 페이지를 390 × 844로 열면 키보드와 동의 배너가 제출 버튼을 가립니다. 페이지는 스크롤되지만 버튼은 여전히 누를 수 없습니다.” URL, 브라우저, 기기, 상태, 재현 단계, 화면 이미지, 기대 결과, 담당자를 붙이세요. 성능 점수가 초록색이어도 예약이 막히는 문제는 해결해야 합니다.

측정한 원인을 고치세요

LCP가 느리면 실제 최대 콘텐츠 요소와 표시가 늦어지는 이유를 찾으세요. 이미지라면 일찍 발견되도록 하고 지연 로딩을 피합니다. 리소스를 더 일찍 발견해야 할 때만 미리 로드하고, 모든 이미지와 글꼴을 미리 로드하지 마세요. LCP 개선 가이드에서 차이를 설명합니다.

상호작용이 느리면 해당 행동을 기록하고 차단 작업을 조사하세요. 필수 기능과 동의를 유지하면서 불필요한 스크립트 작업을 줄이거나 긴 작업을 나눕니다. 레이아웃 이동은 이미지, 임베드, 추가 콘텐츠를 위한 공간을 미리 확보해 줄일 수 있습니다. INP와 CLS 가이드는 서로 다른 문제의 진단을 돕습니다.

WordPress나 Shopify에서는 같은 콘텐츠와 경로로 테마 또는 앱 변경을 테스트 환경에서 검증하세요. 모든 플러그인을 탓하거나 재구축을 제안하기 전에 영향을 측정합니다. 설정으로 고칠 문제도 있고 구성 요소를 바꿔야 할 문제도 있습니다. 저희 웹사이트 최적화 서비스는 원인 파악과 개선을 돕고, 코드 수정이 필요하면 웹사이트 개발로 연결합니다.

색인과 사용성을 따로 점검하세요

Google의 모바일 우선 색인 지침은 반응형 디자인을 권장하면서 다른 모바일 구성도 지원합니다. Googlebot이 모바일 콘텐츠, 이미지, 메타데이터에 접근할 수 있어야 합니다. 사용하기 편한 페이지에도 색인 문제가 있을 수 있으므로 별도의 SEO 조사가 필요할 수 있습니다.

Core Web Vitals는 순위 시스템에 반영되지만 좋은 점수가 상위 노출을 보장하지는 않으며, 나쁜 점수만으로 불이익이 입증되지도 않습니다. Google의 페이지 경험 지침은 페이지의 전체적인 유용성 안에서 이 지표를 설명합니다.

발견한 문제, 배포한 변경, 다시 수행해 성공한 과제, 남아 있는 필드 검증을 기록하세요. 테마, 앱, 양식, 태그를 바꾼 뒤에는 영향을 받은 경로를 다시 확인합니다. 보고서 통과와 방문자의 실제 과제 완료는 별개의 검증입니다.