김 용묵의 절대공간 - 블로그

본인은 우리나라 근현대사와 한글 기계화에 모두 관심이 지대한 사람으로서,
6· 25 휴전(정전?) 협정 문서라는 엄청난 역사적인 문서가 '공 병우 세벌식 타자기'로 작성되었다는 사실에 입이 떡 벌어지며 그야말로 엄청난 전율과 감격을 느낀다.

이것은 한글이 역사상 거의 최초로 기계화가 된 결과물이다. 이 사진을 내 블로그에다가도 소개해 놓을 생각을 왜 지금까지 안 하고 있었나 모르겠다.
후대에 등장한 병신 같은 받침 키 두벌식 타자기가 아니라, 지금의 컴퓨터와 거의 동일한 방식으로 입력 가능한 타자기가 그것도 6· 25 전쟁도 터지기 전의 그 혼란스러운 시기에 핵심 아이디어가 완성되고 제품이 나왔다는 건 참으로 경이로운 일이 아닐 수 없다. 이게 다 넘사벽급의 천재 선각자 공 병우 박사 덕분이다.

저 타자기 자형은 훈민정음 해례본의 인쇄 글씨체만큼이나, 또 8*4*4 도깨비 조합형 비트맵 글꼴만큼이나 한글의 역사에서 빠질 수 없는 중요한 획을 그은 자형이다. 다시 말하지만 저건 197, 80년대도 아니고 1953년에 작성된 문서이다.

비슷한 시기이던 전쟁 중에 살포된 삐라들을 살펴보면 본인은 진작부터 유의미한 차이를 발견할 수 있었다.
삐라 중에는 단순히 적군 디스 흑색선전이나 프로파간다를 담고 있는 찌라시 말고, 뭔가 유엔군 사령관의 싸인이 있고 언어도 한중영 3개로 기재된 '안전 보장 증명서' 같은 것도 있었다. "이 증서를 들고 귀순하면 귀관들은 영예로운 전쟁 포로로서 안전을 절대적으로 보장받을 것이다" 이런 내용이 담겨 있었다. 아래 삐라는 그 중 한 예이다.

그런데... 이 증서를 보면, 한국어와 중국어는 날림 손글씨 붓글씨이지만 영어만은 꼬부랑 필기체가 아니라 또박또박 타자기 글씨였다. 삐라 하나를 봐도 그 시절에 문자의 기계화 수준은 동서양이 격차가 벌어져 있었다는 게 느껴졌다.
전에도 얘기한 적이 있지만, 서양에서 나치를 반대하던 백장미단은 그래도 삐라를 타자기를 쳐서 만들었지만, 반도에서 항일 전단지를 만들던 독립 운동가들은 여전히 붓글씨를 쓰지 않았던가?

그랬는데 동북아의 어느 좁아 터진 듣보잡 전쟁 폐허 국가에서.. 영어나 알파벳을 공식적으로 쓰지도 않는 주제에 자국 문자를 빠르게 찍어 내는 기계식 타자기가 짠 나타났으니 이건 깜짝 놀라 까무러칠 노릇이 아닐 수 없었다.
군대는 타자기의 편리함을 인지하고서 이미 1950년대부터 "유능한 장교라면 영어, 운전, 타자에 능숙해야 한다" 같은 지침이 나돌았다고 한다. 그러나 사회 전반에는 문자의 기계화와 속도 향상, 시간 절약의 필요성 자체를 인지하지 못하던 미개한 분위기가 오랫동안 유지되었다.

모바일은 아무래도 두벌이니 세벌이니 하는 이념과는 거리가 멀며, 애초에 크기도 너무 작다 보니 타자기의 직계 후손이라 할 수 있는 컴퓨터 글자판만치 빠르게 글자를 입력하기는 어렵다. 하지만 언제 어디서나 다룰 수 있다는 점, 그리고 모바일에서는 대개 채팅이나 자기 자아 표현 같은 가벼운 글만 주로 입력한다는 점 때문에 컴퓨터 글자판과는 용도가 양분되어 있다. 헬리콥터가 수직 이착륙과 공중 체류가 가능하다는 점 때문에 고정익기와는 별도의 영역이 있는 것과 비슷한 양상이다.

팥알 님의 블로그에는 이미 진작부터 한글 타자기를 세대별로 전문적으로 연구해 놓은 자료가 한가득이므로 관심 있는 분은 참조하시기 바란다. 저 자료에 비하면 내 블로그의 이 글은 한참 늦은 뒷북에 지나지 않는다.
그럼 휴전 협정 자체에 대한 사항만 몇 가지 언급하며 글을 맺겠다.

• 1953년 7월 27일이 6· 25 전쟁이 끝나고 한반도의 군사분계선 일대에서 총성이 완전히 멎은 날인데, 정확하게는 저 문서에 나와 있듯이 아침 10시경에 공식 문서가 작성되어 그로부터 12시간 뒤, 일과가 다 끝난 밤 10시부터 효력이 발휘되기 시작한 것으로 보인다.
• 휴전 협정이 벌어지고 저 문서가 작성된 장소는 오늘날의 그 판문점이 아니다. 옛날 오리지널 판문점은 지금 판문점보다 서쪽으로 1km쯤 더 떨어진 곳에 있었고 지금은 완전히 북한 땅이다. 그 건물 자체는 현재까지도 남아 있다.
• 저 문서에 서명을 한 사람은 북한, 중국, 미국 대표밖에 없다. 그 당시 남한 측 대표는 알다시피 강경한 북진멸공덕후였던 관계로 휴전 따위에 결코 동의하지 않았기 때문이다.

이 와중에 이 승만 대통령이 무슨 전쟁광 싸이코패스여서 휴전을 반대한 거라고 생각하는 바보 멍청이는 없을 것이다. 그는 “아.. 지금 이렇게 어정쩡하게 휴전을 해 버려서는 안 되는데.. 지금 악을 완전히 뿌리뽑지 않고 미뤘다가는 우린 북괴 빨갱이들의 도발 때문에 앞으로 계속 고생하게 될 것이고 더 큰 희생을 대가로 치르게 될 텐데.. 그래도 우리나라가 힘이 없어서 휴전이 되돌릴 수 없는 대세가 되어 버렸다면 차라리 내 예상이 틀리기를 바랄 뿐입니다.” 이런 차원에서 담화를 발표한 것이었다. (그리고 그 예상은 불행히도 정확하게 적중함)

그는 북괴는 악의 무리이며, 북괴 치하에 있는 동포들은 오늘로 치면 ISIL 같은 곳에 납치· 억류 당해 있는 불쌍한 구출 대상이고 자유와 해방을 선사해야 할 대상이라고 지극히 건전하고 바른 인식을 하고 있었다. 테이큰의 브라이언, 아저씨의 차 태식처럼 말이다. 지금 같이 악의 무리들과 무슨 교류와 협력, 불의한 평화 따위 구걸하는 태도는 전혀 찾을 수 없었다.

Posted by 사무엘

1. 나랏말씀

이런 프로그램이 과거에 개발되어 나왔다는 것을 머리로는 알고 있었지만, 인터넷에 굴러다니는 걸 구해서 도스박스에서 개인적으로 직접 돌려 본 건 굉장히 최근의 일이었다.
얘는 개발 목표와 이념이 완전히 일치하는 건 아니지만, 어찌 보면 날개셋 편집기의 먼 조상뻘 되는 프로그램이라 해도 과언이 아니다.

그리고 얘는 시대를 굉장히 앞서 갔던 프로그램이다. 1993~94년 사이에 개발됐는데 무려 유니코드 1.1 방식 옛한글을 세벌식 글자판과 글꼴로 입· 출력하는 텍스트 에디터이기 때문이다. 비록 에디터로서의 기능은 매우 빈약하고(찾기 기능도 없다!) 글자 모양도 심히 열악하지만 그래도 모아쓰기 출력과 글자 단위 cursor 이동 같은 최소한의 처리는 옳게 지원된다.

예문으로 훈민정음 서문이 포함돼 있다. 방점도 자형 자체는 있지만 오늘날 OpenType 규격처럼 글자의 뒤에다가 쳐 넣으면 글자의 왼쪽에다 알아서 찍어 주지는 않는다.

그 옛날에 국내에서는 겨우 2바이트 조합형이니 완성형이니 하면서 논쟁이 진행 중이었을 뿐, 유니코드를 아는 사람은 일부 극소수 계층 말고는 없었다. 대다수 사람들에게 유니코드는 최소한 2.0이 제정되고 나서 Windows 98 이후의 시간대는 돼서야 갑자기 툭 튀어나온 물건이다.

하물며 지금 같은 인터넷도 없고 "유니코드가 뭐야? 먹는 거야? 주변에 지원하는 프로그램도 아무것도 없구만?" 이러던 초창기였으니.. 이 프로그램은 서식이나 레이아웃 기능이 없는 텍스트 에디터임에도 불구하고 저장한 파일을 읽을 수 있는 프로그램이 사실상 자기 자신밖에 없었다.

이건 평범하게 터보 C 공부한 어느 똑똑한 대학생이 뚝딱 만들어서 PC 통신에다 올릴 만한 물건은 아니고, 사실은 부산 대학교 김 경석 교수 연구실에서 개발해서 배포한 프로그램이다. 지도교수는 그 당시 유니코드 위원회의 우리나라 대표였고, 동료 학자들과 함께(아마 국어학자들과도..) 문헌을 뒤져서 옛한글 자모들을 선별했으며 <컴퓨터 속의 한글 이야기>라는 책을 쓰기도 했다. 이 프로그램은 그 책의 부록 디스켓에 포함돼 있다.

물론, 프로그램의 실제 개발은 제자인 대학원생이 했다. 프로그램 개발자들은 다들 부족한 시간과 여건 속에서 코딩을 하는 편인데, 이 프로그램은 의외로 화면 비주얼은 신경을 썼는지 VGA 기본 팔레트가 아니라 연보라색 계열의 자체 색상을 쓰고 있다.

완성된 글자들의 모양은 볼품없지만, 이미 찍힌 낱자의 모양이 입력 도중에 다른 성분의 낱자에 의해 바뀌지 않기 때문에 뭔가 타자기를 쓰는 것 같다. 세벌식 글자판에다 세벌식 글꼴의 묘미를 제대로 경험할 수 있다. 더구나 이 프로그램에서 최초로 채택한 '세벌식 옛한글' 글쇠배열은 오늘날까지 아래아한글이나 날개셋이 그대로 계승하고 있기도 하다.

유니코드 1.1 옛한글 자모 집합은 그 전 1992년에 발표된 아래아한글 2.0이 사용하는 한컴 2바이트 코드에도 반영된 바 있다. 하지만 아래아한글은 아직 2바이트 완조형에 묶여 있었기 때문에 옛한글의 표현 능력이 온전하지 못했다.

굉장히 의외의 사실인데, 이 프로그램은 텍스트를 빅 엔디언 방식으로 저장한다. 다시 말해 UTF-16BE라는 것이다. LE가 아니라. (물론 저 당시에는 UTF라는 계층은 존재하지 않았기 때문에 UCS2만 있음)
저기서 입력하고 저장한 텍스트는 MS Word처럼 UTF-16BE를 지원하는 소수의 프로그램에서 인코딩을 수동으로 지정해 줘서 연 뒤, 날개셋 편집기에서 한글 형태 정규화를 해 줘야 오늘날 통용 가능한 텍스트 형태로 바뀐다. 저 프로그램이 개발되던 시절에는 지금 같은 U+AC00으로 시작하는 현대 한글 글자마디 11172자가 아직 없었다. byte order mark 같은 것도 없었다.

한편, 나랏말씀은 옛날에 만들어진 프로그램이지만 문서 저장 확인 질문의 Yes/No가 "예/아니오"가 아니라 "예/아니요"인 게 인상적이었다. 그 시절에 본인은 '아니요'를 그 어떤 프로그램의 UI에서도 보지 못했다. 표준어가 나중에 개정되기라고 했나 싶었는데, 그건 아니고 '아니오'가 오랫동안 컴퓨터 프로그램들 사이에서 잘못 내려온 관행이라고 한다.
아래아한글은 2002부터, Windows은 Vista부터 '아니요'로 바뀌었다. 단, 요즘 프로그램들은 대답 자체에 '저장함/저장 안 함'처럼 동작을 일일이 집어넣는 게 대세가 되어 가다 보니 간단한 "예/아니요"를 볼 일이 예전보다 드물어져 있다.

나랏말씀 같은 프로그램이 있다는 걸 내가 더 일찍 알았으면 날개셋 한글 입력기도 한컴 2바이트 코드 같은 걸 거칠 필요 없이, 3.x보다 더 이른 1이나 2.x 버전부터 유니코드 옛한글 기반으로 개발됐을지 모르겠다.
내 프로그램이 1990년대 초· 중반에 개발돼 나왔으면 도스를 겨냥해서 자체한글 텍스트 에디터(편집기) 내지 도스용 한글 바이오스(외부 모듈), 혹은 간단한 램 상주 키보드 훅킹 유틸(입력 패드) 형태로 나왔지 싶다. 흥미로운 상상이 아닐 수 없다. 아예 한글 Windows용 3rd-party IME나 영문 Windows를 통째로 한글화하는 시스템은 만들기 너무 어려웠을 것 같고.

