DB를 어떻게 사용할 것인가? (How to use your DB)

데이터베이스(DB), 정확히는 데이터베이스 매니지먼트 시스템(DBMS)는 현대 자료구조 시스템의 가장 활성화된 형태이다. 그리고 한가지 일만 잘하도록 만든다(Do the best thing you can do) 라는 원칙에 따라 DBMS는 n-tier 구조에서 데이터부분을 책임지는 핵심 요소로 꾸준히 발전되어 왔다.

<느닷없는 참고 그림, Facebook용 DB Schema, 크게 보려면 클릭>

정말 많은 발전을 이루었다. DBMS를 이용해서 할 수 있는 일들이 정말 다양해 졌다. C도 집어삼키고(Pro*C), JAVA도 집어삼켰다. 작성할 수 있는 쿼리(Query)도 버전이 늘어가면서 점점 늘어나고 있다. 예전에는 어렵게 코딩해야 했던 기능들이 내장 함수 한 두개면 한방에 해결되는 사례도 적잖이 있다.

이를테면 어떠한 학생이 있고, 이 학생의 기말성적보다 바로 윗 성적의 학생, 아랫성적의 학생의 몇가지 정보들을 찾고자 하는 경우가 있다고 치자. 예전 같으면 다양한 방식이 시도될 수 있었겠지만, 현재 O모사 DBMS의 경우 lead, lad 라는 함수를 사용하면 sql 문장 하나로 처리가 가능하다. (이정도면, 글자 잘라내기 치환하기 류의 소극적 처리는 언급할 필요도 없다고 본다)

http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/functions001.htm#i88893

위 링크는 유저 정의 함수와 패키지로 제공하는 기능를 제외한 일반 함수의 목록이며, 개인적으로 230개 까지 세다가 그만두었다. 외운다고 외워질 문제의 수준이 아니다.

어디, 비단 이뿐이겠는가?

벤더별 차이는 있지만, DBMS의 발전된 내장 기능을 쓰면 뽑아내기 어려운 자료형태가 손쉽게 나온다.

정말 좋다. 그리고 DBMS을 쓰면 쓸수록, SQL를 쓰면 쓸수록 그 놀라운 기능에 감탄을 하게 된다.

아!

그런데, 안타깝게도 비극은 거기에서 출발한다.

DBMS의 놀라운 기능들, 특히 자료를 뽑아내는 형태의 업무에 있어서 그 막강한 내장 기능들을 자주 사용하다 보면, 다크포스에 빠진 스타워즈의 아나킨 스카이워커처럼 되버리기 쉽다. (뭔소리니냐 이건?-_-)

<"You don't know the power of the Dark Side." >

(어디까지나 주관적이지만) SW개발에 있어서 가장 흔하고 가장 강력한 커플링은 SQL에서 온다고 본다.

소스레벨의 커플링은 고작해봐야, 클래스 몇개, 변수 몇개 수준이지만, SQL에서 오는 커플링은 최악의 경우 서버 박스가 왔다 갔다 하게 만드는 수준이기 때문이다. DBMS 내장 기능을 써대면 써댈수록 해당 DBMS를 벗어나기 어렵게 만든다. 가끔씩 개발좀 했다 싶은 분들, 특히나 평소에 쿼리좀 뱉었다 싶은 분들 중에

'이거 XX DBMS에선 지원되는 쿼리인데, YY DBMS에선 지원이 안되네. 역시 꼬졌...'

식으로 이야기 하는 걸 보곤 한다.

1/3 정도만 맞다고 생각한다.

쓸수 있는데 안쓰는 거랑, 쓸수 없어서 못쓰는 거랑의 차이가 그 1/3이다.

약간 딴 얘길 해보자.

ANSI SQL이라는게 있다. (버전에 따라 다르지만, 여기에선 SQL:1999를 기준으로 삼기로 한다)

SQL문을 표준화 해서 사용하기 위해서 ANSI에서 만들었다. 한, 10년 되었는데, O모사 DBMS가 가장 지원이 늦었다.

왤까?

여러가지가 이유가 있겠지만, (설마 기술력이 딸려서? No way!!)

시장 점유율이 가장높은 O라클 입장에선 개발자들과 강력한 커플링을 형성하고 있는데, 굳이 표준구문 지원해서 이전을 쉽게 만들 필요가 전.혀 없는거다. 오히려 점점더 하드코어하고도 중독성 있는 방향으로 진행했다. (오라클 지원 함수중 analytic function 시리즈를 보라!)

미친듯이 객체지향을 공부한 듯한 포스의 SW아키텍트와 또 잘하는진 모르겠지만 좌우당간 모시기 힘들었다는 모델러들을 데려다가 개발을 했는데, 이상하게 다양한 재사용이 힘든경우가 많다. 모르긴 몰라도, 그 중 으뜸은 DBMS 관련쪽이라고 본다. DBMS 바꾸는 작업을 엄두내는 곳은, 프로젝트가 마왕의 소굴이라 도저히 안되겠다 싶어 용자들을 불러 모은 곳 정도라고 본다.

