DGX와 Local LLM으로 공정 제어를 실험하면서 배운 것

AI가 공정을 직접 제어해도 될까?

요즘 이 질문을 계속 생각하고 있다. 결론부터 말하면, 나는 제한된 조건 안에서는 가능해질 것이라고 본다. 다만 여기에는 아주 중요한 전제가 있다. AI가 기존 제어 시스템을 우회하면 안 된다. PLC, RTOS, 인터락, 레시피 제한, 작업 권한 같은 안전 경계 안에서만 개입해야 한다.

즉, 내가 생각하는 산업 AI의 방향은 AI가 제어기를 대체하는 구조가 아니다. 오히려 반대다. 결정론적 제어 코어는 기존 제어 시스템이 계속 책임지고, AI는 그 위에서 상태를 이해하고, 도구를 선택하고, 제한된 액션을 제안하는 보조 계층이 되어야 한다.

이 글은 그 관점에서 DGX와 Local LLM을 이용해 공정 제어 구조를 실험하면서 정리한 생각이다.

시작은 꽤 단순했다

대표님이 DGX를 사주시면서 “LLM이든 AI든 마음대로 해봐라”라고 하셨다. 그래서 받자마자 Local LLM을 올리고, 이것저것 붙여보기 시작했다.

처음에는 단순히 로컬에서 모델이 얼마나 잘 도는지, 응답 품질이 어느 정도인지, 도메인 컨텍스트를 얼마나 이해하는지 확인하는 정도였다. 그런데 막상 만져보니 생각보다 가능성이 선명했다. 이제 Local LLM은 단순히 대화만 하는 모델이 아니라, 특정 시스템의 상태를 읽고, 도구를 호출하고, 원하는 출력으로 이어지는 흐름을 만들 수 있는 단계에 와 있다.

특히 산업 자동화에서는 이 변화가 꽤 중요하다. 공정 데이터는 외부 클라우드로 마음대로 보낼 수 없는 경우가 많고, 지연 시간이나 보안 요구도 높다. 그래서 모든 것을 외부 API에 의존하는 구조보다는, 현장 가까이에 모델을 두고 필요한 범위 안에서 판단을 수행하는 Edge AI 구조가 더 자연스럽다.

내가 만든 구조

현재 실험 중인 구조를 단순화하면 다음과 같다.

Local LLM Agent
    ->
Tool Calling
    ->
Guard Layer
    ->
PLC / Process Interface
    ->
Feedback

여기서 가장 중요한 점은 LLM Agent가 PLC를 직접 우회하지 않는다는 것이다.

Agent는 공정 상태를 읽고, 어떤 tool을 써야 할지 선택하고, 제한된 액션을 요청할 수 있다. 하지만 실제 실행은 별개의 문제다. 요청된 액션은 Guard Layer를 지나야 하고, 그 안에서 권한, 레시피 범위, 쓰기 가능한 loop인지 여부, 명령 횟수, 실제 반영 여부, feedback 상태를 확인한다.

이 구조에서 AI는 “명령을 내리는 존재”라기보다 “제안하고 조율하는 존재”에 가깝다. 최종 권한은 여전히 제어 시스템 쪽에 있어야 한다.

왜 Guard Layer가 핵심인가

산업 제어에서 LLM을 붙일 때 가장 위험한 착각은 모델이 똑똑해졌으니 더 많은 권한을 줘도 된다고 생각하는 것이다.

나는 반대로 봐야 한다고 생각한다. 모델이 똑똑해질수록, 모델이 할 수 없는 일을 더 명확하게 정의해야 한다. 자연어 명령은 편하지만, 그만큼 모호하다. “조금 올려줘”, “안정화해줘”, “최적화해줘” 같은 말은 사람에게는 자연스럽지만 PLC 입장에서는 위험한 명령이 될 수 있다.

그래서 Guard Layer에서는 최소한 다음과 같은 것들이 필요하다.

• authority check: 이 요청을 수행할 권한이 있는가
• recipe limit: 설정값이 레시피 범위 안에 있는가
• writable loop check: 이 loop가 AI 요청으로 쓰기 가능한 대상인가
• command budget: 짧은 시간 안에 너무 많은 명령을 보내고 있지 않은가
• echo verification: 쓴 값이 실제로 반영되었는가
• feedback check: 실행 이후 PV나 상태가 예상 가능한 방향으로 움직이는가

이런 장치가 있어야 LLM의 액션이 실제 공정에 연결될 수 있다. Guard Layer 없이 Agent를 PLC에 붙이는 것은, 편리한 인터페이스를 만든 것이 아니라 위험한 우회로를 만든 것에 가깝다.

실제로는 많이 막힌다

재미있는 점은 Guard Layer를 강하게 걸수록 오히려 제어가 잘 안 되는 상황이 생긴다는 것이다.

예를 들어 Agent가 어떤 SP를 조정하려고 해도, 레시피 제한이나 command budget에 걸려서 실제 액션이 거의 일어나지 않을 수 있다. 또는 Agent가 의도한 변화량이 너무 작아서 공정에는 의미 있는 영향이 없을 수도 있다. 반대로 제한을 너무 느슨하게 풀면 안전성이 떨어진다.

결국 중요한 질문은 이것이다.

어디까지 막고, 어디부터 허용할 것인가?

이 질문은 단순한 소프트웨어 권한 문제가 아니다. 공정 특성, 제어 대상, 위험도, operator 개입 방식, 설비 상태를 모두 고려해야 한다. 산업 AI에서 어려운 부분은 모델을 붙이는 것보다, 모델이 개입할 수 있는 경계를 설계하는 데 있다.

