AGV 운행 구조 개선과 멘토님 피드백 정리
오늘은 AGV 운행 로직을 AI 분석 결과 중심으로 개선하는 작업을 진행했고, 멘토님 피드백을 통해 프로젝트 구조와 기술 선택에 대해서도 많은 이야기를 들었다.
AI 분석 기반 AGV 운행 로직 개선
기존에는 제조 이벤트가 발생하면 AGV가 바로 출발하는 구조였다.
하지만 이 경우 AI 분석 결과가 Abnormal이어도 AGV가 먼저 출발하는 문제가 발생할 수 있었다.
그래서 전체 흐름을 다시 정리했다.
Manufacturing Event 발생
↓
AI Analysis 수행
↓
정상 여부 판단
↓
정상 → AGV 출발
비정상 → AGV 출발 취소또한 AGV가 모두 운행 중인 경우를 대비해 Route별 Dispatch Queue를 설계했다.
기존에는 대기 중인 AGV가 없으면 예외를 발생시키는 방식이었다.
WAITING AGV 없음
↓
Exception
이를 다음과 같이 변경하려고 한다.
WAITING AGV 없음
↓
Route Queue 저장
↓
AGV 복귀
↓
Queue 확인
↓
자동 Dispatch이 구조를 사용하면 AGV가 모두 사용 중인 상황에서도 이벤트를 유실하지 않고 순차적으로 처리할 수 있다.
Kafka 분석 이벤트 구조 점검
오늘 가장 오래 걸렸던 부분이다.
처음에는 AI 서비스에서
Process Risk Analysis
Bottleneck Analysis
Defect Transfer Prediction
총 3개의 Analysis 이벤트를 각각 발행한다고 생각했다.
그래서 Main Backend에서는 3개의 분석 결과를 모두 모은 뒤 하나라도 Abnormal이면 AGV를 출발시키지 않는 Aggregation 구조를 만들었다.
하지만 실제 코드를 확인해 보니 Assembly에서는 Analysis 이벤트를 한 번만 발행하도록 변경되어 있었다.
이 때문에 Main Backend에서는 3개를 계속 기다리기만 하면서 AGV가 출발하지 않는 문제가 발생했다.
결국 현재 AI 분석 이벤트 구조를 다시 확인하고 Main Backend 로직도 함께 수정하는 작업을 진행했다.
멘토님 피드백
오늘 멘토님께 받은 피드백도 정리해봤다.
1. 프로젝트 구조 통일
Assembly와 Backend는 같은 사람이 구조를 잡아서 코드 스타일이 비슷했지만 Quality Service는 구조가 달라 이질감이 느껴졌다고 하셨다.
큰 프로젝트에서는 서비스마다 따로 관리하기보다
common
config
dto
같은 공통 모듈을 Root Project에서 관리하는 것이 유지보수하기 훨씬 좋다고 한다.
특히 라이브러리 버전 변경이나 DTO 수정 시 여러 프로젝트를 동시에 수정하지 않아도 된다는 장점이 있다.
2. AI를 사용하는 이유를 명확하게 설명하기
"AI를 사용했습니다."보다
왜 AI를 사용했는지를 설명하는 것이 중요하다고 하셨다.
예를 들어
사람이 판단하기 어려운 이상 징후 탐지
제조 데이터의 위험도 예측
공정 간 불량 전이 예측
처럼 AI가 해결하는 문제를 먼저 설명해야 한다.
3. VLM 활용 방식
VLM은 단순히 이미지 분류 모델이 아니라 언어를 함께 이해하는 모델이기 때문에 GPU 사용량이 매우 크다.
그래서 실제 서비스에서는
ML 모델
↓
이상 탐지
↓
VLM
↓
최종 검증
↓
관제사 확인과 같이 사용하는 것이 일반적이라고 하셨다.
4. OpenSearch(ElasticSearch)를 사용하는 이유
OpenSearch는 많은 Raw 데이터를 저장하고 시계열 분석을 수행할 때 강점을 가진다.
하지만 우리가 다루는 알림은 이미 이상 이벤트만 필터링된 데이터이기 때문에 굳이 OpenSearch를 사용할 필요는 없다고 하셨다.
일반적인 관제 시스템에서는
Raw Event
↓
이상 감지
↓
알림 전송
↓
DB 저장순서로 처리하는 경우가 많다고 한다.
또한 OpenSearch는 과거 이벤트와 현재 이벤트 비교 시계열 데이터 분석과 같은 용도로 활용하는 것이 더 적합하다고 설명해주셨다.
5. 라이브러리 버전 관리
현업에서는 신규 기능 개발보다 취약점 대응이 더 많은 경우도 있다고 한다.
그래서 build.gradle을 서비스별로 따로 관리하기보다 Root Project에서 공통 버전을 관리하면 라이브러리 업데이트도 한 번에 가능하다.
6. 프론트엔드 개선 사항
현재 제조/검사 페이지에서는 정상 범위와 이상 범위가 명확하지 않은 그래프가 있다.
프레스 공정처럼
정상 기준선
이상 기준선
을 함께 표시하면 사용자 입장에서 훨씬 직관적으로 데이터를 이해할 수 있다는 피드백을 받았다.
7. Logstash + Kibana 연동
추가로 logback-spring.xml을 수정해서 애플리케이션 로그를 Logstash로 전송하고, OpenSearch(ElasticSearch)에 저장한 뒤 Kibana에서 확인하는 구조도 추천해주셨다.
이렇게 하면 단순한 콘솔 로그보다 운영 환경에서 훨씬 효율적으로 로그를 분석할 수 있을 것 같다.
마무리
오늘은 단순히 기능 구현만 진행한 것이 아니라 AI 분석 이벤트 흐름과 AGV Dispatch 구조를 다시 설계하는 과정을 많이 고민한 하루였다.
특히 멘토님 피드백을 들으면서 "왜 이 기술을 사용하는가", "서비스 구조를 어떻게 가져가야 유지보수가 쉬운가"에 대해 다시 생각해볼 수 있었다.
내일은 Route별 Dispatch Queue를 마무리하고, Logstash-Kibana 연동도 함께 진행해볼 예정이다.
