가끔은 컴퓨터라는 물건이 발명된 지가 아직 100년도 채 안 됐다는 게 도저히 믿어지지 않을 때가 있다. 세상을 이렇게 완전히 180도 뒤바꿔 놓은 기계가 역사가 그렇게도 짧다니! 그 내력이 최소한 전화기나 자동차의 역사 정도는 될 법도 해 보이지만 실제로는 그렇지 않다. 하긴, 텔레비전이 컴퓨터보다 약간 더 일찍 발명된 정도다.

오늘날의 컴퓨터와 비슷한 컨셉이라도 탑재된 물건이 최초로 등장한 시기는 아무리 일찍 잡아도 2차 세계 대전 이후이다. 전자식+2진법+튜링 완전+프로그램 내장형 같은 기본 중의 기본 단서만 추가해 줘도 시기는 더 늦어진다. 그리고 그것마저도 덩치와 성능은 오늘날 우리가 쓰는 노트북과 스마트폰하고는 차마 비할 바가 못 됨은 주지의 사실이다.

컴퓨터가 2차 세계 대전 이후의 산물이라는 건, 다시 말해 단군의 후손들이 역사상 컴퓨터라는 걸 접한 시기는 오로지 '대한민국' 시대가 유일하다는 뜻이다. 일제 강점기나 조선 시대엔 그런 거 없었다. 그러니, 세계의 컴퓨터 역사뿐만 아니라 그 컴퓨터를 처음으로 우리나라에 도입하고 전산망을 개설한 선구자들의 전설의 레전드를 공부해 보는 것도 전산/컴공 전공자이든 비전공자이든 흥미로운 경험이 될 것이다.

우리나라에는 이 분야의 거장으로 성 기수 박사(1934-), 전 길남 박사(1943-)가 있다. 난 성 박사는 고등학교 때 어느 인터넷 사이트를 통해 아주 아주 대단한 분이라고 우연히 알게 됐다. 전 박사는 알지도 못하다가 대학에 진학해서야 내가 다니는 학교의 학과에 소속돼 있는 만렙 명예교수 중의 한 분 정도로나 접하게 됐다.

두 분 다 업적이 워낙 전문적이고 비가시적인 곳에 있는지라 대중적으로 유명하지는 않다. (2011년 10월에 1주일 간격으로 나란히 세상을 떠났음에도 불구하고 스티브 잡스와 데니스 리치의 대외 인지도의 차이를 생각해 볼 것!)
그러나 굳이 따지자면 아무래도 전자보다는 후자가 약간 더 유명하다. 우리나라 인터넷의 아버지라고 최근에 웹툰도 올라왔고 이게 각종 SNS에 퍼날라지면서 반짝 뜨곤 했다. 독자 여러분에게도 일독을 권한다.

(1982년 5월 15일, 구미 전자 기술 연구소와 서울 대학교 사이에 국내 최초 원거리 컴퓨터 네트워크 교신에 성공. 이건 모뎀이냐 랜이냐 뭐냐? 무슨 물리 메커니즘으로? 으음...;;)

저분은 은퇴한 뒤에도 활발히 활동하고 계시고, 게다가 저 웹툰을 보고는 작가에게 고증 오류 피드백까지 친절하게 해 주셨다고 한다. 여담이지만, 저분의 배우자가 여성 운동가인 조한 혜정 교수라니 깜짝 놀랐다.

최근의 강연 내지 인터뷰에서 전 박사는 인터넷은 너무나 대중적으로 퍼진 만큼 앞으로는 좀 더 안전해져야 한다고 거듭 강조한 적이 있다. 안티바이러스 프로그램의 개발자로 유명한 카스퍼스키는 강력한 인터넷 규제와 신원 확인에 찬성하는 의견을 피력하는 사람인데 그것과도 비슷한 맥락인가 싶었다. 초창기에 인터넷의 각종 규격을 설계했던 엔지니어들은 이 비싼 통신 인프라가 어중이떠중이가 다 쓰는 보편적인 물건이 될 거라고는 감히 생각을 못 했었을 것이다. 그러니 보안보다는 성능과 효율을 훨씬 더 중요하게 생각할 수밖에 없었겠지.

난 전산학의 여러 분야 중에서도 네트워크, 보안 쪽은 제일 까막눈 문외한이다 보니..;; 저런 분을 보면 그냥 입 쩍 벌리고 대단하다는 말밖에 안 나온다.

그럼, 다음으로 성 기수 박사 얘기를 좀 하겠다.
이분도 완전 날고 기는 수재였으며 하버드 대학교에서 석· 박사를 3년 만에 뚝딱 마친 것은 오늘날까지도 유학생들 사이에 전설로 회자된다고 그런다. 원래 전공은 기계· 항공 공학 쪽이었으며 전자· 전산이 아니었다. NASA 같은 데에나 들어가서 우주선과 로켓 엔지니어가 됐을 분이 “아무래도 우리나라엔 컴퓨터가 필요하다”는 신념 하에 한국으로 돌아와 KIST 전산실 실장을 맡았다.

전 길남 박사가 라우터 등 인터넷 기술을 자체 개발하여 우리나라를 인터넷 대열에 합류시켰다면, 성 기수 박사는 그보다 옛날에 우리나라의 행정, 은행, 병원, 철도 등 각 분야의 시스템 전산화를 이끌었다. 전산학이라는 학문이 국내 학계에 제대로 정립조차 되기 전인 초창기에 하드웨어와 소프트웨어를 넘나들며 우리나라의 발전에 지대한 업적을 남긴 것이다. 워낙 옛날이기 때문에 구분이 별로 의미가 없었을지도 모르지만, 저분의 세부 관심사는 HW와 SW 중 어디에 가까웠을지가 궁금해진다.

2000년대 초반에 바둑 연구를 끝으로, 그 뒤부터는 저분은 언론에 보도되는 근황은 없이 조용히 노후를 보내고 계신 듯하다.

인터넷 검색을 하면 성 박사의 일대기를 곳곳에서 발견할 수 있다. 그런데 내 시선을 고정시키는 에피소드가 하나 있었다.
지금으로부터 40년도 더 전인 1970년, KIST 전산실에서 그의 주도하에 한글 전자 인쇄 장치를 개발해 냈다고 한다.
유니코드고 트루타입 글꼴이고 뭐고 하나도 없던 까마득한 옛날에 일종의 1세대 비스무리한 한글 기계화를 이룬 거라고 보면 되겠다.
그런데 여기서 벌써 한글 입력 방식에 대한 얘기가 나온다.

이 글을 읽을 때 유의해야 할 점은 다루는 시기가 굉장히 옛날이라는 점이고, 그럼에도 불구하고 논쟁의 대상이 흔히 생각하기 쉬운 기계식 타자기가 아니라 컴퓨터라는 점이다. 물론 시기가 시기이다 보니, 일반인이 간편하게 다룰 수 있는 오늘날의 개인용 소형 컴퓨터 얘기는 전혀 아니다. 저건 애초에 그런 범용(general-purpose) 컴퓨터도 아니다.

저 때보다 약간 전인 1969년 여름에 국가에서는 타자기용으로 네벌식 글자판을 표준으로 지정했다.
난 그 시절엔 두벌식이라는 게 전혀 없었고 그건 나중에 1980년대에 와서야 생긴 줄 알았다. 그런데 그건 아니고 그 이전부터 두벌식과 네벌식이 모두 있었던 듯하다. 사료를 모두 종합해서 고찰해 보면, 1969년에는 “타자기는 네벌식, 전자 기기는 두벌식”으로 표준이 제정됐고 나중에는 네벌식이 공식 폐기뒨 후 “기계식 타자기까지도 받침 글쇠를 넣어서 두벌식”으로 바뀐 것 같다.

또한 같은 두벌식이라 해도 그때의 두벌식은 오늘날의 '바지들고서' KSX5002 26키 배열하고는 차이가 있었을 수도 있으니까. 나의 역사 지식에 오류가 있다면 수정 지적을 환영하는 바이다.

아무튼, 성 기수 박사가 한글 전자 인쇄기를 개발하던 당시에 국가에서는 이미 네벌식과 두벌식을 밀고 있었다. 그리고 성 박사는 자신이 개발하는 기계에 들어가는 한글 입력 소프트웨어를 별다른 고민 없이 두벌식 기반으로 설계했다.
그분도 그렇게 타자기 따로, 컴퓨터 따로 식인 글자판 표준에는 문제가 있다고 판단했다. 그러나 “씁 어쩔 수 없지”였고, 그런 문제의식만으로 끝이었다.

기계식 타자기가 연극과 같다면 컴퓨터는 영화와 같은 매체이다. 기계식 타자기야 메커니즘이 복잡해서 어쩔 수 없지만, 컴퓨터에는 아무 제약이 없으니 글쇠배열은 가능한 한 간단할 수록 좋을 것이다. 자음의 초· 종성 구분은 컴퓨터 소프트웨어가 알아서 판단하게 하는 게 좋을 것이다. 사용자의 입장에서는 자동화가 되어서 좋고, 개발자의 입장에서는 오토마타 이론을 구현하면서 자신의 프로그래밍 실력을 과시할 수도 있어서 좋다..는 게, 컴퓨터쟁이가 한글 입력에 대해서 생각할 수 있는 딱 전형적인 의식 수준 그 이상도 그 이하도 아니지 않았을까?

그 시절, 공 병우 박사는 안 그래도 나라에서 자기의 세벌식 글자판을 외면한 것 때문에 심기가 불편했다. 그랬는데 마침 한글 전자 인쇄기에 네벌식 대신 두벌식 글자판이 들어간다고 하자 책임자인 성 박사를 자기 집에 초대해서 로비(?)까지 시도했다고 한다. 공 박사는 그 시절에 이미 그야말로 억만장자가 된 60대의 안과 의사였고, 성 박사는 30대 중후반으로 공 박사의 아들 연배인 파릇파릇한 공학자였다. 물론 전공은 다를지언정 두 분 다 대한민국 0.1% 이내에 드는 천재들인 건 주지의 사실이다.

공 박사는 고급 외제차를 몰고 성 박사를 데리러 홍릉 KIST를 직접 찾아갔다. 그리고 호화로운 자기 집에서 최고급 요리를 대접하면서 제안을 한 게.. “당신 같은 사람이 세벌식을 지지해 준다면 당신이 필요한 연구비는 내가 얼마든지 대 주겠소.”였다고. 여러분도 잘 아시잖는가. 공 박사는 기계덕후였으며 평생 젊은 프로그래머, 엔지니어들을 굉장히 좋아하셨다.

국가로부터 받는 예산만으로는 당장 연구실의 장비 내지 컴퓨터의 업그레이드조차 빠듯할 지경이었는데.. 그 제안에 성 박사가 귀가 솔깃해질 정도였다고 한다. 이거 뭐 “KIST에 공 병우 박사의 기증으로 슈퍼컴퓨터가 한 대 도입되었다” 같은 역사가 쓰여질 수도 있었다!

허나 설득은 잘 되지 않았던 것 같다. 공 박사의 입장에서 성 박사는 장래는 촉망되지만 한글이나 글자판에 대한 건전한(?) 소신이 없이 그냥 어용학자로 빠질 위험이 있는 인재로 보였을 것이다. 그리고 성 박사의 입장에서 공 박사는 그냥 자기 발명품만 꽉 껴안고 놓을 생각을 안 하는 고집쟁이 타자기 덕후로만 보였을 것이다. 늘어놓는 이야기가 서로 핀트가 안 맞았다.

성 박사는 공 박사로부터 융숭한 대접을 받고 세벌식 한영 타자기를 한 대 선물로까지 받았지만, 세벌식 같은 덴 애착이 별로 안 갔으며 그건 곧 그걸 갖고 싶어하는 다른 후배에게 줘 버렸다고 한다. 그리고 두 '박사'간의 만남은 그걸로 끝이었다. 저 사이트의 글도 “성 기수의 결정은 결과적으로 반공병우파의 손을 들어 준 셈이 되어 버렸다.”라고 씁쓸하게 끝난다.

그래. 하버드에서 3년 만에 박사 학위를 받은 공돌이라고 해도 그 옛날에 타자기와 컴퓨터의 글자판 통일 가능성을 생각할 수는 없었을 것이다. 글자판 일체형 직결식 글꼴이 항공· 기계 분야하고 관계가 있지는 않잖아.

물론 공 박사도 의사 겸 의학자일 뿐, 언어학이나 타이포그래피를 체계적으로 공부해서 그 분야에 학위가 있지는 않은 건 마찬가지다. 그러나 이 분야의 식견에 관한 한은 더 옛날부터 이 극로 선생으로부터 감화를 받아서 한글덕후로 개조가 끝나 있던 공 박사가 더 앞서 있었다. (그러고 보니 이 글에서 덕후 타이틀만 무려 3개가 나왔군.. -_-)

그럼에도 불구하고 저 사이트의 글에서는 꼭 공 박사가 성 박사를 무슨 불의한 일에 접대로 유혹하고 매수라도 하려 한 것처럼 묘사되어 있어서 좀 유감스럽다. 다른 사람들이 보면 오해하겠다.
이거 무슨... “통일교를 공인해 주면 내 사재로 IMF 빚 다 갚아 주겠다”도 아니고.. 뭐냐?

Posted by 사무엘

2014/08/13 08:35 2014/08/13 08:35
, , , , , , , ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/995

두벌식 한글 입력 방식에는 초성과 종성의 구분을 위해 도깨비불 현상이라는 게 존재한다.
이것은 <날개셋> 한글 입력기의 내부에서는 다음과 같은 조건에서 발생한다. 쉽게 말해 두벌식 종성 + 두벌식 중성 + 오토마타 0상태라고 요약된다.

1. 현재 입력 중인 글자의 직전 마지막 타가 두벌식 타입으로 입력되었고, 종성이 존재한다. (초성이나 중성은 있든 없든 무관)

