모델이 정상 응답하는데 완성 스케줄의 TCT가 허용 한도를 넘었다면 무엇부터 해야 할까. 재학습을 시작하기 전에 제품 mix가 바뀌었는지, timestamp가 잘못 들어왔는지, 아직 완료되지 않은 lot이 집계에서 빠졌는지 확인해야 한다. 같은 증상에도 필요한 대응은 다르다. 운영의 핵심은 경보를 많이 만드는 일이 아니라 관측한 변화에 맞는 조치를 선택하고 그 결과를 확인하는 일이다.
한 snapshot에서 설비–lot 조합을 순차 선택해 스케줄을 만드는 가상 사례를 이어간다. 이 편에서는 처리 조건이 다른 제품군 P/Q와 반복 재계획을 운영 확장으로 사용한다. 이 글의 경보·재학습·승격 절차는 작성자의 운영 설계 제안이다. 실제 학습이나 현장 운영을 수행한 결과는 아니다. 10편에서 다룬 제약 검사와 fallback을 전제로, 배포된 시스템을 언제 유지하고 바꿀지에 집중한다.
운영 지표에는 분모와 시차가 필요하다
운영 화면은 실행 건강도, 의사결정 양상, 생산 성과를 함께 보여줘야 한다. 실행 건강도는 timeout과 입력 오류, 의사결정 양상은 행동 분포와 guard 개입, 기본 생산 성과는 대상 lot의 makespan·TCT다. 반복 재계획 확장에서는 OTD·WIP·미완료 age도 추가한다. 어느 한 층만 보면 원인을 잘못 짚기 쉽다. 특히 모든 비율을 같은 분모로 만들면 의미가 흐려진다.
| 지표 | 예시 분모·대상 | 해석할 때 확인할 것 |
|---|---|---|
| timeout 비율 | 모델 스케줄 생성을 시도한 전체 계획 요청 | edge별 성공 추론만 세지 않고 전체 생성 마감 위반을 포함 |
| 제안 생성률 | 적용 범위에 들어온 전체 결정 요청 | 입력 오류·호출 생략도 함께 설명 |
| guard 거절률 | 추론 결과가 도착해 검사한 제안 | timeout은 별도 지표로 남김 |
| 최종 fallback 비율 | 적용 범위의 전체 결정 요청 | 요청마다 최종 경로를 한 번 집계 |
| 모델 실행 비율 | 적용 범위의 전체 결정 요청 | 수락된 제안과 실제 예약 성공 구분 |
| 스케줄 makespan·TCT | 원본 snapshot의 고정 대상 lot 전체 | 예상값과 실제값 분리, 전부 완료 전에는 미확정 |
| 제품별 OTD, 운영 확장 | 해당 기간 납기가 도래한 제품별 lot | 미완료·지연 보고·취소 규약 고정 |
한 계획의 edge 선택 여러 번이나 재시도 한 번을 각각 새 요청으로 세면 모델 호출 수와 업무 결정 수가 달라진다. 따라서 plan request ID에 선택 단계 ID와 시도별 기록을 연결하고, 요청 단위 집계와 시도 단위 집계를 분리한다. timeout, guard 거절, 예약 충돌은 같은 요청에서 차례로 발생할 수 있으므로 이벤트 비율을 무작정 더해 100%를 만들지 않는다. 최종 실행 경로와 실패 원인 이력을 별도로 저장한다.
예를 들어 한 시간에 적용 대상 요청 1,000건이 들어왔고 900건에서 제안이 생성되어 810건을 모델 행동으로 실행했다고 가정하자. 제안 생성 후 실행 비율은 90%지만 전체 요청의 모델 실행 비율은 81%다. 이는 설명용 수치다. 성공한 810건만으로 timeout 비율까지 계산하면 시스템이 어려운 요청을 얼마나 처리하지 못했는지 가려진다.
생산 KPI는 생성 응답보다 늦게 확정된다. snapshot 기준의 예상 makespan·TCT는 제안 지표이고, 실제 처리 결과는 대상 lot을 모두 끝낸 뒤 확정한다. 완료된 lot만 합산해 TCT 한도를 지켰다고 표시하지 않는다. 같은 snapshot이 재계획되거나 대상이 변경됐다면 원본 대상과 실제 실행 이력을 연결하고, 겹치는 대상의 TCT를 중복 합산하지 않는다. 반복 재계획에서는 계획별 예측과 실제 공장 성과도 별도 표에 둔다.
makespan 개선과 TCT 악화를 baseline 대비 추정할 때는 같은 평가 조건의 paired 비교가 필요하다. 현장에서 baseline을 동시에 실행할 수 없다면 실제 관측을 곧바로 반사실 개선율로 부르지 않는다. 10편의 제한 적용 설계와 별도 비교 근거를 사용한다.
다음 OTD 예시는 납기 관리가 필요한 반복 재계획 확장에 추가하는 지표다. cohort는 같은 기준으로 묶은 lot 집합이며 여기서는 납기 날짜가 같은 lot을 뜻한다. 날짜 의 OTD를 다음처럼 고정할 수 있다.
는 날짜 에 납기가 도래한 lot, 는 각 lot의 납기, 는 완료 시각이다. 미완료 lot은 로 취급하고, 이면 OTD를 미정의로 표시한다. 납기까지 완료되지 않은 lot은 적시 완료가 아니므로 분모에서 빼지 않는다. 다만 납기가 아직 도래하지 않은 cohort나 완료 정보의 수집이 지연된 cohort를 확정 OTD로 표시하면 안 된다. 관측 중, 데이터 지연, 확정 상태를 나누고 사전에 정한 보고 지연 여유 뒤에 성숙한 cohort로 판정한다.
cycle time을 완료 lot만으로 계산할 때는 오래 남아 있는 lot이 빠지는 편향도 점검한다. 완료 lot의 cycle time 옆에 미완료 WIP의 age와 tail을 둬야 “빠른 lot만 끝내서 평균이 좋아진” 상황을 볼 수 있다. 운영 초기의 “성과 없음”은 0점도 합격도 아니다. 아직 outcome이 없는 상태로 표시하고 관측을 계속한다.
제품 mix 변화와 policy 성능 저하를 구분한다
전체 OTD 하락이 제품별 성능 하락과 같은 뜻은 아니다. 납기 달성이 어려운 Q의 비중이 커지면 P/Q 각각의 OTD가 유지되어도 전체 값이 내려갈 수 있다. 반대로 쉬운 P가 늘면 취약한 Q의 악화가 가려질 수 있다. 제품·부하·고장 조건별 결과와 전체 운영 실적을 함께 본다.
비교용으로 기준 기간의 가중치 를 고정한 지표를 만들 수 있다.
이는 제품·조건별 성과 를 같은 구성비로 비교하는 표준화다. 현재 실제 mix로 계산한 KPI를 대체하지 않으며, 조건별로 충분한 표본이 없으면 비교 자체가 불안정하다. 관측되지 않은 조건을 임의 값으로 채우지 않는다. 표준화도 기록하지 못한 변화까지 제거하거나 인과 효과를 증명하지는 못한다.
drift는 학습·평가 때와 데이터나 시스템 특성이 달라지는 현상이다. 입력 drift가 감지됐다고 반드시 성능이 나빠진 것은 아니다. 반대로 입력 분포가 비슷해도 처리시간이나 고장 메커니즘이 바뀌면 성능이 나빠질 수 있다. 새로운 제품 코드가 나타난 경우와 단순히 P/Q 비중이 바뀐 경우도 구분한다. 전자는 schema·적용 범위 위반일 수 있고 후자는 검증된 범위 안의 변화일 수도 있다.
경보는 관측 창과 해제 조건까지 정의한다
경보 기준에는 비교 기준, 시간창, 최소 요청 수, 지속 조건, 책임자를 넣는다. 희소 요청 구간에서 한 번의 timeout이 큰 비율로 보일 수 있으므로 비율만 보지 않고 건수와 불확실성을 함께 보여준다. 기준 기간은 현행 시스템이나 승인된 bundle의 안정 운영 구간에서 정하고, 주야간·제품 mix 차이가 크면 적절히 층화한다.
hysteresis는 경보를 켜는 조건과 끄는 조건을 다르게 두어 반복 전환을 줄이는 방식이다. 예를 들어 설명용으로 5분 창에서 timeout이 2%를 넘는 상태가 세 번 이어지면 경보를 켜고, 충분한 요청 수가 확보된 창에서 0.5% 미만이 여섯 번 이어질 때 해제하도록 설계할 수 있다. 이 숫자는 권장 기준이 아니다. 실제 한도는 응답 요구와 정상 변동, 오경보 비용으로 정한다.
이런 지속 조건을 모든 장애에 적용하지는 않는다. 금지 action의 실제 실행이나 중복 명령이 확인되면 신규 모델 명령을 즉시 막고 승인된 대체 제어로 전환한다. 일반적인 입력 분포 변화는 조사 경보일 수 있고, 급격한 WIP 증가나 업무 제약 위반은 성능 지표가 성숙하기 전에도 조치할 이유가 된다. 경보를 알리는 일과 자동 제어를 바꾸는 일의 권한도 분리한다.
재학습 전에 원인을 분류한다
아래 운영 runbook은 증상에서 조사·조치·복귀 근거까지 이어지는 절차서다. 운영자가 첫 대응을 고를 수 있어야 하며, 모든 행을 “재학습”으로 끝내지 않는다.
| 관측·trigger | 먼저 확인할 것 | 초기 조치 | 복귀 또는 변경 근거 |
|---|---|---|---|
| feature 단위·결측 급변 | upstream 배포, schema, timestamp | 입력 복구·영향 요청 추적 | replay와 실제 입력 일치 |
| timeout 증가 | 큐 적체, 서버 자원, 외부 호출 | 용량·의존성 복구, fallback | 시간 한도·장애 주입 재검증 |
| guard 거절 증가 | 최신 상태 지연, 자격 변경, 충돌 | 원인별 적용 제한 | 거절 사유 감소와 실행 검증 |
| mix 변화, KPI 유지 | 승인 범위·조건별 성과 | 관측 유지, 평가 보강 | 성숙 cohort의 결과 |
| 조건별 KPI 악화 | 입력 정상 여부, 환경 변화 | 범위 축소와 후보 실험 | 새 조건·기존 조건 비교 |
| 금지 행동·중복 명령 | 실행 경로·예약·request 기록 | 신규 모델 명령 즉시 중단 | 원인 수정과 재발 검사 |
재학습은 입력이 정상인데 새 운영 조건에서 현 policy의 한계가 확인됐을 때 검토하는 대응이다. 먼저 simulator가 변화를 표현할 수 있는지 확인하고, 필요한 데이터와 시나리오를 갱신한다. 잘못된 feature를 학습에 추가하면 오류에 적응하는 모델이 만들어질 뿐이다. 현실 변화인지 데이터 수집 오류인지 분리하는 비용을 재학습 일정에 포함한다.
재학습 trigger에는 날짜만 쓰지 않고 이유를 남긴다. 예를 들어 “Q 부하가 승인 범위를 벗어남”, “처리시간 모델이 실제 관측을 설명하지 못함”, “동일 조건에서 tail 지연 악화”는 각각 학습 분포, 환경 모델, 목적함수나 행동 설계의 검토로 이어진다. 정기 재학습도 후보를 생성하는 일정일 뿐 자동 승격의 근거가 아니다.
후보 생성과 운영 승격은 별도 결정이다
champion은 현재 승인된 bundle, challenger는 이를 대체할 후보를 뜻한다. 후보를 만들기 전에 데이터 기준 시점, training·validation 분리, 선택할 KPI, 허용 손실, 계산 예산을 고정한다. 여러 후보의 test 결과를 보면서 가장 좋은 것을 계속 고르면 test가 사실상 validation으로 바뀐다.
기존 회귀 suite는 알려진 실패의 재발을 막는 데 사용하고, 새 조건의 untouched holdout은 후보 선택 이후 최종 판단에 사용한다. 이미 결과를 보고 수정한 holdout은 새 독립 평가라는 이름을 붙일 수 없다. 새 데이터를 확보하기 어렵다면 그 한계를 기록하고 현장 적용 범위를 보수적으로 제한한다. training seed 여러 개 중 좋은 하나만 운영 근거로 고르는 선택 편향도 06편의 방법으로 다룬다.
승격 보고서는 “새 모델 평균이 높음”보다 넓어야 한다. makespan·TCT의 주판정 가중치는 05편의 계약에서 가져오고, 현재 관측 빈도로 사후에 바꾸어 유리한 평균을 만들지 않는다. 운영 구성이 지속적으로 바뀌었다면 새 목표 분포와 가중치 버전을 정해 champion과 challenger를 둘 다 다시 평가한다. 동등 평균과 기존 비중 평균도 함께 남겨 성능 변화와 구성 변화를 구분한다. 현재 champion, 검증된 fallback, challenger를 같은 조건에서 비교하고 제품별 제약, tail, guard 포함 성과, runtime을 확인한다. 통과한 후보만 10편의 제한 적용 단계로 보낸다. 새 모델이 좋아도 계산·검증·운영 비용에 비해 이득이 작다면 champion을 유지하는 것이 합리적이다.
rollback은 bundle 복구와 WIP 회복을 나눈다
rollback은 이전 weight를 덮어쓰는 작업보다 넓다. graph schema, edge 생성·ID 대응, normalizer, mask, fallback까지 호환되는 묶음을 복원하고 서버가 실제로 그 bundle ID로 응답하는지 확인한다. 최신 schema로 이미 데이터가 바뀌었다면 이전 bundle을 그대로 읽힐 수 있는지부터 확인해야 한다. 호환되지 않으면 검증된 fallback을 유지하면서 복구한다.
물리 시스템의 상태는 파일처럼 되돌아가지 않는다. 문제가 생긴 동안 Q가 많이 쌓였다면 이전 champion도 그 WIP를 평가에서 경험하지 못했을 수 있다. 승인하지 않은 미래 작업 예약의 해제·재계획과 이미 실행 중인 작업의 처리도 구분한다. 실행 장애 해소와 생산 상태 회복을 별도 사건으로 기록한다. 응답시간은 즉시 정상화되어도 납기 cohort와 WIP는 한동안 악화될 수 있다. 회복 상태가 승인 범위 밖이면 현장 책임자가 정한 회복용 규칙과 범위 제한을 따른다.
DeepMind의 공개 산업 제어 사례는 제약과 별도 검증, 기존 제어로 돌아가는 경로의 필요성을 보여준다. 여기서 제시한 재학습·승격·WIP 회복 절차가 그 사례의 검증된 절차라는 뜻은 아니다. DeepMind 공식 사례
운영 책임과 기록을 실제 명령에 연결한다
수동 전환 권한은 “필요하면 담당자 호출”로 두지 않는다. 가상 운영 계약에서는 현장 운영자가 신규 모델 명령 중단과 승인된 fallback 전환을 수행하고, 서비스 담당자가 실행 장애를 조사하며, 모델 담당자가 평가와 후보 생성을 맡도록 정할 수 있다. 재개·확대 승인자는 이들과 협의하되 명시적으로 지정한다. 이미 처리 중인 공정의 중단 권한은 현장 절차에 따른다.
incident log에는 감지 시각, bundle ID, 영향 요청·lot 범위, 실제 실행 행동, 원인 가설, 변경 사항, 수동 개입자와 복귀 근거를 남긴다. 수동 제어 기간은 모델이 만든 결과인 것처럼 집계하지 않는다. 사고를 닫는 조건도 서비스 복구와 생산 회복, 재발 방지 검증으로 구분한다.
이 편의 산출물은 지표 사전, 경보 규칙, 운영 runbook, 재학습·승격 이력이다. 모델을 계속 쓸 근거와 멈출 근거를 같은 문서에서 추적할 수 있어야 한다. 마지막 편에서는 문제 정의부터 이 운영 판단까지 하나의 가상 스케줄 생성 과제로 연결한다.