안녕하세요.

좋으신 의견에 감사드립니다.

말씀하신 것 처럼 모든 사용자(개발자,운영자)들이 편하게 사용할 수 있는 DBMS 를 만들어 보급하는 것을 저희의 목표로 하고 있읍니다. 다만 제품에 반영하는 여러 기능 및 버그 수정등이 우선순위에 따른 일정관리가 되어지다보니 모든 고객을 만족시키지 못한 부분이 있는 것이 사실입니다. 현재 이를 해결하기 위하여 개발 프로세스 및 인력 확충 등 여러 부문에서 많은 노력을 기울이고 있으니 이점 많은 양해를 바랍니다.

>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를 사용하는 업체를 소프트웨어 구매 비용을 대비하여 끌어 들이려고 하는 것이 아닌가 생각됩니다. 소프웨어구입비용을 제외하고 유지관리의 편의성에서 과연 그들보다 편리한지는 의문이 많이 남습니다.

먼저, 좋은 의견, 관심 감사 드리고, 아래에 항목별로 답변 드립니다.

>mysql이나 firebird같은 dbms가 많이 사용되는 이유는 해당 dbms를 설치해 주기만 하면 모든 작업이 admin으로 로그인한 사용자가 관리가 가능합니다. 하지만 제가 잘못 알고 있는지 모르지만 cubrid는 반드시 별도의 관리툴로 관리해야 하는 작업이 필요합니다. 배포를 하거나 설치를 해 주어야 하는 입장에서는 치명적인 단점입니다.

>그래서 웹서버호스팅업체의 경우 mysql이 많이 사용된다고 봅니다.  뿐만 아니라 각종 포탈사이트를 가보면 업무용패키지를  배포하는 업체들조차 mysql을 사용하는 패키지를 많이 만들고 배포합니다.(불법이든 아니든간에 그만큼 개발이나 배포에 편리하다는 것이겠죠)

CUBRID의 경우에는 설치 계정으로는 mysql처럼 옛날 file system 방식의 데이터보호 수준으로 관리가 가능하고, 그 외 계정으로는 Oracle/MS-SQL과 같은 높은 수준의 사용자관리가 가능하도록 되어 있어, 둘 다 가능한 것으로 생각하고 있었습니다. 배포/호스팅 시나리오 측면에서 불편한 점을 다시 한번 검토하여 보겠습니다. 좋은 지적 감사 드립니다.

>

>이번에 추가된 자바모듈도 마찬가지 입니다.   프로시저를 위한 내부 스크립터를 만들지 않고 외부 모듈에 대한 의존성을 추가함으로서 정말로 제대로 CUBRID를 사용하려면 이제 자바까지 공부해야 하는 상황이 벌어져 버렸습니다.  즉 CUBRID를 사용하는 기업체는 클라이언트프로그래머(웹이 아닌한 자바는 거의 사용하지 않습니다.)에 자바프로그래머까지 필요한 상황이 초래 되었습니다. 위에서 말한 관리상의 문제까지 DBA나 패키지 업체의 경우 클라이언트업체에 가서 DB설정을 해 주는 인력까지 필요한 상황입니다. mysql을 사용하면 전혀 발생할 필요가 없는 비용이죠. 자바모듈이 아닌 SQL표준정도의 프로시저를 내부에서 지원하는 방식으로 가는 것이 맞았다고 봅니다.

이 논쟁은 제가 학부생이었던 시절, 아니 그 이전으로 거슬러 올라갑니다. COBOL로 DB 프로그래밍하던 시절에는 COBOL을 배우면 바로 DB 프로그래밍이 가능했었습니다. 그러다가 데이터에 집중된 로직은 서버에 두고 공유하는 것이 성능/재사용성/관리 측면에서 탁월함을 알고, 이를 위해 저장프로시저가 발명되었습니다. 문제는 당시의 DB 엔진에는 COBOL runtime이 없었기 때문에, DB 벤더들은 어쩔 수 없이 DB 만의 프로그래밍언어 (예, PL/SQL, T-SQL)를 개발할 수 밖에 없었습니다. 이 순간 DB 프로그래밍할 때와 일반 프로그래밍할 때의 데이터타입, 로직, 개발환경(디버깅, 시험 등등) 등이 달라 짜증스럽기 이를 데 없는 세상이 시작되었습니다. 학술적으로는 impedance mismatch 중 하나라고 배웠지요. 결국 DB 분야에서는 일반 프로그래밍 언어와 DB 프로시저 언어를 통일하는 것이 수십년 간 숙원사업이었습니다.

이 답은 사실 DB 분야가 아닌 프로그래밍 분야에서 해결해준 것 같습니다. Java나 .NET이 나오면서 JVM, CLR이 DB 서버에 호스팅될 수 있게 됨에 따라, 이제는 DB 서버에서도 일반 프로그래밍언어로 작성된 프로시저를 수행할 수 있게 된 거지요. 이제는 하나의 프로그래밍 언어 (예, Java, .NET)를 알고, 표준 SQL을 알면, 표준이 아닌 PL/SQL, T-SQL을 몰라도 DB 프로시저 프로그래밍이 가능해졌습니다. 이제는 향후 DB migration 이슈를 걱정하지 않아도 되고, 개발과정의 모든 개발도구(예, Eclipse, Visual Studio, etc)도 사용할 수 있게 되었습니다. 이러한 장점 때문에 프로시저 개발은 Java (오라클의 경우) 혹은 .NET (MS-SQL의 경우)으로 옮겨가는 추세입니다. 큐브리드는 후발 주자로서 이러한 트렌드에 맞추어 Java 방식의 프로시저를 선택한 것입니다.

그렇다고 해서, 이 방식이 모든 경우에 항상 편한 것은 아닐 것입니다. \"나무\"님께서 말씀하신 대로 Java에 익숙하지 않고, PL/SQL, T-SQL과 같은 스크립트에 익숙한 개발자에게는 또 하나의 큰 짐일 것입니다. 이 부분은 개발자 migration이라는 차원에서 저희도 준비를 계획하고 있습니다. 즉, 비록 미래지향적인 추세를 따르고는 있으나, 기존 타제품 개발자들이 큐브리드로 migration하는 데 드는 수고를 최소화하는 측면에서 검토하고 있습니다. 역시, 개선안 감사 드리구요.

앞으로도 많은 개선사항 부탁 드립니다.