예측과 설명과 결정은 서로 다른 일이야
누군가 모델을 만들어 달라고 할 때 실제로 원하는 것은 셋 중 하나인 경우가 많아. 앞으로 일어날 일을 숫자나 범주로 예측하고 싶은 걸 수도 있어. 왜 그런 결과가 나왔는지 설명이 필요할 수도 있고, 지금 무엇을 해야 하는지 결정을 내려달라는 뜻일 수도 있지. 셋은 이어져 있지만 같은 산출물이 아니야. 무엇을 주된 결과로 삼느냐에 따라 평가 지표와 배포 방식, 책임 범위가 달라져.
정확한 예측이 좋은 결정까지 보장하지 않아
해지 확률을 꽤 정확히 맞혀도 연락 기준이 너무 낮으면 상담팀이 감당할 수 없는 고객 목록이 쏟아져. 기준이 너무 높으면 정말 떠날 고객을 놓치지. 잘못 연락했을 때의 비용과 놓쳤을 때의 비용이 다르기 때문에 확률을 행동으로 바꾸는 규칙은 모델 바깥에서 정해야 해. 예측기는 세상을 묘사하고, 결정 규칙은 그 묘사를 바탕으로 행동해. 둘을 한 덩어리로 부르면 어느 쪽이 틀렸는지 찾기 어려워져.
설명도 목적에 따라 모양이 달라져
개발자가 오류를 찾기 위한 설명과 고객에게 판단 근거를 알려주는 설명은 같지 않아. 특성 중요도는 모델이 어떤 정보에 기대는지 보여주지만, 그 정보를 바꾸면 결과가 좋아진다는 뜻은 아니야. 고객에게 행동을 권하려면 예측에 기여한 요인보다 실제로 바꿀 수 있는 요인이 무엇인지 따져야 하지. 설명이 멋져도 가능한 행동으로 이어지지 않으면 결정 도구로서는 부족해.
한 문장으로 시스템의 경계를 적어
어떤 정보가 주어지면 무엇을 예측하고, 어느 기준을 넘으면 어떤 행동을 한다. 이 문장을 팀이 끝까지 채울 수 있어야 해. 예측 대상, 기준값, 행동 주체가 빠지면 모델링보다 제품 설계를 먼저 해야 해. 기준값은 코드 속에 숨은 숫자가 아니라 비용과 처리 능력으로 설명되는 공개된 결정이어야 해.
결정을 나눠 기록하면 책임도 보이기 시작해
로그에는 모델의 확률, 적용한 기준값, 최종 행동, 모델 버전을 따로 남겨. 그래야 결과가 나빴을 때 모델의 순서화가 틀렸는지, 기준값이 현실 비용과 어긋났는지, 행동 자체가 잘못됐는지 분리할 수 있어. 객체를 나누듯 책임을 나누면 교체와 회고가 쉬워져. 모델이라는 한 상자 안에 모든 책임을 숨기지 마. 같은 예측을 써도 인력과 예산이 달라지면 최선의 행동은 달라질 수 있다는 점도 기록해 둬. 행동 규칙의 변경 이력과 승인자까지 남겨야 모델을 바꾸지 않은 정책 변화도 추적할 수 있어.