들어가는 글

블로그 1주년 자축! “짝짝짝”

경축스럽게도 그제(3월 24일)를 기해 이 블로그가 첫 돌을 맞이하게 되었다.

블로그를 처음 열었을 때는 1년은 고사하고 6개월은 운영할 수 있을지 장담하지 못했다.

(더 정확한 표현으로는 6개월을 채우기도 전에 블로그에 더 이상 글을 올리지도 못하고 방치하지는 않을까)

하지만 다행히 요 몇 달 간은 아무리 바쁜 시기에도 1주일에 한 번씩 글을 올리는 루틴을 유지하고 있다.

꾸준한 노력 덕분에 머지 않아 블로그 포스팅 개수 100개도 가시권에 들어오게 되었다.

그동안 어떻게든 루틴을 지키느라 끙끙대며 고생한 것을 생각하면 1주년 기념 파티라도 거창하게 하고 싶은 기분이었다.

고생했다, 나!

그럼 이제부터 터트려볼까 합니다

그렇게 100개의 포스팅을 눈앞에 둔 주인장은 1주년을 맞이해 깨끗하게 포맷되어버린 블로그를 마주했다.

말 그대로 ‘아무것도’ 남아있지 않았다.

언어 설정은 ‘영어’로 바뀌어있었고 포스팅 목록에는 ‘Hello World(처음 블로그 개설하면 생기는 테스트용 글)’만 덩그러니 남아 있었다.

혹시나하는 마음에 새로고침을 해보자 테마도 모두 깨져버리고 블로그 첫 화면이 모두 빈 페이지로 바뀌었다.

그냥 싸그리 날아갔다.

누구나 살면서 경험해본 적이 있을 것이다.

‘공든 탑이 무너지는 장면을 눈 앞에서 망연히 지켜만 볼 수밖에 없었던 순간’을 말이다.

사람의 정신을 죽이는 데는 고작 팝업 몇 개로도 충분하다.

그것이 졸린 눈을 비비며 밤을 새워 워드로 작성한 레포트이든,

그것이 오늘따라 삘 받아 액정 타블렛 위에 휘갈겨 그린 포토샵 PSD이든,

그것이 온갖 고차원적인 수식과 매크로의 하모니를 연주하는 엑셀이나, 인포그래픽을 방불케하는 PPT이든.

지금까지 만든 그것이 ‘저장(백업)’이라는 두 글자가 결핍되었다는 이유 하나만으로 완전히 ‘무(無)’로 돌아가게 된 것을 바라만 볼 수밖에 없었던 심정을 말이다.

하지만 그것도 필자가 마주할 뻔한 고통에 비하면 시시하다고 감히 이야기할 수 있다.

60미터가 넘는 거인이 인간을 집어삼키는 원초적 공포보다 무서운 건, 1년 동안 쌓아올린 포스팅이 통째로 초기화되는 ‘시시포스의 형벌’이다.

고작 ‘하루’가 날아가는 것만으로도 인간은 멘붕이 올 수 있지만, ‘1년’이 날아가는 건 내 인생을 부정당하는 수준의 고통을 받게 된다. (고 말은 하지만 막상 그런 일은 일어나지 않았다.)

그렇다면 독자분들은 궁금할 것이다. 도대체 주인장(필자)는 도대체 왜! 무슨 뻘짓을 했길래 그런 무시무시한 경험을 할 뻔했느냐고.

물론 이 글의 제목을 보신 분들은 이미 짐작하셨을 것이다.

그렇다.
이번 글의 주제는 바로 ‘호스팅 업체 변경하다가 블로그 폭파할 뻔한 썰’
이다.

‘이 글’은 바로 필자처럼 ‘호스팅 업체를 바꾸고 싶지만 그 어디에도 알려주지 않아서’ 혼자서 분투할 수밖에 없었던 경험담이자, 앞으로의 또 다른 ‘나(희생자가 될 뻔한 사람)’를 만들지 않기 위해 써낸 글이다.

물론 필자가 찾지 못했을 뿐, 어딘가에는 매우 간단하게 호스팅 마이그레이션을 하는 방법을 소개하는 글이 있을 수 있다.

그 글을 찾으신 분은 행운아다. 필자와 같이 블로그를 통째로 날려버릴 뻔하지 않았을 테니까!

그렇다면 서론은 여기까지 하고, 필자와 같이 ‘어중간한 지식으로 도전! 하는 유형의 사람’이 어떤 멍청한 선택을 거듭하며 결국에는 ‘체르노빌급’ 결과에 다다르게 되었는지 찬찬히 썰을 풀어보도록 하겠다.

---

단테의 호스팅 마이그레이션 ‘지옥편’

Q: 왜 호스팅 업체를 바꾸겠다는 바보같은 짓을 하셨어요? A: 돈 아끼려고요!

그렇다. 사실 모든 건 돈과 연결되어 있다.

블로그를 운영하다보니 알게 된 사실인데, ‘개인 블로그’라는 것도 일종의 임대료 고지서처럼 매 년마다 도메인 업체와 호스팅 업체에게 ‘자리세’를 지불해야 한다.

그러다 보니 블로그 주인 입장에서는 1주년이 되었다는 건 다시 말해 1주년 이벤트는 커녕 ‘갱신 고지서’를 내야한다는 것을 의미했다.

필자는 FastComet이라는 호스팅 업체에서 워드프레스 블로그를 개설했다.

