1. 개요 (Executive Summary)
홈페이지가 모바일에서 느리게 뜨거나 레이아웃이 깨진다면, 지금 이 순간에도 방문자를 문 앞에서 돌려보내고 있는 것입니다. 사무실 모니터에서는 멀쩡해 보이니 문제를 인지하기 어려울 뿐입니다.
이 글은 세 가지 질문에 답합니다. 내 홈페이지 방문자는 정말 모바일이 다수인가, 구글은 속도를 어떻게 평가하는가, 그리고 무엇부터 고치면 되는가. 디자인 원칙과 속도 최적화 실무, 무료 점검 도구까지 담당자가 직접 확인할 수 있는 수준으로 정리했습니다.
코드를 몰라도 됩니다. 어떤 항목을 제작사에 요구해야 하는지, 결과물을 어떤 기준으로 검수해야 하는지 판단할 수 있으면 충분합니다.
핵심 메시지
구글은 2023년 모바일 퍼스트 인덱싱 전환을 끝냈습니다. 검색 순위를 결정하는 기준 화면은 데스크톱이 아니라 모바일입니다. 그런데 검수는 여전히 사무실 모니터로 하는 곳이 많습니다.
속도 기준도 명확합니다. LCP 2.5초, INP 200ms, CLS 0.1 — 이 세 숫자를 통과하는지가 "빠른 사이트"의 공식 기준입니다.
2. 트래픽은 이미 모바일이 다수다
스탯카운터(StatCounter) 집계로 전 세계 웹 트래픽의 약 60%가 모바일에서 발생합니다. 데스크톱이 기본이고 모바일이 예외였던 시대는 이미 여러 해 전에 끝났습니다.
업종에 따라 격차는 더 벌어집니다. 음식점, 미용실, 병원, 학원처럼 지역에서 고객을 만나는 업종은 검색이 이동 중에, 손 안에서 일어납니다. 네이버 검색, 인스타그램 프로필 링크, 카카오톡으로 공유된 주소 — 이 경로로 들어오는 방문은 거의 전부 모바일입니다. 광고를 집행해 본 담당자라면 유입 리포트에서 모바일 비중이 70%를 넘는 화면을 이미 봤을 겁니다.
2.1 구글은 어느 화면으로 내 사이트를 평가하나?
모바일 화면입니다. 구글은 2016년 모바일 퍼스트 인덱싱(Mobile-First Indexing)을 발표했고, 2023년 10월 전환 완료를 선언했습니다. 지금 구글 검색 결과에 반영되는 것은 스마트폰 크롤러가 읽은 모바일 버전입니다. 데스크톱에서 아무리 완성도가 높아도, 모바일에서 콘텐츠가 잘리거나 숨겨져 있으면 그 내용은 평가에서 빠집니다.
모바일 화면을 간소화한다며 소개 문구와 상세 설명을 통째로 걷어내는 리뉴얼이 종종 있습니다. 보기에는 깔끔해져도 검색엔진 입장에서는 콘텐츠가 사라진 사이트가 됩니다. 줄일 것은 장식이지 정보가 아닙니다.
2.2 왜 데스크톱 화면만 보고 검수하면 안 되나?
제작 과정의 함정이 여기에 있습니다. 발주 담당자도 제작사도 검수는 대부분 사무실 모니터로 합니다. 27인치 화면에서 완벽했던 사이트가 6인치 화면에서는 글자가 깨알 같고, 버튼 두 개가 겹치고, 전화 걸기 버튼은 스크롤을 세 번 내려야 나옵니다.
정작 매출을 만들 고객은 그 6인치 화면으로 들어옵니다. 검수 기준을 "내 모니터에서 예쁜가"에서 "고객 폰에서 쓸 만한가"로 바꾸는 것, 모바일 퍼스트는 거기서 시작합니다.
모바일 퍼스트 인덱싱, 한 줄 요약
구글이 사이트의 순위를 매길 때 모바일 버전의 콘텐츠·구조·속도를 기준으로 삼는다는 뜻입니다. 모바일 화면이 곧 사이트의 공식 성적표입니다.
사이트를 새로 열었거나 리뉴얼 직후라면 색인 등록과 기본 세팅부터 점검해야 합니다. 순서는 홈페이지 오픈 후 90일 SEO 세팅 가이드에 정리해 두었습니다.
3. Core Web Vitals: 구글이 보는 속도 지표
구글은 "빠르다"를 감이 아니라 숫자 세 개로 판정합니다. 로딩 속도(LCP), 반응성(INP), 화면 안정성(CLS). 이 셋을 묶어 Core Web Vitals(핵심 웹 지표)라고 부르고, 검색 순위 산정에 반영합니다.
3.1 세 가지 지표와 통과 기준
| 지표 | 무엇을 재나 | 좋음 | 개선 필요 | 나쁨 |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) |
화면에서 가장 큰 콘텐츠(대개 메인 이미지)가 표시되기까지 걸리는 시간 | 2.5초 이하 | 2.5~4.0초 | 4.0초 초과 |
| INP (Interaction to Next Paint) |
버튼을 탭한 뒤 화면이 반응하기까지 걸리는 시간 | 200ms 이하 | 200~500ms | 500ms 초과 |
| CLS (Cumulative Layout Shift) |
로딩 중 화면 요소가 갑자기 밀리는 정도 | 0.1 이하 | 0.1~0.25 | 0.25 초과 |
판정 기준은 실사용자 데이터의 75번째 백분위수입니다. 방문 100건 중 75건이 기준 안에 들어와야 "통과"입니다. 내 폰에서 한 번 빨리 떴다고 통과가 아니라는 뜻입니다. INP는 2024년 3월부터 기존 지표였던 FID(First Input Delay)를 대체했습니다.
CLS는 이름이 낯설어도 경험은 익숙합니다. 기사를 읽으려고 버튼을 누르는 순간 광고가 끼어들어 엉뚱한 걸 누르게 되는 그 현상. 이미지 크기를 미리 지정하지 않은 페이지에서 흔하게 일어납니다.
3.2 속도가 검색 순위를 얼마나 좌우하나?
영향은 주지만, 콘텐츠 품질을 뒤집을 정도는 아닙니다. 구글은 페이지 경험을 여러 순위 신호 가운데 하나로 반영한다고 밝혀 왔습니다. 비슷한 품질의 문서가 경쟁할 때 빠른 쪽이 앞서는 구조에 가깝습니다.
순위보다 무서운 건 이탈입니다. 구글이 2016년 발표한 조사에서는 모바일 페이지 로딩이 3초를 넘기면 방문의 53%가 중단됐습니다. 클릭당 몇천 원씩 내고 데려온 방문자가 첫 화면을 보기도 전에 떠난다는 얘기입니다. 순위가 한 계단 오르는 것보다 들어온 사람이 머무는 쪽이 매출에는 훨씬 직접적입니다.
내 사이트 점수, 지금 30초면 확인됩니다
PageSpeed Insights(pagespeed.web.dev)에 홈페이지 주소를 넣어 보세요. 모바일 기준 점수와 세 지표의 통과 여부가 바로 나옵니다.
이 글을 끝까지 읽기 전에 먼저 측정해 두면, 뒤에 나오는 최적화 항목 중 무엇이 내 사이트에 해당하는지 판단하기 쉬워집니다.
4. 모바일 퍼스트 설계 원칙
모바일 퍼스트는 "모바일에서도 보이게"가 아닙니다. 작은 화면에서 먼저 설계하고 큰 화면으로 확장하는 순서의 문제입니다. 데스크톱 시안을 먼저 만들고 좁히면 어딘가는 반드시 부러집니다. 좁은 화면에서 살아남은 구조를 넓히는 편이 안전합니다.
4.1 터치 타깃: 엄지로 눌러서 안 틀리는가
마우스 커서는 픽셀 단위로 정확하지만 엄지손가락은 그렇지 않습니다. 구글 머티리얼 디자인은 터치 영역을 최소 48×48dp, 애플 휴먼 인터페이스 가이드라인은 44×44pt로 권장합니다. 버튼 자체가 커야 하고, 버튼 사이 간격도 있어야 합니다. 링크 두 개가 붙어 있으면 둘 중 하나는 오터치로 눌립니다.
전화번호는 반드시 tel: 링크로 걸어 두세요. 번호를 눈으로 외워 전화 앱에 옮겨 적게 만드는 사이트가 아직도 많습니다. 탭 한 번에 통화 화면이 떠야 문의 전화가 늘어납니다.
4.2 글자 크기와 줄 길이
본문은 16px 이상이 기본입니다. 방문자가 손가락으로 화면을 벌려 확대해야 읽힌다면 그 글자는 이미 실패한 겁니다. 줄간격은 1.6~1.8배, 한 줄 길이는 너무 길지 않게. 명도 대비도 챙겨야 합니다. 밝은 회색 글자를 흰 배경에 얹는 유행은 야외 직사광 아래에서 아무것도 안 보이는 화면을 만듭니다.
4.3 햄버거 메뉴가 항상 답은 아니다
메뉴를 전부 석 줄 아이콘 뒤에 숨기는 방식이 표준처럼 굳었지만, 숨긴 메뉴는 덜 눌립니다. 메뉴가 4~5개뿐이라면 굳이 숨길 이유가 없습니다. 상단에 그대로 노출하거나, 자주 쓰는 항목 — 전화, 오시는 길, 예약 — 을 화면 하단 고정 바로 빼는 편이 낫습니다.
햄버거 메뉴가 필요한 경우도 물론 있습니다. 메뉴가 열 개를 넘는 쇼핑몰이나 콘텐츠 사이트가 그렇습니다. 판단 기준은 하나입니다. 방문자가 가장 자주 찾을 행동이 탭 한 번 거리에 있는가.
4.4 첫 화면에 무엇을 보여줄 것인가
모바일 첫 화면은 손바닥 반 뼘입니다. 그 안에 회사 연혁과 CEO 인사말을 넣을 자리는 없습니다. 방문자가 온 목적 — 뭘 하는 회사인지, 연락은 어떻게 하는지, 어디에 있는지 — 이 스크롤 없이 잡혀야 합니다.
우선순위를 정하는 방법은 단순합니다. 고객이 전화로 가장 많이 묻는 질문 세 가지를 적어 보세요. 그 답이 첫 두 화면 안에 없다면 배치가 잘못된 겁니다.
4.5 반응형과 적응형, 무엇을 고를까?
결론부터: 중소기업 홈페이지라면 반응형입니다.
| 구분 | 반응형 (Responsive) | 적응형 (Adaptive) |
|---|---|---|
| 방식 | 하나의 페이지가 화면 폭에 따라 유동적으로 재배치 | 기기별로 별도 화면 또는 별도 URL(m.도메인) 제공 |
| 관리 | URL 하나, 콘텐츠 하나로 단일 관리 | 버전별 이중 관리, 수정 누락 위험 |
| SEO | 구글 권장 방식 | 대체 URL 설정이 어긋나면 색인 문제 발생 |
| 적합한 경우 | 대부분의 기업 홈페이지 | 모바일 기능이 완전히 다른 대형 서비스 |
오래된 사이트 중에는 m.도메인 형태의 모바일 전용 페이지를 따로 운영하는 곳이 남아 있습니다. 관리 비용은 두 배, SEO는 분산되는 구조라 리뉴얼 시점에 반응형 하나로 합치는 편이 낫습니다. 전면 개편을 검토 중이라면 홈페이지 리뉴얼 가이드에서 진행 순서와 체크포인트를 확인할 수 있습니다.
5. 속도 최적화 실무
어디부터 손대야 하나? 이미지입니다. 체감 속도 개선의 대부분은 이미지와 스크립트에서 나옵니다. 서버 증설이나 호스팅 이전을 고민하기 전에, 난이도 낮고 효과 큰 것부터 순서대로 정리했습니다.
5.1 이미지: 가장 크고 가장 쉬운 문제
느린 홈페이지를 열어 보면 십중팔구 원인은 이미지입니다. 카메라에서 나온 4000px짜리 원본을 그대로 올려 두고, 브라우저가 그걸 다 내려받은 뒤에야 작게 줄여 보여주는 구조. 페이지 하나가 수십 MB인 사이트도 실제로 드물지 않습니다.
- WebP 변환: 구글 개발 문서 기준 WebP는 같은 품질에서 JPEG보다 25~34% 작습니다. 변환 도구는 무료로 널려 있고, 워드프레스라면 플러그인이 자동으로 처리합니다.
- 표시 크기에 맞춘 리사이즈: 화면에 400px로 보일 이미지라면 800px(고해상도 대응)이면 충분합니다. 4000px 원본은 서버에만 두세요.
- 지연 로딩:
loading="lazy"속성 하나면 화면 밖 이미지는 스크롤이 닿을 때 불러옵니다. 첫 화면 로딩이 그만큼 가벼워집니다. 단, 첫 화면의 메인 이미지에는 걸지 마세요. LCP가 오히려 늦어집니다. - 가로·세로 크기 명시: width와 height를 지정하면 브라우저가 자리를 미리 잡아 둡니다. 로딩 중 화면이 밀리는 CLS 문제의 가장 흔한 해결책입니다.
5.2 폰트: 한글 폰트는 무겁다
한글은 조합 가능한 글자가 11,172자입니다. 영문 폰트 감각으로 한글 폰트 파일을 통째로 얹으면 폰트 하나가 수 MB를 차지합니다. 글자가 한참 안 보이다가 뒤늦게 바뀌면서 화면이 출렁이는 사이트, 대부분 폰트가 범인입니다.
- 서브셋 폰트: 실사용 빈도가 높은 2,350자(KS X 1001 완성형)만 담은 서브셋을 쓰면 용량이 크게 줄어듭니다. 눈누 같은 폰트 사이트나 구글 폰트가 서브셋 버전을 제공합니다.
- woff2 포맷: 웹폰트는 woff2 하나면 됩니다. ttf나 otf를 웹에 그대로 올리는 것은 압축 안 한 파일을 배포하는 셈입니다.
- font-display: swap: 폰트가 로딩되는 동안 기본 글꼴로 먼저 보여주는 설정입니다. 글자가 아예 안 보이는 빈 화면보다 훨씬 낫습니다.
5.3 스크립트: 안 쓰는 것부터 지운다
채팅 위젯, 옛날에 붙인 트래킹 코드, 쓰지도 않는 슬라이더 라이브러리. 이런 스크립트가 쌓이면 페이지가 버튼 탭에 반응하지 못하는 시간이 길어지고, INP가 나빠집니다. 최적화 기법을 적용하기 전에 목록부터 만들어 안 쓰는 것을 지우는 게 먼저입니다.
남길 스크립트에는 defer 속성을 붙여 페이지 표시를 막지 않게 합니다. 화면을 그리는 데 필요하지 않은 코드가 화면 표시를 기다리게 만들 이유가 없습니다.
5.4 서버 쪽: 압축과 캐싱
서버 설정 몇 줄로 끝나는 항목도 있습니다. gzip 또는 brotli 압축을 켜면 HTML·CSS·JS 같은 텍스트 파일의 전송량이 크게 줄고, 브라우저 캐시(Cache-Control)를 설정하면 재방문자는 이미지와 CSS를 다시 내려받지 않습니다. 직접 만지기 어렵다면 호스팅 업체나 제작사에 "gzip 압축과 브라우저 캐싱 설정해 주세요" 한 줄이면 전달됩니다.
5.5 항목별 효과 정리
| 작업 | 난이도 | 주로 개선되는 지표 |
|---|---|---|
| 이미지 WebP 변환 + 리사이즈 | 낮음 | LCP |
| 이미지 지연 로딩(lazy) | 낮음 | LCP |
| 이미지 width/height 지정 | 낮음 | CLS |
| 한글 폰트 서브셋 + woff2 | 중간 | LCP, CLS |
| 스크립트 정리 + defer | 중간 | INP |
| gzip/brotli 압축 + 캐싱 | 중간 | LCP 전반 |
워드프레스라면: 플러그인 다이어트부터
플러그인 하나하나가 CSS와 스크립트를 얹습니다. 스무 개 넘게 깔린 사이트에서 절반은 대개 비활성이거나 용도를 아무도 기억하지 못합니다.
목록을 뽑아 "이거 지우면 뭐가 안 되나?"를 하나씩 확인하며 정리하는 것만으로 점수가 오르는 경우가 흔합니다. 캐시 플러그인은 성격이 겹치므로 하나만 남기세요. 두 개가 동시에 돌면 오히려 충돌합니다.
6. 점검 도구와 테스트 루틴
도구는 셋이면 충분합니다. PageSpeed Insights, Lighthouse, Google Search Console. 전부 무료이고, 셋 다 회원가입 없이 또는 구글 계정 하나로 씁니다.
6.1 PageSpeed Insights: 실사용자 데이터까지 한 번에
주소를 넣으면 두 종류의 결과가 나옵니다. 위쪽의 실제 사용자 환경 평가는 크롬 사용자들의 최근 28일 실측 데이터(CrUX)로, Core Web Vitals 통과 여부를 판정하는 공식 기준입니다. 아래쪽 진단 점수는 시뮬레이션(랩 데이터)이고, 함께 나오는 개선 항목 목록이 실무에서 제일 쓸모 있습니다. 반드시 모바일 탭을 먼저 보세요. 데스크톱 점수는 대개 후하게 나옵니다.
6.2 Lighthouse: 크롬만 있으면 된다
크롬 개발자 도구(F12)의 Lighthouse 탭에서 같은 진단을 로컬에서 돌릴 수 있습니다. 아직 공개하지 않은 개발 중인 사이트를 점검할 때, 수정 전후를 바로 비교할 때 유용합니다. 제작사에 결과 리포트를 받아 검수 자료로 쓰는 방법도 있습니다.
6.3 Search Console: 실제 방문자 기준의 합격 여부
Search Console의 Core Web Vitals 보고서는 내 사이트 URL들이 실사용자 기준으로 양호/개선 필요/나쁨 어디에 속하는지 모바일과 데스크톱으로 나눠 보여줍니다. 어떤 페이지 그룹이 문제인지 짚어 주므로 수리 우선순위를 정하기 좋습니다.
참고로 예전에 있던 '모바일 사용성' 보고서는 2023년 말 종료됐습니다. 화면 깨짐이나 터치 요소 간격 점검은 이제 Lighthouse와 실기기 테스트로 대신합니다.
6.4 도구보다 확실한 것: 본인 스마트폰
점수가 아무리 좋아도 실제 폰에서 불편하면 소용없습니다. 와이파이를 끄고 LTE로 접속해 보세요. 사무실 기가 인터넷이 아니라 지하철에서 잡히는 신호가 고객의 환경입니다.
- 첫 화면이 3초 안에 의미 있게 뜨는가
- 전화·예약·문의 버튼이 엄지 한 번 거리에 있는가
- 스크롤 중 화면이 밀리거나 덜컥거리지 않는가
- 확대 없이 본문이 읽히는가
랩 데이터와 필드 데이터가 다르게 나온다면
Lighthouse 점수는 좋은데 Search Console에서는 "개선 필요"로 뜨는 경우가 있습니다. 랩 데이터는 정해진 조건의 시뮬레이션이고, 필드 데이터는 느린 폰과 지하철 LTE까지 섞인 실측이기 때문입니다.
둘이 어긋나면 필드 데이터가 기준입니다. 구글이 순위에 반영하는 것도, 고객이 실제로 겪는 것도 그쪽입니다.
7. 결론 및 체크리스트
7.1 세 문장 요약
방문자 다수는 모바일로 들어오고, 구글도 모바일 화면으로 사이트를 평가합니다. 속도는 LCP 2.5초·INP 200ms·CLS 0.1이라는 명확한 합격선이 있고, 그 합격선을 가르는 것은 대부분 이미지·폰트·스크립트입니다. 설계는 작은 화면에서 시작해 큰 화면으로 넓히는 순서가 안전합니다.
7.2 오늘 바로 점검할 6가지
- 실기기 테스트: 와이파이 끄고 본인 폰으로 접속, 첫 화면이 3초 안에 뜨는지 확인
- 점수 측정: PageSpeed Insights 모바일 탭에서 Core Web Vitals 통과 여부 확인, 결과 캡처 보관
- 이미지 정비: WebP 변환, 표시 크기에 맞춘 리사이즈, 지연 로딩, width/height 지정
- 폰트 정비: 한글 서브셋 + woff2 + font-display: swap 적용 여부 확인
- 터치 검수: 전화·문의 버튼이 탭 한 번 거리인지, 버튼 크기 48px 기준을 넘는지, 본문이 16px 이상인지
- 측정 루틴: 월 1회 같은 조건으로 재측정해 기록 — 콘텐츠와 플러그인이 늘수록 속도는 반드시 되돌아갑니다
7.3 속도는 상태가 아니라 습관이다
한 번 최적화한 사이트도 방치하면 다시 느려집니다. 담당자가 배너 이미지를 원본으로 올리고, 마케팅팀이 트래킹 코드를 하나 더 붙이고, 플러그인이 업데이트되면서 스크립트가 늘어납니다. 그래서 마지막 체크리스트 항목이 측정 루틴입니다.
측정 기록이 쌓이면 "요즘 사이트가 느려진 것 같다"는 감이 "3월부터 LCP가 1초 늘었다"는 사실이 됩니다. 사실이 있어야 제작사든 내부든 정확한 수리를 요청할 수 있습니다.