증거 우선, 답변 후순위: SigNoz를 활용한 관측 가능한 산업용 AI 에이전트 구축

대부분의 AI 시스템은 답변을 제공하도록 설계되었습니다.

챗봇에서는 그것이 유용합니다. 하지만 공장 현장에서는 위험할 수 있습니다.

**산업용 IoT 이상 제어 (Industrial IoT Anomaly Control)**를 구축하면서, 저는 한 가지 질문으로 계속 되돌아갔습니다:

AI 에이전트가 실제 문제를 감지했지만, 그 원인을 안전하게 설명할 수 있는 충분한 증거가 없을 때 어떻게 해야 하는가?

제 답변은 간단했습니다. 멈추고, 알고 있는 것을 보여준 뒤, 해당 사례를 사람에게 전달해야 합니다.

이 프로젝트는 시뮬레이션된 수처리 시설을 위한 실시간 모니터링 시스템입니다. 이 시스템은 6개의 산업 자산(industrial assets)으로부터 실시간 센서 데이터를 스트리밍하고, 비정상적인 동작을 감지하며, 지식 베이스(knowledge base)에서 유사한 사례를 검색한 다음, 다음 두 가지 경로 중 하나를 선택합니다:

• 증거가 확실할 때는 안전한 조치를 권장합니다.
• 증거가 불충분할 때는 사람의 검토를 위해 에스컬레이션(escalate)합니다.

SigNoz는 이러한 결정 과정을 가시화(visible)해 주는 역할을 합니다. 최종적인 AI 응답만을 보는 대신, 들어오는 센서 판독값부터 이상 감지(anomaly detection), 지식 검색(knowledge retrieval), 정책 확인(policy checks), 에이전트 설명(agent explanation), 그리고 복구(recovery)에 이르는 전체 경로를 조사할 수 있습니다.

전통적인 알람의 문제점

공장들은 이미 진동, 온도, 습도, 시퀀스 번호, 타임스탬프와 같은 방대한 양의 텔레메트리(telemetry) 데이터를 수집하고 있습니다.

문제는 데이터가 부족한 것이 아닙니다. 문제는 그 데이터를 유용한 결정으로 전환하는 것입니다.

전통적인 임계값(threshold) 알람은 다음과 같이 말할 수 있습니다:

진동이 설정된 제한치를 초과했습니다.

이는 여전히 운영자에게 다음과 같은 여러 질문을 남깁니다:

• 기계가 실제로 고장 나고 있는가?
• 센서나 게이트웨이(gateway)가 잘못된 데이터를 보내고 있는가?
• 이 패턴이 이전에 발생한 적이 있는가?
• 유지보수를 권장할 만큼 충분한 증거가 있는가?
• AI가 왜 이러한 결론에 도달했는가?

반복되는 임계값 경고는 알람 피로(alarm fatigue)를 유발할 수도 있습니다. 하나의 결함이 수십 개의 경고를 생성하면, 운영자는 이를 소음(noise)으로 취급하기 시작할 수 있습니다.

저는 시스템이 또 다른 알람의 홍수를 만드는 대신, 단 하나의 조사(investigation)를 생성하기를 원했습니다.

내가 구축한 것

이 데모는 수처리 시설(water-treatment plant) 내 6개의 자산(assets)을 나타냅니다. TCP 시뮬레이터는 정상 모드(healthy mode)로 실행되거나, 재현 가능한 장비 및 데이터 품질 문제를 생성하는 시드된 결함 모드(seeded faulty mode)로 실행될 수 있습니다.

시스템은 다음 사항을 감지합니다:

• 갑작스러운 진동 스파이크 (vibration spikes)
• 점진적인 진동 드리프트 (vibration drift)
• 누락되거나 간헐적인 판독값 (missing or intermittent readings)
• 중복 이벤트 (duplicate events)
• 시퀀스 간격 (sequence gaps)
• 오래되거나 역전된 타임스탬프 (stale or reversed timestamps)

한 가지 설계 결정이 매우 중요해졌습니다: 잘못된 원격 측정(bad telemetry)은 고장 난 기계와 동일하지 않다는 점입니다. 중복 이벤트와 시퀀스 간격은 데이터 품질 사고(data-quality incidents)가 되며, 결코 기계적 권장 사항(mechanical recommendations)으로 전환될 수 없습니다.

관련된 비정상 판독값들은 하나의 조사(investigation)로 그룹화되어, 모든 판독값마다 새로운 알람이 발생하는 것을 방지합니다.

에이전트가 지식을 사용하는 방법

시스템이 장비 상태 사고(equipment-condition incident)를 감지하면, 구조화된 수처리 시나리오를 포함하는 Chroma 지식 베이스(knowledge base)를 검색합니다.

검색은 유사도 매칭(similarity matching) 전에 필터링됩니다. 관련 없는 사고가 증거가 되는 것을 방지하기 위해 장비 유형(equipment type), 센서 유형(sensor type), 사고 카테고리(incident category)가 사용됩니다.

예를 들어, 원심 펌프(centrifugal pump)의 진동 문제는 다른 자산의 습도 문제로 설명되어서는 안 됩니다.

