오늘의 결론
- 완전 자동 “발행”보다 드래프트 업로드 + 마지막 검수가 운영 안정성이 훨씬 높습니다.
- 핵심은 WordPress 인증을 Application Password로 단단히 고정하는 겁니다.
- 자동화는 “성공”보다 실패 알림/재시도/로그가 제대로 있어야 오래 갑니다.
내가 이 구조로 바꾸게 된 이유
처음에는 “자동 발행”을 목표로 잡았습니다.
그런데 며칠 돌려보니 문제는 발행 자체가 아니라 품질과 리스크였어요.
- 문장 한 줄이 어색해도 그대로 공개됨
- 태그가 쓸데없이 늘어남
- 링크/표현 문제가 생겨도 바로 노출됨
그래서 결론은 단순했습니다.
매일 자동으로 초안만 올려두고, 알림 받고 “최종 검수 후 발행”
이게 현실적으로 제일 덜 고장나고, 운영이 편했습니다.
내 환경
- n8n: Docker 운영
- WordPress: Docker 운영 (REST API 사용)
- 인증: Application Password (우선 추천)
- 목표: 매일 09:00 “드래프트 1건 생성”
- 알림: Slack/메일/시놀로지 챗 중 1개
- 로그 저장: Google Sheets 또는 DB(선택)
전체 아키텍처 한 장 요약
Cron(매일 09:00)
→ 주제 선택(Topic Picker)
→ (옵션) 자료 포인트만 수집
→ 본문 생성/정리(템플릿 or AI)
→ WP REST API로 draft 생성
→ 성공/실패 알림
→ 로그 저장(제목/URL/상태/에러)
운영 팁:
처음부터 “모든 걸 자동으로” 하려면 중간에 반드시 깨집니다.
저는 Topic Picker부터 고정 리스트로 시작해서 성공률을 먼저 올렸습니다.
준비물 체크리스트
- WordPress 계정(편집자 이상) + 미디어/글 권한 확인
- Application Password 생성(추천) 또는 JWT 세팅
- n8n에서 HTTP Request 노드 사용 가능
- 카테고리 ID 확정(고정 추천)
- 알림 채널 1개 이상
- 로그 저장 위치(시트/DB/파일 중 택1)
인증 방식 2가지 (내 결론은 A안)
A안) Application Password (추천)
- WordPress 사용자 프로필에서 “애플리케이션 비밀번호” 생성
- n8n에서 Basic Auth처럼
username + app_password로 호출
장점
- 설정이 단순하고 운영 안정적
- 서버 설정 변경이 거의 없음
주의
- 계정 권한을 최소화(가능하면 전용 계정)
- 앱 비번은 주기적으로 교체
B안) JWT Auth
- Bearer Token 방식이라 자동화에 익숙하면 편합니다.
단점
- 플러그인 + 서버 설정이 필요한 경우가 있어 초기 삽질이 늘어납니다.
초반엔 A안으로 성공 루틴 만들고,
필요하면 B안으로 넘어가는 게 덜 스트레스였습니다.
n8n 워크플로우 설계 (디버깅이 쉬운 순서)
노드 1) Cron
- 매일 09:00 실행
노드 2) Set / Topic Picker
- 방식 1: 고정 리스트에서 랜덤 선택
- 방식 2: 스프레드시트/DB에서 “미작성” 주제 1개 가져오기
운영 팁
- 초반에는 고정 리스트가 무조건 좋습니다.
- DB 연동은 성공률이 안정화된 뒤에 붙이세요.
노드 3) (옵션) 자료 수집
- RSS/메모/내부 문서에서 “포인트만” 가져오기
- 원문 복붙 금지(저작권/품질 이슈)
노드 4) 본문 생성
- A) 템플릿 기반: 품질 일정, 운영 안정
- B) AI 기반: 생산성 높음, 검수 필수
howinfo 자동화 글 톤이면
A로 먼저 안정화 → B로 고도화가 제일 덜 고장납니다.
노드 5) Function (정리/필터)
여기서 하는 일:
- H2/H3 구조 정리
- 과장 표현 제거(무조건/완벽/최고 등)
- 중복 문장 제거
- 너무 긴 문장 쪼개기
노드 6) HTTP Request (Posts Create)
POST /wp-json/wp/v2/postsstatus: draft고정- title/content/categories/tags 매핑
노드 7) IF (성공/실패)
- 성공: 알림 + 로그
- 실패: 재시도(1회) + 실패 알림 + 로그
노드 8) 알림(Slack/메일/시놀로지 챗)
성공 알림엔 꼭:
- 제목
- 드래프트 링크
- 실행 시간
실패 알림엔 꼭:
- 실패 단계
- HTTP 코드
- 응답 요약
- 실행 ID(또는 n8n execution URL)
노드 9) 로그 저장(선택이지만 강추)
저장 필드 추천:
- datetime
- topic/title
- post_id
- draft_url
- status(success/fail)
- error_summary
- duration_ms
WordPress 업로드 필드 매핑 (실무에서 자주 헷갈림)
title: 글 제목content: 본문(HTML 권장)status:draftcategories: 카테고리 ID 배열(고정)tags: 태그 ID 배열 또는 태그 생성 로직
태그 운영 팁:
- 태그 자동 생성은 편하지만, 금방 태그가 폭발합니다.
- 저는 상위 20~30개 태그 풀을 만들어놓고 그 안에서만 고르게 했습니다.
실패 알림 / 재시도 (운영에서 제일 중요한 파트)
재시도는 현실적으로 이렇게만:
- 5xx / 429 → 2분 후 1회 재시도
- 401 / 403 → 재시도 금지(즉시 알림)
무한 재시도는
“고장난 자동화가 매일 스스로를 때리는 구조”가 되어서 운영이 망가집니다.
운영 체크리스트 (매일 자동으로 굴리는 기준)
- status는 항상 draft
- 알림 채널 1개 이상
- 재시도는 최대 1회
- 카테고리 ID 고정
- 태그는 풀 관리(남발 금지)
- 성공 알림에 드래프트 링크 포함
- Application Password 권한 점검(전용 계정 추천)
FAQ
Q1. 완전 자동 발행으로 해도 되나요?
A. 가능하지만, 초반에는 드래프트가 훨씬 안전합니다. 검수 루틴이 잡힌 뒤 자동 발행으로 확장하는 게 좋습니다.
Q2. 이미지(썸네일)까지 자동으로 가능해요?
A. 가능합니다. 다만 “미디어 업로드 → media_id → featured_media 연결” 단계가 추가됩니다(별도 글로 분리 추천).
Q3. 태그 ID를 모르면 어떻게 하죠?
A. 태그 조회 API로 먼저 찾고, 없으면 생성한 뒤 그 ID를 post 생성 payload에 넣는 방식으로 구현합니다.
이 글이 도움이 되었나요?좋아요/추천은 다시 누르면 취소됩니다.