성공적인 차세대 시스템 구축을 위한 DA의 역할은

데이터 관리 프로세스의 정립이 선행되어야!

차세대 시스템 구축을 진행하다 보면 구축되는 시스템 규모에 따라 달라지지만 대부분 많은 인력과 다양한 업무 관계자, 거기에 여러 회사가 함께 모여서 수행하게 되는 경우가 많다. 이러한 복잡한 구성 속에서 DA가 성공적으로 그리고 효과적으로 업무를 수행하기 위해 필요한 것은 무엇일까

모델링 담당 DA는 모델링 규칙에 맞춰 데이터 정합성을 고려하고 성능 개선을 고려한 모델을 그리는 능력 표준 담당 DA는 명확한 표준 사전과 규칙을 구축해 놓는 것

물론 모델링을 잘하고 표준을 잘 정의하는 것은 중요하다. 하지만 그것만이 전부는 아니다. 개개인이 해야 하는 업무들을 모두 모았을 때 전체 프로젝트가 완료되기까지 필요한 모든 스텝이 빠짐없이 구성이 될 때 비로소 성공적으로 DA 업무를 수행 했다라고 말할 수 있다.

과거 많은 프로젝트에서 처음 시작할 때 ISP 혹은 선행 사업으로 데이터 표준, 메타 시스템 구축 등을 잘 해놓고도 실제 차세대 기간 동안에는 표준을 무시하고 진행하여 결국 최종에는 AS-IS와는 별반 다르지 않은 주먹구구식의 데이터가 만들어져 있는 경우를 볼 수 있었다.

이는 표준 혹은 DA 방법론을 문서화하고 산출물화 하는 것에 만족하고 실제 적용에 대해 관심을 가지고 강제화하는 관리 프로세스가 없기 때문에 나타나는 결과이다.차세대 프로젝트는 다양한 사람들이 매일 매일 변경되는 업무 속에서 시간의 제약을 받으며 진행된다. 이런 비상 상황에서 “자신의 일”도 아닌 일에 관심을 가지고 전체 프로젝트를 위해 헌신하는 구성원을 기대하는 것은 관리자 그리고 고객사의 욕심일 뿐이다.

그래서 필요한 것이 차세대의 특성에 맞는 업무 정의, 관계자들간의 역할 정의, 업무 진행 프로세스 정의와 같은 관리 프로세스의 정립이다.

일반 운영 시점과는 다른 차세대 구축 프로젝트에서 고려할 점을 몇 가지 정리해 보면 아래와 같다.

1.다양한 이해관계자
-다양한 수행인력, 다양한 회사들이 함께 모여서 진행된다. 그리고 수시로 인력이 교체된다.
-같이 업무를 협의하고 진행하는 당사자들이 대체로 고객사의 직원이 아니다. 즉 최종 결정에 대해 책임을 질 수 없는 이 프로젝트를 위해 한시적으로 모인 프리랜서들의 집단이다.

2.빈번한 변경 업무
-기존 시스템을 운영하면서 발생되는 것 보다 더 많은 빈도로 신규 추가/변경 등이 발생한다. 심지어 표준 정책마저 바뀌는 경우가 있다.

3.수행사 계약에 따른 업무 범위의 한계
-사업 전체를 계약한 주관 수행사의 입장은 다르겠지만 일반적으로 큰 규모의 프로젝트에 “병”으로 참여하는 수행사는 일부 업무만을 수행하는 “계약”을 하고 수행한다. 이 계약으로 정해진 업무와 업무들 사이에 빈 틈이 생기는 경우가 빈번하며 이러한 빈 틈이 사전에 인지되지 않으면 차세대 참여하는 구성원들을 피곤하게 만들고 서로의 감정을 상하게 만드는 일이 생긴다.

위 3번의 한 예로, 예전 수행한 프로젝트에서 DA 팀과 DBA간에 “SQL 튜닝” 업무를 놓고 긴 줄다리기를 한 경험이 있었다. DA 수행 업체는 표준 관리, 모델링을 업무 범위로 계약을 하고 투입되었고 DBA는 DBMS 관리 업무를 범위로 계약을 한 상태였다. 이 중 누구도 “SQL 튜닝”에 대해 책임을 지지 않으려는 상황이었고 이후 개발이 진행되는 시점에 고객사가 나서서 “전문 튜너”를 별도 계약했지만 이 “튜너”를 관리하겠다고 나서는 팀이 없어서 문제가 해결되지 않는 상황이 계속되었다. 이전까지 하지 않던 관리대상에 없었던 업무이고 관리를 한다는 것 자체가 책임을 가져가는 상황이라 인식되었기 때문이었다.

