데이터실무

DA, SQL, DB보안 등 실무자를 위한 위한 DB기술 바이블!

업무 처리 프로세스 수립 및 운영

데이터 운영관리
분석시스템관리
업무 처리 프로세스 수립 및 운영
작성자
admin
작성일
2021-02-15 15:18
조회
9122

요건정의

본 요건정의 프로세스에서 나오는 내용은 기획단계에서 분석 과제 정의를 통해 도출된 내용이다. 그러나 기획단계에서는 상위 전략적 측면을 다루기 때문에 상세한 수준의 내용이 정의되지 못한다. 전사적 관점에서의 기회를 포착하고 이를 평가·선택하고 다시 과제로 묶어서 분석 테마가 나오게 된다. 분석 테마는 모든 내용을 유사하게 다룰 것이다. 깊이만 다를 뿐이다. 특정 분석기법은 정확한 수치보다는 개략적인 내용중심으로 다룬다. 따라서 분석 요건정의는 매우 실무적인 업무로 이해해야 한다.
요건정의는 분석 요건을 구체적으로 도출·선별·결정하고, 분석과정을 설계하고, 구체적인 내용을 실무담당자와 협의하는 업무다. 광범위하고 다양한 정보를 다루고 문서화 작업의 비중이 높다. 전체 프로세스 중에서 가장 중요한 부분으로, 빅데이터 분석업무의 성패를 좌우한다.

[그림 Ⅴ-1-16] 데이터 분석 방법 및 분석적 사고 교육

[그림 Ⅴ-1-16] 데이터 분석 방법 및 분석적 사고 교육


분석요건 도출

여기에서 요건은 비즈니스 이슈로부터 도출된다. 우선 이슈 정의를 해본다면 업무를 수행하는 데 있어서 수익 증가나 비용 증가, 상황의 변화, 처리 속도의 지연 등을 발생시키는 항목들로 전사적 측면에서 개선돼야 할 사항이다. 주의할 점은 단순한 불편한 사항이나 불만 사항을 요건으로 접근하면, 비즈니스적 의미가 낮아지고 분석 결과를 보고하거나 실행에 옮기는데 타당성을 잃을 가능성이 매우 높다. 따라서 다양한 이슈로부터 진정한 요건이 될 수 있는 항목을 선정하는 것부터가 매우 중요한 과목 Ⅴ 데이터 운영관리 682 빅데이터 실무 기술 가이드 일이다. 분석요건 도출 단계는 기획단계와 유사하지만, 상세하게 접근하고 실무 측면으로 진행하는 특성이 있다. 따라서 분석요건의 조건은 문제를 해결했을 때 투자수익 ROI)으로 증명할 수 있다. 만약 재무적 관점에서 증명할 수 없는 사항이라면 아무리 빅데이터 분석에 해당되는 흥미로운 주제일지라도 기업은 선택 할 수 없다.
요건을 정의하는 단계에서는 상세한 분석보다는 문헌조사 및 이해와 간단한 기초 분석을 수행할 수 있다. 요건으로 제시된 내용에 대한 사실을 확인하고 통찰을 도출해 방향성을 설정하는 데 필요한 수준이면 된다. 따라서 요건정의에 너무 많은 시간을 할당하면 전체 업무 진행에 차질이 따를 수 있다. 이 단계에서는 전문가의 방향성 제시와 이해 관계자들 간의 합의가 중요하다. 기획 단계에서는 ‘캠페인 반응율을 개선해야 한다. 수준이나 재구매 유도 캠페인을 개선·강화해야 한다.’ 정도로 분석요건이 정의된다. 데이터 마이닝 단계에서 요건 정의는 ‘캠페인 반응율 개선을 통한 CRM 업무 효율성 증대, 캠페인 채널 비용 절감, 캠페인 대상 20% 증대 방안’ 정도다.
분석단계의 요건 정의에서는 ‘재구매 유도 캠페인의 대상 고객 20% 확대 방안에 대해 전체 고객구성 상황, 현재의 재구매 캠페인 대상, 캠페인별로 대상이 어떻게 정의되고 변경되는지, 성과는 어떠한지, 미흡한 점은 무엇인지, 어떤 곳에서 재구매 대상을 늘리고 이에 대한 비용은 어디서 보충할 것인지’ 등을 정의한다. 데이터 마이닝의 요건은 ‘캠페인 반응율 개선을 통한 효율성 또는 비용절감’과 같이 정의된다. 시뮬레이션 요건은 ’의약품 분리장비 추가도입에 따른 업무시간 및 재무효과의 변화 검토’, 최적화의 경우 ‘병원의 간호사 배치에 대한 진료과별 최적 할당’ 또는 ‘근무 시간표 최적할당’ 등으로 정의된다. 요건에 대한 현재의 이슈와 실상은 무엇인지, 어떻게 개선할지, 어느 정도 개선할 수 있을지 등을 보완자료로 추가한다.


수행 준거

데이터 분석 업무의 배경·주요 이슈·기대효과·제약사항을 파악할 수 있으며, 이해 관계자들과 의사소통을 통해 데이터 분석요건을 식별할 수 있다. 식별된 데이터 분석요건을 현업의 문서를 수집해 일부 수행함으로써 기획 단계에서 간과할 수 있는 사항을 상세화·구체화할 수 있다. 상세화·구체화한 데이터 분석요건을 명세화할 수 있으며, 종합적으로 분석요건의 적합성을 평가할 수 있어야 한다.


