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

Posted by 사무엘

※ 2.0x

조합형 아스키 파일을 불러와서 편집하는 입력기 기술 데모 수준에 불과하던 1.x 에디팅 엔진이 2.0에 와서는 비약적으로 향상됐다. 서로 다른 입력 설정을 가질 수 있는 입력 항목을 4개까지 가질 수 있고 간단하게나마 플러그 인 확장도 가능해졌다.
편집기는 이제 자동 줄바꿈과 탭 문자가 지원되고 옛한글도 쓸 수 있게 되었다. 유니코드에 대한 지식이 부족해서 당시 아직도 널리 쓰이던 한/글 97의 내부 코드를 사용했던 게 무척 이색적임. 이게 무려 2002년의 일이다.

※ 2.3x

2.0 엔진을 기반으로 해서 편집기에 굉장히 많은 편의 기능이 추가되었다. 예를 들어, 중복 실행 방지라든가 전체 화면 같은 옵션은 이 버전대에서 처음으로 추가되어 오늘날에 이르고 있다.

※ 2.5

2.4와 기능면에서는 큰 차이가 없으나 드디어 개발툴이 비주얼 C++ 2003으로 업그레이드되어 향후 6년간 이 툴이 쓰이기 시작했다. 그리고 이 때부터 MSI 패키지 방식으로 프로그램이 배포되기 시작했고, 이 버전에서 정말 허접하게나마 TSF 모듈이 시범적으로 도입됐다.

※ 3.0 ~ 3.02

<날개셋> 개발 역사상 버전업 gap이 가장 길었던 3.0은 더 말이 필요 없다. API가 밑바닥부터 완전히 revamp되었다.
입력 기본 문자가 64비트 크기로 확장되고 100% 유니코드 기반 설계, 오토마타와 글쇠배열에 수식 지원, 임의의 개수의 입력 아이템 등록, 입력 스키마와 문자 생성기 계층의 분리, 첫가끝 방식 옛한글 표현 등 지금 <날개셋> 한글 입력기의 근간을 상당수 이때 이뤄냈다.
물론 엔진 교체에만 치중하느라 2.x에 있던 기능이 다운그레이드된 것도 그때는 있었다.

3.01은 3.0의 여러 치명적인 버그 수정 중심이었다.
엔진뿐만 아니라 외부 모듈 쪽 연구도 꾸준히 이뤄진 덕분에 3.02 때는 드디어 <날개셋> 한글 입력기가 역사상 처음으로 정식 외부 모듈(윈도우 IME)로 개발되는 쾌거를 이뤘다. 전용 에디터인 편집기 말고도 또 하나의 프런트 엔드가 추가된 것이다.

※ 3.1

상당히 개발 기간이 길었다. 외부 모듈을 처음 만들면서 부딪혔던 지옥 같은 온갖 버그들의 해결에 초점을 맞췄다. 그 후로도 3.x, 심지어 4.x 초반때까지도, 너무 투박하던 3.0x의 UI 편의성 강화 내지 다운그레이드 요인 해소 같은 개선 작업은 계속됐다.

※ 3.41

기념비적인 작품이다.
지금과 같은 tree 형태의 <날개셋> 제어판 UI가 이 때 정착했다. (3.0 UI는 지금보다 훨씬 더 불편했음)
그리고 한 바이너리로 유니코드도 지원하고 윈도우 9x에서도 실행 가능한 기술이 자체 개발되어 이 버전 때부터 적용됐고, MFC 라이브러리에 대한 종속성도 이때부터 완전히 사라졌다. 이 외에도 추가된 기능들 엄청 많다.
원래 3.4가 나왔으나, 치명적인 버그들 때문에 약 3주만에 역사 속으로 묻혔다. -_-

※ 3.9

