LLM 단독 일본어 교정과 kotonoha의 차이점: 진단, 수정, 재확인에 담긴 의미

‘이 글을 자연스러운 일본어로 고쳐줘’라고 대규모 언어 모델(LLM)에게 의뢰하면, 교정 결과를 얻을 수 있습니다. 그렇다면, 일본어 교정 스킬을 갖춘 kotonoha를 사용할 의미는 무엇일까요? 본 기사에서는 글의 우열을 비교하는 것이 아니라, 무엇을 근거로 고치고 어떻게 확인하는지라는 절차상의 차이점을 설명합니다.

kotonoha는 LLM을 대체하는 것이 아닙니다. LLM에 의한 재작성에 독립적인 진단 스크립트와 확인 절차를 결합한 메커니즘입니다.

LLM은 문맥을 읽고 어휘를 선택하며, 설명의 순서나 문체를 조정할 수 있습니다. kotonoha에서도 실제 재작성은 LLM이 담당합니다. GiNZA라는 일본어 분석 도구가 글을 완성본으로 자동 변환하는 것은 아닙니다.

kotonoha가 추가하는 것은, 다시 살펴볼 후보를 찾는 처리와 수정 결과를 확인하는 절차입니다.

LLM 단독 교정
원문 + 지시 → LLM의 판단 → 수정문・설명
kotonoha의 일본어 교정
...

본 기사에서 말하는 ‘LLM 단독’은 외부 진단 스크립트를 사용하지 않고, 프롬프트와 모델 응답으로 교정하는 구성을 의미합니다. LLM 단독으로도 변경 이유 설명이나 자체 점검을 지시할 수 있습니다. 따라서 ‘LLM은 확인하지 못하고 kotonoha는 확인할 수 있다’라고 단순하게 나눌 수는 없습니다.

주요 차이점은, 확인 방법을 그 자리의 지시에 맡길 것인지, 스킬의 절차와 실행 가능한 진단으로 준비해 둘 것인지에 있습니다. kotonoha에서는 변경 금지 정보를 보존하는 것을 불변 조건(invariant condition)으로 삼고, 다음과 같은 확인을 스킬의 절차로 정하고 있습니다.

LLM에게 ‘이 문장은 읽기 어렵다’고 지적받더라도, 길이가 문제인지, 수식 관계가 문제인지, 단순히 문체의 취향인 것인지 모호한 경우가 있습니다. 이유를 물어볼 수는 있지만, 그 설명만으로는 글자 수나 구문을 실제로 측정한지는 확인할 수 없습니다.

kotonoha의 japanese-prose는 GiNZA로 어휘 분할(語の分割), 품사(品詞), 기본형(基本形), 의존 관계(係り受け)를 분석합니다. 그 결과와 미리 정해진 규칙을 사용해서, 다시 살펴볼 후보를 제시합니다.

예를 들어, 기술 문서용 --genre tech에서는 110자를 초과한 문장을 warning, 180자를 초과한 문장을 critical로 처리합니다. 의존 관계에서는 각 토큰이 구문 트리(構文木)의 뿌리에 도달할 때까지의 간선(辺)을 셉니다. 그 최대값이 9를 초과하면 warning입니다.

임계치는 연구에서 실증된 이해도의 경계가 아니라, 구현으로 정한 재검토 기준입니다. 문장의 길이・쉼표・깊이에는 나열 및 추정했을 때 지적을 줄일 수 있는 예외도 있습니다.

측정치가 있다는 것과, 읽기 쉬움을 객관적으로 증명할 수 있는 것은 별개입니다. 독해 시간이나 이해도를 측정하는 것이 아니라, 읽기 어려움으로 이어질 수 있는 특징을 탐지하고 있습니다.

규칙을 사용하는 교정이라고 하면, ‘탐지한 어휘를 모두 고치는’ 처리를 상상할지도 모릅니다. kotonoha에서는 진단 결과를 받아 LLM이 지적을 문맥 속에서 다시 읽어봅니다.

판단은 두 가지입니다.

| 판단 | 의미 |
|---|---| :--- |
fix | 애매함이나 부하를 줄이기 위해, 의미를 보존하며 수정한다 |
keep | 정확성, 분야의 관습, 인용, 의도적인 리듬을 위해 남긴다 |

예를 들어 ‘~하지 않으면 안 된다’는 이중 부정 등을 탐지하는 규칙의 대상입니다. 하지만 요구사항 정의서에서는 의무를 나타낼 필요가 있습니다.

