B-5: 트랜잭션·NULL·관계와 조인의 다리

안녕하세요, 홍순구 튜터입니다. 지난 시간엔 한 표에 몰려 있던 정보를 정규화로 차근차근 나눠, 종이 위 인스타그램 설계도를 거의 완성했어요. 회원·게시물·좋아요를 따로 떼어 깔끔하게 정리했죠. 오늘은 그 설계도에 마지막 마감칠을 합니다. 표를 안전하게 다루는 약속(트랜잭션), 칸이 비었을 때의 의미(NULL), 그리고 정규화로 흩어 놓은 표들을 다시 잇는 다리(조인)까지요.

세 주제가 따로 노는 것 같지만, 사실 한 줄기예요. 정규화로 데이터를 잘게 나눴기 때문에, 그걸 안전하게 바꾸려면 트랜잭션이 필요하고, 비어 있는 칸을 제대로 보려면 NULL을 알아야 하고, 흩어진 표를 다시 모으려면 조인이 필요하거든요. 오늘로 모델링(B 카테고리)을 마무리하고, 다음 시간부터는 종이 설계를 진짜 SQL로 구현하기 시작해요.

 오늘의 여정
   ① 트랜잭션      여러 작업을 하나로 → 전부 되거나, 전부 안 되거나
   ② ACID 4총사    원자성 · 일관성 · 고립성 · 지속성
   ③ NULL          '빈칸'의 정체 — 0도 빈 글자도 아니다
   ④ NULL 의 함정   알 수 없음(3치 논리) 과 IS NULL
   ⑤ 본질식별자     식별자 4조건 다시 보기 — 존재성과 NULL
   ⑥ 조인의 다리    흩어진 표를 키로 다시 잇기 → 첫 JOIN 미리보기

💡 오늘 수업의 핵심 — "정규화로 나눈 표를, 안전하게(트랜잭션) 다루고 정확하게(NULL) 읽고 다시 잇는다(조인)"

🎯 학습 목표

• 트랜잭션이 무엇인지, 그리고 트랜잭션이 지켜야 할 ACID 네 가지 성질을 인스타 시나리오로 이해한다. (SQLD 1과목 단골)
• NULL이 '빈칸'이 아니라 '알 수 없음'이라는 걸 알고, 비교·연산에서 생기는 함정을 피한다.
• 정규화로 흩어진 표가 외래키와 조인으로 어떻게 다시 이어지는지, 첫 SELECT 한 줄로 직접 확인한다.

Step 1: "여러 작업을 하나로 묶기 — 트랜잭션이란"

질문 하나로 시작할게요. 인스타에서 게시물을 하나 삭제하면 무슨 일이 일어날까요? 화면에선 게시물 하나가 사라지는 것뿐이지만, 속을 들여다보면 그 게시물에 달렸던 댓글도, 좋아요도 함께 사라져야 해요. 정규화로 회원·게시물·댓글·좋아요를 따로 떼어 놨으니까요. 즉 '게시물 삭제'는 사실 표 여러 개를 건드리는 여러 작업이에요.

여기서 문제가 생겨요. 게시물은 지웠는데 댓글 삭제가 중간에 실패하면? 주인 없는 댓글이 둥둥 떠다녀요. 데이터가 앞뒤가 안 맞는 상태가 되죠. 그래서 이 여러 작업을 떼어낼 수 없는 하나의 단위로 다뤄야 해요. 이렇게 묶은 작업 단위를 트랜잭션(transaction, 거래·처리)이라고 불러요.

 게시물 하나 삭제 = 사실은 표 여러 개를 건드리는 여러 작업

   ┌─ 게시물 삭제
   ├─ 그 게시물의 댓글 삭제
   └─ 그 게시물의 좋아요 삭제

   이 셋을 한 트랜잭션으로 → 전부 되거나, 전부 안 되거나

