스마트팩토리의 핵심, 미들웨어란 무엇일까?

스마트팩토리 IT 시스템의 근간은 미들웨어(Middleware)에 있다 해도 과언이 아니다. 여기서 말하는 미들웨어란 데이터 인터페이스 미들웨어로, 제조를 중앙에서 관제하는 MES(Manufacturing Execution System, 생산관리시스템)와 생산 설비 인터페이스를 통합 관리하는 시스템을 일컫는다.

사실 스마트팩토리 업계에 종사하는 개발자라도 미들웨어를 접할 기회는 많지 않다. 이번 글에서는 이처럼 접하기 어려운 스마트팩토리 분야의 미들웨어 시스템을 다룰 예정이다. 후반부에서는 이해를 돕기 위해 미들웨어 개발에 가장 많이 쓰이는 언어인 자바스크립트로 만든 예제를 함께 살펴보겠다.

인터페이스를 통합 관리하지 않으면 어떤 일이 벌어질까?

스마트팩토리 미들웨어는 인터페이스의 통합 관리를 목적으로 한다. 그렇다면 인터페이스를 통합 관리해야 하는 이유는 무엇일까? 이 질문에 답하려면, 이를 통합해 관리하지 않을 때 어떤 문제가 발생하는지 알아보는 편이 빠르다.

통합 관리를 하지 않을 경우, 네트워크가 어떻게 구성될지 먼저 생각해보자. 보통 각 통신 접점이 서로 분산된 형태가 나올 것이다. 이를 포인트 투 포인트(Point to Point) 방식이라고 한다.

포인트 투 포인트 방식의 문제는 장애가 발생할 때 원인을 파악하는 과정에서 자주 헛발질을 한다는 점이다. 예를 들어 위 이미지의 설비 1에서 통신 장애가 일어났으며, 그 원인은 MES가 정상 동작하지 않아서라고 하자. 곳곳에서 장애 버저가 울리면 현장 오퍼레이터(OP)가 달려온다. 그는 가장 먼저 설비 1을 확인할 것이다. 그다음 설비 1과 연결된 서비스 1이 돌아가는 PC, 이어 설비/서비스 2, 3과 MES를 순차적으로 돌아다니며 확인한다. 이대로라면 결국 마지막에 MES를 확인하고 장애를 해결할 것이다.

여기서 문제는 무엇일까? 접점이 복잡하기 때문에 작업의 오버헤드가 자주 일어난다는 것이다. MES와 설비 1의 연결이 문제인데, 담당자는 서비스 1, 2, 3을 모두 확인해야 했다. 때로는 실제 현장을 방문해 서비스 1이 돌아가는 PC, 심지어 서비스 2, 3이 돌아가는 PC까지 찾아다녀야 할 수도 있다. 즉, 이런 이유로 포인트 투 포인트 방식은 유지보수와 관리의 효율성이 떨어진다.

또한 확장성도 용이하지 않다. 설비 1을 완전히 다른 기업의 제품으로 바꿔야 한다면, 곧바로 문제가 발생할 것이다. 설비 1과 접점이 있는 서비스 1, 2, 3에다 MES까지 모두 수정해야 하기 때문이다. 새로운 설비를 추가하려면 어떨까? 설비 4를 추가하면 모든 접점의 추가 작업이 필요하다. 결국 어마어마한 추가 비용이 들어간다는 뜻이다.

그래서 이러한 인터페이스 시스템은 이미지처럼 통합 관리를 할 수 있는 아키텍처로 구축한다. 그러면 장애 원인의 파악과 해결이 빠르게 이루어지며, 불필요한 추가 작업이 일어날 가능성도 낮아진다. 확장성과 유연성도 갖추었으므로 추가 개발 비용 역시 낮아진다. 스마트팩토리 개발 업계가 미들웨어 아키텍처를 적극적으로 구상하게 된 가장 큰 이유다.

EAI와 미들웨어 비교하기

매우 일반적인 차원에서 데이터 인터페이스의 유형은 크게 이기간과 이기종으로 구분할 수 있다. 그렇다면 스마트팩토리 미들웨어는 어떤 인터페이스 유형을 따를까? 주로 이기종 인터페이스다.

이기종이란 OS나 하드웨어가 서로 다른 설비들이 실시간으로 통신하는 경우를 말한다. 그 때문에 이기종 인터페이스 논의에서는 통신 프로토콜의 국제 표준 설정이 가장 중요한 현안이 된다.

