079. NULL 무결성과 NOT NULL 제약조건

핵심 인사이트 (3줄 요약)

본질: 데이터베이스에서 NULL은 0이나 공백(Space)이 아니라 **"아직 값이 할당되지 않았음(Unknown)" 또는 "해당 사항 없음(Inapplicable)"**을 뜻하는 관계형 데이터베이스 특유의 미지의 논리 상태다.

가치: NOT NULL 제약조건은 데이터 모델링 단계에서 비즈니스 로직상 '절대 비어 있어서는 안 되는 필수 데이터(예: 주민등록번호, 계좌잔액)'가 누락된 채 테이블에 삽입되는 쓰레기 데이터를 원천 차단하는 가장 1차적인 방패다.

판단 포인트: NULL은 사칙연산과 비교 연산의 결과를 모두 미궁(NULL)으로 빠뜨리며 인덱스(Index) 스캔을 방해하므로, 아키텍트들은 성능과 무결성을 위해 최대한 NOT NULL과 기본값(Default)을 조합하여 NULL의 발생을 억제해야 한다.

Ⅰ. 개요 및 필요성

NULL 무결성(Null Integrity)은 관계형 데이터베이스(RDB)가 현실 세계의 불확실성을 수용하기 위해 만든 양날의 검이다.

회원가입 테이블을 만들 때 '이름'은 무조건 알아야 하지만, '결혼기념일'은 아직 미혼이거나 입력하기 싫을 수 있다. 이 빈칸에 숫자 0을 넣거나 띄어쓰기(공백)를 넣으면 데이터의 의미가 완전히 왜곡된다. 에드거 코드(E.F. Codd) 박사는 이처럼 "값이 존재하지 않음"을 수학적으로 표현하기 위해, 값이 아예 존재하지 않는 특수한 블랙홀 마커인 NULL을 고안했다.

하지만 개발자가 아무데나 빈칸을 허용하면 쓰레기 데이터(Garbage Data)가 쌓이고 시스템이 붕괴된다. 은행 계좌에 잔액 데이터가 비어버리는 참사를 막기 위해, 스키마 레벨에서 "이 열(Column)은 빈칸을 절대 용납하지 않겠다"라고 쇳덩어리 규칙을 거는 것이 바로 NOT NULL 제약조건의 핵심이다.

📢 섹션 요약 비유: NULL은 시험 답안지의 '빈칸(무응답)'이다. 숫자 0이라고 쓴 것은 틀린 답(오답)이지만, 빈칸(NULL)은 이 학생이 몰라서 안 쓴 건지 펜이 고장 나서 못 쓴 건지 알 수 없는 '미지의 상태'를 뜻한다. NOT NULL 제약은 감독관이 "이름 칸은 무조건 채워야만 시험지를 받아주겠다"고 선언하는 규칙이다.

Ⅱ. 아키텍처 및 핵심 원리

삼치 논리 (3-Valued Logic)의 붕괴 구조

NULL이 무서운 이유는 이진법(True/False)으로 돌아가는 컴퓨터의 뇌 구조를 **삼치 논리(True, False, Unknown)**로 박살 내버리기 때문이다.

┌────────────────────────────────────────────────────────┐
│           NULL이 유발하는 블랙홀 연산 논리 (3-Valued Logic)  │
├────────────────────────────────────────────────────────┤
│   [ 산술 연산의 붕괴 ]                                   │
│   100 + NULL = NULL   (미지의 값에 100을 더해도 미지수!) │
│   NULL / 10  = NULL                                    │
│                                                        │
│   [ 논리/비교 연산의 붕괴 ]                              │
│   NULL = NULL ──▶ False (또는 Unknown). 서로 같다고 할 수 없음! │
│   NULL != 100 ──▶ Unknown (다르다고 확신할 수도 없음!)     │
│                                                        │
│ * 핵심 판별법: SQL에서 NULL을 찾으려면 절대 `WHERE col = NULL`을 │
│   쓰면 안 된다. 무조건 특수 문법인 `IS NULL`을 써야만 데이터베이스 │
│   엔진이 미지의 상태를 인식하고 검색해 준다.                    │
└────────────────────────────────────────────────────────┘