3.5와 3.65는 여전히 외부 모듈 버그 해결 위주였고..
3.9에 와서 한글 입력 엔진이 장족의 발전을 이뤘다. 특수 도깨비불과 결합 축약 규칙이 도입되어 휴대전화 같은 굉장히 특이한 한글 입력 방식을 기술하는 기반이 마련되고, 한글뿐만 아니라 임의의 문자를 조합 상태로 입력할 수 있는 "날개셋 고급 입력기"라는 문자 생성기도 추가되었다.
아울러 XML 방식으로 입력 설정 파일을 읽고 쓰는 기능이 최초로 도입된 것도 이 버전부터이다.

※ 4.2

외부 모듈 쪽 버그를 잡은 것도 많지만, 편집기에 세로쓰기가 가능해지고(비록 기괴해 보이지만 -_-) undo/redo 기능이 지금과 같은 수준으로 쓸 만해진 게 이 버전부터이다.
사실 4.x은 3.x 엔진을 기반으로 해서 끊임없이 기능이 추가되고 외부 모듈이 안정화되던 단계였지 옛날 같은 급격한 변화는 없었다.

※ 4.4

윈도우 비스타와 MS 오피스 2007 같은 거물급 소프트웨어가 연달아 출시된 지 얼마 안 된 2007년 초에 나왔다. 이 버전은 에디팅 엔진부터 시작해서 외부 모듈 등 다방면에 걸쳐 굉장히 많은 기능이 추가되고 강화되었다. 윈도우 비스타 환경에 특화된 업데이트가 적용되었음도 물론이다.

개인적으로 무척 의미 심장한 버전이었다고 생각하는데, 놀라운 건 4.4는 4.2가 나온 지 불과 90일이 채 안 되는 짧은 기간만에 완성되었다는 것이다. 게다가 그 기간 동안 세벌식 파워업도 먼저 업데이트하고, 타자연습도 적지 않게 기능이 더해지고 고쳐졌다. 10년에 가까운 <날개셋> 한글 입력기 개발 역사상, 거의 전무후무한 사건이 아닌가 싶다.
어떻게 이 일이 가능했을까? 당시 근무 중이던 병특 회사가 망해 가면서 사실상 조업 중단 상태였고, 덕분에 개인 시간이 굉장히 많았던 덕분이었다. =_=;;

※ 4.55

지금과 같은 언어 리소스 파일이 확실하게 독립한 게 이 버전부터이다. 영어 말고 여타 언어 UI도 이제 이론적으로는 얼마든지 추가가 가능해졌는데, 그런 거 할 인력이 없으니.. -_-;;
이 시기에 정 재민 님의 노력 덕분에 같이 제공되는 비트맵 글꼴의 양과 품질도 굉장히 향상되었다.

※ 4.8x

짠.. 시대의 요구에 부합하여 이때 드디어 64비트 에디션이 나오기 시작했다.
그리고 이때, 프로그램 디렉터리 구조도 윈도우 비스타 기준대로 더욱 깔끔하게 바뀌었다.
4.81에 와서야 드디어 수식에 상수 명칭이 도입되었다.

※ 5.0

비록 기능상의 큰 변화는 없지만 한글 표현 범위가 유니코드 5.2에 맞춰서 확장됐으니, 5.0이라는 번호에 걸맞은 매우 의미심장한 변화라 할 수 있다. 또한 3~4대 버전에서 사용되어 온 비표준 한글 표현 관행도 완전히 없어졌다.
3~4대 버전에서 그대로 쓰이던 입력 설정 파일 포맷이 이 버전에서부터 바뀌었다. 그 대신, 한글 코드 변환과 옛날 방식 설정 파일의 변환만을 전문으로 하는 별도의 유틸리티가 추가됐다.

※ 5.3