비록 내 프로그램은 기본적인 한글 입출력 인프라는 운영체제 차원에서 다 갖춰지고 보장된 뒤에야 개발되어 나왔지만, 그래도 기성 IME들이 지원하지 않는 기능들이 매우 많으며 구현체 차원에서도 Windows IME의 온갖 지저분한 꼼수 동작들을 이 정도로 보정하는 3rd-party IME라는 존재 역할을 수행하고 있다.

2. 신의손

본인은 한글 IME/텍스트 에디터뿐만 아니라 고유한 타자연습 프로그램도 개발하고 지금까지 유지보수 중이다.
타자연습을 처음 개발하던 시절에는 당연히 그 당시 국내에 이미 나와 있던 다른 타자연습 프로그램들을 먼저 쭉 살펴보면서 벤치마킹을 했다.

그런데 그 중 압도적으로 높은 완성도로 제일 잘 만들어진 프로그램을 꼽자면.. 단연 '신의손'이었다. 지금까지도 이 생각은 변함없다.
20년 전 하이텔 게임 제작 동호회 공모전에서 '삭제되었수다'가 혼자 튀면서 압도적인 1등을 했듯이, 타자연습 프로그램 중에서는 신의손이 지존이었다고 개인적으로 생각한다.
상업용 내지 셰어웨어로 만들어도 됐을 퀄리티였다.

디자이너가 따로 없이 1인 개발자의 해골만으로 VGA 16색에서 어지간한 게임에 준하는 저 정도의 미려한 그래픽과 UI를 만든 거라면 정말 보통 실력이 아니다.
게임도 스토리나 설정 같은 게 센스가 철철 넘지고.. (신 중의 신 고무신 ㄲㄲㄲ)
내 경험상 16컬러에서 팔레트를 자체적으로 조작해서 자기만의 독자적인 색깔톤을 만들 정도의 프로그램이라면 비주얼에 신경을 꽤 쓴 프로그램이다. 예전의 도스용 Packard Bell desktop 셸처럼 말이다.

(보통은 저런 파란 톤이지만 최고 어려운 마지막 난이도에서는 화면이 전반적으로 시뻘건 톤으로 바뀐다. 우와~!)
도스용이지만 그래도 나온 때가 1995년이다 보니, 보다시피 Windows에서 그 퍼런 키보드 배경 그림(95에서만 존재하던!)과 각종 아이콘과 굴림체 글자를 따서 도스용 프로그램에다 접목한 것도 꽤 독특한 분위기를 만들어 냈다.
식상한 윗줄 따라 치기 말고 좌우/상하 대조 같은 연습 방식을 도입한 것도 얘가 원조였지 싶다.

손가락 모양의 포인터로 각종 버튼과 UI 요소들을 선택하는 GUI 비주얼을 자랑하면서 정작 마우스를 지원하지 않은 건 조금 의외였다. 허나, 키보드 뚜드리는 연습만 하라고 만들어진 프로그램이 굳이 마우스까지 지원할 필요는 없긴 하지..

신의손의 개발자는 백 승찬 씨로 알려져 있다. ('신자'이신 분은 옹기장이 백 승남 씨와 혼동하지 말 것.)
이분은 정말 진지하게 게임 개발자로 가도 되지 않을까 생각했는데..
근황을 검색해 보니.. 아아~ P2P 유틸인 프루나도 만들었으며 2010년대부터는 이미 모바일로 전향하여 어썸노트라는 앱을 개발해서 여전히 1인 기업 하고 계신다.

신의손은 그냥 대학교 재학 시절에 만든 것인데, 그 프로그램을 상업용으로 판매하려고 유통처를 알아보고 고생도 했다고 한다. (그러나 현실적인 한계에 부딪혀서 실제로 하지는 못했음)
내가 겨우 날개셋 2.x 갖고 깨작거리던 나이 때 벌써 저런 프로그램을 만들 정도였으니 지금은 뭘 못하겠냐..;;
나는 17년 전이나 지금이나 최소한 플랫폼과 외형은 진~짜 바뀐 거 없는 투박하고 공대감성 충만한 프로그램만 죽어라고 파고 있는걸. ㄲㄲㄲㄲㄲ

세상 참 많이도 바뀌었다. 창의적인 일을 하는 모든 분들에게서 경외감을 느끼는 하루이다.

그러고 보니 옛날 프로그램들 중에는 메뉴를 열어 놓은 상태에서도 단축키가 곧장 동작하는 것들이 있었다. 당장 떠오르는 예는 도스용 아래아한글, PowerBasic IDE처럼.
Windows의 기본 UI는 구조적으로 이게 전혀 지원되지 않고 그 대신 메뉴 자체의 액셀러레이터만이 동작하게 돼 있다.
어디서든이 단축키가 동작하는 게 편하긴 한데 그래도 지금은 바뀐 프로그램에 사용자가 적응해야 할 때이긴 하다.

Posted by 사무엘

<날개셋> 한글 입력기 8.4의 다음 버전은 8.5이다. 6월 말쯤에 나올 예정이다. 아울러, 타자연습도 3.5가 나올 예정이다.

8.5의 변화 사항들은 대부분 GUI 등 사소한 것들이다. 그러나 예전보다 센스 있게 동작하도록 기능이 추가되거나 변경된 건 있어도, 지난 8.4에서 뭔가 크게 잘못 동작하던 것이 바로잡혔다거나 버그가 고쳐진 것은 없다. 그만큼 8.4는 완성도 높게 잘 만들어졌으며 <날개셋> 한글 입력기도 '더 고칠 게 없는' 안정화 고정 단계에 근접한 듯하다.

8.5의 존재 의미라 할 수 있고 한글 입력 엔진 차원에서 바뀐 유일한 과업은 바로 '이벤트 핸들러'의 구현이다. 사실, 8.4에서 들어가려 했으나 이론 검증과 확신이 서지 않아서 차마 마무리를 못 하고 한 버전 더 거쳐 가게 됐다.
입력 스키마(현재 사용 중인 놈 한정)와 보조 입력 도구는 한글 입력 엔진으로부터 다음과 같은 상황에서 7종류의 이벤트를 받아서 이때 자신만의 처리를 할 수 있다. 주로 사용자(소문자 a~z) 변수를 초기화하는 수식이 실행된다.

(1) 시스템: <날개셋> 한글 입력기를 사용하는 프로그램 전체가 활성/비활성화됐을 때. 그리고 외부 모듈의 경우, 해당 UI 스레드 차원에서 IME가 날개셋으로 바뀌었거나 해제됐을 때. on/off 경우에 모두 호출된다. 단, 입력 패드는 언제나 시스템 차원에서 global하게 구동 중이므로 이 이벤트를 따로 보내지 않는다.

(2) 포커스: 한 프로그램 안에서 <날개셋> 한글 입력기를 사용하는 창의 포커스가 여기서 딴 데로 바뀌었을 때. 그리고 외부 모듈의 경우 창 포커스는 여전하더라도 내부적으로 사용하는 컨텍스트가 바뀌었을 때(HIMC). 역시 on/off 때 모두 호출된다.
포커스/컨텍스트가 바뀌었으며 잃었다가 얻었다는 사실 자체만 알 수 있지, 구체적으로 그 값을 구분해서 인식할 수 있지는 않다.

(3) 입력 항목(글쇠배열) 전환: 원래 있다가 교체되는 놈(off)과 새로 지정되는 놈(on)이 모두 이벤트를 받는다. 또한, 제어판을 구동하여 입력 설정이 바뀐 뒤에도 디폴트로 지정된 입력 항목은 처음에 on 이벤트를 받는 게 보장된다.
보조 입력 도구에는 요런 통지를 받는 게 이미 있다. 그래서 '화면 키보드' 도구가 지금 사용 중인 글쇠배열을 실시간으로 업데이트 해서 표시해 준다.

(4) 외부에 의한 조합 강제 종료: 한글 입력 중에 마우스 클릭, 포커스 변경, 우리 입력 스키마가 처리하지 않는 글쇠 등의 이유로 조합이 종료되었을 때 이벤트를 받는다. on/off 개념은 없고 그냥 단일.

(5) 문자 연속 입력 단절: 조합 강제 종료와 비슷하지만 이와 완전히 동일하지는 않은 개념이다. 굳이 조합을 만들지 않더라도 문자를 계속 입력하거나 bksp 하고 있었는데 갑자기 비문자 글쇠나 마우스 클릭, 포커스 변경 등이 감지되면 이 이벤트가 한번 날아온다.

지금도 "bksp 연타 시 한번 정해진 동작을 계속 적용" 옵션이 이 이벤트 비슷한 개념을 사용하고 있다. 그런데 이를 개념적으로 더 확장하여, 굳이 한글 조합 중일 때가 아니라 연속 입력 중일 때에 '낱자 단위로', 연속 입력이 끊어졌을 때는 '글자 단위로' 한글을 지우도록 할 수도 있게 했다.

(6) 변수값 변화: 입력 스키마의 글쇠배열 내지 문자 생성기의 오토마타에서 수식 계산으로 인해 변수값이 바뀐 것을 보조 입력 도구가 알 수 있게 한다.
그래서 보조 입력 도구를 이용해 변수값 디버거를 만들 수 있게 된다. 그리고 '화면 키보드' 도구가 아예 context-sensitive하게 지금 입력되는 문자를 화면에다 업데이트 가능하게 된다. 즉, 복벌식 입력기라면 내부 변수값에 따라 두벌/세벌 모드가 됐을 때 글쇠배열 전체가 두벌식이나 세벌식 모양으로 바뀐다.

(7) 타이머: 지금은 천지인 모바일 입력기처럼 특정 상황에서 일정 시간이 경과했을 때 조합을 강제 종료시키는 기능을 구현할 때 타이머가 제한적으로 지원되고 있다. 타이머는 그 기능을 더 일반화해서 겉보기로 조합은 유지하더라도 오토마타의 내부 상태만 바꾸는 것, 임의의 글자를 입력시키는 것, 타이머를 1회가 아니라 계속 동작시키는 등 더 다양한 처리를 할 수 있게 된다.

이렇듯, 통합적인 이벤트 핸들러는 한글 입력기의 아키텍처에서 매우 중요한 기능이다. 오랫동안 필요성만 인지하고 있었을 뿐 작업을 할 엄두를 못 내고 있던 곳에 대대적인 수정이 가해졌다. 이 기능 하나에다가 다른 UI 쪽의 변화 사항들을 합치면 +0.1 버전업은 충분한 가치와 의미를 지닌다.
이벤트 핸들러 수식을 지정하는 UI는 글쇠배열의 추가 옵션을 지정하는 대화상자에 들어갈 예정이다. 어차피 글쇠배열 내부에서 쓰이는 변수들을 초기화하는 수식이 들어갈 테니 말이다.

이것 말고 가볍게 읽을 만한 새 버전 변화 사항들은 다음과 같다. 8.5가 어서 완성됐으면 좋겠다.

1. 한글 낱자 종류 변환에 filler를 안 집어넣는 옵션

텍스트 필터 중에 '한글 낱자 종류 바꾸기'라는 게 있는데, 이건 호환용 한글 자모(U+31??)와 표준 한글 자모(U+11???) 사이를 변환하는 나름 중요한 기능이다.
표준 한글 자모에는 정규화 규칙이라는 게 적용되기 때문에 자음 하나, 모음 하나만 있을 때에도 초/중성의 빈 자리에는 채움 문자(filler)가 꼭꼭 들어간다. 하지만 채움 문자 없이 호환용 자모를 문자 그대로 표준 한글 자모로 일대일 치환만 해 주는 옵션이 이번 버전에서 추가되었다.

이 옵션을 사용하면 정규화 규칙에 어긋나는 문자열을 생성할 수도 있지만, 한편으로 "ㅎㆍㄴ" 같은 풀어 쓴 호환용 자모로부터 모아 쓴 옛한글을 곧바로 만들어 낼 수 있다. 채움 문자가 없으니 각 자모가 그대로 한 글자를 구성하게 됐기 때문이다.

2. 외부 모듈에서 문자표 대화상자의 동작 방식 변경

<날개셋> 편집기와 외부 모듈은 모두 문자를 입력하는 프로그램이니 키보드에 없는 특수문자를 입력하는 '문자표' 기능이 있다.
편집기야 내부의 모든 데이터 입출력이 100% 자가통제가 가능하기 때문에 문제될 게 없지만 외부 모듈은 문자표로부터 받은 문자를 응용 프로그램에서 보내는 것만 가능하고 그 프로그램이 실제로 문자를 접수하는지를 완벽하게 알 수는 없다.

