꼬꼬마(kkma)의 메모리 효율 문제 - konlpy 품사 태거에 대해

꼬꼬마가 konlpy 태거 중에 품사 태깅 결과가 가장 마음에 들었었다. 

그러나 문제는 이를 heroku에 배포 시 2000MB가 넘는 메모리를 사용하며 E15 에러와 함께 뻗어버린다는 것이다.

heroku에서는 무료 서버가 아닌 돈을 지불하는 서버도 1000MB는 꽤나 고가이다. 그렇기 때문에 꼬꼬마가 태깅 실력이 좋다 했도 사용할 수가 없다. 

 

konlpy memory를 검색어로 구글에 검색을 했을 때 kkma 메모리가 연관 검색어로 뜰만큼 kkma는 메모리를 많이 차지한다. 

구글 연관 검색어

심지어 꼬꼬마 공식 홈페이지에도 메모리 얘기가 나와있다.

꼬꼬마 한글 형태소 분석기는 Java 라이브러리로써 jar 파일 형태로 배포한다. 배포하는 jar 파일을 내려받아 형태소 분석기를 사용할 프로젝트의 classpath에 이 파일을 추가하면 형태소 분석기를 사용할 수 있다. Java1.5 이상의 가상 머신 (Virtual Machine)에서 무리 없이 동작한다. 그러나 기분석 사전을 이용하기 때문에, 사전을 메모리에 적재하기 위한 충분한 힙 메모리를 지정해주어야 한다. 따라서 512MB 이상의 메모리를 지정할 것을 권장한다.

512MB면 heroku dyno 기본 메모리 양이다. 너무 크다.

 

그래서 실험해본 결과 꼬꼬마 다음으로 품사 태깅이 잘 되었던 코모란(komoran)을 사용하기로 했다.

코모란 공식 홈페이지에 보면 메모리 사용이 적다고 강조하고 있다. 자신이 있는 것이다.

겨우 50MB 메모리 상에서도 동작이 가능하다고 적혀있다.

 

 

 

하지만 테스트해본 결과 이는 JAVA로 작성된 komoran 코드(konlpy wrapper가 아닌) 구동 시에만 해당되는 내용인 듯하다. heroku에서 konlpy.tag.Komoran으로 테스트 결과 komoran 역시 메모리 부족으로 worker가 죽는다. 메모리 문제에서 살아남는 건 오직 Okt 뿐이었다.

Kkma도 200MB 이상을 요구하다가 뻗었으며 mecab은 heroku에서 설치가 쉽지 않아 시도해보지 못했다.

 

 

코모란의 마지막 특징 "타 형태소 분석기와 달리 공백이 포함된 형태소 단위로 분석이 가능합니다"

이 부분이 독이 될 수도 있겠지만 성능 개선이 이루어진다면 굉장한 장점이 될 것이다.

예를 들어 "영등포 구청"이 자주 등장한다면 "영등포"랑 "구청"보다는 "영등포 구청" 자체가 키워드가 되는 게 적합할 것이다.

 

komoran 공식 홈페이지

www.shineware.co.kr/products/komoran/

KOMORAN @ Shineware

 

 

okt는 사용할 수 없는 이유가 있다. 명사의 범위가 너무 넓다는 점이 문제가 된다. 유효한 키워드 추출을 위해서는 의존명사, 수사는 배제해야만 한다. 그러나 okt를 사용하면 의존명사, 수사까지 모두 하나의 명사로 태그를 하기 때문에 현재 프로젝트에는 적합하지 못하다.