5-5 연습 문제 — 한 사이클 종합 ⭐
요구사항부터 보고서까지 본인 손으로
섹션 5 의 마지막 연습. 요구사항 → 프롬프트 → SQL → 검증 → 보고서 — 라이브 시연으로 본 5단계 사이클을 이번엔 본인 손으로 처음부터 끝까지 돌립니다. 이 연습은 실제로 ChatGPT/Claude 와 DBeaver 를 같이 켜고 풀어야 합니다. 직접 굴려본 사이클만 머리에 남습니다.
이번 연습의 위치
완료 ✓
강의 완료 ✓
지금 여기 ⭐
AI 결과 의심하기 ★
2-4에서 만든 AI 과외 선생님 세션을 그대로 쓰세요. 막히면 정답이 아니라 힌트만 요청하고, 다 푼 뒤에는 본인의 SQL 을 던지며 “내 SQL 검증해줘” 라고 요청하세요. 이번 연습은 사이클 자체가 AI 협업이라 — 검증 단계에서 “이 결과 검산해줘” 후속 메시지까지 보내야 한 바퀴가 완성됩니다.
문제 1. 새 실무 시나리오 — 사이클 시작
다음 가상 요구사항으로 — 5 단계 사이클 전체 를 진행하세요.
“이번 분기에 어떤 상품 라인을 더 키워야 할지 고민 중인데. 지난 1년간 — 매출 상위 10% 회원이 — 가장 많이 산 상품 카테고리 와 각 카테고리의 평균 객단가 를 알려주세요.”
작업 단계 — 다섯 칸을 순서대로 본인 손으로 채웁니다.
사장님 문장을 그대로 SQL 로 옮기려 하지 말고 — 몇 개의 부분 문제로 나뉘는지 부터 적어보세요.
5-1 의 3가지 + 5-2 의 포맷 + 5-3 의 5 원칙 — 배운 걸 전부 담은 프롬프트를 만듭니다.
프롬프트를 보내고 SQL 을 받습니다. 여기서 끝이 아니라 — 다음 칸이 진짜 시작입니다.
행 수가 의미있는 수치인지, 컬럼의 의미가 의도와 맞는지, 검산 SQL 로 교차 확인까지.
숫자 나열이 아니라 — 비전공자도 이해할 수 있는 한 줄 로 정리합니다.
가이드 — 단계별 힌트
Step 1. 요구사항 분해 — 두 부분으로 나누기:
- 부분 A: 매출 상위 10% 회원이 누구인가 (회원ID 추출)
- 부분 B: 그 회원들이 산 카테고리별 — 주문 수 + 평균 객단가
Step 2. 프롬프트 구성 — 부분 A
[테이블 구조 + 관계 + 샘플]
... (shop 정리본 재사용)
[요구사항]
회원별 총 매출 (price × quantity 합) 을 계산하고,
상위 10% 회원의 member_id 목록을 추출.
- 상위 10% = 매출 순으로 정렬했을 때 상위 10%
- 출력: member_id, member_name, 총매출힌트: 회원이 16명 주문했으니 10% 는 약 2 명. 정확히는
LIMIT 2또는 PERCENT_RANK 윈도우 함수.
Step 3-4. AI SQL + 검증 — 받은 SQL 의 행 수를 검증:
- 2명 정도 나와야 정상
- 김철수 / 조성민 / 박민수 같은 다(多)주문자 후보
Step 5. 부분 B 프롬프트 + 검증
[방금 부분 A 결과 활용]
member_id 목록: (1, 9, ...) ← 부분 A 결과
이 회원들이 산 — 카테고리별:
1. 주문 횟수 (DISTINCT order_id)
2. 평균 객단가 (한 주문당 매출 평균)
WITH 절로 단계별 정리.자가 평가
- 각 단계마다 “이게 의도와 맞는지” 멈추고 검증했나?
- AI 가 만든 SQL 의 JOIN 깊이가 적절한가? (JOIN 뻥튀기 함정 회피)
- 결과의 행 수가 의미있는 수치인가? (회원 16명 중 10%, 카테고리 5개 등)
- AI 에게 “이 결과 검산해줘” 라는 후속 메시지를 보냈나?
문제 2. “AI 가 틀린 SQL” 시뮬레이션
다음 SQL 은 — AI 가 문제 1 의 부분 B 에 만들어준 답 인데 사실은 틀렸어요. 어디가 틀렸는지 찾고, 어떻게 검증할 수 있는지 본인이 시연하세요.
-- AI 가 만든 (틀린) SQL
SELECT
c.category_name,
COUNT(*) AS 주문수, -- ⚠️ DISTINCT 빠짐
AVG(p.price * oi.quantity) AS 평균_객단가 -- ⚠️ 평균의 의미 다름
FROM
members m
JOIN orders o
ON m.member_id = o.member_id
JOIN order_items oi
ON o.order_id = oi.order_id
JOIN products p
ON oi.product_id = p.product_id
JOIN categories c
ON p.category_id = c.category_id
WHERE
m.member_id IN (1, 9) -- 상위 10% 회원
GROUP BY
c.category_id, c.category_name;질문:
COUNT(*)이 무엇을 세나? 의도와 맞나?AVG(p.price * oi.quantity)가 정말 “객단가” 인가?- 어떻게 검증하고 수정해야 하나?
정답 보기
1. COUNT(*) 의 문제
COUNT(*) 는 JOIN 후의 모든 행 을 셉니다. 한 주문에 3 상품 있으면 그 카테고리에서 3 으로 셈 — 뻥튀기.
주문상세 행 수를 센다
JOIN 후의 모든 행을 세는 것 — “이 카테고리의 주문상세 행 수” 일 뿐, 주문 횟수가 아닙니다.
이 카테고리를 사러 온 횟수
의도는 “한 회원이 이 카테고리를 사러 온 횟수 (= DISTINCT order_id)”. 3-7 의 패턴 그대로입니다.
2. AVG(p.price * oi.quantity) 의 문제
AVG(price × quantity) 는 주문상세 행별 매출의 평균 — 즉 “한 줄당 평균 매출”. 객단가 (= 한 주문당 평균 매출) 와 다름.
모든 주문상세 행을 평면적으로 평균
한 주문에 5만원 상품 3개 있으면 5만원 × 3 = 15만원 인데, AVG 는 (50000 + 50000 + 50000) / 3 = 50000 으로 잘못 평균.
한 주문 = 그 주문의 총액
한 주문의 총액 = SUM(price × quantity) 을 먼저 구하고 — 그 총액들의 평균. 즉 주문별로 먼저 합산한 후 평균.
수정 (CTE 활용):
WITH order_totals AS (
SELECT
o.order_id,
c.category_id,
c.category_name,
SUM(p.price * oi.quantity) AS order_total
FROM
orders o
JOIN order_items oi
ON o.order_id = oi.order_id
JOIN products p
ON oi.product_id = p.product_id
JOIN categories c
ON p.category_id = c.category_id
WHERE
o.member_id IN (1, 9)
GROUP BY
o.order_id, c.category_id, c.category_name
)
SELECT
category_name,
COUNT(*) AS 주문수,
AVG(order_total) AS 평균_객단가
FROM
order_totals
GROUP BY
category_id, category_name;3. 검증 방법
- 검산 1:
COUNT(DISTINCT o.order_id)와COUNT(*)결과 비교 — 차이가 곧 JOIN 뻥튀기 양 - 검산 2: AVG 결과를 — 본인이 손으로 한두 주문 골라 계산해보기
- 검산 3: 결과 표의 합을 — 다른 방법으로 추출한 “이 회원들의 총 주문 수” 와 비교
AI 가 만든 SQL 의 컬럼명 (“평균_객단가”) 만 보고 “오 객단가 나왔네” 하면 큰 사고. 의미가 맞는지 항상 검증.
문제 3 (도전). 본인 실무 — 한 사이클 진행
본인 회사 / 프로젝트 또는 4-8 의 예시 도메인 중 하나로 — 실제로 “누군가가 던질 만한” 가상 요구사항 을 본인이 만들고, 5 단계 사이클을 진행하세요.
자가 평가 체크리스트
| # | 항목 | 체크 |
|---|---|---|
| 1 | 요구사항이 한 번에 안 풀리는가? (분해 필요) | ☐ |
| 2 | 프롬프트에 5 원칙 (컨텍스트·구체성·결과형태·한가지·검증) 다 들어갔나? | ☐ |
| 3 | AI 가 처음에 짠 SQL 이 의도와 맞았나? | ☐ |
| 4 | 검증 단계에서 의심한 부분 을 명확히 적었나? | ☐ |
| 5 | 검산 SQL 을 별도로 짜서 비교했나? | ☐ |
| 6 | AI 에 “결과 검산해줘” 후속 메시지를 보냈나? | ☐ |
| 7 | 최종 결과를 “비전공자도 이해할 수 있는” 한 줄로 요약했나? | ☐ |
이 사이클을 — 본인 업무에서 주 1 회만 반복 해도, 3 개월 후엔 “AI 시대 데이터 실무 역량” 이 손에 잡힙니다.
여기까지가 섹션 5 — AI 와 협업해서 SQL 을 만드는 한 사이클을 본인 손으로 완주했습니다. 다음 섹션 6 에서는 이 사이클의 심장인 의심하기 를 본격적으로 파고듭니다.