가장 유명한 비유는 계좌이체예요. A가 B에게 1만 원을 보내면, (1) A 잔액에서 1만 원을 빼고 (2) B 잔액에 1만 원을 더해요. 두 작업이 다 돼야 정상이죠. 만약 (1)만 되고 (2)가 실패하면? 돈이 허공으로 사라져요. 그래서 둘을 한 트랜잭션으로 묶고, "둘 다 성공하면 확정, 하나라도 실패하면 전부 취소"로 다뤄요.

이 '확정'을 COMMIT(커밋), '취소·되돌리기'를 ROLLBACK(롤백)이라고 해요. 지금은 이름만 기억해 두세요. 실제로 어떻게 쓰는지는 SQL을 본격적으로 다루는 다음 카테고리에서 배워요.

💡 한 줄 정리

트랜잭션은 떼어낼 수 없는 하나의 논리적 작업 단위로, 묶인 작업이 전부 확정(COMMIT)되거나 전부 취소(ROLLBACK)된다.

Step 2: "ACID ① — 원자성과 일관성"

트랜잭션이 제 역할을 하려면 네 가지 성질을 지켜야 해요. 네 성질의 영어 머리글자를 따서 ACID(애시드)라고 불러요. 한 번에 넷을 다 보면 헷갈리니, 오늘은 둘씩 나눠 볼게요. 먼저 원자성과 일관성.

원자성(Atomicity)은 '더 쪼갤 수 없다'는 뜻이에요. 트랜잭션 안의 작업은 전부 반영되거나, 전부 안 되거나 둘 중 하나예요. 중간만 살짝 반영되는 일은 없어요. 계좌이체에서 (1)만 되고 끝나는 사고를 막아 주는 게 바로 원자성이에요. 흔히 'All or Nothing'(전부 아니면 전무)이라고 표현해요.

 원자성: 중간은 없다 — 전부(All) 또는 전무(Nothing)

   성공 경로:  (1) OK → (2) OK   → COMMIT   → 둘 다 반영
   실패 경로:  (1) OK → (2) 실패 → ROLLBACK → (1)도 취소

   ✗ 막아야 할 것:  (1)만 반영되고 (2)는 안 됨 (돈 증발)

일관성(Consistency)은 트랜잭션 전후로 데이터베이스가 정해 둔 규칙을 늘 만족한다는 뜻이에요. 여기서 규칙이란 우리가 설계에서 걸어 둔 제약이에요. 예를 들어 "게시물의 작성자는 반드시 회원 표에 있는 회원이어야 한다"는 외래키 규칙이 있다면, 트랜잭션이 끝난 뒤에도 이 규칙이 깨져선 안 돼요. 트랜잭션은 데이터를 올바른 상태에서 또 다른 올바른 상태로만 옮겨 놓아야 해요. ★빈출 — ACID 각 글자의 뜻을 짝짓는 문제는 SQLD에 꾸준히 나와요.

💡 한 줄 정리

원자성은 트랜잭션의 작업이 전부 반영되거나 전부 취소되는 성질(All or Nothing)이고, 일관성은 트랜잭션 전후로 데이터가 정해진 규칙을 늘 만족하는 성질이다.

Step 3: "ACID ② — 고립성과 지속성"

이어서 나머지 둘, 고립성과 지속성을 볼게요.

고립성(Isolation, 격리성)은 여러 트랜잭션이 동시에 돌아도 서로 간섭하지 않는다는 뜻이에요. 각자 혼자 데이터베이스를 쓰는 것처럼 보이게 해 주죠. 인스타로 치면, 두 사람이 같은 게시물에 거의 동시에 좋아요를 눌러도 좋아요 수가 꼬이지 않아야 해요. 한쪽 트랜잭션이 끝나기 전의 어중간한 중간 결과를 다른 쪽이 보고 잘못 계산하면 안 되니까요.

