블로그가 삭제됐다 — n8n으로 Wayback에서 55편 되살린 이틀

새벽에 메일 하나가 왔다. 제목은 평범했는데 본문이 안 평범하더라.
“귀하의 블로그가 멀웨어 및 유사 악성 콘텐츠 정책을 위반했습니다.”

멀웨어? 내가? n8n 워크플로 스크린샷이랑 ComfyUI 노드 캡처밖에 없는 블로그인데? 😅

대시보드에 들어가니까 빨간 자물쇠 그림 위에 숫자가 하나 박혀 있었어. 89
89일 뒤에 영구 삭제된다는 뜻이야.
그리고 그 순간부터 글도, 설정도, 테마도 아무것도 못 건드려. 그냥 껍데기만 구경하는 거지.

그래서 이틀 동안 뭘 했냐면 — 구글한테 빌지 않고, n8n을 켰어.

구글은 왜 갑자기 블로그를 지웠을까?

결론부터: 구글의 버그였다. 자동 분류 시스템이 멀쩡한 블로그를 멀웨어로 오탐한 거야.
구글은 8월 5일 저녁 7시 58분(유럽 시각)에 PPC Land를 통해 공식 입장을 냈는데, “일부 Blogger 호스팅 사이트를 하루가 채 안 되는 시간 동안 멀웨어로 잘못 플래그한 버그가 있었고, 수정 작업 중”이라는 요지였어.

문제는 그 “하루가 채 안 되는” 오탐이 만든 결과가 하루짜리가 아니었다는 거야.
정리해 보면 이렇다.

해외 사례를 보면 12년, 18년 운영한 블로그도 걸렸어.
재밌는 건 같은 계정 안에서 휴면 블로그는 멀쩡하고 활동 중인 블로그만 잠겼다는 관찰이 여러 건 나왔다는 점이야.
열심히 쓴 사람만 맞은 거지.

8월 5일 오후부터는 이의신청을 안 넣은 사람들 블로그도 하나둘 돌아오기 시작했어.
개별 심사가 아니라 서버 쪽에서 통째로 되돌린 거야.
그럼 “Request Review” 버튼은 그 시간 동안 대체 뭘 하고 있었던 걸까? 🤔

SEO 컨설턴트 Glenn Gabe가 X에 남긴 한 줄이 이 사건을 제일 잘 요약해. “renting versus owning is a dangerous game” — 빌려 쓰는 것과 소유하는 것은 다른 게임이라는 뜻이야.

Google Takeout 백업만 믿으면 왜 위험할까?

결론부터: Takeout은 “지금 살아 있는 것”을 내보내는 도구지, “지워진 것”을 되살리는 도구가 아니다.

나도 커뮤니티에서 시키는 대로 제일 먼저 Takeout을 돌렸어. 그런데 압축을 풀어 보니 이미지랑 사이트 메타데이터는 있는데 정작 삭제 대상이 된 글들이 안 들어 있더라. 나만 그런 게 아니었어. 해외 포럼에도 “이미지랑 사이트 데이터는 나왔는데 글이 통째로 없다”는 보고가 올라왔어.

Takeout에서 Blogger 글 본문이 실제로 들어 있는 위치는 여기야.

Takeout/
 └── Blogger/
      └── Blogs/
           └── [내 블로그 이름]/
                └── feed.atom   ← 글 본문은 여기 있다

이게 Atom XML이라 다른 플랫폼으로 옮길 수는 있어. 근데 두 가지 함정이 있어.

• 함정 1 — 잠긴 뒤에는 늦다. 블로그가 잠기면 대시보드 접근이 막히고, 그 상태에서 뽑은 아카이브는 온전하지 않을 수 있어.
• 함정 2 — 글이 많으면 잘린다. 2,000편 넘는 블로그에서 export가 불완전했다는 보고가 있어. feed.atom은 피드 형식이라 태생적으로 페이지네이션의 영향을 받아.

Wayback Machine으로 글을 되살리는 n8n 워크플로는 어떻게 짰을까?

결론부터: CDX API로 URL 목록을 뽑고 → id_ 원본으로 HTML을 긁고 → 본문을 파싱해서 → WordPress WXR(XML)로 조립하는 4단계다. n8n 노드로는 8개면 끝나.