사실 이 블로그를 개설할 때는 ‘호스팅’ + ‘도메인’으로 약 5만원이 들었다. 내 개인 블로그의 주소를 만드는 비용이라고 생각하면 그렇게 비싸다고 생각되지는 않았다.

하지만 1년이 지나 날아온 청구서의 갱신 요금은 그의 몇 배나 달하는 157달러(3~4배!)였다.

갱신 고지서를 받고야 깨달았다. 이 호스팅 업체들이 어떻게 장사를 하는 것인지.

대부분의 호스팅 업체들이 처음에 호스팅 계약을 맺을 때는 굉장히 저렴한 가격(약 7~80% 할인가)으로 제공해준 뒤, 갱신 시기가 오면 이제 ‘원가’를 갱신 비용으로 청구하는 전략을 취하고 있었다.

수익이라고는 1년에 0원을 창출하는 이 블로그에, 똑같은 서비스를 받기 위해 십만원이나 더 투자하는 건 최선이 아니라고 느껴졌다.

만약 서비스 품질이 더 나아지거나 무언가 그런 게 있었다면 모르겠는데, 그냥 곧이곧대로 갱신 청구서에 사인하는 건 오히려 바보같은 짓이 아닐까? 라고 생각이 들었다.

그래서 필자는 도메인과 호스팅 각각을 ‘최저가’로 제공해주는 업체를 물색하게 되었다.

이 선택이 얼마 후 예상치도 못한 지점에서 필자를 고통스럽게 하게 될 줄은 꿈에도 모른 채…

어쨌든, 필자는 조금이라도 지갑을 지키기 위해서 어쩔 수 없이 시간을 들여서 블로그를 ‘이주’할 계획을 세우게 되었다.

그 첫 번째 여정은 새로운 ‘도메인 업체’를 찾는 일이었다.

‘첫 번째 교훈’
첫 계약 할인가를 곧이곧대로 믿지 말자. 갱신할 때의 가격을 믿어라.

두 번째 교훈: 호스팅 업체는 꼭 도메인 업체와 같은 곳을 쓰자

두 번째 교훈은 너무 중요한 나머지 제목에도 박제했다.

필자처럼 ‘워드프레스는 쓰고 싶지만 호스팅이고 DNS고 나팔이고 공부하기 싫어’하는 사람들은 반드시 ‘호스팅’과 ‘도메인’ 업체를 같은 곳을 쓰는 것을 권장한다.

여기서 잠깐. 도메인과 호스팅이 각각 정확히 무슨 말인지 모르는 독자분이 계실 수 있으니 필자가 필자의 눈높이에 맞춰서 잠깐 설명하고 넘어가겠다.

도메인이란?

쉽게 말해 ‘사이트 주소’를 말한다. 우리에게 익숙한 모든 주소(예: naver.com 등)도 사실은 ip주소로 되어 있다. 그런데 ip주소는 숫자 또는 규칙성 없는 문자로 되어 있어서 우리가 기억하거나 구별하기가 어렵다. 예를 들어, naver.com의 ip주소가 125.209.248.6이면 우리는 기억하기가 어렵다. 그거를 기억하기 쉽게 ‘naver.com’로 만들어주는 게 바로 도메인이다.

호스팅이란?

일종의 ‘인터넷 주소 임대 서비스’를 말한다. 모든 블로그는 블로그 ‘주소'(부동산으로 비유하면 집 주소)를 갖는다. 그 ‘주소’를 갖기 위해서는 주소를 갖다 놓을 ‘서버'(부동산으로 말하면 집을 지을 토지의 주소)가 필요하다. 주소를 만들 때 서버를 함께 빌려주는 곳이있고(티스토리, 브런치 등), 서버를 빌려주지 않는 곳이 있다. (워드프레스 등) 워드프레스 블로그를 만들기 위해서는 서버를 빌려주는 호스팅 업체에 일정 비용을 지불하는 계약(호스팅)을 맺어야 한다.

필자는 ‘CloudFlare(클라우드플레어)’라는 업체에서 새로 도메인을 계약했다.

그 이유는 ‘높은 인지도’와 ‘합리적인 가격’때문이었다.

CloudFlare에서는 Cloudflare Registrar라는 서비스를 제공하는데, 도메인을 가격 할증 없이 등록 및 이전해주는 서비스다.

FastComet에서 제공하는 도메인 갱신 가격은 13.95달러였는데, CloudFlare의 신규 도메인 가격은 9.77달러로, 약 30%나 저렴했다.

안 그래도 클라우드플레어라는 회사는 필자와 같은 네트워크 관련 지식의 문외한도 이름 정도는 알 정도의 회사였고, 가격 정책이 투명한 점이 마음에 들었다.

그래서 FastComet에서 제공하는 자체 도메인에서 Cloudflare Registrar로 도메인부터 먼저 이전하게 되었다.

‘두 번째 교훈’
내가 전문가가 아니라면 ‘호스팅 업체’와 ‘도메인 업체’는 같은 곳을 쓰자.

새로운 호스팅만 계약하면 끝? 그러면 블로그 주소는?

‘이중 계약’이라는 말을 들으면 어떤 기분이 드는가? 뭔가 찝찝하지 않은가?

그렇다. 필자는 블로그 만료 며칠 전 일종의 ‘이중 계약’ 상태를 맞이하게 되었다.

