n8n 블로그 글 자동 발행 워크플로우, 프론트엔드 설계법

블로그 자동화 글을 찾아보면 대부분 n8n 워크플로우 만드는 법에서 끝나요. 그런데 직접 만들어 보니 진짜 일은 그다음, 글을 받아서 화면에 올리는 프론트엔드 쪽에 있었어요.

혹시 자동 생성된 글 한 편 때문에 블로그 빌드 전체가 깨진 적 없나요? 저는 있어요. 그래서 이번에는 워크플로우 자체보다 받는 쪽 설계 이야기를 하려고 해요.

전체 흐름은 단순해요

n8n이 하는 일은 결국 파일 하나를 만들어 저장소에 커밋하는 것까지예요. 크론 트리거, AI 글 생성, MDX 파일 생성, Git 커밋. 노드 4개면 기본 골격이 나와요.

크론 트리거→AI 글 생성→MDX 파일 커밋→정적 빌드·배포

글 1편이 파일 1개로 떨어지니, 프론트엔드는 새 파일이 생기면 정적 빌드가 도는 구조만 잡으면 돼요.

frontmatter가 곧 컴포넌트 props예요

가장 먼저 정할 건 frontmatter 스키마예요. 저는 title, category, date, summary, source, publish, tags, slug까지 필드 8개를 고정했어요. 이 스키마가 목록 카드, 상세 페이지, 메타 태그 컴포넌트의 props로 그대로 흘러가요.

돌려 보니 AI가 필드를 빼먹거나 형식을 틀리는 날이 꼭 있더라고요. 그래서 빌드 단계에 스키마 검증을 걸어, 틀린 파일은 화면에 올라오기 전에 걸러지게 했어요.

publish 게이트, 자동 글은 초안까지만

자동 생성 글을 바로 공개하면 품질 사고가 나요. frontmatter에 publish: false 한 줄을 기본값으로 두고, 목록 컴포넌트가 이 값을 보고 초안을 숨기게 했어요.

검수는 초안 목록 화면에서 해요. 제목과 요약만 훑고 괜찮으면 publish를 true로 바꾸는 방식이라 한 편에 5분이면 끝나요. 하루 4~5편씩 들어와도 부담이 크지 않았어요.

시각 요소는 화이트리스트로

적용해 봤더니 제일 자주 깨진 건 본문 안 마크업이었어요. 특히 HTML 주석은 MDX 빌드를 그대로 깨뜨려요. AI가 쓸 수 있는 시각 요소를 Figure 컴포넌트 하나로 제한했더니 빌드가 안정됐고, 디자인 톤도 통일됐어요.

• ✓스키마 검증
• ✓publish 게이트
• ✓컴포넌트 화이트리스트

저는 플랜씨(plan-c)라는 무료 금융계산기를 혼자 만들면서 블로그까지 손으로 쓸 시간이 없어 이 구조를 잡았어요. 테스트해 보면 알겠지만, 자동화의 절반은 보내는 쪽이 아니라 받는 쪽 설계예요. 워크플로우를 만들기 전에 스키마와 게이트부터 정해 보세요. 반복을 줄이는 작은 도구는 그렇게 시작하는 것 같아요.