머신러닝

페이지덱에 무료 플랜이 열린 뒤 광고 문서를 대량으로 찍어 내는 계정이 늘었습니다. 태오가 처음 한 일은 조건을 적는 것이었습니다. 문서 하나에 바깥 링크가 열 개를 넘으면 잠그고, 가입한 지 한 시간 안에 문서를 서른 건 넘게 만들면 잠그고, 제목에 특정 단어가 들어가면 잠갔습니다. 한 달 만에 조건이 예순 개가 됐고 반년 뒤에는 320개가 됐습니다.

그즈음부터 같은 문의가 하루 마흔 건씩 들어왔습니다. "우리 팀 문서가 왜 잠겼나요" 였고, 열어 보면 새로 들어온 직원이 첫날에 회의록 템플릿을 서른 건 복사한 경우였습니다. 태오가 117번 조건의 숫자를 서른에서 쉰으로 올리자 그 문의는 사라졌지만, 다음 주에는 쉰 건씩 찍어 내는 광고 계정이 그대로 통과했습니다. 조건을 느슨하게 하면 스팸이 새고 조이면 멀쩡한 사용자가 걸리는 일이 번갈아 반복됐습니다.

문제는 태오의 실력이 아니라 방식에 있었습니다. 정상과 스팸을 가르는 경계는 링크 개수나 문서 개수 하나로 그어지지 않습니다. 스무 가지 신호가 함께 움직여서 만들어지고, 신호끼리 서로를 상쇄하기도 합니다. 사람이 그 조합을 전부 적어 내려가는 것은 불가능하고, 적어 둔 조건은 상대가 읽어 내고 피해 갑니다.

머신러닝은 이 순서를 뒤집습니다. 조건을 적는 대신 과거에 사람이 판정해 둔 결과를 모아서 넘깁니다. 잠갔던 계정 8,000개와 정상으로 확인된 계정 40,000개를 프로그램에 넣고, 그 안에서 둘을 가르는 경계를 스스로 찾게 합니다. 사람은 답을 모아 주고 규칙은 기계가 만듭니다. 규칙 320개를 손으로 관리하던 자리가, 매달 새 기록을 넣어 경계를 다시 그리는 자리로 바뀝니다.

같은 방식이 예측에도 쓰입니다. 지현이 "석 달 안에 해지할 팀을 미리 알고 싶다" 고 했을 때 이것을 조건으로 적을 방법은 없습니다. 어떤 팀은 접속이 줄다가 떠나고 어떤 팀은 마지막 주까지 멀쩡히 쓰다가 떠납니다. 하지만 지난 2년 동안 해지한 팀과 남은 팀의 기록은 이미 쌓여 있고, 그 기록에서 해지 직전 몇 달의 공통점을 뽑아내는 일은 기계가 할 수 있습니다.

그래서 이 갈래는 데이터·분석에서 가장 뒤에 붙습니다. 학습에 넣을 재료가 곧 앞 갈래에서 모으고 다듬어 둔 데이터라서, 남겨 두기로 한 기록이 빠져 있거나 값이 어긋난 상태로는 시작 자체가 되지 않습니다.

머신러닝 아래 묶인 용어들은 모델 하나를 만들어 굴리는 동안 부딪히는 순서대로 놓여 있습니다. 어떻게 배우게 하는가가 방식, 무엇을 맞히게 하는가가 과제, 무엇을 넣어 주는가가 입력, 무엇이 잘못되는가가 문제, 잘됐는지 어떻게 아는가가 평가, 그 뒤로 계속 돌리는 일이 운영입니다. 여섯 갈래입니다.

방식은 정답이 붙어 있느냐로 갈립니다. 둘뿐이고, 고르는 것이 아니라 가진 데이터가 정해 줍니다.

1. 지도 학습 — 정답이 붙은 데이터로 가르칩니다. 앞의 스팸 판정이 여기 속합니다. 계정 48,000개마다 스팸인지 아닌지가 이미 적혀 있으니 프로그램은 그 답을 맞히는 쪽으로 경계를 조금씩 옮깁니다. 결과가 정확한 대신 사람이 답을 붙여 두는 품이 먼저 듭니다.
2. 비지도 학습 — 정답 없이 구조만 찾게 합니다. 무엇을 찾아야 하는지조차 모를 때 씁니다. 페이지덱 계정 5만 개를 사용 패턴만 보고 몇 덩어리로 나눠 보면 회의록만 쓰는 팀과 제안서만 쓰는 팀이 갈려 나옵니다. 나온 덩어리에 이름을 붙이고 뜻을 읽는 것은 사람 몫입니다.

