JPA vs MyBatis 차이! 자바 데이터 접근 어떤 걸 선택할까

핵심 요약

자바에서 DB에 접근할 때 마주치는 두 방향, JPA(ORM)와 MyBatis(SQL 매퍼)를 비교합니다. 결론부터 말하면 정형화된 CRUD·도메인 중심 개발은 JPA, 복잡한 쿼리·기존 DB 연동·세밀한 SQL 제어는 MyBatis가 강합니다. 그리고 현실에서는 둘을 함께 쓰는 경우도 아주 많습니다.

빌드 도구(Gradle vs Maven), 패키징(JAR vs WAR)에 이어, 이번엔 백엔드 개발에서 빠질 수 없는 데이터 접근 기술 이야기입니다. Repository나 DAO를 만들 때 "객체로 다룰 것인가, SQL로 다룰 것인가"라는 선택이 있습니다. 바로 JPA와 MyBatis입니다. 특히 국내 환경에서 자주 부딪히는 갈림길이라 정리해봤습니다.

먼저 용어 정리

비교에 들어가기 전에, JPA 쪽은 용어가 겹겹이 쌓여 있어 헷갈리기 쉽습니다. 관계부터 정리하면 이렇습니다.

• JPA: 자바 객체와 DB 테이블을 매핑하는 ORM 표준(스펙). 현재는 Jakarta Persistence로 이름이 바뀌었습니다. 그 자체는 인터페이스·규약입니다.
• Hibernate: JPA 스펙을 실제로 구현한 가장 널리 쓰이는 ORM 프레임워크입니다.
• Spring Data JPA: JPA/Hibernate 위에 한 겹 더 얹어, Repository 인터페이스만으로 CRUD를 처리하게 해주는 스프링 모듈입니다.
• MyBatis: ORM이 아니라, 객체와 SQL문을 직접 매핑하는 SQL 매퍼 프레임워크입니다.

한 줄로 정리하면, JPA(+Hibernate)는 "객체를 중심에 두고 SQL을 자동 생성"하고, MyBatis는 "SQL을 직접 쓰고 그 결과를 객체에 매핑"합니다. 출발점이 반대입니다.

방향 1 — JPA: 객체 중심의 생산성

ORM객체 중심

엔티티(객체)를 정의하면 JPA가 SQL을 대신 생성해줍니다. 개발자는 SQL보다 도메인 모델에 집중하게 됩니다. Spring Data JPA를 쓰면 메서드 이름만으로 쿼리가 만들어집니다.

public interface UserRepository extends JpaRepository<User, Long> {
    List<User> findByName(String name);
}

findByName이라는 메서드 이름만으로 SELECT ... WHERE name = ? 쿼리가 자동 생성됩니다. 기본 CRUD는 코드를 거의 쓰지 않아도 됩니다.

JPA가 강한 이유

• 반복적인 CRUD 코드가 크게 줄어 생산성이 높습니다.
• 도메인 객체 중심으로 설계해 비즈니스 로직이 깔끔해집니다.
• 스키마가 자주 바뀌어도 엔티티 수정으로 비교적 쉽게 따라갑니다.
• 특정 DB 벤더에 덜 종속적이라 이식성이 좋습니다.

JPA의 한계

• 영속성 컨텍스트, 지연 로딩(lazy loading), N+1 문제 등 고유 개념의 학습 곡선이 있습니다.
• 복잡한 통계·집계 쿼리는 JPQL/QueryDSL로 풀기 번거롭고, 의도대로 SQL이 안 나올 때가 있습니다.
• "어떤 SQL이 나가는지" 추적이 한 단계 멀어집니다.

방향 2 — MyBatis: SQL 중심의 제어력

SQL 매퍼SQL 중심

SQL을 직접 작성하고, 그 결과를 객체에 매핑합니다. 쿼리 한 줄 한 줄을 개발자가 통제하므로, 복잡한 쿼리나 튜닝이 필요한 상황에서 강력합니다.

<select id="findByName" resultType="User">
  SELECT id, name, email
  FROM users
  WHERE name = #{name}
</select>

