Bong's Log

1. JPA 3.0 개요

JPA 3.0은 Jakarta EE 9 및 10과 함께 출시되면서, 기존 Java EE 기반에서 Jakarta EE 네임스페이스로 변경되었습니다. 또한, 불필요한 기능을 제거하고, 더 많은 ORM 관련 기능을 강화하여 JPA를 더욱 효율적으로 사용할 수 있도록 개선되었습니다.

2. 주요 변경 사항 및 새로운 기능

(1) 패키지 변경 (javax.persistence → jakarta.persistence )

기존 Java EE 기반이었던 javax.persistence 패키지가 jakarta.persistence로 변경되었습니다.

import jakarta.persistence.Entity;
import jakarta.persistence.Id;

기존 코드 (javax.persistence)는 JPA 3.0에서 더 이상 지원되지 않으므로, 최신 버전으로 마이그레이션할 경우 변경이 필요합니다.

(2) Criteria API 개선 – setParameter의 동적 타입 지원

기존 JPA의 Criteria API에서는 setParameter()에 명확한 타입을 지정해야 했으나, JPA 3.0에서는 동적 타입을 지원하여 더욱 유연한 코드 작성이 가능해졌습니다.

기존 코드 (JPA 2.x)

CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery<Member> query = cb.createQuery(Member.class);
Root<Member> root = query.from(Member.class);
query.select(root).where(cb.equal(root.get("name"), cb.parameter(String.class, "nameParam")));
TypedQuery<Member> typedQuery = entityManager.createQuery(query);
typedQuery.setParameter("nameParam", "John");

변경된 코드 (JPA 3.0)

CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery<Member> query = cb.createQuery(Member.class);
Root<Member> root = query.from(Member.class);
query.select(root).where(cb.equal(root.get("name"), cb.parameter(String.class, "nameParam")));
TypedQuery<Member> typedQuery = entityManager.createQuery(query);
typedQuery.setParameter("nameParam", "John", String.class); // 동적 타입 지원

이제 setParameter에서 동적 타입을 명확하게 설정할 수 있습니다.

(3) JPQL에서 RETURNING 키워드 지원

JPA 3.0에서는 일부 데이터베이스(예: PostgreSQL)에서 지원하는 RETURNING 키워드를 활용하여 INSERT, UPDATE, DELETE 후 값을 반환하는 기능이 추가되었습니다.

예제: RETURNING 사용

Query query = entityManager.createQuery("UPDATE Member m SET m.status = 'INACTIVE' WHERE m.age > 30 RETURNING m.id");
List<Long> updatedIds = query.getResultList();

이제 특정 조건으로 업데이트된 엔티티의 ID를 바로 조회할 수 있습니다.

(4) Entity Graph의 향상된 지원

JPA 3.0에서는 EntityGraph를 더 강력하게 활용할 수 있도록 개선되었습니다.

예제: Named Entity Graph 적용

@Entity
@NamedEntityGraph(name = "Member.withTeam", attributeNodes = @NamedAttributeNode("team"))
public class Member {
    @Id @GeneratedValue
    private Long id;
    private String name;
    
    @ManyToOne(fetch = FetchType.LAZY)
    private Team team;
}

EntityGraph<?> entityGraph = entityManager.getEntityGraph("Member.withTeam");
Map<String, Object> hints = new HashMap<>();
hints.put("jakarta.persistence.loadgraph", entityGraph);

Member member = entityManager.find(Member.class, 1L, hints);

이제 Entity Graph를 활용하면 복잡한 쿼리를 줄이면서도 연관된 엔티티를 효율적으로 로딩할 수 있습니다.

(5) @Converter를 활용한 더 나은 데이터 변환

JPA 3.0에서는 @Converter를 활용하여 더 많은 유형의 변환을 지원합니다.

예제: Boolean → String 변환

@Converter(autoApply = true)
public class BooleanToStringConverter implements AttributeConverter<Boolean, String> {
    @Override
    public String convertToDatabaseColumn(Boolean attribute) {
        return (attribute != null && attribute) ? "Y" : "N";
    }
    @Override
    public Boolean convertToEntityAttribute(String dbData) {
        return "Y".equals(dbData);
    }
}

이제 Boolean 값을 "Y" 또는 "N"으로 변환하여 저장할 수 있습니다.

3. JPA 3.0으로 마이그레이션 시 고려할 점

• javax.persistence → jakarta.persistence 네임스페이스 변경 필요
• 기존 JPQL 및 Criteria API를 사용할 경우 동적 타입 지원을 활용 가능
• RETURNING 키워드, Entity Graph, @Converter 등의 새로운 기능을 활용하여 성능 최적화 가능

4. 결론

JPA 3.0은 기존 JPA 2.x의 기능을 개선하면서도 더 강력한 ORM 기능을 제공하는 버전입니다. 특히 Jakarta EE 네임스페이스 변경과 함께, Criteria API 개선, RETURNING 키워드 지원, Entity Graph 향상 등이 포함되어 더욱 효율적인 ORM 환경을 제공하고 있습니다.

JPA 3.0으로 마이그레이션할 경우 주요 변경 사항을 숙지하고, 새로운 기능을 활용하여 성능 최적화를 고려하는 것이 중요합니다.

1. VO(Value Object)란?