과제는 무엇을 맞히게 할지 가르는 갈래이고 셋이 자주 쓰입니다. 분류는 어느 범주에 속하는지 맞힙니다. 스팸이냐 아니냐, 들어온 문의가 환불 건이냐 버그 건이냐처럼 답이 미리 정해진 칸 중 하나입니다. 군집화는 칸을 정해 주지 않고 비슷한 것끼리 묶습니다. 앞에서 계정 5만 개를 나눈 일이 이것입니다. 추천은 사람마다 관심 가질 만한 항목을 골라 줍니다. 페이지덱이 처음 들어온 사용자에게 어떤 템플릿을 먼저 보여 줄지 정하는 자리가 여기입니다. 셋의 차이는 답의 모양에 있습니다. 분류는 정해진 칸 하나를, 군집화는 이름 없는 묶음을, 추천은 순서를 매긴 목록을 내놓습니다.

입력은 무엇을 넣어 주느냐를 다루는 갈래입니다. 학습 데이터는 가르치는 데 쓰는 기록 전체이고, 피처는 그 기록에서 뽑아낸 개별 입력 값입니다. 계정 하나를 넣는다고 할 때 기계가 실제로 보는 것은 계정 그 자체가 아니라 가입 후 경과일, 하루 평균 문서 수, 초대한 사람 수, 바깥 링크 비율 같은 숫자 묶음입니다. 이 숫자를 무엇으로 잡느냐가 결과를 크게 가릅니다. 하루 평균 문서 수 대신 누적 문서 수를 넣으면 2년째 쓰고 있는 멀쩡한 팀이 전부 스팸 쪽으로 밀려납니다. 모델을 바꾸는 것보다 피처를 하나 바꾸는 쪽이 점수를 더 올리는 경우가 흔합니다.

문제는 잘 안 되는 두 가지를 다룹니다. 과적합은 학습에 쓴 데이터에만 지나치게 맞춰진 상태입니다. 시험 범위를 이해하는 대신 기출문제의 답만 외운 것과 같아서, 봤던 문제는 전부 맞히고 새 문제는 틀립니다. 학습 데이터에서 98점이 나온 모델이 실제 계정에서 71점이 나오면 이쪽을 먼저 의심합니다. 모델 드리프트는 처음엔 잘 맞던 모델이 시간이 지나며 무뎌지는 현상입니다. 모델이 낡아서가 아니라 바깥이 바뀌기 때문입니다. 스팸 쪽이 수법을 바꾸거나 제품에 새 기능이 붙어 정상 사용 패턴 자체가 달라지면, 모델은 한 글자도 안 바뀌었는데 성능만 내려갑니다.

평가는 잘됐는지 판정하는 갈래입니다. 여기서 맞힌 비율 하나만 보면 안 되는 이유가 있습니다. 전체 계정의 98퍼센트가 정상이라면 무엇이 들어오든 정상이라고 답하는 모델도 98퍼센트를 받습니다. 아무 일도 하지 않는 모델이 높은 점수를 받는 것입니다. 정밀도와 재현율은 그 함정을 피하려고 숫자를 둘로 나눕니다. 스팸이라고 잡은 것 중 진짜 스팸이 몇 퍼센트인지가 하나, 실제 스팸 중 몇 퍼센트를 잡아냈는지가 다른 하나입니다. 둘은 서로 밀고 당깁니다. 기준을 조이면 잡은 것은 거의 다 진짜지만 놓치는 스팸이 늘고, 풀면 반대가 됩니다. 어느 쪽에 무게를 둘지는 기술이 아니라 제품이 정합니다. 잘못 잠근 계정이 해지로 이어지는 제품이라면 놓치는 쪽을 택합니다.

운영은 만든 모델을 계속 돌아가게 만드는 갈래입니다. MLOps는 학습과 배포와 감시를 사람 손 없이 굴러가게 묶어 둔 체계입니다. 노트북에서 한 번 학습시켜 좋은 점수를 받는 일과, 그 모델이 매일 수십만 건을 받아 내면서 성능이 떨어질 때 알림이 오게 만드는 일은 기술이 다릅니다. 앞의 다섯 갈래를 잘 다뤄도 이 갈래가 없으면 모델은 반년쯤 뒤에 조용히 무뎌진 채로 방치됩니다.

