홍보센터

㈜유비씨 개발 본부 조승민 팀장 / smc@uvc.co.kr

AI에게 시뮬레이터를 쥐여주면 무엇이 달라지는가

1. 챗봇은 답을 하고, 에이전트는 실험을 한다

생산 능력을 늘려야 할 때 회의실에서 가장 먼저 나오는 질문은 대개 이런 모양이다. "물류 차량을 몇 대 더 넣어야 합니까." "저 공정 앞 버퍼를 두 배로 키우면 생산량이 얼마나 오릅니까." 확신을 갖고 답하는 사람은 드물다. 현장을 오래 본 책임자가 경험으로 범위를 좁혀주면 그것이 사실상 결론이 된다.

이 질문에 인공지능(AI)이 답하는 방식에는 두 갈래가 있다. 하나는 학습한 지식에서 그럴듯한 답을 꺼낸다. 다른 하나는 그 공장의 모델을 세워 조건을 바꿔가며 실제로 돌려보고 결과를 비교해 답을 만든다. 앞의 방식은 빠르지만 그 답이 이 공장의 답인지 확인할 길이 없다. 뒤의 방식은 시간이 걸리는 대신 근거가 남는다.

제조에서 AI를 쓸 때 진짜로 걸리는 지점은 똑똑함보다 신뢰다. 그 판단을 믿을 수 있어야 쓴다. 믿으려면 확인해야 하고 확인하려면 명령이 설비에 닿기 전에 먼저 돌려볼 자리가 있어야 한다. 시뮬레이터가 그 자리를 맡는다. 이 글은 그 도구를 사람이 아니라 AI가 쥐었을 때 무엇이 달라지는지에 관한 이야기다.

[사진 1] OCTOPUS Simulator 실행 화면 — 이 글에 계속 나오는 반도체 공정 예시 모델이다.

출처: OCTOPUS Simulator

2. 시뮬레이션은 미래를 맞히는 도구가 아니라 실패를 미리 겪어보는 도구다

제조의 의사결정에는 되돌리기 어렵다는 특징이 있다. 설비 배치나 버퍼 용량은 한 번 깔고 나면 바꾸는 데 추가 투자와 생산 중단이 따른다. 현장은 결정하기 전에 확인하고 싶어 하지만 확인할 방법이 마땅치 않았다.

엑셀로 하는 용량 산정은 평균을 다룬다. 그런데 공장을 멈추는 것은 평균이 아니라 변동과 상호작용이다. 앞 공정이 3분 늦어져 뒤 버퍼가 찬다. 버퍼가 찼기 때문에 운반 차량이 짐을 내리지 못하고, 그 차량을 기다리던 다른 공정이 멈춘다. 이런 연쇄는 각 공정의 평균 처리시간을 아무리 정교하게 더해도 나오지 않는다. 시간 순서대로 하나씩 일어나게 해봐야 나온다.

이산사건 시뮬레이션(DES, Discrete Event Simulation)이 하는 일이 그것이다. 공장에서 일어나는 일을 사건 단위로 재현해 사건들이 서로를 막고 기다리게 만드는 과정을 그대로 따라간다. 그래서 시뮬레이션의 쓸모는 미래를 정확히 맞히는 데 있지 않다. 현장에서 겪으면 라인을 멈추게 할 실패를 가상에서 여러 번 겪어보고 버리는 데 있다.

그런데도 시뮬레이션은 아직 제조 현장의 일상 도구가 아니다.

3. 시뮬레이션이 일상 도구가 되지 못한 이유는 모델 만들기에 있다

적어도 우리가 해온 프로젝트에서 시간을 잡아먹은 쪽은 실행이 아니었다. 모델을 만들고 실험을 설계하는 일이었다.

상용 시뮬레이션 도구는 대체로 배우는 데 오래 걸린다. 쓸 만한 공장 모델 하나를 세우는 데는 익숙한 사람이 붙어도 몇 주가 걸리는 일이 흔하다. 그런 사람이 조직에 많지 않으니 시뮬레이션은 늘 대기가 걸린 자원이 된다. 현장에서 "이 조건도 한번 봐달라"는 요청이 올라와도 결과가 나오기까지 몇 주가 걸린다면 결정은 이미 다른 근거로 내려진 뒤다.

