워드프레스 속도 개선, 38점에서 시작한 비전공자의 3주 기록

2026년 08월 06일

PageSpeed Insights를 처음 돌렸을 때 모바일 38점이 뜨더라고요. 빨간색 원 안에 숫자 하나. 그 아래로 “렌더링 차단 리소스 제거”, “서버 응답 시간 단축” 같은 문장이 줄줄이 떴는데, 솔직히 무슨 말인지 하나도 몰랐어요. 그래서 찾아본 글들은 대부분 “캐시 플러그인 깔면 됩니다”로 끝났고요.

결론부터 말하면, 워드프레스 속도 개선은 플러그인 하나로 끝나지 않고 이미지 → 캐시 → 플러그인 정리 → 서버 설정 순서로 손보는 게 효과가 가장 큽니다. 이 순서가 중요한 이유는 앞쪽 항목일수록 코딩이 필요 없고, 실패해도 되돌리기 쉽고, 점수 상승폭이 크기 때문이에요.

이 글은 완성된 최적화 매뉴얼이 아니라 실습 일지예요. 3주 동안 하나씩 바꾸면서 점수가 어떻게 움직였는지, 어디서 사이트를 깨먹고 어떻게 되돌렸는지 그대로 적었어요. 코딩 모르는 상태로 시작했으니, 같은 자리에 계신 분이면 그대로 따라오실 수 있어요.

워드프레스 속도 개선, 왜 굳이 해야 하나요?

워드프레스 속도 개선

📌 핵심 요약

속도 개선은 이미지 → 캐시 → 플러그인 정리 → 서버 설정 순서로, 코딩이 필요 없고 되돌리기 쉬운 것부터 손대면 비전공자도 모바일 기준 30점대에서 80점대까지 올릴 수 있어요.

처음엔 저도 속도가 왜 중요한지 잘 몰랐어요. 내 블로그 글 몇 개, 방문자 하루 20명. 1초 빠르든 3초 느리든 무슨 차이가 있나 싶었죠.

생각이 바뀐 건 서치 콘솔의 코어 웹 바이탈 리포트를 보고 나서였어요. “개선이 필요한 URL”에 제 글 전체가 들어가 있더라고요. 구글은 페이지 경험을 순위 신호로 쓴다고 공식적으로 밝혀왔고, 특히 모바일에서 그 영향이 큽니다.

더 직접적인 건 이탈률이었어요. 애널리틱스에서 페이지 로딩 시간별로 나눠 보니, 3초 넘게 걸리는 글의 이탈률이 눈에 띄게 높았어요. 사람들은 로딩 스피너를 3초 이상 안 봐줍니다. 특히 검색으로 들어온 사람은 뒤로 가기 한 번이면 다른 글로 갈 수 있으니까요.

애드센스를 준비 중이라면 더 절실해요. 광고 스크립트 자체가 무겁기 때문에, 광고를 붙이는 순간 점수가 한 번 더 떨어져요. 광고 없이 60점인 사이트에 광고를 넣으면 40점대로 내려가는 걸 실제로 봤어요. 그래서 광고를 붙이기 전에 기초 체력을 만들어두는 편이 훨씬 편합니다.

💡 꼭 알아두세요

속도가 검색 순위를 끌어올려주는 마법은 아니에요. 콘텐츠 품질이 비슷할 때 갈리는 보조 신호에 가까워요. 다만 이탈률과 광고 노출 시간에는 즉각적으로 영향을 줘서, 글을 늘리는 것과 병행할 가치가 충분해요.

내 사이트가 지금 몇 점인지 어떻게 재나요?

측정 없이 개선하면 뭘 고쳤는지도, 나아졌는지도 알 수 없어요. 저는 두 가지 도구를 같이 썼어요.

