Posted by & filed under Data mining.

오다카 토모히로의 만들면서 배우는 기계학습에 나오는 예제를 여러가지 도구로 각각 간단히 선형회귀(Linear regression)을 하는 방법을 적어봅니다.
(이 정도는 뭐로 하든 한가지만 잘해도 충분한겠습니다만)
선형회귀는 간단히 설명하면 독립변수 X에 대한 종속변수 Y의 값들을 이용해 제곱합이 최소가 되도록 하는 1차식을 도출하는 방법입니다.
예측을 하거나 추이를 살펴보기 위한 방법으로 가장 쉬운 방법 중 하나인데
보통 입력값은 X값들, Y값들이고 출력은 절편(Intercept)과 기울기(Slope)이고 추가로 몇가지를 더 도출할 수도 있습니다.
최소자승법으로 결과를 구하기 위해서 1차식을 제곱합을 구하는 것으로 바꾼다음 각 항을 편미분해서 나온 식에 입력값들을 대입해서 절편과 기울기를 구하게 됩니다.
식은 구글에서 검색해 보시거나 책들을 참조하시면 되겠습니다.

C로 하는 Linear Regression

C로 구현한 예제는 scanf를 이용해서 입력값을 키보드로 입력받고 절편과 기울기로 바로 출력하는 간단한 예제입니다. 책에 있는 예제 그대로입니다.

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
#include
#define TEXTLENGTH 4096

int main() {
char text[TEXTLENGTH];
double xi, yi;
double sxi = 0, syi = 0, sxiyi = 0, sxi2 = 0;
double a0, a1;
int n = 0;

// 데이터입력
while (fgets(text, TEXTLENGTH, stdin) != NULL) {
if (sscanf (text, "%lf %lf", &xi, &yi) == 2) {
/* 변환 성공, 각 항 계산 */
sxi += xi;
syi += yi;
sxiyi += xi * yi;
sxi2 += xi * xi;
++n;
} else {
/* 변환 실패, 건너뛰기 */
fprintf(stderr, "바르지 않은 데이터입니다 : %s", text);
}
}

if (n > 1) {
/* 데이터가 2개 이상 있다 */
/* 계수 계산 */
a0 = (sxi2 * syi - sxiyi * sxi) / (n * sxi2 -sxi * sxi);
a1 = (n * sxiyi - sxi * syi) / (n * sxi2 - sxi * sxi);
/* 결과 출력 */
printf("%1f\n%1f\n", a0, a1);
} else {
fprintf(stderr, "데이터 부족합니다.\n");
}

return 0;
}

/* 입력 값들은 이렇게 넣고 구분은 X값과 Y값의 구분은 TAB으로 합니다.*/
// 1 2.1
// 3 3.7
// 2.5 3.4
// 3.9 3.1
/* 출력된 결과 입니다. */
// 2.010294
// 0.409502

R코드 및 플로팅

R은 이런것은 너무 쉽습니다.
데이터를 data.frame으로 만들어주고 lm을 이용해서 모델을 구한 뒤 화면에 결과를 출력하고 plotting 해버리면 끝입니다.
물론 plotting은 더 미려하게 할 수 있습니다만 정성과 시간이 필요합니다.

1
2
3
4
5
6
7
8
lsm.data c(1, 2.1),
c(3, 3.7),
c(2.5, 3.4),
c(3.9, 3.1)
))
colnames(lsm.data) m m
plot(lsm.data)
abline(m)
r_plot_lsm

Excel로 하는 선형회귀

Excel도 이런 간단한 것은 무척 쉽습니다. 값들을 sheet에 입력하고 마우스로 scatter plot을 차트에서 선택해서 quick chart를 선택하면 추이선이 그대로 그려집니다.
chart의 option에서 display equation을 선택하면 절편과 기울기까지 차트에 표시됩니다.
물론 절편과 기울기만 따로 구해서 식을 재적용하게 할 수 있겠지만 조금 복잡해 집니다.
lsm.xlsx

Datagraph로 선형회귀하기

Datagraph는 Mac에서 사용하는 작은 graphing 툴입니다. 가벼우면서도 싸고 괜찮고 아주 유용한 툴입니다.
Datagraph로 하는 방법은 엑셀과 비슷할 것인데 엑셀보다는 더 쉽습니다.
Datagraph에서는 data를 입력한 후 scatter plot을 그리고 fit function으로 linear를 선택해서 넣으면 그대로 나옵니다.

fit function에서 절편과 기울기가 구해져 있는 것을 알 수 있습니다.
다른 그래프 툴에서도 비슷할 것이라고 생각됩니다.

lsm.dgraph

Python으로 선형회귀하기

Python으로 하는 방법은 직접구하는 방법과 공학용 패키지인 scipy를 이용하는 방법이 있는데 이 scipy라는 패키지가 설치하기가 무척 어렵습니다.
scipy가 제가 사용하는 mac에 잘 설치가 되지 않아서 코드를 테스트를 해보지는 못했고 대략 아래와 같이 구하게 될 것 같습니다.

1
2
3
4
5
from scipy import stats
xvalues = (1, 3, 2.5, 3.9)
yvalues = (2.1, 3.7, 3.4, 3.1)
slope, intercept, r_value, p_value, std_err = stats.linregress(xvalues,yvalues)
print "Intercept: %f, Slope: %f" % (intercept, slope)

Posted by & filed under R.

R에서 ggplot2경제활동인구찍기를 해봤습니다.
사실은 다른 것을 플로팅해보려다가 원하는 자료를 다운로드 받는 것이 만만치 않아서
대충 지나가다가 통계청 데이터중에 처음 보는 것을 가지고 찍어본 것입니다.
우선은 데이터를 가져와야 합니다. 통계청에 가시면 여러가지 통계데이터를 제공하고 있습니다.
아래 사이트에 가서 경제활동인구동향데이터를 긁어 옵니다.
http://kosis.kr/feature/feature_0103List.jsp?mode=getList&menuId=03&NUM=180

CSV로 다운로드 받아서 해도 되겠지만 데이터가 크지 않으므로 그냥 소스코드에 집어넣기 위해서 copy&paste를 해버립니다.
사이트에서 바로 복사하면 컬럼간의 구분이 Tab으로 되어 있을텐데요.
편집기에서 제가 Tab문자를 쓰지 않아서 Tab을 모두 세미콜론(;)으로 바꿨습니다. 그리고 header를 month와 population으로 해서 column 이름을 아예 데이터에서 지정해버렸습니다.

코드는 아래와 같습니다.

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
economic_activity_population <- "month;population
2009.09;24,630
2009.10;24,655
2009.11;24,625
2009.12;24,063
2010.01;24,082
2010.02;24,035
2010.03;24,382
2010.04;24,858
2010.05;25,099
2010.06;25,158
2010.07;25,232
2010.08;24,836
2010.09;24,911
2010.10;25,004
2010.11;24,847
2010.12;24,538
2011.01;24,114
2011.02;24,431
2011.03;24,918
2011.04;25,240
2011.05;25,480
2011.06;25,592
2011.07;25,473
2011.08;25,257
2011.09;25,076
2011.10;25,409
2011.11;25,318
2011.12;24,880
2012.01;24,585
2012.02;24,825
2012.03;25,210
2012.04;25,653
2012.05;25,939
2012.06;25,939
2012.07;25,901
2012.08;25,623"

자 이제 data.frame으로 로딩합니다.

1
statdata <- read.table(file=textConnection(econonic_activity_population), header = TRUE, sep = ";", quote = "\"'", as.is=TRUE,colClasses=c("character", "character"))

그리고 나서
statdata$month 컬럼을 Date형식으로 바꿔줍니다. 그러지 않으면 나중에 곤란해집니다. 궁금하시면 직접해 보시구요.
년도와 날짜로만 되어 있는 문자열을 날짜형으로 바꾸기 위해서 강제로 01을 붙여서 그달의 첫째날로 바꿔버립니다.
그리고 바꿀때 타임존(tz)을 서울(Asia/Seoul)로 해줍니다. 안해주면 가끔 날짜가 UTC로 바뀌는 경우가 있습니다.

1
statdata$month <- as.Date(paste(statdata$month, ".01", sep=""), "%Y.%m.%d", tz="Asia/Seoul")

그리고 statdata$population을 숫자형으로 바꿔줍니다. 그런데 숫자데이터에 콤머가 있으므로 콤머를 다 제거해주고 숫자형으로 바꿉니다.

코드는 아래와 같습니다.

1
statdata$population <- as.numeric(gsub(",", "", statdata$population))

자 이제 플로팅을 해보죠. ggplot2를 로딩한 다음에 바로 찍습니다. ggplot2를 설치하지 않으셨으면 먼저 설치하셔야 합니다.

1
2
3
# install.packages("ggplot2") # 설치를 안했으면 먼저 설치부터...
library(ggplot2) # 로딩
ggplot(statdata, aes(x=month, y=population)) + geom_line()

플로팅한 그림은 아래와 같습니다.

나왔네요. 그런데 회색배경에 검은선이라 이쁘지 않네요.
선에 색을 넣어 봅니다.

1
ggplot(statdata, aes(x=month, y=population)) + geom_line(colour="blue")

조금 낫긴하지만 역시 허전합니다.
아래가 비어서 그런것 같으니 선을 그리지 말고 채우기를 이용해서 그려보죠.
사실 이런류의 데이터는 색을 채우지 않고 선으로 보는 것이 데이터를 보기에는 더 좋습니다만 누군가에게 던져 줄때는 예쁘게 출력하는 것도 중요합니다.
본인이 보는 그래프는 선으로 된 것이면 충분하지만 누군가에게 보여주는 그래프는 알록달록해야 합니다.

1
gplot(statdata, aes(x=month, y=population)) + geom_area()