VO(Value Object)는 값을 표현하는 객체로, 변경이 불가능(Immutable)하며 동일한 속성을 가지면 같은 객체로 간주됩니다.

VO의 주요 특징

• 불변성(Immutable) → 객체 생성 후 값 변경 불가
• 동등성(Equality) 비교 → 동일한 값을 가지면 같은 객체로 간주
• 로직을 포함할 수 있음 → VO 내부에서 관련된 비즈니스 로직을 처리 가능

JPA에서 VO를 활용하면 엔티티의 일관성을 유지하고, 중복된 값 로직을 제거할 수 있는 장점이 있습니다.

2. JPA에서 VO 패턴 적용 방법

(1) VO를 활용하지 않은 일반적인 엔티티 설계

@Entity
public class Member {
    @Id @GeneratedValue
    private Long id;
    private String city;
    private String street;
    private String zipcode;
}

위처럼 엔티티 내에 주소 관련 필드를 직접 추가하면, 여러 엔티티에서 동일한 값 관련 로직이 중복될 수 있습니다.

(2) VO를 적용한 엔티티 설계

JPA에서는 @Embeddable과 @Embedded를 사용하여 VO 패턴을 적용할 수 있습니다.

@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;
    }
}

@Entity
public class Member {
    @Id @GeneratedValue
    private Long id;
    
    @Embedded
    private Address address;
}

VO 패턴 적용의 장점

✅ 재사용성 증가 → 여러 엔티티에서 동일한 값 객체를 재사용 가능

✅ 데이터 일관성 유지 → 동일한 값을 가지면 같은 객체로 관리

✅ 불변성 보장 → 값 변경이 불가능하여 안전한 데이터 모델링 가능

3. VO의 불변성 유지하기

VO는 값이 변경되면 안 되므로, Setter를 제공하지 않고, 생성자로만 값을 설정해야 합니다.

@Embeddable
public class Money {
    private int amount;

    protected Money() {}

    public Money(int amount) {
        if (amount < 0) {
            throw new IllegalArgumentException("금액은 0 이상이어야 합니다.");
        }
        this.amount = amount;
    }
}

이렇게 하면 Money 객체가 생성된 이후 값을 변경할 수 없으며, 잘못된 값이 들어가는 것도 방지할 수 있습니다.

4. VO를 활용한 비즈니스 로직 처리

VO 내부에 연산 로직을 추가하면 비즈니스 규칙을 보다 직관적으로 관리할 수 있습니다.

@Embeddable
public class DiscountRate {
    private double rate;
    
    protected DiscountRate() {}
    
    public DiscountRate(double rate) {
        if (rate < 0 || rate > 100) {
            throw new IllegalArgumentException("할인율은 0~100% 사이여야 합니다.");
        }
        this.rate = rate;
    }
    
    public double applyDiscount(double price) {
        return price * (1 - rate / 100);
    }
}

이제 엔티티에서 applyDiscount() 메서드를 사용하여 할인된 가격을 쉽게 계산할 수 있습니다.

@Entity
public class Product {
    @Id @GeneratedValue
    private Long id;
    
    private double price;
    
    @Embedded
    private DiscountRate discountRate;
    
    public double getDiscountedPrice() {
        return discountRate.applyDiscount(price);
    }
}

1. JPA와 NoSQL의 개념

JPA(Java Persistence API)

JPA는 관계형 데이터베이스(RDBMS)와 객체를 매핑하는 ORM(Object-Relational Mapping) 기술입니다. 대표적인 구현체로는 Hibernate, EclipseLink 등이 있으며, 관계형 데이터 모델을 기반으로 동작합니다.

NoSQL과 MongoDB

MongoDB는 대표적인 NoSQL 데이터베이스로, 관계형 데이터베이스와 달리 스키마 없이 JSON(BSON) 형식으로 데이터를 저장합니다.

• 테이블 대신 컬렉션(Collection)
• 행(Row) 대신 문서(Document) 구조 사용
• 수직적 확장(Scale-Out)에 유리함

2. JPA와 MongoDB를 함께 사용할 수 있을까?

JPA는 본래 관계형 데이터베이스(RDBMS)를 위한 ORM 기술이기 때문에,

JPA 자체로 MongoDB를 직접 사용할 수는 없습니다.

하지만 Spring Data MongoDB를 활용하면 Spring Data JPA와 함께 사용할 수 있는 구조를 만들 수 있습니다.

3. Spring Boot에서 JPA와 MongoDB 함께 사용하기

(1) 의존성 추가 (Gradle 기준)

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa' // JPA
    implementation 'org.springframework.boot:spring-boot-starter-data-mongodb' // MongoDB
    runtimeOnly 'org.postgresql:postgresql' // RDBMS 예제 (선택 사항)
}

(2) application.properties 설정

# 관계형 데이터베이스 설정 (JPA)
spring.datasource.url=jdbc:mysql://localhost:3306/mydb
spring.datasource.username=root
spring.datasource.password=root
spring.jpa.hibernate.ddl-auto=update

# MongoDB 설정
spring.data.mongodb.uri=mongodb://localhost:27017/mydatabase

4. JPA 엔티티와 MongoDB 문서 작성

(1) JPA 엔티티 예제 (RDBMS)

import jakarta.persistence.*;

@Entity
public class User {
    @Id @GeneratedValue
    private Long id;
    private String name;
}

