이상한 충전기 찾기 — 이상감지

세 줄 요약

• 제보와 사람 모니터링에 의존하면 처리량이 사람의 시간에 묶입니다. 그리고 처리량의 상한이 곧 감지의 상한이 됩니다 — 시끄러운 고장만으로 손이 다 차면, 조용한 고장은 볼 여력도 볼 필요도 없습니다.
• 그래서 감지 · 분류 · 조치 · 이관을 하나의 프로세스로 묶었습니다. 중복 제보는 한 이슈로 접고, 되돌릴 수 있는 조치는 자동으로, 되돌리기 어려운 조치는 근거를 갖춰 사람에게 넘깁니다.
• 사람 손이 덜 들자 감지를 넓힐 여유가 생겼습니다. 룰로 아는 고장 위에 정상 패턴을 학습한 감지를 얹고, 거기서 확인된 새 패턴은 다시 룰로 승격시킵니다. 못 잡는 범위는 줄어드는 쪽으로만 움직입니다.

1. 시끄러운 고장만으로도 손이 모자란다

충전기가 늘면 고장도 그만큼 꾸준히 발생합니다. 이건 이상한 일이 아니라 정상입니다. 품이 드는 건 그다음입니다. 그 하나하나를 사람이 확인하고, 분류하고, 적절한 곳으로 보내야 합니다.

그 일은 두 갈래로 들어옵니다. 고객이 알려주는 제보, 그리고 사람이 화면을 지켜보다 심각한 알림을 잡는 모니터링입니다. 둘 다 잘 작동합니다. 다만 둘 다 사람의 시간에 비례해서만 늘어납니다. 담당자가 하루에 볼 수 있는 건수가 있고, 그것이 그날 처리되는 고장의 상한입니다.

여기서 덜 직관적인 결과가 하나 나옵니다. 시끄러운 고장만 처리하는 데도 리소스가 다 든다면, 조용한 고장은 볼 여력이 없을 뿐 아니라 볼 필요도 없습니다. 처리할 사람이 없는데 감지를 예민하게 만들면 대기열만 길어지고, 길어진 목록은 아무도 열지 않습니다. 감지를 넓히는 일 자체가 의미를 잃습니다.

처리할 수 없는 고장을 감지하는 것은 대기열을 늘리는 일일 뿐입니다. 감지를 넓히는 일은 언제나 처리를 자동화한 다음입니다.

그래서 순서가 정해졌습니다. 먼저 이미 알고 있는 시끄러운 고장의 처리를 사람 손에서 떼어내고, 그렇게 확보한 여력만큼 감지를 넓힙니다.

그 아래 가려져 있던 것

그 넓힌 자리에서 처음 보이기 시작한 것이 이런 고장입니다. 커넥터는 잘 꽂혀 있고, 화면도 켜져 있고, 에러 코드도 올라오지 않는데, 전류가 사실상 흐르지 않는 상태로 한참을 머무릅니다. 충전량이 쌓이지 않습니다. 계량값이 거꾸로 갑니다.

사용자 입장에서는 “충전이 안 됐다”인데, 시스템 입장에서는 아무 사건도 없었습니다. 어떤 임계값도 넘지 않았고, 어떤 예외도 발생하지 않았습니다. 우리는 이런 것을 부재(不在)의 고장이라고 불렀습니다. 무언가 잘못된 것이 아니라, 마땅히 일어나야 할 일이 일어나지 않은 겁니다.

여기에 기종의 다양성까지 겹칩니다. 기종마다 ‘정상’의 모양이 다릅니다. 7kW 완속기의 정상적인 충전 곡선과 100kW 급속기의 정상적인 충전 곡선은 아예 다른 그림입니다. 같은 잣대로 보면 완속기는 늘 이상해 보이고, 급속기의 진짜 이상은 정상 범위에 묻힙니다.

이 글은 그래서 세 갈래를 함께 다룹니다.

• 감지를 어디까지 넓힐 수 있는가 — 2~4장
• 감지된 것을 사람 손 없이 어디까지 처리할 수 있는가 — 5~7장
• 그 둘이 서로를 키우는 방식 — 8장

두 번째가 첫 번째의 조건이고, 첫 번째가 다시 두 번째의 재료가 됩니다.

