[회고] 빵 자동 스캐너와 매장 모니터링 프로젝트

hyoin·2026년 1월 18일

ROS2 부트캠프

목록 보기
4/11
post-thumbnail

이 글은 딥러닝 기반 무인 키오스크 및 매장 모니터링 시스템을 구현한 프로젝트에 대한 회고입니다. 기술적인 결과만 나열하기보다는, 프로젝트를 진행하며 어떤 고민을 했고 어떤 선택을 했는지를 중심으로 적어보았습니다. 이후 포트폴리오로 활용하기 위해, 미래의 저에게 설명하듯 정리해 두려는 목적도 있습니다.


1. 프로젝트 개요와 문제 정의

본 프로젝트는 두 가지 문제 해결에서 시작했습니다.

첫째, 베이커리 매장에서 외형이 유사한 빵 메뉴를 자동으로 인식·분류하는 무인 키오스크입니다. 빵은 외형에 따라 메뉴명이 달라지는 경우가 많아 키오스크 도입이 어렵다는 한계가 있었고, 이를 이미지 기반 분류로 해결하고자 했습니다.

둘째, 매장 내 CCTV 영상을 활용해 상황을 모니터링하고 위험 상황을 감지하는 시스템입니다. 폭행, 낙상, 이동약자 감지를 통해 관리자에게 알림과 통계를 제공하는 것을 목표로 했습니다.

저는 이 프로젝트에서 다음 역할을 담당했습니다.

  • 무인 키오스크 기능 구현
  • 관리자용 대시보드 UI 구성 및 API 연동
  • 폭행 감지 모델 설계 및 구현
  • CCTV 모니터링용 모델 3종 통합

특히 폭행 모델을 설계하고 모델들을 통합할 때, 한정된 GPU 환경에서 실시간으로 여러 AI 모델을 동시에 운용해야 함에 집중했습니다.


2. 전체 시스템 및 모델 구성

2-1. 빵 스캔 기능

  • 빵 탐지: YOLO Segmentation (겹쳐진 빵을 인식할 목적 포함)
  • 빵 분류: ResNet50 기반 feature extractor + kNN

2-2. CCTV 모니터링 기능

  • 이동약자 감지: YOLO Detection
  • 낙상 감지: YOLO Pose + LSTM
  • 폭행 감지: XGBoost + Random Forest soft voting

폭행 감지 모델 선정 과정과 리소스 제약에 대한 고민은 별도 글로 정리했습니다: 모델-설계-6GB-GPU에서-실시간-AI-3종-돌리기


3. 주요 시행착오와 의사결정

3-1. 폭행 감지 모델 전처리 방식 변경

초기에는 YOLO Pose 기반 전처리를 사용해 폭행 여부를 분류하려 했습니다. 그러나 실제 구현 과정에서 다음과 같은 문제가 드러났습니다.

  • 매 프레임마다 YOLO Pose를 실행해야 해 연산 비용이 과도함
  • 다중 인물 상황에서 인식 안정성이 낮음
  • 신체가 크게 뒤틀리는 동작(엎어치기 등)에서는 인식 실패가 빈번함

오프라인 성능 지표(f1 score, precision, recall)는 모니터링용으로 무난한 수준이었지만, 실제 테스트에서 실시간 처리가 불가능하다는 점이 결정적인 한계였습니다. 이때 처음으로, 정량적 지표만 보고 모델을 선택하는 건 서비스에서는 위험할 수 있겠다는 생각이 들었습니다.

대안으로 선택한 것이 optical flow 기반 전처리였습니다. 매장은 소극적인 행동(걷기, 앉기 등)이 대부분이기 때문에, 폭행 상황에서만 픽셀 이동량이 급격히 변할 것이라는 가설을 세웠습니다. 이 가설을 바탕으로 optical flow를 특징으로 사용해 모델을 재학습했고, 실시간 환경에서도 안정적으로 동작하는 결과를 얻었습니다.

이 과정에서 얻은 가장 큰 교훈은 다음과 같습니다.

  • 실시간 서비스에서는 "모델 성능"보다 "전체 파이프라인의 안정성"이 더 중요하다
  • 오프라인 지표와 실제 운영 환경 간에는 명확한 간극이 존재하며, 간극을 해소하기 위해선 실제 환경과 유사한 환경에서의 테스트가 필수적이다.

3-2. 발표 자료 구성에 대한 고민

지금까지 겪었던 프로젝트들은 시연 중심 발표였지만, 이번 프로젝트는 발표만으로도 청중이 시스템을 이해할 수 있어야 했습니다. 이에 따라 다음 원칙을 세우고 자료를 구성했습니다.

  • 설계는 구현의 지도이므로, 청중이 설계의 흐름을 따라갈 수 있어야 한다
  • 기술 설명보다 시연을 먼저 배치해 맥락을 제공한다
  • 시연은 기능 설명이 가능한 테스트케이스 중심으로 구성한다
  • 기술 설명과 중복되는 트러블슈팅은 과감히 제거한다

여러 차례 피드백과 자료 수정 끝에 발표를 마무리했고, 이후 받은 피드백을 바탕으로 파이널 프로젝트에서는 발표 흐름에 더 신경 쓸 계획입니다.


4. 아쉬웠던 점과 한계

4-1. 통신 구조의 미완성

전체 구조상 AI 서버와 GUI를 연결하는 central 서버를 두었지만, 실제 구현에서는 CCTV 스트리밍을 AI 서버에 직접 연결했습니다. 일정과 구현 난이도를 고려해 단기적으로 선택한 구조였지만, 결과적으로 UDP 기반 통신을 프로젝트 기간 내에 완성하지 못했습니다.

이 선택은 빠른 기능 구현에는 도움이 되었으나, 서비스 확장성과 역할 분리에 한계가 있다는 점이 분명합니다. 그래서 프로젝트가 끝난 지금, 별도로 UDP 통신을 구현하며 구조를 보완하고 있습니다.

4-2. 역할 외 기술에 대한 이해 부족

팀 내 소통은 원활했지만, 제가 직접 담당하지 않은 빵 탐지·분류 파트의 세부 기술에 대한 이해가 초반에는 부족했습니다. 매일 진행했던 스탠딩 회의에서 기능 설명을 들었기 때문에 기능 자체는 이해했지만, 사용된 모델과 기법의 정확한 기술적 맥락을 늦게 파악했다는 점이 아쉬움으로 남았습니다.

이 경험을 통해 이후 프로젝트에서는 다음을 원칙으로 삼으려 합니다.

  • 역할과 무관하게 전체 시스템의 핵심 기술 스택을 초기에 정리한다
  • 발표 전에는 주요 모델과 기법의 기본 구조를 직접 확인한다

5. 정리하며

이번 프로젝트는 단순히 여러 AI 모델을 구현하는 데서 끝나지 않고, 제한된 리소스 환경에서 실시간 시스템을 설계하고 타협하는 경험이었습니다. 특히 폭행 감지 모델을 구현하며, 서비스 환경을 확인하기 위해 실제 환경과 유사한 테스트가 정말 중요하다는 걸 다시금 깨달았습니다.

이 경험을 바탕으로 이후 프로젝트에서는 모델 성능뿐 아니라, 시스템 전체 관점에서의 안정성과 확장성을 더 적극적으로 고려하고 싶습니다.

프로젝트 소스코드

profile
배워야 할 게 많은 개발자... 하지만 공부를 포기하지 않지!!

0개의 댓글