수도권 전철 안산선(=4호선) 상록수 역에서 수인선이 있던 곳 -> 한대앞 역으로 쭉 걸으며 찍은 사진들.
지금은 찾아볼 수 없는 역사 기록이 되었다.
사용자 삽입 이미지

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

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

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

Posted by 사무엘

2010/01/13 00:44 2010/01/13 00:44
,
Response
No Trackback , 3 Comments
RSS :
http://moogi.new21.org/tc/rss/response/125

한글 노래 (2004/10/9)

사용자 삽입 이미지
저의 손글씨.. 2004년 한글날에 쓴 것입니다.

Posted by 사무엘

2010/01/13 00:13 2010/01/13 00:13
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/124

타자기 별 글꼴 비교

그림은 김 정수 지은 <한글의 역사와 미래> (열화당, 1990)에 있는 화보를 스캔한 것입니다.

1. 공 병우 세벌식 타자기

눈보다는 손의 편의를 철저하게 추구한 능률적인 타자 방식입니다. 글자를 알아보는 데는 지장이 없지만, 글자꼴이 뭔가 어설픈 느낌이 있습니다.

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

2. 표준 네벌식 타자기
가장 '타자기 글꼴'다운 글자꼴이 나옵니다.
사용자 삽입 이미지

3. 김 동훈 다섯벌식 타자기
손으로 쓴 글씨와 별 차이가 없을 정도로 꽤 볼 만한 사각형 글자꼴이 나옵니다. 그 대신 다섯 벌이나 되는 타법을 배우기는 어렵겠죠.
사용자 삽입 이미지

Posted by 사무엘

2010/01/12 23:55 2010/01/12 23:55
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/123

스펀지 방영 화면 (2005/3/12)

2005년 3월 12일,
"50년 전 발명된 [ ]가 지금의 것보다 훨씬 빠르다" 라고 세벌식 타자기를 소개하는 스펀지 아이템에 본인이 실험맨으로 출연했다.
두벌식과 세벌식을 모두 능숙하게 잘 다룬 덕분이었다.
촬영은 2005년 2월 23일.. 내 생일 때 했다. http://moogi.new21.org/news_sponge.htm 참고.
사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지

Posted by 사무엘

2010/01/12 20:06 2010/01/12 20:06
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/122

날개셋 한글 입력기 개발 화면

사용자 삽입 이미지
2004년, 3.0 개발 당시.. 윈도우 XP + 비주얼 C++ 2003.
알록달록한 XP 화면이 그리울 때가 있다.
사용자 삽입 이미지
그로부터 거의 3년 후 2007년, 4.8x 개발 당시, 윈도우 비스타 + 비주얼 C++ 2005
물론 지금은 개발툴도 2008로 업그레이드한 상태이다.

2012년 5월 현재, 비주얼 C++ 2010을 쓰고 있는 개발 인증샷.
사용자 삽입 이미지

Posted by 사무엘

2010/01/12 18:18 2010/01/12 18:18
,
Response
No Trackback , a comment
RSS :
http://moogi.new21.org/tc/rss/response/121

사용자 삽입 이미지
1998년, 제 15회 한국 정보 올림피아드 공모 부문 은상
1999년, 제 50회 Intel ISEF 참가
2000년, 제 17회 한국 정보 올림피아드 공모 부문 대상
사용자 삽입 이미지
그리고 이건 ISEF 참가자용 명찰..
사용자 삽입 이미지
명찰은 대회 일정 중에 사실상 신분증처럼 쓰이기 때문에, 대회장을 출입할 때 늘 착용하고 있어야 한다.
Finalist란 결선 진출자란 뜻으로, 쉽게 말해 이 대회에 작품을 출품한 대회 참가자를 말한다. 대회와 관련된 사람들은 Staff(대회 진행 요원), Judge(심사 위원) 등 자신의 이 적힌 명찰을 착용한다.

명찰 표면에 여러 브로치들이 붙어 있는데, 이는 다른 ISEF 참가자들을 만나면서 마치 명함 교환하듯이 받은 것이다. 본인 역시 당시 KOI 브로치(우측 상단 모서리를 볼 것)를 수십 개 준비해서 본인과 만난 외국 학생들에게 주었다. 영어로는 이런 장신구를 그냥 그대로 pin이라고 한다.

