SK쉴더스 루키즈 지능형 애플리케이션 개발 5기 최종 프로젝트 - 1조 보안 관제

배포 주소: https://aims-factory.com

AIMS: 자동차 제조 공정의 설비·센서 이벤트를 실시간으로 분석하여 이상을 탐지하고, 관제사의 신속한 대응을 지원하는 스마트팩토리 통합 관제 플랫폼

• ML·SHAP 기반 불량 탐지 및 타 공정 전이 예측
• RAG·LLM 기반 관제사 숙련도별 AI 대응 매뉴얼 제공
• 위험도·발생 빈도·조치 이력 기반 알림 우선순위 산정
• AGV 운행 상태와 공정별 물류 흐름 실시간 시각화
• Kafka 기반 MSA와 Kubernetes를 활용한 확장·복구 가능한 운영 환경 구축

메인 대시보드

프레스 공정	차체 공정
도장 공정	의장 공정

검사 현황	검사 분석 결과

혼동행렬	성능지표

• LightGBM, CatBoost, XGBoost, Logistic Regression 총 4가지 머신러닝 모델을 학습하고, 재현율·정밀도·F1-Score·정확도를 기준으로 성능을 비교
• 제조 데이터의 비선형 패턴과 특성 간 상호작용, 학습 속도 및 예측 성능을 종합적으로 고려하여 LightGBM을 최종 모델로 선정
• 4개의 공개 제조 데이터셋을 AIMS 제조 이벤트 구조로 통합하고, 센서값과 공정·설비 정보를 기반으로 35개의 주요 Feature를 생성
• 결측값과 이상치를 처리하고, 데이터 불균형 및 Feature Leakage 문제를 개선하여 모델의 불량 탐지 성능을 향상
• 최종 LightGBM 모델은 재현율 93.41%, 정밀도 76.74%, F1-Score 84.26%, 정확도 92.99%의 성능을 달성
• 제조 이벤트를 분석하여 현재 공정의 불량 가능성과 다음 공정으로의 불량 전이 확률을 예측하고, SHAP 기반 주요 원인을 함께 제공

이상 이벤트 발생	주니어	시니어

• RAG는 설비 조치 매뉴얼, 기술 문서·사양, 과거 장애 사례, 체크리스트 등 AI가 참고할 지식 문서를 벡터 데이터베이스에 저장
• 이상 이벤트가 입력되면 Vector Search를 통해 이벤트와 유사한 문서를 검색하고, 관련 정보를 LLM의 답변 근거인 컨텍스트로 제공
• Prompt에는 AI의 역할과 답변 기준을 정의하고, 답변이 원인 분석 → 단계별 조치 방법 → 주의사항 → 추가 점검 사항 순서로 생성되도록 구성
• 담당자의 숙련도에 따라 설명 수준을 조절하고, 전문 용어를 쉽게 설명하며 검색된 매뉴얼을 기반으로 답변하도록 프롬프트 조건을 설정
• Data에는 회사 정보, 업무 규정·정책, 설비·라인 정보, 내부 용어·코드 체계 등 회사 고유의 도메인 정보를 구성
• RAG에서 검색한 근거 문서와 Prompt의 답변 형식, 회사 Data를 함께 활용하여 회사 환경에 맞는 일관되고 신뢰도 높은 대응 가이드를 생성
• 생성된 가이드는 담당자가 즉시 활용할 수 있도록 원인, 조치 절차, 주의사항 및 점검 항목으로 구조화하여 대시보드에 제공

알림 우선순위 구조	알림 목록
알림 조치	알림 상세

• 기존 관제에는 Risk Score만으로 설비 위험도를 판단하여 반복 발생 여부와 과거 조치 이력이 반영되지 않고, 다수의 알림 발생 시 우선순위를 구분하기 어려운 한계가 존재
• FMEA 개념을 현장 관제 환경에 적용하여 Risk Score, Occurrence, Detection을 반영한 Adaptive eRPN 기반 알림 우선순위 알고리즘을 설계
• Risk Score는 현재 이벤트의 물리적 위험도, Occurrence는 동일·유사 이벤트의 반복 발생 빈도, Detection은 과거 조치 이력과 실제 대응 필요성을 기준으로 산정
• Priority Score = Risk × (1 + Occurrence) × (1 + Detection) 공식을 적용하여 여러 이상 알림의 중요도를 정량적으로 계산
• 산정된 우선순위 점수를 기준으로 온도·진동·전류 이상 알림을 높은 점수순으로 정렬하여 관제 화면 상단에 우선 노출
• 우선순위가 산정된 알림은 WebSocket을 통해 실시간으로 전송하여 관제사가 긴급한 이상 상황을 즉시 확인하고 대응할 수 있도록 구성