지속성(Durability)은 한번 COMMIT된 트랜잭션은 영구히 보존된다는 뜻이에요. 시스템이 갑자기 꺼지거나 고장 나도, 커밋이 끝난 데이터는 사라지지 않아요. 안전한 저장 공간에 확실히 기록된 뒤에 "확정됐다"고 알려 주거든요. COMMIT을 경계로 '이제부터 영구'가 보장되는 것, 이게 지속성의 핵심이에요.

⚠️ 함정 — 고립성을 완벽하게 지킬수록 여러 트랜잭션이 서로 기다려야 해서 동시 처리 속도는 떨어져요. 그래서 실제 데이터베이스는 '어디까지 격리할지'를 몇 단계로 조절할 수 있게 해 둬요(격리 수준). 자세한 단계는 이 과목 범위를 넘으니, 지금은 "고립성과 성능은 맞바꾸는 관계"라는 점만 기억하세요.

💡 한 줄 정리

고립성은 동시에 실행되는 트랜잭션끼리 서로 간섭하지 못하게 하는 성질이고, 지속성은 한번 COMMIT된 결과가 시스템 장애에도 영구히 남는 성질이다.

Step 4: "빈칸의 정체 — NULL이란 무엇인가"

이제 트랜잭션을 떠나 다른 주제로 가요. 우리 회원 표를 다시 떠올려 볼게요. B-1에서 자기소개(bio)는 안 써도 된다고 했고(선택 속성), B-2에서 그 칸은 비어 있어도 되는 도메인이라고 했죠. 실제로 우리 데이터에는 자기소개를 안 쓴 회원이 있어요. 박승우·최도연·한나래의 bio가 비어 있죠. 이 '비어 있음'을 NULL(널)이라고 불러요.

NULL은 '값이 아직 없음' 또는 '알 수 없음'이에요. 여기서 꼭 짚어야 할 게 있어요. NULL은 0도 아니고, 빈 문자열('')도 아니에요. 0은 '숫자 영(零)'이라는 값이 분명히 있는 거고, 빈 문자열은 '길이가 0인 글자'라는 값이 있는 거예요. NULL은 아예 값 자체가 없는 상태고요.

 같은 '비어 보임'이라도 속은 다르다

   bio = '백엔드 공부 중'   → 값이 있음
   bio = NULL              → 값이 아예 없음 (모름 / 안 씀)
   bio = ''                → '길이 0인 글자' 라는 값은 있음

   NULL ≠ 0,   NULL ≠ ''

설문지로 비유하면 딱 맞아요. '나이' 칸에 0이라고 쓰면 '0살'이라는 답을 한 거예요. 그 칸을 그냥 비워 두면 '답을 안 함'(모름)이고요. 둘은 완전히 다른 상태죠. 데이터베이스의 NULL은 이 '답 안 함'에 해당해요.

⚠️ 함정 — NULL을 0이나 빈 문자열과 같다고 착각하는 건 SQLD 단골 함정이에요. "값이 없다(NULL)"와 "값이 0이다", "값이 빈 글자다"는 셋 다 다른 상태라는 걸 분명히 해 두세요.

💡 한 줄 정리

NULL은 '값이 없음 / 알 수 없음'을 뜻하며, 숫자 0이나 빈 문자열('')과는 다른 상태다.

Step 5: "NULL의 함정 — 알 수 없음(3치 논리)"

NULL이 '알 수 없음'이라는 점이 재미있는 결과를 낳아요. NULL이 끼면 그 결과도 '알 수 없음'이 되거든요.

먼저 연산부터 볼게요. NULL + 100은 얼마일까요? '모르는 값'에 100을 더해도 여전히 모르죠. 그래서 답은 NULL이에요. 더하기든 곱하기든, 연산에 NULL이 한 번 끼면 결과는 NULL로 번져요.