그래서 문자표라는 대화상자가 키보드 포커스를 얻어 있는 상태에서 본문 창에다가 계속해서 문자를 보내는 게 기술적으로 가능한 프로그램도 있고 가능하지 않은 프로그램도 있었다. 즉, 외부 모듈에서 문자표 대화상자는 사실상 반쪽짜리 기능이었던 것이다. 텍스트 필터가 TSF A급에서만 사용 가능한 반쪽짜리 기능인 것처럼 말이다. 이런 이유로 인해, 이 버튼은 프로그램을 처음 설치했을 때는 기본적으로 도구모음줄에 나타나 있지도 않았다.

이 점을 감안하여 이번 버전에서는 외부 모듈의 문자표의 동작 방식을 바꿨다. 연속 입력 기능을 희생시켰다. 엔터를 누르면 문자표 대화상자는 곧장 닫혀 버린다.
그 대신 글자 단 하나를 입력하더라도 그 기능만은 IME, TSF A/B 등을 가리지 않고, 또 BMP와 surrogate를 가리지 않고 모든 프로그램에서 제대로 동작하게 정책을 바꿨다. 동작을 차라리 이렇게 바꿔 버릴까 오랫동안 고민했는데 결국 이제야 결정을 내렸다.

문자표를 꺼내 놓은 채로 여러 문자를 입력하고 싶으면, 이런 대화상자가 아니라 '보조 입력 도구' 중 하나인 문자표를 사용하면 된다. 얘는 반대로 문자표 내부에서 키보드 조작을 할 수는 없지만, 키보드 포커스를 차지하지 않기 때문에 창이 떠 있는 상태에서도 다른 프로그램의 UI에 영향을 주지 않는 게 가능하다.

3. 문자표에 Ctrl+클릭

요즘은 그냥 클릭에 뭔가 2% 부족한 면모가 있을 때 Ctrl+클릭을 추가하는 게 새로운 UI 트렌드인 것 같다.
후보 데이터를 추가할 때 Ctrl+클릭을 하면 입력된 문자열이 각각의 글자 단위로 따로 후보로 추가된다. 그리고 낱자 결합 규칙에서도 Ctrl+클릭을 하면 추가 후에 입력란의 값과 키보드 포커스가 그냥 클릭과는 다르게 바뀐다.
외부 모듈의 후보 목록에는 Ctrl+클릭(Ctrl+엔터 포함)뿐만 아니라 Shift+클릭도 있어서 단순히 한자 변환뿐만 아니라 한글(한자) 또는 한자(한글) 형태를 지정할 수도 있다.

이와 같은 맥락에서, 문자표에도 Ctrl+클릭 동작을 추가했다.
그냥 '추가'를 누르면 선택된 문자가 본문에 삽입되고 대화상자가 그대로 남아 있는 반면, Ctrl+클릭을 하면 이제 문자가 삽입됨과 동시에 대화상자가 닫히게 했다. 이 기능이 있으니 정말 편하다. 물론 애초부터 연속 입력이 가능한 편집기의 문자표 같은 곳에서 말이다.

4. 글자가 많이 존재하는 부수는 진하게 표시 (부수로 한자 입력 기능)

오늘날 수만 자에 달하는 한자들을 분류하는 데는 부수라는 게 쓰인다. 부수는 총 214개가 존재하는데, 한자에 식견이 있는 분이라면 다 아시겠지만 이 부수들이 골고루 쓰이는 게 아니다. 분포가 전혀 균일하지 않으며, 소수의 특정 부수에만 쏠림이 매우 심하다.

예를 들어 요일을 나타내는 한자들(火, 水, 木, 金 같은. 단 月은 제외), 人, 車, 言, 鳥처럼 만만하고 보편적인 뜻을 가진 부수에는 한자가 수백~심지어 1000개가 넘게 들어있고 새로운 글자가 또 만들어지기도 한다. 그러나 匕, 至, 臣, 牙, 首, 父, 龜, 鼠 같은 나머지 대부분의 부수들은 듣보잡이다. 그 제부수자 자체는 首, 父, 高, 非, 長처럼 아주 기초적이고 친숙한 반면, 거기서 파생된 한자는 거의 없는 경우도 있다.

이 점을 감안하여, 다음 버전에서는 "부수로 한자 입력" 도구에 한자가 매우 많이 들어있는 상위 10% 정도의 부수는 약간 진하게 표시해서 사용자의 눈에 미묘하게 더 잘 띄게 했다.
이것도 시각 피드백을 어떻게 줄지 무척 고민했다. 색깔을 달리 하는 건 제일 간단하긴 하지만, 실험 결과가 좋지 않아서 관뒀다. 이미 색깔로 변별하는 다른 요인들도 있는데(한자의 등급, 현재 선택된 부수와 획수가 같은 부수) 거기에다 색깔 변화를 더 주면 비주얼이 너무 튀고 더 혼란스러워졌다.

그 다음으로 생각한 건, 글자 크기에 변화를 주는 것이었다. 하지만 이 역시 결과가 별로 좋지 않아서 최종적으로는 '볼드' 속성이 낙찰됐다. 요렇게 해 주니 딱 봤을 때 너무 튀지 않으면서도 자주 쓰이는 메이저 부수만 빨리 찾는 데 확실히 도움이 된다. 나만 그렇게 생각하는 게 아니었으면 좋겠다만..;;

5. 타자연습: 계정 import/export, 그리고 파일 기반 custom 연습글

타자연습에는 로그인 화면에서 계정 파일을 다른 디렉터리로 내보내거나 거기서 계정 파일을 가져오는 import/export 기능을 추가했다.
단순한 파일 copy 기능에 지나지 않지만, 사용자 계정을 컴퓨터끼리 옮길 수 있게 하는 건 진작부터 필요했던 기능인데 이제야 도입됐다.
궁극적으로는 서버를 통한 동기화도 지원해야 할 텐데 그건 내 혼자 할 수 있는 일은 아니고..

그리고 거의 10년 가까이 유지되던 연습글 목록 관리 방식이 바뀌었다.
XML 파일 기반인 것은 변함없지만, 이것은 프로그램이 기본 제공하는 고정 붙박이 연습글에만 적용된다.
이전처럼 사용자가 XML 리스트를 직접 고치는 것은.. 이제는 더 권장되지 않는 지저분한 관행으로 deprecate됐다. 프로그램 UI에는 예전과 같은 '연습글 추가/삭제' 같은 버튼과 기능이 사라졌다.

그 대신, 사용자의 custom 연습글은 특정 디렉터리에다가 txt 파일들을 갖다 놓기만 하고 '새로 고침'을 누르면 거기에 있는 것들을 프로그램이 알아서 추가로 등록해 주는 형태로 바뀌었다. 하위 디렉터리가 있으면 물론 그것까지 알아서 찾기 때문에 재귀적인 트리 구조를 만들 수 있다. 디렉터리는 꾸러미, 파일은 연습글로 그대로 대응되는 거다.

custom 연습글은 크게 두 종류가 있다. (1) 이 컴퓨터를 사용하는 모든 사용자가 똑같이 공유하는 놈, 그리고 (2) 현재 사용자 계정에서만 보이는 놈.
(1)의 위치는 답정너로 고정돼 있다. "운영체제의 공용 문서\YmSoft\NgsType"이다. 여기에다가 txt 파일들을 심어 놓으면 <날개셋> 타자연습에서 어느 계정으로 로그인 하건, 아니 로그인하지 않고 익명으로 사용하더라도 연습글들을 볼 수 있다.

또한, 여기에 덧붙여 임의로 지정된 디렉터리를 하나 더 동일한 방식으로 수색하게 할 수 있다. 이 위치는 각 계정별로 달라질 수 있다.
기본 제공되는 보급 연습글은 맨 위에 표시되며 꾸러미가 예전처럼 자주색이다. 그러나 (1) 공용 custom 연습글은 꾸러미가 밝은 분홍색이며, (2) 개인용 custom 연습글은 꾸러미가 파란색이다.

"문장/글 연습" 탭에 가 있는 상태에서 '환경설정' 버튼을 누르면, 예전에는 '외형'과 '타자 연습'이라고 탭이 2개 있는 대화상자가 떴는데, 이제는 '추가 연습글'이라는 제3의 탭이 추가되었다. 여기에서 공용 연습글 디렉터리가 어디인지 정확한 경로를 확인하고 그 창을 탐색기로 열어 볼 수 있다. 그리고 개인 연습글 디렉터리는 위치도 사용자가 지정하고 탐색기로 여는 것도 가능하다. 이제 나만의 연습글을 추가하는 건 이런 식으로 하면 된다.

여담이지만, 이번 버전에서는 기본 제공되는 연습글들도 좀 현실화했다.
잉여도가 너무 높아 보이던 옛한글 연습글을 삭제하고, 성경도 잠언과 요한복음만 남겼다. 잠언은 '슬기로운 이야기' 카테고리에 있던 것을 '영적 생활'로 옮겼다.
우리말 우리글 카테고리에 있던 글들을 삭제하고 '한글 노래' 하나만 남겨서 '마음의 양식' 카테고리에다 옮겼다.
그래도 <날개셋> 타자연습은 안 창호 선생의 글과 김 성모 화백 어록, '어둠에다크에서'가 한 자리에 놓여 있는 타자 연습 프로그램이다. 제작자가 인터넷 병맛 개그를 좀 좋아하기 때문에..;;

* 그 밖에,

(1)
 <날개셋> 편집기는 상태 표시줄(status bar)에 있는 글자판(입력 항목)을 우클릭하면 글자판을 선택하는 메뉴가 나타난다. 그래서 한영 내지 Shift+Space 같은 단축글쇠를 안 누르고도 마우스로 입력 모드를 전환할 수 있다.
그 중 '빈 입력 스키마'는 아시다시피 <날개셋> 한글 입력기가 제공하는 특정 입력 모드가 아니라 그냥 운영체제가 제공하는 IME를 그대로 받아들여서 문자를 입력하는 모드이다.

빈 입력 스키마를 사용하고 있는 상태에서 이 메뉴를 통해 동일한 빈 입력 스키마를 또 선택하면 그때는 운영체제의 한영 상태를 전환하는 기능을 추가했다. 중국어나 일본어 IME를 사용하고 있다면 해당 언어의 자국 문자 모드와 영문 모드가 전환된다.

(2)
대화상자에서 리스트 박스의 아이템을 더블 클릭하면 그 아이템을 고치거나, 그걸 선택한 채로 '확인'을 바로 누르는 shortcut 동작이 수행되곤 한다. 그에 비해 라디오 버튼의 더블 클릭은 잘 알려져 있지 않지만, 이 역시 MS가 권장하는 UI 동작이다. 대표적인 예가 MS Office 프로그램에서 화면 확대 대화상자인데, 100, 200같은 퍼센트를 라디오 버튼으로 선택하고 그걸 더블 클릭하면 곧바로 대화상자가 종료된다.

<날개셋> 한글 입력기는 다음 버전부터 주요 UI에 라디오 버튼의 더블 클릭이 지원될 예정이다. 라디오 버튼의 선택이 해당 대화상자의 동작 방식이나 옵션을 거시적으로 결정하는 대화상자들이 그 대상이다. 대소문자 전환(전환 방식), 기본 입력기 빠른설정(사용할 글자판) 등등에서 아이템을 더블 클릭하는 것만으로 대화상자를 확인 종료할 수 있게 된다.

(3)
Windows의 한글 IME 지원 체계에는 좀 이상한 문제가 있다.
TSF를 응용 프로그램이 직접 지원하는 A급 환경 말고, 그냥 IME 호환 계층을 통해 지원하는 B급 환경에서는..
처음에 2글자 이상의 조합을 만들면 조합이 그냥 끊어져 버린다. 이건 이유는 모르겠지만 운영체제가 한글 IME에 대해서 거의 일부러 강요하는 동작이다. 9x/XP 시절, IME 모듈조차도 안 이랬는데 말이다.

이런 이유로 인해 TSF B급 프로그램에서는 한글 조합은 반드시 1글자짜리 호환용 한글 자모로 시작해야 하고, 2~3글자짜리로 정규화된 표준/옛한글 자모로 시작할 수 없다. 첫 타 이후에 다음 타로 인해 계속된 조합의 길이가 2글자 이상으로 가는 건 괜찮다.
이번 새 버전에서는 TSF B급 프로그램에서 2글자 이상의 조합을 만들려 해서 조합이 끊어졌다면 이를 감지해서 이 현상에 대한 간단한 안내 메시지와 도움말 링크를 표시하게 했다. 그래서 이건 설정 문제이지 프로그램의 버그가 아님을 사용자가 알 수 있게 했다.

