자동 게시 전 본문 재검사 게이트를 만든 빌드로그

자동 게시 흐름은 마지막 단계가 가장 조심스러워요. 초안이 만들어졌다는 사실과, 공개 직전의 본문이 기준을 통과했다는 사실은 다르기 때문이에요. 이번에는 게시 직전 본문 재검사와 관련된 변경 기록을 중심으로, 1인 개발자가 자동화의 끝단을 어떻게 정리했는지 남겨 봐요.

9월 29일 기록에는 게시 전 본문 재검사를 위한 2개 migration, 017과 018이 포함돼 있어요. 같은 변경 묶음에는 자동 생성·게시 배선, 도표와 썸네일 생성 관련 파일도 함께 있었어요. 최근 7일 이력은 모두 23건이지만, 이 글에서는 한 번의 게시 직전 검사를 깊게 보는 편이 더 맞다고 판단했어요.

직접 만들어 보니 자동화는 앞단의 생성 품질만 보면 흐름이 쉽게 단순해져요. 하지만 실제 공개 지점에서는 본문, 게시 대상, 시각 요소처럼 서로 다른 책임이 만나요. 그래서 재검사 단계를 별도로 두면 “생성됨”과 “게시 가능함”을 같은 상태로 다루지 않을 수 있어요.

초안 생성→게시 직전 재검사→게시 배선

적용해 봤더니 중요한 선택은 검사 규칙을 게시 도구 안에만 숨기지 않는 일이었어요. 변경 기록상 검사와 수정은 각각 migration으로 나뉘어 있고, 운영 절차 문서와 생성 스크립트도 함께 바뀌었어요. 파일이 5개 이상 얽힌 변경에서는 한 파일만 읽고 전체 흐름을 판단하기보다, 각 파일이 어느 단계의 책임을 갖는지 나눠 보는 편이 안전해요.

테스트해 보면 재검사 단계는 콘텐츠를 더 많이 만들기 위한 장치가 아니라, 공개 직전의 판단을 한 번 더 분명하게 하는 장치예요. 예를 들어 카드 생성은 카드 생성대로, 본문 검사는 본문 검사대로 결과를 남겨야 나중에 문제가 생겼을 때 출발점을 좁힐 수 있어요. 자동화의 실패를 모두 하나의 “게시 실패”로 묶지 않는 이유도 여기에 있어요.

돌려 보니 배선 변경만큼 운영 절차 문서가 중요했어요. 코드가 어떤 순서로 실행되는지와 사람이 어느 지점에서 확인할 수 있는지는 별개의 정보예요. 이번 기록에는 게시 절차 문서가 함께 수정돼 있어, 구현과 운영 설명이 같은 변경 단위에 남았다는 점이 눈에 띄어요.

라이프케어로그는 플랜씨(plan-c), 플랜비(plan-b), 플랜엘(plan-l), 플랜티(plan-t)를 만드는 과정에서 이런 작은 운영 경계를 계속 다듬고 있어요. 자동화는 버튼을 줄이는 일이기도 하지만, 공개 전에 무엇을 다시 확인할지 정하는 일이기도 해요.