수집은 했는데 분석에 못 쓰는 공장 데이터
설비 태그 3,000개를 1초 주기로 수집하면 하루에 2억 5,920만 개의 데이터 포인트가 쌓입니다. 포인트당 타임스탬프 8바이트와 값 8바이트만 잡아도 압축 전 하루 약 4GB, 1년이면 약 1.5TB입니다. 그런데 품질팀이 "지난달 불량 로트가 나왔을 때 금형 온도가 어땠는지" 물으면 답을 내는 데 며칠이 걸리는 경우가 많습니다.
원인은 대개 수집량이 아니라 저장 구조에 있습니다.
MES 실적은 "작업지시 1건 완료, 양품 480개"처럼 이벤트 단위의 트랜잭션입니다. 반면 공정 데이터는 시간축에 따라 연속으로 흐르는 값입니다. 두 데이터는 쓰기 패턴과 조회 패턴이 근본적으로 다르기 때문에 저장소도 나눠서 설계해야 합니다.
히스토리안 vs 범용 시계열 DB vs RDB: 무엇에 무엇을 저장할까
| 구분 | 강점 | 적합한 데이터 |
|------|------|---------------|
| 상용 히스토리안 | 산업 프로토콜 연동, 공정 특화 압축, 장기 보존 | 제어 계층의 대량 공정 태그 |
| 오픈소스 시계열 DB | 높은 쓰기 처리량, 유연한 쿼리, 낮은 라이선스 비용 | IoT 센서, 분석용 집계 데이터 |
| RDB | 트랜잭션 무결성, 관계 조인 | 작업지시, 로트, 품질 검사 결과, 태그 메타데이터 |
선택할 때는 다음 네 가지를 기준으로 판단하는 것이 좋습니다.
RDB 하나로 모든 것을 처리하려 하면 결국 인덱스 비대화와 조회 지연에 부딪힙니다.
태그 체계와 수집 주기 설계
명명 규칙과 메타데이터
태그 이름은 ISA-95 계층(사이트-라인-설비-신호)을 따르면 사람이 읽기 쉽고 검색도 쉬워집니다. 예를 들면 `P1.L2.INJ03.MOLD_TEMP`와 같은 형태입니다. 태그마다 단위, 정상 범위, 수집 주기, 원천 장비를 메타데이터로 함께 관리해야 이후 분석에서 같은 값을 다르게 해석하는 문제가 생기지 않습니다.
수집 방식 선택
압축·다운샘플링·보존 정책
원본은 수개월만 보관하고, 1분 집계(평균·최소·최대·표준편차)와 1시간 집계를 계층화해 장기 보관하는 구성이 일반적입니다. 1분 집계는 원본(1초 주기) 대비 포인트 수가 60분의 1, 1시간 집계는 3,600분의 1로 줄어듭니다. 이때 평균만 남기면 순간적인 스파이크가 사라지므로 최소·최대값을 함께 저장해야 합니다.
압축 알고리즘이 지워서는 안 되는 구간도 있습니다. 알람 직전·직후 구간, 불량이 발생한 로트의 생산 구간은 원본 해상도로 별도 보호 정책을 두어야 원인 분석이 가능합니다.
생산 실적·로트와 시계열을 잇는 법
핵심은 컨텍스트화입니다. MES의 작업지시·로트별 시작/종료 시각과 투입 설비를 기준으로 시계열 구간을 묶습니다.
이 구조를 갖추면 "불량 로트 10건과 양품 로트 10건의 금형 온도 분포 비교" 같은 분석을 쿼리 몇 줄로 수행할 수 있습니다.
단계적 도입 로드맵과 POLYGLOTSOFT의 접근
처음부터 전 공장 태그를 대상으로 삼기보다, 불량 영향이 큰 핵심 설비 1~2대와 핵심 태그 50~200개로 파일럿을 시작하는 것이 효과적입니다. 명명 규칙, 보존 정책, 로트 연계 쿼리를 파일럿에서 검증한 뒤 라인 단위로 확장하면 시행착오를 줄일 수 있습니다.
POLYGLOTSOFT는 MES와 IoT 게이트웨이 구축 역량을 바탕으로 태그 체계 설계, 수집 주기 정의, 저장소 구성, 로트 연계 조회 화면까지 일괄로 설계해 드립니다. 쌓아만 두고 쓰지 못하는 설비 데이터가 있다면, 현재 수집 구조 진단부터 함께 시작해 보시기 바랍니다.