AI로 스키마 설계

🔄 Quick Recall: 이전 레슨에서 AI 기반 SQL 작성을 마스터했어요 — 스키마 우선 프롬프트 패턴, JOIN 검증, 반복 개선. 이번에는 스키마 자체를 설계해요.

비즈니스 요구사항에서 테이블로

최고의 스키마는 기술적 결정이 아닌 비즈니스 이해에서 시작해요. AI에게 비즈니스 도메인, 엔터티 간 관계, 예상 데이터 볼륨, 자주 실행할 쿼리를 설명하세요.

✅ Quick Check: 프롬프트에 “예상 데이터 볼륨"을 포함하는 이유는? 볼륨이 설계 결정을 바꾸기 때문이에요. 100행 테이블은 인덱스가 필요 없어요 — PostgreSQL이 밀리초 단위로 스캔해요. 1,000만 행 테이블은 전략적 인덱스가 필요하고 안 그러면 쿼리가 타임아웃돼요.

정규화: 규칙을 따를 때와 따르지 않을 때

AI는 보통 완전히 정규화된 스키마(3NF)를 제안해요. 대부분 맞지만 항상은 아니에요:

정규화할 때:

• 데이터가 자주 변경(고객 주소, 제품 가격)
• 데이터 무결성 보장이 필요(금융 기록)
• 여러 엔터티가 같은 데이터를 참조(불일치 방지)

비정규화할 때:

• 빠른 읽기가 필요하고 느린 쓰기를 허용할 수 있을 때
• 데이터가 거의 변하지 않을 때(이력 기록, 로그)
• 리포팅/분석 DB를 구축할 때(스타 스키마)

관계 설계

세 가지 관계 유형:

일대다 (가장 흔함): 고객 → 주문. orders 테이블에 customer_id 외래 키 추가.

다대다: 학생 ↔ 과목. 연결 테이블 생성: enrollments (student_id, course_id, enrolled_at).

일대일: 사용자 → 프로필. 같은 테이블에 포함하거나 같은 기본 키로 별도 테이블.

AI 검증 팁: AI가 관계를 생성한 후 그려보세요. 연결 테이블이 불필요해 보이면(일대다가 다대다로 위장된 경우) 의심하세요. AI에게 “이게 진짜 다대다인가요, 아니면 단순 외래 키면 충분한가요?“라고 물어보세요.

중요한 데이터 타입

제약조건과 인덱스 추가

AI가 놓칠 수 있는 제약조건을 제안받으세요: NOT NULL, CHECK(유효한 값), UNIQUE(중복 방지), DEFAULT 값, 그리고 자주 쓰는 쿼리를 위한 인덱스.

✅ Quick Check: AI에게 인덱스를 제안해달라고 할 때 자주 쓰는 쿼리를 나열해야 하는 이유는? 인덱스는 그걸 사용하는 쿼리에서만 가치가 있기 때문이에요. customer_name 인덱스는 항상 customer_id로 검색하면 쓸모없어요. 인덱스는 INSERT·UPDATE를 느리게 하는 비용도 있어요. AI에게 쿼리 패턴을 알려줘야 실제 이점을 주는 인덱스를 제안해요.

핵심 정리

• 기술적 결정이 아닌 비즈니스 요구사항과 쿼리 패턴에서 스키마 설계를 시작하세요
• 프롬프트에 예상 데이터 볼륨을 포함 — 볼륨이 정규화, 인덱싱, 데이터 타입 결정을 바꿔요
• AI는 과다 정규화 또는 과소 정규화하는 경향 — “이걸 실제로 따로 쿼리할 건가?“로 검증
• 데이터 타입을 의도적으로 선택: 돈에 DECIMAL, 시간에 TIMESTAMPTZ, ID에 UUID 또는 BIGSERIAL
• 제약조건(NOT NULL, CHECK, UNIQUE)으로 데이터베이스 수준에서 데이터 무결성 강화
• 인덱스 설계에는 쿼리 패턴 지식이 필요 — AI에게 인덱스 추천을 요청할 때 자주 쓰는 쿼리를 나열하세요

Up next: 다음 레슨에서 데이터 클리닝과 변환을 다뤄요 — AI로 지저분하고 비일관적인 데이터를 신뢰할 수 있는 쿼리 가능한 데이터셋으로 바꾸기.