한국어와 Tokenizer

한국어는 Tokenizer를 통해 단어를 분리하기가 대단히 어려운 편에 속하는 언어다.
라틴 문자로 된 언어들은 대부분 단어가 띄어쓰기로 구분되고 동사 변형이나 단어의 성별, 복수형 정도만 고려하면 되는데, 한국어는 그것보다 미묘한 변형들이 많기 때문이다.

특히 까다로운 것은 "조사"다. 교착어 특성상 조사가 단어 뒤에 붙는데, 한국어에서는 이걸 규칙적으로 떼어내는 것이 생각보다 어렵다.

여기서는 한국어용 Tokenizer를 선택하는데 필요한 기반지식, 그리고 대표적인 구현체 몇가지를 소개해본다.

기본 개념 정리

Tokenizer를 이해하고 사용하기 위해서는 기본적인 용어나 개념을 좀 알아두는 것이 좋다.
대략 정리해본다.

한국어 품사 태그

다수의 Tokenizer들은 품사 형태에 따라 다르게 추출하고 추출 정도를 다르게 설정할 수 있는 옵션을 제공한다.
여기서 품사를 구분하는 축약어를 사용하는데, 보통 국립국어원에서 정의한 "세종 품사 태그"를 골자로 삼는다.

출처: https://m.blog.naver.com/aramjo/221404488280
구현체마다 조금씩 확장해서 다르게 쓰기도 하는데, 대체로는 이와 비슷하다.
품사 감지가 되는 Tokenizer들은 특정 품사만 남기는 품사 제거가 가능하다.

형태소 분석

한국어 Tokenizer를 다른 말로 형태소분석기라고 부르기도 한다. 형태소분석이 Tokenizer의 역할에 포함되는 관계라서 엄밀히 말하면 좀 다르긴 한데, 이 글에서도 어느 정도 혼용한다.

정확히 말하면 어절을 형태소 단위로 분리어절을 형태소 단위로 분리하는 것을 형태소분석이라고 부른다.
"먹었습니다"가 들어오면, 그것을 최소한의 의미 단위인 먹 / 었 / 습니다 3개로 분리하는 것이다.

이 경우 "먹"은 동사의 어간이다. '먹다'라는 동작의 핵심 의미를 나타낸다.
"었"은 ... 과거 시제를 나타내는 선어말 어미다.
"습니다"는 높임과 평서형을 나타내는 종결 어미이다.

구현 수준이 높고 무거운 Tokenizer들은 모두 이러한 세부적인 분석을 통해 단어를 분리해낸다.

조사 제거 (Particle Removal)

한국어에서 까다로운 부분 중 하나다.
단어 수준의 추출이 필요하면 반드시 중요하게 확인해봐야 하는 부분이기도 하다.

개념 자체가 어려운 것은 아니고, "삼성전자에서"를 "삼성전자" + "에서"로 분리하는 것이다.

근데 이게 응용 수준으로 가면 상당히 까다롭다. 조사 자체는 정해져있으니까 규칙적으로 제거할 수 있는데, 사전에 없는 고유명사가 조사로 끝나는 경우에는 이게 쉽지 않다.

"하늘빛치과" 같은 고유명사가 있다면, 일반적인 Tokenizer는 이것을 "하늘빛치"+"과"로 분리해버릴 수 있다.

Open Korean Text의 경우: 블랑쉬치과를 "블랑쉬치"로 파괴.
이 문제를 방지하려면 "하늘빛치과" 자체를 사전에 등록해야하는데, 이것도 말이 쉽지 모든 단어를 관리하는 것은 사실상 불가능하다. OOV 섹션에서 후출한다.

조사 제거 정도는 거의 모든 한국어 tokenizer가 제공을 하지만, 그 수준에는 차이가 좀 있다.

어근 추출 (Stemming)

텍스트를 정형적인 형태로 분석하기를 원한다면, 어근 추출도 중요한 부분이다.
특정 용어를 원형에 가까운 어근으로 변환하는 것을 말한다. "먹었습니다"를 "먹다"로 바꾸고 "running"
을 "run"으로 바꾸는 것 등이 이에 속한다.