하여튼 커플링은 나쁘고 DB커플링은 한층 더 나쁘다!

<물론, 이런 커플링이라면 예외겠지만...>

또 다른 얘길 하나 더 해보자.

개발자들도 바보가 아니다. 지금 내가 말한 내용이 지구상에서 처음으로 하는 이야기일리가 없잖은가?

Oh, Really Man? ORM ?

DBMS 커플링은 내가 다 없애 주지! 하면서 나온게 ORM(Object-Relational Mapper)라고 불리는 녀석이다.

DBMS는 신경쓰지마. 내가 다 해줄께. 대신에 넌 Entity 모델에만 신경써!

어떤 의미로 끝내주는 개념이다.

하지만 그건 외국얘기고, 우리나라에선 아직은 활용이 미미하다. 그리고 앞으로도 당분간은 미미할 예정이다.

- 첫째, 기술자체가 낯설다.

일이 빡세서 공부할 시간이 없다는 가슴아픈 사연을 필두로하는 다양한 이유로 배우기 어려워하고 있다.

- 둘째, DBMS에 종속적인 쿼리로 성능을 쥐어짜내는 형태의 SQL 개발에 익숙해진 DBA, 개발자들이 보기엔 문제가 있어 보인다.

- 셋째, 유지보수에도 해당 기술에 대한 이해자가 없으면, 뒷감당이 안된다.

뭐, 그 외에도 자세히 들어가면 자잘하게 많겠지만, 그런거 얘기 하는 자린 아니니까 이쯤하자.

정리하자면 DBMS 커플링을 줄이기 위해서 ORM 을 쓰자! 도 현재는 답이 아니라는 거다.

그럼 방법은?

자, 이제부터 내가 하고자 하는 내용이다.

DB를 어떻게 사용할 것인가? (How to use your DB)

그럴 듯한 제목에 비해 사실 정확한 답은 없다. 대신 개발자가 지키면 보답을 받을 수 있는 원칙은 있다.

여기에서 몇 가지만 소개해 본다.

1. DBMS는 단지 데이터가 저장되어있는 Persistence BOX라고 생각한다. 다양한 기능을 지원한다고 해서 '유후! 옳다쿠나!!' 하고 쓰면 곤란하다. CRUD용 BOX라고 생각하자. 이건 머리속에 넣는 컨셉으로 개발의 방향을 일정하게 유지시킬 수 있게 해준다. 2. 최대한 간결하게 쿼리문(SQL)을 짠다. 쉬운 쿼리가 좋은 쿼리다. 다른 개발자의 이해도 쉽게 만들고, 튜닝도 쉽게 만들어 준다. 이건 절대 법칙에 가깝다. 오해의 소지가 있는 말이지만, 당신이 쓰는 메일이 당신 것이 아닌것처럼, 당신이 작성하는 소스도 당신을 위한 것이 아니라는 생각을 갖는게 좋다. 3. SQL로 비즈니스 로직을 구현하려 들지 말자. 가끔보면 교묘한 SQL로 비즈니스 요구사항을 해결해서는 '후훗!' 하고 있는 걸 보는데, 부디 다시 한번 잘 생각해 보기 바란다. MVC 모델이란게 왜 나왔는지를 말이다. (실제로 분기문과 함수가 천상의 하모니를 이루어서 SQL 하나가 A4 6장 분량을 넘어서는 걸 본적이 있다. 짠 사람은 이미 인간 한계선을 돌파했다고 보는데,결국 수정도 튜닝도 저 하늘 멀리 머나먼 곳으로 가버렸다. - 새로 다시 짰다)

이 외에도 더 막 생각날려고 하는데, 접기로 한다. 위, 세가지만 지키면서 DB를 다뤄도, 품질이 높아지고, 미래에 대한 대비가 가능해 진다. 아주 기초적인 원칙인데, 놀라운 성과가 나올수 있다.

희안한건, 기술이 발달하다 보면, 다양하고 놀라운 기교로 점철되다가 어느 순간엔가는 다시 소박한 모습이 되어서는 최선이 무엇인지에 대해 다시 생각해 보게 만드는 현상이 있다.

무예를 닦으면 닦을 수록 동작이 간결해 진다던가, JAVA진형의 POJO로의 귀환이라던가 하는 식으로 말이다. (비약의 간극이 너무 컷다면 양해를:)

<One Kick, One Kill?>

어쨌든,

기교를 접고 간결함을 추구하며, 남을 생각한다...라는 건

굳이 개발이 아니더라도, 덕목으로 삼을만 하지 않은가?

뭐, 아님 말고!

PS. ORM 에 관심있으신 분은 http://wiki.javajigi.net/pages/viewpage.action?pageId=5924 에도 한번 가보심이. (^_^);