1. 분석 방법론 개요
최근 기업 경쟁력을 향상하기 위하여 데이터 분석 및 활용의 중요성이 강조되고 있다. 지금까지 기업들은 일반 수준의 품질목표나 재무성과를 달성하기 위하여 데이터 기반의 의사결정보다는 경험과 감에 의한 판단만으로도 어느 정도 목표를 달성할 수 있었다. 그러나 극한의 글로벌 경쟁 환경에서는 더 이상 경험과 감에의한 의사결정으로는 한계가 있음을 인식하고 데이터 기반의 의사결정을 위하여 많은 노력을 기울이고 있다.
고정 관념(Stereotype), 편향된 생각(Bias) 프레이밍 효과(Framing Effect:문제의 표현 방식에 따라 동일한 사건이나 상황임에도 불구하고 개인의 판안이나 선택이 달라질 수 있는 현상) 등은 기업의 합리적 의사결정을 가막는 장애 요소이다. 데이터 기반의 의사결정을 위해서는 기업 문화의 변화와 업무 프로세스의 개선이 필요하고 이를 촉진시키는 도로고써 데이터 분석을 활용할 수 있다.
데이터 분석을 효과적으로 기업내 정착하기 위해서는 이를 체계화한 절차와 방법이 정리된 데이터 분석 방법론의 수립이 필요적이다. 프로젝트는 한 개인의 역량이나 또는 조직의 우연한 성공에 기인해서는 안되고 일정한 수준의 품질을 갖춘 산출물과 프로제그의 성공 가능성을 확보하고 제시할 수 있어야 한다. 따라서 방법론은 상세한 절차(Procedures), 방법(Methods), 도구와 기법(Tools & Techniques), 템플릿과 산춘물(Templates & Outputs)로 구성되어 어느 정도의 지식만 있으면 활용이 가능해야 한다.
일반적으로 방법론의 생성 과정은 그림과 같이 개인의 암묵지가 조직의 형식지로 발전하는 형식화 과정을 거치고, 이를 체계화하여 문서화한 최적화된 형식지로 전개됨으로 방법론이 만들어질 수 있다. 이렇게 만들어진 방법론은 다시 개인에게 전파되고 활용되는 내재화 과정을 거쳐 암묵지로발전하는 선순환 화정이 진행되면서 조직 내 방법론이 완성될 수 있다.
방법론은 적용 업무의 특성에 따라 다양한 모델을 가질 수 있다. 폭포수 모델(Waterfall Model)은 단계를 순차적으로 진행하는 방법으로 이전 단계가 완료되어야 다음 단계로 진행될 수 있으며 하향식(Top Down)으로 진행되지만 문제나 개선사항이 발견되면 전 단계로 돌아가는 피드백(Feedback)과정이 수행되기도 한다.
나선형 모델(Spiral Model)은 반복을 통하여 점증적으로 개발하는 방법으로써 처음시도하는 프로젝트에 적용이 용의하지만, 반복에 대한 관리 체계를 효과적으로 갖추지 못한 경우 복잡도가 상승하여 프로젝트 진행이 어려울 수 있다. 이 이외에도프로토타입 모델(Prototype Model) 등 다양한 모델이 있다. 빅데이터 분석에서도 분석 과제의 특징과 조직의 역량에 따라 다양한 모델을 기반으로 방법론을 구축할 수 있다.
일반적으로 방법론은 계층적 프로세스 모델(Stepwised Process Model)의 형태로 구성된다. 최상위 계층은 단계(Phase)로서 프로세스 그룹(Process Group)을 통하여 완성된 단계별 산출물이 생성되어야 한다.
각 단계는 기준선(Baseline)으로 설정되어 관리되어야 하며 버전관리(Configuration Management)등을 통하여 통제가 이루어져야 한다. 각 단계는 여러개의 태스크(Task)로 구성되는데 각 태스크는 단계를 구성하는 단위 활동으로써 물리적 또는 논리적 단위로 품질검토의 항목이 될 수 있다. 마지막 계층은 스텝(Step)으로서 WBS(Work Breakdown Structure)의 위크패키지(Work Package)에 해당되고 입력자료(Input), 처리 및 도구(Process & Tool), 출력자료(Output)로 구성된 단위 프로세스(Unit Process)이다.
2. KDD 분석 방법론
KDD(Knowledge Discovery in Databases)는 1996년 Fayyad가 체계적으로 정리한 데이터 마이닝 프로세스로써 데이터베이스에서의미 있는 지식을 탐색하는 데이터 마이닝부터, 기계학습, 인공지능, 패턴인식, 데이터 시각화 등에서 응용될 수 있는 구조를 갖고 있다. KDD는 데이터에서 패턴을 찾는 과정을 다음과 같이 9개 프로세스로 제시하고 있다.
- 분석 대상 비즈니스 도메인의 이해
- 분석 대상 데이터셋 선택과 생성
- 데이터에 포함되어 있는 노이즈(Noise)와 이상값(Outlier)등을 제거하는 정제작업이나 선처리
- 분석 목적에 맞는 변수를 찾고 필요시 데이터의 차원을 축소하는 데이터 변경
- 분석 목적에 맞는 데이터 마이닝 기법 선택
- 데이터 마이닝 시행
- 데이터 마이닝 결과에 대한 해석
- 데이터 마이닝에서 발견된 지식 활용
가. 데이터셋 선택(Selection)
데이터셋 선택에 앞서 분석 대상의 비즈니스 도메인에 대한 이해와 프로젝트의 목표를 정확하게 설정한다.
데이터셋 선택은 데이터베이스 또는 원시 데이터에서 분석에 필요한 데이터를 선택하고 필요한 경우 추가적으로 데이터셋을 생성할 수 있다. 데이터셋 선택 프로세스를 통하여 데이터 마이닝에 필요한 목표 데이터(Target Data)를 구성하고 다음 단계인 데이터 전처리 프로세스를 통하여 데이터셋 추가가 요구되는 경우 이 선택 프로세스를 반복할 수 있다.
나. 데이터 전처리(Preprocessing)
데이터셋 선택 프로세스에서 추출된 분석 대상용 데이터셋에 포함되어 있는 잡음(Noise)과 이상값(Outlier), 결측치(Missing Value)를 식별하고 필요시 제거하거나 의미 있는 데이터로 처리하는 데이터셋 정제작업을 시행한다. 데이터 전처리 프로세스를 수행하는 과정에서 추가적인 데이터셋이 필요한 경우 데이터셋 선택 프로세스를 반복할 수 있다.
다. 데이터 변환(Transformation)
데이터 전처리 프로세스를 통하여 분석용 데이터셋이 편성되면 분석 목적에 맞는 변수를 선택하거나 데이터의 차원을 축소하여 데이터 마이닝을 효율적으로 적용될 수 있도록 데이터셋을 변경하는 프로세스를 수행한다.
라. 데이터 마이닝(Data Minig)
데이터 변환 프로세스를 통하여 만들어진 분석용 데이터셋을 이용하여 분석 목적에 맞는 데이터 마이닝 기법을 선택하고 데이터 마이닝 알고리즘을 선택하여 데이터의 패턴을 찾거나 데이터를 분류 또는 예측 등 아이닝 작업을 시행한다. 데이터 마이닝 프로세스를 수행하는 과정에서 필요에 따라 데이터 전처리, 데이터 변환 프로세스를 병행할 수 있다.
마. 데이터 마이닝 결과 평가(Interpretation/Evaluation)
데이터 마인ㅇ 결과에 대한 해석과 평가 그리고 분석 목적과의 일치성을 확인한다. 데이터 마이닝을 통하여 발견된 지식을 업무에 활용하기 위한 방안을 찾고필요에 따라 데이터셋 선택 프로세스부터 데이터 마이닝 프로세스를 반복하여 수행한다.
3. CRISP-DM 분석 방법론
CRISO-DM(Cross Industry Standard Process fo Data Mining)은 1996년 유럽연합의 ESPRIT에서 있었던 프로젝트에서 시작되었고 DaimlerChryrler, SPASS, NCR 등이 참여하여 1999년 첫 버전을 발표하였다.
CRISP-DM은 계층적 프로세스 모델(Hierarchical Process Model)로써 4개 레벨로 구성되어 있다.
최상위 레벨은 여러 갱의 단계(Phases)로 구성되고 각 단계는 일반화 태스크(Generic Tasks)를 포함한다.
일반화 태스크는 데이터 마이닝의 단일 프로세스를 완전하게 수행하는 단위이다. 세 번째 레벨은 세분화 태스크(Specilized Tasks)로 일반화 태스크를 구체적으로 수행하는 레벨이다. 예를 들어 데이터 정제(Data Cleaning)의 일반화 태스크는 범주형 데이터 정제, 연속형 데이터 정제 등으로 구체화된 세분화 태스크가 있다. 마지막 레빌인 프로세스 실행(Process Instances)은 데이터 마이닝을 위한 구체적인 실행을 포함한다.
CRISP-DM 프로세스는 6단계로 구성되어 있으며, 각 단계는 폭포수 모델(Waterfall Model)처럼 일방향으로 구성되어 있지 않고 단계 간 피드백(Feedback)을 통하여 단계별 완성도를 높이게 되어 있다.
가. 업무 이해(Business Understanding)
비즈니스 관점에서 프로젝트의 목적과 요구사항을 이해하기 위한 단계로써 도메인 지식을 데이터 분석을 위한 문제정의로 변경하고 초기 프로젝트 계획을 수립하는 단계이다.
- 업무 목적 파악
- 상황 파악
- 데이터 마이닝 목표 설정
- 프로젝트 계획 수립
나. 데이터 이해(Data Understanding)
데이터 이해는 분석을 위한 데이터를 수집하고데이터 속성을 이해하기 위한 과정으로 구성되고 데이터 품질에 대한 문제점을 식별하고 숨겨져 있는 인사이트를 발견하는 단계이다.
- 초기 데이터 수집
- 데이터 기술 분석
- 데이터 탐색
- 데이터 품질 확인
다. 데이터 준비(Data Preparation)
데이터 준비는 분석을 위하여 수집된 데이터에서 분석기법에 적합한 데이터셋을 편성하는 단계로써 많은 시간이 소요될 수 있다.
- 분석용 데이터셋 선택
- 데이터 정제
- 분석용 데이터셋 편성
- 데이터 통합
- 데이터 포맷팅
라. 모델링(Modeling)
다양한 모델링 기법과 알고리즘을 선택하고 모델링 과정에서 사용되는 파라미터를 최적화해 나가는 단계이다. 모델링 과정에서 데이터셋이 추가로 필요한 경우 데이터 준비 단계를 반복 수행할 수 있다. 모델링 단계를 통하여 찾아낸 모델은 테스트용 프로세스와 데이터셋으로 평가하여 모델 과적합(Overfitting) 등의 문제를 발견하고 대응 방안을 마련한다.
- 모델링 기법 선택
- 모델 테스트 계획 설계
- 모델 작성
- 모델 평가
마. 평가(Evaluation)
모델링 단계에서 얻은 모델이 프로젝트의 목적에 부합하는지를 평가한다. 이 단계의 목적은 데이터 마이닝 결과를 수용할 것인지 최종적으로 판단하는 과정이다.
- 분석결과 평가
- 모델링 과정 평가
- 모델 적용성 평가
바. 전개(Deployment)
모델링과 평가 단계를 통하여 완성된 모델은 실 업무에 적용하기 위한 계획을 수립하고 모니터링과 모델의 유지보수 계획을 마련한다. 모델은 적용되는 비즈니스 도메인 특성, 입력되는 데이터의 품질 편차, 운영 모델의 평가 기분 등에 따라 생명주기(Life Cycle)가 다양하므로 상세한 전재 계획이 필요하다. 또한 CRSIP-DM의 마지막 단계이므로 프로젝트 종료 관련 프로세스를 수행하여 프로젝트를 완료시킨다.
- 전개 계획 수립
- 모니터링과 유지보수 계획 수립
- 프로젝트 종료보고서 작성
- 프로젝트 리뷰
4. 빅데이터 분석 방법론
빅데이터를 분석하기 위한 방법론은 계층적 프로세스 모델(Stepwised Process Model)로써 3계층으로 구성된다. 최상위 계층은 단계(Phase)로서 프로세스 그룹(Process Group)을 통하여 완성된 단계별 산출물이 생성되어야 한다. 각 단계는 기준선(Baseline)으로 설정되어 관리되어야 하며 버전과리(Configuration Management)등을 통하여 통제가 이루어져야 한다. 각 단계는 여러 개의 태스크(Task)로 구성되는데 각 태스크는 단계를 구성하는 단위 활동으로써 물리적 또는 논리적 단위로 품질검토의 항목이 될 수 있다.
마지막 계층은 스텝(Step)으로서 WBS(Work Breakdown Structure)의 워크패키지(Work Package)에 해당되고 입력자료(Input), 처리 및 도구(Process & Tool), 출력자료(Output)로 구성된 단위 프로세스(Unit Process)이다.
빅데이터 분석 방법론은 비즈니스 도메인과 문제점을 인식하고 분석계획 및 프로젝트 수행계획을 수립하는 분석 기획(Planning)단계와 비즈니스 요구사항과 데이터 분석에 필요한 원천 데이터를 정의하고 준비하는 데이터 준비(Preparing)단계로 구성된다. 데이터 분석을 위한 원천 데이터가 확보되면 분석용 데이터셋으로 편성하고 다양한 분석 기법과 알고리즘을 이용한 데이터 분석(Analyzing)단계를 수행한다.
분석 단계를 수행하는 과정에서 추가적인 데이터 확보가 필요한 경우 데이터 준비단계로 피드백(Feedback)하여 두 단계를 반복하여 진행한다. 데이터 분석 단계를 진행하ㅕㄴ서 분석 기획에 맞는 모델을 도출하고이를 운영중인 가동 시스템에 적용하거나 시스템 개발을 위한 사전 검증으로 프로토타입 시스템을 구현하고자 하는 경우 시스템 구현(Developing)단계를 수행한다. 데이터 분석 및 시스템 구현 단계를 수행한 후 프로젝트의 성과를 평가하고 정리(Lesson Learned)하거나 모델의 발전 계획을 수립하여 차기 분석 기획으로 전달하는 평가 및 전개(Deploying)단계를 수행하여 빅데이터 분석 프로젝트를 종료한다.
가. 분석 기획(Planning)
분석 기획 단계는 분석하려는 비즈니스를 이해하고 도메인의 문제점을 파악하여 빅데이터 분석 프로젝트의 범위를 확정하는 단계이다. 또한 프로젝트의 정의 및 수행계획을 구체적이고 상세하게 수립하여 향후 프로젝트 진행의 기준선이 되도록 준비한다.
빅데이터 분석 프로젝트는 단순한 데이터 분석이나 아이닝이 아닌 대용량의 정형.비정형 데이터를 활요해야 하고 분석 및 운영을 위한 인프라 구축을 병행하거나 또는 기존 시스템(Legacy System)과의 많은 인터페이스를 동반하는 등 프로젝트내에 위험(Risk)요소가 많이 있으므로 분석 기획 단계에서 프로젝트의 위험을 사전에 식별하고 대응방안을 수립하는 프로세스도 진행한다.
- 비즈니스 이해 및 범위 설정
- 프로젝트 정의 및 계획 수립
- 프로젝트 위험 계획 수립
나. 데이터 준비(Preparing)
분석 기획에 근거하여 비즈니스 요구사항을 데이터 차원에서 다시 파악하고 프로젝트별로 필요로 하는 데이터를 정의하여 전사 차원의 데이터 스토어(Data Store)를 준비한다.
데이터 수집 저장은 조직 내.외부에서 정형.비정형 데이터를 수집해야 하는 복잡하고 많은 시간이 소요되므로 작업의 효율성을 위하여 필요시 ETL(Extract Transform Load)등의 다양한 도구를 사용한다. 또한 분석에 활용되기 위해서는 데이터의 품질확보가 중요하므로 품질통제와 품질보증 프로세스도 수행한다.
- 필요 데이터 정의
- 데이터 스토어 설계
- 데이터 수집 및 정합성 점검
다. 데이터 분석(Analyzing)
데이터 준비 단계에서 확보된 정형.비정형 데이터를 이용하여 분석 기획 단계에서 수립된 프로젝트 목표를 달성하기 위하여 데이터 분석 프로세스를 진행한다. 데이터 스토어(Data Store)에서 분석에 필요한 데이터셋을 준비하고 탐색전 분석, 모델링과 모델 평가 태스크를 진행한다.
비정형 텍스트 데이터가 존재할 경우 텍스트 마이닝, 텍스트 분류 등의 분석 기법과 알고리즘을 이용하여 비정형 분석을 실시하고 필요시 정형 데이터와 결합하여 통합 모델링을 수행한다. 분석용 데이터셋을 추출하는 과정에서 분석에 필요한 충분한 데이터를 확보할 수 없을 경우 데이터 준비 단계를 반봅하여 수행한다.
- 분석용 데이터 준비
- 텍스트 분석
- 탐색전 분석
- 모델링
- 모델 평가 및 검증
- 모델적용 및 운영방안 수립
라. 시스템 구현(Developing)
분석 기획의 의도에 맞는 모델을 데이터 분석 단계를 진행하여 도출하고이를 운영중인 시스템에 적용하거나 프로토타입(Prototype)을 구현하고자 하는 경우 시스템 구현 단계를 진행한다. 단순한 데이터 분석이나 데이터 마이닝을 통한 분석 보고서를 작성하는 것으로 프로젝트가 종료되는 경유에는 시스템 구현 단계를 수행할 필요가 없고 다음 단계인 평가 및 전개 단계를 수행한다.
시스템 구현 단계는 소프트위어공학(Software Engineering), 정보공학(Information Engineering), CBD(Component Based Development)등 일반적으로 사용되는 소프트웨어 개발 생명주기인 SDLC(Software Development Life Cycle)와 기업내 시스템 개발을 위하여 사용하고 있는 방법론을 커스터마이징(Customizing)하여 적용할 수도 있다.
- 설계 및 구현
- 시스템 테스트 및 운영
마. 평가 및 전개(Deploying)
평가 및 전개 단계에서는 분석 기획 단계에서 수립된 프로젝트의 목적을 달성했는지의 여부를 평가하고 데이터 분석 단계와 시스템 구현 단계에서 구축된 모델의 발전계획을 수립하는 등 빅데이터 분석 프로젝트의 종료 및 전개 프로세스로 구성된다. 또한 수행된 프로젝트를 객관적이고 정량적으로 평가하여 내부 활용 및 자산화를 추진한다.
프로젝트 수행 중에 발생된 모든 중간 산출물을 정리하고 프로젝트 종료 보고서를 작성하여 의사소통 체계에 따라 보고하고 프로젝트를 종료한다.
- 모델 발전계획 수립
- 프로젝트 평가 및 보고
____________________________________________________________________________
5. 분석 계획(Planning)
가. 비즈니스 이해 및 범위 설정
빅데이터 분석 프로젝트를 진행하기 위해서는 비즈니스에 대한 충분한 이해와 도메인에 대한 문제점을 파악한다. 비즈니스 이해와 문제점을 파악을 위해서는 업무 매뉴얼 및 업무 전문가의 도움이 필요하다. 프로젝트의 범위를 명확하게 파악하기 위해서는 구조화된 명세서를 작성한다.
1) 비즈니스 이해
빅데이터 분석 대상인 업무 도메인을 이해하기 위해서는 내부 업무 매뉴얼과 관련자료, 외부의 관련 비즈니스 자료를 조사하고 향후 프로젝트 진행을 위한 방향을 설정한다.
- 입력자료: 업무 매뉴얼, 업무전문가의 지식, 빅데이터 분석 대상 도메인에 대한 관련 자료
- 프로세스 및 도구 : 자료 수집 및 비즈니스 이해
- 출력자료 : 비즈니스 이해 및 도메인 문제점
2) 프로젝트 범위 설정
빅데이터 분석 프로젝트의 대상인 비즈니스에 대한 이해와 프로젝트 목적에 부합되는 범위(Scope)을 명확하게 설정하고 프로젝트에 참여하는 모든 관계자들(Project stakehoders)의 이해를 일치시키기 위하여 구조화된 프로젝트 범위 정의서인 SOW(Statement Of Work)를 작성한다.
- 입력자료 : 중장기 계획서, 빅데이터 분석 프로젝트 지시서, 비즈니스 이해 및 도메인 문제점
- 프로세스 및 도구 : 자료 수집 및 비즈니스 이해, 프로젝트 범위 정의서 작성 절차
- 출력자료 : 프로젝트 범위 정의(SOW)
나. 프로젝트 정의 및 계획 수립
빅데이터 분석 프로젝트 추진 목표를 명확하게 정의하고구체화하기 위하여 모델의 운영 이미지를 설계하고 모델 평가 기준을 설정함으로써 프로젝트 정의를 명확하게 한다.
프로젝트 정의가 명확하게 설정되면 이를 기준으로 프로젝트의 WBS(Work Breakdown Structure)를 만들고 데이터 확보 계획, 빅데이터 분석 방법, 일정계획, 예산계획, 품질계획, 인력구성계획, 의사소통계획 등을 포함하는 프로젝트 수행 계획을 작성한다.
1) 데이터 분석 프로젝트 정의
프로젝트의 목표 및 KPI, 목표 수준 등을 구체화하여 상세 프로젝트 정의서를 작성하고 프로젝트의 목표를 명화화 하기 위하여 모델 운영 이미지 및 평가 기준을 설정한다.
- 입력자료: 프로젝트 범위 정의서, 빅데이터 분석 프로젝트 지시서
- 프로세스 및 도구 : 프로젝트 목표 구체화, 모델 운영 이미지 설계
- 출력자료 : 프로젝트 정의서, 모델 운영 이미지 설계서, 모델 평가 기준
2) 프로젝트 수행 계획 수립
프로젝트 수행 계획서를 작성하는 단계로써 프로젝트의 목적 및 배경, 기대효과, 수행방법, 일정 및 추진조직, 프로젝트 관리방안을 작성한다. WBS는 프로젝트 산출물 위주로 작성되어 프로젝트의 범위를 명확하게 한다.
- 입력자료 : 프로젝트 정의서, 모델 운영 이미지 설계서, 모델 평가 기준
- 프로세스 및 도구 : 프로젝트 수행 계획 작성, WBS 작성 도구, 일정계획 수립 도구
- 출력자료 : 프로젝트 수행 계획서, WBS
___________________________________________________________________________
다. 프로젝트 위험계획 수립
빅데이터 분석 프로젝트는 내.외부 시스템간 다양한 인터페이스, 대량의 정형.비정형 데이터 연계, 개인정보보호 등으로데이터 획득 및 활용에 현실적으로 많은 어려움이 있다. 따라서 계획수립 단계에서 빅데이터분석 프로젝트를 진행하면서 발생 가능한 모든 위험(Risk)를 발굴하여 사전에 대응 방안을 수립함으로써 프로젝트 진행의 완전성을 높인다.
1) 데이터 분석 위험 식별
선행하여 진행된 프로젝트 산출물과 정리자료(Lesson Learned)를 참조하고 전문가의 판단을 활요하여 빅데이터 분석 프로젝트를 진행하면서 발생 가능한 위험을 식별한다. 식별된 위험은 위험의 영향도와 빈도, 발생가능성 등을 평가하여 위험의 우선순위를 설정한다.
-입력자료 : 프로젝트 정의서, 프로젝트 수행 계획서, 선행 프로젝트 산출물 및 정리자료
- 프로세스 및 도구 : 위험 식별 절차, 위험영향도 및 발생가능성 분석, 위험 우선순위 판단
- 출력자료 : 식별된 위험 목록
2) 위험 대응 계획 수립
식별된 위험은 상세한 정량적.정성적 분석을 통하여 위험 대응방안을 수립한다. 예상되는 위험에 대한 대응은 회피(Avoid), 전이(Transfer), 완화(Mitigate), 수용(Accept)로 구분하여 위험 관리 계획서를 작성한다.
- 입력자료 : 식별된 위험 목록, 프로젝트 정의서, 프로젝트 수행 계획서
- 프로세스 및 도구 : 위험 정량적 분석, 위험 정성적 분석
- 출력자료 : 위험과리 계획서
6. 데이터 준비(Preparing)
가. 필요 데이터 정의
빅데이터 분석 프로젝트 진행에 필요한 데이터를 정의하는 단계로써 전사 차원에서 필요 데이터를 정의하는 것이 중요하며 정형.비정형.반정형 등의 모든 내.외부 데이터를 포함하고 데이터의 속성, 데이터 오너, 데이터 관련 시스템 담당자 등을 포함하는 데이터 정의서를 작성한다. 데이터 정의서를 이용하여 구체적인 데이터 획등방안을 상세하게 수립함으로써 데이터 획득 과정에서 발생하는 프로젝트 지연을 방지한다.
1) 데이터 정의
시스템, 데이터베이스, 파일, 문서 등의 다양한 내.외부 원천 데이터 소스(Raw Data Source)로 부터 분석에 필요한 데이터를 정의한다.
- 입력자료 : 프로젝트 수행 계획서, 시스템 설계서, ERD, 메타데이터 정의서, 문서 자료
- 프로세스 및 도구 : 내.외부 데이터 정의, 정형.비정형.반정형 데이터 정의
- 출력자료 : 데이터 정의서
2) 데이터 획득방안 수립
내.외부의 다양한 데이터 소스로부터 정형.비정형.반정형 데이터를 수집하기 위한 구체적인 방안을 수립한다. 내부 데이터 획득에는 부서간 업무협조와 개인정보보호 및 정보보안과 관련한 문제점을 사전에 점검하고, 외부 데이터의획득은 시스템간 다양한 인터페이스 및 법적인 문제점을 고려하여 상세한 데이터 획득계획을 수립한다.
- 입력자료 : 데이터 정의서, 시스템 설계서, ERD, 메타데이터 정의서, 문서 자료, 데이터 구입
- 프로세스 및 도구 : 데이터 획득 방안 수립
- 출력자료 : 데이터 획득 계획서
나. 데이터 스토어 설계
빅데이터 분석 프로젝트의 목적을 파악하고필요한 데이터를 정의한 후 데이터 획득방안이 수립되면 데이터를 저장하기 위한 전사 차원의 데이터 스토어(Data Store)를 설계한다. 데이터 스토어는 정형.비정형.반정형 데이터를 모두 저장될 수 있도록 설계한다.
1) 정형 데이터 스토어 설계
정형 데이터는 구조화된 형식으로 데이터베이스나 파일 시스템 등 다양한 데이터 스토어 형태를 가질 수 있으나 일반적으로 관계형 데이터베이스인 RDBMS(Relational Data Base Management System)를 사용하고 데이터의 효율적인 저장과 활용을 위하여 데이터 스토어의 논리적, 물리적 설계를 구분하여 설계한다.
- 입력자료 : 데이터 정의서, 데이터 획득 계획서
- 프로세스 및 도구 : 데이터베이스 논리설계, 데이터베이스 물리설계, 데이터 매핑(Data Mapping)
- 출력자료 : 정형 데이터 스토어 설계서, 데이터 매핑 정의서
2) 비정형 데이터 스토어 설계
하둡, NoSQL등을 이용하여 비정형 또는 반정형 데이터를 저장하기 위한 논리적, 물리적 데이터 스토어를 설계한다.
- 입력자료 : 데이터 정의서, 데이터 획득 계획서
- 프로세스 및 도구 : 비정형.반정형 데이터 논리설계, 비정형.반정형 데이터 물리설계
- 출력자료 : 비정형 데이터 스토어 설계서, 데이터 매핑 정의서
다. 데이터 수집 및 정합성 점검
구축된 데이터 스토어(Data Store)에 크롤링(Crawling), 시스템간 실시간(Real Time 또는 Near Real Time)처리, 배치(Batch) 처리 등으로 데이터를 수집한다. 또한 데이터베이스간 연동, API(Application Program Interface)를 이용한 개발, ETL(Extract Transform Load) 도구의 활용 등 다양한 방법을 이용하여 데이터 수집 프로세스를 진행한다.
저장된 데이터는 데이터의 품질을 확보하기 위한 정합성 검증을 실시하고 데이터 거버넌스에 근거하여 메타 데이터(Meta Data) 및 데이터 사전(Data Dictionary) 등이 저장되고 적용되고 있는지 주기적으로 확인한다.
1) 데이터 수집 및 저장
크롤링 등의 데이터 수집을 위한 ETL 등의 다양한 도구와 API, 스트립트(Script)프로그램 등을 이용하여 데이터를 수집하고, 수집된 데이터를 설계된 데이터 스토어에 저장한다.
- 입력자료 : 데이터 정의서, 데이터 획득 계획서, 데이터 스토어 설계서
- 프로세스 및 도구 : 데이터 크롤링 도구, ETL 도구, 데이터 수집 스크립트
- 출력자료: 수집된 분석용 데이터
2) 데이터 정합성 점검
데이터 스토어의 품질 점검을 통하여 정합성을 확보하고 데이터 품질개선이 필요한 부분에 대하여 보완 작업을 한다.
- 입력자료 : 수집된 분석용 데이터
- 처리 및 도구 : 데이터 품질 확인, 데이터 정합성 점검 리스트
- 출력자료 : 데이터 정합성 점검 보고서
7. 데이터 분석(Analyzing)
가. 분석용 데이터 준비
분석에 필요한 데이터셋을 준비하기 위하여 프로젝트 목표와 도메인을 이해하고비즈니스 롤(Business Rule)을 확인한다. 전사 차원으로 구축된 데이터 스토어(Data Store)에서 분석용 데이터셋을 ETL 도구등을 이용하여 추출하고 데이터베이스나 구조된 데이터 형태로 편성한다.
1) 비즈니스 룰 확인
분석 계획 단계에서 비즈니스 이해, 도메인 문제점 인식, 프로젝트 정의 등을 이용하여 프로젝트의 목표를 정확하게 인식한다. 이러한 이해를 바탕으로 세부적인 비즈니스 룰을 파악하고 분석에 필요한 데이터의 범위를 확인한다.
- 입력자료 : 프로젝트 정의서, 프로젝트 수행 계획서, 데이터 정의서, 데이터 스토어
- 프로세스 및 도구 : 프로젝트 목표 확인, 비즈니스 룰 확인
- 출력자료 : 비즈니스 룰, 분석에 필요한 데이터 범위
2) 분석용 데이터셋 준비
데이터 스토어부터 분석에 필요한 정형.비정형 데이터를 추출한다. 필요시 적절한 가공을 통하여 분석도구 입력자료로 사용될 수 있도록 편성한다. 분석을 위하여 추출된 데이터는 데이터베이스나 구조화된 형태로 구성하고 필요시 분석을 위한 작업 공간(Play Ground, Sandbox 등)과 전사 차원의 데이터 스토어로 분리할 수도 있다.
- 입력자료 : 데이터 정의서, 데이터 스토어
- 프로세스 및 도구 : 데이터 선정, 데이터 변환, ETL 도구
- 출력자료 : 분석용 데이터셋
________________________________________________________________________________________
나. 텍스트 분석
웹 페이지 데이터, 로그 데이터, 텍스트 자료 등 비정형.반정형의 텍스트 데이터를 이용하여 어휘/구문 분석(Word Analysis), 감성 분석(Sentimental Analysis), 토픽 분석(Topic Analysis), 오피니언 분석(Opinion Analysis), 소설 네트워크 분석(Social Network Analysis) 등을 실시하여 텍스트로부터 분석 목적에 맞는 적절한 모델을 구축한다. 텍스트 분석 결과는 모델링 태스크와 연동하여 프로젝트 목적에 부합되는 최종 모델을 구축하기도 한다.
1) 텍스트 데이터 확인 및 추출
텍스트 분석에 필요한 비정형 데이터를 전사 차원의 데이터 스토어(Data Store)에서 확인하고 필요한 데이터를 추출한다.
- 입력자료 : 비정형 데이터 스토어
- 프로세스 및 도구 : 분석용 텍스트 데이터 확인, 텍스트 데이터 추출
- 출력자료 : 분석용 텍스트 데이터
2) 텍스트 데이터 분석
데이터 스토어에서 추출된 텍스트 데이터를 분석 도구로 적재하여 다양한 기법으로 분석하고 모델을 구축한다. 텍스트 분석을 위해서는 용어 사전(용어 유의어 사전, 불용어 사전 등)을 사전에 확보하거나 업무 도메인에 맞도록 작성해야 한다. 구축된 모델은 텍스트 시각화 도구를 이용하여 모델의 의미 전달을 명확하게 한다.
- 입력자료 : 분석용 텍스트 데이터, 용어사전(용어 유의어 사전, 불용어 사전 등)
- 프로세스 및 도구 : 분류체계 설계, 형태소 분석, 키워드 도출, 토픽 분석, 감성 분석, 오피니언 분석, 네트워크 분석
- 출력자료 : 텍스트 분석 보고서
__________________________________________________________
다. 탐색전 분석
분석용 데이터셋에 대한 정합성 검토, 데이터 요약, 데이터 특성을 파악하고 모델링에 필요한 데이터를 편성한다. 탐색전 데이터 분석인 EDA(Exploratory Data Ananlysis)는 다양한 데이터 시각화(Data Visualization)를 활용하여 데이터의 가독성을 명확히 하고 데이터의 형상 및 분포 등 데이터 특성을 파악하는 태스크이다.
1) 탐색전 데이터 분석
다양한 관점 별로 기초 통계량(평균, 분산, 표준편차, 최대값, 최소값 등)을 산출하고데이터의 분포와 변수간의 관계 등 데이터 자체의 특성(중심성, 분포성, 산포성) 및 데이터의 통계적 특성을 이해하고모델링을 위한 기초 자료로 활용한다.
- 입력자료 : 분석용 데이터셋
- 프로세스 및 도구 : EDA 도구, 통계 분석, 변수간 연관성 분석, 데이터 분포 확인
- 출력자료 : 데이터 탐색 보고서
2) 데이터 시각화
데이터 시각화는 탐색전 데이터 분석을 위한 도구로 활용된다. 그러나 모델의 시스템화를 위한 시각화를 목적으로 활용할 경우 시각화 설계, 시각화 구현 등의 별도의 피로세스를 따라 진행되어야 한다.
탐색전 데이터 부석을 진행하면 수행된 데이터 시각화는 모델링 또는 향후 시스템 구현을 위한 사용자 인터페이스 또는 프로토타입(Prototype)으로 활용될 수도 있다.
- 입력자료 : 분석용 데이터셋
- 프로세스 및 도구 : 시각화 도구 및 패키지, 인포그래픽, 시각화 방법론
- 출력자료 : 데이터 시각화 보고서
______________________________________________________________
라. 모델링
모델링이란 분석용 데이터를 이용한 가설 설정을 통하여 통계 모델을 만들거나 기계학습(Machine Learning)을 이용한 데이터의 분류, 예측, 군집 등의 기능을 수행하는 모델을 만드는 과정이다. 기계(Supervised Learning)과 비지도학습(Unsupervised Learning)등으로 나뉘어 다양한 알고리즘을 적용할 수 있다. 모델링을 효과적으로 진행하기 위해서는 모델링 전에 데이터셋을 훈련용(Training)과 테스트용(Testing)으로 분할함으로써 모델의 과적합(Overfitting)을 방지하거나 모델의 일반화(Generalization)에 이용된다.
1) 데이터 분할
모델의 과적합과 일반화를 위하여 분석용 데이터셋을 모델 개발을 위한 훈련용 데이터와 모델의검증력을 테스트하기 위한 데이터로 분할한다. 모델에 적용하는 기법에 따라 교차검증(Cross Validation)을 수행하거나 앙상블(Essemble) 깁법을 적용할 경우 데이터 분할 또는 검증 횟수, 생성모델 갯수 등을 설정하여 데이터 분할 기법을 응용한다.
- 입력자료 : 분석용 데이터셋
- 처리 및 도구 : 데이터 분할 패키지
- 출력자료 : 훈련용 데이터, 테스트용 데이터
2) 데이터 모델링
기계학습 등을 이용한 데이터 모델링은 훈련용 데이터를 활용하여 분류(Classification), 예측(Prediction), 군집(Clustering) 등의 모델을 만들어 가동중인 운영 시스템에 적용한다. 또한 필요시 비정형 데이터 분석결과를 통합적으로 활용하여 프로젝트 목적에 맞는 통합 모델링을 수행한다.
- 입력자료 : 분석용 데이터셋
- 처리 및 도구 : 통계 모델링 기법, 기계학습, 모델 테스트
- 출력자료 : 모델링 결과 보고서
3) 모델 적용 및 운영 방안
모델을 가동중인 운영시스테에 적용하기 위해서는 모델에 대한 상세한 알고리즘 설명서 작성이 필요하다. 알고리즘 설명서는 시스템 구현 단계에서 중요한 입력 자료로 활용되므로 필요시 의사코드(Pseudocode)수준의 상세한 작성이 필요할 수도 있다. 또한 모델의 안정적 운영으 ㄹ모니터링하는 방안도 수립한다.
- 입력자료 : 모델링 결과 보고서
- 처리 및 도구 : 통계 모델링 기법, 기계학습, 모델 테스트
- 출력자료 : 모델링 결과 보고서
마. 모델 평가 및 검증
데이터 분석 목적 및 데이터셋 특성에 따라 모델 평가 방법은 다양한다. 분석 기획 단계에서 작성된 프로젝트 정의서의 평가 기준에 따라 모델의완성도를 평가한다.
모델 검증은 분석용 데이터셋이 아닌 별도의 데이터셋으로 모델의 객관성과 실무 적용성을 검증해야 한다.
검증 스템에서 요구되는 성능 목표에 미달하는 경우 모델링 태스크를 반복하는 등 모델 튜닝 작업을 수행한다.
1) 모델 평가
프로젝트 정의서의 모델 평가 기준에 따라 모델을 객관적으로 평가하고 품질관리 차원에서 모델 평가 프로세스를 진행한다. 모델 평가를위해서는 모델 결과 보고서 내의 알고리즘을 파악하고 테스트용 데이터나 필요시 모델 검증을 위한 별도의 데이터를 활용할 수도 있다.
- 입력자료 : 모델링 결과 보고서, 평가용 데이터
- 프로세스 및 도구 : 모델 평가, 모델 품질관리, 모델 개선작업
- 출력자료 : 모델 평가 보고서
2) 모델 검증
모델의 실 적용성을 검증하기 위하여 검증요 데이터를 이용해 모델 검증 작업을 실시하고 모델링 검증 보고서를 작성한다. 검증용 데이터는 모델 개발 및 평가에 활용된 훈련용 데이터나 테스트용 데이터가 아닌 실 운영용 데이터를 확보하여 모델의 품질을 최종 검증하는 프로세스이다.
- 입력자료 : 모델링 결과 보고서, 모델 평가 보고서, 검증용 데이터
- 프로세스 및 도구 : 모델 검증
- 출력자료 : 모델 검증 보고서
8. 시스템 구현(Developing)
가. 설계 및 구현
모델링 결과를 시스템으로 구현하기 위해서는 모델링 태스크에서 작성된 알고리즘 설명서와 데이터 시각화보고서를 이용하여 시스템 및 데이터 아키텍쳐 설계, 사용자 인터페이스 설계를 진행한다. 가동 중인 시스템에 적용하기 위해서는 운영 시스템에 대한 분석도 수행한다.
시스템 설계서를 바탕으로 BI(Business Intelligence)패키지를 활용하거나 새롭게 프로그램 코딩을 통하여 시스템을 구축한다.
1) 시스템 분석 및 설계
가동중인 시스템을 분석하고알고리즘 설명서에 근거하여 응용시스템(Applicatioin)구축 설계 프로세스를 진행한다. 시스템 분석과설계는 사용중인 정보시스템 개발방법론을 커스터마이징하여 적용할 수 있다.
- 입력자료 : 알고리즘 설명서, 운영중인 시스템 설계서
- 프로세스 및 도구 : 정보시스템 개발방법론
- 출력자료 : 시스템 분석 및 설계서
2) 시스템 구현
시스템 분석 및 설계서에 따라 BI 패키지를 활용하거나 새롭게 시스템을 구축하거나 가동중인 운영시스템의 커스터마이징(Customizing) 등을 통하여 설계된 모델을 구현한다.
- 입력자료 : 시스템 분석 및 설계서, 알고리즘 설명서
- 프로세스 및 도구 : 시스템 통합개발도구(IDE), 프로그램 언어, 패키지
- 출력자료 : 구현 시스템
나. 시스템 테스트 및 운영
시스템에 구현된 모델은 테스트를 통하여 가동중인 시스템에 적용하고 효울적인 운영을 위한 프로세스를 진행한다.
1) 시스템 테스트
구축된 시스템의 검증(Verification & Validation)을 위하여 단위 테스트, 통합테스트, 시스템 테스트 등을 실시한다. 시스템 테스트는 품질관리 차원에서 진행함으로써 적용된 시스템의 객관성과 완전성을 확보한다.
- 입력자료 : 구현 시스템, 시스템 테스트 계획서
- 프로세스 및 도구 : 품질관리 활용
- 출력자료 : 시스템 테스트 결과보고서
2) 시스템 운영 계획
구현된 시스템을 지속적으로활용하기 위하여 시스템 운영자, 사용자를 대상으로 필요한 교육을 실시하고 시스템 운영계획을 수립한다.
- 입력자료 : 시스템 분석 및 설계서, 구현 시스템
- 처리 및 도구 : 운영계획 수립, 운영자 및 사용자 교육
- 출력자료 : 운영자 매뉴얼, 사용자 매뉴얼, 시스템 운영 계획서
9. 평가 및 전개(Deploying)
가. 모델 발전 계획 수립
업무 특성 및 운영 데이터의 품질에 따라 모델 성능은 많은 영향을 받게되고 이를 개선하는 노력이 주기적으로진행되어야 한다. 모델의 생명 주기(Life Cycle)를 설정하고 주기적인 평가를 실시하여 모델을 유지보수 하거나 재구축하기 위한 방안을 마련한다. 모델의 이러한 특성을 고려하여 모델 업데이트를 자동화하는 방안을 수립하여 적용할 수도 있다.
1) 모델 발전 계획
개발된 모델의 지속적인 운영과 기능 향상을 위한 발전계획을 상세하게 수립하여 모델의 계속성을 확보해야 한다.
- 입력자료 : 구현 시스템, 프로젝트 산추물
- 프로세스 및 도구 : 모델 발전 계획 수립
- 출력자료 : 모델 바리전 계획서
나. 프로젝트 평가 및 보고
분석 기획 단계에서 설정된 기준에 따라 프로젝트의 성과를 정량적, 정성적으로 평가하고 프로젝트 진행고정에서 산출된 지식, 프로세스, 출력자료를 지식자산화하고 프로젝트 최종 보고서를 작성한 후 의사소통계획에 따라 보고함으로써 프로젝트를 종료한다.
1) 프로젝트 성과 평가
프로젝트의 정량적 성과와 정성적 성과로 나누어 성과 평가서를 작성한다.
- 입력자료 : 프로젝트 산출물, 품질관리 산출물, 프로젝트 정의서, 프로젝트 수행 계획서
- 프로세스 및 도구 : 프로젝트 평가 기준, 프로젝트 정량적 평가, 프로젝트 정성적 평가
- 출력자료 : 프로젝트 성과 평가서
2) 프로젝트 종료
프로젝트 진행과정의 모든 산출물 및 프롷세스를 지식자산화 하고 최종 보고서를 작성하여 의사소통 절차에 따라 보고하고 프로젝트를 종료한다.
- 입렺자료 : 프로젝트 산출물, 품질관리 산출물, 프로젝트 정의서, 프로젝트 수행 계획서, 프로젝트성과 평가서
- 프로세스 및 도구 : 프로젝트 지식자산화 작업, 프로젝트 종료
- 출력자료 : 프로젝트 최종 보고서
2018년 1월 1일 월요일
2017년 12월 30일 토요일
제1절 분석 기획 방향성 도출
분석 기획이란 실제 분석을 수행하기에 앞서 분석을 수행할 과제의 정의 및 의도했던 결과를 도출할 수 있도록 이를 적절하게 관리할 수 있는 방안을 사전에 계획하는 일련의 작업
1. 분석 기획의 특징
데이터 분석, 특히 빅데이터에 대한 분석을 수행하는데 있어서 주의할 사항
데이터를 다루는 영역의 특성 때문에, it 기술 및 분석 기법에 치우치는 경향
분석은 분석의 대상(what) 및 분석의 방법(How)에 따라서 그림과 같이 4가지로 나누어진다.
분석의 대상이 무언인지를 인지하고 있는 경우(Known), 즉 해결해야 할 문제를 알고 있고 이미 분석의 방법도 알고 있는 경우 1) 개선을 통한 최적화(Optimization)의 형태로 분석이 수행
방법을 모르는 경우에는 해당 분석 주제에 대한 2) 솔루션(Solution)을 찾아내는 방식으로 수행
분석의 대상이 명확하게 무엇인지 모르는 경우(Un-known)에는, 기존 분석 방식을 활용하여 새로운 지식인 3) 통찰(Insight)을 도출해냄으로써 문제의 도출 및 해결에 기여
4) 발견(Discovery) 접근법으로 분석의 대상 자체를 새롭게 도출
특정한 분석 주제를 대상으로 진행할 경우에도, 분석 주제 및 기법의 특성상 이러한 4가지의 유형을 넘나들면서 분서글 수행하고 결과를 도축하는 과정을 반복하게 된다. 문제및 방법을 인지하고 있는 "개선을 통한 최적화" 유형의 분석 주제로 만제를 잡근했지만, 새로운 유형의 주제를 "발견"하거나, 새로운 "솔루션"을 도출하게 되는 경우가 자주 발생한다.
또한, 목표 시점 별로는 당면한 과제를 빠르게 해결하는 "과제 중심적인 접근 방식" 과 지속적인 분석 내재화를 위한 "장기적인 마스터 플랜 방식"으로 나누어 볼 수 있다. 과제 단위로는 진행되는 프로젝트는 문제에 대한 명확한 해결을 위해서 Quick-Win 방식의 데이터 분석을 수행하는 것이 특징이다. 개별 과제의 경우에는 이러한 Quick-Win 방식으로 과제를 수행해도 무방하지만 지속적으로 데이터 붆석 문화를 내재화하기 위해서는 전사적이고 장기적인 관점에서 분석 과제를 도출하고 해당 과제를 수행하는 것이 바람직하다.
문제 해결(Problem Solving)을 위한 단기적인 접근방시과 분석과제정의(Problem Definition)를 위한 중장기적인 마스터플랜 접근 방식은 융향적으로 적용하는 것이 분석기획에서는 중요하다. 마스터픞랜을 수립하고 장기적인 관점에서 접근하는 것이 가장 바람직하지만, 분석의 가치를 증명하고 이해관계자들의 동읟를 구하기 위해서는 분석을 통해서 해결할 수 있는 해묵은 과제를 빠르게 해결해서 분석의 가치를 조기체험함으로써 공감대를 확산시키는 방식도 유용하다.
의미있는 분석을 하기 위해서는 분석 기술, IT 및 프로그래밍, 분석 주제에 대한 도메인 전문성, 의사소통이 중요하고분석 대상 및 방식에 따른 다양한 분석 주제를 과제 단위 혹은 마스터 플랜 단위로 도출할 수 있어야 한다. 분석가는 3가지의 기본 역량에 더하여 프로젝트 관리(Project Management)역량, 리더쉽(Leadership) 역량 등이 필요
2. 분석 기획 시 고려사항
1) 가용한 데이터
2) 적절한 유스케이스
3) 분석과제 수행
첫째, 분석의 기본이 되는 데이터에 대한 고려가 필요, 분석을 위한 데이터의 확보가 우선 필요적이며 데이터가 존재하는 경우에도 데이터의 유형에 따라서 적용 가능한 솔루션 및 분석 방법이 다르기 때문에 유형에 대한 분석이 선행적으로 이루어져야 한다.
둘째, 분석을 통해서 가치가 창출될 수 있는 적절한 활용 방안과 활용 가능한 유스케이스 타색이 필요.
"바뀌를 재 발명하지 마라"는 결언처럼 기존에 잘 구현되어서 활용되고 있는 유사 분석 시나리오 및 솔루션이 있다면 이를 최대한 활용하는 것이 중요하다. 이러한 시나리오를 토대로 소통할 때 분석 결과를 활용할 사용자의 측면에서 공감대를 얻고 원활한 분석 수행에 도움이 될 것이다.
끝으로 분석을 수행암에 있어서 발생하는 장애요소들에 대한 사전 계획 수립이 필요하다. 정확도를 올리기 위해서는 기간과 투입 리소스가 늘어나게 되는데 이것은 비용 상승으로 이어질 수 있으므로 많은 고려가 필요하다. 좋은 분석 결과를 도출하여도 분석가만 이해할 수 있는 형태의 결과가 아닌 사용자가 쉽게 이해하고 활용할 수 있도록 방안을 수립해야 한다. 그리고 부석 수행 시에는 문제 없이 실행되던 분석 결과가 실제 환경에서는 성능에 문제가 발생할 수 있으므로 이러한 부분에 대해서도 고려가 필요하다. 또한 이회성 분석으로 그치지 않고 조직의 역량으로 내재화하기위해서는 충분하고 계속적인 교육 및 활용방안 등의 변화 관리(Change Management)가 고려되어야 한다.
2017년 12월 28일 목요일
8 옵셔널
- 옵셔널 타입
nil이 될 수도 있는 인스턴스는 반드시 옵셔널 타입으로 선언
옵셔널 타입으로 선언되지 않은 인스턴스는 nil이 되지 못한다.
- 옵셔널 바인딩
어떤 옵셔널에 값이 있는지 판단할 수 있는 유용한 패턴
if let temporaryConstant = anOptional{
// temporaryConstant로 어떤 일을 한다
} else {
// anOptional에는 값이 없다. 즉, anOptional은 nil이다.
}
import Cocoa
var errorCodeString: String?
errorCodeString = "404"
if let theError = errorCodeString {
print(theError)
}
- 암묵적으로 언래핑된 옵셔널(implicitly unwrapped)
import Cocoa
var errorCodeStrig: String!
errorCodeString = "404"
print(errorCodeString)
여기서 옵셔널은 암묵적 언래핑을 나타내는 !가 붙어 선언되었다. 그리고 암묵적으로언래핑핀 오셔널을 사용한다는 것은 옵셔널을 명시적으로 언래핑하여 사용하는 것보다 훨씬 더 강한 확신, 즉 값이 있다는 확신의 방증이므로 조건문도 과감하게 없앴다.
- 옵셔널 체이닝(optional chaining)
옵셔널 바인딩처럼 어떤 옵셔널에 값이 있는지 판단
import Cocoa
var errorCodeString : String?
errorCodeString = "404"
var errorDescription: String?
if let theError = errorCodeString, let errorCodeInteger = Int(theError), errorCodeInteger == 404 {
errorDescription = "\(errorCodeInteger + 290): resource was not found."
}
var upCaseErrorDescription = errorDescription?.uppercased()
errorDescription
- 옵셔널을 준비된 상태로 수정하기
새 변수나 상수를 만들지 않아도 되도록 옵셔널을 준비된 상태(in place)로 수정할 수도 있다. 다음처럼 upCaseErrorDescription에 append(_:) 메소드를 호출한다.
...
upCaseErrorDescription?.append( "PLEASE TRY AGAIN.")
upCaseErrorDescription
옵셔널에 값이 있을 때는 텍스트를 추가만 하면되고, 값이 없다면 할 일도 없는 것이다.
- nil 결합 연산자
옵셔널을 처리할 때는 (옵셔널에 값이 있을 때) 값을 가져오거나 옵셔널이 nil일때 기본값을 사용하는 것이 일반적이다. 이를테면 errorDescription에 담긴 오류 정보를 가져올 때 문자열에 오류가 없다면 "No error"라는 기본값을 사용할 수 있다. 이때 필요한 것이 옵셔널 바인딩이다.
let description : String
if let errorEscription = errorDescription{
description = errorDescription
} else {
description = "No error"
}
nil 결합 연산자 사용하기
let description = errorDescription ?? "No error"
??의 왼쪽에는 옵셔널이 와야한다.왼쪽 옵셔널이 nil이면 ??는 오른쪽 값을 리턴한다. 왼쪽 옵셔널이 nil이 아니면 옵셔널에 포함된 값이 리턴된다.
nil이 될 수도 있는 인스턴스는 반드시 옵셔널 타입으로 선언
옵셔널 타입으로 선언되지 않은 인스턴스는 nil이 되지 못한다.
- 옵셔널 바인딩
어떤 옵셔널에 값이 있는지 판단할 수 있는 유용한 패턴
if let temporaryConstant = anOptional{
// temporaryConstant로 어떤 일을 한다
} else {
// anOptional에는 값이 없다. 즉, anOptional은 nil이다.
}
import Cocoa
var errorCodeString: String?
errorCodeString = "404"
if let theError = errorCodeString {
print(theError)
}
- 암묵적으로 언래핑된 옵셔널(implicitly unwrapped)
import Cocoa
var errorCodeStrig: String!
errorCodeString = "404"
print(errorCodeString)
여기서 옵셔널은 암묵적 언래핑을 나타내는 !가 붙어 선언되었다. 그리고 암묵적으로언래핑핀 오셔널을 사용한다는 것은 옵셔널을 명시적으로 언래핑하여 사용하는 것보다 훨씬 더 강한 확신, 즉 값이 있다는 확신의 방증이므로 조건문도 과감하게 없앴다.
- 옵셔널 체이닝(optional chaining)
옵셔널 바인딩처럼 어떤 옵셔널에 값이 있는지 판단
import Cocoa
var errorCodeString : String?
errorCodeString = "404"
var errorDescription: String?
if let theError = errorCodeString, let errorCodeInteger = Int(theError), errorCodeInteger == 404 {
errorDescription = "\(errorCodeInteger + 290): resource was not found."
}
var upCaseErrorDescription = errorDescription?.uppercased()
errorDescription
- 옵셔널을 준비된 상태로 수정하기
새 변수나 상수를 만들지 않아도 되도록 옵셔널을 준비된 상태(in place)로 수정할 수도 있다. 다음처럼 upCaseErrorDescription에 append(_:) 메소드를 호출한다.
...
upCaseErrorDescription?.append( "PLEASE TRY AGAIN.")
upCaseErrorDescription
옵셔널에 값이 있을 때는 텍스트를 추가만 하면되고, 값이 없다면 할 일도 없는 것이다.
- nil 결합 연산자
옵셔널을 처리할 때는 (옵셔널에 값이 있을 때) 값을 가져오거나 옵셔널이 nil일때 기본값을 사용하는 것이 일반적이다. 이를테면 errorDescription에 담긴 오류 정보를 가져올 때 문자열에 오류가 없다면 "No error"라는 기본값을 사용할 수 있다. 이때 필요한 것이 옵셔널 바인딩이다.
let description : String
if let errorEscription = errorDescription{
description = errorDescription
} else {
description = "No error"
}
nil 결합 연산자 사용하기
let description = errorDescription ?? "No error"
??의 왼쪽에는 옵셔널이 와야한다.왼쪽 옵셔널이 nil이면 ??는 오른쪽 값을 리턴한다. 왼쪽 옵셔널이 nil이 아니면 옵셔널에 포함된 값이 리턴된다.
2017년 12월 26일 화요일
6. 루프
- for-in 루프
import Cocoa
var myFirstInt : Int =0
for i in 1...5 {
myFirstInt += 1
myFirstInt
print(myFirstInt)
}
루프를 작성하겠다고 알리는 키워드가 for다. 그 뒤로 이터레이터 i가 선언되었는데, 루프의 현재 반복 횟수를 나타내는 이터레이터(iterator)는 루프 안에서 일정한 값을 보이며, 루프 안에서만 존재한다.
- where
for i in 1...100 where i % 3 == 0 {
print(i)
}
타입 추론
for i in 1...5 {
myFirstInt += 1
print("myFirstInt equals \(myFirstInt) at iteration \(i)")
}
- while 루프
var i = 1
whle i < 6 {
myFirstInt += 1
print(myFirstInt)
i += 1
}
- repeat-while 루프
repeat-while 루프는 루프를 적어도 한 번 실행하고 조건을 판단한다.
repeat{
print("Fire blasters!")
} while shields > 0
제어권 전달문, 다시 보기
continue 사용하기
....
var shields = 5
var blastersOverheating = false
var blasterFireCount = 0
var spaceDemonsDestroyed = 0
while shields > 0 {
if spaceDemonsDestoyed == 500 {
print("You beat the game!")
break
}
if blastersOverheating {
print("Blasters are overheated! Cooldown initiated.")
sleeep(5)
print("Blasters ready to fire")
sleep(1)
blastersOVerheating = false
blasterFireCount = 0
}
if blasterFireCount > 100 {
blastersOverheating = true
continue
}
print("Fire blasters!")
blasterFireCount += 1
spaceDemonsDestroyed += 1
}
import Cocoa
var myFirstInt : Int =0
for i in 1...5 {
myFirstInt += 1
myFirstInt
print(myFirstInt)
}
루프를 작성하겠다고 알리는 키워드가 for다. 그 뒤로 이터레이터 i가 선언되었는데, 루프의 현재 반복 횟수를 나타내는 이터레이터(iterator)는 루프 안에서 일정한 값을 보이며, 루프 안에서만 존재한다.
- where
for i in 1...100 where i % 3 == 0 {
print(i)
}
타입 추론
for i in 1...5 {
myFirstInt += 1
print("myFirstInt equals \(myFirstInt) at iteration \(i)")
}
- while 루프
var i = 1
whle i < 6 {
myFirstInt += 1
print(myFirstInt)
i += 1
}
- repeat-while 루프
repeat-while 루프는 루프를 적어도 한 번 실행하고 조건을 판단한다.
repeat{
print("Fire blasters!")
} while shields > 0
제어권 전달문, 다시 보기
continue 사용하기
....
var shields = 5
var blastersOverheating = false
var blasterFireCount = 0
var spaceDemonsDestroyed = 0
while shields > 0 {
if spaceDemonsDestoyed == 500 {
print("You beat the game!")
break
}
if blastersOverheating {
print("Blasters are overheated! Cooldown initiated.")
sleeep(5)
print("Blasters ready to fire")
sleep(1)
blastersOVerheating = false
blasterFireCount = 0
}
if blasterFireCount > 100 {
blastersOverheating = true
continue
}
print("Fire blasters!")
blasterFireCount += 1
spaceDemonsDestroyed += 1
}
2017년 12월 25일 월요일
5. switch
import Cocoa
var statusCode: Int = 404
var errorString: String = "The request failed:"
switch statusCode {
case 400, 401, 403, 404:
errorString = "There was something wrong with the request."
fallthrough
default:
errorString += " Please review the request and try again."
}
fallthrough라는 제어권 전달문(control transfer statement)
어떤 방향으로 진행되던 실행 흐름을 바꿀 수 있다.
fallthrough 는 현재 case 가 가지고 있는 제어권을 바로 아래 case로 '전달하라'고 switch에 알린다.
다시 말해 statusCode와 일치하는 case에 fallthrough제어권 전달문이 있으면(일반적으로 case 맨 아래 fallthrough를 둠)우선 이 case 코드가 실행되고, 제어권이 현재 case를 '통과하여' 바로 아래 case로 넘어간다. 이 바로 아래 case 는 대조할 값과 일치하든 일치하지 않든 해당 코드가 ㅁ조건 실행된다.
- 구간
valueX...valueY : 대조할 값을 어떤 구간으로 설정
...라는 구간 대조(range matching)
- 값 바인딩
where
튜플과 패턴 대조
statusCode와 errorString은 논리적 연관성을 가지고 있다.
논리적 연관성을 드러낼 수 있도록 한 군데에 저장할 수 있다면 여러모로 유용할 것이다. 튜플(tuple)을 사용하는 이유가 이 때문이다.
튜플은 논리적 연관성이 있는 둘 이상의 값을 한데 묶은 일종의 유한 집합이다. 논리적 연관성의 유무를 판단하는 일은 물론 프로그래머의 몫이다. 튜플을 사용하면 서로 다른 값들이 하나의 복합 값으로 묶이는데, 묶어 놓은 결과는 순서 리스트의 구조를 보인다.
import Cocoa
var satusCode : Int = 418
var errorString: String = "The request failed with the error:"
switch statusCode {
case 100, 101:
errorString += " Informational, \(statusCode)."
case 204;
errorString += " Successful but no content, 204."
case 300...307:
errorString += " Redirection , \(statusCode)."
case 400...417:
errorString += " Client error, \(statusCode)."
case 500...505:
errorString += " Server error, \(statusCode)."
case let unknownCode where (unknownCode >= 200 && unkonCode < 300)
|| unKnownCode > 505:
errorString = "\(unkownCode) is not known error code."
default:
errorString = "Unexpected error encountered."
}
let error = (statusCode, errorString)
튜플요소에 이름 지정하기
let error = (code: statusCode, error: errorString)
error.code
error.error
이렇게 하면 튜플 요소에 그 이름으로, 즉 statusCode는 code로 errorString은 error로 액세스할 수 있다. 오른쪽 사이드바에도 이전과 같은 결과가 출력될 것이다.
튜플을 사용하는 패턴 대조
....
let error = (code: statusCode, eorr: errorString)
error.code
error.error
let firstErrorCode = 404
let secondErrorCode = 200
let erorCodes = (firstErrorCode, secondErrorCode)
switch errorCodes{
case (404, 404):
print("No items found.")
case (404, _):
print("First item not found.")
case (_, 404):
print("Second item not found.")
default:
print("All items found.")
}
- switch vs. if/else
.... let age = 25
if case 18...35 = age {
print("Cool demographic")
}
여러 조건이 담긴 if-case
...
let age = 25
if case 18...35 = age, age >=21 {
print("In cool demographic and of drinking age")
}
var statusCode: Int = 404
var errorString: String = "The request failed:"
switch statusCode {
case 400, 401, 403, 404:
errorString = "There was something wrong with the request."
fallthrough
default:
errorString += " Please review the request and try again."
}
fallthrough라는 제어권 전달문(control transfer statement)
어떤 방향으로 진행되던 실행 흐름을 바꿀 수 있다.
fallthrough 는 현재 case 가 가지고 있는 제어권을 바로 아래 case로 '전달하라'고 switch에 알린다.
다시 말해 statusCode와 일치하는 case에 fallthrough제어권 전달문이 있으면(일반적으로 case 맨 아래 fallthrough를 둠)우선 이 case 코드가 실행되고, 제어권이 현재 case를 '통과하여' 바로 아래 case로 넘어간다. 이 바로 아래 case 는 대조할 값과 일치하든 일치하지 않든 해당 코드가 ㅁ조건 실행된다.
- 구간
valueX...valueY : 대조할 값을 어떤 구간으로 설정
...라는 구간 대조(range matching)
- 값 바인딩
where
튜플과 패턴 대조
statusCode와 errorString은 논리적 연관성을 가지고 있다.
논리적 연관성을 드러낼 수 있도록 한 군데에 저장할 수 있다면 여러모로 유용할 것이다. 튜플(tuple)을 사용하는 이유가 이 때문이다.
튜플은 논리적 연관성이 있는 둘 이상의 값을 한데 묶은 일종의 유한 집합이다. 논리적 연관성의 유무를 판단하는 일은 물론 프로그래머의 몫이다. 튜플을 사용하면 서로 다른 값들이 하나의 복합 값으로 묶이는데, 묶어 놓은 결과는 순서 리스트의 구조를 보인다.
import Cocoa
var satusCode : Int = 418
var errorString: String = "The request failed with the error:"
switch statusCode {
case 100, 101:
errorString += " Informational, \(statusCode)."
case 204;
errorString += " Successful but no content, 204."
case 300...307:
errorString += " Redirection , \(statusCode)."
case 400...417:
errorString += " Client error, \(statusCode)."
case 500...505:
errorString += " Server error, \(statusCode)."
case let unknownCode where (unknownCode >= 200 && unkonCode < 300)
|| unKnownCode > 505:
errorString = "\(unkownCode) is not known error code."
default:
errorString = "Unexpected error encountered."
}
let error = (statusCode, errorString)
튜플요소에 이름 지정하기
let error = (code: statusCode, error: errorString)
error.code
error.error
이렇게 하면 튜플 요소에 그 이름으로, 즉 statusCode는 code로 errorString은 error로 액세스할 수 있다. 오른쪽 사이드바에도 이전과 같은 결과가 출력될 것이다.
튜플을 사용하는 패턴 대조
....
let error = (code: statusCode, eorr: errorString)
error.code
error.error
let firstErrorCode = 404
let secondErrorCode = 200
let erorCodes = (firstErrorCode, secondErrorCode)
switch errorCodes{
case (404, 404):
print("No items found.")
case (404, _):
print("First item not found.")
case (_, 404):
print("Second item not found.")
default:
print("All items found.")
}
- switch vs. if/else
.... let age = 25
if case 18...35 = age {
print("Cool demographic")
}
여러 조건이 담긴 if-case
...
let age = 25
if case 18...35 = age, age >=21 {
print("In cool demographic and of drinking age")
}
인공지능 레벨4
레벨1: 단순한 제어 프로그램을 '인공지능'이라고 칭하고 있다.
마케팅적으로 '인공지능'즉 'AI'라고 지칭하는 것이며, 지극히 단순한 제어 프로그램을 탑재하고 있는 전자 제품을 '인공지능 탑재' 등이라고 부르는 경우
레벨2: 고전적인 인공지능:
행동의 패턴이 지극히 다채로운 경우에서의 지능을 말한다. 장기 프로그램이나 청소 로봇 혹은 질문에 대답하는 인공지능 등이 이에 해당된다.
레벨3: 기계학습을 받아들인 인공지능:
검색 엔진에 내장되어 있거나 빅데이터를 바탕으로 자동적으로 판단하는 인공지능이다.
추론의 구조나 지식 베이스가 데이터를 바탕으로 학습하는 것으로 전형적으로 기계학습의 알로리즘이 이용되는 경우가 많다. 기계학습이라는 것은 표본이 되는데이터를 바탕으로 규칙이나 지식을 스스로 학습하는 것이다. 이 기술은 패턴 인식이라는 과거부터의 연구를 기초로 1990년대부터 진행되어 2000년대에 들어와 빅데이터 시대를 맞이하면서 더욱 진화하고 있다.
레벨4: 딥러닝을 받아들인 인공지능
기계학습을 할 때의 데이터를 나타내기 위해서 사용되는 입력값input(특징feature 이라고 불린다) 자체를 학습하는 것이 이
마케팅적으로 '인공지능'즉 'AI'라고 지칭하는 것이며, 지극히 단순한 제어 프로그램을 탑재하고 있는 전자 제품을 '인공지능 탑재' 등이라고 부르는 경우
레벨2: 고전적인 인공지능:
행동의 패턴이 지극히 다채로운 경우에서의 지능을 말한다. 장기 프로그램이나 청소 로봇 혹은 질문에 대답하는 인공지능 등이 이에 해당된다.
레벨3: 기계학습을 받아들인 인공지능:
검색 엔진에 내장되어 있거나 빅데이터를 바탕으로 자동적으로 판단하는 인공지능이다.
추론의 구조나 지식 베이스가 데이터를 바탕으로 학습하는 것으로 전형적으로 기계학습의 알로리즘이 이용되는 경우가 많다. 기계학습이라는 것은 표본이 되는데이터를 바탕으로 규칙이나 지식을 스스로 학습하는 것이다. 이 기술은 패턴 인식이라는 과거부터의 연구를 기초로 1990년대부터 진행되어 2000년대에 들어와 빅데이터 시대를 맞이하면서 더욱 진화하고 있다.
레벨4: 딥러닝을 받아들인 인공지능
기계학습을 할 때의 데이터를 나타내기 위해서 사용되는 입력값input(특징feature 이라고 불린다) 자체를 학습하는 것이 이
피드 구독하기:
글 (Atom)