검색(retrieval) 단계에서는 가장 강력한 매칭 결과, 유사도 점수(similarity scores), 검증 상태(verification status), 그리고 첫 번째 결과와 두 번째 결과 사이의 간격(gap)을 반환합니다. 이 부분이 제 프로젝트가 기본적인 RAG 애플리케이션과 다른 점입니다.

전통적인 RAG 흐름은 대개 다음과 같습니다:

질문(Question) → 문서 검색(Retrieve documents) → 답변 생성(Generate an answer)

제 흐름은 이에 더 가깝습니다:

이상 징후(Anomaly) → 증거 수집(Collect evidence) → 사고 검색(Retrieve incidents) → 신뢰도 확인(Check confidence)
        → 권장 또는 에스컬레이션(Recommend or escalate) → 승인된 결과 설명(Explain the approved result)

에이전트는 검색된 모든 문서를 충분한 증거로 취급하는 것이 허용되지 않습니다.

LLM은 안전 결정권을 갖지 않는다

저는 모델에게 신뢰도 수치(confidence number)를 생성하라고 요청하지 않았습니다.

언어 모델은 "95% 확신합니다"라고 반환할 수 있지만, 그 숫자는 검증된 확률을 나타내지 않을 수 있습니다. 산업용 유스케이스(industrial use case)에서 이는 안전한 결정 규칙이 아닙.

대신, 애플리케이션은 측정 가능한 신호로부터 신뢰도(confidence)를 계산합니다:

• 이상 징후의 강도(anomaly strength) 및 지속성(persistence);
• 탐지기(detectors) 간의 일치 여부;
• 현재 데이터 품질;
• 가장 잘 검색된 사례(incident)와의 유사성;
• 첫 번째와 두 번째 매칭 간의 거리;
• 선례(precedent)의 검증 여부;
• 설정된 권장(recommendation) 및 에스컬레이션(escalation) 임계값.

주요 안전 규칙은 다음과 같습니다:

