WordPress WP-Cron 비활성화 및 시스템 cron 설정 방법

wp-cron의 정의와 system cron으로 대체해야 하는 이유

WP-Cron은 WordPress에 내장된 작업 스케줄러이며, 누군가 페이지를 요청할 때만 실행됩니다. WordPress 내부의 그 어떤 것도 스스로 동작하지 않습니다. 캐시에서 제공되지 않는 모든 요청에 대해, WordPress는 예약된 작업 목록을 읽고 실행할 시간이 된 작업이 있다면 /wp-cron.php로 자기 자신에게 두 번째 HTTP 요청을 보내 작업을 수행합니다. 해당 작업을 system cron으로 옮기면 사이트 방문자가 1분에 1,000명이든 한 명도 없든 상관없이 고정된 일정에 따라 예측 가능한 방식으로 작업을 한 번 실행할 수 있습니다.

실제 작업은 두 줄의 설정으로 이루어집니다. wp-config.php에 정의된 상수 하나와 crontab 항목 하나가 그것입니다. 이 가이드의 나머지 내용은 이 두 줄만으로는 알 수 없는 부분들을 다룹니다. 작업이 어떤 사용자로 실행되어야 하는지, 예약된 이벤트가 실제로 실행되었는지 확인하는 방법, 그리고 사이트에 아무런 오류 메시지도 출력하지 않은 채 설정이 실패하는 세 가지 경우를 설명합니다.

예제에서는 WordPress 디렉터리로 /srv/www/example.com을, 웹 서버 사용자로 www-data을 사용합니다. 모든 곳에서 본인의 경로와 사용자로 변경하여 적용하십시오.

트래픽이 많은 사이트에서 어떤 방문자가 cron 비용을 유발하는가

캐시되지 않은 모든 요청은 확인 절차에 비용을 지불합니다. WordPress는 cron 옵션을 로드하여 타임스탬프를 비교하고, 실행할 작업이 있으면 spawn_cron()를 호출합니다. 이는 /wp-cron.php으로 비차단 루프백 요청을 보냅니다. 방문자는 결과를 기다리지 않지만, PHP 워커는 기다립니다. pm.max_children = 5을 사용하는 소규모 VPS에서 PHP-FPM을 실행 중이라면, 하나의 느린 예약 작업이 PHP 가용 자원의 5분의 1을 점유하게 됩니다. 이 작업은 가장 많은 페이지 로드가 발생하는 가장 바쁜 시간에 트리거될 가능성이 가장 높습니다.

WordPress는 중복 실행을 제한합니다. 기본값이 60초인 WP_CRON_LOCK_TIMEOUT 수명의 잠금을 사용하므로, 여러 방문자가 동시에 작업을 시작하지는 않습니다. 이 잠금은 중복을 방지할 뿐, 요청 경로에서 작업을 완전히 분리하지는 않습니다.

문제가 되는지 판단하기 전에 서버에서 이 작업이 얼마나 자주 발생하는지 확인하십시오. 각 루프백은 웹 서버 접근 로그에 다음과 같이 나타납니다.

sudo grep -c 'wp-cron.php' /var/log/nginx/access.log

Apache는 대신 /var/log/apache2/access.log에 기록합니다. 하루에 수천 건이 발생하는 것은 실질적인 비용이며, 이는 기사에서 읽는 것보다 자신의 서버에서 직접 측정해야 할 수치입니다. 다른 변경 사항을 적용하기 전후에 VPS 벤치마크를 수행하는 것과 같은 방식입니다.

캐싱은 상황을 바꿉니다. 페이지 캐시가 대부분의 요청을 정적 HTML로 처리하면 해당 요청에 대해 PHP가 실행되지 않으므로 cron 확인도 발생하지 않습니다. 캐시가 잘 적용된 바쁜 사이트는 아래의 조용한 사이트와 유사하게 동작하기 시작합니다.

방문자가 적은 사이트에서 cron이 작동하지 않는 이유

