아시다시피 업무개발, 속칭 SI 개발에서는 DB의 성능이 전체 시스템의 성능을 대부분 좌우합니다.
애플리케이션 자체의 응답 속도는 대단히 빠른데 디비에서 데이터를 쿼리해오고 또 인서트, 업데이트하는 데에 많은 시간이 걸리니까요.

제가 여러번 프로젝트를 하는 동안에도 이런 면 때문에 종종 델파이/C++빌더 애플리케이션 자체보다 DB 최적화에 더 신경을 많이 쓰기도 했습니다. 덕분에 쿼리 튜닝도 주먹구구식이긴 하지만 꽤나 할 수 있게 되었고, 디비의 설정이라든지 그런 것들도 많이 살펴보게 되었습니다.

그런데 저번 회사, 얼마전에 그만둔 회사가 데이터베이스 성능관리 전문입니다. 그래서, 데이터베이스의 성능 관리에 있어 쿼리 튜닝과는 다른 또다른 레벨을 좀 맛보고 나왔습니다. 회사에서 출간했던 데이터베이스 성능관리 관련 고급 서적들도 여러권 갖고 나왔는데, 요즘 짬짬이 보고 있습니다. 회사 다니는 동안에는 제대로 신경쓰지 못했던 기술들이 시간 여유를 가지고 살펴보니 꽤 재미있더군요. 무릎을 탁 치게 만드는 부분들도 꽤 있습니다.

델파이/C++빌더로 진행하는 업무 개발이 적지 않지만, 상당수가 중소규모 프로젝트죠. 대형 프로젝트는 다수가 자바로 진행되고 일부는 닷넷으로 진행되기도 합니다. (그래도 아직 닷넷의 입지는 자바에 비교할 바가 못되죠) 그러다보니 전문 DBA나 모델러 등 데이터베이스 전문가가 따로 있는 프로젝트는 거의 들어보지 못했던 것 같습니다. 작년 중반까지 다녔던 듀오에서도, 제가 상당히 경험이 있는 직원 한명을 DBA로 지정하고 그리로 키우려고 무지하게 애를 썼는데 회사측의 비협조로 별로 성과가 없었습니다.

결국, 델파이/C++빌더로 진행되는 프로젝트들의 다수는 개발자가 DB 아키텍처와 성능 부분도 함께 떠맡고 가게 되는 경우가 흔해집니다. 이건 뭐, 비단 델파이/C++빌더 뿐만 아니라 자바에 비하면 윈도우쪽 프로젝트가 대부분 중소규모이고 디비 전문은 따로 없는 경우가 비일비재합니다.

이전 회사의 SQL 서버 전문 컨설턴트들이 컨설팅을 나가서 가장 애로를 느끼는 점이, 오라클쪽과 달리 해당 사이트에 DBA가 아예 없거나 있어도 전문성이 떨어진다는 점, 그리고 개발자가 디비를 같이 맡고 있는 경우가 흔해서 결과적으로 디비 컨설팅 외에 애플리케이션 개발에 대한 컨설팅도 함께 진행해야 하는 경우가 잦다는 점이었습니다.

결과적으로, 우리 포럼에도 업무 개발을 하시는 분이 꽤 있으실 텐데요. 디비 성능 관리는 어떻게 신경쓰시고들 있으신지요? 사용하는 디비도 오라클에서부터 MS SQL 서버, 파이어버드, MySQL 등 다양하실텐데요. (아마 DB2는 거의 없을 듯)

음... 혹시 큰 장애만 안생기면 돌아가는 대로 그냥 둔다?
아니면... 나름대로 열심히 찾아보고 해서 여러가지 시도를 해본다?

그러나저러나... 제가 프로그래밍에 입문하던 90년대 초부터 데이터베이스가 중심인 개발은 제일 하기 싫었던 분야였는데, 어떻게 살다보니 몇년새 업무 개발과 데이터베이스 전문 비슷하게 되어버렸습니다. 참 산다는 건... 알쏭달쏭하죠?