머신러닝 엔지니어

모델이 잘 만들어졌다는 것과 서비스에서 쓸 수 있다는 것은 다른 이야기입니다. 실험 환경에서는 한 건을 예측하는 데 2초가 걸려도 결과만 맞으면 됩니다. 사용자가 화면을 열고 기다리는 자리에서는 2초가 그대로 느린 화면입니다.

페이지덱에서 문서 추천 모델이 그랬습니다. 만든 쪽에서는 정확도를 보고했고 숫자는 괜찮았습니다. 서비스에 올리려고 보니 한 번 예측에 2.3초가 걸렸고, 학습에 쓴 데이터는 손으로 모아 만든 파일이었습니다. 다시 학습시키는 절차는 아예 없었습니다. 그대로 올린 뒤 3주가 지나자 추천 목록에 오래된 문서만 올라오기 시작했습니다. 새로 만들어진 문서가 모델에 들어가지 않았기 때문입니다.

머신러닝 엔지니어는 이 구간을 맡는 자리입니다. 모델을 서비스가 부를 수 있는 형태로 감싸고, 학습에 쓸 데이터가 매일 같은 모양으로 들어오게 만들고, 성능이 떨어질 때 알아채고 다시 학습시키는 일까지가 범위입니다.

하루는 어제 모델이 내놓은 결과와 응답 시간을 확인하는 일로 시작해, 파이프라인이나 배포를 손보는 일로 끝납니다. 반복되는 일은 여섯 가지입니다.

1. 지표를 셋으로 나눠 봅니다. 예측이 맞는 정도, 응답이 돌아오는 시간, 호출이 실패한 비율입니다. 셋 가운데 하나만 나빠져도 사용자에게는 같은 고장으로 보입니다.
2. 학습에 쓸 데이터가 매일 같은 모양으로 들어오는지 확인합니다. 열 하나가 사라지거나 값의 범위가 바뀌어도 학습은 조용히 진행되고 결과만 나빠집니다. 이 조용한 실패를 잡는 것이 하루 중 가장 값나가는 확인입니다.
3. 모델을 서비스가 부를 수 있는 창구로 감쌉니다. 응답 시간 목표를 먼저 정하고 그 안에 들어오게 만듭니다. 모델을 가볍게 바꾸거나, 자주 나오는 요청의 답을 미리 계산해 두거나, 실시간 대신 하루 한 번 미리 만들어 두는 방식을 씁니다.
4. 배포와 되돌리기를 준비합니다. 새 모델을 전체에 켜지 않고 일부 요청에만 보내 며칠 지켜보고, 나빠지면 이전 모델로 되돌립니다. 모델은 코드와 달리 틀렸다는 것이 바로 드러나지 않으므로 되돌릴 수 있는 상태를 늘 유지합니다.
5. 다시 학습시키는 일을 자동으로 돌립니다. 주기를 정해 돌리거나 성능이 떨어진 신호가 잡히면 돌립니다. 이 자동화 전체를 묶어 부르는 말이 MLOps입니다.
6. 들어오는 데이터의 분포가 변했는지 봅니다. 모델은 그대로인데 사용자가 쓰는 방식이 바뀌면 같은 모델이 다른 결과를 냅니다. 이때는 모델을 고치는 것이 아니라 다시 학습시키는 것이 답입니다.

모델을 만드는 쪽과 서비스를 만드는 쪽 사이에 서는 자리라 양쪽 말을 다 알아야 합니다.

• 데이터 사이언티스트 — 모델을 설계하고 실험하는 쪽입니다. 넘겨받을 때 무엇을 재현해야 하는지를 먼저 맞춥니다. 학습에 쓴 데이터와 설정이 함께 오지 않으면 같은 모델을 다시 만들 수 없습니다.
• 백엔드 개발자 — 모델을 어디서 부를지, 응답이 늦거나 실패했을 때 무엇을 대신 보여 줄지를 함께 정합니다. 페이지덱에서는 태오와 추천이 실패하면 최근 문서 목록을 보여 주기로 정해 뒀습니다.
• 애널리틱스 엔지니어 — 학습에 쓸 데이터를 정리된 형태로 만들어 주는 쪽입니다. 이 자리가 비어 있으면 머신러닝 엔지니어가 그 일까지 하게 되고 모델 쪽에 쓸 시간이 사라집니다.
• 프로덕트 매니저 — 무엇을 좋은 결과로 볼지 정합니다. 정확도가 오르는 것과 제품 지표가 오르는 것은 다른 일이라, 지현과는 추천 후보에 무엇을 넣을지부터 이야기합니다.
• 데이터 분석가와 BI 담당자 — 모델이 내놓은 결과를 사람이 읽는 형태로 바꿔 놓는 쪽입니다. 모델이 왜 그렇게 추천했는지를 설명해야 할 때 이쪽과 함께 봅니다.
• 보안과 법무 담당 — 학습 데이터에 사람을 알아볼 수 있는 값이 섞여 있는지, 그 데이터를 어디까지 쓸 수 있는지를 확인합니다.

"정확도는 좋은데 응답이 2.3초예요. 이 상태로는 못 올립니다."

모델의 품질과 서비스에 올릴 수 있는지가 다른 문제라는 지적입니다.

"학습 데이터가 손으로 모은 파일이에요. 파이프라인부터 만들어야 재학습이 됩니다."

한 번 만드는 일과 계속 돌리는 일의 차이를 짚은 말입니다.

"새 모델을 요청 10퍼센트에만 켜고 이틀 보겠습니다."

모델 배포를 되돌릴 수 있는 형태로 하겠다는 뜻입니다.

태오와 함께 추천 모델을 올리는 작업이 페이지덱에서 이 역할이 처음 생긴 계기였습니다. 실시간으로 예측하는 대신 하루 한 번 사용자마다 추천 목록을 미리 만들어 두는 방식으로 바꿔 응답을 2.3초에서 180밀리초로 줄였습니다. 학습 데이터는 매일 같은 시각에 자동으로 모이게 만들고 재학습을 주 1회로 걸었습니다. 3주 뒤에 오래된 문서만 올라오던 문제는 사라졌습니다.

그 뒤에 남은 문제는 다른 종류였습니다. 정확도 지표는 그대로였는데 추천을 눌러 보는 비율이 오르지 않았습니다. 지현과 함께 확인해 보니 모델은 사용자가 이미 자주 열던 문서를 잘 맞히고 있었습니다. 맞히는 일과 쓸모 있는 일이 다르다는 것이 그 자리에서 정리됐고, 추천 후보에서 최근에 열어 본 문서를 빼기로 정했습니다.

데이터 사이언티스트의 다른 이름이라고 읽는 경우가 가장 많습니다. 둘 다 모델을 다루고 이름에 비슷한 말이 들어가기 때문입니다. 하지만 맡는 구간이 다릅니다. 앞쪽은 어떤 모델이 이 문제에 맞는지를 실험으로 찾고, 이쪽은 그 모델이 초당 수백 번 불려도 버티게 만들고 석 달 뒤에도 같은 성능을 내게 유지합니다. 한 사람이 둘을 다 하는 팀도 있지만, 그 경우 대개 한쪽이 밀립니다.

모델을 올리면 일이 끝난다고 읽는 것도 흔합니다. 배포가 끝이라는 감각은 코드에서 온 것입니다. 그런데 모델은 코드가 그대로여도 성능이 내려갑니다. 사용자가 쓰는 방식이 바뀌고 데이터가 바뀌기 때문입니다. 올린 뒤에 감시와 재학습을 붙이지 않으면 반년쯤 뒤에 아무도 모르는 사이에 추천이 엉뚱해집니다.