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

WP-Cron의 정의와 시스템 cron으로 대체해야 하는 이유

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

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

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

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

캐시되지 않은 모든 요청은 확인 절차에 비용을 지불합니다. WordPress는 cron 옵션을 로드하여 타임스탬프를 비교하고, 실행할 작업이 있으면 spawn_cron()를 호출합니다. 이는 /wp-cron.php으로 비차단 루프백 요청을 보냅니다. 방문자는 결과를 기다리지 않지만, PHP 워커는 기다립니다. pm.max_children = 5을 사용하는 PHP-FPM 기반의 소규모 VPS에서는 느린 예약 작업 하나가 전체 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을 사용하는 주된 이유입니다. 대부분의 실행 시에는 처리할 작업이 없어 기록되는 내용이 거의 없으므로, 작업이 예정된 실행 시간 이후에 파일을 확인하십시오.

셋째, 전체 과정을 검증합니다. 마커 이벤트를 예약하고 해당 이벤트가 사라지는지 지켜봅니다.

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

한 간격 동안 기다린 후 목록 확인 명령을 다시 실행합니다. 1회성 이벤트는 실행되면 큐에서 제거되므로 훅이 사라져야 합니다. 해당 훅 이름에 콜백을 등록한 플러그인이 없으므로, 이를 실행해도 사이트에는 아무런 영향이 없습니다. 두 간격이 지난 후에도 훅이 목록에 남아 있다면 큐가 실행되지 않는 상태이며, 앞선 두 가지 확인을 통해 문제가 cron에 있는지 WP-CLI에 있는지 파악할 수 있습니다.

이 작업에 wp cron test를 사용하지 마십시오. 해당 명령은 방문자에 의해 트리거되는 스포닝(spawning)이 작동하는지 확인하는 용도이며, DISABLE_WP_CRON이 true일 때 오류가 발생합니다. 올바르게 설정된 서버에서는 이 오류가 예상된 결과이지 결함이 아닙니다.

systemd timer 대안

서버의 나머지 예약 작업이 이미 systemd 서비스 및 타이머로 실행되고 있다면, WordPress 작업도 동일한 방식으로 구성하십시오. 이렇게 하면 모든 실행 기록이 systemctl list-timers에 나타나며, 출력 결과는 로그 로테이션이 필요한 파일 대신 저널(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에 설치되는데, 이 경로는 해당 목록에 포함되어 있지 않습니다. 작업이 시작되자마자 1초도 안 되어 실패하며, 로그에는 다음과 같은 한 줄만 남습니다.

/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은 현재 중복 실행을 방지하는 역할을 합니다. 건너뛴 작업은 설계상 즉시 조용히 종료됩니다.

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

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분 간격은 쇼핑몰이나 큐 기반 플러그인처럼 반드시 필요한 경우에만 사용하며, 작업이 몇 초 안에 끝난다는 것을 확인한 뒤에 설정해야 합니다.

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 작업에서 권장되는 방식입니다.

서버 일정에 포함해야 할 기타 작업

시스템 cron이 WordPress 큐를 관리하게 되었다면, 서버의 나머지 정기 작업도 같은 곳에서 관리하여 한눈에 파악할 수 있도록 합니다. 운영체제 보안 패치는 직접 관리하는 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 프로세스에서 이벤트를 실행하며, 이벤트별로 소요 시간을 한 줄씩 출력하므로 로그를 통해 무엇이 실행되었고 얼마나 걸렸는지 정확히 파악할 수 있습니다.