0. 들어가는 말

한글과 한자 문제는 정말 낡고 케케묵었고, 이미 대세를 거스를 수 없는 결론까지 도출된 주제이다. 본인 역시 나이 40이 임박한 지금까지 20여 년째 동일한 지론을 유지하고 있다. 오늘은 오랜만에 이에 대한 생각을 또 복습해 보고자 한다.

"한글로만 쓰니까 무슨 단어 뜻이 분간이 안 되고 어쩌구저쩌구" 하는 불평들은 나도 하라면 한 트럭을 끄집어낼 수 있다.
"역전의 용사"는 지고 있던 전투를 운동 경기마냥 역전(?)시킨 용사가 아니라는 것,
정부 조직을 가리킬 때의 部와, 삼권 분립을 가리킬 때의 府가 다르다는 것 뭐 등등..
온갖 병신같은 교인이나 목사나 교회 욕하면서 나는 이래서 예수 안 믿는다, 교회 안 다닌다.. 이러는 것과 완전히 똑같은 원리로 늘어놓을 수 있다.

그러나 그러나~~~~ 한글· 한자 문제에서는 다음과 같은 사항을 추가로 고려해야 한다.

1. 쓰기: 문자는 그림보다 아라비아 숫자에 더 가까워야

"한글로만 쓰니까 무슨 단어 뜻이 분간이 안 되고 어쩌구저쩌구" 하는 불평은..
그 자체조차도 나머지 90%에 달하는 이미 잘 분간되는 어휘들을 한글로 정말 편하고 빠르게 잘 읽고 쓰고 있기 때문에 나올 수 있는 불평이다! 알겠는가?

할배가 민주주의를 유린한(? 한 5%쯤?) 독재자라고..??
그 독재를 비판할 수 있는 90~95% 민주주의 토대를 닦아 놓은 사람도 할배다. 그와 같은 이치이다. 자, 이 비유를 들면 좀 이해가 빨리 되려나?

한글이나 알파벳 영단어는 최소한의 문자 체계만 떼고 나면, 최소한 모르는 단어를 사전에서 찾아 보는 거 하나는 아주 수월 간결하게 할 수 있다. 어떤 단어로부터 기본형을 유추하는 게 그리 어렵지 않으며, 유한한 요소만으로 무한의 개념을 표현한다는 체계가 있기 때문이다. 이게 문자와 그림의 본질적인 차이이기도 하다.

허나, 한자는 그림 티를 좀 못 벗은 무한집합-_- 문자이다. 모르는 글자를 옥편에서 찾는 데 시간이 얼마나 걸리며(부수, 획수..) 실패율도 얼마나 높을까?

게다가 읽을 줄 아는 것과 쓸 줄 아는 건.. 또 별개의 문제다. 컴퓨터조차 없던 시절에 "아 배고프다, 밥먹고 싶다" 이런 문장까지 백지 상태에서 한중일 어느 언어 방식이건 한자만으로 써야 한다면..?? 아 정말 끔찍하다.
설령 컴퓨터가 있다 해도 맨손에 펜만 있을 때보다야 쓰기가 편리해질 뿐이다. 다른 간편한 소리글자들도 동일하게 컴퓨터의 혜택을 받고 있다면, 한자는 이것들에 비해 입력하고 취급하기가 번거로우며 여전히 격차가 벌어진다.

2. 말하기/듣기: 글자가 아니라 알아들을 수 있는 말이 먼저

그리고 더 결정적으로, 언어라는 건 말이 먼저지 글이 먼저가 아니다. 한자의 음은 기본적으로 왕창 옛날 중국어 음의 낡은 껍데기일 뿐이다. 한글로만 써 놓으니 분간이 안 되는 문제에 앞서, 말이 글자 그림을 봐야만 이해되는 지경으로 배배 꼬이는 것이 더 문제라는 것이 나의 굳건한 지론이다.

정말 단순하고 상식적인 것에서부터 먼저 의문을 품고 제기해 보자.
수수(授受)와 매매(賣買).
세상에, 지구상의 어느 미친 언어가 '주다'와 '받다'라는 정반대 뜻을 같은 소리로 표현하냐?
'팔다'와 '사다'도 마찬가지.
'방화'는 너무 유명한 예일 테고, 그리고 명왕성의 명(冥)은 '어두울 명'이다. '밝을 명'(明)만 있는 줄 알았지? ㄲㄲㄲㄲㄲㄲ

이건 한자로 적지 않으면 뜻을 알 수 없네 타령을 하기에 앞서 말이 이상한 것이다.
형성자라는 건 알고 보면 굉장히 골때리는 제자 원리이다. 이건 글자를 생성하는 거지, 말을 생성하는 게 아니다.
(저 형성도 formation 形成이 아니라 形聲인 것쯤은 이과 출신인 나도 알고 있음)
이미 만들어지고 익숙해져 버린 명칭들은 어쩔 수 없지만, 최소한 더는 이런 식으로 조어를 하지 말고 청각 변별이 되고 잘 와닿는 쪽으로 말을 만들 생각, 시늉이라도 해야 한다.

중국어에는 성조라는 게 있어서 한국어보다는 한자 변별이 되는 편이다. 중세 땐 우리나라(조선??)조차 한자를 좀더 중국식으로 발음하려고 성조를 도입했던 것 같으나, 지금은 몽땅 사라졌다.
그런데 이 성조라는 게 노래를 부를 때는 전혀 표현될 수 없다. 한자의 발음들은 전부 문맥만으로 분별돼야 하며 의미가 잘못 전달될 수도 있다. 그렇기 때문에 내가 알기로 중국은 자기네 가요 뮤직비디오에 자막을 반드시 넣어 줘야 된다.

일본은..? 한자를 청각적으로 최대한 변별하려다 보니 읽는 방식이 너무 다양하고 복잡해져서 한자 위에 히라가나 토가 널리 쓰인다. 특히 이름 같은 생소한 고유명사의 한자는 이렇게 안 해 주면 거의 못 읽는다.
나는 이런 게 정상적인, 자연스러운 문자 생활이 "아니라고" 생각한다. 한 20년쯤 전부터 했던 생각이고 지금도 변함없다.

3. 결론: 국어 교육의 문제와 한글 전용의 문제를 서로 헷갈리지 말자

(1) 문자의 본질: 문자라는 건 말을 받아적는 도구 이상도 이하도 아니며, 그림보다는 추상적인 '숫자'에 더 가까운 면모를 지니는 게 바람직하다.
한자가 일단 익숙해지고 나면 함축적이고 시각성이 뛰어난 구석이 있는 것은 사실이다. 그러나 '읽기'의 장점을 위해서 치르는 '말하기/듣기'와 '쓰기'의 대가, 단점을 결코 만만하게 봐서는 안 된다!

(2) 한국어의 실정: 한국어는 중국어· 일본어와 달리 장단이고 성조고 훈독이고 뭐고 없다시피하며, 한자들을 정말 단순무식하게 한글 1음절로만 연결시켜 놓았다. 거기에다 한글이라는 문자도 자체적인 구조가 꽤 탄탄하며, 히라가나 카타카나 같은 한자 혼용을 전제로 한 보조용 문자가 아니다.
그러니 동음이의어 정리만 좀 해 주면 한글 전용을 하기에 매우 유리한 면모를 갖췄으며, 오늘날 실제로 그렇게 됐다.

(3) 문자 정책: 한글 전용을 전제로 하고, 마치 생소한 신조어를 드러내기 위해서 영어에서 하이픈이나 일부 음절 대문자화를 하듯이 가끔 괄호 안에 한자 병용만 하는 것으로 족하다.
개인적으로 일본식 한자어를 반대하는 소신은 아니다. 하지만 표기까지 몽땅 한자를 밝혀야 할 정도로 중구난방으로 쓰는 것은 반대다. 민족 감정 때문이 아니라 언어학적, 실용적인 측면에서만 접근한다.

