모니터링과 CI/CD — 자동화된 품질 관리

오늘은 ML 모니터링이 왜 필요한지 살펴보겠습니다.

배포 후가 진짜 시작이라는 의미, 함께 확인해 봅시다.

ML 모니터링은 배포된 모델의 입력과 예측을 지속 관찰하는 체계입니다.

단순 서버 상태를 넘어 모델 품질 자체를 추적합니다.

그림 상단 그래프를 보시면 시간에 따른 성능 변화가 나타납니다.

전통 소프트웨어는 시간이 지나도 성능이 유지됩니다.

반면 ML 모델은 코드가 그대로인데 성능이 서서히 떨어집니다.

이 격차 구간이 바로 조용한 실패, Silent Failure입니다.

서버는 정상 응답을 반환하며 겉으로는 문제없어 보이죠.

추천 시스템 클릭률이 절반으로 떨어져도 서버는 멀쩡합니다.

가운데 비교표를 보시면 두 시스템의 차이가 명확합니다.

왼쪽이 전통 소프트웨어, 오른쪽이 ML 시스템입니다.

전통 SW는 버그가 생기면 즉시 에러 로그로 인지합니다.

ML 시스템은 성능이 저하돼도 아무 경고도 뜨지 않습니다.

왼쪽엔 '만들면 끝', 오른쪽엔 '배포하면 시작'입니다.

학습 시점 분포와 운영 시점 분포가 달라지는 건 시간문제입니다.

이제 하단 세 박스를 보시면 실패의 세 원인이 나옵니다.

첫 번째는 데이터 분포 이동, 안정성 가정의 붕괴입니다.

사용자 행동 변화, 계절성, 팬데믹으로 분포가 끊임없이 이동합니다.

두 번째는 피드백 지연, 즉 실제 정답이 즉시 없다는 문제입니다.

대출 심사는 실제 부도 여부를 알기까지 수개월이 걸립니다.

그래서 입력 분포 변화를 대리 지표로 감시해야 합니다.

세 번째는 비용의 비대칭성입니다.

모니터링 구축은 며칠이지만 미감지 장애는 수백 배 손실로 이어집니다.

2020년 질로우 사례에서 주택 예측 실패로 5억 달러 손실이 났습니다.

구글 ML 기술 부채 논문도 유지보수 비용이 대부분이라 경고합니다.

모니터링은 시스템 건강, 데이터 품질, 모델 품질 세 계층으로 구성됩니다.

결국 모니터링 없는 ML은 계기판 없는 비행과 같습니다.

모니터링은 선택이 아닌 생존 조건임을 꼭 기억해 주세요.