n8n으로 워드프레스 초안 발행 전, 놓치기 쉬운 노드 구성 확인 순서

n8n으로 워드프레스 글 발행 자동화를 만들다 보면 의외로 막히는 지점은 AI 본문 생성보다 마지막 초안 발행 단계입니다. 글은 만들어졌는데 제목이 비거나, 슬러그가 이상하게 들어가거나, 이미지 필드가 빠져서 결국 워드프레스에서 다시 손으로 수정하는 경우가 많습니다.

이 문제를 초기에 잡지 않으면 테스트를 몇 번이나 반복하게 되고, 발행 실패보다 더 번거로운 건 ‘발행은 됐는데 품질이 낮은 초안’이 쌓이는 상황입니다. 자동화는 돌았는데 사람이 다시 다듬어야 한다면 시간을 아끼려던 목적이 거의 사라집니다.

이 글에서는 n8n으로 워드프레스 초안 발행 전 확인할 노드를 단순 나열하지 않고, 실제로 재작업을 줄이는 순서로 보겠습니다. 입력 수집, 데이터 정리, 본문 검증, 메타 필드 구성, 이미지 처리, 워드프레스 전송, 예외 처리까지 어떤 노드가 왜 필요한지 실무 관점에서 설명하겠습니다.

특히 처음 만드는 사람과 이미 워크플로를 굴리고 있지만 초안 품질이 들쑥날쑥한 사람은 첫 번째 결론 구간까지만 읽어도 우선순위를 바로 잡을 수 있습니다. 순서 하나만 틀려도 재작업이 생길 수 있어, 먼저 어떤 노드를 앞에 두고 어떤 검증을 뒤에 두어야 하는지부터 잡아두는 편이 훨씬 효율적입니다.

먼저 확인할 것

  • 핵심 기준을 먼저 확인하고 세부 절차로 넘어갑니다.
  • 놓치기 쉬운 조건과 예외 상황을 따로 정리합니다.
  • 필요한 서류나 확인 경로를 미리 확보합니다.
  • 마지막에는 실제 적용 가능 여부를 다시 점검합니다.
n8n 워드프레스 초안 발행 관련 대표 이미지

n8n 워드프레스 핵심

n8n으로 워드프레스 초안 발행 자동화를 만들 때 가장 현실적인 구성은 입력 수집 → 필드 정규화 → 본문 생성 → 품질 검증 → 워드프레스용 필드 매핑 → 초안 발행 → 발행 결과 기록 순서입니다. 많은 분이 AI 생성 노드와 워드프레스 업로드 노드만 먼저 연결하지만, 실제로는 그 사이에 제목·슬러그·excerpt·카테고리·HTML 구조를 정리하는 중간 노드가 빠져서 초안 품질이 흔들립니다.

핵심은 ‘발행 성공’보다 ‘수정할 일이 적은 초안’을 만드는 것입니다. 그래서 노드 수가 적은 구성이 항상 좋은 것은 아닙니다. 오히려 Set, Code, IF, Merge, HTTP Request 같은 단순한 노드를 중간에 넣어 검증 단계를 만드는 편이 나중에 훨씬 안정적입니다. 특히 워드프레스 초안은 공개 발행이 아니더라도 필드 누락이 누적되면 SEO 설정, 이미지 연결, 내부 링크 삽입까지 뒤에서 연쇄적으로 꼬입니다.

  • 최우선: 제목, 슬러그, 본문 HTML, excerpt가 비지 않도록 검증
  • 그다음: 카테고리·태그·상태값(draft) 매핑 확인
  • 중요 변수: 이미지 URL, 대표 이미지 업로드 방식, 커스텀 필드 존재 여부
  • 마지막: 발행 후 post ID 저장, 실패 로그, 재시도 조건 분리

여기서 한 번 더 점검해야 할 부분은 발행 노드 자체보다 워드프레스 안쪽 설정입니다. n8n 워크플로가 정상이어도 SEO 플러그인 메타나 사이트맵, robots 설정이 뒤에서 받쳐주지 않으면 초안만 쌓이고 검색 유입 연결은 약해질 수 있습니다.

