ProjectEli

블로그 호스팅 이사가기 Cloudways에서 AWS로 (고급)

작성자:

Eli

in

, ,

작성계기

문제 상황

  • 작년에 티스토리 블로그에서 워드프레스로 옮겨온 후 많은 부분들이 개선되었으나, 유지비가 들어가기 시작
  • 기존에 싸다고 한 cloudways에서 블로그 운영 중이었음. 그러나 언젠가부터 가격도 오르고 이전보다 속도도 느려짐
    • 실제 월결제액이 19000원 가량
    • 제일 싼거로 운영 중이라 싱가폴에 서버가 있었는데 로딩에 10초 이상 소요되는 경우도 발생
  • 운영비가 부담스러워져서 이사를 계획함
    • 현생 때문에 바빠서 신경쓰지 못했는데, 마침 AWS lightsail이 서울 리전 제공한다는 사실을 알게 됨
    • 현재 운영 중인 블로그이다보니 데이터가 날아가거나 가용성 문제가 생기면 안 되므로 신중하게 이관 진행함

해결 내용 요약

  • 이사 작업은 성공적으로 완료되었고, 다음을 확인함
    • 얼마 전 agentic workflow를 위해 구촉한 ELF 프로토콜의 범용성 점검
    • 국내 서버로 블로그 로딩속도 빨라짐, 월결제 7달러로 유지비 줄어들 것으로 예상
    • Google Antigravity + 터미널 실행한 Claude code Sonnet 4.6 + Gemini 3.1 Pro High 조합으로 전공자 아니어도 플러그인 안쓰고 수동이관 진행할 수 있었음

핵심 요약 (TL;DR)

  • 필자가 직접 진행한 2026 버전 WordPress 블로그 호스팅 옮기는 전 과정 확인 가능
  • 용량제한이 있는 migration 플러그인 사용하지 않고도 무료로 옮기는 방법 제시
  • 블로그 호스팅 옮기는 과정에서 발생했던 모든 문제들과 해결방법 제시
  • 필자가 직접 만든 ELF 프로토콜과 LLM의 조합으로 잃어버리는 정보 없이 자동화하여 기록한 내용의 기록 수준 확인

사전 준비

요약 정보

  • 목표: Cloudways -> AWS Lightsail 마이그레이션을 위한 사전 점검 및 준비 완료
  • 배경: 기존 도메인 주소에서 운영 중인 WordPress를 Cloudways에서 AWS lightsail로 이전. 비용 절감 및 인프라 자율성 확보 목적
  • 교훈:
    • 마이그레이션 대상 규모는 디스크 전체가 아닌 wp-content + DB 용량으로 판단해야 함
    • AWS Free Plan에서는 Lightsail 접근 불가. Paid plan으로 업그레이드시 즉시 접근 가능해짐
    • 실제 Lightsail 플랜 사양은 사전 조사와 다를 수 있으므로 생성 화면에서 재확인 필요
    • 양쪽 SSH 접근이 가능하면 수동 마이그레이션 (mysqldump + scp)가 가장 실용적

상세내용

t01: 현재 사이트 현황 파악

  • 목표: 기존 도메인 주소의 현재 운영 환경 및 스펙 기록
  • 교훈: 마이그레이션은 디스크 전체가 아닌 wp-content + DB로 산정해야 함. Cloudways off-site 백업 기준 DB 크기는 서버 전체를 포함한 수치이므로 실제 mysql dump 결과와 크게 다를 수 있음. Breeze 등 호스팅 전용 플러그인은 마이그레이션 후 제거 대상으로, 사전 식별 필요. CPT(Custom post type UI) 사용 시 마이그레이션 후 해당 플러그인이 우선 활성화되어야 콘텐츠가 정상 표시됨

점검 결과

항목확인 내용결과
WordPress 버전wp-admin > Dashboard6.9.1
PHP 버전Cloudways 콘솔8.3
테마커스텀 테마ProjectEli (자체 제작)
활성 플러그인 수플러그인 목록 전체 기록13개 (상세 목록 하단 참조)
총 게시물/페이지 수Posts + Pages + CPT글 18 + 페이지 6 + CPT(TW가이드) 15 = 39개
미디어 파일 수미디어 라이브러리264개 (사진 대부분, 일부 embed용 HTML 파일)
DB 크기Cloudways off-site backup 기준~655 MB
전체 사이트 용량Cloudways Monitoring disk usage11.82 GB

활성 플러그인 목록

#플러그인버전용도
1Advanced Sidebar Menu9.8.3페이지/카테고리 기반 동적 사이드바 메뉴
2Breeze2.4.1Cloudways 캐시 플러그인 (Varnish 연동)
3Custom Post Type UI1.18.3CPT 등록 (TW가이드 등)
4Highlight Search Terms1.8.3검색어 하이라이트
5Meow 라이트박스5.5.0사진 라이트박스 (EXIF 표시)
6Post Type Transfer1.5포스트 타입 변경
7Post Types Order2.4.3드래그앤드롭 포스트 정렬
8Posts Like Dislike1.1.6좋아요/싫어요 기능
9Site Kit by Google1.173.0Google Analytics/Search Console 연동
10SlimStat Analytics5.3.5자체 웹 분석
11Yoast SEO27.1.1SEO 최적화
12간편한 목차 (Easy TOC)2.0.81자동 목차 생성
13스펙트라 (Spectra)2.19.20구텐베르크 확장 블록

분석사항

  • DB 655 MB + 디스크 11.82GB로 무료 마이그레이션 플러그인(512MB 제한)으로는 처리 불가. 수동 마이그레이션 또는 유료 확장 필요
  • Breeze 플러그인은 Cloudways 전용이므로 Lightsail 이전 후 제거 대상
  • 커스텀 테마(ProjectEli) 사용 중이므로 테마 호환성은 자체 관리 가능
  • CPT(TW가이드)가 custom post type ui로 등록되어 잇으므로 마이그레이션 시 해당 플러그인 우선 설치 필요.

t02: 테마 및 플러그인 업데이트

  • 목표: 마이그레이션 전 모든 테마/플러그인을 최신 버전으로 업데이트하여 호환성 문제 예방
  • 교훈: WP 6.9.1, PHP 8.3, 전 플러그인 모두 최신 상태 확인 완료. 추가 작업 불필요

결과: WordPress Core(6.9.1), 테마(ProjectEli), 플러그인 13개 모두 최신 버전 확인 완료. 업데이트 불필요

t03: 불필요 데이터 정리

  • 목표: 마이그레이션 파일 크기 최소화
  • 교훈: Windows 11 기본 cmd에서 Cloudways Master Credentials를 사용하여 SSH 접속 성공 확인함(보안 설정에서 SSH Access Enabled 필요). 별도 클라이언트(PuTTY 등) 불필요.

wp-content 용량 분포 (정리 전):

폴더용량
uploads/285 MB
plugins/99 MB
themes/15 MB
languages/7.9 MB
cache/4.4 MB
기타 (upgrade 등)< 1 MB
합계~415 MB

디스크 전체 11.82 GB 중 wp-content는 ~415 MB. 나머지는 OS/서버/Cloudways 시스템 파일로 마이그레이션 대상 외. 실제 마이그레이션 대상: wp-content ~415 MB + DB ~655 MB = ~1.07 GB

작업 결과:

  1. wp-content/uploads 내 불필요한 백업 파일 삭제 — 해당 없음 (대용량 백업 파일 미존재)
  2. 캐시 플러그인 캐시 전체 Purge — cache/ 삭제 시도, permission denied (일반 유저 권한). 4.4 MB로 미미하여 skip
  3. 스팸 댓글/휴지통 게시물 영구 삭제 — 스팸 댓글 1건 삭제 완료. 휴지통 게시물 없음
  4. 미사용 테마/플러그인 삭제 — Breeze(Cloudways 전용)는 이전 후 제거 예정, 현시점 삭제 불필요
  5. Post Revision 정리 — skip (DB 655 MB 중 revision 비중 미미, 콘텐츠 39개)
  6. upgrade/, upgrade-temp-backup/ 임시 파일 정리 완료

t04: DNS 권한 및 도메인 정보 확인

  • 목표: 도메인 DNS 변경 가능 여부 사전 확보
  • 교훈: 가비아 자체 네임서버 사용 중. DNS 레코드 수정 권한 정상 확보.
항목확인 내용결과
도메인[기존도메인주소]확인 완료
도메인 등록 업체가비아 (gabia.com)확인 완료
네임서버 관리 위치가비아 자체 네임서버확인 완료
DNS 관리 콘솔 로그인접속 가능확인 완료
A Record 수정 권한수정 화면 진입 가능확인 완료
DNS 레코드 백업전체 레코드 다운로드 완료확인 완료

