01. 문제 정의 — 강화학습에 어떤 결정을 맡길 것인가

“강화학습으로 FAB의 생산성을 높여 보자.” 과제 제안서에 자주 등장할 법한 문장이지만, 이 문장만으로는 학습을 시작할 수 없다. 생산성을 높인다는 것이 생산량을 늘리는 것인지, 납기를 지키는 것인지부터 다르다. 모델이 바꿀 수 있는 것도 lot의 처리 순서인지, 설비 배정인지, 공장에 투입하는 물량인지에 따라 완전히 달라진다.

첫 단계의 산출물은 알고리즘 이름이 아니라 모델에 맡길 결정과 개선을 판정할 기준을 적은 문제 정의서다. 무엇을 바꿀 권한이 있는지, 무엇은 그대로 유지하는지, 어떤 조건에서 기존 운영보다 낫다고 판단할지를 먼저 정해야 한다.

이 글은 한 시점의 설비와 작업 정보를 받아 스케줄을 만드는 예로 그 과정을 설명한다. snapshot은 계획의 기준이 되는 상태를 한 번 고정한 것이다. 설비–lot 조합을 하나씩 선택해 설비별 예정 작업열을 완성한다. 아래 구성과 숫자는 설명을 위한 가정이며 특정 기업의 설비나 실험 결과가 아니다. 공개 연구에서 확인한 내용은 출처를 붙이고, 과제 정의 절차와 양식은 작성자의 설계 제안으로 제시한다.

1. 두 설비와 두 lot으로 선택의 충돌을 본다

lot은 함께 처리하는 작업 단위다. 두 설비 M1·M2는 시각 0에 비어 있고, 두 lot도 모두 준비되어 있다. 처리시간만 다음처럼 다르며, 중간에 작업을 끊거나 새 lot이 들어오는 일은 없다. 처음 예시에는 제품 종류, setup, 납기, 공정 경로를 넣지 않는다.

lot	M1 처리시간	M2 처리시간
L1	1시간	4시간
L2	8시간	12시간

L2를 M1에 먼저 붙이면 L1은 M1에서 기다리거나 더 느린 M2를 써야 한다. L1을 M1에서 먼저 끝내고 L2를 이어 처리하면 개별 작업의 체류시간 합은 작아질 수 있지만, 전체 작업을 끝내는 시각은 늦어질 수 있다. 이 충돌만으로도 배정과 순서를 함께 결정해야 하는 이유를 설명할 수 있다.

makespan은 마지막 lot까지 끝나는 데 걸리는 시간, TCT(total cycle time)는 모든 lot의 cycle time을 합한 값이다. 계산식과 두 스케줄의 비교는 다음 편에서 다룬다. 시리즈의 가상 과제는 다음과 같다.

한 snapshot에서 설비–lot 조합을 순차 선택한다. 각 선택은 미배정 lot 하나를 설비 하나의 예정 작업열 끝에 붙인다. 모든 대상 lot이 한 번씩 배정되면 스케줄을 평가한다. 목표는 TCT 악화를 합의한 범위 안에 두면서 makespan을 줄이는 것이다.

이 충돌이 있다고 RL이 필요한 것은 아니다. 현행 규칙, 조정한 규칙, 제한된 탐색부터 같은 문제에서 비교한다. 둘뿐인 lot은 전수 열거할 수 있으므로 환경 검산에 적합하고, RL의 이점을 입증하는 과제는 아니다.

실제 FAB로 확장할 때는 제어할 설비군과 나머지 공정의 경계를 따로 정한다. 작은 영역만 제어하더라도 다른 공정에 전달되는 영향까지 평가해야 한다. Stöckermann 등의 연구는 산업 데이터 기반 시뮬레이션에서 제어할 bottleneck tool의 선택과 조합이 중요하다고 보고한다. 이는 제어 범위를 문제 정의에 포함할 근거이며, 이 글의 스케줄 생성 방식이나 실제 현장 성과를 검증한 결과는 아니다. Stöckermann et al., 2025

2. 한 번의 decision과 스케줄 생성 요청을 구분한다

이번 문제의 decision은 설비–lot 조합 하나를 선택해 부분 스케줄을 갱신하는 일이다. 스케줄 전체를 만드는 요청 하나에는 여러 decision이 들어간다. 설비가 실제로 가용해질 때마다 lot 하나를 고르는 사건 기반 dispatching과는 시간 경계가 다르다.

