Background Image
2009.05.14 07:37

Java 저장프로시저...

조회 수 29536 추천 수 0 댓글 3
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄


또 긴 글을 적게 되나 싶은데, 사건의 발단은 이렇습니다.

얼마 전에 아래 질문에 제가 답하기를

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만건 돌파로 뜰떠 있을 큐브리드에 좀 우울한 말씀을 드려서 오늘은 좀 죄송하게 되었읍니다.

  • ?
    웁쓰 2009.05.14 19:06
    안녕하세요. 우광명이라고 합니다.
    초보대왕님이 올려주신 글에 두번째 답을 하네요.

    얼마전에 올려주셨던 큐브리드 면접 문제를 회고하며 잘 읽었습니다.
    공교 롭게도 올려 주셨을때 저도 면접 문제 트래킹 하던중이라 누굴까 했었는데..

    여튼 본론으로 들어가서...

    일단 대화의 촛점이 좀 보는 사람의 시각에서 좀 다를듯 여겨 집니다. 자바의 장점이라면 "write once run anywhere" 라는 장점이 있죠. 그런 의미에서 자바가 서버베이스 language에서 꽤나 성장했던것도 사실입니다.

    그런 의미에서 잘만들어 놓은 class library를 어떤 저장소에서 갔다 쓸수 있다면 꽤나 장점이 되겠죠. apache project에서 진행하고 있는 jakarta-commons 프로젝트 처럼요.

    사실 논의의 촛점인 개발자를 위한 DB를 언급 해 주셨는데 사실 저도 어떤게 개발자를 위한 DB일까 고민을 많이 했었습니다.

    적절한 예일지는 모르겠으나 예전 직장에 다닐때 DBA 와 개발자가 따로 있어서 SQL은 DBA가 주로 작업을 해주었지요.
    그래서 개발자는 DB에 대해서는 SP콜만 하는 형태로 만든적이 있습니다. 그 당시에는 PL/SQL package로 만들었구요.
    그런데 제가 말하고자 하는 핵심은 뭐냐면 처음에 만들때는 좋았는데 유지보수 하면서 문제가 발생했습니다.

    최초에 구축했던 사람들이 유지보수에서 멀어지면서 새로온 사람이 기존에 만들어졌던 프로그램에 대해서 이해를 못하는 뭐 그런 문제 였었죠.

    일단 저의 생각은 이렇습니다. 개발자와 DB엔지니어는 다른 존재라고 생각해보구요. SP를 작성했을때 나 아닌 다른 사람과 co-work할때 문제가 발생할 소지가 없는지 그리고 꼭 SP가 필요한지에 대한 의문이 듭니다.

    될수 있다면 비싼 DB자원 보다는 AP에서 로직을 처리하는게 맞다고 생각합니다.

    그리고 마지막으로 자바와 C 기반 프로시져를 만들때

    "자바로 만들면 스크립트 언어를 임베딩하기 편할 것이다" 는 생각이 깔려 있는데, 실은
    "C 메서드를 저장프로시저급으로 만들면 스크립트 언어를 임베딩하기가 더 편합니다."

    이 부분에 대해서 대해서만 간단히 말씀 드리자면 회사 내부에서 pilot비슷하게 ruby, python 등을 임베딩 했던 적이 있습니다.

    임베딩 하기 편하다는 부분에 대해서는 C개발자의 입장에서만으로 보여지구요.

    답글을 달긴 했지만 초보대왕님의 장문의 글이 대단히 멋져 보이네요.

    사실 저도 인터넷상에서 글을 쓰긴 하지만.. 어쨌던 지금 보여주신 열정 계속 부탁 드립니다.

    좋은 하루 보내세요.


  • ?
    초보대왕 2009.05.15 07:23
    -- 될수 있다면 비싼 DB자원 보다는 AP에서 로직을 처리하는게 맞다고 생각합니다.

    "이게 맞다"고 생각하시는 이유는 웁쓰님이 "DB자원" 을 적극 활용하는 경우에 발생할 수 있는 혼란에
    주로 집중하셨기 때문인데,  문제는 그 '혼란' 이란 것은 충분히 통제될 수 있는 혼란이라는 것입니다.
    여기에 대해서도 이미 제가 '큐브리드의 철학' 이라는 제목으로 글을 올린 적이 있기 때문에
    다시 재론한 필요는 없을 것 같습니다.

    http://www.borlandforum.com/impboard/impboard.dll?action=read&db=free&no=14793

    위 링크에서 박지훈님도 웁쓰님과 같은 의견인데, 여기에 제가 다른 의견을 제시하면서 작성했던게
    '큐브리드의 철학은?' 이라는 제목의 글이 되었읍니다.

    웁쓰님은 자바 전문가이신거 같은데, 자바에 대한 의문이 몇 가지 있어서,
    나중에라도 언제한번 자바에 대한 고견을 들려 주시는 날이 있었으면 좋겠읍니다(^^)
  • ?
    웁쓰 2009.05.15 08:54
    음.. 열심히 댓글을 달다가 보니 세션이 끊겨서 글이 날아가 버렸네요. ㅜ.ㅜ

    음.. 링크 걸어주신 볼랜드 포럼글과 "큐브리드의 철학은?" 두글다 읽어 보았습니다. 오래전일이라서 가물 하긴 하네요.

    음 자바 전문가라 하기엔 좀 그렇구요. 단지 자바를 쓸줄 아는 코더 정도 입니다. ㅎㅎ

    큐브리드 인사이드에 오시면 뵐수 있는 날이 있지 않을까요?( 음.. 글을 읽어본 느낌으로는 2차 인사이드때 뵜던분 같은데..ㅎㅎ)

    그럼 편안한 시간 보내세요.