필자는 이번에 호스팅 업체를 FastComet에서 Hostinger로 바꾸게 되었는데, 도메인 주소는 CloudFlare에서 계약을 한 상태였다.

이를 도식화하면 아래와 같다.

FastComet의 호스팅 계약이 만료되는 시점은 3월 22일이다.

필자는 호스팅이 만료되기 전인 3월 16일, Hostinger에서 신규 호스팅 1년 계약을 맺었다.

그리고 Hostinger에서 제공하는 블로그 이전 서비스인 ‘호스팅 마이그레이션’까지 진행했다.

자, 그렇다면 여기에서 독자분들께 깜짝 질문.

3월 16일 기준, ‘호스팅 마이그레이션’까지 끝낸 필자의 블로그 주소는 과연 어느 서비스 업체의 관할에서 관리되고 있었을까?

쉽게 말해, 3월 16일에 필자의 블로그 주소인 subculturegamer.com로 접속하면 어느 호스팅으로 연결되고 있는 걸까?

과거 호스팅 업체였던 ‘FastComet’일까? 아니면 이번에 호스팅 마이그레이션까지 마친 ‘Hostinger’일까? 아니면 필자의 도메인을 관리하는 Cloudflare이었을까?

정답은 잠시 뒤에 공개됩니다.

‘세 번째 교훈’
이번에 이전한 호스팅 업체에서 “Status: All Green”이 떠도 방심하지 말자.

Q: 백업은 안했어요? A: 일주일 백업도 충분한 줄 알았어요.

여기서 잠깐 논제를 바꿔, ‘백업’ 얘기를 해보고자 한다.

눈치 빠른 독자분들은 아마 이렇게 생각할 것이다.

이 블로그 주인장이 진짜로 멍청해서 ‘백업’이라는 걸 단 한 번도 하지 않은 멍청이가 아니고서야 블로그가 통째로 날아갈 리가 없다고.

‘플러그인’을 통해서 백업만 잘 해둬도 이런 불상사는 진작에 막을 것인데 1년간 블로그 운영한 사람이 그것도 모르는 거냐고.

그렇다면 잠깐 필자의 변명을 들어보시라. 먼저 플러그인.

‘블로그 통째로 백업해서 이사하기’와 같은 편리한 기능을 제공하는 플러그인은 ‘유료’다.

블로그 이사하는 데 그깟 돈이 대수냐 싶겠지만, 당시 필자가 신경을 쏟았던 건 바로 ‘안정적인 호스팅 마이그레이션’이지 블로그 데이터 백업이 아니었다.

All-in-One WP Migration와 같은 플러그인은 블로그의 모든 데이터를 백업해서 로컬로 export하는 기능은 제공했다. 하지만 동일한 플러그인을 사용해서 import하려고 하면 용량 제한이 1gb로 제한되는데, 이건 필자의 블로그 전체 데이터를 옮기기에는 턱없이 부족한 용량이었다.

용량 제한을 풀기 위해서는 위 플러그인을 매달 5.75달러로 프리미엄으로 이용하는 연간계약권을 구매해야 했는데, 그렇게 되면 백업에만 60달러가 넘는 비용을 지출하게 된다는 결론에 다다랐다.

혹여나 최악의 상황에서 블로그 주소를 바꿔 새로운 블로그에 모든 데이터를 이전한다면 위 방법도 가능하다.

하지만 위 방법을 택해도 ‘내 블로그 주소는 그대로 유지한 상태에서 모든 데이터를 안전하게 옮기기’라는 방법이 가능한지는 알 수가 없었다.

결론. 필자는 필자의 진짜 고민(호스팅 업체 변경)을 해결해주는 서비스가 아닌 플러그인 따위에 돈을 지출하고 싶지 않았다.

그리고 필자는 1주일마다 자동 백업이 되는 호스팅 서비스를 가입해뒀기 때문에 최악의 경우에도 모든 블로그 데이터를 날릴 위험은 피할 수 있을 거라고 생각했다. (이 글의 위기-결론 플롯의 치명적인 스포일러이지만, 이 백업 덕분에 살았다.)

그래서 플러그인을 이용한 블로그 백업과 이전은 일찌감치 포기했다.

그리고 백업 서비스에 관해 말하자면, ‘매일’ 백업을 하기 위해서는 마찬가지로 만만치 않은 돈이 든다.

이미 1주일마다 백업이 되는 무료 서비스를 받고 있는 점, 그리고 필자의 포스팅 업로드 주기가 1주일인 점을 고려했을 때 매달 약 2달러의 추가 금액 결제를 하면서까지 백업을 해야할 만큼 필자가 백업에 대한 중요성을 인식하지는 못했다.

최악의 경우에도 3월 16일자로 복구할 수 있겠다는 믿음이 있었다.

그래서 필자는 어떠한 백업 서비스를 추가로 하기보다는 블로그를 이전하는 방법에 대해 모색하기 시작했다.

그것이 이 글의 위기 파트로 가는 험난한 길의 첫 발걸음이 되었다.

(다시 한번 스포일러. 이번 글의 엔딩은 해피 엔딩이다. 그런 의미에서 이 글의 과정은 발암일지라도, 끝까지 읽어주셨으면 좋겠다.)

‘네 번째 교훈’
일주일 백업도 부족하다. 매일 백업이 가능하다면 그 방법을 찾아라.
호스팅 만료일에는 사고가 일어날 가능성이 매우 크다.
최소한 호스팅 만료일 전에는 반드시 ‘최후의 백업’을 남겨라.