(4) 교육: 뭐든지 도둑질만 아니면 많이 공부하고 배워서 나쁠 건 없고 그건 한자도 예외가 아니다. 그러나 겨우 말을 담는 껍데기 그릇을 공부하는 것 하나가 이렇게 어렵고 사용하기가 불편하고 시간이 많이 걸리는 것은 큰 문제이다. 한자는 한자어의 어원을 변별하고 의미를 정확하게 학습하는 용도로 쓰기가 아닌 '읽기' 위주로만 가르치면 된다.
국어 교육 문제를 한글 전용 문제로 돌릴 필요는 없다. 국어 교육을 똑바로 안 시키고 표기만 한자 병용을 하면? 한글 대신 헷갈려서 잘못 쓰인 한자들만 글에 가득해질 것이다.

그리고 덧붙이자면.. 한글 전용을 지지하는 사람일수록 한글 맞춤법과 띄어쓰기를 더욱 잘 지켜서 글을 써야 한다. 그게 한글의 표의성과 시각성을 살려 주는 규칙이기 때문이다.

4. 여담

(1) 성경조차 히브리건 그리스건 알파벳이건 소리만 받아적는 간결한 소리글자로 기록됐지, 뜻글자가 쓰이지 않았다.
또한, 세상에서 제일 높은 최고존엄에 대해 다루고 있는 텍스트이지만 한국어 같은 복잡한 높임법 따위 존재하지 않고 하나님도 you라고 바로 가리키는 언어로 기록됐다. 예수냐 예수님이냐 이런 게 본질적인 문제가 아니리는 것이다.

(2) 우리나라의 경우는 과거에 일제가 총칼로 한국어 한글을 말살하면서 일본어를 강요했으니 그건 극심한 저항과 반발에 부딪혔다.
그런데 그렇지 않고, 영국 미국 같은 나라가 한국을 식민지로 삼고,

  • 한국어 대신 영어를 쓰면.. X나 골치아픈 호칭, 높임법 신경쓸 필요 없이 누구나 이름으로 부르고 you로 바로 가리킬 수 있어요~!!
  • 어려운 한자로부터 해방될 수 있어요~!
  • 세계의 석학들, 최신 지식 정보와 바로 소통할 수 있어요~!
  • 미개한 붓이 아니라 타자기로 아주 빠르고 편하게 글을 쓸 수도 있어요~!

이렇게 당근만 흔들면서 접근했으면.. 당시 지식인들이 어떻게 반응했을지, 한국어와 한글의 운명이 어찌 됐을지 나는 장담을 못 하겠다. 이런 여건에서도 공 병우 같은 천재가 한글 타자기를 발명할 수 있었을까?
물론 저런 실용주의적인 사고방식 자체가 전후에 20세기 말이 돼서야 슬슬 등장했으니 이건 가정이 현실적이지 않은 뇌피셜일 뿐이다.

Posted by 사무엘

2021/02/14 08:37 2021/02/14 08:37
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1854

1. 왜 시발이었을까

이 블로그에서 몇 번 다룬 적도 있었던 우리나라 최초의 자국 생산 자동차 '시발'을 생각해 보자.
아무리 좋은 뜻을 담았다고 해도 그렇지, 자동차 이름을 왜 비속어가 연상되는 '시발'이라고 지었을까 지금 우리로서는 궁금증이 들 것이다. 마치 극악의 저출산 때문에 고민인 지금의 관점으로는 과거에 정반대로 "아들 딸 구분 말고 둘만 낳아 잘 키우자" 구호가 나오던 배경을 도무지 이해할 수 없는 것과도 비슷하다.

저 시절을 직접 겪은 옛날 분의 증언에 따르면.. 시발 자동차가 다니던 195, 60년대에도 한국어에 C-bal이라는 욕설 자체는 멀쩡히 존재했었다고 한다.
하지만 옛날의 언어 습관은 여러 정황상 말소리보다 한자 뜻을 훨씬 더 중요하게 따졌던 것 같다. 始發이라는.. 요즘으로 치면 '오리진, 제네시스'나 마찬가지인 좋은 뜻만 가졌으면 됐지, 굳이 "C-bal이 연상되는데?"라고 문제를 제기하는 것 자체가 마치 성에 대한 금기만큼이나 금기시됐던 것 같다. 천한 욕설은 공식적으로는 한국어에 존재하는 걸로 간주되지도 않는 어휘였다.

물론 공개 석상 말고 사석에서는 그런 고매하신 선비질 따위 없었다. 그러니 비단 시발 자동차 말고도, 한자로 뜻은 괜찮지만 소리가 이상해서 어린 시절에 흑역사급 별명을 달고 다녔던 사람이 많았다. 인명 외의 분야를 봐도 야동 초등학교도 있었고, 죽음(대나무 그늘) 마을도 있었다.

야동 초등학교의 경우, 인터넷으로 유명세를 타는 바람에 개명을 해 버린.... 줄 알았으나 그렇지 않고(단, 시골에 학생 수가 너무 적어져서 폐교 위기라고 함)... 후자의 경우 본인이 아주 어리던 시절에 TV를 통해서 봤는데, 노인들이 시골길에서 차에 치여 세상 하직하는 일이 잦아지자 불길하다면서 뒤늦게 개명했다.
(아 그러고 보니 야동 초등학교야.. 학교 이름을 짓던 시절에는 야동이라는 것 자체가 지금처럼 존재하지 않았을 테니 C-bal과는 상황이 좀 다르긴 하다.. ^^)

생각을 해 보라. '죽음'(竹陰)은 멀쩡하게 지명으로 썼으면서, 순우리말과 아무 관계 없는 한자 (중국어)와 소리가 비슷하다는 이유로 다른 멀쩡한 숫자 4는 훨씬 더 적극적으로 기피했던 것이 한국의 언어 문화였다.
개인적으로 이게 바람직한 현상이라고 생각하지는 않는다. 말과 소리가 먼저이고 그 다음이 문자이지, 말이 문자에 끌려가서 꼭 뭘 봐야만 뜻이 통하는 것은 자연스러운 언어 현상이 아니다.

한글로만 쓰니까 뜻이 제대로 드러나지 않네 하는 면모가 분명 있을 것이다. 하지만 뒤집어 생각하자면 말이 그 따위로 돼 버린 게 문제가 있는 상태라는 것이다. 서유럽· 미국 같은 나라는 표음문자 알파벳만 갖고도 넘사벽 급의 학문이고 사상이고 철학이고 과학 기술을 이룩했지 않은가?

본인 역시 그런 맥락에서 20년 전이나 지금이나 변함없는 한글 전용 지지 소신이다.
물론 지금은 그렇게 옥편 뒤지면서 듣보잡 벽자를 찾아내서 이 소리는 이런 뜻이라고 갖다붙이는 짓 대신, 온통 영어 외래어를 갖다붙이는 게 유행이 돼 있다. 어느 게 절대적으로 더 바람직한 현상인지는 잘 모르겠지만, 후자가 차라리 전자보다는 더 나은 것 같다. 듣는 것만으로 뜻이 변별은 되니까 말이다..

2. and는 접속부사인가

그럼 다음으로 잠시 한국어와 영어를 좀 비교해 보겠다.
한국어에는 체언을 잇는 '과/와' 접속조사, 용언(=구, 절 모두)을 잇는 '며/고' 연결어미, 그리고 문장을 잇는 접속부사(그리고)가 전부 따로 논다. 그러나 영어는 전부 간단하게 접속사 and 하나로 끝이다.

그런데 전통적으로 and는 접속부사로 취급되지 않았는가 보다. but, then, however, moreover, meanwhile 등은 명백히 영어의 접속부사이지만 and는 X and Y로만 쓰는 것을 정석으로 쳤던 듯하다. 프로그래밍 언어로 치면 말 그대로 이항 연산자. ㄲㄲㄲ and는 or과 같은 급이지, but과 호응하지는 않는다는 것이다.

먼 옛날에 MS Word의 스펠링+문법 검사기도 문장을 And로 시작하면 틀렸다고 지적하던 게 내 10대 시절 기억으로 남아 있다. 그 대신 "콤마+소문자 and"로 문장을 길게 이어야 했다. 왜 반드시 저래야만 하는지를 본인은 그 당시 이해하지 못하고 넘어갔다. 성경만 해도 And로 시작하는 문장이 부지기수이고, 특히 옛날 고전 텍스트인 KJV는 훨씬 더 많이 쓰였다. And 금기가 왜 있는지는 잘 모르겠다.

