// WordPress · Blogger · AWS Lightsail · 블로그이전 · 삽질기
글 123개, 이미지 597개 — 2년간 운영한 WordPress를 Blogger로 옮기면서 겪은 진짜 삽질 기록
들어가며
약 2년간 AWS Lightsail 위에 WordPress를 올려 블로그를 운영했다. 글 123개, 이미지 597개, 플러그인 18개. 나름 열심히 꾸린 블로그였지만, 결국 Blogger(Google Blogspot)로 이전하기로 결심했다.
이 글은 그 과정에서 겪은 실제 삽질과 해결 과정을 기록한 글이다.
왜 이전했나?
AWS Lightsail 유지비 문제
월 $5짜리 인스턴스였지만, 연간으로 보면 약 8만 원. "블로그 하나 돌리는 데 이 돈이?"라는 생각이 계속 들었다.
비용 현황
| Lightsail 인스턴스 (2vCPU, 2GB) | $15/월 |
| 고정 IP | 무료 (연결 시) |
| 도메인 유지비 | 별도 |
| 연간 합계 | ~$180 (약 24만 원) |
블로그 수익? 0원이었다.
관리 피로도
WordPress는 자유도가 높은 만큼 관리할 게 많다. 매일 손이 가는 항목들:
- PHP, MariaDB, Apache 업데이트
- 플러그인 18개 호환성 체크
- 보안 패치 (ModSecurity, Fail2ban, iptables)
- SSL 인증서 갱신 (Let's Encrypt가 제대로 안 걸려서 자체 서명 인증서로 버틴 적도 있다)
- 서버 모니터링 (Whatap 에이전트, 자체 404 탐지 스크립트)
하루에 한 번은 SSH로 접속해서 상태 확인하는 게 일과였다.
Blogger를 선택한 이유
| 무료 | 호스팅비 0원 |
| 관리 불필요 | 서버, 보안, 업데이트 전부 구글이 처리 |
| 커스텀 도메인 | endoflinux.com 그대로 연결 가능 |
| 안정성 | 구글 인프라. 다운될 일이 없다 |
이전 전 서버 현황
이전하기 전 서버 상태를 기록해뒀다. 나중에 참고할 일이 생길 수도 있으니까.
Cloud : AWS Lightsail (ap-northeast-2, Seoul)
OS : Debian 11 (Bullseye)
Kernel : 5.10.0-35-cloud-amd64
Stack : Bitnami WordPress 6.2.0-14
WordPress : 6.8.3
Apache : 2.4.57
PHP : 8.1.18 (PHP-FPM)
MariaDB : 10.11.2
Disk : 60GB NVMe (8.8GB used)
Uptime : 186 days
콘텐츠 현황
| 발행 글 | 123개 |
| 임시 저장 | 1개 |
| 페이지 | 7개 |
| 미디어 파일 | 597개 |
| 리비전 | 886개 |
Step 1. 백업 — 이건 무조건 먼저
이전이고 뭐고 백업부터. 날리면 끝이다.
DB 덤프
$ mysqldump -u root -p wordpress_db > wordpress_db_dump.sql
파일 백업
$ tar -czf wordpress_backup.tar.gz \
/opt/bitnami/wordpress/wp-content/uploads/ \
wordpress_db_dump.sql
# 결과물: wordpress_backup_20260307.tar.gz (254MB)
글 개별 백업 (보험용)
혹시 모르니 글 124개를 HTML 파일로 개별 저장하고, 이미지 505개도 따로 받아뒀다.
~/Backups/blog_complete/
├── posts/
# 124개 HTML
└── images/
# 505개 이미지
💡
Blogger 임포트용 XML도 별도로 생성해뒀다. blogger_import.xml (1.9MB) — 여기서 첫 번째 삽질이 시작됐다.
Step 2. XML 변환 삽질
WordPress의 내보내기 XML과 Blogger의 임포트 XML은 형식이 완전히 다르다.
WordPress XML (WXR 형식)
<item>
<title>글 제목</title>
<content:encoded><![CDATA[<p>본문 HTML</p>]]></content:encoded>
<wp:post_date>2025-01-15 10:30:00</wp:post_date>
</item>
Blogger XML (Atom 형식)
<entry>
<title type='text'>글 제목</title>
<content type='html'>본문 HTML (이스케이프 필요)</content>
<published>2025-01-15T10:30:00.000+09:00</published>
</entry>
날짜 형식도 다르고, HTML 이스케이프 처리도 달라서 변환 스크립트를 직접 짰다.
이미지 문제 — 진짜 노가다
가장 큰 문제는 이미지였다. WordPress에선 /wp-content/uploads/2025/01/image.png 경로를 쓰지만, Blogger로 가면 이 경로가 전부 죽는다.
해결 방법 (택 1)
| 방법 1 | 이미지를 Google 포토나 외부 호스팅에 올리고 URL 교체 |
| 방법 2 | Blogger 에디터에서 다시 업로드 |
😵
123개 글에 달린 수백 개 이미지를 일일이... 이건 진짜 노가다였다.
Step 3. 도메인 이전
DNS 변경
# Before (AWS)
A Record → 43.202.39.214 (Lightsail IP)
# After (Blogger)
CNAME → ghs.google.com
A Records → 216.239.32.21 (Google IP 4개)
DNS 전파에 최대 48시간 걸린다고 하는데, 실제로는 30분~1시간이면 대부분 전환됐다.
SSL 인증서
WordPress에선 자체 서명 인증서로 버티고 있었는데 (Let's Encrypt 설정이 꼬여서...), Blogger는 커스텀 도메인 연결하면 구글이 SSL을 자동 발급해준다. 이것만으로도 이전한 보람이 있었다.
Step 4. 기존 URL 리다이렉트 문제
이전 후 가장 큰 문제: 기존 WordPress URL이 전부 죽는다.
| WordPress URL | endoflinux.com/2025/01/15/post-title/ |
| Blogger URL | endoflinux.com/2025/01/post-title.html |
완전히 다르다. 기존에 검색엔진에 색인된 URL, 외부에서 걸린 링크 전부 404가 된다.
현실적인 해결
사실 완벽한 해결은 어렵다. 기존 서버를 띄워서 301 리다이렉트를 걸어야 하는데, 서버를 내린 마당에 그것도 쉽지 않다.
1. Google Search Console에서 기존 색인 제거 요청
2. Blogger에서 새로 색인 요청
3. 시간이 지나면 구글이 새 URL로 교체해줌 (수 주~수 개월)
⚠️
교훈
서버 내리기 전에 리다이렉트 설정부터 해놓을 것. Apache에서 mod_rewrite로 301 리다이렉트 규칙을 걸어두고, 한 달 정도 병행 운영하다가 서버를 내리는 게 정석이다.
Step 5. Blogger 테마 커스터마이징
기본 Blogger 테마는 솔직히 밋밋하다. WordPress의 자유도에 비하면 답답한 부분이 많지만, XML 테마를 직접 수정하면 꽤 많은 걸 할 수 있다.
커스텀한 것들
+ 네비게이션 바 (Home, Linux, AWS, Cloud, Docker, Python, AI)
+ 모바일 햄버거 메뉴
+ TOC(Table of Contents) 자동 생성
+ 커스텀 파비콘 (SVG 번개 아이콘)
+ 부팅 느낌의 터미널 스타일 헤더
+ JetBrains Mono 폰트 적용
Blogger XML의 함정
Blogger 테마는 XML 기반인데, 일반 HTML과 문법이 다르다. 이런 식의 삽질이 꽤 있었다.
✗ 안 됨 (XML 파싱 에러)
<b:if cond='data:blog.pageType == "item"'>
<div class="post item-page">
<b:else/>
<div class="post">
</b:if>
✓ 이렇게 해야 됨
<div expr:class='"post" + (data:blog.pageType == "item" ? " item-page" : "")'>
Step 6. 보안 설정 비교
WordPress에서 직접 관리하던 보안 설정들과 Blogger를 비교하면 이렇다.
WordPress (직접 관리)
vs
Blogger (구글 관리)
| SSL |
자체 서명 인증서 (삽질) |
자동 발급 ✓ |
| WAF |
ModSecurity (DetectionOnly 모드...) |
구글 인프라 ✓ |
| DDoS |
iptables + Fail2ban (121개 IP 수동 차단) |
구글 인프라 ✓ |
| 브루트포스 |
Fail2ban sshd jail |
해당 없음 ✓ |
| 파일 에디터 |
DISALLOW_FILE_EDIT 설정 |
해당 없음 ✓ |
| 모니터링 |
Whatap + 자체 스크립트 |
필요 없음 ✓ |
Blogger로 오니 보안 관리 부담이 0이 됐다.
이전 후 느낀 점
좋은 점
+ 비용 0원 — 월 $5 절약
+ 관리 부담 0 — SSH 접속할 일이 없다
+ SSL 자동 — Let's Encrypt 삽질 끝
+ 속도 — 구글 CDN이라 한국에서도 빠름
+ 안정성 — 186일 uptime 걱정하던 게 바보 같다
아쉬운 점
- 자유도 제한 — PHP 플러그인 같은 건 꿈도 못 꿈
- URL 구조 — WordPress만큼 자유롭지 않음
- 기존 링크 사망 — 리다이렉트 못 건 게 아쉬움
- 에디터 — WordPress Gutenberg가 확실히 편했다
비용 정리
| 항목 |
Before (WordPress) |
After (Blogger) |
| 호스팅 | $15/월 | $0 |
| 도메인 | 유지 | 유지 |
| SSL | 삽질 | 자동 |
| 관리 시간 | 하루 30분 | 0분 |
결론
개인 블로그에 AWS 서버를 돌리는 건 공부용으로는 최고지만, 블로그 운영 목적으로는 오버스펙이다.
서버 관리, 보안, 모니터링, 백업... 이런 걸 직접 하면서 배운 건 많지만, 블로그 글 쓰는 시간보다 서버 관리 시간이 더 많아지면 본말이 전도된 거다.
WordPress에서 2년간 배운 것들:
• Linux 서버 관리 (Debian, Apache, PHP-FPM)
• 보안 설정 (Fail2ban, iptables, ModSecurity)
• DB 관리 (MariaDB, 백업/복구)
• 모니터링 (Whatap, 자체 스크립트)
• SSL/TLS (삽질 포함)
이 경험들은 고스란히 남아있고, 지금도 다른 프로젝트에서 써먹고 있다.
// 2년 삽질의 결론
"서버 관리를 배우고 싶으면 WordPress,
글을 쓰고 싶으면 Blogger."
Tags:
#WordPress
#Blogger
#AWS
#Lightsail
#&#lambda;쇝자기
#&#lambda;€ 이전