(2) MongoDB 문서 예제

import org.springframework.data.annotation.Id;
import org.springframework.data.mongodb.core.mapping.Document;

@Document(collection = "users")
public class UserDocument {
    @Id
    private String id;
    private String name;
}

MongoDB에서는 @Entity 대신 @Document를 사용하며, ID는 기본적으로 String 타입입니다.

5. JPA와 MongoDB 저장소(repository) 설정

(1) JPA Repository (RDBMS)

import org.springframework.data.jpa.repository.JpaRepository;

public interface UserRepository extends JpaRepository<User, Long> {
    User findByName(String name);
}

(2) MongoDB Repository

import org.springframework.data.mongodb.repository.MongoRepository;

public interface UserDocumentRepository extends MongoRepository<UserDocument, String> {
    UserDocument findByName(String name);
}

MongoDB에서는 JpaRepository 대신 MongoRepository를 사용해야 합니다.

1. 지연 로딩(Lazy Loading)과 즉시 로딩(Eager Loading)이란?

JPA에서는 엔티티를 조회할 때 연관된 엔티티를 언제 로딩할지를 결정하는 방식이 두 가지가 있습니다.

• 지연 로딩(Lazy Loading): 연관된 엔티티를 실제로 사용할 때 쿼리를 실행하여 가져오는 방식
• 즉시 로딩(Eager Loading): 엔티티를 조회할 때 연관된 엔티티를 한 번에 함께 가져오는 방식

JPA에서는 @OneToMany, @ManyToOne, @OneToOne, @ManyToMany 등의 관계에서 fetch 속성을 사용하여 로딩 전략을 설정할 수 있습니다.

@ManyToOne(fetch = FetchType.LAZY)
private Team team; // 지연 로딩

@OneToMany(mappedBy = "team", fetch = FetchType.EAGER)
private List<Member> members; // 즉시 로딩

2. 지연 로딩(Lazy Loading)

지연 로딩 동작 방식

• 엔티티를 조회할 때 연관된 엔티티를 프록시 객체로 설정
• 실제로 해당 객체를 사용할 때 쿼리를 실행하여 데이터 조회
• 불필요한 데이터 로딩을 방지하여 성능 최적화 가능

지연 로딩 예제

@Entity
public class Member {
    @Id @GeneratedValue
    private Long id;
    private String name;
    
    @ManyToOne(fetch = FetchType.LAZY)
    private Team team; // 지연 로딩 적용
}

Member member = entityManager.find(Member.class, 1L); // SELECT * FROM member
Team team = member.getTeam(); // team을 사용할 때 SELECT * FROM team 실행

장점

✔ 필요할 때만 데이터를 불러오기 때문에 불필요한 데이터 로딩을 방지할 수 있음

✔ 성능 최적화 가능 (특히, 불필요한 조인 방지)

단점

⚠ 연관된 데이터를 여러 번 조회할 경우 N+1 문제 발생 가능

⚠ team.getName()을 호출할 때 쿼리가 실행되므로, 즉시 로딩보다 지연되는 경우 발생

3. 즉시 로딩(Eager Loading)

즉시 로딩 동작 방식

• 엔티티를 조회할 때 연관된 엔티티까지 한 번에 가져옴
• JOIN을 사용하여 한 번의 쿼리로 데이터를 조회

즉시 로딩 예제

@Entity
public class Member {
    @Id @GeneratedValue
    private Long id;
    private String name;
    
    @ManyToOne(fetch = FetchType.EAGER)
    private Team team; // 즉시 로딩 적용
}

Member member = entityManager.find(Member.class, 1L); // SELECT m.*, t.* FROM member m JOIN team t
Team team = member.getTeam(); // 추가 쿼리 실행 없이 사용 가능

장점

✔ 연관된 엔티티를 한 번에 로딩하므로 즉시 사용할 때 추가 쿼리가 실행되지 않음

✔ JOIN FETCH를 사용할 경우 N+1 문제를 줄일 수 있음

단점

⚠ 항상 연관된 엔티티를 함께 로딩하기 때문에 불필요한 데이터까지 불러와서 성능 저하 발생 가능

⚠ 연관된 데이터가 많아지면 JOIN 쿼리의 성능 부담 증가

4. 지연 로딩과 즉시 로딩의 활용법

(1) 기본적으로는 지연 로딩(Lazy Loading) 사용

• 즉시 로딩은 불필요한 데이터를 가져올 가능성이 높아 성능 저하를 일으킬 수 있음
• 대부분의 경우 FetchType.LAZY를 사용하고, 필요할 때만 조인(Fetch Join) 적용

(2) 즉시 로딩이 유용한 경우

• 항상 연관된 데이터를 함께 조회해야 할 경우
• 데이터의 크기가 작고, 조인을 통해 얻는 성능 이점이 있는 경우

(3) Fetch Join을 활용한 성능 최적화

즉시 로딩을 무조건 설정하는 것보다, 필요한 경우 JPQL에서 JOIN FETCH를 사용하여 최적화 가능

List<Member> members = entityManager.createQuery(
    "SELECT m FROM Member m JOIN FETCH m.team", Member.class)
    .getResultList();

이렇게 하면 FetchType.LAZY를 유지하면서도 N+1 문제를 해결할 수 있음.

5. 결론

