요즘에 Tree 계열 알고리즘 많이 사용한다.

randomForest로 부터 데이터 확인 용으로 자주 사용하는 CART 알고리즘 그리고 오늘 처음 본 Conditional Inference Tree까지..

ML알고리즘의 경우 은총알은 없다. 사용 목적에 맞으면 그게 장땡인거다. 게다가 사실 빅 데이터를 가지고 분석을 한다면 내부가 블랙박스로 되어 있어서 어떻게 돌아가는지 안보이는 알고리즘 보다는 투명한 Tree 계열 알고리즘이 더 낫다고 생각한다. 만일 모델 빌드에 실패 하더라도 왜 실패하는지 그리고 어떤 방향으로 나아가야 되는지 룰을 보고 확인 가능하기 때문이다.

Conditional Inference Tree는 통계학적인 가설검정의 기법이 가미된 트리로서 각 노드에 유의수준값이 표시된다. 뭐 통계학 개론 정도 보신 분들이라면 이게 어떤걸 의미하고 왜 노드에 이런게 있는지 짐작을 하실거라 생각한다.

특정 유의수준 이상으로 허용을 하지 않는 선에서 트리는 자라게 되고 대부분 0.05 유의수준을 기준으로 하니 overfitting이 되는 경우는 그다지 없을 것이다.

재밋는 사실은 이 알고리즘이 들어있는 R 패키지에서 이 ctree(Conditional Inference Tree)를 가지고 randomForest 알고리즘을 구현하고 있다는 것이다.

ctree로 모델링 된 객체를 가지고 플로팅을 해보면 이런 아주 우아한 그래프가 그려진다.

내가 본 트리 그래프 중에서 가장 명료하고 많은 정보를 가진 그래프가 아닐 수 없다.

이런 플로팅은 자체가 데이터이자 정보이다.

하루하루 R 패키지 가지고 사용하는 재미로 보내고 있는데, 이런걸 만드는 분들의 노고에 심심한 감사의 표현을 전할 뿐이다.

요즘 여러 기고 요청을 받고 인터뷰를 받아서 개인적으로 고민하고 경험했던 부분들에 대해서 정리할 기회가 있었다.

물론 가장 큰 화두인 빅 데이터에 대한 것이다.

일단 빅 데이터 화두의 중심에서 실무를 하고 있는지라, Bias되어 있는 의견을 보일 수 있겠으나 블로그에서는 항상 내 생각만을 공유해 왔으니 한줄 써보련다.

사실 빅 데이터를 가지고 가치를 내는 분들은 오래전부터 우리 주변에 있어온 사람들이다. 특히 검색 엔지니어들은 빅 데이터를 다루고 이들에 대한 랭킹을 효과적으로 하면서 이를 광고 수익과 연관짓거나 고객에게 정보를 빨리 가져다 주게끔 만들어 준다. 따라서 데이터 사이언티스트들에 가장 가까운 사람들은 바로 검색 엔지니어라도 자신있게 말할 수 있다.

이분들 일하는 거 보면 굉장히 큰 대량의 문서에서 색인어를 뽑고 이를 특화된 DB에 넣는다. 그런데 데이터가 크기 때문에 굉장히 많은 예외 상황이 발생한다. 이들에 대한 예외 처리 그런것을 효과적으로 하기 위해 많은 분들은 이런저런 스크립트 언어로 필터링을 하곤 한다. 일단 색인에 들어가면 랭킹 튜닝을 하기 시작하는데, 여기에 기계학습 기법이 주로 들어간다.
빅 데이터 전처리 -> 분석의 과정, 빅 데이터 처리를 하면서 거치는 작업 프로세스가 하고 차이가 없다.
사실 이렇게 되어보니 어찌보면 검색 서비스가 빅 데이터의 가장 좋은 예라고 볼 수 있을 것이다. 하지만 누구도 그런 이야기는 하지 않았다. 있던것이 부각되는건 임펙트가 없기 때문이다.

사실 빅 데이터의 최종 목적은 데이터에서 가치를 뽑는 것이다. 가치는 결국 분석을 통해서 이뤄지고 분석은 분석가의 손끝에서 완성이 된다. 따라서 플랫폼이 중심이 아니라 사람이 중심이라는 이야기다.

