해결하려던 문제
Switch·CCTV·NVR은 장비 종류와 제조사에 따라 상태 조회, 영상 수신, 이벤트 수신 방식이 모두 달랐습니다. 관리자가 장비를 하나씩 따로 확인하지 않고 한 시스템에서 관리하려면, 서로 다른 방식을 하나의 데이터 흐름으로 묶어야 했습니다. 일부 기능은 문서가 없거나 부족했습니다.
- Switch · CCTV · NVRSNMP · 제조사 API · RTSP · SDK
- 상태·영상·이벤트
- 장비별 연동부Node.js 수집기 · C# NVR 서비스
- REST
- 공통 관제 백엔드Express · MariaDB
- WebSocket · REST
- 관제 화면React
- 본인 담당
- 협업자·팀원 담당
- 외부 장비·시스템
담당 범위와 협업
직접 한 일
- 관제 대상·기능 기준의 데이터 모델과 아키텍처 설계
- 상태·영상·이벤트 처리 REST API 구현, Postman API 문서 작성
- Switch 모델·업타임·포트 상태 주기 수집(SNMP v2c·제조사 API), 변경 이벤트 저장과 WebSocket 전달
- CCTV RTSP 영상을 FFmpeg 기반 WebSocket 스트림으로 변환, 제조사 CGI API 연동
- NVR 제조사 SDK 콜백 이벤트를 받는 C# 서비스와 백엔드 연결
- JWT 인증, 비밀번호 해시, 입력 검증
협업 범위
- 관제 화면 개발 (화면 담당 개발자)
- 기능 지원 여부·API 자료 제공 (장비 제조사)
주요 판단과 선택 이유
- SDK에 묶인 NVR 연동은 별도 서비스로 뗐습니다. NVR 제조사 SDK는 C# 환경에 종속돼 있어, 공통 백엔드(Node.js)에 섞지 않고 C# ASP.NET Core 서비스로 분리했습니다. 장비별 차이는 연동부에 가두고, 상태·이벤트는 공통 흐름으로 저장·전달하는 구조입니다.
- 상태는 “바뀐 것”을 이벤트로 남겼습니다. Switch 상태를 주기적으로 수집하면서 이전 상태와 비교해, 변경이 있을 때만 이벤트로 저장하고 화면에 전달했습니다.
- 문서가 없으면 제조사에 직접 확인했습니다. 프로토콜·제조사 문서를 먼저 분석하고, 필요한 기능이나 문서가 없을 때 제조사 담당자에게 지원 여부와 API 자료를 요청했습니다.
- API는 문서로 공유했습니다. 화면 개발자가 요청·응답 구조를 바로 쓸 수 있도록 Postman 문서를 직접 작성했습니다.
구현 과정
- 관제 대상과 기능을 기준으로 데이터 모델을 설계하고 REST API를 구현했습니다.
- Switch는 SNMP v2c와 제조사 API로 상태를 수집하고, 변경 이벤트를 MariaDB에 저장한 뒤 WebSocket으로 전달했습니다.
- CCTV는 RTSP 영상을 FFmpeg로 MPEG1/WebSocket 스트림으로 바꾸고, 부가 기능은 제조사 CGI API로 연동했습니다.
- NVR은 C# 서비스에서 SDK 콜백 이벤트를 받아 Node.js 백엔드 API로 넘겼습니다.
결과와 검증
- 사무실의 Switch·CCTV·NVR 각 1대로 상태 조회, 영상 재생, 이벤트 수신·저장·화면 전달까지 핵심 흐름을 확인했습니다.
- 화면을 제외한 기획·데이터베이스·아키텍처 설계와 장비 연동·백엔드 개발을 맡아 사무실 검증까지 마쳤습니다.
- 산출물: 데이터베이스·아키텍처 설계, 백엔드 소스, NVR 연동 서비스, REST API와 Postman 문서.
아래는 사용자 인터페이스 설계서의 화면입니다. 화면은 담당 개발자가 만들었고, 화면에 나오는 장비 상태·장애 이벤트는 본인이 만든 백엔드가 수집해 전달합니다.
NMS · Switch 포트 상태
장애 이력