[실패사례] 센서·데이터 구조 실패
PoC는 성공했지만,
현장에서는 신뢰할 수 없었던 시스템
기술 문제가 아니라 데이터 구조 문제였습니다.
프로젝트 개요
적용 분야
시스템 구성
프로젝트 목표
결과
스마트팩토리 / 자동 검사 시스템
다중 센서 · MCU · 데이터 수집 서버
실시간 품질 판별
PoC 성공 → 현장 적용 중단
왜 처음에는 문제가 없어 보였는가
실험실 환경에서는 ‘문제가 없어 보이는’ 조건만 확인했기 때문입니다.
첫째, 테스트 환경의 데이터는 제한적이었습니다.
센서 노이즈, 설치 오차, 환경 변화가 충분히 반영되지 않았습니다.
둘째, 데이터 수집 방식이 현장 운영을 고려하지 않았습니다.
운영 중 발생하는 누락, 지연, 이상 데이터에 대한 설계가 없었습니다.
셋째, PoC 단계의 성공 기준이 너무 단순했습니다.
“동작한다”는 것만으로, “현장에서 신뢰할 수 있는가”는 검증되지 않았습니다.
현장에서 드러난 실제 문제
문제는 센서 성능이나 알고리즘이 아니라, 데이터가 만들어지고 흘러가는 구조에 있었습니다.
첫째, 센서 데이터의 기준점이 현장마다 달랐습니다.
설치 위치, 캘리브레이션 방식, 기준 신호가 통일되지 않아
같은 상태에서도 서로 다른 데이터가 생성되었습니다.
둘째, 정상과 이상을 구분하는 데이터 정의가 없었습니다.
어떤 값이 ‘정상’인지, 어느 시점부터 ‘이상’인지
데이터 레벨에서 합의된 기준이 존재하지 않았습니다.
셋째, 운영 중 발생하는 데이터 변화가 구조에 반영되지 않았습니다.
시간 경과에 따른 드리프트, 환경 변화, 장비 노후로 인한 변화가
데이터 구조상 고려되지 않았습니다.
이 문제는 왜 현장에서 해결되지 못했는가
이 문제는 특정 팀이나 개인의 역량 부족 때문이 아니었습니다.
첫째, 문제는 특정 모듈이 아니라 전체 흐름에 걸쳐 있었습니다.
센서, 제어, 데이터 처리, 운영이 각각 분리되어 있어
어느 한 팀도 전체 구조를 책임지고 볼 수 없었습니다.
둘째, 각 팀은 자신의 영역에서는 ‘정상’을 기준으로 판단했습니다.
센서는 사양을 만족했고, 제어는 요구 성능을 달성했으며,
데이터 분석 역시 주어진 입력에서는 정상적으로 동작했습니다.
셋째, 현장에서 발생하는 문제는 경계 영역에서 나타났습니다.
데이터가 넘어가는 지점, 책임이 모호한 지점에서는
누구도 문제를 정의하거나 구조를 수정하지 못했습니다.
어떻게 접근했는가
이 문제를 해결하기 위해, 기술을 추가하기 전에 시스템 전체를 다시 이해하는 것부터 시작했습니다.
첫째, 데이터가 생성되는 지점부터 흐름을 다시 정리했습니다.
센서 설치 위치, 기준 신호, 수집 주기, 저장 방식까지
데이터가 만들어지는 전 과정을 구조적으로 점검했습니다.
둘째, 데이터가 전달·변환되는 과정의 책임을 명확히 했습니다.
어느 지점에서 어떤 데이터가 만들어지고,
누가 그 의미를 정의하는지 역할을 다시 정리했습니다.
셋째, 현장에서 유지될 수 있는 기준만 남겼습니다.
실험실에서만 성립하는 조건은 제거하고,
운영 중에도 반복 검증 가능한 구조로 재정의했습니다.
그 결과, 무엇이 달라졌는가
시스템이 ‘동작하는지’가 아니라, 현장에서 ‘판단할 수 있는 상태’로 바뀌었습니다.
첫째, 데이터의 기준이 현장에서 동일하게 유지되었습니다.
설치 환경이 달라도 같은 조건에서는 같은 의미의 데이터가
생성되고 해석될 수 있는 구조가 마련되었습니다.
둘째, 정상과 이상에 대한 판단 기준이 명확해졌습니다.
현장에서 어떤 상태가 ‘문제’인지,
언제 대응해야 하는지가 데이터 기준으로 공유되었습니다.
셋째, 운영 중 변화에 대응할 수 있는 여지가 생겼습니다.
환경 변화나 장비 노후가 발생하더라도,
데이터 구조 자체가 이를 감지하고 점검할 수 있게 되었습니다.
이런 문제가 반복되고 있지 않습니까?
기술은 계속 보완하고 있는데,
현장에서는 여전히 같은 문제가 반복되고 있다면
그 원인은
기술이 아닐 수 있습니다.
구체적인 기술이나 제품을
처음부터 설명하지 않아도 괜찮습니다.
문제의 구조부터 함께 정리합니다.