사실 웹 2.0의 경우도 빅 데이터와 종착점은 같다. 웹 데이터를 활용해 지능적인 웹 서비스를 만들어서 사용자에게 기쁨을 주자는게 목적이다. 하지만 어떤가?… 지금 우리 주변은 웹 2.0 바람이 남기고 간 흔적은 고작 Ajax뿐이다. 아마존의 지능적이고 개인화된 웹 서비스는 남의 나라 이야기가 되버렸다.

5년 전에 세상을 떠들썩하게 한 CRM, 데이터 마이닝 붐의 결과로 남은건 밴더들의 플랫폼 뿐이다. 이들 역시 핵심은 데이터에서 가치를 찾아내자는 것이였으나 거품이라고 이야기 하는 사람들이 현재로서는 더 많다. 그러나 그 거품은 플랫폼에 대한 기대의 거품이다.
분석을 하는 사람….분석을 기반으로 한 의사 결정 문화의 가치가 더 중요한 부분이였으나 그렇게 끝이 났다.

10년 가까이 IT 트랜트 핵심 가치는 데이터였고, 그것의 가치를 발굴하자는게 공통의 목적이였다. 하지만 빅 데이터든 뭐든 분석을 하는 사람들의 손끝의 가치는 부각이 된 적이 거의 없었다. 단어만 바뀌어 다른 것처럼 인식되어왔다. 웹 2.0에서는 그런 일을 하는 사람은 개발자였고, 데이터 마이닝 시절은 데이터 분석가, 빅 데이터 시대는 데이터 사이언티스트다.
잘 생각해보면 개발자와 데이터 분석가를 합쳐놓은 사람이 데이터 사이언티스트이다. 달라 보이지만 전혀 다른 사람들이 아니라는 이야기다.

분석을 하는 사람도 엇비슷하고, 추구하는 가치도 엇비슷하고 고작 단어만 바꿔서 밴더들은 툴을 팔고 있다. 분석을 하는 사람들의 가치…그리고 데이터의 가치에 대한 소고조차 없이 말이다.

개인적인 소망은, 금번 빅 데이터 붐으로 인해 플랫폼이 아니라 데이터의 가치를 다시 한번 생각하는 계기로 만들어야 된다고 생각한다. 그렇지 않고서는 빅 데이터는 또 다른 단어로 옷을 바꿔 입고 우리에게 꼬리를 치게 될 것이다.

내 트위터에는 394명의 팔로워가 존재한다. R meetup 발표준비를 핑계로 팔로워와 팔로잉간의 플로팅 몇 개를 그려 봤다.

아래 작업을 위해서 twitteR, ROAuth ggplot2 패키지를 사용했고, 관련 코드는 meetup 이후에 공개하겠다.

이미지를 클릭하면 좀더 자세히 볼 수 있다.

참고로 점의 크기는 트윗수를 의미한다.

소셜캐스터, 오마이뉴스, 임성길 분의 트위터와 같은 엄청난 팔로워들과 팔로잉을 가지고 계신 분들 때문에 많은 분들이 그래프에서 보이질 않는다.

재밋는 사실은 임성길님의 트윗의 경우 본인이 팔로잉 하는 사람들이 팔로워들의 숫자만큼 많은걸 볼 수 있는데, 오마이 뉴스나 SKT 트위터는 그런 경향이 없다. 게다가 권정혁/구루 님의 트위터도 역시 그렇다. 아마도 이런분들의 트위터는 사람들이 정보를 얻기 위해서 팔로잉 하는 경우가 많아서 그런게 아닐까 예상해 본다.

자세히 보기 위해 20000팔로워 아래의 분들만 따로 보자!

좀 더 자세히 보기 위해 6만 팔로워 아래 분들만 보자!

적합된 라인을 해석해 보자면 1000팔로워 아래 분들은 주로 본인이 팔로잉 하는 숫자가 대체적으로 본인을 팔로우하는 숫자들보다 많은 경향을 보인다.

