온라인상의 대부분의 자산 추적 가이드는 연결성을 신뢰할 수 있다고 가정합니다. 하지만 하드웨어의 현실은 동일한 보장을 제공하지 않습니다. GPS 트래커가 터널로 들어 가거나, LoRaWAN 장치가 게이트웨이(Gateway)의 범위 끝에 있거나, 일련의 BLE 비콘(Beacon)에 전력을 공급하는 실내 게이트웨이가 시설 전체 정전 중에 꺼지는 경우가 발생합니다. 만약 원격에서 발생하는 모든 이벤트가 백엔드(Backend)에 즉시 안정적으로 반영된다고 가정하지 않고서는 타임라인을 재구성할 수 없다면, 감사(Auditing)나 사고 조사(Incident investigations)는 언젠가 제대로 작동하지 않을 것입니다. 이 포스트에서는 불안정한 연결성 상황에서도 무너지지 않는 Store-and-Forward (저장 후 전달) 패턴에 대해 살펴봅니다.

단순히 "재시도(Retry)"하는 것은 전략이 아니다

가장 명백한 첫 번째 단계는 데이터가 전달될 때까지 장치나 게이트웨이가 단순히 재시도하도록 하는 것입니다. 이는 필요한 구성 요소이지만, 그 자체만으로는 충분하지 않습니다. 그 이유는 다음과 같습니다:

• 배터리로 구동되는 IoT 장치는 몇 달 또는 몇 년 동안 지속되도록 설계된 전력을 소진하기 전에 무한정 재시도할 수 없습니다.
• 장치에 로컬 버퍼(Local buffer)가 없다면, 오프라인 상태에서 생성된 모든 데이터는 재전송(Re-send) 창이 만료된 후 그대로 유실(Lost)됩니다.
• 조정되지 않은 재시도는 백엔드에 명시적인 중복 제거(Deduplication) 로직이 없다면 종종 중복 계산(Double counts)을 초래합니다.

시스템의 장치 또는 게이트웨이 측에는 일종의 버퍼링(Buffering)이 필요하며, 백엔드에는 멱등적 수집(Idempotent ingestion)이 필요합니다. 하나라도 없으면 데이터 유실이나 데이터 손상이 발생하며, 이는 유실만큼이나 혹은 그보다 더 나쁩니다.

로컬 버퍼링: 무엇을, 얼마나 저장할 것인가?

원격에서 발생하는 모든 이벤트가 동일한 우선순위를 갖거나 로컬 저장 공간에서 동일한 용량을 차지하는 것은 아닙니다. 이 문맥에서 유용한 접근 방식은 다음과 같습니다:

• 우선순위는 높고 빈도는 낮은 데이터 (예: 지오펜스(geofence) 이탈, 임계값 위반, RFID 읽기). 이러한 유형의 이벤트는 수천 개가 쌓여도 저장 공간을 초과할 만큼 빈번하지는 않지만, 유실될 경우 매우 치명적입니다.
• 우선순위는 낮고 빈도는 높은 데이터 (예: 30초마다 발생하는 위치 핑(ping), 임박한 임계값 위반이 없는 주변 센서 값). 이러한 유형의 데이터는 순환 용량(rolling capacity) 방식의 이점을 얻습니다. 버퍼가 가득 차면 가장 오래된 일상적인 핑을 삭제해도 안전할 가능성이 높습니다. 놓쳐도 별다른 문제가 없는 30초 단위의 위치 핑은 지오펜스 진입 이벤트를 놓치는 것보다 대개 덜 중요합니다.

왜 이를 구분해야 할까요? 저가형 IoT 하드웨어는 일반적으로 로컬 저장 공간이 제한적입니다. 버퍼가 우선순위 고려 없이 맹목적이고 균일하게 채워지면, 우선순위가 낮은 잡음(chatter)이 우선순위가 높은 중요한 이벤트를 밀어내는 경우가 빈번합니다.

on_connectivity_lost():
    switch_to_local_buffer_mode()

...

멱등적 수집 (Idempotent Ingestion): 중복 방지

연결이 재개되었을 때 버퍼 내용을 전송하기 시작할 때, 만약 확인 응답(ack)이 유실되어 연결이 복구된 후 장치가 동일한 데이터 패킷을 다시 전송한다면 어떻게 해야 할까요? 또는 오프라인 상태에서 데이터가 전송되었고 확인 응답을 받았지만, 어떤 이유로 기록이 다시 누락되었다면 어떻게 될까요? 확인 응답이 유실되었다는 것은 무언가 중복되었다는 것을 의미하지만, 무언가 유실되었을 때 유일하게 좋은 옵션은 그것을 재전송하는 것입니다. 중복을 제거(de-duplicate)하는 것은 백엔드의 문제입니다.

