PSI를 켰는데 점수가 안 움직이면, 대개 고치는 순서부터 틀린 겁니다. 이미지를 압축하고 폰트만 만지는데도 성능이 제자리라면, 점수 배점과 가장 무거운 지표를 먼저 안 본 경우가 많습니다. 애드센스 심사 전 점검은 "체감상 느린 것"이 아니라 "점수에 바로 들어가는 항목"부터 봐야 합니다.
특히 광고가 붙는 사이트는 속도 최적화 글의 조언을 그대로 따라가면 더 망가질 수 있습니다. 대표적인 게 광고 스크립트를 무조건 늦게 넣는 방식입니다. Auto ads나 크기 미지정 반응형 광고가 있으면 오히려 CLS와 수익이 함께 흔들릴 수 있습니다. 그러니 이 글은 폰트 회고가 아니라, 애드센스 심사 전 하루에 끝내는 PSI 체크 순서를 다룹니다.
준비물은 세 가지면 됩니다. 홈/대표 글/목록 URL 하나씩, PSI 모바일 랩 실행 결과, 그리고 "오늘은 진단 하나만 고친다"는 원칙입니다. 신규 사이트라면 필드 데이터가 비어 있어도 놀랄 필요가 없습니다. 랩 데이터로 병목부터 자르고, 그다음에 실제 사용자 데이터가 쌓일 시간을 기다리면 됩니다.
끝까지 읽으면 점수 배점, LCP 4구간, TBT, 광고 CLS, 폰트 함정까지 어느 순서로 봐야 하는지 감이 잡힙니다. 속도 점수 99를 만드는 게 목표가 아니라, 심사 전에 잘못된 순서로 시간을 낭비하지 않는 것이 목표입니다.
먼저 알아야 할 것: 점수 배점
PSI 점수를 올리려는 사람 대부분이 배점을 모르고 시작합니다. 이미지부터 압축하고 캐시 헤더를 만지는데 점수가 안 움직이는 이유가 여기 있습니다. 그 항목들은 점수의 직접 입력값이 아닐 수 있기 때문입니다.
Lighthouse 10 기준 성능 점수는 다섯 지표의 가중 평균입니다.
| 지표 | 가중치 | 무엇을 재나 |
|---|---|---|
| Total Blocking Time | 30% | 메인 스레드가 막힌 총 시간 |
| Largest Contentful Paint | 25% | 가장 큰 콘텐츠가 그려진 시점 |
| Cumulative Layout Shift | 25% | 레이아웃이 밀린 정도 |
| First Contentful Paint | 10% | 첫 픽셀이 그려진 시점 |
| Speed Index | 10% | 화면이 채워지는 속도 |
여기서 바로 두 가지가 나옵니다. TBT + CLS가 55%입니다. 둘 다 자바스크립트와 광고가 주범인 경우가 많습니다. 그런데 최적화 글 대부분은 이미지와 폰트, 즉 FCP/LCP 위주로만 갑니다.
또 하나, "개선할 항목"과 "진단"은 점수 그 자체가 아닙니다. 구글 문서가 말하듯, 점수를 만드는 건 위 다섯 지표입니다. 진단은 그 지표를 움직이기 위한 힌트일 뿐입니다. 그래서 "미사용 JS 제거 0.8초"를 고쳤는데도 점수는 그대로일 수 있습니다.
💡 Tip: 90점을 넘었다면 숫자 100을 쫓기보다, 진단 원문이 사라졌는지부터 보세요. 애드센스 심사에는 그 시간이 글 한 편 더 쓰는 것보다 가치가 낮을 수 있습니다.
오늘의 체크리스트
인쇄하거나 복사해서 쓰세요. 순서가 중요합니다.
애드센스 쪽, 속도보다 먼저
- [ ] 공개 URL 세 종(홈/대표 글/목록)이 빈 본문 200이 아닌가
- [ ] 문서 0건 카테고리가 내비와 사이트맵에 없는가
- [ ] 개인정보처리방침, 쿠키/광고 고지, ads.txt가 있는가
- [ ] HTTPS와 빈 템플릿 페이지 정리가 끝났는가
- [ ] 주제가 한 분야로 모여 있는가
측정
- [ ] PSI 모바일로 대표 URL 1회 실행
- [ ] 성능 점수와 FCP/LCP/TBT/CLS 스크린샷 저장
- [ ] CrUX 데이터가 URL 단위인지 오리진 단위인지 확인
- [ ] LCP 요소가 무엇인지 확인
고치기
- [ ] LCP 4구간 중 delay가 비대한가
- [ ] TBT 상위 롱태스크가 어느 스크립트인가
- [ ] 광고 슬롯에 min-height가 예약되어 있는가
- [ ] 폰트 로딩이 렌더 차단 경로에 묶여 있는가
재측정
- [ ] 같은 URL, 같은 전략(모바일)으로 재실행
- [ ] 점수가 떨어졌으면 즉시 롤백
- [ ] 진단 원문이 사라졌는지 확인
Step 1 - 애드센스 쪽, 속도보다 우선
순서를 이렇게 잡는 이유가 있습니다. PSI 점수 99를 만들어도 콘텐츠가 부족하면 반려됩니다. 반대는 성립하지 않습니다.
가장 흔한 반려 사유인 low value content의 실제 원인들은 대개 서술형 텍스트 부족, 주제 분산, 빈 목록 200(soft-404)입니다. 표와 데이터만 많고 서술이 없으면 크롤러가 "가치 있는 본문"을 약하게 봅니다. 원예/금융/여행/개발을 한 블로그에서 다루면 깊이가 얕아집니다. 그리고 문서 0건 카테고리가 헤더와 푸터만 달고 200으로 열리면 심사와 색인이 같이 나빠집니다.
이 셋이 해결되지 않았다면 오늘 PSI는 돌리지 마세요. 순서가 아닙니다.
⚠️ 주의: 속도 점수를 위해 콘텐츠를 지우거나 광고를 숨기는 편법은 정책 리스크입니다. 심사 통과가 목적이면 더 위험합니다.
Step 2 - LCP를 4구간으로 쪼개기
LCP가 느릴 때 "이미지를 압축하자"가 첫 반응이라면, 상당수는 헛수고입니다. 구글 공식 가이드는 LCP를 네 구간으로 분해합니다. 이 네 구간을 더하면 정확히 LCP가 됩니다.
| 구간 | 내용 | 이상적 비율 |
|---|---|---|
| TTFB | 첫 바이트를 받기까지 | 약 40% |
| Resource load delay | TTFB 후 LCP 리소스 로드 시작까지 | 10% 미만 |
| Resource load duration | LCP 리소스 다운로드 시간 | 약 40% |
| Element render delay | 리소스 완료 후 실제 렌더까지 | 10% 미만 |
delay가 붙은 두 구간은 0에 가까울수록 좋습니다. 여기가 크면 문제는 압축이 아니라 "늦게 시작"하거나 "다 받았는데 못 그리는 구조"입니다.
이미지를 WebP나 AVIF로 바꿔 load duration을 줄여도, 그 시간이 render delay로 옮겨가면 LCP는 그대로일 수 있습니다. 그래서 LCP 요소와 네 구간을 같이 봐야 합니다.
LCP 리소스가 JS로 동적으로 추가되거나, data-src 뒤에 숨어 있거나, CSS background-image에만 있으면 preload scanner가 늦게 발견합니다. 뷰포트 안 LCP 이미지에는 loading="lazy"를 걸지 말고, 필요한 경우 fetchpriority="high"를 제한적으로 씁니다.
Step 3 - TBT, 가장 무거운데 가장 안 보는 것
배점 30%, 제일 큽니다. 그런데 폰트 최적화 글에서는 거의 안 다룹니다.
TBT는 메인 스레드를 50ms 넘게 막은 작업들의 초과분 합계입니다. 콘텐츠 블로그에서는 광고 스크립트, 애널리틱스, 댓글 위젯, 소셜 임베드, 무거운 테마 JS가 주범인 경우가 많습니다.
PSI 진단의 "메인 스레드 작업 최소화"와 "긴 작업 피하기"를 보면 파일 이름이 드러납니다. 여기서 해당 스크립트를 제거할 수 있는지, 늦출 수 있는지, 조건부로만 로드할 수 있는지 순서로 판단하세요.
필드 지표로는 INP(Interaction to Next Paint) 가 중요합니다. 2024년 3월부터 FID를 대신하는 Core Web Vital입니다. 랩에서는 TBT, 실제 사용자에서는 INP를 함께 보는 감각이 필요합니다.
위처럼 점수보다 먼저 상단 진단과 세부 지표를 같이 봐야 합니다. 한 번의 숫자보다, 어떤 진단이 사라졌는지가 더 재현 가능한 결과입니다.
Step 4 - 광고와 CLS
CLS 배점은 25%입니다. 애드센스를 붙인 사이트에서 CLS를 망치는 주범은 거의 항상 광고 슬롯입니다.
광고가 로드되면서 공간을 차지하면 아래 콘텐츠가 밀립니다. 사용자가 읽던 문장이 아래로 튀고, 링크를 누르려던 손가락이 광고를 누르게 됩니다.
해법은 공간 예약입니다. 광고 슬롯에 예상되는 최대 크기 기준으로 min-height 또는 aspect-ratio를 예약하세요.
.ad-slot {
min-height: 280px;
min-width: 300px;
}
.ad-slot-responsive {
aspect-ratio: 300 / 250;
}핵심은 작은 광고 기준이 아니라 가장 크게 올 수 있는 크기로 예약하는 겁니다.
그리고 원문에 있던 "광고 스크립트를 window load 이후로 미루자"는 조언은 주의가 필요합니다. Auto ads를 쓰거나, 반응형 광고 유닛의 크기를 예약하지 않은 상태라면 늦게 들어온 광고가 이미 그려진 레이아웃을 밀어 CLS를 더 악화시킬 수 있습니다. 심지어 수익이 흔들릴 수도 있습니다.
즉, blanket 지연이 아니라 공간 예약 먼저, 그 다음 실제 CLS 재측정 순서로 봐야 합니다.
폰트 함정 - 800을 700으로 바꿨는데 왜 그대로인가
이 글에서 실무 사례로 남길 만한 지점은 여기입니다.
증상은 이렇습니다. ExtraBold를 없애려고 CSS의 font-weight: 800과 900을 전부 700으로 바꿨습니다. 그런데 네트워크 탭을 보니 ExtraBold 폰트 파일이 여전히 내려옵니다.
원인은 CSS 어딘가에 850, 950 같은 값이 남아 있기 때문입니다. font-weight는 100부터 900까지 임의 정수를 받습니다. 브라우저는 850을 만나면 가장 가까운 무게의 페이스를 다시 가져옵니다.
올바른 접근은 두 단계입니다.
rg "font-weight:\\s*[0-9]{3}" ./src
rg "@font-face" ./src -n쓰지 않는 weight의 @font-face 선언 자체를 지우고, 그 다음 네트워크 워터폴에서 실제 다운로드가 사라졌는지 확인합니다.
글로벌 CSS가 렌더를 막는 동안 @font-face가 안에 있으면 폰트까지 크리티컬 체인에 묶입니다. 그래서 fonts.css로 분리하고 비동기로 로드하는 방식이 실제로 효과를 냈습니다.
font-display: swap이나 optional을 의도적으로 고르고, 한글 폰트는 가능하면 서브셋이나 weight 축소를 같이 검토하세요.
AI에게 던질 요청문
점수 숫자만 던지면 AI는 캐시 헤더나 이미지 압축부터 만지기 쉽습니다. 진단 원문이 계약서입니다.
목표: PSI 모바일 랩에서 [진단 원문 그대로]를 제거한다.
현재 측정값
- 성능 __ / FCP __ / LCP __ / TBT __ / CLS __
- LCP 요소: [PSI 진단에서 확인한 요소]
- LCP 4구간: TTFB __ / load delay __ / load duration __ / render delay __
PSI 진단 원문
- ...
제약
- 관련 없는 대규모 리팩터 금지
- 광고 슬롯의 min-height 예약은 제거하지 말 것
- 변경 파일은 3개 이하
작업 지시
1. 먼저 원인을 특정하고 나에게 확인받은 뒤 수정할 것
2. font-weight는 800/900뿐 아니라 850/950 등 세 자리 숫자 전수 검색
3. 매칭되는 @font-face가 실제로 다운로드되는지 네트워크 기준으로 보고
검증
- 배포 후 동일 URL, 동일 전략(모바일)으로 재실행
- 진단 원문이 사라졌는지 확인이 한 줄이 중요합니다. "먼저 원인을 특정하고 확인받은 뒤"를 넣지 않으면 추측성 수정이 여러 파일로 퍼지기 쉽습니다.
재측정과 롤백
하루에 진단 하나만 고치세요. 두 개를 동시에 고치고 점수가 떨어지면 어느 쪽이 원인인지 알기 어렵습니다.
재측정은 같은 URL, 같은 전략으로 합니다. 그리고 두세 번 돌려 중앙값을 보세요. 광고가 붙은 페이지는 서빙되는 광고에 따라 점수가 흔들립니다.
성공 기준은 점수가 아니라 진단 원문이 사라졌는지입니다. 특히 이미 90대라면 점수 차이는 작게 보일 수 있습니다.
| 증상 | 원인 | 대응 |
|---|---|---|
| 800→700 했는데 ExtraBold가 여전히 내려옴 | 850/950 잔존 또는 @font-face 미삭제 | weight 전수 검색, 선언 삭제 |
| 이미지 압축했는데 LCP 그대로 | 줄어든 시간이 render delay로 이동 | 4구간 분해 후 delay 확인 |
| 미사용 JS를 줄였는데 점수 그대로 | 메인 스레드 차단이 아니었음 | TBT 롱태스크 상위 항목 재타깃 |
| 광고 지연 후 CLS 악화 | 공간 예약 없이 지연 | min-height 예약 먼저, Auto ads면 재측정 |
| 필드 데이터가 URL과 다름 | 오리진 단위 데이터 표시 중 | PSI 상단에서 URL/Origin 확인 |
출처와 링크
- PageSpeed Insights
- About PageSpeed Insights
- Lighthouse performance scoring
- Optimize Largest Contentful Paint
- Interaction to Next Paint
- Minimize Layout Shift
- Effectively loading ads without impacting page speed
- Google Fonts best practices
- AdSense 자격 요건
- 필수 콘텐츠 및 고지
조사 기준: 2026년 7월. 랩 점수는 흔들리므로 진단 원문 제거 여부를 성공 기준으로 두세요. Lighthouse 버전이 바뀌면 배점부터 다시 확인하세요.
FAQ
자주 묻는 질문
PSI 점수 몇 점이면 애드센스 심사에 안전한가요?
점수 기준선이 따로 있는 것은 아닙니다. 핵심은 가치 있는 콘텐츠와 정책 준수입니다. 다만 빈 목록 200, 느린 첫 화면, 과도한 서드파티는 심사와 색인, 이탈을 함께 나쁘게 만들 수 있습니다.
필드 데이터가 데이터 없음이면 문제인가요?
신규 사이트나 저트래픽 사이트에서는 흔한 상태입니다. CrUX 표본이 쌓이기 전까지는 랩 데이터로 병목을 먼저 정리하면 됩니다. 필드가 없다고 점검을 미룰 필요는 없습니다.
TBT와 INP 중 무엇을 더 봐야 하나요?
랩에서 점수를 움직이는 건 TBT이고, 실제 사용자 경험에서는 INP가 중요합니다. 둘 다 메인 스레드 문제와 연결되므로 같이 보는 편이 안전합니다. 다만 상호작용 이후에만 무거워지는 위젯은 TBT보다 INP에서 더 크게 드러날 수 있습니다.
광고를 늦게 붙이면 점수가 잘 나오는데 그렇게 하면 안 되나요?
무조건 지연이 정답은 아닙니다. Auto ads나 크기 미지정 반응형 광고는 늦게 들어오며 CLS를 더 흔들 수 있습니다. 공간 예약을 먼저 하고, 그 상태로 다시 측정해 판단하세요.
폰트 weight만 800에서 700으로 바꾸면 끝인가요?
그렇게 끝나지 않는 경우가 많습니다. 850이나 950 같은 잔존 값, 그리고 남아 있는 @font-face 선언 때문에 ExtraBold 다운로드가 계속될 수 있습니다. 숫자 전수 검색과 네트워크 확인까지 같이 봐야 합니다.
하루에 진단을 몇 개까지 고치나요?
처음에는 한 번에 하나만 고치는 편이 좋습니다. 두 개 이상 동시에 바꾸면 어느 수정이 점수와 진단에 영향을 줬는지 구분하기 어렵습니다. 재측정도 같은 URL과 같은 전략으로 맞춰야 비교가 됩니다.
RELATED TERMS
본문과 함께 보면 좋은 사전 용어
사용자 인증 정보를 JSON 형태로 안전하게 전달하기 위한 토큰 표준(RFC 7519)으로, 서버가 세션 상태를 저장하지 않는 무상태(stateless) 인증 방식이다. 토큰은 헤더(알고리즘·타입), 페이로드(사용자 정보·만료시간), 서명(위변조 방지) 세 부분으로 구성되며, Base64URL로 인코딩되어 점(.)으로 연결된다. AI에게 '로그인 API 만들어줘'라고 하면 높은 확률로 JWT 기반 인증 코드를 생성하는데, 이는 JWT가 구현이 비교적 간단하고 서버리스 환경과 궁합이 좋기 때문이다. 그러나 AI 생성 JWT 코드에서 자주 발생하는 문제들이 있다: 토큰 만료 시간을 설정하지 않거나 지나치게 길게 설정, 리프레시 토큰(refresh token) 메커니즘 누락, httpOnly·secure 쿠키 대신 localStorage에 저장(XSS 취약), 토큰 무효화(로그아웃 시 서버 측 블랙리스트) 미구현, 비밀 키를 코드에 하드코딩 등. 이러한 보안 누락은 AI Slop의 전형적 사례이며, JWT를 사용할 때는 반드시 인간이 보안 측면을 검토해야 한다.
브라우저·노코드 빌더 볼트.뉴StackBlitz 팀이 개발한 비주얼 퍼스트(visual-first) 바이브 코딩 플랫폼으로, 빠른 프론트엔드 개발에 최적화되어 있다. 가장 큰 강점은 즉각적인 시각적 피드백으로, 자연어로 요청하면 코드가 생성됨과 동시에 라이브 프리뷰에서 결과를 바로 확인할 수 있다. '랜딩 페이지를 만들어줘'라고 입력하면, 코드가 작성되는 과정을 실시간으로 보면서 프리뷰 화면에서 결과가 렌더링되는 것을 동시에 볼 수 있어, 개발 경험이 없는 사용자도 'AI가 코드를 만드는 과정'을 직관적으로 이해할 수 있다. StackBlitz의 WebContainers 기술을 활용하여 브라우저 내에서 전체 Node.js 환경을 실행하므로, 서버 사이드 코드도 브라우저에서 직접 동작한다. 원클릭 배포를 지원하여 결과물을 즉시 공유할 수 있다. v0가 UI 컴포넌트에 특화되어 있다면, Bolt.new는 랜딩 페이지, 마케팅 사이트, 간단한 웹 앱 등 '완성된 페이지' 단위의 빠른 제작에 더 적합하다.
프롬프트 엔지니어링 프롬프트 템플릿반복해서 쓰는 AI 작업 지시를 일정한 칸으로 나누어 재사용하는 프롬프트 형식이다. 초보자는 매번 즉흥적으로 '이 기능 만들어줘'라고 쓰기보다, 목표, 현재 파일, 입력 자료, 제약 조건, 원하는 출력 형식, 검증 방법을 같은 순서로 채우면 AI가 누락 없이 코딩 작업을 수행하기 쉽다. 특히 VIBE 코딩에서는 템플릿이 작업 범위를 고정하는 안전장치가 된다. 예를 들어 버그 수정 템플릿에 재현 단계, 기대 동작, 실제 동작, 실패한 테스트, 수정 금지 파일을 넣으면 AI가 엉뚱한 리팩토링으로 번지는 일을 줄일 수 있다. 좋은 템플릿은 길기만 한 문서가 아니라, 사람과 AI가 함께 확인해야 할 결정 지점을 빠뜨리지 않게 해주는 체크리스트에 가깝다.
USEFUL LINKS
실제로 이어서 열어볼 즐겨찾기
Google이 종료한 서비스와 제품을 한눈에 모아, 플랫폼 의존성과 제품 지속성 리스크를 판단하게 해 주는 ‘Google 묘지’ 아카이브입니다.
VIBE 코딩 보안 테이텀 시큐리티 Threads쉬운 보안을 지향하는 한국어 보안 계정으로, AI·VIBE 코딩 흐름에서 놓치기 쉬운 보안 감각을 되짚는 데 유용합니다.
VIBE 코딩 레퍼런스 웹사이트 해부도 · Website Anatomy MapAI와 웹사이트를 함께 만들 때 ‘그 부분’이 아니라 정확한 UI·웹 용어로 지시할 수 있게 돕는 영-한 시각 사전입니다.