납품일에 멈추는 시스템 — 우리가 관제 플랫폼을 직접 만든 이유

SI 계약서에서 가장 중요한 날짜는 납품일입니다. 요구사항을 정리하고, 개발하고, 검수를 통과하면 그날 시스템은 완성됩니다. 그리고 대개 그날 멈춥니다.

멈춘다는 말이 과장으로 들린다면, 5년 전에 구축한 관제 화면을 떠올려 보시면 됩니다. 화면 구성은 구축하던 날 그대로입니다. 그사이 현장은 라인을 늘렸고, 출입 정책이 바뀌었고, 카메라를 스무 대 더 달았습니다. 시스템만 2021년에 남아 있습니다. 버튼 하나를 옮기려 해도 견적서부터 받아야 하고, 만든 회사는 이미 다른 프로젝트에 가 있습니다.

이것이 위치 기반 관제 업계의 기본값이었습니다. 우리도 처음에는 이 방식으로 일했습니다.

「ORBRO OS 이야기」는 우리가 그 기본값에서 어떻게 빠져나왔는지에 대한 글 묶음입니다. 이 글은 그중 가장 밑에 있는 선택을 다룹니다. 프로젝트마다 시스템을 만드는 대신, 플랫폼을 직접 만들기로 한 결정입니다.

Ⅰ. 납품일에 멈추는 시스템

SI 방식 자체가 틀린 것은 아닙니다. 요구가 정말 특수하다면 맞춤 개발이 맞습니다. 문제는 위치 기반 관제라는 영역에서 대부분의 프로젝트가 사실은 같은 것을 다시 만든다는 데 있습니다.

지도 위에 위치를 그리는 엔진. 장비를 등록하고 상태를 보는 화면. 조건에 따라 알람을 보내는 규칙. 데이터를 쌓고 조회하는 저장소. 이름만 다를 뿐 골격이 같은 기능들이 프로젝트마다 새로 개발되고, 서로 호환되지 않는 코드가 되어 현장마다 흩어집니다.

이 구조의 진짜 비용은 개발비가 아닙니다. 어떤 현장도 다른 현장의 개선을 나눠 받지 못한다는 것입니다. A 현장을 위해 만든 좋은 기능은 A 현장에서 끝납니다. 같은 버그는 현장 수만큼 반복해서 고칩니다. 몇 년이 지나면 서로 닮았지만 아무것도 공유하지 않는 시스템이 열 개 쌓입니다.

구분	프로젝트별 SI 개발	플랫폼 + 앱 (ORBRO OS)
시작점	매번 빈 화면에서	검증된 코어 위에서
요구 반영	요구사항 전체를 신규 구현	필요한 앱을 켜고, 없는 것만 개발
납품 이후	계약 종료와 함께 업데이트 중단	업데이트가 계속 도착
개선의 확산	그 현장에만 적용	기본 기능이 되어 전 고객에게
버그 수정	현장 수만큼 반복	코어에서 한 번
고객 전용 요구	코어를 뜯어 수정	API 위 커스텀 앱, 코어는 무손상

여기서 나오는 반문이 있습니다. "그 범용 플랫폼이 우리 현장에 맞겠느냐." 정당한 걱정입니다. 아래 두 장이 그 질문에 대한 답입니다.

Ⅱ. "OS"는 은유가 아니라 구조다

이름에 OS를 붙인 것은 수사가 아니라 설계 결정이었습니다.

처음부터 이런 모습은 아니었습니다. 초기 화면은 흔한 관제 웹처럼 메뉴가 있고 항목을 누르면 페이지가 바뀌는 구조였습니다. 우리는 그 메뉴를 걷어내고 기능 하나하나를 설치하고 삭제할 수 있는 앱으로 다시 정의했습니다. 그다음에 멀티태스킹과 작업 표시줄을 얹었습니다. 관제 화면을 웹사이트가 아니라 바탕화면으로 만들겠다는 결정이었습니다.

