날개셋 모듈 설명

※ ngs3.dll (since 1.0, 2000)

<날개셋> 한글 입력기 커널이다. 문자열 처리, 옛한글 코드 변환, 한글 입력 오토마타 같은 본연의 임무부터 시작해서 자체 한글 비트맵 폰트 출력, 에디트 컨트롤, 심지어 제어판 UI도 들어있고 3.0부터 추가된 수식 해석과 XML 해석까지 다 담당하고 있다. <날개셋> 전체 소스 코드의 절반이 약간 넘는 분량을 이 모듈이 차지한다. 이제 UI 엔진까지 얹으면 커널의 덩치는 더욱 커질 것으로 보인다.

※ ngsedit.exe (편집기. since 1.0, 2000)

<날개셋> 한글 입력기는 처음엔 이런 자체 한글 MDI 에디터로 출발했다. <날개셋>이라는 커널의 기능을 가장 이상적으로 활용할 수 있는 전용 환경이자 가장 기초적인 프런트 엔드가 이 프로그램인 셈이다.

※ ngsx.nip (기본 플러그 인. since 2.x, 2002)

플러그 인이라는 개념은 본인이 거의 2.0을 개발하던 시절부터 생각하고 있었다. ngs3이라는 호스트가 기능을 확장할 수 있는 여러 프로토타입을 제시하면 플러그 인은 그 프로토타입대로 다양한 기능을 구현하여 호스트가 이를 끌어다 쓰는 것이다. 처음엔 텍스트 필터 정도만 액세서리 정도로 플러그 인이 담당하다가 이제는 빠른설정 도우미, 동시입력 스키마 등 다양한 분야에서 이 기본 플러그 인이 기능을 제공하고 있다.

※ ngsime.ime (외부 모듈. since 3.0x, 2004)

그저 편집기에만 머물러 있던 <날개셋> 한글 입력기는 3.0 버전대에서 외부 모듈이 개발되면서부터 진짜 활로를 텄다고 해도 과언이 아니다. 완전 생소한 분야이다 보니 초창기에는 온갖 불안정 문제, 버그에 시달렸으나 경험과 노하우가 쌓이면서 그런 문제들은 차츰 해결돼 갔다. 이 모듈은 단일 바이너리로 윈도우 95의 IME부터 비스타의 TSF 프로토콜까지 가장 세밀하고 탄탄하게 잘 지원하고 있다.

※ uniapi9x.dll (since 3.41, 2005)

윈도우 9x에서 윈도우 유니코드 API 호출을 받아 주는 자그마한 호환성 레이어로, 21세기 초에 MS에서 개발한 unicows (MSLU) 라이브러리와 동일한 역할을 하는 모듈이다. <날개셋> 3.0 개발 당시에 그 MS 솔루션의 사용을 검토했다가 뭔가 문제에 부딪쳐 도입을 포기하고, 대신 잠시 NT 계열 에디션과 9x 계열 에디션을 따로 배포했던 적이 있다. (배포 패키지 만들기가 무지하게 번거롭고 불편했음.-_-)

그러다가 3.41에서는 해당 기능을 자체 구현에 성공함으로써 <날개셋> 한글 입력기, 특히 외부 모듈은 플랫폼 계열을 완전 정복한 무지막지한 프로그램으로 거듭날 수 있었다. 이 모듈은 32비트 PE 포맷에 특화된 루틴이 들어있으며(x86 어셈블리까지는 아니지만-_-), 64비트 에디션에는 당연히 들어가지 않는다.

※ ngsconv.exe (since 5.0, 2008)

뭔가 변환과 관련된 모든 뒷바라지를 담당할 유틸리티로서, 5.0에서 첫 도입되었다. <날개셋> 3, 4 방식으로 저장된 입력 설정(유형, 글쇠배열 등 포함)을 새로운 5.0 방식으로 변환하는 것이 가장 기본적인 용도이며, 이 외에도 <날개셋> 3, 4 방식으로 저장된 변종 옛한글, 한양 PUA, 유니코드 1.x 방식 옛한글과 5.2 방식 옛한글 사이의 변환도 파일과 클립보드 모두 지원한다. 유니코드 상에서 현존하는 모든 옛한글 표현 방식을 중재하는 역할을 한다는 뜻이다.
시간이 흐르고 앞으로 한글 코드, <날개셋> 프로그램 체계가 또 바뀐다면 이 변환 유틸리티의 역할도 더욱 커질 것이다.

※ ngspad.exe / padspyxx.dll (since 5.3, 2009)

실행은 편집기 실행하듯이 EXE로 하지만, 기능은 외부 모듈처럼 여타 환경에서의 한글 입력 역할을 하는 제 3의 중간 계층에 속하는 프런트 엔드이다. 이 역시 거의 3, 4.x 버전 시절부터 상상을 하고 있었으나 여건이 안 되어 추진하지 못했다가 5.0에서 드디어 한글 코드 체계까지 정립에 성공한 뒤 추진하기 시작했다. 문자 입력 솔루션으로서 <날개셋> 한글 입력기의 위상을 완전히 새롭게 자리매김할 아이템으로 기대 중이다.