PageSpeed Insights는 구글이 직접 제공하는 도구예요. 주소 넣고 분석 버튼 누르면 끝. 모바일과 데스크톱 점수를 따로 보여주는데, 반드시 모바일 점수를 기준으로 보세요. 구글의 색인도 모바일 우선이고, 실제 방문자 대부분도 모바일이에요. 제 사이트는 첫 측정에서 모바일 38점, 데스크톱 79점이 나왔어요. 데스크톱만 보면 “그럭저럭인데?” 싶지만 실상은 아니었던 거죠.

GTmetrix는 폭포수 차트(Waterfall)를 보여줘서, 어떤 파일이 몇 초 걸려 로딩되는지 순서대로 확인할 수 있어요. “점수가 낮다”가 아니라 “이 이미지 하나가 2.4초를 잡아먹는다”를 눈으로 보게 해주는 도구예요. 무료 계정은 측정 서버 위치가 제한되니, 한국 방문자 기준 절대 시간보다는 개선 전후 비교용으로 쓰는 게 좋아요.

점수 숫자 자체보다 중요한 건 아래 세 지표예요.

지표 쉽게 말하면 권장 기준
LCP 첫 화면 큰 이미지·제목이 뜨는 시각 2.5초 이내
CLS 읽는 도중 레이아웃이 밀리는 정도 0.1 이하
TTFB 서버가 첫 응답을 주기까지 걸린 시간 0.8초 이내

제 첫 측정값은 LCP 6.1초, CLS 0.31, TTFB 1.9초였어요. 세 개 다 기준 밖. 그런데 이 숫자들이 오히려 반가웠어요. 어디를 고쳐야 하는지 방향이 잡히거든요. LCP가 나쁘면 이미지, TTFB가 나쁘면 서버·캐시, CLS가 나쁘면 이미지 크기 지정이나 광고 영역 문제예요.

⚠️ 주의사항

같은 페이지를 연속으로 재면 점수가 5~10점씩 널뜁니다. 측정 서버 상태에 따라 흔들려요. 한 번 재고 좌절하지 말고, 3회 측정해서 중간값을 기록해두세요. 그리고 홈 화면 말고 글 하나를 고정해서 계속 같은 URL로 재야 비교가 됩니다.

느린 원인이 호스팅인지 내 설정인지 어떻게 구분하나요?

이게 제일 헷갈렸던 부분이에요. 호스팅이 구려서 느린 건지, 내가 플러그인을 20개 깔아놔서 느린 건지 알아야 돈을 쓸지 시간을 쓸지 정할 수 있잖아요.

판별 기준은 TTFB 하나예요. TTFB는 브라우저가 요청을 보내고 서버에서 첫 바이트가 돌아오기까지의 시간이라, 화면에 뭐가 그려지기 전 단계예요. 즉 이미지나 CSS와 무관하게 순수하게 서버가 PHP를 돌려 HTML을 만들어내는 데 걸린 시간이죠.

1

캐시를 끈 상태로 TTFB를 잰다

캐시가 켜져 있으면 서버 실력이 가려져요. 캐시 플러그인을 잠시 비활성화하고 GTmetrix로 TTFB를 확인하세요. 1.5초를 넘으면 서버 쪽 문제일 가능성이 큽니다.

2

기본 테마로 바꿔 다시 잰다

워드프레스 기본 테마로 전환하고 같은 URL을 재보세요. TTFB가 확 떨어지면 서버가 아니라 테마·페이지빌더가 범인이에요. 트래픽이 적은 새벽에 5분만 바꿔보면 됩니다.

3

플러그인을 절반씩 꺼보며 범인을 찾는다

전부 끄고 재고, 절반 켜고 재고, 또 절반. 이 방식으로 저는 백업 플러그인 하나가 관리자 화면을 0.7초씩 붙잡고 있던 걸 찾아냈어요. Query Monitor 같은 진단 플러그인을 쓰면 더 빠르지만, 손으로 해도 30분이면 됩니다.