과도한 억측일지 모르지만, 이런 경향을 보이는 분들은 정보 생산의 트위터러라기 보다는 정보 소비의 트위터러일 가능성이 많아 보인다.

게다가 꼭히 트윗을 많이 날린다고 팔로워들이 꼬이는 것도 아니라는 걸 알 수 있다.

이걸 보니 팔로잉 하는 사람이 적으면서 팔로워들이 많고, 게다가 트윗 량도 고만고만한 트위터러가 정보성 있는 트윗을 날리는게 아닐까 생각해본다. 예를 들어 “추천 책 정보”

내가 속해 있는 1000 팔로워 아래는 거의 춘추전국 시대구나…

참고로 내 팔로워들만 볼 때 팔로워들의 숫자와 팔로잉의 숫자의 상관관계는 0.80에 육박했으며 이를 볼 때 뭐가 먼저인지 모르겠지만 할 수 있는 한 열심히 팔로잉 하는게 그나마 팔로워들을 많이 모을 수 있는 방법이 아닐까 생각해본다.  그리고 트윗량과 팔로워 숫자의 상관관계는 0.40정도로 양의 상관관계지만 꼭히 트윗이 적다고 팔로워들이 적게 오는 것은 아니다. 적은 트윗으로도 사람을 모으는 트위터러를 찾아보는 알고리즘을 만들어 보는 것도 재미있을거 같다는 생각을 해본다.

R로 트위터 분석 하는 과정 소개를 하는 세션을 준비하다가 그려 봤는데 보다가 시간 가는줄 모르겠다.  ㅎㅎ

최근에 ggplot2로 플로팅을 많이 하면서 어떻게 하면 선명한 이미지를 얻어볼까 고민을 조금 했다. 그러다 DPI라든지 픽셀, 도트 같은 웹디자이너 분들이나 다룰 만한 지식을 섭렵하기에 이르렀는데, 결국 컴퓨터 화면에서는 고 해상도가 아닌 이상 플로팅 결과의 차이는 거의 찾아볼 수 없다는 게 결론이다. 그러나 그래프 이미지는 발표자료 같은 곳에서 사용될 수 있고, 이때 이들에서 최적의 해상도로 보여진다면 더 효과적인 발표가 될 것이다.

일단 간단한 예로 지난 포스팅의 결과를 가지고 테스트를 해보도록 하겠다.

지난 포스팅의 그래프를 72DPI의 결과와 600DPI의 결과의 이미지로 출력한다(R은 기본이 72DPI이다).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

library(ggplot2)
 
blogstat <- read.table("SingleFeedStats.csv" ,sep=",", header=T, stringsAsFactors=F)
 
blogstat$Date <- as.Date(blogstat$Date, "%m-%d-%Y")
 
gg1 <- ggplot(blogstat, aes(Date,Subscribers)) + geom_line(aes(colour=Hits))  + xlab("날짜") + ylab("구독자") + 
  scale_color_continuous(name="히트", low="yellow", high="black", guide = guide_legend(reverse=TRUE)) + scale_x_date(breaks ="6 month")
 
gg1
 
tiff(file = "1nd.tiff",width = 648, height = 288, units = "px",type="cairo", family="PKS Bukul", antialias="subpixel" ,compression="lzw")
gg1
dev.off()
 
 
tiff(file = "2nd.tiff",width = 5400, height = 2400, units = "px",type="cairo", res=600,family="PKS Bukul", antialias="subpixel", compression="lzw")
gg1
dev.off()

1nd.tiff 파일은 648/72(9) inch X 288/72(4) inch 의 이미지 파일을 출력하고,

2nd.tiff 파일은 5400/600(9) inch X 2400/600(4) inch 의 이미지 파일을 출력한다.

모두 프린트시 9 X 4 inch의 파일을 생성하나 해상도는 차이가 있다. 이들의 차이점을 간단하게 테스트 하기 위해서 pdf 문서로 이미지를 출력 한 후 비교를 해본다.

문서를 72% 확대 후 비교해 보면 아래와 같이 별 차이가 없으나…

100%로 문서를 비교하게 되면 아래와 같은 차이가 보인다.