더 어려운 것은 모델을 다 만든 다음이다. 실험을 설계해야 한다. 바꿔볼 조건이 다섯 개이고 각 조건에 후보값을 셋씩만 둬도 조합은 243가지가 된다. 전부 돌릴 수는 없으니 사람이 경험으로 추린다. 문제는 이 추림이 제약이라는 점이다. 후보에서 빠진 조합은 끝까지 확인되지 않는다. 사람의 경험이 곧 탐색 범위의 한계가 된다.

시뮬레이션은 한 번 만들어 한 번 보고하는 프로젝트 산출물에 머물렀다. 도구가 부족했다기보다 그 도구를 계속 쓸 수 있는 구조가 없었다.

4. AI가 모델을 만들고 고친다

OCTOPUS Simulator가 바꾸려는 것이 이 지점이다. 우리 제품의 AI 에이전트는 실험 설계보다 모델 만들기를 먼저 맡는다.

사용자는 빈 시나리오에서 대화로 시작할 수 있다. 공정 순서와 설비 구성을 설명하면 에이전트가 설비를 만들고 흐름을 연결한 뒤 처리 시간이나 고장 조건 같은 값을 채운다. 만들어진 모델을 고치는 일도 같은 방식이다. 설비를 더하고 빼고 다른 것으로 바꾼다. 배치를 정리하고 운반 차량이 다닐 통로와 정차 지점을 놓으며, 벽과 작업 구역을 그린다. 결과를 무슨 지표로 볼지도 대화로 정한다.

이 대화는 별도의 창에서 따로 벌어지지 않는다. 3D 배치를 보던 화면에서든 결과 지표를 보던 화면에서든 에이전트는 사용자가 지금 무엇을 보고 있는지를 안다. 고칠 대상을 매번 다시 설명할 필요가 없다. "저 설비는 왜 계속 기다리지"처럼 화면을 가리키며 던지는 질문에도 그 대상을 놓고 답한다.

[사진 2] 차량 한 대를 넣으라는 한 문장이 세 가지 변경 제안이 되고, 적용 범위는 사람이 고른다.

출처: OCTOPUS Simulator

에이전트는 모델 파일을 직접 고쳐 쓰지 않는다. 사람이 말하는 단위로 정의된 편집 명령이 수십 가지 준비되어 있고 에이전트는 그중에서 고른다. 예를 들어 "이 두 공정 사이에 검사 설비를 하나 넣어줘"는 명령 하나로 끝난다. 그 안에서 설비를 만들고 기존 연결을 끊었다가 다시 잇는 세 가지 일이 한꺼번에 일어난다. "이 설비는 빼고 앞뒤를 이어줘"도 마찬가지다. 사람이 도면을 보며 생각하는 단위와 에이전트가 다루는 단위가 같다.

AI에게 모델 파일을 통째로 다시 쓰게 하면 고쳐달라고 한 곳 말고 다른 데가 조용히 바뀐다. 명령 단위로 다루면 무엇을 바꿨는지가 목록으로 남고 의도하지 않은 변경이 섞이지 않았는지 사람이 검토할 수 있다.

이 제품에서 AI가 맡는 범위는 최적화 한 대목보다 넓다. 모델을 만들고 고치고 돌리며, 결과를 읽고 개선안을 찾아 다시 반영하는 과정 전체다.

5. AI가 병목을 진단하고 실험을 설계한다

모델이 만들어지면 다음 문제는 무엇을 바꿔볼 것인가다. 에이전트는 여기서도 실험을 직접 돌린다. 결과를 보기 좋게 요약해주는 보조가 아니다.

