The Yellow Lion King 데이터와 함께 살아가기

[ 직딩생활 ] 보고 잘하는 법

"김대리, XX사업 건 어떻게 됬나? 왜 보고 안했어!!! "

"사업건 취소 됬다며?! 왜 나한테 보고 안했어!!!"

"보고 할 건지도 모르고 있고... 직장생활 기본이 안되있구만!!!"

직장 생활을 하다보면 거의 매일, 많은 일을 보고 하면서 보냅니다.

아니, 어찌보면 보고가 일이고 일중에서 제일 중요한 일입니다.

출근 인사도 출근 보고로 볼 수 있고, 회의나 외근을 다녀올 경우에는 전 후로 보고를 하기도 합니다.

이럴때 가끔 고민이 생깁니다. 

'회의갔다 온 것을 보고해야 하나 말아야 하나?'

정답은 없습니다.

아니 정답은 보고를 받는 사람의 스타일에 따라 다릅니다.

그렇기 때문에 보고가 어려운 것 같습니다.

이런 저런 일을 보고하면

"그런건 보고할 필요 없어!'"

라고 하거나

일이 벌어진 뒤에

 "아니 그런 내용을 왜 아직도 보고 하지 않았나!"

라고 호통을 받기도 합니다.

참,,, 직장생활 어렵죠..ㅠㅠ

위에서 말씀드린 것처럼 보고자의 성향이나 습관에 따라 보고 기준은 다릅니다. 

그렇지만 일반적으로 보고해야하는 기준을 제시해 보고자 합니다.

첫째, 피보고자의 관리 범위를 벗어나는 일에 대해서는 보고를 해야합니다.

'어! 그런일을 나는 왜 모르고 있었지?'라는 말이 나오면 안됩니다.

예를 들면 팀장에게 보고 할 내용은 타 팀과의 협력이나 문제가 있는 경우에 해당합니다.

둘째, 피보고자의 상위자에게 보고 될 내용에 대해서는 미리 보고를 해야합니다.

이것도 당연하겠지요. 본부장은 알고 있는데 팀장이 모르고 있으면 안되기 때문이지요.

첫번째 기준하고 겹치는 부분이 있지만 회사도 조직생활이기 때문에 피할 수 없습니다.

셋째, 기 보고했던 내용에 대한 변경이 발생할 경우 보고를 해야합니다.

지난 번에 내일까지 완료될 것 같다고 보고했는데 문제가 생겨서 완료가 어렵게되면 보고를 해야합니다.

안그러면 지난번 보고가 허위보고가 되는 거죠.

넷째, 휴가, 출장, 외근, 사고 등 근태에 대한 내용은 보고를 해야합니다.

이부분은 아마 사규에 포함되어 있고 시스템적으로 구현되어있는 곳도 많을 것 입니다. 

기본적이고 중요한 보고이기 때문이지요. 정확치는 않지만 휴가나 출장 등 근무장소와 관련된 내용은 업무중 사고 발생시 산재 처리에도 영향을 주기 때문에 중요합니다.

다섯째, 보고해야 할 의미가 있을 때는 보고해야 합니다.

너무도 당연한 얘기지만

'XX와 만나서 XXX 추진 건에 대해서 협의를 하고 왔습니다' 

라고 보고하면

"그래서 뭐! 어쩌라고!"

라는 말을 들을 수 있습니다.

그러니 보고전에 어떤 의미를 전달해야 할지, 그리고 한발 더 나간다면 여기에 피 보고자는 어떻게 반응할지 생각하고 보고해야 합니다.

반대로 어떤 반응이나 인식을 이끌어 내기 위해 보고를 할 경우도 있습니다.

전략적 보고의 한 경우 입니다.

(당연한 얘기지만 사규에서 정한 업무에 따른 보고 절차/기준/방법은 준수해야 합니다.)

보고 시 허위 보고, 과장/축소 보고, 누락 보고 하면 안됩니다.

전략적으로 보고하고, 가급적 짧게 자주 보고하는게 좋습니다.

사안의 경중과 피 보고자의 스타일에 따라서 보고 방법은 달라질 수 있습니다.

일반적으로 상사들은 보고 받기를 좋아합니다.(좋은 소식 위주로...^^)

가급적이면 많은 정보를 제공하고 소통하는 것이 제일 좋은 보고 방법일 수 있습니다.

그리고 마지막으로 다시한번 피 보고자의 입장에서 생각해보고 보고한다면 

