윈도우 비스타에서는 모르긴 몰라도 그래픽/사운드 기술과 관련된 계층이 굉장히 많이 바뀌었습니다.

※ 비디오 (그래픽)

예전에 글로 쓴 적이 있지만 제가 가장 먼저 인지한 큰 변화는, 이제 동영상 화면까지 Print Screen 키로 바로 캡처가 된다는 것. 그것도 Aero (desktop window manager)가 가동 중일 때뿐만 아니라 DWM이 돌아가지 않는 고전 모드일 때도 동일하게 잘 됩니다. 옛날에는 인터넷 같은 데서 웹브라우저 창을 옮기면 그 안에서 돌아가던 동영상은 위치가 이동하지 않거나 느릿느릿 굼뜨던 현상도 심심찮게 볼 수 있었는데 이 역시 비스타에서는 아련한 추억이 됐지요. 그래픽 카드와 운영체제의 발전에 힘입어, 드라이버 계층에서의 어떤 큰 변화가 생긴 게 틀림없습니다.

멀쩡하게 상위 계층의 윈도우 API만 썼다면 비스타라고 해도 안 돌아갈 이유가 없는데, VMware, 메이플, 비주얼 스튜디오 같은 프로그램들이 옛 버전이 비스타에서는 제대로 동작하지 않아 버전업을 해야만 하는 이유도 저런 ‘저수준에서의 미묘한 변화’ 때문이라고 풀이할 수 있겠습니다. XP와 비스타는 각종 하드웨어 드라이버들이 호환되지 않죠. 하지만 비스타와 7은 드라이버 차원의 호환이 유지될 것으로 알려져 있습니다.

윈도우 XP부터는 심지어 운영체제 설치 GUI나 안전 모드에서도 VGA 640*480 16컬러는 완전히 자취를 감추었고, 하이 컬러 이하로는 디스플레이 모드가 설정이 되지도 않습니다. 게임용 3D 그래픽 가속까지는 뒷받침을 원활히 못 하더라도, 최소한 1024*768 하이컬러 이상급의 그래픽 모드는 메인보드가 내장하는 VBE 규격만으로도 지원되게 컴퓨터 규격이 향상됐기 때문이지요. 물론 이것만으로는 비스타 체험 지수는 1밖에 나오지 못하며, 창을 끌어 보기만 해도 답답함이 느껴지기 때문에 비디오 카드 드라이버 업데이트는 필수입니다.

XP보다 전에 선보였던 윈도우 2000은 시대가 시대였으니만큼 여전히 16/256컬러의 잔재를 볼 수 있습니다. 하지만 설령 안전 모드의 16컬러 표준 VGA에서 실행될 때라 하더라도, 그래픽이 쉴 새 없이 변하고 있는 곳에 마우스 포인터를 가져갔을 때 포인터가 깜빡거리거나 사라지지 않습니다. 윈도우 9x 시절에는 상상도 할 수 없었는데! 이걸 보고도 저는 당시 2000은 보통 운영체제가 아니라는 생각을 했었습니다. 하드웨어 차원의 지원이 필요하거든요.

90년대 말, 윈도우 95급 컴퓨터 시절에만 해도(메인보드의 폼 팩터가 슬슬 AT에서 ATX로 넘어가던..), 운영체제의 표준 디폴트 포인터만 깜빡임 보호가 되었지 사용자 정의 포인터는 여전히 깜빡거렸습니다. 비디오 카드의 성능이 썩 좋지 못했다는 뜻이겠죠. 하지만 몇 년 사이에 이마저도 깜빡임이 완전히 사라졌습니다.

아, 그러고 보니 이것도 그래픽 체계의 변화와 관계가 있는지는 모르겠지만, 비스타는 알 수 없는 이유로 인해 콘솔을 전체 화면 모드에서 실행하는 기능이 사라졌고(무조건 창 모드만 가능), 콘솔에다가 파일이나 디렉터리 이름을 마우스로 드래그하여 떨어뜨리는 기능도 없어졌지요.

※ 오디오 (사운드)

지금까지 열거한 비디오 쪽뿐만 아니라 오디오 계층도 윈도우 비스타는 굉장히 많이 바뀌었습니다.
일단 윈도우 95부터 XP까지 큰 차이 없이 제공되던 볼륨 조절 유틸리티 sndvol32.exe가 없어지고 비슷한 기능을 sndvol.exe가 대신 담당하기 시작했는데, 인터페이스가 싹 달라졌죠.

옛날에는 컴퓨터 내부에 소리를 만들어내는 ‘장치’가 여럿 존재했고 윈도우 XP까지는 각 장치들을 멀티미디어 API를 써서 enumerate한 뒤, 장치별로 볼륨을 조절하는 구도였습니다. PC 스피커 따로, 애드립 소리를 내는 미디 따로, 오디오 CD 따로, 입력 단자 따로, 그리고 일반 wave 오디오 따로! (PC 스피커는 볼륨 조절이 되지 않는 게 보통이지만, 노트북 컴퓨터 중엔 그것도 조절되는 게 있었답니다.)

특히 CD롬 드라이브는 CPU와는 전혀 상관없이 자기가 직접 오디오 CD를 재생했습니다. 윈도우 95 시절의 CD 재생기는 그저 오디오 CD에다가 재생/정지/탐색 명령을 내리고, 드라이브로부터 트랙별 시간 정보를 가져와서 재생 지점을 업데이트해 주는 ‘시다바리’ 기능밖에 하지 않았었습니다. 당시 도스용 퀘이크 같은 게임은 오디오 CD 겸 CD롬 형태로 게임을 만들어서 게임 음악은 아예 오디오 트랙의 형태로 제공하기도 했지요.

그러나 지금은 시대가 바뀌었습니다. 사운드 카드는 이제 랜 카드와 더불어 메인보드의 일부로서 완전히 편입이 되어 버렸습니다. 그리고 소리를 내는 모든 장치는 가장 범용적인 매체인 wave 오디오로 통합이 되어 버렸습니다. 이는 전적으로 컴퓨터 성능이 좋아진 덕분입니다.

미디는 이제 어설픈 FM 사운드가 아니라, 소프트웨어적으로 노래방 수준 음향을 wave 오디오로 흉내 내어 주는 신시사이저가 재생합니다. 오디오 CD도 마찬가지. 컴퓨터가 디지털 음원을 일일이 추출, 파악해서 wave 오디오로 내보내는 건 요즘 필수입니다. 그래야 파형 visualization도 보여주고 mp3/wma 리핑 기능도 제공할 수 있을 테니까요.

사정이 이러하니 예전처럼 ‘장치’별 볼륨 조절은 완전히 무의미해졌습니다. 그건 한 프로그램이 어떤 장치를 꺼내서 소리를 출력하면 다른 프로그램은 그 장치를 이용할 수 없던, 쉽게 말해서 멀티웨이브조차 안 되던 윈도우 3.1~95 캐 암울하던 시절의 사고방식이죠. 그나마 wave 오디오의 멀티웨이브는 윈도우 98~2000급으로 넘어가면서 가능해졌지만, 여전히 애드립 미디 같은 다른 장치는 멀티웨이브가 되지 않았었습니다.

비스타부터는 운영체제가 모든 사운드를 wave 오디오 하나로 통제하고 믹싱까지 담당합니다. 그래서 비스타의 볼륨 조절 프로그램을 살펴보면 예전과 같은 개념의 장치 구분은 완전히 사라지고, 현재 실행 중인 응용 프로그램별로 상대적 볼륨을 조절하는 게이지가 나와 있습니다. 이거야말로 윈도우 XP 이하에서는 상상조차 할 수 없던 일이었지 않습니까?

※ 윈도우 각 버전별 비교

Aero Flip3D를 보면서 신기해하던 게 엊그제 같은데 비스타와 오피스 2007이 나온 지도 벌써 2년이 넘었습니다. 제가 XP를 주 작업용 OS로는 ‘빠이빠이’ 한 지도 반 년은 넘은 것 같습니다. 이제는 윈도우 7이 나온다고 해도 비스타하고 시간 간격은 윈도우 95와 98 사이의 간격과 별 차이가 안 날 정도로 시간이 흐른 셈이군요. 그렇게 긴 시간이 지난 것 같지는 않은데.

비스타는 XP 이후로 꽤 긴 시간만에 출시된 데다 상당히 무거운 편인 컴퓨터 요구 사양, 그리고 이질적으로 바뀐 보안 정책, 일부 옛날 프로그램과의 호환성 문제 같은 여러 잡음 때문에 비스타는 그 기술적인 우수성에 비해서는 그렇게까지 환영 받지는 못한 것 같습니다. 그래서 MS도 7에다가 더 전략 가중치를 더 부여하고 있는 듯하기도 하고요.

약 2001~2002년경에 2000/ME/XP 이던 구도가 앞으로는 조만간 XP/비스타/7이 되지 않을까 싶습니다. 비스타는 ME와는 급이 다른 운영체제임에도 불구하고! 차라리 7로 갈아타면 탔지, XP는 앞으로도 한동안은 없어지지 않을 최장수 운영체제로 기억에 남을 것 같습니다.

저의 주 개발 분야인 문자 입출력 쪽만 보더라도 비스타는 일단 TSF를 주된 입력 프로토콜로 완전히 굳혀서 운영체제의 기본 입력기로 지정도 가능하게 했고(XP는 여전히 IME 모듈만 가능함), 일부 TSF A급 확장 프로토콜도 도입했으며 전세계 모든 언어 입력기와 글꼴을 다 내장하고 있습니다. XP로 치자면 ‘동아시아 및 complex script 지원’ 옵션이 선택의 여지 없이 무조건 켜져 있는 것과 같다는 뜻입니다.

한자 글꼴도 단순히 ‘한중일 통합 한자’뿐만 아니라 확장 A, 그리고 심지어 surrogate 영역의 확장 B까지도 Simsun-extB 같은 외국의 확장 글꼴까지 자동으로 대체 동원해서 운영체제 차원에서 제대로 표시해 주는 걸 보고 정말 놀랐습니다. 비스타에서는 굳이 ‘한컴바탕확장’이 없어도 이런 한자들을 어디서나 볼 수 있습니다. <날개셋> 다음 버전에서는 글꼴을 본뜰 때 이런 점도 감안하도록 수정할 예정입니다.

