SQL Mapper(MyBatis) vs ORM(JPA)

백엔드 개발을 하다 보면 데이터베이스와의 연결이 필수적이다. 이때 데이터베이스와 상호작용하는 방식에는 대표적으로 SQL Mapper와 ORM(Object-Relational Mapping) 두 가지 접근법이 있다. SQL Mapper에서도 대표적인 프레임워크는 MyBatis가 있다. ORM 중에서도 Java 진영에서는 JPA(Java Persistence API)가 널리 사용된다. 

현재 백엔드에서 Java & Spring을 사용한다면 대부분 JPA를 많이 사용하는 것 같다. 진행하고 있는 프로젝트에서도 주로 JPA를 사용했다. 과연 SQL Mapper와 ORM의 차이가 무엇이며 JPA(ORM)를 실무에서 많이 사용하는 이유를 알아보고자 한다.

---

SQL Mapper

SQL Mapper는 개발자가 직접 SQL을 작성하여 데이터베이스와 상호작용하는 방식을 의미한다. 즉, SQL을 코드에서 직접 컨트롤할 수 있으며, 객체와 데이터베이스 간의 매핑을 일부 자동화하는 역할을 한다. SQL Mapper 중에서 대표적인 프레임워크는 MyBatis가 있다.

MyBatis 

MyBatis는 SQL Mapper 프레임워크로, SQL을 직접 작성하여 데이터베이스와 상호작용하는 방식이다. SQL 쿼리를 XML이나 어노테이션을 통해 정의하고, 파라미터 바인딩을 지원한다. SQL을 직접 컨트롤할 수 있도록 지원하는 프레임워크로 SQL 최적화가 필요하거나, 복잡한 쿼리를 자주 작성해야 할 때 유리하다.

 

MyBatis의 특징

• SQL을 직접 작성하여 제어 가능 -> 성능 최적화 가능
• XML 또는 어노테이션을 통해 SQL을 정의하고 실행함
• 특정 데이터베이스(DBMS)에 최적화된 SQL을 활용할 수 있음
• JDBC를 내부적으로 사용하지만, SQL 실행을 위한 코드(커넥션, 파라미터 설정, 결과 매핑 등)를 자동 처리하여 JDBC보다 간결한 코드 작성이 가능
• 객체 매핑을 지원하지만 자동화 수준이 낮음 (결과 매핑을 직접 설정해야 함)
• SQL을 직접 작성해야 하기 때문에 CRUD가 많아질수록 코드가 증가할 가능성이 있음

---

ORM(Object-Relational Mapping, 객체 관계 매핑)

ORM은 객체 지향 프로그래밍에서 데이터베이스의 데이터를 객체 형태로 다루기 위한 기술이다. ORM을 사용하면 SQL을 직접 작성하지 않고도 데이터베이스와 상호작용할 수 있다. ORM 중에서도 Java 진영에서는 JPA(Java Persistence API)가 가장 많이 사용된다.

JPA (Java Persistence API)

JPA(Java Persistence API)는 Java에서 ORM을 위한 표준 API다. 가장 많이 사용되는 Hibernate와 EclipseLink, DataNucleus 3가 구현체들이 존재하며, 이를 사용하면 SQL을 직접 작성하지 않고도 Java 객체를 이용해 데이터를 관리할 수 있다.

JPA는 애플리케이션과 JDBC 사이에서 추상화 계층 역할을 한다. 여기서 JDBC(Java Database Connectivity)는 Java에서 데이터베이스와 연결하고 SQL을 실행할 수 있도록 하는 표준 API이다. 즉, Java 애플리케이션과 RDBMS(관계형 데이터베이스) 사이의 다리 역할을 하는 API이다. 따라서 JPA 자체는 데이터베이스와 직접 통신하지 않고 JDBC API를 내부적으로 이용해 SQL을 실행하고, 데이터베이스와의 연결을 관리한다. JPA는 직접 JDBC를 사용하지 않지만, JPA 구현체가 내부적으로 JDBC를 사용하여 데이터베이스와 통신한다.

JPA의 특징

