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

승용차가 있으니까 좋긴 참 좋다. 차는 회사나 교회를 왕래하는 것 같은 일상적인 이동뿐만 아니라 레저/취미 활동의 영역에서도 예전에 불가능하던 것을 가능하게 만들어 줬다.

나한테 차가 생기면 철도에 대한 관심이 상대적으로 줄어들 거라고 도대체 누가 말했던가. 전혀 그렇지 않다.
오히려 차가 생기기 전에는 신규 개통 철도 노선의 첫 차를 시승하기 위해서 전날 노숙을 해야 했지만, 지금은 새벽에 차를 끌고 가서 차에서 자다가 첫 차를 타는 선택의 여지가 생겼다.
예전에는 차를 이용해서 잠깐이나마 서울교외선 답사를 가 본 적도 있다. 자동차는 철도 덕질을 위한 훌륭한 도구 역할을 하고 있다.

지난 3월 말의 어느 날, 본인은 짬을 내서 과감하게 차를 몰고 서울을 빠져나갔다. 그리고 당일치기 철도 테마 여행을 즐겼다.
나름 출근 시간을 넘긴 오전 10~11시 시간대를 선택했지만, 이때도 자동차 전용 도로들은 넘쳐나는 차들 때문에 대단히 혼잡했다. 그래도 서울을 벗어나고 한적한 교외로 들어서니 자동차의 탁월한 이동성은 빛을 발하기 시작했다.

내가 가장 먼저 간 곳은 바로..

1. 주행 중인 KTX 촬영의 명당, 반월 저수지 인근 야산

대략 이런 곳이다.
호수 옆에 비교적 높지 않은 고가 위로 KTX가 달린다. 경부 고속선을 통틀어 보기 드문 낭만적인 풍경이 아닐 수 없다.
여기는 광명 역을 지난 KTX가 무려 10km가 넘는 긴 거리를 지하로 달린 뒤에 처음으로 등장하는 지상 구간이기도 하다. 서울 외곽 순환 고속도로와 서해안 고속도로가 교차하는 조남 분기점의 바로 아래 지하로 KTX가 달린다는 걸 생각해 보라. 그 KTX가 여기로 나온다.

이곳에서 가장 가까운 전철역은 4호선(안산선) 대야미 역이다. 북쪽 방면인 2번 출구로 나간 뒤, 왼쪽으로 꺾어서 나오는 한적한 도로를 쭉 가면 된다. 역에서 3.2km 남짓 떨어져 있기 때문에 걸어서 가기는 좀 힘들다. 그리고 저기는 인적이 드물어서 버스로 쉽게 찾아갈 수 있는 곳도 아니다. 그러니 자가용 콜.

선로로 진입하는 야산 코앞에서 차를 세웠다. 선로 근처는 역시나 외부인의 접근을 금지하는 철조망이 쳐져 있다.

우리는 당연히 철조망을 월담하지는 않는다. 그저 철조망을 따라 언덕을 쭉 오르면 된다.
이로써 본인 역시 수많은 철덕들이 나보다 앞서 개척한 천혜의 철도 출사 성지에 도달하는 데 성공했다.

우와!
일명 하늘다리라고 불리며, 경부 고속선을 위에서 내려다보며 사진 촬영을 할 수 있는 극히 드문 구간!
선로는 한 치의 커브도 없는 직선이고, 앞에 저쪽 끝에도 산 속으로 들어가는 터널이 있다.
우리 앞에 펼쳐진 이 지상 선로는 인터넷 지도로 길이를 측정해 보면 길이가 거의 6km에 달한다.
본인이 서 있는 곳의 앞은 응당 철조망이 가로막고 있으며, 삼엄한 접근 금지 경고문도 붙어 있다.
이곳에서 촬영된 KTX 사진들은 다 철망 안으로 카메라를 집어넣고 zoom도 굉장히 많이 당겨서 촬영된 것들이다.

누구의 소행인지는 모르겠지만 카메라 집어넣기 좋으라고, 선로 중앙의 철망의 일부가 동그랗게 훼손되어 있다.
하지만 철망 너머로 웬 잡초가 무성하게 자라서 시야를 가리는 관계로, 이것을 피하느라 좋은 구도의 사진을 만들기가 상당히 어려워져 있었다.
그리고 여름에 수풀이 온통 초록색일 때 왔으면 주변 경치가 더 좋았을 것 같긴 하다.