윈도우 ME는 잘 알다시피 태생이 9x 계열이기 때문에 95 이래로 변함없던 유니코드 API 부재, 지저분한 16비트 도스의 잔재에다 불안정한 커널, 64K 리소스 제한 같은 단점은 고스란히 갖고 있습니다. 그래서 비슷한 시기에 나온 2000보다는 95/98과 더 동일시됩니다. 안정성은 떨어지는 주제에 덩치만 더 무거워지고, 겉보기로만 도스로 빠져나가는 옵션은 또 없애 놓으니, 도스와의 호환성 때문에 9x 계열 운영체제를 찾는 파워 유저로부터조차도 외면 받을 수밖에 없었습니다.

하지만 ME도 98 SE에 비해서 장점이 없는 것은 아니어서, 부팅 속도가 매우 빠르고 최신 하드웨어 인식은 역시 98보다 확실히 더 탁월하여 2000급에 필적합니다. VMware로 각 운영체제들의 가상 머신을 만들어 보면 2000/ME 이상은 사운드가 자동으로 잡히는 반면, 95/98은 그렇지 않습니다. 또한 2000/ME부터가 미디 신시사이저를 기본 내장하고 있고 멀티웨이브 기능도 더 원활하게 잘 감지됐습니다. 외장 하드와 USB 메모리를 별도의 드라이버 설치 없이 바로 인식하고, ‘하드웨어 안전하게 제거’ 기능을 갖추고 있는 것도 2000/ME부터입니다.

Posted by 사무엘

2010/01/11 09:47 2010/01/11 09:47
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/69

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

Comments List

  1. 와.... 2010/03/15 21:53 # M/D Reply Permalink

    너무 재미있는 내용입니다

    앞으로 이런 쪽 이야기 많이 올려주세요

    몰랐던 내용 잘 알고 갑니다 ^^

    1. 사무엘 2010/03/16 07:53 # M/D Permalink

      고맙습니다.
      비스타를 조금 써 보니까 바로 저런 차이가 느껴졌는데,
      단순히 Aero나 UAC 같은 거 말고 비스타의 그런 면모에 대해 언급한 글을 찾을 수가 없어서
      제가 직접 정리를 해 본 것입니다.
      저는 그렇다고 해서 그렇게 얼리 어답터나 파워 유저 부류는 아니고요.
      요즘은 옛날만치 자주 글은 못 올리지만, 앞으로도 자주 찾아오셔서 좋은 말씀 많이 남겨 주세요 ^^

Leave a comment

회사 동료가, 수백 개의 작은 그림 파일들을 엑셀을 써서 카탈로그처럼 일목요연한 표 모양으로 한데 정리해야 할 일이 있었습니다. 그 많은 그림들을 일일이 Alt+I, P, F로 삽입하는 건 사람이 할 짓이 못 되었기에 프로그래밍을 할 줄 아는 제가 좀 도와 줬습니다. 셀마다 각 파일들을 이미지로 담고 있는 HTML 표 코드를 생성하는 프로그램을 짠 후, 그 표를 엑셀에서 import하는 방법을 썼지요.

쉘 스크립트라든가 하다못해 엑셀의 매크로를 능숙하게 다루는 분이라면 더 쉬운 방법으로 이 문제를 해결했을지 모르나, 저는 그런 지식은 없었기 때문에 이런 일까지 비주얼 C++을 동원해서 해결했습니다.
그런데 문제는 다음부터였습니다. 이렇게 만든 엑셀 문서는 다른 컴퓨터에서는 그림이 보이지 않았습니다. 그림이 문서에 완전히 내장(embed; by value)되지 않고 링크만 저장되었던 것입니다(by reference).

저는 굉장히 당황하지 않을 수 없었습니다. 원래 MS 오피스의 제품에서 그림을 자체 기능으로 삽입하면, 그림은 기본적으로 문서에 완전히 내장됩니다. 링크라는 개념 자체가 사실상 없는 걸로 저는 알고 있었습니다.

그림을 주로 링크로 취급하던 대표적인 프로그램이 과거 아래아한글이었지요. 그래도 얘는 링크가 깨지면 그림이 있는 경로를 다시 묻기라도 했으며, 3.0부터는 그림을 문서 안에다 내장하는 기능도 추가되었습니다. 그림을 링크만 할지 문서에 내장시킬지를 얼마든지 쉽게 지정할 수 있으며, 한번 그렇게 한 후에도 한 상태로 된 그림을 다른 상태로 전환 역시 얼마든지 할 수 있습니다. 그렇기 때문에 전혀 어려울 게 없었습니다.

xlsx의 내부 구조를 들여다보고는 저는 기겁을 하고 말았습니다. 압축 파일 내부의 media 디렉터리에 아무 파일도 없는 걸로 보아 내장이 안 된 건 확실했는데, 이놈의 링크는 또 C:\로 시작하는 완전 절대 경로로 저장되더군요! 이런 이유로 인해, 상대방 컴퓨터에다가 그냥 그림 파일만 던져 준다고 해서 그림을 볼 수 있는 것도 아니며, 디렉터리 구조까지 완전히 일치해야 했습니다.

진짜로 문서 내부에 내장된 그림과, 이렇게 링크만 달랑 걸린 그림이 제각기 어떤 방식으로 저장되는지는 파악할 수 있었습니다만, 엑셀 프로그램 내부에서는, 아래아한글처럼 어떤 그림이 링크인지 내장인지 알려주거나 그 속성을 바꾸는 기능은 아무리 눈을 씻고 찾아 봐도 없었습니다! 이거 뭐 나더러 어쩌라고?

한국어 검색 엔진으로는 이런 문제에 대한 해결책도 거의 찾을 수 없어서 구글에게 영어 검색어로 의뢰를 해 봤지요. 통상 구글링을 해 보면 여러 해외 IT 분야 '지식인' 내지 포럼 사이트들이 검색되는 게 있습니다. 그런데 네이버 지식인 류와는 또 다른 게, 질문만 쏙 보여주고서 답변을 보려면 결제 내지 최소한 회원 가입은 해야 하는 형태인 게 많습니다. 딱 본인처럼, 그림이 들어간 HTM 표를 엑셀로 가져왔다가 나중에 낭패 본 케이스가 하나 있긴 했는데 답변을 보지는 못했습니다. 썅~

그래서 다음으로 생각해 본 방법은, xlsx의 내부 xml 코드를 고쳐서 문서 내부의 '링크 그림'을 '완전 삽입 그림'으로 인위적으로 수정하고 media 폴더에다 강제로 그림 파일도 추가한 후, 이를 다시 zip으로 압축하는 것이었습니다. 오랜만에 OpenXML 덕을 좀 보는가 싶었는데...

문제는 이 방법마저도 통하지 않았습니다. 압축을 푼 내부 구성 파일을 수정 없이 그대로 빵집 같은 유틸로 재압축만 했는데도, 엑셀은 오류가 있다면서 그 압축(=xlsx) 파일을 읽어들이길 거부한 것입니다. xlsx뿐만 아니라, 오피스 2007 SP2에서 추가된 OpenDocument (역시 xml+zip 기반) 방식 역시 마찬가지. 얘네들은 zip 압축이긴 하지만, 일반 압축 유틸리티가 생성하지 않는 메타 정보도 같이 집어넣는 것 같습니다. 이쯤 되니까 진짜 꽤 열받기 시작했죠. MS 제품이 이 정도로 개념 없는 줄은 몰랐는데.

또 한 30분을 삽질하다가 꽤 허무하게 문제를 해결은 했습니다.
htm 문서를 파일-열기로 열면 그림이 링크로 삽입되는 반면, 웹브라우저에서 이 htm을 연 것을 Ctrl+C로 복사하여 엑셀에다 붙여넣으면, 그 그림들은 완전히 내장으로 삽입된다는 것을 알게 되었기 때문입니다. 아놔~ ㅁㄴㅇㄹ

MS 제품과 아래아한글 사이의 넘사벽 이질감을 또 확인하는 계기였습니다. 이놈의 MS 제품들은 내가 문서라든가 프로그램의 내부를 확실하게 제어(under my control)한다는 느낌을 주질 않고 제멋대로 붕 뜬 상태로 알아서 하다가, 그걸 응용/변형해야 할 상황이 생길 때 사람 완전 낭패 보게 만듭니다. 좋게 말하면 당장 사용하고 결과물 만들기엔 편한 것이고, 나쁘게 말하면 사용자를 바보 만들고 일정 실력 이상은 오르는 게 거의 불가능하게 돼 있는, 좀 사악한(?) 기능 디자인이 아닐까 싶습니다.

MS 워드도 97 시절부터 10년을 넘게 써 왔지만 개요/스타일이라든가 특히 개체를 배치하는 방식에 대해, 저는 독학만으로는 절대 완전히 적응 못 하겠다는 결론을 내리고 포기했습니다. 그 반면 아래아한글은 97은 물론이고 워디안/2002 급 이후 버전도 손에 착 잘 맞는 편입니다. MS 워드에만 있던 고급 기능을 아래아한글 특유의 세밀한 스타일로 잘 배치했다는 점은 인정합니다. 지금도 아래아한글이 기술적으로 워드에게 뒤지는 면모는 있으나, 아래아한글에도 MS 워드가 절대로 흉내낼 수 없는 디자인 상의 안정성과 편안함이 있습니다. (민족주의에 호소하는 한글 표현 같은 것 말고요. 한글 표현마저도 엄밀히 말하면 오히려 MS 워드가 좀더 앞서 있습니다.)

사실 이런 비슷한 느낌은 프로그래밍 언어를 쓰면서도 받습니다. C/C++ 이외의 언어, 특히 type이 굉장히 느슨한 언어로 코딩하다 보면 이 개체가 과연 value로 전달되는지, reference로 전달되는지, new만 있고 delete가 없는 언어들은 도대체 언제 이 개체가 garbage collect되어 소멸되는지?
내가 짜는 건 한 줄이지만 이게 내부적으로 어떤 알고리즘으로 구현되며 데이터가 100개가 아니라 10만 개가 넘어가면 성능이 어떻게 될지?
이런 게 신경쓰여서 불안해서 코딩이 잘 되지 않는 경우가 있습니다. 나와 언어가 일심동체가 못 되고 붕 떠 있는 느낌.

