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

비주얼 스튜디오로 C# 프로젝트를 하나 만든 후, 마법사가 생성해 준 기본 폼 애플리케이션을 debug와 release로 제각기 모두 빌드하여 실행해 본다.
그 후 이 프로젝트 디렉터리의 크기를 측정해 보라. 본인은 200KB가 채 나오지 않았다.

그런데 C/C++ 프로젝트를 만들고(MFC는 쓰지도 않고), 그냥 간단한 창만 하나 띄우는 Win32 프로그램을 debug와 release로 모두 빌드해서 실행한 후 디렉터리 크기를 재 보라.
프로젝트가 차지하는 용량은 무려 20MB가 넘는다. (비주얼 스튜디오 2008 기준)

그렇다. C/C++은 프로젝트를 만들고 빌드를 좀 하면, 잡다하게 생기는 중간(intermediate) 파일이 엄청 많다. 게다가 용량도 상당히 많이 잡아먹는다.

<날개셋> 한글 입력기 프로젝트도 32비트 디버그/릴리스, 그리고 64비트까지 빌드하다 보니 디렉터리 전체 크기가 무려 800MB에 달해 있다. 하지만 그 중 실제로 빌드에 쓰이는 소스나 데이터 파일의 합은 20~30MB대는 절대 안 넘을 것이다. -_-;;

OBJ 파일이 생기는 것이야 C/C++ 자체가 링크를 염두에 두고 만들어진 언어이니 어쩔 수 없고 그건 어차피 그렇게 크지도 않다. ..... 라고 말하려고 했는데, 오브젝트 파일도 각종 디버깅 내지 고급 최적화와 관련된 메타정보가 첨가되다 보면 단순히 소스 코드의 기계어 번역이라고 볼 수 없을 정도로 덩치가 은근히 커지긴 한다.

OBJ 말고도 디스크 용량을 상당히 차지하는 주범은 잘 알다시피 pre-compiled header이다(*.PCH) 겨우 몇몇 개의 헤더 정도나 인클루드하면 되는 정올 답안 수준의 프로그램이 아니라 특정 운영체제/플랫폼이나 거대한 라이브러리의 프로그래밍 요소를 다 인클루드하는 프로그램이라면, 그렇게 고정불변이고 덩치가 많은 요소들은 미리 컴파일을 좀 시켜 놔야지 프로그램의 빌드 시간을 줄일 수 있다.

본인이 비주얼 C++을 처음으로 쓴 게 4.2 시절부터이다. 그때엔 MFC 심볼들을 다 빌드해 놓은 pch 파일도 이미 3~5MB 정도 했던 것 같다. 하지만 지금은 그것보다 덩치가 훨씬 더 커져 있고 한 빌드 configuration당 10MB는 훌쩍 넘어간다. 프로젝트 하나 만들 때마다 50~100MB씩은 잡아야 한다. 오로지 C/C++ 언어 프로젝트만이 이런 삽질이 필요하다.

윈도우 SDK나 MFC처럼 매 프로젝트마다 일일이 빌드가 필요하지 않은 것들은 공용 PCH라는 개념으로 공유만 좀 하게 해 놔도 이런 파일의 크기를 상당 부분 줄일 수 있을 텐데 너무 낭비라는 생각이 든다. 하지만 요즘은 하드디스크 용량이 워낙 많다 보니, 빌드 시간을 네트워큭 분산 기술을 줄이려는 연구는 해도 PCH 파일 크기를 줄이려는 연구는 거의 행해지지 않는 것 같다.

이외에도 인텔리센스 데이터베이스인 NCB 파일도 은근히 크고, 매 빌드 때마다 생기는 심볼 디버그 데이터베이스인 PDB 파일도 무시 못 한다.
왜 이런 일이 생기는 것일까? 대략 다음과 같은 관점에서 살펴볼 수 있다.

