Senapse 가상 실험: AI가 설비 이상의 원인을 찾아가는 20분

설비가 이상할 때 가장 먼저 떠오르는 질문은 “어디가 문제냐”입니다. 경보가 울린 태그가 원인인 경우는 생각보다 드뭅니다. 보일러 온도가 올랐다고 보일러가 고장 난 것은 아닐 수 있습니다.

Senapse는 이 질문을 AI와 함께 풀기 위해 만들고 있는 IT-OT 게이트웨이입니다. 현장 장비 값을 모아 두고 AI가 그 값을 읽어 원인을 추론하게 합니다. 이번 글은 Senapse로 해 본 가상 실험의 기록입니다.

Senapse가 하는 일

Senapse는 현장 장비와 AI 사이에 서는 게이트웨이입니다. 장비 쪽으로는 Modbus로 값을 읽고 AI 쪽으로는 MCP(Model Context Protocol, AI가 외부 도구를 부르는 표준 방식)로 도구를 내줍니다.

핵심 원칙은 하나입니다. AI는 제안하고 읽을 수 있지만 바꾸는 것은 사람이 허락해야 합니다.

실험 설계: 정답을 숨긴 고장 시나리오

가상 설비는 두 대입니다. 보일러가 물을 데우고 냉각수 펌프가 보일러 계통을 식힙니다. 펌프 유량이 줄면 보일러 온도가 오르도록 두 장비를 물리 모델로 엮었습니다.

여기에 20분짜리 고장 시나리오를 심었습니다. 근본 원인은 펌프 베어링 열화입니다. 진동이 오르면 전류가 늘고 유량이 줄어듭니다. 그 결과 보일러가 과열됩니다. 원인과 무관한 사건도 섞었습니다.

AI에게는 이 표를 주지 않았습니다. 장비 역할과 정상 범위, “유량이 줄면 보일러 온도가 오른다” 같은 운전 지식만 줬습니다. 운전원이 알 만한 수준의 정보입니다.

1. 설정: AI가 제안하고 사람이 승인합니다

장비 등록부터 AI에게 맡겼습니다. AI가 레지스터 맵을 읽고 장비 2대, 태그 11개의 설정 초안을 만들어 MCP로 제출합니다.

제출하면 게이트웨이가 바로 되읽기 검증을 합니다. 제안한 주소에서 실제 값을 읽어 보고 배율이나 바이트 순서가 이상하지 않은지 판정합니다. 이번에는 11개 태그가 모두 “실측 일치”로 나왔습니다.

AI가 제안한 보일러 설정 초안입니다. 태그마다 실제로 읽은 값과 판정이 붙어 있고 사람이 승인해야 적용됩니다.

승인은 두 번 눌러야 적용됩니다. 실수로 한 번 누른 것으로는 설정이 바뀌지 않습니다.

2. 감시: 대시보드에서 본 20분

시나리오를 돌리는 동안 대시보드는 사건을 그대로 보여 줬습니다. 전류 스파이크 때는 해당 태그가 주의로, 통신 두절 때는 펌프 카드 전체가 불량으로 바뀌었습니다.

보일러 온도가 상한을 넘은 직후의 개요 화면입니다. 버너 출력은 하한 20%에 붙어 있고 펌프 쪽 추이 선에서 진동과 전류는 오르고 유량은 내려가는 것이 보입니다.

다만 대시보드가 알려 주는 것은 “보일러 온도가 높다”까지입니다. 왜 높은지는 알려 주지 않습니다. 그 질문을 AI에게 넘겼습니다.

3. 분석: AI 리포트

시나리오가 끝난 뒤 AI에게 20분 구간의 이상 징후와 원인을 분석하게 했습니다. AI는 MCP로 11개 태그의 원본 이력을 읽고 품질 코드를 사유별로 나눈 다음 HTML 리포트를 만들었습니다.

리포트는 결론부터 말합니다. 보일러 과열은 냉각수 펌프의 기계적 열화 때문일 가능성이 높고 아직 해소되지 않았다는 것입니다. 사건마다 판정이 붙어 있고 설정값 변경은 “정상 조작”으로 분류했습니다.

원인을 판정하는 과정이 이 리포트에서 가장 중요한 부분입니다.

AI는 데이터로 배제할 수 있는 것부터 지웠습니다.

• 속도 지령이 80%로 고정이었으므로 속도 변경은 원인이 아니다
• 버너 출력이 60%에서 20%로 줄었는데 온도가 올랐으므로 가열 과다는 원인이 아니다
• 두 장비 모두 운전 상태를 유지했으므로 정지나 재기동도 아니다

