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

1. 심벌 검색 기능의 퇴화(?)

예전에도 글에서 언급한 적이 있지만, 비주얼 C++에는 Alt+F12를 누르면 심벌 검색을 할 수 있다. 주어진 프로젝트의 소스 코드에 등장하는 모든 명칭들(클래스, 함수, 전역 변수 등등)의 선언과 정의가 있는 곳을 곧바로 찾아갈 수 있으니 이건 매우 편리한 기능이 아닐 수 없다.

이 기능이 특히 강력한 이유는 내가 해당 프로젝트의 내부에서 선언한 명칭뿐만 아니라, 인클루드 파일에 있는 명칭들도 전부 조회할 수 있기 때문이다. 따라서 C/C++ 라이브러리에 있는 함수나 윈도우 플랫폼 SDK 내지 MFC 라이브러리에 있는 방대한 명칭들도 다 조회가 되어서 해당 명칭의 출처를 쉽게 알아낼 수 있다.

어차피 소스 코드를 빌드하여 precompiled header나 인텔리센스 정보를 만들 때 이런 정보들을 다 한 번씩 파싱을 하기 때문에, 심벌 검색은 최적화된 자체 데이터베이스를 대상으로 신속하게 행해진다. 무식하게 수백, 수천 개의 헤더와 소스 파일들을 텍스트 형태로 찾는 find in files 형태가 아니다.

그런데, 비주얼 C++ 2010을 보니 심벌 검색은 해당 프로젝트에서 직접 선언한 명칭만 가능하고, 그 프로젝트가 stdafx.h에다가 인클루드하여 사용하는 플랫폼 SDK, MFC 같은 것들의 명칭은 조회되지 않는다.
200x 시절과 동일하게 '참조에서 찾기' 옵션을 켜고, 검색 범위를 'All components'로 바뀌었는데도 여전하다. 이 기능에 무슨 문제가 생겼는지 궁금하다.

(WM_CREATE 위치가 뜨는 2003 좌, 하지만 뜨지 않는 2010 우)

물론, 소스 코드에서 MFC나 플랫폼 SDK의 명칭을 참조하는 부분에서 F12를 눌러 보면 여전히 해당 명칭의 선언부로 가긴 간다. 하지만 명칭을 직접 입력해서 찾는 심벌 검색 기능은 왜 그게 불가능해진 걸까?

보아하니 그저 닷넷 프레임워크 라이브러리의 명칭을 조회하는 기능에만 신경 쓰느라, C++ 네이티브 개발 쪽은 지원이 간과되기라도 한 건지? 2010은 그렇잖아도 인텔리센스에다 빌드 보조 파일들이(*.sdf, *.ipch) 예전에 비하면 기겁을 할 정도로 방대해졌는데 편의 기능은 도리어 없어지면 어떡하냐 말이다.

2. 메뉴 편집기의 우클릭

C++ 프로젝트를 새로 만들거나 열어서 리소스에서 메뉴 편집기를 연다. 아, 프로젝트를 만들 필요 없이 그냥 리소스 템플릿만 하나 만들어서 메뉴를 생성해도 되겠다.

열었으면 클라이언트 화면의 빈 공간을 아무 데나 우클릭하여 메뉴 편집기에 대한 컨텍스트 메뉴를 연다. 그 후 마우스로 다른 곳을 클릭하거나, 명령을 선택하거나, ESC를 눌러서 컨텍스트 메뉴를 없앤다.
그러면 컨텍스트 메뉴가 화면 좌측 상단에 한 번 또 나타나서 사용자를 성가시게 할 것이다.

이는 명백한 버그이다. 대화상자 같은 다른 리소스 편집기에서는 우클릭을 해도 이런 현상이 생기지 않는다.
2010뿐만이 아니라 무려 2003에서도 동일한 현상이 발견된다. 거의 10년 묵은 버그라는 뜻인데 아무도 신경을 안 쓰는지 지금까지 고쳐지지 않았다.
설마 6.0에서까지 이랬을 것 같지는 않은데 잘 모르겠다. 아직도 6.0 쓰시는 분이 계시면 확인 요망.

여담이지만 마우스가 아니라 Shift+F10 같은 키보드로 컨텍스트 메뉴를 열면 이런 현상이 생기지 않는다.
그리고 화면 빈 공간이 아니라 편집 중인 메뉴 항목의 경우 우클릭하더라도 역시 그 현상이 생기지 않는다.
이건 아주 사소한 코딩 실수로 보이고, 몇 라인만 고치면 바로 제거할 수 있는 버그이다만, 10년에 가까운 시간 동안 발견하고 지적한 사람이 없었나 보다.

C#이나 VB, C++/CLI 같은 닷넷 환경의 경우, 폼(네이티브 개발 환경으로 치면 대화상자)에다가 메뉴 컴포넌트를 집어넣으면 그 자리에서 바로 메뉴를 편집할 수 있게 되어 있으니 네이티브 개발과는 환경이 꽤 다르다.
닷넷 프로그램도 기본 메뉴는 일반 윈도우 운영체제가 제공하는 표준 네이티브 메뉴 형태로 나오지 않겠나 하고 생각해 왔는데, 놀랍게도 그렇지 않다. 비주얼 스튜디오 200x와 비슷한 형태인 싸제 메뉴이다.

3. 툴바 편집기의 화면 잔상

이뿐만이 아니다.
리소스 중에서 툴바 편집기를 보면, 툴바 아이템들을 순서대로 하나씩 찍어 보기만 해도 예전 selection 흔적이 지저분한 잔상으로 잔뜩 남는다. 저건 절대로 multiple selection을 나타내는  게 아니며, WM_PAINT 메시지만 다시 받아도 잔상은 싹 없어진다.

열기, 저장, 모두 저장, 인쇄 아이콘의 테두리에 생긴 잔상들을 보라.
그리고 믿어지지 않겠지만 이건 비주얼 C++ 2003 시절부터 변함없던 버그이다!
전세계에서 압도적인 인지도와 점유율을 자랑하는 개발툴에 이런 초보적인 버그가 있다는 게 믿어지는가? 6.0은 그렇지 않았던 걸로 난 기억한다.

아이콘의 배치 순서를 조정하거나 중간에 여백을 넣기 위해서 드래그 드롭만 해도 잔상이 잔뜩 쌓인다. 구체적으로 재연 조건과 증상을 일일이 기술하기에는 구차하나, 잔상 현상은 2010에서 조금 더 심해졌다.

