부트캠프 최종 피드백 - 이력서와 프로젝트를 다시 돌아보다

부트캠프가 마무리 단계에 접어들면서 이력서와 최종 프로젝트에 대한 피드백을 받을 기회가 있었다.

그동안은 "구현을 많이 하면 좋은 프로젝트"라고 생각했지만, 이번 피드백을 통해 기능의 개수보다 그것을 어떻게 구현했고, 어떤 고민과 과정을 거쳤는지가 더 중요하다는 사실을 다시 한번 느낄 수 있었다.

이번 글에서는 이력서와 프로젝트 측면에서 받은 피드백을 정리하고, 앞으로 어떤 방향으로 개선할 것인지 기록해보려 한다.

📄 이력서 피드백

1. 기술 스택은 '사용했다'가 아니라 '활용했다'를 보여주기

기존 이력서에는 Java, Spring Boot, React처럼 기술 스택 위주로 작성되어 있었다.

하지만 실제로 중요한 것은 어떤 기술을 어디에 활용했고, 어떤 결과를 만들었는지였다.

예를 들어

• Kafka를 이용한 실시간 이벤트 처리
• Redis Queue 기반 AGV Dispatch 구현
• WebSocket(STOMP, SockJS)을 활용한 실시간 관제 화면 구현

처럼 프로젝트 경험과 함께 기술을 설명해야 한다는 피드백을 받았다.

기술은 나열하는 것이 아니라 경험과 연결될 때 비로소 강점이 된다는 점을 배웠다.

2. 결과물을 직접 확인할 수 있도록 구성하기

면접관은 짧은 시간 안에 지원자를 파악해야 한다.

따라서 프로젝트 설명만 작성하는 것이 아니라

• GitHub Repository
• Velog 기술 블로그
• 프로젝트 시연 영상

등 직접 확인할 수 있는 결과물을 함께 제공해야 한다는 피드백을 받았다.

앞으로는 프로젝트 하나를 완료하면 구현에서 끝나는 것이 아니라, 코드와 문서를 함께 정리하여 누구나 쉽게 프로젝트를 이해할 수 있도록 구성할 계획이다.

3. 자기소개서는 경험을 중심으로 작성하기

"책임감이 있다", "협업을 잘한다"와 같은 표현은 누구나 사용할 수 있다.

대신 실제 프로젝트에서

• 어떤 문제를 만났는지
• 어떻게 해결했는지
• 무엇을 배웠는지

를 중심으로 작성해야 설득력이 높아진다는 점을 배웠다.

특히 최근 수행한 프로젝트 경험을 적극 활용하여 개발자로서의 성장 과정을 보여주는 것이 중요하다는 피드백을 받았다.

4. 최근 프로젝트 경험 적극 반영하기

최근까지 진행했던 AIMS 프로젝트에서는 단순히 화면을 구현하는 수준을 넘어 실제 제조 공정을 가정한 실시간 관제 기능을 개발하였다.

특히 내가 담당했던 AGV 실시간 연동 기능은 이력서에서도 충분히 강점으로 활용할 수 있는 경험이라는 피드백을 받았다.

🚗 최근 수행한 AGV 실시간 연동 기능

프로젝트 후반에는 제조 공정 간 AGV 이동을 실시간으로 표현하는 기능을 집중적으로 개발하였다.

초기에는 새로고침을 해야만 상태가 변경되는 방식이었지만, 이를 실시간 구조로 개선하기 위해 WebSocket 기반 통신 구조를 설계하였다.

* Spring Boot WebSocket(STOMP + SockJS)
* React
* Redis
* Kafka

를 함께 활용하였다.

Kafka에서 제조 이벤트를 수신하면 Redis Queue를 통해 AGV 이동 요청을 관리하고, 백엔드에서는 AGV의 이동·도착·복귀 상태를 순차적으로 처리하도록 구현하였다.

상태가 변경될 때마다 WebSocket을 통해 프론트엔드로 즉시 데이터를 전송하여 관제 화면에서 AGV의 이동 상태가 실시간으로 반영되도록 구성하였다.

개발 과정에서는 단순히 기능을 구현하는 것보다 운영 환경에서 발생하는 문제를 해결하는 데 많은 시간을 투자했다.

특히 EKS 환경에서 Backend Pod가 여러 개 실행되면서 Scheduler가 중복 실행되는 문제, Kafka Consumer Group의 Partition 할당 문제, Redis Queue 중복 처리 문제 등을 직접 분석하고 개선하였다.

이 과정을 통해 단순한 기능 구현을 넘어 멀티 인스턴스 환경에서 실시간 시스템을 안정적으로 운영하기 위한 동시성 제어와 메시지 처리 방식에 대해 많은 경험을 쌓을 수 있었다.

프로젝트 최종 단계에서는 제조 이벤트 발생부터 AGV 이동, 다음 공정 전달까지 하나의 흐름으로 연결되는 실시간 관제 기능을 완성할 수 있었다.

🚀 프로젝트 발표 피드백

1. 기능보다 개발 과정을 보여주기

발표 자료는 기능 소개보다

• 왜 만들었는지
• 어떻게 개발했는지
• 어떤 과정을 거쳤는지

를 중심으로 구성하는 것이 좋다는 피드백을 받았다.

특히 Sprint 단위의 개발 과정과 협업 흐름을 함께 보여주면 프로젝트의 완성도를 더욱 효과적으로 전달할 수 있다고 느꼈다.

2. 협업 과정도 프로젝트의 결과물이다

프로젝트는 단순히 기능만 구현한 것이 아니라 팀원들과 함께 계획하고 개선하는 과정이었다.

그래서 발표 자료에는

• Sprint 일정
• Redmine Gantt Chart
• 기능 개발 순서
• 역할 분담

등 협업 과정을 추가하여 프로젝트가 어떤 방식으로 진행되었는지 보여줄 예정이다.

3. Troubleshooting도 중요한 발표 내용

이번 프로젝트에서는 다양한 문제를 경험했다.

예를 들어

• WebSocket 실시간 반영 문제
• Kafka Consumer Group Partition 이슈
• Redis Queue 중복 처리
• Scheduler 동시 실행 문제
• Multi Pod 환경에서 발생한 동시성 문제

등을 직접 해결하면서 프로젝트를 완성했다.

기능 구현보다 이러한 문제를 어떤 방식으로 분석하고 해결했는지를 발표에 포함하는 것이 프로젝트의 깊이를 보여줄 수 있는 요소라는 점을 배웠다.

4. 발표 구성 개선

발표의 전체 흐름도 다음과 같이 수정하기로 했다.

• 프로젝트 목적
• 핵심 기능
• 시스템 아키텍처
• Sprint 기반 개발 과정
• 시연
• 기대 효과
• 향후 계획

또한 시연 영상도 발표 내용을 반복하는 것이 아니라, AI 분석 결과와 AGV 실시간 관제처럼 프로젝트의 핵심 기능을 중심으로 보여주는 방향으로 수정할 예정이다.

✨ 마무리

이번 피드백을 통해 가장 크게 느낀 점은 프로젝트는 기능을 많이 만드는 것이 아니라, 문제를 해결하며 완성해 나가는 과정 자체가 가장 큰 결과물이라는 것이다.

또한 이력서 역시 기술을 나열하는 문서가 아니라, 내가 어떤 기술을 선택했고 어떤 문제를 해결했으며 그 과정에서 어떻게 성장했는지를 보여주는 기록이라는 점을 다시 한번 깨달았다.

앞으로는 프로젝트를 구현하는 것에서 끝나지 않고, 개발 과정과 트러블슈팅, 그리고 그 과정에서 얻은 경험까지 꾸준히 기록하며 성장하는 개발자가 되고자 한다.

이번 작업에서는 제조 이벤트가 발생하면 AGV가 실시간으로 출발하고, 공정 흐름도에 즉시 반영되는 기능을 구현했다.

단순히 AGV를 움직이는 것이 아니라 Assembly Service → Kafka → Main Backend → Redis → WebSocket → Frontend까지 하나의 이벤트가 여러 서비스를 거쳐 화면에 표시되는 전체 흐름을 구성하는 것이 목표였다.

전체 아키텍처

최종적인 데이터 흐름은 아래와 같다.

Manufacturing Event
        │
        ▼
 Assembly Service
(Process Risk Analysis)
        │
        ▼
      Kafka
(factory.manufacturing.analysis)
        │
        ▼
   Main Backend
        │
        ├── AGV Dispatch
        ├── Redis 저장
        └── WebSocket Push
                │
                ▼
 Frontend Process Flow

기존에는 공정 흐름도가 모두 하드코딩되어 있었지만, 이번 작업을 통해 제조 이벤트가 발생하면 실제 AGV가 출발하고 화면에서도 실시간으로 움직이도록 변경하였다.

AGV 출발 조건 개선

처음에는 같은 이벤트인데도 어떤 이벤트는 AGV가 출발하고, 어떤 이벤트는 출발하지 않는 문제가 있었다.

원인을 확인해보니 하나의 Kafka Topic에서

• Process Risk Analysis
• Bottleneck Analysis
• Defect Transfer Analysis

등 여러 종류의 분석 결과가 함께 전달되고 있었다.

AGV 제어는 Process Risk Analysis 결과만 사용하도록 수정하였다.

if (!PROCESS_RISK_ANALYSIS.equals(event.analysisType())) {
    return;
}

그리고 위험 공정으로 판단된 경우에는 AGV를 출발시키지 않도록 구현하였다.

if (event.analysisResult().isAbnormal()) {
    return;
}

이렇게 수정하면서 AGV 출발 조건을 명확하게 분리할 수 있었다.

Duplicate 이벤트 처리

AI 분석 결과는 동일한 eventId가 여러 번 전달될 수 있다.

동일 이벤트가 여러 번 처리되면 AGV도 중복 출발할 수 있기 때문에 Redis를 이용하여 Duplicate 처리를 추가하였다.

redisTemplate.opsForValue().setIfAbsent(
        PREFIX + eventId,
        "1",
        Duration.ofMinutes(1)
);

Redis의 SETNX를 이용하여 동일한 eventId는 최초 한 번만 처리하도록 구현하였다.

AnalysisStatus 기준 통일

이번 작업에서 가장 오래 걸렸던 부분이다.

DB에서는

analysis_status = ABNORMAL

인데 AGV는 정상적으로 출발하는 현상이 발생하였다.

원인을 확인해보니 Assembly Service에서는

• Quality Defect
• Bottleneck
• Equipment Fault
• Sequence Error

등도 모두 ABNORMAL로 처리하고 있었지만,

Main Backend에서는

analysisResult.isAbnormal()

만 기준으로 AGV를 제어하고 있었다.

즉, 서비스마다 ABNORMAL을 판단하는 기준이 달랐다.

최종적으로는 isAbnormal 값만 AnalysisStatus를 ABNORMAL로 변경하도록 수정하여 Main Backend와 동일한 기준을 사용하도록 변경하였다.

WebSocket 기반 실시간 AGV 연동

Frontend도 기존 하드코드를 제거하고 WebSocket(STOMP)을 통해 실시간 데이터를 수신하도록 변경하였다.

Backend에서는

DB
+
Redis

↓

AgvOperationResponse

↓

WebSocket

↓

Frontend

형태로 데이터를 전달한다.

AGV의 위치와 상태는 WebSocket을 통해 실시간으로 갱신된다.

최초 진입 시 상태 복원

WebSocket만 사용할 경우 새로고침하거나 다른 페이지를 이동한 뒤 다시 들어오면 AGV가 하나도 보이지 않는 문제가 있었다.

이를 해결하기 위해

GET /api/main/process-flow

API를 추가하였다.

페이지 진입 시

REST API

↓

