2026. 06. 27 멘토링 일지

임종찬·2026년 6월 27일

AI API KDT Opensearch SK Rookies SK shieldus consumer group kafka msa redmine websocket 국비지원 데이터 흐름도 루키즈 개발 5기 멘토링 무중단

멘토링 일지

목록 보기

4/6

중간발표 피드백

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

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 관리 방식에 대한 피드백도 받았다.

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

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

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

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

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

앞으로 해야 할 일

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

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

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

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

임종찬

SK쉴더스 루키즈 개발 트랙 5기

이전 포스트

2026. 06. 13 멘토링 일지

다음 포스트