관리자 페이지만 유독 느린 경우는 원인이 좀 달라요. 워드프레스 관리자 화면은 캐시가 적용되지 않는 구간이라 서버 성능이 그대로 드러나요. 여기에 하트비트(Heartbeat) API가 15~60초마다 서버를 두드리고, 대시보드 위젯들이 외부 요청을 날려요. 글 편집 화면에서 자동저장이 돌 때마다 버벅인다면 하트비트 주기 조절 플러그인을 써보면 체감이 달라집니다.

제 결론은 이랬어요. TTFB 1.9초 중 1.2초가 테마·플러그인, 0.7초가 서버 몫. 호스팅을 옮기는 대신 내 설정부터 정리하는 게 맞다는 판단이었죠. 실제로 호스팅을 옮겨야 하는 경우는 캐시를 끄고 기본 테마에 플러그인을 다 꺼도 TTFB가 1.5초 넘게 나올 때예요. 그건 서버가 감당을 못 하고 있다는 뜻이에요.

어떤 순서로 손봐야 효과가 제일 큰가요?

워드프레스 속도 개선

여기가 대부분의 글이 안 알려주는 부분이에요. “방법 7가지”는 많은데, 뭐부터 해야 하는지는 안 나와요. 저는 실제로 하나씩 적용하면서 점수 변화를 기록했고, 그 결과를 효과 순으로 정리하면 이렇게 됩니다.

순서 작업 내 사이트 점수 변화 코딩
1 이미지 리사이즈·WebP 변환 38 → 57 불필요
2 페이지 캐시 켜기 57 → 68 불필요
3 안 쓰는 플러그인 정리 68 → 73 불필요
4 CSS·JS 최소화, 웹폰트 정리 73 → 81 일부 필요
5 CDN 연결 81 → 84 불필요
6 PHP 버전 상향·DB 정리 84 → 86 불필요

이 순서를 추천하는 이유는 점수 상승폭 때문만은 아니에요. 앞쪽일수록 실패해도 안전하기 때문이에요. 이미지를 압축했다가 마음에 안 들면 원본을 다시 올리면 그만이고, 캐시는 껐다 켜면 됩니다. 반면 4번 CSS·JS 최소화는 사이트 레이아웃을 실제로 깨뜨릴 수 있어요. 저도 여기서 한 번 크게 넘어졌고, 그 얘기는 뒤에서 자세히 할게요.

그리고 5번 CDN을 낮게 둔 이유는, 개인 블로그처럼 방문자가 대부분 한국에 있는 경우 CDN의 효과가 제한적이기 때문이에요. 해외 유입이 많거나 이미지가 많은 사이트라면 순위가 올라가겠지만, 국내 독자 위주라면 무료 플랜으로 먼저 시험해보고 판단하는 걸 권해요.

💡 꼭 알아두세요

한 번에 여러 개를 동시에 바꾸지 마세요. 점수가 올라도 뭐가 효과였는지 모르고, 사이트가 깨져도 뭐가 범인인지 못 찾아요. 한 가지 → 측정 → 기록 → 다음 것. 저는 메모장에 날짜·작업·점수를 세 칸으로 적어뒀는데, 3주 뒤 이 글을 쓸 때 그 메모가 전부였어요.

이미지 최적화만으로 몇 점이나 오르나요?

제 경우 38점에서 57점. 하루 작업으로 19점이 올랐어요. 단일 작업 중 압도적으로 효과가 컸습니다.

이유는 단순해요. 제가 스마트폰으로 찍은 사진을 그대로 올리고 있었거든요. 한 장에 4.2MB. 그런데 블로그 본문 영역 너비는 800px 정도예요. 브라우저는 4032px짜리 이미지를 받아서 800px로 줄여 보여주고 있었던 거죠. 5MB를 받아서 5분의 1만 쓰는 셈이었어요.

고친 방법은 세 단계예요.

1

업로드 전에 가로 1600px으로 줄이기

본문 폭이 800px이라도 고해상도 화면을 고려해 2배인 1600px이면 충분해요. 맥은 미리보기, 윈도우는 그림판으로도 됩니다. 이것만으로 4.2MB가 600KB대로 떨어졌어요.

