워드프레스에서 블로거닷컴으로 마이그레이션 진행한 과정

이번 워드프레스에서 블로거닷컴으로 마이그레이션 한 과정이다. 지나고 나서 되새겨 본 것이라 100% 정확하지는 않다. 게시물과 이미지를 가져왔고 댓글은 제외했다. 데이터 내에서 값을 찾고 변환하는 과정, 클라우드플래어 R2스토리지 API와 구글 블로거 API 활용 과정은 제미나이와 챗지피티의 도움을 받았다. 개발 언어는 파이썬이다. 

1. 워드프레스의 tool → export 로 게시물 내보내기. 
2. 이 xml은 블로거닷컴에서 인식할 수 없는 형식이므로 워드프레스에 ForthFocus Atom XML Converter for Blogger™ 확장기능을 설치한다. 위에서 받은 xml을 이 플러그인에 업로드해서 블로거닷컴에서 인식할 수 있는 형태로 변환하여 다운로드. 
3. 이미지 파일은 워드프레스 백업,복원으로 유명한 updraftplus로 다운받아 압축을 풀어 한 폴더에 모음. 
4. 원본 이미지는 "이미지파일명.jpg(또는 png)"인데 "이미지파일명-가로x세로.jpg (또는 png)"로 추가 생성된 이미지가 많아 이 이미지들은 별도로 제외시킴. 단, 원본 이미지 이름 자체가 이 형식일 가능성이 없는지 확인해야 함.
5. 블로거닷컴으로 옮긴 게시물에 이미지를 일괄적으로 제 위치에 꽂아넣는 방법이 마땅치 않아 cloudflare의 r2 스토리지에 img.hof.pe.kr 도메인을 할당하고 여기에 이미지 원본 전체를 옮김. API키를 받아 rclone으로 전송했고 hof.pe.kr/wp-content/uploads/aaa.jpg 이미지는 이제 img.hof.pe.kr/aaa.jpg가 됐음. r2 스토리지 메뉴에서 도메인 할당하면 자동으로 클라우드플래어 NS에 항목이 추가됨. 
6. 블로거닷컴용 xml 파일에서 기존 이미지 URL 및 상대경로 (예: /wp-content/uploads/aaa.jpg)로 지정된 경우까지 찾아 img.hof.pe.kr 쪽을 바라보도록 변경
7. 블로거닷컴에 atom xml 파일을 올려 일단 게시물의 새로운 퍼머링크를 할당 받음. 
8. google blogger API로 새로 올린 전체 게시물의 제목, 작성일, 퍼머링크를 받아옴. 
9. 이 파일과 최초 워드프레스에서 다운받은 xml 에서 날짜와 제목을 기준으로 비교하여 같은 게시물의 워드프레스에서의 퍼머링크와 블로거닷컴으로 옮긴 후 새로 받은 퍼머링크 간 변환 테이블 생성 
10. 대략 이때쯤 블로거닷컴에서 사용자 지정 도메인을 사용하기로 하고 네임서버에서 도메인의 A레코드를 AWS Lightsail 인스턴스에서 블로거닷컴 쪽으로 변경 
11. 게시물 내에서 a href 링크가 나 자신(기존 워드프레스 때 퍼머링크)으로 향하는 경우가 있는지를 찾아 별도의 csv로 저장, 9번에서 만들어 둔 매칭 테이블을 활용하여 blogger API로 새 블로거닷컴의 퍼머링크로 교체, 업데이트

테마파일을 설치하고 보니 첨부한 이미지가 본문 레이아웃의 오른쪽으로 뚫고 나가는 경우가 있어 CSS를 수정했다. 별 내용없던 기존 about 페이지는 폐기하고 새로 블로그소개 페이지를 만들어 두었다. 

내부링크 수정 완료

워드프레스에서 블로거닷컴으로 옮겨오면서 내부의 글끼리 걸었던 링크들이 모두 깨지는 참사가 일어났다. 서비스마다 퍼머링크 구조와 정책이 다르니 당연한 일이고 감수하려고 했다. 세상이 좋아져서 다행이 예전 링크를 새 링크로 수정하는 방법을 AI를 통해 찾을 수 있었고, 방금 400여개 글에 포함된 링크를 모두 수정하였다. 블로거닷컴에 API로 연결을 해서 글 내용을 가져오고 변경해서 업데이트 하다보니 자동으로 처리를 했음에도 15분 정도 걸렸다.  주로 2005년부터 2007년 사이의 글에 집중되었고 2008년 이후로는 빈도가 뚝 떨어졌다. 블로그의 부흥기라고나 할까, 그 즈음에 유행했던 글쓰기 패턴이었나보다. 아무래도 작성 글 갯수도 지금보다 더 많았을 것이고. 