찍었습니다. 그런데 어라? 그래프의 모양이 바뀐것 같습니다. 자세히 보니 Y축이 영역(range)가 바뀐것 같은데 그것 때문에 밋밋해진 것이군요.
geom_area는 기본적으로 Y축의 0값부터 채워 넣기 때문에 geom_line과는 다르게 반응합니다.
그래서 Y축의 레인지를 강제로 고쳐줘야 합니다. 밑부분의 넙다란 부분을 잘라서 없애버리는 것입니다.

1
ggplot(statdata, aes(x=month, y=population)) + geom_area() + coord_cartesian(ylim = c(23500, 26500))

그럴듯하게 나오네요. 그런데 여전히 색이 단조롭네요.
테두리의 선색과 채울때 쓴 색을 다르게 줘서 입체감을 조금 살려보죠. 조금 옅은 회색과 조금 진한 회색을 써보겠습니다.

1
ggplot(statdata, aes(x=month, y=population)) + geom_area(colour="gray10", fill="gray50") + coord_cartesian(ylim = c(23500, 26500))

조금 괜찮아졌습니다만 역시 흑백보다는 칼라를 넣는 것이 좋을 것 같네요.
삷이 우울해질것만 같습니다.
제가 좋아하는 보라색을 넣어봅니다.

1
ggplot(statdata, aes(x=month, y=population)) + geom_area(colour="gray10", fill="gray50") + coord_cartesian(ylim = c(23500, 26500))

유후~ 괜찮아졌네요.
자. 이제 대충 색은 되었고 나머지를 조금 더 손을 봐보죠.
Y축의 값은 단위를 천명으로 한 숫자입니다. 통계청 데이터의 설명에 그렇게 나와 있습니다.
원래 숫자대로 바꿔보죠. 값에 곱하기 1000을 해서 원래 숫자로 바꿉니다.
귀찮으니 이쯤에서 처음부터 데이터를 다시 로딩해서 바꿔버립니다. 기존 데이터에 그냥해도 무방합니다.

1
2
3
4
statdata <- read.table(file=textConnection(econonic_activity_population), header = TRUE, sep = ";", quote = "\"'", as.is=TRUE,colClasses=c("character", "character"))

statdata$month <- as.Date(paste(statdata$month, ".01", sep=""), "%Y.%m.%d", tz="Asia/Seoul")
statdata$population <- as.numeric(gsub(",", "", statdata$population)) * 1000

네 바꿨습니다. Y축 레인지를 조절하는 값도 1000을 곱해서 바꿔줘야 하는것을 기억하시구요.
이제 Y축의 레이블값의 숫자들에게 콤머를 찍어줍니다. 콤머를 찍으려면 scales 패키지를 로딩해야 합니다.

1
2
library(scales)
ggplot(statdata, aes(x=month, y=population)) + geom_area(colour="#5c0ab9", fill="#8a4fcd") + coord_cartesian(ylim = c(23500000, 26500000)) + scale_y_continuous(labels=comma)

이제 X축의 레이블들을 수정해봅니다. 2011-01 처럼 되어 있는 것을 2011년 011월 이렇게 바꿔줄 것입니다.
한글 폰트를 지정해 주시는 것을 잊지 말아야 합니다.. 저는 맥을 사용하므로 애플산돌고딕네오를 적었습니다만 Windows 사용자라면 “맑은 고딕”같은 것을 사용해주세요. 폰트를 정확히 지정하지 않으면 한글이 출력되지 않습니다.

1
ggplot(statdata, aes(x=month, y=population)) + geom_area(colour="#5c0ab9", fill="#8a4fcd") + coord_cartesian(ylim = c(23500000, 26500000)) + scale_y_continuous(labels=comma) + scale_x_date(labels = date_format("%Y년 %m월")) + theme(axis.text.x = element_text(family="Apple SD Gothic Neo"))

자! 되었습니다.
이제 마지막으로 X축과 Y축의 타이틀을 한글로 바꿔줍니다.
month와  population을 년/월과 경제활동인구라는 말로 바꿔줄 것입니다.
그러면서 코드를 좀 깔끔하게 정리해 보죠. 한줄에 너무 덕지덕지 다 붙여 놓으면 나중에 찾아서 고치기가 어렵습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
ggp <- ggplot(statdata, aes(x=month, y=population))
ggp <- ggp + geom_area(colour="#5c0ab9", fill="#8a4fcd")
ggp <- ggp + coord_cartesian(ylim = c(23500000, 26500000))
ggp <- ggp + scale_y_continuous(labels=comma)
ggp <- ggp + scale_x_date(labels = date_format("%Y년 %m월"))
ggp <- ggp + xlab("년도/월") + ylab("경제활동인구")
theme.title <- element_text(family="Apple SD Gothic Neo", face="bold", size=12, angle=00, hjust=0.54, vjust=0.5)
theme.text <- element_text(family="Apple SD Gothic Neo", size=10)
ggp <- ggp + theme(axis.title.x = theme.title, axis.title.y = theme.title, axis.text.x = theme.text)
ggp
rm(theme.title)
rm(theme.text)
gc()

드디어 완성입니다.
아주 이쁘지는 않지만 그럭저럭 보여줄만한 수준이 되는 것 같습니다.

다음 포스트에서는 플롯의 영역별로 색을 지정하는 것을 해보죠.

Posted by & filed under Uncategorized.

http://kr.akinator.com/
스므고개 놀이인 아키네이터 한글판입니다.
오래전에 보았을 때는 영문판만 있었는데 이제 한글도 지원하는 군요.
하는 방법은 머리속에 어떤 인물을 상상한 후에 묻는 말에 맞는 답을 클릭해 주면 몇 번 물어보고 답을 맞춥니다.
가수, 영화배우 게임 캐릭터, 소설 주인공, 영화주인공 다 가능한데요.
심심풀이로 해 볼 만한 서비스입니다.

신통하게도 아주 유명하지 않은 사람을 제외하고는 대부분 맞추는데 데이터를 어떻게 수집했는지가 매우 궁금해지는 서비스입니다.
조건에 맞는 인물 중 랭킹이 가장 높은 또는 확률이 가장 높은 캐릭터를 골라주는 것 같은데요.
방법이 정말 궁금하네요.

Posted by & filed under Uncategorized.

진주귀걸이 소녀가 지금 일본에 와 있습니다.
원래 소속이 네덜란드 마우리츠하이스 박물관인데 박물관 홈페이지에 가보면 소녀의 여행 일정에 대해 나와 있습니다.
번역기를 돌려보면 “저 여행을 떠나요!” 라고 나오네요. (긔엽긔 +_+ 쿨럭)

마우리츠하이스 박물관 홈페이지 주소
http://www.mauritshuis.nl/index.aspx?chapterID=9014

여행 일정은 최종 2014년 1월 21일까지는 일본의 동경과 교베를 거쳐 미국의 아틀란타, 시카고, 뉴욕을 마지막으로 들러 돌아가는 일정으로 되어 있습니다.
그 뒤로 다른 곳을 더 가게 되는지 아닌지는 모르겠지만 아마도 본래 집을 더 비우기는 힘드니 돌아가겠지요. 여튼 그때까지는 네덜란드에 가도 이 그림을 볼 수는 없다는 것이네요.

일본의 첫번째 일정인 도쿄 전시는 아래에 있습니다.

http://www.tobikan.jp/museum/2012/mauritshuis2012.html

사실 이 그림은 그렇게까지 아주 유명한 그림은 아닙니다.
관심이 있는 사람은 알고 없는 사람들은 전혀 모르는 그런 그림입니다.
개인적으로 죽기전에 실물을 꼭 봐야 하는 그림 중에 하나로 생각하고 있습니다만… (쿨럭)
사람을 홀리는 마력을 가지고 있는 이 소녀는 바로크시대의 대표적인 작품으로 빛의 표현이 정말 예술입니다.

여간해서는 안될텐데 초청을 할 정도의 일본의 재력과 관심이 부럽습니다만 비교적 가까운 곳에 왔으니 여유가 있다면 꼭 만나봐야할 그림이라고 생각해서 포스팅 해 봅니다.

Posted by & filed under Uncategorized.

한 번쯤 생각을 정리할 필요가 있다고 생각해서 포스팅하는 중이다.(이하 존칭 생략)
조심스럽고 복잡한 것이지만…

빅데이터 문제를 들면서 흔히 하는 말들이 기존에 알 수 없었던 것들을 많은 데이터 또는 많은 데이터에 적용 또는 활용해 봄으로 인해서 알아 낼 수 있다는 말이다.
굉장히 그럴듯한 말인데 조금 위험하긴 하지만 사실 틀린 말은 아니다. 실제로 그런것과 샘플링을 통해서 그럴 것이라고 추정한 것에는 다를 수 있는 점이 있기 때문이다.
여기서 약간의 함정은 “다를 수도 있다”이다. (또는 다른 것이 많다라고 한다)
그리고 그 말을 반박하는 사람은 “별반 다르지 않다”라고 말한다.
이것이 논점의 포인트이다. 아직도 애매하고 논란의 대상이 된다는 것.
이론적으로 어떻게 해서 그렇게 되는지 증명해봐라고 말한다면 못하겠다. 그냥 경험에 비추어 말하는 것이다.

잠깐 옆으로 살짝 새서 통계쪽과 빅데이터, 샘플링에 대한 논점에 대해서 내 어프로치나 스탠스를 생각해 보면 거의 모든 경우에 샘플링을 해서 거의 모든 문제를 해결 할 수 있다. 또는 그렇지 않다를 말하기는 조금 조심스럽다. 이와 관련되어서 여러 관점을 가진 사람들이 달라붙어 말을 꺼내한 사람을 무지몽매한 사람처럼 취급하며 상대를 공격하기 시작하기 때문이다. 학문적 깊이와 고민이 없어서 이론적으로 논리적으로 경험적으로 응대할 수 있다면 이런 민감한 문제에 대해서는 입을 닫는 것이 처세에 유리할 수 있다. 최근의 나는 입을 닫는 쪽이다. 나는 시류에 편승하게 보이려고 노력하는 쪽이다.