✔  기본적으로 지연 로딩을 사용하여 불필요한 데이터 조회를 방지해야 함

✔  즉시 로딩은 항상 연관된 데이터를 함께 조회해야 할 경우에만 사용

✔  N+1 문제 해결을 위해 Fetch Join을 적극 활용

✔  필요에 따라 EntityGraph, Batch Size 등 추가적인 최적화 기법 활용 가능

1. 트랜잭션(Transaction)이란?

트랜잭션은 데이터베이스의 작업 단위로, 여러 개의 연산이 하나의 논리적인 작업으로 처리되는 것을 의미합니다. JPA는 트랜잭션을 통해 데이터의 일관성을 유지하고, 실패 시 롤백을 수행하는 기능을 제공합니다.

트랜잭션의 기본 원칙은 ACID(Atomicity, Consistency, Isolation, Durability)로 정리할 수 있습니다.

• Atomicity(원자성): 트랜잭션 내의 작업이 모두 완료되거나, 하나라도 실패하면 전체가 롤백됨
• Consistency(일관성): 트랜잭션이 실행되면 데이터는 항상 일관된 상태를 유지해야 함
• Isolation(고립성): 각 트랜잭션은 독립적으로 실행되어야 함
• Durability(지속성): 트랜잭션이 성공적으로 완료되면 그 결과는 영구적으로 반영됨

2. JPA에서 트랜잭션 관리

JPA에서는 EntityManager를 통해 트랜잭션을 관리할 수 있습니다. 하지만 Spring Boot에서는 @Transactional을 사용하여 트랜잭션을 더욱 편리하게 관리할 수 있습니다.

(1) EntityManager를 이용한 트랜잭션 관리

EntityManager em = entityManagerFactory.createEntityManager();
EntityTransaction tx = em.getTransaction();
try {
    tx.begin(); // 트랜잭션 시작
    Member member = new Member("John");
    em.persist(member); // INSERT 실행 예정 (쓰기 지연)
    tx.commit(); // 트랜잭션 커밋 (INSERT 실행)
} catch (Exception e) {
    tx.rollback(); // 예외 발생 시 롤백
} finally {
    em.close();
}

위와 같이 EntityTransaction을 사용하여 수동으로 트랜잭션을 관리할 수도 있지만, Spring에서는 @Transactional을 활용하여 더 간편하게 관리할 수 있습니다.

3. @Transactional의 동작 방식

(1) @Transactional 기본 사용법

Spring에서는 @Transactional을 사용하면 자동으로 트랜잭션을 시작하고, 예외 발생 시 롤백하도록 처리됩니다.

@Service
public class MemberService {
    private final MemberRepository memberRepository;

    public MemberService(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

    @Transactional
    public void saveMember(String name) {
        Member member = new Member(name);
        memberRepository.save(member);
    }
}

(2) @Transactional의 주요 기능

• @Transactional이 선언된 메서드가 실행되면 트랜잭션이 자동으로 시작됨
• 메서드가 정상 종료되면 트랜잭션이 커밋(commit) 됨
• 메서드에서 예외가 발생하면 자동으로 롤백(rollback) 됨

4. 트랜잭션 전파 옵션 (Propagation)

@Transactional은 트랜잭션이 어떻게 동작할지를 결정하는 전파(Propagation) 옵션을 제공하며, 기본값은 REQUIRED입니다.

전파 옵션설명

전파 옵션 예제

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void createOrder() {
    Order order = new Order();
    orderRepository.save(order);
}

위 코드는 REQUIRES_NEW 옵션을 사용하여 항상 새로운 트랜잭션을 생성합니다.

5. 트랜잭션 롤백 설정

Spring의 @Transactional은 기본적으로 체크 예외(Checked Exception)는 롤백하지 않고, 실행 예외(Runtime Exception)만 롤백합니다.

(1) 기본 롤백 동작

@Transactional
public void process() throws Exception {
    throw new Exception("체크 예외"); // 롤백되지 않음
}

위 예제는 체크 예외(Exception)가 발생하지만 롤백되지 않습니다.

(2) 특정 예외 롤백 설정

@Transactional(rollbackFor = Exception.class)
public void process() throws Exception {
    throw new Exception("체크 예외"); // 롤백됨
}

rollbackFor = Exception.class 옵션을 추가하면 체크 예외도 롤백 가능하게 설정할 수 있습니다.

6. @Transactional의 주의점

(1) 프록시 기반 동작으로 인한 내부 호출 문제

Spring의 @Transactional은 프록시 기반으로 동작하기 때문에 같은 클래스 내부에서 @Transactional이 적용된 메서드를 호출하면 트랜잭션이 제대로 적용되지 않을 수 있습니다.

@Service
public class MemberService {
    @Transactional
    public void outerMethod() {
        innerMethod(); // 트랜잭션이 적용되지 않음
    }