Posted by 사무엘

2010/01/12 18:16 2010/01/12 18:16
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/120

ISEF의 추억 (1999/5/2-8)

※ 본인은 Intel ISEF의 우리나라 최초 참가자이다. (제 50회, 필라델피아)

5월 2일, ISEF와 관련된 모든 사람(참가자, 스탭, 지도 교사, 옵저버 등)들이 대회 장소인 필라델피아 컨벤션센터에 모여, 명찰을 받고 등록하는 때였다.

사용자 삽입 이미지
등록을 마치고 로댕 박물관 앞. 당시 지도 교수였던 황 대준 교수님(성균관 대학교)과 함께
사용자 삽입 이미지

5월 3일, Opening Dinner. 어느 호텔에서

사용자 삽입 이미지
5월 4일, Evening with Novels.
Merck & Co. Foundation이라는 회사의 후원으로 ISEF 일정 중에 열린 행사로, 무대에 앉아 있는 8명의 노벨 수상자에게 학생이 아무나 나와 마이크로 질문을 하면, 수상자들이 거기에 대답하는 형식으로 진행됐다.
(Academy of Music란 건물 강당에서, 5월 4일 오후 세 시)
사용자 삽입 이미지

Posted by 사무엘

2010/01/12 16:36 2010/01/12 16:36
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/119

윈도우 환경에서야, 실행 가능한 기계어 코드가 들어있는 다른 모듈을 동적으로 로드하는 것이 일도 아니다. LoadLibrary, GetProcAddress라는 마법 같은 API가 있기 때문이다. 플러그 인 같은 것도 프로토콜만 하나 잘 짜 놓으면 얼마든지 만들 수 있다.

하지만 도스 시절에 그런 일종의 DLL이라는 것을 직접 구현을 어떻게 했을까?
본인은 도스 환경에서 하드웨어를 직접 제어한다거나 시스템 프로그래밍 경험이 전혀 없다. PC 통신 시절에 올라오던 랄프 브라운의 "인터럽트 릴리즈" 이런 것들도 내게는 완전 외계인 문서였다.
32비트 윈도우에서 곧바로 C/C++을 공부한 경우이다 보니, 지금 다시 생각해 보면 그게 무척 신기하다. 그래서 점점 다시 저수준 시스템 쪽으로 회귀 중이다.

도스용 아래아한글은 2.5에서 덧실행이라는 기능이 추가되었다. 그래서 과거 1.2 시절에 잠깐 있었던 테트리스 게임도 덧실행으로 부활하고, 아래아한글 안에서 숫제 한네트라는 통신 에뮬레이터까지 구동할 수 있었다. (개인적으로 그래픽 에디터를 그렇게 덧실행으로 내장했으면 무척 좋았을 것 같다.)

3.0에서는 덧실행의 활용의 폭이 더욱 커져서 계산기, 지뢰 찾기, CD 플레이어도 제공했으며 심지어 화면 보호기까지 덧실행 프로그램으로 독립했다. 2.5 확장팩에서부터 제공되던 영한 사전도 GUI는 덧실행 애플릿 형태였다. 이런 덧실행 프로그램들은 내부적으로 32비트 네이티브 코드였으며, 응당 32비트 에디션(HWP386)에서만 지원되었다.

도스용 이야기 역시 이름은 덧실행이 아니지만, 이런 덧실행에 해당하는 여러 기능이 있었다. 그림 파일 뷰어도 있고, AI가 상당히 똑똑했던 걸로 기억하는 오목 게임도 있었다. 16컬러에서밖에 실행되지 않았던 아래아한글과는 달리 이야기는 256색/트루컬러 그래픽까지 지원했지만, 내부 코드는 여전히 볼랜드 C++로 빌드된 16비트 프로그램이었으며, 덧실행 역시 16비트 코드라는 게 아래아한글과는 달랐다.

물론 덧실행에 앞서 이들 프로그램은 그래픽/프린터 드라이버가 이미 일종의 DLL이며 아래아한글의 경우 폰트 드라이버라는 계층이 있었지만, 이들보다 화면에 보이는 GUI가 있는 덧실행 프로그램이 사용자에게 더욱 존재감 있게 다가온 것 역시 부인할 수 없는 사실이다.

