Jpa on kastori

[Spring 완전 정복 #6] Java 데이터 접근 기술의 진화 — JDBC에서 JPA까지, 왜 바뀌었나

Tue, 19 May 2026 00:00:00 +0000

“JPA vs MyBatis 뭐가 더 낫나요?”

이 질문의 답을 제대로 하려면 두 기술이 각각 어떤 문제를 해결하기 위해 등장했는지 알아야 한다. 역사를 따라가면 답이 보인다.

1단계: 순수 JDBC — 모든 것을 직접

Java에서 DB에 접근하는 가장 원시적인 방법이다.

public Order findById(Long id) {
 Connection conn = null;
 PreparedStatement pstmt = null;
 ResultSet rs = null;

 try {
 conn = DriverManager.getConnection(URL, USER, PASSWORD);
 pstmt = conn.prepareStatement("SELECT * FROM orders WHERE id = ?");
 pstmt.setLong(1, id);
 rs = pstmt.executeQuery();

 if (rs.next()) {
 Order order = new Order();
 order.setId(rs.getLong("id"));
 order.setStatus(rs.getString("status"));
 return order;
 }
 return null;
 } catch (SQLException e) {
 throw new RuntimeException(e);
 } finally {
 // 안 닫으면 커넥션 누수 — 매 메서드마다 이 코드가 반복
 if (rs != null) try { rs.close(); } catch (SQLException e) {}
 if (pstmt != null) try { pstmt.close(); } catch (SQLException e) {}
 if (conn != null) try { conn.close(); } catch (SQLException e) {}
 }
}

이 코드의 문제점이 한눈에 보인다.

커넥션 획득 → 쿼리 실행 → 결과 매핑 → 리소스 반납 패턴이 모든 메서드에 반복된다.
finally에서 리소스를 수동으로 닫아야 한다. 빠트리면 커넥션 풀 고갈.
SQLException이 체크 예외라 모든 메서드가 예외를 처리하거나 throws해야 한다.

2단계: JdbcTemplate — 반복 코드 제거

Spring이 JDBC의 반복 코드를 추상화한 것이 JdbcTemplate이다.

@Repository
public class OrderRepository {
 private final JdbcTemplate jdbcTemplate;

 public Order findById(Long id) {
 return jdbcTemplate.queryForObject(
 "SELECT * FROM orders WHERE id = ?",
 (rs, rowNum) -> {
 Order order = new Order();
 order.setId(rs.getLong("id"));
 order.setStatus(rs.getString("status"));
 return order;
 },
 id
 );
 }
}

커넥션 획득/반납, try-finally, SQLException 처리가 사라졌다. Spring이 내부적으로 처리해준다. SQLException은 Spring의 DataAccessException(런타임 예외)으로 변환된다.

하지만 SQL은 여전히 직접 작성해야 하고, 결과를 객체에 매핑하는 RowMapper 코드도 직접 써야 한다.

3단계: MyBatis — SQL을 코드에서 분리

MyBatis는 SQL을 XML 파일로 분리하고, 결과 매핑을 자동화한다.

<!-- OrderMapper.xml -->
<mapper namespace="com.example.mapper.OrderMapper">
 <resultMap id="orderResultMap" type="Order">
 <id property="id" column="id"/>
 <result property="status" column="status"/>
 <result property="memberId" column="member_id"/>
 </resultMap>

 <select id="findById" resultMap="orderResultMap">
 SELECT id, status, member_id FROM orders WHERE id = #{id}
 </select>
</mapper>

@Mapper
public interface OrderMapper {
 Order findById(Long id); // 인터페이스만 선언하면 구현체 자동 생성
}

MyBatis의 진짜 강점은 동적 쿼리다.

<select id="findByCondition" resultMap="orderResultMap">
 SELECT * FROM orders
 <where>
 <if test="status != null">AND status = #{status}</if>
 <if test="memberId != null">AND member_id = #{memberId}</if>
 </where>
</select>

조건에 따라 WHERE절을 동적으로 구성하는 것이 직관적이다.

4단계: JPA — SQL을 아예 작성하지 않는다

JPA(ORM)는 SQL을 직접 작성하지 않고, 객체 간 관계를 그대로 DB에 매핑한다.

@Entity
public class Order {
 @Id @GeneratedValue
 private Long id;

 @ManyToOne(fetch = FetchType.LAZY)
 @JoinColumn(name = "member_id")
 private Member member;
}

// SQL 없이 CRUD
orderRepository.save(order); // INSERT 자동
orderRepository.findById(id); // SELECT 자동
order.setStatus(COMPLETED); // UPDATE 자동 (Dirty Checking)
orderRepository.delete(order); // DELETE 자동

DB 벤더가 바뀌어도 코드 변경이 없다. 객체 관계를 그대로 코드로 표현할 수 있다.

단점도 있다. 학습 곡선이 높고(영속성 컨텍스트, 지연 로딩, N+1 등), 복잡한 집계·통계 쿼리는 JPQL이나 QueryDSL이 필요하다.

4가지 기술 한눈에 비교

기준	JDBC	JdbcTemplate	MyBatis	JPA
SQL 작성	직접	직접	직접 (XML)	자동 생성
결과 매핑	수동	RowMapper	자동 (resultMap)	자동
복잡한 쿼리	자유롭게	자유롭게	자유롭게 (동적 쿼리 강점)	JPQL/QueryDSL 필요
DB 종속성	높음	높음	높음	낮음
학습 난이도	낮음	낮음	중간	높음
생산성	낮음	중간	중간	높음 (단순 CRUD)

JPA vs MyBatis — 이분법이 아니다

“JPA vs MyBatis"를 선택의 문제로 보는 건 틀린 프레임이다. 실무에서는 함께 쓰는 경우도 많고, 상황에 따라 선택이 다르다.

JPA가 유리한 경우: 비즈니스 로직이 복잡하고 객체 중심 설계가 중요한 서비스, 단순 CRUD가 많은 경우.

MyBatis가 유리한 경우: 복잡한 통계·집계 쿼리가 많은 경우, DBA와 협업하며 SQL을 직접 관리해야 하는 경우, 레거시 DB 스키마에 맞춰야 하는 경우.

실무에서 가장 많이 쓰는 조합:

단순 CRUD → JPA Repository
복잡한 조회 → QueryDSL (타입 안전한 JPQL 빌더)
통계·집계 쿼리 → Native Query 또는 MyBatis (별도 모듈)

JdbcTemplate은 여전히 쓴다

JPA 프로젝트에서도 JdbcTemplate이 필요한 상황이 있다.

@Repository
public class OrderBatchRepository {
 private final JdbcTemplate jdbcTemplate;

 // 수백만 건 상태 일괄 변경 — JPA Dirty Checking으로 하면 메모리 부족
 public void bulkUpdateStatus(String oldStatus, String newStatus) {
 jdbcTemplate.update(
 "UPDATE orders SET status = ? WHERE status = ?",
 newStatus, oldStatus
 );
 }
}

JPA @Modifying으로 안 되는 벌크 업데이트, Spring Batch 처리, 간단한 유틸리티 쿼리 등에서 여전히 활용된다.

마치며

각 기술의 진화 방향은 반복 코드 제거 → SQL 관리 편의 → 객체 중심 개발이었다. 이 흐름을 이해하면 “왜 JPA를 쓰는가"와 “언제 MyBatis가 더 나은가"를 맥락 있게 설명할 수 있다.

다음 편에서는 Spring Data JPA — 영속성 컨텍스트와 N+1 문제를 자세히 정리한다.

[Spring 완전 정복 #7] Spring Data JPA — 영속성 컨텍스트와 N+1 문제 완전 정리

Tue, 19 May 2026 00:00:00 +0000

JPA 면접 = 영속성 컨텍스트 + N+1

JPA 관련 면접 질문은 결국 두 가지로 수렴한다. “영속성 컨텍스트가 무엇인지 설명해보세요"와 “N+1 문제가 무엇이고 어떻게 해결하나요?”

이 두 가지를 이해하면 Dirty Checking, 지연 로딩, LazyInitializationException, N+1이 모두 연결된 하나의 그림으로 보인다.

JPA / Hibernate / Spring Data JPA 관계

JPA : Java ORM 표준 인터페이스 (명세)
Hibernate : JPA의 대표 구현체 (Spring Boot 기본)
Spring Data JPA : JPA를 더 편리하게 추상화한 Spring 모듈

개발자 코드 → Spring Data JPA → JPA → Hibernate → JDBC → DB

영속성 컨텍스트 — JPA의 핵심

영속성 컨텍스트는 Entity 객체를 관리하는 1차 저장소다. 트랜잭션당 하나씩 생성된다.

Entity 생명주기

비영속 : new Order() → 컨텍스트와 무관한 일반 객체
영속 : save() 또는 조회 후 → 컨텍스트가 관리, 변경 감지 적용
준영속 : 트랜잭션 종료 → 컨텍스트가 더 이상 관리 안 함
삭제 : delete() → DELETE 예약

1차 캐시

같은 트랜잭션 안에서 같은 Entity를 두 번 조회하면 DB를 두 번 치지 않는다.

Order order1 = orderRepository.findById(1L); // DB 조회
Order order2 = orderRepository.findById(1L); // 1차 캐시에서 반환 — DB 조회 없음

order1 == order2 // true — 동일 객체 보장

Dirty Checking — save() 없이 UPDATE

@Transactional
public void updateOrder(Long id, String newStatus) {
 Order order = orderRepository.findById(id).get(); // 영속 상태
 order.setStatus(newStatus); // setter만 호출
 // save() 없어도 트랜잭션 종료 시 UPDATE 자동 실행
}

영속성 컨텍스트는 Entity를 조회할 때 스냅샷을 저장한다. 트랜잭션 종료 시 현재 상태와 스냅샷을 비교해 변경이 있으면 UPDATE를 자동으로 실행한다. 이것이 Dirty Checking이다.

readOnly = true 트랜잭션에서는 스냅샷을 저장하지 않아 성능이 향상된다. 조회 메서드에 @Transactional(readOnly = true)를 붙이는 이유다.

지연 쓰기 (Write-behind)

@Transactional
public void saveOrders() {
 orderRepository.save(order1); // INSERT 예약
 orderRepository.save(order2); // INSERT 예약
 orderRepository.save(order3); // INSERT 예약
 // 트랜잭션 커밋 시 INSERT 3개 한번에 실행
}

쿼리를 모아뒀다가 커밋 직전에 한번에 DB로 보내 네트워크 왕복 횟수를 줄인다.

지연 로딩 — 필요할 때만 조회

@Entity
public class Order {
 @ManyToOne(fetch = FetchType.LAZY) // 지연 로딩
 @JoinColumn(name = "member_id")
 private Member member;
}

FetchType.LAZY는 Order를 조회해도 Member는 즉시 가져오지 않는다. order.getMember()를 호출하는 순간 DB 조회가 발생한다.

기본값 주의: @ManyToOne, @OneToOne의 기본값은 EAGER(즉시 로딩)다. 필요한 연관 데이터를 항상 함께 가져와 N+1을 유발할 수 있다. 항상 LAZY로 명시적으로 변경하는 것을 권장한다.

LazyInitializationException

@Transactional
public Order getOrder(Long id) {
 return orderRepository.findById(id).get();
} // 트랜잭션 종료 → 영속성 컨텍스트 닫힘

// 컨트롤러에서
Order order = orderService.getOrder(1L);
order.getMember().getName(); // LazyInitializationException!

트랜잭션이 끝나면 영속성 컨텍스트가 닫힌다. 이 상태에서 LAZY 로딩을 시도하면 컨텍스트가 없어 예외가 발생한다. 해결책은 트랜잭션 안에서 필요한 데이터를 미리 로딩하거나 Fetch Join을 쓰는 것이다.

N+1 문제 — JPA의 가장 흔한 함정

원인

List<Order> orders = orderRepository.findAll(); // 쿼리 1번 (N개 Order 조회)

for (Order order : orders) {
 System.out.println(order.getMember().getName()); // 주문마다 Member 조회 N번
}
// 총 1 + N번 쿼리

Order가 100개면 쿼리가 101번 실행된다. 이것이 N+1 문제다.

해결 방법 1: Fetch Join

@Query("SELECT o FROM Order o JOIN FETCH o.member")
List<Order> findAllWithMember();

-- 실행 쿼리 (1번)
SELECT o.*, m.* FROM orders o INNER JOIN member m ON o.member_id = m.id

Order와 Member를 JOIN 한 번으로 가져온다. 단, @OneToMany 컬렉션 Fetch Join + 페이징은 메모리에서 처리하므로 위험하다.

해결 방법 2: @EntityGraph

@EntityGraph(attributePaths = {"member"})
@Query("SELECT o FROM Order o")
List<Order> findAllWithMember();

Fetch Join과 동일하게 동작하지만 어노테이션으로 간결하게 표현.

해결 방법 3: @BatchSize (컬렉션 + 페이징)

@BatchSize(size = 100)
@OneToMany(mappedBy = "order")
private List<OrderItem> items;

-- N번 쿼리 대신 IN절로 묶어서 실행
SELECT * FROM order_item WHERE order_id IN (1, 2, 3, ..., 100)

default_batch_fetch_size를 전역 설정하면 모든 컬렉션에 적용된다.

spring:
 jpa:
 properties:
 hibernate:
 default_batch_fetch_size: 100

컬렉션 페이징 + 연관 데이터 조회에 가장 실용적인 해결책이다.

선택 기준

ToOne 관계 (ManyToOne, OneToOne) → Fetch Join / @EntityGraph
컬렉션 + 페이징 필요 → @BatchSize (전역 설정 권장)
복잡한 조회 → QueryDSL + Fetch Join

연관관계 주인 — mappedBy 규칙

양방향 관계에서 외래 키를 관리하는 쪽이 연관관계의 주인이다.

// Order (주인) — @JoinColumn 있음, 외래 키 실제 관리
@ManyToOne
@JoinColumn(name = "member_id")
private Member member;

// Member (주인 아님) — mappedBy로 읽기 전용 선언
@OneToMany(mappedBy = "member")
private List<Order> orders = new ArrayList<>();

주인에게만 값을 설정해야 DB에 반영된다.

order.setMember(member); // DB에 반영됨 ← 주인
member.getOrders().add(order); // DB 반영 안 됨 (읽기 전용)

실무 활용 — Entity Auditing

생성일시·수정일시를 자동 관리한다. 거의 모든 Entity에 적용하는 패턴이다.

@MappedSuperclass
@EntityListeners(AuditingEntityListener.class)
public abstract class BaseEntity {
 @CreatedDate
 @Column(updatable = false)
 private LocalDateTime createdAt;

 @LastModifiedDate
 private LocalDateTime updatedAt;
}

@Entity
public class Order extends BaseEntity { ... }

@SpringBootApplication에 @EnableJpaAuditing을 추가하면 된다.

마치며

영속성 컨텍스트를 이해하면 JPA의 동작 방식이 논리적으로 연결된다.

Dirty Checking: 스냅샷 비교 → save() 없이 UPDATE
1차 캐시: 같은 트랜잭션 내 동일 Entity 재조회 최적화
N+1: LAZY 로딩이 반복 호출될 때 발생 → Fetch Join, @BatchSize로 해결
LazyInitializationException: 트랜잭션 밖에서 LAZY 로딩 시도 → 트랜잭션 안에서 미리 로딩

다음 편에서는 Spring 쿼리 기술 — JPQL, Criteria API, QueryDSL을 비교한다.

[Spring 완전 정복 #8] QueryDSL이 실무 표준인 이유 — JPQL의 한계와 타입 안전한 동적 쿼리

Tue, 19 May 2026 00:00:00 +0000

JPQL의 불편함 — 오타가 런타임에 터진다

JPA Repository의 쿼리 메서드로 해결되지 않는 복잡한 조회는 @Query로 JPQL을 직접 작성한다.

@Query("SELECT o FROM Order o WHERE o.member.id = :memberId AND o.status = :status")
List<Order> findByMemberAndStatus(@Param("memberId") Long memberId,
 @Param("status") OrderStatus status);

이 방식의 문제가 있다.

컴파일 타임에 오류를 잡을 수 없다. o.member.id를 o.member.idx로 오타를 내도 컴파일은 된다. 런타임에 쿼리가 실행되는 순간에야 오류가 난다.

동적 쿼리가 불편하다. 조건이 있을 수도 없을 수도 있는 검색 기능을 JPQL로 만들려면 조건마다 쿼리 문자열을 조합해야 한다.

리팩터링에 취약하다. 엔티티 필드명을 바꾸면 문자열 안의 JPQL도 직접 찾아서 수정해야 한다.

QueryDSL은 이 문제를 해결한다.

QueryDSL이란

QueryDSL은 Java 코드로 SQL처럼 읽히는, 타입 안전한 쿼리를 작성하게 해주는 라이브러리다.

빌드 시 엔티티 클래스로부터 Q클래스를 자동 생성한다. Order 엔티티가 있으면 QOrder가 생성된다. Q클래스의 필드는 엔티티 필드와 1:1 대응한다.

QOrder order = QOrder.order;
QMember member = QMember.member;

// 자바 코드로 쿼리를 작성 — 컴파일 타임 타입 체크
queryFactory
 .selectFrom(order)
 .join(order.member, member).fetchJoin()
 .where(order.status.eq(OrderStatus.COMPLETED))
 .orderBy(order.createdAt.desc())
 .fetch();

order.status.eq(OrderStatus.COMPLETED) — order.status는 Q클래스의 타입 안전한 필드다. 오타를 내면 컴파일 오류가 발생한다.

기본 설정

<dependency>
 <groupId>com.querydsl</groupId>
 <artifactId>querydsl-jpa</artifactId>
 <classifier>jakarta</classifier>
</dependency>

@Configuration
public class QueryDslConfig {
 @Bean
 public JPAQueryFactory jpaQueryFactory(EntityManager em) {
 return new JPAQueryFactory(em);
 }
}

동적 쿼리 — QueryDSL의 핵심 강점

검색 조건이 선택적으로 적용되는 동적 쿼리가 QueryDSL의 진짜 강점이다.

@Repository
@RequiredArgsConstructor
public class OrderQueryRepository {
 private final JPAQueryFactory queryFactory;

 public List<Order> findByCondition(OrderSearchCondition cond) {
 return queryFactory
 .selectFrom(order)
 .join(order.member, member).fetchJoin()
 .where(
 statusEq(cond.getStatus()),
 memberIdEq(cond.getMemberId())
 )
 .fetch();
 }

 // BooleanExpression — null 반환 시 WHERE 조건에서 자동 제외
 private BooleanExpression statusEq(OrderStatus status) {
 return status != null ? order.status.eq(status) : null;
 }

 private BooleanExpression memberIdEq(Long memberId) {
 return memberId != null ? order.member.id.eq(memberId) : null;
 }
}

BooleanExpression을 반환하는 메서드로 분리하면 두 가지 이점이 있다. null을 반환하면 WHERE 조건에서 자동으로 제외된다. 그리고 이 조건 메서드를 여러 쿼리에서 재사용할 수 있다.

DTO 직접 조회 — 필요한 필드만

엔티티 전체가 아닌 필요한 컬럼만 DTO로 조회할 때 @QueryProjection을 사용한다.

@QueryProjection // DTO 생성자에 붙이면 QOrderSummary 자동 생성
public class OrderSummary {
 private Long orderId;
 private String memberName;
 private OrderStatus status;

 @QueryProjection
 public OrderSummary(Long orderId, String memberName, OrderStatus status) { ... }
}

public List<OrderSummary> findSummary(OrderStatus status) {
 return queryFactory
 .select(new QOrderSummary(
 order.id,
 order.member.name,
 order.status
 ))
 .from(order)
 .join(order.member, member)
 .where(statusEq(status))
 .fetch();
}

DTO 생성자 파라미터도 타입 안전하게 체크된다.

페이징 최적화

public Page<OrderSummary> findSummaryPage(OrderStatus status, Pageable pageable) {
 List<OrderSummary> content = queryFactory
 .select(new QOrderSummary(order.id, order.member.name, order.status))
 .from(order)
 .join(order.member, member)
 .where(statusEq(status))
 .offset(pageable.getOffset())
 .limit(pageable.getPageSize())
 .fetch();

 // count 쿼리 분리 (최적화)
 JPAQuery<Long> countQuery = queryFactory
 .select(order.count())
 .from(order)
 .where(statusEq(status));

 return PageableExecutionUtils.getPage(content, pageable, countQuery::fetchOne);
}

PageableExecutionUtils.getPage()는 마지막 페이지이거나 첫 페이지에서 결과가 pageSize보다 적으면 count 쿼리를 실행하지 않는다. 불필요한 COUNT 쿼리를 줄이는 최적화다.

Repository 구조 패턴

// 1. 기본 JPA Repository + 커스텀 인터페이스
public interface OrderRepository extends JpaRepository<Order, Long>,
 OrderRepositoryCustom { }

// 2. 커스텀 인터페이스 선언
public interface OrderRepositoryCustom {
 List<OrderSummary> findByCondition(OrderSearchCondition cond);
}

// 3. QueryDSL 구현체
@Repository
public class OrderRepositoryImpl implements OrderRepositoryCustom {
 private final JPAQueryFactory queryFactory;
 // QueryDSL 쿼리 구현
}

단순 CRUD는 JpaRepository가, 복잡한 조회는 OrderRepositoryImpl이 담당하는 역할 분리다.

언제 무엇을 쓸까

단순 조회 → JPA 쿼리 메서드 (findByStatus, findByMemberId)
조건 1~2개 → @Query (JPQL)
동적 쿼리 / 복잡한 조인 / DTO 조회 → QueryDSL ← 실무 표준
DB 특화 함수 / 성능 힌트 → Native Query
대용량 통계·배치 → MyBatis (별도 모듈)

기준	JPQL	QueryDSL	Native Query
타입 안전성	❌ 문자열	✅ Q클래스	❌ 문자열
동적 쿼리	불편	✅ BooleanExpression	불편
DB 특화 기능	❌	❌	✅
DTO 조회	new 키워드 (불편)	✅ @QueryProjection	수동 매핑

마치며

QueryDSL이 실무 표준이 된 이유는 명확하다. JPQL의 문자열 기반 한계를 타입 안전한 Java 코드로 대체하고, 동적 쿼리를 BooleanExpression 패턴으로 깔끔하게 처리한다.

다음 편에서는 Spring Security — 인증/인가와 JWT 구현을 정리한다.