고려사항

IEEE에서 정의한 요구공학 프로세스를 고려해야 한다. 요구사항 추출(Elicitation), 요구사항 분석(Analysis), 요구사항 명세(Specification), 요구사항 검증(Validation), 요구사항 유지보수 (Maintenance) 등과 IIBA에서 식별한 일반적으로 인정된 브레인스토밍, 기존 문서 검토(Review Existing Documentation), 외부 인터페이스 분석(External Interface Analysis), 집중 집단 인터뷰 (Focus Group Interview), 관찰 또는 직무 체험(Job Shadowing), 요구사항 도출 워크숍Requirement Elicitation Workshop), 인터뷰(Inteview), 설문(Survey) 등과 같은 요구사항 도출 테크닉을 고려할 수 있다. 이 단계에서는 개별 분석요건에 대한 지나친 상세화보다는 기존 분석 자료와 정보를 기반으로 분석요건 항목들을 누락 없이 식별하는 것에 집중해야 하며, 분석요건은 분석 과정에서 더 구체화되고 수정되는 것이 타당하다.
데이터 분석 업무 이해 당사자들과의 긴밀한 커뮤니케이션과 데이터 분석 기대 효과에 대한 명확한 사전 정의와 협의가 필수적이다. 개인정보 보호, 접근 통제 등 정보 보안 정책과 충돌할 수도 있기 때문에 이에 대한 사전 확인·협의를 필수적으로 고려해야 한다.


수행방안 설계

앞에서 정의한 분석요건에 따라 구체적인 수행방안을 설계한다. 수행방안은 분석요건이 정해졌다고 해서 확정되는 것은 아니다. 분석을 구체적으로 수행하기 위해서는 간단한 탐색적 분석을 수행하면서 미리 가설을 수립해 어떤 분석을 수행할지 틀을 잡아야 한다. 이런 절차와 방안을 수립해야 하는 이유가 있다. 탐색적 분석을 하면서 분석 자체가 의미 없다는 것을 미리 파악할 수 있는 기회를 얻을 수 있다. 결국 자원과 비용, 시간 낭비를 막을 수 있기 때문이다. 미리 가설을 수립해 수행방안을 설계하지 않고 진행하면 분석 필수항목과 선택항목, 어떠한 일정으로 어느 정도 자원이 필요한지 계획 수립이 어려워 진다.
분석자 입장에서는 분석을 해가면서 다양한 시도를 하고 싶지만, 이 경우 품질이나 납기 준수가 어려워 진다. 따라서 반드시 선험적인 지식을 통해 수행방안을 구체적으로 설계해야 한다. 이 단계에서는 반드시 분석기법을 정의하고 진행해야 하며, 결정 시 해당 분석기법에 대한 전문 지식을 갖춘 인력이 참가해 검토해야 한다. 다양한 분석기법을 이해한 전문가가 적합한 분석기법을 다양한 측면에서 검토해 가장 적합한 방법을 제시할 수 있어야 한다. 예를 들어 여름 장마철에 얼마나 홍수가 발생할지 분류·예측할 때에는 데이터 마이닝 전문가가, 어디에서 홍수가 발생할지는 시뮬레이션 전문가가, 홍수 방지 댐 건설 등 한정된 비용을 최적으로 분배해야 하는 최적화 분야에는 최적화 전문가가 참여해 해당 분석기법에 필요한 데이터나 접근방법, 분석도구 및 IT자원 등에 대해 검토할 수 있어야 한다.
빅데이터 기획 단계에서는 전체 로드맵과 선행 및 후행 과제만 정의된다. 여기서 다루는 수행 방안의 최종 산출물은 분석 계획서와 WBS(Work Breakdown Structure)다. 월 단위가 아닌 일 단위가 돼야 하고, 상세한 내용이 정의되는 과정에서 상위 기획단계에서 미처 고려하지 못한 구체적 업무와 자원, 선행관계 등의 충돌로 일정이 부족할 수도 있다.
수행방안의 최종 산출물은 분석 계획서와 WBS다. 분석 계획서는 핵심적인 분석항목과 구체적인 분석범위를 지정해 분석범위를 명확히 하고, 관련된 업무와의 선행 및 후행관계를 검토하기 위해서는 이에 대한 WBS를 일 단위로 아래와 같이 작성해야 한다.

[표 V-1-5] 분석수행 관리를 위한 WBS 예시


Phase Task Method Resources W1
D1 D2 D3 D4 D5

WBS를 작성할 때는 우선 Forward 방식으로 전개를 해보고 납기를 만족시킬 수 있는지를 확인한다. 만약 납기를 초과할 경우 납기 기준으로 Backward로 전개해 언제 특정업무를 반드시 시작해야 하는지를 파악한다. 자원 추가, 일정 조절, 요건 조절 등으로 일정 충돌을 해결한다. 특히 빅데이터 프로젝트는 처리 속도에서 이슈가 발생할 수 있으므로 이를 염두에 두고 접근한다.
빅데이터 인프라 기술과 분석 기술을 겸비한 인력을 구하기는 다른 분야보다 더 어렵다. 따라서 인력이 양 업무를 동시에 수행하는 것은 피해야 하며, 기술 인력은 특정기간에 제한적으로 필요한 경우가 많으므로 해당 시점에만 투입할 수도 있다. 동일 업무에 대해 기술 담당자가 해야 할지, 분석 담당자가 해야 할지에 대해서는 처리속도 및 IT자원의 효율적 활용이라는 기준에서 바라보고 결정해야 한다. 수백 TB의 데이터를 굳이 R에서 처리할 필요는 없으며, Hive 등에서 처리하고 요약해 1TB 이하로 만든 다음, R에서 처리하는 게 적합하다.