KTX 산천이 하나 카메라에 잡혔다. 저 열차의 진행 방향이 어디인지 모르는 분은 없을 거라 생각한다.
멀리서 오는 놈은 쉽게 감지가 되지만, 우리 밑을 지나가는 놈은 출현하기 몇 초쯤 전에 갑자기 주행 소음을 일으키더니 쌩 지나간다. 그래도 디젤 기관차처럼 천지를 진동하는 소음과 진동 수준은 아니다.

경부 고속선에 KTX는 상· 하행을 모두 감안했을 때 평균 대략 10분당 한 번꼴로는 드나드는 것 같다. 하지만 실제 빈도는 몹시 불규칙하여 편차가 큰 편이다.
그리고 아침 11시에서 12시 사이는 전차선 점검을 명목으로 서울과 부산 양 시발역에서 모두 KTX가 출발하지 않는다. 즉, 이 시간대에는 평소보다 열차의 운행이 몹시 뜸해지므로, KTX 출사를 하려면 시간대를 잘못 선택해서 낭패를 보는 일이 없어야 할 것이다.

다음으로 산천 말고 떼제베 기반 재래식 KTX가 지나가는 모습이다. 재래식 KTX는 한 편성의 길이가 거의 380m에 달한다는 걸 생각하자.
광명 역을 출발한 KTX는 지하 터널을 한참 달린 뒤 이 구간으로 나올 무렵쯤이면, 이미 충분히 가속이 되어 주행 속도가 250km/h을 넘고, 속도가 객실내 모니터에 표시되곤 했다.

그런데 이런 언덕 위에서 KTX가 달려오는 걸 보면 생각만치 빨라 보이지가 않는다. 그냥 새마을호가 시속 140대로 슬금슬금(?) 지나가는 것 같다. 과연 그럴까?

하지만 동영상 분석을 해 보니 그렇지 않았다.
길이 380m짜리 열차의 맨 앞이 한 전신주 지점을 통과하고, 다음으로 열차의 맨 끝이 그 전신주를 통과할 때까지 걸린 시간이 5.5초가 좀 안 됐다.
이로부터 열차의 속도를 구해 보면 딱 정확하게 시속 250km에 근접하는 걸 알 수 있었다.

산을 내려온 뒤, 장소를 떠나기 전에 호수 주변의 경치를 좀 더 카메라에 담았다. 가히 철도 성지답다.

이미 아시는 분도 있겠지만 경부 고속선은 안산선 반월-상록수 구간의 중간을 위로 통과한다. 반월-상록수 사이는 역간거리가 3km가 넘고, 중간에 영동 고속도로도 지나는 일종의 교통 요지이다. 한적한 도로를 따라 달리면서 안산선과 경부 고속선의 궤적을 계속 추적해 보는 것도 의미 있는 일이겠으나, 본인은 이 먼 거리를 차를 몰고 온 김에 다른 의미 있는 일을 발견했기 때문에 동쪽으로 이동을 시작했다.
저 앞에 있는 열차 승강장은 반월 역이다. 이 역은 전철역이라기보다는 완전 시골 간이역 분위기가 물씬 풍긴다. 선로와 역무실은 평지이고 지하도를 이용하여 승강장으로 가는 형태도 그렇거니와, 출입구도 남쪽으로 1번만 있지, 논밭을 향하고 있는 북쪽(본인이 서 있는 방향)으로는 없다.

Posted by 사무엘

Windows 운영체제가 인식하는 실행 파일은 구조적으로 편의성의 상징인 GUI 프로그램과, 강력한 자동화의 상징인 콘솔(명령 프롬프트) 프로그램이라는 두 갈래로 나뉘어 있다. 이것은 SUBSYSTEM이라는 링커 옵션으로 지정 가능하다.

이 옵션이 콘솔로 되어 있으면 빌드 과정에서 링커는 C 라이브러리에서 main 함수를 찾아 호출하는 startup 코드를 연결하며, GUI로 지정되어 있으면 잘 알다시피 WinMain 을 호출하는 startup 코드를 연결한다. 해당 함수들은 물론 프로그래머가 따로 구현해 놓아야 한다.