예컨대 애플은 USB 표준을 지키지 않고 독자 규격을 고집했다. 최근 EU는 이러한 애플의 생산에 제재를 가했는데, 여기에는 경제적 비효율과 독과점 문제 등이 얽혀 있다. 애플의 독자 규격 정책으로 USB 제조사들은 표준 USB-C 타입을 생산하는 공정과 애플 USB 생산 공정을 나눠 관리해야 했으며, 이는 곧 높은 생산비용으로 이어졌다. 이렇듯 독자 규격은 규모의 경제와 어긋나고 각 하청업체와 중소형 제조사의 공정 비용을 불필요하게 증가시킨다. 그래서 생산 설비 역시 표준 통신 규격을 지원하는 방향으로 개발된다.

반면 이기간이란 서로 다른 소프트웨어 시스템끼리 통신하는 것으로, 예를 들어 MES와 SCM(Supply Chain Management, 공급망관리), ERP(Enterprise Resource Planning, 전사적 자원관리)가 서로의 실적 데이터를 연동하는 경우를 생각해 볼 수 있다. 이런 경우, EAI(Enterprise Application Integration, 기업응용프로그램통합) 솔루션이 인터페이스를 용이하게 처리해 주는 대표적인 해결책이다.

이기간 인터페이스를 중심으로 하는 EAI의 경우, 일반적으로 국제 표준보다 해당 솔루션 개발사의 독자적인 규격으로 통신을 주고받는다. 이와 달리 이기종 인터페이스를 중심으로 하는 미들웨어의 경우, 다양한 통신 프로토콜을 지원하도록 구축된다. 이를 디자인 패턴에 비유하자면 EAI는 중재자(Mediator), 미들웨어는 아답터(Adapter)라 할 수 있다.

스마트팩토리 분야에서 미들웨어가 중요해진 이유가 여기에도 있다. 설비 업체 입장으로 접근하면 이해가 쉬워진다.

예컨대 당신이 IoT 장비 업체 제품 연구소에 소속된 응용프로그래머라고 해보자. 당신은 EAI로 전송할 HTTP 데이터를 기판에 프로그래밍할 수 있을지 스스로 질문해야 한다. 이는 곧 IoT 장비 메모리에 HTTP 통신을 위한 제반 데이터를 담을 공간이 충분한지, TCP 전송 계층으로 보낼 물리적 환경(전압, 모듈 등)은 만족하는지 묻는 것과 같다. IoT 장비의 메모리는 생각보다 정말 작다고 하니, 이를 모두 확보하기 쉽지 않을 것이다.

그러니 답은 명확하다. 다양한 통신 프로토콜을 지원하는 미들웨어 시스템이 공장에 준비되어 있다면, 설비 업체가 큰 비용을 치르지 않아도 된다. 공장 입장에서도 적은 비용으로 인터페이스를 쓸 수 있다.

간단한 미들웨어를 만들어보자

지금까지 스마트팩토리에서 미들웨어가 왜 중요한지 이유를 알아봤다. 이제 간단한 미들웨어 예제로 그 작동 방식에 대해 살펴보려 한다. 다만 실제로 동작하는 미들웨어를 만들기보다 개념을 이해하고 구조를 익히는 데 중점을 둘 예정이다. 예제는 접근성을 위해 가장 많이 활용되는 자바스크립트(node.js)를 이용했다.

우선 미들웨어가 동작하기 위한 핵심 모듈을 다음과 같이 나누었다.

[미들웨어 핵심 모듈]

1) 통신 드라이버 

2) 태그 

3) 컨트롤러 

4) 웹 API

디렉터리 구조는 다음과 같다.

middleware-code-app/ # 작업 영역 root
│ app.js             # 애플리케이션 메인 실행 코드
├─── lib\            # 라이브러리 폴더 영역
  ├─── driver\       # 통신 드라이버 폴더 영역 (설비 통신 프로토콜)
  ├─── tag\          # 태그 폴더 영역 (바이너리 데이터가 정보화되는 영역)
  ├─── controller\   # 컨트롤러 폴더 영역 (설비 → 미들웨어 처리)
├─── service\
  │ WebApi.js        # 웹 API 코드 (미들웨어 → 사용자 처리)

여기서 주도적인 실행의 단위는 2개로, 컨트롤러와 웹 API이다. 컨트롤러는 통신 드라이버를 이용하여 설비에서 데이터를 개더링한 다음 태그에 저장한다. 웹 API는 요청이 오면 모든 태그를 뒤져 개더링 된 정보를 전송한다. 아래는 이번에 만들 미들웨어의 전체 워크플로다.

외부 시스템에서 미들웨어가 관리하는 설비의 데이터를 요청하면 (캐싱되었긴 하지만) 준-실시간 데이터를 응답하는 것이 시스템의 핵심 기능이다. 이런 구조는 수집기와 전송기가 태그 공간을 사이에 두고 격리된 채 실행된다는 장점이 있다. 이로써 수집기와 전송기는 각각 성능에 따라 서로가 부정적인 영향을 주지 않는다.

1) 통신 드라이버