훅킹 기반으로 IME/TSF 동작 방식을 흉내내어 응용 프로그램에다 한글 조합을 전달하거나 키 입력을 속인다. 가령, 단축키까지 드보락 같은 다른 영문 글자판으로 완전히 바꾸는 것 역시 이 새로운 프로그램으로 가능한 것 중 일부가 될 것이다. 또한 <날개셋> 한글 입력기의 UI 엔진으로 구현한 각종 포인팅 장비 입력이나 화상 키보드, 문자표 등을 일반 프로그램에서 꺼내서 사용할 수도 있게 된다.

윈도우 95 이래 모든 운영체제에서 실행 가능한 다른 모듈과는 달리, 이 새로운 모듈은 동작 방식의 특성상 윈도우 2000 이상 전용으로 설계될 예정이다. 물론 이것도 사실상 아무 제약도 아니다.

※ padui.nip (since 5.3, 2009)

ngsX에 이어 드디어 두 번째로 개발되는 플러그 인이다.
현재 ngsime.ime의 내부에 들어있는 “후보 선택 UI”와 “화상 키보드” UI가 여기로 옮겨져서 외부 모듈과 ngsPad(가칭)가 공유하게 될 것이다. 그리고 한자 부수 입력, 문자표 같은 다른 액세서리가 추후 개발된다면 이 역시 이 모듈에 들어가서 편집기, 외부 모듈, ngsPad가 모두 공유하게 될 것이다.

※ NgsType.exe (타자연습 프로그램. since 2001)

<날개셋> 한글 입력기 1.x 버전대부터 개발되어 온 이 프로그램은 세벌식 자판의 보급과 저변 확대에 지금까지 큰 기여를 했다. 특히 90년대 말~00년대 초에 개발되었다가 지금 더 버전업이 되지 않고 있는 많은 타자연습 프로그램과는 달리 <날개셋>은 기능상 큰 변화는 없을지언정 꾸준히 버그 수정과 유지 보수가 돼 왔다. (비록 개발 우선 순위는 입력기 개발보다 언제나 뒷전이지만)

이 프로그램은 <날개셋> 한글 입력기에 포함되어 있는 애플릿이 아니라 입력기를 사용하여 따로 개발된 정식 애플리케이션(응용 프로그램)이다. 입력기와는 달리 MFC를 사용해서 개발되었고 재컴파일 가능한 소스가 공개되어 있다.

여타 프로그램에 비해 특히 주목할 만한 점은 정확도가 융통성 있게 계산된다는 것, 자체적인 문단 정렬 기능 덕분에 다양한 형태로 연습글을 배치할 수 있다는 것, 세벌식에 특화되어 제작된 게임 정도가 되겠다. 개인적으로 게임 그래픽 개선과 네트워크 연동이라는 두 숙제가 남았다고 본다.
세벌식 외에 다른 글자판의 ‘익힘’ 기능을 추가할 계획은 없다.

Posted by 사무엘

2010/01/10 23:43 2010/01/10 23:43
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/39

Trackback URL : http://moogi.new21.org/tc/trackback/39

Leave a comment

훅킹 프로그래밍

윈도우 훅킹은 운영체제의 내부 메커니즘(주로 메시지)을 가로채어 시스템 전체의 동작 방식을 바꾸는 매우 강력한 기법입니다.

이런 훅은 우리 프로세스 안의 특정 스레드 안에다가만 설치할 수도 있고 시스템의 모든 스레드에다가 설치할 수도 있는데, 32비트 운영체제로 오면서 후자 같은 global 훅(혹은 시스템 훅)을 설치하기 위해서는 훅 프로시저는 반드시 DLL에 따로 존재해야 하는 약간의 번거로움이 생겼습니다.

global 훅은 동작 방식의 특성상 모든 프로세스들에 나의 코드를 주입하는 가장 간편한 방법입니다. 굳이 윈도우 메시지 훅킹이 아니더라도 다른 종류의 훅킹을 위해서라도 윈도우 훅이 사용됩니다. 한컴사전의 노클릭 단어 인식이라든가 과거의 한스타, 그리고 Dependency Walker의 EXE 프로파일 기능처럼 API 훅킹이 동원되는 프로그램도 살펴보시면 별도의 DLL 파일이 존재하는 것을 알 수 있는데, 이는 API 호출을 변조하는 코드 자체를 삽입하기 위해서 윈도우 훅을 사용한 것입니다.

Global 훅은 완전히 특이한 프로그래밍 패러다임을 제공합니다. 다른 프로세스에서 완전 제각기 따로 실행되는 함수를 만들 수 있습니다.
가령, A라는 프로세스에서 B라는 DLL에 들어있는 훅 프로시저로 global 훅을 설치했습니다. 그러면 A와 B 사이의 통신 방법이 문제가 됩니다. 통상 A는 B의 동작 방식을 결정하는 입력 데이터를 주고, B는 훅킹을 통해 얻은 결과를 A에다 전달해야 할 것입니다.

이를 위해 보통 메시지를 쓰면 무난하죠. B에서 A로 통신할 때야 우리끼리만 쓰는 WM_USER+n이라든가, 심지어 WM_COPYDATA를 바로 보내도 무난하지만, 다른 프로세스 안에 존재하기 때문에 메시지가 겹칠 우려가 있는 B를 “향해서” 메시지를 보낼 때는 RegisterWindowMessage로 값이 안 겹치는 게 보장되는 별도의 메시지를 등록해서 쓰는 게 안전합니다.