• Kafka Consumer가 제조 분석 결과를 수신하고, 공정 위험도가 높거나 isAbnormal=true인 이상 이벤트를 선별하여 AGV 출발 요청을 자동 등록
• 1초 주기의 AGV 배차 스케줄러를 구성하고, ShedLock을 적용하여 여러 서버에서 동일 작업이 중복 실행되지 않도록 제어
• AGV 배차 시 상태를 선점 잠금 방식으로 갱신하여 동일한 AGV가 여러 작업에 중복 배정되는 문제를 방지
• 사용 가능한 AGV가 없으면 배차 요청을 Redis 기반 FIFO 대기열에 저장하고, AGV가 확보되면 대기 순서에 따라 작업을 다시 배정
• AGV의 이동 과정을 4단계 상태 머신으로 관리하여 운반 상태를 실시간으로 전이하고, 장애 발생 시 상태를 자동 복구하도록 구성
• AGV의 위치와 운반 상태를 WebSocket/STOMP의 /topic/agv 채널을 통해 대시보드로 실시간 전송
• React와 Three.js를 활용해 공정별 AGV 이동 경로와 상태를 3D로 시각화하여 관제 화면에서 운반 현황을 즉시 확인할 수 있도록 구성

• Kafka를 통해 비동기 이벤트 처리를 적용하여 서비스 간 의존도를 낮추고, 일부 서비스 장애 상황에서도 이벤트를 안정적으로 전달
• MSA 환경에서 서비스의 독립성·확장성·장애 격리를 확보할 수 있는 이벤트 중심 아키텍처를 구축
• 제조 이벤트를 Kafka Topic에 한 번 발행하고, 각 서비스가 필요한 이벤트를 독립적으로 구독하여 처리하도록 구성
• 기존 서비스 간 직접 연결 방식에서 발생하던 강한 결합과 변경 영향 범위 확대 문제를 Kafka 기반 이벤트 스트리밍으로 개선
• 서비스별로 Kafka Topic과 Consumer Group을 분리하여 동일 이벤트를 각 서비스의 목적에 맞게 독립적으로 처리
• 신규 분석 기능이나 서비스 추가 시 기존 서비스의 직접적인 수정 없이 Consumer를 추가하여 유연하게 확장

• Kafka를 통해 수신한 제조 이벤트와 공정 분석 결과를 Elasticsearch에 실시간으로 인덱싱하여 대용량 데이터를 저장
• 불량 탐지 결과, 공정 병목 정보, 설비 상태 및 위험도 분석 결과를 인덱스별로 분리하여 효율적으로 관리
• 차량 ID, 공정 코드, 설비 정보, 분석 유형, 위험도 등 다양한 조건을 조합한 고속 검색·조회 기능을 제공
• Kibana 대시보드를 통해 Elasticsearch에 저장된 분석 결과를 그래프 및 로그 형태로 시각화
• Kafka와 Elasticsearch를 연계하여 데이터 수집부터 검색·분석·대시보드 시각화까지 이어지는 실시간 제조 데이터 분석 환경을 구축

• 이상 이벤트가 발생하면 분석 결과와 알림 정보를 WebSocket/STOMP를 통해 관제 대시보드로 실시간 전송
• 알림 우선순위, 위험도, 공정·설비 정보 및 발생 시각을 /topic/alerts 채널로 전달하여 즉시 화면에 반영
• AGV의 현재 위치, 운반 상태 및 이동 경로 정보를 /topic/agv 채널로 실시간 전송
• AGV의 출발·이동·도착 등 상태 변화를 대시보드에 즉시 반영하여 공정별 운반 현황을 실시간으로 관제