여기서 WXR(WordPress eXtended RSS)가 핵심 개념이야. 워드프레스가 글을 주고받을 때 쓰는 XML 포맷인데, RSS 2.0에 wp: 네임스페이스를 얹은 구조야. 즉 이 XML만 잘 만들면 워드프레스가 글 59편을 한 번에 받아줘.

1단계 — CDX API로 아카이브된 URL을 전부 긁어온다

Wayback Machine에는 검색창 말고 CDX Server API라는 게 있어. 특정 도메인에서 아카이브된 모든 URL을 표로 뱉어주는 API야. n8n의 HTTP Request 노드에 이 주소를 넣었어.

https://web.archive.org/cdx/search/cdx
  ?url=n8n-diy.com/*
  &output=json
  &fl=original,timestamp,statuscode,mimetype
  &filter=statuscode:200
  &filter=mimetype:text/html
  &collapse=urlkey
  &limit=5000

파라미터 하나하나가 다 일을 해.

• collapse=urlkey — 같은 URL의 중복 스냅샷을 접어서 고유 URL 목록만 남긴다
• filter=statuscode:200 — 404·리다이렉트로 잡힌 쓰레기 제거
• filter=mimetype:text/html — 이미지·CSS·JS 빼고 글 페이지만
• output=json — n8n Code 노드에서 바로 다루기 좋게

이 한 방으로 “내 블로그에 무슨 글이 있었는지”에 대한 완전한 목록이 나와.
블로그가 이미 삭제된 상태여도 상관없어. 아카이브는 구글 눈치를 안 보거든 😎

2단계 — id_ 를 안 붙이면 전부 망한다

여기가 제일 중요한 3글자야. 스냅샷 원본을 가져올 때 URL 형태가 두 가지인데, 결과물이 완전히 달라.

# ❌ 이렇게 하면 Wayback 툴바 JS가 본문에 섞여 들어온다
https://web.archive.org/web/20260215093000/https://n8n-diy.com/...

# ✅ timestamp 뒤에 id_ — 아카이브 당시의 순수 원본 HTML
https://web.archive.org/web/20260215093000id_/https://n8n-diy.com/...

id_ 없이 긁으면 본문마다 아카이브 배너 스크립트가 딸려 들어와서 워드프레스에 들어간 뒤에 지저분해져.
이미지도 마찬가지로 id_를 붙여야 원본 바이너리가 온다.

그리고 속도 조절은 필수야. CDX API는 공식 rate limit을 공개하지 않지만 실사용에서는 초당 1회 정도가 안전선이고, 넘기면 429나 503이 떨어져. n8n에서는 두 가지로 처리했어.

1. Loop Over Items 노드로 배치 크기 1
2. HTTP Request 노드 → Options → Batching에서 Batch Interval을 1200ms로 설정

3단계 — HTML 노드로 본문만 발라낸다

n8n에는 HTML 노드(Extract HTML Content)가 있어서 CSS 셀렉터로 원하는 부분만 뽑을 수 있어.
Code 노드에 파서를 직접 짜지 않아도 돼. Blogger 기본 템플릿 기준으로는 이 셀렉터들이 먹혔어.

4단계 — WXR XML로 조립한다

Code 노드에서 문자열로 조립했어. 골격은 이래.

<rss version="2.0"
  xmlns:content="http://purl.org/rss/1.0/modules/content/"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:wp="http://wordpress.org/export/1.2/">
<channel>
  <wp:wxr_version>1.2</wp:wxr_version>
  <item>
    <title>글 제목</title>
    <dc:creator><![CDATA[donghyuk]]></dc:creator>
    <content:encoded><![CDATA[ 본문 HTML 통째로 ]]></content:encoded>
    <wp:post_type>post</wp:post_type>
    <wp:status>publish</wp:status>
    <wp:post_date>2026-02-15 09:30:00</wp:post_date>
    <wp:post_name>original-slug</wp:post_name>
  </item>
</channel></rss>

여기서 딱 하나만 조심하면 돼. 본문 안에 ]]> 문자열이 있으면 CDATA가 그 자리에서 깨진다.
코드 블록이 많은 기술 블로그는 이거 진짜 자주 터져. 치환 함수 한 줄로 막아.

const safe = (s) => s.replace(/\]\]>/g, ']]]]><![CDATA[>');

마지막은 Convert to File → Read/Write Files from Disk로 XML 저장.
그리고 워드프레스에서 도구 → 가져오기 → WordPress로 업로드하면 끝이야.

이미지는 어떻게 살렸을까?

결론부터: WXR 파일은 이미지 파일 자체를 담지 않는다. URL 참조만 담는다.
이걸 모르고 임포트하면 글은 들어오는데 이미지 자리가 전부 깨진 채로 들어와.

순서를 이렇게 잡았어.

1. 원본 CDN부터 확인. Blogger 이미지는 blogger.googleusercontent.com에 올라가는데, 블로그가 잠겨도 이미지 URL은 살아 있는 경우가 있어. 살아 있으면 화질이 더 좋으니까 이쪽을 우선 쓴다.
2. 죽었으면 아카이브에서 회수. Wayback이 다시 쓴 이미지 URL에도 id_를 붙여 원본 바이너리를 받는다.
3. 임포트 시 체크박스. 워드프레스 가져오기 화면의 “첨부 파일 다운로드 및 가져오기”를 반드시 체크. 이걸 켜야 외부 URL의 이미지를 미디어 라이브러리로 빨아들인다.
4. URL 치환 확인. 임포트 후 본문에 web.archive.org 주소가 남아 있으면 언젠가 깨진다. 남은 건 Auto Upload Images 같은 플러그인이나 DB 치환으로 내 도메인 경로로 바꿔준다.

왜 80편 중 55편만 살아났을까?

결론부터: Wayback Machine이 크롤한 적 없는 글은 애초에 복구 대상이 아니기 때문이다.
날아간 25편은 전부 최근 몇 달 안에 쓴 글이었어.

여기서 뼈아픈 사실 하나. 사이트맵을 구글에 제출하는 건 구글을 위한 일이지, 아카이브를 위한 일이 아니다.
Wayback Machine은 개인 도메인을 자주 안 돌아. 특히 발행한 지 얼마 안 된 글은 크롤 순번이 뒤로 밀려.

그래서 워드프레스로 옮긴 첫날에 워크플로 하나를 더 팠어. 새 글 발행 → RSS Feed Trigger → Wayback의 Save Page Now로 자기 URL 제출. 자동화로 돌리려면 archive.org 계정의 API 키가 필요하지만, 한 번 걸어두면 그다음부터는 신경 안 써도 돼.

한 문장으로 줄이면 이거야. 백업을 나만 갖고 있으면 백업이 아니고, 제3자가 갖고 있어야 백업이다. 🗄️

그런데 반전 — 블로거팀이 블로그를 되살려줬다

결론부터: WXR 임포트를 막 끝낸 시점에 블로그가 살아 돌아왔다.
대시보드에 다시 들어가지고, 80편이 그대로 있었어. 이의신청 결과를 기다린지 하루만에 풀린거야.
해외에서 보고된 “서버 쪽 롤백” 패턴 그대로였어.

기분이 묘하더라. 이틀을 태워서 55편을 손으로 건져 올렸는데, 원본이 통째로 돌아온 거야. 😐
그래도 덕분에 마무리는 깔끔하게 됐어. 문제는 이미 워드프레스에 55편이 들어가 있다는 것이었지.
여기서 그냥 백업 XML을 통째로 임포트하면 55편이 두 번 들어간다.

그래서 미복구분 25편만 담은 파일을 따로 만들어서 그것만 넣었어. 순서는 이랬다.

1. 정식 Export부터. 접근 권한이 풀린 즉시 Blogger 설정 → 콘텐츠 백업으로 XML을 받았다. 그런데 제대로 XML을 받을 수가 없었어. 그래서, https://내아이디.blogspot.com/feeds/posts/default?alt=json&max-results=500을 돌려서 XML을 받았어.
2. XML 전체를 읽어서 글 목록을 뽑았다. Blogger 백업 XML은 Atom 형식인데, 글만 들어 있는 게 아니라 댓글·템플릿·설정이 전부 한 파일에 섞여 있다. 그래서 <entry> 중에서 kind가 #post인 것만 걸러야 한다.
3. 이미 살린 59편과 대조했다. 슬러그(URL 경로)를 키로 잡고 워드프레스에 들어간 목록과 비교해서, 겹치지 않는 26편만 남겼다.
4. 그 26편만 담은 WXR 파일을 새로 만들었다. 워드프레스 가져오기는 Blogger XML을 그대로 못 읽으니까, 앞에서 쓰던 변환 로직을 그대로 재사용했다.
5. 그 파일 하나만 임포트. 중복 0건, 누락 0건으로 85편 전량 이전 완료. Blogger 쪽은 그대로 두지 않고 정리했다.

# Blogger 백업 XML에서 "글"만 골라내는 조건
<category scheme="http://schemas.google.com/g/2005#kind"
          term="http://schemas.google.com/blogger/2008/kind#post" />

# 이 조건을 안 걸면 댓글까지 글로 임포트된다

그래서 블로그가 돌아왔는데도 워드프레스 이전을 취소하지 않았어. 돌려줄 수 있는 쪽은, 다시 가져갈 수도 있는 쪽이거든.

DNS·SSL·www 정본 정리는 어떻게 해야 할까?

결론부터: 글을 복구했어도 도메인 정리를 안 하면 검색 노출은 안 돌아온다. 이 순서를 지켜야 다운타임이 줄어.

1. 이전 작업 전날에 TTL부터 낮춘다. 300초 정도로 내려두면 전파가 빨라져. 이거 안 하면 하루를 통째로 기다린다.
2. Blogger용 A 레코드를 걷어낸다. Blogger는 4개의 A 레코드를 쓰라고 안내하는데, 이걸 안 지우면 요청이 계속 구글 쪽으로도 흘러가.
3. www 와 non-www 중 하나를 정본(canonical)으로 고른다. 나머지 하나는 301로 넘긴다. 두 주소가 동시에 200을 뱉으면 색인이 쪼개져.
4. SSL은 DNS 전파가 끝난 뒤에 발급한다. Let’s Encrypt의 HTTP-01 인증은 A 레코드가 새 서버를 가리켜야 통과해. 순서를 바꾸면 발급이 계속 실패한다.
5. 퍼머링크를 Blogger 구조 그대로 맞춘다. 이게 제일 큰 한 방이야.

마지막으로 Search Console에 새 속성을 등록하고 사이트맵을 다시 제출했어.
색인이 재구축되는 데는 시간이 걸리지만, 최소한 URL이 바뀌지 않았다는 사실이 회복 속도를 크게 줄여줘.

오늘 당장 해야 할 백업 5가지는?

이 글을 여기까지 읽었다면, 브라우저 탭 하나 열어서 지금 이거부터 하자. 30분이면 다 돼.

1. Google Takeout 지금 돌리기 — Blogger 선택 → feed.atom이 실제로 들어 있는지 압축 풀어서 눈으로 확인. 안 들어 있으면 그건 백업이 아니다.
2. Wayback Machine에 내 도메인 검색해보기 — 스냅샷이 몇 개나 있는지, 최근 글은 잡혀 있는지 확인. 없으면 지금 web.archive.org/save/로 수동 제출부터.
3. 글 원문을 로컬에 마크다운으로 — 나는 Obsidian에 쌓고 있어. 플랫폼이 뭘 하든 원문은 내 디스크에 남는다.
4. 커스텀 도메인 쓰기 — blogspot 주소를 쓰면 플랫폼이 죽을 때 주소도 같이 죽는다. 도메인이 있으면 짐만 옮기면 된다.
5. 발행 자동 아카이브 워크플로 걸기 — RSS Trigger → Save Page Now. n8n 노드 3개면 끝나고, 이게 오늘 글의 진짜 결론이다.

자주 묻는 질문 (FAQ)

Q. 삭제된 Blogger 블로그도 복구가 되나요?

A. 두 갈래다. 첫째, 대시보드의 “Request Review”로 이의신청. 이번 사태에서는 이의신청 여부와 관계없이 서버 쪽 롤백으로 돌아온 사례가 많았다. 둘째, 구글이 안 돌려주면 Wayback Machine에서 직접 회수한다. 단, 아카이브에 스냅샷이 남아 있는 글만 가능하다.

Q. 89일이라는 숫자는 정확히 뭘 의미하나요?

A. 90일 삭제 시계가 이미 하루 돌아간 상태를 표시한 거다. 즉 잠긴 날부터 90일 뒤 영구 삭제가 예정돼 있다는 뜻이다. 리뷰 기간과 삭제 카운트다운이 같은 숫자로 표시되기 때문에 헷갈리기 쉽다.

Q. Wayback Machine 크롤링을 요청할 수 있나요?

A. 가능하다. web.archive.org/save/ 뒤에 URL을 붙이면 즉시 스냅샷을 만든다. 자동화 API로 대량 제출하려면 archive.org 계정의 키가 필요하고, 초당 1회 정도의 속도를 지키는 게 안전하다.

Q. 복구한 글이 중복 콘텐츠로 페널티를 받지 않나요?

A. 원본이 삭제된 상태라면 중복 이슈는 거의 없다. 오히려 원래 URL 구조를 그대로 유지해서 같은 주소에 같은 글이 다시 서 있게 만드는 편이 색인 회복에 유리하다.

Q. 일부만 복구한 상태에서 원본 백업을 받으면 어떻게 합치나요?

A. 백업 XML을 통째로 임포트하면 이미 넣은 글이 두 번 들어간다. 백업 파일에서 글 항목만 추출하고, 이미 워드프레스에 있는 글의 슬러그 목록과 대조해서 차집합만 담은 임포트 파일을 새로 만들어야 한다. 제목이 아니라 슬러그를 기준으로 비교하는 게 정확하다.

Q. 블로그가 복구됐는데도 워드프레스로 옮겨야 하나요?

A. 나는 옮겼다. 이번 복구는 구글의 판단이 뒤집힌 결과지, 내가 확보한 안전장치가 아니다. 같은 자동 분류 시스템은 그대로 돌아가고 있고, 다음번 오탐이 언제 날지는 아무도 모른다. 최소한 커스텀 도메인 + 내가 통제하는 호스팅 조합으로 옮겨두면, 다음 사고 때는 짐만 옮기면 된다.

Q. n8n 없이도 이 복구가 가능한가요?

A. 파이썬 스크립트로도 된다. n8n을 쓴 이유는 실패한 URL만 골라 재시도하는 루프, 요청 간격 조절, 중간 결과 확인이 GUI에서 바로 되기 때문이다. 80개 URL을 상대로 시행착오를 반복해야 하는 상황에서는 이 차이가 크다.

그래서, 남은 건 80편이 아니라 워크플로 하나

결과만 보면 다 잘 끝났어. 글 80편은 전부 워드프레스에 있고, 하나도 안 잃었어. 🎉

근데 이틀을 통째로 태우고 나서 진짜로 남은 건 따로 있어. 이제 내 글은 내 디스크와 아카이브, 두 군데에 자동으로 복사된다. 구글이 또 버그를 내든, 다음엔 다른 플랫폼이 사고를 치든, 이번처럼 새벽에 심장 떨어질 일은 없어.

플랫폼은 공짜로 좋은 걸 준다. 대신 언제든 회수할 수 있는 조건으로 준다. 그 조건을 잊고 살다가 89라는 숫자를 보게 되는 거지. 이번엔 돌려받았지만, 다음에도 돌려받는다는 보장은 어디에도 없어.

지금 이 글을 읽고 있는 당신 블로그는 백업이 어디 있어? 답이 3초 안에 안 나오면, 그게 오늘 저녁에 할 일이야. 워크플로 만드는 데 30분이면 충분하고, 나처럼 이틀을 태우는 것보다 훨씬 싸게 먹혀 😉

참고 자료
· PPC Land, Blogger owners face 89-day deletion clock as Google malware flags misfire (2026.08.05)
· BleepingComputer, Google Blogger locks hundreds of blogs in malware false positive
· Internet Archive, Wayback CDX Server API
· WordPress Developer Resources, export_wp() / WXR
· Google Blogger 도움말, 내 블로그가 사라졌어요