AI가 만든 예측모델, 무엇을 넣을지는 여전히 사람이 정한다

불량을 미리 판별하는 모델을 만들어달라고 하면, 이제 그 자리에서 결과가 나옵니다. 데이터를 넘기고 무엇을 맞히고 싶은지 말하면 AI가 학습을 돌리고 성능 수치까지 붙여서 돌려줍니다. 예전에는 분석 전담 인력을 붙이거나 외부에 맡겨야 했던 일이 대화 몇 번으로 끝납니다.

그런데 완성된 모델을 앞에 두면 물어볼 것이 마땅치 않습니다. 화면에 성능 수치가 떠 있고, 숫자가 높으면 잘 만들어진 것처럼 보입니다. 이 모델이 무엇을 근거로 불량을 맞히고 있는지, 그 근거가 현장에서 말이 되는 이야기인지, 애초에 이 정도 수치를 현업에 붙여도 되는 수준인지는 화면 어디에도 적혀 있지 않습니다. 물음이 떠오르지 않으니 검토는 수치를 확인하는 선에서 끝나고, 모델은 그대로 현장으로 넘어갑니다.

지난 편에서는 두 조의 불량률 차이가 우연인지 확인하는 데까지 갔습니다. 차이가 진짜라고 확인되어도 왜 그런 차이가 생겼는지는 남아 있었고, AI가 수십 개 변수의 상관계수를 순위까지 매겨 뽑아주더라도 그중 무엇이 원인인지는 계산에서 나오지 않는다는 이야기로 마무리했습니다. 이번 편은 그 지점에서 이어집니다. 국내 대기업 제조 현장에서 진행한 AI Engineering 심화과정의 예측모델 파트를 따라가며, 모델을 만드는 일이 쉬워진 자리에 사람이 무엇을 붙들고 있어야 하는지 확인합니다.

예측모델 네 가지, 무엇을 쓸지는 데이터가 이미 정해놓았다

예측모델을 만들자는 이야기가 나오면 대개 어떤 모델을 쓸지부터 논의가 시작됩니다. 그런데 이 질문은 생각보다 선택의 폭이 좁습니다. 가진 데이터가 어떤 모양이고 무엇을 알고 싶은지가 정해지면 쓸 모델은 거의 자동으로 좁혀지기 때문입니다.

갈림길은 두 개뿐입니다. 먼저 알고 싶은 결과가 있는지를 봅니다. 불량인지 아닌지, 내일 생산량이 몇 개인지처럼 맞히고 싶은 값이 분명하다면 결과가 있는 쪽입니다. 다음으로 그 결과가 숫자인지 이름표인지를 봅니다. 여기서 네 가지가 갈립니다. 결과가 이름표라면 분류입니다. 이 제품이 불량인지 아닌지, 불량이라면 어떤 유형인지를 맞히는 일이 여기 들어갑니다. 결과가 숫자라면 예측입니다. 내일 생산량이 몇 개일지, 다음 달 수요가 얼마일지를 추정하는 경우입니다. 맞히고 싶은 결과가 애초에 없다면 군집입니다. 정답을 정해두지 않고 비슷한 것끼리 묶어 몇 개의 유형이 있는지 살펴보는 방식입니다. 마지막은 이상탐지로, 정상 범위에서 벗어나는 것이 있는지를 알고 싶을 때 씁니다.

네 가지를 외우는 것보다 중요한 것은 이 구분이 무엇에서 나왔는지입니다. 모델의 성능이나 최신 여부가 아니라 데이터의 생김새와 질문의 형태에서 나왔습니다. 그래서 모델을 고르는 일은 실무에서 생각만큼 큰 고민거리가 아닙니다.

일이 막히는 지점은 그 앞입니다. AI로 무엇을 해볼지부터 논의를 시작한 회의는 대체로 길어지는데 결론이 나지 않습니다. 불량을 줄이자거나 생산성을 높이자는 말은 나오지만, 무엇을 맞히고 싶은지가 한 문장으로 정해지지 않습니다. 그 상태에서는 어떤 모델을 골라야 할지 판단할 근거가 없고, 논의는 다른 회사가 무엇을 도입했는지를 참고하는 방향으로 흘러갑니다. 순서를 뒤집어 우리가 가진 데이터에 무엇이 담겨 있고 그 데이터로 무엇을 알고 싶은지부터 적어보면, 쓸 모델은 그 문장 안에 이미 들어 있습니다.