3… 2… 1… 서버를 중지합니다.

아까 독자분들께 던졌던 질문,

‘호스팅 마이그레이션’까지 끝낸 필자의 블로그 주소는 과연 어느 서비스 업체의 관할에서 관리되고 있었을까?

의 정답은 과연 무엇이었을까?

3월 23일이 되자 마침내 진실이 밝혀졌다.

블로그에 접속하자 Acoount Temporary On Hold라는 페이지가 날 반겨주었다.

그렇다. 블로그는 아직 여전히 ‘이전 호스팅 업체’에 연결되어 있었던 것이다.

이전 호스팅 업체의 계약 기간이 만료되자 내 블로그는 ‘문제의 페이지’를 띄우며 뻗어버리고 말았다.

3월 16일에 Hostinger로 호스팅 업체를 변경하고 호스팅 마이그레이션까지 정상적으로 완료되어 안심하고 있던 필자에게 그야말로 청천벽력과도 같은 일이었다.

위 안내문에서 볼 수 있듯이 ‘check your billing’이라는 문구가 있는 것을 보면 결제와 관련된 문제가 있음을 암시한다. 즉, 이전 호스팅 업체에 갱신 요금을 ‘결제’하지 않았으니 위 문구가 뜬다는 것을 유추할 수 있었다.

필자의 블로그는 하루 아침에 ‘과거 호스팅 업체에 갱신 요금을 지불하지 않은 대가’로 하루 아침에 블로그가 잠정 중단되어버린 것이다.

관리자용 페이지에 접근해도 위 화면이 뜨고 있으니 그야말로 속수무책이었다.

필자에게는 이 문제를 해결할 ‘방법’이 필요했다.

그런데 왜 생각을 못 했을까. 이런 일이 일어났을 때 문제를 해결해주기 위해 호스팅 업체에는 24/7 상주 직원이 있다는 것을.

이런 비전문가보다 훨씬 더 잘 이 문제를 해결해줄 수 있는 직원에 의존하는 대신에, 왜 스스로 해결책을 찾아 나서게 된 것일까.

그건 그만큼 이 블로그에 일어난 문제를 어떻게든 내 힘으로 해결해야한다고 느꼈기 때문이었던 것일까.

그렇게 이 문제는 더 복잡해지기 시작한다.

‘다섯 번째 교훈’
패닉이 올 일이 닥치면 ‘전문가’부터 찾아라

잠깐, 그러면 내 글은 어떻게 되는 거지?

필자는 블로그가 멈춘 이유의 원인은 ‘호스팅 마이그레이션’이 정상적으로 완료되지 않았기 때문에 벌어진 것으로 보았다.

그렇지 않고서야 Hostinger에서 제공하는 ‘블로그 마이그레이션’이라는 서비스가 존재할 이유가 없었기 때문이다.

그래서 뭔가 모종의 이유가 있으리라 짐작하고, 호스팅 마이그레이션을 다시 실행시키기로 했다.

그런데 이때 필자의 머리를 스쳐 지나가는 어떤 위기 의식.

그건 그렇고, 그러면 저번 주에 올린 내 글은 어떻게 되는 거지?

다시 한번 마이그레이션을 한다고 생각했을 때 위의 그림이 그려졌다.

앞서 필자는 지금 내 블로그가 아직 Fastcomet에 묶여 있다고 판단했다. 그렇다면 저번 주에 작성한 글도 아직 Fastcomet에 연결되어 있을 터였다.

하지만 확신이 서지는 않았다. 만약 내 판단이 틀렸다면 필자가 저번 주 작성한 글은 말 그대로 공중분해되어버릴 수도 있는 리스크가 있었다.

그래서 필자는 이번 마이그레이션은 어떠한 리스크가 충분히 있을 수 있음을 짐작하고 로컬 백업 서비스를 실행하기로 했다.

Fastcomet과 Hostinger 양쪽 모두 말이다.

그런데 Fastcomet은 이미 필자의 블로그가 Cancelled 처리가 되어버리면서 백업조차 불가능한 상태로 전환되어 있었다.

이 과정에서 조바심이 나기 시작했다.

블로그 관리자 페이지도 접근이 막혀 버린 탓에 플러그인을 이용한 로컬 통백업마저 막힌 상황이었다.

만약 필자가 작성한 글이 Fastcomet에서 사용하던 블로그에 있고, 이것이 Hostinger로 무사히 마이그레이션된다면 필자가 저번 주에 작성한 글도 잘 이전되겠지만, 만에 하나라는 것도 무시할 수 없는 상황이었다.

이미 필자는 50% 이상 확률로 저번 주 작성한 글이 날아갈 거라고 예상했다.

그래서 Hostinger라도 로컬 백업을 해두어야겠다고 생각했는데,

호스팅어의 백업 데이터 시간은 필자가 블로그 글을 올린 시간보다 한참 전이었다.

마이그레이션이 실패하면 블로그 글이 날아가는 건 기정 사실인 셈이었다.

일단 블로그 포스팅 1개를 살리는 것보다는 블로그 전체를 살리는 게 더 중요했으니, 필자는 다음 단계를 밟기로 한다.

‘여섯 번째 교훈’
네 번째 교훈을 다시 한번 복창한다.

(일주일 백업도 부족하다. 매일 백업이 가능하다면 그 방법을 찾아라.
호스팅 만료일에는 사고가 일어날 가능성이 매우 크다.
최소한 호스팅 만료일 전에는 반드시 ‘최후의 백업’을 남겨라.)