t05: AWS 계정 및 Lightsail 준비

  • 목표: AWS 계정 활성 상태 확인 및 Lightsail 인스턴스 플랜 선정
  • 교훈:
    • AWS 신규 가입 시 Free Plan으로는 Lightsail 접근 불가 — Paid Plan 업그레이드 필수 (추가 비용 없음)
    • “Incomplete AWS registration” 에러는 Paid Plan 업그레이드로 즉시 해소됨 (프로비저닝 24시간 대기 불필요했음)
    • 실제 플랜 사양이 사전 조사와 상이할 수 있으므로 생성 화면에서 재확인 필요 (Micro 명칭 폐지, 가격/사양 변동)
    • Lightsail은 연간 할인 옵션 없음, 월간 결제만 제공
    • Lightsail SSH 접속은 브라우저 터미널(Connect using SSH)이 가장 간편
항목확인 내용결과
AWS 계정 상태신규 생성내부 프로비저닝 대기 중 (최대 24시간)
소액 결제 검증카드 소액 결제 후 취소완료
SMS 신원 확인전화번호 인증완료
Free Tier가입 시 Free Plan → Paid Plan 업그레이드업그레이드 완료 (추가 결제 없음)
결제 수단카드 등록 및 유효성확인 완료
기본 리전ap-northeast-2 (Seoul)설정 완료
인스턴스 플랜$7/월 (1 GB RAM, 2 vCPU, 40 GB SSD)선정 완료
예상 월 비용90일 무료, 이후 $7/월–

이슈: Lightsail 접속 불가 (Free Account Plan 제한)

  • AWS 가입 시 “free account plan”을 선택한 경우, Lightsail을 포함한 일부 서비스 접속이 차단됨
  • Free Plan에서 접근 불가 서비스: Lightsail, Savings Plans, Reserved Instances 등
  • 해결: Paid Plan으로 업그레이드 필요
    1. AWS 콘솔 로그인
    2. https://console.aws.amazon.com/billing/home?#/freetier/upgrade 접속
    3. “Upgrade account” 클릭
  • 업그레이드 후에도 기존 $100 크레딧 및 Free Tier 혜택 유지
  • Lightsail 자체 Free Tier: 신규 계정 기준 3개월간 Micro 플랜($5) 무료 제공
  • “Incomplete AWS registration” 에러: 소액 결제 검증 및 SMS 신원 확인 완료 후에도 발생. AWS 내부 계정 프로비저닝 완료까지 최대 24시간 소요 가능
  • 참고: https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/free-tier-plans.html

Paid Plan 업그레이드 (2026-03-07 실행 완료):

  • 프로비저닝 대기 중 Paid Plan 업그레이드를 선행 실행함
  • 업그레이드 시 별도 추가 결제 안내 표시 없음 (기존 크레딧 및 Free Tier 혜택 유지 확인)
  • 결과: Paid Plan 업그레이드 후 Lightsail 정상 접속 및 Create Instance 화면 진입 성공. 2건의 에러 모두 해소

t05 세부 진행 현황:

Step작업상태
1AWS 계정 생성완료
2소액 결제 검증완료
3SMS 신원 확인완료
4Paid Plan 업그레이드완료 (추가 결제 없음)
5기본 리전 Seoul 설정완료
6내부 프로비저닝 완료 대기Paid Plan 업그레이드로 해소
7Lightsail 인스턴스 생성완료 (Running, 2026-03-07)
8고정 IP 생성 및 연결완료 (2026-03-07)
9초기 접속 확인완료 (2026-03-07)

Step 7: 인스턴스 생성 (진행 중)

  • [x] Platform: Linux/Unix 선택
  • [x] Blueprint: Apps + OS > WordPress 6.9.1 (Bitnami) 선택
  • [x] Instance plan: $7 플랜 (1 GB RAM, 2 vCPU, 40 GB SSD, 90일 무료) 선택
  • [x] Instance name: ProjectEli-blog
  • [x] Create instance 클릭
  • [x] 인스턴스 상태 Running 확인 (2026-03-07)

Optional 항목 검토:

  • Launch script: skip (마이그레이션 시 데이터 덮어쓰기 예정)
  • SSH key: Default (해당 리전 기본 키 자동 생성, .pem 파일 다운로드 필수)
  • Automatic snapshots: 마이그레이션 완료 후 활성화 예정 (현 시점 불필요)
  • Instance 수량 (숫자 버튼): 1 유지 (동일 설정 인스턴스 복수 생성 기능, 단일 블로그이므로 불필요)
  • Instance name: ProjectEli-blog

연간 할인 옵션 조사:

  • Lightsail은 월간 결제만 제공. EC2와 달리 Reserved Instance나 연간 약정 할인 옵션 없음
  • 단순하고 예측 가능한 고정 월 비용이 Lightsail의 설계 철학
  • 장기 사용 시 비용 절감이 필요하면 EC2 전환 후 Reserved Instance/Savings Plans 적용 검토 가능
  • 참고: https://aws.amazon.com/lightsail/pricing/

Step 8: 고정 IP 생성 및 연결 (완료)

  • [x] Location: Seoul (ap-northeast-2)
  • [x] Instance: ProjectEli-blog 연결
  • [x] Static IP name: ProjectEliBlogIp
  • [x] 생성 완료 (고정 IP 최대 5개 무료)

Step 9: 초기 접속 확인 (완료)

  • [x] 브라우저에서 http://{고정IP} 접속 → WP 기본 화면 정상 확인
  • [x] SSH 접속: Lightsail 콘솔 > Connect 탭 > Connect using SSH (브라우저 터미널)
  • [x] 초기 비밀번호 확인: cat bitnami_application_password 실행 완료
  • [x] http://{고정IP}/wp-admin 로그인 확인 완료 (user: user, pw: 위 비밀번호)
  • 비밀번호는 초기 설정용 고정값이므로 반복 확인 불필요. 마이그레이션 후 기존 Cloudways 계정 정보로 로그인하게 됨

OS 선택: Linux/Unix vs Windows

  • Linux/Unix 선택. 이유: WordPress 표준 환경, 비용 절반($5 vs $9.50), 커뮤니티/문서 풍부, Migration_Plan의 모든 절차가 Linux/Bitnami 기준

Blueprint 선택: WordPress (Bitnami) vs WordPress (Lightsail) vs WP Multisite

항목WordPress (Bitnami)WordPress (Lightsail)WP Multisite (Bitnami)
WP 경로/opt/bitnami/wordpress/var/www/html/opt/bitnami/wordpress
스택Bitnami 번들 (Apache+MySQL+PHP)표준 LAMPBitnami 번들 + Network Admin
SSL 도구bncert-tool (자동)수동 Certbotbncert-tool (자동)
파일 권한Bitnami 고유 (daemon 유저)표준 LinuxBitnami 고유
문서/커뮤니티가장 풍부상대적으로 적음적음
용도단일 사이트 (표준)직접 관리 선호 시하나의 WP로 다중 사이트 운영

Lightsail WordPress 플랜 (실제 확인, 2026-03-07):

  • 초기 계획 시 참고한 플랜(Nano/Micro/Small 등)과 실제 제공 플랜이 상이함
  • 플랜명(Nano/Micro 등)이 표시되지 않고 가격 기준으로 구분
  • vCPU가 전반적으로 상향됨 (기존 1 vCPU → 현재 2 vCPU)
  • 가격도 상향됨 ($5 플랜이 기존 Micro 1GB가 아닌 512MB)
월 비용메모리vCPUSSD전송량90일 무료
$5512 MB220 GB1 TBO
$71 GB240 GB2 TBO
$122 GB260 GB3 TBO
$244 GB280 GB4 TBX
$448 GB2160 GB5 TBX
  • 초기 계획: Micro ($5/월, 1 GB RAM) → 실제 $5 플랜은 512 MB
  • 수정 결정: $7 플랜 선택 — Cloudways 기존 1 GB와 동일 사양, 90일 무료 적용, 40 GB SSD로 마이그레이션 데이터(~1.07 GB) 충분

Instance plan: General Purpose 선택 (Memory Optimized 대비 소규모 블로그에 적합, 최소 $20/월 불필요)

Network type: Dual-stack (IPv4+IPv6, 선택 가능한 유일한 옵션. IPv6 only는 선택 불가)

t06: 마이그레이션 도구 선정

  • 목표: 데이터 이전에 사용할 플러그인/방법 확정
  • 교훈:
    • 무료 플러그인은 대부분 500 MB 전후 용량 제한이 있으므로 ~1 GB 이상 사이트는 수동 방식이 실용적
    • 양쪽 SSH 접근이 가능하면 수동 방식(SSH+mysqldump+scp)의 기술적 장벽은 낮음
    • 플러그인 방식은 WP 내부에 설치가 필요하나, 수동 방식은 플러그인 불필요 (SSH만으로 외부에서 진행 가능)
    • 최종 결정: 수동 방식 (SSH+mysqldump+scp) 채택. 용량 제한 없음, 외부 의존성 없음, 양쪽 SSH 접근 확인 완료

