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 , 4 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

한글 노래 해설

1. 강산도 빼어났다 배달의 나라 / 긴 역사 오랜 전통 지녀 온 겨레
거룩한 세종대왕 한글 펴시니 / 새 세상 밝혀 주는 해가 돋았네
한글은 우리의 자랑 문화의 터전 / 이 글로 이 나라의 힘을 기르자

2. 볼수록 아름다운 스물 넉 자는 그 속에 모든 이치 갖추어 있고
누구나 쉬 배우며 쓰기 편하니 세계의 글자 중에 으뜸이도다
한글은 우리의 자랑 민주의 근본 / 이 글로 이 나라의 힘을 기르자

3. 한 겨레 한 맘으로 한데 뭉치어 힘차게 일어나는 건설의 일꾼
바른 길 환한 길로 달려 나가자 / 희망이 앞에 있다 한글 나라에
한글은 우리 자랑 생활의 무기 / 이 글로 이 나라의 힘을 기르자

이 노래는 제목이 그냥 <한글 노래>이다.
즉, 한글날과 관계가 있다기보다는 한글 자체에 대한 찬가라는 점에서, 제헌절 노래나 삼일절 노래, 6· 25 노래 등과는 위상이 좀 다르다.

한글 노래는 언제 봐도, 눈물이 나올 정도로 참 감동적이다.
지난 2004년엔 본인, 가사를 손으로 필사한 적도 있다.

잘 알다시피, 이 노랫말을 지은 분은 외솔 최 현배 박사이다. 많고 많은 국어학자 중에 그분 정도로 한글을 진정 사랑한 분만이 ‘이 글로 이 나라의 힘을 기르자’ 수준의 역동적인 가사를 쓸 수 있었다고 본인은 생각한다.

1절은 한글 창제의 감격을 묘사했다.
외솔의 동지이자 조선어 학회 사건 당시의 fellowprisoner (롬 16:7, 골 4:10, 몬 23)이었던 석인 정 태진 선생이 1949년 <한글날을 맞이하여>라고 발표한 논설을 보면 비슷한 표현을 볼 수 있다.

“과연 그 날이야말로 우리 배달민족이 길고 긴 어두움에서 새로운 빛을 보던 날이었고, 그 날이야말로 과연 우리 민족이 오래오래 죽음의 길을 걷던 발길을 돌려서 영원의 삶의 길로 나아오던 바로 그 날이었던 것입니다.”

영생의 길.. 가히 종교적인 수준의 찬사인걸? (단, 너무 기쁨에 겨웠는지, 글 중엔 한글과 우리말을 그렇게 엄밀하게 구분하지 않은 표현도 좀 나오며, 60년이 지난 지금 다시 보기엔 다소 구태의연한 권면도 없지는 않음)
내 신앙관과 짬뽕을 하자면, 그야말로 성경에 나오는 의의 태양(말 4:2) 같은 심상이다.
주찬양 선교단 7집 <일어나라 빛을 발하라>의 2번 트랙 <빛>을 BGM으로 깔면 적절할 것 같다.

2절은 한글의 우수성이 묘사되어 있다.
외솔의 저서 <한글갈>에 있는 문장을 보면, 노래 가사는 저서의 요약이라는 걸 알 수 있다.

“한글은 그 짜임이 가장 과학스럽고 그 자형이 정연하고 아름다우며, 그 글자 수가 약소하고도 그 소리가 풍부하며, 그 학습이 쉽고도 그 응용이 광대하여 글자로서의 모든 이상적인 조건을 거의 다 갖추었다 할 만하니, 이 글자를 지어낸 세종대왕 한 사람 당대의 밝은 슬기가 능히 천고만인의 슬기를 초월하였다 하여도 과언이 아닐 것이다. 그래서 이 글자를 보는 이로 하여금 저절로 찬탄을 금치 못하게 하니 이는 고금이 다름없고 안팎이 한가지이다.”

한글을 ‘민주의 근본’이라고 칭한 것도 단어를 아무렇게나 선택한 게 아니다. 외솔의 평소 지론이 담겼다.
배우기 쉽고 편리한 글자로 문맹을 퇴치하고 국민들을 똑똑하게 만들어야만 민주주의도 실현된다는 그분의 철학은, 유고작인 <한글만 쓰기의 주장>을 읽어 보면 더욱 실감할 수 있다.

그리고 마지막 3절로 가자.
전통적인 기독교 찬송가를 보면, 앞부분은 예수님이나 크리스천의 삶에 대해서 노래하다가도 마지막 절은 재림, 천국, 내세 같은 거시적인 주제로 바뀌는 경우가 많다.
코레일의 사가 Oh Glory Korail도 보아라. 마지막 절은 한국 철도가 대륙을 넘어 세계로 뻗어간다고 스케일이 확 커지지 않던가. ㄲㄲㄲ

그런 맥락에서 한글 노래의 마지막 3절은, 한글을 통한 비전을 제시하고 있다!
김 동길 전 연세대 교수가 1980년대에 한글 문화권에 대해서 글을 썼듯이 말이다.

물론 21세기가 된 지금, 현실은 시궁창이다. 굉장히 시궁창이다.
외국어는 범람하고 국어 문법은 갈수록 잡-_-탕이 돼 간다.
그리고 미래가 안 보이는 경제 불황과 영적 배도와 타락, 그리고 막장으로 치닫는 사회 시스템 앞에서는... 한글이고 나발이고 답이 없다. -_-
나도 솔직히 육신적인 심정으로는 한글 문화권 나부랭이 따위를 바라느니(교리적으로 다분히 후천년주의적이기도 하다ㅋㅋㅋ), 차라리 하늘나라를 바라고 말겠다.

