자동화 레인 편입 전 확인할 것

2026-10-03 기준으로 새 실험 레인은 그림자 실행 7회차에서 처음 통과한 뒤 3개 순환에 편입했고, 담당 날짜가 아니면 모델 호출 전에 실행을 끝내도록 구성했어요. 핵심은 새 레인이 돌아가는지 여부와 기존 레인의 실행 조건을 바꾸지 않는지를 별개의 검증 항목으로 다룬 데 있어요.

새 레인을 바로 정식 순환에 넣기 어려운 이유

자동화 레인을 추가하는 일은 작업 하나를 더 예약하는 일처럼 보이지만, 실제 위험은 공용 순환 규칙에 있어요. 날짜에 따라 담당 레인을 고르는 구조라면 새 항목 하나가 들어오는 순간 기존 레인의 담당일도 함께 달라져요.

이번 기록에서 실험 레인은 그림자 실행 7회차에 처음 게이트를 통과한 뒤에야 순환에 들어갔어요. 통과 전에 순환 목록부터 바꾸면, 아직 검증되지 않은 레인이 실제 작업을 차지하거나 기존 레인을 예정보다 건너뛸 수 있어요.

그림자 통과는 정식 결과와 같지 않아요. 여기서는 새 레인이 정식 발행을 시작했다는 뜻이 아니라, 정식 순환에 넣을지 판단할 최소 신호가 생겼다는 뜻으로만 사용했어요.

이 구분을 빼면 “통과”라는 한 단어가 검증 성공과 운영 전환을 모두 가리켜, 장애가 생겼을 때 어느 단계가 잘못됐는지 찾기 어려워져요.

표의 수치는 2026-10-03 작업 기록 기준이에요. 특히 결과 대기가 0이라는 값은 처리량을 뜻하지 않아요. 관측 대상 중 결론이 나지 않은 항목이 없었다는 상탯값이므로, 통과 수와 섞어 성공률처럼 읽으면 안 돼요.

담당이 아닐 때 조기 종료하는 구조

안전한 순환은 “오늘 실행할 레인”을 고르는 조건과 “선택되지 않은 레인이 무엇을 하지 않아야 하는지”를 함께 정의해야 해요. 이 기록에서는 날짜의 UTC 서수를 순환 길이로 나눈 나머지로 담당 레인을 정했고, 담당이 아닌 레인은 모델을 부르기 전에 종료해요.

이 순서가 중요한 이유는 모델 호출 뒤의 건너뛰기가 비용과 기록을 남기기 때문이에요. 소재를 읽고 초안을 만들기 시작한 뒤에야 비담당임을 발견하면, 최종 결과가 없더라도 사용량·로그·재시도 판단에는 실행 흔적이 남아요.

개념을 단순화하면 흐름은 아래처럼 만들 수 있어요. 실제 시스템의 명령이나 경로가 아니라, 선택과 종료의 경계를 보여 주는 의사 코드예요.

lane = rotation[utc_day_ordinal % rotation.length]

if lane != current_lane:
    stop_before_model_call()

run_authoring_flow()

여기서 조기 종료는 실패를 숨기는 장치가 아니에요. 담당 외 레인이 실행되지 않는 것이 정상이라는 사실을 명시하는 장치예요. 그래서 운영 화면이나 알림에서도 “실패”와 “이번 순서 아님”을 구별해야 해요.

기록에는 순환 변경 전에 실행된 작업이 있더라도 영향이 없다고 적혀 있어요. 변경 전에는 새 레인이 순환에 없어서 선택되지 않은 레인이었고, 따라서 조기 종료 경로로 끝났기 때문이에요. 순환 목록을 수정하는 배포와 예약 작업의 실행 시점이 엇갈려도, 이 경계가 있으면 새 레인을 억지로 실행하지 않아요.

일정 표현 자체는 도구마다 다를 수 있어요. 예를 들어 GitHub Actions의 schedule은 POSIX cron 문법을 사용하지만, 여기서는 문법보다 담당 판정이 모델 호출보다 앞에 있다는 점이 더 중요해요. GitHub Actions의 예약 실행 문서도 일정이 이벤트 조건이라는 점을 설명해요.

편입 뒤에도 분리해서 봐야 할 관측 지표

새 레인을 순환에 넣은 뒤에는 전체 성공 수만 보면 원인을 놓치기 쉬워요. 이번 기록에서는 실험 레인이 생성한 공개 실험 자료를 포함한 브랜치를 별도 레인으로 세어, 일반 작업과 섞이지 않게 했어요.

이 분리는 지표를 좋아 보이게 만들기 위한 분류가 아니에요. 새 레인의 실패가 소재 품질 때문인지, 순환 선택 때문인지, 게이트의 검증 조건 때문인지 판단하려면 출발점이 다른 작업을 같은 묶음으로 계산하지 않아야 해요.

관측 항목은 적어도 세 갈래로 나누는 편이 안전해요. 선택 단계에서는 담당일이 맞았는지, 실행 단계에서는 모델 호출 전 조기 종료가 지켜졌는지, 결과 단계에서는 제출·통과·차단·대기의 수가 각각 무엇인지 봐야 해요. 같은 “실행됨”이라는 표시는 이 세 정보를 대신하지 못해요.

새 레인의 편입 조건도 숫자 하나로 고정하기보다, 관측 범위를 먼저 정하는 편이 나아요. 이번 작업 기록은 14일 창에서 제출·게이트 통과·차단·대기를 함께 제시했지만, 이 숫자만으로 다음 변경의 안전성을 보장하지는 않아요. 순환 순서가 다시 바뀌거나, 레인이 만드는 산출물의 성격이 달라지면 분리 규칙과 관측 창도 다시 확인해야 해요.

개발자가 참고할 수 있는 판단 기준은 간단해요. 새 자동화를 넣기 전에는 그림자 결과와 정식 전환을 분리하고, 넣은 뒤에는 비담당 작업이 모델 호출 전에 끝나는지 확인하며, 지표에서는 새 레인의 결과를 기존 레인과 따로 읽어야 해요. 이 세 경계가 있으면 순환 목록 변경이 단순한 일정 수정이 아니라 검증 가능한 운영 변경이 돼요.

관련 글

• 자동 저작 전 Git 사본 동기화