대한민국에서 개발자라고 불리는 사람들 중'데이터베이스', '오라클'이라는 명칭을 모르는 사람은 없을 것이다. 하지만 데이터베이스에 대한 정확한 이해 없이 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로 보낼 수 있도록허용한다.

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

• - 개발자의 부주의로 인한 성능 저하 및 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 관리의 용이성을 얻고 오라클 데이터베이스 성능을 극대화하는 이점을 볼수 있었다.