유량계 데이터, MQTT와 API 중 무엇으로 보내야 할까요?

유량계 값은 정상적으로 읽히는데, 그다음 단계에서 고민이 생겨요. 이 데이터를 MQTT로 보내야 할지, HTTP API로 전달해야 할지 바로 결정하기가 어렵거든요. 둘 다 서버로 값을 보낼 수 있지만 잘 맞는 상황은 서로 달라요.

먼저 정답부터 말씀드리면, 여러 화면과 서비스가 같은 유량 값을 실시간으로 받아야 할 때는 MQTT가 편해요. 특정 MES나 업무 서버에 값을 전달하고 성공 여부를 바로 확인해야 할 때는 HTTP API가 이해하기 쉬워요. 중요한 건 유행하는 방식을 고르는 게 아니라 우리 현장의 수신 구조와 장애 처리 방법을 먼저 보는 거예요.

프로토콜보다 값을 먼저 정리해요

유량계는 순간 유량과 누적 유량을 함께 제공하는 경우가 많아요. 순간 유량은 현재 공정 상태를 보는 값이고, 누적 유량은 일정 기간 사용량을 확인하는 값이에요. 두 값을 이름 없이 숫자로만 보내면 수신 서버에서 의미를 다시 추측해야 해요.

Modbus TCP 유량계라면 레지스터 주소, 데이터 타입, 워드 순서, 배율, 단위를 장비 매뉴얼과 실제 표시값으로 비교해 보세요. 같은 주소를 읽어도 이 설정이 다르면 값이 크게 어긋날 수 있어요. 수집 시각과 통신 상태도 함께 정하면 연결이 끊겼다가 복구된 값과 현재 값을 구분하기 쉬워요.

유량계 값을 EASY-LINK에서 한 번 정리한 뒤 필요한 전달 경로로 나누는 모습이에요.

여러 곳에서 받는다면 MQTT가 편해요

MQTT는 발행자와 구독자를 Broker가 이어주는 방식이에요. EASY-LINK가 유량 데이터를 Broker에 발행하면 대시보드, 저장 서비스, 알림 서비스가 각자 필요한 Topic을 구독할 수 있어요. 수신자가 늘어날 때마다 현장 장비의 목적지 설정을 모두 바꾸지 않아도 된다는 점이 편리해요.

대신 Topic 이름과 메시지 구조를 미리 정해야 해요. 사업장, 라인, 장비, 측정 항목을 어디까지 Topic에 넣을지 정하고, 값과 단위, 수집 시각, 상태는 payload에서 일관되게 보내는 편이 좋아요. 마지막 값만 보고 현재 값이라고 오해하지 않도록 수집 시각도 꼭 함께 표시해요.

MQTT는 여러 곳에 실시간으로 나누어 보낼 때 강점이 있어요. 하지만 Broker에 전달됐다는 사실이 MES의 업무 처리까지 끝났다는 뜻은 아니에요. 수신 서비스가 실제로 저장했는지 별도 확인이 필요한 작업이라면 이 차이를 설계에 넣어야 해요.

한 시스템과 주고받는다면 API가 단순해요

HTTP API는 요청을 보내고 응답을 받는 흐름이 눈에 잘 보여요. 생산 실적 서버나 자체 업무 시스템처럼 정해진 대상에 유량 값을 전달하고, 성공과 실패를 바로 구분해야 할 때 잘 맞아요. 기존 웹 서버의 인증과 로그 체계를 활용하기도 편해요.

여기서는 재시도 기준이 중요해요. 응답이 늦었다고 해서 서버가 값을 받지 못한 것은 아닐 수 있어요. 같은 데이터를 다시 보낼 때 중복 저장되지 않도록 장비 ID, 수집 시각, 순번처럼 한 건을 구분할 키를 수신 측과 정해두는 편이 좋아요.

또 HTTP 200만 확인하고 끝내지 않아요. 인증 오류인지, 입력 형식 오류인지, 서버가 잠시 바쁜지 구분해야 다시 보낼 요청과 바로 수정할 요청을 나눌 수 있어요. EASY LOGGER의 API 설정에서는 Endpoint Preview와 Payload Log를 이용해 주소와 최근 송수신 내용을 확인할 수 있어요.

MQTT와 API를 나란히 비교해요

