DB 스키마 중심 vs 도메인 중심: iBatis/MyBatis와 ORM 완전 비교

들어가며 

안녕하세요.

오늘은 백엔드 개발자라면 한 번쯤 고민해봤을 주제 SQL 매퍼(MyBatis)와 ORM(JPA)에 대해  다뤄보겠습니다.

 

MyBatis와 ORM(JPA), 어떤 기준으로 선택해야 할까요?

SQL 중심 설계와 도메인 중심 설계의 차이를 이해하면, 프로젝트 구조와 성능, 유지보수 요구사항에 맞춰 적절히 선택하고 활용할 수 있습니다.

 

정말 중요한 내용 같죠? 😅

이 글에서는 단순히 “편하다/불편하다”를 비교하는 수준을 넘어서, 설계 철학과 실제 개발 시 장단점까지 낱낱이 살펴보겠습니다

---

1. iBatis/MyBatis 란?

Batis와 MyBatis는 흔히 ORM으로 분류되지만, 실제로는 SQL Mapper 기술입니다.
개발자가 직접 SQL을 작성하고, 작성한 SQL과 객체를 매핑해 주는 방식입니다. SQL이 핵심이 되기 때문에 DB 스키마 설계가 먼저 이루어지고, SQL 작성과 최적화는 개발자의 몫입니다.

 

우선 iBatis와 MyBatis의 관계부터 알아보겠습니다.

---

iBatis와 MyBatis의 관계

 

iBatis는 2002년경 개발된 SQL Mapper 프레임워크로  Java 객체와 관계형 데이터베이스를 연결하기 위해 만들어졌습니다.

초기 iBatis는 XML 매핑 문법이 다소 복잡하고 직관적이지 않아 동적 SQL 처리나 유지보수 측면에서 한계가 있었습니다.

 

이러한 한계를 개선하기 위해 iBatis 3.x를 기반으로 포크된 프로젝트가 MyBatis입니다. MyBatis는 iBatis의 기본 구조와 설계 철학을 계승하면서 XML 매핑 문법을 직관적으로 개선하고, 어노테이션 기반 매핑을 지원하여 개발자가 상황에 맞게 유연하게 선택할 수 있도록 했습니다. 또한 동적 SQL 처리 기능을 강화하고 유지보수성과 확장성을 높여, 실무 환경에서 보다 편리하고 안정적으로 활용할 수 있는 프레임워크로 발전했습니다.

 

즉, MyBatis는 iBatis의 진화 버전으로, SQL Mapper 역할과 SQL 중심 설계 철학은 동일하지만 현대적인 개발 환경에서 더 편리하게 사용할 수 있도록 개선된 버전입니다.

 

MyBatis의 핵심은 자바 객체와 SQL을 매핑하기 때문에 DB 스키마 중심 설계를 하는 특징을 갖고 있습니다.

---

2. ORM이란?

ORM(Object-Relational Mapping)은 객체 지향 언어의 도메인 모델(엔티티)과 관계형 데이터베이스의 테이블 구조를 자동으로 연결해주는 프레임워크입니다. 도메인 모델만 정의하면 ORM이 내부적으로 SQL을 생성하고 테이블에 매핑해 주므로 개발자는 SQL을 직접 작성하지 않아도 됩니다.

 

즉, ORM은 객체 중심 설계 → SQL 자동 생성 → DB 반영이라는 흐름으로, 객체지향적인 설계와 개발 생산성을 높이는 데 초점을 맞춥니다.

 

ORM 환경에서는 객체 간의 협력과 관계를 먼저 고민하며 비즈니스 요구사항을 기반으로 객체 모델을 설계하면 ORM 프레임워크가 이를 바탕으로 DB 스키마를 생성하거나 매핑합니다. 이렇게 설계된 객체는 단순한 데이터 전달체를 넘어 스스로 비즈니스 로직을 수행할 수 있는 풍부한 도메인 모델이 됩니다.

 

또한 ORM은 상속, 연관관계(1:N, M:N), 다형성과 같은 객체지향 개념을 데이터베이스 관점이 아닌 객체 관점에서 유지할 수 있으며 반복적인 CRUD SQL 작성 부담을 줄여 개발자가 핵심 비즈니스 로직에 집중할 수 있도록 돕습니다.

---

3.  iBatis/MyBatis vs ORM(JPA/Hibernate): 설계 관점의 차이

iBatis/MyBatis: DB 스키마 중심 설계

iBatis/MyBatis는 SQL 중심 설계 철학에 따라 DB 테이블을 먼저 설계하고 이에 맞춰 SQL을 작성합니다. 객체 모델은 단순히 데이터를 전달하는 역할을 수행하며 비즈니스 로직은 주로 Service 레이어에서 SQL 호출 순서를 제어하며 처리됩니다. 이러한 접근 방식은 SQL 최적화와 복잡한 쿼리 제어에 강점이 있습니다.

 

특히 SQL 중심 설계에서는 데이터베이스 구조가 먼저 결정되기 때문에 제약조건이나 인덱스, 그리고 고도화된 DB 기능들을 객체보다 훨씬 세밀하게 반영할 수 있습니다. 개발자가 직접 SQL을 작성하고 조정할 수 있어, 성능 최적화나 특화된 쿼리 구현에 유리합니다.

 

다만 테이블 스키마가 변경되면 이에 의존하는 모든 XML과 자바 객체 코드를 수동으로 수정해야 하므로, 대규모 프로젝트에서는 강한 결합도가 발생할 수 있습니다.

