04. 학습 환경 검증 — simulator를 믿기 전에 확인할 것

policy가 설비를 바쁘게 움직이고 reward도 좋아진다고 해서 학습 환경이 정상인 것은 아니다. 한 lot이 두 설비에서 동시에 처리되거나, 긴 시간 동안 쌓인 WIP 비용이 step 하나의 비용으로 축소될 수 있다. RL은 제공받은 환경에서 유리한 선택을 찾으므로, 업무 규칙과 어긋난 구현도 성과 개선의 경로로 사용할 수 있다.

이 글은 한 snapshot에서 설비–lot 조합을 순차 선택해 스케줄을 만드는 환경을 검증한다. 아래 검사 절차는 설계 제안이며, 계산 사례는 손으로 답을 확인하기 위해 만든 가상 환경이다. 실제 FAB의 성능이나 RL 학습 결과가 아니다. 목표는 어떤 동작을 확인했고 어떤 조건까지 환경을 믿고 사용할 수 있는지 적은 환경 검증 보고서를 만드는 것이다.

1. reset과 step은 부분 스케줄을 갱신한다

reset은 snapshot을 읽고 빈 부분 스케줄을 만드는 작업이다. 처음 예제에서는 두 설비가 시각 0에 비어 있고 두 lot이 준비되어 있다. 이후 진행 중 작업이 있는 snapshot을 추가한다면, 그 작업의 예상 잔여시간과 이미 확정한 예약을 복원해 설비의 초기 예상 가용시각을 정한다. 실제로 가공 중인 작업을 빈 설비처럼 초기화해서는 안 된다.

step은 (설비, lot) 하나를 선택해 해당 설비 작업열 끝에 추가하고, 다음 그래프와 reward를 돌려주는 전이다. 선택한 lot은 다시 배정할 수 없으며, 설비는 나중 작업을 더 받을 수 있다. step마다 생산 사건을 실행하거나 실제 시계를 전진시키지 않는다.

경계	계약과 검사
reset 직후	snapshot 기준 시각 고정, 초기 예정 점유 복원, 대상 lot 집합과 유효 edge 생성
action 수신	해당 단계의 edge ID를 조합으로 해석하고 자격·미배정 여부 검사
부분 스케줄 갱신	append 후 설비 예상 가용시각 갱신, 선택 lot의 모든 edge 제거
다음 선택	남은 조합의 예상 시작·완료시각 재계산, 기준 시각 유지
생성 종료	모든 대상 lot이 정확히 한 번 배정되었는지 확인하고 완성 스케줄 평가

작은 예제에서 대상 lot이 $n$개이고 step마다 하나씩 붙인다면 정상 episode는 $n$번 선택으로 끝난다. 기준 시각이 그대로인 것은 정상이며, 미배정 수까지 줄지 않은 채 같은 상태를 반복하면 오류다. 미배정 lot이 남았는데 유효 edge가 없다면 정상 완료로 처리하지 않는다.

2. 생성 순서와 실제 실행 순서를 구분한다

(M1,L2)를 먼저 고르고 (M2,L1)을 나중에 골라도, 완성 스케줄에서는 두 lot을 시각 0에 동시에 시작할 수 있다. 조합을 고른 순서가 서로 다른 설비의 실제 시작 순서를 강제하는 것은 아니다. 반면 같은 설비에 붙인 lot의 순서는 실행 순서다.

따라서 중복 검사는 설비 하나의 상태만 보면 부족하다. (M1,L1) 뒤에는 (M2,L1)도 사라져야 한다. M1에 한 lot을 붙였다고 M1의 다른 edge까지 제거하면 이 과제를 한 번의 matching으로 바꾼 셈이다. 두 오류를 별도 검사한다.

모든 lot을 배정한 뒤 evaluator가 설비별 작업열을 재생한다. 결정적 예제에서는 시작·완료시각을 직접 계산해도 된다. 처리시간 변동이나 고장을 추가한 확장에서는 이산사건 시뮬레이터(DES)가 물리 시간을 진행시킨다. 그 내부 사건은 생성 policy의 새로운 action 호출이 아니다. 완성 스케줄이 고장 뒤에도 같은 순서로 이어지는지, 중간 재계획을 허용하는지도 확장 명세에 남긴다.