단테의 호스팅 마이그레이션 ‘연옥편’

호스팅 마이그레이션, 다시 한번. 아니, 취소.

지금까지 ‘지옥편’을 거치며, 필자의 블로그가 정지되는 과정과 필자의 블로그 최신 글이 날아갈 위기에 처한 상황을 설명했다.

이번 ‘연옥편’에서는 필자가 ‘교만의 형벌’을 받는 과정과, 이 형벌의 기나긴 터널을 빠져나가기 위해 어떤 과정이 필요했는지 소개하고자 한다.

필자는 호스팅 마이그레이션을 실행하기 위한 버튼을 두고 갈등하고 있었다.

그 이유는 아래의 고민이 해결이 되지 않았기 때문이다.

‘그런데 호스팅 마이그레이션을 분명 성공했음에도 대체 왜 블로그가 예전 호스팅 업체에 연결되어 있는 거지?’

그건 필자에게 어떤 가능성을 시사했다.

‘호스팅 마이그레이션’은 사실 정확히 말하면 블로그를 ‘이전(migrate)’하는 게 아니라 블로그를 ‘복제(duplicate)’하는 게 아닐까하는 것을.

위와 같은 가설이 머리속에 그려지자, ‘호스팅 마이그레이션’을 다시 한번 한다고 해서 블로그 정지가 풀릴 거라고 생각이 들지 않았다.

어쩌면 필자가 해결해야하는 문제는 ‘호스팅’이 아니라 ‘도메인’ 업체에 있는 걸지도 모른다고 생각했다.

그래서 필자는 필자가 새로 구매한 도메인 업체인 ‘클라우드플레어’에서 답을 찾기 시작했다.

‘첫 번째 인사이트’
블로그는 ‘도메인’과 ‘호스팅’이 한 몸이다. 그러니 호스팅에서 문제가 일어나도 도메인도 같이 의심하라.
(feat. 두 번째 교훈이 기억나는가? 호스팅과 도메인이 한 업체면 편해진다.)

DNS? 함부로 건드려도 되나?

도메인 업체 Cloudflare에서 제공하는 옵션은 시쳇말로 너무나도 많았다.

이 과정에서 필자가 수많은 전문용어와 기능들 사이에서 헤멘 경험을 굳이 더 설명하지는 않겠다.

필자가 내린 결론은 ‘DNS라는 것이 수상하다’였다.

특히 가장 결정적인 이유는 이 DNS라는 곳에 기재된 많은 정보가 구 호스팅과 관련이 있어 보였다.

(cPanel, 메일 서버 주소 등등)

여기에 기재된 정보를 임의로 바꾸면 블로그가 더욱 혼란의 구렁텅이로 빠질 것 같아서 건들기가 찝찝했다.

하지만 무언가 대책은 세울 필요가 있었다.

그래서 DNS에 대해 알기 위해 자료를 찾아보기 시작했다.

어쨌든 필자가 위 정보에서 파악한 건 ‘메일’이나 블로그 ‘주소’ 등 다양한 정보가 위 DNS라는 것에 의해 관리되고 있다는 것이었다.

즉, 필자가 아까 생각했던 추론 – 도메인 주소가 예전 호스팅 업체의 주소와 연결되어있다 – 대로, 현재 블로그 연결 문제를 해결할 열쇠가 바로 이 DNS일 확률이 높아진 셈이었다.

필자의 이러한 추정을 방증하는 화면이 하나 더 있었는데, 바로 emails의 Connect Domain이라는 화면이었다.

위의 Current Records와 Expected Records를 비교해보면 뭐가 연결이 안 되어있는지 알 수 있었는데, 이 화면에 있는 모든 항목이 클라우드플레어의 과거 DNS Records와 연결되어 있어 문제가 일어나고 있었다.

다시 말해, 이번에 이주한 Hostinger에서는 위 화면을 통해 ‘너 이메일 못 받을거야. DNS가 예전 거로 되어 있으니 확인해봐!’라는 시그널을 보내준 셈이었다.

필자는 이것을 보고 이메일뿐만 아니라 다른 DNS Records도 모두 과거 호스팅 업체와 연결된 게 아닌가하는 단서를 얻었다.

도메인 업체인 클라우드플레어의 DNS 정보를 모두 새로운 호스팅 사이트의 정보로 최신화하면 어쩌면 문제가 해결될 수도 있지 않을까하는 생각이었다.

다음 단계로 넘어가기 위해서는 새로운 호스팅 업체인 Hostinger에서 DNS에 관한 정보가 있는지 찾아보기 시작했다.

‘두 번째 인사이트’
블로그 호스팅에 관한 중요한 정보는 DNS를 의심하라.

DNS 변경, 그리고 블로그 관리자 화면 복구

다행히 호스팅 업체 Hostinger에서는 DNS Zone Editor라는 탭에서 현재 내 블로그에 설정되어야 할 DNS 정보를 모두 기재해놓고 있었다.

사실 이 DNS 정보는 모두 ‘가변 데이터’다. 즉, 필자 마음대로 바꿔도 되는 정보들이다.

다시 말해, 필자가 앞서 건드리지 않은 한 위 데이터는 ‘디폴트 데이터’, 즉 신뢰해도 되는 데이터라고 생각했다.

