오늘 한 일
오늘은 중간발표를 앞두고 발표자료를 정리하고, 현재 구현 내용과 발표 내용이 일치하도록 기능 정의를 수정했다.
또한 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 신뢰도 평가" 기능이 실제 구현 내용과 맞지 않는다는 점을 발견하고, 이를 "현장 대응형 알림 우선순위"로 재정의하면서 기획과 구현의 일관성을 맞출 수 있었다.
또한 골든서클 방식으로 발표 흐름을 재정비하면서 단순히 기능을 소개하는 것이 아니라
"왜 이 프로젝트를 만들었는가"
를 먼저 전달하는 것이 중요하다는 점을 다시 느꼈다.
이제 남은 기간 동안은 기능 완성도 향상과 통합 테스트에 집중하여 최종 발표까지 프로젝트를 안정적으로 마무리하는 것이 목표다.