현재 AGV 상태 조회

↓

WebSocket 연결

↓

실시간 업데이트

순서로 동작하도록 수정하였다.

덕분에 페이지를 다시 진입해도 현재 운행 중인 AGV 상태를 그대로 복원할 수 있게 되었다.

공정 흐름도 개선

이번 작업을 통해 Process Flow도 실시간 데이터 기반으로 변경하였다.

현재 AGV 상태는

• 🟡 WAITING
• 🔵 MOVING
• 🟢 UNLOADING
• 🟣 RETURNING

총 4가지 상태를 표현한다.

오른쪽 관제 현황에서는

• 🚚 운반중
• 📦 하역중
• ↩️ 복귀중
• ⏸️ 대기중

AGV 수를 실시간으로 집계하도록 구현하였다.

또한 전체 AGV 수는 항상 20대로 유지되도록 수정하였다.

구현 결과

이번 작업을 통해

제조 이벤트 발생

↓

Kafka 전달

↓

Main Backend AGV Dispatch

↓

Redis 상태 저장

↓

WebSocket Push

↓

Frontend 실시간 공정 흐름도 반영

까지 하나의 흐름을 구성하였다.

여러 서비스가 하나의 이벤트를 중심으로 연결되어 동작하는 구조를 직접 구현할 수 있었다.

마무리

이번 작업에서 가장 어려웠던 부분은 기능 구현 자체보다 서비스 간 상태 기준을 맞추는 것이었다.

처음에는 단순히 AGV가 출발하는 조건의 문제라고 생각했지만, 실제 원인은 Assembly Service와 Main Backend가 같은 데이터를 서로 다른 기준으로 해석하고 있었기 때문이었다.

MSA 환경에서는 기능 구현뿐만 아니라 서비스 간 데이터의 의미와 기준을 동일하게 유지하는 것이 중요하다는 점을 다시 한번 확인할 수 있었다.

이번 작업을 통해 Kafka 기반 이벤트 처리, Redis를 이용한 상태 관리, WebSocket을 활용한 실시간 화면 구성까지 하나의 흐름으로 연결해볼 수 있었고, 이벤트 기반 아키텍처를 실제 프로젝트에 적용하는 경험을 할 수 있었다.

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 연동도 함께 진행해볼 예정이다.

오늘은 제조 이벤트와 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 Service

AGV가 도착하면 Main Backend가 새로운 Kafka Topic에 운반 완료 이벤트를 발행하고,

Assembly Service가 이를 수신하여 다음 공정을 READY 상태로 변경하는 방식이다.

장점

• 서비스 간 결합도가 낮다.
• 이벤트 기반 아키텍처를 유지할 수 있다.
• AI 서비스, 통계 서비스 등 다른 서비스에서도 동일 이벤트를 쉽게 활용할 수 있다.
• 향후 기능 확장에 유리하다.

단점

• Topic과 Consumer를 추가로 관리해야 한다.
• 현재 프로젝트 규모에서는 다소 과한 구조가 될 수 있다.

방법 2. API 호출 방식

Main Backend
        ↓
POST /transport/complete
        ↓
Assembly Service

AGV 운반이 완료되면 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를 우선 완성하는 것이 더 중요하다는 점도 다시 한번 정리할 수 있었던 하루였다.

중간발표 피드백

중간발표 이후 멘토링을 통해 발표 내용뿐만 아니라 현재 프로젝트의 구조와 개발 방향에 대해 다시 한번 점검하는 시간을 가졌다. 단순히 기능을 구현하는 것보다 왜 이런 구조를 선택했는지, 데이터가 어떻게 흘러가는지를 명확하게 설명하는 것이 중요하다는 점을 많이 느꼈다.

Kafka는 왜 사용하는가?

가장 많이 나온 이야기 중 하나는 Kafka를 사용하는 이유였다.

그동안은 "무중단 처리" 정도로만 설명했지만, 실제로는 MSA 환경에서 서비스 간 독립성을 유지하기 위해 반드시 필요한 기술이라는 점을 강조해야 했다.

만약 Kafka가 없다면 하나의 제조 이벤트가 발생할 때마다 여러 서비스가 서로 직접 API를 호출해야 한다.

AGV Service
      ↓
Alert Service
      ↓
AI Service
      ↓
Dashboard

이처럼 서비스 간 의존성이 높아지고 아키텍처가 복잡해질 수 있다.

반면 Kafka를 사용하면 하나의 이벤트를 발행하고, 필요한 서비스들이 각각 동일한 이벤트를 독립적으로 소비한다.

Manufacturing Event
        ↓
      Kafka
   ├─ AGV Service
   ├─ AI Service
   ├─ Alert Service
   └─ Dashboard

서비스 간 결합도를 낮출 수 있고, MSA 구조를 유지하기 위한 핵심 요소라는 점을 발표에서 반드시 설명해야 한다는 피드백을 받았다.

데이터 흐름도를 더 명확하게 표현하기

이번 발표에서 가장 많이 수정해야 하는 부분은 데이터 흐름도였다.

기존에는 Kafka와 Consumer Group 위주로 표현했지만, 실제로 중요한 것은

어떤 데이터가 들어와서

어떤 서비스가 처리하고

어떤 결과 데이터를 생성하는가

였다.

예를 들어

제조 이벤트
      ↓
Manufacturing Service
      ↓
AI 분석
      ↓
분석 결과 저장
      ↓
Dashboard 조회

처럼 데이터 → 서비스 → 결과물의 흐름이 한눈에 보이도록 수정하는 것이 좋다는 피드백을 받았다.

Consumer Group 자체는 구현 세부사항이기 때문에 발표에서는 굳이 강조하지 않아도 된다고 하셨다.

AI 기능은 "왜?"를 설명할 수 있어야 한다

최종 발표에서는 단순히

• LightGBM 사용
• SHAP 사용

이라고 설명하는 것이 아니라

왜 해당 모델을 선택했는지를 설명해야 한다.

또한 현재 구현 중인 기능인

• 현장 대응 알림 신뢰성 평가
• 불량 예측 및 전이 분석

에서도 동일한 피드백을 받았다.

특히 알림 신뢰성 평가 공식은 현재 임의로 만든 식을 사용하고 있는데,

공식에 대한 레퍼런스가 있는지 질문이 나왔고,

가능하면 실제 논문이나 산업 사례를 참고하여 근거 있는 계산 방식으로 수정하는 것이 좋다는 의견을 받았다.

실제 산업에서는 단순한 계산식보다는

• 정탐률(True Positive)
• 오탐률(False Positive)
• 관제사의 조치 이력

등을 지속적으로 머신러닝 모델에 학습시켜 AI 신뢰도를 계산한다고 한다.

우리 프로젝트 역시 실제 사례를 참고하여 개선할 필요성을 느꼈다.

기술 스택도 선택 이유를 설명해야 한다

기술 스택 페이지에서도

"무엇을 사용했다"

보다

"왜 사용했는가"

가 중요하다는 피드백을 받았다.

예를 들면

• Kafka → 서비스 간 독립적인 이벤트 처리
• OpenSearch → 대용량 로그 검색 및 분석
• NAT Gateway → Private Subnet에서 외부 AI 서비스와 통신

처럼 기술 선정 이유를 함께 설명하는 것이 발표의 설득력을 높여준다.

반면 Redis는 이번 프로젝트에서는 핵심 기술이라기보다 구현을 위한 보조 기술이므로 비중을 크게 둘 필요는 없다는 의견도 있었다.

실시간 화면은 반드시 WebSocket만이 답은 아니다

제조 페이지와 검사 페이지의 데이터 표시 방식에 대해서도 이야기가 나왔다.

대시보드라고 해서 반드시 모든 화면이 완전한 실시간(WebSocket)일 필요는 없으며,

화면 특성에 따라 일정 주기로 Refresh하는 방식도 충분히 현실적인 선택이라고 한다.

실제 현업에서도 사용자가

• 5초
• 10초
• 30초

등 원하는 새로고침 주기를 설정할 수 있도록 구현하는 경우가 많다고 한다.

따라서

• 정말 실시간이 필요한 데이터
• 일정 주기 조회만으로 충분한 데이터

를 구분해서 설계하는 것이 중요하다.

프로젝트 개요도 선택 이유를 담아야 한다

프로젝트 개요에서는

"왜 자동차 제조를 선택했는가"

정도를 간단하게 설명하는 것이 좋다는 의견도 받았다.

자동차 제조 산업은

• 제조 공정이 매우 복잡함
• 설비 종류가 다양함
• AI 활용 사례가 활발한 분야

또한 관련 기술과 연구 사례도 많아 프로젝트 주제로 적합하다는 점을 함께 설명하면 프로젝트의 설득력이 높아질 것 같다.

앞으로 개선하면 좋을 기능

시간적인 여유가 있다면

현재 Rule을 코드에 하드코딩하는 방식이 아니라,

관제사가 직접 Rule을 생성하고 수정할 수 있도록 관리 화면을 제공하는 방향도 고려해보라는 의견을 받았다.

실제 스마트팩토리 관제 시스템 역시 운영자가 직접 이상 탐지 Rule을 관리하는 경우가 많다고 한다.

일정 관리도 프로젝트의 일부

기술적인 내용 외에도 Redmine 관리 방식에 대한 피드백도 받았다.

현재는 스프린트 경계가 다소 모호했는데,

하나의 스프린트가 종료된 후 -> 배포 및 테스트를 완료하고 -> 다음 스프린트를 시작하는 형태

로 관리하는 것이 애자일 방식에 더 적합하다고 한다.

완료하지 못한 작업도 반드시

• 이번 스프린트에서 끝낼 것인지
• 다음 스프린트로 넘길 것인지

명확하게 관리해야 한다는 점도 다시 확인했다.

앞으로 해야 할 일

멘토링 이후 가장 우선순위가 높은 작업은 다음 두 가지로 정리되었다.

1. 데이터 흐름도를 데이터 → 서비스 → 결과물 중심으로 수정하기 (완료)
2. Redmine 스프린트와 간트 차트를 실제 개발 일정에 맞게 정리하기 (완료)

이번 멘토링을 통해 단순히 기능을 구현하는 것보다 설계 의도와 기술 선택 이유를 설명할 수 있는 프로젝트를 만드는 것이 훨씬 중요하다는 점을 다시 한번 느꼈다.

최종 발표에서는 구현 내용뿐만 아니라 구조와 선택 이유까지 자연스럽게 설명할 수 있도록 계속 보완해 나갈 예정이다.

오늘은 중간발표를 앞두고 발표자료를 정리하고, 현재 구현 내용과 발표 내용이 일치하도록 기능 정의를 수정했다.

또한 PPT 전체 흐름과 발표 대본을 정리하면서 프로젝트의 방향성과 전달하고자 하는 핵심 메시지를 다시 점검하는 시간을 가졌다.

골든서클(Golden Circle) 발표 방식 적용

이번 중간발표는 단순히 기능을 나열하는 방식이 아니라 골든서클 방식으로 발표를 구성하기로 했다.

보통 발표는

무엇을 만들었는가(What)
→ 어떻게 만들었는가(How)

순서로 설명하는 경우가 많다.

하지만 골든서클은

왜 만들었는가(Why)
→ 어떻게 해결했는가(How)
→ 무엇을 만들었는가(What)

순서로 설명한다.

즉,

• 왜 이 프로젝트를 시작했는지
• 어떤 문제를 해결하고 싶었는지
• 어떤 방식으로 접근했는지
• 최종적으로 무엇을 구현했는지

순서로 발표 흐름을 구성하기로 했다.

특히 AIMS 프로젝트에서는

"제조 현장의 데이터는 많지만, 실제로 활용하기 어렵다."

