
⚠️섞으면 위험. "일본어가 아닌 문자"에 대한 대책 방법
요약
AI가 일본어를 작성할 때 유사한 형태의 중국어 간체자를 혼용하는 '오기 문자' 문제의 발생 원인과 메커니즘을 분석합니다. 이는 전통적인 인코딩 오류인 글자 깨짐(Mojibake)과 달리, AI의 학습 데이터 구조상 발생하는 선택의 오류임을 설명합니다.
핵심 포인트
- AI는 다국어 학습 과정에서 유사한 문맥의 한자를 혼동하여 잘못 선택함
- 전통적인 글자 깨짐(Mojibake)은 인코딩 불일치 문제이나, AI 오기는 생성 시점의 착오임
- 폰트에 따라 일본어 한자와 중국어 간체자가 구분하기 어려워 탐지가 매우 까다로움
- Claude Code 등 최신 AI 도구에서도 발생하는 언어 간 간섭 현상
【섞으면 위험⚠️】일본어 한자와 일본어가 아닌 한자
오랜만입니다, 엔지니어가 아닌 방류 사회과학계 연구자입니다.
Claude Code를 중심으로 Codex, Gemini와 공존투쟁하고 있는 매일, 여러 가지를 시스템화(연구 환경 구축)해 나가는 것은 매우 흥미롭습니다. 구축한 「외부 뇌 (External Brain)」도 상당히 재미있는 구조로 발전시켰습니다 (아, 그 이야기는 나중에 따로, 「외부 뇌」 구축에 대해서는 제1탄과 제2탄에 적어 두었습니다).
다만 한 가지, 제 머리를 아프게 하는 것이 오기 문자 (Mistake Characters) 문제입니다.
이, 일본어가 아닌 (일본어에서는 통상적으로 사용하지 않는) 한자나 문자가 섞이는 문제를 어떻게 회피할 것인가? 하는 문제는 「외부 뇌」가 발전하면 할수록 커졌습니다.
예를 들어,
- 「
報告」라고 적혀 있어야 할 곳이 「报告」가 된다 - 「
構造」라고 적혀 있어야 할 곳이 「构造」가 된다
이것들은 중국어 간체자(Simplified Chinese)로 바뀌어 버린 예입니다.
저는 이러한 오기를 하지 않으며, 언뜻 보기에 "어라? 틀렸네"라고 알 수 있지만, Claude Code는…… 이러한 차이를 처음에는 몰랐다고 합니다.
"왜 모르느냐?"라고 물었더니, 똑똑한 그들 AI는 영어도 중국어도 독일어도, 그리고 일본어도 대량으로 학습하고 있기 때문에, "일본어를 쓰고 있다고 생각하면서 옆 선반에 있는 중국어 한자를 무심코 집어오는 경우가 있다"고 합니다.
애초에 옆 선반이 대체 뭐냐고??
더 까다로운 것은, 폰트에 따라서는 일본어 한자와 거의 구분이 안 되는 간체자가 존재한다는 점입니다. 이것은 AI가 찾아내는 것이 거의 불가능하며, 일본인인 저조차도 발견하기 어렵습니다 (노안이면 괴롭습니다). Claude Code의 체크 기능을 빠져나가, 저 자신이 "왠지 위화감이 있다"라고 감각적으로 찾아내는 경우가 종종 있었습니다.
【전제】AI는 왜 일본어를 틀리는가—전통적인 글자 깨짐(Mojibake)과는 별개
"글자 깨짐 (Mojibake)"
이라고 하면, 메일이나 웹 페이지가 "縺ゅ↑縺溘"와 같이 되는 그 현상을 떠올리는 분이 많을 것이라고 생각합니다. 사실, AI에 의한 오기 문자는 발생 메커니즘이 완전히 다릅니다.
전통적인 「글자 깨짐」은 「변환표의 불일치」로 발생한다
컴퓨터 안에서 문자는 모두 "번호"로 관리됩니다 (예를 들어 「あ」는 12354번). 그리고 번호와 문자를 연결하는 변환표 (문자 코드 (Character Code). UTF-8이나 Shift_JIS 등)가 세상에 여러 개 있습니다. 작성한 사람이 UTF-8 표로 저장했는데, 읽는 쪽이 Shift_JIS 표로 열면 번호의 해석이 전부 어긋난다——이것이 전통적인 글자 깨짐입니다.
예: 「あなたのデータ」를 이 방법으로 깨뜨리면 「縺ゅ↑縺溘�ョ繝�繝シ繧ソ」가 됩니다 (직접 재현).
이 경우의 「글자 깨짐」에는 두 가지 특징이 있습니다.
-
전체가 일제히, 규칙적으로 깨진다 (보는 순간 알 수 있다).
-
그리고 올바른 표로 다시 읽으면 원래대로 돌아온다 (세상에 「글자 깨짐 복구 툴」이 있는 것은 이 때문입니다).
오기 문자는 「쓰는 순간의 착오」로 발생한다
반면, AI에 의한 「글자 깨짐 한자」는 변환표는 어디도 틀리지 않았습니다. 저장도 표시도 전부 정상입니다. 망가진 것은, AI가 그 글자를 선택한(쓴) 순간입니다.
저의 「외부 뇌」 운용에서 관측된 착오는 크게 두 가지 패턴이 있었습니다.
패턴 1: 비슷한 글자의 착오
AI는 일본어·중국어·영어를 뒤섞어서 학습하고 있습니다. 「報告」와 「报告」는 학습 데이터 속에서 거의 같은 문맥에 등장하므로, AI의 머릿속에서는 "이웃"입니다. 일본어를 쓰고 있다고 생각하면서 옆 선반(!)에 있는 간체자를 휙 집어버린다.
게다가 헷갈리게도, 똑 닮은 글자는 관리 번호까지 이웃인 경우가 있습니다.
일본어의 「増」는 22679번, 중국어의 「增」는 22686번——불과 7번 차이입니다.
참고로 이 「報告」와 「报告」, 「増」와 「增」의 착오는 초기에 빈번하게 발생했던 현상이었습니다.
패턴 2: 번호의 오기
AI가 프로그램 경유로 문장을 파일에 쓸 때, 문자를 "번호 지정" ( 「を」라면 \u3092 라는 형식)으로 쓰는 경우가 있습니다. 여기서 번호를 한 자리 잘못 적으면 완전히 다른 글자가 나옵니다.
예: 「を」는 3092번 (16진 표기), 「げ」는 3052번. 한 자리 차이이기 때문에, "~를 한다"라고 쓴 셈이 "~게 한다"가 되어 버린다. 또한 인간도 "~를 한다"라는 문맥이라고 상정하고 문장을 읽으면 "~게 한다"를 읽기 넘어가 버리는 (오인하는) 일이 일어나기 쉬워 까다롭습니다.
패턴 3: 언어 자체가 섞이는 경우 (한글·키릴 문자 사례)
드물게 한글이나 키릴 문자가 섞이는 경우가 있었습니다. 이는 패턴 1과는 메커니즘이 조금 다르다고 생각합니다.
한국어는 한자를 공유하지 않기 때문에, '같은 단어의 다른 표기'라는 오인 대상이 없습니다. 하지만, 일본어와 한국어는 문법적 골격이 거의 같다 (어순이 같고, 조사가 뒤에 붙음)는 점이 원인이 됩니다.
예: 「設定を確認」의 「を」 위치는, 한국어 「설정을 확인」의 「을」 위치와 구조적으로 동일. 따라서 조사 슬롯(slot)에서는 한국어 조사가 '문법적으로 가장 그럴듯한 다음 후보'가 되어, 그 순간 언어 스위치가 전환되면서 한글 문자가 유입될 수 있다.
나아가 또 다른 유형으로, 단어 자체가 통째로 다른 언어로 교체되는 유형도 있었습니다.
예: 「操作(조작)」가 러시아어인 「операции」로 되어 있었다. 의미가 같은 단어 (操作/operation/операции)는 AI의 머릿속에서 같은 선반에 나열되어 있다. 그래서 문자와 문법을 공유하지 않는 언어로부터라도, 의미의 유사성만으로 단어가 날아온 것이다.
참고로 키릴 문자는 의외로 일본어 공식 명부(JIS 규격)에 수록되어 있습니다 (2026년 7월 현재). 즉, 명부 대조 (명부에 존재하는 문자는 OK라는 규칙) 방식으로는 문자 오류를 잡아내지 못하는 문제가 남습니다.
한글 문자와 키릴 문자의 혼입은 '구문의 유사성'과 '의미의 유사성'이라는 차이가 있지만, AI 내부에 '문법 판별 장치'와 '의미 판별 장치'가 별개로 존재하는 것은 아닙니다. 둘 다 동일한 메커니즘—다음 글자의 확률 선택—위에서 일어나고 있습니다.
오류를 발생시킨 요인의 차이는, 오류 후보의 출현 확률을 높인 '유사성'의 종류입니다. '의미의 유사성'은 문법이 완전히 다른 언어에서도 오류 문자(단어)가 날아옵니다 (키릴형: 날아오는 것은 명사나 형용사이며, 문장의 뼈대는 일본어 그대로 유지됨).
'구문의 유사성'은 문법이 평행한 언어로부터만 조사와 같은 기능어가 오류 문자로 날아옵니다 (한글형).
즉, 모든 것이 동일한 벡터 공간(vector space) 상의 사건이며, 작용한 '유사성'이 다를 뿐—이라는 것이 실태에 가까운 이해라고 생각합니다.
패턴 4: 괄호·기호 계열의 오인은 다발 장르
단순히 기호의 형태나 모양을 틀리는 케이스는 빈번하게 발생합니다.
그리고 이것이 가장 까다롭다면 까다롭습니다. 겉모습이 닮았거나, 틀리는 로직을 파악하기 어렵기 때문입니다.
예: 가타카나가 「゠」(U+30A0)로 변함
예: 「・(가운데 점)」이 「〓」나 「ヾ」로 변함
예: 한국어 자모 「ㄱ」이 단독으로 섞여 들어옴
결국에는, 검출해서 고칠 수밖에 없습니다.
【대처 방법】 '변환'이 아닌 '검출'
예전 방식의 글자 깨짐(mojibake)은 올바른 변환표만 알면 기계적으로 복원할 수 있습니다.
하지만 AI의 오류 문자는, '본래 무엇이라고 쓰고 싶었는지'에 대한 정보가 남지 않기 때문에 대응표 등으로 일괄 변환을 할 수 없습니다. 우리(AI & 인간)가 할 수 있는 것은 '섞인 글자를 찾아내어, 사람 혹은 AI가 고치는 것'입니다.
이 끝없는 작업을 어떻게든 효율화하고 싶었습니다. 그래서 체커(checker)를 만들었습니다.
【시도 ①】 '희귀한 한자를 의심하라' 작전
AI가 틀리는 한자는 희귀한 한자일 것이다. 그러니 '좀처럼 나오지 않는 한자'를 의심하면 된다.
라는 가설 아래 대책을 세웠습니다. 하지만 즉시 NG 판정을 받았습니다.
실패 이유 그 1: '희귀함'의 정의가 불명확함
'희귀함'을 컴퓨터가 판단하려면 출현율 등 명확한 수치 기준이 필요합니다. 하지만 그런 것이 사전에 존재할 리가 없습니다. 결국, '문제 없음'이라고 판정된 문장을 더블 체크해 본 결과, 오류 문자가 실재하고 있었습니다.
또한, '전체 문장 체크'라고 지시해도 AI에 따라서는 요령을 피우는 경우도 있습니다...
'찾지 못했다'는 '없다'를 의미하지 않는다——이것 때문입니다.
실패 이유 그 2: 억울한 사례 (누레기누)
반대로, 올바른 일본어임에도 불구하고 단지 '희귀하다'는 이유만으로 의심받는 글자가 속출하기도 했습니다.
「憂鬱(우울)」, 「卓越(탁월)」, 「繊維(섬유)」…… 모두 훌륭한 일본어입니다. 어떤 페이지에서는 십수 건의 '의심스러운 글자'가 올라왔고, 조사해 보니 **전부 무죄(정상)**로 판명되어 사태가 커진 것은 이러한 어려운 한자군 때문이었습니다.
억울한 사례가 많아지면 확인하는 인간이 지치게 되고 (AI도 지친다, 아니 요령을 피운다), 진짜 오류를 놓치게 됩니다.
즉, '희귀한지 여부'는 오류 문자의 판정 기준으로
애초에 적절하지 않았습니다.
【운용 버전】 '공식 명부'와의 대조
일본어에서 사용하는 한자에는 국가 규격으로 정해진 공식 명부인 「JIS 규격」이 있습니다. 컴퓨터에서 일본어를 다루는 메커니즘은 이 명부를 바탕으로 만들어져 있습니다. 그리고,
중국어 간체자(Simplified Chinese)는 일본어 명부에 실려 있지 않습니다.
그렇다면 이야기는 간단합니다. 문장의 한자를 한 글자씩 「명부에 실려 있는가?」라고 대조하면 되는 것입니다. 실려 있지 않다면 틀린 글자입니다. 「희귀한가」라는 모호한 기준에서 「명부에 실려 있는지 여부」라는 흑백이 분명한 기준으로 전환했습니다.
이 전환을 통해, 놓치는 것과 억울한 피해(ぬれぎぬ)를 입히는 것이 동시에 사라졌습니다.
- 전체 문장을 한 글자씩 대조하므로,
놓치지 않음 - 「憂鬱(우울)」도 「卓越(탁월)」도 명부에 실려 있는 정규 일본어이므로,
억울한 피해를 입히지 않음
패턴 3에서 언급한 한글 문자도 일본어 명부에 전혀 실려 있지 않기 때문에, 동일한 대조를 통해 그대로 검출할 수 있다는 장점도 있습니다.
【남은 빈틈: 주의 요망 리스트 작성】 한자의 세계는 심오하다
솔직히 고백하자면, 이 [운용 버전]에는 빈틈이 있었습니다.
중국의 지명이나 인명을 쓰는 용도 때문인지, JIS 규격에는 일부 중국어가 실려 있습니다. 그래서 별도로 주의 요망 리스트를 작성했습니다.
- Unicode가 무료로 공개하고 있는 **「한자의 호적부」(Unihan 데이터베이스)**에는 글자마다 「이것이 간체자인가」라는 정보가 실려 있습니다. 거기서 간체자 6,462자를 추출합니다.
- 이번에는 간체자 리스트 측에 대조해 봅니다 (즉, 「간체자인데 일본어 명부에 실려 있는 글자」를 기계적으로 전부 뽑아보았습니다).
- 결과,
98자의 해당 한자가 드러났습니다. - 여기에 더해, 간체자 표시가 없는 중국어 전용 글자(吧・哪・啊・您 = 중국어의 조사나 호칭) 및 명부 중심부에 예부터 섞여 있는 중국어 빈출자(个・广・儿)도 보완하여, 결과적으로
중국어 계열의 주의 요망(한자) 리스트로 총 105자를 작성했습니다.
나아가, 「외부 뇌」 운용을 통해 축적해 온 「AI의 오자 기록(421건/2026년 7월 현재)」과 대조해 본 결과, AI가 구자체(Old Character)를 써버리는 오류도 실제로 확인할 수 있었습니다.
예: 收→収, 對→対, 增→増 등
구자체는 일본어 명부에 정당하게 실려 있는 일본어이기에 판단이 까다로운 부분이지만, 현대 문장에서 AI가 멋대로 썼다면 우선 오류라고 간주합니다.
이에 따라, 실제로 오류로 관측된 구자체 15자를 주의 사항과 함께 주의 요망 리스트에 추가했습니다. 주의 사항이란—인명이나 고전 인용에는 구자체가 올바르게 사용되기 (假屋崎 씨, 續木 씨, 增田 씨 등) 때문에, 그러한 문장을 조사할 때는 이 그룹을 제외하라는 내용입니다.
요약하자면, 주의 요망 리스트는 중국어 계열 105자 + 구자체 15자 = 총 120자입니다.
(다음에 소개할 스크립트 상에서 SIMP라는 변수(+구자체 추가 행)가 이 주의 요망 리스트입니다.)
【사용해 보자】 복사 붙여넣기로 작동하는 오자 체크 도구
이상의 내용을 바탕으로, 간단하게 오자의 유무를 체크할 수 있는 체크 도구를 만들어 보았습니다.
아래 스크립트를 복사해서 사용하세요.
Python의 표준 기능만으로 작동하므로, 추가 설치는 아무것도 필요 없습니다
# 오자 체크 도구 (복사 붙여넣기로 작동합니다 ・ Python 표준 기능만 사용)
# 사용법: python3 mistake_kanji_check.py 조사할파일.txt
import sys
...
사용 방법은 3단계
- 위의 코드를
mistake_kanji_check.py라는 이름으로 저장한다. - 조사하고 싶은 문장을
memo.txt등의 텍스트 파일로 저장한다 (AI의 답변을 복사 붙여넣기 하면 OK). - 터미널(Windows는 명령 프롬프트)에서 다음을 실행한다.
python3 mistake_kanji_check.py memo.txt
실행 결과 예시
【테스트 케이스】
今日の报告를 まとめました。
憂鬱な天気ですが、構造は卓越しています。
データの时系列を确認しました。
【결과】
1행目: 「报」 ← 이 행에 있습니다: 今日の报告를 まとめました。
3행目: 「时」 ← 이 행에 있습니다: データの时系列を确認しました。
3행目: 「确」 ← 이 행에 있습니다: データの时系列を确認しました。
틀린 한자(报・时・确)만 행 번호와 함께 나타나며, 맞지만 희귀한 「憂鬱」, 「卓越」에는 억울한 피해를 입히지 않았다는 점에 주목해 주세요.
그 후 해당 행을 열어 올바른 한자(報・時・確)로 고치기만 하면 됩니다.
【활용 이미지】
【주의】 딱 두 가지만 알아두었으면 하는 점
① 「찾지 못했다」 = 「제로(0)」가 아니다
2026년 7월 현재, 이 체커(Checker)가 찾아낼 수 있는 것은 「명부에 실려 있지 않은 글자」와 독자적으로 작성한 「주의 요망 리스트의 글자」뿐입니다.
예를 들어, 올바른 일본어 한자임에도 다른 글자로 변해 있는 경우(「時」가 「侍」로 되어 있는 등)는 일본어 명부에 실려 있기 때문에 검출할 수 없습니다.
따라서 체커가 말할 수 있는 것은 「찾았다」 혹은 「찾지 못했다」뿐입니다.
일본어로서 문장이 틀리지 않았다는 증명이 아니다라는 점을 유의해 주세요.
그렇다면 어느 정도나 포착할 수 있을까요?
본인의 「외부 뇌 (External Brain)」 운용 중 실제로 발생한 오류 글자는 한자만 349종이 있었으나, 이 체커와 대조해 본 결과 **126종(약 36%)**을 기계적으로 검출했습니다. 나머지 약 64%는 「올바른 일본어 한자로 변한 것」으로, 명부 방식으로는 다 잡아낼 수 없는 영역이었습니다.
36%는 언뜻 적어 보일 수 있지만, 육안으로는 발견하기 어려운(노안이라면 더욱 힘든...) 간체자(Simplified Chinese)・중국어 글자・구자체(Old Character)로의 오류 글자는 이 방식으로 거의 전부 잡아낼 수 있습니다.
"찾지 못하는 것"과 "없는 것"은 다르다—— 이것은 AI의 출력물과 함께 작업할 때 가장 중요한 마음가짐입니다.
② AI에게 「한꺼번에 고치게 하는 것」은 위험하다
기계적으로 검출된 오류 글자는 「전부 AI가 고치면 되지 않을까?」라고 생각할지도 모릅니다.
저는 이 일로 큰 코를 다쳤습니다. 간체자 → 일본어와 같이 정답이 하나로 정해지는 오류는 기계적으로 고칠 수 있지만, 숫자나 인명·지명을 「아마 이것이겠지」라는 식으로 고치게 하면 새로운 오류를 만들어냅니다.
망가진 정보를 AI는 그럴듯한 또 다른 오정보(Misinformation)로 변질시켜 버립니다.
특히 수치나 고유명사는 원래 자료를 보고 사람이 확인해야 합니다. 이 부분은 타협하지 않는 것이 좋습니다.
마지막은 인간에 의한 체크가 필수적입니다.
【마지막으로】 체커는 항상 업데이트해 나간다
체커는 계속해서 업데이트할 필요가 있기 때문에, 이번에 일부러 GitHub를 통해 공개했습니다. 주의 요망 리스트는 2026년 7월 시점의 실적을 반영한 것이며 적절한 업데이트가 필요합니다.
어디까지 가능할지는 모르겠지만, 더욱 지견을 쌓아 나갈 수 있기를 바라고 있습니다.
외부 뇌 시리즈 관련 기사
Discussion

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