AI 시대 DB 모델링 & SQL 완벽 마스터4-8 모델링 종합 실습 ⭐
테크타니 LEARN — 섹션 04 · DB 모델링

요구사항 한 문단을 받아,
ERD 한 장으로 완성하기

섹션 4의 마지막 강의이자 종합 실습입니다. "학원 등록 시스템"이라는 작은 도메인을 받아 — 요구사항 정리, 엔티티 추출, 관계 정의, ERD 그리기 — 4단계를 처음부터 끝까지 직접 해봅니다. 마지막엔 완성한 ERD를 AI에게 검증시키는 실무 협업 방식까지 시연합니다.

난이도보통소요8분준비물4-1 ~ 4-7 완료형태종합 실습 ⭐

이번 섹션의 여정

4-1 ~ 4-4 관계·FK

완료 ✓

→
4-5 ~ 4-6 ERD·정규화

완료 ✓

→
4-7 실무 ERD 분석

완료 ✓

→
4-8 모델링 종합 실습 ⭐

지금 여기

→
섹션 5

AI 협업 SQL 작성법

Step 1 — 요구사항 정리: 모든 모델링의 출발점

지금까지 부모-자식, 관계 종류, FK, ERD 읽기, 정규화, 도메인 비교까지 다 봤습니다. 이번엔 직접 만들어볼 시간이에요. 오늘 갈 길을 지도 한 장으로 먼저 보고 갑니다.

모델링 파이프라인 — 오늘 하는 일 전부
Step 1 Step 2 Step 3 Step 4
요구사항 정리 → 엔티티 추출 → 관계 정의 → ERD 그리기
 
+ Step 5 완성한 ERD를 AI에게 검증받고 보완하기 ⭐
시작 전 체크
4-1 ~ 4-7 완료 — 관계·FK·ERD·정규화 개념
종이·화이트보드 또는 그림판 (그릴 수만 있으면 OK)
2-4에서 만든 AI 과외 선생님 세션 (Step 5에서 사용)

회사에서 이런 메시지를 받았다고 상상해보세요.

"학원 등록 시스템을 만들어야 해요.
학생들이 강의를 신청할 수 있고, 한 학생이 여러 강의를 신청할 수 있어요.
강의마다 강사가 한 명씩 있고, 강사는 여러 강의를 맡을 수 있어요.
학생 등록 시 결제가 이뤄지고, 결제 정보는 안전하게 별도 관리해야 해요."

이게 실무에서 받는 요구사항의 전형적인 형태입니다 — 한두 문단의 자연어. 표도 없고 ERD도 없어요. 여기서 모델링이 시작됩니다. 첫 작업은 이 문단을 핵심 문장 단위로 쪼개는 것입니다.

  • “학생들이 강의를 신청한다”
  • “한 학생이 여러 강의를 신청할 수 있다”
  • “강의마다 강사가 한 명씩 있다”
  • “강사는 여러 강의를 맡을 수 있다”
  • “학생 등록 시 결제가 이뤄진다”
  • “결제 정보는 안전하게 별도 관리한다”
문장마다 단서가 들어 있습니다

각 문장이 “누가, 무엇을, 어떻게 한다” 구조예요. 명사에서 엔티티가, “여러 / 한 명씩” 같은 수량 표현에서 관계가 나옵니다. 다음 두 단계에서 하나씩 캐냅니다.

Step 2 — 엔티티 추출: 명사를 찾으세요

엔티티(Entity) 는 데이터로 표현할 “것 / 사물” — 요구사항 속의 명사입니다. 방금 쪼갠 문장들을 다시 읽으면서 명사에 형광펜을 그어보세요.

요구사항 속 명사테이블 이름
학생students
강의courses
강사teachers
결제payments

엔티티 4개. 그런데 — 여기서 멈추면 빠진 게 하나 있습니다.

✕ 명사만 뽑고 끝내면

엔티티 4개 — 신청 기록이 갈 곳이 없다

학생·강사·강의·결제는 챙겼는데, “학생이 강의를 신청한다”의 신청 자체를 저장할 곳이 없습니다. 누가 언제 어떤 강의를 신청했는지 — 기록할 테이블이 없어요.

✓ 행위도 엔티티로

신청 → enrollments, 5개 완성

신청이라는 행위 자체가 데이터입니다. 그리고 이게 바로 4-3에서 배운 N:M 중간 테이블 — 학생과 강의의 다대다 관계를 풀어주는 자리예요.

놓치기 쉬운 깨달음

명사뿐 아니라 행위(신청·주문·예약·결제)도 거의 항상 엔티티가 됩니다.

우리 shop DB의 orders·order_items가 정확히 이 패턴이었죠 — “주문한다”는 행위가 테이블 두 개가 됐습니다.

최종 엔티티 5개 — students, teachers, courses, enrollments, payments.

Step 3 — 관계 정의: 한 X가 여러 Y? 반대도?

엔티티 사이의 관계는 4-3에서 배운 식별 질문 하나로 결정합니다 — “한 X가 여러 Y를 가질 수 있나? 반대 방향은?”

