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

한메 타자 교사(HTT).
정말 전설적인 타자 연습 프로그램이며, 이후에 등장한 동일 분야 프로그램들의 근간을 제공했습니다.

아래아한글 1.x와 비슷한 연배의 프로그램이죠. 90년대 초반에 개발된 도스용 응용 프로그램들이 90% 이상 볼랜드 터보 C 2.0 기반이었고 그래픽 모드 동작을 위해 BGI 라이브러리를 사용한 것과는 대조적으로 HTT는 MS C 6.0 기반입니다. (비주얼 C++ 6.0이 아님!)

  당시에 통용되던 프로그램들을 좀더 살펴보면,
페르시아의 왕자도 1, 2 모두 MS C로 개발되었고 볼랜드 계열 빌드가 아닙니다.
아래아한글은 16비트 바이너리들은 전통적으로 볼랜드 컴파일러를 써 왔지만, BGI 라이브러리 기반은 물론 아니지요.

HTT는 제가 두벌식을 쓰던 시절과 맥을 함께 했습니다. 세벌식 연습은 도스용 한컴 타자 연습으로 주로 했고 HTT를 쓰지 않았거든요. 390에서 최종으로 갈아타던 시절에는 박 정만 님이 개발한 <광타>의 도움을 받기도 했습니다. 그때가 얼마나 불모지였냐 하면 390 말고 최종 연습을 정식으로 지원하는 프로그램이 “없었습니다.” 윈도우 운영체제는 말할 것도 없고 아래아한글 97이 제공하던 최종 자판에도 오류가 있었습니다. 지금이야 워디안 때부터 최종 자판이 제대로 지원되기 시작했고, 윈도우용 한컴 타자 연습에도 최종 배열이 추가되긴 했지만, <날개셋> 타자연습이 첫 등장하던 시절엔 정말 제 프로그램의 지위가 더욱 독보적이었었습니다.

한메 타자는 일부러 이렇게 만들기라도 했는지 문장 연습하는 감이 묘하게 좀 좋지 않았습니다. 키를 계속 누르고 있으면 글자가 생기는 느낌이 더디고 좀 latency가 느껴집니다. 아마 이것 때문에 그 당시 세벌식 연습을 한메 대신 한컴으로 사용하지 않았던가 생각됩니다.

두벌식으로는 단문도 700 이상은 정말 무리였지만 지금 세벌식으로 연습해 보니 800 넘는 것도 가뿐하군요. “드는 정은 몰라도 나는 정은 안다.”라는 문장은 완전 세벌식 최적화 문장이어서 1000을 넘기기도 했습니다.

그리고 베네치아 게임을 오랜만에 해 보니,
<날개셋> 타자 게임의 혹독하기 그지없는-_- 지옥 훈련에 단련돼 있는 저한테는 정말 애들 장난도 아니었습니다. 떨어지는 속도도 느리고 단어도 훨씬 더 짧고 쉬운 것들이고..!
1단계부터 시작해 보니 2만점대의 점수로 끝탄을 깼습니다. 껑충 바이러스가 두 번이나 걸렸습니다.

8단계부터 시작하니 클리어 시 보너스가 더욱 붙어 47000점대의 점수를 획득했습니다. 물론 단 한 번도 HP를 소모한 적이 없었으므로 재건 바이러스는 아무 의미가 없었죠.

<날개셋> 타자연습의 게임은 베네치아를 전혀 어려움 없이 가뿐하게 엔딩 보는 개발자 본인도 만신창이로 간신히 다 클리어할 정도로 월등히 더 어렵게 짜여 있습니다. 옛날 버전은 지금보다도 더 어려웠어요. -_-;; 난이도와 각종 주인공 밸런스들은 거의 05~06년 이후로는 더 수정 없이 완전히 정착한 듯합니다. 지금 이 상태가 딱 적당하며, 더 어렵게도, 더 쉽게도 만들 필요 없을 것 같습니다. 지금은 타자를 치는 인구가 훨씬 더 늘었으니 국민 평균 실력도 영어 실력만큼이나 더욱 상향 평준화해 있을 거라는 점, 모아치기 같은 세벌식 고급 입력 기능을 십분 활용할 수 있다는 점을 감안하면 말이죠.

옛날에 두벌식 쓰던 시절엔 베네치아도 6~8단계 정도만 되면 글자 떨어지는 게 무서워서 차마 못 할 정도였는데 정말 격세지감입니다. 그나저나 “에이즈 바이러스 퇴치!”와 “지뢰 바이러스”는 도대체 뭘 하는 놈이고 왜 넣었는지 모르겠습니다. 전자는 아무 효과 없는 꽝인 것 같고, 후자는 글자들이 지뢰에 부딪히면 점수가 깎이는 것 정도밖에 모르겠네요.

<날개셋> 타자연습 1.x를 개발하던 초창기 시절엔 한메, 한컴, 광타는 물론이고 신의 손, 번개손, 천타를 꿈꾸며 같은 당대의 경쟁(?) 프로그램들을 많이 참고했습니다. 개인적으로는 도스용 <신의 손>이 정말 완성도가 높다고 인정하며, 그 열악한 640*480 16컬러에서 어지간한 게임을 방불케 하는 비주얼 디자인을 연출해 낸 것에 최고의 점수를 주고 싶습니다. 게임도 나름 테마를 갖춰서 무척 잘 만들었죠.

아무튼, 한메 타자 연습을 보니 이런 저런 여러 생각이 들었답니다. 그리고 세벌식 만세입니다. =_=;;;

Posted by 사무엘

그동안 비주얼 C++에 대한 글을 적지 않게 썼었는데 이렇게 전버전의 특징과 역사를 정리해 본 적은 없는 것 같다.
역시 2003과 2005에 대한 설명이 가장 길다.

※ 1.0

MS C 7.0의 차기 버전으로서, 비주얼 베이직처럼 비주얼이라는 브랜드를 걸고 첫 제품이 출시되었다. 비주얼 C++의 역사는 초기에 Application framework라 불리던 MFC 라이브러리와도 역사를 함께 한다.

※ 1.52

윈도우 3.1 타겟을 지원하는 마지막 버전인지라 굉장히 중요한 위치를 차지하고 있다. AppStudio라는 통합 환경이 있기는 하나 도움말 열람, 리소스 편집 등은 여전히 다른 프로그램에서 따로 해야 했다.
프론트 엔드 GUI는 모두 16비트 프로그램인 반면, 커맨드 라인에서 동작하는 컴파일러, 링커 같은 주요 툴들은 도스 익스텐더 stub을 내장하고 있는 32비트 PE 포맷인 점이 무척 인상적이다.