주로 발표할 때  한글과 컴퓨터의 한쇼를 쓰는데(정품을 가지고 있다는 이유 하나만으로…), 이 한쇼에서는 메뉴얼에 명시되지 않았지만 600DPI 이미지를 기본 사용하는 것으로 알고 있다. (이 부분은 이미지를 로딩해보고 상세 항목에서 이미지 크기를 확대/축소하지 않은 크기를 확인하면 알 수 있다)

R로 그래프 플로팅을 한 결과를 고품질 이미지로 프리젠테이션에 넣는다면 발표시 그리고 그 발표자료를 출력한 핸드아웃을 만들 때 그래프의 퀄리티는 차이가 날 것이다. 단 프린터의 경우 600DPI가 많지만, 프로젝터의 경우 그렇지 않은 경우가 있으므로 발표용 자료는 각자의 테스트가 필요할 거라 생각한다. 물론 내 경우는 모든 데이터 플로팅 결과는 600DPI다. 왜냐면 그래프는 라인이 만들어내는 Art의 한 종류이고 청중에게 가장 정확하고 명료하게 전달될 필요가 있는 중요한 개체이기 때문이다.

그리고 여담이지만 anti-aliasing 옵션은 요즘엔 필수다.

구글 피드 버너에서 이 블로그에 대한 통계 데이터 csv 파일을 다운받아서 ggplot2로 플로팅 해봤다.

아래 보면 2010년 중반의 갑작스런 구독자 감소는 데이터 누락인지, 아니면 많은 RSS 리더기 업체가 서비스를 중단해서 그런건지 모르지만 결국 구글 리더가 흡수했는지 전체적인 증가 추세에는 큰 영향이 없는걸로 보인다. (아주 짧은 주기의 상승 하강이 있는데, 이런 것을 보니 평활화를 해야 겠다는 생각이 들지만 일단 의미 없으니 패스! )

재밋는 사실은 순수한 검색 기반 데이터 분석에 대한 글을 많이 쓸 때 방문자들의 Hit수가 가장 많았다는 것을 알 수 있다. 하지만 R관련 데이터 분석 관련 글을 쓰는 요즘은 그다지 Hits수가 높지는 않지만 최근 4년 동안의 패턴을 볼 때 지속적인 구독자 상승 추세를 보이고 있다는 것을 알 수 있다.  

이미지를 클릭하면 더 상세한 내용을 볼 수 있다.

이 블로그는 개인적으로 느끼고 공부한 것들 그리고 그런 모든 경험을 기반으로 새로운 아이디어나 창조를 하는 고민의 정리물이다. 누굴 위해서 쓴 것도 아닌 그 어떤 다른 불순한 목적도 없어서 아마도 이 블로그가 오랫동안 생존해 온것 같다.

블로그를 운영하면서 “텍스트로 무언가를 정리”하고 “누군가에서 설명하는 과정” 이 자체가 배움의 결과를 가장 확실하게 확인할 수 있는 방법이라는 사실을 누구보다 확실하게 알 수 있었다.  

빅 데이터 시대에 데이터 사이언티스트의 요구 능력이 뭔지 정말 알고 싶다면 빅 데이터 분석 프로젝트를 직접 해보면 된다. 경험해보면 Linux 기반의 데이터 핸들링이 왜 중요하고. Hive, Hadoop이 왜 중요하며, R이 왜 중요한지 알게된다.

통계 전공이나 산업공학 전공하신 분들은 CS쪽 경험이 부족해 어려움을 겪는 걸 많이 봤고, CS 전공 분들은 통계학적인 지식이 부족해서 고생하시는 것을 많이 봤다. 통계, CS 둘중에 어느쪽이 배우기 쉽냐고 물어보신다면, 답변드리기 어렵지만, 빅 데이터 분석에서의 활용도는 CS 기술 쪽이 지식이 좀 더 많은것을 요구한다는 것은 사실이다. 왜냐하면 데이터 마이닝의 70% 이상을 차지한다는 데이터 전처리에서 이 70%의 소요 시간을 획기적으로 줄일 수 있는 가장 빠른 기술은 바로 CS이기 때문이다.