2. 그 상태에서 초성이 없고 중성이 존재하는 두벌식 타입의 날개셋문자가 새로 입력되었다. (종성은 있든 없든 무관)
여기서 두벌식 타입이라 함은, 오리지널 두벌식 또는 6.7에서 새로 추가된 두벌식 종성 타입이 모두 해당한다.

3. 종성까지 입력된 그 상태에서 새로 입력된 날개셋문자에 대한 오토마타 수식 계산 결과가 0이다. 보통 종성의 경우 이어치기 오토마타 수식은 n -> C ? n : 0인데, 이때는 중성이 입력되면 C가 아닌 B가 nonzero가 되므로 어차피 계산 결과는 0으로 귀착된다.

4. 혹은 양수 상태라 해도 그 상태로는 중성 and/or 종성의 낱자 결합이 불가능해서 어차피 다음 글자로 넘어가야 한다. (implied zero state)


이런 상태에서 다음 글자의 조합이 계속될 때는, 그냥 넘어가는 게 아니라 앞 글자의 종성을 적당히 떼어서 다음 글자의 초성에 미리 넣어 주는 게 도깨비불 현상이 하는 일이다.
자음을 분할하는 방식은 그냥 마지막 한 타만 떼는 기본 동작이 있고, 그 외에 특수 도깨비불 규칙이나 초-종성 공유 낱자 결합 규칙이 관여하기도 한다. 이에 대한 더 자세한 설명은 프로그램 도움말을 참고하도록 하시고.

<날개셋> 한글 입력기는 여러 낱자를 한꺼번에 입력하는 걸 지원한다. 초-중성, 중-종성을 한꺼번에 입력하는 건 물론이고 지금 글자의 종성과 다음 글자의 초성을 곧바로 입력하는 것조차 가능하다.
이와 비슷한 맥락으로 두벌식에서는 '굴' 상태에서 ㅡ를 입력해서 '구르'까지 만드는 것뿐만 아니라 ㅡ+ㅁ을 한꺼번에 입력해서 '구름'을 바로 만들 수도 있다.

다만, 그게 오리지널 두벌식 타입으로는 가능한데, 비교적 따끈한 새 기능인 '두벌식 종성' 타입에서는 중성과 종성을 중첩 입력하는 게 제대로 지원되지 않았다. 이것이 지난 7.11 버전에서 개선되었다.
오리지널 두벌식은 비록 종성이라 하더라도 다음 글자로 넘어갈 때 종성이라는 정체성이 없어지고 초성과 완전히 다름없게 처리된다. 그렇기 때문에 그 상태에서 중성+종성을 한꺼번에 입력하는 것이 자연스럽게 가능하다.

그러나 두벌식 종성은... 비록 다음 글자로 넘어가서 모음과 결합함으로써 외형상 초성으로 바뀌긴 하지만, 원래 자신이 종성이었다는 본디 정체성은 변함없이 유지되어야 한다.
자신이 이미 불변 종성인데 중성과 더불어 또 다른 종성까지 한꺼번에 입력되면, 이것은 도깨비불을 의도하는 건지 아니면 그냥 중성과 종성의 평범한 결합이나 분리를 의미하는 건지 프로그램이 논리적으로 명확하게 결정해야 한다.

오리지널 두벌식 타입의 종성 ㅁ (H2|_M)을 조합하는 상태에서 두벌식 ㅏ+ㅂ(H2|EO|_B)을 배당해 주면 응당 '맙'으로 바뀐다. 단지 bksp를 한번 누르면 ㅁ이 이제는 종성이 아니라 초성으로 되어 있을 뿐이다.
그러나 두벌식 종성 타입의 종성 ㅁ (H2J|_M)에다가 같은 입력을 공급하면 '받침ㅁ/ㅏㅂ'이 되고 ㅏ+ㅂ을 따로 조합하는 상태가 된다.

그리고 받침 ㅁ 대신 받침 ㄹ을 조합하는 상태에서 같은 입력을 공급하면 그 중성과 종성이 지금 글자와 결합하여 ㅏ+ㄻ을 조합하는 상태가 된다. 이것은 받침 ㄹ이 오리지널 두벌식이든 두벌식 종성이든 결과가 동일하다. 왜 그럴까?

가장 큰 이유는 입력 날개셋문자에 중성뿐만 아니라 종성이 존재하기 때문이다. <날개셋> 한글 입력기가 제공하는 기본 오토마타들은 한 번에 초-중-종이든 낱자가 하나씩만 들어온다고 가정하고 설계되어 있다. 그래서 C ? n : 0 수식의 값은 nonzero가 되어, 도깨비불 현상 대신 지금 글자의 조합이 계속 유지되게 되는 것이다.

물론, ㄹ+ㅂ의 경우와는 달리 ㅁ+ㅂ은 결합이 성립하지 않는다. 세 성분 중 한 성분이라도 결합이 되지 않으면 결합은 실패하므로 도깨비불 현상이 발생한다. 이때 오리지널 두벌식은 ㅁ을 초성으로 넘겨 주기 때문에 '맙'을 성공적으로 만들어 준다. 그 반면 두벌식 종성은 ㅁ을 종성으로 처리한다. 그래서 도깨비불 현상 후에도 두 종성은 서로 충돌하며 결합이 실패한다.

이 경우 프로그램은 최종적으로 도깨비불 없이 ㅁ이 마치 세벌식 종성이었던 것처럼 변경 없이 놔 두고, ㅏ+ㅂ만 다음 글자로 따로 떼어 내 준다. 이번 7.11이 취한 정책이다. 예전에는 그냥 조합이 끊어져 버렸었다.

두벌식 종성으로도 중성+종성이 충돌 없이 도깨비불 현상 처리가 되려면, 도깨비불은 결합 실패로 인해 뒤늦게 발생하는 게 아니라 오토마타 수식 차원에서 0이 돌아옴으로써 이 타이밍 때 곧바로 발생해야 한다.
애초에 중성+종성 날개셋문자가 C ? n : 0 수식을 nonzero로 통과했던 게 화근이었다. 이 수식을 !B && C ? n : 0으로 바꿔 주면 문제가 해결된다. 종성이 한번 입력된 뒤부터는 오로지 종성만 받아들이도록 말이다.

이렇듯, 두벌식 종성에서 중성뿐만 아니라 중성+종성 복합 입력의 도깨비불 현상을 처리하기 위해서는 프로그램의 내부 알고리즘도 개선되어야 하고, 사용자의 설정도 미묘하게 바뀌어야 함을 알 수 있다. 한글 입력기 하나에도 오묘한 면모가 은근히 많다.

<날개셋> 한글 입력기는 13년 동안 개발되면서 버전이 무려 7.x대까지 올라갔다. 편집기나 외부 모듈의 외형은 엄청 옛날 버전이나 지금이나 거의 바뀐 게 없지만, 이 프로그램이 진짜로 꾸준히 바뀌고 있는 부분은 입력 엔진과 이를 제어하는 제어판 쪽이다. 이 프로그램은 그야말로 어떤 변칙적인 한글 입력 방식도 만들 수 있고 한자 변환이나 bksp 동작 같은 주변 기능까지 전부 세밀하게 제어 가능한 기술 통합형 엔진을 추구하고 있기 때문이다.

살짝만 스포일링을 하자면, 현재 구상하고 있는 것은 고급 입력 스키마와 고급 입력기이다.
글쇠를 길게 눌렀다 떼는 건, 여러 글쇠를 한꺼번에 누르는 것, 타이밍까지 세벌식 자판에 최적화해 주는 입력 스키마..
그리고 지금의 최종 변환 규칙 같은 것을 입력기 단위로도 적용하여 한글로 일본어나 구결을 곧바로 입력할 수 있는 문자 생성기. 한글과 비한글 문자를 조합 상태에서 끌어들일 수 있는 그런 시스템을 생각 중이다.

이 정도까지 만들어 놓으면 프로그램의 버전은 7.x대 중후반은 올라갈 수 있을 것이고, 그 뒤에 입력기 개발은 진짜로 반쯤 접은 채 다음 글꼴 연구를 시작할 수 있을 것 같다.
NLP 쪽의 연동이 없이 한국어와 무관하게 한글 자체만의 engineering도 할 일이 정말 많다.

Posted by 사무엘

2013/12/01 08:22 2013/12/01 08:22
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/904

두벌식과 세벌식 한글 입력 방식을 제각각 가장 극단적인 FM 형태로 디자인해 보면, 다음과 같은 재미있는 차이를 발견할 수 있다.

세벌식은 초성 결합 지향적이고,
두벌식은 종성 결합 지향적이다!

공 병우 세벌식에서 가장 극단적인 FM을 추구한 입력 방식은 바로, 이중모음 정석이 강요되고 겹받침 조합이 없이 모든 겹받침을 반드시 Shift+한 타로만 치게 되어 있는 세벌식 최종이다.

즉, 이 입력 방식에서는 초성 쌍자음을 해당 자음의 연타로 입력하고, 중성 겹모음은 겹모음용 전용 ㅗ와 ㅜ를 통해서만 제한적으로 입력한다. (ㅢ도 반드시 8로만 한 타에 입력해야 하고, ㅡ+ㅣ로는 입력할 수 없음) 끝으로 종성에는 낱자 결합 규칙이 아예 존재하지 않는다.

이런 제약이 존재하는 덕분에 이 입력 방식은 기계식 타자기와 100% 싱크가 가능하다.
세벌식 기계식 타자기는 글쇠가 종이에 찍히는 초점이 두 군데 있으며, 글쇠도 부동(不動)키와 동(動)키로 나뉜다. 초성과 일반 모음들은 동키이고, 겹모음용 ㅗㅜ와 종성은 부동키이다. (한 글쇠에서 아랫글쇠는 동키, 윗글쇠는 부동키가 되는 경우를 대비해 복잡한 지침이 있긴 한데, 이에 대한 자세한 설명은 이 자리에서 생략)

부동키는 글쇠를 찍은 뒤에도 종이가 이동하지 않기 때문에, 당연히 기계식 타자기에서 낱자 결합용으로 쓰일 수 없다. 초성이야 동키이기 때문에 연타로 아쉬운 대로 쌍자음을 표현할 수 있는 반면, 종성은 그렇게 할 수 없는 것이다. 게다가 이미 중성과 종성을 모두 왼손이 담당하고 있다는 특성상(글쇠가 오른쪽에서 왼쪽으로 흐르는 배열인 것도 기계 친화적인 이유가 있음), Shift+한 타로 겹받침을 누르는 것은 왼손의 연타 부담을 경감하는 데도 도움이 된다.

이런 심오한 이유 때문에 공 병우 세벌식은 초성 쌍자음만을 연타로 입력하고 나머지 중성과 종성은 연타를 최소화하는 쪽으로 발전했다.

그에 반해 가장 FM에 충실한 두벌식은 <날개셋> 한글 입력기 6.7에서 추가된 종성 지향 두벌식처럼 자음은 모든 문맥에서 종성과 같은 형태로 결합하는 입력 방식이다.

아래아한글 같은 일부 프로그램의 한글 입력 방식에서는, 두벌식도 마치 세벌식처럼 초성과 종성의 낱자 결합 규칙이 따로 적용되어서 쌍자음을 해당 자음의 연타로 입력할 수 있는 구현체가 있다. 그러나 FM대로라면 초성이든 종성이든 쌍자음은 반드시 Shift+한 타로 입력해야 한다. 애초에 '국가'와 '구까'를 모두 구분하여 연달아 입력하려면 쌍자음은 그렇게 입력해야만 한다.

따라서 두벌식은, 겹받침을 Shift+한 타로 입력하는 세벌식과는 정반대로 초성 쌍자음을 Shift+한 타로 입력하며, 초성에 낱자 결합 규칙이 존재하지 않는다. 흥미로운 사실이 아닐 수 없다.

다만, 세벌식은 그런 극단적인 이념을 추구함으로써 컴퓨터와 기계식 타자기 사이의 글자판 통일을 이루었으며, 기계적으로 유리한 점과 빠르고 편한 타자 사이의 상당히 괜찮은 합의점까지 잘 찾아 낸 반면, 두벌식은 그런 일관성과 통일성이 없다.

두벌식 타자기는 어차피 받침은 Shift부터 반드시 먼저 누르고 쳐야 하기 때문에 치는 방식이 컴퓨터와 다를 뿐만 아니라, 결국은 ㄲ과 ㅆ, 그리고 자주 쓰이는 겹받침이나 겹모음은 예쁜 자형으로 찍기 위해 별도의 글쇠로 따로 있어야 할 수밖에 없다.

단적인 예로, 똑같이 한 타로 입력하는 겹자음이라도 ㄲ과 ㅆ은 초성과 종성에서 모두 쓰이지만, 나머지 ㄸ, ㅃ, ㅉ은 초성에서만 쓰인다. 이것을 기계식 타자기로 어떻게 구분하겠는가? 게다가 Shift+ㄱ은 어차피 ㄲ이 아니라 초성 ㄱ과 받침 ㄱ을 구분하는 데 써야 하는데? 결국은 겹자음의 처리가 두 그룹이 서로 달라질 수밖에 없다. 두벌식으로는 기계간의 글자판 통일을 이루는 게 불가능하다는 게 이 말이다.

두벌식에 대한 이해도가 깊어지니 그 반대편에 있는 세벌식에 대해서도 예전보다 더 잘 알게 되는 것 같다. 내가 다시 말하는데 그 알량한 글쇠 수 좀 줄이려고 PC에서 한글을 두벌식으로 쓰는 건 너무 아깝다. 얻는 것보다 잃는 게 너무 많다.

두벌식이 완전 백해무익한 쓰레기라는 말이 아니라, 가능한 한 세벌식이 엄연히 main이 되고 두벌식은 sub가 되어야 한다는 뜻이다. 세벌식으로는 간단한 기본 오토마타를 토대로 하여 더 발전하는 응용이 가능한 반면, 두벌식은 지금 있는 꼼수를 체계화하는 데에만 온갖 노력을 들여야 한다. 내 학위 논문이 주장하고자 한 바가 바로 이것이다.