당신의 보고는 완벽할 것 입니다.

도움이 되셨기를 바랍니다. 

감사합니다.

빅데이터 관점에서 아키텍처(Architecture)란 무엇일까요?

그리고 아키택트(Architect)는 무엇을 해야할까요?

이를 위해서는 먼저 용어에 대한 정확한 이해가 필요하겠지요?

     // (그전에 잠깐 !!! 왜 빅데이터가 중요한지 알고계시죠? ^^

     //   바로 지난 포스팅에서도 언급되었지만 4차 산업혁명의 핵심 기반이 빅데이터이기 때문입니다.)

그래서 먼저 구글에서 조사해 보겠습니다.

구글에서 아키텍처 라고 검색하면 아래와 같이 나옵니다.

음...무슨 무슨 방식 이라는 용어가 눈에 들어오네요.

우리가 원하는 것은 빅데이터, 그리고 IT시스템과 관련된 아키텍처의 정의를 원하고 있으므로

그 아래 위키 백과에 있는 시스템 아키텍처에 대한 정의가 더 적합 할 것 같습니다.

위키 백과에서는 시스템 아키텍처(System Architecture)를 '시스템이 어떻게 작동하는지를 설명하는 프레임워크' 라고 정의하고 있습니다.

그리고 시스템 목적을 달성하기 위한 각 컴포넌트가 무엇이며, 어떻게 상효작용하는지 등을 설명하는 것이라고합니다.

여기서 보니 프레임워크, 컴포넌트, 상호작용 이라는 용어가 눈에 들어옵니다. 그리고 결국 시스템 아키텍처란 시스템을 설명하기 위한 무엇이네요.

위키에서 프레임워크를 계속해서 찾아보니 '복잡한 문제를 해결하거나 서술하는 데 사용되는 '기본 개념 구조'라고 되어있습니다.

컴포넌트는 다른 말로 구성요소 이니, 결국 아키텍처란 '시스템을 잘 설명하기위해 구성요소와 구조, 관계 등을 설명하는 자료' 라고 할 수 있겠습니다.

이해가 되시는지요?

그래서 구글에서 아키텍처라고 검색하고 이미지를 누르면 아래와 같이 대부분이 순서도와 같은 블럭과 선으로 그려진 이미지들이 보이네요.

그래서 아키텍처를 Box-Line Diagram 이라고 부르기도 한답니다.^^

사실 아키텍처는 지금으로부터 약 10년전에 유행했었습니다.

바로 엔터프라이즈 아키텍처 라는 이름으로 유행했었죠.

우리가 배운 내용으로 무슨 내용일지 유추해 볼까요?

엔터프라이즈는 기업이고 아키텍처는 위에서 말한 것 처럼 설명을 하기 위한 구성요소, 구조 이니...

풀어서 설명하면 기업을 설명하기위해 정리된 구성요소와 구조, 관계를 말합니다. 이런 것은 대부분 박스와 선으로 그려진 이미지로 정리될 수 있고요.

좀더 깔끔하게 정리된 위키 백과의 내용을 보면 아래와 같습니다.

엔터프라이즈 아키텍처(Enterprise Architecture; EA)는 조직의 프로세스 및 정보 시스템 및 부서의 구조와 기능을 포괄적이고 정확한 방법으로 기술하는 방법이고, 이것을 통해 조직이 전략적 목표에 따라 행동하도록 방향을 제시하는 것이다. 정보기술(IT)와 관련이 깊지만, 사업 최적화도 관련이 깊고, 사업구조, 성과관리, 조직구조 아키텍처 등으로 불린다.

자세히 보니 기업에서 수립되는 전략을 슬로건이나 경영 방침/목표로 삼고 추진하는 것도 좋지만 엔터프라이즈 아키텍처로 만들어서 이미지로 구체화 하면 더욱 이해하기 쉬울 것 같다는 생각이 들었습니다.

엔터프라이즈 아키텍처(EA)는 다시 서브 아키텍처로 구성되는데 주로 4가지로 구성됩니다. 

즉, 비즈니스 아키텍처(BA: Business Architecture), 어플리케이션 아키텍처(AA: Application Architecture), 데이터 아키텍처(DA: Data Architecture), 기술 아키텍처(TA: Technical Architecture) 로 구성됩니다. (EA 이야기는 시간이되면 따로 하겠습니다. 이분야도 엄청나게 넓은 분야여서 설명에 많은 시간이 필요할 것 같습니다. 아! 그리고 4가지 뿐만 아니라 정책, 원칙, 표준, 보안 등 다른 요소를 추가하여 EA를 구성하는 기업도 있습니다. 이는 기업의 업종과 특성에 따라 추가될 수 있습니다. 이런 요소가 포함된 것을 엔터프라이즈 거버넌스라고도 합니다.)