또한 프로세스 A가 자신의 주소 공간에 로드되어 있는 DLL B의 변수값을 바꾼다고 해서 다른 프로세스들의 주소 공간에 로딩되어 있는 DLL B의 인스턴스의 변수값이 바뀌지는 않는다는 것도 조심해야 합니다. global 훅 프로시저는 메시지를 받는 그 프로세스의 주소 공간을 기준으로 호출된다는 것!
이걸 헷갈려서는 안 됩니다. 변수 초기화 같은 걸 잘못하면 훅을 설치한 프로세스 A 안의 B만 제대로 동작하게 되고, 다른 프로세스에 침투한 B는 그렇지 못하게 됩니다.

이것 때문에 과거에 굉장히 주의가 필요했던 점이 뭐냐 하면 훅 핸들 값을 공유하는 것이었습니다.
훅 프로시저는 자신에게 걸린 메시지를 처리한 뒤, CallNextHookEx 함수로 그 메시지를 다음 훅에다가 전달도 해 줘야 했습니다. 운영체제에 갈고리질을 하는 놈이 나만 있는 것 아니기 때문에... 그런데 윈도우 9x는 유독 이때 자신이 받은 훅 핸들값도 알아서 전달해 줘야 했습니다.

프로세스 A가 자신의 주소 공간에 있는 B DLL에다가 훅 핸들을 넘겨준다고 해도, 다른 주소 공간에 복제된 다른 B DLL의 인스턴스는 그 값을 알 수 없었습니다.
그래서 이 값은 숫제 메모리 맵드 파일 같은 공유 메모리를 만들어서 넘겨주거나, #pragma data_seg 같은 전처리기로 별도의 공유 섹션을 만들어서 그 전역변수에다 핸들을 공유해야 했지요.

그런데 윈도우 2000 이상, 아니 NT 계열은 그럴 필요가 없습니다. CallNextHookEx 함수를 호출하는 것 자체만으로 이 문맥에서의 훅 핸들은 알아서 감지가 됩니다. 당연히 그렇게 되는 게 이치에 맞죠. 그럼, 윈도우 95보다 NT가 3.1 시절부터 먼저였는데 왜 애시당초 아무 쓸모없던 HHOOK 인자를 받는 게 있었을까? 그건 아마 16비트 시절의 훅킹 API의 프로토타입을 그대로 베끼다 보니 그렇게 된 게 아니었나 싶군요. 32비트 윈도우로 와서 WinMain의 hPrevInstance 인자가 완전 무의미해졌지만 여전히 그대로 남아있는 것처럼.

그럼에도 불구하고 훅킹 API에 관한 한 윈도우 9x는 NT를 100% 닮지 못하고, 그렇다고 해서 아예 3.1 시절처럼 단일 주소 공간도 아니면서(핸들 값 공유도 어려운 환경에서) 꽤 불편한 프로그래밍 관행을 개발자에게 강요하게 되었던 것 같습니다.

윈도우 9x 시절에만 해도 global 훅 프로그래밍은 굉장히 조심스럽게 해야 했습니다. 훅 프로시저에서 뭔가 뻑이 났다간 그건 90% 이상 운영체제 다운으로 연결됐습니다. 디버깅은 더욱 힘들었음. 보호 모드 운영체제란 말이 무색할 정도였어요. 그만큼 운영체제가 안전보다는 열악한 PC 환경에서 효율 내지 도스와의 호환성 위주였으며, 불안정하고 응용 프로그램의 위험한 동작에 대해 취약했습니다.

하지만 XP 정도 되니, 특히 비스타는 이 정도로 안정성이 강화될 줄은 몰랐습니다. 훅 프로시저에 굉장히 어이없는 실수가 들어있었는데 그냥 그 훅만 싹 없어지고 프로그램은 잘 돌아가더군요. 깜짝 놀랐음. 윈도우 9x였으면 당장 blue dead screen이었을 겁니다.
윈도우 2000 때만 해도 IME/TSF 모듈이 해당 응용 프로그램을 뻗게 만들 수 있었는데, XP 이후부터는 안 그렇더군요. 자체적으로 예외 핸들링을 합니다.

global 훅 프로그래밍을 할 때 괴로운 점.
훅을 거둬들이고 모든 프로그램을 종료한 뒤에도 훅 프로시저가 들어있는 DLL의 lock이 즉시 풀리지 않는 경우가 많다는 것입니다. 훅을 해제한 뒤에도 이 DLL이 여전히 몇몇 프로세스의 주소 공간에서 사라지지 않고 상주해 있기 때문입니다. 그런데 3~5분 정도 기다리고 나면 없어져 있어요. 그러니 DLL을 이것저것 고치면서 자주 리빌드를 하기가 힘듭니다. -_-;;

