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

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

사용자 삽입 이미지

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

그런데 북한에 '섯!' 표지판이 있다면, 옛날에 남한에는 주차 대신 '둠'이라는 표지판이 있었다고 한다. 당연히 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

Trackback URL : http://moogi.new21.org/tc/trackback/1477

Leave a comment

본인은 우리나라 근현대사와 한글 기계화에 모두 관심이 지대한 사람으로서,
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

Trackback URL : http://moogi.new21.org/tc/trackback/1395

Leave a comment

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

Trackback URL : http://moogi.new21.org/tc/trackback/1386

Comments List

  1. nyam 2017/07/27 13:36 # M/D Reply Permalink

    항상 공감 가고 완성도 있는 글 감사히 잘 보고 있습니다.
    이 글을 보고 제가 지금까지 '아니요' 대신 '아니오'로 잘못 써오고 있었다는 사실을 깨달았습니다..

    감사합니다.

    1. 사무엘 2017/07/27 15:43 # M/D Permalink

      앗, nyam 님! 오랜만에 뵙습니다. 잘 지내시죠?
      이곳을 꾸준히 방문하고 글들을 구독해 주셔서 고맙습니다. ^^
      ‘아니요’는 저 역시 오랫동안 잘못 알고 있었던 사항입니다.

  2. 경헌 2017/07/27 18:03 # M/D Reply Permalink

    아아 신의손 제작자님이 어썸노트 제작자님 이었군요..

    역시 뛰어난 개발자는 플랫폼을 초월합니다 ㅎㅎ

    1. 사무엘 2017/07/27 20:17 # M/D Permalink

      네, 놀랍죠? 그저 대단하고 부러울 뿐입니다. ^^

Leave a comment

다음 버전 개발 근황

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

Trackback URL : http://moogi.new21.org/tc/trackback/1229

Comments List

  1. 지나가다 2016/06/04 15:38 # M/D Reply Permalink

    갓 윈도10을 접하게 된 기존 사용자입니다.

    엣지 같은 메트로앱에서도 날개셋 입력기가 동작되게 할 수 있는 방법이 없나요?

    1. 사무엘 2016/06/04 17:58 # M/D Permalink

      지금도 Metro UI에서 사용 가능합니다. 다만 메트로 모드가 강요하는 보안 제약 때문에 데스크톱 모드와 동일한 수준으로 GUI 기능을 사용할 수는 없고요. 이건 제 프로그램에서 더 개선이 불가능한 한계입니다.
      더 자세한 것은 프로그램 도움말에서 "VI. 외부 모듈 → 알려진 문제" 부분의 설명을 참고하세요.

Leave a comment

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

Trackback URL : http://moogi.new21.org/tc/trackback/1132

Comments List

  1. 사무엘 2015/09/12 23:35 # M/D Reply Permalink

    다음 버전에서 Windows 10 관련 반영된 사항은..

    1. Metro UI에서는 제어판, 텍스트 필터 등 데스크톱 GUI를 사용하는 기능들을 모두 사용할 수 없게 메뉴 차원에서 막음. 어차피 동작하지 않으므로.

    2. Windows 10은 명령 프롬프트가 굉장히 많이 바뀐 듯함. Metro가 아님에도 불구하고 제어판을 띄우면 뜨지 않을 뿐만 아니라 에러가 났던 문제 해결. 예전에는 없어도 되던 안전 루틴이 필요해짐.

    3. 명령 프롬프트에서 한글 조합 진행이 더 되지 않던 문제 해결.
    A처럼 동작하면 이 프로그램에서 안 돌아가고, B처럼 동작하면 저 프로그램에서 안 돌아가는 정말 엿같은 상황이 있는데.. 지금까지는 명령 프롬프트만을 위한 전용 로직이 있었다.
    그런데 Win10은 명령 프롬프트에서도 자기가 명령 프롬프트라고 알려 주지를 않아서 문제가 발생하고 있었음. 다른 방법으로 문제를 피해 갔지만, 또 다른 프로그램에서 오동작이 발생할 가능성이 있음.;;

    단, Edge에서 페이스북의 댓글란에서 한글 입력이 씹히고 오동작이 발생하는 것은
    거의 1주일이 넘는 디버깅과 테스트, 문자 조합 루틴을 다시 짜 보는 생쑈에도 불구하고 원인 불명 해결 불가로 결론을 내렸습니다. 도대체 MS IME와 제 프로그램이 동작 방식이 뭐가 달라서 저렇게 되는지 알 수 없습니다. Edge의 버그라는 가능성을 더 높게 칩니다.