그래서 필자는 도메인 업체 클라우드플레어에 등록되어 있던 DNS 정보를 ‘덜 중요해보이는 것’부터 천천히 삭제하며 위 DNS 정보로 바꿔 나갔다.

그리고 마침내 DNS를 모두 최신화한 뒤 접속하자, 그리웠던 필자의 워드프레스 관리자 화면이…

아니라 아래의 페이지가 필자를 반겨주었다.

지금까지 줄기차게 필자를 괴롭혀왔던 Account Temporary On Hold라는 화면 대신 SSL이라는 새로운 용어가 필자의 눈앞을 가로막게 된 것이다.

산 넘어 산. 그래도 필자가 무언가 건드려서 해결된 것이 있다는 점에서 나름 기분은 고무되어 있었다.

저 SSL handshake failed라는 오류만 해결하면 어쩌면 필자의 워드프레스 관리자 페이지를 정말로 볼 수 있지도 모른다는 희망이 생겨났다.

그리고 다행인 점은, SSL handshake failed – Error Code 525이라는 에러코드가 노출되어준 덕분에 필자가 어떻게 해야하는지 정확히 파악할 수 있었다.

Account Temporary On Hold라는 오류는 ‘어디서’, ‘무엇이’, ‘어떻게’, ‘왜’ 문제가 일어나는 건지 설명이 없었기 때문에 필자는 정말 많은 시행착오를 겪을 수밖에 없었다.

(그래서 필자는 UX 디자이너가 각 오류마다 어떻게 대응해야하는지 더 섬세하게 접근할 필요가 있다고 생각한다.)

어쨌든, 위 SSL 문제를 해결하기 위해 필자가 향한 곳은 바로 도메인 업체인 클라우드플레어의 SSL/TLS 탭이었다.

원래 위 화면에서 설정된 항목은 ‘전체(엄격)’이었는데, SSL 설정이 문제가 된다고 하니 위 옵션을 ‘가변’으로 조정했다.

뒤늦게 확인해보니, 에러코드 525를 해결하기 위한 정확한 솔루션이 바로 위의 설정을 바꾸는 게 맞았다. 호스팅 업체 한번 바꾸려다가 온갖 잡다한 지식만 늘어간다.

그렇게 설정을 바꾸고 나자, 마침내 필자는 아래의 화면을 마주하게 되었다.

필자가 저번 주(3월 17일)에 작성한 글이 리스트에 존재하지 않는, 필자의 블로그 관리자 페이지가 마침내 나타난 것이다.

수 시간이 걸려 마침내 블로그 재개장의 가능성이 훨씬 더 높아진 셈이었다.

하지만 여전히 블로그 일반 주소에 접근하면 위 오류가 발생하는 문제는 해결되지 않은 상태였다.

이 다음 해결책이 필요했다.

‘세 번째 인사이트’
문제는 하나씩 단계별로 해결하라.

호스팅 마이그레이션, 다시 한번. 아니, 취소. 아니, 해야겠어.

앞서 DNS 설정 변경과 SSL 문제를 해결한 필자는 마침내 ‘블로그 관리자 화면’을 다시 보게 되었다.

여기에서 모든 문제가 해결되었다면 좋았겠지만, 결국 필자는 호스팅 마이그레이션이라는 선택을 하게 된다.

그 이유는 다음과 같다.

• 첫째: 가장 최근에 작성한 3월 17일자 글이 날아갔다. 마이그레이션을 하면 이 글을 복구할 수 있을지도 모른다는 기대감이 있었다.
• 둘째: 여전히 블로그 일반 페이지는 접속이 되지 않는다. 여기부터는 어떻게 해야 복구가 가능한지 감이 오지 않았다.
• 셋째: 혹여나 필자가 3월 16일 진행한 호스팅 마이그레이션’이 정상적으로 되지 않았을 가능성이 있다. 지금까지 해온 모든 게 뻘짓이더라도, 다시 한번 마이그레이션을 하면 모든 블로그 이주가 정상적으로 예쁘게 될 수도 있다고 생각했다.

특히 첫째 이유가 컸다.

고생고생해서 작성한 글이 통째로 ‘없었던 게 되어버리는 것’은 정말 고통스러운 일이다.

아무리 일주일에 한번 글을 올리는 게으른 글쟁이 생활을 하고 있다지만, 깨물어서 안 아픈 손가락 없듯이 필자에게는 정말 소중한 한 개의 포스팅이었기 때문이다.

여기에서 멈추었어야 했다.

하지만 슬픔에 빠진 필자에게 호스팅 마이그레이션은 어쩌면 이 모든 필자의 고민을 해결해 줄 구원같이 여겨졌다.

그렇게 필자는 호스팅 업체인 Hostinger에서 호스팅 마이그레이션을 다시 한번 진행하게 된다.

어쩌면 돌아올지도 모르는 날아가버린 포스팅을 복구할 수 있을 것이라는 막연한 희망을 품고.

그렇게 마이그레이션을 시작하게 되었는데, 시작부터 느낌이 이상했다.

블로그를 구성하는 ‘파일’과 ‘데이터베이스’의 용량이 갑자기 기하급수적으로 낮게 표시되었다.

심지어 Disk Usage와 Files And Directories Limit가 1%로 낮아지고 있었다.

필자는 처음에는 ‘마이그레이션이 되는 도중이니 블로그 데이터를 처음부터 다시 불러오나보다’라고 생각했다.