AI는 Controller가 아니다

이번 실험에서 가장 명확하게 가져간 원칙은 이것이다.

AI는 controller가 아니다. AI는 bounded supervisory layer다.

시간 결정성이 필요한 계층은 RTOS와 PLC가 책임져야 한다. B&R에서 제공하는 RTOS runtime의 장점도 바로 여기에 있다. 실시간 제어, 인터락, critical sequence, 최종 출력 권한은 deterministic layer에 남아 있어야 한다.

반면 LLM Agent는 non-deterministic reasoning layer로 두는 것이 맞다.

RTOS / PLC
    -> deterministic control layer

LLM Agent
    -> non-deterministic reasoning and orchestration layer

이 둘을 섞으면 안 된다. LLM이 제어 루프 안으로 직접 들어오는 순간, 가장 중요한 품질인 예측 가능성과 재현성이 흔들릴 수 있다. 하지만 LLM을 상위 supervisory layer로 두면 이야기가 달라진다. 상태를 해석하고, operator가 봐야 할 정보를 정리하고, 반복적인 판단 절차를 보조하고, 허용된 범위 안에서 액션을 요청하는 역할은 충분히 가능하다.

초기 실험에서 보인 가능성

아직 정량적인 성능 평가를 할 단계는 아니다. 민감한 공정 변수에 바로 붙인 것도 아니고, PV 변화 추이에 따라 특정 element의 SP를 조심스럽게 조정하는 초기 실험에 가깝다.

그럼에도 한 가지 가능성은 꽤 분명하게 보였다.

operator가 직접 개입해야 하는 상황을 줄일 수 있다.

산업 현장에서는 사람이 항상 모든 상태를 같은 밀도로 보고 있을 수 없다. 알람, 트렌드, 레시피, 운전 상태, 품질 결과, 이전 조치 이력까지 동시에 고려해야 하는 경우가 많다. LLM Agent가 이 정보를 한 번에 해석하고, 가능한 액션 후보를 좁혀주고, 왜 그런 판단을 했는지 설명할 수 있다면 operator의 부담을 줄일 수 있다.

여기서 중요한 것은 “사람을 빼는 것”이 아니다. 사람이 더 좋은 판단을 하도록 돕는 것이다.

앞으로 확장하고 싶은 방향

지금 구조는 아직 rule-based orchestration에 가깝다. tool을 정의하고, Guard Layer를 두고, feedback을 확인하는 방식이다. 하지만 여기서 한 단계 더 가면 더 흥미로운 구조가 가능하다.

예를 들면 다음과 같다.

• telemetry 기반 feedback 수집
• 반복 조치 결과 기록
• 실패한 액션과 성공한 액션의 비교
• 공정 상태별 추천 policy 개선
• operator가 승인/거절한 판단 이력 학습

이렇게 쌓이면 Agent는 단순히 rule을 따라 tool을 호출하는 수준을 넘어, 특정 공정과 특정 설비의 운전 맥락을 점점 더 잘 이해하는 시스템이 될 수 있다.

물론 여기서도 제어 코어를 대체하면 안 된다. 개선되는 것은 제어기가 아니라 supervisory policy여야 한다. 즉, 어떤 상황에서 어떤 후보 액션을 제안할지, 어떤 정보를 operator에게 먼저 보여줄지, 언제 개입하지 말아야 할지를 더 잘 배우는 방향이 맞다.

내가 이 주제를 계속 파고드는 이유

내가 이 주제를 재미있게 느끼는 이유는, 그동안 따로 공부해온 것들이 한 지점에서 만나는 느낌이 들기 때문이다.

제어공학은 시스템이 어떻게 움직이는지 보게 해준다. 임베디드와 PLC는 그 시스템을 실제 장비와 연결한다. Python과 소프트웨어 개발은 데이터를 다루고 도구를 만든다. 그리고 LLM은 이 모든 것을 사람이 이해하고 조작할 수 있는 인터페이스로 바꿀 가능성을 준다.

그래서 나에게 산업 AI는 단순히 “AI를 공장에 붙인다”는 말로는 부족하다. 더 정확히는 이런 질문에 가깝다.

제어 시스템을 아는 사람이 LLM을 도구로 쓰면, 현장의 어떤 판단과 반복 작업을 더 안전하게 줄일 수 있을까?

이 질문에 대한 첫 번째 실험이 DGX와 Local LLM을 통한 Edge Control 구조였다.

결론

AI가 공정을 직접 제어하는 미래는 올 수 있다. 하지만 그 미래가 안전하려면, AI가 모든 것을 직접 제어하는 방향이 아니라 안전 경계 안에서 제한적으로 개입하는 방향이어야 한다.

내가 지금 믿고 있는 구조는 명확하다.

• PLC와 RTOS는 deterministic control layer를 책임진다.
• LLM Agent는 non-deterministic reasoning layer를 맡는다.
• Guard Layer는 두 세계 사이의 안전한 경계를 만든다.
• Feedback은 Agent의 판단을 계속 검증한다.
• Operator는 최종 맥락과 책임을 가진다.

결국 핵심은 AI를 controller로 만드는 것이 아니다. AI를 bounded supervisory layer로 설계하는 것이다.

이 방향으로 계속 실험해볼 생각이다. 다음 글에서는 이 구조를 실제로 구현할 때 어떤 tool을 정의했고, Guard Layer를 어떻게 설계했으며, B&R/PLC 환경과 연결할 때 어떤 문제가 있었는지 더 구체적으로 정리해보려고 한다.