이런 덧실행들은 어떻게 만들었을까? 아래아한글 덧실행의 경우, SDK가 있었다.
아래아한글 32비트 에디션과 덧실행 프로그램들은 왓콤 C/C++로 빌드되었는데, SDK가 지정한 각종 함수/구조체 프로토콜에 맞게 덧실행 프로그램을 작성한 후, 역시 SDK가 제공하는 특수한 라이브러리를 써서 링크하고 바이너리에다 고유한 post processing을 마치면 간단히 덧실행 프로그램이 만들어졌다. 얘네들은 헤더만 다를 뿐, 내부적으로는 인텔 32비트 어셈블리 기계어 코드가 들어있는 exe 그대로였다.

아래아한글은 자기 밑에 실행되는 덧실행 프로그램에다가 지금 돌아가는 비디오 환경 같은 걸 알려 주고, 하드웨어 독립적인 각종 그래픽 루틴, 그리고 요즘 GUI 운영체제들이 다 그렇듯이 막강한 한글 입출력 엔진을 이용하여 글자를 찍고 GUI를 출력하는 API를 덧실행에다가 제공해 주었다.

그때 화면 보호기 중에는 아주 고전적인 "우주 여행"도 있었고 점 찍기, 선 그리기, 생명 게임, 퍼즐, 벌떼 같은 것들이 기본 제공되었다. 우주 여행은 단순히 전진만 하는 게 아니라 방향을 꺾는 것도 있고 무척 박진감 넘치고 원근감이 무척 멋지게 잘 표현돼 있었다.

그리고 벌떼도 나름대로 2차원 공간에서의 boid 시뮬레이션인데 움직임이 굉장히 사실적이어서 저런 걸 어떻게 짰을지가 무척 궁금했다.

이것 말고 선이나 점을 그리는 것은 while 루프 안에서 랜덤하게 화면에 낙서를 하는 녀석이었다. 특히 점 찍기는 그냥 화면 가득히 검은 1픽셀 점을 채워넣는 것으로, 프로그램 파일의 크기가 400바이트도 채 되지 않았다.

그래서 문득 궁금해졌다. 크기도 꽤 작고 프로그램을 어떻게 짰을지 감도 오고 하니,
코드 부분을 긁어 와서 디스어셈블을 해 봤다.

본인은 어셈블러 쪽 지식이 거의 없다. 뭐 복잡한 레지스터 이름만 나와도 머리가 지끈거린다.
본인보다 더 고수이신 분이 있으면 아래의 해설에 오류 교정이나 보충할 만한 설명 있으면 얼마든지 환영한다.

; 레지스터에 주어져 있는 어떤 값들을 스택에다 push함.
; 화면 보호기들은 다들 이런 명령으로 시작하더라.
0012FDF8 53               push        ebx
0012FDF9 51               push        ecx
0012FDFA 52               push        edx

; EAX 레지스터의 값을 0으로 초기화. x xor x는 언제나 0이므로, mov 0을 하는 것보다 코드 길이가 짧아서 좋다.
0012FDFB 31 C0            xor         eax,eax

; 뭔가 초기화 함수를 호출한다.
; 아래아한글 덧실행 SDK가 제공해 주는 라이브러리 함수에다 static link를 한 것이다.
0012FDFD FF 15 88 02 00 00 call        dword ptr ds:[288h]
0012FE03 FF 15 50 02 00 00 call        dword ptr ds:[250h]

; 고급 언어로 치면 while문의 시작인 듯. while(CanContinue()); 로 딱 번역 가능한 문장이다.
; 함수 리턴값을 테스트하여 조건이 만족하는 경우 뺑뺑이 바깥으로 빠져나간다. (12FE54)
; 화면 보호기의 종료 조건을 테스트하는 것이므로, 아마 키보드나 마우스 입력을 감지하는 함수일 것이다.
0012FE09 FF 15 14 02 00 00 call        dword ptr ds:[214h]
0012FE0F 85 C0            test        eax,eax
0012FE11 75 41            jne         0012FE54

; 뭔가 포인터 참조를 하는 듯하다. x = ptr->member 정도? 먼저 ptr의 위치를 임시로 EDX에다 저장 후,
0012FE13 8B 15 24 03 00 00 mov         edx,dword ptr ds:[324h]