허나, 그래도 한국보다 더 못 사는 나라들로부터 이민자는 꾸준히 유입되고 있고,
생업을 위해서든 한류 열풍 때문이든, 오늘날은 한국어를 배우는 외국인들도 비록 진짜 메이저급 언어의 학습자에 비할 바는 못 되더라도 은근히 ‘많다’.
신토불이니, “가장 한국적인 게 가장 세계적이다” 식의 구태의연한 드립을 동원하고 싶지는 않다. 하지만 중국과 일본에 끼인 우리나라가 우리만의 개성을 내세워서 세계에 얼굴을 내밀려면 미우나 고우나 한글을 들고 나가야 한다.

그리고 한글이 ‘생활의 무기’란다. 최 현배 박사는 공 병우 한글 세벌식 타자기의 가치를 알았고, 문자를 다루는 기술을 기계화하는 것이 얼마나 중요한지 알았던 사람이다. 그랬기 때문에 ‘무기’라는 단어를 썼다. 자, 이 정도로 풀이하니 한글 노래의 가사가 정말 외솔스럽다는 게 와 닿으시는지?

이 글로 이 나라의 힘을 기르기 위해서 주 시경 선생은 그 옛날에 불모지이던 국어학의 기초를 닦고 한글 맞춤법의 근간을 마련해 놓았다.
최 현배 박사를 비롯한 조선어 학회의 학자들은 언어학의 결정체인 국어사전을 만들었다.
공 병우 박사는 기계와 사람의 편의성을 기가 막히게 조화시킨(=C언어스러운?ㅋㅋ) 전대미문의 한글 타자기를 발명했다.
그리고 아래아한글을 만들어 낸 프로그래머들은 음..;;
아놔 다들 너무 천재들이다..;;

그 다음으로 본인은 지금까지 해 놓은 일이 그 ‘한글탑’ 위에다가 벽돌 한 장 정도 올려놓은 수준은 되려나..? ㅋㅋ
(연세 대학교 캠퍼스 안엔 연세 한글탑이 있다.)

9월 18일 철도의 날과 10월 9일 한글날은 딱 3주 간격이며, 둘은 같은 요일이다.
고로 올해는 철도의 날과 한글날이 모두 일요일이다.
이 사실을 발견하고는 본인, 무릎을 쳤다.
철도와 성경이 만나듯, 철도와 한글 쪽도 이렇게 만날 필요가 있다. ㅋㅋㅋㅋ

예전의 글에서 소개한 적이 있는 김 진우 교수님은 이번 학기에 연세대 국문과 학부에서 <언어학의 이해>를 강의하고 계시는데, 한글날 근처의 주엔 이례적으로 여타 단원을 건너뛰고 ‘문자의 발달사’ 단원을 강의하신다. 당연히 한글을 기리기 위해서이다.

Posted by 사무엘

2011/10/09 08:33 2011/10/09 08:33
, , , ,
Response
No Trackback , 7 Comments
RSS :
http://moogi.new21.org/tc/rss/response/582

탈네모 글꼴에 대한 생각

한글 타이포그래피에서 탈네모 글꼴은 만년 떡밥인 것 같다. 지금 까지 그래와꼬 아패로도 그렇겠지

한글 가변폭 글꼴: 한글 글꼴 중에서 명조, 고딕 내지 한자 같은 부류와는 달리, 글자의 폭이 획일적이지 않고 글자마다 차이가 있는 글꼴을 일컫는다. 본문용으로는 잘 쓰이지 않고 특이한 제목이나 장식용으로 쓰인다. 아래에서 설명될 세벌식 글꼴과는 살짝 다른 개념으로, 세벌 글꼴은 굉장히 높은 확률로 한글 가변폭 글꼴이지만 모든 가변폭 글꼴이 세벌 글꼴은 아니다.

세벌식 글꼴: 공 병우 세벌식으로 만들어진 기계식 타자기로 글자를 쳤을 때 찍혀 나오는 자형과 같거나 최소한 상당히 유사한 구조를 하고 있는 글꼴. 일명 샘물체 내지 안상수체, 공한체 계열이다. 초중종을 이루는 벌수가 매우 적으며 글꼴 크기가 대체로 아주 작고 가볍다. 세벌식 글꼴은 거의 필연적으로 가변폭 글꼴이 되며, '가'과 '강'에서 '가'의 모양이 같아서 세로로도 기복이 크다는 특성상 '탈네모 글꼴'이라고도 분류된다.

그런데 문제는, 획일적인 정사각형을 탈피한 한글 글꼴에 대한 개인 호불호 편차가 굉장히 크다는 것이다. 국어학자, 타이포그래피 디자이너, 한글 기계화 연구인 중에서도 그런 발상 자체를 완전 개혐오하는 분이 좀 있다. 수 년 전, 한겨레 신문사가 이질감을 최소화하려고 무늬만 세벌 글꼴 흉내를 살짝 낸 한겨레결체로 본문 서체를 과감하게 바꿨는데, 당시엔 그것만으로도 “이거 도대체 뭐야?”(성경에 나오는 '만나'의 의미가 정확하게 이것이다-_-) 하는 반발이 벌써부터 터져나오기도 했다고 한다.

애초에 과거 기계식 타자기 시절에 네벌식, 다섯벌식 같은 불편한 입력 방식이 있었던 것도, 세벌식만으로 타자를 하면 자형이 너무 들쭉날쭉하고 못생겼기 때문이었다. 그만큼 사람들의 문자 습관이라는 건 무척 보수적이다.

