모바일 친화성 테스트 2026: 무료 도구와 PSI API

Google은 독립형 모바일 친화성 테스트를 2023년 12월에 종료했지만, 모바일 사용성은 지금도 무료로 확인할 수 있습니다. 성능 진단에는 PageSpeed Insights와 Lighthouse, 레이아웃 확인에는 Chrome DevTools, 탐색과 양식 확인에는 실제 휴대폰을 쓰세요. 이 점검들은 서로 다른 질문에 답합니다. 빠른 페이지에도 누를 수 없는 버튼이 있을 수 있고, 쓰기 편한 페이지도 느리게 로드될 수 있습니다.

20초 만에 결과를 알고 싶다면 무료 모바일 친화성 테스트를 사용해 보세요. URL을 붙여 넣으면 뷰포트, 고정 너비, 너무 작은 글자, 페이지 용량, 크롤링 항목이 채점되고 항목별 해결 방법도 나옵니다. 이메일은 필요 없습니다.

2026년에도 쓸 수 있는 모바일 친화성 점검 도구

“Google 모바일 친화성 테스트를 실행하세요”라는 조언은 이제 통하지 않습니다. Google은 Search Console의 모바일 사용성 보고서, 모바일 친화성 테스트 도구, 모바일 친화성 테스트 API를 2023년 12월 1일부터 종료한다고 발표했고, 종료는 2023년 12월 4일에 공개적으로 확인되었습니다. 그 발표에서 Google이 밝힌 이유는, 모바일 사용성은 여전히 페이지 경험 지침의 일부지만 2015년 이후 다른 자료들이 등장했다는 것이며, 여기에는 “including Lighthouse from Chrome”이라고 적혀 있습니다.

Google은 또한 2023년 12월 1일에 검색 도움말에서 이 도구에 대한 언급을 모두 삭제하고, Search Console의 모바일 사용성 URL을 속성 개요 페이지로 리디렉션했습니다. 2023년 4월 발표에서 Google은 대안으로 Lighthouse를 안내합니다. 종료된 도구를 아직도 쓸 수 있는 선택지로 소개하는 가이드는 오래된 정보입니다.

독립적인 점검 도구로는 Bing의 Mobile Friendliness Test Tool이 남아 있습니다. 뷰포트 설정, 콘텐츠 너비, 가독성, 탭 대상 간격 등 Bing이 모바일에서 페이지를 어떻게 보는지 확인합니다. 이 판정은 Google이나 AI 어시스턴트가 그 페이지를 어떻게 평가하거나 인용할지를 말해 주지 않습니다.

모바일 사용성과 모바일 우선 색인은 서로 다른 점검입니다

Google은 페이지 콘텐츠의 모바일 버전을 색인과 순위에 사용합니다. 모바일 우선 색인 지침은 반응형 디자인, 동적 제공, 별도 모바일 URL을 모두 지원합니다. 구현과 유지 관리가 쉽기 때문에 권장되는 방식은 반응형 디자인입니다.

먼저 Googlebot이 모바일에서 콘텐츠, 이미지, 메타데이터에 접근할 수 있는지 확인하세요. 그다음 사람이 그것을 얼마나 쉽게 쓸 수 있는지 확인하세요. 모바일 페이지가 차단되었다면 크롤링 문제이고, 버튼이 비좁다면 사용성 문제입니다. Lighthouse 점수나 탭 대상 측정만으로는 페이지가 색인될지 알 수 없습니다.

감사 도구 탭을 하나 더 여는 대신 전문가의 눈으로 사이트를 보고 싶다면 웹사이트 최적화 서비스를 확인하세요.

PageSpeed Insights와 Lighthouse로 모바일 감사하기

PageSpeed Insights에서 시작하세요. URL을 붙여 넣고 실행한 뒤, 데스크톱 탭보다 모바일 탭을 먼저 읽으세요.

보고서는 사람들이 자주 헷갈리는 두 부분으로 나뉩니다.