여담이지만 컴퓨터 소프트웨어의 아이콘에서 '한글'을 나타낼 때 쓰는 한글 글자는 대개 '가' 아니면 '한'이다. <날개셋> 한글 입력기는 이를 모두 활용하며, 현 글자판이 세벌식으로 판단되면 '한'이 나오고, 두벌식이면 '가'가 나온다. 꽤 옛날 버전부터 이어져 온 관행인데 이게 나름 합리적인 디자인인 것 같다.

Posted by 사무엘

2012/10/24 08:18 2012/10/24 08:18
, ,
Response
No Trackback , 11 Comments
RSS :
http://moogi.new21.org/tc/rss/response/747

1.

<날개셋> 한글 입력기는 제어판에서 불러다가 곧장 쓸 수 있는 20여 개의 다양한 예제 입력 방식들을 덩달아 제공하고 있다.
6.7 이후 다음 버전에서는 예제 데이터에 아래와 같은 여러 변화가 생길 예정이다.

- 6.7에서 잘 알다시피 종성 지향 두벌식을 활용하여 'MS 두벌식'이라는 유형 파일이 추가되었는데.. 여기에다가 한글 자모 외의 숫자와 기호는 글쇠를 먹지 않게 하는 입력 스키마 설정도 추가했다. (지난 6.5에서 추가된 글쇠 인식 customize 기능으로) 어차피 시스템의 영문 글자판과 똑같은 글자는 IME가 입력시키는 게 아니라 아예 글쇠 자체를 가로채지 않고 응용 프로그램으로 넘겨 준다는 뜻.
이것까지 갖춰 주면 진짜 MS IME와 고증이 100% 일치하게 된다. 특히 외부 모듈에서 말이다.

- 네벌식이 글쇠배열 *.key이 아니라 오토마타와 낱자 결합 규칙을 갖춘 유형(*.ist) 파일로 승격되었다.
받침을 입력하려면 모음을 아무 모음이나 써도 되는 게 아니라 타자기 설계 차원에서 받침용으로 의도된 모음을 써야만 하며, 그렇지 않으면 받침은 다음 글자로 튕긴다.

모음의 용도를 구분하는 건 다양한 방법으로 할 수 있다. 비받침용 모음은 0으로 대응하는 가상 받침을 같이 입력되게 하여 여타 받침과의 결합을 차단시킬 수도 있는데, 본인의 경우 두벌식 모음과 세벌식 모음으로 구분하여 오토마타가 O 변수를 써서 구분하도록 하는 방법을 썼다.

이 외에도 네벌식 오토마타는 초+중(+종)과 중+종은 허용하지만, 초에서 바로 종은 허용하지 않게 설계되어 있다. 97 이전의 도스용 아래아한글이 이런 오토마타를 갖추고 있었다. 또한 ㅒ, ㅖ가 바로 입력 가능하지 않다는 특성상 ㅑ+ㅣ, ㅕ+ㅣ로 해당 모음을 입력할 수 있게 했다.

네벌식은 그나마 옛날 타자기 표준이라는 역사적인 의미가 있고, <날개셋> 기능 활용면에서 의미가 있어서 추가했을 뿐, 타자 관점에서 효율적인 입력 방식은 절대로 아니다. 특히 공 병우 세벌식에 비하면 이런 허접하고 불편한 타자기로 한글 입력을 해야 했을 옛날 타자수들을 생각하면 그저 안구에 습기가 찰 뿐이다.

- 일명 '한소프트 세벌식'과, '드보락 호환 두벌식' 글쇠배열은 효용성이 떨어진다고 판단하여 삭제했다.
특별히 '한소프트 세벌식'에 대해 보충 설명을 하자면, 정체가 불분명하고 원문 자료를 제공하던 사이트도 운영이 중단되어 접속이 불통된 지가 이미 수 년이 지난 상태이다. 글쇠배열도 어차피 그리 잘 만들어진 것도 아닌지라 퇴출을 결정했다. 특히 숫자를 저렇게 Shift를 누른 채 양손으로 입력하게 해 놓으면 도대체 어쩌라는 건지? -_-

2.

현재 '세벌식 순아래' 글쇠배열이라는 게 있어서 예제 파일도 아니고 아예 프로그램에 내장되어 있는 배열 중 하나이다.
그러나 이것은 장기적으로는 *.key 급으로 격하될 예정이다. 내장 데이터로 쳐 주기에는 너무 듣보잡화해 있기 때문이다.

공 병우 박사의 이념을 물려받은 권위와 정통성 있는 세벌식 연구 기관에서--한글 문화원이라든가, 한글 문화원이라든가...-- 앞으로 390과 최종을 통합하는 새로운 세벌식 표준안을 제정한다면, 그 새 배열이 지금 순아래가 있던 자리를 대체하게 될 것이다.

그리고 그 통합안은 더 장기적으로는 390을 또 대체하게 될 수도 있다. 과거에 390이 389를 대체했듯이 말이다.
통합안은 기호 문제 때문에 최종보다는 390에 훨씬 더 가깝게 만들어질 것이다.
그 반면 2000년대부터 세벌식을 접한 사람들은 390보다는 최종이 더 많다. 본인도 최종 사용자.
최종은 27개 겹받침 모두 수록이라는 궁극의 아킬레스건이 있기 때문에 상징적인 의미가 크며, 통합안이 나온 뒤에도 별도로 존속할 가능성이 높다.

이런 이유로 인해, 기존 390 사용자들만 통합안으로 갈아타면, 최종과는 달리 390은 존재의 의미를 상실하여 역사 속으로 사라지게 될 것이다. 이것이 나의 짧은 생각이다.

3.

내 프로그램에는 역사적으로나 설계 방식면에서 의미가 있는 세벌식 글쇠배열 몇 개가 key 파일로 제공되고 있다. 세벌식 389는 받침 배열이 390과 최종의 짬뽕 같으면서도 숫자가 노트북 PC의 키패드 배열과 일치한다는 특징이 있으며, '송 영상'(닉: 길동무)이라는 분이 고안한 영상 세벌식은 세벌식계의 떡밥인 왼쪽부터 시작하는 세벌식을 나름 독창적으로 구현한 배열이다.

누가 만들었는지 모를 왼손/오른손 세벌식은 no shift로도 모자라서 진짜 말 그대로 한 손으로 타자를 치는 것에 특화되어 있다. 내가 알기로 영문 드보락 자판에도 이런 왼손/오른손 변종 배열이 있다. 아마 옛날에 도스용 에디터 같은 데서 이것저것 수집한 자료이지 싶다.

이런 것들은 역사적인 의미 외에 실용적으로 쓰일 가능성이 높지 않으며, 오토마타나 낱자 결합 규칙 같은 것도 그냥 일반적인 PC용 한글 입력기의 설정을 그대로 가져와 쓰는 것만으로도 충분하기 때문에, 유형 파일이 아니라 글쇠배열 형태로만 간단히 제공된다.

4.

현재 프로그램이 기본 제공하는 예제 입력 방식이 20여 개가 있다지만, 파일 하나가 겨우 몇백~몇천 바이트밖에 하지 않으니, 다 합쳐도 크기는 3만 바이트가 채 되지 않는다.
본인은 <날개셋> 한글 입력기의 사용자가 만든 UCC..는 아니고 UCI (user-created input methods) 데이터를 받는다.
마음에 드는 건 프로그램의 다음 버전에다 같이 수록도 흔쾌히 해 줄 것이다. 사실은, 이런 데이터만 공유하는 커뮤니티가 좀 있으면 좋겠다.

선정 기준은 다음과 같다. 하나 이상을 잘 만족하면 된다.

- 아이디어가 기술적으로 독창적일 것: 복벌식이나 신세벌식 같은 것. 이런 식으로 <날개셋>의 조건부 수식과 오토마타, 가상 낱자, 더 나아가 특수 글쇠 따위를 잘 활용하여 두벌식과 세벌식 사이를 왔다 갔다 하는 독창적이고 기발한 한글 입력 방식은 얼마든지 웰컴이다. 수록 0순위임. 다만 한 아이디어 당 한 개, 많아야 두 개로 국한임.

- 역사적 가치가 있거나, 인지도· 권위가 있을 것: 역사성이라 함은 앞서 언급했던 여러 legacy 세벌식 글쇠배열 말이다. 아니면 다수가 쓰거나 명목상의 표준이기라도 해야 한다.
북한 국규 표준은 나름 그쪽에서 권위를 가지고 통용되는 입력 방식이니, 통일을 대비해서라도 예전에 key로만 제공되던 것을 최근에 완전한 유형 형태로 격상했다. 아래아한글 97과 맥 OS, MS 두벌식 같은 기존 메이저 소프트웨어가 미묘하게나마 차이가 존재하는--그것도 오토마타 차원에서!-- 독창적인 한글 입력 방식을 제공하는 것도 바람직한 일이다.

휴대전화용 3대 표준 입력 방식(천지인, 이지한글, SKY-II)은 기술적 독창성과 권위를 모두 갖추고 있으니 두 말할 나위도 없이 수록이다. 사실 이것들을 포인팅 장비로 써 볼 수 있는 보조 입력 도구(패드)도 만들어야 하는데, 아직 6.7에서는 숙원을 못 풀었다.

- 타자 행동 관점에서 아주 효율적이거나 독창적일 것: 모바일용 입력 방식은 워낙 기술적인 메커니즘이 많은 반면, PC용 입력 방식은 딱히 그런 trick은 없이 그냥 글쇠배열 논쟁으로 흐르는 경향이 있다.
역사적인 뿌리나 인지도가 없고 그렇다고 기술적인 독창성도 없는 마이너 글쇠배열이 <날개셋>의 예제로 등재되기 위해서는 진짜 타자 효율이라도 압도적으로 좋다는 증거가 있어야 한다. 그게 아니면 순아래/한손 배열처럼 장애인 접근성 분야라도 파든가.

'영상 세벌식'은 타자 능률까지는 모르겠지만 왼쪽에서 오른쪽으로 흐르는 세벌식이라는 점이 독창성을 인정받아 예제 데이터로 수록되어 있다. 앞서 말한 기술적인 독창성 말고, 배열 자체가 독창적이라는 뜻이다.

- 한글 입력과 관련된 실생활에서 유용할 것: <날개셋> 한글 입력기는 기본적으로 한글 입력에 특화되어 있기 때문에 예제 데이터도 한글 입력 방식을 우대함을 원칙으로 한다. 한글이 아닌 문자는 한국 문화권에서 한글과 같이 즐겨 쓰이는 문자들로 국한한다.

가령, 일본어 문자는 아무래도 아랍· 태국-_- 문자보다야 한국에서 더 친숙하며, <날개셋> 고급 입력기의 사용자 정의 조합 기능을 이용해서 간단히 커버 가능한 예이기 때문에 히라가나와 가타카나가 모두 수록되어 있다. 구결도 마찬가로 국어 정보학 분야에서 유용하기 때문에 수록이다.
콜맥 글자판은 한글 입력과 관계가 없는 영문이지만, 드보락 다음으로 나름 인지도가 있는 마이너 배열인지라 영문 배열은 딱 하나만 선택해서 넣었다.

이상으로 내가 예제 입력 데이터를 선별하여 수록하는 대원칙을 공지했다.
저런 조건 중 하나 이상을 만족하고 기존 예제들과도 완전히 다른 입력 방식이 과연 얼마나 있을지는 잘 모르겠지만, 내 프로그램을 통해 여러 창의적인 한글 입력 방식이 많이 만들어지고 쓰이면 좋겠다.

<날개셋> 한글 입력기는 한글 입력과 관련된 그런 지적 재산들을 모두 구현하고 관리할 수 있는 프로그램이니 말이다.
그런 기반을 마련하기 위해 초창기엔 가장 엄밀한 극단이라 할 수 있는 공 병우 세벌식부터 추구한 뒤, 점차 더 generic한 쪽으로 내려오고 있는 중이다.

여담이지만, '한글 로마자 입력 방식'처럼, 그 자체가 한 입력 방식이 아니라 특정 포괄적인 아이디어 하에서 세부적으로 다양한 입력 방식이 파생되어 나올 수 있다면, 그건 유형 파일이 아니라 아예 별도의 '빠른설정'이라는 플러그 인 프로그램이 담당하게 된다.

Posted by 사무엘

2012/09/13 19:18 2012/09/13 19:18
, , ,
Response
No Trackback , 6 Comments
RSS :
http://moogi.new21.org/tc/rss/response/732

<날개셋> 한글 입력기를 오래 써 본 분들은 아미 아시겠지만, 이 프로그램에서 두벌식 글자판의 자음 글쇠는 내부적으로 다음과 같은 수식으로 표현된다.

T<=1 ? 초성: 종성

그래서 ㄱ을 예로 들면,

T<=1 ? H2|G_: H2|_G

그 반면, 세벌식 글쇠는 간단하게 해당 자모 하나로 끝이다.

H3|G_ (초성 ㄱ) 아니면
H3|_G (종성 ㄱ)

H3은 세벌식 자모를, 그리고 H2는 두벌식 자모를 뜻하는 날개셋문자 접두사이다. G는 ㄱ을 뜻한다. 다만 알파벳 한 글자만 있으면 변수와 구분이 되지 않기 때문에 부득이 뒤에 _가 추가되었다.

종성은 앞에 _를 추가하는 것으로 초성 명칭과 구분한다. 그리고 이렇게 하는 것만으로 명칭의 길이가 두 글자를 넘어섰으므로 뒤에 별도로 또 _를 추가하지는 않는다. <날개셋> 한글 입력기의 헤비 유저라면 이 정도 수식은 이미 다 익숙할 것이다.

