MLOps

모델을 만드는 일과 그 모델을 계속 돌리는 일은 다른 일인데, 한동안 같은 일로 취급됐습니다. 분석가가 노트북에서 정확도 92퍼센트짜리 모델을 이 주 만에 만들면 거기서 일이 끝난 것처럼 보였습니다. 실제로는 그때부터가 시작이었습니다. 그 모델을 제품 안에서 돌리려면 코드를 서버용으로 다시 쓰고, 매일 들어오는 기록을 모델에 흘려 넣는 장치를 붙여야 했습니다. 만드는 데 이 주, 올리는 데 석 달이 걸렸습니다.

올린 뒤가 더 문제였습니다. 모델은 한 번 올려 두면 계속 같은 성능을 내지 않습니다. 알려 주는 장치가 없으니 성능이 내려가도 반년쯤 지나 고객 문의가 늘어난 뒤에야 알았습니다.

그래서 회의 장면이 늘 비슷했습니다. 태오가 "지금 그 모델 몇 점 나와요" 라고 물으면 아무도 답하지 못했습니다. 마지막으로 잰 것이 넉 달 전인데, 그때 어느 날짜까지의 기록으로 학습했는지가 남아 있지 않아 다시 재려면 반나절이 들었습니다.

MLOps 는 코드에 이미 하던 일을 모델에도 하자는 제안입니다. 코드 쪽에는 CI/CD, 즉 고친 코드를 자동으로 검사하고 통과하면 배포까지 잇는 흐름이 이미 있었습니다. 모델도 학습부터 검증, 배포, 감시까지를 한 줄로 이어 두면 사람이 기억하지 않아도 절차가 굴러갑니다.

돌아가는 순서는 여섯 단계이고, 마지막이 첫 단계로 돌아와 고리를 이룹니다.

1. 데이터를 모으고 그 시점을 고정합니다. 학습 데이터는 모델을 가르치는 데 쓰는 기록 전체인데, 어느 날짜까지의 기록을 썼는지 꼬리표를 붙여 따로 보관합니다. 같은 모델을 다시 만들어야 할 때 같은 데이터가 없으면 같은 결과가 나오지 않습니다.
2. 학습을 한 번의 실행으로 묶습니다. 기록에서 피처, 즉 모델이 실제로 들여다볼 숫자 묶음을 뽑는 코드부터 학습까지를 스크립트 하나로 이어 둡니다. 분석가의 노트북이 아니라 회사 서버에서 돌아야 합니다.
3. 검증을 게이트로 겁니다. 새로 만든 모델의 점수가 기준에 못 미치면 다음 단계로 넘어가지 못하게 막습니다. 페이지덱은 스팸 판정 모델의 정밀도와 재현율 중 재현율이 0.80 아래로 떨어지면 배포를 자동으로 중단합니다. 실제 스팸 열 건 중 여덟 건은 잡아야 한다는 뜻입니다.
4. 배포합니다. 통과한 모델을 바로 전체에 붙이지 않고 들어오는 요청의 5퍼센트에만 먼저 태웁니다. 하루 지켜보고 이상이 없으면 나머지로 넓히고, 문제가 보이면 이전 모델로 되돌립니다.
5. 감시합니다. 예측 결과만 보는 것이 아니라 들어오는 입력이 학습 때와 비슷한 모양인지를 매일 잽니다. 모델 드리프트, 즉 처음엔 잘 맞던 모델이 시간이 지나며 무뎌지는 현상은 대개 입력 쪽에서 먼저 신호가 납니다.
6. 재학습으로 돌아갑니다. 감시에서 기준을 벗어나면 1번으로 돌아가 최근 데이터로 다시 학습합니다. 페이지덱은 이 고리를 2주에 한 번 돌립니다.

