자동화 기능을 만들었는데 아무도 시작 버튼을 누르지 않았다

몇 주 전에 만든 자동화 기능의 사용 현황을 확인하다가 이상한 숫자를 봤습니다. 실행 기록이 0건이었습니다. 반복되는 로그 패턴을 잡아 등록해주는 기능인데, 만든 이후 아무도 쓰지 않고 있었습니다. 기능이 고장난 것이 아니었습니다. 시작 버튼을 누른 사람이 없었을 뿐입니다.

어떤 AI 운영·관제 플랫폼의 로그 모니터링 이야기입니다. 반복되는 로그 패턴을 감지해 관리 대상으로 등록하는 기능을 opt-in 방식으로 설계했습니다. 운영자가 화면에서 발견 버튼을 눌러야 감지가 시작되는 구조였습니다.

빈 화면은 아무것도 시작시키지 않았습니다

처음엔 합리적인 설계라고 생각했습니다. 감지를 돌릴지 말지를 운영자가 결정하는 편이 안전해 보였기 때문입니다. 그런데 운영해보니 남은 것은 빈 화면이었습니다. 운영자는 빈 화면 앞에서 무엇을 눌러야 할지 모르고, 눌러야 할 이유도 찾지 못합니다.

결국 반복 패턴은 계속 방치됐습니다. 기능은 존재하는데 커버리지는 0인 상태입니다. 사람이 시작해야 하는 자동화는 대개 시작되지 않는다는 사실을 이때 확인했습니다.

탐지는 기계에, 판정은 사람에게

모델을 뒤집기로 했습니다. 매일 새벽 1시에 스케줄 잡이 자동으로 패턴을 감지하고, 잡힌 후보를 pending 상태로 등록합니다. 운영자는 채워진 큐를 훑으며 두 가지 판정만 합니다. 쓸 만한 후보는 active로 승격하고, 아닌 것은 ignored로 기각합니다.

opt-in에서 opt-out으로의 전환입니다. 사람의 부담이 시작에서 판정으로 이동했습니다. 빈 화면 대신 이미 채워진 triage 큐를 받으면, 사람은 자연스럽게 골라내기 시작합니다.

이렇게 뒤집은 근거는 세 가지였습니다.

시작 클릭 제거 — 빈 화면 대신 이미 채워진 triage 큐를 준다

커버리지 — 아무도 안 눌러 패턴을 통째로 놓치는 사고를 막는다

일관성 — 미매핑 항목을 자동 등록해두고 사람이 처리하는 기존 거버넌스와 같은 형태다

자동이 만들고 사람이 판정하는 구조는 이번이 처음이 아닙니다. AI가 자동 분류한 결과에 사람 검토 게이트를 붙였던 경험이 이번 설계의 밑그림이 됐습니다.

자동 등록이 사고가 되지 않으려면

무언가를 자동으로 등록하는 시스템은 그 자체로 위험을 만듭니다. 그래서 안전장치 세 개를 함께 설계했습니다.

dedup — 같은 (시스템·메시지 템플릿·에러 클래스) 조합은 재생성·재추천하지 않는다

pending 무해성 — 승격 전 상태는 심각도·알람에 자동 반영되지 않는다

soft reject — 기각은 삭제가 아니라 ignored 상태로 남아 재추천을 막는다

이 중 핵심은 pending의 무해성입니다. 자동 등록된 후보가 곧바로 알람을 울리거나 심각도 집계에 잡히면, 새벽에 돌아간 잡이 아침의 장애 대응을 만들어냅니다. 미승격 상태의 부작용이 0이어야 자동 등록을 마음 놓고 돌릴 수 있습니다. 사람이 승격해야 비로소 의미를 가지는 구조입니다.

기각은 삭제가 아니라 상태입니다

기각 처리도 고민 지점이었습니다. 처음 떠올린 것은 단순 삭제였습니다. 그런데 삭제하면 다음날 자동 감지가 같은 패턴을 또 잡아 올립니다. 운영자는 어제 버린 것을 오늘 또 버리게 됩니다. hard delete가 재발견 루프를 만드는 셈입니다.

그래서 기각을 ignored 상태로 남기는 soft reject로 갔습니다. 같은 조합은 다음 자동 감지에서 다시 추천되지 않습니다. 다시는 안 물어본다는 보장이 있어야 운영자가 큐를 신뢰하고, 큐를 신뢰해야 매일 들어와 판정을 합니다.

물론 한 번 기각한 판단이 영원히 옳다는 보장은 없습니다. ignored로 잠재운 항목을 언제, 어떻게 다시 꺼내 검토할지는 별도의 거버넌스 문제입니다. soft reject의 뒷단을 설계했던 경험은 따로 정리해뒀습니다.

임계값 999라는 함정

전환 후에도 함정이 하나 남아 있었습니다. 감지 임계값, 즉 최소 발생 횟수가 999로 세팅돼 있었습니다. 이 값은 코드와 DB에만 존재해서 화면에서는 보이지도 않았습니다.

로그가 많은 시스템에서는 문제가 안 됩니다. 그런데 저볼륨 시스템은 자동 잡이 매일 돌아도 거의 아무것도 잡지 못했습니다. 자동화가 돌고 있는데 결과가 없으니 겉으로는 opt-in 시절의 빈 화면과 구분이 안 됩니다. 임계값을 화면에서 직접 조정하는 설정 패널 3개 필드로 빼내, 운영자가 시스템 볼륨에 맞게 낮출 수 있게 했습니다.

opt-out에도 전제가 있습니다

이 구조가 만능은 아닙니다. 자동 등록이 노이즈를 쏟아내면 triage 큐가 스팸이 되고, 그때는 opt-out이 opt-in보다 나쁩니다. dedup과 임계값이 큐 품질을 지키는 생명선입니다.

또 opt-out은 사람이 큐를 실제로 본다는 전제에 의존합니다. 아무도 큐를 안 보면 pending이 무한 적체됩니다. 판정 실수가 곧바로 외부 영향으로 이어지는 도메인이라면, pending 단계를 2단 검토로 더 두껍게 가져가는 편이 맞습니다.

사람이 시작 버튼을 눌러야 도는 자동화가 있다면, 실제 실행 횟수를 확인해봤는가

자동 등록물이 승격 전에 알람·심각도 집계에 영향을 주지 않는가

기각이 삭제로 처리돼 다음 배치에서 같은 후보가 재추천되고 있지 않은가

감지 임계값 같은 튜닝 지점이 코드가 아니라 화면에 나와 있는가

아무도 큐를 안 볼 때 pending 적체를 감지할 방법이 있는가

지금은 매일 새벽 큐가 채워지고, 운영자는 판정만 합니다. 이번 전환에서 성패를 가른 것은 감지 알고리즘의 정교함이 아니라 사람에게 주는 첫 화면이었습니다. 빈 화면과 시작 버튼을 줄 것인지, 채워진 큐와 판정 버튼을 줄 것인지의 차이입니다.