비슷한 예로 글꼴도 있답니다. 프로젝트 파일로부터 최종 TTF 파일을 만들어서 여타 프로그램에서 테스트를 했습니다. 그런데 한번 그러고 나면, 그 프로그램을 종료한 후에도 내가 새로 설치한 TTF 파일이 여전히 in use 상태여서 지워지거나 교체가 안 되는 겁니다. 그러니 글꼴을 빈번히 수정하고 테스트하기가 힘들죠.

이럴 때 VMware가 해결책이 될 수 있습니다. 가상 머신을 만들어서 훅 프로그램을 실행하거나 글꼴을 설치하기 직전 순간의 스냅샷을 만든 후, 테스트를 하고 나서 스냅샷 시점으로 revert 하기. -_-;; 그게 저절로 파일 lock이 풀리길 기다리거나 재부팅을 하는 것보다 더 빠르더군요. ㄱㅅ!

뭐, global 훅 얘기로 길어졌습니다만, 내 응용 프로그램 안에서의 작은 규모의 훅도 충분히 쓰일 일이 있으며 특히 MFC에서는 내부적으로 이런 훅을 사용합니다. 일반적인 방법으로 잡기 힘든 메시지들도 MFC의 단일 프레임워크 하에서 일관성 있게 처리시키기 위한 목적이기도 하고요,
또 모든 대화상자들을 부모 윈도우 기준으로 중앙에다 재배치시키기 위해서도 훅을 사용해 대화상자가 생성되는 시점을 가로챕니다.

그냥 DialogBox 같은 함수만 호출해 보면 잘 알다시피 대화상자가 중앙에 뜨지 않습니다. MFC는 modal 대화상자만 중앙으로 옮겨 주기 때문에, 그냥 Create 함수로 modeless 대화상자를 만들어 보면 당장 그 위치 차이를 감지할 수 있습니다.

Posted by 사무엘

2010/01/10 23:29 2010/01/10 23:29
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/37

Trackback URL : http://moogi.new21.org/tc/trackback/37

Leave a comment

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

2010/01/10 23:26 2010/01/10 23:26
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/36

Trackback URL : http://moogi.new21.org/tc/trackback/36

Comments List

  1. 김 기윤 2011/01/06 15:26 # M/D Reply Permalink

    이중에 제가 실제 접해본 것은 Visual Basic, Borland C++, Visual C++ 밖에 없네요.

    요즘은 Visual C++ 밖에 안씁니다. (......) 단지 자바 코딩할때만 가끔 Eclipse를 쓰기만 할 뿐..

    1. 사무엘 2011/01/06 18:42 # M/D Permalink

      저도 비주얼 C++ 온리 유저입니다. ^^;;
      하지만 지금 다시 현업으로 써 보고 싶은 개발툴도 저 중에 여럿 있답니다.

Leave a comment

옷깃차례

시계, 반시계 방향을 나타내는 순우리말이 놀랍게도 있습니다.
내일의 순우리말을 발견한 것 같은 그런 느낌인데요.

옷깃차례. 한컴사전에도 올라 있는데,

  옷깃이 바른 자락 위에 왼자락이 덮이는 데서, 왼자락이 덮이는 쪽으로 나가는 차례. 곧, 시작한 사람으로부터 오른쪽으로 돌아가는 차례.

기본적으로 명사이고, '-로'를 붙여 손쉽게 부사 형태로 쓸 수 있습니다.

그런데..
결정적으로

결국 시계 방향이란 건지 반시계 방향이란 건질 모르겠어요. ㄲㄲㄲㄲㄲ
사람들이 원탁에 앉아서 모두 중심을 향하고 있는 상태에서 내 오른쪽 사람이라면 반시계 방향인데? 맞나..?
보는 관점에서는 시계 방향일 수도 있네요. -_-;;;

그게 첫째 문제이고,
둘째는 저 말의 간단한 반의어도 있어야 됩니다.
counter- 내지 반- 같은 접두어를 붙일 수 있냐 여부이구요.

늘 말씀드리는 바이지만 순우리말에 관한 저의 지론은,
무리하게 어설픈 순화 신조어 만들어내기 전에, 이미 있는 말부터 잘 찾아 쓰자. -_-

Posted by 사무엘

2010/01/10 23:24 2010/01/10 23:24
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/35

Trackback URL : http://moogi.new21.org/tc/trackback/35

Comments List

  1. 김 기윤 2011/01/06 15:24 # M/D Reply Permalink

    옛날에도 이 글을 봤던 기억이 있는데, 그 이후로도 "옷깃차례" 라는 단어를 쓰는걸 단 한번도 보지 못했습니다. (....)

    1. 사무엘 2011/01/06 18:41 # M/D Permalink

      국어사전이 저 단어의 뜻과 용법을 더 정확하게 수록해 줬으면 좋겠습니다.
      꼴뚜기질, 용두질-_- 등, 순우리말 중에 의외로 엽기적인 단어도 많습니다.
      최근에는 '들'이 '등'이나 다름없는 의존명사이기도 하다고 해서 정말 깜놀 했음. "사과와 배, 감 들을 사 왔다"에서 '들'은 et cetra라는 뜻이라나요? -_-;;;

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

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

2010/01/10 23:21 2010/01/10 23:21
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/34

Trackback URL : http://moogi.new21.org/tc/trackback/34

Leave a comment

새마을호의 역사

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

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

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

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