2. 아는 이상은 룰로 잡는다

첫 감지는 규칙으로 시작했습니다. “전류가 특정 값 아래로 일정 시간 이상 지속되면 이상”처럼, 사람이 이미 알고 있는 고장 형태를 그대로 조건으로 옮기는 방식입니다.

이 방식은 자주 ‘초보적’이라고 과소평가되는데, 실제로는 매우 강력한 성질을 하나 갖고 있습니다. 설명 가능하다는 것입니다. 운영자에게 “왜 이게 이상인가”를 한 줄로 답할 수 있고, 같은 입력에 같은 판정이 나옵니다.

이 성질은 뒤에서 다시 중요해집니다. 자동 조치는 설명 가능한 판단 위에서만 걸 수 있기 때문입니다. 왜 눌렀는지 설명하지 못하는 판정에 충전기 재시작을 연결할 수는 없습니다.

대신 한계가 분명했습니다.

• 예상한 것만 잡습니다. 규칙은 우리가 이미 본 고장의 목록입니다. 처음 보는 형태는 정의상 걸리지 않습니다.
• 신호가 늘면 조건이 폭발합니다. 전류와 전압과 적산량과 시간을 조합해서 판단해야 하는 순간, 조건문은 사람이 관리할 수 있는 크기를 넘어갑니다.
• 기종마다 분기가 필요합니다. 정상의 기준이 기종별로 다르면, 규칙도 기종별로 갈라져야 합니다.

그림 1. 룰은 선을 미리 긋고, 학습은 평소에서 얼마나 멀어졌는지를 본다. 선 안쪽에 있는 이상은 아무리 특이해도 룰에는 보이지 않는다.

표 1. 두 방식의 성질 비교. 약점의 방향이 서로 반대라서, 하나로 다른 하나를 대체할 수 없다.

표의 마지막 줄이 이 글의 나머지를 결정합니다. 두 방식의 약점이 서로 반대 방향입니다. 그러면 둘 중 하나를 고를 일이 아닙니다. 서로의 약점을 덮게 배치하면 됩니다.

3. 정상을 배워서 이상을 찾는다

여기서부터가 감지를 넓히는 이야기입니다. 한 가지만 미리 밝혀 두면 — 이 확장은 5장 이후에 나오는 처리 자동화가 여력을 만들어 준 다음에야 의미가 있었습니다. 서술 순서상 감지가 먼저 나오지만, 실제 순서는 그 반대였습니다.

접근을 뒤집었습니다. 무엇이 이상인지 가르치지 않습니다. 대신 수많은 정상 충전 세션을 보여주고 ‘보통 충전이 어떻게 생겼는지’만 익히게 합니다. 새 세션이 들어오면 그 평소 패턴에서 얼마나 멀리 떨어져 있는지를 점수로 매깁니다. 정답표 없이 데이터의 일반적인 모습만으로 배우기 때문에 이를 비지도 학습이라고 부릅니다.

비유하면, 룰 기반은 ‘체온 37.5도가 넘으면 발열’이라는 기준표를 미리 만들어 두는 것이고, 이 방식은 그 사람의 평소 체온·맥박 패턴을 알아 두고 평소와 다른 날을 짚어내는 것입니다.

세션 하나를 어떻게 보는가

한 번의 충전은 전류와 전압의 모양, 충전량이 실제로 쌓였는지, 시간과 효율 같은 지표들로 요약해 한 줄로 만듭니다. 이 감지는 매일 한 번, 전날의 세션 전체를 이 방식으로 훑습니다.

그런데 정확도에 가장 크게 기여한 결정은 모델 선택이 아니었습니다. 같은 기종끼리만 비교하도록 잣대를 나눈 것입니다. ‘평소’를 전체 평균으로 잡으면 완속기와 급속기가 서로를 오염시킵니다. 비교 대상을 같은 하드웨어 모델로 묶는 것만으로, 1장에서 이야기한 ‘기종마다 정상이 다르다’는 문제가 대부분 사라졌습니다.

관문을 두 개 둔 이유

감지 모델은 하나가 아니라 여러 개를 두고 각자 채점하게 했습니다. 그리고 과반이 이상이라고 할 때만 이상 후보로 올립니다. 한 모델의 특이한 성향이 그대로 알림이 되지 않게 하려는 장치입니다.