관계양방향 질문의 답결과
강사 ↔ 강의한 강사가 여러 강의 YES / 한 강의에 강사는 1명1:N — teachers → courses
학생 ↔ 강의양쪽 다 여러 개 YESN:M — enrollments가 풀어줌
학생 ↔ 신청한 학생이 여러 신청 YES1:N — students → enrollments
강의 ↔ 신청한 강의에 여러 신청 YES1:N — courses → enrollments
신청 ↔ 결제설계 선택이 필요 (아래)1:1 ⭐

마지막 줄에서 잠깐 멈춥니다. “학생 등록 시 결제가 이뤄진다” — 이 문장은 두 가지로 해석할 수 있어요. 설계 선택이 필요한 순간입니다.

선택 ① — 오늘은 아님

students 1:N payments — 묶음 결제

학생이 강의 여러 개를 한 번에 묶어 결제하는 모델. 결제 1건에 신청 여러 건이 매달립니다. 틀린 설계가 아니에요 — 비즈니스가 장바구니식 결제라면 이쪽이 정답입니다.

선택 ② — 오늘의 선택

enrollments 1:1 payments — 신청별 결제

신청 1건마다 결제 1건. 강의 단위로 결제·환불을 처리하기 쉽고, “결제 정보는 별도 관리” 요구와도 맞습니다. 4-3에서 배운 1:1 분리 패턴이 한 번 더 등장하네요.

설계에 단일 정답은 없습니다

두 선택 모두 성립합니다. 중요한 건 “왜 이 선택을 했는지” 말할 수 있는 것 — 실무에서는 이 순간에 기획자에게 “결제는 강의별인가요, 묶음인가요?” 하고 되묻는 게 모델러의 일입니다.

Step 4 — ERD 그리기: PK·FK·UNIQUE까지

이제 화이트보드에 뼈대부터 슥슥 그립니다. 까마귀발 없이 선만 그어도 충분해요.

화이트보드 — 뼈대 스케치
teachers ─< courses ─< enrollments >─ students
│
└── payments (1:1)
 
─< : 1쪽에서 N쪽으로 갈라진다 (1:N)

뼈대가 잡혔으면 각 엔티티의 PK와 FK를 명시해서 정식 ERD로 완성합니다.

여기서 기술적으로 제일 중요한 한 줄 — payments.enrollment_id에 거는 UNIQUE 제약입니다. FK만 있으면 한 신청에 결제가 여러 건 붙을 수 있는 1:N이 돼버려요. UNIQUE가 있어야 “한 결제 = 한 신청” 을 DB가 강제합니다.

CREATE TABLE payments (
  payment_id    INT AUTO_INCREMENT PRIMARY KEY,
  enrollment_id INT NOT NULL UNIQUE,   -- 이 UNIQUE 가 1:1 을 보장
  paid_at       DATETIME NOT NULL,
  amount        INT NOT NULL,
  FOREIGN KEY (enrollment_id) REFERENCES enrollments (enrollment_id)
);
1:1 의 핵심 장치

1:1 관계는 선으로 그리는 게 아니라 FK + UNIQUE 조합으로 구현합니다.

4-4의 FK가 “부모 없는 자식 금지”를 강제했다면, UNIQUE는 “자식은 한 명만”을 강제하는 장치예요.

Step 5 — AI와 협업: 검증시키고 보완하기 ⭐

이제 이 강의의 하이라이트 — AI와 협업하는 모델링입니다. 방금 만든 ERD를 AI에게 검증시켜볼 거예요. 그 전에, 협업의 방향부터 분명히 하고 갑니다.

✕ 이렇게 쓰면 실력이 늘지 않습니다

”AI야, 학원 등록 시스템 ERD 만들어줘”

그럴듯한 결과는 나옵니다. 하지만 어디가 맞고 틀렸는지 판단할 눈이 없으면 받아쓰기일 뿐이에요. 1:1이냐 1:N이냐 같은 설계 선택이 왜 그렇게 됐는지도 모른 채 넘어가게 됩니다.

✓ 진짜 실무 방식

내가 1차 설계 → AI가 검토 → 내가 보완

4단계로 직접 만든 ERD를 던지고 검증을 요청합니다. 빠진 컬럼, 상태값, 삭제 정책 같은 구멍을 AI가 찾아주고 — 최종 결정은 항상 내가 내립니다.

2-4에서 만든 AI 과외 선생님 세션에 아래 프롬프트를 그대로 던져보세요.

다음 학원 등록 시스템 ERD 를 검토해줘:

[엔티티]
- students (학생): student_id PK, name
- teachers (강사): teacher_id PK, name
- courses (강의): course_id PK, title, teacher_id FK, fee
- enrollments (신청): enrollment_id PK, student_id FK, course_id FK, enrolled_at
- payments (결제): payment_id PK, enrollment_id FK UNIQUE, paid_at, amount

[관계]
- teachers 1:N courses
- students 1:N enrollments
- courses 1:N enrollments  (→ students ↔ courses 의 N:M)
- enrollments 1:1 payments

