엣지 영상 이벤트 감지 포트폴리오: 카메라 한 대에서 실증 보고서까지

영상 AI 개발자를 채용하는 기술연구소의 공고는 종종 하나의 직무 안에 서로 다른 세 작업을 넣는다. 영상을 인식하는 모델, 그 모델을 엣지 장치에서 충분히 빠르게 돌리는 배포 기술, 실제 카메라와 주변 장비를 연결해 현장에서 동작하는 서비스다. 특정한 객체를 찾아 경계 상자를 그리는 데 성공해도 두 번째와 세 번째 과제가 해결되는 것은 아니다.

영상 기반 AI 모델 개발·고도화, 객체 인식·행동·이상상황 분석, 모델 경량화와 추론 속도 개선, 데이터 전처리·학습·평가 파이프라인, 기술 문서 작성, 엣지 디바이스 연결 테스트와 하드웨어·소프트웨어 이슈 대응을 요구하는 공고라면, 포트폴리오에서도 이 작업들을 하나의 경로로 이어 보여 줄 수 있어야 한다. “AI를 사용했다”보다 어떤 영상을 받아 무엇을 판정하고, 어느 장치에서 얼마나 안정적으로 동작했는가가 중심이 된다.

가장 작은 데모의 목표: 사람 탐지에서 사건 기록까지

첫 과제로 적합한 것은 작업구역 침입·장시간 체류 이벤트 감지 데모다. 카메라에 들어온 사람을 탐지한 뒤 사용자가 지정한 관심구역(ROI)에 들어왔는지 판정하고, 구역 안에 설정 시간 이상 머무르면 이벤트를 남긴다. 객체 탐지 모델과 사건 판정 규칙을 나누므로 각각의 책임이 화면에도 드러난다.

가능한 요구사항은 다음 순서로 쌓인다.

1. 웹캠 또는 CCTV 영상의 프레임을 수신한다.
2. YOLO 계열 객체 탐지기를 사용해 사람 위치와 신뢰도를 계산한다.
3. 화면 위에 ROI를 지정하고, 사람과 ROI의 관계를 계산한다.
4. 침입 혹은 체류시간 임계치를 만족할 때 이벤트를 기록한다.
5. 이벤트 시점의 스냅샷·짧은 영상 구간·시각·판정 근거를 저장한다.
6. 웹 화면에서 현재 영상, 감지 상태, 추론 속도와 최근 이벤트를 확인한다.

여기서 “위험행동 감지”라는 표기는 주의가 필요하다. 사람을 찾는 모델이 사람의 의도나 위험 행동을 직접 인식한 것은 아니다. 금지구역 진입은 객체 탐지와 좌표 규칙의 조합이며, 쓰러짐·난동·방치 물체 등의 판단은 별도 모델·시간 정보·검증을 요구할 수 있다. 포트폴리오에서는 탐지된 사실, 규칙이 내린 판정, 사람이 확인한 실제 사건을 구별해 표시해야 한다.

하나의 화면에 드러나야 할 것

데모 화면은 메뉴가 많은 관제 시스템보다 입력-판정-결과의 한눈에 보이는 관계에 집중한다. 왼편에는 카메라 영상과 탐지 상자·ROI를, 오른편에는 모델명·신뢰도 임계값·최근 FPS와 이벤트 상태를 둔다. 아래쪽에는 발생 시각과 이벤트 유형, 스냅샷을 선택할 수 있는 로그를 배치한다. 설정 화면에서는 ROI, 체류시간, 알림 여부와 모델을 조절한다.

이 레이아웃이 기술적 설득력을 얻으려면 화면의 값에 정의가 있어야 한다. FPS가 카메라가 들어온 프레임 수인지 모델이 처리한 프레임 수인지, 추론 지연 시간이 전처리와 후처리를 포함하는지, 이벤트가 같은 사람이 계속 서 있을 때 중복 기록되는지 명확히 해야 한다. 카메라가 끊겼거나 프레임이 누락되었을 때는 “위험 없음”이 아니라 감시 불가 또는 미확인 상태를 표시하는 편이 정확하다.

