워드프레스(AWS Lightsail)에서 Hugo 정적 블로그로 이전

오래전부터 이 블로그는 워드프레스로 운영해 왔습니다. 집 홈서버에서 시작했고, 중간에 구글 클라우드로 이전했다가, 나중에는 AWS Lightsail 위에서 워드프레스를 돌리는 형태로 자리 잡았습니다.

이번에 그 구조를 정리하고, 본문은 Hugo로 빌드한 정적 HTML로 바꾸었습니다. PHP·MySQL·상시 웹서버를 끄고, 필요한 동적 기능(댓글·조회수·인기글 등)만 별도 API로 분리한 형태입니다. 전환 과정과 장단점, 특히 비용 쪽을 정리해 둡니다.

기존 환경: AWS Lightsail + 워드프레스

기존 운영 스펙은 대략 아래와 같았습니다.

• 인스턴스: 1GB RAM, 2 vCPU, 40GB SSD
• 구성: 워드프레스 + MySQL + 웹서버가 한 VM 위에 상시 구동
• 월 비용: USD 7.84 (스냅샷 포함)

사양 자체는 개인 블로그용으로 과하지 않았지만, VM이 항상 켜져 있어야 하고 워드프레스·플러그인·OS 보안 패치를 계속 따라가야 한다는 점이 부담이었습니다. 트래픽이 적어도 “서버가 떠 있는 시간”에 대해 비용을 내는 구조라, 콘텐츠 위주 블로그에는 점점 맞지 않게 느껴졌습니다. 무엇보다 각종 워드프레스 플러그인 때문인지 페이지 접속 시 약 7~10초 정도가 걸렸습니다.

왜 정적 사이트로 바꿨나

전환을 결정한 이유는 크게 네 가지였습니다.

1. 상시 서버 비용 – 글 조회만 해도 Lightsail VM이 계속 돌아가야 함
2. 보안·유지보수 – 워드프레스/플러그인 업데이트, PHP·DB 관리
3. 속도 – 정적 HTML + CDN이 동적 PHP 렌더링보다 단순하고 빠름
4. 장애 분리 – 댓글 API가 잠시 죽어도 본문·목록·검색은 살아 있게

각종 AI 툴이 있어 정적 페이지 변환과 동적 기능 API 개발에 대한 부담이 없는 상태라 전환 결정에 어려움이 없었습니다.

전환 과정 요약

전체 흐름은 대략 이렇게 가져갔습니다.

1. 콘텐츠 정리 – 기존 워드프레스 글을 Hugo Markdown으로 유지 (url: /archives/{id}/로 예전 permalink 유지)
2. 테마·레이아웃 – 기존 이슬나라 룩에 맞춰 Hugo 테마 정리
3. 검색 – Pagefind로 클라이언트 사이드 검색 (한글·태그·카테고리)
4. 정적 배포 – hugo 빌드 → AWS S3(비공개) + CloudFront(HTTPS/CDN)
5. 레거시 URL 호환 – CloudFront Function으로 예전 경로·다운로드 링크 보정
6. 동적 기능 – 댓글·댓글 수·조회수·인기글·문의 폼을 GCP Cloud Run + Firestore API로 분리
7. 스팸 대응 – Cloudflare Turnstile(fail-closed) + Rate Limit + 관리자 삭제/차단

위 과정 모두 AI를 이용해서 처리했습니다.

배포는 로컬에서 빌드한 뒤 스크립트로 올리는 방식입니다.

./scripts/build-site.sh
./scripts/deploy-comment-api.sh   # API 변경 시
./scripts/deploy-static.sh       # public/ → S3 + CloudFront invalidation

워드프레스 관리자 화면에서 “발행” 누르던 것과 비교하면, 지금은 글 작성(마크다운 형식) → 빌드 → 정적 배포 순서가 됩니다. 익숙해지면 부담은 크지 않고, 이마저도 AI 툴을 이용하면 쉽게 처리할 수 있습니다. 전용 편집/발행 툴을 만들까도 생각했지만 당분간은 이렇게 수작업으로 처리하려고 합니다.

새 환경 구조

현재 구조는 아래처럼 정적 레이어와 동적 레이어를 나눈 상태입니다.

• 콘텐츠: Hugo Markdown
• 빌드: Hugo (+ Pagefind 검색 인덱스)
• 정적 파일: AWS S3 (프라이빗 버킷)
• CDN/HTTPS: AWS CloudFront
• 댓글·조회·인기글·문의 API: Google Cloud Run (asia-northeast3)
• 데이터 저장: Google Cloud Firestore
• 봇 검증: Cloudflare Turnstile
• 문의 메일: Mailgun

본문·이미지·검색 인덱스는 CloudFront에서 바로 나가고, 댓글/조회수처럼 DB가 필요한 부분만 Cloud Run을 호출합니다. API가 잠깐 내려가도 글 읽기와 검색은 그대로 됩니다.

