AI 프롬프트로 PostgreSQL 200% 활용하기

1. 역할 / 2. 맥락 / 3. 지시 / 4. 형식

SELECT/INSERT/UPDATE/DELETE 4가지를
같은 users 테이블로 한 파일에 정리.
각 문 + RETURNING 절 활용 + 트랜잭션 안전성.

주요 타입(text/varchar/int/serial/bigint/timestamp/jsonb/uuid/array/enum)을
표 + 언제 무엇을 쓰는지 + MySQL과의 차이.

WHERE 패턴 (=/IN/BETWEEN/LIKE/ILIKE/IS NULL/EXISTS)을 표 +
각 조건과 인덱스 활용도 + 성능 함정.

INNER/LEFT/RIGHT/FULL JOIN + CROSS JOIN을
같은 테이블 쌍으로 결과 비교 + ER 다이어그램.

COUNT/SUM/AVG/MIN/MAX + HAVING + DISTINCT를
매출 데이터로 5가지 분석 쿼리.

B-Tree/GIN/BRIN/Hash 인덱스를
각각 언제 사용 + EXPLAIN ANALYZE로 효과 측정 +
복합 인덱스 컬럼 순서 결정 트리.

ROW_NUMBER/RANK/DENSE_RANK/LAG/LEAD/SUM OVER를
같은 데이터로 5가지 분석 쿼리. PARTITION BY + ORDER BY.

READ COMMITTED / REPEATABLE READ / SERIALIZABLE 차이 +
동시성 이슈(dirty read, phantom) + SELECT FOR UPDATE.

WITH 절(CTE) + RECURSIVE를 활용해
조직도 트리 / 카테고리 트리 쿼리를 만들어줘.
ORM과 비교.

느린 쿼리 진단 5단계.
EXPLAIN ANALYZE / 인덱스 / VACUUM / 통계(ANALYZE) /
파티셔닝. 각 단계 코드 + 효과 측정.

PostgreSQL 보안 체크리스트.
역할/권한/RLS(Row Level Security) /
SSL / pg_hba.conf / 백업 암호화 +
SQL Injection 방지(매개변수화).

-- ❌ 나쁜: '게시물 목록 쿼리'
SELECT * FROM posts WHERE user_id = 5;
-- 문제: 페이지네이션·인덱스 없음, * 사용


-- ✅ 좋은: 인덱스 + cursor + 명시적 컬럼
CREATE INDEX IF NOT EXISTS idx_posts_user_created ON posts(user_id, created_at DESC, id DESC);

-- 첫 페이지
SELECT id, title, created_at FROM posts
WHERE user_id = 5
ORDER BY created_at DESC, id DESC
LIMIT 20;

-- 다음 페이지 (cursor: 이전 마지막의 created_at + id)
SELECT id, title, created_at FROM posts
WHERE user_id = 5
  AND (created_at, id) < ('2026-04-24 10:00:00', 100)
ORDER BY created_at DESC, id DESC
LIMIT 20;

/* 📊 비교: 인덱스·페이지네이션·확장성 모두 갖춤. 프롬프트 구체성이 코드 품질을 결정 */