발행 자동화를 스케줄러로 무인 실행하기

발행 스크립트를 손으로 실행하면 자동화의 절반만 된 것입니다. 정해진 시각에 사람 개입 없이 도는 스케줄러가 있어야 완성입니다. 이 글은 발행 워커를 주기적으로 무인 실행하도록 구성하면서 지킨 원칙과 겪은 함정을 정리한 기록입니다.

무인 실행의 기본 구조

스케줄러가 몇 분마다 워커를 깨웁니다. 워커는 매번 발행 대기열을 확인하고, 발행 시각이 지난 글이 있으면 처리하고, 없으면 조용히 끝냅니다. 핵심은 스케줄러 자체가 판단하지 않는다는 점입니다. 스케줄러는 그저 주기적으로 트리거만 하고, 무엇을 발행할지는 대기열이 결정합니다. 이렇게 분리하면 발행 규칙을 바꿀 때 스케줄러를 건드릴 필요가 없습니다.

이 구조에서 스케줄러의 주기는 정밀할 필요가 없습니다. 발행 시각을 스케줄러가 아니라 대기열의 각 글이 갖고 있기 때문입니다. 스케줄러가 10분마다 돌더라도, 발행 시각이 지난 글만 처리하므로 실제 발행은 예약 시각에 가깝게 일어납니다. 주기를 너무 짧게 잡으면 낭비고, 너무 길면 발행이 밀리니 적당한 간격이면 됩니다.

every N minutes:
  scheduler trigger
    -> check queue
       empty -> exit quietly (no log)
       has   -> run worker -> publish -> report

조용한 실패를 만들지 마라

무인 실행에서 가장 위험한 건 조용히 실패하는 것입니다. 스케줄러가 도는데 아무 일도 안 일어나면, 정상인지 고장인지 알 수가 없습니다. 그래서 발행할 게 없을 때는 아예 출력을 남기지 않아 무음으로 처리하되, 뭔가 시도했는데 안 되면 반드시 이유를 남기게 했습니다. 대시보드가 응답하지 않거나, 발행에 필요한 브라우저가 꺼져 있으면 그 사실을 로그에 찍습니다.

이렇게 하면 로그가 깔끔하면서도 진단 가능합니다. 아무 문제 없으면 로그가 비어 있고, 문제가 있을 때만 그 내용이 남습니다.

실행 전 조건을 먼저 확인한다

워커를 무작정 실행하기 전에, 발행에 필요한 조건이 갖춰졌는지 값싸게 먼저 확인합니다. 대기열에 처리할 글이 있는지, 브라우저 자동화라면 브라우저가 살아 있는지를 봅니다. 조건이 안 되면 무거운 워커를 띄우지 않고 짧은 로그만 남기고 끝냅니다. 이 사전 점검이 불필요한 실행과 그로 인한 오류를 크게 줄여줍니다.

pre-check order
  1) any post due in the queue?  no -> exit (silent)
  2) dashboard responding?       no -> log and exit
  3) browser alive?              no -> log and exit
  4) all pass -> run worker

무인 실행의 전제 조건

스케줄러가 돌아도 발행이 성립하려면 몇 가지 전제가 필요합니다. 대기열을 관리하는 시스템이 떠 있어야 하고, 브라우저 자동화 방식이라면 로그인된 브라우저가 살아 있어야 합니다. 스케줄러만 자동 시작되게 해두고 나머지는 꺼져 있으면, 스케줄러는 매번 조건 미충족 로그만 남기고 건너뜁니다. 그래서 필요한 구성요소를 함께 자동 시작에 넣을지 결정해야 합니다.

무인 실행은 편리하지만, 무인이기 때문에 문제가 조용히 쌓입니다. 그래서 실패를 눈에 띄게 만드는 설계가 자동화의 성패를 가릅니다. 다음 글에서는 이렇게 발행되는 글의 SEO 점수를 발행 전에 코드로 미리 점검하는 방법을 다루겠습니다.