라는 문제의식에서 시작해

"제조 데이터를 통합하고 분석하여 관제 효율을 높이자"

라는 방향으로 설명하기로 했다.

기능 수정

1. 알림 신뢰성 평가 기능 변경

기존 기획

초기에는 AI가 발생시키는 알림에 대해 관제사가 어떻게 반응하는지를 기반으로 AI 신뢰도를 평가하려고 했다.

사용자 행동을

• 무시(IGN)
• 확인 후 미조치(VIEW)

로 구분하고

불신 지수를 계산하여 AI 신뢰도를 평가하는 구조였다.

하지만 현재 시스템에는

• AI 신뢰도 반영 기능
• 모델 자동 개선 기능

이 존재하지 않는다.

즉,

기획서에는 있지만 실제 구현은 되어 있지 않은 상태였다.

변경 후

기능명을

AI 알림 신뢰성 평가

에서

현장 대응형 알림 우선순위

로 변경했다.

현재 실제 구현된 상태값인

• 조치 완료
• 조치 불필요
• 조치 미완료

를 활용하여 알림 우선순위를 계산하는 기능으로 재정의하였다.

현장 대응 감점률

현장 대응 이력을 기반으로 감점률을 계산한다.

현장대응감점률 =
((조치불필요 × 1.0) + (조치미완료 × 0.5))
÷ 전체알림수 × 100

의미는 다음과 같다.

• 조치 불필요 → 실제 필요성이 낮았던 알림
• 조치 미완료 → 대응이 제대로 이루어지지 않은 알림

이 비율이 높을수록 알림의 중요도를 일부 낮추도록 설계했다.

우선순위 점수

최종 우선순위는 RiskScore와 감점률을 결합하여 계산한다.

우선순위점수 =
RiskScore × (1 - 0.5 × 현장대응감점률 / 100)

이를 통해

• 위험도는 높지만 실제로 중요했던 알림
• 현장에서 반복적으로 대응이 필요한 알림

을 상단에 배치할 수 있도록 설계하였다.

변경 목적

• 실제 구현과 기획 내용 일치
• 구현되지 않은 AI 신뢰도 평가 제거
• 현장 대응 데이터를 실제 활용
• 불필요한 알림으로 인한 피로도 감소
• 중요한 알림 누락 방지

향후 계획 페이지 작성

중간발표 이후 일정 관리를 위해

• Redmine
• WBS

를 기반으로 향후 계획 페이지를 작성했다.

주요 내용은 다음과 같다.

구현 예정

• Frontend ↔ Backend 실시간 연동
• Kafka 기반 이벤트 처리 안정화
• AI 분석 결과 연동
• Watchy 기능 개선
• 통합 테스트

최종 발표 전

• 기능 고도화
• UI 개선
• 시연 시나리오 완성
• 최종 발표 자료 작성

을 목표로 진행하기로 했다.

발표 대본 작성

총 24페이지 분량의 중간발표 대본을 작성했다.

발표 흐름은 다음과 같이 구성했다.

프로젝트 개요
→ 팀 구성
→ 수행 절차
→ 주요 기능
→ 기술 스택
→ 수행 경과
→ 향후 계획

각 페이지마다

• 설명 내용
• 다음 슬라이드로 넘어가는 연결 문구

를 함께 작성했다.

프로젝트 개요

프로젝트의 시작 배경을 설명한다.

주요 내용

• Industry 4.0 환경
• 레거시 설비 데이터 문제
• 자동차 제조 산업 선정 이유
• 제조 데이터 통합 필요성
• AI 기반 분석 필요성
• 스마트 관제 플랫폼 구축 목표

주요 기능

현장 대응형 알림 우선순위

• RiskScore 활용
• 현장 대응 감점률 계산
• 위험도 기반 정렬
• 관제 효율 향상

불량 예측 전이 분석

• 제조 데이터 학습
• LightGBM 기반 예측
• SHAP 기반 원인 분석
• 공정별 영향도 분석

Watchy

• 사용자 숙련도별 정보 제공
• AI 매뉴얼 기능
• 단계별 대응 가이드 제공

기술 스택 및 인프라

Backend

• Spring Boot
• JPA
• Redis
• Kafka

Frontend

• Next.js
• TypeScript

AI

• LightGBM
• RandomForest
• ExtraTrees
• Logistic Regression
• SHAP

Infrastructure

• Route53
• ALB
• EKS
• MSK
• RDS
• OpenSearch

수행 경과

현재까지 진행된 내용을 정리했다.

데이터 정제

• Ford 데이터셋
• KAMP 데이터셋
• Bosch 데이터셋

통합 및 정제

이벤트 처리 구조

Scheduler
↓
Kafka
↓
Consumer
↓
Redis
↓
WebSocket
↓
Frontend

실시간 관제 구조 설명

구현 완료 기능

• 메인 대시보드
• 공정 흐름도
• AGV 시뮬레이션
• 이벤트 조회
• 검사 화면
• 실시간 알림

강사님 피드백

모델 성능 지표 노출 주의

현재 모델 성능 수치가 높지 않은 상태에서

정확도 수치를 그대로 강조하면

오히려 약점으로 보일 수 있다는 피드백을 받았다.

개선 방향

현재 성능을 자랑하기보다는

• 왜 해당 모델을 선택했는지
• 어떤 방식으로 개선하고 있는지
• 최종 발표까지 얼마나 향상시킬 계획인지

를 설명하는 것이 더 중요하다.

특히

중간발표 대비 0.1만 향상되어도 충분히 의미 있는 성과

라는 조언을 받았다.

PPT 흐름 개선 필요

현재 PPT를 보면

"그래서 우리가 무엇을 말하고 싶은가?"

가 잘 드러나지 않는다는 피드백을 받았다.

따라서

• Why
• How
• What

흐름이 자연스럽게 이어지도록 다시 정리하기로 했다.

느낀 점

오늘은 기능 구현보다는 발표 준비에 집중한 하루였다.

특히 기존의 "AI 신뢰도 평가" 기능이 실제 구현 내용과 맞지 않는다는 점을 발견하고, 이를 "현장 대응형 알림 우선순위"로 재정의하면서 기획과 구현의 일관성을 맞출 수 있었다.

또한 골든서클 방식으로 발표 흐름을 재정비하면서 단순히 기능을 소개하는 것이 아니라

"왜 이 프로젝트를 만들었는가"

를 먼저 전달하는 것이 중요하다는 점을 다시 느꼈다.

이제 남은 기간 동안은 기능 완성도 향상과 통합 테스트에 집중하여 최종 발표까지 프로젝트를 안정적으로 마무리하는 것이 목표다.

현재 진행 중인 스마트팩토리 관제 시스템(AIMS)은 실제 MES 데이터를 사용하는 것이 아니라 Sample DB에 저장된 제조 이벤트를 기반으로 공정을 시뮬레이션하는 방식으로 구현하고 있다.

초기에는 모든 공정 이벤트를 시간 순서대로 재생하는 구조를 고려했지만, 제조 과정 중 설비 이상이나 품질 문제로 인해 공정이 중단되는 상황을 반영하기 어렵다는 문제가 있었다.

이번 회의에서는 이러한 문제를 해결하기 위한 제조 이벤트 흐름 구조를 정리하였다.

기존 방식의 문제점

기존 구조는 차량 하나에 대해 모든 공정 이벤트가 미리 생성되어 있는 형태였다.

CAR-001

Press
 ↓
Body
 ↓
Paint
 ↓
Assembly

즉, Sample DB에 이미 모든 공정 이벤트가 저장되어 있고 Scheduler가 순서대로 발행하는 방식이다.

하지만 이 구조에서는 다음과 같은 문제가 발생한다.

문제 상황

Press 공정에서 이상 탐지가 발생한 경우

Press (이상 발생)
 ↓
Body
 ↓
Paint
 ↓
Assembly

실제로는 Press 공정에서 생산이 중단되어야 하지만 이미 다음 공정 이벤트가 존재하기 때문에 Body 공정까지 진행되는 모순이 발생할 수 있다.

개선된 제조 이벤트 흐름

이를 해결하기 위해 이벤트 상태 기반 제어 방식을 적용하기로 했다.

핵심 아이디어

모든 공정 이벤트는 원천 DB에 저장되어 있지만 Scheduler는 READY 상태의 이벤트만 Kafka로 발행한다.

Manufacturing Event

READY
 ↓
Kafka 발행
 ↓
분석 수행
 ↓
정상
 ↓
다음 공정 READY

최종 데이터 흐름

차량 하나의 공정 흐름은 다음과 같다.

Press
 ↓
Body
 ↓
Paint
 ↓
Assembly

예를 들어 차량 A가 있다고 가정하면

초기 상태

Scheduler는 READY 상태인 Press만 Kafka로 발행한다.

Press 분석 성공

Press 완료
 ↓
분석 성공
 ↓
Body READY

Press 분석 실패

Press 이상 발생
 ↓
공정 중지
 ↓
Body READY 생성 안함

따라서 문제가 발생한 차량은 다음 공정으로 이동하지 못한다.

팀원 설명용 한 문장 정리

원천DB에는 차량별 4공정 이벤트가 모두 저장되어 있지만, Scheduler는 READY 상태의 row만 Kafka로 발행한다. 처음에는 Press만 READY이고, 각 공정 분석이 정상일 때만 같은 차량의 다음 공정 row를 READY로 열어준다. 따라서 Press에서 이상이 난 차량은 Body row가 READY가 되지 않아 다음 공정으로 넘어가지 않는다.

제조와 검사 프로세스 연결

현재 제조와 검사는 독립적으로 동작하고 있다.

제조
Press
 ↓
Body
 ↓
Paint
 ↓
Assembly

검사
Inspection

하지만 실제 제조 흐름에 가깝게 만들기 위해 제조 완료 이후 검사 프로세스와 연결하는 방향을 검토하였다.

개선 방향

Press
 ↓
Body
 ↓
Paint
 ↓
Assembly
 ↓
Inspection

이를 위해 다음 항목들이 필요하다.

추가 필드

• 공정 시작 시간
• 공정 종료 시간
• 제조 완료 시간
• 검사 시작 시간

특히

Assembly 종료 시각
=
Inspection 시작 가능 시각

으로 사용될 예정이다.

불량 차량 추적

모든 차량이 검사 공정으로 이동하는 것은 아니다.

제조 과정에서

• 품질 불량
• 설비 이상
• 폐기 처리

등이 발생할 수 있기 때문이다.

따라서 차량 추적을 위해 car_master_id를 기준으로 데이터를 관리하기로 하였다.

이를 통해

• 제조 이력 조회
• 검사 결과 조회
• 폐기 차량 추적
• 재작업 차량 추적

등이 가능해진다.

오늘 회의 내용 정리

제조 프로세스

• 제조 데이터 정제 완료 후 검사 페이지와 연동 예정
• 제조와 검사가 현재는 독립적으로 동작하지만 향후 하나의 흐름으로 연결 예정
• 의장 공정 종료 시점을 기준으로 검사 시작 시간 계산
• 공정별 시작 시간과 완료 시간 필드 추가 필요
• 제조 과정에서 폐기된 차량도 검사 시스템으로 전달하여 제조-검사 간 연결성 강화

Kafka 및 데이터 흐름

• 제조 Kafka Topic 구조 수정 진행
• 제조 이벤트 흐름 재정비
• 제조 → AGV 운반 데이터 연결 방식 수정
• 품질 AI Service Kafka 데이터 처리 구조 개선

대시보드

• 메인 페이지 공정 흐름도 Kafka 연동 진행
• 전체 공정 상태 시각화
• 위험/경고 이벤트 조회 기능 구현

앞으로 진행할 작업

제조 파트

