📖 오늘 배운 내용 정리
오늘은 프로젝트 멘토링과 함께 Kafka, Elasticsearch, StreamSets 등 실제 보안관제 환경에서 사용하는 기술들에 대해 학습했다.
기존에는 단순히 기술 스택을 사용하기 위해 도입을 고민했다면, 오늘은 각 기술이 왜 필요한지와 실제 현업에서 어떤 문제를 해결하기 위해 사용하는지를 이해하는 데 집중했다.
🗓️ Redmine 운영 방식 정리
프로젝트를 진행하면서 가장 중요하게 강조된 부분은 "모든 업무를 Redmine에서 관리해야 한다"는 점이었다.
일정을 단순히 적어두는 수준이 아니라 실제 개발 프로세스가 Redmine 중심으로 돌아가야 한다.
권장 구조
일감 유형
* Epic : 큰 기능 단위
* Story : 사용자 요구사항
* Task : 개발 작업
* Bug : 결함 수정
* Spike : 기술 검토
* Test : 테스트Sprint 관리
버전을 Sprint 단위로 관리
예시
* v0.2
* v0.5
* v0.7
* v1.0각 Sprint마다 목표를 설정하고 완료 후 다음 Sprint로 넘어가는 방식으로 운영한다.
Git 브랜치 전략
main
└─ dev
├─ 291/login
├─ 292/dashboard
└─ 293/agv-flowTask 번호를 기준으로 브랜치를 생성하고 작업 완료 후 dev로 Merge한다.
최종적으로 안정화된 dev를 main으로 배포한다.
Kafka를 왜 사용하는가?
기존에는 Kafka를 단순히 "실시간 처리용" 정도로 생각하고 있었는데 실제 핵심은 서비스 간의 완전한 분리(Decoupling)였다.
첫 번째 관점
MSA 환경에서 서비스 간 통신 담당
Scheduler
↓
Kafka
↓
AGV Service
Alert Service
AI ServiceProducer는 메시지만 발행한다.
Consumer는 필요한 메시지만 구독한다.
서로 직접 호출하지 않기 때문에 서비스 간 의존성이 크게 줄어든다.
두 번째 관점
서비스 간 성능 차이 해결
예를 들어
* 데이터 수집 서비스
* AI 분석 서비스
* 알림 서비스가 있다고 가정하면
AI 분석이 느려도 수집 서비스는 계속 데이터를 Kafka에 적재할 수 있다.
즉 서비스마다 독립적으로 Scale Out이 가능해진다.
Kafka 핵심 개념
Topic
메시지를 분류하는 공간
예시
manufacturing-event
agv-event
alert-eventPartition
병렬 처리를 위한 단위
Partition 수가 많을수록 동시에 처리 가능
Consumer와 연결되어 처리량을 조절한다.
Offset
Consumer가 어디까지 읽었는지 저장하는 값
Elasticsearch를 왜 사용하는가?
Elasticsearch는 단순 저장소가 아니라 검색 엔진이다.
사용하는 이유
복잡한 검색
DB에서는 Full Scan이 발생할 수 있는 조건들을 빠르게 처리할 수 있다.
예시
- 특정 기간
- 특정 공정
- 특정 심각도
- 특정 키워드
등을 동시에 검색
대용량 로그 분석
보안관제에서는 수백만 건의 로그가 발생한다.
Elasticsearch는 데이터를 분산 저장하여 빠르게 검색할 수 있다.
시계열 데이터 분석
- 이벤트 발생 추이
- 공정별 장애 추이
- 월별 통계
등을 분석하기에 적합하다.
Elasticsearch 구조
Cluster
└─ Node
└─ Index
└─ Shard
└─ SegmentMaster Node
- 클러스터 관리
- 샤드 배치
- 인덱스 생성/삭제
Data Node
- 데이터 저장
- 검색 처리
- 인덱싱 수행
StreamSets
StreamSets는 데이터 파이프라인을 쉽게 구성할 수 있는 도구다.
예시
Kafka Consumer
↓
데이터 검증
↓
정규화
↓
Elasticsearch 저장복잡한 ETL 작업을 GUI 기반으로 구성할 수 있다.
🔍 보안관제 관점에서 얻은 인사이트
오늘 가장 인상 깊었던 내용은 보안관제의 핵심은 "관제 요원의 클릭 수를 줄이는 것"이라는 점이었다.
보안관제에서는 수많은 이벤트가 발생한다.
문제는
- 정탐
- 오탐
- 미탐
을 구분하기 위해 너무 많은 인력이 투입된다는 것이다.
그래서 실제 현업에서는
- 머신러닝
- AI 분석
- Rule Engine
등을 활용하여 사람이 확인해야 할 이벤트만 선별한다.
결국 좋은 관제 시스템은
"더 많은 정보를 보여주는 시스템"
이 아니라
"지금 꼭 봐야 하는 정보만 보여주는 시스템"
이라는 점을 배웠다.
💡 프로젝트 방향 수정 아이디어
멘토링을 통해 현재 프로젝트 구조에 대한 개선 방향도 얻을 수 있었다.
현재는
프레스 이벤트
차체 이벤트
도장 이벤트
의장 이벤트를 각각 따로 관리하고 있다.
하지만 실제 보안관제에서는 여러 이벤트를 정규화하여 하나의 이벤트 구조로 관리하는 경우가 많다.
예시
{
"eventType": "PROCESS_DELAY",
"process": "PAINT",
"severity": "HIGH",
"message": "공정 지연 발생"
}이처럼 이벤트 형식을 통일하면
- Rule Engine 작성
- 검색
- 분석
- AI 학습
이 훨씬 쉬워진다.
따라서 제조 데이터도 보안관제 방식처럼 정규화하여 관리하는 방향을 추가 검토해볼 예정이다.
📌 프로젝트에 적용할 내용
현재 우리 프로젝트는 자동차 제조 공정을 관제하는 시스템이지만,
보안관제에서 사용하는 기술들을 제조 환경에 적용하여 발전시키는 방향으로 진행하려고 한다.
예시
- Kafka 기반 이벤트 처리
- Elasticsearch 기반 검색 및 분석
- StreamSets 기반 데이터 정규화
- Rule Engine 기반 이상 탐지
- AI 기반 오탐 감소
- 영향 범위 분석
- 보고서 자동 생성
단순히 공장을 모니터링하는 수준이 아니라
"보안관제의 관점으로 제조 공정을 관리하는 시스템"
으로 발전시키는 것이 목표다.
🖊️ 느낀 점
이번 멘토링을 통해 기술을 사용하는 이유에 대해 많이 생각하게 되었다.
Kafka, Elasticsearch, StreamSets 모두 단순히 최신 기술이라서 사용하는 것이 아니라 실제 운영 환경에서 발생하는 문제를 해결하기 위해 존재한다는 점을 이해할 수 있었다.
앞으로도 "이 기술을 왜 사용하는가?"를 먼저 고민하고 프로젝트에 적용해야겠다고 느꼈다.