어차피 GUI든 콘솔이든 EXE 파일이 제일 먼저 실행되는 지점은 실행 파일의 entry point에 지정된 주소이며 원래는 운영체제로부터 아무 인자도 전달되지 않는다. 그 대신, C 라이브러리가 GetModuleHandle, GetStartupInfo, GetCommandLine 등의 여러 기초적인 함수들을 먼저 호출하여 리턴값들을 WinMain에다가 전달해 줄 뿐이다.
콘솔 버전인 main도 마찬가지이다. 명령 옵션을 API 함수로 얻어 온 뒤, 그걸 C 라이브러리가 파싱하여 main에다가 argc와 argv의 형태로 전해 준다.

빌드 관점이 아닌 실제 실행의 관점에서 봐도, Windows는 콘솔 프로그램과 GUI 프로그램을 서로 약간 다른 방식으로 실행해 준다. 콘솔 프로그램의 경우 이미 명령창 같은 콘솔에서 실행되었다면 기존 콘솔을 자동으로 연결시키고, 프로그램이 탐색기 같은 GUI 환경에서 실행되어 콘솔이 없는 경우 “콘솔을 언제나 자동으로 생성”한다. 그 반면, GUI 프로그램에는 그런 조치를 취하지 않는다.

다만, 콘솔 프로그램이라고 해서 GUI 윈도우를 만들거나 메시지 loop을 돌지 말라는 법은 전혀 없으며, 반대로 GUI 프로그램도 추후에 자기만의 콘솔을 얼마든지 따로 생성해서 쓸 수 있다. 콘솔과 GUI를 적절한 혼용하면 유용한 경우가 의외로 매우 많다.

GUI 프로그램의 경우 디버깅 메시지를 찍기 위해 별도의 콘솔을 이용하는 것은 매우 흔한 테크닉이다. DOSBox가 대표적인 경우이다. 그리고 반대로 평소에는 명령창으로 문자열만을 취급하더라도, 가끔 그래프 같은 시각화된 결과물을 보여 줄 필요가 있을 때 제한적으로 GUI 윈도우를 생성하는 프로그램도 생각할 수 있다.

결국 GUI와 콘솔이 완벽하게 혼합된 프로그램이라면 이런 것도 가능해야 할 것이다.
프로그램을 아무 인자 없이 실행하거나, 또는 콘솔이 아닌 GUI 환경에서 실행하면 GUI가 나타난다. 반대로 콘솔에서 실행하거나 /? 같은 명령 옵션을 줘서 실행하면 콘솔로 메시지가 나타나고, 이미 콘솔이 있는 경우 그 콘솔을 사용한다. 압축 유틸리티 같은 게 이런 식으로 개발되어 있으면 아주 편리하지 않겠는가?

그런데 문제는 이 정도로 유연한 GUI/콘솔 하이브리드 프로그램을 만들기는 대단히 어려우며, 운영체제가 구조적으로 그런 것까지 고려하여 만들어지지는 않았다는 점이다. GUI와 콘솔 모두 2% 부족한 면모가 있다.

(1) 프로그램을 콘솔 방식으로 빌드하면, GUI 형태로 실행되어야 할 때에도 언제나 빈 콘솔창이 생겨 버린다. 프로그램이 실행되자마자 곧바로 API 함수를 호출하여 이 콘솔을 죽일 수는 있지만, 콘솔 창 같은 게 깜빡인 것이 사용자에게 그대로 드러나 보이기 때문에 이런 방식은 용납될 수 없다.

(2) 반대로 프로그램을 GUI 방식으로 빌드하면, 콘솔 환경에서 콘솔 형태로 실행되었을 때 기존 콘솔을 연결하는 방법이 없다. 콘솔 프로그램과는 달리 GUI 프로그램에서는 운영체제가 이것을 자동으로 해 주지 않는다. 콘솔에다 메시지를 찍는 것은 새로운 콘솔에다가만 가능하다. 기존 콘솔을 연결하는 AttachConsole이라는 함수가 차후에 추가되기는 했지만 방법이 완전하지 않다.