그 반면에 서양 먹물 좀 먹었거나 일말의 선각자 자질이 있는 분은, 한글 자형이 정사각형 일색이기만 해서는 로마자(p, d, v 같은 들쭉날쭉 다양한 글자가 있는) 같은 가독성이 살아나질 않는다면서 그래도 탈네모 글꼴에 희망을 걸고 있는 경우가 있기도 하다. 그렇잖아도 국어 정서법에는 대문자도 없고, 고유명사도 없고, 영문 정서법 같은 엄격한 띄어쓰기가 정착해 있지 않으며, 문장 부호의 활용이 활발한 것도 아니다. 어찌 보면 굉장히 난감한 상황이 아닐 수 없다. 한글 전용론자라면 맨날 한글이 우수하다고 자뻑만 할 게 아니라, 현실에서 드러나는 한글의 단점을 한글로 해결하는 방법도 연구해야 하지 않겠는가?

컴퓨터용으로 만들어진 세벌식 글꼴은 최소한의 보정을 거친다. 가령, 간의 ㄴ은 감의 ㅁ보다 약간 위로 올라가며(공간이 너무 벌어지니까), 진짜 곧이곧대로 타자기 FM대로 1*1*1벌이라기보다는 최소한 2*1*2벌(특히 글자별 폭의 격차를 줄여서 디자인할 때) 이상이 시도되기도 한다.
<날개셋> 편집기에 존재하는 샘물이나 타자기 같은 글꼴은 에디팅 엔진의 한계 때문에 폭은 불변폭이나, 너그럽게 보면 세벌식 글꼴의 범주에 들어간다.

세벌식이라는 이념은, 한글을 풀어쓰기 형태로 파괴하지 않고 최소한의 형태와 원리를 유지하는 한편으로, 또 사람과 기계 모두에게 편리한 간결한 방법으로 한글을 입출력할 수 있는 정점을 찍은 일종의 교리이다.
탈네모 가변폭 한글 글꼴이라는 개념 자체는 글자판과는 별개로 일부 디자이너들이 시도하기도 했지만, 세벌식이 한글 글꼴에 그런 맥락의 변화를 시도하는 데에도 응당 영향을 끼쳤다고 볼 수 있는 셈이다.

이 이념의 영향을 받아 1980년대에 이미 안 상수 교수가 캐드를 이용한 디자인으로 안상수체 내지 안체를 개발했으며, 1990년대에는 한 재준 교수가 공 병우 박사와 합작으로 공한체와 한체 시리즈를 내놓았다. 대표적인 가변폭+세벌 글꼴이다.
안상수체는 아래아한글 2.1 (1993)에서 처음으로 도입되었고, 공한체/한체는 아래아한글 96에서 도입되어 우리에게 친숙해졌다.

여러분은 이런 탈네모, 세벌, 가변폭 한글 글꼴에 대해서 어떻게 생각하시는가?
일단, 이런 글꼴들은 생김새가 이질적일 뿐만 아니라 기존 네모 글꼴과는 디자인된 metric이라고 해야 하나, 전반적인 크기가 전혀 어울리지 않아서 같이 쓰기가 더욱 힘들다. 같은 크기로 맞췄을 때 저 글꼴은 여타 네모 글꼴들보다 훨씬 더 작아 보인다.

탈네모 글꼴을 처음으로 시도한 디자이너들은, 단순히 '생소하고 디자인이 정착해 있지 못하며, 완성도 높은 탈네모 글꼴이 아직 나오지 않아서 거부감이 드는 것일 뿐이다'라고 생각했다. 즉, 시간이 탈네모 글꼴의 문제를 점차 해결해 줄 거라고 생각했다. 실제로 2011년이 된 오늘날, 굳이 세벌이 아니더라도 가변폭 글꼴에 대한 국민적인 이질감은 예전보다는 줄어든 것 같다.

그러나 그래도 갈 길이 멀다. 아무래도 탈네모 글꼴이 명조· 고딕의 벽을 완전히 넘을 수 있을 것 같지는 않다. 특히 정사각형 안에 차곡차곡 자모가 질서정연하게 배치되는 명조· 궁서· 문화바탕 같은 미려한 서체의 완성도는, 탈네모 글꼴 주장자들이 결코 무시해서는 안 된다.
그런 글꼴이 괜히 수십~수백 년의 짬밥을 먹으면서 국민들로부터 사랑받고 살아남은 게 아니다. 탈네모 글꼴은 여전히 세리프 계열 글꼴이 빈약하며, 그나마 세리프 축에 드는 공한체는 진짜 무늬만 세리프이지 명조 같은 급에 비할 바가 못 된다. 즉 여전히 실험적인 수준을 벗어나지 못하고 있다는 뜻 되겠다.

하지만, (또 반전을 해야겠다)
그럼에도 불구하고
한글은 한자 같은 아예 픽토그램급의 상형문자가 아니고 일정한 규칙과 체계가 있는 '자질문자' 시스템인데..
천편일률적인 정사각형에만 맞춰 쓰는 건 많이 아까운 것도 사실이라고 본인은 생각한다.
이것이 앞으로 한글 타이포그래피가 풀어야 할 숙제 중 하나이다.

믿거나 말거나. MS 워드는.. 2007의 바로 직전의 2003 버전까지만 해도 가변폭 한글 글꼴이 전부 불변폭처럼 고정폭으로 찍혔다! 한글은 한자와 마찬가지로 무조건 정사각형이라고 전제를 했던 것 같다.
워드패드--정확히 말하면 그 밑에서 돌아가는 리치 에디트 컨트롤-- 도 초창기 버전은 마찬가지였는데, 이건 아마 윈도우 2000/XP 타이밍 무렵부터 개선되었지 싶다.

