데이터 수집이 끝이 아닌 이유
현장 장비를 서버에 연결하는 것만으로는 운영 시스템이 완성되지 않습니다. 장비마다 다른 데이터 형식을 정리하고, 순간적인 통신 장애를 견디며, 필요한 시점에 조회·분석·알림으로 연결할 수 있어야 비로소 데이터가 운영 자산이 됩니다.
에이드소프트는 장비 연결부터 저장, 실시간 처리, 관제 화면과 알림까지 전체 흐름을 하나의 데이터 파이프라인으로 설계합니다.
현장에서 운영 화면까지의 기본 흐름
- 장비·센서: 산업 프로토콜과 MQTT로 원시 데이터를 수집합니다.
- 메시징 계층: EMQX, NATS, Kafka, RabbitMQ 중 처리량과 보존 요구에 맞는 구조를 선택합니다.
- 저장 계층: 시계열 조회는 TimescaleDB, 대규모 집계와 분석은 ClickHouse를 중심으로 설계합니다.
- 서비스 계층: WebSocket, API, 대시보드와 알림으로 필요한 사용자에게 전달합니다.
- 운영 계층: Docker 기반 배포와 모니터링, 백업·복구 정책을 함께 구성합니다.
메시지 기술은 목적에 따라 달라집니다
MQTT·EMQX는 장비와 센서가 가볍게 데이터를 전달해야 하는 환경에 적합합니다. 연결 상태가 불안정한 현장이나 다수 장비를 수용하는 구조에서 강점이 있습니다. NATS·JetStream은 서비스 간 통신을 단순하게 유지하면서 메시지 저장과 재처리가 필요한 경우에 활용합니다. Edge와 Cloud를 같은 메시징 체계로 연결해야 할 때도 유용합니다. Kafka는 많은 이벤트를 장기간 보존하고 여러 소비자가 각자의 속도로 재처리해야 하는 대규모 스트리밍에 적합합니다. RabbitMQ는 업무 명령, 비동기 작업, 재시도처럼 명확한 큐 처리에 강점이 있습니다.TimescaleDB와 ClickHouse를 선택하는 기준
TimescaleDB는 PostgreSQL 생태계를 유지하면서 시간 기준 파티셔닝과 집계를 적용하기 좋습니다. 장비 이력과 업무 데이터를 함께 조회해야 하는 시스템에 적합합니다.
ClickHouse는 대량 이벤트를 빠르게 집계하고 사용자용 실시간 분석 화면을 제공해야 할 때 강점을 보입니다. 모든 프로젝트에 한 기술을 고정하기보다 데이터 양, 조회 패턴, 보존 기간과 운영 인력을 함께 보고 선택해야 합니다.
에이드소프트의 구축 원칙
- 원시 데이터와 서비스 데이터를 분리해 변경에 대응합니다.
- 메시지 유실과 중복을 전제로 재처리 가능한 구조를 설계합니다.
- Edge 서버는 필수가 아니라 통신 환경과 현장 판단 필요성에 따라 선택합니다.
- AWS·Azure 또는 고객 인프라를 활용한 하이브리드 구성을 지원합니다.
- 대시보드뿐 아니라 장애 대응, 백업, 권한과 운영 절차까지 함께 설계합니다.
먼저 확인해야 할 질문
장비 수보다 중요한 것은 초당 데이터 발생량, 허용 가능한 지연 시간, 장애 시 보존 범위, 실시간 분석 항목입니다. 이 네 가지가 정리되면 필요한 메시징과 저장 기술도 명확해집니다.
에이드소프트는 특정 제품을 먼저 제안하지 않습니다. 현장과 운영 목표를 확인한 뒤 가장 단순하면서 확장 가능한 구조를 선택합니다.