초보자 1번 실수는 가장 많이 거론되는 도구를 골라서 모든 문제를 거기 욱여넣는 거. 1번 프로 스킬은 앞에 있는 일의 모양에 맞는 도구를 고르는 거야. 작동하는 결정 프레임워크 여기 있어.
| 상황 | 골라 | 이유 |
|---|---|---|
탐색, <100M 행, 지저분한 mixed type | Pandas | 최대 ecosystem, 모든 분석 라이브러리가 받음, REPL 친화적. |
같은 모양인데 노트북에서 100M–10B 행 | Polars (lazy) | Streaming 엔진, query optimizer, 병렬 실행. Pandas 는 OOM. |
| Parquet/Arrow 위에서 익숙한 SQL 분석 | DuckDB | In-process, 서버 없음, 파일 직접 query, 비용 대비 환상적인 성능. |
| 이미 데이터가 Postgres/BigQuery/Snowflake 안에 | SQL (warehouse 안) | 꺼내고 다시 넣지 말고. 데이터 사는 곳에서 compute. 정리는 dbt 로. |
| Label 필요 없는 수치 무거운 작업 | NumPy | Pandas 보다 overhead 적음, vectorization 직통. |
| 진짜 페타바이트 규모 | Spark / BigQuery / Snowflake | 이 quest 범위 밖. 원리는 그대로 transfer. |
말 안 한 default
2026 에 처음부터 시작하고 데이터가 파일에 있다면: Parquet 으로 저장, DuckDB 로 query, 크기에 따라 Pandas 또는 Polars 로 manipulate, Pandera 로 검증. 이 stack 이 대부분의 실무자에게 대부분의 문제에서 — 한 머신에서 — 더 무거운 게 필요하기 전까지 몇 년을 버텨.
요점은 표 외우는 거 아니야. 이 일의 모양은 뭘까? 라고 물어보는 반사를 키우는 거 — import 치기 전에.