Cron 페이스를 다시 잡은 하루

cover

크론은 “돌고 있다”는 사실만으로 충분하지 않다. 오늘 다시 확인한 것은 더 단순했다. 자동화에서 중요한 것은 실행 주기가 아니라, 한 번의 실행이 무엇을 끝내는지와 그 실행들이 어느 속도로 누적되는지다.

문제는 멈춤이 아니라 너무 느린 전진이었다

처음에는 TouchDesigner 공식 문서 처리 크론이 살아 있다고 생각했다. 정해진 시간마다 실행되고 있었고, 로그도 남고 있었다. 하지만 실제 진척을 들여다보니 구조가 맞지 않았다. 목표는 한 문서를 붙잡고, 그 문서에서 필요한 파생 노트를 완성한 뒤, 다음 문서로 넘어가는 흐름이어야 했다. 그런데 실제 운영은 임의의 한 건을 보수하는 방식에 가까웠다. 매번 무언가를 고치기는 하지만, 특정 소스 문서 하나가 “완료”로 잠기는 순간이 없었다.

더 큰 문제는 규모였다. 매니페스트에서 derivedNotes가 달린 공식 문서 레코드는 1,122건이었다. 당시 설정대로라면 2시간마다 한 건씩 처리한다. 계산하면 2,244시간, 약 93.5일이다. 대략 3개월 동안 크론이 성실하게 돌아야 겨우 한 바퀴를 돈다는 뜻이다. 자동화가 게으른 것이 아니라, 페이스 설계가 백로그의 크기와 맞지 않았던 셈이다.

결정: 진행 단위와 진행 속도를 분리했다

이날의 결정은 크론을 더 자주 돌리는 것만이 아니었다. 핵심은 두 질문을 분리하는 일이었다. 첫째, 이번 실행은 무엇을 “하나의 완료 단위”로 볼 것인가. 둘째, 한 번의 실행에서 어느 정도의 양을 처리할 것인가.

그래서 진행 단위는 source doc 락온으로 잡았다. 한 문서를 선택하면 그 문서의 파생 노트 상태를 끝까지 확인하고, 완료된 것은 완료로 인정하고, 보수가 필요한 것은 제한된 범위 안에서 고친다. 진행 속도는 별도로 배치 처리량으로 조정했다. 첫 검사에서 통과한 항목은 제한 없이 IMMEDIATE_COMPLETE로 넘기고, 실제 수리가 필요한 항목은 한 번에 5건까지만 다룬다. 여기에 wall-clock 20분 캡을 걸어, 크론이 무한히 길어지는 것도 막았다.

적용: 프롬프트와 스케줄을 같이 바꿨다

수정된 운영 메모의 핵심은 다음처럼 정리할 수 있다.

Process unit: lock onto one source doc and resolve its derived-note state.
Throughput: unlimited IMMEDIATE_COMPLETE when the first check passes.
Repair budget: up to 5 REPAIR_NEEDED items per run.
Time budget: stop at a 20-minute wall-clock cap.
Schedule: */30 * * * *

스케줄도 2시간 주기에서 30분 주기로 바뀌었다. 하지만 중요한 것은 /30 *라는 숫자 자체가 아니다. 30분마다 실행하더라도 한 번의 실행이 단지 “랜덤 보수 1건”이면 같은 문제가 반복된다. 반대로 2시간 주기라도 명확한 문서 단위와 배치 처리량이 있으면 훨씬 예측 가능한 운영이 된다. 이번 변경은 주기 조정이 아니라, 완료 판정과 처리량을 함께 설계한 변경이었다.

경로도 공개 글에서는 익명화해 다루기로 했다. 내부에서는 ~/vault/... 아래의 공식 문서와 매니페스트를 기준으로 삼지만, 블로그에 필요한 것은 사적 위치가 아니라 운영 원칙이다. 자동화 회고는 재현 가능한 판단 구조를 남겨야지, 개인 작업 환경의 지도를 노출할 필요는 없다.

회고: 크론은 시계가 아니라 처리 모델이다

오늘의 교훈은 간단하다. 크론의 “진행 단위”와 “진행 속도”는 분리해서 설계해야 한다. 진행 단위는 어떤 일을 완료로 볼지 정한다. 진행 속도는 그 완료 단위를 얼마나 많이, 얼마나 자주 밀어낼지 정한다. 이 둘을 섞어 버리면 크론은 열심히 돌지만 프로젝트는 움직이지 않는 상태가 된다.

특히 AI 에이전트 자동화에서는 이 구분이 더 중요하다. 모델은 매 실행마다 그럴듯한 일을 할 수 있다. 그러나 그 일이 전체 백로그의 어느 위치를 닫았는지, 다음 실행이 무엇을 이어받을 수 있는지, 실패한 항목이 어떻게 다시 배정되는지까지 정해져 있지 않으면 실행 로그만 늘어난다.

그래서 좋은 크론 설계는 “몇 시에 도는가”에서 끝나지 않는다. 무엇을 붙잡고, 무엇을 완료로 인정하고, 무엇을 다음 배치로 넘기며, 어느 시점에 멈출지를 같이 정해야 한다. 오늘 다시 잡은 것은 시간표가 아니라 페이스였다. 그리고 페이스는 결국 자동화가 스스로 앞으로 나아가게 만드는 최소한의 운영 문법이다.