4. 속성 대화상자

비주얼 C++ 6.0까지는 전통적으로 가로로 길쭉한 자신만의 context-sensitive한(문맥 민감. 사용자가 키보드 포커스를 두거나 선택한 개체나 문서에 따라서 대화상자 내부 내용이 수시로 동적으로 바뀌는) 속성 대화상자가 있어서 Alt+Enter를 누르면 언제든지 그게 떴었다. old timer라면 추억의 옛날 스타일 대화상자를 기억하실 것이다.

그게 닷넷부터는 비주얼 베이직 스타일의 프로퍼티 그리드로 다 바뀌었다.
특히 프로젝트 설정 대화상자(VC6 표준 단축키 기준 Alt+F7)도 이 형태로 리모델링된 것 여러분들 다 아실 것이다.

그러나 프로퍼티 그리드가 커버하지 못하는 UI가 있었으니 그것은 바로 preview 기능이다.
비트맵, 대화상자, 메뉴 등 리소스들을 일일이 열 필요 없이 찍어 보기만 해도 이놈이 대략 어떻게 생겼는지 간략히 표시해서 보여주는 기능인데,
이건 2차원적인 공간에다 뭔가를 그려야 하기 때문에 기존 프로퍼티 그리드로 커버할 수가 없다.

그래서 별도의 버튼을 누르면 결국 과거 6.0 시절의 속성 대화상자와 비스무리하게 생긴 대화상자가 떠서 미리보기를 보여주는 기능이 들어갔다. 뭐, 여기까지는 뭐 나쁘지 않다. 메뉴나 대화상자가 좀 더 깔끔하게 그려졌으면 좋겠는데 10년 전이나 지금이나 하나도 바뀐 게 없이 똑같이 엉성하다는 건 아쉽지만 말이다.

그런데 과거의 200x 시절에는 미리보기를 보는 중에도 키보드 포커스는 각종 리소스들을 고르는 화면에서 계속 유지가 되어서 위· 아래 화살표를 누르며 리소스들을 조회할 수 있었는데,
2010부터는 뭔가를 선택하고 나면, 키보드 포커스가 미리보기 대화상자로 바뀌어 버린다. 그래서 마우스로 해당 아이템들을 일일이 찍어야 한다.

역사적으로 비주얼 C++은 4.0 때 Developer Studio (MSDEV)라는 첫 UI가 갖춰진 이래로 닷넷으로 넘어갈 때 대대적인 리모델링을 거쳤고, 2010 때는 WPF 기반으로 또 IDE의 구현체가 크게 바뀌었다.

요즘 다시 C++11 지원처럼 C++ 지원이 강화되고는 있다지만, 기존 코드들이 리팩터링되는 과정에서 예전에는 없던 사소한 버그들이 끼어 들어가는 게, MS에서 닷넷에 비해 네이티브 환경 개발에 점점 소심해지고 있다는 생각이 들어서 아쉽다. 닷넷과 관련된 개발 환경이라면 저런 버그가 들어갔을 리가 없을 텐데 말이다.

다음은 버그까지는 아니고, 비주얼 C++과 관란하여 추가로 떠오르는 생각들이다.

1. 비주얼 C++은 32비트 시절 이래로(무려 4.x부터) 80비트 초정밀 부동소숫점인 long double을 무시하고, 이것도 일반 double과 완전히 동일한 64비트 부동소숫점으로만 제공하는 것으로 잘 알려져 있다.
난 32비트 CPU에서는 10바이트 단위로 정보를 처리하는 게 불편해저서 long double이 도태한 게 아니겠나 정도로만 생각해 왔다.
그런데 나중에 알고 보니 인텔 CPU엔 80비트 부동소숫점을 연산하는 명령 자체는 존재한다고 한다. 단지, MS 컴파일러가 이를 활용하지 않는다고.

이것까지 지원해야 하면 %타입 문자부터 시작해서 언어 라이브러리에도 그야말로 대대적인 칼질이 가해져야 하는 건 사실일 것이다. 그런데 그렇다고 해서 있는 CPU의 기능을 컴파일러가 활용하지 않는 건 좀 문제가 있어 보이는데?
인텔 컴파일러 같은 다른 벤더 제품 중에는 long double을 쓸 수 있는 놈이 있는지 궁금하다.

2. 오늘날 거의 모든 IDE와 에디터들은 탭을 customize할 수 있다.
화면에 표시되는 탭 길이를 조절하고(보통 거의 다 4를 쓰지만), 코딩용 자동 들여쓰기를 할 때 공백을 삽입할지 탭을 삽입할지를 지정할 수 있다. 그리고 언어별로 어떤 탭 설정을 사용할지도 지정 가능하다.

그런데 여기서 한 발 더 나아가서, 읽어들이는 소스 코드의 형태를 보고 탭 컨벤션을 자동 감지하게 할 수는 없나?
space로 맞춰져 있는 소스 코드에다가 눈치 없게 탭으로 들여쓰기를 삽입한다거나 혹은 그 반대로 하는 것. 불편하다.

자동 들여쓰기를 구현했을 정도라면 앞뒤의 중괄호가 어떻게 돼 있고 whitespace들이 space인지 tab인지 주변 context들은 다 파악했다는 뜻이다.
따라서 조금만 더 센스 있게 동작하게 만드는 것은 마치 코드의 줄바꿈 문자의 종류를 자동 감지하는 것만큼이나 그렇게 어려운 일이 아니리라 여겨진다.

Posted by 사무엘

1. 조화평균과 조화수열

우리는 중등 학교의 수학에서 산술, 기하, 조화평균을 배운다.
물론, 대부분의 일상생활에서 숫자를 다룰 때는 단순히 합계를 자료의 개수로 나누기만 하는 산술평균 하나만 있어도 충분하다. 그러나 다른 개념의 평균이 필요할 때도 있다.

가령, 어떤 수치가 1년 간격으로 예전보다 3배, 4배, 5배씩 증가해서 총 60배가 되었다면, 이를 해마다 4배씩 증가했다고 싸잡아 간주할 수는 없는 노릇이다. 4의 3승은 64이지 60이 아니기 때문이다.

