WordPress 플러그인 최적화 실전 — 블로그 속도와 SEO를 동시에 잡은 방법 | devYul

← 16편: 구글 애드센스 승인 결과 공개 — 심사 기간과 피드백 정리

애드센스 승인을 받은 직후, 나는 뭔가 이상한 걸 발견했다. Google PageSpeed Insights를 처음으로 제대로 열어봤는데, 모바일 점수가 41점이었다. 솔직히 말하면, 숫자를 보고 잠깐 멍했다. 광고가 붙기 시작했는데 페이지가 이렇게 느리면 방문자가 광고를 보기도 전에 뒤로 가기를 누르겠구나 싶었다. 뭔가 열심히 쌓아온 탑이 모래 위에 서 있는 느낌이었다.

돌이켜보면 당연한 결과였다. 처음 WordPress를 세팅할 때 플러그인을 “일단 유명한 거 다 깔면 되겠지” 하는 식으로 접근했다. 캐싱, 보안, 백업, SEO, 이미지 최적화, 소셜 공유… 하나씩 검색해서 나오는 걸 다 설치했더니 활성화된 플러그인이 어느새 24개였다. 백엔드 개발자로 5년을 살아왔으면서 정작 내 블로그 서버에는 사용도 안 하는 플러그인들이 가득했던 것이다. 진짜 부끄러운 이야기지만, 이게 지금 17편을 쓰게 된 계기다.

WordPress 플러그인 남용이 블로그 속도를 망치는 이유

개발자 입장에서 생각해보면 사실 당연한 얘기다. 플러그인 하나가 활성화되면 WordPress가 모든 페이지를 로드할 때마다 그 플러그인의 PHP 코드를 실행한다. CSS, JavaScript 파일을 추가로 불러오는 경우도 많다. 24개면 요청 한 번에 덕지덕지 붙는 미들웨어가 24개라고 보면 된다.

문제는 “유명하고 평점 좋은 플러그인”들조차 서로 충돌하거나 중복 기능을 가지고 있다는 거다. 내 경우 캐싱 플러그인이 두 개 깔려 있었다. W3 Total Cache와 LiteSpeed Cache가 동시에 활성화되어 있었는데, 이 둘이 서로 자기 방식대로 캐시를 처리하려다 보니 오히려 캐싱이 전혀 안 되고 있었다. 확인하고 나서 진짜 허탈했다. 속도를 높이려고 깐 플러그인이 속도를 죽이고 있었다니.

그 외에도 “언젠가 쓰겠지”하고 깔아두고 비활성화한 플러그인들도 문제다. 비활성화했다고 완전히 무해한 건 아니다. 데이터베이스에 테이블과 옵션들이 고스란히 남아 있어서 DB 쿼리 성능에 영향을 준다.

플러그인은 많을수록 좋은 게 아니라, 적을수록 강해진다. 24개에서 11개로 줄인 것만으로 페이지 속도가 눈에 띄게 달라졌다.

플러그인 감사(Audit) — 남길 것과 버릴 것 구분하기

나는 일단 모든 플러그인 목록을 구글 스프레드시트에 옮겨 적었다. 그리고 각각에 대해 딱 세 가지만 물었다.

• ✅ 이 기능이 지금 실제로 쓰이고 있나?
• ✅ 다른 플러그인이나 테마에서 이미 같은 기능을 제공하지 않나?
• ✅ 이걸 빼면 블로그 운영에 치명적인 문제가 생기나?

이 기준으로 보니 확실히 보였다. 소셜 공유 버튼 플러그인은 이미 테마(Astra)에 기본 탑재되어 있었다. 별도 플러그인 필요 없었다. 구글 Analytics 연동 플러그인은 Yoast SEO에서도 설정할 수 있어서 중복이었다. 팝업 마케팅 플러그인은 한 번도 설정조차 안 했다. 단순히 “나중에 쓸 수도 있다”는 이유로 켜놓고 있었다.

결국 24개에서 11개로 정리했다. 내가 남긴 핵심 플러그인 목록과 그 이유를 정리하면 이렇다.