    @Transactional
    public void innerMethod() {
        // 실제로 트랜잭션이 적용되지 않음
    }
}

해결 방법으로 트랜잭션을 관리하는 별도의 클래스로 분리하거나, AOP 프록시를 활용하여 해결할 수 있습니다.

(2) 읽기 전용 트랜잭션 설정

읽기 전용 트랜잭션을 설정하면 Hibernate의 성능 최적화를 활용할 수 있습니다.

@Transactional(readOnly = true)
public List<Member> findAllMembers() {
    return memberRepository.findAll();
}

readOnly = true를 설정하면 변경 감지가 비활성화되고, 불필요한 쓰기 지연 저장소 기능이 동작하지 않아서 성능이 최적화됩니다.

7. 결론

• JPA에서는 EntityManager를 통해 트랜잭션을 관리할 수 있지만, Spring에서는 @Transactional을 사용하여 더욱 편리하게 트랜잭션을 관리할 수 있습니다.
• 전파 옵션(Propagation)을 활용하여 트랜잭션의 흐름을 제어할 수 있으며, 기본적으로 REQUIRED 옵션이 사용됩니다.
• Spring의 @Transactional은 실행 예외(Runtime Exception) 발생 시 자동으로 롤백되며, 체크 예외는 rollbackFor 옵션을 통해 롤백 가능하게 설정할 수 있습니다.

1. JPA란?

JPA(Java Persistence API)란?

JPA는 자바 객체(Entity)와 관계형 데이터베이스(RDB)를 매핑하는 ORM(Object-Relational Mapping) 기술의 표준 인터페이스입니다. 즉, JPA 자체는 구현체가 아니라 ORM을 위한 표준 스펙(명세, API) 을 정의하는 역할을 합니다.

JPA의 주요 특징

• 객체와 관계형 데이터베이스 매핑 → 자바 객체(Entity)와 데이터베이스 테이블을 자동으로 매핑
• SQL 대신 메서드 기반 데이터 조작 → JPQL을 사용하여 SQL 없이 데이터 조회 및 조작 가능
• 트랜잭션 및 영속성 컨텍스트 관리 → 데이터 변경 감지, 1차 캐시, 자동 플러시 등의 기능 제공
• 데이터베이스 독립성 보장 → 특정 DBMS(MySQL, PostgreSQL, Oracle 등)에 종속되지 않고 구현체 변경 가능

즉, JPA는 SQL을 직접 다루지 않고 객체 중심으로 데이터베이스를 관리할 수 있도록 도와주는 표준 기술입니다.

2. Hibernate란?

Hibernate란?

Hibernate는 JPA의 구현체(Provider) 중 하나입니다. JPA가 인터페이스라면, Hibernate는 그 인터페이스를 실제로 동작하게 만드는 라이브러리라고 볼 수 있습니다.

Hibernate의 주요 특징

• JPA의 모든 기능을 지원하며, 추가적인 기능 제공
• Lazy Loading & Fetch 전략 지원 → 연관된 엔티티를 필요할 때만 불러오는 기능
• Hibernate Query Language (HQL) 지원 → JPQL과 유사한 쿼리 언어 제공
• 배치 처리 및 캐싱 최적화 → 벌크 연산 및 1차/2차 캐싱을 지원하여 성능 개선

Hibernate는 JPA 표준을 따르면서도 고유한 기능을 추가로 제공하는 강력한 ORM 프레임워크입니다.

3. JPA와 Hibernate의 차이점

JPAHibernate

4. Spring Boot에서 JPA와 Hibernate

Spring Boot에서는 기본적으로 Hibernate를 JPA의 구현체로 사용합니다. 따라서 JPA를 사용할 경우 Hibernate가 자동으로 적용됩니다. 하지만 JPA는 특정 구현체에 의존하지 않기 때문에 필요하면 EclipseLink, OpenJPA 등의 다른 구현체로 교체할 수도 있습니다.

JPA와 Hibernate 설정 예제

Spring Boot에서 JPA(Hibernate) 설정

spring.datasource.url=jdbc:mysql://localhost:3306/testdb
spring.datasource.username=root
spring.datasource.password=root
spring.jpa.hibernate.ddl-auto=update
spring.jpa.show-sql=true

위 설정을 적용하면 JPA를 사용할 수 있으며, 기본적으로 Hibernate가 구현체로 동작합니다.

1. 영속성 컨텍스트(Persistence Context)란?

JPA에서 영속성 컨텍스트(Persistence Context)는 엔티티를 관리하는 중요한 개념으로, 엔티티의 상태를 관리하고 자동 변경 감지를 수행하는 역할을 합니다. 영속성 컨텍스트는 EntityManager를 통해 관리되며, 트랜잭션 단위로 엔티티를 캐싱하고 변경 사항을 추적합니다.

2. 영속성 컨텍스트의 주요 동작 원리

(1) 1차 캐시(First-Level Cache)

JPA에서는 데이터베이스에서 조회한 엔티티를 1차 캐시에 저장합니다. 이후 동일한 엔티티를 조회할 경우 데이터베이스를 조회하지 않고 캐시에서 가져오기 때문에 성능이 향상됩니다.

1차 캐시 동작 예제

Member member1 = entityManager.find(Member.class, 1L); // DB에서 조회 후 1차 캐시에 저장
Member member2 = entityManager.find(Member.class, 1L); // 1차 캐시에서 바로 반환 (DB 조회 X)

위 코드에서 member1과 member2는 같은 영속성 컨텍스트 내에서 동일한 객체(엔티티)로 관리됩니다.

1차 캐시의 장점은 동일한 엔티티를 반복 조회할 때 성능을 최적화하고, 트랜잭션 내에서 엔티티 변경을 추적할 수 있다는 점입니다.

(2) 변경 감지 (Dirty Checking)

JPA의 변경 감지 기능을 활용하면 flush() 시점에 수정된 엔티티를 자동으로 감지하여 SQL UPDATE 쿼리를 실행합니다.

변경 감지 동작 예제

Member member = entityManager.find(Member.class, 1L); // 영속 상태
member.setUsername("newUsername"); // 값 변경 (SQL 실행 X)

entityManager.flush(); // 변경 감지 -> UPDATE 쿼리 자동 실행

변경 감지를 사용하면 update 메서드를 호출할 필요 없이 변경된 필드만 업데이트할 수 있습니다. 또한 flush() 시점까지 한 번의 UPDATE 쿼리만 실행되므로 성능이 최적화됩니다.

변경 감지는 영속성 컨텍스트 내의 엔티티에만 적용되며, 준영속(detached) 상태에서는 동작하지 않습니다.

(3) 쓰기 지연 (Write-Behind & Transactional Write-Behind)

JPA에서는 persist()를 호출한다고 해서 바로 INSERT SQL이 실행되지 않습니다. 쓰기 지연 전략에 의해 SQL은 트랜잭션이 커밋되는 시점에 한꺼번에 실행됩니다.

쓰기 지연 동작 예제

entityManager.persist(new Member("user1")); // INSERT SQL 실행 X
entityManager.persist(new Member("user2")); // INSERT SQL 실행 X

entityManager.flush(); // INSERT SQL이 한 번에 실행됨

이렇게 하면 여러 개의 INSERT 쿼리를 하나의 배치로 실행하여 성능을 최적화할 수 있습니다.

flush()를 호출하면 즉시 SQL이 실행되지만, 트랜잭션이 종료되지는 않습니다.

(4) 플러시 (Flush) 전략

flush()는 영속성 컨텍스트의 변경 사항을 데이터베이스에 반영하는 역할을 합니다. JPA는 기본적으로 트랜잭션이 커밋될 때 자동으로 flush()를 호출하지만, 필요에 따라 수동 호출할 수도 있습니다.

flush() 동작 방식

entityManager.flush(); // 변경된 엔티티의 변경 사항을 즉시 DB에 반영

flush()는 다음과 같은 시점에서 실행됩니다.

1. 트랜잭션이 커밋될 때 자동 실행
2. JPQL 실행 직전에 자동 실행
3. 수동으로 flush() 호출 시 즉시 실행

flush()는 SQL을 실행하지만, 트랜잭션을 종료하지 않으므로 이후 롤백이 가능합니다.

(5) 준영속(Detached) 상태와 병합(Merge)

JPA에서 엔티티가 영속성 컨텍스트에서 분리(Detached)되면 변경 감지가 동작하지 않습니다. 다시 영속 상태로 변경하려면 merge()를 사용해야 합니다.

준영속 상태 예제

Member member = entityManager.find(Member.class, 1L);
entityManager.detach(member); // 영속성 컨텍스트에서 분리 (준영속 상태)

member.setUsername("newUsername"); // 변경 감지 X (UPDATE 실행 안됨)

병합(Merge) 예제

Member detachedMember = new Member("user1");
Member mergedMember = entityManager.merge(detachedMember); // 병합 후 영속 상태로 변경

merge()는 기존 엔티티를 변경하는 것이 아니라 새로운 엔티티를 반환합니다. 따라서 기존 객체 대신 merge()로 반환된 객체를 사용해야 합니다.

1. QueryDSL이란?

QueryDSL은 타입 안전한 SQL 및 JPQL을 생성할 수 있도록 도와주는 프레임워크입니다. JPQL보다 가독성이 뛰어나고, 컴파일 타임에 오류를 잡을 수 있어 동적 쿼리를 작성할 때 매우 유용합니다.

2. QueryDSL 설정 및 기본 사용법

(1) QueryDSL 설정 (Gradle 기준)

dependencies {
    implementation 'com.querydsl:querydsl-jpa:5.0.0'
    annotationProcessor 'com.querydsl:querydsl-apt:5.0.0:jpa'
    annotationProcessor 'jakarta.persistence:jakarta.persistence-api:3.1.0'
}

QueryDSL을 사용하면 Q타입 클래스를 자동 생성해야 하므로, IDE에서 빌드 후 생성된 Q타입 클래스를 확인해야 합니다.

(2) QueryDSL 기본 사용법

1) Q클래스 생성

