PLC나 센서 데이터를 수집하다 보면, 결국 프로젝트 중반쯤 이런 고민에 부딪힙니다.
"이 많은 데이터를 어디에 저장해야 안 터지고, 빠르고, 나중에 써먹기 편할까?"
현장의 데이터는 보통 시계열(Time-series)입니다. 온도, 전류, 진동, 생산 카운트 같은 값이 초 단위, 혹은 그 이하로 쏟아지죠. 오늘은 현업에서 가장 많이 언급되는 3대장, InfluxDB / TimescaleDB / MongoDB를 "실무 의사결정 기준"으로 비교해 봅니다.
단순 스펙 비교가 아니라, '현장에서 굴려보니 이렇더라'는 관점입니다.
1. 산업 데이터, RDB처럼 다루면 망합니다
일반적인 웹 서비스 데이터와 다르게, 공장 데이터는 아주 명확한 특징이 있습니다.
- 쓰기(Write) 폭탄: 수천 개의 태그가 1초마다 들어옵니다. 수정(Update)은 거의 없고 오직 추가(Insert)뿐입니다.
- 조회(Read)는 '최근' 위주: "지금 온도 몇 도야?", "지난 1시간 트렌드 보여줘."
- 집계가 생명: 1초 데이터를 1년치 다 보여달라는 사람은 없습니다. 1분 평균, 1시간 최대값 등으로 '다운샘플링'이 필수입니다.
- 자동 삭제(Retention): 원본은 7일 뒤 삭제, 통계는 1년 보관 같은 정책이 없으면 디스크가 금방 뻗습니다.
즉, "저장은 무식하게 하되, 조회와 관리는 스마트하게" 되어야 합니다.
2. 바쁘신 분들을 위한 3줄 요약 (결론부터)
- TimescaleDB: "나는 SQL이 편하고, 설비/작업지시 데이터랑 조인(Join)도 해야 한다." (가장 무난한 추천)
- InfluxDB: "순수하게 모니터링/대시보드/알람이 목적이고, 압축률과 전용 쿼리가 중요하다."
- MongoDB: "데이터 형식이 제각각이고, 로그/이벤트/JSON을 통째로 넣고 싶다."
3. 한눈에 보는 비교
시계열 데이터베이스(TSDB) 비교 분석
| 항목 | InfluxDB | TimescaleDB (PostgreSQL) | MongoDB |
|---|---|---|---|
| 정체성 | 시계열 전용 DB | RDB (PostgreSQL) + 시계열 플러그인 | 문서형 NoSQL |
| 강점 | 압축률 최강, 보관 정책(RP) 설정 간편 | SQL 사용, 조인 가능, 안정성(ACID) | 스키마 유연성, 개발 속도 빠름 |
| 약점 | 독자 쿼리(Flux/InfluxQL) 학습 필요, 조인 어려움 | RDB 기반이라 무거운 편 | 시계열 전용 기능(압축/집계)은 설계 역량에 달림 |
| 추천 | 대시보드(Grafana), 서버/센서 모니터링 | MES/ERP 연동, 정형 데이터 분석 | 비정형 로그, 빠른 프로토타이핑 |
4. 실무 선택 체크리스트 (7가지 질문)
아래 질문 중 "YES"가 많은 쪽을 선택하세요.
A. 데이터 모델 / 비즈니스
- 설비 마스터, 작업지시(LOT), 제품 정보와 엮어서 조회해야 하나요? 👉 TimescaleDB
- 태그(센서 종류)가 수만 개 이상이고 계속 늘어나나요? 👉 Influx/Timescale (카디널리티 설계 필수)
B. 운영 / 성능
- 초당 쓰기량이 엄청나고, 디스크 비용(압축)을 아껴야 하나요? 👉 InfluxDB
- 운영팀이 SQL과 PostgreSQL 튜닝에 익숙한가요? 👉 TimescaleDB
- 엔터프라이즈급 권한 관리나 백업/복구 체계가 필요한가요? 👉 TimescaleDB
C. 활용 방식
- Grafana 붙여서 차트 띄우는 게 1순위인가요? 👉 InfluxDB (가장 빠름)
- 측정값 외에 에러 로그나 복잡한 JSON 정보도 같이 넣나요? 👉 MongoDB
5. 같은 데이터를 저장할 때 차이점
2026-02-10 10:00:00에 1번 라인 프레스기의 전류값을 저장한다고 가정해봅시다.
5-1) InfluxDB (Tags & Fields)
measurement: sensor_data
tags: line=A, equipment=Press-01, tag=current
fields: value=12.3
- 특징: 태그(Tags)로 인덱싱이 자동 처리됩니다. 검색이 매우 빠르지만, 태그 값을 너무 다양하게(예: 시리얼 넘버) 넣으면 성능이 급격히 떨어집니다.
5-2) TimescaleDB (SQL)
CREATE TABLE sensor_readings (
time TIMESTAMPTZ NOT NULL,
line TEXT,
equipment TEXT,
value DOUBLE PRECISION
);
-- Hypertable로 변환
SELECT create_hypertable('sensor_readings', 'time');
- 특징: 그냥 SQL 테이블입니다. 그래서 JOIN equipment_master ON ... 같은 쿼리가 가능합니다. 이게 현업 개발자에겐 엄청난 무기입니다.
5-3) MongoDB (Document)
{
"ts": "2026-02-10T10:00:00Z",
"meta": { "line": "A", "eq": "Press-01" },
"value": 12.3,
"status": { "code": "OK", "msg": "Normal" }
}
- 특징: status 필드처럼 구조가 바뀌거나 복잡한 정보도 욱여넣을 수 있습니다. 유연하지만, 나중에 통계 낼 때 머리가 좀 아플 수 있습니다.
6. 시나리오별 추천 조합
Scenario 1: "일단 실시간 모니터링부터 합시다" (DX 초기)
- 추천: InfluxDB (또는 Timescale) + Grafana
- 복잡한 로직 없이 데이터를 붓고, 바로 차트로 띄우기에 가장 가성비가 좋습니다.
Scenario 2: "MES랑 연동해서 불량 원인 분석해야 합니다" (고도화)
- 추천: TimescaleDB
- "A제품 생산할 때 설비 온도가 어땠어?"라는 질문에 답하려면, 생산실적 테이블과 센서 테이블을 조인해야 합니다. RDB 기반인 TimescaleDB가 압도적으로 유리합니다.
Scenario 3: "개발자 구하기 힘들고 빨리 만들어야 해요"
- 추천: MongoDB
- 스키마 설계 고민 없이 일단 개발을 시작할 수 있습니다. 단, 데이터가 쌓일수록 느려지는 건 감수하고 나중에 튜닝해야 합니다.
7. 경험상 여기서 다 터집니다 (주의점)
- 시간 동기화 (NTP): PLC 시간과 서버 시간이 안 맞으면 데이터가 미래에서 오거나 과거로 사라집니다.
- 무한 저장: "일단 다 저장해"라고 하고 보관 정책(Retention Policy) 안 세우면, 6개월 뒤 디스크 풀 차서 새벽에 전화 옵니다.
- 다운샘플링 부재: 1년치 데이터를 1초 단위로 조회하면? 브라우저가 뻗거나 DB가 뻗습니다.
- 망 분리: DB를 폐쇄망(OT)에 둘지, DMZ에 둘지 보안 정책을 먼저 확인하세요. 기술보다 보안 심사가 더 오래 걸립니다.
8. 마치며
정답은 없습니다. 하지만 "실패하지 않는 선택"은 있습니다.
- 나중에 업무 데이터와 엮일 것 같다? 👉 TimescaleDB로 시작하세요.
- 순수하게 설비 상태만 본다? 👉 InfluxDB가 빠릅니다.
- 우리는 이미 Mongo를 잘 쓴다? 👉 MongoDB 쓰셔도 됩니다. (단, 시계열 컬렉션 기능을 꼭 공부하세요.)
궁금한 점이나 현장 상황은 댓글로 남겨주시면 답변드리겠습니다.
