결과 예시
절 단위 표가 실행 순서대로 나왔고, LEFT JOIN 인데 WHERE 가 오른쪽 표를 걸러 사실상 INNER JOIN 이 되는 함정을 잡아냈다.
| 코드 조각 | 하는 일 | 주의점 |
|---|---|---|
| WHERE o.created_at >= '2026-01-01' | 올해 만들어진 주문만 남깁니다 | 주문 없는 고객이 여기서 탈락해 LEFT JOIN 이 무의미해집니다 |
| HAVING COUNT(o.id) >= 3 | 묶은 뒤 주문 3건 이상인 그룹만 남깁니다 | WHERE 는 묶기 전, HAVING 은 묶은 뒤에 거릅니다 |
CREATE TABLE 문을 함께 붙이면 열 이름 추측이 사라집니다.
Claude에서 실제로 실행해 확인 · 2026-09
왜 이렇게 쓰는가
코드를 설명해 달라는 요청은 AI가 가장 잘하는 일 중 하나지만, 설명의 "순서"와 "깊이"를 정해 주지 않으면 결과가 들쭉날쭉합니다. 이 프롬프트는 그 둘을 고정합니다.
역할을 "처음 배우는 사람을 가르치는 강사"로 두면 설명의 깊이가 정해집니다. 같은 쿼리를 "시니어 DBA"에게 설명받으면 실행 계획과 인덱스 이야기가 먼저 나옵니다. 맥락에서 데이터베이스 종류를 알려 주는 이유는 문법이 조금씩 달라서입니다. LIMIT 은 MySQL·PostgreSQL 에 있지만 SQL Server 는 TOP 을 쓰고, 날짜 함수는 제품마다 다릅니다. 이 한 단어가 엉뚱한 문법 지적을 막습니다.
과제 문단에서 "실행 순서 기준"이 핵심입니다. SQL 은 쓰는 순서(SELECT 가 맨 앞)와 실행되는 순서(FROM 이 맨 앞)가 다르고, 초보자가 헷갈리는 지점이 바로 여기입니다. 순서를 명시하면 "왜 WHERE 에서는 별칭을 못 쓰는가" 같은 질문이 자연스럽게 풀립니다.
형식의 "한마디로 " 문장은 전체 그림을 먼저 잡게 하고, "결과 예시 3행"은 머릿속에서 결과 표를 그려 보게 합니다. 이 두 가지가 없으면 설명은 정확해도 읽고 나서 "그래서 뭐가 나오는데?"가 남습니다. 제약의 "12개만"은 AI가 사소한 스타일 지적으로 설명을 길게 늘이는 것을 막습니다. 쿼리를 """ 로 감싼 것은 쿼리 안의 주석(-- 이건 지워)이 지시로 읽히지 않게 하기 위해서입니다.
용어가 낯설면 아하AI에서: prompt, hallucination
나쁜 예와 비교
이 쿼리 설명해줘 SELECT ... (쿼리 붙여넣기)
설명은 나오지만 SELECT 절부터 쓰는 순서대로 훑어 내려가서, 초보자가 정작 궁금한 "언제 걸러지고 언제 묶이는가"가 빠집니다. 어떤 DB 인지 모르니 관계없는 문법 주의사항이 붙기도 합니다.
변형
쿼리를 고쳐야 할 때
당신은 {{데이터베이스}} 성능 튜닝 경험이 많은 데이터 엔지니어입니다. 아래 쿼리를 설명하지 말고, 같은 결과를 내면서 더 읽기 쉽거나 빠른 쿼리로 고쳐 주세요. 고친 쿼리 → 무엇을 왜 바꿨는지 표(전 · 후 · 이유) → 결과가 달라질 수 있는 경우가 있다면 경고, 순서로 답해 주세요. 확신이 없는 최적화는 제안하지 마세요.
""" {{쿼리}} """
역할을 엔지니어로 바꾸고 "설명하지 말고"를 명시했습니다. "확신이 없는 최적화는 제안하지 마세요"가 없으면 검증되지 않은 힌트가 붙습니다.
한 줄 요약만
아래 {{데이터베이스}} 쿼리가 무엇을 하는지 비개발자에게 설명하듯 두 문장으로 요약해 주세요. 기술 용어는 쓰지 마세요.
""" {{쿼리}} """
기획자나 팀장에게 쿼리 목적을 전달할 때 씁니다.
모델별 주의
테이블 구조를 모르면 AI가 열 이름의 뜻을 추측합니다. CREATE TABLE 문이나 열 목록을 함께 붙여 넣으면 정확도가 올라갑니다
관련 프롬프트
마지막 수정 2026-09-02 · 잘못된 점이 있나요? 알려 주세요