2

플러그인으로 WebP 자동 변환

EWWW Image Optimizer 무료 버전을 썼어요. 설치 후 WebP 변환을 켜고 기존 이미지 일괄 최적화를 돌리면, 이미 올린 사진들도 한꺼번에 처리돼요. 600KB가 다시 180KB 수준으로 내려갔습니다.

3

첫 화면 이미지는 지연 로딩에서 제외

지연 로딩은 화면 밖 이미지를 나중에 불러오는 기능인데, 맨 위 대표 이미지까지 미루면 오히려 LCP가 나빠져요. 캐시 플러그인 설정에서 첫 이미지 1장은 제외하도록 지정했더니 LCP가 0.6초 줄었어요.

많이 걱정하시는 게 화질인데, 저는 육안으로 차이를 못 느꼈어요. WebP는 같은 화질을 더 적은 용량으로 담는 포맷이라, 압축률을 80% 안팎으로 두면 블로그 사진 용도로는 충분해요. 다만 디자인 시안이나 제품 상세컷처럼 픽셀 단위가 중요한 이미지라면 압축률을 90%로 올리고 개별 확인하는 게 안전합니다.

⚠️ 주의사항

기존 이미지 일괄 최적화를 돌리기 전에 미디어 폴더 백업을 먼저 하세요. 원본 보관 옵션을 꺼둔 채 압축하면 되돌릴 방법이 없어요. 저는 호스팅 파일 관리자에서 uploads 폴더를 통째로 압축해 내려받은 뒤 실행했어요.

캐시 플러그인은 뭘 어떻게 설정해야 하나요?

캐시가 뭔지부터 짚고 갈게요. 워드프레스는 누가 페이지를 요청할 때마다 PHP를 실행하고 데이터베이스를 조회해서 HTML을 새로 만들어요. 방문자 100명이면 똑같은 작업을 100번 하는 거죠. 캐시는 완성된 HTML을 한 번 만들어 저장해두고 다음 사람에게 그대로 내주는 것이에요. 그래서 TTFB가 크게 줄어듭니다.

플러그인 선택은 사실 크게 고민할 필요가 없어요. 중요한 건 내 서버가 어떤 웹서버를 쓰느냐예요.

상황 추천 비용
호스팅이 LiteSpeed 서버 LiteSpeed Cache 무료
일반 Apache·Nginx, 설정 최소화 WP Fastest Cache 무료
세밀하게 조정하고 싶음 W3 Total Cache 무료
설정 고민 없이 맡기고 싶음 WP Rocket 유료(공식 사이트 확인)
클라우드웨이즈 사용 중 Breeze 무료

결론부터 말하면 개인 블로그는 무료로 충분해요. 유료 플러그인의 값어치는 기능보다 “설정 고민을 대신해준다”는 데 있어요. 시간을 아끼고 싶고 여러 사이트를 운영한다면 손익분기가 맞지만, 블로그 한 개라면 무료로 시작해서 부족함을 느낄 때 옮겨도 늦지 않아요.

제가 실제로 켠 항목은 이렇습니다. 처음엔 겁나서 페이지 캐시 하나만 켜고 이틀 지켜봤어요.

📋 내가 켠 캐시 설정

✓ 페이지 캐시 — 가장 먼저, 단독으로 켜기
✓ 브라우저 캐시 — 재방문자 속도 개선, 부작용 거의 없음
✓ GZIP 압축 — 텍스트 파일 용량 축소, 안전
✓ CSS·JS 최소화(Minify) — 켠 뒤 전 페이지 확인 필수
✓ 이미지 지연 로딩 — 첫 화면 이미지는 제외 설정
✓ 모바일 별도 캐시 — 반응형 테마면 꺼도 무방