• 위쪽의 필드 데이터: Chrome UX Report에서 가져온 실제 Chrome 사용자의 측정값으로, 28일 이동 기간으로 매일 업데이트됩니다. Google의 페이지 경험 신호가 실제로 쓰는 것이 이 데이터입니다.
• 아래쪽의 실험실 데이터: Google 서버에서 한 번 실행한 Lighthouse 시뮬레이션입니다. 진단에는 유용하지만 실제 사용자에 대한 판정은 아닙니다.

세 가지 지표를 모두 포함한 Core Web Vitals 평가를 통과하려면 세 지표 모두 75번째 백분위수에서 “좋음” 기준을 충족해야 합니다. 필드 데이터가 없으면 보고서가 이 완전한 평가를 제공할 수 없을 뿐, 페이지가 불합격했다는 증거는 아닙니다. Lighthouse는 한 번의 탐색 측정으로 필드 INP를 측정할 수 없습니다.

출처: web.dev의 Core Web Vitals 기준값, 2026년 기준. INP는 2024년 3월 12일에 First Input Delay(FID)를 대신해 Core Web Vitals 지표가 되었으므로, 아직도 FID 최적화를 권하는 체크리스트는 무시하세요.

기준선을 옮긴 PageSpeed Insights의 두 가지 변경

2024년 12월 5일, PageSpeed Insights는 CPU(프로세서) 속도를 얼마나 제한할지 조정했고, 이 때문에 모바일 실험실 측정의 Total Blocking Time이 대체로 늘었습니다. 필드와 데스크톱 결과는 영향을 받지 않았습니다. 아무것도 배포하지 않았는데 모바일 실험실 점수가 떨어졌다면 이것이 그럴듯한 원인입니다.

PageSpeed Insights(PSI)와 그 API는 2025년 10월 20일에 Lighthouse 13.0으로 전환했습니다. 버전에 따라 보이는 진단 항목이 달라질 수 있으니 결과마다 Lighthouse 버전을 기록하세요. 실제 사용자를 지속적으로 모니터링하려면 Google은 CrUX API 또는 CrUX History API를 권장합니다. Google은 PSI API에 CrUX 필드 데이터를 더 이상 포함하지 않을 계획입니다.

모바일 친화성 테스트 API를 대신할 것이 있나요?

기존 모바일 친화성 테스트 API는 도구와 함께 종료되었습니다. PageSpeed Insights API로 모바일 Lighthouse 측정을 자동화할 수는 있지만, 예전의 모바일 친화성 합격 여부 결과를 재현하지는 않습니다. 레이아웃과 상호작용 점검은 여전히 필요합니다.

아래 요청은 모바일 성능, 접근성, 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'

Google의 시작 가이드는 키 없이 API를 써 보는 것을 허용하고, 자주 자동으로 요청할 때는 키를 쓰라고 권장합니다. 일괄 실행을 예약하기 전에 프로젝트의 현재 할당량을 확인하세요. 응답이 HTTP 429라면 테스트한 페이지의 결과로 취급하지 말고 할당량을 조사하세요. 매개변수와 응답 필드는 API 참조 문서에 나와 있습니다.

카테고리 점수는 lighthouseResult.categories에서, 개별 결과는 lighthouseResult.audits에서 읽으세요. 점수는 0에서 1 사이 척도이며 0.92는 100점 만점에 92점입니다. 나중에 비교할 때 어떤 측정인지 알 수 있도록 테스트한 URL과 함께 fetchTime과 lighthouseVersion을 저장하세요. 응답을 감사 결과로 다루기 전에 HTTP 오류와 runtimeError를 처리하세요.

필드 성능에는 CrUX API 또는 CrUX History API를 쓰세요. URL에 따라 실제 사용자 데이터가 부족할 수 있습니다. 그 상태를 나쁜 결과와 구분하고, 실험실 점수를 필드 Core Web Vitals 통과로 보고하지 마세요.

Lighthouse를 로컬에서 실행하기

