2026. 06. 16 회의록

프로젝트 재소개

현재 진행 중인 AIMS(AI Manufacturing Monitoring System) 프로젝트는 자동차 제조 공정을 대상으로 하는 스마트팩토리 통합 관제 시스템이다.

실제 제조 데이터를 수집하는 환경은 아니기 때문에, 현재는 Sample DB에 저장된 제조 이벤트 데이터를 기반으로 공정 흐름을 시뮬레이션하는 형태로 개발을 진행하고 있다.

오늘은 제조 데이터를 Kafka 기반 이벤트 구조로 전환하기 위한 데이터 모델과 Topic 설계를 진행하였다.

---

제조 이벤트 데이터 구조 재정비

기존 원본 데이터셋은 공정별 컬럼 구조가 다르고 관제 시스템에서 바로 사용하기 어려운 형태였다.

따라서 관제 시스템이 이해하기 쉬운 형태의 통합 제조 이벤트 구조를 정의하였다.

manufacturing_event_json

Scheduler가 Kafka로 전송할 원본 이벤트를 저장하는 테이블이다.

주요 정보는 다음과 같다.

* 이벤트 정보

  * event_id
  * event_time

* 차량 및 설비 정보

  * car_master_id
  * equipment_id

* 공정 정보

  * process_code
  * station_code

* 설비 상태 정보

  * equipment_code
  * equipment_type
  * equipment_status

* 이벤트 정보

  * event_type
  * event_json

* Kafka 전송 관리

  * is_sent
  * sent_at

Scheduler는 아직 전송되지 않은 이벤트를 조회한 후 Kafka Topic으로 발행한다.

manufacturing_event_json
↓
is_sent = false 조회
↓
event_time 정렬
↓
Kafka Producer 전송
↓
is_sent = true
↓
sent_at 저장

---

제조 이벤트 JSON 표준화

원본 데이터를 그대로 사용하는 대신 관제 시스템에서 필요한 의미 기반 구조로 변환하였다.

{
  "event": {},
  "location": {},
  "equipment": {},
  "equipmentStatus": {},
  "product": {},
  "sensor": {},
  "manufacturing": {},
  "processMetrics": {},
  "processData": {},
  "sourceTrace": {}
}

이를 통해 모든 서비스가 동일한 메시지 포맷을 사용할 수 있도록 구성하였다.

---

Kafka 도입 이유

현재 프로젝트는 여러 서비스가 동일한 제조 이벤트를 활용한다.

예를 들어 하나의 제조 이벤트가 발생하면 다음 작업들이 동시에 수행된다.

• AI 이상 분석
• 병목 분석
• 설비 상태 계산
• 실시간 알림 생성
• Elasticsearch 저장
• Dashboard 표시

Kafka 없이 구현하면 각 서비스가 동일 데이터를 개별 조회해야 한다.

Kafka를 사용하면 이벤트를 한 번 발행하고 여러 서비스가 독립적으로 구독할 수 있다.

Scheduler
↓
Kafka
├─ AI Service
├─ Manufacturing Service
├─ Equipment Service
├─ Elasticsearch Consumer
└─ Redis Consumer

서비스 간 결합도를 낮추고 확장성을 확보할 수 있다는 장점이 있다.

---

Kafka Topic 설계

1. factory.manufacturing.raw

모든 제조 이벤트가 가장 먼저 전달되는 원천 이벤트 Topic이다.

Producer

• Scheduler

Consumer

• Manufacturing Service
• AI Service
• Equipment Service
• Redis Consumer
• Elasticsearch Consumer

MVP 단계에서는 공정별 Topic을 나누지 않고 하나의 Raw Topic으로 관리하기로 결정하였다.

PRESS
BODY
PAINT
ASSEMBLY

공정 구분은 processCode 값으로 처리한다.

---

2. factory.manufacturing.analysis

AI 분석 결과를 전달하는 Topic이다.

포함 정보

• overallRiskScore
• bottleneckRisk
• defectTransferRisk
• equipmentRisk
• riskLevel
• recommendation

예상 활용

• 병목 예측
• 설비 이상 감지
• 품질 이상 감지
• 불량 전이 예측

---

3. factory.manufacturing.alert

위험 이벤트만 별도로 전달하는 Topic이다.

분석 결과가 WARNING 또는 CRITICAL 수준일 경우 생성된다.

분석 결과
↓
Alert 생성
↓
Kafka Alert Topic
↓
WebSocket
↓
Dashboard 알림 표시

실시간 알림 기능 구현의 핵심이 되는 Topic이다.

---

4. factory.manufacturing.equipment

설비 상태 계산 결과를 전달한다.

포함 정보

• 설비 상태
• 가동 시간
• 정지 시간
• 유휴 시간
• 가동률

Dashboard에서 설비 모니터링에 활용될 예정이다.

---

전체 이벤트 흐름

최종적으로 정리된 제조 이벤트 흐름은 다음과 같다.

Sample DB
↓
manufacturing_event_json
↓
Scheduler Producer
↓
factory.manufacturing.raw
↓
AI Service
Manufacturing Service
Equipment Service
↓
factory.manufacturing.analysis
↓
Redis
Main DB
Elasticsearch
↓
factory.manufacturing.alert
↓
WebSocket
↓
Dashboard

설비 상태 계산 흐름은 별도로 분리된다.

factory.manufacturing.raw
↓
Equipment Service
↓
factory.manufacturing.equipment
↓
Redis
Main DB
Dashboard

---

추가 진행 사항

인프라

• Frontend Dockerfile 작성
• GitHub Actions 추가
• 배포 후 도메인 연결 작업 진행

데이터 전처리

• 검사 데이터 전처리 Python 코드 작성 진행 중

강사님 피드백

• ALB 443 리스너 규칙 수정 필요
• 로드밸런서 및 대상 그룹(Target Group) 재확인 필요

---

마무리

오늘은 제조 데이터를 단순 조회 방식이 아닌 이벤트 기반 구조로 전환하기 위한 설계를 진행하였다.

특히 Kafka를 중심으로 제조 이벤트, AI 분석 결과, 알림 이벤트, 설비 상태 데이터를 분리함으로써 향후 MSA 확장과 실시간 관제 기능 구현이 가능하도록 구조를 정리할 수 있었다.

다음 단계에서는 Scheduler Producer 구현과 Kafka Consumer 개발을 통해 실제 제조 이벤트가 Dashboard까지 전달되는 흐름을 구현할 예정이다.