통계적 방법론에서는 샘플링을 통한 방법과 샘플링을 통한 모델의 최적화 방법이나 추정방법이 잘 되어 있어서 꼭 전수검사를 하지 않아도 대략의 것은 맞아 떨어지거나 전수검사(또는 전수검사에 필적할 만큼 많은 검사)를 한 것과 샘플링을 한 것의 차이는 거의 없다.

라는 것이 빅데이터의 빈곤한 필요의 이유성을 반박하는 쪽의 얘기다. 문제는 이것을 반박할 만한 뚜렷한 이론이나 논리나 경험을 내가 가지고 있지 않다는 것이다. 솔직히 잘 모르겠다. 나는 여기에 대한 깨달음이나 확고한 주관이 없다. 앞서에서 말한 내가 입을 닫는 이유이다. 아주 깊이 고민해 본적이 없고 나는 그 통계학을 조금이라도 기웃거리며 공부했다는 사람들은 다 안다는 중심극한원리도 끝까지 잘 이해를 하지 못하고 있다. – 노파심에 말하지만 정의상 무엇이고 어떻게 돌아가는지를 모르는게 아니라 기저의 원리를 완전히 이해 못했다는 말이긴 하다. – 결국은… 그러니까 모른다는 말이다.
그런것도 다 모른다는 사람이 이런 포스트를 건방지게 올리느냐라고 말한다면 조용히 다른 사이트로 이동해 주기를 정중히 부탁드린다.

그런데 생각해보면 말장난같긴 하지만 위에서 말한 샘플링 논쟁이 문제는 무엇을 하는데 샘플링을 한다. 안한다라는 말이 나오냐는 것이다.
데이터의 분포를 확인하기 위해서는 샘플링을 해도 충분하다는 것인지 예측모델을 만들기 위해서도 샘플링으로 충분하다는 것인지 살펴봐야 하는 대상이 롱테일에서의 테일 부분인데도 샘플링으로 충분한 것인지…
인터넷상에 떠도는 말이나 블로그등을 봐도 그런말에 대해서 잘 언급하지 않고 포괄적으로만 말한다. 물론 지면관계로 인해 그랬을 수 있다. 그런데 설명하지 않는 것도 문제가 있다. 그런 것쯤은 공부를 했다는 사람이면 충분히 기본으로 알고 논점에 들어가야 하는 것이 아닌가? 라고 되물을 수도 있을 텐데. 이것은 정말 말장난이라고 생각한다. 무엇에 대해서든지 정확히 뭘 하려고 하는지 말해야 한다. “상대가 무지해서 대화가 안돼!”라는 식의 태도는 교만함으로 인한 자신의 무지함을 감추기 위한 것이라고 생각한다. – 아닐 수도 있겠지만 대부분은 그렇다고 생각한다. -

통계적인 분야에 대해서는 깊이가 부족하지만 샘플링도 충분히 가능하지만 샘플링을 하지 않고 전수를 해 보려고 하는 이유는 노말(Normal)한 것들을 보지 않고 노말하지 않은 데이터들을 살펴보거나 혹시 나올 지도 모를 것들을 찾아 보겠다는 것이다. 전반적인 분포나 어떤 특성만 파악하려고 한다면 이런 자원소모가 큰 일은 잘 하지 않을 것이다.
노말한 것들, 직관적으로 쉽게 알 수 있는 것들은 이미 오래 연구가 되어 있거나 잘 알고 있는 것들이다.
더 해도 뚜렷한 성과를 보기 힘들다. 쉽게 성과를 보려면 (이런 생각 자체가 조금 무리이지만) 결국 남들이 보지 못한 것을 봐야 한다. 그것들은 정규분포의 가운데에 근처에 있는 것들이 아닐 가능성이 크다. 그리고 그런것들은 희소성을 가지고 있기 때문에 데이터가 많으면 많을 수록 더 잘 드러나고 제법 많은 양이 늘어나면 그것들 자체로도 어떤 규칙이나 특성들을 가지게 된다는 것을 발견할 수도 있다. (반대로 말하면 없을 수도 있다)
이 가능성 때문에 그 부분에 투자를 하는 것이다.
그런것이 없다고 확신할 수 있고 필요 없다고 생각하면 안하면 되는 것이다.

내가 지금까지 많이 봐왔는데 그건 안봐도 뻔해

라고 확신이 서면 안해도 될 것이다. 대신 일말의 아닐 가능성이나 다른 것이 발견될 가능성은 포기하는 것이다.

해 봤는데도 역시 잘 안나왔어

라는 말과는 다른 말이다. 이 경우에는 할 말이 별로 없다. 뭔가 잘 못한 것이 있을 것이다라는 말로 공격하기 전에. 가능성에 대한 도전을 해 본것과 아닌것의 차이는 크다고 생각한다. 그로 인해 생긴 시야가 당연히 달라져 있을 것이므로 결과가 같던 다르던 상관없이 의미가 있다. 물론 ROI나 output 측면에서 보면 후자쪽이 더 미련한 짓인 것처럼 보일 수 있다. 시간낭비만 한 것으로 보일 수도 있으므로. 하지만 내 경험상 그렇게 해서 괜찮은 것을 찾았다고 말하는 사람들이 꽤 있다. 사실 찾았어도 뭘 찾았는지는 잘 말해주지 않지만. – 이 경우는 아무런 득도 없었는데 무의미해 보이지 않으려고 한 거짓말 일 수도 있다 -

이 포스트에서는 통계적 관점보다는 우선 데이터마이닝관점에서 샘플링 논쟁이 어떤 부분에 해당이 될지에 대해 생각을 정리해 본 것이다. 어쨌든 나는 통계쪽에는 깊이가 별로 없는데다가 추정이니 다변량이니 분포니 이런 것은 머리아프다.

연관규칙탐사

연관규칙탐사는 보통 데이터마이닝 관련 서적의 초반부에 나온다. 쉽고 흥미 있는 주제라서 그런 것 같다.
데이터마이닝에서 샘플링을 안하고 하는 것이 기본적으로 유리한 것으로 우선 생각하는 것은 이 연관규칙탐사(Association Rule Mining)이다. 흔히 말하는 “장바구니탐색”이다. 이것은 논란의 여지가 별로 없을 것 같다. 컴퓨팅파워만 충분하다면 많은 양을 해보는 것이 여러모로 괜찮은 것을 발굴하기 좋은 방법이다.
이것은 빈발도(Frequency)기반이라 샘플링과 샘플링이 아닌 것의 결과의 차이가 굉장히 다르게 나타난다. 지지수(Support number)의 조절로도 많은 차이가 나는 것을 볼 수 있다. – 빈발도는 카운트이고, 지지도는 Threshold이다 – 작은 양의 데이터에서는 볼 수 없었던 특이한 그룹들의 데이터가 눈에 분명 보이는 때가 있다.

관점에 따라서 혹자는 이것을 노이즈라고 하고 혹자는 이것은 새로운 것을 발굴(Discovery)이라고 말한다.

어떤 사람들은

연관규칙탐사는 너무 단순하고 숫자세기 아닌가? 이 논점의 일부로 넣기에는 너무 조잡하고 수준 낮은 대상이다.

라고 말할 수도 있겠다. 샘플링이고 뭐고 이런 간단하고 무식한 것에 무슨 의미를 두드냐는 의미로 받아들인다. – 수준이 낮은 것이라는 말은 개인적으로 조금 거부감이 든다 – 실제로 해보지도 않고 “조잡하고 그런 쉬운것쯤이야”라고 말해 버리는데, 여기서는 의외성을 찾는데 샘플링이 그 의외성을 가리고 있을 가능성이 크다는 말이 하고 싶다. 어쨌든 이렇게 단순하고 조잡해 보이는 알고리즘도 실제로 극단적인 대상에 대해서 해 본 것과 그렇지 않은 것은 차이가 크다. 연관규칙에서 support number를 왜 조절하는지 곰곰히 생각해 보자.

“원래 outlier가 의외성 아닌가? 샘플링을 해도 outlier 영역은 있어서 확인이 가능하다. 앞뒤가 안 맞다” 라고 물으면 답변이 또 길어질 것 같다. 짧게 말하면 내 경험으로는 아닌 경우가 더 많았다. 혹자가 나는 별반 차이가 없는 경우가 더 많았다고 말한다면 나와는 다른 도메인 다른 상황에서 다른 뭔가를 봤을 것이고 그 경험도 당연히 맞을 것이다.

또 다른 질문으로

연관규칙탐사는 원래 샘플링 안하는 것이 아닌가? 샘플링하고 별반 상관 없는 것이 아닌가?

라고 지나가다가 묻는 사람도 있을 것이다. 교과서를 잘 읽어 보면 알겠지만 옜날 교과서는 샘플링을 하는 것을 기본으로 하고 있다. 최근 교과서는 그런 말을 아예 언급하지 않는다. 설명하려고 하는 것이 그런 것은 아니고 최근에는 그렇게까지 깊이 연구되는 쪽이 아니라서 그런 것 같기도 하다.

여하튼 보편적으로 샘플링을 하는 이유가 기본적으로

일일히 숫자세기가 어렵고 모든 모집단의 데이터를 다 얻기 어렵기 때문이다.