왜 노드 구성이 자주 꼬일까

가장 흔한 이유는 n8n을 ‘데이터를 옮기는 도구’로만 보고, ‘발행 전 검수 흐름’을 넣지 않기 때문입니다. 예를 들어 구글 시트에서 주제를 읽어 와서 AI로 본문을 만들고 바로 워드프레스로 보내면 겉으로는 자동화처럼 보입니다. 하지만 실제 글 하나를 보면 제목 길이 과다, HTML 태그 누락, excerpt 미작성, 카테고리 값 불일치 같은 문제가 숨어 있습니다.

또 하나의 원인은 각 노드가 맡아야 할 역할이 섞이는 것입니다. AI 노드에게 제목 생성, 본문 생성, 슬러그 생성, 해시태그 생성, 메타 설명 생성까지 한 번에 맡기면 출력 형식이 조금만 흔들려도 다음 노드가 깨집니다. 반대로 역할을 잘게 나누면 디버깅은 쉬워지지만 노드 간 필드 이름이 제각각이어서 다시 혼선이 생길 수 있습니다. 그래서 중요한 것은 노드 개수보다 역할 분리 기준입니다.

실제로는 여기서 실패하는 경우가 많아, 본문 생성 기준만 볼 게 아니라 워드프레스 내부 설정도 같이 비교해야 합니다. 예를 들어 메타 설명이나 사이트맵이 자동 반영되는지, 이미지 포맷 최적화가 따로 필요한지까지 이어서 확인하면 초안 발행 후 손작업을 줄일 수 있습니다.

이 흐름을 이해하면 왜 Rank Math 설정, sitemap 구성, robots.txt 설정이 초안 자동화와 따로 노는 주제가 아닌지도 보입니다. 발행 직전 노드 구성이 좋아도 뒤쪽 검색 노출 흐름이 비어 있으면 자동화 효율이 반쪽이 되기 쉽습니다.

필수 노드 역할

워드프레스 초안 발행 전 기준으로 보면 n8n의 필수 노드는 크게 여섯 역할로 나눌 수 있습니다. 첫째는 입력 수집 노드, 둘째는 데이터 정리 노드, 셋째는 생성 노드, 넷째는 검증 노드, 다섯째는 발행 노드, 여섯째는 기록 노드입니다. 이 여섯 가지가 보이면 워크플로가 길어 보여도 구조는 단순해집니다.

입력 수집에는 Manual Trigger, Schedule Trigger, Webhook, Google Sheets, Airtable, Notion, RSS 같은 노드가 들어갈 수 있습니다. 데이터 정리에는 Set, Edit Fields, Code, Merge가 중심이 되고, 생성에는 OpenAI 계열 또는 외부 LLM API 연결이 들어갑니다. 검증에는 IF, Switch, Code, Error Trigger 조합이 유용하고, 발행에는 WordPress 노드 또는 HTTP Request가 사용됩니다. 기록에는 Google Sheets 업데이트, 데이터베이스 저장, Slack 알림, 이메일 알림 같은 후속 노드가 들어갑니다.

구간 주요 노드 확인 포인트 빠지면 생기는 문제
입력 수집 Trigger, Sheets, Notion, Webhook 주제·카테고리·상태값 입력 여부 빈 글감, 잘못된 분기
데이터 정리 Set, Merge, Code 필드명 통일, null 처리 다음 노드 매핑 오류
본문 생성 LLM, HTTP Request JSON 형식, HTML 본문 구조 파싱 실패, 태그 깨짐
품질 검증 IF, Code, Switch 제목 길이, 본문 길이, 금칙어 발행은 되지만 품질 저하
워드프레스 발행 WordPress, HTTP Request status=draft, slug, excerpt, category 공개 오발행, 필드 누락
결과 기록 Sheets Update, Slack, DB post ID, 실패 사유, 재처리 여부 중복 발행, 추적 불가

