구역을 그리는 순간 관제가 시작된다 — 위치추적 앱 열 개
2026-08-05
실시간 위치추적(RTLS)을 처음 켠 날, 현장에서 가장 자주 나오는 반응은 감탄이 아니라 질문입니다. 도면 위에 점들이 떠서 실제로 움직입니다. 사람이 걸으면 점도 걷습니다. 그리고 5분쯤 지나면 담당자가 묻습니다. "그래서 이걸로 뭘 하죠?"
정당한 질문입니다. 좌표는 그 자체로 정보가 아니기 때문입니다. 어떤 태그가 도면 위 어느 지점에 있다는 사실은, 그 지점이 자재 적재구역인지 통행로인지 출입 금지 구역인지 시스템이 모르는 한 아무것도 말해 주지 않습니다.
그래서 ORBRO OS에서 위치추적을 시작할 때 가장 먼저 하는 일은 태그를 켜는 것이 아닙니다. 도면 위에 선을 긋는 일입니다.
「ORBRO OS 이야기」 이번 글은 플랫폼에서 가장 두꺼운 카테고리, 위치추적 앱 열 개를 다룹니다. 미리 말해 두면 열 개 중 아홉 개는 첫 번째 앱이 그은 선 위에서 동작합니다.
Ⅰ. 선을 긋는 앱 — Zone Manager
Zone Manager는 도면 위에 운영 구역(Zone)을 그리는 앱입니다. 사각형, 다각형, 펜으로 자유롭게 그리기, 이동과 회전, 지우개, 되돌리기까지 여덟 가지 도구로 원하는 모양을 만들고 이름을 붙입니다. 이렇게 만들어진 구역은 도면 위의 그림이 아니라 좌표 폴리곤 데이터로 저장됩니다.
규모가 감이 안 오실 수 있어 실제 숫자를 들면, 저희 사무 공간 한 층에만 33개의 구역이 등록되어 있습니다. 회의실, 카페테리아, 쇼룸, 통로처럼 운영상 구분해서 봐야 하는 단위마다 하나씩입니다.
중요한 점은 이 구역이 도면 종류를 가리지 않는다는 것입니다. 실내 벡터 도면이든, 도시 지도 위의 옥외 광장이든, 산업 현장의 항공사진이든 구역을 그리는 방식은 똑같습니다. 실내와 실외를 같은 문법으로 다룰 수 있다는 뜻입니다.
Zone Manager는 ORBRO OS에서 끌 수 없는 앱입니다. 워크스페이스마다 필요 없는 앱은 꺼서 화면에서 치울 수 있지만, 이 앱만은 비활성화 토글이 잠겨 있습니다. 나머지 아홉 개가 이 앱이 만든 데이터를 먹고 살기 때문입니다.
한 가지 실무적인 조언을 덧붙이면, 구역 이름은 처음에 제대로 지어야 합니다. 나중에 알림이 발송될 때 구역 이름이 문구에 그대로 들어갑니다. "Zone 07에 진입했습니다"와 "3라인 프레스 위험구역에 진입했습니다"는 새벽 두 시에 문자를 받는 사람에게 전혀 다른 메시지입니다.
Ⅱ. 구역이 생기면 세기 시작한다
구역이 정의되면 첫 번째 질문이 생깁니다. 지금 저기 몇 명 있나.
Zone Counting이 그 답을 냅니다. 구역과 추적 카테고리를 지정하면 현재 인원과 누적 인원을 카드로 보여 주고, 시간에 따른 변화를 그래프로 그립니다. 같은 구역에 여러 개를 걸 수 있는 것이 이 앱의 요령입니다. 카페테리아 하나에 '사람 수 집계'와 '자산 수 집계'를 따로 등록해 두면, 같은 공간을 두 가지 눈으로 동시에 볼 수 있습니다.
두 번째 질문은 방향입니다. 몇 명이 있느냐보다 몇 명이 들어오고 나갔느냐가 중요한 곳이 있습니다.
In-out Tracking은 구역 안에 기준선을 긋고 어느 쪽이 IN이고 어느 쪽이 OUT인지 지정합니다. 그 선을 넘는 대상을 방향에 따라 입장과 퇴장으로 분류해, 0시부터 24시까지 시간대별 막대그래프로 쌓습니다. 출입구, 게이트, 통로처럼 흐름이 지나가는 지점에 씁니다.
Reverse Tracking은 같은 기준선을 쓰되 목적이 반대입니다. 정상 이동 방향을 정해 두고, 그 반대로 지나간 것만 잡아냅니다. 일방통행 통로를 거슬러 오는 지게차, 출차 전용 램프로 진입하는 차량 같은 것들입니다. 정상 흐름은 기록하지 않고 어긋난 것만 남기기 때문에, 기록이 쌓인다는 사실 자체가 곧 경고입니다.
여기서 반드시 짚어야 할 함정이 하나 있습니다. 기준선의 방향을 반대로 놓으면 결과가 통째로 뒤집힙니다. 입장이 퇴장으로, 역주행이 정상 통행으로 집계됩니다. 시스템은 오류를 내지 않고 조용히 틀린 답을 냅니다. 설치 직후 사람이 한 번 직접 지나가 보면서 방향이 맞는지 확인하는 절차를 권합니다. 5분이면 되는 일이 몇 달치 데이터를 살립니다.
Ⅲ. 구역은 경고도 한다
세는 것 다음은 알리는 것입니다.
Alert Zone은 구조가 가장 단순합니다. 구역 하나와 대상 카테고리 하나를 연결해 두면, 그 대상이 구역에 들어오는 순간 경보가 발생합니다. 복잡한 조건식을 세우지 않아도 되기 때문에 출입 금지 구역, 통제 구역, 위험 설비 주변처럼 "들어오면 안 되는 곳"에 바로 걸 수 있습니다. 발생 기록은 시간순으로 쌓이고 엑셀로 내려받을 수 있습니다.
Zone Effect는 알림의 방식이 다릅니다. 문자나 팝업이 아니라 지도 자체를 바꿉니다. 조건이 충족되면 해당 구역이 도면 위에서 점멸하거나 색이 어두워집니다. 관제 화면을 보고 있는 사람은 알림 목록을 읽을 필요 없이, 지도에서 깜빡이는 곳을 보면 됩니다. 지속 시간을 5초처럼 정해 두거나 조건이 풀릴 때까지 유지하도록 설정할 수 있습니다.
이 두 앱의 차이가 곧 ORBRO OS가 경고를 다루는 방식입니다. 급한 것은 소리와 진동으로, 상태는 화면의 색으로. 두 가지를 같은 알림 목록에 밀어 넣으면 결국 아무도 목록을 보지 않게 됩니다.
한 가지 덧붙이면, Zone Effect가 반응하는 '조건'은 위치추적 앱 안에만 있는 개념이 아닙니다. ORBRO OS의 조건은 긴급, 경고, 주의, 관심, 정상 다섯 등급으로 관리되고, 하나의 조건이 알림과 화면 효과와 대응 절차 세 갈래로 동시에 쓰입니다. 이 구조는 AI 앱을 다룬 글에서 자세히 살펴보겠습니다.
Ⅳ. 지나간 뒤에 묻는 질문
관제의 절반은 실시간이지만, 나머지 절반은 사후입니다. 사고가 났을 때, 재고가 사라졌을 때, 동선을 개선하려 할 때 필요한 것은 지금이 아니라 그때입니다.
Timeline은 태그 하나를 기준으로 하루를 되짚습니다. 그 태그가 어느 시간에 어느 구역에 있었는지 시간축 그래프로 보여 주고, 구역별로 얼마나 머물렀는지를 엑셀로 정리해 줍니다. 구역 단위의 이력이라 읽기 쉽습니다.
Record는 더 촘촘합니다. 이름 때문에 영상 녹화로 오해받곤 하는데, Record가 저장하는 것은 위치 데이터입니다. 공간과 시간을 정해 1시간부터 12시간까지 기록해 두면, 나중에 그 시간대의 움직임을 지도 위에서 재생할 수 있습니다. 배속 조절도 됩니다. 구역 단위가 아니라 좌표 단위라서, 구역 경계 안에서 정확히 어떻게 움직였는지까지 보입니다.
둘의 관계는 이렇게 정리됩니다. 어디에 얼마나 있었나는 Timeline, 어떻게 움직였나는 Record. 사고 조사에서는 대개 둘을 함께 봅니다.
Heatmap은 개체가 아니라 공간을 봅니다. 기간을 정하면 그동안 활동이 집중된 자리를 도면 위 밀집도로 칠해 줍니다. 시간 구간별로 나눠 재생할 수 있고, 그 변화를 GIF로 내보낼 수도 있습니다. 어느 통로가 실제로 붐비는지, 설비 앞에 사람이 얼마나 서 있는지처럼 도면만 봐서는 알 수 없는 것이 여기서 드러납니다.
다만 Heatmap의 조회 범위는 오늘을 포함한 최근 8일입니다. 월 단위 비교가 필요하다면 주기적으로 내보내 따로 보관하는 운영이 필요합니다. 숨길 이유가 없는 제약이라 미리 말씀드립니다.
Ⅴ. 신원이 필요한 순간 — Access
지금까지의 아홉 개 앱에는 공통점이 하나 있습니다. 누구인지 묻지 않는다는 것입니다. 위치 데이터는 태그와 카테고리로 움직일 뿐, 그 사람이 김 아무개인지 확인하지 않습니다. 인원 집계와 동선 분석에는 이 편이 오히려 낫습니다.
그런데 신원이 반드시 필요한 순간이 있습니다. 출입 관리입니다.
Access는 인증 이벤트를 다룹니다. 출입 기기에서 인증이 일어나면 누가 언제 어느 문을 통과했는지 기록하고, 사용자별로 첫 출입 시간, 마지막 출입 시간, 총 체류 시간, 출입 횟수를 집계합니다. 사용자와 그룹과 출입 정책으로 필터링해서 볼 수 있습니다.
엘리베이터 연동도 이 앱이 담당합니다. 연결 규칙을 등록해 두면 출입 인증과 동시에 해당 층으로 가는 호기가 호출됩니다. 사람이 버튼을 누르지 않아도 되는 구조입니다.
In-out Tracking과 Access는 언뜻 비슷해 보이지만 성격이 다릅니다. In-out Tracking은 인증 없이 흐름을 세고, Access는 인증으로 신원을 남깁니다. 광장의 유동 인구는 앞쪽으로, 사무실 출입 대장은 뒤쪽으로 다뤄야 합니다. 둘을 겹쳐 보면 건물 전체 체류 시간과 구역별 체류 시간을 대조할 수도 있습니다.
도입할 때 먼저 정할 것
열 개 앱을 다 켜는 현장은 없습니다. 실제로는 이 순서로 정리하는 편이 빠릅니다.
첫째, 구역을 먼저 그립니다. 앱을 고르기 전에 도면을 놓고 운영상 구분해야 하는 단위를 정하는 일이 먼저입니다. 이 작업이 부실하면 뒤의 모든 결과가 부실해집니다.
둘째, 묻고 싶은 질문을 문장으로 씁니다. "3라인에 지금 몇 명 있나"는 Zone Counting, "게이트를 몇 명이 지났나"는 In-out Tracking, "위험구역에 누가 들어왔나"는 Alert Zone입니다. 질문이 정해지면 앱은 저절로 정해집니다.
셋째, 기준선이 있는 앱은 설치 직후 반드시 검증합니다. 앞서 말한 방향 문제 때문입니다.
마치며
위치추적 시스템의 값어치는 점이 얼마나 정확하게 찍히느냐로만 결정되지 않습니다. 그 점이 지나간 자리에 어떤 의미가 부여되어 있느냐가 절반입니다.
열 개의 앱 중 아홉 개가 첫 번째 앱이 그은 선 위에서 동작합니다. 세는 것도, 경고하는 것도, 되짚는 것도 전부 구역이 있어야 성립합니다. 그래서 ORBRO OS에서 위치추적 도입의 첫날은 태그를 나눠 주는 날이 아니라, 도면을 펴 놓고 여기서부터 저기까지가 한 구역이라고 합의하는 날입니다.
카메라 이야기는 따로 있습니다. 사람이 지켜보지 않아도 현장을 읽는 AI 앱 네 개와, 무언가를 발견한 다음에 실제로 무슨 일이 일어나야 하는가를 다룬 글입니다.
현장에 맞는 구역 설계부터 함께 검토하고 싶으시다면, ORBRO에 문의해 주세요.

