티스토리에서 워드프레스로 이사 후기

티스토리가 이상한 정책을 시작할 작년 6월. 불안감에 미리 워드프레스를 하나 만들어 두었습니다. 이사는 아니었습니다. 단지 워드프레스 블로그를 한번 추가로 개설해본 것입니다. 1000여개 가까운 포스트를 옮길 엄두가 나지 않았기 때문이고. 워드프레스가 익숙하지도 않았고 어렵다고 생각했기 때문입니다. 막상 워드프레스를 써보니 생각보다 어렵지도 않았고, 괜찮았습니다. 벼르고 벼르던 티스토리 이사를 이번에 거행하였습니다. 속이 후련합니다.

티스토리 이사 요약

이사한 곳 : 워드프레스
호스팅 업체 : AWS lightsail
이사 방법 : 수작업
포스트 수 : 약 1000개
소요시간 : 약 3주
2차 도메인 사용 유무 : 유

호스팅 업체 어디선택? (AWS lightsail, 클라우드웨이즈, 카페24?)

처음 워드프레스를 시작할 때 호스팅 업체로 선택한 것은 AWS lightsail 이었습니다. 클라우드웨이즈, 벌쳐, 카페24 등 많은 호스팅 업체가 있지만, 비교해봤을때 가장 가성비 좋고 믿을만했던 업체가 AWS 인 것 같습니다. 이번에 티스토리를 이사할 때도 다른 호스팅을 사용해볼까 하다가 결국 AWS 로 만들었습니다. (현재 워드프레스만 3개 운영중인데 모두 AWS 만 쓰고 있네요.) 다른 업체들의 경우 신뢰가 안가거나, 너무 비싸다고 생각되었습니다. 다만 AWS 의 경우, 뒤늦게 요금 폭탄을 맞았다는 후기들이 있어 요금에만 주의하면 좋을 것 같습니다.

티스토리 이사 어떻게 해야할까?

전체 포스팅을 어떻게 옮겨야하나. 이 부분이 가장 고민이었습니다. 도메인은 어차피 2차 도메인이니, 워드프레스를 새로 만들어 글을 모두 옮기고 글 주소를 똑같이 한 뒤, 도메인만 덮어씌우면 되지 않을까 생각했습니다. 예를들어 처음 워드프레스를 개설하면 주소가 http://12.34.56.78 이런식으로 됩니다. 원래 티스토리의 주소가 https://sondoctor.co.kr 이었고, 각 포스트마다 숫자로 주소가 되어있습니다. https://sondoctor.co.kr/1122 이런식이라, 각 포스트를 워드프레스로 복사하고 주소를 http://12.34.56.78/1122 이렇게 동일하게 한 뒤, 나중에 sondoctor.co.kr 이라는 도메인을 워드프레스로 옮기면 됩니다. 그럼 워드프레스 주소가 http://sondoctor.co.kr 로 바뀌게 되고 주소는 동일하게 유지할 수 있습니다. 이 후 인증서 (SSL, AWS lightsail 은 무료로 인증서 제공) 을 설치하면 최종적으로 주소가 https://sondoctor.co.kr 로 바뀝니다. 그럼 완성입니다.

티스토리 글 복사 어떻게 해야하나? 그냥 수작업으로 하자! 그게 맘편하다.

글을 옮기는 방법을 한참 고민해봤습니다. 워드프레스를 새로 만들고 (만드는 것은 금방됩니다.) 글을 어떻게 옮길지에 대해 1주일은 고민한듯 합니다. 티스토리 글을 백업 받아 (약 1 GB 용량) 서버에 업로드 한 후 여러 고수분들의 블로그 글, 유튜브 등을 보면서 따라서 진행해보았는데, 솔직히 잘 되지 않았습니다. 결국 chatGPT 의 도움을 빌려 AWS 서버에 업로드해둔 티스토리 html 파일들을 자동으로 워드프레스로 옮기는 php 를 즉흥적으로 만들어 실행해보았습니다. 이 또한 시행착오가 있었고 결국 작동을 하긴 했지만. 포스트마다 이미지 파일들은 제대로 보이지 않았고, 본문 글 배치도 엉망이었습니다. 다만, 포스트 제목과 포스트별 작성한 날짜는 제대로 입력이 되어 있었습니다. 저는 그걸로 만족하고 나머지 글과 이미지는 수동으로 하나씩 옮기기로 했습니다. 어차피 오래되어 가치없는 글, 이 블로그와 어울리지 않는 지극히 개인적인 글 등을 다 정리하고 싶기도 했습니다. 방망이 깎는 노인의 심정으로 서두르지말고 천천히 옮기자는 마음이었습니다. 2주간 800여개 포스트를 옮긴 것 같습니다. 평일 새벽시간, 주말 오전시간 등 틈나는대로 옮겼습니다. 200개 포스트가 아직 남아있긴하나, 빠른 시일내로 나머지 포스트도 옮길 계획입니다. (도메인을 빨리 세팅하고 테스트 해보고 싶었기 때문에 서둘렀습니다.)

