워드프레스 예약발행 자주 실패한다면 크론 루프백 서버확인

워드프레스 예약발행 실패 후기 서버설정 방법

최근 워드프레스에서 글을 미리 써두고 예약발행까지 걸어놨는데, 시간이 지나도 글이 그대로 예약 상태로 남아 있으면 은근히 답답합니다. 처음에는 저장을 잘못했나 싶지만, 실제로는 글 내용보다 예약발행을 움직이는 자동 실행 기능이 제시간에 돌지 않아서 생기는 경우가 더 많습니다.

특히 카페24, 클라우드웨이즈, 블루호스트 VPS처럼 서버를 조금이라도 만질 수 있는 환경에서는 설정 상태에 따라 증상이 다르게 보입니다. 어떤 사이트는 새벽 예약글이 자주 밀리고, 어떤 사이트는 관리자에 다시 접속해야 발행되며, 어떤 사이트는 예약 시간이 지나도 계속 조용합니다.

저는 이런 문제를 볼 때 글 편집 화면부터 다시 열지 않습니다. 워드프레스 예약발행 실패는 대개 WP-Cron, 루프백 요청, 서버 크론 등록, 여기에 플러그인 충돌까지 겹치면서 생기기 때문입니다. 괜히 글만 다시 예약해 봐야 같은 증상이 반복되는 이유가 여기 있습니다.

예약발행이 문제가 되는 이유

워드프레스 예약발행은 리눅스 서버의 일반 크론처럼 혼자 계속 도는 구조가 아닙니다.

워드프레스 성능 개선 3가지 - 하나 이상의 필수모듈 누락 예정된 이벤트, 지속적인 객체캐시 사

워드프레스 안에서 돌아가는 WP-Cron이 예약 시간을 확인하고 발행 작업을 실행하는데, 이 과정에서 내부 호출이 막히거나 실행 조건이 꼬이면 예약글이 제시간에 올라오지 않을 수 있습니다.

실제로 많이 걸리는 이유는 크게 네 가지입니다.

• 첫째, DISABLE_WP_CRON을 켜둔 상태에서 서버 크론을 등록하지 않은 경우입니다.
• 둘째, 캐시 플러그인이나 보안 플러그인 때문에 루프백 요청이 막히는 경우입니다.
• 셋째, 워드프레스 시간대 설정이 잘못돼 예약 시간이 엇갈리는 경우입니다.
• 넷째, 사이트 방문이 적은 시간대라 WP-Cron이 제때 움직이지 못하는 경우입니다.

겉으로 보면 예약발행 실패는 단순한 오류처럼 보이지만, 안쪽을 들여다보면 결국 자동으로 실행돼야 할 작업이 제대로 돌지 않은 문제에 가깝습니다. 그래서 저는 이 문제가 생기면 글을 다시 쓰기보다 자동 실행 통로부터 먼저 봅니다.

예약발행 문제 시 먼저 볼 곳

가장 먼저 들어가 볼 곳은 워드프레스 관리자 화면의 도구 > 사이트 건강입니다.

여기서 예약 이벤트, 루프백 요청, REST API 관련 경고가 보이면 원인 방향이 꽤 빨리 잡힙니다.

예약글이 안 올라오는데 사이트 건강에서 루프백 오류까지 뜬다면, 그건 거의 글 문제가 아니라 내부 통신 문제라고 봐도 됩니다.

다음은 설정 > 일반의 시간대입니다. 한국에서 운영하는 사이트라면 보통 서울로 맞춰두는 편이 안전합니다.

시간대가 UTC나 다른 지역으로 잡혀 있으면 예약 시간이 어긋나서 사용자는 실패처럼 느끼지만, 실제로는 다른 시각으로 계산되고 있을 수 있습니다.

세 번째는 wp-config.php 파일입니다.

이 파일 안에 아래 코드가 들어 있으면 워드프레스 기본 크론은 꺼진 상태입니다.

define('DISABLE_WP_CRON', true);

이 줄 자체가 무조건 잘못된 건 아닙니다. 서버에서 대신 크론을 돌리고 있다면 오히려 더 안정적일 수 있습니다.

다만 이 값을 켜둔 뒤 실제 서버 크론을 등록하지 않았다면, 예약발행이 자주 밀리거나 멈추는 이유가 되기 쉽습니다. 쉽게 말해 워드프레스 안쪽 알람은 꺼놨는데 바깥에서 대신 깨워줄 장치를 만들지 않은 상태와 비슷합니다.

