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

한메 타자 교사(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 사무엘

- 한글 전용에 반대하고 학교에서 한자 교육을 더 일찍 더 많이 더 강화하는 걸 좋아한다.
- 각종 안내 표지판이나 공문서 같은 곳에서 한자를 더 많이 볼 수 있게 되는 걸 좋아한다.

- 한글 풀어쓰기를 극렬 반대하고 배척한다.
- 그들에게 한글과 한자는 수레의 양 날개이다.
- 중국· 일본의 지명/인명을 현지음으로 읽는 걸 극악으로 혐오한다. (북경 > 베이징, 모택동 > 마오 쩌둥)
- 띄어쓰기를 싫어하며 어지간한 복합 명사들은 붙이는 걸 선호한다.
- 세로쓰기에 굉장히 우호적이다.
- 중국, 일본 사람과의 필담(?)을 엄청 좋아하며 한중일 한자 일치 사업에 우호적이다.

- 영어, 알파벳 남발을 싫어한다. 거기까지는 좋은데 요즘 그렇게 돼 가는 원인이 한자를 안 가르쳤기 때문이라고 생각한다. -_-;;
- 오늘날 문화가 저질화하고 어휘력/사고력/학력 저하 따위가 한글 전용 때문이라고 생각한다. 일각에서는 심지어 좌경화까지 한글 전용 탓으로 돌린다.

- 부모님 이름을 한자로 못 쓰는 건 정말 치욕적인 불효이다.

* * * * * *
그 반면, '한글' 진영 안에서 보편적으로 통용되는 신념은..

- 한자 교육은 현행처럼 중학교부터 가르치는 거나 똑바로 잘 하면 충분하다고 여긴다.
- 한글 전용법의 '얼마 동안을' 조항마저도 이제 삭제해야 한다고 여긴다.
- 풀어쓰기는 주류가 되기는 곤란하나 특수한 분야의 연구 주제로 가치 정도는 인정한다.

- 한글 하나만으로 충분하며 한자는 말 그대로 얼마든지 우리 마음대로 처분해도 되는 낡은 유물(legacy)일 뿐이다.
- 언어에는 청각성이 배제되어서는 안 됨을 인지하며 불필요한 한자어 남발을 자제한다.
- 한자 문화권 국가라도 가능한 한 현지음 표기를 존중해야 한다고 여긴다.
- 엄밀한 맞춤법과 띄어쓰기를 추구하여 한글 자체를 '표의성'을 지닌 표음문자로 활용하려 노력한다.
- 가로쓰기, 탈네모꼴 글꼴 같은 쪽에 우호적이다.

- 한중일은 한자 안에서도 말과 글이 서로 다 달라져 있기 때문에 글자 일치 사업에 거의 의미를 두지 않는다.

Posted by 사무엘

http://www.hani.co.kr/arti/science/kistiscience/336364.html
http://pc21th.egloos.com/4496840
(참고)

철도는 선로 위의 돌멩이가 치명적인 약점이고
항공기는 조류 충돌이 치명적인 약점이라면
인공 위성, 우주 왕복선 등에는 지구 표면을 뒤덮고 있는 수천, 수만 개의 우주 쓰레기들이 치명적인 위협으로 작용하고 있습니다.

5, 60년대 처음 발사되던 당시에 인공 위성은 인류에게 우주 개발 시대를 여는 신호탄이었고, 미국· 러시아 같은 강대국의 최첨단 과학 기술의 총아였습니다.
지구는 둥글기 때문에 직진하는 전파만으로는 지구 반대편으로 신호를 보낼 수 없습니다. 과거에는 고맙게도 지구 대기권의 전리층이 전파를 반사해 주었기 때문에 어느 정도 무선 통신이 가능했습니다.

하지만 오늘날처럼 정보가 폭증하고 있고 옛날보다 훨씬 더 파장이 짧은 전파도 쏘아올리는 시대에는, 지구 전리층만으로는 한계가 있고 통신 위성이 전파를 별도로 처리해 주어야 합니다. 달에는 전리층 같은 것도 없기 때문에 달 뒷면에 쏙 숨으면 지구와 교신이 그대로 끊어져 버립니다. 놀랍죠?

위성은 말 그대로 한없이 지구를 향해 떨어지고 있는 덕분에 지구상에 떠 있는 존재입니다. 통신 용도로 쓰이며 지구 자전 주기와 공전 주기가 완전히 같은 '정지 위성'은 지표면으로부터 무려 35000km에 달하는 곳에 떠 있으며, 개수도 전세계적으로 200개가 채 되지 않습니다. 이 이상은 더 띄우지 않기로 국제 협약까지 맺어져 있습니다.

하지만 이보다 더 낮은 고도, 짧게는 300~2000km 정도의 고도에서 도는 인공 위성도 굉장히 많이 존재합니다. (이 정도만으로도 이미 최소한 열권 이상이고 우주나 다름없는 영역입니다) 그리고 이 저궤도 위성이 문제입니다.

낮은 궤도를 도는 위성은 그만큼 지표면과 가깝기 때문에 통신이나 정찰 임무를 더 원활히 수행할 수 있으며 띄우는 데 드는 비용도 저렴합니다. 그렇지만 그만큼 대기와의 마찰도 고궤도보다는 커서 계속 떠 있기가 힘들며, 지구를 매우 빠르게 돌아야 합니다. 공전 횟수가 하루에 10수 회 정도는 기본인 걸로 알고 있습니다.

이런 이유로 인해 저궤도 위성은 수명이 짧습니다. 열권 정도만 돼도 위성은 잘 알다시피 태양 방면과 지구 방면의 표면 온도차는 달의 낮과 밤의 차이만큼이나 벌어집니다. 위성은 이런 환경에서도 자체적으로 열 제어를 하고, 마치 통닭구이처럼 뱅글뱅글 돌면서 온도 배분을 균형 있게 하도록 설계되지요. 지표면보다 훨씬 더 열악하고 살벌한 환경에서 동작하는 기계인 것입니다. 거기에 돌아가는 컴퓨터도 오늘날의 PC에다 견주자면 XT급이 될까말까 하지만 그걸로도 옛날에는 임무 수행 할 걸 다 한 셈입니다.

하지만 수명이 다하고 이물질 때문에, 혹은 초속 수십 km로 날면서 공기와의 마찰이 누적되어 야기된 물리적 손상 때문에, 제품에 미묘한 오동작이 발생하면.. 이런 균형이 깨지게 됩니다. 위성은 이 온도차를 견디지 못하고 단순히 고장나서 작동만 중단되는 게 아니라 배터리 같은 것이 열받아서 펑 폭발합니다.

수명이 끝난 폐 인공 위성이라든가 이런 잔해들은 땅에 잘 떨어지지도 않고 초속 수~수십 km로.. 총알보다도 더 빠른 속도로 날아다니면서 우주 교통을 방해하는 요인이 되고 있으며, 인공 위성의 추후 발사를 어렵게 만들고 있습니다. 말 그대로 우주 쓰레기들입니다. 부딪치면 꽤 많이 아플 겁니다. 이 정도면 조류 충돌쯤은 저리가라이죠?

인공 위성 잔해는 아니지만, 로켓이 발사되면서 떨어뜨린 수백 kg급의 연료 탱크가 바닷속에 처박히지도 않고 우주 쓰레기가 되어 지구 주변을 돌고 있었다는 말에도 적지 않은 충격.
인간의 손길이 닿은 곳은 땅, 물, 공기도 모자라서 우주 공간까지 자가 회수가 되지 않는 폐기물 찌꺼기들로 몸살을 앓게 되는 것 같습니다. 무슨 일을 해도 깔끔하게 하질 못하고 꼭 side effect를 남기고, 뒷수습을 스스로 못 합니다.

이런 우주 쓰레기들은 컴퓨터로 비유하자면 garbage collection 없이 memory leak가 한계에 달하고 있는 컴퓨터 메모리라든가, 수천 개의 legacy들과 DLL hell로 몸살을 앓고 있는 과거 윈도우 시스템 디렉터리를 보는 것과 같습니다.

Posted by 사무엘

자동차가 다니는 도로 중에는 일반 시가지의 도로와는 달리, 진출입로를 입체화하여 신호 대기를 없애고 보행자는 물론 이륜차도 접근할 수 없게 한 ‘자동차 전용’ 도로가 있다. 이런 도로는 최고 속도 제한뿐만 아니라 최저 속도 제한까지 있어 많은 자동차가 원활하게 통과하도록 하고 있다.

한편, 도시와 도시를 이으며 해당 지역이 아닌 중앙 정부에서 노선을 직접 고시하여 관리하는 도로를 ‘국도’라고 부른다. 국도는 이미 번호로 매겨져 있어서 가령 1번 국도는 서울, 안양, 평택 등 처음엔 경부선 철도와 비슷한 길을 가다가 목포로 가며, 4번 국도는 경주 감포에서 출발하여 대전까지 경부선과 비슷한 방향을 향하다가 당진에서 끝난다. 국도라는 용어에는 시설이라는 개념은 그다지 들어있지 않기 때문에, 심지어 비포장 아니면 2차선 도로일 수도 있고 최근에 리모델링된 국도 구간은 미국 프리웨이급의 8차선의 고가 도로일 수도 있다. 원래 국도의 노선은 북한 지역까지 다 포함하고 있다.

이 글에서 다루고자 하는 한국의 고속도로는 자동차 전용 도로의 성격에 가깝지만 행정상으로는 ‘고속 국도’이다. 즉 국도이지만 통행료를 받는 유료 도로이고 시설이 일반 국도보다 훨씬 더 좋다. (88올림픽 고속도로는 예외이지만.)
사실 이런 고속도로와 개념적으로 정확하게 100% 대응하는 말이 영어에는 존재하지 않는다. 미국에는 한국의 경부 고속도로급의 넓고 잘 뻗은 길이 경부-경인 축이나 수도권에만 있는 게 아니라 미국 전역에 구축되어 있다. 하지만 한국과 같은 유료 도로는 아니다.

고속도로가 많지 않던 시절에는 매 도로마다 이름이 붙어 있었지만 요즘은 고속도로가 워낙 거미줄처럼 많이 놓이고 구조가 복잡해지면서, 우리나라도 고속도로의 이름을 없애고 일반 국도처럼 번호만으로 부르려고 시도하고 있다. (한국의 고속도로로서 상징적인 의미가 매우 큰 경부 고속도로는 당당히 1번이다.)
하지만 국민 정서상 그게 금방 정착할 것 같지는 않다. 주변에는 여전히 경부, 중부내륙, 영동 같은 명칭이 친숙하다.

이 한국의 고속도로는 유료 도로이다 보니 통행료를 징수하는 톨게이트가 존재한다. 마치 지하철 역 내부가 승차권 개집표기 전후로 분리되어 있고, 공항 내부가 탑승권 소지자만 들어가는 구역으로 분리되어 있는 것처럼 고속도로 구간을 분리하는 역할을 톨게이트가 하는 셈이다. 톨게이트는 차량의 소통을 크게 방해하기 때문에 이 오버헤드를 줄이고자 요즘은 하이패스 같은 기술이 등장하기도 했다.

톨게이트는 고속도로가 시작하는 양 종점에 있고 또 각 지역 인터체인지 말단에도 있다. 그래서 자동차는 톨게이트를 통과하여 고속도로에 진입한 후 톨게이트를 통과하여 고속도로에서 벗어나게 된다. 여기까지는 이해하는 데 아무 어려움이 없을 것이다.

그런데 경인이나 외곽 순환 같은 수도권 고속도로에서는 얘기가 좀 달라진다. 여기서는 단순히 장거리 여행이 아니라 매일 출퇴근을 고속도로로 하는 사람도 굉장히 많다. 진출입로인 인터체인지도 훨씬 더 조밀하게 많이 있다. 마치 일반 철도역 간격으로 있던 역이 (광역)전철역 간격으로 바뀌는 것과 정확히 같다. 여기에 일일이 다 톨게이트를 설치하고 수많은 차들을 세우는 것은 현실적으로 무리이다.

그렇기 때문에 이 두 고속도로는 다른 방법으로 통행료를 징수하고 있다.
일단 고속도로에 진입 자체는 톨게이트 없이 마음대로 한다. 하지만 도로 중간중간에 톨게이트가 있다. 외곽 순환의 경우 전구간을 통틀어 6개의 톨게이트가 있으며 경인 고속도로는 도로 중앙에 톨게이트가 하나 있다. 물론 통행료도 일반적인 거리 비례제가 아니라 고정된 요금을 매우 조금만 징수한다. 또한 톨게이트를 통과하지 않는 구간만 이용할 때는 통행료를 낼 필요가 없다.

따라서 경기도 남부에서 수평축의 외곽 순환 고속도로와 만나는 수직축의 서해안/경부/중부 고속도로들은, 외곽 순환 고속도로와 만나기 전에 이미 전통적인 방식의 요금 정산과 징수를 끝내야 한다. 그래서 제각기 서서울/서울/동서울 톨게이트는 안산, 성남 같은 꽤 남쪽에 자리잡고 있다.

철도뿐만 아니라 도로도 수도권과 비수도권이 상이한 교통 수요에 따른 상이한 운영 방식을 유지하고 있다는 것을 알 수 있다.

참고로, 철도는 서울을 기점으로 보지만 도로는 남북 통일과 대륙 진출을 염두에 두고 남쪽을 기점으로 보고 있다는 것이 흥미로울 것이다. 즉 경부 고속도로의 기점을 서울이 아닌 부산으로 본다는 것이다.

Posted by 사무엘

class CAppFrame: public CWnd {
public:
        void PostNcDestroy() { delete this; }
};

class CMyApp: public CWinApp {
public:
        BOOL InitInstance();
};

CMyApp g_App;

BOOL CMyApp::InitInstance()
{
        m_pMainWnd=new CAppFrame;
        m_pMainWnd->CreateEx(0, AfxRegisterWndClass(0), _T("Hello World"), WS_OVERLAPPEDWINDOW,
                100, 100, 500, 500, NULL, NULL);
        m_pMainWnd->ShowWindow(SW_SHOW);
        m_pMainWnd->UpdateWindow();
        return TRUE;
}

위의 코드는 MFC를 써서 만들 수 있는 가장 간단한 GUI 프로그램이다. 빈 창만 달랑 뜨는 게 허전하면, message map 넣고 OnPaint에다가 Hello, world! 출력하는 코드만 추가해 주면 된다.
MFC로 창을 띄우기 위해서는 본질적인 것 딱 두 가지만 기억하면 된다.

첫째, CWnd에서 상속 받은 클래스를 만들기

둘째, CWinApp에서 상속 하나 받아서 전역 개체를 하나 반드시 만들고, InitInstance를 오버라이드하여 내 윈도우 클래스를 생성하는 코드를 짜 주기

물론 요즘은 닷넷 프레임워크 같은 더 객체 지향적이고 깔끔한 API도 나와는 있지만 저 정도만 해도 그냥 C언어 + Win32 API만 썼을 때와는 비교할 수도 없이 간단하게 내가 원하는 일을 곧장 시작할 수 있다. 윈도우 클래스 등록, 윈도우 프로시저 등 온갖 지저분한 내부 처리를 상당 부분 MFC가 알아서 해 주기 때문이다.

MFC의 핵심부이며 가장 자주 다루게 되는 부분은 역시 윈도우를 나타내는 CWnd 관련 개체이다. 응용 프로그램의 메인 윈도우부터 시작해서 대화상자와 대화상자 안의 자그마한 컨트롤까지 매우 다양한 용도로 쓰이는 HWND를 한 뿌리 클래스와 상속 클래스만으로 원활히 제어하기 위해 MFC는 굉장히 심도 있게 설계되었으며 내부적으로 자질구레한 일들을 매우 많이 해 주고 있다. 단순히 ShowWindow(hWnd, SW_SHOW)를 wnd.ShowWindow(SW_SHOW)로 바꿔 주는 것을 훨씬 넘어서는 수준이다.

더구나 메시지 맵을 통해 컨트롤 서브클래싱(기존 윈도우 컨트롤의 동작을 부분적으로 조작하는 것)까지 매끄럽게 연결시킨 것까지 보면, 솔직히 굉장히 잘 만든 프레임워크임을 인정하지 않을 수 없다.

이런 프레임워크를 만들 때 근본적으로 문제가 되는 것은 CWnd라는 C++ 오브젝트와 운영체제의 HWND 사이의 씽크를 맞춰 주는 작업이다. 둘은 원래 개념적으로 생성 주기나 scope이 서로 완전히 다른 존재이다. 하지만 MFC는 한 HWND를 가리키는 CWnd 오브젝트가 중첩되지 않도록 배려하고 있으며, 나의 C++ 코드에 의해 생성되지 않은 외부 HWND에 대해서도 임시 맵까지 만들어 가면서 CWnd를 동기화해 주고 있다. 멀티스레드 환경까지 감안하면 이는 더욱 복잡한 작업이 된다.

new 연산자로 CWnd가 생성될 때 CreateWindow를 같이 해 주고, HWND가 완전히 소멸되어 WM_NCDESTROY가 왔을 때 CWnd까지 delete로 지워 주는 것은 대부분의 경우엔 바람직한 디자인 패턴이나, 이것이 언제나 유용한 것은 아니다. 가령 modal 대화상자는 자체적으로 message loop까지 갖추고 있기 때문에 heap이 아닌 스택에다가 간단히 지역변수로 선언하는 경우가 더 유용하기 때문이다. 더구나 대화상자는 사용자가 대화상자를 닫았더라도, 이 C++ 클래스 갖고 있는 데이터 변수들을 후에 활용하는 경우가 많기 때문에 HWND 개체가 사라진 뒤라도 C++ 개체는 남아 있어 줘야 한다.

이래저래 CWnd와 HWND 사이의 관계와 생성/소멸 주기는 여러 모로 이해하기 까다롭다. CWnd 클래스 중에서 new로 생성되고 HWND의 소멸과 동시에 소멸되어야 하는 오브젝트라면, PostNcDestroy 함수를 오버라이드하여 delete this를 넣어 주어야 메모리 누수가 발생하지 않는다. 응용 프로그램의 주 프레임 윈도우라든가 modeless 대화상자가 이런 예에 속한다.

저 소스 코드에서는 CWnd를 날것으로 사용했지만, CWnd에서 파생되어 아예 전문적으로 응용 프로그램의 주 프레임 윈도우를 담당하고 있는 MFC 클래스인 CFrameWnd는 PostNcDestroy가 이미 저렇게 구현되어 있다. 그뿐만 아니라 이 클래스는 LoadFrame 함수에서 이미 윈도우 클래스의 등록까지 다 알아서 해 주기 때문에 저 소스 코드에서처럼 AfxRegisterWndClass를 번거롭게 호출할 필요도 없다. 사용자가 준 ID와 일치하는 응용 프로그램 타이틀, 아이콘, 심지어 단축키 액셀러레이터 테이블 따위를 모두 엮어서 윈도우의 기반을 자동으로 구성해 주기 때문이다.

MFC를 써서 아주 간단한 프로그램을 짜고 싶은데 비주얼 C++의 MFC 마법사가 기본으로 생성해 주는 코드는 군더더기가 너무 많다. 그래서 이럴 때 본인은 MFC 없이 일반 Win32 응용 프로그램으로 프로젝트를 시작한 후, 저 코드 템플릿을 갖다 붙이고 프로젝트 세팅을 “MFC 사용”으로 수동으로 바꾸는 방법을 쓴다.

필요한 건 MFC가 잘 캡슐화해 준 message loop, 몇몇 GDI 오브젝트 같은 것밖에 없는데 이것만 쓰기에는 MFC는 덩치가 너무 커지고 static link를 하기에도 오버헤드가 너무 큰 것도 불만이다. 차라리 known DLL만 쓰기 때문에 매우 가벼운 바이너리를 만들 수 있는 비주얼 C++ 6.0이 그리울 때도 있다. 어차피 이후 버전에서 추가된 기능은 거의 안 쓰기 때문에.

<날개셋> 타자연습은 소스를 보면 알겠지만 딱 MFC를 써서 개발되었다. 하지만 한글 입력기는 3.0부터 MFC를 쓰지 않으며, 믿거나 말거나 MFC를 어설프게 흉내 내어 본인이 내부적으로 자체 개발한 프레임워크 라이브러리를 static link하여 개발해 오고 있다. 하지만 자체 라이브러리는 오버헤드 줄이고 최대한 가볍게 만드느라, Win32 API라든가 각종 핸들을 캡슐화한 수준이 MFC 수준으로 범용적이고 체계적이고 편하지는 못하기 때문에, 여전히 MFC가 그리울 때가 있다. ^^;;

Posted by 사무엘

밝은 초록색 선은 정석적인 원그리기 알고리즘으로 그린 진짜 원.
파란색 선은 제어점이 2개인 3차 베지어 곡선 하나로 사분원을 흉내낸 것,
그리고 빨간색 선은 제어점이 하나인 2차 베지어 곡선 두 개로 사분원을 흉내낸 것입니다.

베지어 곡선으로 원을 수학적으로 100% 정확하게 기술할 수는 없습니다.
단지 제어점을 잘 배치해서 원과 굉장히 비슷하게 생긴 곡선만을 그릴 수 있을 뿐입니다.

그래도 곡선이 그려진 곳에 초록색 점을 거의 찾을 수 없는 걸 알 수 있는데요, 3차 베지어 곡선(파란)만 해도 원하고 실용적으로 아무 차이가 없을 정도로 잘 근사해 냅니다.

빨간 선인 2차 베지어 곡선도 파란 선(≒ 원)과 상당히 일치하긴 하지만 그래도 파란 선이 초록 선과 일치하는 것만치 일치하지는 못합니다. 미묘하게 서로 살짝 어긋나는 오차가 보이죠?
(2차 곡선 여러 개를 모아도 3차 곡선을 근사만 할 수 있을 뿐 정확하게 일치시킬 수는 없습니다.)

컴퓨터의 벡터 드로잉에서 쓰이는 곡선들은 다 베지어 곡선(또는 이와 수학적으로 동일한 형태로 변형할 수 있는 다른 스플라인)입니다.
특히 트루타입 폰트가 쓰는 곡선은 2차 베지어 곡선이기 때문에 이렇게 빨간 선을 표현하는 방식과 동일한 방식으로 O, 이응, ● 같은 글자가 표현된다고 생각하시면 정확합니다.

Posted by 사무엘

예전에도 글로 쓴 적이 있지만, 16비트 윈도우 바이너리(exe/dll), 소위 NE 파일의 형태는 보면 볼수록 참 이상야릇하다고 느껴져서 흥미가 갑니다.

MZ로 시작하는 도스 EXE는 구조가 사실 매우 간단합니다. 맨 처음 32바이트 남짓한 구조체에다 몇몇 오프셋, 사이즈, 레지스터 초기값 따위를 넣고 재배치 정보(optional)만 넣어 주고 나면 그 뒤부터는 공통분모라는 게 없이 전적으로 프로그래머/컴파일러 재량입니다. COM은 아예 헤더란 것이 없고 곧장 코드+데이터가 등장하는 형태이니 초간단 패치 내지 램 상주 유틸리티, 혹은 심지어 바이러스를 만들 때 이보다 더 좋은 수단이 없었습니다.

하지만 좀더 복잡한 운영체제는 바이너리 파일에도 더 정교한 체계대로 구간별 역할을 딱딱 나누고 있습니다.
가령, EXE 뒤에다가 별도의 내장 데이터를 덧붙이는 것은 도스 시절에는 전적으로 컴파일러/링커 내지 해당 기능을 수동으로 제공하는 라이브러리의 재량이었습니다. 가령 볼랜드 컴파일러로 *.bgi 드라이버나 글꼴을 *.obj로 바꿔서 embed시키는 것은 운영체제보다 훨씬 더 상위 계층에서 행해지는 일이었죠.
하지만 윈도우에서는 운영체제 차원에서 바이너리 파일 안에 리소스라는 데이터 영역을 별도로 구분하여 관리해 주며, 이를 불러오는 API도 운영체제 차원에서 제공됩니다.

16비트 중에서도 윈도우 1.x(무려 1985년에 나온 바로 그것!), 2.x, 3.x의 포맷이 모두 서로 살짝 다르다고 하는데, 2.x 이상 바이너리는 오늘날 윈도우 운영체제의 NTVDM 하에서도 바로 실행 가능하다고 들었습니다. (9x 계열에서는 말할 나위도 없음.) 하지만 1.x도 리소스 데이터를 좀 변환하고 버전 플래그 같은 몇몇 값만 수정하면 곧장 실행할 수 있다고 하더군요. 윈도우가 하위 호환성을 상당히 잘 지키면서 버전업되어 왔다는 얘기가 되겠습니다.

0x3C 오프셋에 도스 바이너리가 아닌 실제 바이너리가 시작되는 위치가 기록되어 있다는 것은 NE(16비트 윈도우 바이너리), PE(오늘날의 32/64비트 바이너리) 모두 공통입니다. NE에도 PE와 마찬가지로 최소 운영체제 버전과 자신을 빌드한 링커의 버전이 헤더에 명시되어 있습니다.

윈도우 3.x 바이너리들은 대개 링커 버전이 5~6 정도로 잡혀 있던데 이건 비주얼 C++ 버전이 아니라 그 전신인 MS C 버전 기준이라고 보는 게 타당하겠습니다. 비주얼 C++ 1.5x는 MSC_VER의 값이 600밖에 안 되거든요. 그 반면 요즘 비주얼 C++ 200x는 이미 무려 1300~1500대까지 올라갔죠.

최소 운영체제 버전은 물론 3.10으로 잡으면 윈도우 3.1에서 실행 가능합니다. 하지만 이 수치를 더 높게 4.0으로 잡으면 “윈도우 3.1에서 실행되지 않는 16비트 윈도우 바이너리”를 만들 수 있습니다.

그런 예가 무엇이 있냐 하면 바로 윈도우 9x 이후에 제공되는 SysEdit.exe입니다. 이 프로그램은 16비트 EXE이지만 정작 윈도우 3.1에서는 실행이 안 됩니다. 하지만 윈도우 9x에서 실행하면 비록 16비트 EXE이지만 대화상자의 배경을 다른 32비트 프로그램들처럼 회색 입체 효과로 입혀 주며 16비트 프로그램과 호환되지 않는 일부 신규 메시지/API를 32비트 프로그램과 같은 스타일로 날려 줍니다. Win32s도 아니고 참 난감한 케이스이죠? 윈도우 9x가 나오던 당시, MS에서 내부적으로 기존 16비트 프로그램들의 외형 껍데기의 이질감을 줄이려고 넣은 꽁수에 가깝다고 보면 되겠습니다.

요즘은 파일 포맷을 설계할 때 최대한 확장성을 고려하여 chunk 테이블부터 넣는 게 일반적입니다. MIDI(음악), TTF(글꼴), PNG(그래픽)들이 다 그렇죠. PE도 마찬가지여서 text, data, reloc, rsrc 같은 청크 식별자가 존재합니다. 하지만 NE는 나중에 등장한 PE와는 달리 그런 구분은 존재하지 않으며 헤더, 세그먼트 테이블, 리소스 테이블, 이름 테이블 등 미리 정해진 정보가 순차적으로 쭉~ 등장하는 형태입니다.

kernel, user, gdi처럼 내가 참조하여 import하는 다른 모듈의 API에 대한 정보는 있지만 PE처럼 함수명이 그대로 기록되어 있지는 않고 그냥 서열 번호만 들어가는 것 같습니다. 또한 윈도우 1.x가 맨 처음에 파스칼로 개발되어서 그 영향을 받아서인지, export하는 심볼 이름들은 다 대문자로만 적혀 있고 대소문자 구분은 딱히 안 하는 걸로 보입니다. 물론 윈도우 내부 API가 SDK 형태로 최초로 정식 공개된 3.0 시절에는 이미 다 C언어 기반으로 바뀌었지만.

끝으로, NE에는 PE에 전혀 없는 개념인 name table이라는 게 있습니다. 프로젝트 빌드할 때 *.DEF 파일로부터 링커가 생성해 주는 테이블일 겁니다.
그것도 resident name, non-resident name이라 하여 언제나 메모리에 상주하는 것, 아니면 언제나 상주시키지 않기는 때문에(메모리 아끼기 위해) 불러오는 데 시간이 좀 걸릴 수도 있는 것으로 종류도 나뉘어 있습니다. 둘 다 자신이 export하는 함수들의 명칭 같은데 정확한 용도가 무엇인지, 그리고 또 왜 이런 식으로 분류를 했는지는 알 길이 없습니다. 인터넷으로도 이런 게 있다는 식으로 기계적으로 설명해 놓은 자료만 있지, NE 포맷을 왜 이런 식으로 만들 수밖에 없었는지 같은 친절한 설명은 정말 찾을 수 없더군요.

또한 이 테이블에는 꼭 export symbol만 들어가는 게 아니라, non-resident name의 1순위로는 이 프로그램의 full name도 같이 들어갑니다. 즉, 버전 리소스를 굳이 안 뒤져도 여기를 찾아봐도 “Microsoft Visual C++”, “FontMania” 같은 정보를 얻을 수 있다는 것이죠. 오늘날 쓰이는 PE에는 이런 정보가 없습니다.

윈도우 3.1의 기본 프로그램인 문서 작성기, 페인트 등의 EXE를 들여다보면 마치 DLL처럼 프로그램의 내부 함수로 추정되는 명칭(특히 윈도우/대화상자 프로시저)을 상당수 non-resident name table에다가 export해 놓은 것을 알 수 있습니다. PageInfoWndProc, DialogGoto, BroadcastChildEnum 등. 왜 이렇게 해 놓은지는 저는 16비트 윈도우 개발 경험이 없으니 알 길이 없습니다. 메모리가 캐 부족하던 시절에 아마 한 번 만들어 놓은 코드는 EXE, DLL을 불문하고 최대한 많이 재사용하려고 이렇게 한 게 아닌가 싶습니다.

그나마 resident name table은 거의 쓰지도 않는 거 같던데 왜 만들었는지도 모르겠고.. 수수께끼이군요. 참고로 32비트 시대로 와서는 리소스 같은 건 free 한다는 개념 자체가 없어졌습니다. 당연히 resident, non-resident 같은 구분도 전혀 필요 없죠.

대략 이렇게 NE 포맷에 대해서 살펴봤는데, PE까지 그대로 이어지고 있는 개념도 있는 반면 어떤 것은 완전히 다른 것도 존재한다는 걸 알 수 있었습니다. 역시 16비트와 32비트 사이에는 넘사벽 같은 gap이 있는 듯이 보입니다.

Posted by 사무엘

오랜만에 플게에 이런 이슈가 나와서 우리말 쪽으로도 글을 써 본다.

1. 서로, 스스로를 부사가 아닌 명사로 쓰는 것은 잘못됐다.
OK. 공감함.
  서로가 서로를 배려해야 한다. (X)
  각자(우리)가 상대를 배려해야 한다. (O)

  네 스스로에게 문제가 있다. (X)
  너 자신에게 문제가 있다. (O)
O 같은 어휘를 생각해 내기가 귀찮아서 X로 단순화하고 있는 것 같다.

하지만 '모두'까지 부사로만 써야 하고 명사형이 잘못됐다는 것은 현실성이 없다.
모두를 안 쓰면 전부, 전체 같은 한자어가 대신 들어갈 수밖에 없음.

2. 그녀라는 말을 쓰지 말아야 한다.
응, 충분히 취지를 이해하며 가능한 한 다른 걸로 표현을 바꿔 쓰고 싶은데 전혀 안 쓸 수가 있나?
특히 성경 번역 같은 거 할 때.. 한국어에 she 같은 개념 자체가 없었고 이제는 필요해졌는데 어떡하라고?

3. '-에 있어서'란 말을 쓰지 말아야 한다.
OK. 정말 장황한 군더더기이고 '더 이상'만큼이나 안 쓰고 지냄.

4. 역할, 입장, 불구하고(despite, in spite of) 같은 말도 쓰지 말아야 한다.
글쎄. 한동안 구실, 관점, though 같은 다른 표현도 써 봤지만 전자는 후자하고 의미가 다른 면모가 있다.
완전히 안 쓸 수는 없을 것 같으며, 특히 이런 문제와 관련하여 본인의 고민은 도대체 일본과 한국이 공용하는 한자어들 중 어떤 건 괜찮고 어떤 건 써서는 안 되는지 판단하는 그 잣대가 불분명하다는 것이다. 이건 판단 보류.

5. 애매하다와 모호하다를 구분해야 한다.
OK. 좋은 지적.
  공연히 애매한 사람을 들볶다..
  의미가 너무 모호(한자어)하고 막연하다.

6. '의'자 붙이는 거 자제해야 한다.
가능한 한 지키려고 노력하지만, 싸그리 몰아낼 수는 없다.
'의'자 안 붙이고 링컨 대통령의 "국민의, 국민에 의한, 국민을 위한 정치"를 번역할 수는 없는 노릇이 아닌가.
한국어는 이런 점에서 표현력이 무척 떨어지는 면모가 있다.
'A의 평면 B로의 정사영'... 영락없는 영어/일본어 번역투인 것은 알지만 도대체 이보다 더 간편하게 어떻게 번역할 수 있겠는가?

7. '보다'를 주의해서 써야 한다.
  보다 나은 미래 (X)
  네가 나보다 낫다 (O)
OK. X는 영 어색하고 기초적인 우리말 문법 관념도 없이 생겨난 표현임을 인정한다. '(좀)더'만 써도 충분하죠.

8. 했었다 같은 이중 과거
순화 운동가들이 보면 펄쩍 뛰고 노발대발할 말투인데..
원래 한국어에는 없던 시제 표현을 확장해서 받아들인 거라고 볼 수 있지 않을까? "간 적이 있다"를 줄여서 "갔었다"라고.. 굳이 배척할 필요는 없다고 느낀다.

9. '가지다' 남발
OK. 한국어의 정서와 명백하게 이질적인 own, have 직역투는 자제염..;;
쓰기 전에 한번 생각을 해 보고 쓰자.
임신하면 아이를 배는 거지 아이를 갖는 게 아니다.
행사를 가지는 건 너무 심했잖아!

이것 말고 또 무슨 예가 있을까?
본인은 고등학교 시절에 이 오덕 선생, 대학교 시절에 이 수열 선생님의 우리말 순화 책을 섭렵한 경험이 있다.
100% 공감하지는 못하는 사항도 있지만 어쨌든 우리말의 실태에 대해 많은 생각을 일깨워 준 좋은 내용이었다.

스스로 판단하기에 OK라고 결론을 내린 사항들은 나름대로 이 홈페이지 열 무렵부터 그대로 지켜 왔다.
지금은 한말글 정신이 투철하던 2001~02 시절에 비해서는 많이 타-_-락해서 본인 쓰는 글에 한자어, 영단어도 예전보다 많이 들어간 편이지만, 그래도 감각 자체를 잃어버린 건 아니다.

나의 원칙은 간단하며 실용성을 지향한다.

- 한국어가 의미가 잘 구분되고 문법에 원칙이 있는 언어가 되는 방향으로: 다르다/틀리다는 반드시 구분해서 써야 한다. '더 이상' 같은 말을 쓰지 말아야 한다.
- 청각적으로 구분이 잘 되는 방향으로: 그래서 한글 전용 지지이다.
- 그리고 가능하면 짧고 간결하게
- 그리고 가능하면 토박이말에 우선순위: 어설픈 외래어 순화보다, 이미 있던 순우리말부터 먼저 퍼뜨리고 써야 한다.

4번을 제외하고 위의 세 가지 대원칙에 역행하지 않는다면 외래어나 번역투도 다른 우리말 순화 운동가들에 "비해서는" 그렇게 배척하지 않는다.
우리말이 영어처럼 수동태가 발달해 있지 않고 자주 쓰이지 않는 것은 사실이나 우리말에 수동태에 해당하는 표현이 없어서 좋을 것도 없는 건 사실이지 않은가.

물론, 번역투 때문에 말이 장황하고 거추장스러워지는 것은 분명히 경계한다. 또한 외래어나 외래 문체가 전혀 필요하지 않고 이미 멀쩡히 잘 쓰이던 우리말 표현까지 왜곡되고 파괴되는 것 역시 막아야 할 것이다.

우리말과 글 쪽의 홍보/계몽은 이렇듯 분명한 원칙과 체계를 갖추고 추진해야 쓸데없는 논쟁과 반감에 휩싸이지 않는다.

그리고 "비판을 하려면 수긍할만 한 대안을 제시하라." 주의이다.
그런 거 없이 무조건 뭐 일본식 한자어니까, 번역투란 이유만으로 쓰지 말자는 주장은 그냥 가능한 한 기피하는 고려 수준은 될 수 있어도, 적극적으로 안 쓰지는 않는다.

내가 또 하나 주장을 하는 걸로 글을 맺겠다. 나름대로 이 바닥에 짬밥도 있기 때문에 응용하는 것이다.

※ '기존'은 '예전'이 아니다. 제발 똑바로 쓰자.

- 현존, 실존 이런 단어하고 똑같은 용법으로 써야 하는 말이다.
- "기존에 있던 것들은 다 지워라" 이런 말... 정말 한숨만 나온다. "기존하는 것들은" 아니면 "예전의 것들은"이라고 쓰는 게 낫다.

Posted by 사무엘

요세미티 국립 공원과, 샌프란시스코 일대의 관광 사진부터 먼저..

(1)

모레 아침이면 벌써 귀국이다. ㅠㅠ (여기는 지금 금요일 저녁)
내일은 멀리는 안 나가고 쉬면서 선물 쇼핑 위주로 시간을 보내게 될 것 같다.
한국은 또 환율이 워낙 올라서, 이거 귀국 후에 남은 달러를 되팔아도 차익 챙길 수 있을 정도가 돼 있구나. -_-;;

민박을 한 집안이 다 크리스천 가정이었다.
LA에서 만난 분들은 아예 매주 우리 서울 교회 목사님하고 잘 알고, 설교를 정기 구독하는 KJV 신자들이니 노선이 완전 일치한다. 그러니 그 교회 다니는 청년이 미국 방문한 거니까, 이거 뭐 일면식인 사람들하고도 어지간한 친척 이상으로 친밀하게 지낼 수 있었다.

샌 프란시스코에서 만난 가정도 KJV까지 일치는 아니지만 꽤 열심히 믿는 장로교 집안이었다. 이것만으로도 마음이 굉장히 편했다.

금문교를 비롯해 볼 거 다 봤다.
말로만 듣던 실리콘 밸리와, 스탠포드, UC 버클리 대학도 다 눈도장 찍고 사진 찍었다. 둘은 서로 사립, 공립이라는 차이도 있거니와 캠퍼스 분위기가 서로 굉장히 다른 것 같았다.

프리웨이 저 너머로 보이는 저 건물이 말로만 듣던 휴렛 패커드, 야후의 본사라니 감개무량했다.

(2)

무지로 인해 한 가지 실망한 것.
샌 프란시스코에 UC 버클리 대학이 있고,
매사추세츠 주에 버클리 음악 대학은 따로 있다.
한글로는 구분되지 않으나 영어 스펠링이 서로 다르다. Berkeley vs Berklee.. -_-;;
내가 가 본 곳은 당연히 전자..

(스탠포드 대학과 라이벌 관계이다. 참고로 스탠포드 대학은 아래..)

버클리라고 해서 Looking for you의 작곡자 MALTA님이 거쳐 간 학교를 이 기회에 성지 순례로 방문하는가 싶었지만 그건 아니었다. T_T
후자뿐만 아니라 전자도 재즈 쪽이 강하다고 하더라만..
아마 송 영주 씨가 거쳤다는 버클리 대학도 전자가 아니고 후자이지 싶다. 한글로만 적으면 구분 못 한다. 전자를 "UC 버클리"로, 후자를 "버클리 음악 대학"으로 구분해 줘야 한다.

(3)

혼자 이렇게 훌쩍 외국으로 떠나는 것도 그렇게 어려운 일이 아니란 걸 알게 됐다.

미국 가기 전까지는 이민에 대해서 부정적인 얘기를 주로 많이 들어 왔다.
의료 제도가 완전 개떡이다,
유색 인종에 대한 정서적 차별이 여전하고 치안도 형편없다, 미국도 이제 예전의 미국이 아니다,
그저 교육비, 기름값 비싸다는 이유 정도만으로 한국 떠나고 싶다는 식의 소리는 꿈에도 하지 마라.

처럼.

하지만 여기서는 약간 다른 의견도 들었다.
여기에 잘 정착해 계신 분들은 하나같이 한국보다 여기가 살기 좋다고 말한다.
(한국과는 달리) 법과 원칙이 통한다,
연줄이 아니라 실력만 있으면 인정 받을 수 있다,
국민성이 훨씬 더 선진적이다,
굳이 대도시에 안 매달려도 푸근하게 잘 살 수 있다 등.

그리고 만난 분들로부터도,
너처럼 영어 걱정 없고 미국 음식 거부감 없고
더구나 컴퓨터 쪽 하는 사람은, 여기 와서 공부 계속하다 영주권 받고 걍 정착하라는 제안도 적지 않게 받았다. ㄱ-

단순히 개인의 영달 차원이 아니라
유능한 사람들이 이민 듬뿍 가 줘서 전세계에 코리아 타운 건설하고 한국인들이 정착해서 살 수 있는 터전을 마련하는 게 애국 행위라는 얘기까지 나오더라.
실제로 재미 교포들이 국내 수출 자동차나 전자 기기도 듬뿍 사 주고, 외환 위기 때 달러도 굉장히 많이 보태 줬다고 한다.
스타로 치면 끝없는 멀티 확장 뻘 되겠다.

에휴, 하지만 본인은 유학 가기엔 학부 성적도 상당히 안 좋고,
무엇보다도 한글 입력기, 한국 철도 등..
내 전문 특기 분야 자체가 그다지 미국에서 인정 받을 만한 분야가 아니니, 말씀은 고맙지만 현실성은 별로 높지 못하다. -_-;;

(4)

- 도로에 가끔씩 XING 이렇게 적혀 있는 게 도대체 뭐지? 한어병음 표기 같아서 중국식 지명이나 도로명인 줄 알았는데 LA뿐만 아니라 샌 프란시스코에서도 보인다.
나중에 알고 보니 CROSSING (횡단)을 줄여 쓴 것이었다. ㅜㅜ
미국 도로 표지판에도 그런 거 굉장히 많다. BLVD, RD, INTL
X는 Z소리도 되고, 음절 말미에서 ks 소리도 되고, 저런 의미도 갖고 있다. ㅜㅜ #이 sharp도 되고 number도 되는 것처럼.

- 흰 달걀을 미국 가서야 거의 10년만에 처음 본 거 같다. 우리나라는 묘하게 흰 달걀이 완전 자취를 감추고 말았다. 살색 달걀하고 맛, 영양이 아무 차이가 없는데 소비자 취향이 한데 우루루 쏠려 버렸기 때문이다.

- 미국에서 어디 돌아다니느라 차 안에서 보낸 시간이 정말 어마어마했다. 만약 다음에 또 미국 갈 일이 있을 때는 차에서 들을 수 있는 오디오 내지 MP3 씨디 하나 좀 구워 가야겠다. 오랫동안 Looking for you 못 들으니 금단 증세 때문에 좀 괴로웠다. ㅜㅜ
10년 안으로, 이번 여권과 비자 유효 기간이 끝나기 전엔 또 갈 기회가 있으려나? 더구나 미국 비자는 면제 직전에 꽤 번거롭게 받은 건데, 한 번 방문만으로 끝내 버리면 아까우니까. -_-

Posted by 사무엘

여기 낮엔 완전 더워서 초여름 같습니다.
여름 같은 날씨에 겨울 같은 낮 길이는 태국에서도 경험한 적 있지만 참 적응 안 되네요.

Posted by 사무엘