방문자가 없으면 cron도 실행되지 않습니다. 하루에 방문자가 몇 명뿐인 사이트는 방문자가 들어오는 무작위 시점에 맞춰 하루에 몇 번만 예약된 작업이 실행됩니다.

증상은 모두 동일한 형태를 띱니다. 09:00에 예약된 게시물은 누군가 페이지를 불러올 때까지 게시물 목록에 Missed schedule 상태로 남아 있습니다. 백업 플러그인은 야간 작업을 건너뜁니다. 업데이트 확인이 지연되어 보안 릴리스가 이미 나왔음에도 대시보드에는 업데이트할 항목이 없다고 표시됩니다. 주문 이메일, 갱신 알림, 만료 경고가 늦게 발송됩니다.

이와 관련하여 기록되는 오류는 없습니다. WordPress 관점에서는 작업이 시작된 적이 없으므로 지연된 것으로 간주하지 않습니다.

1단계: wp-config.php에서 방문자 트리거 비활성화

/srv/www/example.com/wp-config.php 파일을 열고 다음 상수를 추가합니다.

define( 'DISABLE_WP_CRON', true );

이 상수는 /* That's all, stop editing! Happy publishing. */이라고 적힌 줄 위에 배치해야 합니다. 해당 주석 바로 아래 줄에서 wp-settings.php을 호출하며, wp-settings.php에서 WordPress가 init에 크론 체크를 연결하기 때문입니다. 해당 require 문 이후에 상수를 정의하면 설정이 너무 늦게 적용되어 아무런 효과가 없습니다. 이 경우 파일 내용은 올바르게 보이지만 트리거는 계속 실행됩니다.

해당 줄이 의도한 위치에 있는지 확인합니다.

grep -n "DISABLE_WP_CRON\|stop editing" /srv/www/example.com/wp-config.php

이 상수는 이벤트 예약 자체를 멈추지는 않습니다. 플러그인은 이전과 동일하게 큐에 작업을 계속 추가합니다. 단지 페이지 로드 시 해당 큐가 실행되는 것을 막을 뿐이며, 이는 3단계를 완료하기 전까지 큐가 전혀 실행되지 않음을 의미합니다.

또한 /wp-cron.php에 대한 직접적인 요청을 차단하지는 않습니다. 누구나 여전히 해당 URL을 요청할 수 있으며, 파일은 예정된 작업만 실행하므로 일반적으로는 무해합니다. 웹 서버 설정에서 이를 차단하는 것은 선택 사항입니다. 만약 차단할 경우, 이 가이드의 마지막 부분에 있는 curl 폴백 기능도 작동하지 않게 됩니다.

2단계: WP-CLI 설치

WP-CLI는 WordPress를 위한 공식 명령줄 도구입니다. 이 도구는 웹 서버의 PHP 모듈과는 별도 패키지인 PHP 명령줄 바이너리가 필요합니다.

php -v
sudo apt install -y php-cli

공식 설치 가이드에서 권장하는 대로 phar 빌드에서 WP-CLI를 설치합니다.

cd /tmp
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
wp --info

php wp-cli.phar --info는 PHP 바이너리 경로, PHP 버전, WP-CLI 버전을 출력합니다. 이 세 가지가 모두 출력된다면 phar 파일이 정상적으로 작동하는 것입니다. 2026년 8월 기준으로 설치 가이드에서 요구하는 최소 사양은 PHP 7.2.24이며, Ubuntu 24.04는 PHP 8.3을 제공하므로 현재 서버 환경은 요구 사항을 충분히 충족합니다. 나중에 sudo wp cli update으로 업데이트하십시오.

WP-CLI는 root가 아닌 사이트 사용자 계정으로 실행해야 합니다.

sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com core version

root 계정으로 실행하면 WP-CLI는 시작을 거부합니다.

Error: YIKES! It looks like you're running this as root.

