4-4 연습 문제 — FK 라는 안전망,
없는 세계를 상상해 봐야 가치가 보인다
이번 강의에서 배운 것 — FK 는 부모-자식 안전망, 그리고 RESTRICT / CASCADE / SET NULL 의 의미. 눈으로 읽고 끝내면 머리에 남지 않습니다. 세 문제 모두 본인 답을 먼저 적어 본 다음에 정답을 열고, 풀어본 뒤에는 본인 답을 AI 에 검증 요청하세요.
섹션 4 에서의 위치
완료 ✓
강의 완료 ✓
지금 여기
설계도 읽기
정규화 · 모델링 실전
2-4에서 만든 AI 과외 선생님 세션을 그대로 쓰세요. 막히면 정답이 아니라 힌트만 요청하고, 다 푼 뒤에는 본인 답을 던지며 “내 답 검증해줘” 라고 요청하세요. FK 옵션 선택은 정답표 암기가 아니라 — “이 비즈니스에서는 뭐가 옳은가” 를 따져보는 사고 습관입니다.
문제 1. FK 없으면 어떤 사고?
쇼핑몰 DB 에 FK 가 하나도 없었다 고 가정합시다. 다음 시나리오에서 어떤 일이 일어날까요?
시나리오: 운영자가 실수로
members테이블에서 회원ID = 1 (김철수) 를 삭제했습니다. 그런데 김철수의 주문은 6 건, 그 주문상세는 10 행 남아있습니다.
1) 어떤 데이터가 유령 상태가 되나? 2) 그 유령 데이터로 어떤 사고가 날 수 있나? 3) FK 가 있었다면 무슨 일이 일어났을까?
정답 보기
1) 유령 데이터
orders의 6 행 —member_id = 1인데 회원 정보 없음order_items의 10 행 — 그 6 주문에 속한 주문상세도 유령 주문에 속한 유령 주문상세 가 됨
2) 가능한 사고
- 분석 보고서: 회원ID = 1 의 매출 X 만원, 근데 회원 정보 없음 → “누구야?” 추적 불가
- JOIN 시 missing —
members JOIN orders하면 그 6 행이 누락. 데이터 양 차이 발생 - 직원이 새 회원 가입을 회원ID = 1 으로 다시 만들면 — 김철수가 아닌 새 사람이 김철수의 과거 주문 을 가짐 (보안 사고)
3) FK 가 있었다면
DELETE FROM members WHERE member_id = 1;시점에 DB 가 거부. 사고 자체가 발생 안 함.- 운영자가 “왜 안 지워지지?” 알아보다 — “아 주문이 남아있구나, 먼저 처리해야겠다” 깨달음.
FK 한 줄이 막아준 사고 비용 = 분석 신뢰성 + 보안 + 디버깅 시간.
문제 2. shop init.sql 의 FK 분석
public/sample-data/init.sql 의 5 테이블에 — FK 가 총 몇 개 있나? 어떤 부모-자식 쌍을 보호하는지 나열하세요.
정답 보기
FK 총 4 개:
| # | 자식 테이블 | FK 컬럼 | 부모 테이블 | 부모 컬럼 |
|---|---|---|---|---|
| 1 | products | category_id | categories | category_id |
| 2 | orders | member_id | members | member_id |
| 3 | order_items | order_id | orders | order_id |
| 4 | order_items | product_id | products | product_id |
관찰:
order_items는 두 개의 FK 를 가짐 — 두 부모 (orders,products) 의 자식. 이게 4-3 의 N:M 중간 테이블 의 특징.- 모든 FK 가 기본 (
RESTRICT) — 부모 삭제 시 자식이 있으면 거부.
문제 3 (도전). CASCADE vs SET NULL — 어떤 게 맞을까
다음 시나리오 각각에서 — CASCADE / SET NULL / RESTRICT 중 무엇이 맞을까요? 이유와 함께.
| # | 시나리오 |
|---|---|
| A | 게시글 삭제 시, 그 게시글의 댓글도 같이 삭제하고 싶다 |
| B | 부서가 해산되면, 그 부서 직원들은 “부서 없음” 상태로 남아있어야 한다 |
| C | 회원을 함부로 삭제하지 못하게, 주문이 있으면 삭제 자체를 막고 싶다 |
“부모가 사라질 때 자식은 어떻게 돼야 옳은가” — 자식 입장에서 생각해 보세요.
정답 보기
| # | 정답 | 이유 |
|---|---|---|
| A | CASCADE | 게시글 없어졌는데 댓글만 남으면 유령 댓글. 게시글과 댓글은 “같이 사라져야 정상” 인 관계. |
| B | SET NULL | 부서는 없어졌지만 직원 데이터는 살려야 함. 직원의 department_id 컬럼만 NULL 로. |
| C | RESTRICT (또는 기본값) | 운영자 실수로 회원 함부로 못 지우게 막음. “먼저 주문 처리하고 다시 시도하세요” 안전망. |
구분 사고법:
- 자식이 부모의 일부 라면 → CASCADE (댓글, 주문상세, 자식 페이지)
- 자식이 독립적 존재 라면 → SET NULL (직원, 작성자, 담당자)
- 삭제 자체를 막아야 한다면 → RESTRICT (회원, 상품 마스터)
위 분류는 “비즈니스 의미” 의 문제예요. 같은 테이블 관계도 회사마다 다를 수 있음 — “우리 회사는 어떻게 해야 옳을까” 라는 판단이 모델러의 역할.
다 풀었다면 — AI 검증 루틴까지
FK 없는 세계의 사고 비용 상상하기 · shop 의 FK 4개 지도 그리기 · CASCADE / SET NULL / RESTRICT 를 비즈니스 의미로 고르기
— 세 문제를 본인 답으로 먼저 적어봤다면, FK 가 단순 문법이 아니라 안전망이라는 감각이 생긴 겁니다. 마지막 한 걸음 — 본인 답을 AI 선생님에게 검증받는 것까지 해야 진짜 끝입니다.
관계를 DB 가 지키게 만들었으니, 다음은 그 관계들이 한 장에 그려진 설계도 — ERD 를 읽는 법입니다.