엑시엄이 보는 DB 세상
데이터 전문가와 개발 전문가의 역할로 보는 DB 0 8 5,083

by axiom DB전문가와 개발자의 역할 프로시저를 이용한 개발방법 [2012.12.17]


대한민국에서 개발자라고 불리는 사람들 중'데이터베이스', '오라클'이라는 명칭을 모르는 사람은 없을 것이다. 하지만 데이터베이스에 대한 정확한 이해 없이 SQL을 작성하는 개발자들을 많이 봐왔다. 데이터베이스 전문가들과 개발 전문가들의 특화된 기술력이 다를 뿐이다.

그래서 필자는 데이터를 포함한 데이터베이스 영역은 데이터 전문가들에게 맡기고 응용프로그램(이하 AP) 개발은 전문 개발자들에게 맡겨야 한다고 생각한다.

이는 사람에게만 국한된 것이 아니다. 데이터베이스와 AP도 분명히 그어야 할 경계선이 있다.

데이터베이스와 AP의 경계

결론부터 이야기 하자면, 개발하고자 하는 정보시스템이 오라클 DBMS 기반으로 개발될 때는 데이터를 처리하는 일련의 모든 작업은 오라클 DBMS의 특화된 기능들을 사용해야 할 것이고, AP는 오라클 DBMS에서 담당해야 할 기능 또는 일 처리를 대신 수행해서는 안 된다는 것이다.

다시 말하면 JAVA/C 또는 C# 등과 같은 프로그램 언어로 개발된 AP 내부에는 SQL이 삽입될 필요가 없다는 것이다. 그러면 어떤 방법으로 AP는 오라클 DBMS에게 데이터를 요청할 것인가?

위 질문에 대한 답은 간단하다. 오라클 DBMS의 내장된 패키지 또는 프로시저를 호출하면 된다.

그러기 위해서 선행되어야 할작업은 무엇인가? AP가 필요로 하는 데이터 셋에 대한 질의 SQL을 오라클 DBMS 내의 저장된 패키지 또는 프로시저화해서 프로그래밍/컴파일해 놓아야 한다. 이렇게 오라클 DBMS에 저장된 패키지 또는 프로시저를 AP에서는 호출하기만 하면 되는 것이다. 그리고 데이터베이스는 데이터 인출, 변경, 생성, 삭제에 관한 SQL을 패키지 또는 프로시저로 저장하고 있으면 된다.

하지만 어떻게 저장 프로시저로 데이터베이스에서 데이터를 인출해 올 수 있을까라는 의문이 드는 사람도 있을 것이다.

MSSQL은 저장 프로시저 내에 단순 SELECT 문의 명시만으로도 쉽게 데이터를 인출해 올 수 있다.

하지만 오라클은 조금 다르다. 오라클은 참조커서라 불리는 커서를 사용해야 하고, 프로시저에 이참조커서를 사용해 프로그래밍하면 인출 데이터도 AP로 넘길 수있다.

참조커서의 활용

참조 커서는 프로그래밍이 용이하고 융통성이 있으며 성능 또한 탁월하다. 또한, 참조커서는 프로시저에서 마지막 행이 처리되기까지 기다리지 않고, 첫 번째 행을 바로 AP로 보낼 수 있도록허용한다.

그럼 참조커서를 사용한 프로시저 사용의 이점을 생각해 보자.

  • - 개발자의 부주의로 인한 성능 저하 및 Hard Parsing을 방지할 수 있다.
  • - SQL 변경 시, AP 수정 배포 비용이 절감된다.
  • - 오라클 전문가와 AP 전문가의 특화된 능력을 100% 발휘할 수 있다.

첫 번째 이점에서, 많은 개발자들이 서로 다른 AP를 개발하지만 필요한 데이터는 공통적일 수 있다. 공통된 데이터를 인출하기위해 서로 다른 SQL을 작성할 수 있고, 작성된 SQL의 성능은 천차만별일 것이다.

하지만 공통된 데이터를 인출하기 위한 SQL은 최적의 성능을 가진 SQL 하나면 될 것이고, 이 SQL이 프로시저화되어 있어 다수의 AP는 프로시저명 하나만 호출하면 된다. 그리고 이는 자연적으로 오라클 리소스를 많이 사용하는 Hard Parsing을 줄일 수 있다.

또한 이 일련의 작업이 개발자가 아닌 데이터 전문가에게 맡겨진다면 데이터 전문가와 개발 전문가의 의견 출동이 발생하는 경우를 현저히 감소시킬 수 있고, 각 전문가의 역량을 100% 발휘할 수 있도록 프로젝트가 올바른 방향으로갈 것이라는 기대감도 생기게 된다.

두 번째 방법에서 AP는 변경되지 않지만 SQL이 변경되어야 할 필요가 있을 때, 굳이 AP를 수정해 따로 배포할 필요가 사라진다.

프로시저화된 SQL을 수정해 재 컴파일한다면 다수의 AP에 산재해 있는 SQL을 찾아내서 모두 변경하고 배포해야 할 수고를 덜 수 있다.

