Chapter 1 The data science process

이 책의 구성

Part 1 데이터 사이언스 소개

1. 데이터 사이언스 프로세스
2. R로 데이터 불러오기
3. 데이터 탐색하기
4. 데이터 관리하기

Part 2 모델링 방법

5. 모델 선택과 평가
6. 메모라이제이션 방법
7. 선형 회귀와 로지스틱 회귀
8. 비지도 방법
9. 고급 방법 살펴보기

Part 3 결과 보여주기

10. 문서화와 배포
11. 효과적인 프레젠테이션 만들기

Part 1 데이터 사이언스 소개

1장 데이터 사이언스 프로세스

1.1 데이터 사이언스 프로젝트에서의 역할들
1.2 데이터 사이언스 프로젝트의 단계
    - 목표 설정하기
    - 데이터 수집 및 관리
    - 모델링
    - 모델 평가 및 비평
    - 프레젠테이션과 문서화
    - 모델 배포 및 유지/보수
1.3 원하는 결과 설정하기
    - 모델 성능의 하한과 상한 설정하기
1.4 정리

데이터 사이언티스트는 프로젝트를 처음부터 끝까지 이끌어가는 역할을 맡고 있다. 데이터 사이언스 프로젝트에서의 성공은 하나의 흥미로운 도구에서 오는 것이 아니라, 수량화할 수 있는 목표, 좋은 방법론, 분야를 넘나드는 소통, 그리고 반복 가능한 작업흐름에서 온다.

1.1 데이터 사이언스 프로젝트에서의 역할들

데이터 사이언스는 무(無)에서 오는 것이 아니다. 다양한 역할과 기술, 그리고 도구에서 비롯된 협업이라고 할 수 있다. 프로세스 자체에 대해 살펴보기 전에 성공적인 프로젝트를 위해 필요한 역할들에 대해 우선 알아보도록 하자. 역할을 정의함에 있어서 Fredrick Brook 의 저서인 The Mythical Man-Month: Essays on Software Engineering(Addison-Wesley 출판사, 1995년) 에 나오는 "수술팀" 과 애자일 소프트웨어 개발 패러다임에서 아이디어를 조금씩 빌려왔다.

1.1.1 프로젝트에서의 역할

표 1.1 데이터 사이언스 프로젝트에서의 역할과 책임

경우에 따라 여러 역할을 담당하는 경우도 있으며, 특히 고객, 데이터 아키텍트, 그리고 운영팀의 경우에는 데이터 사이언스 프로젝트에 포함되지 않은 사람들이 그 역할을 담당하기도 하는데, 이 때 이들은 꼭 필요한 협력자들인 경우가 많다.

• 프로젝트 스폰서

  데이터 사이언스 프로젝트에서 가장 중요한 역할은 프로젝트 스폰서이다. 이들이 결과물을 원하는 사람이고, 일반적으로 비지니스의 관심을 대표하는 사람이기 때문이다. 결과물이 프로젝트 스폰서의 마음에 들 때 그 프로젝트는 말 그대로 성공한 것이고, 그들에게서 계약 종료를 얻어내는 것이 데이터 사이언스 프로젝트의 주된 조직 목표이다. 항상 스폰서에게 알려주고, 그들을 포함하라 계획과 진행 사항을 보여주고, 그들이 이해할 수 있는 말로 성공이던 실패던 중간 보고를 하라. 스폰서가 만족한 상태에서 계약을 종료하기 위해서는 구체적인 목표를 알아내야 한다. 그들의 목표를 양적인 말로 바꾸도록 항상 시도하라.

• 고객

  스폰서가 비지니스의 관심을 대표한다면, 고객은 모형의 최종 사용자의 관심을 대표한다고 할 수 있다. 이들은 수학이나 통계에 대한 전문가는 아닐지 모르지만 관련된 비지니스 프로세스에 정통하고, 팀에서 분야 전문가의 역할을 담당한다. 스폰서와 마찬가지로 고객들에게도 항상 알려주고, 관여하게끔 만들어야 한다. 만들어진 모형을 최종 사용자가 사용할 수 없거나, 사용하지 않는다면 그 프로젝트는 실패한 것과 마찬가지기 때문이다.

