"편리하다"로 끝내는지, 추상화 비용까지 보고 도입 조건을 말할 수 있는지를 가른다.
JPA를 쓰면 객체 그래프 중심으로 데이터 접근을 설계하고 영속성·변경 감지·트랜잭션 연동 같은 반복 작업을 프레임워크에 맡길 수 있다. 특히 Spring Data JPA는 리포지토리 인터페이스, 메서드명 기반 쿼리, @Query, Pageable·Auditing 같은 공통 요구를 한 번에 묶어 DAO 구현 부담을 크게 낮춘다. 단 영속성 컨텍스트·지연 로딩·N+1 같은 _프레임워크가 가린 비용_이 따라오므로, 도메인 중심 이득과 추상화 비용을 함께 본 뒤 도입을 결정한다. 즉 "빠르다 vs 느리다"가 아니라 "어디까지 추상화에 맡길지"의 판단이다.
JDBC/MyBatis 프로젝트를 JPA로 전환한 경험이 있다면 줄어든 코드량과 새로 생긴 쿼리 튜닝 이슈를 균형 있게 연결할 수 있다
복잡 통계 쿼리만 QueryDSL/Native로 빼본 적이 있다면 _층별 선택_의 기준을 답변 후크로 쓸 수 있다
팀 리포지토리 컨벤션을 정해본 적이 있다면 어떤 케이스에 @Query를 허용했는지로 말할 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.