티스토리 글을 복사해서 워드프레스로 붙여넣기. 그나마 빠른 방법

지금 이 글은 하나의 문단내 여러 문장이 있지만, 초창기 티스토리에 글을 적을 때, 네이버 블로그 처럼 문장 마다, 또는 한 문장에서도 여러번 줄바꿈을 시행하였습니다. 긴 글을 읽기 싫어하는 요즘 사람들의 트렌드에 맞추기 위해서였죠. 티스토리는 줄바꿈 (엔터) 을 하면 태그로 저장됩니다. 사실 태그는 문단을 나타냅니다. 진정한 의미의 줄바꿈은 태그입니다.

문제는 워드프레스에서 태그는 줄간격이 넓다는데 있습니다. (물론 이를 CSS 를 적용하여 줄간격을 조정할 수도 있겠으나 저는 그 방법을 잘 모르기도하고, 왠만하면 기본 워드프레스 CSS 를 유지하고 싶었습니다.) 그러다보니 티스토리에서 한 문단인 듯 보였던 글의 뭉치를 워드프레스에 복붙하면 각 줄마다 문단으로 바뀌어 줄 간격 여백이 커지고 글이 이상하게 보이는 것입니다. (아래 사진)

고민하다가 저는 워드프레스에서 문단내 줄바꿈 (shift + enter) 으로 바꿨습니다. ( 태그) 처음에는 일일이 손으로 shift + enter 를 눌러가며 편집을 했는데, 좀 더 편하게 해주는 웹도구를 또 즉흥적으로 만들었고 바로 아래 링크로 연결되어 있습니다. ( 를 로 바꿔주는 도구입니다. 이러한 작업은 완전한 자동이 아닌, 수동이라, 이또한 다소 불편하고 시간이 꽤나 걸리는 작업이긴 합니다.)

티스토리 워드프레스 이사 할 때 복사-붙여넣기 도구

또 단축키를 사용하면 그나마 빠르게 작업할 수 있습니다. 저는 <h4>나 <h5> 등으로 바꿔주는 단축키인 alt + shift + 4 또는 5 를 많이 사용했습니다. 단축키 목록은 아래 링크에서 더 자세히 확인할 수 있습니다.

워드프레스 블록 편집기(Gutenberg) 키보드 단축키 모음

이제 도메인을 씌우자.

바로 어제 일요일 새벽에 도메인 작업을 진행했었습니다. 도메인을 옮기고 다시 SSL 을 설치했습니다. 우여곡절이 있긴 하였지만, 그럭저럭 성공하였습니다. 이 때는 속이 후련했습니다. 주말 시간을 보내고 저녁에 사이트에 접속해보았는데 깜짝 놀랐습니다. 페이지 로드 속도가 엄청나게 느린 것입니다. 페이지 로드에 10~30초가 걸리니 도저히 사용할 수 없었습니다. 이렇게 느린 페이지를 누가 들어와 볼까요. 또 검색엔진에서도 순위가 밀릴 것입니다. 아무래도 도메인 바꾼 첫날이라 그런가보다 했는데, 시간이 지나도 상황은 나아지지 않았습니다.

워드프레스 도메인을 바꾼 후 왜 페이지 로딩이 느려졌을까?

정말 답답했습니다. 이런 고민을 하고 계신 분이 있을까봐 여기에 기록을 남겨둡니다. 다행히 지금은 문제가 해결된 듯합니다. 우선 이 상태로 1주일은 지켜볼 예정입니다.

정확한 원인은 모르지만 아마도 제가 잘못 했던 것이 도메인을 옮기기전에 여러 플러그인을 깔아둔 것이었습니다. 그것이 가장 주요한 원인이었던 것 같습니다. 먼저 rank math 플러그인과 google site kit 을 삭제했습니다. 그러더니 약간 페이지 로드 속도가 빨라졌습니다. 또 워드프레스끼리 글을 옮기는 워드프레스 가져오기 도구 플러그인을 삭제했더니 속도가 더 나아졌는데 그래도 페이지 로드에 3~7초가 걸렸습니다. 아직 문제가 남아있었습니다. 최종적으로 YARPP, short coder 플러그인을 삭제했더니 페이지 로드 속도가 더 빨라졌습니다. 여기서 요점은, 도메인 씌우기 전에 플러그인을 되도록 깔지 말라! 라는 것입니다. 도메인 바뀌고 로직이 꼬여 페이지 로딩이 매우 느려졌던 것 같습니다. 특히 YARPP 같은 자동으로 관련 포스팅을 나열해주는 플러그인이 핵심 문제였던 것 같습니다.