동시 완료와 상태 변경의 처리 순서는 이 실행 evaluator에서 정의한다. 예를 들어 완료와 고장이 같은 시각이면 어느 작업이 완료로 인정되는지 정하고, 사건 heap의 우연한 삽입 순서에 맡기지 않는다. 미래 사건을 재현하는 내부 상태와 policy에 공개할 관측은 구분한다.

3. reward 분배와 생산 시간 적분을 따로 검산한다

02편처럼 같은 최종 비용을 증분 reward로 나누기로 했다면, 각 단계의 합이 의도한 값인지 검사한다. 부분 비용을 $J_k$, 전체 배정 수를 $N$이라 할 때 $r_k=-(J_{k+1}-J_k)$이면 합은 $-(J_N-J_0)$이고, $J_0=0$이면 terminal reward $-J_N$과 같다. 이는 정한 비용 분배가 구현됐는지 확인하는 조건이지, RL 학습 자체의 필수 조건은 아니다. 예를 들어 reward를 모두 두 배로 바꾸면 합은 달라도 스케줄의 우열은 같다. 보조 reward를 추가했다면 그 식을 기준으로 검증하고, 원래 KPI와 다른 선택을 유도하지 않는지 별도 평가한다.

실행 evaluator에서는 물리 시간에 따른 WIP(Work in Process) 면적을 독립 계산할 수 있다. 여기서 WIP는 대기·가공 중인 미완료 대상 lot 수다. WIP 면적은 시간–WIP 그래프 아래의 면적, 즉 개수에 유지 시간을 곱해 누적한 재공시간이다. 총 lot 개수가 아니라 lot·시간 단위의 값이며, 2 lot이 3시간 남아 있으면 6 lot·시간이다. 이를 관측 기간으로 나누면 시간 평균 WIP가 된다.

생산 사건 시각 $u_0<\cdots <u_q$ 사이의 미완료 대상 수가 $N_i$라면 다음처럼 계산한다.

$${\int }_{u_0}^{u_q}N(t)dt=\sum _{i=0}^{q-1}{N}_i(u_{i+1}-u_i)$$

완료·투입으로 WIP가 바뀌면 구간을 나눠 각 상태가 유지된 시간만큼 센다. 마지막 WIP에 전체 시간을 곱하거나 사건마다 개수만 더하면 틀릴 수 있다. 이 적분은 실제 생산 timeline에서 수행하며, 생성 step마다 물리 시간이 흐른다는 뜻은 아니다.

대상 lot을 끝까지 추적하고 이탈이 완료뿐이라면 다음 관계로 교차 검산한다.

$${\int }_{t_0}^{{\max }_j{C}_j}N(t)dt=\sum _{j\in \mathcal{J}}\left(C_j-\max (R_j,t_0)\right)$$

왼쪽은 시각별 WIP로, 오른쪽은 lot별 체류시간으로 같은 누적값을 계산한다. 모두 시각 0에 투입된 공통 예제에서는 TCT와 같다. 초기 age가 있다면 적분은 snapshot 이후 체류시간만 세므로, 전체 TCT를 얻으려면 이전 age를 더해야 한다. 생성 reward와 실행 KPI가 같은 버그를 공유하지 않도록 서로 다른 계산 경로로 검산한다.

4. 두 설비·두 lot으로 정답을 만든다

01·02편과 같은 조건을 그대로 검산한다. M1·M2가 시각 0에 비어 있고 L1의 처리시간은 1/4시간, L2는 M1에서 8시간·M2에서 12시간이다. 두 lot은 모두 0에 투입되며 setup·고장·추가 도착은 없다.

선택 경로	완성 스케줄의 실제 처리 흐름	완료 L1/L2	makespan	TCT
(M1,L1) → (M1,L2)	M1: L1 0–1, L2 1–9	1 / 9	9시간	10 lot·시간
(M1,L2) → (M2,L1)	M1: L2 0–8, M2: L1 0–4	4 / 8	8시간	12 lot·시간

A의 WIP 면적은 $2\times 1+1\times 8=10$이고 B는 $2\times 4+1\times 4=12$다. 각 완료시각의 합과 일치한다. makespan은 각각 9와 8이다. 두 경로 모두 생성 step은 2번이고 생성 기준 시각은 끝까지 0이다.