그런 상위 계층 언어들이 how보다 what을 중시하게 하고, 익숙해질 경우 생산성은 더 뛰어난 것은 사실이나 저는 C/C++스러운 저수준 면모가 더 마음에 들고 편안하더군요.

Posted by 사무엘

2010/01/11 09:46 2010/01/11 09:46
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/68

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

Leave a comment

철도역 리모델링의 추억

저의 대학 시절 중반기에 KTX 개통과 주요 대형역들의 리모델링 공사가 행해졌습니다.
그리고 그와 거의 딱 일치하는 시기에 저는 철도 매니아가 됐습니다. 타이밍 한번 절묘하기 그지없습니다.

※ 서울

일제 강점기 때 일본의 건축가가 서양 스타일로 지은 그 유명한 옛 역사는 역사적 가치가 워낙 높아서 사적 문화재로도 지정돼 있죠. 간이역이 아닌 대형역이 문화재로 지정받은 건 유일한 사례가 아닐까 합니다.
옛날 역사만 해도 공항 같다는 느낌이 들 정도로 게이트 수도 많고 덩치가 컸습니다. 요즘이야 선상역이 대세이지만, 옛날에는 어지간한 중대형 역도 1층이 매표소이고 승강장까지는 지하도를 통과하여 가는 경우가 많았는데요. 그래도 서울 역은 옛 건물도 나름 선상역인지라, 탈 때는 1층의 입구로 들어가서 대합실, 매표소가 있는 2층으로 올라가고 다시 승강장으로 계단을 이용하여 내려갔었습니다. (영화 라이터를 켜라 참고)

이미 KTX 개통 전 2003년 말부터 지하철 서울 역의 출구 개조 공사가 활발히 진행됐고 역의 기능은 옆에 새로 지어진 민자역사 유리궁전으로 완전히 넘어갔습니다. 그러고 보니 서울 청계 고가 철거 공사와 시기적으로 비슷했습니다. 신축 건물은 서울 역이라는 문구보다 콩코스(Concos)가 더 큼직하게 보이죠.

옛날 역사는 하차 승객은 역 입구로 나오는 게 아니라, 지하도를 통해 별도의 출구로 빠져나갔습니다.
지금도 대전 역은 지하도는 아니지만 하차 승객의 통로가 별도로 분리된 형태이고, 대전은 동부 고속버스 터미널도 마치 서울 강남 고속버스 터미널처럼 하차장이 따로 갖춰져 있는 게 인상적이랍니다.
참고로 옛날에는 청량리 역도 하차 승객 전용 지하도와 출구가 있었습니다. 지금은 또 새 역사 신축하느라 그것도 다 없어지고 형태가 바뀌었지만.

※ 대전

대전 하면 우동이 유명했지요.
옛날 역사는 2층도 없는(최소한 승객이 올라갈 일은 없는) 1층짜리 자그마한 건물이었고, 역사에서 승강장까지는 또 지하도로 이동하던 형태였습니다. 하지만 2004년부터 슬슬 리모델링 공사가 진행되어 지금은 선상역으로 변했습니다. 저는 대학 시절, 대전 역의 변화를 일일이 목격할 수 있었습니다.

옛날에는 역전 광장도 무지막지하게 넓었습니다만, 지금은 온통 택시 진입로와 지하철 출구 공사 때문에 공간이 거의 사라지고 없습니다. 대전은 건물 통로상으로 딱 연결은 안 돼 있지만 지하철 출구로 나오면 딱 철도역 입구이기 때문에 지하철과의 연계가 서울만큼이나 잘 돼 있습니다.
다만, 대전은 1호선 치고는 철도역에 해당하는 지하철 역이 이례적으로 굉장히 깊습니다. 서울, 대구, 부산은 안 그렇거든요.

※ 동대구

과거의 구질구질하던 동대구 역도 유리궁전으로 변신하고, 언덕 위의 본 입구뿐만 아니라 언덕 아래에서도 올라가는 출입구를 신설했습니다. 사실, 선상역으로 리모델링하면서 서울, 대전도 반대편 출입구가 신설되어 역의 접근성이 더 향상되기도 했답니다.

동대구 역은 언덕 위에 건설되어서 언덕 아래의 승강장으로 내려간다는 특성상, 입구에 들어가서 별도로 또 계단을 오르내리지 않습니다. 들어가면 곧바로 매표소와 대합실이 나오는 게 특이하죠. 나가면 광장은 거의 없고 고가 도로 상으로 차와 택시들만이 즐비합니다.

지하철 동대구 역하고는 서울· 대전에 비해서는 거리가 좀 먼 편입니다. 하지만 이 기회에 이 지역에 동대구 역, 지하철 역, 동대구 고속버스 터미널, 동부 시외버스 터미널이 통합한 종합 터미널이 생기면 얼마나 좋을까 싶기도 합니다. 전국에서 유례를 찾을 수 없는 대구 명물이 되겠죠. 대구는 철도역과 고속버스 터미널 모두 굉장히 특이한 형태라는 건 익히 잘 알려진 사실이니까요.

※ 부산

겉은 으리으리한 유리 궁전으로 탈바꿈하여 외형은 광주 역과 비슷해 보입니다. 하지만 내부는 60년대 말에 건설된 옛날 형태에서 크게 달라진 게 없습니다. 한 건물로 연결은 돼 있지만 서울 같은 완전한 선상역은 아니어서 대합실· 매표소 영역과 승강장 영역은 다소 거리가 있습니다.
바다와 가까운 역이다 보니 이 역의 승강장 주변엔 온통 컨테이너, 화물들을 심심찮게 볼 수 있습니다. 경부선상의 다른 역과는 다른 분위기이고 마치 또다른 항구 역인 인천 역을 떠올리게 합니다.

부산 역은 제가 알고 있는 경부선 역들 중 현재 광장이 가장 넓은 역이기도 합니다. KTX 개통을 앞두고 숱한 리모델링의 손길에도 불구하고 학교 운동장을 방불케 하는 넓은 광장이 아직 원형 그대로 남아 있습니다. 지하철 역과는 그렇게 완전 가깝지는 않아서 지하철 출입구는 학교로 치면 딱 교문까지만 닿지, 대전이나 서울처럼 학교 건물 코앞에 닿아 있지는 않습니다. 이런 점에서는 부전동 역(부전 역)도 마찬가지.
전에도 글로 썼지만 부산은 남쪽이 철도, 북쪽 노포동 쪽에 종합 버스 터미널 이렇게 교통이 양분되어 있습니다.

Posted by 사무엘

2010/01/11 09:45 2010/01/11 09:45
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/67

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

Leave a comment

※ 종축 (서 -> 동 순)

15: 가장 서쪽에 있는 서해안 고속도로입니다. 서울 2기 지하철 전구간, 그리고 인천 공항과 더불어 2001년에 완전 개통한 이 도로는 서울-목포를 일직선으로 연결하며 특히 충청도 서부의 발전에 크게 기여했습니다. 서울에는 서서울 톨게이트로 진입하며, 횡축인 영동 고속도로하고는 안산 분기점에서, 외곽 순환과는 조남 분기점에서 만나는데 두 분기점은 서로 굉장히 가까이 있습니다.
소설 <상록수>의 저자 심 훈이 최 용신의 장례식에 참석하러 당진에서 안산까지 찾아왔다고 하는데, 그 이동 경로가 이 도로하고 거의 정확히 일치합니다.

1: 한국 고속도로의 상징인, 그 이름도 유명한 경부 고속도로입니다. 대각선 경로이기 때문에 정확하게 횡축이라고 보기는 힘듭니다. 건설비가 1km당 사기에 가까운 1억 원이 들었고 비슷한 시기에 비슷한 규모로 건설된 일본 동명 고속도로 건설비의 1/8이 들었다는 도로. 그러나 그 후 유지 보수, 패치하는 데 비용이 훨씬 더 많아 든 도로. 1970년 7월 7일에 개통식이 열렸고 공사 중에 77명이 순직했다는 그 도로입니다.
평택 이북으로는 철도와는 달리 서쪽이 아닌 동쪽으로 간다는 점, 그리고 남부에서 경주와 울산 근처로 우회한다는 점만 빼면 철도 경부선과 노선이 얼추 비슷합니다. 분당에 서울 톨게이트가 있으며, 영동과는 신갈 분기점에서, 외곽 순환과는 판교 분기점에서 만납니다. 처음엔 전구간 4차선으로 건설됐지만 지금은 건천-경주-울산 같은 남쪽 최고 오지 구간만 제외하면 거의 다 6, 8차선급으로 확장됐습니다.

25: 이 번호는 서울에서 시작하는 고속도로가 아닙니다. 경부 고속도로에서 시작하다가 천안에서 갈라지는 논산-천안 민자 고속도로와, 호남 고속도로를 한데 묶어 25번이라고 일컫습니다. 원래 대전에서 논산까지 이어지던 구간은 251번 호남 고속도로 지선으로 바뀌었습니다. 마치 철도에서, 서대전-대전처럼 원래 호남선의 일부였던 구간이 대전선이라는 지선으로 바뀐 것과 비슷한 맥락입니다.

35: 중부 고속도로와 통영-대전 고속도로를 한데 묶어 일컫는 번호입니다. 두 고속도로는 엄밀히 말하면 서로 끊어져 있고, 그 사이의 청주-대전은 경부 고속도로 구간을 공유합니다. 중부는 잘 알다시피 청주, 이천, 용인, 광주, 하남처럼 산으로 가로막혀 있고 철도도 없던 수도권 동남부 교통 오지의 접근성을 크게 올려 주었습니다.
호법 분기점에서 영동 고속도로와 만나며, 하남 분기점에서 외곽 순환과 만남과 동시에 이 고속도로도 끝이 납니다. 동서울 톨게이트가 있습니다. 대전 이남은 가 본 적이 없군요.