과거의 아래아한글 97은 정사각형 글꼴을 쓸 때는 안 그런데 공한체나 안상수체 같은 가변폭 글꼴로 한글을 입력하면 매번 줄 전체가 번쩍거리며 바뀌는 게 보여서 불편했다. 이 문제는 차세대 엔진 기반인 워디안/2002부터 바로 개선되긴 했다.

Posted by 사무엘

2011/08/25 09:23 2011/08/25 09:23
,
Response
No Trackback , 7 Comments
RSS :
http://moogi.new21.org/tc/rss/response/560

본인은 윈도우 플랫폼용 한글 입력기의 개발자이다. 그런데 진짜 옛날 도스 시절, 텍스트 모드가 따로 있던 시절에 한글 입출력 바이오스 같은 건 어떻게 구현했는지가 무진장 궁금해질 때가 있다.
출력은 그렇다 치더라도 입력은 어떻게 구현했을까? 게다가 한글도 모자라서 한자 입력은?
그리고 한글 정도면 양반이지 도스 시절에 일본은 사정이 어땠을까? 한자 변환까지 포함한 일본어 입력이 가능했을까? -_-;;

IBM 호환 PC는 그렇게 그래픽에 최적화돼 있지도 않던 놈이었고.. 영어 아스키 코드밖에 모르는 이런 기계에다가 없는 문자를 찍기 위해서는 막대한 양의 오버헤드가 필요했다.

요즘은 잘 알다시피 사운드 카드, 랜 카드 따위는 마더보드에 통합되어 버린 지가 오래이고 GPU, PPU 같은 거나 별도로 부착하는 CPU 애드온이다. (그리고 이마저도 요즘은 본격 통합 기세-_-)
허나 한 25~30년 전에는 한글 카드라는 별도의 하드웨어가 있을 정도였다. '한글 도깨비'. 그때는 그만큼 컴퓨터의 성능이 열악했다.

한글 입출력 바이오스를 만들려면, 일단 바이오스의 글꼴을 다른 걸로 대체할 수 있을 정도로 하드웨어에 정통해야 했고 메모리 사용량이든 계산량이든 극도의 최적화 작업이 필수였다. 한글 모드에서는 텍스트의 스크롤 속도가 한 2, 30% 정도 감소하는 효과가 있었기 때문. -_-;; 더구나 기본 메모리 640KB는 그야말로 1K라도 아껴야 하는 귀중한 영역이기 때문에, 한자 글꼴 같은 건 XMS/EMS 같은 확장 메모리에다 저장하는 테크닉도 필수였다.

VGA의 기본 텍스트 모드는 잘 알다시피 가로 80글자, 세로 25글자이다. 그런데 아주 신기하게도 한 글자의 크기는 너무나 컴퓨터스럽게 잘 떨어지는 8*16이 아니라, 9*16이다. 그리고 화면 해상도는 640*400도, 640*480도 아니요 720*400이다. 정작 mode 12H 같은 그래픽 모드 중에는 640을 넘는 해상도가 없던 시절이었는데 왜 텍스트 모드만 한 글자의 폭이 8이 아닌 9였는지는 모르겠다.
한글 바이오스들은 16*16 크기의 한글· 한자 글꼴을 사용했으며 640*400 해상도의 텍스트 모드에서 동작했다.

그뿐만이 아니다. 그때 VGA 텍스트 모드에는 화면 전체의 테두리 색이라는 게 있었다! 베이직에서 COLOR문은 보통 글자색과 배경색을 의미하는 A,B만이 쓰이는데, 셋째 인자도 있어서 이걸 지정하면 화면의 테두리에도 색깔을 줄 수 있었다. 이런 기능을 누가 썼고 왜 만들었는지는 모르겠지만...
이건 DosBOX나 VMware 같은 에뮬레이터들도 지원 안 하고 있는 기능이다.
그 테두리가 차지하는 픽셀 수는 얼마나 됐을까? 이것까지 감안한 화면 해상도는 얼마였을지를 생각하면 옛날에 비디오와 관련된 하드웨어 제어는 심오함 그 자체였겠다는 생각이 든다.

텍스트 모드의 바이오스 글꼴을 다루는 테크닉을 구사한 프로그램은 흔치 않았다. 도스용 노턴 유틸리티(Norton Utility)는 이걸 환상적으로 조작해서 텍스트 모드에서 준 GUI 수준의 비주얼을 만들고 심지어 그래픽 모양의 마우스 포인터까지 구현하는 용자짓을 했다. 그리고 Screen Thief라는 캡처 프로그램은 당시로서는 흔치 않게 텍스트 모드를 색깔과 바이오스 글꼴까지 감안한 실제 그래픽 화면 픽셀 그대로 캡처하는 기능이 있었다.
뭐, 한글 바이오스가 구동된 상태에서 노턴 유틸리티 같은 프로그램을 GUI 모드로 동시에 실행했다간 '영 좋지 않은 곳에 하드웨어 접근이 일어나서' 대략 불상사가 발생했겠지만 말이다. "내 컴이 다운이라니!!"