지금 ORBRO OS를 열면 브라우저 주소는 거의 바뀌지 않습니다. 대신 화면 안에서 창이 열리고, 겹치고, 작업 표시줄에 쌓입니다. 지도 위에서 자산 위치를 보다가 출입 기록 창을 띄우고, 그 위에 카메라 창을 겹쳐 둘 수 있습니다. 페이지를 이동하는 웹사이트가 아니라, 하나의 바탕화면 위에 앱을 띄우는 방식입니다.

이 구조가 중요한 이유는 화면이 아니라 그 아래에 있습니다. 운영체제가 하드웨어를 추상화해 앱이 하드웨어를 몰라도 되게 만들듯, ORBRO OS는 위치 인프라와 데이터를 추상화합니다. 앱은 앵커가 몇 대인지, 카메라가 어떤 모델인지 알 필요가 없습니다. 새 기능을 만들 때 지도와 인증과 알람을 다시 만들지 않아도 된다는 뜻입니다. 그래서 앱이 빨리 늘어납니다. 실제로 늘었습니다.

Ⅲ. 22개 앱 — 켜는 것으로 완성되는 관제

스마트폰을 살 때 우리는 모든 앱이 깔린 기기를 사지 않습니다. OS가 있고, 필요한 앱을 고릅니다. ORBRO OS도 같은 방식입니다. 현재 22개 앱을 5개 카테고리로 제공하고, 현장은 필요한 것만 켭니다. 워크스페이스 단위로 앱을 활성·비활성할 수 있어서, 쓰지 않는 기능은 화면에 아예 나타나지 않습니다.

기본 (5) — Dashboard, Device Manager, Setting, 3D View, Weather. 어느 현장에나 있어야 하는 골격입니다.

위치추적 (10) — Zone Manager, Zone Counting, Zone Effect, In-out Tracking, Reverse Tracking, Alert Zone, Access, Heatmap, Timeline, Record. 가장 두꺼운 카테고리이자 플랫폼의 심장입니다. 구역을 그리고, 그 구역을 드나든 사람과 자산을 세고, 지나간 경로를 되짚습니다. 바탕이 되는 기술은 RTLS 소개 페이지에 정리해 두었습니다.

AI (4) — AI Event, AI RTLS, Multi Cam, LPR. AI Event는 카메라 영상에서 헬멧 미착용, 쓰러짐, 화재, 위험구역 진입, 충돌 같은 상황을 잡아냅니다. 엣지 제품 AI Event Manager와 연동해 영상 분석은 현장의 엣지 장비에서 처리합니다.

데이터 분석 (2) — Scan Insight, Nearby Search. 쌓인 위치·신호 데이터를 조회하고 분석합니다. 관제가 '지금'을 보는 일이라면 이쪽은 '다음'을 준비하는 일입니다.

서비스 (1) — SOP. 조건이 걸리면 정해진 대응 절차를 화면에 띄웁니다. 사고가 났을 때 담당자가 매뉴얼을 찾을 필요가 없게 만드는 앱입니다.

같은 플랫폼이어도 제조 공장과 오피스는 전혀 다른 조합을 켭니다. 공장은 Alert Zone·AI Event·Zone Counting을 앞에 두고, 오피스는 Access·Heatmap·Dashboard를 중심에 놓습니다. 앱을 고르는 순간 범용 플랫폼은 그 현장만의 관제 시스템이 됩니다. 개발이 아니라 구성으로.

Ⅳ. 한 현장의 요구가 모두의 기본 기능이 되기까지

플랫폼을 만들며 지켜 온 원칙이 하나 있습니다. 고객 요구를 가능한 한 '기본 기능'으로 흡수한다는 것. 말로는 쉬우니 실제로 어떻게 됐는지 세 가지만 보겠습니다.

전시 공간을 운영하는 한 고객이 특정 구역에 사람이 들어오면 즉시 알려 달라고 했습니다. 그 요구로 만든 기능은 해당 고객 전용으로 끝나지 않고, 다듬어져 Alert Zone이라는 앱이 되었습니다. 지금은 22개 앱 중 하나로 모든 고객이 씁니다.

대형 건설 현장을 운영하는 고객은 상황이 발생하면 시스템이 대응 절차를 직접 띄워 주기를 원했습니다. 여기서 나온 것이 SOP 앱입니다. 함께 붙인 무선 센서 연동 — 공기질, 가스, 누수, 비상버튼 — 도 지금은 기본 제공입니다.