글쎄, 이런 게 아닐까? 원래 '보다'는 조사이기 때문에 "A보다 B가 더 낫다" 형태로만 쓰는 게 맞는데.. 요즘은 그게 부사처럼 쓰여서 건방지게 앞에 나오는 경우가 많다. "보다 나은 미래를 위하여"

옛날에 우리말 바로 쓰기 운동하던 분들이 저건 잘못됐다고 번역투와 더불어서 왕창 지적했었다.
나도 굳이 '더'가 멀쩡히 있는데 '보다'를 일부러 바꿔서 쓸 필요는 느끼지 않기 때문에 자제하고 지낸다.
대문자 And가 한국어로 치면 저런 느낌이 들지 않을까 생각이 문득 든다.

한편, 뉴스 앵커 멘트에서 종종 쓰이듯이 "김 씨는 그러나 사실을 부인했습니다"처럼 접속부사가 문장 맨 앞이 아니라 주어와 도치(?)되는 것도 문법에 어긋난다고 얘기가 많다.
나 역시 어감상 어색해서 개인적으로는 저렇게 안 쓴다. 하지만 저걸 비문으로까지 간주하는 건.. 좀 문법 나치스러운 발상 같다. 영어로도 Mr Kim, however, denied the fact 처럼 콤마와 함께 접속부사를 중간에 잘만 집어넣는걸...

3. 동작상(動作相)

언어에는 제각기 동작상에 대한 관점의 차이가 있어서 한국어로는 ‘죽었다’ 하나뿐이지만 영어로는 you died와 you are dead가 더 세분화돼 있다. (그리고 보통 전자보다는 후자로 번역되는 일이 더 많음)

‘죽다/죽었다’뿐만 아니라 한국어의 용언 중에는 ‘맞다’처럼 동사인지 형용사인지 굉장히 헷갈리고 동사 과거 시제가 사실상 현재 시제의 형용사처럼 돼 버린 물건이 좀 있다.
‘미치다’, ‘틀리다’도 생각해 보자. You are crazy/wrong이 “너 미쳤다/틀렸다”이지 않은가? “미친다/틀린다”는 동작상이 꼬여서 용례가 겉돌고 있으며, 그 와중에 ‘틀리다’는 ‘다르다’의 영역을 야금야금 침범하는 중이다. 총체적인 무질서인 것 같다.

여담이지만 영어 have는 동명사 내지 현재진행형인 having이 존재한다. 하지만 단순히 ‘가지다, 소유하다, 내게 있다’라는 1차 의미일 때는 현재진행형 시제를 사용할 수 없다는 독특한 규칙을 초등학교 영어 수준에서 배우게 된다. have가 현재진행형인 것은 좋은 시간을 보낸다거나 경험하는 등, 2차 파생 의미일 때에만 가능하다.

이런 것도 동작상의 차이로 인해 발생하는 용례 차이라고 볼 수 있다. 그리고 원래 원칙은 저렇지만 관계대명사 앞에서는 "~를 가진"이라는 뜻으로도 is having에서 is가 생략된 꼴이 잘만 쓰인다.;;;.

4. 맞춤법과 띄어쓰기의 난해함

  • -ㄹ수록: 의존명사 '수'(할 수 있다)를 떠올려서 그런지 '그럴 수록'처럼 띄어 쓰는 경우가 주변에서 많이 보인다. '-수록'은 뭐 다른 형태로 활용되는 게 전무하며 그 자체로 연결어미로 분류된다. 그러므로 붙이는 게 맞다. '그럴수록'
  • -ㄹ지: 역시 어미인데.. 문제는 얘는 좀 명사화 접사처럼 쓰이는 경우가 많다는 것이다(할지 말지를 결정한다, 할지 말지가 문제이다). 그래서 사람들이 역시 '지'를 의존명사처럼 인지하고 띄어 쓰려는 경향이 있다. 진짜 의존명사인 '줄'도 같이 떠올리는 것 같다. (너 그럴 줄은 몰랐다)
  • -ㄹ까 봐: 얘는 '할까 보다'라고 분할이 가능하기 때문에 '봐' 앞을 띄운다. "네가 사고라도 당할까 봐 두려웠다" 그래도 다른 띄어쓰기에 비해서는 중요성이 상대적으로 덜한 띄어쓰기에 가깝다.
  • - 왜냐하면: 단독으로 부사이다. '왜냐 하면'이라고 띄울 필요가 없다.
  • - 못하다: "저는 그 일을 못 합니다" / "그렇게 되지는 못합니다"
    '못'은 부사이고 '못하다'는 동사, 형용사, 보조용언이 다 되는 정신나간(?) 단어이다.

영어 정서법에 비해 우리말의 한글 맞춤법이 더럽게 복잡하고 띄어쓰기가 어려운 건 모든 사람들이 공감하는 현실이다. 왜 그럴까? 이를 원론적으로 따져보면 이렇다.

일단 (1-1) 한국어가 언어 구조적으로 어미 접사가 어간 뒤에 덕지덕지 복잡하게 붙는 걸 좋아하는 교착어이고 애매한 품사통용어가 많기 때문이다.
이 한 글자짜리 형태소를 접사나 어근이라고 보면 붙이고, 고유한 부사나 명사라고 보면 띄운다. 그런데 그 기준과 경계가 엿장수 마음대로가 되기 십상이다..;;.

가령, 본인은 내 개인 블로그 한정으로 성과 이름도 띄어 쓰고 어지간한 사람들보다 띄어쓰기를 더 하면 더 하지 결코 덜 하지는 않지만.. '전세계'에서 '전'과 '세계'를 띄어야 하는 건 개인적으로 좀 납득이 안 된다. 全 정도면 그냥 접두사로 보거나, 쟤만이라도 거의 한 단어로 굳은 것을 인정할 필요가 있지 않을까?

(1-2) 게다가 띄어쓰기 말고 사이시옷도 말이다. 왜 '물고기'는 '꼬기'이고 '불고기'는 '고기'인가,
'볶음밥'은 '밥'이고 '비빔밥'은 '빱'인가,
그럼 '김밥'은 밥인가 빱인가 이런 거는.. 정말 랜덤이고 개연성이 없다. 규칙을 찾을 수 없다. 한국어가 원래 그런 언어다.

그리고 (2-1) 문자 차원에서는 역설적으로 모아쓰기 때문이다.
글자가 단독으로도 적당히 음절 경계 변별이 뛰어나기 때문에 어느 정도는 띄어쓰기를 안 해도 알아보는 데 지장이 없다. 그런데 그렇다고 띄어쓰기를 전혀 안 할 수는 없다.
그러니 한 단어로 붙여 쓰는 예외를 정하는 게 난감하고 띄어쓰기 규칙이 복잡해지는 것이다.

(2-2) 사이시옷은 말부터가 제멋대로인데 그건 음절 단위로 딱딱 떨어지지 않는 초분별 요소에 속하며 한글이라는 체계 하에서 표현하기가 몹시 난감하다. 사이시옷 규정이 캐 더럽고 구린 이유가 이 때문이다. 한자어의 경우 "숫자 횟수 곳간" 등의 몇 개만 예외로 인정하고 나머지는 그냥 표기하지 않기로 정해 버렸다.

알파벳 같은 풀어쓰기형 문자를 썼으면 띄어쓰기는 약간이나마 더 쉬워졌을 수 있다. 체언과 조사도 띄우고 좀 헷갈린다 싶은 건 몽땅 띄우고, 좀 아쉬운 건 하이픈으로 연결하고.. 사이시옷이나 축약은 ' 점 하나 찍어서 해결해 버리면 된다.

다시 말해 모아쓴 한글의 덩어리 단위가 '초분절적 변별요소'까지 포함한 한국어의 형태소· 음운 단위보다 크기 때문에 이 모든 문제가 발생하는 것이다. 한글의 큰 장점인 동시에 그로 인해 얻는 부작용인 셈인데, 쉽지 않은 문제이다.

여담이지만, 영어권에서는 심지어 숫자와 단위 사이도 꼬박꼬박 띄운다. 100MB, 50kg라고 안 하고, 우리로서는 어색하게 느껴지겠지만 100 MB, 50 kg라고 쓴다는 것이다.
숫자와 알파벳 이렇게 문자의 종류가 달라지기 때문에 붙여도 전혀 모호하지 않을 것 같은데, 이는 단어와 띄어쓰기에 대한 인식이 서양 언어 문화권과 동양의 그것이 서로 다르기 때문이다.

