JPA/Hibernate 주니어 기술면접
새 면접Q. JPA의 영속성 컨텍스트(Persistence Context)란 무엇이며, 엔티티의 생명주기(Entity Lifecycle)에 대해 설명해주세요.
엔티티를 관리하는 메모리 공간과 4가지 상태(비영속, 영속, 준영속, 삭제)를 생각해보세요.
영속성 컨텍스트는 엔티티를 영구 저장하는 환경으로, 엔티티 매니저를 통해 엔티티를 관리하는 일종의 1차 캐시 공간입니다. 엔티티의 생명주기는 비영속(new), 영속(managed), 준영속(detached), 삭제(removed) 4가지 상태로 구분됩니다. 비영속은 엔티티 객체를 생성만 한 상태이고, 영속은 persist() 메서드로 영속성 컨텍스트에 저장된 상태입니다. 준영속은 detach()나 clear()로 영속성 컨텍스트에서 분리된 상태이며, 삭제는 remove()로 삭제를 요청한 상태입니다. 영속 상태의 엔티티만 변경 감지와 1차 캐시의 이점을 누릴 수 있습니다.
- • 영속성 컨텍스트는 엔티티를 관리하는 메모리 공간
- • 4가지 생명주기: 비영속, 영속, 준영속, 삭제
- • 영속 상태에서만 JPA의 주요 기능 활용 가능
트랜잭션 범위 내에서 엔티티 조회 및 수정 시 자동으로 변경 감지가 동작하는 원리의 기반이 됩니다.
준영속 상태의 엔티티를 다시 영속 상태로 만들려면 어떻게 해야 하나요?
Q. 게시판 서비스에서 게시글 목록을 조회할 때 N+1 문제가 발생했습니다. 각 게시글마다 작성자 정보를 가져오는데 쿼리가 1 + N번 실행되고 있습니다. 이 문제의 원인과 해결 방법을 설명해주세요.
지연 로딩(Lazy Loading)과 연관 엔티티 조회 방식을 고려해보세요.
N+1 문제는 연관 엔티티를 지연 로딩으로 설정했을 때, 메인 엔티티 조회 후 각 엔티티마다 연관 엔티티를 개별적으로 조회하면서 발생합니다. 게시글 목록 조회 쿼리 1번 실행 후, 각 게시글의 작성자 정보를 가져오기 위해 N번의 추가 쿼리가 실행되는 것입니다. 해결 방법으로는 Fetch Join을 사용하여 JPQL에서 'join fetch'를 명시하거나, @EntityGraph 어노테이션으로 연관 엔티티를 한 번에 로딩할 수 있습니다. 또는 @BatchSize 어노테이션으로 IN 절을 사용한 배치 로딩을 적용할 수 있습니다. 상황에 따라 DTO 프로젝션으로 필요한 데이터만 조회하는 방법도 효과적입니다.
- • 지연 로딩 시 연관 엔티티 개별 조회로 발생
- • Fetch Join으로 한 번에 조회 가능
- • @EntityGraph, @BatchSize 등 다양한 해결책 존재
목록 조회 API에서 성능 저하의 가장 흔한 원인으로, 쿼리 수를 줄여 응답 시간을 개선하는 데 필수적입니다.
Fetch Join을 사용할 때 페이징 처리 시 주의해야 할 점은 무엇인가요?
Q. JPA에서 @Transactional 어노테이션의 역할과 readOnly 속성의 장점에 대해 설명해주세요.
트랜잭션 경계 설정과 조회 전용 작업에서의 최적화를 생각해보세요.
@Transactional은 선언적 트랜잭션을 제공하여 메서드 실행 전에 트랜잭션을 시작하고, 정상 종료 시 커밋, 예외 발생 시 롤백을 자동으로 처리합니다. 이를 통해 데이터 일관성을 보장하고 개발자가 트랜잭션 관리 코드를 직접 작성하지 않아도 됩니다. readOnly=true 속성은 조회 전용 트랜잭션임을 명시하여 영속성 컨텍스트의 변경 감지(Dirty Checking)를 수행하지 않아 성능이 향상됩니다. 또한 데이터베이스 레벨에서도 읽기 전용 힌트를 제공하여 최적화가 가능하며, 실수로 데이터를 수정하는 것을 방지할 수 있습니다. 일반적으로 조회 서비스 메서드에는 readOnly=true를 설정하는 것이 권장됩니다.
- • 트랜잭션의 시작, 커밋, 롤백 자동 처리
- • readOnly=true로 변경 감지 생략하여 성능 향상
- • 조회 전용 작업에 readOnly 설정 권장
서비스 계층에서 데이터 정합성을 보장하고, 조회 API의 성능을 최적화하는 데 필수적으로 사용됩니다.
@Transactional을 클래스 레벨과 메서드 레벨에 동시에 선언하면 어떻게 동작하나요?
Q. JPA에서 양방향 연관관계를 설정할 때 연관관계의 주인(Owner)을 정하는 이유와 mappedBy 속성의 역할을 설명해주세요.
외래키 관리 주체와 데이터베이스 테이블 구조를 고려해보세요.
양방향 연관관계에서 연관관계의 주인을 정하는 이유는 외래키를 관리할 엔티티를 명확히 하기 위함입니다. 데이터베이스 테이블에는 외래키가 한 쪽에만 존재하지만, 객체는 양쪽에서 참조가 가능하므로 혼란을 방지하기 위해 주인을 지정합니다. 연관관계의 주인만이 외래키를 등록, 수정할 수 있으며, 주인이 아닌 쪽은 읽기만 가능합니다. mappedBy 속성은 주인이 아닌 쪽에 설정하여 상대 엔티티의 어떤 필드에 의해 매핑되는지를 명시합니다. 일반적으로 외래키가 있는 테이블에 해당하는 엔티티를 주인으로 정하는 것이 권장되며, 다대일 관계에서는 다(N) 쪽이 주인이 됩니다.
- • 외래키 관리 주체를 명확히 하기 위해 주인 설정
- • 주인만 외래키 등록/수정 가능, 반대편은 읽기만
- • mappedBy는 주인이 아닌 쪽에 설정
회원과 주문, 게시글과 댓글 같은 양방향 관계 설정 시 데이터 정합성을 유지하는 데 필수적입니다.
양방향 연관관계에서 편의 메서드(Convenience Method)를 작성하는 이유는 무엇인가요?
Q. 상품 주문 서비스에서 동시에 여러 사용자가 같은 상품을 주문할 때 재고 차감 로직에서 데이터 정합성 문제가 발생했습니다. JPA에서 낙관적 락(Optimistic Lock)과 비관적 락(Pessimistic Lock)의 차이와 각각 어떤 상황에 적합한지 설명해주세요.
동시성 제어 방식과 충돌 빈도를 고려해보세요.
낙관적 락은 트랜잭션 충돌이 발생하지 않을 것으로 가정하고, @Version 어노테이션으로 버전 관리를 통해 수정 시점에 충돌을 감지합니다. 충돌 발생 시 OptimisticLockException이 발생하며, 애플리케이션에서 재시도 로직을 구현해야 합니다. 비관적 락은 트랜잭션 시작 시 데이터베이스 레벨에서 SELECT FOR UPDATE로 행을 잠가 다른 트랜잭션의 접근을 막습니다. 낙관적 락은 충돌이 적고 읽기가 많은 환경에 적합하며, 비관적 락은 충돌이 빈번하고 데이터 정합성이 중요한 환경에 적합합니다. 재고 차감처럼 동시성 충돌이 자주 발생하는 경우 비관적 락이나 분산 락을 고려하는 것이 좋습니다.
- • 낙관적 락은 버전 관리로 충돌 감지, 비관적 락은 행 잠금
- • 낙관적 락은 충돌 적은 환경, 비관적 락은 충돌 빈번한 환경에 적합
- • 재고 관리 같은 중요한 동시성 제어에는 비관적 락 권장
이커머스의 재고 관리, 좌석 예매 시스템 등 동시 접근이 많은 자원의 정합성을 보장하는 데 사용됩니다.
비관적 락의 PESSIMISTIC_READ, PESSIMISTIC_WRITE, PESSIMISTIC_FORCE_INCREMENT의 차이를 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!