이 프로젝트의 목표는 단순합니다. 이상을 찾는 모델을 만드는 데서 멈추지 않고, 운영자가 실제로 보고, 판단하고, 대응할 수 있는 시스템으로 끝까지 연결하는 것입니다. 앞선 장들에서 이상 탐지 모델의 원리와 점수화 방식을 배웠다면, 이제는 그 결과를 대시보드와 알림, 운영 프로세스까지 묶어 하나의 제품으로 완성해 볼 차례입니다.
이번 프로젝트에서는 서버 로그, 애플리케이션 지표, IoT 센서 데이터처럼 시간에 따라 쌓이는 값을 예로 들어 보겠습니다. 이 데이터는 겉으로 보면 그저 숫자의 흐름이지만, 운영 관점에서는 "평소와 다른 순간"을 빠르게 알아채는 것이 중요합니다. 문제는 현실의 이상이 교과서처럼 깔끔하지 않다는 데 있습니다. 새벽에는 원래 트래픽이 낮고, 월요일 오전에는 원래 요청이 많고, 특정 장비는 다른 장비보다 원래 진동이 큽니다. 그래서 실무의 이상 탐지는 "값이 크면 이상"이 아니라 "평소 패턴에 비해 얼마나 벗어났는가"를 계산하는 쪽으로 갑니다.12
무엇을 만드는 프로젝트인가
우리가 만들 시스템은 네 층으로 구성됩니다. 먼저 데이터가 들어오고, 그 데이터를 모델이 점수화합니다. 그 다음 대시보드가 현재 상태를 보여 주고, 마지막으로 규칙 엔진이 점수와 맥락을 바탕으로 알림을 보냅니다. 이렇게 보면 간단해 보이지만, 실제로는 이 네 층이 서로 어긋나지 않도록 맞추는 일이 핵심입니다.
예를 들어 CPU 사용률이 95%라는 숫자 하나만 보면 당장 경보를 울리고 싶어집니다. 하지만 배치 작업이 돌아가는 새벽 한 시라면 정상일 수 있습니다. 반대로 CPU는 70%여도 평소보다 두 배 높고 에러 로그까지 함께 늘고 있다면, 오히려 더 위험한 신호일 수 있습니다. 결국 운영 가능한 이상 탐지 시스템은 숫자 하나를 판정하는 기계가 아니라, 정상 기준선과 변화 맥락을 함께 읽는 도구여야 합니다.34
먼저 데이터 파이프라인부터 설계한다
이상 탐지 프로젝트에서 가장 흔한 실수는 모델부터 고르는 것입니다. 하지만 이상 탐지는 데이터의 모양이 곧 성능입니다. 로그와 센서 데이터를 그저 저장만 해서는 안 되고, 나중에 "정상 패턴"을 학습할 수 있는 구조로 정리해야 합니다.
가장 먼저 챙길 것은 시간입니다. 모든 이벤트와 측정값에는 신뢰할 수 있는 타임스탬프가 있어야 하고, 가능하다면 수집 시각과 발생 시각을 분리해 두는 편이 좋습니다. 네트워크 지연이나 배치 적재 때문에 늦게 들어오는 데이터가 생길 수 있기 때문입니다. Elastic의 운영 문서도 과거 구간을 얼마나 되돌아볼지와 데이터 지연을 어떻게 다룰지 신중히 잡지 않으면 이상을 놓칠 수 있다고 설명합니다.1
그다음은 집계 단위입니다. 1초 단위로 들어오는 원시 데이터가 있다고 해서 반드시 1초 단위로 판단해야 하는 것은 아닙니다. CPU, 요청 수, 센서 진동 같은 값은 1분 평균, 5분 최대값, 15분 변화율처럼 집계 수준을 바꾸면 훨씬 읽기 쉬운 패턴이 됩니다. 지나치게 촘촘하면 노이즈가 커지고, 지나치게 굵으면 이상이 뭉개집니다. 실무에서는 운영자가 대응할 수 있는 속도와 데이터의 자연스러운 변동 주기를 함께 보며 버킷 크기를 정합니다.13
또 하나 중요한 것은 컨텍스트 필드입니다. 장비 ID, 서비스 ID, 지역, 호스트, API 이름, 버전, 배포 여부 같은 필드가 빠지면 정상 기준선을 분리해서 학습할 수 없습니다. 전체 평균은 멀쩡한데 특정 장비 한 대만 이상한 상황을 잡으려면, 그 장비를 구분할 키가 필요합니다. Microsoft Fabric의 실시간 이상 탐지 설정도 값 컬럼뿐 아니라 시간 컬럼과 그룹 기준 컬럼을 함께 지정하도록 요구하는데, 바로 이런 이유 때문입니다.4
실전에서는 다음과 같은 테이블 구조를 자주 씁니다.
timestamp: 이벤트 발생 시각entity_id: 장비, 서버, 서비스, 매장 등 관측 대상 IDmetric_name: cpu_usage, error_count, vibration_rms 같은 지표 이름metric_value: 실제 수치window_size: 1m, 5m, 1h 같은 집계 단위context: region, version, deployment_id, holiday_flag 같은 보조 정보quality_flag: 결측 보정 여부, 지연 수집 여부, 추정값 여부
여기서 quality_flag는 특히 유용합니다. 결측치를 0으로 메웠는지, 이전 값으로 채웠는지, 아예 제외했는지 나중에 추적할 수 있어야 하기 때문입니다. 이상 탐지에서 결측은 단순한 빈칸이 아니라 때로는 시스템 장애의 신호일 수도 있습니다. 센서가 갑자기 값을 보내지 않거나, 로그 수집기가 멈췄거나, 데이터 피드 자체가 끊길 수 있습니다. 그래서 "결측 처리 방식"도 모델의 일부로 취급해야 합니다.
정상 패턴은 평균이 아니라 리듬이다
이제 데이터를 모았으니 정상 상태를 학습해야 합니다. 여기서 중요한 관점 전환이 하나 있습니다. 정상은 하나의 숫자가 아니라 리듬입니다.
어떤 서비스의 요청 수는 평일 오전 9시에 올라가고 점심에 살짝 줄었다가 오후에 다시 오를 수 있습니다. 어떤 센서는 장비가 가동될 때만 진동이 커지고 야간에는 거의 0에 가까울 수 있습니다. 어떤 결제 시스템은 월말에 원래 트래픽이 급증합니다. 이런 패턴을 무시하고 전체 평균과 표준편차만 보면, 정상적인 피크를 이상으로 오해하거나 진짜 이상을 평범한 변동으로 덮어 버릴 수 있습니다.
그래서 기준선을 만들 때는 시간대, 요일, 휴일, 계절성, 최근 추세를 함께 반영하는 편이 좋습니다. Splunk의 예제는 시간, 요일, 휴일 같은 특성을 넣어 예측값을 만들고, 실제 값과 예측값의 차이를 기반으로 점수를 계산합니다.3 이 방식의 장점은 설명이 쉽다는 것입니다. "평소 월요일 오전 10시에는 이 정도여야 하는데 오늘은 많이 벗어났다"라고 말할 수 있기 때문입니다.
프로젝트 초반에는 복잡한 모델보다 아래와 같은 기준선부터 만드는 것이 좋습니다.
같은 시간대와 요일의 과거 평균 또는 중앙값
최근 N개 윈도우의 이동평균과 이동표준편차
예측 모델이 만든 기대값과 실제값의 잔차
오토인코더 같은 모델의 재구성 오차
이 네 가지는 난이도와 해석 가능성이 서로 다릅니다. 운영 초반에는 설명 가능한 점수가 특히 중요합니다. 운영자는 "왜 경보가 떴는가"를 알아야 대응할 수 있기 때문입니다. 잔차 기반 점수나 Z-score는 그 이유를 비교적 쉽게 설명할 수 있고, 오토인코더의 재구성 오차는 다변량 패턴을 잡는 데 유리합니다.23
이상 여부보다 이상 점수를 먼저 만든다
현실의 시스템은 0 아니면 1처럼 딱 잘라 움직이지 않습니다. 그래서 "이상이다/아니다"를 바로 내기보다 먼저 이상 점수를 계산하는 것이 좋습니다. 이상 점수는 말 그대로 정상 패턴에서 얼마나 벗어났는지를 숫자로 표현한 값입니다.
예를 들어 실제값과 기준선 차이의 절댓값을 표준편차로 나눈 점수를 쓸 수 있습니다. 또는 예측값과 실제값의 잔차를 제곱해 크게 벗어난 경우를 더 강하게 반영할 수도 있습니다. 딥러닝 기반이라면 입력을 다시 복원했을 때의 재구성 오차를 점수로 삼을 수 있습니다. GitHub의 간단한 실시간 이상 탐지 예제도 오토인코더 재구성 오차를 사용해 새 이벤트가 이상인지 판단하고, 그 결과를 대시보드로 바로 밀어 넣습니다.2
핵심은 이상 점수가 연속값이어야 한다는 점입니다. 연속값이면 임계값을 조정할 수 있고, 심각도 등급도 나눌 수 있고, 시간에 따라 점수가 어떻게 쌓이는지 볼 수 있습니다. 대시보드에서 운영자가 정말 보고 싶은 것은 빨간 점 하나가 아니라, "지금 이상이 커지고 있는가, 줄어드는가, 반복되는가"입니다.
실전에서 자주 쓰는 점수식은 이런 식으로 생각하면 됩니다.
anomaly_score = f(actual - baseline, rolling_change, seasonal_context, model_error)
식이 어려워 보여도 뜻은 단순합니다. 현재 값과 기준선의 차이, 최근 변화량, 시간 문맥, 모델 오차를 섞어 하나의 위험 점수로 만든다는 뜻입니다.
대시보드는 판정 화면이 아니라 판단 화면이다
이상 탐지 대시보드를 만들 때 초보자가 자주 빠지는 함정이 있습니다. 화면 가운데에 "정상" 또는 "이상"만 크게 보여 주는 것입니다. 그 화면은 멋있어 보일 수는 있지만, 운영에는 별로 도움이 안 됩니다.
운영자가 보고 싶은 것은 다섯 가지입니다. 원본 지표, 기준선, 이상 점수, 최근 추세, 그리고 관련 이벤트입니다. 이 다섯 가지가 함께 있어야 "왜 이상인지"를 빠르게 읽을 수 있습니다. OpenSearch와 Splunk의 대시보드 문서도 이상 결과를 시간축 위에 겹쳐 보거나, 현재 점수와 과거 이력, 예측 오차를 한 화면에서 확인하는 방향을 제시합니다.35
좋은 대시보드에는 보통 다음 화면이 들어갑니다.
상단 요약 카드: 현재 활성 경보 수, 심각 경보 수, 최근 24시간 이상 발생 건수
메인 시계열 차트: 실제값과 기준선, 상하 허용 범위, 이상 발생 구간 표시
이상 점수 차트: 시간에 따라 점수가 어떻게 변했는지 표시
엔터티 비교 패널: 장비나 서비스별로 어떤 대상이 가장 크게 벗어났는지 정렬
이벤트 타임라인: 배포, 장애, 설정 변경, 점검 시작 같은 운영 이벤트 표시
상태 테이블: 확인 전, 확인 중, 오탐, 조치 완료 같은 운영 상태 표시
여기서 메인 차트는 특히 중요합니다. 실제값만 보면 이상인지 판단이 어렵고, 점수만 보면 비즈니스 감각이 사라집니다. 두 개를 함께 보여 줘야 "숫자는 많이 움직였지만 기준선 안이다" 혹은 "원본 변화는 작아 보여도 평소 패턴에서는 꽤 큰 이탈이다"를 읽을 수 있습니다.
그리고 가능한 한 새 데이터가 들어올 때 자동 갱신되도록 만드는 편이 좋습니다. 완전한 실시간이 아니어도 괜찮습니다. 1분, 5분, 15분처럼 운영 리듬에 맞춘 주기적 갱신이면 충분한 경우가 많습니다. 다만 사용자는 갱신 주기를 알아야 하고, 화면에는 마지막 업데이트 시각이 보여야 합니다. 실시간처럼 보이는데 20분 전 데이터라면, 그 대시보드는 친절한 척하는 거짓말쟁이가 됩니다.
알림은 모델이 아니라 규칙 엔진이 보낸다
이상 점수가 나왔다고 해서 그 값을 그대로 슬랙이나 이메일로 보내면 금방 문제가 생깁니다. 노이즈가 많아지고, 순간 스파이크에도 경보가 터지고, 운영자는 며칠 안 가 알림을 무시하게 됩니다. 이른바 alert fatigue, 경보 피로입니다.
그래서 알림 시스템은 보통 모델 뒤에 오는 규칙 엔진으로 설계합니다. Elastic 문서가 강조하듯, 실제 운영에서는 점수 임계값뿐 아니라 연속 매치 횟수, 조회 구간, 버킷 수, 플래핑 방지 같은 조건을 함께 사용합니다.1 즉, "점수가 80을 넘으면 알림"이 아니라 "최근 15분 동안 5분 버킷 3개 연속으로 80 이상이면 심각 경보" 같은 식으로 다듬어야 합니다.
예를 들어 다음과 같은 규칙을 둘 수 있습니다.
이상 점수 60 이상이 2회 연속 발생하면 경고
이상 점수 80 이상이 3회 연속 발생하면 심각
서비스 A는 매출 영향이 크므로 같은 점수라도 우선순위를 높임
배포 직후 10분은 일시적 변동 구간으로 별도 규칙 적용
회복 상태가 2개 윈도우 이상 유지되면 자동으로 경보 종료
이런 규칙을 두는 이유는 간단합니다. 운영에는 "탐지 민감도"와 "알림 신뢰도"를 동시에 챙겨야 하기 때문입니다. 민감도만 높이면 오탐이 늘고, 신뢰도만 높이면 미탐이 늘어납니다. 이 균형을 맞추는 곳이 바로 규칙 엔진입니다.
또 하나 잊기 쉬운 것이 회복 알림입니다. 문제가 생겼다는 메시지만 있고 정상으로 돌아왔다는 알림이 없다면, 운영자는 끝없이 불안해집니다. Elastic은 조건 충족 시 알림뿐 아니라 조건이 더 이상 충족되지 않을 때의 recovery action도 지원하는데, 실제 운영에서 매우 중요한 기능입니다.1
운영 흐름까지 설계해야 진짜 시스템이 된다
모델이 이상을 잡고, 대시보드가 보여 주고, 규칙이 알림을 보냈습니다. 이제 끝일까요? 아직 아닙니다. 진짜 중요한 것은 그 다음입니다. 누가, 어떻게, 무엇을 할 것인가가 정해져 있어야 합니다.
운영 가능한 이상 탐지 시스템에는 최소한 다음 흐름이 필요합니다.
이상이 발생하면 경보가 생성됩니다. 경보에는 발생 시각, 대상 ID, 점수, 원본 지표, 관련 로그 링크, 담당 팀, 심각도, 권장 조치가 담깁니다. 운영자는 경보를 열어 보고 상태를 바꿉니다. 처음에는 new, 확인을 시작하면 acknowledged, 실제 문제로 판단되면 in_progress, 오탐이면 false_positive, 조치가 끝나면 resolved 같은 상태로 바뀝니다. 이 상태 전이가 쌓이면 나중에 오탐률과 대응 시간, 재발률을 분석할 수 있습니다.
이 흐름이 없는 시스템은 탐지는 잘해도 운영에는 약합니다. 모두가 "이상은 떴는데 그래서 누가 뭘 했지?"라는 질문 앞에서 멈추게 됩니다. 반대로 상태 관리가 되면 이상 탐지 결과가 티켓 시스템, 온콜 프로세스, 장애 회고와 연결됩니다. 그때부터 이상 탐지는 모델 프로젝트가 아니라 운영 체계의 일부가 됩니다.
이번 프로젝트의 예시 아키텍처
이 장에서는 너무 무거운 인프라보다, 이해하기 쉬운 운영형 구조를 기준으로 생각해 봅시다.
데이터는 애플리케이션 로그나 센서 수집기에서 들어옵니다. 수집 레이어는 이벤트를 시간 기준으로 정렬해 저장하고, 1분 또는 5분 단위 집계를 만듭니다. 점수 계산 서비스는 새 버킷이 생길 때마다 기준선과 비교해 이상 점수를 계산합니다. 계산 결과는 anomaly_scores 테이블 또는 시계열 저장소에 기록됩니다. 대시보드는 이 저장소를 읽어 차트를 갱신합니다. 규칙 엔진은 새 점수를 읽어 경보를 생성하고, 슬랙이나 이메일, 웹훅으로 통지합니다. 운영자는 대시보드에서 경보를 확인하고 상태를 바꿉니다.
아주 작은 규모라면 배치 방식도 충분합니다. 예를 들어 5분마다 집계, 점수 계산, 알림 평가를 순서대로 돌릴 수 있습니다. 반대로 실시간성이 중요한 시스템이라면 이벤트 스트림과 메시지 큐를 붙여 거의 즉시 처리할 수 있습니다. GitHub의 anomaly-dashboard 예제는 새 값이 들어오면 Python 탐지 서비스가 재구성 오차를 계산하고, 결과를 Socket.IO로 대시보드에 밀어 주는 단순한 구조를 보여 줍니다.2 데모로는 훌륭하고, 운영으로 가려면 여기서 큐, 비동기 처리, 인증, 배치 추론, 모델 버전 관리 같은 요소를 추가하면 됩니다.
이상 점수 테이블과 알림 테이블을 분리하자
실무에서 꽤 중요한 설계 팁 하나를 소개하겠습니다. 점수 저장소와 알림 저장소를 분리하는 것입니다.
점수 테이블은 모델이 계산한 사실을 기록합니다. 예를 들면 timestamp, entity_id, metric_name, baseline, actual, residual, anomaly_score, model_version 같은 필드가 들어갑니다. 반면 알림 테이블은 운영 판단의 결과를 기록합니다. alert_id, severity, rule_id, status, assignee, first_triggered_at, last_seen_at, closed_at 같은 필드가 들어갑니다.
이 둘을 섞어 버리면 나중에 문제가 생깁니다. 점수는 연속적으로 쌓이는데 알림은 여러 점수를 묶어 하나로 관리해야 할 때가 많기 때문입니다. 같은 장비에서 10분 동안 계속 점수가 높게 나왔다면, 운영자는 열 개의 경보보다 하나의 지속 경보를 원합니다. 즉, 모델의 시간 해상도와 운영의 사건 해상도는 다를 수 있습니다.
평가 기준도 운영 관점으로 바꿔야 한다
이상 탐지 프로젝트의 성과를 평가할 때도 조심해야 합니다. 모델 정확도만 보면 현장 감각을 놓치기 쉽습니다. 이상 탐지는 보통 불균형 데이터이기 때문에, 단순 정확도보다 정밀도, 재현율, F1, PR-AUC 같은 지표가 더 중요하게 쓰입니다.67 특히 경보 시스템에서는 "얼마나 많이 잡았는가" 못지않게 "쓸데없는 경보를 얼마나 줄였는가"가 중요합니다.
하지만 여기서 한 걸음 더 나가야 합니다. 운영형 프로젝트에서는 모델 지표만으로 충분하지 않습니다. 다음과 같은 운영 지표를 함께 봐야 합니다.
알림당 확인 시간
오탐으로 닫힌 비율
실제 장애를 놓친 미탐 사례 수
동일 원인으로 중복 생성된 경보 수
심각 경보의 평균 해결 시간
운영자가 유용하다고 평가한 경보 비율
이 지표들을 보면 시스템이 "잘 맞추는가"를 넘어 "쓸 만한가"를 알 수 있습니다. 예를 들어 F1은 괜찮아도 운영자가 절반 이상을 오탐으로 닫는다면, 그 시스템은 현장 적합성이 낮은 것입니다.
배포 후 개선 루프를 반드시 만든다
이상 탐지 시스템은 배포가 끝이 아니라 시작입니다. 계절이 바뀌고, 서비스가 성장하고, 장비가 교체되고, 사용 패턴이 변하면 기준선도 함께 흔들립니다. 그래서 운영자 피드백을 모델과 규칙 양쪽에 다시 넣는 루프가 필요합니다.48
가장 실용적인 개선 루프는 이렇습니다. 우선 모든 경보에 대해 운영자가 상태를 남기게 합니다. 오탐인지, 진짜 이상인지, 조치가 필요했는지 기록합니다. 그리고 매주 또는 매월 경보 로그를 분석합니다. 어떤 규칙이 너무 민감했는지, 어떤 장비군에서만 오탐이 많은지, 어떤 시간대에 지연 수집 때문에 오판이 생기는지 살펴봅니다. 그 결과에 따라 임계값을 조정하고, lookback 구간을 바꾸고, 기준선을 다시 학습하고, 필요하면 모델을 교체합니다.
모니터링 관점에서는 점수 분포 자체도 관찰해야 합니다. 예전에는 대부분 0.1에서 0.3 사이였는데 최근 2주 동안 0.4에서 0.6으로 밀려 올라갔다면, 뭔가 정상 기준선이 흔들리고 있다는 뜻일 수 있습니다. ML 운영 도구들은 이런 분포 변화와 드리프트를 계속 추적해 모델 성능 저하를 조기에 알아차리는 방향으로 발전해 왔습니다.89
여기서 중요한 것은 "재학습"만 정답이 아니라는 점입니다. 어떤 문제는 규칙만 손봐도 해결되고, 어떤 문제는 집계 단위를 바꾸는 것이 더 효과적이며, 어떤 문제는 애초에 입력 데이터 품질부터 고쳐야 합니다. 즉, 개선 루프는 모델 재학습 파이프라인이 아니라 운영 학습 파이프라인에 가깝습니다.
작은 예제로 끝까지 그려 보기
이제 하나의 구체적인 시나리오를 상상해 보겠습니다. 당신은 공장 설비의 진동 센서를 모니터링하는 팀에 있습니다. 센서는 10초마다 값을 보냅니다. 우리는 1분 단위로 평균, 최대, 표준편차를 집계합니다. 장비마다 정상 진동 수준이 다르므로 machine_id를 기준으로 분리해 기준선을 학습합니다. 주간과 야간의 가동 패턴이 다르기 때문에 시간대 특성도 함께 넣습니다.
모델은 우선 최근 4주 같은 시간대의 중앙값을 기준선으로 쓰고, 현재 값과의 차이를 MAD 또는 표준편차 기반 점수로 환산합니다. 여기에 최근 15분 변화율을 추가해 갑작스러운 치솟음을 반영합니다. 점수 70 이상이 3회 연속이면 경고, 85 이상이 2회 연속이면 심각으로 정의합니다. 점수가 높더라도 설비 점검 일정이 등록된 시간대라면 경보 우선순위를 자동으로 낮춥니다.
대시보드에서는 첫 화면에 설비별 현재 상태를 카드로 보여 줍니다. 카드를 누르면 실제 진동 값, 기준선, 허용 범위, 이상 점수, 최근 점검 이력, 담당자 메모가 한 페이지에 나옵니다. 운영자는 경보를 확인하고 "베어링 마모 의심, 현장 점검 요청" 같은 메모를 남깁니다. 그 메모는 나중에 라벨처럼 쌓여, 모델 개선과 운영 지식 축적에 동시에 도움이 됩니다.
이 시나리오의 아름다운 점은 모델이 특별히 화려하지 않아도 시스템이 유용하다는 것입니다. 운영자는 "왜 떴는지"를 이해할 수 있고, "누가 무엇을 할지"가 정해져 있고, 피드백이 다시 시스템에 반영됩니다. 이것이 바로 제품으로서의 머신러닝입니다.
프로젝트를 마치며
이상 탐지 대시보드 프로젝트는 많은 것을 가르쳐 줍니다. 첫째, 이상 탐지의 핵심은 모델 선택보다 정상 기준선을 어떻게 정의하느냐에 있습니다. 둘째, 실무의 이상은 단일 판정보다 점수와 맥락으로 다뤄야 합니다. 셋째, 좋은 대시보드는 빨간불을 켜는 화면이 아니라 운영 판단을 빠르게 만드는 화면입니다. 넷째, 알림은 모델이 직접 보내는 것이 아니라 규칙 엔진이 운영 현실에 맞게 조정해 보내야 합니다. 마지막으로, 탐지는 시작일 뿐이고 진짜 가치는 조치와 개선 루프에서 나옵니다.
이제 여러분은 이상 탐지 모델을 "학습했다"는 말보다 더 강한 말을 할 수 있습니다. 운영자가 실제로 쓸 수 있는 이상 탐지 시스템을 설계했다고 말할 수 있습니다. 그리고 그 차이가, 노트북 속 실험과 현실 제품 사이의 가장 큰 차이입니다.
참고
1Generating alerts for anomaly detection jobs
2GitHub - Adilolla/anomaly-dashboard
3Deep dive: Create a data ingest anomaly detection dashboard using ML-SPL commands
4Anomaly detection in Real-Time Intelligence
5Anomaly detection visualizations and dashboards - OpenSearch Documentation
7Metrics — Anomalib documentation
8How to stop worrying and start monitoring your ML models: a step-by-step guide
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.