크론 작업은 누군가 사이트를 방문하는지 여부와 관계없이 백그라운드에서 일정에 따라 명령을 실행합니다. 이 가이드에서는 KPanel에서 크론 작업을 추가하는 방법, 이 플랫폼에 맞게 일정과 명령을 올바르게 작성하는 방법, 신뢰할 수 없는 WordPress 내장 스케줄러를 대체하는 방법, 작업이 예상대로 동작하지 않을 때 출력을 확인하는 방법을 다룹니다.
KPanel에서 크론을 찾는 위치
크론은 사이트에 속해 있으므로 메인 메뉴가 아니라 사이트에서 접근합니다:
- KPanel에 로그인한 다음 왼쪽 사이드바에서 웹사이트를 클릭합니다.
- 원하는 사이트를 클릭합니다.
- 사이트 자체 메뉴에서 설정를 연 다음 Cron을 엽니다.
직접 주소는 /websites/<site-id>/cron입니다. 기존 작업 목록이 표에 표시되며, 사이트에 작업이 없으면 빈 상태가 표시됩니다.
작업 추가하기
오른쪽 상단의 크론 작업 추가를 클릭합니다. 양식에는 세 개의 필드가 있습니다.
일정
여섯 개의 사전 설정 버튼이 표현식을 자동으로 채워줍니다:
| 버튼 | 표현식 |
|---|---|
| 매분 | * * * * * |
| 5분마다 | */5 * * * * |
| 매시간 | 0 * * * * |
| 매일 오전 2시 | 0 2 * * * |
| 매주 일요일 | 0 2 * * 0 |
| 월간 1일 | 0 2 1 * * |
또는 크론 표현식에 직접 입력할 수도 있습니다. 순서대로 다섯 필드는 분, 시, 일, 월, 요일입니다:
minute hour day-of-month month day-of-week
0 3 * * *은 매일 오전 3시에 실행됩니다.*/15 * * * *은 15분마다 실행됩니다.0 9 * * 1은 매주 월요일 오전 9시에 실행됩니다.30 1 1 * *은 매월 1일 오전 1시 30분에 실행됩니다.0 */6 * * *은 정각마다 6시간 간격으로 실행됩니다.
라벨
나중에 알아볼 수 있는 이름을 지정하세요. 예를 들어 WordPress cron 또는 Nightly stock sync 같은 것입니다. 작업 표에 표시되는 항목이므로 설명이 되도록 작성하세요. job 3은 새벽 2시에 아무런 도움이 되지 않습니다.
명령
실행할 셸 명령입니다. Save를 클릭하여 작업을 생성합니다.
전체 경로를 사용하세요. 크론은 최소한의 환경에서 실행되며 셸 프로필이 전혀 적용되지 않으므로, SSH로 로그인했을 때는 작동하는 단순한 php나 상대 디렉터리가 여기서는 조용히 실패합니다. 매번 전체 경로를 작성하세요.
명령 작성하기
작업은 사이트 자체의 시스템 사용자로 실행되므로, 홈 디렉터리가 올바른 기준점이 되고 ~는 올바르게 해석됩니다. 사이트 파일은 다음 위치에 있습니다:
~/htdocs/yourdomain.co.nz
사이트의 설정, 그다음 SFTP 탭에서 정확한 경로를 확인할 수 있으며, 사이트 파일 아래에 표시됩니다.
일반적인 명령 예시:
cd ~/htdocs/yourdomain.co.nz && /usr/bin/wp cron event run --due-now
cd ~/htdocs/yourdomain.co.nz && /usr/bin/php bin/send-queued-emails.php
/usr/bin/curl -fsS https://yourdomain.co.nz/api/nightly-report
예약하기 전에 명령을 테스트하세요. wp 명령이라면 사이트의 WordPress, 그다음 Console 섹션에 붙여넣거나 SSH를 통해 실행해 보세요. 절대 작동하지 않을 작업은 새벽 3시에 로그 파일에서 찾는 것보다 프롬프트에서 발견하는 편이 훨씬 쉽습니다.
WordPress의 내장 스케줄러 대체하기
WordPress에는 자체적인 유사 스케줄러인 WP-Cron이 내장되어 있으며, 이는 누군가 페이지를 로드할 때만 작동합니다. 방문이 적은 사이트에서는 예약된 게시물이 늦게 게시되고 이메일이 발송되지 않은 채로 쌓입니다. 방문이 많은 사이트에서는 모든 방문자가 일정 확인 비용을 부담하게 됩니다.
실제 크론 작업은 두 문제를 모두 해결합니다. KPanel은 전체 전환 과정을 대신 처리해 줍니다:
- 사이트를 연 다음 WordPress 탭을 엽니다.
- WP-Cron 섹션을 엽니다.
- 시스템 cron 활성화를 클릭합니다.
이렇게 하면 WP-Cron을 5분마다 실행하는 일정이 추가되고, DISABLE_WP_CRON이 설정되어 페이지 로드가 더 이상 WP-Cron을 트리거하지 않게 됩니다. 같은 화면의 시스템 cron 제거는 두 가지 변경 사항을 모두 되돌립니다.
직접 수동으로 처리하고 싶다면 두 단계로 이루어집니다:
방문자에 의해 트리거되는 버전을 비활성화합니다. 설정, 그다음 파일 관리자를 사용하여 wp-config.php의 /* That's all, stop editing! */ 줄 위에 다음을 추가합니다:
define( 'DISABLE_WP_CRON', true );
실제 작업을 추가합니다. 설정, 그다음 Cron에서:
- 일정:
*/5 * * * * - 라벨:
WordPress cron - 명령:
cd ~/htdocs/yourdomain.co.nz && /usr/bin/wp cron event run --due-now
DISABLE_WP_CRON 부분을 건너뛰지 마세요. 둘 다 실행 중이면 예약된 모든 작업이 두 번 실행될 수 있습니다. 중복 이메일, 중복 주문 처리, 구독 플러그인의 중복 청구가 발생할 수 있습니다. WP-Cron 섹션의 원클릭 작업을 사용하면 이런 일이 발생하지 않습니다.
WooCommerce와 백그라운드 대기열
WooCommerce는 주문 상태 변경, 구독 갱신, 이메일, 재고 업데이트를 위해 백그라운드 대기열을 사용합니다. 이는 WP-Cron에 의존하므로, 방문이 적은 상점에서 바로 문제가 생기는 작업 유형입니다.
실제 일정이 설정되면 대기열은 5분마다 처리됩니다. wp-admin의 WooCommerce, 그다음 Status, 그다음 Scheduled Actions에서 확인할 수 있습니다.
방문량이 많은 상점은 */2 * * * *로 전환할 수 있습니다. 이보다 더 짧게 설정해도 거의 도움이 되지 않습니다. 작업을 수행하는 시간보다 프로세스를 시작하는 데 드는 시간이 더 많아지기 때문입니다. WooCommerce 설정하기를 참고하세요.
기존 작업 관리하기
작업 표에는 라벨, 일정, 명령, 마지막 실행, 상태가 표시되며, 각 행에는 두 가지 작업이 있습니다:
- Disable은 작업을 삭제하지 않고 일시 중지하며, 다시 활성화하려면 Enable로 바뀝니다. 작업이 문제를 일으키는지 테스트할 때 사용하세요.
- Delete는 작업을 영구적으로 제거합니다. 확인 메시지가 표시되며, 예약된 실행은 즉시 중단됩니다.
크론 작업 삭제는 되돌릴 수 없습니다. 일정은 그 즉시 서버에서 제거됩니다. 일시적으로만 중단하려는 경우에는 Disable을 사용하세요.
출력 확인하기
KapsuleHost가 생성하는 모든 작업은 출력을 자동으로 캡처합니다. 표준 출력과 오류는 사이트 사용자의 홈 디렉터리 내 cron-logs 디렉터리의 로그 파일에 추가되며, 작업당 하나의 파일이 생성됩니다.
이 로그는 "내 작업이 실행되었는가?"라는 거의 모든 질문에 대한 답이 됩니다. 명령이 출력한 내용과 발생한 오류를 기록하기 때문입니다.
이를 확인하려면 SSH로 연결하여 ~/cron-logs/을 확인하세요. SSH는 키 인증을 사용하므로, 먼저 사이트의 설정, 그다음 SSH 키 탭에서 공개 키를 추가하세요. SSH 키 추가하기를 참고하세요.
파일 관리자와 SFTP 계정은 사이트 디렉터리인 ~/htdocs/yourdomain.co.nz로 제한되며, cron-logs은 그보다 한 단계 위에 있습니다. 이는 의도적인 설계로, SFTP 접근 권한이 있는 외주 작업자가 웹사이트 외의 영역에 접근하지 못하도록 막아줍니다. 로그에 접근하려면 네이티브 SSH를 사용하거나, 아래와 같이 출력을 사이트 디렉터리로 리디렉션하세요.
파일 관리자에서 열 수 있는 위치에 출력을 저장하고 싶다면 직접 리디렉션하세요:
cd ~/htdocs/yourdomain.co.nz && /usr/bin/wp cron event run --due-now >> ~/htdocs/yourdomain.co.nz/wp-content/cron.log 2>&1
2>&1은 오류를 일반 출력과 동일한 파일로 보냅니다. 이것이 없으면 오류는 어디에도 기록되지 않습니다.
사이트 디렉터리 내부의 모든 항목은 웹을 통해 요청될 가능성이 있습니다. 리디렉션된 로그는 사이트 루트가 아니라 wp-content 아래에 두고, 아무도 추측할 수 없는 이름을 지정한 다음, 디버깅을 마치면 삭제하세요.
모범 사례
- 일정을 분산시키세요. 여섯 개의 작업을 모두
0 2 * * *로 설정하면 모두 동시에 시작됩니다.0 2,10 2,20 2처럼 분산하세요. - 정말로 필요한 경우가 아니라면 매분 실행은 사용하지 마세요. WordPress와 WooCommerce를 포함한 거의 모든 경우에
*/5로도 충분합니다. - 작업을 짧게 유지하세요. 간격보다 오래 걸리는 작업은 다음 실행과 겹치게 됩니다.
- 출력이 많은 작업은 리디렉션하세요. 그래야 수다스러운 작업 하나가 디스크를 가득 채우지 않습니다.
- 목록을 가끔 검토하세요. 제거한 플러그인에서 남은 작업이 계속 실행될 수 있습니다.
문제 해결
작업이 전혀 실행되지 않는 것 같습니다. 먼저 경로를 확인하세요. 로그 파일을 열어보세요. 그런 다음 상태가 Disabled가 아니라 Active인지 확인하세요. 그런 다음 같은 명령을 SSH로 실행해서 어떤 결과가 나오는지 확인하세요.
로그에 "command not found"가 표시됩니다. 전체 경로가 누락된 것입니다. 단순한 이름 대신 /usr/bin/php, /usr/bin/wp, /usr/bin/curl을 사용하세요.
Permission denied. 작업은 사이트의 시스템 사용자로 실행됩니다. 해당 사용자가 명령이 접근하는 모든 것을 소유하거나 최소한 읽을 수 있어야 합니다. 파일 관리자 사용하기에서 권한을 확인하세요.
WordPress 작업이 여전히 늦게 실행됩니다. 전환의 두 부분이 모두 적용되었는지 확인하세요. 설정, 그다음 Cron에 일정이 존재하는지, 그리고 DISABLE_WP_CRON이 설정되어 있는지 확인하세요. WordPress 탭의 WP-Cron 섹션에서 두 상태를 모두 확인할 수 있습니다.
작업은 실행되지만 그동안 사이트가 느려집니다. 더 한가한 시간대로 옮기거나 작업을 더 작은 단위로 나누세요. 사이트 수준의 리소스 사용량은 성능에서 확인할 수 있습니다. 웹사이트 속도 개선하기를 참고하세요.
플러그인 업데이트 후 작업이 동작하지 않게 되었습니다. 명령 경로가 변경되었을 수 있습니다. 로그를 확인한 다음, 작업 표에서 기존 작업을 삭제하고 수정된 작업을 새로 추가하여 명령을 업데이트하세요.