List of Articles
번호 제목 글쓴이 날짜 조회 수
100 3회 CUBRID Inside 생생한 세미나 현장 속으로~ CUBRID_DEV 2009.06.25 33396
99 CUBRID를 어떻게 함께 만든단 말인가?? 2 1 file CUBRID_DEV 2009.06.16 26613
98 큐브리드 매니저 2008 R2 - 맛뵈기 프리뷰 정병주 2009.06.16 49139
97 2009 3rd CUBRID Inside를 다녀와서! 2 시난 2009.05.27 36913
96 오픈소스SW 저작권 인식제고를 위한 공모전 3 정병주 2009.05.22 41772
95 (CUBRID후원) 여성개발자모임터 커뮤니티 세미나 CUBRID_DEV 2009.05.20 20114
94 (CUBRID 후원) 우분투 사용자 커뮤니티 안내 2 file CUBRID_DEV 2009.05.20 23228
93 CUBRID Inside 3회 참가 신청 받습니다. CUBRID_DEV 2009.05.19 18961
» Java 저장프로시저... 3 초보대왕 2009.05.14 29536
91 헛...;; 2 secret 혜꽁이양 2009.05.13 6
90 큐브리드 다운로드 4만건 돌파 기념 간식 배달 이벤트 - 축하 메시지 남기기 ^^ 291 2 file admin 2009.05.13 219569
89 다운로드 월 3000건 돌파, 축하합니다. 4 flypig 2009.04.30 24469
88 CUBRID 오픈소스 프로젝트 4월 소식지 2 CUBRID_DEV 2009.04.25 23259
87 큐브리드 면접문제를 회고하며... 5 초보대왕 2009.04.22 34429
86 벌써 4월말이 되어 가는데... 1 flypig 2009.04.22 17879
85 오라클이 썬을 인수함 1 flypig 2009.04.21 18150
84 큐브리드양을 소개합니다. 1 정병주 2009.04.07 44637
83 안녕하세요~! 2 루키민규 2009.03.30 18502
82 어헙... 감사합니다..(꾸벅) 1 갈은양파 2009.03.12 18010
81 cubrid 홈페이지 글씨체에 대해서 2 프란체스카 2009.03.10 17684
Board Pagination Prev 1 ... 4 5 6 7 8 9 10 11 12 13 Next
/ 13

Contact Cubrid

대표전화 070-4077-2110 / 기술문의 070-4077-2113 / 영업문의 070-4077-2112 / Email. contact_at_cubrid.com
Contact Sales