(4)
좀 어이없는 실수이긴 한데..
드보락이라는 영문 글쇠배열을 만든 사람은 미국의 교육심리학자인 '어거스트 드보락' 박사이다. Dvorak Simplified Keyboard라는 이름으로 이 글쇠배열이 공표된 것은 1932년이고 특허를 얻은 것은 1936년이다.
하지만 지금까지 <날개셋> 한글 입력기의 빠른설정 UI와, 타자연습 도움말의 '세벌식과 드보락의 관계는?'에는 이게 '안톤 드보락이 1930년에 고안한 글쇠배열'이라고 잘못 소개되어 있었다.

이 사람의 이름은 체코의 작곡가 이름인 '안토닌 드보르작'과 매우 혼동되는 편인데, 그거 영향을 받은 것 같다.
우연히 간단한 구글링을 하다가 이 사실을 발견하고는 바로잡았다. <날개셋> 한글 입력기와 타자연습의 다음 버전에서 반영될 것이다.
이거 실수의 근원을 추적해 보니.. 어이없게도 아래아한글의 도움말이었다. 2007 버전만 해도 글자판 소개에서 드보락 설명을 보면 "쿼티 글자판의 단점을 보완하여 1930년 안톤 드보락 박사가 고안한 글자판"이라고 설명되어 있기 때문이다.

Posted by 사무엘

1. Windows 10

그 이름도 유명한 Windows 10을 본인도 드디어 입수했다. Mac OS와 Windows 모두 10을 최종 메이저 버전으로 설정했다는 게 무척 흥미롭다.

개인 컴은 물론이고 회사 컴도 평소에 활발하게 쓰던 물건은 "Windows 10 다운로드 준비가 끝났는데 설치할까요?"가 진작부터 뜬 반면,
평소에 잘 안 쓰고 "여기에나 한번 10을 깔아 볼까?"라고 정작 비워 놨던 컴은 한참을 기다려도 Windows 10 설치 말이 없었다. "준비되면 알려 주세요"를 몇 번이나 클릭했는데도 감감 무소식. 이것도 평소에 로그인 횟수나 네트워크 트래픽을 감안해서 업데이트 순서를 짠 건지는 모르겠다.

참다못해 Windows 10 설치 프로그램을 직접 다운로드 해서 실행한 뒤에야 운영체제를 7에서 10으로 바꿀 수 있었다. 다운로드와 설치는 물론 금방 끝난 건 아니지만, 그렇다고 Windows 8.1을 설치하던 시절보다 터무니없이 오래 걸리지는 않았다.

설치 직후에는 바탕 화면의 personalize가 되지 않았다. 인증이 필요하대서.. "으잉? Windows 10은 완전 무료 아니었나? 자동 업데이트를 안 하고 수동 설치를 해서 그렇나?" 어리둥절했는데 재부팅을 한번 하고 나니 인증은 저절로 패스 됐고, 까맣던 배경 그림은 10을 설치하기 전의 모습으로 되돌아왔다.

비주얼에 대한 소감은..
프로그램의 제목이 가운데가 아니라 왼쪽 정렬로 돌아왔으며, 글씨 크기도 약간 더 크다가 다시 메뉴 글씨 크기와 동일하게 돌아왔다. 또한 화면을 부분만 차지하는 시작 메뉴가 되돌아왔으며 프로그램 창 주변에 그림자 그러데이션이 생긴 것은 일면 과거의 Windows Vista/7 시절로의 회귀를 떠올리게 한다.
창의 최소/최대화와 닫기 버튼이 굉장히 커지긴 했는데 정작 _ □ X 모양은 너무 대충 그려 넣은 듯. -_-;;

명령 프롬프트가 가로폭 조절이 가능해진 것이 무척 인상적이다. 하지만 글꼴은 여전히 제대로 customize가 안 된다. 하다못해 먼 옛날 9x 시절에는 코드 페이지가 무엇이냐에 따라 Courier New나 Lucida Console이라도 볼 수 있었는데 너무 칙칙한 글꼴은 오히려 NT 계열이 9x보다도 퇴보했다.

운영체제를 업데이트 한 직후, 이전까지 사용하던 프로그램들은 10에서도 거의 그대로 곧장 사용이 가능했다. 그러나 <날개셋> 한글 입력기는 편집기만 남아 있고 외부 모듈은 운영체제의 IME 목록에서 사라졌다.
허나 이건 프로그램을 재설치만 하면 해결되니 그리 심각한 문제는 아니다. 또한 지금까지 파악한 바로는 Windows 10은 문자 입력에 관해서 딱히 기술적으로 크게 바뀐 게 보이지 않는다. 심지어는 세벌식 파워업도 10의 MS 한글 IME를 대상으로 잘 동작한다.

2. <날개셋> 한글 입력기에서 발견된 문제

다만, <날개셋> 한글 입력기가 Windows 10에 대비하여 개선해야 할 사항은 크게 두 가지가 발견됐다.

(1) 첫째, Windows 10은 Metro 앱도 데스크톱에서 뭔가 일체형으로 연계하며 동작하게 된 듯하다. Windows 10의 상징이라 해도 과언이 아닌 엣지(Edge) 브라우저도 기술적으로는 Metro 앱이다. Metro 모드에서는 클래식 데스크톱 GUI를 사용하는 기능들이 동작하지 않는다. 고로 <날개셋> 제어판이나 About 대화상자 같은 것도 못 띄운다. (그걸 시도하면 그냥 씹히거나 프로그램 전체가 그냥 튕긴다)
8 시절에는 메트로 앱들은 데스크톱의 입력 도구모음줄에 접근을 할 수 없으니 신경 쓸 필요가 없었는데, 이제는 메트로 모드에서는 이런 기능들을 건드릴 수 없도록 도구모음줄 버튼이나 메뉴를 흐리게 처리해 줘야겠다.

날개셋 말고 다른 IME들은 이 문제를 어떻게 해결했느냐 하면 한글 IME는 아예 대화상자가 출력되는 명령들을 모조리 없애 버렸다. 심지어 8에는 있던 About 명령조차도 없앴다. 일본/중국어 IME는 GUI가 나오는 기능들은 몽땅 다른 프로그램을 통해 실행되게 되어 있다.

사실, 한글 IME도 부수/획수 한자나 필기 인식 같은 보조 입력 도구는 별도의 프로그램을 통해 구동한다. 그러나 내 프로그램은 이런 것들이 다 in-process 형태로 구동된다. 그래서 Metro 모드 같은 데서는 여러 제약이 걸리는 것 같다. 금방 해결 가능한 문제는 아닌 것 같고 프로그램 구조를 앞으로 어떻게 유지할지 생각을 해 봐야겠다.
참고로, 엣지 브라우저 자체는 크롬의 마소 버전이라고 생각해도 좋을 정도로 "빠르고" 산뜻해서 느낌이 굉장히 좋았다. 그거 하나는 인정한다.

(2) 둘째, 엣지에서 페이스북에 접속해서 댓글을 써 보니, 한참 글자를 입력하다가 비한글 문자를 입력하는 순간, 예전에 입력 중이던 글자가 몽땅 사라지는 문제가 있었다. "가을에." -> "에."만 남는 식.
또한 명령 프롬프트에서도 내 프로그램으로 한글을 입력해 보면, 조합하던 글자가 덮어써진다. "가" "가을" "가을에"가 되는 게 아니라 "가" "을" "에". 신기하게도 MS IME로 한글을 좀 입력하다가 다시 날개셋으로 돌아오면 명령 프롬프트는 이 문제가 없어짐.

100% 재연 가능하고, MS IME는 안 그런데 내 프로그램만 그렇고.. 현상 자체는 완벽하게 파악이 됐지만 이건 또 MS가 무슨 농간을 부린 건지 허무한 생각이 든다. 아마 둘 다 같은 원인 때문일 거라고 추측만 하는데.. 제일 골치 아픈 부류의 문제이며 해결이 쉽지 않을 수도 있다.

3. key의 인식 방법과 관련된 customization

이건 Windows 10과는 관계가 없는 다른 얘기이다.
<날개셋> 한글 입력기는 한글을 생성하기에 앞서서 key 입력을 인식하는 방식 자체를 사용자화 가능하다. 크게 다음과 같은 시나리오가 있다.

(1) 원래는 먹던 특정 key를 먹지 않게 할 수 있다: 표준 두벌식의 경우 오로지 A~Z 26개 key만 사용하기 때문에 나머지 숫자와 기호는 따로 IME가 가로채는 게 아니라 그냥 응용 프로그램으로 넘겨서 숫자나 기호를 입력하게 한다.

(2) 원래는 먹지 않던 특정 key를 IME 입력으로 바꿀 수 있다: space의 경우, 굳이 IME가 처리할 필요가 없는 key이다. 하지만 인디자인 버그 같은 걸 해결하기 위해서 IME가 굳이 가로채어 공백을 되돌리게 할 수 있다.

(3) 특정 key를 IME 입력 대신 다른 key로 바꿀 수 있다: 내 프로그램으로 드보락 글쇠배열을 사용하는 경우, 보통은 드보락 방식대로 IME가 알파벳을 보내게 한다. 하지만 글쇠 누름 날개셋문자를 사용하면 아예 해당 알파벳 key 입력을 응용 프로그램에다가 보내게 할 수도 있다.

쉽게 말해 비한글 알파벳이나 공백 같은 문자를 IME 방식으로 보내느냐, 그렇지 않고 더 원초적인 key 메시지 형식으로 보내느냐를 제어할 수 있다는 뜻이다.
단축키 같은 것은 key 입력 메시지 형태로 온 것만 인식되지 IME 방식으로 전달된 문자로는 인식되지 않는 경우가 많기 때문이다. MS Excel의 경우, 영문을 key 입력 형태로 입력했을 때에만 함수의 목록 자동 완성이 처리되지만 IME 방식으로 입력된 것에는 반응하지 않는다.

(1)과 (2)는 6.5 버전에서 기본 입력 스키마에 해당 기능이 추가되고 구현됐다. 한편, '글쇠 누름' 날개셋문자는 비교적 최근인 7.9 버전에서 추가되었다.
현재 개발 중인 8.2 버전은 (3)이 소개하는 '글쇠 누름' 날개셋문자의 사용을 홍보하기 위해, 제어판의 글쇠배열 편집 창에서 숫자/문자를 입력하는 '일반 문자' 날개셋문자를 그에 상응하는 '글쇠 누름' 날개셋문자로 자동으로 모두 바꾸는 기능을 추가했다.

그리고 더 간단히, 사용자가 누른 key에 해당하는 글쇠 누름 날개셋문자를 자동으로 입력시키는 모드도 추가했다. 예전에는 세벌식 한글, 두벌식 한글, 이동, 영문 알파벳 같은 모드가 있었는데 그런 것처럼 새로운 모드를 넣었다는 뜻이다. 아주 자연스럽게 기능 확장이 가능하다.

또한 (2)를 더 쉽게 설정할 수 있게 하기 위해, 단축글쇠를 입력받는 대화상자에다가는 지금 누른 가상 키코드의 문자값에 해당하는 '일반 문자' 날개셋문자를 자동으로 배당하는 기능도 추가했다.
알파벳이나 숫자를 key 입력으로 보내는 것과 IME 문자열로 보내는 것의 차이에 대해서는 도움말에다가도 더 자세한 설명을 넣을 예정이다.

4. 고기 먹고 싶음 -_-

아직 어쩔 수 없는 여름이긴 하지만 그래도 날씨가 예전보다 덜 더워져서 무척 좋다.
난 어릴 때부터 왜 태양이 긍정적인 심상이고 그늘이 부정적인 심상인지를 이해를 못 했을 정도로 몸에 열이 많고 더위를 싫어했다.

이제 좀 가을이 되고 나면 날씨 탓할 일 없이 더 집중해서 코딩을 진행하고 싶은데.. 프로그램 완성의 꿈은 요원하기만 하다.
도깨비불 현상 없는 입력 방식이 심리적으로 무척 도움이 된다. 세벌식은 없어질래야 없어질 수 없고 없어져서는 안 되는 한글 입력 방식이다. 뭐 그건 그렇고..

Posted by 사무엘

외국인 중에서 한글에 대해서 정말 경이로운 체계를 가진 우수한 문자라고, 심지어 라틴 알파벳보다도 더 훌륭하다고 극찬을 늘어놓은 석학들이 있다. 개중엔 재레드 다이아몬드처럼 언어학이 아니라 단순히 다른 인문학 분야를 전공한 사람도 있지만, 언어학을 본격적으로 전공한 학자, 그것도 레알 엄청난 괴수 중에도 한글 예찬론자가 있다.

이것 자체는 기록이 다 남아 있고 출처 검증도 가능한 엄연한 팩트이므로 더 의심하지 않아도 된다. "무슨 소수 민족에게 한글 보급"과 같은 급의 루머가 아니다.
또한, 창조과학은 생물학이나 지질학, 천문학을 직접 전공하지 않은 타 분야의 공학 박사나 의사들이 민다고 까이는 반면, 한글 예찬론은 일부나마 실제 현업 언어학자들로부터 지지를 받고 있으니 성격이 좀 다르다.

