매일 도는 작업은 있었습니다
제 짧은 영상 파이프라인에는 매일 저녁 스케줄러가 부르는 게시 스크립트가 있었습니다. macOS의 launchd가 정해진 시각에 daily_publish를 실행하고, daily_publish는 발행 큐에서 항목을 꺼내 올립니다. 이 부분은 자동이었습니다.
큐를 채우는 쪽은 따로 있었습니다. 웹앱 결과 페이지를 순서대로 캡처해 큐에 넣는 rotation.py입니다. 이 엔진은 이미 만들어 두었고, 순회 위치도 디스크의 파일에 기록하게 해 두었습니다. 그런데 스케줄러 설정을 다시 보니 launchd가 부르는 건 daily_publish 하나뿐이었습니다. 생성 단계는 스케줄 어디에도 없었습니다.
당신의 자동화에서 스케줄러가 실제로 부르는 진입점은 무엇이고, 그 진입점이 소비하는 입력은 누가 만듭니까?
'게시가 자동'이라는 말과 '파이프라인이 자동'이라는 말은 다릅니다. 게시만 예약돼 있으면, 큐를 채우는 일은 결국 사람이나 열려 있는 에이전트 세션의 몫으로 남습니다. 그 사람이 손을 놓는 날부터 큐는 줄어들기만 합니다.
왜 눈에 잘 띄지 않았나
큐에 쌓여 있던 백로그가 쿠션 역할을 했습니다. 생성이 멈춰도 게시는 한동안 정상적으로 돌고, 스케줄러 쪽에서 보면 매일 성공입니다. 게시 작업의 성공 여부만 보고 있으면, 입력을 만드는 쪽이 예약돼 있지 않다는 사실은 드러나지 않습니다. 쿠션이 다 떨어지는 날에야 드러나는 구조였습니다.
당신이라면 게시 작업 안에 생성을 끼워 넣겠습니까, 아니면 둘을 감싸는 바깥 스크립트를 새로 두겠습니까?
스크립트 하나로 묶고, 스케줄러가 부르는 대상을 바꿨습니다
저는 바깥에 얇은 스크립트를 하나 두는 쪽을 골랐습니다. engine/autopilot.sh는 22줄입니다. 하는 일은 두 가지입니다. 먼저 rotation.py로 그날의 큐 항목을 생성하고, 그다음 daily_publish로 게시합니다. 기존 두 스크립트는 건드리지 않았습니다.
그리고 launchd plist에서 실행 대상을 daily_publish에서 autopilot으로 바꿨습니다. plist 변경은 2줄입니다. 실행 시각은 18:30입니다. 같은 커밋에서 .gitignore에도 한 줄이 추가됐습니다.
로테이션은 매일 새 테마를 만들어 내기 때문에, 이 구조에서는 큐를 채우려고 세션을 열거나 사람이 개입할 필요가 없습니다. 커밋 메모에 적은 '개입/세션 불필요'가 이 뜻입니다.
검증은 실제 게시 없이 했습니다
무인으로 돌릴 스크립트를 처음부터 실제 게시로 시험하고 싶지는 않았습니다. 그래서 autopilot.sh에 DRY=1 모드를 넣었습니다. 확인한 건 세 가지입니다.
- DRY 모드에서 생성부터 게시까지 체인이 끝까지 이어지는지
- 크롬 캡처가 clean-env에서도 되는지
- 큐에 백로그 쿠션이 남아 있는지
두 번째 항목이 launchd에서 특히 신경 쓰이는 부분입니다. launchd가 띄우는 프로세스는 제 터미널 셸과 환경이 다릅니다. 터미널에서 잘 되던 캡처가 스케줄러 아래에서는 실패할 수 있으니, 셸 환경을 비운 상태에서 캡처가 되는지 따로 확인했습니다.
자가진단 체크리스트
- 스케줄러 설정 파일을 열어, 실제로 실행되는 진입점이 파이프라인의 처음부터 끝까지를 부르는지 확인했습니까?
- 소비 단계(게시)가 성공하는 동안 생산 단계(생성)가 멈춰 있어도 알아챌 수 있는 신호가 있습니까?
- 무인 진입점을 셸 환경 없이, 그리고 실제 부작용 없는 드라이런으로 끝까지 돌려 봤습니까?
솔직한 부분
이 커밋 시점에 확인한 건 DRY 체인과 clean-env 캡처, 그리고 백로그가 남아 있다는 사실까지입니다. 18:30에 launchd가 실제로 autopilot을 불러 무인으로 게시까지 끝낸 결과는 이 기록에 없습니다. 커밋 제목에는 생성→게시→분석이라고 적었지만, 본문에 적힌 건 생성과 게시뿐이라 분석 단계가 어떻게 붙어 있는지는 여기서 말할 수 없습니다. 생성이 실패한 날 게시 단계가 어떻게 동작하는지도 이 기록만으로는 알 수 없습니다. 백로그 쿠션이 그런 날을 메워 주리라 기대하고는 있지만, 확인한 것은 아닙니다.