• SQL을 직접 작성할 필요 없이 객체(Entity) 중심으로 데이터를 관리
• SQL 대신 메서드 호출을 통해 데이터베이스 조작 가능
• 자동 매핑 기능 지원 (객체와 테이블 간의 변환을 자동 처리)
• 트랜잭션 및 캐싱 기능을 내장하고 있음

---

MyBatis(SQL Mapper)와 JPA(ORM)의 차이점

	MyBatis	JPA
개념	SQL Mapper (SQL 직접 작성)	ORM (객체와 DB 매핑)
데이터 접근 방식	SQL 기반 (쿼리를 직접 작성)	객체 지향적인 방식 (Entity 중심)
쿼리 작성 방식	XML 또는 어노테이션으로 SQL 직접 작성	JPQL(Java Persistence Query Language) 사용
유지보수성	SQL이 많아질수록 유지보수 어려움	코드 변경 시 SQL 수정 없이 객체만 변경, 객체 모델 변경 시 자동 반영 가능
트랜잭션 관리	직접 관리해야 함	Spring과 함께 사용하면 자동 관리 가능
DB 종속성	특정 DB 기능 활용 가능	DB 독립적 설계 가능
CRUD	SQL을 직접 작성해야 하므로 코드 증가	save(), findById() 같은 메서드로 간편한 CRUD 지원

 

JPA(ORM)를 이용하는 이유

비즈니스 로직 중심 개발

• JPA는 비즈니스 로직과 데이터 액세스를 분리할 수 있도록 지원
• SQL을 직접 작성하지 않고 비즈니스 로직을 객체(Entity) 기반으로 개발할 수 있음
• MyBatis는 SQL 중심적 접근 방식이므로, 데이터베이스에 종속적인 개발이 될 가능성이 높음

유지보수성과 확장성

• JPA는 SQL을 직접 작성하지 않으므로, 코드 수정 시 SQL을 변경할 필요가 없음
• 테이블 구조가 변경될 경우, MyBatis는 모든 SQL을 찾아서 수정해야 하지만, JPA는 엔티티 클래스만 수정하면 자동 반영됨
• 따라서 유지보수가 쉽고, 코드 변경이 일어났을 때 확장성이 좋음

객체 지향적인 데이터 관리

• MyBatis는 SQL을 직접 작성해야 하기 때문에, 객체 지향적 설계와 다소 거리가 있음
• JPA는 객체(Entity) 중심으로 설계되어 객체 지향 패러다임을 유지할 수 있음

기본적인 CRUD 자동화

• JPA는 CRUD 작업을 자동으로 처리하는 기능을 제공하며, 코드량이 적어짐
• MyBatis는 모든 CRUD SQL을 직접 작성해야 하므로, 코드 중복이 많아질 가능성이 높음

패러다임의 불일치 해결

• 객체(Object, OOP)와 관계형 데이터베이스(RDBMS)는 서로 데이터를 다루는 방식과 개념이 다르기 때문에 패러다임 불일치(Paradigm Mismatch) 문제가 발생
• JPA는 ORM을 통해 객체와 관계형 데이터베이스의 불일치를 해결하는 역할을 함
• MyBatis는 SQL 중심적이므로, 객체-관계 매핑을 직접 해야 함

데이터 접근 추상화 및 벤더 독립성

• JPA는 특정 데이터베이스 벤더(MySQL, Oracle, PostgreSQL 등)에 종속되지 않도록 설계됨
• MyBatis는 특정 DBMS의 SQL 문법을 직접 사용하기 때문에, DBMS 변경 시 SQL을 모두 수정해야 함

---

그래서 JPA가 짱인가?

JPA(ORM)는 유지보수성과 생산성이 중요한 프로젝트에 적합하며, 객체 지향적인 데이터 관리가 가능하기 때문에 많이 선택하는 것 같다. 하지만 JPA를 사용하기 위해서는 다양한 스펙과 사용법을 배워야하기 때문에 MyBatis를 그대로 사용하는 경우도 있는 것 같다. 또한  SQL 최적화가 필요하거나, 복잡한 쿼리가 많은 경우에는 여전히 사용된다고 한다. 따라서 JPA를 기본으로 사용하면서, 복잡한 SQL이 필요한 경우 MyBatis를 함께 사용하는 것이 좋을 것 같다.