마이바티스

XML 매퍼 설정은 마이바티스에서 SQL 문과 자바 객체 간의 매핑 관계를 정의하는 핵심적인 방법이다. 이 방식은 애너테이션 기반 매핑과 함께 마이바티스의 두 주요 구성 방식을 이룬다. 개발자는 주로 XML 파일을 사용하여 데이터베이스 CRUD 작업에 필요한 SQL 명령문, 매개변수 타입, 결과 매핑 규칙을 상세히 기술한다.

XML 매퍼 파일의 구조는 정해진 DTD나 XML 스키마를 따른다. 파일 내에는 일반적으로 <select>, <insert>, <update>, <delete>와 같은 요소들이 정의되며, 각 요소는 고유한 id를 가지고 특정 자바 메서드와 연결된다. parameterType 속성은 메서드에 전달되는 인자의 타입을, resultType 또는 더 복잡한 resultMap은 쿼리 실행 결과가 매핑될 자바 객체의 타입이나 구조를 지정한다.

이 XML 파일은 마이바티스 설정 파일(mybatis-config.xml)에서 리소스 경로로 등록되거나, 매퍼 인터페이스와 동일한 클래스패스 위치 및 네임스페이스를 가지도록 배치된다. 마이바티스 세션은 이 XML 파일을 읽어 파싱하고, 애플리케이션 실행 시 정의된 SQL 문과 매핑 정보를 런타임에 사용할 수 있도록 준비한다. 이를 통해 JDBC 코드의 반복 작업과 하드 코딩된 SQL 문을 효과적으로 분리할 수 있다.

XML을 이용한 설정 방식은 복잡한 다중 테이블 조인 쿼리나 동적 SQL(<if>, <foreach> 등)을 구성할 때 특히 강력하다. 또한, SQL 문을 자바 소스 코드와 완전히 분리함으로써 가독성을 높이고, SQL 수정 시 재컴파일 없이 XML 파일만 변경하면 되는 유연성을 제공한다.

마이바티스는 SQL 문과 자바 객체를 연결하는 방법으로 XML 외에도 애너테이션 기반 매핑을 지원한다. 이 방식은 인터페이스의 메서드에 직접 SQL 쿼리를 애너테이션으로 정의하는 것으로, 복잡한 동적 SQL을 다루기 어려운 단순한 쿼리에 적합하다.

주요 애너테이션으로는 @Select, @Insert, @Update, @Delete가 있으며, 각각 CRUD 연산에 대응하는 SQL을 지정한다. @Results와 @Result 애너테이션을 사용하면 데이터베이스 컬럼과 자바빈즈 프로퍼티 간의 복잡한 매핑 관계를 정의할 수 있다. 또한, @Param 애너테이션은 메서드의 매개변수를 SQL 문 내의 플레이스홀더에 바인딩하는 데 사용된다.

애너테이션 기반 매핑의 장점은 SQL이 자바 코드와 가까이 위치하여 직관적이고 관리가 편리하다는 점이다. 그러나 SQL 문이 길어지거나 동적 조건이 많아질 경우 가독성이 떨어지고 유지보수가 어려워질 수 있다. 따라서 복잡한 매핑이나 다중 테이블 조인, 동적 쿼리가 필요한 경우에는 XML 매퍼를 사용하는 것이 일반적이다. 두 방식은 공존할 수 있으며, 하나의 매퍼 인터페이스 내에서 혼합하여 사용하는 것도 가능하다.

마이바티스는 SQL 문을 실행하는 데 있어 XML 매퍼나 애너테이션을 사용하는 방법 외에도, 핵심 API를 직접 호출하는 저수준의 실행 방식을 제공한다. 이 방식은 SqlSession 객체의 메서드를 직접 사용하여 매퍼 파일에 정의된 SQL 문의 네임스페이스와 아이디를 문자열로 지정해 실행하는 것이다.

예를 들어, session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101)과 같은 형태로 호출한다. 여기서 첫 번째 인자는 실행할 SQL 문의 완전한 식별자(네임스페이스 + 아이디)이며, 두 번째 인자는 SQL에 전달할 파라미터 객체이다. selectOne 외에도 selectList, insert, update, delete 등 다양한 CRUD 작업을 수행하는 메서드가 존재한다.

이러한 API 직접 실행 방식은 동적 SQL이나 복잡한 로직을 처리할 때 유연성을 제공하지만, 일반적으로는 타입 안전성이 떨어지고 컴파일 시점에 오류를 검출하기 어렵다는 단점이 있다. 따라서 대부분의 현대적인 마이바티스 애플리케이션에서는 인터페이스와 매퍼를 바인딩하는 getMapper() 방식을 선호한다.

