일본어 입력 시스템 Sumibi 개발 part29: Jev는 변환 타이밍을 결정할 수 있을까
요약
본 글은 Emacs의 일본어 입력 시스템 Sumibi에 대한 개선 방안을 다룹니다. 기존 방식이 변환 키 없이 자동 변환하는 과정에서, Jev라는 TypeSafe 모델을 활용하여 '변환 시작 타이밍' 자체를 판단하도록 시제품화했습니다. 이를 통해 영어 문장이나 기호가 포함된 경우 불필요한 오작동을 줄이는 데 성공했습니다.
핵심 포인트
- Jev는 변환 결과를 만드는 것이 아니라, 변환이 발동할 최적의 '타이밍'을 판정합니다.
- 벤치마크 결과, 영어 문장 입력 시에는 변환 발동이 0회로 나타나 오작동을 크게 줄였습니다.
- 단순 임계값(threshold)만으로는 '지금도 괜찮다'와 '더 기다리고 싶다'를 구분하기 어렵다는 한계를 확인했습니다.
서론
Emacs 버전 Sumibi의 주변(ambient) 변환은 변환 키를 누르지 않아도 조사나 구두점 등을 계기로 로마자를 일본어로 변환합니다. 편리한 장점이 있지만, 입력된 문자가 영어인지 아니면 계속 이어질 일본어인지를 단순한 규칙만으로 구분하기는 어려운 부분이 있습니다.
이에 이번에는 TypeSafe의 Jev에게 '지금 변환을 시작해야 하는지'를 판정하게 하여, 변환 키를 누르지 않고 로마자 입력 도중에 자동 변환하는 시스템을 시제품화했습니다. Jev는 일본어 변환 결과를 만드는 역할을 하는 것이 아니라, 변환이 발동할 타이밍을 판단하는 역할입니다. 조사용 벤치마크와 결과는 PR #188에, Emacs에서 구동한 시제품은 PR #190에 공개했습니다.
1. 타건마다 변환 여부를 질문하기
로마자 일본어, 영어 문장, 기호, 숫자, 코드 등 47케이스・1239타건을 준비했습니다. 이 벤치마크에서는 키를 하나 누를 때마다 그 시점의 입력 문자열, 직전 키, 입력 후 대기 시간 등을 Jev에게 전달하고, 반환된 0~1의 평가값이 0.8 이상이면 '변환한다'고 판정합니다. 정답 레이블이나 아직 입력하지 않은 문자는 전달하지 않았습니다.
이상적인 변환 위치뿐만 아니라, '여기서 변환해도 좋지만, 조금 더 기다리는 것이 좋은 위치'도 별도로 기록했습니다. 예를 들어 arigatou gozaimasu 의 경우,
arigatou 뒤에서는 일찍 허용되지만, 마지막 공백이 가장 이상적인 위치입니다. 이는 변환 타이밍에 대한 평가이며, 한자 변환의 정확도는 측정하지 않았습니다.
쉘과 암호화 파일을 가정한 2케이스・32타건은 로컬에서 제외하고 API로 전송하지 않았습니다. 남은 1207타건을 Jev jev-1.13.0 및 질문문 v2로 측정했습니다.
전체 측정 결과
| 보고 싶었던 것 | 결과 |
|---|---|
| 영어 문장 15케이스・685타건에서의 변환 발동 | 0회 |
| ... |
'기다리고 싶은 위치에서의 발동'은 변환 내용의 오류가 아니라, 기대보다 빠른 발동을 의미합니다. 아래 3개 그림은 전체 집계와 별도로 측정한 개별 입력 예시입니다.
영어 문장 15건에서는 발동이 0회였습니다. 하단의 장문 예시에서도 91타건 모두 임계값(threshold) 0.8 미만이었으며, 최대값은 0.45였습니다.

선행한 33케이스 비교에서도 현행 규칙의 근사 구현은 영어 문장 240타건에서 7회 발동했고, Jev는 0회였습니다.
이상적인 위치를 놓친 3곳 중 2곳은 반각 !였습니다. 아래 그림에서도 , , . , ? 는 임계값을 초과했고, !는 0.75였습니다. 남은 1곳은 ohayou gozaimasu 의 끝(0.79)입니다. ! 발동 대응은 보류합니다.

세로선은 기호 뒤에 700ms 기다린 판정점입니다.
어려운 것은 '지금도 괜찮다'와 '조금 더 기다리고 싶다'의 구분
arigatou gozaimasu 의 경우 첫 공백이 0.85, 마지막 공백이 0.84였습니다. 둘 다 임계값 0.8을 초과하기 때문에 고정된 임계값만으로는 '지금도 괜찮다'와 '끝까지 기다리고 싶다'를 구분할 수 없습니다.

계속해서 g를 치자 평가값은 0.24로 떨어집니다. 임계값을 0.9로 하면 두 공백 모두에서 발동하지 않으며, 일찍 발동하는 것과 놓치는 것 사이에 트레이드오프가 있습니다.
Emacs 버전으로 시제품화 해보기
벤치마크에서는 조작감을 측정할 수 없기 때문에, PR #190에서 Jev의 판정을 Emacs 버전 주변 변환에 연결했습니다. Jev가 발동 타이밍을 결정하고, 한자 변환은 기존 Sumibi가 담당합니다. 기본값은 규칙 방식 그대로이며, Jev 방식은 명시적으로 선택하는 시제품입니다.
API 문의와 변환은 비동기 방식으로 처리하며, 입력이 진행된 후 도착한 오래된 응답은 폐기합니다. 사용 중인 Emacs에서는 프로그램의 주석이나 문자열 리터럴 내부에서도 동작을 확인했습니다. 변환 키를 누르지 않아도 로마자의 적절한 끊김 지점에서 변환이 발동하며, 생각했던 대로의 사용감을 제공합니다.
정식 채택은 서비스를 판단한 후에
사용 중에는 의도대로 작동했지만, Jev를 Sumibi의 공식적인 종속성으로 삼을지 여부는 아직 보류합니다. 변환 타이밍을 판정하는 서비스 중 어떤 것이 오랫동안 제공될지 파악한 후에 통합하고 싶습니다. PR #190은 시제품으로 공개했으며, 기존 규칙 방식을 기본값으로 유지했습니다.
기술적인 측면에서도 0.8이라는 임계값은 잠정적이며, arigatou 처럼 후속을 기다리지 않고 변환하는 경우도 있습니다. 영어 문장 15케이스에서 발동이 0회라는 결과 역시 모든 입력에서의 안전성을 보장하지는 않습니다. 벤치마크 비용은 매 타건마다 API에 전송했을 경우의 개산이며, 시제품은 전송을 집계하므로 실제 비용은 입력 방식에 따라 달라집니다. Jev의 판정과 한자 변환에는 각각 API 이용료가 발생합니다.
관련 링크
토론

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