시카고 대학교의 제임스 맥콜리 교수는 잘 알다시피 한글날은 전세계의 언어학계가 다함께 경축해야 하는 날이라면서 10월 9일엔 휴강을 했던 것으로 유명하다.
연세 대학교가 배출한 가히 세계적인 언어학 석학인 김 진우 교수도 학부 모교로 돌아와서 석좌교수 명목으로 잠시 강의를 하던 때엔, 2학기에 한글날이 낀 주엔 문자의 역사 강의를 했다. 내가 수업을 듣던 시절에도 종종 한글 감탄을 늘어놓았으며, 한글날이 국경일이 아닌 것은 정말 통탄할 일이라고 말씀을 하셨다. (2011년, 아직 국경일이 아니던 시절에)

물론 꼭 그렇게까지 감흥을 느끼지는 않는 학자들도 있으며, 오히려 저런 식의 생각을 문화 제국주의니, 한글 쇼비니즘이니 뭐 이상한 꼬리표를 붙여서 불쾌하게 받아들이는 사람들 역시 없지는 않다.
이런 와중에 미천한(?) 본인이 한글이 우수하네 어떻네 하는 오래 된 고리타분한 논쟁에 불을 추가로 지피고 싶지는 않다. 그러나 관찰을 통해 발견할 수 있는 분명한 팩트를 하나 지적하고자 한다.

"한글은 뭔가 천재들을 매료시키고 오덕질 거리를 제공하기에 충분한 특성은 갖추고 있는 것으로 보인다."
그렇지 않고 단순히 한글이 한국어만 잘 표기해 내는 세계의 여러 평범한 문자들 중 하나일 뿐이라면, 한국어가 모국어가 아닌 외국의 언어학 석학 중에 한글 예찬론자가 나타날 수가 없었을 것이다.
또한 공 병우 박사처럼 언어와는 거의 관계 없는 전공이던 천재 공돌이 의학자가 갑자기 하필이면 한글 덕후 타자기 덕후로 돌변할 수도 없었을 것이다.

그래서 지금 있는 한글 자모나 한글 맞춤법 체계에 만족하지 못하고 한글을 외국어의 다른 음성을 표기하는 용도로도 쓸 수 있게 확장해야 한다고 주장하는 분들이 여럿 있다. 이 역시 주장자 중에는 이공계 박사나 의사 등, 스펙이 비범하긴 하지만 언어학만을 깊게 공부하지는 않은 사람이 있는가 하면, 음성· 음운론을 통달한 저명한 언어학자도 있다. 이 현복 교수 같은 엄청난 분도 그 중 하나이니까.. 그러니 이것은 단순히 비전문가 한글 덕후의 마이너한 재야 학설 정도로 마냥 치부할 문제도 아니다.

지금의 암호 같이 배배 꼬인 IPA 부호보다 더 체계적이고 알아보기 쉬운 음성 부호 체계가 한글의 제자 원리를 바탕으로 만들어진다면 그건 나름 의미있는 일일 것이다. 단, 거기에는 여러 전제조건과 단서가 붙어야 하고 현실적인 한계를 감안해야 할 것이다.

1. 당연한 말이지만, 그것은 지금 한국어를 표기하는 한국어 정서법(일명 한글 맞춤법)과는 완전히 별개로 따로 가는 체계가 되어야 한다. 한글의 표기 능력 같은 걸 떠나서 한국어에는 영어 F나 TH 같은 음가 따위는 존재하지 않는다. R과 L을 똑같이 ㄹ로 적는 이유는 한글을 모독하기 위해서(?)가 아니라 그게 한국어에서 음운론적인 변별 요소가 아니며, 고로 굳이 구분해서 적을 필요가 없기 때문이다.
과거에 조선어 학회가 무단으로, 혹은 심지어 일제와 결탁까지-_-해서 옛한글 자모를 없애고 훈민정음을 한글로 절뚝발이로 만들어 버렸다고 얘기를 하는 분을 보면.. 으음, 숨이 탁 막힌다. 나머지 뒷부분의 주장까지 신뢰성이 팍 깎이게 된다.

2. 옛한글 자모는 어떻게 활용할 것이며 한국어에 없는 소리를 어떤 규칙대로 새로운 글자에다 대응할지.. 통일이 잘 돼야 한다. 허나, 국내에 계신 한글 확장 연구가들은 내가 알기로 제각각 정말 개성 넘치고 자기 지론과 고집이 강한 분들이다. 과연 호락호락 합의가 가능할까? 아래아의 음가조차도 정확하게 모르는 마당에 하물며 다른 글자들은.. 글쎄다.
또한 한글이 기본적으로 제공되는 모음이 풍부한 건 사실이지만, 발성 기관의 모양을 본뜬 자음과는 달리 모음은 기하학적인 수직· 수평선과 점뿐이다. 이런 제자 컨셉만으로 단순히 이중모음이 아니라 IPA의 온갖 이상한 모음들을 다 그려낼 수 있을지에 대해서도 생각해 봐야 한다.

3. 알다시피 유니코드가 제정되고 BMP 영역은 마치 IPV4 주소만큼이나 사실상 고갈이 임박한 이 시점에서..
인제 와서 컴퓨터에서 예전에 없던 문자를 새로 만들어 통용하는 건 굉장히 부담이 큰 모험이다. 더구나 조합을 해서 상황에 따라 달리 표현하는 건 거의 불가능에 가까워졌다고 봐야 한다. 새로운 한글 확장 부호가 겨우 PUA 영역에만 머무르는 듣보잡이 아니라 정식으로 등재되어 쓰이려면, 국가 표준이든 대중적인 표준이든 정말 갈 길이 멀다. 그런데 그것이 과연 가능할까.

4. 새로운 한글 입력법을 같이 제안하는 분도 있다. 단, 이들도 PC에서의 표준 두벌식 글자판과 대놓고 싸우지는 않는다.
그나마 표준 두벌식 다음으로 인지도가 제2순위로 높고 모든 데스크톱 운영체제에서 이미 지원까지 되고 있는 가장 이상적이고 합리적인 대안이 바로 공 병우 세벌식인데.. 이마저도 전체 사용자 수는 1%가 채 안 된다.

그러니 하물며 이것보다도 더 마이너들은 동일한 조건에서는 전혀 승산이 없다고 봐야 한다. 그 대신 다른 차별화 요소를 통해 틈새시장을 공략하는데, 크게 (1) 모바일, (2) 장애인 접근성, (3) 지금까지 얘기했던 외국어 표기를 위한 다른 정서법으로 나뉜다. 허나 내가 보기엔 이것들도 이젠 그 많은 연구자들이 아웅다웅 다투기에는 그릇 크기가 너무 작은 레드 오션이다.

마치 이족 보행 로봇이 창작물이 아니라 현실에 등장할 가능성만큼이나 이건 녹록치 않은 문제이다.
그래서 나는 없는 정서법을 새로 만들려는 시도는 감히 하지 않는다.
개인적인 생각으로는, 음성 부호 연구보다는 이미 있는 한글 체계에 대해서 세벌식 글자판 연구나 훨씬 더 중요하게 국가 차원에서 진행했으면 좋겠다. 한국어+한글 기성 체계만으로 domain을 한정하더라도 입출력 기술 쪽으로 한글의 고유한 특성을 활용해서 새로 개발해야 할 것이 즐비하다. 그리고 그것이 나의 관심사이다. 자세한 사항은 아직 기밀이다만.

각 사람들이 자기 오덕 기질과 똘끼를 발휘하여 한글을 응용한 솔루션을 내놓고, 그것이 자연스럽게 시장의 선택을 받아서 채택되거나 도태한다면 나쁠 게 없는 현상이다. 허나 시장이라는 게 그렇게 건전하게만 돌아가는 게 아니고, 또 얼치기 한글 장사꾼이 나랏돈 타서 병크를 다 저질러 놓음으로써 나중에 동일 분야의 후학에게 돌아갈 혜택과 지원까지 막아 버린다면.. 이건 좀 큰 문제이고 비극인 것 같다. 이 문제를 어찌하면 좋을지 고민된다.

한 줄 요약: 한글은 독창적이고 과학적이고 충분히 우수한 문자인 건 틀림없다. 허나, 한글의 우수성을 살리고 싶다면 솔까말 음성 부호 연구보다는 지금 상황에서는 세벌식 연구가 훨씬 더 필요하고 절실하다.

Posted by 사무엘

지금이야 고등학생이 스마트폰 앱을 뚝딱 만들고 안드로이드나 애플 사의 앱스토어에다 등록하는 소프트웨어 유통망까지 확립된 시대이다. 하지만 지금으로부터 20여 년 전에는 개인이 만든 소위 '공개 소프트웨어'라는 것들이 PC 통신을 통해 배포되곤 했다. 게임, 업무 등 분야도 엄청 많았으며, 이거 하나로 스타 개발자로 유명세 타는 사람 역시 응당 있었다.

개발자들 중엔 대학생이 많았다. 도움말이나 리드미 파일을 보면, PC 통신 ID뿐만 아니라 개발자 자신의 소속 학교, 학과, 학번(연도만)까지 밝히곤 했다. 그들은 지금은 다 어디서 뭘 하고 있을까?
더 어린 중· 고등학생이 그 정도 퀄리티의 도스용 프로그램을 만들기엔 리소스도 부족하고 컴퓨터에 대한 인식이 부족했으며 기계값이 아직 너무 비쌌다. 하물며 Windows용 프로그램을 만들려면 더 좋은 컴퓨터에 더 비싼 개발 환경이 필요했을 테고.

국내 개발자들은 당연히 자기 프로그램의 UI를 한국어로 만들었다.
그리고 세월이 흐르면서 프로그램들은 아무리 간단하고 작은 규모라 해도, 한글 바이오스에 의존하는 텍스트 모드보다는 그래픽 모드에서 '자체 한글' 기반으로 동작하는 경우가 많아졌다.
이때 자연스럽게 필요해지는 것은 그래픽 모드에서 한글을 찍어 주고 때로는 입력까지 처리해 주는 일명 '한글 라이브러리'이다.

옛날에 도스 시절에 자체 한글을 구현한 라이브러리를 만들어서 PC통신으로 뿌리고 잡지에 강좌를 올리고 책도 쓰며 유명세 타던 프로그래머들은 굉장히 날고 기는 수재들이었다.
아예 게임을 만드는 급까지는 아니더라도 나름 VGA 그래픽 하드웨어를 제어하고 여러 래스터 그래픽 알고리즘을 최적화된 어셈블리어 코드로 직접 짜는 건 쉬운 일이 아니었다. 또한 한글 입력 오토마타를 깔끔하게 짜는 것도 아무나 선뜻 할 수 있는 난이도는 아니었다(특히 두벌식은 더 어려움).

그래서 공개 소프트웨어 리드미의 '감사의 글'(acknowledgements)을 보면, “본 프로그램은 이런 한글 라이브러리를 사용하였으며, 우수한 미들웨어를 무료로 공개해 주신 누구누구에게 감사합니다” 같은 문구도 심심찮게 볼 수 있었다.

열악한 환경의 특성상, 그 시절에 한글 라이브러리는 사실상 그래픽 라이브러리나 마찬가지였다. 그리고 더 나아가면 마우스에 간단한 대화상자까지 제공하는 통합 GUI 라이브러리로 발전하곤 했다.

아래아한글의 개발사로 유명한 한글과컴퓨터 사에서는 아무래도 저런 기술의 본좌이었을 테니, 1991년엔가 <컴퓨터 속의 한글>이라는 책을 출간했다. 싸제 한글 라이브러리를 개발한 많은 프로그래머들이 이 책을 참고하여 터를 닦은 뒤, 자기만의 살을 붙이고 자신만의 방식으로 API를 설계해서 물건을 만들었다.

회사가 아닌 개인 자격으로는 PC 통신 시절에 '터보이빨'이라는 닉으로 유명하던 임 인건 씨가 있다. 이분은 그 이름도 유명한 '한라프로'라는 걸출한 물건을 개발하여 상업용으로 판매도 했으며, 아마 서울대 기계공학과 재학 시절에 터보 C 정복이라고 책도 하나 썼다. 본인 역시 아래아한글 1.x로 편집· 조판되어 있던 이 고전을 읽으면서 C언어 기초를 닦았었다.

어디 그 뿐이랴? 지금까지도 인터넷 검색을 하면 굴러다니는 '프로그래머 십계명'이라는 글도 저분 작품이다.
이 정도면 저분은 거의 프로급 소프트웨어 엔지니어 같은데... 프로필을 보면 알 수 있듯 저분은 프로그래밍이 본업이 아니다. 훗날 저분은 같은 학교에서 박사까지 마친 뒤, 업계에서 고급 엔지니어 경력을 쌓다가 지금은 '성진 C&C'라고 금속, 재료 쪽 중소기업의 부사장 자리에 올랐다.