이 표에서 중요한 건 검증 노드가 별도 구간으로 있어야 한다는 점입니다. 많은 워크플로가 ‘생성되면 바로 발행’ 구조인데, 그 사이에 최소한의 필드 검사만 추가해도 실패율이 크게 내려갑니다.

입력 수집 노드에서 먼저 볼 것

초안 발행 전 노드 구성에서 가장 앞단은 생각보다 중요합니다. 입력 수집 단계가 흔들리면 이후 모든 노드가 정상 작동해도 엉뚱한 결과가 나올 수 있습니다. 예를 들어 주제만 있고 카테고리가 비어 있거나, 초안 상태를 뜻하는 필드가 없거나, 내부적으로 사용할 slug_seed 값이 빠져 있으면 뒤에서 억지로 보정해야 합니다.

입력 소스가 시트든 노션이든 폼이든, 최소한 다음 필드를 먼저 정의해 두는 편이 좋습니다. 주제, 카테고리, 글 의도, 발행 상태, 이미지 힌트, 내부 링크 후보, 금지 각도, 참고 글, 우선순위 정도입니다. 이런 값이 없어도 AI는 그럴듯한 초안을 만들 수 있지만, 자동 발행 단계에서는 분기 기준이 없어서 사람 개입이 늘어납니다.

처음에는 필수 입력을 줄여 빨리 돌리고 싶겠지만, 장기적으로는 오히려 앞단 필드를 조금 더 넣는 편이 편합니다. 특히 카테고리 값은 워드프레스 쪽 ID와 연결될 수 있으니 문자열 이름만 보내는지, 사전에 매핑 테이블을 두는지 정해야 합니다. 초반에 이 기준이 없으면 같은 카테고리도 표기만 달라져 분기가 실패합니다.

순서 하나만 틀려도 재작업이 생길 수 있어, 여기서 입력 필드 설계와 워드프레스 카테고리 구조를 한 번 더 맞춰보는 것이 좋습니다. 나중에 SEO 메타나 사이트맵 흐름까지 연결할 계획이라면 발행 전에 어떤 값이 반드시 있어야 하는지부터 점검해야 다음 단계 판단이 빨라집니다.

본문 생성 전 정규화 노드

AI 본문 생성 전에 Set 또는 Code 노드로 데이터를 정규화하는 단계는 거의 필수라고 봐도 됩니다. 여기서 하는 일은 거창하지 않습니다. 빈 값에 기본값을 넣고, 문자열 길이를 제한하고, 카테고리 이름을 통일하고, 후속 노드가 참조할 필드명을 한 버전으로 정리하는 것입니다. 이런 단계가 빠지면 프롬프트가 흔들리고, 출력 형식도 문서마다 달라집니다.

예를 들어 topic, title_seed, focus_keyword, category_name, status, excerpt_hint, image_prompt처럼 중간 필드를 명확히 나눠두면 이후 생성과 검증이 편해집니다. 특히 슬러그 생성은 한글 제목을 그대로 쓰지 않고 별도 규칙을 두는 편이 안전합니다. 워드프레스가 자동 슬러그를 만들 수는 있지만, 중복 제목이 많은 자동화 환경에서는 예상하지 못한 뒤 숫자 접미사가 붙을 수 있습니다.

정규화 단계에서 자주 놓치는 부분은 줄바꿈, 따옴표, HTML 예약문자입니다. AI 응답을 JSON으로 받든 텍스트로 받든, 워드프레스 본문에 들어갈 HTML과 메타 필드에 들어갈 일반 텍스트는 다르게 다뤄야 합니다. 메타 설명에 줄바꿈이 그대로 들어가거나 제목에 특수문자가 과도하게 들어가면 초안은 생성되어도 편집 화면에서 바로 수정하게 됩니다.

또한 같은 글을 여러 채널에 쓰는 경우라면 워드프레스용 필드와 SNS용 필드를 분리해 두는 것이 좋습니다. 한 번에 만들 수는 있어도, 초안 발행 전 노드에서는 워드프레스에 필요한 최소 필드가 무엇인지 먼저 고정해야 합니다.