후보 (조사 완료):

도구무료 용량 제한설치 방식장점단점
All-in-One WP Migration512 MBWP 플러그인 (양쪽 설치)UI 단순, 안정적~1.07 GB로 제한 초과. 유료 확장 $69
Duplicator500 MBWP 플러그인 (원본측) + installer.phpDB+파일 일괄 패키지제한 초과. 설정 복잡도 높음
UpdraftPlus (Free)제한 없음WP 플러그인 (양쪽 설치)대용량 파일 자동 분할, 무료마이그레이션(URL 변경) 기능은 유료. 백업/복원만 무료
WPvivid (Free)제한 없음WP 플러그인 (양쪽 설치)키 기반 직접 전송Bitnami 환경 호환성 확인 필요
Migrate Guru제한 없음WP 플러그인 (원본측)서버 측 처리, 무료BlogVault 서버 경유, 외부 의존성
수동 (SSH+mysqldump+scp)제한 없음플러그인 불필요 (SSH만)완전 무료, 유연, 안정적기술 난이도 높음
수동 (WP-CLI+rsync)제한 없음플러그인 불필요 (SSH만, WP-CLI 사전 설치)가장 빠르고 안정적, 대용량 최적양쪽 SSH 접근 필요, 기술 난이도 높음

비교 분석 (마이그레이션 대상 ~1.07 GB 기준):

  • 플러그인 방식: All-in-One/Duplicator는 무료 용량 초과로 탈락. UpdraftPlus/WPvivid는 무료로 가능하나 URL 변경(Cloudways IP → Lightsail IP) 처리에 제약
  • 수동 방식: 양쪽 모두 SSH 접근 가능(Cloudways cmd 접속 확인, Lightsail 브라우저 터미널 확인)하므로 기술적 전제조건 충족

결정: 수동 방식 (SSH+mysqldump+scp) 채택

  • 사유: 양쪽 SSH 접근 가능, 마이그레이션 대상 ~1.07 GB로 적정 규모, 용량 제한 없음, 외부 서비스 의존 없음, 완전 무료
  • Bitnami 환경 주의사항:
    • WP 경로: /opt/bitnami/wordpress
    • 파일 권한: sudo chown -R bitnami:daemon /opt/bitnami/wordpress
    • DB 접속 정보: /opt/bitnami/wordpress/wp-config.php에서 확인
  • 참고: https://docs.bitnami.com/aws/how-to/migrate-wordpress/

데이터 마이그레이션

요약정보

  • 목표: Cloudways의 WordPress 데이터(DB + wp-content)를 Lightsail 인스턴스로 이전 및 정상 동작 확인
  • 배경: S001에서 사전 준비 완료. 마이그레이션 대상 ~1.07 GB (DB ~655 MB + wp-content ~415 MB). 양쪽 SSH 접근 확인 완료
  • 교훈: 실제 마이그레이션 데이터 크기는 ~290 MB (DB 66 MB + wp-content 224 MB)로 초기 추정치 ~1.07 GB보다 훨씬 작음 (압축 효과). Bitnami Lightsail은 MariaDB 사용 — mysqldump/mysql 대신 mariadb-dump/mariadb 명령어 사용 필요. Yoast SEO는 마이그레이션 후 인덱싱 데이터 불일치로 Fatal Error 발생 가능 — 임시 비활성화 후 재활성화+SEO Data 최적화로 해결. credential은 로그에 플레이스홀더로 처리하고 웹 콘솔 참조로 대체하면 보안과 재현성을 동시에 확보 가능.

상세내용

t01: 접속 정보 확인 및 사전 고려사항

  • 목표: 마이그레이션 실행에 필요한 환경 정보 수집. credential은 기록하지 않고 웹 콘솔 참조로 대체
  • 교훈: DB 접두사 wp_ 확인 (기본값). 플러그인 전용 테이블(wp_ulike, wp_yoast 등)도 존재하나 전체 덤프 시 자동 포함됨. Lightsail SSH 키는 브라우저 터미널 사용 시 불필요.

사전 고려사항: 개인정보 보호 원칙

웹 콘솔에서 재확인 가능한 credential(DB user/password, IP, SSH 정보)은 로그 및 LLM 대화에 기록하지 않음. 단, 아래 항목은 Cloudways 해지 후 재확인 불가능하거나 마이그레이션 명령어에 직접 영향을 주므로 기록 필요:

#항목기록 사유확인 방법
1DB 테이블 접두사 ($table_prefix)기본값 wp_가 아닌 경우 t08 search-replace 쿼리의 테이블명이 변경됨. Cloudways 해지 후 확인 불가Cloudways SSH > grep table_prefix wp-config.php
2Cloudways WP 설치 경로t02(mysqldump), t03(tar) 명령어에서 정확한 경로 필요. 호스팅마다 상이Cloudways SSH > find / -name wp-config.php 2>/dev/null
3Lightsail SSH 기본 키(.pem)생성 시 1회만 다운로드 가능. 분실 시 로컬 SSH 접속 불가 (브라우저 터미널은 가능)Lightsail 콘솔 > Account > SSH keys

작업:

  • [x] Cloudways SSH 접속하여 위 항목 1, 2 확인 및 기록 완료 (명령어 pwd, DB Manager 확인)
  • [x] Lightsail SSH 키(.pem) — skip. 브라우저 터미널(Connect using SSH)로 전 작업 수행 가능. .pem은 로컬 cmd SSH 접속 시에만 필요
  • [x] DB 접속 정보는 기록하지 않음 — 실행 시 Cloudways 콘솔 / Lightsail wp-config.php에서 직접 확인
항목값
Cloudways WP 설치 경로확인 완료 (applications/[랜덤문자열]/public_html)
DB 테이블 접두사wp_ (Cloudways DB Manager에서 직접 확인)
추가 DB 확인 사항wp_ulike, wp_yoast 등 특정 플러그인 전용 테이블 포함 (전체 덤프 시 자동 포함)
Lightsail SSH 키 보관skip (브라우저 터미널 사용)

Cloudways SSH 접속 방식 비교:

항목Master CredentialsApplication Credentials
접근 범위서버 전체 (모든 앱)해당 앱만
권한 수준sudo 가능앱 디렉토리 내 한정
홈 경로/home/master/home/[app주소]
WP 경로/home/master/applications/[랜덤문자열]/public_html/home/[app주소]/public_html
mysqldump/tar/scp가능가능
  • 마이그레이션 작업(mysqldump, tar, scp)은 양쪽 모두 동일하게 수행 가능
  • 결정: Master Credentials 사용 (이미 접속 중, 기능적 차이 없음)

t02: Cloudways에서 DB 덤프 생성

  • 목표: WordPress DB 전체를 mysqldump로 백업
  • 교훈: SSH Master Credentials와 DB Credentials는 별개. -p와 비밀번호 사이 공백 금지. 덤프 파일 66 MB (Cloudways off-site backup 655 MB 대비 작은 이유: off-site backup은 서버 전체 포함).

참고: mysqldump는 Cloudways 서버 내부에서 DB를 .sql 파일로 추출하는 작업. 로컬 PC로 다운로드하는 것이 아님. 생성된 파일은 Cloudways 서버의 ~/wp_db_backup.sql에 저장되며, Lightsail로의 전송은 t05에서 별도 수행.

주의: -p와 비밀번호 사이에 공백이 있으면 안 됨. 공백 시 비밀번호가 DB 이름으로 해석됨. 또한 SSH Master Credentials와 DB Credentials는 별개이므로, Cloudways 콘솔 > Application > Access Details > Database 섹션의 credential을 사용해야 함.

작업:

  • [x] Cloudways SSH 접속 (cmd에서 Master Credentials 사용)
  • [x] mysqldump 실행 완료:mysqldump -u [DB_USER] -p[DB_PASSWORD] [DB_NAME] > ~/wp_db_backup.sql
  • [x] 덤프 파일 크기 확인: 66 MBls -lh ~/wp_db_backup.sql

t03: Cloudways에서 wp-content 압축

  • 목표: wp-content 디렉토리를 tar로 패키징
  • 교훈: SSH 접속 시 public_html까지 도달한 상태면 cd 불필요, 바로 tar 실행 가능. 압축 소요 약 1분 (wp-content ~285 MB → 압축 후 224 MB).

작업:

  • [x] public_html 디렉토리에서 압축 실행 (약 1분 소요):tar -czf ~/wp_content_backup.tar.gz wp-content/
  • [x] 압축 파일 크기 확인: 224 MBls -lh ~/wp_content_backup.tar.gz

t04: Lightsail DB 접속 정보 확인

  • 목표: Lightsail Bitnami WordPress의 DB 접속 정보 수집
  • 교훈: Bitnami wp-config.php에서 grep으로 DB_NAME, DB_USER, DB_PASSWORD, DB_HOST 4항목 즉시 확인 가능.