• Kafka Topic 구조 수정
• 제조 이벤트 흐름 정비
• 제조 → 검사 데이터 연동
• 공정 완료 시점 계산 로직 추가

메인 대시보드

• 공정 흐름도 Kafka 연동
• 제조 이벤트 기반 AGV 운반 연계

품질 분석

• Kafka 데이터 수신
• 폐기 차량 데이터 처리
• 검사 페이지 데이터 연동

마무리

이번 논의를 통해 단순히 이벤트를 시간 순서대로 재생하는 방식에서 벗어나, 공정 분석 결과에 따라 다음 공정을 열어주는 이벤트 제어 구조를 적용하게 되었다.

이 구조를 사용하면 실제 제조 현장에서 발생할 수 있는 설비 이상, 품질 불량, 생산 중단 등의 상황을 보다 현실적으로 시뮬레이션할 수 있으며, 이후 Kafka 기반 MSA 구조와 검사 프로세스 연동에도 자연스럽게 확장할 수 있을 것으로 기대된다.

오늘은 스마트팩토리 관제 시스템에서 제조 이벤트를 어떤 방식으로 생성하고 전달할 것인지에 대해 팀 내 논의를 진행하였다.

기존에는 프레스, 차체, 도장, 의장 공정별 이벤트를 각각 생성하는 구조를 고려하고 있었지만, 공정 간 데이터 연계와 Kafka 활용 측면에서 비효율적인 부분이 존재하였다.

이에 따라 제조 이벤트를 하나의 생산 단위(Car 기준 이벤트)로 관리하고, Kafka를 통해 공정 흐름에 맞게 순차적으로 처리하는 방향으로 구조를 변경하기로 하였다.

제조 이벤트 처리 흐름 개선

기존 방식

Press Event
Body Event
Paint Event
Assembly Event

공정별로 별도 이벤트를 생성하다 보니 이벤트 간 연관관계를 관리하기 어렵고 데이터 중복도 발생할 수 있었다.

개선 방식

Manufacturing Event
    ↓
PRESS
    ↓
BODY
    ↓
PAINT
    ↓
ASSEMBLY

하나의 제조 이벤트가 Kafka를 통해 전달되며 현재 공정 상태를 갱신하는 방식으로 변경하였다.

이를 통해 생산 중인 차량이 어느 공정까지 진행되었는지 추적할 수 있으며, 공정 이상 발생 시 후속 공정에도 자연스럽게 영향을 반영할 수 있게 된다.

AGV 연동 구조 논의

현재 프로젝트에서는 제조 공정과 AGV 운행을 별도 기능으로 구현하고 있었으나, 실제 제조 환경을 고려하면 AGV 역시 제조 이벤트와 연결되어 동작하는 것이 자연스럽다고 판단하였다.

예시 시나리오

PRESS 공정 완료
        ↓
Kafka Event 발생
        ↓
AGV 출발
        ↓
BODY 공정으로 운반
        ↓
BODY 공정 시작

이 구조를 적용하면 공정 완료 이벤트를 기준으로 AGV가 움직이게 되며 실제 생산 흐름과 유사한 시뮬레이션이 가능해진다.

또한 특정 공정에서 설비 이상이 발생할 경우

설비 이상 발생
        ↓
공정 중지
        ↓
AGV 대기
        ↓
후속 공정 지연

과 같은 연쇄 효과를 표현할 수 있다.

제조 공정과 검사 공정의 연결성 검토

현재 제조 공정과 검사 공정은 각각 독립적으로 구현되고 있다.

하지만 강사님 피드백을 통해 최종 발표에서는 기능 단위 설명보다 사용자 관점의 흐름으로 설명하는 것이 중요하다는 점을 확인하였다.

기존 설명 방식

제조 시스템
품질 검사 시스템
AI 분석 시스템

개별 기능 설명

개선 방향

생산
 ↓
이상 탐지
 ↓
품질 검사
 ↓
AI 분석
 ↓
알림 및 대응

사용자가 경험하는 하나의 업무 흐름으로 설명

향후 발표 자료에서도 각 기능을 독립적인 모듈로 설명하기보다는 하나의 제조 시나리오 안에서 연결되는 구조로 정리할 예정이다.

AI 활용 방식 재검토

현재 제조 공정에서는 Rule 기반 이상 탐지와 AI 분석 기능이 함께 사용되고 있다.

강사님 피드백에 따르면 이상 탐지와 같이 명확한 기준이 존재하는 문제는 LLM보다는 ML 기반 모델이 적합할 수 있다.

따라서 최종 발표에서는

• 제조 공정 이상 탐지 → Rule + ML 기반
• AI 매뉴얼 및 사용자 지원 → LLM 활용

이라는 역할 분리를 명확히 설명할 계획이다.

또한 향후에는 RAG 구조를 적용하여 제조 도메인 지식과 운영 데이터를 함께 활용하는 방향도 검토하기로 하였다.

향후 개발 방향

다음 주부터는 아키텍처 설계 중심의 논의보다 실제 구현 비중을 높일 예정이다.

우선순위는 다음과 같다.

1. Kafka Producer / Consumer 연동 완료
2. 제조 이벤트 → AGV 연동 구현
3. 공정 흐름도 실시간 반영
4. WebSocket 기반 실시간 알림 구현
5. AI 매뉴얼 기능 구체화
6. 전체 시스템 아키텍처 다이어그램 완성

현재까지는 구조 설계 단계가 대부분 완료되었으며, 앞으로는 실제 기능 구현과 서비스 통합에 집중할 예정이다.

느낀 점

오늘 회의를 통해 단순히 Kafka를 사용하는 것보다 "왜 Kafka가 필요한가"를 다시 고민해볼 수 있었다.

특히 제조 이벤트, AGV, 알림, AI 분석을 하나의 이벤트 흐름으로 연결하면 각 기능이 독립적으로 동작하면서도 동일한 데이터를 공유할 수 있다는 점이 인상적이었다.

최종 목표는 단순한 기능 시연이 아니라 실제 스마트팩토리 관제 시스템처럼 생산 → 물류 → 품질 → 분석 → 대응이 하나의 흐름으로 이어지는 구조를 구현하는 것이다.

오늘은 제조 데이터 처리 구조와 Kafka 도입 범위에 대해 팀원들과 구체적으로 논의했다.

현재 프로젝트는 실제 MES 데이터를 수집하는 구조가 아니라, AI 서비스에서 생성한 Sample 데이터를 기반으로 제조 시뮬레이션을 수행하고 있다.

현재 데이터 흐름 구조

현재 데이터 흐름은 다음과 같이 구성되어 있다.

AI-Service
    ↓
Sample DB
    ↓
Backend
    ↓
분석 수행
    ↓
Main DB 저장
    ↓
Frontend 조회

AI-Service가 제조 이벤트 데이터를 생성하고 Sample DB에 저장한다.

Backend는 Sample DB 데이터를 읽어 이상 탐지 및 집계 분석을 수행한 뒤 Main DB에 저장한다.

Frontend는 Main DB를 조회하여 대시보드에 데이터를 표시한다.

왜 Main DB에 저장할까?

단순히 실시간 데이터만 보여준다면 Backend에서 분석 후 바로 Frontend로 전달할 수도 있다.

Sample DB
    ↓
Backend 분석
    ↓
Frontend

하지만 이렇게 되면 과거 데이터 조회가 불가능하다.

관제 시스템에서는 다음과 같은 기능이 필요하다.

과거 이상 이력 조회
위험도 추이 분석
공정별 통계 확인
설비 가동률 히스토리 확인

따라서 분석 결과를 Main DB에 저장하는 구조를 유지하기로 했다.

AI-Service와 Backend의 역할 분리

초기에는 데이터 분석 기능을 AI-Service로 이동하는 방안도 검토했다.

하지만 현재 분석 로직은 대부분 규칙 기반 계산 수준이기 때문에 Backend에서 처리하는 것이 더 효율적이라고 판단했다.

최종 역할은 다음과 같이 정리되었다.

Backend

생산 데이터 집계
설비 가동률 계산
이상 여부 판정
분석 결과 저장

AI-Service

Sample 제조 데이터 생성
공정 불량 분석
병목 현상 분석

Assembly Service

규칙 기반 이상 탐지

Kafka를 어디에 적용할 것인가?

현재 가장 많이 논의한 부분은 Kafka를 어느 구간에 사용할지였다.

Kafka를 사용하는 목적은 다음과 같다.

서비스 간 결합도 감소
비동기 처리
이벤트 기반 구조
서비스 확장성 확보

현재 고려 중인 구조는 다음과 같다.

Sample DB
    ↓
Scheduler
    ↓
Kafka
    ├── Manufacturing Service
    ├── Alert Service
    ├── Equipment Service
    ├── Dashboard Service
    └── AI Service

Scheduler가 Producer 역할을 수행하고,

각 서비스가 Consumer가 되어 동일 이벤트를 독립적으로 처리하는 구조이다.

Kafka Topic 설계

제조 서비스에서 사용할 Topic은 다음과 같이 정의하였다.

factory.manufacturing.raw         제조 원천 이벤트
factory.manufacturing.analysis    분석 결과
factory.manufacturing.alert        위험 이벤트
factory.manufacturing.equipment    설비 상태

현재는 각 Topic당 Partition 2개를 고려하고 있다.

Kafka Partition에 대한 이해

회의 중 가장 많이 헷갈렸던 부분은

"브로커가 2대면 토픽도 반으로 나뉘는가?"였다.

예를 들어

Broker 1
Broker 2

가 존재하고

Topic 10개
Partition 1개

라면

토픽이 5개씩 나뉘는 것이 아니다.

실제로는

Topic
 └─ Partition
      ↓
 Broker 배치

구조가 된다.

즉,

Topic
  ↓
Partition
  ↓
Broker

순서로 생각해야 한다.

토픽은 논리적인 이름일 뿐이고 실제 데이터 저장 단위는 Partition이다.

Kafka는 Partition 리더를 여러 브로커에 분산 배치하여 부하를 분산한다.

제조 분석 결과 테이블 구조 정리

분석 결과는 공통 테이블과 공정별 상세 테이블로 분리하기로 했다.

공통 분석 결과

manufacturing_analysis_result

저장 정보

이벤트 ID
차량 ID
설비 ID
공정 코드
이상 여부
위험도 점수
심각도
분석 메시지

공정별 상세 결과

Press

press_analysis_result

• 사이클 타임
• 지연 시간
• 생산 카운트 증가 여부

Body

body_analysis_result

• 진동 분석
• 주파수 분석
• 로봇 상태

Paint

paint_analysis_result

• 도장 두께
• 표면 품질
• 비전 분석 결과

Assembly

assembly_analysis_result

• 작업 순서 오류
• 누락 부품
• 체결 오류

설비 가동률 계산 방식

설비 상태 이력을 저장하는 테이블도 추가하였다.

equipment_status_history

공정별 가동률은 다음과 같이 계산한다.

가동률 = 현재 RUNNING 설비 수 / 전체 설비 수 × 100

이를 통해 대시보드에서 실시간 설비 가동 현황을 시각화할 수 있다.

강사님 피드백

오늘 받은 주요 피드백은 다음과 같다.

1. Kafka는 로컬에서 먼저 검증

MSK를 바로 구축하기보다

Docker Kafka
→ 기능 검증
→ AWS MSK

순서로 진행하는 것이 좋다.

2. 서비스 간 데이터 흐름 명확화

각 서비스가 어떤 데이터를 생산하고 소비하는지

팀원 전체가 동일하게 이해할 수 있도록 데이터 흐름도를 정리할 필요가 있다.

3. 관제 시스템만의 강점 강조

발표 시