두벌식에서 번거롭게 수식이 추가된 이유는 한 글쇠가 상황에 따라 초성 역할도 하고 종성 역할도 해야 하기 때문이다. 오토마타에서 1번 상태는 통상 초성을 첫 입력받은 상태이기 때문에 그때까지는 ㄱ을 초성으로 내보내고, 중성이나 종성이 입력된 뒤부터는 종성으로 내보내라는 뜻이다. 한 마디로 말해 두벌식 타자기에 존재하던 ‘받침’ 글쇠를 이 수식이 담당한다고 생각하면 된다.

세벌식이 아닌 두벌식 자모는 종성을 처리할 때 세벌식 자모에 비해 다음과 같은 두 가지 추가 작업이 행해진다. 두벌식 글자판에서 한글이 입력되는 과정을 생각해 보면 자명한 것들이다.

첫째, 두벌식 종성 다음에 두벌식 중성이 이어지면, 잘 알다시피 도깨비불 현상이 일어난다. 직전에 입력되었던 마지막 종성 한 타가 다음 글자의 ‘초성’이 되고, 그 글자와 중성이 한데 결합한다.

둘째, 두벌식 종성이 계속 입력되었는데 기존 종성과 새 종성이 결합이 불가능하면 새 종성은 다음 글자의 종성이 아니라 ‘초성’으로 넘어간다.


두벌식을 세벌식에다가 추가적인 처리를 덤으로 하는 관점에서 한글 입력기를 설계하면 대체로 이런 식의 구현체가 나온다. <날개셋> 한글 입력기도 그렇고 아래아한글도 그렇고, 심지어 맥 OS의 한글 입력기도 그러하다.

특히 맥 OS는 두벌식과 세벌식의 낱자 결합 규칙이 완전히 동일하다. 초성은 쌍자음을 원시 자음의 연타로 입력할 수 있는 반면 종성(ㄲ, ㅆ)은 그렇게 할 수 없는 것이 둘 모두 똑같다. 초성의 결합 규칙과 종성의 결합 규칙이 분명히 구분되어 있으며, 두벌식에서 다음 음절로 이어진 첫 자음도 응당 초성으로 간주된다.

그런데 ‘초성’이 아닌 ‘종성’ 관점의 두벌식 한글 입력 방식도 생각할 수 있으며, 사실 이것이 초성과 종성의 구분이 없는 진정한 두벌식다운 두벌식이라 할 수 있다. 이 사상이 반영된 구현체는 마이크로소프트 Windows의 한글 IME가 유일하다.

MS IME의 두벌식은 초성과 종성의 구분이 없고 자음 입력은 어떤 경우에든 종성 문맥으로 간주된다. 그렇기 때문에 모음 없이 자음을 바로 입력할 때도 ㄳ, ㄻ 같은 겹자음을 만들 수 있다. 심지어 그 상태에서 ‘ㄱ (ㅏ) 가 (bksp) ㄱ (ㅅ) ㄳ (ㅗ) ㄱ소’ 같은 자유로운 입력도 가능하다.

이것은 <날개셋> 한글 입력기에서는 지금까지 가능하지 않았다. 수식 없이 H2|_G 같은 기존 두벌식을 종성만 배당하면, 모음 없이 당장 겹자음을 만드는 것을 비슷하게 흉내는 낼 수 있다. 그러나 완전히 똑같게는 못 한다. 계속해서 다음 음절로 입력되는 자음은 어차피 종성이 아니라 초성이 되어 버리고, 종성의 낱자 결합 규칙이 적용되지 않기 때문이다.

또한 두벌식 종성으로 자음, 그 다음으로 모음을 입력한 뒤 Bksp를 눌러 보면, 첫 타에 해당하는 자음은 종성이 아니라 초성으로 바뀌어 있는 것도 볼 수 있다. 내부적으로 두벌식 종성과 두벌식 중성 사이에는 도깨비불 현상이 한번 일어나서 종성이 초성으로 넘어간 걸로 간주되기 때문이다.

이 문제를 해결하고 종성 위주 두벌식을 도입하기 위해, 본인은 <날개셋> 한글 입력기의 어느 부분을 개량하면 좋을지 굉장히 많이 고민했다. 기존 패러다임과 새 패러다임을 어떻게 조화시킬까?
어느 구조체를 확장할까, 어느 API에다 옵션 플래그를 추가할까, 아예 날개셋문자에다가 새로운 타입을 추가할까..? 이런 결정을 내려야 할 때가 정말 내가 엔지니어로서 현역이고 살아 있음을 느낀다.

API 호환성을 깨뜨리지 않고 가장 후폭풍이 적은 방법을 며칠간 고민하던 중, 결국은 날개셋문자에다 타입을 추가하는 게 가장 바람직하겠다는 결론을 도출하였다. 그래서 H2에 이어 일명 H2J라는 타입이 도입되었다. 일명 ‘두벌식 종성’ 타입. <날개셋> 한글 입력기 다음 버전인 6.7에서 바로 볼 수 있을 예정이다.

현재 한글 입력과 관련된 날개셋문자 타입은 H3과 H2 말고도 H3의 자매격에 해당하는 다중 자모가 둘 더 있다. <날개셋> 한글 입력기는 기존 H3만으로도 ‘ㅏ+종성ㄴ’ 같은 다중 자모를 배당할 수 있다. 초성 ㄱ을 입력 중에 저걸 누르면 곧바로 ‘간’이 되고, ‘오’를 입력하던 중에 저걸 누르면 곧바로 ‘완’이 된다. 다중 자모는 동시치기 같은 것과는 전혀 다른 개념이므로 그런 것과는 절대로 혼동하지 말라.

그런데 디폴트인 H3은 ‘초-중-종’을 순서대로 적용하는 반면, 여타 다중 자모는 ‘중-종’만 적용 후 음절을 끊고 다음 글자 초성을 또 입력시키거나 ‘종’만 적용 후 ‘초-중’은 다음 글자로 넘긴다. 세벌식은 음절 경계와 관련된 변칙적인 처리가 없으니 이런 다중 자모까지도 생각할 수 있는 반면, 두벌식은 다중 자모까지는 갈 수 없고 음절 경계 처리에만 치중한 파생 타입만을 생각할 수 있는 셈이다.

‘두벌식 종성’ 타입으로 입력된 종성은 도깨비불 현상이나 결합 실패로 인해 다음 글자로 넘어갈 때 초성으로 바뀌는 게 아니라 종성이 그대로 유지된다. 그리고 그 상태에서 중성을 입력하더라도 종성은 초성으로 바뀌지 않고 종성 상태로 그대로 보존된다.

이 타입을 쓰면 두벌식으로도 자음을 배당할 때, 골치 아픈 수식을 쓸 필요 없이 언제나 마치 세벌식처럼 H2J|_G라고 언제나 종성 형태만 넘겨 주면 끝이다. 다만, <날개셋> 편집기처럼 초-중-종성의 형태를 완벽하게 보존하는 한글 글꼴 체계에서는 처음에 초성을 입력했는데 초성이 아니라 종성이 나타나기 때문에 마치 도깨비불 현상만큼이나 보기가 어색할 것이다.

이 어색함은 표준 한글 자모를 호환용 한글 자모로 치환해서 표시해야 덜해진다. 즉, 애초에 초성과 종성의 구분이 없는 글자판은 역시나 초성과 종성의 구분이 없는 글자 코드와 글꼴을 동반해야 자연스럽다는 뜻. 실제로는 한글의 구성 원리를 어기고 전혀 자연스럽지 않은 처리가 추가로 행해지는 셈이다. 오버헤드는 ‘세벌식 < 기존 세벌식 관점에서 추가로 구현된 두벌식 < 새로 도입된 종성 지향 두벌식’의 순으로 많아진다.

H2J 타입을 쓰면 <날개셋> 한글 입력기로도 MS IME의 두벌식과 완전히 동일하게 동작하는 입력 방식을 구현할 수 있다. 사실 내 프로그램은 세벌식 자판과 관련된 응용 기능들은 거의 1.x 시절부터 제공해 온 반면, 두벌식을 두벌식답게 지원하는 편의 기능들은 훨씬 나중에 도입되어 왔다. 특수 도깨비불 규칙(3.9부터)이라든가, 초-종성 공유 낱자 결합 규칙(6.0)에 이어, 종성 지향 두벌식(6.7)의 순이다.

알면 별로 어려울 것 없는 내용인데 이 글 내용을 제대로 이해한 분이 얼마나 되려나 모르겠다. <날개셋> 한글 입력기는 올해로 개발 12주년이고 무려 7.0을 바라보는 시점인데 아직도 한글 입력의 본질과 관련된 새로운 기능이 추가되고 향상된 게 있다는 게 내게는 무척 흥미롭고 의미심장하게 느껴진다.

Posted by 사무엘

2012/08/08 08:20 2012/08/08 08:20
, , , ,
Response
No Trackback , 6 Comments
RSS :
http://moogi.new21.org/tc/rss/response/717

1.

<날개셋> 한글 입력기는 잘 알다시피 글쇠배열 수준을 넘어서 한글 조합 로직을 완전히 외부에 expose하고 사용자가 이를 입력 옵션의 일부로서 마음대로 고칠 수 있는 유일한 한글 입력 프로그램이다.

한글 조합 로직은 전산학에서 오토마타라고 불리는 '정규 문법'(regular grammar)으로 흔히 모델링되며, 보통은 그 알고리즘이 해당 한글 입력 프로그램의 소스 코드 내부에 복잡한 switch문의 형태로 하드코딩되어 있다. 그러나 <날개셋> 한글 입력기는 그렇지 않으며, 아예 C언어 수식의 문법 형태로 오토마타를 사용자가 일일이 지정이 가능하다.

정규 문법은 옛날에 1996년도 한국 정보 올림피아드 경시부(본인이 그 시절에 정올 공부를 한 세대여서.. ^^)에서 출제되었던 잠수함 코드 식별 문제와 같은 차원의 난이도이다. 주어진 규칙대로 상태를 쭉쭉 switch해 나가다가 코드가 yes로 끝나면 잠수함이고, 그렇지 않으면 noise이다. 한글 입력 오토마타도 그런 수준이라는 뜻이다.

첨언하자면, 이것보다 한 단계 더 복잡한 차원의 문법은 그 이름도 유명한 문맥 자유 문법(CFG)이다. 이제는 다단계의 여닫는 식별 부호를 재귀적으로 처리할 정도가 되어야 하고, 제대로 파싱하기 위해서는 스택이 필요하다. 여기서 스택은 한글 입력 순서를 기억하는 그런 스택이 아니라, 각 재귀 단계별 상태를 기억하기 위한 스택이다. 정규 문법이 Windows의 INI 파일 정도의 복잡도라면, 문맥 자유 문법은 XML 정도 된다고 보면 된다.

전산학 전공자라면 데이터 구조 시간에 복잡한 괄호와 연산자가 들어간 수식을 처리하는 프로그램을 만든 적이 있을 텐데, 그게 바로 간단한 문맥 자유 문법을 인식하는 프로그램을 구현해 본 것이다. 그러나 한글은 초-중-종성으로만 구성되지 '초성-여는 중성-종성-닫는 중성'이라든가, '여는 초성-중성-여는 종성-닫는 종성-닫는 초성' 처럼 글자 자체가 재귀적으로 이상하게 전개되는 형태는 아니므로, CFG가 아닌 정규 문법만으로 표현이 충분히 가능하다.

사람이 다루는 자연어든, 컴파일러가 다루는 프로그래밍 언어 소스가 아니어도, 컴퓨터라는 계산 기계가 인식과 생성과 처리 가능한 모든 파일 포맷은 결국 이런 문법으로 formal하게 생성 규칙을 나타낼 수 있으며 그럴 수밖에 없다. 텍스트 파일이든, 그래픽 포맷이든, 심지어 기계어 코드의 포맷이든 말이다. 그래서 오토마타 이론은 전산학에서 매우 중요하게 다루어진다.

2.

다시 본론으로 돌아와 한글 입력기 얘기를 계속하겠다.
한글 입력기도 구현체가 제각각이기 때문에 프로그램마다 동작 방식이 대동소이한 차이가 있었다. 예를 들어 “중성+종성 형태의 미완성 한글의 입력이 가능한가? 그리고 세벌식의 경우 초성+종성 미완성 한글도 입력 가능한가?” 하는 것 말이다. 오토마타는 바로 이런 세밀한 로직을 바꿀 수 있다.

아래아한글은 도스용 3.x까지만 해도 그런 게 가능하지 않다가 윈도우용으로 넘어오면서 어느 샌가 미완성 한글의 표현이 가능해졌으며, 특히 97 때는 전무후무하게 초-종-중 순의 입력도 가능해서 아주 초보적인 형태의 모아치기까지 지원했었다. 그게 워디안 이후부터는 다시 없어졌지만 말이다.

<날개셋> 한글 입력기는 그런 것들을 구분하기 위해서 일반적인 이어치기 오토마타뿐만이 아니라 미완성 한글의 입력을 불허하는 오토마타도 따로 갖추고 있다.
PC 환경이 도스에서 윈도우로 넘어가면서 한글 코드의 주류도 조합형에서 완성형으로 넘어갔다. 완성형은 구조적으로 낱자의 초성과 종성을 구분하는 게 불가능하고 미완성 한글도 표현할 수 없기 때문에, 한글 입력 오토마타도 그에 맞춰서 설계되는 게 불가피했다.

그런데 맥 OS가 제공하는 한글 입력기는 동작 방식이 흥미롭다. 두벌식은 별 차이가 없는데 MS의 한글 입력기와 큰 차이를 보이는 부분은 세벌식이다.
오토마타가 '미완성 한글을 허용 안 하는 이어치기'의 변종이다. 초성과 중성의 단독 입력은 허용하지만, 종성 단독이나 여타 미완성 한글의 입력은 아예 무시하여 허용하지 않는다. 또한 받침 ㄲ, ㅆ은 ㄱ, ㅅ의 연타로 입력을 못 하고 반드시 한 타로만 쳐야 한다.