라는 데서 우선은 벗어나지 않았으면 좋겠다. 그리고 무엇을 보고 싶은지에 따라 샘플링하는 것과 아닌것도 달라져야 한다고 생각한다.
연관규칙탐사는 샘플링을 하지 않았을 때 유용한 것을 알아 낼 수 있는 대표적인 방법이고 특별히 유용하지 않는 그러니까 샘플링을 해도 충분히 알 수 있는 일반적인 사실을 알고 싶어했다면 샘플링을 하던 하지 않던간에 이것도 별 차이는 없다.

결론적으로 샘플링이고 뭐고 간에 연관규칙탐사에 있어서는 가능한 많은 데이터를 돌려 보면 볼만한 것이 많이 나온다.

지도학습 (Supervised Learning)

지도학습에서는 샘플링이 문제가 된다.
데이터마이닝에서 지도학습, 교사학습, Supervised Learning, 분류(Classification)는 같은 말이다. 용어 선택의 차이일 뿐이다.
이것은 학습데이터와 학습데이터로 만든 모델을 평가할 때 생기는 전반의 문제 때문인데, 샘플링 때문에 미지(Unseen)데이터에 대해 판별을 잘 하지 못하는 것에 대한 우려 때문이다. 샘플링의 문제에서 벗어날 수가 없다.
실제로도 샘플링을 어떻게 하느냐에 따라 결과의 차이가 심하게 난다.

지도학습에서 첫번째 샘플링을 하는 것은 EDA이다. 대충 데이터를 살펴보겠다는 것인데 이것은 다른 것에서도 다 하는 것이므로 넘어가자. – 데이터가 매우 많은 경우 모든 데이터를 사람이 일일히 다 살펴볼 수는 없다. – 그 다음에는 학습데이터(Training-set)을 얻기 위해서 하게 되는데, 정확히는 학습데이터에 레이블링(Labeling, Class를 부여)하기 위해서 이다. 학습을 시키기 위해서 데이터에 정답을 사람이 일일히 따주는 작업을 위한 것이다. 레이블 달 수 있는 적절한 분량만큼을 샘플링하는 것이고 샘플링한 데이터가 대상이 되는 데이터의 대표성을 잘 반영해야 한다. 개수로만 따질 문제는 아니다.
노파심에서 하는 말이지만 모든 데이터에 레이블이 이미 정확하게 다 달려 있다면 일반적으로 데이터마이닝에서 말하는 지도학습문제가 아니다. 모든 데이터에 레이블이 다 달려 있다면 지도학습을 할 필요가 없다.

그리고 만든 모델의 정확도를 판단하기 위해서 샘플링된 평가데이터(test set)등에 데이터를 대고 정확도를 점검한다. test-set은 때로는 training-set의 일부이기도 하고 아니기도 하다. – 보통은 training-set의 일부이다. -

이제 이렇게 만든 분류모델 -또는 예측모델 – 을 실제로 미지의 데이터에 적용하게 되는데 여기서는 실제로 평가데이터에 평가한 것 보다 대부분 결과가 안 좋게 나타난다. 여러가지 이유가 있을 것이다.
샘플링의 문제일 수도 있고 아닐 수도 있지만 결론은 어쨌든 미지의 데이터에 대해 예측을 잘 할 만큼 학습을 완벽하게 못한 것이다.

여기서 샘플링 문제라고 가정을 하고 극단적인 질문으로 학습데이터의 샘플링양을 늘리면 보편적으로 쉽게 잘 해결이 되느냐이다. 즉, 100억개의 모집단이 있고 이것을 위한 어떤 예측모델을 만드는데 학습데이터를 1000개를 쓰는 것보다 10000개를 쓰는 것이 더 유리하고 10000개 보다 100000개를 쓰는 것이 더 유리하냐는 것이다.
보편적으로는 그렇다라고 대답한다. 100억개의 다양성을 다 만족하기 위해서는 1000개나 10000개나 10만개도로 직감적으로도 적다는 것을 느낄 수 있다. 데이터가 아주 단조로운 데이터가 아니는 조건에서 말이다. – 물론 실제로 그 도메인에서 그런 것을 해봐야 알 것이다. 일반화하기는 다소 무리가 있다. – 그래서 10만개에서 100만개로, 100만개에서 1000만개로 학습데이터를 늘리면 다른 것 안해도 학습모델의 정확도가 더 좋아지냐? 가 사실 실제의 의문일 것인데.
모른다. 내 경험상 대부분 잘 안되기 쉽다.
100만개 이상의 학습데이터를 만드는 것 자체가 매우 불가능에 가까운 일이고 한다고 해도 그것을 제어하는 일이 거의 인간의 능력밖의 일이 된다. 100만개나 되는 데이터를 대표성을 가지게 잘 샘플링 하는 것 부터가 너무 어려운 문제이고 100만개를 태깅할 그럴 만한 돈이 현실적으로 없다. – 도메인에 따라서는 학습데이터가 수명을 가지는 경우도 많다. 오래되 면 못 쓰는 데이터가 생긴다는 것이다 -
결국 학습데이터를 늘리는 쪽을 기존 학습데이터를 이용해서 비슷한 데이터나 그렇지 부족한 영역의 데이터를 채워넣기 위해서 기계적인 방법을 이용하려고 하게 되고 그게 잘 알려진 Semi Supervised Learning이다. 이것을 준지도학습 또는 반지도학습이라고도 하는데 Semi Supervised Learning은 학습데이터가 부족한 경우외에도 학습데이터의 레이블이 심하게 불균형인 경우에도 사용한다.
Semi Supervised Learning에서 얼마만큼 어떻게 학습데이터를 기계적으로 채워넣어야 적절한지는 잘 모른다. 매우 어려운 문제이다. 나는 사실 이것을 제대로 해 본적이 없다. 내 능력의 제어권 밖이다.

그래서 지도학습에 있어서는

샘플링과 샘플링을 하지 않은 것의 비교는 불가능하고 원래의 논의 대상도 아니다. 그냥 이것은 뭘 어떻게 해도 다 샘플링이다.

데이터의 양의 차이가 있겠지만 샘플링에서 벗어날 수 없다.

비지도학습 (Unsupervised Learning)

클러스터링(Clustering) 또는 비교사학습, 비지도학습이라고한다.
학습데이터 없이 대충 알고리즘을 통해서 어떻게 데이터가 분류되는지를 보는 쪽이다. 결과에 대한 제어가 안된다. 다만 혹시 뭔가 다른 것을 볼 수 있지 않을까 호기심용으로 쓰이거나 대략 포괄적으로 뭔가 데이터를 분류해 보고 싶은데 어떤 기준으로 분류할지는 정해지지 않은 것을 할 때 쓴다.

이것도 샘플링과 관련이 있는가?

당연히 있다. 데이터베이스 내에 있는 전 사원을 분류해 보고 싶으며 샘플링이 아닌 것이고 고객의 일부 데이터나 전체 데이터를 이용해서 전체의 미지의 고객에 대한 분류를 해보 싶으면 샘플링이다. 또는 사내의 전 사원을 다 해보고 싶은데 양이 많아서 몇 명씩만 뽑아서 했다면 역시 샘플링이다.
알고리즘이나 알고리즘을 제어하기 이후의 문제로 데이터의 양으로 인해 군집화가 잘 되는지 알 안되는지는 차이가 있을 것이다. 클러스터링문제에 있어서 옳고 그름은 없다. 그냥 데이터의 양으로 인해 잘 드러나지 않은 군집이 드러나서 영향을 미치고 결과가 다르게 나올 수 있다.

결국 이것도 샘플링을 잘 하면 해결되는 문제가 아닌가?

라고 물을 수 있다. 분류된 군집의 개체수가 1개일 때와 10개일때와 100개일때의 의미가 없다라고 말한다면 그럴 수 있다. 하지만 대부분의 경우에는 의미가 있다. 이것은 데이터의 양에 따라 차이가 난다. 특별한 다수의 군집을 발견했는데 모두가 개체수가 1인 것과 10개인 것과 100개인것과 20인 것들의 차이가 있을때의 관찰자에게 생기는 시야의 차이는 있다. 물론 이것도 샘플링을 잘했을 때의 이야기라는데는 이견이 없다.
자세히 보고 싶다면 많으면 많을 수록 좋다. 그것이 아니라면 필요 없다.

샘플링을 안하는 것이 빅데이터가 아니라 샘플데이터가 많은 것도 빅데이터 문제이다.

비지도학습은 지도학습과는 달리 레이블링이 필요 없어서 데이터를 늘리는데 컴퓨팅 파워 외에는 문제될 것이 별로 없다. 다만 결과를 해석하고 반복하고 뭔가를 이해하려고 할 때 드는 부담이 매우 늘어날 뿐이다. 이것은 인간의 몫인데 슬슬 기계의 몫으로 넘기려고 하는 도전이 많다. 이것 또한 빅데이터 문제이다.

롱테일

롱테일, 파레토 법칙(Pareto law), 때로는 파워로우(Power law)까지를 잠깐 얘기해 보자.
파워로우는 잠깐 빼고 파레토쪽만 생각해 보면 80대 20으로 잘 알려진 이 문제는 데이터를 바라보는 관점과 해석하는 것에 따른 차이가 있다.
흔히 드는 얘가 대충 전체 매출의 80%를 만드는 것은 상위 20%의 고객이다라는 것으로 유력한 소수의 집단이 큰 흐름에 지대한 영향을 끼치는 것을 말한다. 앞서의 예에서는 두 가지 관점에서 데이터를 바라 볼 수 있는데

  • 전체 매출을 차지하는 20%의 개체들이 매우 중요하다고 보는 관점과
  • 20%의 대상은 소수이며 이미 잘 알려져 탐색이 된 상태이기 때문에 80%에 관심을 가져야 한다는 관점이다.

