JPA 기초

다음 장의 Spring Data JPA는 인터페이스만 선언하면 CRUD가 자동으로 만들어지는 편리한 도구다. 하지만 그 편리함이 어떻게 동작하는지는 한 겹 아래에 있는 JPA와 영속성 컨텍스트를 알아야 이해된다. 이 장에서는 "왜 save()를 부르지 않아도 수정이 되는가" 같은 질문에 답할 수 있도록 JPA의 핵심 개념을 먼저 다진다.

#1. ORM과 JPA

자바는 객체로 데이터를 다루고, 관계형 데이터베이스는 테이블(행과 열) 로 데이터를 다룬다. 이 둘은 사고방식이 다르다.

• 객체는 참조(member.getTeam().getName())로 연관 데이터를 따라간다.

• 테이블은 외래 키(FK)와 조인으로 연관 데이터를 잇는다.

이 차이를 객체-관계 패러다임 불일치라고 한다. 개발자가 직접 SQL을 쓰면 객체를 테이블에 맞춰 일일이 변환하는 반복 코드가 끝없이 생긴다.

ORM(Object-Relational Mapping) 은 객체와 테이블을 자동으로 매핑해 이 변환을 대신해 주는 기술이다. JPA는 자바의 ORM 표준 명세이고, Hibernate는 그 명세를 구현한 대표 라이브러리다.

graph LR
    A[내 코드<br/>엔티티 객체] --> B[JPA 표준 명세]
    B --> C[Hibernate 구현체]
    C --> D[(데이터베이스)]

#2. EntityManager와 영속성 컨텍스트

JPA의 모든 동작은 EntityManager(엔티티 매니저) 를 통해 일어난다. 엔티티를 저장·조회·수정·삭제할 때 우리는 EntityManager에게 일을 시킨다.

그리고 EntityManager는 내부에 영속성 컨텍스트(Persistence Context) 라는 공간을 가진다. 이것이 JPA의 심장이다.

영속성 컨텍스트 = "엔티티를 보관하고 관리하는 가상의 메모리 공간"

엔티티를 직접 DB에 넣는 게 아니라, 먼저 이 영속성 컨텍스트에 넣는다. 그러면 JPA가 적절한 시점에 알아서 DB와 동기화한다.

// 순수 JPA 코드 (Spring Data JPA는 이 과정을 감춰 준다)
em.persist(member);   // 영속성 컨텍스트에 member를 저장(아직 DB 아님)
Member found = em.find(Member.class, 1L);   // 조회

#3. 엔티티의 생명주기

엔티티 객체는 영속성 컨텍스트와의 관계에 따라 네 가지 상태를 오간다.

stateDiagram-v2
    비영속: 비영속 (new)
    영속: 영속 (managed)
    준영속: 준영속 (detached)
    삭제: 삭제 (removed)
    비영속 --> 영속: persist()
    영속 --> 준영속: detach() / 트랜잭션 종료
    영속 --> 삭제: remove()
    준영속 --> 영속: merge()

Member member = new Member();   // 1) 비영속 — 그냥 자바 객체
member.setName("kim");

em.persist(member);             // 2) 영속 — 영속성 컨텍스트가 관리 시작
member.setName("lee");          // 영속 상태라 이 변경은 자동 감지된다

em.detach(member);              // 3) 준영속 — 더는 관리하지 않음
em.remove(member);              // 4) 삭제

#4. 영속성 컨텍스트가 주는 이점

엔티티를 곧장 DB에 넣지 않고 영속성 컨텍스트를 한 단계 거치는 이유는, 그 사이에서 JPA가 여러 최적화를 해 주기 때문이다.

#① 1차 캐시 — 같은 트랜잭션 안 반복 조회는 DB를 안 친다

영속성 컨텍스트는 관리 중인 엔티티를 내부 캐시(1차 캐시)에 들고 있다. 같은 트랜잭션 안에서 같은 식별자를 다시 조회하면 DB 대신 캐시에서 바로 꺼낸다.

Member m1 = em.find(Member.class, 1L);   // DB에서 조회 → 1차 캐시에 저장
Member m2 = em.find(Member.class, 1L);   // SELECT 쿼리 없음! 캐시에서 반환

#② 동일성 보장

같은 식별자로 조회한 엔티티는 같은 객체다. 1차 캐시 덕분에 == 비교가 참이 된다.

m1 == m2;   // true

#③ 쓰기 지연 — INSERT를 모았다가 한 번에

persist()를 호출해도 INSERT SQL이 바로 나가지 않는다. SQL을 쓰기 지연 저장소에 모아 두었다가, 커밋(flush) 시점에 한꺼번에 DB로 보낸다.

em.persist(memberA);   // INSERT SQL 만들어 저장소에 쌓기만
em.persist(memberB);   // INSERT SQL 또 쌓기
// 아직 DB에는 아무 일도 일어나지 않음
tx.commit();           // 이 순간 모아 둔 INSERT가 한꺼번에 실행

#④ 변경 감지 (Dirty Checking) — update()가 없는 이유

JPA에는 update() 메소드가 없다. 영속 상태 엔티티의 값을 바꾸기만 하면 커밋 시점에 JPA가 알아서 UPDATE SQL을 만든다.

Member member = em.find(Member.class, 1L);   // 영속 상태
member.setName("새이름");                      // 값만 변경
// em.update(member)  ← 이런 코드는 필요 없다(존재하지도 않는다)
tx.commit();                                  // 변경 감지 → UPDATE 자동 실행

원리는 이렇다. 영속성 컨텍스트는 엔티티를 처음 읽어 온 시점의 스냅샷을 따로 보관한다. 커밋(flush) 때 현재 값과 스냅샷을 비교해, 달라진 필드가 있으면 UPDATE를 생성한다.