작업:

  • [x] Lightsail SSH 접속 (브라우저 터미널)
  • [x] wp-config.php에서 DB 정보 확인 완료 (4항목):cat /opt/bitnami/wordpress/wp-config.php | grep -E "DB_NAME|DB_USER|DB_PASSWORD|DB_HOST"
  • credential은 로그에 기록하지 않음. 필요 시 위 명령어로 재확인.
  • WP 경로: /opt/bitnami/wordpress

t05: 백업 파일을 Lightsail로 전송

  • 목표: Cloudways의 DB 덤프 + wp-content 압축 파일을 Lightsail로 전송
  • 교훈: Cloudways↔로컬 전송은 ~1 MB/s로 느림. Lightsail(Seoul)↔로컬은 수십 MB/s로 빠름. 로컬 경유 방식(A)은 .pem 키 관리 불필요하고 브라우저 터미널 방침과 일관. scp 명령어 끝의 .(공백+점) 누락 시 에러 발생에 주의.

전송 방법 옵션:

방법절차비고
A. Cloudways→로컬→Lightsailscp로 로컬에 다운로드 후 Lightsail에 업로드2단계 전송, 로컬 경유
B. Cloudways→Lightsail 직접Cloudways에서 scp로 Lightsail에 직접 전송1단계 전송, SSH 키 필요

결정: 방법 A (로컬 경유) — .pem 키 불필요, 브라우저 터미널 방침과 일관

Step 1: Cloudways → 로컬 PC (다운로드)

  • Windows 11 기본 터미널은 PowerShell이므로 cmd 별도 실행 필요
  • cmd 기본 경로가 system32이므로 작업 디렉토리 변경:cd /d %USERPROFILE%\Downloads (/d 플래그: 드라이브 변경 포함한 디렉토리 이동)
  • [x] cmd에서 scp로 다운로드 (Cloudways Master Credentials 사용, 대시보드 > 서버 선택 > Master Credentials에서 확인):scp [CW_USER]@[CW_IP]:~/wp_db_backup.sql . scp [CW_USER]@[CW_IP]:~/wp_content_backup.tar.gz . 주의: 명령어 끝의 . (공백+점)을 반드시 포함해야 함. 현재 디렉토리(Downloads)에 저장하는 의미. 누락 시 에러 발생.
  • [x] 로컬에서 파일 수신 확인. 전송 속도 1 MB/s 미만으로 시간 소요됨 (66 MB + 224 MB, 합계 약 290 MB)

Step 2: 로컬 PC → Lightsail (업로드)

  • [x] Lightsail SSH 키(.pem) 다운로드 완료
    • Lightsail 콘솔 > 인스턴스 > Connect 탭 > Use your own SSH client > SSH key download
    • 파일명: LightsailDefaultKey-ap-northeast-2.pem (Seoul 리전 기본 키)
  • [x] cmd에서 scp로 업로드 완료 (Downloads 폴더, .pem과 백업 파일이 같은 경로에 위치):scp -i LightsailDefaultKey-ap-northeast-2.pem wp_db_backup.sql bitnami@[LS_IP]:~/ scp -i LightsailDefaultKey-ap-northeast-2.pem wp_content_backup.tar.gz bitnami@[LS_IP]:~/
    • Lightsail이 Seoul 리전이므로 수십 MB/s 속도로 전송, 수 초 내 완료 (Cloudways→로컬 대비 대폭 빠름)
  • [x] Lightsail 브라우저 ssh 터미널에서 수신 파일 확인 완료:ls -lh ~/wp_db_backup.sql ~/wp_content_backup.tar.gz

t06: Lightsail에서 DB 복원

  • 목표: Cloudways DB 덤프를 Lightsail MySQL에 임포트
  • 교훈: Bitnami Lightsail은 MariaDB 사용. mysqldump/mysql은 deprecated — /opt/bitnami/mariadb/bin/mariadb-dump 및 mariadb 사용. Cloudways mysqldump 출력 .sql은 MariaDB와 호환됨. 임포트 전 기존 DB를 반드시 백업(안전망). 66 MB 임포트에 약 10초 소요.

주의: t06의 모든 명령어는 Lightsail 브라우저 터미널에서 실행 (로컬 cmd 아님).

DB 접속 정보 확인 방법: Lightsail 터미널에서 아래 명령어로 확인:

cat /opt/bitnami/wordpress/wp-config.php | grep -E "DB_NAME|DB_USER|DB_PASSWORD|DB_HOST"

출력 예시:

define( 'DB_NAME', 'bitnami_wordpress' );
define( 'DB_USER', 'bn_wordpress' );
define( 'DB_PASSWORD', '[DB_PASSWORD]' );
define( 'DB_HOST', '127.0.0.1:[PortNumber]' );
  • [LS_DB_USER] = bn_wordpress, [LS_DB_NAME] = bitnami_wordpress
  • [LS_DB_PASSWORD]는 출력된 값을 그대로 사용

주의사항:

  • 브라우저 터미널에서 Ctrl+C/V 사용 금지 (터미널에서 Ctrl+C는 프로세스 중단 명령). 마우스 우클릭으로 복사/붙여넣기
  • -p와 비밀번호 사이에 공백 없이 입력 (t02와 동일)

작업:

  • [x] 기존 Lightsail DB 백업 (안전망):/opt/bitnami/mariadb/bin/mariadb-dump -u [LS_DB_USER] -p[LS_DB_PASSWORD] [LS_DB_NAME] > ~/ls_db_original_backup.sql 백업 후 ls ~ 로 확인:bitnami_application_password ls_db_original_backup.sql wp_db_backup.sql bitnami_credentials wp_content_backup.tar.gz
    • bitnami_application_password, bitnami_credentials: Bitnami 인스턴스 초기 생성 시 자동 생성되는 파일 (정상)
    • ls_db_original_backup.sql: 안전망 백업 정상 생성
    • wp_db_backup.sql, wp_content_backup.tar.gz: t05에서 전송한 Cloudways 백업 파일
  • [x] Cloudways 덤프 임포트 완료 (약 10초 소요, 에러 없이 프롬프트 복귀):/opt/bitnami/mariadb/bin/mariadb -u [LS_DB_USER] -p[LS_DB_PASSWORD] [LS_DB_NAME] < ~/wp_db_backup.sql

참고: Bitnami Lightsail은 MariaDB 사용. mysqldump/mysql 명령어는 deprecated 경고 발생. /opt/bitnami/mariadb/bin/mariadb-dump 및 /opt/bitnami/mariadb/bin/mariadb를 사용. Cloudways의 mysqldump로 생성한 .sql 파일은 MariaDB와 호환됨.

  • [x] 임포트 완료 확인

t07: Lightsail에서 wp-content 복원

  • 목표: Cloudways wp-content를 Lightsail에 배치 및 권한 설정
  • 교훈: Bitnami WP 파일 권한은 소유자 bitnami, 그룹 daemon, 디렉토리 775, 파일 664가 표준. ls -la 출력의 문자열(rwxrwxr-x 등)을 3자리씩 소유자/그룹/기타로 읽으면 숫자 권한으로 변환 가능. 기존 wp-content는 mv로 백업(wp-content-original) 후 t10에서 안정화 확인 후 삭제 예정.

주의: t07의 모든 명령어는 Lightsail 브라우저 터미널에서 실행.

작업:

  • [x] 기존 Lightsail wp-content 백업 (안전망, 1초 미만):sudo mv /opt/bitnami/wordpress/wp-content /opt/bitnami/wordpress/wp-content-original
  • [x] 압축 해제 및 배치 (수 초 소요):cd /opt/bitnami/wordpress sudo tar -xzf ~/wp_content_backup.tar.gz
  • [x] 파일 권한 설정 완료 (chown 즉시, chmod 디렉토리 즉시, chmod 파일 약 10초):sudo chown -R bitnami:daemon /opt/bitnami/wordpress/wp-content sudo find /opt/bitnami/wordpress/wp-content -type d -exec chmod 775 {} \; sudo find /opt/bitnami/wordpress/wp-content -type f -exec chmod 664 {} \;
  • [x] 권한 설정 확인 완료. 확인 명령어 및 결과 예시:ls -la /opt/bitnami/wordpress/wp-content/ ls -la /opt/bitnami/wordpress/wp-content/ | head -5 ls -la /opt/bitnami/wordpress/wp-content/plugins/ 결과 읽는 법 (숫자가 아닌 문자로 표시됨):drwxrwxr-x bitnami daemon → 디렉토리, 775 (정상) -rw-rw-r-- bitnami daemon → 파일, 664 (정상)
    • d = 디렉토리, - = 파일
    • rwx = 읽기(r=4)+쓰기(w=2)+실행(x=1) = 7
    • rw- = 읽기(r=4)+쓰기(w=2) = 6
    • r-- = 읽기(r=4) = 4
    • 3자리씩 소유자/그룹/기타 순서: rwxrwxr-x = 775, rw-rw-r-- = 664
    • 소유자 bitnami, 그룹 daemon 확인 → 전체 정상