야적장을 운영하는 고객은 자재 입출고를 바코드로 찍고 싶어 했습니다. 위치추적 플랫폼에 바코드는 낯선 요구입니다. 이것도 기본으로 들어갔습니다. 바코드 자산 관리와 PDA 스캐너 연동이 정식 기능이 되었고, 창고를 쓰는 다른 고객들이 그대로 씁니다.

세 경우 모두 요구한 고객은 자기 요구를 얻었고, 요구하지 않은 고객은 요구하지 않은 기능을 얻었습니다.

물론 흡수할 수 없는 요구도 있습니다. 그 회사의 업무 규칙에만 존재하는 화면, 그 조직에서만 쓰는 결재 흐름 같은 것들. 이때 코어를 뜯지 않습니다. 플랫폼이 열어 둔 API 위에 그 고객 전용 앱을 얹습니다. 코어의 안정성과 현장의 특수성을 함께 지키는 방식이고, 내부에서는 하이브리드 패턴이라고 부릅니다.

이 구조를 끝까지 책임질 수 있는 이유는 층 전체를 우리가 만들기 때문입니다. 위치 태그 하드웨어부터 현장에 놓이는 엣지 장비, 그 위의 관제 소프트웨어까지 한 회사가 설계합니다. 특정 대기업 생태계에 얹혀 있지 않으니 문제가 생기면 어느 층에서든 우리 손으로 고칠 수 있고, 다음에 무엇을 만들지도 우리가 정합니다.

Ⅴ. 데이터는 현장 밖으로 나가지 않는다

ORBRO OS는 온프레미스로 설치됩니다. 클라우드 제품에 온프레미스를 '지원'하는 것이 아니라, 현장 안에 서버를 두는 것을 전제로 설계했습니다.

국내 B2B 현장의 조건 때문입니다. 공공기관과 제조 현장에서는 망분리와 보안 심사가 걸려 있어 외부 클라우드로 데이터를 내보내는 것 자체가 불가능한 경우가 많습니다. 작업자의 위치와 카메라 영상은 특히 민감합니다. 이런 현장에서 온프레미스는 선택지가 아니라 입장 조건입니다.

맞는 현장은 결국 같은 질문을 가진 곳들입니다. 무엇이 어디에 있는가. 작업자 안전과 동선을 봐야 하는 제조, 자산과 물류 흐름을 추적해야 하는 창고, 출입과 공간 운영을 관리하는 오피스, 관할 상황을 한 화면에서 파악해야 하는 지자체. 요구는 전부 다르지만 바탕의 질문은 같고, 그 위에 각자 다른 앱 조합을 얹으면 됩니다.

마치며

우리가 관제 플랫폼을 직접 만든 이유는 단순합니다. 현장마다 처음부터 다시 만드는 방식으로는, 어떤 현장도 계속 좋아지는 시스템을 가질 수 없기 때문입니다.

ORBRO OS에는 납품일이 없습니다. 배포일만 있습니다. 메뉴를 걷어내고 앱 체제로 바꾸었던 그날부터 1년 남짓 동안, 서른 번 가까이 배포했습니다.

앞에서 특정 구역 알림을 요청했던 그 고객을 다시 떠올려 보겠습니다. 그가 요청한 것은 앱 하나였습니다. 그동안 그의 화면에는 요청하지 않은 스물한 개의 앱이 함께 도착했습니다. 바코드도, 대응 절차도, 영상 이벤트 감지도 처음에는 다른 현장에서 온 요구였습니다. 5년 전 화면에 멈춰 있는 시스템에서는 일어나지 않는 일입니다.

이어지는 글에서는 이 플랫폼을 채우는 앱들을 카테고리별로 들여다봅니다. 가장 두꺼운 위치추적 앱 열 개, 사람이 지켜보지 않아도 현장을 읽는 AI 앱, 그리고 그 전부를 떠받치는 기본 앱들입니다. 그전에 화면을 직접 보고 싶으시다면, 데모와 도입 문의는 언제든 환영합니다.