워드프레스 REST API로 글을 자동 발행하는 스크립트를 돌렸는데 갑자기 401이나 403이 뜬다면 원인이 뭘까요? 대부분은 인증 방식이 애플리케이션 비밀번호로 넘어가지 않았거나, 짧은 시간에 요청을 반복해서 서버 쪽에서 요청을 막은 경우입니다. 이 글에서는 워드프레스 5.6 이상을 기준으로 REST API 인증을 세팅하는 방법과, 자동으로 발행할 때 429 응답을 받으면 어떻게 재시도해야 안전한지 정리합니다.
XML-RPC 대신 REST API로 자동 발행하는 이유가 뭔가요?
xmlrpc.php는 오래전부터 워드프레스에 있었지만, 무차별 로그인 시도의 통로로 자주 악용돼서 보안 플러그인이 아예 막아버리는 경우가 많습니다. 반면 워드프레스 4.7부터 코어에 내장된 REST API는 /wp-json/wp/v2/posts 같은 엔드포인트로 JSON을 주고받는 구조라 응답을 파싱하기 쉽고, 구텐베르크 에디터 자체도 이 API로 글을 저장합니다.
그래서 자동 발행 파이프라인을 새로 짠다면 xmlrpc보다 REST API 쪽이 유지보수 측면에서 낫습니다. 다만 호스팅사에 따라 REST API 자체를 방화벽에서 차단해둔 경우가 있어서, 스크립트를 짜기 전에 /wp-json/ 주소가 브라우저에서 정상적으로 JSON을 반환하는지부터 확인하는 편이 안전합니다.
애플리케이션 비밀번호 발급과 인증 방식 비교
워드프레스 관리자 프로필 화면 맨 아래로 내려가면 “Application Passwords” 항목이 있습니다. 이름을 입력하고 새 비밀번호 추가를 누르면 4자리씩 6그룹으로 묶인 문자열이 한 번만 표시되는데, 이걸 저장해뒀다가 사용자명과 함께 Basic 인증 헤더에 넣으면 됩니다. 워드프레스 공식 문서에서 이 기능을 애플리케이션 비밀번호라는 이름으로 설명하고 있습니다.
curl -X POST https://example.com/wp-json/wp/v2/posts \
-u "admin:ab12 cd34 ef56 gh78 ij90 kl12" \
-H "Content-Type: application/json" \
-d '{"title":"자동 발행 테스트","content":"본문 내용입니다","status":"publish"}'정상적으로 인증되면 아래처럼 새로 생성된 글의 id와 link가 담긴 JSON이 돌아옵니다.
{"id":4821,"date":"2026-09-14T10:03:12","link":"https://example.com/?p=4821","status":"publish","title":{"rendered":"자동 발행 테스트"}}인증 방식은 애플리케이션 비밀번호 외에도 몇 가지가 더 있는데, 용도에 따라 골라야 합니다.
| 인증 방식 | 코어 지원 여부 | 별도 플러그인 | 비고 |
|---|---|---|---|
| 애플리케이션 비밀번호 | 5.6 이상 기본 지원 | 불필요 | HTTPS 필요, Authorization: Basic 헤더 사용 |
| Basic Auth 플러그인 | 미지원 | WP REST API – Basic Auth 필요 | 로컬 개발·테스트용, 운영 서버엔 비권장 |
| OAuth 1.0a | 미지원 | WP REST API – OAuth1 필요 | 불특정 다수에게 배포하는 서드파티 앱에 적합 |
| 쿠키 + Nonce | 기본 지원 | 불필요 | 브라우저 세션 기반이라 외부 스크립트엔 부적합 |
혼자 운영하는 블로그를 스크립트로 자동 발행할 때는 애플리케이션 비밀번호만으로 충분한 경우가 대부분입니다.
요청이 몰리면 429와 Retry-After 헤더가 돌아옵니다
워드프레스 코어 자체에는 REST API 요청 횟수를 제한하는 기능이 없습니다. 대신 서버단 웹방화벽, Wordfence 같은 보안 플러그인, 또는 Cloudflare 같은 CDN이 짧은 시간에 몰린 요청을 429 상태 코드로 걸러내는 구조입니다. 이때 응답 헤더에 Retry-After가 포함돼 있으면 몇 초 뒤에 다시 시도하라는 신호로 보면 됩니다.
문제는 이 헤더가 항상 붙어 있지는 않다는 점입니다. 방화벽 설정에 따라 헤더 없이 그냥 429나 403만 돌려주는 경우도 있어서, 스크립트에서는 헤더가 없을 때를 대비한 기본 대기시간을 따로 정해두는 편이 안전합니다.
발행 스크립트에 재시도와 백오프 로직을 넣어보세요
여러 개의 글을 한 번에 자동 발행할 때는 요청 사이에 간격을 두고, 429가 오면 Retry-After 값만큼 기다렸다가 다시 시도하는 함수 하나만 있어도 실패율이 크게 줄어듭니다. 아래는 파이썬 requests 라이브러리로 짠 예시입니다.
import time
import requests
def publish_post(url, auth, payload, max_retries=5):
for attempt in range(max_retries):
res = requests.post(url, auth=auth, json=payload, timeout=10)
if res.status_code == 201:
return res.json()
if res.status_code == 429:
wait = int(res.headers.get("Retry-After", 5))
print(f"429 발생, {wait}초 후 재시도 ({attempt + 1}/{max_retries})")
time.sleep(wait)
continue
res.raise_for_status()
raise RuntimeError("최대 재시도 횟수를 초과했습니다")이 함수를 여러 편의 글을 순회하며 호출할 때는 성공 여부와 상관없이 요청 사이에 1~2초 정도의 고정 지연을 추가로 넣어두면, 애초에 429를 마주치는 빈도 자체가 줄어듭니다. 워드프레스 REST API 핸드북에도 클라이언트가 요청 속도를 스스로 조절하도록 권장하는 문구가 있으니 참고할 만합니다.
이 방식이 안 통하는 경우도 있습니다
애플리케이션 비밀번호 기능은 사이트가 HTTPS로 접속되지 않으면 프로필 화면에 아예 나타나지 않습니다. 로컬 개발 환경처럼 http로만 접속하는 경우엔 wp_is_application_passwords_available 필터를 코드로 직접 걸어 강제로 켜야 하는데, 운영 서버에서는 HTTPS 인증서부터 먼저 적용하는 쪽이 근본적인 해결책입니다.
또한 일부 공유 호스팅이나 카페24 같은 관리형 워드프레스 호스팅은 자동화 트래픽을 봇으로 인식해서 REST API 요청 자체를 차단하기도 합니다. 이런 환경에서는 재시도 로직을 아무리 잘 짜도 계속 403이 반복될 수 있어서, 호스팅사 고객센터에 REST API 화이트리스트 등록을 요청해야 풀리는 경우가 있습니다. 자동 발행 스크립트를 운영 서버에 붙이기 전에 반드시 스테이징 환경이나 테스트 계정으로 요청 빈도를 조금씩 늘려가며 확인해보는 편이 좋습니다.
인증과 재시도 로직만 챙기면 자동 발행 파이프라인은 안정적입니다
워드프레스 REST API로 자동 발행할 때 막히는 지점은 거의 두 군데로 좁혀집니다. 애플리케이션 비밀번호가 HTTPS 환경에서 제대로 발급됐는지, 그리고 429가 왔을 때 Retry-After를 존중하며 재시도하는 로직이 있는지입니다. 두 가지만 코드에 반영해두면 여러 계정에 글을 순차적으로 자동 발행하는 스크립트도 오류 없이 오래 돌릴 수 있습니다.
다음 단계로는 오늘 만든 publish_post 함수에 발행 실패 시 슬랙이나 이메일로 알림을 보내는 부분을 추가해보시길 권합니다. 실패를 조용히 넘기지 않고 바로 확인할 수 있어야 자동화 파이프라인을 안심하고 맡길 수 있습니다.