항목	가상 과제의 결정
계획의 기준	고정한 snapshot의 설비 상태와 대상 lot 집합
호출 단위	스케줄 생성 요청 안에서 (설비 ID, lot ID) 하나를 반복 선택
후보 집합	미배정 lot과 배정 가능한 설비의 조합
모델 권한	설비 선택과 해당 설비 작업열의 처리 순서 결정
고정할 로직	각 선택은 작업열 끝에 추가. 이미 붙인 작업의 재배치와 별도 대기 행동은 없음
입력의 시간 기준	snapshot 확보 당시 사용할 수 있던 정보. 이후 실제 완료·고장 정보는 제외
선택 뒤 갱신	lot을 미배정 집합에서 제거하고 선택한 설비의 예상 가용시각 갱신
생성 종료	모든 대상 lot이 배정되면 종료. 실제 생산 시간은 생성 중 진행하지 않음
실행 조건	완성한 스케줄을 최신 상태에서 검증한 뒤 예약·실행
막힘·추론 실패	미배정 lot이 있는데 후보가 없거나 계산 한도를 넘으면 실패 사유를 남기고 검증된 기존 계획 방식 사용

예를 들어 첫 선택이 (M1,L1)이면 M1의 예정 작업은 L1: 0–1이 된다. 다음에 (M1,L2)를 골라도 된다. M1이 지금 비어 있어야 하는 것이 아니라, 예정 작업열 끝인 시각 1부터 L2를 배치하기 때문이다. (M2,L2)를 고를 수도 있지만 이미 배정한 L1을 다시 고를 수는 없다.

여기에는 세 종류의 시간이 있다. snapshot의 기준 시각, 부분 스케줄의 예상 시작·완료시각, 스케줄 계산에 걸린 실제 응답시간이다. 조합을 두 번 고른 것을 생산 2시간으로 세면 안 된다. 생성된 계획을 실제로 실행하거나 simulator에서 재생할 때 생산 시간이 진행한다.

모든 lot을 M1에 배정해 M2가 비게 되는 결과는 가능하다. 다만 설비를 일부러 몇 시간 쉬게 하는 별도 action은 없다. 그런 권한이나 이미 정한 순서의 수정이 필요하면 문제 정의를 바꿔야 한다.

모델을 사용할 수 없을 때 대신 쓰는 처리 경로를 fallback이라고 한다.

학습 전에는 스케줄별 선택 수, 유효 조합 수와 서로 다른 완성 스케줄이 나오는지를 집계한다. 후보가 여러 개여도 설비 간 독립적인 두 선택의 순서만 바뀌고 최종 스케줄이 같을 수 있다. 후보 수를 그대로 개선 가능성으로 해석하지 않는다.

3. 순차적인 효과가 있어야 RL을 검토할 이유가 생긴다

첫 선택으로 L2를 M1에 붙이면 M1의 예상 가용시각은 8이 된다. 이후 L1을 M1에 붙이면 9에 끝나고 M2에 붙이면 4에 끝난다. 반대로 L1을 M1에 먼저 붙이면 L1은 1에 끝나고 L2는 그 뒤에 놓을 수 있다. 물리 시간이 흐르지 않아도 부분 스케줄이 다음 선택의 비용을 바꾼다.

어떤 관측에서 어떤 행동을 고를지 정하는 함수를 policy라고 한다. 학습된 policy는 여러 snapshot에서 스케줄을 만드는 데 반복 사용된다. 한 snapshot에서 얻은 스케줄은 그 policy가 만든 결과물이다.

장기 효과만으로 RL을 택할 수는 없다. 수리 최적화도 여러 배정의 영향을 함께 고려할 수 있고, 규칙이 충분한 성과를 낼 수도 있다. 다음 세 질문을 함께 확인한다.

1. 선택의 영향이 이어지는가? 현재 선택이 설비의 예정 점유와 후속 배정 비용을 통해 완성 스케줄의 성과에 영향을 주는가?
2. 상황에 따라 좋은 선택이 달라지는가? 하나의 규칙으로 처리하기 어려운 충돌이 여러 snapshot에서 반복되는가?
3. 대안을 학습하고 비교할 근거가 있는가? 완성 스케줄을 평가할 계산기, 검증한 simulator 또는 적합한 로그가 있는가?

이것은 착수 검토를 위한 질문이지 RL이 우수해지는 충분조건은 아니다. 처리시간 예측을 개선하는 것과 그 예측을 이용해 좋은 스케줄을 만드는 것도 별개의 과제다.

4. 비교할 대안을 먼저 만든다