그래도 우리가 배운 지식을 이용해서 짧게 설명하고 넘어가자면 비즈니스 아키텍처는 기업의 비즈니스를 잘 설명하기 위해 구성요소를 정의하고 구성요소간의 관계를 정리한 자료이고, 어플리케이션 아키텍처는 이러한 기업의 비즈니스 활용을 위한 주요 IT시스템의 구성 내용과 관계를 정리한 것이라 할 수 있으며, 데이터 아키텍처는 기업 전체의 데이터가 어떻게 구성되고 어떻게 관계/운영되는지를 정리한 자료가 될 것 같습니다. 그리고 기술 아키텍처는 이러한 시스템들을 구축/운영하기 위한 하드웨어/기술의 구성요소와 요소간의 관계를 정리한 자료라고 할 수 있겠습니다. 구체적인 자료로 보면 프로세스 멥, 기능 멥, 데이터 (개념/논리/물리)모델, 서버/Network 구성도가 될 것 같습니다.

보통 단위/단일 시스템의 아키텍처에도 동일하게 적용하여 시스템 구축 전에 아키텍처를 설계하고 설계에 따라 시스템을 구축하게 됩니다. (물론 국내에서는 주로 대형 프로젝트가 아니면 시간과 비용을 아끼고자 이러한 아키텍처 설계 부분이 무시되거나 축소되는 경향이 많습니다. - 체계적이지 못한 것이지요)

이렇게 해서 대략적인 아키텍처, 엔터프라이즈 아키텍처 그리고 그와 관련된 BA, AA, DA, TA 등에 대한 용어를 익히게 되었습니다.

기본부터 시작하다보니 중요한 것을 빼먹었는데요.....

시스템 아키텍처는 왜 필요할까요? 

좀더 쉽게 (공부했으니까..^^) 시스템을 잘 설명하기 위한 구성/구조/관계를 정리한 자료가 왜 필요할까요?

잠시, 생각해보시죠.

....

생각하고계시죠 ? ! ......

....

생각나셨나요? 네, 결국 시스템을 잘 구축하고 활용/관리하기 위해서 필요하며, 또다른 중요한 이유는 다른 관계자(사용자, 개발자 등)와 소통하기 위한 자료/Tool로서 필요합니다. 여기서 조금 더 들어가면, 시스템을 잘 구축하고 활용/관리 한다는 의미는 결국 시스템 구축시, 운영시, 변경시 아키텍처가 있으면 효율적으로(싸고/빠르고/품질좋은 시스템을) 구축할 수 있다는 것이고, 운영시 장애에 효과적으로 대처할 수 있으며, 시스템의 확대/변경 필요시에도 효율적으로 대응할 수 있음을 의미합니다.

많이 오기는 했는데요 ^^,  제가 앞으로 말씀드릴 내용은 바로 빅데이터 아키턱처에 대한 이야기 입니다.

아키텍처는 이제 이해 되셨죠...빅데이터는 그냥 간단하게 큰 데이터라고 생각하시면 됩니다.

초기에 빅데이터를 정의하고 특징을 말핼때 3V 라고해서 

데이터의 크기(Volume), 데이터의 속도(Velocity), 데이터의 다양성(variety)을 강조 했습니다.

요즘은 여기에 가치(Value)를 추가하여 4V라고 합니다.

다시말하면 3가지의 특징을 가지는 데이터를 빅데이터라고 말할 수 있습니다.

단일시스템에서 보관할 수 없을 정도 크기(Volume)의 데이터, 실시간으로 생성,저장,시각화 되야하는 데이터,

그리고, 포멧이 정해진 DBMS의 테이블이 아니라, 이미지, 택스트파일, 비디오/오디오 파일 등 비정형의 다양한 데이터까지포함하는 다양성(Variety)을 가지는 데이터를 말합니다.

이러한 빅데이터를 수집/저장/처리/분석하기위한 아키텍처는 어떻게 구성해야하는지를 앞으로 이야기해보도록 하겠습니다.

빅데이터가 확대 생산되면서 이에 대한 저장/관리/처리/활용이 더욱 중요하게 되었고 목적에 따라 새로운 아키텍처 패턴이 필요하게 되었으며, 최근에적용이 확대되면서 더욱 중요해지고 있기 때문이죠.

