TIL_260212

최종프로젝트 피드백 정리

 

---

박람회 피드백

송 튜터님 (QAQC 1·2기)

1) 모델/기술 설명 방식
• SHAP, XAI 등은 굳이 어렵게 말하지 말고
 → “피처 셀렉션(중요도 낮은 변수 제거)”처럼 업무 언어로 간단히 표현해도 충분.
• ASOF JOIN에서 288초 근거 질문:
 → “도메인에서 제공/확인된 평균 시간차를 기준으로 매칭” 같은 근거 문장은 반드시 준비.2) “군집화” 표현/논리 보완
• 지금 방식은 클러스터링 알고리즘이라기보다 **성능군(고/중/저) 나누고 임계치 다르게 둔 ‘룰 기반 분기’**에 가까움.
• “임계치가 데이터 늘면 바뀐다”는 점 때문에
 → 왜 이 분기/임계 설계가 타당한지(원리/절차/업데이트 방식) 보강 필요.
• 특히 D01/G03/F09 같은 설비군 분류는
 → “도메인적 공통점(라인, 조건, 설비 타입 등) 없이 그냥 끼워맞춘 것처럼 보일 수 있다” 지적.3) 대시보드(가장 강한 피드백)
• 페이지/요소가 너무 많아서 “열심히 한 거 다 때려박은 느낌”.
• 대시보드는 “아무것도 모르는 현장/관리자”가 봐도
 어디부터 보고 → 뭐가 문제고 → 다음 액션이 뭔지가 나와야 함.
• “메인 화면(실시간 모니터링)”을 중심으로 두고,
 부가 정보는 탭/드롭다운 구조로 절반 이하로 압축 추천.
• SPC 관점도 넣으면 제조업 어필이 커짐:
 UCL/LCL만 두지 말고 SPC 룰(룰1~4 등) 같은 현장 룰을 보조로 붙여라.4) 포트폴리오/취업 어필
• “논문(레퍼런스) 활용”이 없다는 점 지적:
 제조업(특히 대기업)은 근거(문헌, 표준, 선행연구)를 좋아하니 작은 논문이라도 녹여라.
• n8n은 제조에서 메인이 아니라
 ‘끼워넣은 느낌’ 날 수 있으니 프로젝트 핵심과 분리해서 소개하는 것도 고려.

이 멘토님 (운영/관리자 관점 중심)

1) 알람 운영의 현실성(핵심)
• 알람/메일은 많아지면 무시된다 → “알람 빈도”가 운영 성패.
• 기준(임계치/트리거)이 트렌드에 따라 변할 수 있는데,
 → 그 “기준을 어떻게 잡고/어떻게 조정하는지” 근거 필요.2) 알람 이후 “조치”까지 연결
• 현업의 문제는 “알람을 받는 것”이 아니라
 “알람 보고 실제로 어떤 조치를 했는지(시정/보완 조치 기록)”가 통제되지 않는 것.
• 알람 → 확인 → 조치(누가, 언제, 무엇을)까지 이어지면 현업 가치가 급상승.3) KPI/경영 언어로 번역
• 경영진은 결국 2개만 본다:
 원가 절감 / 성과 개선.
• 대시보드 지표(예: 불량률 11.27%)를
 “목표 대비 갭” 또는 “손실/비용 관점”으로 해석 가능한 구조가 있으면 좋다.
• 다만 대시보드 자체에 비용을 바로 넣기 어렵고(데이터 통합 필요),
 ‘불량률 → 손실 추정’ 같은 번역 레이어를 고민해보라는 취지.4) 성공/실패 요인: 자동화 & 조직 R&R
자동화가 70%여도 나머지 30% 수동 입력이 남으면 현장 반발이 커진다.

• 실제 도입은 데이터/현장/품질 등 이해관계자 R&R(책임/역할) 정리가 필수.

 

임 튜터님 (품질/통계 관점, “치명적인 누락” 지적)