처음 시연에는 웹캠 하나와 녹화된 짧은 영상 하나면 충분하다. 매번 같은 사건을 재현할 수 있는 녹화본은 현장 데모의 우연성을 줄인다. 하지만 녹화본에서 잘 동작했다는 것만으로 실시간 영상에 적용되었다고 말해서는 안 된다.

추천한 구현 경로와 각 도구의 역할

제안된 초기 구성은 Python과 OpenCV, YOLO 계열 모델, FastAPI 또는 Streamlit, SQLite와 파일 기반 이벤트 저장소였다. 웹 대시보드는 기존 웹 프레임워크에 익숙하다면 Next.js·React를 쓸 수도 있다. 핵심은 유행하는 프레임워크를 많이 사용하는 것이 아니라, 영상 수신·추론·규칙·저장·표시가 서로의 결함을 숨기지 않게 분리하는 것이다.

첫 데모를 모든 행동인식 문제로 확장할 필요는 없다. 작동하는 사람 탐지 + 한 종류의 사건 판정이 성능 측정과 문서화의 출발점이다.

온디바이스·엣지 최적화는 이름이 아니라 측정이다

카메라 영상을 원격 클라우드에서 처리하지 않고 장치 근처에서 추론하면 엣지 처리의 성격을 띤다. 하지만 노트북에서 웹캠과 객체 탐지기를 실행했다고 해서 특정 엣지 보드에 배포할 수 있음을 증명한 것은 아니다. 개발기에서의 엣지형 시연과 실제 보드의 온디바이스 실증은 따로 기록해야 한다.

비교 후보로 제시된 경로는 원본 모델과 ONNX 변환본, 장치에 따라 ONNX Runtime·OpenVINO·NCNN·TensorRT 등의 런타임, 그리고 가능하다면 양자화 모델이었다. 그러나 서로 다른 환경에서 잰 속도를 단순 나열하거나 FP32와 INT8을 이름만 바꿔 비교해서는 경량화 성과가 아니다. 가능한 동일한 입력 해상도·평가 영상·전후처리·반복 횟수로 다음을 비교해야 한다.

• 모델 가중치 크기와 실제 메모리 사용량
• 프레임당 추론 지연 시간과 종단간 지연 시간
• 연속 처리 FPS 및 시간이 흐른 뒤의 속도 변화
• 같은 장면에서의 탐지 누락·오검출·이벤트 판정 변화
• 장치 종류와 실행 백엔드, 모델 버전과 테스트 조건

정확도나 속도의 실측 수치가 없는 상태에서는 우수성을 주장하지 않는다. 양자화는 모델을 작게 만들 수 있지만 대상 객체와 조명 조건에 따라 오검출이 늘 수도 있다. 특히 불규칙한 현장 영상에서는 처리량뿐 아니라 감지할 수 없었던 시간과 실패한 입력도 중요한 성능 항목이다.

카메라와 센서를 합치면 독립적인 포트폴리오가 된다

영상 이벤트를 MQTT로 받은 센서 상태나 PLC·설비 신호와 함께 판단하는 두 번째 단계는 단순한 객체 탐지보다 현장 실무에 가깝다. 예컨대 “위험구역에 사람이 탐지됨”과 “문열림 신호가 들어옴”을 동시에 만족할 때 복합 이벤트를 기록할 수 있다. 사람이 보이지 않는 상태에서 설비 이상 신호가 발생했을 때는 사람이 없다고 결론 내리기보다 영상 불확실성과 설비 상태를 함께 표시해야 한다.

확장 예로는 사람 탐지와 급격한 온도 변화, 접근금지구역 진입과 문열림, 장비 진동 상승과 작업구역 영상 상태 등이 제안됐다. 이는 검증된 위험 예측 모델이 아니라 센서 신호와 영상 판정의 결합 규칙 예시다. 현장에 적용하려면 카메라 지연과 센서 이벤트 타임스탬프의 시간 정렬, MQTT 통신 장애, 센서 보정과 품질, 중복 메시지, 임계값과 오경보 처리가 추가 과제가 된다.