그다음이 두 번째 관문입니다. 학습 기반 감지의 약점은 표에서 봤듯 ‘이상하다는 건 아는데 이유를 못 말한다’는 것입니다.

이 약점을 메우려고 사람의 말로 설명을 쓸 수 있는 AI를 한 겹 더 뒀습니다. 이상 후보로 올라온 세션의 실제 데이터를 다시 읽고 설명과 유형명을 붙입니다. “전류가 거의 흐르지 않는 상태가 오래 지속되었습니다 → 저전류 장시간 충전” 같은 식입니다. 이 단계에서 “사실은 정상”이라고 판단되면 거기서 걸러집니다.

그림 2. 두 관문을 모두 통과한 세션만 알림이 된다. 탈락한 판단도 버리지 않고 저장해 다음 학습의 재료로 쓴다.

왜 두 번 거를까요. 여기에 이 시스템의 가장 중요한 판단이 있습니다. 감지 시스템에는 두 가지 실패가 있습니다. 놓치는 것과 틀리게 알리는 것. 둘 다 나쁘지만, 우리는 둘을 같은 무게로 두지 않았습니다.

빠짐없이 잡는 것보다, 알렸으면 진짜일 것을 택했습니다. 신뢰를 잃은 알림은 꺼진 알림과 같습니다.

— 헛알림이 쌓이면 운영팀은 알림을 열지 않게 되고, 그 순간 시스템의 가치는 0이 됩니다.

대신 알리지 않은 판단도 전부 저장합니다. 정상으로 판정된 것, 분류에 실패한 것, 처리하지 못한 것까지. 알림으로 나가지 않았다는 것이 데이터로서 가치가 없다는 뜻은 아니기 때문입니다. 이 기록이 다음 학습과 기준 조정의 재료가 됩니다.

4. 새 패턴은 룰이 된다

여기까지만 보면 ‘룰을 학습으로 대체했다’는 이야기처럼 들립니다. 실제 구조는 그 반대입니다. 학습은 룰을 늘리기 위한 장치로 배치했습니다.

학습이 찾아낸 이상 패턴이 반복해서 올라오고, 현장 조치 결과와 맞춰 봐도 일관되고, 운영팀과 “이건 확실한 이상 유형이다”라는 합의가 이뤄지면 그 패턴은 명시적인 룰로 승격됩니다. 한번 룰이 되면 그 유형은 룰이 빠르고 값싸게, 그리고 무엇보다 설명 가능하게 처리합니다.

승격의 이득은 세 겹입니다. 판정이 즉시 나오고, 비용이 사실상 0이 되고, 설명 가능해지므로 자동 조치를 연결할 수 있게 됩니다. 2장에서 미뤄 둔 이야기가 여기서 회수됩니다. 자동으로 충전기를 재시작하려면 그 판정이 왜 내려졌는지 한 줄로 말할 수 있어야 하고, 그건 룰의 성질입니다.

그리고 반대쪽 이득이 하나 더 있습니다. 룰이 그 유형을 가져가면, 학습 쪽은 이미 해결된 쉬운 탐지에 자원을 쓰지 않게 됩니다. 아직 규칙으로 정의되지 않은, 더 어렵고 처음 보는 이상을 찾는 데 집중할 수 있습니다.

그림 3. 학습이 찾고, 사람이 승인하고, 룰이 기억한다. 한 바퀴 돌 때마다 ‘아직 못 잡는 범위’는 줄어드는 쪽으로만 움직인다.

이 루프의 성질이 마음에 듭니다. 시간이 갈수록 룰의 목록은 길어지고, 학습의 관심은 계속 더 어려운 쪽으로 밀려납니다. 어느 쪽도 상대를 대체하지 않고, 전체 탐지 범위만 넓어집니다. ‘AI가 사람을 대신한다’가 아니라 학습이 찾고, 사람이 승인하고, 룰이 기억한다는 분업입니다.

5. 감지를 조치로

감지의 끝을 알림이라고 두면, 시스템이 잘 돌수록 사람의 시간이 더 많이 듭니다. 알림은 결국 누군가 읽고 판단하고 손을 움직여야 하는 일감이기 때문입니다. 감지가 실제로 값을 하는 순간은 그것이 조치로 이어질 때입니다.

