자동 게시 전 본문 재검사, 5개 파일로 연결한 기록

자동 게시 흐름을 만들 때 가장 오래 붙잡게 되는 지점은 생성이 아니라 마지막 확인이었어요. 글이 만들어졌다는 사실과, 게시 가능한 본문이라는 판단은 서로 다른 일이기 때문이에요. 라이프케어로그의 콘텐츠 자동화 작업에서도 이 경계를 코드와 절차로 나눠 보기로 했어요.

최근 7일 동안의 git 기록에는 19건의 변경이 남아 있어요. 그중 9월 29일 커밋에서는 게시 직전 본문 재검사와 자동 생성·게시 배선, 도표·썸네일 생성 관련 작업이 함께 변경됐어요. 변경 파일은 SQL migration 2개와 문서, 자동 승인 스크립트, 그림 생성 스크립트를 포함해 5개였어요. 한 번의 자동화라고 뭉뚱그리기보다, 어느 단계가 무엇을 맡는지 드러내는 편이 나중에 확인하기 쉬웠어요.

초안 생성→게시 직전 본문 재검사→게시 흐름 연결

직접 만들어 보니 재검사는 생성 단계에 섞어 두기보다 게시 직전에 두는 편이 읽기 쉬웠어요. 생성기는 초안을 만들고, 검사기는 발행 기준을 다시 확인하고, 게시 단계는 통과한 결과를 받아 처리하는 식이에요. 각 단계가 실패했을 때 어디를 봐야 하는지도 자연스럽게 갈라졌어요.

적용해 봤더니 SQL migration을 2개로 분리한 기록도 작업 의도를 남기는 데 도움이 됐어요. 하나는 게시 전 텍스트 확인을 위한 변경이고, 다른 하나는 게시 게이트 보완을 위한 변경이에요. 파일 수를 줄이는 것보다, 변경 이유가 서로 다른 경우 경계를 보이는 편이 운영 기록을 다시 읽을 때 편했어요.

• ✓생성 책임
• ✓검사 책임
• ✓게시 책임

테스트해 보면 자동화의 빈틈은 정상 흐름보다 예외 흐름에서 먼저 보여요. 그래서 본문 검사 결과가 게시 단계까지 이어지는지, 생성된 시각 요소가 글 흐름에 맞는지, 수동 절차 문서와 코드의 역할이 어긋나지 않는지를 따로 살폈어요. 이번 기록에는 티스토리 도표와 썸네일 생성도 함께 포함됐지만, 생성 자체가 발행 판단을 대신하도록 두지는 않았어요.

돌려 보니 1인 개발에서는 “자동”이라는 말보다 확인 가능한 경계가 더 중요했어요. 플랜씨(plan-c)처럼 로그인 없이 쓰는 도구를 운영하든, 콘텐츠 자동화를 다루든 독자가 만나는 결과물 앞에는 마지막 판단 지점이 필요해요. 다음 작업에서도 생성, 검사, 게시의 책임을 한 줄로 합치기보다 기록과 확인이 가능한 순서로 유지하려고 해요.