• 데이터 사이언티스트

  데이터 사이언티스트는 프로젝트 전략 수립과 고객 교육을 포함해서, 프로젝트를 성공으로 이끄는 데에 모든 책임을 지고 있다. 보다 기술적인 수준에서는, 이들은 데이터를 살펴보고, 통계적인 실험이나 절차를 수행하고, 머신 러닝 모델을 적용하고, 결과를 평가한다.

• 데이터 아키텍트

  데이터 아키텍트는 모든 데이터와 저장에 대한 책임을 지고 있다.

• 운영팀

  운영팀의 역할은 데이터를 수집하고, 결과물을 배포하는 데에 있어서 굉장히 중요하다. 이 역할을 맡은 사람은 반응 시간이나, 프로그래밍 언아, 배포에 있어서 중요한 데이터 크기 등에 대한 제약을 이미 알고 있을 가능성이 높다.

1.2 데이터 사이언스 프로젝트의 단계

이상적인 데이터 사이언스 환경은 데이터 과학자와 다른 이해관계자들 사이의 피드백과 대화를 장려하는 것이다. 비록 이 책이 다른 데이터 사이언스 프로세스에 대한 논의와 마찬가지로 사이클을 별개의 단계로 나누었지만, 실제로 그 단계들 사이의 경계는 유동적이며, 한 단계의 활동은 다른 단계와 겹치기도 한다. 심지어 당신이 한 프로젝트를 끝내고 모델을 배포하더라도, 새로운 이슈와 문제가 생길 수도 있다. 한 프로젝트의 끝이 다른 새로운 프로젝트로 이어지기도 한다.

* 목표 설정하기: 풀고자 하는 문제가 무엇인가?
* 데이터 수집하고 관리하기: 필요한 정보는 무엇인가?
* 모형 만들기: 해결책을 제시할 수 있는 패턴을 데이터에서 찾아보자.
* 모형 평가하기: 모델이 문제를 풀 수 있는가?
* 결과 발표하고 문서화 하기: 문제 해결 능력과 방법을 정립하자.
* 모형 배포하기: 실제 문제를 풀기 위한 모델을 배포하자.

1.2.1 목표 설정하기

데이터 사이언스 프로젝트에서 첫 번째로 할 일은 측정가능 하고 정량화할 수 있는 목표를 정하는 것이다.

* 애초에 스폰서는 왜 이 프로젝트를 원하는가? 부족한 것이 무엇이고 필요한 것이 무엇인가?
* 지금 해결하고자 하는 문제는 무엇이고, 왜 충분히 좋지 못한가?
* 필요한 자원은 무엇인가: 어떤 데이터가 필요하고, 사람을 얼마나 필요한가? 같이 일한 분야 전문가가 있는가? 컴퓨터 자원은 어느 정도인가?
* 당신이 제시할 결과를 스폰서는 어떻게 배표할 계획인가? 성공적인 배포를 위해 만족해야하는 제약 사항엔 어떤 것이 있는가?

명확한 목표는 확실한 정지 조건과 확실한 수용 조건을 얻게 해준다. 목표가 명확하지 않을수록 프로젝트는 산으로 갈 가능성이 높다. 왜냐하면 "적당히 좋은" 결과란 없기 때문이다.

하지만 그렇다고 때로 탐색적 프로젝트가 필요 없다는 뜻은 아니다. 이러한 경우라도 시간 제한과 같이 명확한 중지 조건을 통해 프로젝트의 범위를 정할 수 있다. 목표는 가설 후보를 세우는 것이다. 이러한 가설들은 이후에 전면적인 모델링 프로젝트를 위한 명확한 문제나 목표가 될 수도 있다.

프로젝트의 목표에 대한 좋은 아이디어를 세운 후에 목표를 달성하기 위한 데이터를 모으는 데에 집중할 수 있다.