이 시절에 컴파일러는 도스/윈도우 모두 그것도 메모리 모델별로 다 지원해야 했기 때문에 타겟 지정하는 옵션이 무척 까다로웠던 것 같다. 그리고 kernel32, gdi32, user32처럼 API가 분야별로 나뉘어 있는 게 아니라 윈도우 API import 라이브러리가 한 파일에 다 들어있었다.

군대 갔다 온 분, 특히 육군 쪽으로 갔다 온 분은 ‘상호 존중과 배려’라는 표어에 매우 익숙할 것이다. 실제로 이걸로 검색해 보면 군대 관련 사이트, 블로그 포스트들이 제일 먼저 많이 뜬다. -_-;;
그런데 윈도우 3.1만큼 이 문구가 잘 들어맞는 환경도 별로 없을 것 같다. 프로세스들이 혼자 시스템 자원 CPU 시간을 절대 독점하지 말고 다른 프로세스에 대한 자발적인 ‘상호 존중과 배려’로 멀티태스킹을 서로 만들어 가야 하기 때문이다. ^^;;

※ 2.0

32비트 타겟으로 나온 첫 버전으로 알려져 있으나, 그 시기가 윈도우 95가 나오기도 전이고 NT는 점유율이 미미하던 때였다. 시대를 너무 앞서 가는 바람에 주목을 별로 못 받은 전설 같은 존재이다.
(그나저나 그렇다면 94년 이전에 윈도우 NT 3.1의 각종 바이너리들은 무엇으로 빌드했는지 궁금하다. MS 자체적으로만 쓰는 내부 컴파일러? ㄱ-)

32비트 환경에서는 메모리 모델 구분이 없는 대신, CRT에 링크 방식(static/DLL)과 멀티스레드 지원 여부라는 개념이 새롭게 생겼다.

※ 4.0

DirectX에 4라는 버전이 없는가 하면 비주얼 C++에는 3.x대 버전이 없다. 내부적으로 꾸준히 버전업이 돼 온 MFC의 버전 번호에 맞춰 곧바로 4.0으로 건너뛰게 된다. 참고로 윈도우 95의 워드패드가 웬 듣보잡 MFC 3.0 기반인 점이 흥미롭다. 98 이후부터는 전부 MFC42 기반으로 바뀌었음.

4.0에 와서야 비로소 오늘날의 비주얼 C++과 상당한 골격이 갖춰졌다. 즉 코딩, 리소스 편집, 클래스 마법사, 도움말 열람을 한 프로그램에서 할 수 있는 진정한 통합 환경 Developer Studio가 이 버전부터 생겼다. msdev.exe라는 프로그램 이름은 훗날 6.0까지 이어졌다.
이때는 아직 16비트에서 32비트로 한창 넘어가는 과도기였기 때문에 Win32s 타겟이 지원되기도 했다.

참고로 MS에서 개발한 프로그램 중에서 MFC를 쓴 놈은 고작 워드패드, 그림판, 그리고 비주얼 C++ 6 이하 버전의 IDE와 관련 몇몇 유틸리티(Spy++, Dependency Walker) 정도? -_-;;

※ 4.2

4.1을 거쳐 4.0이 마이너 업그레이드된 버전으로, 제법 인지도를 얻었다. ActiveX 컨트롤, STL 같은 기능이 추가되고 MFC DLL의 이름도 이때부터 MFC42로 이름이 바뀌어 큰 뼈대의 변경 없이 훗날의 6.0까지 이어졌다. MFC42는 윈도우 98 이래로 운영체제가 이제 known DLL로 인정하는 마지막 버전 숫자이기도 하니 더욱 의미가 있다.

4.2에서부터 Win32s의 지원이 중단되었다. 오죽했으면 설치할 때 “이 버전부터 Win32s를 더 지원하지 않으니, 그 환경 개발하고 싶으면 이거 설치하지 말고 옛날 버전 쓰셈!”이란 경고문까지 나온다.

※ 5.0

GUI 껍데기는 거의 다 6.0처럼 바뀐 반면, 내부 구조와 기능은 여전히 4.2와 비슷하다고 보면 되겠다. 도구모음줄과 메뉴가 MS 오피스 97 스타일로 바뀌고(하지만 내부 코드 베이스는 서로 완전히 다름) 대화상자도 리모델링되었으나, 도움말은 여전히 RTF 기반이고 인텔리센스도 아직 없었다. 이듬해에 나온 6.0에 밀려 완전히 존재감을 상실했다. 프로젝트 파일 포맷이 이때 처음으로 DSP, DSW로 바뀌었는데, 이 포맷은 결국 5와 6 두 버전에서만 쓰이고 이후 버전에서는 또 바뀌게 되었다.

이때부터 bool이 built-in type으로 지원되기 시작했다. 그리고 이때부터 빌드하는 EXE 파일에 PE 재배치 정보가 기본적으로 생략되게 되었다.

※ 6.0

나온 지 10년이 지난 지금도 어렵지 않게 찾을 수 있고, 윈도우 XP만큼이나 최장수 개발툴로 이용되고 있는 결정판이다. 이 버전 이후로 거의 4년 가까이 버전업이 없었고 다음 버전인 닷넷이 변화폭이 너무 크기도 했기 때문이다.

6에서는 인텔리센스, edit and continue, delay-loaded DLL 같은 획기적인 기능이 처음으로 추가되고 도움말이 별도의 MSDN 라이브러리로 독립함과 동시에 HTML 기반으로 모두 바뀌었다.
이 버전은 윈도우 9x에서 설치 가능한 마지막 버전임과 동시에 MSVCRT, MFC42 같은 known DLL만 사용하는 바이너리를 생성할 수 있는 마지막 버전이기도 하다. 주요 라이브러리를 DLL 링크하고도 DLL 배포 걱정을 할 필요가 전혀 없다는 장점이 있다.

4.2 때는 ClassView에 있는 각종 클래스, 변수 정보가 소스 파일을 매번 저장할 때에만 업데이트됐다. 이것이 내용이 바뀔 때마다 실시간으로 바뀌기 시작한 것도 5.0은 아니고 6.0부터인 걸로 기억한다.

※ 7.1 (2003)

비주얼 C++의 다음 버전은 처음엔, 버전 번호나 연도가 아닌 닷넷이라는 브랜드로 출시되었다. MFC를 써서 개발된 VC 특유의 전통적인 msdev.exe는 퇴출되고 devenv라는 MS 오피스 내지 비주얼 베이직 스타일의 IDE가 등장했는데, 이는 완전히 새로운 것이라기보다는 예전에 비주얼 스튜디오에 있던 Visual InterDev와 비슷한 형태였다. 단지 거기에다 외형만 MS 오피스 XP 스타일 UI를 그대로 물려받았다.

