티스토리 게시글을 워드프레스로 옮기는 방법과 URL·파일 용량 문제 해결
티스토리에서 워드프레스로 블로그를 옮길 때 가장 번거로운 부분은 게시글 본문과 이미지를 한꺼번에 이전하는 작업입니다. 티스토리 백업 파일을 직접 분석해 가져오거나 공개 글을 크롤링하는 방법도 있지만, 설정과 사후 정리가 필요합니다. Mytory가 개발한 티스토리 마이그레이션 플러그인은 이 과정을 워드프레스 관리자 화면에서 처리할 수 있도록 단순화한 도구입니다.
다만 ‘백업 파일을 업로드하면 바로 끝난다’고 생각하면 곤란합니다. 파일 크기 제한, 서버 처리 시간, 이미지 썸네일 생성, 숫자형 URL 문제 때문에 사이트 규모에 따라 작업 방식이 달라집니다. 특히 검색 유입이 있는 블로그라면 글이 정상적으로 들어왔는지만 확인할 것이 아니라 이전 주소를 어떻게 연결할지도 함께 계획해야 합니다.
플러그인 이전 방식이 처리하는 범위
먼저 티스토리 관리자 화면에서 관리 → 블로그 → 데이터 관리로 이동한 뒤 ‘데이터 관리하기’와 ‘블로그 백업’을 실행합니다. 백업 결과에는 게시글별 HTML 파일과 이미지가 포함되며, 한 번 백업한 뒤에는 30일이 지나야 다시 백업할 수 있다는 조건이 있습니다. 이전을 시작하기 전에 백업 파일을 여러 장소에 보관하는 편이 안전합니다.
워드프레스가 설치된 뒤에는 Mytory가 배포한 플러그인을 내려받아 플러그인 → 플러그인 추가 메뉴에서 업로드 방식으로 설치하고 활성화합니다. 이후 도구 → 티스토리 가져오기에서 백업 파일을 지정하면 게시글과 첨부 이미지의 임포트를 진행할 수 있습니다.
플러그인에서 선택할 수 있는 주요 항목은 날짜 유지, 태그 가져오기, 카테고리 가져오기, 이미지 WebP 변환입니다. 날짜를 유지하면 기존 글의 발행 시점을 기준으로 워드프레스 게시글을 만들 수 있고, 카테고리와 태그를 함께 가져오면 이전 후 분류 체계를 다시 만드는 수고를 줄일 수 있습니다.
호스팅과 도메인이 결과에 영향을 주는 이유
티스토리는 별도의 웹호스팅을 준비하지 않아도 되지만, 자체 워드프레스를 운영하려면 서버가 필요합니다. 방문자가 많거나 여러 사이트를 운영할 예정이라면 클라우드웨이즈 같은 클라우드 기반 호스팅을 검토할 수 있고, 상대적으로 트래픽이 적은 사이트라면 서울 서버를 제공하는 ChemiCloud 같은 선택지도 고려 대상이 될 수 있습니다.
국내 호스팅으로는 카페24나 가비아를 사용할 수 있지만, 요금만 볼 것이 아니라 웹 용량과 트래픽을 확인해야 합니다. 티스토리에 이미지가 많이 포함되어 있다면 워드프레스에서 원본 이미지 외에 썸네일 파일까지 추가로 생성되므로 실제 백업 파일보다 더 많은 저장 공간이 필요할 수 있습니다. 테마와 플러그인에 따라 이미지 한 장에서 여러 크기의 썸네일이 만들어지는 점도 놓치기 쉽습니다.
개인 도메인을 계속 사용할 계획이라면 도메인 연결과 DNS 변경 시점도 이전 일정에 포함해야 합니다. .com, .co.kr, .kr, .net은 비교적 무난하지만, 첫해 등록비가 낮은 일부 도메인은 갱신 비용이 크게 오를 수 있으므로 장기 비용을 따져야 합니다. 호스팅과 도메인을 별도 업체에서 관리할 경우 네임서버 또는 DNS 레코드 설정을 직접 확인해야 합니다.
파일이 크면 업로드보다 분할이 먼저다
워드프레스의 ZIP 업로드 가능 크기는 플러그인보다 서버 설정의 영향을 크게 받습니다. 백업 파일이 제한 용량을 넘으면 관리자 화면에서 파일을 선택하는 단계부터 실패할 수 있습니다. 이때는 백업 파일을 글 100개 또는 환경에 따라 40개 정도의 단위로 나누어 여러 차례 가져오는 방법을 사용할 수 있습니다.
2026년 2월 업데이트 내용 기준으로는 백업 파일의 압축을 푼 뒤 FTP 또는 SFTP로 서버에 업로드하고, 플러그인에서 해당 파일을 읽어 가져오는 방식도 추가되었습니다. 이 방식은 웹 관리자 화면의 업로드 제한을 피할 수 있다는 점이 장점입니다. 다만 FTP 업로드 경로와 파일 이름을 정확히 지정해야 하므로 초보자에게는 일반 업로드보다 오히려 확인할 항목이 많을 수 있습니다.
파일 용량이 업로드 한도 안에 들어오더라도 한 번에 너무 많은 글과 이미지를 처리하면 임포트 도중 멈출 수 있습니다. 글 수가 많거나 이미지가 많은 사이트라면 처음부터 전체 데이터를 한 번에 넣기보다 작은 분량으로 테스트한 뒤 50~100개 단위로 나누어 순차 처리하는 편이 안정적입니다.
| 상황 | 넣는 방법 | 먼저 확인할 것 |
|---|---|---|
| 백업이 업로드 한도 안 | 관리자 화면에서 그대로 업로드 | 서버의 업로드 용량 설정 |
| 한도를 넘음 | 40~100개 단위로 분할 | 분할 파일의 구조가 인식되는지 |
| 분할해도 실패 | 압축을 풀어 FTP·SFTP로 올린 뒤 읽기 | 업로드 경로와 파일 이름 |
| 이미지가 매우 많음 | WebP 변환을 끄고 원본으로 먼저 | 썸네일 생성분까지 포함한 저장 공간 |
WebP 변환은 속도보다 성공 여부를 먼저 확인
WebP는 일반적으로 이미지 용량을 줄여 페이지 전송량과 저장 공간을 낮추는 데 도움이 될 수 있습니다. 하지만 변환 작업은 서버의 이미지 처리 기능과 호스팅 환경에 의존합니다. 이미지가 많은 백업에서 WebP 변환을 동시에 실행하면 임포트 시간이 길어지고 서버 부하가 커져 오류가 발생할 가능성도 있습니다.
따라서 첫 테스트에서는 WebP 변환을 끈 상태로 글과 이미지가 정상적으로 들어오는지 확인하는 것이 좋습니다. 이후 일부 글을 대상으로 변환 결과와 파일 크기를 비교한 뒤 전체 적용 여부를 결정하면 됩니다. 클라우드웨이즈에서 WebP가 제대로 표시되지 않는 경우에는 애플리케이션 설정의 WEBP Redirection을 활성화한 뒤 다시 테스트하는 방법이 안내되어 있습니다.
WebP 변환은 필수 절차가 아닙니다. 이전 성공률과 원본 보존이 더 중요한 상황이라면 우선 원본 형식으로 이전하고, 이미지 최적화는 별도의 단계로 진행하는 편이 관리하기 쉽습니다.
가장 큰 변수는 티스토리 URL이다
이 플러그인의 기본 이전 방식에서는 티스토리의 숫자형 URL이 그대로 유지되지 않을 수 있습니다. 예를 들어 기존 글 주소가 숫자 기반이었다면 워드프레스의 고유주소 설정에 따라 새로운 주소가 생성될 수 있습니다. 글 내용이 모두 이전되어도 검색엔진에 저장된 기존 주소가 새 글로 연결되지 않으면 검색 유입과 외부 링크에서 손실이 생길 수 있습니다.
글 수가 적다면 임포트 후 워드프레스 편집 화면에서 각 글의 고유주소를 기존 형식에 맞게 수동으로 변경하는 방법을 검토할 수 있습니다. 글이 많다면 기존 주소와 새 주소의 대응표를 만든 뒤 301 리디렉션을 설정하는 방식이 현실적입니다. 301 리디렉션은 이전 주소를 방문한 사용자를 새 주소로 보내는 설정이므로, 주소가 바뀌는 이전에서는 글 자체를 옮기는 작업만큼 중요합니다.
개인 도메인을 티스토리에 연결해 사용했고 이미 구글이나 네이버에 노출된 글이 있다면 URL 정책을 먼저 정해야 합니다. 수동 변경이 가능한 규모인지, 자동 매핑이나 별도 작업이 필요한 규모인지에 따라 이전 난도가 크게 달라집니다. 플러그인만으로 모든 URL이 자동 보존된다고 가정해서는 안 됩니다.
임포트 후 확인할 항목과 자주 생기는 오류
가져오기가 끝나면 워드프레스 관리자에서 단순히 완료 메시지만 보지 말고 실제 데이터 수를 대조해야 합니다. 전체 글 수, 카테고리, 태그, 이미지가 예상과 맞는지 확인하고 대표 글을 열어 본문 서식과 이미지 표시 상태를 점검합니다. ‘총 0개 포스트를 가져왔습니다’라는 메시지가 나타나는 경우에는 분할한 백업 파일의 구조나 인식 방식에 문제가 있을 가능성이 있으므로 파일을 다시 준비하거나 관련 해결 방법을 확인해야 합니다.
대표 이미지가 비어 있을 때
블로그 목록이나 홈 화면에서 썸네일이 보이지 않는다면 첫 번째 본문 이미지를 대표 이미지로 지정해야 할 수 있습니다. 이 작업을 보조하는 방법으로 FIFU 플러그인을 사용할 수 있습니다. 다만 테마와 플러그인에 따라 대표 이미지 처리 방식이 다르므로 일부 글에서 먼저 확인하는 것이 좋습니다.
본문 서식이 깨져 보일 때
가져온 글이 일반 편집기에서 예상과 다르게 보이면 편집 화면에서 콘텐츠를 선택한 뒤 블록으로 변환하여 수정할 수 있습니다. 이후 GeneratePress처럼 가벼운 테마를 적용하거나 엘리멘터 같은 페이지 빌더로 레이아웃을 구성할 수 있지만, 페이지 빌더는 디자인 편의성에 비해 사이트 처리량을 늘려 속도에 영향을 줄 수 있습니다. 임포트 직후 테마를 크게 바꾸기보다 원본 데이터가 온전한지 확인한 후 디자인을 조정하는 순서가 안전합니다.
대규모 이전에서는 테스트 사이트를 먼저 만들고 일부 백업만 가져오는 것이 좋습니다. 중복 임포트가 발생하거나 원하는 형태로 들어오지 않을 수 있기 때문입니다. 문제가 반복되면 사이트를 초기화한 뒤 분할 크기, WebP 옵션, 서버 설정을 바꾸어 다시 시도하는 방법을 고려할 수 있습니다. 글이 수천 개이거나 숫자 URL을 반드시 유지해야 한다면 단순 플러그인 임포트보다 URL 매핑과 리디렉션까지 포함한 별도 이전 계획이 필요합니다.