NOT NULL 제약조건은 데이터가 INSERT 되거나 UPDATE 되는 순간, DB 엔진의 무결성 검증기가 작동하여 입력값이 없으면 트랜잭션 자체를 롤백(Rollback)시켜버려 이 끔찍한 블랙홀 연산이 생기는 원인을 원천 봉쇄한다.

📢 섹션 요약 비유: NULL과의 연산은 '블랙박스에 100원 넣기'와 같다. 블랙박스 안에 돈이 얼마 있는지 모르는 상태(NULL)에서 100원을 넣어도, 총액은 여전히 "모른다(NULL)"이다. 블랙박스끼리 비교(NULL = NULL)해도 내용물이 같은지 절대 확신할 수 없다.

Ⅲ. 비교 및 연결

무결성 제약조건 (Integrity Constraints)의 방어 계층

NOT NULL은 데이터베이스가 스스로를 지키는 5대 무결성 중 가장 기초적이고 파괴적인 1차 방어선이다.

방어선 (제약 조건)	방어 목적	쇳덩어리(DB) 검증 로직	비즈니스 예시
개체 무결성 (Primary Key)	식별성 보장	중복 불가(`UNIQUE`) + 절대 빈칸 불가(`NOT NULL`)	사번, 주민번호
NULL 무결성 (`NOT NULL`)	필수 데이터 누락 방지	INSERT/UPDATE 시 해당 컬럼의 값 존재 여부 검사	패스워드, 결제금액
도메인 무결성 (`CHECK`)	업무 규칙 값의 범위 방어	입력값이 조건(예: 나이 > 0)에 맞는지 산술 검사	나이, 성별(M/F)
참조 무결성 (`Foreign Key`)	테이블 간의 고아 데이터 방어	자식이 부모의 기본키에 존재하는 값만 참조하는지 검증	주문 테이블의 부서 코드

기본키(Primary Key)는 본질적으로 식별자 역할을 해야 하므로, UNIQUE 제약과 NOT NULL 제약이 하드웨어적으로 완전히 융합된 형태다. 이름 없는 사람을 구별할 수 없듯, 식별자가 NULL이라는 것은 데이터베이스 아키텍처에서 절대 용납되지 않는 시스템의 붕괴다.

📢 섹션 요약 비유: NOT NULL 제약이 놀이공원 입구의 '키 120cm 이상(필수 조건) 입장 제한'이라면, Primary Key는 한발 더 나아가 입장하는 모든 사람의 '얼굴(식별성)이 똑같은 사람이 없어야 한다'는 이중 검문소다.

Ⅳ. 실무 적용 및 기술사 판단

실무 시나리오

성능 튜닝과 인덱스(Index) 스캔 융합: 오라클(Oracle) 같은 B-Tree 인덱스 아키텍처는 데이터가 NULL인 레코드를 아예 인덱스 트리에 저장하지 않는다. 만약 어떤 컬럼에 NULL이 잔뜩 들어있는데 WHERE col IS NULL로 검색하면, 인덱스를 타지 못하고 테이블 전체를 뒤지는 풀 스캔(Full Table Scan)이 터져 DB 서버가 뻗어버린다. 아키텍트는 NOT NULL과 함께 DEFAULT 'N' 같은 기본값을 깔아두어 인덱스 검색 경로를 사수해야 한다.
COALESCE / NVL 함수를 통한 아키텍처 회피: 통계나 집계(SUM, AVG)를 낼 때 데이터에 NULL이 섞여 있으면, 전체 결과가 엉뚱하게 왜곡(NULL은 AVG의 분모에서 아예 제외됨)된다. SQL을 짤 때 치명적인 산술 오류를 막기 위해 COALESCE(col, 0)이나 NVL(col, 0) 함수를 씌워 NULL을 안전한 숫자 0으로 실시간 치환하여 계산하는 것이 쿼리 작성의 불문율이다.

안티패턴