원문: 관리자는, 업데이트 전에 설정 파일을 저장하고는 안 된다.
의미를 보존한 수정 예:
관리자는, 업데이트 전에 설정 파일을 저장할 필요가 있다.
...

규범 표현의 서식이 정해진 문서라면, 원래의 표현을 keep으로 판단하는 경우도 있습니다. 탐지 규칙은 후보를 제시하지만, 채택 여부까지 결정하지는 않습니다.

LLM 단독으로도 마찬가지로 의미를 보존하라는 지시는 내릴 수 있습니다. kotonoha의 차이점은, 탐지 결과마다 수정/유지를 판단하고 불변 조건을 확인하는 흐름을 스킬에 포함하고 있다는 점입니다.

다만, 이 절차만으로는 의미 보존을 보장할 수 없습니다. 수치나 의무의 강도를 바꾸지 않도록 스킬이 지시하더라도, 진단 CLI(명령줄 도구)가 의미 보존을 형식적으로 증명하는 것은 아닙니다. 차이점 확인과 내용 검토는 필요합니다.

LLM 단독으로도 '다시 한번 확인해 달라'고 요청할 수 있습니다. kotonoha에서는 여기에 더하여, 같은 스크립트로 수정 전후를 조사합니다.

진단 결과를 JSON으로 저장하면 다음 실행에서 베이스라인(baseline)으로 지정할 수 있습니다.

예를 들어, 긴 글을 분할하더라도 같은 시작 문장을 연속시키면 새로운 지적이 나올 가능성이 있습니다. 이는 '원래 문제가 사라졌는지'뿐만 아니라, '수정으로 인해 다른 문제를 늘리지 않았는지'를 확인하기 위함입니다.

같은 입력, 스크립트, 설정, 분석 모델과 실행 환경을 통일할수록 진단 결과를 비교하기 쉬워집니다. 반면, LLM에 의한 수정 문장까지 같아지지는 않습니다. 진단의 비교 가능성과 생성문의 재현성은 구분해야 합니다.

베이스라인 대조에도 한계가 있습니다. 카테고리와 정규화된 발췌(抜粋)로 지적을 식별하기 때문에, 표현이 바뀌면 같은 문제라도 신규로 처리될 수 있습니다. 숫자도 정규화되므로, 지적이 지속되고 있다는 것이 수치가 보존되었다는 증거가 되지 못합니다.

차이점을 짧은 예시로 살펴보겠습니다. 다음 문장을 교정 대상으로 합니다.

この機能においては、設定ファイルを編集することが可能です。
管理者は、更新前に設定ファイルを保存しなくてはならない。

수정안은 예를 들어 다음과 같습니다.

この機能では、設定ファイルを編集できます。
管理者は、更新前に設定ファイルを保存する必要があります。

이 수정안은 LLM 단독으로도 생성할 수 있는 것입니다. 본 기사에서는 다른 LLM에 이 문장을 입력하여 비교 실험을 진행하지 않았습니다.

kotonoha에서 주목해야 할 것은 '이 수정문을 생성했는가'가 아니라, 진단 결과와 수정 판단을 대응시킬 수 있다는 점입니다.

| 원문 지적 | 진단 카테고리 | 이 예시에서의 판단 |
|---|---|
| においては | heavy_location_phrase | 'では'로 바꿔도 장면을 나타내는 의미를 유지할 수 있으므로 fix |
| することが可能 | indirect_ability | 'できます'로 간결화할 수 있으므로 fix |
| しなくてはならない | double_negative | 보존의 의무를 지키는 표현으로 바꿔서 fix |

참조 구현의 --genre tech

로 실측했을 때, 수정 전은 3건・94점, 수정 후는 0건・100점이었습니다. 베이스라인 비교는 신규 0건, 지속 0건, 해소 3건입니다.

스코어는 100점에서 감점 방식입니다.

score = max(0, 100 - 10 × critical件数
- 4 × warning件数
- 1 × info件数)

이 예시는 warning가 1건, info가 2건이므로, 수정 전은 6점 감점됩니다. 다만, 100점은 '등록된 진단에서 지적이 없었다'는 의미입니다. 문장의 품질이 6% 개선되었다고 하더라도, LLM 단독보다 우수하다고 보여주지는 못합니다.

본 기사의 참조 구현과 실행 조건은 다음과 같습니다.

작업 디렉토리에서 npm 패키지와 동봉 스킬을 설치합니다.