; 함수 호출을 염두에 두고, 아마 EAX의 값인 0을 얹어 놓는 것 같다. 이렇게 EAX를 자주 써먹는 이유는 아까 xor EAX,EAX와 마찬가지로 명령어 길이가 짧기 때문.
0012FE19 50               push        eax

; EBX에다가 화면 세로 해상도를 저장하는 것 같다.
0012FE1A 8B 5A 14         mov         ebx,dword ptr [edx+14h]
; 아마도 이 0x24C 오프셋이 난수를 되돌리는 함수인 듯하다.
0012FE1D FF 15 4C 02 00 00 call        dword ptr ds:[24Ch]

; 정확한 의미 잘 모름.;;
0012FE23 89 C2            mov         edx,eax
0012FE25 43               inc         ebx

; 32비트 숫자를 31만치 오른쪽으로 비트 shift 한다는 것은 결국 그 숫자의 부호만 남기고 싹 없앤다는 뜻인데.. 특별한 의미는 모르겠다. 나눗셈 연산 전에 부호와 관련된 무슨 플래그 설정인 듯.
0012FE26 C1 FA 1F         sar         edx,1Fh

; 이제 난수가 화면 세로 해상도의 범위 안에 있도록, 난수 값을 화면 해상도로 나눈 나머지를 구한다.
; idiv 명령은 한번에 몫과 나머지를 모두 구하는데, 나머지의 값을 EDX에다 저장해 준다. 그렇기 때문에 EDX를 push하는 것을 알 수 있다.
; 아까 inc ebx 명령은, 화면 해상도에 0이 들어오더라도 나눗셈 에러가 나지 않게 안전 조치를 취한 것 같다.
0012FE29 F7 FB            idiv        eax,ebx
0012FE2B 52               push        edx

; 세로에 이어 가로 위치 argument를 얹을 준비를 한다. 다시 EDX에다가 324h 포인터 위치를 저장하고,
0012FE2C 8B 15 24 03 00 00 mov         edx,dword ptr ds:[324h]

; 아까 0x14가 화면의 세로 해상도이고 이거는 10h이니 가로 해상도? ㅋㅋ
0012FE32 8B 5A 10         mov         ebx,dword ptr [edx+10h]
0012FE35 FF 15 4C 02 00 00 call        dword ptr ds:[24Ch]

; 아까와 거의 동일하다. 이번엔 inc 명령은 들어가 있지 않다.
0012FE3B 89 C2            mov         edx,eax
0012FE3D C1 FA 1F         sar         edx,1Fh
0012FE40 F7 FB            idiv        eax,ebx
0012FE42 52               push        edx

; 이제는 324h 오프셋 자체를 push한다. 이 값은 역시 덧실행 프로그램이 호스트(아래아한글) 프로그램으로부터 받은 핸들 같다.
; 이게 제일 나중에 push된다는 말은, C++ 코드 상으로 제일 첫째 argumet라는 뜻이다. 즉,
; SetPixel(hDC, x, y, 0); 에서 hDC뻘 된다는 뜻이다. 0은 아까 EAX의 값으로 대체했던 점의 색깔 정도? (이 화면 보호기는 화면을 온통 검은 점으로 채운다)
0012FE43 FF 35 24 03 00 00 push        dword ptr ds:[324h]

; 점 찍는 함수 드디어 호출!
0012FE49 FF 15 E0 01 00 00 call        dword ptr ds:[1E0h]

; 함수 호출 후 argument를 얹었던 스택 위치를 재정리하는 작업. 16바이트를 더하는 것을 보면, 위의 함수가 총 4개의 인자를 받았다는 것을 알 수 있다.
0012FE4F 83 C4 10         add         esp,10h

; 다시 while의 시작으로 빠꾸
0012FE52 EB B5            jmp         0012FE09

; 루프 끗.
0012FE54 5A               pop         edx
0012FE55 59               pop         ecx
0012FE56 5B               pop         ebx
0012FE57 C3               ret

따라서 위의 코드에서 loop 부분을 슈도코드로 재구성하면 대략 이런 형태가 되겠다.

HANDLE hHWPHost;
while( CanContinue() )
        PutPixel( hHWPHost, rand() % hHWPHost->nScreenX, rand() % (hHWPHost->nScreenY+1), 0 );