t08: wp-config.php 및 사이트 URL 수정

  • 목표: Lightsail 환경에 맞게 DB 접속 정보 및 사이트 URL 갱신
  • 교훈: DB 데이터만 임포트했으므로 wp-config.php는 Lightsail 원본 유지 (변경 불필요). DNS 변경 전에는 siteurl/home을 고정 IP로 임시 변경해야 접속·검증 가능. S003에서 도메인으로 복원 필요.

주의: t08의 모든 명령어는 Lightsail 브라우저 터미널에서 실행.

작업:

  • [x] wp-config.php의 DB 접속 정보가 Lightsail 값인지 확인 → 일치 확인 (변경 불필요)cat /opt/bitnami/wordpress/wp-config.php | grep -E "DB_NAME|DB_USER|DB_PASSWORD|DB_HOST"
    • t06에서 DB 데이터만 임포트했으므로 wp-config.php는 Lightsail 원본 그대로 유지됨
    • t04에서 확인한 값(bitnami_wordpress, bn_wordpress 등)과 일치
  • [x] DB 내 사이트 URL 변경 완료 (Cloudways URL → Lightsail 고정 IP):/opt/bitnami/mariadb/bin/mariadb -u [LS_DB_USER] -p[LS_DB_PASSWORD] [LS_DB_NAME] -e " UPDATE wp_options SET option_value = 'http://[LS_STATIC_IP]' WHERE option_name = 'siteurl'; UPDATE wp_options SET option_value = 'http://[LS_STATIC_IP]' WHERE option_name = 'home'; " 왜 고정 IP로 변경하는가:
    • DB의 siteurl/home이 https://[기존도메인주소]이면, WP는 모든 요청을 해당 도메인으로 리다이렉트
    • 현재 DNS는 Cloudways를 가리키므로 → Lightsail IP로 접속해도 Cloudways로 이동되거나 인증서 오류 발생
    • wp-admin 로그인, 프론트엔드 확인(t09) 모두 불가능 → 검증을 위해 임시로 고정 IP 변경 필수
    S003에서 도메인 복원 필요:시점siteurl / home 값이유지금 (t08)http://[LS_STATIC_IP]DNS가 아직 Cloudways → IP로만 접속·검증 가능S003 (DNS+SSL 완료 후)https://[기존도메인주소]DNS가 Lightsail을 가리키고 SSL 설치 완료 후 원래 도메인으로 복원S003에서의 복원 명령어 (동일 UPDATE문, 값만 변경):/opt/bitnami/mariadb/bin/mariadb -u [LS_DB_USER] -p[LS_DB_PASSWORD] [LS_DB_NAME] -e " UPDATE wp_options SET option_value = 'https://[기존도메인주소]' WHERE option_name = 'siteurl'; UPDATE wp_options SET option_value = 'https://[기존도메인주소]' WHERE option_name = 'home'; "
  • [x] Apache/서비스 재시작 완료:sudo /opt/bitnami/ctlscript.sh restart

t09: 마이그레이션 결과 검증

  • 목표: Lightsail에서 마이그레이션된 사이트 정상 동작 확인
  • 교훈: Yoast SEO는 마이그레이션 후 인덱싱 데이터 불일치로 Fatal Error 발생 가능 — 임시 비활성화 후 재활성화+SEO Data 최적화로 해결. Nav 등 내부 링크의 도메인 리다이렉션은 siteurl/home만 변경한 상태에서 정상 현상 (DNS 변경 시 자연 해소).

주의: t09의 터미널 명령어는 Lightsail 브라우저 터미널에서 실행.

검증 항목:

  • [x] http://[고정IP] 접속 → 메인 페이지 정상 표시 (Yoast 비활성화 후 확인)
  • [x] http://[고정IP]/wp-admin → 기존 Cloudways 계정으로 로그인 확인
    • WP 관리자 계정 확인 방법: Cloudways 콘솔 > Application > WordPress > Access Details
    • DB를 덮어쓰기했으므로 기존 Cloudways 계정이 그대로 유효
  • [x] 게시물 확인: 글 18개, 페이지 6개, CPT(Custom Post Type) 게시물 15개 — 정상
  • [x] 미디어 라이브러리: 264개 파일 정상 표시
  • [x] 테마(ProjectEli) 정상 적용 확인
  • [x] 플러그인 동작 확인:
    • Custom Post Type UI 등 대시보드에서 정상 표시
    • Yoast SEO는 t09 트러블슈팅에서 임시 비활성화 상태 (wordpress-seo-disabled). 재활성화는 S003에서 진행
    • 이외 플러그인 정상 동작 확인
  • [x] 프론트엔드 콘텐츠 확인:
    • 게시글 접속 → 본문 텍스트, 이미지 정상 표시
    • 미디어에 업로드된 HTML 파일이 임베드된 글 → 정상 작동 확인
    • 레이아웃/이미지 깨짐 없음

참고: Nav 클릭 시 기존 도메인으로 리다이렉션되는 현상

  • 정상 현상. t08에서 변경한 것은 wp_options의 siteurl/home 2개 값뿐
  • 게시물 본문, 메뉴 링크, 위젯 등에 하드코딩된 URL은 여전히 https://[기존도메인주소]
  • S003에서 DNS를 Lightsail으로 변경하면 해당 도메인이 Lightsail IP로 해석되므로 자연히 해소
  • 지금 전체 search-replace는 불필요 (S003에서 도메인 복원 예정)

트러블슈팅: Yoast SEO Fatal Error

  • http://[고정IP] 접속 시 “이 웹사이트에 치명적인 오류가 있습니다” 발생
  • 에러 로그 확인:sudo tail -50 /opt/bitnami/apache/logs/error_log
  • 확인된 오류:
    1. Fatal Error (사이트 다운 원인): Yoast SEO pagination-helper.php:74에서 array_key_exists() TypeError — 마이그레이션 후 인덱싱 데이터 불일치
    2. Warning (비치명적): chmod(): Operation not permitted in class-wp-filesystem-direct.php:173 — PHP가 daemon 유저로 실행되나 파일 소유자가 bitnami여서 chmod 불가. Bitnami 환경의 알려진 이슈
  • 조치: Yoast SEO 플러그인 임시 비활성화sudo mv /opt/bitnami/wordpress/wp-content/plugins/wordpress-seo /opt/bitnami/wordpress/wp-content/plugins/wordpress-seo-disabled
  • 결과: 메인 페이지 정상 표시 확인
  • Yoast 재활성화 및 SEO Data 최적화는 S003(DNS+SSL 완료 후)에서 진행 예정

t10: 임시 파일 정리

  • 목표: 마이그레이션 완료 후 불필요한 임시 파일 삭제
  • 교훈: wp-content-original(Lightsail 기본 wp-content 백업)은 안정화 확인 전까지 보존. SSH 키(.pem)는 보안상 삭제 권장 (필요 시 Lightsail 콘솔에서 재다운로드 가능).

작업:

Lightsail 서버 (~/):

  • [x] 마이그레이션 임시 파일 삭제 완료:rm ~/wp_db_backup.sql rm ~/wp_content_backup.tar.gz rm ~/ls_db_original_backup.sql
  • wp-content-original은 안정화 확인 후 삭제 예정 (S004에서 처리):sudo rm -rf /opt/bitnami/wordpress/wp-content-original

로컬 PC (Downloads 폴더):

  • [x] wp_db_backup.sql 삭제 완료
  • [x] wp_content_backup.tar.gz 삭제 완료
  • [x] LightsailDefaultKey-ap-northeast-2.pem 삭제 완료 (보안상 삭제. 브라우저 터미널 사용 시 불필요. 필요 시 Lightsail 콘솔에서 재다운로드 가능)

Cloudways 서버 (~/):

  • [x] 임시 파일 삭제 완료:rm ~/wp_db_backup.sql rm ~/wp_content_backup.tar.gz
    • Cloudways 해지 시 서버 자체가 소멸하므로 해지 예정이면 별도 삭제 불필요

옮겨진 웹사이트 활성화 (DNS 변경, SSL, 사이트 복원)