이와 같은 차세대 프로젝트의 특수성을 고려하여 본 글에서는 DA 업무 중 변경 관리 중심으로 업무, 이해관계자, 이해관계자간의 R&R 등에 대해 이야기 하고자 한다. (기본적인 업무 - 초기 논리/물리 모델링, 표준 정비 작업 등 -은 완료 된 이후 작업만 대상)

▣“일을 할 수 있는 사람이 누가 있는지 알아야 일을 배분할 수 있다” : 이해관계자 확인
차세대 프로젝트라고 해서 모든 세부 조직과 담당자가 있는 것은 아니다. 프로젝트 규모에 따라 혹은 프로젝트 방법론에 따라 다양한 조직과 이해관계자가 존재할 수 있다. DA 조직을 예를 들면 전문 모델러들을 DA 조직에 포함해서 모델 설계를 맡기는 경우도 있지만 전문 모델러 없이 설계자들에게 모델링을 맡기고 소수 인력의 통합 DA 혹은 DBA가 관리하는 경우도 있다. 또한 데이터 보안 관련 결정을 고객사 보안 팀에서 정책을 결정하는 경우도 있지만 고객사 담당 현업이 직접 결정하는 경우도 있다. 이렇듯 다양하게 나타날 수 있는 현재 프로젝트의 이해관계자에 대해 먼저 파악을 해야 다음에 이야기되는 “업무”를 누가 할 것인지를 머리 속에 그릴 수 있게 된다.

아래 표는 이해관계자를 나열한 예시이다. 이 예시에서는 개발, DBA조직과 분리된 전문 DA 조직(모델러 포함)이 있는 것을 기준으로 하였다.



이해관계자를 정리하는데 있어 기억할 점은 “업무구분” 별로만 이해관계자를 정리하는데 그치지 않고 “수행사/고객사”별로 이해관계자를 정리해야 한다는 점이다. 실제 업무는 수행사에서 한다 하더라도 결국 최종 결정은 고객사에서 해야 하는 것이다. 통합 테스트, 인수테스트, 프로젝트 검수와 같이 굵직굵직한 사안에 대해 도장만 찍는 것이 고객사 담당자의 역할이 아니다. 표준 단어 변경, 테이블 추가와 같이 조그마한 사안이라 하더라도 고객이 결정해야 하는 것이다. 물론 DA 전문가의 의견을 듣고 결정하는 것이긴 하지만 고객의 역할이 빠져서는 안 된다.

▣“일할 사람들을 모아놨으니 이제 어떤 일을 해야 할 것인지를 알아보자”:차세대 구축을 하면서 발생되는 DA업무 정의
한번 고생해서 만들어 놓은걸 그대로 쓰면 좋겠지만, 대부분의 차세대 프로젝트에서는 많은 것들이 바뀐다. 신규 추가는 당연히 발생되는 것이고 잘 쓰던 걸 바꿔야 한다던가, 잘못 정의된 혹은 설계된 것들이 있으면 과감히 삭제해야 한다. 어떤 일들이 일어 날 것인지를 사전에 정리할 수 있다면 업무 진행의 혼란을 최소화할 수 있을 것이다.

아래 예시는 DA 업무 중 빈번히 발생되거나 발생 시 영향도가 높은 업무들을 정리한 예시이다. 예시에서 보면 일부 타 영역의 업무로 판단되는 업무들이 존재한다. 하지만 그 업무가 DA 영역의 업무가 아님을 명확히 하기 위해 서라도 업무 목록을 정리하는 것이 좋다.



업무를 정리하면서 고려할 점은 해당 업무를 진행함으로써 영향을 받는 다른 업무가 있는가를 고려해야 한다는 것이다. 예를 들면 “속성/컬럼 추가” 작업 이 진행되었다고 한다면 단순히 ERD를 고치고 테이블 정의서 산출물을 잘 정리하는 것만으로 끝나는 것이 아니라 테이블을 직접 생성하고 관리하는 DBA에게 알리고, TO-BE 데이터 이행 작업을 수행하는 이행 개발자에게 이행규칙 변경이 진행 될 수 있도록 알려야 한다는 것이다. 항상 다른 이해관계자에게 영향을 주는 업무인지를 고려해야 “나는 잘했는데 시스템은 망하는” 결과가 발생되지 않는다.