로그를 직접 분석해야 하는 기존 방식 VS 한 화면에서 전체 공정을 파악할 수 있는 관제 시스템

이라는 차별점을 강조하는 것이 좋다는 피드백을 받았다.

마무리

오늘은 Kafka 도입 범위와 제조 데이터 분석 구조를 상당히 구체화할 수 있었다.

특히 Kafka Topic, Consumer Group, Partition 구조를 실제 서비스 관점에서 정리하면서 단순히 "Kafka를 사용한다" 수준이 아니라 어떤 데이터를 어디서 발행하고 누가 소비할 것인지까지 정의할 수 있었다.

다음 단계에서는 Docker 기반 Kafka 환경을 먼저 구축하고, Scheduler → Kafka → Consumer 구조를 실제로 연결해보면서 이벤트 흐름을 검증할 예정이다.

현재 진행 중인 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까지 전달되는 흐름을 구현할 예정이다.

📖 오늘 배운 내용 정리

오늘은 프로젝트 멘토링과 함께 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-flow

Task 번호를 기준으로 브랜치를 생성하고 작업 완료 후 dev로 Merge한다.

최종적으로 안정화된 dev를 main으로 배포한다.

Kafka를 왜 사용하는가?

기존에는 Kafka를 단순히 "실시간 처리용" 정도로 생각하고 있었는데 실제 핵심은 서비스 간의 완전한 분리(Decoupling)였다.

첫 번째 관점

MSA 환경에서 서비스 간 통신 담당

Scheduler
    ↓
Kafka
    ↓
AGV Service

Alert Service

AI Service

Producer는 메시지만 발행한다.

Consumer는 필요한 메시지만 구독한다.

서로 직접 호출하지 않기 때문에 서비스 간 의존성이 크게 줄어든다.

두 번째 관점

서비스 간 성능 차이 해결

예를 들어

* 데이터 수집 서비스
* AI 분석 서비스
* 알림 서비스

가 있다고 가정하면

AI 분석이 느려도 수집 서비스는 계속 데이터를 Kafka에 적재할 수 있다.

즉 서비스마다 독립적으로 Scale Out이 가능해진다.

Kafka 핵심 개념

Topic

메시지를 분류하는 공간

예시

manufacturing-event
agv-event
alert-event

Partition

병렬 처리를 위한 단위

Partition 수가 많을수록 동시에 처리 가능

Consumer와 연결되어 처리량을 조절한다.

Offset

Consumer가 어디까지 읽었는지 저장하는 값

Elasticsearch를 왜 사용하는가?

Elasticsearch는 단순 저장소가 아니라 검색 엔진이다.

사용하는 이유

복잡한 검색

DB에서는 Full Scan이 발생할 수 있는 조건들을 빠르게 처리할 수 있다.

예시

• 특정 기간
• 특정 공정
• 특정 심각도
• 특정 키워드

등을 동시에 검색

대용량 로그 분석

보안관제에서는 수백만 건의 로그가 발생한다.

Elasticsearch는 데이터를 분산 저장하여 빠르게 검색할 수 있다.

시계열 데이터 분석

• 이벤트 발생 추이
• 공정별 장애 추이
• 월별 통계

등을 분석하기에 적합하다.

Elasticsearch 구조

Cluster
 └─ Node
      └─ Index
            └─ Shard
                  └─ Segment

Master 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 모두 단순히 최신 기술이라서 사용하는 것이 아니라 실제 운영 환경에서 발생하는 문제를 해결하기 위해 존재한다는 점을 이해할 수 있었다.

앞으로도 "이 기술을 왜 사용하는가?"를 먼저 고민하고 프로젝트에 적용해야겠다고 느꼈다.

오늘의 목표

오늘은 프론트엔드와 백엔드 기능 연동 상태를 점검하고, 현재까지 구현한 기능들을 통합하는 작업을 진행했다. 또 프로젝트 진행 상황을 좀 더 체계적으로 관리하기 위한 일정 관리 방식과 성과 측정 방법에 대한 피드백도 받았다.

오전 회의

프론트엔드 · 백엔드 연동 점검

오후 3시에 예정된 프론트엔드와 백엔드 연동 테스트를 위해 각 기능의 구현 상태를 확인했다.

현재 로그인과 회원가입 기능은 구현이 완료된 상태이며, 인증 방식은 HTTPOnly Cookie 기반으로 적용하기로 결정했다.

이를 통해 브라우저에서 JavaScript로 직접 접근할 수 없는 방식으로 인증 정보를 관리하여 보안성을 높일 수 있도록 구성할 예정이다.

산출물 제출 준비

산출물 제출을 대비해 현재까지 작성된 문서와 구현 현황을 다시 한번 점검했다.

### 오후 회의

GitHub 운영 방식 정리

각자 구현한 기능에 대해 Pull Request를 작성하고 코드 리뷰를 진행했다.

프론트엔드와 백엔드 기능은 모두 main 브랜치로 Merge를 완료했으며, 앞으로는 매주 금요일마다 구현한 기능들을 통합하여 Merge하기로 팀 내 규칙을 정했다.

이렇게 하면 코드 품질을 유지하면서 충돌을 최소화할 수 있을 것으로 기대된다.

강사님 피드백

프로젝트 관리의 중요성

현재 프로젝트는 다음 항목들이 완료된 상태다.

• 시스템 설계 완료
• 기능 우선순위 선정 완료
• 프로젝트 문서 작업 완료

다만 앞으로는 단순히 기능 구현에만 집중하는 것이 아니라 프로젝트 진행 상황을 수치화하여 관리할 필요가 있다는 피드백을 받았다.

Redmine 기반 일정 관리

프로젝트 진행 현황을 보다 명확하게 파악하기 위해 Redmine 운영 기준을 정립하기로 했다.

관리 항목 예시는 다음과 같다.

Backend

• 전체 API 개수
• 구현 완료 API 수
• 진행 중 API 수
• 테스트 완료 여부
• 기능별 개발 진척도

Frontend

• 전체 페이지 수
• 구현 완료 페이지 수
• 대시보드 개발 진행률
• UI/UX 개선 항목

AI

• 모델 선정 근거
• 데이터셋 규모
• 테스트 케이스 수
• 정확도(Accuracy)
• 오탐률(False Positive Rate)

각 분야별 진행 상황을 수치로 관리하면 현재 프로젝트 상태를 보다 객관적으로 파악할 수 있을 것 같다.

주간 성과 관리 방안

강사님께서는 프로젝트 성공 여부를 판단하기 위해서는 주간 단위의 목표 관리가 중요하다고 강조하셨다.

이에 따라 다음과 같은 프로세스를 적용하기로 했다.

1. 주 초 목표 수립
2. Redmine 일정 등록
3. 주간 진행 상황 기록
4. 금요일 성과 취합
5. 목표 대비 달성률 측정
6. 팀 단위 회고 진행

앞으로는 단순히 무엇을 했는지가 아니라 얼마나 달성했는지를 꾸준히 관리할 예정이다.

느낀 점

오늘은 기능 개발 자체보다 프로젝트를 어떻게 관리할 것인지에 대해 많이 고민한 하루였다.

그동안은 기능 구현에 집중했다면 이제는 프로젝트 전체 진행 상황을 수치화하고 관리하는 체계를 만드는 것도 중요하다는 것을 느꼈다.

특히 Backend, Frontend, AI 분야별로 완료율과 달성도를 기록하면 현재 위치와 앞으로 해야 할 작업을 더 명확하게 파악할 수 있을 것 같다.

남은 기간 동안에는 기능 구현뿐 아니라 일정 관리와 주간 회고 체계도 함께 정착시켜 프로젝트 완성도를 높여나갈 계획이다.

오늘 한 일

오늘은 현재 진행 중인 스마트팩토리 관제 프로젝트의 프론트엔드, 백엔드, 인프라 구조를 점검하고 MSA 환경에서의 인증 처리 방식과 데이터 구조에 대해 논의했다. 또한 멘토링을 앞두고 현재까지 진행된 내용과 MVP 방향성을 정리하는 시간을 가졌다.

오전 회의

각자 담당 업무를 중심으로 개발을 진행했다.

팀원별 진행 사항

• 혜인

  • 도장 공정 이상 탐지 기능 구현
  • Entity 설계 및 데이터 구조 작업

• 서경

  • EKS 환경 구축 진행
  • 완료 후 Route53, ACM, ALB 연동 예정

• 미정

  • 병목 탐지 모델링 작업

• 종찬

  • 메인 대시보드 AGV 실시간 흐름도 구현

• 건

  • 검증 페이지 백엔드 개발
  • DTO, Entity, Controller, Repository, Service 구성

• 준호

  • 메인 페이지 인프라 API 구현

오후 회의

멘토링 준비

멘토님께 현재 프로젝트 진행 상황을 설명하기 위해 아래 내용을 정리하기로 했다.

• 인프라 구성

• 프론트 프로토타입

• MVP 기능

• DB 구조

  • Sample DB
  • Main DB

• 팀원별 역할 및 업무 분담

강사님 피드백 이후 검토 사항

1. Spring Boot 서비스 포트 분리

MSA 구조를 고려하여 서비스별 포트를 분리하기로 했다.

• Main Service : 8081
• Manufacturing Service : 8082
• Quality Service : 8083

서비스를 독립적으로 운영하고 추후 EKS 환경으로 배포하기 위한 준비 과정이다.

2. 인증 처리 방식 검토

JWT 인증을 어떤 위치에서 처리할 것인지 논의했다.

방안 1

Frontend Proxy → Main Service

• 프론트에서 Main Service로 요청
• Main Service가 JWT 검증 수행
• 내부 서비스 호출

장점

• 인증 로직 중앙 집중화

단점

• Main Service 의존도 증가

방안 2

Frontend Proxy → 각 서비스

• 서비스별 JWT 직접 검증
• MSA 표준 구조에 가까움

장점

• 서비스 독립성 확보

단점

• JWT 검증 로직 중복 가능

향후 Security 공통 모듈을 만들어 JWT 검증 로직을 재사용하는 방향도 검토하기로 했다.

3. Sample DB 데이터 기준일 검토

시뮬레이션용 데이터의 날짜를 특정 시점(예: 6월 5일)로 고정하여 사용할지 논의했다.

현재 프로젝트는 실제 제조 데이터를 사용하는 것이 아니라 샘플 데이터를 기반으로 AGV 이동 및 공정 흐름을 시뮬레이션해야 하기 때문에 데이터 기준 시점 관리가 중요하다.

강사님 피드백 정리

Ingress 기반 인증 처리

운영 환경에서는 Front Proxy 대신 Ingress를 활용하여 서비스 라우팅을 수행하게 된다.

로컬 환경

Frontend
   ↓
Proxy
   ↓
Backend Services

운영(EKS) 환경

Frontend
   ↓
Ingress
   ↓
Backend Services

따라서 운영 환경에서는 각 서비스가 JWT 검증을 수행하는 구조가 자연스러운지 검토가 필요하다.

AI 모델링 방향 검토

현재 추진 중인 불량 전이 예측 기능에 대해 추가 검토가 필요하다는 피드백을 받았다.

검토 항목

• 어떤 데이터셋을 사용할 것인가
• 불량 여부를 판단하는 컬럼은 무엇인가
• Station 정보 활용 가능 여부
• 공정 단계별 전이 분석 가능 여부
• 설비 정보 활용 가능 여부

단순히 AI 모델을 만드는 것이 아니라 실제 불량 판단 근거가 되는 데이터를 명확하게 정의해야 한다는 점을 다시 확인했다.

MSA 백엔드 아키텍처 검토

이번 피드백에서 가장 많이 논의된 내용 중 하나였다.

주요 내용

