SQL 학습

왜 다시 SQL인가?

ML 공부를 하다 보면 어느 순간 Pandas에서 groupby 돌리는 게 느려서 짜증나는 시점이 온다. 알고 보면 그 연산 대부분은 처음부터 DB에서 끝냈어야 하는 것들이다.

대용량을 통째로 끌어와서 Python에서 처리하는 건 그냥 비효율이다. DB 단에서 집계와 피처를 만들고 최소한의 데이터만 올리는 게 훨씬 빠르고 깔끔하다. 당연한 이야기인데, 실제로 느려지기 전까지는 잘 와닿지 않는다.

핵심 기능: AI 엔지니어 관점

JOIN/GROUP BY — 학습 데이터셋의 기본

여러 테이블을 결합해 모델이 학습 가능한 단위로 정규화된 뷰를 만든다. 간단한 것 같지만, 여기서 피처 설계 방향이 결정된다.

윈도우 함수 — DB 단 피처 엔지니어링

가장 쓸모 있었던 건 LAG, LEAD, RANK 같은 윈도우 함수다. 시계열이나 순위 기반 피처를 Python에서 굳이 만들 필요가 없어진다. 예를 들어 사용자별 직전 구매 시점으로부터의 경과 시간, 이런 게 SQL 한 방에 나온다.

1SELECT
2  user_id,
3  order_timestamp,
4  EXTRACT(EPOCH FROM (
5    order_timestamp - LAG(order_timestamp, 1) OVER (PARTITION BY user_id ORDER BY order_timestamp)
6  )) AS time_since_last_order
7FROM orders;

서브쿼리/CTE — 복잡도를 단계화

가독성과 재사용성을 높여서 협업이랑 유지보수가 편해진다. 복잡한 피처 로직을 여러 단계로 쪼갤 수 있다는 게 실무에서 꽤 중요하다.

워크플로우 영향

SQL을 다시 제대로 보고 나서 일하는 방식이 꽤 바뀌었다.

• 피처 엔지니어링의 중심이 DB로 이동했다. 무거운 연산은 SQL로 처리하고 Python은 모델링에 집중하게 됐다.
• EDA도 빨라졌다. GROUP BY/COUNT로 분포와 이상치 윤곽을 먼저 잡고 들어가니까 탐색 시간이 줄었다.
• 커뮤니케이션도 달라졌다. 문제 지점을 스키마나 파티션 단위로 명확히 지적할 수 있게 됐다.

ML 엔지니어에게 SQL은 선택이 아니라 기본기라는 걸 다시 느꼈다.