AI 시대 DB 모델링 & SQL 완벽 마스터4-7 실무 ERD 분석
테크타니 LEARN — 섹션 04 · DB 모델링

쇼핑몰·SNS·예약 — 도메인이 바뀌어도
부모-자식 패턴은 그대로입니다

지금까지는 shop 한 도메인으로만 모델링을 봤습니다. 오늘은 완전히 다른 비즈니스 세 개의 ERD를 나란히 놓고 비교합니다. 쇼핑몰, SNS, 예약 시스템 — 서로 전혀 다른 서비스인데, 데이터 모델의 뼈대는 거의 같다는 걸 직접 확인하는 시간입니다.

난이도보통소요7분준비물4-5 · 4-6 완료형태ERD 3장 비교 분석

이번 섹션의 여정

4-1 ~ 4-4 관계·FK

완료 ✓

→
4-5 ERD 읽는 법

완료 ✓

→
4-6 정규화 직관

완료 ✓

→
4-7 실무 ERD 분석 ⭐

지금 여기

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

직접 ERD 그리기

→
섹션 5

AI 협업 SQL 작성법

이번 강의는 직접 치는 SQL이 없는 읽는 강의입니다. 대신 앞에서 배운 도구를 전부 꺼내 씁니다 — ERD 3장을 같은 사고법으로 분석하면서, “모델링 사고법 하나로 모든 도메인을 다룰 수 있다” 는 걸 눈으로 확인할 거예요.

시작 전 체크 — 이 두 가지가 머리에 있나요?
4-5 — ERD 읽기 5단계 (마스터 찾기 → 부모-자식 → 관계 종류 …)
4-6 — 두 직관 (같은 정보 두 번 X · 한 테이블에 한 종류만)
N:M 은 중간 테이블로 푼다 (4-3)

도메인 1 — 쇼핑몰: 이미 아는 그림 (복습)

이미 익숙한 우리 shop부터 빠르게 복습합니다. 5테이블, 부모-자식 4쌍.

부모-자식 관계를 한 줄로 요약하면 이렇습니다.

shop — 부모-자식 한 줄 요약
members ──1:N──▶ orders ──1:N──▶ order_items
categories ──1:N──▶ products ──1:N──▶ order_items
 
직접 관계는 전부 1:N — orders ↔ products 의 N:M 은 order_items 가 풀어줌
패턴shop 에서의 적용
1:Nmembers→orders · categories→products · orders→order_items · products→order_items
N:M (중간 테이블)orders ↔ products — order_items 가 풀어줌
비즈니스 흐름으로 읽으면

“운영자가 카테고리·상품을 등록하고 → 회원이 가입하고 → 주문하면 → 주문상세가 기록된다.” — 4-5에서 배운 대로, ERD는 결국 비즈니스가 흘러가는 순서입니다.

도메인 2 — SNS: 새 패턴 두 개가 나옵니다

이번엔 SNS입니다. 인스타그램이나 X(트위터) 같은 서비스를 떠올리면 돼요. 사용자가 글을 쓰고, 댓글을 달고, 좋아요를 누르고, 서로 팔로우합니다.

뼈대는 익숙합니다 — users→posts, posts→comments 전부 1:N. 그런데 여기서 새로운 패턴 두 개가 등장합니다.

패턴 ① — 자기참조 N:M (팔로우). “한 사용자가 여러 사용자를 팔로우하고, 한 사용자가 여러 사용자에게 팔로우당한다.” — users 한 테이블이 자기 자신과 N:M 관계입니다. N:M이니 당연히 중간 테이블이 필요한데, 그 follows 테이블의 두 FK가 둘 다 users 를 가리키는 게 포인트예요.

follows — 두 FK 가 같은 테이블(users)을 가리킴
follows (중간 테이블)
├─ follower_id FK → users.user_id "팔로우하는 사람"
└─ following_id FK → users.user_id "팔로우당하는 사람"
 
follower_id │ following_id │ 의미
────────────┼──────────────┼──────────────────────────
1 │ 2 │ 1번 사용자가 2번을 팔로우
2 │ 1 │ 2번도 1번을 팔로우 (맞팔)
 
자기참조 N:M — 팔로우·친구 관계, 직원-매니저 트리 구조에 쓰임

패턴 ② — 좋아요 (users ↔ posts 의 N:M). 이건 사실 새 패턴이 아닙니다. shop에서 이미 본 형태예요.

N:M = 중간 테이블 — 도메인만 다르고 구조는 동일
shop : orders ↔ products → order_items (order_id, product_id, quantity)
SNS : users ↔ posts → likes (user_id, post_id)
 
likes 는 order_items 와 똑같은 패턴 — 옷만 갈아입었음
이 강의의 한 줄

모델은 새 게 아닙니다 — 같은 패턴이 다른 옷을 입은 것. 좋아요는 주문상세와, 팔로우는 중간 테이블과 같은 구조입니다.

도메인 3 — 예약 시스템: 드디어 1:1 의 실전 등장

마지막은 예약 시스템 — 호텔이나 에어비앤비 같은 서비스입니다.

users→reservations, rooms→reservations 는 익숙한 1:N. 그런데 reservations 와 payments 사이 — “한 예약은 결제 한 건, 한 결제는 예약 한 건.” 4-3에서 “드물게 쓰인다” 고 했던 1:1 관계가 드디어 실전에 나왔습니다.

