시간 기반 스케줄러가 안 도는 가장 흔한 결론
대부분의 문제는 크론(스케줄) 자체가 기대한 시간에 실행되지 않거나, 실행은 되는데 워커·권한·타임존·큐 상태에서 막혀서 “안 돈 것처럼” 보일 때 생깁니다.
그래서 로그는 “에러가 난 줄”만 보기보다, 아래 순서대로 먼저 확인할 원인을 잡아가는 게 가장 빠릅니다.
로그에서 원인 찾는 순서: 점검표로 정리
로그를 열었을 때, 에러 문장부터 찾기보다 “실행 파이프라인” 관점으로 건너뛰지 말고 내려가 보세요.
- 스케줄러가 실행을 “찍었는지” → 큐/워커가 “처리했는지”
- 시간은 “서버 타임존” 기준으로 해석되는지
- 권한/토큰/권한 없는 작업이 아닌지
- 재시도·중복 실행 제한이 의도치 않게 발동되지 않았는지
- “스케줄 트리거” 로그가 있으면 다음 단계로 넘어갑니다.
- 트리거가 없으면 크론/타임존/작동 주기 설정부터 의심합니다.
- 트리거는 있는데 “실행 시작”이 없으면 워커·큐·권한을 먼저 봅니다.
| 1차로 볼 것 | 확인 포인트(로그/화면에서) | 의심 원인 | 바로 할 수 있는 조치 |
|---|---|---|---|
| 스케줄 트리거 흔적 | 해당 시간대에 “잡이 시작되었다/트리거되었다”는 문구 존재 여부 | 크론 착각, 타임존 불일치, 스케줄러 자체 미작동 | 실행 기준 시각(서버/플러그인)을 먼저 맞추기 |
| 작업 생성/큐 적재 | 트리거 후 “큐에 넣었다/작업이 생성되었다” 로그가 있는지 | 큐 적재 실패, 환경 설정 누락 | 큐 설정/대기열 로그 확인 후 재시도 |
| 워커 처리 로그 | 워커가 “작업 처리 시작/종료”를 남기는지 | 워커 미구동, 프로세스 종료, 장애 | 워커 상태(실행 중인지)부터 확인 |
| 권한/토큰 오류 | 인증·권한·토큰 관련 메시지(예: 권한 없음, 토큰 만료 등) 등장 여부 | 스케줄 실행 계정과 API 권한 불일치 | 스케줄이 쓰는 계정 권한/토큰 재확인 |
| 중복 제한/재시도 정책 | “이미 실행 중/스킵됨/재시도 대기” 같은 문구 | 중복 실행 방지 때문에 스킵됨 | 동시성/중복 제한 값 확인 후 테스트 |
| 환경(메모리/타임아웃) | 처리 중 갑자기 끊기는지, 타임아웃/리소스 관련 문구 | 작업이 오래 걸려 종료됨 | 작업 단위 줄이기, 타임아웃 설정 점검 |
로그에 “에러가 없다”면 더 위험할 수 있어요. 이럴 땐 트리거 자체가 안 찍히거나(크론/타임존), 트리거는 찍히는데 워커가 처리를 못 하는 경우가 많습니다.
크론 착각 줄이는 체크리스트: 설정 먼저 점검
스케줄이 “안 돈다”는 말을 가장 자주 만드는 건, 설정한 시간 기준과 실제 실행 기준이 다른 경우예요.
1) 시간 기준이 뭐냐부터 확인
크론 표현식에서 분/시를 맞춰도, 실제 실행은 서버의 타임존 또는 워드프레스/플러그인의 시간 기준으로 돌아갈 수 있어요.
따라서 로그에서 “언제 실행 트리거가 찍혔는지”와, 서버 시간(또는 앱 시간)이 같은지부터 맞추는 게 1순위입니다.
2) “서버가 잠들어 있지 않은지” 확인
호스팅 환경이 절전 모드/스케줄 프로세스 제한을 걸어두면 크론이 예약만 하고 실 실행이 막히는 경우가 생깁니다.
이때는 웹 요청은 되는데 작업만 조용히 끊기는 패턴이 흔해요.
3) 스케줄러 프로세스가 실제로 상시 실행 중인지
로컬에서는 잘 도는 설정이 배포 후엔 프로세스가 꺼져서 멈추기도 합니다.
“설정 저장”만 했는지, “실행 주체(워커/스케줄러)가 켜져 있는지”를 로그에서 확인하세요.
4) 테스트는 ‘가까운 시간’으로 짧게
바로 다음 1~2분 안에 실행되게 테스트해보면, 크론 표현식/타임존 문제인지, 워커/큐 문제인지가 빠르게 갈립니다.
테스트 시간을 너무 멀리 잡으면 원인 찾는 시간이 늘어나요.
“처음엔 트리거가 찍히는지”만 확인하는 1차 테스트를 먼저 해두면, 실패해도 다음 단계 점검으로 바로 넘어갈 수 있어요.
타임존 문제를 확실히 거르는 방법
타임존은 애매하게 넘어가면 계속 헷갈립니다. 아래를 같이 확인해 주세요.
- 스케줄을 설정한 화면/설정값에서 “시간 기준”이 명시되어 있는지 확인합니다.
- 서버 시간(운영 환경)과 워드프레스 시간(사이트 시간)이 동일한지 확인합니다.
- 로그에 찍힌 실행 시각과 “내가 기대한 시각”을 분 단위로 비교합니다.
- 일광절약시간(DST)처럼 계절에 따라 달라지는 환경이면, 변경 시점 전후로 테스트합니다.
타임존이 어긋나면 “주기 자체”는 정상인데도 실행이 다른 시간에 일어나서, 사용자 입장에서는 계속 누락처럼 보일 수 있어요.
워커·큐·권한 문제: 실행은 되는데 결과가 없는 경우
크론 트리거가 찍히는데도 실제 작업 결과(예: 글 발행, 댓글 처리, 알림)가 안 나오면 “실행 이후 단계”를 봐야 합니다.
워커가 꺼져 있는 경우
작업은 큐에 들어갔는데 워커 프로세스가 꺼져 있으면 처리 로그가 없을 가능성이 큽니다.
이때는 웹 요청이 잘 된다고 해서 스케줄 결과까지 괜찮다고 볼 수 없어요.
권한/토큰이 스케줄러 계정과 불일치
스케줄러가 쓰는 계정과 실제로 작업을 수행하는 계정 권한이 다르면, 에러가 나더라도 “실행은 했는데 결과가 없다” 형태로 보일 수 있습니다.
로그에서 인증·권한 관련 문구가 있는지 먼저 확인해 주세요.
중복 실행 제한으로 스킵되는 경우
같은 작업이 겹치지 않게 막아둔 설정이 오히려 “항상 스킵” 상태로 만들기도 합니다.
중복 제한/동시성 설정이 있다면, 테스트 기간을 짧게 하면서 스킵 로그가 찍히는지 확인하세요.
재시도 정책(몇 초 뒤 다시 시도)이 있으면, “안 돌아간 것처럼” 보여도 실제로는 계속 스킵/대기 중일 수 있어요. 스킵/재시도 문구를 꼭 함께 확인하세요.
WPFLOW로 시간 스케줄 안정화할 때 유용한 점검 포인트
WPFLOW 자동화는 설정만 해두면 끝이 아니라, “실행 환경에서 실제로 돌아가느냐”까지 같이 봐야 안정적으로 유지됩니다.
아래 항목은 시간 기반 스케줄러에서 특히 자주 놓치는 부분이에요.
- 예약 실행이 걸린 흐름에서 실제 실행 로그가 찍히는지 먼저 확인
- 크로스포스트/외부 연동이 있으면 권한·토큰 오류가 없는지 점검
- 큐/워커(실행 프로세스)가 정상인 환경인지 확인
- 테스트는 가까운 시간으로 짧게 반복해 “트리거→처리” 연결이 되는지 확인
원하시면 wpflow로 스케줄 기반 흐름을 만들 때 초안을 빠르게 잡고, 로그/설정 점검 항목까지 포함해 정리하는 방식으로 작업 시간을 줄여보세요. 시작은 https://wpflow.kr에서 하실 수 있어요.
자주 묻는 질문
크론 설정은 맞는데도 실행 트리거 로그가 안 찍혀요. 어디부터 봐야 하나요?
가장 먼저 시간 기준(타임존)과 스케줄러 프로세스가 실제로 계속 실행 중인지부터 확인하세요. 그다음으로 서버 절전/작업 제한 같은 운영 환경 이슈가 있는지 봅니다.
트리거 로그는 있는데 결과가 없어요. 이 경우는 어떤 원인이 많나요?
대개 워커·큐 처리 단계에서 막히거나, 권한/토큰 문제로 작업이 수행되지 않는 경우가 많습니다. 로그에서 “큐 적재/처리 시작/인증 오류/스킵/재시도” 문구가 있는지 순서대로 확인해 보세요.
테스트 시간을 어떻게 잡는 게 좋아요?
처음에는 1~2분처럼 가까운 시간으로 짧게 잡아 “트리거가 찍히는지”와 “처리가 이어지는지”를 빠르게 확인하는 편이 원인 분리가 쉬워요. 멀리 잡으면 점검 시간이 늘어납니다.
마무리: 로그 한 줄로도 원인 순서를 잡을 수 있어요
시간 기반 스케줄러가 안 도는 날은 “에러 찾기”보다 트리거→큐→워커→권한→재시도 흐름으로 체크하면 훨씬 빨리 정리됩니다.
다음 글을 통해 크론 착각이나 중복 실행 이슈를 더 줄이는 방식도 같이 보면 도움이 됩니다. 예를 들어 웹훅 중복 발행 패턴, 크로스포스트 권한·토큰 체크도 함께 점검해 보세요.