모델을 학습시키고 성능을 재는 일은 AI가 합니다. 무엇을 맞히고 싶은지 한 문장으로 정하는 일이 사람에게 남습니다.

예측 정확도, 100퍼센트는 없다는 전제에서 시작한다

기계학습으로 만든 예측모델에 100퍼센트는 없습니다. 과거에 쌓인 데이터에서 패턴을 찾아 아직 오지 않은 값을 추정하는 방식이라, 패턴을 벗어나는 경우가 반드시 남습니다. 성능 수치가 85퍼센트로 나왔다면 100건 중 15건은 틀린다는 뜻이고, 그 15건이 어느 건일지는 미리 알 수 없습니다. 모델을 더 손보면 이 숫자를 올릴 수는 있지만 어느 지점부터는 올라가지 않습니다.

이 전제를 받아들이고 나면 물어야 할 것이 세 가지로 갈라집니다. 무엇을 예측할 것인가, 어느 정도 정확도가 나와야 현업에서 쓸 수 있는가, 지금 이 수치를 받아들이고 넘어가도 되는가입니다. 세 질문 모두 모델이 답해주지 않습니다.

첫 번째 질문은 애초에 이 업무에 예측모델을 붙여도 되는지를 묻는 것입니다. 틀리면 안 되는 일에는 붙이기 어렵습니다. 한 건의 오판이 곧바로 사고나 책임 문제로 이어지는 영역이 그렇습니다. 반대로 사람이 전수로 확인하던 것을 우선순위 정렬로 바꾸는 정도라면, 틀리는 경우가 섞여 있어도 전체 작업량이 줄어드는 쪽이 남는 장사입니다. 같은 성능의 모델이라도 어디에 붙이느냐에 따라 쓸 만한 도구가 되기도 하고 쓰면 안 되는 도구가 되기도 합니다.

두 번째와 세 번째는 붙어 있는 질문입니다. 몇 퍼센트부터 합격인지에 대한 일반 기준은 없습니다. 여기서 성능을 읽는 방식을 하나 알아둘 필요가 있습니다. 불량이라고 판정한 것 중 실제로 불량이었던 비율과, 실제 불량 가운데 놓치지 않고 잡아낸 비율은 서로 다른 숫자입니다. 그리고 이 둘은 함께 올라가지 않습니다. 의심스러운 것을 폭넓게 불량으로 걸러내면 놓치는 건수는 줄지만 멀쩡한 제품까지 걸려 나오고, 확실한 것만 골라내면 오판은 줄지만 놓치는 불량이 늘어납니다. 한쪽을 높이면 다른 쪽이 내려가는 구조입니다.

이 구조를 모르고 요구사항을 적으면 이렇게 됩니다. 놓치는 것도 없고 잘못 걸러내지도 않는 모델을 만들어달라는 주문이 나갑니다. 성립하지 않는 조건이라 결국 양쪽 모두 어중간한 모델이 나오고, 현장에서는 검사 인원을 줄이지도 못하고 재검사만 늘어난 채로 슬그머니 쓰이지 않게 됩니다. 놓치면 고객까지 흘러가 큰일이 나는 불량인지, 잘못 걸러내면 정상 제품이 폐기되고 라인이 멈추는 상황인지에 따라 어느 쪽을 우선할지가 갈립니다. 그 선택을 내릴 수 있는 사람은 두 실수의 대가가 각각 얼마인지 아는 사람뿐입니다.

성능 수치를 계산하는 일은 AI가 합니다. 이 수치를 받아들일지, 어느 쪽 실수를 감수할지 정하는 일이 사람에게 남습니다.

모델 고도화, 성능을 가르는 지점은 그곳이 아니다

성능이 기대에 못 미치면 대개 모델을 바꿔보자는 이야기가 먼저 나옵니다. 더 최근에 나온 알고리즘, 더 무거운 모델, 유료 도구를 검토합니다. 그런데 모델을 바꿔서 얻는 개선폭보다 데이터를 손봐서 얻는 개선폭이 훨씬 큽니다. 같은 데이터를 놓고 모델만 바꾸면 소수점 아래에서 왔다 갔다 하는 정도인데, 데이터 자체가 정리되면 결과가 눈에 띄게 달라집니다.

