MyBatis와 JPA 차이

현재 다니고 있는 회사 실무에서는 Mybatis 주로 사용하고 있습니다. Mybatis와 JPA차이에 대해서 알아볼려고 합니다.

구글 트랜드로 보면 전 세계적으로 Mybatis보다 JPA를 많이 사용중인걸로 보입니다. 한국에서도 아직 Mybatis를 많이 사용중인걸로 확인되네요, 레거시한 서비스들이 많이 있다는 거겠죠 😢

1. ORM이란?

ORM(Object Relational Mapping)은 어플리케이션의 객체와 관계형 데이터 베이스(RDB)의 테이블 간에 매핑을 자동화 해주는 도구입니다. 이 기술의 핵심 목표는 개발자가 SQL문법 대신 자바와 같은 프로그래밍 언어를 사용하여 DB에 접근할 수 있도록 돕는 것을 말합니다. 이를 통해 개발 언어의 일관성과 코드의 가독성이 향상되며, 결과적으로 개발 생산성을 높이고 개발 비용을 절감하는 이점을 제공합니다. ORM은 save() 나 find() 와 같은 객체 메서드 호출을 통해 DB에 데이터를 저장하거나 조회하는 과정을 추상화합니다.

ORM 나온 배경

ORM이 필수적으로 자리 잡은 배경에는 객체지향 프로그래밍(OOP)과 관계형 데이터베이스(RDB)간의 근본적인 불일치, 즉 패러다임 불일치문제가 있습니다. OOP는 데이터와 행위를 함께 갖는 객체를 중심으로 하는 반면, RDB는 데이터를 테이블 형태로 구조화하여 저장합니다. 이 두 시스템의 지향점이 다르기 때문에 여러가지 문제가 발생하여, 개발자는 이 간극을 메우기 위해 개발 비용이 증가합니다.

• 상속과 다형성

  OOP는 상속을 통해 코드 재사용과 확장성을 제공하지만, RDB는 이러한 계층적 구조를 직접적으로 지원하지 않습니다. ORM은 클래스 계층을 DB 테이블과 매핑하는 다양한 전략을 제공하여 이 문제를 해결합니다.

• 식별성 문제

  객체의 동일성(== 비교)은 인스턴스의 메모리 주소에 의해 결정되는 반면, DB의 row의 동일성은 주로 Primay Key에 의해 결정됩니다. ORM은 같은 DB row를 조회 할때 마다 새로운 인스턴스를 생성하는 것을 방지하고, 단일 트랜잭션내에서 동일한 row가 항상 같은 객체 인스턴스로 매핑되도록 보장하여 객체의 동일성을 보장합니다.

• 데이터 네비게이션

  OOP에서는 객체 참조를 통해 다른 객체로 손쉽게 이동할 수 있습니다. 예를 들어, 회원 객체에서 소속 팀 객체로 접근하는 것이 직관적입니다. 하지만 DB에서는 JOIN 연산을 통해서만 관련 데이터에 접근할 수 있습니다. ORM은 이러한 복잡한 조인 연산을 자동으로 처리하며, 필요에 따라 연관된 객체를 로드하는 지연 로딩(Lazy Loading)또는 즉시 로딩(Eager Loading) 전략을 제공하여 애플리케이션 성능을 최적화 할 수 있습니다.

2. Mybatis란?

Mybatis는 ORM의 철학을 일부 공유하지만, SQL을 직접 작성하고 관리하는 것을 핵심으로 하는 SQL Mapper Framework입니다. 이는 객체와 RDB를 매핑하되, 그 중심에는 SQL을 두는 Mybatis만의 접근 방식을 형성합니다.

Mybatis는 순수한 JDBC(Java Database Connect) API를 사용하여 DB에 접근할 때 많은 양의 반복적인코드(예: Connection , Statment ,ResultSet 관리 및 예외 처리)를 추상화하여 개발자의 부담을 크게 줄여줍니다. Mybatis의 주요 목적은 SQL 자체의 체계적인 관리와 SQL의 입출력 데이터와 자바 객체간의 효율적인 변환 방법을 제공하는데 있습니다.

Mybatis 원리 알아보기

3. JPA란?

JPA(Java Persistence API)는 자바에서 ORM 기술을 사용하기 위한 표준 명세(Standard Specification)입니다. 이는 JPA 자체가 라이브러리가 아니라 인터페이스와 같은 추상적인 개념이며, 실제 구현체로는 Hibernate, EclipseLink 등이 존재 합니다.