그때는 마우스의 존재 여부를 알아오는 테크닉만큼이나 한글 바이오스의 존재 여부를 알아오는 테크닉도 있었고
이는 텍스트 모드에서 실행되는 프로그램이 선문자를 깨지지 않고 맞게 출력하기 위해서 필수였다. 도스용 V3이나 MDIR 같은 프로그램들 말이다.
그러고 보니 한글 모드에서는 아스키 번호 1~31번 제어 문자도 원래 얼굴 모양 등 각종 도형이던 게, 1바이트 선문자로 바뀌었던 것 같다.

당연한 말이지만, 한글 바이오스는 바이오스의 글자 크기가 8*16이기만 하면, 텍스트가 아닌 그래픽 모드에서도 물론 동작했다.
하지만 그래픽 모드에서까지 텍스트를 찍는 프로그램은 전혀에 가깝게 없을 테니 이건 그리 의미는 없는 기능이었다.
그래픽 모드에서 동작하던 프로그램이 crash가 발생하는 바람에 그 상태 그대로 도스로 빠져나가서 도스 프롬프트가 찍힌 게 아닌 이상 말이다.
텍스트 모드에서는 cursor가 아주 빠르게 깜빡거렸지만 그래픽 모드에서는 cursor가 깜빡이지 않는다는 중요한 차이가 있었다.

그럼, 말이 나온 김에 옛날에 접했던 도스용 한글 바이오스들을 추억 차원에서 몇 개 예나 좀 들어 보자.

1. 본인이 난생 처음으로 접했던 IBM 호환 PC는 대우 전자에 개발한 286 AT였는데, config.sys의 DEVICE 문을 통해 구동하는 자체(대우에서) 개발 소프트웨어 기반 한글 바이오스가 들어있었다. 즉, 일단 load된 후엔 메모리에서 제거하는 방법이 없어서 불편했다. (그 당시 sys 파일은 com 실행 파일과 기술적으로 비슷한 구조가 아니었겠나 싶다.)
Alt+한영을 누르면 한글 바이오스 메뉴가 떠서 영문 전용/조합형/완성형 같은 모드를 바꿀 수 있었고, Alt+한자를 누르면 일시적으로 영문 전용 모드로 전환할 수 있었다.
대우 전자에서 개발한 만큼, 조합형과 완성형뿐만이 아니라 당시 악명 높던 DH 완성형도 지원했는데, 얘는 알파벳 소문자+대문자를 묶어서 한글을 표현하는 경우도 있었던 걸로 기억한다. 물론 한글 코드의 표준화가 일단락되면서 깔끔하게 묻혀서 역사 속으로 사라졌지만.

텍스트 + 한글 모드일 때는 화면의 맨 아래에 자그마하게 현재 한글/영문 모드인지, 완성형인지 조합형인지 같은 상태가 파란 배경의 줄에다 떴다. (그래픽 모드일 때는 그런 거 없음) 텍스트 모드에서 그런 걸 어떻게 구현했는지 지금 생각하면 정말 신기하기 그지없다.
물론 아까 말했던 VGA 테두리도 그보다 더 아래에 표시되었다.

한글을 입력하다가 bksp를 누르면 그냥 바이트 단위로 지워졌다. 즉, '한'을 입력하다가 bksp를 누르면 '하'가 되는 게 아니라 그대로 조합이 끝나면서 KS 완성형 기준 '한'을 구성하는 %C7%D1 중 %C7만 남아서 깨진 문자가 보였다.
우연히 한글 초성만 입력해 놓고 한자 키를 누르니까 지금까지 듣도 보도 못한 온갖 특수문자들이 펼쳐져서 이것도 신비로움 그 자체였다.

2. 한글 MS-DOS를 판매한 MS도 응당 자체 한글 바이오스를 갖추고 있었다.
그런데 지금까지 생각해도 참 대단한 건, MS에서 만든 한글 제품은 텍스트 모드에서도 깨진 문자를 보여주는 법이 없었다.
조합 중인 문자든 조합이 끝난 문자든, 한글은 알아서 자동으로 2바이트씩 한꺼번에 지워졌다. 조합 중인 글자를 조합의 역순으로 차곡차곡 '한' -> '하' 식으로 지워 주기에는 도스 환경이 너무 열악했고, MS가 개발한 한글 바이오스는 그냥 한글을 한꺼번에 지웠다.

GWBASIC, QBASIC 같은 프로그램은 한글판이 따로 있었는데, 한글 바이오스를 구동하지 않고 한글판 프로그램을 실행하면 글자만 깨지는 게 아니라 그대로 컴퓨터가 다운됐었다!
그러나 텍스트 모드에서 GUI를 구현한 한글판 프로그램들을 잘 살펴보면, 메뉴 같은 게 배경에 있는 한글의 2바이트를 반으로 가르게 될 경우 나머지 1바이트도 알아서 지워서 표시해 줬다. 어떤 경우에도 깨진 한글의 잔해 바이트가 표시되는 일이 없었다.

아마 한글 바이오스뿐만이 아니라 응용 프로그램 차원에서 무슨 특수한 처리를 한 것 같긴 한데, 그 대신 당시 MS에서 만든 한글판 프로그램들은 한글 바이오스가 없으면 동작하지 않고, 속도도 느리고 이래저래 파워 사용자들에게서 욕 많이 먹었다. 특히 QuickBasic 한글판은 라이브러리 파일이 영문판과 호환되지 않는 등 최악의 제품이었다.

<날개셋> 한글 입력기는 현재 '마소바탕'이라고 하여 MS 한글 바이오스가 내장한 조합형 글꼴을 그대로 지원하고 있다. 조합 구조가 전통적인 8*4*4벌 도깨비 글꼴과는 다른데 이런 것까지 복원해 냈다.