37: 폭증하는 교통량을 감당하기 위해, 이천에서 하남까지 위의 중부 고속도로와 동일한 구간에다 또 도로를 건설한 것입니다. 제 2 중부 고속도로라고 부릅니다. 경부는 대부분 평지에 저렴하게 건설됐기 때문에 확장이 쉬웠지만, 중부는 길이 없는 험준한 산을 다 고가와 터널로 뚫으면서 건설된지라 도저히 확장을 할 수가 없었고 옆에 도로를 또 만드는 수밖에 없었지요. 제 2 중부는 중간 나들목도 없기 때문에 일종의 장거리 급행 도로 역할도 합니다.

45: 중부내륙 고속도로입니다. 대전을 안 거치고 여주, 충주, 상주 같은 국토 최고 중심부를 관통하여 경기도와 경상도를 지름길로 연결합니다. 덕분에 서울에서 구미 이남으로 가는 고속버스들은 이 도로를 즐겨 이용합니다. 가는 길목에서 철도 충북선과 경북선하고 모두 마주치며, 김천에서 경부 고속도로와 만나지요. 김천 이남으로는 창녕, 마산까지 한데 쭉 이어지는데, 그쪽까지는 가 본 경험이 없습니다.

55: 대구에서 출발하여 군위, 의성, 안동, 풍기, 제천, 원주로 가는 중앙 고속도로와, 그 유명한 부산-대구 민자 고속도로를 한데 일컫는 번호입니다. 중앙 고속도로는 철도 중앙선과 놀라울 정도로 노선이 비슷하죠. 하지만 이제 수도권과 꽤 멀리 떨어져 있으며 북쪽에서 서울을 향하지 않고 춘천으로 간다는 점 때문에 평시에 통행량이 그렇게 많지는 않습니다. 경부 고속도로에서 중앙 고속도로는 금호 분기점에서, 부산-대구 민자 고속도로는 동대구 분기점에서 진입하면 되는데, 이 둘의 거리는 그렇게 길지는 않습니다. 본인 이용 경험 없음.

65: 서해안 축에 비해 여전히 교통 오지로 남아 있는 동해안 축을 연결하기 위한 고속도로 노선입니다. 현재는 작년 말에 갓 개통한 부산-울산간 민자 고속도로에 이 번호가 붙어 있지요. 경부 고속도로는 너무 서쪽으로 치우쳐 있어서 정작 울산에서는 이용하기 힘든 감이 있었습니다.
새로 생긴 고속도로는 부산과 울산을 30분대 거리로 연결해 주었지만, 길이 너무 곧아서 과속의 여지가 있다는 비판도 받고 있다고 합니다. 본인 이용 경험 없음.

※ 횡축 (남 -> 북 순)
우리나라는 통일을 염두에 두고 도로에서 남쪽을 기점으로 본다고 말씀드린 바 있습니다. 그래서 동서를 관통하는 횡축 도로도 남쪽부터 차례대로 번호를 매깁니다.

10: 국토 최남단에 있는 남해 고속도로는 철도 경전선과 노선이 거의 일치합니다. 본인 이용 경험 전무함.

12: 4공 때 경부가 건설됐다면, 5공 때는 대구와 광주를 잇는 악명 높은 88 올림픽 고속도로가 건설됐죠. 소백 산맥을 넘으면서 주변 경치는 정말 좋지만, 그래 봤자 최고 시속 겨우 80에 중앙 분리대도 없는 2차선의 열악한 도로입니다. 중앙선을 넘어 앞차를 추월하려다가 맞은편 차선과 정면 충돌 사고도 막 나서 교통사고 치사율이 굉장히 높습니다. 본인 이용 경험 전무하며, 언젠가 드라이브를 해 보고 싶음.

20: 산으로 가로막힌 지형의 특성상 경주를 거치는 길밖에 없었던 포항과 대구를 직통으로 이은 것을 시작으로, 무주, 익산, 군산을 연결할 예정인 노선 번호입니다. 그렇게 다 완공되고 나면 국도 4호선과 경로가 얼추 비슷해지겠군요. 본인은 이용 경험 없음.
하지만, 이 고속도로가 생긴 후에도 시외버스들은 여전히 경주를 거쳐서 대구나 서울로 가고 있으며, 대구-포항은 고속버스 노선도 없어서 이 도로의 이용 빈도는 그다지 높지 않은 걸로 알고 있습니다. 그나저나 얘는 대구-부산과는 달리 비싼 민자 도로는 아니지요.

30: 2007년 말에 개통한 청원-상주 고속도로에 붙은 번호입니다. 이 도로는 국내에서 최초로 최고 시속 120km를 기준으로 건설되기도 했습니다. 서쪽으로 평택까지 확장 공사가 진행 중이지만 동쪽으로는 별다른 계획이 없군요. 아마 안동, 영덕 정도가 되지 않을까 싶습니다.
본인은 딱 한 번 구경한 적 있습니다. 회인, 속리산 등 지금까지 들어 보지 못한 나들목 이름이 나와서 놀랐더랬습니다.

40: 경기도 남부에서 서해안과 경부 고속도로를 연결해 주는 평택-안성간 고속도로로 개통했습니다. 비록 지금은 짧지만 앞으로 진천, 충주, 제천까지 연장될 예정입니다.

50: 횡축 고속도로 중에 현재 가장 길고 유명한 영동 고속도로입니다. 수도권에서도 가깝기 때문에 인천에서 강릉까지 이 도로가 경기도 남부에서 감당하는 교통 비중은 가히 절대적이며, 주말과 평일을 가리지 않고 차들로 인해 큰 혼잡을 겪고 있습니다. 신설된 직선 고가 도로 덕분에 서울에서 강릉까지 불과 3시간대에 갈 수 있으며, 이는 재래식 철도인 태백, 영동선과는 비교할 수 없이 빠릅니다.

60: 영동보다 더 북쪽으로, 한창 건설이 진행 중인 경춘 고속도로에 이 번호가 붙어 있으며, 이 도로는 앞으로 강원도 양양까지 연장될 예정이라 합니다.

※ 다음은 수도권에 있는 여타 고속도로들입니다.

100: 서울 지하철 2호선을 떠올리게 하는 외곽 순환 고속도로입니다. 첫 구간이 건설된 이래 거의 20년만에 완전한 고리를 이루게 되었지요. 경기도 남부에서는 마치 영동 고속도로처럼 횡축 노선을 제공하고 있고 북부는 민자 구간으로 서울 교외선과 노선이 매우 비슷합니다. 저는 남부 구간만 구경해 봤습니다. 의왕, 과천에서 매우 높은 고가로 경부선 철길을 타넘는 형태가 인상적입니다.

110~130: 120번이 경인 고속도로이고 130이 그 위로 지나는 공항 고속도로, 그리고 110은 제 2 경인 고속도로입니다. 인천과 서울은 철도도 2복선이고 고속도로도 무려 3개나 있는 셈이네요. 차선도 당연히 8차선. 그래도 쏟아지는 교통량을 감당을 못 해서 저속도로, 통행료 폐지라는 말이 나오는 지경입니다. 전국에서 가장 뻑뻑한 길은 단연 ‘경인’ 축임이 틀림없습니다.
저는 인천은 전철로밖에 가 보질 않아서 이쪽 고속도로는 구경한 적이 없습니다.

Posted by 사무엘

2010/01/11 09:43 2010/01/11 09:43
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/66

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

Leave a comment

아래아한글 2007은 2006년 한글날에 출시되었던 초창기 RTM 판을 어둠의 경로로나 잠깐 구해 쓰다가 다시 2005로 돌아와 버렸고, 저는 그 존재감을 1년이 넘게 잊고 지내 왔습니다.

그런데 얼마 전 한 지인께서 보내 주신 아래아한글 2007은 정말 사뭇 달라진 모습이었습니다.
사실 아래아한글이 그 때 이후로 3년에 가까운 시간 동안 아직까지 메이저 버전업이 없는 상태이긴 하지만 그래도 제품 개선은 정말 꾸준히 돼 오고 있었습니다. MS 식으로 표현하자면, 단순한 버그/보안 업데이트 수준을 넘어 서비스 팩 정도는 된다는 거지요.

각종 패치와 업데이트를 다 받고 나니 버전은 7.5.8.527이 되었습니다. 아래아한글도 날개셋과 마찬가지로 비주얼 C++ 2003 (7.1)로 개발되고 있는 건 여전하고요.
윈도우 비스타에서 “시스템 스타일” 테마를 쓰면드디어 Aero 반투명 프레임이 적용된 대화상자가 나오더군요. (2005는 그렇지 않았음.) 윈도우 XP 시절엔 MS 오피스 2003 테마가 그럭저럭 볼만 했으나 비스타에서는 아주 밍밍하고 보기 안 좋은 모양이 돼 버리기 때문에 차라리 아래아한글 2007 특유의 기본 블루 메탈 테마나 시스템 스타일 테마가 낫습니다.

지금까지 아래아한글은 대화상자에서 숫자만 입력 받는 에디트 컨트롤의 동작이 정말 기괴했습니다. 글씨 크기나 여백량 등. 세벌식 자판을 쓰고 있으면, 2004 이하에서는 Shift+알파벳의 고유 숫자도 동작을 안 하고, 0~9의 쿼티 숫자 배열도 동작을 안 해서 꼼짝없이 글자판을 바꾸거나 numlock 키패드만 써야 했습니다. 그러던 것이 2005에서는 Shift+알파벳 숫자는 인식되도록 개선됐고, 2007에서는 숫자 입력란에서는 아예 한글 글자판이 동작 안 하고 무조건 0~9 숫자만 인식하게 바뀌었던데 저는 차라리 이런 결정을 환영합니다. 정말 속 답답하던 동작 방식이었는데 무척 잘 했습니다.

글꼴을 고르는 콤보 박스가 화살표 키 선택만 가능한 게 아니라 이름을 입력도 해서 빠르게 찾을 수 있게 된 것은 매우 환영할 만한 기능. 비주얼 C++ IDE는 2003에서 2005 이후로 넘어가면서 이런 점에선 오히려 퇴보했죠. (물론 글꼴이 주류인 프로그램은 아니지만.)

그리고 운영체제 한글 IME로 비완성형 문자가 ?로 바뀌고 제대로 입력되지 않던 버그.. 드디어 고쳐진 것을 확인했습니다. 이제 아래아한글로도 <날개셋> 한글 입력기를 띄워서 각종 확장 한자나 옛한글까지 그대로 입력할 수 있습니다.