Lighthouse는 Chrome DevTools에 들어 있습니다. 페이지를 열고 마우스 오른쪽 버튼을 눌러 검사를 선택한 뒤, Lighthouse 패널을 열고 모바일을 선택해 보고서 생성을 클릭하세요. Lighthouse는 설치된 Chrome에서 실행되며 결과를 원격 서버로 전송하지 않으므로, PSI가 접근할 수 없는 스테이징 환경이나 비밀번호로 보호된 빌드도 감사할 수 있습니다.

모바일 프리셋은 어림짐작이 아닙니다. Lighthouse는 CPU를 4배 느리게 하는 배수를 적용해 데스크톱 CPU를 중급 휴대폰 수준으로 낮추고, 4G 연결의 하위 4분의 1을 대표하는 “Slow 4G” 네트워크 프리셋을 더합니다. 기기 에뮬레이션은 Lighthouse의 constants.js에 따르면 412x823 뷰포트와 기기 배율 1.75의 Moto G Power 프로필을 쓰며, 모바일과 터치가 활성화됩니다(이 글의 이전 버전은 2.625라고 적었는데, 이는 Lighthouse가 폐기한 예전 Moto G4 프로필의 배율이지 현재 값이 아닙니다).

Lighthouse 13은 많은 성능 감사를 DevTools에 맞춘 인사이트로 대체했고, unsized-images와 non-composited-animations는 진단 항목으로 남겼습니다. 예전의 글꼴 크기 감사도 삭제했습니다. 진단 항목이 사라졌다고 읽을 수 없는 글자가 괜찮아지는 것은 아닙니다. 실제 페이지의 글자를 휴대폰에서 확인하세요.

Chrome DevTools 기기 에뮬레이션 단계별 안내

점수는 속도를 알려 줍니다. 에뮬레이션은 페이지를 쓸 수 있는지를 알려 줍니다. 둘 다 하세요.

1. Chrome에서 페이지를 열고 검사 단축키를 누른 뒤 기기 툴바를 켜세요.
2. 먼저 좁은 뷰포트를 고르세요. 360x800과 390x844에서 테스트한 다음 태블릿 너비까지 단계적으로 넓히세요.
3. 제한을 Mid-tier mobile로 설정하거나, Lighthouse 프로필에 맞춰 Slow 4G와 CPU 4배를 직접 적용하세요.
4. 가로 모드로 돌리세요. 각 방향에서 주 메뉴, 양식, 결제 또는 문의 단계를 여세요.
5. 크기를 바꾸면서 Elements 패널을 보고 어떤 컨테이너가 넘치는지 찾으세요.

점수로는 절대 잡지 못하지만 에뮬레이션으로 잡을 수 있는 것:

• 이웃 요소에 붙어 있는 작은 탭 대상. Lighthouse 탭 대상 감사가 다루는 경우도 포함됩니다
• 고정 너비 표, 임베드, 너무 큰 이미지 때문에 생기는 가로 넘침
• 세로가 짧은 화면에서 뷰포트의 절반을 차지하는 고정 헤더와 쿠키 배너
• 닫기 버튼이 화면 밖으로 밀려난 모달
• 포커스할 때 잘못된 키보드가 뜨거나 확대되는 입력란

편안한 터치 컨트롤을 위해 레이아웃이 허락하는 한 48x48 CSS 픽셀을 목표로 하세요. Lighthouse의 문서화된 규칙은 대상 크기와 주변 대상과의 겹침을 모두 고려하며, 더 작은 컨트롤을 모두 불합격 처리하지는 않습니다. 별도의 WCAG 2.2 AA 대상 크기 기준은 간격과 기타 예외를 둔 24x24 CSS 픽셀을 씁니다. 어느 쪽도 Google의 보편적인 순위 기준값은 아닙니다.

