Framework (블랙박스 증후군)

DB 아키텍처에 대해 깊히 이해하지 못하는 객체지향 개발자가 흔히 하는 실수중의 하나는 DB에 대한 블랙박스 증후군이다.

이들은 마치 데이타베이스를 라디오의 건전지처럼 교체할 수 있어야 한다고 생각하고 데이타베이스의 특정 기능을 사용하는 것을 마치 나쁜짓인양 무슨 수를 써서라도 피하려고 한다. 그래도 데이타베이스 독립이라는 명록으로 데이타베이스의 기능을 사용하고 데이타베이스 활용을 거부한다. (데이타베이스 종속이란 말 자체가 사실 우물에 독뿌리기 오류를 범하고 있다. 종속이란 그리 듣기 좋은 단어가 아니기 때문이다.) 사실 데이터베이스의 독립을 이루기란 극히 어려울뿐 아니라 반대의 경우보다 훨씬 더 많은 비용이 든다.

이 문제는 크게 경제성과 비경제성 문제로 나눌수 있는데

첫번째로 블랙박스 증후군에 걸린 개발자는 수학이 아니라 공학이 가져야 하는 경제성 즉 비싼 데이타베이스 비용을 낭비하거나 이미 존재하는 기능임에도 직접 작정하는 수고를 통해 많은 시간을 낭비하게 된다.

두번째로 앞에서도 말한바와 같이 실질적으로 매우 어렵다. Ansi SQL만을 사용해서 어떤 제품을 만든다는 것은 Hello World 프로그램 따위에서나 생각할 수 있다. DB 벤더마다 Length, substring 같은 기본 함수들의 사용법이나 명칭등이 다르기 때문에 고작 쓸 수 있는 SQL이란 select * from emp 같은 정도를 사용할 수 있을 뿐이다.

세번째로 어려울뿐 아니라 어떤 문제는 사실 불가능한 것들도 있다. 예컨데 트랜잭션 모델의 경우 Oracle과 MSSQL은 많은 차이가 있고 이는 설사 같은 SQL을 사용했다고 하더라도 다른 결과를 일으키는 경우가 있다.

이러한 등등의 문제로 10년이 넘는 개발자의 생활중 사실 단 한번도 DB 독립을 갖춘 제품을 보지 못했다는 경험적인 이유도 있다. 그 많은 제품들은 물론 데이타베이스의 종속을 피하고자~ 라는 말이 대부분 있었음에도 불구하고 말이다. 실질적으로 제품정도의 코드에서 데이타베이스의 종속을 제거한 코드를 만드는것은 이론적으로 불가능은 아닐지라도 매우매우 어렵다.

그래서 객체지향과 DB는 서로간에 한발 양보를 하고 타협을 하게 되는데.
하나는 객체지향쪽에서 DB쪽으로 한발 접근한 DB를 객체형식으로 다루는 등의 하이버네이트식의 접근이고
다른 하나는 DB쪽에서 아예 객체기반 DB를 만드려는 시도이다.

여기서 두번째는 이 글의 주제와 맞지 않고 사실 논리적으로도 문제가 있다. DB의 종속을 피하기 위해 객체지향 DB를 사용하라는것 자체가 모순이다.(그리고 사실 객체기반 DB는 단순히 종속성의 문제때문에 개발된게 아니다. )


첫번째 하이버네이트식의 접근은 그 열렬한 추종자가 많이 줄긴 했지만 지금도 충분히 지나치게 과대평가라고 생각한다. 몇년전 하이버네이트 소스를 며칠동안 뜯어본적이 있었는데 그 대부분이 케이스별 SQL을 만드는 string 연산이였다. 지금은 나아졌는지 모르겠지만 어쨌거나 이방식은 겉보기에는 종속을 피할 수 있을지라도 DB의 효율성을 심각하게 감소시킨다. 무료(?)인 오픈소스 디비를 사용하면 비용이 안든다고 주장하지만 그 만큼의 저 효율을 어딘가에서 메꿔야 하기 때문에 그닥 납득하지는 못하겠다.

IBatis의 방법은 조금 더 현실적이긴 하지만 이도 역시 다른 문제가 있다. 이건 머 차차 쓰기로 하고 잠이나 -ㅅ-;;;;