물론 마지막 고지에 깃발을 꽂는 기술은 통계, 마이닝 기술이지만..

전반적으로 고달프고 힘든 작업이다… 이 빅 데이터 분석..

UseR! 2012에 abstract를 제출했다는 이야기를 했었는데, 그 결과를 금주 초에 받게 되었다. 결과는 예상했던 대로 accept…

Text Mining을 이용한 SNA인데.. 이 발표의 abstract를 제출한 이유는 일단 회사에서 해외 발표를 할 경우에는 출장 형식으로 지원을 해준다는 것이 컸고 이번 기회를 빌어서 메일로만 이야기 했던 분들하고 안면을 좀 트고.. 첫날에 있을 Tutorial 세션에서 좀 배워보고자 하는 욕구가 컷다.  물론 회사 제품인 RHive에 대한 지원 및 설명도 적극적으로 준비해가서 해야 한다.

일단 일이 이렇게 되었고, 출장 준비해서 잘 참석하고 와야겠다. 무엇보다 금번 출장에서 또 누굴 만나고, 어떤 것을 배워 올지 사뭇 기대가 된다.

그럼 6월 Nashville, Vanderbilt University에서 ….

최근 rjson이 업데이트 되었는데, 정말 기다리고 기다리던 CJK 인코딩 문제가 해결되었다. 그래서 이것을 활용하는 twitteR 패키지에서 이젠 정상적으로 한글이 나오게 되었다.  이 패키지를 활용하면 트위터 팔로워들 그리고 내가 팔로잉 하는 사람들의 정보를 가져와서 분석할 수 있고, 이 밖에도 그들 각자의 트위터 문장을 분석할 수 있다.

비로소 KoNLP가 가장 많이 활용될 수 있는 패키지가 이제 정상화 된 것으로 볼 수 있다.

이것을 가지고 간단하게 나를 팔로잉하는 사람들의 자기소개를 분석해서 어떤 사람들이 나를 팔로잉하는지 확인해보고 이를 기반으로 내가 어떤 성격의 트윗을 주로 날렸는지 간접적으로 유추해 볼 수 있을 것이다. 한마디로 내가 한 말들로 인해 어떤 사람들이 나를 팔로윙 하는지 알아보자는 것이다.

코드는 아래와 같다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

library(twitteR)
library(KoNLP)
library(wordcloud)
library(tm)
 
# gogamza <- userTimeline(user="gogamza", n=1000)
# 
# gogamzatw <- c()
# for(i in 1:length(gogamza)){
#   gogamzatw <- append(gogamzatw, gogamza[[i]]$text)
# }
# 
# gogamzaNoun <- sapply(gogamzatw, extractNoun,USE.NAMES=F)
# 
# gogamza.corpus <- Corpus(VectorSource(gogamzaNoun))
# 
# control <- list(stopwords=T, removePunctuation = T, removeNumbers=T, minDocFreq=2)
# tw.tdm <- TermDocumentMatrix(gogamza.corpus, control)
 
 
gogamza <- getUser("gogamza")
#gogamza.friends <- gogamza$getFriends()
#gogamza.friendsID <- gogamza$getFriendIDs()
gogamza.followers <- gogamza$getFollowers()
 
 
#팔로워들의 자기 소개를 벡터에 적재 한다. 
followerDesc <- c()
 
for(i in gogamza.followers){
  followerDesc <- append(followerDesc, i$description)
}
 
 
#쓸모없는 문자들을 제거한다. 
followerDesc <- gsub("\n","", followerDesc)
followerDesc <- gsub("\r", "", followerDesc)
 
 
nouns <- Map(extractNoun, followerDesc)
 
wordsvec <- unlist(nouns, use.name=F)
#쓸모없는 문자들을 제거한다. 특히 영문자의 경우 tm의 stopwords를 활용한다. 
wordsvec <- wordsvec[-which(wordsvec %in% stopwords("english"))]
wordsvec <- gsub("[[:punct:]]","", wordsvec)
wordsvec <- Filter(function(x){nchar(x)>=2}, wordsvec)
 