1.2.2 데이터 수집과 관리

이 단계는 여러분이 필요로 하는 데이터를 파악하고, 탐색하고, 분석에 적당하게 가공하는 것을 포함한다. 때로 이 단계는 전체 프로세스에서 가장 많은 시간을 차지하기도 한다.

* 나에게 가능한 데이터는 무엇인가?
* 내 문제를 해결하는데 도움이 되는가?
* 충분한가?
* 데이터의 퀄리티도 만족스러운가?

가능하다면 최대한 직접 측정할 수 있는 정보를 사용하고, 다른 측정값에서 추론을 통해 얻을 수 있는 정보의 사용을 줄여라.

이 단계에서 데이터의 최초 탐색과 시각화가 이루어진다. 데이터 정제도 해야할 것이다. 데이터의 오류를 바로잡고, 필요하다면 변수를 변환할 것이다. 데이터 탐색과 정제 과정에서 문제 해결에 도움이 안 되는 것들을 발견하거나, 다른 정보도 필요하다고 느낄 수도 있을 것이다. 이러한 발견 때문에 여러분과 다른 이해 관계자가 프로젝트의 목표를 바꾸거나 개선을 할 수도 있다.

1.2.3 모델링

드디어 모델링이나 분석 단계에서 통계와 머신러닝을 사용하는 데까지 왔다. 여기서 여러분은 목표를 달성하기 위해 데이터에서 유용한 인사이트를 찾아내기 위해 노력해야할 것이다.

* 분류: 어떤 것이 속하는 카테고리를 정하는 것
* 스코어링: 가격이나 확률과 같은 숫자를 예측하거나 예상하는 것
* 랭킹: 선호에 따라 아이템을 분류하는 것을 배우는 것
* 클러스터링: 가장 비슷한 것들끼리 묶는 것
* 관계 찾기: 데이터에서 확인할 수 있는 상관 관계나 잠재적 인과 관계를 찾는 것
* 케릭터화: 데이터로부터 아주 일반적인 도표나 보고서를 만드는 것

library(rpart)

## Warning: package 'rpart' was built under R version 3.4.4

load('./Statlog/GCDData.RData')

model <- rpart(Good.Loan ~
                   Duration.in.month +
                   Installment.rate.in.percentage.of.disposable.income +
                   Credit.amount +
                   Other.installment.plans,
               data = d,
               control = rpart.control(maxdepth = 4),
               method = 'class')

1.2.4 모델 평가

모델을 만들고 나면 그것이 목표를 만족하는지 정해야만 한다:

* 요구사항만큼 정확한가? 일반화도 잘 되는가?
* "명확한 예상" 보다 정확한가? 현재 사용하는 것보다 결과가 나은가?
* 모델의 결과물이(계수, 클러스터, 규칙) 문제 영역에서 말이 되는가?

만약 위의 질문 중 하나라도 "아니요"라는 대답이 나왔다면, 다시 모델링 단계로 돌아가거나 데이터가 목표를 달성하는데에 도움이 되지 않는다고 결정을 내려야 할 것이다. 즉, 보다 현실적일 목표를 세우거나, 원래의 목표를 달성하기 위한 추가 자료나 자원을 모아야 한다는 것을 의미할 수도 있다.

실제 클래스와 예측한 클래스의 표로 이루어진 혼동행렬(confusion matrix)은 분류기(classifier) 의 정확도를 나타내는 좋은 요약 통계량이다.

# Make a data frame with 2 columns
resultframe <- data.frame(Good.Loan = creditdata$Good.Loan,
                          pred = predict(model, type = "class"))
head(resultframe)

##   Good.Loan     pred
## 1  GoodLoan GoodLoan
## 2   BadLoan  BadLoan
## 3  GoodLoan GoodLoan
## 4  GoodLoan GoodLoan
## 5   BadLoan GoodLoan
## 6  GoodLoan GoodLoan

# Make a frequency table with the data frame
rtab <- table(resultframe)
rtab

##           pred
## Good.Loan  BadLoan GoodLoan
##   BadLoan       41      259
##   GoodLoan      13      687

