💡 Enum 저장 방식, 뭐가 더 나을까?

💡 JPA Enum 저장 방식, 진짜 STRING이 답일까?

🧐 개발하다 문득 든 의문

DB에 Enum을 저장할 때, EnumType.ORDINAL과 EnumType.STRING 중 어떤 방식을 선택하는 게 최선일까?

• ORDINAL(숫자 저장) → 빠르지만 위험?
• STRING(문자열 저장) → 안전하지만 느릴까?

이걸 고민하다가 원인부터 실험, 해결책까지 정리해봤다.

---

✅ 1. JPA Enum 저장 방식

JPA에서 Enum을 DB에 저장하는 방법은 크게 두 가지다.

1️⃣ EnumType.ORDINAL (숫자로 저장)

@Enumerated(EnumType.ORDINAL)
private MemberStatus status;

📌 예제

public enum MemberStatus {
    ACTIVE,   // 0
    INACTIVE, // 1
    BANNED    // 2
}

✔️ 장점
✅ 숫자로 저장돼서 성능이 좋다
✅ 저장 공간이 적다 (INTEGER 타입)

❌ 단점
🚨 Enum 순서가 바뀌면 기존 데이터가 꼬일 위험이 있음
🚨 DB에서 직접 조회할 때 가독성이 떨어짐 (숫자만 보임)

📌 이 방식이 위험한 이유
만약 Enum 값의 순서가 변경되면, 기존 데이터가 엉뚱한 값으로 매핑될 가능성이 있음 😱

public enum MemberStatus {
    ACTIVE,   // 0
    BANNED,   // 1  <- 순서 변경!
    INACTIVE  // 2
}

• 기존에 1이었던 값이 INACTIVE → BANNED로 변함
• 실제 데이터가 바뀌지 않았는데도 서비스 로직이 꼬이는 대참사 발생 💀

🚨 "ORDINAL 방식은 절대 Enum 값이 바뀌지 않는 경우에만 사용해야 한다!"

---

2️⃣ EnumType.STRING (문자열로 저장)

@Enumerated(EnumType.STRING)
private MemberStatus status;

📌 예제

ID	Name	Status
1	Alice	ACTIVE
2	Bob	BANNED

✔️ 장점
✅ 가독성이 좋음 (DB에서 값만 봐도 의미를 이해할 수 있음)
✅ 순서 변경과 상관없이 안전함

❌ 단점
🚨 숫자보다 저장 공간을 더 차지함 (VARCHAR 타입)
🚨 대량 데이터에서 조회 성능이 다소 떨어질 수 있음

---

✅ 2. Enum 저장 방식별 성능 비교

데이터 5000개 기준으로 성능 테스트를 진행해보자.

📌 실제 조회 속도 비교

저장 방식	조회 속도 (5000개)
EnumType.ORDINAL (숫자)	0.5~1ms
EnumType.STRING (문자열)	1~2ms

• ORDINAL(숫자) 방식이 약 2배 빠름
• 문자열 조회 시 비교 연산이 추가되면서 약간 느려짐
• 소규모 데이터에서는 큰 차이 없음

📌 데이터 크기 비교

저장 방식	5000개 기준 DB 크기
EnumType.ORDINAL (숫자)	약 20KB
EnumType.STRING (문자열)	약 40~50KB

• ORDINAL(숫자): 약 20KB
• STRING(문자열): 약 2배 더 많음

💡 소규모 데이터에서는 성능 차이가 크지 않지만, 대량의 데이터에서는 ORDINAL 방식이 유리할 수 있음.

하지만 ENUM이 변경될 가능성이 있다면 STRING 방식이 유지보수 측면에서 더 안전함.

---

✅ 3. Enum 저장 방식 개선 방법

ORDINAL 방식이 위험한 이유는 순서가 바뀔 가능성 때문이다.
그렇다면 순서를 강제하는 방법이 있다면 ORDINAL을 써도 괜찮을까?

🚀 해결책: @JsonFormat + @ColumnDefinition

@JsonFormat(shape = JsonFormat.Shape.OBJECT)
public enum MemberStatus {
    ACTIVE(1, "활동 중"),
    INACTIVE(2, "비활동"),
    BANNED(3, "차단됨");

    private final int code;
    private final String description;

    MemberStatus(int code, String description) {
        this.code = code;
        this.description = description;
    }

    public int getCode() {
        return code;
    }

    public String getDescription() {
        return description;
    }
}

@Column(columnDefinition = "TINYINT")
@Enumerated(EnumType.ORDINAL)
private MemberStatus status;

• 이렇게 하면 순서가 아니라 직접 지정한 코드로 매핑됨!
• ACTIVE(1), INACTIVE(2), BANNED(3)로 고정되기 때문에 순서가 바뀌어도 안전함!
• 그리고 TINYINT를 쓰면 저장 공간도 줄일 수 있음

📌 하지만, 여전히 DB 조회 가독성이 떨어질 수 있음.
이럴 땐 Enum을 따로 테이블로 만들어서 관리하는 방법도 있다.

---

✅ 4. Enum을 별도 테이블로 관리하기

JPA에서 Enum을 테이블로 저장하면 조회 성능을 유지하면서 가독성도 확보 가능하다.

@Entity
@Table(name = "member_status")
public class MemberStatusEntity {
    @Id
    private Integer code;
    
    @Column(nullable = false, unique = true)
    private String name;
}

이렇게 하면 Enum을 변경할 때도 안정적으로 관리 가능하다.
하지만, 조인 쿼리가 추가되므로 서비스 규모에 따라 선택해야 한다.

---

✅ 5. 최종 결론: 언제 어떤 방식이 좋을까?

상황	추천 Enum 저장 방식
성능이 가장 중요함	ORDINAL (숫자 저장)
유지보수와 가독성이 중요함	STRING (문자열 저장)
순서 변경 가능성이 있음	STRING or 별도 테이블 관리
Enum 값이 많고 자주 바뀜	별도 테이블로 관리

🚀 실제 서비스라면?

• 대부분 EnumType.STRING이 유지보수하기 좋음
• ORDINAL은 절대 Enum이 변하지 않을 때만 사용
• 데이터가 많아질 경우, Enum 테이블을 만들어서 관리하는 것도 고려

---

✅ 최종 한 줄 정리

"성능이 중요한 서비스는 ORDINAL, 유지보수가 중요한 서비스는 STRING을 선택하자"