수행 준거

권한 및 계정을 확보해 데이터베이스 접근환경을 구축할 수 있고, 분석 대상 데이터의 존재여부와 품질을 확인할 수 있으며, 간단한 기초분석을 통해 분석수행 타당성을 확인한다. 분석기법, 수행 단계 및 절차, 인도 산출물, 주요 일정, 수행 인력을 식별하고 구성해 분석 방법론을 구축할 수 있고, 구축된 분석 방법론을 기반으로 분석 프로젝트 수행 계획을 수립할 수 있다.


고려사항

분석 수행 방법론 구축 시 프로젝트 관련 지식 체계인 프로젝트 통합관리(Project Integration Management), 프로젝트 범위 관리(Project Scope Management), 프로젝트 시간 관리(Project Time Management), 프로젝트 비용 관리(Project Cost Management), 프로젝트 질 관리(Project Quality Management), 프로젝트 인력 관리(Project Human Resource Management), 프로젝트 의사소통 관리(Project Communication Management), 프로젝트 위험 관리(Project Risk Management), 프로젝트 조달 관리(Project Procurement Management), 프로젝트 이해당사자 관리(Project Stakeholders Management)를 참조 및 활용해야 한다. 분석 프로젝트 수행 계획에는 일정 계획, 수행 조직 및 역할·책임, 표준 인도 산출물, 품질관리 계획(테스트 및 요건 검증 계획 포함), 위험 관리 계획, 의사소통 계획(보고서 제출 주기, 회의 운영일정 등)과 같은 항목들이 포함될 수 있다.
필수 분석 항목과 선택 분석 항목들을 사전에 구분해 우선순위를 부여하고, 우선순위가 높은 필수 분석 항목들이 작업 대상에서 누락되지 않도록 한다. 예상한 결과가 나오지 않을 경우, 대안적 접근 방안으로 분석 항목들을 추가·식별할 수 있다. 필수·보조·대안적 접근에 대한 절대적 분석 시간을 분석자의 역량, 분석 대상의 규모, 분석 대상의 복잡성, 분석 관련 자료의 획득 및 가공 용이성을 기반으로 예측하며, 주요 수행 마일스톤들을 식별해야 한다. 데이터 오류 또는 분석 수행 오류 등으로 인한 재작업 시간을 분석해 일정에 반영한다. 데이터 오류 및 시스템 성능 부족 현상 발생 등 관련 위험들을 사전 식별하고 대응 방안을 수행한다.


요건 확정

요건 도출과 분석계획을 수립하면, 요건에 어떻게 접근하고 어떤 정량적·정상적 효과가 나올지 기획안이 나온다. 이를 통해 분석 요청 부서와 IT 부서, 기타 연관 부서와 공유해 최종요건을 확정한다. 이 단계에서는 기획단계에서 나온 분석 과제가 기각될 수도 있다.
자세한 현황과 내용을 정의하는 과정에서 기획단계의 오류를 발견할 수 있다. 그리고 사전에 충분히 소통하지 않을 경우, 요건 확정이 어려우므로 사전에 지속적으로 대화·조율하며 요건을 확정한다. 특히 분석은 복잡성과 전문성이 필요한 분야이므로 짧은 시간 안에 상대방으로부터 이해를 구하기 어렵다. 한번 확정된 요건을 종료(Closing)해 이후에 변경하는 일이 없도록 해야 한다. 확정된 요건이 바뀌기 시작하면 다시 반복 작업들로 시간을 보낼 수 있으므로, 요건을 명확히 처리·결정한다. 하지만 실무를 하다 보면, 모델링 과정에서 요건이 변경되는 일은 빈번히 발생한다. 프로젝트 완료일을 준수할 수 있는 범위에서 조율해야 한다.


수행 준거

상세화·구체화·명세화한 데이터 분석요건 항목을 기준으로 추진 의미가 있는지를 최종 결정하며, 이해 관계자들에게 설명할 수 있어야 한다. 공식 변경 관리를 통해, 데이터의 분석요건 항목들을 변경할 수 있다. 분석요건에 대한 적합성·타당성·일정 계획에서의 제약을 종합해 업무범위(Scope)를 조정할 수 있다. 확정 데이터 분석요건 항목들을 변경 이력 및 추적성을 확보해 현행화할 수 있다. 데이터 분석요건을 문서화해 이해관계자들 간 공식적으로 확장할 수 있다.


고려사항

데이터 분석요건 변경은 반드시 공식 변경관리 절차에 따라 이뤄져야 한다. 데이터 분석요건은 특정 이해 관계자의 의견 위주로 확정하기 보다, 참여자들의 다양한 시각과 의견이 폭 넓게 수집 ·수렴·고려해 확정한다. 이해관계자들 간의 의견 불일치를 최소화하고, 만약 의견 대립 시 이를 적극 조율해야 한다. 요건 확정 이후에 데이터 분석요건 변경은 전체 프로젝트에 큰 영향(대부분 부정적)을 미치므로 모든 이해관계자들의 공감대 아래 진행한다.