나이를 먹고 사회적 위치가 바뀌면서 본인은 점차 시간의 압박에 시달리고 있다. <날개셋> 개발 주기도 갈수록 길어지는 게 눈에 띈다. 하지만 5.3은 5.0 이후 꽤 긴 시간만에 완성된 만큼 알찬 변화가 많으며, 보기 좋은 작품이다.
편집기는 8*4*4 도깨비 한글 글꼴뿐만 아니라 임의의 조합 테이블을 내장한 자체 글꼴을 지원하기 시작해, 옛한글 자모까지 포함하여 더욱 다양한 한글 글꼴을 사용할 수 있게 되었다.
이것 말고도 5.3에서의 가장 큰 변화는 "입력 패드"라는 제 3의 프런트 엔드의 추가이다. 편집기처럼 실행해서 외부 모듈처럼 다른 프로그램에다 글자 입력을 보내 주는 이 도구는 포인팅 장비로 입력 UI를 클릭하여 문자 입력이 가능하다. 예전에 존재하던 화면 키보드도 이런 입력 UI 중의 하나로 위상이 바뀌고, 동일한 UI를 세 개의 프런트 엔드에서 동일하게 구동하는 체계가 정립된 것이다.

그건 그런데, 5.3에 와서도 아직도 외부 모듈 버그 수정 사항이 심심찮게 보인다. 정말 윈도우 IME는 제대로 만들기가 불가능하며, 문제가 생길 때마다 그때 그때 고치는 수밖에 없다.
5.31은 5.3의 버그 패치라기보다는, 5.3에서 미처 다 못 넣은 기능들에 대한 강화판에 더 가깝다.

※ 5.5x

이 버전부터는 프로그램의 무설치 실행이 가능해졌으며, 윈도우 7에서 새롭게 발생하는 문제에 대한 패치가 몇 차례 이뤄졌다. 내부적으로는 개발툴이 6년만에 업그레이드되었다.
이 외에, 입력 UI로 부수 한자 입력기와 문자표가 입력 UI로 추가되었다. <날개셋>은 기술적으로 키보드 입력뿐만 아니라 터치스크린 입력 방식까지 커버할 만반의 준비를 하고 있는 중이다.

최신 버전인 5.52가 나온 후 현재 개인적으로 작업해 놓았거나 작업 중인 사소한 수정 사항은 다음과 같다. 일종의 ‘알려진 버그’인 셈이다.

1. 윈도우 라이브 메신저에서 마우스 클릭으로 대화창을 연 후 한글을 바로 입력하면 첫 타가 영문으로 씹히는 문제 (이건 기술적으로는 메신저의 버그임. 문제를 피해 가도록 조치를 취함)

2. 지금은 기억도 안 나는 여러 UI 개선. 특히, 받침 결합 규칙이 전혀 없는 세벌식 최종 자판에서 글쇠배열만 390이나 두벌식으로 바꾸려 할 때 경고 메시지가 뜨게 바꿈. ^^;;

3. XML 방식으로 설정 파일을 저장할 때, "" 안에 들어있는 부등호나 따옴표 같은 문자가 & 엔티티로 제대로 바뀌지 않을 수도 있는 문제를 발견하여 수정

4. 윈도우 7의 콘솔에서 한글을 조합 중이다가 조합을 중단할 때, 조합 중이던 한글이 덧나는 문제가 있다. ‘다 -> 다다.’ 처럼. 이게 일단은 MS IME에서도 두벌식이 아닌 세벌식 모드일 때 동일하게 나타나며, 비스타에서는 전혀 나타나지 않는 증상이 7에서만 나타나는 걸로 미뤄 볼 때 운영체제의 버그일 가능성이 높다.

5.52 이후 다음 버전은 또 기능 추가에 초점을 둔 5.7 정도로 생각 중이다.

Posted by 사무엘

내 프로그램의 중복 실행 여부를 판단하려면? (물론 윈도우 프로그래밍 기준)

실행 직후에 자신만 식별할 수 있는 이름으로 커널 오브젝트를 만들어서, 이놈의 생성 여부로 판단하는 게 제일 무난하고 안전하다. 커널 오브젝트라 함은 메모리 맵드 파일, 뮤텍스, 이벤트 등 이름의 scope가 전역적인 어느 것이라도 될 수 있겠다.

