[Spring] 기본값(Default)은 어디서 관리해야 할까? DB Default vs 애플리케이션 Default(@Builder.Default)

개요

기본값(default)은 어디서 책임져야 할까?
결론부터 정리하면, “기본값(default)은 가능하면 프로그램(도메인/애플리케이션)이 책임지고, DB default는 최소화하자”는 방향이 유지보수와 운영 측면에서 유리하다.

사용자 ↔ 프로그램 ↔ DB 구조에서 비즈니스 규칙과 데이터의 의미는 DB보다 프로그램이 더 잘 알고 있고, 그 규칙이 바뀌는 지점도 대부분 프로그램이기 때문이다.

---

애플리케이션 default를 지향하는 이유

엔티티 생성 시점에 기본값을 프로그램에서 세팅하면, 비즈니스 규칙(어떤 값이 기본인지, 어떤 상태가 유효한지)을 코드로 일관되게 관리할 수 있다. 코드는 버전 관리가 되고, 리뷰/테스트/배포를 통해 규칙이 “항상 최신 상태”로 유지된다.

또한 운영 중 DB에 직접 insert 하는 상황은 원칙적으로 없어야 한다. 정말 특수/긴급한 상황에만 제한적으로 일어나야 하고, 정상적인 데이터 생성 경로는 프로그램(API/서비스 로직)을 통해 통제되는 게 맞다. 이런 전제를 깔면, 기본값을 DB에 두기보다 프로그램이 책임지는 쪽이 더 자연스럽다.

---

@Builder.Default의 정확한 의미

@Builder.Default는 DB의 DEFAULT를 설정하는 기능이 아니다. “빌더로 객체를 생성할 때, 프로그램 내부에서 기본값을 채워주는 설정”이다.

즉 insert 시 어떤 값이 들어갈지는 DB가 결정하는 게 아니라 프로그램이 결정하게 된다. 물론 프로그램과 DB에 둘 다 기본값을 맞춰두면 더 안전할 수 있지만, 기본 사상은 “기본값은 프로그램이 책임진다”에 가깝다.

---

ID는 왜 DB에 맡기는가(예외)

ID는 예외적으로 DB의 auto_increment(또는 sequence/identity)를 따르는 게 일반적이다. 이유는 간단하다.

• 유일성 보장
• 동시성 상황에서의 안전한 키 생성

이 영역은 프로그램에서 기본값을 만드는 것보다 DB가 생성하는 쪽이 표준적이고 안전한 패턴이다.

---

DB default를 많이 두면 생기는 운영 비용

DB default 자체가 나쁘다기보다는, DB에 기본값/규칙이 많아질수록 운영/이관/확장 시점에 관리 포인트가 늘어난다는 게 핵심이다.

• DB가 물리적으로 확장(분리, 샤딩)되거나, 이전(마이그레이션)되거나, 복제/환경 분리(스테이징/프로덕션)가 생기면 “옮겨야 할 것”이 늘어난다.
• 테이블 데이터뿐 아니라 스키마, 제약조건, 뷰/프로시저/트리거 같은 DB 오브젝트까지 함께 관리 대상이 되고, 이를 수동 쿼리/수작업에 의존하면 실수 가능성이 커진다.
• 반대로 기본값을 프로그램에 두면, 배포만으로 규칙이 따라가고(버전 관리/리뷰/테스트 가능), 최신 상태를 일관되게 유지하기 쉬워진다.

정리하면 “DB는 저장과 무결성(제약조건) 중심”, “프로그램은 도메인 규칙과 기본값 중심”으로 역할을 나누는 게 지향점이다.

---

언제 DB default가 낫고, 언제 코드 default가 낫나

구분	DB default를 두는 게 괜찮은 경우	프로그램(애플리케이션) default가 더 나은 경우
기본 목적	데이터 무결성/안전장치(프로그램을 안 거치고 들어오는 데이터까지 최소 보정)	도메인 규칙을 코드로 일관되게 유지(테스트/리뷰/버전관리)
값의 성격	“언제나 동일”하고 DB 관점에서 의미가 고정된 값(예: created_at 기본값, soft delete 기본 false 등)	비즈니스에 따라 변할 수 있는 값(예: 초기 상태값, 정책에 따른 기본 등급/권한 등)
변경 가능성	거의 안 바뀌거나, 바뀌어도 DB 마이그레이션으로 관리 가능한 수준	자주 바뀌거나 환경/버전에 따라 달라질 수 있음(코드 배포로 맞추는 게 편함)
운영/이관 관점	DB 스키마 마이그레이션을 체계적으로 운영하고, 환경 간 스키마 동기화가 잘 됨	DB 이전/확장(복제, 분리, 이관) 시 스키마 의존도를 줄이고 싶음
데이터 유입 경로	외부 시스템/배치/직접 SQL 등 “프로그램 밖”에서 유입될 가능성이 큼	모든 쓰기 경로가 API/서비스를 통해 통제됨(직접 insert가 원칙적으로 없음)
대표 예시	DEFAULT CURRENT_TIMESTAMP, 컬럼 NOT NULL + 기본값, DB가 책임지는 ID 생성(auto_increment/sequence)	@Builder.Default, 엔티티 생성 로직에서 초기 상태 세팅, “가입 시 기본 등급=USER” 같은 정책값