[Spring][JPA] @Embeddable와 @Embedded를 사용하는 경우, 예시 코드와 함께 쉽게 알아보자!

 

어떤 필드를 일반적인 문자열로 두는 것이 아닌
의미 있는 객체로 만들어야 하는 경우
@Embeddable과 @Embedded를 붙인다.
더 자세하게 알아보자.

 

 

 

 

1. @Embeddable과 @Embedded

• @Embeddable은 값 타입을 정의하는 곳에 표시한다.
• @Embedded는 값 타입을 사용하는 곳에 표시한다.
• 임베디드 타입은 복합 값 타입으로 불리며 새로운 값 타입을 직접 정의하여 사용하는 JPA의 방법을 의미한다.
• 아래 예시를 보면서 더 쉽게 이해해보자.
  
  
• @Embedded X

import jakarta.persistence.*;

@Entity
@Table(name = "users")
public class User {

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

    private String name;

    // 임베디드를 사용하지 않으면 이렇게 3개의 필드가 생긴다.
    private String city; 
    private String street; 
    private String zipcode;
    
}

배송지를 입력하는 상황을 생각해보자. 보통 주소는 하나의 값처럼 보이지만, 실제로는 시 + 도로명 주소 + 우편번호가 합쳐져 있다. 위의 코드가 이 값들을 전부 User 엔티티 안에 직접 넣은 것이다.

 

 

• @Embedded O

import jakarta.persistence.*;

@Entity
@Table(name = "users")
public class User {

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

    private String name;

    // 임베디드 타입이라고 어노테이션을 붙여서 하나의 필드로 관리한다.
    @Embedded
    private Address address; 
    
}

그런데 결국 city, street, zipcode는 각각 따로 존재하는 개념이 아닌, 모두 합쳐져서 하나의 주소로 표현되는 값들이다. 즉, User 입장에서는 주소와 관련되 세부 필드를 하나한 들고 있기보다, Address라는 타입을 묶어서 관리하는 편이 더 깔끔하다.

그래서 city, street, zipcode를 Address 클래스 안에 모아두고, User 엔티티에서는 그 Address를 하나의 필드처럼 사용한다.

@Embedded 
private Address address;

이렇게 하면 User 엔티티는 주소의 세부 구조까지 직접 관리하지 않아도 되고 주소와 관련된 값들은 Address라는 별도의 타입 안에서 깔끔하게 정리할 수 있다. 이처럼 엔티티 안에서 여러 값을 하나의 의미 있는 타입으로 묶어 사용하는 것을 임베디드 타입이라고 한다.

 

// 이제 임베디드 타입이 어떤 식인지 정의해줘야할 차례이다.
@Embeddable
public class Address {

    private String city;
    private String street;
    private String zipcode;

    protected Address() {}

    public Address(String city, String street, String zipcode) {
        this.city = city;
        this.street = street;
        this.zipcode = zipcode;
    }

    public String getCity() { return city; }
    public String getStreet() { return street; }
    public String getZipcode() { return zipcode; }
}

이제 주소 클래스를 정의해야한다. 아까도 말했듯이 주소는 시, 도로명, 우편번호가 들어가야한다. 이걸 User 엔티티에 넣게 되면 여러 컬럼으로 나눠져 있어야한다.

이런 경우 객체지향적이지 않으며 응집력을 떨어뜨린다. 그래서 객체에서는 User와 Address를 분리시키고 DB 테이블에는 하나의 테이블에 평평하게 모든 컬럼이 들어가길 원하는 경우 @Embeddable을 사용한다.

- 아마도 테이블에 이렇게 생성될거임 -

id (PK)	name	city	street	zipcode
1	홍길동	서울시	테헤란로	12345

꼭 여러 컬럼으로 나눠야할 경우만 사용하는 것이 아닌 검증 로직이 필요한 경우 객체로 따로 묶어서 사용할 수 있다. 예를 들어서 우편 번호가 5자리인지 포맷 검증을 하고 싶다면 이런 경우에도 임베디드 타입으로 설정해 코드를 작성하면 된다. 

 

 

 

 

---

 

 

 

 

2. 그래서 어떤 경우 사용하는가?

• 별도의 Entity로 만들기 애매한 경우
  : Entity가 되려면 자신만의 고유한 식별자(ID, PK)가 있어야하고 그것의 생명주기가 독립적이어야한다. 그런데 주소, 기간, 금액 같은 데이터들은 독립적으로 존재할 이유가 없다. 왜냐면 결국 회원이 있어야하기 때문이다. 즉, 대상이 자신만의 고유한 식별자를 가질 필요강 없고 소유한 Enity에 완전히 의존적일 때 임베디드 타입을 사용한다.
  
  
• 그러나 단순한 문자열이 아닌 의미있는 값으로 만들어야하는 경우
  : 아까도 말했듯이, 검증이 필요할 수 있다. 우편 번호가 5자리가 맞는지, 생년월일이 최근이거나 미래는 아닌지 등 일반적인 문자열이어도 그것이 어떤 의미를 갖는 경우 임베디드 타입이 필요하다. 만약 우편 번호를 일반적인 문자열로 뒀다고 가정하자. 우편번호를 사용곳마다 우편 번호를 검증하는 로직을 작성해야한다. 그런데 우편 번호의 규칙이 바뀌게 되었다면? 그렇다면 작성해둔 코드를 찾아다니며 수정해야한다. 이렇게 서비스에 두면 검증 로직이 흩어지기 쉽기 때문에 의미가 있다면 임베디드 타입으로 작성하는 것이 좋다.
  
  
• 주의) 임베디드 타입은 불변성을 지향한다.
  : @Embeddable은 단지 이 객체가 다른 엔티티의 테이블에 컬럼으로 들어간다고 매핑 설정만 해줄 뿐, 객체를 불변으로 만들지는 않는다. 다만 개발자는 임베디드 타입으로 작성한 경우 불변으로 코드를 작성해야한다. 만약 Address 객체에 Setter가 열려있다고 가정하자. 이 상태에서 회원1과 회원2가 우연히 같은 주소 객체를 공유하게 되면 회원1이 주소를 수정했을 경우, 회원2의 주소도 함께 변경되게 된다. 그래서 임베디드 타입을 작성할 때, Setter를 절대로 만들지 않아야하고 필드 변경이 필요하다면 아예 새로운 객체를 생성해서 통째로 갈아끼워야한다. 또 생성자를 통해서만 최초 값을 세팅하도록 해야한다.