"이 부품을 누가 설치했으며, 언제 테스트했습니까?"라는 질문은 단순하게 들릴 수 있습니다. UAV (무인 항공기) 제조에서, 사건 발생 6개월 후 새벽 2시에 감사관 앞에서 이 질문에 신뢰할 수 있게 답변하는 것은 진정으로 어려운 데이터 엔지니어링 (Data Engineering) 문제입니다. 저는 DroneForge AI와 같은 팀들이 이 문제에 어떻게 접근하는지 살펴보았으며, 이는 "추적성 (Traceability)"이 내부적으로 실제로 무엇을 요구하는지에 대한 좋은 사례 연구입니다.

핵심적인 실수: 상태를 가변적(Mutable)으로 취급하는 것

가장 흔한 실패 모드는 부품의 이력을 가변적인 상태 필드 (Mutable status field)로 모델링하는 것입니다:

// 취약함: 이력을 덮어쓰며, 감사 추적(Audit trail)이 남지 않음
component.status = "installed"
component.installed_by = operator_id
...

이 방식은 "이전 상태는 무엇이었습니까?" 또는 "이 부품이 나중에 통과했더라도, 테스트 중에 플래그(Flag)가 지정된 적이 있습니까?"라는 질문이 나오기 전까지는 잘 작동합니다. 가변 필드를 사용하면 해당 이력은 그냥 사라져 버립니다.

해결책은 추가 전용 이벤트 로그 (Append-only event log)를 사용하는 것입니다:

// 내구성 있음: 모든 상태 변경은 새로운 이벤트이며, 아무것도 덮어쓰지 않음
event_log.append({
    "component_id": component.id,
...

현재 상태는 이벤트 로그를 기반으로 도출된 뷰 (Derived view)가 되어야 하며, 신뢰할 수 있는 원천 (Source of truth)이 되어서는 안 됩니다. 이 단 하나의 아키텍처 (Architectural) 선택이 감사 질의에 답할 수 있는 시스템과 그렇지 못한 시스템을 가르는 차이점입니다.

교정 주기(Calibration Windows)는 일급 제약 조건(First-Class Constraint)이다

테스트 장비—RF 계측기, 환경 챔버, NDT (비파괴 검사) 장치—에는 교정 주기 (Calibration windows)가 있습니다. 교정 범위를 벗어난 장비로 수행된 테스트는 감사 목적으로 유효한 테스트가 아닙니다. 이는 모든 테스트 이벤트가 단순히 합격/불합격 결과뿐만 아니라 교정 확인 (Calibration check) 정보를 반드시 포함해야 함을 의미합니다:

// 사후가 아니라 테스트 시점에 교정 상태를 검증함
def record_test_event(equipment_id, component_id, result):
    calibration = calibration_registry.get_status(equipment_id)
...

교정 유효성을 소급하여 확인하는 것은 쓰기 시점 (Write-time)에 캡처하는 것보다 훨씬 어렵습니다. 누군가 질문을 던질 때쯤이면 교정 기록은 이미 갱신되어 사라졌을 수도 있기 때문입니다.

예측 유지보수(Predictive Maintenance)는 동일한 이벤트 로그(Event Log)에 대한 시계열 분석(Time-Series Analysis)일 뿐입니다

제가 진정으로 우아하다고 느끼는 부분은 바로 이 지점입니다. 추적성(Traceability)을 위해 구축된 이벤트 로그가 예측 유지보수(Predictive Maintenance)를 위한 입력값으로도 사용된다는 점입니다. 별도의 추적 시스템이 필요하지 않습니다.

// 동일한 추가 전용(append-only) 로그로부터 사용 시간 트렌드를 도출
usage_events = event_log.filter(equipment_id=equipment_id, event_type="usage_session")
hours_since_last_service = sum(e.duration for e in usage_events 
...

별도의 유지보수 추적 파이프라인을 실행하는 대신, 감사인(Auditor)을 만족시키는 동일한 내구성이 있고 타임스탬프(Timestamp)가 찍힌 이벤트 스트림(Event Stream)이 장비 고장을 예측하는 모델에도 데이터를 공급합니다. 하나의 데이터 모델이 매우 다른 두 가지 소비자(Consumer)를 충족하는 것입니다.

모델의 정교함보다 쿼리(Query) 설계가 더 중요합니다

놓치기 쉬운 미묘한 지점이 있습니다. 이 시스템에서 어려운 부분은 이상 징후(Anomaly)를 식별하는 AI 모델이 아니라, "이 부품을 만진 모든 사람과 모든 것을 보여달라"는 기본 쿼리(Query)가 합리적인 시간 내에 실제로 완전한 답변을 반환하도록 보장하는 것입니다. 즉, 다음을 의미합니다:

• 감사 쿼리는 양방향("이 부품을 무엇이 만졌는가" 및 "이 사람/스테이션이 무엇을 만졌는가")으로 진행되므로, component_id와 station_id 모두를 기준으로 이벤트 로그를 인덱싱(Indexing)해야 합니다.
• 감사 시점의 압박 속에서 전체 부품 이력을 확인하기 위해 수십 개의 조인(Join)이 필요하지 않도록, 적절한 수준의 비정규화(Denormalization)를 수행해야 합니다.
• 이상 징후 플래그(Anomaly flags)를 별도의 동기화가 어긋날 수 있는 사이드 테이블(Side table)이 아니라, 동일한 로그 내의 일급 이벤트(First-class events)로 취급해야 합니다.

왜 이곳에서 이 정도 수준의 엄격함이 정당화되는가

대부분의 제조 추적 시스템은 최종 일관성(Eventual consistency)과 최선 노력(Best-effort) 방식의 로깅을 허용할 수 있습니다. 하지만 UAV 제조는 일반적으로 이를 허용할 수 없습니다. 답변할 수 없는 감사 질문에 대한 비용이 매우 높기 때문에, 추가적인 엔지니어링 규율(추가 전용 로그(Append-only logs), 쓰기 시점 교정 확인(Write-time calibration checks), 컴플라이언스 및 예측을 위한 통합 이벤트 스트림(Unified event streams))을 도입하는 것은 분명히 그만한 가치가 있습니다.

다른 사람들은 대규모 환경에서 append-only 이벤트 로그 (append-only event logs)와 쿼리 성능 (query performance) 사이의 트레이드오프 (tradeoff)를 어떻게 처리했는지 궁금합니다. 비정규화된 읽기 모델 (denormalized read models), CQRS, 혹은 다른 방법을 사용하셨나요? 서로의 경험을 공유할 수 있다면 좋겠습니다.

aiot #iot #manufacturing #dataengineering #uav