AI 블로그 자동화, 어디까지 맡기면 좋을까?
AI 블로그 자동화는 자료 정리·초안 작성·이미지 준비·워드프레스 초안 저장처럼 반복되는 작업부터 맡기는 것이 좋습니다. 사실 판단과 공개 여부는 별도 검토 단계로 두고, 저장 결과를 확인한 뒤 발행이나 예약으로 넘어가세요. 자동화의 범위는 생성량보다 오류를 발견하고 되돌릴 수 있는 구조를 기준으로 정하는 편이 실용적입니다.
자동화할 작업과 판단할 작업 나누기
자동화는 여러 작업을 정해 둔 순서와 조건으로 실행하는 것입니다. AI가 원고를 만드는 기능과 워드프레스에 저장하는 기능은 별개이며, 연결했다고 사실 검수까지 끝나는 것은 아닙니다. 각 단계의 입력·결과·중단 조건부터 정해야 합니다.
| 작업 | 자동화할 수 있는 부분 | 확인할 부분 |
|---|---|---|
| 기획·자료 정리 | 후보 분류, 주장·출처 목록 생성 | 중복 주제와 실제 출처 적합성 |
| 원고 | 목차·초안·서식 변환 | 사실, 누락된 조건과 설명의 충분함 |
| 이미지 | 생성, 크기 변환, 업로드 | 문자·로고·오류·오인 가능성 |
| 저장 | 본문·요약문·분류·대표 이미지 설정 | 대상 사이트와 실제 저장 값 |
| 공개 | 검토를 마친 글의 발행·예약 처리 | 최종 공개 범위, 날짜와 화면 |
예를 들어 제목과 본문은 완성됐지만 대표 이미지가 다른 글에 연결됐다면 게시 준비가 끝난 것이 아닙니다. 단계별 완료 기준을 두면 일부 성공을 전체 성공으로 잘못 보고하는 일을 줄일 수 있습니다.
처음에는 초안 저장까지 연결하기
처음 구성할 때는 입력 자료 → 원고 생성 → 형식 검사 → 초안 저장 → 검토 순서로 시작해 보세요. 한 글로 전체 흐름을 확인한 뒤 대상 수를 늘리는 편이 오류 원인을 찾기 쉽습니다. 생성이 잘된다는 이유만으로 곧바로 무인 발행까지 확대할 필요는 없습니다.
저장 전에는 필수 항목을 검사합니다. 제목과 요약문이 있는지, 본문 제목 단계가 맞는지, 링크가 존재하는지, 카테고리가 실제 사이트 항목인지 확인하세요. 형식 검사는 자동화할 수 있지만 글의 유용성과 사실관계는 별도 검토가 필요합니다.
이미지는 업로드 성공과 글 연결을 나누어 확인해야 합니다. 미디어 라이브러리에 들어갔어도 대표 이미지로 선택되지 않았을 수 있습니다. 여러 글을 처리한다면 원고별 글 ID·미디어 ID·단계 상태를 기록하여 서로 바뀌지 않도록 합니다.
워드프레스 API를 사용할 때 알아둘 구조
API(Application Programming Interface)는 프로그램이 다른 서비스의 기능을 정해진 요청으로 사용하는 통로입니다. 워드프레스 REST API에서는 글을 생성·조회·수정할 수 있습니다. 공식 글 API 문서는 본문·요약문·카테고리·대표 이미지와 글 상태 필드를 설명합니다.
아래는 인증 연결을 준비한 자동화에서 POST /wp-json/wp/v2/posts로 보낼 수 있는 요청 본문의 예시입니다. 실행 스크립트가 아니며, 글을 공개하지 않고 초안으로 생성하는 구조를 보여 줍니다.
{
"title": "검토할 블로그 글 제목",
"content": "<p>검토할 본문입니다.</p>",
"excerpt": "글에서 다루는 내용과 독자가 얻을 정보를 요약합니다.",
"status": "draft"
}
카테고리와 대표 이미지를 추가하려면 실제 사이트에서 조회한 ID를 사용해야 합니다. 미디어 API의 post는 첨부 관계를, 글의 featured_media는 대표 이미지 선택을 나타내므로 같은 작업으로 취급하지 않습니다. 공식 미디어 API 문서에서 각 필드를 확인할 수 있습니다.
새 글 생성 응답에서 받은 ID는 즉시 보관하세요. 응답을 받지 못했을 때 같은 생성 요청을 무조건 반복하면 중복 글이 생길 수 있습니다. 먼저 작업 기록과 실제 사이트에서 생성 여부를 확인하고 재시도 여부를 판단하는 구조가 필요합니다.
인증 정보와 기존 편집을 보호하기
연결 계정에는 필요한 권한을 부여하고, 비밀번호나 토큰은 공개 원고·프롬프트·로그에 넣지 않습니다. 워드프레스는 HTTPS 요청에서 애플리케이션 비밀번호를 사용하는 인증 방식을 지원합니다. 지원 조건과 연결 방식은 REST API 인증 문서에서 확인하세요.
기존 글을 수정할 때는 처음 읽은 내용과 실제 저장 직전의 내용을 비교해야 합니다. 작업 중 운영자가 편집했다면 예전 원고를 통째로 덮어쓰지 말고 최신 내용을 기준으로 변경안을 다시 적용하세요. 본문만 바꾸는 요청이라면 상태·게시일·슬러그까지 함께 보내지 않는 편이 안전합니다.
공개 글을 바꾸기 전에는 복원할 본문과 주요 설정을 보관합니다. 실패했을 때 어느 글의 어느 값을 복원할지 알 수 있어야 합니다. 자동화 스크립트가 로그를 남기더라도 인증 헤더와 비밀 값까지 기록하지 않는지 확인하세요.
예약 발행은 시간대와 실제 상태까지 확인하기
검토를 마친 글을 예약할 때는 사이트 시간대와 입력 시각을 맞춰야 합니다. 워드프레스 API의 현지 게시 시각과 GMT 시각이 같은 순간을 나타내는지 비교하세요. ‘예약 요청을 보냈다’와 ‘미래 시각으로 저장됐다’는 별도로 확인합니다.
예를 들어 한국 시간 기준으로 간격을 정했다면 첫 게시 시각과 각 글의 순서를 기록한 뒤, 저장 결과가 의도한 간격인지 계산할 수 있습니다. 초안 날짜를 그대로 둔 채 상태만 바꾸거나, 실행 컴퓨터의 시간대를 사이트 시간대로 가정하지 않도록 합니다.
워드프레스 기본 예약 작업에는 WP-Cron이 관여합니다. 공식 문서는 페이지 요청을 계기로 예약 작업을 확인하므로 방문이 없을 때 실행이 늦어질 수 있다고 설명합니다. 정확한 시각 운영이 중요하면 호스팅의 예약 작업 구성도 별도로 확인해야 합니다. WP-Cron 설명을 참고하세요.
예약 저장 후 상태가 future라면 ‘예약 완료’로 기록합니다. 예약 시각이 지난 뒤 다시 조회해 publish인지 확인하고, 로그아웃 상태에서도 공개 주소가 열리는지 확인해야 ‘발행 완료’로 처리할 수 있습니다.
오류가 나면 해당 단계에서 멈추고 재개하기
여러 글을 한꺼번에 처리할 때는 글마다 상태를 나누어 관리합니다. 한 글의 이미지 업로드가 실패했다고 나머지 글의 상태까지 성공으로 표시하지 말고, ‘원고 완료·초안 저장 완료·이미지 연결 대기’처럼 실제 결과를 남기세요.
- 원고 검수 실패: 저장·발행으로 넘어가지 않고 수정할 항목을 남깁니다.
- 업로드 실패: 이미 생성한 글과 미디어가 있는지 확인한 뒤 재시도합니다.
- 편집 충돌: 최신 원고를 다시 읽고 변경안을 조정합니다.
- 공개 오류: 대상 글과 원인을 확인하고 보관한 값으로 필요한 부분을 복원합니다.
예를 들어 글 ID가 5010, 새로 업로드한 미디어 ID가 7020인 가상의 작업에서 대표 이미지 설정만 실패했다고 해 보겠습니다. 다음 순서로 확인하면 이미 성공한 생성을 반복하지 않고 해당 단계부터 재개할 수 있습니다. 아래 ID는 예시이며 실제 사이트에서는 저장 응답으로 받은 값을 사용해야 합니다.
GET /wp-json/wp/v2/posts/5010으로 글을 다시 조회하고 제목·본문·요약문·분류·상태가 작업 기록과 같은지 비교합니다. 다른 편집이 확인되면 변경부터 중단합니다.GET /wp-json/wp/v2/media/7020으로 해당 파일이 실제로 있는지와 첨부 대상인post값을 확인합니다.- 글과 미디어가 확인되고 원래 연결 의도가 유지된다면 빠진 대표 이미지 설정만 재시도합니다. 해당 글 전용으로 새로 올린 미디어의 첨부 관계가 빠졌다면 그것도 별도로 보완하되, 기존 공용 미디어의 첨부 대상을 임의로 바꾸지는 않습니다.
- 다시 조회해 글의
featured_media와 해당 새 미디어의post가 각각 의도한 ID인지 확인한 뒤 완료로 기록합니다. 글이나 이미지를 새로 만드는 요청부터 반복하지 않습니다.
작업이 끝나면 저장된 본문·요약문·분류·이미지를 다시 조회하고, 공개했다면 최종 URL과 모바일 화면도 확인합니다. 자동화를 평가할 때는 작성 속도뿐 아니라 재작업 시간, 중복 발생과 복원 가능성을 함께 보세요. 필요한 검토를 유지하면서 반복 작업을 줄이는 구조가 오래 관리하기 좋습니다.