덕분에 비주얼 C++과는 영 인연이 없고 비주얼 베이직만의 전유물인 것 같던 Property grid가 도입되어 비주얼 C++ 특유의 등록정보 대화상자를 대체했다. 클래스 마법사도 이 형태로 대체됐다. 도움말은 5.0 시절처럼 IDE 내부에 띄울 수도 있고 6.0처럼 외부에 띄울 수도 있는 융통성 있는 형태로 바뀌었다.

이제 주류로 내세운 게 C#, 공용 언어 런타임 같은 닷넷 환경이긴 했지만 네이티브 C/C++ 쪽도 크게 향상되었다. 6이 표준대로 제대로 지원하지 않던 문법 내지 컴파일러의 버그 많이 수정되기도 하고 네이티브 wchar_t 형식이 지원되기 시작했으며, 6에서 첫 도입됐던 인텔리센스도 굉장히 강력해져 특히 #define 심볼에 대해서도 동작하기 시작했다. 링크 시점에서 코드를 생성하는 전역 최적화라든가 crash mini-dump 생성 기능도 이때 첫 도입된 기능이다. 닷넷 정도만 써 보면 이제 6.0은 충분히 열악함을 느끼기에 충분할 것이다.

공용 라이브러리는 이제 MSVCR71, MFC71로 바뀌었는데, 이 DLL은 최신 운영체제라고 해서 더는 기본 내장을 해 주지 않기 때문에 응용 프로그램이 알아서 자기 디렉터리나 윈도우 시스템 디렉터리에다 구비해야 한다. 이 점에 관한 한 6.0이라든가 side-by-side assembly를 사용하는 8.0 이후만도 더 못하고 무책임한 면이 없지는 않다. 또한 64비트 개발은 불가능하지는 않으나 불편하고 디버깅도 되지 않고 IDE 차원의 적극적인 보조는 못 받는 어정쩡한 위상을 차지하고 있다. 이 불완전한 면모들은 후속 버전인 8에서 보완되었다.

사실 7.1은 최초로 나왔던 ‘닷넷’(7.0)의 버그 수정판이다. 엄청난 기능이 도입되었던 만큼 첫 버전은 불안정하고 버그도 많았기 때문이다. 7.1 버전은 아래아한글, VMware, 스타크래프트 같은 다수의 상용 프로그램의 최신 버전 개발에 아직까지 쓰이고 있다.

※ 8.0 (2005)

이 버전부터 닷넷이라는 이름을 떼고 출시는 되었으나 8은 7.1하고 아무 단절도 없이 닷넷과 네이티브를 모두 지원하는 동일한 개발 도구의 연장선이다. 이 버전은 닷넷 초창기 버전인 7의 과도기적 불완전하고 2% 부족하던 면모를 속 시원히 보완한 게 무척 많았다. 요즘 어도비 사에서 나오는 프로그램들이 이 버전으로 개발되고 있다.

첫째, 별도의 플랫폼 SDK를 설치할 필요 없이 IDE 차원에서 64비트 빌드와 디버깅이 정식 지원된다.
둘째, 공용 DLL인 MSVCR80, MFC80의 배포 방식이 side-by-side assembly 방식으로 완전히 바뀌었다. 일각에서의 불만을 감수하고라도 이건 꽤 강한 정책이었다. 이와 덩달아, 리소스 편집기로 수동으로 해야 하던 메니페스트 생성/편집 기능도 상당 부분 자동화됐다.

셋째, for 문의 변수 scope처럼 그동안 표준을 어기고 있던 문법을 교정하고, CRT의 보안을 크게 강화했다. strcpy_s와 gets_s(대상 버퍼 크기), qsort_s(콜백 함수에 데이터 전달 가능), strtok_s(토큰 중복 호출 가능) 같은 함수가 새롭게 등장하고 strchr 같은 경우, C++에서는 const 포인터를 되돌리는 버전과 비const 포인터를 되돌리는 함수가 오버로딩으로 분리해 나갔다. 무척 신선한 변화라 느껴진다. STL 디버깅도 훨씬 더 편해졌다.
넷째, UI 상으로도 이제 MS 오피스 스타일에서 독립한 새로운 외형 비주얼을 갖기 시작했으며, 도구모음줄 아이콘도 256색으로 더 화려해졌다. 전통적으로 ClassView에 클래스와 멤버들이 한 트리에 쫙 나열되던 것이 멤버는 별도의 리스트에 뜨도록 바뀌기도 했다.
이 버전부터는 생성하는 프로젝트의 디폴트 기반 인코딩이 드디어 유니코드로 바뀌었다.

※ 9.0 (2008)

8이 질적으로 많이 바뀌었다면 9는 윈도우 비스타의 등장처럼 8 출시 이후에 생긴 변화를 IDE나 MFC 라이브러리 같은 데에 적극 반영하여 양적인 향상을 꾀했다. 또한 MS 오피스 스타일의 GUI를 손쉽게 만들 수 있는 feature pack을 드디어 도입하기도 했다.

이렇게 시대의 조류 때문에 생긴 변화를 제외하면 9는 네이티브 C/C++의 관점에서 봤을 때, 7에서 8로 넘어갈 때 같던 큰 변화는 느껴지지 않으며 따라서 8은 조만간 별다른 존재감 없이 9로 흡수될 걸로 예상된다. 완전히 새로운 기능으로는 보안 강화를 위해 링커에 추가된 시작 주소 랜덤화 기능 정도? 이 옵션은 MS 오피스 2007과 윈도우 비스타의 모든 바이너리에 기본 적용돼 있으며, 과거 Win32s의 잔재로나 기억되던 EXE 파일의 재배치 정보를 다시 끌어들인 장본인이기도 하다.

9는 8과는 달리 윈도우 2000도 설치되지 않으며, 윈도우 9x 계열은 아예 타겟 플랫폼에서도 완전히 제외되었다. 링커 옵션에서 바이너리의 최소 요구 운영체제 버전이 4에서 5로 껑충 뛰었고, 이보다 낮은 값은 지정 자체가 안 된다.
또한 single threaded CRT 라이브러리 옵션도 없어졌다. 이것만 빼면 그다지 아쉬울 것 없다.

Posted by 사무엘

※ QuickBasic

아래의 PB와 더불어 제 인생에서 거의 최초로 접한 “EXE 생성기”가 아니었나 싶습니다. 중학교 시절 저의 주된 장난감이었습니다. 특히 가장 대중적인 베이직 컴파일러였던지라 한글 입출력/그래픽/사운드/마우스/메모리 등 갖가지 분야의 공개/상용 라이브러리로 기능을 확장해서 프로그램을 만들던 기억이 납니다.