여섯 갈래는 한 줄로 끝나지 않고 되돌아옵니다. 성능이 떨어진 것이 감지되면 최근 기록으로 학습 데이터를 새로 모으고, 평가 점수를 보고 피처를 바꾸고, 다시 학습시킨 모델을 운영에 올립니다. 한 번 만들어 두면 끝나는 물건이 아니라 계속 손이 가는 설비에 가깝습니다.

"이건 규칙으로는 못 잡아요. 머신러닝으로 가려면 라벨 붙은 데이터가 얼마나 있는지부터 봐야 합니다."

과거에 사람이 판정해 둔 기록이 충분히 쌓여 있지 않으면 시작조차 못 한다는 뜻입니다.

"모델은 올렸는데 정밀도가 0.6이라 자동 차단은 못 합니다. 일단 검토 큐로만 보냅시다."

열 건 잡으면 그중 넷이 멀쩡한 계정이니 사람이 한 번 더 보게 두자는 제안입니다.

"지난달부터 성능이 떨어졌어요. 모델은 그대로인데 들어오는 문서가 달라졌습니다."

모델을 고칠 문제가 아니라 최근 데이터로 다시 학습시킬 때가 됐다는 말입니다.

페이지덱에서 스팸 판정 모델을 처음 올린 날, 태오가 회의에서 꺼낸 숫자는 맞힌 비율 94퍼센트였습니다. 지현이 되물은 것은 그 숫자가 아니라 "멀쩡한 계정을 잘못 잠그는 일이 하루 몇 건이냐" 였습니다. 세어 보니 열두 건이었고, 그중 절반은 돈을 내는 팀이었습니다. 그래서 첫 달은 자동으로 잠그지 않고 사람이 보는 목록에만 올리기로 했습니다.

석 달 뒤 회의에서는 다른 숫자가 올라왔습니다. 잘못 잠근 건수가 하루 두 건까지 내려왔고, 그 대신 태오가 규칙을 고치는 데 쓰던 시간이 주당 여섯 시간에서 한 시간으로 줄었습니다. 규원이 물은 것은 모델의 점수가 아니라 이 두 가지였습니다. 고객 문의가 줄었는지, 그리고 사람이 손으로 하던 일이 얼마나 없어졌는지입니다.

머신러닝이 규칙보다 언제나 낫다고 여기는 오해가 가장 흔합니다. 규칙으로 안 되던 문제를 풀어 주는 장면을 먼저 보게 되니 그렇게 읽힙니다. 하지만 이 방식은 과거 기록이 있을 때만 작동합니다. 판정해 둔 사례가 몇백 건뿐이거나, 아예 처음 만드는 기능이라 기록이 없으면 규칙 쪽이 낫습니다. 답을 설명해야 하는 자리에서도 그렇습니다. 왜 이 계정을 잠갔냐는 물음에 규칙은 "제목에 이 단어가 있어서" 라고 답할 수 있지만 모델은 대개 그러지 못합니다. 이 오해를 그대로 두면 팀은 규칙 열 줄이면 끝날 일에 두 달을 쓰고, 결과가 규칙보다 나쁘게 나와도 되돌리지 못합니다. 이미 그쪽으로 사람을 붙여 놨기 때문입니다.

데이터가 많기만 하면 알아서 된다고 보는 오해도 자주 나옵니다. 학습에 많은 데이터가 필요하다는 말을 자주 들으니 양이 전부인 것처럼 들립니다. 실제로 결과를 가르는 것은 양보다 답의 품질입니다. 페이지덱에서 잠근 계정 8,000개 중 1,500개가 실은 잘못 잠근 것이었다면, 모델은 그 잘못까지 함께 배웁니다. 사람이 하던 실수를 자동으로 반복하는 장치가 만들어지는 것입니다. 이 오해를 붙들고 있으면 팀은 점수가 안 오를 때마다 데이터를 더 모으는 쪽으로만 움직이고, 정작 답이 어긋나 있는 기록을 골라내는 일에는 손을 대지 않습니다. 그래서 학습을 시작하기 전에 답이 붙은 기록을 몇백 건 뽑아 사람이 다시 확인하는 절차를 둡니다.