고진기술래[苦盡技術來] 고생 끝에 기술이 온다 #1 _ SIS 본부 2팀 강대웅 상무

고진기술래[苦盡技術來]: 고생 끝에 기술이 온다.

들어가며

---

생각해보면 조금 오래된 이야기이다. 2001년 경 데이터 관련 일을 지속하고자 국내 최대 IT 기업인 삼성SDS를 떠나 규모가 작은 데이터 전문 기업으로 옮겨 데이터 웨어하우스 시스템 구축 사업에 세 번 연속 참여하게 되면서 알게 된 몇 가지 소소한 기술적 경험들을 몇 회에 걸쳐 연재 형식으로 포스팅 해보고자 한다.

---

1회. 유효계약 FACT TABLE은 왜 월별로 만드는가?

---

[Business Requirement]

“현재는 유효계약건수를 월별로 만들어서 보고 있는데, 이것을 일별로 보고 싶습니다. 유효계약이란, 

계약이 체결된 이 후 만기나 해지가 되지 않고 유지되고 있는 것을 의미합니다. 

한편, 우리 회사에서는 모든 통계 데이터를 건 별, 즉 계약번호 수준까지 볼 수 있어야 합니다.”

고객은 왕이고 고객은 항상 옳다는 얘기도 있기 때문에 고객이 요구하면 무조건 구현해야 하는 것이 당면과제처럼 인식될 수 있다. 고객의 요구는 상호 존중과 합의라는 토대에서 최대한 수용하는 것이 바람직하다고 생각한다. 다만, 그것이 가져올 시스템적 변화에 따른 ROI가 부적절하다면 재고되고 철회될 수 있도록 노력해야 한다.

위에 제시한 고객의 요건은 실제로 있었던 것이고 대부분의 정보계(정보계라 함은, 데이터를 가공하여 가치 있는 정보를 생산하고 유통하는 체계를 의미하며 통상 데이터 웨어하우스 관련 기술을 적용하여 구현함) 프로젝트 시 쉽게 접할 수 있는 유형의 것이기도 하다.

유효계약건수를 일별로 제공해야 하는 이 요구사항은 타당한가? 수용할 수 있는가? 수용했을 때 현행 시스템 특성 대비 어떤 변화가 일어날 것인가?

1.1 데이터 모델 비교

우선 간단하게 나마 ER Diagram으로 표현된 데이터 모델을 비교해보고자 한다.

 

좌측의 월별유효계약Fact가 기존 데이터 모델이고 우측의 일별유효계약 Fact가 신규 요구사항을 구조화한 것이다.

차이는 매우 간단하다. 기존 데이터 모델은 통계기준년월(YYYY-MM)이 Primary Key에 포함되어 있고, 신규 데이터 모델은 통계기준일자(YYYY-MM-DD)가 Primary Key에 포함되어 있는 정도이다. 이 미묘한 차이가 구현되는 시스템에는 큰 변화를 가져오게 된다.

1.2 구현 시의 차이

경험이 풍부한 독자라면 이미 이야기하고자 하는 바를 간파했을 것이다. 경험이 부족하더라도 어느 정도 짐작할 수 있을 것이다. 기존 데이터 모델과 신규 데이터 모델 간의 구조적인 변화는 미미한 수준이지만 실제로 데이터를 발생시켜보면 차이가 매우 크다는 것을 알 수 있다.

시스템 구축을 의뢰한 고객사의 유효계약건수는 약 15,000,000 건이라고 가정해보자. 어떤 Industry를 막론하고 어떤 유형의 계약이든 이 정도는 되어야 먹고 살만하지 않겠는가? 고객의 요구는 계약번호 수준의 건별 데이터까지 조회되기를 원하므로 기존 시스템에서는 월별로 약 15,000,000 건씩 데이터가 발생되었다. 1년이면 180,000,000 건씩 발생되었을 테고 적어도 10년 정도의 추이분석은 기본적으로 할 것이므로 최소 1,800,000,000 건 정도 쌓여있을 것이다.

한편, 보편적으로 Fact 테이블에는 유효계약건수와 같은 Measurement를 다양한 시각에서 분석 가능하도록 상품코드, 판매채널코드, 영업사원번호(영업소, 지점, 본부 등 포함) 수많은 Dimension 칼럼들이 포함되어 있다. 테이블의 사이즈는 항상 가로 * 세로이므로 이 데이터를 위한 저장공간의 크기는 적어도 작지는 않았을 것이다.

지금까지 이야기 한 것은 기존 시스템을 기준으로 한 것이고, 신규 시스템에서는 어떻게 될 것인가?

유효계약건수는 월별로 만들면 매월 약 15,000,000 건씩 발생된다고 했다. 그런데, 일별로 만들어도 매일 약 15,000,000 건씩 발생된다. 그러니까 신규 시스템의 데이터 건수는 기존 시스템의 데이터 건수 대비 약 30배에 달하는 54,000,000,000 건이 된다. 무려, 오백사십억 건!!!

아무리 디스크 값이 껌 값 취급된 지 좀 되었다고 하지만 이것은 좀 너무 했다 싶을 것이다.

월별로 보던 것을 일별로 보기를 원하는 이 사소한 차이가 시스템에는 매우 큰 변화를 초래할 수 있음에 대해 요구사항을 검토하고 분석해야 할 담당자가 미리 간파하지 못하고 그대로 설계•개발•초기 데이터를 적재해보는 과정에서야 비로소 알게 된다면 프로젝트에는 적지 않은 위험요소로 등장하게 될 것이다.

1.3 차이 발생 기술적 배경