MS는 오로지 고객 편의 위주로 기존 관행을 확 깨는 새로운 제품 만드는 데는 정말 비상한 재주가 있다는 걸 인정해야겠습니다. 그래서 윈도우 9x 같은 타협안으로 소비자 시장을 우려먹기도 했고, 베이직 개발 환경만 해도 저런 대화형 구조에다가 라이브러리까지 특수한 EXE로 링크해서 ‘퀵라이브러리’(QLB)라는 개념을 발명하여, IDE에서 빌드도 없이 바로 프로그램을 실행시킨 것도 정말 대단하다고밖에 말할 수 없군요.

QB는 최종 버전이 4.5였고 그로부터 몇 년 뒤에 소위 MS Basic이라 불린 Basic PDS (전문 개발 시스템)가 7.0/7.1 (VS .NET 같군)라는 QB 후속 버전이 나오긴 했습니다. 하지만 차이를 전혀 모르겠어요. 오히려 기능 확장의 생명인 라이브러리가 호환이 안 되고 불편해서 널리 사용되지는 않았습니다. PDS 이후 MS는 비주얼 베이직으로 넘어갑니다. 마치 MS C 7 이후로 비주얼 C++이 나온 것처럼.

※ PowerBasic

볼랜드에서 Turbo Basic을 잠시 만들던 전 직원이 볼랜드를 나와서 따로 창조한 브랜드이죠. 베이직만으로 QB보다 월등히 빠르고 거의 C/C++ 수준의 효율적인 네이티브 코드를 만들어 준 덕분에 QB와는 별개 영역에서 사용자를 구축하고 있습니다. 저는 3.1을 써 봤습니다.

단점으로는 QB에 비해 역시 라이브러리 캐부족, 일부 QB와 호환되지 않는 문법, QB보다는 다루기 불편한 IDE. 그리고 PB도 아예 Win32 콘솔 프로그램은 만들어도 32비트 도스 익스텐터와의 연계는 없었던 걸로 압니다.
또한 QBasic도 지원하는 스크린 mode 13H (VGA 320x200 256색) 모드를 지원 안 하는 것도 너무너무 아쉬운 점.

세상에 베이직처럼 Dialect가 많은 언어도 별로 없는 것 같습니다. 요즘 베이직은 그냥 스크립트 언어처럼 쓰거나 아니면 .NET 구도에 맞춰서 문법 다 뜯어고쳐서 쓰는데, PB는 베이직으로 하드코어 네이티브 코드를 지향했다고 볼 수 있습니다. 참고로 베이직을 거의 어셈블리 수준으로 짬뽕시킨 언어 내지 툴로 ASIC이라는 녀석도 있었습니다.

※ Visual Basic

GUI 바로 만들고 거기에다 코드를 즉시 갖다붙이는 형태가 무척 재미있어서 잠시 갖고 놀아 봤습니다. 하지만 런타임 DLL이 필요한 EXE밖에 못 만든다는 걸 알고서 이내 좌절함. 그나마 5.0 이전 버전은 EXE 자체도 자바 내지 닷넷 같은 슈도코드 기반이지 네이티브 코드는 지원도 안 하고 있었고요.

아울러, 닷넷부터는 IDE가 언어 불문하고 한데 통합되었기 때문에 VB 특유의 그 개성 넘치는 IDE를 볼 수 없게 된 것이 좀 아쉽습니다.

※ Borland Pascal

언어 특성상 C/C++과는 비교가 안 될 정도로 빌드 속도가 월등히 빠르고 라이브러리 오버헤드도 훨씬 작아서(Hello, world! 프로그램의 exe 크기) 굉장히 좋은 인상을 받았습니다. 16비트 도스용 네이티브 컴파일러로는 그야말로 최고봉이 아닌가 싶습니다. 파스칼 언어도 제가 베이직에서 C/C++로 전환할 때의 과도기 컨셉 역할을 잘 해 주었습니다. 이걸로 뭔가 걸출한 프로젝트를 진행해 봤으면 하는 아쉬움도 있습니다.

파스칼은 교육용으로 무척 훌륭한 언어이고 간단한 문법 덕분에 빌드하기는 간편하나, C/C++보다 함축성이 굉장히 떨어져서 코딩하기는 번거롭습니다. 가령 정수 나누기 정수도 결과가 무조건 실수가 되고 일일이 형변환을 해야 하는 건 기계 입장에서는 직관적이지 못하죠. 또한 단축연산이란 것도 없고.

※ Turbo C/C++

고등학교 때 정보 올림피아드 준비하던 시절에 잠시 다뤘을 뿐, 제품 자체의 왕년의 영향력에 비해서 얘를 써 본 경험은 거의 없습니다. 본격적인 응용 프로그램 개발을 위해 필요한 프로젝트 세팅, 메모리 모델 설정 같은 것도 전혀 해 본 적 없습니다. 저는 16비트 C/C++과는 도스/윈도우 공히 인연이 없는 셈입니다.

※ Delphi

놀랍게도 제가 얘를 다뤄 본 건 95년에 나온 초창기, 그것도 16비트 버전인 1.0뿐입니다. 오브젝트 파스칼 언어로 비주얼 베이직 같은 프로그래밍을 할 수 있구나 하는 인상만 받고 더 진척된 건 없습니다.

델파이는 런타임 DLL이 필요한 EXE를 만드는 옵션 자체가 없고 기본적으로 EXE 크기가 2~300KB대 이상은 먹고 들어가는 걸로 알고 있습니다.

※ C++ Bulder

비베, 델파이 수준의 RAD 환경을 C++로도 만들어 버렸으니 대단하다는 인상을 받았음. 물론 다른 건 다 델파이를 따라해도 빌드 속도를 따라할 수는 없지요.
버전 3을 써 봤습니다. 골치아프게 Win32 GDI API 쓸 필요 없이 캔바스 객체에 접근하여 프로퍼티를 바꾸는 것만으로 선과 면 색을 바꾸는 것도 흥미로웠습니다.

하지만 RAD 용도로는 어차피 델파이가 한 역할 담당하고 있었고, C++ 빌더는 상대적으로 존재감이 덜했던 것 같습니다.
MFC도 지원은 하지만, 빌드 속도 내지 빌드된 코드의 성능이 MFC의 본고장인 VC로 빌드한 것보다 무척 뒤쳐졌던 걸로 기억합니다. 빌드 속도는 흠, pre-compiled header 설정을 안 해서 그런 걸까?