W3 Total Cache는 과감하게 삭제했다. Hostinger는 LiteSpeed 서버를 쓰기 때문에 LiteSpeed Cache 플러그인이 압도적으로 궁합이 좋다. 이걸 모르고 일반 캐싱 플러그인을 쓰고 있었던 것 자체가 낭비였다.

호스팅 환경에 맞는 플러그인을 고르는 게 핵심이다. Hostinger + LiteSpeed Cache 조합은 설정만 제대로 하면 별도 CDN 없이도 충분히 빠르다.

LiteSpeed Cache로 WordPress 페이지 속도 최적화하기

LiteSpeed Cache는 그냥 “설치만 하면 빠르다”가 아니다. 기본 설치 상태에서는 설정이 거의 비활성화되어 있어서, 제대로 켜줘야 효과가 난다. 내가 하나씩 만지면서 실제로 점수가 올라간 설정들을 정리해봤다.

캐시 설정 (Cache 탭)에서는 Page Cache, Browser Cache를 켜고, Cache Logged-in Users는 껐다. 로그인 상태에서 캐시가 작동하면 관리자 바가 엉키는 문제가 생긴다.

최적화 설정 (Optimize 탭)이 핵심이다. CSS, JS Minify와 Combine을 켰고, Lazy Load Images를 활성화했다. 그리고 Remove Query Strings도 켰다. 이 설정들이 실제 점수에 제일 많이 기여했다.

이미지 최적화 (Media 탭)에서는 WebP 포맷 자동 변환을 켰다. 기존에 JPEG로 올린 이미지들도 LiteSpeed의 클라우드 최적화 서비스(무료 크레딧 제공)로 일괄 변환했다. 썸네일 이미지 하나가 300KB에서 80KB로 줄었다. 같은 품질인데 용량이 3분의 1이 된 거다.

이 작업들을 마친 뒤 다시 PageSpeed Insights를 돌렸다. 모바일 41점 → 74점, 데스크톱 68점 → 91점. 뿌듯했다. 코드 한 줄 안 짜고 설정만 바꿔서 이 정도면 충분히 의미 있는 개선이다.

LiteSpeed Cache의 Minify, Lazy Load, WebP 변환 세 가지만 제대로 켜도 PageSpeed 점수는 확실히 달라진다.

WordPress SEO 자동화와 플러그인 연동하기

속도 문제를 해결하고 나니 다음은 SEO였다. 16편에서 애드센스 승인을 받았지만 솔직히 검색 유입은 아직 초라한 수준이다. 자동화로 글을 발행하고 있지만 SEO 메타데이터가 제대로 채워지지 않은 글이 꽤 있다는 걸 이번에 확인했다.

Python 자동화 스크립트로 WordPress REST API에 글을 올릴 때 Yoast SEO 필드들을 함께 채워주지 않으면, Yoast가 본문에서 자동으로 뽑아주긴 하지만 정확도가 떨어진다. 특히 메타 디스크립션이 문제다. 본문 첫 문단에서 그냥 잘라오는 경우가 많아서 클릭을 유도하는 문장이 아니라 그냥 도입부가 들어가버린다.

그래서 나는 Claude API로 글 생성할 때부터 메타 디스크립션을 함께 생성하고, REST API 호출 시 Yoast의 커스텀 필드에 직접 넣어주도록 스크립트를 수정했다.

⚙️ 사전 준비: Yoast SEO 플러그인이 설치·활성화되어 있어야 합니다. JWT Authentication 플러그인으로 토큰 인증이 설정된 상태에서 사용하세요. requests, python-dotenv 라이브러리가 설치되어 있어야 합니다.

import os
import requests
from dotenv import load_dotenv

load_dotenv()

WP_URL = os.getenv("WP_URL")          # 예: https://devyul.com
WP_JWT_TOKEN = os.getenv("WP_JWT_TOKEN")  # JWT 토큰