2010/01/10 23:19 2010/01/10 23:19
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/32

Trackback URL : http://moogi.new21.org/tc/trackback/32

Comments List

  1. 지나가는 사람 2010/09/23 10:01 # M/D Reply Permalink

    중간에 빠진 부분이 있더군요. 수정 부탁드립니다.

    1989년 10월22일. 서울-울산 간 새마을호 운행 시작
    1992년 9월29일. 서울-마산 간 새마을호 운행 시작

    1. 사무엘 2010/09/23 19:05 # M/D Permalink

      일단 반영은 해 놨습니다. 하지만 글쓴이가 누구신지, 그 운행 내역에 대한 출처를 더 정확히 알 수 있으면 좋겠네요.

  2. 김재영 2010/09/25 15:41 # M/D Reply Permalink

    반영 감사합니다.

    제 이름은 위에 썼다 싶이 김재영입니다.

    자료의 출처는 서울-울산 같을 경우 역 앞에 세워진 발자취에 왕복 1회 운행(이때는 8량 운행이고 1992년 10월 1일부터 16량 중련운행, 그리고 2002년 10월 15일부터 서울-포항 열차와 복합열차로 운행하였습니다-출처: 동아일보, 울산역 발자취)나와있고 역 직원분도 맞다고 그러시더군요.
    서울-마산 같을 경우 9월 29일자 동아일보와 매일경제에 철도청이 10월 1일부터 서울-마산 새마을호를 장대열차로 왕복 1회 신규 운행한다고 나와있었습니다.

    둘 다 공식적은 문서가 출처는 아니지만 발자취는 울산역에서 홍보용으로 눈에 띄에 세워두니 그래도 코레일에서 인정하는 기록만 적어 놓을 것 같아서, 신문은 2개의 신문사에서 모두 동일한 내용으로 보도하였으니 신뢰성이 있는 듯 해서 수정을 요청하였습니다. 넣고 제외하고는 님께서 결정해주시기를 바랍니다.
    그리고 죄송합니다. 제가 실수를 하였더군요. 9월 29일은 그 내용이 실린 신문이 나왔는 날이고 실제 운행일은 10월 1일 입니다.
    이렇게 오류를 찾을수 있는 기회를 주셔서 감사합니다.

    1. 사무엘 2010/09/26 23:05 # M/D Permalink

      김 재영 님, 반갑습니다.
      저는 그런 식의 비슷한 홍보 멘트를 포항 역에서도 본 기억이 있어요.
      아마 포항으로 새마을 PP가 다니기 시작한 것도 1992년 비슷한 시기일 겁니다.
      알려 주셔서 고맙습니다. ^^

Leave a comment

윈도우 운영체제가 NT 초창기 시절 이래로 지금까지 사용해 오고 있는 실행 파일 포맷은 잘 알다시피 portable executable 형식입니다. 헤더도 이니셜인 PE로 시작합니다. 물론 네이티브 EXE이기 때문에 코드 부분은 기계마다 다르겠지만, 헤더 구조체라든가 리소스 같은 공통된 부분은 최대한 일치시켜서 이식성을 고려해서 설계했다는 뜻이지요.

늘 인텔 CPU에서만 돌아가는 EXE만 보다가 MIPS 같은 RISC CPU에서 돌아가는 PE 실행 파일을 헥사 에디터로 들여다보니 진짜로 기계어 코드가 한눈에 보기에도 일정 바이트 간격으로 아주 균일하게 나열돼 있더군요. 그걸 보고 놀랐던 기억이 납니다.

64비트 PE도 일부 구조체만 64비트로 확장되었을 뿐 기본적인 골격은 초창기 32비트 PE와 같습니다. 더구나 윈도우 운영체제가 인식하는 리소스(스트링 테이블, 대화상자, 메뉴 등)의 포맷은 매우 다행스럽게도 32비트 PE와 완전히 일치합니다.

EXE와 DLL은 자신만의 프로세스 공간을 만들어서 단독 실행이 가능하냐의 차이가 존재하는데, 기술적으로는 헤더의 비트 몇 군데만 다르지 똑 같은 PE 바이너리입니다. 이런 바이너리를 ‘모듈’이라고 부릅니다.

c, cpp 같은 소스 코드를 컴파일하면 기계어 코드인 obj 파일이 생깁니다. 이런 obj 파일과 lib를 링크하면 그런 모듈 파일이 결과물로 생성됩니다. lib는 또다른 obj의 묶음일 뿐 obj와 완전히 다른 파일이 아닙니다. 또한 모듈 역시 그런 obj, lib에 들어있는 코드를 PE 규격에 맞게 재배치하고 묶은 파일일 뿐이지 원시 파일과 그렇게 큰 차이가 없습니다.

윈도우 운영체제에서 개발 환경을 만든 사람들의 생각은, 링커가 특별히 할 일이 없게 하는 것이었던 것 같습니다. 물론 요즘은 전역 최적화처럼 링크 타임에도 코드를 생성하는 기술도 도입되어 사정이 그렇게 간단하지만은 않게 됐지요.