잘 생각해 보면 사실 이것은 샘플링을 하고 안하고의 문제와 관련이 없을 수 있다.

샘플링을 해도 20%가 80%의 매출을 차지하는 것과 같은 비중을 차지하는 것과 같은 패턴은 잘 달라지지 않는다. 안해도 결국 대부분 마찬가지이고. 80%의 매출을 일으키는 20%의 고객에게만 관심 있다면 이 문제에 있어서 빅데이터는 큰 문제가 아니다.
문제는 반대의 경우인데 이 경우에 20%의 매출을 만드는 80%의 고객들은

  • 영향략이 그리 크지 않지만 무시할 수준은 못된다.
  • 상위 20%의 고객에 대한 연구는 충분히 이루어졌고 더 할 것이 없어 보인다. 그래서 80%의 잉여스러운 존재에 대해서 눈을 돌리고 싶다.
  • 그러나 쪽수도 많고
  • 다양성 때문에 일일히 케어 하자면 너무 디테일 해져야 할 수도 있고
  • 잘 드러나지 않은 것들이 많아서 특성을 살피기에는 투자가 많이 필요하다.

라는 것이 문제다. 경쟁 우위를 확보하기 위해서 이 80%를 케어하기 시작한 것은 제법 오래되었다. 그런데 이런 디테일함을 케어하기 위해서는 사람이 다하기 어려우니 비교적 컴퓨팅파워를 이용해서 기계적으로 뭔가를 얻어내려한다. 이것도 빅데이터 문제다. 물론 이 문제도 대상을 정확하게 규명하고 하나씩 샘플링 해가면서 하면 되지 않느냐인데. 해도된다. 하지만 이제 그러기에는 데이터가 너무 많아지고 있다.

자질 추출 (Feature Extraction)

이 문제는 샘플링과 상관이 없을 가능성이 높다.
지도학습이던지 비지도학습이던지 알고리즘을 돌리고 모델을 만드려면 자질(Feature, 또는 attribute라고 한다)을 추출해야 한다. – 베이지안 계열 중에는 이 과정이 단순히 카운트 세는 것으로 끝나는 경우가 있어 없는 것처럼 보일 수도 있다. – 보통 ETL과정에서는 이것을 Aggregation이라고도 말할 수도 있는데 컴퓨팅파워가 많이 들고 최근에는 가능하면 많이 넣으려는 추세다. – Feature를 많이 넣으면 많이 넣을 수록 좋다는 말이 절대 아니다 – 많이 시도 해 보려고 한다는 것이고 단순하게 몇개만 해봐서는 성능향상이 더 이상 나오지 않는 것이 많다는 것이다. 자질 추출은 단순히 대상의 레코드 뿐만 아니라 전체의 레코드에 대해서 스캔을 다 해봐야 하는 경우도 의외로 많다.
검색엔진 같은 것에서 많이 쓰는 TF/IDF같은 것이 그렇다. 컴퓨팅파워가 극도로 많이 소모되고 모델을 만들 때도 만든 모델을 적용할 때도 똑같이 필요한 과정이다. 그래서 컴퓨팅 파워가 많이 소모될 수 밖에 없는데 이 것은 그대로 빅데이터 문제가 되기 쉽다. 그리고 feature의 값들 중 일부는 연관이 있는 다른데이터의 샘플링을 하고나서 생성된 값을 쓰는 경우가 있다. 매우 데이터가 많고 복잡한 모델의 경우 이런 것도 하게 되는데 샘플링을 한 값을 자질로 넣기 위해서는 그것을 결정하는 사람이 매우 수준이 높고 연구를 많이 해야 하고 그것에 대한 전체 흐름과 영향에 대해서 완전히 파악하지 않으면 위험하기 짝이 없는 자질이 된다. 그럼 빅데이터 솔루션으로 샘플링하지 말고 다 하면 되겠네? 비꼬는 질문이 날아 올텐데 상황상 안되는 경우도 비일비재하고 데이터를 조인의 조인의 조인의…을 하다보면 자원이 천문적으로 필요한 도메인도 세상에는 존재한다. 어느 부분에 있어서도 데이터 처리의 문제는 샘플링 문제를 사실상 벗어나기 어렵다. 빅데이터를 한다고 해도 기본적으로 그 소양은 갖추고 있어야 유리하다는 것이다.

특별한 대상을 탐색하기 위한 수준 높은 샘플링

제대로 공부했고 제대로 훈련된 분석가라면 특별한 대상을 탐색하고 분석하기위해서 샘플링을 충분히 잘 할 수 있고 그것으로 해석이 가능하고 충분하다고 말할 수 있다. 샘플링을 충분히 잘 할 수 있으면 사람이 충분히 제어할 만한 수준이 되므로 모든 데이터를 또는 대용량의 데이터를 다 들여다 보지 않아도 충분하다라고 말할 수 있다.

샘플링을 제대로 하지도 못하면서 그냥 데이터만 막 들이밀면 문제가 잘 해결될 것 처럼 말하지 말라!

샘플링과 대용량 데이터에 대한 얘기가 나오면 피를 토하고 말씀하시는 분들의 요점은 이것인 것 같다.

맞는 말 같다.

정말 맞는 말이라고 생각한다. 하지만 사실 나는 이것을 아주 잘하는 사람을 몇 명 보지 못했다. 그래서 잘 안되고 있다고 생각한다. 내가 많이 보지 못했기 때문에 그런 사람들이 드믈것이라고 말하는 것에 어폐가 있다고 할 수 있다. 인정한다.
하지만 그래도 반박하자면…
말로는 뭔들 못할까? 밥그릇 챙기기로 보이는 행위를 굳이 할 필요는 없다. 보여주면 되는 것이다. 나는 아직 그런분들을 많이 보지 못했다.
샘플링해서 분포를 보고 이 분포가 맞는지 안 맞는지 오차가 얼마인가를 생각하는 것 보다는 전체를 카운팅해서 어그리게이션 한 다음에 히스토그램 그리는 것이 더 명확하고 쉽다.

외국계 포털에서 일하면서 많은 아이디어를 많은 데이터에서 단지 팩터별로 카운트 해 보는 것만으로도 독특한 아이템이나 관점을 찾아내는 사람을 많이 봤다. 물론 막대한 양의 컴퓨팅 파워가 필요하기 때문에 이것 조차도 쉽게 따라 할 수 없는 것이긴 하지만. 이런 간단한 것들이 때로는 간단한 것이 회사의 매출에 지대한 영향을 끼치기도 했었다. 몇몇의 것들은 사실 별것 아닌 것 같으면서도 이런 것들이 이루어져서 새로운 거대한 흐름을 만들기도 했다. 보통 이런것들은 바깥세상에 숨기기 마련이다. 별것 아닌 것이서 그럴 수도 있고 알려지면 따라하기 때문에 그것이 곤란해서 일 수도 있다. 이런 간단하면서도 충격적인 것들은 사내에서도 대내 기밀인 경우도 많다. 알려지면 누구나 따라하기 때문에 알려지는 시점을 늦추고 최대한 시간을 벌려는 것이다. 알고 나면 정말 별거 아닌 것들이다. 먼저 알아내서 깃발 꽂으면 되는 것들.

구글의 페이지링크와 같은 것들처럼 알고 나면 별것 아닌 것이다.

알고 나면 별거 아닌 것 같은 콜럼부스의 달걀 같은 것이다.

남들도 알고 있고 나도 알고 있는 것은 경쟁에 있어서 무기가 되지 않는다.

그것을 위해서 수단 방법을 가리지 않는 것이고 샘플링을 하고 안하고의 이전에 있어서 현대에 기업이나 사업에서는 수단방법을 가리지 않으려고 한다. 그것이 샘플링이 되었던지 통계학의 깊은 수준의 지식이 필요하든지를 떠나서 말이다.

데이터와 정보처리에 있어 그 수단 중 하나가 빅데이터 솔루션이다. 우리가 어떤것에 대해서 얘기할 때 구체적으로 무엇에 대해서 얘기하고 있는지 곰곰히 생각해 볼 필요가 있다. 나는 빅데이터를 해도 샘플링을 해야 하는 문제는 결국 그럴 수 밖에 없다고 생각하는 주의이고 그 문제를 컴퓨팅 자원을 소모해서 쉽게 해결할 수 있다면 가능한 그 방법을 택하겠다는 주의이다. 나는 빅데이터가 기존의 통계학도들이나 빅데이터에 적응하지 않으려하는 데이터 분석가들의 밥줄을 끊던 말던 사실상 관심이 없다. 알아서 챙겨야 할 문제다.
이미 사회에 진출하는 많은 학생들이 빅데이터에 대한 학습도 많이 하고 진출하고 있다. 사실 나는 그들이 매우 두렵다.

통계쪽에 대해서는 얘기를 하지 않았지만 그래도 하고 싶은 말은 있다.
혹시 이 글을 읽는 분들 중에서 통계학에 정통을 했으며 샘플링 문제에 있어서 고수준의 지식을 가지고 있는 분들이 있고 솔직하게 생각해서 그런 분들이 어줍잖게 컴퓨터의 힘을 빌어 그런 깊은 지식에 대한 학습의 노력없이 당장 나온 결과만 보고 따라 오려는 사람들을 불편하게 생각하는 분이 있다면 그 분들도 더 노력을 해야할지 모르겠다. 기계가 어느 정도 많은 것을 해결해 주는 시기가 점점 오고 있다는 것은 분명하니까.

Posted by & filed under Uncategorized.

R과 관련없이 유명한 상용 Interactive Data Visualization 툴로는 Spotfire가 있습니다.
Spotfire는 그래프를 그리고 그래프의 영역을 계속 마우스로 선택해 나가면서 데이터를 탐색하게 해주는 툴입니다.
이 포스트에서 언급하는 것들은 주로 spotfire같은 것은 인터랙티브하게 반응하는 UI를 말합니다.
Processing이나 Paper.js같은 미디어아트와는 다소 다릅니다.