def publish_post_with_seo(title, content, meta_description, focus_keyword, slug):
    """
    WordPress REST API로 포스트 발행 + Yoast SEO 메타데이터 함께 설정
    """
    headers = {
        "Authorization": f"Bearer {WP_JWT_TOKEN}",
        "Content-Type": "application/json",
    }

    payload = {
        "title": title,
        "content": content,
        "status": "publish",
        "slug": slug,
        # Yoast SEO 커스텀 필드
        "meta": {
            "_yoast_wpseo_metadesc": meta_description,
            "_yoast_wpseo_focuskw": focus_keyword,
            "_yoast_wpseo_title": f"{title} | devYul",
        },
    }

    response = requests.post(
        f"{WP_URL}/wp-json/wp/v2/posts",
        headers=headers,
        json=payload,
        timeout=30,
    )

    if response.status_code == 201:
        post_data = response.json()
        print(f"✅ 발행 완료: {post_data['link']}")
        return post_data
    else:
        print(f"❌ 발행 실패 [{response.status_code}]: {response.text}")
        return None


# 사용 예시
publish_post_with_seo(
    title="WordPress 플러그인 최적화 실전",
    content="
본문 내용...
",
    meta_description="WordPress 플러그인 24개를 11개로 줄이고 PageSpeed 점수를 41점에서 74점으로 올린 실전 기록.",
    focus_keyword="WordPress 플러그인 최적화",
    slug="wordpress-plugin-optimization",
)

이렇게 하면 글이 발행됨과 동시에 Yoast SEO 메타 디스크립션과 포커스 키워드가 자동으로 채워진다. 수동으로 글 하나하나 들어가서 수정할 필요가 없어진다. 자동화의 진짜 맛은 이런 데서 난다.

WordPress REST API의 meta 필드를 활용하면 Yoast SEO 메타데이터도 발행 시점에 자동으로 채울 수 있다. 자동화 블로그라면 이 설정은 필수다.

이미지 최적화 — 썸네일 하나로 속도가 달라진다

페이지 속도에서 이미지가 차지하는 비중은 생각보다 훨씬 크다. PageSpeed Insights에서 “Properly size images”와 “Serve images in next-gen formats” 경고가 뜬다면 이미지 최적화가 안 된 것이다. 처음에 내 블로그가 딱 이 두 가지에서 다 걸려 있었다.

해결 방법은 두 가지로 나눌 수 있다.

첫 번째는 업로드 전 전처리다. 나는 썸네일을 만들 때 크기를 1200×630px로 고정하고, JPEG 품질을 80%로 저장하도록 Pillow 스크립트를 짜두었다. 이렇게 하면 원본 파일 자체가 처음부터 가볍다. (썸네일 자동 생성 스크립트는 19편에서 자세히 다룰 예정이다.)

두 번째는 LiteSpeed Cache의 WebP 변환이다. WordPress 미디어 라이브러리에 있는 기존 이미지들도 LiteSpeed Cache 관리 화면에서 “Optimize Images” 버튼 한 번으로 일괄 최적화가 된다. 무료 크레딧이 월 일정량 제공되는데, 소규모 블로그라면 충분하다.

그리고 Yoast SEO에서 Open Graph 이미지(SNS 공유 시 뜨는 썸네일)도 반드시 설정해두자. 설정이 안 되어 있으면 Threads나 카카오톡으로 링크를 공유할 때 이미지가 안 뜨거나 엉뚱한 이미지가 뜬다. 14편에서 Threads 마케팅을 하면서 이게 없어서 공유 미리보기가 텍스트만 나왔던 기억이 있다. 그 때 제대로 안 잡고 넘어간 게 뒤늦게 확인되었다.

이미지는 업로드 전 크기 제한 + LiteSpeed WebP 변환 + OG 태그 설정, 이 세 가지가 기본이다.

데이터베이스 최적화 — 조용히 무거워진 곳

플러그인 정리, 캐시 설정, 이미지 최적화까지 했는데도 가끔 첫 페이지 로딩이 느릴 때가 있었다. 원인을 찾아보니 데이터베이스 문제였다. WordPress는 글을 저장할 때마다 리비전(수정 이력)을 쌓는다. 자동화로 글을 발행하다 보면 한 글에 리비전이 10개, 20개씩 쌓이기도 한다.