보다시피 실제 나가는 SQL이 그대로 눈앞에 있습니다. 복잡한 조인, 동적 쿼리, 통계성 조회처럼 "SQL을 정교하게 다뤄야 하는" 작업에서 MyBatis의 가치가 분명해집니다.

MyBatis가 강한 이유

• 작성한 SQL이 그대로 실행되어, 쿼리 동작이 명확하고 튜닝이 쉽습니다.
• 복잡한 리포트·집계·통계 화면에 유리합니다.
• 이미 존재하는 DB(레거시 스키마)에 얹어 쓰기 좋습니다.
• SQL에 익숙한 팀이라면 진입 장벽이 거의 없습니다. 단위 테스트 시 모킹도 비교적 단순합니다.

MyBatis의 한계

• CRUD가 많아질수록 반복적인 SQL·매핑 작성 부담이 커집니다.
• DB 종속성이 높아 벤더 변경 시 SQL 수정이 필요할 수 있습니다.
• 객체 중심 설계의 이점을 자동으로 얻기는 어렵습니다.

국내 환경 참고

해외에서는 JPA/Hibernate 채택 비중이 높은 편이지만, 국내 금융·공공·SI 환경에서는 MyBatis가 여전히 표준에 가깝게 쓰입니다. 복잡한 정산·집계 쿼리가 많고, SQL을 직접 통제·리뷰해야 하는 문화가 자리 잡았기 때문입니다. 그래서 국내 개발자는 두 기술을 모두 다룰 줄 아는 것이 현실적으로 유리합니다.

한눈에 보는 비교

항목	JPA (Hibernate)	MyBatis
성격	ORM (객체 중심)	SQL 매퍼 (SQL 중심)
SQL 작성	자동 생성	직접 작성
CRUD 생산성	높음	보통
복잡 쿼리 제어	다소 불리	매우 강함
학습 곡선	가파름 (고유 개념)	완만함 (SQL 기반)
DB 종속성	낮음	높음
국내 채택	증가 추세	여전히 강세

선택 기준 — 무엇을 고를까

"무엇이 더 우월하냐"보다 "내 프로젝트 성격이 무엇이냐"로 접근하는 게 맞습니다. 대략 이렇게 나뉩니다.

• JPA가 어울리는 경우: CRUD 중심의 업무 애플리케이션, 도메인 모델이 중요한 신규 서비스, 스키마가 자주 바뀌는 환경, 빠른 개발 생산성이 필요한 경우.
• MyBatis가 어울리는 경우: 복잡한 통계·리포트·집계 화면, 정교한 SQL 튜닝이 필요한 경우, 기존 레거시 DB에 연동하는 경우, 팀의 SQL 숙련도가 높은 경우.

현실적인 정답 — 함께 쓰기

실무에서는 둘 중 하나만 고집하기보다 강점에 맞춰 병행하는 구성이 흔합니다. 예를 들어 회원 가입·기본 CRUD는 JPA로, 매출 집계 리포트 같은 복잡한 조회는 MyBatis로 나눠 쓰는 식입니다. 스프링부트에서는 두 기술을 한 프로젝트에 함께 설정해 쓸 수 있습니다.

정리

객체 중심으로 빠르게 만들고 싶다면 JPA, SQL을 손에 쥐고 정교하게 다루고 싶다면 MyBatis입니다. 어느 한쪽이 절대 우위는 아니며, 작은 기능 하나에 먼저 적용해보고 팀에 맞는 쪽을 정하는 게 가장 확실합니다. 특히 국내에서 일한다면 둘 다 익혀두는 것이 현실적인 강점이 됩니다.

개인적으로는 신규 도메인은 JPA로 생산성을 가져가되, 복잡한 조회가 몰리는 영역만 MyBatis로 떼어내는 조합이 가장 균형 잡혀 있다고 봅니다. 도구를 진영 싸움처럼 볼 필요 없이, 각자 잘하는 자리에 배치하면 됩니다.

본 글의 예시는 스프링부트 3.x / Spring Data JPA 기준이며, 버전과 설정에 따라 세부 동작이 달라질 수 있습니다. 실제 적용 전 공식 문서를 확인하시기 바랍니다.