assert not (
    decision == "RECOMMEND"
    and confidence < configured_threshold
...

증거가 정책을 통과하면 시스템은 제한된 점검 조치(bounded inspection action)를 권장합니다. 매칭이 약하거나, 불분명하거나, 검증되지 않았거나, 누락된 경우 결정은 ESCALATE가 됩니다.

LLM은 결과에 대한 설명만을 제공합니다. LLM은 정책을 무시하거나 증거를 조작할 수 없습니다. 제공자(provider)를 사용할 수 없는 경우, 센서 프로세싱이 계속되는 동안 결정론적 폴백(deterministic fallback)이 답변을 제공합니다.

이러한 분리는 이 프로젝트를 통해 얻은 가장 큰 교훈 중 하나였습니다:

애플리케이션이 안전을 책임져야 합니다. 모델은 이를 전달하는 것을 도와야 합니다.

SigNoz를 통해 전체 결정 과정을 가시화하기

관측 가능성(observability)을 추가한다는 것은 "API가 작동 중이다" 또는 "모델이 200 응답을 반환했다"를 넘어선다는 것을 의미했습니다. 저는 에이전트 결정의 품질을 관찰하고 싶었습니다.

애플리케이션은 OTLP HTTP를 통해 OpenTelemetry 트레이스(traces), 메트릭(metrics), 구조화된 인시던트 로그(structured incident logs)를 방출하며, 모니터링을 비즈니스 로직과 분리하여 유지합니다.

일반적인 읽기 작업은 다음과 같은 이름의 루트 스팬(root span)을 생성합니다:

sensor.process

이상 징후 조사 시에는 다음과 같은 구조를 포함할 수 있습니다:

sensor.process
├── detectors.evaluate
├── incident.evaluate
...

첫 번째 정책 결정은 즉시 생성됩니다. 검색(retrieval)과 설명(explanation)은 백그라운드에서 실행되는데, 이는 느린 임베딩(embedding)이나 LLM 호출이 라이브 스트림을 절대 중단시켜서는 안 되기 때문입니다.

트레이스는 다음과 같은 세부 정보를 연결합니다:

• 장비 및 센서 식별 정보;
• 인시던트 ID 및 카테고리;
• 탐지기 이름 및 이상 징후 심각도(anomaly severity);
• 검색된 선례 ID;
• 최종 정책 결정;
• 모델 또는 폴백(fallback) 중 무엇이 설명을 생성했는지 여부;
• 복구 진행 상황.

원시 측정값(Raw measurements), 프롬프트(prompts), 키(keys), 그리고 복구 노트(repair notes)는 텔레메트리(telemetry)에서 의도적으로 제외되었습니다.

에이전트를 이해하는 방식을 바꾼 대시보드

저는 Water Treatment Agent — Trust & Recovery라는 이름의 SigNoz 대시보드를 만들었습니다.

가장 유용한 패널들은 다음과 같습니다:

• 장비별 텔레메트리 처리량(telemetry throughput);
• 탐지기(detector) 활동;
• 권장 및 에스컬레이션(escalation) 횟수;
• 지식 검색(knowledge retrieval) 결과;
• 에이전트 평가 지연 시간(latency);
• 자동 장애 해결(automatic incident resolutions);
• 장애 복구 시간(incident recovery time).

제가 실제로 겪었던 문제 중 하나는 자동 해결(automatic resolutions)에 잘못된 메트릭 축소(metric reduction) 방식을 사용한 것이었습니다. 전체 카운트(total-count) 패널에 비율(rate)을 사용했더니 결과가 비어 있거나 혼란스럽게 나타났습니다. 선택된 범위에 걸친 증가량(increase)을 사용하고 합계(sum)를 표시함으로써 이 문제를 해결했습니다.

저는 문서를 읽기만 해서가 아니라, 실제 텔레메트리를 관찰함으로써 이를 배웠습니다.

또한 에이전트 지연 시간(latency)을 시도된 모드(attempted mode)와 최종 모드(final mode) 모두로 그룹화했습니다.

이를 통해 다음과 같은 사항을 구분할 수 있습니다:

• Mistral을 시도했으나 Mistral로 완료됨;
• Mistral을 시도했으나 결정론적 폴백(deterministic fallback)으로 완료됨;
• 결정론적 모드(deterministic mode)를 직접 사용함.

따라서 폴백(fallback)은 숨겨진 로그 라인이 아니라, 가시적인 운영 신호가 됩니다.

탐지부터 복구까지의 장애 추적

운영자 대시보드는 각 장애(incident)와 함께 W3C 트레이스 ID(trace ID)를 저장합니다.

운영자는 활성화된 장애에서 **SigNoz에서 트레이스 열기(Open trace in SigNoz)**를 클릭하여 전체 조사 단계로 즉시 이동할 수 있습니다.

이는 제품을 관측성(observability)과 직접 연결합니다:

운영자가 장애 확인
→ 정확한 트레이스 열기
→ 탐지기 증거 확인
...

에이전트는 설명을 생성한 후 멈추지 않습니다.

에이전트는 자산(asset)을 계속 감시합니다. 장비 장애는 5회 연속으로 정상 수치가 읽힌 후에만 자동으로 해결됩니다. 복구 스팬(recovery span)은 현재의 정상 카운트와 장애가 안전하게 종료되었는지 여부를 기록합니다.

운영자는 실제 발견 사항과 수정 사항을 기록할 수 있습니다. 이는 검증된 증거를 대체하지 않으면서도 명확하게 라벨링된 로컬 지식(local knowledge)이 됩니다.

내가 배운 것

가장 큰 교훈은 에이전트 관측성 (observability)이 단순히 토큰 수 (token counts)나 모델 지연 시간 (model latency)에 국한되지 않는다는 점이었습니다. 이러한 지표들은 가장 중요한 질문에 답하지 못합니다:

왜 시스템이 특정 행동을 권장할 만큼 충분한 증거가 있다고 판단했는가?

의미 있는 관측성을 위해서는 다음 요소들을 연결해야 합니다:

• 원시 이벤트 처리 (raw event handling);
• 탐지기 출력 (detector output);
• 인시던트 상태 (incident state);
• 검색 품질 (retrieval quality);
• 정책 규칙 (policy rules);
• 모델 동작 (model behaviour);
• 폴백 동작 (fallback behaviour);
• 복구 (recovery).

기권 (Abstention) 또한 가시적이어야 합니다. 에스컬레이션 (Escalation)은 실패한 응답이 아닙니다. 그것은 종종 더 안전한 결과입니다. SigNoz는 에이전트가 얼마나 자주 기권하는지, 그리고 그 원인이 검색 (retrieval) 때문인지 또는 데이터 품질 때문인지를 보여줍니다.

또한 저는 실시간 경로 (live path)를 느린 AI 작업으로부터 독립적으로 유지했습니다. 안전한 탐지기 전용 (detector-only) 결과가 운영자에게 먼저 도달한 다음, 검색 (retrieval)과 설명 (explanation)이 이를 보완합니다.

결론

산업용 IoT 이상 제어 (Industrial IoT Anomaly Control)는 항상 자신감 있게 말하도록 설계되지 않았습니다.

이 시스템은 증거 체인 (evidence chain)을 구축하고, 명확한 규칙을 따르며, 그 증거가 충분히 강력하지 않을 때 멈추도록 설계되었습니다.

SigNoz는 첫 번째 이상 수치부터 최종 결정 및 복구에 이르기까지, 그 증거 체인을 운영자나 엔지니어가 검사할 수 있는 무언가로 바꿔줍니다.

이 프로젝트의 이면에 있는 원칙은 간단합니다:

증거 우선. 답변 후순위.

프로젝트 링크

• GitHub: https://github.com/dawgdevv/AI-Powered-Industrial-Anomaly-Detection
• 데모 영상:

참고 문헌

• SigNoz 셀프 호스팅 설치: https://signoz.io/docs/install/docker/
• SigNoz OpenTelemetry Python 인스트루멘테이션 (instrumentation): https://signoz.io/docs/instrumentation/opentelemetry-python/
• OpenTelemetry 문서: https://opentelemetry.io/docs/