baseline은 새 방법의 성과를 판단하는 비교 기준이다. 이 과제의 가장 중요한 baseline은 현장에서 실제로 사용하는 규칙이다. 단순 FIFO보다 잘하는 것과 이미 여러 예외·우선순위를 반영한 운영 규칙보다 잘하는 것은 다른 성과다. 이번 비교에서는 lot 순서만으로 스케줄이 완성되지 않으므로, 각 lot을 어느 설비에 붙일지도 정한다. 예를 들어 FIFO 순서로 lot을 가져와 예상 완료시각이 가장 빠른 설비에 append하고, 동률이면 설비 ID로 해소하는 방식까지 baseline 계약에 넣는다.

다음 표는 방법의 우열표가 아니라, 과제 초기에 비교 후보를 고르는 질문표다.

후보	먼저 검토할 상황	실제 비교에서 확인할 것
현행 규칙과 규칙의 계수 조정	운영 지식을 유지하면서 우선순위 충돌을 줄이고 싶을 때	제대로 재현했는지, 간단한 조정만으로 목표를 달성하는지
예측 모델 + 기존 결정 로직	처리시간·지연 위험 등의 추정 오차가 판단을 어렵게 할 때	예측 개선이 실제 의사결정과 KPI 개선으로 이어지는지
수리 최적화·탐색	목적과 제약을 명시하고 제한된 시간 안에 후보 계획을 구할 수 있을 때	주어진 정보·계산 시간 안에서 얻은 해의 품질과 변경 대응
모방학습	재현하려는 숙련자의 결정이나 solver의 해가 있을 때	교사의 품질, 새로운 상태에서의 오류, 학습 목표와 업무 목표의 차이
강화학습	행동의 장기 효과를 반영하는 반복 가능한 policy를 배우고 싶을 때	학습·평가 근거, 변동성, 새로운 조건의 성능, 전체 운영 비용

모방학습은 관측과 모범 행동의 짝으로부터 행동을 재현하도록 학습하는 접근이다. 모방을 통한 초기화 후 RL로 개선하거나, 예측 모델을 수리 최적화와 결합하는 식의 조합도 가능하다. 비교 후보를 서로 배타적인 제품처럼 다룰 필요는 없다.

비교에서는 같은 정보와 권한을 줘야 한다. RL만 전체 공장의 상태를 보고 baseline은 국소 대기열만 보게 했다면, 개선이 학습 때문인지 정보 추가 때문인지 구분하기 어렵다. 반대로 solver가 미래의 실제 고장 시각을 알고 RL은 모르게 했다면 그것은 동일 조건의 운영 비교가 아니다. 추가 정보를 쓰는 방법은 별도 조건으로 표시해야 한다.

Stöckermann 등의 산업 시나리오에는 전문가가 조정한 설비군별 규칙이 포함된다. 이 점은 공개 benchmark의 단순 규칙 비교를 현장의 개선 여지로 그대로 옮기기 어려운 이유이기도 하다. Stöckermann et al., 2025

5. 무엇을 학습하고, 무엇으로 채택할지 구분한다

이번 과제에서 학습하려는 것은 부분 스케줄에서 다음 설비–lot 조합을 고르는 policy ${\pi }_{\theta }$다. $\theta$는 관측을 행동 선택으로 연결하는 모델의 parameter다. 시뮬레이션에서 상태·행동·reward의 기록을 수집하는 방식을 택했다면, 그 기록으로 기대 누적 reward가 커지도록 parameter를 갱신한다. 이를 개념적으로 쓰면 다음과 같다.

$${\theta }^{\star }\in \arg \underset{\theta }{\max }{J}_R(\theta ),J_R(\theta )={\mathbb{E}}_{{\pi }_{\theta }}\left[\sum _{k=0}^{T-1}{\gamma }^k{r}_k\right]$$

여기서 $k$는 생산 사건 번호가 아니라 조합 선택 순서이고, $T$는 스케줄 완성까지의 선택 수다. 유한한 스케줄 생성 과제의 총비용을 그대로 학습하려면 $\gamma =1$로 두는 선택이 자연스럽다. 마지막 선택에만 완성 스케줄의 비용을 reward로 줄 수도 있다. 실제 loss와 갱신 방식은 선택한 알고리즘에 따라 달라진다. 보상 분배와 시간의 관계는 다음 편에서 다룬다.

채택 여부는 별도의 KPI로 판단한다. baseline과 후보의 makespan을 $M_0,M_{\pi }$, TCT를 $T_0,T_{\pi }$라고 하면 다음 두 값을 구분한다.

$$I_M=\frac{M_0-M_{\pi }}{M_0},D_T=\frac{T_{\pi }-T_0}{T_0}$$

