4-7 연습 문제 — 실무 ERD 분석,
세 도메인의 패턴을 직접 읽어낸다
이번 강의에서 배운 것 — 쇼핑몰 / SNS / 예약 세 도메인 비교, 자기참조 N:M, 그리고 1:1 의 실무 의미. 눈으로 따라 읽은 ERD 는 금방 흐려지지만, 부모-자식 쌍을 직접 세어보고 분리 이유를 직접 설명해본 ERD 는 머리에 남습니다. 마지막 도전 문제에서는 본인 도메인의 ERD를 한 장 그려봅니다.
이번 연습의 위치
완료 ✓
완료 ✓
강의 완료 ✓
지금 여기
섹션 4 마무리 ⭐
2-4에서 만든 AI 과외 선생님 세션을 그대로 쓰세요. 막히면 정답이 아니라 힌트만 요청하고 — 풀어본 뒤에는 본인의 답을 던지며 “이 분석이 맞나 검증해줘” 라고 물어보세요. 직접 분석하고 → 검증받는 이 순서가 ERD 읽는 눈을 만듭니다.
문제 1. SNS ERD — 부모-자식 모두 식별
4-7 강의 의 SNS ERD 를 보고 — 모든 부모-자식 쌍 을 나열하세요. follows 의 두 FK 는 별도 쌍으로 세야 합니다.
정답 보기
총 7 쌍 (SNS 는 패턴이 풍부해서 많음):
| # | 부모 | 자식 | FK |
|---|---|---|---|
| 1 | users | posts | posts.user_id |
| 2 | posts | comments | comments.post_id |
| 3 | users | comments | comments.user_id |
| 4 | users | likes | likes.user_id |
| 5 | posts | likes | likes.post_id |
| 6 | users | follows (follower) | follows.follower_id ⭐ |
| 7 | users | follows (following) | follows.following_id ⭐ |
핵심:
comments는 두 부모 (posts,users) — “어느 게시글의 어느 사용자가 단 댓글”likes는 N:M 중간 테이블 (users↔posts)follows는 자기참조 N:M — 둘 다users를 가리키지만 역할 이 다름 (follower vs following)
문제 2. 예약 시스템의 1:1 — 왜 분리됐나
4-7 의 예약 ERD 에서 reservations 와 payments 는 1:1 관계입니다. 이 두 정보를 한 테이블에 합치면 어떤 문제가 생기나요? 그리고 분리했을 때 어떤 이점이 있나요?
정답 보기
reservations (잘못 - 1:1 강제 통합)
reservation_id | user_id | room_id | check_in | check_out | card_no | paid_at | receipt_no민감 정보와 예약 정보가 한 몸
① 보안 — card_no 같은 민감 정보가 예약 조회 시 매번 같이 노출. “오늘 예약자 목록” 조회 시 카드번호가 SQL 결과에 포함될 위험.
② 상태 불일치 — 예약은 했지만 결제 전 상태 (pending) 일 때 카드번호 등이 NULL 로 잠시 있음. “결제가 안 됐는지, 안 된 채로 NULL 인지” 구분 어려움.
③ 자주 안 보는 정보가 같이 — 결제 정보는 환불·정산 때만 보는데, 매번 예약 조회 SELECT 에 끼어옴.
④ 확장성 — 다중 결제 (할부, 분할 결제) 미래 요건이 들어오면 — 한 테이블로는 표현 불가능.
보안·상태·확장이 전부 깔끔
① 보안 격리 — payments 테이블 권한 별도 관리 (예약 직원은 카드번호 안 보임, 정산 직원만 봄).
② 명확한 상태 — payments 행 존재 여부 자체가 “결제 됐다 / 안 됐다” 의 표시.
③ 조회 효율 — 예약만 보려면 가벼운 reservations 만 JOIN.
④ 확장성 — 1:1 을 나중에 1:N 으로 바꾸기 쉬움 (분할 결제 등).
“1:1 같은데 분리됐다면 — 보안·격리·확장성 이유” 라고 추측하면 거의 맞습니다.
문제 3 (도전). 본인 회사 / 관심 도메인 ERD 그려보기
당신이 다니는 회사 / 관심 있는 도메인의 ERD 를 직접 한 장 그려보세요. 그 후 AI 에게 검증을 요청.
예: 학원, 음식점 주문, 의료 진료기록, 게임 캐릭터…
어떤 “것들” 이 있나? (회원·상품·이벤트…)
누가 부모이고 누가 자식인지 — FK 가 어디에 들어가는지 표시.
N:M 이 있는지 / 중간 테이블이 필요한지 식별.
완성한 ERD 를 mermaid 코드로 옮겨서 검증을 요청합니다.
AI 프롬프트 예시:
다음 도메인의 ERD 를 검토해줘:
[도메인]
[당신의 도메인 설명 1-2 문장]
[ERD]
[mermaid 코드 또는 텍스트 형태로 테이블/관계 명시]
[검증 요청]
1. 빠진 엔티티가 있나?
2. 부모-자식 관계가 정확한가?
3. N:M 인데 1:N 으로 잘못 잡은 곳이 있나?
4. 정규화 위반 (직관 1, 2) 이 있나?본인 도메인에 모델링 사고법을 적용해보는 게 목적. AI 의 검증 결과를 참고하되, 본인 판단으로 “우리 회사 비즈니스엔 이게 맞다” 라고 반박할 수도 있어야 합니다.
모범 예시 — 카페 주문 도메인
분석:
- 부모-자식 5 쌍
- N:M: orders ↔ menu_items (
order_items중간) - staff 는 “이 주문을 응대한 직원” — orders 의 또 다른 부모. 한 직원이 여러 주문 응대 (1:N)
추가 고민 거리:
- 옵션 (사이즈, 시럽 등) 을 텍스트로 저장? 별도
order_options테이블? - 재고 관리 필요한가?
inventory테이블?
본인 답안을 AI 에 던졌을 때 — 이런 분석이 나오는지 확인.
세 도메인의 패턴을 읽고 본인 도메인까지 그려봤다면 — 이제 요구사항 한 줄에서 ERD 한 장까지, 모델링의 전 과정을 직접 돌려볼 차례입니다.