델파이와는 달리 C++ 빌더의 EXE는 기본적으로 VCL.DLL이던가 컴포넌트 DLL이 필요한 형태입니다. 스테틱 링크가 가능한지는 기억이 안 납니다.

※ Watcom C/C++

MS와 볼랜드 컴파일러의 공통점은 32비트 도스 익스텐더 기반 코드 생성을 지원하지 않았다는 것입니다. 자기네 컴파일러들이나 겨우 몇 MB 정도 추가 메모리 확보를 위해, 286용 16비트 도스 익스텐더 정도를 사용한 게 고작입니다.

그러던 차에, 상용 게임들 덕분에 유명하던 DOS4GW 기반 코드 생성을 지원하던 왓콤 컴파일러는 정말 신선한 충격이었습니다. sizeof(int)도 말로만 듣던 4바이트로 나왔죠.
최적화 성능도 매우 뛰어났던 걸로 기억합니다. 익스텐더는 다르지만 도스용 아래아한글 386 에디션도 왓콤 기반이었던 것으로 유명합니다.

하지만 라이브러리가 부족하고 IDE도 없는 이 컴파일러로 본인이 당장 할 수 있는 일이 별로 없었던 게 아쉽습니다.

※ DJGPP

자유 소프트웨어 진영의 위력을 보여준 불세출의 32비트 도스 컴파일러입니다. 소스까지 공짜, DOS4GW보다 stub 크기가 훨씬 작고 더구나 DPMI가 기제공되는 환경에서는(윈도우 도스박스 같은) 필요하지도 않은 CWSDPMI.
거기에다 rhide 같은 IDE와 알레그로 같은 무지막지한 게임 라이브러리.

빌드 속도가 좀 느리고 exe 크기가 살짝 좀 큰 게 압박인데, 그 정도는 좀 대형 프로그램 작성하다 보면 아무것도 아닙니다. 도스가 살아 있다면 계속해서 쓰고 싶습니다. 물론 윈도우용 GCC도 있다고는 들었지만.

※ Visual C++

여러 개발툴들을 거쳐 이제 최종적으로 정착한 도구는, 그 이름도 유명한 비주얼 C++입니다. 더 설명이 필요없으리라 믿습니다. 닷넷이고 뭐고 많이 나와도 역시 한글 IME를 직접 개발하다 보니 제게는 네이티브 말고 다른 계층은 필요하지가 않네요.

Posted by 사무엘

지금은 오나전 아련한 추억이 됐죠. ㄱ-

1. 포트 충돌이 일어나면 모뎀과 마우스를 동시에 못 쓰던 것. ㄲㄲㄲㄲㄲㄲㄲㄲ
(시스템 종료 후 컴이 자동으로 꺼지기 시작,
마우스 휠과 USB 포트, 키보드와 마우스 단자가 PS 포트로 변경...
한 97~99년을 전후해서 다 그렇게 바뀐 것 같더군요.)

2. 도스를 완전히 못 벗어난 윈도우 9x 특유의 블루 데드 스크린과
64KB 리소스 제약..
이건 지구상의 어떤 운영체제에도 없던 이상한 제약이 아니었나 싶습니다.
16비트에서는 도스, 아니면 풀 32비트에서 유닉스, OS/2급의 빵빵한 운영체제 이런 구도였지, 둘을 저렇게 짬뽕한 OS는 윈도우 9x 부류가 유일했으니까요. MS가 고객 수요에 맞춰 장사를 정말 잘 한 것입니다.

3. 물론 이건 운영체제라기보단 드라이버 탓이 더 크겠지만
윈도우 98 시절까지만 해도 멀티웨이브 안 되던 컴도 많았어요. -_-;;
사운드 카드가 동시에 한 프로그램밖에 쓸 수 없는 자원이었던 캐암울한 시절도 있었습니다. ㄱ-

윈도우 2000/ME로 넘어오면서부터

- 소프트웨어 시뮬만으로 미디 신시사이저 지원
- 멀티웨이브 본격 지원
- 메모리 스틱, 외장하드 등 어지간한 USB 기억장치를 자동 인식. "이 장치를 안전하게 제거" 메뉴 자체가 생김 (98 SE는 아직 그런 거 없음.)

꽤 많은 변화가 생겼던 것 같습니다. 과거의 제약이 차츰 사라졌죠.
윈도우 ME는 비록 악명은 높지만 최신 하드웨어 인식 잘 하는 건 98보다 뛰어나다는 걸 확실히 인정함.

그리고 마우스 포인터.
제 기억이 맞다면, 아마 윈도우 2000은 VGA 640*480 16 컬러에서 돌아갈 때도 마우스 포인터가 그래픽이 바뀌는 곳에서 깜빡거리지 않을 거에요. 그거 보고 무척 놀랐던 기억이 납니다.
XP부터는 이제 안전 모드에서도 VGA 16컬러는 볼 일이 없어졌고... ㄱ-

하드웨어 지원을 받아서 마우스 포인터가 깜빡거리는 게 없어진 것이 한 90년대 중반부터인데, 이때도 지원이 완전하지는 못해서 흑백 monochrome 기본 커서가 아닌 커스텀 포인터는 여전히 깜빡거리기도 했었습니다.

CD롬 부팅 후 곧바로 운영체제 설치가 가능해진 것도 2000부터이죠?
NT에 그런 기능 있었을 리는 없고,
9x 계열에도 그런 거 없습니다. 그래서 vmware에서 세팅할 때도 먼저 도스 + fdisk 파티션부터 만들어야 합니다.

Posted by 사무엘

<사진으로 보는 한국 철도 역사>
이런 책이라도 있으면 당장 사겠다.
풍부한 역사 검증에, 사진에, 주제별 색인까지!

어쩌다 비슷한 주제의 책을 검색해 보면 전부 철도청 시절의 정부 간행물이고, 지금은 다 절판되고 없다. ㄱ- 어쩜 이 분야로 자료가 왜 이리 열악한지 모르겠다.

앞의 글은 지하철 글이고 이번에는 어제 철도 연표를 뒤져 본 기억으로 새마을호의 역사만을 종합해 보고자 한다. 새마을호 애호가라면 이 날짜들을 꼭 기억하라.

1974년 8월 15일, 서울 지하철 1호선이 개통함과 동시에 관광호가 새마을호로 명칭 변경하여 운행 시작.
새마을호가 무궁화호, 통일호 같은 명칭보다 먼저 생겼다는 뜻이다. (밑줄 그으시길. ㄱ-) 나머지 명칭은 거의 10년 뒤인 84년 1월 1일부터 시행되기 시작했다. 시민들을 대상으로 명칭 공모를 83년 7월 4일에 했다.

