카테고리 보관물: 미분류

R과 Interactive visualization의 문제

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 연동까지도 더불어 생각하면 선택의 폭이 더욱더 좁아집니다.

 

R에서 Locale 바꾸기

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


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")

데이터 사이언티스트 (Data scientist)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

형태소분석기와 워드세그멘터

형태소 분석기 정보 모음 (Information POS tagger, word segmenter)

검색과 관련된 업무(정보처리기술과 관련된 직종 또는 관련 업무)를 하게되면 뭔가를 구현하거나 어떤 데이터를 처리해야 할 때 모든 것에 기본적으로 부딪히는 문제의 첫번째가 형태소분석기입니다. 한국어의 특성상 형태소분석기가 없으면 자연어처리가 매우어렵습니다. (반면에 미국 친구들은 정말 쉽게 막가더군요. -ㅁ-)
형태소분석기는 품사를 태깅해주는(무슨 품사인지 마킹해주는)는 라이브러리라고 생각하면 편합니다.
영어로는 POS(Part of Speech) tagger라고 하고 Morphology Analyzer라고도 부릅니다. (의미상으로도 영어는 POS tagger가 맞고 한국어는 Morphology Analyzer가 맞는것 같습니다)

형태소 분석기에서 기본적으로 제공하는 기능은 품사태깅과 자동띄어쓰기입니다. (띄어써야 할 곳에 여백을 만들어주고 동사, 명사, 형용사등의 사자 돌림의 것들이 뭔지 구별해주는..)
품사를 태깅하기 위해서는 띄어쓰기와 기본형 변환등의 문제를 해결해야 하는데 필연적으로 자동띄어쓰기를 지원하게 됩니다. (물론 구현체에 따라 아닌 것도 있습니다.)
워드세그멘터는 품사의 태깅없이 자동띄어쓰기만을 해주는 것을 말하는데 검색의 인덱서에 주로 사용됩니다. (인덱서는 띄어쓰기를 문법에 맞지 않게 과하게 하는 경우가 많습니다만 이게 처리할 때 유리한 점이 많이 있습니다)
보통은 형태소분석기에 품사태깅 도구와 자동띄어쓰기가 함께 포함되어 있습니다.

물론 모든 텍스트 데이터 처리나 텍스트 마이닝이라고 해서 반드시 형태소분석기가 필요한 것은 아닙니다만, 사실상 텍스트 마이닝이나 자연어처리와 관련있는 작업을 하게 되면 대부분의 경우 필요하다고 봐야 합니다.
쉽게 예를들어 오픈소스 검색엔진인 Lucene을 설치해서 뭔가 개인프로젝트나 학생인 경우에 졸업과제 같은 것을 하려고 해도 우선 걸리는 것이 형태소분석기이고, 그 외에도 조금 전문적인일으로 스팸 필터링(Spam filtering), 질의어 분류(Query categorization), 문서 중복 제거(Document Deduplication) 등은 대부분의 경우에 형태소분석기가 없으면 작업이 힘들거나 좋은 성능이나 결과를 포기해야 합니다. 더나가서는 Language Parser라 불리는 구문분석기가 필요해질 때가 있습니다. (보통 NLP에서 영어로 parser라고 하면 구문분석기를 말합니다).
형태소분석기가 없을때 대안으로 하는 것이 N-gram으로 글자(character)를 unit의 기본으로 잡고 처리하거나 하는 원초적인 방법인데 작업도 힘들고 결과물도 대게 좋지 않습니다. 설령 그와 같이 작업이 쉽게 가능하고 비슷한 품질이 나왔다고 해서 향 후에 발생할 모든 잠재적인 문제들에 대해서 미리 대비하는 해결책은 아니라서 섣불리 접근하기 힘듭니다.

보통의 정보처리회사(보통 인터넷기업이나 검색회사 또는 데이터마이닝 회사겠지요)에서는 몇 개의 형태소분석기가 이미 자체적으로 구비되어 있으므로 회사내에서의 업무라면 그냥 가져다 쓰면 되겠지만 개인적으로 하고 싶은 일에는 보통 회사자산을 가져다 쓰면 안되도록 금지 되어 있어, 개인 프로젝트를 할 때 저작권이나 사용료 지불없이 쓸만한 것이 있는지 간단하게 정보를 수집해 봤습니다. (어..논문같은 것을 쓴다거나 할때요)

꼬꼬마 형태소 분석기

세종계획 결과물을 이용해서 제작한 형태소 분석기입니다. 소스코드를 입수할 수 있고 결과물도 나쁘지 않습니다. 소스코드는 별도로 요청을 하셔야 합니다. Java로 만들어져 있습니다. 갱신이 된지 좀 오래되었습니다.

한나눔 형태소 분석기

카이스트에서 만든 형태소분석기입니다. 최근에는 연구용이나 개인용으로는 꼬꼬마 아니면 한나눔을 주로 사용하는 것 같습니다. 한나눔도 Java로 만들어져 있습니다. 최근 업데이트가 거의 없습니다.

KISTI 검색엔진 및 형태소 분석기

실제로 사용해보지는 않았습니다만 괜찮다고 들었습니다.

  • www.kristalinfo.com
  • http://www.kristalinfo.com/K-Lab/idx/
    http://www.kristalinfo.com/K-Lab/ma/

락끄님의 형태소분석기 데모

역시 사용해 보지 않았습니다.

  • http://ids.snu.ac.kr/wiki/Morpheme_Analyzer_Demo

HAM – 강승식 교수님의 Hangul Analysis Module