다음은 비교예요. 보통 비교의 결과는 참(TRUE) 아니면 거짓(FALSE), 둘 중 하나죠. 그런데 NULL이 끼면 '알 수 없음(UNKNOWN)'이라는 세 번째 결과가 생겨요. 이렇게 결과가 셋이 되는 걸 3치 논리(three-valued logic)라고 해요.

 보통의 비교는 둘:     참(TRUE) / 거짓(FALSE)
 NULL 이 끼면 셋:      참 / 거짓 / 알 수 없음(UNKNOWN)

   나이 = NULL    → 알 수 없음 → 아무 행도 안 걸림  (함정)
   나이 IS NULL   → NULL 인 행을 정확히 가려냄      (올바른 방법)

   NULL + 100 = NULL    (연산에 NULL 이 끼면 결과도 NULL)

그래서 "자기소개가 비어 있는 회원"을 찾으려고 bio = NULL이라고 쓰면 안 돼요. 등호 비교의 결과가 '알 수 없음'이 되어 한 명도 안 걸리거든요. NULL인지 확인할 때는 등호(=)가 아니라 IS NULL이라는 전용 표현을 써요. ★빈출 — 자세한 사용법은 다음 시간(C-1)에 배우지만, "NULL 비교는 =이 아니라 IS NULL"이라는 한 가지는 지금 새겨 두세요.

이게 설계에도 영향을 줘요. 어떤 칸을 비워도 되게 둘지, 반드시 채우게 막을지를 정해야 하거든요. 반드시 채워야 하는 칸에는 NOT NULL(널 불가) 제약을 걸어요. 다음 Step에서 이 NOT NULL이 식별자와 어떻게 연결되는지 볼게요.

💡 한 줄 정리

NULL이 끼면 연산 결과도 NULL이 되고 비교 결과는 '알 수 없음'이 되므로, NULL 여부는 =이 아니라 IS NULL로 확인해야 한다.

Step 6: "본질식별자 다시 보기 — 존재성과 NOT NULL"

NULL을 배웠으니, B-3에서 다룬 식별자 이야기를 한 번 더 정리하면 딱 맞아떨어져요. 주식별자가 갖춰야 할 네 가지 조건, 기억하시죠?

 주식별자가 갖춰야 할 네 가지 (B-3)

   유일성   다른 행과 겹치지 않는다
   최소성   꼭 필요한 칸만으로 식별한다
   불변성   값이 잘 바뀌지 않는다
   존재성   항상 값이 있다 — NULL 불가 = NOT NULL

방금 NULL을 배운 지금, 네 번째 존재성이 또렷해져요. 존재성이란 주식별자에는 반드시 값이 있어야 한다는 조건이에요. 누구인지 가리키는 키가 비어 있으면(NULL이면) 그 행을 식별할 수가 없으니까요. 그래서 주식별자는 늘 NOT NULL이어야 해요. Step 5에서 본 NOT NULL 제약이 바로 이 존재성을 지키는 장치예요.

이제 본질식별자와 인조식별자를 다시 봐요. 본질식별자는 업무에서 자연히 나오는 속성으로 식별하는 거예요(예: 이메일, username). 인조식별자는 식별만을 위해 새로 만든 번호예요(member_id). B-3에서 우리는 인조식별자(member_id)를 주식별자로 골랐죠. 왜였을까요?

본질식별자는 위험 요소가 있어요. 이메일은 사람이 바꿀 수 있고(불변성 위협), 가입 방식에 따라 비어 있을 수도 있어요(존재성 위협). NULL을 배운 지금 보면, 본질식별자가 NULL이 될 수 있다는 점이 인조식별자를 택하는 또 하나의 분명한 이유예요. 안 바뀌고 항상 값이 있는 번호를 주식별자로 삼는 게 안전하니까요.

💡 한 줄 정리

주식별자의 존재성 조건은 'NULL 불가(NOT NULL)'와 같은 말이며, 본질식별자가 NULL·변경의 위험을 가질 수 있어 안전한 인조식별자를 주식별자로 쓴다.

