공정 제어는 왜 알고리즘보다 구축과 운영이 어려운가

공정 제어를 이야기할 때는 보통 어떤 알고리즘을 쓰는지부터 봅니다. 하지만 양산에서는 알고리즘을 고르는 일보다 그 로직을 실제 공정에 올려 계속 돌리는 일이 더 어렵습니다. 공정에 맞게 만들고 검증한 뒤, 조건이 바뀌고 예외가 생겨도 운영해야 하고, 다음 제품이나 장비에서도 다시 써야 합니다.

제어식이나 모델은 생각보다 단순할 수 있습니다. 코드 몇 줄이면 끝나는 경우도 있습니다. 문제는 그다음입니다. 어떤 데이터를 받아 언제 계산할지, 계산 결과를 써도 되는 상태인지, recipe는 어디까지 바꿔도 되는지 같은 기준이 필요합니다. 데이터가 빠지거나 이상해졌을 때의 처리와 rollback도 정해둬야 합니다.

이런 일을 빼고 알고리즘의 복잡도나 예측 정확도만 비교하면, 실제 양산에서 들어가는 일의 큰 부분이 보이지 않습니다.

세 접근은 제어 로직보다 그 주변을 어디까지 직접 만들어야 하는지가 다릅니다

그림은 레거시 rule 기반 제어, 커스텀 코드 기반 제어, Amfibian을 구축 용이성, 커스터마이징, 양산 운영, 확장·재사용, 사전 검증의 다섯 관점에서 비교합니다. 어느 한 방식이 항상 우월하다는 뜻은 아닙니다. 각각 사람이 직접 해야 하는 engineering work의 위치가 다릅니다.

기존 fab 제어 플랫폼의 rule 기반 제어, 사람이 직접 분석하고 구현하는 커스텀 코드 기반 제어, Amfibian의 구축과 운영 특성을 개념적으로 비교한 그림입니다.

레거시 rule 기반 제어: 이미 양산에
자리 잡았지만, 표현할 수 있는 로직에는
한계가 있습니다

많은 fab에는 이미 오래전부터 APC나 R2R 형태의 제어 플랫폼이 들어가 있습니다. 이 환경에서는 엔지니어가 플랫폼 안에서 사칙연산, 조건식, limit, 간단한 rule을 조합해 다음 run의 recipe를 계산합니다. MES와 계측 데이터 연결, 실행 시점, 권한과 운영 절차가 이미 갖춰져 있다는 점은 큰 장점입니다. 한번 검증된 로직은 양산에서 안정적으로 오래 쓸 수 있습니다.

문제는 공정이 복잡해질수록 이런 표현 방식만으로는 부족해진다는 점입니다. 변수 간 비선형 관계나 다변량 상호작용, Virtual Metrology, 이상 상태에 따른 gating, 여러 모델을 조합하는 로직을 넣으려면 기존 플랫폼이 허용하는 계산식과 rule의 범위를 넘어가기 쉽습니다. 결국 복잡한 문제일수록 로직이 길어지고 예외가 늘어나거나, 플랫폼 밖에서 별도의 분석과 계산을 한 뒤 결과만 연결하는 구조가 됩니다.

즉 레거시 플랫폼의 약점은 양산 운영 자체가 아닙니다. 오히려 운영은 이미 잘 되어 있습니다. 한계는 새로운 제어 방법을 만들고 검증하는 표현력과 개발 속도, 그리고 복잡한 로직을 다른 공정으로 확장하는 방식에 있습니다.

커스텀 코드 기반 제어:
레거시의 한계를 넘을 수 있지만,
사람이 시스템까지 직접 만들어야 합니다

두 번째 방식은 공정 엔지니어나 데이터 사이언티스트가 데이터를 직접 분석하고, 문제에 맞는 모델·계산 로직·예외 처리를 Python이나 R 같은 코드로 직접 작성하는 방식입니다. 레거시 플랫폼의 사칙연산과 rule만으로 표현하기 어려운 관계를 다룰 수 있고, 공정 특성에 맞춰 원하는 만큼 자유롭게 설계할 수 있습니다.

