알고리즘 쇼핑 중독이라는 병
'정형 데이터니까 XGBoost'라는 문장을 얼마나 자주 들으시나요? velog에 올라온 머신러닝 알고리즘 총정리 글은 선형 회귀부터 LightGBM까지 주요 알고리즘을 깔끔하게 정리하고, 마지막에 과제별 추천 알고리즘 표를 제시합니다. 교과서적으로 훌륭한 정리이지만, 데이터 분석가 관점에서 한 가지 빠진 것이 있습니다. 그 알고리즘을 돌리기 전에, 베이스라인은 세웠는지 묻는 대목입니다.
실무에서 가장 흔한 실수는 '알고리즘 쇼핑'입니다. Random Forest 돌려보고, XGBoost 돌려보고, LightGBM까지 돌린 다음 F1-score가 0.02 높은 쪽을 '최종 모델'이라고 부르는 패턴이요. 근거는 있나요? 그 0.02 차이가 통계적으로 유의한가요? Cross-validation의 fold별 분산은 확인했나요? 샘플 사이즈가 충분한 상태에서 나온 결과인가요? 이런 질문 없이 알고리즘만 바꿔 끼우는 건, 엔진을 교체하면서 연료 품질은 확인하지 않는 것과 같습니다.
베이스라인이 없으면 '개선'도 없다
해당 글에서 제시한 알고리즘 선택 가이드는 실용적입니다. 이진 분류라면 로지스틱 회귀를 베이스라인으로 잡고 XGBoost/LightGBM으로 올라가라는 조언은 정확합니다. 하지만 실전에서 이 조언이 무시되는 이유는 간단합니다. 로지스틱 회귀의 accuracy가 0.91이 나왔을 때, 많은 사람이 '더 좋은 알고리즘이 있을 텐데'라고 생각하지, '이 0.91이 의미하는 바가 무엇인지'를 먼저 파고들지 않기 때문입니다. 클래스 불균형이 9:1인 데이터셋에서 accuracy 0.91은 majority class를 전부 찍어도 도달하는 수치입니다. Precision, Recall, ROC-AUC를 함께 보지 않으면, 로지스틱 회귀가 '충분히 좋은' 건지 '아무것도 학습하지 못한' 건지 구분할 수 없습니다.
하드웨어 벤치마크가 알려주는 교훈: '빠르다'의 함정
velog의 AutoMine++ 벤치마크 시리즈에서 저자는 SYCL 기반 iGPU 행렬 곱셈을 NumPy와 비교합니다. 결과는 '참패'였습니다. iGPU 구현이 NumPy에 완패한 거죠. 저자의 결론이 핵심입니다: "하드웨어 차이가 아무리 나 봤자, 그걸 제어하는 소프트웨어에 의해 극복될 수 있다." 이건 ML 모델 선택에도 그대로 적용됩니다. 더 복잡한 알고리즘(더 강력한 하드웨어)을 도입해도, 데이터 전처리와 피처 엔지니어링(소프트웨어 최적화)이 엉망이면 단순 모델에 진다는 뜻입니다.
이 벤치마크에서 또 하나 주목할 점은 warm-up 단계를 분리한 것입니다. JIT 컴파일 시간을 제외하기 위해 사전 실행을 둔 설계는, ML 실험에서도 그대로 적용되어야 합니다. 첫 번째 epoch의 학습 시간을 전체 평균에 포함시키면 latency 지표가 왜곡됩니다. 벤치마크의 신뢰도는 이런 디테일에서 결정됩니다.
데이터 수집 단계부터 편향은 시작된다
dev.to의 웹 스크래핑 가이드는 BeautifulSoup으로 이커머스 사이트에서 상품명과 가격을 수집하는 파이프라인을 소개합니다. 기술적으로는 깔끔하지만, 이 데이터로 ML 모델을 학습시키겠다면 즉시 던져야 할 질문이 있습니다. 이 데이터에는 어떤 편향이 있을까요?
웹 스크래핑 데이터의 전형적인 함정을 나열하면 이렇습니다: - 선택 편향(Selection Bias): 특정 카테고리 페이지만 크롤링하면 전체 상품 분포를 대표하지 못합니다 - 생존자 편향(Survivorship Bias): 현재 판매 중인 상품만 수집되고, 단종·품절 상품은 누락됩니다 - 시간 편향(Temporal Bias): 크롤링 시점의 가격은 세일 기간인지, 평상시인지에 따라 완전히 달라집니다 - 라벨 품질: 상품 카테고리 태그가 판매자마다 일관적이지 않으면 분류 모델의 라벨 자체가 노이즈입니다
df.to_csv("product_data.csv")를 실행하기 전에, df.describe()와 df.isnull().sum()부터 찍어보는 습관이 알고리즘 선택보다 먼저입니다.
실전 체크리스트: 알고리즘 선택 '전에' 확인할 5가지
- 베이스라인 모델을 세웠는가? — 회귀라면 평균값 예측, 분류라면 majority class 예측 또는 로지스틱 회귀. 이것보다 나아야 '학습이 일어난 것'입니다.
- 평가 지표가 비즈니스 목표와 일치하는가? — 스팸 필터에서 Recall이 중요한지 Precision이 중요한지는 알고리즘이 아니라 비즈니스가 결정합니다.
- 데이터 분포를 확인했는가? — 클래스 불균형, 이상치, 결측치 비율.
pd.DataFrame.describe()가 XGBoost보다 먼저입니다. - 데이터 수집 과정의 편향을 인지하고 있는가? — 웹 스크래핑이든 로그 데이터든, 수집 방법 자체가 분포를 왜곡합니다.
- 실험 결과의 재현 가능성을 확보했는가? —
random_state=42를 넣는 것만으로는 부족합니다. train/test split 전략, cross-validation fold 수, 하이퍼파라미터 탐색 범위까지 기록해야 합니다.
전망: 복잡한 모델이 아니라 견고한 파이프라인이 이긴다
AutoMine++ 벤치마크에서 NumPy가 iGPU를 이긴 것처럼, 실제 운영 환경에서는 정교하게 튜닝된 로지스틱 회귀가 대충 돌린 딥러닝 모델을 이기는 경우가 비일비재합니다. 알고리즘 총정리 글이 제시한 선택 가이드는 유용하지만, 그 가이드를 따르기 전에 데이터 품질 검증과 베이스라인 수립이 선행되어야 합니다. 이건 correlation이지 causation이 아닙니다—복잡한 모델을 썼더니 성능이 올랐다는 건, 복잡한 모델 '덕분에' 올랐다는 뜻이 아닐 수 있습니다. 피처 하나를 제대로 만드는 것이 알고리즘 세 개를 바꿔 끼우는 것보다 RMSE를 더 많이 줄이는 세계에서, 우리가 먼저 의심해야 할 것은 알고리즘이 아니라 데이터 그 자체입니다.