어떤 프로그램이 유니코드를 얼마나 잘 대비해서 만들어졌는지 측정하는 좋은 척도 중 하나는 파일 이름 인식인데요.
제가 보기엔 아래아한글은 아직도 윈도우 9x를 지원하느라, 혹은 TCHAR 같은 범용 자료형으로 Unicode-prepared된 코드를 작성해 놓지를 못해서... 하이튼 이 둘 중 한 이유로 인해 과감하게 스위치를 유니코드로 바꿔서 빌드 못 하고,
당장 유니코드 문자 지원이 절대적으로 필요한 부분에다가만 유니코드 함수를 임시방편으로 끼워넣은 거라는 인상을 받습니다. 윈도우 XP sp2 이상만 지원하는 MS 오피스 2007과는 달리, 한컴 제품은 똑같은 2007이 무려 윈도우 98 이상을 지원한다고 명시하고 있지요.. 물론 날개셋은 윈도우 95/NT4까지 다 지원.. 그러고도 유니코드도 100% 지원하죠.

임시방편이라고 생각하는 근거를 말씀드리자면..
영문 윈도우에서 HWP 파일은 한글이 섞인 파일도 잘 불러옵니다. 한글이 섞인 디렉터리 이동도 되고 파일 열기도 대화상자와 drag/drop 방식 모두 잘 되더군요. 이것만 해도 크게 개선된 것입니다. 하지만 HWP가 아닌 TXT 파일은 열리지 않았습니다. 더구나 “다른 프로세스가 파일을 사용 중이어서 열 수 없습니다”라고 에러 메시지도 ‘잘못’ 나오고요.따로 처리할 이유가 전혀 없는데도 파일 타입에 따라 유니코드 API 사용 여부를 따로 처리하고 있으니, 일관성 있는 처리가 아니라 HWP에다가만 임시방편 처리를 추가한 거라는 결론을 잠정적으로 내린 것이죠. 또한 ‘열기’ 대화상자라든가 타이틀에 뜨는 문서 파일 이름이 여전히 ???? 로 바뀌어 나온다는 것도 개선돼야 할 것입니다. 진짜로 여기서는 Ansi, 저기서는 유니코드 API를 섞어 쓴 것입니다.

한편, 아래아한글도 드디어 2007 나중판에서는 문서를 PDF로 저장? 인쇄? 하는 기능이 자체 포함되었습니다. 예전에 별개의 제품으로 팔던 PDF converter 엔진이 그대로 포함되어, 자체 글꼴인 HFT까지도 깔끔한 PDF로 바꿔 줍니다! 2.5 확장팩 시절의 추억의 신명 시스템 글꼴과 3.0/96 때의 #로 시작하는 수많은 글꼴들을 이제 깔끔한 PDF로 만날 수 있어 무한 감개무량하며 앞으로 아래아한글 쓸 일이 더욱 늘 것 같습니다.

단, 하나 옥의 티를 찾았는데요.
HFT 영문 이탤릭 글꼴이 PDF로 제대로 인쇄되지 않고 그냥 normal 글꼴을 기울인 형태로 바뀌어 버리더군요.
아래아한글이 내장하고 있는 신명조와 윈도우 운영체제가 내장하고 있는 바탕은 둘 다 ‘한양 시스템’에서 제작했으며 원도가 거의 일치합니다. 물론 후자가 영문의 폭이 좀더 크긴 하지만 비슷하죠.

하지만 둘의 큰 차이를 하나 꼽자면 전자는 영문에 이탤릭 전용 글꼴이 있다는 것입니다.
더구나 아래아한글 2.5 정도에서 추가된 걸로 기억하는 수식 전용 글꼴은 당시 교과서와 문제집 같은 출판물에서나 볼 수 있던 그 자형을 재현한 것이어서 더욱 의미가 컸습니다. 이것도 이탤릭체가 없으면 거의 무용지물이죠. 이것이 PDF로 만들면 여전히 되살아나지 않으니 개선이 필요하다고 봅니다.

끝으로 이건 극소수 매니아 계층 이외에게는 거의 의미가 없을 내용이지만 제품의 완성도 차원에서 하나 언급하겠습니다. 아래아한글의 한자 코드 체계와 관련이 있는 내용입니다.
아래아한글 2.0 이후에서부터 추가된 약 11000여 자의 제 2 수준 한자는 유니코드 BMP 영역에 대부분 이미 존재하지만(A급), 어떤 건 BMP에 없고 무려 surrogate 영역(B급)까지 가야 하는 것도 있으며 어떤 건 아예 유니코드 자체에 아직 정식 등재되지 않은 것(C급)도 있습니다. 물론 유니코드 버전이 계속 올라가면서 C급 한자라는 집합은 완전히 사라질 수도 있지요. 지금도 C급 한자는 거의 10여 자 남짓밖에 안 됩니다.

아래아한글은 이미 제 2수준 한자와 유니코드 사이의 변환 테이블도 다 갖추고 있고 이를 문자표에다 제공하고 있습니다. 하지만 정작 한컴 2바이트 코드로 저장된 파일을 가져와 보면 아래아한글이 지금처럼 유니코드 surrogate를 정식 지원하기 전에 워디안/2002 시절에 임시로 사용하던 변환 테이블을 여전히 수정하지 않은 것 같습니다.
가령 B급 한자에 속하는 0x531C는 한중일 통합 한자 확장 B인 U+20850 (surrogate 영역)이지만 이 글자를 한컴 2바이트 코드로 저장하여 불러와 보면, 옛날의 임시 주소인 U+A700이라는 엉뚱한 문자가 되지요.

아래아한글은 97에서 워디안으로 넘어갈 때 정말 큰 진통을 겪긴 했지만 그래도 그때 고비를 잘 넘긴 것 같습니다. 그때 HWP 파일 포맷이 딱 바뀐 이후, 지금은 아랍 어, 세로쓰기, 문서 워터마크 등 문서의 뼈대 구조를 결정하는 굵직한 기능이 엄청 많이 추가되었음에도 불구하고 워디안부터 2007까지 파일 포맷이 근본적으로 바뀌는 일 없이 하위/상위 호환성이 잘 유지되고 있으니까요.

다음 버전(아마 2010)은 지금 MS 오피스 다음 버전이 추구하고 있는 것과 마찬가지로 ODF 스펙 구현이 몰두 중이라고 합니다. 개인적인 생각은 아래아한글도 어서 워드처럼 개체가 사각형이 아닌 모양으로 본문을 감싸는 기능이 지원돼야 한다고 생각합니다. 앞서 지적했지만 유니코드 지원도 강화돼야 할 것이고, 좀더 욕심을 부리면 워드처럼 TSF A급 프로그램으로 발전하고 한양 PUA가 아닌 유니코드 낱자 결합 방식으로 옛한글을 지원해야 할 텐데, 참 가야 할 길이 멀군요!

Posted by 사무엘

2010/01/11 09:43 2010/01/11 09:43
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/65

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

Leave a comment

C++, 템플릿 이야기

오늘날 소프트웨어 업계에서 네이티브 기계어 기반 프로그램을 개발, 빌드하는 데 가장 널리 쓰이는 언어는 단연 C++이다.
C++은 잘 알다시피 C언어로부터 파생되어 C의 호환성을 유지하면서 거기에 OOP 요소를 가미한 매우 복잡한 언어이다. 클래스와 this 포인터, 생성자/소멸자. 상속, 정보 은닉, 다형성 따위는 언뜻 C처럼 보이는 코드의 함축성과 표현력을 월등히 끌어올려 주었다.

C++이 처음 등장한 것은 1983년이지만, 당대의 주류 컴퓨터 성능에 비해서 컴파일러 구현의 난해함, C++의 개념을 구현하기 위한 비용에 대한 논란 등등 때문에 실제로 C++이 업계에서 널리 쓰이기 시작한 것은 최소한 90년도가 지나서이다.

C++도 일종의 순수주의자의 관점에서 보자면 지저분한 특성, 욕 얻어먹을 면모가 굉장히 많다. 마치 윈도우라는 운영체제처럼.
하지만 상업적으로 성공하는 제품은 역시 무조건 성능이 우수한 것보다는, 현실과 이상을 적당히 잘 절충하고 대중화를 잘 한 녀석이라는 사실은 프로그래밍 언어라는 바닥에서도 적용되는 게 틀림없다.

오늘날 C++ 말고 동급 용도의 다른 어떤 언어에도 존재하지 않으며 앞으로도 차용되지 않을 기능을 뽑자면 아마 전처리기와 다중 상속이 아닌가 싶다. 강력한 만큼 괴악하고 폐단(?)이 심하기도 한 기능이어서이다. 요즘은 조건부 컴파일의 범위를 넘어서는 전처리기/매크로 기능은 거의 빠지는 추세이고 다중 상속도 인터페이스라는 다른 개념으로 대체되고 있다. 자바, C#, D 같은 언어의 스펙을 보면 그 alternative를 알 수 있다.

C++은 첫 등장한 후에도 꾸준히 변화해 왔다.
90년대 이후에는 템플릿이라는 어마어마한 기능이 추가되었으며
기능상으로 없던 게 추가된 건 아니지만, type-safety 강화 및 모호성 발생 예방을 위해서 특별히 취해진 조치도 상당하다. 가령, static_cast 같은 장황한 형변환 연산자가 추가되었으며 bool, wchar_t 같은 타입이 built-in으로 추가되었다. explicit도 이런 차원에서 추가된 키워드이다.

namespace는 각종 명칭들의 scope을 C와 같은 2차원적인 평면이 아닌 3차원적인 입체 계층으로 관리하게 해 준 엄청난 기능인 한편으로 C++ 컴파일러 구현의 난해성을 더욱 올린 기능이 아닌가 싶다. 컴파일러 개발자 내지 컴파일러를 돌리는 컴퓨터가 고생하는 만큼 프로그래머는 더 편해지고 프로그램을 유지 관리하기가 더 수월해지는 셈이다.

