« Previous : 1 : ... 207 : 208 : 209 : 210 : 211 : 212 : 213 : 214 : 215 : ... 221 : Next »

타자기 별 글꼴 비교

그림은 김 정수 지은 <한글의 역사와 미래> (열화당, 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

철도 차량 가속음 트렌드

우리나라에 존재하는 철도 동력차가 움직일 때 나는 음향은, 동력원이 무엇이냐에 따라서 크게 달라진다.

1. 기름으로 달리냐 전기로 달리냐

요즘은 철도는 다 전철로 바뀌는 추세이기 때문에 기름(디젤 엔진)으로 달리는 차는 아래의 딱 세 계보밖에 없다.
디젤 기관차(정확히 말하면 디젤 전기 기관차), 새마을호 PP 동차, 통근형 디젤 동차 내지 이를 개조한 무궁화호
내구연한이 경과하면 이런 차들은 대부분 역사 속으로 사라지고, 제일 마지막에 남는 건 비전철 구간을 달리고 화물 수송도 가능한(다목적) 기관차밖에 없을 것이다.
한편, 전기로 달리는 차는 굉장히 다양한 계보가 존재한다.

2. 일반열차 타입이냐 전동차 타입이냐

전자에 속하는 건 전기 기관차, KTX, 누리로이다. 사실 누리로는 엄밀히 따지면 전동차에 속할 수도 있지만, 현재 코레일 일선에서 일반열차 체계로 분류되어 있으니 전자에 넣었다.
이제 다음부터 등장하는 건 전부 소위 지하철 전동차들이다.

3. VVVF냐 아니냐

전동차는 VVVF 방식이냐 아니냐에 따라서 음색이 크게 차이가 난다.
VVVF란 ‘가변 전압 가변 주파수의 약자’인데, 쉽게 말해서 이게 더 기술적으로 더 발달한 좋은 방식인 반면, 변속할 때 위이잉~ 신시사이저 같은 소리가 크게 들린다. 내가 아주 좋아하는 음향이다.
VVVF 이전에는 전동차의 동력비를 조절하는 방식으로 저항 내지 쵸퍼 방식이 있었다. 2010년 현재 전국에서 VVVF 차량을 전혀 볼 수 없는 지하철은 부산 1호선이 유일하다. (시 재정도 부족하고, 그나마 차량 내구연한도 40년으로 늘렸으니 더욱 오래 볼 듯. ㅋㅋ)
이제는 구형 차량의 최후의 보루라 여겨지던 서울 지하철 1~3호선에도 신형 차량이 놀라울 정도로 많이 들어와서 구형 차량을 보기가 어려워지고 있다.

4. 초기 VVVF (90년대) 혹은 후기 VVVF (21세기 이후)

우리나라에 VVVF 전동차 시대가 개막된 것은 1990년대 초, 지하철로 치면 서울 2기 지하철(5~8호선), 그리고 수도권 광역전철로 치면 과천선 내지 분당선 정도의 시기로 보면 정확하다.
이때는 정말 춘추 시대처럼 전동차를 도입한 회사마다 유럽제, 일제 등 제각각의 인버터를 도입하여 노선마다 차량의 구동음이 제일 다채로웠다. 그래서 서울 지하철 5~8호선(1996~2000)은 노선별로 음악 소리 같은 아름다운 소리가 나는 것이다.
비슷한 시기에 개통한 부산 2호선(1999), 인천(1999), 대구 1호선(1997) 전동차도 서로 구동음이 제각기 다르고 서울 지하철 차량하고도 다르다.

그런데, 21세기에 들어서서는 구동음의 변화가 멈추고, 뭔가 획일화 추세가 보이기 시작했다. 이에 본인은 이것을 ‘후기 VVVF’ 시기라고 분류한다. 이 시기가 언제까지 지속될지는 모르겠다.

먼저 코레일 전동차도 2002년인가 2005년도 도입분부터는 더 변화가 감지되지 않고 있다.
지하철은 2005년부터 도입된 2호선 신형 전동차 구동음이 대세가 되었다.
2호선 신차, 그리고 2009년부터 도입된 3호선 신차와 9호선 전동차는 구동음이 모두 동일하다. 구동음의 첫음이 C#이다.

그런데, 부산 3호선(2005), 대구 2호선(2005), 그리고 공항 철도 전동차(2007)는 동일한 인버터 구동음인데 첫음의 높이만 다르다. 직접 타 보고 녹음한 음향과 대조해 본 끝에 동일함을 확인했다. ^^ 구동음의 첫음이 E인데, 앞의 것보다 약간 더 높다.
대전(2006)도 동일한 계보이며 첫음만 G로 차이가 있다. (앞의 것보다 낮은 옥타브)
광주 지하철(2004)은 직접 확인은 못 했지만 대전과 같은 구동음이 아닐까 생각된다.
이런 트렌드를 한데 뭉뚱그려서 21세기부터 시작된 ‘후기 VVVF’로 묶을 수 있는 것이다.

  그가 또 철도 차량에 관하여 말하되 디젤 기관차로부터 대도시를 다니는 지하철에 이르기까지 하고 그가 또 저항과 쵸퍼와 VVVF 전동차에 관하여 말하였으므로 (묵왕상 4:33) ㅋㅋㅋㅋㅋㅋㅋㅋ

서울 지하철 5호선 전동차 구동음이 너무 멋있다고 느껴서 5호선과 6호선만 골라 가며 타던 시절이 무려 2003년이다. 그로부터 5~6년 뒤, 본인은 철도 차량 음향은 다 마스터를 해 버렸다.
여기가 무슨 일본 같은 철도 왕국도 아니고, 땅도 좁고.. 얼마 되지도 않는 단순한 차량 계보인데 딱히 힘든 게 없다.

우리나라는 겨우 2004년에 고속철로 프랑스 떼제베 차량이 도입된 단일 계보인 반면, 일본은 이미 1964년부터 자체 기술로 개발된 신칸센이 다니기 시작했고, 고속철 차량 계보만 해도 0계부터 시작해서 열몇 종 가까이 되니, 그 복잡도가 우리나라와는 비교가 안 된다.
일본은 도쿄에 지하철도 이미 일제 강점기인 1920년대 말부터 다니기 시작했다. 첨단 철도 기술의 총아라 할 수 있는 지하철과 고속철 모두 한국보다 반세기 가까이 앞선 셈이다.

Posted by 사무엘

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

http://www.hanmal.pe.kr/bbs/view.php?id=ulimal&no=318
여기 나오는 단어들은 "고어"가 아닙니다.

저는 간결하고 짤막하고 청각적으로 변별도 잘 되는 외래어나 한자어 한 단어를, 무리하게 다 순우리말로 풀어야 할 필요는 없고, 그래서는 안된다고 생각합니다.

하지만, 이미 있는 우리말도 다 활용 안 하면서 무분별하게 외래어를 끌어들이고, 그게 더 뽀대난다고 생각하는 건 매우 잘못됐다고 생각합니다.

저런 순우리말을 살리려면.. 국어시간에 가르치는 것보다도,
영한사전의 뜻풀이를 바꾸는 게 현실적으로 가장 빠를 겁니다.

king에 왕보다 임금이 먼저 나오게 하고, reliable에 '신뢰할 수 있는, 믿을 수 있는'보다 '미더운'이 먼저 나오게 하면, 학생들부터 금방 익히게 됩니다. 왜? 당장 짧고 좋으니까!

그 외에도 아주 미세하고 섬세한 감정 차이를 내는 영어 단어랑 일대일 대응할 간결한 순우리말 어휘들도.. 찾아 보면 아주 많을 겁니다.
한번 보세요. 방나다, 사그랑이, 가년스럽다, 떼꾼하다, 에멜무지로 등등..

번역투 표현이 왜 문제가 되느냐? 일본의 영어사전으로부터 일본식 표현을 그대로 베낀 영한사전 때문입니다.
지금 영어의 영향력이 얼마나 됩니까? 지금 현실적으로 국어사전보다도 우리 국어생활에 더 영향을 끼치는 건 영한사전입니다. 영한사전이 바뀌어야 우리말이 삽니다.

※ 성 제훈 박사님이 매일 올리는 저 "우리말 123" 글터에 매일 들러서 내용을 구독해 보시길 권합니다. 유익합니다.

보태기~
그리고, 영한사전 못지않게 순우리말의 수호자가 되어야 할 곳은..

성경!

영한사전이 전국 수백만의 학생들의 언어 중추를 결정한다면,
성경은 전국 수백만의 크리스천들에게 절대적 권위를 가진 텍스트로 글자 하나하나가 그대로 골수에 박혀 영향을 끼칩니다.

거기에 순우리말이 있으면,
순우리말도 살리고, 세속적인 말투라는 느낌도 안 들고...
일석이조 아닙니까.

킹 제임스 성경만 봐도, 거기 나오는 고어(?)들은 당대 1600년대에도 안 쓰던 말이었습니다. ye, thou 따위는 그때에도 이미 you로 통합되어 있었습니다. 성경 본문과 제임스 왕께 바치는 헌사는 문체가 살짝 다릅니다.

개인적으로 "가라사대" 없애는 거 반대입니다.
개역개정판도 그렇고, 요즘 나오는 '문체만 옛날식'인 성경들(흠정역 등)이 왜 그런 말까지 없애는지 모르겠습니다.
"말씀하시되"는 너무 깁니다. 성경에 said, saith가 한두 번 나오는 말이 아닌데, 운율 생각해서라도 한 음절이라도 짧아야죠. "이르시되"는 say보다는 tell 같은 다른 용도가 있는 단어입니다.

흠정역이 비판받는 점이, 제한된 현대어 어휘만으로 영어 번역에만 충실하다 보니, 표현이 너무 장황하고 운율감이 떨어진다는 점입니다.
이럴 때 순우리말을 뒤지면 더 좋은 번역이 나올 수 있지요.

Posted by 사무엘

2010/01/11 18:58 2010/01/11 18:58
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/113

« Previous : 1 : ... 207 : 208 : 209 : 210 : 211 : 212 : 213 : 214 : 215 : ... 221 : Next »

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2024/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:
3042442
Today:
2069
Yesterday:
1700