국산 시스템 소프트웨어에 대한 단상

저는 98년도 부터 비교적 최근까지 UNISQL로 개발을 해온 개발자입니다.
글을 읽다가 몇가지 오해가 있는듯 싶어 글을 올립니다.
참 저는 UniSQL의 직원이 아닙니다. 그러므로 일부러 옹호하고 싶은 생각은 없습니다.

UNISQL이 객체관계형DBMS 라는건 맞습니다. OODB의 기반에 RDBMS에 대한 표준을 상당부분 수용하고 있습니다.
다만, 기본구조 자체가 OO로 설계되어 있으므로, table 설계가 RDBMS 기반으로 되어있다면 성능이 많이 떨어집니다.
UNISQL Tunning이라는 Reference를 따르면 조인이 필요한 대부분의 것을 Object(or table)에 대한 참조로 대체하는 것을 보여줍니다. 이렇게 사용했을 경우 RDBMS에 비하여 많은 성능의 향상을 얻을 수 있습니다.

KCC가 판권을 인수한 것 또한 맞습니다. 그러나 현재는 UniSQL에 대한 상표권을 취득하여 UniSQL이라는 회사명을 사용하고 있습니다. URL 또한 취득했더군요.(www.unisql.com)

Connection Pool에 대한 문제는... UNISQL의 경우에는 기본적으로 Connection을 관장하는 미들웨어인 UNICAS(UniWEB, Vision3의 업그레이드 버젼)를 통하여 질의를 하도록 권장하고 있습니다.
직접 DBMS와의 Connection을 관리하고 싶다면 C나 C++로 만드셔야 합니다.(그게 UNICAS입니다. ^^;)
Connection Pool을 구현한 UNICAS가 존재하므로 UNISQL의 입장은 Conneciton Pooling을 할 필요가 없다는 것입니다.
그러나 미들웨어를 구현하는 것 또한 많은 노하우가 필요한 부분이므로, 이전의 미들웨어인 UniWEB과 Vision3, 초기의 UNICAS 등에서는 많은 문제가 있었던 것 또한 사실입니다. 이 부분에서 UniSQL에서는 나름대로 R&D 팀을 미국 지사에도 설립하여 노력한 결과 현재의 미들웨어에서는 많은 결점을 극복한 것으로 판단됩니다.
(개인적으로는 그렇다고 만족할만한 수준이라고 하기는 그렇지만요...)
그리고... UNICAS가 미들웨어이므로... 관리가 필요합니다. 그냥 내비둔다고 잘 돌아가는게 아닙니다.
서버 튜닝, DB 튜닝을 하듯이 UNICAS에 대한 튜닝도 필요합니다.
이러한 튜닝을 통해서도 많은 성능의 향상을 볼 수 있습니다.

PHP와 UniSQL과의 연동은 실제 프로젝트에 사용해본 적이 없어 뭐라 말씀드리기는 힘들겠네요.
그러나 PHP로 UniSQL에 UNICAS없이 직접 접속할 수 있는 방법은 없습니다.
저로서는 UniTCL, Java, VB, C, C++로 연동해보았습니다만은, 위와 같은 튜닝과 더불어 개발에서도 UniSQL의 장점을 최대한 활용한다면 몇백명 붙는다고 죽는 일은 없었습니다.
실제 개발에서는 조인은 가급적 피해야 합니다. 객체에 대한 참조를 최대한 활용하는 것이 가장 좋습니다. 또한, Class(table)의 상속을 십분 활용하는 것도 좋은 방법일 것입니다.

그리고, UniSQL의 영문 매뉴얼은 매우 충실한 편입니다. 한글 매뉴얼도 있습니다.
다만 UniSQL의 홈페이지에서 이러한 많은 레퍼런스를 모두 제공하지 않는 점은 유감이더군요. 정책때문인지...
UniSQL에서는 매뉴얼을 먼저 영문으로 만듭니다. 차후에 한글버젼을 만들더군요.
한글 매뉴얼이 부실하다고 불평하는 분도 계시겠지만, 어차피 외국제품들 매뉴얼 다 영문입니다.
한글 매뉴얼도 나오겠지만, 영문 매뉴얼에 비해 시간차가 발생합니다. 그만큼 경쟁력에서 뒤쳐지지는거라 생각합니다.
현재 우리의 실정으로, 개발자라면 영문 매뉴얼을 부담없이 보는것이 필요하다는 생각입니다.