입력 무시는 <날개셋> 한글 입력기의 오토마타에서 -1이라는 음수 상태로 정의되어 있으므로 이런 입력 로직도 <날개셋> 한글 입력기로 어렵지 않게 구현할 수 있다.

0 → A ? 1 : B ? 3 : C ? -1 : 0
1 → A ? 1 : B ? 2 : C ? -1 : 0
2 → B ? 2 : C ? 4 : 0
3 → B ? 3 : C ? -1 : 0
4 → C ? 4 : A|B ? 0 : -1

초기 상태에서는 종성 C만 -1로 빠지게 하여 무시하면 된다. 그리고 초성이 입력된 상태인 1번 상태에서도 C만 무시하면 된다.
초성과 중성이 모두 입력된 2번 상태에서만 종성의 입력이 허용되며, 이 경우 오토마타는 4번 상태로 가게 된다.
중성만 단독으로 입력된 상태인 3번에서도 중성만 동일 상태로 받아들이면 되고 종성은 여전히 무시한다. (C ? -1: 0)

끝으로 문제가 되는 건 초-중-종성이 모두 입력된 4번 상태이다. 받침 ㄴ+ㅎ=ㄶ 같은 결합은 계속 허용해야 하지만 더 결합할 수 없는 받침은 입력을 무시해야 한다. 그리고 초성과 중성은 다음 글자로 입력을 받아들인다. 이 상태를 어떻게 표현하면 좋을까?

<날개셋> 한글 입력기는 오토마타로부터 양수 상태값을 얻어서 결합 가능 승인은 받았지만 실제로는 낱자 결합 규칙이 존재하지 않아서 추가 결합이 불가능해진 낱자가 발견될 경우, 성분 변수 A~C에다가 모두 0을 집어넣어서 해당 상태에 대한 오토마타 함수값을 다시 구한다. 그렇기 때문에 C에 값이 있을 때는 일단 4번 상태를 계속 유지하게 하되, 초성이나 중성에 값이 있으면(A|B) 다음 글자로 넘어가서 조합을 진행하게 하고(0), 진짜로 세 변수가 모두 0일 때만 -1로 조합을 무시하게 하면 된다.

요컨대 초성과 중성만 단독 입력이 가능하고 정확하게 초-중-종 순서를 따르지 않은 unexpected 종성은 입력을 무시하게 한 오토마타인데, 이것도 좀 오래 써 보니 오타 방지 차원에서는 나쁘지 않은 것 같다.

3.

이제 오토마타 얘기 말고 다른 기술적인 얘기로 넘어가겠다.
맥 사용자라면 이미 충분히 아시겠지만, 매킨토시 컴퓨터는 별도의 한/영이나 한자 키가 없기 때문에 한/영 전환이 cmd+space이고, 한자 변환은 opt(alt)+enter이다.

다만 약간 불편한 점은, 두벌식이든 세벌식이든 겹받침을 입력하는 방법이 없다는 것이다. 두벌식에서 ㄱ+ㅅ을 누르면 둘은 따로 떨어지며, 세벌식은 아예 겹받침 단독 입력이 불가능하기 때문이다.

초성+한자로 특수문자를 입력하는 기능도 맥에는 없다. 일반 PC에서는 그야말로 도스 시절에서부터 존재한 오랜 전통임에도 불구하고, 맥은 그런 것의 영향을 지금까지 전혀 받지 않은 채 지내 왔다니 놀라울 따름이다. 전/반각 모드 같은 것도 맥에서는 찾을 수 없다.

윈도우에서는 두벌식/세벌식이 한 한글 IME 내부에서의 설정치로 존재해 왔지만 맥은 각각의 벌식이 마치 영문 쿼티/드보락처럼 별개의 입력 방식으로 다뤄진다. 어찌 보면 이게 더 직관적인 디자인인 건지도 모르겠다. 그래서 입력 환경 설정 대화상자에는 글자판을 선택하는 옵션은 없으며 backspace 키의 동작 방식 같은 것만 있다.

Windows는 95 이래로 조합 중인 한글을 깜빡이는 네모 커서로 나타내는 관행을 도스 시절 프로그램으로부터 확실하게 도입하여 정착시켰다. 이 당연한 관행이 3.1때까지만 해도 없었기 때문에, 한글을 조합 중일 때 커서는 그냥 해당 한글의 앞에 똑같은 길쭉한 형태로만 보였다. 당시 윈도우 3.x용 MS 워드 6.0이 예외적으로 IME를 자체 처리하여 네모 커서를 자체 구현하던 수준이었다.

그에 반해 맥은 조합 중인 한글을 그냥 일본어나 중국어의 조합을 표시하듯이 밑줄로 처리한다. 즉, 맥에서는 깜빡이는 네모 커서를 볼 일이 없다는 뜻. 사실, 깜빡이는 네모 커서는 도스 시절 이래로 오랫동안 봐 왔기 때문에 심리적으로 편하기는 하지만, 한글 조합을 두 글자 이상의 길이로 표현하는 가능성을 차단했다는 큰 제약도 존재한다.

그래서 MS 운영체제에서는 전통적으로 한글 조합을 단어 단위로 잡는 기능이 존재한 적이 없다. 한자 입력할 때를 빼면 사실 전/반각만큼이나 별로 필요하지도 않은 것도 사실이긴 하지만 말이다. 그 반면 맥에는 그 옵션이 있다.

이런 점들을 감안하면, 한글 입력 하나를 두고도 맥과 윈도우는 문화가 상당히 다름을 알 수 있다. 차이는 이것으로 그치지 않는다. 오류가 없는 100% 정확한 세벌식 최종 글자판이 윈도우에서는 무려 비스타와 오피스 2007 타임라인에 와서야 겨우 제공된 반면, 맥에서는 공 박사님의 영향력 덕분인지 그야말로 OS X도 아니고 20세기 클래식 시절부터 당연히 기본 제공되어 왔음도 감안할 필요가 있다.

Posted by 사무엘

2012/07/20 19:21 2012/07/20 19:21
, , , , ,
Response
No Trackback , 3 Comments
RSS :
http://moogi.new21.org/tc/rss/response/709

※ <날개셋> 한글 입력기의 개발자가 알기 쉽게 요약한 우리나라 한글 기계화의 간략한 역사이다.

실용성을 떠나서 어떻게든 모아쓰기 형태의 한글을 찍을 수 있는 타자 기계를 완전히 최초로 만든 사람은 재미 교포 이 원익(1914)이다. 이건 세로쓰기 형태였다.
그 후 1949년에 잘 알다시피 공 병우가 최초의 세벌식 쌍초점 타자기를 발명하고,
1958년에는 김 동훈이 다섯벌식(자음 2, 모음 2, 받침 1) 타자기를 발명했다.

사용자 삽입 이미지사용자 삽입 이미지

동일한 정사각형 공간에 한글을 모아쓰기 형태로 보기 좋게 찍으려면 잘 알다시피 한글 자모의 벌수가 많아져야 한다. 그러나 벌수가 많아질수록 기계 구조가 복잡해지고 치기가 어려워지는 등 타자 능률에는 여러 모로 애로사항이 꽃핀다.

공 병우는 미려한 자형을 과감히 포기하고, 자형은 그냥 알아볼 수만 있는 정도의 빨랫줄 샘물체 형태로 찍히지만 타자 능률 하나는 정말 기가 막히게 좋은 한쪽 극단을 선택하여, 세벌식이라는 글쇠배열 이념을 고안했다. 이때가 이분이 환자의 안과 진료까지 때려치우고 기계 덕질을 하던 시절이다.

세벌식은 외형만 약간 희생하면, 굳이 풀어쓰기까지 안 가고도 한글 역시 영문 뺨칠 정도로 기계로 편하게 칠 수 있는 문자라는 걸 최초로 입증해 보였다. 구조가 간단한 덕분에 한영 겸용 타자기까지 만들 수 있었다.

사용자 삽입 이미지

처음에는 왼손에서 오른손으로 흐르는 배열을 생각했는데, 왼쪽에서 오른쪽으로 종이가 진행되는데 글쇠가 엉키는 현상을 방지하기 위해 지금과 같이 오른손에서 왼손으로 흐르는 배열을 선택하게 되었다고 공 박사 자서전을 찾아보면 나온다. 기계식 타자기를 배제한다면 어느 방향이 더 좋을지에 대한 견해는 여전히 떡밥인 듯하다. R2L은 오른손잡이의 손에 유리한 반면, L2R은 시각적으로 무척 직관적이라는 장점이 있으니 말이다.

이렇게 세벌식 타자기는 성능이 좋은 덕분에, 닥치고 능률이 짱인 군대에서 아주 환영받았다. 뭐, 군대에서도 백 선엽 장군처럼 한글 기계화에 대한 관념이 없이, 여전히 세월아 네월아 한자를 섞어서 손으로 쓴 문서를 좋아하는 지휘관도 없지는 않았지만 말이다.
다만, 세벌식 타자기는 글자 모양이 심하게 보기 안 좋고 이질감이 심했던지라, 민간에서는 김 동훈 다섯벌식도 여전히 공존하여 쓰였다.

기계식 타자기는 몇 벌식으로 만드느냐에 따라서 기계 구조가 완전히 달라져야 했다. 구조가 상이한 한글 타자기가 공존한다는 것은 사회 비용을 증가시키고 손실이 이만저만이 아니었기에 국가가 나서서 통일안을 만들었다.

그래서 다섯벌식과 세벌식을 절충한답시고 1969년 6월에 과학기술처가 내놓은 게 네벌식이다. 개그 만화 일화 씰 사장님의 표현을 빌리자면...

“그래서 너희들은 새로운 글자판을 제정했다. 그것이 이것과 이것과 이것의 네벌식이다.
팔릴까보냐! 세벌식의 능률도, 다섯벌식의 자형도 어느 것 하나 제대로 못 살린 글자판이 되어 버렸지 않나! 더 이상해! 게다가 왜 공청회 없이 졸속으로 후다닥 만든 거냐! 누가 고안한 거냐, 제정 위원들은 글자판 전문가이긴 하냐? 대체 누구냐!”

사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
뭐 이랬다.
과거 영국에서는 비숍 성경과 제네바 성경을 통합하는 킹 제임스 성경 표준안이 아주 훌륭하게 정착하였지만, 한국의 타자기 글자판 표준화는 해피엔딩이 되지 못했다.

허나 그때는 때가 박통 시절인지라 표준화는 불도저 식으로 추진되었다. 비표준이 된 세벌식과 다섯벌식은 모두 상당히 무식한 정치적 탄압을 받으면서 시장에서 씨가 마르고 말았다.
세벌식 지지자들이 이를 가는 대목이다. 오늘날 세벌식이 대부분의 사람들에게 듣보잡 글자판으로 전락해 버린 가장 큰 계기가 이것이기 때문이다. 이것으로 시즌 1은 종료.

시즌 2는 컴퓨터와 함께 시작되었다.
1970년대 후반엔 몇몇 선구자들을 중심으로 Apple II PC가 국내에 도입되었으며, 이에 타자기가 아닌 컴퓨터용 한글 입력 방식의 필요성이 논의되었다. 공 병우 박사 역시 당당한 Apple II 사용자였으며 그 후로도 매킨토시만을 애용하였다(오옷.. 1세대 앱등이).

컴퓨터는 전자식으로 동작하니 기계식 타자기를 만들 때와는 달리 여러 벌의 한글 자모를 갖추지 않아도 된다. 영문 글자판과 잘 어울리게 한글 자모를 하나씩만 곱게 집어넣으면 된다.

그 당시의 국내의 컴퓨터 전문가들은 한글을 어떻게 입력하면 좋을지, 한글이 조합 중일 때 시각적인 화면 피드백은 어떻게 만들면 좋을지 같은 것을 면밀히 연구하였고 중국이나 일본에서는 자국 문자 입력을 어떻게 하는지도 적극 벤치마킹했다.

지금은 당연한 개념으로 여겨지고 있지만 오늘날의 컴퓨터용 두벌식 한글 입력 오토마타의 이론적 근간을 처음으로 마련한 분은 KAIST 전산학과의 최 광무 교수이다. 그분의 1978년도 석사 학위 논문 <한글 모아쓰기에 관한 연구>의 요지가 이것이다. “자음과 모음 한 벌씩, 그리고 쌍자음은 Shift로 한 타 만에 바로 입력하게 하면 음절 경계 모호성이 없이 모아 쓴 한글의 연속 입력이 가능하다”는 것.

그렇잖아도 과학기술처는 KAIST에 용역을 주어 컴퓨터용 한글 글자판을 고안하게 했고, 그래서 1982년엔 최 교수의 사상을 기반으로 하여 오늘날의 KS X 5002 두벌식 글쇠배열이 표준으로 자리잡았다. 그냥 자음 모음만 아무 생각 없이 한 벌씩 배치하면, 요즘 천지인 같은 일부 모바일 한글 입력 방식이 그러하듯이 음절 경계 모호성이 존재하게 된다.

이 두벌식 배열은 타자기용 네벌식 배열보다야 구조가 훨씬 더 간단하고 배우기 쉬웠다. 왼손은 자음이나 오른손은 모음이니 언뜻 보기에 얼마나 직관적인가? 숫자와 기호가 영문 글자판과 완전히 일치하며, 딱 알파벳 26개 자리에만 한글 자모가 들어있다.

하지만 초중종성 세 벌로 이뤄진 문자를 두 벌의 글자판만으로 치려다 보니 필연적으로 타자 도중에 원하지 않는 글자가 생기는 도깨비불 현상을 피할 수 없었고, 또 타자기와 컴퓨터의 치는 방식이 서로 다르다는 큰 문제도 있었다. 예전에는 타자기에서 세벌식과 다섯벌식 때문에 사용자가 헷갈렸다면 이제는 타자기의 네벌식과 컴퓨터의 두벌식 때문에 혼동이 생긴 것이다.