Leave a comment

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

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

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

Trackback URL : http://moogi.new21.org/tc/trackback/1102

Comments List

  1. 허국현 2015/06/10 09:04 # M/D Reply Permalink

    외국인 한글 교육 사이트를 돌아 다니다 보면, 자주 보이는 질문들 중 하나가, "ㄱ은 K인가요? G인가요?"입니다. 사실 변종도 많습니다. (ㅈ은 j인가요? ch인가요?, ㄷ은 d인가요? t인가요? ㅂ은 B인가요? P인가요? 등)

    한국어 자음는 발음의 세기에 따라 정해지지, 유성음, 무성음에 따라 정해지지 않습니다. 그러다 보니, 이 부분이 헷갈릴 수밖에 없습니다. 규칙이 있는가 알아 보려고 했는데, 첫번째 나오는 것은 무성음이다 외에는 두번째 나오는 것부터는 답이 없더군요. 정말 그때그때 달라요였습니다. "이히리기우구추" 수준으로 다 외우세요밖에 답이 없을 정도로...

    아마 한글로 음성 기호를 만든다면 유성음, 무성음 문제도 해결해야 할 것입니다.

    1. 사무엘 2015/06/10 10:23 # M/D Permalink

      네, 그렇습니다. 듣보잡 나라 언어도 아니고 당장 이웃 일본어를 표기하는 데에도 유· 무성음의 구분이 필요하죠. F 같은 것만 신경 쓸 때가 아닙니다.
      뭐 사잇소리만 해도 정말 답이 없는 지경인데, 유/무성음이 설마 그거보다 더 복잡하겠어요? ㅎㅎ

  2. 김재주 2015/06/10 14:10 # M/D Reply Permalink

    오랜만에 한글 얘기 나왔으니 말인데요. 혹시 노마 히데키 교수의 "한글의 탄생" 이란 책 읽어 보셨는지요? 예전에도 추천했던 것 같은데, 일본인들을 대상으로 한자->구결->가나로 이어지는 전통적인 한자 기반 문자체계를 소개하고, 그와는 완전히 독창적인 한글이 어떻게, 누구에게서 탄생했는가, 어째서 한글이 과학적인 문자인가 등등을 민족주의적 시각에서 벗어나 상당히 객관적인 시점에서 서술하고 있습니다(저자가 일본인이니까요)


    우리말로도 번역이 되어 있는데, 한국인 입장에서도 꼭 읽어봐야 한다고 생각합니다.

    1. 사무엘 2015/06/10 17:04 # M/D Permalink

      네, 오랜만에 한글 얘기 하지요? ㅎㅎ
      전에도 한번 언급하신 적이 있었습니다. 저 같은 연구자에게 꼭 필요한 문헌이랍니다.
      한번 보려고 생각은 했는데 미처 그러지 못했네요. 검색을 해 보니 마침 학교 도서관에도 비치돼 있고.. 지금 기말 과제 때문에 빌린 책을 반납해야 할 때가 곧 오니 그때 도서관에서 꼭 볼 생각입니다. ^^

Leave a comment

지금이야 고등학생이 스마트폰 앱을 뚝딱 만들고 안드로이드나 애플 사의 앱스토어에다 등록하는 소프트웨어 유통망까지 확립된 시대이다. 하지만 지금으로부터 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 사무엘

2014/09/09 08:30 2014/09/09 08:30
, , , ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1005

Trackback URL : http://moogi.new21.org/tc/trackback/1005