그럼에도 불구하고, 프로그램적으로 SQL 문의 아이디를 구성해야 하는 특수한 경우나 매우 동적인 쿼리 실행이 필요한 상황에서는 이 저수준 API가 유용하게 활용될 수 있다. 이는 마이바티스가 개발자에게 JDBC의 번거로움을 줄이면서도 필요시 저수준 제어권을 유지할 수 있도록 하는 설계 철학의 일면을 보여준다.

마이바티스의 핵심 구성 요소는 크게 설정 파일, 매퍼 인터페이스, SQL 세션, SQL 세션 팩토리로 구분된다. 이 요소들은 자바 애플리케이션과 데이터베이스 간의 상호작용을 구성하고 제어하는 역할을 한다.

가장 기본이 되는 구성 요소는 SqlSessionFactoryBuilder이다. 이 빌더는 XML 형식의 메인 설정 파일(일반적으로 mybatis-config.xml)을 읽어들여 SqlSessionFactory를 생성한다. 설정 파일에는 데이터베이스 연결 정보(JDBC 드라이버, URL, 사용자명 등), 트랜잭션 관리 방식, 그리고 애플리케이션에서 사용할 매퍼 파일의 위치 등이 정의되어 있다.

생성된 SqlSessionFactory는 SqlSession을 생산하는 공장 역할을 한다. SqlSession은 마이바티스의 핵심 API로, 실제로 SQL 문을 실행하고 트랜잭션을 관리하며 매퍼 인터페이스의 프록시 객체를 얻는 데 사용된다. 애플리케이션은 이 세션을 통해 데이터베이스와의 모든 통신을 수행한다.

실질적인 SQL 명령과 객체 관계 매핑은 매퍼 인터페이스와 그에 대응하는 XML 파일 또는 애너테이션에 정의된다. 매퍼 인터페이스는 자바 인터페이스로 선언되며, 각 메서드는 실행할 SQL 문과 연결된다. 이 연결은 동일한 네임스페이스를 가진 XML 파일의 <select>, <insert> 등의 구문이나, 인터페이스 메서드에 직접 부착된 @Select, @Insert 등의 애너테이션을 통해 이루어진다.

마이바티스의 동작 원리는 크게 설정 로드, SQL 실행, 결과 매핑의 세 단계로 요약할 수 있다. 애플리케이션이 시작될 때 마이바티스는 주 설정 파일(mybatis-config.xml)을 읽어 데이터베이스 연결 정보와 트랜잭션 관리 방식, 그리고 매퍼 파일의 위치 등을 구성한다. 이어서 지정된 경로의 XML 매퍼 파일이나 애너테이션이 달린 자바 인터페이스를 파싱하여 내부에 SQL 명령과 그에 대한 메타데이터를 저장한다.

구체적인 SQL 실행 과정은 다음과 같다. 애플리케이션 코드에서 SqlSession 객체를 통해 selectOne() 같은 API를 직접 호출하거나, 더 일반적으로는 getMapper() 메서드로 매퍼 인터페이스의 프록시 객체를 얻는다. 이 프록시 객체의 메서드가 호출되면, 마이바티스는 미리 파싱해 둔 정보를 바탕으로 해당 메서드와 연결된 SQL을 찾아낸다. 이후 JDBC를 이용해 실제 데이터베이스에 쿼리를 실행하고, 그 결과로 받아온 ResultSet을 처리한다.

마이바티스의 핵심인 결과 매핑 단계에서는 실행된 SQL의 결과가 자바 객체로 변환된다. 개발자가 XML이나 애너테이션으로 정의한 resultType 또는 resultMap 설정을 따라, 데이터베이스 컬럼의 값이 대상 객체의 프로퍼티에 자동으로 채워진다. 이 과정에서 복잡한 객체 관계 매핑이나 중첩 객체의 처리도 지원한다. 이러한 방식으로 마이바티스는 개발자가 반복적인 JDBC 코드와 수동 ResultSet 처리를 작성할 필요 없이, SQL과 객체 지향 코드 사이의 간극을 효과적으로 메워준다.

