그러나 마트성 데이터를 활용할 경우 몇 가지 문제가 발생할 수 있다. 이들 문제 대부분은 개발 시작 시점에는 표면으로 드러나지 않는다. 배포(운영에 시스템을 반영하는 작업) 시점이나, 이후 운영 시점 그리고 향후 고도화 시점에 문제 가 붉어진다. 그 때문에 장기적인 관점에서 시스템을 운영하는 운영자라면, 앞으로 얘기할 4가지 포인트에 대해 고민해 볼 필요가 있다.
2.1. 배치일자 문제
배치는 보통 월, 주, 일 등을 주기로 시스템 결과를 갱신하는 걸 말한다. 통상 운영 리스크를 줄이기 위해, 월배치가 많이 선호된다. 월배치는 보통 당월 초에 전월까지 기록된 데이터를 활용한다. 보통은 소스 데이터가 만들어지는 것을 감안해 매월 2~15일을 기준으로 만든다.
원천이 아닌, 마트를 바라보는 경우 여기서 문제가 생긴다. 만약 마트성 데이터가 매월 15일에 만들어진다면 어떨까? 어쩔 수 없이 새로 구축하는 시스템은 16일 이후에 배치를 일정을 잡아야 할 것이다. 이런 식으로 마트가 마트를 바라보는 일이 자주 발생하면 어떨까? 배치 일자가 끊임없이 밀리게 된다.
일정이 밀리는 게 큰 문제처럼 안 보일지 모른다. 하지만 시기가 중요한 과제라면, 배치일정이 밀리는 건 큰 문제가 될 수 있다. 보험사기 적발 시기가 늦을 수 있다. 이미 가입이 끝난 고객에게 상품 가입을 권유하라고 할 수도 있다. 이런 시스템은 제 기능을 하지 못한다.
<사례> A 금융사에서 있었던 일
어떤 금융사 프로젝트에서 있었던 일이다. 고객 요청으로 소스 데이터가 아닌, 마트 데이터의 집계 결과를 이용해 분석 마트를 만들었다. 마감년월 기준으로 변수를 가져다 썼다. 그리고 배포가 임박해, 현재 시점을 기준으로 테스트를 진행했다. 그런데 데이터가 모두 비어있었다. 바라보던 데이터가 당월 기준 15일이 지나야 전전월 데이터가 적재되는 것이었다. 결국, 전전월 데이터를 가져오도록 코드를 수정하고, 모형도 다시 만들었다. 덕분에 신나게 야근했다.
2.2. 소스 마트가 고도화되거나 폐기되는 문제
두 번째 문제는 소스로 사용한 마트가 수정되거나 폐기되는 경우다. 마트는 목적을 가지고 만든다. 그렇기 때문에 상황이 바뀌면 폐기되거나 업그레이드될 수 있다. 데이터 레이아웃이 바뀌면, 변수의 자료형이나 구조, 기준 등 많은 요소가 다양하게 바뀐다.
먼저, 마트가 수정되는 경우다. 고도화 프로젝트로 기존 마트의 구조나 내용이 바뀔 수 있다. 이 경우, 운영되고 있을 내가 만든 시스템에 어떤 영향이 미칠지 알 수 없다. 보통 고도화 프로젝트에서는 영향도 분석이 선행된다. 하지만, 운영 책임자가 빈번하게 바뀌는 경우도 있다. 이 경우 히스토리 관리가 제대로 되지 않는 경우도 있다. 그러면 운영이 시작되자마자 기존 데이터를 바라보던 사업부에서 항의가 빗발친다.
두 번째는 폐기되는 경우다. 사용하지 않는 시스템은 그때그때 폐기해 주는 것이 좋다. 그런데 쓰지 않아 폐기하려던 시스템의 결과를 다른 시스템에서 사용하고 있다고 하면, 어떨까? 결론부터 말하면, 폐기할 수 없다. 정말 단순한 결과 하나만 가져다 써도 쉽게, 폐기할 수 없다. 해당 시스템을 직접 개발한 사람이 와서 정리하지 않는 한 말이다. 왜냐고? 어떤 문제가 생길지 나도 너도 모두 모르기 때문이다.
2.3. 내부로직을 정확히 알기 어려운 문제
세 번째 문제는 '내부로직'이다. 만들어진 결과를 가져와 쓰는 것은 참 편리하다. 내가 굳이 만들 필요가 없기 때문이다. 하지만, 세부적인 로직을 알 수 없다면, 설명할 수 없다. 가져다 쓴 수치에 대한 정확한 의미를 알기도 어렵다.
예를 들어, '평균 구매 금액'이란 변수가 있다고 하자. 직관적으로 이해하기 쉽다. '아 어떤 고객이 구매한 금액의 평균이구나'라고 생각할 수 있다. 하지만, 조금만 더 생각해 보면, 월평균인지, 주 평균인지, 그냥 평균인 지도 의문이다. 그리고 기간을 얼마나 고려했는지도 의문이다. 단위는 어떠한가? 지점인가? 고객인가? 상품인가? 저 문구만 보아서는 알기 어렵다. 변수 이름은 대부분은 '함축적' 으로 관리한다.
보통은 메타 관리 시스템에 변수에 대한 설명이 있다. 하지만, 내가 경험한 10개 이상의 대기업 어디에도 세부 정의를 적어놓은 시스템은 없었다. 메타 관리 시스템에 저 변수는 분명 이렇게 설명되어 있을 것이다. '평균적으로 구매한 금액을 집계한 값' 이 정도만 되어도 관리자가 엄청 성실한 거다. 설명이 없는 경우가 대부분이다.
그렇다면, 결국은 해당 변수를 만드는 로직을 받아서 확인해야 한다. 그리고 어떤 소스를 이용해 만들었는지도 알아야 한다. 코드를 직접 검토하는 게 제일 정확하지만, 제일 오래 걸린다. 로직이 간단하면 모를까 여러 데이터를 봐야 하는 경우라면 난감하기 짝이 없다. 이런 경우에는 그냥 새롭게 정의하는 편이 훨씬 낫다. 시간 절약을 위해 가져다 쓰려다가 시간이 10배는 더 들 수도 있기 때문이다. 그리고 새로 정의하는 마음이 편하다.
'대응이 되기 때문'이다.
2.4. 영향도 분석이 어려움
마지막 네 번째는 영향도 분석이 어렵다는 점이다. 마트가 마트를 바라보는 일이 많아지면, 나중에 무엇 하나 건드리기 어려워진다. 정말이다. 한 시스템을 고도화하려고 보면, 기존 시스템이 여러 개 엮이게 된다. 결과적으로 이 모든 시스템을 다 고쳐야 하는 상황이 발생할 수도 있다. 이게 왜 문제가 될까?
고도화 수행 시간이 늘어난다. 기존 시스템을 고도화하기 위해서는 복잡하게 얽힌 시스템들으 분석해야 한다. 초기에는 해볼만 하지만, 시간이 지나면, 불가능한 수준이 된다. 시스템이 늘어나면, 늘어날수록 도무지 관리가 안 되게 된다. 그리고 쉽게 시스템을 폐기하지도 못 한다. 이는 마치 뚱뚱해지는 거랑 같다. 불필요한 지방이 쌓이고, 빼기도 힘들다.
댓글 없음:
댓글 쓰기