요약정보

  • 목표: Lightsail으로 이전된 사이트를 실제 도메인으로 활성화하고, HTTPS 적용 및 마이그레이션 후 플러그인 이슈 해소
  • 배경: S002에서 데이터 마이그레이션 완료. 현재 고정 IP로만 접속 가능 (siteurl/home이 고정 IP로 임시 설정됨). Yoast SEO 비활성화 상태
  • 교훈: DNS 전파는 즉시 완료될 수 있음(48시간은 최대치). bncert-tool의 리다이렉션 옵션은 상호 배타적이므로 순서에 주의. Bitnami wp-config.php의 동적 URL 생성($_SERVER['HTTP_HOST'])은 HTTP_HOST 미설정 요청에서 Yoast SEO Fatal Error를 유발 — fallback 추가 + HTTPS 프로토콜 수정으로 해결. 플러그인 재설치, 퍼머링크 재저장으로는 해결 불가한 문제도 있으므로 에러 로그의 스택 트레이스를 소스 코드까지 추적하는 것이 중요.

상세내용

t01: DNS A Record 변경

  • 목표: 도메인이 Lightsail 고정 IP를 가리키도록 DNS 변경
  • 교훈: 가비아에서 A Record 변경은 루트(@)와 서브도메인(www) 두 건을 각각 수정해야 함. 변경 자체는 단순 작업이나, 변경 전 Lightsail 고정 IP를 콘솔에서 정확히 확인하는 것이 중요.

사전 확인:

  • 가비아 DNS 관리 페이지 접속 확인
  • 현재 A Record가 Cloudways IP를 가리키고 있음
  • Lightsail 고정 IP는 Lightsail 콘솔 > 인스턴스 > Networking에서 확인

작업:

  • [x] 가비아 로그인 > My가비아 > DNS 관리
  • [x] 기존 A Record의 IP를 Lightsail 고정 IP로 변경
    • @ (루트 도메인) → Lightsail 고정 IP
    • www (서브도메인) → Lightsail 고정 IP
  • [x] 변경 저장 완료

t02: DNS 전파 확인

  • 목표: DNS 변경이 전파되어 도메인이 Lightsail을 가리키는지 확인
  • 교훈: DNS 전파는 “최대 48시간”이 통상 안내되지만 실제로는 수 분 이내에 완료될 수 있음. nslookup으로 로컬 확인 + whatsmydns.net으로 글로벌 전파를 동시에 확인하면 충분. hosts 파일 선행 테스트는 즉시 전파 시 불필요.

참고: DNS 전파는 통상 수 분~수 시간 소요. 최대 48시간까지 걸릴 수 있음.

확인 방법:

  • [x] 로컬 PC에서 확인:nslookup [기존도메인주소] 결과의 Address가 Lightsail 고정 IP와 일치함을 확인
  • [x] 브라우저에서 http://[기존도메인주소] 접속 → Lightsail 사이트 표시 확인
  • [x] 외부 DNS 전파 확인: whatsmydns.net에서 전 세계 서버 전부 Lightsail IP로 전환 확인

대안 (미사용): hosts 파일 선행 테스트는 DNS 전파가 즉시 완료되어 불필요했음.

# 참고: DNS 전파 지연 시 아래 방법으로 로컬에서 선행 테스트 가능
# Windows: C:\Windows\System32\drivers\etc\hosts
# 관리자 권한으로 메모장 열기 → hosts 파일에 추가:
[LS_STATIC_IP]  [기존도메인주소]
# 테스트 완료 후 반드시 해당 줄 삭제

t03: SSL 인증서 설치

  • 목표: Let’s Encrypt SSL 인증서 설치 및 HTTPS 활성화
  • 교훈: bncert-tool은 SSL 설치+HTTP→HTTPS 리다이렉션+자동갱신을 한 번에 처리. www→non-www와 non-www→www는 상호 배타적이므로 원하는 방향의 반대를 먼저 물어볼 때 No를 선택해야 함. 자동갱신은 root crontab이 아닌 systemd timer 또는 /etc/cron.d/ 등으로 등록됨.

주의: SSL 설치는 DNS 전파가 완료된 후 실행해야 함. 전파 전 실행 시 인증서 발급 실패.

작업 (Lightsail 브라우저 터미널):

  • [x] bncert-tool 실행 완료:sudo /opt/bitnami/bncert-tool
  • [x] 도메인 입력 안내에 따라 진행:
    • Domain list: [기존도메인주소] + www.[기존도메인주소]
    • HTTP-to-HTTPS 리다이렉션: Yes
    • www-to-non-www 리다이렉션: Yes (non-www를 기본 도메인으로 사용)
    • non-www-to-www 리다이렉션: No
    • 이메일 주소 입력 (인증서 만료 알림용)
    • 동의 후 설치 진행
  • [x] 설치 완료 확인: https://[기존도메인주소] 접속 → HTTPS 정상 표시 (자물쇠 아이콘, SSL 오류 없음)

주의: 리다이렉션 옵션 선택 순서

  • bncert-tool은 non-www-to-www 활성화 여부를 먼저 물어봄
  • www-to-non-www와 non-www-to-www는 동시 활성화 불가 (상호 배타적)
  • non-www를 기본으로 사용하려면: non-www-to-www에 No → www-to-non-www에 Yes 순서로 선택

참고:

  • bncert-tool은 Let’s Encrypt 인증서 자동 갱신(90일마다)도 함께 설정함
  • 설치 완료 시 로그 파일이 /tmp/bncert-[타임스탬프].log에 저장됨

인증서 자동갱신 확인:

  • sudo crontab -l → no crontab for root (root crontab에는 미등록)
  • 자동갱신은 root crontab이 아닌 다른 메커니즘으로 설정될 수 있으므로 아래 순서로 확인:# 1. systemd timer 확인 sudo systemctl list-timers | grep -i renew # 2. 시스템 전체 cron 확인 ls /etc/cron.d/ cat /etc/cron.d/* # 3. bitnami 유저 crontab 확인 sudo crontab -u bitnami -l # 4. daemon 유저 crontab 확인 (실패) sudo crontab -u daemon -l # → "The user daemon cannot use this program (crontab)" (daemon 유저는 crontab 사용 불가, 정상)
  • 1~3에서 자동갱신 등록 확인됨

t04: DB 사이트 URL 도메인 복원

  • 목표: t08(S002)에서 고정 IP로 임시 변경한 siteurl/home을 원래 도메인으로 복원
  • 교훈: -e 옵션으로 인라인 SQL 실행 시 DB명이 두 번 입력되지 않도록 주의. 브라우저 터미널에서 복잡한 명령어는 대화형 모드가 더 안전함. Ctrl+F5 강력 새로고침으로 캐시된 리다이렉션 제거 필요.

작업 (Lightsail 브라우저 터미널):

  • [x] siteurl/home을 도메인으로 복원:/opt/bitnami/mariadb/bin/mariadb -u [LS_DB_USER] -p[LS_DB_PASSWORD] [LS_DB_NAME] -e " UPDATE wp_options SET option_value = 'https://[기존도메인주소]' WHERE option_name = 'siteurl'; UPDATE wp_options SET option_value = 'https://[기존도메인주소]' WHERE option_name = 'home'; " 주의: DB명([LS_DB_NAME])이 -e 앞에 1회만 입력되어야 함. 두 번 입력 시 usage 에러 발생.(선택) 대화형 모드로 실행하는 방법:/opt/bitnami/mariadb/bin/mariadb -u [LS_DB_USER] -p[LS_DB_PASSWORD] [LS_DB_NAME] 프롬프트(MariaDB [bitnami_wordpress]>) 진입 후 SQL을 한 줄씩 입력:UPDATE wp_options SET option_value = 'https://[기존도메인주소]' WHERE option_name = 'siteurl'; UPDATE wp_options SET option_value = 'https://[기존도메인주소]' WHERE option_name = 'home'; exit
    • DB 접속 정보 확인: cat /opt/bitnami/wordpress/wp-config.php | grep -E "DB_NAME|DB_USER|DB_PASSWORD|DB_HOST"
    • -p와 비밀번호 사이 공백 없이 입력
    • 프로토콜은 https:// (SSL 설치 완료 상태)
  • [x] Apache 재시작:sudo /opt/bitnami/ctlscript.sh restart
  • [x] https://[기존도메인주소] 접속 → 정상 표시 확인 (Ctrl+F5 강력 새로고침)
  • [x] Nav 등 내부 링크 클릭 → 도메인으로 정상 이동 확인 (S002에서의 리다이렉션 문제 해소)

t05: Yoast SEO 재활성화

  • 목표: S002 t09에서 임시 비활성화한 Yoast SEO를 재활성화하고 인덱싱 데이터 재생성
  • 교훈: Yoast Fatal Error의 근본 원인은 Yoast 자체가 아닌 Bitnami wp-config.php의 동적 URL 생성 ($_SERVER['HTTP_HOST']). 플러그인 재설치만으로는 해결 불가. wp-config.php에서 WP_HOME/WP_SITEURL을 도메인으로 하드코딩해야 해소됨. Google 소셜 로그인, Site Kit 연동은 마이그레이션 후에도 정상 동작.

배경: S002에서 마이그레이션 후 Yoast SEO pagination-helper.php:74 Fatal Error 발생하여 플러그인 폴더명을 wordpress-seo-disabled로 변경하여 비활성화한 상태.