그래서 감지 결과는 알림과 별개로 이슈 추적 시스템에 메시지로 전달됩니다. 여기서부터는 ‘이상한 세션’이 아니라 ‘추적되고 종결되어야 하는 사건’으로 다뤄집니다.

이슈가 되기 전에 한 번 걸러진다

도착한 제보는 곧바로 이슈가 되지 않습니다. 먼저 1차 판단을 거쳐 세 갈래로 갈립니다. 새 이슈로 등록할지, 진행 중인 기존 이슈에 붙일지, 아니면 무시할지를 정합니다.

이 단계가 없으면 어떻게 되는지가 중요합니다. 어떤 충전기가 이미 고장으로 판정되어 수리가 진행 중이고 담당자가 붙어 있는데, 그 충전기는 당연히 매일 같은 이상으로 다시 감지됩니다. 그때마다 새 이슈를 만들면 이슈 목록은 며칠 만에 같은 이야기로 가득 찹니다. 그래서 이미 사람이 붙어 있는 건이라면 새 이슈를 만들지 않고 제보만 그 이슈에 병합합니다.

사소해 보이는 처리인데, 이것이 감지 민감도를 올릴 수 있게 해 주는 조건입니다. 중복이 그대로 목록에 쌓이는 구조에서는 감지를 조금만 예민하게 만들어도 운영 화면이 먼저 무너집니다. 중복을 접어 두면, 더 많이 감지하는 것과 운영이 감당할 수 있는 것이 충돌하지 않습니다. 1장에서 이야기한 ‘처리량이 곧 감지의 상한’이라는 제약을 푸는 지점이 정확히 여기입니다.

조치 직전에 한 번 더 멈춘다

이슈가 되면 분류 규칙이 조건을 맞춰 처리 방향을 정하고, 신뢰도가 충분한 규칙이라면 운영자 확인 없이 워크플로우가 자동으로 시작됩니다. 가장 앞에 있는 자동 조치는 원격 재시작입니다.

다만 그 직전에 안전 게이트가 하나 있습니다. 충전 중인 충전기는 재시작하지 않습니다. 누군가 지금 충전하고 있는 충전기를 재시작하는 것은 고장을 고치는 게 아니라 고장을 만드는 일입니다. 그리고 여기에 한 겹 더 있습니다. 충전 중인지 확인하는 것 자체가 실패하면, 충전 중인 것으로 간주합니다. 모를 때는 안 하는 쪽입니다.

그림 4. 이슈가 되기 전에 한 번 걸러지고, 조치 직전에 한 번 더 멈춘다. 중복 병합이 감지 민감도를 올릴 수 있게 만들고, 안전 게이트가 자동 조치를 안전하게 만든다.

자동화의 범위를 정할 때 쓴 기준은 단순합니다. 되돌릴 수 있는 것만 자동으로 합니다. 원격 재시작은 최악의 경우에도 결과가 ‘충전기가 다시 켜진다’입니다. 판단이 틀렸어도 복구할 수 있는 종류의 행위이고, 그래서 사람의 확인 없이 걸어 둘 수 있습니다.

6. 재시작으로 안 되면 사람에게

재시작으로 해결되지 않는 고장이 있습니다. 계량기가 물리적으로 죽었거나 통신 모듈이 고장난 경우처럼, 소프트웨어를 다시 올려도 상태가 그대로인 것들입니다. 이때 계속 재시도하는 것은 자동화가 아니라 방치입니다. 시스템은 바쁘게 뭔가를 하고 있고, 충전기는 계속 죽어 있습니다.

그래서 ‘여기서부터는 사람이 가야 한다’를 판정하는 단계를 두었습니다. 판정은 두 가지 근거를 함께 봅니다.

• 근거 A — 신호. 재시작으로는 회복되지 않는 것으로 알려진 에러 계열(예: 계량·통신 계열)이 보고되었는가.
• 근거 B — 결과. 그 충전기에서 최근 실제로 충전된 양이 사실상 없는가.

두 번째 근거가 이 설계에서 가장 마음에 드는 부분입니다. 에러 코드는 충전기가 ‘아프다’고 말하는 것이지만, 충전 이력은 실제로 아무도 충전하지 못했다는 사실입니다. 전자는 신호이고 후자는 결과입니다.