이런 식으로 비율 내지 배율을 좋아하는 계산 분야에서는 기하평균이 필수이다. 앞의 예에서는 (3+4+5)/3이 아니라, 3*4*5의 세제곱근인 약 3.915가 정확한 값이다.

그럼 조화평균은 무엇이며 어떤 용도로 쓰일까?
역수의 산술평균을 또 역수로 취한 값이 바로 조화평균이다. 두 수 a, b의 조화평균을 그 정의대로 구해서 식을 정리하면 2ab / (a+b)가 나온다. 쉽게 말해 곱을 합으로 나눈 셈이다.

자동차가 동일한 길이의 두 구간을 달리는데 한 구간은 시속 30km로, 다른 구간은 시속 60으로 달렸다면, 전체 구간에 대한 자동차의 표정 속도는 30과 60의 조화평균인 시속 40이 나온다. 한 구간의 길이가 30km였다고 생각해 보면 가는 데 시속 30으로 1시간, 시속 60으로 30분이 걸렸을 터이니 전체 60km를 1시간 반 만에 주파하는 속도는 시속 40이기 때문이다.

반대로 길이가 중요하지 않고 소요 시간의 절반을 시속 30으로 달리고 나머지 소요 시간 동안 60으로 달렸다면 자동차의 표정 속도는 응당 산술평균인 시속 45가 될 것이다. 관점의 차이를 이해하시겠는가?

학교에서 조화평균은 병렬 연결된 저항들의 전체 저항값을 구할 때 정도에나 쓰였지만 교통 관련 계산을 할 때 더욱 유용히 쓰일 수 있다.
어떤 노선에 버스가 5분 간격으로 다닌다고 치자. 그런데 5분으로도 모자라서 그 상태에서 3분 간격의 버스가 추가로 더 투입되었다면, 실질적인 배차 간격은 얼마로 좁혀졌다고 볼 수 있을까?

답부터 말하자면 이 값은 5와 3의 조화평균의 절반과 같은 1.875분이다.
5와 3의 최소공배수인 15분이라는 시간을 생각해 보면, 그 동안 5분 간격 버스는 3대가 다닐 수 있다. 그러나 3분짜리 버스는 5대가 다닐 수 있으므로 15분 동안 버스가 총 8대로 늘어난 셈이 된다.

따라서 실질적인 평균 배차간격은 15를 8로 나눈 1.875분이다. 5와 3의 조화평균인 3.75는, 5분 간격 버스와 3분 간격 버스를 합친 것이 3.75분 간격 버스 두 대를 합친 것과 동일한 증차 효과를 낸다는 걸 의미한다.

임의의 동일한 수들에 대해서 기하평균(G)은 산술평균(A)보다 크지 않으며, 조화평균(H)은 기하평균(G)보다 크지 않다는 것이 증명되어 있다. 그리고 아예 H=G^2 / A라는 항등식도 알려져 있다. 어떤 데이터에 대해서 두 종류의 평균값을 알고 있으면 다른 한 평균값은 그로부터 유도해 낼 수 있다는 뜻이 되겠다.

한편, 1/3, 1/4, 1/5 ~처럼 역수가 등차수열을 이루는 수열은 조화수열이라고 한다. A, A와 B의 조화평균, B으로 구성된 세 수는 응당 조화수열이다.
이건 등차나 등비수열도 아니고 도대체 무슨 의미가 있는지 궁금할 것이다. 하지만 자연에서 조화수열은 아주 직관적으로 쉽게 찾을 수 있다. 이름에 괜히 harmonic이 붙은 게 아니다.

일단 우리 눈에 사물이 비쳐 들어오는 원근법이란 게 반비례이기 때문에 조화수열과 관계가 있다. 직선으로 뻗은 도로에 균일한 간격으로 그어진 차선을 보자. 멀리 떨어진 놈일수록 중앙의 소실점에 가까워지고 겉보기 간격이 더욱 조밀해진다. 그 간격이 수학적으로는 바로 조화수열인 것이다.

거시적으로 보면 태양은 달보다 N배나 더 크지만 지구로부터의 거리도 똑같이 N배나 더 멀리 떨어져 있다. 그렇기 때문에 지구에서의 겉보기 크기가 둘이 거의 같으며 일식도 일어날 수 있다.

사람의 뇌는 두 눈이 보내 준 2차원 영상을 합성하여 3차원 공간을 인지하는 능력이 대단히 발달해 있다. 그런데 그 능력은 수학적으로 따지자면, 2차원 조화수열 간극으로부터 3차원 등차수열 간극을 유추하는 게 상당수를 차지하고 있을지도 모른다. 그만큼 조화수열은 우리에게 친숙한 존재이다.

그 다음으로 우리가 조화수열을 시각적으로 볼 수 있는 흥미로운 분야는 음악이다. 실로폰도 그렇고 파이프 오르간이나 하프도 그렇고, 음을 만들어 내는 매체는 저음이 언제나 길고 고음은 한 치의 예외 없이 짧다.

그런데 그 짧아지는 간격이 조화수열이다. 매체를 그런 간격으로 만들면 소리의 파형 주기는 기하급수적으로(=등비수열) 짧아지는 평균율 음계가 나오는가 보다. 어떻게 그게 물리적으로 가능한지는 잘 모르겠다.

2. 황금비

조화수열이라는 말이 나왔으니 말인데, 아름다움이나 조화 같은 걸 수학적으로 설명할 때 빠짐없이 등장하는 건 황금비이다.

기본 발상은 a:b = (a+b):a 비례식을 만족하는 a와 b의 비율이다. 음, 뭔가 심오하지 않은지? 쉽게 말해 긴 변과 짧은 변의 비율이, 긴 변과 짧은 변을 합한 것하고 긴 변과의 비율과 같은 걸 말한다. 이걸 식으로 표현하면 이차방정식으로 귀착되고, 황금비의 값은 (1+sqrt(5))/2, 대략 1.618이 된다.

황금비 상수는 뭔가 심오함이나 신비로움, 괴팍함이 느껴지는 초월수도 아니고, 간단한 이차방정식만으로 값을 구해서 모든 특성을 파악할 수 있는 평범한 대수적 수에 불과하다. 그런데 이게 왜 그렇게 중요한 걸까?

