공장 바닥 추적 프로젝트를 시작한 지 몇 달이 지났을 무렵, 운영 팀의 한 팀원이 대시보드를 살펴보더니 아주 무덤덤한 어조로 물었습니다. "왜 이 지게차가 4초 만에 건물 전체를 순간이동했죠?"\n\n순간이동을 한 것은 아니었습니다. 하지만 데이터는 그렇게 말하고 있었습니다. 이 포스트에서는 실시간 산업용 센서 위치 데이터를 다룰 때 발생하는 구체적인 데이터 품질 문제와, 테스트 단계에서는 괜찮아 보였지만 실제 운영 환경(production)에서 실패했던 방식이 아닌, 실제로 효과가 있었던 해결책들을 다룹니다.\n\n## 문제 1: 움직임처럼 보이게 만드는 클록 드리프트 (Clock drift)\n\n"순간이동하는 지게차"는 시계가 약 6초 정도 차이 나는 두 개의 RTLS 앵커(anchor) 때문에 발생했습니다. 앵커 A의 14:03:58(앵커 시간) 읽기 값과 앵커 B의 14:04:02(앵커 시간) 읽기 값을 단순히 타임스탬프(timestamp) 순으로 정렬하자, 자산이 1초도 안 되는 짧은 시간 동안 80미터를 이동한 것처럼 나타났습니다.\n\n해결책: 여러 물리적 판독기(reader)로부터 읽어온 데이터의 순서를 정할 때 장치가 보고하는 타임스탬프에 의존하지 마세요. 모든 데이터는 에지 게이트웨이(edge gateway)나 브로커(broker)에 수집될 때 시간을 기록하고, 판독기의 시계가 정확하다고 가정하는 대신 주기적으로 신뢰할 수 있는 소스(NTP가 동기화된 게이트웨이 등)에 장치 시계를 동기화하세요.\n\n\n# 단순한 방식 (클록 드리프트 발생 시 깨짐)\nevent["timestamp"] = raw_read["device_reported_time"]\n# 더 견고한 방식\n...\n\n\n## 문제 2: "신호 없음"은 "부재"와 같지 않다\n\n초기에 우리의 점유 분석(occupancy analytics) 결과는 클린룸이 15~20분마다 완전히 비워진다는 것을 시사했는데, 이는 현장 관리자들의 관찰 결과와 모순되었습니다. 근본 원인은 BLE 비콘(beacon)의 드롭아웃(dropout)이었습니다. 작업자들이 떠난 것이 아니라, 그들의 배지가 단순히 스캔 주기(scan cycle)를 놓친 것이었습니다.\n\n해결책: 모든 누락된 핑(ping)을 이탈을 의미하는 이벤트로 처리하는 대신, 존재 여부를 모델링할 때 유예 기간(grace period)을 구현하세요. 작업자는 단일 핑이 유실된 즉시가 아니라, 예상되는 신호 간격(signal gap)을 초과하는 기간 동안 관찰되지 않을 때까지 "존재"하는 것으로 간주해야 합니다.

def is_still_present(last_seen, now, grace_period_seconds=90):
    return (now - last_seen).total_seconds() < grace_period_seconds

이러한 한 가지 조정만으로도 잘못된 "구역 비어 있음 (zone empty)" 알림의 수가 크게 감소했습니다. 지나고 보면 당연해 보이지만, 초기 프로토타입에서 단순히 지도 위에 가공되지 않은 핑 (raw pings)을 표시할 때는 간과하기 쉽습니다.

문제 3: 완전한 "도착 (arrivals)"라고 보기 어려운 RFID 판독

출입구 근처에 배치된 수동형 RFID 리더기 (Passive RFID readers)는 카트가 지나갈 때 가끔 태그를 매우 짧은 간격으로 여러 번 읽습니다. 예를 들어 2초 동안 세 번을 읽는 식인데, 기술적으로는 모두 유효하며 단순한 처리 방식(naive processing)을 사용할 경우 모두 "도착"으로 카운트됩니다.