고장을 판정하는 가장 확실한 근거는 에러 코드가 아니라, 그 충전기에서 아무도 충전하지 못했다는 사실입니다.

이 구분이 실제로 무엇을 막아 주는지가 중요합니다. 에러는 떴지만 사람들이 계속 정상적으로 충전하고 있는 충전기가 있습니다. 여기에 현장 인력을 보내면 그 출동은 낭비이고, 낭비된 출동은 다음 출동의 신뢰를 깎습니다.

반대로 에러가 잠깐 사라졌더라도 최근 아무도 충전하지 못했다면, 그것은 코드가 뭐라고 하든 고장입니다. 1장에서 이야기한 ‘부재의 고장’은 애초에 신호로는 잡히지 않습니다 — 결과로만 잡힙니다.

그림 5. 신호와 결과를 함께 요구한다. 되돌리기 어려운 일일수록 판정의 근거를 하나 더 요구하는 쪽으로 설계했다.

두 근거가 모두 충족되면 고장신고가 자동으로 등록됩니다. 그냥 티켓 하나가 열리는 게 아니라, 어떤 에러 계열이 최근 몇 번 보고되었는지 같은 판정 근거가 채워진 양식까지 만들어져서 접수됩니다. 사람이 하는 일이 ‘접수를 만드는 것’에서 ‘접수된 것을 판단하는 것’으로 바뀝니다.

마지막으로 이 판정에도 페일세이프를 두었습니다. 충전 이력 조회 같은 외부 조회가 실패하면 조건 미충족으로 처리하고 워크플로우는 계속 흐릅니다. 대신 조용히 넘기지 않고 경고를 남깁니다. 자동 조치가 ‘모를 때는 하지 않는’ 쪽이었던 것과 같은 원칙입니다. 모른다는 이유로 사람을 현장에 부르지는 않습니다.

7. 무엇을 보고 그렇게 판단했나

6장의 두 근거는 ‘자동으로 이관을 걸어도 되는가’를 가르는 최소 조건입니다. 사람을 현장에 부르는 판정이라 일부러 좁게 잡았습니다. 그런데 그 이슈를 사람이 들여다볼 때 쓰는 근거는 훨씬 넓습니다. 잠깐 한 단계 앞으로, 이슈가 분류되는 시점으로 돌아가 보겠습니다.

거기서 이슈 하나에 대해 서른 가지 가까운 점검 항목이 데이터로 채워집니다.

사람이 하던 확인을 그대로 옮겼다

원래 사람이 하던 일입니다. 신고가 들어오면 담당자가 관제 로그를 열고, 충전 이력을 뒤지고, 모뎀 상태를 확인하고, 같은 충전소의 다른 기기는 어떤지 봤습니다. 그 확인 순서를 그대로 데이터 조회로 옮긴 것이 이 항목들입니다.

• 기기 · 통신 — 충전기가 붙어 있는가, 통신 모뎀이 살아 있는가, 신호 세기는 어떤가.
• 상태 · 로그 — 프로토콜 대화가 정상 순서로 흘렀는가, 마지막 로그가 어디서 멈췄는가, 같은 모델의 고장률이 유난히 높은가.
• 충전 이력 — 같은 충전기에서 다른 사용자는 정상 충전했는가, 신고 이후에도 정상 충전이 있었는가, 지난 몇 달은 정상이었는가.
• 사용자 · 인증 — 카드 인증과 원격 시작 중 어느 쪽이 실패했는가, 이 사용자가 여러 충전기에서 연달아 중단했는가, 과거에 같은 신고가 확정된 적 있는가.
• 이상감지 — 최근 며칠 사이 이 충전기에 이상감지가 있었는가.

항목 하나하나는 그 자체로 결론이 아닙니다. 엮일 때 결론이 됩니다. 카드 인증은 실패하는데 앱 원격 시작은 성공한다면, 충전기가 죽은 것이 아니라 카드 리더기가 고장난 것입니다. 같은 구역의 여러 기기가 한꺼번에 통신이 끊겼다면, 충전기를 아무리 들여다봐도 답이 없습니다. 그 구역의 전원 문제니까요.

