워드프레스 관리자 화면을 반복해서 열지 않고 글을 등록하려면 무엇이 필요할까? WordPress REST API를 사용하면 외부 프로그램이 글과 페이지, 카테고리, 태그를 JSON 데이터로 주고받을 수 있다. 제목과 본문을 구조화하고 상태를 draft 또는 future로 지정하면 초안 저장과 예약 발행도 자동화할 수 있다.
이 글은 API의 전체 기능을 나열하기보다 개인 사이트에서 안전하게 글을 등록하는 최소 구조를 설명한다. 예제의 주소, 사용자명과 비밀번호는 반드시 자신의 테스트 환경 값으로 교체해야 한다.
REST API의 기본 주소
워드프레스의 기본 글 엔드포인트는 다음과 같다.
https://example.com/wp-json/wp/v2/posts
인증 없이 GET 요청을 보내면 공개된 글 목록을 읽을 수 있다. 하지만 글 생성과 수정에는 해당 작업 권한이 있는 사용자 인증이 필요하다. 워드프레스는 외부 HTTPS 요청에 애플리케이션 비밀번호를 사용할 수 있다.
일반 비밀번호와 애플리케이션 비밀번호의 차이
애플리케이션 비밀번호는 워드프레스 로그인 화면에서 사용하는 주 비밀번호와 분리된 API용 자격 증명이다. 사용자 프로필에서 용도를 알아볼 수 있는 이름으로 생성하고, 더 이상 사용하지 않으면 해당 비밀번호만 폐기할 수 있다.
- 사이트는 HTTPS를 사용한다.
- 자동화마다 별도의 애플리케이션 비밀번호를 만든다.
- 코드 저장소와 글 본문에 실제 값을 기록하지 않는다.
- 환경변수나 비밀 저장소를 사용한다.
- 마지막 사용 시각과 IP를 정기적으로 확인한다.
초안 글을 만드는 최소 요청
글 생성에는 POST 요청과 JSON 본문을 사용한다. 아래는 구조를 보여주기 위한 예제다.
curl --user "USERNAME:APPLICATION_PASSWORD" -X POST "https://example.com/wp-json/wp/v2/posts" -H "Content-Type: application/json" -d '{
"title": "예약 발행 테스트",
"content": "<p>본문입니다.</p>",
"status": "draft"
}'
status를 draft로 두면 즉시 공개되지 않는다. 자동화 개발의 첫 단계에서는 반드시 초안으로 저장하고 관리자 화면에서 제목, 본문과 작성자를 확인한다.
예약 글을 만드는 핵심 필드
미래 날짜에 공개하려면 status를 future로 지정하고 날짜를 함께 보낸다.
{
"title": "예약 글 제목",
"content": "<p>검토가 끝난 본문</p>",
"status": "future",
"date": "2026-09-08T09:00:00"
}
date는 사이트의 현지 시간 기준이다. UTC 시간을 명시적으로 관리해야 한다면 date_gmt도 함께 검토한다. 가장 흔한 오류는 서버 UTC와 워드프레스 시간대를 섞어 예상과 다른 시각에 발행하는 것이다.
카테고리와 태그는 이름이 아니라 ID
글 생성 요청의 categories와 tags에는 일반적으로 숫자 ID 배열을 전달한다.
{
"categories": [25],
"tags": [103, 104]
}
카테고리 ID는 /wp/v2/categories, 태그 ID는 /wp/v2/tags에서 조회할 수 있다. 이름만 보고 매번 새 태그를 생성하면 ‘AI’, ‘인공지능’, ‘생성형AI’처럼 유사 태그가 불필요하게 늘어난다. 자동화 전에 표준 태그 목록을 정해 두는 편이 좋다.
응답에서 반드시 확인할 값
HTTP 상태 코드가 성공이라고 해서 작업이 완전히 끝난 것은 아니다. 응답 JSON에서 다음 항목을 기록한다.
- id: 워드프레스가 부여한 글 ID
- status: draft, future, publish 중 실제 저장 상태
- date와 date_gmt: 예약 시각
- link: 공개 후 사용할 주소
- author·categories·tags: 지정한 분류가 적용됐는지 여부
오류 응답도 함께 저장해야 한다. 401은 인증, 403은 권한, 400은 잘못된 필드나 날짜 형식을 우선 점검한다.
안전한 자동화는 두 단계로 나눈다
1단계: 생성
AI가 만든 제목과 본문을 draft로 등록한다. 이 단계에서는 공개 권한을 사용하지 않아도 되는 구조가 가장 안전하다.
2단계: 승인과 예약
사람이 출처, 내부 링크, 카테고리, 개인정보를 확인한 뒤 future로 변경한다. 완전 자동 공개가 필요하더라도 최소한 검증 규칙과 실패 시 중단 조건을 둔다.
중복 글을 막는 방법
네트워크가 끊기면 프로그램이 같은 요청을 다시 보내 중복 글을 만들 수 있다. 요청 전에 기존 글의 슬러그나 외부 시스템의 고유 ID를 확인하고, 생성 결과의 글 ID를 저장한다. 실패했는지 알 수 없다고 무조건 POST를 반복하지 않는다.
- 제목이 아니라 고유한 작업 ID를 기록한다.
- 생성 성공 후 반환된 글 ID를 로컬 기록에 저장한다.
- 재시도 전에 해당 ID 또는 슬러그가 존재하는지 조회한다.
- 동일 작업의 최대 재시도 횟수를 제한한다.
운영 전 테스트 순서
- 별도의 테스트 글을
draft로 생성한다. - 한글, 링크, 목록과 코드 블록이 깨지지 않는지 확인한다.
- 10분 뒤의 시간을 지정해
future테스트를 한다. - 작성자, 카테고리, 태그와 공개 URL을 확인한다.
- 잘못된 인증과 중복 요청이 로그에 남는지 확인한다.
- 애플리케이션 비밀번호 폐기 절차를 시험한다.
정리
- WordPress REST API는 JSON을 사용해 글과 분류를 생성·수정할 수 있다.
- 외부 자동화는 주 비밀번호보다 애플리케이션 비밀번호를 사용한다.
- 처음에는 draft로 등록하고 검토 후 future로 변경하는 흐름이 안전하다.
- 예약 시간대, 분류 ID, 응답 로그와 중복 방지를 함께 설계해야 한다.
다음 글에서는 자동화 계정의 권한, 비밀정보 보관, 검토와 감사 기록을 포함한 운영 보안을 다룬다.
참고자료
- WordPress REST API Handbook
- WordPress REST API Posts Endpoint
- WordPress REST API Authentication
- WordPress Application Passwords