반대로 그 자유도만큼 사람이 책임져야 하는 범위도 넓습니다. 분석 코드를 production code로 옮기고, MES나 계측 데이터와 연결하고, 실행 trigger를 만들고, input이 비정상일 때의 동작과 안전 범위를 정하고, 모델이나 로직이 바뀔 때마다 검증해야 합니다. 배포 후에는 상태를 확인하고 update와 rollback도 관리해야 합니다.

한두 공정에서는 잘하는 사람이 직접 관리할 수 있습니다. 하지만 제품과 장비가 늘어나면 비슷한 data connection, validation, exception handling, deployment logic을 프로젝트마다 반복해서 만들게 됩니다. 담당자가 바뀌면 코드의 맥락을 다시 이해해야 하는 문제도 생깁니다. 커스텀 코드는 제어 로직의 자유도를 크게 높이지만, 그 코드를 양산 시스템으로 만드는 일까지 자동으로 해결해주지는 않습니다.

Amfibian: 제어 로직의 자유도와
양산 운영 구조를
한 workflow 안에 둡니다

Amfibian은 레거시 플랫폼의 운영 안정성과 커스텀 코드의 유연성 사이에서, 반복되는 구축과 운영 작업을 제품화하는 방향입니다. 엔지니어는 Studio에서 모델과 제어 로직을 구성하고, Digital Twin에서 적용 전에 검증하고, 검증된 package를 Runtime에서 생산 데이터에 연결해 운영합니다. DOE, Virtual Metrology, Process Control Apps도 같은 데이터·검증·운영 구조를 공유합니다.

핵심은 특정 알고리즘 하나를 제공하는 것이 아닙니다. 계산식, 통계 모델, 머신러닝 모델, 여러 제어 로직 가운데 문제에 맞는 방식을 선택하되, 그 주변에서 반복되는 구축, 검증, 배포, 운영, 변경 관리의 구조는 공통으로 가져가는 것입니다. 한 공정에서 만든 방법이 다음 공정에서는 처음부터 다시 만드는 코드가 아니라 출발점이 되도록 하는 것이 목적입니다.

양산에서 어려운 일은 제어값을 계산한 다음부터 시작됩니다

실제 fab에서는 controller가 숫자 하나를 내놓은 뒤에도 계속 판단해야 합니다. 지금 어떤 version이 돌고 있는가. 어떤 공정 조건에서 이 결과를 사용해도 되는가. input이 늦거나 빠졌을 때는 어떻게 할 것인가. 조정 가능한 범위를 어떻게 제한할 것인가. 공정이 변하면서 기존 로직이 더 이상 맞지 않는다는 것을 어떻게 알 것인가. 문제가 생기면 어디까지 되돌릴 것인가.

레거시 플랫폼은 이 운영 문제를 오랜 기간 해결해왔습니다. 다만 복잡한 로직을 표현하고 빠르게 실험하기 어렵습니다. 커스텀 코드는 그 제약을 크게 줄이지만, 이번에는 구축과 운영 체계를 사람이 직접 만들어야 합니다. Amfibian의 역할은 이 둘의 장점을 이어서, 더 자유로운 모델과 제어 로직을 기존 양산 시스템 수준으로 검증하고 운영할 수 있게 하는 데 있습니다.

이 차이는 제품, 장비, 공정의 수가 늘어날수록 커집니다. 제어 프로젝트마다 데이터 연결, 검증 방법, 배포 절차, 운영 기준을 새로 만들면 engineering effort도 프로젝트 수에 가깝게 늘어납니다. 반대로 이 부분을 공통화하면 다음 프로젝트는 이미 검증된 운영 방식에서 시작할 수 있습니다.