작업 (Lightsail 브라우저 터미널):

  • [x] 플러그인 폴더명 복원:sudo mv /opt/bitnami/wordpress/wp-content/plugins/wordpress-seo-disabled /opt/bitnami/wordpress/wp-content/plugins/wordpress-seo
  • [x] https://[기존도메인주소] 접속 → Fatal Error 재발 확인
  • [x] 다시 비활성화:sudo mv /opt/bitnami/wordpress/wp-content/plugins/wordpress-seo /opt/bitnami/wordpress/wp-content/plugins/wordpress-seo-disabled

대응: 기존 플러그인 삭제 후 신규 설치 (인덱싱 데이터 초기화)

  • [x] wp-admin 접속 (Google 소셜 로그인이 마이그레이션 후에도 정상 동작함을 확인)
  • [x] wp-admin > 플러그인 > Yoast SEO 비활성화 상태 확인 → 삭제 실행 (대시보드에서 제거됨)
  • [x] Lightsail 터미널에서 잔여 파일 삭제:sudo rm -rf /opt/bitnami/wordpress/wp-content/plugins/wordpress-seo-disabled
  • [x] wp-admin > 플러그인 > 새로 추가 > “Yoast SEO” 검색 → 설치 → 활성화
  • [x] Yoast SEO 설정:
    • Google Site Kit 연결: “다시 로그인” 안내 → 계속 → 연결 정상 표시 확인
    • 작업 목록: 초기 설정 완료 ✓, Hello World 삭제 ✓, llms.txt 생성 → 버튼 눌러 완료 처리 ✓
    • 새 콘텐츠 생성: 미완료 (향후 글 작성 예정이므로 유지)
    • 알림 센터: “SEO 데이터 최적화 시작하기” → 버튼 클릭, 수 초 내 자동 최적화 완료
    • “Yoast AI로 SEO 제목 수정” 알림 → 숨김 처리
    • 처음 구성(First-time configuration) → 이미 모든 항목 완료 상태
  • [x] 프론트엔드에서 Yoast Fatal Error 재발 — 재설치 후에도 동일 에러 발생
  • [x] wp-admin에서 Yoast 비활성화 → 프론트엔드 정상 복구 확인
  • [x] 퍼머링크 재저장 시도 (설정 > 고유주소 > 변경없이 저장, 사용자 정의 구조 /%post_id%/) → 효과 없음
  • [x] 근본 원인 발견 및 수정: Bitnami wp-config.php의 동적 URL 생성
    • Bitnami 기본 설정:define( 'WP_HOME', 'http://' . $_SERVER['HTTP_HOST'] . '/' ); define( 'WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/' );
    • 문제점:
      1. HTTP_HOST가 없는 요청(봇, 내부 프록시) → URL이 http:/// → wp_parse_url() 반환값 false → Yoast Fatal Error
      2. http:// 고정 → SSL 설치 후에도 https://가 아닌 http://로 인식
      3. define()이 DB의 siteurl/home 값을 덮어씀 → t04에서 설정한 DB 값 무시
    • 수정 (Lightsail 터미널에서 sudo nano /opt/bitnami/wordpress/wp-config.php):define( 'WP_HOME', 'https://[기존도메인주소]' ); define( 'WP_SITEURL', 'https://[기존도메인주소]' );
  • [x] 수정 후 Yoast SEO 활성화 상태에서 프론트엔드 정상 접속 확인 (Fatal Error 완전 해소)

최종 적용: 동적 할당 + fallback 방식으로 교체 (하드코딩에서 전환)

  • 하드코딩 → 동적 할당 + fallback으로 변경 완료. 사이트 정상 작동 확인.
  • 수정 위치: /opt/bitnami/wordpress/wp-config.phpif ( ! isset( $_SERVER['HTTP_HOST'] ) ) { $_SERVER['HTTP_HOST'] = '[기존도메인주소]'; } define( 'WP_HOME', 'https://' . $_SERVER['HTTP_HOST'] . '/' ); define( 'WP_SITEURL', 'https://' . $_SERVER['HTTP_HOST'] . '/' );
  • 도메인 변경 시 fallback 값($_SERVER['HTTP_HOST'] = '...')만 수정하면 됨
  • 성능 영향 없음 (isset() 1회, 나노초 수준)
  • 상세 분석 및 버그 리포트 초안: 2_Wiki/Yoast_Bitnami_FatalError.md 참조

주의: 브라우저 터미널에서 nano 사용 시

  • Ctrl+W(nano 검색)는 브라우저의 탭 닫기 단축키와 충돌 → 화살표 키로 이동하거나 F6 사용
  • 저장: Ctrl+O → Enter, 종료: Ctrl+X

t06: 활성화 결과 검증

  • 목표: 도메인+HTTPS 환경에서 사이트 전체 정상 동작 확인
  • 교훈: Bitnami wp-config.php의 동적 URL 생성이 플러그인 Fatal Error의 근본 원인이 될 수 있으며, 플러그인 재설치나 퍼머링크 재저장으로는 해결 불가. wp-config.php 수준에서 HTTP_HOST fallback + HTTPS 프로토콜 수정이 필요. 브라우저 터미널에서 nano 사용 시 Ctrl+W 충돌 주의.

Yoast SEO Fatal Error 시행착오 요약:

#시도결과
1S002 t09: 플러그인 폴더명 변경으로 비활성화프론트엔드 복구, 근본 해결 아님
2S003 t05: 폴더명 복원(mv)으로 재활성화Fatal Error 재발
3S003 t05: 기존 플러그인 삭제 후 wp-admin에서 신규 설치wp-admin에서는 정상, 프론트엔드 Fatal Error 재발
4S003 t06: 퍼머링크 재저장 (rewrite rules 재생성)효과 없음
5S003 t06: wp-config.php 동적 URL → 도메인 하드코딩해결
6S003 t06: 하드코딩 → 동적 할당 + fallback으로 교체해결 (최종)

근본 원인: Bitnami wp-config.php가 $_SERVER['HTTP_HOST']로 WP_HOME/WP_SITEURL을 동적 생성 → HTTP_HOST 미설정 요청에서 wp_parse_url() 실패 → Yoast pagination-helper.php:74 Fatal Error

  • 상세 분석 및 버그 리포트 초안: 2_Wiki/Yoast_Bitnami_FatalError.md 참조

검증 항목:

  • [x] https://[기존도메인주소] → 메인 페이지 정상 표시 (Yoast 활성 상태)
  • [x] http://[기존도메인주소] → HTTPS로 자동 리다이렉션 확인
  • [x] wp-admin 로그인 정상
  • [x] Nav 메뉴 클릭 → 도메인 내 정상 이동
  • [x] 게시글 탐색 → 이미지, 레이아웃, 콘텐츠 정상
  • [x] 미디어 라이브러리 이미지 정상 표시 확인
  • [x] 모바일 브라우저: wp-admin 및 프론트엔드 모두 정상 접속 확인

사후 점검 및 기존 호스팅 서비스(Cloudways) 해지

요약정보

  • 목표: 마이그레이션 완료된 사이트의 안정화 점검, 불필요 항목 정리, Cloudways 해지
  • 배경: S001(사전 준비), S002(데이터 마이그레이션), S003(DNS+SSL+사이트 활성화) 완료. 사이트 정상 동작 확인됨. 최소 1주 안정화 기간 후 Cloudways 해지 예정
  • 교훈: Cloudways 전용 플러그인(Breeze)은 마이그레이션 후 즉시 제거. SMTP는 실제 사용하지 않으면 스킵 가능. Automatic snapshots은 7일 보존 대비 $2/월이므로 소규모 블로그에서는 비용 대비 효과 낮음 — 필요 시 수동 스냅샷 활용. Cloudways는 앱 1개 서버에서 앱만 삭제 불가, 서버 삭제 필요. 계정 해지는 영구적(동일 이메일 재사용 불가)이며 잔여 청구금은 후불 자동 결제.

상세내용

t01: 퍼머링크 갱신

  • 목표: .htaccess 재생성으로 URL 구조 정상 동작 보장
  • 교훈: SSL 및 wp-config.php 수정 후 퍼머링크 재저장하여 .htaccess 최신 상태를 보장하는 것이 안전.

작업:

  • [x] wp-admin > 설정 > 고유주소 > 변경 없이 변경사항 저장 클릭
    • 현재 사용자 정의 구조: /%post_id%/
    • S003 t06에서 이미 1회 수행했으나, SSL 및 wp-config.php 수정 후 재수행
  • [x] 프론트엔드에서 게시글 접속하여 URL 정상 작동 확인

t02: Breeze 플러그인 제거

  • 목표: Cloudways 전용 캐시 플러그인 제거
  • 교훈: Cloudways 전용 플러그인은 마이그레이션 후 반드시 제거. Lightsail에서는 Varnish가 없으므로 Breeze 불필요.