저 간단하기 그지없는 코드를 C언어로 짜도, 컴파일을 하면 저 정도 수준의 기계어 코드로 번역된다는 것이 놀랍다.
역시 전산학의 총아는 컴파일러이다. 컴파일러 제작자가 존경스럽다.

프로그램 논리를 다 알고 있는 초간단 코드도 겨우 인텔 CPU 인스트럭션 세트 매뉴얼을 뒤지고,
간단히 내가 생각하는 코드를 VC++로 최적화 없이 컴파일하여 살펴보면서 낑낑대면서 디스어셈블을 해 봤는데,
이보다 훨씬 더 복잡한 기계어 프로그램은, 암호 같은 숫자와 명령 코드 속에서 본디 의미와 논리를 찾는다는 게 거의 불가능에 가깝다.

커다란 wav 파일 하나 던져 주고서, 이걸 재생하지 않고서 무슨 소리인지 알아 맞히는 거나 다름없다.
wav는 그래도 손실 압축이라도 되지, 기계어 exe는 같은 크기이더라도 정보량이 훨씬 더 많으며 손실 압축을 할 수가 없다.

점 찍기와는 달리, 선 그리기만 해도 코드 길이가 저것보다 더 길고, 특히 난수를 다섯 개나 요청한다.
x1, y1, x2, y2, 그리고 색깔 이렇게 다섯 개인 것을 어셈블리 코드 상으로 확인을 할 수 있었다.

비록 도스에서 돌아가는 일개 덧실행 프로그램이지만
돌아가는 기계 환경이 동일하고 똑같은 32비트 기계어이기 때문에 비주얼 C++의 디버깅 기능으로 이렇게 간단히 디스어셈블리 결과를 들여다볼 수 있다는 게 신기했다 (실행은 당연히 못 하지만).

단지 운영체제에 따라 EXE 파일의 포맷이 다르며, 입출력이라든가 운영체제가 제공하는 기능을 요청할 때, 도스 프로그램은 인터럽트에 의존하는 반면, 윈도우는 커널 영역에 자리잡은 함수 호출 기법을 사용하는 식의 차이가 존재하는 것이다.

Posted by 사무엘

2010/01/12 11:40 2010/01/12 11:40
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/118

나의 세벌식 이야기

본인은 세벌식 최종 자판을 1999년부터 지금까지 10년간 써 온 사람이다.
세벌식으로 10분간 장문 평타 750타대를 유지하며, 이 타속은 2002~3년 이후로 성장이 멈춰서 지금까지 안정화되어 쭉 이어져 오고 있다. 최종 유저이지만 390도 배열은 다 외우고 있다.

그러는 한편으로 두벌식도 장문 평타 450~500대를 유지하고 치며, 남보다 느리다는 소리는 안 듣는다. 나는 머리와 손이 두 자판에 모두 완전히 능숙하다. 어렸을 때는 '받침' 글쇠가 따로 존재하는 두벌식 타자기도 써 봤다.
그렇기 때문에 다른 어지간한 사람들보다는 두벌식과 세벌식의 경험 차이를 좀더 객관적으로 볼 수 있는 위치에 서 있다고 생각한다. 나름대로 아래와 같은 경력도 있으니..!
http://moogi.new21.org/news_sponge.htm

그런 나의 판정은??
두말할 나위도 없이 당연히 세벌식이 더 편하고 더 빠르게 칠 수 있는 자판이다. ^^;; 타자를 오래 할수록 차이는 더 두드러지게 된다. 개인적으로 장문하고 단문의 타속이 이렇게도 차이가 안 날 수가 있다는 걸 처음으로 느낀 게 세벌식 쓰면서부터이다.
공 병우 박사의 은혜가 고마울 따름이다. 내가 이 쪽으로 프로그램까지 이미 여럿 만들었으니 기득권 유지(?) 때문에 하는 말이 아니다.

이 홈페이지에 자주 들르는 분들은 다 아시겠지만 나는 평소에 프로그래밍뿐만 아니라 글도 많이 쓰는 편이다(당연히 한글로). 그렇기 때문에 글을 많이 칠수록 세벌식 자판의 혜택을 더욱 많이 누리고 있다.

