JPA vs MyBatis, 실무에서 왜 이렇게 고민하게 될까?

Spring 기반 프로젝트를 하다 보면
JPA와 MyBatis 중 무엇을 선택할지 한 번쯤은 반드시 고민하게 된다.

보통 시작은 비슷하다.

• “JPA가 표준이니까”
• “엔티티 중심 설계가 좋아 보여서”
• “CRUD는 JPA가 빠르잖아”

그래서 많은 프로젝트가 자연스럽게 JPA로 출발한다.
하지만 운영을 겪기 시작하면,
이 선택에 대해 다시 고민하게 되는 순간이 온다.

이 글에서는
단순한 기능 비교가 아니라
실무 + 운영 관점에서 왜 이 고민이 반복되는지 정리해본다.

---

MyBatis에 대한 가장 흔한 오해

 “MyBatis는 쿼리에 비즈니스 로직을 넣는 방식이다”

이건 MyBatis의 문제가 아니라 설계 문제다.

• 조건 판단
• 정책 분기
• 상태 관리

이런 것들은 어디까지나 Service Layer의 책임이고,
MyBatis는 SQL 매핑 도구일 뿐이다.

MyBatis를 쓴다고 해서
비즈니스 로직을 XML에 넣어야 하는 건 아니다.

잘못된 사용 사례가
도구의 성격처럼 오해되고 있을 뿐이다.

---

JPA를 선택했을 때의 분명한 장점

JPA의 장점은 명확하다.

• 생산성 높음
• CRUD 구현 속도 빠름
• 도메인 중심 설계에 유리
• 코드량 감소

특히 초기 개발 속도는 JPA가 압도적이다.
그래서 신규 프로젝트에서 JPA를 먼저 선택하는 경우가 많다.

 

---

그런데 실무에서 고민이 시작되는 지점

문제는 운영 단계다.

이런 상황들이 겹치기 시작한다

• 조회 쿼리가 점점 복잡해짐
• 성능 이슈 발생
• N+1 문제
• Fetch 전략으로 인한 예측 불가한 쿼리
• 장애 상황에서 쿼리 추적이 어려움

이때부터 개발자는 느끼게 된다.

“개발할 땐 편했는데,
운영에서는 통제가 쉽지 않다.”

 

---

MyBatis가 다시 선택지로 올라오는 이유

MyBatis의 장점은 많지 않다.
하지만 운영 관점에서는 치명적인 장점 몇 개가 있다.

1. SQL이 그대로 보인다

• 실행되는 쿼리가 명확
• 테이블 관계 한눈에 파악 가능
• 운영 DB에서 바로 검증 가능

2. 복잡한 조회에 강하다

• 동적 쿼리 명확
• 통계/검색 조건 처리 용이
• JPQL보다 가독성 높은 경우가 많음

3. 성능 이슈 대응이 빠르다

• 쿼리 단위 튜닝 가능
• 실행 계획 분석 용이
• 장애 시 원인 파악 속도 빠름

---

그렇다고 MyBatis가 무조건 좋은 건 아니다

당연히 단점도 있다.

• CRUD 반복 코드 많음
• 생산성은 JPA보다 떨어짐
• 도메인 모델 중심 설계엔 불리

그래서 실무에서는 극단적인 선택보다 혼용이 많다.

 

---

실무에서의 현실적인 선택 기준

JPA가 잘 맞는 경우

• CRUD 위주의 서비스
• 비즈니스 로직 중심
• 빠른 기능 추가가 중요한 경우

MyBatis가 잘 맞는 경우

• 조회/통계 쿼리 비중 높음
• 트래픽 많음
• 운영 안정성과 장애 대응이 중요한 경우

정리하면,

JPA vs MyBatis는
기술 취향의 문제가 아니라
운영 전략의 문제다.

---

그렇다면 JPA로는 정말 커버가 안 될까?

실무에서 JPA의 한계로 자주 언급되는 케이스는
보통 두 가지다.

• 통계성 조회
• 복잡한 조회 로직

하지만 이 두 가지 모두
설계로 어느 정도 커버가 가능하다.

 

---

통계성 조회는 사실 JPA vs MyBatis의 문제가 아니다

대량 데이터 기반 통계성 조회는
애초에 OLTP 트랜잭션 쿼리와 성격이 다르다.

실무에서는 보통 다음과 같은 구조를 사용한다.

• 별도 통계 테이블 구성
• 배치 작업으로 집계 데이터 생성
• 조회 시에는 단순 select만 수행

이 경우에는
JPA든 MyBatis든
기술 선택이 핵심이 아니다.

>  문제는 기술이 아니라
데이터 모델링과 배치 전략이다.

 

---

복잡한 조회 로직은 Facade 패턴으로 완화할 수 있다

JPA에서 조회 로직이 복잡해질수록
Repository가 비대해지고
JPQL이나 QueryDSL이 난잡해지기 쉽다.

이때 실무에서 자주 사용하는 방법이
Facade 패턴이다.

• 여러 Repository 호출 조합
• 조회 전용 로직 분리
• 도메인 로직과 조회 로직 분리

이 방식으로
JPA의 복잡한 조회도 충분히 관리 가능하다.

---

그럼에도 고민이 사라지지 않는 이유

기술적으로 커버가 가능하더라도
마지막에 남는 질문은 이거다.

“운영 중 문제가 생겼을 때
얼마나 빠르게 원인을 파악할 수 있는가?”

이 지점에서
JPA와 MyBatis의 차이는
APM에서 더 명확하게 드러난다.