그다음 남은 후보 중에서 “베어링 열화가 가장 개연성 높다”고 추론했고 이것이 추론이라는 점을 밝혔습니다. 진동 주파수 스펙트럼이 없어 베어링과 축 정렬 불량을 데이터로는 가를 수 없다는 한계도 적었습니다.

채점 결과

정답 타임라인과 비교했습니다.

6건 모두 짚었습니다. 열화 시작이 11초 늦은 것은 노이즈 속에서 추세가 확실해질 때까지 기다리는 판정 방식 때문입니다.

4. 실험: 무장 세션으로 가설 확인

관찰만으로 원인을 확정할 수 없을 때는 직접 건드려 봐야 합니다. Senapse에서는 이것을 무장 세션(쓰기 권한을 시간과 태그 범위로 묶어 잠시 여는 장치)으로 합니다.

AI가 “속도 지령을 80%에서 70%로 잠시 낮춰, 진동이 속도의 제곱만큼 줄어드는지 보겠다”고 신청했습니다. 회전과 관련된 원인이라면 진동은 속도의 제곱에 비례하기 때문입니다.

무장 세션 신청 화면입니다. 목적, 만질 태그, 그 태그를 만지는 이유가 적혀 있고 사람이 허용 시간을 정해 승인합니다.

승인 후 AI는 예측을 먼저 기록하고 쓰기를 실행했습니다. 쓴 레지스터를 되읽는 것은 판정에 쓰지 않았습니다. 장비가 명령을 받아들였는지가 아니라 레지스터에 값이 들어갔다는 것만 보여 주기 때문입니다. 반응은 진동, 유량 같은 별도 태그로 1분 뒤에 확인했습니다.

진동이 예측대로 줄어 회전 관련 원인이라는 가설이 지지됐습니다. 동시에 유량이 줄어 보일러 온도가 올랐습니다. 속도를 낮추는 것은 진동 대책이 될 수 없다는 뜻입니다. AI는 바로 80%로 되돌리고 별도 읽기로 원복을 확인한 뒤 세션을 반납했습니다.

실험에서 드러난 것

가상 실험이지만 제품의 허점도 몇 가지 드러났습니다.

쓰기 도구의 타입 문제. AI 클라이언트에 따라 쓰기 값 70이 숫자가 아니라 문자열로 전달됐고 게이트웨이가 이를 거부했습니다. 도구 정의에 값의 타입이 빠져 있던 것이 원인이었습니다. 실험 중에는 같은 도구를 숫자 타입으로 직접 호출해 진행했고 실험 직후 도구 정의에 숫자와 불리언 타입을 넣어 고쳤습니다. 고친 뒤에는 AI가 숫자를 숫자로 보내는 것을 확인했습니다.

쓰기 직후 되읽기 값. 쓰기 응답에 담기는 되읽기 값이 이전 값으로 나오는 경우가 있었습니다. 장비가 레지스터를 갱신하기 전에 읽었기 때문입니다. 이런 경우를 대비해 AI 분석 규칙에는 “쓰기 직후 되읽은 값은 판정에 쓰지 않는다”는 항목이 원래 들어 있었고 이번에 실제로 그 덕을 봤습니다. AI는 이 값을 무시하고 1분 뒤 별도 태그로 반응을 확인했습니다.

화면 갱신. 상단 헤더의 장비 상태가 페이지를 옮겨야만 바뀌는 것도 발견했습니다.

아직 아닌 것

이번 실험은 문제를 낸 쪽과 푼 쪽이 같은 팀입니다. 시나리오는 펌프 열화가 깔끔하게 퍼지도록 만든 것이라 실제 설비의 복잡한 노이즈와 여러 원인이 겹치는 상황은 담지 못했습니다.

시뮬레이터의 물리 모델도 단순합니다. 진동은 속도의 제곱, 유량은 속도에 비례하게 만들었고 실제 펌프 곡선이나 베어링 결함 주파수는 없습니다. 무장 실험의 결과가 예측과 거의 같았던 것도 그 때문입니다.

그래도 확인하고 싶었던 흐름은 확인했습니다. AI가 설정을 제안하고, 사람이 승인하고, 수집한 데이터로 원인을 좁히고, 허락받은 범위 안에서 직접 실험해 가설을 확인하는 것. 다음은 실제 장비 위에서 이 흐름을 돌려 볼 차례입니다.

문의

• Email : [email protected]
• Insta : https://www.instagram.com/going.sen/
• Website : https://intosen.com/kr/consult/