Framework (개요)

Database Framework를 작성한것은 사실 우연한 계기였다.
2003년 모회사에  입사하자마자 새버전의 솔류션 개발에 DBA로서 참여하게 되었는데 이전까지 DB전문가가 없었던 관계로 주로 하게될 역할은 모델링과 기초 설계 담당이었다.

그때까지 몇개의 웹스크립트와 몇개의 언어를 필요에 의해 겉핧기로만 알고 있었을뿐 개발자보다는 DBA나 모델러로서 오랫동안 일을 했기 때문에 자바의 실력은 아주 별로였다. (게다가 당시 내 주력언어는 VB와 C#이었다.) 고작해야 몇가지 패턴책을 보고 이것저것 몇가지 흉내만 가까스로 낼수 있는 정도였으니까.

이전버전의 제품은 수많은 버그와 유지보수의 문제로 몸살을 앓고 있었고 새로운 팀은 이러한 문제를 벗어나기 위한 한가지 방법으로서 System Framework를 먼저 제작하고 그 후에 비즈니스 요구사항을 가진 제품을 올리기로 합의하였다. 시간이 그리 넉넉하진 않았고 팀 자체가 새로 결성되었기에 먼저 팀는 인터넷의 여러 오픈소스 - 주로 아파치와 소스포지를 참고 - 를 참고하여 베이스로 깔고 목적에 맞게 보완/수정하는걸 기본전략으로 하였다.

당시 나는 CMS 도메인에 대해 기본지식이 없었기 때문에 인터넷이나 이전 버전을 참고하면서 논리적 디자인과 물리적 디자인 그리고 기초 데이타를 얻기위해 DB에 수천만간의 테스트 데이타를 작성해놓고 기초 성능 테스트를 하고 있었다.

문제가 생긴건 팀이 셋팅되고 한달쯤 지나 DB 디자인이 어느정도 확정이 되고 개발팀에게 ERD를 작성하여 모델 디자인을 설명하고 작성중이던 Framework 소스를 보게 된때였다. 그때까지는 개발자도 아니고 자바개발에 비교적 무심하였기 때문에 그냥 데이타베이스 쪽은 어떤가 하고 그냥 훓어봤을뿐이었다. 아마 그때 팀은 아파치 오픈소스인 현재의 common-dbutils의 모테인 릴리즈 이전버전을 사용하고 있었다. 지금 생각하면 우습지만 당시에는 커넥션 풀링을 쓴다는게 어려웠던 시절이고 마치 그게 대단한 기술로 보였던 시절이었다.(DB라는 리소스 특성상 커넥션하는 소스에 아주 조그만 버그만 있었도 프로그램이 중지되었으니까..) 그래서 커넥션 풀링이 된다는 것만으로 common-dbutils은 개발자들에게 아주 합당한 선택이었다. 

무심코 소스를 보게 된거지만 common-dbutils은 말 그대로 utility library일뿐 개념상으로 전혀 프레임워크가 아니었을뿐더러 만약 이 라이브러를 쓰면 DB의 대부분의 기능을 쓸수 없게 되리란걸 알게 되었다. 지금도 그렇지만 그때도 DB를 블랙박스로 다루어야 한다는 사상이 팽배해 있던 시절이라 "프로시저? 그거 특정 DB에만 있는거잖아 그걸 쓰면 안되지" 라던가 "DB 함수 그게 먼데? 그보단 일단 읽어서 자바 함수로 처리하자" 등등의 생각들이 지배하고 있었다.

이전글에서도 언급은 한적이 있지만 DB를 블랙박스로 다룬다는 것이 DB의 공통기능만을 써야 한다는 걸 - 이를테면 Ansi SQL만을 사용한다 등의 - 의미해서는 안된다. 오히려 DB와 상관없이 DB에 있는 모든 기능을 최대한 이용할 수 있는데까지 이용해야 한다. 물론 지금도 나아진게 없긴 하지만 DB를 단순히 저장매체의 종류로서만 사용한다면 DB가 수천만원을 호가할 이유가 없다.

어쨌거나 그걸 보고 팀장을 찾아가 이 프레임워크는 이런저런 문제가 있기 때문에 다시 설계/개발을 해야한다고 찾아가서 따지기 시작했다. 돌이켜 생각해보면 팀장으로서는 아마도 황당했으리라-ㅅ- 웬 처음 합류한 DBA가 몇시간 소스를 훔쳐보더니 개발이 어쩌고 저쩌고 하며 당시의 주류와는 다른 이상한 얘기를 해댔으니까. 삼사일간이나 이 문제로 투닥투닥 거린끝에 결국 "그럼 니가 한번 해보세요-ㅅ-"로 결론이 났고 자리로 돌아와선 괜히 말했나-ㅅ- 라는 후회가 슬쩍 들기도 하였지만 당시의 나는 고생끝에 작성한 DB 모델이 개발 소스의 요구에 의헤 훼손당하고 싶지 않아 오기를 부렸다.

그래서  주말에 이틀 날밤까고-ㅅ- 만든게 이 DBFramework 였다. 50개 안팍의 클래스가 6년동안 조금씩 기능이 추가되면서 약 150개의 클래스가 되었지만 기본 디자인은 전혀 바뀌지 않았다. 맨바닥 헤딩이었이면 훨씬 더 걸렸겠지만 이전에 C#으로 DCOM용으로 DB Framewor를 만들어본적이 있었고 그걸 1년동안 사용하면서 여러가지 단점에 대해서도 느낀바가 있었기 때문에 개념적인 문제보다는 Java라는 언어 때문에 고생하였다. 그 후로 어쩌다 보니 쭉 개발일도 하게 되면서 이제는 DBA보다는 개발자라는 명칭이 더 익숙하니 이 일은 내 IT 인생에 일종의 전환점이 되었다. 물론 딱히 좋은 전환점은 아니라고 쭉 생각하고 있긴 하지만 말이다 -ㅅ-;

당시에는 명확하게 정립이 된건 아니었지만 그 때에도 최우선했던 한가지는 실험실 코드의 분리였다. 다른 프레임워크와 마찬가지로 데이타베이스 프레임워크도 실제 코드에 쓰이기 위해서는 처음에 고려하지 못했던 다양한 요구사항들이 추가된다. 이를테면 SQL의 추적기능이 있어야 한다든가 느린 SQL은 취소할 수 있는 Undo 기능이 있어야 한다든가 로그 기능이 있어야 하거나 설정값을 조절할 수 있어야 한다든가 등등의 현실적 요구사항들이 나중에 스물스물 생겨나게 되는데 절대로 설계시 그러한 요구사항을 미리 고려해서는 안된다는 것이다. 

위 그림은 흔히 나오는 컴포넌트 디자인의 예이다. 오른쪽은 복잡도가 클래스에 비례하기 때문에 높은 반면에 왼쪽은 복잡도가 그리 높지 않다. 당연한 얘기이긴 한데 왼쪽과 같이 나누기 전에 먼저 고려해야 하는 것이 있다. 

멋지게 3차원 그림을 표현하고 싶지만능력이 안되니 위쪽과 아래쪽 컴포넌트를 높이에 따른 3차원이라고 생각하자 -ㅅ-
이 차원의 존재는 "관련있는"의 기준이 아닌 실험실과 비실험실의 차원이다. 물론 이것도 하나의 레이어의 일종이지만 별도의 차원으로 얘기하는 것은 이 차원이 가지는 특별성 때문이다. 

미리 나중에 생길지 모르는 비지니스 요구 사항을 대비하는 디자인이라는 것은 언뜻 그럴듯 해보이지만 사람은 앞으로 생길지 모르는 추가 요구사항을 고려하는 것 자체가 예언만큼이나 힘들고 그러한 것을 한다고 해도 불필요하게 과도한 복잡한 디자인을 유발할 가능성이 높다. 앞으로 나올 요구사항에 대비해야 하는 확장 가능한 디자인은 되려 간결한 설계에서 나오는 표현력을 떨어뜨리고 비지니스 정보의 확장 포인트가 중간에 끼어듬으로서 효율성을 감소시킨다.

프레임워크를 처음 만들때 가장 먼저 생각해야 할 분리 원칙은 비즈니스 요구사항과 상관없는 코드의 분리를 통한 미니멀리즘이다. 모든 일체의 기능적 요구사항은 무시하고 비기능적 요구사항 - 효율성, 테스트 용이성 등을 먼저 고려해여 레이어를 분리해야 한다. 그리고 이런 비기능적 요구사항이 구현될 실험실 레이어 부분을 현실 환경과 분리시켜야 한다.

위의 UML은 중요한 클래스의 Overview인데 파란색 사각형이 계속 말하는 실험실 코드이며 만약 비지니스 요구사항이 생긴다면 파란색 부분이 아닌 빨간색 부분에서 확장을 해야 한다.