# Overall model accuracy
sum(diag(rtab)) / sum(rtab)

## [1] 0.728

# Model precision
sum(rtab[1, 1]) / sum(rtab[, 1])

## [1] 0.7592593

# Model recall
sum(rtab[1, 1]) / sum(rtab[1, ])

## [1] 0.1366667

# False positive rate
sum(rtab[2, 1]) / sum(rtab[2, ])

## [1] 0.01857143

전체적인 정확도는 만족스럽지 못하다. Recall 은 모형이 실제로 발견할 수 있는 나쁜 대출의 갯수를 측정한다. Precision 은 나쁘다고 예측한 대출이 실제로 나쁜 갯수를 측정한다. False positive rate 는 좋은 대출이 실수로 나쁘게 판단된 것의 갯수를 측정한다. 이상적으로는 recall 과 precision 은 높이고, false positive rate 는 낮추는 것을 우리는 원한다.

1.2.5 발표와 문서화

여러분의 모형이 성공 기준을 만족시켰다면 프로젝트 스폰서와 다른 이해 관계자들에게 그 결과를 보여주어야 한다. 그리고 배포된 이후 이 모형을 사용, 운영, 보수를 해야하는 사람을 위해 문서로 만들어야할 것이다.

그 대상은 자신의 역할에 따라 원하는 정보가 다를 것이다. 비지니스쪽 사람은 비지니스의 관점에서 여러분이 발견한 것의 영향력을 이해하고 싶어할 것이다. 모형의 기술적인 부분은 그들이 흥미로워할 주제가 아니기 때문에 생략하거나 개념적인 내용만 다루고 넘어가는 것이 더 좋을 것이다.

하지만 최종 사용자를 위한 발표에서는 이 모델이 어떻게 그들의 일을 도울 수 있을 지를 강조해야 할 것이다.

* 모형을 어떻게 해석해야하는가?
* 모형의 결과물은 어떤 형태인가?
* 만약 그 모형이 의사결정나무에서 사용한 결정들을 보여준다면 이를 어떻게 이해해야 하는가?
* 모형이 분류 예측과 함께 신뢰 점수까지 제공할 때 이를 어떻게 사용할 수 있는가?
* 모형을 기각할 수 있을 때는 언제인가?

1.2.6 모형 배포와 보수

드디어 모형이 운영에 들어갔다. 많은 곳에서 이는 데이터 사이언티스트의 우선 역할이 모형을 매일 운영하는 것이 아님을 의미한다. 하지만 여전히 그 모형이 문제없이 돌아가고, 큰 문제를 일으키지 않게끔 만들어야 한다. 뿐만 아니라 환경이 바뀜에 맞춰서 모형을 업데이트 하는 것을 잊지 말자.

1.3 기대치 설정하기

기대치를 설정하는 것은 프로젝트의 목표와 성공 조건을 설정하는 데에서 중요한 역할을 한다. 여러분의 팀에서 비지니스를 담당하고 있는 팀원은 아마도 이미 비지니스의 목표를 만족시키는데 필요한 성능에 대한 생각을 가지고 있을지도 모른다. 프로젝트를 제대로 시작하기 전 여러분이 가지고 있는 자원이 비지니스의 목표를 달성하는 데에 충분한지 확인해보자.

1.3.1 모형 성능의 하한과 상한 설정하기

수용 조건을 정하는 데에 있어서 모형이 어느 정도의 성능을 내야만 하는지, 그리고 주어진 데이터를 가지고 어느 정도의 성능을 낼 수 있는지는 모두 중요하다.

영모형: 성능의 하한

영모형이란 모형이 최소한 이것 보다는 나아야 한다는 "명백한 예측" 으로 설정하거나, 현재 존재하는 해결책으로 설정할 수 있다. 만약 현재 사용하는 모형이 없다면 만들 수 있는 모형 중에서 가장 간단한 것으로 정해라. 그렇다면 이것 보다 얼만큼이나 나아야 할까? 통계학에서는 가설검증 이나 유의성 검증 이라는 것이 있는데, 여러분의 모형이 영모형보다 더 나은지를 검증하는 절차이다. 여러분은 모형의 성능이 통계학적으로 "유의적으로 더 나은" 성능을 보이게끔 해야한다.

