MyBatis란? JDBC·JPA와 비교하고 공공 프로젝트에서 쓰는 이유

MyBatis란 무엇인가

MyBatis는 SQL을 직접 작성하고, 그 SQL과 자바 객체를 연결해 주는 SQL 매퍼 프레임워크다. 쿼리는 개발자가 XML이나 어노테이션에 직접 쓰고, MyBatis는 그 쿼리에 파라미터를 넣고 결과를 객체로 매핑하는 역할을 맡는다. JDBC를 직접 다룰 때 반복되는 지저분한 코드(Connection, PreparedStatement, ResultSet 처리)를 걷어내 주면서도, SQL 자체는 개발자가 100% 통제한다는 점이 특징이다.

여기서 자연스럽게 나오는 질문이 MyBatis JDBC JPA 차이다. 셋 다 자바에서 DB를 다루지만 접근 방식이 다르다. JDBC는 가장 낮은 수준의 표준 API, MyBatis는 SQL을 직접 쓰되 반복 코드를 줄여 주는 매퍼, JPA는 SQL을 거의 쓰지 않고 객체 중심으로 다루는 ORM이다.

JDBC·MyBatis·JPA 비교

구분	JDBC	MyBatis	JPA
SQL 작성	직접 작성	직접 작성	대부분 자동 생성
반복 코드	많음	적음	적음
SQL 통제력	높음	높음	낮음 (튜닝 시 JPQL/네이티브)
학습 난이도	낮음(개념)/번거로움(코드)	중간	높음
복잡 쿼리 대응	자유로움	자유로움	까다로움
객체 중심 설계	약함	약함	강함
대표 사용처	학습/단순 처리	공공 SI/SM, 레거시, 복잡 SQL	신규 서비스, 도메인 중심

JDBC와 MyBatis 비교

1. JDBC로 직접 짜면 생기는 반복

JDBC는 자바의 표준 DB 접근 API다. 동작 원리를 이해하는 데는 좋지만, 조회 하나를 위해 매번 같은 형태의 코드를 반복해야 한다.

// JDBC 직접 사용 (반복되는 부분이 많다)
Connection conn = null;
PreparedStatement pstmt = null;
ResultSet rs = null;
try {
    conn = dataSource.getConnection();
    pstmt = conn.prepareStatement("SELECT member_id, member_nm FROM member WHERE member_id = ?");
    pstmt.setString(1, memberId);
    rs = pstmt.executeQuery();
    while (rs.next()) {
        // rs.getString(...) 으로 일일이 꺼내 객체에 담음
    }
} catch (SQLException e) {
    // 예외 처리
} finally {
    // rs, pstmt, conn 닫기 (빠뜨리면 커넥션 누수)
}

커넥션을 닫는 코드를 빠뜨리면 커넥션 누수로 운영 장애까지 이어진다. 이 반복과 실수 위험을 줄여 주는 게 MyBatis다.

2. MyBatis는 SQL만 남기고 나머지를 걷어낸다

MyBatis를 쓰면 위 JDBC 코드의 반복 부분이 사라지고, 개발자는 SQL과 매핑에만 집중한다.

<!-- MemberMapper.xml -->
<select id="selectMember" parameterType="string" resultType="com.example.vo.MemberVO">
    SELECT member_id, member_nm
    FROM   member
    WHERE  member_id = #{memberId}
</select>

// 호출 코드는 한 줄
MemberVO member = memberMapper.selectMember(memberId);

Connection이나 ResultSet을 직접 다룰 필요가 없고, 커넥션 반납도 프레임워크가 처리한다. 그러면서 SQL은 그대로 눈에 보인다. JDBC의 통제력은 유지하면서 번거로움만 덜어낸 셈이다.

MyBatis와 JPA 비교

1. JPA는 SQL을 거의 쓰지 않는다

JPA는 객체와 테이블을 매핑해 두면 SQL을 자동으로 만들어 실행하는 ORM이다. 단순 CRUD는 메서드 호출만으로 처리되고, 객체 중심으로 도메인을 설계할 수 있다. 반면 SQL이 자동 생성되다 보니, 복잡한 통계 쿼리나 튜닝이 필요한 경우 JPQL이나 네이티브 쿼리로 따로 풀어야 한다.

2. 통제력과 생산성의 트레이드오프

둘의 차이는 결국 "SQL을 누가 쓰느냐"다. MyBatis는 개발자가 직접 써서 통제력이 높고, 복잡한 쿼리나 DB 특화 기능(Oracle 힌트, 분석 함수 등)을 자유롭게 넣을 수 있다. JPA는 반복 작업 생산성이 높고 객체지향 설계에 강하지만, SQL을 세밀하게 다뤄야 하는 상황에서는 오히려 우회가 늘어난다. 어느 쪽이 우월하다기보다 프로젝트 성격에 따라 갈린다.