"kiwi", "nori", "mecab-ko" 같은 대형 tokenizer들은 지원하고, open korean text 같은 경량 구현체는 제공하지 않을 수 있다.

Stop Word 제거

필요없는 형태소들을 날려버리는 것을 말한다.
"은", "는", "이", "가" 같은 조사를 제거하거나, 원한다면 추가 사전을 통해서 특정 단어들을 날려버리도록 할 수 있다.

"kiwi", "nori" 같은 tokenizer들은 stop word 사전 관리 기능을 제공한다.

OOV (Out-of-Vocabulary)

형태소분석에서 가장 까다로운 것은 항상 고유명사다.
아무리 잘 구현되어있고 한국어 문장을 잘 분석하게 해놨더라도, 모르는 단어가 포함되면 규칙에 의해서 의도치 않은 분해가 일어날 수 있기 때문이다.
과격하게 형태소 분리를 하는 구현체는 "두쫀쿠"를 "두", "쫀", "쿠"로 분리해버릴 수 있고, "세브란스치과"
를 "세브란스", "치과"나 "세브란스치", "과(조사)"로 분리해버릴 수도 있다.

이렇게 사전에 없는 고유명사가 있는 것, 혹은 그 고유명사를 처리하는 것을 OOV라고 부른다.
OOV를 처리하는 방식에는 몇가지 방식이 있는데, 무엇을 선택해도 100% 완전하게 되는 것은 없다.

1. 사전 관리 (User Dictionary)

고전적으로는 사용자 사전에 고유명사를 추가해서 대응하는 방식을 많이 사용했고, 대중적인 Tokenizer 구현체들은 이 방식을 기본적으로 전부 제공한다.
사전에 추가만 해두면 아주 확실하게 처리가 된다는 것이 보장되지만, 새로운 신조어나 고유명사가 계속 유입될 경우를 대응하는 것이 사실상 불가능하다는 단점이 있다.
게다가 매번 업데이트하고 리로드하는 것도 일이다.

2. 통계 기반 탐지

혹은, 특정 말뭉치가 등장하는 빈도를 기준으로 고유명사를 추론할 수 있다.
soynlp의 Word Extractor나 Noun Extractor 같은 구현체가 이에 속한다.

통계 개념을 적용해서 실시간으로 사전을 관리하는 변형 기법이라고 할 수 있다.

다만 이것도 100% 완전한 것이 아님은 인지하고 있어야 한다.
통계와 사전이 구축되기 전에는 품질을 보장할 수 없는 cold start 문제가 있는데다가, 통계를 기반으로 한 추론이 오탐일 수도 있다.

3. 문맥 기반 탐지

아니면 아예 문맥을 기준으로 명사를 구분하는 것도 방법이다. 이건 단순히 규칙 기반으로 처리하기는 어렵고, LLM처럼 자연어 기반으로 학습된 모델을 사용해야 한다.

kiwi가 이 방식을 써서 경량모델을 내장해놓은 특수한 케이스다.

4. LLM 지르기

사실 그냥 가장 편하고 확실한 방법은 괜찮은 LLM을 쓰는 것이다.
오픈모델을 서빙해도 되고, GEMINI 같은 저렴한 서비스의 경량 모델을 쓰는 것으로도 충분하다.

대신 비용문제, 낮은 가용성/처리량 문제, 락인되는 문제가 생길 수 있다.

Tokenizer 구현체

Tokenizer 구현체는 꽤 여러가지가 존재하고, 구현 수준이나 기능의 종류, 처리량 등이 전부 다르다.
그래서 잘 확인해보고 선택을 해보는 것이 좋다.
여기서는 mecab, nori, kiwi, okt, charabia 정도를 간단히 소개해본다.

Nori (Elasticsearch)

Elasticsearch 환경에서 주도적으로 사용되는 Tokenizer다. 검색용으로 만들어졌다.
Java로 구현되어있고, 조사 제거, 어근 추출 등의 전반적인 기능들을 적당히 잘 제공한다.

현재 Elasticsearch에서 한국어를 쓴다고 하면 이걸 기본값으로 선택하는 편이다.

