워드프레스 예약 글이 ‘예약을 놓침’으로 표시될 때 확인할 WP-Cron 원인과 해결 순서
워드프레스 예약 글이 발행 시각을 지났는데도 공개되지 않고 ‘예약을 놓침(Missed Schedule)’으로 표시되는 경우가 있습니다. 예약 시간을 다시 지정하면 한 번은 해결되는 것처럼 보여도 같은 현상이 반복된다면 글 편집기보다 예약 작업을 실행하는 WP-Cron을 살펴봐야 합니다.
다만 모든 문제가 WP-Cron 때문인 것은 아닙니다. 관리자 화면에서는 이미 공개됐지만 홈페이지 캐시가 갱신되지 않아 발행되지 않은 것처럼 보일 수도 있고, 사이트 시간대가 잘못 설정돼 사용자가 생각한 시각과 워드프레스가 해석한 시각이 다를 수도 있습니다. 따라서 실제 발행 실패와 화면 표시 문제를 먼저 나누는 것이 출발점입니다.
예약 발행은 WP-Cron 작업으로 처리된다
미래의 발행 시간을 지정한 글은 즉시 공개되지 않고 예약 상태로 저장됩니다. 워드프레스는 해당 시간이 되면 예약 이벤트를 실행해 게시물 상태를 공개로 변경합니다. 이 과정에 관여하는 대표적인 예약 작업 실행기가 WP-Cron입니다.
여기서 ‘Cron’이라는 이름 때문에 서버가 정해진 시각에 워드프레스를 자동 실행한다고 생각하기 쉽습니다. 하지만 기본 WP-Cron은 리눅스의 시스템 Cron과 작동 방식이 다릅니다. 일반적인 시스템 Cron은 서버가 직접 정해진 시각에 명령을 실행하지만, WP-Cron은 사이트에 요청이 들어왔을 때 실행 시간이 지난 이벤트가 있는지 확인하는 방식입니다.
즉 기본 구조는 다음과 같습니다.
- 시스템 Cron: 실행 시각 도달 → 서버가 명령 실행
- 기본 WP-Cron: 사이트 요청 발생 → 기한이 지난 워드프레스 이벤트 확인 → 작업 실행
| 시스템 Cron | 기본 WP-Cron | |
|---|---|---|
| 실행 계기 | 정해진 시각 도달 | 사이트에 요청이 들어옴 |
| 방문자가 없으면 | 그대로 실행 | 다음 요청까지 지연 |
| 시간 정확도 | 주기 설정에 따름 | 보장되지 않음 |
| 끄는 스위치 | 서버 크론탭에서 제거 | DISABLE_WP_CRON |
따라서 방문자가 거의 없는 사이트에서는 오전 9시에 예약한 글이 정확히 오전 9시에 공개된다고 보장하기 어렵습니다. 오전 8시 50분부터 9시 20분까지 방문이나 다른 요청이 전혀 없다면, 이후 첫 요청이 들어온 시점에 작업이 처리될 수 있습니다. 예약 시간이 중요한 사이트라면 이 차이를 운영 조건으로 고려해야 합니다.
먼저 실제 발행 실패인지 캐시 문제인지 구분한다
문제를 해결하기 전에 관리자 화면의 글 목록에서 게시물 상태를 확인해야 합니다. 관리자에서도 글이 예약 상태로 남아 있거나 ‘예약을 놓침’으로 표시된다면 예약 이벤트 실행 문제를 조사할 가능성이 큽니다.
반대로 관리자 화면에서 이미 공개 상태라면 WP-Cron을 바로 수정할 필요는 없습니다. 홈페이지 캐시가 이전 화면을 계속 보여주고 있을 수 있기 때문입니다. 예를 들어 글이 오후 2시에 정상 공개됐지만 홈페이지 캐시가 오후 1시 50분에 생성된 상태라면, 방문자는 오후 2시 10분에도 새 글을 보지 못할 수 있습니다.
다음처럼 확인하면 범위를 좁힐 수 있습니다.
- 관리자 글 목록에서 실제 상태가 공개인지 확인합니다.
- 글의 직접 URL로 접속해 게시물이 열리는지 봅니다.
- 홈페이지에서만 보이지 않는다면 페이지 캐시, CDN, 테마의 글 목록 조건을 확인합니다.
- 관리자에서도 예약 실패로 남아 있다면 WP-Cron과 예약 이벤트를 조사합니다.
직접 URL에서는 글이 열리는데 홈페이지 목록에만 나타나지 않는다면 예약 발행보다는 캐시, 카테고리 조건, 테마 쿼리 문제일 가능성이 있습니다.
| 관리자 상태 | 직접 URL | 홈페이지 | 어디를 볼 것인가 |
|---|---|---|---|
| 공개 | 열림 | 안 보임 | 페이지 캐시·CDN·테마 쿼리 |
| 공개 | 안 열림 | 안 보임 | 퍼머링크·권한·리디렉션 |
| 예약을 놓침 | — | — | WP-Cron 실행 경로 |
| 예약 대기 | — | — | 사이트 시간대 설정 |
가장 먼저 볼 설정과 서버 조건
타임존 확인
관리자 화면의 설정 → 일반에서 사이트 시간대를 확인합니다. 사이트가 한국에서 운영되는데 다른 지역이나 UTC 기준으로 설정돼 있다면 사용자가 입력한 오전 9시와 워드프레스가 처리하는 오전 9시가 달라질 수 있습니다. 한국 사이트라면 서울을 기준으로 한 지역 시간대 설정이 맞는지 확인하는 편이 안전합니다.
지역 기반 시간대는 단순한 UTC 오프셋보다 지역의 시간 규칙을 반영하기 쉽습니다. 특히 일광절약시간제가 적용되는 지역을 대상으로 운영한다면 고정된 숫자 오프셋보다 도시 기반 설정이 유리합니다.
DISABLE_WP_CRON 확인
wp-config.php에 다음 설정이 있는지 확인합니다.
define( 'DISABLE_WP_CRON', true );
이 값이 true이면 페이지 요청을 계기로 실행되는 기본 WP-Cron이 꺼집니다. 이 설정 자체가 잘못된 것은 아닙니다. 서버의 시스템 Cron이 대신 wp-cron.php를 실행하도록 구성한 사이트에서는 의도적으로 사용합니다.
문제는 기본 WP-Cron을 끈 뒤 시스템 Cron을 설정하지 않은 경우입니다. 이때는 예약 글뿐 아니라 플러그인의 정기 작업, 백업, 임시 데이터 정리, 보안 검사, 알림 발송 등 여러 예약 기능이 함께 멈출 수 있습니다.
wp-cron.php 요청과 루프백 요청
워드프레스 설치 디렉터리의 wp-cron.php는 WP-Cron 실행과 관련된 핵심 파일입니다. 워드프레스가 자신의 도메인으로 HTTP 요청을 보내 작업을 실행하는 환경에서는 이 요청이 서버나 보안 장비에 의해 차단되지 않아야 합니다.
문제를 일으킬 수 있는 조건은 서버 방화벽과 WAF 규칙, 잘못된 리디렉션, HTTP Basic Authentication, DNS 설정, SSL 인증서, 프록시 구성, 호스팅의 내부 요청 제한 등입니다. 워드프레스가 자기 사이트에 접속하는 루프백 요청이 실패하면 관리자 화면의 사이트 건강 검사에 관련 경고가 나타날 수 있습니다.
개발용 스테이징 사이트에 Basic Authentication을 걸어 둔 경우도 주의해야 합니다. 운영 사이트에서는 정상인데 테스트 사이트에서만 예약 작업이 실패한다면 인증 방식이나 외부·내부 요청 제한을 먼저 비교해 볼 만합니다.
사이트 이전 뒤 문제가 생겼다면 서버 Cron을 따로 확인한다
호스팅을 옮길 때 파일과 데이터베이스는 이전했지만 서버에 등록된 Cron 작업은 자동으로 옮기지 않는 경우가 많습니다. 기존 서버가 다음 구조였다고 가정해 보겠습니다.
DISABLE_WP_CRON으로 기본 WP-Cron 비활성화- 서버의 시스템 Cron이 정기적으로 워드프레스 작업 실행
새 서버에서 파일과 데이터베이스만 복원하면 DISABLE_WP_CRON 설정은 남아 있을 수 있지만 기존 서버의 시스템 Cron은 존재하지 않을 수 있습니다. 그러면 새 서버는 기본 실행도 하지 않고 대체 실행도 하지 않는 상태가 됩니다.
사이트 이전 직후부터 예약 발행이 멈췄다면 다음 항목을 함께 대조해야 합니다.
- 이전 서버에서 시스템 Cron을 사용했는지 확인합니다.
- 새 서버에 동일한 예약 작업이 등록돼 있는지 확인합니다.
DISABLE_WP_CRON값과 현재 서버 구성의 조합이 맞는지 봅니다.- 새 서버에서
wp-cron.php또는 WP-CLI 실행이 실제로 가능한지 점검합니다.
이 확인을 빼고 글의 예약 시간만 계속 수정하면 당장의 게시물은 수동으로 처리할 수 있어도 다음 예약 글에서는 같은 문제가 재현될 수 있습니다.
등록된 이벤트와 오류 로그로 범위를 좁힌다
관리자 화면에서는 도구 → 사이트 건강을 먼저 확인할 수 있습니다. 예약 이벤트나 루프백 요청 관련 경고가 있다면 유용한 단서가 됩니다. 다만 검사 시점에는 서버가 정상이고 특정 시간대에만 실패하는 문제도 있으므로 경고가 없다는 이유만으로 WP-Cron을 완전히 배제해서는 안 됩니다.
WP-CLI를 사용할 수 있는 서버라면 등록된 이벤트를 다음 명령으로 확인할 수 있습니다.
wp cron event list
이 목록에서 어떤 이벤트가 등록돼 있는지, 실행 예정 시간이 지났는지, 특정 플러그인이 지나치게 많은 작업을 만들고 있는지 살펴볼 수 있습니다. 실행 시간이 지난 작업을 수동으로 처리하려면 다음 명령을 사용할 수 있습니다.
wp cron event run --due-now
수동 실행에서는 작업이 정상적으로 처리되는데 자동 실행만 실패한다면 이벤트 자체보다 WP-Cron 호출 경로를 의심할 수 있습니다. 반대로 수동 실행에서도 특정 이벤트가 오류를 낸다면 해당 플러그인의 콜백, 설정, 외부 API 연결 또는 PHP 호환성을 조사해야 합니다.
운영 사이트에서 --due-now를 실행할 때는 주의가 필요합니다. 예약된 백업이나 정리 작업, 대량 처리 작업이 한꺼번에 실행될 수 있기 때문입니다. 실행 전 어떤 이벤트가 밀려 있는지 확인하는 편이 좋습니다.
PHP 오류도 확인 대상입니다. WP-Cron 프로세스는 시작됐지만 플러그인의 작업 코드에서 치명적인 오류가 발생하면 실제 기능은 완료되지 않을 수 있습니다. 문제가 발생한 시각과 PHP 오류 로그, 워드프레스 디버그 로그의 시간을 맞춰 보면 특정 플러그인과의 연관성을 판단하기 쉽습니다. 운영 환경에서는 오류를 방문자 화면에 노출하기보다 로그로 기록해야 합니다.
시스템 Cron으로 바꿀 때 고려할 조건
방문자 요청에 의존하는 기본 방식이 사이트 운영에 맞지 않다면 서버의 실제 스케줄러로 WP-Cron 실행을 분리할 수 있습니다. 이 방식은 방문자가 없어도 정해진 주기에 작업을 실행할 수 있어 트래픽이 적지만 예약 발행 시간이 중요한 사이트, 전자상거래 사이트, 백그라운드 작업이 많은 사이트에서 검토할 만합니다.
다만 시스템 Cron을 자주 실행한다고 항상 좋은 것은 아닙니다. 실행 간격이 너무 길면 예약 작업이 늦어지고, 지나치게 짧으면 서버에 불필요한 요청과 작업 부하가 늘어납니다. 분 단위 정확성이 필요한 사이트와 하루에 몇 번만 작업해도 되는 사이트의 설정은 같을 수 없습니다. 호스팅 업체가 제공하는 최소 주기나 권장 방식도 확인해야 합니다.
보안 목적으로 wp-cron.php 접근을 무조건 차단하는 것도 피해야 합니다. 서버 내부에서 PHP를 직접 실행하는 구성이라면 외부 HTTP 접근이 필요하지 않을 수 있지만, HTTP 요청으로 WP-Cron을 호출하는 구성이라면 차단 규칙 때문에 작업이 실패할 수 있습니다. 현재 실행 경로를 확인한 뒤 방화벽과 WAF 규칙을 조정해야 합니다.
반복되는 ‘예약을 놓침’ 점검 순서
문제를 처음 확인했다면 서버 설정부터 크게 바꾸기보다 다음 순서로 조사하는 것이 효율적입니다.
- 관리자 화면에서 글의 실제 상태와 직접 URL을 확인합니다.
- 홈페이지 캐시나 CDN 때문에 오래된 화면이 보이는 것은 아닌지 구분합니다.
- 설정 → 일반에서 사이트 시간대를 확인합니다.
- 도구 → 사이트 건강에서 예약 이벤트와 루프백 관련 경고를 확인합니다.
wp-config.php의DISABLE_WP_CRON설정을 확인합니다.- 해당 값이
true라면 시스템 Cron이 실제로 존재하고 실행되는지 확인합니다. - WP-CLI의
wp cron event list로 밀린 이벤트와 특정 플러그인 작업을 살펴봅니다. - 필요할 때
wp cron event run --due-now로 수동 실행 결과를 확인합니다. - PHP 오류 로그, 서버 방화벽, WAF, DNS, SSL, 인증 설정을 점검합니다.
예약 게시물 하나만 실패하는지, 특정 플러그인 작업만 실패하는지, 사이트의 모든 예약 작업이 멈췄는지도 구분해야 합니다. 한 기능만 문제라면 플러그인 코드나 설정이 원인일 수 있고, 여러 예약 작업이 동시에 멈췄다면 WP-Cron 호출이나 서버 실행 환경을 먼저 보는 편이 합리적입니다.
예약 글을 다시 편집해 즉시 공개하거나 Cron 이벤트를 한 번 수동 실행하는 방법은 임시 조치입니다. 반복되는 문제라면 DISABLE_WP_CRON과 시스템 Cron의 조합, 루프백 요청 가능 여부, 플러그인 오류까지 확인해야 재발을 줄일 수 있습니다. 특히 사이트를 이전한 직후라면 파일과 데이터베이스뿐 아니라 서버에 남아 있던 Cron 설정도 이전 대상이었는지 별도로 확인해야 합니다.
