자바 개발자들은 흔히 Mr. everything in Java 를 추종하는 모습을 보입니다. 즉, 모든 것을 자바로 짜면 그게 좋고 그렇게 못하면 나쁘다고 생각하는 것입니다. 그러나 그로인한 JDBC 드라이버에 대한 오해가 있습니다. (이하 이런글이 언제나 그렇듯 반말)

JDBC 드라이버의 종류는 4가지인데 그중 가장 자주 사용되는게 당연히 JDBC Type 4 드라이버이다. JDBC Type 4 인 이 드라이버는 흔히 pure java 라는 이름으로 미화가 되는 방식으로서, 데이터베이스의 네트웍 프로토콜을 사용해 직접 소켓통신한다. 대부분의 경우 type 4의 성능은 매우 우수하다.

type 3라는 형태도 존재하나, 좀처럼 제공되는 일이 드물다. type 3은 미들웨어를 통한 DB 접속을 제공하며, 이 성능은 type2 보다 통상(언제나 통상에 유의하자. 이 세계엔 무조건이란게 없다.) 우수하다. 만약 type3 이 존재한다면 type3과 type4를 벤치마킹하여 그 중 나은것을 택하는 것이 좋다.

문제는 우리의 주목은 하나도 받지 못하는 type 2 드라이버이다. type2는 부분적 자바, 부분적 JNI구현으로 만들어지며 알다시피 JNI 호출에는 오버헤드가 있다. 이 오버헤드라는 것은, 시간이 갈수록 JAVA의 VM이 빨라질수록 pure java에 비해 크게 느껴진다. 또 한편, 역설적으로도 자바의 VM이 개선될수록 JNI 호출에 따른 오버헤드가 작아지므로 JNI 호출에 따른 오버헤드가 작아진다. 마지막으로, VM 이 개선될 수록 pure java 코드가 네이티브 코드에 비해 성능이 그리 나쁘지 않게되는 되지만 ‘통상’ 네이티브 코드가 빠르다.

말을 빙빙 돌렸는데, 한마디로 말하면 pure java 와 JNI+java 는 길고 짧은걸 대봐야한단 말이다. type2가 명백히 득이 되는 경우는 네트워크 접속이 필요가 없는 경우이다. 대부분의 경우에는 DB와 웹 애플리케이션이 하나의 서버에 작성된다. (즉, 개념적 투티어.) 이런 경우에는 소켓접속이 낭비라는 사실에 주목해야한다. 즉, type 4는 서버가 한대라면 도통 쓸데 없는 소켓접속에 시간을 다 날려버린다는 것이다.

이처럼 서버가 한대일때는 JNI 호출의 오버헤드가 소켓 접속의 오버헤드보다 작기만 하다면 type2가 type4보다 월등히 좋을 확률이 높다. 더군다나 ‘네이티브’ 라는 것은 그 머신에 최적화 된다. 최적화된 코드와 불필요한 소켓통신을 유발하는 순수 자바 코드끼리의 성능 격차는 재봐야안다.

말하자면 type 4의 alias인 jdbc thin driver는 misnomer라도 별 하자가 없다. 얇긴 뭐가 얇단 말인가. 오히려 모두의 성능을 비교해보지 않고 무조건 thin 만 사용하는 것이 귀가 얇은 행동일 수 있다.

사실이 이러함에도 type 4가 우수하다는 편견은 생각외로 매우 많이 퍼져있으며, 어느정도는 거의 복구 불가능할 정도로 확고하게 자리잡고 있다.

p.s. 기본적으로 이런 류의 제 글들을 배껴갈때는 배껴간다고 코멘트하시기 바라고, 저의 written permission 없이는 상업적으로 이용하실수 없습니다… ^^