1979년 1월 12일. 서울-경주 새마을호 운행 시작. 포항, 울산으로는 아직 안 갔다. 이때 새마을호는 지금 새마을호의 좌석이나 외형이 아니었다.

1983년 7월 1일. 열차 시각표를 전면 개정하여 운행 시간 단축. 다른 문헌을 종합하면, 이때 서울-부산 새마을호의 운행 시간이 4시간 40분이 되었다. 성능 좋은 특대형 기관차의 도입과 경부선 선형 개량 덕분에, 한창 열차 속도가 빨라지던 시절이었다.

1984년 8월 31일. 경부선 서정리-천안 구간에서 새마을호 150km/h로 시운전 성공. 역사적인 기록이다. 이곳은 지금까지도 KTX를 제외하고 전국에서 선형이 가장 좋으며 열차가 가장 빠르게 전속력으로 달리는 구간이다. 철도 기술 연구소 연구진의 노력의 결실이었다.
그런데 저런 말만 불쑥 있지, 이때 뭘 구체적으로 개선해서 속도를 끌어올렸는지 내용이 없던 게 아쉽다.

1985년 11월 16일. 83년에 이어 또다시 열차 시각표가 전면 개정된다. 지난해의 시운전 결과를 적용하여 열차 운행 시각은 더욱 단축되었으며 KTX 개통 직전까지 가장 빠른 시간인 서울-부산 새마을호 4시간 10분이 이때 달성되었다.

1987년 7월 6일. 오늘날 새마을호의 프로토타입인 전후동력형(PP) 디젤 동차가 운행되기 시작함. 대우 중공업에서 생산한 6량짜리 동차가 그 시초이다. 그 후 불과 사흘 뒤인 8월 9일부터는 주말에 중련편성 운행도 시작했다.

흔히 혼동하기 쉬운데, 새마을호의 과거의 트레이드마크이던 시속 150km 주행 및 서울-부산 4시간 10분 달성은 PP의 운행보다 먼저 별개로 일어난 사건이다. PP가 이를 최초로 달성한 것이 아님을 기억하기 바란다. 마치 공 병우 박사가 한글 타자기 자체를 최초로 발명한 분이 아닌 것과도 같은 이치이다.

1988년 언젠가부터, 새마을호 기내지인 레일로드가 비치되기 시작함.
1989년 10월 22일. 서울-울산 간 새마을호 운행 시작

1991년 11월 25일, 수도권 전철의 확장 공사로 떠들썩하던 바로 그 때 장항선에도 새마을호가 운행되기 시작

1992년 6월 30일, 새마을호의 차기 구도로서 고속철 기공식이 거행됨. (참고로 알아 두셈)
1992년 10월 1일. 서울-마산 간 새마을호 운행 시작

1993년 5월 1일. 포항까지 가는 새마을호 운행 시작. 아마 이것이 발전하여 이내 울산-포항 중련편성 새마을호가 되지 않았나 싶다.

1995~97년 사이에 새마을호의 도색이 노랑-초록으로 바뀌었다. 철도청 연표에 왜 이런 기록이 없는지 궁금하다.

1998년 8월 1일. 새마을호 안내방송에 일본어가 추가되었다.

1999년 12월 1일. 전국 철도역사에서 대합실, 승강장이란 말이 사라지고 맞이방, 타는곳 등으로 바뀌었다. 이때 용어 개편을 단행했는데, 이걸 잘 했다고 철도청은 한동안 이 오덕 선생님 같은 우리말 운동 진영에서 꽤 칭찬 받았다. 새마을호와는 관계가 없지만 중요하기 때문에 그냥 다시 소개함.

2000년 2월 10일, 철도청에서 6 sigma 경영방침을 선포함

2000년 6월 1일. 그렇다. 새마을호 객실 내부에 세계 최초로 영상정보 서비스가 개시되었다. 그 전에는 객실에 그냥 자막이 흘러나오는 전광판만 있었는데 모니터로 다 대체된 셈이다.
영상 서비스는 그 후로 약 7년 동안 지속되었으며, 아마 Looking for you도 2002년부터 06년까지 4년 남짓한 시간 동안 새마을호에서 들을 수 있지 않았나 추정된다. 이런 UI 쪽으로는 공식 문헌이 전무하며, 경험담으로 추측할 뿐이다.

Posted by 사무엘

※ 1.x 시절

윤곽선 폰트라는 개념이 없던 시절엔 도트용과 레이저용이라는 기묘한 구분이 있었습니다.
레이저용이라고 해 봤자 겨우 300dpi짜리 프린터였는데, 그때는 그 고해상도 비트맵 글꼴만 해도 제작 비용이라든가 컴퓨터 상의 처리 부담이 만만찮았습니다.
레이저 프린터용 자형의 존재 여부가 한 프로그램의 에디션을 구분하고 복사 방지장치 장착 여부를 결정한 것이나 다름없습니다.

※ 2.0, 2.1

일반용과 전문용으로 구분했습니다. 가격 차이는 거의 2.5배 정도.
글씨를 자유롭게 확대할 수 있게 되었기 때문에, 일단 레이저 프린터용 비트맵 자형도 일반용에 기본 내장은 되는 '거저 먹는' 양상이 되었습니다.
아래아한글 2.0은 우리나라 소프트웨어 역사에 그야말로 획기적인 한 획을 그었습니다.
하지만 컬러 인쇄와 윤곽선 글꼴, 맞춤법 검사기 같은 기능은 전문용에만 있었지요. 윤곽선 글꼴이 없었으니 일반용은 글씨 크기 조절이 사실 별 의미가 없었습니다.
전문용은 락이 걸렸습니다. 그리고 2.1 전문용은 386 전용 코드로 개발되었습니다.

※ 2.5

드디어 2.5에서 일반용과 전문용이란 구분도 없어지고, 대신 86, 386 코드 에디션 구분이 생겼습니다. 86 에디션은 제 기억으로 덧실행, 맞춤법 같은 기능이 없는 거 빼고 문서를 만드는 기능상으로는 거의 차이가 없습니다. 286 AT 기종에서도 드디어 컬러 인쇄와 윤곽선 글꼴을 구현해 냈습니다. 눈물나게 감동스럽습니다.
다만, 2.5부터는 영한사전, 추가 확장 글꼴 같은 '확장팩'이란 개념이 생겼고, 확장팩에만 락이 걸렸습니다. 락이 없으면 영한사전 메뉴는 비활성화됐고, 신명시스템 글꼴은 아무 말 없이 그냥 동작하지 않고 명조로 대체되어 나왔죠. "한글과컴퓨터 2"라는 폰트 드라이버 자체가 락이 걸렸던 것 같습니다.

