마이바티스의 장단점

MyBatis가 좋은 이유

1. SQL 제어권이 명확함
복잡한 쿼리, 조인, 인덱스 활용, 성능 튜닝 등을 개발자가 직접 세밀하게 제어할 수 있음. Query 플랜 보고 힌트 주거나, 특정 DB 기능 활용하기 좋음.


2. 동적 SQL 지원이 유연함
<if>, <choose>, <foreach> 같은 XML 기반 동적 SQL 요소가 있고, 파라미터 조합에 따라 SQL을 유연히 구성 가능.


3. 학습 진입 장벽이 낮은 편
SQL을 이미 잘 아는 개발자라면 “쿼리 작성 + 매핑” 구조가 익숙하고, JDBC 쪽 복잡한 boilerplate를 줄여주는 만큼 빠르게 사용할 수 있음.


4. DB 종속적인 기능 활용 가능
DB 벤더의 고유 기능(stored procedure, 함수, 힌트 등)을 쿼리에서 바로 쓸 수 있음. ORM보다 제약이 적음.


5. 명확한 매핑 & 코드 분리
SQL과 Java 코드를 분리(XML 또는 annotation), SQL 변경이 있을 때 Java 코드를 많이 건드리지 않아도 되는 구조 가능.




---

단점 / 제약

1. 반복 코드 & 매핑 유지 부담
CRUD 같은 단순 작업도 쿼리를 일일이 써야 하고, 테이블/컬럼 변경 시 매핑 XML이나 DTO/VO, Mapper 인터페이스 쪽도 같이 수정해야 함.


2. 런타임 에러 가능성
SQL 문법 오류, 컬럼 누락, 타입 매치 실패 등이 컴파일 타임에 잡히지 않고 실행 시점(runtime)에 발견되는 경우 많음.


3. DB 종속성 & 이식성 낮음
SQL 쿼리가 특정 DB 벤더 문법에 의존할 경우, DB 변경(예: MySQL → Oracle)시 손이 많이 감.


4. 객체 지향 기능 부족
1차 캐시, 쓰기 지연, 연관 관계 매핑(연관된 객체 간의 자동 fetch/join 등), 트랜잭션 경계 관리 등이 ORM (예: JPA/Hibernate) 만큼 자동화되어 있지 않아서, 이런 것들을 직접 고려해야 함.


5. 유지보수 측면의 복잡성
개발자 간 쿼리 작성 스타일이나 Mapper 구조가 잘 통일되지 않으면, 코드가 지저분해지거나 중복 많아져 버림. 헬퍼 매핑, 유틸, 공통 매개변수 처리 등이 잘 설계되어야 함.




---

ORM / JPA 대비 MyBatis가 나을/덜 나을 경우

상황 MyBatis가 유리한 경우 JPA/ORM 쪽이 유리한 경우

쿼리 복잡성 (조인 많음 / 서브쿼리 / DB 벤더 기능 활용) MyBatis
데이터 액세스 패턴이 단순 CRUD 중심, 도메인 간 관계 많은 객체 중심 모델 ORM
DB 변경 가능성 낮고 스키마 안정적인 경우 MyBatis
DB 종류 바꿀 가능성 있거나 벤더 독립성을 높여야 할 경우 ORM
퍼포먼스 미세 튜닝/쿼리 응답 시간 중요할 경우 MyBatis
생산성 / 유지보수 / 코드의 단순화 / 프로덕션에서 엔티티 기반 기능 활용(1차 캐시, lazy loading 등) 중요한 경우 ORM



---

MyBatis를 잘 쓰기 위한 고려 / 튜닝 포인트 (장애 예방 위주)

SQL 작성 시 인덱스, 데이터 양, JOIN 폭, 서브쿼리 vs 조인 vs 뷰 등을 충분히 고려

파라미터 바인딩 또는 프로젝션(projection) 최소화 (필요한 컬럼만 조회)

Mapper XML 구조 설계 시, 중복 쿼리, 공통 WHERE 절, 동적 SQL 패턴 추출 및 재사용

실행 계획(EXPLAIN), 쿼리 프로파일러 / APM 지표 활용

커넥션 풀 / 트랜잭션 경계 주의: MyBatis 쪽에서는 SqlSession 관리가 중요

페이징 처리는 limit/offset 또는 cursor, 필요한 경우 데이터 이동 전략 고려

캐시 활용: MyBatis 자체의 2차(cache) 설정 가능, 읽기 중심 쿼리에 대해 고려

테스트: SQL 변경 시 단위 테스트 또는 통합 테스트에서 쿼리 실행 확인



---

결론

MyBatis3는 매우 강력한 도구이고, 특히 다음 같은 프로젝트에서 좋은 선택이 될 가능성이 높습니다:

DB 중심 로직이 많거나 복잡한 쿼리를 많이 써야 하는 서비스

성능 및 응답시간 튜닝, 쿼리 제어가 중요한 경우

레거시 DB가 있고, 스키마나 테이블 설계가 자주 변경되지 않는 환경

벌크 작업, 보고서, 복잡 동적 쿼리, 최적화가 빈번한 경우


하지만, 객체 모델 중심의 개발, 스키마 변화 많음, 조직 규모 크고 유지보수자 많음, ORM의 편의성이 중요한 경우라면 MyBatis만 고집하는 것은 비효율일 수 있음. 실제로 많은 조직이 “기본 CRUD는 JPA/ORM + 복잡 쿼리/성능 중요 부분만 MyBatis 또는 네이티브 SQL” 혼합 전략을 쓰기도 하고요.