물류사 데이터 거버넌스 프로젝트의 챌린지들
어떤 어려움을 어떻게 극복했을까
최근 데이터 거버넌스 프로젝트를 성공리에 마무리했다. 프로젝트에서 배운 점들에 대해서 정리하기로 했다. 이 글에서는 다음과 같은 내용들을 다룬다.
수행한 프로젝트의 개요
데이터 거버넌스 수립 프로젝트란
지역 최적화와 전사 최적화의 문제
의사소통과 문서 작업의 중요성
타 조직과의 협업 시 어려움
낯선 업무 도메인과 용어
I. 프로젝트 개요
고객사는 국내의 물류 유통 대기업이었고, 프로젝트의 목표는 IT 시스템 구축/운영 시 전사적으로 적용할 데이터 거버넌스 정책을 수립하는 것이었다.
1. 데이터 거버넌스 정책
데이터 거버넌스 정책을 쉽게 풀어 말하자면, 데이터 테이블 설계에 관련한 표준은 무엇이며 이러한 표준이 잘 지켜지는지에 대한 관리 감독을 어떻게 할 것인가에 대한 점을 정하는 문서이다. 따라서 데이터 모델링에 관한 사항과 데이터 표준화에 대한 사항을 상세 정의하고, 향후 이러한 규칙들을 어떻게 절차화하고 어떤 조직이 어떤 업무를 맡아 처리할지를 기술하는 다양한 문서들을 작성하는 프로젝트였다.
향후 전사적으로 도입할 데이터 거버넌스 정책을 수립하는 업무였기에, 현재 고객사의 주요 IT시스템들의 현황에 대한 분석도 동반되었다. 어떤 DBMS를 사용하고 있으며 데이터 규모는 어떠한지, 향후 개선 계획 등을 운영 담당자 인터뷰를 통해 조사했다.
2. 데이터 표준화 및 데이터 모델 현행화
금번 프로젝트에서는 주요 업무 시스템 4개를 선정하여 테이블/컬럼에 대한 한글명을 표준화하여 모델을 생성하는 작업도 포함되었다. 이는 향후 전사적으로 사용할 표준 사전(단어, 도메인, 용어) 생성하기 위한 사전 단계이면서 데이터 자산에 대한 가시성을 확보하기 위해 중요한 작업이기도 하다. 나는 주로 이 작업을 담당했다.
3. 데이터 거버넌스 시스템 도입
수립한 데이터 거버넌스 정책이 단순히 문서로만 남지 않기 위해서는 이를 실행하기 위한 도구를 갖추는 것이 몹시 중요하다. 데이터 거버넌스 정책을 체계적이고 손쉽게 적용하기 위한 솔루션 도입도 함께 이루어졌다. 때문에 솔루션이 도입과 함께 커스터마이징도 이루어졌다. 솔루션으로 지원할 수 있는 기능과 고객사 요구사항 간의 균형점을 잘 찾아내는 것이 중요했다.
4. 프로젝트 특이점
모든 프로젝트들에는 고유성이 있다. 동일 도메인이라거나 동일 유형의 프로젝트라고 하더라도 업무가 매번 새로울 수밖에 없다. 이번 프로젝트가 특별했던 점 세 가지를 꼽아 보았다.
첫 번째, 데이터 거버넌스를 신설 조직이 맡았다.
데이터 거버넌스 수립 프로젝트를 하게 되는 경우, 어떤 조직에서 데이터 거버넌스를 총괄하는지에 따라서 정책 방향성이 크게 달라지곤 한다. 기존의 IT 정책 담당 부서가 프로젝트 오너이면서 향후 데이터 거버넌스 실행 조직으로 업무 확장을 계획하고 있거나, 하위 조직 신설을 염두하는 경우가 가장 일반적인 것 같다.
이번 프로젝트는 최근 신설된 디지털 전환을 위한 팀이 조직이 데이터 거버넌스 수립에 대한 프로젝트를 발주한 경우였다. 고객팀의 구성원이 대체로 경력직으로 최근 1-2년 새 채용되어 온 분들이 많았다. 고객팀분들도 회사 업무나 레거시 시스템에 대해 학습해 나가는 단계에 함께 일하게 되었다는 점이 특별했다.
두 번째, 모델 현행화 이후 모델 활용 계획이 없었다.
본 프로젝트를 통해 표준화 및 모델 현행화 작업을 4개 주요 업무시스템에 진행하기로 되어 있었다. 대체로 테이블명/컬럼명에 대한 표준화를 거쳐서 데이터 모델을 구축하고 나면 통상적으로 이 모델을 지속적으로 관리하며 사용한다. 신규 테이블 설계나 생성 시 모델에 표현하여 모델이 항상 최신성을 갖추도록 하는데, 이번 프로젝트에서는 향후 모델에 대한 사용이나 관리를 하지 않기로 하였다. 여러 현실적 이유 때문이었지만 5,000개가 넘는 테이블에 대한 모델 생성 작업 이후 관리/활용을 하지 않는 것이 일반적인 케이스는 아니다.
세 번째, 데이터 거버넌스 시스템을 시범 도입한 업무시스템이 존재했다.
사내에 데이터 거버넌스 시스템을 시범 도입한 사례가 존재했다. 해외 업무와 밀접한 업무시스템이었는데, 작년 데이터 거버넌스 시스템 도입과 함께 해당 업무시스템의 데이터 표준을 정의하였다. 당시의 프로젝트도 우리 회사의 동료가 맡아했고, 당시 구축한 시스템과 정책을 잘 활용하고 있었다. 덕분에 금번 프로젝트 착수 이전에 해당 업무시스템 프로젝트 당시 상황 등에 대해서 전해 들을 수 있었다.
II. 프로젝트의 챌린지들
모든 프로젝트들에는 고유한 어려움들이 있다. 아무리 경력이 많고 연차가 높아도 매번 새로운 어려움에 부딪히며 일하겠구나란 예감은 기우가 아니라 현실이다. 이번 프로젝트에서 겪었던 어려움들과 극복했던 방법들, 그리고 아쉬움들을 기록해 본다.
1. 지역 최적화된 표준 체계의 존재와 한계
앞서 프로젝트 개요에서 1개 업무 시스템에서 거버넌스 시스템을 시범 도입하여 사용하고 있다는 점을 언급했었다. 이 업무 시스템의 표준 체계를 상세히 점검하고, 최대한 기존 표준 체계를 수렴하는 방향으로 전사 표준을 수립하기로 하였으나 큰 한계가 있었다. 해당 업무시스템이 해외 특화 시스템인 점을 반영하여 표준 체계가 수립되어 있어 전사적 시각에서는 수용하기 어려운 표준이 다수 존재했기 때문이었다.
1개 시스템에 최적화된 표준 체계를 가지고 있다 보니 지엽적인 시각에서는 완전했던 의사결정이었더라도, 전사적으로 확대 적용이 불가능한 지점이 있었다. 예를 들면, 해당 표준 체계는 특정 DBMS를 기준으로 테이블명/컬럼명 길이 기준을 수립하였으나 전사적으로는 그보다 짧은 명명규칙을 가진 DBMS를 사용하는 경우가 많았다. 또한, 해외 이용자를 위한 시스템이다 보니 표준 단어로 외래어를 차용한 경우가 많았으나, 전사 관점에서는 의사소통의 명확성을 위해 표준으로 삼기 어려운 단어들이 많았다. 물리적으로도 큰 차이가 있었는데, 일시 도메인을 VARCHAR(14)로 정의하여 사용하고 있었으나 전사표준으로는 DATETIME을 사용키로 결정되었고 시스템 컬럼의 종류도 상이할 수밖에 없었다.
결과적으로 전사 표준에 해당 표준 체계를 통합하지 못했다. 이에 대해서 같은 회사에서 거버넌스 체계를 수립하는데 이전 수립한 정책과 전사 정책에 왜 차이가 생기는지, 일관성 문제가 제기되기도 했다. 지역 최적화된 표준과 전사 최적화된 표준을 수립할 때에는 의사결정에 있어 차이가 있을 수밖에 없다는 점에 대해 근거자료를 제시하느라 최종 결정까지 많은 시일이 소요되었다.
이번 경험을 통해서 데이터 표준을 일부 시스템에서만 적용하여 사용하는 경우 향후 전사적으로 확대 적용하는 데에는 많은 어려움이 따른다는 점을 확실하게 느낄 수 있었다.
2. 고객과의 의사소통
고객과의 소통 문제는 언제나 어렵다. 고객의 성향과 프로젝트 팀의 성향에 따라서 소통 창구나 빈도, 방식이 상이하다.
이번 프로젝트에서는 고객과 많은 의사소통을 했다. 대체로 모든 의사결정에 대해 회의를 소집하고 고객과 함께 의논하고 결정 내렸다. 투명한 의사결정과 민주적인 절차로 인해 더 좋은 의사결정을 내릴 수 있었지만, 이 과정에서 시간과 체력이 소모되는 건 어쩔 수 없었다. 결정을 내리지 못한 채로 시간이 흐르는 일이 잦아지다 보니 조급함에 팀원끼리 예민해지기도 했다. 갈등 상황에서 많은 스트레스를 받는 내게는 고통스러운 소통 방식이었지만 고객의 의견을 가장 가까운 곳에서 밀도 높게 청취할 수 있었다는 점에서 값진 시간이기도 했다.
컨설턴트는 고객이 Well Informed Decision을 내릴 수 있도록 도와야 한다. 이때 어떤 방식의 의사소통과 결정 방식이 가장 효율적이며 만족스러울 것인가에 대한 고민이 더 커졌다.
3. 문서 품질에 대한 높은 기대
이번 프로젝트의 고객은 여러 맥락에서 문서를 통한 의사소통의 중요성을 크게 염두하고 있어, 문서 품질 요구가 많이 강조되었다. 데이터 거버넌스를 도입한다는 것은 사실 새로운 프로세스와 통제를 실행하는 일이기 때문에, 많은 설득이 필요한 작업이다. 또한 체계가 지속적으로 유지되고 강화되기 위해서는 정확한 가이드라인이 필수적이기 때문에 고객의 염려와 요구에는 충분히 공감할 수 있었다.
하지만 이를 시정하는 과정에 있어서 고객과 원치 않는 오해가 있었다. 우리 팀이 대체로 겪는 고객들이 IT부서의 실무자들이기 때문에 문서의 외관과 관련된 요구나 지적은 받아본 경험이 많지 않았다. 때문에 이번 고객의 요구에 대응하는 과정이 신속하고 적극적이지 못했고, 이에 대해 고객 불만이 높아졌다. 결국 업무 조정을 통해서 문서 수정 업무에 좀 더 많은 공수를 할당해야 했다.
다행히도 이전에 공공기관을 주 고객으로 했던 업무 경험이 도움이 되었다. 문서를 통한 의사소통이 강조되는 조직의 업무 문화에 익숙한 편이었고 고객 요구사항도 명확한 편이었다. (Non-IT를 위한 친절한 용어 사용, 헤드 메시지의 흐름, 숫자/전문용어보다는 이미지 활용 등) 업무 중요도를 조정하고 실행하면서 잘 마무리될 수 있었다. 프로젝트 초기에 고객팀의 문서를 최대한 많이 공유 받아 이 팀의 스타일에 대해 파악할 수 있었더라면 좀 더 수월하지 않았을까, 아쉬움이 남는다.
IT 운영팀의 협조
IT 운영팀은 데이터 현황 조사에 있어서 중요한 정보원이다. 테이블/컬럼의 명칭을 확인할 만한 근거 정보가 없는 경우 실제 테이블 구조에 대한 이해가 있는 인력의 도움이 절실하다. 단순히 테이블명이나 컬럼명을 가지고 추측하여 한글 명칭을 부여해서는 그 정확도와 품질을 신뢰할 수 없어지고, 장기적으로는 데이터 모델의 활용 가치가 떨어뜨리게 된다. 뿐만 아니라 IT 운영팀은 데이터 거버넌스 정책이 수립된 이후 이를 가장 가까운 곳에서 활용하게 되는 인력이기도 하다.
때문에 운영팀 인력의 협조가 필수적인데, 협업을 하기 쉽지 않았다. 이에 대한 원인은 이번 프로젝트 발주 과정에서 운영팀이 담당해야 할 업무나 인터뷰 등 실제 소요되는 작업에 대한 공수가 정확하게 산정되어 반영되지 못한 점이 가장 크다. 운영팀도 기존에 담당하고 있는 업무와 신규 개발 프로젝트 등으로 업무량이 과중한 상황이었기에, 본 프로젝트의 중요성이나 필요성에 대한 공감대가 충분함에도 불구하고 협조를 하기 위한 물리적 시간이 절대적으로 부족했다. 게다가 담당 시스템에 대한 데이터 모델을 생성한 이후에 운영자들이 어떤한 활용 목표를 가지고 있지 않다는 점도, 참여도를 높이는 데 걸림돌로 작용했다.
이번 프로젝트처럼 프로젝트 발주팀이 IT 운영팀에 대한 업무 우선순위나 배정의 권한이 없는 경우에는, IT운영팀과의 업무 협조 방안을 조기에 확인하고 조정할 필요가 있겠다. 협조가 어려운 상황이라면 프로젝트 수행 범위와 방법론, 전략을 수정하기 위해 고객과 충분한 논의를 거쳐야겠다. 또한, 프로젝트의 결과물인 데이터 모델이 향후 시스템 개선이나 차세대를 진행할 때 어떤 효과를 낼 수 있는지에 대해서 잘 알려서 프로젝트 초기 착수 단계부터 참여에 대한 동인을 잘 제공해야한다는 생각도 들었다.
낯선 업무 도메인과 전문 용어들
내가 표준화를 담당했던 업무 시스템은 해운 관련이었다. 선박과 관련된 다양한 용어들이 사용되고 있었고, 물류 용어도 낯선 것이 많았다. 이에 대한 한글 자료가 많지 않아서 외래어를 피하면서도 실무자가 이해할만한 한글 단어로 대체하는 작업에 많은 시간이 소요되었다.
수많은 약어들이 사용되고 있었는데, 영문 약어는 분야에 따라서 상의한 의미로 사용되기에 해당 테이블에서 사용하고 있는 약어에 대해 정확히 정의하는 일이 쉽지 않았다. 담당자 확인을 거칠 수 있었다면 수월했겠지만 상기 사유로 인해서 IT 운영팀에게 질의하여도 답변을 제때 받을 수 없었고 때로는 운영담당자도 알지 못하여 답변이 어려운 용어들도 있었다.
이에 대해 빠르게 업무를 진행하기 위해 시스템 매뉴얼과 업무 자료를 요청했지만, 이를 제공받지 못했다. 결국 구글링을 통해서 여러 자료를 다각적으로 검토해 보고 가장 적합한 의미를 추정하여 정의를 내리고 담당자 확인을 거치는 방식으로 업무를 진행했다.
높은 영문 코멘트 비율
표준화 작업 시에 주로 참조하는 정보는 테이블 정의서와 DBMS의 코멘트 정보다. 이 정보들을 긁어모아서 설정한 명명규칙에 따라서 표준화를 한다. 그런데 내가 담당했던 시스템이 유독 테이블과 컬럼 코멘트의 영문 비율이 높았고, 코멘트가 서술식으로 작성된 경우가 많았다. 코멘트에 단순히 명칭만 들어있는 게 아니라 코드 값에 대한 설명이나 데이터 흐름에 대한 설명문이 포함되어 있었다.
따라서 코멘트 정제 작업을 해야 했다. 코드값 정보는 향후 코드 정의 시 활용할 수 있도록 별도로 정리해 두고, 명칭 이외의 설명은 제거하여 명사화하는 작업을 1차적으로 했다. 정제 이후 한글화 작업을 운영팀에 요청했어야 하지만 프로젝트 일정 내 회신이 오지 않으리라는 게 확실하여서 직접 한글화 작업을 수행했다. 원래 WBS 상에 계획하였던 것보다 많은 공수가 들었지만, 담당 시스템이 중요도가 높았고, 한글화 작업에 대한 효과가 컸다. 한글명을 입힌 데이터 모델을 보면서 업무 이해가 한 층 수월해지는 것을 보면서 개인적으로 보람을 느낄 수 있었다.
금번 프로젝트가 내게는 두 번째 데이터 거버넌스 프로젝트였다. 첫 프로젝트와는 도메인뿐 아니라 많은 점들이 달랐던 프로젝트였다. 특히 이번 프로젝트는 작업자가 한 명 더 많았는데, 한 명이라는 인원이 작업 계획 수립과 수행에 많은 영향을 줬다. 작업 배분과 취합 문제가 복잡해져서 작업이 더 어렵게 느껴졌다. 이런 게 프로젝트의 묘미인가 싶기도.
다음 프로젝트는 더 즐겁게 할 수 있기를.