우리는 프로젝트를 진행하면서 진행 도중 모델이 변경되는 경우나 성능에 의한 SQL 쿼리 변경을 해야 하는 경우를 많이 봐왔다. 특히나 프로젝트 진행 도중 모델이 변경되면 많은 개발자들의 원성을 받으며 그 원성을 진화해야 하는 경우를 다수봐왔고, 그로 인해 개발자들은 자신들이 개발해 놓은 프로그램을 수정하느라 밤샘 작업을 하곤 했다.

생각해 보면 모델이 변경된다고 해서 개발자들이 작성해 놓은 프로그램이 표면적으로 봤을 때 변경되는 것은 없다. 이 말은 단순히 화면에 뿌려주는 데이터가 변경되는 경우는 없다는 것이다.

하지만 개발자들이 밤샘 작업을 하는 것은 내부적으로는 변경된 모델에서 데이터를 질의하는 SQL이 변경되어야 하며, 변경된 SQL을 개발자들이 자신이 작성한 프로그램 코드에 적용해야 하기 때문이다.

하지만 이런 작업을 배제하고, 프로그램과 데이터베이스 사이에 입출력의 인터페이스만을 제공해 준다면 어떨 것인가?

이것은 몇 년 전에 IT 프로젝트 개발 방법론으로 유행했던 CBD 개발 방법론과 비슷하다. 각각의 모듈을 독립적으로 개발하되 서로 입출력의 인터페이스만 통일시킨다면 서로의 영역을 침범할 필요 없이 프로젝트를 수행할 수 있게 된다.

이때의 시너지 효과는 다음과 같다. 모델이 변경되어도 개발자 자신이 개발한 프로그램에 대한 변경은 최소화되게 된다.

변경 전 모델에서 데이터를 인출하는 SQL은 기존에 모두 데이터베이스내에 저장된 프로시저 또는 패키지 형태로 존재하고 있었고, 모델 변경 후, 변경된 엔터티에 의해 관련된 저장 프로시저 또는 패키지는 INVALID 상태로 변경될 것이다.

데이터 전문가는 그 INVALID 프로시저 객체 또는 INVALID 패키지 객체만을 찾아서 SQL을 수정해 주면 되고, 개발자는 자신이 개발한 소스에 대한 수정을 하지 않아도 되는 것이다.

이는 생각보다 큰 효과를 가져 올 수 있다. 또한 이런 것들에 의해 프로젝트의 성패가 충분히 좌우될 수 있다.

세 번째 방법에서 개발자들의 요청에 의해 데이터 전문가가 SQL을 작성해 프로시저 또는 패키지 객체로 저장하고 해당 객체명을 AP 개발자들에게 알려주면 된다.

그러면 AP 개발자들은 어렵다고 느끼는 SQL 작성에 많은 시간을 할애하지 않아도 되고, 최적의 AP를 개발하는 데 더 많은 시간을 할애할 수 있을 것이다.

전문 분야는 따로 있다

실 예로 필자가 프로젝트를 수행하면서 프로젝트를 함께 하던 개발자와 담소를 나눌 때 들었던 이야기가 있다. 그는 웹 프로그래밍을 전문으로 하는 개발자였고, 그의 고충은 이러했다.

항상 빠듯한 일정에 쫓기며 일해 온 그는 SQL 작성하는 것만 아니라면 좀 수월하게 개발 업무를 수행했을 거라는 것이다. 시스템의 데이터 모델 자체도 아직 이해가 되지 않는 상황에서 그 모델을 파악해서 데이터를 인출하는 SQL을 만드는 것이 그에게는 엄청난 스트레스였다. 그래서 SQL 하나를 작성하는 데 반나절 이상, 길게는 하루가 걸리는 것도 보아왔다.

하지만 그는 SQL이 만들어지고 난 후에 관련 웹 페이지를 만드는 것은 한 시간도 안 되어 척척 완료하곤 했다. 이는 개발자가 전문적으로 할 수 있는 분야는 분명히 있고 그 웹 개발자에게 전문 분야의 개발 업무를 맡겨야 하지만, 전문 분야도 아니면서 자신도 없는 SQL 작성 업무를 같이 병행해 일을 하다 보니 자신의 역량을 100% 발휘하지 못하는 결과를 낳았다. 그리고 항상 일정에 쫓겨 일하며 불만만 쌓여 갔다.

한가지 더 지적할 사항은 개발자가 자신의 역량을 발휘할 수 있는일이 아닌 상황에서의 SQL 작성은 항상 성능 이슈를 낳았고, 시스템 오픈을 얼마 남겨놓지 않은 상황에서 이는 더욱 부각되어 데이터 전문가를 포함한 모든 프로젝트 일원이 밤샘 작업을 해야만 했다는 것이다.

이 얼마나 비효율적인 프로젝트 진행 현실인가?

하지만 프로젝트의 발주업체 또는 용역업체에서는 비용을 절감해야 한다는 명목 하에 데이터 전문가들의 프로젝트 투입을 망설이고 있다.