이 때문에 5공 시절이던 1983년에는 타자기용 네벌식 글자판이 공식적으로 폐기되었고 역사 속으로 사라졌다. 네벌식을 웬수처럼 여기고 있던 세벌식 진영의 사람들도 이 순간만은 기뻐했다. 이제는 표준 글자판이 좀 개선되려나?

그러나 현실은 나아진 게 없었다. 컴퓨터용 글자판은 변함없이 두벌식이고, 타자기는 새로운 후속 표준이 정식으로 제정되는 게 없이 그냥 컴퓨터처럼 어중간한 두벌식으로 바뀌어 버렸다. 타자기에는 컴퓨터 같은 한글 입력 오토마타 장치가 없으니 그 대신 새로 무엇이 추가되었냐 하면 '받침' 키 신공이다. 여기서 또 씰 사장님의 절규 추가.

“그래서 너희들이 새로 만든 것이 이것과 이것과 이것의 두벌식 타자기이다.
무섭다구! 받침을 입력할 때마다 Shift를 눌러야 하는 기형 타자기를 도대체 누가 쓴단 말이냐! 이 기계로 타자를 해야 하는 타자수의 얼굴이 기분 나빠!”

사용자 삽입 이미지
아마 그 당시 높으신 분들은, 어차피 글자판은 이 지경이 돼 버렸고 이제 대세는 타자기에서 컴퓨터로 넘어가고 있으니 타자기는 이 참에 완전히 손을 놔 버린 모양이다. 그래서 실제로 한글 타자기는 컴퓨터와 비교했을 때 단순히 기계적인 기능의 차이 때문이 아니라, 글자판과 입력 방식 차원에서의 원론적이고 구조적인 차이로 인해 컴퓨터의 적수가 될 수 없어서 급속도로 몰락하고 말았다. 이것으로 시즌 2 종료.

오늘날 컴퓨터에서는 표준이 된 두벌식, 그리고 한글 구성 원리와 일치하는 세벌식만이 남아 있고 그보다 더 복잡한 벌수의 입력 방식은 완전히 역사 속으로 사라져 있다. 세벌식은 도깨비불 현상이 없고 타자 능률이 매우 좋다는 점, 그리고 기계간의 글자판 통일이 가능하다는 점이 두벌식이 흉내도 낼 수 없는 압도적인 장점이기 때문에, 한글이 남아 있는 한 절대로 없어지지는 않을 것이다. 비록 글쇠 수가 좀 많고 기호가 영문 자판과 다른 게 단점이긴 하지만 말이다.

하지만 처음부터 타자기와 컴퓨터가 모두 속 시원하게 똑같이 세벌식으로 갔으면 글자판 통일은 진작에 이뤄졌을 것이며, 타자기도 온갖 n벌식 입력 방식에 이리 저리 휘둘리다가 망하는 일이 없었을 것이다. 타자기도 자기가 할 수 있는 본분은 다 수행하면서 실제보다 더욱 늦게 현역에서 물러났을 것이다.

참으로 아쉬운 대목이 아닐 수 없다. 세상에 기계식 타자기로 저 정도로 칠 수 있는 문자가 라틴 알파벳 계열을 빼고 전세계에 얼마나 될까? 그런데도 고작 네모 글꼴 하나 건지려고 벌수 놀이를 한 것치고는 감수해야 한 사회적 손실과 치러야 한 대가가 너무 컸다. 기술이 발달하면 세벌식 타자기의 빨랫줄 모양 글꼴도 그 방향을 유지하면서 얼마든지 더 미려하게 개선할 수 있었을 텐데 말이다.

세벌식이 확고하게 타자기와 PC의 주 입력 방식으로 자리잡았다면, 두벌식은 세벌식을 적용하기에는 글쇠 수가 충분치 않고, 어차피 기계식 타자기와의 연결 고리가 없으며 장시간 빠르게 입력을 할 필요도 없는 기기를 위한 제한적이고 예외적인 변칙 입력 방식으로 추후에 논의되게 되었을 것이다.

요 얼마 전엔 드디어 모바일용 한글 입력 방식으로 천지인과 이지한글(나랏글), SKY 세 종류가 복수 표준으로 지정되었다. 기계식 타자기의 글쇠배열과는 상황이 달라도 너무 다르다. 어차피 한글 입력은 소프트웨어적으로 처리되기 때문에 무슨 입력 방식을 심든 물리적인 비용이 드는 게 없으며, 어차피 어느 입력 방식이든 두벌식 안에서 그 나물에 그 밥이기 때문에 성능 격차도 예전 같지 않다. 그러니 그냥 압도적으로 많이 쓰이는 기존 입력 방식 몇 개만을 그대로 인정해 주는 것만으로도 충분했다.

요즘은 한글날도 20여 년 만에 다시 공휴일로 되돌리려는 움직임이 있는데, 세벌식의 표준화에 “too late”는 있을 수 없다고 본다. 장기적으로는 390과 최종을 통합하는 글쇠배열이 있어야 할 것이고, 표준화는 언제든지 논의되어야 한다. 다시 강조하지만 한글은 두벌식으로만 쓰기엔 너무 아까운 문자이고, 세벌식의 압도적이고 상징적인 장점은 절대로 없어지거나 희석되지 않을 것이기 때문이다..

여담이다만, 아마 공 병우 박사님이 2010년대까지 살아 계셨다면, 맨날 아이폰으로 트위터 하면서 한글날 공휴일 지정과 세벌식 표준화를 주장하는 트윗을 남기고 젊은이들과 얘기를 나누셨을 것 같다. 비록 타자기/PC에서만치 세벌식을 강경하게 주장하지는 않을지라도 모바일용 한글 입력 방식을 연구하는 건 당연지사이고..;;

사용자 삽입 이미지
공 병우 박사(1907~1995). 안과 의사에다 불세출의 한글 공학자까지 인증..;; 하나만 제대로 하기도 무진장 힘들 텐데, 머리가 너무 좋고 시대를 너무 앞서갔던 분이다..;;

Posted by 사무엘

2012/07/15 08:29 2012/07/15 08:29
, , , , , ,
Response
No Trackback , 12 Comments
RSS :
http://moogi.new21.org/tc/rss/response/707

<날개셋> 한글 입력기의 개발자가 심층 분석한 MS 한글 IME 리포트.
버그를 나열하기 전에 먼저 독자의 이해를 돕기 위한 기술 설명부터 하겠다.

A. MS IME의 두벌식과 세벌식의 구현 차이 -- 오토마타

일단 좋은 말부터 꺼내자면, MS 한글 IME는 현존하는 한글 입력기들 중, 어떤 의미에서는 기본에 충실하게 가장 FM대로 만들어져 있다. 두벌식과 세벌식의 로직이 서로 확고하게 분리되어 있으며 구조가 완전히 다르다. 그리고 MS 버전의 두벌식 한글 입력기는 전산학적으로 볼 때 진정한 두벌식의 고증에 가장 충실하게 만들어져 있다.

무슨 말이냐 하면, 자음이라면 초성을 조합할 때와 종성을 조합할 때의 조합 규칙에 차이가 없다. 그래서 초성이 입력되는 상태에서도 ㄶ, ㄳ 같은 겹받침을 바로 입력할 수 있는 반면, ㄲ, ㅆ 같은 쌍자음은 연타가 아니라 반드시 Shift로만 입력할 수 있다. 이 동작 방식은 내가 알기로 윈도우 95 시절 이래로 시종일관 변함 없다.

<날개셋> 한글 입력기나 아래아한글의 두벌식 입력기는 그렇지 않다. 도깨비불 현상만 추가되었을 뿐 세벌식의 사고방식으로 두벌식을 덤으로 구현한 형태에 가깝다. <날개셋>의 경우, 이 점을 감안하여 지난 6.0 버전에서 초-종성 공유 낱자 결합 규칙이라는 개념이 추가되었으며, 이를 사용하면 두벌식 입력 방식을 좀 더 두벌식스러운 사고방식으로 설정할 수 있다.

뭐, 아래아한글도 1980년대 말에 1.0이 처음 개발되었을 때는 개발자들이 세벌식이 정확하게 뭔지 몰라서 자음만 한 벌 더 있을 뿐 여전히 도깨비불 현상이 존재하는 형태로 만들었다가, 고 공 병우 박사에게서 지적 받고 고쳤다는 일화가 전해지긴 한다만.

B. MS IME의 두벌식과 세벌식의 구현 차이 -- 글쇠 인식

표준 두벌식 글자판은 A부터 Z까지 딱 알파벳 글쇠 26개에만 한글이 배당되어 있고 나머지 글자들은 영문과 완전히 똑같다. 그렇기 때문에 MS 한글 IME는 두벌식일 때는 알파벳 글쇠만 가로채어 사용하며, 숫자, 기호, 공백 글쇠는 처리하지 않고 응용 프로그램으로 그대로 넘겨 준다.

세벌식은 그렇지 않다. 몇 가지 영문과 일치하는 기호가 있긴 하지만 일반적으로 공 병우 세벌식은 4단까지 독자적으로 사용하고 숫자와 기호 영역까지 침범한다. 그래서 MS IME는 세벌식에 대해서는 아예 공백까지 포함한 48개 글쇠 자리를 모두 가로채어 동작한다. <날개셋> 한글 입력기는 가로챌 글쇠 영역 자체를 필요에 따라 정밀하게 제어하는 옵션을 아주 최근의 6.5 버전에서야 추가했다.

이렇게 두 글자판의 구현이 제각각 따로라는 점 자체는 나쁘지 않다. 그러나 이는 MS IME에 두벌식을 쓸 때는 괜찮은데 세벌식을 쓸 때만 자잘한 버그가 존재하는 빌미를 제공하고 있다. 역사적으로 볼 때, 이런 버그는 더럽게 안 고쳐진다는 특징도 있었다. 두벌식과 세벌식의 넘사벽 급의 인지도 차이 때문이다.

10년도 더 전에 포트리스라는 대포 쏘기 게임이 인기였을 때, 세벌식으로는 한글 모드에서 Space로 대포 쏘기가 안 되어 채팅과 게임을 같이 하기가 불편하다는 이슈가 있었다. 두벌식에서는 Space가 응용 프로그램이 직접 접수한 공백이지만, 세벌식에서는 Space가 직접 오는 게 아니라, 한글 IME가 가공을 하고 보내 준 공백이라는 완성된 문자열이 오기 때문이다.

C. 윈도우 7에서의 변화

자, 앞에서 다룬 건 MS 한글 IME의 두벌/세벌 메커니즘의 차이이고, 지금 하는 얘기는 운영체제의 버전에 따른 디테일의 변화 쪽이다.

16비트 윈도우 시절에는 운영체제에 유니코드도, 국제화(I18N)도, 지역화(L10N)도 없었다. 동일 제품을 한중일 나라의 문자를 입출력할 수 있게 개량하는 것은 MS의 각 지사에서 완전히 독자 기술을 사용해서 알아서 재량껏 해야 했다.

그러다가 윈도우 95/NT4가 되면서 글꼴 쪽도 획기적으로 발전하고(내장 비트맵, 트루타입 컬렉션 등), 입력기 쪽도 한중일 통합 IME 프로토콜이 처음으로 제정되었다. 그리고 입력기 프로그램은 EXE가 아니라 여타 운영체제에서 유례를 찾기 힘든 독특한 형태인 DLL이 되었다. 그래서 윈도우만 입력기의 한영 상태가 각 프로그램별로(정확히는 스레드별로) 완전히 따로 놀지, 공유가 되지 않는다.

윈도우 2000부터는 추가 글꼴과 코드 페이지 데이터만 설치해 주면 세계 어느 나라 윈도우에서도 아무 나라 언어의 입력기를 설치할 수 있게 되었고, 윈도우 XP부터는 고급 텍스트 서비스라고 불리는 일명 TSF 기술이 도입되었다. 윈도우 비스타부터는 이제 전세계 언어의 입력기와 글꼴이 추가 설치를 할 필요도 없이 기본으로 제공되며, TSF 프로토콜이 주류가 되고 기존 IME 프로토콜은 호환성 계층을 통해서나 제공된다.

이로써 비스타에서 문자 입력 방식의 그랜드 슬램이 달성되고 해피엔딩이 된 것 같은데, 윈도우 7에 와서는 기능이 추가된 건 없으면서 뭘 또 잘못 건드렸는지 문자 입력 쪽의 안정성이 전반적으로 하락했다. MS 한글 IME만의 버그인 것도 있고 운영체제 자체의 버그인 것도 있다. 이 글에서는 지금까지 언급한 A~C를 염두에 두고, 2012년 현재 MS 한글 IME에 존재하는 것으로 알려진 버그들을 정리해 보았다.

1. 세벌식 최종 + 전각문자

맥 OS는 공 병우 박사(이분이 요즘 같았으면 전형적인 앱등이이셨다ㅋㅋㅋ)의 텃새 덕분에 전통적으로 세벌식 최종이 강세였으며, 세벌식이라 하면 곧 최종 자판을 가리켰다. 그러나 PC 쪽은 도스 시절 이래로 390이 강세였기 때문에 세벌식이라 하면 곧 390을 가리켰다. 최종은 아래아한글조차 97에 와서야 제공하기 시작했을 정도로 인지도가 미미했다.

윈도우 95 때 처음으로 세벌식 최종 글쇠배열이 있긴 했지만 그런 인지도 부족으로 인해 틀린 배열이 굉장히 많았다. 그게 98에서 좀 바로잡히긴 했지만 여전히 오류가 있었고, 그 오류는 윈도우 XP/오피스 2003에 가기까지 고쳐지지 않았다.

