JDBC 기초와 트랜잭션 — H2 로 직접 커넥션·쿼리·커밋을 다루기

배치 04 레슨의 InMemoryDatabase 시뮬레이션을 실제 DB(H2)로 옮깁니다. 드라이버 로딩부터 PreparedStatement 바인딩, ResultSet 타입 매핑, 트랜잭션 커밋/롤백, 10만 건 배치 insert 실측, 생성 키, 메타데이터, 예외 분기까지 JDBC 만으로 직접 다루고, JdbcTemplate 비슷한 헬퍼를 손으로 만들어 "프레임워크가 감춰 주는 것"을 이해합니다.

1. 왜 배우는가

실무에서 DB 를 순수 JDBC 로 다루는 일은 드뭅니다. MyBatis, JPA, Spring JdbcTemplate 이 대부분을 대신합니다. 그런데 장애는 항상 그 아래에서 납니다.

"커넥션 풀 고갈로 서비스 정지", "SELECT 한 줄이 10만 행을 힙에 올려 OOM", "트랜잭션이 안 걸려서 재고는 빠졌는데 주문은 없음", "배치가 밤새 건별 커밋으로 돌다가 새벽에 미완료". 이 문제들을 진단하려면 프레임워크가 결국 무엇을 호출하는지 — Connection, PreparedStatement, ResultSet, commit() — 알아야 합니다.

배치 04 레슨에서 begin()/commit()/rollback() 을 HashMap 두 개로 흉내 냈습니다. 그 계약("커밋 전 변경은 격리되어 있고 취소 가능하다")은 실제 DB 에서도 같지만, 실제 DB 에는 시뮬레이션에 없던 것들이 있습니다.

커넥션이라는 비싼 자원, 문자열 결합이 만드는 SQL 인젝션, NULL 이 0 으로 읽히는 함정, 격리 수준, 제약 조건 위반이 던지는 SQLException, 그리고 커밋마다 발생하는 진짜 fsync 비용. 이 레슨은 그 차이를 하나씩 실행해서 확인합니다.

H2 를 쓰는 이유는 설치 없이 jar 하나로 인메모리 DB 가 뜨고, 표준 SQL 과 JDBC 4 를 거의 완전히 지원하기 때문입니다. 여기서 배운 코드는 URL 과 드라이버만 바꾸면 PostgreSQL, MySQL, Oracle 에서 그대로 동작합니다. 그것이 JDBC 가 존재하는 이유입니다.