블로그 자동 발행을 예약했는데 글이 안 올라왔다: 무엇을 확인해야 할까

예약만으로는 원고 준비와 공개가 끝나지 않는다. 실제 미발행과 수동 복구 사례를 통해 완성본, 블로그 공개, 소셜 공유를 따로 확인하고 중복 게시 없이 다음 행동을 결정하는 방법을 정리했다.

자동 발행을 예약해 두었는데 시간이 지나도 글이 없었다. 이 블로그의 2026년 9월 18일 사례에서는 예약 도구가 고장 난 것이 아니었다. 그 시각에 발행할 수 있는 완성본이 준비되지 않았다.

예약을 등록하면 글이 올라갈 것이라고 생각하기 쉽지만, 원고와 이미지 검토, 블로그 공개, 소셜 공유는 각각 끝나야 하는 작업이다. 이 글은 블로그나 뉴스레터 발행을 자동화하려는 사람이 ‘예약 완료’ 이후 무엇을 확인해야 하는지 판단하기 위한 경험 기록이다.

다시 발행하기 전에 세 곳부터 확인하기

먼저 발행 도구에 검토가 끝난 완성본이 있는지 본다. 다음으로 공개 주소에서 실제 글과 이미지가 보이는지 확인한다. 마지막으로 Threads 같은 소셜 프로필에 이미 같은 링크가 올라가 있는지 본다. 공개된 글이 있는데 버튼부터 다시 누르면 중복으로 게시할 수 있기 때문이다.

이 사례에서 바뀐 운영 기준은 예약 등록을 완료로 보지 않고, 완성본·공개 글·소셜 게시물을 따로 확인하는 것이었다. 아래의 기록과 판단표는 자동화 도구를 바꾸기 전에 어디서 작업이 멈췄는지 찾는 데 쓸 수 있다.

발행 흐름의 개념 일러스트이며 실제 장애 화면은 아니다.

실제 무슨 일이 있었나 (운영 기록)

참고: 아래는 이 사이트(QSike Tech Notes)의 측정된 운영 기록이다. 통제된 실험이 아니며, ‘앞으로 중복이 절대 일어나지 않는다’는 증명도 아니다.

• 2026-09-18 07:00 (KST) 예약 발행 슬롯이 지나갔다. 블로그와 Threads 어디에도 발행 시도가 없었다. 원인은 스케줄러 고장이 아니었다. 발행 준비가 끝난 미발행 글이 없었을 뿐이다. 즉 준비 실패였고, 자동 복구도 일어나지 않았다 — 애초에 복구할 제출 시도가 없었다.
• 2026-09-20 운영자가 검토 후 즉시 발행을 명시적으로 승인했다. 글을 준비·검토한 뒤 블로그에 먼저 발행했고, 공개 URL·이미지 표시·canonical·사이트맵·RSS를 직접 확인했다. 이 순서가 중요하다: 소셜 공유는 블로그가 완전히 공개된 뒤에야 할 수 있는 단계다. 공유할 링크가 아직 404이거나 이미지가 깨져 있으면, 소셜 게시물이 잘못된 상태를 가리키게 된다. 그다음 Threads 최근 게시 목록에서 같은 글 URL이 이미 있는지 확인한 뒤 공유했다. 블로그 발행 시각은 14:25:52, Threads 공유 시각은 14:26:46 (모두 KST). 발행·공유 확인 기록을 남겼고, 결과가 불확실한 상태에서 재시도하지 않았다.
• 2026-09-21 기준 이 발행·검증 절차를 거쳐 공개가 완료된 게시물은 2건이다.

직전에 발행한 글은 블로그 글에 갑자기 취소선이 생겼다면: 숫자 범위 표기부터 확인하세요였다. 9월 18일에 빠진 슬롯의 자리를 이 글이 9월 20일에 대신 채운 셈이다.

상태는 네 개다: 예약 ≠ 준비 ≠ 공개 ≠ 공유

9월 18일 사례의 핵심은 ‘예약됨’과 ‘발행 준비됨’이 다른 상태라는 점이다. 게시물 자동화에서는 적어도 네 가지 상태를 구분해야 한다.

1. 예약됨(scheduled) — 캘린더나 발행 도구에 ‘이 시각에 나간다’는 계획이 등록되어 있다.
2. 준비됨(ready) — 그 시각에 실제로 발행될 수 있는 완성본(최종 원고, 이미지, 검토 완료 표시)이 존재한다.
3. 공개됨(public) — 누구나 열 수 있는 URL에 실제 응답이 있고, 본문·이미지·canonical·사이트맵·RSS가 일치한다.
4. 소셜 공유됨(shared) — Threads 등 소셜 프로필에 최근 게시물로 실제로 나타난다.

‘글이 안 나왔다’는 현상은 이 네 단계 중 어디서 끊어졌는지에 따라 전혀 다른 문제다. 9월 18일은 2번이 비어 있어서 1번이 아무것도 하지 못한 경우였다. 도구 고장이 아니라 준비 실패였고, 그 준비 실패 자체는 고쳐야 할 운영 워크플로우의 틈이었다 — ‘예약 시각에 완성본이 반드시 존재하게 만드는’ 인계 절차가 비어 있었기 때문이다.

‘글이 없다’의 서로 다른 세 가지 원인

예약 슬롯이 조용히 지나갔을 때, 실제로는 적어도 세 가지 경우가 섞여 있다.

• 준비 미완료 — 제출 자체가 일어나지 않았다. 실패 로그가 없는 것이 정상이다. (9월 18일 사례)
• 실제 제출 실패 — 발행 시도는 있었으나 거부·오류로 실패했다. 도구 쪽에 실패 기록이 남아야 한다.
• 응답 불명 — 제출은 했는데 타임아웃 등으로 결과를 모른다. 이 경우 글은 이미 공개됐을 수도 있다.