다른 방법으로 중복 실행을 판단하는 방법은 크게 윈도우 아니면 파일로 식별하는 것으로 나뉘는데, 커널 오브젝트만치 완전하지는 못하다. 그 이유를 지금부터 설명하겠다.

※ 응용 프로그램이 생성한 윈도우로 판단하는 법

FindWindow 함수로 나만이 지정하는 윈도우 클래스 이름이나 윈도우 캡션 이름을 검색하여 그게 존재하면 그 윈도우로 포커스를 옮겨 버리고 나는 실행을 종료한다. 대개, 이미 존재하는 인스턴스로 포커스를 옮겨 주는 작업이 필요할 것이므로 윈도우로 검색하는 방법은 어지간해서는 상당히 간편하고 직관적이고 좋은 방법이긴 하다. 다만,

만약 MFC 같은 프레임워크로 프로그램을 개발하고 있었다면, 메인 윈도우의 클래스 이름을 나만의 명칭으로 변경하기 위해 PreCreateWindow 같은 함수를 번거롭게 오버라이드해야 한다.

또한 클래스 이름이 아니라 캡션 이름으로 검색하는 것은 어지간해서는 피해야 한다. 캡션 이름 검색은 모든 top-level 윈도우들에 WM_GETTEXT 메시지를 보내는 방법으로 행해지기 때문에 오버헤드가 클 뿐만 아니라, 이미 실행된 내 프로그램 윈도우가 작업 중이어서 응답을 안 하고 있다면 프로그램 실행이 의도대로 되지 않을 우려가 크다.

윈도우로 검색하는 방법은 근본적으로 큰 약점이 있다. 일반적으로 프로그램이 실행된 직후 로딩, 각종 초기화를 끝내어 메인 윈도우를 생성하기까지는 적지 않은 시간이 소요된다는 것이다. 커널 오브젝트를 생성하는 것처럼 즉시 생성되는 게 아니다. 그렇기 때문에 첫 인스턴스가 아직 메인 윈도우를 만들기 전에 사용자가 실수나 고의로 또 엔터를 눌러서 둘째 인스턴스까지 실행한 경우 여전히 프로그램이 두 개가 실행되어 버릴 수가 있다. 프로그램이 어떤 경우에도 절대로 두 인스턴스 이상이 실행돼서는 안 되는 중요한 프로그램인 경우 윈도우 검색의 결과에만 의존해서는 안 된다.

※ 파일 차원에서 판단하는 법

윈도우 3.1 시절에는 WinMain 함수의 둘째 인자인 hPrevInstance를 살펴보는 것만으로도 내 프로그램의 중복 인스턴스를 판단할 수 있었다.
32비트 이후의 운영체제에서는 인스턴스 핸들의 의미가 한 주소공간 안의 포인터로 완전히 바뀌어 버렸기 때문에, 주소공간 자체가 독립적인 프로세스를 식별할 수는 없게 되었다. 오로지 그 주소공간 안에 로드되어 있는 여러 DLL 같은 모듈들만 식별할 수 있다.

그 반면, 지금도 EXE 내지 DLL 내부에 공유 가능한 섹션을 따로 생성하여 여기에 중복 인스턴스와 관련된 정보를 간단하게 집어넣을 수도 있다. 즉,
#pragma data_seg()
#pragma comment(linker, "/Section:SHARED,RWS")
이런 지시문 안에다가 전역변수를 선언하면 그 변수는 운영체제의 가상 메모리 상으로 나의 모든 인스턴스들이 공유하게 된다는 뜻이다. 자세한 것은 MSDN 참고. 번거롭게 메모리 맵드 파일 API를 호출할 필요 없이 간단한 데이터 공유에는 이 방법이 굉장히 편리하다.

