Kafka 기반 AGV 운반 흐름 개선과 서비스 간 연동 방식 고민
오늘은 제조 이벤트와 AGV 운반 흐름을 다시 점검하면서, 공정 완료와 AGV 운반 완료 사이의 관계를 어떻게 설계해야 하는지에 대해 팀원들과 많은 논의를 진행했다.
또한 강사님 피드백을 통해 현재 프로젝트에서 가장 우선해야 하는 것이 무엇인지도 다시 한번 정리할 수 있었다.
AGV 운반 시점에 대한 고민
현재 프로젝트에서는 제조 공정이 완료되면 다음 공정을 READY 상태로 변경하고, AGV가 출발하도록 구현하고 있다.
하지만 현재 Assembly Service에서는 Scheduler가 5초마다 READY 상태의 이벤트를 조회하여 Kafka로 발행하는 구조이기 때문에 문제가 하나 발생한다.
예를 들어,
PRESS 공정 완료
↓
BODY 이벤트 READY
↓
Scheduler가 BODY 이벤트 Kafka 발행
↓
AGV는 아직 PRESS → BODY 이동 중
↓
BODY 공정이 먼저 시작됨실제 제조 공정에서는 AGV가 다음 공정에 도착해야 작업이 시작되어야 한다.
하지만 현재 구조에서는 AGV의 이동 여부와 관계없이 Scheduler가 READY 이벤트를 먼저 발행하기 때문에 비정상적인 흐름이 발생할 수 있다.
즉,
공정 준비(READY)와 실제 운반 완료를 동일하게 취급하면 안 된다는 문제가 생긴 것이다.
해결 방안 고민
방법 1. Kafka 이벤트로 운반 완료 전달
Main Backend
↓
factory.transport.completed
↓
Assembly ServiceAGV가 도착하면 Main Backend가 새로운 Kafka Topic에 운반 완료 이벤트를 발행하고,
Assembly Service가 이를 수신하여 다음 공정을 READY 상태로 변경하는 방식이다.
장점
- 서비스 간 결합도가 낮다.
- 이벤트 기반 아키텍처를 유지할 수 있다.
- AI 서비스, 통계 서비스 등 다른 서비스에서도 동일 이벤트를 쉽게 활용할 수 있다.
- 향후 기능 확장에 유리하다.
단점
- Topic과 Consumer를 추가로 관리해야 한다.
- 현재 프로젝트 규모에서는 다소 과한 구조가 될 수 있다.
방법 2. API 호출 방식
Main Backend
↓
POST /transport/complete
↓
Assembly ServiceAGV 운반이 완료되면 Main Backend가 Assembly Service의 API를 호출하여 다음 공정을 READY 상태로 변경하는 방식이다.
장점
- 구현이 단순하다.
- 별도의 Kafka Topic이 필요 없다.
- 즉시 처리할 수 있다.
- 현재 프로젝트 규모에 적합하다.
단점
- Main Backend가 Assembly Service를 직접 호출하게 되어 서비스 간 결합도가 높아진다.
- 다른 서비스에서 운반 완료 정보를 활용하려면 추가 개발이 필요하다.
현재 프로젝트에서는 구현 난이도와 일정 등을 고려하여 API 방식으로 우선 구현하기로 결정하였다.
강사님 피드백
오늘 강사님께서 여러 가지 피드백을 주셨는데, 가장 크게 느낀 부분은 MVP에 집중해야 한다는 점이었다.
현재는 Kafka나 Redis 같은 기술을 어떻게 활용할지 고민하는 데 많은 시간을 쓰고 있지만,
발표와 시연에서는 결국 사용자가 직접 볼 수 있는 기능이 가장 중요하다.
특히,
- MVP 기능을 먼저 완성할 것
- 데이터 구조는 미리 만들어 놓고 테스트를 병행할 것
- 데이터 흐름과 MVP 기능이 자연스럽게 연결되어야 할 것
이라는 점을 강조해 주셨다.
또한 AI 기능 역시 단순히 API를 호출하는 수준이 아니라,
- RAG
- Prompt Engineering
- MCP
- 전처리
등을 함께 고려해야 프로젝트의 차별성이 생길 수 있다는 조언도 들을 수 있었다.
느낀 점
오늘 가장 고민했던 부분은 "언제 다음 공정을 시작해야 하는가?"였다.
처음에는 단순히 공정이 끝나면 다음 이벤트를 READY로 만들면 된다고 생각했지만,
실제 제조 흐름에서는 AGV라는 물리적인 운반 과정이 존재하기 때문에 그 과정까지 고려해야 정상적인 시뮬레이션이 된다.
이번 논의를 통해 이벤트 기반 아키텍처를 설계할 때는 비즈니스 흐름과 실제 공정 순서가 일치하도록 설계하는 것이 중요하다는 점을 다시 한번 느꼈다.
또한 현재 프로젝트 단계에서는 이상적인 구조보다 발표와 시연에 필요한 MVP를 우선 완성하는 것이 더 중요하다는 점도 다시 한번 정리할 수 있었던 하루였다.
