VibeCoding 365 심층 학습 가이드
구글 애드센스 블로그 및 사이트 무조건 체크 | 웹페이지 스피드 테스트 - 구글 공식
PSI 모바일 랩 → 폰트 비동기 분리 → AI 수정 프롬프트까지 한 세션
- 핵심 주제
- AdSense PageSpeed Insights Checklist
- 예상 시간
- 12분
- 업데이트
- 2026.07.23
- 키워드
- PageSpeed Insights · 애드센스 · 웹페이지 스피드
문제 신호
애드센스 심사를 넣기 직전, 또는 반려 메일을 받은 뒤, 광고 코드만 만지작거리는 경우가 많다. 정작 공개 URL을 열어 보면 카테고리·목록 페이지가 헤더·푸터만 있고, 모바일은 첫 페인트까지 수 초가 걸린다. PageSpeed Insights(이하 PSI)를 돌리면 성능이 50~80대에 머물고, 「렌더링을 차단하는 요청」「사용하지 않는 CSS」「웹폰트」가 상단에 쌓인다.
점수가 낮다고 무조건 반려되는 것은 아니다. 구글 게시자 정책의 핵심은 가치 있는 콘텐츠·정책 준수 쪽이다. 다만 빈 목록·느린 첫 화면·과도한 서드파티는 심사·색인·이탈이 한 묶음으로 나빠지기 쉽다. 그래서 심사 전에 공식 PSI를 한 세션으로 끝내는 루프를 고정한다.
이 글은 백과사전형 속도론이 아니다. 오늘 한 사이트 URL을 고르고, 모바일 랩을 돌리고, 진단 1~2개를 고쳐서 재측정까지 가는 바이브코딩 세션이다. 실측 사례에서는 모바일 성능이 80 → (잘못된 수정으로) 50대 → 폰트 비동기 분리 후 99까지 올라간 루프를 기준으로 적는다. 실서비스 도메인명은 적지 않는다.
30초 판정
| 지금 상황 | 오늘은 패스 | 오늘 PSI 세션 |
|---|---|---|
| 홈·카테고리에 문서 0건 페이지가 200으로 열림 | — | ✅ 먼저 soft-404부터 |
| 광고 스크립트만 바꾸고 본문은 그대로 | ❌ | ✅ 콘텐츠·속도 같이 |
| PSI 없이 「대충 빠르겠지」 | ❌ | ✅ 공식 랩 1회 |
| 성능 90+인데 개인정보·ads.txt만 비어 있음 | 속도는 보류 | 정책 페이지 우선 |
| CrUX(필드) 데이터 없음·랩만 있음 | 정상(신규 흔함) | ✅ 랩으로 병목부터 |
도구는 구글 공식 PageSpeed Insights다. 주소창에 pagespeed.web.dev를 열고 URL을 넣는다. 모바일·데스크톱을 나눠 보고, 랩(Lighthouse) 과 필드(실제 사용자·CrUX) 를 구분한다. 신규·트래픽 적은 사이트는 필드가 「데이터 없음」이어도 이상하지 않다. 그때는 랩 진단으로 고친다.
짧게만 외운다.
- FCP: 첫 텍스트·이미지 페인트. 폰트·CSS 차단에 민감.
- LCP: 가장 큰 콘텐츠. 히어로·큰 이미지·웹폰트 체인.
- TBT: 메인 스레드 차단(랩). 무거운 JS·동기 서드파티.
- CLS: 레이아웃 밀림. 광고·이미지 크기 미지정.
- SI: 시각적 완성 속도 감각.
점수는 추정치다. 같은 URL도 시간대·캐시·광고 응답에 따라 몇 점 흔들린다. 세션 성공 기준은 한 번의 숫자보다, 상단 진단 문구를 고쳤는지다.
최소 루프
애드센스·블로그·콘텐츠 사이트 공통으로, 아래만 먼저 통과시킨다.
- 공개 URL 3종을 적어 둔다. 홈, 대표 글 1개, 카테고리·목록 1개.
- 각 URL이 빈 본문 200이 아닌지 확인한다. 문서 0건이면 404(+가능하면
noindex)로 바꾸고, 내비·칩에서 링크를 뺀다. - PageSpeed Insights에 모바일로 홈(또는 대표 랜딩)을 넣는다.
- 성능·접근성·권장사항·SEO 네 칸과, FCP/LCP/TBT/CLS를 스크린샷으로 남긴다.
- 「개선할 항목」에서 1순위 1개만 고른다. 대개 렌더 차단 CSS, 웹폰트, 미사용 JS, 이미지다.
- AI에게 고칠 때는 점수 숫자만 보내지 말고, 진단 문구 + 파일 경로 후보 + 제약을 붙인다(다음 절 템플릿).
- 배포 후 같은 URL·같은 전략(모바일)으로 재측정한다. 점수가 떨어지면 롤백 후보를 먼저 본다.
최소 성공 조건
- soft-404 후보 URL이 공개 내비에 없음
- PSI 모바일 1회 실행·스크린샷 저장
- 진단 1개 수정 → 재측정 1회레이스 레시피: PSI → AI 수정 → 99까지
실세션에서 겪은 순서를 그대로 옮긴다. 도메인은 생략하고, 증상 → 잘못된 수정 → 올바른 수정만 남긴다.
기준선 찍기
모바일 랩에서 성능이 대략 80대, FCP·LCP가 3~4초대면 「나쁘지 않은데 아쉬운」 구간이다. 접근성·SEO가 이미 높아도, 성능만 남으면 심사 전 체크리스트에 걸린다.
왼쪽·가운데는 개선 과정 스샷, 오른쪽은 같은 유형 URL을 폰트 비동기 분리까지 끝낸 뒤의 성능 99 결과다. 숫자가 목표가 아니라, 「진단이 사라졌는지」를 본다.
잘못된 수정이 점수를 깎는 패턴
「굵은 글씨(ExtraBold)를 쓰지 말자」고 font-weight: 800/900만 700으로 바꿨는데, CSS 어딘가에 850 / 950 같은 값이 남아 있으면 브라우저는 여전히 ExtraBold 페이스에 매칭한다. 한글·라틴 ExtraBold가 각각 수백 KiB로 다시 내려오고, 점수는 50대로 떨어질 수 있다.
AI에게 「800/900만 찾아」라고 하면 이 함정에 빠진다. 요청문에 모든 numeric weight · @font-face 목록 · 실제 네트워크 워터폴을 넣어야 한다.
결정타: 폰트를 렌더 차단 경로에서 분리
글로벌 CSS가 렌더를 막는 동안 그 안에 @font-face가 있으면, 브라우저는 폰트까지 크리티컬 체인에 묶는다. PSI에 「렌더링 차단 요청 예상 절감 N초」가 크게 잡히면 여기다.
실무 레시피:
@font-face만fonts.css(이름은 자유)로 분리한다.- 레이아웃에서 폰트 CSS를 비동기로 건다. 흔한 패턴:
<link
rel="stylesheet"
href="/path/to/fonts.css"
media="print"
onload="this.media='all'"
/>
<noscript><link rel="stylesheet" href="/path/to/fonts.css" /></noscript>--font-sans등에 시스템 폴백을 먼저 둔다. 첫 페인트는 시스템 글꼴, 웹폰트는 이후 swap.- UI weight는 Regular/Bold 중심으로 줄인다. 안 쓰는 SemiBold·ExtraBold
@font-face는 삭제한다. - 한글 CJK는 용량이 크므로
font-display: optional또는swap을 의도에 맞게 고른다. 느린 4G 랩에서는 optional이 FCP에 유리한 경우가 많다.
광고·서드파티는 첫 페인트 뒤로
애드센스 스크립트를 <head>에 즉시 넣으면 TBT·메인 스레드·연결 경쟁이 커진다. 세션에서는 다음을 기본값으로 둔다.
windowload이후 삽입- 가능하면
requestIdleCallback(없으면setTimeout)으로 한 박자 더 미룸 - 초기
preconnect가 과하면dns-prefetch로 완화 검토
승인 전 계정은 콘솔 403이 남을 수 있다. 그건 성능 점수와 별개로 두고, 스크립트 타이밍만 정리한다.
AI에게 이렇게 수정 요청한다
복붙 템플릿:
목표: PageSpeed Insights 모바일 랩에서 [진단명]을 제거하거나 크게 줄인다.
URL: (재현용 공개 URL — 채팅에 민감 도메인을 올리기 싫으면 「홈 랜딩」으로만 표기)
전략: mobile
현재 점수: 성능 __ / FCP __ / LCP __ / TBT __ / CLS __
PSI 상단 진단 (원문 붙여넣기):
- ...
제약:
- 관련 없는 대규모 리팩터 금지
- 디자인 톤(브랜드 폰트 가족)은 유지하되 weight·로딩 방식만 변경 가능
- 빈 목록 페이지는 200 유지 금지 → 404 + 내비 숨김
검증:
- 배포 후 동일 URL로 PSI 모바일 재실행
- 라이브 CSS에서 ExtraBold/@font-face 잔존 여부 grep
산출:
- 변경 파일 목록
- 왜 이 진단이 사라지는지 3줄추가로 효과가 좋았던 한 줄:
font-weight 숫자 전수(800/900뿐 아니라 850/950 등)를 검색하고,
매칭되는 @font-face가 실제로 다운로드되는지 네트워크 기준으로 보고해.「점수 90 만들어줘」만 던지면 AI는 캐시 헤더·이미지 CDN만 만지다 핵심 체인을 놓친다. 진단 원문이 세션의 계약서다.
애드센스와 같이 보는 비속도 체크
속도 세션과 같은 날 끝낼 항목이다. 점수가 아니어도 심사에서 먼저 걸린다.
- 문서 있는 URL만 내비·사이트맵에 노출
- 개인정보처리방침·쿠키·광고 고지
ads.txt·소유권 확인- 대량 생성처럼 보이는 중복·빈 템플릿 페이지 정리
- HTTPS·가능하면 HSTS
PSI SEO·권장사항 칸이 높아도, 빈 카테고리 200이 남아 있으면 품질 이슈는 그대로다.
머지 전 검수
- [ ] 홈·글·목록 URL 각각 본문이 실제로 있는가
- [ ] soft-404 후보가 404(또는 유사)로 바뀌고 내비에서 빠졌는가
- [ ] PSI 모바일 기준선·수정 후 스크린샷이 있는가
- [ ]
@font-face가 렌더 차단 CSS에서 분리됐는가 - [ ] UI
font-weight에 800/900/850/950 잔존이 없는가 - [ ] 광고 스크립트가 load/idle 이후로 미뤄졌는가
- [ ] AI 프롬프트에 진단 원문·제약이 포함됐는가
- [ ] 재측정에서 점수가 크게 떨어지지 않았는가(떨어지면 롤백)
깨지는 지점
| 증상 | 원인 | 대응 |
|---|---|---|
| 800→700 했는데 ExtraBold 다운로드 | 850/950 등 잔존 weight | weight 전수 검색 + face 삭제 |
| 폰트 분리 후에도 FCP 붕괴 | 글로벌 CSS에 face 재유입·번들 합침 | 빌드 산출물 grep |
| 점수가 오르락내리락 | 광고·A/B·캐시·랩 변동 | 동일 전략 2회, 진단 유무로 판정 |
| 필드 데이터 없음 | 트래픽·CrUX 미수집 | 랩으로 진행, 필드만 기다리지 말 것 |
| 성능 99인데 심사 반려 | 콘텐츠·정책 이슈 | 빈 페이지·저가치·정책 문서 재점검 |
| AI가 디자인 전체 리라이트 | 제약 없음 | 「로딩·weight만」 명시 |
FAQ
PageSpeed 점수가 높으면 애드센스가 무조건 통과하나요? 아닙니다. 게시자 정책·콘텐츠 가치가 본선입니다. PSI는 심사 전 UX·기술 부채를 줄이는 공식 체크에 가깝습니다.
모바일만 보면 되나요? 심사·검색 모두 모바일 비중이 큽니다. 먼저 모바일 랩을 고치고, 여유 있으면 데스크톱을 봅니다.
필드(실제 사용자) 데이터가 없으면 무의미한가요? 신규·저트래픽이면 흔합니다. 랩 진단으로 병목을 제거하고, 필드가 쌓이면 다시 확인하면 됩니다.
웹폰트를 없애야만 하나요? 필수는 아닙니다. Regular/Bold로 줄이고, 렌더 차단 경로에서 빼며, 폴백을 두면 브랜드 글꼴을 유지한 채 점수를 올릴 수 있습니다.
AI에게 코드베이스 전체를 줘도 되나요? 가능하지만, PSI 진단 원문·의심 파일·제약을 먼저 넣는 편이 빠르고 안전합니다. 「점수만」 요청은 피합니다.
다음에
- 오늘: soft-404 정리 → PSI 모바일 1회 → 폰트/차단 CSS 1건 → 재측정.
- 배포·스모크 루프는 /vibe-coding/deployment-smoke-ai-coding-loop를 이어서 보면 맞다.
- 링크 미리보기·OG는 /vibe-coding/dynamic-og-image-link-preview-guide.
- 용어·CWV 보강은 /vibe-dictionary.
- 공식 도구: PageSpeed Insights · web.dev Core Web Vitals.
자주 묻는 질문
PageSpeed 점수가 높으면 애드센스가 무조건 통과하나요?
아닙니다. 게시자 정책·콘텐츠 가치가 본선입니다. PSI는 심사 전 UX·기술 부채를 줄이는 공식 체크에 가깝습니다.
모바일만 보면 되나요?
심사·검색 모두 모바일 비중이 큽니다. 먼저 모바일 랩을 고치고, 여유 있으면 데스크톱을 보면 됩니다.
필드(실제 사용자) 데이터가 없으면 무의미한가요?
신규·저트래픽이면 흔합니다. 랩 진단으로 병목을 제거하고, 필드가 쌓이면 다시 확인하면 됩니다.
웹폰트를 없애야만 하나요?
필수는 아닙니다. Regular/Bold로 줄이고 렌더 차단 경로에서 빼며 폴백을 두면 브랜드 글꼴을 유지한 채 점수를 올릴 수 있습니다.
AI에게 코드베이스 전체를 줘도 되나요?
가능하지만 PSI 진단 원문·의심 파일·제약을 먼저 넣는 편이 빠르고 안전합니다. 점수만 요청하는 방식은 피하세요.
Related terms
본문과 함께 보면 좋은 사전 용어
2025년 2월, OpenAI 공동 창립자이자 전 테슬라 AI 리더인 Andrej Karpathy가 X(구 트위터)에서 처음 사용한 용어로, AI에게 자연어로 원하는 결과를 설명하면 AI가 코드를 생성하고, 개발자는 생성된 코드를 세밀히 검토하지 않고 결과(동작 여부)에 의존하여 개발을 진행하는 방식을 뜻한다. Karpathy의 원문 표현을 빌리면 '바이브에 완전히 몸을 맡기고, 코드가 존재한다는 사실 자체를 잊는' 접근법이다. Cursor, Claude Code, Copilot 같은 AI 코딩 도구가 급속히 발전하면서, 비개발자도 프로토타입이나 간단한 앱을 만들 수 있게 된 현상을 상징하는 말로 확산되었다. 2025년 Collins Dictionary가 '올해의 단어'로 선정할 만큼 대중적 인지도를 얻었다. 다만 전문 개발 현장에서는 코드 품질·보안·유지보수 측면의 위험이 지적되며, Andrew Ng 등은 프로덕션 환경에서의 무비판적 바이브 코딩에 대해 경고하기도 했다. 바이브 코딩은 AI 보조 코딩의 스펙트럼에서 가장 자율도가 높은 끝에 위치하며, 플랜 모드나 코드 리뷰를 결합하는 '책임 있는 바이브 코딩' 논의로 이어지고 있다.
IDE·AI 어시스턴트제드Rust 프로그래밍 언어로 처음부터 작성된 고성능 코드 편집기로, Atom 에디터의 창시자들이 만들었다. 네이티브 속도가 가장 큰 강점으로, Electron 기반(VS Code, Cursor, Windsurf 등)의 에디터보다 파일 열기, 검색, 렌더링 등 모든 작업에서 체감 가능한 속도 차이를 보인다. 네이티브 AI 어시스턴트를 내장하여 코드 선택 후 AI에게 리팩토링이나 설명을 요청할 수 있으며, 실시간 멀티플레이어 협업(동시 편집)도 핵심 기능이다. 2026년 3월에는 ACP(Agent Context Protocol) Registry에 합류하여 에이전틱 워크플로를 지원하기 시작했다. 현재 macOS와 Linux를 공식 지원하며 Windows 지원은 개발 중이다. AI 기능 자체는 Cursor나 Windsurf에 비해 아직 성숙도가 낮지만, 속도에 민감한 개발자나 대규모 코드베이스를 다루는 환경에서 주목받고 있다. 오픈소스 프로젝트로 커뮤니티 기여가 활발하다.
브라우저·노코드 빌더볼트.뉴StackBlitz 팀이 개발한 비주얼 퍼스트(visual-first) 바이브 코딩 플랫폼으로, 빠른 프론트엔드 개발에 최적화되어 있다. 가장 큰 강점은 즉각적인 시각적 피드백으로, 자연어로 요청하면 코드가 생성됨과 동시에 라이브 프리뷰에서 결과를 바로 확인할 수 있다. '랜딩 페이지를 만들어줘'라고 입력하면, 코드가 작성되는 과정을 실시간으로 보면서 프리뷰 화면에서 결과가 렌더링되는 것을 동시에 볼 수 있어, 개발 경험이 없는 사용자도 'AI가 코드를 만드는 과정'을 직관적으로 이해할 수 있다. StackBlitz의 WebContainers 기술을 활용하여 브라우저 내에서 전체 Node.js 환경을 실행하므로, 서버 사이드 코드도 브라우저에서 직접 동작한다. 원클릭 배포를 지원하여 결과물을 즉시 공유할 수 있다. v0가 UI 컴포넌트에 특화되어 있다면, Bolt.new는 랜딩 페이지, 마케팅 사이트, 간단한 웹 앱 등 '완성된 페이지' 단위의 빠른 제작에 더 적합하다.
Useful links
실제로 이어서 열어볼 즐겨찾기
AI와 웹사이트를 함께 만들 때 ‘그 부분’이 아니라 정확한 UI·웹 용어로 지시할 수 있게 돕는 영-한 시각 사전입니다.
VIBE 코딩 보안테이텀 시큐리티 Threads쉬운 보안을 지향하는 한국어 보안 계정으로, AI·VIBE 코딩 흐름에서 놓치기 쉬운 보안 감각을 되짚는 데 유용합니다.
VIBE 코딩 제품 리서치Killed by Google · Google GraveyardGoogle이 종료한 서비스와 제품을 한눈에 모아, 플랫폼 의존성과 제품 지속성 리스크를 판단하게 해 주는 ‘Google 묘지’ 아카이브입니다.
다음 학습
같은 섹션에서 이어 읽기 좋은 콘텐츠
바이브코딩 애드센스 부업 | 간접 수익화와 개인정보·보안 최소 루프
문제 신호
바이브코딩으로 「부업 사이트」를 만들 때 첫 프롬프트가 종종 이렇게 시작한다. 회원가입, 문의폼, 결제, 관리자 대시보드까지 한 번에. 화면은 빨리 나오지만, 그 순간부터 주문·환불·고객 DB·API 키·로그에 쌓인 이메일이 운영자 책임이 된다.
애드센스 부업의 본체는 상품을 직접 파는 일이 아니다. 유용한 콘텐츠로 방문을 모은 뒤, 광고 지면을 통해 수익을 받는 간접 수익화다. Google이 광고 매칭과 정산을 담당하고, 게시자는 콘텐츠·정책·트래픽 품질을 지킨다(How AdSense works).
진짜 쉬운 바이브 코딩 | 쌩초보는 그냥 이거 보자
바이브 코딩, 어디서부터 시작해야 할지 막막하다는 분들이 정말 많습니다. 코딩을 한 번도 안 해본 사람이 "AI한테 시켜서 웹사이트를 만든다"는 말을 들으면 거창하게 느껴지죠. 그런데 막상 시작 지점은 의외로 단순합니다. 깔아야 할 건 딱 두 개, 외워야 할 흐름은 한 줄로 끝납니다.
이 글은 완전 초보가 자기 컴퓨터에서 첫 결과물을 띄우기까지의 과정을 그대로 따라갈 수 있게 정리한 가이드입니다. 어려운 이론은 빼고, "이거 눌러라, 저거 쳐라" 수준으로 갑니다.
▶ 이 글의 전 과정을 영상으로 한 번에 보고 싶다면? 위 썸네일을 누르면 영상으로 바로 이동해요. 설치부터 첫 앱 완성까지 모든 과정이 1시간 40분짜리 멤버십 영상 하나에 풀버전으로 담겨 있습니다. 글로 큰 흐름을 잡고, 막히는 구간만 영상으로 따라오면 훨씬 빨라…