이후에는 비즈니스 요건과 이에 따른 아키텍처 패턴에 대해서 차근차근 알아보겠습니다.

감사합니다.

전에 봤던 Good Java 보다 한 단계 수준 높은 책이다. 왜냐하면 Good Java에서는 자세한 설명과 이미지로 이해를 쉽게 하여 입문 개발자를 위한 책이었다.

이책의 제목에서 처럼 자바 입문이 아닌 스프링 입문을 위한 책이다. (스프링 입문을 위한 자바 객체지향의 원리와 이해)

그럼에도 불구하고 객체지향의 원리와 구조적 방법과의 차이 등을 자세하게 설명한다.

특히 객체지향 프로그래밍의 특징중 하나인 추상화를 설명할때 일반적으로 추상하면 떠오르는 피카소와 이집트의 벽화를 예로 들면서 일반적인 개념에서 프로그래밍적인 개념으로의 이해를 돕고 있다.

뒷 부분으로 가면서 스프링을 이용한 실질 적인 프로그래밍 패턴과 코드 설명 등이 자세하게 나온다.

뒷부분의 스프링 관련 내용은 많은 내용을 담고 있어서 모두 이해하지는 못했다.

OOP의 4대 특성 = 캡, 상추다.

캡술화 - Encapsulation : 정보 은닉(information hiding)

상속 - inheritance : 재사용

추상화 - Abstraction : 모델링

다형성 - Polymorphism : 사용 편의

객체 지향 설계 5대 원칙 = SOLID

1. SRP (Single Responsibility Principle) : 단일 책임 원칙

   ==> 어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다 - 로버트 C. 마틴

2. OCP (Open Closed Principle): 개발 폐쇠 원칙

   ==> 소프트웨어 엔티티(클래스, 모듈, 함수 등)는 확장에 대해서는 열려 있어야 하지만 변경에 대해서는 닫혀 있어야 한다 - 로버트 C. 마틴  -> 다른말로: 자신의 확장에는 열려 있고, 주변의 변화에 대해서는 닫혀 있어야 한다.

3. LSP ( Liskov Subsitution Principle) : 리스코프 치환 원칙

  ==> 서브 타입은 언제나 자신의 기반 타입으로 교체할 수 있어야 한다. - 로버트 C. 마틴

  --> 다른말로: 하위 클래스 is a kind of 상위 클래스 - 하위 분류는 상위 분류의 한 종류다.

                    구현 클래스 is able to 인터페이스 - 구현 분류는 인터페이스할 수 있어야 한다.

4. ISP (Interface Segregation Principle): 인터페이스 분리 원칙

  ==> 클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안된다 - 로버트 C. 마틴

        다른말로 : 단일 책임원칙(SRP)과 인터페이스 분리원칙(ISP)은 같은 문제에 대한 두 가지 다른 해결책이라고 볼수 있음

        한 남자에게 많은 역할 책임을 주지말고 남자를 역할별로 분리하거나, 역할별로 인터페이스를 만들어서 해결 

5. DIP (Dependency Inversion Principle): 의존 역전 원칙

  ==> 고차원 모듈은 저차원 모듈에 의존하면 안된다. 이 두 모듈 모두 다른 추상화된 것에 의존해야 한다.

  ==> 추상화된 것은 구체적인 것에의존하면 안 된다 구체적인 것이 추상화된 것에 의존해야 한다.

  ==> 자주 변경되는 구체(Concrete) 클래스에 의존하지 마라

  --> 다른말로 : 자신보다 변하기 쉬운 것에 의존하지 마라

06장 스프링이 사랑한 디자인 패턴

스프링 : 자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크

디자인 패턴은 객체 지향의 특성 중 상속(extends), 인터페이스(interface/implements), 합성(객체를 속성으로 사용)을 이용한다.

어댑터 패턴(Adapter Pattern)

   데이터베이스 시스템을 공통의 인터페이스인 ODBC 또는 JDBC를 이용해 조작하는 것과 같은 구조 패턴

프록시 패턴(Proxy Pattern)

   다른 누군가를 대신해서 그 역할을 수행하는 대리자/대변인을 만들어 사용하는 구조

데코레이터 패턴(Decorator Pattern)

   메서드 호출의 반환값에 변화를 주기 위해 중간에 장식자를 두는 패턴