그리고 또 '한라프로'와 더불어 한글 라이브러리의 양대 산맥이던 물건으로는 '허르미'가 있는데, 이걸 개발한 분은 한 우진 씨이다. 국내의 유명 철덕인 한 우진 씨(미래철도 DB)와는 동명이인임.

저분 역시 물건만 만들어 공개하고 끝이 아니라, 한글을 구현하는 기술 디테일을 친절하게 저술까지 해서 이름을 날렸다. 그리고 카이스트 전산학과에서 학, 석, 박을 마치면서 멀티미디어 데이터 압축 알고리즘 쪽 전문가가 되었다. 졸업 후엔 삼성 전자에서 몇 년 근무하다가 나중에는 가천 대학교 교수로 부임했다.

다들 왜 저렇게 똑똑한 거야..;;; ㅜㅜ
후대에 등장한 많은 한글 출력 라이브러리들은 한컴 사의 책이든, 위의 두 제품의 영향을 어떤 형태로든 받았다고 생각하면 된다. 1990년대 중반 이후에 만들어진 것들은 시대의 흐름답게 슈퍼 VGA를 지원하고 32비트 환경(Watcom C/C++ 내지 DJGPP)을 지원하는 식의 발전이 이뤄지기도 했다.

저런 선구자들에 비해, 본인은 도스 시절이 다 끝난 뒤에야 한글 관련 솔루션의 개발에 입문했다. 하드웨어 제어나 그래픽 알고리즘, GUI 따위를 자체 구현할 필요는 전혀 없고 내 입력기는 그렇다고 자동 완성, 상용구, 속기 같은 NLP/lexicon 기반요소가 등장하는 것도 전혀 아닌데 도대체 이 바닥에서 무슨 일을 한 걸까?

그런 것들이 없는 대신에 내 프로그램은 그야말로 한글을 자모 단위로 조작하는 기본 동작에만 초인적인 집중과 최적화를 했으며, 온갖 똘끼 넘치는 아이디어들을 구현하게 됐다.

아울러, 내 프로그램은 다른 건 몰라도 자체 편집기에서 도스 시절의 비트맵 글꼴을 출력하는 루틴만은 여전히 답습하고 있다. 옛날 추억과 한글 프로그래밍 정신 계승(?), 그리고 기술적으로는 한글 조합 자모나 옛한글 표현 같은 여러가지 이유 때문이다.
이건 한글을 가장 가볍고 단순하게, 마치 컴퓨터 속의 기계식 타자기처럼 원시적으로 출력해 주는 시스템이라는 상징적인 의미가 크다.

본인은 지금은 타자기 시절이나 도스 시절과는 다른 차원의 한글 프로그래밍이 여전히 필요하다고 생각하며, 심지어 한국어를 개입시키지 않더라도 한글 자체에 대한 엔지니어링이 연구할 여지가 있다고 생각한다. <날개셋> 한글 입력기의 개발을 다 마치고, 가까운 미래에 박사까지 다 마치고 20년쯤 뒤 먼 미래엔 뭘 하고 있을까? 한글 가지고 더 창의적으로 먹고 살 거리가 없으면 진짜로 철도로 업종 전환할지 알 수 없는 노릇이다. ㅎㅎ

Posted by 사무엘

작년 가을엔 <응답하라 199x>라는 레트로 장르의 TV 드라마가 인기가 많았다.
요즘은 사극 드라마라도 하나 방영되면 전국의 역덕후들이 벌떼처럼 일어나서 별 희한한 곳에서 고증 오류들을 찾아 올리는 게 관행이다. 이 드라마 역시 예외가 아니었다.

2013년 10월 18일 방영분에는 아래와 같은 유명한 장면이 나온다.

서울 지하철 1호선의 노선색이 빨간색이고 역명판이 둥글게 만들어져 있던 옛날 시절을 재현한 것까지는 좋다. 솔직히 말하면 본인조차도 그 실물을 본 적은 없다. 본인은 서울 태생이 아니며 서울 지하철을 이용하기 시작한 건 21세기부터이기 때문이다.

그럼에도 불구하고 저 장면에는 여러 크고 작은 고증 오류가 존재한다.
벽면의 인테리어가 실제 지하철 서울 역과 다르며 섬식 승강장 역을 상대식 승강장으로 만들어 놓은 건 애교라 친다만...
역명판의 글꼴을 2003년에 만들어진 걸로 쓰면 어떡하냐. 무려 코레일체!

20세기 설정에 너무 깔끔한 21세기 서체가 혼자 확 튀어 보인다.
게다가 저건 철도청/코레일의 전속 서체이지 서울 지하철에서 쓰던 서체도 아니다.
완전 어처구니없는 고증 오류가 아닐 수 없다.ㅋㅋㅋㅋㅋ

또한, 글꼴만치 부각되는 건 아니지만 '서울驛'이라는 한자 병기가 들어간 것도 오류다.
서울 지하철이 처음 개통했을 때는 역명판에 한자 병기가 없었기 때문이다. 그건 1999~2000년대가 돼서야 추가되었다. 딱 그 시기에 로마자 표기법 개정분 반영, 한자 병기와 더불어 국철(= 광역전철) + 지하철 노선색 통합까지 몽땅 진행되었으니 수도권 전철의 외형이 크게 바뀌는 시기였다.

그건 그렇고 아무튼...
그럼 1994년 기준으로 코레일체 대신 저기에 무슨 글꼴이 들어가야 맞는지 궁금하다면, 아래의 '진짜' 옛날 사진을 참고하시기 바란다. 엔하위키엔 관련 자료가 이미 다 올라와 있다. ㅎㅎ

시대를 풍미해 온 지금의 지하철 전속 서체와 같거나 최소한 비슷한 투의 납작한 헤드라인이 그때에도 쓰였다.
초롱테크에서 1990년대 중반에 정식으로 내놓은 그 디지털 서체는 그걸 좀 더 세련되게 다듬은 게 아닐까 싶다.

본인은 개인적으로 이 서체를 굉장히 좋아한다. 마치 런던 지하철의 전속 서체가 그야말로 런던 지하철 전체의 정체성을 대변하는 명물이 되어 있듯, 저 서체는 수도권 전철까지는 아니어도 서울 지하철을 대표하는 서체가 되기에 손색이 없다고 생각한다.

그런데 왜 그걸 함부로 바꾸고, 이미 만들어 놓은 멀쩡한 시설까지 돈 들여서 뜯어고치고 있는지 모를 일이다.
서울 도시철도 공사 관할역들의 경우, 지상에 있는 검은 배경의 세로형 역 폴사인의 서체가 어느 샌가 야금야금 서울 남산체로 바뀌고 있다.

오히려 지하철이 아니라 광역전철 소속이어서 우측도 아닌 좌측통행으로 건설된 신분당선이 클래식 지하철체를 살려 쓰고 있으니.. 혼란스럽다.

음, 그나저나 응답하라 1994의 오류가 또 생각 났다.
내가 언뜻 본 기억으로는 그 드라마 내부에서 등장하는 TV 뉴스 화면의 자막이...
굴림은 양반이고 아예 나눔고딕인 장면이 있었다!

서 태지가 은퇴하는 소식이 나오는 20세기 복고 드라마에, 2008년 한글날에 무료 배포된 서체가 등장한다는 게 말이 되냐.. ㅋㅋㅋㅋ

요즘은 유튜브만 검색하면 1990년대 옛날 영상 매체의 주요 장면을 아주 쉽게 구할 수 있다.
자막에다가는 엑스포체나 그래픽체만 넣었어도 지금으로부터 2, 30년 전의 영상 매체의 구리구리한(?) 분위기를 아주 손쉽게 낼 수 있었을 것이다. 무슨 서체를 쓰든 CG 처리는 똑같이 필요했을 텐데, 이게 무슨 돈이 더 드는 일도 아니고!

* 결론

1. 이렇듯 글꼴 유행도 시대에 따라 변한다.
2. 철도와 성경의 융합에 이어 철도와 글꼴의 융합도 얼마든지 가능하다.

Posted by 사무엘

유니코드 1.x가 제정되었을 때는 믿거나 말거나 한글도 글자마디는 완성형 몇천 자만 지금과는 딴판의 영역에 등록되어 있었다. 단, 글자마디뿐만 아니라 옛한글을 포함한 자모도 자음 134개(물론 초성과 종성의 개수는 서로 다르고 따로 등록됨), 모음 66개가 등록되어서 이 자모들을 아래아한글 2.x가 한컴 2바이트 코드에서 그대로 채택해서 썼다. 한컴 2바이트 코드는 기존 조합형 코드와 유니코드를 적당히 짬뽕한 문자 코드였던 것이다.

유니코드는 첫 도입 배경이 저렇다 보니 “유니코드 = all 2바이트 단일 문자 체계 = wide character 문자 체계”라고 혼동하는 사람이 적지 않다. 그러나 이는 개념적으로 올바른 관계가 아니다. 2바이트 문자 체계로만 치자면 한컴 2바이트 코드도 이에 해당하며, 윈도 이외에 유닉스 계열 OS에서는 wide character는 16비트가 아니라 32비트인 경우도 있다. 왜 32비트이냐 하면 6만 5천여 개라는 집합 크기도 시간이 흐르다 보니 부족해졌기 때문이다.

1996년에 유니코드 2.0이 제정되면서 유니코드는 오늘날 우리가 아는 유니코드와 같은 뼈대가 갖춰졌다. 한번 등록한 문자는 이제부터 재배치나 제거 없이 영구불변으로 굳히기로 했으며, 이때 현대 한글 글자마디 11172자가 순서대로 고스란히 등록되었다. 2바이트 조합형처럼 비트 연산은 못 쓰지만 그래도 테이블 없이 뺄셈과 나눗셈, 나머지 연산으로 한글의 자소 정보를 얻을 수 있으니, 과거 조합형 한글 코드의 장점을 유니코드에서도 물려받은 셈이다.

외국 위원들의 반대를 무릅쓰고 한글에다 유니코드의 금싸라기 영역을 이만치 할당 받기 위해 한국 위원회 사람들이 애를 많이 썼다. 사실 확장완성형도 유니코드 등록 근거를 대기 위해 급히 만들어진 것이라고 한다.
이와 더불어 유니코드 2.0에서는 중요한 개념 내지 꼼수가 추가로 도입되었는데, 바로 surrogate이다.
16비트 공간 중 일부 영역은 그대로 쓰지 말고 따로 떼어 내서 두 글자를 뭉쳐서 더 많은 종류의 글자를 표현하는 데 쓰자는 것이다.

0xD800부터 0xDBFF는 high surrogat이고, 0xDC00부터 0xDFFF까지는 low surrogate이다. high는 언제나 앞에, low는 언제나 뒤에 오는 식으로 역할이 딱 고정되어 있다. 1024개의 앞짝과 1024개의 뒷짝이 만나니, 총 2048개의 독립 글자를 희생하여 2의 20승, 약 100만여 개의 글자 공간을 추가로 확보할 수 있게 된다. 요컨대 유니코드에 U+D800 같은 글자는 없고, U+D7FF 다음에는 곧바로 U+E000이 이어진다. 그 대신 0xD800과 0xDC00이 만나면 U+10000이라는 surrogate, 즉 확장 평면이 시작될 뿐이다. 예전의 16비트 단일 영역은 '기본 다국어 평면'(BMP)이라고 불리게 되었다.

비록 과거의 1바이트/2바이트 혼합 체계보다는 사정이 훨씬 낫고 문자열 처리가 수월한 건 사실이지만, 어쨌든 유니코드도 확장으로 인해 2바이트 단일 표현(UCS2)이라는 깔끔한 장점은 포기해야 하게 되었다. 이쯤 되니 유니코드라는 개념에서 문자 코드와 인코딩을 구분해서 표현해야 할 필요가 생겼다.

유니코드 자체는 UCS, 즉 universal character set이라 불리는 단일 문자 집합이다. 얘는 '가'라는 한글 글자에다가 U+AC00이라는 코드값을 부여해 줄 뿐, 그 코드값이 메모리나 파일에 어떻게 표현되는지에 대해서는 규정하지 않는다. 이를 표현하는 방식이 바로 Unicode transfer format, 즉 인코딩이 된다.

모든 유니코드 번호를 아무 뒤끝 없이 32비트 정수 하나로 균일하게 표현하면 그것은 UTF32이다. 아까 wide character가 4바이트인 플랫폼은 바로 UTF32를 구현하는 자료형인 것이다. 가장 깔끔하고 공간도 넉넉하고 모든 글자를 하나씩 쉽게 접근할 수 있지만 한 글자가 4바이트나 차지하여 메모리 낭비가 심하다.

