앱 공장 글 하나를 예약해 두고 공개 시각을 기다렸다.
영상과 글을 같은 시각에 맞춰 두었으니, 시간이 지나면 둘 다 열려 있어야 했다. 그런데 YouTube 영상은 공개됐는데 WordPress 글은 그대로 예약 상태에 머물렀다.
처음에는 날짜나 시간대가 잘못됐다고 생각했다. WordPress의 로컬 시간과 UTC를 다시 봤고, 글의 상태도 확인했다. 예약 시각 자체는 맞았다. 문제는 예약 정보가 아니라 그 예약을 실제로 실행할 주체가 없었다는 것이었다.
예약은 있었지만, 깨워줄 사람이 없었다
WordPress의 예약 발행은 WP-Cron에 기대고 있다. 이름은 Cron이지만 일반적인 Linux cron처럼 계속 떠 있는 데몬은 아니다. 기본 WP-Cron은 사이트 방문이 들어올 때 예약 작업을 확인하고 실행한다.
트래픽이 많지 않은 새 블로그라면 예약 시각에 방문자가 없을 수 있다. 그러면 작업이 늦게 실행될 수 있다. 하지만 내 환경은 그보다 더 분명한 상태였다.
define( 'DISABLE_WP_CRON', true );wp-config.php에서 WP-Cron이 비활성화돼 있었다. 서버의 작업 스케줄러로 대체하려는 구성 자체는 이상하지 않다. WordPress 공식 문서도 시스템 스케줄러를 연결한 뒤에는 페이지 요청마다 WP-Cron을 실행하지 않도록 이 값을 사용할 수 있다고 설명한다.
문제는 그 다음이었다. DISABLE_WP_CRON=true인데 대신 실행할 시스템 스케줄러가 없었다.
예약 작업은 등록돼 있었다. 다만 그 작업 목록을 열어볼 프로세스가 한 번도 호출되지 않았다.
결국 예약 시간이 지나도 글은 스스로 공개될 수 없었다. 설정 한 줄만 보면 성능 최적화처럼 보이지만, 대체 스케줄러가 빠지면 예약 발행과 각종 백그라운드 작업을 멈추게 하는 스위치가 된다.
먼저 밀린 작업을 한 번 실행했다
원인을 확인한 뒤에는 WordPress 컨테이너 안에서 wp-cron.php를 직접 실행했다. 이미 예약 시각이 지난 글은 이 호출을 계기로 공개됐다.
docker exec -u www-data WORDPRESS_CONTAINER \
php /var/www/html/wp-cron.phpWORDPRESS_CONTAINER는 실제 Container Manager의 WordPress 컨테이너 이름으로 바꿔야 한다. 설치 방식에 따라 PHP 사용자와 WordPress 경로도 다를 수 있으니 그대로 복사하기보다 컨테이너 내부 경로부터 확인하는 편이 안전하다.
여기서 한 번 실행해 글을 공개하는 것으로 끝내면 같은 문제가 다시 생긴다. 내가 필요했던 것은 수동 복구가 아니라 다음 예약도 자동으로 처리되는 구조였다.
Synology 작업 스케줄러가 매분 WP-Cron을 호출하게 했다
WordPress가 Synology NAS의 Container Manager에서 실행되고 있었기 때문에 DSM의 제어판 → 작업 스케줄러에 사용자 정의 스크립트 작업을 만들었다.
- 작업 스케줄러에서 예약된 작업의 사용자 정의 스크립트를 만든다.
- 실행 주기를 1분으로 설정한다.
- WordPress 컨테이너의
wp-cron.php를 PHP로 실행한다. - 작업이 활성 상태인지 확인하고 수동 실행으로 먼저 시험한다.
- 최근 실행 결과가
Success인지 확인한다.
docker exec -u www-data WORDPRESS_CONTAINER \
php /var/www/html/wp-cron.phpHTTP로 wp-cron.php를 호출하는 방법도 있지만, 내 구성에서는 NAS 안에서 컨테이너를 직접 실행하는 편이 경로와 실패 원인을 확인하기 쉬웠다. 외부 DNS나 인증서 상태에 예약 발행이 의존하지 않는다는 점도 마음에 들었다.
작업을 만든 뒤에는 다음 세 가지를 따로 확인했다.
- DSM 작업 스케줄러가 활성 상태이고 최근 결과가
Success인지 - WordPress 시간대가
Asia/Seoul인지 - 예약 글의 로컬 시각과 UTC 시각이 서로 맞는지
다음 예약 글로 다시 검증했다
스케줄러가 성공했다고 표시되는 것과 글이 제시간에 공개되는 것은 다른 문제다. 그래서 다음 앱 공장 글을 실제 검증 대상으로 삼았다.
WordPress 글을 2026년 8월 17일 오전 8시 KST, UTC로는 2026년 8월 16일 오후 11시에 예약했다. 예약 전에는 익명 URL이 404였고 홈페이지와 카테고리에도 보이지 않았다. 내부 예약 이벤트의 다음 실행 시각도 오전 8시로 확인했다.
그 글은 이후 실제로 공개 상태가 됐다. 지금도 앱 공장 10화에서 공개된 결과를 확인할 수 있다. 이때서야 “작업 스케줄러가 성공했다”가 아니라 “예약 발행 경로 전체가 동작한다”고 판단할 수 있었다.
내가 놓쳤던 점
DISABLE_WP_CRON은 문제의 원인이라고만 말하기 어렵다. 시스템 스케줄러로 WP-Cron을 안정적으로 호출한다면 오히려 예측 가능한 운영 방식이다.
내가 놓친 것은 설정의 절반만 적용한 상태였다.
WP-Cron 비활성화
+ 시스템 스케줄러 없음
= 예약 작업을 실행할 주체 없음그리고 관리자 화면의 “예약됨” 표시는 미래 작업이 저장됐다는 뜻이지, 그 시각에 실행될 것이라는 보증은 아니었다. 예약 발행을 운영 기능으로 쓴다면 다음을 한 묶음으로 확인해야 한다.
- WordPress와 서버의 시간대
DISABLE_WP_CRON설정- 대체 작업 스케줄러의 존재와 실행 주기
- 작업 실행 사용자와 컨테이너 경로
- 스케줄러의 최근 성공 여부
- 실제 예약 글을 이용한 종단 간 검증
지금은 새 예약 글을 만들 때 공개 시각만 보지 않는다. 예약 전 비노출, 내부 이벤트, DSM 스케줄러, 공개 후 URL까지 함께 확인한다. 설정 하나를 고치는 것보다, 실패가 다시 조용히 지나가지 않게 만드는 쪽이 더 중요했다.
참고: WordPress 공식 문서 — Hooking WP-Cron Into the System Task Scheduler
답글 남기기