@PrePersist와 @PreUpdate를 통한 효율적인 데이터 무결성 관리

서론

데이터 무결성은 데이터베이스의 핵심 요소 중 하나이며, 이를 위해 초기 설계 단계에서 다양한 제약 조건을 설정한다. 그러나 현실에서는 설계 후 운영 단계로 넘어가면서 새로운 서비스나 기능이 추가될 때 예상치 못한 문제들이 발생한다. 예를 들어, 데이터베이스 속성에 설정된 not null 조건을 해제하여 null 값을 허용하게 되거나 외래키 제약 조건을 해제하면서, 원래의 데이터 무결성을 유지하기 어려워지는 경우가 자주 발생한다.

이러한 상황은 특히 기능이 유사하지만 대상이 다른 새로운 연관 관계가 형성되거나, 상태값의 업데이트에 따라 변경 시간이 저장되어야 하는 경우와 같이, 단순히 데이터베이스 레벨의 제약 조건 추가만으로는 해결하기 어려운 문제들이다. 이를 해결하기 위해 데이터베이스 트리거를 활용하는 방식을 생각해볼 순 있지만 트리거 사용은 데이터베이스에 대한 종속성을 증가시킬 뿐만 아니라, 유지보수 및 확장성 측면에서도 여러 문제점을 야기할 수 있다.

이러한 문제를 해결하는 데 있어서 JPA의 @PrePersist 와 @PreUpdate 어노테이션은 매우 효과적인 대안이었다. 이전에는 서비스 레이어에서 복잡한 조건문들을 통한 유효성 검사를 진행했으나, 이 두 어노테이션의 도입으로 이러한 과정이 크게 간소화되었다. 이 글에서는 데이터베이스 레이어에서 처리하기 어려운 제약 조건들을 @PrePersist 와 @PreUpdate 를 활용하여 애플리케이션 레이어에서 효과적으로 관리하는 방법을 살펴보고자 한다.

@PrePersist

@PrePersist 어노테이션은 엔티티가 데이터베이스에 저장되기 바로 전에 호출된다. 이를 사용하여 엔티티가 영속화되기 전에 필요한 초기화나 유효성 검사를 수행할 수 있다.

예시 코드:

@Entity
public class Account {

    @Id
    @GeneratedValue
    private Long id;

    private String username;

    private String status; // 예: "ACTIVE", "SUSPENDED"

    @PrePersist
    public void validateStatus() {
        if (!Arrays.asList("ACTIVE", "SUSPENDED").contains(status)) {
            throw new IllegalArgumentException("Invalid status");
        }
    }
}

엔티티 생성시, 특정 조건을 충족하는지 검증하는 로직을 구현할 때 @PrePersist 가 사용될 수 있다. 위 예는 사용자 계정이 특정 조건을 만족하는지 검증하는 경우이다.

@PreUpdate

@PreUpdate 어노테이션은 엔티티의 상태가 변경되어 데이터베이스에 업데이트되기 전에 호출된다. 이를 통해 업데이트 전 유효성 검사나 상태 업데이트 등의 작업을 할 수 있다.

예시 코드:

@Entity
public class Order {

    @Id
    @GeneratedValue
    private Long id;

    private String status; // 예: "NEW", "SHIPPED", "DELIVERED"

    private LocalDateTime shippedAt;

    private LocalDateTime deliveredAt;

    @PreUpdate
    public void updateOrderStatus() {
        if ("SHIPPED".equals(status) && shippedAt == null) {
            this.shippedAt = LocalDateTime.now();
        } else if ("DELIVERED".equals(status) && deliveredAt == null) {
            this.deliveredAt = LocalDateTime.now();
        }
    }
}

위 예시처럼, 엔티티의 상태가 복잡하게 변화할 때, @PreUpdate 를 사용하여 필요한 로직을 실행할 수 있다. 아래 예시는 주문 상태에 따라 자동으로 관련 필드를 업데이트하는 경우이다.

다른 예시1 – 로그 기록

엔티티의 생성이나 업데이트 시점에 로그를 남기는 용도로 사용할 수 있다. 이는 시스템의 모니터링이나 디버깅에 도움이 될 수 있다.

javaCopy code
@Entity
@EntityListeners(AuditingEntityListener.class)
public class Product {

    @Id
    @GeneratedValue
    private Long id;

    private String name;

    @PrePersist
    public void logCreation() {
        // 생성 로그 기록
        System.out.println("Product created: " + name);
    }

    @PreUpdate
    public void logUpdate() {
        // 수정 로그 기록
        System.out.println("Product updated: " + name);
    }
}

다른예시2 – 외래키 제약조건

외래키 제약조건의 not null 조건이 해제되어 있더라도, 엔티티의 생성이나 업데이트 시점에 어플리케이션 레벨에서 논리적인 제약 조건을 설정하고 유지할 수 있다.

@PreUpdate
    private void validate() {
        if (user == null && group == null) {
            throw new IllegalStateException("User 또는 Group 중 하나는 반드시 존재해야 합니다.");
        }
    }