첫째, C/C++은 굉장히 작은 언어이고, 프로그래밍에 필요한 요소들을 전적으로 소스와 동일한 텍스트 포맷인 헤더 파일의 파싱(느림!!)에 의존하여 읽어들이는 형태이기 때문이다. 라이브러리 링크는 별도의 계층으로 따로 존재하지, 즉시 읽어들일 수 있는 바이너리 유닛/패키지라든가(파스칼, 자바, C# 등) 언어가 자체 내장하고 있는 요소가 없다. 원천적으로 이식성을 택했지, 속도를 배려하지는 않은 느린 프로세스를 사용하는 셈이다.

둘째, C/C++은 전처리기라든가 링크 과정으로 인해 빌드가 더욱 느리고, 언어의 해석이 더디기 때문이다. 모든 토큰은 그냥 토큰이 아니라 전처리기를 재귀적으로 거치면서 다 까 봐야 실체가 드러난다. ^^;;; 헤더 파일의 글자 하나를 고치면 이 여파가 수백, 수천 개의 소스 파일에 동시에 파급되고 프로그램의 의미가 전혀 다르게 바뀔 수 있다. 이것은 장점도 있지만 똑똑한 개발 환경이나 빠른 빌드 환경을 만드는 데는 불리한 구조이다.
그러니, 소스 코드를 조금이라도 빨리 분석하기 위해서는 소스코드 자체뿐만 아니라 온갖 메타정보들을 ‘별도의 파일’로 보관할 수밖에 없다. NCB처럼 말이다.

셋째, C/C++은 그 어느 에뮬레이터나 가상 기계 계층이 없이, CPU 차원에서 기계가 직통으로 알아듣는 프로그램을 만들 수 있다. 잘 최적화된 프로그램은 사람이 원래 짠 소스 코드와는 전혀 다른 형태가 될 수도 있다. 그러니 이런 코드의 디버깅은 어려울 수밖에 없다. 변수의 내용을 확인하거나 한 줄씩 실행하는 것까지는 못 하더라도 프로그램이 뻗었을 때 스택 덤프라도 보려면 빌드된 프로그램과 소스 코드 사이의 관계를 설명하는 최소한의 정보라도 있어야 한다. 소스 코드와 형태가 전혀 딴판인 코드를 생성하는 컴파일러일수록 그런 정보는 더욱 세부적이고 양이 많아질 수밖에 없다.

한 마디로 C/C++이 정말 강력하고 포괄적이고 대인배 같은 언어이다 보니 주변에 붙는 군더더기도 많은 모양이다. ^^ 코드 생성이 여러 단계를 거치면서 매우 번거롭고 어려운 대신, 한번 만들어 진 코드는 그 어느 언어보다도 강력하다.

Posted by 사무엘

1905년, 경부선이 개통한 당시부터 영업을 시작한 수원 역은 가히 경기도 남부의 교통 허브 역할을 맡고 있다. 지금은 새마을호 이하 모든 열차가 정차하며 백화점이 인근에 있는 민자 역사이다. 구로와 수원은 애경 백화점(AK 플라자)이, 영등포, 안양, 청량리는 롯데 백화점이 접수하고 있다는 점이 흥미롭다. 덧붙이자면 서울 역은 갤러리아 백화점이다.

수원 역은 한때는 수인선과 수려선이 만나서 수직인 경부선뿐만 아니라 수평의 철도까지 교차하는 지점으로, 즉 경부 고속도로로 치면 신갈 분기점 같은 환승역이기도 했다. 비록 지금은 그 철도는 없어졌지만 걱정 마시라. 분당선이 다시 수원으로 연장되는 중이고, 수인선은 복선 전철로 재건될 예정이기 때문에 옛날의 영광은 다시 찾아올 것이다.

수원은 대전과 마찬가지로 경부선 덕분에 급성장한 도시이다. 비록 인천만치 터져 나가지는 않지만 인구도 100만 명을 돌파하고 광역시급 덩치가 됐다. 단순 철도뿐만 아니라 1974년에 수도권 전철이 개통한 것이 크게 기여했다.

그런데 한 선로 위의 동일한 역에서 과금 체계가 다른 두 종류의 열차를 취급하려면 어떻게 하면 좋을까?
아예 선로별 복복선인 서울 시내 구간은 별로 걱정할 필요가 없다. 영등포, 용산, 서울, 청량리 같은 역은 여기에 속한다.

(이하 모든 그림에서 파란 선은 일반열차를, 빨간 선은 전동차를 의미함)

하지만 방향별 복복선 구간에서 열차를 정차 내지 대피시킬 공간마저 충분하지 않은 역은 일반열차 승객과 전철 승객을 분리시키기 위해 머리를 좀 써야 한다. 지금의 수원과 평택 같은 역을 생각해 보면 된다. 수원 같은 경우, 전철 승객은 지하도를 통해 지하로 나가고, 일반열차 승객은 계단을 통해 윗층으로 나가고 있다. 광명 역은 이런 시설이 없기 때문에, 셔틀 전동차 이용객은 개집표기를 통과하지 않고 반대편 승강장으로 갈 수없다.

이에 덧붙여, 드물지만 바로 역의 앞뒤로 전철 승강장과 일반열차 승강장을 분리하는 경우도 있다. 좌우 공간이 충분하지 못한 역이 쓰는 방식인데 경부선 안양과 중앙선 덕소 역이 이에 속한다.

그럼, 전철 개통 당시 수원 역의 배선은 어땠을까?
결론부터 말하자면 매우 열악했다. 사실 1호선의 또 다른 종점인 인천 역도 아직까지 인상 선로조차 없는 열악한 역이긴 마찬가지이다.
수원에서 운행을 마친 전동차는, 부산까지 가는 경부선 일반열차보다 먼저 방향을 바꾸고 반대편 방향으로 ‘회차’를 해야 한다. 그렇기 때문에 수원 역은 중앙에 전동차 승강장이 섬식으로 있고 양 끝에 일반열차 승강장이 존재하는 형태였다. 위의 그림에서 아래쪽이 부산 방면이요, 위쪽은 서울 방면이다.

그림을 보노라면, 당시 수원 역의 배선 구조는 문제가 많았음을 한눈에 알 수 있다.
전동차를 증차하기 위해 경부선 수원 이북 구간은 이미 1980년대 초에 2복선으로 확장되었다. 그래서 전동차는 새로 생긴 외선으로, 일반열차는 기존 내선으로 방향별 복복선으로 다니기 시작했다.
그런데 수원 역에서는 전동차가 회차를 해야 하기 때문에 일반열차--정확하게 말하면 수원에서 정차하는 열차--가 외선으로, 그리고 전동차가 내선으로 자리를 바꿨다. 철도에서 만악의 근원인 평면교차가 발생한다는 뜻이다.

게다가 이것 말고도 진정한 재앙은 따로 있었다. 그렇게 내선과 외선을 바꿔치기한 후에, 수원 역의 전동차 승강장의 선로는 그럼 전동차만의 전용 공간이기라도 했냐 하면 그것도 아니었다는 점이다. 외선은 일반열차 중에서 수원 역에 정차하는 열차만이 이용했고 무정차 통과하는 열차는 여전히 그대로 내선을 통과했다. 전동차 승강장을 스쳐 지나가면서 말이다. 그렇다. 그 선로는 경부 본선이었다. 흠좀무.

이 때문에 전동차는 화서에서 수원으로 진입하기 전에(X자형 교차 지점) 늘 일반열차 눈치를 봐야 했고, 심지어 회차선에서 전동차 승강장으로 진입할 때도 일반열차 눈치를 봐야 했다. 마음 편하게 지낼 수가 없었던 것이다. 경부선 선로를 2복선으로 확장한 뒤에도 이것 때문에 전동차를 도무지 충분히 증차할 수 없었다.

이때 가장 위협적인 존재는 새마을호였다. 이때 새마을호는 오늘날의 KTX의 위상을 능가하는 호화 귀족 열차였고, 모 사이트의 표현을 빌리자면 “서울 대전 대구 부산 찍고~” 트로트 가사에 정확하게 맞춰 신나게 질주하던 괴물이었다. 수원 역 플랫폼쯤은 최고 시속 140km로 통과해 버렸다. 전철을 타는 승강장이니 완전히 막아 버릴 수도 없고.. “전동차 승강장으로 열차가 통과할 예정이오니 부디 물러서 주시기 바랍니다” 경부선 수도권 전철 구간이 여전히 복선이던 1970년대에나 들을 수 있을 법한 희귀한 경고 방송이 세 번째 반복되는 순간, 쌩....! 했다.

수원 역에서는 전동차 기관사의 고충도 더 컸다. 수원에서 하행 전동차가 운행을 마치면 회차선에 들어갔다가 나와서 상행 방면 선로로 진입한 뒤부터 승객이 타야 되는데, 수원에서 상행을 이용하는 승객들은 차에 빨리 타서 앉아 가겠다는 심보로, 이제 종착해서 회차선으로 들어갈 예정인 전동차에도 무자비하게 타 댔다(섬식인 덕분에 상하행 승객이 동일 플랫폼 사용!). 용산에서 종착한 급행 전동차도 지금까지 비슷한 이유로 인해 골치를 썩고 있음은 주지의 사실이다.

회차선에 들어가 있는 동안 직원이 차량을 청소도 하고 특히 기관사와 차장은 200m에 가까운(10량 편성 기준) 거리를 걸어 반대쪽으로 위치 교대도 해야 한다. 그런데 통행이 어려울 정도로 승객이 많이 타 버리면 이들은 부득이 차 밖으로 내려서 옆 선로로 걸어가야 했다. 바로 경부 본선으로 말이다! 그런데 거기로 새마을호가 통과해 버리면? 이건 그야말로 기관사를 죽음으로 내모는 짓이나 다름없었다.

이렇듯, 수원 역은 위상에 걸맞지 않게 열악한 회차 구조 때문에 문제가 많았고 실제로 2002년엔가 03년에는 선로 작업 차량이 대기 중이던 지하철 전동차를 추돌하는 사고가 나기도 했다. 하지만 다행히 이 모든 일들은 이제 옛날의 추억이 되어 있다. 회차 시설은 입체 교차 시설이 잘 갖춰진 병점 역으로 옮겨지고 이제 수원 역은 종착역이 아닌 단순 통과역으로 바뀌었기 때문이다.

2005년에 수도권 전철이 천안까지 연장 개통하기에 앞서, 2년 전에 중간 지점인 평택도 아니고 병점까지만 서둘러 연장 개통한 것은 그만큼 수원 역의 평면교차 문제 해소가 시급했기 때문이라고 풀이할 수 있다.

Posted by 사무엘

Posted by 사무엘

http://xkcd.com/681/
천문 과학에 대한 통찰력과 위트가 두루 엿보이는 정말 탁월한 그림.
지구를 탈출하여 달로 갈 때는 집채만 한 로켓과 어마어마한 양의 연료가 필요하지만, 달에서 지구로 귀환할 때는 아주 작은 비행체만 있어도 되는 이유가 이 그림 한 장으로 명쾌히 설명된다.

지구의 중력을 벗어나기란 그렇게도 어렵고 비용이 많이 든다.
그래서 로켓 부품의 재활용성을 최대화하기 위해 우주 왕복선이란 게 발명되었지만, 요즘 발사되는 우주 왕복선들은 그냥 지구 궤도만 돌다가 돌아온다.

학교에서 배우기를 지구의 탈출 속도는 초속 11.2km라고 한다. 이것은, 지표면에서 공을 초속 11.2km로 던져야만 그 공이 다시는 지구로 떨어지지 않는다는 뜻일 뿐, 공이 자체적으로 추력을 낼 수만 있다면 당연히 그보다 느려도 된다. 이렇게 지구를 탈출했더라도 태양을 탈출할 정도로 빠른 속도를 내지 못한다면 지구를 탈출한 물체는 궁극적으로는 태양을 빙글빙글 돌게 된다.

초속 11.2km만 해도 지표면에서는 상상하기도 어려울 정도로 빠른 속도이며, 인간이 발명한 동력 기관만으로는 만들기가 거의 불가능하다. 그렇기 때문에 우주 탐사선들은 인근 행성의 중력을 통해서 가속을 받는 방법으로 연료 없이 장시간 비행을 계속한다. 참고로, 보이저 내지 파이어니어 호처럼 태양계 밖으로 끊임없이 진행하고 있는 우주 탐사선들은 주행 속도가 초속 15~20km에 달하고 있다. 그 속도로도 목성형 행성들을 하나씩 통과하는 데 2~3년씩 걸리곤 했다.

지구상의 한 지점에서 다른 지점으로 이동하는 게 목적인 일반 비행기와는 달리, 로켓은 오로지 위로 뜨는 것만이 목적이므로 비행기처럼 이착륙 따위는 당연히 존재하지 않는다. 항공기에는 내연 기관이 아니라 터보 프롭, 터보 팬, 램 제트 등 여러 가지 방식을 통해 공기로부터 추진력을 얻는 엔진이 존재하나, 지구의 중력을 탈출하여 공기가 없는 곳에서도 날기 위해서는 현실적으로 로켓 방식이 유일하다. 과거에 로켓은 미사일 같은 무기로나 쓰여 왔으나 이 추진력을 지구를 탈출하는 데 써 보자는 생각을 체계적인 학문으로 처음 정립한 사람이 바로 20세기 초의 독일과 소련의 천재 과학자들이었다.

우주 왕복선은 일반적인 항공 역학을 이용하여 나는 게 아니기 때문에 전투기나 여객기 같은 날개가 존재하지 않는다. 그렇지만 과거 SF 소설의 삽화에는 우주를 나는 비행기(?)에도 아주 폼나는 날개를 그려 놓곤 해 왔다.

끝으로 사진 추가.

http://ko.wikipedia.org/wiki/%ED%8C%8C%EC%9D%BC:Speed_of_light_from_Earth_to_Moon.gif
http://ko.wikipedia.org/wiki/%ED%8C%8C%EC%9D%BC:Mars_Moons_Orbit_distance_flipped.jpeg

화성의 위성과 지구의 달이 얼마나 극과 극인지를 단적으로 보여주는 사진이다.
일단 화성 자체가 반지름이 지구의 거의 절반에 불과할 정도로 작은 행성인데, 그 작은 화성을 저렇게 확대하고도 화성의 위성은 먼지 정도로밖에 보이지 않는다.

사실, 화성의 두 위성은 구 모양을 이루지도 못할 정도로, 위성이라고 부르기도 민망한 작은 돌덩어리일 뿐이다. (지름 10~20km대) 공전 주기도 대단히 짧고 화성으로부터 불과 1~2만 km대밖에 떨어져 있지 않다. 참고로 지구의 정지 궤도가 3만 5천 km대이고, 포보스의 궤도는 지구로 치면 중궤도 정도 수준밖에 안 된다.

그 반면 달은? 크기가 그 큰 지구의 무려 1/4에 달하며(지름 약 3500km), 지구와도 무려 38만 km나 떨어져 있고 아주 서서히 지구로부터 멀어지고 있다. 지구 크기를 저렇게 줄여 놓아도 달도 선명하게 보이는 게 신기하지 않은지? 달은 정말 지구에게 어울리지 않는 인위적이고 비정상적으로 큰 위성임이 틀림없다.

Posted by 사무엘

거의 20년 전의 윈도우 3.0 이래로 한글판 운영체제가 내장해 온 한글 글꼴은 바탕, 돋움, 굴림, 궁서의 4종류였다. 그리고 한자 글꼴은 바탕, 돋움에만 존재하여 2종류였다. 지극히 교과서적인 기본 글꼴에만 한자 글립이 있었다는 뜻.
그때는 fallback 글꼴이라는 개념조차 없었기 때문에 궁서나 굴림 같은 글꼴을 쓰면 한자가 아예 나타나지도 않았었다.

그러던 것이 윈도우 95에서부터는 상황이 크게 개선되어 궁서의 한자는 바탕으로, 굴림의 한자는 돋움으로 좀더 유사한 글꼴의 한자 글립을 공유하게 되었다. 이것은 별도의 fallback 글꼴을 지정한 게 아니라, 아예 한 글꼴 파일이 collection으로 바탕과 궁서를 나타내고 있고 한자 글립을 내부적으로 바탕의 것으로 공유하기 때문에 가능해진 것이다.

윈도우 비스타에서 새롭게 추가된 글꼴인 ‘맑은 고딕’도 한자 글립을 갖고 있지 않다. 한자를 찍으려고 하면 돋움체의 글립이 자동으로 쓰이는데 이것은 fallback 글꼴이 쓰인 게 맞다.

한자 자체도 윈도우 95 시절까지는 고작 KS 완성형 코드에 있는 상용 한자 4888자밖에 없었다. 그러던 것이 98부터는 확장 한자 2856자가 추가되었고, XP 무렵에는 유니코드의 ‘한중일 통합 한자’ 영역의 한자가 모두 기본 제공되기 시작했다. 그리고 비스타부터는 ‘한중일 통합 한자 확장 A’까지 굴림/돋움 같은 글꼴에서 기본 제공되기 시작했고, 심지어 surrogate 영역에 존재하는 확장 B도 외국에서 제작된 별도의 글꼴을 자동으로 fallback 하여 표현할 수도 있게 되었다.

이렇게 PC 환경이 좋아지면서 컴퓨터에서 문자를 표현하는 능력이 비약적으로 향상돼 왔는데 본인이 늘 아쉽게 생각하는 게 있다. 기본 제공되는 한자 서체 자체는 20년 전이나 지금이나 바탕과 돋움 두 종류뿐이라는 점이다. 이제는 굴림과 궁서도 고유한 한자 글립을 제공할 때도 되지 않았나 싶다.

21세기가 된 지 무려 10년 가까이 지나고 온갖 기발하고 현란한 한글/영문 글꼴이 넘쳐나는 지금도, 한국에서 소위 명조와 고딕 계열 이외의 한자 글꼴을 찾기란 의외로 매우 어렵다! 사실은 신명조와 중고딕 말고 견명조, 견고딕조차도 드문 실정이다.
어지간한 운영체제나 워드 프로세서가 번들로 제공하는 글꼴에서는 거의 찾을 수 없고 최소한 별도의 글꼴 확장팩에서나 제공된다. 이런 의미에서 과거 아래아한글 2.5 확장팩은 정말 신선한 충격이었다. ‘신명 궁서’는 아래아한글이 최초로 제공한 궁서 계열 한자 글꼴이었다.

그나마 견명조, 견고딕, 궁서는 좀 사정이 나아졌다. 아래아한글이 번들로 제공하는 HY견명조, HY견고딕에도 한자 글립이 같이 들어있다. 하지만 굴림 계열의 한자 글꼴은 정말 없다. 무려 아래아한글 3.0대 내지 96의 확장팩부터 제공된 한글맵시 글꼴에서 그런 한자 글꼴을 본 기억이 나고 HFT가 아닌 범용적인 TTF 방식은 아직까지 구경조차 못 해 봤다.

둥근고딕, 세나루, 디나루 등의 명칭으로 불리는 이 굴림 계열 글꼴은 원래는 그래픽이나 헤드라인처럼 일반 PC에서 보기가 쉽지 않은 글꼴이었으며, 아래아한글도 2.5 확장팩에서부터나 제공하기 시작했다. 그런데 윈도우 95가 이 글꼴을 확 퍼뜨려 준 덕분에 굴림은 그때부터 그야말로 길바닥에 차이는 돌멩이마냥 오늘날 우리나라에서 웹과 인쇄물 등에서 제일 흔하게 쓰이는 글꼴이 되었다. ^^

워낙 흔하다 보니 굴림 말고 별도의 굴림 계열 글꼴은 거의 나오거나 쓰이지 않았다. 그런데 그 흔한 기본 글꼴에 한자 글립이 없었고, 따라서 한자 글립이 추가된 다른 둥근고딕 글꼴도 거의 볼 수 없게 된 게 아닌가 한다.

사실 굴림체 계열의 한자 글꼴이 가장 널리 쓰이고 있는 곳은 일본이다. 둥근고딕 한자로 쓰인 문장만 봐도 일본이 바로 떠오를 정도이다. 한국에서 이런 글꼴을 볼 일이 없기 때문이다.
그리고 뭔가 소프트웨어를 동아시아 환경에 맞게 localize할 때 기준으로 삼는 언어 역시 단연 일본어이다. 국력도 국력이거니와, 워낙 일본의 문자 체계와 문자 입력법이 복잡하기 때문에 일단 일본을 기준으로만 프로그램을 고쳐 놓으면 한국이나 중국어 버전은 약간만 추가 조치를 취하면 되기 때문이다.

굴림체를 비판하는 사람들은 굴림체가 한글답지 못하고 일본 한자 서체의 스타일을 그대로 베꼈다고 주장한다. 사실, 한글 윈도우 95가 돋움이 아닌 굴림을 기본 글꼴로 내세우고 나온 것도, 굴림 계열 글꼴을 즐겨 쓰는 일본 쪽 문화를 참고했던 게 아닐까 하는 생각이 들기도 한다. 실제로 각종 컴퓨터 용어를 제정하거나 심지어 한글 코드과 글꼴 같은 걸 정할 때도 우리나라 엔지니어들은 일본은 localize를 어떻게 했는지를 엄청 많이 참고해 온 것도 어쩔 수 없는 현실이다.

그런데 그렇게 굴림체를 도입해 놓고도 정작 둥근고딕 스타일의 한자 글립은 아직까지도 없다는 게 아쉽다. 예전이야 메모리 용량이 아깝고 하드디스크 용량이 아까워서 뺐다 치지만 지금은 전혀 그런 걱정이 없고 평생 쓸 일 없을 것 같은 유니코드 상의 온갖 외국어 문자도 다 글꼴이 내장되어 있다. 현실적으로 한글과 로마자 다음으로 가장 많이 쓰이는 문자인 한자를, 많이도 필요 없고 상용 한자 4888자만이라도 바탕과 돋움이라는 단조로움을 벗어나게끔 운영체제가 배려를 해 주면 어떨까 하는 생각이 든다.

Posted by 사무엘

Posted by 사무엘

서울과 부산을 잇는 철도 노선으로 경부선(경부 고속선 포함)만을 떠올리기 쉬우나, 사실은 중앙선과 동해남부선도 그 역할을 하고 있다. 서울에 청량리 역이 있다면 부산에는 부전 역이 그 역할을 한다. 경부선 이외의 다른 마이너 노선을 주로 취급한다는 공통점이 있기 때문이다.

경부선은 선형도 좋을 뿐만 아니라 우리나라의 주요 대도시를 경유하는 매우 중요한 노선으로 일제 강점기 때부터 일찌감치 복선화가 되었고, 1970년대에 이미 우리나라에서 최초로 수도권 광역전철이 개통하기도 했다. 물론 서울과 부산을 직선으로만 잇는다면 용인, 상주를 경유하여 지금의 중부내륙 고속도로와 비슷한 노선이 거리가 더 짧으나, 험준한 지형을 피하기 위해 대전과 수원을 경유하는 노선이 결정된 것이다. (사실, 경부선 덕분에 가장 극적으로 급발전한 도시는 단연 대전이라 할 수 있다.)

그러나 이런 경부선과는 달리 중앙선은 경부선과 비슷한 위상의 장거리 간선임에도 불구하고, 시간이 정지해 있다는 표현이 어울릴 정도로 낙후해 있다. 건설부터가 경부선보다 35년 가까이 늦었고, 경부선은 이미 복선화 작업이 한창이던 시절이었다. 그리고 물자가 열악하던 2차 세계 대전에 그것도 경부선보다 훨씬 더 험준한 오지를 경유하여, 애초에 여객보다 화물에 더 비중을 두고 졸속으로 만든 노선이니 경부선보다 질이 떨어질 수밖에 없었다. 경부선은 지금은 시속 140까지 달리는 구간도 있는 반면, 중앙선은 여전히 6~70대에 머물러 있다.

중앙선은 광역전철 개통도 덩달아 경부선보다 시기적으로 30년이 늦다. 복선 선로+대피선으로 전동차와 일반열차가 다니는 지금의 중앙선은 정확하게 1970년대 경부선의 모습이다. 경부선은 시도 때도 없이 서울-부산 열차가 드나들고 고속철까지 건설된 반면, 중앙선은 전구간을 다니는 열차조차 거의 없을 정도로 한산하며, 아직 전구간이 복선이나 전철화되지도 않아 있다. 청량리-부전 전역 정차 통일호가 2004년 KTX 개통에 맞춰서 폐지된 뒤에는 중앙선을 전구간 직통 운행하는 열차는 하루 단 한 번, 밤차밖에 없었다. (2008년부터는 낮에도 한 차례 전구간 직통 열차가 생기긴 했지만) 중부내륙과 중앙 고속도로가 개통하면서 중앙선은 더욱 몰락의 길을 가고 있다.

이 글에서는 경부선과 중앙선의 차이와 더불어, 그 중앙선 밤차의 추억에 대해 다루고자 한다.
2003년 말, 서울에서 볼일을 본 후 새마을호를 타고 경주에 가려고 했는데 그 열차를 놓치고 못 타는 바람에 대신 우연히 발견하여 타게 된 열차가 바로 중앙선 밤차였다. 세상에 이런 열차가 있나 싶었다. 그 당시는 서울-경주가 무려 6시간 반이나 걸렸다. 비록 느리지만 수원, 천안, 구미, 대구처럼 늘 식상한 역명이 아니라 원주, 제천, 안동 같은 색다른 지역을 지나면서 철도 여행의 운치를 더욱 북돋워 주었다.

그 후 본인은 이 열차를 상행과 하행 할 것 없이 기회가 될 때마다 애용했다. 경부선 열차를 이용할 수 없는 시간대에 존재하는 매우 훌륭한 우회 경로였기 때문이다. 고속철이 개통한 이래로 열차 시각표가 무수히 많이 개정되었지만 중앙선 밤차만은 없어지지 않고 6년 전이나 지금이나 청량리 21:00 하행, 그리고 경주 0:06 상행은 바뀌지 않았다. 경주-서울 6시간 36분이던 소요 시간이 2005년 하반기에는 이 5시간 40분대로 좁혀지기도 했는데, 다이아가 비현실적이었는지 지금은 다시 6시간 10분 정도로 조정되어 있다.

서울 역을 출발하여 대구 역에서 대구선-동해남부선으로 빠지는 열차가 새마을호 중에는 여럿 있다. 하지만 무궁화호 중에도 밤 10시~10시 반 시간대에 서울을 출발하여 부전으로 가는 차가 하루 단 한 번 있다. 그래서 경주 역에 새벽에 도착하는 열차는 중앙선 밤차와 더불어 이 열차까지 합해 총 2회가 존재한다. 이 구도도 2003년 이래로 지금까지 전혀 바뀌지 않고 전해 내려오고 있다.

사실 밤차라는 것은 엄청 장거리 내지 소요 시간이 긴 노선에 적합한 것이고 요즘은 없어지는 추세이다. 선로의 관리 측면에서 볼편하기 때문이다. 침대차만 해도 오래 전에 사라지지 않았던가. 밤에 청량리 역을 출발하여 다음 날 아침에 강릉에 도착하는 그런 노선에나 어울린다. 하지만 중앙선은 앞으로 획기적으로 열차 주행 속도가 빨라지지 않는 한, 이런 특별한 환경에 따른 수요를 충당하는 밤차가 당분간은 사라질 것 같지 않다. KTX의 영향을 전혀 받지 않는 간선 노선! 그래서 본인 역시 이 열차에 애착을 갖고 앞으로도 더욱 자주 이용하고자 한다.

기타 잡설

1. 심야에는 중앙· 태백· 영동선과는 달리 경부선과 호남선은 전차선을 가동하지 않는다. 이런 이유로 인해 경부선 쪽 밤차는 언제나 디젤 기관차가 다닌다.

2. 고속철 개통 전에는 주말에만 운행하던 경주-대전 경유-광주 무궁화호가 있었다. 대전-서대전 구간을 지나가는 아주 독특한 열차였다. 본인은 고향이 경주이고 그 당시 학교는 대전이었다. 그러니 일요일 17:20에 경주를 출발하여 20:30쯤에 대전에 도착하던 이 열차는 학교로 돌아갈 때 이보다 더 적격일 수 없던 열차였다.
경주에 사는 덕분에 청량리 밤차를 비롯해 여러 독특한 열차를 이용할 기회가 있었다.

3. 경부선은 서울-대전 평지, 대전-대구 산악, 대구-부산 강과 들판이라는 세 가지 양상으로 나뉜다.
중앙선도 대략 그런 구도가 있다. 어디까지는 들판, 어디까지는 산, 안동 이남부터는 평지.. 여기에 대한 연구도 좀 해야 하는데, 맨날 밤차만 타니까 그렇게도 절경이라는 중앙선 바깥 경치를 잘 구경할 수가 없다.

Posted by 사무엘

1.
자바는 잘 알다시피 파일 하나와 클래스 하나가 완전히 일대일 대응하며, 파일 이름이 클래스 이름과 일치까지 해야 한다(여러 클래스를 선언하더라도 한 클래스의 내부에서 선언해야 함). 자바는 여러 소스 코드를 한데 모아서, 다시 말해 링크해서 exe를 만든다는 개념이 없고 그냥 소스 코드가 그대로 바이트 코드로 컴파일된 클래스 파일이 되고 거기에 있는 static void Main 함수를 실행하는 구조이다. 그런 만큼 아예 그런 형태를 언어 차원에서 강제함으로써 관리 면에서 얻는 편의도 분명 있을 것이다.

그런데 C#은 그렇지는 않다. C++과 마찬가지로, 파일과 클래스가 일대일 대응하지 않아도 된다. 한 파일에 여러 클래스가 담길 수도 있고, partial 예약어를 쓰면 반대로 한 클래스가 여러 파일에 나눠 담길 수도 있다!
(MSDN에 설명돼 있는 것처럼, 여러 사람이 한 클래스에 대해 공동 작업을 할 때나 클래스의 일부분이 다른 출처로부터 자동으로 생성된다거나 할 때 무척 유용하겠다.)

게다가 C#은 비록 닷넷 전용이긴 해도 여러 소스로부터 한 exe를 만들 수 있는 언어이다. 그렇다 보니 자바에서는 걱정할 필요가 없던 문제가 하나 생기는 게 있는데, 바로 여러 클래스들이 자기만의 static void Main 함수를 정의할 수 있다는 점이다. 이 경우 컴파일러는 에러를 발생시키며, Main 함수를 하나만 남기든가, 어느 클래스의 Main 함수를 실행시킬 지 별도의 옵션으로 지정해 달라는 메시지를 남긴다.

Main 함수가 없거나 둘 이상 존재한다는 에러는 링크 에러가 아니고 런타임 에러는 더욱 아니며, 컴파일 에러라는 게 흥미롭다. C#도 자바와 마찬가지로 링크라는 개념은 없다.

2.
C#에는 C/C++과 마찬가지로 const라는 예약어도 있고 이에 덧붙여 readonly라는 예약어도 있다. const는 컴파일 시점에서 값이 완전히 고정되어 있는 primitive 타입의 상수나 문자열만 지정할 수 있다. 그리고 C++과는 달리 const와 static을 동시에 지정할 수 없다. 어떤 멤버가 const이기만 하면 static은 당연히 자동으로 지정되기 때문이다.

그 반면 readonly는 const보다 더 동적인 값을 선언할 때나 생성자 함수에 한 번 정한 후에 그 뒤부터 고칠 수 없도록 지정할 수 있어 편리하다. primitive 타입이 아니라 new로 할당하는 개체/배열이라든가, 상수이긴 한데 값이 실행 시점에서 가변적으로 정해질 수 있는 값--함수 실행 결과처럼--이라면 readonly로 지정하면 된다.

C++은 이 둘의 경계가 모호했다. 굳이 구분하자면 일반 const 멤버는 생성자 함수에서 동적인 값으로 초기화가 가능했던 반면, static const는 컴파일 때 정적인 값으로만 초기화가 가능했다.
C#은 배열은 자바와 마찬가지로 무조건 new로 할당하기 때문에, 값이 전혀 동적이지 않는 상수 테이블 같은 것도 배열이라면 const가 아닌 readonly로 할당해야 한다.

한편, 자바는 이 점에서 C#과는 다른 재미있는 차이를 보인다. 내 기억이 맞다면 const가 없고 아마 final이 const 역할도 하며, 오버라이드 가능하지 않은 고정 함수임을 나타낼 때도 쓰이는 예약어이다. 즉, C++과 C#은 virtual이라고 별도로 지정한 함수만 가상 함수인 반면, 자바는 별도로 지정하지 않은 모든 함수가 기본적으로 가상 함수인 것이다.

그나저나, this 포인터를 const로 바꿈으로써 이 멤버 함수가 실행 결과가 read-only임을 나타내는 const는, 자바와 C#에서 어떻게 표현하는지 모르겠다.

3.
뒷북일 수도 있지만 한 마디.
유니코드가 제정된 후에 발명된 언어인 자바와 C#은, 해당 언어가 규정하는 문자 집합이 유니코드이다. 그래서 char 형의 기본 크기가 놀랍게도 2바이트이며 문자열 리터럴도 기본이 유니코드 UTF16 형태이다. 게다가 변수를 비롯한 각종 명칭 이름을 한글로 지을 수 있다. ^^ 사실, 비주얼 스튜디오에서는 C# 소스 코드 자체가 기본적으로는 BOM까지 붙어 있는 UTF8 인코딩으로 저장된다.

하지만 C/C++은 그렇지 않다. 1970년대부터 존재한 저수준 시스템 언어인 만큼, 21세기에도 C/C++ 코드는 ANSI 인코딩이다. char 형은 규정상 무조건 1바이트여야 하고 절대로 바뀔 수 없으며, ""는 기본적으로 char 문자열이고 wide 문자열은 L""이라고 접두어를 붙여서 별도로 지정해 줘야 한다.

옛날의 일부 C언어 컴파일러는 키보드로 바로 칠 수 없는 일부 기호를 다른 기호의 나열로 대체하는 시퀀스까지 존재했었다. 그렇게도 열악한 환경에서부터 쓰였던 언어와 유니코드 시대에 등장한 언어는 그 배경이 극과 극일 수밖에 없다.

문자열 타입은 그렇다 치더라도 C/C++이 현대 언어들처럼 유니코드 명칭을 받아들이는 일도 있을 수 없다. 그러려면 그렇잖아도 링크라는 계층이 존재하는 언어인데 오브젝트 파일의 포맷이 바뀌어야 하고, 심지어 운영체제의 API 구조조차 바뀌어야 할지도 모른다. 윈도우 API 중에 GetProcAddress 함수의 둘째 인자가 괜히 PCSTR인 게 아니다(PCTSTR이 아닌 일반 string). 보수적이고 이식성을 생명처럼 여기는 이쪽 바닥에서는 상상조차 할 수 없는 일인 것이다.

이처럼, 똑같이 클래스가 있고 상속이 존재하는 소위 객체 지향 언어라 하더라도 C++, C#, 자바 같은 언어들의 설계 목적과 주 용도, 빌드 단계, 문법 구조, 고안된 당시 배경을 살펴보는 것은 각 언어들의 철학을 이해하는 데 큰 도움이 될 것이다.

Posted by 사무엘

본인은 얼마 안 있으면 적성 검사를 받아야 할 정도로 면허를 딴 지 오래 됐지만, 지금까지 차를 몬 경험이 거의 없고 운전 실력 역시 그 이름도 유명한 장롱 면허 수준에 머물러 왔다. 명절 때나 아니면 다른 일로 인해 고향을 드나들 때는 당연히 선택의 여지가 없이 대중교통만 이용했다. 이런 상황은 앞으로도 한동안 변하지 않을 것 같다.

하지만 이번 설에는 어떻게 여건이 잘 맞은 덕분에 21세기 이래로 최초로 자차를 이용했고, 더구나 꽤 장거리를 직접 운전까지 해서 무사히 도착하는 데 성공했다. 맨날 고속버스에 의지해서 다니던 경로를 내 손으로 주파하니 무척 기분이 좋았다.

1. 천호대로를 타고 지하철 5호선 라인을 따라 동쪽으로 쭉: 천호대로는 서울 시내에서 중앙 버스 전용 차선이 가장 먼저 생겼을 정도로 넓은 도로이다. 직진만 하면 되지만 길 자체가 직선으로만 된 것은 아니다. 중간에 커브도 있고, 언덕도 꽤 있다. 이쪽 구간은 한강이 수평선 방향이 아니라 수직선 방향에 가깝게 흐르기 때문에, 동쪽으로 가는 과정에서 천호 대교로 한강을 건너게 된다.

2. 외곽 순환 고속도로의 상일 IC까지 43번 국도: 강동 역까지 통과하고 나면 5호선 라인을 벗어난다. 이때부터 차선이 좁아지고 지나가는 차들이 눈에 띄게 뜸해지며, 아파트 대신 각종 화원, 공원, 언덕이 나타나면서 시가지가 아닌 교외 분위기가 물씬 풍긴다. 직진만 쫙 하면 고속도로가 나오니 이보다 간편할 수가 없다. 상일 IC로 진입하지 않고 또 직진을 하면 하남시가 나온다.지도로만 보던 지역을 실제로 구경할 수 있었다.

강남 고속버스 터미널이 반포 IC 인근에서 경부 고속도로를 접수하고 있다면 강변 동서울 터미널은 중부 고속도로를 접수하고 있다. 사실 이 터미널 자체가 중부 고속도로의 활성화를 위해 정책적으로 세워진 것이기도 하다. 그런데, 동서울 터미널에서 출발하여 중부 고속도로로 진입하는 버스들은 알고 보면 굉장히 비효율적인 경로를 이용한다.

먼저 올림픽 대교를 이용하여 강남으로 건넌 뒤, 올림픽대로를 타고 한참을 동쪽뿐만 아니라 ‘북쪽’으로 주행한다. 남쪽으로 가야 할 차가 북쪽으로 가서 상일 IC가 아닌 강일 IC를 통해 고속도로로 진입한다. 버스 차창을 살펴보면 서울 지하철 5호선 고덕 차량기지 근처를 지나는 게 보이니, 얼마나 우회 경로인지 알 수 있다. 이번에는 자가용을 직접 운전한 덕분에 그런 우회 경로를 피할 수 있었다.

3. 외곽 순환 고속도로(100): 8차선으로 된 근사한 도로이다. 조금만 남쪽으로 내려가면 하남 분기점이 나오고 여기서 중부 고속도로(35) 쪽으로 가면 동서울 요금소가 나온다. 새벽에 출발했지만 고난은 이제부터 시작이었다. 극심한 정체가 계속됐다.

4. 중부 고속도로: 이 도로는 처음엔 8차선인 것처럼 시작하지만 얼마 못 가 차선의 절반은 제2 중부 고속도로(37)로 빠져나가고 4차선으로 줄어든다. 제2 중부는 잘 알다시피 중부 고속도로의 용량 확장을 위해, 영동 고속도로(50)와 만나는 호법 분기점까지 오리지널 중부의 옆에다가 도로를 또 지은 것이다. 중부 고속도로는 경기도 남동부의 험악한 산지를 터널과 교량으로 연결한 험한 선형이기 때문에, 경부처럼 차선 확장을 도저히 할 수 없고 옆에 도로를 또 만들 수밖에 없었던 것이다.

5. 영동 고속도로: 호법 분기점과 여주 분기점까지는 잠시 영동 고속도로 구간을 이용한다. 8차선의 아주 시원시원한 길이었지만 중부내륙 고속도로(45)로 진입하는 길부터는 다시 차들이 거북이걸음을 시작했다.

6. 중부내륙 고속도로: 가장 장거리 구간이지만 정체가 심해서 좀 답답한 시간을 보내기도 했다. 4차선이고 최고 시속이 100이 아닌 110이며 터널과 고가 교량이 많다는 점에서는, 중부 고속도로와도 비슷하다.
내가 운전하던 무렵엔, 정체에 시달리던 하행과는 달리 맞은편 상행은 차가 거의 없고 한산하여 극단적인 대조를 보였다. 정체는 거의 괴산 이남까지 가서야 풀려서 차가 제 속도를 내기 시작했다.

그나저나 날씨가 정말 판타지 급이었다. 눈이 부슬부슬 내리다가 산악 지대로 가니 함박눈으로 돌변했는데, 터널을 하나 지나고 나오자 눈이 그치고 햇볕이 났다. 그랬는데 어느 샌가 또 잔뜩 흐린 날씨로 바뀌었다. 하지만 다행히 빙판길은 없었으니 눈 때문에 딱히 고생하지는 않았다.

7. 경부 고속도로: 김천부터 드디어 내게 아주 친숙한 경부 고속도로이다. 수도권이 아닌 곳에서 8차선이나 되는 유일한 고속도로이다. 물론 경산부터는 6차선으로 줄어들고 영천 이남부터는 4차선으로 줄어들지만 말이다. 경부 고속도로가 개통한 지 벌써 40주년이 돼 가는데, 아직까지 4차선을 유지하고 있는 극소수 구간이 그쪽이다.

여기부터는 가끔 서행 상태가 되긴 했지만 전반적으로는 소통이 원활했다. 무척 인상적인 점은 아까와는 반대로 상행이 막히고 있는 경우가 많았다는 것. 그나저나 포항으로 가는 길목인 도동 분기점에서의 극심한 혼잡이었다. 저 많은 차들이 포항을 드나드는 차들이라는 것에 적지 않게 놀랐다.

서울에서 경주까지 문에서 문까지 7시간 가까이 걸렸으니 그렇게 빨리 가지는 못했다. 워낙 정체가 심해서 이거 시속 100은 낼 기회가 있을까 궁금했는데 그래도 이따금씩 앞에 차가 없을 때는 순간적으로 130~140까지 밟은 적도 있었다.

영천에서 경주까지는, 중앙 분리대와 입체 교차로까지 갖추고 준 고속도로 급으로 변모해 있는 4번 국도를 이용했다. 시설 좋고 차도 거의 안 다니니 최적의 드라이브 코스였다. 최대 시속 80km로 설계되어 있지만 120까지 밟아 보기도 했다.
그런데 역시 고속도로와의 차이는 뭐니 뭐니 해도 커브의 반경이었다. 내가 지금까지 거친 어느 고속도로에서도 찾을 수 없는 급커브가 곧바로 느껴졌다. 국도와 고속 국도의 차이가 이런 것이구나. 도로의 설계 최대 시속은 이런 것까지 감안하여 산출된 것이다.

이렇게 무사고로 한번 완주는 했지만, 여전히 난 운전이 어렵게 느껴진다.
군대에서도 사고는 이병 시절이 아니라 어설프게 고참 행세를 시작하는 일병 시절에 많이 난다고 하듯, 자동차 사고도 완전 긴장이 바짝 든 왕초보 시절보다는 스스로 초보 딱지를 뗐다고 생각하고 방심할 때 가장 많이 난다고 생각한다.

아직까지도 핸들을 잡던 기억이 머리에 선하다. 방심하다가 금방이라도 앞 차를 추돌할 것만 같은 그런 느낌 말이다. 차간 거리를 굉장히 길게 유지하면서 달리고 싶은데 그러면 내 뒤에 있던 차가 어김없이 앞으로 끼어드니 그렇게 하기도 쉽지 않다.

Posted by 사무엘

예전에 짜 놓은 C++ 코드를 C#으로 포팅할 일이 있어서 모처럼 비주얼 스튜디오로 C# 프로젝트를 만들어 봤다. 그렇게 거창한 건 아니고, 그냥 콘솔에서 간단하게 입출력만 주고받는 150~200줄 남짓의 정올 답안 정도 되는 규모의 프로그램이다.

public void 이런 식으로 멤버 함수를 선언하는 것이나, 클래스 안에다가 함수 몸체를 다 써 넣는 것은 자바를 닮았다.
전처리기 같은 게 없고 C++보다 소스 코드 파싱이 훨씬 더 용이한 것 역시 자바와 일치한다. 사실 이건 요즘 객체 지향 언어들의 보편적인 추세이기도 하니까.

이 언어 역시 자바처럼 생산성 하나는 정말 좋겠다는 생각이 들었다. 파싱이 쉽기 때문에 IDE가 굉장히 똑똑해질 수 있다. 소스 코드 자동 리팩터링이라든가 인텔리센스 자동 완성, 코딩 컨벤션 교정 같은 것을 월등히 더 지능적으로 구현할 수 있다는 뜻.
실제로 C++ 쓰다가 C#을 쓰면 정말 그 편리함에 감탄하곤 한다.
환상적인 빌드 속도도 큰 매력이며, precompiled header 나부랭이도 없다. delete 때문에 골머리를 썩을 필요도 없다.
네이티브 바이너리를 못 만들어서 낭패이긴 하지만 말이다.

자바와 C#에는 C++에서 ::와 ->에 해당하는 연산자가 없으며 이들의 기능을 .이 모두 맡고 있다. 일단 포인터라는 게 존재하지 않으니 ->가 필요 없고, . 가 개체의 멤버 참조뿐만 아니라 scope와 namespace 식별까지 모두 맡고 있는 것이다. 그렇게 해도 문법상으로 모호해지지는 않는다.

C에는 다차원 배열이 존재하지 않으며 오직 배열의 배열 내지 다차원 포인터만이 그 개념을 대신하고 있는 반면, C#은 자유롭게 다차원 배열을 선언할 수 있다. 무슨 얘기냐 하면 실행 시간에 임의의 값으로 x*y 크기의 동적 배열을 만들 수 있다는 뜻. (C/C++은 언어 차원에서 이 간단한 일도 바로 가능하지 않다.)

C#은 콤마 연산자는 존재하지 않는 듯하다. 그리고 int 같은 기본 타입을 reference로 전달할 수 있는데, 이때는 반드시 ref를 추가해야 한다. 함수를 선언할 때 ref를 붙이는 건 마치 파스칼에서 var을 붙이는 것과 비슷한데, 이뿐만이 아니라 그런 함수를 호출할 때도 func(ref a) 이런 식으로 ref를 붙여야 하는 게 무척 신기하게 느껴졌다.

앞으로 간단한 벡터 그래픽 데모 프로그램을 짤 일이 있을 것 같은데 이것도 간단하게 C#으로 짜면 딱일 것 같다. 복잡한 최적화 루틴 같은 거 필요 없고, 그냥 결과물이 마음에 들 때까지 빌드를 엄청 자주 해야 할 텐데 C++보다 생산성이 월등히 더 뛰어날 수 있기 때문이다.
하지만 그러려면 Win32 API와는 완전히 다른 그래픽 체계를 또 공부해야 되네. -_-;;

Posted by 사무엘