AI 블로그 자동화에서 수동 개입 경계를 정하는 법

요약

Futory처럼 Next.js와 Markdown으로 운영되는 AI 블로그는 평일마다 새 글 하나를 만들고, 테스트와 빌드를 거쳐 공개 페이지까지 확인하는 자동화 흐름을 갖습니다. 이 흐름이 안정적이려면 자동화가 끝까지 처리해야 하는 일과 사람이 개입해야 하는 일을 미리 나누어 두어야 합니다. 기준이 없으면 작은 경고에도 발행이 멈추거나, 반대로 빌드 실패 뒤에도 런타임을 재시작하는 위험한 상황이 생길 수 있습니다.

수동 개입 경계는 자동화를 약하게 만드는 장치가 아니라 더 오래 믿고 맡기기 위한 안전선입니다. Futory의 바이브코딩 루틴에서는 날짜 중복 검사, posts 백업, 새 Markdown 작성, 콘텐츠 테스트, 테마 테스트, 빌드, .next 산출물 확인, PM2 재시작, 공개 URL 검증이 차례로 이어집니다. 각 단계마다 자동으로 복구할 수 있는 문제와 멈추고 보고해야 하는 문제를 구분하면 무인 발행의 품질이 좋아집니다.

왜 수동 개입 경계가 필요한가

자동 발행은 반복 작업을 줄여 주지만 모든 문제를 자동으로 고쳐도 된다는 뜻은 아닙니다. 예를 들어 오늘 날짜 글이 이미 존재하면 새 글을 하나 더 만드는 대신 멈추어야 합니다. 반대로 최근 글 목록을 읽는 과정에서 비슷한 주제가 보이면 자동화는 다른 좁은 주제를 선택할 수 있습니다. 두 상황 모두 “문제가 있다”는 공통점이 있지만 대응은 완전히 다릅니다.

계속 진행해도 되는 문제

자동화가 안전하게 우회할 수 있는 문제는 사람을 부르지 않아도 됩니다. 최근 글과 주제가 겹칠 때 다른 운영 각도를 선택하는 일, 백업 도구 하나가 막힐 때 Python tarfile로 같은 posts 백업을 만드는 일, 공개 검증에서 제목 대신 slug와 날짜를 기준으로 확인하는 일은 모두 자동으로 처리할 수 있습니다. 이런 우회는 원천 데이터를 바꾸지 않고 목표를 그대로 만족시키기 때문에 자동화의 역할에 맞습니다.

반드시 멈추어야 하는 문제

반대로 콘텐츠 계약이나 배포 계약을 깨는 문제는 멈추어야 합니다. npm run test:content가 실패하면 새 Markdown의 frontmatter나 본문 구조가 잘못되었을 수 있습니다. npm run build가 실패하면 공개 런타임을 재시작해도 새 글은 안전하게 반영되지 않습니다. SSH로 PM2 재시작이 실패하면 파일과 빌드는 준비됐지만 실제 서비스 반영은 불확실합니다. 이때는 다음 단계를 실행하지 않고 정확한 명령과 오류를 보고해야 합니다.

Futory 루틴에서 경계를 세우는 방법

수동 개입 경계는 단계마다 “자동화가 가진 권한”과 “검증 가능한 결과”를 함께 보는 방식으로 정할 수 있습니다. Futory의 정기 발행은 기존 글을 수정하지 않고 새 파일 하나만 추가하는 제한된 작업입니다. 이 제한은 답답한 제약이 아니라 사고 범위를 작게 만드는 장점입니다.

중복 방지는 사람이 아니라 규칙이 맡는다

하루에 한 편이라는 원칙은 감으로 판단하면 안 됩니다. 오늘 KST 날짜가 frontmatter에 있거나 파일명에 있으면 자동화는 SKIP해야 합니다. 이미 있는 글의 제목과 파일 경로를 보고하면 충분합니다. 여기에서 사람이 더 쓸지 말지 판단하게 만들면 무인 크론의 의미가 줄어듭니다. 중복 방지는 명확한 규칙으로 자동 처리하는 편이 안전합니다.

파일 생성은 가장 작은 단위로 제한한다

새 글을 만들 때는 기존 posts를 고치지 않고 영어 kebab-case slug의 Markdown 파일 하나만 추가합니다. 이 원칙이 있으면 실패 시 되돌릴 대상이 분명합니다. 자동화가 동시에 오래된 글의 태그를 고치거나 레이아웃을 수정하기 시작하면 발행 실패가 콘텐츠 문제인지 코드 문제인지 알기 어려워집니다. 바이브코딩은 빠른 실행을 좋아하지만, 빠른 실행일수록 변경 단위는 작아야 합니다.