작업:

  • [x] wp-admin > 플러그인 > Breeze > 비활성화 → 삭제 완료
  • [x] 삭제 후 사이트 정상 동작 확인

t03: SMTP 설정

  • 목표: 이메일 발송 기능 확보 (비밀번호 찾기, 문의 폼 등)
  • 교훈: 현재 이메일 발송 기능 미사용이므로 스킵. 향후 필요 시 WP Mail SMTP + 외부 서비스 연동 필요.

결정: Skip — 별도 이메일 발송 기능(문의 폼, 회원가입 등) 사용하지 않으므로 현재 설정 불필요.

  • 향후 필요 시: WP Mail SMTP 플러그인 + Gmail SMTP / SendGrid / Amazon SES 연동

t04: Site Kit by Google 재연동 확인

  • 목표: Google Analytics/Search Console 연동 정상 작동 확인
  • 교훈: Site Kit 대시보드에서 Search Console, Analytics, PageSpeed Insights, Google 로그인 4개 기능 모두 마이그레이션 후 정상 동작. S003 t05에서 확인했던 “Google 소셜 로그인”은 Site Kit의 Google 로그인 기능이었음.

작업:

  • [x] wp-admin > Site Kit > 대시보드 접속 → 데이터 정상 표시 확인
  • [x] Site Kit 설정에서 4개 항목 정상 동작 확인:
    • Search Console: 정상
    • Analytics: 연동 정상 (데이터 수집은 추후 확인)
    • Google 로그인: 정상 (S003 t05에서 확인했던 소셜 로그인 기능의 출처)
    • PageSpeed Insights: 정상

추후 확인사항:

  • [ ] Google Analytics 데이터 수집 정상 여부 (1~2일 후 대시보드에서 신규 트래픽 데이터 확인)

t05: wp-content-original 삭제

  • 목표: S002 t07에서 백업해둔 Lightsail 기본 wp-content 삭제
  • 교훈: 안정화 확인 후 불필요한 백업 폴더는 디스크 절약을 위해 삭제.

작업 (Lightsail 브라우저 터미널):

  • [x] 삭제 완료:sudo rm -rf /opt/bitnami/wordpress/wp-content-original
  • [x] 삭제 후 사이트 정상 동작 확인

t06: Automatic Snapshots 활성화

  • 목표: Lightsail 자동 백업 설정
  • 교훈: Lightsail automatic snapshots은 디스크 전체 크기(40 GB) 기준 과금, 최근 7일만 보존. 비용 대비 보존 기간이 짧아 소규모 블로그에서는 불필요할 수 있음.

결정: Skip — 최근 7일만 보존되므로 활성화하지 않기로 결정.

과금 검토:

항목Lightsail Automatic Snapshots
디스크 크기40 GB ($7 플랜)
단가$0.05/GB/월
월 예상 비용$2.00/월
보존 기간최근 7일 (이전 자동 삭제)

Cloudways와 비교:

항목Cloudways BasicLightsail $7 플랜
자동 백업포함 (추가 비용 없음)별도 과금 ($2/월)
보존 기간수 일~수 주최근 7일
총 월 비용~$28~36/월$7 (스냅샷 미사용 시)
  • 필요 시 수동 스냅샷(Lightsail 콘솔 > Snapshots > Create snapshot)으로 특정 시점 백업 가능

t07: Cloudways 해지

  • 목표: 기존 Cloudways 호스팅 해지
  • 교훈: Cloudways는 앱 1개인 서버에서 앱만 삭제 불가 → 서버 자체 삭제 필요. 후불 방식이므로 잔여 청구금은 다음 주기에 자동 결제. 계정 해지는 영구적이며 동일 이메일 재사용 불가. Add-on(Integrations)에서 무료 서비스(Application Migration)는 과금 없으므로 별도 해제 불필요.

결정: Cloudways 결제일이 임박하여 1주 안정화 기간 없이 즉시 진행.

  • S003에서 DNS+SSL+전항목 검증 완료, S004 t01~t05 사후 점검 완료로 안정화 충분히 확인됨

해지 작업:

  • [x] Cloudways 콘솔에서 앱 삭제 시도 → 앱만 삭제 불가 (서버에 앱이 1개뿐이면 앱만 지울 수 없고 서버 자체를 삭제해야 함)
  • [x] 서버 삭제 진행
    • Cloudways에서 삭제된 서버는 14일간 백업 제공 (필요 시 복원 가능)
  • [x] Add-on 확인: 좌측 메뉴 > Integrations에서 Application Migration만 enable 상태 확인
    • Application Migration은 무료 제공 서비스(첫 1회 무료)이므로 과금 없음, disable 불필요
  • [x] 계정 해지 완료:
    • Account > Profile > Cancel your Account
    • “I agree to the above conditions, please delete my account and remove my data permanently” 체크 → Cancel my Account
    • 확인창에서 이유 입력 후 Cancel 버튼 클릭
    • 상태: Your account is in cancellation process. Access is limited to the Billing section to settle your final dues.
    • 로그아웃 후 재로그인 시에도 동일한 Billing 한정 접속 화면 표시됨을 확인
    • 잔여 청구금은 후불(pay-as-you-go) 방식으로 다음 결제 주기에 자동 결제 후 종료

계정 해지 시 주의사항 (Cloudways 안내):

  • 플랫폼 내 모든 작업 불가
  • 동일 이메일/비밀번호로 재로그인 불가
  • 모든 데이터 영구 삭제 (복구 불가)
  • 재사용 시 새 이메일로 재가입 필요
  • 서버, 앱, add-on, 서비스 모두 삭제됨

결론

  • 수동으로 백업 및 호스팅 변경을 진행했고, 결과적으로 아주 깔끔하게 이사에 성공함
  • 혼자서는 못했을 것 같은데 프로젝트 전체를 ELF 프로토콜에 넣고 LLM으로 로컬 문서 검색 증강을 돌리니 내역 추적과 변경이 잘 되었고, 문제 해결도 쉬웠음
  • 심지어 도중에 발생한 버그의 해결법까지 제시해서 현재 해당 플러그인 운영주체에게 깔끔하게 보고까지 완료함

후기

기존에는 업무용으로만 사용하던 ELF 프로토콜을 이번에 취미에도 적용해 보았다. 이 내용을 일일이 수동으로 기록했다면 정말 힘들고 빼먹는 내용들도 많았을 텐데, 로컬에서 antigravity로 열어서 로컬 문서 검색 증강 + 유료 LLM의 강력한 성능을 최대한 발휘하니 전체 과정을 아주 상세히 기록하면서도, 반나절 정도 만에 이 복잡한 작업을 완수할 수 있었다.

한 가지 언급하고 싶은 점은, 보안과 성능 문제이다. 아무래도 개인정보 이슈도 있어서 중요정보는 LLM에게 알려주지 않고 진행했고 기록도 개인정보를 담지 않도록 노력했는데, 정말 중요한 정보가 포함된 것이 아니었다면 전 과정을 자동화로 진행하여 훨씬 빠른 시간에 끝낼 수 있었다고 생각한다. 전체 시간의 절반 정도를 LLM의 출력을 이해하고 다음 진행하는 데 썼는데, human in the loop에서 이미 사람이 병목이 되는 것을 뼈저리게 느꼈던 하루였다. 그래도 이전에 OpenAI의 프롬프트 출력에서 API키 유출사건도 있고 해서 어떻게든 최중요 정보는 온라인상에 두지 않는 것이 맞다고 생각한다.

필자의 블로그 이름인 ProjectEli는 스마트폰도 없던 2000년대 중반부터 시작했던, 삶의 전 부분을 디지털 정보로 기록하여 정보 손실을 막고 개인 두뇌와 경험의 한계를 넘어서고자 하는 프로젝트의 이름이다. 약 20년 뒤인 2026년에 드디어 이것이 일부 가능해졌다는 것을 확인한 점에서 개인적으로는 매우 감회가 새로웠다.

이전에 local LLM으로 작동하는 음성인식 스마트 스피커를 만들었던 적이 있는데, 앞으로 하드웨어 성능이 발전되어 개인용 그래픽카드에서도 현재 클라우드 LLM 수준의 성능을 확보할 수 있다면 이것이 아주 가속화되지 않을까 한다. 아직 많은 사람들이 이런 agentic workflow에 접근 불가능한 것으로 알고 있는데, 수동으로라도 LLM이 쉽게 읽을 수 있는 프로토콜로 기록해 둔다면 나중에 활용도가 높을 것이다. 필자의 ELF 프로토콜이 이 과정에 조금이라도 도움이 될 수 있다면 매우 보람찰 것 같다. 끝.

0
, ,

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

더 많은 글들

ProjectEli 2006-2026, All rights reserved.

목차

← 목차