모델링

모델링은 요건정의에 따라 상세 분석기법을 적용해 모델을 개발하는 과정이다. 빅데이터 분석에서 모델링을 거치면, 필요한 입력 데이터에 대한 처리가 매우 용이해진다. 시뮬레이션이나 최적화에서 필요한 자료가 빅데이터 분석 시스템에 이미 존재할 가능성이 높다. 예를 들어 엘리베이터 운행에 대한 시뮬레이션을 시도할 때, 엘리베이터 사용에 대해 어느 층에서 언제 사용자가 버튼을 눌렀는지, 탑승한 경우 몇 층을 지정했는지, 대기시간이 어느 정도였는지에 대한 실제 데이터가 있어서 이를 분석해 시뮬레이션을 위한 실증적 분포(Empirical Distribution)를 사용할 수 있게 된다.
기존에는 이런 데이터가 머신 데이터로 입수·누적되지 않아 별도로 사람이 시간연구(Time Study)를 하거나 일부 가정조건으로 데이터를 처리해야 하는 경우가 빈번했다. 최적화에서도 제약조건에 해당되는 값이 실제 어떠했는지 시스템에 존재한다. 결국 가정하거나 인터뷰해 값을 구할 일이 없어지므로 모델링 시 데이터 획득 및 검증에 소요되는 시간이 크게 줄어든다. 빅데이터 분석의 모델링에 대해서는 해당기법에 대한 전문 지식이 필요해 ‘모델링’에서 각각 상세한 모델링 방법을 알아보겠다.

[그림 Ⅴ-1-17] 빅데이터 분석 프로세스에서 모델링

[그림 Ⅴ-1-17] 빅데이터 분석 프로세스에서 모델링


모델링 마트 설계와 구축

어떤 모델링 기법을 사용하든 모델링을 위한 데이터를 시스템에 체계적으로 미리 준비해 놓으면 모델링이 용이해진다. 모델링 도구에 따라 DBMS에서 직접 값을 가져와 반영할 수 있는 기능도 제공한다. 따라서 모델링 진행 전에 필요한 데이터의 마트를 설계해 비정규화(De-normalized) 상태로 처리하면 사용이 편하다. 특히 데이터 마이닝에서 지도학습(Supervised Learning)은 모델링 마트를 직접 이용해 모델을 개발할 수 있다.


수행 준거

다양한 원천 데이터로부터 분석 대상 데이터를 획득할 수 있다. 분석 대상 데이터를 탐색 ·정제·요약 등 전처리해 변수들을 식별할 수 있다. 분석 대상 데이터를 구조화하는 모델 마트를 설계할 수 있다. 전처리한 분석 대상 데이터를 적재해 모델 마트를 구축할 수 있다.


고려사항

데이터 원천은 관계형 DB, 데이터 웨어하우스, 시스템 로그, 비정형 텍스트 데이터 등 다양한 형태로 존재할 수 있다. 분석 대상 데이터(변수)는 연속형과 범주형으로 구분할 수 있다. 연속형은 주어진 범위 내의 연속되는 실수들로 구성되고, 범주형은 수치형과 텍스트형으로 구분할 수 있으며, 다시 순위 정보를 포함하지 않는 명목형 변수와 순위 정보를 포함하는 순위형 변수로도 구분된다.
재활용성이 높은 모델 마트 설계·구축을 위해서는 원천 데이터에 대한 명확한 이해가 선행돼야 한다. 기존 정보 시스템 내의 데이터를 최대한 활용·확장하는 접근을 하고, 신중히 채택된 가설을 기반으로 마트를 설계해 작업 효율성을 최대화한다. 데이터의 획득·수정·확정이 지연될 우려가 크므로, 계획된 기간 내에 데이터 획득과 확정을 강제해 현실적인 작업 수행을 유도해야 한다. 데이터 정제 시 1단계(데이터 요약), 2단계(파생 변수 도출), 3단계(변수 확대)라는 단계별 접근 기법을 권고한다.


탐색적 분석과 유의 변수 도출

데이터 마이닝에 해당하는 업무로 해당 비즈니스 이해와 분석요건에 대한 구체적인 사실(fact)을 발견해 통찰을 얻기 위해 수행하는 업무로 흔히 EDA(탐구 데이터 분석, exploratory data analysis)라고 한다.
EDA는 매우 시간을 많이 필요한 일로 최근에는 EDA를 자동으로 신속하게 수행해 유의미한 값만 파악해 데이터 마트로 만든 후 모델링 업무로 진행하는 게 일반적이다. 유의미한 변수를 파악하는 방안은 목표값(Target Value)별로 해당 변수가 분포된 값을 보고 해당 변수의 구간에서 차이가 큰지를 파악한다. 만약 이런 구간이 존재하면 유의미한 변수임을 시각적으로 알아볼 수 있다. 이 단계와 최종분석결과를 산출하고 결과를 공유하는 단계에서는 시각화가 매우 중요한 역할을 하는데 전문적 지식이 없는 사람들의 이해를 도울 수 있다.
그러나 여기서 시각화는 정보를 효율적인 방식으로 제시한다는 데 의미가 있지, 전문적인 시각화 구현을 의미하지 않는다. 예를 들어 3D(Three Dimension)를 이용한 개발 수준을 의미하지 않는다. 시각화해 정보를 제시할 때 유의할 점은 모양이 좋은 것보다도 펙트와 통찰을 전달할 수 있는 것에 중점을 둔다. 따라서 단순 그래프 출력은 지양한다. 시각화를 할 때는 제시하고자 하는 정보의 차이가 있다. 추세의 변화, 다른 것과 비교하는 데 적합한 그래프 형식의 선택이 필수적이고 불필요한 스케일 조절은 잘못된 길로 인도할 소지가 높으므로 지양한다.