검수(?)하면서 살펴보니 다른 사이트로 연결한 링크들은 이미 99%이상 다 깨진 상태이다. 어쩔 수 없는 일이다. 내가 사용한 내 퍼머링크에 대해서는 게시물 단위로는 거의 다 살려놓았으니 링크에 대한 책임은 이 정도면 됐지 싶다. 

[업데이트]@2026.8.29 22:00

첨부된 이미지 중 워드프레스에서 이미 "이미지원본이름-가로해상도x세로해상도.jpg|png"  포맷으로 삽입된 경우들이 있다. 워드프레스때는 이미지를 하나 업로드하면 워드프레스가 임의로 4~5개의 해상도별 이미지를 임의로 생성해두는 것이 불만이었는데 이걸 실제로 포스트에 워드프레스가 사용했던걸 이제야 발견했다. 이미지를 클라우드플래어 r2 스토리지로 옮길 때 이 추가생성된 리사이즈된 이미지들은 제외하고 옮겼고, 그 여파로 여러 개의 게시물에서 이미지가 깨지는 현상이 생겼다. 총 39개 게시물을 찾아냈고 이 또한 모두 원본 이미지로 경로를 변경하여 복구해 두었다. 

블로거닷컴으로 완전히 왔다.

 워드프레스가 설치되어 있던 AWS 라이트세일 인스턴스를 완전히 삭제했다. 아침에 인스턴스를 중지 상태로 바꿔놓고 '블로거닷컴에서 적응이든 셋팅이든 실패하면  다시 워드프레스로 돌아갈거야?' 를 생각해보니 차마 다시 돌아가진 못하겠다. 인스턴스를 재부팅하거나 새로 생성하는 순간부터 따라오는 수많은 셋팅과 모니터링, 유지보수에 대한 책임과 스트레스를 또 감당할 생각을 하니 속이 메슥거릴 정도다. 말하자면 배수의 진이다. 워드프레스를 즉시 되살릴 수 있는 여지를 없애버렸다. 

블로그를 워드프레스에서 블로거닷컴으로 이전 중

 24년차에 접어든 블로그 생활 중 가장 큰 변화가 아닐까 싶다. b2로부터 시작해서 워드프레스로 운영하다가 오늘 블로거닷컴으로 이사를 했다. 아직 도메인을 옮긴것은 아니라 지금은 블로거닷컴에서 받은 주소만 갖고 있는 상태이다. 안정화가 되면 도메인도 이쪽을 향하도록 수정할 것이다. 일단은, 그간의 글과 이미지를 마이그레이션 해 왔다. 변경하면서 달라진 점들은 이러하다.

• 이미지는 모두 cloudflare의 r2 스토리지로 옮겼다. img.hof.pe.kr 주소를 부여하고 기존에 삽입됐던 이미지들은 모두 새 이미지 서버에서 불러오도록 하였다. 생각만큼 이미지가 많지는 않다. 3천여개의 파일에 300메가바이트 정도이다.  r2 스토리지는 10기가바이트까지 무료로 사용할 수 있다.  과거 글에 포함된 이미지는 외부 스토리지에 무료로 맡기고 새 글에 포함할 이미지는 블로거닷컴에 직접 첨부하여 글 작성을 한다. 
  
  
• 댓글은 옮겨오지 않았다. 새로운 댓글도 받지 않을 것이다.
  
  
• 내부 링크가 문제다. 내 글에서 내 예전글로 향하는 링크가 상당히 많았는데 이것의 링크를 재정비 하는 일이 생각보다 만만치 않다. 워드프레스에서 hof.pe.kr/123 같은 형태였던  링크가  블로거닷컴으로 옮겨오면서 hof.pe.kr/2006/02/my_new_post.html 이런식으로 바뀌었기 때문에 이 링크들을 찾아 바꾸는게 큰 일이다. 블로거닷컴에서 제공하는 컨텐츠 수정 api 를 사용하면 된다고 하는데 이를 위해 워드프레스와 블로거닷컴의 데이타를 비교해서 오류없이 링크 테이블을 만드는 일이 생각대로 되지 않았다. 1. 글의 제목 2. 워드프레스의 퍼머링크 3. 마이그레이션 한 이후 블로거닷컴의 퍼머링크를 스프래드시트에 만들어 두긴 했다. 블로그 뒤적거리다가 링크 만나면 하나씩 장부책 보고 바꿔보도록 해야겠다.
  
  
• 당연한 얘기지만 게시글의 고유한 URL인 퍼머링크가 싹 바뀌었다. b2시절부터 index.php?p=123 같은 구조를 계속 리다이렉션 해가며 hof.pe.kr/wp/123에서 hof.pe.kr/123 까지 링크가 깨지지 않게 유지해왔는데 이젠 다 블로거닷컴의 주소체계에 따라 링크가 변경되었다. 