Posted by 사무엘

2020/12/08 08:35 2020/12/08 08:35
, ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1828

오늘날처럼 컴퓨터의 문자 인코딩이 유니코드로 천하통일이 되기 전엔 국내에서는 2바이트 완성형과 조합형 한글 코드 논란이 가라앉지 않고 있었다. 완성형은 94*94 격자 모양의 단순하고 국제 규격에 부합하는(?) 방식으로 인코딩돼 있었지만 한글의 구성 원리를 무시하고 한글을 난도질했다는 비판을 떠안고 있었다.

완성형은 “한글 vs 비한글”을 구분하고 처리하는 데 유리했다.
그에 비해 민간에서는 “한글 글자 vs 낱자”의 처리가 더 용이한 조합형이 훨씬 더 대중적으로 쓰였다. 그도 그럴 것이 640KB 기본 메모리를 1KB라도 더 확보하려고 목숨 걸던 시절, 메모리 모델이 어떻고 far 포인터가 어떻고 이러던 시절에.. 한글 처리를 위해서 2350자 테이블을 내장하고 다닌다는 건 성능과 효율로나 민족 정서(?)로나 도저히 용납할 수 없었기 때문이다.

허나, 명목상 국가 표준은 완성형이었기 때문에 마소 역시 도스와 Windows의 한글판을 전적으로 완성형 기반으로 만들었다. 완성형은 두벌식과 마찬가지로 그 시절에 소프트웨의 한글판을 필요 이상으로 더 무겁게 만든다는 비판을 피하기 어려웠다. 다만, 이건 애초에 우리나라에서 표준을 이상하게 만든 게 잘못이지 마소의 잘못은 아닐 것이다.

Windows 3.1이야 이런 배경에서 만들어졌기 때문에 한글 IME로 똠, 펲 같은 글자가 입력되지 않았으며, 또ㅁ, 페ㅍ이라고 글자가 풀어졌다. ‘썅’은 2350자에 속해 있는데 중간의 ‘쌰’는 그렇지 않기 때문에 ‘썅’까지 덩달아 입력할 수 없는 것은 유명한 사실이다.

그리고 처음부터 ‘쌰’를 입력하면 ‘ㅆㅑ’라고 잘 갈라지는데, 두벌식에서 ‘있’ 다음에 ㅑ를 입력하면 ‘이ㅆㅑ’가  되지 않고 뭔가 올바른 동작이 나오지 않았던 걸로 본인은 기억한다.
이런 것들이 한글 입력기, 특히 특정 문자 입력 제한이 걸린 두벌식 입력 방식을 구현할 때 고려해야 하는 복병이다. 날개셋이야 이 분야 전문이기 때문에 그런 것들도 다 정상적으로 처리해 준다.

그럼 차기 버전인 Windows 95는 상황이 어땠을까?
Windows 95는 오늘날 세계 표준 문자 집합 겸 인코딩인 유니코드, 특히 유니코드 중에서도 버전 2.0이 한창 제정되고 있던 와중에 개발되고 먼저 출시되었다. 이건 굉장히 중요한 사건이었다.

우리나라에서는 수 년 전 유니코드 1.x 시절에는 완성형 2350자만 그대로 제출하는 삽질을 저지른 적이 있었다. 그러다가 유니코드 2.0에서 문자 체계를 싹 재정비하는 인류 역사상 마지막 기회가 찾아왔을 때.. 한글을 11172자 모두 순서대로 등록하려는 과감한, 역사적인 계획을 세웠다. 그래야 글자 코드값으로 자모 정보를 쉽게 추출할 수 있기 때문이다.
이건 스타에다 비유하자면 종족 밸런스를 앞으로 다시는 바꾸지 않는 1.08 패치와 비슷한 타이밍이었다.

그런데 그렇게 하려면 세계를 설득해야 했다.
다른 나라들은(특히 일본과 중국도) BMP 영역의 1/5 가까이를.. 그것도 사용자가 1억도 채 안 되는 언어의 고유 문자로 싹 도배하려는 한국을 고깝게 보고 이의를 제기했다.
유니코드 회의에서 누가 발언권을 얻으려면 한화로 억대에 달하는 회원 등록비도 많이 내야 하는데, 이런 비용을 한컴 같은 기업에서 많이 후원해 줬다. 저 때는 삼성전자도 훈민정음 워드 같은 프로그램이나 간간이 만들었지, 지금 정도로 IT계에 세계구급 영향을 행사하는 기업이 아니었다는 걸 생각해 보자!

이런 우여곡절 끝에 한글 11172자는 1996년 7월, 유니코드 위원회의 승인을 받아서 성공적으로 등재되었다. 이거 내막을 아는 사람이라면 이것도 1981년 서울 올림픽 바덴바덴의 기적에 맞먹는 외교 승리라고 여기고 칭송한다. 올림픽은 52:27의 압승이라도 했지만 11172자 등재는 찬성이 반대를 한 표 차이로 정말 간신히 꺾은 거라고 한다.

그런데 문제는 Windows 95는 유니코드 2.0이 정식으로 발표되기 미묘하게 약간 전에 출시되었다는 것이다. 한글판도 1995년 11월 말에 출시됐으니..;;
그럼에도 불구하고 각종 글꼴과 코드 변환 테이블은 이미 유니코드 2.0을 기준으로 맞춰져 있다. 어떻게 이게 가능했을까?

유니코드 2.0에다가 한글을 2350자가 아니라 11172자를 몽땅 집어넣기 위해서는.. 근거가 필요했다. 유니코드가 아닌 기존 2바이트 인코딩 중에도 한글 11172자 표현이 가능한 놈이 있어야 했다.
그럼 Windows가 처음부터 조합형 코드로 개발됐으면 좋았겠지만 모종의 이유로 인해 그리 되지 못했고.. 결국은 기존 완성형에다가 지저분한 독자적인 편법을 동원해서 비완성형 한글을 끼워넣을 수밖에 없었다.

이게 그 이름도 유명한 확장완성형, 일명 CP949 인코딩이다.
KS X 1001은 한글 2350자, 한자 4888자 등을 포함하는 그 2바이트 완성형 문자 집합/코드이고, KS X 1003은 역슬래시를 원화로 대체한 그 한국 특유의 1바이트 영문/숫자 아스키 문자 집합이다. 이 둘을 합쳐서 EUC-KR이라고 부르고, 여기에다가 확장완성형까지 추가하면 CP949가 된다. 집합 관계를 정리하자면 (KS X 1001 ∪ KS X 1003) = EUC-KR ⊂ CP949이다.

(참고: KS X 1002는 완성형 형태로 현대 한글, 옛한글, 한자를 추가로 정의하는 규격이다. 하지만 KS X 1001과 병용하는 인코딩 규칙이 제정되지 않아서 컴퓨터에서 실제로 쓰인 적은 없는 캐잉여이다. 얘는 애초에 유니코드 1.1에다가 글자를 추가로 등록할 근거를 마련하려고 어거지로 만든 문자 집합에 지나지 않는데, 이제는 유니코드 1.1 자체도 오래 전에 흑역사가 됐으니 더욱 의미와 존재감이 없다.)

이렇듯, 확장완성형이라는 건.. 비록 처음에 첫단추를 잘못 끼우긴 했지만 뒤늦게 유니코드 2.0에라도 한글을 11172자를 순서대로 다 집어넣기 위해서 도입한 2바이트용 타협 절충안이었다. 마소에서는 한국 편을 들면서 도와 주면 도와 줬지, 최소한 상황을 더 나쁘게 만든 건 절대 없었다.

그럼에도 불구하고 1990년대 당시에는 마소에서 완성형에다가 그보다 더한 확장완성형까지 집어넣어서 한글을 난도질한다고 엄청난 논란이 일었다. 심지어 한컴에서도 아래아한글 도움말 및 제품 광고에서 이 괴담을 어느 정도 활용하고 부추겼다.