graph LR
    A[조회 시점<br/>스냅샷 저장] --> B[필드 값 변경]
    B --> C[커밋/flush]
    C --> D{스냅샷과 비교}
    D -->|다름| E[UPDATE 생성·실행]
    D -->|같음| F[아무 일 없음]

#5. flush — 영속성 컨텍스트를 DB에 반영

flush는 영속성 컨텍스트의 변경 내용(쌓인 INSERT/UPDATE/DELETE)을 DB에 실제로 내보내는 동작이다. flush가 일어나는 시점은 세 가지다.

#6. JPQL — 객체를 향한 쿼리

find()는 식별자(PK) 하나로만 조회한다. "이름이 kim인 회원 전체"처럼 조건 검색이 필요하면 JPQL(Java Persistence Query Language) 을 쓴다. JPQL은 테이블이 아니라 엔티티 객체를 대상으로 하는 SQL과 비슷한 쿼리다.

// FROM 뒤가 테이블명(member)이 아니라 엔티티명(Member)이다
List<Member> members = em.createQuery(
        "select m from Member m where m.name = :name", Member.class)
    .setParameter("name", "kim")
    .getResultList();

JPA가 이 JPQL을 실제 DB 방언에 맞는 SQL로 번역해 실행한다. 다음 장에서 볼 Spring Data JPA의 쿼리 메소드(findByName)와 @Query 가 결국 이 JPQL을 더 편하게 쓰는 방법이다.

#7. 연관관계의 이해

엔티티는 혼자 있지 않다. 회원은 여러 주문을 갖고, 주문은 한 회원에 속한다. 이런 엔티티 사이의 관계를 연관관계로 매핑한다. 여기서 핵심은 객체와 테이블이 관계를 표현하는 방식이 다르다는 점이다.

• 객체는 참조로 잇는다 — order.getMember()

• 테이블은 외래 키(FK)로 잇는다 — orders.member_id

JPA가 이 둘을 연결해, 객체 참조를 따라가면 알맞은 조인/조회 SQL이 나가도록 해 준다.

#방향 — 단방향과 양방향

테이블은 FK 하나면 양쪽 어디서든 조인할 수 있어 방향이 없다. 하지만 객체는 참조를 가진 쪽에서만 반대쪽을 찾아갈 수 있어 방향이 생긴다.

• 단방향: 한쪽만 참조를 가진다. (Order만 member를 가짐)

• 양방향: 양쪽이 서로 참조를 가진다. (Order.member + Member.orders)

#다중성

#연관관계의 주인 (owner) { #7-owner }

양방향 관계에서 가장 많이 헷갈리는 개념이다. 객체는 참조가 둘(Order.member, Member.orders)인데, 테이블의 FK는 orders.member_id 하나뿐이다. 그래서 JPA는 "이 FK를 누가 관리할지" 한 쪽을 정해야 한다. 이 쪽이 연관관계의 주인이다.

• 주인 = FK를 가진 쪽, 즉 @ManyToOne이 있는 쪽(여기서는 Order)이다.

• 주인이 아닌 쪽(@OneToMany)은 mappedBy로 "나는 저쪽 필드에 의해 매핑된, 읽기 전용 거울" 임을 표시한다.

class Order {
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "member_id")   // ← FK를 가진 '주인'
    private Member member;
}

class Member {
    @OneToMany(mappedBy = "member")   // ← 주인이 아님(읽기 전용). FK를 바꾸지 못한다
    private List<Order> orders = new ArrayList<>();
}

#8. N+1 문제 { #8 }

연관관계와 지연 로딩(LAZY)을 쓰면 거의 반드시 만나는 대표적인 성능 함정이 N+1 문제다.

목록을 가져오는 쿼리 1번 + 그 목록의 각 항목마다 연관 엔티티를 가져오는 쿼리 N번 = 총 N+1번

#어떻게 생기나

LAZY 연관 필드는 실제로 접근하는 순간 쿼리가 나간다. 그래서 목록을 돌면서 연관 엔티티에 접근하면, 건수만큼 추가 쿼리가 발생한다.

// 주문 10건 조회 → SELECT 1번
List<Order> orders = orderRepository.findAll();

for (Order order : orders) {
    // order.member는 LAZY → 접근하는 순간 회원 SELECT가 매번 나간다
    System.out.println(order.getMember().getName());   // ← 10번 추가 쿼리
}
// 합계: 1(주문) + 10(회원) = 11번

select * from orders;                       -- 1번
select * from member where id = 1;          -- +1
select * from member where id = 2;          -- +1
...                                          -- 주문 수만큼 반복

데이터가 10건이면 11번이지만, 1000건이면 1001번이다. 목록이 커질수록 치명적이다.

#해결 방법

// fetch join — 주문과 회원을 한 방에 조인해서 조회 (쿼리 1번)
@Query("select o from Order o join fetch o.member")
List<Order> findAllWithMember();

#9. 이제 Spring Data JPA로

여기까지가 순수 JPA의 뼈대다. 정리하면, 우리는 엔티티를 영속성 컨텍스트에 맡기고, JPA가 1차 캐시·쓰기 지연·변경 감지로 DB와의 동기화를 똑똑하게 처리한다.

하지만 순수 JPA만 쓰면 EntityManager를 직접 열고 닫고, 트랜잭션을 일일이 관리하고, 반복적인 CRUD 코드를 매번 짜야 한다. Spring Data JPA는 이 반복을 걷어내고 JpaRepository 인터페이스 선언만으로 CRUD를 제공한다. 그 안에서 지금 배운 영속성 컨텍스트가 그대로 돌아간다.