다지점 통합 관제, 현장이 여러 곳이 되면 구조가 달라지는 이유

오전 아홉 시, 본사 운영 담당자가 노트북을 엽니다. 주소를 하나 치고, 아이디와 비밀번호를 넣고, 어제 상태를 확인합니다. 그리고 다음 주소를 칩니다. 지점이 열두 곳이면 이 과정을 열두 번 반복합니다. 관리 지점이 스무 곳으로 늘면, 담당자는 오전을 로그인으로 다 쓰게 됩니다.

최근 저희가 받은 문의 세 건이 서로 다른 업종인데 같은 문장을 담고 있었습니다. 전국에 무인 보관 지점을 200곳 넘게 운영하는 회사는 전지점 적용을 전제로 견적을 요청했고, 여러 철거 현장을 옮겨 다니는 건설사는 “추후 여러 현장으로 확대할 경우 현장별 데이터를 한 계정에서 통합 관리할 수 있는지”를 질문 목록 마지막에 적었습니다. 매장 열두 곳을 운영하는 리테일 기업도 지점별 현황을 한 번에 보는 대시보드를 요구했습니다.

세 곳 모두 단일 현장에서 잘 돌던 시스템을 그저 여러 번 깔면 될 것으로 생각합니다. 그런데 현장을 늘리는 것과 본사에서 보는 것은 같은 일이 아닙니다. 화면을 옆으로 늘리는 것과 층을 하나 올리는 것은 다릅니다.

I. 한 곳에서 되던 것이 열두 곳에서 안 되는 세 가지 이유

1. 계정과 권한

단일 현장은 관리자 한 명이 모든 것을 보는 구조로 둔 경우가 많습니다. 지점이 여럿이 되면 이 전제가 깨집니다. 지점장은 자기 지점만 봐야 하고, 지역 관리자는 담당 권역을 보고, 본사 안전팀은 전체를 보되 개인을 특정하는 항목은 못 보게 막아야 할 수도 있습니다. 계정을 나누는 일이 아니라 조직도를 시스템 안에 그리는 일입니다.

2. 집계

지점 화면 열두 개를 나란히 붙여 놓으면 보기엔 그럴듯하지만 질문에 답하지는 못합니다. 본사가 실제로 궁금한 것은 “오늘 전체에서 미처리로 남은 건이 몇 건인가”, “지난달 대비 사건이 늘어난 지점은 어디인가” 같은 합계와 순위입니다. 이건 화면을 모아서가 아니라 데이터를 모아야 나옵니다.

3. 네트워크

단일 현장은 같은 망 안에서 보는 구성이 무난합니다. 지점이 흩어지면 밖으로 나가는 경로가 필요해집니다. 이때 가장 흔히 공사가 커지는 것이 영상입니다. 상태값과 사건 기록은 가벼워서 어느 회선으로든 올라가지만, 영상을 상시로 내보내면 회선비도 보안 부담도 급하게 오릅니다.

이 세 가지를 먼저 정하지 않고 장비부터 달면, 지점 수가 늘 때마다 구조를 다시 짜게 됩니다. 다지점 설계는 나중에 붙이는 기능이 아니라 첫 현장에서 정해야 하는 전제입니다.

II. 지점이 늘면 새로 생기는 결정 네 가지

1. 무엇을 올리고 무엇을 현장에 남길 것인가

모든 원본 데이터를 본사로 보낼 필요는 없습니다. 현장의 엣지 장비가 영상을 보며 판정하고, 판정된 사건과 그 순간의 클립만 올리는 구조가 가장 흔하고 또 가장 오래 갑니다. 회선 부담이 작고, 사건이 생겼을 때만 영상을 열면 되기 때문입니다.

2. 권한을 몇 장으로 나눌 것인가

보통 세 장이면 충분합니다. 현장 작업자, 지점 책임자, 본사 관리자입니다. 중요한 것은 장수가 아니라 상위 권한이 하위 데이터를 어디까지 볼 수 있는가를 문서로 정해 두는 것입니다. 이걸 정해 두지 않으면 나중에 반드시 현장에서 문제가 됩니다.

3. 지점마다 다른 것을 어떻게 흡수할 것인가

지점 열두 곳은 제각기 다릅니다. 면적도 다르고 구조도 다르고 출입구 수도 다릅니다. 그런데 본사 화면은 같은 지표로 줄을 세워야 합니다. 그래서 구역의 이름과 사건의 이름을 전사 공통으로 맞추는 작업이 반드시 필요합니다. 어느 지점은 입구를 “정문”으로, 다른 지점은 “1게이트”로 부르면 집계가 안 됩니다. 지루해 보이지만 다지점 구축에서 가장 자주 발목을 잡는 대목입니다.