왜 한글을 난도질 하느냐 하면, 확장완성형은 이미 2350가 조밀하게 순서대로 배치된 건 그대로 유지하면서 나머지 틈새에다가 비완성형 8822자를 집어넣는 형태가 되기 때문이다. 그러면 겉보기로는 11172자가 모두 배당되지만 문자의 코드값 순서가 그 문자의 사전상의 배열 순서와 일치하지 않게 된다. 사전 순 정렬을 하려면 코드값을 별도로 보정을 해야 한다.

물론 코드값만으로 문자를 정렬할 수 있는 게 가능하지 않은 것보다는 더 직관적이고 깔끔하고 낫다. 하지만 오늘날 유니코드는 시간 차를 두고 뜬금없이 여기저기 지저분하게 추가된 문자들이 워낙 많기 때문에(특히 한자~!!), 거시적으로 봤을 때 코드값만으로 문자들을 정렬하는 건 어차피 불가능하고 무의미해져 있다.

뭐, 이것도 논란이 다 끝난 오늘날의 관점에서 보니까 별것 아닌 것처럼 보이지, 2바이트 한글 코드만 단독으로 생각하던 시절에 확장완성형이 답답하고 지저분하게 보이는 것도 부인할 수 없어 보인다.
그리고 마소는 훗날 IMF 때 경영난에 빠진 한컴에다가 돈줄을 대 주는 대신 아래아한글의 개발을 중단시키려 했던 바 있다. 그러니 확장완성형에 대한 불필요한 오해 실드를 감안하더라도 마소에 대한 국민 감정이 마냥 좋을 수만은 없었을 것이다.

아무튼, 그 시절 Windows 95는 유니코드 2.0의 정식 도입을 선도하면서 온전한 한글 11172자의 입출력이 가능해지려는 과도기에 연결 고리 역할을 했다.
참고로 95 말고 Windows NT는 도스 짬뽕이던 기존 Windows와 달리, 1993년 첫 버전부터 2바이트 wide char 유니코드 기반이었다. 얘도 유니코드 2.0이 정착할 무렵이 돼서야 본격적으로 정식 한글판이 나올 수 있었다. 3.51부터 말이다.

사용자 삽입 이미지

Windows NT 3.5 한글판의 ‘베타 버전’ 평가판. 이건 Windows NT의 역사상 최초로 만들어진 한글판으로, 정말 엄청난 희귀 레어템이다. 마치 Windows 2.x의 듣보잡 한글판처럼 말이다.

저 화면에서 한글 글꼴은 기존 Windows 3.1의 돋움체(큐닉스 제작) 8포인트이다. 하지만 영문은 정체를 모르겠다. W와 i의 폭이 다른 가변폭인 걸 보니 같은 돋움체의 영문은 아닌데, Arial은 물론이고 심지어 후대에 등장한 Tahoma나 Verdana까지 그 어떤 영문 글꼴도 저 크기에서 9나 5의 획이 저렇게 생기지 않았다.

그런데 저 영문 모양이 내가 보기에 전혀 낯설지는 않다.
마소에서 개발한 1990년대 옛날 프로그램의 스플래시 화면 내지 About 대화상자에서 Copyright 문구가 저런 스타일의 글꼴로 표시된 걸 본 것 같기도 한데.. 정확한 정체는 모르겠다.

내 기억이 맞다면 Windows NT 3.51의 정식 한글판은 3.51의 특성상 Windows 3.1과 같은 구형 UI 기반임에도 불구하고 한글 글꼴은 이미 Windows 95 한글판과 동일한 한양 시스템 글꼴로 갈아탔다.
Windows NT의 역사에서 유니코드 1.1 방식 한글이 존재했던 적은 내가 아는 한 없다. 만에 하나 있다면 그건 조합형 코드를 잠깐 썼었다고 전해지는 MS-DOS의 초창기 한글판만큼이나 완전 전설 속에나 존재하지 싶다.

이렇게 95건 NT건 온전한 11172자짜리 유니코드 2.0 기반임에도 불구하고.. 95의 한글 IME를 써 보면.. 구버전인 Windows 3.1과 마찬가지로 여전히 2350자밖에 입력할 수 없었다. 다만, “있+ㅑ”일 때는 ㅆ이 뒷글자로 넘어가지 않도록 로직이 약간 개선돼 있었다.;; ㅎㅎ

사실, Windows 95의 한글 IME는 확장완성형을 기반으로 11172자를 모두 입력하는 기능도 구현은 돼 있었다. 하지만 그걸 기본적으로는 봉인해 놓았으며, 사용 여부를 별도의 유틸리티를 통해 따로 지정할 수 있었다!
바로, C:\Windows 디렉터리에 있는 iso10646.exe라는 30KB짜리 자그마한 프로그램이다. 역시 괜히 과도기였던 게 아니다.

사용자 삽입 이미지

프로그램 UI에는 유니코드니 완성형이니 같은 말은 없고 그냥 "ISO 10646 사용 여부"가 전부였다. 유니코드의 문자 집합을 가리키는 표준 규격 명칭이 ISO 10646이기 때문이다.
전체 사용 아니면 특정 프로그램에서만 사용.. 이런 걸 지정해 주면 타 프로그램에서 똠쌰 등등의 글자를 입력할 수 있었다.

신기한 것은 Windows용 프로그램뿐만 아니라 도스용 mshbios의 한글 입력기까지 이 설정의 영향을 받았다는 것이다. 설정값을 레지스트리가 아니라 파일에다 저장했던가 보다. 아니면 도스에서도 레지스트리 파일에 저수준으로 접근을 했던지..

확장 한자의 사용 여부를 옵션으로 지정하는 것처럼 2350/11172자 입력 범위도 그냥 IME의 옵션으로 지정하면 됐을 것 같은데 굳이 별도로.. 제대로 문서화되지도 않은 프로그램에다 저렇게 꽁꽁 숨겨 놨다.
부작용을 어지간히도 의식했는지 각종 프로그램별로 입력 범위를 달리 지정할 수 있게 신경을 썼다. 즉, 여느 평범한 IME 옵션이 아니라.. 날개셋으로 치면 응용 프로그램별 동작 보정 옵션과 비슷한 걸로 취급한 것이다.

훗날 MS Office 97이 나왔고.. 그 중 Word는 단품으로 따로 팔기도 했다.
마소 역시 한컴 진영의 조합형 한글 마케팅을 많이 의식했는지, 신문 광고에서 조그맣게.. "우리 마소 제품에서도 똠방각하 펩시콜라 찦차를 입력할 수 있습니다." 문구와 함께, iso10646 프로그램 사용법을 소개해 놓기도 했었다.

본인은 학창 시절에 그 광고를 직접 본 기억이 있다.
지금도 구글에서 iso10646.exe 라고 검색해 보면 옛날 흔적을 찾아볼 수 있다.

마소의 전략은.. 요런 프로그램을 몰래 집어넣은 뒤, 확장완성형이 계속 부정적인 피드백을 받으면 Windows 95는 그딴 거 지원한 적 없다고 발뺌 하면서 2350자 기존 완성형에만 머무르면 될 것이고,
한글을 2350자밖에 입력 못 한다고 욕먹는 게 더 크면, 저 비장의 프로그램을 음지에서 양지로 끄집어내려는 속셈이었던 것 같다. 쉽게 말해 간보기 전략이다.

그러다가 Windows 98부터는 이런 간보기가 없어지고 그냥 모든 프로그램에서 확장완성형까지 활용한 11172자 한글 입력이 되기 시작한 것이다. 나중에 Office 2000과 함께 옛한글 입력기가 도입됐을 때는 이제 마소의 제품이 옛한글의 표현 능력도 아래아한글 97과 한컴 2바이트 코드를 추월하게 됐다.

이상이다. “라떼는 말이야” 같은 얘기가 좀 길어졌다.. ^^
25년 전, Windows 3.1에서 95로 넘어간 것은 정말 엄청난 격변이었다. 하지만 Windows 95와 98 사이에도 컴퓨터 환경은 굉장히 많이 바뀌었다.
가정용 PC의 평균 램 용량이 4~16MB대이던 것이 그 짧은 기간 동안 32~128MB로 순식간에 뻥튀기 됐다. PC 규격도 이것저것 많이 바뀌고.. 또 무엇보다도 이 사이에 유니코드 2.0이 제정되었다. 운영체제 차원에서 UTF-8 인코딩이 직접 지원되기 시작한 최초의 Windows가 바로 98이다.

