• Home

이젠 ggmap으로 네이버지도 기반 시각화를 즐기자!

새해 첫 포스팅을 네이버 지도 API 연동 코드가 ggmap 패키지(개발버전)에 통합된 것을 알리는 것으로 시작한다.

제작년(2013) 11월에 ggmap의 구글 API의 오류를 살펴보다가 한국의 PoI(point of interest)가 포함된 네이버 맵 API를 통합하면 어떨까 해서 약 6시간동안 뚝딱 만들어서 pull request를 보냈던 기억이 난다. 그러나 pull request에 대한 어떠한 피드백도 받지 못하고 있다가 22일전 쯤에 ggmap의 제작자로부터 코드 커밋에 대한 커멘트가 올라왔던 것을 오늘 확인했고, 실제 개발 버전을 설치해 테스트를 해보니 잘 동작하는 것을 보고 이렇게 글을 쓴다.

hw

너무 오랜 기다림이고 잊고있었던 상태라 다소 예상치 못한 즐거움을 준것도 사실임…. ㅎㅎ

이 코드가 오늘도 통합이 안되어 있었다면 ggnavermap과 같은 패키지를 만들려고까지 했는데, 그런 코드 브랜치는 만들 필요가 없어져서 매우 다행이라는 생각을 해본다. 다만 네이버의 지도 static API지원이 앞으로도 쾌적하게 지원되기만을 바랄 뿐이다.

그리고 다음 CRAN 릴리즈가 언제가 될지 모르지만 아래와 같이 개발버전을 사용해도 큰 문제는 없다고 생각한다.

앞으로 네이버맵 static API관련 ggmap의 코드 서포트를 해야될거 같아 보이니 현재 ggmap의 구조도 다시 파악해야 될 것 같다.

모두들 네이버 지도 API로 즐거운 지도 시각화가 되길 바란다. :)

## devtools::install_github("dkahle/ggmap")
library(ggmap)
library(lubridate)

#한국 지진 데이터
#https://dl.dropboxusercontent.com/u/8686172/eq2.tsv
eq <- read.table('eq2.tsv', sep = "\t", header = T, stringsAsFactors = F)
eq$latitude <- unlist(strsplit(eq$latitude, " "))[seq(from = 1, to = nrow(eq),
    by = 2)]
eq$longitude <- unlist(strsplit(eq$longitude, " "))[seq(from = 1, to = nrow(eq),
    by = 2)]


eq$longitude <- as.double(eq$longitude)
eq$latitude <- as.double(eq$latitude)
eq$year <- as.factor(substr(eq$date, 1, 4))
eq$date <- ymd_hm(eq$date)

cent <- c(126.96136, 37.52962)
bmap <- ggmap(get_navermap(center = cent, level = 4, baselayer = "default",
    overlayers = c("anno_satellite", "traffic"), marker = data.frame(cent[1],
        cent[2]), key = "c75a09166a38196955adee04d3a51bf8", uri = "www.r-project.org"),
    extent = "device", base_layer = ggplot(eq, aes(x = longitude, y = latitude)))

bmap + geom_point(aes(size = power, colour = date), data = eq, alpha = 0.7) +
    geom_density2d()

plot of chunk unnamed-chunk-1

블로그 방문자수 예측치 평가 비교

블로그 방문자 예측 모형 생성 후 약 2주가 지났으며 슬슬 실제 값과 예측값을 비교 분석해볼 필요가 있을것 같아서 아래와 같이 추가 분석을 해봤다.

suppressPackageStartupMessages({
library(rga)
library(xts)
library(forecast)
})
rga.open(instance="ga", where="./ga.rga")


daily_visits_src <- ga$getData(
  key,
  start.date = "2011-01-01",
  end.date = "2014-12-29",
  metrics = "ga:users",
  dimensions = "ga:date",
  sort = "ga:date",
  batch = TRUE
)

daily_visits <- daily_visits_src 

library(forecast)

daily_xts <- xts(daily_visits$users, order.by = daily_visits$date,frequency = 7)

weekly_sum <- apply.weekly(daily_xts, sum)

weekly_ts <- ts(as.numeric(weekly_sum["/2014-12-14"]), start = c(2011, 1),frequency = 52)


weekly_ar <- auto.arima(weekly_ts)


plot(forecast(weekly_ar,h=2))
lines(ts(as.numeric(weekly_sum["/2014-12-28"]), start = c(2011, 1),frequency = 52), col='red')
lines(fitted(weekly_ar), col='blue',lty=2)
legend("topleft", legend=c('observation', 'fitted'),lty = c(1,2), col = c('red','blue'))

plot of chunk unnamed-chunk-1

위 그래프에서 푸른색 점은 예측치를 의미한다.