결국, 어느 방식을 선택하더라도 문제가 완전히 없을 수가 없다. 콘솔창을 필요할 때만 생성하면서 콘솔이 이미 존재하는 경우 기존 콘솔과 자동으로 연결이 되는 프로그램을 만들 수는 없는 것일까?

Visual Studio IDE인 devenv 프로그램은 이 문제를 해결한 듯해 보인다.
아무 인자를 안 주고 실행하면 잘 알다시피 커다란 IDE 창이 생긴다.
그러나 /? 를 주고 실행하면 각종 명령 옵션 사용법이 기존의 콘솔에다가 깔끔하게 찍힌다. 그냥 대충 도움말 창 하나 띄우고 끝인 게 아니다.
마소에서는 이것을 어떻게 구현하였을까?

그 비결은 너무 허무할 지경이다.
IDE 실행 파일이 있는 디렉터리를 가 보면, devenv 프로그램은 .exe도 있고 .com도 있어서 두 종류가 있다.

Windows는 도스 시절의 전통을 물려받았기 때문에 명령 프롬프트에서 사용자가 확장자 없이 실행 파일을 지정하면 EXE보다 COM을 먼저 실행한다. 그래서 COM은 /?  옵션 같은 걸 받아들이는 콘솔 프로그램으로 만들고, EXE를 GUI 프로그램으로 드는 꼼수를 쓴 것이다! devenv /?가 아니라 devenv.exe /? 라고 확장자를 강제 지정하면 명령 옵션 리스트가 역시나 대화상자 GUI 형태로 출력되는 걸 볼 수 있다. ^^

도스 시절에 COM은 잘 알다시피 EXE보다 더 작고 단순한 실행 파일이다. 실행 파일 자체의 헤더나 파일 포맷 같은 게 존재하지 않으며, 메모리 재배치도 없이 최대 64KB의 크기 안에 x86 기계어 코드와 데이터가 모두 들어가고 컴퓨터의 고정된 메모리 주소에 그대로 주입되어 실행되었다.

요즘이야 COM이나 EXE나 모두 동일한 실행 파일이다. 오히려 COM 확장자를 사칭하여, 사용자가 의도한 프로그램 대신 악성 코드를 먼저 실행시키는 보안 위험이 문제되고 있는 지경이다. 마치 autorun 기능을 막듯이 COM의 실행을 막아 버리면 속 시원할지 모르나, 과거 프로그램과의 호환성 차원에서 그게 속 시원하게 가능할지는 모르겠다. 그래도 64비트 Windows는 아예 16비트 프로그램을 실행하는 기능 자체가 없어진 지 오래인데..

어쨌든, 실행 파일의 확장자로 콘솔용과 GUI용 프로그램을 구분시킨 건 Windows에서 배치 파일을 이용하여 자기 자신을 제거하는 프로그램을 만드는 것만큼이나 참 기발한 꼼수인 것 같다. 세상에 그런 방법을 쓸 줄은 몰랐다.

※ 추가 설명

1. Windows용 qt 라이브러리를 사용한 프로그램은 GUI 프로그램임에도 불구하고 main 함수에서 실행이 시작된다. 이것은 물론 qt 라이브러리의 내부에 WinMain 함수가 있어서 그게 사용자의 main 함수를 또 호출하기 때문일 것이다. MFC 라이브러리도 자체적인 WinMain 함수가 내부에 존재한다는 점을 감안하면 이는 충분히 수긍이 가는 디자인이다.

더구나 Windows를 제외한 다른 운영체제들은 실행 파일의 성격을 Windows처럼 GUI 아니면 콘솔 형태로 이분화하지 않으며 똑같이 main 함수를 쓴다. 그렇기 때문에, 크로스 플랫폼을 지향하는 qt는 응당 Windows에서의 프로그래밍 방식도 main을 기준으로 맞췄다고 볼 수 있다.

2. 과거의 16비트 Windows 시절에는 말 그대로 도스 프롬프트만이 있었을 뿐 콘솔이라는 게 없었다. 이것만으로도 그때 Windows는 구조적으로 기능이 굉장히 빈약했음을 알 수 있다.

Posted by 사무엘