1) 가장 큰 결핍: 가설·통계 검증
• “취업 관점에서 제일 치명적으로 빠진 것”으로 가설 수립 + 통계적 검증을 콕 집음.
• 제조/품질은 전통적으로 “방법(통계 기반)”으로 발전해왔기 때문에
 통계 검증 파트가 있어야 포트폴리오 흐름이 완성된다는 의견.2) PPT/지표 구성 압축
• 성능지표(accuracy/precision/recall/f1) 등을 한 화면에 다 넣기보다
 “우리 목적상 제일 중요한 지표”를 전면에 두고 나머지는 보조로.
• 막대/그래프가 “무엇을 봐야 하는지 초점이 약하다” → 강조점/주석/핵심 1~2개만 남기기.3) 군집화/LOF 근거
• 군집화(성능군 분류)의 근거는 보완 필요.
• LOF 근거를 더 파고드는 건 “투머치”일 수 있으니,
 급한 건 통계검증 + 대시보드 축약이라고 우선순위 제시.4) RUL은 “개념+계산”은 좋았는데…
• RUL 계산 아이디어(대표값+추세/기울기 기반)는 틀린 개념 아니고 좋다고 평가.
• 다만 발표에서는 RUL을 어떻게 구했는지(계산 흐름)가 안 보였다는 지적.
• “RUL 예측 모델을 따로 했냐?” 질문도 나왔고,
 현재는 모델이라기보다 대시보드에 계산 로직을 이식한 형태로 이해함.

이 멘토님 (제약 QA 18년, “사용자/현장 가독성” 중심)

1) 대시보드 권한/사용자 분리
• 작업자 vs 관리자 vs 결정권자 관점이 다르니
 보여주는 화면/지표를 명확히 분리(권한별 뷰) 하면 더 좋다.2) 유지보수까지 연결한 점은 강점
• “설비 유지보수 포인트까지 제시”한 건 매우 긍정적.
 (언제 조치했고, 왜 조치가 필요한지까지 이어지는 구조)3) 알람 트리거의 당위성을 꼭 만들어라
• 질문 포인트:
“한 샷에 4개 제품”인데 4개 중 1개 NG vs 3개 NG의 리스크는 다르다
“연속 2회/3회 알람”의 리스크 차이를 분석했는지
“왜 24샷 단위로 묶었는지” 근거
• 결론: 지금도 구현은 좋지만, 숫자(2/3, 24)의 선택이
 ‘임의 설정’처럼 보이지 않도록 근거(데이터/리스크/운영 정책)를 붙여야 한다.4) 제약/규제 산업 관점 코멘트
제약도 AI/ML 도입 중이고 자동화/리포팅 시스템 존재.
다만 규제 산업이라 “시스템 자체도 검증(Validation) 후에 써야 해서” 쉽게 실시간 적용되지 않는다.

• 제안: 여기에 CPK/공정능력(SPC)까지 접목해서 설명하면 인상이 더 강해진다.

한 줄로 요약하면 (피드백 공통분모)

• (1) 근거: 임계치/군집/알람/24샷 같은 “운영 정책 숫자”의 근거를 더 탄탄히
• (2) 압축: 대시보드는 “의사결정 흐름”만 남기고 과감히 덜어내기
• (3) 품질 언어: 통계 가설검증 + SPC/CPK 같은 제조 표준 언어를 섞기
• (4) 운영 연결: 알람 → 확인 → 조치/이력까지 이어지는 설계 강조
• (5) 경영 번역: KPI를 목표/손실/비용 관점으로 설명할 수 있게

 

 

 

라이브 피드백

가장 큰 구조적 문제
“많이 했다”는 보이는데
“왜 그렇게 했는지”가 약하다
너희는 실험을 많이 했고 모델도 여러 개 만들었고 전략도 많아.
근데 듣는 사람 입장에서는 이렇게 보였어:

실험은 많은데,
 선택 기준이 명확하게 정리되어 있지 않다.