인간이 보편적으로 새벽 2시에 가장 깊이 잠들어 있는지, 저녁 8시에 죄책감 없이 가장 잔인해지는지는 잘 모르겠지만, 저 비율이 인간이 보편적으로 가장 심리적인 안정감과 균형과 조화를 느낀다고 그런다. 오죽했으면 golden ratio라는 이름이 붙었겠는가? 이것 말고 golden이라는 말이 붙은 개념은 “자신이 대접받고 싶은 만큼 남에게도 대접해 줘라”로 요약되는 golden rule 정도밖에 없다.

1 1 2 3 5 8 13 21~ 로 이어지는 그 유명한 피보나치 수열도 현재 항과 이전 항의 비율이 황금비로 수렴한다는 건 잘 알려진 사실이다. 일반항을 구하는 공식엔 응당 황금비 상수가 들어간다.

또한, 0부터 시작해서 x=sqrt(1+x)를 무한 반복해도 x는 황금비로 수렴한다. 계산 과정의 특성상 x는 sqrt(2)도 한 번 거치지만, 궁극적으로는 다른 수로 수렴하게 된다는 게 흥미롭다.
황금비는 역수가 자신에서 1을 뺀 값과 같다는 특징이 있기도 하다. (0.618...) 1/x = x-1인데, 이는 특별한 게 아니라 황금비의 정의의 특성상 당연한 귀결이다.

도형 중에서는 정오각형이 변 길이와 대각선 길이의 비가 황금비이다.
1마일이 대략 1.609km인 건 아무래도 황금비와는 관계가 없고 전적으로 우연인 듯하다.
또한 종래의 4:3 aspect ratio를 깨고 컴퓨터 화면이 가로로 좀 더 길쭉한 추세로 가는 것 역시, 사람들이 황금비를 심리적으로 더 좋아해서인지는 모르겠다.

한편, A4나 B4 같은 용지의 길이 비율은 황금비가 아니라 sqrt(2)이다. 본인은 A4 용지의 크기가 210*297mm인 건 알고 있었지만 그 비율이 sqrt(2)를 표방한 것인 줄은 전혀 모르고 있다가 최근에 알게 되고는 크게 놀랐다. 심심해서 297을 210으로 나눠 봤는데 딱 1.414...가 나왔으니 말이다.

이런 비율의 장점은 우리가 이미 실생활에서 적지 않게 경험한 적이 있지 싶다. 종이를 반으로 접어도 크기 비율이 접기 전과 동일하게 유지된다는 것.
즉, 황금비가 a:b = (a+b):a를 추구했다면, 용지는 a:b = b:a/2를 추구한 셈이다.
황금비가 길이가 1인 정오각형의 대각선 길이라면, sqrt(2)는 길이가 1인 정사각형의 대각선 길이이다.

원래는 조화수열에 대해서만 글을 쓰려고 했는데 어쩌다가 황금비까지 나오면서 얘기가 옆길로 샜는지 모르겠다. 둘은 실용적인 의미가 약간 유사점이 있다 보니 미묘하게 한 글로 엮이게 된 것 같다.

Posted by 사무엘

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 사무엘

‘수인선’이라 하면 대한민국 최후의 협궤 철도라고 굳이 철덕이 아니어도 우리나라 역사· 지리· 문화에 약간이나마 관심이 있는 사람이라면 다 알고 있다.
일제 강점기인 1937년에 개통된 수인선은 원래 더 먼저 만들어진 수려선(1930년)과 직결하여 경기도 여주까지 이어졌다. 여주에서 나는 쌀을 인천항으로 수송하여 일본으로 반출하려는 목적이었다.

그러나 대한민국 정부 수립 후엔 쌀을 인천항으로 나를 일이 없어졌고, 도로 교통도 발달하면서 이 장난감 같은 철도는 잉여로 전락하고 말았다. 그래서 수려선은 이미 1972년에 진작에 폐선되어 흔적도 없이 사라졌다. 참고로 현재의 국도 42호선이 수려선과 많이 겹쳤었다. 수원 시내 동쪽에서 수원 역 정문으로 닿는 그 도로가 바로 국도 42호선임.

그리고 수인선도 적자를 감당치 못하여 시간이 흐를수록 운행 구간은 축소되었고, 결국 1995년 12월 31일에 치른 종운식을 끝으로 운행이 중단되었다. (운행 중단이라 쓰고 폐선이라 읽는다 ㄲㄲ)

물론, 운행 중단과 폐선은 엄밀히 보자면 동일한 개념이 아니다. 가령, 서울 교외선은 여객 열차가 다니지 않는 운행 중단 상태이지만 폐선은 아니다. 그에 반해 수인선은 그 뒤로 선로가 관리되지 않고 방치되었으며, 협궤 열차 자체가 한국 철도에서 완전히 맥이 끊김으로써 폐선이나 다름없는 상태로 전락한 것이다.

그 수인선이 폐선된 지 딱 16년 반 만에 1차 구간이 부분적으로나마 표준궤 복선 전철로 부활하여 우리 곁에 돌아왔다. 만세! 개통 날짜도 2012년 6월 30일 토요일인 덕분에 본인은 전날인 29일 금요일에 회사 근무를 마친 후, 미리 시흥으로 답사를 갔다.

본인이 다니는 회사가 있는 곳은 판교이다. 자동차라면 성남에서 안산 내지 시흥으로 가는 경로로 우리의 친구인 외곽 순환 고속도로(고속국도 100호선)가 있지만, 우리나라 대중교통은 서울과 위성도시를 잇는 방사형 노선만 발달해 있을 뿐 위성도시 사이를 잇는 순환형 노선은 인프라가 무척 열악하다. 철도는 그게 더욱 심하다.

그래서 성남 버스 103번을 타고 서쪽으로 간 뒤, 4호선 인덕원 역에서 전철을 쭉 타는 경로를 택했다. 사실 버스가 워낙 느리기 때문에 이건 시간적인 메리트는 별로 없다. 인터넷 지도는 아예 서울 강남(분당선 - 2호선 선릉-사당 - 4호선)까지 매우 심하게 우회하는 지하철 경로를 제시할 정도였는데 차라리 그게 가장 빨리 가는 경로가 맞는 듯했다.

단지 나는 시간적으로 급한 상태가 아니고, 한국학 중앙 연구원 같은 생소한 지대를 구경하고 싶고, 외곽 순환 고속도로가 아닌 다른 길(안양판교로. 지방도 57호선)로 성남-의왕-과천을 횡단해 보고 싶어서 버스를 선택한 것이었다.

