근거는 있나요? — 모델을 열기 전에 쿼리부터 열어야 하는 이유
모델 성능이 떨어지면 우리는 본능적으로 하이퍼파라미터 그리드를 다시 짜거나, 아키텍처를 바꾸거나, feature importance plot을 들여다봅니다. 그런데 실제로 프로덕션 ML 시스템의 장애 포스트모템을 뜯어보면, 근본 원인이 모델 바깥에 있는 경우가 놀라울 만큼 많습니다. 최근 dev.to에 공유된 한 SQL-to-ML 파이프라인 실수 분석 사례는 이 문제를 아주 선명하게 보여줍니다. Churn 모델의 성능이 갑자기 떨어졌는데, 아키텍처도, 학습 파이프라인도, 평가 프레임워크도 바뀐 게 없었다는 겁니다. 범인은 SELECT * FROM customers c JOIN orders o ON c.customer_id = o.customer_id—이 한 줄이었습니다.
문제를 정리하면 이렇습니다. 이 쿼리는 고객당 주문 건수만큼 행을 복제합니다. 주문 10건인 고객은 훈련 데이터에서 10배 과대 표현됩니다. 모델 입장에서는 고빈도 주문 고객의 패턴에 과적합할 수밖에 없고, 그 결과 Precision은 겉보기엔 괜찮아 보여도 Recall과 F1-score가 특정 세그먼트에서 처참하게 무너집니다. 이건 data leakage도 아니고, label noise도 아닙니다. 단순히 granularity mismatch—학습 단위(unit of analysis)의 정의 실패입니다. GROUP BY customer_id로 집계한 뒤 피처를 구성했다면 일어나지 않을 일이었습니다.
여기서 멈추지 말고 질문을 확장해 봅시다. NULL 처리는요? COALESCE(income, 0)이 '소득이 0원인 고객'과 '소득 정보가 없는 고객'을 동일하게 만든다면, 모델은 이 두 집단을 구분할 수 없습니다. AVG(transaction_amount) 같은 글로벌 집계는요? 고객별 맥락 없이 전체 평균으로 피처를 만들면, 모델이 학습할 수 있는 entity-level variance가 소멸합니다. 결국 SQL 쿼리 하나하나가 사실상 feature engineering의 결정이고, 그 결정이 모델의 학습 경계(decision boundary)를 직접 규정합니다. 파이프라인은 전처리가 아니라 모델 아키텍처의 일부입니다.
82% 정확도, 근데 샘플이 합성 데이터라면요?
파이프라인 품질 문제가 모델 '안'에서도 반복되는 사례가 있습니다. CI/CD 환경에서 flaky test—코드 변경 없이 간헐적으로 실패하는 테스트—를 ML로 예측하려는 연구 프로젝트가 그렇습니다. 실행 시간 분산, 실패 빈도, 커밋 상관 패턴 등을 피처로 추출해 Logistic Regression, Random Forest, Gradient Boosting을 돌렸고, 초기 실험에서 Accuracy ~82%, Recall은 '강함(strong)'이라고 보고합니다.
여기서 데이터 분석가로서 던져야 할 질문이 몇 가지 있습니다. 첫째, 샘플 사이즈가 충분한가요? 이 실험은 Playwright 기반 합성 데이터(synthetic execution logs)에서 수행되었습니다. 인위적으로 주입된 불안정 패턴이 실제 CI 환경의 flaky test 분포와 얼마나 일치하는지에 대한 검증이 없습니다. 둘째, Precision이 'moderate'라고만 표현되어 있는데, flaky test 탐지에서 false positive의 비용을 생각하면 이건 치명적입니다. 안정적인 테스트를 flaky로 분류하면 엔지니어가 정상적인 실패 신호를 무시하게 되고, 이는 오히려 CI 신뢰도를 더 떨어뜨립니다. 셋째, 82% accuracy는 베이스라인 대비 얼마나 개선된 것인가요? 만약 전체 테스트의 80%가 stable이라면, '전부 stable로 찍는' majority classifier도 80% accuracy를 달성합니다. class imbalance 하에서 accuracy는 거의 무의미한 지표입니다. ROC-AUC나 Precision-Recall AUC를 봐야 합니다.
연구팀도 이를 인식하고 있어서 '실제 오픈소스 CI 데이터셋 수집'을 다음 단계로 제시하고 있는데, 솔직히 말하면 이건 다음 단계가 아니라 첫 번째 단계여야 했습니다. 합성 데이터에서의 82%는 proof-of-concept으로서의 가치는 있지만, 프로덕션 의사결정의 근거로는 부족합니다. 이 역시 결국 데이터 품질과 실험 설계의 문제입니다.
백테스트 없는 AI 트레이딩: Correlation을 Causation으로 파는 법
데이터 파이프라인과 실험 설계의 함정이 가장 위험해지는 영역은 역시 금융입니다. 한 개발자가 yfinance 기반으로 4개 시장(미국·홍콩·싱가포르·중국 A주)의 매매 신호를 생성하는 AI 시스템을 공개했습니다. SMA 크로스오버, RSI, 모멘텀 스코어를 결합해 -5~+5 점수를 매기고 BUY/SELL/HOLD 신호를 내보내는 구조입니다.
기술적으로 깔끔한 Python 코드이고 리스크 관리 레이어(2% 룰, 25% 캡, 손절 로직)도 있습니다. 그런데 결정적으로 빠져 있는 것이 백테스트(backtest) 결과입니다. Sharpe ratio, maximum drawdown, win rate, profit factor—이 중 어느 하나도 제시되지 않았습니다. '2026년 2월 22일 오늘의 신호'를 보여주는 것은 단일 시점 스냅샷이지 전략 검증이 아닙니다. 더구나 yfinance 데이터에는 survivorship bias(상장 폐지 종목 미포함), look-ahead bias(과거 데이터의 사후 수정) 문제가 내재되어 있습니다. 저자 본인도 "Yahoo Finance is free but has occasional gaps"라고 인정하고 있는데, 이 'occasional gaps'가 트레이딩 전략의 성과를 얼마나 왜곡할 수 있는지에 대한 정량적 분석은 없습니다.
"Simple beats complex"라는 결론도 근거 없이는 위험한 주장입니다. SMA 크로스오버 전략이 대다수 리테일 트레이더보다 낫다는 건 무엇과 비교한 것인가요? 베이스라인이 '감(gut feeling)'이라면, 그건 베이스라인 자체가 설정되지 않은 겁니다. Buy-and-hold SPY 대비 초과 수익(alpha)이 통계적으로 유의미한지가 핵심 질문인데, 이 질문은 한 번도 등장하지 않습니다.
시사점: 모델 아키텍처보다 데이터 계약(Data Contract)이 먼저입니다
세 가지 사례의 공통 패턴은 명확합니다. SQL granularity 오류는 학습 단위 정의 실패, 합성 데이터 실험은 검증 데이터의 대표성 실패, 백테스트 부재는 평가 설계 실패입니다. 세 가지 모두 모델 '바깥'에 있는 문제이고, 모델을 아무리 튜닝해도 해결되지 않습니다.
실무에서 제가 권장하는 체크리스트는 이렇습니다:
- JOIN 후 행 수를 반드시 검증하세요.
SELECT COUNT(DISTINCT customer_id)vsSELECT COUNT(*)— 이 두 숫자가 다르면 granularity가 깨진 겁니다. - 합성 데이터 실험 결과는 upper bound로만 취급하세요. 실제 데이터의 노이즈, 분포 이동, 라벨 오류를 반영하면 성능은 반드시 하락합니다.
- 금융 모델은 out-of-sample 백테스트 없이 '작동한다'고 말하지 마세요. Walk-forward validation, 거래 비용 포함, 슬리피지 반영은 최소 요건입니다.
- 데이터 계약(Data Contract)을 코드로 관리하세요. 스키마 검증, NULL 비율 임계치, 행 수 범위 체크를 CI 파이프라인에 넣어야 합니다.
의료 사기 탐지 분야에서 한 자율 AI 에이전트가 흥미로운 접근을 보여줬습니다. 블랙박스 ML 대신 6가지 해석 가능한 신호(upcoding 빈도, 서비스 다양성, 청구 속도, 진단-치료 불일치, 지리적 밀도, 피어 벤치마크)를 조합한 composite score를 사용했는데, 초기 구현에서 전국 평균 기준으로 비교해 농촌 클리닉의 false positive가 급증하는 문제를 겪고, 이를 지리적 피어 그룹 기반으로 수정해 FPR을 낮췄습니다. 이것이야말로 데이터 맥락(context)을 이해하는 파이프라인 설계의 좋은 예시입니다.
전망: 파이프라인 테스트가 모델 테스트만큼 성숙해져야 합니다
ML 커뮤니티는 모델 평가에는 교차 검증, ablation study, statistical significance test를 당연하게 적용하면서, 데이터 파이프라인에는 df.head() 한번 찍어보는 수준에 머무는 경우가 많습니다. Great Expectations, dbt tests, Pandera 같은 데이터 검증 도구가 존재하지만, 아직 ML 프로젝트의 표준 관행으로 자리 잡지 못했습니다. 모델 정확도 0.01을 올리기 위해 GPU 수백 시간을 쓰기 전에, 업스트림 쿼리 한 줄이 학습 데이터의 분포를 얼마나 왜곡하고 있는지부터 확인하세요. 가장 큰 ML 개선이 새로운 모델이 아니라 더 나은 쿼리에서 온다는 것—이건 correlation이 아니라, 충분한 근거가 있는 causation입니다.