Step 7: "흩어진 표를 키로 다시 잇기 — 관계가 조인으로"

이제 오늘의 마지막 다리예요. 지난 시간 정규화로 한 표에 몰려 있던 정보를 회원·게시물 같은 여러 표로 쪼갰어요. 깔끔해졌지만 숙제가 하나 생겼죠. "이 게시물을 누가 썼나"를 알려면, 게시물 표에 있는 작성자 칸을 들고 회원 표로 찾아가야 해요.

여기서 그 작성자 칸이 외래키(Foreign Key, FK)예요. 외래키는 다른 표의 주식별자를 가리키는 칸이에요. 게시물 표의 작성자 칸은 회원 표의 member_id(주식별자)를 가리키죠.

 회원 표 (참조되는 쪽)
   member_id (PK) · username · nickname · bio

 게시물 표 (참조하는 쪽)
   post_id (PK) · member_id (FK) · caption

   게시물 표의 member_id(FK) ──→ 회원 표의 member_id(PK) 를 가리킴
   두 키를 맞대어 이으면 = 조인(JOIN)

여기서 이름을 하나 정리할게요. 지난 시간 설계도에선 게시물의 작성자를 writer_id라고 불러, 좋아요를 누른 사람(member_id)과 구분했어요. 그런데 실제 우리 데이터의 게시물 표에서는 작성자 칸 이름이 member_id예요. A-1에서 처음 만났던 바로 그 칸이죠. 이름이 writer_id든 member_id든, '이 게시물을 쓴 회원을 가리키는 외래키'라는 역할은 똑같아요. (좋아요 표는 다음 카테고리에서 만들 거라, 지금 실제로 이어 볼 수 있는 건 회원·게시물 두 표예요.)

흩어진 두 표를 다시 모으려면 어떻게 할까요? 게시물 표의 member_id와 회원 표의 member_id를 맞대어, 같은 회원끼리 줄을 이어 주면 돼요. 이렇게 키를 맞대어 여러 표를 다시 잇는 것이 조인(JOIN)이에요. 두 명단을 학번으로 맞춰보는 일과 똑같아요. 한쪽 명단의 학번을 다른 명단에서 찾아 같은 줄에 붙이는 거죠.

💡 한 줄 정리

외래키는 다른 표의 주식별자를 가리키는 칸이며, 이 키를 맞대어 흩어진 표들을 다시 잇는 것이 조인(JOIN)이다.

Step 8: "첫 조인 SELECT 미리보기 — 게시물과 작성자 잇기"

말로만 하면 감이 안 오니, 실제로 한 번 이어 볼게요. 회원 표와 게시물 표를 member_id로 맞대어, 각 게시물 옆에 그 작성자의 닉네임을 붙여 보는 거예요.

SELECT m.nickname, p.caption
FROM   post p
JOIN   member m ON p.member_id = m.member_id;

읽는 법은 이래요. 게시물 표(p)와 회원 표(m)를, 게시물의 member_id와 회원의 member_id가 같은 것끼리(ON 뒤의 조건) 이어 붙여라. 그러면 각 게시물 줄에 그 작성자의 닉네임이 딱 따라붙어요.

 회원 표 ⨝ 게시물 표  (member_id 로 맞댐)

   김재훈  ← post 1, 2, 3
   이민지  ← post 4, 5, 6
   박승우  ← post 7, 8
   정하루  ← post 9, 10
   최도연  ← post 11
   강지수  ← post 12
   ----------------------------
   합계 12 행  (게시물 12개 = 결과 12행)

실제로 실행하면 정확히 12행이 돌아와요. 게시물이 12개니 각 게시물마다 한 줄씩, 작성자 닉네임이 붙어서요. 그런데 여기서 눈여겨볼 게 있어요. 회원은 8명인데, 결과에 작성자로 등장하는 건 6명뿐이에요. 게시물이 0개인 윤태양(7번)·한나래(8번)는 어디로 갔을까요?