UniSQL에도 단점이 있습니다. 무엇보다 멀티스레드가 제대로 지원되지 않아 시스템의 사양이 매우 높더라도, 모두 사용하는데에는 한계가 있다는 것입니다. 이것은 Enterprise급의 DBMS의 성능이라는 관점에서 매우 취약한 약점입니다. 이 부분에서는 UniSQL 측이 조만간 Upgrade 버젼을 내놓을 계획이라고 하더군요.
(개인적으로 DB가 CPU를 다 잡아먹는 경우는 10% 정도 발생했습니다. 대부분 미들웨어인 UNICAS가 시스템 자원을 많이 잡아 먹더군요.)

UniSQL의 성능을 최대한 활용하려고 개발한 다음에 다른 DB에 연동하려면 다시 개발하는게 좋을 정도로 호환성이 떨어지게 됩니다. 이 부분은 다른 ORDBMS나 OODBMS를 사용해도 마찬가지일 것입니다.

현재 많이 뜨고 있는 J2EE와 UniSQL의 연동 문제는 나름대로 아쉬운 점이 많습니다.
UniSQL 자체가 ORDBMS 이므로, J2EE의 entity를 그대로 연동하는 것이 가능할 법도 한데... 그 부분에서는 이렇다할 말이 없더군요. 다만 XML 기반 DB에 대한 연구는 활발히 진행하고 있다더군요.
이것은 신문에서 본것이고 본사 직원에게 들은게 아니라서... 정확히 어느정도나 진행되었는지 모르겠네요.

원래 이 토론의 주제와는 상관없는 내용이고 특정 제품을 홍보하는 듯한 글이 되어 조금 찜찜하긴 한데요.
국산 제품에 대한 제 개인적인 생각은 그렇습니다.

가장 불만을 가지는 것이 서비스입니다. 이 부분은 우리나라 사람들이 이중의 잣대를 들이대는게 아니냐는 생각입니다.
외국제품 구입하게되면 필요한 유지보수 비용이나 교육등에 대한 서비스 비용이 별도로 지급되어야 한다면 원래 그런줄 압니다. 외국에서도 그렇게 한다고 하면 고개를 끄덕입니다.
그러나 국산제품은 가까운 곳에 있으니깐 서비스비용은 무료로 생각하는 경향이 있습니다.
외국제품들도 하자 많이 발생합니다. 국산제품이라고 해서 발생하지 말라는 법 없습니다.
국산제품의 하자에는 유난히 혹독합니다. 이중의 잣대가 아닌 냉정한 판단이 필요할 것 같습니다.
(UniSQL에는 유난히 병특이 많습니다. 그리고 이 병특들이 서비스의 상당수를 지원하고 있습니다. 그러니 질이 떨어질 수 밖에 없었습니다. 그러한 문제점이 많이 제기되어 수정되어 현재의 서비스는 충실한 편에 속한다고 생각합니다. 외국제품들의 서비스보다는 훨씬 낳습니다. ^^;)

국산제품 무조건 옹호하거나 애용하자고 하기는 좀 그렇습니다. 이 치열한 세상에서 그러한 논리를 내놓으면 뒤떨어진 수국론자로 취급되기 일쑤입니다. 하지만, 나름대로 외국제품과 경쟁해도 뒤떨어지지 않는 제품을 국산이라는 미명하에 깎아내리지는 말았으면 좋겠습니다. 애초에 외국제품들 끼리 비교하듯이 성능을 비교해보고 비슷하다면 기왕이면 다홍치마라고 국산제품을 선택하는 모양새면 좋겠습니다. 국산제품이 서비스를 받기에는 더욱 용이합니다.
정 갑갑하면 본사로 쳐들어갈 수도 있잖습니까? ^^;

-본의아니게 겁쟁이로 올리는군요 : 처리~-