얼마 전엔 꽤 흔치 않은 개념을 코딩해야 할 일이 있었다.
템플릿 클래스 안에 static 멤버가 있었고, 이 멤버는 그 클래스가 자체 정의하는 구조체를 사용하고 있었다. 그래서 이 static 멤버를 클래스 바깥에서 초기화를 해 줘야 했는데, 그 멤버의 type을 클래스 바깥에서 표현이 제대로 되지 않고 자꾸 컴파일 에러가 나는 것이었다.

template<typename T>
class A {
        struct B {
        };
        static B data;
};

template<typename T>
A<T>::B A<T>::data;

(1) C++ 초창기.. 그러니까 한 터보 C++ 1.0 시절에는 static 데이터 멤버를 이렇게 바깥에서 정의 안 해 줘도 괜찮았다. 하지만 스펙이 바뀌어서 정의를 안 하면 링크 에러가 나게 나중에 바뀌었다.

(2) 또한 typename이라는 키워드도 C++에 템플릿이 추가되고 나서 한 박자 뒤에 표준화되어 90년대 중반에 도입된 것이다. 예전에는 class T만 가능했다가 문맥상 혼동을 없애기 위해 나중에 추가되었다.

어쨌든.. A라는 클래스가 템플릿이 아니거나,
혹은 data의 타입이 저런 자체 구조체가 아니라 전역 scope로 존재하는 다른 구조체 내지 그냥 built-in 타입이었다면.. 저렇게 선언하는 건 정말 일도 아니다.
그리고 솔직히 템플릿 클래스에다가 저런 식의 멤버를 만드는 일은 굉장히 희박한 것도 사실이다.

템플릿 클래스 내부의 자체 구조체로 선언된 static 멤버를 정의하는 방법은 아무리 생각해도 저것밖에 없는데 컴파일러가 도무지 말을 안 들어서 한 30분을 삽질했다.
그런데 문제 해결 방법은 기괴했다. typename을 앞에 추가하면 되더라..;;

template<typename T>
typename A<T>::B A<T>::data;

템플릿은 컴파일러가 실제로 생성해 내는 그 코드 자체가 아니라, 나중에 코드를 생성하는 틀, 말 그대로 템플릿에 불과하기 때문에 C++ 컴파일러에 템플릿이 첫 도입되었던 초창기엔 디버깅도 굉장히 어렵고, 실제로 템플릿을 A<int>처럼 인스턴스화해서 사용해 보기 전엔 컴파일 에러 자체도 잡아내기가 쉽지 않았다. 더구나 템플릿 클래스의 각종 구현부도 소스 파일이 아니라 헤더 파일에 다 선언되어 있어야 하기 때문에 한계가 많으며, 최적화 성능도 시원찮아서 code bloat의 주범이라고 욕도 먹었다. int형 코드 따로, short형 코드 따로 등등등.

하지만 지금은 상황이 많아 나아져서, 적당히 비슷한 타입으로 여러 템플릿을 사용하더라도 어지간한 건 void *형 포인터로 C 문법으로 general하게 코드를 생성할 정도로 컴파일러도 많이 똑똑해졌다. compile-time뿐만 아니라 link-time에 코드를 생성하고 한 obj 파일뿐만 아니라 여러 obj 파일 사이의 전역적인 최적화를 수행하는 기술이 도입된 것도 템플릿의 처리에 무척 유리하다. 압축으로 치면 RAR의 솔리드 압축 기능뻘 된다. 비주얼 C++은 6.0은 이런 기능이 없고, 200x닷넷급에서 최초로 이런 게 도입되었다.

C는 일단 그 가벼움과 C 특유의 이식성 때문에 영원히 절대 없어지지 않을 언어이다. (그 정도 고급 언어 중에 공용체, 비트 필드가 존재하는 언어가 또 무엇이 있을까? =_=;; C에 비트 회전 연산자가 없는 게 이상하다.)
그에 반해 C++은 동급이면서 더 깔끔하고 생산성 뛰어나고 GC(누수 메모리 자동 회수)까지 지원하는 다른 차세대 OOP 언어로 먼 미래에 대체될 수 있을 수도 있겠다는 생각이 들기도 한다. 특히 클라이언트에서 네이티브의 비중이 낮아질수록 지위가 역전되는 시기는 더욱 일러질지도 모르겠다.

윈도우 운영체제가 전통적으로 C언어식 API를 제공해 왔다면, 닷넷은 C# 기반이기도 하다.
하지만 20여 년에 가까운 컴퓨터 역사상, 무수히 쌓인 C/C++ 코드의 쪽수와 짬밥이 쉽사리 역전될 것 같지는 않기도 하고.. 미래를 예측하기란 참 어렵다. ^^;;

Posted by 사무엘

2010/01/11 09:40 2010/01/11 09:40
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/64

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

Leave a comment

항공기의 종류 정리

사람이나 물건을 싣고 공중을 비행할 수 있는 교통수단을 모두 통틀어 ‘항공기’(aircraft)라고 한다.
미사일은 항공기와 같은 역학 원리로 목표물을 향해 날아가지만 단순히 비행체일 뿐 항공기는 아니다.
또한 아예 지구 대기권을 벗어나 날아가는 로켓, 우주 왕복선은 비록 승무원이 탑승했다 하더라도 항공기라고 간주하지는 않는다.

항공기를 분류하는 큰 속성을 둘 꼽자면 경항공기냐 중항공기냐, 그리고 동력원이 있냐 없냐이다.
경항공기(aerostat)란 밀도를 공기보다 낮춤으로써 날아가는 항공기를 말한다. 동력원이 없는 경항공기는 기구(balloon)이며, 동력원이 있는 경항공기는 비행선(airship)이다.

밀도를 낮춰서 뜨기 위해서는 경항공기는 부피가 어마어마하게 커야 한다. 비운의 사고로 최후를 맞이한 힌덴부르크 호의 경우 생긴 것만 봐도 프로토스 캐리어를 연상시키는데, 타이타닉 호보다 덩치가 더 컸다. 마치 옛날에 자전거가 앞바퀴가 엄청나게 컸던 것 같은 그런 과도기 모습을 보는 것 같다. 물론 그래 봤자 수송 인원은 오늘날의 중형 제트 여객기 수준밖에 안 된다.

기구는 수송력과 이동성은 실용적인 가치가 거의 없으며 그저 하늘에 뜨는 것 자체에만 의미가 있다고 봐야 한다. 그나마 비행선이 20세기 초반에 여객 수송용으로 잠시 실용화된 적이 있다가 경제성, 안전 등 여러 문제로 인해 오늘날은 사라졌다. 공기보다 가벼운 대표적인 기체인 수소는 너무 위험하고 헬륨은 너무 비싸다는 게 문제이다. 공기보다 가볍다고 해서 기구가 한없이 위로 올라가면, 희박한 주변 공기 탓에 기구 내부의 공기가 펑 터져 나오고 만다는 것도 잘 알려진 현상이다.

그럼, 중항공기에 대해 살펴보자. 중항공기는 공기보다 무거우며, 양력이라는 물리 특성을 활용하여 공중에 뜬다. 중항공기 중에 동력원이 없는 것은 글라이더(glider)이다. 물론 글라이더는 스스로 공중에 뜰 수는 없기 때문에 마치 연을 처음 날릴 때처럼 자동차 견인 같은 도움을 받아야 한다. 동력도 없는 데다 밀도까지 높은 글라이더는 기구만큼이나 용도가 크게 제한되며, 탑승 인원도 거의 전투기 수준밖에 될 수 없다.

동력원이 있는 중항공기가 드디어 진정한 ‘비행기’(airplane)이라고 불릴 수 있는 교통수단이며 그 전신을 라이트 형제가 최초로 발명한 것으로 알려져 있다. 단순히 car이다가 이제 automobile로 바뀐 셈이다. 비행기는 크게 고정익 항공기와 회전익 항공기로 나뉜다. 전자는 고정된 커다란 날개를 통해 양력을 얻어서 공중에 뜨며, 이착륙할 때 활주로가 필요한 평범한 비행기이다. 후자는 우리가 헬리콥터라고 부르는 그런 비행기이다. 물론 수직 이착륙이 가능한 중간 형태의 비행기도 특수한 용도로 쓰인다.

따라서, '경비행기'는 말 그대로 덩치가 작은 중항공기를 일컫는 말이지만, '경항공기'는 부피면에서 비슷한 수송력을 지닌 중항공기보다 훨씬 더 크면 컸지 결코 작지는 않다는 것을 알 수 있다.

바퀴를 굴려서 지표면과의 마찰을 의지하여 움직이는 육상 교통수단과는 달리, 항공기와 선박에는 동력원이 없이 움직이는 방법이 존재한다는 것이 인상적이다. 비록 동력 기관이 발명된 것은 2, 300년 남짓밖에 안 되었지만, 육로와 해로는 성경에도 등장할 정도로 인류 역사상 가장 오래 된 교통수단이다.

그 반면 철도는 은근히 굉장히 최근에 발명된 교통수단으로, 처음 등장한 시기가 고작 1800년대밖에 되지 않는다. 항공은 역사가 더 짧아서 겨우 1세기 남짓이다. 그래서 항공업계에서 쓰이는 cabin, boarding, captain 같은 용어는 선박 분야로부터 고스란히 물려받은 용어이기도 하다. 다른 교통수단도 마찬가지이지만 항공은, 말세에 인류의 이동이 빨라져 이리저리 왕래하고 지식이 증가할 거라고 성경 다니엘서에 예언된 그 예언을 이루는 주된 도구임이 틀림없다.

그나저나 집채만한 비행기가 어떻게 공중에 뜨고 전투기는 묘기까지 부릴 수 있는지, 글라이더가 어떻게 뜨는지도 나는 도통 이해할 수 없다. 파일럿 류만 이해가 안 가는 게 아니라 항공기 류 자체가 별로 이해가.. ㅜㅜ
불과 몇백 년 전만 해도 당대 최고의 물리학자조차 공기보다 무거우면서 하늘을 나는 artifact는 존재 불가능이라고 단언을 했었지 않은가.

Posted by 사무엘

2010/01/11 09:39 2010/01/11 09:39
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/63

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

Leave a comment

인천 공항 스타라인