국내에서는 워낙 유명한 것이라 따로 설명이 필요 없지요. 라이센스비용을 받으시는 걸로 알고 있습니다. 많이는 아니지만 사용해 봤었는데 좋았었습니다. 지금은 사용을 하지 않으므로…

  • http://nlp.kookmin.ac.kr/
  • http://nlp.kookmin.ac.kr/data/han-dic.html – 그밖에 다양한 text문서 자료/프로그램
  • http://nlp.kookmin.ac.kr/down/data/KorStems.zip – 조사/어미 자료

모란소프트 – 조영환 박사님의 형태소분석기 MORAN

안써봐서 잘 모르겠습니다만 나쁘지 않다고 들었습니다.

  • 링크: http://www.moransoft.co.kr/

검색엔진 및 형태소분석기 – PHP형태소 분석기

PHP의 extension인지 native인지 잘 모르겠습니다. PHP전용이라면 쪼끔 그렇습니다. 여러 시스템에 유연하게 연동하는데 불편해서 활용도가 떨어질 가능성이 있습니다. 품질은 잘 모르겠습니다.

  • 링크: http://lab.zagia.com/

이상호님의 KTS

오래전에 작업을 중단하신 걸로 알고 있습니다.

  • http://kldp.net/projects/kts
  • http://chem.skku.ac.kr/~kle/main/KTS

포항공대 NLP연구실

  • http://nlp.postech.ac.kr
    • http://nlp.postech.ac.kr/~project/DownLoad/index.html – binary를 다운로드 받을 수 있습니다
    • http://nlp.postech.ac.kr/DownLoad/cgi-bin/POSTAG/SKOPE99a_demo.tar.gz

이 외에도 찾아 보면 의외로 많이 있습니다.

기타 한글 및 한국어 처리에 도움이 될만한 것들

선택할 때 고려사항

개인적으로 한국어 형태소분석기를 볼 때 응용개발자의 입장에서 중요하게 생각하는 것은 우선 아래 3가지를 먼저 생각하는데요.

물론 형태소분석기 자체를 개발하거나 연구하는 분들의 생각과는 많이 다를 수도 있을 것 같습니다

일관성

결과물이 일관성있게 잘 나와야 합니다. 조그만 차이에도 단어 띄어쓰기나 품사태깅이 들쭉날쭉하거나 예외에 따른 변화가 너무 많거나 후처리로 제어 해야 할 것들이 너무 많으면 후속 작업을 하기가 매우 힘듭니다. 일관성이 영 아닌 것들도 많이 있으므로 쓰기전에 테스트가 필요합니다. 기분석 사전이 얼마나 잘 생성되어 있는지에 따라 달라지는데 본인이 생성한 것이 아니면 테스트 해보기전에 알지 못하는 것이 많습니다. 보통은 알고리즘이나 구현체 문제라기 보다는 학습데이터의 부족과 사전의 부족이 아닌가 싶습니다.

속도

실행속도가 가능한 빠른것이 유리합니다. 형태소분석기의 속도가 왜 빨라야 하는지 잘 이해하지 못하겠다고 말씀하시는 분들이 있는데, 경우에 따라 다 다르겠지만 검색엔진에서 searcher, indexer로 쓰이는 것 외에도 텍스트 처리와 관련해서 서비스 형태(대몬 형태)로 응용구현체가 구동이 되는 경우가 많이 있습니다. 서비스형태의 응용구현체는 형태소분석기가 소모하는 시간이 길면 연산자원이 많이 소요되므로 그 자체로 부담이고 손해입니다. 형태소 분석기 자체가 자원소모가 꽤 많은 편이라 서비스나 운영시스템에 전개하는 것 까지 고려해야할 필요가 있습니다. 최근에는 하드웨어들이 좋아졌기 때문에 형태소분석기의 라이브러리 성능도 심하게 따지지는 않는 것 같습니다만 그럼에도 불구하고 가능하다면 최대한 빠른 것이 좋습니다. 이런 이유의 한가지로 외국산 고성능 형태소 분석기들은 여전히 C/C++로 작성되고 있는 것을 볼 수 있습니다. (다 이유가 있다는…)

유연성

유연성이란 잘못된 것 또는 변화된 상황에 빨리 대처할 수 있게 유연한 장치들을 가지고 있어야 하고 빠르게 대처할 수 있어야 한다는 것입니다. 예외사항이나 특이한 문제가 발생했을 때 사전을 수정하거나 예외 처리를 할 수 있는 각종 장치가 다 마련되어 있어야 합니다. 형태소 분석기를 사용하다보면 도메인(domain)별로 사전을 따로 관리해야 할 수 있습니다. 특히 복합명사나 도메인별로 주로 쓰는 단어에 대한 태깅이 달라지는 문제가 발생할 수 있는데 이럴때마다 형태소 분석기의 기분석 사전을 업데이트하는 것은 위험합니다. 후처리로 해결을 해야 하는데 이런 지원 기능이 내장되어 있거나 추가 구현을 쉽게 할 수 있게 되어 있어야 합니다. 보통은 후처리사전(사용자 사전)과 언어처리를 위한 유틸리티 라이브러리로 후처리를 합니다.
유연성의 또다른 측면으로 여러 응용구현체에서 가져다 쓸 수 있어야 합니다. 형태소 분석기들이 주로 C/C++로 작성되는 또 하나의 이유는 여러 랭귀지들의 패키지로 제공하기 쉽다는데 있습니다. perl, php, python, java 등입니다. 서비스나 응용 구현체를 어떤 것으로 만들지는 알 수 없으므로 가능하다면 많은 시스템에서 적용이 가능한 형태로 되어 있는 것을 쓰는 것이 나중을 대비해서 유리합니다.