• Route 53을 통해 서비스 도메인 요청을 처리하고, ACM 인증서를 적용하여 HTTPS 기반의 안전한 통신 환경을 구성
• Public Subnet에는 외부 요청을 수신하는 ALB와 Private Subnet의 외부 통신을 지원하는 NAT Gateway를 배치
• ALB Ingress Controller를 통해 외부 요청을 서비스별 경로에 따라 EKS 내부 애플리케이션으로 라우팅
• Private Subnet에는 EKS 애플리케이션, Amazon MSK, RDS MySQL, ElastiCache Redis 및 OpenSearch를 배치하여 외부 접근을 제한
• 애플리케이션과 데이터 저장소를 내부 네트워크에서만 통신하도록 분리하여 공격 표면을 최소화하고 데이터 보안을 강화

• Frontend, Backend, Assembly Service, Quality Service, AI Service를 각각 독립적인 컨테이너 서비스로 구성
• 각 서비스의 애플리케이션을 Docker Image로 빌드하고, Amazon ECR에서 이미지와 버전을 관리
• 서비스를 Kubernetes의 Deployment와 Service 단위로 배포하여 기능별 독립적인 운영과 확장이 가능하도록 구성
• AWS Load Balancer Controller와 Ingress를 적용하여 Route 53 → ALB → Ingress → Service → Pod 순서로 요청을 전달하고, 경로에 따라 각 MSA 서비스로 라우팅
• 특정 서비스의 장애나 트래픽 증가 시 해당 서비스의 Pod만 개별적으로 복구·확장하여 다른 서비스에 미치는 영향을 최소화

• Amazon MSK를 통해 제조 이벤트와 분석 결과를 실시간으로 수집하고, 각 서비스가 Kafka 이벤트를 독립적으로 구독하여 처리
• RDS MySQL의 SampleDB와 MainDB를 분리하여 원천 제조 데이터와 서비스 운영 데이터를 목적에 따라 저장
• ElastiCache Redis를 활용하여 세션, 실시간 상태 및 반복 조회 데이터를 캐싱하고 데이터 조회 부하를 감소
• OpenSearch에 제조 이벤트와 분석 결과를 저장하여 공정·설비·위험도 등 다양한 조건의 빠른 검색과 분석을 지원

• 데이터베이스 계정, API Key 등 민감한 설정값을 AWS Systems Manager Parameter Store에서 중앙 관리
• External Secrets Operator(ESO)가 Parameter Store의 값을 조회하여 Kubernetes Secret으로 자동 동기화
• 애플리케이션은 Kubernetes Secret을 통해 필요한 설정값을 주입받아, 중요 정보가 소스 코드나 배포 파일에 직접 노출되지 않도록 구성

• 개발자가 GitHub Repository에 코드를 Push하면 GitHub Actions가 애플리케이션 테스트와 빌드를 자동으로 수행
• 빌드가 완료되면 Docker Image를 생성하여 Amazon ECR에 저장하고 이미지 태그를 통해 버전을 관리
• 신규 이미지 버전에 맞게 Kubernetes Manifest의 이미지 태그를 자동으로 갱신
• Argo CD가 Infra Repository의 변경 사항을 감지하고, 선언된 Manifest와 실제 EKS 클러스터 상태를 비교하여 자동 동기화
• 애플리케이션 코드와 배포 설정을 분리하고 모든 변경 이력을 Git으로 관리하여 추적 가능성, 운영 일관성 및 롤백 편의성을 확보

• Kubernetes Rolling Update 방식을 적용하여 기존 Pod를 유지한 상태에서 신규 버전의 Pod를 순차적으로 생성
• 신규 Pod가 Readiness Probe를 통과한 경우에만 서비스 트래픽을 전달하여 준비되지 않은 Pod로 요청이 유입되는 상황을 방지
• 정상적으로 실행 중인 신규 Pod로 트래픽을 점진적으로 전환한 뒤 기존 Pod를 종료하여 배포 중 서비스 중단을 최소화
• 배포 과정에서 문제가 발생하면 이전 ReplicaSet으로 빠르게 롤백하여 안정적인 서비스 운영이 가능하도록 구성
• 서비스별 독립 배포 구조를 통해 특정 기능의 변경이나 장애가 전체 시스템으로 확산되는 것을 최소화

• Main Backend Repository
• Assembly Repository
• Quality Repository
• AI Repository
• Frontend Repository
• Infra Repository

최혜인(팀장)	김건	박미정	이준호	임종찬	하서경