CUBRID가 타 db에 비하여 강력한 것은 사실일 지도 모릅니다.
하지만 결정적인 단점은 배포와 관리가 너무 불편하다는 것입니다. 별도의 DBA가 있는 엔터프라이즈환경을 대상으로 하는 dbms라면 할말은 없습니다. 그러나 mysql같은 비지니스모델을 염두에 두고 개발자레벨에서의 확산을 바란다면 지금의 상태로는 어림 없습니다.
우리나라의 90%이상의 dbms사용처는 별도의 dba가 없는 중소기업내지 소규모 개발자입니다. (인력낭비죠) 이런 환경에서의 관리는 외부인이건 내부인이건 해당기업의 개발을 담당하는 개발자가 될 수 밖에 없습니다.
mysql이나 firebird같은 dbms가 많이 사용되는 이유는 해당 dbms를 설치해 주기만 하면 모든 작업이 admin으로 로그인한 사용자가 관리가 가능합니다. 하지만 제가 잘못 알고 있는지 모르지만 cubrid는 반드시 별도의 관리툴로 관리해야 하는 작업이 필요합니다. 배포를 하거나 설치를 해 주어야 하는 입장에서는 치명적인 단점입니다.
그래서 웹서버호스팅업체의 경우 mysql이 많이 사용된다고 봅니다. 뿐만 아니라 각종 포탈사이트를 가보면 업무용패키지를 배포하는 업체들조차 mysql을 사용하는 패키지를 많이 만들고 배포합니다.(불법이든 아니든간에 그만큼 개발이나 배포에 편리하다는 것이겠죠)
이번에 추가된 자바모듈도 마찬가지 입니다. 프로시저를 위한 내부 스크립터를 만들지 않고 외부 모듈에 대한 의존성을 추가함으로서 정말로 제대로 CUBRID를 사용하려면 이제 자바까지 공부해야 하는 상황이 벌어져 버렸습니다. 즉 CUBRID를 사용하는 기업체는 클라이언트프로그래머(웹이 아닌한 자바는 거의 사용하지 않습니다.)에 자바프로그래머까지 필요한 상황이 초래 되었습니다. 위에서 말한 관리상의 문제까지 DBA나 패키지 업체의 경우 클라이언트업체에 가서 DB설정을 해 주는 인력까지 필요한 상황입니다. mysql을 사용하면 전혀 발생할 필요가 없는 비용이죠. 자바모듈이 아닌 SQL표준정도의 프로시저를 내부에서 지원하는 방식으로 가는 것이 맞았다고 봅니다.
NHN에서 mysql과 비교한 자료같은 것은 큰 의미가 없습니다. 일반 중소기업의 전산실에 소속된 개발자나 소프트웨어업체에서 문제는 사용의 편의성이나 배포의 편의성입니다.
생각해보면 CUBRID의 가는 방향은 일반 개발자를 끌어들이려고 하는 것이 아니고 오라클이이나 DB2같은 dbms를 사용하는 업체를 소프트웨어 구매 비용을 대비하여 끌어 들이려고 하는 것이 아닌가 생각됩니다. 소프웨어구입비용을 제외하고 유지관리의 편의성에서 과연 그들보다 편리한지는 의문이 많이 남습니다.
|