장점

• 비용이 Lightsail보다 낮음 – 아래에 따로 정리
• 페이지 응답이 단순해짐 – HTML/CSS/JS + CDN 캐시
• 해킹 대상이 줄어듦 – 인터넷에 열려 있던 워드프레스 관리자 화면, PHP, DB가 사라짐
• 배포가 재현 가능 – Git + 빌드 스크립트 기준으로 동일하게 올릴 수 있음
• 장애 격리 – 동적 API 장애 ≠ 사이트 전체 장애
• 스케일 – 트래픽이 늘어도 정적 쪽은 CloudFront가 흡수

단점 / 주의할 점

• 글 발행이 빌드 기반 – 관리자 UI에서 바로 저장·미리보기하던 감각과는 다름
• 플러그인 생태계 없음 – 워드프레스 플러그인으로 하던 건 직접 만들거나 포기
• 동적 기능은 직접 설계 – 댓글·조회수·스팸 대응을 API로 구현·운영해야 함
• 초기 이전 비용(시간) – URL 호환, 업로드 파일, 테마, 댓글 이전/재구현 등 한 번은 손이 큼
• 콜드 스타트 – Cloud Run을 min-instances=0으로 두면 가끔 첫 응답이 조금 느릴 수 있음

개인 블로그처럼 “글을 읽고, 가끔 댓글 달고, 검색하는” 용도에는 장점이 더 컸고, 쇼핑몰·회원제·복잡한 폼이 많은 사이트라면 정적 전환이 항상 정답은 아닐 수 있습니다.

비용 비교

가장 체감이 큰 부분입니다.

기존 (Lightsail)

신규 (예상)

트래픽이 개인 블로그 수준이고, Cloud Run은 요청 있을 때만 떠 있는 설정(min-instances=0, 메모리 512Mi)을 기준으로 잡았습니다. 숫자는 대략적인 예상치이며, 실제 청구는 트래픽·배포 횟수·메일 발송량에 따라 달라집니다.

참고로 Cloud Run Always Free 할당은 주로 미국 일부 리전 기준으로 안내되는 경우가 많고, 이 블로그 API는 지연을 줄이려고 asia-northeast3(서울)에 두었습니다. 그래서 “완전 0원”보다는 소액이 나오는 쪽으로 보는 편이 맞습니다. 그래도 Lightsail처럼 매월 고정으로 7달러대를 내는 구조는 아닙니다.

정적 페이지만 보면 AWS 쪽은 거의 무료에 가깝고, 남는 비용의 대부분은 댓글/조회 API(Cloud Run) 쪽에서 발생한다고 보면 됩니다. 댓글·조회 API를 아예 안 쓰거나 트래픽이 거의 없으면 월 비용은 더 내려갑니다.

한눈에 비교

• 기존: 월 약 USD 7.84 (고정에 가까움)
• 신규: 월 약 USD 1 ~ 3 예상 (트래픽·API 사용량에 따라 변동)
• 체감 절감: 대략 60% ~ 80%대 수준

여기에 “워드프레스 보안 패치·플러그인 깨짐·DB 백업”에 쓰던 시간도 줄어들어서, 돈보다 운영 부담 감소가 더 클 수도 있습니다.

아직 남은 것 / 운영 메모

• 글 올릴 때마다 빌드·배포 한 번씩
• CloudFront 캐시 무효화 비용/한도(경로 수)는 배포 스크립트에서 관리
• API·시크릿(Turnstile, Admin 토큰 등)은 로컬 env로만 관리하고 저장소에는 넣지 않음
• 실제 청구서는 한두 달 돌려본 뒤 이 글의 예상치를 보정할 예정

마치며

Lightsail 위의 워드프레스를 Hugo 정적 사이트 + CloudFront + Cloud Run API 구조로 바꿨습니다. 예전 permalink(/archives/...)는 유지하면서, 본문은 정적으로 두고 댓글·조회 같은 부분만 서버리스로 분리한 형태입니다.

체감으로 가장 큰 변화는 속도입니다. 예전에는 페이지가 열리기까지 7~10초까지 걸리던 적이 있었는데, 전환 후에는 0.5초 정도면 열리는 수준으로 개선되었습니다.

월 비용은 약 7.84달러(고정) 에서 대략 1~3달러대(변동) 로 내려갈 것으로 보고 있고, 보안 패치와 서버 상시 가동에 대한 부담도 같이 줄었습니다. 한동안 실제 청구 금액을 보면서 수치가 어긋나면 후속으로 다시 정리해 보겠습니다.

비슷한 고민(개인 블로그를 VM 워드프레스로 돌리는 중인데 비용·유지보수가 아깝다)이 있다면, 정적 전환을 한 번쯤 검토해 보셔도 좋을 것 같습니다.