[DB] 자연키와 인조키 중 어떤걸 기본키로 둬야 할까?

1. 개요

김영한 강사님의 강의를 들으며 웹 개발을 공부하기 시작한 이후, 기본 키 전략을 설정할 때 항상 인조키를 사용해왔다.

특별히 이유를 고민해보지 않고 습관적으로 인조키를 선택해왔는데, 최근 코드 리뷰 중에 "이미 고유한 값이 존재하는데, 왜 굳이 별도의 컬럼을 추가해 인조키를 사용했느냐"는 질문을 받게 되었다.

 

한 번도 깊이 생각해본 적 없는 부분이었기에, 이번 기회에 자연키와 인조키의 장단점을 비교해보고, 어떤 키를 선택하는 것이 더 좋은지 정리해보려 한다.

 

 

 

 

 

 

 

 

 

 

2. 자연키? 인조키?

자연키란 비즈니스 모델에서 자연스럽게 나오는 속성이다.

회원 데이터를 예로 들면, 회원 ID는 고유한 값이며 변경될 가능성의 거의 없다. 또한 주민등록번호도 고유한 값으로 자연키의 한 예가 될 수 있다. 

 

인조키는 비즈니스 모델과 달리 오로지 unique함을 보장하기 위해서 인조적으로 만든 속성이다. 

예를 들면 UUID, Auto Increment가 이에 해당한다. 

 

 

 

 

 

 

 

 

 

 

 

3. 자연키를 사용했을 때 문제점

자연키를 기본키(PK)로 두었을 경우 발생하는 문제점들은 다음과 같다.

 

 

 

1. 변경 가능성을 배제할 수 없다.

과거에는 주민등록번호를 기본 키로 두는 기업이 많았다. 주민등록번호는 모든 사람들에게 반드시 부여되며(NOT NULL), 유일하고(UNIQUE), 절대 변하지 않기 때문에 적합해 보였다. 

 

하지만, 정부 정책이 변경되면서 주민등록번호를 법적으로 저장할 수 없게 되었다. 이로 인해 많은 주민등록번호를 PK로 사용하던 많은 기업들이 데이터베이스의 구성을 변경해야만 했다. 

 

이러한 변경은 기본 키를 변경하는 단순히 번거로운 작업이 될 뿐만 아니라, 데이터베이스 성능에도 악영향을 미치게 된다. MySQL과 같이 기본 키가 레코드의 물리적 저장 위치를 결정하는 데이터베이스에선 그 영향이 더욱 크다. 

 

MySQL에서는 PK가 레코드의 물리적인 저장 위치를 결정하기 때문에, 인덱스는 PK에 의존한다. 그래야 인덱스를 타고 들어와서 PK를 통해 저장된 위치에서 레코드를 읽어올 수 있기 때문이다. 

 

 

 

PK가 변경된다는 것은 레코드의 물리적인 저장 위치가 바뀌어야 함을 의미하며, 이는 인덱스까지 재구성하도록 영향을 준다. 이는 엄청난 디스크 작업을 필요로 한다. 

 

 

비즈니스 영역에서 절대적으로 변하지 않는 것은 없다

 

 

 

2. 성능 문제로 이어진다.

PK를 대체키로 사용하게 되면 일반적으로 자동 증가 숫자를 사용하게 되므로 성능을 향상시킬 수 있다. 반대로 자연키를 PK로 사용하는 경우 일반적으로 문자열로 사용되며, 심지어 복합키로 구성되는 경우가 많은데, 이는 PK를 비대하게 만들어 성능에 좋지 못하다.

 

비즈니스와 관련히는 PK 값은 자동 증가하는 전략을 갖는 인조키를 PK로 두었을 때 보다 훨씬 큰 값을 갖는 경우가 많다. 주민등록번호와 같은 문자열은 단순 숫자보다 훨씬 데이터가 크며, 심지어 복합키로 구성될 경우 PK의 크기는 훨씬 비대해진다. 

 

일반적으로 PK의 크기는 작을수록 좋으며, 원시타입 일수록 좋다. 

 

아래 내용은 RealMySQL에서 5개의 인덱스를 갖는 테이블의 기본 키(Primary Key) 크기에 따른 인덱스 크기 비교를 보여준다.

