자동 게시 전 본문 재검사, 1인 개발자가 잡은 경계

게시 직전에도 한 번 더 보는 이유

자동 게시를 다루다 보면 작성이 끝난 시점과 외부에 노출되는 시점 사이에 틈이 생겨요. 이번 기록에서는 그 틈을 줄이기 위해 게시 직전 본문을 다시 검사하는 변경을 다뤘어요.

9월 29일 커밋에서는 본문 재검사와 게시 게이트 관련 변경이 함께 들어갔고, 검사 로직·절차 문서·자동 승인 스크립트·도표 생성기를 포함해 5개 파일이 바뀌었어요. 직접 만들어 보니 중요한 건 검사 항목을 많이 늘리는 일이 아니라, 어느 시점에 무엇을 확인할지 분명히 나누는 일이었어요.

초안 생성→게시 직전 재검사→게시 처리

작성과 게시를 같은 일로 보지 않기

초안이 만들어졌다고 해서 그대로 게시 가능한 상태라고 볼 수는 없어요. 중간에 입력이 바뀌거나, 후속 단계가 다른 본문을 넘길 수도 있기 때문이에요. 그래서 흐름을 세 단계로 분리했어요.

1. 본문을 준비해요.
2. 게시 직전에 다시 검사해요.
3. 조건을 통과한 본문만 게시 처리로 넘겨요.

적용해 봤더니 이 분리는 오류를 특정 단계에 묶어 보기에 좋았어요. 문제가 생겼을 때 “자동 게시가 이상하다”라고 넓게 추적하는 대신, 작성물인지 재검사인지 게시 처리인지부터 확인할 수 있기 때문이에요.

이번 변경에는 017과 018 번호의 게시 관련 마이그레이션도 포함됐어요. 번호 자체가 품질을 보장하진 않지만, 변경 단위를 추적하는 기준으로는 충분히 쓸모가 있었어요. 테스트해 보면 검사 규칙은 작성 단계와 게시 직전 단계에서 같은 결과를 내야 해요. 둘 중 한쪽만 통과한다면 규칙보다 연결 방식부터 살펴볼 차례예요.

자동화는 기록을 남겨야 이어집니다

최근 7일 기록에는 관련 작업을 포함해 19건의 커밋이 남아 있어요. 이 숫자가 작업량이나 성과를 뜻하지는 않아요. 다만 작은 변경을 나눠 남기면, 나중에 어떤 결정이 어떤 파일과 연결됐는지 되짚을 수 있어요.

돌려 보니 자동화는 한 번의 실행보다 다음 점검을 위한 흔적이 더 중요했어요. 절차 문서와 검사 로직을 함께 바꾼 이유도 여기에 있어요. 구현만 남으면 운영 흐름이 흐려지고, 문서만 남으면 실제 동작과 멀어질 수 있어요.

• ✓작성 단계 분리
• ✓게시 직전 검사
• ✓변경 기록 추적

라이프케어로그는 플랜씨, 플랜비, 플랜엘, 플랜티처럼 서로 다른 문제를 다루는 제품을 만들고 있어요. 제품이 달라도 콘텐츠를 다루는 과정에서는 입력과 출력 사이의 확인 지점을 분명히 두는 습관이 계속 필요해요.