import com.querydsl.core.types.dsl.EntityPathBase;

QMember member = QMember.member;

2) 단순 조회 쿼리 작성

JPAQueryFactory queryFactory = new JPAQueryFactory(entityManager);
Member result = queryFactory
    .selectFrom(member)
    .where(member.username.eq("testUser"))
    .fetchOne();

3) 여러 조건을 사용하는 WHERE 절

List<Member> results = queryFactory
    .selectFrom(member)
    .where(
        member.age.gt(18),
        member.status.eq(Status.ACTIVE)
    )
    .fetch();

QueryDSL의 where() 메서드는 여러 조건을 가변 인자로 받을 수 있어 코드가 깔끔해집니다.

3. QueryDSL의 동적 쿼리 작성법

(1) BooleanBuilder 활용

BooleanBuilder를 사용하면 조건을 동적으로 추가할 수 있습니다.

BooleanBuilder builder = new BooleanBuilder();
if (username != null) {
    builder.and(member.username.eq(username));
}
if (age != null) {
    builder.and(member.age.gt(age));
}

List<Member> results = queryFactory
    .selectFrom(member)
    .where(builder)
    .fetch();

(2) Where절 메서드 추출

코드를 더 깔끔하게 만들기 위해 where 절을 별도의 메서드로 추출할 수도 있습니다.