워드프레스용 필드 매핑

워드프레스 초안 발행 직전에는 어떤 필드를 실제로 보내야 하는지 명확해야 합니다. 일반적으로는 title, content, status, excerpt, slug, categories, tags, featured_media 정도가 기본입니다. 여기에 사용하는 테마나 플러그인에 따라 meta description, focus keyword, custom fields가 추가될 수 있습니다. 이때 WordPress 기본 노드로 충분한지, REST API를 HTTP Request로 직접 쏴야 하는지 결정이 필요합니다.

기본 노드만으로 해결되는 경우도 많지만, 커스텀 필드나 특정 SEO 플러그인 메타까지 다루려면 API 응답 구조를 직접 확인해야 합니다. 그래서 처음부터 무조건 복잡한 구성을 만들 필요는 없지만, 향후 확장할 가능성이 있다면 발행 노드 앞에서 데이터를 워드프레스 구조에 맞춰 한 번 더 매핑하는 노드가 있는 편이 좋습니다.

특히 초안 상태는 반드시 명시적으로 넣는 습관이 필요합니다. 테스트 중에 status 필드가 빠지면 예상치 못한 공개 발행이 나는 환경도 있기 때문입니다. 또한 categories 값은 이름이 아니라 ID 배열이 필요한 경우가 많아, 사람 친화적인 입력값과 실제 발행값을 분리해 관리하는 편이 안전합니다.

이 단계에서 많이 갈리는 부분은 SEO 메타를 어디까지 자동화할지입니다. 제목과 본문만 보내고 나중에 워드프레스에서 정리할 수도 있지만, 게시물 수가 늘어나면 병목이 됩니다. 따라서 Rank Math 같은 SEO 설정과 메타 필드 반영 방식을 미리 정리해 두면 발행 후 수정 횟수를 크게 줄일 수 있습니다.

n8n 워드프레스 확인

자동 발행에서 가장 가치가 큰 노드는 생성 노드가 아니라 검증 노드입니다. AI가 그럴듯하게 써도, 워드프레스 초안으로 올릴 가치가 있는지는 별도로 판정해야 합니다. 이때 IF나 Code 노드로 최소 품질 기준을 만들어 두면 발행 성공률보다 실사용 가능성이 높아집니다.

검증 기준은 복잡할 필요가 없습니다. 예를 들어 제목 길이 최소치, 본문 길이 하한, excerpt 존재 여부, HTML에 h2 개수 존재 여부, 금칙어 포함 여부, placeholder 문구 존재 여부, JSON 파싱 성공 여부 같은 항목만 봐도 효과가 큽니다. 본문 안에 ‘여기에 내용 추가’ 같은 임시 문구가 들어가면 초안 발행을 막는 식의 룰도 실무에서는 매우 유용합니다.

  • 제목 검증: 너무 짧거나 동일 제목 반복 여부 확인
  • 본문 검증: 최소 길이, h2 수, 문단 수, 금칙어 검사
  • 메타 검증: excerpt, slug, category 값 존재 여부
  • 상태 검증: draft 강제 설정 여부
  • 중복 검증: 기존 발행 로그와 topic 중복 여부

여기서 비용만 보면 노드를 줄이고 싶어지지만, 실제 사용 단계에서는 다시 바꾸는 경우가 많습니다. 검증 노드를 빼면 생성 비용은 조금 아껴도 사람이 수정하는 시간이 늘어나고, 결국 발행 효율이 떨어집니다. 워드프레스 자동화는 ‘한 번에 통과하는 초안’을 만들 때 비로소 체감 효율이 생깁니다.

중간쯤에서 한 번 더 확인해야 할 건 검색 노출과 성능 쪽 후속 설정입니다. 초안 품질만 좋아도 충분해 보이지만, 실제 유입까지 생각하면 이미지 최적화, sitemap, robots, CDN 같은 다음 기준을 같이 봐야 운영 단계에서 막히지 않습니다.