※ 몇 가지 중요한 사실

- 아마 2350자에 없는 비완성형 한글에 대해 최초로 동작한 윤곽선 글꼴은 2.1에서 추가된 휴먼 안상수체 계열의 조합형 글꼴입니다.
- 신명조가 비완성형 한글과 옛한글까지 윤곽선화한 건 2.5나 3.0때부터입니다. 제 2수준 한자가 윤곽선화한 것과 시기가 비슷합니다.
- 1.X 시절부터 있던 샘물과 필기체는 정확하게 2.5에서 윤곽선화했습니다.

- 윈도우용 아래아한글 3.x에서부터 2.5 확장팩 글꼴이 락이 풀린 형태로 제공되기 시작했습니다. 윈도우용 버전은 기존 도스용 2.5의 락이 걸린 확장팩 글꼴도 바로 읽어들였을 뿐만 아니라, 3.0용 확장팩 자체도 락이 풀려서 도스용 2.5에다가 복사하면 바로 읽을 수 있는 형태로 글꼴이 들어있었다는 뜻입니다. 사용하는 폰트 드라이버가 "한글과컴퓨터 2" 대신 일반 "한글과컴퓨터"로 바뀌었습니다.

Posted by 사무엘

-- 철도 근성 수련을 원하는 후학들을 위해 알기 쉽게 정리한 한국 철도 역사. ㄳ!

경부선은 우리나라 최장거리 간선 철도망입니다. 고속도로와 철도 모두 경인 다음으로 경부가 건설되었습니다.

  서울-대전: 평지입니다. 열차가 가장 빠르게 달립니다. 지금의 KTX 경부 고속선, 경부 고속도로도 쫙 평행하게 달리기 때문에 서로 거의 만나지 않습니다.
  대전-대구: 소백산맥을 넘느라 경부선에서 가장 험준한 구간입니다. 고속도로 건설할 때도 이 구간에서 순직자가 가장 많이 났습니다. 길도 꼬불꼬불하고 고속선, 고속도로, 기존 철길이 막 제멋대로 교차합니다. 특히 김천이 이 세 길이 한데 만나는 곳입니다.
  대구-부산: 병풍처럼 둘러진 산에 낙동강 따라 천혜의 경치를 감상할 수 있는 구간입니다. 경부 고속도로는 아예 경주 쪽으로 가 버리니 볼 일이 없죠.

1905년 전구간 단선 개통.
일본은 한반도를 영원무궁토록 자기 식민지로 삼으면서 이곳을 대륙 침략의 허브로 삼으려고 했습니다. 그래서 본격적으로 조선 주권을 빼앗기 전에 철도부터 집요하게 건설했습니다.
서울과 부산을 잇는 노선이지만, 지름길인 상주, 용인 쪽은 지형이 너무 험해서 피했습니다. 그쪽과 얼추 비슷한 노선인 중부내륙 고속도로를 보십시오. 온통 고가, 터널인데다 전구간 개통도 무려 2004년입니니다. 그 당시로서는 기술로나 돈으로나 엄두를 낼 수 없었죠.

덕분에 김천, 대전, 수원을 경유하게 노선이 결정되었습니다. 특히 대전은 말 그대로 한밭이었다가 순전히 경부선 덕분에 엄청 대박을 보고 발전한 도시라 해도 과언이 아니죠.
그나저나 이 정도 규모의 철도를 놓기 위해 일본의 측량 기사들이 제멋대로 남의 나라 영토와 지형을 허락도 없이 얼마나 철저하고 교묘하게 측량해 갔겠습니까?
거기에다 노동력 착취는 둘째치고, 대대로 살아오던 집이나 밭을 하루아침에 거의 반강제로 헐값에 날린 주민들의 반발도 만만찮았습니다. 도시화, 산업화가 다 그렇듯이 경부선도 그 당시로서는 이런 흑역사를 남기고서 완공됐습니다.

경부선은 일제 강점기엔 경의선과 직결하여 북한은 물론, 중국까지도 가는 국제 철도의 역할까지 했습니다. 그렇게 교통량이 꾸준히 증가하자 1939년 전구간 복선 개통. 일본은 한창 전쟁에 미쳐 있던 차에 이미 또다른 간선인 중앙선을 건설하고 있었습니다. 물자가 부족한 전시인데다 중앙선은 애초부터 험준한 지형에 화물 수송용으로 계획되어서 경부선과는 비교할 수 없이 열악하고 굴곡이 심한 노선이 되었습니다. 조금만 언덕 나오면 빙빙 돌아 가고... 평균 운행 시속이 6, 70km밖에 안 됩니다.

그 후 1974년, 서울-수원간 수도권 전철 개통. 그 덕분에, 과거에 증기 기관차가 역사 속으로 사라진 것처럼 수도권 통근용으로 그때까지 운행되던 디젤동차가 서서히 퇴출되었습니다. 동력원만 전기로 바뀐 게 아니라 이 전동차는 서울 지하철 1호선(서울역-청량리)과 그대로 직결 운행을 하여 본격적인 지하철 시대도 열었습니다.

  중요한 사실: 개통 당시에는 지금의 중앙선 전철처럼 복선 구간에다 일부 역에 대피선만 설치해서 일반열차와 전동차가 선로를 공유했다는 것. 이때는 역 수도 지금보다 훨씬 적었고 완급 운행이라는 개념 자체가 없었습니다.

옛날에 미국과 소련이 우주 개발 때문에 체제 경쟁을 했던 것처럼 서울 지하철도 북한과의 체제 경쟁의 산물이 아니냐는 말이 나왔었습니다. 그런 말이 나올 만도 한 게, 북한에서는 73년에 평양 지하철을 먼저 개통했기 때문입니다.
일본은 이미 1920년대에 도쿄 지하철을 개통했으니 우리나라는 고속철은 일본보다 40년, 지하철은 반세기 가까이나 늦은 셈입니다.

1981년 말, 늘어나는 열차 수요를 감당하기 위해 서울-수원 수도권 전철 구간이 드디어 2복선으로 확장되었습니다. 철도 박물관에 다시 가 본 덕분에 정확한 정보를 입수했습니다.

1983년, 새마을호의 서울-부산 운행 시간이 5시간대에서 4시간 40분으로 단축되었습니다. 이 시기에 경부선 어느 구간에 선형 개량을 한 덕분이었습니다. 제가 알기로는 천안-평택 쪽입니다. 현재 경부선, 아니 전국의 일반열차 노선을 통틀어 열차가 시속 140~150km대로 가장 빠르게 달리는 구간이죠. (더 자세한 정보 필요)

