실무 기본값은 LAZY

핵심 차이는 연관 데이터를 지금 읽느냐, 필요할 때 읽느냐입니다

두 전략의 본질은 연관 엔티티를 가져오는 시점입니다. 그 시점이 바뀌면 초기 응답, 쿼리 수, 메모리 사용, N+1 위험이 함께 달라집니다.

같은 시작점

주문 목록을 먼저 조회한다. 이후 화면이나 API가 order.member.name까지 읽는지에 따라 전략의 차이가 드러난다.

LAZY

EAGER

가져오는 시점

연관 필드에 접근할 때 부모만 먼저 읽고, 자식은 실제 사용 시점에 초기화합니다.

부모 조회 직후 바로 부모를 읽는 순간 연관 엔티티도 함께 준비합니다.

같은 요청에서

목록만 보여주면 가볍게 끝나지만, member를 순회해서 읽기 시작하면 추가 조회가 이어져 N+1로 커질 수 있습니다.

이후 접근은 단순하지만, 실제로 쓰지 않는 연관 데이터까지 처음부터 읽어 과조회가 생기기 쉽습니다.

운영 비용

초기 응답이 가볍다 대신 접근 패턴을 모르면 뒤늦게 쿼리 비용이 붙습니다.

초기 응답과 메모리가 무거워질 수 있다 대신 이후 접근 비용은 예측하기 쉽습니다.

실무 해석

기본 전략으로 두고, 정말 함께 읽어야 하는 조회만 명시적으로 당깁니다.

전역 기본값으로 두기보다, 필요한 조회를 코드에서 분명히 드러낼 때만 사용합니다.

핵심 takeaway

LAZY는 기본 비용을 낮추고 선택적으로 확장하는 전략이고, EAGER는 편한 대신 필요 없는 연관 데이터까지 끌어와 전체 조회를 무겁게 만들 수 있습니다.

JPA 기본값 점검

기본값이 실무 기본 전략과 일치하지 않는 연관관계를 먼저 정리합니다.

@ManyToOne · @OneToOne 기본 EAGER → 보통 LAZY로 변경

@OneToMany · @ManyToMany 기본 LAZY → 그대로 유지