세벌식이 가장 최적화되어 있는 패턴은 1~3단 사이에서 받침이 자주 나오고 초중종 다 한 타씩 끝나는 글자들이다. '대한민국', '한글날' 이런 단어는 내가 두벌식을 차별해서가 아니고 정말로 세벌식의 능률을 따라갈 수가 없다. 모아치기가 바로 이런 단어를 위해서 존재하는 개념이다.

뭐 글쇠 수가 많고 외워야 할 게 많아서 어렵고 더구나 속도까지 안 날 거라는 말은 정말 근거 없는 소리이고 쉽게 말해서 엄살이다. 이건 내가 자신있게 말할 수 있다. 두벌식보다 하루나 이틀 정도 시간 더 들여서, 평생을 훨씬 더 편한 자판 쓰면서 보내는 게 이익이지 않은가? 없, 않 같은 글자를 두벌식으로 치느니 차라리 받침 더 외워서 세벌식처럼 치고 말겠다.

더구나 세벌식은 그렇게도 접근하기 어렵고 그렇게도 프로페셔널 매니아-_-적인 글자판도 아니다. 오히려 세벌식은 전기계, 전계층 글자판 통일까지 염두에 두고 철저하게 '보편적'으로 만들어진 글자판이다. 저런 쪽의 오해는 제발 더 없었으면 좋겠다.

본인은 두벌식도 단문은 500 넘기는 건 물론이고 600까지도 치긴 하지만, 30초 이상만 한글 타자를 할 상황이 생기면 남 컴퓨터라도 반드시 설정부터 세벌식으로 바꾸고 세벌식으로 친다. 그만큼 타속과는 별개로 두벌식이 불편하다. 머리를 손이 따라가지 못한다. 걸핏하면 초성과 종성이 뒤바뀌고 꼬이고, "생일, 없어"가 "생리, ㅇ벗어"로 바뀌는 소위 "두벌식 오타" 때문에 글자가 엉망이 돼 버린다. 그 반면 세벌식은 근본적으로 그럴 일이 거의 없을 뿐만 아니라 그나마 오타가 난 것도 모아치기 오토마타를 쓰면 보정마저 된다! 시간이 흐름에 따라 순수하게 손의 체력이 딸리고 지쳐서 타속이 떨어질 뿐이지, 구조적인 장애물 bottleneck은 느껴지지 않는다.

이런 이유로 인해 나는 두벌식을 쓸 때는 날타는 생각도 안 하고 지내며, 타순이 꼬이는 걸 방지하는 아주 강력한 스레드 동기화(?) 오브젝트를, 큰 오버헤드를 감수하고라도 머릿속에다 발동하고 타자를 한다. 두벌식이라는 체계 하에서도 굉장히 졸속으로 비합리적으로 만들어진 축에 드는 이런 불편한 글자판만으로, 7, 800, 단문이라도 1000을 넘게 치는 사람이 있다는 게 대단할 따름이다. 정말 대단하고 존경스럽다. 나는 저게 4단 쓰는 것보다 훨씬 더 큰 단점으로 보이는데!

물론 세벌식도 단점이 있으며, 몇몇 예외적인 글자는 두벌식보다 치기 어려운 게 있다. 오른손으로 쳐야 하는 ㅖ(예의), 받침 ㄽ, ㄿ, ㄾ이라든가 '컴퓨터', 퇴, 봐 같은 글자. 이 정도는 연습으로 충분히 극복이 된다고 개인적으로 생각은 하지만, 초보자에게는 분명 쉽지 않을 거라는 점을 본인도 인정한다.

세벌식 10년차로서 내가 정말로 세벌식에서 어렵다고 여겨지는 자리를 굳이 꼽자면 그냥 4단이 아니라 4단의 중앙에 있는 '모음'들이다. 법률, 불량률, 야유 같은 것. 세벌식은 자리를 찾고 이동하기가 어렵지만 두벌식으로도 자음 연타가 굉장히 많아서 그다지 유쾌하게 치지는 못할 단어들이다. 이거 말고 ㅋ, 받침 ㅆ 같은 4단은 전혀 불편하지 않으며, 있어서 오히려 편한 것들이다.

