제가 함께 일했던 모든 딜리버리 매니저(delivery manager)들은 월요일 아침마다 예측 모델을 실행합니다. 그것은 '공포(dread)'라고 불립니다.

포트폴리오를 열고 30개의 프로젝트를 훑어보면, 당신의 직감이 그것들을 분류합니다. '이 다섯 개는 걱정되네, 저 20개는 괜찮아, 그리고 저 하나 — 저 하나는 이번 달에 터지겠군.' 수학은 없습니다. 하지만 이것은 실제 모델입니다. 입력값(속도(velocity), 에스컬레이션(escalations), 연락이 뜸해진 PM 등), 가중치(수년간의 고통을 통해 학습된 것), 그리고 출력값(오늘 누구에게 주의를 기울일 것인가)이 존재하기 때문입니다.

저는 SRE(Site Reliability Engineering)와 DevOps 분야에서 10년 동안 그런 직감을 쌓아왔습니다. 이제 저는 AI 엔지니어링(AI engineering)으로 전환하고 있으며, 제가 스스로에게 강제한 첫 번째 일은 모델을 학습시키지 않는 것이었습니다. 대신 저는 사고 문서(thinking documents)를 작성했습니다. 코드 작성 이전에 문제를 프레이밍(framing)하는 것입니다. 처음에는 빌드 시간을 낭비하는 것처럼 느껴졌습니다.

하지만 그것이 핵심이었다는 것이 밝혀졌습니다.

어려운 부분은 수학이 아닙니다.

처음 시작할 때, 저는 머신러닝(ML)의 어려움이 수학에 있다고 가정했습니다. 그래디언트(Gradients), 손실 함수(loss functions), 그리스 문자들 말입니다. 그렇지 않습니다. 문제가 제대로 프레이밍(framed)되고 나면 그 중 대부분은 이미 결정되어 있습니다.

진짜 어려운 부분은 알고리즘(algorithm)의 상류(upstream)에 있는 모든 것입니다. 당신이 실제로 묻고 있는 질문은 무엇인가? 잘못된 답변의 비용은 얼마인가? 그리고 모델이 답변을 내놓았을 때 어떤 일이 발생하는가? 이것들을 틀리면 세상에서 가장 우아한 모델이라 할지라도 잘못된 것을 정확하게 예측하게 됩니다.

제 분야의 실제 문제를 통해 이것이 어떻게 나타나는지 살펴보겠습니다.

워크스루(Walk-through): IT 서비스의 SLA 위반 예측

작업은 간단해 보입니다. 이번 달에 어떤 딜리버리 프로젝트가 SLA(Service Level Agreement)를 위반할지 예측하는 것입니다. 데이터를 가져오고, 분류기(classifier)를 학습시키면 끝입니다. 하지만 단 하나의 모델이 실행되기 전에 네 가지 질문이 모든 것을 결정합니다.

1. 이벤트의 정확한 정의는 무엇인가? 이번 달에 보고된 침해(breach)인가? 이번 달에 탐지된 것인가? 아니면 이번 달로 근본 원인(root-cause)이 파악된 것인가? 각 정의에 따라 학습 데이터(training data), 레이블(labels), 그리고 시스템이 실제로 예측하는 대상이 달라집니다. 부주의하게 선택한다면, 아무도 묻지 않은 질문에 답하는 모델을 출시하게 될 것입니다.

2. 어떤 행동을 위한 예측인가? 위험한 프로젝트가 단순히 PM에게 이메일 하나를 보내는 수준이라면, 오탐(false alarm)의 비용은 저렴합니다. 하지만 그로 인해 다른 고객의 프로젝트에 투입된 엔지니어 두 명을 빼내야 한다면, 모든 오탐에는 희생자가 따릅니다. 동일한 모델, 동일한 점수라 할지라도 완전히 다른 시스템이 됩니다.

