댄싱바이트 블로그의 자동 발행 방식을 다시 확인했다. 나는 미리 만들어둔 글을 큐에서 하나씩 꺼내는 방식인지 궁금했다. 실제로는 달랐다. 맥에서 평일 오전 10시마다 작업이 실행됐고, 그때 AI가 새 글을 써서 바로 발행하고 있었다.
자동화는 돌아가고 있었다. 다만 내가 원하는 문장으로 글이 나오는지는 따로 확인해야 했다. 그래서 기존 글을 다시 읽고, 글을 만드는 단계와 공개하는 단계를 나눴다.
원고를 먼저 읽을 수 있게 했다
예전에는 생성한 글이 빌드를 통과하면 곧바로 배포됐다. 빌드 검사는 파일 형식과 사이트가 만들어지는지를 확인하는 데 필요하다. 하지만 비유가 과한지, 문장이 어색한지, 인용한 숫자가 정확한지는 확인해주지 않는다.
지금은 검토를 마친 원고를 발행 큐에 넣는다. 자동 작업은 화요일과 목요일 오전 10시에 실행되고, 시간이 된 글을 한 편씩 공개한다. 원고가 없으면 새 글을 즉석에서 쓰지 않고 기다린다.
일정을 채우려고 글을 쓰는 부담도 줄일 수 있다. 기술 글과 내가 겪은 이야기를 미리 읽고 배치할 수 있고, 같은 주제가 연달아 나오는지도 확인할 수 있다.
발행했다는 기록도 확인했다
기존 실행 스크립트에는 실패해도 마지막에 정상 종료를 반환하는 문제가 있었다. 모델 사용 한도나 인증 때문에 글을 쓰지 못해도, 예약 작업의 종료 상태만 보면 성공으로 보일 수 있었다.
이 부분을 고치고 공개 주소에서 제목과 본문이 실제로 나오는지 확인하도록 했다. 저장소에 글이 들어간 것, 배포가 시작된 것, 독자가 글을 읽을 수 있는 것은 각각 다른 상태다.
중간에 실패한 글은 처리 중인 상태로 남긴다. 다음 실행에서는 그 글의 결과부터 확인한다. 완료 여부를 모르는 채 다음 글로 넘어가지 않도록 한 것이다.
자동화가 맡을 일을 정했다
자동 발행이 잘되는지 보려면 예약 시간이 맞는지만 확인해서는 부족했다. 어떤 글이 공개되는지, 실패를 알아볼 수 있는지, 아직 공개하지 않을 원고가 섞이지 않는지도 봐야 했다.
이번에는 원고를 읽고 고르는 일과 정해진 시간에 공개하는 일을 나눴다. 글의 내용은 미리 검토하고, 발행 시각과 반복 작업은 자동화에 맡긴다. 지금 내 블로그에는 이 방식이 더 맞는다.