3. 끝으로 태백한글이라는 프로그램이 있었다. 1994~95년까지 32비트 코드로까지 비교적 오래 개발되었고, 도깨비 글꼴을 그대로 지원한다는 점이 무척 좋았다. 얘는 아마 조합 중인 한글을 음소 단위로 지우는 기능이 있었지 싶다.

도스도 모자라서 영문 윈도우 3.x에서 한글을 구현해 냈다는 한메한글 같은 프로그램은 운영체제의 무슨 계층에서 훅킹을 해서 도대체 어떻게 만든 걸까? 파워 사용자 중에는 영문 윈도우+한메한글이 오히려 한글 윈도우보다 더 안정적이고 좋았다는 말을 할 정도였으니 말이다.
32비트 시대가 도래하기 전에 한글 IME는 DLL이 아닌 EXE이긴 했는데, 그때는 구체적으로 어떤 메카니즘을 썼는지 잘 모르겠다. 물론 그 시절에는 한 프로세스가 시스템 전체에 어떤 영향을 끼치기가 지금보다 훨씬 더 쉬웠을 테니까 그 원리가 그렇게 복잡하고 어려운 건 없었을 것이다.

이것저것 잡설이 길어졌는데, 추억에 공감하시는 분이 있다면 용자.

한글 윈도우 3.1은 실행 전에 언제나 아래와 같은 경고문이 떴었다.
보다시피 MS는 분명히 Hangeul이라는 명칭을 썼었다. 허나 지금 대세는 Hangul이 압도적으로 굳어져 버린 듯. <날개셋> 한글 입력기도 6.0부터는 표기를 Hangul로 바꿨다.

Warning: For correct execution of DOS Box in Hangeul Windows 3.1,
You should use Hangeul Windows 3.1 standard HBIOS.

Warning: Your DOS is not compatible with Hangeul MS-DOS. You may have
some problems when you use Hangeul Windows 3.1.

Press any key to continue...

Posted by 사무엘

2011/06/30 08:47 2011/06/30 08:47
, , ,
Response
No Trackback , 10 Comments
RSS :
http://moogi.new21.org/tc/rss/response/533

세벌식 찬사

요즘 <날개셋> 타자연습에서 추가된 "김 화백 어록" 연습글로 재미있게 타자 연습을 하고 있다. 이런 연습글을 진작에 추가할 생각을 왜 못 했는지 모르겠다. ㅋㅋㅋㅋ

본인은, 사람이 타자를 하는 동작이 컴퓨터 CPU가 돌아가는 과정과 비슷한 구석이 있다는 생각을 오래 전부터 해 왔다.
연습글은 기계어 인스트럭션들이고, 글을 읽는 사람의 눈은 디코더. 타자 속도는 클럭 속도.-_-;;
CPU에 캐쉬 메모리가 있고 파이프라이닝이 있는 것처럼, 사람이 타자를 하는 것도 사실은 글자 단위가 아니라 최소한 단어 단위, 덩어리 단위로 하게 된다. 영문 독해를 빨리 하려면 단어 하나하나가 아니라 덩어리가 통째로 머리에 들어와야 하듯, 타자도 마찬가지이다. 글자 나부랭이 깨작깨작 눌러가지고는 마치 독수리 타법만큼이나 속도가 빨리 날 수가 없다.

세벌식이 두벌식보다 우수하고 속도가 빠른 이유는, 겨우 자모 단위가 아니라 그렇게 머릿속의 덩어리를 그대로 글자판의 손동작으로 옮기는 데 두벌식보다 월등히 더 유리한 구조이기 때문이다. 익숙한 어절이 등장하면 그 초중종성 낱자와 손 모양이 일대일 일심동체가 되어 머리의 지시가 마구잡이로 손으로 전달되고, 머리는 그 글자의 다음 글자가 이루는 손 모양까지 예측하게 된다. 일명 날타. 이런 최적의 조건이 잘 만족되면 세벌식으로 단문은 900~1000타도 어렵지 않게 나온다.

CPU로 치면 파이프라인이 쫙쫙 잘 되는 인스트럭션이라 할 수 있는데 공 병우 세벌식은 우-좌 리듬감 덕분에 이런 게 잘 된다. 쭈루루룩~ 그냥 타자를 치고 싶어진다. '한글날' 같은 글자... 쫘르륵~ 파이프라인이 최적이다.

날타는 오타가 나기 쉽다. 그런데 세벌식은 모아치기라든가 각종 한글 입력 설정 보정을 통해서 그런 오타를 보완하는 시스템까지 갖출 수 있으니, 심리적으로 더욱 편하고 막힘없이 타자를 할 수 있다. 꽤 오랫동안 지치지 않고 장문을 단문 치듯 치는 게 가능하다.
물론 세벌식에서도 '예의, 엽, 까'처럼 좌우 교대가 어긋난다거나 동일 손가락 연타가 발생하는 글자는 미스가 발생하긴 하지만, 종성과 초성 사이의 불규칙한 왼손 연타로 온통 얼룩져 있는 두벌식의 불편함에 비할 바야 물론 아니다.

또한, 앞에서 예를 든 것처럼 대놓고 손가락 움직임이 어긋나는 연타까지는 아니지만 세벌식으로 치기 좀 어려운 글자가 또 있다. '불량률' 같은 단어는 검지의 운지가 1단에서 4단까지 들쭉날쭉해서 세벌식을 10년 넘게 쓴 본인에게도 여전히 쉽지 않다. 이런 글자는 날타가 안 통하고 한 낱자씩 속도를 줄여서 또박또박 쳐야 한다. CPU로 치면 공간 locality의 위배 때문에 캐쉬 미스가 나는 메모리 접근에 비유할 수 있겠다. 날타냐 정타냐를 잘 결정해야 오타 없이 빠른 타자를 할 수 있다. 오타가 한 번 나면 손실이 가히 엄청나기 때문에.