다행히 이 문제는 해결 가능합니다. 모든 이벤트에는 일반적으로 장치 ID(device ID), 일련번호(sequence number), 타임스탬프(timestamp)로 구성된 클라이언트 측 고유 식별자(unique identifier)가 포함됩니다. 그런 다음 백엔드의 수집 지점(ingestion point)은 unique_id가 이미 존재하면 업데이트(upsert)하고, 그렇지 않으면 단순히 삽입(insert)하도록 구성됩니다.

on_ingest(event):
    if event_store.exists(event.unique_id):
        return ACK  // 이미 처리됨, 재처리하지 않음
...

만약 Upsert(업서트)를 수행하지 않는다면, 버퍼 재생(buffer playback) 도중에 네트워크 중단이 발생할 경우 해당 자산(asset)에 대한 많은 이벤트가 소리 없이 중복 처리될 수 있습니다. 이는 임계값 위반에 대한 알림이 중복으로 울리거나, 이력(history) 내 동일한 위치 포인트가 중복 기록되어, 자산 이력의 분석적 활용을 손상시키는 결과를 초래합니다.

시퀀스 번호(Sequence Numbers)가 타임스탬프(Timestamps)보다 나은 이유

대부분의 하드웨어는 연결이 끊겼을 때 시계(clock)를 정밀하게 유지하지 못합니다. 저가형 IoT 기기는 며칠 또는 몇 주에 걸쳐 드리프트(drift, 시간 오차)가 발생할 수 있으며, 며칠 동안 오프라인 상태로 지낸 후 기기가 마침내 재연결되었을 때 시계가 당혹스러울 정도로 오래된 상태일 수 있습니다. 이를 방지하기 위해, 기기는 타임스탬프 외에도 기기별로 자체적인 단조 시퀀스 번호(monotonic sequence number)를 유지해야 합니다.

이를 통해 시계가 어긋나거나 심하게 불일치하더라도, 재전송된 메시지에 대해 항상 정확히 동일한 재생(playback)을 재구성할 수 있습니다.

타임스탬프와 시퀀스 번호가 크게 차이 날 경우, 알림을 생성하고 조사할 수 있도록 준비하십시오.

피할 수 없는 공백(Gap)에 대비하기

오늘날까지도 테스트 및 개발 과정에서의 한 가지 함정은 해피 패스(happy path, 정상 경로) 시나리오에만 집중하는 것입니다. 즉, 기기가 연결을 잃었다가 다시 온라인 상태가 되어 아무런 문제 없이 모든 이벤트를 우아하게 재전송하는 경우만을 가정하는 것입니다. 여러분은 또한 다음과 같은 상황에 대해 테스트하고 대비해야 합니다:

• 버퍼 재생 중에 기기가 복구되었다가 다시 연결을 잃는 경우
• 기기가 오프라인 상태인 동안 버퍼가 용량에 도달하여 가득 차는 경우
• 오프라인 상태에서 기기의 NVRAM(비휘발성 메모리)을 상실하는 경우
• 오프라인 상태에서 배터리를 소진하는 경우
• 오프라인 상태에서 기기가 리셋되는 경우
• 버퍼가 재생되는 동안 연결된 상태에서 기기가 리셋되는 경우
• 버퍼가 백엔드로 재생되는 동안 기기가 오프라인 상태에서 재할당되거나 퇴역하는 경우

궁극적으로, 회복 탄력성 있는 데이터 수집 (Data Ingestion) 전략을 설계하고 실행하는 것은 다른 종류의 원격 수집 데이터에도 동일하게 적용되지만, 추적 및 이력 이벤트 데이터 (Historical Event-data) 시나리오에서는 특히 중요합니다. 전체 가치 제안 (Value Proposition)이 이 이력 데이터의 무결성 (Integrity)에 달려 있기 때문입니다. 하드웨어를 찾는 분들을 위해, AssetTrackPro는 자사의 식별 기반 자산 태그 (Identification-based asset tags)와 게이트웨이 (Gateways)가 이러한 종류의 로컬 버퍼링 (Local buffering) 문제를 어떻게 즉시 해결하는지를 포함한 포괄적인 목록을 제공하고 있습니다.

버퍼 재생 (Buffer replay)을 관리하면서, 특히 지오펜싱 (Geofencing) 및 상태 머신 (State machines)과 관련하여 어떤 문제에 직면하셨나요? 기기가 "구역 이탈 (Exited zone)" 이벤트를 재생하고 있는 동안, 해당 구역에 이미 다시 진입한 상태라면 이를 어떻게 관리하시나요?