AI 블로그 운영 로그를 다음 개선으로 연결하는 루틴

요약

AI와 함께 블로그를 운영하면 글 작성, 검증, 배포를 빠르게 자동화할 수 있습니다. 하지만 자동화가 오래 유지되려면 매일의 실행 결과가 사라지지 않고 다음 개선으로 이어져야 합니다. Futory는 Next.js Markdown 파일을 추가하고, npm run test:theme, npm run test:content, npm run build를 통과한 뒤, 호스트의 /opt/wordblog에 동기화하고 PM2/Nginx를 통해 공개 URL을 확인하는 흐름을 갖고 있습니다. 이 과정에서 남는 로그는 단순한 성공/실패 기록이 아니라 블로그 운영의 방향을 잡아주는 데이터입니다.

운영 로그를 잘 읽으면 어떤 글감이 반복되는지, 어떤 검증 조건이 자주 실패하는지, 어떤 배포 단계가 느린지, 공개 확인에서 어떤 문제가 생기는지 알 수 있습니다. 이 글은 Futory 운영 맥락에서 cron 실행 결과와 배포 로그를 어떻게 정리하고, 다음 콘텐츠와 자동화 개선으로 연결할 수 있는지 설명합니다. 목표는 “오늘 글이 올라갔다”에서 끝나는 것이 아니라 “오늘의 운영 경험이 내일의 더 안정적인 시스템으로 남는 것”입니다.

운영 로그를 글감으로 보는 이유

자동 게시 cron은 매일 같은 시간대에 실행되지만 매번 완전히 같은 일을 하지는 않습니다. KST 기준 날짜를 계산하고, 그날의 랜덤 게시 시간을 고르고, 이미 오늘 날짜의 글이 있는지 확인합니다. 선택된 시간이 아니면 건너뛰고, 이미 게시된 글이 있으면 중복을 막습니다. 선택된 시간이라면 새 글을 만들고 검증과 빌드, 동기화, PM2 재시작, 공개 URL 확인까지 진행합니다.

이 흐름은 그대로 하나의 운영 스토리입니다. 예를 들어 특정 날에 test:content가 frontmatter 누락을 잡았다면 “콘텐츠 검증이 자동 게시를 어떻게 보호하는가”라는 글감이 됩니다. test:theme가 다크/라이트 모드 보존을 확인했다면 “콘텐츠 배포에서도 UI 회귀 테스트가 필요한 이유”를 설명할 수 있습니다. 공개 URL 확인이 늦게 성공했다면 PM2 재시작 후 부팅 대기와 재시도 로직을 다룰 수 있습니다.

AI 개발에서 중요한 것은 결과만이 아니라 판단 과정입니다. 어떤 조건 때문에 배포를 멈췄는지, 어떤 기준을 통과했기 때문에 공개했다고 말할 수 있는지 기록하면 독자는 추상적인 자동화 이야기가 아니라 실제 운영자의 기준을 볼 수 있습니다.

Futory에 맞는 로그 정리 기준

날짜와 시간 게이트

가장 먼저 남겨야 할 것은 KST 기준 날짜와 선택된 게시 시간입니다. 서버 cron은 UTC 기준으로 실행될 수 있지만, 콘텐츠 운영은 독자가 보는 날짜와 맞아야 합니다. 그래서 Asia/Seoul 기준 현재 시간을 계산하고, random.seed(YYYY-MM-DD)로 오늘의 게시 시간을 정하는 방식은 중요한 운영 조건입니다.

로그에는 현재 KST 시간, 선택된 시간, 실행 여부가 분명히 남아야 합니다. 선택 시간이 아니라면 SKIP: not selected hour처럼 짧게 끝나는 것이 좋습니다. 이미 오늘 날짜의 글이 있다면 SKIP: already published today로 중복 게시를 막았다는 사실만 남기면 충분합니다. 이런 짧은 스킵 로그도 운영 품질을 보여줍니다. 아무것도 하지 않은 것이 아니라, 하지 않아야 할 일을 정확히 하지 않은 결과이기 때문입니다.

검증 단계와 실패 원인

새 글을 작성한 뒤에는 검증 로그가 핵심입니다. Futory에서는 콘텐츠만 바꿔도 npm run test:theme를 먼저 확인해야 합니다. 기존 다크/라이트 모드 기능은 components/ThemeToggle.tsx, app/theme-init.tsx, CSS의 data-theme 변수 흐름에 의존하므로, 글 배포 과정에서 해당 기능이 사라지지 않았는지 확인하는 절차가 필요합니다.

npm run test:content는 frontmatter, 필수 섹션, 길이, 카테고리, 태그 같은 콘텐츠 기준을 확인합니다. 자동 작성된 글은 겉으로는 자연스러워도 운영 규칙을 빠뜨릴 수 있습니다. 이 검증이 실패했다면 로그에는 “왜 실패했는가”와 “무엇을 고쳤는가”가 남아야 합니다. 단순히 재시도했다고 적는 것보다 누락된 ## 자주 묻는 질문을 추가했다거나, 날짜 형식을 수정했다는 식의 구체적인 기록이 다음 개선에 도움이 됩니다.

배포와 공개 확인