이 구조는 영상만 다루는 개발자와 차별화할 수 있는 지점이기도 하다. 그러나 실제 포트폴리오에 구현되지 않은 센서 연동을 이미 수행한 것처럼 쓰면 안 된다. 대시보드에 가상의 센서값을 표시했다면 모의 데이터임을 명시하고, 나중에 실제 MQTT 또는 PLC 신호로 바꿨을 때 테스트 기록을 남긴다.

데이터 전처리와 평가: 무엇이 모델의 실패인가

이상상황의 정확도는 모델뿐 아니라 데이터의 조건과 판정 정의에 좌우된다. 지시된 ROI가 애매한 경우, 사람이 한 프레임 누락된 경우, 가림이나 역광으로 상자가 흔들리는 경우, 서로 다른 사람이 연속해서 같은 구역에 들어오는 경우는 다른 종류의 오류다. 이런 실패 예시를 명시하면 “영상 AI가 사람을 인식한다”는 추상적 문장을 평가 가능한 기능으로 바꿀 수 있다.

이벤트 로그에는 가능하면 입력 영상 식별자, 장면 시각, 탐지 결과, 규칙 설정, 최종 판정을 함께 남긴다. 위험구역 침입처럼 규칙으로 정의할 수 있는 사건에서는 탐지 모델의 오차와 규칙의 오차를 나눠 보는 평가가 중요하다. 성능 점검 표에는 정상 진입·경계선 접촉·가림·야간·영상 끊김·복수 인원 등 시나리오를 마련하고, 각 결과를 통과·실패·미시험으로 기록하는 방식이 적합하다.

문서가 데모를 완성한다

제시된 채용 공고는 기술 문서 작성과 엣지 하드웨어·소프트웨어 문제 대응을 주요 업무로 포함한다. 따라서 코드 저장소에는 최소한 목적, 입력과 출력, 모델과 런타임 버전, 시스템 구성도, 실행법, 테스트 영상의 조건, 성능 비교표, 실패 사례와 다음 개선 계획이 함께 있어야 한다. 좋은 시연 영상 한 편으로 끝내지 않고 왜 이 모델과 장치를 골랐고 어떤 조건에서 실패하는지를 기록하는 것이다.

제안된 2주형 개발 흐름은 첫 주에 영상 입력·사람 탐지·ROI 침입 판정과 화면을 만들고, 둘째 주에 이벤트 저장·로그·간단한 성능 측정·README와 설계 문서를 더하는 방식이었다. 이 일정은 개발 계획 예시이지 완성 기간의 보증이나 수행 완료 기록이 아니다. 완주 기준은 기능 수보다 재현 가능한 실행과 평가 기록에 둔다.

채용 자료에서도 “PyTorch를 사용할 줄 안다”거나 “엣지 AI를 했다”는 포괄적 문장보다, 영상에서 사건을 분리하고 기록했으며 모델 처리 조건을 비교했다는 검증 가능한 구현 범위를 설명하는 편이 설득력 있다. 기존 현장 데이터·원격 운영 기술과의 연결도 실제 구현 범위를 벗어나 과장하지 않아야 한다.

소설 에이전트와 공통인 공학적 교훈

로컬 소설 제작기가 생성된 본문과 요약, 검수·재개 지점을 구별하는 것처럼 영상 이벤트 시스템도 화면에 보이는 상자, 내부 판정, 저장된 사건, 사람이 확인한 실제 상황을 구별해야 한다. 둘 다 모델 출력이 그럴듯한 순간에 시스템 전체가 완성된 것으로 착각하기 쉽다. 장기 실행과 엣지 배포에서 신뢰할 수 있는 것은 재현 가능한 입력, 판정 근거, 남겨진 결과, 실패가 드러나는 기록이다.

관련 문서

• 출근 전에 켜두는 로컬 소설 제작기
• 피지컬 AI의 월드 모델과 양자 최적화
• 오래된 영어책 한 권을 끝까지 번역하려면