반대로 캐시 플러그인은 절대 두 개를 동시에 쓰면 안 돼요. 둘 다 .htaccess 파일과 wp-config.php를 건드리기 때문에 설정이 충돌해서, 캐시가 안 지워지거나 로그인이 풀리거나 흰 화면이 뜹니다. 갈아탈 때는 반드시 이전 플러그인을 비활성화가 아니라 삭제하고, 남은 캐시 파일까지 정리한 뒤 새 플러그인을 설치하세요.

사이트 상태 화면에 뜨는 “지속적인 객체 캐시를 사용해야 합니다” 경고도 자주 받는 질문인데, 개인 블로그 규모에서는 급하지 않아요. 객체 캐시(Redis 등)는 데이터베이스 조회 결과를 메모리에 담아두는 기능이라 방문자가 많고 쿼리가 복잡한 사이트에서 빛을 봅니다. 호스팅이 Redis를 지원하면 켜두면 좋지만, 지원 안 한다고 무리해서 설치할 이유는 없어요.

설정 바꿨다 사이트가 깨졌는데 어떻게 되돌리나요?

워드프레스 속도 개선

솔직히 말하면 저는 사이트를 두 번 깨먹었어요. 이 섹션이 이 글에서 제일 중요한 부분일지도 몰라요.

첫 번째는 자바스크립트 지연(Defer/Delay) 설정이었어요. PageSpeed에서 “렌더링 차단 리소스 제거”를 계속 지적하길래, 캐시 플러그인의 JS 지연 로드를 전부 켰어요. 점수는 81점에서 89점으로 뛰었죠. 기분 좋게 잤는데, 다음 날 아침에 보니 모바일 햄버거 메뉴가 안 열리고 문의 폼 전송 버튼이 먹통이었어요. 데스크톱에선 멀쩡해서 반나절 동안 몰랐던 거예요.

두 번째는 CSS 결합(Combine) 옵션. 여러 CSS 파일을 하나로 합치는 기능인데, 켜자마자 글 목록 카드 간격이 무너지고 폰트가 기본체로 바뀌었어요.

두 경우 모두 해결은 단순했어요. 해당 옵션 하나만 끄고 캐시를 비웠더니 바로 정상으로 돌아왔어요. 문제는 “어떤 옵션이 범인인지” 아는 거였고, 그건 한 번에 하나씩 켰다면 5초면 알 일이었어요.

1

캐시부터 비운다

플러그인의 “모든 캐시 삭제”를 누르고 시크릿 창으로 확인하세요. 놀랍게도 절반은 이 단계에서 해결됩니다. 서버 단 캐시(호스팅 제공)가 따로 있다면 그것도 비워야 해요.

2

마지막에 켠 옵션 하나만 끈다

플러그인 전체를 지우지 마세요. 방금 바꾼 옵션만 되돌리고 다시 캐시를 비우면 됩니다. 제 경우 JS 지연 로드 체크 해제 하나로 끝났어요.

3

관리자 로그인이 안 되면 FTP로 플러그인 폴더명 변경

흰 화면이 떠서 관리자 페이지조차 못 들어갈 때 쓰는 최후 수단이에요. wp-content/plugins 안의 해당 폴더 이름 뒤에 -off를 붙이면 워드프레스가 그 플러그인을 자동 비활성화합니다. 호스팅 파일 관리자로도 됩니다.

4

그래도 안 되면 백업 복원

여기까지 왔다면 백업이 유일한 답이에요. 그래서 어떤 설정이든 건드리기 전에 백업을 먼저 잡아두는 습관이 필요해요.

깨진 원인을 못 찾을 때는 Claude Code에 물어봤어요. 개발자 도구 콘솔에 뜬 빨간 에러 메시지를 그대로 복사해서, 이렇게 물었더니 원인 후보와 확인 순서를 정리해주더라고요.

💡 실제로 쓴 프롬프트

