User:Yes0song/ko 자동변환기

English: User:Yes0song/Automatic conversion in Korean language
日本語: User:Yes0song/ko自動変換モジュール

주의: 이것은 저의 현재 입장과 다릅니다. 이 문서는 참고용으로 남겨둔 것입니다.

이 페이지는 ko-kr(한국어 대한민국 표준어 한글 전용), ko-hanja(한국어 대한민국 표준어 한자 혼용), ko-kp(한국어 북한 문화어 한글 전용) 間 자동 변환(automatic conversion)에 관하여 제가 생각해낸 방안입니다. Automatic conversion between simplified and traditional Chinese, Automatic conversion in Serbian language을 참고했습니다.

이 문서를 작성하게 된 동기는, Requests for new languages#Wikipedia in Hanja에서 ko-hanja Wikipedia를 ko와 별도로 만드는 것에 관해 부정적 의견을 읽었기 때문입니다. 한자→한글 자동 변환기를 만들어 ko에 탑재시킨다면 굳이 ko-hanja를 따로 만들지 않아도 될 것이라는 의견이었습니다.

그래서 저는 이 문서에서, ko 안에서 ko-kr과 ko-hanja 간에 automatic conversion하는 방안을 생각해 보았습니다(또, 장기적으로는 더 나아가 ko-kp도 포함한 automatic conversion을 하는 방법에 관해서도 생각해 보았습니다).

의견이나 질문은 ko:사용자토론:Yes0song에서 해주십시오.

이하 경어체(敬語體)는 생략합니다.

한국어 위키백과의 발전 방향

한자 혼용판 추가
북한 문화어판 추가(ko-kr↔ko-hanja↔ko-kp 간 automatic conversion)
연변 조선어(ko-cn) 등 그 밖의 해외 한국어 방언 추가