이때 --allow-root를 사용하라는 제안이 나타나지만, 여기서는 사용하지 마십시오. 그 이유는 아래의 첫 번째 실패 유형에서 설명합니다.

또한 sudo -u www-data -i는 작동하지 않는다는 점에 유의하십시오. 해당 계정의 로그인 셸이 /usr/sbin/nologin으로 설정되어 있어 This account is currently not available. 오류가 발생하기 때문입니다. 명령어를 sudo -u로 직접 전달하면 로그인 셸을 거치지 않으므로 정상적으로 실행됩니다.

이제 WordPress가 1단계에서 설정한 상수를 인식하는지 확인합니다.

sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com eval 'var_dump( DISABLE_WP_CRON );'

이 명령은 bool(true)를 출력합니다. 정의되지 않은 상수에 대한 치명적 오류(fatal error)가 발생한다면 define() 줄이 실행되지 않는다는 의미이며, 이는 보통 해당 코드가 require 문 아래에 위치했기 때문입니다.

3단계: 올바른 사용자로 cron 항목 추가하기

PHP가 파일을 작성할 때 사용하는 소유자 계정을 사용해야 합니다. 양쪽 모두 확인하십시오:

stat -c '%U %G' /srv/www/example.com/wp-content/uploads
grep -E '^(user|group) = ' /etc/php/8.3/fpm/pool.d/www.conf

기본 Ubuntu 설치 환경에서는 두 경우 모두 www-data을 사용합니다. Ubuntu 24.04의 LAMP 스택 구성에서처럼 사이트별로 별도의 PHP-FPM 풀과 전용 사용자를 생성했다면, 아래 모든 과정에서 해당 사용자를 사용하십시오.

해당 사용자가 쓰기 권한을 가질 수 있도록 로그 디렉터리를 생성합니다:

sudo install -d -o www-data -g www-data -m 750 /var/log/wp-cron

해당 사용자의 crontab을 편집합니다:

sudo crontab -u www-data -e

다음 한 줄을 추가합니다:

*/5 * * * * /usr/bin/flock -n /run/lock/wp-cron-example.lock /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now >> /var/log/wp-cron/example.log 2>&1

각 부분을 살펴보겠습니다. */5는 5분마다 작업을 실행합니다. flock -n은 락 파일을 사용하여 이전 작업이 여전히 실행 중이면 즉시 종료합니다. /usr/local/bin/wp는 cron 실행에 필요한 절대 경로입니다. --path는 명령이 어떤 작업 디렉터리에서든 실행될 수 있도록 합니다. --due-now은 큐에 있는 모든 이벤트가 아닌, 시간이 도래한 이벤트만 실행합니다. 리다이렉트는 일반 출력과 오류를 읽을 수 있는 하나의 파일로 보냅니다.

실무에서 이 리다이렉트는 선택 사항이 아닙니다. Cron은 작업의 출력을 해당 사용자에게 메일로 보내려 시도하는데, 대부분의 VPS 이미지에는 메일 전송 에이전트(MTA)가 설치되어 있지 않습니다. 이 경우 cron은 (CRON) info (No MTA installed, discarding output)을 기록하고 출력을 삭제해 버립니다. 파일로 저장해야 기록이 남습니다.

저장된 파일을 확인합니다:

sudo crontab -u www-data -l

여러 사이트를 운영하는 경우, 모든 작업이 동시에 시작되지 않도록 분 단위를 엇갈리게 하여 각각 한 줄씩 작성합니다:

*/5 * * * * /usr/bin/flock -n /run/lock/wp-cron-one.lock /usr/local/bin/wp --path=/srv/www/one.example.com cron event run --due-now >> /var/log/wp-cron/one.log 2>&1
2-59/5 * * * * /usr/bin/flock -n /run/lock/wp-cron-two.lock /usr/local/bin/wp --path=/srv/www/two.example.com cron event run --due-now >> /var/log/wp-cron/two.log 2>&1

로그는 회전(rotate)시키지 않으면 계속 커집니다. /etc/logrotate.d/wp-cron을 작성하십시오:

