DATOR


성공적인 차세대 시스템 구축을 위한 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 리더

응용 프로그램

개발자, 설계자

개발 리더(응용 파트별), 현업 담당자

데이터 이행 개발

데이터 이행 개발자, 데이터 이행 PL

데이터 이행 총괄

DBA

DBA, 튜너

DBA 담당 리더

Infra

Infra 담당자

Infra 담당 리더

보안

보안 담당자

보안 총괄

       (표1) 업무구분 별 수행사/고객사 별 이해관계자(예시)


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

 

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


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

 


업무 구분

업무
번호

업무

업무 설명/업무 진행 시 유의 사항

연관
업무 번호

데이터

표준 관리

1.1

신규 단어 추가

표준 단어 추가 시 기존 표준 단어와 영문 약어 중복에 유의

 

1.2

신규 용어 추가

유사 용어가 이미 등록되어 있는지에 대해 검토하고 필요한 경우에 한해 등록

 

1.3

신규 도메인 추가

통일할 수 있음에도 불구하고 불필요하게 세분화해서 등록하는 도메인이 없도록 검토

 

1.4

단어 표준 변경

단어 표준을 변경(영문 약어 변경에 한함)한다는 의미는 해당 단어를 사용하는 모든 DB 오브젝트의 이름을 모두 바꾼다는 의미가 됨. 영향도가 큰 업무인 관계로 신청 가능한 인원을 최소화하고 충분한 검토가 필요함

1.5, 3.3, 4.1, 4.2, 5.2

1.5

용어 표준 변경

해당 용어를 사용하고 있는 엔티티/속성이 기 존재하는지를 확인하고 모든 속성이 동일하게 변경될 수 있을 때만 변경 가능

3.3, 4.1, 4.2, 5.2

1.6

단어/용어/도메인 표준 삭제

영향을 받는 대상이 없는 경우에만 삭제 가능

 

1.7

표준 규칙/정책 변경

고객사의 의사 결정이 있을 경우에만 변경. 표준 변경 시 영향을 받는 대상의 범위를 먼저 파악하고 변경해야 함

 

코드 표준 관리

2.1

AS-IS 코드 정제

AS-IS 시스템에서 발생된 데이터 중 코드 값 프로파일링을 통해 정제 대상을 확인하고 미등록 코드 값에 대해서는 코드등록 혹은 AS-IS 데이터 정제 등의 정비가 필요함

2.2

2.2

AS-IS TO-BE 코드 매핑

AS-IS 코드가 TO-BE 시스템으로 이행될 때 변경되는 코드 값 매핑을 정리하여 개발팀에 제공

5.2

2.3

신규 코드 등록

기존의 코드와 중복되는 코드 값을 가지는 코드가 아닌지 사전에 검토 후 등록

1.3, 2.2

2.4

코드 값 변경

변경하고자 하는 코드를 사용하고 있는 모든 테이블의 응용 프로그램 담당자에게 코드 값 변경이 담당 프로그램에 영향이 없는지 확인을 해야 함

2.2, 5.2

2.5

코드 삭제

테이블에서 컬럼으로 사용하고 있지 않더라도 응용 프로그램에서만 코드가 있을 수 있음으로 삭제에 유의

1.6, 2.2

데이터

모델 관리

3.1

엔티티/테이블

추가/삭제

신규일 경우 누가 언제 어떤 용도로 사용하기 위해 신청을 하였는지 엔티티 정의에 상세히 정리 삭제 역시 누가 어떤 사유에서 삭제를 신청했는지를 별도로 정리

4.1, 4.2, 4.3, 5.1, 5.2, 6.1

3.2

속성/컬럼 추가

신규 컬럼이 TO-BE 데이터 이행 시 데이터 이행이 필요한 컬럼인지를 확인하고 만약 필요하다면 컬럼 매핑 정보, 전환 규칙도 같이 받아서 정리

4.1, 4.2, 4.3, 5.1, 5.2, 6.1

3.3

속성/컬럼 변경

컬럼 변경 시 해당 컬럼을 이용한 인덱스가 존재하는지를 확인하고 만약 존재한다면 해당 인덱스에 대해서도 변경 작업을 동시에 진행해야 함

4.1, 4.2, 4.3, 4.4, 5.1, 5.2, 6.1

3.4

속성/컬럼 삭제

AS-IS 부터 존재한 컬럼이라면 삭제 신청한 사유, 일시, 신청자를

기록 그리고 해당 컬럼에서 관리하고 있던 데이터를 버릴 것인지

다른 컬럼으로 옮겨야 하는 것인지에 대해서도 확인을 해야 함

4.1, 4.2, 4.3, 4.4, 5.1, 5.2, 6.1

데이터

오브젝트 관리

4.1

테이블 생성/변경

테이블 생성/변경 작업 시 사용하는 스크립트 생성자와 실제 스크립트를 수행하는 작업자, 그리고 최종 테이블 생성 스크립트를 관리하는 관리자에 대한 R&R를 명확히 해야 함

4.2, 5.1, 5.2, 6.1

4.2

인덱스 추가/변경/삭제