한계도 알아 두세요. 에뮬레이션은 데스크톱 브라우저 크기를 바꾸고 느린 CPU를 흉내 낼 뿐입니다. 실제 터치 지연, iOS Safari의 특성, 엄지손가락이 닿는 범위, 발열로 성능이 제한된 중급 Android 기기가 무거운 스크립트를 처리하는 방식은 재현하지 못합니다. 모든 감사는 실제 휴대폰에서 마무리하세요.

Search Console에서 Core Web Vitals 모바일 데이터 읽기

예전의 모바일 사용성 보고서는 사라졌습니다. 실제 사용자 성능에는 Search Console의 Core Web Vitals 보고서를 쓰고, 레이아웃과 상호작용은 따로 점검하세요.

Search Console을 열고 Core Web Vitals로 이동해 모바일 보고서를 살펴보세요. Google은 개요를 기기별로 나누고, 비슷한 경험을 제공하는 URL을 그룹으로 묶고, 각 그룹에 가장 성적이 나쁜 지표의 상태를 부여합니다. 따라서 한 템플릿에서 지표 하나만 나빠도 그 템플릿의 모든 URL이 “나쁨”으로 떨어집니다.

저희가 읽는 방법:

• 모바일 차트 옆의 보고서 열기를 클릭하고 “나쁨”, “개선 필요”, “좋음” 탭을 전환하세요.
• “URL이 좋음으로 간주되지 않는 이유” 표를 읽으세요. 불합격한 지표와 넘어선 기준값이 나옵니다.
• URL이 아니라 템플릿을 고치세요. 상태가 그룹 단위이므로 템플릿 하나를 고치면 많은 페이지가 움직입니다.
• 배포한 뒤에는 추적 시작을 쓰세요. Google은 28일 동안 모니터링하며, 그 기간 내내 문제가 나타나지 않을 때만 해결됨으로 표시합니다.

주의할 점이 두 가지 있습니다. 데이터는 28일 이동 집계이므로 화요일에 배포한 수정이 수요일에 보이지 않습니다. 또 Google은 PageSpeed Insights 데이터가 Core Web Vitals 보고서와 다를 수 있다고 분명히 밝힙니다. 하나는 기기 프로필 하나로 실행한 실험실 측정이고, 다른 하나는 수천 건의 실제 세션이기 때문입니다. 둘이 다를 때는 필드 데이터를 믿고 실험실 측정으로 원인을 찾으세요. web.dev에서 실험실과 필드의 차이를 더 자세히 설명합니다. 같은 지표가 저희의 웹사이트 최적화 방식에도 들어 있습니다.

가장 흔한 모바일 문제와 해결 방법

위 도구들이 잡도록 만들어진 문제와, 각각에 쓰이는 기준값 또는 규칙입니다.

어떤 도구가 무엇을 감지하는지 보세요. 목록 전체를 다루는 점검 도구는 하나도 없으며, 바로 그래서 예전의 합격 여부 배지만으로는 결코 충분하지 않았습니다.

저희가 하는 감사 순서

저희 사이트와 클라이언트 사이트에서 쓰는 순서입니다.

1. URL을 하나가 아니라 세 개 고르세요. 홈페이지, 주요 서비스나 제품 페이지, 블로그 글입니다. 템플릿마다 문제가 다르게 나타납니다.
2. Search Console이 먼저입니다. Core Web Vitals의 모바일 보기에서 어떤 URL 그룹이 “나쁨”이나 “개선 필요”에 있고 어떤 지표가 표시되는지 적어 두세요. 실제 사용자 데이터이므로 이것이 우선순위를 정합니다.
3. 불합격한 그룹마다 URL 하나를 PSI로 측정하세요. 필드 데이터와 실험실 데이터를 비교하세요. 필드는 “나쁨”인데 실험실은 괜찮다면, 서드파티 스크립트, 로그인 상태, 느린 원본 서버처럼 깨끗한 실험실 측정에서는 보이지 않는 것을 찾으세요.
4. 같은 세 URL을 로컬 Lighthouse로 측정하세요. 모바일 프리셋으로 탭 대상과 unsized-images 진단, 그리고 대비 문제는 접근성 패널을 읽으세요.
5. DevTools 기기 모드에서 360x800. 메뉴, 양식, 주요 전환 단계를 열고 화면을 돌려 넘침과 가려진 콘텐츠를 찾으세요.
6. Bing의 Mobile Friendliness Test를 같은 URL에 실행해 뷰포트, 너비, 가독성, 탭 간격에 대한 두 번째 크롤러의 판정을 받으세요.
7. 실제 휴대폰 한 대, 가능하면 중급 Android. 사무실 Wi-Fi가 아니라 모바일 데이터로 로드하고 전환 행동을 처음부터 끝까지 완료하세요.
8. 템플릿 수정을 배포하고 Search Console에서 추적 시작을 누르세요. 검증이 끝나기까지 28일을 예상하세요.