PE는 text(실행되는 기계어 코드), rdata(스트링 리터럴처럼 읽기전용 상수나 초기화 값), rsrc(윈도우 리소스 데이터), DLL 심볼 import/export 테이블, reloc(재배치 정보) 등 여러 섹션으로 나뉩니다. 특히 재배치 정보는 Win32s 시절에는 exe에도 필요했지만 지금은 dll에만 넣어 주면 됩니다.

PE의 헤더에는 자신의 기본 어드레스, 자신이 돌아가는 데 필요한 최소한의 운영체제 버전 같은 여러 정보가 들어가고 심지어 자신을 빌드한 링커의 버전을 기입하는 공간도 있습니다. 가령 비주얼 C++로 빌드하면 6.0, 7.1 (닷넷 2003), 8.0 (2005) 같은 번호를 쉽게 식별할 수 있지요.

원래 MS 자체에서 만든 프로그램 바이너리들의 링커 버전은 비주얼 C++의 버전과 거의 일치하지 않았습니다.
가령 윈도우 95는 까마득한 2.5, 그리고 98/ME는 3.1, 윈도우 2000은 5.12, 오피스 XP는 6.2였습니다. 비주얼 C++과는 별도로 자신들만 쓰는 컴파일러/링커가 있었던 것 같습니다.

하지만 이것이 언제부턴가, 한 02~03년부터 버전이 일치하기 시작했습니다. MS에서도 내부적으로 비주얼 스튜디오를 쓰기라도 했는지?
윈도우 XP는 7.0으로 당대의 최신 비주얼 C++이던 닷넷 2002와 일치합니다.
그리고 XP sp2 (sp1은 모르겠음)와 오피스 2003은 비주얼 C++ 닷넷 2003의 버전과 같은 7.1입니다.

그 후 윈도우 비스타와 오피스 2007의 모든 바이너리들은 비주얼 C++ 2005의 버전인 8.0으로 물갈이되어 있습니다. 하지만 CRT 라이브러리는 살짝 다릅니다. 오피스는 msvcr80을 쓰지만 운영체제는 자신만의 msvcrt를 고수하고 있습니다. 하지만 이제는 msvcrt에도 비주얼 C++ 2005에서 새로 추가된 strcpy_s 같은 보안 강화 함수들이 추가되어 있습니다.

msvcrt는 이제 운영체제가 혼자 마음대로 바꿔 쓰는 CRT DLL로 격리시키고 응용 프로그램들은 이제 msvcr??을 알아서 배포해서 쓰든가, 싫으면 스테틱 링크하라는 구도가 된 셈입니다.

Posted by 사무엘

2010/01/10 23:17 2010/01/10 23:17
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/31

Trackback URL : http://moogi.new21.org/tc/trackback/31

Leave a comment

서울 지하철의 굴곡 포인트

※ 1호선: 서울로 들어가는 경로 자체가 영등포 쪽으로 우회입니다. 물론 광역전철 말고 지하철 구간은 종로라는 큰 길을 따라 건설되어서 곧은 편이지만, 시청-종각만이 거의 90도로 꺾는 급커브입니다. 동아일보 사옥 아래를 피하느라 그렇게 됐다고 합니다.

※ 2호선: 순환선이기 때문에 생기는 커브를 제외하면 직선 구간은 그런대로 곧게 잘 만든 것 같습니다.

※ 3호선: 교대-고속터미널을 경유하느라 ㄷ자 모양의 괴이한 커브가 생겨 버렸죠. 일산선 구간도 삼송-원당 쪽을 경유하느라 오리지널 경의선에 비해 굴곡이 너무 심합니다.

※ 4호선: 과천선 구간의 경마공원-대공원 경유가 굴곡을 만들고 있고, 용산-서울역 1호선과의 중복 구간도 일종의 굴곡 우회 경로입니다. 남산 아래를 뚫고 도심으로 바로 직행하는 전철 노선이 아쉽습니다.

※ 5호선: 2호선과 겹치는 강북 도심 구간은 매우 심한 굴곡 커브가 이어집니다. 신금호까지 남쪽으로 내려갔다가 광화문까지 북쪽으로 올라가죠.
오로지 1호선과의 환승을 위해 건설된 신길 역도 긴 환승 통로에 상당한 굴곡이 진 곡선역이 됐습니다.
끝으로, 김포공항도 예외가 아니어서 인근역과 거의 예각을 이룰 정도로 큰 굴곡입니다.

※ 6호선: 마포구에서 지하철이 왼쪽으로 살짝 꺾게 만든 장본인은 상암동의 월드컵 경기장입니다. 6호선 건설 당시, 월드컵 경기장의 건설 예정지가 뒤늦게 그렇게 확정되자 황급히 노선을 바꾸느라 꽤 곤혹을 치렀다고 합니다. 그 대신 택지 개발 계획도 취소되고 월드컵 경기장 후보지에서도 탈락한 5호선 마곡 역은 미개통 노는 역이 되고 말았지요.

※ 7호선: 강남 구간에 고속터미널-상도가 국립묘지를 피해 가는 우회 구간입니다. 직선 구간은 9호선이 역할을 대신할 것으로 보입니다.

※ 8호선: 분당선과의 중복을 피하기 위해, 남쪽에 남한산성을 경유하는 괴상한 굴곡 노선이 형성되어 있습니다.

Posted by 사무엘

