세 가지 꿈으로 만들어가는 새로운 공장

산업 기계를 가동해 본 사람은 누구나 한 번 이상 생각해 봤을 세 가지 질문이 있습니다. 너무 이상적이어서 소리 내어 말하지 않는 세 가지 질문입니다. 이 글에서는 그 질문들을 정리해 봅니다.

장면을 시작하며

야간 근무, X 구역. 라인이 멈춥니다. HMI 패널에 코드가 표시됩니다: E-1423. 설명서는 세 건물이나 떨어진 곳에 있습니다. 그 기계를 아는 기술자는 휴가 중입니다. 작업자는 두 가지 선택지가 있습니다. 다음날 아침에 응답할 수도 있는 고객 지원에 전화하거나, 추측해서 해결하려고 시도하는 것입니다. 전 세계 산업화된 국가에서 이와 같은 장면이 밤마다 수백 번 반복됩니다.

문제는 설명서가 부족한 것이 아닙니다. 설명서는 너무 많습니다. 문제는 기계가 자신이 무엇을 필요로 하는지 잘 알고 있다는 것입니다. (압력 센서가 30초 동안 뭔가 잘못되었다고 알려주고 있습니다.) 하지만 작업자가 이해할 수 있는 언어로 말할 수 없고, 문제를 설명할 뿐 해결책을 말하지 못한다는 것입니다. "압력 범위 초과"는 새벽 3시에 도움이 되지 않는 문구입니다. "공기 회로의 밸브 V12를 확인하십시오. 아마도 밸브가 고착되었을 것입니다."는 도움이 됩니다.

이것이 우리가 하고 있는 일의 시작입니다. 새로운 PLC가 아닙니다. 더 멋진 HMI도 아닙니다. 2026년에 기계를 움직이는 소프트웨어가 무엇이어야 하는지에 대한 다른 방식의 사고방식입니다. 그리고 우리가 함께 유지하려고 노력하는 세 가지 고정 관념, 꿈이라고 불러도 좋습니다.

꿈 번호 하나: 프로그래밍 없이 자동화하기

오늘날의 산업 자동화는 매우 특별한 인물을 필요로 합니다. 즉, ladder, function block, structured text와 같은 IEC 61131-3 계열의 언어로 프로그래밍할 수 있는 사람인데, 이 언어는 소프트웨어 세계의 다른 곳에서는 거의 사용되지 않습니다. 이러한 언어를 아는 사람은 드물고 비싸며 거의 항상 3주 정도 뒤쳐집니다.

아이러니한 점은 기계를 정말 잘 아는 사람이 프로그래머가 아니라는 것입니다. 그것은 부서장, 숙련된 유지보수 담당자, 20개의 유사한 시스템을 설치한 통합자입니다. 이 사람들은 기계가 무엇을 해야 하는지 알고 있습니다. 1990년대에 만들어진 프로그래밍 언어를 배워서 설명하고 싶어하지 않습니다.

아이디어는 사슬을 뒤집는 것입니다. 소프트웨어 개발자는 재사용 가능한 구성 요소(모션 제어, 센서 관리, 작동 시퀀스 등)를 현대적이고 범용적인 언어로 한 번만 작성합니다. 기계 통합자는 이를 프로그래밍하지 않고, 기계가 무엇을 해야 하는지 음성 또는 서면으로 지정하여 구성합니다. 대규모 언어 모델(LLM)은 번역기 역할을 합니다. 통합자의 기능 사양을 받아 이미 작성되고 테스트된 구성 요소를 조립하여 실행 가능한 구성으로 변환합니다.

이것은 "AI가 당신을 대신하여 코드를 작성한다"는 환상이 아닙니다. 이것은 더 겸손하고 현실적인 것입니다. AI는 당신의 사양을 읽고 인증된 구성 요소 중에서 어떻게 결합할지 선택합니다. 5밀리초 사이클로 축을 움직이는 중요한 코드는 여전히 인간이 결정론과 신뢰성을 보장하는 언어로 작성합니다. 하지만 그 코드는 한 번 작성되어 백 번 재사용됩니다.

두 번째 꿈: 자기 자신을 아는 기계

오늘날 기계들은 제대로 소통하지 못하고, 제대로 말하지도 못합니다. 경보는 숫자 코드이고, 진단은 일련의 LED입니다. 로그는 제조업체만이 열 수 있는 바이너리 파일입니다. 그 기계가 그 허용 오차로 이천 번의 사이클을 거친 후 어떻게 작동하는지에 대한 지식은 사람의 머릿속에 있거나 어딘가의 PDF에 있습니다.

두 번째 꿈은 기계 스스로 자신을 아는 것입니다. 신비로운 의미가 아니라 매우 구체적인 의미로, 기술 문서, 프로세스 매개변수, 일반적인 오류 사례, 개입 절차는 더 이상 캐비닛이나 별도의 문서 서버에 있지 않고 기계 자체 내에 존재하며 자체 소프트웨어로 읽을 수 있습니다. 그리고 문제가 발생하면 기계는 "오류 1423"이라고 말하지 않습니다. "밸브 V12가 아마도 붙었을 것이므로 확인해야 합니다. 그동안 속도의 60%로 저하된 모드로 계속 진행할 수 있습니다"라고 말합니다.