BMP 영역에 있는 놈은 종전대로 16비트 정수 하나로 표현하고 확장 평면에 있는 놈만 surrogate 두 개로 쪼개서 표현하는 방식은 UTF16이라고 불린다. UCS2를 개념적으로 확장한 것이기 때문에 처음부터 2바이트 wide character를 표방하며 개발된 Windows 플랫폼이 매우 사랑하는 방식이다. 비록 Windows의 wchar_t는 이제 유니코드 코드 포인트 하나를 온전히 표현할 수 있을 정도로 충분히 크지 못한데도 말이다.

끝으로, 그 이름도 유명한 UTF8이 있다. 얘는 U+007F 안에 드는 전통적인 알파벳· 숫자, 제어 문자들은 1바이트로 유지하고, 나머지 BMP 영역의 외국어들은 2~3바이트로 표현하고 surrogate는 BMP와 동일한 4바이트로 늘여 표현하는 진정한 multibyte 인코딩이다.

n째 문자를 찾는 무작위 접근은 안 되겠지만, Windows NT처럼 커널을 처음부터 16비트 문자 단위로 설계하지 않고도 기존 8비트 문자 시스템에서 유니코드를 단절감 없이 표현할 수 있다는 엄청난 장점이 있다. CPU의 엔디언(비트 배열 순서)의 영향을 받지 않으며, tail byte가 기존 영문· 숫자와 충돌을 일으키지도 않는다는 점도 좋고 말이다.
그래서 얘는 웹에서 매우 사랑받고 있고 윈도 이외의 플랫폼에서는 파일뿐만 아니라 메모리 저장용으로도 UTF8이 즐겨 쓰인다. 사실 윈도만 이례적으로 UTF16을 너무 사랑하고 있는 것이고.. ㅎㅎ

여담이지만 UTF32, 16, 8 중 유니코드의 문자 집합이 먼 미래에 또 확장되어야 할 때, 공간이 가장 넉넉하게 남아 있는 놈은 두 말할 나위 없이 UTF32이다. UTF8이야 애초부터 들쭉날쭉 가변 길이 인코딩을 표방했기 때문에 한 글자당 4바이트보다 더 긴 5~6바이트까지 약간 더 확장할 여지가 있다. 지금 당장은 그것까지는 쓰이지 않지만 말이다.

하지만 UTF16은 유일하게 확장의 여지가 전혀 없다. 지금 surrogate 영역이 다 차 버리면 surrogate의 surrogate라도 또 만들지 않는 이상 답이 없다. 그리고 그런 헛짓을 할 바에야 차라리 UTF16을 폐기하고 UTF8 아니면 UTF32로 갈아타는 게 낫지..;; 이런 미묘한 면모가 있다.

다만, 한글 표현의 관점에서는 메모리가 가장 적게 드는 인코딩이 UTF16이라는 것도 감안할 점이다. 현대 한글 글자마디의 경우 UTF8은 3바이트, UTF32는 4바이트이지만 UTF16은 2바이트다. 초-중-종성이 모두 갖춰진 옛한글이라면 UTF8과 UTF32는 각각 9바이트, 12바이트를 차지하지만 UTF16은 6바이트이니 차이가 더 벌어지게 된다. 유니코드에는 한글이 완성형(글자마디+호환용 자모) 방식과 조합형(세벌 한글 자모) 방식이 모두 등록되었으며 완성형 방식도 11172자가 순서대로 모두 등록되었으니, 예전의 조합형· 완성형 논쟁을 완전히 종결짓는 데 성공했다.

Windows NT도 처음에 개발될 때 문자 처리 단위를 wide로 무리해서 넓히느라 고생하지 말고, 그냥 UTF8만 도입했으면 어땠을까 싶지만 이제 와서는 다 지난 일이다. 아무래도 UTF8보다야 UTF16이 컴퓨터의 입장에서는 더 빠르고 간편하게 각각의 문자를 인식할 수 있으며, 이것이 메모리와 성능 소모면에서 UTF32와 UTF8 사이의 완충지대 역할을 해 온 건 부인할 수 없기 때문이다. 덕분에 Windows API의 관점에서는 UTF8조차도 native 인코딩인 유니코드 UTF16으로부터 '변환'되어야 하는 여러 multibyte 인코딩 중의 하나일 뿐이다~! ㅎㅎ

옛날에 인터넷 익스플로러의 버전이 5~6이던 시절엔 한글로 된 URL이 인식이 잘 안 돼서 맨날 “URL을 UTF8로 보냄” 옵션을 끄라는 지시가 팁처럼 공유되곤 했다. 당시엔 Unicode-aware하지 않은 웹 서버가 아직 많아서 말이다. 오늘날로 치면 UAC(사용자 계정 컨트롤)를 끄거나 팝업 창 허용 기능을 사용하는 것과 비슷한 편법이다.
하지만 요즘은 UTF8 방식 URL이 표준으로 정착한 지 오래다. 호환성을 중요시하는 IE에나 그런 옵션이 있지, 크롬 같은 브라우저는 선택의 여지 없이 무조건 UTF8이기도 하고 말이다.

유니코드는 문자 처리 기술의 발전과 함께 더욱 덩치가 커졌으며, 한편으로 더욱 복잡해지고 지저분해지고 있다.
UTF32가 아닌 인코딩으로는 어차피 메모리 배열 인덱스만으로 실제 글자 인덱스를 얻을 수 없는 것은 물론이거니와, 메모리 상으로 존재하는 글자 코드 포인트 수와, 화면에 출력되는 글자의 수도 일대일 대응이 전혀 이뤄지지 않게 되었다. 옛한글이라는 것도 유니코드 관련 기술이 방대해지면서 덤으로 같이 처리 가능해졌을 뿐이다. 진짜 미치도록 복잡한 문자에 비하면 옛한글 쯤이야 양반이지... 동일한 글자를 나타내는 방법이 여러 가지 존재하게 되어서 정규화라는 것도 필요해졌다.

코드 포인트 값만으로 정렬을 하는 것 역시 상당수 의미를 잃었다. 옛한글 자모는 유니코드 5.2 때 한양 PUA 비표준에만 존재하던 것들이 추가 등록되었는데, 이것들의 코드 포인트상의 순서를 따지는 건 부질없는 짓이다. 가뜩이나 부족한 BMP 공간의 여러 틈새에 산발적으로 간신히 등록된 것 자체를 감지덕지해야 할 판이다.

한자는 더욱 가관이다. 유니코드에서 공간을 압도적으로 제일 많이 차지하고 있는 문자인 건 두 말할 나위도 없거니와.. BMP 영역에 이미 등록돼 있고 호환용 같은 이유도 없는데 작업자의 실수로 인해 나중에 surrogate 확장 평면에 중복 등록된 글자도 있고, 일본 문자 코드의 실수 때문에 문헌에 전혀 등장한 적이 없는 유령 한자가 등재돼 있기도 하다.

이것이 오늘날의 컴퓨터 문명을 지배하고 있는 가장 원초적인 규범에 속하는 유니코드의 현실이다. ㅎㅎ
수십 년 주기로 유니코드를 전면 reset하고 코드값을 재정리하면 어떨까 싶지만 그건 기존 컴퓨터 문명이 핵 전쟁 같은 걸로 폭삭 없어지지 않는 한, 상상 속에서나 가능한 일일 것이다.

Posted by 사무엘

디지털 컴퓨터는 전자 신호로 0과 1만을 인식할 수 있다. 그렇기 때문에 컴퓨터에서는 문자 역시 0과 1의 조합인 숫자로 표현되며, 문자를 그런 숫자에다가 대응시키는 규칙이 바로 문자 코드이다. 정보 교환을 원활히 하기 위해서는 보내는 쪽과 받는 쪽이 모두 문자 코드가 통일돼 있어야 함은 두 말할 나위가 없다.

정보량의 최소 단위는 1비트이지만 현실적으로 컴퓨터의 기억 장치들이 한 글자로 취급하는 정보량의 최소 단위는 8비트, 즉 바이트이다. 8비트, 2^8승, 즉 256이라는 정보량은 숫자와 알파벳을 정하는 데는 충분하고 상위 1비트를 잉여화하여 오류 검출용으로까지 사용할 수 있을 정도이지만, 한글이나 한자 같은 문자를 담는 데는 턱없이 부족하다.

한자는 글자를 체계적으로 부분글자로 분해할 뾰족할 방도가 없는 상태로 글자 수가 너무 많다. 한글은 글자 생성 체계는 한자보다 훨씬 더 유리한 위치에 있지만, 실용적으로 편하게 다루려면 여전히 1만여 개의 미리 조합된 음절 형태를 그대로 배당해야 한다.

예를 들어 현실에서 '학교'라는 단어는 두 글자로 간주되지, 데이터베이스나 문서 분량 같은 데서 5글자라고 계수되는 곳은 아무도 없다. 코드 차지 영역을 줄이자니 메모리 사용량이 늘며, 그리고 오늘날로 치면 화면에 보이는 글자 길이와 메모리를 차지하는 글자 길이가 서로 완전히 따로 노는 complex script 급의 복잡한 기술이 필요해진다.

결국 한글과 한자는 1바이트만으로 표현할 수 없고 통상 2바이트로 표현된다. 그런데 기존 1바이트 영문· 숫자를 건드릴 수는 없으니 1바이트와 2바이트 문자가 공존하는 multi-byte 코드 체계가 만들어진다. 영문권에서 패리티 비트 내지 유럽 특수문자를 표현하는 데 쓰이는 최상위 1비트는, 이 문자가 1바이트로 끝인지 아니면 2바이트 문자의 첫 바이트(lead byte)인지를 판별하는 비트로 쓰인다.
공교롭게도 한글· 한자는 폭도 균일한 2글자 분량을 차지하여 비주얼 상 잘 어울린다. 전각· 반각이라는 개념이 여기서 유래된다.

그런데 lead byte는 그렇다 쳐도 2바이트의 다음 둘째 바이트인 tail byte도 기존 순수 1바이트 문자들과(영문· 숫자 같은) 전혀 겹치지 않게 할 것인지? 아니면 어차피 얘는 lead byte에 의해 변별이 됐으니 좀 문맥 의존적으로 겹치는 걸 허용할 것인지가 문제가 된다. 한글 코드의 경우 완성형은 겹치지 않으나 조합형은 겹친다.

그렇기 때문에 조합형은 tail byte가 대문자 알파벳과 소뭇자 알파벳이 제각기 따로 될 수 있고 심지어 \ 역슬래시 문자가 나올 수도 있다. 이런 이유로 인해 조합형은 1비트 + 초중성 5비트씩 한글의 구성 원리를 매우 잘 반영하여 설계된 문자 코드임에도 불구하고 당시 8.3 제약이 있던 시절에 파일 이름을 사실상 한글로 지정할 수 없었으며, 심지어 이론적으로는 // 주석을 조합형 한글로 지정한 경우 \ 때문에 2-byte aware 하지 않은 컴파일러에서는 충돌이 발생할 수도 있었다.

옛날에 한글 MS-DOS 시절에 한글 도스 셸이나 QBasic처럼 텍스트 GUI(?)를 구현한 프로그램들을 실행해 보면 한국 마소가 굉장히 잘 만든 게 있었다. 메뉴나 대화상자 같은 게 표시되어서 배경에 있던 2바이트 텍스트를 반토막 내더라도 깨진 문자열을 보여주는 법이 결코 없었다. 늘 짝수 바이트가 유지돼야 하는 한글/한자 영역이 홀수 바이트로 줄어들면 가장자리를 하나 삭제해 주면 된다.

그러나 문맥 의존적인 문자 코드로 그런 걸 구현하려면 문자열을 처음부터 읽어 봐야 하고, 두 바이트 중 하나가 소실됐을 때의 뒷처리가 문맥 독립 코드보다 더 어려우면 어렵지 쉽지는 않을 것이다. 불가능하다는 뜻은 아니지만.

조합형을 옹호하고 완성형을 까기에만 바쁜 분들의 심정이야 세벌식+한글 에반젤리스트로서 본인은 적극 이해한다. 그러나 과거의 2바이트 한글 코드의 이면엔 이런 면모도 있었음을 지적하고자 한다. 완성형은 여러 이슈가 얽혀서 그렇게 만들어졌지, 작정하고 한글을 난도질하려는 악의적인 의도로 만들어진 건 아니었다. 문맥 독립성뿐만 아니라 굉장히 보수적인 국제 규격 권장 사항을 만족하는 방식으로 문자 코드를 만들려다 보니, 한글 11172자에다 한자와 각종 특수문자들까지 넣을 절대적인 공간 자체가 부족했기 때문이다.

나중에 완성형에다 어거지로 한글 부족분을 채워 넣은 cp949 확장완성형은 어차피 조합형처럼 문맥 독립성이 깨졌다. 물론, 어차피 이렇게 만들 거면 처음부터 조합형으로 가지 하는 비판은 피할 수 없게 된 게 사실이다. 그런데, 이런 비슷한 삽질을 일본도 문자 코드를 만들면서 했으며, 이를 우리나라도 그대로 답습했을 뿐이다.