베이즈율: 성능의 상한

비지니스에서 원하는 성능 목표는 하한 이상이라면 당연히 높을수록 좋을 것이다. 최대한 빨리 이 목표를 이룰 수 있는 데이터가 준비되도록 해야만 한다. 여기서 살펴봐야할 것은 통계학자들이 설명할 수 없는 분산(Unexplainable variance) 라고 부르는 것이다. 즉, 여러분이 가진 입력변수로도 설명할 수 없는 분산이 어느 정도 인지를 말한다. 베이즈율은 현재 가지고 있는 데이터로 달성할 수 있는 최고의 예측 정확도라고 생각할 수 있다. 만약 베이즈율이 비지니스에서 원하는 성능 목표에 미치지 못한다면 모형을 개선시킬 수 있는 추가 데이터를 찾기 전까지는 프로젝트를 시작해서는 안 될 것이다.

1.4 요약

데이터 사이언스 프로젝트는 데이터 사이언티스트와 다른 이해 관계자들 사이에, 그리고 프로세스의 다른 단계들 사이에 수없이 많은 반복을 요구한다. 그리고 그 이해 관계자들에게 알려주고, 그들을 관련시키는 것이 중요하다. 프로젝트가 끝났을 때 이와 관련된 사람 중 그 누구도 최종 결과물에 놀라지 않도록 해야한다.

명심해야할 점

* 성공적인 데이터 사이언스 프로젝트는 통계 이상의 것을 요구한다. 운영적인 고민뿐만 아니라 비지니스와 고객의 관심을 대표하는 다양한 역할을 필요로 한다.
* 명확하고, 확실하고, 정량화할 수 있는 목표를 갖도록 하라.
* 모든 이해 관계자들에게 현실적인 목표를 제시하도록 하라.

1.2.3 모델링

드디어 모델링이나 분석 단계에서 통계와 머신러닝을 사용하는 데까지 왔다. 여기서 여러분은 목표를 달성하기 위해 데이터에서 유용한 인사이트를 찾아내기 위해 노력해야할 것이다.

* 분류: 어떤 것이 속하는 카테고리를 정하는 것
* 스코어링: 가격이나 확률과 같은 숫자를 예측하거나 예상하는 것
* 랭킹: 선호에 따라 아이템을 분류하는 것을 배우는 것
* 클러스터링: 가장 비슷한 것들끼리 묶는 것
* 관계 찾기: 데이터에서 확인할 수 있는 상관 관계나 잠재적 인과 관계를 찾는 것
* 케릭터화: 데이터로부터 아주 일반적인 도표나 보고서를 만드는 것

library(rpart)
load('./Statlog/GCDData.RData')

model <- rpart(Good.Loan ~
                   Duration.in.month +
                   Installment.rate.in.percentage.of.disposable.income +
                   Credit.amount +
                   Other.installment.plans,
               data = d,
               control = rpart.control(maxdepth = 4),
               method = 'class')

1.2.4 모델 평가

모델을 만들고 나면 그것이 목표를 만족하는지 정해야만 한다:

* 요구사항만큼 정확한가? 일반화도 잘 되는가?
* "명확한 예상" 보다 정확한가? 현재 사용하는 것보다 결과가 나은가?
* 모델의 결과물이(계수, 클러스터, 규칙) 문제 영역에서 말이 되는가?

만약 위의 질문 중 하나라도 "아니요"라는 대답이 나왔다면, 다시 모델링 단계로 돌아가거나 데이터가 목표를 달성하는데에 도움이 되지 않는다고 결정을 내려야 할 것이다. 즉, 보다 현실적일 목표를 세우거나, 원래의 목표를 달성하기 위한 추가 자료나 자원을 모아야 한다는 것을 의미할 수도 있다.