인천 공항 내부에 있는 스타라인이라는 무인 경전철은, 인천 공항에 확장 탑승동이 지어진 관계로 main 여객 터미널과 확장 탑승동을 연결하기 위해서 활주로 지하에 건설되었다. 둘 사이의 거리는 거의 900미터 정도 된다고 한다.
완공도 작년 6월이니 얼마 되지 않았으며, 한창 내가 병특 마칠 무렵에 생긴 것이었다. 작년에 미국 갔다 올 때도 이미 있었다는 얘기인데 나는 물론 그땐 그런 게 있다는 걸 알지 못했다.

물론 타는 곳은 승차권을 소지하고 보안 검색과 출국 신고까지 마친 승객 당사자만 들어갈 수 있는 ‘면세 구역’에 있기 때문에 일반 공항 방문객이 이걸 이용할 수는 없다. 확장 탑승동은 전구간이 면세 구역이다. 지난 3월 말에 중국 갔다 올 땐, 겨우 1시간 남짓 제주도 거리밖에 안 되는 노선을 이용하는데 탑승구까지 가느라 시껍을 했다. 비행기에서 내린 직후 공항의 면세 구역을 완전히 벗어나 환영객이 기다리고 있는 출구까지 나가는 데 거의 30분은 걸린 것 같았다. 수하물 찾을 것도 없었는데도! 아예 비행기 탑승권 뒷면에도 “탑승구가 졸라 멀리 떨어져 있으니 공항에 꼭 충분히 일찍 오셔야 합니다” 주의 사항이 찍혀 있었다.

스타라인 자체에 대해서 얘기를 좀 더 하자면, 일단 서울 지하철이나 심지어 공항 철도와도 굉장히 다르다. 차량은 3량 1편성이며, 운전석이 없는 무인 열차여서 앞뒤 터널 경치를 볼 수 있다. (물론 차량 자체도 일본에서 도입한 거라고 한다) 그리고 고무 바퀴이다. 한 편성 안의 모든 차량이 같은 외형으로 생겼으며 객실과 객실 사이를 이동할 수 없다. 다수의 항공 여객을 아주 짤막한 시간 동안만 수송하는 차량의 특성상, 좌석은 소수의 노약자석 말고는 없다.

또 하나 매우 중요한 사실이 있다.
재미 삼아 한 열차 안에서 짱박고 있다가 왔던 길로 되돌아가면 되는 일반 광역전철과는 달리, 이 열차는 장난으로 탈 수가 없다. 이 열차를 타기 위해 별도의 승차권이라도 사야 하는 것도 아니고 완전 무료인데도 왜 그럴까? 교통수단별로 시스템의 차이를 살펴보자.

고속버스 터미널은 심지어 승차권 없이도 아무라도 승강장까지 갔다가 잠시 차내에 들어가서 배웅을 하고 올 수도 있다. 한 차의 승객이 적기 때문에, 승차권 검사는 어차피 출발 직전에 차내에서 이루어진다.
그 반면 철도는 역내에 개집표기가 있어서 마치 고속도로의 톨게이트처럼 paid 영역과 non-paid 영역이 엄격하게 구분되어 있다. 일반 열차역의 경우 비승객이 paid 영역에 잠시 들어갔다 나오려면 입장권을 구매해야 한다. 비승객이 열차 객실 내부까지 들어가는 것을 금지는 하고 있으나 이를 막을 방법은 없다.

이제 국제선 공항은 어떨까? 입장권 같은 건 꿈에도 상상할 수 없다. (면세점 쇼핑 좀 하려고 입장권 구입? ㅋㅋㅋ) paid 영역 안에서도 출발 승객과 도착 승객이 드나들 수 있는 구간은 매우 엄격하게 분리되어 있다. 출발(출국) 승객과 도착(입국) 승객을 엄격하게 분리시켜야 하기 때문에, 스타라인 같은 열차 안에서도 두 부류의 승객이 섞여서는 절대 안 된다.
이런 이유로 인해 한번 여객 터미널에서 확장 탑승동으로 이동한 출국 승객은 다시 터미널로 돌아올 수 없으며 매번 열차는 한쪽 출입문을 열어서 모든 ‘출국’ 승객이 내린 것을 확인한 후에 거길 닫고 반대쪽 출입문을 열어서 ‘입국’ 승객을 받아들인다.

공항에 따라서는 여객 터미널과 탑승동이 일체로 연결되어 있지 못해서 paid 영역으로 들어간 후, 공항 건물에서 비행기까지나 또는 그 반대로는 저상 버스를 또 타고 이동하는 경우도 있다. 하지만 인천 공항은 그런 게 없고 모든 탑승구가 건물로 연결되어 있다. 철도역으로 치면 역사와 승강장이 따로 있는 옛날 역과, 100% 선상역으로 지어지고 있는 요즘 역의 차이 정도 된다고 할 수 있다.

그나저나 항공업계는 어찌 보면 가장 세계화 텃세가 강한 분야임에도 불구하고 대한 항공이 ‘코에어’로 사명을 바꾼다던가, 요즘 전철까지 유행처럼 번지고 있는 ‘승객’ -> ‘고객’ 이런 트렌드는 없는 것 같다.

Posted by 사무엘

2010/01/11 09:34 2010/01/11 09:34
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/62

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

Leave a comment

우주 탐사선들

인류가 만들어 낸 인공물(artifact) 중 현재 지구에서 가장 멀리 떨어져 있는 것은 우주 탐사선 보이저 1호/2호이다. 태양계를 떠나 지구로부터 한없이 멀어지고 있는 탐사선은 파이어니어 10/11호밖에 없는 줄 알았는데, 이것 말고도 더 있다는 걸 알게 됐다.

http://blog.naver.com/bk210850/140001208301
이들은 이미 태양-해왕성 사이 거리의 두 배에 달하는 지점마저 넘어섰다.

파이어니어 10호의 경우 2003년 초에 정말 가냘픈 신호가 감지된 것을 끝으로 교신이 영영 끊겼고, 이제는 수명이 다 해 죽은 것으로 추정된다. 하지만 보이저 탐사선은 지구로부터 100수십 억 km나 떨어져 태양계의 거의 끝자락에 도달했음에도 불구하고 지금도 예상 수명을 훨씬 초과하여 살아 있고 활동 중이라 하니, 정말 놀랍지 않을 수 없다. 물론, 그렇게도 멀리서 오는 탐사선의 미약한 전파를 잡아내려면 정말 넓고 크고 성능 좋은 안테나들을 세계 각지에 설치해 놔야 한다.

  (파이어니어 10호는 2000년 말에도 교신이 한동안 끊겨서 이거 실종이 아닌가 싶었으나 2001년 5월에 다시 신호가 와서 관계자들이 안도한 적이 있었다.)

무려 30여 년 전, 박통 시절에, 인텔에서 이제 막 4비트/8비트 마이크로프로세서를 만들어 내던 시절에 발사된 우주 탐사선이 지구로 각종 행성들의 사진을 보내 왔다는 게 정말 믿기 힘들다. 하다못해 JPG 압축 알고리즘도 없던 시절인데 말이다.
본인의 경우, 처음 봤을 때의 전율과 감격을 아직도 잊을 수 없는 사진이 뭐냐 하면 달 뒷면의 모습, 그리고 달과 지구가 나란히 포즈를 취하고 한 사진에 찍혀 있는 모습이다. 달은 지구에 비해서 얼마나 비정상적으로 기괴하게 큰 위성인지를 한눈에 알 수 있다. 인류가 이런 정보와 지식을 얻기까지 몇 년이 걸렸던가!

1960, 70년대엔 냉전 구도 때문이었는지는 모르겠으나 미국과 러시아가 우주 개발이 한창 전성기였다. 어떤 놈은 금성과 수성의 표면을 관측한 뒤 임무를 마치고 태양을 돌다가 과열되어 최후를 마치기도 했고, 어떤 놈은 금성 대기권에서, 어떤 놈은 금성 표면에서 1시간을 버티다 고열 고압을 견디지 못하고 파괴되기도 했다. 탐사선 이름은 기억 안 나는데, 목성 착륙을 시도하다가 그대로 파괴되어 버리고 연락이 끊긴 놈도 있었다. 목성은 크기만 작을 뿐 내부 성분은 태양 같은 항성과 완전히 똑같다고 하니, 착륙했다간 그 길로 짙은 고압 유독가스에 모든 게 분해되어 버릴지도 모르겠다. Quake 3 Area에 나오는 Fog of Death가 생각난다.

그런 시도가 있은 후 어떤 놈은 그렇게 특정 행성에서 말뚝 박고 최후를 마치는 게 아니라 아예 태양계 밖으로 영원한 질주를 시작한 것이다. 기존 행성의 중력을 이용하여 나름 초속 수십 km로 주행한다 하지만 그래 봤자 한 행성에서 다른 행성까지 가는 데 꼬박 2~3년씩 걸린다. 지구와 전파를 교신하는 데도 수십 분에서 한두 시간은 족히 걸린다. (태양-지구 사이의 거리인 1 천문단위가 전파로는 8분 20초 가량 소요)

그런데 여기서 중요한 것은, 자체 연료도 없는 우주 탐사선이 아무 때에나 그렇게 기존 행성의 중력을 잘 이용하여 태양계 바깥으로 갈 수 있는 게 아니라는 사실이다. 정확한 사항은 기억이 안 나지만, 1970년대 중반이 외행성들이 거의 일렬로 배열되어 백수십 년마다 한 번 찾아올까 말까 하는 절호의 기회였다고 한다. 이것도 어쩌면 영적으로 볼 때 우연은 아닌 것 같다. -_-;;

탐사선의 궤도를 계산하고 탐사선이 그 암흑천지 우주 공간 속에서 일말의 에너지를 받아서 전력을 생산하고 더구나 사진까지 찍고 지구와 교신하는 건 정말 수학과 과학 첨단 기술의 승리라고밖에는 말할 수 없다. 광량이 절대적으로 부족한 곳에서 항성도 아니고 행성 사진을 어떻게 저렇게 찍었을까? (극악의 노출 시간 동안 있는 빛 없는 빛 다 긁어모아서 찍지 않았겠나? -_-) 육안으로는 지구에서 관측할 수 없는 천왕성만 해도 아직까지 우주 탐사선이 보내 준 사진의 질이 별로 좋지 못하며, 그저 희뿌연 구 형상만 파악할 수 있는 실정이다.