하지만 시간이 지나도 데이터가 복구될 기미를 보이지 않았다.

급한대로 필자는 마이그레이션 진행중 버튼을 강제로 캔슬했다.

그리고 다시 블로그에 들어가자, 블로그 첫 화면은 아래와 같이 바뀌어 있었다.

모든 플러그인 초기화.

포스팅 개수는 단 한 개. Hello World.

사용하고 있는 리소스 용량. 약 1메가 바이트 미만.

이것이 바로 2번에 걸친 호스팅 마이그레이션 시도의 참담한 결과였다.

‘네 번째 인사이트’
그동안 운이 좋았다고 해서 모든 것이 뒤집힐 요행을 바라지 마라.

단테의 호스팅 마이그레이션 ‘천국편’

단테의 신곡을 읽어본 사람들은 모두 ‘지옥편’이 가장 재미있었다고 하고 ‘천국편’이 제일 지루했다고들 한다.

그도 그럴 것이, 지옥편에서 묘사하는 지옥의 생생한 모습은 인간의 공포 저편의 근원에서부터 상상력을 불러일으키지만, 천국에 관한 묘사는 기껏해야 우리가 상상할 수 있는 범주 안의 어떤 모습이기 때문이다.

이 기나긴 글도 결국에는 ‘해피 엔딩’이라는, 뻔하고 지루한 결말로 끝나게 된다.

하지만 이 이야기는 아직 끝나지 않았다.

그러니 마지막에 필자가 어떻게 이 모든 상황을 해결하고 블로그를 정상화했는지 그 결말에 이르는 이야기까지 독자 분들이 함께 해주신다면 필자로서는 이 글을 작성한 소소한 보람을 느낄 수 있을 것 같다.

이제 이 이야기의 나침반은 ‘천국편’으로 향한다.

Re:제로부터 시작하는 백업 데이터 불러오기

필자가 이렇게 무모한 일을 벌이게 된 것은 사실 뒷배가 있었기 때문이다.

그건 바로 호스팅 업체에서 제공하는 ‘최후의 백업’이 건재하다는 믿음 때문이다.

다행히 위 백업 데이터(3월 17일자)를 통해 필자는 다시 블로그를 ‘포스팅 1개만 날아간’ 상태까지 복구할 수 있었다.

그리고 이때 필자는 과거 ‘티스토리 블로그’를 운영했을 적 했던 어떤 경험이 떠올랐다.

그때도 필자는 포스팅 1개를 어떤 실수로 날려버린 적이 있었는데, 그때 ‘그 방법’으로 날아간 포스팅을 복구한 적이 있었다.

그리고 이번에도 바로 그 방법을 사용해보기로 했다.

제거된 블로그 글 복구하기

혹시 ‘하드 디스크 복구’라는 말을 들어본 적이 있는가?

하드 디스크에서 어떤 파일을 삭제한다고 해도 그 파일은 사실 삭제된 게 아니라 그 파일을 식별할 수 있는 ‘색인’이 지워진 거라고 한다.

그래서 ‘색인’을 복구했을 때 운만 좋다면 파일을 거의 온전하게 다시 되살릴 수 있다.

블로그 포스팅도 마찬가지다.

필자를 포함한 모든 블로그는 블로그 글을 게시한 순간 인터넷에 노출되는 게 아니라, 일종의 ‘색인화’ 작업을 거치게 되어있다.

구글 등에서는 ‘크롤링 봇’이라는 이름으로 어떤 웹사이트에서 신규 게시된 블로그 게시글을 보고 ‘색인화’ 작업을 하는데, 그 이후에는 구글에서 검색하면 포스팅이 노출되게 된다.

요점은, ‘색인화’가 되어있는 포스팅이라면 그 색인이 지워지기 전에 빠르게 복구할 수도 있다는 사실이다.

이 방법은 ‘아직 작성중인 글’을 복구하는 데는 쓸 수 없다. 그 이유는 색인화가 이루어지지 않았기 때문이다.

또한 게시한 지 얼마 되지 않아 아직 크롤링 봇이 색인하지 않은 상태라면 마찬가지로 복구할 수 없다.

그렇다면 그 방법이 궁금할 것이다. 어떻게?

블로그 포스팅 자체가 날아가버린 상태에서 어떻게 복구할 수 있을까?

그 비결은 포스팅의 ‘제목’과 ‘퍼머링크’에 있다.

이번에 필자가 블로그를 복구하는 과정에서 날려버린 글은 바로 아래의 글이다.

위 글은 필자가 호스팅 업체를 Hostinger로 변경한 뒤 작성한 글으로, 이번 백업 데이터에는 안타깝게도 포함되어있지 않았다.

하지만 지금으로부터 약 1주일 전(3월 17일) 게시한 덕에, 크롤링 봇이 위 포스팅을 ‘색인화’하는 데는 충분한 시간이 있었다.

아래는 필자가 검색 엔진 Bing에 검색한 결과다.

위 글은 실제로 필자의 블로그에서는 이미 ‘삭제된’ 글이었다.

그래서 당시에 저 링크를 타고 들어가면 ‘Page not Found’ 오류가 발생했다.

그렇다면 위 글에 들어가도 내용을 볼 수 없는데 어떻게 위 글로 복구를 한다는 걸까?

위의 역삼각형을 누르면 위 글의 ‘캐시 여부’를 알 수 있다.