비록 최종 글자판은 참고표와 가운뎃점처럼 1바이트 아스키 영역에 없는 글자가 있는 게 특이점이긴 했지만, 윈도우 98부터는 어차피 한글 IME의 모든 내부 자료구조가 유니코드로 바뀌었기 때문에 큰 문제가 되지 않았다. 구조가 그러하니 내가 파워업을 개발해서 패치도 가능했던 것이고.

윈도우 비스타 + MS 오피스 2007에 와서야 드디어 100% 정확한 세벌식 최종 글자판이 제공되기 시작했다. 2003년 중반에 내가 한국 MS를 방문해서 수정을 강력하게 요청했던 것도 아마 작용하지 않았겠나 생각해 본다. 비록 그 해 가을에 발표된 오피스 2003에서 바로 반영되지는 못했지만 말이다.

그런데, 이 사람들이 일을 깔끔하게 처리하지 못했다. 전각 모드에서는 참고표와 가운뎃점이 제대로 입력되지 않는다. 얘들은 아스키 문자가 아니니 라틴 문자처럼 일괄적으로 0xFEE0를 더해서는 안 되는데 그거 처리를 추가하지 않은 듯하다. 윈도우 7+오피스 2010에서까지 변함없다. 물론 한국에서는 전각 문자를 거의 쓰지 않으니, 이건 심각한 문제는 아니다.

참고로 한중일의 MS 오피스는 XP 버전부터 운영체제의 IME를 자기 것으로 패치하는 게 관행이 됐다. 일본어 IME는 운영체제의 것과 오피스의 것이 차이가 난다는 말도 있는 듯하지만, 한글 IME는 운영체제의 것이나 오피스의 것이나 차이가 거의 없음.

2. MS 워드 2007 이상에서 세벌식을 쓸 때만 나타나는 역상 현상

워드 2007 이상에서, 오피스 2007 이상 또는 윈도우 비스타 이상이 제공하는 한글 IME로 세벌식을 써서 한글과 숫자, 기호, 공백을 입력한다. 그 뒤에 IME를 날개셋이라든가 다른 일본어· 중국어 입력기로 바꾼 뒤 글자를 입력한다. 그러면 예전에 MS 한글 IME의 세벌식으로 입력했던 공백이나 숫자, 기호가 역상(검은 배경, 흰 글씨)으로 바뀐다!

사용자 삽입 이미지
굉장히 기괴한 버그이다. 이것은 워드에서만 나타난다는 점에서 워드의 문제이기도 하지만 세벌식으로 입력한 비한글 문자에 대해서만 나타난다는 점에서 MS IME의 문제이기도 하다. B에서 언급한 기술 차이를 생각해 보라.

이 역상은 문서의 내부 서식이 아니라, 문자의 중간 조합 상태를 표현하기 위해 문자 입력기가 임시로 부여하는 시각 효과이다. 일본어 입력 중에 나타나는 점선 밑줄 같은 것 말이다. 해당 문서를 저장한 뒤에 다시 불러오면 다행히 사라지긴 하지만, 그 상태에서 조치를 취하지 않으면 인쇄도 그대로 역상 모양으로 된다. -_-

더욱 기괴한 건, 오피스 2003 같은 예전 버전의 MS IME로는 세벌식을 쓰더라도 이런 현상이 발생하지 않는다는 점이다. MS 제품 자체의 버그가 확실하다. 윈도우 7/오피스 2010에서까지 고쳐지지 않았다.

3. 윈도우 7, 한글 입력 중에 바탕 화면을 클릭했을 때

윈도우 7에서 MS 워드 2007이나 2010을 실행하여 아무 한글 IME로나 한글을 입력한 상태로 있는다. 창을 최대화하지는 않은 채로 가령, ‘아’를 조합하고 있는다. 그리고 그 상태로 마우스로 바탕 화면을 클릭했다가, 다시 워드의 제목 표시줄을 클릭하여 돌아온다.

비스타에서는 동일한 절차를 수행하고 나면 ‘아’의 조합이 종료되어 커서가 ‘아’ 뒤에 가 있다. 그러나 7에서는 커서가 여전히 ‘아’를 조합하고 있지만 실질적으로는 조합이 끝난 상태이다. 받침 ㄴ을 입력하더라도 ‘안’이 되지 않고 ㄴ이 새로 조합된다.

윈도우 7은 한글 조합 중에 창의 포커스가 바뀌었을 때의 내부적인 처리가 갑자기 좀 이상하게 혹은 엄격하게 바뀌었다. 비스타나 XP 이전에는 아무 문제가 없던 게 7에서 갑자기 문제를 일으켜서 그에 대한 방어를 해야 했다. <날개셋> 한글 입력기도 과거의 5.51과 5.52 때 이와 관련된 버그 패치가 행해졌다.

4. 윈도우 7의 콘솔에서 세벌식으로 조합을 종료할 때 글자가 덧남

윈도우 XP/비스타에서는 해당사항 없고 7에서만 발생하는 구조적인 문제이다. 서비스 팩 1에서도 고쳐지지 않았다.
명령 프롬프트에서 세벌식 자판으로 한글을 입력하다가 온점이나 스페이스처럼 비한글 문자를 입력하면서 조합을 종료시키면, 조합 중이던 한글이 덧난다. 가령, ‘다.’를 입력하다 보면 ‘다다.’가 된다.

이건 꽤 황당하고 심각한 버그인데 왜 아직까지 안 고쳐졌는지 이해가 안 된다. 게다가 윈도우 7은 출시된 지 이제 무려 3년이 다 돼 가지 않는가.
왜 세벌식일 때만 그렇냐고? 이 역시 B에서 설명되었듯, 비한글 문자를 처리하는 방식이 두벌식과 세벌식이 다르기 때문이다. 문자 입력 프로그램이 아니라 운영체제의 구조적인 버그이기 때문에 윈도우 7에서는 MS IME든 날개셋이든 동일하게 발생한다.

5. IME 2010, 콘솔에서 한자 후보 목록이 곧바로 나타나지 않음

이것은 약간 불편할 수는 있지만 그렇게 심각한 문제는 아니다. 콘솔에서 한글을 조합하는 중에 한자 키를 눌러 보면, 원래 한자 후보가 콘솔 창의 하단에 곧바로 떠야 하는데 뜨지 않는다.
물론 이 상태에서도 번호를 누르면 해당 한자로 바로 변환이 되며, 좌우 화살표 같은 페이지 전환 키를 누르면 그제서야 후보 목록이 나타난다. 뭔가 코딩 실수가 들어간 듯하다.

이 버그는 윈도우 7의 기본 한글 입력기에서도 존재하지 않으며, 한글판 MS 오피스 2010과 함께 설치된 한글 IME 2010에서만 나타나는 문제이다. 즉, 운영체제의 것을 대체하는 오피스의 IME가 오히려 버그를 포함하고 있는 셈이다.
<날개셋> 한글 입력기에는 물론 이런 문제가 없다.

Posted by 사무엘

2012/06/24 08:34 2012/06/24 08:34
, , , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/699

세벌식 파워업 이야기

본인은 10여 년 전인 2000~2001년 사이에 세벌식 솔루션 3관왕-_-? 3총사를 차례로 최초로 개발하였다. 이 홈페이지 대문에 다 공개되어 있다.

하나는 주력 연구 작품인 <날개셋> 한글 입력기. 이건 사실 세벌식 글자판을 기본으로 삼아 한글 입력 체계에 대한 총체적인 연구를 목표로 하는 학술적인 프로그램이다. 이윤을 목표로 만드는 것도 아니고, 또 딱히 사용자 중심적으로 만드는 프로그램도 아니기 때문에, 여느 공개 소프트웨어에서는 찾을 수 없는 특이한 기능과 라이선스, 그리고 초심자가 언뜻 보기에 접근하기 어려워 보이는 복잡한 UI를 고수하고 있다.

뭐, 그래도 어쨌든 대부분의 일반 사용자들은 그냥 에디터가 하나 필요해서, 혹은 Shift+Space를 쓰거나 한글 로마자 글자판을 쓰려고, 혹은 세벌식 모아치기를 하려고, 또는 드보락 자판을 같이 쓰려고 이 프로그램을 사용한다. 하지만 그건 이 프로그램이 제공하는 기능의 완전 빙산일각일 뿐이다. 좀 외람된 비유이다만, 구원받아서 누리는 크리스천의 온갖 영적 복은 다 제끼고, 오로지 죽어서 지옥 안 가고 천당 가려고 예수 믿는 것과 비슷한 맥락이다. (엥?)

그리고 다음으로 잘 알다시피 타자연습 프로그램이 있다. 세벌식을 연습하려면 세벌식 사용자가 만든 세벌식에 최적화된 타자연습 프로그램이 있어야겠다는 생각을 해서 만들었다. 세벌식이 그냥 잉여 옵션이 아니라, 세벌식, 특히 최종 자판이 main인 프로그램.

사실, 아래아한글 워디안/2002가 리모델링된 한컴타자 유틸리티를 공개하기 전이던 2000년대 초엔, 세벌식 최종을 정식 지원하는 타자연습 프로그램은 박 정만 님이 개발한 '광타'밖에 없었다. 그리고 윈도우 운영체제와 아래아한글 97이 제공하던 최종 자판은 오류가 있었다. 그만치 최종 자판은 인지도가 안습하였다. 그런 와중에 세벌식 최종 전용 타자연습 프로그램인 <날개셋> 타자연습의 임팩트는 결코 작지 않았다.

타자연습은 잘 알다시피 한글 입력기의 한글 입출력 엔진을 빌려서 개발되었다. 비록 수 년 전부터는 입력기의 연구 개발에 밀려서 타자연습의 메이저 버전업이 중단된 상태이지만, 본인은 이 프로그램의 개발을 완전히 접거나 포기한 상태가 아니다. 껀수가 생기면 얼마든지 프로그램을 또 업데이트할 생각이다. 이 프로그램은 입력기보다는 훨씬 더 사용자 지향적으로 개발되고 있다.

다음으로 이 두 프로그램에 비해 인지도가 덜하고 <날개셋>이라는 브랜드도 붙어 있지 않으나, 또 아주 중요한 세벌식 솔루션이 마지막으로 있으니, 그것은 바로 세벌식 파워업이다.

세벌식 파워업은 세벌식과 관계가 있으나 <날개셋> 한글 입력기와는 무관한 프로그램이다. 이건 <날개셋> 없이 운영체제의 기본 IME만으로 세벌식을 쓰려는 사람에게 필요하다. 이 프로그램은 클릭 한 번으로 MS 기본 한글 IME의 두벌식/세벌식 설정을 간편하게 바꿔 준다. 이 외에도 화면에 세벌식 최종 글쇠배열을 띄워 놓는 기능과 한글 IME 제어판 설정을 바로 꺼내 주는 기능도 있어서 세벌식 사용자에게 무척 유용하다.

이 프로그램은 사실 <날개셋> 한글 입력기 1.0의 개발이 끝나고 정보 올림피아드도 끝났던 2000년 말에 처음으로 개발되었다. 레지스트리 설정을 바꿈으로써 윈도우 95/98/ME의 한글 IME를 대상으로는 잘 동작했으나, 2000에서는 동작하지 않았다. 하지만 이 기능만으로도 본인은 세벌식 사용자들에게서 칭찬과 감사의 말을 굉장히 많이 들었다.

그러다가 세벌식 파워업이 진짜로 ‘파워업’이 된 때는 2004년, <날개셋> 한글 입력기가 3.0으로 대폭 업그레이드된 그 시절이었다. 그때 두 가지 정말 큰일을 해냈다. 먼저 공유 메모리 패치 지점을 reverse engineering으로 찾아냄으로써, 드디어 2000/XP 등 모든 계열의 한글 IME에서 세벌식 자동 전환 기능을 동작시키는 데 성공했다. 그리고 다음으로, 당시 오류가 있던 MS 한글 IME의 세벌식 최종 글쇠배열을 아예 파일 차원에서 ‘패치’하는 엽기적인 기능을 추가했다!

그 당시는 <날개셋> 한글 입력기 3.0과 더불어 외부 모듈이 처음으로 개발되고 있었는데, 그러는 한편으로 MS IME 자체에 대한 연구도 진행되어, 그걸로 참고표와 가운뎃점을 찍는 방법을 찾아냈던 것이다. 이것 역시 <날개셋> 개발에 필적하는 쾌거였다.

파워업 프로그램이 마지막으로 큰 변화를 겪은 때는 그로부터 2년 반쯤 뒤에, 윈도우 비스타와 MS 오피스 2007이 나왔을 때이다. 이제야 정신을 차린 MS가 세벌식 최종 글쇠배열 오류를 고쳐 준 덕분에, 패치 기능은 이제 더 필요하지 않았다. 하지만 글자판 자동 전환 기능이 동작하려면 바뀐 메모리 변경 지점을 알아야 했기에, 그때는 VMware로 윈도우 비스타를 급히 설치하고, 아주 가벼운 개발툴인 비주얼 C++ 4.2 (무려 1996년 프로그램!)를 설치하여 그거 디버거를 이용해 메모리 변경 지점을 알아냈다.

윈도우 7/오피스 2010의 한글 IME는 윈도우 비스타/오피스 2007의 그것과 구조가 거의 같기 때문에 파워업의 추가적인 알고리즘 패치가 필요하지 않다. 하지만 파워업을 관리자 권한으로 실행하고 나면 한글 IME 설정 대화상자가 뜨지 않으며(그쪽에서 의도적으로 실행을 거부함), 관리자 권한으로 실행된 프로그램은 파워업의 글자판 전환 기능이 통하지 않는 문제가 있었다.
새로운 이슈가 발견된 셈인데, 글자판 전환 기능이 안 되던 문제는 최근에 다행히 간단한 조치 끝에 해결하여 패치를 등록하였다. 관심 있으신 분은 받아서 사용하기 바란다.