wordcount <- table(wordsvec)
pal <- brewer.pal(8,"Dark2")
 
 
wordcloud(names(wordcount),freq=wordcount,scale=c(4,0.5),min.freq=10,
          random.order=T,rot.per=.1,colors=pal)

이렇게 나온 워드 클라우드는 아래와 같다.

나를 팔로잉 하는 분들이 내가 트위터에서 어떤 의미인지 해석해 보자면,

“IT개발자이며 정보나 웹, data에 관심있는 엔지니어…”

맞는 이야기다…쩝

나 말고 정말 많은 팔로워들이 있는 @gaiaville 님의 경우 아래와 같다.

CEO란 단어도 있고, 소셜 그리고 엔지니어 SNS, 자바, 데이터, 검색 등등이 있다.

물론 이 그림을 보고 해석은 각자 나름대로 할 수 있을 것이다.

혹여나 트위터에서 어떤 사람의 성향을 바로 알고자 한다면, 위 코드에서 상대방 아이디만 넣어보면 대략 알 수 있지 않을까 한다. 원작자로서 다만 타인의 뒤를 캐는데 코드가 활용되지 않길 바랄 뿐이다.  ㅋ  

굉장히 유명한 트위터러에 대한 정보를 알고자 한다면 팔로워들을 분석하기 보다는 트위터러의 엑티브한 행동의 결과인 트위터러가 팔로잉하는 사람들의 자기소개를 분석해 보는게 더 효과적일지도 모르겠다.

외근, 몸살에 시달리면서 준비한 발표자료로 3회 R meetup 발표를 했다.

금번 모임 주제는 시각화(visualization)였으며, ggplot2를 살펴보는 와중에 전에 링크드인 분석가가 했던 이야기 “"Visualization is more important than you think."가 계속 머리속에 맴돌았다. 데이터 분석에서 생각보다 중요한 것…. 시각화…

국내 R 사용자를 위해 R meetup을 하자고 처음 제안한 이후에, 생각해보니 2회만 제외하고 모두 발표를 했다. ^^;

최근에 ggplot2를 사용해서 플로팅 하는 분들이 해외에서 늘어나고 있고, R관련 책에서 묻지마 활용을 하는 만행을 하는 몇 가지 패키지 중에 하나로 손꼽히는 ggplot2에 대한 내용이다.

처음에는 ggplot2의 튜토리얼을 하고자 했는데, 청중의 수준을 예상할 수 없을 뿐더러, 시간도 너무 오래 걸릴 듯 해서 소개와 몇몇 활용 예제에 대해서 발표를 했다. 이 발표를 하면서 살짝 언급한 The Grammer of Graphics에 대해 관심이 급 생겼다.. Object Oriented Design… 얼마나 멋진 개념인가?

ggplot2를 하면서 가장 명확하게 느낀점은 흡사 OOP 프로그래밍을 하는 느낌을 받았다는 것이다. 요망하는 시각화(구현)를 하기 위해 컴포넌트를 만들고 이들을 배치하는 과정 자체가 프로그래밍의 그것과 흡사했다. 

발표자료 다운로드 : Hello ggplot2

앞으로 좀더 많은 깨달음을 얻는다면 좀더 고수준의 개념들을 이야기 할까 한다.

최근에 KoNLP가 업데이트 되었으며, 업데이트 내용은 아래와 같다.

Version 0.7
------------------------------------------------------------------------------
  * new dictionary added which from Sejong projects
  * added example
  * Set "dontrun" on example code because Windows encoding problems.
  * Warning message may appear if system doesn't have Hangul encoding ability(no warning on UTF-8).

Version 0.0-9.3
------------------------------------------------------------------------------
  * added user dictionary manage functions.
  * to -Xmx1024m for big dictionary size
  * supports JRE 1.5

버전명을 이렇게 한꺼번에 크게 올린 이유는 0.1도 안되는 버전이라 사용자들이 생각해 오류가 있을거라고 예상할 염려가 있어서이다. 사실 버전은 1.0이 되어도 무리가 없을 정도로 완성도는 있다고 생각한다.

