들어가며
현업을 하면서 최대 관심사는 기존 Native Query들을 마이그레이션하는 작업이였다.
물론 회사에서 웹파트에서는 Mybatis를 쓰는 경우도 많았지만 최근 자바진영은 JPA를
주로 사용하고 있기도 하고, 여러가지 장점들이 많아서 JPA를 선호하는 입장에서
JPA를 정리해본다.
JPA가 뭐고, 어떻게 쓰고 이런 내용은 사실 김영한님 강의 와 책
그리고 잘 정리된 블로그와 Spring 공식문서만 잘봐도 학습하는데
크게 문제가 없기 때문에 차근차근 필요할때마다 정리해볼거고
이유와 근거 그리고 방법에 대한 포스팅을 주로 할 예정이다.
MyBatis vs JPA
1. MyBatis
- 특징
- SQL Mapper 프레임워크
- 개발자가 직접 SQL을 작성
- XML이나 어노테이션으로 SQL 매핑
- SQL의 자유도와 복잡한 쿼리 처리에 강점
- 장점
- 복잡한 SQL 작성에 용이
- 데이터베이스에 종속적인 기능을 활용 가능
- 특정 쿼리에 최적화된 성능 제공
- SQL을 직접 제어할 수 있어, 성능 튜닝이 필요할 때 유리
- 단점
- SQL을 직접 작성해야 하므로 생산성이 낮을 수 있음
- 유지보수 시 SQL 파일을 별도로 관리해야 함
- 객체-관계 매핑(ORM) 기능이 부족 (매퍼 필요)
- 사용 사례
- 복잡한 조회 쿼리가 많은 경우
- 기존 SQL을 활용해야 하는 경우
- 데이터베이스에 종속적인 기능을 활용해야 할 때
2. JPA (Java Persistence API)
- 특징
- ORM (Object-Relational Mapping) 프레임워크
- 객체를 통해 데이터베이스를 다룸 (SQL을 직접 작성하지 않아도 됨)
- Hibernate, EclipseLink 같은 구현체 존재
- 엔티티(Entity)를 사용하여 객체와 데이터베이스 테이블을 자동 매핑
- 장점
- 코드의 생산성이 높아짐 (CRUD 메서드 자동 생성)
- 유지보수가 쉬움 (객체 중심으로 개발 가능)
- 1차 캐시, 지연 로딩, 트랜잭션 관리 등 다양한 기능 제공
- DB 변경에 상대적으로 유연 (추상화된 Repository 사용)
- 단점
- 복잡한 쿼리는 @Query 또는 QueryDSL을 사용해야 함
- 학습 곡선이 다소 있음 (특히 연관 관계 설정)
- 자동 생성되는 쿼리의 성능을 제어하기 어려운 경우도 있음
- 사용 사례
- CRUD 비즈니스 로직이 많은 경우
- 도메인 중심 설계(DDD, Domain-Driven Design)를 사용할 때
- 데이터 변경이 많고 트랜잭션 관리가 중요한 경우
현업에서 두개다 사용해본 결과 개인적으로 Mybatis는 이전 선배 개발자 (ORM 이전) 분들은
선호할만한 프레임워크였다. ORM 과 객체지향적 개발이 약간 떨어지는 부분이 느껴졌지만
기존 DB를 활용하거나 제대로 설계되지 않은 DB구조들 , 자바같은 언어의 경험보다는
SQL경험이 많은 경우에는 더 용의할 것으로 느껴졌다.
다만, 위에서 정리하였듯 모던한 트렌드에 맞춘 ORM이라기 보다는 SQL을 네이티브하게 하는 것보다는
더 편리하게 접근하게 쓸 수 있음에 초점이 되어있는 느낌을 강하게 받았다.
JPA는 객체를 대상으로 DAO를 구축하고 이를 활용함으로써 복잡도를 낮추면서
스프링 프레임워크의 의존성 주입(Dependency Injection, DI)
및 제어의 역전(Inversion of Control, IoC) 을 적극 활용할 수 있다.
이를 통해 언어 중심(객체 중심)의 개발 이 가능하여, 비즈니스 로직에 집중할 수 있는 장점을 경험해보면
생산성 차이에서 확연한 차이를 느낄 수 있었다.
나 또한, 실무를 하며 여러 테이블구조들을 보고 왔지만, 복잡한 쿼리를 사용할 일은 사실 매우 적다.
10개 작성하면 한개 나올까 정도였다. 물론 회바회니까 그냥 내 경험이다.
최근 트랜드인 MSA기반의 아키텍처 구조에서는 더욱 그러한다고 생각된다.
다만, 예전 개발 방식의 맞는 구조들, 현실과 타협한 부분들 , SI식 하드코딩인 테이블에 콜룸을 의미없이 몇십개 몇백개씩 박고 쓰는 방법에서는 처음에야 간단해도 성능 고도화 , 점점늘어나는 추가조건에 대한 유지보수가 되기 시작하면 오히려 쿼리복잡성이 증가하는 것도 경험하였다.
사실 이러한 부분이 한국 개발 문화에서의 문제이기도 한데, 생산성 (그냥 시간안주고 빨리해달라는 식)이
초반 개발에서는 이점이 있어서 이렇게 뒤 생각안하고 던지듯이 만들어 두는데
제대로 된 개발이며 , 뒤에 유지보수할 사람들을 생각해보자 내가 그런 입장이였는데 정말 죽을 맛이였고,
지켜지지 않는 규칙들과 처리 방안이 정말힘들었다.
그래서 언어자체로 컨트롤할 수 있는 JPA를 선호하며 김영한님의 JPA 책에 서두에 본인또한 같은 경험을 하였고, 이렇게 일하기 싫어서 JPA를 도입했다는 점이 굉장히 공감가는 부분이였다.