AI 기반 SQL 작성

스키마 우선 프롬프트 패턴

AI 기반 SQL의 가장 중요한 기법: 항상 스키마를 제공하세요.

나쁜 프롬프트: “비활성 고객을 찾는 쿼리를 써주세요.”

좋은 프롬프트:

데이터베이스: PostgreSQL
테이블:
- customers (id SERIAL, name TEXT, email TEXT, created_at TIMESTAMP)
- orders (id SERIAL, customer_id INT REFERENCES customers(id), total DECIMAL, order_date DATE, status TEXT)

지난 90일 동안 주문하지 않았지만 그 전에 최소 1건의 주문이 있던 고객을 찾아주세요. 이름, 이메일, 마지막 주문일, 총 평생 지출액을 포함해주세요.

스키마 맥락이 추측을 없애요. AI가 정확한 칼럼명, 데이터 타입, 관계를 알아서 — 첫 시도에 실행되는 쿼리를 만들어요.

✅ Quick Check: 프롬프트에서 total 칼럼을 DECIMAL, order_date를 DATE로 지정하는 게 왜 중요할까요? 데이터 타입이 어떤 함수가 작동하는지 결정하기 때문이에요. AI가 날짜 칼럼을 TEXT로 생각하면 적절한 날짜 연산 대신 문자열 비교를 시도할 수 있어요. 명시적 타입이 더 정확한 쿼리를 만들어요.

JOIN: 실수가 일어나는 곳

JOIN은 AI 생성 SQL이 가장 자주 틀리는 곳이에요:

중복 행: AI가 GROUP BY나 DISTINCT가 필요한데 일반 JOIN을 써요. 누락 데이터: AI가 LEFT JOIN이 필요한데 INNER JOIN을 써요(주문 없는 고객이 사라져요). 잘못된 관계: 테이블 이름이 모호할 때 AI가 잘못된 칼럼으로 조인해요.

검증 팁: JOIN 쿼리를 실행한 후 행 수를 확인하세요. 고객이 1,000명인데 쿼리가 5,000행을 반환하면, JOIN에서 원치 않는 카테시안 곱이 생긴 거예요.

집계와 GROUP BY

집계 쿼리(SUM, COUNT, AVG)와 GROUP BY, HAVING은 AI의 강점이에요 — 수동으로 쓰기 번거롭지만 AI가 잘 처리해요.

✅ Quick Check: 왜 전년 대비 성장률 쿼리가 월간 매출 쿼리보다 AI에게 어려울까요? 성장률은 같은 카테고리에 대해 두 다른 기간(올해 vs 작년)을 비교해야 하기 때문이에요. 보통 윈도우 함수나 셀프 조인이 필요하고, AI가 할 수 있지만 날짜 경계를 주의해서 검증해야 해요.

서브쿼리와 CTE

복잡한 분석에는 AI에게 가독성을 위해 CTE(Common Table Expression)를 사용하도록 가르치세요. CTE는 복잡한 쿼리를 디버깅하기 쉽게 만들어요 — 한 섹션이 잘못되면 그 CTE만 독립적으로 실행할 수 있어요.

반복 개선 루프

실제 AI 기반 쿼리 작성은 이 패턴을 따라요:

1. 첫 프롬프트: 전체 스키마 맥락과 함께 필요한 것 설명
2. 쿼리 실행: 구문 에러 확인
3. 결과 검증: 알려진 데이터 포인트와 비교
4. 개선: AI에게 구체적으로 뭐가 틀렸는지 알려주기(“날짜 범위가 포괄적이어야 해요”, “JOIN에서 중복 행이 나와요”)
5. 반복 — 결과가 기대와 일치할 때까지

이 루프는 복잡한 쿼리에서 보통 2-3회 반복이에요 — 그래도 처음부터 쓰는 것보다 훨씬 빨라요.

핵심 정리

• AI에게 SQL을 요청할 때 항상 스키마(테이블명, 칼럼, 타입, 관계)를 포함하세요
• 데이터베이스 시스템을 지정하세요 — PostgreSQL, MySQL, SQL Server는 날짜, 문자열, 고급 기능에서 다른 구문을 써요
• JOIN은 AI가 가장 많이 실수하는 곳 — 행 수를 검증하고 중복이나 누락을 확인하세요
• 반복 개선(프롬프트 → 실행 → 검증 → 수정)은 복잡한 쿼리에서 보통 2-3사이클
• CTE가 복잡한 AI 생성 쿼리를 읽기 쉽게 만들고 섹션별 디버깅이 가능해요

Up next: 다음 레슨에서 AI로 데이터베이스 스키마를 설계하는 법을 배워요 — 비즈니스 요구사항을 정규화된, 효율적인 테이블 구조로 변환.