1은 기술적으로 어렵지 않게 도입할 수 있다(자세한 것은 #ko-kr과 ko-hanja의 자동 변환 참고). 2번 이후는 당장은 어렵다. 훗날 한국어 위키백과에 사용자가 늘고, 북한 회원 수도 많이 늘어난다면 그 이후에 시도해 볼 만하다.

ko-kr과 ko-hanja의 자동 변환

기본 변환 기능

한자→한글 자동 변환도 어려우나, 한글→한자 자동 변환은 거의 불가능에 가깝다. 현재로서는 ko-kr→ko-hanja 기능은 포기해야 할 것이다. 문서가 한자 혼용문으로 작성돼 있으면 ko-kr에서는 그것을 한글로 바꾸어주는 기능을 MediaWiki에서 제공하는 식이 되어야 할 것이다.

현재 MediaWiki는 유니코드 정규화 알고리즘의 영향으로 CJK Compatibility Ideographs 영역에 있는 한자는 Unified CJK Ideographs로 변환, 매핑시키고 있다.

오랫동안 한국어 문자 코드 체계에서는 한자의 발음이 여러 개일 경우, 같은 한자라도 따로 코드를 할당하는 방식을 써왔다(반면에 중국어와 일본어 코드와 한국어 코드의 확장 한자는 1자당 1코드만 할당했음). 이것이 유니코드에 흡수되면서 대표적인 음을 가진 문자만 Unified CJK Ideographs에 포함되고 나머지는 CJK Compatibility Ideographs 영역에 할당이 되게 되었다.

MediaWiki는 CJK Compatibilty Ideographs 영역으로 입력되면 자동으로 Unified CJK Ideographs의 문자로 변환해버린다(유니코드 정규화 알고리즘 사용). 그러나 이것은 한자→한글 자동 변환을 어렵게 하는 요인이 되고 만다. CJK Compatibility Ideographs 영역의 한국어 한자들은 한자의 발음까지 고려된 것이기 때문에 한자에서 한글로 자동 변환할 때 편리하게 이용될 수 있다.

따라서 ko-kr~ko-hanja 자동 변환기를 사용하기 위해 한자의 유니코드 정규화 알고리즘을 off 시키도록 MediaWiki를 수정하는 것이 좋을 것이다^[1]^[2]. 그러면 같은 한자에 발음이 여러 개가 있어도 한글로 바꾸는 데에 문제가 없을 것이다.

快樂 → 쾌락 (樂: 樂)
樂園 → 낙원 (樂: 樂)
音樂 → 음악 (樂: 樂)
樂山 → 요산 (樂: 樂)

CJK Compatibility Ideographs 영역에 할당되지 않고 Unified CJK Ideographs에만 매핑이 되어 있는 글자가 多音字인 경우는 다소 복잡해진다. 예컨대 '輛'(량)의 경우 두음법칙에 따라 '양'으로도 읽힐 수 있는데, '양'으로 읽힐 경우에 쓰는 글자가 樂처럼 따로 배당되어 있지 않다. 이 경우는 두음법칙 처리 알고리즘이 한자→한글 변환기에 내장이 되어 있어야 할 것이다. 또 그 밖에 두음법칙을 제외한 多音字에 대해서도 따로 단어장을 마련하여 이 글자가 어떤 음으로 쓰였는지 MediaWiki 변환기가 자동 판단할 수 있게 프로그래밍해야 할 것이다^[3].

현행 대한민국 표준어 규정에 따르면 한자어에는 사이시옷(ㅅ)을 넣지 않는 게 원칙이다. 예외적으로 貰房, 數字, 回數, 庫間, 車間, 退間, 그리고 茶盞, 茶欌, 茶酒煎子, 邪되-·邪ㅅ되-(邪돼-·邪ㅅ돼-) 등은 사이시옷을 넣는 한자어들인데, 변환기에서 이 단어들을 예외 처리하여 각각 셋방, 숫자, 횟수, 곳간, 찻간, 툇간, 찻잔, 찻장, 찻주전자, 삿되-(삿돼-)로 변환하게 해야 할 것이다.

특수한 변환

ko-kr에서는 '한글(漢字', ko-hanja에서는 '漢字'로 나타나게 하는 경우 (ko-kr에서는 한자를 병기, ko-hanja에서는 한자만 표시하는 경우)
ko-kr에서는 '한글(漢字', ko-hanja에서는 '漢字(한글'로 나타나게 하는 경우 (ko-kr, ko-hanja 모두 한자와 한글을 병기하되 문자 표기 순서만 달라지게 하는 경우)
ko-kr에서는 '한글(漢字', ko-hanja에서는 '漢字(한글'로 나타나게 하는 경우 (대개 문서의 처음 부분에서 사용됨)

위와 같이 특수한 경우를 위한 위키 문법 tag나 template이 새로 도입되어야 할 것이다.

문서 제목 처리

한자 혼용 제목을 문서의 기본 제목으로 고치고, 한글 전용 제목은 한자 혼용 제목으로 넘겨주기 처리한다.

한글 전용판 보기 모드에서는 한자 혼용된 제목이 한글 전용으로 변환되어 웹브라우저에 표시되게 한다.

문서 편집

문서를 편집할 때 한자 혼용이 되어 있는 문서는 한자를 잘 모르는 편집자에게는 불편할 수 있다.

그래서 필자는 편집 화면에서 한자가 자동으로 한글로 변환되어 나타나는 기능을 새롭게 제안한다.

위 화면은 한자 혼용으로 작성된 문서의 Wikitext이다. 만약 한자를 잘 모르는 사용자 입장에서는 편집할 때 애를 먹을 수 있다.

위 화면은 Wikitext 내의 한자를 모두 한글로 자동 변환해서 보여주는 모습이다. 원래 한자였던 부분은 파란색으로 처리, 구분을 지었다. 그러면 한자를 모르는 사용자도 편집을 쉽게 할 수 있을 것이다(참고: 이 상태에서 편집을 하면 파란색 부분은 다시 원래의 한자로 저장되도록 한다). 앞으로 미디어위키의 편집 화면에서 이런 식의 한자→한글 변환 기능을 제공한다면 기존 한글 전용 사용자의 반발도 없애면서 자연스럽게 한자 혼용 문서도 취급할 수 있게 될 것이다.

ko-kp까지 도입하려면

ko-kr과 ko-kp의 차이는 writing system에 있는 게 아니라 vocabulary에 있다. 따라서 당분간은 변환기 제작이 쉽지 않을 것 같다.

향후에 ko-kp를 지원하는 변환기를 만들려면 1. 일일이 ko-kr 대 ko-kp 단어 대응 DB를 만들어야 할 것이고 2. 되어-되여 등의 표기법상의 차이를 교정하는 시스템을 구축해야 할 것이며 3. 변환될 때 조사(助詞)가 자동 변경(예: 이→가)되게 해야 할 것이다. 중문 위키백과에서 사용 중인 converter에서 비슷한 기능을 가지고 있는 걸로 아는데, 이것을 한국어판 위키백과에서 도입할 수 있을지 모르겠다. 남북한은 언어 이질화가 꽤 많이 진척되었기 때문에 어휘 대응 DB를 구성하는 데에 많은 시간과 용량이 필요하게 될지 모른다.

응용에 관한 의견

이 글에서 제시한 방식으로 한자→한글 변환기를 만들 수 있다면, 더 나아가 쯔놈→베트남어 로마자 자동 변환기도 만들 수 있을 것이다. 현재 Wikimedia Incubator에서는 기존의 vi(베트남어, 로마자 표기)와 달리 쯔놈으로 작성된 vi-nom이 테스트 중에 있다. 그러나 자동 변환기가 도입된다면 굳이 vi-nom WP를 따로 만들 필요 없이, vi에서 쯔놈을 처리하면 될 것이다. 실제적으로는 어려울 듯... 일반 문서는 관계 없을 수 있으나 대문과 같이 디자인이 요구되는 곳에서 문제 발생 여지 충분히 있음(로마자와 쯔놈의 글자 폭의 차이 등으로 인하여).

ja의 경우, zh의 자동 변환기를 응용하면 현대 가나 표기법(現代仮名遣い)+약자(新字体) ↔ 역사적 가나 표기법(歷史的假名遣ひ)+정자(舊字體) 간 자동 변환기를 개발해 볼 수도 있을 것이다.

en의 경우 en-gb(영국식 영어)와 en-us(미국식 영어) 간 자동 변환을 도입해볼 수도 있을 것이다.

각주

↑ 마침 한국어판에서 옛한글도 유니코드 정규화 알고리즘 때문에 문제를 일으킨 바 있다(w:ko:틀:첫가끝 참고). 한자 뿐만 아니라 한글에 대해서도 유니코드 정규화 알고리즘을 off시키도록 하면 좋을 것 같다.
↑ 어떤 분이 "KS 코드에서 같은 한자를 음에 따라 여러개의 코드로 할당한 것은 심각한 설계 결함으로 인식된다"며 유니코드 정규화 알고리즘을 off시키는 것을 반대하셨다. 그러나 필자는 미디어위키가 유니코드 정규화 알고리즘을 강제하는 것이 한국의 컴퓨팅 실정에 맞지 않다고 생각한다. 아직도 한국의 많은 문서들이 음에 따라 여러 개의 코드를 할당한 KS 코드 체계에 맞춰서 편집되고 있는 상황이다. 또 아래아한글을 비롯한 많은 소프트웨어가 한글 변환을 여기에 의존하고 있다. 그러므로 필자는 한자에 관한 한 유니코드 정규화 알고리즘을 off시키는 것을 강력히 지지한다.
↑ 이것은 초창기에는 도입하기가 다소 어렵기 때문에 중장기적으로 기능을 추가해도 상관 없을 것이다. 왜냐하면 CJK Compatibility Ideographs에 할당된 글자가 있는 한자들은 사용빈도가 높아서, 두음법칙 처리·多音字 처리 알고리즘이 따로 없어도 정상적으로 한글 전환이 가능하기 때문이다.

[1] 마침 한국어판에서 옛한글도 유니코드 정규화 알고리즘 때문에 문제를 일으킨 바 있다(w:ko:틀:첫가끝 참고). 한자 뿐만 아니라 한글에 대해서도 유니코드 정규화 알고리즘을 off시키도록 하면 좋을 것 같다.

[2] 어떤 분이 "KS 코드에서 같은 한자를 음에 따라 여러개의 코드로 할당한 것은 심각한 설계 결함으로 인식된다"며 유니코드 정규화 알고리즘을 off시키는 것을 반대하셨다. 그러나 필자는 미디어위키가 유니코드 정규화 알고리즘을 강제하는 것이 한국의 컴퓨팅 실정에 맞지 않다고 생각한다. 아직도 한국의 많은 문서들이 음에 따라 여러 개의 코드를 할당한 KS 코드 체계에 맞춰서 편집되고 있는 상황이다. 또 아래아한글을 비롯한 많은 소프트웨어가 한글 변환을 여기에 의존하고 있다. 그러므로 필자는 한자에 관한 한 유니코드 정규화 알고리즘을 off시키는 것을 강력히 지지한다.

[3] 이것은 초창기에는 도입하기가 다소 어렵기 때문에 중장기적으로 기능을 추가해도 상관 없을 것이다. 왜냐하면 CJK Compatibility Ideographs에 할당된 글자가 있는 한자들은 사용빈도가 높아서, 두음법칙 처리·多音字 처리 알고리즘이 따로 없어도 정상적으로 한글 전환이 가능하기 때문이다.

[1]

[2]

[3]