자동 발행 워크플로를 구축해두고 며칠 뒤 확인하면 일부 포스트가 발행되지 않은 채 누락되어 있는 경우가 있습니다. 에러 메시지도 없고, 로그상 성공으로 찍혀 있는데 WordPress에는 글이 없는 상황입니다. 이런 불일치는 retry 트리거 누락 또는 published_log와 실제 발행 상태 사이의 정합성 문제에서 비롯됩니다.
이 글에서는 WordPress 자동 발행 파이프라인에서 retry 트리거가 왜 작동하지 않는지 진단하는 방법과, published_log와 WordPress 실제 상태를 비교해 정합성을 확인하는 구체적인 절차를 정리합니다.
자동 발행 파이프라인에서 retry 트리거가 필요한 이유
WordPress REST API를 통한 자동 발행은 네트워크 지연, API 타임아웃, 인증 토큰 만료 등 다양한 이유로 중간에 실패할 수 있습니다. 문제는 실패가 발생했을 때 파이프라인이 이를 인지하고 재시도(retry)하는 구조가 없으면, 해당 항목은 처리된 것처럼 published_log에 기록되거나 아무 기록 없이 조용히 건너뛰어진다는 점입니다.
retry 트리거가 필요한 대표적인 상황은 다음과 같습니다.
- WordPress REST API 응답이
200이 아닌500또는503으로 돌아왔을 때 - API 응답 자체가 없었을 때 (타임아웃)
- 발행 요청은 성공했으나 반환된
post_id가published_log에 기록되지 않았을 때 - 인증 토큰이 만료되어
401오류가 발생했을 때
이 중 마지막 케이스가 가장 까다롭습니다. 발행은 실제로 됐는데 로그에는 없는 상황, 반대로 로그에는 성공으로 기록됐는데 WordPress에는 글이 없는 상황 모두 정합성 오류에 해당합니다.
retry 트리거가 포함된 발행 흐름 구조
retry 트리거 진단 절차
retry 트리거가 제대로 작동하는지 확인하려면 파이프라인의 각 단계에서 응답값이 올바르게 처리되고 있는지 추적해야 합니다.
1단계 — API 응답 코드 로깅 확인
WordPress REST API 발행 요청 직후, 응답 상태 코드(status_code)를 반드시 로그에 기록하도록 설정되어 있는지 확인합니다. 201 Created가 아닌 경우에는 retry 조건으로 분기해야 합니다.
n8n 기준으로는 HTTP Request 노드 이후 IF 노드를 연결해 {{ $response.statusCode }}가 201인지 여부로 분기하는 구조가 일반적입니다. 이 분기가 없으면 실패해도 다음 노드로 그대로 넘어갑니다.
2단계 — retry 횟수 상한 설정 여부 확인
retry 로직이 있더라도 무한 루프 방지를 위한 상한이 없으면 동일 항목을 계속 재시도하는 문제가 발생합니다. retry_count 필드를 published_log 또는 별도 상태 테이블에 기록하고, 일반적으로 3회 초과 시 failed 상태로 마킹하는 방식을 권장합니다.
3단계 — retry 트리거 발동 조건 점검
retry가 전혀 발동하지 않는다면 트리거 조건 자체가 잘못 설정된 경우가 많습니다. 다음 항목을 순서대로 점검합니다.
| 점검 항목 | 정상 상태 | 문제 상태 |
|---|---|---|
| API 응답 코드 분기 | 201 외 코드 → retry 분기 | 모든 응답을 성공으로 처리 |
| retry_count 기록 | 시도마다 +1 기록 | 기록 없음, 무한 루프 가능 |
| 실패 항목 상태값 | pending 또는 failed로 구분 | published로 잘못 기록 |
| retry 트리거 스케줄 | 주기적으로 pending 항목 재처리 | 트리거 없음, 수동 실행 필요 |
published_log 상태값 구조 예시
published_log 정합성 체크 방법
published_log는 어떤 콘텐츠가 언제 발행됐는지 기록하는 테이블 또는 시트입니다. 이 로그와 WordPress의 실제 발행 상태가 일치하지 않으면 중복 발행이나 누락이 발생합니다.
정합성 체크의 기본 원리
핵심은 published_log에 기록된 post_id가 WordPress에 실제로 존재하는지 대조하는 것입니다. WordPress REST API의 GET /wp/v2/posts/{id} 엔드포인트를 활용하면 특정 post_id의 존재 여부와 상태(publish, draft, trash)를 확인할 수 있습니다.
정합성 체크 절차
다음 순서로 진행합니다.
① 로그에서 published 상태 항목 추출
published_log에서 status = published로 기록된 항목과 해당 post_id를 전체 추출합니다.
② WordPress API로 실제 상태 조회
추출한 post_id마다 GET /wp/v2/posts/{post_id}를 호출해 응답값의 status 필드를 확인합니다. 응답이 404이면 WordPress에 해당 포스트가 존재하지 않습니다.
③ 불일치 항목 분류
결과를 세 가지로 분류합니다.
- 정상: 로그
published+ WordPresspublish상태 일치 - 로그 오기록: 로그에는
published인데 WordPress에 없거나draft상태 - 로그 누락: WordPress에는 글이 있는데 로그에 기록이 없음
④ 불일치 항목 처리
로그 오기록 항목은 status를 pending으로 재설정 후 retry 트리거 대상에 포함시킵니다. 로그 누락 항목은 post_id와 발행 시각을 역으로 기록해 로그를 보완합니다.
자주 발생하는 정합성 오류 패턴과 원인
실제 운영 환경에서 반복적으로 나타나는 패턴은 다음과 같습니다.
| 오류 패턴 | 원인 | 조치 |
|---|---|---|
| 로그에 published, WordPress에 없음 | API 타임아웃 후 로그만 먼저 기록 | 로그 기록을 API 성공 응답 이후로 순서 변경 |
| 같은 콘텐츠 중복 발행 | retry 시 중복 체크 로직 없음 | 발행 전 slug 또는 title 중복 확인 쿼리 추가 |
| 로그 기록 없이 WordPress에만 글 존재 | 로그 기록 단계에서 오류 발생 | 로그 기록 실패 시 별도 알림 트리거 추가 |
| draft 상태로 잘못 발행 | API 요청 시 status 파라미터 누락 | 요청 body에 "status": "publish" 명시 |
정합성 체크 결과 분류 흐름
정합성 체크 자동화를 위한 구조 권장 사항
매번 수동으로 대조하는 것은 비효율적입니다. 정합성 체크 자체를 별도 워크플로로 구성하면 주기적으로 자동 실행할 수 있습니다.
권장 구조는 다음과 같습니다.
- 스케줄 트리거: 매일 1회 또는 발행 완료 후 N분 뒤 실행
- 데이터 조회:
published_log에서 최근 N건의 published 항목 추출 - API 대조: 각
post_id마다 WordPress API 호출 후 상태 비교 - 불일치 처리: 불일치 항목을
mismatch상태로 마킹 + Slack 또는 이메일 알림 발송 - retry 연동:
mismatch항목을 retry 트리거 대상 큐에 자동 추가
이 구조를 갖추면 파이프라인이 조용히 실패하는 상황을 사전에 감지할 수 있습니다. WordPress REST API 공식 문서(developer.wordpress.org/rest-api)에서 각 엔드포인트 응답 스펙을 확인하면 체크 로직 설계에 도움이 됩니다.
자주 묻는 질문
Q. published_log는 어디에 저장하는 것이 좋습니까?
Google Sheets, Airtable, 또는 MySQL 중 파이프라인 도구와 연동이 쉬운 것을 선택합니다. n8n 기준으로는 Google Sheets 또는 Airtable 노드가 기본 지원되어 설정이 간단합니다.
Q. retry 횟수는 몇 회로 설정하는 것이 적절합니까?
일반적으로 3회를 상한으로 설정하고, 초과 시 failed 상태로 마킹 후 수동 확인 알림을 발송하는 방식이 권장됩니다. 네트워크 문제가 아닌 콘텐츠 자체의 오류라면 자동 retry로 해결되지 않기 때문입니다.
Q. WordPress API 호출 시 인증은 어떻게 처리합니까?
Application Passwords 방식이 현재 WordPress에서 권장하는 인증 방식입니다. JWT 플러그인을 사용하는 경우 토큰 만료 주기를 파이프라인 실행 주기보다 길게 설정해야 401 오류로 인한 정합성 오류를 방지할 수 있습니다.
retry 트리거와 정합성 체크는 자동 발행 파이프라인에서 가장 나중에 챙기게 되는 부분이지만, 운영 기간이 길어질수록 이 구조가 없으면 누락 포스트를 일일이 찾아내야 하는 상황이 반복됩니다. 처음 파이프라인을 설계할 때 함께 구성해두는 것이 결과적으로 훨씬 적은 시간이 듭니다.
썸네일: Brett Jordan on Unsplash