그런데 한 건씩 짝을 이룬다면, 그냥 예약 테이블에 결제 컬럼을 넣으면 안 될까요?

✕ 결제 컬럼을 reservations 에 박으면

민감 정보가 매번 딸려 나옵니다

카드번호·영수증ID 같은 민감 정보가 예약을 조회할 때마다 같이 노출됩니다. 게다가 결제 전 예약은 결제 컬럼이 전부 NULL — 자주 보지도 않는 정보가 테이블만 무겁게 만들어요.

✓ payments 를 1:1 로 분리하면

보안 격리 + 시점 분리

민감 정보는 별도 테이블에 격리해 접근 권한을 따로 관리하고, 결제 행은 예약이 확정된 시점에만 생성합니다. 예약 테이블은 가볍게 유지되고, 결제가 필요할 때만 JOIN하면 됩니다.

1:1 의 실무 의미

보안 · 격리 · 시점 분리. “하나에 하나” 라고 무조건 쪼개는 게 아니라 — 분리할 이유가 있을 때만 1:1 로 뺍니다. 이유가 없으면 그냥 한 테이블이 맞아요.

세 도메인 비교 — 같은 패턴이 다른 옷

자, 세 도메인을 한눈에 놓고 비교해 봅시다. 이 표가 오늘 강의의 결론입니다.

패턴쇼핑몰SNS예약
부모-자식members→ordersusers→postsusers→reservations
1:N모든 직접 관계모든 직접 관계users→reservations · rooms→reservations
N:M (중간 테이블)order_itemslikes · follows(없음)
자기참조 N:M(없음)follows ⭐(없음)
1:1(없음)(없음)payments ⭐
공통점부모-자식이 출발점동일동일

쇼핑몰·SNS·예약 — 비즈니스는 전혀 다른데, 모든 도메인에서 부모-자식 패턴이 데이터 모델의 출발점입니다. 1:N, N:M, 1:1, 자기참조… 전부 부모-자식의 변형일 뿐이에요.

4-2 에서 약속드린 메시지의 실증

“부모-자식만 알면, AI 가 모든 도메인의 SQL 을 만들어준다.” — 4-2에서 드린 약속이 빈말이 아니었다는 걸, 세 도메인이 직접 보여줬습니다.

처음 보는 도메인을 만나도 됩니다

회사에 가면 — 우리 강의에서 안 다룬 도메인의 ERD를 받게 될 거예요. 의료, 금융, 물류, 게임, 콘텐츠 플랫폼… 걱정하지 마세요. 분석 순서는 항상 같습니다.

단계할 일강의에서 배운 도구
1마스터(부모) 테이블부터 찾기4-5 ERD 읽기 5단계
2부모-자식 관계 식별4-2 부모/자식 테이블
3관계 종류 판단 (1:N / N:M / 1:1)4-3 식별 질문
4빈틈·잘못된 설계 진단4-6 두 직관
도메인 지식 ≠ 모델링 지식

도메인이 바뀌어도 부모-자식 사고법은 그대로입니다. 병원의 환자→진료, 은행의 고객→계좌→거래, 게임의 유저→캐릭터→아이템 — 전부 오늘 본 패턴의 변형이에요.

자주 헷갈리는 지점

① FK 두 개가 같은 테이블을 가리켜도 되나요?

follows 의 follower_id 와 following_id 가 둘 다 users 를 가리키는 게 어색하게 느껴질 수 있어요. 역할이 다른 두 개의 관계일 뿐입니다.

FIX ▸됩니다. FK는 어느 테이블의 PK를 참조하느냐만 중요 — 같은 테이블을 두 번 참조해도 전혀 문제없습니다 (자기참조).
② 1:1 이면 그냥 한 테이블로 합치면 안 되나요?

1:1 을 배우고 나면 모든 걸 쪼개고 싶어지는데, 1:1 은 어디까지나 예외적인 패턴입니다.

FIX ▸합쳐도 동작은 합니다. 분리할 이유(보안·격리·시점)가 있을 때만 1:1 로 빼는 거예요 — 이유가 없으면 한 테이블이 정답.
③ likes 같은 중간 테이블에는 PK 가 없나요?

같은 사용자가 같은 글에 좋아요를 두 번 누르는 걸 막는 역할도 복합 PK가 합니다.

FIX ▸두 FK 를 묶은 복합 PK 를 씁니다 — shop 의 order_items 도 (order_id, product_id) 복합 PK였죠.
영상 멈추고 — 직접 한 장 분석해보세요

AI에게 “우리 회사 ERD 분석해줘” 라고 시키는 날이 반드시 옵니다. 그때 여러분이 직접 분석해본 경험이 있어야 AI의 답을 검증할 수 있어요. 본인 회사나 관심 있는 도메인의 ERD 한 장을 골라, 위의 4단계로 직접 분석해보세요.

세 도메인을 하나의 사고법으로 읽어냈다면 — 이제 모델링의 마지막 단계만 남았습니다. 다음 강의는 비즈니스 요구사항을 받아 직접 ERD를 그리는 종합 실습입니다.

NEXT LESSON4-7 연습 문제

SNS·예약 ERD에서 직접 패턴을 찾아내며 오늘 배운 비교 분석을 손에 익힙니다.

GO ▸ 연습 문제 풀기
4-6 연습 문제4-7 연습 문제