---

ORM: 도메인 모델 중심 설계

반면 ORM은 객체 중심 설계 철학을 따르며 도메인 모델을 먼저 설계하고 ORM이 SQL과 DB 매핑을 처리합니다. 객체는 단순 데이터 전달체를 넘어 비즈니스 로직을 수행하는 풍부한 도메인 모델로 활용될 수 있습니다. 반복적인 CRUD SQL 작성 부담이 줄고 객체지향 패러다임을 그대로 유지하면서 개발 생산성을 높일 수 있습니다.

 

하지만 프레임워크가 생성하는 SQL이 항상 최적화되어 있는 것은 아니어서 경우에 따라 성능 상의 한계가 발생할 수 있습니다. 반복적인 CRUD SQL 작성 부담이 줄어들어 개발자는 핵심 비즈니스 로직에 더 집중할 수 있지만 복잡한 쿼리 제어나 세밀한 성능 조정이 필요한 경우에는 제한이 존재합니다.

 

이러한 한계를 최근에는 JPA와 QueryDSL, Criteria API 조합으로 보완할 수 있습니다.

이 기술들을 활용하면 복잡한 조회 조건이나 동적 쿼리도 객체 지향적 방식으로 안전하게 처리할 수 있어, SQL 직접 작성 없이도 대부분 요구사항을 만족할 수 있습니다.

---

요약하면  iBatis/MyBatis는 SQL과 DB 구조를 명시적으로 제어할 수 있어 성능 최적화와 특화 쿼리에 강점이 있으며, ORM은 객체 중심 설계와 유지보수 생산성, 반복 CRUD 자동화가 강점입니다.

---

4.  어떤 기준으로 선택해야 할까?

프로젝트에 맞는 기술을 선택할 때는, 성능 요구와 설계 중심을 기준으로 판단하는 것이 좋습니다.

• 성능 최적화가 중요한 경우: 대규모 데이터 처리나 복잡한 SQL 최적화가 필요하다면 iBatis/MyBatis가 적합합니다. 개발자가 직접 SQL을 작성하고 제어할 수 있어, DB 스키마 설계 의도를 정확히 반영하면서 성능을 세밀하게 조정할 수 있습니다.
• 유지보수와 객체지향 설계가 중요한 경우: 객체 중심 설계와 반복 CRUD, 개발 생산성이 중요하다면 ORM이 더 적합합니다. 도메인 모델을 중심으로 설계된 ORM 환경에서는 핵심 비즈니스 로직에 집중할 수 있으며, 반복적인 SQL 작성 부담이 줄어듭니다.

최근에는 JPA + QueryDSL/Criteria API 기술이 발전하여 ORM에서도 복잡한 동적 쿼리나 조건 검색을 안전하게 처리할 수 있습니다. 그러나 성능 최적화가 극도로 중요하거나, DB 레벨 제약조건, 인덱스, 파티셔닝 등을 그대로 반영해야 하거나, 기존 레거시 DB와 강하게 결합된 프로젝트에서는 여전히 iBatis/MyBatis 방식이 유리합니다.

따라서 JPA와 QueryDSL이 ORM의 장점을 보완하지만, 프로젝트 특성과 요구사항에 따라 SQL 직접 제어가 필요한 경우 MyBatis를 선택하는 것이 합리적입니다.

---

5. 정리

구분                   iBatis/MyBatis                                                            ORM (JPA/Hibernate)

설계 중심	DB 스키마 중심 (Data-Driven Design)	도메인 모델 중심 (Domain-Driven Design)
SQL 작성	개발자가 직접 작성	프레임워크가 자동 생성
객체 역할	단순 데이터 전달 (DTO/VO)	풍부한 도메인 모델, 로직 포함 가능
제어권	SQL 최적화 및 복잡 쿼리 직접 제어 가능	SQL 추상화, 객체 중심 트랜잭션 관리
유지보수	스키마 변경 시 SQL과 객체 수동 수정 필요	객체 설계 중심, 반복 CRUD 자동 처리
생산성	반복 작업 많음, DB 이해 필요	CRUD 자동화로 생산성 향상

iBatis/MyBatis는 SQL과 DB 중심의 명시적 제어가 강점이며 ORM은 객체 중심 설계로 생산성과 객체지향적 모델링이 강점입니다. 프로젝트 요구사항과 환경에 따라, 성능과 세밀한 SQL 제어가 필요하면 iBatis/MyBatis를, 도메인 중심 개발과 유지보수, 생산성을 중시하면 ORM을 선택하는 것이 합리적입니다.

---

마치며

이번 글에서는 iBatis/MyBatis와 ORM(JPA/Hibernate)의 설계 철학과 접근 방식, 장단점을 살펴보았습니다.

 

사실 저는 그동안 JPA만 알고 있어 MyBatis를 왜 쓰는지 이해가 잘 되지 않았습니다. 그러나 MyBatis의 SQL 중심 설계와 세밀한 성능 최적화 가능성을 알게 된 후, 두 기술이 가진 장단점과 특성을 이해하게 되었습니다.

 

이번 포스팅을 통해  프로젝트 요구사항과 설계 관점에 따라 MyBatis와 JPA를 적절히 선택하여 사용하는 것이 중요하다는 것을 배웠습니다. 단순히 편리함만을 기준으로 선택하기보다 각 기술의 강점을 살려 프로젝트에 맞게 활용하는 것이 중요할것 같습니다.