레코드 한 건당 약 50바이트의 차이는 미미해 보이지만, 레코드 건수가 100만 건이 되면 인덱스 크기는 190MB나 증가하게 된다.

만약 레코드 건수가 1000만 건이 되면 그 차이는 무려 1.9GB까지 증가한다. 인덱스의 크기가 커질수록 동일한 성능을 유지하기 위해 더 많은 메모리가 필요하게 된다. 따라서 기본 키의 크기는 데이터베이스 성능에 직접적인 영향을 미치기 때문에 신중하게 선택해야 한다.

 

 

 

 

 

 

3. 복잡한 테이블 구조와 개발 난이도 상승

자연키를 PK로 사용하게 되면 1개의 컬럼만으로 PK를 구성하지 못하고 복합키를 사용해야 하는 경우가 빈번하게 발생한다. 

만약 복합키를 갖는 테이블과 연관관계를 맺어야 한다면 복합키를 전부 외래키로 갖고 있어야 하고 이는 테이블 구조와 관련 코드를 복잡하게 만든다. 

 

복합키를 PK로 갖는 테이블과 관계를 맺는 테이블이라면 해당 복합키를 다른 테이블도 가져야 한다. 예를 들어 (생년월일, 이름, 성별)을 PK로 갖는 사용자 테이블이 있다고 하자. 그러면 해당 키가 사용자를 식별할 수 있는 키이므로 무결성을 위해 사용자 주문 내역 테이블에도 (생년월일, 이름, 성별) 컬럼을 동일하게 가져야하는 것이다.

 

 

 

 

JPA에서 복합키를 사용하기 위해선 @Embeddable, @EmbeddedId를 사용하거나, @IdClass를 사용해야 한다. 

 

 

아래 예시 코드는 @Embeddable, @EmbeddedId 를 사용하여 복합키를 사용하는 모습이다. 

@Embeddable
public class CompositeKey implements Serializable {

    private String keyPart1;
    private Long keyPart2;

    // equals()와 hashCode() 반드시 구현
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        CompositeKey that = (CompositeKey) o;
        return Objects.equals(keyPart1, that.keyPart1) &&
               Objects.equals(keyPart2, that.keyPart2);
    }

    @Override
    public int hashCode() {
        return Objects.hash(keyPart1, keyPart2);
    }

 

 

@Entity
public class MyEntity {

    @EmbeddedId
    private CompositeKey id;

    private String someValue;
    }
}

 

 

 

만약 MyEntity와 연관관계를 맺는 엔티티가 있다면 아래와 같은 방식으로 외래키를 설정해줘야 한다. 

import jakarta.persistence.*;

@Entity
public class ChildEntity {

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

    @ManyToOne
    @JoinColumns({
        @JoinColumn(name = "parent_key_part1", referencedColumnName = "keyPart1"),
        @JoinColumn(name = "parent_key_part2", referencedColumnName = "keyPart2")
    })
    private MyEntity parent; // 부모 테이블의 복합키 참조

    private String childValue;

    public ChildEntity(MyEntity parent, String childValue) {
        this.parent = parent;
        this.childValue = childValue;
    }
}

 

 

 

 

 

4. 무결성 보장의 위험

대체키를 사용한다는 것은 키의 생성 및 관리를 완전히 데이터베이스에 위임한다는 것이다. 반면에 자연키를 사용한다는 것은 유효성 검사와 데이터의 무결성 등을 개발자가 직접 관리한다는 것인데, 아무래도 사람이 직접 관리하는 것 보다는 시스템을 통해 이를 위임하는 것이 안정적이다.

 

인조키를 사용할 경우, 일관된 방식으로 키를 생성 및 관리하여 데이터의 무결성을 보장할 수 있다.  

 

 

 

 

 

 

 

 

 

 

 

 

 

4. 결론

JPA는 일관성있게 항상 인조 키를 사용하는 것을 권장한다. 그 외에도 PK가 주민번호와 같은 개인 정보라면 유출 위험 등의 부수적인 문제가 있어서 가급적이면 인조 키를 사용하는 것이 요즘의 추세이다.

 

지금까지는 인조키를 당연하게 사용해왔지만, 알고 쓰는 것과 모르고 쓰는 것은 천지차이이다. 

 

왜? 에 대한 질문을 던지며, 더 깊이 고민하고 생각하며 개발해 나가야겠다.