세 경우의 대응은 각각 다르다. 준비 미완료라면 당장의 조치는 재시도가 아니라 완성본을 만들어 검토를 끝낸 뒤 발행하는 것이고, 준비 실패가 인계 절차의 틈에서 왔다면 그 워크플로우 자체를 고쳐야 한다. 실제 제출 실패라면 실패 기록에서 원인을 찾아 고친 뒤 재시도한다. 응답 불명이라면 공개 상태를 확인해 미발행이 확정된 경우에만 재시도한다. 그러나 첫 번째 동작은 셋 다 같다: 재시도 전에 실제 공개 상태를 확인하는 것. 특히 응답 불명 상태에서 곧바로 재시도하면 중복 게시 위험이 생긴다. HTTP 명세(RFC 9110) 기준으로 POST는 멱등(idempotent)이 아닌 메서드라, 같은 POST를 두 번 보내면 서버가 두 번 처리할 수 있다. 명세 §9.2.2는 클라이언트가 비멱등 메서드 요청을 자동 재시도하지 말 것(SHOULD NOT)을 권고한다 — 원래 요청이 적용됐는지 탐지할 수단이 있는 경우가 아니라면 말이다. Threads API도 컨테이너 생성과 발행이 분리된 2단계 구조여서, 1단계가 성공했는지 모르는 채 전체를 다시 돌리면 중복 가능성이 남는다. 그래서 이 사이트의 운영 원칙은 ‘결과가 불확실하면 재시도하지 않고, 공개 상태와 접수 기록을 먼저 확인한다’였다. (이는 일반화된 기술 주장이고, 실제 중복 방지가 검증된 횟수 같은 성과 수치는 없다.)

작성·점검·공유 흐름의 개념도다. 본문의 네 상태를 하나씩 대응시킨 그림은 아니다.

독자용 5단계 확인 체크리스트

특정 도구에 의존하지 않고, 캘린더·발행 대시보드·브라우저·소셜 프로필만으로 확인할 수 있다.

1. 캘린더에서 일정과 시간대를 확인한다. 예약 시각이 정말 지났는지, KST/UTC 같은 시간대 표기 오류는 아닌지 본다.
2. 발행 도구 대시보드(또는 draft preview)에서 해당 글의 상태를 본다. ‘예약됨’인지 ‘초안’인지 ‘발행됨/오류’인지 구분한다. 여기서 준비 미완료와 제출 실패가 갈린다.
3. 공개 URL을 브라우저에서 직접 연다. 대시보드가 ‘발행됨’이라고 해도 끝이 아니다. 본문과 이미지가 실제로 표시되는지, 발행 시각 표기가 올바른지 확인한다.
4. 소셜 프로필의 최근 게시물을 확인한다. 블로그가 공개돼 있어도 소셜 공유는 별개 단계다. 반대로, 공유 버튼을 다시 누르기 전에 이미 같은 URL이 게시돼 있는지 여기서 먼저 확인해야 중복을 막는다.
5. 확인 결과를 타임스탬프·URL과 함께 기록한다. 무엇을 언제 확인했고 결과가 무엇이었는지 남겨야, 다음에 같은 일이 생겼을 때 ‘재시도’와 ‘확인’ 중 무엇을 해야 할지 판단할 수 있다. 결과가 불확실하면 기록해 두고 재시도하지 않는다.

재시도 전에 공개 상태를 먼저 확인하는 순서를 나타내는 설명용 일러스트다.

다음 행동을 결정하는 표

복사해서 쓰는 확인 양식 — 아래 빈칸은 본인의 확인 결과로 채운다. 실제 성공 사례나 측정값이 아니다.

예정 시각과 시간대:
완성본 검토 여부:
발행 도구의 상태와 접수 기록:
블로그 공개 URL과 본문·이미지 확인 시각:
소셜 게시 URL과 확인 시각:
아직 확인하지 못한 항목:
다음 행동과 담당자:

한계

• 위 운영 기록은 한 사이트의 실제 사례일 뿐이다. “이 체크리스트로 장애를 몇 % 막았다”거나 “복구 시간을 몇 분 단축했다” 같은 실측 수치는 없다. 9월 20일의 복구도 자동 복구가 아니라 운영자의 명시적 승인 아래 수동으로 진행한 절차였다.
• 응답 불명 상황에서 공개 상태 확인이 항상 즉시 가능하지는 않다(반영 지연, 캐시 등). 그럴 때는 확인 가능 시점까지 기다리는 것이 안전한 기본값이다.

확인한 출처 / 근거

• RFC 9110: HTTP Semantics — Idempotent Methods (Section 9.2.2) — POST가 멱등이 아니라는 점, 비멱등 요청의 자동 재시도를 피하라는 권고의 근거.
• Threads Posts — Meta for Developers — Threads 발행이 컨테이너 생성+발행의 2단계라는 근거.
• 참고: 2026-09-18 미발행 슬롯, 2026-09-20 수동 복구(블로그 14:25:52 KST, Threads 14:26:46 KST), 2026-09-21 기준 완료 게시물 2건은 이 사이트의 운영자 확인 기록(내부 검증 완료)이다. 복구의 공개 결과물은 직접 확인할 수 있다 — 블로그 글은 블로그 글에 갑자기 취소선이 생겼다면: 숫자 범위 표기부터 확인하세요, Threads 공유는 해당 게시물이다. 절차 시각·건수 기록 자체에 대한 별도 공개 URL은 없으며, 없는 URL은 만들지 않는다.