수행 준거

분석 목적과 요건, 데이터 특성을 기반으로 적합한 데이터 분석기법을 선정할 수 있다. 선정된 데이터 분석기법을 기준으로 분석 모형을 설계할 수 있다. 설계한 분석 모형을 기준으로 유의성을 분석해, 높은 유의성을 보유한 변수들을 식별할 수 있다. 높은 유의성을 보유한 최소한의 변수들로 분석 모형들을 구축할 수 있다.


고려사항

분석 모형 설계·구축 시에는, 해당 모형의 학습·평가·검증을 통해 최적의 모형을 선정 및 적용하기 위해 하나 이상의 모형을 준비하는 것이 타당하다. 탐색적 분석을 통해 준비된 데이터의 가설 적합성과 충분성을 사전 검증해야 한다.
변수의 유의성 검증 후 유의성이 높은 최소한의 변수들로 분석 모형을 검증할 것을 권장한다. 시뮬레이션을 통해 기 수립된 분석 모형의 타당성과 적합성을 판단해 반복적으로 보정해야 한다. 최적화를 위해 분석 모형 및 데이터의 유의성을 반복적으로 보정해야 한다. 최소한의 시간에 탐색적 분석을 완료하는 것이 성공적인 분석의 관건으로, 단위 분석에 대한 예상 소요 시간을 추정해 필요 시 샘플링할 것을 권고한다. 탐색적 분석과 유의변수 도출 과정에서 정보의 부족함 식별 시, 신속하게 추가 변수를 개발해 데이터 마트에 반영해야 한다.


모델링

모델링은 개념적인 모델링도 있지만, 결국 이를 구현해 적용할 수 있어야 한다. 전체 내용을 제대로 제시하려면 특정 도구를 사용해야 한다. SQL은 거의 차이가 없고, 표준이라고 할 수 있는 ANSI SQL이 있다. 그러나 주요 DBMS 공급사들은 자사 특성에 따라 다양한 기능을 추가·제시하므로 ANSI SQL로 활용·적용에 대한 정보를 제시할 수 있는 것은 매우 제한적이다. 따라서 SQL의 경우도 특정 공급사의 SQL을 이용해 제시함으로써 이해 및 실습과 적용에 도움을 줄 수 있다.
가장 광범위하게 사용되고 학습을 위해 획득이 용이한 DBMS를 선택해야 한다. 이처럼 분석에서도 동일한 어려움이 있다. 분석도구도 데이터 마이닝, 시뮬레이션, 최적화별로 산업에서 시장 점유율이 높은 도구들이 다양하게 있고, 일부는 데이터 마이닝 도구에서 시뮬레이션이나 최적화를 지원하기도 한다. 대표적인 예가 오픈소스 R이다. R은 데이터 입수 및 변환, 분석용 마트 생성에서 기초통계 및 기타 다양한 분야의 시각화, 시뮬레이션 및 최적화를 지원한다. 상용 시뮬레이션 도구와 최적화 도구가 있지만, 입수 및 다양한 적용이 쉬운 오픈소스 R 기반으로 모델링을 소개한다. 단 시뮬레이션은 매우 전문적인 불연속(Discrete) 시뮬레이션 모델이 가장 많이 사용되므로 해당 내용에 대해서는 특정 도구를 기준으로 학습하기보다는 개념으로 제시한다. 최적화는 일정 부분까지 R 기반으로 소개한다.


수행 준거

다양한 모델링 기법을 능숙하게 다뤄 업무 특성에 적합한 기법을 선택하거나 모델링 기법을 결합해 적용할 수 있어야 한다. 선택된 모델링 기법을 이용해 모델링한다. 미래값을 예측하는 데 프로세스적인 측면이 없으면, 데이터 마이닝 모델링을 수행한다. 프로세스 및 자원에 대한 제약이 있고 입력값이 확률분포를 갖는 경우, 시뮬레이션 기법을 선택한다. 프로세스 및 자원에 대한 제약이 있고 상수값을 가질 때는 최적화 기법을 사용한다. 경우에 따라 시뮬레이션과 최적화를 결합접근할 수 있다.


고려사항

데이터 마이닝 모델링은 통계적 모델링이 아니므로 지나치게 통계적 가설이나 유의성에 집착하지 말아야 한다. 충분한 시간이 있으면 다양한 옵션을 줘서 시도하며, 일정 성과가 나오면 해석과 활용 단계로 진행할 수 있도록 의사 결정해야 한다. 분석 데이터를 훈련 및 테스트 데이터로 6:4, 7:3, 8:2 비율로 상황에 맞게 실시한다.
훈련 및 테스트 성능에 큰 편차가 없고 예상 성능을 만족하면 중단한다. 과도한 성능에 대한 집착으로 분석 모델링의 주목적이 실무 적용에 있음을 간과하고 시간을 낭비하면 후속 검증 및 적용에 지연이 발생할 수 있다.