[검증 요청]
1. 빠진 엔티티 / 관계는?
2. 정규화 직관 위반된 곳은?
3. 보완해야 할 컬럼은?
4. 실무에서 추가로 고려할 점은?
AI 과외 선생님 — ERD 검토
나: (위 프롬프트 + ERD 전송)
 
AI: 전체 구조는 탄탄합니다. 보완 포인트 세 가지 —
 
① 신청의 진도·완료 상태가 없어요
→ enrollments.status (in_progress/completed/cancelled)
② 환불을 고려하면 결제에도 상태가 필요해요
→ payments.status (paid/refunded)
③ 강사 휴직·퇴사 시 강의는 어떻게 되나요?
→ courses.teacher_id FK 에 ON DELETE SET NULL 검토
 
피드백을 받아 내 ERD를 한 번 더 다듬는다 — 이게 협업
1차 설계 → AI 검증 → 보완, 사이클 완성
⭐ 강의 메시지의 정수

AI가 ERD를 처음부터 만들어주는 게 아닙니다. 내가 1차로 만들고, AI가 피드백하고, 내가 보완한다.

이 사이클이 진짜 실무의 AI 협업 모델링입니다.

자주 막히는 지점

① 엔티티를 몇 개나 뽑아야 할지 감이 안 와요

너무 많이 뽑아도, 너무 적게 뽑아도 불안한 단계입니다. 기준은 “여러 건 저장할 데이터인가”예요 — “학원 이름” 같은 단일 값은 엔티티가 아닙니다.

FIX ▸명사를 일단 전부 적고 — "이게 여러 건 쌓이는 기록인가?" 로 추려내세요. 행위(신청·주문·예약·결제)는 거의 항상 엔티티입니다.
② 학생과 강의를 그냥 직접 연결하면 안 되나요?

양쪽 다 “여러 개”인 관계를 FK 하나로 이으려 하면, 한쪽 테이블에 FK 컬럼을 여러 개 만들거나 한 칸에 여러 값을 욱여넣게 됩니다 — 4-6에서 본 안티패턴이에요.

FIX ▸관계형 DB에는 N:M을 직접 표현하는 방법이 없습니다. 중간 테이블(enrollments)이 유일한 길 — 4-3을 복습하세요.
③ AI가 피드백 대신 새 ERD를 통째로 만들어버려요

요청이 모호하면 AI는 자기 설계를 새로 제안하는 쪽으로 흐릅니다. 검토 범위를 좁혀주는 게 협업의 기술이에요.

FIX ▸"내 설계를 기준으로 검토만 해줘. 새로 만들지 마" 를 프롬프트에 명시 — 위 프롬프트처럼 검증 요청 항목을 번호로 주면 더 확실합니다.

섹션 4 완주 — 메시지를 손에 잡았습니다

오늘 한 일을 한 줄씩 정리하면 이렇습니다.

Step무엇을핵심 도구
1. 요구사항 정리자연어 한 문단 → 문장 단위 분해형광펜 / 메모
2. 엔티티 추출명사 찾기 + “행위도 엔티티” 점검화이트보드
3. 관계 정의”한 X가 여러 Y? 반대도?” 식별 질문양방향 답 표
4. ERD 그리기PK·FK 명시 + UNIQUE 등 제약mermaid / draw.io
5. AI와 협업1차 설계 → 검증 → 보완AI 과외 선생님

그리고 — 섹션 4, 모델링이 끝났습니다. 8개 강의 동안 걸어온 길입니다.

강의핵심 한 줄
4-1 관계의 구조엑셀 한 장 사고에서 관계 사고로
4-2 부모 / 자식 테이블 ⭐모든 관계는 결국 부모-자식
4-3 1:1 / 1:N / N:M식별 질문으로 관계 판별
4-4 외래키 (FK)관계를 DB가 강제하는 장치
4-5 ERD 읽는 법설계도를 읽는 5단계 루틴
4-6 정규화 직관중복 제거의 두 가지 직관
4-7 실무 ERD 분석도메인이 달라도 뼈대는 같다
4-8 모델링 종합 실습 ⭐요구사항 → ERD, 직접 완주
⭐ 이 강의의 마케팅 메시지, 그 절반”DB 모델링만 알면 AI가 SQL 다 만들어준다.”

— 앞부분 “DB 모델링”을 방금 손에 잡으셨습니다. 여기까지 따라오신 분들, 진심으로 박수.

다음 섹션 예고 — 나머지 절반

섹션 5 AI 협업 SQL 작성법에서는 — 여러분이 만든 이 모델링을 AI에게 어떻게 정확히 전달하고, 어떤 프롬프트가 좋은지 단계별로 다룹니다. 모델링이 무기라면, 섹션 5는 그 무기를 쓰는 법이에요.

먼저 연습 문제로 오늘의 4단계를 새 도메인에 한 번 더 적용해보세요 — 손에 잡힌 흐름은 한 번 더 굴려야 진짜 내 것이 됩니다.

NEXT LESSON4-8 연습 문제

새 도메인의 요구사항을 받아 — 엔티티 추출부터 ERD까지 직접 한 바퀴 돌려봅니다.

GO ▸ 연습 문제 풀기
4-7 연습 문제4-8 연습 문제 ⭐