조합형과 완성형은 11172자와 2350자의 차이뿐만 아니라 한글 낱자를 표현하는 방식에서 매우 큰 차이가 있다.
조합형은 글자마디와 자모의 차이가 사실상 없다. 그냥 초 중 종성 중 한 성분만 있으면 자모이고, 초성과 중성이 갖춰졌으면 글자마디이다. 초성 ㄱ과 종성 ㄱ을 구분해서 표현할 수 있고 초성+종성이나 중성+종성 같은 '미완성 한글'도 얼마든지 표현할 수 있다.

그러나 완성형엔 그런 개념이 없다. 한글 입력을 처음 시작했을 때 쓰라고 '호환용 한글 자모'라는 게 있는데 그건 한글이 아니라 명목상으로는 '특수문자' 영역이다. 그냥 한글 자모 모양인 그림일 뿐이다. 초성+종성 구분이나 미완성 한글 표현 같은 건 없다.

메모리 1바이트가 아깝던 16비트 도스 시절에 국내에서는 조합형 한글 코드+글꼴이 쓰였지 마소의 윈도처럼 2350자 완성형 코드+글꼴로 돈지랄을 하는 프로그램은 전혀 없었다. 이런 압도적인 인지도의 차이로 인해 조합형은 1992년에 한국의 복수 표준으로 승격되어서 cp1361이라는 이름으로 나름 운영체제의 코드 페이지에 등록도 됐다.

자, 이렇게 컴퓨터는 1바이트 인코딩에다가 한중일 문화권을 위한 1+2바이트 멀티바이트 인코딩 구도가 유지되었고 마소에서는 이를 도스 시절부터 코드 페이지라고 불렀다. 그런데 이런 문자 코드들은 (1) 알파벳· 숫자 같은 공통 문자를 제외하면 같은 문자라 해도 국가마다 배당된 코드값이 같을 수가 없고, (2) 문자 집합 자체의 크기가 너무 작아서 세계 모든 문자들을 한 코드 페이지에다 담을 수 없다는 문제가 있었다.

人(사람 인)이라는 한자가 한국· 중국· 일본의 표준 코드에서의 코드값이 같을 리가 없으니 (1)은 자명한 문제다. (2)의 경우, 2바이트 코드라 해도 앞서 보았듯이 1바이트 문자와의 충돌을 피하기 위해 매우 제한된 영역의 바이트들만 묶을 수 있다. 이 때문에, 문맥 의존까지 시킨다 해도 추가로 만들 수 있는 문자는 1만여 자에 불과하다. CJK에서 쓰는 상용 한자들이나 간신히 다 집어넣을 정도이다.

그래서 1980년대 말부터 이런 발상의 전환이 이뤄졌다. “앞으로 컴퓨터의 메모리는 증가하고 소프트웨어 국제화의 중요성은 커질 테니, 글자 하나의 크기를 16비트로 쿨하게 확장하고 6만여 자의 공간에다가 전세계 언어 문자들을 집어넣고 동일 문자 동일 코드값을 실현하는 게 어떨까?”

이것이 바로 유니코드의 존재 목적 되시겠다. 컴공 전공자가 아니더라도 컴퓨터에서 '유니코드'라는 말은 한 번쯤은 다들 들어 보셨을 것이다. 이건 그야말로 컴퓨터 문자 코드계의 바벨 탑 내지 에스페란토 같은 물건이다.

마이크로소프트는 소프트웨어의 국제화에 굉장한 혜안이 있던 기업이었다. 그래서 OS/2와 결별하고 Windows NT를 첫 개발할 때, 애초부터 8비트 문자가 아니라 유니코드를 담을 수 있는 16비트 문자를 기반으로 설계했다. 심지어는 NTFS 파일 시스템까지도. 그리고는 이를 독자적으로 wide character이라고 부르기 시작했다. 어차피 8비트 문자만으로 충분하던 라틴 문화권에서는 별로 득이 되는 것도 없이 메모리 사용량만 두 배로 뻥튀기되는 대가를 감수하고라도 말이다.

Win32 API는 기존 16비트 윈도 API를 최대한 닮게 설계되었지만, 문자열을 다루는 모든 API에 A 버전과 W 버전 구분이 생겼다. 다만, 32비트 시절에 처음으로 도입된 OLE/COM 같은 기술은 처음부터 오로지 유니코드(= wide) 문자열만 취급하게 만들어졌다.

PE 방식으로 만들어진 32비트 EXE/DLL은 string 테이블, 메뉴, 대화상자 같은 리소스의 저장 포맷도 다 유니코드 방식으로 바뀌었다. 윈도 3.1에다가 Win32s를 설치하면 32비트 커널 DLL뿐만 아니라 각종 코드 페이지 변환 테이블도 설치되는 걸 볼 수 있다. 그게 바로 리소스를 변환하기 위해서이다.

윈도 NT가 3.x나 9x보다 메모리 사용량이 매우 많았던 이유 중 하나도 유니코드 때문이며, 반대로 윈도 9x가 유니코드 API를 지원하지 않았던 이유도 가정용 PC의 부족한 메모리 문제 때문이다.
이 때문에 컴파일 스위치만 바꿔서 유니코드와 기존 멀티바이트를 모두 커버할 수 있는 TCHAR, _T 같은 개념도 그때 생겼다. 두 개의 문자 포맷을 모두 지원하는 작업은 정말 엄청난 대공사였을 것 같다.

Posted by 사무엘

1. 중국 (+대만, 홍콩, 마카오): 100%

중국어는 딱히 굴절이나 활용이 심하지 않은 고립형이고 1글자 1의미(형태소) 1음절이 성립하다 보니... 한자 같은 문자는 글자 수가 너무 많고 복잡하다는 단점을 빼면 자기 나라 말을 적는 데 그리 나쁜 솔루션은 아니다. 중국이 한자 종주국인 것엔 이유가 있는 셈이다. 물론, 그 단점이 꽤 큰 단점이긴 하지만 말이다.
중국어는 성조를 빼면 언어적으로 동음이의어도 많다. 그래서 한자로 '팔다'와 '사다'가 모두 같은 음(매)이고, 밝을 명(明)만 있는 게 아니라 어두울 명(冥)도 있다. 그걸 글자에다 뜻을 밝혀 적어서 구분하려는 생각을 한 듯하다.

이런 이유로 인해 중국은 한자 자체를 폐지하기보다는 획을 과감히 줄인 간체자를 만들어서 정착시켰는데, 이는 여타 한자 사용 국가들과의 단절과 혼란을 야기했다는 비판도 받고 있다. 지금과 같이 문자를 기계식이 아닌 전자식으로 다룰 수 있는 성능 좋은 기계가 일찍 발달했으면 쟤들은 굳이 간체자를 만들 생각을 안 했을지도 모른다.

2. 일본: 90% 보조 문자만 도입

일본어는 구조적으로 중국어보다는 한국어에 훨씬 더 가까운 언어이기 때문에 애초부터 한자만을 표기 수단으로 쓰는 것엔 불편함이 있었다. 일본어는 성조가 없고 음운 구조도 간단한 대신, 한자 하나를 여러 음절로 읽을 수 있고 훈독과 음독으로 모두 읽을 수 있다. 그래서 자기네 단순한 음운 구조에 맞춘 히라가나· 가타카나라는 표음문자를 보조적으로 덧붙여서 쓰고 있다.

한자를 없애고 고유 문자만으로 자기네 언어를 다 표기하는 건 불가능하지는 않다. 하지만 길어지고 보기 안 좋아지는 관계로 한자를 완전히 대체하는 건 영 한계가 있다. 마치 한글 자모가 단독이 아닌 모아쓰기를 전제로 만들어져 있는 것만큼이나 일본의 고유 문자는 한자 같은 여타 문자를 보조하는 용도로 만들어졌다는 성격이 강하다.

중국어와 일본어 텍스트에 쓰이는 복잡한 한자들은 한 글자씩 짜 맞춰서 입력하기가 너무 느리고 불편하다. 그렇기 때문에 문장이나 어절 단위로 더 긴 문자열을 입력함으로써 context를 만들고 후보 수를 줄인 뒤에 한꺼번에 변환을 한다. 즉, 이들 언어는 NLP 기술이 동원된 복잡한 입력 프로그램이 필요하다.

3. 한국 (대한민국, 북한): legacy로서 극소수 1% 미만. 고유 문자로 사실상 대체

교착어인 한국어의 복잡 미묘한 용언 활용을 한자로 제대로 표기할 수는 없는 노릇이며, 한국어는 음운 구조도 일본어보다 더 풍부하고 복잡하다. 이런 배경 속에서 세종대왕은 인류 역사상 유례를 찾기 힘든 똘끼를 발휘하여 세계가 놀라고 극찬하는 완전한 형태(full-featured, stand-alone)의 고유 문자를 만들어 버렸다.

한글은 단독으로 써도 시각성과 변별성이 충분히 우수하며, 한국어에서는 한자와 음의 대응이 일본어보다 훨씬 단순한 편이다. 의미상 모순되는 동음이의어만 피해 가면 한자 대신 고유 문자 전용이 어렵지 않게 가능하며, 그것이 이미 실제로 일어났다! 게다가 한글은 NLP 기술 없이 매우 빠르고 편리하게 입력도 되고 기계화가 가능하다.

그래서 20세기 중반 이후로 한반도에서는 한자가 빠른 속도로 도태되어 사라졌으며, 한자는 아주 예외적인 상황에서나 희소하게 등장하는 물건이 되었다. 한국어가 중국어와 아예 완전히 다른 언어이고 한자 표기가 어울리지 않는 구조이기 때문에 이에 대처하는 솔루션도 아예 극단적으로 새롭고 과격하게 출발 가능했던 것 같다.

4. 베트남, 몽골: 0% 완전히 폐지하여 흔적조차 없애고 여타 문자로 대체

베트남은 로마자로 공식 문자를 바꾸고 한자를 폐지했다. 단, 베트남어는 중국어보다도 성조가 더 다양해서 이런 걸 알파벳에다 덧붙이는 표기가 꽤 복잡한 편이다. 그래서 베트남 문자는 로마자 기반임에도 불구하고 컴퓨터에서 마치 아랍어 같은 complex script로 분류되고 있다.

몽골은 먼 옛날에 한자를 잠시 쓰긴 했지만 이내 자기네 고유 문자 내지 러시아 키릴 문자로 문자를 갈아탔다. 그렇기 때문에 오늘날은 베트남보다도 더 한자의 흔적을 찾을 수 없는 나라이다.

내가 한자에 대해서 글을 쓰면서 늘 느끼는 점인데,
한자는 말을 받아 적는 여러 문자 중의 하나이며, 그냥 legacy 그 이상도 그 이하도 아니다. 그러니 각 나라마다 자기 언어 사정에 맞게 편한 대로 처분하면 그만이다. 간체자 개량을 하든, 보조 문자를 만들든, 아니면 다른 문자로 완전히 대체를 하든 말이다. 그리고 그건 아주 자연스러운 현상이다. 굳이 중국어 같은 언어를 쓰는 문화권이 아닌 이상, 저렇게까지 불편하고 무거운 문자를 굳이 고집할 필요가 전혀 없기 때문이다.

한중일 3국간의 한자 통합이 가능해서 사람들이 필담이 가능하다면, 그건 불가능한 것보다는 나을지 모르겠다. 하지만 그건 정치· 언어· 문화의 장벽을 감안했을 때 호락호락 가능하지 않다. 불가능한 걸 가능하게 만들겠다고 높으신 분들이 머리를 맞대고 고민해 봤자 돈과 시간 들인 것에 비해 영양가 있는 결과가 나오지는 않을 거라는 데 한 표 건다. 조금 심하게 말하면, 그건 같은 라틴 알파벳을 쓴다고 해서 유럽 국가들이 다 필담으로 의사소통이 가능할 거라고 생각하는 것만큼이나 무모한 발상이다.

한자는 원칙이 있는 것 같으면서도 결국은 없는 chaotic한 글자이다.
뭔가 제자 원리를 봤을 때 한자처럼 생기긴 했는데 인류 역사상 그 어떤 문헌에도 존재한 적이 없는 '유령 한자'가 있다는 건 문자 코드에 관심이 있는 분이라면 이미 아실 것이다. 중국이나 일본에서 문자 코드를 제정하면서 글자들을 수집할 때, 어느 작업 인부가 실수를 한 모양이다.

빽빽한 중국어 자연어 텍스트처럼 생겼는데 실제로는 언어적인 의미가 전혀 없고 실존한 적이 없는 한자처럼 생긴 글자들로만 구성된 텍스트 디자인을 만든 사람도 있다. 그래, 한자는 역시 그런 문자이다.

Posted by 사무엘