2010/01/10 23:11 2010/01/10 23:11
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/30

Trackback URL : http://moogi.new21.org/tc/trackback/30

Leave a comment

4종 교통수단 분석

※ 육상 (도로)

문전 수송이 가능한 유일한 교통수단
차체의 크기가 가장 작음
휴게소라는 중간 시설이 있는 유일한 교통수단
조향이 가능한 2차원 교통수단
도로 정체의 영향을 받는 유일한 교통수단. 날씨 영향도 받긴 하나 항공, 해운만하지는 않음. 승차권에 평균 운행 시간은 나와도 도착 예정 시각은 찍혀 있지 않음

※ 육상 (철도)

한 치의 오차도 없이 정확하게 길이 있는 곳만 다닐 수 있고, 진로 분기도 외부에서 선로를 바꿔 줘야만 가능한 유일한 1차원 교통수단. 폐선되는 경우, 차량이 다니던 기반 시설까지 다 철거해야 하는 유일한 교통수단.
버스보다 객실 폭이 넓지만, 선로 폭은 도로보다 더 좁음 (공간 이용이 매우 효율적)
조향이라는 개념이 없기 때문에 속력은 비행기 다음으로 가장 빠르게 올릴 수 있음
좌석에 구명 장비(조끼, 안전벨트, 마스크 등)가 없는 유일한 교통수단. 멀미도 전혀 없다.
차량을 매우 길게 편성할 수 있어 대량 수송에 적합함
길에 대한 초기 투자비용이 가장 많이 들며, 꼼꼼한 유지 보수도 필요한 유일한 교통수단
전기 동력원을 쉽게 끌어다 쓸 수 있는 유일한 교통수단
기상 영향을 가장 덜 받는 전천후 교통수단
차체의 옆에서 탑승하며 출입문이 여러 군데에 있음

※ 항공

유일한 3차원 교통수단이며 디젤 엔진이 쓰이지 않는 유일한 교통수단
운항 중에는 중간 정지나 기체 비상 탈출이 절대 불가능한 유일한 교통수단으로, 운항 전 보안이 가장 크게 요구됨
속력이 가장 빠르고 가장 장거리를 운행할 수 있으며 운임도 가장 비쌈

※ 해운

탈 때, 동체가 땅에 닿아 있지 않은 유일한 교통수단
조향이 가능한 2차원 교통수단 (도로와 비슷)
크기를 가장 키울 수 있는 교통수단. 화물의 비중이 큼 (철도와 비슷)
바다의 특성상, 풍력으로도 그럭저럭 달릴 수 있는 유일한 교통수단
속력은 가장 느림
기상 영향을 크게 받음 (항공과 비슷)

서로 개성 넘치죠?

Posted by 사무엘

2010/01/10 23:09 2010/01/10 23:09
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/29

Trackback URL : http://moogi.new21.org/tc/trackback/29

Leave a comment

나의 고속도로 이용 경험

※ 메이저급

  경부(1): 서울-경주, 경주-대구, 경주-대전, 대전-서울 뭐 고속도로 하면 이 경로가 골수에 박혀 있죠. 하도 많이 이용해 봤으니까요. 저의 고속도로 이용 기억의 70% 이상 차지.
단, 경주 이남은 정말 묘하게 간 적도 없고 기억도 없다시피하군요. 경부는 전국에서 가장 넓은 고속도로로, 이제 아직까지 4차선으로 남아 있는 곳은 영천 이남 정도밖에 없습니다.

  중부(35): 경부 다음으로 제 기억 속에 남은 고속도로입니다. 대전에서 청주나 서울 갈 때 웬 처음 듣는 IC 이름들이 보이길래 경부가 아니구나 직감했습니다. 무려 통영까지 뚫렸지만 대전 이남 구간은 못 타 봤습니다. 개인적으로 이 도로가 경부 다음으로 무척 애착이 갑니다.
요즘은 또 유성-서울 시외버스가 이 도로를 애용합니다. 중부는 경부보다 동쪽에 있기 때문에 동서울 터미널과 잘 연결되기 때문입니다. 경부보다 훨씬 험한 지형을 고가와 달리고 하남, 이천, 광주 같은 수도권 동남부를 경유합니다. 산으로 가로막힌 오나전 철도 사각지대이기도 하죠.
덕분에 수도권 구간의 도로 확장도 경부 확장하듯이 못 하고, 옆에 아예 도로를 하나 더 짓는 방법으로 해야만 했습니다. 이름하여 제2 중부 고속도로이죠.

  중부내륙(45): 중부보다 더 오른쪽이고 영동 고속도로의 여주 분기점에서 만납니다. (여주 분기점 이북으로 양평까지도 확장 예정이라 함) 그리고 김천에서 경부와 만나는 걸로 끝나던 노선도 더 확장되어 마산까지 내려가죠. 김천 이남은 즐.
서울에서 출발하여 구미, 대구, 경주로 가는 고속버스들이 이 도로 덕분에 대전으로 우회하지 않고 더 곧은 길로 갈 수 있게 됐습니다. KTX 뺨칠 정도로 길이 곧고, 고가 터널이 일품입니다. 서울-경주 오갈 때 가끔 구경함.

