예약한 시간이 지났는데 글이 여전히 ‘예약됨’으로 남아 있다면 무엇부터 확인해야 할까? 워드프레스 예약 발행은 편리하지만 일반적인 서버의 고정 스케줄러와 작동 방식이 다르다. 시간대, 방문 트래픽, 캐시, 보안 설정 가운데 하나만 어긋나도 ‘예약 실패’가 발생할 수 있다.
이 글은 플러그인을 무작정 추가하기 전에 원인을 좁혀 가는 순서로 설명한다. 핵심은 WP-Cron의 동작 방식을 이해하고, 사이트 시간과 예약 상태, 내부 요청 가능 여부를 차례로 확인하는 것이다.
WP-Cron은 일반적인 Cron과 무엇이 다른가
서버 Cron은 운영체제가 정해진 시각에 명령을 실행한다. 반면 WP-Cron은 워드프레스의 예약 작업 시스템이다. 예약된 글 발행, 업데이트 확인, 플러그인의 정기 작업 등이 WP-Cron 이벤트로 등록된다.
중요한 차이는 WP-Cron이 보통 사이트 요청을 계기로 실행된다는 점이다. 방문자가 페이지를 열면 워드프레스가 실행할 시간이 지난 이벤트가 있는지 확인한다. 방문이 거의 없는 사이트에서는 정확한 시각보다 늦게 실행될 수 있다. ‘오전 9시 예약’은 9시에 반드시 별도 프로세스가 깨어난다는 의미가 아닐 수 있다.
1단계: 사이트 시간대 확인
관리자 화면의 설정 → 일반 → 시간대를 먼저 확인한다. 한국에서 운영한다면 ‘서울’ 또는 UTC+9처럼 실제 운영 시간과 맞는 값이어야 한다. 단순히 현재 화면에 보이는 시계가 맞는지만 보지 말고 워드프레스가 예약 시간을 어떤 시간대로 저장하고 표시하는지 확인해야 한다.
예약 글 편집 화면에서 날짜와 오전·오후도 다시 본다. 9:00 오전과 9:00 오후, 사이트 시간과 서버 UTC를 혼동하는 사례가 의외로 많다.
2단계: 글 상태 확인
글 → 모든 글 → 예약됨 목록을 열어 해당 글이 실제로 미래 글 상태인지 확인한다. 임시글이나 검토 대기 상태라면 시간이 되어도 공개되지 않는다. 예약 날짜가 과거인데 ‘예약을 놓침’으로 표시된다면 발행 이벤트가 실행되지 않은 것이다.
- 제목 옆에 ‘예약됨’이 표시되는가?
- 날짜 열의 시간과 편집 화면 시간이 같은가?
- 가시성이 공개로 설정되어 있는가?
- 작성자에게 글을 발행할 권한이 있는가?
3단계: 사이트 방문으로 지연 여부 구분
예약 직후 방문이 거의 없었던 소규모 사이트라면 공개 페이지를 한 번 연 뒤 몇 분 후 예약 목록을 확인한다. 이때 발행된다면 WP-Cron 자체가 망가진 것이 아니라 트래픽 의존 방식 때문에 지연된 가능성이 크다.
반대로 여러 차례 요청이 들어왔는데도 실행되지 않는다면 내부 요청, 캐시 또는 설정 문제를 살펴봐야 한다. 같은 행동을 반복하기보다 어느 단계까지 정상인지 기록하는 편이 빠르다.
4단계: 사이트 건강과 루프백 요청 확인
도구 → 사이트 건강에서는 예약 이벤트와 루프백 요청 관련 문제를 확인할 수 있다. 루프백 요청은 워드프레스가 자기 사이트에 다시 요청을 보내는 방식이다. 호스팅 방화벽, 보안 플러그인, 기본 인증, DNS 오류가 이 요청을 막으면 예약 작업도 영향을 받을 수 있다.
보안 플러그인을 모두 끄는 식으로 접근하지 말고 사이트 건강에 표시된 오류와 서버 로그를 먼저 확인한다. 운영 사이트에서 플러그인을 한꺼번에 비활성화하면 보안과 기능에 더 큰 문제가 생길 수 있다.
5단계: WP-CLI로 Cron 상태 점검
서버 명령줄을 사용할 수 있다면 WP-CLI가 가장 명확한 진단 도구다. 워드프레스 공식 WP-CLI에는 Cron 실행 가능 여부를 검사하는 명령과 예약 이벤트 목록을 확인하는 기능이 있다.
wp cron test
wp cron event listwp cron test가 성공하면 워드프레스가 Cron 실행 요청을 생성할 기본 조건이 갖춰졌다는 뜻이다. 이벤트 목록에서는 실행 예정 시각과 훅 이름을 확인할 수 있다. 명령은 사이트 백업과 서버 권한을 확인한 뒤 사용한다.
6단계: 캐시와 방화벽 점검
페이지 캐시 자체가 항상 WP-Cron을 막는 것은 아니지만, 잘못된 캐시 규칙이나 보안 정책이 wp-cron.php 요청을 차단할 수 있다. 다음 항목을 확인한다.
- 호스팅 오류 로그에 403·429·500 응답이 있는가?
- 보안 플러그인이 내부 요청을 공격으로 분류했는가?
- Cloudflare 같은 프록시에서 과도한 봇 차단이 적용되었는가?
DISABLE_WP_CRON설정이 켜져 있는데 서버 Cron은 없는가?
방문이 적은 사이트의 안정적인 방법
정확한 시간 실행이 중요하다면 호스팅의 서버 Cron을 사용해 일정 간격으로 워드프레스 Cron을 호출할 수 있다. 이 경우 중복 실행을 피하기 위해 WP-Cron 자동 실행 설정과 서버 Cron 구성을 함께 설계해야 한다. 호스팅마다 설정 화면과 명령 경로가 다르므로 해당 업체 문서를 기준으로 적용한다.
개인 블로그에서 몇 분의 지연이 허용된다면 기본 WP-Cron을 유지하는 것이 관리 부담이 적다. 예약 발행이 광고나 뉴스레터와 동시에 실행되어야 한다면 서버 Cron을 검토할 이유가 커진다.
복구 후 점검표
- 테스트 글을 10분 뒤로 예약하고 실제 공개 시각을 기록한다.
- 사이트 시간대와 서버 시간을 각각 확인한다.
- 사이트 건강의 예약 이벤트 오류가 사라졌는지 본다.
- 캐시 삭제 후 공개 URL과 RSS에 글이 나타나는지 확인한다.
- 같은 문제가 반복되면 호스팅 로그와 Cron 이벤트를 함께 보관한다.
정리
- WP-Cron은 기본적으로 사이트 요청을 계기로 실행되므로 저트래픽 사이트에서 지연될 수 있다.
- 시간대와 글 상태를 먼저 확인한 뒤 사이트 건강, 내부 요청, 캐시와 방화벽 순으로 점검한다.
- 정확한 실행 시간이 필요하면 서버 Cron을 고려한다.
- 플러그인을 추가하기 전에 실패 지점을 기록하는 것이 중요하다.
다음 글에서는 Search Console에서 노출은 발생하지만 클릭이 나오지 않는 페이지를 찾고 개선하는 방법을 다룬다.