워드프레스에 비해 디자인이든 데이터든 내가 하고싶은 대로 바꾸고 뒤적이고 자르고 붙이는 자유도는 낮아졌다. 그런데 강산이 두번이 넘게 바뀔 동안 써오던 플랫폼을 왜 옮겼느냐,

플랫폼을 관리하고 유지하는데 드는 노력과 비용이 생각보다 많이 낭비되고 있었다. 월5$짜리 AWS Lightsail 인스턴스에 워드프레스 하나 달랑 올려놓고 쓰고 있는데, 최근의 서버 접속지연 현상을 겪고 다양한 문제파악과 해결을 위한 시도를 해보면서 이 문제가 결국 메모리 부족이 원인인 것으로 의심되었다. 메모리를 늘이기 위해 상위 인스턴스로 업그레이드를 하자니, 무엇때문에 블로그를 쓰고 중요한게 무엇인지를 다시 생각해보게 됐다. 난 그저 쓰고 싶은 이야기 쓰고 남기면 이게 저장되고 나중에 찾아볼 수 있으면 되는것 아닌가,라는 질문을 다시 하게 됐다는 이야기다.  

아울러 오래전 글 내용들이 이제는 큰 의미도 없고, 퍼머링크를 유지하기 위한 비용도 그만한 값어치가 있나 싶기도 하다. 수십년전(...) 내 블로그로 향하는 링크를 갖고 있던 그 블로그들도 다 사라진 마당에 어디서 누가 예전 링크 클릭해서 들어온다고 링크를 관리하고 있지? 싶은것이지. 

골치아픈 플랫폼 관리의 문제는 구글에서 잘 해줄테니, 나는 그저 돌고돌고 돌아 이제서야 편안하게 글쓰고 저장버튼 누르는 즐거움을 누려볼까 한다.

클라우드플래어의 프록시 서비스 들어갔다가 뺀 이야기

6월에 aws 라이트세일 블루프린트가 기존 비트나미 패키지에서 라이트세일 패키지로 변경되면서 새 인스턴스를 만들어서 이 블로그를 옮겼다. 이후로 업타임로봇의 5분주기 핑 테스트에서 잦은 서버 접속불가 현상이 생기기 시작했다. 할 수 있는 원인파악 방법과 대응을 해 보았으나 전혀 효과가 없었다. 인스턴스간 편차가 있나 싶어 새 인스턴스를 서너개 교체해 보았다. 오랜 세월 운영하며 워드프레스 DB가 꼬였나 싶어 새로 설치하고 순수한 게시물 데이타XML과 첨부 이미지만 옮겨와 보았다. 모든 플러그인을 다 사용중지도 해 보았다. 그래도 하루, 길어도 이틀에 한번은 접속 불가 리포트가 날아왔다. 외부의 공격이 원인이라면 클라우드플래어가 막아줄테니 최후(?)의 수단으로 클라우드플래어의 방화벽 뒤로 숨어보았다. 어제 오후에 네임서버를 옮기고 프록시 서비스를 작동시켰다. 아침에 일어나보니 밤에 서버 순단현상이 생겼다는 업타임로봇의 알림메일이 도착해 있었다. 밤10시 반에 한번 왔었고, 두번째는 아침 6시에 또 한번 타임아웃 알림 메일이 도착했는데 다행이 그 순간에 컴 앞에 있던 중이라 즉각 이 블로그에 접속해보니, 어? 접속이 잘 됐다. 4분뒤에 접속이 복구됐다는 메일이 도착했다. 5분 주기 체크이긴 한데 체크한 순간에 접속이 안되고 즉각 메일이 왔고 내가 바로 블로그 접속을 했으니 1. 접속이 안되고 있는 중 2. 체크 3. 알림 4. 확인의 상황이 이루어지기까지는 수초 정도만 걸렸을 것이다. 접속이 안된다며? 그런데 나는 접속이 되네?

됐고, 일단 클라우드플래어의 프록시가 해결해 줄 수 있는 문제가 아님은 명확해졌다. 네트워크 타임아웃 "문제"를 해결하기 위해 클라우드플래어로 들어가는 것은 해결책이 아닌게다. 아울러 이 조치에 따른 부작용이라 해야할지, 문제가 생겼다. 블로그 접속에 종종 지연이 발생했다. 이게 0.5초 걸리던게 1초가 걸리는게 아니고 10초 지연도 걸리고 50초 지연도 걸리곤 한다. 당연히 용납할 수 있는 수준이 아니다. 특히 wp-admin 하위 메뉴로 들어가면 지연이 더 심해지는데 2분 가까이 걸린 적도 있었다. 페이지 열리는데 2분 걸리는 것이면 인터넷에 블로그를 쓸게 아니고 타자기로 쳐서 펀치 뚫어 보관하는 걸 고려해야하지 않겠는가.