마이바티스는 원래 iBATIS라는 이름으로 시작된 프로젝트이다. iBATIS는 2001년에 클린턴 비긴(Clinton Begin)에 의해 개발되었으며, '인터넷'과 '아바타'를 합친 'iBATIS'라는 이름을 사용했다. 이 프레임워크는 SQL 매핑 라이브러리로서 자바 개발자들이 관계형 데이터베이스와 상호작용하는 방식을 단순화하는 것을 목표로 했다. iBATIS 2.x 버전까지는 상당한 인기를 끌며 JDBC를 직접 사용하는 번거로움을 줄이고 객체와 데이터베이스 테이블 간의 매핑을 지원했다.

그러나 2010년에 프로젝트가 아파치 소프트웨어 재단으로 이관되면서, 프레임워크는 근본적인 재설계와 리팩토링을 거치게 된다. 이 과정에서 프로젝트 이름이 '마이바티스(MyBatis)'로 변경되었고, 버전은 iBATIS 3.0으로 출시되었다. 이름 변경의 주요 이유는 아파치 재단의 상표 정책과 기존 iBATIS 2.x 코드베이스와의 명확한 차별화에 있었다. 따라서 마이바티스는 iBATIS의 공식적인 후속 버전이자 현대적인 진화체로 볼 수 있다.

마이바티스로의 전환은 단순한 이름 변경을 넘어서는 중요한 아키텍처적 개선을 동반했다. 인터페이스와 애너테이션을 통한 매퍼 정의 지원이 강화되었고, 동적 SQL 처리가 더욱 강력해졌으며, 스프링 프레임워크와의 통합이 원활해졌다. 결과적으로, 오늘날 'iBATIS'라는 용어는 주로 2010년 이전의 레거시 버전을 지칭할 때 사용되며, 현재 활발히 개발되고 있는 최신 버전은 '마이바티스'라고 부른다. 이 역사적 배경 때문에 두 이름이 혼용되어 언급되기도 한다.

하이버네이트는 자바를 위한 강력한 객체 관계 매핑 프레임워크이다. JPA의 대표적인 구현체로, 개발자가 SQL을 직접 작성하지 않고도 자바 객체와 관계형 데이터베이스 테이블 간의 매핑을 선언적으로 처리할 수 있게 해준다. 하이버네이트는 내부적으로 JDBC를 추상화하여, 객체를 데이터베이스에 저장, 조회, 수정, 삭제하는 복잡한 작업을 단순화한다.

마이바티스가 SQL 매핑에 초점을 맞춘 반면, 하이버네이트는 객체 모델 중심의 접근 방식을 취한다는 점이 주요 차이점이다. 하이버네이트는 HQL이라는 객체 지향 쿼리 언어를 제공하며, 캐싱과 지연 로딩 같은 고급 기능을 내장하고 있어 대규모 복잡한 애플리케이션 개발에 적합하다. 또한 스프링 프레임워크와의 통합이 매우 원활하게 지원된다.

두 프레임워크는 각각 다른 철학을 지니고 있어 선택은 프로젝트 요구사항에 따라 달라진다. 하이버네이트는 생산성과 객체 지향 설계를 중시하며, 데이터베이스 독립성과 복잡한 도메인 모델 관리에 강점을 보인다. 반면 마이바티스는 세밀한 SQL 제어와 기존 복잡한 SQL 또는 저장 프로시저를 활용해야 하는 상황, 그리고 간결한 설정을 선호할 때 유리하다.

JPA(Java Persistence API)는 자바 ORM 기술의 표준 명세이다. 자바 커뮤니티 프로세스를 통해 정의된 이 API는 관계형 데이터베이스의 데이터를 자바 객체에 매핑하고 관리하기 위한 인터페이스와 규칙을 제공한다. JPA 자체는 구현체가 아닌 명세서에 불과하며, 하이버네이트, 이클립스링크, DataNucleus 등이 JPA 명세를 구현한 대표적인 퍼시스턴스 프레임워크이다.

마이바티스와 JPA의 핵심적인 접근 방식 차이는, 마이바티스가 SQL 매핑에 초점을 맞춘 SQL 매퍼라면, JPA는 객체 모델 자체에 더 깊게 관여하는 완전한 ORM 프레임워크라는 점이다. JPA는 엔티티 클래스와 애너테이션을 사용하여 객체와 테이블 간의 매핑을 정의하며, JPQL(Java Persistence Query Language)이라는 객체지향 쿼리 언어를 제공한다. 이를 통해 개발자는 데이터베이스 벤더에 종속되지 않는 추상화된 쿼리를 작성할 수 있다.