공 병우 세벌식이 정말 대단하고 절묘하다고 느껴지는 면모는 앞서 말했듯이 기계식 타자기부터 컴퓨터까지 "직결식이 가능하며 글자판 통일을 염두에 뒀다는 것"(안 마태 글자판에도 없는 면모이다), 그리고 기계에게 편하게 함과 동시에 사람에게도 편하게 두 마리 토끼를 효과적으로 같이 잡았다는 것이다. (오른쪽에서 왼쪽으로 타자 진행 및 겹모음용 ㅗ ㅜ, 그리고 숫자 배열 같은)
세상에 한글 갖고 한 건 하려는 장사꾼이 아니라 정말로 한글 기계화의 근간과 뿌리를 생각한 공 병우 박사 같은 선각자는 이 세상에 정말 찾을 수 없다.

그래서 남들이 4단을 없애고 어떻게든 세벌식 자판의 단점만 가리려고 시도한 것과는 달리 본인은 컴퓨터 상에서 세벌식 자판의 다른 잠재적인 장점을 찾으려는 시도를 했고, 모아치기를 범용화한 오타마타 편집, 무한 낱자 수정, 각종 특수 글쇠들을 생각해 냈다. <날개셋> 한글 입력기를 그런 아이디어로 개발한 것이다.

두벌식은 글쇠 수가 정말로 너무 적어서 세벌식을 적용할 수 없는 곳에서 보조 역할로나 쓰이는 방식이어야 한다.
아울러 현 세벌식 자판에 대한 연구도 세벌식 최종을 기준으로 계속하여, 특히 기호를 재정비하고 재배치해야 할 자모가 있다면 더 효율적으로 바꾸는 시도가 있어야 하지 않나 생각도 해 본다.

Posted by 사무엘

2010/01/12 09:48 2010/01/12 09:48
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/117

모아쓰기와 풀어쓰기

  한글을 풀어서 쓰게 되면 모아쓸 때보다 글자의 형태가 더 단순해진다는 것 그 장점 하나는 나도 절대적으로 인정한다. 한글도 알파벳처럼 지금보다 훨씬 더 작은 픽셀 속에도 들어갈 수 있게 되고, 글자 하나하나가 더 큼직하고 알아보기 쉬워지며 글자를 더 작게 만들어도 되고 책 크기가 더 작아져도 되고, 모아쓸 때보다 글자를 기계적으로 다루기도 훨씬 더 쉬워지고... 언뜻 듣기만 하면 이 얼마나 솔깃한 매력인가!

본인 역시 한글 풀어쓰기 자체가 한글 파괴이고 세종대왕에 대한 모독이네 하는 감정적이고 원색적인 비난은 하지 않으며 할 필요도 없다. 지금 한글 풀어쓰기를 제일 배척하고 있는 진영은 오히려 소위 한자파들이다(주 시경, 최 현배 같은 사람까지 들먹이면서 엄청 욕을 한다). 하지만 예전의 풀어쓰기 옹호론자들이 주로 공 병우 박사와는 다른 노선을 간 한글 기계화 연구인들 위주였다면, 요즘은 음성학, 한글 맞춤법 쪽에 조예가 있는 국어학자 위주로 풀어쓰기 지지자를 찾을 수 있는 편이다.

  그런데 현실적인 장벽은 한글은 각각의 낱자들이 풀어쓰기에 그렇게 최적화되어 있지 못하다는 것.
모아쓰던 한글 자모를 기계적으로 있는 그대로 쫙 풀어 버리는 것만으로는 변별성, 시각성 면에서 도저히 모아쓰기를 따라잡을 수 없다. 이건 단순히 모아쓰기에 익숙해서 좋은 차원이 절대 아니다. 마치 일본어 히라가나를 쭈욱 풀어서 써 놓은 것과, 한자가 적당히 섞여 있는 것의 차이라고나 할까.
자음 ㅇ을 생략해야 할 것이고 모음 ㅡ는 도저히 있는 그대로 쓸 수 없으니 U자처럼 기울인다거나 어떻게든 변형을 해야 한다. 폭도 문제. 전각으로 쓰기엔 글자가 너무 널널하고, 그렇다고 반각으로 써도 ㅏㅓㅣ 같은 부류가 아닌 이상 그다지 보기가 좋지 못하다. 풀어쓴 한글 자모들이 실제 문장인지 아니면 "이니셜"인지 구별을 하기 위해 로마자 알파벳처럼 대소문자 같은 개념도 필요해질 것이다.