1주일 정도 한번 지켜보고 또 내용을 기록해보겠습니다.

또 다시 느려지다!

어떤 글의 카테고리를 수정한 후 다시 페이지 로딩속도가 현저하게 느려졌습니다. 해결된 줄 알았는데, 또 말썽입니다. 도메인을 입히기전 설치했던 플러그인은 이제 딱 2개, permalink manager 와 쉬운 목차 플러그인입니다. permalink manager 가 원인일 것 같아 삭제해보았으나 속도에는 변화가 없었습니다. 이럴때 바로 물어볼 수 있는 곳은 chat GPT! 일단 믿고 따라해보기로 했습니다.

쿼리모니터 플러그인을 설치하여 ‘느린 쿼리’ 를 분석해본 결과 wp_options autoload 쿼리였습니다. autoload=yes 옵션 정리를 해야한다고 phpMyAdmin에 들어가라고 합니다. 거기서 무거운 DB를 확인하고 삭제하라고… 나 phpMyAdmin 뭔지도 모르고… 들어갈 줄도 모르는데?

(1) AWS lightsail 호스팅시 phpMyAdmin 접속 방법 (설치 방법)

Lightsail 콘솔 → 인스턴스 선택 → 연결(Connect using SSH) 클릭하면 SSH 터미널이 열립니다.

sudo apt update
sudo apt install phpmyadmin

위 명령어를 각각 입력하면 phpMyAdmin이 설치되기 시작합니다. 설치하면서 몇 가지 옵션을 묻습니다.

웹 서버는 Apache2 를 선택합니다.
Configure database for phpmyadmin with dbconfig-common? 라고 물어보는데, phpMyAdmin이 자체적으로 데이터베이스를 설정할지 물어보는 것입니다. 이 떄 No 를 눌렀습니다.
Configuring phpmyadmin – Please provide a password for phpmyadmin to register with the database server. If left blank, a random password will be generated. MySQL application password for phpmyadmin 이라고 물어보는데, phpMyAdmin이 MySQL 서버와 통신할 때 사용할 계정 비밀번호를 설정하냐는 물음입니다. yes 선택 후 사용할 비밀번호를 입력합니다. (대문자, 소문자 구별, 특수기호 사용 가능합니다.) 컨펌을 위해 비밀번호를 한번 더 입력하라는 메세지가 이어서 나옵니다. 아까 정했던 비번을 다시 입력해주면 됩니다.

※ 참고 : AWS lightsail 에서 MySQL 실행 여부 및 상태 확인하는 명령어 (Bitnami 에서)

SSH 터미널에서 아래 문구 입력
sudo /opt/bitnami/ctlscript.sh status
아래와 같이 mysql 이 running 이면 정상인 상태.
apache already running mysql already running

(2) phpMyAdmin 설치 후 Bitnami 와 연결

설치 후 phpMyAdmin을 Bitnami WordPress에서 접근하려면 Apache 설정에 alias를 만들어야 하는데, SSH 터미널에서 다음 명령어를 실행합니다.

sudo nano /opt/bitnami/apache2/conf/bitnami/bitnami-apps-prefix.conf

다음 내용을 파일 맨 아래에 추가하거나 기존 파일이 없어 새로 만들어졌다면 아래 내용을 그냥 추가하여 저장하면 됩니다.

Alias /phpmyadmin "/usr/share/phpmyadmin"

<Directory "/usr/share/phpmyadmin">
    Options Indexes FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>

Ctrl+O를 누르면 저장할지 물어보는데 enter 를 누르면 되고, 저장이 되었다면 Ctrl+X를 눌러 나노편집기를 빠져나오면 됩니다.

이 후 Apache 를 재시작 해줍니다.

sudo /opt/bitnami/ctlscript.sh restart apache

(3) phpMyAdmin 접속하기

이 후 브라우저에서 “http://서버IP/phpmyadmin” 접속하면 phpMyAdmin 이 떠야하지만, 저는 실행이 안되고 “For security reasons, this URL is only accessible using localhost (127.0.0.1) as the hostname.” 메세지가 출력되었습니다.

이는 기본적으로 Bitnami는 보안 때문에 phpMyAdmin을 외부 IP에서 직접 접속하지 못하도록 localhost(127.0.0.1)만 허용하기 때문입니다. (Bitnami 스택의 phpMyAdmin 접근 제한 설정 때문)

