AI 블로그 자동화에서 프롬프트 계약을 운영 문서로 다루기

요약

AI 블로그 자동화에서 프롬프트는 단순히 “오늘 글 하나 써줘”라는 요청문이 아닙니다. Futory처럼 content/posts/*.md에 Markdown 파일을 추가하고, 콘텐츠 검증, 테마 검증, Next.js 빌드, PM2 재시작, 공개 URL 확인까지 이어지는 구조에서는 프롬프트가 곧 운영 계약이 됩니다. 어떤 시간에 실행할지, 어떤 날짜를 기준으로 삼을지, 중복은 어떻게 막을지, 실패하면 어디에서 멈출지까지 명시해야 자동화가 매일 같은 품질로 움직입니다.

이 글은 Futory의 일일 발행 루틴을 기준으로 AI 작업 지시를 검증 가능한 프롬프트 계약으로 다루는 방법을 정리합니다. 핵심은 “좋은 글을 만들어라”보다 “어떤 조건에서 아무것도 하지 말아야 하는지”, “새 파일 하나만 추가해야 하는지”, “공개 성공을 어떤 증거로 판단할지”를 먼저 고정하는 것입니다. 바이브코딩은 빠른 구현을 가능하게 하지만, 반복 운영에서는 프롬프트 자체도 코드처럼 관리되어야 합니다.

프롬프트가 운영 계약이 되는 순간

자동화가 한 번만 실행된다면 프롬프트는 비교적 느슨해도 됩니다. 사람이 결과를 보고 고치면 되기 때문입니다. 하지만 크론으로 매일 실행되는 발행 작업에서는 프롬프트가 실제 파일 시스템과 배포 프로세스를 움직입니다. 이때 애매한 지시는 중복 글, 잘못된 날짜, 빌드 실패, 공개 검증 누락으로 이어질 수 있습니다.

작업 범위를 먼저 제한한다

Futory의 일일 발행 작업에서 가장 중요한 계약은 “새 Markdown 파일 하나만 만든다”는 범위 제한입니다. 기존 글을 고치지 않고, 크론을 새로 만들지 않고, 배포 설정을 임의로 바꾸지 않는다는 조건이 있어야 실패 원인이 작아집니다. 글 하나를 추가하는 작업과 운영 시스템을 변경하는 작업이 섞이면 자동화 보고서를 읽어도 무엇이 변했는지 추적하기 어렵습니다.

범위를 제한하면 재시도도 쉬워집니다. 오늘 날짜 글이 이미 있으면 멈추고, 없을 때만 백업 후 새 파일을 만듭니다. 이 단순한 규칙이 하루 한 편 원칙을 지키는 가장 강한 안전장치입니다.

성공 조건을 감각이 아니라 증거로 쓴다

“발행됐다”는 말은 여러 상태를 섞기 쉽습니다. 파일이 생성된 것, 빌드가 성공한 것, PM2가 재시작된 것, 공개 상세 페이지가 200으로 열리는 것, 목록 페이지에서 발견되는 것은 모두 다른 단계입니다. 프롬프트 계약에는 이 단계를 나눠서 성공 조건을 적어야 합니다.

예를 들어 Futory에서는 .next 산출물에 새 slug가 포함됐는지 확인하고, SSH로 futory-wordblog PM2 앱을 재시작한 뒤, /posts/<slug>와 홈, /posts, /vibe-coding 목록을 cache-busting 요청으로 확인합니다. 이 정도 증거가 있어야 사용자는 자동 발행이 실제 독자 화면까지 반영됐는지 알 수 있습니다.

좋은 프롬프트 계약에 들어갈 항목

날짜와 시간 기준

일일 발행 자동화는 서버 시간과 독자가 기대하는 날짜가 어긋나기 쉽습니다. 그래서 Futory 루틴은 Asia/Seoul 기준 날짜와 시간을 사용합니다. 월요일부터 금요일까지만 실행하고, 14시부터 18시 사이에서 날짜별로 하나의 선택된 시간을 정합니다. 현재 시간이 선택된 시간이 아니면 파일을 만들지 않고 스킵해야 합니다.

이 조건은 글쓰기 품질과 무관해 보이지만 운영에서는 매우 중요합니다. 같은 날 여러 번 크론이 실행되어도 선택된 시간에만 행동하므로 불필요한 중복과 잦은 배포를 막을 수 있습니다.

중복 방지 기준

중복 방지는 filename만 보면 부족합니다. 어떤 글은 slug에 날짜가 없고, 날짜는 frontmatter에만 들어갈 수 있습니다. 따라서 프롬프트 계약은 “오늘 날짜가 frontmatter나 파일명에 이미 있으면 스킵한다”처럼 보수적으로 작성되어야 합니다. 특히 빌드 실패 후 다음 크론이 다시 실행될 때 같은 날짜 글을 또 만들지 않는 것이 중요합니다.

콘텐츠 형식

AI에게 자유롭게 글을 쓰게 하면 매번 구조가 흔들릴 수 있습니다. Futory에서는 ## 요약, 여러 H2와 H3, ## 자주 묻는 질문, ## 결론 같은 형식을 고정하면 독자가 익숙한 리듬으로 글을 읽을 수 있습니다. frontmatter도 제목, 설명, 날짜, 카테고리, 태그 배열을 같은 방식으로 유지해야 목록 카드와 카테고리 페이지가 안정적으로 동작합니다.

실패를 계약에 포함해야 한다

검증 실패 시 다음 단계로 가지 않는다

좋은 자동화 프롬프트는 성공 흐름만 적지 않습니다. npm run test:content가 실패하면 테마 검증이나 빌드로 넘어가지 않아야 하고, npm run build가 실패하면 PM2를 재시작하지 않아야 합니다. 실패 상태에서 다음 단계를 실행하면 원래 안정적이던 공개 서버까지 불필요하게 건드릴 수 있습니다.

보고서에는 멈춘 위치를 남긴다

자동화가 실패했을 때 사용자가 가장 알고 싶은 것은 “무엇을 고치면 되는가”입니다. 그래서 보고서에는 선택된 시간, 백업 경로, 새 파일 경로, 테스트 결과, 빌드 결과, PM2 재시작 여부, 공개 검증 결과가 단계별로 들어가야 합니다. 실패가 발생하면 정확한 명령과 오류를 남기고 멈추는 것이 프롬프트 계약의 일부입니다.

운영자가 점검할 수 있는 프롬프트 체크리스트

매일 실행 전 확인할 질문

• 오늘이 KST 평일인가?
• 현재 시간이 오늘의 선택된 발행 시간인가?
• 오늘 날짜가 frontmatter나 파일명에 이미 있는가?
• 최근 글과 주제가 지나치게 겹치지 않는가?
• 새 파일을 쓰기 전에 content/posts 백업이 만들어졌는가?

공개 전 확인할 질문

• frontmatter가 프로젝트 규칙과 맞는가?
• 콘텐츠 검증과 테마 검증이 모두 통과했는가?
• Next.js 빌드가 성공했는가?
• .next 산출물에서 새 slug가 확인되는가?
• PM2 재시작이 실제 호스트 앱에 적용됐는가?
• 공개 상세 페이지와 목록 페이지가 새 글을 보여주는가?

이 체크리스트를 프롬프트에 넣으면 AI는 더 창의적인 글을 쓰면서도 운영 경계를 벗어나지 않습니다. 바이브코딩에서 중요한 것은 자유롭게 만드는 능력과 멈춰야 할 조건을 함께 갖는 것입니다.

자주 묻는 질문

프롬프트 계약을 너무 자세히 쓰면 AI가 딱딱한 글만 쓰지 않나요?

그렇지 않습니다. 계약은 운영 경계를 정하는 역할이고, 문장 표현과 예시는 여전히 유연하게 만들 수 있습니다. 오히려 날짜, 파일 경로, 검증 조건을 고정하면 AI는 불필요한 판단에 에너지를 쓰지 않고 본문 품질에 집중할 수 있습니다.

매일 같은 주제처럼 보이는 문제는 어떻게 줄이나요?

최근 글을 먼저 읽고 오늘 글의 관점을 분리하면 됩니다. 예를 들어 어제는 롤백 기준을 다뤘다면 오늘은 프롬프트 계약, 내일은 검증 로그나 내부 링크처럼 운영 자동화의 다른 층위를 다룰 수 있습니다. 같은 Futory 맥락을 유지하되 독자가 얻는 실무 포인트를 바꾸는 방식입니다.

프롬프트도 버전 관리해야 하나요?

반복 실행되는 자동화라면 버전 관리하는 편이 좋습니다. 프롬프트가 바뀌면 생성되는 파일, 실행 명령, 보고서 형식도 바뀔 수 있기 때문입니다. 최소한 변경 이유와 적용 날짜를 남기면 나중에 특정 날짜부터 발행 품질이나 실패 패턴이 달라진 이유를 추적하기 쉽습니다.

결론

Futory의 AI 블로그 자동화에서 프롬프트는 일회성 요청이 아니라 매일 실행되는 운영 계약입니다. 날짜 기준, 선택 시간, 중복 방지, 백업, 새 파일 생성 범위, 검증 명령, 빌드, PM2 재시작, 공개 URL 확인까지 계약으로 고정해야 자동화가 안전하게 반복됩니다.

바이브코딩은 빠르게 만들고 즉시 개선하는 방식이지만, 공개 블로그 운영에서는 빠름만으로 충분하지 않습니다. AI가 무엇을 해야 하는지뿐 아니라 언제 아무것도 하지 말아야 하는지, 어떤 증거가 있어야 성공이라고 말할 수 있는지를 프롬프트에 담을 때 Futory의 일일 발행 루틴은 더 신뢰할 수 있는 운영 도구가 됩니다.