두벌식은 4단을 안 쓰고, 치기 편한 글자와 치기 불편한 글자 사이의 편차가 세벌식만치 심하지는 않다.
하지만 평균적인 타자 experience가 세벌식보다 훨씬 나쁘다. 세벌식은 입체 교차이고 두벌식은 신호등이 있는 평면 교차..

어차피 800타, 900타 치지도 못하고 스마트폰용으로 작은 화면에다 그냥 버튼 수 적은 입력 방식을 만들 때야 두벌식이든 그보다 더 복잡한 입력 방식이든 크게 상관할 바가 아니다만... 생업을 목적으로 방대한 양의 글을 입력할 수 있는 정도의 규모를 갖춘 기계에서 한글을 입력하는 데 세벌식을 생각하지 않는다는 건 어불성설이다.
특히, 타자기를 지나치게 폄하하는 의견에 본인은 다음과 같은 관점에서 동의하지 않는다.

첫째, 타자기의 형태를 거의 그대로 답습한 지금 같은 키보드보다 더 보편적이고 빠른 문자 입력 스키마는 지금까지 나오지 않았으며, 본인은 앞으로도 키보드가 그렇게 호락호락 없어질 거라고는 생각하지는 않는다.
참고로 한 10년 전부터, 스마트폰 같은 게 없던 시절부터도 앞으로 음성 인식 기술 때문에 키보드가 없어질 거라는 낭설이 떠돌았었다. 과연? -_-

둘째, 사람들은 공 병우 세벌식이 타자기를 고려하느라고 뭔가 굉장히 많은 걸 희생했다고 생각하는 경향이 많다. 그러나 그렇지 않으며, 공 병우 세벌식은 기계의 물리적 호환성과 사람의 편의· 심리라는 두 토끼를 매우 훌륭한 형태로 모두 잡았다.

그리고.. 늘 하는 말이지만, 오토마타가 장땡이 절대 아니다.
두벌식은 오토마타가 있으니까 컴퓨터에서나 겨우 문제될 게 없는 수준인 반면,
세벌식은 이론적으로 오토마타가 아예 없어도 되고, 있으면 당연히 두벌식보다 훨씬 더 앞서갈 수 있다.

세벌식이 글쇠 수가 좀 많은 것은.. 그래 솔까말 손가락이 짧은 사람에게 물리적으로 약간은 불편할 수 있다.
그러나 글쇠배열 자체가 외우기 힘들다거나 배우기가 그렇게 엄살 부릴 정도로 힘든 건... 절대 절대 아니다.
정말로 두벌식을 두 시간 만에 익혔으면 세벌식은 세 시간, 아니면 그래 까짓거 네 시간 만에 익히는 정도.
그러고 나서 평생 그 글자판을 쓰는 시간은 얼마나 되며, 평생 만들어 내는 글자는 몇 자나 될까?
이게 비교나 되는 게임이란 말인가?

그 글쇠 조금 더 익히는 대신에 얻는 것, 그리고 그 글쇠 좀 줄여서 잃는 것...
내가 보기엔 전자가 훨씬 더 남는 장사인데 사람들이 고작 그것만 갖고 야단법석을 떠는 게 안타깝다.

흔히, 지금 아무리 비용이 들더라도 100년 앞을 내다보고 미래를 위해서 해야 하는 투자의 예로 남북 통일도 있고, 독립 운동-_-도 있고 220볼트 승전도 제시되곤 하는데,
세벌식을 쓰는 건 그런 것보다도 더 비용이 덜 들고, 휠씬 '덜 극단적인' 예이다.

공 박사가 아니었으면 공 병우 세벌식 같은 글쇠배열은 도대체 얼마나 더 나중에야 나오게 됐을까, 아니 지구가 멸망하기 전에 발명되는 게 가능하긴 했을까?
컴퓨터는커녕 글을 기계로 쓴다는 생각 자체가 없던 시절에 그런 걸 만들 생각을 했다면, 공 박사는 얼마나 천재이고 시대를 앞서간 사람이었던가?

오늘은 모처럼 아주 고전적인, '클래식'한 주제를 다시 꺼내 보았다.
내가 이렇게 이따금씩 세벌식에 '자뻑'하는 건.. 다 이유가 있어서이다. ^^;;

Posted by 사무엘

2011/06/19 19:22 2011/06/19 19:22
, , ,
Response
No Trackback , 8 Comments
RSS :
http://moogi.new21.org/tc/rss/response/528

언어 잡설

오랜만에 전공 관련 잡설을 끄적인다.

1. 요즘 나오는 옥편이라면 각 한자들마다 글자의 유니코드 번호는 꼭 수록해 줘야 하지 않을까 싶다. 컴퓨터 시대에 저 정보는 하다못해 필순보다도 훨씬 더 필요하고 유용할 것이다.

2. 한자는 입력하고 다루는 데는 굉장히 불편하지만, 뜻글자라는 특성상 한자가 적당히만 쓰이면 형태소 분석과 의미 파악에는 굉장히 유리하다. 한-일 번역과 일-한 번역의 난이도의 차이를 생각해 보면 명백하다. 일본어는 처음에 입력하기가 느리고 불편하지만, 나중에 자연어 처리에는 다소 편할 수 있다는 뜻.
그와 반대로 한국어는 한글로 입력은 전광석화처럼 할 수 있지만 그만큼 소리만으로 기계가 힘들게 유추해야 하는 정보가 많으며, 언어 자체도 구조가 미치도록 판타지 다이나믹 귀걸이 코걸이 식이다 보니 자연어 처리 입장에서는 여간 까다로운 게 아니다.