내가 왕년에 무슨 생각으로 무슨 똘끼를 발휘하여 이런 세벌식 솔루션을 세 종류나 만들어 버렸는지 모르겠다. 세벌식을 극도로 활용한 전문적인 한글 입력기, 그리고 세벌식 beginner를 위한 타자연습, 그리고 단순 세벌식 light user를 위한 파워업. 제각기 커버하는 영역이 있다!.

공교롭게도 이 세 프로그램은 유니코드 API를 지원하는 방식도 제각기 다 다르다. 입력기는 잘 알다시피 자체 제작한 호환 레이어가 있어서 유니코드 기반 바이너리로도 9x 계열 운영체제에서 동작 가능한 가장 정교하고 바람직한 구조로 되어 있다. 타자연습은 ANSI/유니코드 에디션이 제각각 빌드되어 있고, 파워업은 그냥 ANSI 빌드로만 배포된다. 한편, 64비트 바이너리가 따로 빌드되어 배포되고 있는 건 입력기가 유일하다.

본인은 이 프로그램들이 지난 10여 년 동안 세벌식의 보급에 큰 기여를 해 왔을 거라는 자부심을 갖고 있다. 고인드립이 될까 봐 조심스럽게 하는 말이지만, 공 병우 박사님이 5~10년 정도만 더 살아 계셨으면(1995년 타계) <날개셋> 한글 입력기가 개발되는 것도 보고 가셨을 텐데 하는 약간의 아쉬움도 있다.

내가 지금까지 왜 이런 짓을 했을까? 글쎄다. 딴 게 아니고 한글 같은 문자는 컴퓨터에서 두벌식으로만 쓰기에는 너무 아깝다는 막연한 관념이 있어서였다. 그리고 한글 기계화 이념에 관한 한은 세벌식만이 살 길이라는 강한 확신이 들어서이다. 그 생각은 10년 전이나 지금이나 변함이 없다. 좀 심하게 표현하자면 이렇게까지 말할 수 있다. “그 불편한 두벌식을 쓰면서 어떻게 한글이 우수한 문자라는 말을 할 수 있을까?”

지금은 세월이 흘러, 나의 감성을 건드리는 영역은 철도에게 자리를 많이 내 줬다. 세벌식 쪽은 그냥 워낙 오래 전부터 내가 전문적으로 연구해 온 분야이기 때문에 지금까지 그저 관성만으로 덕-_-력이 유지되고 있는 것도 있다.

그러나 세벌식은 그래도 너무 매력 있는 한글 글쇠배열이며, 동시에 한글 기계화의 근간을 이루는 교리이다. 요즘은 컴퓨터도 다들 멀티코어가 대세인데, 세벌식은 내가 예전에 글로 쓴 적이 있듯이 사람 손의 병렬화-_-에 유리한 방식이다. 이 글을 보시는 분들도 다들 이 기회에 세벌식으로 글자판을 바꿔 보시길 바란다. 터치스크린이 주류인 모바일에서는 세벌식은 동시치기를 통한 활로를 적극적으로 모색되어야 하지 않을까 싶다.

Posted by 사무엘

2012/02/14 08:16 2012/02/14 08:16
, , ,
Response
No Trackback , 11 Comments
RSS :
http://moogi.new21.org/tc/rss/response/641

My Programming Life

1.

<날개셋> 한글 입력기는 동일한 입력기 커널을 공유하는 세 개의 프런트 엔드가 있다.
그 중에서 가장 존재감 있는 터줏대감은 전용 에디터인 편집기이고, 실질적으로 가장 널리 이용되는 프로그램은 윈도우용 IME인 외부 모듈이다. 한편, 편집기처럼 실행되어 마치 IME처럼 동작하는 포인팅 장치 입력 유틸리티인 입력 패드도 지난 5.3 버전에서부터 추가되어 제 3의 프런트 엔드 구실을 하고 있다.

그 중 가장 먼저 만들어진 ‘편집기’는... 프로그램을 만든 본인부터가 에디터로서 아주 유용히 사용한다.
차라리 외부 모듈은 디버깅 할 때 외에는 사용하지 않는다. 운영체제의 기본 IME로 지정되어 있으면 파일을 고칠 수가 없어서 디버깅을 못 하기도 하기 때문이다.

<날개셋> 편집기는 어떤 점에서는 아주 답답하다. 가변폭 글꼴이 지원 안 되고 글씨 크기 조절도 안 되고, ClearType 렌더링이라든가 OpenType 스펙 등 오늘날의 모든 최신 타이포그래피 기술로부터 완벽하게 소외된 외딴 섬이기 때문이다.

그러나 한편으로 <날개셋> 편집기는 아주 작고 가벼우면서도 윈도우 95 이래 어떤 OS에서나 동일하게 유니코드 5.2 옛한글을 마음대로 조합할 수 있고 한글을 내 마음대로 다룰 수 있는 우리집 안방 같은 공간이다. 내가 만든 프로그램이어서 자화자찬 차원이 아니라 정말로 그렇다.
입력 기능뿐만 아니라 다양한 텍스트 필터도 있고, 한글을 자모 단위로 찾고 입력기에다 넘겨주는 글쇠를 붙여넣는 것 같은 아기자기한 기능도 있다. 도스 시절 추억의 도깨비 한글 비트맵 글꼴을 볼 수 있는 건 덤이다.

예전에는 옛한글은 오로지 내장 글꼴로밖에 표현할 수 없었는데 5.3에서부터 임의의 조합 테이블과 추가 자모를 내장 가능한 자체 비트맵 글꼴 포맷을 제정함으로써 <날개셋> 한글 입력기의 커널은 나름대로 글꼴도 독립을 이뤘다. 아래아한글 1.x와 비슷한 글월 입력 환경을 윈도우 환경에서 재현해 낸 것이다.

완전한 텍스트 에디터 엔진을 처음부터 새로 만들었기 때문에, 앞으로 한글 표현 방식이 어떻게 바뀌든 이 구조에 맞춰 엔진을 마음대로 내가 고칠 수 있다.
리눅스나 맥 OS에서는 이런 게 언제쯤 상륙 가능할까? ㄲㄲ

2.

지금까지 <날개셋> 한글 입력기를 만드는 과정에서 그 당시엔 내가 방법을 전혀 몰라서 어려움을 겪던 고비가 몇 차례 있었다.
- 인스톨 패키지 만들기(2002~2003년): MSI 기반으로 완전히 해결
- 외부 모듈(2004~2005년): 3.x 초창기 버전 때 무수한 시행 착오를 겪으면서 결국 안정화 단계. 하지만 “아직까지도” 일부 극소수 몰상식-_-한 응용 프로그램에서 사소한 오동작 버그 신고가 올라오고 있음
- 64비트(2007년): 결국은 본인이 64비트 기계를 직접 장만하면서 지원에 성공.

3.

한 컴퓨터를 놔두고 세벌식 사용자인 본인과 두벌식 사용자인 지인이 같이 앉아 문서를 읽으면서 검토와 교정을 하고 있었다. 이때 복벌식 입력 방식을 아주 유용하게 사용했다. 글자판 전환을 할 필요 없이 서로 자기에게 익숙한 글자판으로 자기가 수정하고 싶은 곳에서 바로 글자를 입력하면 되니 이렇게 편할 수가 없었다. ^^

이거 하니까 세벌식 관련 다른 팁이 또 생각난다. 세벌식 숫자 배열이 익숙한 분이라면, numlock이 켜져 있을 때 오른손 숫자 자리가 non-shift 자리로 내려오게 하면 엑셀 같은 데서 숫자 입력을 아주 편리하게 할 수 있다. <날개셋> 한글 입력기로는 가능하다.

4.

버전 5.53 내지 5.65쯤부터 추가되었지 싶은데, <날개셋> 편집기로 프로그램이 아닌 문서 창(MDI)의 시스템 메뉴를 보면 해당 문서 파일의 ‘속성’ 창을 바로 꺼내거나, 탐색기를 꺼내거나 전체 경로를 복사하는 명령이 있다. ‘파일 경로 복사’를 고르면 되는데, 지금까지는 진짜 말 그대로 파일의 경로가 텍스트 형태로 복사되어 메모장에서만 그걸 붙여넣을 수 있었다.

그런데 탐색기에서 Ctrl+V를 누르면 해당 파일 자체가 실제로 복사도 되게끔 프로그램을 고쳐 봤다. 메모장과 탐색기는 클립보드를 사용하는 방식이 완전히 다르기 때문에 이 기능은 서로 충돌을 일으키지 않으며, 이렇게 하니까 아주 편하다. 5.8 버전에 이 기능이 반영되지 못해서 아쉽다.

5.8을 릴리즈한 후 현재까지 도움말의 오타 내지 로그인 화면· 아웃룩· vim 등에서의 사소하지만 쉽지 않은 외부 모듈 관련 버그가 몇 개 보고되어 있다. 하지만 다들 프로그램의 성능이나 안정성(죽는다거나-_-)과 관련된 건 아니다. MS IME의 소스를 직접 보지 않는 이상 이런 것까지 다 완벽하게 처리하는 버그 없는 IME란 제작 불가능하다. -_-

5.

다음은 <날개셋> 타자연습 이야기. 지금부터는 그림도 좀 곁들이겠다.

사용자 삽입 이미지
요즘도 실력 유지를 위해 타자 연습을 안 하는 건 아닌데,
주옥같은 연습글을 만들었다. 다음 버전에 추가할지 진지하게 고민 중이다. ^^;;

공 병우 세벌식은 10년을 넘게 써도 한글의 위상을 끌어올린 정말 위대한 발명품임이 느껴진다. 그 반면 저 불편한 현행 두벌식 글자판은 어떻게 쓰는지 그걸로 빨리 치는 사람들이 대단하기 그지없다. 세벌식의 단점--기껏해야 글쇠 수 좀 많고 4단 쓰는 것--에 비해 두벌식의 단점은 훨씬 더 치명적이다.

사용자 삽입 이미지
2008년부터 2010년까지 존재하는 본인의 게임 점수판은 전부 ‘승리’(12단계 깨고 엔딩)이다. 본인이 사무엘이라는 이름을 쓰기 시작한 건 2008년 말부터임.
<날개셋> 타자 게임은 과거의 한메 타자 베네치아보다 훨~씬 더 어렵지만 요즘은 한글 타자가 워낙 일상화했기 때문에 본인 말고도 엔딩 보는 사람이 꽤 있을 것이다.

6.

끝으로, 10년 전에 만들었던 WordTech 엔진(컴퓨터 자동 대국 기능)을 요즘 완전히 새로 다시 짜고 있다. 스크린샷은 기존 WordTech와, 새 엔진(GUI를 갖다붙이지 않은 콘솔 프로그램)끼리 서로 검증 대국을 시키는 모습이다.

사용자 삽입 이미지
본인은 <날개셋> 한글 입력기를 만들기 전엔 국내에서 거의 최초로 크로스워드 게임 엔진을 만든 바 있으나... 그 당시의 작품은 지금의 관점에서 보면 기술적으로 개허접.. ㄲㄲㄲㄲ

요즘은 워낙 컴퓨터가 똑똑해진 덕분에, 굳이 이것보다 더 빠르고 메모리를 덜 쓰는 크로스워드 게임 엔진을 만든다는 게 큰 의미는 없지만... 이번에 새로 짠 코드는 메모리 사용량, 계산량, lexicon의 자료구조와 알고리즘, 코드의 깔끔함과 재사용성 등 모든 면에서 10년 전의 구닥다리 코드와는 비교가 되지 않는다. 참으로 아름답다. ^^;;

사실, 이렇게 만들면 된다는 이론적 기반은 이미 수 년 전에 완성되었지만 <날개셋> 개발 때문에 뒷전으로 밀려서 지금까지 작업을 못 하고 있었을 뿐이다.
WordTech도 버전업 좀 하고 싶은데.. ㅠㅠ 컴퓨터과학과 대학원 수업에서 무슨 과목으로든 프로젝트로 좀 할 기회라도 있었으면 좋겠다. 이 엔진 얹으면 버전 4.0으로 가는 건데.;;

콘솔은 만국의 공통 인터페이스이다 보니(표준 입출력 스트림^^), 엔진을 비주얼 C++뿐만이 아니라 오랜만에 DJGPP로도 컴파일해서 도스에서 돌려 봤다. 똑같이 32비트이기 때문에 별 어려움 없이 돌아간다. 지금도 DJGPP가 버전업이 되고 있는지는 모르겠지만 내가 보유하고 있는 건 무려 1997년에 설치한 버전. 혹시 bool 키워드가 지원되지 않나 확인해 봤는데 다행히 지원한다.

10년 전에는 DJGPP의 그 느린 빌드 속도가 무척 거슬렸으나 지금은 그마저도 전광석화. 별도의 도스박스 같은 에뮬뿐만이 아니라 그냥 윈도우 운영체제의 NTVDM에서도 잘 돌아간다.
단, printf의 포맷 지정자로 %c만 인식하고 %C는 인식하지 않는다. 대문자를 찍는다는 생각에 %X와 %x(16진수 숫자)를 구분하듯 습관적으로 %C를 지정해 줬는데 인식이 안 되더라. 뭐, 어차피 찍을 때 chCode+'A' 식으로 대문자를 지정하기 때문에 %c와 %C는 전혀 구분할 필요가 없고 %c만 지원해도 충분하긴 하다.

이상으로 본인의 programming life 잡설 끗.

Posted by 사무엘

2010/12/29 16:46 2010/12/29 16:46
, , , , , ,
Response
No Trackback , 12 Comments
RSS :
http://moogi.new21.org/tc/rss/response/440


블로그 이미지

그런즉 이제 애호박, 단호박, 늙은호박 이 셋은 항상 있으나, 그 중에 제일은 늙은호박이니라.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2024/03   »
          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
31            

Site Stats

Total hits:
2633430
Today:
228
Yesterday:
1754