DA 조직의 구성에 대하여

필자의 후배들이 몇몇 업체의 DBA를 담당하는데 차세대 프로젝트에서 DA 조직의 구성방법에 대하여 가끔 필자에게 질문이 들어오곤 한다.
이때 필자는 반드시 아래의 구조를 가지게끔 답변을 한다.

1.CIO 는 반드시 DA팀의 수장이어야 한다.
2.전사적인 관점에서 DA 조직의 팀은 크게 7으로 나뉘어야 한다.
-표준화팀: 단어사전, 용어(속성)사전, ERD 표준, SQL 표준 , 프로그램 언어의 표준등 각종 표준정의및 관리
-모델링팀: 업무파악, 개념모델및 논리/물리모델 정의 및 관리
-DBA팀 : DBMS 종류별로 오브젝트의 생성및/관리, 오브젝트별 권한관리, 오프젝트별 용량관리, 백업/복구관리, DBMS 버그페치
-튜닝팀 : 쿼리및 오브젝트, 인스턴스의 최적화
-SYS ADMIN 팀:운영체제 관리및 최적화, 디스크 최적화(스트라이핑)및 관리, 네트워크 관리, OS 버그페치등
-데이터 보안및 품질팀: 기업의 데이터 품질이나 보안(DBMS내의 각종권한 정책 및 데이터 암호화등)에 대하여 관리
-전환팀 : 기존 NDB/HDB/RDB 의 데이터를 Cleansing및 매핑 하여 TO-BE 시스템으로 이관
3.DA의 각팀에는 반드시 권위있는 갑의 직원이 상주해야 한다.
4.DA의 각팀의 구성원은 반드시 해당하는 분야의 전문가 이어야 한다.
5.DA의 각팀은 반드시 긴밀히 협조해야 한다.

1번을 명시한 이유는 권력이 없는 수장이 관리 하는 DA 조직은 항상 불안하고 불필요한 논쟁이 끊이지 않을것이다.
예를 들면 표준화팀에서 표준을 배포해도 개발팀에서 이런저런 이유로 따르지 않을것이고 시간이 지나서 프로그램의 품질및 성능은 보장받지 못할것이며 그럴경우 관리자들은 누구의 책임인지 추궁하게 될것이다.

2번의 팀구성은 항상 7개의 팀으로 구성될 필요는 없다.
예를 들면 차세대 시스템의 분석단계에서는 표준화팀과 모델링팀은 필수적이고 나머지팀은 선택적일수 있다.
또한 개발단계에서는 튜닝팀과 데이터보안/품질팀이 필수적이며 이 필수적이며 세팅이 끝난 SYSTEM 팀은 선택적일수 있다.
OPEN 전단계에서는 전환팀이 필수적이다.
이처럼 단계별로 DA 조직을 늘였다 줄였다 할수 있으나 반드시 단계별로 필수적인 팀을 구성하여 운영하여야 한다.
또한 SYS ADMIN 팀은 사실상 DA 팀으로 볼수 없으나 운영하지 않을경우 DA 팀이 다치는 경우를 많이 보아왔다.
예전에는 요구가 거의 없다시피 했으나 최근에 특히 필수적으로 구성되는 팀이 데이터의 보안및 품질 팀이다.

3번을 명시한이유는 차세대프로젝트의 전형적인 문제점 때문이다.
다시말하면 갑의 요구와 컨설팅의 결과를 분석/설계/개발 하는것이 을의 할일 이지만 그것을 하기위해서는 반드시 갑의 도움이 있어야 한다.
예를 들면 모델러가 AS-IS 모델을 분석해야 할때 갑의 담당자가 없다면? 아마 팀마다 돌아다니면서 ERD 를 받아야 할것이다. 필자도 ERD 및 각종 분석에 필요한 문서를 수거하는데 3주나 걸린 뼈아픈 경험이 있다. 이것 때문에 WBS 상에 분석이 2주가 밀려 버렸다.
ERD와 각종문서를 를 받아야 할 당위성같은 문서를 작성해야 했으며 각종 문서별로 보안등급이 있어 부서마다 처음보는 업무요청서를 작성해야 했으며 부서중에서 1/3 정도는 보안관계상 문서를 주기 어렵다고 기각당하기 까지 했다.
반드시 권위있는 갑측 직원이 팀원으로 구성되어야 한다. 그리고 갑측직원은 반드시 전문가일 필요는 없다.

4번을 명시한 이유는 말하지 않아도 알것이다.
모델러를 잘못 선택한 순간 데이터의 구조가 엉망이 되고 튜너가 실력이 없으면 성능이 떨어지고 결국 DBMS 가 멎을 것이다. 또한 전환팀이 부실하면 데이터 이관작업이 몇년이 걸릴수도 있고 보안팀이 부실하면 OPEN 후에 해킹을 당할수도 있다. 똑똑한 DBA는 장애에 대한 계획을 세우고 장애시 모든데이터를 살린다.똑똑한 몇명이 전체 기업을 살릴수도 똑똑하지 못한 몇명이 전체 기업을 죽일수도 있다.

5번을 명시한 이유는 DA 팀의 각각의 팀원들은 전문가 들이고 또한 자존심 또한 매우 많은 편이다.
불필요한 논쟁을 하다보면 서로가 다치게 된다.
여러분도 알고있는 전형적인 논쟁을 예를들면 물리모델링 할때 모델러와 DBA 간의 싸움은 끝이없다.
최소한 같은 DA 조직내에 있는 팀원모두는 모를지라도 각팀의 PL 들은 서로를 잘알고 친해져야 할필요가 있다.
생각해보라 SQL 표준을 표준화팀에서 만들었고 그것을 어기면서 SQL 을 튜닝하는 튜닝팀이란...

1번부터 5번까지 반복적인 답변을 너무도 많이 하여 이제 는 외울(?) 지경이다
다행인것은 최근의 대형금융권 혹은 대형통신사의 차세대 프로젝트는 거의 필자의 구성법과 비슷하게 가고 있다는 것이다.
꼭 대형 업체(금융권이나 통신사)들의 차세대 시스템 구축이 아니더라도 여러분들이 IT 관련 일을 하고 있다면 나름대로 DA 팀을 구성 해보기 바란다.
어느자리에 누굴 쓸것인가? 혹은 내가 어느자리로 갈것인가?
DA 조직이란것이 21세기에 들어온이상 꿈같은 이야기만은 아닐것이다.