신고만 하는 수동적인 객체와 함께 문제를 해결하는 능동적인 객체 사이의 차이입니다. 전자는 문제를 작업자에게 남기고, 후자는 함께 해결합니다.

이는 두 가지 다소 예상치 못한 사항을 필요로 합니다. 첫째, 기계에 대한 지식, 즉 역사적으로 매뉴얼, 전기 회로도, CAD 도면 및 기술자들의 경험에 보관되어 있던 지식을 공식화하고 시스템에 통합해야 합니다. 둘째, 시스템이 대화할 수 있는 상호 작용자를 가져야 합니다. 다시 말해, 코드를 생성하는 것이 아니라 증상을 이해할 수 있는 조치로 번역하고, 패널 앞에 있는 사람의 언어로 전달하는 LLM을 사용해야 합니다.

다시 한번 말씀드리지만, 마법은 아닙니다. 더 잘 작성되고, 더 잘 색인화된 문서, 그리고 그 위에 대화형 인터페이스일 뿐입니다. 하지만 야간 근무자에게는 모든 것이 바뀝니다.

세 번째 꿈: 어디든 실행되는 소프트웨어

세 번째 꿈은 가장 기술적이고 역설적으로 가장 정치적인 꿈입니다. 오늘날 산업 자동화는 폐쇄적인 생태계의 세계입니다. 모든 주요 PLC 제조업체는 자체 언어, 개발 환경, 하드웨어, 드라이버 및 유통업체 네트워크를 보유하고 있습니다. 공급업체를 변경하면 모든 것을 다시 작성해야 합니다.

여기서의 목표는 특정 브랜드의 PLC가 협상에서 승리했는지에 관계없이 예산과 필요한 성능에 따라 하드웨어를 선택할 수 있도록 일반 하드웨어(산업용 미니 PC, 임베디드 컨트롤러, 지하실 서버 등)에서 실행되는 소프트웨어 시스템을 구축하는 것입니다. 실시간 Linux 운영 체제, 개방형 표준(EtherCAT 등) 기반 통신 보드, 결정적 부분에 대한 최신 언어 및 비결정적 부분에 대한 보다 민첩한 언어의 소프트웨어 구성 요소입니다.

규칙은 여기서 유토피아가 구체화되는 지점입니다. 하드웨어는 신뢰성에 영향을 미치지 않고 성능에만 영향을 미쳐야 합니다. 동일한 로직은 성능이 낮은 기계에서도 동일하게 작동해야 합니다. 단, 속도는 느려집니다. 사이클 시간이 5ms에서 10ms로 변경되면 축은 동일한 정밀도로 절반의 속도로 이동합니다. 절대로 "거의 동일"이 아니며, "그 경우를 제외하고는 작동합니다"도 아닙니다. 동일한 시스템, 동일한 결정, 동일한 보장입니다.

이 부분에서 숙련된 엔지니어들은 웃음을 터뜨릴 것입니다. 실시간 처리가 어렵고, Linux가 처음부터 실시간 시스템으로 설계되지 않았으며, LLM이 Raspberry Pi에서 실행되지 않고, 동일한 스택에서 서로 다른 언어를 혼합하는 것이 튜토리얼에서 약속하는 것보다 훨씬 더 많은 위험을 수반한다는 것을 잘 알고 있습니다. 그들은 옳습니다. 하지만 방향은 바로 그것이고, 그것을 구축하기 위한 빌딩 블록 — Linux 커널의 실시간 확장, 성숙한 오픈 소스 EtherCAT 스택, 겸손한 하드웨어에서 실행되기 시작하는 LLM — 은 오늘날 처음으로 모두 함께 존재합니다.

왜 "유토피아"인가

유토피아는 솔직한 단어입니다. 이 세 가지 중 어느 것도 오늘날 완성된 제품이 아닙니다. 첫 번째는 생산 환경에서 사용하기에 충분히 신뢰할 수 있는 LLM이 필요하며, 우리는 이제 막 첫걸음을 내딛고 있습니다. 두 번째는 오늘날 거의 전부 비공식적인 산업 지식의 방대한 공식화 작업을 필요로 합니다. 세 번째는 20년의 우위를 점하고 있는 폐쇄형 생태계에 맞서 오픈 소스 대안을 구축해야 합니다.

그러나 이 세 가지 꿈을 함께 연결하면 명확한 방향이 그려집니다. 하드웨어는 범용 상품이고, 소프트웨어는 재사용 가능하며, 지식은 기계에 내장되고, 오늘날 전체 산업의 병목 현상인 PLC 프로그래머의 역할은 사라지는 것이 아니라 진정으로 필요한 곳, 즉 기본 구성 요소를 한 번 작성하는 곳으로 이동합니다.

향후 기사에서 이 퍼즐의 조각들을 구축하고 있는 과정을 설명해 드리겠습니다. 하나씩, 퍼즐이 완성될 것이라는 약속 없이 말이죠. 아직 완성되지 않았지만, 윤곽이 보이기 시작했습니다.