싱글턴 패턴(Singleton Pattern)

   인스턴스를 하나만 만들어 사용하기 위한 패턴

템플릿 메서드 패턴(Template Method Pattern)

   상위 클래스의 견본 메서드에서 하위 클래스가 오버라이딩한 메서드를 호출하는 패턴

팩터리 메서드 패턴(Factory Method Pattern)

   팩터리 메서드란 객체를 생성해서 반환 하는 메서드

   오버라이드 된 메서드가 객체를 반환하는 패턴

전략 패턴(Strategy Pattern)

   클라이언트가 전략을 생성해 전략을 실행할 컨텍스트에 주입하는 패턴

   패턴의 3요소 (전략 객체, 컨텍스트, 클라이언트)

     : 전략 메서드를 가진 전략 객체, 전략 객체를 사용하는 컨텍스트, 전략 객체를 생성해 컨텍스트에 주입하는 클라이언트(제3자)

템플릿 콜백 패턴(Template Callback Pattern-견본/회신 패턴)

   전략을 익명 내부 클래스로 구현한 전략 패턴

그밖에

  스프링의 MVC의 경우 프론트 컨트롤러 패턴(Front Controller Pattern) 과 MVC 패턴(Model-View-Controller)을 활용하고 있다

07 스프링 삼각형과 설정 정보

POJO (Plain Old Java Object) 기반의 IoC/DI, AOP, PSA

IoC(Inversion of Control / 제어의 역전), DI(Dependency Injection / 의존성 주입)

AOP : Aspect-Oriented Programming : 관점/핵심 지향 프로그래밍

PSA : Portable Service Abstraction : 일관성 있는 서비스 추상화

08 자바8 람다와 인터페이스 스팩 변화

빅데이터 지원을 위한 멀리코어 병렬분산 프로그래밍을 위한 개선 필요

빅데이터 지원을 위한 자바8변경사항

   빅데이터 지원 -> 병렬화 강화 -> 컬렉션 강화  -> 스트림 강화 -> 람다 도입 -> 인터페이스 명세 변경 -> 함수형 인터페이스 도입

람다란 코드블럭, 이를 변수로 활용 가능

람다 = 변수에 저장 가능한 로직

기존의 자바에서 로직은 메서드를 통해서만 구현이 가능했는데 이제 람다로 표현할 수도 있게 됨

데이터 분석 방법론 (KDD, SEMMA, CRISP-DM)

데이터 분석 방법론

막상 데이터 분석을 하려고 하면 막막할 때가 많습니다...이럴때 미리 잘 정리된 절차와 방법을 따라서 하나씩 진행한다면 쉽게 접근할 수 있겠지요! 바로~~~, 이러한 방법을 정리해 봅니다. ^^

​먼저 분석 방법론이란 무엇일까요? 방법론은 쉽게 말하면 앞에서도 잠깐 얘기한 절차와 방법입니다. 즉 어떤 일을 하기위한 체계적인 절차와 그 처리 방법을 정리한 것이라고 하겠습니다. 그럼 데이터 분석 방법에는 어떤 것들이 있을까요? 분석 방법에는 크게 3가지로, 통계적 방법론, 데이터 마이닝 방법론, 빅데이터 방법론으로 구분할 수 있을 것 같습니다. 통계적 방법론은 전통적인 통계 분석을 위한 방법론을 말합니다. 주로 학술 연구를 중심으로 사용되지요. 그리고 통계적 기법/이론을 발굴/적용하는데 중심이 되어있기 때문에 비즈니스 목적과 요구사항을 파악하고 처리하는데 미흡합니다. 반면 데이터 마이닝 방법론은 비즈니스 활용을 목적으로 만들어진 데이터 분석 방법론입니다. 즉, 분석을 통한 비즈니스 활용을 위한 절차와 방법이 정리되어 있습니다. 때문에 산업 현장에서 많이 쓰입니다. 빅데이터 방법론은 빅데이터의 적용 확대에 따라 비정형 데이터의 활용, 분산/분석 기술의 변화와 이에 따른 필요한 분석방법의 (귀납법중심으로의) 변화에 따른 새로운 분석 방법론입니다.