Windows에서 완성형 2350자에 구애받지 않고 한글 입력이 가능해지기까지 이런 우여곡절이 있었다.
Windows 98은 현대 한글이 완전히 해금됐고, 지난 Windows 8 (2012)부터는 옛한글까지 해금됐으니 참 격세지감이다. 그 사이의 XP는 입력 프로토콜이 IME에서 TSF로 넘어간 과도기였고 말이다.

그런데 정작 옛한글 말뭉치를 엄청나게 많이 구축한 21세기 세종 계획은 이것보다 미묘하게 일찍 진행된 바람에 비표준 한양PUA 방식으로 결과물을 산출해 버렸으니 타이밍이 안습했던 구석이 있다.

Posted by 사무엘

2020/11/09 08:35 2020/11/09 08:35
, , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1817

한글을 입력할 때 ㄷ, ㅂ, ㅈ 같은 자음을 연타해서 각각 ㄸ, ㅃ, ㅉ을 만드는 건 명백하게 초성 문맥에서 행해지는 일이다. ㄸㅃㅉ은 종성에 쓰이지 않기 때문이다(현대 한글 기준). 그리고 ㄲ과 ㅆ은 비록 종성에서도 쓰이긴 하지만 얘도 가능한 한 초성 문맥에서 처리하는 게 동작의 일관성 차원에서 더 좋다.

이들과는 반대로 ㄱ+ㅅ으로 ㄳ, ㄹ+ㅁ으로 ㄻ 등을 입력하는 건 종성 문맥이다.
세벌식은 초성 글쇠와 종성 글쇠가 물리적으로 서로 다르기 때문에 초성의 결합이 가능한 상황과 종성의 결합이 가능한 상황이 아주 명확하게 구분된다. 하지만 두벌식은 어떻게 구현하느냐에 따라 초성과 종성을 뭉뚱그린 자음의 결합 가능 여부가 달라진다.

세벌식 구현하듯이 두벌식을 구현한 프로그램(아래아한글, macOS, 날개셋 기본 설정)이라면 초성 입력 문맥에서는 ㄸㅃㅉ의 결합만 가능하다. 그리고 두벌식 기반 옛한글 입력 환경이라면 역시 무조건 이런 식으로 동작하게 된다.

한편, 마소 한글 IME는 초성 쌍자음의 연타 결합을 지원하지 않고 ㄳㄶㄻ 같은 겹받침을 단독으로 입력할 수 있다. 초성까지도 언제나 종성 문맥에서만 동작하기 때문이다. 이 개념은 날개셋 한글 입력기도 오래 전 6.X 후반 버전에서 두벌식 종성이라는 개념으로 뒤늦게 수용한 바 있다.

그런데 문제는.. 초성의 결합과 종성의 결합을 모두 지원하는 프로그램도 있다는 것이다.
초성과 종성의 구분이 없는 두벌식에서 ㅂ+ㅂ는 ㅃ, ㅂ+ㅅ는 ㅄ가 되면서 그 상태로 ㅏ를 누르면 각각 ‘빠’와 ‘ㅂ사’(ㅄㅏ가 아님!)가 된다.
내가 아는 프로그램으로는 새나루, 그리고 먼 옛날(2003년..)에 남북 합작으로 개발됐던 Unicode CJK IME도 이 범주에 든다.

사용자 삽입 이미지

이 동작을 날개셋으로 구현하는 건 가능할까?
결론부터 말하자면 가능은 하다.
하지만 이건 날개셋 한글 입력기의 내부 구조라는 관점에서 보면 초성 문맥이 갑자기 종성으로 널뛰기 하듯이 바뀌는 굉장히 예외적이고 변칙적인 동작이다. 그래서 평소에 잘 쓰이지 않는 설정을 많이 바꿔 줘야 한다. 이 글에서는 날개셋에서 “ㅃ빠”와 “ㅄㅂ사”의 입력이 모두 가능한 두벌식 입력 설정을 만드는 걸 실습해 보겠다.

먼저, “기본 글자판 설정” 빠른설정을 이용해서 종성 지향이 아닌 일반적인 두벌식 입력 설정을 세팅한다. 자음 처리 방식을 “성분별로 따로”로 지정하고, 쌍자음의 연타 입력은 “모두 허용”을 지정하도록 한다.

그 다음으로 우리가 할 일은 (1) 초성 문맥에서 ㄴ 다음에 ㅈ, ㅂ 다음에 ㅅ 따위가 입력됐을 때 조합 중인 글자를 초성이 아닌 종성으로 한꺼번에 바꾸는 것이다. 이건 글쇠배열 수식이 담당해야 한다. ㅅ의 경우, 수식은..

T<=1 ? D==1 ? H2|_GS|0xFFFA : D==36 ? H2|_RS|0xFFFA : D==86 ? H2|_BS|0xFFFA : H2|S_ : H2|_S

으로 가장 복잡하다. 원래 ㅅ만 초성 또는 종성 형태로 곱게 입력하는 T<=1 ? H2|S_ : H2|_S 라는 수식에서 초성 문맥에 대해

T<=1 ? {블라블라블라 ? XXXXX :} H2|S_ : H2|_S

이라는 항이 길게 추가된 것이다. ㅅ을 입력하는 자리에서는 ㄳ, ㄽ, ㅄ을 담당해야 해서 수식이 가장 길다.
입력된 글쇠의 초중종성 값은 A~C에 들어있고 현재 조합 중인 글자의 초중종성 값은 D~F에 들어있다. D의 값 1은 ㄱ을 나타내고 36은 ㄹ, 86은 ㅂ을 의미한다.

그때의 리턴값은 H2|_GS|0xFFFA 이런 꼴인데.. H2는 이 글자가 다음에 중성이 이어졌을 때 도깨비불 현상을 일으키고 초성 문맥으로 넘어가는 두벌식 한글임을 뜻한다. 그리고 밑줄로 시작하는 GS, RS, BS 같은 명칭은 종성을 뜻한다.
0xFFFA는.. 해당 성분, 여기서는 초성을 무조건 0으로 바꿔서 없애는 특수 낱자이다. 그래서 초성 ㄱ 다음에 이런 부류의 수식이 입력되면 종성 ㄳ으로 바뀔 수 있다.

이런 식의 변형을 ㄱ(ㄺ), ㅎ(ㄶㅀ), ㅁ(ㄻ), ㅂ(ㄼ), ㅈ(ㄵ), ㅌㅍ(ㄾㄿ)에 모두 해 줘야 한다. 가령, ㅈ 자리는 다음과 같다.

T<=1 ? D==12 ? H2|_NJ|0xFFFA : H2|J_ : H2|_J

이렇게 해 주면 날개셋에서도 초성 ㄴ 다음에 ㅈ을 입력했을 때 글자가 갑자기 종성 ㄵ으로 바뀌는 걸 볼 수 있다.
하지만 이 상태로 중성을 입력해도 ‘ㄴ자’가 되지는 않으며 중성이 지금 조합 중인 글자에 접수된다.

이걸 보정하려면 먼저 (2) 오토마타를 수정해 줘야 한다.
초성을 없애는 0xFFFA도 오토마타의 관점에서는 nonzero, nontrivial인 초성이다. 그렇기 때문에 초성 첫 타가 입력된 뒤인 1번 상태의 수식 A ? 1 : B ? 2 : C ? 3 : 0을..
A&&A<=255 ? 1 : B ? 2 : C ? 3 : 0

정도로 수정해 줘야 한다. 그래야 초성 입력만으로 ㄳㄵㄻ 등이 입력됐을 때, 오토마타의 상태가 종성인 3번으로 바뀌며 다음 중성이 현재 글자가 아닌 다음 글자로 가게 된다.

그리고 마지막으로.. (3) 특수 도깨비불 규칙을 수정해야 한다. (제어판의 ‘낱자 처리’ 탭)
이렇게 초성에서 종성으로 인위적으로 강제로 바뀐 겹받침은 한글 입력기의 관점에서는 입력 과정에서의 개연성이 파악되어 있지 않다. 즉, ㄳ을 ㄱ+ㅅ으로 분할해야 한다는 것을 알지 못하기 때문에 도깨비불 현상이 발생하더라도 ㄳ을 통째로 뒷글자 초성으로 보내 버린다. 이는 올바른 결과가 아니다.