드라이버란 하드웨어와 애플리케이션을 이어주는 매개체를 의미한다. 우선 인터페이스를 위해 IDriver 클래스를 만들고 메소드를 접속(Open), 접속 끊기(Close), 수신(Receive), 발신(Send)으로 나누었다. 모든 수신과 발신을 상속할 클래스들이 비동기로 구현되도록 async로 정의해 두자.

이를 상속한 TCP/IP 드라이버의 예시를 보면, 그 의도를 더 자세히 이해할 수 있을 것이다.

이제 driver 폴더 하위에 RS232c, NFC/RFID, 또는 독자 규격인 SAP RFC 등 그 하위 클래스를 추가할 수 있다. 바로 이것이 미들웨어의 핵심이다. 웬만한 통신 프로토콜을 모두 준비해 어떤 설비든 통신을 지원하는 것이다.

2) 태그

태그는 내가 인터페이스하려는 데이터를 태깅하는 작업이다. 예를 들어, RFID 리더기가 읽은 데이터가 팔레트의 ID 값이라고 하자. 우리가 수신한 데이터 자체에는 팔레트 ID라는 정보가 전혀 없다. 따라서 여기에서 의미를 주는 요소를 따로 태깅하는 것이다.

Tag 클래스는 곧 자신을 먼저 정의(태깅)하고, 그다음 들어오는 데이터를 별도 공간에 저장하는 방식이다.

3) 컨트롤러

컨트롤러는 통신 드라이버와 태그 모두를 멤버로 갖고 이들을 제어하는 역할이다.

위의 코드를 보자. 각 프로토콜마다 필요한 데이터가 달라지고 계층화된 부분도 있어 복잡하다. 그래서 컨트롤러의 메소드를 단순화하고 그 내부에서는 분기에 따라 처리되도록 퍼사드 패턴을 적용했다. ReadStart() 메소드에서는 데이터를 수신하면 이를 저장하고 true로 응답하도록 했다.

4) 웹 API

웹 API는 싱글턴 패턴으로 구현해 하나의 서버에서만 처리되도록 한다. Init() 메소드로 태그 집합을 받고, “/middleware”에 POST 요청이 오면 그때 태그 정보를 수집하여 응답하도록 설정했다.

5) 미들웨어 실행

이제 이들을 실행해 주는 코드 app.js를 보자. 이 코드에는 IoT 장비를 연결하기 위한 정보가 포함된다. 그 하위에는 각 데이터를 태깅하며 정의한 데이터가 들어 있다.

이렇게 수집된 데이터는 태그 집합에 모인다. 만약 웹 API로 요청이 들어오면, 미들웨어는 현재의 태그 정보를 모두 모아 응답한다. 아래는 포스트맨으로 전송하여 응답받은 결과이다.

이러한 미들웨어가 없었다면, 설비가 지원하는 통신 프로토콜 확인 → 데이터 협의 → S/W개발 → 통신이라는 고난한 과정이 필요했을 것이다. 그러나 미들웨어가 있을 때는 웹 API와 태그명, 데이터에 대한 협의만 이뤄지면 끝이다. 설비를 확장할 때에도 클라이언트 입장에서는 추가할 태그명만 알면 된다. 이렇듯 미들웨어는 생산 현장의 변화에 대한 유연한 대응과 경제적인 효율을 제공한다.

마치며

위에서 살펴본 예제 코드는 제한적인 기능과 추상적인 실행만을 보여주고 있다. 따라서 실제 사용은 어려울 것이다. 예컨대 디지털 트윈(Digital-Twin)을 지원하는 미들웨어라면, 실시간으로 데이터를 브로드 캐스팅할 수 있는 구조(Pub/Sub)가 되어야 한다. (이때는 MQTT 등 메시지 프로토콜이나 Redis 등 인메모리 DBMS를 고려할 수 있다.) 이 미들웨어는 교육을 목적으로, 요청-응답 기능만 다룬 점을 주의해야 한다. 자세한 구현 역시 주석의 //TO DO로 독자에 바톤을 넘기기도 했다.

그러나 적어도 미들웨어의 구조와 실행 단위를 이해하기에는 충분하다고 생각했다. 모자란 부분을 직접 구현해 가다 보면 더 많이 공부하고 연구할 수 있을 것이다. 참고로 글에 나온 소스 중 일부는 분량을 고려해 간략하게 만들었다. 전체 소스 코드를 보고 싶다면 깃허브를 참고할 수 있다.

주니어 개발자의 경우 예제 코드로 미들웨어의 핵심 구조를 익혀보길 추천한다. 무엇보다 미들웨어가 얼마나 높은 비즈니스 가치를 지녔는지, 스마트팩토리 업계 사람들에 충분히 전달되었기를 바란다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.