SQL 입문부터 활용까지 — 데이터 분석 보고서와 대시보드 개발

코멘토 직무부트캠프(4주)의 주차별 기록입니다. 개발 경력 초기, SQL을 처음 체계적으로 배운 시기의 노트라 짧지만, 뒤에 5년 뒤에도 남아 있는 것을 붙여 둡니다.

1주차 — 기초 SQL

• Country별 조건 만족 고객 수: GROUP BY + COUNT(). 여기서 배운 것 중 지금도 쓰는 디테일 — COUNT(컬럼)은 NULL을 제외하고, COUNT(*)·COUNT(1)은 모든 행을 센다. 이 차이를 모르면 집계가 조용히 틀립니다.
• Customer별 주문 총 수량: LEFT JOIN vs INNER JOIN — "주문이 없는 고객도 0으로 보여야 하는가"가 선택 기준이라는 피드백.
• 년월별 Employee별 판매 개수: DATE_FORMAT()/SUBSTR()로 날짜를 그룹 키로 만드는 법.

2주차 — 심화

카테고리별 집계, 다중 테이블 JOIN, 서브쿼리로 JOIN 없이 추출하기, HAVING + 서브쿼리(세 번 이상 주문된 상품), 중첩 쿼리(연속 주문 직원)까지. "같은 답을 JOIN으로도 서브쿼리로도 낼 수 있다"는 걸 처음 체감한 주였습니다.

3주차 — 가설 설정과 검증

세 가설(덴버의 건당 금액 최소 / 81번 제품 주문량 최다 / 3월 매출 최소)을 세우고 데이터로 검증했는데, 셋 다 데이터가 반박했습니다. 받은 피드백이 오래 남았습니다:

지표 설정과 데이터 추출은 잘 수행됨. 다만 가설의 비즈니스적 의미가 부재하고, 결과 분석에서 더 깊은 인사이트 도출이 필요함.

쿼리는 맞는데 질문이 약하다는 지적이었어요.

4주차 — Northwind 대시보드

3주차까지의 쿼리를 지표로 묶어 대시보드로 만드는 마무리 과제였습니다.

5년 뒤에도 남아 있는 것

• COUNT(컬럼)의 NULL 제외는 지금도 집계 쿼리를 쓸 때마다 소환되는 지식입니다. ORM 뒤에 숨어 있어도 결국 이 규칙 위에서 동작하고요 — Django에서 쿼리가 안 보여 생기는 문제들은 ORM 글에 따로 정리했습니다.
• "주문 없는 고객도 보여야 하는가"라는 JOIN 선택 기준은 프레임워크가 바뀌어도 그대로였습니다. LEFT/INNER의 문법이 아니라 이 질문이 본체였어요.
• 제일 오래 남은 건 3주차 피드백입니다. "쿼리는 맞는데 질문이 약하다" — 이후 통계 대시보드를 개편하며 "이 화면이 없으면 못 아는 게 뭔가"를 먼저 묻게 된 습관의 출발점이 여기였다고 생각합니다.

각주 — 정직한 기록 하나. 원래 이 글에는 자료 링크로 github.com/dashboard라는 플레이스홀더가 그대로 게시돼 있었습니다. 실제 저장소 링크를 넣으려다 만 흔적인데, 5년 만에 발견해서 제거했습니다.