또 플러그인들이 삭제된 후에도 wp_options 테이블에 autoload 옵션들을 남겨두는 경우가 있다. 이 autoload 옵션들은 WordPress가 부팅할 때마다 전부 불러온다. 쓸데없는 데이터가 많으면 그만큼 부팅이 느려진다.

WP Revisions Control 플러그인으로 포스트당 리비전 최대 5개로 제한했다. 그리고 LiteSpeed Cache에 포함된 “Database Optimizer” 기능으로 오래된 리비전, 스팸 댓글, 트래시 데이터를 일괄 정리했다. 별도 플러그인 없이도 된다는 게 LiteSpeed Cache의 장점 중 하나다.

⚙️ 사전 준비: DB 최적화 전에 반드시 UpdraftPlus로 전체 백업을 먼저 해두세요. 아래 WP-CLI 명령어는 Hostinger 호스팅의 SSH 접속이 가능한 환경(비즈니스 플랜 이상)에서 실행할 수 있습니다.

# WP-CLI로 오래된 포스트 리비전 일괄 삭제
wp post delete $(wp post list --post_type='revision' --format=ids) --force

# autoload 옵션 크기 확인 (큰 값부터 정렬)
wp db query "SELECT option_name, LENGTH(option_value) as size 
             FROM wp_options 
             WHERE autoload='yes' 
             ORDER BY size DESC 
             LIMIT 20;"

# DB 테이블 최적화 (MyISAM 테이블 대상)
wp db optimize

이 작업을 하고 나서 TTFB(Time to First Byte)가 약 380ms에서 210ms로 줄었다. 눈에 보이는 수치 변화라 직접 확인했을 때 꽤 만족스러웠다.

리비전 제한과 DB 정리는 자동화 블로그일수록 더 중요하다. 글이 많이 쌓일수록 DB 부담도 함께 커지기 때문이다.

최적화 전후 비교 — 실제 점수 변화

한 달에 걸쳐 조금씩 적용한 최적화 작업들의 전후를 정리하면 이렇다.

이 표를 직접 작성하면서 새삼 느꼈다. “완벽한 시스템보다 일단 돌아가는 것 먼저”라는 주의로 시작했는데, 일단 돌아가게 만든 다음에는 돌아가는 것을 제대로 돌아가게 만드는 과정이 필요하다는 것. 부업도 결국 유지보수가 있다.

최적화는 한 번에 다 하려고 하면 지친다. 한 달에 걸쳐 한 가지씩 고쳐나가는 것만으로도 결과는 확실히 달라진다.

솔직한 현재 평가 — 그래서 이게 부업에 도움이 됐냐고?

PageSpeed 점수가 오르면 SEO에 직접 영향을 준다. Google의 Core Web Vitals가 검색 랭킹 신호 중 하나이기 때문이다. 실제로 최적화를 적용하고 약 3주 뒤부터 Search Console에서 평균 게재 순위가 조금씩 올라오는 게 보였다. 劇적인 변화는 아니지만, 방향은 맞다는 확신이 생겼다.

그리고 애드센스 광고 수익 측면에서도 의미가 있다. 페이지가 느리면 광고 로딩보다 사용자 이탈이 먼저 일어난다. 모바일 점수 41점짜리 페이지에서 광고를 달아봤자 클릭을 기대하기 어렵다. 속도 최적화는 결국 광고 수익 최대화와 직결된다.

비용 면에서는 이번 작업이 거의 무료였다. LiteSpeed Cache, Yoast SEO Free, WP Revisions Control 모두 무료 플러그인이다. Hostinger 비즈니스 플랜의 LiteSpeed 서버 환경을 제대로 활용하는 것만으로 충분했다. 월 고정비 14,000~28,000원 유지하면서 이 정도 성능을 뽑을 수 있다는 게, 스타트업 서버 최적화를 해온 입장에서도 꽤 만족스럽다.

다음은 카카오 애드핏이다. 구글 애드센스에만 의존하는 게 불안한 이유가 있다. 한국 독자 비중이 높은 블로그인데 구글 애드핏은 한국 광고 단가가 글로벌 대비 낮다는 얘기를 자주 접했다. 카카오 애드핏이 실제로 수익 보완이 되는지, 직접 달아보고 솔직하게 비교해볼 예정이다.