유효계약건수, 신계약건수, 해지계약건수, 수입보험료 등 숫자 형식으로 표현되는 통계 계수를 데이터 웨어하우스 관련 기술 용어로 Measurement라고 한다. Measurement는 Fact 테이블의 집합(크기)을 결정하는 가장 중요한 요소로서, 유효계약건수의 경우 위에 언급한 바와 같이 일별로 생성 시 보편적으로 데이터 건수가 매우 많이 발생되는 특성이 있다. 이에 반해, 신계약건수나 해지계약건수, 수입보험료(고객이 보험회사에 납입한 보험료) 관련 Fact 테이블의 데이터 건수는 상대적으로 적게 발생된다.

유효계약건수가 포함되어 있는 Fact 테이블 데이터 건수가 신계약건수 등이 포함되어 있는 다른 Fact 테이블보다 더 많이 발생되는 이유는 무엇일까(물론, 항상 그렇다는 것은 아니고 보편적으로 그러하다는 것이다)? 데이터 전문기업으로 이직한 2001년, 입사와 동시에 처음 수행해보는 데이터 웨어하우스 구축 프로젝트에서 그것도 PM으로 많은 고생을 하는 와중에 이 고민을 했고 신계약건수, 해지계약건수, 수입보험료의 경우는 업무’행위’에 관한 것이고, 유효계약건수는 계약의 ‘상태’에 관한 것이기 때문이라는 나름의 결론을 내린 바 있다.

시간이 조금 흘러, 신계약건수 등을 Event Measurement, 유효계약건수와 같이 상태에 관한 것들을 Status Measurement라고 정립하였는데, 각각의 특징은 다음과 같다.

 Event Measurement

• 업무행위가 발생될 때 계수에 반영된다.
• 예를 들어, 신계약이 체결되면 신계약건수에 값이 반영된다.
• 그러므로 특정 일자 혹은 기간 동안 관련된 업무행위가 발생되지 않으면 해당 Measurement가 포함되어 있는 Fact 테이블에도 데이터가 발생되지 않는다.
• 한편, 시계열적으로 해당 Measurement를 합산했을 때 그 결과가 유효한 Fact(=사실)이다. 즉, 5월 한 달 간 매일 신계약이 10건씩 발생되었다면 5월의 신계약건수는 10건 * 31일에 해당하는 310건이 될 것이다(이러한 특성을 Ralph Kimball은 (Fully) Additive하다고 했다).

Status Measurement

• 어떤 대상(계약, 계좌 등)의 상태를 측정하여 계수에 반영한다.
• 특정 일자 혹은 기간 동안 업무행위가 전혀 발생되지 않았더라도 상태 Measurement가 포함되어 있는 Fact 테이블에는 데이터가 발생되어야 한다.
• 예를 들어, 전월 말 기준 유효계약건수가 15,000,000 건이었는데 당월에 신계약도 발생되지 않았고 만기가 도래되었거나 해지된 계약 건이 전혀 없었더라도 당월 말 유효계약건수는 15,000,000 건이 발생되어야 한다. 왜냐 하면 유효계약건수는 계약 데이터의 ‘상태’이므로…
• 이러한 Status Measurement는 관련 업무가 시작된 이래로 모든 Event들을 모은 결과인 것이다. 신계약이 발생되면 유효계약건수가 증가되었다가 만기 또는 해지되면 유효계약건수가 감소될 것이다.
• 한편, 시계열적으로 해당 Measurement를 합산했을 때 그 결과가 유효한 Fact(=사실)가 될 수 없다. 비현실적인 예가 되겠지만, 1월부터 12월까지 매 월 말일자의 유효계약건수가 각각 15,000,000 건씩이라고 가정했을 때 해당 년도의 유효계약건수는 15,000,000  건 * 12개월에 해당되는 180,000,000 건인가? 그렇지 않다. 해당 년도의 유효계약건수는 해당 년도의 말일(12월 31일) 기준의 계약 상태가 ‘유효’인 건들의 건수이므로 여전히 15,000,000 건이다(이러한 특성을 Ralph Kimball은 Non-Additive하다고 했다. 엄밀히 말하자면 Semi-Additive이다. 이와 관련된 내용은 다음 회에 설명하기로 한다.).

프로젝트를 수행하는 동안 세상 모든 종류의 Measurement들을 Event Measurement와 Status Measurement로 분류해도 될 것인가에 대한 Self-Question에 대한 답을 얻어보고자 데이터 모델링이나 데이터 웨어하우스 권위자들의 서적 등을 통해 확인해보고자 했으나 그 당시에는 알 수 없었고, 몇 년 전 Ralph Kimball이 Transaction Fact(=Event), Periodic Snapshot Fact(=Status), Accumulating Snapshot Fact(=다수의 Event들을 하나의 Fact 테이블에 표현함으로써 어떤 결과에 이르는 소요시간 등이 쉽게 측정될 수 있도록 구조화한 것)로 분류하고 있음을 확인하였고 Tom Haughey도 이와 유사하게 Transaction(=Event), Line Item(주문과 같은 헤더 정보에 다수 개의 Transaction(=Event)들이 1:M 형식으로 표현되는 Fact), Status/Balance 분류하고 있음을 확인하게 되었다.

정보계 프로젝트를 수행하고 있거나 혹은 운영 중인 독자들께서는 고객의 요구사항에 표현되어 있는 Measurement가 Event인지 Status인지를 확인하고 특성을 고려하여 설계 및 개발할 것을 권고하면서 1회차 포스팅을 정리하고자 한다.

다음 회에는 손해율 Measurement에 관한 경험을 이와 유사한 방식으로 이야기해 볼 예정이다.