빌드 이후에는 공개 신호로 판단한다

로컬 테스트와 빌드가 통과해도 실제 발행 완료는 공개 페이지에서 확인해야 합니다. .next 산출물에 slug가 있는지 먼저 보고, PM2를 재시작한 뒤 /posts/<slug>가 200인지 확인합니다. 이어서 홈, /posts, /vibe-coding에 오늘 날짜나 slug가 보이면 상세 페이지와 발견 경로가 모두 통과한 것입니다. 이 검증은 사람이 브라우저를 열지 않아도 자동화가 수행할 수 있는 영역입니다.

보고서에 남길 기준

수동 개입 경계는 최종 보고서에 드러나야 다음 운영자가 믿을 수 있습니다. 단순히 “성공”이라고 쓰는 대신 어떤 단계는 자동으로 처리했고 어떤 단계는 통과했는지 짧게 남기는 것이 좋습니다.

성공 보고는 운영 장부처럼 쓴다

성공한 날의 보고서에는 선택된 KST 시간, 중복 검사 결과, 백업 경로, 제목, 날짜, 파일 경로, 공개 URL, 테스트와 빌드 상태, PM2 재시작 상태, 공개 검증 상태가 들어가야 합니다. 이 정보는 다음 실행의 주제 회피와 장애 분석에도 쓰입니다. 긴 콘솔 로그보다 고정된 항목의 짧은 장부가 더 실용적입니다.

실패 보고는 하지 않은 일을 함께 적는다

실패했을 때는 어느 명령이 실패했는지만큼 이후 단계를 실행하지 않았다는 사실도 중요합니다. 빌드 실패 후 PM2를 재시작하지 않았다고 적으면 운영자는 공개 서비스가 불필요하게 흔들리지 않았다는 점을 알 수 있습니다. 공개 검증 실패라면 파일 생성, 테스트, 빌드, 재시작은 통과했지만 반영 확인이 부족한 상태로 구분할 수 있습니다.

자주 묻는 질문

자동화가 알아서 고칠 수 있는 범위를 넓히면 더 좋지 않나요?

무조건 넓히는 것은 위험합니다. 새 글 하나를 만드는 루틴이 기존 콘텐츠 수정, 테마 변경, 배포 설정 변경까지 처리하면 실패 범위가 커집니다. 자동화는 반복적이고 검증 가능한 우회에 강하고, 의미 판단이나 계약 변경은 별도 작업으로 분리하는 편이 안전합니다.

공개 검증이 늦게 반영되면 글을 다시 만들어야 하나요?

아니요. 같은 날짜 글을 다시 만들면 중복 방지 원칙을 깨게 됩니다. 먼저 .next 산출물, PM2 재시작, no-cache 요청 결과를 확인해야 합니다. 파일과 빌드가 맞다면 문제는 런타임 반영이나 캐시일 가능성이 높습니다.

사람이 개입해야 하는 상황은 어떻게 줄일 수 있나요?

단계별 계약을 명확히 하고, 실패 메시지를 조치 가능한 형태로 남기면 개입 횟수는 줄어듭니다. 예를 들어 frontmatter 형식, 필수 섹션, 최소 본문 길이, 목록 페이지 검증 기준을 자동 테스트로 만들면 사람은 애매한 품질 판단보다 실제 계약 변경에 집중할 수 있습니다.

결론

AI 블로그 자동화에서 수동 개입 경계는 자동화를 멈추기 위한 장치가 아니라 안전하게 계속 실행하기 위한 운영 설계입니다. Futory의 Next.js Markdown 루틴은 새 파일 하나만 만들고, 정해진 테스트를 통과하고, 빌드 산출물과 공개 페이지를 확인하는 작은 단계를 지킬 때 가장 안정적입니다.

바이브코딩은 빠른 시도와 배포를 장점으로 삼지만, 빠름은 기준이 있을 때만 반복 가능합니다. 자동화가 할 수 있는 우회는 조용히 처리하고, 콘텐츠 계약이나 배포 계약이 깨지는 지점에서는 멈추어 정확히 보고하는 것. 이 경계를 지키면 Futory의 평일 발행은 사람의 상시 감시 없이도 예측 가능한 리듬으로 운영될 수 있습니다.