공공 프로젝트에서 MyBatis를 쓰는 이유

공공기관 SI/SM 프로젝트, 특히 전자정부 표준프레임워크(eGovFramework) 기반 사업에서는 MyBatis(또는 그 전신인 iBatis 계열)가 사실상 기본처럼 쓰인다. 이유는 기술적 우열보다 현장 환경에 있다.

• 복잡하고 방대한 SQL — 공공 업무는 통계, 정산, 다중 조인이 많아 SQL을 직접 통제하는 방식이 유리하다.
• 기존 DB 스키마 고정 — 이미 운영 중인 테이블 구조에 맞춰 개발하는 경우가 대부분이라, 객체 중심으로 스키마를 설계하는 JPA의 강점이 살기 어렵다.
• 유지보수 인력 교체 — SM 단계에서 담당자가 자주 바뀌는데, SQL이 그대로 보이는 MyBatis가 인수인계와 장애 추적에 유리하다.
• 표준 가이드와 산출물 — eGovFramework 가이드와 과거 사업 산출물이 MyBatis 기준으로 축적돼 있어 일관성을 유지하기 쉽다.
• DBA와의 협업 — 쿼리 리뷰나 튜닝을 DBA가 직접 보는 경우가 많아, SQL이 명시적으로 드러나는 편을 선호한다.

정리하면, 신규 서비스를 객체 중심으로 빠르게 만드는 환경이라면 JPA가 맞을 수 있지만, 기존 스키마·복잡한 SQL·잦은 담당자 교체라는 공공 SI/SM의 조건에서는 MyBatis의 "SQL이 보인다"는 특성이 실질적인 장점이 된다.

초급 개발자가 헷갈리는 부분

• "MyBatis가 JPA보다 구식"이라는 단정. 용도가 다른 도구이고, 환경에 따라 선택이 갈린다. 우열 문제가 아니다.
• MyBatis도 동적 SQL(if, foreach 등)로 꽤 유연하게 쿼리를 조립할 수 있다는 점을 모르고 단순 매퍼로만 여기는 경우.
• JPA를 쓰면 SQL을 아예 몰라도 된다는 오해. 실무에서는 결국 생성된 SQL과 성능을 봐야 한다.
• 공공 프로젝트에 JPA를 도입하려다 기존 스키마·산출물 체계와 충돌해 오히려 비용이 커지는 경우.

FAQ

Q1. MyBatis와 JPA 중 무엇을 먼저 배워야 하나요?

취업/투입 대상이 공공 SI/SM이나 레거시 유지보수라면 MyBatis가 우선이다. 신규 서비스 회사를 목표로 한다면 JPA 비중이 높다. 둘 다 알아 두면 선택 폭이 넓어진다.

Q2. MyBatis는 JDBC를 대체하나요?

완전히 대체한다기보다 JDBC 위에서 동작하며 반복 코드를 줄여 준다. 내부적으로는 여전히 JDBC를 사용한다.

Q3. 공공 프로젝트는 JPA를 절대 안 쓰나요?

절대는 아니다. 신규 사업이나 일부 모듈에서 JPA를 쓰는 경우도 늘고 있다. 다만 기존 스키마와 산출물 체계 때문에 MyBatis 비중이 여전히 높다.

Q4. MyBatis로 복잡한 쿼리도 다 처리되나요?

SQL을 직접 쓰므로 복잡한 조인, 통계, DB 특화 함수 모두 자유롭게 쓸 수 있다. 동적 SQL로 조건 조립도 가능하다.

Q5. MyBatis JDBC JPA 차이를 한 문장으로요?

JDBC는 직접 다 짠다, MyBatis는 SQL만 직접 쓰고 나머지는 맡긴다, JPA는 SQL도 거의 맡긴다.

정리

MyBatis JDBC JPA 차이는 "SQL을 누가, 얼마나 직접 쓰느냐"로 요약된다. JDBC는 반복이 많아 번거롭고, MyBatis는 SQL 통제력을 유지하면서 반복을 줄이며, JPA는 객체 중심으로 SQL 작성 자체를 최소화한다. 공공 SI/SM과 eGovFramework 환경에서 MyBatis가 표준처럼 쓰이는 건 기술이 더 뛰어나서가 아니라, 기존 스키마·복잡한 SQL·잦은 담당자 교체라는 현장 조건에 잘 맞기 때문이다. 도구의 우열을 따지기보다, 지금 투입된 프로젝트가 어떤 성격인지 보고 거기에 맞는 방식을 이해하는 것이 실무에서는 더 중요하다.