JPA 원리 알아보기

4. Mybatis와 JPA 비교

Mybatis와 JPA는 DB 영속성이라는 공통 목표를 추구하지만, 이를 달성하는 방법론에서 극명한 차이를 보입니다. 이러한 차이는 프로젝트의 생산성, 유지보수성, 성능에 직접적인 영향을 미칩니다.

구분	Mybatis (SQL 매퍼)	JPA (ORM 표준)
중심 철학	SQL 중심	객체 중심
쿼리 방식	개발자가 직접 작성한 네이티브 SQL	객체 지향 쿼리 언어인 JPQL 또는 메서드
설정 방식	주로 XML 파일에 SQL 정의	어노테이션을 사용한 매핑
핵심 메커니즘	개발자 작성 SQL + 매퍼 인터페이스	영속성 컨텍스트 (1차 캐시, 쓰기 지연, 변경 감지)
DBMS 종속성	높음 (특정 DB 문법 사용)	낮음 (DB 방언 자동 처리)
생산성 (CRUD)	낮음 (수동 작성)	매우 높음 (자동화된 기능 제공)

Mybatis는 SQL의 강력한 기능을 그대로 활용하는 데 초점을 맞춥니다. 이는 개발자가 쿼리에 대한 완전한 제어권을 가질 수 있게 합니다. 반면, JPA는 SQL을 추상화하고 객체지향 패러다임을 극대화하여 개발자가 비즈니스 로직에만 집중할 수있도록 돕습니다.

개발 생산성 및 유지 보수성

• 코드량 및 생산성

  JPA는 기본적인 CRUD 기능이 JpaRepository 인터페이스를 통해 자동화되어 있어 별도의 구현이 필요 없습니다. 이는 단순 반복적인 작업을 최소화하여 개발 생산성을 압도적으로 향상시킵니다. Mybatis는 이와 달리 간단한 CRUD 쿼리도 모두 개발자가 수동으로 작성해야하는 번거로움이 있습니다.

• 유지보수 용이성

  JPA는 DB에 대한 종속성이 낮으므로, 필드 추가/삭제와 같은 데이터 모델 변경시 엔티티 클래스만 수정하면 JPA가 자동으로 변경사항을 감지하여 UPDATE 쿼리를 생성합니다. 반면, Mybatis는 스키마 변경시 관련 SQL 쿼리문을 모두 찾아 수동으로 수정해야 하므로 유지보수 비용이 큽니다.

성능, 복잡성 및 제어 능력

• SQL 제어의 한계

  Mybatis는 SQL에 능숙한 개발자에게 오히려 개발 시간을 단축시킬 수 있습니다. 특히 복잡한 JOIN 이나 동적 쿼리, 서브 쿼리, 스토어드 프로시저 사용 등 세밀한 제어가 필요한 경우 Mybatis의 동적 SQL 기능(if , choose , forearch 등)이 매우 유용합니다. JPA도 복잡한 쿼리를 위해 JPQL, QueryDSL, 혹은 네이티브 쿼리를 지원하지만, 이경우 JPA의 핵심 장점인 객체지향성이 희석될 수 있습니다.

• 성능 최적화

  JPA는 1차 캐시와 쓰기 지연 기능 덕분에 불필요한 DB 접근을 줄이고 I/O를 최적화하여 높은 성능을 낼 수 있습니다. 그러나 이는 개발자가 JPA의 내부 동작 원리를 정확히 이해하고 올바르게 사용했을 때의 이야기입니다. 반면, Mybatis는 개발자가 직접 쿼리를 작성하므로, 개발자의 SQL 튜닝 능력에 따라 성능이 좌우됩니다. 이로 인해 Mybatis는 복잡한 쿼리의 성능 예측 및 최적화가 더 투명하고 용이하다는 평가를 받습니다.

5. Mybatis와 JPA 선택 기준

선택 기준은 트렌드나 개인의 선호가 아닌, 프로젝트의 구체적인 요구사항과 팀의 역량에 기반해야 합니다.

JPA 선택해야하는 이유

1. 신규 프로젝트
2. 단수 CRUD 중심의 비즈니스 로직
3. 객체지향적 설계 지향

Mybatis 선택해야하는 이유

1. 레거시 시스템 유지보수 및 확장
2. 고도로 복잡한 쿼리