Unique 제약 조건은 데이터 무결성을 지킬 수 있게 도와준다.
나는 이전까지는 @Column(unique = true)를 필드들에 직접 주어 설정해 왔었는데 최근 새로운 unique 적용 방법을 알게되었다.

이번 글에서는 이 두 가지 방법을 비교하고, 실무에서는 어떤 방식이 더 나은지 그 이유까지 정리해볼게요.

✅ 두 가지 방법 예시

① @Table(uniqueConstraints)

@Entity
@Table(
    name = "member",
    uniqueConstraints = {
        @UniqueConstraint(columnNames = {"email"}),
        @UniqueConstraint(columnNames = {"username"}),
        @UniqueConstraint(columnNames = {"provider", "provider_id"})  // 소셜 로그인용 복합 UNIQUE 예시
    }
)
public class Member {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String email;

    private String username;
}

→ 테이블 레벨에서 Unique 적용
→ DDL 생성 시 ALTER TABLE 수준에서 UNIQUE KEY 생성

② @Column(unique = true)

@Entity
public class Member {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(unique = true)
    private String email;

    @Column(unique = true)
    private String username;
}

→ 컬럼 단위에서 Unique 적용
→ DDL 생성 시 해당 컬럼 뒤에 UNIQUE 옵션 추가

✅ 차이점 비교

비교 항목 (차이점을 중심으로 )	@Table(uniqueConstraints)	@Column(unique = true)
적용 위치	테이블 레벨	컬럼 레벨
복합 UNIQUE 지원 여부	가능 (columnNames = {"col1", "col2"})	불가능 (단일 컬럼만)
DDL 생성 결과 형식	별도 ALTER TABLE or CONSTRAINT 생성	컬럼 정의 뒤에 UNIQUE 추가
DDL 관리 툴과의 호환성	더 명확하게 관리됨	컬럼 제약으로 나오므로 덜 명확할 수 있음
JPA 표준 준수 여부	JPA 표준 어노테이션	Hibernate 구현체 특화 성격 강함 (@Column(unique=true)는 JPA 표준이 아님 → Hibernate 확장 기능임)
실무 사용 권장 여부	👍 많이 사용	⚠️ 잘 쓰지 않음 (테스트/간단한 경우만)

✅ 왜 실무에서는 @Table(uniqueConstraints) 가 더 좋은가?

1️⃣ 복합 UNIQUE 지원 가능

대부분 서비스는 복합 unique가 필요한 경우가 많음 (ex: (user_id, email) 같이)

@Table(uniqueConstraints) 는 복합키까지 자연스럽게 지원

@Column(unique=true) 는 단일 필드만 가능 → 확장성 낮음

2️⃣ JPA 표준성과 이식성

@Table(uniqueConstraints) 는 JPA 표준 → 모든 JPA 구현체에서 지원

반면 @Column(unique = true) 는 Hibernate에서만 확장적으로 사용 가능
→ 다른 구현체로 갈 경우 깨질 수 있음

3️⃣ DDL 관리 측면

@Table(uniqueConstraints) 는 DDL이 명확하게 constraint 레벨로 생성됨

ALTER TABLE ADD CONSTRAINT UNIQUE (email)

@Column(unique=true) 는 컬럼 정의에 UNIQUE 붙이는 정도라
→ DDL 툴/DBA가 관리할 때 가독성이 떨어짐

4️⃣ 실무 경험적 이유

많은 팀에서 @Column(unique = true) 를 썼다가
→ 복합 unique 필요하거나 → DDL 툴과 충돌하면서 → 전부 @Table(uniqueConstraints)로 변경한 케이스 많음

---

✅ 결론

상황	추천 방식	이유
복합 Unique 필요한 경우	@Table(uniqueConstraints)	유일한 선택지
단일 Unique라도 실무 적용	@Table(uniqueConstraints)	표준적, 명확, 이식성 우수
간단한 테스트/프로토타입	@Column(unique=true)	빠른 테스트용 (운영 권장 X)

되도록 운영 코드에서는 @Table(uniqueConstraints) 사용이 더 안전하고 실무적으로 표준적이다.
@Column(unique=true) 는 빠른 테스트 용도로서만 사용하자.