새로 개통하는 철도역이나 노선을 개통 당일 첫 차로 답사하러 내가 직접 그 전날에 미리 근처에서 외박까지 하는 건 4년 전(2008년 6월)의 서울 지하철 5호선 마곡 역 개통 방문 이래로 이게 두 번째였다.
전국이 거의 한 달 가까이 이상 고온과 가뭄에 시달리면서 찜통 같은 6월을 보냈는데 이 날 저녁부터 때마침 단비가 땅을 촉촉히 적시고 여행을 한결 더 운치 있게 만들어 줬다.

수인선을 타려면 출발역인 오이도 역 주변에서 대기하는 게 좋다. 하지만 거기 주변은 그냥 닥치고 아파트뿐이고 식당, PC방, 찜질방 같은 상업 시설이 눈에 띄질 않았다. 특히 오이도 역의 동쪽 방면인 3번 출구는 그야말로 잉여 황무지인 걸로 잘 알려져 있다. 오죽했으면 출구 역세권에 대해서 쓸 게 없어서 그냥 ‘동광장’이 끝이다!

그래서 본인은 부득이 그 앞의 정왕 역에서 내려서 거기 근처에서 외박을 했다. 이는 이튿날 실제로 오이도 역 주변을 살펴보니 정말로 현명한 선택이었다. 그래도 오이도 역에서 첫 차는 타야 하니 새벽 4시 무렵에 본인은 우산을 쓰고 어두컴컴한 빗길을 걸으면서 정왕에서 오이도 역으로 도보로 이동했다. 이것도 재미있는 추억이었다.
이런 과정을 거쳐 본인은 5시 30분에 오이도에서 송도로 출발하는 수인선 전동차에 성공적으로 탑승했다.

수인선은 세 단계에 걸쳐 개통될 예정인데, 이번에는 그 중 1단계가 개통한 것이다(오이도-송도). 아직 13km 남짓밖에 안 되는 짧은 구간이지만, 시흥시와 인천 광역시가 어떤 형태로든 철도로 이어지고, 인천 지하철 1호선 원인재 역과 환승이 가능해진 것만으로도 큰 효과가 기대된다. 그 유명한 수인선 소래 철교도 이 구간에 포함되어 있다.

2단계 때는 인천 시내를 좀 더 깊숙이 관통하여 수인선이 드디어 경인선 인천 역과 연결된다. 1단계 구간은 모든 역들이 지상이거나 지상 고가이지만(연수-송도 사이에 잠깐 지하 터널은 지남), 2단계 때는 지하역도 생길 것이고 특히 수인선 인천 역 승강장은 지하에 만들어질 거라고 알려져 있다. 현재 동인천 역에서 회차하는 경인선 급행 전동차는 나중엔 이 지하 인천 역까지 들어오게 될 것으로 보인다.

또한 2단계 구간에 포함돼 있는 용현 역이 개통되면 인하 대학교도 드디어 전철 역세권에 들게 될 것이다. 사실, 이 2단계 구간인 송도-인천은 수인선에서 가장 먼저 폐선된 구간이기도 하다. 무려 1973년이니, 수려선의 폐선과 시기적으로 별 차이도 안 난다.

마지막으로 3단계는 한대앞 역에서 수원 역까지 나머지 잔여 구간이다. 즉, 인천 다음으로 수원과의 연결이다. 여기는 수원 시내만 지하이고 나머지 교외 구간은 응당 지상이나 고가로 만들어질 것으로 보인다. 1995년 말 당시에 최후까지 영업을 하던 수인선 구간은 바로 여기였다.

한대앞-오이도는 복복선이 아니라 기존 안산선과 수인선 열차가 선로를 “공유”하게 된다. 이 구간은 안산선이 의도적으로 수인선과 동일한 선형으로 만들어지기도 했다. 또한 4호선 열차의 절반은 어차피 사당까지밖에 안 가기 때문에 안산선은 선로 용량이 남기도 하고 말이다.

그래서 인천-오이도-한대앞-수원이 연결됨으로써 수인선이 완공되고, 지금 기흥까지 가는 분당선도 수원까지 연장되어 내려오면, 수인선과 분당선은 수도권 남부를 도는 거대한 노란색 광역전철로 변모하게 된다! 이를 염두에 두고 수인선의 노선색은 분당선의 그것과 동일한 노랑으로 설정되어 있다. 마치 광역전철 중앙선과 경의선이 미래의 직결 운행을 염두에 두고 둘 다 옥색을 쓰고 있듯이 말이다.

아마 그때쯤이면 전철 노선도의 토폴로지도 크게 바뀌게 될 것이다. 지금까지 분당선은 동쪽으로 끝나고 안산선은 서쪽으로 끝나는 형태였는데 이젠 이들을 한데 이어 줘야 하기 때문이다.

지금 1단계 개통을 한 수인선은 다른 노선과 직결 운행을 하는 게 없이 오이도-송도만 짤막하게 왔다 갔다 하는 중이다. 6량 1편성이고 전철 중앙선과 비슷한 배차 간격인 15분당 1대 운행이다. 민자 사철이 아니라 전형적인 코레일 광역전철이기 때문에 독자적인 운임을 받는다거나 한 건 없다. 따라서 기존 기본 운임 체계에 따라 마음 놓고 타면 된다.

원래 오이도 역은 쌍섬식 승강장으로 한 섬은 상행, 다른 섬은 하행이 전담하고 있었다. 그러던 것이 수인선이 개통하면서 승강장의 용도가 반씩 분담되어. 한 섬은 안산선, 다른 섬은 수인선 승강장으로 바뀌었다. 시종착역은 플랫폼이 좀 많아야 할 텐데 저런 식으로만 운영해서는 회차 용량의 감소가 우려되긴 하지만, 안산선과 수인선 모두 배차가 최하 10분이 넘는 한적한 노선이고 둘 다 인상선도 있는 형태이니 그리 큰 문제가 되지는 않지 싶다.

수인선 1차 개통 구간의 주변 경치는 공장 아니면 고층 아파트들이다. 남동 인더스 파크는 남동 산업 단지를 쓸데없이 외래어 버프를 씌워서 표기한 것. 우리집에 있는 본드의 제조사인 ‘오공 본드’의 공장이 이 역 근처의 차창 밖에서 보였다.
인천논현 역은 서울 지하철의 논현 역과 헷갈리지 말라고 ‘인천’이라는 접두어가 붙었다. 사랑 침례 교회는 이 역에서 400m 남짓 떨어져 있다.