그래서 SSH 터널링을 사용하기로 합니다. (이 때부터 슬슬 포기하고 싶어졌습니다. 너무 어려워…)

또 Bitnami Lightsail 서버는 비밀번호 로그인 대신 .pem 키 파일을 사용해야 한다고 합니다. (이 때 진짜 포기할까 생각했습니다.) 우선 SSH 키를 콘솔 인스턴스에서 다운받았습니다. 다운로드 폴더에 저장이 되있는 상태입니다. 그리고 아래 명령어를 윈도우 ‘명령 프롬프트’ 에 입력하였습니다. (윈도우키 + R 하면 실행창이 뜨는데 이 때 cmd 를 입력하면 명령프롬프트가 실행됩니다.)

ssh -i "C:/Users/Sondoctor/Downloads/sondoctor.pem" -N -L 8888:127.0.0.1:80 bitnami@12.34.56.78

위 내용을 .pem 키 파일이 실제로 있는 경로에 맞춰 수정해주고, 12.34.56.78 대신 실제 IP 로 바꿔서 실행해주면 됩니다. 뭔가 실행이 된 것 같은데, 커서만 깜빡이고 아무 변화가 없습니다. 그럼 성공입니다.

이제 브라우저에 다음 주소를 입력하여 phpMyAdmin 을 실행합니다.

http://127.0.0.1:8888/phpmyadmin

시간이 좀 걸리긴 했지만 잘 동작했습니다. 이제 ID 와 비밀번호를 입력해야 합니다. ID 는 root 를 입력하면 됩니다. 비밀번호는 AWS lightsail 의 SSH 터미널에서 다음 명령어를 입력하면 비밀번호를 확인할 수 있습니다. 이 비밀번호를 phpMyAdmin 로그인 화면에 입력하면 됩니다.

cat /home/bitnami/bitnami_application_password

(4) phpMyAdmin 에서 불필요한 autoload DB 확인 후 삭제하기

phpMyAdmin 에서 상단 좌측 부분에 ‘데이터베이스’를 선택합니다.
그리고 나타나는 목록 중 bitnami_wordpress 를 클릭합니다.
이 후 나타나는 테이블 목록 중에서 wp_options 를 클릭합니다.

저같은 경우에는 약 1500개 가량의 테이블 목록이 나타났습니다.

그래서 SQL 에 다음과 같은 코드를 입력하여 불필요한 테이블들을 삭제했습니다.

auto_saved_image 관련 항목 삭제

DELETE FROM wp_options
WHERE option_name LIKE 'auto_saved_image_%';

이를 실행했더니 테이블 목록이 500여개 정도로 확 감소했습니다.

캐시/임시 옵션 삭제

DELETE FROM wp_options
WHERE option_name LIKE '_transient_%';
DELETE FROM wp_options
WHERE option_name LIKE '_site_transient_%';

EML 플러그인 관련 임시 데이터 삭제

DELETE FROM wp_options
WHERE option_name LIKE 'eml_%';

위 명령을 실행하고 데이터를 삭제하자 이제서야 비로소 페이지로딩 속도가 빨라졌습니다. ★★★

그리고 기존 삭제했던 플러그인 관련 데이터들도 정리하기로 했습니다.

permalink manager 플러그인 관련 데이터 삭제

SELECT * FROM wp_options
WHERE option_name LIKE 'permalinkmanager_%';

또는

DELETE FROM wp_options
WHERE option_name IN (
'permalink_manager_options',
'permalink_manager_uris',
'permalink_manager_redirects',
'permalink_manager_exclude_post_types'
);

Rank Math SEO 플러그인 관련 데이터 삭제

DELETE FROM wp_options
WHERE option_name LIKE 'rank_math_%';

Jetpack 플러그인 관련 데이터 삭제

DELETE FROM wp_options
WHERE option_name LIKE 'jetpack_%';

Shortcoder 플러그인 관련 데이터 삭제

DELETE FROM wp_options
WHERE option_name LIKE 'shortcoder_%';

Google Site Kit 플러그인 관련 데이터 삭제

DELETE FROM wp_options
WHERE option_name LIKE 'googlesitekit_%';

근본 원인을 해결한 것 같아서 속이 시원합니다.

2025. 9. 13 추가 > 해결이 된 줄 알았으나 또다시 문제가 재발합니다. 이번에는 객체 캐시 설정을 한 뒤 해결되었습니다. (참고 포스팅 : 2025. 9. 13 – 워드프레스 객체 캐시 설정하기 (Object cache))