이는 프로젝트 진행 중에 분명 문제가 부각될 수 있고, 그 후에 더 많은 비용을 지출해 하드웨어 증설이나 전문 인력의 투입을 통해 성능을 개선하곤 한다.

더 안 좋은 상황은 시스템 오픈 1~2년 만에 차세대 프로젝트를 진행한다는 것이다. 이는 결과적으로 보면 더 큰 비용 낭비일 것이다.

위에서 언급한 세 가지 예 이외에도 많은 부분에서 데이터 영역과 AP 영역을 분리하는 것이 훨씬 큰 이점을 갖고 있다. 또한 이런 영역 분리에서 오라클의 참조커서는 꼭 활용되어야 한다.

위의 내용을 포함해 가장 중요한 것은 데이터에 대한 처리는 AP가 아닌 DBMS 내에서 처리해야 가장 효과적이며 저장 프로시저를 활용한다면 그 효과를 극대화시킬 수 있다는 것이다.

실제로 필자는 이러한 방법으로 SI 프로젝트를 진행해 데이터 및 SQL 관리의 용이성을 얻고 오라클 데이터베이스 성능을 극대화하는 이점을 볼수 있었다.

- 강좌 URL : http://www.gurubee.net/lecture/2237

- 구루비 강좌는 개인의 학습용으로만 사용 할 수 있으며, 다른 웹 페이지에 게재할 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^

- 구루비 강좌는 서비스 제공을 위한 목적이나, 학원 홍보, 수익을 얻기 위한 용도로 사용 할 수 없습니다.

by 김정식 [2012.12.17 20:20:57]
개발 방법에 정답은 없으니깐 위와 같은 개발 방법의 장,단 점에 대해서 자유롭게 논의를 하는 것도 좋을 것 같습니다. 

by 김정식 [2012.12.17 20:22:06]
저도 2000년도 초반에 프로시저를 이용한 개발을 많이 해봤는데요..
프로시저를 이용한 개발 방법은 성능향상과 DB에 최적화 된다는 장점과 SQL 작성 롤을 DB 전문가가 책임진다는 장점이 있지만,
프로시저의 변경이력관리(버전관리)나 오류시 롤백수행등에 어려움이 있었고 프로시저 내에 비지니스 로직이 들어간 경우 업무파악에도 어려움이 있었던 거 같습니다.
어플리케이션에서 비지니스 로직이 관리가 되고, 프로시저에서는 비지니스 로직 수행을 위한 최소 단위의 SQL문만 패키지별로 관리하는 것도 괜찮다고 생각 합니다.

by 김정식 [2012.12.17 20:26:46]
개인적으로 개발자도 "권순용의 DB 이야기 칼럼"에 나오는 "1. 결합칼럼 인덱스와 단일칼럼 인덱스" 강좌를 정확하게 이해하고 활용할 수 있는 정도의 SQL문 작성 능력이 된다면 좋겠다는 생각을 많이 했습니다.

by 김정식 [2012.12.17 20:27:33]
 "권순용의 DB 이야기 칼럼"에 앞으로 좋은 내용이 등록될 예정인데요.. 개발자 분들께서도 꼭 정독하였으면 좋겠습니다.

by 아발란체 [2012.12.21 09:19:24]
국통(국가통합)DB구축 사업을 몇 개 했었는데 개발자가 거의 다 하더라고용,
J2EE 프로젝트에서 많은 인력이 투입되서 대부분 개발 시간이 프리젠테이션 5-10%, 프로시저 짜는데 90%.
한편으로 프로시저만 전문 짜는 분들은 아직 못 뵈었어요, 거의 개발자가 다 하더라고용.
지방이라 그런가 DBA 3분 정도 있었는데 튜닝 정도만 도와주는 정도.
근데 생각해보면 DBA(achitecture)와 개발이 분리 된다면
정도에 따라 DBA쪽이 알고리즘을 짜는 개발쪽, 개발은 퍼블리셔가 될 수도 있겠네용~ ^.^

by 라희파더 [2013.04.08 17:23:49]
좋은글 감사합니다^^

by 잠잠 [2013.06.26 17:25:57]
프로시저의 변경이력관리(버전관리)문제로 삼성계열 플젝에선 절대로 안합니다
식약청은 이글에 나온 대로 햇다고 들었습니다



by 라희파더 [2013.08.08 09:47:11]
글내용 대로 한다면 업무영역이 확실해 질거 같은 생각도 들긴하지만

실제 프로젝트 에서 프로젝트를 수행하다보면 SQL 에 비즈니스 로직이 녹아 들어가 있기때문에 

이론상으로는 충분히 가능할거 같지만 막상 부딪히게 되면 쉽지 않은 작업일거 같은생각이 듭니다. 

제일 베스트 케이스는 개발을 진행하는 개발자가 어느정도의 SQL 실력을 갖추는게 관건 이라고 생각됩니다.
댓글등록
SQL문을 포맷에 맞게(깔끔하게) 등록하려면 code() 버튼을 클릭하여 작성 하시면 됩니다.
로그인 사용자만 댓글을 작성 할 수 있습니다. 로그인, 회원가입