진동 데이터 엣지 전처리, MQTT와 MariaDB를 나누는 기준

진동센서를 달고 나면 곧바로 다음 질문이 생겨요. 파형을 전부 MQTT로 보내야 할까요, 아니면 현장에서 요약한 값만 MariaDB에 남겨도 될까요? 둘 중 하나를 고르는 문제처럼 보이지만, 실제로는 데이터가 생기는 지점과 분석 목적, 장애가 났을 때 다시 확인할 범위를 먼저 나눠야 해요.

2026년 산업통상부는 제조 데이터의 안전한 저장·활용 기반과 함께 실시간 추론 수요에 대응하는 엣지 방식 인프라를 계속 확충하겠다고 밝혔어요. 진동 데이터도 같은 관점으로 볼 수 있어요. 모든 원시값을 멀리 보내는 것보다 설비 가까이에서 무엇을 남기고 무엇을 전달할지 정해야, 나중에 추세와 사건을 함께 설명할 수 있어요.

먼저 데이터 길을 나눠볼게요

진동센서가 곧바로 MQTT나 데이터베이스와 연결되는 것은 아니에요. 센서가 내보내는 신호를 전용 진동 분석기, PLC 또는 상태 감시 장치가 받아 원시 파형이나 계산된 상태값으로 만들어요. 그다음 엣지 전처리 계층에서 연속 파형, 일정 간격의 추세값, 이상 시점 전후의 사건 구간 가운데 무엇을 보낼지 정해요.

여기서 MQTT는 데이터를 전달하는 통로이고, MariaDB는 전달된 이력을 조회할 수 있게 남기는 저장소예요. 브로커가 메시지를 받아 주었다고 장기 이력이 보장되는 것은 아니고, 데이터베이스에 행이 생겼다고 원래 파형을 복원할 수 있는 것도 아니에요. 수집 시각, 설비 운전 상태, 측정 위치와 축, 값의 종류, 전처리 설정 버전을 함께 남겨야 서로 다른 시점의 값을 비교할 수 있어요.

원시 파형 분석, 현장 연결, MQTT 전달, MariaDB 저장을 서로 다른 책임 구간으로 나눈 흐름이에요.

이 구조는 센서 데이터 수집과 설비 데이터 수집을 같은 상자에 억지로 넣지 않아요. 센서나 분석기가 이미 추세값을 제공하는지, PLC가 운전 상태를 함께 갖고 있는지, 원시 파형을 다시 봐야 하는 사건이 무엇인지에 따라 시작점이 달라져요.

세 가지 보관 방식은 쓰임이 달라요

원시 파형을 모두 보관하면 나중에 다른 분석을 시도하기 좋아요. 대신 네트워크와 저장 공간, 시간 정합을 더 세심하게 운영해야 해요. 반대로 추세값만 남기면 운영 화면은 단순해지지만, 갑자기 값이 달라진 이유를 파형으로 다시 확인하기 어려울 수 있어요.

방식	현장에 남길 것	MQTT로 보낼 것	잘 맞는 목적
원시 파형 중심	연속 파형과 수집 조건	파일 위치나 필요한 구간	상세 분석과 원인 검토
사건 구간 + 추세	사건 전후 파형, 평상시 추세	사건 정보와 추세값	운영과 사후 확인의 균형
추세값 중심	계산된 상태값과 설정 버전	주기값과 상태 정보	설비 간 비교와 데이터 추세 분석

조사 깊이와 데이터 부담을 함께 보고 보관 방식을 고르는 비교 기준이에요.

처음부터 한 방식을 모든 설비에 적용할 필요는 없어요. 고장 원인을 자세히 살펴야 하는 핵심 회전체는 사건 구간을 남기고, 상태 변화만 비교할 보조 설비는 추세값부터 시작할 수 있어요. 선택 기준은 저장 비용보다 ‘이 값으로 어떤 판단을 다시 설명해야 하는가’에 두는 편이 좋아요.

MQTT와 MariaDB는 같은 일을 하지 않아요

MQTT는 발행자와 구독자를 느슨하게 연결하는 데 알맞아요. 진동 상태값을 대시보드, 알림 처리기, 데이터 적재 서비스로 나눠 보낼 때 유연해요. 다만 토픽 이름만으로 설비, 측정 위치, 단위, 전처리 버전이 모두 설명되지는 않으니 메시지 구조와 권한을 함께 설계해야 해요.

MariaDB는 시각별 값을 조회하고 설비별 추세를 비교하는 데 쓰기 좋아요. 여기에는 장비 식별자, 원본 시각과 수신 시각, 값의 종류, 단위, 품질 상태, 설정 버전을 나눠 두는 편이 안전해요. MQTT 재전송으로 같은 메시지가 다시 들어올 수 있으므로, 중복을 구분할 키와 적재 실패 기록도 미리 정해 두세요.