npm install kotonoha
npx kotonoha install
npx kotonoha --version

앞서의 문장을 before.md와 after.md로 저장하고, 같은 디렉토리에서 실행합니다. Python 의존 패키지는 스크립트 초반부 메타데이터에 따라 uv가 해결합니다.

이러한 명령어들은 진단과 비교를 수행할 뿐, 원문을 수정하지 않습니다. 수정하거나 유지해야 하는 이유 또한 진단 CLI가 생성하는 것이 아니라, 스킬을 따르는 LLM이나 작업자가 기록합니다.

짧은 이메일의 표현 방식을 바꾸거나, 설명 문구를 부드럽게 하거나, 여러 표현 안을 비교할 때와 같은 용도에서는, LLM에게 원문과 목적을 전달하고 출력을 스스로 확인하는 것만으로 충분한 경우가 있습니다.

kotonoha는 진단 실행 및 결과 확인 과정이 늘어나기 때문에 도입과 확인에 번거로움이 따릅니다. GiNZA와 분석 모델을 사용하는 Python 환경도 필요합니다. 짧은 문장의 일회성 교정에서 반드시 이 시스템을 사용할 필요는 없습니다.

반면, 다음 용도에서는 진단과 판단을 분리하는 가치가 있습니다.

의 full 모드에서는, 문장 진단 외에도 독해 부하 진단, 제목/단락 시작 부분 추출, 용어 후보 추출을 수행합니다. 일반 진단과 독해 부하 진단에는 중복이 있기 때문에, 건수나 점수는 합산하지 않습니다.

문서 전체의 구성이나 필요한 정보는 별도의 tech-writer 스킬이 담당합니다. 문장의 자연스러움과 기술 문서로서의 완전성을 분리하여 확인하도록 설계되었습니다.

진단을 추가하더라도 LLM의 판단은 필요합니다. 규칙에 일치하는 부분이라도 실수로 고쳐버리지 않도록 하기 위함입니다.

예를 들어, '1년 동안 걸쳐 감시하다'의 '을 거쳐'는 등록된 진단 대상입니다. 하지만 기간을 나타내는 의미가 있기 때문에, 단순히 중복 표현으로 삭제해서는 안 됩니다. 인용 중인 정형구나 형식을 맞춘 절차에도 비슷한 주의가 필요합니다.

또한, 진단 대상은 문서 전체가 아닙니다. Markdown에서 본문을 추출할 때, 제목/표의 행/펜스로 둘러싸인 코드는 제외됩니다. 본문의 진단이 100점이라 해도, 표의 오기나 코드 예제의 문제는 별도로 확인해야 합니다.

이 점수만으로는 사실의 정확성이나 논거의 충분성을 판단할 수 없습니다. 독자가 실제로 이해했는지도 알 수 없습니다. 문서가 길수록 지적 사항이 늘어나기 쉬워, 점수를 다른 문서나 저자의 순위 매김에 사용하는 것도 부적절합니다.

진단 스크립트는 로컬에서 실행할 수 있지만, 교정 전체가 오프라인으로 완결된다고 할 수는 없습니다. 본문을 LLM에게 전달할 때는, 이용하는 실행 환경이나 모델 제공처의 설정에서 데이터 취급을 확인해야 합니다.

종료 조건도 100점이 되는 것이 아닙니다. 모든 지적 사항에 판단이 내려지고, 새롭게 수정해야 할 지적 사항이 없으며, 변경 금지 정보가 보존되는 것입니다. 편집과 재진단은 1회 스킬 실행으로 최대 3라운드까지 하며, 해결되지 않으면 미해결 항목을 보고합니다.

LLM 단독과 kotonoha의 차이는 '어느 쪽이 일본어를 아는가'에 있지 않습니다. 둘 다 LLM의 문맥 이해와 생성 능력을 사용합니다.

수정문을 빠르게 얻고 싶다면, 우선 LLM 단독으로 충분할 때가 있습니다. 수정 이유를 공유하고 같은 기준으로 반복 확인하고 싶다면, kotonoha처럼 진단과 리뷰 절차를 결합하는 의미가 있습니다.

최종적인 문장이 같더라도, 어디를 측정했고, 무엇을 고쳤으며, 무엇을 의도적으로 남겼는지 확인할 수 있습니다. 그 확인 자료를 추가하는 것이 kotonoha 일본어 교정의 특징입니다.

아래 kotonoha 링크는 본 기사에서 참조한 커밋에 고정되어 있습니다.