사용자가 남긴 말은 두 경우 모두 “충전이 안 돼요” 한 마디였습니다. 데이터를 엮으면 하나는 부품 교체로 끝나고, 다른 하나는 전기 공사로 갑니다. 그래서 항목들은 평탄한 목록으로 두지 않고 판단 트리로 엮었습니다. 원인이 하나라는 보장이 없으니, 여러 갈래가 동시에 켜질 수도 있습니다.

그림 6. 항목 하나는 신호일 뿐, 엮여야 결론이 된다. 같은 “충전이 안 돼요”가 부품 교체와 전기 공사로 갈린다.

필요할 때만 부르고, 근거를 남긴다

덧붙일 게 두 가지 있습니다. 첫째, 이 점검은 필요할 때만 부릅니다. 규칙으로 명확히 떨어지는 이슈는 규칙이 즉시 처리하고, 규칙에 걸리지 않는 애매한 이슈에만 이 넓은 점검을 불러 판정에 씁니다. 4장의 분업과 같은 모양입니다. 싸고 설명 가능한 것이 먼저고, 비싸고 넓은 것은 그것으로 안 되는 곳에만 씁니다.

둘째, 판정에는 근거가 함께 남습니다. 각 항목은 예/아니오만 남기지 않고 어느 기간의 무엇을 보고 그렇게 판정했는지를 기록합니다.

여기서 ‘언제를 기준으로 보는가’를 신고 시점과 점검 실행 시점으로 나눠 두었습니다. 어제 오후의 문제를 오늘 아침에 점검한다면 대부분의 조회창은 어제 오후를 기준으로 잡아야 하고, ‘신고 이후에도 정상 충전이 있었는가’ 같은 사후 관찰 항목만 지금까지 봐야 합니다. 이 둘을 섞으면 같은 이슈를 언제 다시 점검하느냐에 따라 결론이 달라집니다.

감지 결과가 판정 근거로 돌아온다

목록의 마지막 갈래가 이 글의 앞부분과 이어집니다. 점검 항목 중 하나가 “최근 이 충전기에 이상감지가 있었는가”입니다. 3장에서 만든 감지 결과가 여기 판정 근거로 되돌아옵니다.

이 점검 결과는 사람과 AI가 판정할 때 보는 근거로 쓰이고, 어떤 조합이 확실한 결론인지에 합의가 쌓이면 그대로 자동 이관 조건이 됩니다. 4장에서 이야기한 승격이, 감지에서만 아니라 판정 근거에서도 똑같이 일어나는 셈입니다.

8. 패턴과 해결이 노하우가 된다

이슈 하나는 사건입니다. 이슈 여러 개는 패턴입니다. 그런데 패턴은 어떤 축으로 묶어 보는지에 따라 완전히 다른 것이 보입니다.

이슈는 분류가 끝나면 자동으로 여러 축에 동시에 묶입니다. 충전기 · 충전소 · 증상 · 제조사 · 하드웨어 모델 · 펌웨어 버전, 여섯 축입니다. 하나의 이슈가 여러 그룹에 함께 속할 수 있습니다.

왜 축을 나누는지는 조치를 생각하면 분명해집니다. “이 충전기가 이상하다”와 “이 펌웨어 버전이 이상하다”는 전혀 다른 결론으로 이어집니다. 앞은 재시작과 수리로 가고, 뒤는 배포 롤백으로 갑니다.

충전기 단위로만 보고 있으면 후자는 영원히 ‘여러 대가 각각 고장난 것’으로만 보입니다. 축을 미리 나눠 두는 것은, 아직 물어보지 않은 질문에 답할 준비를 해 두는 일입니다.

그림 7. 축이 달라지면 조치가 달라진다. 그리고 해결의 결과는 다음 감지의 근거로 돌아간다.

자동화의 실패도 자동으로 발견되어야 한다

자동 조치를 걸어 두면 새로운 실패 모드가 생깁니다. 자동으로 시도했는데 실패한 채 아무도 모르게 멈춰 있는 이슈입니다. 사람이 손으로 처리하던 시절에는 담당자가 기억하고 있었지만, 자동화된 뒤에는 아무도 그것을 기억하지 않습니다.

조치가 실패한 채 남은 이슈와 오래 진행 중인 이슈를 자동으로 한자리에 모읍니다. 모아 놓으면 재시도든 종결이든 한 번에 처리할 수 있습니다. 자동화를 도입할 때 함께 만들어야 하는 것은 자동화의 실패를 발견하는 장치입니다.