필드 데이터와 실험실 데이터가 다른 이유

Google은 PageSpeed Insights 데이터가 Core Web Vitals 보고서와 다를 수 있다고 명시합니다. 실험실 데이터는 기기 프로필 하나로 한 번 실행한 시뮬레이션입니다. 필드 데이터는 실제 Chrome 사용자의 28일 이동 집계입니다. 실험실 데이터와 필드 데이터에 관한 web.dev 가이드는 흔한 원인을 이렇게 꼽습니다. 실제 기기와 네트워크는 실험실보다 편차가 크고, 서드파티 스크립트는 실제 사용자에게 다르게 작동하고, 캐시와 뒤로-앞으로 캐시가 재방문을 바꾸고, CrUX는 트래픽이 충분한 URL만 보고합니다. 둘이 다를 때는 필드 데이터를 판정으로, 실험실 측정을 진단으로 다루세요.

사이트를 검토할 때 저희는 먼저 Search Console 필드 데이터를 보고, 그다음 PSI와 Lighthouse로 요소나 스크립트를 찾아냅니다. Google의 최적화 가이드가 곧 실행 지침입니다.

• 느린 LCP: Largest Contentful Paint 최적화. 대표 이미지를 압축하고, 최신 형식으로 제공하고, LCP 요소를 미리 로드하고, 지연 로딩하지 마세요.
• 높은 INP: Interaction to Next Paint 최적화. 긴 작업을 나누고, 메인 스레드를 막는 서드파티 JavaScript를 늦추거나 없애세요.
• 높은 CLS: Cumulative Layout Shift 최적화. 이미지와 임베드에 너비, 높이 또는 aspect-ratio를 지정해 로드될 때 레이아웃이 튀지 않게 하세요.

Search Console은 비슷한 경험을 제공하는 URL을 그룹으로 묶고, 각 그룹에 가장 성적이 나쁜 지표의 상태를 부여합니다. 공용 카드 컴포넌트에 이미지 크기를 지정하는 것 같은 템플릿 수정 하나로 많은 URL이 한꺼번에 움직일 수 있습니다. 배포한 뒤에는 추적 시작을 쓰고, Google이 문제를 해결됨으로 표시할 때까지 28일 전체를 기다리세요.

테마 변경, 플러그인이나 앱 설치, 태그 관리자 배포 후에는 이 여덟 단계를 반복하고, 분기마다 정기 점검도 하세요. 서드파티 스크립트는 Google의 INP 지침에 INP 위험 요소로 문서화되어 있으며, 그래서 3단계에서 필드 데이터를 깨끗한 실험실 측정과 비교합니다. 이 모바일 점검과 관련된 크롤링, 색인, 페이지 작업은 저희 검색 엔진 최적화 서비스를 참고하세요.

WordPress나 Shopify를 쓴다면

두 플랫폼 모두 코드 대신 설정만으로 대부분을 해결할 수 있습니다.