이렇게 파일 차원에서 식별하는 방법은 윈도우 차원에서 식별하는 방법이 잠재적으로 갖고 있는 부작용들이 전혀 없어서 좋으나, 말 그대로 파일에 전적으로 종속적이라는 큰 한계가 있다.
같은 EXE를 이름만 바꿔 복사해서 실행한 것은 중복 인스턴스로 전혀 판단하지 못한다는 것이다. 이 점이 매우 중요하며, 이는 대부분의 경우 원치 않는 결과일 것이다. 결국 실행 파일 그 자체가 아니라 그 실행 파일이 만들어 놓은 결과를 추적해서 중복 실행을 판단하는 접근 방식이 필요하게 된다.

Posted by 사무엘

Posted by 사무엘

Posted by 사무엘

Posted by 사무엘

http://blog.naver.com/mhangulo/20054140906
여기서 본인의 눈길을 끈 정보는
"서울-부산간 KTX 전기 요금은 100만원 남짓."
열차 주행뿐만 아니라 객실 내부의 전기 공급까지 다 포함한 비용이겠죠.

본인은 어디선가 다른 출처를 통해, 서울 지하철 5호선급의 노선에서 전동차 한 편성이 편도 운행하는 데 드는 전기 요금이 10몇 만원이라는 얘기를 들은 적이 있습니다.

서울-부산간 거리는 약 408km에 약 100만원. KTX는 18량에 최대 935명이 타고.
지하철 노선 길이는 약 40~50km에 약 10몇 만원. 전동차는 8~10량에 초만원일 때 1600~2000명까지 탈 수 있음.

※ 408km는 곧게 뻗은 고속신선으로 달려서 산출된 거리에요. 기존선으로 달리면 서울-부산은 440km가 좀 넘습니다.

요금과 거리의 비율이 얼추 맞죠.
KTX는 빠르게 운행하느라 힘들지만, 지하철 전동차는 고가감속으로 시도 때도 없이 가다 서다를 반복해야 하기 때문에, 역시 만만찮게 힘듭니다.

정확한 비교가 되긴 어렵지만 그래도 얼추 짐작해 보면 굉장히 수긍이 가는 결과인 것 같습니다.
서울-부산 KTX 편도 운임이 거의 5만원에 육박하니 935명이 타는 열차에 겨우 20여 명, 객차 딱 한 량의 1/3밖에 안 되는 인원만 타도 "수송원가"는 건진다는 황당한 얘기가 나옵니다.

또한 상일동-방화 교통카드 운임이 요즘 1600원이니, 지하철 한 칸에 성인이 좌석 승객(40여 명)과 입석 승객이 비슷한 양만치만 타도 "수송원가" 건집니다.
우리나라에서 전기가 얼마나 저렴한 동력원인지를 알 수 있습니다. 원자력 발전 캡숑 짱 만쉐이입니다.

서울-부산을 기름으로 달린다면?
<과학 기술로 달리는 철도>란 책을 보면 우리나라 특대형 디젤 기관차는 1km 주행에 경유를 3.32리터 쓰는 기름 먹는 하마라고 합니다. 1리터로 3.32km가 절대 아님. 운행 조건이 전혀 명시되어 있지 않으니 무척 부정확한 통계가 될 수밖에 없긴 하지만.. 감만 잡도록 하죠.

여기에다 408이든 440이든 곱하면 소모되는 기름 양은 약 1460리터에 달합니다.
철도에 무슨 비닐하우스나 어선처럼 면세유 쓴다는 말은 못 들었으므로, 세금이 그대로 붙은 자동차 경유값 리터 당 1800을 곱하면... 네, 무려 이미 260만원이 넘습니다.

그 디젤 기관차 하나로는 객차도 최고 많아야 8~9개까지만 끌 수 있습니다. 그 반면 KTX는 한번에 18개에 달하는 객차를 끕니다.
수송량에서도 차이가 나는데, 디젤은 거기에다 발전차 가동에 드는 기름값도 추가해야겠죠? 발전차의 연료 및 유류비에 대해서는 전혀 아는 게 없으니 제끼더라도, 이런 것들을 감안하면 전기는 디젤보다 수송원가가 비교가 안 될만큼 무지막지 싸다는 것을 알 수 있습니다.

