이 글에서 정리하는 내용
ChatGPT와 Codex를 워드프레스 블로그 자동화에 연결할 때는 글 작성, 검증, 이미지 업로드, 글 생성 단계를 한 번에 묶기보다 각 산출물을 분리해야 안정적으로 운영할 수 있습니다. 이 글은 AI로 블로그 글을 무작정 발행하는 방법이 아니라, draft 상태로 먼저 생성하고 사람이 최종 확인할 수 있는 워드프레스 자동 업로드 파이프라인을 만드는 기준을 정리합니다.
- 자동화하려는 범위를 먼저 나누기
- ChatGPT가 맡기 좋은 단계
- Codex가 맡기 좋은 단계
- 워드프레스에 들어가는 데이터 구조
- 자동 업로드 파이프라인 예시
- 자동화할 때 조심할 부분
- 정리
자동화하려는 범위를 먼저 나누기

워드프레스 블로그 자동화라고 하면 처음에는 글 작성부터 발행까지 한 번에 끝내는 흐름을 떠올리기 쉽습니다. 주제를 입력하면 ChatGPT가 글을 쓰고, Codex가 업로드 코드를 고쳐서 워드프레스에 바로 올려주는 식입니다. 겉으로는 가장 빠른 방식처럼 보이지만 실제 운영에서는 이 구조가 오히려 불안정해질 수 있습니다.
글 하나에는 제목만 들어가지 않습니다. slug, 카테고리, 태그, 요약문, SEO 제목, SEO 설명, 대표 이미지 alt, 본문 이미지 alt, 본문 HTML, 발행 상태까지 함께 맞아야 합니다. 자동화가 이 값을 따로따로 만들면 글은 올라가도 수정할 부분이 계속 남습니다. 이미지 URL이 비어 있거나, 카테고리 slug가 틀리거나, 본문 이미지 순서와 JSON의 이미지 배열 순서가 어긋나는 일이 생기기 쉽습니다.
그래서 자동화 범위는 먼저 둘로 나눠야 합니다. 하나는 글 작성 자동화이고, 다른 하나는 워드프레스 업로드 자동화입니다. 글 작성 자동화는 사람이 읽을 본문과 메타데이터를 만드는 단계입니다. 업로드 자동화는 이미 정리된 데이터를 워드프레스가 이해할 수 있는 형식으로 넣는 단계입니다.
두 단계를 분리하면 문제가 생겼을 때 확인 지점도 분명해집니다. 본문 문장이 어색하면 ChatGPT 작성 단계에서 고치면 되고, JSON 파싱 오류가 나면 업로드 데이터 단계에서 확인하면 됩니다. 이미지가 본문에 보이지 않으면 미디어 업로드나 placeholder 치환 로직을 보면 됩니다. 모든 과정을 한 덩어리로 묶는 것보다, 실패 지점이 보이는 구조가 운영에는 더 맞습니다.
특히 기술 블로그라면 자동 발행보다 draft 생성 흐름을 먼저 잡는 쪽이 안정적입니다. AI가 만든 글은 문장보다 사실 관계와 코드 흐름에서 문제가 생길 수 있습니다. 워드프레스에 draft로 글을 만든 뒤 관리자 화면에서 본문, 이미지, 코드 블록, 링크를 확인하고 publish로 바꾸는 흐름이 검수 기준을 남깁니다.
ChatGPT가 맡기 좋은 단계
ChatGPT는 파이프라인 안에서 글의 재료를 정리하는 역할에 잘 맞습니다. 주제 하나를 입력받아 기획, 본문, 메타데이터, 이미지 명령어, 업로드용 JSON처럼 단계별 산출물로 나누면 이후 자동화 코드가 다루기 쉬워집니다.
가장 먼저 만들 산출물은 기획입니다. 글 유형, 핵심 관점, 예상 독자, 목차, 다룰 범위를 먼저 정리해두면 본문 작성이 흔들리지 않습니다. 워드프레스 자동화 글이라면 단순히 “ChatGPT 사용법”을 설명하는 글이 아니라, 글 작성과 업로드를 분리해 검증 가능한 구조로 만드는 글이라는 관점을 먼저 잡아야 합니다.
그다음은 HTML 본문입니다. 워드프레스에 넣을 수 있는 본문 HTML을 만들되, 이미지 슬롯은 업로드 단계와 연결될 수 있게 비워둡니다. 이미지를 아직 업로드하지 않았다면 본문 안에는 빈 이미지 블록을 두고, 나중에 JSON 변환 단계에서 `__BODY_IMAGE_1_URL__` 같은 placeholder로 바꾸는 식입니다.
메타데이터도 별도 단계로 분리합니다. 제목, slug, description, tags, keywords, focus keyword, 이미지 alt를 본문과 따로 정리하면 워드프레스 입력값과 SEO 플러그인 입력값을 안정적으로 맞출 수 있습니다. 본문을 먼저 쓰고 마지막에 메타데이터를 정리하면, 글의 실제 내용과 검색 키워드가 어긋날 가능성도 줄어듭니다.
blogflow.kr처럼 글을 단계별로 생성해 워드프레스에 올리는 구조라면 이 분리가 더 중요해집니다. 2단계 HTML 본문을 수정했는데 5단계 JSON까지 매번 새로 작성하면 작은 수정도 큰 작업이 됩니다. 반대로 본문, 메타데이터, 이미지 정보가 각각 독립된 산출물로 남아 있으면 마지막 변환 단계에서 필요한 값만 다시 조합할 수 있습니다.
단계별 산출물로 나누는 예시
{
"step1": "글 기획",
"step2": "워드프레스 본문 HTML",
"step3": "본문 디테일 보강",
"step4": "SEO 및 워드프레스 메타데이터",
"step5": "업로드용 JSON",
"step6": "이미지 생성 명령어"
}
이 구조의 장점은 각 단계의 결과물이 서로 이어지지만, 같은 결과물을 반복해서 만들지 않는다는 점입니다. 2단계에서 본문 HTML을 만들고, 4단계에서 메타데이터를 만든 뒤, 5단계에서는 둘을 합쳐 업로드용 JSON으로 변환합니다. 이렇게 나누면 5단계 JSON 오류가 났을 때 본문 전체를 다시 쓰지 않아도 됩니다.
ChatGPT를 글 작성 도구로만 쓰면 매번 결과가 조금씩 달라집니다. 반대로 산출물 형식을 고정해두면 자동화 파이프라인의 입력값으로 사용할 수 있습니다. 글을 잘 쓰는 것과, 워드프레스가 처리할 수 있는 데이터로 만드는 것은 다른 문제입니다.
Codex가 맡기 좋은 단계
Codex는 글 자체를 판단하는 역할보다 코드와 파일 흐름을 점검하는 역할에 놓는 것이 자연스럽습니다. 워드프레스 자동 업로드 파이프라인에서는 JSON 스키마 검증, 업로드 스크립트 수정, 이미지 업로드 로직 점검, 에러 로그 분석 같은 작업이 Codex와 잘 맞습니다.
예를 들어 업로드용 JSON을 만들었는데 워드프레스 플러그인에서 “JSON 형식이 올바르지 않습니다”라는 오류가 난다면, 원인은 대부분 본문 HTML 안의 큰따옴표 escape, 줄바꿈 처리, trailing comma, 이미지 placeholder 불일치 같은 부분에 있습니다. 사람이 눈으로 찾기에는 피곤하지만, Codex에게 스키마와 샘플 데이터를 같이 주고 검증 로직을 보게 하면 빠르게 좁힐 수 있습니다.
이미지 업로드도 마찬가지입니다. 대표 이미지를 올린 뒤 `featuredImage.url`만 바뀌고 본문 HTML의 이미지 슬롯은 그대로 남아 있으면 글에는 이미지가 보이지 않습니다. 본문 이미지 1을 업로드했을 때 `bodyImages[0].url`, `bodyImages[0].id`, HTML의 첫 번째 이미지 슬롯이 함께 바뀌는지 확인해야 합니다. 이런 연동 로직은 글쓰기보다 코드 검증에 가깝기 때문에 Codex가 다루기 좋은 영역입니다.
Codex에게 작업을 맡길 때는 목표와 완료 기준을 같이 줘야 합니다. “업로드 플러그인 고쳐줘”보다 “대표 이미지 업로드 후 featuredImage.id와 featuredImage.url이 바뀌고, 본문 이미지 업로드 후 bodyImages 배열과 HTML placeholder가 같은 순서로 치환되게 해줘. 완료 기준은 JSON.parse 통과와 draft 글 생성 성공이야”처럼 쓰는 쪽이 결과를 검토하기 쉽습니다.
또 하나 중요한 부분은 실패했을 때 되돌릴 수 있는 구조입니다. 자동 업로드 스크립트가 글을 바로 publish로 만들면 잘못된 글이 공개될 수 있습니다. Codex에게 업로드 로직을 맡길 때도 기본 상태는 draft로 두고, 실패 로그와 생성된 글 ID를 남기도록 구성해야 운영 중 원인을 추적할 수 있습니다.
Codex에게 맡길 작업을 구분하는 기준
| 작업 | 맡기기 좋은 도구 | 확인할 기준 |
|---|---|---|
| 글 주제 기획 | ChatGPT | 독자, 검색 의도, 글의 관점 |
| 본문 HTML 작성 | ChatGPT | 문장 흐름, 코드 블록, 이미지 슬롯 |
| JSON 스키마 검증 | Codex | 필수 필드, escape, placeholder |
| 워드프레스 업로드 로직 | Codex | 인증, posts, media, draft 생성 |
| 최종 발행 판단 | 사람 | 사실 관계, 화면 표시, 내부 링크 |
표에서 중요한 것은 역할의 우열이 아니라 경계입니다. ChatGPT가 만든 글을 Codex가 그대로 업로드하는 흐름보다, ChatGPT는 구조화된 입력값을 만들고 Codex는 그 입력값을 안전하게 처리하는 코드 쪽을 보는 흐름이 더 관리하기 쉽습니다.
워드프레스에 들어가는 데이터 구조
워드프레스 자동 업로드의 중심에는 결국 데이터 구조가 있습니다. REST API를 직접 쓰든, 별도 플러그인을 만들든, 워드프레스에 전달할 값은 정해져 있습니다. 제목, 본문, 상태, slug, 카테고리, 태그, 대표 이미지, 본문 이미지가 서로 맞아야 합니다.
REST API 기준으로 글은 posts 엔드포인트를 통해 생성할 수 있고, 이미지는 media 엔드포인트를 통해 업로드할 수 있습니다. 다만 실제 운영에서는 REST API를 직접 호출하는 방식과 관리자 화면에서 JSON을 넣고 처리하는 플러그인 방식 중 하나를 선택하게 됩니다. 둘 중 어느 쪽을 쓰더라도 데이터 구조를 먼저 안정화해야 합니다.
예를 들어 블로그 자동 업로드용 JSON은 아래처럼 구성할 수 있습니다. 실제 운영에서는 HTML 문자열이 더 길어지고, 이미지 URL은 업로드 전에는 placeholder로 둡니다.
{
"title": "ChatGPT와 Codex로 워드프레스 블로그 자동 업로드 파이프라인 만들기",
"slug": "chatgpt-codex-wordpress-auto-upload-pipeline",
"description": "ChatGPT와 Codex를 활용해 워드프레스 블로그 글 작성부터 업로드까지 연결하는 자동화 흐름을 정리합니다.",
"category": "coding",
"categoryLabel": "자동화 업무",
"tags": ["워드프레스 자동화", "ChatGPT", "Codex"],
"status": "draft",
"featuredImage": {
"id": 0,
"url": "__FEATURED_IMAGE_URL__",
"alt": "ChatGPT와 Codex를 활용한 워드프레스 자동 업로드 파이프라인"
},
"bodyImages": [
{
"id": 0,
"placeholder": "__BODY_IMAGE_1_URL__",
"url": "__BODY_IMAGE_1_URL__",
"alt": "블로그 글 작성과 워드프레스 업로드 단계를 분리한 자동화 구조"
}
],
"html": "<div class="auto-wrapper">...</div>"
}
여기서 자주 틀리는 부분은 `category`입니다. 사람이 읽는 이름인 “자동화 업무”를 넣는 것이 아니라, 워드프레스에 등록된 slug인 `coding` 같은 값을 넣어야 합니다. 반대로 관리자 화면이나 점검용 표시에는 `categoryLabel`처럼 사람이 읽는 이름이 필요할 수 있습니다.
이미지 쪽도 구분해야 합니다. 대표 이미지는 워드프레스 글의 썸네일 후보이고, 본문 이미지는 HTML 안에서 특정 위치에 들어갑니다. 대표 이미지를 업로드했다고 해서 본문 이미지가 자동으로 채워지는 것은 아닙니다. 본문 안의 이미지 슬롯과 JSON의 `bodyImages` 배열이 같은 순서를 바라보도록 맞춰야 합니다.
워드프레스 REST API만 기준으로 보면 카테고리와 태그는 slug가 아니라 ID로 전달해야 하는 경우가 많습니다. 그래서 내부 업로드 도구가 slug를 입력받는다면, 업로드 직전에 해당 slug를 실제 term ID로 바꾸는 과정이 필요합니다. 이 변환이 빠지면 JSON에는 맞는 값이 있어 보여도 워드프레스 글에는 기본 카테고리가 붙을 수 있습니다.
자동 업로드 파이프라인 예시
실제 파이프라인은 복잡하게 시작할 필요가 없습니다. 처음부터 완전 자동 발행을 만들기보다, 한 편의 글을 draft로 안정적으로 생성하는 흐름을 먼저 잡아야 합니다. 그다음 이미지 자동 반영, 내부 링크 후보 점검, 예약 발행 같은 기능을 붙이면 됩니다.
기본 흐름은 아래처럼 볼 수 있습니다. 사용자가 주제와 키워드를 입력하면 ChatGPT가 단계별 결과물을 만들고, 5단계 JSON이 업로드 도구의 입력값이 됩니다. 업로드 도구는 이미지를 먼저 올리고, 업로드 결과로 받은 attachment ID와 URL을 JSON과 HTML에 반영한 뒤 글을 draft로 생성합니다.
주제 입력
→ 1단계 기획
→ 2단계 HTML 본문
→ 4단계 메타데이터
→ 5단계 업로드 JSON
→ 이미지 파일 선택
→ 워드프레스 미디어 업로드
→ JSON과 HTML 이미지 슬롯 자동 치환
→ draft 글 생성
→ 관리자 화면에서 최종 확인
→ publish 전환
이 흐름에서 Codex는 중간중간 코드 검증자로 들어갑니다. 예를 들어 이미지 업로드 후 본문 첫 번째 이미지 슬롯이 여전히 빈 문자열이면, Codex에게 플러그인 코드에서 placeholder 치환 순서와 `bodyImages` 배열 처리 부분을 확인하게 할 수 있습니다. 글 생성 요청이 401 또는 403으로 실패한다면 인증 헤더, 애플리케이션 비밀번호, 사용자 권한, HTTPS 요청 여부를 먼저 보게 합니다.
REST API를 직접 호출하는 방식이라면 요청 흐름은 대략 아래처럼 나뉩니다. 실제 코드에서는 인증 정보와 사이트 주소를 환경변수로 빼고, 실패 응답을 반드시 로그로 남겨야 합니다.
async function createDraftPost(postData) {
const response = await fetch(`${process.env.WP_URL}/wp-json/wp/v2/posts`, {
method: 'POST',
headers: {
'Content-Type': 'application/json',
Authorization: `Basic ${process.env.WP_AUTH_TOKEN}`
},
body: JSON.stringify({
title: postData.title,
slug: postData.slug,
content: postData.html,
status: 'draft'
})
});
if (!response.ok) {
const errorBody = await response.text();
throw new Error(`WordPress draft 생성 실패: ${response.status} ${errorBody}`);
}
return response.json();
}
이 예시는 전체 업로드 스크립트가 아니라 글 생성 요청의 뼈대입니다. 실제 자동화에서는 카테고리 ID 변환, 태그 생성 또는 조회, 대표 이미지 ID 연결, 본문 이미지 URL 치환이 추가됩니다. 처음부터 모든 기능을 한 번에 넣기보다 draft 생성이 먼저 성공하는지 확인하고, 그다음 미디어 업로드를 붙이는 순서가 안정적입니다.
플러그인 방식이라면 흐름은 조금 다릅니다. 관리자 화면에 JSON textarea와 이미지 파일 입력을 두고, 파일을 선택하는 순간 AJAX로 미디어 라이브러리에 업로드합니다. 업로드가 성공하면 JSON 안의 `featuredImage.id`, `featuredImage.url`, `bodyImages[].id`, `bodyImages[].url`을 실제 값으로 바꾸고, 본문 HTML의 placeholder도 같은 URL로 치환합니다. 마지막 글 생성 버튼은 이미 정리된 JSON을 기준으로 draft 글을 만드는 역할만 맡습니다.
자동화할 때 조심할 부분