확인할 질문	MQTT가 잘 맞는 경우	HTTP API가 잘 맞는 경우
누가 값을 받나요?	여러 구독 서비스	정해진 업무 서버
흐름은 어떤가요?	발행·구독	요청·응답
수신자가 늘어나나요?	Broker에 구독자 추가	대상별 API 계약 확인
성공을 어떻게 보나요?	전달과 업무 처리를 나눠 확인	응답 코드와 본문 확인
재전송에서 중요한 것은?	QoS와 중복 처리	멱등 키와 오류 분류

하나만 고집할 필요는 없어요. 실시간 대시보드에는 MQTT로 보내고, 확정된 집계 결과는 HTTP API로 전달할 수 있어요. 다만 두 경로에서 원시 값을 각각 다르게 가공하면 안 돼요. 단위와 시각, 품질 기준은 EASY-LINK 또는 상위 수집 계층에서 한 번 정리하는 편이 좋아요.

MQTT는 여러 수신자에게 나누기 좋고, API는 정해진 시스템과 요청·응답을 확인하기 좋아요.

왜 EASY-LINK가 필요한가요?

EASY-LINK는 현장의 Modbus RTU/TCP 유량계와 PLC 값을 읽어 MQTT, HTTP API, MySQL 같은 대상으로 전달하는 산업용 게이트웨이예요. 유량계마다 별도 프로그램을 만들어 서버에 붙이는 대신, 웹 설정 화면에서 수집 장비와 주소, 전달 대상을 순서대로 정리할 수 있어요.

특히 기존 유량계가 Modbus TCP를 제공한다면 장비를 교체하지 않고 수집 경로를 추가하는 구성을 검토할 수 있어요. 여기서 EASY-LINK가 대신해 주지 않는 부분도 있어요. 유량계의 정확한 레지스터 정의와 단위는 장비 매뉴얼로 확인해야 하고, API 서버의 중복 처리나 MQTT 구독 서비스의 저장 로직도 각 시스템에서 준비해야 해요.

유량계 한두 대의 값을 MQTT나 API로 바로 보내는 목적이라면 EASY-LINK만으로 충분할 수 있어요. 현장 가까이에서 수집과 변환, 전달을 단순하게 시작하고 싶은 경우에 잘 맞아요.

EASY LOGGER까지 함께 쓰면 좋은 때

라인과 장비가 늘어나면 단순 전달만으로는 부족해질 수 있어요. 여러 EASY 장치와 PLC 데이터를 한곳에 모으고, DB 저장과 대시보드, VPN 원격 관리, MQTT와 API 설정을 함께 관리해야 한다면 EASY LOGGER가 상위 관리 지점 역할을 해요.

EASY LOGGER를 무조건 함께 써야 하는 것은 아니에요. 한 라인의 유량 데이터를 한 서버로 보내는 구성이라면 EASY-LINK부터 시작해도 돼요. 여러 라인의 데이터를 모아 이력을 남기고, 운영 화면과 외부 연동을 같은 기준으로 관리할 필요가 생길 때 EASY LOGGER를 추가하는 편이 자연스러워요.

공식 설정 글을 보면 EASY LOGGER의 MQTT는 Broker 기반 발행·구독과 Topic Preview를 제공하고, API는 외부 서버 POST와 Endpoint Preview, Payload Log를 제공해요. 즉, 전달 방식 선택뿐 아니라 연결 상태와 최근 송수신 내용을 한곳에서 확인해야 할 때 도움이 돼요.

우리 현장은 이렇게 골라보세요

• 여러 서비스가 실시간으로 같은 값을 받아야 하나요? 그렇다면 MQTT를 먼저 살펴봐요.
• 정해진 업무 서버의 성공 응답이 중요한가요? 그렇다면 HTTP API가 편해요.
• 순간 유량과 누적 유량의 이름, 단위, 시각이 정해졌나요?
• 통신 복구 뒤 같은 값이 다시 들어올 때 중복 처리 기준이 있나요?
• 유량계 한두 대만 연결하나요, 여러 라인을 통합 관리해야 하나요?
• 저장, 대시보드, 원격 관리까지 한곳에서 봐야 하나요?

처음에는 한 가지 전달 경로로 작은 범위를 확인해 보세요. 값의 의미와 장애 처리 기준이 맞는지 확인한 뒤 MQTT 구독자나 API 대상을 늘리는 편이 안정적이에요.

세부 설정은 EASY LOGGER MQTT 설정 방법과 EASY LOGGER API 설정 방법에서 이어서 볼 수 있어요. 다른 기술 글은 블로그 목록에서 확인할 수 있고, 유량계 프로토콜과 전달 대상을 함께 검토하려면 HT Automation 홈페이지에서 현재 구성을 알려주세요.