※ 마이너급

  영동(50): 수도권 남부의 대표적인 가로축 고속도로로, 주말, 평일에 극심한 혼잡을 자랑합니다. 서쪽으로는 인천, 안산까지도 가죠. 하지만 저는 동쪽으로 여주 정도까지만 이용해 봐고 그보다 더 동쪽으로는 못 가 봤습니다.

  호남 고속도로 지선: 대전에서 학교 다닐 때, 유성 고속/시외버스 터미널에서 버스 타고 서울 갈 때, 유성 내지 북대전 IC에서 회덕 JC까지 아주 짤막한 구간만 이용해 봤습니다. 그 이남은 가 본 적 없습니다.

  서울외곽순환(100): 중부에서 동서울 IC -> 서울 시내 진입할 때에나 잠깐. 다른 구간은 경험무.

  서해안(15), 평택제천(40): 사실 서울은 서쪽은 철도, 동쪽은 도로 거의 이런 구도로 장거리 교통이 형성돼 있습니다. 그래서 서서울 IC, 서해안 고속도로는 더욱 경험이 드뭅니다. 고속버스로 이 도로를 가 본 적은 없고, 자가용은 더더욱 전무하고, 정말 특별한 계기로 딱 두 번 서해안 -> 평택제천 -> 경부 이런 식으로 길을 가 본 적은 있습니다. 그 유명한 서해대교까지는 못 가 봤고요.

  당진상주(30): 작년 가을에 개통한 오나전 따끈따끈 새 도로. 개통한 줄도 모르고 지냈는데, 작년 겨울에 경주 집에 갈 때 처음 보고 깜짝 놀랐습니다. 제한 속도가 110도 아닌 120km/h이고 '회인'이라는 웬 처음 듣는 IC가 등장하길래 새로 생긴 도로임을 직감했지만 어디를 경유하는지는 몰랐습니다. 나중에 지도를 찾아 보고서야 알았죠.

※ 한 번도 못 가 봤고, 달려 보고 싶은 곳

  익산-포항(포항-대구)
  부산-대구 민자 고속도로
  중앙 고속도로
  88 올림픽 고속도로
  논산-천안 민자 고속도로 (훈련소 있으면서 논산 쪽 톨게이트를 봤음)
  서해안, 영동 고속도로의 나머지 구간들

Posted by 사무엘

2010/01/10 23:07 2010/01/10 23:07
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/28

Trackback URL : http://moogi.new21.org/tc/trackback/28

Comments List

  1. 소범준 2011/12/05 00:34 # M/D Reply Permalink

    저의 경험으로는

    경부 : 서울 한남대교남단 기점~대전 비룡분기점까지. 그 이남은 경험무.
    중부 : 동서울~청주, 대전 판암분기점~비룡분기점. 판암 이남으로는 경험무. 특히 제2중부(하남 산곡~이천 마장)도 지나치지 못함. ㅋㅎ
    영동 : 전구간 유경험. ㅋㅎ(특히 어렸을 적에 구 대관령길을 부모님과 넘었던 적이 있음)
    중부내륙 : 여주 가남분기점~음성 감곡IC. 그 이북과 이남은 경험무.
    중앙 : 춘천기점~원주 만종분기점~영주. 그 이남은 경험무.
    호남(천안논산 포함) : 지선구간(대전 회덕기점~논산JCT 전구간)포함해서 천안~정읍, 정읍~장성JCT. 순천. 그 중간은 경험무.
    서울외곽순환 : 전구간 유경험 ㅎㅎ
    서울춘천 : 전구간 유경험 ㅎㅎ
    서해안 : 서울~부안. 그 이남으로는 경험무.
    평택제천 : 구 평택안성 시절에 평택~안성. 그 동쪽으로는 경험무.
    제2경인과 인천공항 : 전구간 유경험 ㅎㅎ
    경인 : 거의 전구간 유경험. 자세히는 기억 안남.
    88올림픽 : 장성JCT~남원. 그 서쪽/동쪽으로는 무경험.
    남해 : 순천기점~광양. 그 동쪽으로는 무경험.
    평택봉담 : 전구간 유경험.

    그리고, 그 외에 아직도 미개척인 구간은

    구 구마선 전구간
    대구부산선
    당진상주선
    용인동탄선
    고창담양선 일부구간

    이상입니다. ㅎㅎ 전부 제가 직접 달려보진 못하고, 동반 여행이나 아버지 출장 동행차 다닌 결과물들입니다.

    ※ 참고로 당진상주간 고속도로는 논산천안을 건설할 때 미리 분기점의 틀을 갖춰놓았습니다.
    근데.. 이 유명한 논산천안을 한 번도 안가보셨다니!! 흠좀무.;;

    1. 사무엘 2011/12/05 11:33 # M/D Permalink

      형제는 저와는 달리 대전 이남의 경부축 경험이 없군요.
      반대로 공주 내지 호남 쪽으로 연고지가 없는 사람은 논산천안을 탈 일이 없죠. ^^

Leave a comment
« Previous : 1 : ... 141 : 142 : 143 : 144 : 145 : 146 : 147 : 148 : Next »

블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2019/01   »
    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:
1098029
Today:
188
Yesterday:
378