$I_M$은 클수록 좋은 makespan 개선율이고, $D_T$는 양수이면 TCT 악화율이다. 예를 들어 TCT 증가는 2%까지 허용하고 makespan은 최소 3% 개선해야 한다고 정할 수 있다. 이 값은 설명용이며, 실제 허용치는 업무 가치와 손실 비용으로 정한다. 02편에서 여러 후보의 절충을 비교하는 방법을 다룬다.

또한 평가 사례를 동일 비중으로 평균할지 실제 운영 빈도로 가중할지 정해야 한다. 전자는 고른 사례 전반의 성능, 후자는 목표 운영 분포에서의 기대 성능을 묻는다. 이 과제는 근거가 있는 운영 빈도 가중 평균을 주판정으로 쓰고, 동등 평균과 시나리오별 손실을 함께 보고하는 것으로 가정한다. 가중치 근거가 없다면 운영 기대 성과라고 주장하지 않는다. 세부 선택 기준은 05편에서 다룬다.

6. 학습할 장소와 데이터를 확보한다

“데이터가 많다”는 말만으로 학습 가능 여부를 판단하기 어렵다. 이번 스케줄 생성 문제라면 원본 snapshot, 각 단계의 부분 스케줄과 후보 조합, 완성 스케줄, 실행 이후 결과를 연결할 수 있어야 한다. 일별 생산량 합계만 있는 데이터와 decision 직전의 상태를 복원할 수 있는 데이터는 활용 범위가 다르다.

학습 경로는 크게 다음처럼 구분할 수 있다.

• 시뮬레이션에서 상호작용하며 학습: policy의 행동을 적용한 뒤 다음 상태를 생성한다. 현행 운영 재현뿐 아니라 다른 행동을 적용했을 때의 상태 변화도 합리적인지 검증해야 한다.
• 과거 로그로 offline RL 수행: 새 상호작용 없이 고정된 데이터로 학습한다. simulator가 필수인 것은 아니지만, 로그가 뒷받침하지 않는 선택과 상태에서 생기는 불확실성을 다뤄야 한다.
• 실제 시스템에서 데이터를 추가 수집: 허용된 제어 범위와 별도의 운영 검증이 필요하다. 이 글의 첫 가상 과제에서는 생산 설비에서 탐색 행동을 실행하는 방식을 채택하지 않는다.

Levine 등의 offline RL 리뷰는 데이터 수집 방식과 학습 policy 사이의 distribution shift, 즉 서로 다른 상태·행동 분포에서 생기는 문제를 핵심 난점으로 설명한다. 같은 결정만 반복한 로그를 오래 모았다고 해서 다른 결정의 효과까지 관측한 것은 아니다. Levine et al., 2020

이번 사례는 검증한 simulator에서 policy를 학습하고, 운영 시에는 고정된 모델로 추론하는 방식으로 시작한다. 학습이 simulator와 온라인으로 상호작용한다는 말과, 배포된 모델이 생산 중에 스스로 parameter를 계속 바꾼다는 말은 구분해야 한다.

관측과 실행의 시간 차이도 처음부터 요구사항에 넣는다. 데이터가 만들어진 시각과 모델이 받은 시각, 스케줄 구성에 걸린 시간과 실제 예약까지의 지연을 기록해야 한다. 현실 RL의 지연, 시스템 상태의 일부만 알 수 있는 부분 관측, 제약을 분리해 다룬 Dulac-Arnold 등의 연구는 이런 항목을 문제 정의에 포함할 근거를 제공한다. 구체적인 FAB 허용 시간은 해당 시스템에서 정해야 한다. Dulac-Arnold et al., 2020

7. 첫 학습 전에 비용과 보류 조건을 정한다

모델 추론이 빠르다고 과제 전체가 저렴한 것은 아니다. simulator 구축·보정, 데이터 정합성 확인, 설정 탐색, 독립 반복, 평가, 시스템 연결, 재학습까지 비용이 발생한다. 이 비용을 감수할 만큼 개선이 필요한지를 먼저 판단해야 한다.

계산 예산은 작은 pilot 실행으로 추정할 수 있다. 가령 학습 설정 20개를 각각 난수 초기값인 training seed 5개로 반복하고, 한 번에 worker 하나를 2시간 사용한다고 가정하자. worker는 여기서 학습 실행 하나를 처리하는 계산 자원 단위다. 학습만으로 $20\times 5\times 2=200$ worker-hours가 필요하다. 동일한 worker 8개에 100회 실행을 배분하면 마지막 묶음의 빈자리 때문에, 모든 실행이 정확히 2시간이고 추가 비용이 없어도 $\lceil 100/8\rceil \times 2=26$시간이 걸린다. 평가·자원 대기·통신·실패 재실행 비용은 별도다. 이는 예산 계산 예시이며 필요한 설정 수나 seed 수에 대한 권고는 아니다.