모델이 제품 화면 안에서 매일 예측을 내놓고 있고, 그 예측이 틀리면 사용자가 바로 느끼는 자리라면 이 체계가 값을 합니다. 페이지덱의 스팸 계정 판정이 그렇습니다. 하루 4,000건을 판정하고 잘못 막으면 멀쩡한 팀이 로그인을 못 하니, 성능이 내려갔다는 사실을 반년 뒤가 아니라 그날 알아야 합니다. 모델이 여러 개일 때도 그렇습니다. 하나는 사람이 기억으로 관리하지만 다섯 개가 되면 어느 것을 언제 다시 학습시켰는지가 섞입니다.

반대로 분기에 한 번 돌려 보고서에 숫자를 싣는 모델 하나뿐이라면 갖추는 비용이 더 큽니다. 절차를 세우는 데 몇 달이 드는데, 그 모델은 분석가가 반나절 들여 다시 돌리면 그만입니다.

한계는 두 가지입니다. 첫째, 앞단에 데이터 파이프라인이 없으면 성립하지 않습니다. 원천 데이터를 분석할 수 있는 형태로 옮기고 다듬는 흐름이 매일 같은 시각에 돌아 주지 않으면, 자동 재학습은 어제 빠진 데이터로 학습한 모델을 오늘 배포합니다. 둘째, 자동화는 판단을 대신해 주지 않습니다. 재현율 0.80 이라는 기준선을 어디에 그을지는 사람이 정하고, 그 선을 잘못 그으면 체계는 잘못된 모델을 성실하게 배포합니다.

"모델 성능이 3주째 내려가고 있는데 재학습 파이프라인은 왜 안 돌았어요?"

감시는 붙어 있는데 그 신호가 재학습으로 이어지지 않았다는 지적입니다.

"이거 MLOps 붙이기 전에는 배포 한 번에 이 주 걸렸어요."

체계를 갖추기 전후의 시간 차이를 근거로 드는 말입니다.

"지금 서비스에 떠 있는 게 어느 시점 데이터로 학습한 모델인지부터 확인해 주세요."

기록이 남아 있느냐를 묻는 말이고, 이 질문에 바로 답하지 못하면 아직 체계가 없는 상태입니다.

페이지덱에서는 스팸 계정 판정 모델이 처음으로 이 고리에 올라갔습니다. 그전에는 태오가 한 달에 한 번 손으로 재학습을 돌렸는데, 다른 일이 밀리면 두세 달을 건너뛰었습니다. 그 사이 스팸 쪽이 수법을 바꾸면 정상 계정이 잘못 막혔고, 규원에게 항의 메일이 온 뒤에야 알려졌습니다.

고리를 올린 뒤에는 순서가 뒤집혔습니다. 재현율이 기준 아래로 내려간 날 아침에 태오에게 알림이 오고, 그날 재학습이 돌고, 5퍼센트에서 하루 지켜본 뒤 전체로 넓힙니다. 지현은 판정 기준을 얼마나 조일지만 정합니다. 사람이 하던 일이 줄어든 게 아니라 기억해야 하던 일이 줄었습니다.

도구를 도입하면 MLOps 가 갖춰진다고 보는 경우가 가장 많습니다. 소개 자료가 대부분 도구 이름으로 설명하니 그렇게 읽힙니다. 하지만 이 체계의 핵심은 도구가 아니라 판정 기준과 되돌아가는 고리입니다. 어떤 점수 아래면 배포를 막을지, 무엇이 벌어지면 재학습을 돌릴지를 정해 두지 않은 채 도구만 깔면, 실행 이력만 예쁘게 쌓이고 성능이 내려가는 것은 여전히 아무도 모릅니다. 반대로 기준을 정해 두면 스크립트 몇 개와 알림 하나로도 시작할 수 있습니다.

배포하면 모델 일이 끝난다는 오해도 흔합니다. 일반적인 코드는 고치지 않으면 어제와 같이 동작하니 그 감각이 그대로 옮겨 옵니다. 모델은 다릅니다. 바깥 데이터가 바뀌면 코드가 그대로여도 예측이 빗나가기 시작합니다. 그대로 두면 성능이 내려가는 동안 아무 경보도 울리지 않고, 고객 문의라는 가장 늦은 경로로 소식을 듣게 됩니다.