SQL CREATE TABLE의 DEFAULT와 NOT NULL: 새 행의 기본값을 안전하게 설계하는 법

테이블에 DEFAULT 'NEW'를 넣었는데 NULL이 저장되거나 오류가 난다면 기본값이 모든 빈칸을 고쳐 주는 기능이라고 생각했을 가능성이 크다. DEFAULT는 값을 생략했을 때의 규칙이고, NOT NULL은 NULL 자체를 허용할지의 규칙이다.

DEFAULT는 INSERT에서 열을 생략했을 때 적용된다

다음은 NUMBER와 VARCHAR2를 쓰는 Oracle 문법 예시다. 테이블의 상태 열에 기본값을 둔다. 다른 데이터베이스에서는 열 타입 이름을 해당 제품에 맞게 바꿔 실행한다.

CREATE TABLE orders (
  id       NUMBER PRIMARY KEY,
  customer VARCHAR2(100) NOT NULL,
  status   VARCHAR2(20) DEFAULT 'NEW' NOT NULL
);

INSERT INTO orders (id, customer)
VALUES (1, '고객A');

SELECT id, status FROM orders WHERE id = 1;

INSERT는 status 열을 지정하지 않았으므로 조회 결과는 1, NEW여야 한다. 기본값은 새 행의 초기 상태를 한곳에서 정할 때 유용하다. 다만 이미 들어 있는 행을 자동으로 바꾸거나, 애플리케이션이 명시적으로 보낸 값을 덮어쓰지는 않는다.

NULL을 명시하면 기본값과 다른 결과가 나온다

다음 INSERT는 status에 NULL을 직접 전달한다.

INSERT INTO orders (id, customer, status)
VALUES (2, '고객B', NULL);

status에 NOT NULL 제약이 있으므로 이 문장은 실패해야 한다. 이것은 좋은 실패다. 주문 상태가 없는 행을 조용히 저장하는 대신 입력 오류를 데이터베이스 경계에서 막아 준다.

테스트에서는 성공과 실패를 각각 확인한다. 열을 생략한 첫 INSERT 뒤에는 status='NEW'인지 조회한다. 두 번째 INSERT는 제약 오류가 나는지 확인하고, id=2 행이 남지 않았는지 조회한다. 실패 메시지만 보고 넘어가면 도구의 자동 재시도나 예외 처리 때문에 기대와 다른 데이터가 저장됐는지 놓칠 수 있다.

NOT NULL이 없다면 데이터베이스 제품과 문법 설정에 따라 명시한 NULL이 그대로 저장될 수 있다. 따라서 '기본값을 원한다'는 의도와 'NULL을 허용하지 않는다'는 의도는 각각 선언하는 편이 명확하다.

기본값은 업무 규칙의 전부가 아니다

NEW, PAID, CANCELED처럼 상태 값이 늘어나는 경우 DEFAULT만으로는 허용 가능한 전이를 막지 못한다. 애플리케이션 서비스에서 상태 변경 규칙을 검증하고, 필요하면 CHECK 제약이나 별도 상태 테이블을 고려한다. 기본값은 시작점을 정할 뿐, 주문이 어떤 순서로 변할 수 있는지까지 설명하지 않는다.

날짜·시간 기본값도 주의가 필요하다. 생성 시각에는 데이터베이스의 현재 시각을 쓰기 편하지만, 어느 시간대 기준인지와 갱신 시각을 누가 바꾸는지는 별도 결정이 필요하다. 서버와 데이터베이스의 시간대가 다르면 로그를 비교하기 어려워진다.

스키마 변경은 기존 데이터도 확인한다

운영 테이블에 NOT NULL 열을 추가할 때 기존 행에 값이 없으면 바로 제약을 걸 수 없다. 먼저 기존 행을 어떤 값으로 채울지, 그 값이 실제로 맞는지 검토해야 한다. 단순히 임의 기본값을 넣으면 과거 데이터의 의미를 바꿀 수 있다.

마이그레이션은 빈 데이터베이스에서만 실행하지 말고, 기존 행·NULL 입력·열 생략 입력을 포함한 테스트 데이터로 확인하자.

핵심 요약

DEFAULT는 열을 생략한 INSERT의 초기값이고, NOT NULL은 NULL 저장을 막는 제약이다. NULL을 직접 넣는 것과 열을 생략하는 것은 다르다. 기본값을 업무 규칙 전체로 보지 말고, 스키마 변경 전에는 기존 데이터의 의미와 마이그레이션 순서를 먼저 확인하자.