“워드프레스에서 캐시 플러그인의 자바스크립트 지연 로드를 켠 뒤 모바일 메뉴 버튼이 동작하지 않아요. 콘솔 에러는 아래와 같습니다. (에러 붙여넣기) 저는 코딩을 모르니 플러그인 설정 화면에서 해결할 수 있는 방법부터, 어떤 항목을 어떤 순서로 확인해야 하는지 알려주세요. 코드 수정이 필요하면 그건 마지막에 알려주세요.”

포인트는 “코딩 모른다”와 “설정으로 해결 가능한 것부터”를 명시하는 거예요. 안 그러면 바로 functions.php 코드를 주는데, 비전공자가 그걸 잘못 붙여넣으면 사이트가 더 크게 무너집니다.

⚠️ 주의사항

설정을 바꾼 뒤엔 반드시 시크릿 창과 실제 스마트폰으로 확인하세요. 로그인 상태에서는 캐시가 적용되지 않아 멀쩡해 보입니다. 저도 이것 때문에 반나절 동안 깨진 걸 몰랐어요. 확인할 곳은 홈·글 상세·모바일 메뉴·검색·댓글창 다섯 군데면 충분해요.

여기까지 하고 점수는 얼마나 변했나요?

3주간의 기록을 정리하면 이렇습니다. 같은 글 URL, 모바일 기준, 3회 측정 중간값이에요.

항목 시작 3주 후
모바일 점수 38 86
LCP 6.1초 2.2초
TTFB 1.9초 0.6초
CLS 0.31 0.04
플러그인 개수 19개 11개
글 하나 총 용량 8.4MB 1.3MB

플러그인은 19개에서 11개로 줄였는데, 판단 기준은 세 가지였어요. 3개월 동안 한 번도 안 들어간 설정 화면이면 삭제, 테마나 다른 플러그인 기능과 겹치면 삭제, 1년 이상 업데이트가 없으면 삭제. 다만 삭제 전에 확인할 게 있어요. 폼·갤러리·SEO 플러그인은 데이터를 자체 테이블에 저장하기 때문에, 지우면 그 데이터가 함께 사라질 수 있어요. 삭제 전에 데이터 내보내기가 가능한지 먼저 보고, 애매하면 비활성화 상태로 2주쯤 두고 문제가 없는지 지켜본 뒤 지우세요.

그리고 일부러 손대지 않은 것도 적어둘게요. 100점을 만들려면 사용하지 않는 CSS 제거, 중요 CSS 인라인 처리, 테마 파일 직접 수정 같은 작업이 필요한데, 여기서부터는 코드 수정 영역이고 테마 업데이트 때 되돌아갈 위험도 있어요. 저는 86점에서 멈췄습니다. 90점대를 향해 사이트를 불안정하게 만드는 것보다, 안정적인 80점대로 글을 계속 쓰는 편이 낫다고 판단했어요.

혼자 할 수 있는 경계선을 정리하면 이래요. 플러그인 설정 화면 안에서 해결되는 것은 전부 혼자 가능하고, functions.php나 테마 파일을 열어야 하는 순간부터는 자식 테마·백업·되돌리기 방법을 먼저 익힌 뒤에 손대는 게 맞아요. 사업용 사이트라 다운타임이 손해로 이어진다면, 그 시점부터는 전문가에게 맡기는 게 오히려 저렴합니다.

자주 묻는 질문

Q. PageSpeed Insights 점수는 몇 점이면 괜찮은가요?
모바일 기준 70점 이상이면 실사용에 지장 없어요. 90점은 목표가 아니라 보너스입니다. 점수보다 LCP 2.5초 이내, CLS 0.1 이하를 먼저 맞추세요. 이 두 개가 실제 방문자 체감과 직결됩니다.

Q. 캐시 플러그인을 두 개 이상 깔아도 되나요?
안 됩니다. 둘 다 .htaccess와 wp-config.php를 수정해서 충돌이 나요. 흰 화면, 로그인 풀림, 캐시 미삭제 같은 증상이 생깁니다. 갈아탈 땐 기존 것을 완전히 삭제한 뒤 설치하세요.