검산용 비용을 $J=M+TCT$로 두자. 여기서는 단위를 비용으로 환산하는 계수를 각각 수치 1로 둔 설명용 식이다. A의 terminal reward는 -19이고, 부분 비용 증분으로 나누면 -2, -17이다. B는 terminal -20이며 증분 -16, -4다. 같은 비용을 분배한 이 예제에서는 할인 전 합이 각각 -19와 -20인지 검사한다. 이 가중합은 makespan 단독 목적이나 TCT 허용 한도를 대신하지 않는다.

실행 평가를 $H=5$시간에서 잘랐을 때도 확인한다. A의 WIP 면적은 $2\times 1+1\times 4=6$, B는 $2\times 4+1\times 1=9$다. 두 계획 모두 L2가 미완료이므로 이 면적을 완성 TCT라고 보고하지 않는다. 생성은 끝났지만 outcome 평가는 아직 끝나지 않았다는 구분이 필요하다.

다음에는 자격 없는 edge 하나, 진행 중 작업 하나, 처리시간 변동 하나를 차례로 추가한다. 조건마다 기대 스케줄과 timeline을 먼저 쓰고 결과와 대조한다. setup이나 고장을 한꺼번에 넣지 않아야 실패 원인을 좁힐 수 있다.

5. 종료와 수집 중단을 구분한다

Gymnasium은 과제 자체의 종료를 terminated, 외부 사유로 episode 진행을 끊는 경우를 truncated로 구분한다. 이 시리즈의 기본 episode는 모든 대상 lot을 배정하고 정한 evaluator로 최종 reward를 받으면 종료한다. 생성 중 rollout 수집만 끊었다면 마지막 부분 스케줄의 가치를 이어 추정할 수 있다. 반면 업무상 계산 마감 위반은 계약한 실패 경로이며, 단순 수집 중단처럼 성공 결과에서 빠뜨리지 않는다. Gymnasium: Handling Time Limits

실행 simulator의 관측을 5시간에서 끊었다는 것과 policy의 스케줄 생성 episode를 중간에 끊었다는 것은 다른 경계다. 완료 KPI가 필요한 과제라면 실행 평가를 이어가거나 평가 실패 규칙을 적용한다. 이어지는 운영을 제어하는 별도 과제로 바꾸었을 때만 그 시간 경계에 맞춰 value target을 다시 설계한다.

다음은 가치를 추정하는 critic의 한 단계 target을 설명하는 식이다.

$$y_k=r_k+{\gamma }_k(1-1\{\mathrm{terminated}\})V(o_{k+1})$$

실제 종료면 다음 가치가 없고, 단순 수집 중단이면 적절한 마지막 observation의 가치를 이어 붙인다. 이것을 bootstrap이라고 한다. 식은 한 단계 예시이며 실제 학습기의 return·advantage 계산은 여러 전이를 함께 사용할 수 있다. 기본 스케줄 생성 과제에서는 할인 없이 합산할 수 있고, 다른 discount를 쓴다면 그 의미와 실제 구현을 함께 명시한다.

자동 reset을 사용하는 수집기에서는 반환된 observation이 이미 새 episode의 초기 상태일 수 있다. 그 관측을 이전 episode의 마지막 상태처럼 사용하면 엉뚱한 미래 가치를 연결한다. 종료 플래그와 마지막 observation의 전달 경로를 작은 테스트로 확인해야 한다. 라이브러리마다 반환 규약이 달라 구체적인 학습기 연결은 07편에서 다룬다.

6. API 검사와 업무 동작 검사를 분리한다

Gymnasium의 environment checker는 observation/action space와 반환 인터페이스 등을 확인하는 유용한 출발점이다. 하지만 검사 통과가 lot 보존이나 실제 공정의 재현성을 보증하지는 않는다. mask와 무관하게 뽑은 action이 전달될 수 있다는 점도 고려해야 한다. 환경은 invalid action을 명확한 오류로 거절할지, 별도 정의한 처리로 응답할지 계약을 정하고, 유효 행동 검사는 mask를 사용하는 별도 경로에서 수행한다. Gymnasium: Utility Functions

invalid action을 받아 조용히 첫 번째 유효 edge로 바꾸는 처리는 피해야 한다. 기록된 행동과 실제 실행한 행동이 달라져 학습 데이터의 의미가 흐려진다. mask 오류로 학습 중 금지 행동이 나왔다면 통상적인 탐색 실패처럼 넘기지 말고 원인을 기록하고 해당 실행을 점검한다.

