학습 중 reward가 올랐고, 시험용 snapshot에서도 평균 성능이 좋았다. 그래도 배포하기에는 정보가 부족하다. lot 수가 늘어나면 어떤가? 한 설비에서만 빨리 처리되는 lot이 몰리면 어떤가? makespan을 줄이는 대신 일부 lot의 체류시간을 크게 늘리지는 않는가?
강화학습 평가에서 시나리오는 snapshot의 설비·lot 구성, 처리 조건, 관측·실행 조건과 평가 종료 기준을 함께 정한 실험 단위다. 처리시간 변동이나 고장을 추가한 실행 evaluator에서는 외부 사건 경로도 포함한다. 여기서 policy는 관측을 받아 행동을 선택하는 규칙이며, 학습된 신경망도 하나의 policy다. 단순히 난수 seed를 바꾸는 것만으로는 다른 운영 조건을 평가했다고 말하기 어렵다. 이 글에서는 공개 연구가 강조하는 일반화 문제를 출발점으로, 제조 스케줄링에 적용할 평가 설계를 제안한다.
시나리오는 여러 축의 조합이다
먼저 정상·비정상을 하나의 목록으로 분류하기보다, 서로 다른 질문을 분리한다. 아래 분류는 특정 논문의 공식 분류가 아니라 평가 누락을 줄이기 위한 설계 틀이다.
| 분류 축 | 시나리오 예 | 확인할 질문과 특징 |
|---|---|---|
| 학습 분포와의 거리 | 익숙한 제품 mix / 신규 mix / 부하 범위 초과 | ID (In-Distribution)는 학습 분포 안의 새 표본, OOD (Out-of-Distribution)는 학습 분포 밖의 조건이다. seed가 달라도 조건이 같으면 주로 ID (In-Distribution) 검증이다. |
| 운영 상태 | 정상 가동 / 수요 급증 / 고장 / 복구 | 평균 효율, 충격 직후 손실, 정상 수준 복귀 시간을 각각 본다. |
| 발생 빈도와 강도 | 일상 변동 / 드문 동시 고장 / 극단적 과부하 | rare는 빈도, stress는 강도에 관한 말이다. 드물지만 약한 사건도 있고 반복되는 강한 부하도 있다. |
| 관측 품질 | 정상 데이터 / 지연 / 누락 / 단위 변경 | 의사결정 능력과 데이터 장애 대응 능력을 구분한다. 물리 상태가 정상이어도 관측은 틀릴 수 있다. |
| 실행 조건 | 즉시 실행 / 지연 / action 거절 | 추론 결과가 현장 상태와 맞지 않을 때의 재검증과 fallback을 평가한다. |
| 시간 구조 | 짧은 과도 구간 / 고정 기간 / 장기 연속 가동 | 초기 상태 의존성, 지연된 손실, 누적 WIP의 영향을 구분한다. |
| 제어 범위 | 단일 설비군 / 여러 설비군 공동 제어 | 국소 개선이 다른 공정의 혼잡으로 옮겨 가는지 확인한다. |
이 문맥의 ID (In-Distribution)와 달리, lot ID나 snapshot ID의 ID (Identifier)는 대상을 구별하는 식별자를 뜻한다.
이 표는 FAB로 확장할 때의 평가 축이다. 첫 평가는 두 설비·소수 lot의 고정 snapshot에서 lot 수, 설비별 처리시간 차이, 배정 가능 edge를 바꾸는 것으로 충분하다. 이후 제품 mix는 처리 조건이 다른 lot의 구성비로, 고장은 완성 스케줄의 실행 조건으로 추가한다. 여러 공정의 공동 제어나 중간 재계획까지 허용한다면 권한을 확장한 별도 실험으로 기록한다.
모든 조합을 전수 실행할 필요는 없다. 먼저 정상 조건에서 기준 성능을 측정하고, 한 축씩 바꿔 원인을 파악한 다음, 실제로 함께 일어날 수 있는 복합 조건을 추가한다. 예를 들어 제품 mix 변화와 고장은 각각 통과했어도, 변경된 mix가 특정 설비에 의존하면 두 조건의 결합에서 실패할 수 있다.
학습 환경과 별도의 평가 환경을 두는 이유도 여기에 있다. 반도체 Dispatching을 다룬 Stöckermann 등의 연구도 고장 seed와 load mix를 별개의 불확실성으로 평가한다. 이는 단순한 난수 변경과 운영 조건 변경을 구분해야 한다는 좋은 출발점이다. 다만 이 연구는 산업 데이터에 기반한 시뮬레이션 연구이며, 실제 FAB 배포 성능의 증거로 읽어서는 안 된다. Stöckermann et al., Scalability of Reinforcement Learning Methods for Dispatching in Semiconductor Frontend Fabs
스케줄 완성과 생산 완료를 평가의 경계로 삼는다
두 policy를 각각 조합 선택 1,000번으로 비교하면 완성한 스케줄 수와 대상 lot 수가 달라질 수 있다. 한 snapshot에 10개 lot이 있으면 생성 episode는 정상적으로 10번 선택하고, 100개 lot이면 100번 선택한다. 이 차이는 생산 10시간과 100시간의 차이가 아니다.
기본 평가는 같은 snapshot과 대상 lot에서 스케줄을 각각 완성한 뒤 동일 대상 lot이 전부 완료될 때까지 재생해 makespan과 TCT를 측정한다. 초기 상태를 , 실행 evaluator의 변동 경로를 라 쓰면 결과는 다. 완료까지 걸리는 시간이 makespan이라는 성과이므로, 두 방법의 종료 시각이 달라지는 것이 정상이다. 생성 응답시간 한도와 실행 평가의 자원 한도는 별도로 둔다.
| 시간·횟수 | 이번 문제에서의 의미 |
|---|---|
| 조합 선택 단계 | 부분 스케줄 갱신 횟수 |
| snapshot 기준 시각 | 계획의 출발점, 생성 중 고정 |
| 실행 생산 시간 | 완성 스케줄을 실제로 처리하는 시간, makespan·TCT 계산에 사용 |
| 생성 응답시간 | 조회·그래프 생성·모든 조합 선택·검증에 걸린 실제 시간 |
평가 한도에서 미완료가 남으면 완료 lot만으로 계산한 TCT를 섞지 않는다. 평가 실패·미완료를 남기고 사전에 정한 처리 규칙을 따른다. 정상 완료 때까지 실행한 결과와 임의의 시간 까지의 WIP 면적도 다른 지표다. 생성 episode 중 수집을 끊는 truncation과 전부 배정해 끝나는 termination은 04편의 경계로 구분한다. Gymnasium 공식 문서: Handling Time Limits
운영에서 재계획을 반복하는 확장도 따로 평가한다. 이는 스케줄 전체를 끝까지 실행하는 대신, 정한 시간 안에 시작할 작업만 확정하고 새 상태에서 나머지를 다시 계획하는 방식이다. 예를 들어 09시에 L1 → L2로 계획해 L1을 시작했더라도, 10시에 L3가 도착하면 아직 시작하지 않은 순서를 L3 → L2로 바꿀 수 있다. 이미 가공 중인 L1은 유지한다.
이 경우 두 방법을 같은 초기 상태·외부 유입 경로에서 시작해 동일한 7일 동안 운영하는 식으로 비교한다. 이후 snapshot은 각 방법이 실제로 만든 대기열과 설비 상태를 이어받아야 한다. 매번 초기 상태로 reset하면 앞선 선택으로 쌓인 손실을 지워 버린다. 일별 생산량·납기와 함께 미완료 age, 즉 남은 lot의 투입 이후 경과시간을 보면 쉬운 작업만 끝내고 어려운 작업을 남기는지도 확인할 수 있다.
겹치는 snapshot의 예상 TCT를 더해 실제 운영 TCT로 쓰지는 않는다. 09시에 투입돼 13시에 끝나는 lot이 09시와 10시 snapshot에 모두 있으면, 각 계획에 잡힌 4시간을 더할 때 같은 lot을 두 번 센다. 실제 투입·완료 기록에서 lot마다 한 번 집계하고 미완료 대상은 별도 추적해야 한다. 단일 snapshot의 스케줄 품질과 이런 반복 운영의 성과는 대상·실행 조건이 달라 결과도 구분해 보고한다.
장기 정상 성능을 보려면 빈 공장에서 WIP가 쌓이는 초기 구간을 warm-up으로 제외할 수 있다. 반면 장애 평가의 고장 직후 손실과 회복 과정은 측정 대상이므로 제거하지 않는다. 이런 관측 구간의 선택은 시뮬레이션 출력 분석과 연결된다.
동등 평균과 운영 빈도 가중 평균은 다른 질문에 답한다
시나리오 집합을 , 각 시나리오에서 baseline 대비 makespan 개선율의 기대값을 라고 하자. 여기서는 시나리오별 평균을 동일 비중으로 합하는 동등 평균을 사용한다. 원자료를 모두 합친 평균과는 다르며, 시나리오마다 같은 수의 사례가 있을 때 둘이 일치한다.
동등 평균은 정한 종류의 문제를 두루 잘 푸는지 묻는다. 운영 빈도 가중 평균은 목표 기간에 들어올 계획 요청 한 건에서 어떤 성과를 기대하는지 묻는다. 평가 편의상 어려운 사례를 많이 뽑았다고 운영에서도 그 상황이 자주 발생하는 것은 아니다.
다음은 두 종류의 snapshot을 같은 횟수 평가했다고 가정한 결과다. 수치는 baseline 대비 makespan 개선율이며, 양수가 좋다.
| 시나리오 | 목표 운영 비중 | 후보 A | 후보 B |
|---|---|---|---|
| 일반 구성 | 90% | +8% | +4% |
| 드문 편중 구성 | 10% | -4% | +3% |
| 동등 평균 | 각각 50% 적용 | +2% | +3.5% |
| 운영 빈도 가중 평균 | 위 90/10 적용 | +6.8% | +3.9% |
동등 평균이면 B가 좋고, 운영 빈도 가중 평균이면 A가 좋다. 최소 개선 폭이 3%라면 A는 동등 평균에서 미달하고 운영 평균에서는 넘는다. 어느 계산이 잘못된 것이 아니라 해결하려는 의사결정이 다르다.
어느 평균으로 결정할지는 다음처럼 정한다.
- 현재 운영의 도입 여부가 질문이고 빈도를 추정할 근거가 있으면 운영 빈도 가중 평균을 주판정으로 쓴다. 목표 기간과 적용 범위에서 대표 snapshot을 수집하고, 시나리오가 중복되지 않도록 분류해 비중을 정한다. 과거 기간과 향후 계획이 다르면 예정된 변화도 반영한다.
- 여러 유형에 고른 능력을 갖춘 방법을 고르는 것이 목적이면 동등 평균을 주판정으로 쓸 수 있다. 다만 시나리오 분류를 잘게 쪼개 특정 유형의 비중을 키우지 않도록 집합을 먼저 고정한다. 빈도를 모른다는 이유로 동등 평균을 실제 운영 기대 성과라고 부르지는 않는다.
- 빈도가 불확실하면 가능한 비중 범위에서 결론이 유지되는지 본다. 위 예시에서 일반 구성 비중을 라 하면 A는 , B는 %이므로 일 때 A가 우세하다. 목표 비중이 이 경계 양쪽에 걸리면 현재 자료로 후보 우열을 확정하기 어렵다.
이 시리즈의 도입 판단은 근거를 정한 운영 빈도 가중 평균을 주판정으로 하고, 동등 평균을 함께 공개하는 것으로 가정한다. test 결과를 본 뒤 유리한 평균을 고르지 않는다. 가중치의 출처·기간·분류 기준·갱신 규칙까지 평가 계약에 남긴다. 개별 사례를 동등하게 볼지 시나리오 종류를 동등하게 볼지도 구분한다.
또한 이 예시는 사례별 상대 개선율을 평균했다. 실제 절감 시간의 기대값이나 전체 lot의 체류시간 절감이 목적이라면 절대 차이로 집계하거나 적절한 분모를 먼저 합쳐야 한다. snapshot 수의 비중, lot 수의 비중, 생산량의 비중은 서로 바꿔 쓸 수 없다.
평균 점수와 통과 조건을 분리한다
주판정 평균을 골랐어도 그것만으로 채택하지 않는다. 02편의 예처럼 운영 평균 makespan 개선이 최소 3%이고 TCT 악화는 2% 이내라는 기준을 둔다면, 각 기준의 불확실성 처리와 필수 시나리오별 TCT 한도도 함께 정한다.
앞의 후보 A는 드문 편중 구성에서 makespan이 4% 악화된다. 이 손실이 별도 허용 한도 안에 있는지, TCT와 lot별 장기 지연은 허용되는지 확인하기 전에는 채택할 수 없다. stress 평가를 많이 해 실패를 찾되, 이를 운영 빈도 추정과 혼동하지 않는다. 중복·누락·자격 위반 같은 금지 행동은 평균의 큰 이득으로 상쇄하지 않는다.
시험에서 위반이 0건이어도 모든 조건에서 불가능하다는 증명은 아니다. 실행한 스케줄 수와 lot·설비 규모, 평가 조건을 함께 남긴다. 운영 빈도가 거의 0이라고 본 장애도 필수 검증 조건이면 별도 통과표에 둔다.
실행 전에 시나리오 계약을 작성한다
다음은 실제 평가에 쓸 수 있는 계약의 가상 예다. 계약은 데이터 파일 하나보다 넓은 개념으로, 결과 해석에 필요한 조건을 묶은 문서다.
| 항목 | 사전 기록 예 |
|---|---|
| 질문 | TCT 한도를 지키면서 완성 스케줄의 makespan을 줄이는가 |
| 초기 상태 | 대상 lot ID와 설비 상태가 있는 snapshot, version 고정 |
| 외부 변동 | 기본 검산은 결정적. 확장에서는 동일 작업·설비 ID에 대응한 처리시간·고장 변동 |
| 평가 경계 | 대상 lot 전부 완료까지. 생성 응답시간 한도·실행 평가 한도 별도 |
| 비교 대상 | 현재 계획 방식, 조정한 규칙, 학습 policy, guard·fallback 포함 시스템 |
| KPI | 동일 대상의 makespan·TCT, 계획 유효성, 전체 생성 응답시간 |
| 주판정 집계 | 목표 기간의 운영 빈도 가중 상대 개선율. 동등 평균 별도 공개 |
| 가중치 근거 | 대표 snapshot 기간, 시나리오 분류, 빈도 추정과 민감도 범위 |
| 실패 처리 | timeout·배정 누락·미완료를 삭제하지 않고 원인과 상태 기록 |
| 통과 기준 | makespan 최소 개선 폭, TCT 전체·필수 시나리오 한도, 불확실성 규칙 |
| 데이터 분리 | 학습·선택에 쓰지 않은 snapshot 묶음과 실행 변동 경로 |
held-out 시나리오는 학습과 모델 선택에서 따로 보관한 조건을 뜻한다. test에서 실패한 사례를 보고 reward를 고쳤다면 그 사례는 다음 개발 라운드의 학습 또는 validation 자료가 된다. 같은 사례를 계속 “처음 보는 시험”이라고 부를 수는 없다. 반복 개발을 위해 회귀 검사 집합은 유지하되 최종 판단용 새 holdout을 따로 확보해야 한다.
평가 산출물은 결국 점수 하나가 아니라 어떤 조건에서 어떤 policy가 허용 가능한가를 설명하는 표다. KPI와 reward에서 정한 지표를 어떤 조건에서 측정할지 정했다면, 다음에는 실험 방법론에 따라 비교와 반복, 모델 선택 절차를 설계한다.
참고문헌
- Stöckermann et al. (2025), Scalability of Reinforcement Learning Methods for Dispatching in Semiconductor Frontend Fabs. arXiv
- Gymnasium, Handling Time Limits. 공식 문서
이전: 04. 학습 환경 검증 · 시리즈 목차 · 다음: 06. 실험 방법론