본격적인 학습 투자 전에는 다음 단계를 통과하도록 제안한다.

단계	확인할 근거	충족되지 않을 때
결정 범위 확인	변경 권한과 선택 가능한 후보가 명시됨	모델보다 제어 범위와 시스템 인터페이스부터 정리
개선 여지 조사	현행 규칙 재현, 손실 원인과 대안의 비교	단순 규칙 조정으로 충분하면 그 대안을 채택
학습·평가 가능성 확인	데이터 시점 복원, 환경 검증, KPI 독립 계산	계측·simulator 보완을 별도 선행 과제로 전환
작은 학습 실험	의도한 행동을 학습하는지, 비용이 감당 가능한지 확인	원인을 분류하고 수정 범위·추가 예산·중단 조건 결정

개선이 안 보였다는 결과만으로 “RL은 이 문제에 불가능하다”고 결론 내릴 수는 없다. 환경이나 reward 구현이 잘못됐을 수도 있다. 반대로 원인을 확인하지 않은 채 계산 예산만 계속 늘리는 것도 타당하지 않다. 보류는 기법의 영구적인 부정이 아니라, 현재 확보한 근거로 다음 투자를 정당화하기 어렵다는 판단이다.

8. 한 장의 문제 정의서로 남긴다

아래는 지금까지의 결정을 묶은 가상 작성 예시다. 합격 수치 역시 실제 기준이 아니라 표를 채우는 방법을 보여주기 위한 값이다.

항목	작성 예시
업무 문제와 가설	같은 설비를 먼저 쓰려는 lot의 충돌 때문에 makespan과 TCT 사이 절충이 발생한다는 가설
제어 권한	한 snapshot에서 조합을 순차 선택해 설비별 작업열 끝에 추가. 대상 lot 전부 배정
고정 조건	대상 lot 집합과 처리 조건. 첫 버전에는 신규 도착·고장·setup 없음
주요 KPI	동일 대상 lot 전체의 makespan과 TCT. 전부 완료할 때까지 평가
성과 판단 예	운영 빈도 가중 makespan 개선 최소 3%, 추정 불확실성을 포함한 규칙은 사전 평가 계획에 명시
보조 조건 예	TCT 증가 2% 이내. 전체 평균과 필수 시나리오별 한도를 별도로 명시
금지·실행 조건	중복·누락·설비 작업 중첩 금지, 완성 스케줄 재검증, 전체 생성 응답시간 한도
비교 대상	현행 계획 방식, 조정한 규칙, 동일 시간 예산의 제한 탐색, RL policy
학습·운영 방식	검증한 평가 환경에서 학습. 운영은 고정 모델로 스케줄 생성
검증 범위	소수 lot 검산부터 시작해 처리시간 변동·설비 제약을 단계적으로 추가
보류 조건	snapshot 복원 불가, 행동 효과 재현 부실, 허용 손실 초과, 비용 대비 개선 근거 부족
담당과 산출물	운영 담당이 KPI와 절충을 결정하고 개발 담당이 재현성·연결을 검증

허용 손실과 최소 개선 폭은 reward 계수를 정하는 일과 다르다. 후보를 보고 기준을 바꾸기보다, 업무 담당자가 감수할 손실과 필요한 이득을 먼저 합의하고 독립 평가로 확인한다. 시험에서 위반이 없었다는 결과 역시 모든 운영 조건에 대한 보증은 아니다.

이 정의서가 완성되면 다음 작업이 구체적이 된다. 데이터 담당자는 어떤 시점의 상태를 복원해야 하는지 알고, simulator 담당자는 어떤 행동 효과를 재현해야 하는지 안다. 학습 담당자는 변경할 policy의 범위를 알며, 운영 담당자는 어떤 근거로 후보를 채택하거나 거절할지 논의할 수 있다.

다음 편에서는 이 정의서의 KPI와 허용 조건을 실제 측정식으로 고정하고, 그것을 학습에 사용할 reward와 어떻게 연결할지 다룬다.

참고문헌

• Stöckermann et al. (2025), Scalability of Reinforcement Learning Methods for Dispatching in Semiconductor Frontend Fabs: A Comparison of Open-Source Models with Real Industry Datasets. arXiv
• Levine, Kumar, Tucker, Fu (2020), Offline Reinforcement Learning: Tutorial, Review, and Perspectives on Open Problems. arXiv
• Dulac-Arnold et al. (2020), An empirical investigation of the challenges of real-world reinforcement learning. arXiv

시리즈 목차 · 다음: 02. KPI와 reward