/var/log/wp-cron/*.log {
    weekly
    rotate 4
    missingok
    notifempty
    compress
    create 640 www-data www-data
}

실제 적용 전 구문 분석을 확인합니다: sudo logrotate --debug /etc/logrotate.d/wp-cron.

단계 4: 예약된 이벤트가 실제로 실행되었는지 확인

성공적으로 저장된 crontab 라인이 실행을 보장하지는 않습니다. 가장 간단한 확인 방법부터 확실한 증거를 찾을 수 있는 방법 순으로 진행하십시오.

첫째, cron이 명령을 시작했습니까? cron은 자체 유닛으로 저널에 로그를 기록합니다.

journalctl -u cron.service --since "15 min ago" | grep wp

정상적인 항목은 다음과 같으며, 앞부분의 타임스탬프와 호스트 이름은 생략되었습니다.

CRON[24913]: (www-data) CMD (/usr/bin/flock -n /run/lock/wp-cron-example.lock /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now >> /var/log/wp-cron/example.log 2>&1)

이 라인은 cron이 www-data 사용자로 명령을 시작했음을 의미합니다. 명령이 실제로 성공했는지 여부는 알 수 없습니다.

둘째, WordPress가 무언가를 실행했습니까? 로그 파일을 읽어 보십시오.

sudo tail -n 20 /var/log/wp-cron/example.log

WP-CLI는 이벤트당 한 줄을 출력하고 마지막에 합계를 표시합니다.

Executed the cron event 'wp_version_check' in 0.418s.
Success: Executed a total of 2 cron events.

오류는 동일한 파일에 기록되며, 이것이 바로 2>&1을 사용하는 이유입니다. 대부분의 실행 시에는 처리할 작업이 없어 기록되는 내용이 거의 없으므로, 작업이 대기 중인 것을 알고 있는 실행 직후에 파일을 확인하십시오.

셋째, 종단 간(end-to-end) 테스트를 수행하십시오. 마커 이벤트를 예약하고 사라지는지 확인하십시오.

sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com cron event schedule wp_cli_cron_check now
sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com cron event list --fields=hook,next_run_relative --format=csv | grep wp_cli_cron_check

한 간격만큼 기다린 후 리스트 명령을 다시 실행하십시오. 일회성 이벤트는 실행 시 큐에서 제거되므로 훅이 사라져야 합니다. 해당 훅 이름에 콜백을 등록한 플러그인이 없으므로, 실행해도 사이트에 다른 영향은 없습니다. 두 간격이 지난 후에도 훅이 여전히 리스트에 있다면 큐가 실행되지 않는 것입니다. 이때 첫 번째와 두 번째 확인 단계가 문제가 cron에 있는지 WP-CLI에 있는지 알려줄 것입니다.

이 작업에 wp cron test를 사용하지 마십시오. 해당 명령은 방문자에 의한 스폰(spawning) 트리거가 작동하는지 확인하는 것이며, DISABLE_WP_CRON이 true일 때 오류를 발생시킵니다. 올바르게 구성된 서버에서는 이 오류가 예상된 출력이며 결함이 아닙니다.

systemd timer 대안

서버의 나머지 예약 작업이 이미 systemd 서비스 및 타이머로 실행되고 있다면, WordPress 작업도 동일하게 구성하십시오. 이렇게 하면 모든 실행 내역이 systemctl list-timers에 표시되며, 로그를 회전(rotate)할 필요 없이 저널(journal)로 출력이 전달됩니다.

/etc/systemd/system/wp-cron-example.service를 작성하십시오:

[Unit]
Description=Run due WordPress cron events for example.com

[Service]
Type=oneshot
User=www-data
Group=www-data
ExecStart=/usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now

그런 다음 /etc/systemd/system/wp-cron-example.timer을 실행하십시오:

[Unit]
Description=Run WordPress cron for example.com every 5 minutes

[Timer]
OnCalendar=*:0/5
AccuracySec=30s
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now wp-cron-example.timer
systemctl list-timers wp-cron-example.timer
journalctl -u wp-cron-example.service -n 20

systemd는 동일한 서비스를 동시에 두 번 실행하지 않으므로, 이 방식에서는 flock이 필요하지 않습니다. Persistent=true을 설정하면 시스템이 꺼져 있는 동안 놓친 작업을 나중에 실행할 수 있는데, 이는 crontab 항목으로는 불가능한 기능입니다.

crontab과 타이머 중 하나만 선택하십시오. 동일한 사이트에 두 방식을 모두 사용하면 대기열이 중복 처리되어, 이메일이나 주문 작업이 두 번 실행되는 모습이 사용자에게 노출될 수 있습니다.

cron 작업을 root 권한으로 실행하면 안 되는 이유

이는 설정이 실패하는 세 가지 방식 중 첫 번째입니다. 작업을 root의 crontab에 넣으면 WP-CLI는 아무 작업도 수행하지 않고 중단됩니다.

Error: YIKES! It looks like you're running this as root.

큐는 절대 실행되지 않으며, 출력을 리다이렉트하지 않았다면 메시지를 확인할 수도 없습니다. 위험한 해결책은 --allow-root를 추가하는 것인데, 이렇게 하면 해당 실행 중에 플러그인이 생성하는 모든 파일의 소유자가 root가 되기 때문입니다. 다음 웹 요청은 www-data 권한으로 실행되므로 해당 디렉터리에 쓰기 작업을 할 수 없으며, 사이트에는 다음과 같은 오류가 발생하기 시작합니다.

Unable to create directory wp-content/uploads/2026/08. Is its parent directory writable by the server?

파일 소유권을 복구한 다음 작업을 이동하십시오.

sudo chown -R www-data:www-data /srv/www/example.com/wp-content

root의 crontab과 www-data의 crontab은 별도의 파일이므로, 한쪽에서 줄을 삭제해도 다른 쪽에는 영향을 주지 않습니다. 둘 다 확인하십시오.

sudo crontab -u root -l
sudo crontab -u www-data -l

cron이 wp: not found를 보고하는 이유

이번이 두 번째 실패입니다. cron은 사용자 작업에 매우 짧은 PATH인 /usr/bin:/bin을 제공합니다. WP-CLI는 /usr/local/bin에 설치되는데, 이 경로는 해당 목록에 포함되어 있지 않습니다. 작업이 시작되자마자 찰나의 순간에 실패하며, 로그에는 다음과 같은 한 줄만 남습니다.

/bin/sh: 1: wp: not found

추측하지 말고 cron의 환경 변수를 직접 확인하십시오. 임시로 다음 줄을 추가합니다.

*/5 * * * * env > /tmp/cron-env.txt 2>&1