이뿐만이 아니다. 모아쓰기에 최적화되어 있던 한글 맞춤법도 상당수 뜯어고쳐야 한다. 명사하고 토씨 사이도 띄어야 할 것이고 모아쓰기를 하던 시절보다 띄어쓰기의 필요성이 월등히 더 커지고 쓰임이 엄격해질 것이다.
모아쓰던 시절보다 풀어쓰기 정서법이 더 간편해질 수 있을지는 모르나, 어쨌든 현 체계를 다 뜯어고치고 어떤 점에서는 모아쓰기가 지니고 있던 장점마저도 희생해야 할 것들이 적지 않다. 한글을 모아쓰면서 야기되는 단점이 풀어쓰기가 해결해야 할 저 숱한 과제들을 상쇄하고 남을 정도로 치명적이고 큰 단점인 것일까?

  이런 점에서 볼 때 본인은 풀어쓰기야말로 장점보다는 문제점, 위험성이 더 크다고 여긴다. 제한적인 상황에서 특수하게 쓰일 수 있을지는 모르나 한글을 활용하는 방법 면에서 main이 될 수는 없다.
한글은 어차피 근본 철학이 알파벳과는 완전히 다르게 만들어졌다. 분명 알파벳의 장점이 한글의 단점일 수도 있고 그 반대의 경우도 있을 수 있다. 가령 이제 와서 한글에다 대문자, 이탤릭체 따위를 만들거나 한글로 수학식, 프로그래밍 언어를 표기해 보겠다는 것은 무의미한 바보짓에 가깝다. (내가 보기에 가장 도전장을 내밀어 볼 만한 곳은 그나마 음성 기호 분야 정도..) 하지만 승부를 할 분야가 겨우 그것밖에 없냐 하면 그렇지도 않다.

타자를 예로 들어 보자. 한글이 무음 ㅇ을 언제나 채워넣는 것은 불필요한 1타 추가라는 점에서는 단점이지만, 이 덕분에 양손 교대 타자가 수월하게 이뤄진다는 점에서 보면 한글만의 장점인 것이다. 무리하게 한글에다가 알파벳의 장점을 어설프게 끼워 넣으려다 죽도 밥도 못 쑤게 되는 실수를 범하기보다는, 한글의 특성을 이용한 장점을 더욱 살리고 부각시키는 시스템을 만드는 것이 더 바람직한 문제 접근 방식이라 여겨진다. 한글에 일면 이런 단점이 있다는 것을 부정은 하지 않되, 이를 별 의미 없는 단점으로 가리고 오히려 더 큰 장점으로 승화하는 시도를 하면 된다는 것이다.

  이런 생각을 본인은 오래 전부터 하고 있었고, 거기에 가장 부합하는 기계화 성과가 바로 글자판과 글꼴과 코드를 한데 아우르는 "세벌식, 직결식" 철학임을 알 수 있었다. 공 병우 박사는 정말로 한글의 본질에 대해서 잘 알고 진정어린 애정을 갖고 오랜 연구를 한 분이라는 확신이 들었다. 남들이 겨우 '한글로는 안 돼' 내지 '그래도 한자가 없으면 안 되지' 같은 미개한 수준에 머물러 있었고 그나마 조금 선각자라는 사람은 기껏 '한글도 언젠가는 알파벳처럼 다 풀어쓰기로 바꿔야 기계화를 제대로 할 수 있어'에 머물러 있던 시절,
과감하게 쌍촛점 타자기를 만들고, 모아쓰기 체계를 근본적으로 건드리지 않으면서 가벼운 문자의 장점은 그대로 살릴 수 있는 방식을 생각해 낸 것이다. 한글을 2350 상형문자로 본 게 아니라 초중종 각 낱자라는 관점에서 보되, 이 셋이 하나라는 일종의 삼위일체(?) 관점으로 본 셈이다.

Posted by 사무엘

2010/01/12 09:47 2010/01/12 09:47
, , , ,
Response
No Trackback , 8 Comments
RSS :
http://moogi.new21.org/tc/rss/response/116

« Previous : 1 : ... 216 : 217 : 218 : 219 : 220 : 221 : 222 : 223 : 224 : ... 230 : Next »

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2026/08   »
            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:
3994483
Today:
862
Yesterday:
2195