이미지와 미디어 처리

워드프레스 초안 발행 자동화에서 이미지 처리는 생각보다 많은 오류를 일으킵니다. 본문은 올라갔는데 대표 이미지가 비어 있거나, 외부 URL만 붙고 실제 미디어 라이브러리에는 등록되지 않거나, WEBP 파일이 환경에 따라 미리보기에서 깨지는 경우가 대표적입니다. 그래서 이미지 관련 노드는 본문 생성 이후, 발행 직전 또는 발행 직후에 분리하는 편이 안정적입니다.

기본적으로는 이미지 프롬프트 생성, 이미지 URL 수집, 미디어 업로드, 업로드된 media ID 회수, 게시물 featured_media 연결 순서로 보는 것이 좋습니다. WordPress 노드만으로 미디어 처리가 제한적일 수 있어 HTTP Request로 미디어 업로드 API를 따로 다루는 경우도 많습니다. 이때 파일명 규칙, MIME 타입, 인증 헤더를 함께 확인해야 합니다.

이미지 최적화 관점까지 보면 더 중요해집니다. 초안 발행은 성공했지만 원본 이미지가 너무 크면 사이트 속도와 광고 가시성까지 영향을 받습니다. 따라서 자동화 설계 단계에서 WEBP 변환, 이미지 용량 제한, 대체텍스트 생성 여부까지 고려하면 나중에 운영 품질이 훨씬 좋아집니다.

특히 대표 이미지가 필수인 사이트라면 이미지 업로드 실패 시 ‘초안은 만들되 발행 플래그를 검토 상태로 남기는 분기’를 두는 방식이 현실적입니다. 모든 실패를 막으려 하기보다, 품질이 낮은 초안을 사람이 빠르게 식별할 수 있게 만드는 편이 더 안정적입니다.

n8n 워드프레스 순서

처음 구성할 때는 노드 목록보다 실제 실행 순서가 더 도움이 됩니다. 아래 순서는 가장 단순하면서도 초안 품질과 디버깅 편의성을 함께 챙기기 쉬운 흐름입니다. 이 구조를 기본형으로 두고, 나중에 SEO 메타나 이미지 처리, 내부 링크 추천 단계를 확장하는 방식이 부담이 적습니다.

  1. Trigger 실행: 수동 테스트 또는 스케줄 시작
  2. 입력 데이터 로드: 시트·노션·DB에서 topic, category, status 읽기
  3. Set/Code 정규화: 빈 값 보정, 필드명 통일, slug_seed 생성
  4. AI 생성: 제목, excerpt, HTML 본문, FAQ 등 필요한 초안 생성
  5. 출력 파싱: JSON 분리, 개별 필드 추출
  6. 품질 검증: 제목 길이, 본문 길이, 필수 필드, 금칙어 검사
  7. 이미지 처리: 필요 시 대표 이미지 업로드 후 media ID 저장
  8. 워드프레스 초안 발행: status=draft로 게시물 생성
  9. 결과 저장: post ID, 발행 시간, 실패 사유 기록
  10. 알림 전송: 슬랙이나 메일로 검토 대상 공유

이 순서를 그대로 쓰라는 뜻은 아닙니다. 다만 생성 후 곧바로 발행하지 않고, 파싱과 검증을 사이에 넣는다는 구조만 지켜도 실패가 크게 줄어듭니다. 초반에는 5개 노드로 끝내려 하기보다 ‘어디서 깨졌는지 보이는 구조’를 우선으로 잡는 편이 좋습니다.

여기서 한 단계 더 가려면 워드프레스 발행 후 점검 주제를 분리해서 보는 것이 좋습니다. 예를 들어 초안이 잘 들어간 다음에는 SEO 플러그인 설정, 사이트맵 반영, robots 허용 여부처럼 후속 단계에서 실제 노출 품질이 갈리기 때문입니다.

n8n 워드프레스 실패 포인트