• 서비스별 포트 분리
• Eureka 역할 구분
• JWT 인증 처리 위치 결정
• Security 공통 모듈 적용 검토
• 로컬 Proxy 구성
• EKS Ingress 구성

특히 Eureka는 서비스 등록과 발견만 담당하며 인증 기능은 제공하지 않는다는 점을 다시 확인했다.

관제 서비스 아이디어 검토

멘토님께 현재 관제 서비스 MVP 방향에 대한 피드백을 요청하기로 했다.

현재 검토 중인 기능

• 병목 탐지
• 불량 전이 분석
• AGV 실시간 관제
• 알림 신뢰도 분석
• 숙련자 대응 패턴 학습

추가로 확장 가능한 MVP 기능이 있는지 의견을 받아볼 예정이다.

인프라 관련 내용

멘토님께서 제공해주신 자료를 기반으로 관제 서비스를 구축할 수 있다는 의견을 받았다.

다만 실제 적용 시에는

• ECR 설정
• EFS 마운트
• 스토리지 경로 설정

등의 작업이 필요하며 이 부분은 추가 학습이 필요해 보인다.

느낀 점

오늘은 단순히 기능 개발만 진행한 것이 아니라 실제 운영 환경을 고려한 아키텍처 설계와 인증 구조에 대해 깊게 고민해볼 수 있었다.

특히 MSA 환경에서 인증을 어느 계층에서 처리할 것인지, 그리고 로컬 개발 환경과 EKS 운영 환경의 차이를 어떻게 설계에 반영할 것인지가 중요한 고민거리였다.

또한 AI 기능 역시 단순히 모델을 적용하는 것이 아니라 실제 데이터의 의미와 활용 목적을 명확하게 정의해야 한다는 점을 다시 느꼈다.

앞으로는 멘토링을 통해 현재 MVP 방향성을 검증받고, 인프라와 백엔드 구조를 조금 더 구체화해 나갈 예정이다.

오늘의 목표

오늘은 스마트팩토리 관제 시스템 구현을 위한 데이터 저장 구조와 실시간 데이터 처리 방식에 대해 논의하고, 데이터베이스 구축 및 프론트/백엔드 개발을 진행했다.

오전 작업

데이터 저장 구조 논의

현재 프로젝트는 실제 제조 데이터를 사용하는 것이 아니라 샘플 데이터를 기반으로 공정 흐름과 AGV 이동을 시뮬레이션해야 한다.

이를 위해 샘플 데이터베이스(Sample DB)와 운영 데이터베이스(Main DB)를 분리하여 운영하는 방안을 논의했다.

검토한 방식

1. 특정 기간 데이터를 저장하고 시스템 시간을 조작하는 방식

• Sample DB에 6/1 ~ 6/7 데이터를 저장
• 시스템이 현재 시간을 기준으로 해당 데이터를 조회

장점

• 실제 데이터 흐름처럼 구현 가능

단점

• 시간 계산 로직이 복잡해짐

2. 스케줄러를 통해 Sample DB에 지속적으로 데이터 적재

• 일정 주기로 Sample DB에 데이터를 삽입
• Main DB가 실시간으로 조회

장점

• 실제 운영 환경과 가장 유사

단점

• 데이터 생성 로직 추가 필요

3. Sample DB에 데이터를 미리 적재 후 순차 조회

• 날짜와 무관하게 첫 번째 데이터부터 순서대로 사용

장점

• 구현이 가장 단순

단점

• 실제 운영 데이터와 차이가 존재

4. 예약 작업을 이용한 실시간 데이터 생성

• INSERT 명령을 예약 실행
• 실제 데이터가 들어오는 것처럼 구성

장점

• 실시간 환경 재현 가능

단점

• 관리 포인트 증가

추가 진행 사항

오전 시간에는 다음 작업도 함께 진행했다.

• 데이터베이스 테이블 생성
• 데이터셋 정제 작업
• 공정 흐름도 구조 정리
• 병목 탐지 모델링 구현
• Redis 생성
• 샘플 데이터 정제

오후 작업

Redis 연결 환경 정리

현재 Redis는 AWS ElastiCache 환경에서 운영된다.

개발 초기에는 Bastion 서버를 이용한 SSH 터널링 방식으로 접속할 수 있도록 구성했다.

로컬 개발 환경

REDIS_HOST=127.0.0.1
REDIS_PORT=16379

EKS 배포 환경

REDIS_HOST=Redis Primary Endpoint
REDIS_PORT=6379

Redis SSH 터널 연결

ssh -i "C:\Users\user\Downloads\*.pem" \
-L 16379:REDIS_PRIMARY_ENDPOINT:6379 \
ubuntu@BASTION_ELASTIC_IP

해당 터널이 활성화되어 있는 동안에는 로컬 PC에서 Redis를 다음과 같이 사용할 수 있다.

127.0.0.1:16379

DB와 Redis 터널 통합

매번 DB 터널과 Redis 터널을 따로 여는 것이 번거롭기 때문에 SSH Config를 이용하여 하나의 명령으로 사용할 수 있도록 구성했다.