모델링 성능평가

모델링 성능을 평가하는 기준은 분석 기법별로 다양하다. 데이터 마이닝에서는 정확도(Accuracy), 정밀도(Precision), 디텍트 레이트(Detect Rate), 리프트(Lift) 등의 값으로 판단한다. 시뮬레이션에서는 Throughput, Average aiting Time, Average Queue Length, Time in System 등의 지표가 활용된다. 최저화 에서는 최적화 이전의 Object Function Value와 최적화 이후의 값의 차이를 구해 평가할 수 있다.


수행 준거

분석 모형 적합성 판단 기준을 수립할 수 있다. 분석 모형별 학습용 데이터 집합을 구축할 수 있다. 구축된 학습용 데이터로 분석 모형을 조정할 수 있다. 학습용 데이터를 활용해 조정한 분석 모형에 검증용 데이터를 적용해, 학습용 데이터 기반 결과와 검증용 데이터 기반 결과를 비교·분석할 수 있다. 검증 결과에 따라 필요 시 분석 모형과 데이터(항목, 건수)를 조정해 최적화할 수 있다. 선정된 기법(방법)으로 분석 모형을 실제 운영환경에 적용할 수 있으며, 오픈소스 R을 이용할 때는 샤이니(shiny)를 이용해 배포할 수 있다.


고려사항

업무 특성에 따라 다양한 모델링 기법을 선택하거나 결합해 적용할 수 있어야 한다. 미래 값을 예측하는 데 프로세스적인 측면이 없으면, 데이터 마이닝 모델링을 수행한다. 프로세스 및 자원에 대한 제약이 있고 입력 값이 확률 분포를 가지면 시뮬레이션 기법을 선택한다. 프로세스 및 자원에 대한 제약이 있고 상수값을 갖는 경우는 최적화 기법을 사용한다. 경우에 따라 시뮬레이션과 최적화를 결합해 접근할 수 있다. 데이터 마이닝 모델링은 통계적 모델링이 아니므로 지나치게 통계적 가설이나 유의성에 집착하지 말아야 한다.
다양한 옵션에 대한 시도는 충분한 시간이 있으면 실시하며, 일정 성과가 나오면 해석 및 활용적 측면 단계로 옮겨가야 한다. 훈련 및 테스트 성능에 큰 편차가 없고 예상 성능을 만족하는 시점에 작업을 완료할 수 있다. 성능에 대한 과도한 집착으로 인해 분석 모델링의 실무 적용이라는 핵심 목적이 간과되고, 후속 검증 및 적용에 지연이 발생할 수 있음을 염두에 둔다.


검증 및 테스트

모든 모델링에서는 반드시 검증 및 테스트를 거친다. 분석용 데이터를 트레이닝(Training)용과 테스트용으로 분리한 다음, 분석용 데이터를 이용해 자체 검증한다. 실제 테스트에서는 신규 데이터에 모델을 적용해 결과를 도출한다. 테스트 데이터의 비율은 분석용 데이터세트의 30% 정도를 이용하는 게 일반적이나 전체 데이터가 충분할 경우 6:4 또는 5:5로 분리해 테스트 집단을 선정할 수 있다.
이 내용은 IT에서의 단위시험(Unit Test)에 해당된다.

[그림 Ⅴ-1-18] 빅데이터 분석 프로세스에서 검증과 테스트

[그림 Ⅴ-1-18] 빅데이터 분석 프로세스에서 검증과 테스트


운영 상황에서 실제 테스트

운영상황에서 실제 테스트는 분석 결과를 업무 프로세스에 가상으로 적용해 검증하는 실무 적용 직전의 활동이다. 이를 자동화만 하면 실무에 언제든지 적용할 수 있다. 따라서 운영상황에서 실제로 테스트해 분석과 운영 간 연계를 검증할 수 있고, 돌발 상황에서 문제 없이 모델을 적용할 수 있는지 전체적인 흐름을 통합 시험(integration Test)하는 과정이다.


수행 준거

구축 및 조정된 분석 모형을 테스트하기 위한 유사 운영환경을 구축할 수 있다. 구축한 유사 운영환경에서 분석 모형을 테스트하기 위한 절차를 설계할 수 있다. 설계된 절차에 따라 테스트하고 그 결과를 분석할 수 있다. 테스트 결과를 기반으로 분석 모형을 조정해 반복 테스트할 수 있다. 최종 테스트 결과를 기반으로 분석 모형의 실제 운영환경 적용을 판단할 수 있다.


고려사항