플러그인 충돌 확인

여기서 많은 분들이 막히는 부분이 하나 있습니다.

“플러그인 충돌 같긴 한데, 운영 중인 사이트에서 플러그인을 전부 꺼볼 수는 없지 않나?” 저도 이 부분이 늘 걸렸습니다.

다행히 꼭 전체 비활성화만 답은 아닙니다. 사이트에 영향 덜 주면서 확인하는 방법이 따로 있습니다.

가장 먼저 볼 수 있는 건 역시 사이트 건강입니다.

여기서 루프백 요청 실패, REST API 오류, 예약 이벤트 경고가 보이면 특정 플러그인이 내부 요청을 막고 있을 가능성이 있습니다.

이름까지 바로 찍어주진 않지만, 적어도 예약발행 실패가 글 저장 문제가 아니라 플러그인이나 서버 쪽 통신 문제라는 건 거의 분명해집니다.

그다음으로 쓸 만한 방법은 Troubleshooting Mode입니다. 이 방식은 전체 방문자에게는 아무 영향 없이, 내 관리자 계정에서만 플러그인과 테마를 따로 테스트할 수 있는 형태라 운영 사이트에서도 부담이 덜합니다.

사이트를 공개로 운영 중인데 전체 플러그인을 끄기 어렵다면 이쪽이 훨씬 현실적입니다.

또 하나 많이 쓰는 방법은 Query Monitor입니다.

이 플러그인은 관리자 화면에서 PHP 경고, HTTP 요청 오류, 느린 쿼리, 특정 플러그인에서 발생한 문제를 비교적 자세히 보여줍니다. 예약발행이 실패하는 순간 특정 보안 플러그인이 403을 만들었는지, 특정 캐시 플러그인이 내부 호출을 막았는지 살펴볼 때 도움이 됩니다.

그리고 생각보다 놓치기 쉬운 게 디버그 로그입니다. 화면에는 아무 오류가 안 보여도, 예약발행 시점에만 특정 플러그인 파일에서 경고나 치명적 오류가 찍히는 경우가 있습니다. 이런 건 관리자 화면만 봐서는 잘 안 보이고, 로그를 직접 봐야 드러납니다.

디버그 로그 켜는 방법

wp-config.php에 아래 설정을 넣으면 화면에는 에러를 노출하지 않고 로그 파일만 남길 수 있습니다.

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

이 상태에서 테스트 글을 5분 뒤로 예약하고, 실패가 다시 생긴 뒤 wp-content/debug.log를 보면 됩니다.

거기서 특정 플러그인 경로나 함수 이름이 반복해서 보이면 꽤 유력한 단서가 됩니다.

저는 예약발행 문제를 볼 때 이 로그를 같이 보는 편이 훨씬 빨랐습니다. 화면은 멀쩡한데 로그는 아주 시끄러운 경우가 생각보다 많기 때문입니다.

전부 끄지 않고 보는 순서

운영 중 사이트라면 저는 보통 이렇게 봅니다.

먼저 사이트 건강에서 루프백과 예약 이벤트 경고를 확인합니다.

그다음 Troubleshooting Mode로 내 계정에서만 테스트합니다.

필요하면 Query Monitor로 관리자 화면의 오류를 보고, 마지막으로 debug.log에서 예약발행 시점 에러를 확인합니다. 이 정도만 해도 플러그인 충돌인지 아닌지, 어느 쪽이 더 의심스러운지 꽤 빠르게 좁혀집니다.

한 번에 점검

예약발행 문제를 한 번에 정리하고 싶다면 순서를 정해두는 게 좋습니다.

이것저것 동시에 건드리면 뭐 때문에 나아졌는지 오히려 더 헷갈립니다. 저는 아래 순서대로 보는 편입니다.

점검 항목	정상 상태	문제 신호	확인 방법
사이트 건강	중요 경고 없음	루프백 실패, 예약 이벤트 경고	도구 > 사이트 건강
시간대 설정	서울로 설정	UTC 또는 다른 지역	설정 > 일반
wp-config.php	기본 크론 사용 또는 서버 크론 연동	DISABLE_WP_CRON만 켜져 있음	파일 직접 확인
플러그인 충돌	루프백 및 내부 요청 정상	401, 403, timeout, PHP 오류	Troubleshooting, Query Monitor, debug.log
테스트 글	예약 시간에 자동 발행	예약 상태로 남아 있음	5분 뒤 테스트 예약

위 표만 순서대로 확인해도 원인 범위가 꽤 빠르게 줄어듭니다.