일단 클라우드플래어로 옮긴 네임서버는 그대로 두고 프록시 기능을 다 껐다. 즉각 페이지 (메인 및 개별게시물) 로딩 속도가 0.3~0.4초대로 회복되었다.

두번째 조치는, 이건 마치 원효대사 해골물 같은 관점인데. 업타임로봇의 모니터링을 껐다. 뭔가 천만뷰 블로그를 운영하는 것도 아니고 매출이 나오는 쇼핑몰도 아니고, 하루에 한번 5분 이내 순단 현상이 일어난다고 보면 이것 때문에 스트레스받지 말고 그냥 모니터링을 중단하는게 낫겠다 싶었다. 여태까지 해본 조치들의 면면을 보면 해볼만큼 한계까지 해본 것이고 더 이상의 노력과 시간을 들이는 것은 흔한 말로 인건비도 안나오는 작업이다. 심지어 접속이 안된다는 알림이 오자마자 접속해보니 접속이 잘 되는 상황을 겪어보니, 어쩌면 허깨비를 앞에 두고 쉐도우복싱을 하는건 아닌가 하는 의심도 하게 됐다.

[업데이트]@2026.8.29
잘못된 접속 중단 알림은 아니었다. 며칠전 또 한번 접속 타임아웃 알림이 왔고 곧바로 접속 테스트 해보니 연결이 안됐다. 메모리는 다 사용했고 추가로 스왑이 엄청 잡혀 있었는데  에러 로그를 못 남길 정도로 지연이 있었다는 AI님의 진단이 있었다. 서버 사양을 한단계 올리라는 조언이 있었는데 그 사양이 충분한지, 앞으로도 영원히(?) 충분한지는 아무도 모르는 것. 

비트나미 인스턴스에서 라이트세일 인스턴스 후 잦은 에러

6월에 AWS Lightsail에서 이 블로그가 돌아가는 인스턴스를 비트나미 인스턴스에서 라이트세일 인스턴스로 변경하였다.CPU니 램이니 서버 스펙은 완전 동일했고 블로그도 잡데이터들 삭제하고 깨끗하게 정리해서 옮겼다. 문제는 그때부터 며칠에 한번씩 몇분씩 접속 불가 현상이 생겼다.

uptimerobot.com 에서 5분 간격으로 서버가 살았는지 죽었는지 찔러보고 접속이 안되면 메일을 보내준다. 그간 받은 로그를 차트로 그려보니 이러했다. 예전에는 일년에 한번 접속 끊기는 정도였는데 6월에 인스턴스를 바꾸면서부터는 일주일에 한번 이상 접속이 끊겼다가 복구되곤 하였다. 두달간 아파치의 error.log를 제미나이를 이용해 분석시켰고 두가지 대응방안을 받았다. 첫번째는 .htaccess를 이용하여 워드프레스 내부 파일에 직접 접속할 경우 403 에러를 내는 것. (기존에는 500 에러)

두번째는 비트나미 인스턴스 때는 있다가 라이트세일 인스턴스에서 사라졌다고 하는 fail2ban 을 다시 설치하여 비정상적인 접근을 하는 아이피들을 자동으로 ban시키는 것이다.

처음에는 .htaccess 을 이용하는 방법만 적용했는데 error.log를 보니 하루 2~3천회씩 접속하는 ip들이 보여서 fail2ban까지 함께 적용시켰다. 이상한 짓 하는 ip들이 잘 차단되는지, 무엇보다 네트워크 타임아웃 오류가 사라지는지 지켜봐야겠다.

[업데이트]@2026.8.17
하루만에 서버 접속불가 현상이 또 생겼다. 접속 불가가 생기기 직전 access.log와 error.log는 깨끗했다. fail2ban이 블록한 ip도 하나도 없이 0을 유지하고 있었다. 서버 cpu도 꾸준히(...) 1%~2% 부하를 벗어나지 않았다. 외부로부터 들어오는 악성 트래픽이 원인이 아닌가보다.

서버 사양이 동일하다 하더라도 비트나미에서 라이트세일로 블루프린트가 바뀌었고 어쩌면 환경 편차가 있을 수도 있으니 새 인스턴스를 만들었다. 저번에 고생한 것과 다르게 이번에는 다행이 구글드라이브에 자동 백업된 DB와 첨부파일이 문제없이 한방에 복원이 됐다. SSL 인증서도 라이트세일 웹 ui에서 쉽게 발급할 수 있었다. 처음 생성한 서버에서 생긴 오류가 두달 뒤에 생성한 서버에서는 괜찮을까, '그래 저번 서버는 뭔가 잔잔한 오류나 편차가 있던 서버였을수도 있잖아?' 하는 불안 반, 기대 반인 심정이다. 이래도 또 순단현상이 생기면 진짜 20년간의 워드프레스를 다 고정페이지로 발행해버리고 새 블로그를 하던지 해야하지 않겠나 싶기도 하다.