Q. 플러그인을 삭제하면 데이터도 사라지나요?
종류에 따라 달라요. 폼·갤러리·SEO 플러그인은 자체 테이블에 데이터를 저장하므로 함께 지워질 수 있어요. 반면 단순 표시용 플러그인은 지워도 글은 그대로예요. 삭제 전에 설정 화면에서 내보내기 기능이 있는지 확인하고, 없으면 데이터베이스 백업을 먼저 받으세요.

Q. 국내 호스팅과 해외 호스팅 중 어디가 빠른가요?
방문자가 한국에 몰려 있다면 국내 서버가 물리적 거리 때문에 유리해요. 다만 서버 사양과 웹서버 종류(LiteSpeed 여부), PHP 버전이 더 큰 변수라 “국내라서 빠르다”고 단정하긴 어려워요. 옮기기 전에 무료 체험으로 같은 글을 올려 TTFB를 직접 비교해보세요.

Q. 관리자 페이지만 유독 느린 건 왜 그런가요?
관리자 화면은 페이지 캐시가 적용되지 않는 영역이라 서버 성능이 그대로 드러나요. 여기에 하트비트 API의 주기적 요청과 대시보드 위젯의 외부 통신이 겹칩니다. 하트비트 주기를 늘리고 불필요한 대시보드 위젯을 접어두면 체감이 개선돼요.

참고자료

  • PageSpeed Insights — 구글 공식 속도 측정 도구. 모바일·데스크톱 점수와 개선 항목을 함께 제공합니다.
  • Web Vitals (web.dev) — LCP·CLS·INP 등 코어 웹 바이탈 지표의 정의와 권장 기준을 정리한 구글 공식 문서.
  • WordPress 공식 성능 최적화 문서 — 캐싱, 데이터베이스, 서버 설정 등 워드프레스 공식 개발자 문서의 최적화 안내.
  • Google Search Console — 내 사이트의 코어 웹 바이탈 실제 사용자 데이터를 URL 그룹별로 확인할 수 있습니다.

3주 전의 저는 38점이라는 숫자 앞에서 뭘 해야 할지 몰라 창을 닫았어요. 지금 돌아보면 제일 도움이 된 건 대단한 기술이 아니라 메모장 세 칸이었어요. 날짜, 무엇을 바꿨는지, 점수가 몇 점이 됐는지. 그것만 적어두니 뭐가 효과였는지, 어디서 깨졌는지가 다 보이더라고요.

혹시 지금 빨간 점수를 보고 계신다면, 오늘은 이미지 하나만 줄여보세요. 스마트폰 사진을 가로 1600px으로 리사이즈해서 다시 올리고 점수를 재보는 것. 그거 하나로 10점 넘게 움직이는 걸 보면 다음 단계로 갈 힘이 생깁니다.

저도 아직 86점이고, 여전히 손대지 못한 항목이 남아 있어요. 100점짜리 정답을 알려드릴 수는 없지만, 코딩을 모르는 상태에서 여기까지 오는 길은 확실히 있다는 건 말씀드릴 수 있어요. 다음엔 애드센스 광고를 붙인 뒤 점수가 얼마나 떨어졌고 어떻게 다시 끌어올렸는지도 기록해볼게요.


함께 보면 좋은 글

About the author
VIBE PRESS
코딩을 배운 적 없는 사람이 Claude Code와 워드프레스로 직접 사이트를 만들어가는 기록입니다. 완성된 정답을 가르치는 곳이 아니라, 막히고 헤매고 겨우 해결한 과정을 그대로 남깁니다. 도메인 연결, 호스팅 설정, 테마와 플러그인, 글 발행 자동화까지 — 직접 부딪히며 알게 된 것들을 순서대로 씁니다. 잘못 알고 있던 것을 나중에 고치는 일도 있습니다. 그때는 글을 수정하고 무엇이 틀렸는지 함께 남깁니다.