Tokenizer에 필요한 것들은 얼추 있다. 조사 제거, 어근추출, 품사별 선별 등.
구현 수준은 괜찮은 편인데, Java 구현이라서 아무데나 붙이긴 곤란하다.

Mecab-Ko (은전한닢)

MeCab은 원래 일본어를 위한 형태소 분석기인데, 한국어에 맞게 확장한 구현체가 Mecab-ko다.
C++로 구현체다.

과거에는 Elasticsearch에서 은전한닢(Seunjeon) 플러그인을 통해 많이 사용되었지만, 현재는 Lucene에 기본 포함된 Nori가 널리 사용되면서 사용 빈도가 크게 줄었다.
예전에 은전한닢을 써봤던 기억으로는 미묘하게 구렸다... 지금은 나쁘지 않은 것 같긴 하다만.

사용자 사전 기능을 제공한다. 다만 사용자 사전은 CSV 기반으로 관리되며, 변경 시 사전을 다시 빌드하거나 재로드해야 하므로 실시간으로 동적으로 관리하기에는 다소 불편하다.

OOV 처리는 사용자 사전 수준으로만 제공한다.
그 외에는 기능 수준이 대략 nori와 비슷하다. 품사 식별, 조사 제거, 어근 추출 등 기본적인건 있다.

Kiwi

C++ 구현체다.
언어별 포팅이 괜찮게 제공되고, 편의성이 좋다.
구현 방식이나 기능 수준은 nori와 비슷하거나 더 풍부한 편이다. 그리고 좀 더 범용에 가깝다.

품사 식별, 조사 제거, 어근 추출 등의 기능을 잘 제공하고, OOV 기능도 괜찮게 제공이 되는 편이다.
특히 최신 버전에서는 문맥 감지용 경량 모델을 내장해서 고유명사를 꽤 잘 추출한다.

다음 웹페이지에서 즉시 테스트가 가능하다.
https://kiwi.bab2min.pe.kr/

Open Korean Text

Scala 구현체이나 언어별 포팅 버전이 존재한다.
트위터 같은 SNS의 글에서 키워드를 추출하는 목적으로 만들어졌다.

형태소 분석기라기보다는 가벼운 한국어 텍스트 전처리 도구에 가깝다.
한국어 정규화, 토큰화, 품사 태깅, 어구 추출 등의 기능을 제공하지만, MeCab-ko나 Kiwi, nori처럼 정교한 형태소 분석 품질을 기대하기는 어렵다.

장점은 사용이 쉽고 비교적 가볍다는 점이다.
특히 SNS 문장, ㅋㅋ/ㅎㅎ, 띄어쓰기 오류, 구어체 표현 같은 비정형 텍스트를 다루는 데 강점이 있다.

반면 사용자 사전, 정교한 원형 복원, 품사 인식, OOV 처리, 검색 인덱싱용 품질 측면에서는 한계가 있다.
따라서 고품질 형태소 분석이나 브랜드명 보존이 중요한 시스템보다는, 빠르게 키워드를 뽑거나 비정형 한국어 텍스트를 대략적으로만 정규화하는 용도에 더 적합하다.

charabia

Rust 구현체다. 검색을 목적으로 만들어졌다.
meilisearch에서 자기들 쓰려고 만들었는데, 여기저기서 많이 갖다쓰더라.

이것도 형태소 분석기보다는 범용 Tokenizer에 가깝다.
언어별 특성에 맞게 기본적인 단어 분리와 정규화를 수행하며, 한국어의 경우에도 가벼운 수준의 토큰화를 제공한다.

장점은 매우 가볍고 빠르며, 다국어를 별도의 무거운 형태소 분석기 없이 한 번에 처리할 수 있다는 점이다.
반면 품사 태깅, 원형 복원, 사용자 사전, OOV 처리 등 정교한 한국어 형태소 분석 기능은 제공하지 않는다.

따라서 전문적인 한국어 분석보다는 검색 인덱싱이나 검색을 위한 가벼운 전처리 용도에 적합하다.

참조
https://github.com/meilisearch/charabia
https://github.com/open-korean-text/open-korean-text
https://github.com/bab2min/kiwi
https://bab2min.tistory.com/682
https://datascienceschool.net/03%20machine%20learning/03.01.04%20soynlp.html