인덱스 추가/변경/삭제는 해당 테이블의 담당자(응용 프로그램에서 해당 테이블에 대해 오너쉽이 있는 담당자) 혹은 해당 담당자의 요청을 받은 튜너만이 추가할 수 있도록 신청 권한에 제약을 주는 편이 관리에 용이함

6.2

4.3

시퀀스 추가/변경

신규 테이블이 아닌 AS-IS 부터 존재한 테이블인 경우 데이터 이행 시 시퀀스를 사용할 수 있으므로 운영 시작 시점의 초기 시퀀스 값에 대해 관리가 필요함

5.2

4.4

파티션 테이블 변경

TO-BE 테이블의 파티션이 변경되면 응용 개발 프로그램 뿐만 아니라 데이터 이행 개발에도 영향이 있을 수 있으므로 변경 사항에 대한 공지가 필요함

5.2

데이터

이행 규칙

5.1

데이터 이행 규칙 신규

신규 테이블 혹은 신규 컬럼에 대한 이행 규칙은 테이블/컬럼 추가 신청 시점부터 받아서 정리하는 것을 권장함. 만약 이행 규칙을 제공한 사람이 수행사 설계자였다면 고객사에게 검토를 요청하여 확인을 받아야 함

 

5.2

데이터 이행 규칙 변경

데이터 이행 규칙 신규와 동일

 

5.3

데이터 이행
(
/본 이행)

시스템 오픈을 위한 데이터 이행 혹은 이행 테스트 시 이행 팀 뿐만 아니라 DBA, Infra 담당자 들도 같이 모니터링을 하면서 진행해야

이행 시점에 발생될 수 있는 긴급 사항에 대해 빠른 조치가 가능함

 

기타

6.1

테스트 데이터 제공

시점 데이터 확보 방안, 실 데이터 제공 시 데이터 보안 관련 사항

(민감 정보 삭제 혹은 스크램블링), 테스트를 위해 필요한 데이터의 사이즈와 테스트 DB 서버 용량 등에 대해 검토가 필요

 

6.2

SQL 성능 개선

시스템 성능에 영향을 줄 수 있는 SQL에 대한 상시 모니터링이 필요

4.2, 4.4


(2) 차세대 구축을 진행하면서 발생되는 업무 수행 유의사항 정리 (예시)



 

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

 

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

 

업무구분

수행사/ 고객사 구분

담당자

역할

DA

수행사

DA

표준 단어/용어/도메인 변경 작업

AS-IS – TO-BE 코드 매핑, AS-IS 코드 정제 작업

코드 추가/변경 신청에 대한 검토 승인

데이터 모델 변경 작업

테이블 생성/변경 스크립트 작성

AS-IS – TO-BE 컬럼 매핑 정의서 작성

메타시스템 관리자

메타 시스템 유지 보수

메타 시스템 권한 관리

결제선 관리

고객사

DA 담당자

데이터 표준/규칙 변경 요청에 대한 검토 변경 작업

모든 수행사 DA 담당자 작업에 대한 최종 검토 승인

테스트 데이터(시점 데이터) 확보 방안 수립

응용 프로그램 개발

수행사

개발자

신규 테이블, 모델 변경, 코드 추가/ 변경 요건을 설계자 혹은 개발PL 전달

설계자

신규 테이블, 모델 변경, 코드 추가/ 변경 신청

고객사

개발 리더 (응용 파트별)

신규 테이블, 모델 변경, 코드 추가/변경 신청에 대한 검토 승인

신규 추가 테이블/속성에 대한 데이터 이행 규칙 확인

현업 담당자

신규 테이블 업무 요건 확인

신규 추가 테이블/속성에 대한 데이터 이행 규칙 확인

데이터 이행 개발

수행사

데이터 이행 개발자

데이터 이행 규칙 정의서 작성

데이터 이행 개발

테스트 데이터 제공

데이터 이행 PL

테스트 데이터 제공 계획 수립

데이터 이행 계획 수립

고객사

데이터 이행 총괄

테스트 데이터 제공 계획 수립

시스템 이행과 연계한 데이터 이행 계획 수립

DBA

수행사

DBA

데이터 오브젝트 생성/변경 DBMS 반영 작업 수행

데이터 오브젝트 생성 스크립트 관리

시스템 간의 TO-BE 테스트 데이터 Copy 작업 수행

데이터 이행 지원 – DBMS 모니터링

고객사

DBA 담당 리더

DBMS 관리 정책 수립

튜너

수행사

튜너

DBMS 성능 모니터링

SQL 성능 튜닝

인덱스/테이블 파티션 생성 요청

Infra

수행사

Infra 담당자

DB 서버 관리

DB Disk 용량 관련 관리

데이터 이행 지원 - 서버 성능 모니터링

고객사

Infra 담당

DB 서버 구성 정책 결정

DB Disk 용량 관리 정책 결정

보안

수행사

보안 담당자

테이블/속성 보안 대상 속성 관리

고객사

데이터 보안 담당자

테이블/속성 보안 대상 속성에 대한 보안 정책 수립

           (표3) 이해관계자 별 수행 업무(예시)

 

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

 

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


table-2.jpg


 

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


table-3.jpg


신청

검토 및 승인

수행

수행결과검토

결과통보대상

 

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

 

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


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

 



 

 


 

Tag :

Leave Comments