해결책: 하위 프로세스(downstream processes)가 이를 별개의 이벤트로 해석하기 전에, 태그/리더기 쌍(per-tag/reader pair)별로 디바운스 윈도우 (debounce window)를 사용하여 이벤트 수준에서 판독 데이터를 중복 제거(Deduplicate)합니다.

def should_emit_event(tag_id, reader_id, last_event_time, now, debounce_seconds=5):
    key = (tag_id, reader_id)
    if key not in last_event_time:
...

이 처리가 없다면, 하위 카운트(예: 이 카트가 오늘 이 체크포인트를 몇 번 방문했는지)가 부풀려지며, 누군가가 현장 수량과 수동으로 대조하여 불일치를 발견하기 전까지는 이를 감지하기 어렵습니다.

문제 4: 신뢰도는 이진적이지 않다

우리의 사고방식에서 핵심적인 변화는 BLE 또는 RTLS로부터 얻은 위치 "고정 (fix)"이 확정적인 것이 아니라, 신뢰 수준 (confidence level)을 동반하는 추정치라는 점을 받아들인 것이었습니다. 이는 대개 RSSI 및 관련된 앵커 (anchors)나 비콘 (beacons)의 수와 같은 요인에 의해 결정됩니다.

모든 위치 추정치를 동일하게 신뢰할 수 있는 것으로 취급하면, (예를 들어 금속 장비의 반사로 인해 발생하는) 간헐적인 잘못된 판독이 태그를 잠시 잘못된 구역에 위치시키면서 잘못된 알림을 유발했습니다. 데이터 파이프라인 (data pipeline)을 통해 신뢰도 점수 (confidence score)를 전달하고, 해당 점수가 미리 정의된 임계값 (threshold)을 초과할 때만 하위 동작을 트리거함으로써, 우리는 거짓 양성 (false positive) 알림을 크게 줄일 수 있었습니다.

def is_actionable(location_event, min_confidence=0.7):
    return location_event["confidence"] >= min_confidence

문제 5: 파일럿 구역에서 작동하던 모델이 일반화되지 않음

하나의 조립 라인 데이터를 사용하여 개발된 혼잡 예측 모델 (congestion prediction model)은 해당 맥락에서는 잘 작동했지만, 레이아웃과 교대 근무 일정이 다른 두 번째 라인에 배포되었을 때는 성능이 저하되었습니다.

해결책: 보편적인 모델이 효과적으로 전이 (transfer)될 것이라고 가정하는 대신, 각 구역의 기준 트래픽 패턴 (baseline traffic pattern)을 하나의 특성 (feature)으로 간주하십시오. 구역별로 간단한 정규화 (normalisation) 기술을 적용하는 것만으로도 (예: 공장 전체 평균이 아닌 해당 구역의 과거 기준치와 현재 트래픽을 비교하는 방식), 모델의 복잡성을 높이는 것보다 일반화 (generalisation) 성능을 더 많이 향상시킬 수 있었습니다.

핵심 교훈

이러한 문제들 중 특별히 새로운 것은 없었습니다. 본질적으로 이 모든 문제는 "데이터가 데모에서 보여준 것처럼 깨끗하지 않다"라는 주제의 변형일 뿐이었습니다. 해결책은 고급 알고리즘에 기반한 것이 아니라, 머신러닝 (machine learning)을 적용하기 전에 클록 드리프트 (clock drift), 신호 공백 (signal gaps), 중복 (duplicates), 그리고 신뢰도 (confidence)와 관련된 데이터 파이프라인 (data pipeline) 문제를 정직하게 다루는 데 있었습니다.

만약 유사한 시스템을 구축 중이며, 이 엔드투엔드 (end-to-end) 정규화 계층(데이터가 정제된 후의 ERP/MES 통합 포함)을 처리하는 방법에 대한 포괄적인 참고 자료를 찾고 있다면, PlantLog AI에서 공장 내 물류를 위해 RFID, BLE, UWB 및 RTLS 데이터를 결합하는 방식에 대해 분석한 내용을 확인해 보십시오. 이는 가치 있는 비교 지점이 될 것입니다.

산업용 센서 데이터와 관련하여 여러분이 경험한 다른 실패 사례들에 대해 듣고 싶습니다. 댓글을 통해 경험을 공유해 주세요!