#예측치
forecast(weekly_ar,h=2)
##          Point Forecast    Lo 80    Hi 80     Lo 95    Hi 95
## 2014.981       1700.911 1468.060 1933.761 1344.7966 2057.024
## 2015.000       1286.451 1026.222 1546.680  888.4654 1684.437
#실측치
weekly_sum["2014-12-21/"][1:2]
##            [,1]
## 2014-12-21 1423
## 2014-12-28 1513
accuracy(forecast(weekly_ar,h=2), as.numeric(weekly_sum["2014-12-21/"][1:2]))
##                     ME     RMSE      MAE         MPE     MAPE      MASE
## Training set  16.72562 181.2540 129.5494 -0.02872443 12.00540 0.9226019
## Test set     -25.68086 253.5336 252.2297 -2.27820967 17.25169 1.7962840
##                    ACF1
## Training set 0.02624812
## Test set             NA

MAPE가 학습시 12%정도였는데, 실제 시간이 지나 2주치 방문자의 실제값과 예측치를 비교한 test의 경우 17%가 나옴.

피크를 친 다음주의 낙폭이 예상보다 컸다는 것을 알 수 있는데, 이는 하루동안 블로그가 히트를 쳤다고 해서 그 인기가 계속 진행되지는 않는다는 것을 알려주고 있으며, 어느정도 평상시 방문자수에 회귀하는 경향이 있다는 것을 알 수 있다. 그리고 블로그 호스팅을 급히 업그레이드 하지 않도록 시계열 예측 모델을 기반으로 의사결정을 했던게 꽤 유의미했다는 것을 알 수 있다.


누구든지 나와 같이 10년 넘게 블로깅을 해온 블로거의 경우도 트래픽 리셋을 하루동안 3번 이상 하게되면 이러한 트래픽이 어느정도 미래에도 계속 될 거라는 장미빛 환상에 빠지기 쉽다. 그래서 쉽게 추가 비용을 들여 호스팅 업그레이드를 하게 된다(실제 당시 콜센터 상담까지 받았으며 결재 직전까지 진행이 되었었다). 사람의 결정이라는게 이렇게 비 과학적이고 즉흥적일 가능성이 농후하다는 사실을 다시금 느끼게 해줬던 매우 좋은 사례였고, 따라서 개인적으로도 매우 흥미롭고 의미있었던 분석이었다.

데이터 분석가의 KPI 그리고 소프트웨어 개발자의 KPI

약 9년의 소프트웨어 엔지니어 생활에서 데이터 분석분야로 업무 분야를 바꾼 뒤 약 3년 정도의 시행착오 끝에 현재 데이터 분석가로 탈바꿈을 했고, 어느정도 안정궤도에 올랐다는 생각이 들어 관련 내용을 정리하고자 이렇게 글을 써본다.

“데이터를 분석한다”

많은 사람들이 위 문장을 사용하고 인식하는데 매우 큰 차이를 보이고 있다. 단순히 데이터 전처리 및 단어 카운팅을 하는것을 분석행위라 하는 것 부터, 시각화, 고급 모델링 및 통계분석 추론하는 행위까지 포함하고 있는 문장이기 때문이다. 이 때문에 데이터 분석가라는 직업 자체가 매우 폄하되거나 과대 포장되는 경우가 상당히 많을 것으로 생각된다. 하지만 이 글에서는 “분석한다”라는 의미는 “의사결정에 도움이 되거나 자동화를 위해 데이터에서 통계적으로 유의미한 정보를 추출하는 행위”로 정의하도록 하겠다.

이런 이유 때문에 다수의 소프트웨어 개발자들이 데이터 전처리를 하면서 간단하게 분석을 수행하기도 하고, 오히려 고급 통계분석이나 데이터마이닝을 업무에 적용해 스스로가 데이터 분석가로 거듭나는 사람들이 종종 있다. 반면에 데이터 분석가로 탈바꿈 하고 싶지만 그렇게 하지 못하는 소프트웨어 개발자들도 많이 봐왔다.

소프트웨어 개발자에서 데이터 분석가로 성공적으로 업종 변경을 하는건 경험자의 한사람으로 봤을때 그리 간단한 문제가 아니다. 흡사 오랫동안 오른손을 주로 사용해서 조각을 해온 사람에게 왼손만 사용하게 하는 것과 같은데 예외 사항으로 조각을 위한 도구를 만들때는 오른손을 사용하게 해서 필요한 다양한 도구를 만드는 시간을 단축할 수 있게 하는 상황과 매우 유사하다.

변신을 위해 몇가지 유념해야 될 사항이 있다.

  1. 그동안 주력 기술과 경력을 쌓았던 소프트웨어 개발 능력이 앞으로는 주력이 되서는 안된다. 이걸 너무도 잘해 계속 성과로 내세우다가는 영영 데이터 분석 업무로 갈 수 없다.
  2. 소프트웨어 개발은 본인의 분석 업무를 매우 쾌적하게 만들어줄 환경과 빠른 분석을 위한 보조 수단으로 활용한다.
  3. 데이터 분석가의 KPI와 소프트웨어 개발자의 KPI는 다르다.