위 예시는 user 와 group 중 하나는 반드시 null이 아니어야 한다는 비즈니스 규칙을 강제할 수 있다. 이를 통해 데이터베이스에 저장되는 데이터의 무결성을 보장하며 데이터베이스 레벨에서의 제약 조건 대신, 애플리케이션 레벨에서 논리적 검증을 수행한다. 또한 엔티티가 저장되거나 업데이트되는 시점에 자동으로 검증 로직이 실행되어 수동으로 검증 로직을 호출할 필요가 없게 하며, 일관된 상태 유지에 도움을 준다.

영속성 컨텍스트 내에서 @PrePersist와 @PreUpdate의 작동 방식

• 엔티티가 생성(New)되고 persist() 메소드에 의해 영속성 컨텍스트에 저장될 때, @PrePersist 콜백이 호출된다.
• 엔티티가 Managed 상태가 되면, JPA는 엔티티의 변경을 추적한다.
• 엔티티에 변경이 발생하면, 해당 트랜잭션이 커밋되는 시점에 @PreUpdate 콜백이 호출되고, 변경된 내용이 데이터베이스에 반영된다.
• 엔티티가 detach() 메소드에 의해 Detached 상태가 되거나, remove() 메소드에 의해 Removed 상태가 되면, 영속성 컨텍스트에서 분리된다.

@PrePersist와 @PreUpdate 사용 시 유의해야 할 점

@PrePersist와 @PreUpdate 는 엔티티의 저장과 변경시 매번 실행되는 콜백 메소드 이므로 매우 복잡한 로직을 수행하거나, 다른 엔티티에 대한 쿼리를 실행하거나, 외부 시스템과의 통신 등을 수행하는 경우에는 성능 저하가 발생할 수 있다.

1. 적절한 유효성 검사를 수행해야 한다.
   • 이들 어노테이션은 데이터가 데이터베이스에 저장되거나 업데이트되기 전에 실행된다. 따라서, 엔티티의 상태가 올바른지 확인하는 간단하면서도 효과적인 유효성 검사를 수행하는 것이 중요하다. 불필요하거나 과도한 검사는 피해야 한다.
2. 로직의 복잡성을 관리해야 한다.
   • 복잡한 로직이나 처리는 @PrePersist 와 @PreUpdate 내에서 피해야 한다. 이들 메소드는 가능한 한 가볍고 빠르게 수행되어야 한다. 복잡한 로직은 서비스 레이어나 도메인 서비스로 옮기는 것이 좋다.
3. 외부 시스템과의 상호작용은 피해야 한다.
   • 데이터베이스 저장이나 업데이트 과정에서 외부 시스템과의 통신은 피해야 한다. 이는 처리 시간을 증가시키고, 예측 불가능한 지연이나 오류를 발생시킬 수 있다.
4. 엔티티의 상태 변화에 주의해야 한다.
   • @PrePersist 와 @PreUpdate 내에서 엔티티의 상태를 변경할 때는 주의가 필요하다. 이러한 변경은 다른 부작용을 일으킬 수 있으므로, 엔티티의 상태 변화는 명확하고 예측 가능해야 한다.
5. 성능에 미치는 영향을 고려해야 한다.
   • 이 어노테이션들이 포함된 메소드가 자주 호출되므로, 성능에 미치는 영향을 항상 고려해야 한다. 특히 대량의 데이터 처리 시에는 이러한 콜백 메소드들의 성능이 중요하다.

이러한 점들을 유의하며 @PrePersist 와 @PreUpdate 를 사용한다면, 애플리케이션의 데이터 처리 과정을 보다 효율적이고 안정적으로 관리할 수 있을 것이다.

정리

지금까지 데이터베이스 레이어에서 처리하기 어려운 제약 조건을 Java Persistence API(JPA)의 @PrePersist와 @PreUpdate 어노테이션을 사용하는 방식을 통해 애플리케이션 레이어에서 효과적으로 관리하는 방법에 대해 살펴보았다.

@PrePersist와 @PreUpdate 어노테이션은 데이터베이스에 의존하지 않고 복잡한 유효성 검사나 초기화, 상태 변경 등의 작업을 수행할 수 있도록 주기에 이를 활용하면, 데이터베이스의 제약 조건에서 벗어나 애플리케이션 레이어에서 데이터 무결성을 보장할 수 있어 애플리케이션의 신뢰성을 높일 수 있다.

또한, 데이터베이스에 종속적인 코드 대신 이 두 어노테이션을 사용하면, 코드의 유연성과 재사용성이 높아져 유지보수성이 향상 되며 애플리케이션의 변경과 확장에도 용이하다.

하지만, 이러한 어노테이션의 사용은 적절한 상황에서 잘 활용되어야 한다. 필요 이상으로 사용하면 오히려 코드의 복잡성을 증가시킬 수 있기 때문이다. 따라서, 유효성 검사나 초기화, 상태 변경 등의 작업을 어디서 수행할 것인지, 어떤 방식으로 할 것인지에 대한 철저한 고민과 설계가 필요하다.