그렇기 때문에 현대 한글 겹받침에 대한 규칙이 등록되어 있어야 하는데.. 이건 내정값을 살펴보면 ‘현대 겹받침’이라고 ㄳ부터 ㅄ까지 11개가 이미 등록된 게 있다. 그걸 불러오면 된다. 겹받침을 원래대로 종성 문맥에서만 입력한다면 기재할 필요가 없는데 초성 문맥에서의 입력 때문에 필요해진 것일 뿐이다.

이런 작업을 해 주면 날개셋에서도 두벌식의 초기 상태에서 초성 ㄲ와 종성 ㄳ을 동시에 처리할 수 있다.
왠지 좀 비효율적이고 삽질스러워 보이지만.. 날개셋의 현 체계에서는 이보다 더 깔끔하게 동일 동작을 구현할 방법은 존재하지 않는다. 초성이 갑자기 그렇게 종성으로 널뛰기로 바뀌어야 할 논리적인 근거가 없기 때문이다.

한글 입력기 중에는 두벌식과 세벌식, 그리고 현대 한글과 옛한글의 입력 로직이 프로그램 코드 차원에서 완전히 분리되어 있는 편이다. 마소 IME는 그럴 거라고 추정되며, 오픈소스인 libhangul도 그러하다. 그래서 초성에서의 종성 겹받침 결합이 두벌식 현대 한글을 위한 별도의 로직으로 구현돼 있다.

하지만 날개셋의 경우 두벌식이건 세벌식이건 모두 범용적인 동일 로직으로 처리되고, 초중종 성분별로 낱자 결합 규칙이 존재할 뿐이다. 그렇기 때문에 초성을 종성으로 갑자기 바꾸는 건 선뜻 수용 가능한 동작이 아니다.
뭐, 굳이 넣자면 초성만을 위해 0xFFF? 같은 특수한 의미를 갖는 코드값을 추가할 수는 있다. 하지만 내 프로그램에 그런 걸 넣지는 않을 것이고 그냥 이렇게 우회해서 동일 동작을 구현 '가능'하다는 것만으로 놔둘 생각이다.

이런 두벌식에 비해 세벌식은 도깨비불 현상 없고 한글의 모아쓰기 구조와 직관적으로 대응하기 때문에 입력 방식으로서 처리하기가 얼마나 편한지를 알 수 있다.
물론 초성과 종성에 같은 자음을 사용한다는 점 때문에 두벌식 사고방식이 편한 것도 있다. 하지만 현실에서는 초중종성을 한데 모은다는 특성을 살리는 게 더 편리하다.

Posted by 사무엘

2020/10/15 08:36 2020/10/15 08:36
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1808

북한은 정치 분야에서 언어 구사가 좀 과격한 구석이 있을지언정, 우리 남한만치 한자어나 외래어를 막 남발하지 않고 순화를 많이 한다고 그런다. 하지만 그렇다고 진짜로 아이스크림 대신 얼음보숭이 같은 오글거리는 말까지 적극 사용할 정도는 아니라는 탈북자의 증언도 있다.

이런 와중에 남한 같았으면 그냥 '정지'라고 할 것을 북한의 도로 표지판은 진짜 단순무식하게 '섯!'이라고 적혀 있다고 한다. 언어학적 의미 전달이야 이보다 더 명확할 수 없고 문제가 전혀 없지만, 그럼에도 불구하고 뭔가 격식이 안 어울리다 보니 우리 같은 사람들은 빵터지게 된다.

사용자 삽입 이미지

출처를 알 수 없는 이 흐릿한 사진이 제일 유명하지만, 구글링을 해 보면 이것 말고 다른 장소에서도 곳곳에 '섯/섯!'이라고 적힌 북한 표지판이 많이 나온다. 교차 검증이 되는 셈이므로 이 자료는 신빙성이 있다.

그런데 북한에 '섯!' 표지판이 있다면, 옛날에 남한에는 주차 대신 '둠'이라는 표지판이 있었다고 한다. 당연히 Doom 게임이 아니라-_-;; '(세워) 두다'의 명사형이다.
본인도 지금까지 '그랬다 카더라'라고 소문만 들었는데 그 표지판의 실제 모습을 우연히 발견했다. 다음은 1970~80년대의 어느 대한뉴스에서 교통 질서 캠페인이 나오던 화면을 캡처한 것이다.

사용자 삽입 이미지

사용자 삽입 이미지

둠. 참 강렬하지 않은가..??? =_=;;
이런 말이 잠시나마 만들어져 쓰인 배경에는 국어학자 최 현배 박사가 있었다. 이분이 한국어에서 '-음/ㅁ' 명사화 접미사를 굉장히 좋아했던 분이기 때문이다. 저서를 '지음'으로, 생활을 '살음'이라고 표현했을 정도로.

내가 지금까지 관련 자료를 소개한 적이 없었구나. 그분의 저서..라기보다는 유고작인 <한글만 쓰기의 주장>의 한 부분을 인용하고자 한다. 원작의 맞춤법과 띄어쓰기, 외래어 표기를 그대로 옮겨 썼다.

한국 국어 교육 학회의 주최로 1968년 12월 8일은 은석 국민 학교에서 열린 강연회 연사로 초빙되어 우리 나라에 온, 일본 경도 대학 언어학 교수 이스이 히사노스께(泉井久之助) 박사는 "意味와 文法"이란 제목의 강연에서 다음과 같은 요지를 말하였다:

한국말은 움직씨의 끝에 뒷가지 "음"을 붙여서 이름씨로 만드는 편리한 말본이 있다. 이 말본을 활용하면 개념의 혼란없이 한자말을 모두 한글로 풀어쓸 수 있다. 한글은 한자의 음을 빌릴 필요없이, 새로운 말을 구성해 낼 수 있다.

일본말은 움직씨에 뒷가지를 붙여서 이름씨로 만드는 말본이 없기 때문에, 한자와의 인연을 결코 끊을 수 없다. 이런 점에서 한국 말본은 일본 말본보다 우수하여, 한자와의 전면적 결별이 용이하다. 이점에 대해서는 일본인이 부러워해야 할 바이다. 정거장의 개설구를 "나가는 곳", 집찰구를 "나오는 곳" "分離"를 "나눔", "誕生"을 "낳음" 들로 쉽사리 새 이름씨로 풀어 쓸 수 있기 때문에, 한자 전폐는 더욱 용이하다. 고.

이스이 교수는 학술회의 회원이기도 하고, 많은 언어학 저서도 있는 일본 유수한 노 언어학자인데, 강연 뒤 신문 기자와의 회견에서 다음과 같이, 한글 연구의 방향도 제시하였다.

"음"을 붙여서 움직이름씨(동명사, Gerund)를 만들고, 이를 사색의 대상으로 한다면, 의미의 세계가 넓어져서, 한국인의 정신 활동이 크게 발달될 것이다. 이런 의미에서 한국의 언어학은 지금 있는 말을 분석 정리하는 데에 그치지 말고, 한글의 조어력을 발달시키고, 한글의 저력(속힘)을 발굴해 내는 방향으로 나가야 한다고.

그리고 그는, 최근 한국 정부가 취한 한글 전용화 계획은 한국의 사회적인 편리를 위해서나, 한국만의 독특한 문화발전을 위해 잘한 일이라고, 덧붙여 말하였다.
참 고맙고도 존경할만한 말씀이다. 일본인인 언어학 박사 교오또 대학 노교수가 학자적 양심 그대로 배달말본의 우수성, 조어력의 풍부함에 대한 학적 소견을 솔직히 베풀어서, 자비자굴(自卑自屈)에 빠진 우리 학계에 큰 각성과 격려를 주었으니, 이것이 참 고맙지 아니한가?


지금이야 민족이나 인종, 심지어 언어를 서로 대놓고 비교하면서 어느 게 우수하네 마네 하는 소리는 그야말로 히틀러스러운 나치즘, 파시즘, 국뽕 전체주의 소리 들으면서 욕 먹기 딱 좋다. 더구나 난 일본어를 전혀 모르기 때문에 동명사를 만드는 게 한국어보다 뭐가 그렇게 불편한지 저 말의 배경도 잘 모르겠다. 뭐, 일본인 학자가 거짓말을 하지는 않았겠지..