캐시에 대해서는 자세한 설명은 생략한다. 쉽게 말하자면 글을 빨리 불러오기 위해 미리 준비된(ready-made) 상태라고 보면 된다.

이 ‘캐시 데이터’를 불러올 수만 있다면 날아간 글을 확인할 수 있다.

이제 저 ‘캐시됨’이라는 글씨를 클릭해보자.

위 글은 필자가 3월 17일에 작성한 글의 원본이다.

여기까지 온 독자분들은 필자가 어떻게 날아간 글을 복구할 수 있었는지 이제 궁금증을 해소하셨을 것이다.

비록 필자는 3월 17일에 업로드했다는 그 사실까지 복구할 수는 없었지만, 저 ‘캐시된 페이지’를 통째로 복사함으로써 3월 23일에 글을 다시 올릴 수 있었다.

필자에게 중요한 건 업로드한 날짜가 아니었다. 위 글을 무사히 복구했다는 그 사실만이 중요했을 뿐.

이렇게 필자는 무사히 ‘호스팅 업체 변경’부터 ‘블로그 초기화’라는 과정을 거쳐 마침내 ‘모든 글 복구’라는 대 여정을 무사히 마치게 되었다.

정리하는 글

호스팅 업체 변경 방법이 궁금한 사람이 왜 아무도 없는건데?!

세상에서 가장 무시무시한 비폭력적인 형벌을 꼽으라면 그건 바로 지금까지 해온 모든 노력을 수포로 만들어버리는 ‘시시포스형’이 아닐까.

게임에서는 1주년을 맞이하면 거창하게 1주년 이벤트를 여는데, 필자는 1주년 기념 파티는 고사하고 1년 동안 열심히 꾸려온 블로그가 통째로 날아갈 뻔했다.

필자가 호스팅 업체를 변경할 때 필자는 나름 열심히(?) 호스팅 업체 변경하는 방법에 대해 검색하고 다녔던 기억이 있다.

하지만 필자에게 도움이 된 글은 ‘단 한 개’도 없었다.

정확히 말하자면, 해외 호스팅 업체 변경 방법(Fastcomet -> Hostinger)에 대해 정리해준 분은 아무도 없었다.

그래서 필자는 오로지 혼자 힘으로 호스팅 업체를 변경하는 대장정을 뛸 수밖에 없게 된 것이었다.

가비아나 닷홈과 같은 국내 호스팅 업체를 사용했다면 이런 고생은 덜 했을지도 모르겠다.

이 모든 ‘뻘짓’의 기록을 담은 이 글은 과거 아무것도 모른 채 블로그가 정지된 충격을 맞이했던 나를 위해 바치는 일종의 ‘위로’이자 내 뒤를 따를 또다른 누군가의 길이 되어주기 위한 하나의 이정표다.

지금 와서 든 생각인데, 블로그 마이그레이션을 할 때는 ‘도메인’과 호스팅’ 양쪽에서 궁합이 맞아야 한다.

이번에 필자가 겪은 일련의 과정은 ‘도메인’을 호스팅과 독립시킨 게 첫 번째 패착이었고 (그 때문에 DNS 설정을 모두 수동으로 잡아야 했다.) 두 번째로 호스팅 마이그레이션 기능을 원리도 모르고 지나치게 신뢰했다는 점이었다.

만약 필자가 도중에 도메인 업체를 클라우드플레어로 변경하지 않고 이전 호스팅 업체인 FastComet과 새로 계약한 호스팅 업체인 Hostinger 사이에서 도메인을 이전했다면, 어쩌면 DNS 설정도 모두 자동으로 해결되었을지도 모를 일이다.

하지만 필자는 클라우드플레어라는 제3의 도메인 업체를 끼고 진행했기 때문에 DNS 설정이나 호스팅 마이그레이션이라는 생전 듣도보도 못한 이름과 설정까지 건드리며 블로그 문제를 해결할 수밖에 없었다.

만약 정말로 블로그의 모든 데이터가 초기화된다는 리스크를 짊어지고 있다면 이런 미친 짓은 진작에 시도조차 하지 않았을 것이다. 처음부터 미국 또는 유럽 어딘가에 살고 있는 ‘전문가’에게 영어로 지금 상황을 알렸을 것이고, 어찌어찌 해결이 되었을 것이다.

그러한 ‘당연한 수순’에 필자가 도달하지 못한 이유는, 필자는 어릴 적부터 내 문제는 내가 해결해야한다는 성미였던 것과, 그리고 이 문제를 내가 해결할 수 있을까하는 순수한 호기심 때문이었다.

그래서 어느 순간부터 필자는 이 문제를 정말로 ‘나 스스로’ 해결해보고 싶었다.

그 어떤 블로그에서도 ‘호스팅 이사하는 방법’을 알려주지 않고 있었기 때문에 필자는 생고생을 하게 되었지만, 한편으로는 필자가 경험한 모든 이러한 경험이 누군가에게는 호스팅을 이전하는 데 도움이 될 수도 있지 않을까하는 막연한 생각도 함께였다.

다행히 필자가 블로그를 무사히 복구하는 데 성공한 덕에, 이 글은 세상에 나올 수 있었다.

(만약 필자가 블로그 복구에 실패했다면 이 블로그마저도 사라졌을지도 모를 일이다.)

혹독한 1주년 이벤트를 뛰고 나니, 안타깝게도 내일의 출근 시간이 조금 더 가까워졌음을 실감하게 되었다.