위 세번째 항목이 매우 중요한데, 데이터 분석 업무의 궁극적인 목적은 의사 결정을 위한 유의미한 정보 발견이다. 이는 특정 기능을 하는 소프트웨어를 제작하는 행위가 목적인 소프트웨어 개발과는 매우 다른 목적이다. 몇몇 이를 혼동해서 특정 기능을 수행하는 통계 알고리즘을 직접 구현하는데 80%의 시간을 소모하고 20%의 시간을 데이터 분석에 할애하는 개발자들이 종종 있는데, 이는 데이터 분석 업무에서는 도박행위하고 같다. 이 행위는 필자도 수년전 직접 시행착오를 했던 부분인데, 그당시 Neural Network를 Erlang이라는 언어로 직접구현(노드를 worker로 할당해 학습을 분산시키는 개념)하고 데이터 분석을 하고자 했는데, 알다시피 Neural Network와 같은 데이터를 입력으로 받고 데이터로 모델링을 하는 학습 알고리즘의 경우 디버깅이 매우 어렵다. 게다가 Neural Network 자체가 블랙박스 모형이라는 점도 큰 장애물로 작용을 했다. 이렇게 80% 이상의 프로젝트 시간을 구현에 허비하고 남은 20%의 시간만 실제 데이터 분석에 투자하는 과오를 범하고 말았다. 결국 프로젝트는 앞으로 이렇게 하지 말아야 겠다는 교훈만을 남긴채 실패하고 말았다.

이 당시 나는 개발자적인 만족감에 도취되 Erlang언어로 Neural Network를 직접 구현하는 만행을 저질렀다. 이런 만족감 이면에는 통계분석의 경험 부족을 개발 결과물로 어느정도 보완하고자 하는 무의식적인 의도가 있었던 것이 아니였을까 회상해 본다. 이 당시 부족한 경험과 실력이지만 그당시 가능했던 통계분석 방법으로 데이터 분석 목적 달성을 위해 노력했다면 어땠을까 하는 생각을 가끔씩 해보기도 하나 개발자에서 데이터 분석가로 가기 위해 어느정도 피할 수 없는 시행착오가 아니였을까 하는 생각이 들기도 한다.

데이터 분석을 하는데, 소프트웨어 개발 기술 및 이해정도는 요즘같은 시기에 매우 큰 힘이된다. 하지만 데이터 분석의 KPI를 잊은채 소프트웨어 개발 결과물을 내세우고 싶은 유혹 또한 있기 마련이다. 이런 유혹을 떨칠 수 있는 사람만이… 다른 능력이 있더라도 데이터 분석 업무의 시행착오를 묵묵히 견뎌낼 수 있는 사람이 데이터 분석 업무로 성공적인 안착을 할 수 있다고 생각한다. 물론 데이터 분석 KPI를 달성하기 위해 새로 습득해야 될 지식과 경험이 생각보다 매우 많다는 함정이 있지만 말이다.

흥미롭게도 소프트웨어 개발과는 다르게 데이터 분석에서 소프트웨어 혹은 코드조각은 그저 중간 결과물에 지나지 않는다. 한번의 분석을 위해 수백라인의 R코드를 작성하지만 분석 결과가 무의미 하다면 코드는 쓰레기통에 들어가고 만다. 코드가 가치가 있으려면 데이터 분석 결과가 유의미 해야되고 이를 배치잡으로 동작시킬 필요가 있을때 비로소 분석 코드가 소프트웨어로 되살아날 기회가 생긴다. 따라서 분석과정에서는 개발과정과 같이 심혈을 기울여 최적화된 코드를 미리 작성할 필요가 없으며 이미 존재하는 알고리즘을 재구현할 이유도 없는 것이다. 프로토타이핑을 하듯이 데이터 분석코드는 작성할 필요가 있고, 이미 존재하는 알고리즘은 사용과 해석에 필요한 지식을 습득하는데 투자를 하고 가져다 쓰는게 가장 좋다. 이는 데이터 분석 및 모델링에 ‘은제탄환(Silver Bullet)’이 존재하지 않기 때문이며, 목적에 맞는 탄환을 빠르게 찾아서 선택사용하는게 데이터 분석 KPI를 달성하는데 가장 좋은 접근방법이기 때문이다.

“직접 만들지 않고 이렇게 가져다 쓰기만 하면 내가 얻는게 뭐가 되나요?” 하고 소프트웨어 개발자 관점의 질문을 할 수 있다고 생각하는데, 데이터 분석을 하다보면 해석과 추론을 위해 알아야 될 통계지식이 너무도 많이 요구된다. 그 지식을 실무에 적용 시키는 훈련이 곧 학습이 되고 경험이 되는 것이다. 흥미롭게도 위와 같은 질문 자체가 아직 소프트웨어 개발의 KPI에서 벗어나지 못했다는것을 의미하기도 한다.