첫 번째 실패 패턴은 AI 출력 형식이 흔들리는데도 파싱 노드를 느슨하게 잡는 경우입니다. 한 번은 JSON으로 오고, 다음 번은 설명 문장이 섞여 오면 이후 Set 노드나 WordPress 노드에서 필드를 읽지 못합니다. 이런 경우에는 모델 프롬프트를 다듬는 것만큼, 응답 형식을 강제하고 파싱 실패 시 재요청 또는 보류 분기를 만드는 것이 중요합니다.

두 번째는 워드프레스 인증과 권한 문제입니다. 테스트 환경에서는 되는데 운영 환경에서 막히는 경우가 많은데, 이는 애플리케이션 비밀번호, REST API 권한, 보안 플러그인 차단, Cloudflare 또는 호스팅 방화벽 이슈가 섞여 있기 때문입니다. 발행 노드 자체를 의심하기 전에 인증 헤더, 엔드포인트 접근 가능 여부, 사용자 권한을 먼저 확인해야 합니다.

세 번째는 카테고리·태그·SEO 메타처럼 본문 외 필드를 나중 문제로 미루는 패턴입니다. 처음에는 글만 들어가면 된다고 생각하지만, 게시물이 쌓일수록 수정 비용이 기하급수적으로 늘어납니다. 특히 검색용 기본 설정이 비어 있으면 발행 자동화는 돌았는데 유입 구조는 약한 상태가 이어질 수 있습니다.

네 번째는 이미지와 성능을 초안 발행과 분리하지 않는 것입니다. 이미지를 매번 생성하고 업로드하다가 실패하면 전체 워크플로가 멈추는 구조라면 운영 피로도가 커집니다. 본문 초안과 미디어 처리를 분기해서 실패 허용 범위를 다르게 두는 것이 훨씬 현실적입니다.

n8n 워드프레스 순서

초안 발행 전 노드 구성이 얼추 완성됐더라도, 운영 단계에서는 다른 질문이 생깁니다. 이 워크플로가 반복 실행돼도 중복 발행이 없는지, 실패한 글은 다시 잡아낼 수 있는지, 초안 품질이 일정한지 같은 기준입니다. 자동화는 ‘한 번 성공’보다 ‘반복해도 유지되는지’가 훨씬 중요합니다.

아래 체크리스트는 실제 운영으로 넘어가기 전 마지막으로 보기 좋은 항목입니다. 테스트 단계에서는 대충 넘어갈 수 있어도, 글 수가 늘어나면 이 부분에서 안정성과 생산성이 갈립니다.

  • 입력 데이터에 고유 ID가 있어 중복 발행을 막을 수 있는가
  • status 값이 항상 draft로 고정되는가
  • 제목, 본문, excerpt, slug 중 하나라도 비면 발행이 중단되는가
  • 카테고리 값이 워드프레스 실제 ID와 연결되는가
  • 이미지 실패 시 전체 중단인지, 초안만 생성인지 분기돼 있는가
  • 발행 후 post ID와 원본 row ID를 함께 저장하는가
  • 실패 로그가 남아 다음 재처리가 쉬운가
  • 워드프레스 내부 SEO·사이트맵·robots 설정과 충돌이 없는가

이 체크리스트에서 마지막 항목은 자주 미뤄지지만 중요합니다. 초안이 아무리 잘 올라가도 검색엔진이 읽을 구조가 안 잡혀 있으면 자동화의 성과가 체감되기 어렵습니다. 그래서 운영 직전에는 발행 노드만 보지 말고 워드프레스의 SEO 플러그인, 사이트맵, robots, 이미지 최적화까지 한 번에 점검하는 편이 좋습니다.

n8n 워드프레스 마지막

n8n으로 워드프레스 초안 발행 자동화를 만들 때 핵심은 ‘노드를 많이 쓰느냐 적게 쓰느냐’가 아닙니다. 필드 정리와 검증을 발행 전에 분리해 두느냐가 성패를 가릅니다. 입력 수집, 정규화, 본문 생성, 검증, 발행, 기록의 구조가 보이면 워크플로는 길어 보여도 오히려 다루기 쉬워집니다.