1987년, 한국 철도 차량 역사에 한 획을 그을 전후 동력형(PP) 새마을호 디젤 동차가 대우 중공업에서 첫 생산되어 경부선에 투입되었습니다. 스포츠카 같은 날렵한 외형에 디젤 기관차보다 조용하고 가볍고 가속력 좋고, 자체 발전 시설도 있고. 아직 우등 고속이 생기기도 전이었는데 세계 최고급의 호화 인테리어!

저번엔 노선이 개선되고 이번엔 차량이 개선됨으로써 서울-부산 운행 시간이 4시간 10분으로 단축되었습니다. (동대구· 대전만 정차) 비행기 다음으로 빠른 교통수단이 되었습니다. 그때의 새마을호는 지금의 KTX 이상의 초호화 귀족 열차였습니다. 기내지 레일로드도 88년에 창간했죠.

그 후, 1999~2002년 그 사이에.. 서울-구로 3복선 개통.  (더 자세한 정보 필요)
만성적인 수송력 부족을 호소하던 경인선이 차츰 2복선 으로 확장되고 급행 전동차가 운행되기 시작했습니다. 그와 맞물려 경부선과 경인선 전동차가 합류하는 서울 구간의 선로 확장도 필요해졌고, 그 때문에 이 구간은 전국에서 선로가 가장 많고 열차가 가장 자주 다니는 3복선이 되었습니다. 완행 전동차, 급행 전동차, 일반열차 이렇게 한 쌍식입니다.

서울 외곽과는 달리 빽빽한 서울 한복판에서 선로 확장이란 매우 어려운 일이었습니다. 이 때문에 서울 구간은 방향별 복복선 대신 비효율적인 선로별 복복선이 되었습니다. 상대식 승강장이 그대로 쌍섬식 승강장으로 확장되지 못하고, 비효율적인 쌍상대식 승강장이 됐습니다.
게다가 선로를 평행하게 쭉 확장을 못하고 대방-노량진 사이에서 일반열차 선로가 꽈배기굴로 전동차 선로 맞은편으로 옮겨 가는 구조가 되었습니다.

사실 경부선은 최소한 수원까지도 3복선이 되어야 할 정도로 용량이 한계에 달했습니다. KTX와 일반열차, 일반열차와 급행 전동차 사이의 만성적인 신호 대기와 지연을 해결할 길이 없습니다. 경인선은 전동차밖에 없는 2복선인데도 워낙 절대적인 수요가 너무 많아서 지옥철이고, 경부선은 수요는 경인선만하지 않지만 일반열차 때문에 전동차가 부족해서 지옥철입니다.

2003년 수원-병점 수도권 전철 개통. 경부선 전철의 남쪽 한계가 30년만에 더 아래로 바뀌었습니다. 사실 천안-수원간 복복선 및 수도권 전철 공사는 1996년부터 진행되어 왔는데, 가장 시급하던 병점까지 먼저 개통을 한 것입니다. 승객 수요보다도 시설 면에서 훨씬 더 시급했습니다. 수원 역은 지금까지 전동차의 종점임에도 불구하고 전동차 회차 시설이 열악했기 때문입니다.

경부선에서 일반열차는 2복선 선로의 내선에서 달리고, 전동차는 외선에서 달립니다. 수원 역에서 운행을 마친 전동차는 다시 서울로 돌아가기 위해 선로를 바꿔야 하는데, 한쪽 외선에서 맞은편 외선으로 가기 위해 일반열차의 내선 선로를 평면 교차하며 침범해야만 했습니다. 이는 매우 바람직하지 못한 구조로, 경부선 전동차의 잦은 지연과 신호 대기를 야기했으며 전동차 증차에도 큰 걸림돌이었습니다.
이 문제를 해결하기 위해 일반열차를 취급하지 않는 인근 지역에 전동차를 입체 교차로 회차할 수 있는 역을 만들고, 천안 개통에 대비한 추가 차량 기지까지 연결해 놓은 것입니다. 이것이 병점 연장 개통의 의미입니다.

  (사례 연구: 한때 청량리-회기 구간에 승객의 원성이 하늘을 찌를 정도로 악명 높았던 전동차 지연의 원인도 맞은편 용산-성북 경원선 전동차와의 평면교차 때문이었습니다. 지금은 그게 용산-덕소 노선이 되어서 교차가 해소됐죠. 그러면 회기에서 성북까지 가는 열차 수가 줄었다는 뜻인데, 그 대신 병점에서 출발한 경부선 전동차가 청량리를 넘어 성북까지 가 줍니다. 단, 천안 발 전동차는 여전히 청량리까지만 가죠.)

2004년, 고속철 개통. 전기로 달리는 KTX가 기존선을 임시로 사용하는 대구-부산 구간이 전철화가 끝났습니다. 고속철 개통은 분명 의미 있는 일이었지만 일반열차 감축과 정차역 증가, 그리고 새마을호의 급격한 몰락을 알리는 신호탄이기도 했습니다.

2005년, 9년간의 공사 끝에 병점-천안이 2복선 전철화함과 동시에 수도권 전철 구간이 되었습니다. 수도권 전철 운임으로 천안까지 가는 시대가 열린 것입니다. 새로 건설된 구간은 전동차 완급 혼합 운행을 위한 대피선도 마련되어 있어 수원 이북보다 수월하게 전동차가 달릴 수 있습니다.
아울러, 이때 천안-조치원 구간도 전철화가 완료되어 경부선, 충북선, 중앙선의 삼각 전철 노선망이 완성되었습니다.

끝으로 지난 2006년 말에 경부선 전구간이 전철화가 끝났습니다. 이것도 최소한 90년대 말부터 꽤 오래 끈 공사였는데 한국 철도의 오랜 숙원을 이뤘습니다. 지형이 험준한 추풍령 쪽의 선형 개량 공사도 같이 했습니다.
경부선 첫 개통 100년만의 일이고 우리나라 국력과 교통 수요를 감안할 때 너무 늦은 감이 있습니다. 사실 고속신선 건설보다도 기존선 전철화부터 먼저 해야 했습니다.

중앙, 영동, 태백선 쪽에서나 볼 수 있던 전기 기관차가 서울-부산간 노선에도 투입되어 쌩쌩 달리는 것을 보노라면 말할 수 없는 희열을 느낍니다. 가감속력 좋고(지연 만회에도 유리함) 수송원가가 훨씬 더 싸고, 조용하고 운전하기도 관리하기도 더 편해서 기관사들이 아주 좋아합니다. 일부 철도매니아들은 경부선 전철화가 고속철 개통보다 더 의미 있는 일이고 경사· 쾌거라고 말하기도 합니다.
 

Posted by 사무엘