Sign in Subscribe
Brain Loading...

[멋쟁이사자처럼부트캠프] 클라우드 엔지니어링 6기 JDBC 따잇! MyBatis

李

• 5 min read
https://namu.wiki/w/%ED%94%8C%EB%9D%BC%EC%9D%B4%EA%B3%A4
ⓒNintendo/Creatures Inc./GAME FREAK inc. (참조: Internet Meme / 나무위키)

오늘字

데이터베이스와 통신하기 위해 순수 JDBC를 처음 접했을 때, 가장 먼저 드는 생각은 "단순한 쿼리 하나를 보내는 데 이렇게 많은 준비 과정이 필요한가?"입니다. 매번 DB 접속 정보를 입력하고, 드라이버를 로딩하며, Connection을 맺고 자원을 반납하는 과정은 구조적으로 복잡하고 가독성을 떨어뜨립니다. 이러한 JDBC의 상위호환(저는 그렇게 느꼈습니다.) MyBatis을 단계별로 비교해 보겠습니다.

두 기술의 역할과 특징

구분JDBCMyBatis
개념자바에서 DB에 접속하고 SQL을 실행하기 위한 기본 APIJDBC 사용을 편리하고 효율적으로 만들어주는 SQL 매핑 프레임워크
SQL 관리자바 소스 코드 내부에 String 형태로 하드코딩.xml 파일로 SQL을 분리하여 외부에서 관리
데이터 매핑ResultSet을 통해 개발자가 직접 객체에 값을 세팅SQL 실행 결과를 자동으로 DTO 객체에 바인딩
연결 관리매번 Connection 생성 및 close() 등 외부 자원 수동 반납 필요설정된 정보를 바탕으로 프레임워크가 자원 관리를 자동화
  • 라이브러리 vs 프레임워크: .jar 파일이 외부에서 만들어진 클래스들의 묶음(라이브러리)이라면, 프레임워크는 프로그램 개발을 위한 '틀'까지 제공하는 확장된 개념입니다.

​실행 단계 비교

순수 JDBC의 실행 단계

  1. 접속 정보 설정: MySQL 접속 정보 4가지(Driver, URL, ID, Password) 준비.
  2. 드라이버 로딩: Class.forName() 등을 통한 드라이버 메모리 로딩.
  3. Connection 맺기: DB와의 물리적 연결 생성.
  4. SQL문 작성 및 전송: PreparedStatement 객체를 생성하고 쿼리 실행.
  5. 외부 자원 반납: finally 블록에서 ResultSet, Statement, Connection 순으로 해제.

MyBatis 실행 단계

  1. .properties 작성
    • JDBC에서 소스 코드에 하드코딩했던 4가지 접속 정보를 외부 파일(예: com/config/jdbc.properties)에 key=value 형태로 분리하여 저장합니다 (utf-8 인코딩 필수).
  2. DTO 클래스 생성
    • 테이블당 1개의 DTO 클래스를 작성하며, 변수명을 테이블의 컬럼명과 일치시키는 것이 핵심입니다 (예: deptno 컬럼 -> int deptno;).
    • 기본 생성자와 Getter/Setter가 필수적이며, 이렇게 만들어진 DTO는 MyBatis가 자동으로 데이터를 넣고 빼는 데 사용됩니다.
  3. .xml 파일 생성
    • 비즈니스 로직과 SQL을 분리하기 위해 XML 태그를 사용해 SQL을 작성합니다.
  4. 자바 코드에서 설정 파일 연동
    • 자바 코드에서는 쿼리 전송 및 자원 반납의 복잡한 로직 대신, configuration.xml 파일을 읽어 SqlSessionFactory를 빌드하는 방식으로 초기화합니다.
    • 이후 개발자가 메서드만 호출하면 MyBatis가 매핑된 SQL문을 자동으로 실행해 줍니다.

내 생각

학습을 진행하며 가장 크게 체감한 장점은 보안과 관리의 분리, 그리고 반복 작업의 제거입니다.

  • 보안 및 형상 관리의 혁신: 기존 JDBC 방식처럼 소스 코드 내에 DB 계정 정보를 작성하면, 컴파일된 .jar 파일이나 버전 관리 시스템(Git 등)에 민감한 정보가 그대로 노출되는 치명적인 보안 이슈가 발생합니다. 하지만 MyBatis를 도입하며 .properties라는 외부 파일로 이를 분리함으로써, 환경별 설정 교체가 쉬워졌고 보안 위험도 크게 낮출 수 있다는 점을 깨달았습니다.
  • 마법 같은 자동 바인딩: DTO와 XML을 생성하는 초기 세팅이 번거로워 보일 수 있으나, 변수명만 컬럼명과 일치시키면 쿼리 결과를 자동으로 객체에 매핑해 주는 부분에서 코드 가독성과 유지보수성이 압도적으로 좋아지는 것을 확인했습니다.

의문점

갑자기 번뜩이는 의문이 머릿속을 스쳤습니다. "자바에는 가비지 컬렉터(GC)가 있는데, 왜 내가 직접 메모리를 비워줘야 하지?" 위대한 재미나이에게 물어보니 그 이유는 다음과 같았습니다.

  • DB 커넥션은 '외부 네트워크 자원'이다 자바의 가비지 컬렉터(GC)는 JVM 메모리 내부의 객체는 잘 청소하지만, 외부 데이터베이스와의 물리적인 네트워크 소켓 연결까지 즉각적으로 감지하고 끊어주지는 못합니다.
  • 데이터베이스의 한정된 자원(Connection Limit) 데이터베이스 서버는 동시에 연결할 수 있는 클라이언트의 수(Connection)가 제한되어 있습니다. 작업을 마쳤는데도 자원을 반납(close())하지 않으면, 이 연결들이 허공에 떠 있는 상태(Connection Leak)가 되고, 결국 DB 서버가 새로운 접속을 받을 수 없어 서비스가 뻗어버리는 치명적인 장애로 이어집니다.