같은 요구사항, 천차만별 결과 —
나쁜 프롬프트 5가지 안티패턴

이번 섹션의 여정

5-1에서 AI에게 꼭 줘야 할 3가지(스키마·샘플 데이터·결과 형태)를, 5-2에서 그걸 전달하는 포맷을 배웠죠. 이번 강의는 반대편에서 봅니다 — 사람들이 실제로 자주 던지는 나쁜 프롬프트 5가지를 해부하고, 각각을 좋은 프롬프트로 고쳐봅니다. 다섯 장면 모두 우리 shop DB 기준입니다.

안티패턴 ① — 컨텍스트 없는 한 줄

가장 흔한 유형입니다. 머릿속 요구사항을 한 줄로 압축해서 던지는 것.

[테이블 구조]
- categories: category_id PK, category_name
- products: product_id PK, price, category_id FK → categories
- order_items: order_id FK, product_id FK, quantity

[요구사항]
카테고리별 총 매출 (price × quantity 의 합).
출력: 카테고리명, 총매출. 매출 많은 순.

이 프롬프트가 받아낸 SQL을 DBeaver에서 돌려보면 —

안티패턴 ② — 모호한 단어

이번엔 컨텍스트를 줬다 해도 빠지기 쉬운 함정 — 사람끼리만 통하는 단어입니다.

자주 쓰는 모호한 단어들, 이렇게 바꾸면 됩니다.

안티패턴 ③ — 결과 형태를 말하지 않음

쿼리 내용은 맞게 시켰는데, 받고 싶은 표의 모양을 말하지 않는 경우입니다.

회원별 매출 합계.
- 출력 컬럼: 회원이름, 총매출
- 정렬: 매출 많은 순
- 행 수: 최대 10개

안티패턴 ④ — 한 번에 너무 많이

요구사항이 명확해도, 한 번에 전부 시키면 또 다른 문제가 생깁니다.

안티패턴 ⑤ — 받은 SQL을 검증하지 않음 ⭐

다섯 가지 중 가장 위험한 안티패턴이자, 이 강의 전체를 관통하는 핵심입니다.

검증 루틴을 3단계로 정리하면 이렇습니다.

안티패턴 ③의 좋은 프롬프트로 받은 SQL을 실제로 검증해보면 —

SELECT
  m.member_name,
  SUM(p.price * oi.quantity) AS total_sales
FROM
  orders o
JOIN members m
  ON m.member_id = o.member_id
JOIN order_items oi
  ON oi.order_id = o.order_id
JOIN products p
  ON p.product_id = oi.product_id
GROUP BY
  m.member_name
ORDER BY
  total_sales DESC
LIMIT 10;

좋은 프롬프트 5원칙 — 한 장 정리

다섯 장면을 한 표로 모으면 이렇게 됩니다. 캡처해서 저장해두세요.

이제 자가 진단입니다. 본인의 평소 SQL 요청 프롬프트를 떠올려보세요 — 몇 개나 지키고 있나요?

3개 이상이면 평균 이상 프롬프터, 5개 모두면 AI 시대 SQL 실력자입니다. 부족했던 항목이 보였다면 — 그게 오늘 강의의 수확이에요.

자주 막히는 지점

오늘 비교한 다섯 장면 중 분명 찔리는 게 하나는 있었을 거예요. 다음 강의는 안티패턴 ④의 해결책 — 복잡한 요구사항을 단계별로 쪼개는 CTE 사고법입니다. 그 전에 연습 문제로 5원칙을 손에 익혀두세요.