에이전트는 먼저 실행 결과를 읽고 병목을 찾는다. 어느 공정 앞에서 대기가 길어지는지, 어느 자원이 놀고 있는지를 지표에서 읽어낸다. 대기가 긴 지점과 노는 지점이 어떻게 연결되는지도 함께 본다. 여기서 가설이 나오면 그 가설을 확인할 실험을 스스로 설계한다. 연속적인 값을 다뤄야 하면 실험계획법(DOE)을, 조합이 너무 많아 전부 돌릴 수 없으면 유전 알고리즘(GA)을, 설비를 더하거나 빼는 구조 변경을 봐야 하면 구조 탐색(Sweep)을 고른다. 실험을 실행해 결과를 기준선과 비교하고 다시 진단으로 돌아간다.

다만 무엇을 탐색할지는 에이전트가 혼자 정하지 않는다. 바꿀 수 있는 값이 무엇이고 지금 얼마이며 어느 범위까지 훑을지를 후보로 정리해 먼저 내놓고 사용자가 고른 뒤에 돌린다. 목표가 분명해도 이 단계는 건너뛰지 않는다. 어떤 범위를 훑었는지 모르는 채로 받은 답은 검증할 수가 없기 때문이다.

[사진 3] 돌리기 전에 무엇을 어느 범위로 훑을지 먼저 묻는다.

출처: OCTOPUS Simulator

우리는 새로운 AI 모델을 만들지 않았다. 판단은 언어모델이 하고 계산은 시뮬레이션 엔진이 한다. AI는 어떤 실험을 할지 정할 뿐이고 숫자는 실제로 돌아간 시뮬레이션이 낸다. 이 구조에서 나온 결과는 모델이 그럴듯하게 지어낸 값이 아니라 다시 돌려 확인할 수 있는 실행 기록이다.

6. 차를 늘리자 배치 문제가 가려졌다

반도체 공정을 본뜬 예시 모델을 놓고 네 단계짜리 자동 탐색을 짜서 54번을 돌린 적이 있다. 산화로 6대, 노광기 10대, 식각기 8대, 증착기 8대, 계측기 4대로 설비 36대에 운반 차량이 붙는 구성이다. 레이아웃 8종과 AMR 대수를 훑어 후보를 좁혔다. 좁힌 레이아웃에서 설비 입출구 방향을 바꿔보고 남은 조합의 대수를 넓힌 뒤, 최종 후보 다섯을 30일 길이로 다시 확인했다. 탐색이 최대화한 값은 단순 생산량이 아니라 균형 출고량과 과잉 투입, 설비 구성을 함께 반영한 내부 지표였다. 아래 숫자는 해석이 갈리지 않도록 처리량과 가동률로 옮겨 적었고 모두 레이아웃 8종의 평균이다.

직관적인 가설은 운반 차량을 늘리는 것이었다. 3대에서 4대로 늘릴 때는 처리량이 22.3% 뛰었다. 부족했던 것이 맞았다. 그런데 4대에서 7대까지 세 대를 더 넣는 동안 처리량은 4.0%밖에 오르지 않았다. 차량 한 대당 평균 가동률은 20.7%에서 11.2%로 거의 절반까지 내려갔다.

배치는 반대로 움직였다. 차가 3대일 때는 레이아웃에 따라 처리량이 15.7% 갈렸는데 7대에서는 그 차이가 2.2%로 좁혀졌다. 설비 평균 가동률이 3대에서 71.2%였다가 4대부터 87%를 넘어서니 차량보다 설비 쪽 한계가 먼저 걸리기 시작했다. 차를 넉넉히 넣으면 어느 배치든 그 한계까지 밀린다. 뒤집으면 이렇게 된다. 배치를 잘 잡은 4대가 평균적인 7대와 거의 같은 처리량을 냈다. 차 세 대에 해당하는 처리량 차이가 배치 안에 들어 있었던 셈이다.

레이아웃 8종과 AMR 대수 다섯 가지를 조합하면 40개 조건이 나온다. 손으로 빠짐없이 비교하기는 번거롭다. 이 사례 자체는 미리 정한 규칙으로 돌린 자동 탐색이지만 에이전트가 넓은 후보군을 훑을 때 하는 일도 같은 성격이다. 계산을 대신 해주지는 않는다. 손으로는 번거로워서 빠뜨리는 조합까지 열어본다.