금 버전의 가장 큰 변화는 외부 사전 파일을 가져와 형태소 분석기에 올릴 수 있는 인터페이스를 제공한다는 것이다. 이에 대한 대부분의 내용은 아래 예제 코드 몇줄로 설명이 된다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

## This codes can not be run if you don't have encoding system which can en/decode Hangul(ex) CP949, EUC-KR, UTF-8).
dicpath <- paste(system.file(package="KoNLP"), "/dics/data/kE/dic_user2.txt", sep="")
newdic <- read.table(dicpath, sep="\t", header=FALSE, fileEncoding="UTF-8", stringsAsFactors=FALSE)
 
 
 
## backup merged new dictionary
backupUsrDic(ask=FALSE)
 
mergeUserDic(newdic)
 
## restore from backup directory
restoreUsrDic(ask=FALSE)
 
## reloading new dictionary
reloadAllDic()

현재 배포 버전에서는 세종계획에서 배포한 전자사전 파일에서 현재 사용자 사전과 시스템 사전이 없는 일반명사 단어들만 추가한 파일을 포함하고 있다. 따라서 위의 예제는 이 파일에 접근해 현재 사용자 사전을 백업하고 이후 파일을 머지하여 새로운 사전 파일을 만들고 백업파일로부터 예전 파일을 복원하는 일련의 과정을 보여준다. 그리고 마지막에 사전 파일이 바뀌었을 경우에 따른 재로딩 명령을 해주는 명렁어를 불러줬다.  

따라서 현재 KoNLP0.7에 들어있는 세종계획 명사 사전을 사용하고 싶다면 아래와 같은 명령어 시퀀스를 사용하면 된다.

1
2
3
4
5
6
7
8

dicpath <- paste(system.file(package="KoNLP"), "/dics/data/kE/dic_user2.txt", sep="") 
 
newdic <- read.table(dicpath, sep="\t", header=FALSE, fileEncoding="UTF-8", stringsAsFactors=FALSE)
 
backupUsrDic(ask=FALSE)
 
mergeUserDic(newdic) 
reloadAllDic()

이렇게 실행하면 기존 사용자 사전에 새로운 사전이 추가되어 분석을 할 수 있게 된다.

만일 사용자분들이 직접 수정한 단어 사전이 있다고 하면 “단어<TAB>tag” 형식의 파일을 준비해 위 명령어를 참고로 사전을 추가해 주면 된다. 자동으로 인코딩을 맞춰 주기 때문에 위 인터페이스를 사용하는게 인코딩에 대한 지식이 없는 사용자들이 무리없이 KoNLP를 활용하는 길이라 생각한다. 물론 인코딩 지식이 있으신 분은 직접 편집해도 된다.

위 코드를 올리기 위해서 많은 시행착오가 있었다. 일단 윈도우 시스템에 한글 코덱이 없는 경우 그러니까 일반적인 영문 윈도우의 경우 예제 코드를 돌리면서 에러가 났었는데, 이 때문에 윈도우 빌드파일 생성이 늦어졌었다.

라이브러리 로딩시 한글 인코딩 기능이 없다면 패키지 시작 메시지로 관련 메시지를 보여주고, 예제 코드를 검증하는 절차를 건너 뛰는 걸로 해결했다. 이렇게 해결을 하게 된 이유는 R 시스템 그리고 윈도우만의 특징 때문이였다. 자바처럼 인코딩에 맞게 한글 파일을 읽어 들이면 내부적으로 유니코드 형태로 유지하면 되는데, R의 경우 인코딩에 맞게 파일을 읽어 들어더라도 내부적으로 로케일 캐릭터 셋으로 데이터셋 유지를 해 윈도우 기본 로케일에 따른 인코딩에 한글이 빠져 있다면 에러가 나버리는 것이다. 이는 R로 텍스트 마이닝을 하는 초심자들에게는 편한 장점이 있는 반면에 라이브러리의 유연성은 떨어져 개발자가 골치하퍼지는 경우가 되겠다.

하여튼 일단 KoNLP 라이브러리로 분석을 하기 위해서는 리눅스, 맥의 경우 UTF-8 환경을 추천하고, 한글 윈도우가 아닌 윈도우는 피하길 추천한다.