Reference & Project
Case study
객관적 데이터로 풀어낸 노리시스템의 핵심 인사이트
MES 사례
MOS, OI, TC와 설비 Dispatcher를 이벤트 스트림으로 연결합니다. 시스템 간 직접 호출을 메시지 기반 연동으로 대체하여, 향후 RMS·SPC 확장까지 동일한 구조 위에서 수용합니다.
이벤트 연동
Kafka Topic · Pub/Sub · 표준 envelope
업무 처리 엔진
WSM · 설비 Dispatcher(ADS) · MES 코어
운영 · 관측
Kubernetes · OpenTelemetry · LGTM
연동 대상
MOS · OI · TC · 설비
서로 다른 시스템과 설비를 하나의 이벤트 버스로 통합하는 EAI 구성
확장 방식
Plug-in 방식 확장
기존 연동을 수정하지 않고 토픽 구독만으로 신규 시스템을 언제든 끼워 넣습니다.
시스템이 늘어날수록 인터페이스가 급증하는 구조와, 설비 상태 변화에 즉시 대응해야 하는 요구를 동시에 해결해야 했습니다.
시스템이 늘어날수록 인터페이스 수가 급격히 증가하고, 한 시스템의 변경이 연결된 모든 지점에 영향을 미칩니다.
배치 방식의 데이터 교환으로는 설비 상태 변화에 즉시 대응하기 어렵고, 지시 전달과 실적 수집 사이에 지연이 발생합니다.
시스템을 직접 연결하는 대신 이벤트 버스를 중심에 두어, 연동 대상이 늘어나도 인터페이스 복잡도가 선형으로 유지되도록 설계합니다.
발행·구독 구조
발신 측은 토픽에 기록만 하며 수신 측의 가동 상태를 알 필요가 없습니다.
메시지 보존과 재처리
일정 기간 메시지가 보존되므로, 장애 복구 후 밀린 데이터를 순서대로 이어서 처리할 수 있습니다.
이벤트 발생부터 토픽 적재, 스트림 처리, MES 반영, Dispatcher 지시까지 하나의 흐름으로 이어집니다.
설비와 상위 시스템에서 상태 변화와 실적이 발생합니다.
발신 측은 토픽에 기록만 하며, 수신 측 상태와 무관하게 동작합니다.
메시지 형식을 변환하고 규칙에 따라 분기·집계합니다.
작업 진척과 재공 상태가 MES에 실시간으로 갱신됩니다.
다음 작업 대상을 판정하여 설비에 지시를 내려보냅니다.
연동 방식이 달라도 같은 이벤트 계약을 사용하고, 메시지는 보존·재처리됩니다. 신규 시스템은 토픽 구독만으로 추가되고, 처리량 증가는 파티션과 컨슈머 확장으로 흡수합니다.
정상 발행 지속
offset 유지 · 적재 계속
일시 중단
기존 연동 수정 없음
각 시스템은 상대의 주소나 가동 상태를 알지 않고 토픽에만 발행·구독합니다. 연동 대상이 늘어나도 인터페이스 복잡도가 선형으로 유지됩니다.
시스템 분리, 순서 보장, 이벤트 영속화를 전제로 파이프라인을 설계하여 설비 데이터의 정합성과 복구 가능성을 확보했습니다.
설비 데이터 송신자와 수신자를 완전히 분리(Decoupled)하여, 특정 서비스 장애가 설비 데이터 수집이나 타 시스템에 영향을 주지 않도록 격리했습니다.
동일 설비에서 발생하는 상태 전이 및 계측 이벤트의 엄격한 시간순(FIFO) 처리를 보장하여 데이터 정합성을 유지합니다.
디스크 기반 메시지 영속화(Retention)를 통해 후행 시스템 장애 발생 시에도 데이터 유실 없이 정상 복구 시점부터 안전하게 재처리합니다.
설비 데이터가 순간적으로 폭증해도 브로커가 완충 역할을 수행하여, 후행 시스템은 자신의 처리 속도에 맞춰 소비합니다. 점대점 연동에서 발생하던 서버 다운과 타임아웃을 구조적으로 차단합니다.
시스템마다 다른 인터페이스를 만들지 않고, 필요한 토픽만 구독하는 방식으로 각자 독립적으로 동작합니다.
작업 계획과 진척 정보를 교환하여 실행 상태를 동기화합니다.
현장 단말의 입력과 조회 요청을 실시간 이벤트로 처리합니다.
설비 RESERVE, Lot Process Start · End · Complete, DCol 정보를 전송합니다.
설비 가용 상태와 우선순위를 반영해 다음 작업을 배정합니다.
Kafka 스트리밍, MSA 구조, Kubernetes 운영, 자동 확장과 자동 복구, 업무 커버리지, 통합 관제를 하나의 기반 위에서 제공합니다.
실시간 제조 데이터를 병렬·분산 처리. 파티션 동시성으로 데이터 폭주에도 유실 없이 흡수합니다.
단위 서비스별 독립 배포·부분 업데이트. 특정 모듈 장애가 전체 중단으로 번지는 위험을 차단합니다.
클라우드·온프레미스 하이브리드 모두 적용. 컨테이너 자원을 영리하게 활용해 인프라 비용을 최소화합니다.
Auto-scaling으로 즉시 자원 확장, Self-healing이 장애 노드를 자동 복구해 무중단 환경을 유지합니다.
기준정보·생산이력·자재수불·품질검사·설비보전 등 스마트팩토리 핵심 업무를 완결성 있게 지원합니다.
로그 분석과 실시간 알람으로 운영 상태를 한눈에 관제. 이상 징후를 조기 포착해 선제 대응합니다.
설비·TC와 OI 프론트·백엔드가 Kafka를 경유해 WSM 엔진과 통신하고, ADS가 다음 작업 설비를 판정합니다.
장비 / 센서
장비 제어
운영자 화면(UI)
운영 API·이벤트
LOT STEP별 가용 설비 반환
◂ WO_BESTWORK_REQ이벤트 처리·라우팅 엔진
⇄ JDBCvia PgBouncer
metadata와 data로 구성된 공통 envelope를 사용하고, eventType 단일 매핑으로 이벤트가 정확히 하나의 핸들러로 전달됩니다.
MES 하위 시스템 간 양방향 데이터를 이벤트로 표준화해 주고받습니다.
하나의 결과를 여러 후속 토픽으로 확장 발행 — 소비자 추가 시 발행 측 코드 수정이 필요하지 않습니다.
eventType 단일 매핑으로 이벤트가 정확히 하나의 핸들러로 라우팅됩니다.
// 공통 메시지 스키마 (envelope) { "metadata" : { "eventType": "MAT_CREATE", "timestamp": "2026-07-14T09:12:03Z", "source": "MCS", "correlationId": "L-0121010" }, "data": { "matId": "L-0121010", "eqpId": "EQP-042", "stepSeq": 10 } }
OpenTelemetry로 수집한 세 종류의 신호를 도메인 키로 묶어, 이벤트가 지나간 경로와 지연 구간을 그대로 되짚을 수 있습니다.
구조화 로그 수집·검색
통합 대시보드·알람
분산 트레이스 저장
장기 메트릭 저장
Pod 내 Java Agent
kubelet · cAdvisor
라벨 인덱스 · 객체 스토리지
TraceID 기반 조회
Prometheus 호환 장기 보관
로그에서 TraceID로 트레이스를 열고, 트레이스 구간에서 해당 시점의 메트릭으로 이동하는 상호 참조를 하나의 화면에서 수행합니다.
이벤트가 거치는 서비스·토픽 구간을 추적해 병목·실패 지점을 시각화합니다.
mat_id · eqp_id · step_seq 도메인 키를 로그·트레이스·메트릭에 자동 주입해 3종 신호를 한 축으로 연결합니다.
Prometheus 메트릭 기반 임계치 알람으로 이상 징후를 조기에 포착합니다.
인메모리 전송 방식과 달리 디스크에 영속 저장하므로, 장애 복구 후 밀린 이벤트를 순서대로 이어서 처리합니다.
브로커가 전달을 전담하여 데이터베이스는 트랜잭션에 집중하고, 하나의 이벤트를 여러 소비자가 동시에 처리합니다.
Java · Spring Boot · Kafka · PostgreSQL · Kubernetes · OpenTelemetry 등 검증된 오픈 기술로 구성했습니다.
한 시스템의 점검이나 장애가 다른 시스템의 처리를 멈추지 않고, 복구 후 밀린 메시지를 이어서 처리합니다.
설비 상태 변화가 발생한 즉시 다음 작업 배정에 반영되어 설비 대기 시간을 줄입니다.
레시피 관리와 공정 통계 분석은 기존 토픽을 구독하는 방식으로 추가되므로, 기존 연동을 수정하지 않고 확장할 수 있습니다.