한 주기가 지난 후 /tmp/cron-env.txt를 읽고 해당 줄을 삭제하십시오. 그 파일에 있는 PATH= 값이 작업에 적용되는 정확한 환경입니다.

두 가지 해결 방법이 있습니다. 3단계에서와 같이 절대 경로인 /usr/local/bin/wp을 사용하십시오. 또는 모든 작업 줄 상단, crontab의 맨 위에 PATH를 한 번 설정하십시오.

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

동일한 함정이 한 단계 아래에도 존재합니다. wp phar는 #!/usr/bin/env php로 시작하므로, 셸이 php도 찾을 수 있어야 합니다. PHP가 /usr/bin 외부에 위치하는 경우(사용자 지정 빌드나 제어판 빌드에서 흔히 발생함) 다음과 같은 오류가 발생합니다.

/usr/bin/env: 'php': No such file or directory

이런 경우에는 /usr/local/bin/php /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now와 같이 인터프리터를 명시적으로 호출하십시오.

1분 간격이 원래 문제를 재발시키는 이유

이번이 세 번째 실패입니다. * * * * *은 5분보다 안전해 보이지만, 트래픽이 많은 사이트에서는 다시 원점으로 돌아가게 만듭니다. 한 번의 실행이 설정된 간격보다 오래 걸리면, 첫 번째 작업이 끝나기도 전에 다음 작업이 시작됩니다. 10분이 지나면 10개의 PHP 프로세스가 각각 메모리와 데이터베이스 연결을 점유하게 됩니다.