Interactive Data Visualization이 뭔데?

데이터 분석에서 Interactive Data Visualization 이 필요한 이유는 데이터탐색을 빠르고 직관적으로 하기 위한 것입니다.
엑셀같은 스프레드시트에 수치를 적어넣고 그래프를 다시 그리거나 R같은 곳에서 코드 적어가며 그래프를 완성해 나가는 방법은 탐색을 하는데 있어 시간이 꽤 걸리고 불편하다는 것입니다.

쉽게 할 수 있는 방법이 있다면 쉽게 해야 한다. 그것이 모티브다.

Interactive Data Visualization 애플리케이션이 작동하는 방식은 대충 특정 데이터를 로딩한 다음 그것에 대한 기본 그래프(플롯)나 여러 그래프를 나열해 놓고 한쪽에서 마우스로 눈에 띄는 영역이나 다른 영역을 선택하면 다른 플롯에서도 그 부분이 별도로 표시할 수 있고, 확대도 할 수 있고, 다른 플롯으로 다시 그려볼 수도 있게 해줍니다. 이 과정을 매우 유연하고 편하고 반복적으로 하게 해주는 것을 말한다.

때로는 애니메이션 기능을 이용해서 움직이게 만드는 것도 이 부류에 넣기도 하는데 애니메이션은 사실 직관을 찾기 위한 용도이지 진짜 탐색을 위한 용도는 아닌 경우가 많지요.  그부분은 다른 포스트에 따로 적기로 하겠습니다.

R과 Interactive Visualization을 말하기 전에 우선 결론적으로

R로 Interactive Visualization을 구현 하는 것이 매우 어렵다.

R을 위한 Interactive Visualization 패키지로는 ggobi, cranvas, iplot(Acinonyx)등이 가장 유명합니다. 그 외에도 다수가 있지만 그렇게 주류로 사용되지 않습니다. 일반적인 플로팅 패키지중에서 비교적 Interactive Visualization에 가까운 것으로는 역시 ggplot2가 있습니다. ggplot2에 대한 내용은 여기서 자세히 얘기하지 않겠습니다.

R로 Interactive Visualization이 잘 안되는 이유들

우선 아예 안되는 것이 아니라 잘 안되는 것이라고 말해둡니다.  오해의 여지를 줄이기 위해서

1. Cross platform을 위한 렌더링 엔진 문제

iplot과 ggobi같은 R 패키지는 GTK를 사용하고 cranvas는 Qt SDK를 interfacing해 놓은 qtbase 라는 R패키지에 강한 의존성을 가집니다. 물론 이 패키지들도 플랫폼에 따라 렌더링 엔진이 조금씩 다르긴 하지만 적어도 Mac OS X와 Linux를 위한 버전은 확실하게 의존성이 강합니다.  이런 패키지들이 렌더링 엔진을 이렇게 지저분하게 선택해야 하는 이유는 당연히 Cross platform 때문인데 대부분의 R사용자들은 Windows를 사용하지만 대부분의 R의 코어나 패키지 개발자들은 Windows를 사용하지 않고 Linux나 Mac을 사용합니다. 그리고 현존 하는 가장 유력한 범용 Cross Platform용 렌더링 엔진은 Qt, GTK, Java 정도입니다.
Java는 렌더링 엔진이 아니지만 어쨌든 크로스플랫폼으로 화면을 제어할 수 있어서 포함했습니다.
그 외에는 Browser기반의 Javascript + HTML5가 고려대상이 되겠구요.

대부분 Interactive Visualization 의 경우 여기서부터가 문제가 생깁니다.
Cranvas는 qtbase를 사용하지만 qtbase는 Windows를 지원하지 않으며 QtSdk를 설치하는 것도 매우 귀찮은 일이고
ggobi와 iplot2가 사용하는 GTK는  Qt보다 설치가하기 더 지저분합니다.
Java는 R과 인터페이싱하기가 너무 복잡하다는 문제점이 있습니다.
이 경우에는 rJava를 사용해서 R에서 Java를 제어할 것인지 Rj를 사용해서 Java에서 R을 제어할 것인지도 고민이 됩니다.
또 R의 패키지는 렌더링엔진을 포함해서 배포할 수 없는 구조이고 사용자가 알아서 다 설치해야 한다는 점입니다.

여기까지의 요점은 아래와 같습니다.

  1. Qt나 Qtk관련 패키지들은 설치 자체가 어렵고
  2. Java는 Interfacing 자체가 또 하나의 숙제고
  3. HTML5+Javascript는 매우 복잡하고 지저분하다.
2. 기존 plotting 평션의 재활용 문제

R에는 많은 plotting관련 패키지들이 있습니다. 기본으로 제공하는 것도 물론 매우 훌륭한다. 대부분의 현존하는 모든 형태의 2차원 플롯은 다 지원하고 미려하고 섬세한 표현이 가능하긴합니다.
하지만 사용자마다 쓰는 플롯이 다르고 원하는 바도 많이 다릅니다.

사람의 욕심은 끝이 없어서 이 미려한 R의 플로팅을 인터렉티브 플로팅에서도 보고 싶어하지만
안타깝게도 렌더링할때 때로는 R의 플로팅용 device를 다시 개발해야하는 문제가 있으며 인터랙티브요소 때문에 plotting에 대한 펑션을 다시 제작해야 하는 경우가 대부분입니다.

이런 방식은 기본 플로팅 평션을 그대로 쓸 수가 없다.

결국 포기하고 포팅을 하거나 새로 만들게 되는데 R의 패키지 제작자들이 많아 1 ~ 2명 정도가 대부분인 것으로 볼 때 많은 종류의 플롯을 지원하기가 당연히 어려울 것이다. 완성도가 높을 수가 없습니다.
대충 어렵게 설치해서 Cranvas, iplot등을 어렵게 쓴다고 해도 이 패키지들의 결과물의 상태가 문제점이 많습니다.

그리 빠르지 않다.
그리 예쁘지 않다.
그리 편하지 않다.

실제로는 그리 쓸만하지 않다는 것입니다.

3. HTML5+Javascript을 활용하는 것은 어색하다.

그러면 크로스플랫폼 문제라도 해결하기 위해서 Application based에서 Web based로 전환하면 어떨까? Web based라면 플랫폼문제가 해결되고 기존의 플로팅 펑션을 그대로 활용하는 것은 일단 포기하는 것으로 생각하고 성능과 편리함을 미세하게 조절하고 경쾌하게 움직이는 것도 역시 다소 희생한다고 하면 시도해 볼 수도 있겠습니다.

R이 범용 랭귀지가 아니기 때문에 이 또한 우아하게 해결이 되지 않지만 그래도 할 수는 있습니다. R로 web service를 할 수 있는 잘 알려진 방법은 다음의 두가지입니다.

  • Apache를 설치하고 rApache모듈을 붙여서 R로 CGI 코딩을 한다.
  • Rook 패키지를 설치해서 CGI코딩을 하고 로칼에서 브라우저로 R에 접속한다.

이 외에도 많지만 요즘 대세는 위 두가지입니다.
위의 두가지중 하나를 선택한 후에는 base로 사용할 Javascript framework을 선택해야 하는데
Processing.js, paper.js, hichart, ExtJs등을 선택할 수 있습니다.

그런데 이쯤되면

이걸 왜 R로 해야하지?

라는 의문이 생깁니다.
애초에 R을 이용한 Interactive Visualization을 하고 싶은 이유는 앞에서 말하지는 않았지만
아래와 같은 이유 때문이 많습니다.

  • R의 강력한 플로팅 기능을 그대로 활용
  • R의 다양한 알고리즘, 펑션이나 관련 패키지를 그대로 활용
  • 최대한 R base에서 많은 부분을 할 수 있도록해서 사용성을 높임

어떤 방법을 선택해도 위 문제중 2가지 이상을 쉽게 해결해 주지 못합니다.
첫번째는 기존 플로팅 펑션을 포팅하는 방법외에는 길이 없습니다.
두번째는 R을 베이스로 작동하게 하면 해결되긴 합니다.
세번째가 문제인데
이것을 해결하기 위해서는 너무 많은 삽질이 필요합니다.
지금까지 제 결론은

R의 그래픽 디바이스를 Web 기반으로 작동하게 하나 만들고 그 디바이스를 이용한 플롯펑션을 만들고, 그리고 인터페이스쪽 부분을 Javascript로 떡칠하는 것입니다.

물론 여기까지의 이런 고민들은 Windows라는 OS를 포기하고 나 혼자만 쓰기로 작정하고 Cocoa 기반으로 만들면 됩니다.  하지만 그러기에는 Windows사용자가 너무 많습니다.

더구나 Big Data를 위해서 Hadoop, Hive, RHive 연동까지도 더불어 생각하면 선택의 폭이 더욱더 좁아집니다.

 

Posted by & filed under Uncategorized.

R에서 Locale을 바꾸는 코드입니다.
R에서 Locale을 지원하는 function들이 아직은 많지 않습니다만
datetime을 다루는 것들 중 일부는 따르는 것이 있습니다.
아래 예제 코드는 OS별로 Locale코드가 다른 문제로 인해 결과물을 다르게 나올 수 있음을 유의하셔야 합니다.
포맷을 바꾸고 싶으면 Locale에 의존하기 보다는 강제로 세팅을 하는 것이 아직은 편할 수 있습니다.
물론 en_US이기 때문에 이렇게 세팅하면 메세지가 영어로 나옵니다.