"Garbage In, Garbage Out", 들어간 것이 엉망이면 나오는 것도 엉망이라는 말은 데이터를 쓰는 모든 일에 해당합니다. 기계학습은 여기서 조금 더 나쁩니다. 잘못된 데이터가 잘못된 결과 하나로 끝나지 않고, 그 안에 섞인 잘못된 패턴까지 학습하기 때문입니다. 표기가 어긋나 절반만 연결된 데이터로 모델을 만들면 그 절반의 세계에서만 통하는 규칙을 배우고, 그 규칙을 앞으로 들어올 모든 데이터에 계속 적용합니다. 사람은 이상한 결과를 보면 어딘가 잘못됐다고 느끼지만, 모델은 배운 대로 일관되게 틀립니다. 그래서 오류가 눈에 띄지 않습니다.

지난 2편에서 다룬 작업이 왜 필요했는지에 대한 답이 이 자리에 있습니다. 빈 칸을 어떻게 처리할지 기준을 정하고, 시스템마다 다른 날짜와 단위 표기를 맞추고, 부품 코드의 접두어 차이를 맞춰 연결율을 확인하던 일입니다. 당시에는 분석을 시작하기 위한 준비 작업처럼 보였겠지만, 실제로는 모델 성능의 상한선을 거기서 정하고 있었던 셈입니다. 앞단에서 어긋난 데이터는 뒷단의 어떤 모델로도 되돌릴 수 없습니다.

한 번 만든 모델을 계속 쓰는 방식도 짚어둘 필요가 있습니다. 새 측정치가 들어오면 자동으로 쌓이고, 실행할 때마다 최신 데이터까지 반영해 스스로 갱신되도록 설계할 수 있습니다. 데이터가 쌓일수록 모델이 좋아지는 구조라 대체로 바람직한 방향입니다. 다만 조건이 하나 붙습니다. 쌓이는 데이터의 성격이 그대로여야 합니다.

설비를 교체하거나 측정 방식을 바꾸거나 원자재 공급처가 달라지면, 그 시점을 기준으로 데이터의 성격이 달라집니다. 숫자가 담긴 열의 이름은 그대로라 표에서는 아무 일도 없어 보이지만, 그 안의 값들은 다른 조건에서 나온 것입니다. 이 데이터를 이전 데이터와 함께 학습시키면 서로 다른 두 세계가 하나로 뭉개지면서 모델이 오히려 나빠집니다. 자동으로 갱신되도록 설계해둔 경우에는 이 일이 조용히 일어납니다. 어느 시점부터 이전 데이터를 끊어야 하는지는 그 변화가 있었다는 사실을 아는 사람만 알 수 있습니다.

데이터를 쌓고 모델을 다시 학습시키는 일은 자동으로 돌아갑니다. 언제 데이터를 끊을지 판단하는 일이 사람에게 남습니다.

원인 변수 선택, 현장은 이미 답의 절반을 알고 있다

지난 편 마지막에 남겨둔 질문으로 돌아갑니다. 불량률에 차이가 있다는 것까지는 확인했는데, 무엇 때문에 그 차이가 생겼는지는 아직 답이 없는 상태였습니다.

원인을 찾으려면 어떤 조건이 불량과 함께 움직이는지 보게 됩니다. AI에게 맡기면 수십 개 변수의 상관계수를 뽑아 순위까지 정렬해줍니다. 목록 맨 위에 올라온 변수를 원인으로 지목하고 싶어지는데, 함께 움직인다는 사실과 원인이라는 사실은 다른 이야기입니다. 두 값이 나란히 오르내리는 이유는 한쪽이 다른 쪽을 일으켜서일 수도 있고, 둘 다 제3의 조건에 끌려다니고 있어서일 수도 있고, 그냥 우연일 수도 있습니다. 상관계수는 이 셋을 구분하지 못합니다.

구분하지 않고 넘어가면 이런 일이 생깁니다. 상관 상위에 오른 변수를 그대로 원인 변수로 넣어 모델을 만듭니다. 성능은 잘 나옵니다. 함께 움직이는 값이니 맞히는 데는 실제로 도움이 됩니다. 그 결과를 근거로 해당 조건을 관리 항목에 올리고 관리 범위를 좁힙니다. 그런데 불량률은 움직이지 않습니다. 그 변수가 원인이 아니라, 원인과 나란히 나타나던 또 다른 결과였기 때문입니다. 모델은 계속 잘 맞히고 개선 활동은 계속 성과가 없는 상태가 이어집니다.