오늘은 그중에서 데이터 마이닝 방법론에 대해서 이야기해 보겠습니다.
제정법(제가 정리한 방법)에 따르면 데이터 분석을 위해 필요한 단계/절차, 활동내용, 산출물을 정리한 것으로 방법론에 따라 분석을 쭉~ 진행해 나가면 자연 스럽게 분석이 이루어지게 되는 것을 말합니다. 따라서 잘만 따라서 진행해 나간다면 (1)초보자도 쉽게 따라할 수 있으며, (2)분석지식이 부족한 사람도 분석 과정을 이해하기 쉽고, (3)중간에 깜빡하고 지나가는 작업을 방지할 수 있어서 일정한 수준 이상의 데이터 분석 품질을 유지 할 수 있습니다. 물론, 각 방법론의 의미와 방법을 잘 이해하고 잘 따라가야 겠지요. ^^

KDD, CRISP-DM, SEMMA

KDD는

Knowledge Discovery in Database의 약자이며 기술과 데이터베이스를 중심으로한 Insight 발굴을 위한 절차와 단계를 정리한 것입니다. 때문에 DBMS를 운영하는 조직에서는 쉽고 유용하게 사용될 수 있습니다. (이를 위해 BI(Business Intelligence)라는 용어로 불리어 지기도 합니다. 서로 다른 점을 보면 BI는 개념적인 측면의 용어이고 KDD는 방법론의 이름이라는 것이 다릅니다.) 때문에 KDD는 데이터베이스에서의 Data를 통해 Insight를 얻기 위한 표준화된 처리 절차와 방법에 대한 정의라고 생각하시면 됩니다.

크게 5단계의 과정, Selection: 추출(Target Data 생성), Pre-processing: 전처리(Preprocessed Data), Transformation: 변환(Transformed Data), Data Mining(Patterns), Interpretation Evaluation: 해석/평가(Knowledge)을 거치게 됩니다.

[Google image 검색결과중]

SEMMA는

Sampling Exploration Modification Modeling Assessment의 약자입니다. Statistics 관점의 방법론으로 분석 솔루션 업체인 SAS사 주도로 만들어진 방법론 입니다. 총 5단계로 구성되며, 샘플링, 데이터 탐색/전처리 등 통계 중심의 방법론 입니다. 이름중에 Sampling이 들어있는 것만봐도 아시겠죠! 그래서, 이것도 역시 비즈니스 상에서 필요한 목적과 요구사항 도출/정리/처리하는데 적합하지 않은 방법 입니다.

​​[Google image 검색결과중]

CRISP-DM는

CRoss-Industry Standard Process for Data Mining의 약자 입니다.1996년 유럽연합EU의 프로젝트로 시작했습니다. CRISP-DM은 SPSS, Teradata, NCR 등 많은 업체들이 참여했습니다. 현재는 공식적인 활동은 중단한 상태이고 IBM의 SPSS Modeler 가이드로 업계애서 많이 사용중 입니다. 단계는 총 6단계로, 비즈니스 이해, 데이터 이해, 데이터 준비, 모델링, 모델 평가, 고객전달 입니다. 비즈니스 현장에서 많이 쓰이는 방법론이니까 자세히 알아보겠습니다.

각 단계 별로 아래와 같은 목적 및 주요 Task가 있습니다.

1. 비즈니스 이해
• ​Determine Business Objects
• Assess Situation
• Determine Data Mining Goals
• Produce Project Plan​
2. ​데이터 이해
• ​Collect Initial Data
• Describe Data
• Explore Data
• Verify Data Quality​
3. 데이터 준비
• ​Select Data
• Clean Data
• Construct Data
• Integrated Data
• Format Data
4. 모델링
• ​Select Modeling Technique
• Generate Test Design
• Build Model
• Assess Model​
5. 모델 평가
• ​Evaluate Results
• Review Process
• Determine Next Steps​
6. 고객전달 ​
• ​Plan Deployment
• Plan Monitoring and Maintenance
• Produce Final Report
• Review Project

​

[Google image 검색결과중]


이렇게 방법론을 보고 따라서 하려해도 실제로 업무에 적용하는 것은 쉬운 일이 아닙니다. 논리적인 연계와 흐름이 쉽지 않아서 이해하고 목적에 맞게 분석을 수행해 내기가 쉽지 않기 때문이죠.
다음 포스팅에서는 구체적인 사례를 들어가면서 얘기해 보도록 하겠습니다.

https://bigdatamaster.tistory.com/66

감사합니다.

그리고 이러한 기술 활용을 통한 고객 프로파일링 내용과
택스트 분석을 통한 고객분석/고객 성향분석에 대한 정보는 아래를 확인해보세요.

https://bigdatamaster.tistory.com/m/6

https://bigdatamaster.tistory.com/m/96