빌드가 성공하면 스테이징과 라이브 경로의 차이를 의식해야 합니다. 컨테이너의 /opt/data/wordblog_next_staging은 호스트에서 /root/hermes-agent/data/wordblog_next_staging로 보이고, 실제 라이브 앱은 호스트 /opt/wordblog에서 동작합니다. 따라서 파일을 동기화할 때 .git, node_modules, .next, .env를 보존하거나 제외하는 기준이 중요합니다.

호스트에서 의존성을 확인하고, 콘텐츠 검증과 테마 검증, 빌드를 다시 실행한 뒤 pm2 restart futory-wordblog --update-env를 수행해야 합니다. 마지막으로 https://futory.oig.kr/posts와 새 글 URL이 HTTP 200을 반환하고 오늘 날짜가 보이는지 확인해야 성공이라고 말할 수 있습니다. 이 공개 확인 결과는 독자 관점의 최종 검증이므로 운영 로그에서 가장 중요한 줄 중 하나입니다.

로그를 다음 자동화 개선으로 바꾸는 방법

운영 로그를 모아 보면 반복되는 패턴이 보입니다. 예를 들어 빌드는 성공하지만 공개 URL 확인에서 가끔 늦게 응답한다면 PM2 재시작 후 최대 20초 정도 재시도하는 로직을 강화할 수 있습니다. 특정 섹션 누락이 자주 발생한다면 콘텐츠 생성 프롬프트보다 검증 스크립트의 오류 메시지를 더 구체적으로 바꾸는 편이 좋습니다. 글 제목이 기존 글과 비슷해진다면 파일 목록을 읽고 중복 주제를 더 적극적으로 피하는 규칙을 추가할 수 있습니다.

이 과정은 바이브코딩의 장점을 잘 보여줍니다. 처음부터 완벽한 운영 시스템을 설계하는 대신, 실제 실행 결과를 보고 작은 규칙을 추가합니다. 실패한 배포는 낭비가 아니라 다음 자동화 조건의 재료가 됩니다. 성공한 배포도 마찬가지입니다. 어떤 조건을 통과했기 때문에 성공했는지 알면, 그 조건을 유지하거나 더 명확하게 만들 수 있습니다.

콘텐츠 운영에서도 같은 방식이 유효합니다. 오늘의 글이 PM2/Nginx 공개 확인을 다뤘다면 다음 글은 배포 후 캐시와 브라우저 새로고침 문제를 다룰 수 있습니다. 오늘의 로그가 중복 게시 방지를 보여줬다면 다음 글은 시간대와 날짜 기준을 더 자세히 풀 수 있습니다. 운영 기록은 단순한 내부 메모가 아니라 독자에게 실제로 도움이 되는 연재의 원천입니다.

자주 묻는 질문

성공 로그만 남기면 충분한가요?

충분하지 않습니다. 성공 여부는 중요하지만, 어떤 검증을 통과했는지와 어떤 공개 URL을 확인했는지가 함께 남아야 합니다. 그래야 나중에 문제가 생겼을 때 “정말 배포가 되었는가”, “빌드만 성공한 것인가”, “공개 도메인까지 확인했는가”를 구분할 수 있습니다.

실패 로그를 공개 글감으로 써도 되나요?

가능합니다. 다만 내부 비밀값, 서버 접근 정보, 민감한 경로는 조심해야 합니다. 대신 실패 원인의 유형과 해결 기준을 중심으로 정리하면 독자에게 도움이 됩니다. 예를 들어 .env 값 자체가 아니라 “빌드 시점 환경변수가 필요한 코드 구조를 런타임 초기화로 바꿨다”는 식으로 설명할 수 있습니다.

AI가 로그를 읽고 다음 글감을 정하게 해도 괜찮나요?

괜찮지만 검증 기준이 함께 있어야 합니다. 기존 content/posts/*.md를 읽어 중복 주제를 피하고, 바이브코딩 카테고리 안에서 AI 개발, 자동화, 배포, 운영이라는 방향을 유지해야 합니다. AI가 제안한 주제라도 Futory의 운영 맥락과 연결되지 않으면 다시 조정하는 편이 좋습니다.

운영 로그가 너무 많아지면 어떻게 관리하나요?

모든 줄을 사람이 읽을 필요는 없습니다. 최종 상태, 실패 원인, 수정 내용, 공개 확인 URL처럼 의사결정에 필요한 항목만 요약하면 됩니다. 자세한 빌드 출력은 필요할 때 확인하고, 블로그 글에는 독자가 배울 수 있는 기준과 판단만 남기는 방식이 효율적입니다.

결론

Futory의 자동 게시 루틴은 글 하나를 만드는 작업이면서 동시에 작은 배포를 수행하는 운영 흐름입니다. KST 시간 게이트, 중복 게시 방지, Markdown 콘텐츠 검증, 테마 보존, Next.js 빌드, 호스트 동기화, PM2 재시작, 공개 URL 확인이 모두 연결되어 있습니다. 이 과정에서 생기는 로그를 잘 정리하면 자동화의 신뢰도를 높이고, 다음 콘텐츠의 방향도 더 선명하게 만들 수 있습니다.

AI와 함께 만들고, 자동화하고, 운영하는 기록은 결과물만 쌓는 일이 아닙니다. 매일의 실행 결과를 읽고, 실패를 규칙으로 바꾸고, 성공을 기준으로 남기는 과정까지 포함합니다. 운영 로그를 다음 개선과 다음 글감으로 연결할 때, 블로그는 단순한 글 모음이 아니라 실제 시스템을 키워가는 기록이 됩니다.