그래서 무엇을 원인 변수로 넣을지 고르는 일이 남습니다. 여기서 자주 놓치는 것이 있습니다. 어떤 조건이 결과에 크게 작용하는지는 현장에서 오래 일한 사람이 이미 알고 있다는 점입니다. 어느 설비가 유독 말썽인지, 어떤 조건이 흔들리면 며칠 뒤에 불량이 따라 오르는지는 데이터를 돌려보기 전부터 몸에 쌓여 있는 지식입니다. 다만 숫자로 확인된 적이 없어 회의에서 추측으로 취급될 뿐입니다.

변수 선택을 통째로 AI에게 넘기면 이 지식이 모델에 들어가지 않습니다. AI는 주어진 표 안에서 통계적으로 관계가 있어 보이는 것을 골라낼 뿐이라, 애초에 데이터로 수집되지 않은 조건은 후보에 오르지도 못하고 수집은 되었지만 이름만 봐서는 의미를 알 수 없는 열은 그냥 하나의 숫자 열로 취급됩니다. 현장을 아는 사람이 후보 인자를 먼저 추려주고 그 안에서 AI가 기여도를 따지는 순서로 가면, 모델은 더 적은 변수로 더 설명 가능한 결과를 냅니다. 감으로 알고 있던 것을 데이터로 확인하는 절차이기도 해서, 결과가 어긋나면 그것대로 얻는 것이 있습니다.

교육에서 다룬 실습이 정확히 이 순서였습니다. 상황은 이랬습니다. 라인 불량률이 오르고 있는데 어떤 배합과 공정 조건일 때 불량이 많이 나오는지를 그동안 감으로만 추정해왔습니다. 데이터는 쌓여 있었지만 그 감을 확인해본 적은 없는 상태였습니다.

참여자들은 먼저 사람이 변수를 골랐습니다. 그 변수들로 불량 여부와 불량 유형을 맞히는 분류 모델을 만들고 성능을 측정했습니다. 여기서 멈추지 않고, 새로 측정한 값을 넣으면 불량 여부와 유형과 확률을 화면에 보여주는 도구까지 완성했습니다. 분석 결과가 보고서 한 장으로 끝나지 않고 현장에서 계속 쓰이는 형태로 남은 것입니다.

변수를 고른 것은 사람이고, 모델 학습과 성능 측정과 도구 구현은 AI가 했습니다.

마치며

모델을 만드는 일과 그 모델을 판단하는 일이 갈라졌습니다. 만드는 쪽은 짧아졌습니다. 데이터를 넘기고 무엇을 맞히고 싶은지 말하면 학습부터 성능 측정까지, 필요하면 현장에서 쓸 도구 형태까지 나옵니다. 판단하는 쪽은 그대로 남았습니다. 어떤 데이터를 넣을지 설계하는 일, 나온 결과를 해석하는 일, 그리고 그 예측값을 근거로 무엇을 할지 결정하는 일입니다.

세 가지 모두 계산에서 나오지 않습니다. 무엇을 원인으로 볼지는 공정을 아는 사람에게서 나오고, 이 정확도를 받아들일지는 두 종류의 실수가 각각 얼마짜리인지 아는 사람에게서 나오며, 데이터를 언제 끊을지는 현장에서 무엇이 바뀌었는지 아는 사람에게서 나옵니다.

HRD 관점에서 짚어볼 지점이 여기입니다. 데이터 분석 교육을 운영하고 있다면, 그 과정이 모델을 만들어보는 실습에 얼마나 배정되어 있고 이 모델을 믿어도 되는지 따지는 훈련에 얼마나 배정되어 있는지 확인해볼 필요가 있습니다. 만드는 일은 도구가 빠르게 대신하고 있는 영역입니다. 반면 무엇을 넣고 무엇을 믿고 무엇을 할지 정하는 판단은 대신할 주체가 없고, 그 판단을 할 수 있는 사람은 조직 안에 이미 있습니다. 현장을 오래 겪은 사람들입니다. 이들이 갖고 있는 감각을 데이터로 옮길 수 있게 만드는 것이 교육이 맡을 몫입니다.

지금까지 네 편에 걸쳐 표에 담긴 숫자를 다뤘습니다. 다음 편에서는 이미지를 다룹니다. 사람 눈으로 하던 외관 검사를 코드로 옮길 때, 어떤 방법을 쓸지가 기술의 우열이 아니라 지금 가지고 있는 이미지의 양과 형태로 결정된다는 이야기입니다.

우리 조직의 데이터 교육이 도구를 다루는 데 머물러 있는지, 나온 결과를 앞에 두고 판단하는 훈련까지 담고 있는지 점검해보고 싶으시다면, 포텐스닷이 함께 확인해드릴 수 있습니다.