컴퓨터의 발전 속도도 놀랍지만
어떻게 인간이 자체 동력으로 하늘을 나는 데 성공하고서 겨우 반세기 남짓만에 민간인 여객기가 전세계를 연결하기 시작하고 인공 위성을 띄웠으며 이내 우주 왕복선과 탐사선이 발사되었을까? 그런데 한편으로는 그로부터 거의 40년이 또 지난 지금은 왜 우주 개발 쪽으로 아무런 진척이 없을까? 신기하기 그지없다.

또한 우주를 아무리 뒤져 봐도 아직까지 태양과 지구 같은 이런 행성-항성 조합은 발견되지 않았고 생명 또한 발견되지 않은 것도 경이롭다. 달은 자전 주기와 공전 주기가 정확하게 일치하여 지구에서는 뒷면이 절대로 보이지 않으며, 지구에서 달의 겉보기 크기가 태양의 겉보기 크기와 일치하는 것도 우연이라고는 도저히 받아들일 수 없는 이상한 점인 것은 틀림없어 보인다.

Posted by 사무엘

2010/01/11 00:45 2010/01/11 00:45
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/60

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

Leave a comment

우리는 C/C++ 언어에서 포인터란, 정수와 비슷한 형태이긴 하나 일반적인 숫자가 아니라 메모리 주소를 가리키는 특수한 자료형이라고 배운다. 포인터는 하드웨어 친화적이고(기계 입장에서 아주 직관적임) 매우 강력한 프로그래밍 요소이지만, 그만큼 길들여지지 않은 야생마처럼 위험 부담이 크다. 포인터 자체하고 포인터가 가리키는 메모리 영역이 따로 놀 가능성이 언제든지 있기 때문에 memory leak, dangling pointer 같은 위험에 노출되기가 매우 쉽다. 자유라는 약이 무질서라는 독으로 변질될 여지가 큰 것이다.

포인터의 값은 다른 지역/전역 변수의 주소로부터 얻어지거나 아니면 메모리 할당 함수를 통해 생성된다. 우리가 직접 상수 값을 대입하는 경우는 거의 없으며, 두 포인터의 값의 차이를 상대적으로 비교하는 경우는 있을지언정, 포인터가 나타내는 그 숫자 자체는 프로그래머에게 사실상 아무 의미가 없다.

사실 이 숫자가 무엇을 의미하는지는 C/C++ 언어의 영역이 아니라 그 언어를 돌리는 플랫폼 내지 운영체제의 영역으로 넘어가게 된다. 포인터란 그만큼 저수준인 존재이며, C++ 이후에 등장한 더 진보한 언어들은 포인터를 더 다루기 편하고 덜 위험한 형태로 어떻게든 감싸고 포장하고 더 상위 계층을 만들려고 애쓰고 있다.

우선 0은 NULL 값으로 유명하며, 윈도우 운영체제의 경우 0뿐만이 아니라 그 이후 0xFFFF 번지까지가 모두 오류로 간주된다. 즉, 이 영역은 운영체제가 어떤 경우에도 메모리를 가리키는 주소로 절대 인정하지 않으며, 오히려 응용 프로그램이 일반 숫자를 포인터로 착각하고 잘못 사용한 것으로 간주하여 무조건 오류를 일으켜 주겠다는 뜻이다. 이런 정책은 사실 프로그래머에게 굉장히 유용하다. 16비트 범위 안에 드는 작은 숫자는 메모리 주소보다는 인덱스 번호 같은 일반 숫자의 의미를 갖는 경우가 훨씬 더 많기 때문이다.

그 후 32비트 윈도우를 기준으로, 64KB부터 2GB까지는 응용 프로그램이 마음대로 사용할 수 있는 “사용자 영역”이다. 이 공간에 나의 EXE, DLL들이 로딩도 되고, 스택/힙 같은 메모리 공간이 할당되고 모든 일이 일어난다. 한 프로세스는 다른 프로세스의 이 영역을 넘볼 수 없다.

단 여기서 잠깐 예외가 있는데, 윈도우 9x는 앞부분의 64KB부터 4MB까지가 또 도스 및 16비트 윈도우 프로그램과의 호환성 유지를 위한 고정된 공용 주소로 예약이 되어 있다. 이런 이유로 인해 윈도우 9x는 4MB에 해당하는 0x400000보다 낮은 메모리 주소에다가는 32비트 바이너리를 불러올 수 없다. EXE/DLL의 preferred base가 이보다 더 낮은 주소인 데다가 재배치 정보까지 들어있지 않다면 그 바이너리는 윈도우 2000/XP 이상에서는 실행 가능하지만, 9x에서는 실행할 수 없게 된다. 비주얼 C++을 보면 EXE의 디폴트 기준 주소가 0x400000으로 잡혀 있는데, 이것은 윈도우 9x와의 호환성을 고려한 귀결이다.

NT급 윈도우는 0x80000000부터 커널이 사용하는 메모리 영역이 시작된다. 쉽게 말해 32비트 포인터로 가리킬 수 있는 4GB의 영역을 응용 프로그램이 2GB, 커널이 2GB로 반반씩 나눠 쓴다는 뜻이다. 물론 여기 부근에도 NT 계열과 9x 계열 윈도우는 메모리를 사용하는 방법이 대동소이한 차이가 존재한다.

NT급 윈도우에는 0x80000000 이전의 64KB 공간을 또 떼어서, 프로그래밍의 편의상 무조건 사용하지 않고 여기에 접근하는 것을 에러로 간주하는 영역을 또 두고 있다. 0~0xFFFF의 용도와 마찬가지이며, 말 그대로 사용자 영역과 커널 영역 사이에 안전을 위해 마련해 놓은 "메모리의 비무장 지대"인 셈이다.

한편 9x 계열은 그런 것은 존재하지 않는다. 대신 0x80000000부터 0xC0000000 사이의 1GB를 “공유 메모리 전용 영역”으로 지정하여, 일부 운영체제 커널 DLL과, 응용 프로그램들이 생성하는 ‘공유 메모리’(memory mapped file)를 이 영역에다 따로 두고 있다. 물론 NT 계열은 그런 것들도 다 구분 없이 사용자 영역에 저장된다. 실제로는 같은 물리 메모리를 가리키더라도 이를 가리키는 포인터의 값은 프로세스마다 다 다를 수 있다는 것이다. 이런 이유로 인해, 공유 메모리를 생성해 보면 9x 계열은 메모리 위치가 0x80000000을 상회하는 높은 주소인 반면, NT 계열은 심지어 자기 EXE가 로딩된 0x400000보다도 낮은 위치에 매핑이 된 경우도 볼 수 있다.

본인 생각에, 이것은 안정성을 약간 희생하여 좀더 작고 빠른 저사양 친화형 OS를 추구한 9x 계열의 고육지책으로 보인다. 사용자 영역에는 진짜로 각 프로세스마다 따로 돌아가야 하는 메모리만 넣고, 조금이라도 프로세스들이 공유할 여지가 있는 메모리는 여기에다가 따로 옮겨 둔 것이다.
이런 구조상의 차이로 인해 윈도우 9x는 NT 계열만치 커다란 메모리 맵 파일 내지 공유 메모리를 생성할 수 없다. 모든 응용 프로그램들이 1GB짜리 공간 안에서 바둥대며 살아야 하기 때문이다. 하지만 NT 계열은 설령 공유 메모리라 할지라도 마치 자기 개인 메모리 다루듯이 얼추 2GB 안에서 자유롭게 그런 것들을 만들어 보호도 잘 받으면서 쓸 수 있다.

나머지 영역은 전부 커널이 사용한다. 프로세스, 스레드 같은 각종 커널 오브젝트를 생성하고 가상 메모리 내지 페이지 파일들을 관리하기 위한 메모리이다. 쉽게 말해 메모리를 관리하기 위한 메모리. 무슨 커널이 최하 1GB에 넉넉잡아 2GB까지씩이나 주소를 차지하고 있어야 하냐 질문할지 모르는데, 결론부터 말하면 그 정도 공간은 반드시 있어야 하며 사실 2GB조차도 부족한 감이 있다.

NT급 운영체제는 커널 영역의 주소가 사용자 응용 프로그램으로부터 완벽하게 보호받고 있으며 user가 커널 영역 메모리로 접근을 시도하면 즉시 에러가 난다. 둘 사이에 앞서 언급한 "비무장 지대"까지 존재한다. 그러나 9x 계열은 그렇지 못하다.

BYTE *pb = (BYTE *)0xC0001000;
int i;
for(i=0; i<4096; i++) {
        printf("%02X ", *pb), *pb=*pb; pb++;
}

이런 간뎅이-_-가 배 밖에 나온 코드를 실행하면 NT급에서는 당연히 즉시 Access violaton 에러가 나고 프로세스가 사살되는 반면,
9x 계열은 놀랍게도 잘 실행된다. *pb=*pb로 해 줬으니 망정이지 다 0으로 덮어쓴다거나 하면 무슨 일이 벌어질까? 9x 계열이 왜 불안정할 수밖에 없는지 답이 딱 나올 것이다.

같은 32비트 안에서 사용자:커널이 2G:2G가 아니라 사용자한테 좀더 메모리를 많이 줘서 더 대용량의 데이터를 처리할 수 있게 한 3G:1G 부팅 방식도 있긴 한다. 사실 9x 계열도 앞서 말한 구조의 차이 때문에 커널 메모리는 1G이다.
하지만 이 경우 운영체제가 관리할 수 있는 가상 메모리의 이론적 최대치가 크게 감소하고 생성 가능한 커널 오브젝트(프로세스, 스레드, 공유 메모리 등)의 수도 더 줄어든다는 것을 알아야 한다. 또한 응용 프로그램도 large-address-aware하게 빌드되었다는 별도의 플래그가 있어야 한다.

Posted by 사무엘

2010/01/11 00:43 2010/01/11 00:43
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/59

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

Leave a comment
« Previous : 1 : ... 144 : 145 : 146 : 147 : 148 : 149 : 150 : 151 : 152 : ... 154 : Next »

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2019/08   »
        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:
1236184
Today:
497
Yesterday:
554