1
2
3
4
5
6
7
sessionInfo()
Sys.getlocale()
Sys.setlocale("LC_TIME", "en_US.UTF-8")
Sys.setlocale("LC_CTYPE", "en_US.UTF-8")
Sys.setlocale("LC_COLLATE", "en_US.UTF-8")
Sys.setlocale("LC_MONETARY", "en_US.UTF-8")
Sys.setlocale("LC_MESSAGES", "en_US.UTF-8")

Posted by & filed under Uncategorized.

데이터 사이언티스트(Data scientist, 이하 데이터 사이언티스트)에 대한 정의와 신규 직종으로써의 논의 거리고 많이 언급되고 있는 것 같아 저도 제 생각을 정리해 봅니다.

데이터 사이언티스트는 데이터와 관련된 것들을 모두 연동 또는 연결해서 결과물을 만들어 낼 수 있는 사람입니다.
이런 작업이 가능 하려면 관련된 다양한 지식과 경험, 기교가 필요합니다. 여기서는 다양성이 더 중요한데 학습 영역도 넓어야 하고 깊이도 나름 갖추고 있지 않으면 안됩니다. 학습 뿐만 아니라 실제 경험이 있어야 하는 것이 더 중요합니다. 학교에서 배우기에는 분량도 많고 영역도 상당히 넓습니다.

데이터 사이언티스트의 스펙에는 정보검색, 자료구조, 기계학습, 데이터마이닝, 알고리즘, 비주얼라이제이션, 인간공학 그리고 비지니스적인 설득을 위한 프리젠테이션까지도 포함됩니다.

이런 데이터 사이언티스트들의 정의에 나오는 스펙을 만족시킬 수 있는 사람은 현재로써는 IR과 관련된 일을 집중적으로 해서 업무 영역이 넓어진 사람이 대표적입니다.
이 사람들은 훈련이 되는 것이 아니라 스스로 훈련을 해야만 스펙을 갖출 수 있기 때문에 학교를 갓 나온 사람들에게서는 그런 것을 찾기가 어려울 것이며 그래서 실리콘 밸리에서 데이터 사이언티스트를 채용하려고 할 때 관련이 있는 회사에서 일한 경험이 많은 사람을 우선해서 채용하려고 하는 것입니다.

이 사람들은 대형 인터넷 업체에서 일을 하면서 초창기의 정보검색을 서비스로 제공하는 과정을 거쳤으며 전혀 쓸모 없을 법한 기계학습과 데이터마이닝, 인공지능이 정보검색과 서비스에 어떻게 적용되는지를 봐왔고, UI와 디자인의 표현이 인간의 반응에 어떤 영향을 주고 어떻게 다음 행동을 유도할 수 있는지를 이해하는 과정을 거치게 됩니다.
그리고 그런 데이터의 가공과 흐름과 사용자의 반응들로 인해 만들어진 로그와 같은 2차데이터들에서 부가적으로 얻을 수 있는 것이 무엇인지 경험 또는 아이디어를 통해서 얻어내서 3차데이터로 만들어내는 과정도 당연히 거쳤을 것이며, 방대하게 늘어나는 데이터를 통해 데이터와 관련된 시스템의 구조와 데이터를 추출, 가공 그리고 제공하는 방법을 이해하고 고민하며, 거대한 데이터와 시스템을 구축하는데 자원을 절약하는 방법과 자원을 과소비하여 시간을 단축을 엑셀레이션하는 역발상의 다른 패러다임을 생각해내고 이해하는 과정도 거쳤을 것입니다.
그리고 최종적으로 이런 것들이 어떤 싸이클을 돌며 하나의 생태계와 같이 끊기지 않는 순환고리를 만들며, 스스로도 점점 확장되어 갈 수 있게 하나의 작은 사회를 설계하며 조절하고 순환이 잘 되도록 유도하는 방법까지도 이해하게 됩니다.

이것이 현재 유행하는 빅데이터와 관련된 일을 하는데 필요하다고 말하는 데이터 사이언티스트의 기본 스펙이라고 할 수 있습니다.

현재의 사람들이 중에 이 스펙들을 갖춘 사람이 드문 이유는 이와 관련된 일이 지금까지 진입장벽이 매우 높은 일부 인터넷 서비스에서만 폐쇄적으로 그리고 집중적으로 다루어져 왔으며 이런 스펙들이 크게 각광받는 분야도 아니었으므로, 취업시장에서 흔히 진리라고 여겨지는 적자생존의 논리에 의해서 이와 같은 커리어 패쓰로 진입하려는 사람도 많지 않았기 때문입니다.  진입을 꺼려하는 또하나의 이유는 관련된 일들은 실패할 확률이 매우 많아 성과를 보여주기 어렵고, 지루하고 반복되는 일이 되기 쉬우며, 업무량이 많음에도 불구하고 옆에서 보기에는 놀고 있는 것처럼 보이기 때문이며 제대로 평가를 하기도 어려운 일을 하기 때문입니다.

하지만 이런것에 획기적인 전환을 이끄는데 중심이 되는 회사가 구글, 아마존, 페이스북, 야후, 넷플릭스등의 온라인 마켓, IR 그리고 소셜 콘텐트 서비스 회사들입니다.

그들은 이런것들이 충분히 돈벌이가 되며 가치를 만들어 낼 수 있음을 이미 오랫동안 사업을 하면서 알아왔고 최근에는 그에 대한 내용을 상당히 공개하게 되었고 성공의 핵심에 데이터를 다루는 일이 있다는 것을 알게 되었으며, 많은 사람들이 그에 대한 것을 호기심 또는 새로운 분야에 대한 탐구심 또는 각광받는 직군으로의 진입을 생각하며 관심을 가지게 됩니다.

그리고 이와 같은 회사들은 손으로 만져지는 하드웨어는 판매하는 것들이 아무것도 없으면서 그렇다고 소프트웨어를 판매하는 것도 아니며 그와는 다른 무형의 가치인 데이터의 가공을 팔아서 챙긴 이익으로 세계 최상레벨의 기업으로써의 위상을 보여주기까지 합니다.

결국 데이터 사이언티스트는 이들 기업이 하는 일의 공통적인 부분을 하나의 직군에 대한 커리어라고 보고 ,이것을 최대한 커버할 수 있는 엔지니어 그룹 중에 현재로써는 그 수가 가장 적은 사람들입니다.

실리콘 밸리에서 이 사람들이 최근 이 사람들 많이 필요하게 된 이유는, 이 사람들이 있으면 데이터와 관련된 사업을 하려는 벤쳐들은 스타트업을 바로 시작할 수 있으며, 시작하는데는 많은 수의 데이터 사이언티스트가 필요하지도 않습니다. 분산처리, 네트워크, 코어개발등의 엔지니어도 필요하고 공급도 부족하지만 이런 것들은 시작하는데 당장 필요하지 않으며 분산처리를 제외하고는 데이터와 직접적인 관련이 없으며 어느 정도 제품의 구매를 통해서 해결할 수도 있으며 아직까지는 취업시장에서 인재를 쉽게 구할 수 있습니다.
하지만 데이터 사이언티스트는 쉽게 양성되지 않는 프리랜서의 시초인 고대의 창기병들처럼 빨리 공급이 채워지지 않으며 훈련기간이 더디게도 길고 현재 생존해 있는 수가 생각보다 매우 적습니다.

스타트업 뿐만 아니라 대형 기업에서도 수가 많은 편이 아니며 이탈했을 경우 채워 넣기가 쉽지 않고, 그렇다고 해서 내부에서 양성하기에도 쉽지 않습니다. 훈련이 쉽지 않고 시간이 상당히 오래 걸리기 때문입니다.

결국 공급이 매우 부족하며 당장은 해결할 수 없는 것입니다.
이 공급은 계속해서 부족하게 될 것이 자명하며 그 이유로는 데이터와 관련된 일에 사람들이 관심을 돌리고 있고 쌓이는 데이터는 점점 많아지고 다양화되기 때문에 그 공급부족 현상이 더 가속화될 수 밖에 없는 것입니다.

현재의 정의로 보면 데이터 사이언티스트는 데이터와 관련된 일에 대해서는 아키텍트(Architect)이며 실무자라고 할 수 있으며 데이터와 관련된 모든 것을 설계하고 구성할 수 있는 사람입니다.

그리고 이 사람들이 하는 일과 관련된 것들 중 아주 큰 데이터를 가진 부분집합을 사람들은 한 단어로 빅데이터(Big Data)라고 합니다.

 

Posted by & filed under Uncategorized.

통속 소설 몇권을 형태소 분석기로 돌려서 명사만 추출해서 단어를 쭉 훑어 보았습니다.

왜냐고 물으신다면. 그냥  하고 싶어서…
가끔은 멍때리는 짓을 하고 싶은 욕구가 무럭무럭 일어납니다.

많은 양의 단어들이 잘못된 개행과 맞춤법오류, 형태소 분석기 후처리 사전의 부족함으로 인해 공중분해되어 날아가 버렸지만 보편적으로 강력한 것들은 그럼에도 불구하고 의도한대로 대충 추출되었습니다.
앞서 말씀드렷듯이 명사만 보려고 했기 때문에
동사와 조사 기타 잡사등은 다 날려버렸고 대명사도 저멀리 은하계 저편으로 강제로 날려 버렸습니다.

사실 원래 해보려고 했던 것은 분야별로 잘 나오는 명사들이 있어서 대략 명사들의 출현 빈도나 패턴등으로 어떤 부류의 소설인지 자동 분류가 가능하지 않을까 하는 호기심 때문이었습니다.  (아주 쓸데 없는 짓이지요)
물론 소설은 자동분류가 필요 없을 것입니다. 이미 출판이 되거나 연재가 시작 될 때 그 부류가 결정이 되기 때문에.
여튼 그리고 겸사겸사 소설들에서 사용하는 명사들은 어떤 것이 많이 쓰이는지 장르별로 차이가 얼마나 많은지 그런 것을 확인해 보고 싶어서 였습니다.