개선해야 할 것

• 각 전략마다 선택 기준 1줄 명시
• “그래서 무엇 때문에 이 전략을 채택했는가”를 구조화

예:

• 기기별 모델 분리 → 데이터 분포 차이 때문
• LOF 결합 → 오탐 억제 목적
• MTBFA 도입 → 알람 과잉 대응 문제 때문

지금은 전략 나열이 많고,
 의사결정 근거 구조화가 부족한 상태야. 데이터 고립(LOF) — 정의 부족
이건 아주 정확한 지적이야.
지금 상태는:

• 고립 여부 판단 → YES / NO
• 의사결정 트리 그림 있음

문제는 이거야:

고립의 기준이 수치로 정의되지 않았다.

실무자는 반드시 묻는다:

• 어떤 변수 조합?
• 거리 기준?
• 스케일링 방식?
• 임계값 어떻게 정했는가?

개선 포인트

• 고립 판단에 사용한 변수 명시
• 거리/밀도 계산 방식 명시
• threshold 선정 근거 명시

지금은 “개념 설명” 단계이고
 현업 기준은 “정량 정의” 단계야. MTBFA / RUL — 검증 과정 부족
이건 꽤 중요한 구조적 문제야.
지금은:

• 개념 설명
• 수식 설명
• 끝

튜터가 말한 건 이거야:

이 지표가 실제로 유의미하다는 검증이 없다.

부족한 점

• 실제 설비 예시 비교 없음
• 지표 수치 차이가 어떤 의미인지 없음
• threshold 근거 없음

즉,

지표 정의는 했는데
 지표 타당성 검증이 없다.

 

개선 포인트

• 정상 설비 vs 불안정 설비 비교
• 지표 분포 차이 제시
• 임계값 설정 기준 제시

지표를 만들었으면
 “왜 이 수치가 위험인지”를 보여줘야 함. 차트 과밀도 문제
이건 발표 완성도에 직결되는 문제야.
지금 슬라이드 특징:

• 한 장에 비교 2~3개
• 이중축
• 누적 막대 + 라인
• 텍스트 설명 과다

결과:

독자가 한 번에 이해 못함

개선 포인트

• 하나의 슬라이드 = 하나의 비교
• 이중축 제거
• 비교 대상 분리
• 텍스트는 차트 밖으로

지금은 “연구 보고서 느낌”
 튜터가 원하는 건 “의사결정 보고서 느낌” 대시보드 과잉 설계
지금 구조는:

• 실시간 대시보드
• 이상탐지 대시보드
• 리포트 대시보드
• 로그 뷰
• 월간 리포트

많다.
튜터가 느낀 건:

기능은 좋은데 구조 정리가 안 됐다.

개선 포인트
• 사용자 기준으로 구분
현장
엔지니어
관리자
• 실시간 vs 배치 분리
• 월간 리포트는 웹에서 제거 가능
지금은 기능 중심 설계고
 현업은 사용자 시나리오 중심 설계야. 집계 마트 부재 (성능 문제)
월간 리포트 로딩 느린 이유:

• 트랜잭션 데이터를 직접 불러옴
• 집계 레이어 없음

현업에서는:

• raw layer
• mart layer (집계 테이블)
• dashboard 연결

이 구조가 기본이야.
이게 없어서:

“분석은 잘했는데 운영 아키텍처 고민은 덜했다”
 로 보였을 가능성 있음.

도식화 수준이 낮음
텍스트 기반 다이어그램이 많음.
튜터가 말한 건:

Mermaid나 Figma 같은 도식화 툴 사용했으면 더 좋았겠다.

즉,
지금은 “텍스트로 설명한 구조”
 원하는 건 “눈으로 이해되는 구조” KPI 카드 부족
대시보드 상단에

• 전체 장비 수
• 정상 장비 수
• 이상 장비 수
• 경고 장비 수

이런 요약 지표가 없음.
이건 UX 완성도 문제야.