private BooleanExpression usernameEq(String username) {
    return username != null ? member.username.eq(username) : null;
}

private BooleanExpression ageGt(Integer age) {
    return age != null ? member.age.gt(age) : null;
}

List<Member> results = queryFactory
    .selectFrom(member)
    .where(usernameEq(username), ageGt(age))
    .fetch();

이렇게 하면 가독성이 높아지고, 재사용성이 증가합니다.

4. QueryDSL을 활용한 복잡한 쿼리 작성

(1) 조인 (Join) 활용

List<Member> results = queryFactory
    .selectFrom(member)
    .join(member.team, QTeam.team)
    .where(QTeam.team.name.eq("TeamA"))
    .fetch();

(2) 서브쿼리 사용

QMember subMember = new QMember("subMember");
List<Member> results = queryFactory
    .selectFrom(member)
    .where(member.age.eq(
        JPAExpressions
            .select(subMember.age.max())
            .from(subMember)
    ))
    .fetch();

QueryDSL을 활용하면 JPQL에서는 어렵던 서브쿼리도 직관적으로 작성할 수 있습니다.

5. QueryDSL을 이용한 INSERT, UPDATE, DELETE

(1) QueryDSL을 이용한 INSERT

QueryDSL 자체로 INSERT 쿼리를 직접 지원하지 않음. JPA에서는 persist()를 사용하여 INSERT를 수행해야 함.

Member member = new Member();
member.setUsername("newUser");
member.setAge(25);
entityManager.persist(member);

(2) QueryDSL을 이용한 UPDATE

QueryDSL의 update()를 활용하여 벌크 업데이트 수행 가능.

long updatedRows = queryFactory
    .update(member)
    .set(member.age, member.age.add(1))
    .where(member.status.eq(Status.ACTIVE))
    .execute();

✅ 주의: 벌크 연산 후 entityManager.clear();로 영속성 컨텍스트 초기화 필요.

(3) QueryDSL을 이용한 DELETE

QueryDSL의 delete()를 활용하여 특정 조건의 데이터를 삭제 가능.

long deletedRows = queryFactory
    .delete(member)
    .where(member.age.lt(18))
    .execute();

✅ 주의: DELETE도 벌크 연산이므로 entityManager.flush(); 및 entityManager.clear(); 필요.

6. QueryDSL 사용 시 장점과 주의점

(1) QueryDSL의 장점

✅ 타입 안전성: 런타임이 아닌 컴파일 타임에 오류를 잡을 수 있음
✅ 가독성: JPQL보다 직관적인 문법
✅ 동적 쿼리 최적화: BooleanBuilder, Where절 분리 등을 활용하여 유연한 쿼리 작성 가능
✅ 복잡한 SQL 처리 가능: 서브쿼리, GroupBy, Join 등 다양한 SQL 기능 지원

(2) QueryDSL 사용 시 주의점

⚠ 빌드 시 Q타입 클래스 생성 필요: Q클래스가 자동 생성되지 않으면 빌드를 수동 실행해야 함

7. 결론

QueryDSL은 타입 안전한 동적 쿼리 작성을 지원하며, 복잡한 SQL을 쉽게 작성할 수 있는 강력한 도구입니다.

특히 JPQL보다 가독성이 좋고 유지보수성이 뛰어나기 때문에, Spring Boot + JPA 환경에서는 매우 편리하다.

1. Native Query란?

Spring Data JPA에서는 기본적으로 JPQL(Java Persistence Query Language)을 사용하지만, 복잡한 SQL을 실행해야 할 경우 @Query 어노테이션을 활용하여 Native Query를 사용할 수 있습니다.

Native Query는 직접 SQL을 작성하여 실행하는 방식으로, 복잡한 조인, 성능 최적화, 데이터베이스 특정 기능을 사용할 때 유용합니다.

2. Native Query 사용법

(1) 기본적인 Native Query 사용

public interface MemberRepository extends JpaRepository<Member, Long> {
    
    @Query(value = "SELECT * FROM member WHERE username = :username", nativeQuery = true)
    Member findByUsername(@Param("username") String username);
}

위 코드에서는 nativeQuery = true를 설정하여 순수 SQL을 실행하고 있습니다.

(2) 여러 컬럼을 조회하는 경우

@Query(value = "SELECT id, username FROM member WHERE team_id = :teamId", nativeQuery = true)
List<Object[]> findMembersByTeamId(@Param("teamId") Long teamId);

위와 같이 List<Object[]> 형태로 데이터를 받을 수 있으며, 필요하면 DTO로 변환해야 합니다.

(3) DTO 매핑하여 조회하기

Native Query의 결과를 DTO로 매핑하려면 @SqlResultSetMapping 또는 Constructor Expression을 사용할 수 있습니다.

1) @SqlResultSetMapping 사용

@SqlResultSetMapping(
    name = "MemberDtoMapping",
    classes = @ConstructorResult(
        targetClass = MemberDto.class,
        columns = {
            @ColumnResult(name = "id", type = Long.class),
            @ColumnResult(name = "username", type = String.class)
        }
    )
)