4. 지점이 늘 때 비용은 어떻게 늘어나는가

두 번째 지점과 서른 번째 지점의 추가 비용은 같지 않습니다. 장비는 선형으로 늘지만 중앙 설계는 한 번 해 두면 계속 씁니다. 견적을 받으실 때 지점 한 곳 기준과 전체 기준을 나눠서 보시면 확장 계획을 세우기 훨씬 쉽습니다.

III. 지점마다 따로 두고 리포트만 모으면 되지 않나

충분히 나올 반문입니다. 실제로 지점이 서너 곳 이하이고 사건이 드문 경우라면 이 방식이 가장 쌉니다. 지점마다 독립적으로 운영하고 월말에 파일을 모으면 됩니다.

갈리는 지점은 둘입니다. 첫째는 시간입니다. 리포트는 지난 일을 알려 줍니다. 지금 어느 지점에서 무슨 일이 벌어지고 있는지를 묻기 시작하면 문서로는 답이 안 됩니다. 둘째는 일관성입니다. 지점마다 따로 운영하면 기준도 같이 갈라집니다. 어느 지점은 경보를 느슨하게 잡고 어느 지점은 빡빡하게 잡아 두면, 수치만 보고 지점을 비교하는 순간 잘하는 곳이 못하는 곳으로 보입니다.

그래서 기준은 개수가 아니라 질문의 종류입니다. 월말에 돌아보는 질문만 있다면 리포트로 충분합니다. 오늘 지금을 묻는 질문이 생겼다면 그때부터는 통합이 필요합니다.

IV. 지점 수에 따라 달라지는 것

구분	현장 1곳	2에서 10곳	10곳 이상
계정 구조	관리자 1명으로 충분	지점장·본사 2단계	권역을 끼운 3단계
화면	현장 도면 하나	지점 전환 목록	집계 화면이 기본, 도면은 상세
구역·사건 이름	현장 편의대로	공통안 권장	공통 체계 필수
영상	상시 열람 가능	사건 중심 열람	클립 중심, 원본은 현장 보관
비용의 주역	장비비	장비비 + 회선	장비비 + 운영 표준화

오른쪽으로 갈수록 기술보다 규칙의 비중이 커집니다. 지점이 많은 조직이 실제로 사는 것은 장비가 아니라 같은 이름으로 생각하는 상태입니다.

V. 도입 검토 시 확인할 것

먼저 지금 몇 곳이고 이년 뒤에 몇 곳인지를 적어 보시기 바랍니다. 이 숫자 하나가 구조 선택을 대부분 결정합니다. 늘릴 계획이 없다면 무거운 통합 구조를 미리 사실 이유가 없습니다.

다음은 회선입니다. 지점이 자체 인터넷을 쓰는지, 본사 망에 묶여 있는지, LTE 라우터만 있는지에 따라 올릴 수 있는 데이터의 양이 갈립니다. 이건 설치 전에 반드시 확인해야 하는 항목이고, 나중에 바꾸기가 가장 어렵습니다.

세 번째로 지점 한 곳을 기준 현장으로 정하십시오. 가장 큰 곳이 아니라 가장 흔한 형태의 지점이 좋습니다. 거기서 구역 이름과 사건 기준을 정리해 두면 나머지 지점은 복제가 됩니다.

마지막으로 사건이 발생했을 때 누가 먼저 보느냐를 정하셔야 합니다. 본사가 먼저 보는 구조는 통제가 쉬우나 현장이 수동적이 되고, 현장이 먼저 보는 구조는 빠르나 본사가 뒤늦게 압니다. 정답은 업무 성격에 따라 다르지만, 정해 두지 않으면 둘 다 놓칩니다.

마치며

오전 아홉 시에 로그인을 열두 번 하는 것은 시간이 아깝기 때문만이 아닙니다. 열두 번을 다 돌고 나서도 전체가 어떤 상태인지는 여전히 모르기 때문입니다. 화면을 옆으로 아무리 늘려도 그 위의 층은 생기지 않습니다.

ORBRO OS는 여러 현장의 구역과 상태를 한 체계로 묶어 보기 위해 만들어졌고, 현장에서는 UWB RTLS와 AI Event Manager가 위치와 영상 사건을 만듭니다. 하드웨어부터 관제 화면까지 한 손에서 만들기 때문에 지점이 늘어날 때 어느 계층을 바꿔야 하는지를 같은 자리에서 판단할 수 있습니다. 지금 지점 수와 이년 뒤 계획을 알려 주시면 거기에 맞는 구조부터 같이 그려보겠습니다.