WordPress 초기 셋업 기록: 성능·SEO 파이프라인 5종 검증기
- Rank Math로 SEO 뼈대 세우기 (메타·구조화 데이터)
- EWWW Image Optimizer로 WebP 자동 변환·서빙
- WP Super Cache로 페이지 정적 HTML 캐싱
- 고유주소 구조 정비 (SEO 친화 URL)
- 테스트 글로 파이프라인 실제 작동 확인
블로그를 새로 시작하며 가장 먼저 한 일은 화려한 첫 글을 쓰는 것이 아니라, 튼튼한 기초 공사였습니다. Rank Math로 SEO 뼈대를 세우고, EWWW Image Optimizer로 이미지를 가볍게 만들고, WP Super Cache로 페이지를 정적 HTML로 캐싱하는 세 가지 축을 하나씩 검증했습니다. 이 글은 그 하루의 기록입니다.
블로그는 오래 남기는 기록입니다. 시작 후 며칠 만에 SEO 구조를 바꾸거나 몇 달 뒤에 이미지 최적화를 소급 적용하면 URL이 흔들리고 검색엔진 신뢰가 떨어집니다. 처음부터 제대로 된 뼈대 위에서 글을 쌓아가면 시간이 지날수록 자산이 됩니다.
🧩 전체 구성 — 사용한 스택
이번 셋업의 뼈대는 Docker 위에서 돌아가는 WordPress입니다. 테마는 가볍고 커스터마이징이 편한 Kadence를 골랐고, 그 위에 세 개의 핵심 플러그인을 얹었습니다.
| 구성 요소 | 선택 | 역할 |
|---|---|---|
| 호스팅 | Docker + WordPress | 컨테이너 기반 운영 |
| 테마 | Kadence | 경량·커스터마이징 우수 |
| SEO | Rank Math | 메타 태그·JSON-LD 스키마 |
| 이미지 | EWWW Image Optimizer | 압축 + WebP 자동 변환 |
| 캐싱 | WP Super Cache | 정적 HTML + gzip 압축 |
🔍 1단계 — Rank Math SEO 설치
가장 먼저 설치한 것은 Rank Math입니다. SEO 플러그인은 사이트의 각 페이지가 검색엔진에게 어떻게 보일지를 결정하는 도구입니다. 제목 태그, 메타 설명, 오픈 그래프 태그, 구조화 데이터가 모두 여기서 만들어집니다.
설치 후 설정 마법사를 따라가며 사이트 이름, 기본 언어, 대표 이미지 등을 지정했습니다. 특별히 신경 쓴 부분은 한국어 사이트로 명시적으로 태깅하는 것이었습니다. ko-KR 언어 코드가 모든 페이지의 스키마와 메타 태그에 자동으로 들어가도록 설정했습니다.
🖼️ 2단계 — EWWW Image Optimizer와 WebP
이미지는 웹페이지에서 가장 무거운 요소입니다. 아무리 캐싱을 잘해도 이미지가 1MB짜리 JPG라면 방문자의 첫인상은 느립니다. EWWW Image Optimizer는 업로드된 이미지를 자동으로 압축하고, 더 나아가 같은 이미지의 WebP 버전을 함께 생성합니다.
Google이 만든 차세대 이미지 포맷입니다. 같은 화질을 유지하면서 파일 크기를 JPG 대비 20~50% 줄일 수 있습니다. Safari 구버전 같은 일부 브라우저는 지원하지 않지만,
<picture> 태그로 자동 폴백이 가능합니다.
EWWW는 <picture> 태그를 활용해 이 호환성 문제를 우아하게 해결합니다. 브라우저가 WebP를 지원하면 WebP를, 지원 안 하면 원본 JPG를 자동으로 서빙합니다.
🔗 3단계 — 고유주소부터 잡기
플러그인만 설치하면 끝날 줄 알았지만, WP Super Cache를 설정하려 하자 붉은 오류 메시지가 나왔습니다. “고유주소 구조가 필요합니다”라는 경고였습니다. WordPress의 기본 URL 구조는 ?p=123 같은 쿼리스트링 형태인데, 이 형태로는 정적 HTML 캐싱이 불가능하고 SEO 관점에서도 최악입니다.
설정 → 고유주소에서 “글 이름” 방식으로 변경했습니다. 저장 순간 WordPress가 .htaccess에 재작성 규칙을 자동으로 넣어주며, 이후 모든 캐싱과 SEO 도구가 정상적으로 작동할 수 있는 기반이 마련되었습니다.
⚡ 4단계 — WP Super Cache
방문자가 페이지를 요청할 때마다 WordPress는 PHP를 실행하고 MySQL에서 데이터를 뽑아 HTML을 조립합니다. 이 과정이 약 0.3초 걸립니다. WP Super Cache는 한 번 조립된 HTML을 파일로 저장해두고, 다음 방문자에게는 그 파일을 그대로 전달합니다. 응답이 밀리초 단위로 빨라집니다.
Easy 탭에서 “캐싱 켜기”를 선택하고 상태를 업데이트했습니다. 캐시 테스터를 돌려보니 같은 페이지를 두 번 요청했을 때 두 응답의 타임스탬프가 정확히 일치했습니다. 두 번째 요청이 저장된 정적 HTML을 그대로 받았다는 뜻입니다.
🧪 5단계 — 테스트 글로 전체 파이프라인 검증
인프라를 다 만들었으니 실제로 잘 동작하는지 확인할 차례였습니다. 테스트 글을 하나 작성하고, 이미지를 삽입하고, Rank Math 메타 설명을 입력한 뒤 발행했습니다. 그리고 실제 공개된 페이지의 HTML 소스를 열어 다섯 가지 흔적을 찾았습니다.
📊 검증 결과 — 소스에 남은 흔적들
WP Super Cache의 작동은 HTML 맨 아래 주석에서 확인됐습니다.
<!-- Dynamic page generated in 0.316 seconds. --> <!-- Cached page generated by WP-Super-Cache on 2026-08-05 11:57:42 --> <!-- Compression = gzip -->
원본 페이지가 0.316초 걸려 생성되었고, 그 결과물이 캐시로 저장되었으며, gzip 압축까지 함께 활성화되어 있음을 세 줄이 증명하고 있습니다.
Rank Math의 흔적은 <head> 안에 있었습니다. rank-math-schema 클래스를 가진 JSON-LD 블록에는 여섯 개의 스키마 엔터티가 들어 있었습니다.
@graph: ├─ Person / Organization # 사이트 소유자 ├─ WebSite # 사이트 전체 메타 ├─ ImageObject # 대표 이미지 ├─ WebPage # 이 페이지 ├─ Person (author) # 저자 └─ BlogPosting # 핵심 — 블로그 글 스키마
이 페이지가 “누가 언제 어떤 언어로 쓴 블로그 글인지”를 Google이 완전히 이해할 수 있게 된 것입니다.
WebP 서빙은 가장 확인이 까다로웠습니다. 처음 소스를 검색했을 때 .webp 문자열이 0건이었고, 원인을 찾는 데 시간이 걸렸습니다.
EWWW는 WebP 파일을 정상적으로 만들었지만(원본 대비 83.9% 감소, 1.4MB → 72.4KB), 실제로 페이지에 WebP를 서빙하는 옵션은 별도로 활성화해야 했습니다. “파일 생성”과 “서빙”이 다른 단계였습니다.
EWWW 설정에서 “JS WebP 재작성”과 “이미지 WebP 재작성” 두 옵션을 켜고 캐시를 비운 뒤 다시 확인하자, HTML 소스에 <picture> 태그와 .jpg.webp 확장자를 가진 여러 사이즈의 이미지 경로가 나타났습니다.
<picture> <source srcset="...개미-1.jpg.webp 1024w, ...개미-1-300x300.jpg.webp 300w, ...개미-1-150x150.jpg.webp 150w" type="image/webp"> <img src="...개미-1.jpg" alt="..."> </picture>
반응형 이미지(150w, 300w, 1024w) 세 사이즈 모두 각각의 WebP 버전이 생성되어 있었고, 브라우저는 자동으로 최적 사이즈를 선택해 다운로드합니다.
✅ 최종 성과 — 파이프라인 5종 검증 완료
- 이미지 용량 83.9% 감소 (1.4MB → 72.4KB)
- 반응형 3사이즈(150w, 300w, 1024w) 모두 WebP 서빙
- 페이지 응답 시간: 0.316초 → 캐시 시 밀리초 단위
- gzip 압축으로 전송량 60~80% 추가 감소
- BlogPosting 스키마로 Google 리치 스니펫 대응
💭 배운 것
WordPress 플러그인들은 각자 잘 만들어져 있지만, 조합할 때 순서와 상호작용이 중요합니다. 특히 캐싱 플러그인과 이미지 최적화 플러그인은 서로의 결과물을 침범할 수 있어서, 설정을 바꿀 때마다 캐시를 비우는 습관이 필요합니다.
“설정을 켰다”와 “실제로 작동한다”는 다릅니다. 페이지 소스를 직접 열어 확인하지 않았다면 WebP가 서빙 안 되는 사실을 몰랐을 것입니다. 결과물을 소스 수준에서 확인하는 습관이 인프라 검증의 마지막 단추입니다.
🚀 다음 단계
이 정도의 인프라 위에서 이제 진짜 콘텐츠를 쌓을 수 있게 되었습니다. 다음에 할 일은 두 가지입니다.
- Blogspot 45편 이전 — 기존 콘텐츠를 이곳으로 옮기고 URL 매핑
- 도메인 연결 + HTTPS — IP 접속에서 도메인 접속으로, Let’s Encrypt 인증서 발급
하지만 그건 다음 기록으로 남기겠습니다.
시작이 반이라는 말이 있지만, 좋은 시작은 반보다 더 많은 몫을 차지한다.