전철화가 되고 나서 철도 수송원가가 거의 1/3이나 그 이하 수준으로 떨어졌다는 말은 결코 과장이 아닌 것 같습니다. 특히나 우리나라처럼 기름값 비싼 나라에서는!

Posted by 사무엘

Posted by 사무엘

1. 다른 언어는 어떤지 모르겠지만, 최소한 영어와 일본어는 임의의 인명을 소리만 듣고 받아적기는 거의 불가능에 가깝다.
영어는 언문 일치가 개떡이기 때문이요, 일본어는 한자 때문이다. 특히 한자 문화권에서는 내 자식은 특별하게 키우려고 일부러 잘 안 쓰이는 어려운 한자만 골라서 집어넣는 경우도 흔하다. 그래서 그런 문화권은 일상 생활에서는 잘 알려진 쉬운 이름만 사용하는 애칭이 발달해 있는 것이다. 영어 알파벳은 단어 단위로 한자 같은 뜻글자를 이루고 있는 것에 가깝다. ^^

한국어가 영어보다 문법이 복잡하고 어렵고, 띄어쓰기 같은 맞춤법도 엄밀하게 정착해 있지 못한 면모가 있는 것은 사실이지만 그렇다고 해서 사정이 꼭 절망적이기만 한 것은 아니다. 한글은 그런 게 필수불가결한 변별 요소가 아니기 때문에, 그런 걸 꼭 안 지켜도 어지간하면 뜻이 잘 통하기 때문이다. 사실 영어에서 단어 철자나 띄어쓰기가 틀리는 것은 한글 자모를 잘못 적는 것이나 마찬가지이다. ㅈ을 ㅊ으로 잘못 적는 게 아니라 아예 ∨ 같은 엉뚱한 글자로 적는 것과 비슷한 맥락인 것이다.

2. better than nothing은 이게 다른 것보다 나은 게 하나도 없다는 '꼴찌, 무익'이라는 뜻일까,
아니면 그래도 '아예 없는 것보다는 낫다'는 '위안' 뉘앙스일까? 영어로 이 둘은 어떻게 구분하면 좋을까?
'아닌' 것과 '없는' 것은 의미가 비슷하지만 다를 때도 있다. 이런 게 헷갈릴 때가 있다.

3. 영어에서 비교급을 쓸 때 간단한 형용사에 대해서는 잘 알다시피 -er, -est 어미가 붙지만,
3음절 이상의 긴 단어이거나 형용사 자체가 -ous, -ful 같은 접미사가 붙은 단어라면 그런 어미가 또 붙지는 않고, more, most 같은 부사가 비교급을 만들어 준다.
그런데 문제는 more, most 자체도 many의 비교급으로서 형용사의 의미가 있다는 것.
나의 영문법 지식에 따르면, "더 유명한 사람들이 오고 있다"와 "유명한 사람들이 더 오고 있다"가 영작을 할 때 구분이 안 되는 상황이 벌어질 수 있다는 뜻이다.
마치 한국어에서 조사 '과(와)', '랑'이 and라는 의미도 있고 with라는 의미도 어느 정도 동시에 갖고 있어서 발생하는 모호성/중의성 정도와 비슷한 차원인 것 같다.

4. '한번'은 붙일까 띄울까?
인간의 언어에서 1이라는 숫자는 두 가지 방면에서 매우 중요한 의미가 있다.
첫째는 0이 아니라 1이라는 의미일 때(부재가 아니라 실존)이다. 이때는 영어에서도 a, the 같은 관사가 붙는다.
둘째는 복수가 아니라 1이라는 의미이다. 이때는 영어로 정확하게 one이라는 숫자가 쓰인다.

그래서 0이 아니라는 부정관사에 가까운 의미로 쓰는 '한번'은 붙여 쓰고, 진짜 정확하게 one time이 되어야 할 때는 '한 번'이라고 띄어 쓴다고 생각하면 대체로 맞다.