Comments List

  1. 김경록 2014/09/19 12:38 # M/D Reply Permalink

    '무한 낱자 수정' 기능은 날개셋 입력기에서만 찾아볼 수 있는 정말 편리하고 독특한 기능이에요!!

    1. 사무엘 2014/09/20 11:26 # M/D Permalink

      그 상태에서도 필요하다면 언제나 지금 낱자를 고치기만 하는 게 아니라 다음 글자로 빠지는 것도 예외적으로 알 수 있게 하는 연구가 진행 중입니다.
      국가적으로 세벌식 자판의 가능성과 가치가 꼭 재평가되었으면 좋겠습니다. :)

Leave a comment

작년 가을엔 <응답하라 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 사무엘

2014/01/06 08:13 2014/01/06 08:13
, , ,
Response
No Trackback , 5 Comments
RSS :
http://moogi.new21.org/tc/rss/response/917

Trackback URL : http://moogi.new21.org/tc/trackback/917

Comments List

  1. 정 용태 2014/01/08 00:13 # M/D Reply Permalink

    글꼴은 누구나 쉽게 만들고 쓸수 없는 물건이기에 시대를 관통하는거 같습니다..
    특정 시기에 한글 소프트웨어에 번들된 글꼴이 많이 쓰이는 시절도 있었고요.. 예를 들면 한글에 있는 특유의 필기체 같은.. 요즘은 그 특유의 필기체를 어디서도 찾아보기 힘드네요 ^^

  2. 정 용태 2014/01/08 00:25 # M/D Reply Permalink

    그리고 살짝 궁금해져서 필기체에 대해 서핑해봤는데 이런 재미있는 링크도 있어서 붙여봅니다.
    http://puwazaza.com/319
    http://www.youtube.com/watch?v=qefD5YHPeEM

    1. 사무엘 2014/01/08 10:43 # M/D Permalink

      새해 첫 댓글 당첨이십니다. ^^
      한글의 경우 잘 알다시피 복잡한 조합 룰 때문에 완성도 높은 글꼴을 만들기가 더욱 어렵습니다.
      그나마 이미 정해진 조합 룰 템플릿을 기반으로 싸제 글꼴을 찍어내는 건 옛날에 비트맵 시절에는 그나마 유행이 있었는데 지금은 다 없어졌지요.
      그리고 그 조합 룰 자체를 새로 짜는 기술은 글꼴 제조 회사들이 제각각 보유하고 있지 일반인에게 공개되어 있지 않습니다. (안타깝지만 그 이유는 물론 저는 매우 수긍합니다)

      아래아한글 필기체의 경우, 만들어진 사연이 있는 것도 아시죠? 지금은 아래아한글이 아니면 <날개셋> 편집기에서나 볼 수 있는 추억의 글꼴이 됐습니다. ㅎㅎ

      Comic Sans가 원래는 BOB에 들어갈 글꼴이었는데 그렇게 퍼져 나가고 또 그런 금지 처분을 먹었다니.. 정말 흥미로운 걸요? 처음 알았습니다.
      정 용태 님, 복 많이 받으세요.

  3. 파츠쿠 2014/01/08 17:40 # M/D Reply Permalink

    그게 바로 김치들의 철도에 대한 의식수준이죠. 세금으로 철도 깔아줬더니 시끄럽다고 이설하고 옮기는 새끼들이 김치들이죠.

    1. 사무엘 2014/01/09 06:37 # M/D Permalink

      저도 철도에 대한 지역 이기주의 및 왜곡된 인식이 참 안타깝답니다.
      하지만 그런 인식을 깨어 있는 철덕들이 차근차근 개선해 나가야겠죠. 굳이 다른 사람들을 비하할 필요는 없을 듯합니다. ^^

Leave a comment

유니코드 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 사무엘

2013/12/16 08:25 2013/12/16 08:25
, , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/909

Trackback URL : http://moogi.new21.org/tc/trackback/909

Leave a comment

디지털 컴퓨터는 전자 신호로 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 사무엘

2013/12/13 08:24 2013/12/13 08:24
, , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/908

Trackback URL : http://moogi.new21.org/tc/trackback/908

Leave a comment
« Previous : 1 : 2 : 3 : 4 : 5 : Next »

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2018/06   »
          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 29 30

Site Stats

Total hits:
973169
Today:
6
Yesterday:
524