예약발행은 괜히 손댈 곳이 많아 보이지만, 실제로는 몇 군데만 보면 됩니다. 문제는 조용해서 더 짜증 난다는 점인데, 로그와 사이트 건강을 같이 보기 시작하면 생각보다 금방 윤곽이 잡힙니다.

카페24 확인방법

카페24에서 워드프레스 예약발행이 자주 실패한다면 먼저 wp-config.php에 DISABLE_WP_CRON이 들어 있는지부터 보는 게 좋습니다.

이 값이 들어간 상태에서 서버 쪽 크론 등록이 빠져 있으면 예약글이 밀리거나 아예 발행되지 않을 수 있습니다.

카페24는 상품에 따라 조금 다르지만 보통 호스팅 관리자 쪽에서 크론 서비스를 따로 등록하는 방식이 쓰입니다.

여기서 워드프레스의 wp-cron.php가 일정 간격으로 실행되도록 잡아두면 예약발행 안정성이 꽤 좋아집니다. 방문이 적은 블로그일수록 이런 차이가 더 눈에 들어옵니다.

카페24에서 자주 놓치는 부분은 두 가지입니다.

하나는 워드프레스 내부 크론을 꺼둔 사실을 모르고 있는 경우, 다른 하나는 크론을 등록했지만 호출 주기가 너무 길거나 경로가 잘못된 경우입니다. 예약발행이 중요하면 5분 또는 15분 간격으로 확인하는 편이 무난합니다.

클라우드웨이즈 확인

클라우드웨이즈는 서버 자동 작업을 직접 넣기 편한 편이라 예약발행 문제도 비교적 정리하기 쉽습니다.

이 환경에서는 워드프레스 내부 기능에만 맡기기보다, 서버 쪽에서 wp-cron.php를 일정 간격으로 호출해 주는 방식이 훨씬 안정적입니다.

실제로는 아래처럼 curl이나 wget 명령을 넣는 형태를 많이 씁니다.

curl -s https://내도메인.com/wp-cron.php > /dev/null 2>&1

wget --delete-after https://내도메인.com/wp-cron.php

이렇게 주기적으로 워드프레스 크론을 깨워주면 새벽 예약발행이나 방문이 적은 시간대에도 비교적 일정하게 동작합니다.

블로그 예약발행이 자주 있는 사이트라면 5분 간격이 더 편하고, 조금 느슨하게 잡고 싶다면 15분도 쓸 수 있습니다.

블루호스트 VPS 확인

블루호스트 VPS에서는 크론 등록은 되어 있는데 실제 실행 기록이 제대로 남지 않는 경우도 있습니다.

그래서 단순히 작업이 보인다고 끝내지 말고, 마지막 실행 시간과 호출 주소까지 같이 보는 게 좋습니다.

특히 실수하기 쉬운 부분은 도메인 주소 오타, 호출 주기를 너무 길게 잡은 경우, wp-config에서는 기본 크론을 꺼뒀는데 서버 크론 명령이 틀린 경우입니다. 예약발행 실패가 이어진다면 결국 여기서도 볼 건 비슷합니다. 시간대, WP-Cron, 루프백 오류, 플러그인 충돌. 이름만 다를 뿐 문제 생기는 자리는 거의 비슷합니다.

루프백 오류

서버 크론까지 제대로 넣어뒀는데 예약발행이 불안정하다면 그다음은 루프백 요청을 의심해봐야 합니다.

루프백 요청은 워드프레스가 자기 자신에게 보내는 내부 호출이라고 보면 됩니다. 이게 막히면 예약발행뿐 아니라 자동업데이트, 일부 플러그인 작업, 사이트 건강 검사까지 같이 어긋날 수 있습니다.

특히 cURL error 28, 401 오류, 403 오류 같은 문구가 보이면 캐시나 보안 관련 설정부터 보는 편이 좋습니다. 예전에는 이런 문구가 떠도 그냥 서버가 느린가 보다 했는데, 실제로는 특정 보안 플러그인이 내부 요청을 막고 있던 경우가 더 많았습니다.

가장 덜 꼬이는 방식

정리하면 가장 덜 꼬이는 방식은 단순합니다.

워드프레스 기본 크론에만 맡기지 말고, 서버에서 wp-cron.php를 일정 간격으로 직접 실행하게 만들어 두는 것입니다.

여기에 시간대를 맞춰두고, 루프백 요청이 막히지 않게 정리하고, 플러그인 충돌 여부를 로그로 확인하면 예약발행 문제는 대부분 잠잠해집니다.