3. 카이스트에서는 100% '재수강'이라는 용어만 쓰이지만, '재이수'라는 말도 있다는 건 연세대에 가서 처음 알았다.
카이스트에서는 봄학기, 가을학기라고 학기를 구분하지만 연세대는 그냥 고등학교 이전처럼 1학기, 2학기를 쓴다.
인문계 대학원에서는 교수가 다른 교수를 일컬을 때나 강의실에서 학생이 교수를 부를 때 '선생님'이라는 말을 쓴다. 심지어는 나이 많은 학생끼리도 친해지기 전에는 서로 선생이라고도 한다.
그러나 이공계 대학원에서는 여전히 '교수님'이 주도적인 것 같다.
이런 일련의 차이를 혹자는 '학교 방언'이라고 풀이하더라.

4. 이기다, 지다, 틀리다, 맞다, 모르다 같은 용언은 영어와 비교했을 때 용도에 따라 시제가 조금씩 일치하지 않는 면모가 있다.
격투 게임 같은 데서 흘러나오는 You win 같은 멘트를 '네가 이긴다'라고 번역하지는 않으며,
You are wrong도 '네가 틀리다'라고는 절대로 번역되지 않는다. wrong, incorrect를 언제나 과거 시제로 번역하다 보니 정작 현재 시제인 '틀리다'는 자꾸 '다르다'라는 뜻으로 이상하게 꼬이고 있는 것 같다.

5. 학교에서 구수한 옛한글들이 잔뜩 찍혀 있는 어느 옛날 한글 성경을 봤는데... '밥팀례'라는 희한한 단어가 있더이다. 밥티슴(baptism)과 침례의 합성어인지? 우리 선조들의 작명 겸 번역 센스에 감탄했다.
아울러, 개역성경도 '사단'이라고 적어 놓은 Satan을, 훨씬 더 옛날 성경이 '사탄'이라고 더 정확하게 표기하고 있었다.

6. 폐사: 가축이 폐사하는 것 말고 弊社 또는 ?社는 자기 회사를 겸손하게 낮춰 일컫는 말이다.
그러니 비즈니스 메일이나 광고에서 자주 볼 법도 한 단어 같은데.. 본인은 태어나서 지금까지 폐사라는 단어를 본 곳은 자동차 취급 설명서가 전부이다. -_-;;; 그 업계만의 방언이기라도 한 걸까? '폐사가 보증하는 순정 부품을 사용하시기 바랍니다. / 주행 중 이 경고등이 갑자기 켜진다면 폐사 서비스 센터에서 정비를 받으시기 바랍니다.'
IT 업계에서도 쓰지 말라는 법이 없을 텐데. '모 제품에 이런 버그 내지 보안 취약점이 발견되었으므로 사용자께서는 폐사가 제공하는 업데이트를 반드시 받으시기 바랍니다.'
아무리 겸손한 비하라지만 졸(졸고, 졸저)도 아니고 '폐'가 들어가니까 부정적인 느낌이 더 강하게 느껴지는 것 같다.

7. 또 자동차 취급 설명서 이야기.
요즘 차 취급 설명서에 '핸들'이 '스티어링 휠'이라고 적혀 있는 걸 보고 놀랐다. 호치키스가 스태플러로 바뀌듯, 국민들의 평균적인 영어 실력이 증가하면서 콩글리시도 점차 바로잡혀 가는 것 같다. ^^;;;
하지만 백미러는 그냥 실외 미러라고 표기했고, 진짜배기 영어인 리어뷰 미러라고 하지는 않은 듯하다.

8. 세월이 흐르면서 아래아한글 97이 이제 완전히 역사 속으로 사라졌기 때문에, <날개셋> 한글 입력기도 구닥다리 한컴 2바이트 코드에 대한 지원을 차츰 줄여서 지금은 이게 변환기 유틸에서나 볼 수 있는 존재가 돼 있다.
그런데 맨날 옛한글 말뭉치 자료를 다루는 이 바닥 사정을 들여다 보니까, 한컴 2바이트 코드가 그렇게까지 죽은 포맷은 아닌 것 같다. 한컴 2바이트 코드를 기준으로 만들어진 형태소 분석기 같은 툴들이 아직까지 쓰이고 있어서 말이다. 현실이 그만큼 낙후해 있다는 뜻 되겠다.

본인이 다니는 이 대학원에 있으면서 좋은 점을 꼽자면 이러하다. 국어학 쪽의 진짜 전공자, 현업 종사자들의 언어학적 소견과 역사 증언을 접할 수 있다는 것이다.
말글 쪽으로는 '운동꾼'이기만 할 뿐 비전문가의 편협한 주장만을 접한 것과는 다르다. 비록 자기 전공 분야에서는 공학 박사이고 뭐 별별 업적을 남긴 분이라 하더라도 국어학 계열로는 이상한 지론에 빠져 이상한 주장을 밀어붙이는 분이 안타깝지만 꽤 있다. 나는 그렇게 되지 않으려 한다.

Posted by 사무엘

2011/05/13 08:39 2011/05/13 08:39
, ,
Response
No Trackback , 6 Comments
RSS :
http://moogi.new21.org/tc/rss/response/510

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

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2019/12   »
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:
1293381
Today:
32
Yesterday:
499