이 조인은 양쪽에 짝이 있는 줄만 이어 줘요. 이런 조인을 안쪽 조인(INNER)이라고 해요. 게시물이 하나도 없는 회원은 게시물 표에 짝이 없으니, 이을 상대가 없어 결과에서 빠진 거예요. "게시물이 없는 회원도 빠뜨리지 말고 보여 줘"라고 하려면 다른 종류의 조인이 필요한데, 그건 다음에 본격적으로 다뤄요.

⚠️ 함정 — INNER 조인은 양쪽에 짝이 있는 줄만 남겨요. 짝이 없는 줄(게시물 0개 회원)은 조용히 사라지죠. "분명 회원이 8명인데 왜 6명만 나오지?" 하는 함정이 여기서 나와요. C-5에서 짝 없는 쪽도 살리는 OUTER 조인을 배우면 이 함정이 풀려요.

💡 한 줄 정리

두 표를 키로 맞대는 INNER 조인은 양쪽에 짝이 있는 행만 남기므로, 게시물이 0개인 회원은 결과에서 빠진다(짝 없는 쪽까지 보려면 OUTER 조인이 필요).

마무리

오늘로 B 카테고리, 데이터 모델링을 마무리했어요. 종이 위 인스타그램 설계도가 이제 정말 완성됐죠. 다섯 박스를 잇고, 각 행을 키로 가리키고, 속성을 정규화로 잘 나눠 담고, 마지막으로 그 표들을 안전하게 다루고(트랜잭션) 정확하게 읽고(NULL) 다시 잇는(조인) 법까지 봤으니까요. 오늘 세 주제는 따로인 것 같아도, 결국 "잘게 나눈 표를 어떻게 안전하고 정확하게 다루느냐"라는 한 줄기였어요.

오늘 배운 핵심 세 가지

• 💡 하나 — 트랜잭션은 떼어낼 수 없는 하나의 작업 단위이고, ACID(원자성·일관성·고립성·지속성) 네 성질로 안전을 보장한다. 원자성은 전부 또는 전무, 일관성은 규칙 유지, 고립성은 동시 실행 격리, 지속성은 커밋 후 영구 보존이다.
• 💡 둘 — NULL은 '값이 없음 / 알 수 없음'이며 0이나 빈 문자열과 다르다. NULL이 끼면 연산은 NULL, 비교는 '알 수 없음'이 되므로 NULL 여부는 =이 아니라 IS NULL로 확인한다.
• 💡 셋 — 외래키는 다른 표의 주식별자를 가리키는 칸이고, 이 키를 맞대어 흩어진 표를 다시 잇는 것이 조인이다. INNER 조인은 양쪽에 짝이 있는 행만 남긴다.

다음 시간 예고

이제 종이 설계가 끝났으니, 다음 시간부터는 이 설계도를 진짜 SQL로 옮겨요. C 카테고리의 첫걸음은 CREATE TABLE로 회원·게시물 표를 실제로 만들고, SELECT로 조회하고, WHERE로 원하는 행만 골라내는 거예요. 오늘 배운 NULL도 그때 IS NULL로 직접 다뤄 보고, 조인의 짝 없는 쪽을 살리는 OUTER 조인은 조인을 전문으로 파는 모듈(C-5)에서 본격적으로 만나요. 종이에 그린 설계도가 화면에서 살아 움직이는 걸 보게 될 거예요.

과제

오늘 배운 트랜잭션·NULL·조인을 직접 따져 보는 과제예요. SQL 문법을 외우는 게 아니라, 개념을 시나리오에 적용해 보는 게 목적이에요.

[기초] 트랜잭션이 깨지면 무슨 일이 생길까

