점프와 쉼없는 나아감

언제부터인가 Java EE 프로젝트에 DBMS가 등장하더니 이제는 많은 프로젝트가 거의 DBMS 중심으로 프로젝트가 진행되곤 하는 거 같다.  설계 == ERD 작성이고 자바 객체는 DB 테이블의 그림자이며, 자바 메서드는 SQL 호출을 몇개 묶은 것이다. 그리고 성능 튜닝은 SQL 튜닝이고 말이다.  그러다 보니 웃기지도 않는 일들이 간혹 생긴다. 이를테면 도메인 모델 객체는 아예 Map 객체로 대신하는 일 같은 거다. DBMS가 바뀌면 아예 코드는 다시 짜야 한다.  boolean으로 정의해야 할 데이터 타입이 Oracle에서 지원되지 않는다는 이유 하나만으로 String이나 int 형이 되야 하는 황당한 일도 발생한다.  여러 ORM 프레임워크 중에서도 유독 iBatis가 인기를 끌고 있는 점도 이를 반영하는 걸꺼다.

그런데 과연 모든 데이터 처리를 DBMS(정확히는 RDBMS)에게 맡기는 것이 합리적인 걸까? 성능과 확장성 면에서 기존 RDBMS는 너무 무거운 게 아닐까? 더욱이 무언가 구조 면에서 구닥다리 느낌이 나는 것도 있고 말이다.

이에 관해 많은 생각할 꺼리를 던져주는 블로그 포스트를 보게 되었다. 약간 접근로가 다르긴 하지만 말이다.  "이 업계의 많은 사람들이 DBMS를 마치 맥가이버칼(Swiss Army Knife)과 같이 다용도로 쓸 수 있는 데이터 저장 공간으로 바라보는 나쁜 버릇에 빠져 있다(Many eyes in the industry have indulged in the bad habit of seeing the DBMS as the data storage equivalent of a Swiss Army Knife)." 라는 말이 이 포스트의 주제를 말하고 있다 하겠다.

덧붙여 Michael Stonebraker와의 대담도 소개하고 있다. 여기에서도 같은 시각이 보이는데 현재의 RDBMS를 one-size-filts-all로 표현하고 있다.  여러 데이터 처리 영역의 요구 사항을 기존 RDBMS가 충족하지 못하고 있으며 실제 시장의 점유율에서도 그렇다는 얘기다. 더욱이 RDBMS의 최고 장기라 할 수 있는 OLTP에서도 기존의 패러다임을 깬 새로운 시각으로 성능 향상에 도전해 볼 수 있다는 얘기도 있다.

역시 어렴풋이 갖고 있던 문제 의식이 나만의 문제 의식은 아니었나보다.  단지 나는 하루하루 바쁘다는 핑계로 그 문제 의식을 발전시켜 볼 생각을 안한 거고 누구는 적극적으로 발전시킨 것이고.

PS. Michael Stonebraker가 누군가 했더니 Ingres와 Postgres를 창시(?)한 사람이었다.  Postgres는 지금 PostgreSQL이 되었고. PostgreSQL은 내가 아주 좋아하는 DBMS다.