분석 모형의 유형에 따라 과적합화(overfitting)가 발생할 수 있으므로 주의가 필요하다. 실제 운영환경 성능 테스트는 사전 시나리오를 따라 1주일 정도 실시할 것을 권장한다(시뮬레이션은 실제 운영환경에서 성능 테스트 불가). 실제 운영환경 성능의 일 단위 측정이 가능한 경우, 1주일간 일 단위 성능이 일관됨을 확인해야 한다.
성능 테스트 결과는 일 단위로 공유해 분석 모형의 실무 적용의 객관성을 유지할 것을 권고한다. 모델링 결과로 인한 업무 변화(업무 절차, 조직 등)에 대한 반발이 예상되므로, 조직 변화관리와 병행할 것을 권고한다. 성능 테스트는 최소 3회 이상, 테스트 기간은 최소 1주 이상으로 할 것을 권고한다.
성능 테스트 시 불필요한 외부 이해관계의 개입을 최소화 또는 차단해, 성능 테스트 수행 과정 및 결과의 왜곡을 방지해야 한다.


비즈니스 영향도 평가

의미 있는 분석 결과를 확보하려면 비즈니스 영향도와 효과를 산출할 수 있어야 한다. 정확성을 높여 비용이나 만족도를 개선하거나, 추가 수익을 창출할 수 있어야 한다. 그리고 ROI를 산출해 해당 분석에 투자한 비용 대비 재무 효과가 200~300% 이상임을 증명해야 CFO(Chief Finance Officer)가 받아들일 수 있다. 이러한 영향도와 효과는 실제 테스트를 통해 나온 최종 결과로 산출해 이를 기반으로 정량적 효과를 도출할 수 있다. 따라서 최대한 충분한 기간 실행하고 전체를 대표할 수 있을 만큼의 테스트를 실행해 영향도나 효과를 산출하는 데 모두들 납득할 수 있는 결과를 산출해야 한다.
영향도를 산출하는 데는 해당 업무 전문가의 도움이 절대적으로 필요하며, 재무정보 입수를 위해서는 재무팀과의 논의가 필요하다. 예를 들어 캠페인 효율과 효과가 올라간 경우, 매출액이 증가하면 수익이 얼마가 올라가는 지에 대한 제품군별 영업이익률에 대한 정보, 자동화에 따른 인건비 절감액, 직급별 시간당 원가 등은 재무팀과 협의가 필요하다.


수행 준거

모델링 성과에서의 Detection Rate가 증가하거나 Lift가 개선돼 발생되는 정량적 효과에 대해 비즈니스적인 효과를 제시하도록 한다. 효과는 직접적 정량적 효과에 집중하도록 한다. 타 모델링과의 중복에 따른 효과를 통제·제시할 수 있어야 한다. 기대효과는 수익과 ROI로 제시한다.


고려사항

투자 대비 효과 정량화 기법에는 총 소유 비용(TCO, Total Cost of Ownership), 투자대비효과(ROI, Return On Investment), 순현재가치(NPV, Net Present Value), 내부수익률(IRR, Internal Rate of Return), 투자회수기간(PP, Payback Period)등이 있다.
데이터 마이닝 모델링에서는 Detection Rate가 증가하거나 Lift가 개선돼 발생되는 정량적 효과를 제시한다. 시뮬레이션에서는 처리량, 대기시간, 대기행렬의 감소를 통한 정량적 효과를 제시한다. 최적화에서는 목적함수가 증가한 만큼의 정량적 효과를 제시한다. 사업 특성에 따라 비용요소가 이미 영업이익율이나 공헌이익에 반영됐을 수 있으므로 중복적으로 비용 요소를 차감하지 말아야 한다. 타 사업부문과의 중복적인 측면을 고려해야 하나 하나 단위 프로젝트에서의 수익과 비용으로 평가하는 것이 원칙이며, 투자비용이 과다한 경우 타 과제와의 분배를 협의해야 한다.


적용

적용은 분석결과를 업무 프로세스에 완전히 통합해 실제 일·주·월 단위로 운영하는 것이다. 분석시스템과 연계돼 사용될 수 있고, 별도 코드로 분리돼 기존 시스템(legacy system)에 별도 개발해 운영할 수 있다.

[그림 Ⅴ-1-19] 빅데이터 분석 프로세스에서 적용

[그림 Ⅴ-1-19] 빅데이터 분석 프로세스에서 적용


운영 시스템에 적용과 자동화

운영 시스템에 적용해 운영하면 실시간 또는 배치 스케줄러(Batch Scheduler)가 실행하고, 주기별로 분석 모델의 성과가 예상했던 수준으로 나오고 있는지 모니터링할 수 있다. 이때 DBMS에 성과자료를 누적하고, 이상 현상이 발생하면 경고(Alert)를 자동으로 발송하도록 설정한다.
특히 분석모델은 개발된 내용이 많아질수록 상시 파악을 수작업으로 하는 일이 매우 큰 부담이 되므로 자동으로 이뤄지고 이상 시에만 확인하도록 프로세스를 수립해 놓아야 한다. 그래야 분석업무를 다양한 분야에 적용할 수 있고, 지속적인 정교화 과정을 통해 성과를 거둘 수 있다. 오픈소스 R을 이용해 이 단계를 단순화할 수 있다. R은 GUI를 지원해 사용자가 직접 구체적인 작업을 하고, 분석 결과를 보고, 외부와의 연계를 단순화해 인터랙티브하게 진행할 수 있다. R Studio에서 제공하는 샤이니(shiny)를 이용해 모델링 결과를 사용자 작업 파일과 서버상의 파일을 이용해 간단히 배포할 수도 있다.
샤이니는 사용자 작업파일(ui. R)과 서버파일(ui. R)로 구성돼 있다. 사용자 작업파일(ui. R)에는 사용자의 작업 화면에 대한 설계를 하고, 서버 파일(server. R)에는 구체적 분석 작업에 대한 내용인 모델이 포함된다. 이 과정을 거쳐 해당 URL에 접속하면 R로 개발한 분석모델을 실행할 수 있어서 별도의 C나 자바 프로그램으로 일괄 처리하는 환경으로 변환 및 재개발할 필요가 없다. 단 샤이니는 싱글 코어는 무료지만, 멀티코어는 동시 접속자 기준으로 비용이 다소 발생한다.