"언제 한번 놀러 오시죠." / "우리 한번 맞장 떠 볼까?" / "그런 방법도 한번 써 봤지만, 잘 먹히지 않았다." (놀러 오는 것, 맞장 뜨는 것처럼 안 하던 행위를 해 본다는 게 중요함)
"이미 접수가 되어 있으니 글쓰기 버튼은 한 번만 눌러야 합니다." / "한 번만 더 틀렸다간 진짜 죽는다" (왜 띄었는지 명확하다)

Posted by 사무엘

<너는 참 열심히 살았다>라는 공 병우 박사의 글은 본인이 10년도 더 전에 고등학교 시절에 접했고 내 홈페이지의 자료실에도 있을 뿐만 아니라 본인이 개발한 타자연습 프로그램의 연습글에도 등재되어 있다. 이 글을 요 며칠 전 다시 읽어 봤다.
http://moogi.new21.org/book1.htm

내가 어렸을 때는 그저 감성적으로 세벌식을 지지한 것도 없지 않았지만, 좀더 성숙하고 나이가 들면서 생각해 보니 공 박사는 예전에 생각했던 것보다 더욱, 정말 무서울 정도로 천재이고 선각자였다는 생각이 들며 전율을 느낀다. 그 시절에 벌써 저런 걸 생각해 냈다니! ㅎㄷㄷ 하는 그런 느낌 말이다.
(글을 보면 알겠지만, 심지어 이메일조차도 없고 ‘팩시밀리는 놔두고 얻다가 쓰나?’ 그러던 옛날이다.)

90년대 초반에 이미 80대의 나이로 매킨토시를 애마로 사용하면서 글을 쓰신 고인이 지금도 살아 계셔서 인터넷, 채팅, 댓글 문화, 휴대전화 문자, 블로그, 심지어 스마트폰이라는 걸 접했다면, 어떻게 대응하고 한글 세벌식을 응용해서 어떤 발명을 해냈을까? 아마 그런 것도 시간을 아껴 주는 기계라고 아주 좋아하셨을 것 같다. ^^;;
그런데 나는 노트북에 너무 익숙해진 나머지 노트북보다 작은 기계에는 관심이 없어진 것도 있다. 10년 전엔 내가 시대를 앞서 갔지만, 지금은 오히려 뒤쳐지고 있는 느낌이다. -_-

어쨌든, 이렇게 기계가 작아지면서 한글 기계화 역사에서도 뭔가 중요한 변화가 생겼다. ‘기계간의 글자판 통일’이라는 관점에서 두벌식, 세벌식이라는 논쟁은 그리 의미가 없어졌다는 것이다. 마치 유니코드 앞에서 조합형 완성형 논쟁이 의미가 없어진 것과 비슷한 맥락이라 할 수 있겠다.
그렇다면 앞으로 타자기와 호환되는 기계화 방식은 정말로 의미가 없어진 것일까? 작은 화면에 버튼 수도 더 줄일 수 있는 두벌식이 세벌식에 비해 우위를 차지하게 되는 걸까?

본인은 그렇지는 않다고 생각한다. 컴퓨터가 더 작아질 수가 없는 주된 이유 중 하나는 입력 속도 때문이다. 두 손으로 누르는 범용적인(=속기가 아닌) 입력 방식 중에 오늘날의 타자기/일반 키보드보다 더 빠른 입력 방식은 내가 알기로는 없다. 또한 12키나 아이폰 20키 같은 제한된 입력 환경에서도 음절 모호성이나 도깨비불 현상이 존재하지 않는 세벌식 입력 방식을 구현하려는 연구는 여전히 진행 중이다.
세벌식은 모바일에서도 죽지 않았다. 그 몇 가지 결과물을 소개한다.
http://moonhwawon.ye.ro/zboard/zboard.php?id=00_notice&no=64 (휴대전화 12키)
http://www.hopark.info/?p=1315 (아이폰 15키)

Posted by 사무엘