프로젝트 배경
1) 문제점 - 장비 제조사마다 통신 규격이 다르고 일부는 자체 클라우드를 거쳐야만 제어가 되어, 장비를 추가할 때마다 서버를 수정하게 됨 - 현장·고객사가 늘면 데이터 경계 관리가 어려워지고, 코드 한 줄의 실수가 타 고객 데이터 노출로 이어질 수 있음 - 장비 등록 경로가 여러 개면 검증되지 않은 장비가 들어올 여지가 생김 - 제어 명령의 도달 여부와 처리 결과를 추적할 수 없으면 현장 대응이 늦어
프로젝트 성과
새 장비 지원이 서버 수정 없이 어댑터 추가로 끝나는 구조
통신 방식이 다르거나 제조사 클라우드를 거치는 장비도 위에서는 같은 장비로 보입니다. 화면과 자동화 규칙을 다시 만들지 않습니다
고객사 데이터 경계를 데이터베이스가 강제
코드에서 조건을 빠뜨려도 다른 고객 데이터가 조회되지 않습니다. 사람 실수로 생기는 정보 노출 사고를 구조로 막았습니다
검증된 장비만 등록되는 단일 경로
장비가 제조 단계 인증서를 제시해야 등록됩니다. 등록 경로를 하나로 고정해 뒷문으로 들어오는 경우를 없앴습니다
전 계층 동시 기동 관통 검증 · 테스트 354건
서버·어댑터·펌웨어·웹을 함께 띄워 장비 발견에서 명령 실행 확인까지 이어지는 것을 확인했습니다
핵심 기능
진행 단계
조사와 계약 설계
2026.07.
기성 IoT 런타임의 한계를 조사하고, API와 데이터 계약을 먼저 문서로 고정한 뒤 구현에 들어갔습니다
프로젝트 상세
현장에 장비를 늘리다 보면 같은 문제를 반복해서 만납니다. 제조사마다 통신 방식이 다르고, 어떤 장비는 자기네 클라우드를 거쳐야만 제어됩니다. 장비를 추가할 때마다 서버를 뜯어고치게 되고, 현장이 늘면 어느 데이터가 어느 고객 것인지 관리가 어려워집니다. 그래서 장비를 붙이는 부분과 데이터를 다루는 부분을 처음부터 분리해 플랫폼으로 만들었습니다. 새 장비를 지원할 때는 어댑터만 추가합니다. 서버 본