다음 명령으로 프로세스가 쌓이는지 직접 확인하십시오.

ps -eo etimes,user,args | grep '[c]ron event run'

etimes는 프로세스의 경과 시간(초)입니다. 한 줄만 출력되면 정상입니다. 설정한 간격보다 훨씬 큰 경과 시간을 가진 줄이 여러 개 보인다면 작업이 쌓이고 있다는 뜻입니다. 소규모 VPS에서는 이것이 MySQL Too many connections 오류로 이어지거나, 커널이 메모리 확보를 위해 PHP를 강제 종료하는 결과로 나타납니다. 이는 sudo dmesg -T | grep -i 'killed process' 명령으로 확인할 수 있습니다.

WP-CLI는 wp-cron.php을 요청하는 대신 이벤트 콜백을 직접 실행하므로, WordPress가 중복 실행을 방지하기 위해 사용하는 60초 잠금 기능이 여기에는 적용되지 않습니다. 3단계 항목에 있는 flock -n이 현재 중복 실행을 막아주는 역할을 합니다. 건너뛴 작업은 설계상 즉시 조용히 종료됩니다. 작업 중복은 호스트 커널이 해결해 주는 문제가 아니라 crontab에서 직접 해결해야 하는 문제입니다. Linux 커널 7.2에 추가된 캐시 인식 작업 배치 기능조차 프로세스가 어떤 코어에서 실행될지만 결정할 뿐, 프로세스를 몇 개나 실행할지는 관여하지 않습니다.

실제로 의존하는 가장 짧은 주기에 맞춰 간격을 선택하고, 먼저 실행 시간을 측정하십시오.

time sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now

5분은 합리적인 기본값입니다. 09:00에 예약된 게시물은 09:05까지 게시됩니다. 시간에 민감한 작업이 없는 사이트라면 15분도 충분합니다. 1분 간격은 쇼핑몰이나 큐 기반 플러그인처럼 실제로 1분 단위가 필요한 경우에만 사용하며, 작업이 몇 초 안에 완료된다는 것을 확인한 후에 설정해야 합니다.

WP-CLI를 설치할 수 없는 경우

일부 호스팅 환경은 셸 도구 사용을 차단합니다. wp-cron.php에 일반 HTTP 요청을 보내면 전체 웹 스택을 거치기는 하지만 동일한 큐를 실행할 수 있습니다.

*/5 * * * * /usr/bin/curl -sS --max-time 120 "https://example.com/wp-cron.php?doing_wp_cron" > /dev/null

이 방식을 사용할 때 포기해야 하는 사항은 다음과 같습니다.

• 웹 서버와 PHP-FPM의 요청 시간 제한으로 인해 실행 시간이 긴 작업은 중간에 중단될 수 있습니다.
• 인증서가 유효하지 않으면 curl이 SSL certificate problem 오류와 함께 중단되므로, Certbot on nginx를 사용하여 인증서 갱신이 정상적으로 작동하도록 유지해야 합니다.
• 페이지 캐싱이 wp-cron.php를 캐시해서는 안 됩니다. 캐시될 경우 cron 요청이 캐시된 응답을 받아 아무 작업도 실행되지 않습니다.
• 이벤트별 출력 결과를 확인할 수 없으므로, 작업이 실행되었는지 확인하려면 작업 결과물만 살펴봐야 합니다.

-sS 옵션은 성공 시 curl의 출력을 숨기고 오류만 출력하므로, cron 작업에 적합합니다.

서버 스케줄에 포함해야 할 그 밖의 작업