Host aims-db
    HostName BASTION_ELASTIC_IP
    Port 22
    User ubuntu
    IdentityFile C:/Users/user/Downloads/*.pem

    LocalForward 13306 RDS_ENDPOINT_ADDRESS:3306
    LocalForward 16379 REDIS_PRIMARY_ENDPOINT:6379

    ServerAliveInterval 60
    ExitOnForwardFailure yes

이후에는 다음 명령만 실행하면 된다.

ssh aims-db

데이터셋 적재

오후에는 Sample DB와 Main DB에 데이터셋을 적재했다.

진행 과정에서 발견한 문제는 다음과 같았다.

• 데이터셋 구조와 설계한 테이블 구조가 일치하지 않음
• 날짜 저장 정책 변경 필요
• 일부 컬럼 정규화 필요

이를 반영하여 데이터셋을 수정한 뒤 최종적으로 데이터를 저장했다.

병목 탐지 모델링

공정별 생산 흐름을 기반으로 병목 현상을 탐지하기 위한 모델링 작업을 추가로 진행했다.

향후에는 다음과 같은 기능으로 확장할 예정이다.

• 공정별 대기시간 계산
• 공정별 처리량 비교
• AGV 이동 지연 분석
• 병목 공정 자동 탐지

백엔드 개발

백엔드에서는 기본 개발 환경을 구축했다.

구현 항목은 다음과 같다.

• Entity
• DTO
• Repository
• Controller
• Service 구조 설계

향후 API 개발을 위한 기본 틀을 구성했다.

인프라 설계

AWS 환경에서 EKS Cluster 구축을 위한 설계를 진행했다.

현재 검토 중인 구성 요소는 다음과 같다.

• EKS
• ALB
• Redis (ElastiCache)
• RDS
• GitHub Actions
• ArgoCD

프론트엔드 수정

샘플 데이터 및 공정 구조 변경 사항을 반영하기 위해 메인 페이지를 수정했다.

주요 변경 사항은 다음과 같다.

• 공정 흐름도 재설계
• AGV 이동 경로 수정
• 공정 간 이동 라인 추가
• AGV 수량 증가에 따른 UI 조정

실제 제조 라인처럼 AGV가 공정 사이를 왕복 이동하는 형태로 변경하는 작업을 진행했다.

강사님 피드백

EC2를 터널 전용으로 사용하는 문제

현재 Bastion 서버를 통해 DB 및 Redis 터널을 연결하고 있으나, 강사님께서는 단순 통로 역할만 수행하는 EC2는 자원 낭비가 발생할 수 있다고 조언해 주셨다.

개선 방향

• Redmine 서버를 활용한 접속 구조 검토
• VPC를 Redmine용과 서비스용으로 분리
• Bastion 서버는 t3.micro 최소 사양 사용

GitHub Actions 운영 방식

GitHub Actions는 브랜치별로 자동 실행되도록 구성하는 것이 좋다는 의견을 받았다.

권장 구조

• 테스트용 Workflow
• 실제 배포용 Workflow

YAML 파일을 분리하여 운영 환경과 테스트 환경을 구분하는 방향으로 설계할 예정이다.

협업 프로세스

추가로 다음과 같은 팀 운영 방안도 제안받았다.

• Daily Meeting 진행
• Git Push 주기 정하기
• 코드 리뷰 문화 정착
• 공통 개발 규칙 수립

프로젝트 규모가 커질수록 개발 생산성보다 협업 프로세스가 더욱 중요해질 수 있기 때문에 팀 차원의 규칙을 정하는 것이 필요하다는 의견이었다.

마무리

오늘은 단순히 기능 개발만 진행한 것이 아니라 앞으로의 실시간 데이터 처리 구조와 운영 방식을 결정하는 중요한 논의를 진행한 하루였다.

특히 Sample DB와 Main DB를 분리하여 운영하는 구조, Redis 연결 방식, 병목 탐지 모델링 등은 향후 스마트팩토리 관제 시스템의 핵심 기반이 될 것으로 보인다.

내일부터는 API 개발과 실시간 AGV 시뮬레이터 구현을 본격적으로 진행할 예정이다.

📌 오늘 진행 내용

오늘은 프로젝트의 실제 개발을 시작하기 위한 구조 설계와 개발 환경 정리를 진행하였다.

그동안 프로젝트 기획과 요구사항 정의에 집중했다면, 이제는 실제 구현 단계로 넘어가기 위해 서비스 구조와 저장소 전략, 데이터베이스 접근 방식 등을 구체화하는 시간을 가졌다.

🏗 서비스 구조 확정

AIMS는 기능별 독립 서비스를 기반으로 한 구조로 개발을 진행하기로 결정하였다.

Backend Repository

backend
├─ assembly-service
├─ quality-service
└─ ai-service

각 서비스는 담당 기능을 독립적으로 개발할 수 있도록 분리하며, 향후 서비스 확장과 유지보수성을 고려한 구조를 목표로 한다.

주요 역할

Assembly Service

자동차 제조 공정 및 생산 라인 관련 데이터 관리

Quality Service

품질 검사 및 불량 데이터 관리

AI Service

AI 분석 기능 담당

• 병목 현상 분석
• 불량 전이 분석
• 원인 분석
• LLM 기반 대응 지원

🤖 AI Service 구조 설계

AI Service는 FastAPI 기반으로 개발을 진행하며 아래와 같은 계층 구조를 사용한다.

Core Layer

core/

공통 설정, 로깅, 예외 처리 담당

Router Layer

routers/

API 엔드포인트 관리

• Health Check
• Orchestrator API
• LLM API
• 분석 API
• 머신러닝 API

Service Layer

service/

비즈니스 로직 처리

• 분석 서비스
• LLM 서비스
• 오케스트레이션 서비스

Machine Learning Layer

ml/

AI 모델 생명주기 관리

• 데이터 로딩
• 전처리
• Feature Engineering
• 학습
• 평가
• 추론
• 모델 버전 관리

프로젝트 초반부터 학습 코드와 서비스 코드를 분리하여 향후 유지보수와 모델 교체가 쉽도록 설계하였다.

🗄 데이터베이스 구조 설계

AIMS는 하나의 RDS 인스턴스 내부에 두 개의 논리 데이터베이스를 운영한다.

RDS
├─ sampledb
└─ maindb

sampledb

원본 데이터 저장

• 외부 데이터셋
• 개발용 샘플 데이터
• 시뮬레이션 데이터

maindb

실제 서비스 데이터 저장

• 분석 결과
• 대시보드 데이터
• 이벤트 데이터
• 운영 데이터

원본 데이터와 서비스 데이터를 분리함으로써 데이터 정합성과 관리 효율성을 확보할 수 있다.

🔐 보안 고려 사항

RDS는 Private Subnet에 배치한다.

외부에서 직접 접근하지 않고 Bastion Host를 통해 SSH 터널링 방식으로 접속하도록 구성한다.

Developer PC
      ↓
Bastion EC2
      ↓
Private RDS

이를 통해 데이터베이스를 외부에 노출하지 않고 안전하게 운영할 수 있다.

또한 다음 사항을 팀 규칙으로 정하였다.

• PEM 키 공개 금지
• DB 비밀번호 공유 금지
• GitHub 업로드 금지
• Notion 공개 문서 업로드 금지

🍪 인증 방식 개선

기존 JWT 전달 방식에서 보안성을 높이기 위해

변경 전

URL 또는 LocalStorage 기반 토큰 관리

변경 후

HTTPOnly Cookie 기반 JWT 관리

방식으로 변경하기로 하였다.

이를 통해

• XSS 공격 위험 감소
• 토큰 노출 방지
• 보안성 향상

효과를 기대할 수 있다.

📦 저장소 구조

프로젝트 저장소는 역할별로 분리하여 운영한다.

Infra Repository

infra

Terraform 코드 및 인프라 관리

Backend Repository

backend

Spring Boot 및 AI 서비스 관리

Frontend Repository

frontend

v0 기반 화면을 React + TypeScript 코드로 이전

🔍 코드 품질 관리

팀 협업 품질 향상을 위해

main
 ↕
dev

브랜치 운영 전략을 사용한다.

모든 기능은 Pull Request를 통해 병합하며

• 코드 리뷰
• 동작 검증
• 충돌 확인

과정을 거친 후 반영하도록 하였다.

🎯 앞으로의 계획

현재까지는 프로젝트 기획과 설계가 중심이었다면 이제는 실제 개발 단계에 진입하게 되었다.

다음 목표는 다음과 같다.

• Spring Boot 서비스 개발
• AI 분석 서비스 구현
• 실시간 데이터 처리 구조 설계
• 대시보드 연동

AIMS 프로젝트가 단순 모니터링 시스템이 아니라 제조 공정 데이터를 통합적으로 분석하고 시각화하는 지능형 관제 시스템으로 발전할 수 있도록 지속적으로 구현해 나갈 예정이다.

📌 오늘 회의 목표

오늘은 스마트팩토리 통합 관제 시스템(AIMS)의 데이터 구조와 API 명세를 구체화하고, 현재 구현 중인 프론트엔드(V0) 수정 사항을 정리하는 시간을 가졌다.

특히 실제 구현 단계에 진입하기 전,

어떤 데이터를 저장할 것인가 어떤 API를 제공할 것인가 사용자가 어떤 방식으로 이벤트를 처리할 것인가

를 중심으로 논의하였다.

1. ERD 구조 구체화

현재 시스템은 크게 샘플 데이터 저장 영역과 관제 시스템 운영 영역(Main DB) 으로 분리하여 설계하고 있다.

샘플 DB

실제 공장 데이터를 대신하여 AI 분석 및 시뮬레이션에 활용되는 데이터이다.

주요 데이터는 다음과 같다.

차량 정보
차량 상태 데이터
운전자 입력 데이터
차량 제어 데이터
차량 동역학 데이터
설비 정보
AGV 운반 상태
로봇팔 진동 데이터
열화상 이미지 데이터
공정별 환경 데이터

이를 통해 실제 자동차 제조 공정과 유사한 데이터를 생성하고 관제 시스템으로 전달할 수 있도록 구성하였다.

Main DB

관제 시스템이 실제로 사용하는 데이터 영역이다.

주요 기능은 다음과 같다.

이벤트 관리

알림 상세 정보
AI 지원 정보
조치 타임라인
대응 매뉴얼
불신 지수

사용자 관리

사용자 정보
사용자 업무 현황

제조 공정 분석

차량 공정 이동 이력
제조 병목 분석 결과
제조 불량 전이 예측 결과

공정별 AI 분석

프레스 이상 정지 탐지
차체 공정 분석
도장 공정 분석
의장 공정 분석

검사 프로세스

검사 프로세스
검사 상태 상세
검사 요약
위험 이력

2. 이벤트 시스템 개선

현재 프로젝트에서 가장 많이 사용되는 기능인 이벤트 관리 영역에 대한 개선 방향을 확정하였다.

이벤트 발생 범위 제한

기존에는 다양한 공정에서 이벤트가 생성될 수 있었지만,

이번 회의에서는 실제 공정 중심 관제를 위해 아래 4개 공정만 이벤트 발생 대상으로 제한하기로 결정하였다.

프레스
차체
도장
의장

반대로 아래 영역에서는 이벤트를 생성하지 않는다.

검사
자재 관리

이를 통해 이벤트의 의미를 더욱 명확하게 만들고 불필요한 알림을 줄일 수 있게 되었다.

이벤트 상태 단순화

기존에는 상태값이 많아 관리가 복잡했다.

이에 따라 상태를 아래 3개로 통일하였다.

ACTION_REQUIRED (조치 필요)
COMPLETED (조치 완료)
NO_ACTION_REQUIRED (조치 불필요)

이를 통해 사용자가 이벤트를 보다 쉽게 관리할 수 있도록 개선하였다.

AI 매뉴얼 동작 방식 변경

기존에는 AI 신뢰성 지수를 기준으로 안내 대상을 선정하였다.

하지만 실제 관제 환경에서는 중요도가 더 중요하다고 판단하여,

앞으로는:

이벤트 우선순위 점수

기반으로 AI 매뉴얼 마스코트가 대응 이벤트를 추천하도록 변경하기로 하였다.

또한 조치 완료 또는 조치 불필요 상태가 된 이벤트는 더 이상 AI가 안내하지 않는다.

3. 프론트엔드(V0) 개선 사항

사용자 경험 개선을 위해 여러 UI 수정 사항을 결정하였다.

팝업 동작 개선

기존 문제점

8초마다 팝업 재생성
깜빡이는 현상 발생
사용자가 닫아도 다시 표시

개선 내용

반복 재알림 제거
팝업 닫기(X)는 삭제가 아닌 숨김 처리
이벤트 데이터는 유지
AI 마스코트 안내는 계속 유지

이벤트 페이지 개선

페이지네이션 추가

페이지당 10건 표시

이벤트 샘플 데이터 확대

프레스
차체
도장
의장

공정 이벤트를 대량 추가

건수 표시 방식 변경

기존: 전체 128건

변경: 현재 10건 / 전체 128건

4. API 명세 초안 작성

기능별 API를 아래와 같이 분류하였다.

Main API

메인 대시보드 조회

담당 업무
설비 상태
AGV 현황
생산 추이
공정 흐름도

Process API

공정 분석 기능

병목 분석
불량 전이 예측
AI 원인 분석
프레스 이상 탐지
차체 공정 분석
도장 공정 분석
의장 공정 분석

Events API

이벤트 관리 기능

이벤트 목록
이벤트 상세
조치 이력
AI 대응 추천
매뉴얼 조회
신뢰성 평가
통계 조회
상태 변경

Inspection API

검사 데이터 저장

검사 결과
공정 진행 현황
위험도 추이

Cars API

샘플 차량 데이터 조회

차량 정보
차량 상태
운전자 입력
제어 데이터
차량 동역학

5. 강사님 피드백

강사님께서는 개발 진행 방식에 대해 다음과 같은 조언을 해주셨다.

스프린트 단위를 2주로 설정할 것
스프린트 목표를 명확하게 정의할 것
매일 진행 상황을 기록할 것
단순 개발뿐 아니라 설계와 문서 작업도 일정으로 관리할 것

향후에는 Redmine을 활용하여 스프린트별 목표와 일일 진행 상황을 체계적으로 관리할 예정이다.

마무리

오늘 회의에서는 단순 기능 논의를 넘어 실제 구현을 위한 데이터 구조와 API 설계를 구체화하였다.

특히 이벤트 시스템의 구조를 단순화하고, AI 매뉴얼의 동작 기준을 현실적인 우선순위 기반으로 변경하면서 프로젝트의 방향성이 더욱 명확해졌다.

다음 단계에서는 확정된 ERD와 API 명세를 기반으로 백엔드 구현과 프론트엔드 연동 작업을 본격적으로 진행할 예정이다.

최근 계속해서 진행중인 자동차 스마트팩토리 통합 관제 플랫폼 프로젝트의 MVP 기능을 구체화하고, 멘토님 및 강사님의 피드백을 받는 시간을 가졌다.

이번 회의의 핵심 주제는 단순히 "무엇을 만들 것인가"가 아니라,

"왜 이 기능이 필요한가?" "기존 MES나 관제 시스템과 다른 것이 무엇인가?" "사용자에게 어떤 가치를 제공하는가?"

에 대한 답을 저번 회의에 이어서 찾는 과정이었다.

MVP 기능에 대한 재검토

화요일에 선정했던 MVP 기능들을 멘토님께 메세지를 보내 공유하고 피드백을 받는 시간을 가졌다.

멘토님께서는 기능 자체보다도

"왜?" 를 계속해서 질문하셨다.

또한 기존 MES와 무엇이 다른가? 에 대한 질문을 받고 우리가 만드는 AIMS가 제공하는 차별점은 무엇인가에 대한 고민을 해보게 되었다.

새롭게 제안된 MVP

회의 중 흥미로운 아이디어가 하나 나왔다.

숙련자 행동 패턴 학습 기능

관제 업무를 하다 보면 특정 장애 상황에서 항상 특정 담당자가 빠르게 대응하는 경우가 있다.

하지만 이러한 대응 노하우는 대부분 문서화되지 않고 개인에게만 축적된다.

만약 해당 담당자가 부재중이라면?

새로운 담당자는 동일한 문제를 해결하는 데 훨씬 많은 시간이 필요할 수 있다.

이를 해결하기 위해 다음과 같은 기능을 제안했다.

기능

숙련된 관제 담당자의 행동 로그 수집
장애 발생 시 어떤 화면을 확인했는지 기록
어떤 조치를 수행했는지 저장
해결까지 걸린 시간 분석
유사 상황 발생 시 대응 가이드 추천

팀끼리 회의를 마치고 해당 기능을 AI 매뉴얼 기능과 연계하여 신규 사용자가 해당 관제 시스템을 사용 시에 숙련자가 직접 했던 조치 기록을 기반으로 어떻게 조치해야 할지 추천하는 방식으로 만들어 보고자 계획을 세웠다.

내일 할 일

아키텍처 정의서 작성
Redmine 일정 정리
WBS 작성
MVP 기능 문서 업데이트
차별화 포인트 구체화

프로젝트가 조금씩 기능 구현 단계에 가까워지고 있다. 이제는 "무엇을 만들 것인가"보다 "왜 만들어야 하는가"를 더 깊게 고민해야 할 시점인 것 같다.

최근 팀 프로젝트 주제로 자동차 스마트팩토리 기반 관제 시스템을 기획하면서, 단순히 “기능이 많은 시스템”이 아니라 실제 제조 현장에서 왜 필요한지 설명할 수 있는 기능이 무엇인지에 대해 많은 고민을 하게 되었다.

특히 중간 발표에서는 구현 자체보다도 어제 얘기한 내용에서의 연장선으로:

• 왜 해당 주제를 선택했는지
• 왜 이 기능이 필요한지
• 기존 시스템과 어떤 차별성이 있는지

를 논리적으로 설명하는 것이 중요하다는 피드백을 받았다.

그 과정에서 저희 팀은 스마트팩토리 환경의 특징을 다시 정리해보게 되었다.

왜 자동차 스마트팩토리였을까?

자동차 제조 공정은 프레스, 차체, 도장, 의장, 검사와 같이 여러 공정이 순차적으로 강하게 연결되어 있는 구조를 가진다.

특히 AGV, 컨베이어, 로봇 설비, PLC, MES 등 다양한 시스템이 동시에 동작하며 실시간 데이터를 지속적으로 생성한다는 특징이 있다.

이러한 구조에서는 하나의 작은 이상 상황이 단순 설비 오류로 끝나는 것이 아니라:

부품 공급 지연
공정 대기
품질 문제
생산량 감소

와 같은 연쇄적인 문제로 이어질 가능성이 높다.

즉 자동차 스마트팩토리는 단순 모니터링이 아니라, 이벤트 간 상관관계를 분석하고 예방 중심으로 대응하는 관제 시스템의 필요성이 매우 높은 환경이라고 판단하였다.

MVP 기능 선정 과정

초기에는 원격 제어, 화재/침수 대응, 확장형 플랫폼 등 다양한 기능들을 후보로 고려하였다.

하지만 실제 구현 가능성, 프로젝트 기간, 그리고 “보안 관제”라는 핵심 방향성을 다시 고민하면서 기능을 재정리하게 되었다.

그 결과 최종적으로 아래 3가지 MVP 기능이 가장 현실적이면서도 프로젝트의 방향성을 잘 보여줄 수 있다고 판단하였다.

1️⃣ 알림 신뢰성 평가 시스템

스마트팩토리 환경에서는 수많은 이벤트와 알람이 동시에 발생한다.

문제는 실제 현장에서는 오경보(False Positive)가 많아질수록 작업자가 알람 자체를 신뢰하지 않게 되는 “경보 피로(Alarm Fatigue)” 문제가 발생한다는 점이다.

즉:

중요한 알림과 불필요한 알림이 구분되지 않으면 결국 실제 위험 상황도 놓칠 수 있게 된다.

이를 해결하기 위해 저희는 “불신 지수(Distrust Score)” 개념을 도입하였다.

작업자의:

무시한 알림
즉시 대응한 알림
반복적으로 발생한 이벤트

등을 기반으로 알림 신뢰도를 계산하고, AI 모델이 임계값과 알림 방식을 동적으로 조정하도록 설계하였다.

예를 들어 불신 지수가 높아질 경우:

임계값 완화
알림 우선순위 조정
알림 방식 변경

등을 통해 실제로 중요한 이벤트만 우선적으로 전달할 수 있도록 구성하였다.

단순히 AI가 알림을 생성하는 것이 아니라, 현장의 반응 데이터를 다시 AI 판단 로직에 반영하는 “피드백 루프 기반 관제 시스템”이라는 점에서 차별화를 두고자 하였다.

2️⃣ 공정 간 불량 전이 예측

자동차 제조 공정은 공정 간 연결성이 매우 강하다.

예를 들어:

• 차체 공정의 용접 품질 문제는
• 도장 공정의 표면 품질 저하로 이어질 수 있고,
• 이후 의장 공정의 조립 불량까지 영향을 줄 수 있다.

하지만 대부분의 제조 현장에서는 “현재 공정”만 관리하는 경우가 많아, 이후 공정에서 발생할 문제를 사전에 예측하기 어렵다.

우리는 이러한 구조에 주목하여 제품별 제조 이력과 공정 데이터를 기반으로:

센서 데이터
처리 시간
품질 검사 결과
공정 이동 정보

간의 관계를 분석하고, 특정 이상 징후가 이후 공정의 품질 문제로 이어질 가능성을 예측하는 기능을 기획하였다.

이를 통해 단순 불량 탐지가 아니라:

“현재 발생한 이상이 미래 공정에 어떤 영향을 줄 것인가?”

를 분석하는 예방 중심 관제 시스템을 구현하고자 하였다.

3️⃣ AI 기반 운영 매뉴얼

스마트팩토리 환경은:

설비
PLC
센서
AGV
MES
품질 시스템

등 수많은 요소들이 동시에 연결되어 있기 때문에, 초보 작업자나 신규 관제사가 시스템을 이해하기 어렵다는 문제가 존재한다.

특히 실제 현장에서는 여전히 숙련자의 경험과 노하우에 의존하는 경우가 많다.

우리는 이러한 문제를 해결하기 위해 AI 기반 운영 매뉴얼 기능을 기획하였다.

단순히 오류 코드만 출력하는 것이 아니라:

장애 원인 설명
영향받는 공정 분석
우선 점검 요소
대응 가이드
위험도 분석

등을 자연어 형태로 제공하여 초보 사용자도 상황을 빠르게 이해할 수 있도록 구성하였다.

즉: “숙련자 중심 운영 구조”에서 벗어나, 비숙련자도 쉽게 사용할 수 있는 서포터형 관제 시스템을 목표로 하였다.

마무리

이번 MVP 선정 과정에서 가장 중요하게 고민했던 부분은:

“이 기능이 실제 제조 현장에서 왜 필요한가?”

였다.

단순히 기술을 많이 사용하는 것이 아니라:

왜 Kafka를 사용하는지
왜 AI가 필요한지
왜 이벤트 상관관계 분석이 중요한지

를 실제 스마트팩토리 환경과 연결해서 설명할 수 있어야 한다고 생각했다.

아직 구현 전 단계이지만, 프로젝트의 방향성과 문제 정의를 구체적으로 고민하는 과정 자체가 굉장히 중요하다는 것을 느낄 수 있었던 시간이었다.

기술보다 중요한 것은 “왜?”

오늘 오전 회의에서는 단순히 어떤 기술을 사용할지보다, “왜 이 프로젝트를 만들고 어떤 문제를 해결하려 하는가?”에 대한 이야기를 중심으로 논의를 진행했다.

기술보다 중요한 것 = WHY

이번 회의에서 가장 인상 깊었던 말은 다음이었다.

“Redis, Kafka 같은 기술은 결국 도구일 뿐이다.”

그동안은 어떤 기술을 사용할지에 초점이 많이 맞춰져 있었다. Kafka를 붙이고, Redis를 쓰고, OpenSearch를 넣는 구조 자체에 집중했지만, 오늘은 그보다 더 중요한 것이 있다는 피드백을 받았다.

- 왜 Kafka가 필요한가?
- 왜 Redis를 사용하는가?
- 왜 이 관제 시스템이 필요한가?
- 기존 관제 시스템과 무엇이 다른가?

결국 발표에서 중요한 것은 기술 나열이 아니라, 그 기술을 사용하게 된 배경과 목적이라는 점이었다.

프로젝트 발표에서 중요한 “스토리텔링”

이번 회의에서는 발표 방향성에 대한 이야기도 많이 나왔다.

단순히:

1. Kafka 사용
2. Redis 사용
3. OpenSearch 사용
4. AI 예측 적용

처럼 나열하는 방식은 기술 설명으로 끝나버릴 가능성이 크다는 의견이 있었다.

대신 아래와 같은 흐름이 중요하다는 피드백을 받았다.

예시 흐름
공정 이상 발생
AGV 이동 지연 발생
특정 공정 병목 확대
후속 공정까지 영향 전파
관제 시스템이 위험도를 분석
관리자에게 알림 및 대응 가이드 제공

즉, “기술 설명”이 아니라 “어떤 상황에서 어떤 문제를 어떻게 해결하는가”를 보여줘야 한다는 것이다.

기능 중심 vs 서비스 중심

오후 회의에서는 프로젝트 방향성을 두고 팀 내부 논의도 진행했다.

# 기술 중심 접근

장점:

- 다양한 기술 스택을 강조 가능
- 시스템 구조 설명에 강함

단점:

- 발표에서 기술 나열만 하다가 끝날 가능성 존재
- 실제 사용자 관점이 약할 수 있음

# 서비스 중심 접근

장점:

사용자 입장에서 이해하기 쉬움
AI 매뉴얼 같은 차별화 요소 추가 가능

단점:

자칫 주제가 “관제”보다 “서비스 기능” 중심으로 흐를 수 있음

아직 팀 내부적으로 어느 방향에 더 집중할지는 결정하지 못했지만, 우선 ERD를 정의하고 데이터 구조를 먼저 정리한 뒤 다시 논의하기로 했다.

현재 진행 상황

현재는 다음 작업들을 병행 중이다.

- ERDCloud 기반 테이블 설계
- 공용 테이블 정의
- 각 기능별 데이터 구조 정리
- 데이터셋 정규화
- 샘플 데이터 생성

특히 단순 더미 데이터가 아니라, 실제 공정 흐름처럼 보이는 데이터를 만드는 것이 중요하다는 이야기도 나왔다.

오늘 회의를 통해 느낀 점

오늘 회의를 통해 가장 크게 느낀 점은 “좋은 프로젝트는 기술이 아니라 문제 해결 흐름으로 설명된다”는 점이었다.

Kafka, Redis, OpenSearch 같은 기술은 분명 중요하지만, 그보다 중요한 것은:

• "왜" 필요한지
• 어떤 문제를 해결하는지
• 사용자가 어떤 도움을 받는지

를 설명할 수 있어야 한다는 것이다.

앞으로는 단순 구현보다도 “이 시스템이 실제 현장에서 어떻게 사용될 수 있을까?”를 더 많이 고민해보려 한다.

05.29 프로젝트 기획 및 설계 회의

오늘은 본격적인 기능 개발에 들어가기 전, 프로젝트의 전체적인 방향성 + 문서 체계를 정리하는 시간을 가졌다.

현재 진행중인 프로젝트는 AI 기반 자동차 제조 통합 보안 관제 시스템으로 스마트팩토리 환경에서 발생하는 제조 과정에서 수집되는 데이터를 기반으로 이상탐지 및 통합 관제를 수행하는 시스템을 목표로 한다.

📌 프로젝트 진행 방향

이번 회의에서는 먼저 프로젝트의 뼈대를 탄탄하게 잡아보고자 문서들을 우선적으로 정리하고자 하였다.

요구사항 정의서
프로젝트 수행 계획서
클라우드 사용 계획서
인프라 구성도
아키텍처 정의서

기능 구현에 앞서서 먼저 요구사항 명세서부터 명확하게 정의하는 것을 팀 회의를 통해 목표로 두고 진행했다.

📌 레드마인(Redmine) 기반 일정 관리

현재 진행중인 프로젝트는 애자일 (Agile) 방식으로 진행하기로 하였다. 단순히 일정을 적는 것이 아닌 기능 단위로 세부 목표를 나누고 진행 상황을 관리하는 방향으로 진행하기로 하였다.

마일스톤

프로젝트의 큰 흐름을 다음과 같이 분류하고:

기획
중간 발표
최종 발표

이처럼 가장 큰 목적을 기준으로 단계를 나눠놓고 그 안에서 다시 세부 목표를 쪼개는 방식으로 진행한다.

에픽

에픽은 비교적 큰 목표 단위로 약 4주 정도의 중기 목표로 설정한다고 설명해주셨다.

스프린트

주간 단위의 작은 목표이다. 실제로는 스프린트를 중심으로 일정 관리르 진행할 예정으로, 매주 금요일마다 아래 내용을 기준으로 회의를 진행하는 것이 진행하는데 매끄러울 것이라고 생각했다.

현재 기능 유지 여부
방향성 수정 여부
기능 추가/삭제 결정
다음 주 목표 설정

칸반보드를 통해:

담당자
진행 상태
우선순위
일정 관리

까지 함께 관리할 예정이다.

📌 피그마(Figma) 기반 화면 설계

오후에는 피그마를 활용하여 실제 대시보드 화면을 설계하는 시간을 가졌다.

특히 이번 프로젝트는:

실시간 이벤트 관제
AGV 운반 상태
제조 공정 흐름
AI 이상 탐지
이벤트 로그 관리

등을 한눈에 볼 수 있는 UI를 목표로 하고 있다.

해당 이미지는 현재 예상 메인 대시보드 구현 화면이다.