또 긴 글을 적게 되나 싶은데, 사건의 발단은 이렇습니다.
얼마 전에 아래 질문에 제가 답하기를
http://www.cubrid.com/zbxe/bbs_developer_qa/42796
해당 함수를 큐브리드에서는 자바이외의 다른 저장프로시저로 포팅할 수는 없다.
그래서 이것이 "큐브리드의 큰 약점이다"는 답변을 달았읍니다. 그런데 남재우님이 다시
-- JAVA를 사용함으로써 SP단에서 다른 데이터베이스(이기종 포함)와의 작업 역시
-- 가능하도록 할 수가 있으므로 JAVA를 이용한 SP의 사용이 꼭 단점이라고 하기는 좀 어렵습니다.
라고 적어 주셨고, 저는 다시
-- 그렇다면 더 막강한 C/C++ 로 했어야 하며,
-- 이점은 아무래도 CUBRID 의 실수 같습니다.
라고 했읍니다. 여기에 대하여 재우님은
-- 말씀하신 것처럼 그냥 C를 사용하는 메소드를 발전시킬까도 많은 고민을 했었읍니다.
-- 아시겠지만 CUBRID는 메소드를 지원을 했읍니다.
-- C로 작성을 해서 등록을 하고 SP와 다름없이 사용할 수 있도록 환경을 마련하였었는데
-- 상당수의 고객분들의 말씀은 누가 지금 C로 만드는가 였었읍니다.
-- 지금 말씀하시는 것처럼 보다 쓰기 좋은 몇가지가 있는데 왜 C라는 거였었고...
-- 그래서 많은 고민을 하였던 거였었구요...
-- C 를 사용하여 메쏘드라는 것을 지원하던 때는
-- 오히려 C에 대한 반문이 무척 많았읍니다.
-- 기본적으로 C는 어려운 언어였고, 무었보다 메모리 관리가 어려워서
-- 코딩에 신경을 많이 써야만 했었기에 많은 고객분들이 다른 방식을 원했었읍니다...
라며 그간의 사정을 알려주셨네요. 그러나 여기에서도 '의문'은 또 일어납니다.
고객들이 C 보다 간편한 저장프로시저의 사용을 원하는 것은 당연합니다.
그래서 큐브리드는 C 의 메소드를 발전시켜 '저장프로시저' 급으로 만들어도
어차피 사용하기는 불편할 테니, 차라리 자바로 만들자, 그러면 자바에서는 다른 스크립트 언어를
임베딩시킬 수 있을테니 다른 스크립트 언어로 포팅하는 것도 쉬워지지 않겠는가 라고 판단하신듯 합니다.
그러나 여기에는 함정이 숨어 있읍니다. 이 판단의 기저에는
"자바로 만들면 스크립트 언어를 임베딩하기 편할 것이다" 는 생각이 깔려 있는데, 실은
"C 메서드를 저장프로시저급으로 만들면 스크립트 언어를 임베딩하기가 더 편합니다."
바로 이 점을 놓치신 듯 합니다. 이렇게 C 기반 저장프로시저가 있고, 이것을 기반으로
다른 스트립트언어를 쉽게 내장토록 하고 있는 DB 가 PGSQL 입니다.
PGSQL 가 얼마나 다양한 저장프로시저 스크립트언어를 지원하는지는 이미 소개했기 때문에,
새삼 재론할 필요가 없을 듯 합니다. PGSQL 이 지원하는 저장프로시저의 가장 밑바닥 기반이 C 이기 때문에
C 를 호출할 수 있는 자바도 당연히 PGSQL 이 지원하는 저장프로시저 목록에 안 들어갈 리가 없습니다.
그러니까 저장프로시저를 큐브리드에 도입한다고 하셧을때, 전략을
"자바기반 => 다른 스크립트 내장" 이 아니고
"C 메서드 확장 => 다른 스크립트 내장" 이 되었다면 좋았었다라는 것입니다.
큐브리드가 자바 저장프로시저를 도입한 후, 개발자들이 임의로 다른 저장 스크립트언어를
저장프로시저로 내장시킬 수가 있게 되었나요. 아쉽게도 그렇지 않습니다.
그런데 PGSQL 은 됩니다. 그래서 PGSQL 이 "개발자를 위한 DB" 라는 얘기가 나오는 한 이유인 것이죠.
-- 내가 쓰기 좋은 환경에 무엇인가가 있으면 그건 좋은 것이고요...
-- 내가 쓰기 힘든 것에 있으면 그건 좀 힘든 것이지 않은가 싶습니다....
-- 저도 JAVA는 싫어하고 DOS시절부터 메모리 신경쓰며 코딩하던 C가 그래도 쓸만한 언어였었지만...
-- 어쩔수 없는 선택이라는 것이... 조금이라도 많이 쓰시고 편하게 쓰실 수 있는 방향으로
-- 잡아드리는 것이 제품의 방향성이지 않은가 싶습니다.
-- 모든 분들을 만족드리고 싶지만 어쩔수 없는 선택의 기로에서 JAVA를 선택할 수 밖에 없었던
-- 저희의 상황을 이해해 주셨으면 합니다.
-- JAVA의 선택에 좋아하시던 많은 분들도 계셨었던것은 사실이지만요..^^;;
조금이라도 많이 쓰이고 편하기 쓰게 하려는 방향으로 자바를 택하셨다면,
C 를 채택한 경우 결국에는 더 편해질 것이라는 것은 생각을 안하셨다는게 못내 아쉽습니다.
그랬더라면 지금쯤 누구는 펄로, 누구는 자바로, 누구는 파이선으로 저장프로시저 언어를 내장시키는
작업을 하고 있을 것이고 그 중 몇은 이미 완성이 되어 있을 텐데 말입니다.
이렇게 된 원인은 PGSQL 처럼 C 기반 저장프로시저 위에 각종 스크립트 언어가 동작하는 환경에
생소하셔서 그런게 아닌게 생각합니다. 또한 C 기반 메서드를 저장프로시저급으로 발전시킬까 말까를
고민하셧던 상황을 제가 그때 알았었더라면 (주제 넘지만) 뭔가 제가 참고가 될만한 얘기를
해드릴 수 있지 않았겠나 하는 생각도 듭니다.
다운로드 4만건 돌파로 뜰떠 있을 큐브리드에 좀 우울한 말씀을 드려서 오늘은 좀 죄송하게 되었읍니다.