여튼 몇권을 형태소 분석기를 돌려 추출한 명사만 훑어 본 것인데 거의 모든 소설에서 공통적으로 1,2,3등으로 나오는 단어는 아래와 같습니다.

1. 주인공 이름
2. 사람
3. 생각
4. …

뭐 대충 이런 순서입니다. “인간”과 “사람”을 동의어로 취급해서 count를 하나로 합치면 가장 많은 것이 “사람”이었구요.
저것들이 롱테일에서 헤드부분을 차지하고
그 뒤로 미들부분에 나오는 것들이 보통 그 소설의 특성을 반영할 수 있는 명사들이었습니다.
판타지 소설이면 마법과 갑옷 뭐 그런것에 관련된 어휘들, 무협소설이면 무공과 관련된 것들, …
그리고 그 뒤로는 주변인물들 이름들을 비롯한 다소 애매하지만 소설의 내용을 유추하거나 반영할 만한 단어들이 나왔습니다.
테일쪽에서는 사자성어들과 외래어표기, 어려운 한자어 등이 많이 보였습니다.

보통 소설들이 3인칭 시점이 많으므로 주인공 이름이  가장 많이 나오는 것이 당연할 것입니다.
다시 말하면 그다지 중요하지 않다는 얘기구요.
그냥 소설을 읽지 않고도 주인공이 누구고 주변 인물이 대충 누구인지 알아내는 정도에나 쓸까요.
글자수와 자음과 모음의 사용 빈도나 패턴을 뽑아서 분류기로 만들면 주인공이 서양인지 동양인지 판타지인물인지 정도도 알 수 있을 것 같습니다만. (그다지 쓸모 없는 일 +1)
여튼 포스팅을 하게 된 이유는 무작정 많이 출현한 이유가 궁금해지는 저 “사람”과 “생각”이라는 단어입니다.
제가 보통 소설을 읽을 때 크게 주목하지 않는 단어들이기 때문이고 그렇게 많이 출현 할 것이라고 전혀 생각하지 않았기 때문이기도 합니다.
“생각”의 경우는 동사의 일부분으로 사용된 것도 상당히 많기 때문에 명사만 제대로 카운트 했다고 할 수는 없습니다.
불쌍한 동사파생접미사들은 명사만 남기고 모두 대명사들과 함께 은하계 저편으로 이미 날아갔습니다.
(붙여서 동사로 취급해서 날려 버렸어야 하는데 뭐 그렇게 정성들이고 싶지는 않아서…)

여튼 제가 추측한 원인은
소설의 특성상 이야기를 이끌어 나가면서 주인공과 주변인물들을 비롯한 사람들이 하는 생각에 대해 심리묘사나 설명으로 이야기를 매끄럽게 이어가기 위해서 많이 사용할 수 밖에 없는 것이 아닌가라고 생각했습니다. (지금 제가  쓴 문장에도 “사람”과 “생각”이란 단어가 들어 있습니다만)

그런데 심리묘사를 위해서 많이 쓰기도 했지만 사람과 생각이라는 단어가 상당히 비슷하긴 하지만 여러가지 용도로 많이 쓰이는 것을 확인했습니다. 다목적?
일일히 다 열거하기 귀찮아서 쓰지는 않습니다만 대체할 만한 단어가 있는 경우에도 생각과 사람이라는 단어가 거의 두 세 문장 건너서 한 번씩 출현할 정도로 많이 그리고 다양하게 쓰이고 있었습니다. 대신 그때 그때 사용되는 의미의 차이가 미묘하게 있기는 했습니다. 그다지 중요하지 않은 문장을 중간에 끼워넣기 위해서 쓰이는 경우도 많았습니다. 즉 이야기를 전개하는데 핵심적인 부분에서는 쓰이는 경우는 많지 않았지만 뭔가 당위성이나 이유를 설명하기 위해서 표현한 문장들에서는 대부분 “사람”과 “생각”이 많이 쓰이고 있었습니다.
“사람들은 당연히 그렇게 생각하기 마련이다” 같은 문장 이라든가.
“그런 사람들은 많지 않을 것이 분명했다” 같은.
“그런 생각을 하며 쏜살같이 달려 나갔다” 라던가
물론 모든 소설이나 책들이 이러지는 않을 것이라고 생각합니다. (또 해봐야지)
다음에는 중간급 단어들이 어떤 특성이 나오는지 공휴일에 정말 심심해지면 해볼참입니다.

이 포스트에 결론은 없습니다.
그냥 직접 해보면 예상했던 것과 다른 것이 나오니 심심할 때 꼭 해보자라는 교훈을 답습했다는 것 정도.

 

Posted by & filed under Application.

이슈관리시스템으로 많이 쓰이는 것 중에 JIRA라는 반쯤은 상용인 제품이 있는데
대부분의 이슈관리시스템이 그렇듯이 웹기반으로 되어 있어
Interactive하게 관리하거나 기민하게 업데이트하고 관리하는 것이 조금 불편할 수 있습니다.

Jira는 웹기반이면서도 상당히 interactive하고 깔끔하고 편리한 UI를 제공합니다만
어쨌든 web browser내에서 작업해야 한다는 한계가 있습니다.
작업을 조금 하다보면 다른 사이트나 페이지의 탭에 가려 있어 집중적으로 모니터링하고 관리하기 쉽지 않습니다.

그래서 application 형태의 관리 소프트웨어의 필요성을 느끼게 되는데요.

찾아보니 Jira client라는 것을 ALMworks사에서 판매하고 있었습니다.
10 user 이하의 Jira를 쓰는 경우에는 lite 버전으로 무료로 쓸 수 있고
사용하고 있는 Jira가 10 user가 넘어가면 pro를 구매해야 합니다.
(Jira 서버에 등록된 사용자가 10 user 이하여야 한다는 얘기입니다)

lite버전으로는 10 user가 넘는 Jira에 접속을 하면 제대로 작동을 하지 않습니다.
10 user가 넘는지를 Jira에 접속한 후 확인합니다.
처음에는 10 user가 넘는 Jira server에도 접속이 가능하지만 user 수가 넘는 것이 확인되면
application이 바로 기능을 disable 해버립니다.

pro버전은 30일 trial로 사용하는 것이 가능하니 미리 사용해 보고 구매할지를 결정하는 것이 좋겠습니다.

여튼 lite 버전의 Jira 사용자 수 제한 때문에 결국은 아주 소규모로 관리하는 경우가 아니면
결국 돈을 주고 구매해야 한다는 것이겠고
10명 이하의 Jira그룹에서 Jira client까지 써야 할 정도로 복잡한 관리가 필요할지는 사실 의문입니다.

가격은 좀 비싼편입니다. 1 user용이 99$입니다.

다운로드설치는 아래 사이트를 방문해서 적절한 OS를 선택한 후에 다운받을 수 있습니다.

http://almworks.com/jiraclient/download.html

Jira client의 첫화면

JIRA Client.png
  • 매우 구리구리한 첫 화면
  • 좌 트리, 우 리스트 (좌청룡 우백호?)
  • 마치 메일 클라이언트를 보는 것 같은 화면 구성

거의 모든 Java로 작성된 GUI가 그렇듯이 UI가 그리 미려하지 않습니다.
심지어 font 크기도 조절하지 못합니다만
조금만 사용해 봐도 기능면에서는 상당히 괜찮다는 것을 알 수 있습니다.
Query를 다양하게 만들어서 계속 특정 그룹의 ticket들을 모니터링하거나
자기가 할당받은 issue에 대해서 working timer를 걸어두고
일을 한 후에 소모한 시간과 함께 work log에 update해주는 기능등이 있습니다.

Query 생성 화면

Select a Field to Create Distribution.png

Distribution 생성 화면

Create Query.png

Working Timer Tracker (작업한 시간 카운트)

Time Tracker-1.png

몇시간 써봤는데 상당히 맘에 들어 계속 쓸 생각입니다.
요약을 하자면 Jira client는 다음과 같은 기능들이 아주 괜찮습니다.

  • 작업시간타이머(working timer)는 작업기록(work log)에 기록할 때 일하는 소모한 시간을 타이머로 체크해서 update 기록해 줍니다.
  • Query를 쉽게 만들 수 있고 query 및으로 distribution이라는 것을 만들어서 각각의 세부항목으로 분기시켜 볼 수 있습니다. 몇번의 마우스 클릭 만으로도 잘 분배해 줍니다.
  • 검색이 쉽고 간단합니다.
  • 좌측의 tree 구조가 봐야 할 것들 해결해야 할 것들을 일목요연하게 보여주고 접근하게 해줍니다.
  • 여러 그룹의 Jira를 연결할 수 있습니다.
    • Apache등의 많은 오픈소스가 Jira로 관리되고 있는데 이런것들에 접근하면서 관련된 버그들을 tracking하거나 할 때 편리합니다.

이슈관리는 업무를 진행하는데 있어 매우 중요한 업무도구인 만큼
잘쓰는 것과 효율적으로 쓰는 것이 매우 중요하다고 생각합니다.

Jira의 웹화면 자체에 적응하는 것도 좋지만
웹화면자체에서 작업하는 것이 익숙하지 않거나
애플리케이션만의 빠르고 경쾌하고 고도화된 어떤 것들을 원한다면
업무효율을 위해서 이런 애플리케이션 형태의 클라언트를 사용해 보는 것도 괜찮을 것입니다.

 

참고로 제작사에서 deskjilla라는 bugzilla client도 판매하고 있습니다.
벅질라(Bugzilla) 이슈관리시스템으로 사용하고 있다면 고려해 볼 만 하겠습니다.