숫자에서 자유롭자

데이터 분석은 수놀음이다. 하지만 수만의 게임은 아니다.
여러 선택지 중에서 어떤 알고리즘 (모델)을 취할 것인가?라는 아주 흔한 상황을 생각해보자. 트레이닝 데이터로 모델들을 학습하고, 테스트 데이터로 각 모델의 정확도를 측정해서 가장 좋은 성능의 모델을 최종 선택할 거다. 원칙적으로 틀린 건 없지만 전적으로 옳은 것도 아니다. 숫자가 가장 객관적이지만 객관성만으로 모든 결정이 이뤄지는 건 아니다. A가 B보다 10% 낫다는 것이 과연 A가 답이다라는 걸 의미하는 걸까? 보통은 그렇다. 보통은…
숫자가 잘 작동할 때는 다른 여러 근거가 있는데 화룡점정으로 수치가 그 결정을 뒷받침해줄 때다. 아니면 어떤 수치를 얻었는데 그걸 제대로 해석하거나 다른 근거가 함께 동반될 때다. 게임이 복잡할수록 숫자 하나만으로 결정이 이뤄지지 않는다. 데이터를 다루는 사람은 숫자로 객관성을 담보해야 하지만 숫자가 잘못된 결론으로 이끌 수도 있음을 항시 조심해야 한다.
연구 논문을 작성할 때 늘 문제가 되는 건 데이터 가용성이다. 모델의 복잡도와 크기는 엄청 커진 딥러닝의 시대에도 여전히 수 십 년 전에 사용하던 데이터로 검증한다. 대학 다닐 때 IRIS 데이터를 처음 접했는데, 요즘 논문을 봐도 여전히 IRIS가 등장한다. 물론 이런 데이터는 수차례 다양한 연구자들을 통해서 검증이 끝났고 그래서 모델의 성능을 해석하는데 용이하다. 역으로 말하면, 우리가 실제 현장/필드에서 만나는 수많은 데이터들은 검증이 이뤄지지 않았고 그런 데이터에 따른 수치는 제대로 해석하기 어렵고 때론 신뢰하기 어렵다는 거다. 데이터가 깨끗하지도 않고 완전하지도 않다. 데이터는 수집하고 있는데 필요한 모든 데이터를 수집하고 있는 것인지도 모르겠고 제대로 쌓고 있는지도 모르는 경우가 다반사다. 실제 데이터가 많다는 곳에 가봐도 정작 필요한 데이터는 없는 경우를 종종 — 대부분 — 본다. 깨끗하지 않은, 즉 이해도가 낮은 데이터로 만든 수치에서 객관성을 찾기란 어렵다.
각고의 노력으로 데이터를 제대로 이해했고 잘 정제했다고 가정하자. 그런 데이터로 학습한 모델의 성능, 즉 수치는 과연 옳은가? 그래서 다양한 환경에서의 반복 실험, 즉 재현성이 필요하다. 다른 데이터에서도 잘 동작하는지도 확인하고, 설정을 조금 변경해도 잘 나오는지 등을 확인하는 거다. 특히 과거 데이터로 만든 오프라인 테스트의 결과는 실시간 데이터에서 반드시 검증돼야 한다. 이전 직장에서 모델의 성능을 비교할 때 RIG라는 걸 평가 지표로 사용했는데, 오프라인 테스트에선 분명 새로운 모델이 더 좋았는데 실제 시스템에 적용하면 별로 나아지지 않는 경우가 흔했다. 그나마 수 차례의 경험으로 오프라인 RIG가 5% 이상 높을 때 실제 서비스에서의 CTR이나 매출 등이 더 낫다는 암묵적 잠정 결론을 얻었다. 돌발 상황은 죽은 데이터에 기록되어있지 않다.
보통 모델을 평가할 때 주요 한 두 개의 지표만을 보는 것도 숫자의 신뢰도를 떨어뜨린다. 분류 모델을 평가한다면 정확도를 보통 가장 먼저 본다. 정확도가 가장 중요한 지표지만 정확도만으로 결정을 내리면 안 된다. 학습이나 추론 속도도 중요하고, 모델의 크기도 중요하다. 요즘은 GPT-3 등 대형 모델에 너무 익숙해져 있는데 그런 모델은 스마트 폰이나 웨어러블 디바이스 등의 온디바이스 리즈닝에는 부적합하다. 최근 많이 고민하고 있는데 모델의 interpretability도 중요하다. 노련한 데이터 과학자들만의 세상이라면 문제가 적을 수도 있지만, 새로운 모델을 만들면 경험 차이가 많은 팀원들을 먼저 이해시켜야 하고, 카운트파트 기획자도 이해시켜야 하고, 상사나 경영진도 이해시켜야 하고, 나중에는 (각종 CS 등) 일반 소비자도 이해시켜야 할 때도 있다. 딥러닝이 좋은 건 당연히 알지만 여전히 로지스틱 모델이 더 나은 선택일 때도 있다. 특히 서비스에선 모델의 정확도나 속도나 그런 건 모르겠고 일단 매출 (ROI)가 높아야 한다. 다른 건 다 떠나서, 그냥 정확도만 높이면 되는 상황이라고 하자. Accuracy metrics라고 구글링을 하면 수많은 지표들이 나열된다. 보통 대부분의 지표들이 서로 연결돼있어서 한 지표에서 성능이 좋으면 다른 지표도 성능이 좋다. 그런데 항상 그럴까? 정확도만 보더라도 수 (십) 가지의 다른 지표를 통해서 교차 검증해야 한다. AUC가 10% 포인트 높다고 해서 정확도가 진짜 좋아졌다고 말할 수 없다.
분산 분석 등을 통해서 귀무가설 (null hypothesis)를 거절 reject 하는 통계적 유의미성 statistical significance를 따지는 것이 정석이지만, 실제 현장에선 단순히 A/B 테스트를 통해서 조금이라도 평가 수치가 높은 모델을 선택한다. 그런데 연구 논문에서는 통계적 유의성이 중요하다. 보통 p-value를 많이 보이지만, 이것도 요즘은 해석의 문제 또는 오남용으로 조심스럽게 사용하는 추세다. 논문을 보면 자신의 아이디어를 거창하게 설명했지만 수치 해석 파트에 가면 개선의 효과가 별로 크지 않은 경우도 자주 본다. 작은 개선이 의미 없다는 의미가 아니다. 예를 들어, 0.1%라는 작은 개선들이 누적되면 언젠가는 5~10% 또는 그 이상의 퀀텀 점프를 이룬다고 믿는다. 말하고 싶은 것은 작은 숫자적 개선이 실제 효용으로 연결되지 않을 수도 있다는 점이다. 예를 들어, 정확도를 10% 개선했다고 해서 매출이 항상 5% 증가하는 것도 아니고, 알고 보니 그런 개선을 위해서 전력 사용량이 2배 증가해서 오히려 손해를 볼 수도 있다. 숫자는 중요하지만 집착은 금물이다.
그 외에도 다양한 측면에서 숫자만의 위험성을 설명할 수 있다. … 결국 하고 싶었던 말은 정량적으로 평가하는 것과 함께 — 아직은 — 정성적으로 평가하는 걸 병행해야 한다는 걸 강조하고 싶다. 숫자를 보더라도 결과 숫자만이 아니라 그래프를 그려서 좀 더 포괄적으로 보는 것이 필요하다. 모델을 평가할 때 항상 옳은 데이터를 얻을 수 있는 것이 아니기 때문에 — 얻더라도 완벽할 수 없기 때문에 — 숫자가 아닌 결과를 눈으로 훑어보는 것도 필요하다. 데모 시스템을 만들어서 눈으로 직접 확인하기 전까진 내가 만든 모델이 얼마나 엉망인지 숫자로는 알 수 없다. 때론 숫자에 속기도 한다. 모든 상황을 고려한 전체를 다 확인할 수는 없지만 샘플링을 통해서라도 실제 데이터가 어떻게 바뀌는지 확인해야 한다. 알만한 큰 기업들에 데이터를 검수하는 수많은 사람들이 고용되어있다는 걸 잊어선 안 된다. 물론 데모 결과를 보거나 운영자가 검수한다고 해서 가장 좋은 모델을 얻는 것은 아니다. 이해할 수 없어도 실 서비스에서 가장 좋은 성능을 보이는 쪽으로 선택하게 된다. 그럼에도 가능한 모든 측면에서 검증하는 걸 게을리하면 언젠가 탈 난다. 내가 직접 처리하지 않기만을 바라는 것이 아니라면…
나도 그냥 요약된 숫자만 보고 싶다. 하지만 그러다 언젠간 큰코다친다.