처음 만드는 분이라면 가장 먼저 제목·본문·excerpt·slug·status를 안정적으로 보내는 기본형부터 완성하는 것이 좋습니다. 이미 자동화를 돌리고 있는데 초안 품질이 들쑥날쑥하다면, 새 모델을 바꾸기보다 검증 노드와 필드 매핑 노드를 먼저 손보는 편이 효과가 큽니다. 결국 워드프레스 자동화는 생성 능력보다 발행 전 확인 구조가 결과를 더 많이 좌우합니다.

다음으로 볼 건 발행 이후의 품질입니다. SEO 메타가 실제로 어떻게 반영되는지, 사이트맵과 robots가 검색 흐름을 막고 있지 않은지, 이미지와 CDN 설정이 속도까지 받쳐주는지 확인하면 자동화의 완성도가 한 단계 올라갑니다.

자주 묻는 질문

n8n으로 워드프레스 초안만 발행하려면 최소 몇 개 노드가 필요한가요?

아주 단순하게는 Trigger, 입력 수집, AI 생성, WordPress 발행 정도로 시작할 수 있습니다. 다만 실제 운영에서는 필드 정리와 품질 검증, 결과 기록까지 포함해 7~10개 안팎이 더 안정적입니다. 최소 구성이 가능하더라도 검증 노드가 없으면 수정할 초안이 많이 쌓일 수 있습니다.

WordPress 기본 노드만 써도 충분한가요?

기본적인 초안 생성에는 충분한 경우가 많습니다. 하지만 커스텀 필드, SEO 메타, 이미지 업로드, 세부 REST API 제어가 필요하면 HTTP Request를 함께 쓰는 편이 유연합니다. 설정 오류 기준까지 확인하면 재작업을 줄일 수 있습니다.

가장 먼저 검증해야 할 필드는 무엇인가요?

제목, 본문 HTML, excerpt, slug, status를 우선 검증하면 됩니다. 여기에 카테고리 ID까지 안정적으로 매핑되면 실사용 가능한 초안의 기본 조건이 맞춰집니다. 이후에는 SEO 설정 반영 방식까지 보면 초안 이후 단계 판단이 더 빨라집니다.

AI 응답 형식이 자꾸 흔들리면 어떻게 바꿔야 하나요?

프롬프트 수정만으로 해결하려 하기보다 출력 형식 강제, 파싱 실패 시 재시도, 실패 시 보류 분기를 함께 만드는 편이 좋습니다. JSON 키 존재 여부를 Code 노드에서 확인하면 안정성이 올라갑니다. 입력 방식과 파싱 규칙까지 함께 보면 흔들리는 결과를 더 빨리 잡을 수 있습니다.

대표 이미지가 없어도 초안 발행을 진행해도 될까요?

내부 검토용 초안이라면 가능하지만, 썸네일이 필수인 운영 구조라면 이미지 실패를 별도 오류로 분리하는 것이 좋습니다. 본문 초안과 미디어 처리를 나누면 전체 워크플로 중단을 줄일 수 있습니다. 이미지 최적화 기준까지 같이 보면 발행 후 속도 문제도 미리 줄일 수 있습니다.

카테고리는 이름으로 보내도 되나요, ID로 보내야 하나요?

입력 단계에서는 이름이 편하지만, 최종 발행 단계에서는 ID로 보내는 방식이 더 안정적입니다. 중간 매핑 노드에서 이름을 ID로 변환하면 카테고리 표기 흔들림 때문에 생기는 오류를 줄일 수 있습니다.


소소한 행복을 찾는 블로그에서 더 알아보기

구독을 신청하면 최신 게시물을 이메일로 받아볼 수 있습니다.

위로 스크롤

소소한 행복을 찾는 블로그에서 더 알아보기

지금 구독하여 계속 읽고 전체 아카이브에 액세스하세요.

계속 읽기