특히 카페24, 클라우드웨이즈, 블루호스트 VPS처럼 서버 설정을 만질 수 있는 환경이라면 이 방법이 장기적으로 더 편합니다. 예약글뿐 아니라 백업, 자동 작업, 일부 플러그인 일정 실행까지 같이 안정되는 경우가 많아서 나중에 비슷한 문제로 다시 붙잡고 씨름할 일이 줄어듭니다.

직접 해보는 순서

지금 바로 점검하려면 아래 순서대로 해보시면 됩니다.

1. 설정 > 일반에서 시간대를 서울로 맞춥니다.

2. 도구 > 사이트 건강에서 예약 이벤트와 루프백 경고를 확인합니다.

3. wp-config.php에서 DISABLE_WP_CRON이 있는지 봅니다.

4. 있다면 서버 쪽 크론 작업을 등록하거나 실행 상태를 다시 확인합니다.

5. 플러그인을 바로 다 끄지 말고 Troubleshooting Mode, Query Monitor, debug.log로 충돌 흔적을 먼저 확인합니다.

6. 테스트 글을 5분 뒤로 예약해 실제 발행 여부를 다시 봅니다.

7. 그래도 안 되면 루프백 차단, 서버 호출 기록, 보안 플러그인 설정을 다시 봅니다.

이 순서대로 보면 대부분은 원인이 꽤 빨리 드러납니다. 예약발행 실패는 괜히 복잡해 보이지만, 실제로는 확인할 자리가 어느 정도 정해져 있습니다. 괜히 글만 다시 저장하거나 예약 시간을 여러 번 바꾸기 전에, 자동 실행 장치와 내부 통신부터 점검하는 편이 훨씬 낫습니다.

Q. 워드프레스 예약발행이 자꾸 실패하는 가장 흔한 이유는 뭔가요

가장 흔한 이유는 WP-Cron이 제시간에 실행되지 않는 경우입니다. 방문자가 적어 호출이 늦어지거나, DISABLE_WP_CRON만 켜두고 서버 크론을 등록하지 않았거나, 루프백 요청이 막힌 경우가 많습니다.

Q. DISABLE_WP_CRON이 있으면 무조건 잘못된 건가요

그렇지는 않습니다. 서버 크론을 따로 돌리고 있다면 오히려 더 안정적일 수 있습니다. 문제는 워드프레스 내부 크론만 꺼두고 외부에서 대신 실행해 줄 장치를 만들지 않았을 때입니다.

Q. 플러그인 충돌인지 꼭 비활성화해야만 알 수 있나요

반드시 그렇지는 않습니다. 사이트 건강의 루프백 경고, Troubleshooting Mode, Query Monitor, debug.log를 함께 보면 전체 플러그인을 끄지 않고도 꽤 많이 좁혀볼 수 있습니다.

Q. 카페24에서 예약발행이 안 되면 어디부터 봐야 하나요

먼저 시간대와 사이트 건강을 보고, 그다음 wp-config.php의 DISABLE_WP_CRON 여부를 확인하는 편이 좋습니다. 이후 호스팅 관리자 쪽 크론 등록 상태를 보면 원인 범위가 많이 줄어듭니다.

Q. 클라우드웨이즈나 블루호스트는 몇 분 간격이 적당한가요

예약발행 기준으로는 5분 간격이 가장 무난합니다. 서버 자원을 조금 더 아끼고 싶다면 15분 간격도 가능하지만, 정시 발행 정확도는 5분 쪽이 더 낫습니다.

Q. 루프백 오류가 뜨면 어떻게 해야 하나요

캐시 플러그인, 보안 플러그인, 방화벽, SSL 설정부터 확인해 보는 편이 좋습니다. 여기에 Query Monitor나 debug.log를 같이 보면 어떤 플러그인이 내부 요청을 막는지 단서가 더 잘 보입니다.

워드프레스 예약발행 실패는 자주 겪는 문제지만, 구조를 한 번 이해하고 나면 막연한 오류처럼 느껴지지 않습니다.

카페24든 클라우드웨이즈든 블루호스트 VPS든 결국 핵심은 비슷합니다. WP-Cron이 실제로 돌고 있는지, 루프백 요청이 막히지 않았는지, 서버 쪽 자동 실행이 제대로 잡혀 있는지, 그리고 플러그인 충돌 흔적이 로그에 남는지 이 네 가지만 먼저 확인해도 방향이 꽤 빨리 보입니다.