인스타에서 회원이 자기 게시물을 삭제하는 상황을 떠올려 보세요. 이 삭제는 (1) 게시물 표에서 게시물 삭제 (2) 댓글 표에서 그 게시물의 댓글 삭제 (3) 좋아요 표에서 그 게시물의 좋아요 삭제, 이렇게 세 작업으로 이뤄져요. (1)은 됐는데 (2)에서 오류가 나 멈췄다고 해봐요. (가) 이때 데이터가 어떤 이상한 상태가 되는지 한 줄로 적고, (나) 트랜잭션의 어떤 성질이 이 사고를 막아 주는지, 그 성질이 어떻게 작동해 데이터를 원래대로 되돌리는지 설명해 보세요.

[응용] NULL을 어떻게 다뤄야 할까

회원 표에는 자기소개(bio)가 비어 있는 회원이 있어요(NULL). (가) "자기소개를 안 쓴 회원을 찾아 줘"라는 조건을 bio = NULL로 쓰면 왜 한 명도 안 걸리는지, NULL의 성질로 설명하고 올바른 표현은 무엇인지 적어 보세요. (나) 회원 표의 username(아이디)·nickname(표시 이름)·bio(자기소개) 세 칸 중 어떤 칸을 NOT NULL로 두고 어떤 칸을 NULL 허용으로 둘지 정하고, 각각의 이유를 한 줄씩 붙여 보세요.

[심화] 조인으로 표를 다시 이어 보기

회원 표(8명)와 게시물 표(게시물 12개, 작성자가 6명)를 member_id로 잇는 INNER 조인을 한다고 해봐요. (가) 결과가 몇 행이 나올지 예상하고 그 이유를 적어 보세요. (나) 게시물이 0개인 회원 2명(7·8번)이 결과에 안 나오는 이유를, INNER 조인의 동작으로 설명해 보세요. (다) 만약 "게시물이 없는 회원도 빠뜨리지 말고 한 줄씩 보여 줘"라고 하려면 어떤 종류의 조인이 필요할지, 이름만 떠올려 적어 보세요.

생각해볼 주제

1. ACID를 완벽하게 지키면 항상 좋을까

트랜잭션의 고립성을 완벽하게 지키면 데이터는 안전하지만, 여러 트랜잭션이 서로 기다리느라 동시 처리 속도가 떨어져요. 안전과 속도가 맞바꾸는 관계인 거죠. 그렇다면 모든 서비스가 무조건 가장 강한 고립성을 골라야 할까요? 좋아요 수를 세는 일과 계좌이체처럼, 데이터가 잠깐 어긋나도 큰일이 아닌 경우와 한 푼도 틀리면 안 되는 경우를 떠올리며, 상황마다 다르게 골라야 하는 이유를 생각해 보세요.

2. 비어도 되는 칸을 다 막아 버리면 안전할까

NULL이 함정을 만드니, "그럼 모든 칸을 NOT NULL로 막아서 빈칸을 아예 없애면 안전하지 않나?"라는 생각이 들 수 있어요. 정말 그럴까요? 자기소개를 아직 안 쓴 회원, 아직 카테고리를 안 정한 게시물처럼 '아직 값이 없는 게 자연스러운' 경우를 떠올려 보세요. 모든 칸을 NOT NULL로 막으면 이런 회원·게시물은 어떻게 될지, NULL을 허용하는 것과 막는 것이 각각 무엇을 얻고 무엇을 잃는지 생각해 보세요.

3. 왜 거의 항상 인조식별자를 주식별자로 쓸까

실무에서는 회원을 식별할 때 이메일이나 아이디(본질식별자) 대신, 의미 없는 번호(member_id 같은 인조식별자)를 주식별자로 두는 경우가 압도적으로 많아요. 그냥 이메일을 주식별자로 쓰면 표 하나가 줄어 더 간단할 텐데도요. 그럼에도 번호를 새로 만들어 주식별자로 삼는 이유는 무엇일지, 식별자 4조건(특히 불변성·존재성)과 "주식별자가 바뀌면 그걸 가리키던 다른 표들은 어떻게 되나"를 함께 떠올리며 생각해 보세요.