산업 데이터 보안도 이 경로 안에서 다뤄야 해요. 브로커 계정은 발행과 구독 범위를 나누고, MariaDB 계정은 조회와 기록 권한을 필요한 만큼만 열어요. 네트워크가 끊겼을 때 현장 버퍼가 무엇을 보존하는지, 복구 뒤 시간 순서가 어떻게 맞춰지는지도 운영 문서에 남겨야 해요.

EASY 제품은 어디에 들어갈까요

센서나 PLC가 Modbus RTU·Modbus TCP 레지스터로 계산된 진동 상태값을 제공한다면 산업용 IoT 게이트웨이를 연결 계층으로 둘 수 있어요. EASY-LINK는 이런 Modbus 장비와 PLC의 값을 읽어 MQTT, HTTP API, DB 쪽으로 이어 주는 게이트웨이 역할을 맡아요. 원시 진동 파형의 고속 샘플링이나 주파수 분석을 대신하는 장비는 아니므로, 그 기능이 필요하면 전용 분석기나 엣지 처리 장치를 앞단에 둬야 해요.

EASY LOGGER는 PLC와 Modbus 데이터를 정해진 조건으로 수집하고 MariaDB에 저장하며, MQTT 같은 외부 전달 상태를 함께 운영하는 로거 역할을 맡아요. 한 장치의 상태값을 상위 시스템에 연결하는 일만 필요하면 EASY-LINK 중심으로 검토할 수 있어요. 여러 설비의 수집 주기, 저장 이력, 전달 상태를 한곳에서 관리해야 한다면 EASY LOGGER까지 검토할 이유가 생겨요.

두 제품을 반드시 함께 써야 하는 것은 아니에요. EASY-LINK와 전용 분석기를 조합해 데이터 연동만 맡길 수도 있고, PLC가 이미 필요한 상태값을 계산한다면 EASY LOGGER로 수집·저장 운영을 묶을 수도 있어요. 자세한 저장 설정은 EASY LOGGER DB 설정 방법, 전달 설정은 EASY LOGGER MQTT 설정 방법에서 이어서 볼 수 있어요.

한 설비부터 단계적으로 확인해요

먼저 회전 설비 한 대와 측정 위치 한 곳을 정해요. 정상 운전, 기동과 정지, 부하가 달라지는 구간을 구분해 원시 시각과 PLC 시각, 브로커 수신 시각, DB 적재 시각이 이어지는지 확인해요. 값이 달라졌을 때 측정 변화인지, 전처리 설정 변화인지, 전송 지연인지 나눌 수 있어야 해요.

다음에는 메시지를 끊었다가 복구해 보세요. 누락 구간이 표시되는지, 같은 데이터가 두 번 저장되는지, 오래된 값이 최신 상태처럼 보이지 않는지 살펴봐요. 이 검증을 통과한 뒤 설비 수와 보관 기간을 늘리면 통신 문제와 데이터 품질 문제를 훨씬 쉽게 분리할 수 있어요.

현재 센서 출력, PLC 통신 방식, 필요한 추세와 사건 구간을 정리하면 구성 범위를 빠르게 좁힐 수 있어요. 현장 연결 가능 여부를 먼저 확인해 보세요. EASY-LINK만으로 충분한지, EASY LOGGER의 저장 운영이 필요한지 부담 없이 연결 구간부터 살펴볼 수 있어요. 다른 설비 데이터 수집 글은 기술 블로그에서도 확인할 수 있어요.

제어 안전은 별도 경계로 남겨요

진동 데이터가 기준을 벗어났다고 MQTT 메시지만으로 설비를 자동 정지시키면 안 돼요. 데이터 수집 경로는 상태를 관찰하고 근거를 남기는 역할이며, 비상정지·보호계전·인터락은 검증된 제어 계층과 현장 절차에 남겨야 해요. 읽기 경로와 쓰기 권한도 기본적으로 분리하는 편이 좋아요.

대시보드에는 마지막 정상 수신 시각과 데이터 품질 상태를 함께 보여주세요. 통신이 끊긴 값을 정상값처럼 계속 표시하지 않아야 운영자가 센서 이상, 네트워크 장애, DB 적재 실패를 구분할 수 있어요. 엣지 컴퓨팅을 도입하는 목적도 모든 판단을 자동화하는 데 있지 않아요. 필요한 데이터를 가까이서 정리하되, 사람이 다시 확인할 근거와 안전한 운영 경계를 남기는 데 있어요.