워드프레스 자동 업로드에서 가장 먼저 조심할 부분은 인증 정보입니다. 워드프레스 관리자 비밀번호를 코드나 JSON 안에 직접 넣으면 안 됩니다. 외부 스크립트나 자동화 도구에서 접근해야 한다면 애플리케이션 비밀번호처럼 용도를 분리할 수 있는 인증 방식을 쓰고, 실제 값은 환경변수로 관리해야 합니다.
두 번째는 이미지 URL 추정입니다. 워드프레스 미디어 라이브러리는 업로드 월, 리사이즈 파일명, 중복 파일명 처리 방식에 따라 실제 URL이 달라질 수 있습니다. 파일명을 보고 `https://example.com/wp-content/uploads/…` 같은 URL을 임의로 만드는 방식은 피해야 합니다. 이미지는 업로드 응답으로 받은 실제 URL과 attachment ID를 기준으로 반영해야 합니다.
세 번째는 JSON 유효성입니다. 본문 HTML을 JSON 문자열 안에 넣으면 큰따옴표, 줄바꿈, 백슬래시 때문에 오류가 자주 생깁니다. 특히 Gutenberg 이미지 블록 주석이나 코드 블록 안의 문자열이 섞이면 눈으로 봐서는 문제를 찾기 어렵습니다. 업로드 전에 `JSON.parse`가 통과하는지 확인하는 단계를 넣어두면 불필요한 실패를 줄일 수 있습니다.
네 번째는 카테고리와 태그입니다. 워드프레스 REST API에서는 카테고리와 태그가 이름이 아니라 ID로 연결되는 경우가 많습니다. 내부 플러그인을 쓴다면 slug를 받아서 ID로 변환하는 로직이 필요할 수 있습니다. 이 변환이 빠지면 글은 생성되지만 엉뚱한 카테고리에 들어가거나 기본 카테고리로 남을 수 있습니다.
다섯 번째는 글 품질 검수입니다. 자동화 파이프라인이 완성되면 글을 만드는 속도는 빨라집니다. 하지만 속도가 빨라질수록 잘못된 설명, 오래된 기술 기준, 비슷한 문장 반복, 부정확한 코드 예시가 쌓일 가능성도 커집니다. 그래서 마지막 단계에는 사람이 봐야 할 체크리스트를 남겨야 합니다.
여섯 번째는 로그에 남는 민감정보입니다. 업로드 실패 로그를 자세히 남기는 것은 필요하지만, Authorization 헤더, 애플리케이션 비밀번호, API 키, 토큰이 그대로 찍히면 다른 문제가 됩니다. 실패 원인을 남기되 인증값은 마스킹하고, 운영 설정 파일은 공유 대상에서 제외하는 기준을 세워야 합니다.
발행 전 확인할 체크리스트
- 글 상태가 draft인지 확인
- 제목과 slug가 주제와 맞는지 확인
- 본문 이미지가 실제로 표시되는지 확인
- 대표 이미지와 본문 이미지 alt가 비어 있지 않은지 확인
- 코드 블록이 깨지지 않았는지 확인
- 카테고리와 태그가 의도대로 들어갔는지 확인
- 내부 링크가 있다면 publish 글만 연결됐는지 확인
- 민감정보가 본문이나 JSON에 남아 있지 않은지 확인
- 실패 로그에 인증값이 그대로 남지 않았는지 확인
이 체크리스트는 자동화를 느리게 만들기 위한 장치가 아닙니다. 확인할 항목이 고정되어 있어야 자동화 범위를 넓힐 수 있습니다. 매번 감으로 확인하면 빠뜨리는 부분이 생기지만, 체크 항목을 기준으로 보면 어떤 작업을 다음 자동화 대상으로 넘길 수 있는지 판단하기 쉽습니다.
정리
ChatGPT와 Codex를 워드프레스 블로그 자동화에 연결할 때 핵심은 “누가 글을 쓰느냐”보다 “어떤 결과물을 어떤 순서로 넘기느냐”입니다. ChatGPT는 기획, 본문, 메타데이터, 이미지 설명, 업로드용 JSON처럼 글의 재료를 구조화하는 데 잘 맞습니다. Codex는 그 결과물을 받아 업로드 코드, JSON 검증, 이미지 치환, 실패 로그 같은 개발 작업을 점검하는 데 더 어울립니다.
워드프레스 쪽에서는 posts, media, 인증, 카테고리, 태그, 이미지 ID 연결을 각각 분리해서 봐야 합니다. 모든 것을 한 번에 자동 발행하려고 하면 실패 지점이 흐려집니다. 먼저 draft 글을 안정적으로 만드는 흐름을 만들고, 그다음 이미지 업로드와 메타데이터 반영을 붙이는 순서가 관리하기 쉽습니다.
자동화의 목표는 발행 버튼을 없애는 것이 아닙니다. 반복 입력을 줄이고, 사람이 확인해야 할 지점을 명확하게 만드는 것입니다. 블로그 글 수가 늘어날수록 이 차이는 커집니다. 글쓰기 시간을 줄이려면 AI에게 모든 판단을 맡기기보다, 사람이 검수할 수 있는 파이프라인을 먼저 설계하는 쪽이 오래 갑니다.
참고 자료
WordPress REST API Handbook의 Posts, Media, Authentication 문서와 OpenAI Codex 공식 문서를 기준으로 자동 업로드 흐름과 도구 역할을 확인했습니다.