핵심 이슈: '400건 분석'이라는 숫자, 그 자체를 먼저 의심해야 합니다
근거는 있나요? ML 프로젝트의 모든 단계에서 가장 먼저 던져야 할 질문입니다. 최근 dev.to에 게시된 두 가지 프로젝트—Hacker News "Who is Hiring" 스레드에서 400건 이상의 채용 공고를 추출·분석한 파이프라인과, GPT-4o Vision으로 식사 사진에서 칼로리를 추정하는 시스템—는 ML 파이프라인의 데이터 수집, 전처리, 모델 추론, 결과 해석이라는 전 단계를 관통하는 훌륭한 '반면교사' 사례입니다. 둘 다 기술적으로 깔끔하게 구성되어 있지만, 데이터 분석가의 관점에서 보면 각 단계마다 통계적 지뢰가 숨어 있습니다.
1단계: 데이터 수집—샘플 사이즈와 선택 편향
HN 채용 분석 프로젝트는 Hacker News의 월간 "Who is Hiring" 스레드 단일 월(2026년 2월) 데이터에서 400여 건의 공고를 추출했습니다. 여기서 첫 번째 질문: 샘플 사이즈가 충분한가요? 400건은 숫자만 보면 적지 않지만, 이 데이터는 'HN에 공고를 올리는 기업'이라는 극히 특정한 모집단에서 나온 것입니다. HN에 채용 공고를 올리는 회사는 대체로 테크 스타트업이며, 대기업이나 비테크 산업은 거의 포함되지 않습니다. 이건 전형적인 선택 편향(selection bias)입니다. "Python 백엔드 역할이 Node.js 대비 15% 연봉 프리미엄을 보인다"는 결론은 이 편향된 샘플 안에서의 correlation이지, 시장 전체의 causation이 아닙니다.
더 문제적인 것은 연봉 데이터의 결측률입니다. 원문은 salary_min과 salary_max 필드에 null을 허용하는 스키마를 사용하고 있는데, HN 채용 공고에서 연봉을 명시하는 비율은 통상 30~40%에 불과합니다. 나머지 60% 이상이 결측인 상태에서 "15% 프리미엄"을 계산했다면, 실제 비교 가능한 샘플은 100건 미만일 가능성이 높습니다. Velog의 데이터 전처리 정리글이 강조하듯, 결측치 처리 전략—삭제, 평균 대체, KNNImputer—중 어떤 것을 선택했느냐에 따라 결과가 완전히 달라집니다. 결측 비율과 처리 방법이 보고되지 않은 통계는 의심해야 합니다.
2단계: 데이터 추출—LLM이 만든 구조화 데이터의 라벨링 품질
두 프로젝트 모두 LLM을 데이터 추출의 핵심 도구로 사용합니다. HN 분석은 Llama 3 등의 모델로 비정형 텍스트에서 JSON을 추출하고, 칼로리 트래커는 GPT-4o Vision으로 이미지에서 영양 정보를 추론합니다. 여기서 반드시 물어야 할 것: 이 LLM 추출의 Precision과 Recall은 얼마입니까? HN 파이프라인에서 "Global Remote"와 "US-Only Remote"를 분류했다고 하는데, 원문에 "Remote (US/Canada preferred)"라고 적힌 공고는 어느 카테고리에 들어갔을까요? LLM의 분류 일관성(inter-rater reliability)에 대한 검증 없이 37% vs 22%라는 비율을 확정적으로 제시하는 것은 위험합니다.
GPT-4o Vision 칼로리 추적은 더 심각한 문제를 안고 있습니다. 원문은 "High-Precision"이라는 제목을 달고 있지만, 정작 정확도 지표가 단 하나도 제시되지 않습니다. Confidence score를 0~1로 반환하도록 프롬프트에 지시했지만, 이 confidence가 실제 칼로리 오차와 어떤 상관관계를 보이는지에 대한 검증이 없습니다. 베이스라인 대비 얼마나 개선되었는지도 알 수 없습니다. 파스타 위의 파마산이 20g인지 50g인지를 사람도 맞추지 못하는데, 모델의 MAE(Mean Absolute Error)나 RMSE가 보고되지 않은 시스템을 "High-Precision"이라고 부를 근거는 어디에 있을까요?
3단계: 결과 해석—Correlation ≠ Causation의 원칙
HN 분석이 도출한 "비자 스폰서십의 80%가 AI 인프라와 핀테크에 집중"이라는 인사이트를 생각해 봅시다. 이건 해당 섹터가 비자 스폰서십에 '우호적'이라는 의미일까요, 아니면 단순히 HN에 공고를 올리는 AI/핀테크 회사의 비율이 높기 때문일까요? 숨은 교란 변수(confounding variable)를 통제하지 않은 상태에서 섹터와 비자 스폰서십의 관계를 단정 짓는 것은 전형적인 correlation-causation 혼동입니다. 이걸 판단하려면 최소한 섹터별 공고 수 대비 비자 스폰서십 비율의 정규화가 필요합니다.
시사점: 프로덕션 환경에서 이 숫자들이 살아남을 수 있는가
실제 운영 환경에서도 이 성능이 나올까요? GPT-4o Vision 칼로리 트래커를 매일 세 끼 사용한다고 가정하면, 매번 API 호출 비용이 발생하고, 조명·각도·그릇 크기라는 통제 불가능한 변수가 추론 정확도를 흔듭니다. 원문도 "production-grade에는 캐싱과 에러 핸들링이 필요하다"고 인정하지만, 근본적인 문제는 인프라가 아니라 모델 출력의 신뢰도 측정 자체가 설계에 빠져 있다는 점입니다. Ablation study 없이 Chain-of-Thought 프롬프팅이 얼마나 기여하는지도 알 수 없습니다.
HN 채용 분석 역시 마찬가지입니다. 단일 월 데이터로 "시장이 Python/Go/Rust로 회전하고 있다"고 결론 내리려면, 최소 6~12개월 추세 데이터와 통계적 유의성 검정(예: 월별 비율 차이에 대한 chi-square test)이 필요합니다. N=1 시점의 스냅샷으로 추세를 논하는 것은 df.head()만 보고 전체 분포를 판단하는 것과 같습니다.
전망: 파이프라인은 쉬워지고, 의심은 더 어려워진다
LLM 기반 데이터 추출 파이프라인의 구축 난이도는 계속 낮아지고 있습니다. BeautifulSoup으로 파싱하고 LLM으로 JSON을 뽑는 파이프라인은 이제 주니어 엔지니어도 하루 만에 만들 수 있습니다. 하지만 그 파이프라인이 뱉어낸 숫자의 통계적 유효성을 검증하는 능력은 오히려 더 희소해지고 있습니다. 결측률은 몇 퍼센트인지, 선택 편향은 어떤 방향으로 작용하는지, 베이스라인 대비 개선은 얼마인지, 이 결과가 일반화 가능한지—이 질문들을 던지지 않는 ML 파이프라인은 아무리 코드가 깔끔해도 프로덕션에서 사고를 냅니다. 숫자를 만드는 것보다 숫자를 의심하는 것이 더 비싼 기술이 되는 시대입니다.