• 결정하기 전에 360px에서 테스트한 반응형 테마
• LCP 이미지를 제외한 모든 곳에 기본 지연 로딩
• CSS(Cascading Style Sheets)로 줄인 데스크톱 파일이 아니라 올바른 크기로 제공하는 최신 이미지 형식
• Shopify Online Store 2.0 템플릿과 섹션 단위 이미지 크기 지정
• 설치된 앱과 플러그인 감사. 각각이 보통 렌더링을 막는 JavaScript를 추가하기 때문입니다

테마나 앱을 바꿀 때마다 Lighthouse를 다시 실행하세요. 모바일 점수가 조용히 떨어지는 곳이 바로 거기입니다. 테마 자체가 한계라면, 처음부터 성능과 SEO를 설계에 넣은 최신 프레임워크로 다시 만드는 것이 해법이며, 저희 웹사이트 개발 서비스가 제공하는 것이 바로 그것입니다.

자주 묻는 질문

Google 테스트가 없어진 지금 모바일 친화성은 어떻게 확인하나요?

Chrome DevTools의 Lighthouse를 모바일 프리셋으로 실행하고, PageSpeed Insights의 모바일 탭을 확인하고, Search Console의 Core Web Vitals 모바일 보고서를 읽은 뒤, 실제 휴대폰에서 확인하세요. 합격 여부 판정이 필요하다면 Bing의 Mobile Friendliness Test가 지금도 제공합니다.

모바일 친화적과 반응형의 차이는 무엇인가요?

모바일 친화적이란 휴대폰에서 페이지를 쓸 수 있다는 뜻입니다. 반응형 디자인은 유동적인 레이아웃과 CSS 미디어 쿼리로 같은 페이지를 여러 뷰포트에 맞춥니다. Google은 유지 관리가 쉬운 반응형 디자인을 권장하지만, 동적 제공과 별도 모바일 URL도 지원합니다.

별도의 모바일 웹사이트가 필요한가요?

아니요. 반응형 URL 하나가 유지 관리가 더 쉽고, 중복 콘텐츠 처리를 피할 수 있으며, SEO와 생성형 엔진 최적화에 하나의 신호 묶음을 제공합니다.

Google은 모바일 친화적이지 않은 웹사이트에 불이익을 주나요?

콘텐츠 접근과 사용자 경험을 따로 확인하세요. Google은 색인을 위해 모바일 콘텐츠에 접근하고 렌더링할 수 있어야 합니다. Core Web Vitals는 순위에 쓰이지만, 페이지 경험이 부족해도 Google은 관련성 있는 콘텐츠를 계속 찾습니다. 모바일 점수가 나쁘다는 사실만으로는 색인 삭제, 불이익, 특정한 순위 하락이 증명되지 않습니다.

PageSpeed Insights와 Search Console의 결과가 다른 이유는 무엇인가요?

Google은 둘이 다를 수 있다고 밝힙니다. PSI 실험실 데이터는 기기 프로필 하나로 한 번 실행한 시뮬레이션입니다. Search Console은 URL 그룹 전체에 대해 실제 Chrome 사용자의 28일 이동 집계를 보고합니다. Google의 Core Web Vitals 보고서 문서와 실험실과 필드에 관한 web.dev 글 모두 필드 데이터를 판정으로, 실험실 데이터를 진단으로 다루라고 말합니다.

배지 하나를 네 가지 도구가 대신합니다

합격 여부 배지 하나는 사라졌고 돌아오지 않습니다. 그 자리를 대신한 것이 더 낫습니다. 실제 사용자의 필드 측정, 스테이징에서도 실행할 수 있는 실험실 감사, 레이아웃을 위한 뷰포트 에뮬레이션, 그리고 Bing이라는 두 번째 크롤러의 판정입니다. 이 네 가지를 중심으로 프로세스를 짜고, Search Console이 알려 주는 실제 사용자 경험으로 우선순위를 정하고, 개별 URL이 아니라 템플릿을 고치세요.

저희는 밴쿠버에서 이 작업을 웹사이트 최적화로 제공합니다. 모바일 성능 때문에 순위나 전환을 잃고 있다면 그로스 감사부터 시작하세요.