마치 지금 서울 지하철 6호선과 경의선 전철, 그리고 공항 철도가 공덕-DMC 사이에서 상당 부분 중복 구간이 존재하듯, 수인선과 안산선은 일부 구간을 중복 수준을 넘어서 아예 동일 선로를 공유한다. 하지만 대피선이 설치된 역이 많은 만큼, 수인선이나 오리지널 안산선(4호선) 중 어느 노선의 열차는 안산선 구간에서 표정 속도에 차이를 두어, 급행 형태로 좀 다니면 좋겠다.

본인은 수인선의 복선 전철 부활을 경축하는 바이다. 나머지 구간도 어서 개통하고 분당선-수인선이 경의-중앙선과 짝을 이루는 거대한 광역전철이 되는 날을 꿈꿔 본다. 그리고 안산선 구간과 만날 예정인 소사-원시선과 신안산선도 어서 개통하고 서울 지하철 7호선 연장 구간과 인천 지하철 2호선까지 개통한다면 철도 덕후로서 무진장 행복해질 것 같다. ^^

Posted by 사무엘

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

실용성을 떠나서 어떻게든 모아쓰기 형태의 한글을 찍을 수 있는 타자 기계를 완전히 최초로 만든 사람은 재미 교포 이 원익(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 사무엘

창세기 출애굽기 레~위기, 민수기 신명기 여호수아 ...
교회 다니는 분이라면 신구약 성경 목록가 다들 아시죠? 그런데 이 노래 멜로디의 origin이
1900년에 작곡된 일본 <철도 창가>라는 사실, 아십니까?
에, 그러니까 육당 최 남선이 지은 <경부 철도가> 같은 그런 노래입니다.

일본에 가면 심지어 전동차의 발차 경보음으로도 이 곡의 멜로디가 나옵니다.
철도와 성경 사이의 완벽한 연결 고리를 발견하여 대단히 기쁩니다.

저 곡 멜로디를 이용해서 경부선 역 목록가나 지하철 노선 목록가를 만들어 보면 어떨까 싶습니다.

자, 이것만 실으면 분량이 너무 적으니 아래 사진은 보너스.
지난 2010년 12월 21일, 경춘선에 복선 전철화 공사가 끝나고 무궁화호 대신 통근형 전동차가 첫 운행되기 시작했을 때의 모습입니다.
얼마나 철도를 사랑하고 철도 개통에 감격했으면 저러기까지 할까요? 진정한 철덕의 기상이란 게 무엇인지를 보고 도전을 받게 됩니다.

Posted by 사무엘

오늘날 PC에서 명맥을 유지하며 살아있는 데스크톱용 운영체제는 역시나 윈도우, 맥, 리눅스 3관왕이다. 다만 이들이 대등한 점유율이 절대 아니며, 셋의 점유율은 공비가 무려 10에 육박하는 등비수열을 이룬다.

맥이야 x86 계열 CPU로 갈아타고 기계의 가격도 내리면서, 옛날에 비해서야 정말 많이 대중화가 되었다. 또한 아이폰/아이패드가 모바일에서 워낙 큰 성공을 거둔 덕분에 맥북/아이맥까지 반사 이익을 보고 있기도 하다. 아이폰/아이패드에서 돌아가는 소프트웨어를 만들려면 결국 그 계열의 PC가 필요하니까 말이다.

그래도 윈도우에 비하면야 맥 사용자는 정말 10% 이내의 소수이다. 맥OS를 작정하고 써 볼 의향이 있는 게 아니라면, 맥 계열 기계는 비슷한 사양의 일반 컴퓨터보다 여전히 비싸며 구입 후에 서비스도 구리고 키보드· 마우스의 일부 동작 방식이 이질적이기 때문에 덥석 권할 게 못 된다. 솔직히 나도 지금의 맥북 살 돈으로 일반 노트북을 샀다면 아마 화면이 두 배 정도 더 큰 걸 살 수 있었지 싶다. 그러나 ‘스잡빠’, ‘앱등이’로 대표되는 굳건한 추종자도 있는 마당에, 이쪽 진영은 결코 없어지지는 않을 것이다.

맥은 소수이지만 인지도라도 있지 리눅스는 그조차도 없다. 리눅스를 서버도 아닌 데스크톱 로컬 환경의 주 운영체제로 쓰는 사람은 가히 소수 중의 소수이다. 작정하고 MS 진영을 반대하고 철저한 copyleft 정신으로 무장한 컴덕후 해커이거나, 잡스를 숭배하는 것처럼 리처드 스톨먼을 숭배하는(최소한 그의 인격이 아니면 그의 이념을) 사람 정도만이 리눅스를 쓰지 않을까 싶다.

물론, 맥이 예전보다 접근성이 개선된 것만큼이나 리눅스도 옛날에 비해서는 초보자가 쓰기 정말 편해지긴 했다. 하지만 그래도 초보자가 쓰기엔 리눅스는 인지도 있는 응용 프로그램이 부족하고, 뭘 세팅하고 바꾸려면 유닉스 명령줄을 다뤄야 하는 등 생소한 면모가 적지 않다.

(연구 목적으로 2010년 무렵에 VM을 만들어서 돌려 본 우분투 리눅스 9.x의 화면이다. 한때 리눅스의 그래픽 셸은 GNOME이냐 KDE냐로 갈라져 혼란스러운 편이었으나, 요즘은 결국 둘 다 지원하는 쪽으로 가는 추세라 한다.)

20년이 넘게 도스와 윈도우에만 길들여지고 10년이 넘게 윈도우 프로그래밍만 해 본 본인의 입장에서 맥 OS에 존재하는 주목할 만한 특징을 간추려 보면 다음과 같다.

가장 먼저, 운영체제의 시스템 메뉴와 응용 프로그램의 메뉴가 한데 완전히 통합되어 있다는 점이 매우 인상적이다.
Windows는 운영체제의 시스템 메뉴에 해당하는 시작 메뉴가 task bar에 있다. 이것은 응용 프로그램의 창에 소속된 메뉴하고는 당연히 완전히 별개이다. CreateWindowEx 함수는 창을 생성할 때 메뉴 핸들도 별개로 받는다.

그러나 맥은 화면 상단에 항상 고정되어 있는 시스템 메뉴에 응용 프로그램의 메뉴가 얹힌 형태로 나타난다. 이런 건 윈도우에서는 OLE 개체 embedding 상태에서나 어렴풋이 볼 수 있는 모습이다.

(제목은 워드패드인데 도움말에 나와 있는 건 그림판. 어?)

응용 프로그램 메뉴는 파일이나 도움말 같은 기본적인 것만 남고, 그 사이엔 개체를 제공하는 프로그램의 메뉴가 뜨는 것 말이다. 요즘은 이런 디자인도 과거 유물로 치부되어 별도의 프로그램 창이 따로 뜨는 형태로 바뀌고 있지만. (MS부터가 자기네들이 만든 표준 메뉴 인터페이스를 구닥다리로 치부하고 안 쓰려 하니 말이다)

맥에서는 시스템 전체를 통틀어 pull-down 메뉴는 하나만 있으며, 한 순간에 현재 활성화되어 있는 프로그램의 메뉴 하나만 볼 수 있다. 문서 창에 메뉴가 따로 달려 있지 않다. 그리고 맥에서 돌아가는 GUI 응용 프로그램이라면 반드시 이런 디자인을 따라야만 한다.

윈도우에서는 대화상자 하나만 달랑 띄우고 따로 메뉴를 만들기는 곤란한 프로그램의 경우, 대화상자의 시스템 메뉴를 customize해서 보통 ‘이동 / 닫기’만 있는 그 메뉴에다가 About이라든가 Always on top 같은 추가 명령을 넣는 경우가 있다. 그러나 맥은 어떤 프로그램에게라도 무조건 기본 메뉴가 주어지니 그런 식의 테크닉이 존재하지 않는다.

맥은 그런 기본적인 인터페이스가 모든 응용 프로그램에서 무조건 동일하기 때문에 윈도우처럼 무슨 오피스 200x 스타일 메뉴나 도구모음줄을 만들어 주는 GUI 툴킷이라는 게 존재하지 않는다. 윈도우에서야 보급 메뉴 대신에 그 자리에다 싸제 메뉴 창을 얹어서 보급 메뉴처럼 동작하게만 만들면 custom UI를 손쉽게 만들 수 있지만, 맥은 그렇게 할 수 없으니 말이다.

비주얼 C++의 MFC 프로젝트 마법사를 보면, GUI 응용 프로그램을 전통적으로 MDI, SDI, 대화상자라는 세 형태로 분류한다. 그런데 맥에서는 어떤 형태의 프로그램도 일단은 가장 범용적인 MDI에서 시작한다고 볼 수 있다. 실제로 문서 창은 하나밖에 생성하지 않는 프로그램이라 할지라도 말이다. ‘<날개셋> 타자연습’을 맥용으로 만든다면, 프로퍼티 페이지의 밖에 존재하는 ‘사용자 로그인’이나 ‘종합 환경설정’ 같은 명령은 응당 메뉴에서 내리는 명령으로 바뀌어야 할 것이다.

또한 맥은 동일 프로그램의 중복 실행에 대한 개념이 Windows와는 다르다. 같은 프로그램은 한 번만 실행되고 그 동일한 프로그램이 여러 문서를 담당한다는 MDI 사고방식이 맥은 더욱 엄격하다. 그래서 맥 OS의 task bar에 해당하는 dock은 프로그램이 실행됐냐 안 됐냐의 여부만 표시되어 있지만, 이 아이디어를 차용한 윈도우 7의 task bar는 프로그램의 중복 실행 개수도 살짝 표시하고 있는 것이다.

이런 디자인 때문에, 맥에서 프로젝트 단위로 문서를 다루는 프로그램은 내부 구조가 많이 복잡해진다. 개발툴이 그런 예 중 하나이다. 비주얼 C++이야 여러 개를 실행해서 제각기 프로젝트를 열면 되지만, xcode는 프로젝트별로 각각의 문서창을 차지하고 있으면서 그 내부에서 또 파일을 편집하는 창을 관리해야 한다.

맥 응용 프로그램은 마지막 문서 창이 닫혀서 문서가 하나도 없는 상태에서 키보드 포커스가 다른 프로그램으로 넘어갈 때 자동으로 종료되는 편이다. 이런 동작 방식은 Windows에서는 볼 수 없던 모습이다.
물론 모든 프로그램이 그러는 건 아니다. 대표적으로 Finder도 파일 표시(윈도우로 치면 탐색기 창 같은) 창이 하나도 없이 포커스가 바뀌더라도 종료되지 않고 언제나 실행되어 있는다. 내장 웹브라우저인 사파리도 마찬가지이다.

키보드로는 Alt+F4에 해당하는 Cmd+Q를 누르면 언제나 프로그램이 종료된다. 단, 윈도우의 Alt+F4는 그냥 창을 닫는다는 보편적인 용도도 포함하는 단축키인 반면, Cmd+Q는 언제 어디서나 해당 응용 프로그램을 완전히 종료시킨다는 의미 차이가 있다.

윈도우 프로그래머라면, 맥에서는 저런 것뿐만이 아니라 응용 프로그램의 파일 구성까지 상상도 못 할 정도로 다르다는 사실에 더욱 놀라게 될 것이다. 단순 실행 파일 말고 GUI 응용 프로그램은 아이콘, 리소스, 구성 파일이 한데 담긴 패키지 형태로 배포된다. 파일 시스템상으로는 디렉터리 구조이지만 운영체제 내부에서는 가상적인 단일 패키지 파일로 취급된다.

맥에서는 그럼 레지스트리가 없으면 응용 프로그램의 설정 저장을 위해 어떤 기법을 쓰는지? 프로그램 추가/제거는 어떻게 하는지? 동일 개발자가 만든 여러 프로그램이 동일 코드를 공유하려면 DLL 같은 건 어느 디렉터리에다 집어넣으면 되는지? 맥은 윈도우 같은 32/64비트 코드 혼용 문제는 없는지?

알고 싶은 게 한두 가지가 아닌데 그런 걸 윈도우 프로그래머의 입장에서 잘 설명해 놓은 인터넷 사이트나 책은 아직까지는 난 못 봤다. 아무래도 둘은 서로 달라도 너무 달라서 두 플랫폼의 사고방식에 모두 완전히 통달한 개발자는 거의 없으리라 예상된다.;;

이렇듯, 그토록 쉽게 다가설 수 없는 이질감에도 불구하고, 맥 OS는 좀 써 보면 윈도우에서는 느낄 수 없는 참을 수 없는 고급스러움, 미적 감각이 느껴지는 건 부인할 수 없다. 맥 같은 녀석이 존재함으로써 IT 세계가 좀 더 다양해지고 MS의 독점을 약간이나마 견제하는 효과가 난 건 인류 전체의 관점에서는 그래도 이익이긴 한 것 같다.

Posted by 사무엘

Posted by 사무엘

Posted by 사무엘

우리나라의 여객용 철도 차량은 시설과 운임 체계가 기관차+객차(일반열차) 아니면 통근형 전동차(전철)로 비교적 경직되게 양분된 편이었다. 그러나 그것도 옛말이 되어 간다. 일반열차처럼 앞을 보는 좌석을 갖추고 있으면서 전동기가 바닥에 달린 동력 분산식 좌석형 고상홈용 전동 열차가 속속 도입되면서 기존의 여객 열차 운행 패러다임에 변화를 일으키고 있기 때문이다.

한국의 철덕후라면 이 점을 주목하지 않을 수 없다. 옛 EEC(우등형 전기 동차)의 뒤를 잇는 후손으로 현재 무엇이 있는지 살펴보자.

1. 공항 철도 직통열차 (2007)

서울 역-인천 공항을 무정차로 운행하는 열차로, EEC의 멸종 이후로 국내에 10여 년 만에 최초로 도입된 동력 분산식 좌석형 전동 열차이다. 좌석은 KTX와 동일한 고정식 좌석이며 따라서 역방향 좌석이 있다. 6량 1편성.
다만, KTX가 순방향과 역방향이 서로 마주보는 형태이고 중앙에 동반석이 있는 반면, 공항 철도 직통열차는 순방향과 역방향이 서로 등지고 반대쪽을 보는 형태이다. 항공 여행객이 이용하는 열차라는 특성상 짐칸도 따로 있다.

공항 철도 직통열차는 거리 당 임률이 KTX보다도 더 높아서 국내에서 가장 비싼 열차이다. 지금은 사실상 서울 역의 도심 공항 터미널에서 출국 수속을 받은 뒤 곧장 비행기 타러 공항으로 갈 사람들이나 이용하는 열차가 되었다. 좌석수에 비해서 잉여력이 너무 강해서 텅 빈 채로 운행되는 경우가 많지만, 운임이 워낙 독자적으로 비싸기 때문에 수지가 아주 안 맞는 건 아니라고 한다.

2. 누리로 (2009)

현재 가장 대중적인 인기를 ‘누리고’ 있는 전동 열차로, 무궁화호와 완전히 동일한 등급으로 기존 일반열차의 운임 체계를 따르며 운행되고 있다. 4량 1편성.
다만, 이 열차는 대놓고 서울-부산 무궁화호를 대체하는 게 아니라 현재로서는 오히려 서울-천안 급행 전동차를 대체하는 컨셉에 더 가깝다. 그래서 지금도 서울 역에서 누리로를 타는 곳은 서울-천안 급행열차가 출발하고 도착하는 제일 동쪽 끝 플랫폼이다. 운행 구간도 서울-부산이 아니라 수도권 전철 1호선을 따라 장항선으로 빠져서 신창까지 간다.

급행 전동차와 비슷한 수준으로 정차하지만, 가감속 성능이 좋아서 표정 속도가 높다. 수요가 많은 시간대에는 중련 편성하여 8량으로 달리기도 한다. 또한 명절에는 대전이나 익산 같은 더 장거리 구간을 운행하기도 하며, 서울-조치원-제천으로 충북선 구간을 달릴 때도 있다.
(참고로 누리로의 도입 이후에도 평일에 하루 3회 다니는 기존 서울-천안 급행 전동차는 여전히 건재하다)

3. ITX 청춘 (2012)

새마을호보다 명목상 ‘더 고급’ 등급인 준고속 2층 전동 열차이다. 독자적인 운임 체계를 쓰며 임률이 새마을호보다 약간 더 높다. 현재는 아직 경춘선에만 운행 중이다. (정확히는 용산-청량리-춘천 직결) 8량 1편성으로 의외로 길다.

공항 철도는 그 성격상 일반 통근형과 직통의 구분이 필수이고, 경춘선은 통근형만 굴리기에는 좀 긴 노선이며 통근 외에도 관광 기능을 무시할 수 없는 노선이다. 그러니 이런 곳에 좌석형 전동 열차를 투입한 것은 현명한 결정이다. 구닥다리 통일호가 다니고 디젤 기관차 무궁화호가 뒤를 잇던 철도 노선에 이런 최신형 전동차가 등장할 줄 누가 예상이나 했을까? 단, 이 열차 때문에 기존의 저렴한 경춘선 급행 전동차가 명맥이 끊어진 건 아쉬운 점이다.

누리로가 서울 역의 지상 전동차 승강장에서 출발하듯, ITX 청춘도 명목상 일반열차이지만 중앙선 전동차가 출발하는 그 승강장에서 1시간에 1대꼴로 출발한다. 여기는 천안 이남의 장항선 수도권 전철들만큼이나 일반열차 승객과 전동차 승객이 섞이기 쉬우며, 마음만 먹으면 부정 승차가 쉽게 가능하다. 승객 분리와 검표를 잘 해야 할 텐데 말이다.

.
.

위에서 소개된 세 열차들은 정체성이 광역전철과 일반열차 사이를 좀 오락가락하는 위치에 있다. 덕분에 20년이 넘게 한국인들의 뇌리에 각인되어 왔던 (KTX)-새마을-무궁화 열차 등급 구도가 문란해지고 있다.

이들 이후로는 중앙선 같은 험준한 간선 철도를 달리는 새마을호급 TTX 틸팅 준고속 전동차가 등장하여, 퇴역하는 기존 새마을호의 역할을 대체할 것이다. 대세는 역시 전동차이다.
KTX 산천 이후에는 사실 고속철조차도 동력 분산식으로 개발 중이다. 승강장만 고상홈으로 바뀌면 일본의 신칸센하고 형태가 완전히 같아진다.

한 우진 님께서 이 글과 거의 같은 주제로 글을 쓰신 적도 있으므로 참고하시라. (☞ 클릭)

Posted by 사무엘