[사진 4] 4대를 넘어서면 처리량은 거의 오르지 않는다.

출처: OCTOPUS Simulator

7. 이것이 가능한 이유는 모델이 데이터이기 때문이다

지금까지 설명한 일이 가능하려면 모델이 AI가 다룰 수 있는 형태여야 한다. 사소해 보이지만 결정적인 조건이다.

기존 도구들도 스크립트와 API를 제공한다. 다만 모델 자체는 그 도구 고유의 프로젝트 파일에 담겨 있고 자동화도 도구가 정해둔 방식을 따라야 한다. 외부 에이전트가 모델을 읽고 고치려면 그 사이를 잇는 계층을 따로 만들어야 한다.

OCTOPUS Simulator는 시나리오 모델 전체가 JSON으로 선언된다. 설비, 연결, 동작 로직이 모두 읽고 쓸 수 있는 데이터다. 세 주체가 같은 것을 본다. 사람이 브라우저에서 편집하는 대상, 외부 시스템이 API로 읽는 대상, AI가 명령으로 고치는 대상이 모두 같은 구조다.

이 모델은 웹에서 바로 열린다. 설치가 필요 없다. 3D 화면은 결과를 보여주는 창이 아니라 그 자체가 편집 환경이다. 설비 배치와 연결은 물론이고 벽, 통로, 운반 차량의 주행 경로, 작업 구역 같은 공간 요소를 실제 공간을 보면서 직접 편집한다. 2D 흐름도는 같은 모델을 로직 중심으로 본 다른 화면이다.

이 구조를 잡는 데는 시간이 오래 걸렸다. 컴포넌트를 어떤 단위로 나눌지, 무엇을 포트로 드러내고 무엇을 안으로 감출지, 동작을 어떤 어휘로 조립할지를 하나씩 정해야 했다. 사람이 다루기 좋게 정리해둔 그 구조가 그대로 에이전트가 다루기 좋은 구조가 됐다. 앞에서 본 편집 명령들도 그 위에 얹힌 것이다. 바탕이 조립식이 아니었다면 "두 공정 사이에 끼워 넣어라" 같은 명령은 애초에 성립하지 않는다.

8. 마치며 — 틀려도 되는 곳에서 먼저 틀려본다

AI가 모델을 고칠 수 있다면 AI가 모델을 망칠 수도 있다. 그래서 제안과 적용 사이에 관문을 두었다. 에이전트가 제안한 변경은 기본적으로 대기 상태로 올라온다. 사용자는 이번 것만 적용할 수도 있고 세션이나 프로젝트 범위에서 자동 적용을 허용할 수도 있다. 자동으로 적용되는 경우에도 검사는 그대로 거친다. 적용 직전 상태는 자동으로 보관되어 버튼 한 번으로 되돌릴 수 있다. 제안이 만들어진 뒤 사람이 모델을 먼저 손댔다면 그 제안은 적용되지 않고 거부된다. 적용 전에는 없는 설비를 지어내지 않았는지, 배치가 겹치지 않는지 확인하는 검사가 돈다.

제안이 거부되는 일은 생각보다 자주 나온다. 사람이 먼저 모델을 손봐놓고 그 전에 받아둔 제안을 뒤늦게 적용하려는 경우가 흔하기 때문이다. 그때마다 적용은 막히고 에이전트가 바뀐 모델을 다시 읽어 제안을 새로 만든다.

모델을 만드는 일과 실험을 설계하는 일은 오래 전문가 한두 명의 몫이었다. 그 두 가지를 에이전트가 맡으면서 시뮬레이션은 한 번 만들어 한 번 보고하는 산출물에서 궁금할 때마다 물어보는 도구 쪽으로 옮겨가고 있다.

에이전트가 내놓는 답도 결국 시뮬레이션의 답이다. 모델이 현장과 다르면 답도 다르다. 그래서 이 도구가 대신해주는 것은 판단이 아니라 판단의 근거다. 설비를 세우기 전에, 라인을 바꾸기 전에, 틀려도 되는 곳에서 먼저 틀려보는 일이다.