수행 준거

분석 모형 적용에 따른 기존 업무 프로세스 영향도와 개선 기회를 분석할 수 있다. 식별된 기존 업무(비즈니스) 프로세스 영향도와 개선기회를 바탕으로, 목표 업무(비즈니스) 프로세스를 설계하고 문서화할 수 있다. 분석 모형의 운영환경 적용을 위한 다양한 기법(방법)들의 특징·장점·단점을 비교·분석할 수 있다. 비교·분석 결과를 기준으로, 분석 모형 적용 기법(방법)을 선정할 수 있다. 선정된 기법(방법)으로 분석 모형을 실제 운영환경에 적용할 수 있다.


고려사항

최종 모델링 결과를 실제 운영 정보 시스템에 적용하는 단계로, 상용 또는 오픈소스 도구의 활용 또는 자체 개발을 고려할 수 있다. 모델 적용 자동화 및 모델 갱신 자동화를 고려할 수 있으나, 전용(상용 또는 오픈소스) 도구에서 해당 기능 제공 시에만 적용하는 것이 타당하다. 또한 적용하는 것으로 결정할 경우, 적용 대상 데이터의 볼륨과 처리 속도를 고려해야 한다.
시뮬레이션은 모델 적용을 위한 프로세스와 업무 규칙이 문서화되고 이해 관계자 간 공유돼야 한다. 최적화는 최적화 솔루션의 결과를 시스템과 인터페이스가 가능하도록 데이터베이스 연동 프로그램을 개발해야 한다.


주기적 리모델링

한 번 만든 모델이 영원히 동일한 성과를 낼 수 없다. 비즈니스 상황이 변하거나 분석결과 적용에 따른 주변 요인들이 관심의 대상으로 부각되기 때문이다. 때로는 분석결과를 고객에게 적용하는 경우 고객의 행동패턴이 변화하게 된다. 이점은 부정적이기보다는 자연스러운 성과로, 이러한 변화에 시스템이 대응할 수 있어야 된다. 그래서 성과 모니터링이 지속적으로 돼야 하고, 일정수준 이상으로 편차가 지속적으로 하락하는 경우 리모델링을 주기적으로 수행해야 한다.
일반적으로 주기적 리모델링은 분기·반기·연 단위로 수행한다. 일·주 단위 리모델링은 특수 분야를 제외하고는 바람직하지 않다. 기법별로 모델링 주기를 본다면 데이터 마이닝은 평균 분기별로 수행하면 적합하고, 시뮬레이션은 주요 변경이 이뤄지는 시점과 반기 정도면 적합하다. 최적화는 1년에 한 번 정도가 적합하다. 리모델링 시 수행하는 업무는 데이터 마이닝은 동일한 데이터를 이용해 학습을 다시 하는 방법과 변수를 추가해 학습하는 방법이 있다. 시뮬레이션은 이벤트 발생 패턴의 변화, 시간 지연(Delay)의 변화, 이벤트를 처리하는 리소스 증가, Queuing Priority, Resource Allocation Rule 변화 등을 처리한다. 최적화는 Object Function의 계수 변경이나 Constraint에 사용되는 제약값의 변화와 추가가 있다.


수행 준거

분기·반기·연 단위로 정기적인 분석 모형 재평가를 실시하고, 성능 편차 발생을 분석·식별할 수 있다. 업무 IT 환경에 주요 변화 발생 시, 분석 모형 재평가를 실시하고 성능 편차 발생을 분석·식별할 수 있다. 정기·비정기 분석 모형 재평가 결과에 기반해 모형 조정·개선 작업을 수행하거나, 분석모형 전면 재구축을 위한 독립 프로젝트 계획을 수립해 추진할 수 있다.


고려사항

데이터 마이닝, 최적화 모델링 결과를 정기적(분기, 반기, 연 단위)으로 재평가해 결과에 따라 필요 시 분석 모형을 재조정 해야 한다. 데이터 마이닝은 최신 데이터 적용이나 변수 추가 방식으로 분석 모형을 재조정할 수 있다.
시뮬레이션은 업무 프로세스 KPI의 변경 또는 주요 시스템 원칙 변경, 발생 이벤트의 건수 증가에 따라 성능 평가를 하고 필요 시 재조정해야 한다. 최적화는 조건 변화나 가중치 변화 시 계수 값 조정 또는 제약 조건 추가로 재조정할 수 있다. 업무 특성에 따라 차이가 있으나, 일반적으로 초기에는 모형 재조정을 자주 수행해야 한다. 하지만 점진적으로 그 주기를 길게 설정할 수 있다. 관리 대상 모델이 월 20개 이상이거나, 기타 업무와 병행해서 수행해야 하는 경우 수작업이 아닌 도구를 통한 업무 자동화를 권고한다.