
일본어 입력 시스템 Sumibi 개발 part19: mozc와 LLM의 하이브리드 변환
요약
일본어 입력 시스템 Sumibi 개발 과정에서 mozc의 빠른 응답성과 LLM의 타이포 내성을 결합한 하이브리드 변환 방식을 소개합니다. mozc로 즉시 가확정 결과를 보여주고 LLM 결과로 덮어쓰는 프로그레시브 변환 UI를 제안합니다.
핵심 포인트
- mozc의 즉각적인 응답성과 LLM의 문맥 추론 능력을 결합
- 타이포에 취약한 사전 기반 방식의 한계를 LLM으로 보완
- 프로그레시브 변환을 통해 LLM의 레이턴시 문제 해결
- Emacs 오버레이 기능을 활용한 사용자 경험 최적화
서론
새로운 시도로써, mozc와 LLM을 결합한 하이브리드 변환에 도전하고 있습니다.
저는 지금까지 여러 개의 IME를 개발해 왔습니다. 그중 하나인 mozc-modeless는 mozc만을 사용하여 모드리스(modeless) 변환을 실현하고 있습니다. 반면, Sumibi는 LLM만을 사용하여 모드리스 변환을 실현하고 있습니다.
이 두 가지 접근 방식에는 각각 다음과 같은 트레이드오프(trade-off)가 있습니다.
mozc: 변환 응답이 거의 즉각적이지만, 타이포(typo)에 취약함 -
LLM: 타이포에는 강하지만, 변환 응답에 시간이 걸림
그래서 양측의 장점을 결합할 수 없을까 생각한 것이 이번 하이브리드 변환입니다.
트레이드오프에 대하여
앞서 언급한 트레이드오프를 몇 가지 관점에서 정리하면 다음과 같습니다.
| 관점 | mozc | LLM |
|---|---|---|
| 변환 응답 | 거의 즉시 | 수백 밀리초~수 초 |
| ... |
변환 응답
mozc는 사전 기반의 변환 엔진이므로, 입력으로부터 거의 지연 없이 변환 후보를 반환해 줍니다. 타이핑 템포를 깨뜨리지 않고 입력할 수 있다는 점은 일상적으로 문장을 쓰는 데 있어 큰 이점입니다.
반면 LLM은 추론에 일정 시간이 소요됩니다. 네트워크를 통한 API를 사용하는 경우에는 그 레이턴시(latency)도 더해지기 때문에, mozc와 같은 '노 타임(no-time)' 경험은 되지 않습니다.
타이포에 대한 내성
mozc는 입력된 읽기(yomi)를 그대로 사전과 대조하기 때문에, 오타가 있으면 의도한 변환에 도달할 수 없습니다. 예를 들어 「お疲れさまです(수고하십니다)」라고 치려다가, 급한 나머지 모음이 빠졌다고 가정해 봅시다.
mozc는 이처럼 중간에 변환할 수 없는 알파벳(s)이 남은 망가진 결과로 취급해 버립니다. 이 정도로 망가지면 아무리 변환 후보를 따라가도 목적하는 단어에 도달할 수 없습니다.
LLM은 전후 문맥으로부터 "원래는 이렇게 쓰고 싶었겠구나"라고 추측할 수 있기 때문에, 약간의 타이포가 있어도 올바른 결과로 보정해 줍니다. 모드리스 변환처럼 로마자 상태로 긴 문장을 한꺼번에 입력하는 스타일과는 특히 궁합이 좋은 특성입니다.
왜 하이브리드인가
지금까지 살펴본 것처럼, mozc와 LLM의 장점과 단점은 정확히 반대되는 관계에 있습니다. 양자를 잘 결합하면 서로의 약점을 보완할 수 있을 것입니다.
이것이 이번 하이브리드 변환을 시도하고자 생각한 동기입니다.
어떤 UI로 만들 것인가 — 프로그레시브 변환
mozc와 LLM을 어떻게 결합할 것인가. Sumibi에서는 **프로그레시브 변환(progressive conversion, 2단계 변환)**이라는 접근 방식을 채택하기로 했습니다. 한마디로 말하면, 빠른 mozc의 결과를 먼저 '가확정'으로서 즉시 보여주고, 나중에 도착하는 LLM의 결과로 덮어쓰는 구조입니다.
변환이 실행될 때의 흐름은 다음과 같습니다.
[Ctrl-J]
│
├─(즉시)로마자 → 히라가나
...
mozc는 로컬에서 거의 무지연으로 동작하므로, Ctrl-J를 누르는 순간 이미 가확정이 표시됩니다. LLM의 결과를 기다리는 동안 화면에 아무것도 나오지 않아 "기다려야 한다는 느낌"이 드는 문제를 이로써 거의 해소할 수 있습니다.
「가확정」은 오버레이로 겹치기만 하면 된다
여기서의 포인트는 가확정을 버퍼(buffer)에 직접 쓰지 않는 것입니다. Emacs의 오버레이(overlay) 기능을 사용하여, 입력된 로마자 위에 mozc의 변환 결과를 겉모습만 겹쳐서 표시합니다. 글자 색(face)을 바꿈으로써 "이것은 아직 가상태입니다"라는 것을 한눈에 알 수 있게 합니다.
버퍼의 실체는 로마자 그대로이므로, LLM의 결과가 도착하면 오버레이를 지우고 해당 영역에 정식 텍스트로서 삽입하기만 하면 됩니다. undo(취소)도 깔끔하게 하나의 단위로 묶이며, 구현 측면에서도 리스크가 낮습니다.
LLM이 느려도·실패해도 곤란하지 않다
이 구조의 좋은 점은 기다리는 느낌이 사라지는 것뿐만이 아닙니다.
네트워크가 느리거나 LLM이 타임아웃(timeout)·실패하더라도, 이미 표시되어 있는 mozc의 가확정을 그대로 확정시키면 됩니다. 로컬에서 고속으로 동작하는 mozc가 폴백(fallback)으로서 작동하기 때문에 입력 리듬이 끊기지 않습니다.
Ctrl-J뿐만 아니라 자동 변환에도 효과적
이 프로그레시브 변환은 Ctrl-J에 의한 명시적인 변환뿐만 아니라, 조사나 구두점을 계기로 자동으로 변환이 실행되는 "앰비언트 변환(ambient conversion)"에도 적용합니다. watashiwa
ような 짧은 입력에서도, 우선은 mozc의 결과가 즉시 눈에 보이게 됩니다.
참고로, 이 기능은 기본적으로 비활성화(opt-in) 상태로 두며, mozc_emacs_helper를 찾을 수 없는 환경에서는 자동으로 꺼지도록 할 예정입니다.
마지막으로
이번에는 mozc와 LLM을 결합한 하이브리드 변환(hybrid conversion)이라는 새로운 시도에 대해 소개했습니다.
mozc의 "빠르지만 오타(typo)에 취약하다"는 특성과, LLM의 "오타에 강하지만 느리다"는 특성은 서로의 약점을 보완할 수 있는 관계에 있습니다. 평소 입력 시에는 mozc의 경쾌함을 활용하고, 오타나 모호한 입력으로 막혔을 때만 LLM의 영리함에 의지하는—그런 구분된 사용이 가능하다면, 양쪽의 장점만을 취할 수 있지 않을까 생각합니다.
아직 시행착오를 거치는 중이지만, 실제로 사용해 보니 속도와 영리함의 균형이라는 측면에서 보람을 느끼고 있습니다. 앞으로도 계속 사용하며 변환의 정밀도나 전환 메커니즘을 다듬어 나가고자 합니다.
여기까지 읽어주셔서 감사합니다.
Discussion

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기