개발의 편의를 위해 테이블의 모든 컬럼을 널 허용(Nullable)으로 설계하는 만행: ERD를 짤 때 "나중에 무슨 데이터가 비어있을지 모르니까 일단 다 뚫어놓자"라며 NOT NULL을 안 거는 초보 설계. 나중에 프론트엔드나 백엔드 로직에 구멍이 나서 '상품 가격'이나 '고객 비밀번호'에 조용히 빈칸(NULL)이 INSERT 되기 시작하면, 나중에 장애가 터졌을 때 범인을 찾을 수도 없고 복구할 수도 없는 거대한 쓰레기통(Garbage Data) 데이터베이스가 완성된다. 필수 값은 무조건 데이터베이스 스키마 레벨에서 목숨을 걸고 차단벽(NOT NULL)을 세워야 한다.
📢 섹션 요약 비유: 테이블을 모두 널 허용(Nullable)으로 만드는 것은, 은행 금고를 만들면서 "직원들이 열쇠 꺼내기 귀찮으니까 문을 아예 닫지 말자"고 하는 짓이다. 결국 누군가 빈 봉투(쓰레기 데이터)를 슬쩍 넣어두어도 금고(DB)는 조용히 그걸 삼키고 오염되어 버린다.

Ⅴ. 기대효과 및 결론

NULL은 관계형 데이터베이스가 유연성을 확보하기 위해 도입한 천재적인 마커지만, 다루기 까다로운 맹독과 같다. 그리고 NOT NULL 제약조건은 이 맹독이 데이터베이스 시스템의 심장부로 번지는 것을 막아주는 가장 저렴하고 완벽한 해독제다.

애플리케이션(Java, Python) 코드에서 if문으로 빈칸을 아무리 열심히 막더라도 버그는 발생한다. 최후의 보루인 데이터베이스 스키마 레벨에 NOT NULL 제약을 쇳덩어리처럼 박아두면, 어떤 해커나 버그투성이 코드도 필수 데이터의 누락을 강제할 수 없다. 결론적으로 NOT NULL 제약의 적절한 설계는 데이터 품질(Data Quality)을 담보하는 아키텍트의 가장 강력한 통제 권한이다.

📢 섹션 요약 비유: NULL은 약국에서 파는 '강력한 항생제'다. 필요할 때 적절히 쓰면 유연성을 주지만, 막 쓰면 시스템의 면역(연산과 인덱스)을 박살 낸다. NOT NULL 제약은 이 항생제를 오남용하지 못하게 막는 의사의 '엄격한 처방전'이다.

📌 관련 개념 맵

개념	연결 포인트
3치 논리 (3-Valued Logic)	True / False / Unknown(NULL)로 구성된 DB 연산의 규칙. `NULL AND FALSE = FALSE`지만 `NULL OR TRUE = TRUE`가 되는 기괴한 논리망
개체 무결성 (Entity Integrity)	테이블의 모든 레코드는 고유하게 식별 가능해야 하며, 기본키(PK)는 절대로 `NULL`을 가질 수 없다는 관계형 DB의 헌법 제1조
NVL / COALESCE 함수	쿼리 실행 중 마주친 `NULL`을 0이나 '미정' 같은 구체적인 값으로 임시 치환하여 블랙홀 연산을 회피하는 DB 마법사들의 주문

📈 관련 키워드 및 발전 흐름도

관계형 모델의 유연성 요구 (값이 없는 상태의 표현 필요성)
    │
    ▼
NULL 마커(Marker) 도입 (공백이나 0과는 완전히 다른 '미지의 상태' 정의)
    │
    ▼
NULL로 인한 삼치 논리(3-Valued Logic) 연산 붕괴 및 인덱스 누락 부작용 발생
    │
    ▼
무결성 제어의 도입 ──▶ NOT NULL 제약조건을 통한 스키마 레벨 방어 체계 확립
    │
    ▼
현대 DB 모델링의 룰 (최소한의 NULL 허용, DEFAULT 값 우선 전략 융합)

이 흐름도는 "유연성을 위한 빈칸 허용 → 시스템 붕괴의 부작용 직면 → 스키마 레벨의 물리적 강제 방어벽(제약조건) 설치"로 이어지는 데이터 품질 통제 아키텍처의 발전사를 보여준다.

👶 어린이를 위한 3줄 비유 설명

데이터베이스에서 NULL은 0점이나 빈칸이 아니라, 시험지를 아예 내지 않아서 점수를 알 수 없는 '물음표(?)' 상태예요.
이 물음표(?) 상태인 친구랑 점수를 더하거나 비교하려고 하면 컴퓨터가 바보가 되어버려요.
그래서 데이터베이스 선생님은 NOT NULL이라는 몽둥이를 들고, "이름이나 나이 같은 중요한 칸에 물음표(?)를 내면 절대 안 받아준다!"라고 철벽을 치는 거랍니다!