하지만 저 때가 어떤 시절이었는가? 최 현배 박사는 1970년에 세상을 떠났으니 지금으로부터 무려 반세기 전의 옛날 사람이다.
1968년 12월 8월이면 뭐 떠오르는 거 없으신가? 박 정희 대통령에 의해 국민 교육 헌장이 선포된 지 겨우 사흘 뒤의 일이다(12월 5일). 그야말로 어마어마한 옛날이 아닐 수 없다.

저 때는 언어건 문화건 경제건 "우린 안 될 거야 아마"라고 아무 꿈도 희망도 없던 시궁창 헬조선 반도에서 국민들에게 "우리는 우수한 민족이다, 우리(는/도) 할 수 있다"라고 정치인 지식인들 할 것 없이 무지한 국민들에게 마음껏 국뽕이라는 동기 부여를 주입해 줘야 했다. 그러던 와중에 한글은 가히 이보다 더 훌륭할 수 없는 약이었던 것이다. 그래서인지 저 글을 보면 알 만한 거물급 국어학자임에도 불구하고 '한국어'를 쓸 만한 문맥에서까지 문자인 '한글'이 엄밀한 구분 없이 종종 섞여 쓰여 있다.

최 현배는 당대를 살았던 공 병우· 이 승만 같은 인물과 비슷한 급의 천재이고, "방망이 깎던 노인"을 연상케 할 정도로 아주 강직하고 괴팍한 고집쟁이였다. 194~50년대엔 단순히 한자를 없애는 수준을 넘어서 문자를 기계화하지 못하면 민족이 망할 거라고까지 생각해서 <글자의 혁명> 같은 굉장히 과격한 책도 쓴 적이 있다. (한글을 라틴 알파벳 같은 풀어쓰기 문자로 마개조하자)

그리고 일본인 스승 밑에서 언어학을 공부했고 언어학뿐만 아니라 교육학과 철학에도 일가견이 있었지만, 한편으로 조선어 학회 사건 때 투옥되어 고초를 겪고 죽을 뻔하기까지 했다. 그렇기 때문에 그는 일본의 일 짜만 나와도 몸서리 쳤던 골수 민족주의자 항일 인사였다. 미국의 조지 부시 대통령(아들 말고 아버지)이 개인 소신으로는 평생 일본을 싫어하며 지냈듯이 말이다(군 복무 시절에 동료들이 미친 식인귀 일본군에게 잡아먹혔으며, 자기도 극적으로 구조되지 못했으면 그렇게 될 뻔..).

이런 최 현배 박사의 주장에 대해서 날틀, 배꽃계집큰배움터 같은 이상한 오해와 음해가 나돌았다. 하지만 그가 실제로 장려했던 순우리말 용어는 말본, 셈본, 넘보랏살, 콩팥 이런 온건한 선을 넘지 않았으며, 그리고 저런 '둠'이야말로 주작이 아닌 팩트이다. 최 박사의 저서를 보면 '둠'이 제안된 배경을 더 잘 이해할 수 있을 것이다. 순화라는 게 명사를 억지로 뭉쳐 붙이는 것만이 전부가 아니다.

본인이 생각하기에도, 동사를 명사화해서 표현할 때 영한사전 번역투 영향을 받아서 천편일률적으로 '-는 것'만 쓸 게 아니라, '-음/ㅁ', '-기' 같은 접미사도 많이 활용하는 것이 표현의 다양성 차원에서 좋다고 여겨진다. 뭐, 전에도 얘기했듯이 영어는 근본적으로 명사와 형용사를 좋아하는 반면, 한국어는 동사(용언)와 부사를 좋아하는 언어라는 차이가 있기도 하다.

도시락, 동아리, 모꼬지 이런 말은 최 현배의 사후에 그의 학풍을 물려받은 대학생 우리말 사랑 단체에서 1980년대쯤에 만들거나 재발견하여 보급되었다. 특히 동아리가 '서클'을 성공적으로 대체한 것은 매우 이례적인 현상이다.
이거 이후로 국내에서 순우리말 순화 운동은 1990년대에 컴퓨터 분야를 중심으로 무른모, 셈틀, 누리그물(...;; ) 이런 거나 나오다가 지금은 완전히 생명력을 잃고 자취를 감춘 것 같다.

이상. '둠, 섯'에서 시작해서 오랜만에 한글, 국어, 최 현배 박사 등 여러 얘기가 나왔다. 나의 모국어인 한국어의 문법과 어휘를 어떻게 활용하고 개량하면 이 영어 만능 시대에 더 간결하게 구사하고, 더 정확하게 번역할 수 있으려나 모르겠다. 쏟아져 나오는 용어들을 일일이 다 번역하는 것은 무의미하고 결국은 있는 그대로 빌려 쓰는 말도 있겠지만, 그게 결국은 독해력· 문해력의 격차로 이어지고 학문 수준의 격차로 이어지 않을지?

진실은 한국어· 한글이 앞으로 수십~수백 년 안에 사멸할지도 모른다고 걱정하던 옛날 민족주의 성향의 언어학자들하고, 그런 거 아무 의미 없다고 상대주의적으로만 흘러가는 요즘 추세의 중간에 있지 않나 생각이 든다.

Posted by 사무엘

2018/04/10 08:37 2018/04/10 08:37
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1477

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

사용자 삽입 이미지

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

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

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

사용자 삽입 이미지

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

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

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

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

  • 1953년 7월 27일이 6· 25 전쟁이 끝나고 한반도의 군사분계선 일대에서 총성이 완전히 멎은 날인데, 정확하게는 저 문서에 나와 있듯이 아침 10시경에 공식 문서가 작성되어 그로부터 12시간 뒤, 일과가 다 끝난 밤 10시부터 효력이 발휘되기 시작한 것으로 보인다.
  • 휴전 협정이 벌어지고 저 문서가 작성된 장소는 오늘날의 그 판문점이 아니다. 옛날 오리지널 판문점은 지금 판문점보다 서쪽으로 1km쯤 더 떨어진 곳에 있었고 지금은 완전히 북한 땅이다. 그 건물 자체는 현재까지도 남아 있다.
  • 저 문서에 서명을 한 사람은 북한, 중국, 미국 대표밖에 없다. 그 당시 남한 측 대표는 알다시피 강경한 북진멸공덕후였던 관계로 휴전 따위에 결코 동의하지 않았기 때문이다.
"휴전 협정은 전쟁을 줄이는 것이 아니라 더 큰 전쟁의 준비 행위이고 더 많은 고난과 파괴를 의미하며, 전쟁과 내란에 의한 공산당의 더 많은 침략 행위의 서막이 된다는 나의 확신 때문에 나는 휴전 협정 서명에 반대하였습니다. 이제 휴전이 서명된 이 마당에 나는 그 결과에 대한 나의 판단이 틀렸던 것으로 나타나기만 기원할 뿐입니다.
그러나 북녘의 동포 여러분, 희망을 버리지 마십시오. 우리는 여러분을 결코 잊거나 외면하지 않을 것이고 반드시 여러분을 구출할 것입니다." (1953년 7월 29일자 민주신보, 그 당시 이 승만 대통령의 담화문 윤문 각색)


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

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

Posted by 사무엘

2017/08/20 08:30 2017/08/20 08:30
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1395

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 사무엘

2017/07/27 08:38 2017/07/27 08:38
, , ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1386

다음 버전 개발 근황

<날개셋> 한글 입력기 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 사무엘

2016/05/21 08:24 2016/05/21 08:24
, ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1229

Windows 10 사용기 외

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 사무엘

2015/08/28 08:31 2015/08/28 08:31
, , ,
Response
No Trackback , a comment
RSS :
http://moogi.new21.org/tc/rss/response/1132

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

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

시카고 대학교의 제임스 맥콜리 교수는 잘 알다시피 한글날은 전세계의 언어학계가 다함께 경축해야 하는 날이라면서 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 사무엘

2015/06/08 08:28 2015/06/08 08:28
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1102

« Previous : 1 : 2 : 3 : 4 : 5 : Next »

블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2021/02   »
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28            

Site Stats

Total hits:
1548655
Today:
444
Yesterday:
485