3. 확신에 찬 오답(confident-wrong)의 비용은 얼마인가? 건강한 프로젝트에 대해 0.9의 침해 위험(breach-risk)을 내놓는 것은 돈과 신뢰를 낭비하는 일입니다. 반면, 실제 침해가 발생한 프로젝트에 대해 0.1을 내놓는 것은 고객 관계를 태워버리는 일입니다. 이러한 비용은 대칭적이지 않으며, 어떤 알고리즘도 이를 알지 못합니다. 각 실패 방향이 돈과 평판 측면에서 어떤 비용을 초래하는지는 오직 당신만이 알고 있습니다.

4. 위험 구역(dangerous zone)은 어디인가? 우리에게 그것은 모델이 어깨를 으쓱하는 지점인 0.5입니다. 0.5는 "전혀 모르겠다"는 의미이며, 그 시점에는 유능한 관리자의 머릿속에 있는 '월요일 아침의 공포 모델'이 분류기(classifier)보다 더 강력하게 작동합니다. 어떤 확률이 어떤 행동을 유발할 것인가는 비즈니스 결정입니다. 그것은 결코 모델이 결정할 문제가 아니었습니다.

이 네 가지 질문에서 무엇이 빠져 있는지 주목하십시오. 로지스틱 회귀(logistic regression), 랜덤 포레스트(random forests), 또는 신경망(neural networks)에 대한 언급은 전혀 없습니다. 이 네 가지가 결정되면 알고리즘에 대한 질문("이것은 분류(classification)인가? 회귀(regression)인가? 비지도 학습(unsupervised)인가?")은 스스로 답을 내놓게 됩니다. 이것이 알고리즘이 첫 번째 결정이 아니라 마지막 결정인 이유입니다.

운영(ops)에서 빌려온 프레임워크

이 모든 것이 저에게 새로운 것은 아니었습니다. 단지 이것이 머신러닝(ML)에도 적용된다는 사실을 몰랐을 뿐입니다. SRE(Site Reliability Engineering)에서 우리는 다음과 같은 질문을 던지지 않고서는 모니터링 알람을 절대 배포하지 않습니다. "정확히 무엇이 알람을 발생시키는가? 누가 호출(page)되는가? 그들은 무엇을 하는가? 그리고 새벽 3시에 발생하는 오탐(false page)의 비용은 얼마인가?" 이러한 답변이 없는 알람은 호출기가 달린 소음일 뿐입니다.

그러한 답변이 없는 예측도 마찬가지입니다. 갈 곳을 잃은 숫자일 뿐입니다.

그래서 이제 저는 어떤 모델을 건드리기 전에, 다음 네 가지를 적어둡니다:

이 예측이 어떤 결정에 기여하는지, 그리고 누가 그 결정에 따라 행동하는지를 한 문장으로 정의합니다.
두 가지 실패 방향(failure directions)에 대한 비용을 산정합니다. 비용을 산정할 수 없다면, 임계값(threshold)을 설정할 준비가 되지 않은 것입니다.
정확한 이벤트 정의와 그 시간 범위(time window)를 설정합니다.
그다음에야 비로소: 이 질문의 형태에 적합한 알고리즘 군(family of algorithm)이 무엇인지 결정합니다.

4번 항목은 10분이면 충분합니다. 1~3번 항목은 며칠이 걸립니다. 그리고 이 과정들이 있기에 4번 항목이 쉬워지는 것입니다.

알고리즘은 당신이 내리는 마지막 결정입니다.

이 글은 시리즈의 첫 번째 포스트입니다. 저는 고전적인 머신러닝 (ML) 알고리즘들을 하나씩(다음은 로지스틱 회귀 (logistic regression)입니다) 살펴보며, 각 알고리즘이 당신의 세계에 대해 무엇을 예측(bet)하는지, 그리고 그것이 프로덕션 (production) 환경에서 무엇을 의미하는지를 동일한 관점에서 다룰 예정입니다. 저는 10년 차 SRE/DevOps 엔지니어(현재 Movate를 통해 Google의 Piper 인프라에서 근무 중)로서 AI 플랫폼 엔지니어링 분야로 전환하고 있으며, 그 과정을 공개적으로 기록하고 있습니다. 만약 ML 이외의 이유로 ML 프로젝트가 실패하는 것을 목격한 적이 있다면, 댓글로 그 이야기를 들려주세요.