WordPress 큐를 시스템 cron이 관리하게 되었다면, 서버의 나머지 정기 작업도 같은 곳에서 관리하여 한눈에 파악할 수 있도록 합니다. 운영체제 보안 패치는 직접 관리하는 cron 라인보다는 unattended upgrades를 사용하는 것이 적절합니다. WordPress 플러그인 및 테마 업데이트는 다른 관점에서 결정해야 합니다. crontab에 wp plugin update --all를 설정하면 아무도 지켜보지 않는 새벽 3시에 라이브 사이트가 중단될 위험이 있으므로, 신중하게 실행하거나 스테이징 단계와 백업을 거친 후 진행하십시오.

FAQ

WP-Cron을 비활성화하면 예약된 게시물이 발행되지 않습니까?

아니요, 큐를 처리할 다른 수단이 있다면 발행됩니다. DISABLE_WP_CRON는 페이지 로드 시 큐가 트리거되는 것만 막을 뿐입니다. 이벤트는 이전과 동일하게 예약됩니다. 09:00로 설정된 게시물은 09:00 이후 첫 번째 cron 실행 시 발행되므로, 5분 간격으로 설정했다면 09:05까지는 발행됩니다. 상수를 설정하고 cron 항목을 추가하지 않으면, 큐가 실행될 때까지 게시물은 Missed schedule으로 표시된 채 목록에 남아 있습니다.

WordPress cron 작업은 어떤 사용자로 실행해야 합니까?

PHP가 작성하는 파일의 소유자인 사용자로 실행해야 하며, 기본 Ubuntu 설치 환경에서는 www-data입니다. stat -c '%U %G' /srv/www/example.com/wp-content/uploads 명령으로 확인하고 PHP-FPM 풀 설정의 user = 라인과 비교하십시오. root 사용자로 작업을 실행하면 WP-CLI가 YIKES 오류와 함께 중단되며, --allow-root 플래그로 강제 실행할 경우 wp-content 내부에 웹 서버가 이후에 수정할 수 없는 root 소유 파일이 생성됩니다.

시스템 cron은 얼마나 자주 WordPress cron을 실행해야 합니까?

대부분의 사이트에는 5분 간격이 적당합니다. 실제로 의존하는 가장 짧은 예약 주기에 맞추되, 단일 실행에 소요되는 시간보다 충분히 길게 설정하십시오. 소요 시간은 WP-CLI 명령 앞에 time를 붙여 측정할 수 있습니다. 1분 간격으로 설정하면 flock으로 보호하지 않는 한, 트래픽이 많은 사이트에서는 실행이 겹쳐 쌓일 수 있습니다.

WP-Cron을 비활성화한 후 왜 wp cron test가 실패합니까?

해당 명령은 방문자가 트리거하는 스폰 방식을 테스트하기 때문이며, DISABLE_WP_CRON가 true로 설정되면 오류를 보고합니다. 이는 이 방식으로 설정된 서버에서 나타나는 정상적인 결과입니다. 대신 시스템 cron 경로를 확인하십시오. /var/log/wp-cron/example.log을 읽거나, wp cron event schedule로 마커 이벤트를 예약한 뒤 다음 실행 후 wp cron event list에서 해당 이벤트가 사라졌는지 확인하십시오.

WP-CLI가 꼭 필요한가요, 아니면 wp-cron.php에 curl을 사용하는 것으로 충분합니까?

curl도 작동하며, WP-CLI를 설치할 수 없는 환경에서는 올바른 대안입니다. 다만 웹 서버를 통해 WordPress를 로드하므로 속도가 느리고 요청 시간 제한의 영향을 받습니다. WP-CLI는 웹 시간 제한이 없는 명령줄 PHP 프로세스에서 이벤트를 실행하며, 이벤트당 소요 시간을 한 줄씩 출력하므로 로그를 통해 무엇이 실행되었고 얼마나 걸렸는지 정확히 파악할 수 있습니다.