JPA를 사용하면 영속성 컨텍스트와 같은 내부 메커니즘을 통해 객체의 상태 변화를 자동으로 감지하고 데이터베이스에 동기화하는 것이 가능하다. 이는 캐싱, 지연 로딩, 더티 체킹 등 복잡한 기능을 표준화된 방식으로 제공함으로써 생산성을 높이는 장점이 있다. 반면, 이러한 높은 수준의 추상화는 복잡한 SQL이나 데이터베이스 고유 기능을 사용해야 할 때 제약이 될 수 있으며, 이 점에서 개발자가 SQL을 직접 제어할 수 있는 마이바티스와 차별화된다.

스프링 프레임워크 생태계에서는 스프링 데이터 JPA 모듈을 통해 JPA 사용이 더욱 편리해졌다. 마이바티스 역시 스프링과의 통합을 잘 지원하므로, 프로젝트의 요구사항, 팀의 숙련도, 복잡한 쿼리의 비중 등을 고려하여 JPA 표준 ORM과 마이바티스 SQL 매퍼 중 하나를 선택하거나, 경우에 따라 둘을 혼용하기도 한다.

마이바티스는 자바 애플리케이션에서 데이터베이스와 상호작용하기 위한 퍼시스턴스 프레임워크이다. 이 프레임워크의 핵심 역할은 개발자가 직접 작성한 SQL 문과 자바 객체 간의 매핑을 간편하게 처리하는 데 있다. 마이바티스는 JDBC를 내부적으로 사용하여 데이터베이스에 접근하지만, JDBC를 직접 사용할 때 발생하는 반복적이고 번거로운 코드 작성을 크게 줄여준다.

JDBC를 직접 사용하면 Connection, PreparedStatement, ResultSet 등의 객체를 수동으로 관리하고, SQL 실행 후 얻은 결과를 일일이 자바 객체로 변환하는 작업이 필요하다. 마이바티스는 이러한 저수준의 상세 작업을 추상화하여, 개발자는 SQL과 그 결과를 매핑할 객체의 관계에만 집중할 수 있게 한다. 즉, SQL 실행 로직과 데이터 변환 로직을 분리함으로써 코드의 가독성과 유지보수성을 향상시킨다.

마이바티스는 XML 파일 또는 애너테이션을 통해 SQL 문을 정의하고, 입력 파라미터와 출력 결과를 자바 빈즈나 간단한 객체에 자동으로 바인딩한다. 이는 복잡한 JDBC 코드를 캡슐화하여 데이터베이스 접근 계층의 코드를 깔끔하게 정리하는 효과가 있다. 따라서 마이바티스는 JDBC의 강력한 제어력을 유지하면서도 그 사용 편의성을 극대화하는 중간 계층 프레임워크라고 볼 수 있다.

마이바티스는 스프링 프레임워크와의 통합을 공식적으로 지원하며, 이는 자바 기반 애플리케이션 개발에서 매우 일반적인 조합이다. 스프링의 의존성 주입 컨테이너와 마이바티스의 SQL 매핑 기능을 결합함으로써 개발자는 복잡한 JDBC 코드를 작성하지 않고도 데이터 접근 계층을 쉽게 구성하고 관리할 수 있다. 이를 위해 마이바티스는 mybatis-spring이라는 전용 통합 모듈을 제공한다.

이 통합 모듈의 핵심은 SqlSessionFactoryBean이다. 개발자는 스프링 설정 파일(또는 자바 설정)에서 이 빈을 정의하여 데이터소스를 주입하고, 매퍼 XML 파일의 위치를 지정하며, 마이바티스의 전역 구성을 설정할 수 있다. 그 후, 매퍼 인터페이스를 스프링 빈으로 직접 등록할 수 있어, 다른 스프링 빈에 의존성 주입으로 주입하여 사용하는 것이 가능해진다. 이 과정에서 스프링의 트랜잭션 관리 기능과도 완벽하게 연동되어, 선언적 트랜잭션을 마이바티스 작업에 적용할 수 있다.

이러한 통합의 주요 장점은 애플리케이션 아키텍처의 일관성을 유지할 수 있다는 점이다. 마이바티스 매퍼는 평범한 자바 인터페이스로, 스프링의 제어의 역전 원칙에 따라 다른 서비스 빈과 동일한 방식으로 관리된다. 결과적으로 개발자는 스프링 부트와 같은 현대적 프레임워크와 함께 사용할 때 최소한의 설정으로 마이바티스를 빠르게 통합하고, 관계형 데이터베이스와의 상호작용에 집중할 수 있게 된다.