무엇을 볼지도 데이터로 둔다

운영이 던지는 질문은 계속 바뀝니다. 그런데 ‘무엇을 수집해서 어떻게 볼지’가 코드에 박혀 있으면, 새 질문마다 배포를 기다려야 합니다. 그래서 수집 항목과 분석 관점을 데이터로 정의해 두고, 코드 배포 없이 바꿀 수 있게 했습니다.

같은 이유로 분류 규칙을 대화로 만들 수 있게 했습니다. 운영자가 조건식 문법을 배우지 않아도 자연어로 규칙을 만들 수 있습니다. 4장의 승격 루프에서 가장 자주 막히는 구간은 ‘합의는 됐는데 아직 규칙으로 안 옮겨진’ 지점인데, 그 마지막 구간을 짧게 만드는 장치입니다.

그리고 다시 감지로

루프가 닫히는 곳이 여기입니다. 이관해서 실제로 수리된 건은 감지가 맞았다는 증거이고, 출동했는데 정상이었던 건은 오탐의 증거입니다. 이 판정 결과가 다음 모델과 다음 룰의 근거가 됩니다. 감지 → 조치 → 해결이 한 방향의 파이프라인이 아니라 순환인 이유입니다.

그래서 이 루프에서 가장 값진 데이터는 모델이 만들어 내는 점수가 아니라, “이건 오탐이었다”와 “이건 감지에 안 잡혔는데 실제 고장이었다”입니다. 현장의 판단이 감지 쪽으로 되돌아오는 경로가 이 루프의 폭을 정합니다.

마치며 — 일하는 방식

지금도 매일 상당한 양의 이상 세션이 감지됩니다. 그중 일부는 사람이 알아차리기 전에 자동 원격 재시작으로 정리되고, 일부는 재시작으로는 해결되지 않는다는 판정을 받아 고장신고로 자동 등록됩니다.

기능보다, 그 사이사이의 판단을 남겨 두고 싶었습니다.

• 처리량이 시야를 결정한다. 더 보려면 먼저 더 처리할 수 있어야 한다. 감지를 넓히는 일은 언제나 처리를 자동화한 다음이다.
• 룰과 학습은 경쟁하지 않는다. 학습이 찾고, 합의가 승인하고, 룰이 기억한다. 한 바퀴 돌 때마다 못 잡는 범위만 줄어든다.
• 알림의 가치는 재현율이 아니라 정밀도에 있다. 신뢰를 잃은 알림은 꺼진 알림과 같다.
• 자동화는 되돌릴 수 있는 것까지. 되돌리기 어려운 일은 근거를 하나 더 갖춰 사람에게 넘긴다.
• 판정은 신호보다 결과를 본다. 에러 코드보다, 실제로 아무도 충전하지 못했다는 사실이 강하다.
• 모를 때는 하지 않는다. 확인이 실패하면 안전한 쪽으로 기운다. 다만 조용히 넘기지는 않는다.
• 자동화의 실패도 자동으로 발견되어야 한다. 자동화와 함께 만들어야 하는 것은 그 자동화가 멈춘 것을 알아채는 장치다.

‘이상한 충전기를 찾는 일’은 결국 모델을 잘 고르는 문제가 아니었습니다. 사람 손이 닿아야 하는 지점을 하나씩 줄여, 더 볼 수 있는 여력을 만드는 일이었습니다. 무엇을 이상이라 부를지 정하고 그 판정에 무엇까지 걸어도 되는지의 경계를 그리는 일도, 결국 그 여력을 어디에 쓸지 정하는 문제였습니다.

기술 스택 · Kotlin · Spring Boot · JPA · MySQL · Redis(캐시·큐·분산락) · GCP Pub/Sub · 이벤트 기반 메시징 · Google Gemini · React

이 글은 설명을 위해 내부 식별자와 구현 세부를 일반화했습니다. 감지 건수·모델 성능·판정 임계값 등 운영 수치는 공개하지 않았고, 에러 코드는 계열 수준으로만 서술했습니다. 본문의 판단 기준은 설계 의도를 설명하기 위한 것으로, 실제 운영 값과 다를 수 있습니다.