▣“사람과 할 일이 정해졌으면 이제 누가 어떤 일을 할 것인지를 정리하자”: R&R 정의
R&R은 다음에 나올 “프로세스”와 선-후 관계가 얽혀 있다. 각 이해관계자의 역할을 미리 정해놓아야 업무 프로세스를 정할 때 세부 스만, 업무 프로세스를 정의해보니 필요한 스텝이 나오고 그 스텝을 수행할 수 있는 이해관계자가 그 때 결정될 수 있기도 하다. 따라서 어느 것을 먼저 해야 하느냐를 고민하는 것보다 “업무를 수행하는데 있어 필요한 프로세스를 빠짐없이 정리하고 그 프로세스의 세부 작업 스텝에 수행할 이해관계자를 정확하게 매핑 하는 것”에 초점을 맞춰서 결정하는 것이 바람직하다고 본다. 상황에 따라 달라지겠지만 개인적으로는 이해관계자들간의 역할에 대해 큰 틀을 먼저 정하고 이 후 결정되는 업무 프로세스에 따라 세부 조정을 하는 방식으로 진행하는 편을 선호한다.



이해관계자들의 역할을 정의하다 보면 한가지 업무인데 수행하는 담당자가 한 명이 아닌 업무들이 나타나게 된다. 한 명에게 일을 몰아주기에는 애매한 업무들, 이런 업무들에 대해서는 업무 수행 프로세스를 정의하면서 단계별 스텝에서 각자의 역할에 대해 정리를 하면 된다.

▣“업무를 누가 어떤 순서로 수행하는지 세분화해서 프로세스를 결정하자”: 업무 수행 프로세스 정의
이제 지금까지 도출한 이해관계자, 업무, 역할들을 종합해서 최종 관리 프로세스를 정의해야 한다. 각 업무별 관리 프로세스를 상세하게 프로세스 다이어그램으로 정리하는 것이 가장 좋겠지만, 당장 정리하기에 복잡하고 시간이 많이 걸린다면 최소한 해당 업무를 진행하기 위해 작업하는 상세 단계를 순서대로 나열하고 각 단계의 수행자를 표로 간략히 정리해보자.



▣“이제 내가 언제 무엇을 해야 하는지 확인해보자”: 이해관계자 & 업무 프로세스 Map정리
지금까지 다양한 업무에 대해 여러 관계자들의 업무 프로세스 별 역할을 정의해왔다. 업무가 다양하고 복잡할수록, 프로세스가 정교해질수록 많은 내용이 정리가 되었을 것이다. 이러한 내용들을 하나의 표로 모아서 내가 할 일은 무엇인지 한눈에 확인할 수 있도록 정리해보자.



이렇게 Map으로 정리해 보면 내가 해야 하는 일에 대한 정리가 될 뿐만 아니라 업무의 역할 정의에서 누락이 없는지 확인이 가능하다. 붉은 색으로 표시된 “수행”은 반드시 하나의 업무에 대해 한 명 이상이 나타나야 정상이다. 또한 정상적인 업무 요청이라면 1,2,3,5의 단계가 최소 1번 이상씩은 나타나야 한다. 신청(1번)한 사람은 있고 수행(3번)한 사람도 있는데 승인(2번)할 사람이 없는 경우는 수행사끼리 알아서 북치고 장구치고 했다는 이야기가 된다.

지금까지 복잡하고 귀찮아 보이는 업무-역할 정의에 대해 예시를 들어가며 설명을 했는데, 복잡하지만 이런 과정을 통해 프로젝트 초기에 각자의 역할의 범위를 정확히 인지할 수 있고, 다른 업무와의 연계가 원활이 이루어질 수 있는 정보를 얻을 수 있게 된다. 하지만 예시는 예시일 뿐 각자의 프로젝트의 상황에 맞춰 정리해 나가는 것은 여러분들의 몫이다.

단, 반드시 기억할 점은 DA 업무의 특성상 규칙을 지키지 않고, 절차를 지키지 않고 혼자만의 생각으로 진행해버린 작업을 되돌리는 것은 초기에 관리 프로세스를 정립하는데 소요되는 시간보다 훨씬 길고 힘든 시간이 필요하다는 점이다.