@Query(value = "SELECT id, username FROM member WHERE team_id = :teamId", nativeQuery = true)
@SqlResultSetMapping("MemberDtoMapping")
List<MemberDto> findMemberDtoByTeamId(@Param("teamId") Long teamId);

2) Constructor Expression 사용

@Query(value = "SELECT new com.example.dto.MemberDto(m.id, m.username) FROM Member m WHERE m.team.id = :teamId")
List<MemberDto> findMemberDtoByTeamId(@Param("teamId") Long teamId);

3. Native Query 사용 시 주의점

(1) 데이터베이스 종속성

• Native Query는 특정 데이터베이스의 SQL 문법을 따르므로, DBMS 변경 시 유지보수 비용이 증가할 수 있습니다.

(2) 결과 매핑 문제

• Native Query는 자동으로 엔티티와 매핑되지 않기 때문에, 컬럼명을 정확하게 매칭하거나 DTO를 활용해야 합니다.

(3) 동적 쿼리 지원 부족

• JPQL이나 QueryDSL과 달리, Native Query는 동적 쿼리 지원이 어렵기 때문에 String 기반으로 직접 조합해야 하는 불편함이 있습니다.
• 이를 해결하기 위해 EntityManager.createNativeQuery() 또는 QueryDSL + SQL Templates를 활용할 수도 있습니다.

4. 결론

Spring Data JPA의 Native Query는 복잡한 SQL을 실행하거나, 성능 최적화가 필요할 때 유용하지만, 데이터베이스 종속성과 유지보수 비용이 높아질 수 있습니다. 따라서 가급적이면 JPQL, QueryDSL을 우선적으로 고려하고, 필요할 때만 Native Query를 활용하는 것이 좋습니다.

1. N+1 문제란?

N+1 문제는 JPA에서 연관된 엔티티를 조회할 때 발생하는 성능 저하 문제 중 하나입니다. 이는 하나의 메인 엔티티를 조회한 후, 연관된 엔티티를 추가로 조회하면서 발생합니다.

예제 코드

@Entity
public class Team {
    @Id @GeneratedValue
    private Long id;
    private String name;
    
    @OneToMany(mappedBy = "team", fetch = FetchType.LAZY)
    private List<Member> members = new ArrayList<>();
}

@Entity
public class Member {
    @Id @GeneratedValue
    private Long id;
    private String username;
    
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "team_id")
    private Team team;
}

List<Team> teams = em.createQuery("SELECT t FROM Team t", Team.class).getResultList();
for (Team team : teams) {
    System.out.println(team.getMembers().size()); // N개의 추가 쿼리 실행
}

위 코드에서 Team을 조회한 후, 각 Team에 속한 Member를 조회하면서 N개의 추가 쿼리가 발생합니다.

2. N+1 문제 해결 방법

(1) LAZY 설정 사용

기본적으로 JPA는 @OneToMany와 같은 컬렉션 연관 관계에 대해 FetchType.LAZY를 적용하는 것이 좋습니다. LAZY 로딩을 사용하면 필요할 때만 연관된 엔티티를 가져와 N+1 문제를 최소화할 수 있습니다.

@OneToMany(mappedBy = "team", fetch = FetchType.LAZY)
private List<Member> members;

FetchType.LAZY를 설정하면 기본적으로 프록시 객체를 반환하며, 실제 엔티티가 필요한 시점에 쿼리가 실행됩니다.

(2) Fetch Join 사용

Fetch Join을 사용하면 한 번의 쿼리로 연관된 엔티티까지 한꺼번에 조회할 수 있습니다.

List<Team> teams = em.createQuery("SELECT t FROM Team t JOIN FETCH t.members", Team.class).getResultList();

(3) Entity Graph 사용

JPA의 @NamedEntityGraph 또는 EntityGraph를 사용하여 동적으로 연관 엔티티를 로딩할 수 있습니다.

@Entity
@NamedEntityGraph(name = "Team.members", attributeNodes = @NamedAttributeNode("members"))
public class Team {
    // ...
}

EntityGraph<?> entityGraph = em.getEntityGraph("Team.members");
Map<String, Object> hints = new HashMap<>();
hints.put("javax.persistence.fetchgraph", entityGraph);
List<Team> teams = em.createQuery("SELECT t FROM Team t", Team.class)
                      .setHint("javax.persistence.fetchgraph", entityGraph)
                      .getResultList();

(4) Batch Size 조정 (@BatchSize 사용)

Hibernate의 @BatchSize 옵션을 사용하면 연관된 엔티티를 한 번의 쿼리로 묶어서 가져올 수 있습니다.

@OneToMany(mappedBy = "team", fetch = FetchType.LAZY)
@BatchSize(size = 10)
private List<Member> members;

또는 글로벌 설정으로 적용할 수도 있습니다.

spring.jpa.properties.hibernate.default_batch_fetch_size=10

3. 결론

N+1 문제는 성능 저하를 유발하는 대표적인 문제이지만, LAZY 설정, Fetch Join, Entity Graph, Batch Size 등의 전략을 활용하면 효과적으로 해결할 수 있습니다. 상황에 맞는 최적화 전략을 선택하여 효율적인 JPA 사용을 고려하는 것이 중요합니다.