생성 단계에서는 다음 관계와 ID 유일성을 매번 확인한다.

$$N_{\mathrm{target}}=N_{\mathrm{assigned}}+N_{\mathrm{unassigned}}$$

선택마다 미배정 수가 정확히 하나 줄어야 한다. 같은 lot을 두 번 붙이지 않고, 설비별 작업열에서 이전 완료시각보다 다음 시작시각이 빠르지 않은지도 검사한다. 그래프의 선택 가능 edge와 미배정 집합이 같은 대상을 가리켜야 한다.

실행 evaluator에서는 고정 대상의 수가 완료 lot 수 + 미완료 lot 수와 같은지 확인한다. 한 lot이 두 설비에서 동시에 처리되지 않는지, 각 설비에서 배정 순서대로 실행되는지도 검사한다. 작업을 대상에서 제거하는 예외를 추가했다면 제거 사유와 KPI 분모 변경 규칙을 별도로 정의한다.

진행이 멈췄을 때도 두 경로를 구분한다. 생성 중 미배정 lot은 남았는데 edge가 없으면 실패다. 실행 중 모든 설비가 처리 중이라 다음 완료를 기다리는 것은 정상이다. 미완료 작업이 있는데 실행 가능한 이동도, 자원을 풀어 줄 사건도 없다면 실행 모델 오류나 제약 충돌을 조사한다. 어느 경우든 멈춘 표본을 좋은 성과의 평균에서 조용히 빼지 않는다.

7. 구현이 맞는가와 현실을 닮았는가는 다른 질문이다

verification은 정한 모델과 규칙을 코드가 올바르게 구현했는지 확인하는 일이다. 앞의 보존식과 두 설비·두 lot 검산이 여기에 해당한다. validation은 그 모델이 의도한 실제 시스템을 용도에 충분하게 재현하는지 확인하는 일이다. 코드에 오류가 없어도 처리시간 분포나 설비 정지 구조가 현실과 다르면 학습 근거는 약해진다.

운영 데이터를 추가한 확장에서는 현행 계획을 재생한 simulator와 실제 운영을 비교할 때 같은 초기 WIP·투입·설비 달력으로 맞춘 뒤, 총생산량뿐 아니라 제품별 대기·setup·고장 복구·WIP 변화의 시간 경로를 살펴본다. 보정에 쓴 기간과 검증 기간은 구분한다. 평균만 맞추려고 parameter를 조정하면 서로 다른 오류가 상쇄될 수 있다.

현행 규칙을 재현했다는 사실만으로 다른 policy의 행동 효과까지 검증되지는 않는다. 드물었던 제품 전환이나 특정 설비로의 집중 배정처럼 후보 policy가 더 자주 만드는 조건은 추가 근거가 필요하다. 근거를 확보하기 어려운 영역은 학습·적용 범위에서 제한하고 한계로 남긴다.

최종 보고서는 다음처럼 다음 단계의 판단에 필요한 정보를 담는다.

항목	기록할 내용
재현 식별자	simulator·입력 데이터·규칙·schema 버전, seed와 초기 상태
verification 결과	대상 보존, 손계산 timeline, edge 갱신, 중복·누락·invalid action, 실행 정지 사례의 기대값과 실제값
validation 범위	대조한 기간·제품·설비·운영 조건과 지표별 오차
사용 한계	검증하지 못한 제품 전환·극단 부하·고장 조합과 적용 제한
판단	학습 가능 범위, 보완할 항목, 변경 시 다시 실행할 검사

검증은 “simulator 검증 완료”라는 단일 표시에 가두기 어렵다. 어떤 결정을 학습하고 어느 조건에서 평가할 것인지에 따라 필요한 신뢰 범위가 달라진다. 다음 편에서는 이 보고서의 사용 범위를 바탕으로 정상·변화·장애 조건을 평가 시나리오로 구체화한다.

참고문헌

• Farama Foundation, Gymnasium — Handling Time Limits. 공식 문서
• Farama Foundation, Gymnasium — Utility Functions. 공식 문서

이전: 03. 관측과 행동 설계 · 시리즈 목차 · 다음: 05. 평가 시나리오